rfc926.txt

RFC 相关的技术文档

ISO DIS 8473 (May 1984)                                        [Page 28]





RFC 926                                                    December 1984


 6.16  Quality of Service Maintenance Function

  In order to support the Quality of Service requested by Network
  Service users, the Protocol may need to make QOS information available
  at intermediate systems. This information may be used by network
  entities in intermediate systems to make routing decisions where such
  decisions affect the overall QOS provided to NS users.

  In those instances where the QOS indicated cannot be maintained, the
  NS provider will attempt to deliver the PDU at a QOS less than that
  indicated. The NS provider will not necessarily provide a notification
  of failure to meet the indicated quality of service.

 6.17  Classification of Functions

  Implementations do not have to support all of the functions described
  in Section 6. Functions are divided into three categories:

   Type 1:  These functions must be supported.

   Type 2:  These functions may or may not be supported. If an
            implementation does not support a Type 2 function, and the
            function is selected by a PDU, then the PDU shall be
            discarded, and an Error Report PDU shall be generated and
            forwarded to the originating network-entity, providing that
            the Error Report flag is set.

   Type 3:  These functions may or may not be supported. If an
            implementation does not support a Type 3 function, and the
            function is selected by a PDU, then the function is not
            performed and the PDU is processed exactly as though the
            function was not selected. The protocol data unit shall not
            be discarded.

  Table 6-1 shows how the functions are divided into these three
  categories:













ISO DIS 8473 (May 1984)                                        [Page 29]





RFC 926                                                    December 1984


         +---------------------------------------------------+
         | Function                       |  Type            |
         |--------------------------------|------------------|
         |                                |                  |
         | PDU Composition                |  1               |
         | PDU Decomposition              |  1               |
         | Header Format Analysis         |  1               |
         | PDU Lifetime Control           |  1               |
         | Route PDU                      |  1               |
         | Forward PDU                    |  1               |
         | Segment PDU                    |  1               |
         | Reassemble PDU                 |  1               |
         | Discard PDU                    |  1               |
         | Error Reporting                |  1 (note 1)      |
         | PDU Header Error Detection     |  1 (note 1)      |
         | Padding                        |  1 (notes 1   2) |
         | Security                       |  2               |
         | Complete Source Routing        |  2               |
         | Partial Source Routing         |  3               |
         | Priority                       |  3               |
         | Record Route                   |  3               |
         | Quality of Service Maintenance |  3               |
         +---------------------------------------------------+

            Table 6-1.  Categorization of Protocol Functions
























ISO DIS 8473 (May 1984)                                        [Page 30]





RFC 926                                                    December 1984


  Notes:

   1)  While the Padding, Error Reporting, and Header Error Detection
       functions must be provided, they are provided only when selected
       by the sending Network Service user.

   2)  The correct treatment of the Padding function involves no
       processing. Therefore, this could equally be described as a Type
       3 function.

   3)  The rationale for the inclusion of type 3 functions is that in
       the case of some functions it is more important to forward the
       PDUs between intermediate systems or deliver them to an
       end-system than it is to support the functions. Type 3 functions
       should be used in those cases where they are of an advisory
       nature and should not be the cause of the discarding of a PDU
       when not supported.
































ISO DIS 8473 (May 1984)                                        [Page 31]





RFC 926                                                    December 1984


7  STRUCTURE AND ENCODING OF PDUS

 7.1 Structure

  All Protocol Data Units shall contain an integral number of octets.
  The octets in a PDU are numbered starting from one (1) and increasing
  in the order in which they are put into an SNSDU. The bits in an octet
  are numbered from one (1) to eight (8), where bit one (1) is the
  low-order bit.

  When consecutive octets are used to represent a binary number, the
  lower octet number has the most significant value.

  Any subnetwork supporting this protocol is required to state in its
  specification the way octets are transferred, using the terms "most
  significant bit" and "least significant bit." The PDUs of this
  protocol are defined using the terms "most significant bit" and "least
  significant bit."

   Note:

    When the encoding of a PDU is represented using a diagram in this
    section, the following representation is used:

     a)  octets are shown with the lowest numbered octet to the left,
         higher number octets being further to the right;

     b)  within an octet, bits are shown with bit eight (8) to the left
         and bit one (1) to the right.

  PDUs shall contain, in the following order:

   1)  the header, comprising:

    a)  the fixed part;

    b)  the address part;

    c)  the segmentation part, if present;

    d)  the options part, if present

   and






ISO DIS 8473 (May 1984)                                        [Page 32]





RFC 926                                                    December 1984


   2)  the data field, if present.

  This structure is illustrated below:

                       Part:                Described in:  

            +-------------------+                          
            |    Fixed Part     |            Section 7.2   
            +-------------------+                          

            +-------------------+                          
            |   Address Part    |            Section 7.3   
            +-------------------+                          

            +-------------------+                          
            | Segmentation Part |            Section 7.4   
            +-------------------+                          

            +-------------------+                          
            |   Options Part    |            Section 7.5   
            +-------------------+                          

            +-------------------+                          
            |       Data        |            Section 7.6   
            +-------------------+                          

                       Figure 7-1.  PDU Structure






















ISO DIS 8473 (May 1984)                                        [Page 33]





RFC 926                                                    December 1984


 7.2 Fixed Part

  7.2.1 General

   The fixed part contains frequently occuring parameters including the
   type code (DT or ER) of the protocol data unit. The length and the
   structure of the fixed part are defined by the PDU code.

   The fixed part has the following format:

                                                      Octet 
            +------------------------------------+          
            | Network Layer Protocol Identifier  |     1    
            |------------------------------------|          
            |         Length Indicator           |     2    
            |------------------------------------|          
            |   Version/Protocol Id Extension    |     3    
            |------------------------------------|          
            |            Lifetime                |     4    
            |------------------------------------|          
            |S |M |E/R|         Type             |     5    
            | P| S|   |                          |          
            |------------------------------------|          
            |          Segment Length            |    6,7   
            |------------------------------------|          
            |             Checksum               |    8,9   
            +------------------------------------+          

                  Figure 7-2.  PDU Header--Fixed Part

  7.2.2 Network Layer Protocol Identifier

   The value of this field shall be binary 1000 0001. This field
   identifies this Network Layer Protocol as ISO 8473, Protocol for
   Providing the Connectionless-mode Network Service.














ISO DIS 8473 (May 1984)                                        [Page 34]





RFC 926                                                    December 1984


  7.2.3 Length Indicator

   The length is indicated by a binary number, with a maximum value of
   254 (1111 1110). The length indicated is the length in octets of the
   header, as described in Section 7.1, Structure. The value 255 (1111
   1111) is reserved for possible future extensions.

    Note:

     The rules for forwarding and segmentation ensure 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.

  7.2.4 Version/Protocol Identifier Extension

   The value of this field is binary 0000 0001. This Identifies a
   standard version of ISO 8473, Protocol for Providing the
   Connectionless-mode Network Service.

  7.2.5 PDU Lifetime

   The Lifetime field is encoded as a binary number representing the
   remaining lifetime of the PDU, in units of 500 milliseconds.

   The Lifetime field is set by the originating network-entity, and is
   decremented by every network-entity which processes the PDU. The PDU
   shall be discarded if the value of the field reaches zero.

   When a network-entity processes a PDU, it decrements the Lifetime by
   at least one. The Lifetime shall be decremented by more than one if
   the sum of:

    1)  the transit delay in the subnetwork from which the PDU was
        received; and















ISO DIS 8473 (May 1984)                                        [Page 35]





RFC 926                                                    December 1984


    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 error exists the value used shall be an
   overestimate, not an underestimate.

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

   When the Segmentation function is applied to a PDU, the Lifetime
   field is copied into all of the Derived PDUs.

  7.2.6 Flags

   7.2.6.1 Segmentation Permitted and More Segments Flags

    The Segmentation Permitted flag determines whether segmentation is
    permitted. A value of one indicates that segmentation is permitted.

    A value of zero indicates that the non-segmenting protocol subset is
    employed. Where this is the case, the segmentation part of the PDU
    header is not present, and the Segment Length field serves as the
    Total Length field.

    The More Segments flag indicates whether the data segment in this
    PDU contains (as its last octet) the last octet of the User Data in
    the NSDU. When the More Segments flag is set to one (1) then
    segmentation has taken place and the last octet of the NSDU is not
    contained in