One document matched: draft-ietf-intserv-charac-01.txt
Differences from draft-ietf-intserv-charac-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 06:03:13 |