One document matched: draft-ietf-nsis-qspec-05.txt
Differences from draft-ietf-nsis-qspec-04.txt
IETF Internet Draft NSIS Working Group Jerry Ash
Internet Draft AT&T
<draft-ietf-nsis-qspec-05.txt> Attila Bader
Expiration Date: January 2006 Ericsson
Cornelia Kappler
Siemens AG
July 2005
QoS-NSLP QSPEC Template
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 1]
Internet Draft QoS-NSLP QSPEC Template July 2005
Abstract
The QoS NSLP protocol is used to signal QoS reservations and is
independent of a specific QoS model (QOSM) such as IntServ or
DiffServ. Rather, all information specific to a QOSM is encapsulated
in a separate object, the QSPEC. This draft defines a template for
the QSPEC, which contains both the QoS description and QSPEC control
information. The QSPEC format is defined, as are a number of QSPEC
parameters. The QSPEC parameters provide a common language to be
re-used in several QOSMs. To a certain extent QSPEC parameters
ensure interoperability of QOSMs. Optional QSPEC parameters aim to
ensure the extensibility of QoS NSLP to other QOSMs in the future.
The node initiating the NSIS signaling adds an Initiator QSPEC that
must not be removed, thereby ensuring the intention of the NSIS
initiator is preserved along the signaling path.
Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 6
4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 6
4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 6
4.3 Example of NSLP QSPEC Operation . . . . . . . . . . . . . . 8
4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . . 12
4.4.1 Mandatory and Optional QSPEC Parameters . . . . . . . 12
4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 12
4.5 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 12
5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 13
5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 13
5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 QoS Desired . . . . . . . . . . . . . . . . . . . . . 14
5.2.2 QoS Available . . . . . . . . . . . . . . . . . . . . 15
5.2.3 QoS Reserved . . . . . . . . . . . . . . . . . . . . 18
5.2.4 Minimum QoS . . . . . . . . . . . . . . . . . . . . . 18
6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 18
6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 19
6.2 <QSPEC Procedure Identifier> Parameter . . . . . . . . . . 20
6.3 <NON QOSM Hop> Parameter . . . . . . . . . . . . . . . . . 20
6.4 <Excess Treatment> Parameter . . . . . . . . . . . . . . . 21
6.5 <Bandwidth> & <S> Parameters . . . . . . . . . . . . . . . 21
6.6 <Token Bucket> Parameters . . . . . . . . . . . . . . . . . 22
6.7 <QoS Class> Parameters . . . . . . . . . . . . . . . . . . 23
6.7.1 <PHB Class> Parameter . . . . . . . . . . . . . . . . 23
6.7.2 <Y.1541 QoS Class> Parameter . . . . . . . . . . . . 23
6.7.3 <DSTE Class Type> Parameter . . . . . . . . . . . . . 24
6.8 <Priority> Parameters . . . . . . . . . . . . . . . . . . . 24
6.8.1 <Preemption Priority> & <Defending Priority>
Parameters . . . . . . . . . . . . . . . . . . . . . 24
6.8.2 <Reservation Priority> Parameters . . . . . . . . . . 25
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 2]
Internet Draft QoS-NSLP QSPEC Template July 2005
6.9 <Path Latency> Parameter . . . . . . . . . . . . . . . . . 27
6.10 <Path Jitter> Parameter . . . . . . . . . . . . . . . . . 27
6.11 <Path BER> Parameter . . . . . . . . . . . . . . . . . . . 28
6.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters . . . . . . . . . . 29
6.13 Non-Support Flags . . . . . . .. . . . . . . . . . . . . . 29
6.14 Tunneled-Parameter Flags . . . . . .. . . . . . . . . . . 30
7. QSPEC Procedures & Examples . . . . . . . . . . . . . . . . . . 31
7.1 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 31
7.1.1 Sender-Initiated Reservations . . . . . . . . . . . . 31
7.1.2 Receiver-Initiated Reservations . . . . . . . . . . . 32
7.1.3 Resource Queries . . . . . . . . . . . . . . . . . . 33
7.1.4 Bidirectional Reservations . . . . . . . . . . . . . 33
7.1.5 Setting Optional Parameter Flags . . . . . . . . . . 33
7.2 QSPEC Examples . . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
11. Normative References . . . . . . . . . . . . . . . . . . . . 36
12. Informative References . . . . . . . . . . . . . . . . . . . 36
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
Appendix A QoS Models and QSPECs . . . . . . . . . . . . . . . . . 39
Appendix B Mapping of QoS Desired, QoS Available, and QoS
Reserved of NSIS onto AdSpec, TSpec, and RSpec of RSVP IntServ . . 39
Appendix C: Main Changes Since Last Version & Open Issues . . . . 40
C.1 Main Changes Since Version -04 . . . . . . . . . . 40
C.2 Open Issues . . . . . . . . . . . . . . . . . . . 40
Intellectual Property Statement . . . . . . . . . . . . . . . . . 40
Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 41
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . 41
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 3]
Internet Draft QoS-NSLP QSPEC Template July 2005
1. Conventions Used in This Document
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 RFC 2119 [RFC2119].
2. Introduction
The QoS NSLP establishes and maintains state at nodes along the path
of a data flow for the purpose of providing forwarding resources
(QoS) for that flow [QoS-SIG]. The design of QoS NSLP is conceptually
similar to RSVP [RFC2205], and meets the requirements of [RFC3726].
A QoS-enabled domain supports a particular QoS model (QOSM), which is
a method to achieve QoS for a traffic flow. A QOSM incorporates QoS
provisioning methods and a QoS architecture. It defines the behavior
of the resource management function (RMF), including inputs and
outputs, and how QSPEC information is interpreted on traffic
description, resources required, resources available, and control
information required by the RMF. A QOSM also specifies a set of
mandatory and optional QSPEC parameters that describe the QoS and how
resources will be managed by the RMF. QoS NSLP can support signaling
for different QOSMs, such as for IntServ, DiffServ admission control,
and those specified in [Y.1541-QOSM, INTSERV-QOSM, RMD-QOSM]. For
more information on QOSMs see Section 7.2 and Appendix A.
One of the major differences between RSVP and QoS-NSLP is that
QoS-NSLP supports signaling for different QOSMs along the data path,
all with one signaling message. For example, the data path may start
in a domain supporting DiffServ and end in a domain supporting
Y.1541. However, because some typical QoS parameters are
standardized and can be reused in different QOSMs, some degree of
interoperability between QOSMs exists.
The QSPEC travels in QoS-NSLP messages and is opaque to the
QoS NSLP. The content of the QSPEC is QOSM specific. Since
QoS-NSLP signaling operation can be different for different QOSMs,
the QSPEC contains two kinds of information, QSPEC control
information and QoS description.
QSPEC control information contains parameters that governs the RMF.
An example of QSPEC control information is how the excess traffic is
treated in the RMF queuing functions.
The QoS description is composed of QSPEC objects loosely
corresponding to the TSpec, RSpec and AdSpec objects specified in
RSVP. This is, the QSPEC may contain a description of QoS desired
and QoS reserved. It can also collect information about available
resources. Going beyond RSVP functionality, the QoS description
also allows indicating a range of acceptable QoS by defining a QSPEC
object denoting minimum QoS. Usage of these QSPEC objects is not
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 4]
Internet Draft QoS-NSLP QSPEC Template July 2005
bound to particular message types thus allowing for flexibility. A
QSPEC object collecting information about available resources MAY
travel in any QoS-NSLP message, for example a QUERY message or a
RESERVE message.
3. Terminology
Mandatory QSPEC parameter: QSPEC parameter that a QNI SHOULD populate
if applicable to the underlying QOSM and a QNE MUST interpret, if
populated.
Minimum QoS: Minimum QoS is a QSPEC object that MAY be supported by
any QNE. Together with a description of QoS Desired or QoS
Available, it allows the QNI to specify a QoS range, i.e. an upper
and lower bound. If the QoS Desired cannot be reserved, QNEs are
going to decrease the reservation until the minimum QoS is hit.
Optional QSPEC parameter: QSPEC parameter that a QNI SHOULD populate
if applicable to the underlying QOSM, and a QNE SHOULD interpret if
populated and applicable to the QOSM(s) supported by the QNE. (A QNE
MAY ignore if it does not support a QOSM needing the optional QSPEC
parameter).
QNE: QoS NSIS Entity, a node supporting QoS NSLP.
QNI: QoS NSIS Initiator, a node initiating QoS-NSLP signaling.
QNR: QoS NSIS Receiver, a node terminating QoS-NSLP signaling.
QoS Description: Describes the actual QoS in QSPEC objects QoS
Desired, QoS Available, QoS Reserved, and Minimum QoS. These QSPEC
objects are input or output parameters of the RMF. In a valid QSPEC,
at least one QSPEC object of the type QoS Desired, QoS Available or
QoS Reserved MUST be included.
QoS Available: QSPEC object containing parameters describing the
available resources. They are used to collect information along a
reservation path.
QoS Desired: QSPEC object containing parameters describing the
desired QoS for which the sender requests reservation.
QoS Model (QOSM): A method to achieve QoS for a traffic flow, e.g.,
IntServ Controlled Load. A QOSM specifies a set of mandatory and
optional QSPEC parameters that describe the QoS and how resources
will be managed by the RMF. It furthermore specifies how to use QoS
NSLP to signal for this QOSM.
QoS Reserved: QSPEC object containing parameters describing the
reserved resources and related QoS parameters, for example,
bandwidth.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 5]
Internet Draft QoS-NSLP QSPEC Template July 2005
QSPEC Control Information: Control information that is specific to a
QSPEC, and contains parameters that govern the RMF.
QSPEC: QSPEC is the object of QoS-NSLP containing all QOSM-specific
information.
QSPEC parameter: Any parameter appearing in a QSPEC; includes both
QoS description and QSPEC control information parameters, for
example, bandwidth, token bucket, and excess treatment parameters.
QSPEC Object: Main building blocks of QoS Description containing a
QSPEC parameter set that is input or output of an RMF operation.
Resource Management Function (RMF): Functions that are related to
resource management, specific to a QOSM. It processes the QoS
description parameters and QSPEC control parameters.
Read-only Parameter: QSPEC Parameter that is set by initiating or
responding QNE and is not changed during the processing of the QSPEC
along the path.
Read-write Parameter: QSPEC Parameter that can be changed during the
processing of the QSPEC by any QNE along the path.
4. QSPEC Parameters, Processing, & Extensibility
4.1 QSPEC Parameters
The definition of a QOSM includes the specification of how the
requested QoS resources will be described and how they will be
managed by the RMF. For this purpose, the QOSM specifies a set of
QSPEC parameters that describe the QoS and QoS resource control in
the RMF. A given QOSM defines which of the mandatory and optional
QSPEC parameters it uses, and it MAY define additional optional QSPEC
parameters. Mandatory and optional QSPEC parameters provide a common
language for QOSM developers to build their QSPECs and are likely to
be re-used in several QOSMs. Mandatory and optional QSPEC parameters
are defined in this document, and additional optional QSPEC
parameters can be defined in separate documents. Specification of
additional optional QSPEC parameters requires standards action, as
defined in Section 4.5.
4.2 QSPEC Processing
The QSPEC is opaque to the QoS-NSLP processing. The QSPEC control
information and the QoS description are interpreted and MAY be
modified by the RMF in a QNE (see description in [QoS-SIG]).
A QoS-enabled domain supports a particular QOSM, e.g. DiffServ
admission control. If this domain supports QoS-NSLP signaling, its
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 6]
Internet Draft QoS-NSLP QSPEC Template July 2005
QNEs MUST support the DiffServ admission control QOSM. The QNEs MAY
also support additional QOSMs.
A QoS NSLP message can contain a stack of at most 2. The first on
the stack is the Initiator QSPEC. This is a QSPEC provided by the
QNI, which travels end-to-end, and therefore the stack always has at
least depth 1. QSPEC parameters MUST NOT be deleted from or added to
the Initiator QSPEC. In addition, the stack MAY contain a Local
QSPEC stacked on top of the Initiator QSPEC. A QNE only considers
the topmost QSPEC.
At the ingress edge of a local QoS domain, a Local QSPEC MAY be
pushed on the stack in order to describe the requested resources in a
domain-specific manner. Also, the Local QSPEC is popped from the
stack at the egress edge of the local QoS domain.
This draft provides a template for the QSPEC, which is needed in
order to help define individual QOSMs and in order to promote
interoperability between QOSMs. Figure 1 illustrates how the QSPEC
is composed of QSPEC control information and QoS description. QoS
description in turn is composed of up to four QSPEC objects (not all
of them need to be present), namely QoS Desired, QoS Available, QoS
Reserved and Minimum QoS. Each of these QSPEC Objects, as well as
QSPEC Control Information, consists of a number of mandatory and
optional QSPEC parameters.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 7]
Internet Draft QoS-NSLP QSPEC Template July 2005
+-------------+---------------------------------------+
|QSPEC Control| QoS |
| Information | Description |
+-------------+---------------------------------------+
\________________ ______________________/
V
+----------+----------+---------+-------+ \
|QoS Desir.|QoS Avail.|QoS Rsrv.|Min QoS| > QSPEC
+----------+----------+---------+-------+ / Objects
\_______ ____/\____ ____/\___ _____/\___ ____/\__ ___/
V V V V V
+-------------+... +-------------+...
|QSPEC Para. 1| |QSPEC Para. n|
+-------------+... +-------------+...
Figure 1: Structure of the QSPEC
The internal structure of each QSPEC object and the QSPEC control
information, with mandatory and optional parameters, is illustrated
in Figure 2.
+------------------+-----------------+---------------+
| QSPEC/Ctrl Info | Mandatory QSPEC |Optional QSPEC |
| Object ID | Parameters | Parameters |
+------------------+-----------------+---------------+
Figure 2: Structure of QSPEC Objects & Control Information
4.3 Example of NSLP/QSPEC Operation
This Section illustrates the operation and use of the QSPEC within
the NSLP. The example configuration in shown in Figure 3.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 8]
Internet Draft QoS-NSLP QSPEC Template July 2005
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | DiffServ |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | "X"G | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/
Figure 3: Example Configuration to Illustrate QoS-NSLP/QSPEC
Operation
In this configuration, a laptop computer and a handheld wireless
device are the endpoints for some application that has QoS
requirements. Assume initially that the two endpoints are stationary
during the application session, later we consider mobile endpoints.
For this session, the laptop computer is connected to a home network
that has no QoS support. The home network is connected to a
CableLabs-type cable access network with dynamic QoS (DQOS) support,
such as specified in the 'CMS to CMS Signaling Specification' [CMSS]
for cable access networks. That network is connected to a DiffServ
core network that uses the RMD QOSM [RMD-QOSM]. On the other side of
the DiffServ core is a wireless access network built on generation
"X" technology with QoS support as defined by generation "X". And
finally the handheld endpoint is connected to the wireless access
network.
We assume that the Laptop is the QNI and handheld device is the QNR.
The QNI will populate an Initiator QSPEC to achieve the QoS desired
on the path. In this example we consider two different ways to
perform sender-initiated signaling for QoS:
Case 1) The QNI sets <QoS Desired>, <QoS Available> and possibly
<Minimum QoS> QSPEC objects in the Initiator QSPEC, and initializes
<QoS Available> to <QoS Desired>. Since this is a reservation in a
heterogenic network with different QOSMs supported in different
domains, each QNE on the path reads and interprets those parameters
in the Initiator QSPEC that it needs to implement the QOSM within its
domain (as described below). Each QNE along the path checks to see if
<QoS Available> resources can be reserved, and if not, the QNE
reduces the respective parameter values in <QoS Available> and
reserves these values. The minimum parameter values are given in
<Minimum QoS>, if populated, otherwise zero if <Minimum QoS> is not
included. If one or more parameters in <Available QoS> fails to
satisfy the corresponding minimum values in Minimum QoS, the QNE
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 9]
Internet Draft QoS-NSLP QSPEC Template July 2005
notifies the QNI and the reservation is aborted. Otherwise, the QNR
notifies the QNI of the <QoS Available> for the reservation.
Case 2) The QNI populated the Initiator QSPEC with <QoS Desired>.
Since this is a reservation in a heterogenic network with different
QOSMs supported in different domains, each QNE on the path reads and
interprets those parameters in the Initiator QSPEC that it needs to
implement the QOSM within its domain (as described below). If a QNE
cannot reserve <QoS Desired> resources, the reservation fails.
In both cases, the QNI populates mandatory and optional QSPEC to
ensure correct treatment of its traffic in domains down the path.
Since the QNI does not know the QOSM used in downstream domains, it
includes values for those mandatory and optional QSPEC parameters it
cares about. Let us assume the QNI wants to achieve IntServ-like QoS
guarantees, and also is interested in what path latency it can
achieve. The QNI therefore includes in the QSPEC the QOSM ID for
IntServ Controlled Load Service. The QSPEC objects are populated with
all parameters necessary for IntServ Controlled Load and additionally
the parameter to measure path latency, as follows:
<QoS Desired> = <Token Bucket>
<QoS Available> = <Token Bucket> <Path Latency>
In both cases, each QNE on the path reads and interprets those
parameters in the Initiator QSPEC that it needs to implement the QOSM
within its domain. It may need additional parameters for its QOSM,
which are not specified in the Initiator QSPEC. If possible, these
parameters must be inferred from those that are present, according to
rules defined in the QOSM implemented by this QNE.
There are two possibilities when a RESERVE message is received at a
QNE at a domain border (we illustrate both possibilities in the
example):
- the QNE can stack a local QSPEC on top of the Initiator QSPEC (this
is new in QoS NSLP, RSVP does not do this).
- the QNE can tunnel the Initiator RESERVE message through its domain
and issue its own Local RESERVE message. For this new Local RESERVE
message, the QNE acts as the QNI, and the QSPEC in the domain is an
Initiator QSPEC. This procedure is also used by RSVP in making
aggregate reservations, in which case there is not a new intra-domain
(aggregate) RESERVE for each newly arriving interdomain (per-flow)
RESERVE, but the aggregate reservation is updated by the border QNE
(QNI) as need be. This is also how RMD works [RMD-QOSM].
For example, at the RMD domain, a local RESERVE with its own RMD
Initiator QSPEC corresponding to the RMD-QOSM is generated based on
the original Initiator QSPEC according to the procedures described in
Section 4.5 of [QoS-SIG] and in [RMD-QOSM]. That is, the ingress QNE
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 10]
Internet Draft QoS-NSLP QSPEC Template July 2005
to the RMD domain must map the QSPEC parameters contained in the
original Initiator QSPEC into the RMD QSPEC. The RMD QSPEC for
example needs <Bandwidth> and <QoS Class>. <Bandwidth> is generated
from the <Token Bucket> parameter. Information on <QoS Class>,
however, is not provided. According to the rules laid out in the RMD
QOSM, the ingress QNE infers from the fact that an IntServ Controlled
Load QOSM was signaled that the EF PHB is appropriate to set the <PHB
Class> parameter. These RMD QSPEC parameters are populated in the
RMD Initiator QSPEC generated within the RMD domain.
Furthermore, the node at the egress to the RMD domain updates <QoS
Available> on behalf of the entire RMD domain if it can. If it
cannot, it raises parameter-specific flags, warning the QNR that the
final value of these parameters in QoS Available is imprecise.
In the XG domain, the Initiator QSPEC is translated into a Local
QSPEC using a similar procedure as described above. The Local QSPEC
becomes the current QSPEC used within the XG domain, that is, the
it becomes the first QSPEC on the stack, and the Initiator QSPEC is
second. This saves the QNEs within the XG domain the trouble of
re-translating the Initiator QSPEC. At the egress edge of the XG
domain, the translated Local QSPEC is popped, and the Initiator QSPEC
returns to the number one position.
If the reservation was successful, eventually the RESERVE request
arrives at the QNR (otherwise the QNE at which the reservation failed
would have aborted the RESERVE and sent an error RESPONSE back to the
QNI). The QNR generates a positive RESPONSE with QSPEC objects <QoS
Reserved> - and for case 1 - additionally <QoS Available>. The
parameters appearing in <QoS Reserved> are the same as in <QoS
Desired>, with values copied from <QoS Available> in case 1, and with
the original values from <QoS Desired> in case 2. That is, it is not
necessary to transport the <QoS Desired> object back to the QNI since
the QNI knows what it signaled originally, and the information is not
useful for QNEs in the reverse direction. The <QoS Reserved> object
should transport all necessary information, although the <QoS
Available> and <QoS Reserved> objects may end up transporting some of
the same information.
Hence, the QNR populates the following QSPEC objects:
<QoS Reserved> = <Token Bucket>
<QoS Available> = <Token Bucket> <Path Latency>
If the handheld device on the right of Figure 3 is mobile, and moves
through different "XG" wireless networks, then the QoS might change
on the path since different XG wireless networks might support
different QOSMs. As a result, QoS-NSLP/QSPEC processing will have to
renegotiate the <QoS Available> on the path. From a QSPEC
perspective, this is like a new reservation on the new section of the
path and is basically the same as any other rerouting event - to the
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 11]
Internet Draft QoS-NSLP QSPEC Template July 2005
QNEs on the new path it looks like a new reservation. That is, in
this mobile scenario, the new segment may support a different QOSM
than the old segment, and the QNI would now signal a new reservation
(explicitly, or implicitly with the next refreshing RESERVE message)
to account for the different QOSM in the XG wireless domain. Further
details on rerouting are specified in [QoS-SIG].
4.4 Treatment of QSPEC Parameters
4.4.1 Mandatory and Optional QSPEC Parameters
Mandatory and optional QSPEC parameters are defined in this document
and are applicable to a number of QOSMs. Mandatory QSPEC parameters
are treated as follows:
o A QNI SHOULD populate mandatory QSPEC parameters if applicable to
the underlying QOSM.
o QNEs MUST interpret mandatory QSPEC parameters, if populated.
Optional QSPEC parameters are treated as follows:
o A QNI SHOULD populate optional QSPEC parameters if applicable to
the QOSM for which it is signaling.
o QNEs SHOULD interpret optional QSPEC parameters, if populated and
applicable to the QOSM(s) supported by the QNE. (A QNE MAY ignore
the optional QSPEC parameter if it does not support a QOSM needing
the optional QSPEC parameter).
4.4.2 Read-only and Read-write QSPEC Parameters
Both mandatory and optional QSPEC parameters can be read-only or
read-write. Read-write parameters can be changed by any QNE, whereas
read-only parameters are fixed by the QNI and/or QNR. For example in
a RESERVE message, all parameters in <QoS Available> are read-write
parameters, which are updated by intermediate QNEs. Read-only
parameters are, for example, all parameters in <QoS Desired> as sent
by the QNI.
QoS description parameters can be both read-only or read-write,
depending on which QSPEC object, and which message, they appear in.
In particular, all parameters in <QoS Desired> and <Minimum QoS> are
read-only for all messages. More details are provided in Sec. 7.1.
In the QSPEC Control Information Object, the property of being
read-write or read-only is parameter specific.
4.5 QSPEC Extensibility
Additional optional QSPEC parameters MAY need to be defined in the
future. Additional optional QSPEC parameters are defined in separate
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 12]
Internet Draft QoS-NSLP QSPEC Template July 2005
Informational documents specific to a given QOSM. For example,
optional QSPEC parameters are defined in [RMD-QOSM] and
[Y.1541-QOSM].
5. QSPEC Format Overview
QSPEC = <QOSM ID> <QSPEC Control Information> <QoS Description>
As described above, the QSPEC contains an identifier for the QOSM,
the actual resource description (QoS description) as well as QSPEC
control information. Note that all QSPEC parameters defined in the
following Sections are mandatory QSPEC parameters unless specifically
designated as optional QSPEC parameters.
Each optional QSPEC parameter has an associated 'non-support' flag.
If such a flag is set, at least one QNE along the data transmission
path between the QNI and QNR can not support the specified optional
parameter.
Each mandatory and optional QSPEC parameter has an associated
'tunneled parameter' flag. When a RESERVE message is tunneled
through a domain, QNEs inside the domain cannot update read-write
parameters. The egress QNE in a domain has two choices: Either it is
configured to have the knowledge to update the parameters correctly.
Or it cannot update the parameters. In this case it MUST set the
tunneled parameter flag to tell the QNI (or QNR) that the
information contained in the read-write parameter is most likely
incorrect (or a lower bound).
A QSPEC object ID identifies whether the object is <QSPEC Control
Information> or <QoS Description>. As described below, the <QoS
Description> is further broken down into <QoS Desired>, <QoS
Available>, <QoS Reserved>, and <Minimum QoS> objects. A QSPEC
parameter ID is assigned to identify each QSPEC parameter defined
below.
A QOSM ID is included in the QSPEC and tells a QNE which parameters
to expect. This may simplify processing and error analysis.
Furthermore, it may be helpful for a QNE or a domain supporting more
than one QOSM to learn which QOSM the QNI would like to have in order
to use the most suitable QOSM. Note that the QSPEC parameters do not
uniquely define the QNI QOSM since more parameters than required by
the QNI QOSM can be included by the QNI. QOSM IDs are assigned by
IANA.
5.1. QSPEC Control Information
QSPEC control information is used for signaling QOSM RMF functions
not defined in QoS-NSLP. It enables building new RMF functions
required by a QOSM within a QoS-NSLP signaling framework, such as
specified, for example, in [RMD-QOSM] and [Y.1541-QOSM].
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 13]
Internet Draft QoS-NSLP QSPEC Template July 2005
<QSPEC Control Information> = <QOSM ID> <QSPEC Procedure Identifier>
<NON QOSM Hop> <Excess Treatment>
Note that <NON QOSM Hop> is a read-write parameter. <QOSM ID>, <QSPEC
Procedure Identifier> and <Excess Treatment> are read-only
parameters.
<QOSM ID> identifies the particular QOSM being used by the QNI (the
QOSM ID is assigned by IANA)>
<QSPEC Procedure Identifier> is an identifier for which QSPEC
procedures are used, as defined in Section 7.1.
<NON QOSM Hop> is a flag bit telling the QNR (or QNI in a RESPONSE
message) whether or not a particular QOSM is supported by each QNE
in the path between the QNI and QNR. A QNE sets the <NON QOSM Hop>
flag parameter if it does not support the relevant QOSM
specification. If the QNR finds this bit set, at least one QNE along
the data transmission path between the QNI and QNR can not support
the specified QOSM.In a local QSPEC, <NON QOSM Hop> refers to the
QoS-NSLP peers of the local QOSM domain.
The <Excess Treatment> parameter describes how the QNE will process
excess traffic, that is, out-of-profile traffic. Excess traffic MAY
be dropped, shaped and/or remarked. The excess treatment parameter is
initially set by the QNI and is read-only.
5.2 QoS Description
The QoS Description is broken down into the following QSPEC objects:
<QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
<Minimum QoS>
Of these QSPEC objects, QoS Desired, QoS Available and QoS Reserved
MUST be supported by QNEs. Minimum QoS MAY be supported.
5.2.1 <QoS Desired>
<QoS Desired> = <Traffic Description> <QoS Class> <Priority>
<Path Latency> <Path Jitter> <Path BER>
These parameters describe the resources the QNI desires to reserve
and hence this is a read-only QSPEC object. The <QoS Desired>
resources that the QNI wishes to reserve are of course directly
related to the traffic the QNI is going to inject into the network.
Therefore, when used in the <QoS Desired> object, <Traffic
Description> refers to traffic injected by the QNI into the network.
<Traffic Description> = <Bandwidth> <Token Bucket>
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 14]
Internet Draft QoS-NSLP QSPEC Template July 2005
<Bandwidth> = link bandwidth needed by flow [RFC 2212, RFC 2215]
<Token Bucket> = <r> <b> <p> <m> <MTU> [RFC 2210]
Note that the Path MTU Discovery (PMTUD) working group is currently
specifying a robust method for determining the MTU supported over an
end-to-end path. This new method is expected to update RFC1191 and
RFC1981, the current standards track protocols for this purpose.
<QoS Class> = <PHB Class> <Y.1541 QoS Class> <DSTE Class Type>
An application MAY like to reserve resources for packets with a
particular QoS class, e.g. a DiffServ per-hop behavior (PHB)
[RFC2475], or DiffServ-enabled MPLS traffic engineering (DSTE) class
type [RFC3564].
<Priority> = <Reservation Priority> <Preemption Priority>
<Defending Priority>
<Reservation priority> is an essential way to differentiate flows for
emergency services, ETS, E911, etc., and assign them a higher
admission priority than normal priority flows and best-effort
priority flows. <Preemption Priority> is the priority of the new
flow compared with the defending priority of previously admitted
flows. Once a flow is admitted, the preemption priority becomes
irrelevant. <Defending Priority> is used to compare with the
preemption priority of new flows. For any specific flow, its
preemption priority MUST always be less than or equal to the
defending priority.
Appropriate security measures need to be taken to prevent abuse of
the <Priority> parameters, see Section 8 on Security Considerations.
<Path Latency>, <Path Jitter> and <Path BER> are optional parameters
describing the desired path latency, path jitter and path bit error
rate respectively. Since these parameters are cumulative, an
individual QNE cannot decide whether the desired path latency, etc.,
is available, and hence they cannot decide whether a reservation
fails. Rather, when these parameters are included in <Desired QoS>,
the QNI SHOULD also include corresponding parameters in a <QoS
Available> QSPEC object in order to facilitate collecting this
information.
5.2.2 <QoS Available>
<QoS Available> = <Traffic Description> <QoS Class> <Priority>
<Path Latency> <Path Jitter> <Path BER> <Ctot>
<Dtot> <Csum> <Dsum>
When used in the <QoS Available> object, <Traffic Description> refers
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 15]
Internet Draft QoS-NSLP QSPEC Template July 2005
to traffic resources available at a QNE in the network.
<Path Latency>, <Path Jitter>, <Path BER>, <Ctot>, <Dtot>, <Csum>,
and <Dsum> are optional QSPEC parameters. As such, each of these
optional QSPEC parameters has an associated flag, that is, <Path
Latency Flag>, <Path Jitter Flag>, <Path BER Flag>, <Ctot Flag>,
<Dtot Flag>, <Csum Flag>, and <Dsum Flag>. If these flags are set,
then at least one QNE along the data transmission path between the
QNI and QNR can not support the specified optional parameter. This
means the value collected in the corresponding parameter is a lower
bound to the "real" value. A QNE MUST be able to set the optional
parameter flag if it does not support the optional parameter, and as
such the optional parameter flags are mandatory QSPEC parameters.
The <QoS Available> Object collects information on the resources
currently available on the path when it travels in a RESERVE or QUERY
message and hence in this case this QSPEC object is read-write. Each
QNE MUST inspect all parameters of this QSPEC object, and if
resources available to this QNE are less than what a particular
parameter says currently, the QNE MUST adapt this parameter
accordingly. Hence when the message arrives at the recipient of the
message, <QoS Available> reflects the bottleneck of the resources
currently available on a path. It can be used in a QUERY message,
for example, to collect the available resources along a data path.
When <QoS Available> travels in a RESPONSE message, it in fact just
transports the result of a previous measurement performed by a
RESERVE or QUERY message back to the initiator. Therefore in this
case, <QoS Available> is read-only.
The parameters <Token Bucket> and <Bandwidth> provide information,
for example, about the bandwidth available along the path followed by
a data flow. The local parameter is an estimate of the bandwidth the
QNE has available for packets following the path. Computation of the
value of this parameter SHOULD take into account all information
available to the QNE about the path, taking into consideration
administrative and policy controls on bandwidth, as well as physical
resources. The composition rule for this parameter is the MIN
function. The composed value is the minimum of the QNE's value and
the previously composed value. This quantity, when composed
end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
minimal bandwidth link along the path from QNI to QNR.
The <Path Latency> parameter accumulates the latency of the packet
forwarding process associated with each QNE, where the latency is
defined to be the smallest possible packet delay added by each QNE.
This delay results from speed-of-light propagation delay, from packet
processing limitations, or both. It does not include any variable
queuing delay which may be present. Each QNE MUST add the
propagation delay of its outgoing link, which includes the QNR adding
the associated delay for the egress link. Furthermore, the QNI MUST
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 16]
Internet Draft QoS-NSLP QSPEC Template July 2005
add the propagation delay of the ingress link. The composition rule
for the <Path Latency> parameter is summation with a clamp of
(2**32 - 1) on the maximum value. This quantity, when composed
end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
minimal packet delay along the path from QNI to QNR. The purpose of
this parameter is to provide a minimum path latency for use with
services which provide estimates or bounds on additional path delay
[RFC 2212]. Together with the queuing delay bound, this parameter
gives the application knowledge of both the minimum and maximum
packet delivery delay. Knowing both the minimum and maximum latency
experienced by data packets allows the receiving application to know
the bound on delay variation and de-jitter buffer requirements.
The <Path Jitter> parameter accumulates the jitter of the packet
forwarding process associated with each QNE, where the jitter is
defined to be the nominal jitter added by each QNE. IP packet
jitter, or delay variation, is defined in RFC 3393 [RFC3393], Section
4.6 (Type-P-One-way-peak-to-peak-ipdv), where the suggested
evaluation interval is 1 minute. Note that the method to estimate
peak-to-peak IP delay variation without active measurements requires
more study. This jitter results from packet processing limitations,
and includes any variable queuing delay which may be present. Each
QNE MUST add the jitter of its outgoing link, which includes the QNR
adding the associated jitter for the egress link. Furthermore, the
QNI MUST add the jitter of the ingress link. The composition rule
for the <Path Jitter> parameter is summation of a large percentage of
the peak-to-peak variation with a clamp on the maximum value (note
that the methods of accumulation and estimation of nominal QNE jitter
are under study). This quantity, when composed end-to-end, informs
the QNR (or QNI in a RESPONSE message) of the nominal packet jitter
along the path from QNI to QNR. The purpose of this parameter is to
provide a nominal path jitter for use with services that provide
estimates or bounds on additional path delay [RFC 2212]. Together
with the <Path Latency> and the queuing delay bound, this parameter
gives the application knowledge of the typical packet delivery delay
variation.
The <Path BER> parameter accumulates the bit error rate (BER) of the
packet forwarding process associated with each QNE, where the BER is
defined to be the smallest possible BER added by each QNE. Each QNE
MUST add the BER of its outgoing link, which includes the QNR adding
the associated BER for the egress link. Furthermore, the QNI MUST
add the BER of the ingress link. The composition rule for the
<Path BER> parameter is summation with a clamp on the maximum value
(this assumes sufficiently low BER values such that summation error
is not significant). This quantity, when composed end-to-end,
informs the QNR (or QNI in a RESPONSE message) of the minimal packet
BER along the path from QNI to QNR. As with <Jitter>, the method to
estimate <Path BER> requires more study.
<Ctot>, <Dtot>, <Csum>, <Dsum>: Error terms C and D represent how the
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 17]
Internet Draft QoS-NSLP QSPEC Template July 2005
element's implementation of the guaranteed service deviates from the
fluid model. These two parameters have an additive composition rule.
The error term C is the rate-dependent error term. It represents the
delay a datagram in the flow might experience due to the rate
parameters of the flow. The error term D is the rate-independent,
per-element error term and represents the worst case non-rate-based
transit time variation through the service element. If the
composition function is applied along the entire path to compute the
end-to-end sums of C and D (<Ctot> and <Dtot>) and the resulting
values are then provided to the QNR (or QNI in a RESPONSE message).
<Csum> and <Dsum> are the sums of the parameters C and D between the
last reshaping point and the current reshaping point.
5.2.3 <QoS Reserved>
<QoS Reserved> = <Traffic Description> <QoS Class> <Priority> <S>
These parameters describe the QoS reserved by the QNEs along the data
path, and hence the QoS reserved QSPEC object is read-write.
<Traffic Description>, <QoS Class> and <Priority> are defined above.
<S> = slack term, which is the difference between desired delay and
delay obtained by using bandwidth reservation, and which is used to
reduce the resource reservation for a flow [RFC 2212]. This is an
optional parameter.
5.2.4 <Minimum QoS>
<Minimum QoS> = <Traffic Description> <QoS Class> <Priority>
<Minimum QoS> does not have an equivalent in RSVP. It allows the QNI
to define a range of acceptable QoS levels by including both the
desired QoS value and the minimum acceptable QoS in the same message.
It is a read-only QSPEC object. The desired QoS is included with a
<QoS Desired> and/or a <QoS Available> QSPEC object seeded to the
desired QoS value. The minimum acceptable QoS value MAY be coded in
the <Minimum QoS> QSPEC object. As the message travels towards the
QNR, <QoS Available> is updated by QNEs on the path. If its value
drops below the value of <Minimum QoS> the reservation fails and is
aborted. When this method is employed, the QNR SHOULD signal back to
the QNI the value of <QoS Available> attained in the end, because the
reservation MAY need to be adapted accordingly.
Future versions of this document will describe how <Minimum QoS> can
be used by the QNI to send a discrete set of desired parameters.
6. QSPEC Functional Specification
This Section defines the encodings of the QSPEC parameters and QSPEC
control information defined in Section 5. We first give the general
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 18]
Internet Draft QoS-NSLP QSPEC Template July 2005
QSPEC formats and then the formats of the QSPEC objects and
parameters.
Note that all QoS Description parameters can be either read-write or
read-only, depending on which object and which message they appear
in.
6.1 General QSPEC Formats:
Note: This section is in a draft state and further work is needed to
define exact formats of objects.
Type: QSPEC
Length: Variable
Value: This object contains a 2 byte QOSM ID and variable length
QSPEC information, which is QOSM specific.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOSM ID | Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID | Parameter ID | Length (bytes)|Parameter Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Parameter Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID | Parameter ID | Length (bytes)|Parameter Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Parameter Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object ID:
0: control information
1: QoS Desired
2: QoS Available
3: QoS Reserved
4: Min QoS
Alternatively, in order to make the coding more efficient, QOSMs may
define one or more optional 'container QSPEC parameter', which
contain several sub-parameters. However, optional parameters that are
expected to be used by several QOSMs (as e.g. the optional <path
latency> parameter defined in this document) SHOULD be defined as
individual parameters, i.e. not inside a container QSPEC parameter.
For example, a container QSPEC parameter might be defined as follows:
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 19]
Internet Draft QoS-NSLP QSPEC Template July 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object ID = 0 | Parameter ID | Length = 5 | Para 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Para 2 |S|M| Para 5 |U|B| Para 8 | Empty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where "Para n" is the nth sub-parameter, and S, M, U and B are flags.
The individual parameters in the container can be parsed out as
needed by the RMF. By using the container the relative overhead of
the QSPEC header to the payload can be decreased considerably when a
QOSM uses many short parameters.
6.2 <QSPEC Procedure Identifier> Parameter
Object ID = 0
Parameter ID = 0
Length = 1 byte
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|QSPEC Procedure|
| Identifier |
+-+-+-+-+-+-+-+-+
QSPEC Procedure Identifier: This is an identifier for which QSPEC
procedures are used, as defined in Section 7.1. Allowed values are
as follows:
0: Sender-Initiated Reservations, as defined in Section 7.1.1
1: Receiver-Initiated Reservations, as defined in Section 7.1.2
2: Resource Queries, as defined in Section 7.1.3
3: Bidirectional Reservations, as defined in Section 7.1.4
6.3 <NON QOSM Hop> Parameter
Object ID = 0
Parameter ID = 1
Length = 1 byte
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| NON QOSM Hop |
+-+-+-+-+-+-+-+-+
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 20]
Internet Draft QoS-NSLP QSPEC Template July 2005
NON QOSM Hop: This field is set to 1 if a non QOSM-aware QNE is
encountered on the path from the QNI to the QNR.
6.4 <Excess Treatment> Parameter
Object ID = 0
Parameter ID = 2
Length = 1 byte
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Excess |
| Treatment |
+-+-+-+-+-+-+-+-+
Excess Treatment: Indicates how the QNE SHOULD process out-of-profile
traffic. Allowed values are as follows:
0: drop
1: shape
2: remark
The excess treatment parameter is set by the QNI.
6.5 <Bandwidth> & <S> Parameters [RFC 2212, RFC 2215]
The <Bandwidth> parameter MUST be nonnegative and is measured in
bytes per second and has the same range and suggested representation
as the bucket and peak rates of the <Token Bucket>. <Bandwidth> can
be represented using single-precision IEEE floating point. The
representation MUST be able to express values ranging from 1 byte per
second to 40 terabytes per second. For values of this parameter only
valid non-negative floating point numbers are allowed. Negative
numbers (including "negative zero"), infinities, and NAN's are not
allowed.
A QNE MAY export a local value of zero for this parameter. A network
element or application receiving a composed value of zero for this
parameter MUST assume that the actual bandwidth available is unknown.
Object ID = 1-4
Bandwidth Parameter ID = 3
Slack Term Parameter ID = 4
Length = 4 bytes
Bandwidth is Mandatory QSPEC Parameter
Slack Term is Optional QSPEC Parameter
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 21]
Internet Draft QoS-NSLP QSPEC Template July 2005
Parameter Values:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Slack term S MUST be nonnegative and is measured in microseconds.
The Slack term, S, can be represented as a 32-bit integer. Its value
can range from 0 to (2**32)-1 microseconds.
6.6 <Token Bucket> Parameters [RFC 2215]
The <Token Bucket> parameters are represented by three floating
point numbers in single-precision IEEE floating point format followed
by two 32-bit integers in network byte order. The first floating
point value is the rate (r), the second floating point value is the
bucket size (b), the third floating point is the peak rate (p), the
first integer is the minimum policed unit (m), and the second integer
is the maximum datagram size (MTU).
Note that the two sets of <Token Bucket> parameters can be
distinguished, as could be needed for example to support DiffServ
applications (see Section 7.2).
Object ID = 1-4
Token Bucket #1 Parameter ID = 5
Token Bucket #2 Parameter ID = 6
Length = 20 bytes
Mandatory QSPEC Parameters
Parameter Values:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When r, b, p, and R terms are represented as IEEE floating point
values, the sign bit MUST be zero (all values MUST be non-negative).
Exponents less than 127 (i.e., 0) are prohibited. Exponents greater
than 162 (i.e., positive 35) are discouraged, except for specifying a
peak rate of infinity. Infinity is represented with an exponent of
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 22]
Internet Draft QoS-NSLP QSPEC Template July 2005
all ones (255) and a sign bit and mantissa of all zeroes.
6.7 <QoS Class> Parameters
6.7.1 <PHB Class> Parameter [RFC 3170]
As prescribed in RFC 3170, the encoding for a single PHB is the
recommended DSCP value for that PHB, left-justified in the 16 bit
field, with bits 6 through 15 set to zero.
Object ID = 1-4
PHB Class Parameter ID = 7
Length = 2 bytes
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSCP | 0 0 0 0 0 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
The registries needed to use RFC 3140 already exist, see [DSCP-
REGISTRY, PHBID-CODES-REGISTRY]. Hence, no new registry needs to be
created for this purpose.
6.7.2 <Y.1541 QoS Class> Parameter [Y.1541]
Y.1541 QoS classes are defined as follows:
Object ID = 1-4
Y.1541 QoS Class Parameter ID = 8
Length = 1 byte
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Y.1541 |
| QoS Class |
+-+-+-+-+-+-+-+-+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently
allowed are 0, 1, 2, 3, 4, 5.
Class 0:
Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3.
Real-time, highly interactive applications, sensitive to jitter.
Application examples include VoIP, Video Teleconference.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 23]
Internet Draft QoS-NSLP QSPEC Template July 2005
Class 1:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3.
Real-time, interactive applications, sensitive to jitter.
Application examples include VoIP, Video Teleconference.
Class 2:
Mean delay <= 100 ms, delay variation unspecified, loss ratio <=
10^-3. Highly interactive transaction data. Application examples
include signaling.
Class 3:
Mean delay <= 400 ms, delay variation unspecified, loss ratio <=
10^-3. Interactive transaction data. Application examples include
signaling.
Class 4:
Mean delay <= 1 sec, delay variation unspecified, loss ratio <=
10^-3. Low Loss Only applications. Application examples include
short transactions, bulk data, video streaming.
Class 5:
Mean delay unspecified, delay variation unspecified, loss ratio
unspecified. Unspecified applications. Application examples include
traditional applications of default IP networks.
6.7.3 <DSTE Class Type> Parameter [RFC3564]
DSTE class type is defined as follows:
Object ID = 1-4
DSTE Class Type Parameter ID = 9
Length = 1 byte
Mandatory QSPEC Parameter
Parameter Values:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| DSTE |
| Class Type |
+-+-+-+-+-+-+-+-+
DSTE Class Type: Indicates the DSTE class type. Values currently
allowed are 0, 1, 2, 3, 4, 5, 6, 7.
6.8 Priority Parameters
6.8.1 <Preemption Priority> & <Defending Priority> Parameters
[RFC 3181]
Object ID = 1-4
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 24]
Internet Draft QoS-NSLP QSPEC Template July 2005
Preemption Priority Parameter ID = 10
Defending Priority Parameter ID = 11
Length = 2 bytes (unsigned)
Mandatory QSPEC Parameter
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The priority of the new flow compared with the
defending priority of previously admitted flows. Higher values
represent higher priority.
Defending Priority: Once a flow is admitted, the preemption priority
becomes irrelevant. Instead, its defending priority is used to
compare with the preemption priority of new flows.
6.8.2 <Reservation Priority> Parameter [PRIORITY-RQMTS, SIP-PRIORITY]
Object ID = 1-4
Admission Priority Parameter ID = 12
RPH Namespace Parameter ID = 13
RPH Priority Parameter ID = 14
Length = 4 bytes
Mandatory QSPEC Parameter
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Admission | RPH Namespace | RPH Priority |
+ Priority | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
High priority flows, normal priority flows, and best-effort priority
flows can have access to resources depending on their admission
priority value, as described in [PRIORITY-RQMTS], as follows:
Admission Priority: 1 byte
0 - high priority flow
1 - normal priority flow
2 - best-effort priority flow
[SIP-PRIORITY] defines a resource priority header (RPH) with
parameters "RPH Namespace" and "RPH Priority" combination,
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 25]
Internet Draft QoS-NSLP QSPEC Template July 2005
applicable only to flows with high reservation priority, as follows:
RPH Namespace: 2 bytes
0 - dsn
1 - drsn
2 - q735
3 - ets
4 - wps
RPH Priority: 1 byte
Each namespace has a finite list of relative priority-values. Each
is listed here in the order of lowest priority to highest priority:
4 - dsn.routine
3 - dsn.priority
2 - dsn.immediate
1 - dsn.flash
0 - dsn.flash-override
5 - drsn.routine
4 - drsn.priority
3 - drsn.immediate
2 - drsn.flash
1 - drsn.flash-override
0 - drsn.flash-override-override
4 - q735.4
3 - q735.3
2 - q735.2
1 - q735.1
0 - q735.0
4 - ets.4
3 - ets.3
2 - ets.2
1 - ets.1
0 - ets.0
4 - wps.4
3 - wps.3
2 - wps.2
1 - wps.1
0 - wps.0
Note that SIP nodes can send multiple NameSpace.Priority tupple
values in the same message, in part because end nodes may not know
what Namespace "domain" it resides in, nor which Namespace "domains"
it may traverse. Therefore multiple <Reservation Priority>
parameters MAY be sent in a given QSPEC, which is turn contain
multiple RPH Namespace/Priority combinations.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 26]
Internet Draft QoS-NSLP QSPEC Template July 2005
Note that additional work is needed to communicate these flow
priority values to bearer-level network elements
[VERTICAL-INTERFACE].
6.9 <Path Latency> Parameter [RFC 2210, 2215]
Object ID = 1-4
Path Latency Parameter ID = 15
Length = 4 bytes
Optional QSPEC Parameter
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The latencies are
reported in units of one microsecond. An individual QNE can advertise
a latency value between 1 and 2**28 (somewhat over two minutes) and
the total latency added across all QNEs can range as high as
(2**32)-2. If the sum of the different elements delays exceeds
(2**32)-2, the end-to-end advertised delay SHOULD be reported as
indeterminate. A QNE that cannot accurately predict the latency of
packets it is processing MUST raise the Path Latency Flag and either
leave the value of Path Latency as is, or add its best estimate of
its lower bound. A raised Path Latency Flag indicates the value of
Path Latency is a lower bound of the real Path Latency. The
distinguished value (2**32)-1 is taken to mean indeterminate latency
because the composition function limits the composed sum to this
value, it indicates the range of the composition calculation was
exceeded.
6.10 <Path Jitter> Parameter
Object ID = 1-4
Path Jitter Parameter ID = 16
Length = 4 bytes
Optional QSPEC Parameter
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 27]
Internet Draft QoS-NSLP QSPEC Template July 2005
The composition rule for the <Path Jitter> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The jitters are
reported in units of one microsecond. An individual QNE can advertise
a jitter value between 1 and 2**28 (somewhat over two minutes) and
the total jitter added across all QNEs can range as high as
(2**32)-2. If the sum of the different elements delays exceeds
(2**32)-2, the end-to-end advertised jitter SHOULD be reported as
indeterminate. A QNE that cannot accurately predict the jitter of
packets it is processing MUST raise the Path Jitter Flag and either
leave the value of Path Jitter as is, or add its best estimate of its
lower bound. A raised Path Jitter Flag indicates the value of Path
Jitter is a lower bound of the real Path Jitter. The distinguished
value (2**32)-1 is taken to mean indeterminate jitter. A QNE which
cannot accurately predict the jitter of packets it is processing
SHOULD set its local parameter to this value. Because the
composition function limits the composed sum to this value, receipt
of this value at a network element or application indicates that the
true path jitter is not known. This MAY happen because one or more
network elements could not supply a value, or because the range of
the composition calculation was exceeded.
6.11 <Path BER> Parameter
Object ID = 1-4
Path BER Parameter ID = 17
Length = 4 bytes
Optional QSPEC Parameter
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Bit Error Rate (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The composition rule for the <Path BER> parameter is summation with
a clamp of 10^-2 on the maximum value. The BERs are reported in
units of 10^-11. An individual QNE can advertise a BER value between
1 and 2**28 and the total BER added across all QNEs can range as high
as (2**32)-2. If the sum of the different elements delays exceeds
(2**32)-2, the end-to-end advertised BER SHOULD be reported as
indeterminate. A QNE that cannot accurately predict the BER of
packets it is processing MUST raise the Path BER Flag and either
leave the value of Path BER as is, or add its best estimate of its
lower bound. A raised Path BER Flag indicates the value of Path BER
is a lower bound of the real Path BER. The distinguished value
(2**32)-1 is taken to mean indeterminate BER. A QNE which cannot
accurately predict the BER of packets it is processing SHOULD set its
local parameter to this value. Because the composition function
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 28]
Internet Draft QoS-NSLP QSPEC Template July 2005
limits the composed sum to this value, receipt of this value at a
network element or application indicates that the true path BER is
not known. This MAY happen because one or more network elements
could not supply a value, or because the range of the composition
calculation was exceeded.
6.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters [RFC 2210, 2212, 2215]
Object ID = 1-4
Ctot Parameter ID = 18
Dtot Parameter ID = 19
Csum Parameter ID = 20
Dsum Parameter ID = 21
Length = 4 bytes
Optional QSPEC Parameters
Parameter Values:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Since-last-reshaping point composed D [Dsum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The error term C is measured in units of bytes. An individual QNE
can advertise a C value between 1 and 2**28 (a little over 250
megabytes) and the total added over all QNEs can range as high as
(2**32)-1. Should the sum of the different QNEs delay exceed
(2**32)-1, the end-to-end error term MUST be set to (2**32)-1. The
error term D is measured in units of one microsecond. An individual
QNE can advertise a delay value between 1 and 2**28 (somewhat over
two minutes) and the total delay added over all QNEs can range as
high as (2**32)-1. Should the sum of the different QNEs delay
exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1.
6.13 Non-Support Flags
Object ID = 1-4
Path Latency Non-Support Flag Parameter ID = 22
Path Latency Non-Support Flag Parameter ID = 23
Path Latency Non-Support Flag Parameter ID = 24
Ctot Non-Support Flag Parameter ID = 25
Dtot Non-Support Flag Parameter ID = 26
Csum Non-Support Flag Parameter ID = 27
Dsum Non-Support Flag Parameter ID = 28
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 29]
Internet Draft QoS-NSLP QSPEC Template July 2005
Slack Term Non-Support Flag Parameter ID = 29
Length = 1 byte
Mandatory QSPEC Parameters
Parameter Values:
General format for the Non-Support Flag:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Non-Support |
| Flag |
+-+-+-+-+-+-+-+-+
This field is set to 1 if a QNE is encountered that does not support
the QSPEC parameter on the path from the QNI to the QNR.
6.14 Tunneled-Parameter Flags
Object ID = 1-4
<NON QOSM Hop> Tunneled-Parameter Flag Parameter ID = 30
<Excess Treatment> Tunneled-Parameter Flag Parameter ID = 31
<Bandwidth> Tunneled-Parameter Flag Parameter ID = 32
<S> Tunneled-Parameter Flag Parameter ID = 33
Token Bucket Rate Tunneled-Parameter Flag Parameter ID = 34
Token Bucket Size Tunneled-Parameter Flag Parameter ID = 35
Peak Data Rate Tunneled-Parameter Flag Parameter ID = 36
Minimum Policed Unit Tunneled-Parameter Flag Parameter ID = 37
Maximum Packet Size Tunneled-Parameter Flag Parameter ID = 38
PHB Class Tunneled-Parameter Flag Parameter ID = 39
Y.1541 QoS Class Tunneled-Parameter Flag Parameter ID = 40
DSTE Class Type Tunneled-Parameter Flag Parameter ID = 41
Preemption Priority Tunneled-Parameter Flag Parameter ID = 42
Defending Priority Tunneled-Parameter Flag Parameter ID = 43
Admission Priority Tunneled-Parameter Flag Parameter ID = 44
RPH Namespace Tunneled-Parameter Flag Parameter ID = 45
RPH Priority Tunneled-Parameter Flag Parameter ID = 46
Path Latency Tunneled-Parameter Flag Parameter ID = 47
Path Jitter Tunneled-Parameter Flag Parameter ID = 48
Path BER Tunneled-Parameter Flag Parameter ID = 49
Ctot Tunneled-Parameter Flag Parameter ID = 50
Dtot Tunneled-Parameter Flag Parameter ID = 51
Csum Tunneled-Parameter Flag Parameter ID = 52
Dsum Tunneled-Parameter Flag Parameter ID = 53
Length = 1 byte
Mandatory QSPEC Parameters
Parameter Values:
General format for the Tunneled-Parameter Flag:
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 30]
Internet Draft QoS-NSLP QSPEC Template July 2005
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tunneled- |
| Parameter Flag|
+-+-+-+-+-+-+-+-+
This field is set as follows: When a RESERVE message is tunneled
through a domain, QNEs inside the domain cannot update read-write
parameters. The egress QNE in a domain MUST set the tunneled-
parameter flag to tell the QNI (or QNR) that the information
contained in the read-write parameter is most likely incorrect (or a
lower bound).
7. QSPEC Procedures & Examples
7.1 QSPEC Procedures
While the QSPEC template aims to put minimal restrictions on usage of
QSPEC objects in <QoS Description>, interoperability between QNEs and
between QOSMs must be ensured. We therefore give below an exhaustive
list of QSPEC object combinations for the message sequences described
in QoS NSLP [QOS-SIG]. A specific QOSM may impose more restrictions
on the QNI or QNR freedom.
7.1.1 Sender-Initiated Reservations
Here the QNI issues a RESERVE, which is replied to by a RESPONSE.
This response is generated either by the QNR or, in case the
reservation was unsuccessful, by a QNE. The following possibilities
for QSPEC object usage exist:
| RESERVE | RESPONSE
---------------------------------------------------------------
a.| QoS Desired | QoS Reserved
b.| QoS Desired, QoS Avail. | QoS Reserved, QoS Avail.
c.| QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail.
a.) If only QoS Desired is included in the RESERVE, the implicit
assumption is that exactly these resources must be reserved. If this
is not possible the reservation fails. The parameters in QoS
Reserved are copied from the parameters in QoS Desired.
b.) When QoS Available is included in the RESERVE also, some
parameters will appear only in QoS Available and not in QoS Desired.
It is assumed that the value of these parameters is collected for
informational purposes only (e.g. path latency).
However, some parameters in QoS Available can be the same as in QoS
Desired. For these parameters the implicit message is that the QNI
would be satisfied by a reservation with lower parameter values than
specified in QoS Desired. For these parameters, the QNI seeds the
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 31]
Internet Draft QoS-NSLP QSPEC Template July 2005
parameter values in QoS Available to those in QoS Desired (except for
cumulative parameters such as <path latency>).
Each QNE adapts the parameters in QoS Available according to its
current capabilities. Reservations in each QNE are hence based on
current parameter values in QoS Available (and additionally those
parameters that only appear in QoS Desired). The drawback of this
approach is that, if the resulting resource reservation becomes
gradually smaller towards the QNR, QNEs close to the QNI have an
oversized reservation, possibly resulting in unnecessary costs for
the user. Of course, in the RESPONSE the QNI learns what the actual
reservation is (from the QoS RESERVED object) and can immediately
issue a properly sized refreshing RESERVE. The advantage of the
approach is that the reservation is performed in half-a-roundtrip
time.
The parameter types included in QoS Reserved in RESPONSE must be the
same as those in QoS Desired in RESERVE. For those parameters that
were also included in QoS Available in RESERVE, their value is copied
into QoS Desired. For the other parameters, the value is copied from
QoS Desired (the reservation would fail if the corresponding QoS
could not be reserved).
The parameters in the QoS Available QSPEC object in the RESPONSE are
copied with their values from the QoS Available QSPEC object in the
RESERVE. Note that the parameters in QoS Available are read-write
in the RESERVE message, whereas they are read-only in the RESPONSE.
c.) this case is handled as case (b), except that the reservation
fails when QoS Available becomes less than Minimum QoS for one
parameter. If a parameter appears in QoS Available but not in
Minimum QoS it is assumed that the minimum value for this parameter
is that given in QoS Available.
7.1.2 Receiver-Initiated Reservations
Here the QNR issues a QUERY which is replied to by the QNI with a
RESERVE if the reservation was successful. The QNR in turn sends a
RESPONSE to the QNI.
QUERY | RESERVE | RESPONSE
---------------------------------------------------------------------
a. QoS Des. | QoS Des. | QoS Res.
b. QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl.
c. QoS Avail. | QoS Des. | QoS Res.
a.) and b.) The idea is that the sender (QNR in this scenario) needs
to inform the receiver (QNI in this scenario) about the QoS it
desires. To this end the sender sends a QUERY message to the
receiver including a QoS Desired QSPEC object. If the QoS is
negotiable it additionally includes a (possibly zero) Minimum QoS, as
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 32]
Internet Draft QoS-NSLP QSPEC Template July 2005
in Case b.
The RESERVE message includes QoS Available if the sender signaled QoS
is negotiable (i.e. it included Minimum QoS). If the Minimum QoS
received from the sender is non-zero, the QNR also includes Minimum
QoS.
c. This is the "RSVP-style" scenario. The sender (QNR) issues a QUERY
with QoS Available to collect path properties, and the QoS Desired in
the RESERVE issued by the receiver (QNI) is populated from the
parameter values in QoS Available from the QUERY message. The
advantage of this model is that the situation of over-reservation in
QNEs close to the QNI as described above does not occur. On the
other hand, the QUERY may find, for example, a particular bandwidth
is not available. When the actual reservation is performed, however,
the desired bandwidth may meanwhile have become free. That is, the
'RSVP style' may result in a smaller reservation than necessary.
7.1.3 Resource Queries
Here the QNI issues a QUERY in order to investigate what resources
are currently available. The QNR replies with a RESPONSE.
QUERY | RESPONSE
--------------------------------------------
QoS Available | QoS Available
Note QoS Available when traveling in the QUERY is read-write, whereas
in the RESPONSE it is read-only.
7.1.4 Bidirectional Reservations
On a QSPEC level, bidirectional reservations are no different from
uni-directional reservations, since QSPECs for different directions
never travel in the same message.
7.1.5 Setting Optional Parameter Flags
An optional parameter is always accompanied by an optional parameter
flag in all objects. For example, if the QNI populates an optional
parameter in QoS Desired, it MUST also populate the optional
parameter flag in <QoS Available>. Hence, if a QNE wants to check
for support of optional parameters, it MUST include a <QoS Available>
object and the optional parameter flags are only in that object. If
a QNE does not support the optional parameter, it MUST set the
optional parameter flag in the QoS Available object. Optional
parameter flags SHOULD only travel in the <QoS Available> object, and
are generally not included in the QoS Desired, Minimum QoS and QoS
Reserved objects.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 33]
Internet Draft QoS-NSLP QSPEC Template July 2005
7.2 QSPEC Examples
This Section provides an example QSPEC for DiffServ admission
control. The QSPEC for IntServ controlled load service is
specified in [INTSERV-QOSM] (note that the QOSMs for IntServ
Controlled Load Service and IntServ Guaranteed Service are defined in
[RFC2211] and [RFC2212], respectively).
The QSPEC for DiffServ admission control may be composed, for
example, of the QSPEC objects <QoS Desired> and <QoS Available>, as
well as <QoS Reserved>. Which QSPEC object is present in a
particular QSPEC depends on the message type (RESERVE, QUERY etc) in
which the QSPEC travels. Parameters in the QSPEC for DiffServ
requesting bandwidth for different PHBs are as follows:
Example QSPEC for the DiffServ EF PHB [RFC3297]:
<QSPEC Control Information> = <Excess Treatment>
<QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
<QoS Desired> = <Traffic Description> <QoS Class>
<Traffic Description> = <Token Bucket>
<QoS class> = <PHB Class=EF>
<QoS Available> = <Token Bucket>
<QoS Reserved> = <Token Bucket>
In general, the EF PHB is a property of the service that is NOT
dependent on the input traffic characteristics. A server of rate R
and latency E that is compliant with the EF PHB must deliver at least
the configured service rate R with at most latency E for any traffic
characterization. Therefore, strictly speaking, there is no specific
traffic descriptor required to deliver the EF PHB (which by
definition is a local per-hop characterization). However, in order
to deliver a reasonable end-to-end delay, it is typically assumed
that EF traffic is shaped at the ingress. A typical assumption is
that input traffic at any ingress is constrained by a single rate
token bucket. Therefore, a single rate token bucket is sufficient
to signal in QoS-NSLP/QSPEC for the DiffServ-QOSM.
Example QSPEC for the DiffServ AFxy PHB [RFC2597]:
<QSPEC Control Information> = <Excess Treatment>
<QoS Description> = <QoS Desired> <QoS Available> <QoS Reserved>
<QoS Desired> = <Traffic Description> <QoS Class>
<Traffic Description> = <Committed Burst Size (CBS) Token Bucket>
<Excess Burst Size (EBS) Token Bucket>
<QoS class> = <PHB Class=AFxy>
<QoS Available> = <CBS Token Bucket> <EBS Token Bucket>
<QoS Reserved> = <CBS Token Bucket> <EBS Token Bucket>
QNEs process two sets of token bucket parameters to implement the
DiffServ AF QOSM, one token bucket for the average (CBS) traffic and
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 34]
Internet Draft QoS-NSLP QSPEC Template July 2005
one token bucket for the burst (EBS) traffic. These 2 token buckets
are sufficient to cover most of the ways in which one would
distinguish among 3 levels of drop precedence at the queuing
mechanics level, as described in the Appendix to [RFC2597].
QoS-NSLP/QSPEC can support signaling the parameters required for the
DiffServ marker elements described in [RFC2697] and [RFC2698].
[RFC2697] defines a Single Rate Three Color Marker (srTCM), which
can be used as component in a DiffServ traffic conditioner [RFC2475,
RFC2474]. The srTCM meters a traffic stream and marks its packets
according to three traffic parameters, Committed Information Rate
(CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be
either green, yellow, or red. A packet is marked green if it does
not exceed the CBS, yellow if it does exceed the CBS, but not the
EBS, and red otherwise.
RFC 2697 and RFC 2698 provide specific procedures, where in essence,
RFC 2697 is using two token buckets that run at the same rate.
8. Security Considerations
The priority parameter raises possibilities for Theft of Service
Attacks because users could claim an emergency priority for their
flows without real need, thereby effectively preventing serious
emergency calls to get through. Several options exist for countering
such attacks, for example
- only some user groups (e.g. the police) are authorized to set the
emergency priority bit
- any user is authorized to employ the emergency priority bit for
particular destination addresses (e.g. police)
9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].
[QoS-SIG] requires IANA to create a new registry for QoS Signaling
Model Identifiers. The QoS Signaling Model Identifier (QOSM ID) is
a 4 byte value carried in a QSPEC. The allocation policy for
new QOSM IDs is TBD.
This document also defines 53 objects and parameters for the QSPEC
Template, as detailed in Section 6. Values are to be assigned for
them from the NTLP Object Type registry.
10. Acknowledgements
The authors would like to thank (in alphabetical order) David Black,
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 35]
Internet Draft QoS-NSLP QSPEC Template July 2005
Anna Charny, Xiaoming Fu, Robert Hancock, Chris Lang, Dave Oran, Tom
Phelan, Hannes Tschofenig, and Sven van den Bosch, for their very
helpful suggestions.
11. Normative References
[DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry
[PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes
[QoS-SIG] S. Van den Bosch et. al., "NSLP for Quality-of-Service
Signaling," work in progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] B. Braden et. al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification," RFC 2205, September 1997.
[RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2211] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC 2211, Sept. 1997.
[RFC2212} Shenker, S., et. al., "Specification of Guaranteed Quality
of Service," September 1997.
[RFC2215] S. Shenker and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215, Sept.
1997.
[RFC2474] Nichols, K., et. al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474,
December 1998.
[RFC2475] S. Blake et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] J. Heinanen, et. al., "Assured Forwarding PHB Group," RFC
2597, June 1999.
[RFC2697] J. Heinanen, R. Guerin, "A Single Rate Three Color Marker,"
RFC 2697, September 1999.
[RFC2698] J. Heinanen, R. Guerin, "A Two Rate Three Color Marker,"
RFC 2698, September 1999.
[RFC3297] A. Charny, et. al., "Supplemental Information for the New
Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior),"
RFC 3297, March 2002.
12. Informative References
[CMSS] "PacketCable (TM) CMS to CMS Signaling Specification,
PKT-SP-CMSS-103-040402, April 2004.
[DIFFSERV-CLASS] Baker, F., et. al., "Configuration Guidelines
for DiffServ Service Classes," work in progress.
[INTSERV-QOSM] C. Kappler, "A QoS Model for Signaling IntServ
Controlled-Load Service with NSIS," work in progress.
[PRIORITY-RQMTS] Tarapore, P., et. al., "User Plane Priority Levels
for IP Networks and Services," T1A1/2003-196 R3, November 2004.
[Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling
Protocol - Capability Set 3" Sep. 2003
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 36]
Internet Draft QoS-NSLP QSPEC Template July 2005
[RFC1633] B. Braden et. al., "Integrated Services in the Internet
Architecture: an Overview," RFC 1633, June 1994.
[RFC3393] C. Demichelis, P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002.
[RFC3564] F. Le Faucheur et. al., Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering, RFC 3564,
July 2003
[RFC3726] M. Brunner et. al., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RMD-QOSM] A. Bader, et. al., " RMD-QOSM: An NSIS QoS Signaling
Policy Model for Networks
Using Resource Management in DiffServ (RMD)," work in progress.
[SIP-PRIORITY] H. Schulzrinne, J. Polk, "Communications Resource
Priority for the Session Initiation Protocol(SIP)." work in
progress.
[VERTICAL-INTERFACE] M. Dolly, P. S. Tarapore, S. Sayers,
"Discussion on Associating of Control Signaling Messages with Media
Priority Levels," T1S1.7 & PRQC, October 2004.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
for IP-Based Services," May 2002.
[Y.1541-QOSM] J. Ash, et. al., "Y.1541-QOSM -- Y.1541 QoS Model for
Networks Using Y.1541 QoS Classes," work in progress.
13. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
Attila Bader
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc u. 1 H-1037
Budapest Hungary
EMail: Attila.Bader@ericsson.com
Chuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Phone: + 1 973-236-6700
Fax:+1 973-236-7453
E-mail: cdvorak@att.com
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 37]
Internet Draft QoS-NSLP QSPEC Template July 2005
Yacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex
FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Email: cornelia.kappler@siemens.com
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
Andrew McDonald
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
EMail: andrew.mcdonald@roke.co.uk
Al Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-1571
Fax: +.1 732 368-1192
E-mail: acmorton@att.com
Percy Tarapore
AT&T
Room D1-3D33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4172
E-mail: tarapore@.att.com
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
EMail: Lars.Westberg@ericsson.com
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 38]
Internet Draft QoS-NSLP QSPEC Template July 2005
Appendix A: QoS Models and QSPECs
This Appendix gives a description of QoS Models and QSPECs and
explains what is the relation between them. Once these descriptions
are contained in a stable form in the appropriate IDs this Appendix
will be removed.
QoS NSLP is a generic QoS signaling protocol that can signal for many
QOSMs. A QOSM is a particular QoS provisioning method or QoS
architecture such as IntServ Controlled Load or Guaranteed Service,
DiffServ, or RMD for DiffServ.
The definition of the QOSM is independent from the definition of QoS
NSLP. Existing QOSMs do not specify how to use QoS NSLP to signal
for them. Therefore, we need to define the QOSM specific signaling
functions, as [RMD-QOSM], [INTSERV-QOSM], and [Y.1541-QOSM].
A QOSM SHOULD include the following information:
- Role of QNEs in this QOSM:
E.g. location, frequency, statefulness...
- QSPEC Definition:
A QOSM SHOULD specify the QSPEC, including QSPEC parameters.
Furthermore it needs to explain how QSPEC parameters not used in this
QOSM are mapped onto parameters defined therein.
- Message Format
QSPEC objects to be carried in RESERVE, QUERY RESPONSE and NOTIFY
- State Management
It describes how QSPEC info is treated and interpreted in the
RMF and QOSM specific processing. E.g.
admission control, scheduling, policy control, QoS parameter
accumulation (e.g. delay).
- Operation and Sequence of Events
Usage of QoS-NSLP messages to signal the QOSM.
Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved of
NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ
The union of QoS Desired, QoS Available and QoS Reserved can provide
all functionality of the objects specified in RSVP IntServ, however
it is difficult to provide an exact mapping.
In RSVP, the Sender TSpec specifies the traffic an application is
going to send (e.g. token bucket). The AdSpec can collect path
characteristics (e.g. delay). Both are issued by the sender. The
receiver sends the FlowSpec which includes a Receiver TSpec
describing the resources reserved using the same parameters as the
Sender TSpec, as well as a RSpec which provides additional IntServ
QoS Model specific parameters, e.g. Rate and Slack.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 39]
Internet Draft QoS-NSLP QSPEC Template July 2005
The RSVP TSpec/AdSpec/RSpec seem quite tailored to receiver-initiated
signaling employed by RSVP, and the IntServ QoS Model. E.g. to the
knowledge of the authors it is not possible for the sender to specify
a desired maximum delay except implicitly and mutably by seeding the
AdSpec accordingly. Likewise, the RSpec is only meaningfully sent in
the receiver-issued RSVP RESERVE message. For this reason our
discussion at this point leads us to a slightly different mapping of
necessary functionality to objects, which should result in more
flexible signaling models.
Appendix C: Main Changes Since Last Version & Open Issues
C.1 Main Changes Since Version -04
- fixed <QOSM hops> in Sec. 5 and 6.2 as discussed at Interim Meeting
- discarded QSPEC parameter <M> (Maximum packet size) since MTU
discovery is expected to be handled by procedure currently defined
by PMTUD WG
- added "container QSPEC parameter" in Sec. 6.1 to augment encoding
efficiency
- added the 'tunneled QSPEC parameter flag' to Sections 5 and 6
- revised Section 6.2.2 on SIP priorities
- added QSPEC procedures for "RSVP-style reservation", resource
queries and bidirectional reservations in Sec. 7.1
- reworked Section 7.2
C.2 Open Issues
- include error handling
- have coding checked by independent expert
- coding of QSPEC Procedure ID
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 40]
Internet Draft QoS-NSLP QSPEC Template July 2005
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Ash, et. al. <draft-ietf-nsis-qspec-05.txt> [Page 41]
| PAFTECH AB 2003-2026 | 2026-04-22 17:41:40 |