diff options
Diffstat (limited to 'doc/rfc/rfc1139.txt')
| -rw-r--r-- | doc/rfc/rfc1139.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1139.txt b/doc/rfc/rfc1139.txt new file mode 100644 index 0000000..26621b9 --- /dev/null +++ b/doc/rfc/rfc1139.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group IETF-OSI Working Group +Request for Comments: 1139 R. Hagens + January 1990 + + + An Echo Function for ISO 8473 + +Status of this Memo + + This memo defines an echo function for the connection-less network + layer protocol. This memo is not intended to compete with an ISO + standard. This is a Proposed Elective Standard for the Internet. + Distribution of this memo is unlimited. + +Abstract + + This memo defines an echo function for the connection-less network + layer protocol. Two mechanisms are introduced that may be used to + implement the echo function. The first mechanism is recommended as + an interim solution for the Internet community. The second mechanism + will be progressed to the ANSI X3S3.3 working group for consideration + as a work item. + + When an ISO standard is adopted that provides functionality similar + to that described by this memo, then this memo will become obsolete + and superceded by the ISO standard. + +1. Introduction + + The OSI Connection-less network layer protocol (ISO 8473) 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. Gateways 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 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. + + There are three important issues to consider when defining an echo + extension to ISO 8473: complexity, code-path divergence, and backward + + + +IETF-OSI Working Group [Page 1] + +RFC 1139 An Echo Function for ISO 8473 January 1990 + + + compatibility. The complexity of the echo facility must be kept low. + If it is not, then there is a good chance that the facility will not + be universally provided. The code-path consideration requires that + the echo path through a system is 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. + + Backward compatibility is an important consideration whenever a + change is made to a protocol. For this reason, this memo defines two + implementation mechanisms: the short term approach and the long term + approach. The short term approach will produce echo packets that are + indistinguishable from normal data ISO 8473 PDUs. These echo packets + may be switched through ISO 8473 routers that do not implement the + echo function. The short term approach will be adopted as an + Elective Internet Standard because it is backward compatible with ISO + 8473. However, due to its nature, the short term approach will never + be incorporated into future versions of ISO 8473. + + The long term approach will produce echo packets that are not + compatible with the existing standard. However, the long term + approach may be acceptable by ISO as an addendum to ISO 8473. In + this event, backward compatibility will no longer be an issue. At + that juncture, the short term approach defined by this memo will be + obsolete and superseded by the ISO addendum. + +2. The Generic Echo Function + + The following section will describe 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 PDU, + perform some processing, and generate an echo-reply PDU. Depending + on the echo implementation, the echo-request entity may be thought of + as an entity that exists above the network layer, or as an entity + that co-exists with the network layer. Subsequent sections will + detail the short and long term implementation mechanisms. + + For the purposes of this memo, the term "ping" shall be used 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). + + 2.1 The Echo Request + + When a system decides to ping a remote system, an echo-request is + built. All fields of the PDU 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 + + + +IETF-OSI Working Group [Page 2] + +RFC 1139 An Echo Function for ISO 8473 January 1990 + + + NSAP address. The rules of segmentation defined for a DT PDU also + apply to the echo-request PDU. + + The echo-request is switched through the network toward its + destination. Upon reaching the destination system, the PDU is + processed according to normal processing rules. At the end of the + input processing, the echo-request PDU is delivered to the echo- + request entity. + + The echo-request entity will build and dispatch the echo-reply + PDU. This is a new PDU. Except as noted below, this second PDU + is built using the normal construction procedures. 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 information). + + 2.2 The Echo Reply + + The entire echo-request PDU is included in the data portion of the + echo-reply PDU. This includes the echo-request PDU header as well + as the any data that accompanies the echo-request PDU. The entire + echo-request PDU is included in the echo-reply so that fields such + as the echo-request lifetime may be examined when the reply is + received. After the echo-reply PDU is built, it is transmitted + toward the new destination (the original source of the echo- + request). The 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 + destination. Upon reaching its destination, it is processed by + the PDU input function and delivered to the entity that created + the echo-request. + +3. The Short Term Implementation Mechanism + + The short term implementation mechanism will use an ISO 8473 normal + data PDU as the echo-request and echo-reply PDU. A special NSAP + selector value will be used to identify the echo-request and insure + that it reaches the echo-request entity. This selector value is + known as the echo-request selector. In addition, an echo-reply + selector is defined so that the echo-reply PDU may be identified at + the destination system. It is important to note that (except for the + NSAP selector) the echo-request PDU and the echo-reply PDU are + indistinguishable from a DT PDU. + + This approach has the advantage that it is simple and does not allow + any code-path divergence. In addition, this approach requires that + + + +IETF-OSI Working Group [Page 3] + +RFC 1139 An Echo Function for ISO 8473 January 1990 + + + only the systems which wish to generate an echo-reply PDU must + change. Systems that do not adhere to this memo will not generate an + echo-reply PDU, but will still switch other echo-request and echo- + reply PDUs. + + 3.1 The Echo Request + + An echo-request is built using the normal DT PDU construction + procedures. All fields of the PDU header are assigned normal + values (see implementation notes). The address of the system to + be pinged is inserted as the destination NSAP address. The + selector field of the destination NSAP address must contain the + echo-request selector. The selector field of the source NSAP + address must contain the echo-reply selector. + + 3.2 The Echo Reply + + Except as noted below (see implementation notes), an echo-reply is + built using the normal DT PDU construction procedures. The + destination NSAP address is taken from the source address of the + echo-request PDU. + + 3.3 Use of NSAP Selectors + + The choice of echo-request and echo-reply NSAP selectors is a + local matter. However, to insure interoperability, and as an + interim measure until use of the directory service becomes + widespread, this memo will recommend the following default values + (specified in decimal): + + Echo Request Selector - 30 + Echo Reply Selector - 31 + +4. The Long Term Implementation Mechanism + + The long term implementation mechanism will define two new 8473 PDU + 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. + + 4.1 The Echo Request + + The type code for the ERQ PDU is decimal 30. + + 4.2 The Echo Reply + + The type code for the ERP PDU is decimal 31. + + + + +IETF-OSI Working Group [Page 4] + +RFC 1139 An Echo Function for ISO 8473 January 1990 + + +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 PDUs + + The rules used for discarding a DT PDU (8473, sec 6.9 - sec 6.10) + are applied when an echo-request or echo-reply is discarded. + + 5.2 Error Report Flag + + The error report flag may be set on the echo-request PDU, the + echo-reply PDU, or both. If an echo-request is discarded, 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 the address of the echo-request entity. + It should be noted that the echo-request entity and the originator + of the echo-request PDU are not required to process ER PDUs. + + 5.3 Use of the Lifetime Field + + The lifetime field of the echo-request and echo-reply PDU should + be set to the value normally used for a DT PDU. Note: although + this memo does not prohibit the generation of a PDU 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-reply PDU. This memo recommends that the normal DT + lifetime value should be set in the echo-request and echo-reply + PDU. + + 5.4 Transfer of Options from the echo-request + PDU to the echo-reply PDU + + With two exceptions, all options present in the echo-request + header are copied directly into the echo-reply header. The two + exceptions are the record route option and the source route + option. A record route option present in an echo-request PDU is + copied into the echo-reply PDU, but the routes recorded in the + option are "erased" by resetting the second octet of the option to + 3. This allows the entire record route option space to be used by + the echo-reply PDU. Note: the record route present on the echo- + request is not lost because the echo-request PDU is wholly + contained in the data part of the echo-reply PDU. + + The second exception concerns the source route option. A source + route option present on the echo-request PDU is not copied into + + + +IETF-OSI Working Group [Page 5] + +RFC 1139 An Echo Function for ISO 8473 January 1990 + + + the echo-reply PDU. + + 5.5 Use of the Priority Option + + If the priority option is included, it will normally be set to + value 0 (default priority). This memo allows for priority values + higher than 0 to be set in the echo-request or echo-reply header, + but cautions against this practice. + + 5.6 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-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. + + 5.7 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-replies are correlated between multiple processes on a + single machine is a local matter and not defined by this memo. + +Security Considerations + + Security issues are not addressed in this memo. + +Author's Address + + Robert A. Hagens + Computer Science Department + 1210 West Dayton Street + Madison, WI 53706 + + Phone: (608) 262-1204 + + EMail: hagens@CS.WISC.EDU + + + + + + + + + + + +IETF-OSI Working Group [Page 6] +
\ No newline at end of file |