rfc2216.txt

RFC 的详细文档！

   not. The specific treatment accorded nonconforming packets is not
   specified in this definition; common actions are relegating the
   packet to best effort service, discarding the packet, or marking the
   packet in some fashion.

  o Admission Control

   Admission control is the process of deciding whether a newly arriving
   request for service from a network element can be granted. This
   action must be performed by any service which wishes to offer
   absolute quantitative bounds on overall performance. It is not
   necessary for services which provide only relative statements about
   performance, such as the Internet's current best-effort service. The
   precise criteria for making the admission control decision are a
   specific to each particular service.

 o Policing

   Policing is the set of actions triggered when a flow's actual data
   traffic characteristics exceed the expected values given in the
   flow's traffic specification. Services which require policing
   functions to operate correctly must specify both the action to be






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


   taken when such discrepancies occur and the locations in the network
   where discrepancies are to be detected.  Examples of such actions
   might include relegating the packet to best effort service, dropping
   packets, reshaping the traffic, or marking non-conforming traffic in
   some fashion.

  o Interfaces

   The service module conceptually interacts with other portions of the
   network element through a number of interfaces.  The service
   specification document should clearly define the specific data,
   including formats, which moves across each conceptual interface, and
   ensure that the mapping between conceptual interfaces and the
   specific mechanisms of the service being defined are clear.

 Data Format and Representation

   A service module will import and export a variety of data according
   to the specific requirements of the services the network element
   supports. Each service definition MUST specify the format of each
   such data item in an abstract manner. The information specified must
   be sufficient for the designer of a setup protocol to correctly
   select an appropriate concrete (packet) format for variables
   containing this data. At minimum, the following information must be
   given:

     - Type: whether the quantity is an enumeration, a numerical value,
     etc.

     - Range: for numerical quantities, the minimum and maximum values
     the quantity must be able to represent. For enumerated quantities,
     an estimate of the maximum number of items which may need be
     enumerated in the future, even if many of the values are currently
     unused.

     - Precision: the precision with which a numerical quantity must be
     represented, and whether that precision is absolute (calling for an
     integer quantity) or a percentage of the value (allowing for a
     floating point quantity).

   The service definition SHOULD additionally specify a preferred
   concrete format for each data field, in the usual packet-layout
   format used in current Internet Standard documents or in some other
   accepted specification format. If the service definition contains
   these concrete definitions, they should be sufficiently complete and
   detailed to allow the service definition to be incorporated by
   reference into the specifications for setup protocols and other users
   of the specified data.



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


      NOTE: The wording above is intended to encourage the use of common
      data formats by all protocols carrying data related to a specific
      service, while not mandating this common format or infringing on
      the freedom of protocol specification designers to define data
      representations using alternative mechanisms such as ASN.1 or XDR.

Service and Data Element Naming

   End-nodes, network elements, setup protocols, and management entities
   within an integrated services internetwork need to exchange
   information about services, service invocation parameters,
   characterization parameters, and the intermediate variables and end
   results of composition functions.  To support this requirement, a
   single uniform namespace is established for services and their
   parameters.

   The namespace is a two-level hierarchy:

     <service_name>.<parameter_name>.

   Each of these elements is a integer numerical quantity.

   <Service Name> is an integer in the range 1 to 254. The number space
   is broken into three regions.

   Service number 1 is used to indicate that the associated parameter is
   generic", and is not associated with a specific service. This use of
   generic parameters is described more fully in [RFC 2215].

   The range from 2 to 127 used to name services defined by the IETF.
   Procedures for allocating service numbers in this region will be
   established by the IETF INT-SERV WG and the IANA. Services designed
   for public use should obtain a number from this space. The minimum
   requirement for doing so is a published RFC following the format
   described in this note.

   Service numbers in the region above 127 are reserved for experimental
   or private services. Service designers may allocate numbers from this
   space at random for local experimental use. A policy for global but
   temporary allocation of these numbers may be established in the
   future if necessary.

   The value 0 is left unused to allow the direct mapping of parameter
   names to MIB object names, as described below.

   The value 255 is reserved to facilitate future expansion of the
   service number space, if required.




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


   <Parameter_name> is a number in the range 1 to 254, allocated on a
   per-service basis.  Within this range, the values 1 to 127 are
   reserved for assignment to parameters with a common, shared meaning
   across all services. These parameters are defined in [RFC 2215].

   Numbers for parameters specific to a service are assigned from the
   range 128-254 by the author of the service specification document.

   The value 0 is left unused to allow the direct mapping of parameter
   names to MIB object names, as described below.

   The value 255 is reserved to facilitate future expansion of the
   parameter number space, if required.

   In addition to their uses within the integrated services framework,
   these <service_number>.<parameter_number> pairs should be used as
   last two levels of the MIB name when the corresponding values are
   made available to network management protocols.

Specification Document Format

   The following portion of this document describes the layout and
   contents of a service specification. Each service specification
   document MUST contain the sections marked [required] below, in the
   order listed. Each document SHOULD contain each of the remaining
   sections in the list below, unless there is a compelling argument
   that the presence of the section is not beneficial. Additional
   material, including references, should be included at the end of the
   document.

   Some of these sections are normative, in that they describe specific
   requirements to which conformant implementations must adhere.  Other
   sections are informational in nature, in that they describe necessary
   context and technical considerations important to the implementor of
   a service. The sections, and their nature (required or optional, and
   informational or normative) are listed below:

 o Components

   The body of a service specification document incorporates the
   following sections:

     - End-to-End Behavior [required] [informational]

     - Motivation [required]  [informational]

     - Network Element Data Handling Requirements [required] [normative]




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


     - Invocation Information [required] [normative]

     - Exported Information [required] [normative]

     - Policing [required] [normative]

     - Ordering and Merging [required] [normative]

     - Guidelines for Implementors  [optional] [informational]

     - Evaluation Criteria [required] [informational]

     - Examples of Implementation [optional] [informational]

     - Examples of Use [optional] [informational]

 o End-to-end Behavior

   This is a description of the behavior that results if all network
   elements along the path offer the same service, invoked with a
   defined set of parameters.

   In private networks it will generally be the case that the required
   end-to-end behavior is obtained by concatenation of network elements
   utilizing the same service and making significant use of
   characterizations.

   In the global Internet, this will not always be true. End-to-end
   behaviors will frequently be obtained through a concatenation of
   network elements supporting different services, including in some
   cases elements which exercise no QoS control at all. Mechanisms to
   characterize end-to-end behavior in this circumstance are not fully
   established at this time. Future versions of this document may impose
   additional requirements on service specifications to facilitate
   inter-service composition.

   This section is for informational purposes only.

 o Motivation

   This section discusses why this service is being defined. It
   describes what kinds of applications might make use of this service,
   and why this service might be more appropriate for those applications
   than other possible choices. This section is for informational
   purposes only.






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


 o Network Element Data Handling Requirements

   This section contains a description of the QoS properties seen by
   data packets processed by a network element using this service. The
   description must clearly explain what variables are controlled, the
   degree of control exercised, and what aspects of the service's
   handling model are fixed or assumed. Examples of degree of control
   information include "this property must be mathematically assured"
   and "this property should be met under most conditions". An example
   of a stated assumption is "this service is assumed to have extremely
   low packet loss; delay targets must be met using admission control
   rather than by discarding packets when overloaded".

   Requirements on packet handling SHOULD, when at all possible, be
   expressed as performance requirements rather than by specifying a a
   particular packet scheduling algorithm. The performance requirements
   might, for example, be a specification of the maximal packet delays
   or the minimal bandwidth share given to a flow.

   This section also specifies actions which the packet handling path is
   required to take to actively provide feedback to end-nodes about
   conditions at the network element. Such actions might include
   explicitly generated congestion feedback, indicated either as bits
   set in the header of data packets or separate control messages sent.

   When writing this section of the service specification document, the
   authors' goal should be to specify the required behavior as precisely
   as necessary while still leaving adequate room for the implementation
   and architectural tradeoffs appropriate to different circumstances
   and classes of network elements. Successfully achieving this balance
   may require some care.

 o Invocation Information

   This section describes the set of parameters required by a service
   module to invoke the service, and a description of how the parameter
   values are used by the service module.  For example, a hypothetical
   "bounded delay" service might be described as accepting a request
   indicating a delay target for the network element and the set of
   packets subject to that delay target, and processing packets in the
   given set with a delay of the target value or less.

   Necessary invocation information for most services can be broken into
   two parts, the Traffic Specification (TSpec) and the Service Request
   Specification (RSpec). The TSpec gives characteristics of the data






Shenker & Wroclawski         Informational                     [Page 11]