RFC 1575

RFC 1575: An Echo Function for CLNP (ISO 8473) 🎀

Okay bestie, let's set the scene 💖 This is RFC 1575, filed under the Network Working Group and dated February 1994. The authors are S. Hares (Merit/NSFNET) and C. Wittbrodt (Stanford University/BARRNet) 🌸 It's a Standards Track doc, which is giving official, and it obsoletes RFC 1139, so RFC 1139 is retired and this is the new version 💅

---

Status of This Memo 📜

Lowkey the official bit: this document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🧚 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1), that's the source of truth 💅 Distribution of this memo is unlimited 🌈

Abstract 💜

Okay so this memo defines an echo function for the connection-less network layer protocol 🦋 The mechanism it mandates is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473", which becomes an integral part of Version 2 of ISO 8473. Main character energy 👑

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

1. Conventions 🎀

Here's the language used in the spec items, no cap 🫶

• MUST, SHALL, or MANDATORY: the item is an absolute requirement of the specification.
• SHOULD or RECOMMENDED: the item should generally be followed for all but exceptional circumstances.
• MAY or OPTIONAL: the item is truly optional and may be followed or ignored according to the needs of the implementor.

2. Introduction 🌸

Okay so the OSI Connection-less network layer protocol (ISO 8473) defines a way to transmit and relay data and error protocol data units (PDUs), or, preferably, packets, through an OSI internet 🌐 The problem? The world these packets travel through is imperfect. Gateways and links can fail 😭 This memo defines an echo function to be used for debugging and testing the OSI network layer. Hosts and routers that support the OSI network layer MUST be able to originate an echo packet, and also respond when an echo is received ✨

Network management protocols can be used to figure out the state of a gateway or link 🔍 But periodt, those protocols run on something that may experience packet loss, so it can't be guaranteed that the network management applications can be used. We need a simple mechanism in the network layer so systems can be probed to see 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 network management already offers 💅

The code-path consideration is a big deal. The echo path through a system has to be identical (or very close) to the path normal data takes 🌊 An echo path must succeed and fail in unison with the normal data path, or else it's not going to be a useful diagnostic tool 💀

Previous drafts describing an echo function for CLNP offered two implementation alternatives (see RFC 1139). Backward compatibility matters whenever a protocol changes, but at this point it's more important that the echo mechanisms used on the Internet interoperate 🫶 So this memo defines one implementation mechanism, the one that's consistent with one of the previous drafts 🦋

3. The Generic Echo Function 🦋

So this section describes the echo function in a generic way 🌈 This memo defines an echo-request entity. Its job is to accept an incoming echo-request packet, do some processing, and generate an echo-response packet. Think of the echo implementation as an entity that coexists with the network layer, like a little sidekick 🧚 Later sections 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 gets built 💅 All fields of the packet header are assigned normal values (see the implementation specific sections for more info). The address of the system to be pinged goes in as the destination NSAP address. The segmentation rules defined for a data (DT) packet also apply to the echo-request packet 🍓

The echo-request gets switched through the network toward its destination. (An echo packet must follow the same path as a CLNP data packet with the same options in the CLNP header, that's the rule 🌊) Once it reaches the destination system, the packet is processed according to normal processing rules. At the end of 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 brand 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 the 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 🫧 That means the echo-request packet header AND any data that came with it. Why? So fields like the echo-request lifetime can be examined when the response is received, iykyk 🔍 After the echo-response packet is built, it's transmitted toward the new destination, which is the original source of the echo-request. The segmentation rules for a data packet also apply to the echo-response packet ✨

The echo-response packet is relayed through the network toward its destination. (An echo response packet must follow the same path as a CLNP data packet with the same options in the CLNP header.) When it reaches its destination, it's 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 🧚 They're ERQ (echo-request) and ERP (echo-response). Apart from a new type code, these packets are identical to the data 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 🔥

These notes are an integral part of this memo, so implementors really need to take heed 😤 Like, pay attention, it's important 💀

5.1. Discarding Packets 🗑️

The rules for discarding a data packet (ISO 8473, Section 6.9 - Section 6.10) are applied when an echo-request or echo-response gets 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 is sent to the echo-request source address on the originating machine. If an echo-response is discarded, the associated error-report packet is sent to the echo-response source address. In general, that'll 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 🙈

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. Heads up: this memo does not prohibit generating a packet with a smaller-than-normal lifetime field, but it 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 normally be used when sending a data packet 💜

Part 1 wrap 🎀 Part 2 picks up with Section 5.4 and everything after it, bestie 🫶

5.4. Echo-request function 🎀

Okay bestie, this function is what system management calls to find out how the Network layer is doing. It checks (a) whether specific network-entities can be reached and (b) what the paths between network-entities look like once routing does its thing. When it's invoked, it makes an echo-request (ERQ) packet. The echo-request packet SHALL be built and handled by ISO 8473 network-entities in end systems and intermediate systems in exactly the same way as a data packet, with these caveats 💅:

• a) The info the packet composition function (ISO 8473) has to work with is current state, local information, and whatever system management supplies. 🧠
• 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. Any extra info in an NSAP address, beyond what's in a NET, only matters to the packet decomposition function in a destination end system. It's not needed to process an echo-request packet, since no N-UNITDATA indication is ever produced from one. So the fact that these fields hold NETs instead of NSAP addresses doesn't change how any network-entity processes the packet. It's giving "no drama" 🌸
• c) Once an echo-request packet reaches its destination, as decided by the Header processing (call HEADER FORMAT Analysis function in ISO 8473), the echo-response function SHALL handle this Network Protocol Data Unit (NPDU) instead of the packet 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's up to each individual system whether handling echo-request packets involves system management. One example is reporting that echo packets have been received, which some systems do with the ping packet. Some systems find this valuable if they're getting pinged to death 🙈

• d) The maximum length of the echo-request packet equals the maximum length of the echo-response packet minus the maximum length of the echo-response packet header. This makes sure the entire echo-request packet fits inside 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 the maximum length of the echo-request packet). If the first octet of data is 1000 0001, then an echo-response header is contained in the echo-request packet. That header means 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. Extra overhead is a no from me 🙅‍♀️

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). In other words, it's an echo-request packet whose destination address field holds a Network entity title that identifies that network-entity 🎯 When invoked, the echo-response function creates an echo-response (ERP) packet. 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 these caveats:

• a) The info available to the packet composition function is 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. Swapping the addresses, iykyk 💕
• 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. Nothing else gets to crash the party 🎉
• 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 info in that header to pick values for the fields of the echo-response packet header. In this case, however, the value of the lifetime field in the echo-response packet header inside the echo-request packet's 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, no matter what those fields say in the echo-response packet header in the echo-request packet's data part 🧮
• 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, identical to or derived from the corresponding options in the echo-request packet and/or the echo-response packet header in the echo-request packet's data part (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. 🧭
• f) It's a local matter whether the destination network-entity performs the lifetime control function on an echo-request packet before doing the echo-response function. The destination network-entity SHALL make the same decision about this that it would make, as a local matter, for a data packet under ISO 8473 🕰️

5.6. Use of the Priority Option 👑

The 8473 priority function indicates the relative priority of a packet. 0 is normal and 14 is the highest. Packets with higher values will be transmitted before lower ones. What a system does upon receiving an 8473 packet with the priority field set is a "LOCAL MATTER", meaning any two systems could handle it differently 🤷‍♀️

Hopefully, in the future, Internet routers will handle this as a priority queueing function. Some implementors treat the priority queueing function as a cap. For example, if a router is congested, every packet with a priority higher than 20 gets through, and every packet with a priority less than 20 gets dropped 🚦

In short, the basic function of priority has wide latitude in the ISO specification. That wide latitude 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. Sending an echo-request packet with a priority set may give unexpected results until the priority feature is more widely deployed in 8473-capable routers and end systems 😬

However, if the priority function MUST be used, the safest value MAY be 0, which indicates Normal priority. It will most likely follow the 8473 pathways.

In the future, as the priority function is implemented 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 using the source route option in either echo-request or echo-response packets. If the source route option is used to specify the route the echo-request packet takes toward its destination, this memo does not recommend using an automatically generated source route on the echo-response packet. Loops are a hard pass 🔁

5.8. Transmission of Multiple Echo-Requests 📬

The echo function may be used by more than one process on any individual machine. How multiple echo-requests and echo-responses get correlated between multiple processes on a single machine is a local matter, and this memo doesn't define it 🫶

6. Security Considerations 🔐

Security issues are not discussed in this memo. Yes, this is the security section 😭 Plan your own protections, bestie!

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).

That's the whole thing, bestie! 🌈✨💖