rfc1575.txt

RFC 的详细文档！

      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: [phone]
      EMail: [e-mail]


      Cathy J. Wittbrodt
      Stanford University/BARRNet
      Networking Systems
      Pine Hall 115
      Stanford, CA 94305

      Phone: [phone]
      EMail: [e-mail]

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]