rfc994.txt

RFC 相关的技术文档

RFC 994                                                    December 1986


5     Overview of the Protocol

5.1   Internal Organization of the Network Layer

   The architectural organization of the Network Layer is described in a
   separate document, Internal Organization of the Network Layer (ISO
   8648). ISO 8648 identifies and categorizes the way in which functions
   can be performed within the Network Layer by Network Layer protocols,
   thus providing a uniform framework for describing how protocols
   operating either individually or cooperatively in the Network Layer
   can be used to provide the OSI Network Service. This protocol is
   designed to be used in the context of the internetworking protocol
   approach to the provision of the Connectionless-mode Network Service
   defined in that Standard.

   This protocol is intended for use in the Subnetwork Independent Con-
   vergence Protocol (SNICP) role.  A protocol which fulfills the SNICP
   role operates to construct the OSI Network Service over a defined set
   of underlying services, performing functions which are necessary to
   support the uniform appearance of the OSI Connectionless-mode Network
   Service over a homogeneous or heterogeneous set of interconnected
   subnetworks.  This protocol is defined to accommodate variability
   where Subnetwork Dependent Convergence Protocols and/or Subnetwork
   Access Protocols do not provide all of the functions necessary to
   support the Connectionless-mode Network Service over all or part of
   the path from one NSAP to another.

   As described in ISO 8648, a protocol at the Network Layer may fulfill
   different roles in different configurations.  Although this protocol
   is designed particularly to be suitable for a SNICP role in the con-
   text of the internetworking protocol approach to the provision of the
   Connectionless-mode Network Service, it may also be used to fulfill
   other roles and may therefore be used in the context of other ap-
   proaches to subnetwork interconnection.

   The specification of this protocol begins with a definition of the
   underlying service which it assumes. This service is made available
   by the operation of other Network Layer protocols or through provi-
   sion of the Data Link Service. The underlying service assumed by this
   protocol is described in Clause 5.5.

5.2     Subsets of the Protocol

   Two proper subsets of the full protocol are defined which permit the
   use of known subnetwork characteristics and are therefore not subnet-
   work independent.

   The Inactive Network Layer protocol subset is a null-function subset
   which can be used when it is known that the source and destination
   end-systems are connected by a single subnetwork, and when none of
   the functions performed by the full protocol is required to provide



ISO 8473                                                       [Page 12]

RFC 994                                                    December 1986


   the Connectionless-mode Network Service between any pair of end-
   systems.

   The Non-segmenting protocol subset permits simplification of the
   header where it is known that the source and destination end-systems
   are connected by subnetworks whose service data unit sizes are
   greater than or equal to a known bound which is large enough so that
   segmentation is not required. This subset is selected by setting the
   Segmentation Permitted flag to zero.

5.3     Addresses and Titles

   The following Clauses describe the addresses and titles used by this
   Protocol.

5.3.1    Addresses

   The Source Address and Destination Address parameters referred to in
   Clause 7.3 of this International Standard are OSI Network Service Ac-
   cess Point Addresses.  The syntax and semantics of an OSI Network
   Service Access Point Address are described in a separate document,
   ISO 8348/AD2, Addendum to the Network Service Definition Covering
   Network Layer Addressing.

   The encoding used by this protocol to convey NSAP Addresses shall be
   the preferred binary encoding specified in ISO 8348/AD2; the entire
   NSAP address, taken as a whole, is represented explicitly as a string
   of binary octets.  This string is conveyed in its entirety in the ad-
   dress fields described in Clause 7.3. The rules governing the genera-
   tion of the preferred binary encoding are described in ISO 8348/AD2.

5.3.2    Network-entity Titles

   A network-entity title is an identifier for a network-entity in an
   endsystem or intermediate-system. Network-entity titles are allocated
   from the same name space as NSAP addresses, and the determination of
   whether an address is an NSAP address or a network-entity title
   depends on the context in which the address is interpreted. The en-
   tries in the Source Routing and Recording of Route parameters defined
   in Clauses 7.5.4 and 7.5.5 are network-entity titles. The Source Ad-
   dress and Destination Address parameters in the Error Report PDU de-
   fined in Clause 7.9.1.2 are also network-entity titles.

   The encoding used by this protocol to convey network-entity titles
   shall also be the preferred binary encoding; again, the entire
   network-entity title, taken as a whole, is represented explicitly as
   a string of binary octets.  This string is conveyed in its entirety
   in the fields described in Clauses 7.5.4, 7.5.5, and 7.9.1.2.






ISO 8473                                                       [Page 13]

RFC 994                                                    December 1986


5.4     Service Provided by the Network Layer

   The service provided by this protocol is the Connectionless-mode Net-
   work Service described in ISO 8348/AD1, Addendum to the Network Ser-
   vice Definition Covering Connectionless-mode Transmission.  The Net-
   work Service primitives provided are summarized in Table 1:

           _____________________________________________________________
          |             PRIMITIVES                    PARAMETERS        |
          |____________________________________________________________ |
          |  N_UNITDATA         .Request    |  N_Source_Address,        |
          |                     .Indication |  N_Destination_Address,   |
          |                                 |  N_Quality_of_Service,    |
          |                                 |  N_Userdata               |
          |_________________________________|___________________________|

               Table 1: Service Primitives for Underlying Service


   The Addendum to the Network Service Definition Covering
   Connectionless-mode Transmission (ISO 8348/AD1) states that the max-
   imum size of a connectionless-mode Network-service-data-unit (NSDU)
   is limited to 64512 octets.

5.5     Underlying Service Assumed by the Protocol

   The underlying service required to support this protocol is defined
   by the following primitives:

           _____________________________________________________________
          |             PRIMITIVES                    PARAMETERS        |
          |____________________________________________________________ |
          |  SN_UNITDATA        .Request    | SN_Source_Address,        |
          |                     .Indication | SN_Destination_Address,   |
          |                                 | SN_Quality_of_Service,    |
          |                                 | SN_Userdata               |
          |_________________________________|___________________________|

               Table 2: Service Primitives for Underlying Service


                                   Note:
   These service primitives are used to describe the abstract interface
   which exists between the ISO 8473 protocol machine and an underlying
   real subnetwork or a Subnetwork Dependent Convergence Function which
   operates over a real subnetwork or real data link to provide the
   required underlying service.







ISO 8473                                                       [Page 14]

RFC 994                                                    December 1986


5.5.1    Subnetwork Points of Attachment

   The source and destination addresses specify the points of attachment
   to a public or private subnetwork(s) involved in the transmission.
   Subnetwork Point of Attachment addresses (SNPAs) are defined by each
   individual subnetwork authority.

   The syntax and semantics of SNPAs are not defined in this Standard.

5.5.2    Subnetwork Quality of Service

   Subnetwork Quality of Service describes aspects of an underlying
   connectionless-mode service which are attributable solely to the
   underlying service.

   Associated with each connectionless-mode transmission, certain meas-
   ures of Quality of Service are requested when the primitive action is
   initiated.  These requested measures (or parameter values and op-
   tions) are based on a priori knowledge of the service(s) made avail-
   able to it by the subnetwork. Knowledge of the nature and type of
   service available is typically obtained prior to an invocation of the
   underlying connectionless-mode service.

   The Quality of Service parameters identified for the underlying
   connectionless-mode service may in some circumstances be directly
   derivable from or mappable onto those identified in the
   Connectionless-mode Network Service.  The following parameters as de-
   fined in ISO 8348/AD1, Addendum to the Network Service Definition
   Covering Connectionlessmode Transmission, may be employed:

     (a)  transit delay;

     (b)  protection against unauthorized access;

     (c)  cost determinants;

     (d)  priority; and

     (e)  residual error probability.


                                    Note:
        For those subnetworks which do not inherently provide Quality of
        Service as a parameter when the primitive action is initiated, it
        is a local matter as to how the semantics of the service requested
        might be preserved. In particular, there may be instances in which
        the Quality of Service requested cannot be maintained.  In such
        circumstances, an attempt shall be made to deliver the protocol
        data unit at whatever Quality of Service is available.





ISO 8473                                                       [Page 15]

RFC 994                                                    December 1986


5.5.3    Subnetwork User Data

   The SN-Userdata is an ordered multiple of octets, and is transferred
   transparently between the specified subnetwork points of attachment.

   The underlying service assumed by the CLNP is required to support a
   service data unit size of at least 512 octets.

   If the minimum service data unit sizes supported by all of the sub-
   networks involved in the transmission of a particular PDU are known
   to be large enough that segmentation is not required, then the Non-
   segmenting protocol subset may be used.


5.5.4    Subnetwork Dependent Convergence Functions

   Subnetwork Dependent Convergence Functions may be performed to pro-
   vide an underlying connectionless-mode service in the case where a
   real subnetwork does not inherently provide the connectionless-mode
   service assumed by the protocol.  If a subnetwork inherently provides
   a connection-mode service, a Subnetwork Dependent Convergence Func-
   tion provides a mapping into the required underlying service.  Sub-
   network Dependent Convergence Functions may also be required in those
   cases where functions assumed from the underlying service are not
   performed.  In some cases, this may require the operation of an ex-
   plicit protocol (i.e., a protocol involving explicit exchanges of
   protocol control information between peer network-entities) in the
   Subnetwork Dependent Convergence Protocol (SNDCP) role. However,
   there may also be cases where the functionality required to fulfill
   the SNDCP role consists simply of a set of rules for manipulating the
   underlying service.

5.6     Service Assumed from Local Environment

   A timer service must be provided to allow the protocol entity to
   schedule events.

   There are three primitives associated with the S-TIMER service:

      1.  the S--TIMER Request,
      2.  the S--TIMER Response, and
      3.  the S--TIMER Cancel.

   The S--TIMER Request primitive indicates to the local environment
   that it should initiate a timer of the specified name and subscript
   and maintain it for the duration specified by the time parameter.

   The S--TIMER Response primitive is initiated by the local environment
   to indicate that the delay requested by the corresponding S-TIMER Re-
   quest primitive has elapsed.




ISO 8473                                                       [Page 16]

RFC 994                                                    December 1986


   The S--TIMER Cancel primitive is an indication to the local environ-
   ment that the specified timer(s) should be canceled. If the subscript
   parameter is not specified, then all timers with the specified name
   are canceled; otherwise, the timer of the given name and subscript is
   cancelled.  If no timers correspond to the parameters specified, the
   local environment takes no action.

   The parameters of the S--TIMER service primitives are specified in
   Table 3.

               __________________________________________________
              |        PRIMITIVES               PARAMETERS      |
              |_________________________________________________|
              |    S--TIMER     .Request  |  S-Time,            |
              |                           |  S-Name,            |
              |                           |  S-Subscript        |
              |                           |                     |
              |                 .Response |  S-Name,            |
              |                           |  S-Subscript        |
              |___________________________|_____________________|

                        Table 3: Timer Primitives


   The time parameter indicates the time duration of the specified ti-
   mer.  An identifiying label is associated with a timer by means of
   the name parameter. The subscript parameter specifies a value to dis-