rfc2215.txt

中、英文RFC文档大全打包下载完全版 .

     service-specific value to the next-hop node.

     5. If the arriving value is a global value for a general parameter
     (parameter_number is 127 or less, and the service_number is 1), and
     the local implementation of *any* service exports a service-
     specific value for that general parameter, compose the arriving
     (global) value with the service-specific value for that parameter
     exported by the local service, and pass the result as a service-
     specific value to the next-hop node. This will require adding a new
     data field to the message passed to the next hop, to hold the newly
     generated service-specific value. Repeat this process for each
     service that exports a service-specific value for the parameter.

     6. If the arriving value is a global value for a general parameter
     (the service_number is 1, and the parameter_number is 127 or less),
     compose the arriving (global) value with the global parameter value
     exported by the local node, and pass the result as a global
     (service 1) value to the next-hop node. This step is performed
     whether or not any service-specific values were generated and
     exported in step 5.

3. General Parameter Definitions

 3.1 NON-IS_HOP flag parameter

   This parameter provides information about the presence of network
   elements which do not implement QoS control services along the data
   path.

   The local value of the parameter is 1 if the network element does not
   implement the relevant QoS control service, or knows that there is a
   break in the chain of elements which implement the service.  The
   local parameter is 0 otherwise.  The local parameter is assigned
   parameter_number 1.



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


   The composition rule for this parameter is the OR function. A
   composed parameter value of 1 arriving at the endpoint of a path
   indicates that at least one point along the path does not offer the
   indicated QoS control service.  The parameter_number for the composed
   quantity is 2.

   The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this
   flag is set, it indicates that one or more network elements along the
   application's data path does not support the integrated services
   framework at all. An example of such an element would be an IP router
   offering only best-effort packet delivery and not supporting any
   resource reservation requests.

   Obviously, a network element which does not support this
   specification will not know to set this flag.  The actual
   responsibility for determining that a network node does not support
   integrated services may fall to the network element, the setup
   protocol, or a manual configuration operation and is dependent on
   implementation and usage.  This calculation must be conservative.
   For example, a router sending packets into an IP tunnel must assume
   that the tunneled packets will not receive QoS control services
   unless it or the setup protocol can prove otherwise.

   Service-specific versions of the NON_IS_HOP flag indicate that one or
   more network elements along a path don't support the particular
   service. For example, the flag parameter identified by ID <2,2> being
   set indicates that some network element along the path does not
   support the Guaranteed service, though it might support another
   service such as Controlled-Load.

   If the global NON_IS_HOP flag <1,2> is set for a path, the receiver
   (network element or application) should consider the values of all
   other parameters defined in this specification, including service-
   specific NON_IS_HOP flags, as possibly inaccurate. If a service
   specific NON_IS_HOP flag is set for a path, the receiver should
   consider the values of all other parameters associated with that
   service as possibly inaccurate.

   The NON_IS_HOP parameter may be represented in any form which can
   express boolean true and false. However, note that a network element
   must set this flag precisely when it does *not* fully understand the
   format or data representation of an arriving protocol message
   (because it does not support the specified service). Therefore, the
   data representation used for this parameter by setup and management
   protocols must allow the parameter value to be read and set even if
   the network element cannot otherwise parse the protocol message.





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


   An appropriate XDR description of this parameter is:

                             bool NON_IS_HOP;

   However, the standard XDR data encoding for this description will not
   meet the requirement described above unless other restrictions are
   placed on message formats. An alternative data representation may be
   more appropriate.

      NOTE: The message format described for RSVP in [RFC 2210] carries
      this parameter as a single-bit flag, referred to as the "break
      bit".

 3.2 NUMBER_OF_IS_HOPS

   IS stands for "integrated services aware".  An integrated services
   aware network element is one that conforms to the various
   requirements described in this and other referenced documents.  The
   network element need not offer a specific service, but if it does it
   must support and characterize the service in conformance with the
   relevant specification, and if it does not it must correctly set the
   NON_IS_HOP flag parameter for the service. For completeness, the
   local parameter is assigned the parameter_number 3.

   The composition rule for this parameter is to increment the counter
   by one at each IS-aware hop.  This quantity, when composed end-to-
   end, informs the endpoint of the number of integrated-services aware
   network elements traversed along the path.  The parameter_number for
   this composed parameter is 4.

   Values of the composed parameter will range from 1 to 255, limited by
   the bound on IP hop count.

   The XDR representation of this parameter is:

                      unsigned int NUMBER_OF_IS_HOPS;

 3.3. AVAILABLE_PATH_BANDWIDTH

   This parameter provides information about the bandwidth available
   along the path followed by a data flow.  The local parameter is an
   estimate of the bandwidth the network element has available for
   packets following the path.  Computation of the value of this
   parameter should take into account all information available to the
   network element about the path, taking into consideration
   administrative and policy controls on bandwidth, as well as physical
   resources.




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


      NOTE: This parameter should reflect, as closely as possible, the
      actual bandwidth available to packets following a path. However,
      the bandwidth available may depend on a number of factors not
      known to the network element until a specific QoS request is in
      place, such as the destination(s) of the packet flow, the service
      to be requested by the flow, or external policy information
      associated with a reservation request.  Because the parameter must
      in fact be provided before any specific QoS request is made, it is
      frequently difficult to provide the parameter accurately. In
      circumstances where the parameter cannot be provided accurately,
      the network element should make the best attempt possible, but it
      is acceptable to overestimate the available bandwidth by a
      significant amount.

   The parameter_number for AVAILABLE_PATH_BANDWIDTH is 5. The global
   parameter <1, 5> is an estimate of the bandwidth available to any
   packet following the path, without consideration of which (if any)
   QoS control service the packets may be subject to.

   In cases where a particular service is administratively or
   technically restricted to a limited portion of the overall available
   bandwidth, the service module may wish to export an override
   parameter which specifies this smaller bandwidth value.

   The composition rule for this parameter is the MIN function. The
   composed value is the minimum of the network element's value and the
   previously composed value. This quantity, when composed end-to-end,
   informs the endpoint of the minimal bandwidth link along the path
   from sender to receiver.  The parameter_number for the composed
   minimal bandwidth along the path is 6.

   Values of this parameter are measured in bytes per second.  The
   representation must be able to express values ranging from 1 byte per
   second to 40 terabytes per second, about what is believed to be the
   maximum theoretical bandwidth of a single strand of fiber.

   Particularly for large bandwidths, only the first few digits are
   significant, so the use of a floating point representation, accurate
   to at least 0.1%, is encouraged.

   The XDR representation for this parameter is:

                      float AVAILABLE_PATH_BANDWIDTH;

   For values of this parameter only valid non-negative floating point
   numbers are allowed. Negative numbers (including "negative zero"),
   infinities, and NAN's are not allowed.




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


      NOTE: An implementation which utilizes general-purpose hardware or
      software IEEE floating-point support may wish to verify that
      arriving parameter values meet these requirements before using the
      values in floating-point computations, in order to avoid
      unexpected exceptions or traps.

   If the network element cannot or chooses not to provide an estimate
   of path bandwidth, it may export a local value of zero for this
   parameter.  A network element or application receiving a composed
   value of zero for this parameter must assume that the actual
   bandwidth available is unknown.

 3.4 MINIMUM_PATH_LATENCY

   The local parameter is the latency of the packet forwarding process
   associated with the network element, where the latency is defined to
   be the *smallest* possible packet delay added by the network element.
   This delay results from speed-of-light propagation delay, from packet
   processing limitations, or both. It does not include any variable
   queuing delay which may be present.

   The purpose of this parameter is to provide a baseline minimum path
   latency for use with services which provide estimates or bounds on
   additional path delay, such as Guaranteed [RFC 2212].  Together with
   the queuing delay bound offered by Guaranteed and similar services,
   this parameter gives the application knowledge of both the minimum
   and maximum packet delivery delay.  Knowing both the minimum and
   maximum latency experienced by data packets allows the receiving
   application to accurately compute its de-jitter buffer requirements.

   Note that the quantity characterized by this parameter is the
   absolute smallest possible value for the packet processing and
   transmission latency of the network element. This value is the
   quantity required to provide the end hosts with jitter bounds. The
   parameter does *not* provide an upper-bound estimate of minimum
   latency, which might be of interest for best-effort traffic and QoS
   control services which do not explicitly offer delay bounds. In other
   words, the parameter will always underestimate, rather than
   overestimate, latency, particularly in multicast and large cloud
   situations.

   When packets traversing a network element may experience different
   minimal latencies over different paths, this parameter should, if
   possible, report an accurate latency value for each path. For
   example, when an ATM point-multipoint virtual circuit is used to
   implement IP multicast, the mechanism that implements this parameter
   for the ATM cloud should ideally compute a separate value for each
   destination. Doing this may require cooperation between the ingress



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


   and egress elements bounding the multi-access communication cloud.
   The method by which this cooperation is achieved, and the choice of
   which IP-level network element actually provides and composes the
   value, is technology-dependent.

   An alternative choice is to provide the same value of this parameter
   for all paths through the cloud. The value reported must be the
   smallest latency for any possible path. Note that in this situation,
   QoS control services (e.g., Guaranteed) which provide an upper bound
   on latency cannot simply add their queuing delay to the value
   computed by this parameter; they must also compensate for path delays
   above the minimum. In this case the range between the minimum and
   maximum packet delays reported to the application may be larger than
   actually occurs, because the application will be told about the
   minimum delay along the shortest path and the maximum delay along the
   actual path.  This is acceptable in most situations.

   A third alternative is to report the "indeterminate" value, as
   specified below.  In this circumstance the client application may
   either deduce a minimum path latency through measurement, or assume a
   value of zero.

   The composition rule for this parameter is summation with a clamp of
   (2**32 - 1) on the maximum value. This quantity, when composed end-
   to-end, informs the endpoint of the minimal packet delay along the
   path from sender to receiver. The parameter_number for the latency of
   the network element's link is 7. The parameter_number for the
   cumulative latency along the path is 8.

   The latencies are reported in units of one microsecond. An individual
   element can advertise a latency value between 1 and 2**28 (somewhat
   over two minutes) and the total latency added across all elements can
   range as high as (2**32)-2. If the sum of the different elements
   delays exceeds (2**32)-2, the end-to-end advertised delay should be