Next Steps in Signaling C. Kappler
Internet-Draft Siemens AG
Expires: April 17, 2006 X. Fu
Univ. Goettingen
October 14, 2005
A QoS Model for Signaling IntServ Controlled-Load Service with NSIS
draft-kappler-nsis-qosmodel-controlledload-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a QoS Model to signal IntServ controlled load
service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS
Model specific information is carried in an opaque object, the QSPEC.
This document hence specifies the QSPEC for controlled load service,
how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP
messages must be used.
Kappler & Fu Expires April 17, 2006 [Page 1]
Internet-Draft Controlled-Load QOSM October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling with QoS NSLP . . . . . . . . . . . . . . . . . . . 3
2.1. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. QoS Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IntServ Controlled Load Service . . . . . . . . . . . . . . . 5
4. NSIS QoS Model for IntServ Controlled Load Service . . . . . . 6
4.1. Role of QNEs . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. QSPEC Definition . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Controlled Load Service Requirements . . . . . . . . . 7
4.2.2. QOSM ID . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. QSPEC Control Information . . . . . . . . . . . . . . 8
4.2.4. QoS Description . . . . . . . . . . . . . . . . . . . 8
4.3. Usage of QoS-NSLP Messages -- QSPEC Procedures . . . . . . 9
5. Processing Rules in QNEs . . . . . . . . . . . . . . . . . . . 10
5.1. Admission Control . . . . . . . . . . . . . . . . . . . . 10
5.2. Packet Scheduling and Excess Treatment . . . . . . . . . . 11
6. Interoperation with Controlled Load Service Specified in
RFC2211 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. QSPEC Format for Controlled Load QOSM . . . . . . . . 17
Appendix B. Change Tracker . . . . . . . . . . . . . . . . . . . 21
B.1. Open issues . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 22
B.3. Changes since -01 . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Kappler & Fu Expires April 17, 2006 [Page 2]
Internet-Draft Controlled-Load QOSM October 2005
1. Introduction
The QoS NSIS Signaling Layer Protocol, QoS-NSLP [19] defines how to
signal for QoS reservations in the Internet. The protocol is not
bound to a specific mechanism for achieving QoS, such as IntServ or
DiffServ. Rather, the actual QoS information is carried opaquely in
the protocol in a separate object, the QSPEC [19]. A method for
achieving QoS a for a traffic flow is called QoS model. It is
expected that a number of QoS models will be developed for QoS-NSLP.
Examples are [6] and [7] and this draft.
The purpose of this document is to describe a QoS model for
controlled-load service of IntServ [5]. In [10] it is specified how
to signal for controlled-load service with RSVP. This document
describes how to signal for the same service with QoS-NSLP.
The controlled-load service is rather minimal both in terms of
information that is signaled - basically bandwidth in the form of a
token bucket - and in terms of prescribed realization of the service
in the network. It is therefore suited for a wide range of
realizations, such as reserving resources per-flow per-network node
[8], achieving QoS in appropriately engineered DiffServ networks with
admission control [16], or across IP tunnels or MPLS Label Switched
Paths (LSPs) with reserved bandwidths and admission control [14]
[17].
The document is structured as follows: It gives a brief overview of
QoS-NSLP and the QSPEC, and the content and features of a QoS model
as described in [19] and [4]. It then gives a brief overview of the
controlled-load service of IntServ. Subsequently, the actual QoS
model for controlled-load service is described. A section describing
the interoperation of QoS NSLP and RSVP, both for signaling
controlled-load service, is also provided.
2. Signaling with QoS NSLP
2.1. QoS NSLP
QoS NSLP [19] is an NSIS signaling layer protocol for signaling QoS
reservations in the Internet. Together with GIST [18], it provides
functionality similar to RSVP and extends it, e.g. by supporting both
sender-initiated and receiver-initiated reservations. QoS-NSLP
however does not support multicast. QoS NSLP establishes and
maintains reservation state in QoS-NSLP aware nodes, called QNEs,
along the path of a data flow. The number or frequency of QNEs is
not prescribed. The node initiating a reservation request is called
QNI, the node terminating the request is called QNR. QNI and QNR are
Kappler & Fu Expires April 17, 2006 [Page 3]
Internet-Draft Controlled-Load QOSM October 2005
also QNEs, and are not necessarily the actual sender and receiver of
the data flow they are signaling for as they may also be proxying for
them.
QoS-NSLP defines four message types, RESERVE, QUERY, RESPONSE and
NOTIFY. The message type identifies whether a message manipulates
state (e.g. RESERVE) or not (e.g. QUERY, RESPONSE). The RESERVE
message is used to create, refresh, modify or remove reservation
state in QNEs. The QUERY message is used to request information
about the data path without making a reservation. This functionality
can be used to 'probe' the path for certain characteristics. The
RESPONSE message is used to provide information about the results of
a previous RESERVE or QUERY message, e.g. confirmation of a
successful reservation, error, or for transferring results of a QUERY
back towards the querying node. The NOTIFY message is not important
in the context of this memo.
2.2. QSPEC
QoS NSLP carries QoS Model specific information encapsulated in an
opaque object, the QSPEC [4]. The QSPEC thus fulfills a similar
purpose as TSpec, RSpec and AdSpec in RSVP [9]. The QSPEC is not
interpreted by the QoS NSLP Processing unit on a QNE, but passed
as-is to the Resource Management Function RMF on the same node, where
it is interpreted.
The QSPEC is structured internally into QSPEC Control Information,
and QoS Description.
o QSPEC Control Information contains parameters that govern the
processing of the resource request in the RMF, e.g. information on
excess treatment.
o QoS Description is composed of QSPEC objects, namely QoS Desired,
QoS Available, QoS Reserved and Minimum QoS. A particular QoS
Description typically only contains a subset of these objects.
* QoS Desired contains parameters describing the QoS desired by a
QNI.
* QoS Available contains parameters describing the available
resources. In the controlled load service QOSM, this QSPEC
object is used to collect information on the available
bandwidth along a path.
* QoS Reserved describes the actual QoS reserved.
* Minimum QoS can be included by a QNI together with QoS Desired
to signal a range of QoS (between QoS Desired and Minimum QoS)
is acceptable.
The QSPEC template [4] defines a number of mandatory and optional
QSPEC parameters. Mandatory parameters must be interpreted by each
QNE, whereas optional parameters can also be ignored. This ensures
Kappler & Fu Expires April 17, 2006 [Page 4]
Internet-Draft Controlled-Load QOSM October 2005
some degree of interoperability between QoS Models while at the same
time providing extensibility and flexibility. In a given QoS Model,
new optional parameters may be defined.
The QSPEC carries a QoS Model identifier, which identifies what QoS
Model is being signaled about. This QoS Model defines what
parameters must be included in a given QSPEC. However, the QNI may
also include additional parameters, in order to give additional
information to QNEs that are not supporting this specific QoS Model.
2.3. QoS Model
A QoS-enabled domain supports a particular QoS model (QOSM), which is
a method to achieve QoS for a traffic flow, such as IntServ
Controlled Load or DiffServ [13]. QoS NSLP is independent of the
QOSM, just as RSVP [9] is independent of IntServ. A QOSM hence
incorporates QoS provisioning methods and a QoS architecture. It
however also defines how to use QoS NSLP. It therefore defines the
behavior of the resource management function (RMF), including inputs
and outputs, and how QSPEC information on traffic description,
resources required, resources available, and control information
required by the RMF is interpreted. A QOSM also specifies the QSPEC
parameters that describe the QoS and how resources will be managed by
the RMF.
3. IntServ Controlled Load Service
As specified in [5], the controlled-load service defined for IntServ
supports applications which are highly sensitive to overload
conditions, e.g. real-time applications. The controlled-load service
provides to an application approximately the end-to-end service of an
unloaded best-effort network. "Unloaded" thereby is used in the
sense of "not heavily loaded or congested" rather than in the sense
of "no other network traffic whatsoever".
The definition of controlled-load service is intentionally imprecise.
It implies a very high percentage of transmitted packets will be
successfully delivered to the end nodes. Furthermore, the transit
delay experienced by a very high percentage of the delivered packets
will not greatly exceed the minimum transmit delay experienced by any
successfully delivered packet. In other words, a short disruption of
the service is viewed as a statistical effect which may occur in
normal operation. Events of longer duration are indicative of
failure to allocate sufficient resources to the controlled-load flow.
In order to ensure that the conditions on controlled-load service are
met, clients requesting the service provide network elements on the
Kappler & Fu Expires April 17, 2006 [Page 5]
Internet-Draft Controlled-Load QOSM October 2005
data path with an estimation of the data traffic they are going to
generate. When signaling with RSVP, the object carrying this
estimation is called TSpec. In return, the service ensures that in
each network element on the data path, resources adequate to process
traffic falling within this descriptive envelope will be available to
the client. This must be accomplished by admission control.
The controlled-load service is implemented per-flow in each network
element on the data-path. Thereby, a network element may be an
individual node such as a router. However, a network element can
also be a subnet, e.g. a DiffServ cloud within a larger IntServ
network [16]. In this case, the per-flow traffic description (e.g.
carried in the RSVP TSpec) together with the DiffServ Code Point
(carried e.g. in the DCLASS object [15] of RSVP) is used for
admission control into the DiffServ cloud. The DiffServ cloud must
ensure it provides controlled-load service. It is also possible to
operate controlled-load service over logical links such as IP tunnels
[14] or MPLS LSPs [17]. The per-flow traffic descriptor is in this
case used for admission control into the tunnel/LSP.
4. NSIS QoS Model for IntServ Controlled Load Service
According to [4], a QOSM SHOULD include the following information:
o Role of QNEs in this QOSM: E.g. location, frequency, statefulness
etc.
o QSPEC Definition: A QOSM SHOULD specify the QSPEC, including QSPEC
parameters. Furthermore it needs to explain how mandatory QSPEC
parameters not used in this QOSM are mapped onto parameters
defined therein.
o QSPEC procedures: describes how to signal the QOSM.
o Processing Rules: it describes how QSPEC info is treated and
interpreted in the RMF and QOSM specific processing. E.g.
admission control, scheduling, policy control, QoS parameter
accumulation (e.g. delay).
o Operation and Sequence of Events, i.e. what QSPEC procedures to
use to signal the QOSM.
o Message Format and QSPEC objects to be carried in RESERVE, QUERY
RESPONSE and NOTIFY.
Subsequent sections treat these points one-by-one. An example bit-
level QSPEC format is given in Appendix A.
4.1. Role of QNEs
Controlled-load service network elements can be individual routers or
subnets. I.e. it is not necessary for each network node on the data
path to interpret the signaling for the service. Rather, dedicated
Kappler & Fu Expires April 17, 2006 [Page 6]
Internet-Draft Controlled-Load QOSM October 2005
nodes may interpret signaling information and take on responsibility
that the subnet they represent delivers adequate service. In fact,
this setting maps nicely onto QoS-NSLP - and the NSIS protocol suite
in general. In NSIS, QNEs are just required to be located on the
data path. However there are no prescriptions regarding their number
or frequency. Hence, in the controlled-load QoS model, there must be
(at least) one QNE acting on behalf of every network element. E.g.
all ingress routers to a DiffServ cloud could be QNEs, performing
admission control. If there is more than one QNE per network
element, they must be coordinated among themselves to ensure the
network element delivers controlled-load service. Controlled Load
QNEs are always stateful.
4.2. QSPEC Definition
4.2.1. Controlled Load Service Requirements
The controlled-load service QOSM uses Token_Bucket parameters[4],
which consist of a token bucket specification (i.e. bucket rate r and
a bucket depth b) plus a peak rate (p), a minimum policed unit (m)
and a maximum packet size (M) to describe a data flow's required
resources. The minimum policed unit m is an integer measured in
bytes. All IP datagrams of size less than m are counted against the
token bucket as being of size m. For more details, including value
ranges of the parameters see [10].
The controlled-load service has no required characterization
parameters the QNI needs to be informed about, i.e. current
measurement and monitoring information need not be exported by QNEs,
although individual implementations may do so if they wish.
When using RSVP to signal for controlled-load services, the PATH
message collects information on MTU and available bandwidth which is
used by the receiver to adapt the reservation parameters in the
RESERVE message [10][11]. It is hence related to the signaling for
Controlled Load rather than to the Controlled Load Service itself.
Indeed, while collecting path MTU can be useful for achieving QoS, it
is not considered to be part of QoS signaling or QOSMs [4] in NSIS;
rather, an independent path MTU discovery mechanism (e.g., [22])
during the flow setup phase is assumed to provide means to learn
about the path MTU. Available bandwidth may be collected if desired
and used for controlled load service QOSM.
4.2.2. QOSM ID
See Section 8.
Kappler & Fu Expires April 17, 2006 [Page 7]
Internet-Draft Controlled-Load QOSM October 2005
4.2.3. QSPEC Control Information
QSPEC Control Information for controlled load service QOSM provides
information about QOSM support along the path followed by a data
flow. In addition, information on Excess Treatment (drop or reshape)
MAY be included.
In RSVP, when non-IntServ hops are discovered on the path, a flag is
raised. Additionally, the number of IntServ hops is counted. This
way a sender or receiver can determine whether end-to-end QoS could
be achieved. The QSPEC template defines a similar parameter, namely
the <NON QOSM Hop> flag. It is set to 1 if a QNE unaware of
Controlled Load Service is encountered on the path from the QNI to
the QNR. Discussions: per [4], <NON QOSM Hop> is just a flag;
counting the number of non QOSM hops is currently a function of QoS
NSLP.
Furthermore, Excess Treatment parameter MAY be included in the
control information. Currently supported values are "reshape" or
"drop" and the default value (if the parameter is not included in the
Control Information) is "reshape". This parameter is used for a
controlled load service implementation to handle the received data
traffic belonging to a controlled load flow which is "non-conformant"
to the Token Bucket specification reserved. Traffic is considered
"non-conformant" when:
over time period T, the amount of data received exceeds rT+b; or
data rate of the traffic exceeds the peak rate p; or
data packet size is larger than M or the QNE's outgoing link MTU
4.2.4. QoS Description
The QoS Description can contain some or all of the following objects:
<QoS Desired> = <Token Bucket>
<QoS Available> = <Bandwidth>
<Minimum QoS> = <Token Bucket>
<QoS Reserved> = <Token Bucket>
Among them, <QoS Desired> and <QoS Reserved> MUST be supported by all
QOSM implementations, as defined in [4].
<QoS Available> is required for receiver-initiated reservations, and
MAY be used in sender-initiated reservations. It is used for
gathering available bandwidth information along the path. This
information can be used by QNI (or QNR, for receiver-initiated
Kappler & Fu Expires April 17, 2006 [Page 8]
Internet-Draft Controlled-Load QOSM October 2005
reservations) to make an appropriate reservation thereafter,
particularly to re-issue a failed reservation.
<Minimum QoS> is optional. It always travels together with <QoS
Desired>. It signifies that the QNI can accept a downgrade of
resources for particular parameters in the reservation, down to the
value of the respective parameter in <Minimum QoS>. For parameters
not appearing in <Minimum QoS>, it cannot accept a downgrade. For
controlled load service this means if <token bucket> is included, a
downgrade of all token bucket parameters is possible.
In all QSPEC objects additional parameters MAY be included, as
described in [4].
4.3. Usage of QoS-NSLP Messages -- QSPEC Procedures
QoS-NSLP allows a variety of message sequences for reserving
resources ("QSPEC Procedures"). Particularly, sender-initiated,
receiver-initiated and bi-directional messages are possible. E.g.,
in sender-initiated reservations, a RESERVE is issued by the QNI. If
the reservation is successful, the QNR replies with a RESPONSE. If
the reservation fails, the QNE at which it failed sends a RESPONSE
(QoS NSLP is not quite clear on this).
The QSPEC template defines what QSPEC objects are carried in which of
these messages, and how they are translated from message-to-message.
For each of the message patterns defined in QoS NSLP, a variety of
QSPEC object usages, the so-called QSPEC Procedures, are possible.
o in the simplest message sequence, sender-initiated reservations,
the RESERVE may carry just <QoS Desired> to indicate the exact QoS
it wants, and the corresponding RESPONSE carries solely <QoS
Reserved>. This implies either the exact resources described in
<QoS Desired> are reserved, or the reservation fails.
o A more advanced QNI would include, in addition to <QoS Desired>, a
<QoS Available> QSPEC object, or even a <Minimum QoS>. <QoS
Available> allows collecting path properties, e.g. currently
available bandwidth, and <Minimum QoS> signals that (and how much)
less resources than <QoS Desired> are acceptable. The RESPONSE
message carries <QoS Reserved>, and additionally copies the <QoS
Available> QSPEC Object from RESERVE. This information may be of
particular interest if a reservation failed. Note however, that
since the QNE failing the reservation sends the RESPONSE, no
complete e2e information on e.g. bandwidth can be collected and
delivered to the QNI. Generally, it needs to be discussed what is
the most efficient way of providing feedback to the QNI for
sender-initiated reservations.
Kappler & Fu Expires April 17, 2006 [Page 9]
Internet-Draft Controlled-Load QOSM October 2005
o In an "RSVP-style" receiver-initiated reservation, the sender
(QNR) issues a QUERY with <QoS Available> collecting information
on available bandwidth. The receiver (QNI) reacts with a RESERVE
message containing <QoS Desired> with a token bucket whose values
are derived from the collected bandwidth information. The
signaling exchange is concluded with a RESPONSE by the QNR
including a <QoS Reserved> echoing the token bucket that was
reserved.
Note that the initial message triggering the signaling exchange fully
determines the sequencing of subsequent messages, and also determines
what QSPEC objects will be carried in them. That is, only the QNI
has freedom in choosing a particular QSPEC procedure. Other QNEs can
only react to this.
The controlled load service parameters can be signaled with any QSPEC
procedure. Note, in contrast, in RSVP only one type of message
exchange is defined (receiver-initiated reservations, and the
equivalent of <Minimum QoS> = 0). However, this is a characteristic
of RSVP rather than of the controlled load service.
5. Processing Rules in QNEs
5.1. Admission Control
For controlled-load service, QNEs are required to perform admission
control. All resources important to the operation of the network
element must be considered when admitting a request. Common examples
of such resources include link bandwidth, router or switch port
buffer space, and computational capacity of the packet forwarding
engine. It is not prescribed how a QNE determines adequate resources
are available. It is however required that they make bandwidth
greater than the token rate available to the flow in certain
situations in order to account for fluctuations. E.g. statistical
methods may be used to determine how much bandwidth is necessary.
During the admission control, the controlled-load service Token
Bucket parameters MUST be met according to the following rule: a
Token Bucket A to be allocated for a flow MUST be "as good or better
than" or "greater than or equal to" Token Bucket B (which is carried
in the received QoS Description, e.g., QoS Desired, or Minimum QoS if
available), i.e.,:
the token bucket rate r for Token Bucket A is greater than or
equal to that of Token Bucket B, and
the token bucket depth b for Token Bucket A is greater than or
equal to that of Token Bucket B, and
Kappler & Fu Expires April 17, 2006 [Page 10]
Internet-Draft Controlled-Load QOSM October 2005
the peak rate p for Token Bucket A is greater than or equal to
that of Token Bucket B, and
the minimum policed unit m for Token Bucket A is less than or
equal to that of Token Bucket B, and
the maximum packet size M of Token Bucket A is greater than or
equal to that of Token Bucket B.
Remark: these rules come originally from rules for ordering token
buckets in [5].
There are no target values for other parameters, e.g. delay or loss,
other than providing a service closely equivalent to that provided to
best-effort traffic under lightly loaded conditions.
Although path MTU discovery is not necessarily part of the controlled
load service QOSM, controlled load service QOSM QNEs must reject a
service request (by returning an admission control error) if the
maximum packet size M signaled in <QoS Desired>, resp. in <Minimum
QoS> if available, is bigger than the MTU of the segment of the path
managed by this QNE.
Resource requests for new flows are accepted if capacity is
available. Reservation modifications are accepted if the new <token
bucket> is strictly smaller than the old one. Otherwise they are
treated like new reservations from an admission control perspective.
5.2. Packet Scheduling and Excess Treatment
A QNE MUST ensure the Token Bucket requirements for any individual
flow given at setup time are met locally. That is, traffic MUST obey
the rule that over all time periods, the amount of data sent does not
exceed rT+b. Packets smaller than m are counted as of size m. A
basic requirement for packet scheduling is that the QNE MUST ensure
the QoS requirements are met for traffic belonging to flows whose
traffic are all conformant.
In presence of arriving non-conformant traffic, the QNE MUST behave
as follows:
the QNE MUST continue to provide the contracted QoS for traffic
belonging to flows which are all conformant.
the QNE SHOULD prevent excess control load traffic from unfairly
impacting the handling of arriving best-effort traffic.
While fulfilling the above two requirements, the QNE MUST attempt
to forward the excess traffic on a best-effort basis if sufficient
resources are available, unless indicated differently by <Excess
Treatment>.
Several basic approaches for excess treatment are suggested in [5]
Kappler & Fu Expires April 17, 2006 [Page 11]
Internet-Draft Controlled-Load QOSM October 2005
and reused here, although other alternatives are possible, if
available. A simple approach is the priority mechanism, namely, to
let the QNE process excess controlled-load traffic at a lower
priority than the elastic best-effort traffic, especially when the
most controlled-load traffic arises from non-rate-adaptive real-time
applications.
The second approach is that a QNE can maintain separate flow classes
(e.g., one for each non-conformant controlled-load traffic, one for
inelastic best-effort flows, and another from elastic best-effort
flows), where packet scheduling mechanisms like Fair Queueing or
Weight Fair Queueing can be used. One implementation, for instance,
could allocate each controlled-load flow a 1/N "fair share"
percentage of the available best effort bandwidth for its excess
traffic.
Finally, Random Early Detection (RED) queueing mechanism may be used.
6. Interoperation with Controlled Load Service Specified in RFC2211
The controlled-load service QOSM is intended to be consistent with
the RSVP/Controlled Load Service specified in [5], although the
signaling protocols used are QoS-NSLP and RSVP, respectively. This
section discusses how a router implementing both RSVP and QoS NSLP
could translate from one to the other.
The following is a table contains a mapping of messages, objects and
parameters between QoS NSLP and RSVP for the specific case of
controlled-load signaling using the "RSVP-style" receiver-initiated
signaling described in Appendix A. For other QSPEC procedures (e.g.
sender-initiated signaling) the mapping may be different, or even
impossible.
| Message | Object(s) | Parameter(s)
--------------------------------------------------------------------
RSVP | Path | (1) ADSpec | avail. Bw and MTU
| | (2) Sender TSpec | Token Bucket
QoS NSLP | QUERY | QoS Avail. | avail. Bandwidth
| | |
RSVP | Resv | FlowSpec | Token Bucket
QoS NSLP | RESERVE | QoS Desired | Token Bucket
| | |
RSVP |ResvConfirm| |
QoS NSLP | RESPONSE | QoS Reserved | Token Bucket
Kappler & Fu Expires April 17, 2006 [Page 12]
Internet-Draft Controlled-Load QOSM October 2005
It is evident from the table above that some objects, particularly
Sender-TSpec and ADSpec cannot be mapped easily. The SenderTSPEC in
RSVP specifies the traffic an application is going to send. The RSVP
AdSpec probes the available bandwidth on the data path. In QoS NSLP,
the sender queries the network for the QoS that is available. It
carries the "available bandwidth" parameter which is then updated by
all QNEs to reflect the QoS that is actually available. See
Section 4.3 for a detailed description of QSPEC procedure for
controlled-load service.
Note that under controlled-load QOSM, there is no MTU discovery as in
RSVP/CLS, where path MTU is a mandatory parameter. This relieves the
QNE from being overloaded with the orthogonal task of determining
path MTU.
7. Security Considerations
This Internet Draft raises no new security issues.
8. IANA Considerations
A new QOSM ID ("Controlled-Load Service QOSM") needs to be assigned
by IANA.
9. Conclusions
This document describes a QoS Model to signal IntServ controlled load
service with QoS NSLP. Up to now, it was only described how to
signal for IntServ controlled load service with RSVP. Since no
independent document exists that describes IntServ controlled load by
its own, i.e. without RSVP, it is sometimes difficult to determined
what features are specific to IntServ controlled load, and which
features are specific to RSVP:
Is it indeed vital for QNIs signaling for controlled load service
to be informed about the number of hops not implementing this
QOSM? Since the controlled load QOSM exclusively relies on
mandatory parameters it can be expected that all QNEs can make
sense of the reservation, independent of whether they explicitly
implement controlled load service or not. Of more interest
appears the number of non-QoS-NSLP hops (which is collected in the
main message body of QoS NSLP rather than in the QSPEC).
The QoS NSLP QOSM for controlled load service allows a variety of
message exchanges all eventually resulting in a reservation, e.g.
sender-initiated, receiver-initiated and bidirectional signaling.
The controlled load service when signaled with RSVP was bound to
Kappler & Fu Expires April 17, 2006 [Page 13]
Internet-Draft Controlled-Load QOSM October 2005
sender-initiated reservations.
When signaling with RSVP, it is not possible to define a range of
acceptable QoS. Also this seems to be a characteristic of RSVP
rather than a feature of the controlled load service.
RSVP allows discovery of path MTU. Since independent mechanisms
area exist to this end, this feature has not been reproduced by
the Controlled Load QOSM (and QoS NSLP in general)
An issue of general interest discovered here concerns feedback of
information in sender-initiated scenarios (In receiver-initiated
scenarios it does not occur because path information is collected
before the RESERVE is issued). A QNI may include in <QoS Available>
several parameters, e.g. bandwidth, which it would like to measure
along the data path. If the reservation fails, e.g. because the
desired bandwidth was to large, the QNE failing the reservation
returns a RESPONSE, including the <QoS Available> QSPEC object with
accumulated information up to this point. The QNI can learn from
this why the reservation failed at this particular QNE. However it
cannot be sure a subsequent downgraded RESERVE will be more
successful. This is because there may be even more difficult
conditions (e.g. even less bandwidth) down the path. That is, in
sender-initiated scenarios it is not straightforward to receive
feedback from a failed reservation that allows to make a good guess
at what size of reservation would be more successful. Of course it
would be possible for the QNI to issue a QUERY first to find out
about a suitable value for, e.g. maximum packet size. However this
adds another round-trip time to the reservation, thereby obsoleting
one of the main benefits of sender-initiated reservations compared to
receiver-initiated ones.
Another issue is that <QoS Desired> may also include <QoS Class>. Is
it useful for Controlled Load Service QOSM?
In this draft, the feedback problem is solved by including a <Minimum
QoS> QSPEC object in sender-initated reservations. This gives some
flexibility as it implicitly says the QNI would also accept a
downgraded reservation, up to the value specified. When the maximum
packet size in <Minimum QoS> is set to a very small value
reservations are not going to fail because of the MTU problem. Note
however as currently specified in [19], the <Minimum QoS> QSPEC
object is not necessarily supported by all QNEs.
10. References
Kappler & Fu Expires April 17, 2006 [Page 14]
Internet-Draft Controlled-Load QOSM October 2005
10.1. Normative References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[2] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
[4] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06
(work in progress), October 2005.
[5] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
10.2. Informative References
[6] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS
Model", draft-ietf-nsis-rmd-03 (work in progress), July 2005.
[7] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using
Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in
progress), May 2005.
[8] Braden, B., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[10] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[11] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.
[12] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
[13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
Kappler & Fu Expires April 17, 2006 [Page 15]
Internet-Draft Controlled-Load QOSM October 2005
[14] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
Operation Over IP Tunnels", RFC 2746, January 2000.
[15] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[16] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation over
Diffserv Networks", RFC 2998, November 2000.
[17] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[18] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-08 (work in
progress), September 2005.
[19] Bosch, S., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-07 (work in progress), July 2005.
[20] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress),
July 2005.
[21] "Path Computation Element (pce) Charter,
http://www.ietf.org/html.charters/pce-charter.html", 2005.
[22] "Path MTU Discovery (pmtud) Charter,
http://www.ietf.org/html.charters/pmtud-charter.html", 2005.
[23] "IP Flow Information Export (ipfix) Charter,
http://www.ietf.org/html.charters/ipfix-charter.html", 2005.
[24] "NGN QoS Framework and Requirements", DTS/TISPAN-05009-NGN.
[25] Lee, S., "Applicability Statement of NSIS Protocols in Mobile
Environments",
draft-ietf-nsis-applicability-mobility-signaling-02 (work in
progress), July 2005.
[26] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[27] Alfano, F., "Diameter Quality of Service Application",
draft-alfano-aaa-qosprot-04 (work in progress), September 2005.
[28] Farrel, A., "Path Computation Element (PCE) Architecture",
Kappler & Fu Expires April 17, 2006 [Page 16]
Internet-Draft Controlled-Load QOSM October 2005
draft-ietf-pce-architecture-02 (work in progress),
September 2005.
[29] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[30] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[31] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding
and Control Element Separation (ForCES) Framework", RFC 3746,
April 2004.
Appendix A. QSPEC Format for Controlled Load QOSM
This section provides two example formats for a QSPEC used by
controlled load QOSM in a successful sender-initiated reservation.
For details about the coding refer to [4]. Other scenarios can be
easily derived by adapting to the QoS-NSLP signaling procedure and
used QoS specifications. Also, more parameters can be added by the
QNI if it feels this is necessary.
The first example is a "minimal" QSPEC for Controlled Load, which is
the QSPEC containing the least number of objects and parameters. It
signals for sender-initiated reservations, containing only the QOSM
Hops flag as control information, and the token bucket for QoS
Desired. It is interesting to note that the difference between the
QSPEC in the RESERVE and the RESPONSE message is only slight. The
actual values of the parameters are of course different. Beyond
this, the second QSPEC object is identified as "QoS Desired" in
RESERVE with Read-write flag and as "QoS Reserved" in the RESPONSE
message with Read-only flag.
Kappler & Fu Expires April 17, 2006 [Page 17]
Internet-Draft Controlled-Load QOSM October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID = Ctrld Load | 0 | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|QOSM_ID= TBD | QSPEC_Lenth = 64| NON QOSM Hop | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=0(ctrl) | Obj_Lenth = 4 | Excess treatm.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|r|r|Object Type = Ctrl.Info|r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 1 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NON QOSM Hop| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|r|r|Object Type = QoS Des. |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=1(QoSDe)| Obj_Lenth = 24| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 5 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=2(QoSAv)| Obj_Lenth = 8 | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| available bandwidth (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=4(MiQoS)| Obj_Lenth = 24| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 A minimal QSPEC for sender initiated reservation (RESERVE)
Kappler & Fu Expires April 17, 2006 [Page 18]
Internet-Draft Controlled-Load QOSM October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID = Ctrld Load | 0 | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|r|r|Object Type = Ctrl.Info|r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 1 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NON QOSM Hop| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|r|r|Object Type = QoS Res. |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 5 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|QOSM_ID= TBD | QSPEC_Lenth = 40| NON QOSM Hop | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=0(ctrl) | Obj_Lenth = 4 | Excess treatm.| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=3(QoSDe)| Obj_Lenth = 24| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Obj_ID=2(QoSAv)| Obj_Lenth = 8 | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| available bandwidth (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2 An Example QSPEC for sender initiated reservation (RESPONSE)
The other example is a "RSVP-style QSPEC", that is, it mimics the way
RSVP signals for Controlled Load as closely as possible. It signals
for receiver-initiated reservations, and consists of a 3-way message
Kappler & Fu Expires April 17, 2006 [Page 19]
Internet-Draft Controlled-Load QOSM October 2005
exchange featuring QUERY, RESERVE and RESPONSE, see [4] for details.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID = Ctrld Load | 1 | 3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|r|r|Object Type = Ctrl.Info|r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 1 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NON QOSM Hop| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|r|r|Object Type = QoS Avl. |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 3 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| available bandwidth (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 3 A QSPEC for "RSVP-style" reservations (QUERY)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID = Ctrld Load | 1 | 3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|r|r|Object Type = Ctrl.Info|r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 1 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NON QOSM Hop| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|r|r|Object Type = QoS Des. |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 5 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 4 A QSPEC for "RSVP-style" reservations (RESERVE)
Kappler & Fu Expires April 17, 2006 [Page 20]
Internet-Draft Controlled-Load QOSM October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID = Ctrld Load | 1 | 3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|r|r|Object Type = QoS Res. |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|N|T| 5 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 5 A QSPEC for "RSVP-style" reservations (RESPONSE)
Other scenarios can be easily derived by adapting to the QoS-NSLP
signaling procedure and used QoS specifications.
Appendix B. Change Tracker
B.1. Open issues
1. Review by IntServ CLS expert
2. Add section on what to do with mandatory QSPEC parameters which
are not needed for Controlled Load
3. Issue concerning the "RSVP-Style Reservation". In RSVP, the PATH
message sends a Sender_TSPEC (primarily token bucket reflecting the
sender traffic's characteristics) in addition to ADSpec. The token
bucket in the RESERVE message is an update of the token bucket in the
PATH message considering the available bandwidth. In QoS NSLP, there
are three alternative means for composing and interpreting the QSPEC
in a QUERY message:
o Use a single QoS Available object (which in turn carries available
bandwidth in QUERY, allow each QNE be able to modify and forward
it, and let the QNR originate a QoS Desired (Token Bucket) object
based on this QoS Available object. The current draft utilizes
this approach, however it is not clear whether this will be done.
o Use a token bucket (QNE-readonly) plus available bandwidth (QNE
readable and writable) in QUERY, and let the QNR compose the QoS
Desired based on the available bandwidth information gathered
along the path and the token bucket originally specified by the
Kappler & Fu Expires April 17, 2006 [Page 21]
Internet-Draft Controlled-Load QOSM October 2005
QNI. This is more similar to RSVP/IntServ but requires further
study.
o Use a single Token Bucket parameter as QoS Available object in
QUERY, let QNEs interpret certain fields in the Token Bucket
(e.g., average/peak rate) as bandwidth, and the QNR compose a new
Token Bucket as QoS Desired. This seems to simplify the object
but may need different interpretations of a Token Bucket.
B.2. Changes since -02
1. Added "RSVP-style reservation" as running example
1. Updated interoperability section
2. Aligned QSPEC example in Appendix A with update of QSPEC draft
and added more details
B.3. Changes since -01
1. Clarifications about path MTU, scheduling/excess treatment and
QOSM Hops.
2. Added a section "Interoperation with RFC2211" and QSPEC format as
Appendix.
Appendix C. Acknowledgements
The authors would like to thank Andrew McDonald for fruitful
discussions. John Loughney and Bob Braden provided useful comments.
Kappler & Fu Expires April 17, 2006 [Page 22]
Internet-Draft Controlled-Load QOSM October 2005
Authors' Addresses
Cornelia Kappler
Siemens AG
Siemensdamm 62
13627 Berlin
Germany
Email: cornelia.kappler@siemens.com
Xiaoming Fu
University of Goettingen
Institute for Informatics
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
Kappler & Fu Expires April 17, 2006 [Page 23]
Internet-Draft Controlled-Load QOSM October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kappler & Fu Expires April 17, 2006 [Page 24]