draft-ietf-noop-echo-00.txt   rfc1575.txt 
An Echo Function for ISO 8473 Network Working Group S. Hares
Request for Comments: 1575 Merit/NSFNET
Obsoletes: 1139 C. Wittbrodt
Category: Standards Track Stanford University/BARRNet
February 1994
Network Working Group IETF-NOOP Working Group An Echo Function for CLNP (ISO 8473)
INTERNET DRAFT R. Hagens January 1990
Revised C. Wittbrodt
1. Status of this Memo Status of this Memo
This memo is an Internet Draft. Internet Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Internet community, and requests discussion and suggestions for
Areas, and its Working Groups. Note that other groups may improvements. Please refer to the current edition of the "Internet
also distribute working documents as Internet Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet Drafts are draft documents valid for a maximum of Abstract
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each This memo defines an echo function for the connection-less network
Internet Draft directory to learn the current status of this layer protocol. The mechanism that is mandated here is in the final
or any other Internet Draft. process of being standardized by ISO as "Amendment X: Addition of an
Echo function to ISO 8473" an integral part of Version 2 of ISO 8473.
This Internet Draft defines an echo function for the Table of Contents
connection-less network layer protocol. This memo is not
intended to compete with an ISO standard. This is a Pro-
posed Elective Standard for the Internet. Distribution of
this memo is unlimited.
2. Abstract Section 1. Conventions ................................. 2
Section 2. Introduction ................................ 2
Section 3. The Generic Echo Function ................... 3
Section 3.1 The Echo-Request ........................... 3
Section 3.2 The Echo-Response .......................... 3
Section 4. The Implementation Mechanism ................ 4
Section 4.1 The Echo-Request ........................... 4
Section 4.2 The Echo-Response .......................... 4
Section 5. Implementation Notes ........................ 4
Section 5.1 Discarding Packets ......................... 4
Section 5.2 Error Report Flag .......................... 4
Section 5.3 Use of the Lifetime Field .................. 5
Section 5.4 Echo-request function ...................... 5
Section 5.5 Echo-response function ..................... 6
Section 5.6 Use of the Priority Option ................. 8
Section 5.7 Use of the Source Route Option ............. 8
Section 5.8 Transmission of Multiple Echo-Requests ..... 9
Section 6. Security Considerations ..................... 9
Section 7. Authors' Addresses .......................... 9
Section 8. References .................................. 9
This memo defines an echo function for the connection-less 1. Conventions
network layer protocol. The mechanism that is recommended
here is in the final process of being standardized by ISO as
"Amendment X: Addition of an Echo function to ISO 8473" This
document is intended to mirror the ISO work and provide easy
access to that information to the Internet community
3. Table of Contents The following language conventions are used in the items of
specification in this document:
An Echo Function for ISO 8473 o MUST, SHALL, or MANDATORY -- the item is an absolute
requirement of the specification.
Section 1 Status of this Memo ......................... 1 o SHOULD or RECOMMENDED -- the item should generally be followed
Section 2 Abstract .................................... 1 for all but exceptional circumstances.
Section 3 Table of Contents............................ 1
Section 4 Introduction ................................ 2
Section 5 The Generic Echo Function ................... 3
Section 5.1 The Echo Request .......................... 3
Section 5.2 The Echo Reply ............................ 3
Section 6 The Implementation Mechanism ................ 4
Section 6.1 The Echo Request .......................... 4
Section 6.2 The Echo Reply ............................ 4
Section 7 Implementation Notes ........................ 4
Section 7.1 Discarding PDUs ........................... 4
Section 7.2 Error Report Flag ......................... 4
Section 7.3 Use of the Lifetime Field ................. 5
Section 7.4 Echo request function ..................... 5
Section 7.5 Echo response function .................... 7
Section 7.6 Use of the Priority Option ................ 8
Section 7.7 Use of the Source Route Option ............ 8
Section 7.8 Transmission of Multiple Echo Requests .... 8
Section 8 Security Considerations ..................... 9
4. Introduction o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
The OSI Connection-less network layer protocol (ISO 8473) 2. Introduction
defines a means for transmitting and relaying data and error
report PDUs through an OSI internet. Unfortunately, the
world that these packets travel through is imperfect. Gate-
ways and links may fail. This memo defines an echo function
to be used in the debugging and testing of the OSI network
layer.
Network management protocols can be used to determine the The OSI Connection-less network layer protocol (ISO 8473) defines a
state of a gateway or link. However, since these protocols means for transmitting and relaying data and error protocol data
themselves utilize a protocol that may experience packet units, (PDUs) or preferably, packets through an OSI internet.
loss, it cannot be guaranteed that the network management Unfortunately, the world that these packets travel through is
applications can be utilized. A simple mechanism in the imperfect. Gateways and links may fail. This memo defines an echo
network layer is required so that systems can be probed to function to be used in the debugging and testing of the OSI network
determine if the lowest levels of the networking software layer. Hosts and routers which support the OSI network layer MUST be
are operating correctly. This mechanism is not intended to able to originate an echo packet as well as respond when an echo is
compete with or replace network management; rather it should received.
be viewed as an addition to the facilities offered by net-
work management.
The code-path consideration requires that the echo path Network management protocols can be used to determine the state of a
through a system is identical (or very close) to the path gateway or link. However, since these protocols themselves utilize a
used by normal data. An echo path must succeed and fail in protocol that may experience packet loss, it cannot be guaranteed
unison with the normal data path or else it will not provide that the network management applications can be utilized. A simple
a useful diagnostic tool. mechanism in the network layer is required so that systems can be
probed to determine if the lowest levels of the networking software
are operating correctly. This mechanism is not intended to compete
with or replace network management; rather it should be viewed as an
addition to the facilities offered by network management.
Although backward compatibility is an important considera- The code-path consideration requires that the echo path through a
tion whenever a change is made to a protocol, it is more system be identical (or very close) to the path used by normal data.
important at this point that the echo mechanisms used on the An echo path must succeed and fail in unison with the normal data
path or else it will not provide a useful diagnostic tool.
An Echo Function for ISO 8473 Previous drafts describing an echo function for CLNP offered two
implementation alternatives (see RFC 1139). Although backward
compatibility is an important consideration whenever a change is made
to a protocol, it is more important at this point that the echo
mechanisms used on the Internet interoperate. For this reason, this
memo defines one implementation mechanism (consistent with one of the
previous drafts).
Internet interoperate. For this reason, this memo defines 3. The Generic Echo Function
one implementation mechanism.
5. The Generic Echo Function The following section describes the echo function in a generic
fashion. This memo defines an echo-request entity. The function of
the echo-request entity is to accept an incoming echo-request packet,
perform some processing, and generate an echo-response packet. The
echo implementation may be thought of as an entity that coexists with
the network layer. Subsequent sections will detail the
implementation mechanism.
The following section will describe the echo function in a For the purposes of this memo, the term "ping" shall be used to mean
generic fashion. This memo defines an echo-request entity. the act of transmitting an echo-request packet to a remote system
The function of the echo-request entity is to accept an (with the expectation that an echo-response packet will be sent back
incoming echo-request PDU, perform some processing, and gen- to the transmitter).
erate an echo-reply PDU. The echo implementation may be
thought of as an entity that coexists with the network
layer. Subsequent sections will detail the implementation
mechanism.
For the purposes of this memo, the term "ping" shall be used 3.1. The Echo-Request
to mean the act of transmitting an echo-request PDU to a
remote system (with the expectation that an echo-reply PDU
will be sent back to the transmitter).
5.1. The Echo Request When a system decides to ping a remote system, an echo-request is
built. All fields of the packet header are assigned normal values
(see implementation specific sections for more information). The
address of the system to be pinged is inserted as the destination
NSAP address. The rules of segmentation defined for a data (DT)
packet also apply to the echo-request packet.
When a system decides to ping a remote system, an echo- The echo-request is switched through the network toward its
request is built. All fields of the PDU header are assigned destination. (An echo packet must follow the same path as CLNP data
normal values (see implementation specific sections for more packet with the same options in the CLNP header.) Upon reaching the
information). The address of the system to be pinged is destination system, the packet is processed according to normal
inserted as the destination NSAP address. The rules of seg- processing rules. At the end of the input processing, the echo-
mentation defined for a DT PDU also apply to the echo- request packet is delivered to the echo-request entity.
request PDU.
The echo-request is switched through the network toward its The echo-request entity will build and dispatch the echo-response
destination. Upon reaching the destination system, the PDU packet. This is a new packet. Except as noted below, this second
is processed according to normal processing rules. At the packet is built using the normal construction procedures. The
end of the input processing, the echo-request PDU is destination address of the echo-response packet is taken from the
delivered to the echo- request entity. source address of the echo-request packet. Most options present in
the echo-request packet are copied into the echo-response packet (see
implementation notes for more information).
The echo-request entity will build and dispatch the echo- 3.2. The Echo-Response
reply PDU. This is a new PDU. Except as noted below, this
second PDU is built using the normal construction pro-
cedures. The destination address of the echo-reply PDU is
taken from the source address of the echo-request PDU. Most
options present in the echo-request PDU are copied into the
echo-reply PDU (see implementation notes for more informa-
tion).
5.2. The Echo Reply The entire echo-request packet is included in the data portion of the
echo-response packet. This includes the echo-request packet header
as well as any data that accompanies the echo-request packet. The
entire echo-request packet is included in the echo-response so that
fields such as the echo-request lifetime may be examined when the
response is received. After the echo-response packet is built, it is
transmitted toward the new destination (the original source of the
echo-request). The rules of segmentation defined for a data packet
also apply to the echo-response packet.
The entire echo-request PDU is included in the data portion The echo-response packet is relayed through the network toward its
of the echo-reply PDU. This includes the echo-request PDU destination. (A echo response packet must follow the same path as a
header as well as the any data that accompanies the echo- CLNP data packet with the same options in the CLNP header.) Upon
request PDU. The entire echo-request PDU is included in the reaching its destination, it is processed by the packet input
function and delivered to the entity that created the echo-request.
An Echo Function for ISO 8473 4. The Implementation Mechanism
echo-reply so that fields such as the echo-request lifetime The implementation mechanism defines two new 8473 packet types: ERQ
may be examined when the reply is received. After the (echo-request) and ERP (echo-response). With the exception of a new
echo-reply PDU is built, it is transmitted toward the new type code, these packets will be identical to the date packet in
destination (the original source of the echo- request). The every respect.
rules of segmentation defined for a DT PDU also apply to the
echo-reply PDU.
The echo-reply PDU is relayed through the network toward its 4.1. The Echo-Request
destination. Upon reaching its destination, it is processed
by the PDU input function and delivered to the entity that
created the echo-request.
6. The Implementation Mechanism The type code for the echo-request packet is decimal 30.
The implementation mechanism will define two new 8473 PDU 4.2. The Echo-Response
types: ERQ (echo-request) and ERP (echo-reply). With the
exception of a new type code, these PDUs will be identical
to the DT PDU in every respect.
6.1. The Echo Request The type code for the echo-response packet is decimal 31.
The type code for the ERQ PDU is decimal 30. 5. Implementation Notes
6.2. The Echo Reply The following notes are an integral part of memo. It is important
that implementors take heed of these points.
The type code for the ERP PDU is decimal 31. 5.1. Discarding Packets
7. Implementation Notes The rules used for discarding a data packet (ISO 8473, Section 6.9 -
Section 6.10) are applied when an echo-request or echo-response is
discarded.
The following notes are an integral part of memo. It is 5.2. Error Report Flag
important that implementors take heed of these points.
7.1. Discarding PDUs The error report flag may be set on the echo-request packet, the
echo-response packet, or both. If an echo-request is discarded, the
associated error-report (ER) packet will be sent to the echo-request
source address on the originating machine. If an echo-response is
discarded, the associated error-report packet will be sent to the
echo-response source address. In general, this will be the
destination address of the echo-request entity. It should be noted
that the echo-request entity and the originator of the echo-request
packet are not required to process error-report packets.
The rules used for discarding a DT PDU (8473, sec 6.9 - sec 5.3. Use of the Lifetime Field
6.10) are applied when an echo-request or echo-reply is dis-
carded.
7.2. Error Report Flag The lifetime field of the echo-request and echo-response packets
should be set to the value normally used for a data packet. Note:
although this memo does not prohibit the generation of a packet with
a smaller-than-normal lifetime field, this memo explicitly does not
attempt to define a mechanism for varying the lifetime field set in
the echo-response packet. This memo recommends the lifetime value
that would under normal circumstances by used when sending a data
packet.
The error report flag may be set on the echo-request PDU, 5.4. Echo-request function
the echo-reply PDU, or both. If an echo-request is dis-
carded, the associated ER PDU will be sent to the echo-
request source address on the originating machine. If an
echo-reply is discarded, the associated ER PDU will be sent
to the echo-reply source address. In general, this will be
An Echo Function for ISO 8473 This function is invoked by system management to obtain information
about the dynamic state of the Network layer with respect to (a) the
reachability of specific network-entities, and (b) the
characteristics of the path or paths that can be created between
network-entities through the operation of Network layer routing
functions. When invoked, the echo-request function causes an echo-
request (ERQ) packet to be created. The echo-request packet shall be
constructed and processed by ISO 8473 network-entities in end systems
and intermediate systems in exactly the same way as the data packet,
with the following caveats:
the address of the echo-request entity. It should be noted a) The information available to the packet composition function
that the echo-request entity and the originator of the (ISO 8473) consists of current state, local information, and
echo-request PDU are not required to process ER PDUs. information supplied by system management.
7.3. Use of the Lifetime Field b) The source and destination address fields of the echo-request
packet shall contain, respectively, a Network entity title (NET)
of the originating network-entity and a Network entity title of
the destination network-entity (which may be in either an end
system or an intermediate system). NOTE: A Network entity title
is syntactically indistinguishable from an NSAP address. The
additional information in an NSAP address, if any, beyond that
which is present in a Network entity title, is relevant only to
the operation of the packet decomposition function in a
destination end system, and therefore is not needed for the
processing of an echo-request packet (from which no N-UNITDATA
indication is ever produced). The fact that the source and
destination address fields of the echo-request packet contain NETs
rather than NSAP addresses therefore does not affect the
processing of an echo-request packet by any network-entity.
The lifetime field of the echo-request and echo-reply PDU c) When an echo-request packet has reached its destination, as
should be set to the value normally used for a DT PDU. determined by the Header processing (call HEADER FORMAT Analysis
Note: although this memo does not prohibit the generation of function in ISO 8473), the echo-response function shall handle
a PDU with a smaller-than-normal lifetime field, this memo this Network Protocol Data Units (NPDU) instead of the packet
explicitly does not attempt to define a mechanism for vary- decomposition function. In ISO 8473, the packet decomposition
ing the lifetime field set in the echo-reply PDU. This memo function is like a decomposing fish on the sea shore - it takes a
recommends that the normal DT lifetime value should be set packet down to its bare bones and processes it.
in the echo-request and echo-reply PDU.
7.4. Echo request function Also, it is up to each individual system whether or not handling
echo-request packets involves system management. One example of
involving system management is the reporting reception of the echo
packets as some systems do with the ping packet. Some systems
find this of value if they are being pinged to death.
"Extracted from ISO 8473/PDAMx Addition of an Echo function d) The maximum length of the echo-request packet is equal to the
to ISO 8473" maximum length of the echo-response packet minus the maximum
length of the echo-response packet header. This ensures that the
entire echo-request packet can be contained within the data field
of the echo-response packet (see ISO 8473).
Section 6.19 from ISO 8473 e) The data part of the echo-request packet may, as a local
matter, contain zero or more octets with any values that fit
within the echo-request packet. (see (d) above for maximum length
of the echo-request packet). If the first octet of data is binary
1000 0001, then an echo-response header is contained in the echo-
request packet. The existence of this header insures that a
router can formulate a standard echo-response packet.
This function is invoked by system management to obtain Normally, the "more segmentation" flag in the encapsulated echo-
information about the dynamic state of the Network layer response packet header shall be zero, and the segmentation portion of
with respect to (a) the reachability of specific network- the encapsulated packet shall not be included. The segmentation
entities, and (b) the characteristics of the path or paths length in the echo-response packet header shall be zero.
that can be created between network-entities through the
operation of Network layer routing functions. When invoked,
the Echo request function causes an Echo request (ERQ) PDU
to be created. The ERQ PDU shall be constructed and pro-
cessed by ISO 8473 network-entities in end systems and
intermediate systems in exactly the same way as the DT PDU,
with the following caveats:
a) Since the Echo request function is invoked by system If the "more segmentation" flag is set in the encapsulated echo-
management, rather than by a N-UNITDATA request, the infor- response packet header, then a segmentation length shall be filled in
mation available to the PDU composition function (ISO 8473 and the segmentation part of the echo-response packet header will be
clause 6.1) consists of current state, local information, present in the echo-response header. This same segmentation function
and information supplied by system management; the refer- shall be present in the echo-response sent by the router.
ences in ISO 8473 clause 6.1 to information obtained from
parameters of the N-UNITDATA request do not apply to the
composition of an ERQ PDU.
b) The source and destination address fields of the ERQ PDU NOTE: However, this formulated echo-response is not required between
shall contain, respectively, a Network entity title of the any two systems. With a common format for an echo-request packet
originating network-entity and a Network entity title of the used in an environment such as the Internet, the echo-response header
destination network-entity (which may be in either an end may not be needed, and may in fact be unnecessary overhead.
system or an intermediate system). NOTE: A Network entity
title is syntactically indistinguishable from an NSAP
address. The additional information in an NSAP address, if
any, beyond that which is present in a Network entity title,
An Echo Function for ISO 8473 5.5. Echo-response function
is relevant only to the operation of the PDU decomposition This function is performed by a network-entity when it has received
function in a destination end system, and therefore is not an echo-request packet that has reached its destination, as
needed for the processing of an ERQ PDU (from which no N- determined by the Header format analysis function (ISO 8473 clause
UNITDATA indication is ever produced). The fact that the 6.3) that is, an echo-request packet which contains, in its
source and destination address fields of the ERQ PDU contain destination address field, a Network entity title that identifies the
NETs rather than NSAP addresses therefore does not affect network-entity. When invoked, the echo-response function causes an
the processing of an ERQ PDU by any network-entity. echo-response (ERP) packet to be created. The echo-response packet
shall be constructed and processed by ISO 8473 network-entities in
end systems and intermediate systems in exactly the same way as the
data packet, with the following caveats:
c) When an ERQ PDU has reached its destination, as deter- a) The information available to the packet composition function
mined by the Header format analysis function (ISO 8473 consists of current state, local information, and information
clause 6.3), the Echo response function (ISO 8473 clause contained in the corresponding echo-request packet.
6.20), rather than the PDU decomposition function (ISO 8473
clause 6.2), shall be invoked. It is a local matter whether
or not this involves an interaction with system management.
NOTE: Since the Echo response function is a type 2 function
(see ISO 8473 clause 6.21), the destination network-entity
may or may not perform the Echo response function upon
receiving an ERQ PDU. System management must therefore con-
sider, when the Echo request function is invoked, that non-
receipt of a corresponding Echo response PDU may be due to
non-support of the Echo response function by the destination
network-entity.
d) The maximum length of the ERQ PDU is equal to the maximum b) The source address field of the echo-response packet shall
length of the Echo response PDU minus the maximum length of contain the value of the destination address field of the
the Echo response PDU header. This ensures that the entire corresponding echo-request packet. The destination address field
ERQ PDU can be contained within the data field of the Echo of the echo-response packet shall contain the value of the source
response PDU (see ISO 8473 clause 6.20). address field of the corresponding echo-request packet.
e) The data part of the ERQ PDU may, as a local matter, con- c) The echo-request packet, in its entirety, shall be placed into
tain zero or more octets with any values (subject to the the data part of the echo-response packet. The data part of the
overall maximum length of the ERQ PDU specified in (d) echo-response packet shall contain only the corresponding echo-
above). If the first octet of the data part contains the request packet.
binary value 1000 0001 (the NLPID for ISO 8473), then the
first n octets of the data part (where n is the value of the
second octet of the data part) shall contain an entire Echo
response PDU header, in which every field in the fixed part
and address part, except the segment length and checksum
fields, must contain a valid value. The "more segments"
flag shall have the value zero. If and only if the "segmen-
tation permitted" flag is set to 1, the segmentation part
shall be present. The options part, if present, may contain
any of the options described in ISO 8473 clause 7.5. NOTE:
This ERP PDU header, if present in the data part of an ERQ
PDU, may be, but is not required to be, used in whole or in
part by the destination network-entity to compose an ERP PDU
(see ISO 8473 clause 6.20 (d)).
NOTE: If this information is not present in the data part d) If the data part of the echo-request packet contains an echo-
of the ERQ PDU, it may not be possible for the Echo response response header, the packet composition function may, but is not
function of the destination network-entity to select an required to, use some or all of the information contained therein
appropriate value for the lifetime field of the ERP PDU. to select values for the fields of the echo-response packet
header. In this case, however, the value of the lifetime field
contained in the echo-response packet header in the echo-request
packet data part must be used as the value of the lifetime field
in the echo-response packet. The values of the segment length and
checksum fields shall be computed by the network-entity regardless
of the contents of those fields in the echo-response packet header
in the data part of the echo-request packet.
An Echo Function for ISO 8473 e) The options part of the echo-response packet may contain any
(or none) of the options described in ISO 8473 (but see Section
5.7 of this RFC). The values for these options, if present, are
determined by the network-entity as a local matter. They may be,
but are not required to be, either identical to or derived from
the corresponding options in the echo-request packet and/or the
echo-response packet header contained in the data part of the
echo-request packet (if present). The source routing option in
the echo-response packet shall not be identical to (copied from)
the source routing option in the echo-request packet header. If
the recording of route option in the echo-response packet is
identical to (copied from) the recording of route option in the
echo-request packet header, the second octet of the parameter
value field shall be set to the value 3.
7.5. Echo response function f) It is a local matter whether or not the destination network-
entity performs the lifetime control function on an echo-request
packet before performing the echo-response function. The
destination network-entity shall make the same decision in this
regard that it would make, as a local matter, for a data packet in
accordance with ISO 8473.
"Extracted from ISO 8473/PDAMx Addition of an Echo function 5.6. Use of the Priority Option
to ISO 8473"
Section 6.20 from ISO 8473 The 8473 priority function indicates the relative priority of
packet. 0 is normal and 14 is the highest. Packets with higher
values will be transmitted before lower values. The specific
action upon receiving a 8473 packet with the priority field set is
a "LOCAL MATTER". These means, any two systems could do it
differently.
This function is performed by a network-entity when it has Hopefully, in the future, Internet routers will handle this as a
received an ERQ PDU that has reached its destination, as priority queueing function. Some implementors consider the
determined by the Header format analysis function (ISO 8473 priority queueing function to be a cap. For example, if a router
clause 6.3) Q that is, an ERQ PDU which contains, in its is congested, all those packets with priorities higher than 20,
destination address field, a Network entity title that iden- will be allowed through, and those with priority less than 20 will
tifies the network-entity. When invoked, the Echo response be dropped.
function causes an Echo response (ERP) PDU to be created.
The ERQ PDU shall be constructed and processed by ISO 8473
network-entities in end systems and intermediate systems in
exactly the same way as the DT PDU, with the following
caveats:
a) Since the Echo response function is not invoked by a N- In short, the basic function of priority has wide latitude in the
UNITDATA request, the information available to the PDU com- ISO specification. This wide latitude of implementation needs to
position function (ISO 8473 clause 6.1) consists of current be narrowed for implementations within a common network
state, local information, and information contained in the environment such as the Internet. The 8473 priority function is
corresponding ERQ PDU; the references in ISO 8473 clause rarely implemented in today's Internet. The transmission of an
6.1 to information obtained from parameters of the N- echo-request packet with a priority set may provided unexcepted
UNITDATA request do not apply to the composition of an ERP results until a more wide spread deployment of the priority
PDU. feature in 8473 capable routers and end systems.
b) The source address field of the ERP PDU shall contain the However, if the priority function must be used it is the safest
value of the destination address field of the corresponding value may be the value 0 - which indicates Normal priority. It
ERQ PDU. The destination address field of the ERP PDU shall most likely this value will follow the 8473 pathways.
contain the value of the source address field of the
corresponding ERQ PDU. NOTE: The observation contained in
the NOTE following ISO 8473 clause 6.19 (b) applies also to
the ERP PDU.
c) The ERQ PDU, in its entirety, shall be placed into the In the future, as the implementation of the priority function
data part of the ERP PDU. The data part of the ERP PDU further Internet documents will need to deal with its expected
shall contain only the corresponding ERQ PDU. use.
d) If the data part of the ERQ PDU contains an ERP PDU 5.7. Use of the Source Route Option
header (see ISO 8473 clause 6.19 (e)), the PDU composition
function may, but is not required to, use some or all of the
information contained therein to select values for the
fields of the ERP PDU header. In this case, however, the
value of the lifetime field contained in the ERP PDU header
in the ERQ PDU data part must be used as the value of the
lifetime field in the ERP PDU. The values of the segment
length and checksum fields shall be computed by the
network-entity regardless of the contents of those fields in
the ERP PDU header in the data part of the ERQ PDU.
e) The options part of the ERP PDU may contain any (or none) Use of the source route option in ISO 8473 may cause packets to
loop until their lifetime expires. For this reason, this memo
recommends against the use of the source route option in either an
echo-request or echo-response packets. If the source route option
is used to specify the route that the echo-request packet takes
toward its destination, this memo does not recommend the use of an
automatically generated source route on the echo-response packet.
An Echo Function for ISO 8473 5.8. Transmission of Multiple Echo-Requests
of the options described in ISO 8473 clause 7.5. The values The echo function may be utilized by more than one process on any
for these options, if present, are determined by the individual machine. The mechanism by which multiple echo-requests
network-entity as a local matter. They may be, but are not and echo-responses are correlated between multiple processes on a
required to be, either identical to or derived from the single machine is a local matter and not defined by this memo.
corresponding options in the ERQ PDU and/or the ERP PDU
header contained in the data part of the ERQ PDU (if
present). The source routing option in the ERP PDU shall
not be identical to (copied from) the source routing option
in the ERQ PDU header. If the recording of route option in
the ERP PDU is identical to (copied from) the recording of
route option in the ERQ PDU header, the second octet of the
parameter value field shall be set to the value 3.
f) It is a local matter whether or not the destination 6. Security Considerations
network-entity performs the lifetime control function on an
ERQ PDU before performing the Echo response function. The
destination network-entity shall make the same decision in
this regard that it would make, as a local matter, for a DT
PDU in accordance with ISO 8473 clause 6.4.
7.6. Use of the Priority Option Security issues are not discussed in this memo.
If the priority option is included, it will normally be set 7. Authors' Addresses
to value 0 (default priority). This memo allows for prior-
ity values higher than 0 to be set in the echo-request or
echo-reply header, but cautions against this practice.
7.7. Use of the Source Route Option Susan K. Hares
MERIT/NSFNET
Internet Engineering
1075 Beal Avenue
Ann Arbor, MI 48109-2112
Use of the source route option in ISO 8473 may cause packets Phone: (313) 936-3000
to loop until their lifetime expires. For this reason, this EMail: skh@merit.edu
memo recommends against the use of the source route option
in either an echo-request or echo-reply PDU. If the source
route option is used to specify the route that the echo-
request PDU takes toward its destination, this memo does not
recommend the use of an automatically generated source route
on the echo-reply PDU.
7.8. Transmission of Multiple Echo Requests Cathy J. Wittbrodt
Stanford University/BARRNet
Networking Systems
Pine Hall 115
Stanford, CA 94305
The echo function may be utilized by more than one process Phone: (415) 725-5481
on any individual machine. The mechanism by which multiple EMail: cjw@magnolia.Stanford.EDU
echo-requests and echo-replies are correlated between multi-
ple processes on a single machine is a local matter and not
defined by this memo.
An Echo Function for ISO 8473 8. References
8. Security Considerations [1] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
Security issues are not addressed in this memo. [2] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
Working Group, January 1990.
[3] ISO 8473-1993 Protocol for providing the connectionless-mode
network service, edition 2 (IS under preparation).
 End of changes. 81 change blocks. 
335 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/