rfc995.txt

RFC 相关的技术文档

   The Flush Old Redirect Function is executed to remove Configuration
   entries in the routing information base whose Holding Timer has ex-
   pired.  When the Holding Time for an ES or IS expires, this function
   removes the corresponding entry from the routing information base of
   the local Network Entity.

7.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 entire PDU header. The checksum is verified
   at each point at which the PDU is processed. If the checksum calcula-
   tion fails, the PDU must be discarded.

   The use of the Header Error Detection 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 formulf to be satis-
   fied:

        (The Sum from i=1 to L of a(i)) (mod   255) = 0

        (The Sum from i=1 to L of  (L - i + 1) * a(i))  (mod   255) = 0


   where L = the number of octets in the PDU header, and a(i) = the value of
   the octet at position i. The first octet in the PDU header is considered to
   occupy position i = 0.

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








ISO N4053                                                      [Page 24]

RFC 995                                                    December 1986


7.12   Classification of Functions

   Implementations do not have to support all of the functions described
   in clause 7. Functions are divided into four categories:

   Type A:   These functions must be supported in all cases.

   Type B:   These functions must be supported by Systems which implement
             the Configuration Information.

   Type C:   These functions must be supported by Systems which implement
             the Redirect Information.

   Type D:   These functions are optional.

   If a PDU is received which invokes an optional function that is not
   implemented, that PDU is discarded.

   Table 3 shows how the functions are divided into these four
   categories, and to which type of system (ES, IS, or both) they apply.

    ______________________________________________________________
    | Function                      |   Category |   System Type |
    |_______________________________|____________|_______________|
    | Report Configuration          |      B     |      ES,IS    |
    | Record Configuration          |      B     |      ES,IS    |
    | Configuration Response        |      A     |       ES      |
    | Flush Old Configuration       |      B     |      ES,IS    |
    | Request Redirect              |      C     |       IS      |
    | Query Configuration           |      B     |       ES      |
    | Record Redirect               |      C     |       ES      |
    | Refresh Redirect              |      D     |       ES      |
    | Flush Old Redirect            |      C     |       ES      |
    | PDU Header Error Detection    |      A     |      ES,IS    |
    |_______________________________|____________|_______________|

            Table 3: Categories of Protocol Functions

8   Structure and Encoding of PDUs

                              Note:
     The encoding of the PDUs for this protocol is compatible with that
     used in ISO 8473.

                       Temporary Note:
     The method employed for describing the encoding of PDUs is provisional.
     Member bodies are requested to comment on whether another
     method (such as ASN.1 with an appropriate concrete syntax) would
     be preferable.





ISO N4053                                                      [Page 25]

RFC 995                                                    December 1986


8.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 in-
   creasing 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 proto-
   col 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 fixed part;

     2.  the Network address part;

     3.  the Subnetwork address part, if present; and

     4.  the Options part, if present.

8.2   Fixed Part

8.2.1  General

   The fixed part contains frequently occurring parameters including the
   type code (ESH, ISH, or RD) of the protocol data unit.The length and
   the structure of the fixed part are defined by the PDU code.












ISO N4053                                                      [Page 26]

RFC 995                                                    December 1986


   The fixed part has the following format:

                                               Octet
      ________________________________________
      |    Network Layer Protocol Identifier |    1
      |______________________________________|
      |           Length Indicator           |    2
      |______________________________________|
      |      Version/Protocol Id Extension   |    3
      |______________________________________|
      |        reserved (must be zero)       |    4
      |______________________________________|
      | 0 |0 |0 |           Type             |    5
      |___|__|__|____________________________|
      |           Holding Time               |   6,7
      |______________________________________|
      |             Checksum                 |   8,9
      |______________________________________|

         Figure 1: PDU Header -- Fixed Part


8.2.2  Network Layer Protocol Identifier

   The value of this field shall be 1000 0010.

                     Temporary Note:
     The value 1000 0010 is provisional, pending resolution of the NLPID
     issue in SC6.

   This field identifies this Network Layer Protocol as ISO SC6/N4053,
   End System to Intermediate System Routing Exchange Protocol for use in
   conjunction with ISO 8473.

8.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 of the entire PDU
   (which consists entirely of header, since this protocol does not car-
   ry user data) in octets, as described in clause 8.1. The value 255
   (1111 1111) is reserved for possible future extensions.

8.2.4  Version/Protocol Identifier Extension

   The value of this field is binary 0000 0001. This identifies a stan-
   dard version of ISO xxxx, End System to Intermediate System Routing
   Exchange Protocol for use in conjunction with ISO 8473.







ISO N4053                                                      [Page 27]

RFC 995                                                    December 1986


8.2.5  Type Code

   The Type code field identifies the type of the protocol data unit.
   Allowed values are given in table 4.

   _____________________________________________________
   |            | Bits               5   4   3   2   1 |
   |____________|______________________________________|
   |____________|______________________________________|
   |ESH PDU     |                    0   0   0   1   0 |
   |____________|______________________________________|
   |ISH PDU     |                    0   0   1   0   0 |
   |____________|______________________________________|
   |RD PDU      |                    0   0   1   1   0 |
   |____________|______________________________________|

                   Table 4: Valid PDU Types

   All other PDU type values are reserved.

8.2.6  Holding Time

   The Holding Time field specifies for how long the receiving Network
   entity should retain the configuration/routing information contained
   in this PDU.  The receiving Network entity should discard any infor-
   mation obtained from this PDU from its internal state when the hold-
   ing time expires.  The Holding time field is encoded as an integral
   number of micro-fortnights.

8.2.7  PDU Checksum

   The checksum is computed on the entire PDU header. A checksum value
   of zero is reserved to indicate that the checksum is to be ignored.
   The operation of the PDU Header Error Detection function (Clause
   7.11) ensures that the value zero does not represent a valid check-
   sum. A non-zero value indicates that the checksum must be processed.
   If the checksum calculation fails, the PDU must be discarded.

8.3   Network Address Part

8.3.1  General

   Address parameters are distinguished by their location. The different
   PDU types carry different address parameters however.The ESH PDU car-
   ries a Source NSAP address (SA); the ISH PDU carries a Intermediate
   System Network entity Title (NET); and the RD PDU carries a Destina-
   tion NSAP address (DA), and possibly a Network Entity Title (NET).

8.3.2  NPAI (Network Protocol Address Information) Encoding

   The Destination and Source Addresses are Network Service Access Point



ISO N4053                                                      [Page 28]

RFC 995                                                    December 1986


   addresses as defined in ISO 8348/AD2, Addendum to the Network Service
   Definition Covering Network Layer addressing.The Network Entity Title
   address parameter is defined in clause 4.5. The Destination Address,
   Source Address, and Network Entity Title are encoded as NPAI using
   the binary syntax defined in clause 8.3.1 of ISO 8348/AD2.

   The address information is of variable length. Each address parameter
   is encoded as follows:

         _______________________________________________
         | Octet  | Address parameter Length Indicator |
         |   n    |                (e.g., 'm')         |
         |________|____________________________________|
         | Octets |                                    |
         | n + 1  |       Address Parameter Value      |
         |  thru  |                                    |
         | n + m  |                                    |
         |________|____________________________________|

                       Figure 2:  Address Parameters
8.3.3  Source Address Parameter for ESH PDU

   The Source Address is the NSAP address of an NSAP served by the Net-
   work entity sending the ESH PDU. It is encoded in the ESH PDU as fol-
   lows:


                                                   Octet
         ________________________________________
         |Source Address Length Indicator (SAL) |   10
         |______________________________________|
         |                                      |   11
         :           Source Address (SA)        :
         |                                      |  m - 1
         |______________________________________|

          Figure 3: ESH PDU - Network Address Part

8.3.4  Network Entity Title Parameter for ISH PDU

   The Network entity Title parameter is the Network Entity Title of the
   Intermediate System sending the ISH PDU. It is encoded in the ISH PDU
   as follows:











ISO N4053