diff options
Diffstat (limited to 'doc/rfc/rfc1575.txt')
| -rw-r--r-- | doc/rfc/rfc1575.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1575.txt b/doc/rfc/rfc1575.txt new file mode 100644 index 0000000..2fd222b --- /dev/null +++ b/doc/rfc/rfc1575.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Hares +Request for Comments: 1575 Merit/NSFNET +Obsoletes: 1139 C. Wittbrodt +Category: Standards Track Stanford University/BARRNet + February 1994 + + + An Echo Function for CLNP (ISO 8473) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an echo function for the connection-less network + layer protocol. The mechanism that is mandated here is in the final + 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. + +Table of Contents + + 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 + + + + + +Hares & Wittbrodt [Page 1] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + +1. Conventions + + The following language conventions are used in the items of + specification in this document: + + o MUST, SHALL, or MANDATORY -- the item is an absolute + requirement of the specification. + + o SHOULD or RECOMMENDED -- the item should generally be followed + for all but exceptional circumstances. + + o MAY or OPTIONAL -- the item is truly optional and may be + followed or ignored according to the needs of the implementor. + +2. Introduction + + The OSI Connection-less network layer protocol (ISO 8473) defines a + means for transmitting and relaying data and error protocol data + units, (PDUs) or preferably, packets through an OSI internet. + Unfortunately, the world that these packets travel through is + imperfect. Gateways and links may fail. This memo defines an echo + function to be used in the debugging and testing of the OSI network + layer. Hosts and routers which support the OSI network layer MUST be + able to originate an echo packet as well as respond when an echo is + received. + + Network management protocols can be used to determine the state of a + gateway or link. However, since these protocols themselves utilize a + protocol that may experience packet loss, it cannot be guaranteed + that the network management applications can be utilized. A simple + 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. + + The code-path consideration requires that the echo path through a + system be identical (or very close) to the path used by normal data. + An echo path must succeed and fail in unison with the normal data + path or else it will not provide a useful diagnostic tool. + + 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). + + + +Hares & Wittbrodt [Page 2] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + +3. 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. + + For the purposes of this memo, the term "ping" shall be used to mean + the act of transmitting an echo-request packet to a remote system + (with the expectation that an echo-response packet will be sent back + to the transmitter). + +3.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. + + The echo-request is switched through the network toward its + destination. (An echo packet must follow the same path as CLNP data + packet with the same options in the CLNP header.) Upon reaching the + destination system, the packet is processed according to normal + processing rules. At the end of the input processing, the echo- + request packet is delivered to the echo-request entity. + + The echo-request entity will build and dispatch the echo-response + packet. This is a new packet. Except as noted below, this second + packet is built using the normal construction procedures. The + destination address of the echo-response packet is taken from the + 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). + +3.2. The Echo-Response + + 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 + + + +Hares & Wittbrodt [Page 3] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + + echo-request). The rules of segmentation defined for a data packet + also apply to the echo-response packet. + + The echo-response packet is relayed through the network toward its + destination. (A echo response packet must follow the same path as a + CLNP data packet with the same options in the CLNP header.) Upon + reaching its destination, it is processed by the packet input + function and delivered to the entity that created the echo-request. + +4. The Implementation Mechanism + + The implementation mechanism defines two new 8473 packet types: ERQ + (echo-request) and ERP (echo-response). With the exception of a new + type code, these packets will be identical to the date packet in + every respect. + +4.1. The Echo-Request + + The type code for the echo-request packet is decimal 30. + +4.2. The Echo-Response + + The type code for the echo-response packet is decimal 31. + +5. Implementation Notes + + The following notes are an integral part of memo. It is important + that implementors take heed of these points. + +5.1. Discarding Packets + + 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. + +5.2. Error Report Flag + + 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. + + + + + +Hares & Wittbrodt [Page 4] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + +5.3. Use of the Lifetime Field + + 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. + +5.4. Echo-request function + + 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: + + a) The information available to the packet composition function + (ISO 8473) consists of current state, local information, and + information supplied by system management. + + 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. + + c) When an echo-request packet has reached its destination, as + determined by the Header processing (call HEADER FORMAT Analysis + function in ISO 8473), the echo-response function shall handle + this Network Protocol Data Units (NPDU) instead of the packet + + + +Hares & Wittbrodt [Page 5] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + + decomposition function. In ISO 8473, the packet decomposition + function is like a decomposing fish on the sea shore - it takes a + packet down to its bare bones and processes it. + + 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. + + d) The maximum length of the echo-request packet is equal to the + 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). + + 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. + + Normally, the "more segmentation" flag in the encapsulated echo- + response packet header shall be zero, and the segmentation portion of + the encapsulated packet shall not be included. The segmentation + length in the echo-response packet header shall be zero. + + If the "more segmentation" flag is set in the encapsulated echo- + response packet header, then a segmentation length shall be filled in + and the segmentation part of the echo-response packet header will be + present in the echo-response header. This same segmentation function + shall be present in the echo-response sent by the router. + + NOTE: However, this formulated echo-response is not required between + any two systems. With a common format for an echo-request packet + used in an environment such as the Internet, the echo-response header + may not be needed, and may in fact be unnecessary overhead. + +5.5. Echo-response function + + This function is performed by a network-entity when it has received + an echo-request packet that has reached its destination, as + determined by the Header format analysis function (ISO 8473 clause + 6.3) that is, an echo-request packet which contains, in its + destination address field, a Network entity title that identifies the + network-entity. When invoked, the echo-response function causes an + + + +Hares & Wittbrodt [Page 6] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + + 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: + + a) The information available to the packet composition function + consists of current state, local information, and information + contained in the corresponding echo-request packet. + + b) The source address field of the echo-response packet shall + contain the value of the destination address field of the + corresponding echo-request packet. The destination address field + of the echo-response packet shall contain the value of the source + address field of the corresponding echo-request packet. + + c) The echo-request packet, in its entirety, shall be placed into + the data part of the echo-response packet. The data part of the + echo-response packet shall contain only the corresponding echo- + request packet. + + d) If the data part of the echo-request packet contains an echo- + response header, the packet 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 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. + + 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. + + + + + +Hares & Wittbrodt [Page 7] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + + 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. + +5.6. Use of the Priority Option + + 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. + + Hopefully, in the future, Internet routers will handle this as a + priority queueing function. Some implementors consider the + priority queueing function to be a cap. For example, if a router + is congested, all those packets with priorities higher than 20, + will be allowed through, and those with priority less than 20 will + be dropped. + + In short, the basic function of priority has wide latitude in the + ISO specification. This wide latitude of implementation needs to + be narrowed for implementations within a common network + environment such as the Internet. The 8473 priority function is + rarely implemented in today's Internet. The transmission of an + echo-request packet with a priority set may provided unexcepted + results until a more wide spread deployment of the priority + feature in 8473 capable routers and end systems. + + However, if the priority function must be used it is the safest + value may be the value 0 - which indicates Normal priority. It + most likely this value will follow the 8473 pathways. + + In the future, as the implementation of the priority function + further Internet documents will need to deal with its expected + use. + +5.7. Use of the Source Route Option + + 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 + + + +Hares & Wittbrodt [Page 8] + +RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 + + + automatically generated source route on the echo-response packet. + +5.8. Transmission of Multiple Echo-Requests + + The echo function may be utilized by more than one process on any + individual machine. The mechanism by which multiple echo-requests + and echo-responses are correlated between multiple processes on a + single machine is a local matter and not defined by this memo. + +6. Security Considerations + + Security issues are not discussed in this memo. + +7. Authors' Addresses + + Susan K. Hares + MERIT/NSFNET + Internet Engineering + 1075 Beal Avenue + Ann Arbor, MI 48109-2112 + + Phone: (313) 936-3000 + EMail: skh@merit.edu + + + Cathy J. Wittbrodt + Stanford University/BARRNet + Networking Systems + Pine Hall 115 + Stanford, CA 94305 + + Phone: (415) 725-5481 + EMail: cjw@magnolia.Stanford.EDU + +8. References + + [1] ISO/IEC. Protocol for Providing the Connectionless-mode Network + Service. International Standard 8473, ISO/IEC JTC 1, + Switzerland, 1986. + + [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). + + + + + + +Hares & Wittbrodt [Page 9] +
\ No newline at end of file |