rfc995.txt

RFC 的详细文档！

 6.3   Addressing

   The Source Address and Destination Address parameters referred to in
   this International Standard are OSI Network Service Access Point Ad-
   dresses. The syntax and semantics of an OSI Network Service Access
   Point Address are described in a separate document, ISO 8348/DAD2,
   Addendum to the Network Service Definition covering Network Layer Ad-
   dressing.

6.4   Underlying Service Assumed by the Protocol

   The underlying service required to support this protocol is defined
   by the primitives in Table 1.

     _________________________________________________________________
     |    SN_UNITDATA          .Request    | SN_Destination_Address, |
     |                         .Indication | SN_Source_Address,      |
     |                                     | SN_Quality_of_Service,  |
     |                                     | SN_Userdata             |
     |_____________________________________|_________________________|

            Table 1: Service Primitives for Underlying Service



                             Note:
      These service primitives are used to describe the abstract interface
      which exists between the 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.

6.4.1  Subnetwork Addresses

   The source and destination addresses specify the points of attachment
   to a public or private subnetwork(s) involved in the transmission
   (known as Subnetwork Points of Attachment, or SNPAs).Subnetwork ad-
   dresses are defined in the Service Definition of each individual sub-
   network.  This protocol is designed to take advantage of subnetworks
   which support broadcast, multicast, or other forms of multi-



ISO N4053                                                      [Page 12]

RFC 995                                                    December 1986


   destination addressing for n-way transmission. It is assumed that the
   SN_Destination_Address parameter may take on one of the following
   multi-destination addresses in addition to a normal single destina-
   tion address:

     All End System Network entities

     All Intermediate System Network entities

   Where a real subnetwork does not inherently support broadcast or oth-
   er forms of transmission to multi-destination addresses, a conver-
   gence function may be used to provide n-way transmission to these
   multi-destination addresses.

   When the SN_Destination_Address on the SN_UNITDATA.Request is a
   multi-destination address, the SN_Destination_Address parameter in
   the corresponding SN_UNITDATA.Indication shall be the same multi-
   destination address.

   The syntax and semantics of subnetwork addresses, except for the pro-
   perties described above, are not defined in this Protocol Standard.

6.4.2  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 is required to support a service data unit
   size of at least that required to operate the Protocol for Providing
   the Connectionless Network Service (ISO 8473).

6.5   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.

   The S--TIMER Cancel primitive is an indication to the local environ-



ISO N4053                                                      [Page 13]

RFC 995                                                    December 1986


   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 2.

          ___________________________________________
         |                          |               |
         | S--TIMER     .Request    | S-Time,       |
         |                          | S-Name,       |
         |                          | S-Subscript   |
         |                          |               |
         |              .Response   | S-Name,       |
         |                          | S-Subscript   |
         |__________________________|_______________|

                  Table 2: 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-
   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.

6.6   Subnetwork Types

   In order to evaluate the applicability of this protocol in particular
   configurations of End Systems, Intermediate Systems and subnetworks,
   three generic types of subnetwork are identified. These are:

     1.  the point-to-point subnetwork,

     2.  the broadcast subnetwork, and

     3.  the general topology subnetwork

    These subnetwork types are discussed in the following clauses.




ISO N4053                                                      [Page 14]

RFC 995                                                    December 1986


6.6.1  Point-to-Point Subnetworks

   A point-to-point subnetwork supports exactly two systems. The two
   systems may be either two End Systems, or an End System and a single
   Intermediate System. A single point-to-point data link connecting two
   Network Entities is an example of a point-to-point subnetwork.


   Configuration Information on a point-to-point Subnetwork.On a point-
   to-point subnetwork the Configuration Information of this protocol
   informs the communicating Network entities of the following:

     1.  Whether the topology consists only of two End Systems, or

     2.  One of the two systems is a Intermediate System.

                           Note:
     On a point-to-point subnetwork, if both systems are Intermediate Systems,
     then this protocol is inapplicable to the situation, since a IS-to-IS
     protocol should be employed instead. However, there is no reason why
     the configuration information could not be employed in a IS-to-IS
     environment to ascertain the topology and initiate operation of a
     IS-to-IS protocol.

   The Intermediate System is informed of the NSAP address(es) supported
   by the Network entity in the End System. This permits reachability
   information and routing metrics concerning these NSAPs to be dissem-
   inated to other Intermediate Systems for the purpose of calculating
   routes to/from this End System.

   Route Redirection Information on a point-to-point Subnetwork.  Route
   Redirection Information is not employed on point-to-point subnetworks
   because there are never any alternate routes.

6.6.2  Broadcast Subnetworks

   A Broadcast subnetwork supports an arbitrary number of End Systems
   and Intermediate Systems, and additionally is capable of transmitting
   a single SNPDU to all or a subset of these systems in response to a
   single SN_UNITDATA.Request.An example of a broadcast subnetwork is a
   LAN (local area network) conforming to DIS8802/2, type 1 operation.


   Configuration Information on a broadcast Subnetwork.On a broadcast
   subnetwork the Configuration Information of this protocol is employed
   to inform the communicating Network entities of the following:

     1.  End Systems are informed of the reachability, Network entity Title,
         and SNPA address(es) of each active Intermediate System on the
         subnetwork.




ISO N4053                                                      [Page 15]

RFC 995                                                    December 1986


     2.  Intermediate Systems are informed of the NSAP addresses supported
         by each End System and the Subnetwork address of the ES. Once the
         Intermediate System obtains this information, reachability
         information and routing metrics concerning these NSAPs may be
         disseminated to other ISs for the purpose of calculating routes
         to/from each ES on the subnetwork.

     3.  In the absence of an available Intermediate System, End Systems may
         query over a broadcast subnetwork to discover whether a particular
         NSAP is reachable on the subnetwork, and if so, what SNPA address
         to use to reach that NSAP.

   Route Redirection Information on broadcast Subnetworks.Route Redirec-
   tion Information may be employed on broadcast subnetworks to permit
   Intermediate Systems to inform End Systems of superior routes to a
   destination NSAP. The superior route might be another IS on the same
   subnetwork as the ES, or it might be the destination ES itself, if it
   is directly reachable on the same subnetwork as the source ES.

6.6.3  General Topology Subnetworks

   A general topology subnetwork supports an arbitrary number of End
   Systems and Intermediate Systems, but does not support a convenient
   multidestination connectionless transmission facility as does a
   broadcast subnetwork.An example of a general topology subnetwork is a
   subnetwork employing X.25 or ISO 8208.

                                 Note:
     The crucial distinguishing characteristic between the broadcast
     subnetwork and the general topology subnetwork is the "cost" of an
     n-way transmission to a potentially large subset of the systems on
     the subnetwork. On a general topology subnetwork, the cost is assumed
     to be close to the cost of sending an individual PDU to each SNPA on
     the subnetwork.  Conversely, on a broadcast subnetwork the cost is
     assumed to be close to the cost of sending a single PDU to one SNPA
     on the subnetwork.  Intermediate situations between these extremes
     are of course possible. In such cases it would be possible to treat the
     subnetwork as either in the broadcast or general topology categories.

   Configuration Information on a general topology Subnetwork.  On a
   general topology subnetwork the Configuration Information is general-
   ly not employed because this protocol can be very costly in the util-
   ization (and charging for) subnetwork resources.


   Route Redirection Information on a general topology Subnetwork.
   Route Redirection Information may be employed on general topology
   subnetworks to permit Intermediate Systems to inform End Systems of
   superior routes to a destination NSAP. The superior route might be
   another IS on the same subnetwork as the ES, or it might be the des-
   tination ES itself, if it is directly reachable on the same subnet-



ISO N4053                                                      [Page 16]

RFC 995                                                    December 1986


   work as the source ES.