ISO 8473 Echo: Echo function for ISO 8473
A diagnostic mechanism for testing the connectionless network layer.
Hagens, R.A., "Echo function for ISO 8473", RFC 1139, DOI 10.17487/RFC1139, January 1990, <https://www.rfc-editor.org/info/rfc1139>.
@misc{rfc1139,
series = {Request for Comments},
number = 1139,
howpublished = {RFC 1139},
publisher = {RFC Editor},
doi = {10.17487/RFC1139},
url = {https://www.rfc-editor.org/info/rfc1139},
author = {R.A. Hagens},
title = {{Echo function for ISO 8473}},
pagetotal = 6,
year = 1990,
month = jan,
} RFC text
Contents
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
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
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
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
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
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
AI ELI5
On this page
§1Why Echo Matters for Network Testing
The ISO 8473 connectionless network layer protocol (CLNP) handles datagram transmission and relaying in an OSI internet. However, the real-world networks carrying CLNP packets are imperfect: gateways fail, links go down, and packets are lost. Debugging these failures is difficult because network management protocols that could diagnose problems themselves depend on working packet delivery, creating a chicken-and-egg problem.
An echo function solves this by providing a lightweight diagnostic mechanism at the network layer. A system can send an echo-request packet to a remote machine and expect an echo-reply coming back. If the reply arrives, the path works; if not, something is broken. Importantly, the echo path must use the same code path as normal data, so it fails and succeeds in unison with regular traffic—making it a reliable diagnostic tool.
This memo defines echo using two approaches: a backward-compatible short-term version and a long-term version suitable for future ISO standards.
Network paths can break, but we need a simple way to check if they're working without relying on complicated management systems. Echoing is like a ping: send a test packet, get an answer back.
§2How the Echo Function Works
The echo function is conceptually simple. A sending system builds an echo-request PDU (Protocol Data Unit) with the remote system as the destination. This request travels through the network like any normal data packet, following the same routing and processing rules. When it reaches the destination system, it is delivered to an echo-request entity—a function that processes echo requests.
The echo-request entity then constructs an echo-reply PDU and sends it back to the original sender. The entire echo-request PDU, including its header and data, is encapsulated inside the echo-reply packet's data portion. This way, when the sender receives the reply, it can examine fields like the original packet's lifetime to determine how long the round trip took and whether the packet was modified.
The key design constraints are simplicity (so all systems implement it), code-path identity (the echo path must match normal data path exactly), and backward compatibility (existing systems should not break when echo packets pass through).
Send a message to a distant computer. When it arrives, that computer wraps the message inside a new message sent back to you, so you can verify the round trip worked.
§3Two Implementation Approaches
The RFC defines a short-term approach for immediate adoption and a long-term approach for future ISO standards.
Short-term approach: Echo packets are built using normal ISO 8473 Data (DT) PDU construction. The trick is in the NSAP address selectors. The echo-request uses a reserved selector value (decimal 30 by default) in the destination address to identify it as an echo-request. The source address uses a different selector value (decimal 31) to identify the echo-reply return path. To systems that do not implement echo, these packets look like perfectly ordinary data packets and are routed normally. Only systems that recognize the special selector values understand that these are echo packets and generate replies. This approach is maximally backward-compatible: old routers switch echo packets like any other data, and old endpoints simply ignore them.
Long-term approach: Two new PDU types are defined, ERQ (echo-request, type code 30) and ERP (echo-reply, type code 31). These are identical to DT PDUs except for the type code. This approach is not backward-compatible with existing ISO 8473 but may be adopted by ISO as an addendum to the standard.
There are two ways to do this. The quick way hides echo messages inside ordinary packets using special addresses—old systems won't recognize them as special but will deliver them anyway. The proper way creates official new packet types, but old systems might not know what to do with them.
§4Implementation Considerations
Several rules govern how echo packets are handled. First, the same discard rules applied to normal DT PDUs apply to echo packets—if the lifetime field expires, the packet is discarded.
Second, error report handling differs slightly. If an echo-request is discarded and has the error report flag set, an error report is sent back to the original sender. If an echo-reply is discarded, the error report goes to the source address of the echo-reply (typically the echo-request entity itself).
Third, the lifetime field in both echo-request and echo-reply should use normal data values—the RFC does not attempt to define special lifetime handling for echo packets.
Most PDU options (flags that modify behavior) from the echo-request are copied into the echo-reply, with two exceptions. The record route option is copied but reset to allow the echo-reply to record a complete path. The source route option is explicitly not copied, because source-routed echo requests can cause packet loops. Similarly, while the RFC allows priority values in echo headers, it cautions against using high priority, as normal data priority should apply.
Finally, multiple processes on a single machine may send echo-requests simultaneously. How a system correlates replies to requests among multiple processes is a local implementation matter not defined by this RFC.
When handling echo packets, follow the normal rules: discard if they're too old, report errors properly, and don't try to force special priority or routing that normal packets wouldn't use.