One document matched: draft-kappler-nsis-qosmodel-controlledload-10.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ietf-nsis-qos-nslp SYSTEM "reference.I-D.ietf-nsis-qos-nslp.xml">
<!ENTITY rfc2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY ietf-nsis-qspec SYSTEM "reference.I-D.ietf-nsis-qspec.xml">
<!ENTITY rfc2211 SYSTEM "reference.RFC.2211.xml">
<!ENTITY ietf-nsis-rmd SYSTEM "reference.I-D.ietf-nsis-rmd.xml">
<!ENTITY ietf-nsis-y1541-qosm SYSTEM "reference.I-D.ietf-nsis-y1541-qosm.xml">
<!ENTITY rfc1633 SYSTEM "reference.RFC.1633.xml">
<!ENTITY rfc2205 SYSTEM "reference.RFC.2205.xml">
<!ENTITY rfc2210 SYSTEM "reference.RFC.2210.xml">
<!ENTITY rfc2215 SYSTEM "reference.RFC.2215.xml">
<!ENTITY rfc2475 SYSTEM "reference.RFC.2475.xml">
<!ENTITY rfc2746 SYSTEM "reference.RFC.2746.xml">
<!ENTITY rfc2996 SYSTEM "reference.RFC.2996.xml">
<!ENTITY rfc2998 SYSTEM "reference.RFC.2998.xml">
<!ENTITY rfc3031 SYSTEM "reference.RFC.3031.xml">
<!ENTITY rfc3181 SYSTEM "reference.RFC.3181.xml">
<!ENTITY ietf-nsis-ntlp SYSTEM "reference.I-D.ietf-nsis-ntlp.xml">
]>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<rfc docName="draft-kappler-nsis-qosmodel-controlledload-10" ipr="pre5378Trust200902" category="info">
<front>
<title abbrev="Controlled-Load QOSM">A QoS Model for Signaling IntServ
Controlled-Load Service with NSIS</title>
<author fullname="Cornelia Kappler" initials="C." surname="Kappler">
<organization abbrev="deZem GmbH">deZem GmbH</organization>
<address>
<postal>
<street>Knesebeckstr. 86/87</street>
<city>Berlin</city>
<code>10623</code>
<country>Germany</country>
</postal>
<email>cornelia.kappler@googlemail.com</email>
</address>
</author>
<author fullname="Xiaoming Fu" initials="X." surname="Fu">
<organization abbrev="Univ. Goettingen">University of
Goettingen</organization>
<address>
<postal>
<street>Institute of Computer Science</street>
<street>Goldschmidtstr. 7</street>
<city>Goettingen</city>
<code>37077</code>
<country>Germany</country>
</postal>
<email>fu@cs.uni-goettingen.de</email>
</address>
</author>
<author fullname="Bernd Schloer" initials="B." surname="Schloer">
<organization abbrev="Univ. Goettingen">University of
Goettingen</organization>
<address>
<postal>
<street>Institute of Computer Science</street>
<street>Goldschmidtstr. 7</street>
<city>Goettingen</city>
<code>37077</code>
<country>Germany</country>
</postal>
<email>bschloer@cs.uni-goettingen.de</email>
</address>
</author>
<date year="2009" />
<area>Transport</area>
<workgroup>Next Steps in Signaling</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>NSIS-QOSM</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The QoS NSIS Signaling Layer Protocol, QoS NSLP <xref
target="I-D.ietf-nsis-qos-nslp"></xref> 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 <xref target="I-D.ietf-nsis-qos-nslp"></xref>. 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 <xref target="I-D.ietf-nsis-rmd"></xref> and <xref
target="I-D.ietf-nsis-y1541-qosm"></xref> and this draft.</t>
<t>The purpose of this document is to describe a QoS model for
controlled-load service of IntServ <xref target="RFC2211"></xref>. In
<xref target="RFC2210"></xref> 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.</t>
<t>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 <xref
target="RFC1633"></xref>, achieving QoS in appropriately engineered
DiffServ networks with admission control <xref target="RFC2998"></xref>,
or across IP tunnels or MPLS Label Switched Paths (LSPs) with reserved
bandwidths and admission control <xref target="RFC2746"></xref> <xref
target="RFC3031"></xref>.</t>
<t>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 <xref target="I-D.ietf-nsis-qos-nslp"></xref> and <xref
target="I-D.ietf-nsis-qspec"></xref>. 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.</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>The terminology defined in <xref
target="I-D.ietf-nsis-qos-nslp"></xref> and <xref
target="I-D.ietf-nsis-qspec"></xref> applies to this document.</t>
</section>
<section anchor="sec2" title="Signaling with QoS NSLP">
<section anchor="sec2.1" title="QoS NSLP ">
<t>QoS NSLP <xref target="I-D.ietf-nsis-qos-nslp"></xref> is an NSIS
signaling layer protocol for signaling QoS reservations in the
Internet. Together with GIST <xref
target="I-D.ietf-nsis-ntlp"></xref>, 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.</t>
<!--The text below used to just say NOTIFY is not important for us. But I am not so sure. We may have to define CLS-specific errors. Therefore I updated this sentence to just say what NOTIFY does. We still need to check whether we need extra error codes
-->
<t>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.</t>
</section>
<section title="QSPEC">
<t>QoS NSLP carries QoS Model specific information encapsulated in an
opaque object, the QSPEC <xref target="I-D.ietf-nsis-qspec"></xref>.
The QSPEC thus fulfills a similar purpose as TSpec, RSpec and AdSpec
in RSVP <xref target="RFC2205"></xref>. 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.</t>
<t>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.
<list style="symbols">
<t><QoS Desired> contains parameters describing the QoS
desired by a QNI.</t>
<t><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.</t>
<t><QoS Reserved> describes the actual QoS reserved.</t>
<t><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.</t>
</list></t>
<!--TMOD parameter MUST be interpreted. But QSPEC does not mandate the parameter be included in all QSPECs!!! (corrected); Max Packet size (MTU) is no longer part of TMOD. Accordingly I moved around some of the text in this section.
-->
<t>The QSPEC template <xref target="I-D.ietf-nsis-qspec"></xref>
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.</t>
</section>
<section anchor="QoSModel" title="QoS Model">
<t>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 <xref target="RFC2475"></xref>. QoS NSLP
is independent of the QOSM, just as RSVP <xref
target="RFC2205"></xref> 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.</t>
</section>
</section>
<section anchor="controlledLoad" title="IntServ Controlled Load Service">
<t>As specified in <xref target="RFC2211"></xref>, 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".</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="RFC2998"></xref>. 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 <xref target="RFC2996"></xref> 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 <xref target="RFC2746"></xref> or MPLS LSPs <xref
target="RFC3031"></xref>. The per-flow traffic descriptor is in this
case used for admission control into the tunnel/LSP.</t>
</section>
<section anchor="clqosm"
title="NSIS QoS Model for IntServ Controlled Load Service ">
<t>According to <xref target="I-D.ietf-nsis-qspec"></xref>, a QOSM
MUST include the following information: <list style="symbols">
<t>role of QNEs, e.g., location, frequency, statefulness, etc.</t>
<t>QSPEC definition including QSPEC parameters</t>
<t>QSPEC procedures applicable to this QOSM</t>
<t>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).</t>
<t>at least one bit-level QSPEC example</t>
<t>QSPEC parameter behavior for new QSPEC parameters the QOSM
specification defines</t>
</list></t>
<t>A QOSM specification MAY include the following information: <list style="symbols">
<t>define additional QOSM-specific error codes</t>
<t>can state which 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).</t>
</list></t>
<t>Subsequent sections treat these points one-by-one. An example
bit-level QSPEC format is given in Appendix A.</t>
<section anchor="QNEs" title="Role of QNEs">
<t>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.</t>
</section>
<section title="QSPEC Definition">
<section title="Controlled Load Service Requirements">
<t>The controlled-load service QOSM uses TMOD1 parameters<xref
target="I-D.ietf-nsis-qspec"></xref>, which consist of a token
bucket specification (i.e. bucket rate r and a bucket depth b) plus
a peak rate (p) and a minimum policed unit (m). 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 <xref
target="RFC2210"></xref>.</t>
<t>Note the TMOD1 parameter does not contain a maximum transmission
unit (MTU), as the original token bucket does. 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
<xref target="RFC2210"></xref><xref target="RFC2215"></xref>. 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 <xref target="I-D.ietf-nsis-qspec"></xref>
in NSIS; rather, an independent path MTU discovery mechanism (e.g.,
<xref target="pmtud-charter"></xref>) during the flow setup phase
is assumed to provide means to learn about the path MTU.</t>
<!--removed section on QOSM ID because this parameter was discarded in the QSPEC-->
<t>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.</t>
<t></t>
</section>
<section anchor="QSPEC Objects" title="QSPEC Objects">
<t>The QSPEC can contain some or all of the following objects:</t>
<t><QoS Desired> = <TMOD1></t>
<t><QoS Available> = <TMOD1></t>
<t><Minimum QoS> = <TMOD1></t>
<t><QoS Reserved> = <TMOD1></t>
<t>Among them, <QoS Desired>, <QoS Available> and <QoS Reserved> MUST be
supported by all QOSM implementations, as defined in <xref
target="I-D.ietf-nsis-qspec"></xref>.</t>
<t><QoS Available> is required for receiver-initiated
reservations case 2 and 3, and case 2 and 3 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.<!-- Note <path latency> is an optional parameter, i.e. some QNEs may not understand it.
However, such QNEs are required to raise a corresponding flag. In this case the value
collected in <path latency> is a lower bound to the actual value.!--></t>
<t><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.</t>
<t>Furthermore, the Excess Treatment parameter MAY be included as
parameter. Currently supported values are "reshape" or "drop". The
default value for the Controlled Load QOSM if not included 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 TMOD1
specification reserved. Traffic is considered "non-conformant" when:
<list style="symbols">
<t>over time period T, the amount of data received exceeds rT+b;
or</t>
<t>data rate of the traffic exceeds the peak rate p; or</t>
<t>data packet size is larger than M or the QNE's outgoing link
MTU</t>
</list></t>
<t>In all QSPEC objects additional parameters MAY be included, as
described in <xref target="I-D.ietf-nsis-qspec"></xref>.</t>
</section>
</section>
<section anchor="QSPECProcedures"
title="Usage of QoS NSLP Messages -- QSPEC Procedures">
<t>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.</t>
<t>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. <list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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<!--The bandwidth parameter was abolished. We must replace it with a TMOD-->.
<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.</t>
</list></t>
<t>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 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.</t>
<t>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.</t>
</section>
</section>
<section title="Processing Rules in QNEs ">
<section title="Admission Control">
<t>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.</t>
<t>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.,: <list style="symbols">
<t>the TMOD1 rate r for TMOD1 A is greater than or equal to that of
TMOD1 B, and</t>
<t>the TMOD1 depth b for TMOD1 A is greater than or equal to that of
TMOD1 B, and</t>
<t>the peak rate p for TMOD1 A is greater than or equal to that of
TMOD1 B, and</t>
<t>the minimum policed unit m for TMOD1 A is less than or equal to
that of TMOD1 B, and</t>
</list></t>
<t>Remark: these rules come originally from rules for ordering TMOD1s
in <xref target="RFC2211"></xref>.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Packet Scheduling and Excess Treatment">
<t>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.</t>
<t>In presence of arriving non-conformant traffic, the QNE MUST behave
as follows: <list style="symbols">
<t>the QNE MUST continue to provide the contracted QoS for traffic
belonging to flows which are all conformant.</t>
<t>the QNE SHOULD prevent excess control load traffic from
unfairly impacting the handling of arriving best-effort
traffic.</t>
<t>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>.</t>
</list></t>
<t>Several basic approaches for excess treatment are suggested in
<xref target="RFC2211"></xref> 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.</t>
<t>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.</t>
<t>Finally, Random Early Detection (RED) queueing mechanism may be
used.</t>
</section>
</section>
<section title="Preemption">
<t>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 <xref target="RFC3181"></xref>.</t>
</section>
<section title="Interoperation with Controlled Load Service Specified in RFC2211">
<t>The controlled-load service QOSM is intended to be consistent with
the RSVP/Controlled Load Service specified in <xref
target="RFC2211"></xref>, 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.</t>
<t>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 <xref target="Appendix"></xref>.</t>
<t><figure>
<artwork>
| 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>
</artwork>
</figure></t>
<t>Please note that TMOD1 in <QoS Available> specifies bandwidth only.
See Section <xref target="QSPEC Objects"></xref> how to set bandwidth in TMOD.</t>
<t>A RSVP Path Message includes a SenderTSPEC specifying the traffic an
application is going to send. The RSVP AdSpec is optionally 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.</t>
<t>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 <xref
target="QSPECProcedures"></xref> for a detailed description of QSPEC
procedure for controlled-load service.</t>
<t>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.</t>
</section>
<section title="Security Considerations">
<t>This document does not raise additional security issues beyond those described in
<xref target="I-D.ietf-nsis-qos-nslp"></xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>A new QOSM ID ("Controlled-Load Service QOSM") needs to be assigned
by IANA.</t>
</section>
<section anchor="conclusions" title="Conclusions">
<t>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.</t>
<t>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
receiver-initiated reservations.</t>
<t>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.</t>
<t>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)</t>
<t>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.</t>
<t>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. Note however as
currently specified in <xref target="I-D.ietf-nsis-qspec"></xref>,
the <Minimum QoS> QSPEC object is not necessarily supported by all
QNEs.</t>
</section>
</middle>
<back>
<references title="Normative References">
&ietf-nsis-qos-nslp;
&rfc2119;
&ietf-nsis-qspec;
&rfc2211;
</references>
<references title="Informative References">
&ietf-nsis-rmd;
&ietf-nsis-y1541-qosm;
&rfc1633;
&rfc2205;
&rfc2210;
&rfc2215;
&rfc2475;
&rfc2746;
&rfc2996;
&rfc2998;
&rfc3031;
&rfc3181;
&ietf-nsis-ntlp;
<reference anchor="pmtud-charter">
<front>
<title>Path MTU Discovery (pmtud) Charter,
http://www.ietf.org/html.charters/pmtud-charter.html</title>
<author>
<organization></organization>
</author>
<date year="2005" />
</front>
</reference>
</references>
<section title="Bit level Examples of QSPEC objects for Controlled Load QOSM">
<section title="Minimal QSPEC objects for Sender-Initiated Reservation">
<t>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.</t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=0/1| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 An Example QSPEC for Sender-Initiated Reservation(RESERVE)
</artwork>
</figure></t>
<t></t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=0/1| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.2 An Example QSPEC for Sender-Initiated Reservation(RESPONSE)
</artwork>
</figure></t>
</section>
<section title="Extended QSPEC objects for Sender-Initiated Reservation">
<t>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 <xref
target="I-D.ietf-nsis-qspec"></xref> for details. The optional
<Excess Treatment> parameter defines the behavior of the traffic
conditioner how to handle out of profile traffic.</t>
<t><!--The Excess Treatment parameter seemed to belong to "QoS Desired" rather than "Minumum QoS" --><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=0/3| Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|0|r| ID = 11 <Excess Tr.> |r|r|r|r| Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt |Remark Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 3 (Min. QoS) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.3 Example QSPEC for Sender-Initiated Reservation(RESERVE)
</artwork>
</figure></t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=0/3| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 2 (QoS Res.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.4 Example QSPEC for Sender-Initiated Reservation(RESPONSE)
</artwork>
</figure></t>
<t></t>
</section>
<section anchor="Appendix"
title="Receiver Initiated Reservation (RSVP Style)">
<t>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.</t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=1/3| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.5 Example QSPEC for Receiver-Initiated Reservation(QUERY)
</artwork>
</figure></t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=1/3| Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.6 Example QSPEC for Receiver-Initiated Reservation(RESERVE)
</artwork>
</figure></t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers.|0|QSPECType|r|r|QSPEC Proc.=1/3| Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.7 Example QSPEC for Receiver-Initiated Reservation(RESPONSE)
</artwork>
</figure></t>
</section>
<section title="Resource Queries">
<t>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.</t>
<t><figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | QSPEC Type | 2 | 1 |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|r|r|r| Type = 1 (QoS Avail.) |r|r|r|r| Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|r| ID = 1 <TMOD-1> |r|r|r|r| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.8 Example QSPEC for Resource Queries (QUERY and RESPONSE)
</artwork>
</figure></t>
<t>Other scenarios can be easily derived by adapting to the QoS NSLP
signaling procedure and used QoS specifications.</t>
</section>
</section>
<section title="Change Tracker">
<!--Removed open issues on QSPEC-1 parameters as these dont exist anymore. Removed one of the alternatives in issue 2 since we no longer have the bandwidth parameter. Also removed the 2nd open issue since with the removal of the bandwidth parameter in the QSPEC all options seemed to collapse into one!?!?-->
<section title="Changes in -09">
<t>1. Updated Bit level Examples of QSPEC object to current Object format</t>
<t>2. Editorial changes made</t>
</section>
<section title="Changes in -08">
<t>1. Removed discussion about number of hops not implementing the CLS
QoSM in section Conclusions</t>
</section>
<section title="Changes in -07">
<t>1. Editorial changes made</t>
</section>
<section title="Changes in -06">
<t>1. Updated requirements for QOSM specification</t>
<t>2. Clarified the use of <Minimum QoS></t>
<t>3. Added section about preemption</t>
</section>
<section title="Changes in -05">
<t>1. Included additional bit-level examples.</t>
<t>2. Updated section about interoperation with RSVP-CLS.</t>
</section>
<section title="Changes in -04">
<t>1. Adapted terminology and content to latest version of QSPEC (v17).
E.g. removed QOSM ID, removed MTU,...</t>
</section>
<section title="Changes in -03">
<t>1. Adapted terminology and updated references.</t>
</section>
<section title="Changes in -02">
<t>1. Added "RSVP-style reservation" as running example</t>
<t>2. Updated interoperability section</t>
<t>3. Aligned QSPEC example in Appendix A with update of QSPEC draft
and added more details</t>
</section>
<section title="Changes in -01">
<t>1. Clarifications about path MTU, scheduling/excess treatment and
QOSM Hops.</t>
<t>2. Added a section "Interoperation with RFC2211" and QSPEC format
as Appendix.</t>
</section>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Andrew McDonald for fruitful
discussions. John Loughney, Bob Braden and Hannes Tschofenig provided helpful comments.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:52:24 |