An Echo Function for CLNP (ISO 8473)
RFC 1575
Document | Type |
RFC - Draft Standard
(February 1994; No errata)
Obsoletes RFC 1139
Was draft-ietf-noop-echo (noop WG)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1575 (Draft Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group S. Hares Request for Comments: 1575 Merit/NSFNET Obsoletes: 1139 C. Wittbrodt Category: Standards Track Stanford University/BARRNet February 1994 An Echo Function for CLNP (ISO 8473) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. 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 Hares & Wittbrodt [Page 1] RFC 1575 An Echo Function for CLNP (ISO 8473) February 1994 1. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 2. Introduction The OSI Connection-less network layer protocol (ISO 8473) defines a means for transmitting and relaying data and error protocol data units, (PDUs) or preferably, packets 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. 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. 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. The code-path consideration requires that the echo path through a system 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 or else it will not provide a useful diagnostic tool. Previous drafts describing an echo function for CLNP offered two implementation alternatives (see RFC 1139). Although backward compatibility is an important consideration whenever a change is made to a protocol, it is more important at this point that the echo mechanisms used on the Internet interoperate. For this reason, this memo defines one implementation mechanism (consistent with one of the previous drafts). Hares & Wittbrodt [Page 2]Show full document text