[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 2215

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                  S. Shenker/J. Wroclawski
draft-ietf-intserv-charac-01.txt                      Xerox PARC/MIT LCS
                                                              June, 1996
                                                          Expires: 12/96


          Specification of General Characterization Parameters


Status of this Memo


   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   This document is a product of the Integrated Services working group
   of the Internet Engineering Task Force. Comments are solicited and
   should be addressed to the working group's mailing list at int-
   serv@isi.edu and/or the author(s).

Abstract

      This memo defines general characterization parameters for network
      elements supporting enhanced qualities of service.
      Characterization parameters are used to characterize the service
      environment along the path of a packet flow desiring QoS control.
      General characterization parameters are those that are not
      specific to a particular quality of service.

Introduction

   This memo defines a standard for general, or service-independent,
   characterization parameters for network elements. General
   characterization parameters are those that are not specific to a



Shenker/Wroclawski       Expires December, 1996                 [Page 1]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


   particular quality of service. A discussion of how these parameters
   fit into an integrated services architecture can be found in [1].
   Please refer to that document for definitions and additional
   information about the specification of qualities of service within
   the IP protocol family.

   The specifications of the various qualities of service ([2-3])
   describe the associated characterization parameters made available by
   those services. However, there are some quantities of interest that
   are not specific to a particular quality of service. These "general"
   characterizations are described in this document.

   Characterization parameters are named using a scheme described in
   [1]. Each parameter is identified by a service_name and a
   parameter_within_service field. The service-name associated with
   general characterization parameters is 0. The
   parameter_within_service value for each parameter defined in this
   document is given below.

   Parameters described here are of two types; local or composed. Local
   parameters reflect a value exported by a single network element.
   Composed parameters reflect the running composition of local
   parameters along a path, as specified by a composition rule. The
   definition of each parameter also specifies the composition rule.

   Both local and composed parameters are named so that a network
   management entity can request the value of either a local or path-
   composed parameter at any point within the network.

   Note that a particular service may specify a service_specific
   parameter which overrides a general parameter with the same
   information. For example, a service may allow network elements to
   specify a MTU for packets requesting that service which is smaller
   than the physical MTU supported by the network element.

   Conceptually, all characterization parameter definitions are "per-
   next-hop" as opposed to "per interface" or "per network element". In
   cases where the network element is a (or controlling) a shared media
   path, the element may need to provide different values for different
   next-hops. In some cases, parameter definitions may include a
   tolerance range, such that if all next-hop values are within the
   tolerance range only a single value need be stored and provided.

   This document is not yet stable, and should not be taken as an
   implementation specification.






Shenker/Wroclawski       Expires December, 1996                 [Page 2]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


Parameter Definitions

 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 document and the documents [1-3]. (The
   network element need not offer those services, but if it does it
   supports and characterizes the services in conformance with the
   relevant specification). The local parameter always has a value of 1.
   For completeness, the local parameter is assigned the parameter_name
   1.

   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 from sender to receiver.
   The parameter_name for this composed parameter is 2. The parameter
   may be represented as a single 16-bit unsigned integer in network
   byte order.

 Non-IS hop encountered flag

   For each outgoing path from a network element, the local parameter is
   0 if the network element is certain that there exists no break in the
   QoS control services between itself and the next IS-aware network
   element on the path. The local parameter is 1 otherwise. The local
   parameter is assigned parameter_name 3.

   The actual responsibility for computing the value of the local
   parameter at a network node along the path may fall to the network
   element, the setup protocol, or a manual configuration operation.
   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.

   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 QoS
   control services.  The parameter_name for the composed quantity is 4.

   These characterization parameters may be represented as 16-bit
   unsigned integers in network byte order.

   If the Non-IS-hop flag is set for a path, the values of all other
   parameters defined in this specification must be considered
   approximate.



Shenker/Wroclawski       Expires December, 1996                 [Page 3]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


      NOTE: The previous version of this document defined the above
      parameter as a count. Discussion within the intserv and RSVP
      groups suggests that accurately counting non-IS hops in all
      situations is both difficult and unnecessary.

 Minimum Available Path Bandwidth

   The local parameter is the minimum bandwidth the network element
   makes available to packets following the path. The value of this
   parameter must be as accurate as possible, taking into consideration
   administrative and policy controls on bandwidth, as well as physical
   resources. Computation of the value of this parameter should take
   into account all information available to the network element about
   the path.  If the value cannot be calculated exactly, the result
   should err on the side of underestimating the available bandwidth.

   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_name for the bandwidth of the
   network element is 4. The parameter_name for the composed minimal
   bandwidth along the path is 5.

   These values are measured in bytes per second, and can range from 1
   byte per second to as large as 40 terabytes per second (or about what
   is believed to be the maximum theoretical bandwidth of a single
   strand of fiber). Clearly, particularly for large bandwidths, only
   the first few digits are significant and so the use of floating point
   representations, accurate to at least 0.1% is encouraged.  These
   characterizations of bandwidth can be represented by floating point
   numbers in single-precision IEEE floating point format. Only bit
   patterns representing valid zero or positive floating-point numbers
   are allowed. Bit patterns representing negative numbers, NAN's, or
   "negative zero" are illegal.

      NOTE: This parameter should reflect, as much as possible, policy
      and administrative restrictions on bandwidth available to a path.
      However, the actual value available may depend on a number of
      factors not available to the network element, 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.  This makes it difficult to provide the
      parameter accurately.  Generally, a network element expected to
      provide an accurate value of this parameter would have to have in
      hand all of the information necessary to process a resource
      reservation request. In circumstances where the parameter cannot
      be provided accurately, the network element should come as close



Shenker/Wroclawski       Expires December, 1996                 [Page 4]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


      as possible, but is not expected to be either "conservative"
      (consistantly estimating low) or "liberal" (consistantly
      estimating high).

 Minimum Path Latency

   The local parameter is the latency of the link associated with the
   network element, where the latency is defined to be the minimal
   possible packet delay along the path taken by the flow. This delay
   may result from "speed-of-light" propagation delay, from packet
   processing limitations, or both.

   When packets leaving a network element may follow different paths,
   such as virtual circuits within an ATM cloud, different latency
   values must be provided for different paths. Doing so may require
   cooperation between the ingress and egress elements bounding a
   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.

   It is acceptable to provide a single value for multiple paths if the
   latency values of all paths are within 10 percent or 100 microseconds
   of each other, whichever is greater.

   In certain cases determining the correct latency value to report is
   extremely difficult. For instance, the speed-of-light delays on an
   ethernet bridged via satellite with another ethernet vary by several
   orders of magnitude. In a case such as this the network element may
   either employ a latency estimation protocol, return the best-case
   (longest) minimum latency between any two nodes using the shared
   resource, or return the "indeterminate" value, as specified below.

      NOTE: This parameter represents the "minimal minimum" path
      latency. In a shared-media situation it should represent the
      shortest latency between the local node and any other. The
      rationale for this is that the parameter is intended for use with
      services such as Guaranteed [ref] which provide a means to
      advertise additional latency above the minimum.

   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_name for the latency of
   the network element's link is 6. The parameter_name for the
   cumulative latency along the path is 7.

   The delays are measured in units of one microsecond. An individual
   element can advertise a delay value between 1 and 2**28 (somewhat



Shenker/Wroclawski       Expires December, 1996                 [Page 5]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


   over two minutes) and the total delay added across all elements can
   range as high as (2**32)-2. Should the sum of the different elements
   delay exceed (2**32)-2, the end-to-end advertised delay should be
   (2**32)-1. This value is explained in the next paragraph.

   The value (2**32)-1 is taken to mean "indeterminate latency". A
   network element which cannot accurately predict the latency of
   packets it is processing should set its local parameter to this
   value. Because the composition function limits the composed sum to
   this value, presence of this value at the end-point of the path
   indicates that the true path latency is not known. This may happen
   because one or more network elements could not supply a value, or
   because the range of the composition calculation was exceeded.

   Note that while the granularity of measurement is microseconds, a
   conforming element is free to measure delays more loosely. The
   minimum requirement is that the element estimate its delay accurately
   to the nearest 100 microsecond granularity. Elements that can measure
   more accurately are, of course, encouraged to do so.

      NOTE: Measuring in milliseconds is not acceptable, because if the
      minimum delay value is a millisecond, a path with several hops
      will lead to a composed delay of at least several milliseconds,
      which is likely to be misleading.

   The characterization parameters may be represented as 32-bit unsigned
   integers in network byte order.

 Path MTU

   The local characterization parameter is the path IP MTU, where the
   MTU of a network element is defined to be the maximum transmission
   unit the network element can accommodate without fragmentation
   including IP and upper-layer protocol headers, but not including link
   level headers. The composition rule is to take the minimum of the
   network element's MTU and the previously composed value. This
   quantity, when composed end-to-end, informs the endpoint of the
   maximum transmission unit that can traverse the path from sender to
   receiver without fragmentation. The parameter_name for the MTU of the
   network element's link is 8. The parameter_name for the composed MTU
   along the path is 9.

 Service Availability

   The INT SERV working group is still developing proposals for handling
   heterogeneity. When that work is complete, a set of requirement
   parameters will be defined.




Shenker/Wroclawski       Expires December, 1996                 [Page 6]


INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996


 Security Considerations

   Security considerations are not discussed in this memo.

References


   [1] S. Shenker and J. Wroclawski. "Network Element Service
   Specification Template", Internet Draft, June 1995, <draft-ietf-
   intserv-svc-template-01.txt>

   [3] S. Shenker and C. Partridge. Specification of Guaranteed Quality
   of Service", Internet Draft, June 1996, <draft-ietf-intserv-
   guaranteed-svc-04.txt>

   [3] J. Wroclawski. "Specification of the Controlled Load Quality of
   Service", Internet Draft, November 1995, <draft-ietf-intserv-ctrl-
   load-svc-01.txt>


Author's Address:


   Scott Shenker
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304-1314
   shenker@parc.xerox.com
   415-812-4840
   415-812-4471 (FAX)

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139
   jtw@lcs.mit.edu
   617-253-7885
   617-253-2673 (FAX)













Shenker/Wroclawski       Expires December, 1996                 [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/