rfc926.txt

RFC 的详细文档！

RFC 926                                                    December 1984


  5.5.1  Subnetwork Addresses

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

   The syntax and semantics of subnetwork addresses are not defined in
   this Protocol Standard.

  5.5.2  Subnetwork Quality of Service

   Subnetwork Quality of Service describes aspects of a subnetwork
   connectionless-mode service which are attributable solely to the
   subnetwork service provider.

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

    Note:

     The quality of service parameters identified for the subnetwork
     connectionless-mode service may in some circumstances be directly
     derivable from or mappable onto those identified in the
     connectionless-mode Network Service; e.g., the parameters

      a)  transit delay;
      b)  protection against unauthorized access;
      c)  cost determinants;
      d)  priority; and
      e)  residual error probability

     as defined in ISO 8348/DAD1, Addendum to the Network Service
     Definition Covering Connectionless-mode Transmission, may be
     employed.








ISO DIS 8473 (May 1984)                                        [Page 12]





RFC 926                                                    December 1984


     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, the subnetwork service provider shall attempt to
     deliver the protocol data unit at whatever Quality of Service is
     available.

  5.5.3  Subnetwork User Data

   The SN_Userdata is an ordered multiple of octets, and is transferred
   transparently between the specified subnetwork service access points.

   The subnetwork service is required to support a subnetwork service
   data unit size of at least the maximum size of the Data PDU header
   plus one octet of NS-Userdata. This requires a minimum subnetwork
   service data unit size of 256 octets.

   Where the subnetwork service can support a subnetwork service data
   unit (SNSDU) size greater than the size of the Data PDU header plus
   one octet of NS_Userdata, the protocol may take advantage of this. In
   particular, if all SNSDU sizes of the subnetworks involved 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
   provide a connectionless-mode subnetwork service in the case where
   subnetworks also provide a connection-oriented subnetwork service. If
   a subnetwork provides a connection-oriented service, some subnetwork
   dependent function is assumed to provide a mapping into the required
   subnetwork service described in the preceding text.

   A Subnetwork Dependent Convergence Protocol may also be employed in
   those cases where functions assumed from the subnetwork service
   provider are not performed.











ISO DIS 8473 (May 1984)                                        [Page 13]





RFC 926                                                    December 1984


 5.6  Service Assumed from Local Evironment

  A timer service is 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
  request primitive has elapsed.

  The S_TIMER cancel primitive is an indication to the local environment
  that the specified timer(s) should be cancelled. If the subscript
  parameter is not specified, then all timers with the specified name
  are cancelled; 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:




















ISO DIS 8473 (May 1984)                                        [Page 14]





RFC 926                                                    December 1984


            Primitives                  Parameters             
      +--------------------------------------------------------+ 
      |                           |                            | 
      | S_TIMER Request           | S_Time                     | 
      |                           | S_Name                     | 
      |                           | S_Subscript                | 
      |                           |                            | 
      | S_TIMER Response          | S_Name                     | 
      |         Cancel            | S_Subscript                | 
      +--------------------------------------------------------+ 

                      Table 5-3.  Timer Primitives

  The time parameter indicates the time duration of the specified timer.
  An identifying label is associated with a timer by means of the name
  parameter. The subscript parameter specifies a value to distinguish
  timers with the same name. The name and subscript taken together
  constitute a unique reference to the timer.































ISO DIS 8473 (May 1984)                                        [Page 15]





RFC 926                                                    December 1984


SECTION TWO.  SPECIFICATION OF THE PROTOCOL

6  PROTOCOL FUNCTIONS

 This section describes the functions performed as part of the Protocol.

 Not all of the functions must be performed by every implementation.
 Section 6.17 specifies which functions may be omitted and the correct
 behavior where 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 of protocol given in Section 7. Protocol
  Control Information required for delivering the data unit to its
  destination is determined from current state information and from the
  parameters provided with the N_UNITDATA Request; e.g., source and
  destination addresses, QOS, etc. User data passed from the Network
  Service user in the N_UNITDATA Request forms the Data field of the
  protocol data unit.

  During the composition of the protocol data unit, a Data Unit
  Identifier is assigned to identify uniquely all segments of the
  corresponding NS_Userdata. The "Reassemble PDU" function considers
  PDUs to correspond to the same Initial PDU, and hence N_UNITDATA
  request, if they have the same Source and Destination Addresses and
  Data Unit Identifier.

  The Data Unit Identifier is available for ancillary functions such as
  error reporting. The originator of the PDU must choose the Data Unit
  Identifier so that it remains unique (for this Source and Destination
  Address pair) for the maximum lifetime of the PDU (or any Derived
  PDUs) in the network.
















ISO DIS 8473 (May 1984)                                        [Page 16]





RFC 926                                                    December 1984


  During the composition of the PDU, a value of the total length of the
  PDU 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.

  Where the non-segmenting subset is employed, neither the Total Length
  field nor the Data Unit Identifier field is present. During the
  composition of the protocol data unit, a value of the total length of
  the PDU 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.

 6.2  PDU Decomposition Function

  This function is responsible for removing the Protocol Control
  Information from the protocol data unit. During this process,
  information pertinent to the generation of the N_UNITDATA Indication
  is retained. The data field of the PDU received is reserved until all
  segments of the original service data unit have been received; this is
  the NS_Userdata 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
  indicating that this is a standard version of the Protocol, this
  function determines whether a PDU received has reached its destination
  using the destination address provided in the PDU is the same as the
  one which addresses 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
  indicating that the Inactive Network Layer Protocol subset is in use,
  then no further analysis of the PDU header is required. The














ISO DIS 8473 (May 1984)                                        [Page 17]





RFC 926                                                    December 1984


  network-entity in this case determines that either the network address
  encoded in the network protocol address information of a supporting
  subnetwork protocol corresponds to a network Service Access Point
  address served by this network-entity, or that an error has occurred.
  If the subnetwork PDU has been delivered correctly, then the protocol
  data unit may be decomposed according to the procedure described for
  that particular subnetwork protocol.

 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 whether
  its assigned lifetime has expired, in which case it must be discarded.

  The operation of the 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
  Milliseconds). The Lifetime of the Initial PDU is determined by the
  originating network-entity, and placed in the Lifetime field of the
  PDU.

 6.5  Route PDU Function

  This function determines the network-entity to which a protocol data
  unit should be forwarded, using the destination NSAP address
  parameters, Quality of Service parameter, and/or other parameters. It
  determines the subnetwork which must be transited to reach that
  network-entity. Where segmentation occurs, it further determines which
  subnetwork(s) the segments may transit to reach that network-entity.



















ISO DIS 8473 (May 1984)                                        [Page 18]





RFC 926                                                    December 1984


 6.6  Forward PDU Function

  This function issues a subnetwork service primitive (see Section 5.5)
  supplying the subnetwork identified by the "Route PDU" function with
  the protocol data unit as an SNSDU, and the address information
  required by that subnetwork to identify the "next" intermediate-system
  within the subnetwork-specific address domain.

  When an Error Report PDU is to be forwarded, and is longer than the
  maximum user data acceptable by the subnetwork, it shall be truncated
  to the maximum acceptable length ad forwarded with no other change.
  When a Data PDU is to be forwarded ad is longer than the maximum user
  data acceptable by the subnetwork, the Segmentation function is
  applied (See Section 6.7, which follows).

 6.7  Segmentation Function

  Segmentation is performed when the size of the protocol data unit is
  greater than the maximum size of the user data parameter field of the
  subnetwork service primitive.

  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. The Protocol Control Information required to
  identify, route, and forward a PDU is duplicated in each PDU derived
  from the Initial PDU. The user data encapsulated within the PDU
  received is divided such that the Derived PDUs satisfy the size
  requirements of the user data parameter field of the subnetwork
  service primitive.

  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.