Internet DRAFT - draft-kappler-nsis-qosmodel-controlledload
draft-kappler-nsis-qosmodel-controlledload
Network Working Group C. Kappler
Internet-Draft ck technology concepts
Intended status: Informational X. Fu
Expires: March 7, 2012 B. Schloer
Univ. Goettingen
September 4, 2011
A QoS Model for Signaling IntServ Controlled-Load Service with NSIS
draft-kappler-nsis-qosmodel-controlledload-14
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 7, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Kappler, et al. Expires March 7, 2012 [Page 1]
Internet-Draft Controlled-Load QOSM September 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Kappler, et al. Expires March 7, 2012 [Page 2]
Internet-Draft Controlled-Load QOSM September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Signaling with QoS NSLP . . . . . . . . . . . . . . . . . . . 5
3.1. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. QoS Model . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IntServ Controlled Load Service . . . . . . . . . . . . . . . 7
5. NSIS QoS Model for IntServ Controlled Load Service . . . . . . 8
5.1. Role of QNEs . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. QSPEC Definition . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Controlled Load Service Requirements . . . . . . . . . 9
5.2.2. QSPEC Objects . . . . . . . . . . . . . . . . . . . . 10
5.3. Usage of QoS NSLP Messages -- QSPEC Procedures . . . . . . 11
6. Processing Rules in QNEs . . . . . . . . . . . . . . . . . . . 12
6.1. Admission Control . . . . . . . . . . . . . . . . . . . . 12
6.2. Packet Scheduling and Excess Treatment . . . . . . . . . . 13
7. Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Interoperation with Controlled Load Service Specified in
RFC2211 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Bit level Examples of QSPEC objects for
Controlled Load QOSM . . . . . . . . . . . . . . . . 18
A.1. Minimal QSPEC objects for Sender-Initiated Reservation . . 18
A.2. Extended QSPEC objects for Sender-Initiated Reservation . 19
A.3. Receiver Initiated Reservation (RSVP Style) . . . . . . . 21
A.4. Resource Queries . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Change Tracker . . . . . . . . . . . . . . . . . . . 25
B.1. Changes since -13 . . . . . . . . . . . . . . . . . . . . 25
B.2. Changes since -12 . . . . . . . . . . . . . . . . . . . . 25
B.3. Changes since -11 . . . . . . . . . . . . . . . . . . . . 25
B.4. Changes since -10 . . . . . . . . . . . . . . . . . . . . 25
B.5. Changes since -09 . . . . . . . . . . . . . . . . . . . . 26
B.6. Changes since -08 . . . . . . . . . . . . . . . . . . . . 26
B.7. Changes since -07 . . . . . . . . . . . . . . . . . . . . 26
B.8. Changes since -06 . . . . . . . . . . . . . . . . . . . . 26
B.9. Changes since -05 . . . . . . . . . . . . . . . . . . . . 26
B.10. Changes since -04 . . . . . . . . . . . . . . . . . . . . 26
B.11. Changes since -03 . . . . . . . . . . . . . . . . . . . . 26
B.12. Changes since -02 . . . . . . . . . . . . . . . . . . . . 26
B.13. Changes since -01 . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Kappler, et al. Expires March 7, 2012 [Page 3]
Internet-Draft Controlled-Load QOSM September 2011
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Kappler, et al. Expires March 7, 2012 [Page 4]
Internet-Draft Controlled-Load QOSM September 2011
1. Introduction
The QoS NSIS Signaling Layer Protocol, QoS NSLP [RFC5974] 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 [RFC5974]. A method for
achieving QoS 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 [RFC5977] and [RFC5976] and this draft.
The purpose of this document is to describe a QoS model for
controlled-load service of IntServ [RFC2211]. In [RFC2210] 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
[RFC1633], achieving QoS in appropriately engineered DiffServ
networks with admission control [RFC2998], or across IP tunnels or
MPLS Label Switched Paths (LSPs) with reserved bandwidths and
admission control [RFC2746] [RFC3031].
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 [RFC5974] and [RFC5975]. 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. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology defined in [RFC5974] and [RFC5975] applies to this
document.
3. Signaling with QoS NSLP
Kappler, et al. Expires March 7, 2012 [Page 5]
Internet-Draft Controlled-Load QOSM September 2011
3.1. QoS NSLP
QoS NSLP [RFC5974] is an NSIS signaling layer protocol for signaling
QoS reservations in the Internet. Together with GIST [RFC5971], 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
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
may 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. A NOTIFY message is sent
asynchronously and need not refer to any previously received message.
The information conveyed by a NOTIFY message is typically related to
error conditions.
3.2. QSPEC
QoS NSLP carries QoS Model specific information encapsulated in an
opaque object, the QSPEC [RFC5975]. The QSPEC thus fulfills a
similar purpose as TSpec, RSpec and AdSpec in RSVP [RFC2205]. The
QSPEC is not interpreted by the QoS NSLP Processing unit on a QNE,
but passed as-is to the Resource Management Function RMF, usually
located on the same node, where it is interpreted.
The QSPEC is composed of QSPEC objects, namely <QoS Desired>, <QoS
Available>, <QoS Reserved> and <Minimum QoS>. A QSPEC typically only
contains a subset of these objects. QSPEC objects contain a set of
QSPEC parameters that govern the processing of the resource request
in the RMF, e.g. information on excess treatment.
o <QoS Desired> contains parameters describing the QoS desired by a
QNI.
Kappler, et al. Expires March 7, 2012 [Page 6]
Internet-Draft Controlled-Load QOSM September 2011
o <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.
o <QoS Reserved> describes the actual QoS reserved.
o <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 [RFC5975] defines a number of QSPEC parameters.
<TMOD1> provides a description of the traffic for which resources are
reserved. This parameter MUST be interpreted by each QNE along the
path. All other QSPEC parameters MAY be signaled by the QNI if they
are applicable to the underlying QOS desired. The QNI sets the
M-Flag if they must be interpreted by downstream QNEs. If the
parameter cannot be interpreted by a QNE the reservation fails. A
QSPEC parameter without set M-Flag should be interpreted by the QNE
but may be ignored if it cannot be interpreted. In a given QoS
Model, new optional parameters may be defined.
3.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 [RFC2475]. QoS NSLP is independent of
the QOSM, just as RSVP [RFC2205] 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.
4. IntServ Controlled Load Service
As specified in [RFC2211], 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".
The definition of controlled-load service is intentionally imprecise.
It implies a very high percentage of transmitted packets will be
Kappler, et al. Expires March 7, 2012 [Page 7]
Internet-Draft Controlled-Load QOSM September 2011
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
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 [RFC2998]. 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 [RFC2996] 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 [RFC2746] or MPLS LSPs [RFC3031]. The per-flow traffic
descriptor is in this case used for admission control into the
tunnel/LSP.
5. NSIS QoS Model for IntServ Controlled Load Service
According to [RFC5975], a QOSM MUST include the following
information:
o role of QNEs, e.g., location, frequency, statefulness, etc.
o QSPEC definition including QSPEC parameters
o QSPEC procedures applicable to this QOSM
o QNE processing rules describing how QSPEC information is treated
and interpreted in the RMF, e.g., admission control, scheduling,
policy control, QoS parameter accumulation (e.g., delay).
o at least one bit-level QSPEC example
o QSPEC parameter behavior for new QSPEC parameters the QOSM
specification defines
o a defininition of what happens in case of preemption if the
default QNI behavior (tear down preempted reservation) is not
followed
Kappler, et al. Expires March 7, 2012 [Page 8]
Internet-Draft Controlled-Load QOSM September 2011
A QOSM specification MAY include the following information:
o defininitions of additional QOSM-specific error codes
o the QoS NSLP options a QOSM wants to use, when several options are
available for a QOSM (e.g., Local QSPEC to either a) hide
Initiator QSPEC within a local domain message, or b) encapsulate
Initiator QSPEC).
Subsequent sections treat these points one-by-one. Several example
bit-level QSPEC formats are given in Appendix A.
5.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
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. For
example all ingress routers to a DiffServ cloud could be QNEs,
performing admission control. If there is more than one network
element per QNE, they MUST be coordinated among to ensure they
delivers controlled-load service. Controlled Load QNEs are always
stateful.
5.2. QSPEC Definition
5.2.1. Controlled Load Service Requirements
The controlled-load service QOSM uses TMOD1 parameters[RFC5975],
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 (MPS). 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 [RFC2210].
The TMOD1 parameter contains a maximum packet size (MPS), as the
original token bucket does (MTU). 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 RESV message [RFC2210][RFC2215].
In QoS NSLP the TMOD1 parameter collecting resource information on
the path may be included in QUERY, RESERVE or RESPONSE messages.
Kappler, et al. Expires March 7, 2012 [Page 9]
Internet-Draft Controlled-Load QOSM September 2011
Available bandwidth may be collected if desired and used for
controlled load service QOSM. 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.
5.2.2. QSPEC Objects
The QSPEC can contain some or all of the following objects:
<QoS Desired> = <TMOD1>
<QoS Available> = <TMOD1>
<Minimum QoS> = <TMOD1>
<QoS Reserved> = <TMOD1>
Among them, <QoS Desired>, <QoS Available> and <QoS Reserved> MUST be
supported by all QOSM implementations, as defined in [RFC5975].
<QoS Available> is required for receiver-initiated reservations with
object combination 1 and 2, and object combination 1 and 2 in sender-
initiated reservations. It is used for gathering available bandwidth
information along the path. This information can be used by the QNI
(or QNR, for receiver-initiated reservations) to make an appropriate
reservation thereafter, particularly to re-issue a failed
reservation. Since only bandwidth is needed, set the <TMOD1>
parameters r = peak rate = p, b = large, m = large and for TCP
traffic, r = average rate, b = large, p = large.
<Minimum QoS> MAY be supported by QNEs and is optional to implement
and to use. If supported 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 <Minimum QoS> is included, a
downgrade of all TMOD1 parameters is possible.
Furthermore, the Excess Treatment parameter MAY be included as
parameter. Currently supported values are "drop", "shape" or "re-
mark". The default value for the Controlled Load QOSM if not
included is "shape". 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 TMOD1
specification reserved. Traffic is considered "non-conformant" when:
Kappler, et al. Expires March 7, 2012 [Page 10]
Internet-Draft Controlled-Load QOSM September 2011
o over time period T, the amount of data received exceeds rT+b; or
o data rate of the traffic exceeds the peak rate p; or
o data packet size is larger than M or the QNE's outgoing link MTU
In all QSPEC objects additional parameters MAY be included, as
described in [RFC5975].
5.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 an INFO_SPEC
object indicating this failure towards the QNI.
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 TMOD1, 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 end-to-end information on e.g. bandwidth can be collected
and delivered to the QNI.
o In an "RSVP-style" receiver-initiated reservation, the sender
(QNR) issues a QUERY with <QoS Desired> specifying the desired
resources and <QoS Available> collecting information on available
TMOD1 parameters. The receiver (QNI) reacts with a RESERVE
message containing <QoS Desired> with a TMOD1. <QoS Available> is
copied from the QUERY message. The signaling exchange is
concluded with a RESPONSE by the QNR including a <QoS Reserved>
echoing the TMOD1 that was reserved.
Note that the initial message triggering the signaling exchange fully
determines the sequencing of subsequent messages, and also determines
Kappler, et al. Expires March 7, 2012 [Page 11]
Internet-Draft Controlled-Load QOSM September 2011
what QSPEC objects will be carried in them. That is, only the QNI
for sender initiated reservation and the QNR for receiver initiated
reservation have 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.
6. Processing Rules in QNEs
6.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 TMOD1
parameters MUST be met according to the following rule: a TMOD1 A
from the available resources for a flow MUST be "as good or better
than" or "greater than or equal to" TMOD1 B (which is carried in the
received QoS Description, e.g., <QoS Desired>, or <Minimum QoS> if
available), i.e.,:
o the TMOD1 rate r for TMOD1 A is greater than or equal to that of
TMOD1 B, and
o the TMOD1 depth b for TMOD1 A is greater than or equal to that of
TMOD1 B, and
o the peak rate p for TMOD1 A is greater than or equal to that of
TMOD1 B, and
o the minimum policed unit m for TMOD1 A is less than or equal to
that of TMOD1 B, and
o the maximum packet size MPS of TMOD1 A is greater than or equal to
that of TMOD1 B.
Remark: these rules come originally from rules for ordering TMOD1s in
[RFC2211].
There are no target values for other parameters, e.g. delay or loss,
Kappler, et al. Expires March 7, 2012 [Page 12]
Internet-Draft Controlled-Load QOSM September 2011
other than providing a service closely equivalent to that provided to
best-effort traffic under lightly loaded conditions.
Resource requests for new flows are accepted if capacity is
available. Reservation modifications are accepted if the new <TMOD1>
is strictly smaller than the old one. Otherwise they are treated
like new reservations from an admission control perspective.
6.2. Packet Scheduling and Excess Treatment
A QNE MUST ensure the TMOD1 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:
o the QNE MUST continue to provide the contracted QoS for traffic
belonging to flows which are all conformant.
o the QNE SHOULD prevent excess control load traffic from unfairly
impacting the handling of arriving best-effort traffic.
o 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
[RFC2211] 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.
Kappler, et al. Expires March 7, 2012 [Page 13]
Internet-Draft Controlled-Load QOSM September 2011
7. Preemption
The controlled-load service QOSM makes use of the <Preemption
Priority> and <Defending Priority> parameter to preempt flows. A new
flow with higher <Preemption Priority> can preempt an already
admitted flow with lower <Defending Priority>. One single higher
priority flow can replace more than one lower priority flow until the
requested amount of <TMOD1> is met. Once the flow is admitted
<Preemption Priority> becomes irrelevant. More details about
Preemption and Defending Priority are provided in [RFC3181].
8. 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 [RFC2211], 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 that 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.3.
| Message | Object(s) | Parameter(s)
--------------------------------------------------------------------
RSVP | Path | Sender TSpec | token bucket
| | ADSpec | avail. bw and MTU
QoS NSLP | QUERY | <QoS Desired> | <TMOD1>
| | <QoS Available> | <TMOD1>
| | |
RSVP | Resv | FlowSpec | token bucket
QoS NSLP | RESERVE | <QoS Desired> | <TMOD1>
| | <QoS Available> | <TMOD1>
| | |
RSVP | ResvConfirm | |
QoS NSLP | RESPONSE | <QoS Reserved> | <TMOD1>
Please note that TMOD1 in <QoS Available> specifies bandwidth only.
See Section Section 5.2.2 how to set bandwidth in TMOD.
A RSVP Path Message includes a SenderTSPEC specifying the traffic an
application is going to send. The RSVP AdSpec is optionally
Kappler, et al. Expires March 7, 2012 [Page 14]
Internet-Draft Controlled-Load QOSM September 2011
included. It probes for the available bandwidth on the data path.
This reservation model is referred to as One Pass with Advertising
(OPWA). When the AdSpec is omitted, the Receiver cannot determine
the available resources for the resulting end-to-end QoS. This
reservation model is referred to as One Pass. On arrival at the
Receiver the FlowSpec, consisting of the TSpec, is created. The
TSpec is usually derived from the SenderTSpec and if available from
the AdSpec. It contains the desired QoS. The Resv message is sent
upstream to the Sender. At each hop the desired resource reservation
is reserved. The last node sends a ResvConf back to the Receiver to
indicate that end-to-end reservation has been installed.
In QoS NSLP, the sender populates the QoS which it desires by
including a <QoS Desired> and optionally queries the network for the
QoS that is available. In this case it carries the <QoS Available>
parameter which is updated by all QNEs to reflect the QoS that is
actually available. With the <QoS Desired> object, the Receiver
(QNI) is informed about the requested resources. See Section 5.3 for
a detailed description of QSPEC procedures for controlled-load
service.
9. Security Considerations
This document does not raise additional security issues beyond those
described in [RFC5974] and [RFC5975].
10. IANA Considerations
A new QOSM ID ("Controlled-Load Service QOSM") needs to be assigned
by IANA.
11. 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 determine
what features are specific to IntServ controlled load, and which
features are specific to RSVP.
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, et al. Expires March 7, 2012 [Page 15]
Internet-Draft Controlled-Load QOSM September 2011
receiver-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.
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.
In this draft, the feedback problem is solved by including a <Minimum
QoS> QSPEC object in sender-initiated reservations. This gives some
flexibility as it implicitly says the QNI would also accept a
downgraded reservation, up to the value specified.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
Kappler, et al. Expires March 7, 2012 [Page 16]
Internet-Draft Controlled-Load QOSM September 2011
[RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC
Template for the Quality-of-Service NSIS Signaling Layer
Protocol (NSLP)", RFC 5975, October 2010.
12.2. Informative References
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements",
RFC 2215, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC2998] 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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, October 2010.
[RFC5976] Ash, G., Morton, A., Dolly, M., Tarapore, P., Dvorak, C.,
and Y. El Mghazli, "Y.1541-QOSM: Model for Networks Using
Y.1541 Quality-of-Service Classes", RFC 5976,
Kappler, et al. Expires March 7, 2012 [Page 17]
Internet-Draft Controlled-Load QOSM September 2011
October 2010.
[RFC5977] Bader, A., Westberg, L., Karagiannis, G., Kappler, C., and
T. Phelan, "RMD-QOSM: The NSIS Quality-of-Service Model
for Resource Management in Diffserv", RFC 5977,
October 2010.
Appendix A. Bit level Examples of QSPEC objects for Controlled Load
QOSM
A.1. Minimal QSPEC objects for Sender-Initiated Reservation
The first example shows a "minimal" QSPEC for Controlled Load
containing the least number of objects and parameters. It signals
for sender initiated reservations, containing the TMOD1 for <QoS
Desired> and for <QoS Reserved>. The difference between the QSPEC in
the RESERVE and the RESPONSE message is only slight.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=0/0| Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 An Example QSPEC for Sender-Initiated Reservation(RESERVE)
Kappler, et al. Expires March 7, 2012 [Page 18]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=0/0| Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.2 An Example QSPEC for Sender-Initiated Reservation(RESPONSE)
A.2. Extended QSPEC objects for Sender-Initiated Reservation
The following QSPEC offers a range of acceptable bandwidth in case
the request of <QoS Desired> cannot be fulfilled. When <QoS
Available> becomes lower than <Minimum QoS> the reservation fails.
The requesting node gets informed by <QoS Available> about the
remaining resources. See [RFC5975] for details. The optional
<Excess Treatment> parameter defines the behavior of the traffic
conditioner how to handle out of profile traffic.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=0/2| Length = 23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kappler, et al. Expires March 7, 2012 [Page 19]
Internet-Draft Controlled-Load QOSM September 2011
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|r| ID = 11 <Excess Tr.> |r|r|r|r| Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Re-mark Val| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 3 (Min. QoS) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.3 Example QSPEC for Sender-Initiated Reservation(RESERVE)
Kappler, et al. Expires March 7, 2012 [Page 20]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=0/2| Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.4 Example QSPEC for Sender-Initiated Reservation(RESPONSE)
A.3. Receiver Initiated Reservation (RSVP Style)
This is an example for an 'RSVP-style' reservation using a 3-way
handshake. The QNR as the sender issues a QUERY and informs the QNI
at the receiver about the desired bandwidth. The requested resources
are contained in <QoS Desired>. Resource information about the path
is collected in <QoS Available>. The receiver copies the content of
<QoS Available> into <QoS Desired>. The QNI is updated about
available resources before sending the RESERVE. A RESPONSE is sent
back to confirm the reservation.
Kappler, et al. Expires March 7, 2012 [Page 21]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.5 Example QSPEC for Receiver-Initiated Reservation(QUERY)
Kappler, et al. Expires March 7, 2012 [Page 22]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.6 Example QSPEC for Receiver-Initiated Reservation(RESERVE)
Kappler, et al. Expires March 7, 2012 [Page 23]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=1/2| Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.7 Example QSPEC for Receiver-Initiated Reservation(RESPONSE)
A.4. Resource Queries
The QUERY message is used to collect information about available
bandwidth along the path. It does not manipulate any state. In
response to the <QoS Desired> a <QoS Available> object describing the
resources is returned.
Kappler, et al. Expires March 7, 2012 [Page 24]
Internet-Draft Controlled-Load QOSM September 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|I|QSPECType|r|r|QSPEC Proc.=2/0| Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 (m) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size-1 (MPS) (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.8 Example QSPEC for Resource Queries (QUERY and 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. Changes since -13
1. Editorial changes made
B.2. Changes since -12
1. References updated
B.3. Changes since -11
1. Editorial changes made
B.4. Changes since -10
1. Updated Bit level Examples of QSPEC object to current Object
format
2. Removed discussion about collecting path MTU
Kappler, et al. Expires March 7, 2012 [Page 25]
Internet-Draft Controlled-Load QOSM September 2011
B.5. Changes since -09
1. Updated Bit level Examples of QSPEC object to current Object
format
2. Editorial changes made
B.6. Changes since -08
1. Removed discussion about number of hops not implementing the CLS
QoSM in section Conclusions
B.7. Changes since -07
1. Editorial changes made
B.8. Changes since -06
1. Updated requirements for QOSM specification
2. Clarified the use of <Minimum QoS>
3. Added section about preemption
B.9. Changes since -05
1. Included additional bit-level examples.
2. Updated section about interoperation with RSVP-CLS.
B.10. Changes since -04
1. Adapted terminology and content to latest version of QSPEC (v17).
E.g. removed QOSM ID, removed MTU,...
B.11. Changes since -03
1. Adapted terminology and updated references.
B.12. Changes since -02
1. Added "RSVP-style reservation" as running example
2. Updated interoperability section
3. Aligned QSPEC example in Appendix A with update of QSPEC draft
and added more details
Kappler, et al. Expires March 7, 2012 [Page 26]
Internet-Draft Controlled-Load QOSM September 2011
B.13. 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, Bob Braden and Hannes Tschofenig
provided helpful comments.
Authors' Addresses
Cornelia Kappler
ck technology concepts
Berlin
Germany
Email: cornelia.kappler@cktecc.de
Xiaoming Fu
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen 37077
Germany
Email: fu@cs.uni-goettingen.de
Bernd Schloer
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen 37077
Germany
Email: bernd.schloer@yahoo.com
Kappler, et al. Expires March 7, 2012 [Page 27]
