rfc2216.txt

RFC 的详细文档！


RFC 2216            Network Element Service Template      September 1997


   traffic to be handled, while the Rspec specifies the properties
   desired from the service. For example, a service offering a
   mathematical bound on delay might accept a TSpec giving the traffic
   flow's bandwidth and burstiness specified as a Token Bucket, and an
   RSpec giving the maximum tolerable queueing delay.

   A service accepting an invocation request may be thought of as
   entering into a "contract" to provide the service described by the
   RSpec as long as the flow's traffic continues to be described by the
   TSpec. If the flow's traffic pattern falls outside the bounds of the
   TSpec, the QoS provided to the flow may change. The precise nature of
   this change is also described by the service specification (see
   "Policing" below).

   The RSPec and TSpec components of the invocation information should
   be specified separately and independently, as they will often be
   generated by different elements of the internetwork

   All quantitative information specifications in this section should
   follow the guidelines given in the Data Formats section of this
   document, above.

 o Exported Information and Characterization Parameters

   This section describes information which must be collected and
   exported by the service module. Exported information is available to
   other modules of the network element, and by extension to setup
   protocols, routing protocols, network management tools, and the like.

   Information exported by service modules may be used in several ways.
   For example, quantities such as the amount of link bandwidth
   dedicated to the service and the set of data flows currently
   receiving the service are appropriate pieces of information to make
   available as network management variables.

   A service definition may identify a particular subset of the
   information exported by a service module as characterization
   parameters. These characterization parameters may be used to compute
   or estimate the end-to-end behavior of a data flow traversing a
   concatenation of network service elements. They may also be used to
   characterize portions of the path for use by network elements (e.g.,
   in computing the buffer necessary, an element may need to know
   something about the service characteristics of the upstream portion
   of the path). A service which defines characterization parameters
   also specifies the characterizations they are used to generate and
   the composition functions used to generate the characterizations.





Shenker & Wroclawski         Informational                     [Page 12]

RFC 2216            Network Element Service Template      September 1997


      NOTE: Characterization parameters are identified as such by virtue
      of being the inputs to a service's defined composition functions.
      Because characterization parameters are part of a service's
      overall exported data set, they are also available to other
      functions, such as network management. The discussion below
      relates solely to their use as characterization parameters, and is
      not intended to limit other uses.

   Characterization parameters may be relatively static quantities, such
   as the bandwidth available on a specific link, or relatively dynamic
   quantities, such as a running estimation of current packet delay.

   Support for a service's defined characterization parameters is
   mandatory. Any network element offering this service must be able to
   measure, compute, or, if allowed by the specification, estimate the
   service's characterization parameters. Service designers are
   encouraged to understand the implications of specifying
   characterization parameters for a service, particularly with respect
   to not unduly restricting the choice of hardware and software
   architectures used to implement the network element.

   Characterization parameters are used by composing the values exported
   by each network element along a data flow's path according to a
   composition rule. For each parameter or set of parameters used to
   develop a characterization, the service specification must specify
   the composition rule to be used. These composition rules should
   result in characterizations that are independent of the order in
   which the element are composed; commutativity and associativity are
   sufficient but not necessary conditions for this.

   Characterization parameters are available through a general
   interface, and are provided in response to a request from some other
   module, such as a setup protocol or the routing protocol. The
   question of exactly how, or if, a specific protocol (e.g., RSVP) uses
   characterization parameters to generate characterizations is
   described in the specification of that specific protocol.

   The correct use of characterization parameters supplied by service
   modules is a function of the setup, routing, or management protocol
   controlling the module. There is no absolute guarantee that
   characterizations will be available to end-nodes desiring to use a

   QoS control service. Service designers targeting services for the
   global Internet may wish to ensure that a service is useful even in
   the absence of characterizations, and to exhibit such uses in the
   "Examples" sections of the service description document.





Shenker & Wroclawski         Informational                     [Page 13]

RFC 2216            Network Element Service Template      September 1997


   Conversely, the availability of characterizations may be mandatory in
   certain circumstances, particularly for private IP networks providing
   tightly controlled qualities of service for specific applications.
   Service designers targeting this environment should particularly
   ensure that the service provides adequate characterization parameters
   and composition functions to meet the needs of target audiences. It
   may be appropriate to specify the same basic service with additional
   characterizations for meeting specific requirements beyond those of
   the global Internet.

   Some useful "general" characterization parameters and corresponding
   composition rules are not associated with any specific service.
   These include the speed-of-light latency of communication links and
   available link bandwidth. These general characterization parameters
   are defined in [RFC 2215].

   Although every conformant implementation of a service is required to
   provide that service's characterization parameters, it is still
   possible that the desired characterization parameters will not be
   available for composition at all network elements in a path. This
   situation may arise when different network element services are used
   at different points in the end-to-end path, as may be required in a
   heterogeneous internetworking environment. For this reason,
   characterization parameters and composition function results
   conceptually include a "validity flag". A network element which is
   unable to provide the characterization parameter must set this flag,
   and otherwise leave parameter or composed value unchanged. Once set,
   the flag is preserved by the composition function, and serves as an
   indicator of the validity of the data when the final composed result
   is delivered to its destination.

   Protocols which transport characterization parameters and composition
   data must define and support a concrete representation for this
   validity flag, as well as for the characterization parameters
   themselves.

   NOTE: This service specification template does not allow a service
   definition to *require* that a setup or invocation mechanism used
   with the service perform any function other than transport of
   invocation parameters to the network elements and signalling of
   errors generated by the network elements to the end nodes. A notable
   example of this is that service specification documents may not
   require or assume that characterizations defined in the specification
   are actually computed or presented to the end nodes.

   That point notwithstanding, the practical usefulness of a specific
   service may be highly dependent on the presence of some additional
   behavior in the networked system, such as the computation and



Shenker & Wroclawski         Informational                     [Page 14]

RFC 2216            Network Element Service Template      September 1997


   presentation of characterizations to end-nodes or the reliable
   assurance that every network element in the path from sender to
   receivers supports the given service. Service specification authors
   are strongly encouraged to clearly explain the situation of their
   service in this regard. Statements such as:

      The characterizations defined by this service serve as useful
      hints to the application. However, the service is specifically
      intended to be useful even if characterizations are not available.

   or

      The usefulness of this service depends strongly on the delivery of
      both characterizations and the knowledge that all network elements
      on the path support the service. Requests for this service when
      characterizations are not available are likely to lead to
      incorrect or misleading results.

   are appropriate. It may also be useful to consider this point in the
   "Examples of Use" section described below.

   NOTE: The possibility of modifying the overall architecture to
   provide information about the invoking protocol in a service request,
   and to allow a service to require that the invocation protocol
   support specific additional functionality, is an area of active
   study.

 o Policing

   This portion of the service description describes the nature of
   policing used to enforce adherence to a flow's Traffic Specification.
   The specification document must specify the following points

     - Expected policing action. This is the action taken when packets
     not conforming to the TSpec are detected.  Example actions include
     relegating nonconforming packets to best effort, immediately
     dropping nonconforming packets, delaying these packets until they
     once again "fit" into the TSpec, or "marking" nonconforming packets
     in some way.

     - Legality of alternative policing actions. The section must
     specify whether actions not specifically mentioned in
     specification's description of policing behavior are legal. For
     example, a service description which specifies that nonconforming
     packets are to be dropped should state whether an alternate action,
     such as delaying these packets, is acceptable.





Shenker & Wroclawski         Informational                     [Page 15]

RFC 2216            Network Element Service Template      September 1997


     - Location of policing actions in the internetwork. The description
     of policing must specify where that policing is done. Possibilities
     include "at the edges of the network only", "at every hop",
     "heterogeneous branch points" (points where the branches of a
     multicast tree converge and have different TSpecs reserved
     downstream), and "source merge points" (points where multiple data
     streams covered by a single resource reservation converge). The
     specification should clearly state requirements about topology
     information (for example "this is an edge node" or "this is a
     source merge point") which must be available from the setup
     protocol or another source.

     In this section the specification should also specify the legality
     of policing at additional points in the network, beyond those
     listed above.  This is important due to technical effects such as
     are described in the next paragraph.

     Applicable additional technical considerations. If policing of data
     flows is required or legal at points other than the flow's first
     entry into the network, the service definition should describe any
     additional technical considerations which affect the design of such
     policing. For example, many potential services will allow a data
     flow to become more bursty as it progresses through the network. If
     such a service allows policing at points other than the network
     edge, the traffic specification describing the flow will have to be
     modified from that given by the application to the network to
     account for this growing burstiness. Otherwise, it is likely that
     the flow will be overpoliced, with packets being penalized
     unnecessarily.

 o Ordering and Merging

   Ordering and merging come into play when a network element receives
   several invocation requests covering the same data flow. As examples,
   this could occur if several receivers of a multicast data flow
   requested QoS services for that flow using the RSVP setup protocol,
   or if a flow was subject to both a statically installed permanent
   invocation request and a dynamic request from a resource setup
   protocol.

   In this situation the service module must be able to answer questions
   about the ordering between different invocation requests, and must be
   able to generate a single new invocation request which meets the
   semantics of the setup protocol and the requirements of all the
   original requesters. Operationally, this is achieved by having the
   invoking protocol ask the service module, given a set of invocation
   requests I1...In, to compute a new request which results in the
   desired behavior.



Shenker & Wroclawski         Informational                     [Page 16]

RFC 2216            Network Element Service Template      September 1997


   Five operations must be defined in this section. These are:

     - Ordering. The section must define an ordering relationship
     between the service's TSpecs and RSpecs. This may be a partial
     ordering, in that some TSpecs or RSpecs may be unordered with
     respect to each other.

     - Summation. This function computes an invocation request which
     represents the sum of N input invocation requests. Typically this
     function is used to compute the size of a service request adequate
     for a shared reservation for N different flows. It is desirable but
     not required that this function compute the "least possible sum".

     - Minimum. This function computes the minimum of two TSpecs.
     Typically this function is used to compute the TSpec for an actual
     service invocation given a target TSpec for the service request and
     a TSpec for the flow's actual traffic pattern. The minimum function
     must compute the smallest TSpec adequate to describe the minimum of
     the requested TSpec and the flow's actual traffic.

     - RSVP-Merge function. This function computes the invocation
     request used to request service at an RSVP [RFC 2205] merge point.
     The function must a) compute an appropriate invocation request for
     a set of downstream reservations being merged, and b) generate
     appropriate reservation parameters to be passed upstream by RSVP.