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]
