rfc2215.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        S. Shenker
Request for Comments: 2215                                J. Wroclawski
Category: Standards Track                            Xerox PARC/MIT LCS
                                                         September 1997


                General Characterization Parameters for
                  Integrated Service Network Elements


Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo defines a set of general control and characterization
   parameters for network elements supporting the IETF integrated
   services QoS control framework. General parameters are those with
   common, shared definitions across all QoS control services.

1. Introduction

   This memo defines the set of general control and characterization
   parameters used by network elements supporting the integrated
   services framework.  "General" means that the parameter has a common
   definition and shared meaning across all QoS control services.

   Control parameters are used by applications to provide information to
   the network related to QoS control requests. An example is the
   traffic specification (TSpec) generated by application senders and
   receivers.

   Characterization parameters are used to discover or characterize the
   QoS management environment along the path of a packet flow requesting
   active end-to-end QoS control.  These characterizations may
   eventually be used by the application requesting QoS control, or by
   other network elements along the path. Examples include information
   about which QoS control services are available along a network path
   and estimates of the available path bandwidth.

   Individual QoS control service specifications may refer to these
   parameter definitions as well as defining additional parameters
   specific to the needs of that service.



Shenker & Wroclawski        Standards Track                     [Page 1]

RFC 2215          General Characterization Parameters     September 1997


   Parameters are assigned machine-oriented ID's using a method
   described in [RFC 2216] and summarized here.  These ID's may be used
   within protocol messages (e.g., as described in [RFC 2210]) or
   management interfaces to describe the parameter values present. Each
   parameter ID is composed from two numerical fields, one identifying
   the service associated with the parameter (the <service_number>), and
   the other (the <parameter_number>) identifying the parameter itself.
   Because the definitions of the parameters defined in this note are
   common to all QoS control services, the <parameter_number> values for
   the parameters defined here are assigned from the "general
   parameters" range (1 - 127).

      NOTE: <parameter_numbers> in the range 128 - 254 name parameters
      with definitions specific to a particular QoS control service. In
      contrast to the general parameters described here, it is necessary
      to consider both the <service_number> and <parameter_number> to
      determine the meaning of the parameter.

      Service number 1 is reserved for use as described in Section 2 of
      this note. Service numbers 2 through 254 will be allocated to
      individual QoS control services. Currently, Guaranteed service
      [RFC 2212] is allocated number 2, and Controlled-load service [RFC
      2211] is allocated number 5.

   In this note, the textual form

                    <service_number, parameter_number>

   is used to write a service_number, parameter_number pair.  The range
   of possible of service_number and parameter_number values specified
   in [RFC 2216] allow the parameter ID to directly form the tail
   portion of a MIB object ID representing the parameter. This
   simplifies the task of making parameter values available to network
   management applications.

   The definition of each parameter used to characterize a path through
   the network describes two types of values; local and composed.  A
   Local value gives information about a single network element.
   Composed values reflect the running composition of local values along
   a path, specified by some composition rule.  Each parameter
   definition specifies the composition rule for that parameter. The
   composition rule tells how to combine an incoming composed value
   (from the already-traversed portion of the path) and the local value,
   to give a new composed value which is passed to the next network
   element in the path. Note that the composition may proceed either






Shenker & Wroclawski        Standards Track                     [Page 2]

RFC 2215          General Characterization Parameters     September 1997


   downstream, toward the receiver(s), or upstream, toward the sender.
   Each parameter may give only one definition for the local value, but
   may potentially give more than one definition for composition rules
   and composed values. This is because it may be useful to compose the
   same local value several times following different composition rules.

   Because characterization parameters are used to compute the
   properties of a specific path through the internetwork, all
   characterization parameter definitions are conceptually "per-next-
   hop", as opposed to "per interface" or "per network element".  In
   cases where the network element is (or is controlling) a shared media
   or large-cloud subnet, the element may need to provide different
   values for different next-hops within the cloud.  In practice, it may
   be appropriate for vendors to choose and document a tolerance range,
   such that if all next-hop values are within the tolerance range only
   a single value need be stored and provided.

   Local and composed characterization parameter values have distinct
   ID's so that a network management entity can examine the value of
   either a local or path-composed parameter at any point within the
   network.

   Each parameter definition includes a description of the minimal
   properties, such as range and precision, required of any wire
   representation of that parameter's values. Each definition also
   includes an XDR [RFC 1832] description of the parameter, describing
   an appropriate external (wire) data representation for the
   parameter's values. This dual definition is intended to encourage a
   common wire representation format whenever possible, while still
   allowing other representations when required by the specific
   circumstances (e.g., ASN.1 within SNMP).

   The message formats specified in [RFC 2210] for use with the RSVP
   setup protocol use the XDR data representation parameters.

   All of the parameters described in this note are mandatory, in the
   sense that a network element claiming to support integrated service
   must recognize arriving values in setup and management protocol
   messages, process them correctly, and export a reasonable value in
   response. For some parameters, the specification requires that the
   network element compute and export an *accurate* local value. For
   other parameters, it is acceptable for the network element to
   indicate that it cannot compute and export an accurate local value.
   The definition of these parameters provides a reserved value which
   indicates "indeterminate" or "invalid". This value signals that an
   element cannot process the parameter accurately, and consequently
   that the result of the end-to-end composition is also questionable.




Shenker & Wroclawski        Standards Track                     [Page 3]

RFC 2215          General Characterization Parameters     September 1997


      NOTE (temporary): Previous versions of this and the RSVP use
      document used both the reserved-value approach and a separate
      INVALID flag to record this fact.  Now, the reserved-value
      approach is used exclusively. This is so that any protocol which
      retrieves a parameter value, including SNMP, can carry the invalid
      indication without needing a separate flag. The INVALID flag
      remains in the RSVP message format but is reserved for use only
      with a possible future service-composition scheme.

2. Default and Service-Specific Values for General Parameters

   General parameters have a common *definition* across all QoS control
   services. Frequently, the same *value* of a general parameter will be
   correct for all QoS control services offered by a network element. In
   this circumstance, there is no need to export a separate copy of the
   value for each QoS control service; instead the node can export one
   number which applies to all supported services.

   A general parameter value which applies to all services supported at
   a network node is called a default or global value. For example, if
   all of the QoS control services provided at a node support the same
   maximum packet size, the node may export a single default value for
   the PATH_MTU parameter described in Section 3, rather than providing
   a separate copy of the value for each QoS control service. In the
   common case, this reduces both message size and processing overhead
   for the setup protocol.

   Occasionally an individual service needs to report a value differing
   from the default value for a particular general parameter. For
   example, if the implementation of Guaranteed Service [RFC 2212] at a
   router is restricted by scheduler or hardware considerations to a
   maximum packet size smaller than supported by the router's best-
   effort forwarding path, the implementation may wish to export a
   "service-specific" value of the PATH_MTU parameter so that
   applications using the Guaranteed service will function correctly.

   In the example above, the router might supply a value of 1500 for the
   default PATH_MTU parameter, and a value of 250 for the PATH_MTU
   parameter applying to guaranteed service. In this case, the setup
   protocol providing path characterization carries (and delivers to the
   application) both a value for Guaranteed service and a value for
   other services.

   The distinction between default and service-specific parameter values
   makes no sense for non-general parameters (those defined by a
   specific QoS control service, rather than this note), because both
   the definition and value of the parameter are always specific to the
   particular service.



Shenker & Wroclawski        Standards Track                     [Page 4]

RFC 2215          General Characterization Parameters     September 1997


   The distinction between default and service-specific values for
   general parameters is reflected in the parameter ID name space.  This
   allows network nodes, setup protocols, and network management tools
   to distinguish default from service-specific values, and to determine
   which service a service-specific parameter value is associated with.

   Service number 1 is used to indicate the default value. A parameter
   value identified by the ID:

                           <1, parameter_number>

   is a default value, which applies to all services unless it is
   overridden by a service-specific value for the same parameter.

   A parameter value identified by the ID:

                    <service_number, parameter_number>

   where service_number is not equal to 1, is a service-specific value.
   It applies only to the service identified by service_number.

   These service-specific values are also called override values.  This
   is because when both service-specific and default values are present
   for a parameter, the service-specific value overrides the default
   value (for the service to which it applies). The rules for composing
   service-specific and global general parameters support this override
   capability.  The basic rule is to use the service-specific value if
   it exists, and otherwise the global value.

   A complete summary of the characterization parameter composition
   process is given below. In this summary, the "arriving value" is the
   incompletely composed parameter value arriving from a neighbor node.
   The "local value" is the (global or service-specific) value made
   available by the local node. The "result" is the newly composed value
   to be sent to the next node on the data path.

     1. Examine the <service_number, parameter_number> pair associated
     with the arriving value. This information is conveyed by the setup
     protocol together with the arriving value.

     2. If the arriving value is for a parameter specific to a single
     service (this is true when the parameter_number is larger than
     128), compose the arriving value with the local value exported by
     the specified service, and pass the result to the next hop. In this
     case there is no need to consider global values, because the
     parameter itself is specific to just one service.





Shenker & Wroclawski        Standards Track                     [Page 5]

RFC 2215          General Characterization Parameters     September 1997


     3. If the arriving value is a service-specific value for a
     generally defined parameter (the parameter_number is 127 or less,
     and the service_number is other than 1), and the local
     implementation of that service also exports a service-specific
     value for the parameter, compose the service-specific arriving
     value and the service-specific local value of the parameter, and
     pass the result as a service-specific value to the next-hop node.

     4. If the arriving value is a service-specific value for a general
     parameter (the parameter_number is 127 or less, and the
     service_number is other than 1), and the local implementation of
     that service does *not* export a service-specific value, compose
     the service-specific arriving value with the global value for that
     parameter exported by the local node, and pass the result as a