An Echo Function for CLNP (ISO 8473)

A single implementation mechanism is mandated (type codes 30 and 31) rather than the two alternatives in RFC 1139, because interoperability among Internet implementations is more important at this stage than backward compatibility with prior drafts.

An optional embedded echo-response header in the echo-request data field (signaled by first octet 0x81) allows a router to formulate a standard echo-response; however, this is noted as potentially unnecessary overhead in a common-format environment like the Internet and is not required between any two systems.

The echo mechanism is intended as an addition to network management facilities rather than a replacement. It addresses the limitation that network management protocols themselves use the same potentially-lossy network layer, so a simpler in-band probe is needed to verify that the lowest levels of networking software operate correctly.

The echo path through a system must 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, otherwise it will not provide a useful diagnostic tool.

The ISO 8473 priority option has wide latitude in the specification and is rarely implemented in today's Internet. Using a priority value other than 0 (Normal) on echo-request packets may produce unexpected results; value 0 is recommended as safest until priority is more widely deployed.

RFC 1575 obsoletes RFC 1139, which offered two implementation alternatives for the CLNP echo function. This memo mandates a single mechanism (consistent with one of the previous drafts) to ensure that echo implementations on the Internet interoperate, prioritizing interoperability over backward compatibility.

The mechanism for correlating multiple echo-requests and echo-responses across multiple processes on a single machine is a local matter and is not defined by this memo.

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.

If the recording of route option in the echo-response packet is copied from the echo-request packet header, the second octet of the parameter value field SHALL be set to the value 3.

The echo-request packet, in its entirety, SHALL be placed into the data part of the echo-response packet, and the data part of the echo-response packet shall contain only the corresponding echo-request packet.

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 specified caveats.

The lifetime field of echo-request and echo-response packets SHOULD be set to the value normally used for a data packet. The memo does not define a mechanism for varying the lifetime field set in the echo-response packet.

The maximum length of the echo-request packet SHALL equal the maximum length of the echo-response packet minus the maximum length of the echo-response packet header, ensuring the entire echo-request packet fits within the data field of the echo-response packet.

The rules used for discarding a data packet (ISO 8473, Section 6.9–6.10) are applied when an echo-request or echo-response is discarded.

The source address field of the echo-response packet SHALL contain the value of the destination address field of the corresponding echo-request packet, and the destination address field of the echo-response packet SHALL contain the value of the source address field of the corresponding echo-request packet.

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.

This memo RECOMMENDS against the use of the source route option in either echo-request or echo-response packets, because use of the source route option in ISO 8473 may cause packets to loop until their lifetime expires.

When an echo-response packet header is embedded in the echo-request data part and used by the packet composition function, the value of the lifetime field in that embedded header MUST be used as the lifetime field value in the echo-response packet; segment length and checksum SHALL be recomputed by the network-entity regardless.

An echo-response packet must follow the same path as a CLNP data packet with the same options in the CLNP header. The entire echo-request packet (header and data) is carried in the echo-response data field so that fields such as the echo-request lifetime may be examined upon receipt.

If the first octet of the echo-request data field is binary 10000001, an echo-response header is contained in the echo-request packet. This embedded header allows a router to formulate a standard echo-response packet including lifetime, segment length, and checksum fields.

The echo-request packet's source and destination address fields contain Network Entity Titles (NETs) rather than full NSAP addresses. A NET is syntactically indistinguishable from an NSAP address, and the additional NSAP information is irrelevant to echo-request processing since no N-UNITDATA indication is produced.

The error report flag may be set on the echo-request, echo-response, or both. If an echo-request is discarded, an error-report (ER) packet is sent to the echo-request source; if an echo-response is discarded, the ER packet is sent to the echo-response source. The echo-request entity and originator are not required to process ER packets.

Two new ISO 8473 packet types are defined: ERQ (echo-request) with type code decimal 30, and ERP (echo-response) with type code decimal 31. With the exception of the new type code, these packets are identical to the data packet in every respect.

Security issues are not discussed in this memo.

security

The echo-request packet type code field is set to decimal 30; the echo-response packet type code field is set to decimal 31. All other header fields follow the same structure as an ISO 8473 data (DT) packet.