📄 rfc2216.txt
字号:
Network Working Group S. Shenker
Request for Comments: 2216 J. Wroclawski
Category: Informational Xerox PARC/MIT LCS
September 1997
Network Element Service Specification Template
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document defines a framework for specifying services provided by
network elements, and available to applications, in an internetwork
which offers multiple qualities of service. The document first
provides some necessary context -- including relevant definitions and
suggested data formats -- and then specifies a "template" which
service specification documents should follow. The specification
template includes per-element requirements such as the service's
packet handling behavior, parameters required and made available by
the service, traffic specification and policing requirements, and
traffic ordering relationships. It also includes evaluation criteria
for elements providing the service, and examples of how the service
might be implemented (by network elements) and used (by
applications).
Introduction
This document defines the framework used to specify the functionality
of internetwork system components which support the the ability to
provide multiple, dynamically selectable qualities of service to
applications using an internetwork. The behavior of individual
routers and subnetworks is captured as a set of "services", some or
all of which may be offered by each element. The concatenation of
these services along the end-to-end data paths used by an application
provides overall quality of service control.
The definition of a service states what is required of a router (or,
more generally, any network element; a router, switch, subnet, etc.)
which supports a particular service. The service definition also
Shenker & Wroclawski Informational [Page 1]
RFC 2216 Network Element Service Template September 1997
specifies parameters used to invoke the service, the relationship
between those parameters and the service delivered, and the end-to-
end behavior obtained by concatenating several instances of the
service.
Each service definition also specifies the interface between that
service and the environment. This includes the parameters needed to
invoke the service, informational parameters which the service must
make available for use by setup, routing, and management mechanisms,
and information which should be carried between end-nodes and network
elements by those mechanisms in order to achieve the desired end-to-
end behavior. However, a service definition does not describe the
specific protocols or mechanisms used to establish state in the
network elements for flows that use the described service.
Services defined following the guidelines of this document are
intended for use both within the global Internet and private IP
networks. In certain cases a concatenation of network element
services may be used to provide a range of end-to-end behaviors, some
more suited to a decentralized internet and some more appropriate for
a tightly managed private network. This document points out places
where such distinction may be appropriate.
This document is comprised of three parts. The first defines some
terms used both in this document and in the various service
specification documents. The second discusses data formats and
representations. The third portion of the document describes the
various components of the service specification template.
Definitions
The following terms are used throughout this document. Service
specification documents should employ the same terms to express these
concepts.
o Quality of Service (QoS)
In the context of this document, quality of service refers to the
nature of the packet delivery service provided, as described by
parameters such as achieved bandwidth, packet delay, and packet loss
rates. Traditionally, the Internet has offered a single quality of
service, best-effort delivery, with available bandwidth and delay
characteristics dependent on instantaneous load. Control over the
quality of service seen by applications is exercised by adequate
provisioning of the network infrastructure. In contrast, a network
with dynamically controllable quality of service allows individual
application sessions to request network packet delivery
characteristics according to their perceived needs, and may provide
Shenker & Wroclawski Informational [Page 2]
RFC 2216 Network Element Service Template September 1997
different qualities of service to different applications. It should
be understood that there is a range of useful possibilities between
the two endpoints of providing no dynamic QoS control at all and
providing extremely precise and accurate control of QoS parameters.
o Network Element
A "Network Element" (or the equivalent shorter form "Element"), is
any component of an internetwork which directly handles data packets
and thus is potentially capable of exercising QoS control over data
flowing through it. Network elements include routers, subnetworks,
and end-node operating systems. A QoS-capable network element is one
which offers one or more of the services defined according to the
rules given in this document. Note that this definition, by itself,
preclude QoS-capable network elements that meet performance goals
purely through adequate provisioning rather than active admission and
traffic control mechanisms. A "QoS-aware" network element is one
which supports the interfaces (described below) required by the
service definitions. Thus, a QoS-aware network element need not
actually offer any of the services defined according to the format of
this document; it merely needs to know how to deny service requests.
o Flow
For the purposes of this document a flow is a set of packets
traversing a network element all of which are covered by the same
request for control of quality of service. At a given network element
a flow may consist of the packets from a single application session,
or it may be an aggregation comprising the combined data traffic from
a number of application sessions.
NOTE: this definition of a flow is different from that used in
IPv6, where a flow is defined as those packets with the same
source address and FlowID.
Mechanisms used to associate a request for quality of service control
with the packets covered by that request are beyond the scope of this
document.
o Service
The phrase "service" or "QoS Control Service" describes a named,
coordinated set of QoS control capabilities provided by a single
network element. The definition of a service includes a
specification of the functions to be performed by the network
Shenker & Wroclawski Informational [Page 3]
RFC 2216 Network Element Service Template September 1997
element, the information required by the element to perform these
functions, and the information made available by the element to other
elements of the system. A service is conceptually implemented within
the "service module" contained within the network element.
NOTE: The above defines a precise meaning for the word "service".
Service is a word which has a variety of meanings throughout the
networking community; the definition of "service" given here
refers specifically to the actions and responses of a single
network element such as a router or subnet. This contrasts with
the more end-to-end oriented definition of the same word seen in
some other networking contexts.
o Behavior
A "behavior" is the QoS-related end-to-end performance seen by an
application session. This behavior is the end result of composing the
services offered by each network element along the path of the
application's data flow.
When each network element along a data flow path offers the same
service, it is frequently possible to explain the resulting end-to-
end behavior in a straightforward fashion. The behavior of a data
flow path comprised of elements using different services is more
complicated, and may in fact be undefined. A future version of this
document may impose additional requirements on the service
specification relating to multi-service concatenation.
o Characterization
A characterization is a computed approximation of the actual end-to-
end behavior which would be seen by a flow requesting specific QoS
services from the network. By providing additional information to
the end-nodes before a flow is established, characterizations assist
the end-nodes in choosing the services to be requested from the
network.
o Characterization Parameters
Characterizations are computed from a set of characterization
parameters provided by each network element on the flow's path, and a
composition function which computes the end-to-end characterization
from those parameters. The composition function may in practice be
executed in a distributed fashion by the setup or routing protocol,
or the characterization parameters may be gathered to a single point
and the characterization computed at that point.
Shenker & Wroclawski Informational [Page 4]
RFC 2216 Network Element Service Template September 1997
Several characterizations may be computed for a single candidate data
flow. Conversely, a service may provide no characterizations, and
under some conditions no characterizations may be available to the
end-nodes requesting QoS services.
o Composition Function
A composition function accepts characterization parameters as input
and computes a characterization, as described above.
o Traffic Specification (TSpec)
A Traffic Specification, or TSpec, is a description of the traffic
pattern for which service is being requested. In general, the TSpec
forms one side of a "contract" between the data flow and the service.
Once a service request is accepted, the service module has agreed to
provide a specific QoS as long as the flow's data traffic continues
to be accurately described by the TSpec.
As examples, this specification might take the form of a token bucket
filter (defined below) or an upper bound on the peak rate. Note that
the traffic specification specifies the flow's *allowed* traffic
pattern, not the flows *actual* traffic pattern. The behavior of a
service when a flow's actual traffic does not conform to the traffic
specification must be defined by the service (see "Policing" below).
o Service Request Specification (RSpec)
A Service Request Specification, or RSpec, is a specification of the
quality of service a flow wishes to request from a network element.
The contents of a service request specification is highly specific to
a particular service. As examples, these specifications might contain
information about bandwidth allocated to the flow, maximum delays, or
packet loss rates.
o Setup Protocol
A setup protocol is used to carry QoS-related information from the
end-nodes requesting QoS control to network elements which must
exercise that control, and to install and maintain to required QoS
control state in those network elements. A setup protocol may also
be used to collect QoS-related information from interior network
elements along an application's data flow path for ultimate delivery
to end nodes. Examples of protocols which perform setup functions are
RSVP [RFC 2205], ST-II [RFC 1819], and Q.2931.
Shenker & Wroclawski Informational [Page 5]
RFC 2216 Network Element Service Template September 1997
Note that other mechanisms, such as network management protocols, may
also perform this function. The phrase "setup protocol"
conventionally refers to a protocol with this function as its primary
purpose.
o Token Bucket
A Token Bucket is a particular form of traffic specification
consisting of a "token rate" r and a "bucket size" b. Essentially,
the r parameter specifies the continually sustainable data rate,
while the b parameter specifies the extent to which the data rate can
exceed the sustainable level for short periods of time. More
specifically, the traffic must obey the rule that over all time
periods, the amount of data sent cannot exceed rT+b, where T is the
length of the time period.
Token buckets are further discussed in [PARTRIDGE].
o Token Bucket Filter
A Token Bucket Filter is a filtering or policing function which
differentiates those packets in a traffic flow which conform to a
particular token bucket specification from those packets which do
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -