rfc994.txt

RFC 相关的技术文档

   tinguish timers with the same name. The name and subscript taken to-
   gether constitute a unique reference to the timer.

   Timers used in association with a specific protocol funtion are de-
   fined under that protocol function.


                                   Note:
       This International Standard does not define specific values for
       the timers. Any derivations described in this Standard are not
       mandatory. Timer values should be chosen so that the requested
       Quality of Service can be provided, given the known characteristics
       of the underlying service.














ISO 8473                                                       [Page 17]

RFC 994                                                    December 1986


              SECTION  TWO.  SPECIFICATION OF THE PROTOCOL


6     Protocol Functions

   This Clause describes the functions performed as part of the Proto-
   col.

   Not all of the functions must be performed by every implementation.
   Clause 6.17 specifies which functions may be omitted, and the correct
   behavior when requested functions are not implemented.

6.1     PDU Composition Function

   This function is responsible for the construction of a protocol data
   unit according to the rules governing the encoding of PDUs given in
   Clause 7.  Protocol Control Information required for delivering the
   data unit to its destination is determined from current state and lo-
   cal information and from the parameters associated with the N-
   UNITDATA Request.

   Network Protocol Address Information (NPAI) for the Source Address
   and Destination Address fields of the PDU header is derived from the
   NS-Source-Address and NS-Destination-Address parameters. The NS-
   Destination-Address and NS-Quality-of-Service parameters, together
   with current state and local information, are used to determine which
   optional functions are to be selected. User data passed from the Net-
   work Service User (NS-Userdata) forms the Data field of the protocol
   data unit.

   During the composition of the protocol data unit, a Data Unit Iden-
   tifier is assigned to distinguish this request to transmit NS-
   Userdata to a particular destination NS User from other such re-
   quests. The originator of the PDU must choose the Data Unit Identif-
   ier so that it remains unique (for this Source and Destination ad-
   dress pair) for the maximum lifetime of the Initial PDU in the net-
   work; this rule applies for any PDUs derived from the Initial PDU as
   a result of the application of the Segmentation Function (see Clause
   6.7).  Derived PDUs are considered to correspond to the same Initial
   PDU, and hence the same N-UNITDATA Request, if they have the same
   Source Address, Destination Address, and Data Unit Identifier.

   The Data Unit Identifier is also available for ancillary functions
   such as error reporting (see Clause 6.10).

   The total length of the PDU in octets is determined by the originator
   and placed in the Total Length field of the PDU header. This field is
   not changed in any Derived PDU for the lifetime of the protocol data
   unit.





ISO 8473                                                       [Page 18]

RFC 994                                                    December 1986


   When the Non-segmenting protocol subset is employed, neither the To-
   tal Length field nor the Data Unit Identifier field is present.  The
   rules governing the PDU composition function are modified in this
   case as follows. During the composition of the protocol data unit,
   the total length of the PDU in octets is determined by the originator
   and placed in the Segment Length field of the PDU header. This field
   is not changed for the lifetime of the PDU. No Data Unit Identifica-
   tion is provided.

6.2     PDU Decomposition Function

   This function is responsible for removing the Protocol Control Infor-
   mation from the protocol data unit.  During this process, information
   pertinent to the generation of the N-UNITDATA Indication is deter-
   mined as follows. The NS-Source-Address and NS-Destination-Address
   parameters of the N-UNITDATA Indication are recovered from the NPAI
   in the Source and Destination Address fields of the PDU header. The
   data field of the PDU received is reserved until all segments of the
   original service data unit have been received; collectively, these
   form the NS-Userdata parameter of the N-UNITDATA Indication.  Infor-
   mation relating to the Quality of Service provided during the
   transmission of the PDU is determined from the Quality of Service and
   other information contained in the Options Part of the PDU header.
   This information constitutes the NS-Quality-of-Service parameter of
   the N-UNITDATA Indication.

6.3     Header Format Analysis Function

   This function determines whether the full protocol described in this
   Standard is employed, or one of the defined proper subsets thereof.
   If the protocol data unit has a Network Layer Protocol Identifier in-
   dicating that this is a standard version of the Protocol, this func-
   tion determines whether a received PDU has reached its destination,
   using the Destination Address provided in the PDU. If the Destination
   Address provided in the PDU identifies an NSAP served by this
   network-entity, then the PDU has reached its destination; if not, it
   must be forwarded.

   If the protocol data unit has a Network Layer Protocol Identifier in-
   dicating that the Inactive Network Layer Protocol subset is in use,
   then no further analysis of the PDU header is required. The network-
   entity in this case determines that either the Subnetwork Point of
   Attachment address encoded as network protocol address information in
   the supporting subnetwork protocol corresponds directly to an NSAP
   address serviced by this network-entity or that an error has oc-
   curred. If the subnetwork protocol data unit has been delivered
   correctly, then the PDU may be decomposed according to the procedures
   described for that particular subnetwork protocol.






ISO 8473                                                       [Page 19]

RFC 994                                                    December 1986


6.4     PDU Lifetime Control Function

   This function is used to enforce the maximum PDU lifetime. It is
   closely associated with the Header Format Analysis function.  This
   function determines whether a PDU received may be forwarded or wheth-
   er its assigned lifetime has expired, in which case it must be dis-
   carded.

   The operation of the PDU Lifetime Control function depends upon the
   Lifetime field in the PDU header.  This field contains, at any time,
   the remaining lifetime of the PDU (represented in units of 500 mil-
   liseconds). The Lifetime of the Initial PDU is determined by the ori-
   ginating network-entity, and placed in the Lifetime field of the PDU.
   When the Segmentation function is applied to a PDU, the value of the
   Lifetime field of the Initial PDU is copied into all of the Derived
   PDUs.

   The Lifetime of the PDU is decremented by every network-entity which
   processes the PDU. When a network-entity processes a PDU, it decre-
   ments the PDU Lifetime by at least one.  The value of the PDU Life-
   time field shall be decremented by more than one if the sum of:

      1.  the transit delay in the underlying service from which the PDU
          was received; and

      2.  the delay within the system processing the PDU

   exceeds or is estimated to exceed 500 milliseconds.  In this case,
   the lifetime field should be decremented by one for each additional
   500 milliseconds of delay. The determination of delay need not be
   precise, but where a precise value cannot be ascertained, the value
   used shall be an overestimate, not an underestimate.

   If the Lifetime field reaches a value of zero before the PDU is
   delivered to the destination, the PDU must be discarded.  The Error
   Reporting function shall be invoked as described in Clause 6.10, Er-
   ror Reporting Function, and may result in the generation of an Error
   Report PDU.  It is a local matter whether the destination network-
   entity performs the Lifetime Control function.

6.5     Route PDU Function

   This function determines the network-entity to which a protocol data
   unit should be forwarded and the underlying service that must be used
   to reach that network-entity, using the Destination Address and the
   total length of the PDU. Where segmentation is required, the Route
   PDU function further determines over which underlying service Derived
   PDUs/segments must be sent in order to reach that network-entity. The
   results of the Route PDU function are passed to the Forward PDU func-
   tion (along with the PDU itself) for further processing.  Selection
   of the underlying service that must be used to reach the "next" sys-



ISO 8473                                                       [Page 20]

RFC 994                                                    December 1986


   tem in the route is initially influenced by the NS-Quality-of- Ser-
   vice parameter of the N-UNITDATA Request, which specifies the QoS re-
   quested by the sending NS User. Whether this QoS is to be provided
   directly by the CLNP, through the selection of the Quality of Service
   Maintenance parameter and other optional parameters, or through the
   QoS facilities offered by each of the underlying services is deter-
   mined prior to invocation of the Forward PDU function.  Route selec-
   tion by intermediate systems may subsequently be influenced by the
   values of the Quality of Service Maintenance parameter (if present),
   and other optional parameters (if present).

6.6     Forward PDU Function

   This function issues an SN-UNITDATA Request primitive (see Clause
   5.5), supplying the subnetwork or SNDCF identified by the Route PDU
   function with the protocol data unit as user data to be transmitted,
   the address information required by that subnetwork or SNDCF to iden-
   tify the "next" system within the subnetwork-specific addressing
   domain (this may be an intermediate-system or the destination end-
   system), and Quality of Service constraints (if any) to be considered
   in the processing of the user data.

   When the PDU to be forwarded is longer than the maximum service data
   user size provided by the underlying service, the Segmentation func-
   tion is applied (See Clause 6.7, which follows).

6.7     Segmentation Function

   Segmentation is performed when the size of the protocol data unit is
   greater than the maximum service data unit size supported by the
   underlying service to be used to transmit the PDU.

   Segmentation consists of composing two or more new PDUs (Derived
   PDUs) from the PDU received. The PDU received may be the Initial PDU,
   or it may be a Derived PDU. All of the header information from the
   PDU to be segmented, with the exception of the segment length and
   checksum fields of the fixed part, and the segment offset of the seg-
   mentation part, is duplicated in each Derived PDU, including all of
   the address part, the data unit identifier and total length of the
   segmentation part, and the options part (if present).

                                   Note:
       The rules for forwarding and segmentation guarantee that the
       header length is the same for all segments (Derived PDUs) of
       the Initial PDU, and is the same as the header length of the
       Initial PDU.  The size of a PDU header will not change due to
       operation of any protocol function.

   The user data encapsulated within the PDU received are divided such
   that the Derived PDUs satisfy the size requirements of the user data
   parameter field of the primitive used to access the underlying ser-



ISO 8473                                                       [Page 21]

RFC 994                                                    December 1986


   vice.

   Derived PDUs are identified as being from the same Initial PDU by
   means of

     (a)  the source address,

     (b)  the destination address, and

     (c)  the data unit identifier.

   Segmentation shall not result in the generation of a Derived PDU con-
   taining less than eight (8) octets of user data.

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

      (a)  Segment Offset --- identifies, with respect to the start
           of the Initial PDU, the octet at which the segment begins;

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

      (c)  More Segments Flag --- is 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 rout-
   ing of the individual Derived PDUs.  The Segmentation Permitted flag
   is set to one to indicate that segmentation is permitted. If the Ini-
   tial PDU is not to be segmented at any point during its lifetime in
   the network, the flag is set to zero by the source network-entity.
   The setting of the Segmentation Permitted flag cannot be changed by
   any other network-entity for the lifetime of the Initial PDU and any
   Derived PDUs.

6.8     Reassembly Function

   The Reassembly function reconstructs the Initial PDU from the Derived
   PDUs generated by the operation of the Segmentation Function on the
   Initial PDU (and, recursively, on subsequent Derived PDUs).  A bound
   on the time during which segments (Derived PDUs) of an Initial PDU
   will be held at a reassembly point before being discarded is provid-
   ed, so that reassembly resources may be released when it is no longer
   expected that any outstanding segments of the Initial PDU will arrive
   at the reassembly point. Upon reception of a Derived PDU, a reassem-
   bly timer is initiated with a value which indicates the amount of



ISO 8473                                                       [Page 22]

RFC 994                                                    December 1986