home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1575 < prev    next >
Text File  |  1994-02-17  |  22KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Hares
  8. Request for Comments: 1575                                  Merit/NSFNET
  9. Obsoletes: 1139                                             C. Wittbrodt
  10. Category: Standards Track                    Stanford University/BARRNet
  11.                                                            February 1994
  12.  
  13.  
  14.                   An Echo Function for CLNP (ISO 8473)
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This memo defines an echo function for the connection-less network
  27.    layer protocol.  The mechanism that is mandated here is in the final
  28.    process of being standardized by ISO as "Amendment X: Addition of an
  29.    Echo function to ISO 8473" an integral part of Version 2 of ISO 8473.
  30.  
  31. Table of Contents
  32.  
  33.    Section 1. Conventions .................................    2
  34.    Section 2. Introduction ................................    2
  35.    Section 3. The Generic Echo Function ...................    3
  36.    Section 3.1 The Echo-Request ...........................    3
  37.    Section 3.2 The Echo-Response ..........................    3
  38.    Section 4. The Implementation Mechanism ................    4
  39.    Section 4.1 The Echo-Request ...........................    4
  40.    Section 4.2 The Echo-Response ..........................    4
  41.    Section 5. Implementation Notes ........................    4
  42.    Section 5.1 Discarding Packets .........................    4
  43.    Section 5.2 Error Report Flag ..........................    4
  44.    Section 5.3 Use of the Lifetime Field ..................    5
  45.    Section 5.4 Echo-request function ......................    5
  46.    Section 5.5 Echo-response function .....................    6
  47.    Section 5.6 Use of the Priority Option .................    8
  48.    Section 5.7 Use of the Source Route Option .............    8
  49.    Section 5.8 Transmission of Multiple Echo-Requests .....    9
  50.    Section 6. Security Considerations .....................    9
  51.    Section 7. Authors' Addresses ..........................    9
  52.    Section 8. References ..................................    9
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Hares & Wittbrodt                                               [Page 1]
  59.  
  60. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  61.  
  62.  
  63. 1.  Conventions
  64.  
  65.    The following language conventions are used in the items of
  66.    specification in this document:
  67.  
  68.       o MUST, SHALL, or MANDATORY -- the item is an absolute
  69.         requirement of the specification.
  70.  
  71.       o SHOULD or RECOMMENDED -- the item should generally be followed
  72.         for all but exceptional circumstances.
  73.  
  74.       o MAY or OPTIONAL -- the item is truly optional and may be
  75.         followed or ignored according to the needs of the implementor.
  76.  
  77. 2.  Introduction
  78.  
  79.    The OSI Connection-less network layer protocol (ISO 8473) defines a
  80.    means for transmitting and relaying data and error protocol data
  81.    units, (PDUs) or preferably, packets through an OSI internet.
  82.    Unfortunately, the world that these packets travel through is
  83.    imperfect.  Gateways and links may fail.  This memo defines an echo
  84.    function to be used in the debugging and testing of the OSI network
  85.    layer.  Hosts and routers which support the OSI network layer MUST be
  86.    able to originate an echo packet as well as respond when an echo is
  87.    received.
  88.  
  89.    Network management protocols can be used to determine the state of a
  90.    gateway or link.  However, since these protocols themselves utilize a
  91.    protocol that may experience packet loss, it cannot be guaranteed
  92.    that the network management applications can be utilized.  A simple
  93.    mechanism in the network layer is required so that systems can be
  94.    probed to determine if the lowest levels of the networking software
  95.    are operating correctly.  This mechanism is not intended to compete
  96.    with or replace network management; rather it should be viewed as an
  97.    addition to the facilities offered by network management.
  98.  
  99.    The code-path consideration requires that the echo path through a
  100.    system be identical (or very close) to the path used by normal data.
  101.    An echo path must succeed and fail in unison with the normal data
  102.    path or else it will not provide a useful diagnostic tool.
  103.  
  104.    Previous drafts describing an echo function for CLNP offered two
  105.    implementation alternatives (see RFC 1139).  Although backward
  106.    compatibility is an important consideration whenever a change is made
  107.    to a protocol, it is more important at this point that the echo
  108.    mechanisms used on the Internet interoperate.  For this reason, this
  109.    memo defines one implementation mechanism (consistent with one of the
  110.    previous drafts).
  111.  
  112.  
  113.  
  114. Hares & Wittbrodt                                               [Page 2]
  115.  
  116. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  117.  
  118.  
  119. 3.  The Generic Echo Function
  120.  
  121.    The following section describes the echo function in a generic
  122.    fashion.  This memo defines an echo-request entity.  The function of
  123.    the echo-request entity is to accept an incoming echo-request packet,
  124.    perform some processing, and generate an echo-response packet.  The
  125.    echo implementation may be thought of as an entity that coexists with
  126.    the network layer.  Subsequent sections will detail the
  127.    implementation mechanism.
  128.  
  129.    For the purposes of this memo, the term "ping" shall be used to mean
  130.    the act of transmitting an echo-request packet to a remote system
  131.    (with the expectation that an echo-response packet will be sent back
  132.    to the transmitter).
  133.  
  134. 3.1.  The Echo-Request
  135.  
  136.    When a system decides to ping a remote system, an echo-request is
  137.    built.  All fields of the packet header are assigned normal values
  138.    (see implementation specific sections for more information).  The
  139.    address of the system to be pinged is inserted as the destination
  140.    NSAP address.  The rules of segmentation defined for a data (DT)
  141.    packet also apply to the echo-request packet.
  142.  
  143.    The echo-request is switched through the network toward its
  144.    destination.  (An echo packet must follow the same path as CLNP data
  145.    packet with the same options in the CLNP header.)  Upon reaching the
  146.    destination system, the packet is processed according to normal
  147.    processing rules.  At the end of the input processing, the echo-
  148.    request packet is delivered to the echo-request entity.
  149.  
  150.    The echo-request entity will build and dispatch the echo-response
  151.    packet.  This is a new packet.  Except as noted below, this second
  152.    packet is built using the normal construction procedures.  The
  153.    destination address of the echo-response packet is taken from the
  154.    source address of the echo-request packet.  Most options present in
  155.    the echo-request packet are copied into the echo-response packet (see
  156.    implementation notes for more information).
  157.  
  158. 3.2.  The Echo-Response
  159.  
  160.    The entire echo-request packet is included in the data portion of the
  161.    echo-response packet.  This includes the echo-request packet header
  162.    as well as any data that accompanies the echo-request packet.  The
  163.    entire echo-request packet is included in the echo-response so that
  164.    fields such as the echo-request lifetime may be examined when the
  165.    response is received.  After the echo-response packet is built, it is
  166.    transmitted toward the new destination (the original source of the
  167.  
  168.  
  169.  
  170. Hares & Wittbrodt                                               [Page 3]
  171.  
  172. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  173.  
  174.  
  175.    echo-request).  The rules of segmentation defined for a data packet
  176.    also apply to the echo-response packet.
  177.  
  178.    The echo-response packet is relayed through the network toward its
  179.    destination. (A echo response packet must follow the same path as a
  180.    CLNP data packet with the same options in the CLNP header.)  Upon
  181.    reaching its destination, it is processed by the packet input
  182.    function and delivered to the entity that created the echo-request.
  183.  
  184. 4.  The Implementation Mechanism
  185.  
  186.    The implementation mechanism defines two new 8473 packet types: ERQ
  187.    (echo-request) and ERP (echo-response).  With the exception of a new
  188.    type code, these packets will be identical to the date packet in
  189.    every respect.
  190.  
  191. 4.1.  The Echo-Request
  192.  
  193.    The type code for the echo-request packet is decimal 30.
  194.  
  195. 4.2.  The Echo-Response
  196.  
  197.    The type code for the echo-response packet is decimal 31.
  198.  
  199. 5.  Implementation Notes
  200.  
  201.    The following notes are an integral part of memo.  It is important
  202.    that implementors take heed of these points.
  203.  
  204. 5.1.  Discarding Packets
  205.  
  206.    The rules used for discarding a data packet (ISO 8473, Section 6.9 -
  207.    Section 6.10) are applied when an echo-request or echo-response is
  208.    discarded.
  209.  
  210. 5.2.  Error Report Flag
  211.  
  212.    The error report flag may be set on the echo-request packet, the
  213.    echo-response packet, or both.  If an echo-request is discarded, the
  214.    associated error-report (ER) packet will be sent to the echo-request
  215.    source address on the originating machine.  If an echo-response is
  216.    discarded, the associated error-report packet will be sent to the
  217.    echo-response source address.  In general, this will be the
  218.    destination address of the echo-request entity.  It should be noted
  219.    that the echo-request entity and the originator of the echo-request
  220.    packet are not required to process error-report packets.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hares & Wittbrodt                                               [Page 4]
  227.  
  228. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  229.  
  230.  
  231. 5.3.  Use of the Lifetime Field
  232.  
  233.    The lifetime field of the echo-request and echo-response packets
  234.    should be set to the value normally used for a data packet.  Note:
  235.    although this memo does not prohibit the generation of a packet with
  236.    a smaller-than-normal lifetime field, this memo explicitly does not
  237.    attempt to define a mechanism for varying the lifetime field set in
  238.    the echo-response packet.  This memo recommends the lifetime value
  239.    that would under normal circumstances by used when sending a data
  240.    packet.
  241.  
  242. 5.4.  Echo-request function
  243.  
  244.    This function is invoked by system management to obtain information
  245.    about the dynamic state of the Network layer with respect to (a) the
  246.    reachability of specific network-entities, and (b) the
  247.    characteristics of the path or paths that can be created between
  248.    network-entities through the operation of Network layer routing
  249.    functions.  When invoked, the echo-request function causes an echo-
  250.    request (ERQ) packet to be created.  The echo-request packet shall be
  251.    constructed and processed by ISO 8473 network-entities in end systems
  252.    and intermediate systems in exactly the same way as the data packet,
  253.    with the following caveats:
  254.  
  255.       a) The information available to the packet composition function
  256.       (ISO 8473) consists of current state, local information, and
  257.       information supplied by system management.
  258.  
  259.       b) The source and destination address fields of the echo-request
  260.       packet shall contain, respectively, a Network entity title (NET)
  261.       of the originating network-entity and a Network entity title of
  262.       the destination network-entity (which may be in either an end
  263.       system or an intermediate system).  NOTE: A Network entity title
  264.       is syntactically indistinguishable from an NSAP address.  The
  265.       additional information in an NSAP address, if any, beyond that
  266.       which is present in a Network entity title, is relevant only to
  267.       the operation of the packet decomposition function in a
  268.       destination end system, and therefore is not needed for the
  269.       processing of an echo-request packet (from which no N-UNITDATA
  270.       indication is ever produced).  The fact that the source and
  271.       destination address fields of the echo-request packet contain NETs
  272.       rather than NSAP addresses therefore does not affect the
  273.       processing of an echo-request packet by any network-entity.
  274.  
  275.       c) When an echo-request packet has reached its destination, as
  276.       determined by the Header processing (call HEADER FORMAT Analysis
  277.       function in ISO 8473), the echo-response function shall handle
  278.       this Network Protocol Data Units (NPDU) instead of the packet
  279.  
  280.  
  281.  
  282. Hares & Wittbrodt                                               [Page 5]
  283.  
  284. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  285.  
  286.  
  287.       decomposition function.  In ISO 8473, the packet decomposition
  288.       function is like a decomposing fish on the sea shore - it takes a
  289.       packet down to its bare bones and processes it.
  290.  
  291.       Also, it is up to each individual system whether or not handling
  292.       echo-request packets involves system management.  One example of
  293.       involving system management is the reporting reception of the echo
  294.       packets as some systems do with the ping packet.  Some systems
  295.       find this of value if they are being pinged to death.
  296.  
  297.       d) The maximum length of the echo-request packet is equal to the
  298.       maximum length of the echo-response packet minus the maximum
  299.       length of the echo-response packet header.  This ensures that the
  300.       entire echo-request packet can be contained within the data field
  301.       of the echo-response packet (see ISO 8473).
  302.  
  303.       e) The data part of the echo-request packet may, as a local
  304.       matter, contain zero or more octets with any values that fit
  305.       within the echo-request packet. (see (d) above for maximum length
  306.       of the echo-request packet). If the first octet of data is binary
  307.       1000 0001, then an echo-response header is contained in the echo-
  308.       request packet.  The existence of this header insures that a
  309.       router can formulate a standard echo-response packet.
  310.  
  311.    Normally, the "more segmentation" flag in the encapsulated echo-
  312.    response packet header shall be zero, and the segmentation portion of
  313.    the encapsulated packet shall not be included.  The segmentation
  314.    length in the echo-response packet header shall be zero.
  315.  
  316.    If the "more segmentation" flag is set in the encapsulated echo-
  317.    response packet header, then a segmentation length shall be filled in
  318.    and the segmentation part of the echo-response packet header will be
  319.    present in the echo-response header.  This same segmentation function
  320.    shall be present in the echo-response sent by the router.
  321.  
  322.    NOTE: However, this formulated echo-response is not required between
  323.    any two systems.  With a common format for an echo-request packet
  324.    used in an environment such as the Internet, the echo-response header
  325.    may not be needed, and may in fact be unnecessary overhead.
  326.  
  327. 5.5.  Echo-response function
  328.  
  329.    This function is performed by a network-entity when it has received
  330.    an echo-request packet that has reached its destination, as
  331.    determined by the Header format analysis function (ISO 8473 clause
  332.    6.3) that is, an echo-request packet which contains, in its
  333.    destination address field, a Network entity title that identifies the
  334.    network-entity.  When invoked, the echo-response function causes an
  335.  
  336.  
  337.  
  338. Hares & Wittbrodt                                               [Page 6]
  339.  
  340. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  341.  
  342.  
  343.    echo-response (ERP) packet to be created.  The echo-response packet
  344.    shall be constructed and processed by ISO 8473 network-entities in
  345.    end systems and intermediate systems in exactly the same way as the
  346.    data packet, with the following caveats:
  347.  
  348.       a) The information available to the packet composition function
  349.       consists of current state, local information, and information
  350.       contained in the corresponding echo-request packet.
  351.  
  352.       b) The source address field of the echo-response packet shall
  353.       contain the value of the destination address field of the
  354.       corresponding echo-request packet.  The destination address field
  355.       of the echo-response packet shall contain the value of the source
  356.       address field of the corresponding echo-request packet.
  357.  
  358.       c) The echo-request packet, in its entirety, shall be placed into
  359.       the data part of the echo-response packet.  The data part of the
  360.       echo-response packet shall contain only the corresponding echo-
  361.       request packet.
  362.  
  363.       d) If the data part of the echo-request packet contains an echo-
  364.       response header, the packet composition function may, but is not
  365.       required to, use some or all of the information contained therein
  366.       to select values for the fields of the echo-response packet
  367.       header.  In this case, however, the value of the lifetime field
  368.       contained in the echo-response packet header in the echo-request
  369.       packet data part must be used as the value of the lifetime field
  370.       in the echo-response packet.  The values of the segment length and
  371.       checksum fields shall be computed by the network-entity regardless
  372.       of the contents of those fields in the echo-response packet header
  373.       in the data part of the echo-request packet.
  374.  
  375.       e) The options part of the echo-response packet may contain any
  376.       (or none) of the options described in ISO 8473 (but see Section
  377.       5.7 of this RFC).  The values for these options, if present, are
  378.       determined by the network-entity as a local matter.  They may be,
  379.       but are not required to be, either identical to or derived from
  380.       the corresponding options in the echo-request packet and/or the
  381.       echo-response packet header contained in the data part of the
  382.       echo-request packet (if present).  The source routing option in
  383.       the echo-response packet shall not be identical to (copied from)
  384.       the source routing option in the echo-request packet header.  If
  385.       the recording of route option in the echo-response packet is
  386.       identical to (copied from) the recording of route option in the
  387.       echo-request packet header, the second octet of the parameter
  388.       value field shall be set to the value 3.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hares & Wittbrodt                                               [Page 7]
  395.  
  396. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  397.  
  398.  
  399.       f) It is a local matter whether or not the destination network-
  400.       entity performs the lifetime control function on an echo-request
  401.       packet before performing the echo-response function.  The
  402.       destination network-entity shall make the same decision in this
  403.       regard that it would make, as a local matter, for a data packet in
  404.       accordance with ISO 8473.
  405.  
  406. 5.6.  Use of the Priority Option
  407.  
  408.       The 8473 priority function indicates the relative priority of
  409.       packet.  0 is normal and 14 is the highest.  Packets with higher
  410.       values will be transmitted before lower values.  The specific
  411.       action upon receiving a 8473 packet with the priority field set is
  412.       a "LOCAL MATTER".  These means, any two systems could do it
  413.       differently.
  414.  
  415.       Hopefully, in the future, Internet routers will handle this as a
  416.       priority queueing function.  Some implementors consider the
  417.       priority queueing function to be a cap.  For example, if a router
  418.       is congested, all those packets with priorities higher than 20,
  419.       will be allowed through, and those with priority less than 20 will
  420.       be dropped.
  421.  
  422.       In short, the basic function of priority has wide latitude in the
  423.       ISO specification.  This wide latitude of implementation needs to
  424.       be narrowed for implementations within a common network
  425.       environment such as the Internet.  The 8473 priority function is
  426.       rarely implemented in today's Internet.  The transmission of an
  427.       echo-request packet with a priority set may provided unexcepted
  428.       results until a more wide spread deployment of the priority
  429.       feature in 8473 capable routers and end systems.
  430.  
  431.       However, if the priority function must be used it is the safest
  432.       value may be the value 0 - which indicates Normal priority.  It
  433.       most likely this value will follow the 8473 pathways.
  434.  
  435.       In the future, as the implementation of the priority function
  436.       further Internet documents will need to deal with its expected
  437.       use.
  438.  
  439. 5.7.  Use of the Source Route Option
  440.  
  441.       Use of the source route option in ISO 8473 may cause packets to
  442.       loop until their lifetime expires.  For this reason, this memo
  443.       recommends against the use of the source route option in either an
  444.       echo-request or echo-response packets.  If the source route option
  445.       is used to specify the route that the echo-request packet takes
  446.       toward its destination, this memo does not recommend the use of an
  447.  
  448.  
  449.  
  450. Hares & Wittbrodt                                               [Page 8]
  451.  
  452. RFC 1575          An Echo Function for CLNP (ISO 8473)     February 1994
  453.  
  454.  
  455.       automatically generated source route on the echo-response packet.
  456.  
  457. 5.8.  Transmission of Multiple Echo-Requests
  458.  
  459.       The echo function may be utilized by more than one process on any
  460.       individual machine.  The mechanism by which multiple echo-requests
  461.       and echo-responses are correlated between multiple processes on a
  462.       single machine is a local matter and not defined by this memo.
  463.  
  464. 6.  Security Considerations
  465.  
  466.       Security issues are not discussed in this memo.
  467.  
  468. 7.  Authors' Addresses
  469.  
  470.       Susan K. Hares
  471.       MERIT/NSFNET
  472.       Internet Engineering
  473.       1075 Beal Avenue
  474.       Ann Arbor, MI 48109-2112
  475.  
  476.       Phone: (313) 936-3000
  477.       EMail: skh@merit.edu
  478.  
  479.  
  480.       Cathy J. Wittbrodt
  481.       Stanford University/BARRNet
  482.       Networking Systems
  483.       Pine Hall 115
  484.       Stanford, CA 94305
  485.  
  486.       Phone: (415) 725-5481
  487.       EMail: cjw@magnolia.Stanford.EDU
  488.  
  489. 8.  References
  490.  
  491.    [1] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
  492.        Service.  International Standard 8473, ISO/IEC JTC 1,
  493.        Switzerland, 1986.
  494.  
  495.    [2] Hagens, R., "An Echo Function for ISO 8473", RFC 1139, IETF-OSI
  496.        Working Group, January 1990.
  497.  
  498.    [3] ISO 8473-1993 Protocol for providing the connectionless-mode
  499.        network service, edition 2 (IS under preparation).
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Hares & Wittbrodt                                               [Page 9]
  507.  
  508.