doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1575.txt b/doc/rfc/rfc1575.txt
new file mode 100644
index 0000000..2fd222b
--- /dev/null
+++ b/doc/rfc/rfc1575.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+
\ No newline at end of file