RFC 1139

RFC 1139: An Echo Function for ISO 8473 💖

Okay bestie, this is RFC 1139 🎀, and it's called An Echo Function for ISO 8473. It was written by R. Hagens for the IETF-OSI Working Group (the header also says Network Working Group), and it's dated January 1990. Its category is a Proposed Elective Standard for the Internet ✨. The header doesn't list anything it obsoletes or updates, but the Abstract says it'll be obsoleted once an ISO standard shows up with similar functionality 🦋.

Status of This Memo ✨

This memo defines an echo function for the connection-less network layer protocol. It is not intended to compete with an ISO standard. This is a Proposed Elective Standard for the Internet, and 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 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. 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 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 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 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 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 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 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 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 🎀.

5. Implementation Notes ✨

okay bestie, this part is where the spec gets real about the little things implementors need to take heed of 🫶 these bits are literally part of the memo, not optional extras, so read them like the main plot 💅

5.1. Discarding PDUs 🗑️

okay so when an echo-request or echo-reply gets thrown out, the same rules used for discarding a DT PDU apply 💖 those rules live in 8473, sec 6.9 - sec 6.10 🌸 same vibes, different packet, no cap

5.2. Error Report Flag 🚩

the error report flag can be set on the echo-request PDU, the echo-reply PDU, or both 🎀 here's the tea: if an echo-request gets discarded, the associated ER PDU is sent to the echo-request source address on the originating machine 💌 and if an echo-reply gets discarded, the associated ER PDU goes to the echo-reply source address 🦋

in general, that's gonna be the address of the echo-request entity 🧚 ngl the spec makes a point here: the echo-request entity and the originator of the echo-request PDU are not required to process ER PDUs 🙈 so don't assume they will, periodt 💅

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 🌈 okay but here's the lowkey important part: this memo doesn't prohibit making a PDU with a smaller-than-normal lifetime field 👀 HOWEVER, it explicitly does not try to define a mechanism for varying the lifetime field in the echo-reply PDU 🫣

the memo recommends that the normal DT lifetime value be set in both the echo-request and echo-reply PDU 💜 that's the move, bestie ✨

5.4. Transfer of Options from the echo-request PDU to the echo-reply PDU 🎁

okay this one is giving main character energy 👑 with two exceptions, all options in the echo-request header get copied straight into the echo-reply header ✨

the two exceptions are the record route option and the source route option 🧭 for the record route option, it does get copied into the echo-reply PDU, BUT the recorded routes get "erased" by resetting the second octet of the option to 3 🧹 this lets the entire record route option space be used by the echo-reply PDU 💖

and don't panic, the record route from the echo-request isn't lost 🫶 the echo-request PDU is wholly contained in the data part of the echo-reply PDU, so it's all still there 🌸

the second exception is the source route option 🙅‍♀️ a source route option on the echo-request PDU is not copied into the echo-reply PDU at all 💅

5.5. Use of the Priority Option 🚀

if the priority option is included, it'll normally be set to value 0 (default priority) 🍓 the memo does allow priority values higher than 0 to be set in the echo-request or echo-reply header, but it cautions against this practice 😬 so maybe don't go wild with it, iykyk 💀

5.6. Use of the Source Route Option 🛣️

okay bestie, listen up 🚨 use of the source route option in ISO 8473 may cause packets to loop until their lifetime expires 😭 for this reason, the memo recommends against using the source route option in either an echo-request or echo-reply PDU 🙅‍♀️

if the source route option is used to specify the route the echo-request PDU takes toward its destination, the memo does not recommend using an automatically generated source route on the echo-reply PDU 🦋 it's not a whole vibe, just don't 💅

5.7. Transmission of Multiple Echo Requests 📬

the echo function can be used by more than one process on any individual machine 🧚‍♀️ and here's the thing: how multiple echo-requests and echo-replies get correlated between those processes on a single machine is a local matter 🏠 this memo doesn't define it, so that's a decision for each machine 🌈

---

Security Considerations 🔐

okay real talk, this section is short but SERIOUS 💀 security issues are not addressed in this memo 😭 so if you're looking for a security guide here, sorry bestie, it's not in this one 🙈 go check elsewhere and stay safe out there 🫶

---

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 💌