GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1575

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:
    a) The information available to the packet composition function
    (ISO 8473) consists of current state, local information, and
    information supplied by system management.
    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.  The
    additional information in an NSAP address, if any, beyond that
    which is present in a Network entity title, is relevant only to
    the operation of the packet decomposition function in a
    destination end system, and therefore is not needed for the
    processing of an echo-request packet (from which no N-UNITDATA
    indication is ever produced).  The fact that the source and
    destination address fields of the echo-request packet contain NETs
    rather than NSAP addresses therefore does not affect the
    processing of an echo-request packet by any network-entity.
    c) When an echo-request packet has reached its destination, as
    determined by the Header processing (call HEADER FORMAT Analysis
    function in ISO 8473), the echo-response function shall handle
    this Network Protocol Data Units (NPDU) instead of the packet

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

    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 is up to each individual system whether or not handling
    echo-request packets involves system management.  One example of
    involving system management is the reporting reception of the echo
    packets as some systems do with the ping packet.  Some systems
    find this of value if they are being pinged to death.
    d) The maximum length of the echo-request packet is equal to the
    maximum length of the echo-response packet minus the maximum
    length of the echo-response packet header.  This ensures that the
    entire echo-request packet can be contained within 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 maximum length
    of the echo-request packet). If the first octet of data is binary
    1000 0001, then an echo-response header is contained in the echo-
    request packet.  The existence of this header insures that 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.

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) that is, an echo-request packet which contains, in its
 destination address field, a Network entity title that identifies the
 network-entity.  When invoked, the echo-response function causes an

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

 echo-response (ERP) packet to be created.  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 the following caveats:
    a) The information available to the packet composition function
    consists of 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.
    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.
    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 information contained therein
    to select values for the fields of the echo-response packet
    header.  In this case, however, the value of the lifetime field
    contained in the echo-response packet header in the echo-request
    packet 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 regardless
    of the contents of those fields in the echo-response packet header
    in the data part of the echo-request packet.
    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, either identical to or derived from
    the corresponding options in the echo-request packet and/or the
    echo-response packet header contained in the data part of the
    echo-request packet (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.

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

    f) It is a local matter whether or not the destination network-
    entity performs the lifetime control function on an echo-request
    packet before performing the echo-response function.  The
    destination network-entity shall make the same decision in this
    regard that it would make, as a local matter, for a data packet in
    accordance with ISO 8473.

5.6. Use of the Priority Option

    The 8473 priority function indicates the relative priority of
    packet.  0 is normal and 14 is the highest.  Packets with higher
    values will be transmitted before lower values.  The specific
    action upon receiving a 8473 packet with the priority field set is
    a "LOCAL MATTER".  These means, any two systems could do it
    differently.
    Hopefully, in the future, Internet routers will handle this as a
    priority queueing function.  Some implementors consider the
    priority queueing function to be a cap.  For example, if a router
    is congested, all those packets with priorities higher than 20,
    will be allowed through, and those with priority less than 20 will
    be dropped.
    In short, the basic function of priority has wide latitude in the
    ISO specification.  This wide latitude of implementation 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.  The transmission of an
    echo-request packet with a priority set may provided unexcepted
    results until a more wide spread deployment of the priority
    feature in 8473 capable routers and end systems.
    However, if the priority function must be used it is the safest
    value may be the value 0 - which indicates Normal priority.  It
    most likely this value will follow the 8473 pathways.
    In the future, as the implementation of the priority function
    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 the use of the source route option in either an
    echo-request or echo-response packets.  If the source route option
    is used to specify the route that the echo-request packet takes
    toward its destination, this memo does not recommend the use of an

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

    automatically generated source route on the echo-response packet.

5.8. 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-responses are correlated between multiple processes on a
    single machine is a local matter and not defined by this memo.

6. Security Considerations

    Security issues are not discussed in this memo.

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

Hares & Wittbrodt [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1575.txt · Last modified: 1994/02/17 02:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki