rfc926.txt

RFC 的详细文档！

ISO DIS 8473 (May 1984)                                        [Page 19]





RFC 926                                                    December 1984


  The following fields of the PDU header are used in conjunction with
  the Segmentation function:

   a)  Segment Offset - identifies at which octet in the data field of
       the Initial PDU the segment begins;

   b)  Segment Length - specifies the number of octets in the Derived
       PDU, including both header and data;

   c)  More Segments Flag - set to one if this Derived PDU does not
       contain, as its final octet of user data, the final octet of the
       Initial PDU; and

   d)  Total Length - specifies the entire length of the Initial PDU,
       including both header and data.

  Derived PDUs may be further segmented without constraining the routing
  of the individual Derived PDUs.

  A Segmentation Permitted flag is set to one to indicate that
  segmentation is permitted. If the Initial PDU is not to be segmented
  at any point during its lifetime in the network, the flag is set to
  zero.

  When the "Segmentation Permitted" flag is set to zero, the non-
  segmenting protocol subset is in use.

 6.8  Reassembly Function

  The Reassembly Function reconstructs the Initial PDU transmitted to
  the destination network-entity from the Derived PDUs generated during
  the lifetime of the Initial PDU.

  A bound on the time during which segments (Derived PDUs) of an Initial
  PDU will be held at a reassembly point is provided so that resources
  may be released when it is no longer expected that any outstanding
  segments of the Initial PDU will arrive at the reassembly point. When
  such an event occurs, segments (Derived PDUs) of the Initial PDU held
  at the reassembly point are discarded, the resources allocated for
  those segments are freed,









ISO DIS 8473 (May 1984)                                        [Page 20]





RFC 926                                                    December 1984


  and if selected, an Error Report is generated.

   Note:

    The design of the Segmentation and Reassembly functions is intended
    principally to be used such that reassembly takes place at the
    destination. However, other schemes which

     a)  interact with the routing algorithm to favor paths on which
         fewer segments are generated,

     b)  generate more segments than absolutely required in order to
         avoid additional segmentation at some subsequent point, or

     c)  allow partial/full reassembly at some point along the route
         where it is known that the subnetwork with the smallest PDU
         size has been transited

    are not precluded. The information necessary to enable the use of
    one of these alternative strategies may be made available through
    the operation of a Network Layer Management function.

    While the exact relationship between reassembly lifetime and PDU
    lifetime is a local matter, the reassembly algorithm must preserve
    the intent of the PDU lifetime. Consequently, the reassembly
    function must discard PDUs whose lifetime would otherwise have
    expired had they not been under the control of the reassembly
    function.

 6.9  Discard PDU Function

  This function performs all of the actions necessary to free the
  resources reserved by the network-entity in any of the following
  situations (Note: the list is not exhaustive):

   a)  A violation of protocol procedure has occurred.

   b)  A PDU is received whose checksum is inconsistent with its
       contents.










ISO DIS 8473 (May 1984)                                        [Page 21]





RFC 926                                                    December 1984


   c)  A PDU is received, but due to congestion, it cannot be processed.

   d)  A PDU is received whose header cannot be analyzed.

   e)  A PDU is received which cannot be segmented and cannot be
       forwarded because its length exceeds the maximum subnetwork
       service data unit size.

   f)  A PDU is received whose destination address is unreachable or
       unknown.

   g)  Incorrect or invalid source routing was specified. This may
       include a syntax error in the source routing field, and unknown
       or unreachable address in the source routing field, or a path
       which is not acceptable for other reasons.

   h)  A PDU is received whose PDU lifetime has expired or the lifetime
       expires during reassembly.

   i)  A PDU is received which contains an unsupported option.

 6.10  Error Reporting Function

  6.10.1  Overview

   This function causes the return of an Error Report PDU to the source
   network-entity when a protocol data unit is discarded. An "error
   report flag" in the original PDU is set by the source network-entity
   to indicate whether or not Error Report PDUs are to be returned.

   The Error Report PDU identifies the discarded PDU, specifies the type
   of error detected, and identifies the location at which the error was
   detected. Part or all of the discarded PDU is included in the data
   field of the Error Report PDU.

   The address of the originator of the Data Protocol Data Unit is













ISO DIS 8473 (May 1984)                                        [Page 22]





RFC 926                                                    December 1984


   conveyed as both the destination address of the Error Report PDU as
   well as the source address of the original Data PDU; the latter is
   contained in the Data field of the Error Report PDU. The address of
   the originator of the Error Report PDU is contained in the source
   address field of the header of the Error Report PDU.

    Note:

     Non-receipt of an Error Report PDU does not imply correct delivery
     of a PDU issued by a source network-entity.

  6.10.2  Requirements

   An Error Report PDU shall not be generated to report the discarding
   of a PDU that itself contains an Error Report.

   An Error Report PDU shall not be generated upon discarding of a PDU
   unless that PDU has the Error Report flag set to allow Error Reports.

   If a Data PDU is discarded, and has the Error Report flag set to
   allow Error Reports, an Error Report PDU shall be generated if the
   reason for discard (See Section 6.9)  is

    a)  destination address unreachable,

    b)  source routing failure,

    c)  unsupported options, or

    d)  protocol violation.



















ISO DIS 8473 (May 1984)                                        [Page 23]





RFC 926                                                    December 1984


    Note:

     It is intended that this list shall include all nontransient
     reasons for discard; the list may therefore need to be amended or
     extended in the light of any changes made in the definitions of
     such reasons.

   If a Data PDU with the Error Report flag set to allow Error Reports
   is discarded for any other reason, an Error Report PDU may be
   generated (as an implementation option).

  6.10.3  Processing of Error Reports

   Error Report PDUs are forwarded by intermediate network-entities in
   the same way as Data PDUs. It is possible that an Error Report PDU
   may be longer than the maximum user data size of a subnetwork that
   must be traversed to reach the origin of the discarded PDU. In this
   case, the Forward PDU function shall truncate the PDU to the maximum
   size acceptable.

   The entire header of the discarded data unit shall be included in the
   data field of the Error Report PDU. Some or all of the data field of
   the discarded data unit may also be included.

    Note:

     Since the suppression of Error Report PDUs is controlled by the
     originating network-entity and not by the NS User, care should be
     exercised by the originator with regard to suppressing ER PDUs so
     that error reporting is not suppressed for every PDU generated.



















ISO DIS 8473 (May 1984)                                        [Page 24]





RFC 926                                                    December 1984


 6.11  PDU Header Error Detection

  The PDU Header Error Detection function protects against failure of
  intermediate or end-system network-entities due to the processing of
  erroneous information in the PDU header. The function is realized by a
  checksum computed on the PDU header. The checksum is verified at each
  point at which the PDU header is processed. If PDU header fields are
  modified (for example, due to lifetime function), then the checksum is
  modified so that the checksum remains valid.

  An intermediate system network-entity must not recompute the checksum
  for the entire header, even if fields are modified.

   Note:

    This is to ensure that inadvertent modification of a header while a
    PDU is being processed by an intermediate system (for example, due
    to a memory fault) may still be detected by the PDU Header Error
    function.

  The use of this function is optional, and is selected by the
  originating network-entity. If the function is not used, the checksum
  field of the PDU header is set to zero.

  If the function is selected by the originating network-entity, the
  value of the checksum field causes the following formulae to be
  satisfied:

     L
   (SUM)     a   = 0  (modulo 255)
              i
     i=1

     L
   (SUM)     (L-i+1) a   = 0 (modulo 255)
                       i
     i=1

    Where L = the number of octets in the PDU header, and
          a = value of octet at position i.
           i








ISO DIS 8473 (May 1984)                                        [Page 25]





RFC 926                                                    December 1984


  When the function is in use, neither octet of the checksum field may
  be set to zero.

  Annex C contains descriptions of algorithms which may be used to
  calculate the correct value of the checksum field when the PDU is
  created, and to update the checksum field when the header is modified.

 6.12  Padding Function

  The padding function is provided to allow space to be reserved in the
  PDU header which is not used to support any other function. Octet
  alignment must be maintained.

   Note:

    An example of the use of this function is to cause the data field of
    a PDU to begin on a convenient boundary for the originating
    network-entity, such as a computer word boundary.

 6.13  Security

  An issue related to the quality of the network service is the
  protection of information flowing between transport-entities. A system
  may wish to control the distribution of secure data by assigning
  levels of security to PDUs. As a local consideration, the Network
  Service user could be authenticated to ascertain whether the user has
  permission to engage in communication at a particular security level
  before sending the PDU. While no protocol exchange is required in the
  authentication process, the optional security parameter in the options
  part of the PDU header may be employed to convey the particular
  security level between peer network-entities.

  The syntax and semantics of the security parameter are not specified
  by this Standard. The security parameter is related to the "protection
  from unauthorized access" Quality of service parameter described in
  ISO 8348/DAD1, Addendum to the Network Service Definition Covering
  Connectionless-mode Transmission. However, to facilitate
  interoperation between end-systems and relay-systems by avoiding
  different interpretations of the same encoding, a mechanism is
  provided to distinguish user-defined security encoding from
  standardized security encoding.








ISO DIS 8473 (May 1984)                                        [Page 26]





RFC 926                                                    December 1984


 6.14  Source Routing Function

  The Source Routing function allows the originator to specify the path
  a generated PDU must take. Source routing can only be selected by the
  originator of a PDU. Source Routing is accomplished using a list of
  intermediate system addresses (or titles, see Section 5.3 and 5.5.1)
  held in a parameter within the options part of the PDU Header. The
  size of the option field is determined by the originating
  network-entity. The length of this option does not change as the PDU
  traverses the network. Associated with this list is an indicator which
  identifies the next entry in the list to be used; this indicator is
  advanced by the receiver of the PDU when the next address matches its
  own address. The indicator is updated as the PDU is forwarded so as to
  identify the appropriate entry at each stage of relaying.

  Two forms of the source routing option are provided. The first form,
  referred to as complete source routing, requires that the specified
  path must be taken; if the specified path cannot be taken, the PDU
  must be discarded. The source may be informed of the discard using the
  Error Reporting function described in Section 6.10.

  The second form is referred to as partial source routing. Again, each
  address in the list must be visited in the order specified while on
  route to the destination. However, with this form of source routing
  the PDU may take any path necessary to arrive at the next address in
  the list. The PDU will not be discarded (for source routing related
  causes) unless one of the addresses specified cannot be reached by any
  available route.