< draft-ietf-intserv-charac-01.txt   draft-ietf-intserv-charac-02.txt >
Internet Engineering Task Force Integrated Services WG Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT S. Shenker/J. Wroclawski INTERNET-DRAFT S. Shenker and J. Wroclawski
draft-ietf-intserv-charac-01.txt Xerox PARC/MIT LCS draft-ietf-intserv-charac-02.txt Xerox PARC/MIT LCS
June, 1996 October, 1996
Expires: 12/96 Expires: 3/97
Specification of General Characterization Parameters General Characterization Parameters for
Integrated Service Network Elements
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 35 skipping to change at page 1, line 36
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
This document is a product of the Integrated Services working group This document is a product of the Integrated Services working group
of the Internet Engineering Task Force. Comments are solicited and of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at int- should be addressed to the working group's mailing list at int-
serv@isi.edu and/or the author(s). serv@isi.edu and/or the author(s).
Abstract Abstract
This memo defines general characterization parameters for network This memo defines a set of general control and characterization
elements supporting enhanced qualities of service. parameters for network elements supporting the IETF integrated
Characterization parameters are used to characterize the service services QoS control framework. General parameters are those with
environment along the path of a packet flow desiring QoS control. common, shared definitions across all QoS control services.
General characterization parameters are those that are not
specific to a particular quality of service.
Introduction 1. Introduction
This memo defines a standard for general, or service-independent, This memo defines the set of general control and characterization
characterization parameters for network elements. General parameters used by network elements supporting the integrated
characterization parameters are those that are not specific to a services framework. "General" means that the parameter has a common
particular quality of service. A discussion of how these parameters definition and shared meaning across all QoS control services.
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]) Control parameters are used by applications to provide information to
describe the associated characterization parameters made available by the network related to QoS control requests. An example is the
those services. However, there are some quantities of interest that traffic specification (TSpec) generated by application senders and
are not specific to a particular quality of service. These "general" receivers.
characterizations are described in this document.
Characterization parameters are named using a scheme described in Characterization parameters are used to discover or characterize the
[1]. Each parameter is identified by a service_name and a QoS management environment along the path of a packet flow requesting
parameter_within_service field. The service-name associated with active end-to-end QoS control. These characterizations may
general characterization parameters is 0. The eventually be used by the application requesting QoS control, or by
parameter_within_service value for each parameter defined in this other network elements along the path. Examples include information
document is given below. about which QoS control services are available along a network path
and estimates of the available path bandwidth.
Parameters described here are of two types; local or composed. Local Individual QoS control service specifications may refer to these
parameters reflect a value exported by a single network element. parameter definitions as well as defining additional parameters
Composed parameters reflect the running composition of local specific to the needs of that service.
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 Parameters are assigned machine-oriented ID's using a method
management entity can request the value of either a local or path- described in [RFCTEMPLATE] and summarized here. These ID's may be
composed parameter at any point within the network. used within protocol messages and management interfaces to describe
the parameter values present. Each parameter ID is composed from two
numbers, one identifying the service associated with the parameter
(the <service_number>), and the other (the <parameter_number>)
identifying the parameter itself. <parameter_number> values for the
parameters defined in this document are assigned from the "general
parameters" range (1 - 127). Numbers in this range indicate that the
parameter definition is shared by all QoS control services.
Note that a particular service may specify a service_specific NOTE: Parameters numbered 128 - 254 have definitions specific to a
parameter which overrides a general parameter with the same particular QoS control service. In contrast to the general
information. For example, a service may allow network elements to parameters described here, the parameter's meaning depends on the
specify a MTU for packets requesting that service which is smaller service_number portion of the parameter ID.
than the physical MTU supported by the network element.
Conceptually, all characterization parameter definitions are "per- Service number 1 is reserved for use as described in Section 2 of
next-hop" as opposed to "per interface" or "per network element". In this note. Service numbers 2 through 254 will be allocated to
cases where the network element is a (or controlling) a shared media individual QoS control services. Currently, Guaranteed service
path, the element may need to provide different values for different [RFCG] is allocated number 2, and Controlled-load service [RFCCL]
next-hops. In some cases, parameter definitions may include a is allocated number 5.
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 In this note, the textual form
implementation specification.
Parameter Definitions <service_number, parameter_number>
Number of IS Hops is used to write a service_number, parameter_number pair. The range
of possible of service_number and parameter_number values specified
in [RFCTEMPLATE] 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.
IS stands for "integrated services aware". An integrated services The definition of each parameter used to characterize a path through
aware network element is one that conforms to the various the network describes two types of values; local and composed. Local
requirements described in this document and the documents [1-3]. (The values reflect conditions at a single network element. Composed
network element need not offer those services, but if it does it values reflect the running composition of local values along a path,
supports and characterizes the services in conformance with the as specified by a composition rule. Each parameter definition
relevant specification). The local parameter always has a value of 1. specifies the composition rule for that parameter. The composition
For completeness, the local parameter is assigned the parameter_name rule describes how to combine the arriving composed value and the
1. 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 downstream, toward the receiver(s), or upstream, toward the
sender. Each parameter may give only one definition for the local
value, but may 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.
The composition rule for this parameter is to increment the counter Because characterization parameters are used to compute the
by one at each IS-aware hop. This quantity, when composed end-to-end, properties of a specific path through the internetwork, all
informs the endpoint of the number of Integrated-Services aware characterization parameter definitions are conceptually "per-next-
network elements traversed along the path from sender to receiver. hop", as opposed to "per interface" or "per network element". In
The parameter_name for this composed parameter is 2. The parameter cases where the network element is (or is controlling) a shared media
may be represented as a single 16-bit unsigned integer in network or large-cloud subnet, the element may need to provide different
byte order. values for different next-hops. 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.
Non-IS hop encountered flag Local and composed characterization parameter values have distinct
ID's so that a network management entity can request the value of
either a local or path-composed parameter at any point within the
network.
For each outgoing path from a network element, the local parameter is Each parameter definition includes a description of the minimal
0 if the network element is certain that there exists no break in the properties, such as range and precision, required of any wire
QoS control services between itself and the next IS-aware network representation of that parameter's values. Each definition also
element on the path. The local parameter is 1 otherwise. The local includes an XDR [RFCXDR] description of the parameter, describing an
parameter is assigned parameter_name 3. 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 actual responsibility for computing the value of the local The message formats specified in [RFCRSVPUSE] for use with the RSVP
parameter at a network node along the path may fall to the network setup protocol use the XDR data representation parameters.
element, the setup protocol, or a manual configuration operation.
This calculation must be conservative. For example, a router sending All of the parameters described in this note are mandatory, in the
packets into an IP tunnel must assume that the tunneled packets will sense that a network element claiming to support integrated service
not receive QoS control services unless it or the setup protocol can must recognize arriving values in setup and management protocol
prove otherwise. messages, process them correctly, and export a reasonable value in
response. For certain parameters, it is required 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.
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 supported at 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 copy 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 [RFCG] 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.
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. 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 (the parameter_number is larger than 128), compose the
arriving value with the locally value exported by the specified
service, and pass the result to the next hop.
3. 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 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
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.
The composition rule for this parameter is the OR function. A The composition rule for this parameter is the OR function. A
composed parameter value of 1 arriving at the endpoint of a path 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 indicates that at least one point along the path does not offer the
control services. The parameter_name for the composed quantity is 4. indicated QoS control service. The parameter_number for the composed
quantity is 2.
These characterization parameters may be represented as 16-bit The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this
unsigned integers in network byte order. 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.
If the Non-IS-hop flag is set for a path, the values of all other Obviously, a network element which does not support this
parameters defined in this specification must be considered specification will not know to set this flag. The actual
approximate. 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.
NOTE: The previous version of this document defined the above Service-specific versions of the NON_IS_HOP flag indicate that one or
parameter as a count. Discussion within the intserv and RSVP more network elements along a path don't support the particular
groups suggests that accurately counting non-IS hops in all service. For example, the flag parameter identified by ID <2,2> being
situations is both difficult and unnecessary. 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.
Minimum Available Path Bandwidth 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 local parameter is the minimum bandwidth the network element The NON_IS_HOP parameter may be represented in any form which can
makes available to packets following the path. The value of this express boolean true and false. However, note that a network element
parameter must be as accurate as possible, taking into consideration 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.
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 [RFCRSVPUSE] 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 administrative and policy controls on bandwidth, as well as physical
resources. Computation of the value of this parameter should take resources.
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 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 is
permitted 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
implementationally 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 composed value is the minimum of the network element's value and the
previously composed value. This quantity, when composed end-to-end, previously composed value. This quantity, when composed end-to-end,
informs the endpoint of the minimal bandwidth link along the path informs the endpoint of the minimal bandwidth link along the path
from sender to receiver. The parameter_name for the bandwidth of the from sender to receiver. The parameter_number for the composed
network element is 4. The parameter_name for the composed minimal minimal bandwidth along the path is 6.
bandwidth along the path is 5.
These values are measured in bytes per second, and can range from 1 Values of this parameter are measured in bytes per second. The
byte per second to as large as 40 terabytes per second (or about what representation must be able to express values ranging from 1 byte per
is believed to be the maximum theoretical bandwidth of a single second to 40 terabytes per second, about what is believed to be the
strand of fiber). Clearly, particularly for large bandwidths, only maximum theoretical bandwidth of a single strand of fiber.
the first few digits are significant and so the use of floating point Particularly for large bandwidths, only the first few digits are
representations, accurate to at least 0.1% is encouraged. These significant, so the use of a floating point representation, accurate
characterizations of bandwidth can be represented by floating point to at least 0.1%, is encouraged.
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 The XDR representation for this parameter is:
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
as possible, but is not expected to be either "conservative"
(consistantly estimating low) or "liberal" (consistantly
estimating high).
Minimum Path Latency float AVAILABLE_PATH_BANDWIDTH;
The local parameter is the latency of the link associated with the For values of this parameter only valid non-negative floating point
network element, where the latency is defined to be the minimal numbers are allowed. Negative numbers (including "negative zero"),
possible packet delay along the path taken by the flow. This delay infinities, and NAN's are not allowed.
may result from "speed-of-light" propagation delay, from packet
processing limitations, or both.
When packets leaving a network element may follow different paths, NOTE: An implementation which utilizes general-purpose hardware or
such as virtual circuits within an ATM cloud, different latency software IEEE floating-point support may wish to verify that
values must be provided for different paths. Doing so may require arriving parameter values meet these requirements before using the
cooperation between the ingress and egress elements bounding a values in floating-point computations, in order to avoid
communication cloud. The method by which this cooperation is unexpected exceptions or traps.
If the network element cannot or wishes 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 should 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 *minimal* possible packet delay added by the network element
This delay may result 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 minimal path
latency for use with services which provide estimates or bounds on
additional path delay, such as Guaranteed [RFCG]. In conjunction
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 lower bound on the packet processing and transmission
latency of the network element. This value is the quantity required
to provide jitter bounding. The parameter does *not* provide the type
of upper-bound estimate on minimum latency which might be of interest
for best-effort traffic and QoS control services which do not
explicitly offer delay bounds. That is, 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, this parameter should ideally 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 used to implement this parameter would ideally compute a
separate value for each destination. Doing so may require cooperation
between the ingress and egress elements bounding the multi-path
communication cloud. The method by which this cooperation is
achieved, and the choice of which IP-level network element actually achieved, and the choice of which IP-level network element actually
provides and composes the value, is technology-dependent. provides and composes the value, is technology-dependent.
It is acceptable to provide a single value for multiple paths if the An alternative choice is to provide the same value of this parameter
latency values of all paths are within 10 percent or 100 microseconds for all paths through the cloud. The value reported must be the
of each other, whichever is greater. smallest latency for any possible path. Note that in this situation,
QoS control services (e.g., Guaranteed) which provide an upper bound
In certain cases determining the correct latency value to report is on latency cannot simply add their queuing delay to the value
extremely difficult. For instance, the speed-of-light delays on an computed by this parameter; they must also compensate for path delays
ethernet bridged via satellite with another ethernet vary by several above the minimum. In this case the range between the minimum and
orders of magnitude. In a case such as this the network element may maximum packet delays reported to the application will be larger,
either employ a latency estimation protocol, return the best-case because the application will be told about the minimum delay along
(longest) minimum latency between any two nodes using the shared the shortest path and the maximum delay along the actual path. This
resource, or return the "indeterminate" value, as specified below. is acceptable in many situations.
NOTE: This parameter represents the "minimal minimum" path A third alternative is to report the "indeterminate" value, as
latency. In a shared-media situation it should represent the specified below. In this circumstance the client application may
shortest latency between the local node and any other. The either deduce a minimum path latency through measurement, or assume a
rationale for this is that the parameter is intended for use with value of zero.
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 The composition rule for this parameter is summation with a clamp of
(2**32 - 1) on the maximum value. This quantity, when composed end- (2**32 - 1) on the maximum value. This quantity, when composed end-
to-end, informs the endpoint of the minimal packet delay along the to-end, informs the endpoint of the minimal packet delay along the
path from sender to receiver. The parameter_name for the latency of path from sender to receiver. The parameter_number for the latency of
the network element's link is 6. The parameter_name for the the network element's link is 7. The parameter_number for the
cumulative latency along the path is 7. cumulative latency along the path is 8.
The delays are measured in units of one microsecond. An individual The latencies are measured in units of one microsecond. An individual
element can advertise a delay value between 1 and 2**28 (somewhat element can advertise a latency value between 1 and 2**28 (somewhat
over two minutes) and the total delay added across all elements can over two minutes) and the total latency added across all elements can
range as high as (2**32)-2. Should the sum of the different elements 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 delay exceed (2**32)-2, the end-to-end advertised delay should be
(2**32)-1. This value is explained in the next paragraph. reported as indeterminate. This is described below.
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 Note that while the granularity of measurement is microseconds, a
conforming element is free to measure delays more loosely. The conforming element is free to measure delays more loosely. The
minimum requirement is that the element estimate its delay accurately minimum requirement is that the element estimate its delay accurately
to the nearest 100 microsecond granularity. Elements that can measure to the nearest 100 microsecond granularity. Elements that can measure
more accurately are, of course, encouraged to do so. more accurately are, of course, encouraged to do so.
NOTE: Measuring in milliseconds is not acceptable, because if the NOTE: Measuring in milliseconds is not acceptable, because if the
minimum delay value is a millisecond, a path with several hops minimum delay value is a millisecond, a path with several hops
will lead to a composed delay of at least several milliseconds, will lead to a composed delay of at least several milliseconds,
which is likely to be misleading. which is likely to be misleading.
The characterization parameters may be represented as 32-bit unsigned The XDR description of this parameter is:
integers in network byte order.
Path MTU unsigned int MINIMUM_PATH_LATENCY;
The local characterization parameter is the path IP MTU, where the The distinguished value (2**32)-1 is taken to mean "indeterminate
MTU of a network element is defined to be the maximum transmission latency". A network element which cannot accurately predict the
unit the network element can accommodate without fragmentation latency of packets it is processing should set its local parameter to
including IP and upper-layer protocol headers, but not including link this value. Because the composition function limits the composed sum
level headers. The composition rule is to take the minimum of the to this value, receipt of this value at a network element or
network element's MTU and the previously composed value. This application indicates that the true path latency is not known. This
quantity, when composed end-to-end, informs the endpoint of the may happen because one or more network elements could not supply a
maximum transmission unit that can traverse the path from sender to value, or because the range of the composition calculation was
receiver without fragmentation. The parameter_name for the MTU of the exceeded.
network element's link is 8. The parameter_name for the composed MTU
along the path is 9.
Service Availability 3.5. PATH_MTU
The INT SERV working group is still developing proposals for handling This parameter computes the maximum transmission unit (MTU) for
heterogeneity. When that work is complete, a set of requirement packets following a data path. This value is required to invoke QoS
parameters will be defined. control services which require that IP packet size be strictly
limited to a specific MTU. Existing MTU discovery mechanisms cannot
be used because they provide information only to the sender and they
do not directly allow for QoS control services to specify MTU's
smaller than the physical MTU.
Security Considerations The local characterization parameter is the 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_number for the MTU of the network
element's link is 9. The parameter_number for the composed MTU along
the path is 10.
A correct and valid value of this parameter must be provided by all
IS-aware network elements.
A specific service module may specify an MTU smaller than that of the
overall network element by overriding this parameter with one giving
the service's MTU value. A service module may not specify an MTU
value larger than that given by the global parameter.
Values of this parameter are measured in bytes. The representation
must be able to express values ranging from 1 byte to 2**32-1 bytes.
The XDR description of this parameter is:
unsigned int PATH_MTU;
3.6. TOKEN_BUCKET_TSPEC
This parameter is used to describe data traffic parameters using a
simple token bucket filter. This parameter is used by data senders to
describe the traffic parameters of traffic it expects to generate,
and by QoS control services to describe the parameters of traffic for
which the reservation should apply. It is defined as a general rather
than service-specific parameter because the same traffic description
may be used by several QoS control services in some situations.
The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127.
The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification
plus a peak rate p, minimum policed unit m, and a maximum packet size
M.
The token bucket specification includes an average or token rate r
and a bucket depth b. Both r and b must be positive.
The token rate r is measured in bytes of IP datagrams per second.
Values of this parameter may range from 1 byte per second to 40
terabytes per second. In practice, only the first few digits of the r
and p parameters are significant, so the use of floating point
representations, accurate to at least 0.1% is encouraged.
The bucket depth, b, is measured in bytes. Values of this parameter
may range from 1 byte to 250 gigabytes. In practice, only the first
few digits of the b parameter are significant, so the use of floating
point representations, accurate to at least 0.1% is encouraged.
The peak traffic rate p is measured in bytes of IP datagrams per
second. Values of this parameter may range from 1 byte per second to
40 terabytes per second. In practice, only the first few digits of
the r and p parameters are significant, so the use of floating point
representations, accurate to at least 0.1% is encouraged. The peak
rate value may be set to positive infinity, indicating that it is
unknown or unspecified.
The range of values allowed for these parameters is intentionally
large to allow for future network technologies. Any particular
network element is not expected to support the full range of values.
The minimum policed unit, m, is an integer measured in bytes. All IP
datagrams less than size m will be counted against the token bucket
as being of size m. The maximum packet size, M, is the biggest packet
that will conform to the traffic specification; it is also measured
in bytes. Both m and M must be positive, and m must be less then or
equal to M.
The XDR description of this parameter is:
struct {
float r;
float b;
float p;
unsigned m;
unsigned M;
} TOKEN_BUCKET_TSPEC;
For the fields r and b only valid non-negative floating point numbers
are allowed. Negative numbers (including "negative zero), infinities,
and NAN's are not allowed.
For the field p, only valid non-negative floating point numbers or
positive infinity are allowed. Negative numbers (including "negative
zero), negative infinities, and NAN's are not allowed.
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.
4. Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
References 5. References
[1] S. Shenker and J. Wroclawski. "Network Element Service [RFCRSVP] B. Braden, et. al. "Resource Reservation Protocol (RSVP) -
Specification Template", Internet Draft, June 1995, <draft-ietf- Version 1 Functional Specification", Internet Draft, July 1996,
intserv-svc-template-01.txt> <draft-ietf-rsvp-spec-13.txt>
[3] S. Shenker and C. Partridge. Specification of Guaranteed Quality [RFCRSVPUSE] J. Wroclawski. "The Use of RSVP with IETF Integrated
of Service", Internet Draft, June 1996, <draft-ietf-intserv- Services", Internet Draft, October, 1996, <draft-ietf-intserv-rsvp-
guaranteed-svc-04.txt> use-01.txt>
[3] J. Wroclawski. "Specification of the Controlled Load Quality of [RFCTEMPLATE] S. Shenker and J. Wroclawski. "Network Element QoS
Service", Internet Draft, November 1995, <draft-ietf-intserv-ctrl- Control Service Specification Template". Internet Draft, October
load-svc-01.txt> 1996, <draft-ietf-intserv-svc-template-03.txt>
[RFCG] S. Shenker, C. Partridge, and R Guerin. "Specification of the
Guaranteed Quality of Service", Internet Draft, July 1996, <draft-
ietf-intserv-guaranteed-svc-06.txt>
[RFCCL] J. Wroclawski. "Specification of the Controlled Load Quality
of Service", Internet Draft, July 1996, <draft-ietf-intserv-ctrl-
load-svc-03.txt>
[RFCXDR] R. Srinivansan. "XDR: External Data Representation
Standard", RFC 1832, August 1995.
Author's Address: Author's Address:
Scott Shenker Scott Shenker
Xerox PARC Xerox PARC
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304-1314 Palo Alto, CA 94304-1314
shenker@parc.xerox.com shenker@parc.xerox.com
415-812-4840 415-812-4840
415-812-4471 (FAX) 415-812-4471 (FAX)
 End of changes. 48 change blocks. 
205 lines changed or deleted 585 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/