rfc1575.txt

RFC 的详细文档！

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]

RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994


3.  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 packet,
   perform some processing, and generate an echo-response packet.  The
   echo implementation may be thought of as an entity that coexists with
   the network layer.  Subsequent sections will 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 is
   built.  All fields of the packet 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 data (DT)
   packet also apply to the echo-request packet.

   The echo-request is switched through the network toward its
   destination.  (An echo packet must follow the same path as CLNP data
   packet with the same options in the CLNP header.)  Upon reaching the
   destination system, the packet is processed according to normal
   processing rules.  At the end of the 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 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
   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.  This includes the echo-request packet header
   as well as any data that accompanies the echo-request packet.  The
   entire echo-request packet is included in the echo-response so that
   fields such as the echo-request lifetime may be examined when the
   response is received.  After the echo-response packet is built, it is
   transmitted toward the new destination (the original source of the



Hares & Wittbrodt                                               [Page 3]

RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994


   echo-request).  The rules of segmentation defined for a data packet
   also apply to the echo-response packet.

   The echo-response packet is relayed through the network toward its
   destination. (A echo response packet must follow the same path as a
   CLNP data packet with the same options in the CLNP header.)  Upon
   reaching its destination, it is 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: ERQ
   (echo-request) and ERP (echo-response).  With the exception of a new
   type code, these packets will be identical to the date 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

   The following notes are an integral part of memo.  It is important
   that implementors take heed of these points.

5.1.  Discarding Packets

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





Hares & Wittbrodt                                               [Page 4]

RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994


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.  Note:
   although this memo does not prohibit the generation of a packet 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-response packet.  This memo recommends the lifetime value
   that would under normal circumstances by used when sending a data
   packet.

5.4.  Echo-request function

   This function is invoked by system management to obtain information
   about the dynamic state of the Network layer with respect to (a) the
   reachability of specific network-entities, and (b) the
   characteristics of the path or paths that can be created between
   network-entities through the operation of Network layer routing
   functions.  When invoked, the echo-request function causes an echo-
   request (ERQ) packet to be created.  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 the following caveats: