One document matched: draft-ietf-nsis-qspec-10.txt
Differences from draft-ietf-nsis-qspec-09.txt
IETF Internet Draft NSIS Working Group Jerry Ash
Internet Draft AT&T
<draft-ietf-nsis-qspec-10.txt> Attila Bader
Expiration Date: December 2006 Ericsson
Cornelia Kappler
Siemens AG
June 2006
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 December 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 document 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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 1]
Internet Draft QoS-NSLP QSPEC Template June 2006
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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. QSPEC Parameters, Processing, & Extensibility . . . . . . . . . 7
4.1 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 7
4.2 QSPEC Processing . . . . . . . . . . . . . . . . . . . . . 8
4.3 Example of NSLP/QSPEC Operation . . . . . . . . . . . . . . 10
4.4 Treatment of QSPEC Parameters . . . . . . . . . . . . . . . 14
4.4.1 Mandatory and Optional QSPEC Parameters . . . . . . . 14
4.4.2 Read-only and Read-write QSPEC Parameters . . . . . . 15
4.5 Reservation Success/Failure, QSPEC Errors, & INFO_SPEC
Notification . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.1 Reservation Failure and Error E-Flag . . . . . . . . 16
4.5.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 17
4.5.3 QSPEC Tunneled Parameter T-Flag . . . . . . . . . . . 17
4.5.4 INFO_SPEC coding of reservation outcome . . . . . . . 17
4.5.5 QNE Generation of a RESPONSE message . . . . . . . . 18
4.5.6 Special Cases of QSPEC Stacking . . . . . . . . . . . 19
4.6 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 19
4.7 QOSM Specification Requirements . . . . . . . . . . . . . . 20
5. QSPEC Format Overview . . . . . . . . . . . . . . . . . . . . . 20
5.1 QSPEC Control Information . . . . . . . . . . . . . . . . . 21
5.2 QoS Description . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 <QoS Desired> . . . . . . . . . . . . . . . . . . . . 22
5.2.2 <QoS Available> . . . . . . . . . . . . . . . . . . . 23
5.2.3 <QoS Reserved> . . . . . . . . . . . . . . . . . . . 25
5.2.4 <Minimum QoS> . . . . . . . . . . . . . . . . . . . . 26
6. QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Sender-Initiated Reservations . . . . . . . . . . . . . . . 26
6.2 Receiver-Initiated Reservations . . . . . . . . . . . . . . 28
6.3 Resource Queries . . . . . . . . . . . . . . . . . . . . . 29
6.4 Bidirectional Reservations . . . . . . . . . . . . . . . . 30
6.5 Preemption . . . . . . . . . . . . . . . . . . . . . 30
7. QSPEC Functional Specification . . . . . . . . . . . . . . . . 30
7.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 30
7.2 Parameter Coding . . . . . . . . . . . . . . . . . . . . . 33
7.2.1 <NON QOSM Hop> Parameter . . . . . . . . . . . . . . 33
7.2.2 <Excess Treatment> Parameter . . . . . . . . . . . . 34
7.2.3 <Bandwidth> . . . . . . . . . . . . . . . . . . . . . 35
7.2.4 <Slack Term> Parameter . . . . . . . . . . . . . . . 35
7.2.5 <Token Bucket> Parameters . . . . . . . . . . . . . . 35
7.2.6 <QoS Class> Parameters . . . . . . . . . . . . . . . 37
7.2.6.1 <PHB Class> Parameter . . . . . . . . . . . . 37
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 2]
Internet Draft QoS-NSLP QSPEC Template June 2006
7.2.6.2 <Y.1541 QoS Class> Parameter . . . . . . . . 37
7.2.6.3 <DSTE Class Type> Parameter . . . . . . . . . 38
7.2.7 Priority Parameters . . . . . . . . . . . . . . . . . 38
7.2.7.1 <Preemption Priority> & <Defending Priority>
Parameters . . . . . . . . . . . . . . . . . 38
7.2.7.2 <Admission Priority> Parameter . . . . . . . 39
7.2.7.3 <RPH Priority> Parameter . . . . . . . . . . 39
7.2.8 <Path Latency> Parameter . . . . . . . . . . . . . . 41
7.2.9 <Path Jitter> Parameter . . . . . . . . . . . . . . . 41
7.2.10 <Path PLR> Parameter . . . . . . . . . . . . . . . . 42
7.2.11 <Path PER> Parameter . . . . . . . . . . . . . . . . 43
7.2.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
11. Normative References . . . . . . . . . . . . . . . . . . . . . 48
12. Informative References . . . . . . . . . . . . . . . . . . . . 48
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49
Appendix A: QoS Models and QSPECs . . . . . . . . . . . . . . . . 50
Appendix B: Mapping of QoS Desired, QoS Available and QoS Reserved
of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 50
Appendix C: Main Changes Since Last Version & Open Issues . . . . 51
C.1 Main Changes Since Version -04 . . . . . . . . . . 51
C.2 Open Issues . . . . . . . . . . . . . . . . . . . 52
Intellectual Property Statement . . . . . . . . . . . . . . . . . 52
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 53
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 53
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].
1. Contributors
This document is the result of the NSIS Working Group effort. In
addition to the authors/editors listed in Section 13, the following
people contributed to the document:
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
Email: cdvorak@att.com
Yacine El Mghazli
Alcatel
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 3]
Internet Draft QoS-NSLP QSPEC Template June 2006
Route de Nozay
91460 Marcoussis cedex
FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
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
Email: acmorton@att.com
Percy Tarapore
AT&T
Room D1-33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4172
Email: tarapore@.att.com
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
Email: Lars.Westberg@ericsson.com
2. Introduction
The QoS NSIS signaling layer protocol (NSLP) [QoS-SIG] establishes
and maintains state at nodes along the path of a data flow for the
purpose of providing forwarding resources (QoS) for that flow. The
design of QoS NSLP is conceptually similar to RSVP [RFC2205], and
meets the requirements of [RFC3726].
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 4]
Internet Draft QoS-NSLP QSPEC Template June 2006
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) defined in [QoS-SIG],
including inputs and outputs.
The QoS NSLP protocol is used to signal QoS reservations and supports
signaling for different QOSMs, such as for IntServ, DiffServ
admission control, and those specified in [Y.1541-QOSM, INTSERV-QOSM,
RMD-QOSM]. All information specific to a QOSM is encapsulated in
the QoS specification (QSPEC) object, which is QOSM specific, and
this document defines a template for the QSPEC. A particular QOSM
specifies a) a set of mandatory and optional QSPEC parameters, and
b) how the QSPEC information is interpreted by the RMF with respect
to the QoS description, resources desired, resources available, and
control information.
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 behavior of the RMF. An example of QSPEC
control information is how the excess traffic is treated in the RMF
queuing functions. The QoS description parameters include, for
example, traffic description parameters, such as <Token Bucket> and
<Bandwidth>, and constraints parameters, such as <PHB Class> and
<Path Latency>.
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
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. The QSPEC travels in QoS NSLP messages but is
opaque to the QoS NSLP, and is only interpreted by the RMF.
Interoperability between QoS NSIS entities (QNEs) in different
domains that implement different QOSMs is enhanced (but not
guaranteed) by the definition of a common set of mandatory and
optional QSPEC parameters. Mandatory parameters in the QSPEC must be
meaningfully interpreted by all QNEs in the path, independent of
which QOSM they support. This way, NSIS provides a mechanism for
interdomain QoS signaling and interworking. Optional QSPEC
parameters, in contrast, may be skipped if not understood.
Additional optional parameters can be defined by all QOSMs, thereby
ensure the extensibility and flexibility of QoS NSLP.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 5]
Internet Draft QoS-NSLP QSPEC Template June 2006
A QoS NSIS initiator (QNI) initiating the QoS NSLP signaling adds an
initiator QSPEC object containing parameters describing the desired
QoS based on the QOSM it supports. A local QSPEC can be stacked on
the initiator QSPEC to accommodate different QOSMs being used in
different domains. A domain supporting a different local QOSM than
the QNI can interpret the initiator QSPEC and stack a local QSPEC
to meet the local QOSM requirements. If the local domain cannot
fully interpret the initiator QSPEC, it can flag the condition and
either continue to forward the reservation or possibly reject the
reservation.
Thus, 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. The ability to achieve end-to-end QoS through multiple
Internet domains is also an important requirement, and illustrated
in this document.
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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 6]
Internet Draft QoS-NSLP QSPEC Template June 2006
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.
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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 7]
Internet Draft QoS-NSLP QSPEC Template June 2006
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.
As defined in Section 4.6, additional optional QSPEC parameters can
be defined in separate Informational documents specific to a given
QOSM. For example, optional QSPEC parameters are defined in
[RMD-QOSM] and [Y.1541-QOSM].
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 QNE MUST support at least one QOSM. A QoS-enabled domain supports
a particular QOSM, e.g. DiffServ admission control. If this domain
supports QoS NSLP signaling, its QNEs MUST support the DiffServ
admission control QOSM. The QNEs MAY also support additional QOSMs.
The QSPEC contains a QOSM ID, i.e. information on what QOSM is being
signaled by the QNI. However, if a QSPEC arrives at a QNE that does
not support the QOSM being signaled, it can still understand the
QSPEC content, at least to a basic degree. This is because mandatory
parameters have been defined as a common language. Therefore, a QNE
MUST at least interpret all the mandatory parameters in a QSPEC even
if it does not support the corresponding QOSM.
Mandatory parameters provide a minimal subset of parameters. A
QNE MUST either a) strictly interpret a mandatory parameter, or
b) remap the parameter and raise the <NON QOSM HOP> flag defined in
Section 5.1, where the remapping MUST be specified in the QOSM
specification. Here the terminology 'strictly interpret' means that
the parameter is implemented according to the commonly accepted
definition and/or as specified by references given for each QSPEC
parameter. This means that in case a), a <Token Bucket> parameter
must be strictly interpreted as a token bucket. However, in case b),
a <token Bucket> parameter may be remapped, perhaps to a <Bandwidth>
parameter.
In the latter case, the remapping of the <Token Bucket> to
<Bandwidth> must be specified in the QOSM specification document.
For example, QOSM X exclusively uses the parameter <Bandwidth>. It
must define a mapping of the mandatory parameter <Token Bucket>.
The mapping consists of interpreting the Token Bucket Rate as
the <Bandwidth> parameter and disregarding the other Token Bucket
parameters. Clearly, some information contained in the <Token
Bucket> parameter is lost by this mapping, and the resulting QoS may
not be quite what was intended by the QNI. Therefore, QOSM X also
specifies that the <NON QOSM HOP> flag be raised. Thus, a QNE using
QOSM X is able to make an informed decision whether to admit a
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 8]
Internet Draft QoS-NSLP QSPEC Template June 2006
reservation described in terms of <Token Bucket>, and at the same
time (by means of <NON QOSM HOP>) signals to the QNI/QNR that the
exact intention of the QNI may not be met.
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.
When reserving resources with a RESERVE message, a local QSPEC MAY be
pushed on the stack at the ingress edge of a local QoS domain, 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. When a RESPONSE message corresponding
to the RESERVE message arrives on its way back at the egress edge, a
local QSPEC MUST again be generated, describing the reserved
resources in a domain-specific manner. This local QSPEC is popped
from the stack at the ingress edge.
A domain supporting a different local QOSM than the initiator (QNI)
domain inspects all mandatory parameters and consults its local QOSM
as to how to interpret these parameters and decides whether it can
accommodate the flow. This analysis can have these various outcomes:
a) RMF determines that it can accommodate the flow with the QoS
Desired specified by the QNI, b) RMF determines that some Initiator
QSPEC parameters cannot be satisfied with the available resources,
and marks the appropriate error flags (see Section 4.5), but does not
reject the reservation, or c) RMF determines that some Initiator
QSPEC parameters cannot be satisfied with the available resources,
marks the appropriate error flags (see Section 4.5), and also rejects
the reservation. The QNE also in any event sets the <NON QOSM HOP>
flag, as described in Section 5.1.
When a reservation is successful, the information is passed from the
RMF to QoS NSLP processing and translated into the QoS NSLP INFO_SPEC
code class 'success' [QoS-SIG].
This document 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-10.txt> [Page 9]
Internet Draft QoS-NSLP QSPEC Template June 2006
+-------------+---------------------------------------+
|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-10.txt> [Page 10]
Internet Draft QoS-NSLP QSPEC Template June 2006
+----------+ /-------\ /--------\ /--------\
| 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 signal an Initiator QSPEC object to achieve the QoS
desired on the path. As stated in Section 4.2, the QNI MUST support
at least one QOSM, but it may not know the QOSM supported by the
network. In any case, if the QNI supports only one QOSM, it would
normally signal a reservation according to the requirements of that
QOSM. Furthermore, the QNI would most likely support the QOSM that
matches its functionality. For example, the default QOSM for mobile
phones might be the XG-QOSM, while the INTSERV-QOSM might be the
default for workstations.
Referring to Figure 3, the laptop computer may choose the
INTSERV-QOSM because it is connected to a wired network. If the
handheld device acts as the QNI, it may choose the XG-QOSM because it
is connected to the XG wireless network. On the other hand, a
particular QOSM could be configured if a user/administrator knows
that some particular QOSM is used. For example, if the laptop
computer is connected to the XG network via the XG phone, which acts
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 11]
Internet Draft QoS-NSLP QSPEC Template June 2006
as a modem, then it reasonable to specify the XG-QOSM since resources
are accessed through the XG network,
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
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 signals 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
consistent with the QOSM it is signaling and any additional
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
signaled 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.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 12]
Internet Draft QoS-NSLP QSPEC Template June 2006
There are three possibilities when a RESERVE message is received at a
QNE at a domain border (we illustrate these possibilities in the
example):
- the QNE just leaves the QSPEC as-is.
- 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
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 the parameter-specific, 'not-supported' flag,
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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 13]
Internet Draft QoS-NSLP QSPEC Template June 2006
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 includes 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
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].
For bit-level examples of QSPECs see the documents specifying QOSMs
[INTSERV-QOSM, Y.1541-QOSM, RMD-QOSM].
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 signaled.
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 signaled and
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 14]
Internet Draft QoS-NSLP QSPEC Template June 2006
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).
Note that the QNI referred to above can be an ingress QNE in a local
domain initiating a local QSPEC object.
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 Reservation Success/Failure, QSPEC Errors, & INFO_SPEC Notification
A reservation may not be successful for several reasons:
- a reservation may fail because the desired resources are not
available. This is a reservation failure condition.
- a reservation may fail because the QSPEC is erroneous, or because
of a QNE fault. This is an error condition.
A reservation may be successful, but still some parameters could not
be interpreted or updated properly:
- a QSPEC parameter cannot be interpreted because it is an unknown
optional parameter type. This is a QSPEC parameter not supported
condition. The reservation however does not fail. The QNI can
still decide whether to keep or tear down the reservation depending
on the procedures specified by the QNI's QOSM.
- a QSPEC parameter value in the <QoS Available> object cannot be
updated because QoS NSLP was tunneled to the QNE. This is a
QSPEC tunneled parameter condition. The reservation however does
not fail. As above, the QNI can still decide whether to keep or
tear down the reservation.
The following sections describe the handling of unsuccessful
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 15]
Internet Draft QoS-NSLP QSPEC Template June 2006
reservations in more detail, as follows:
- details on flags used inside the QSPEC to convey information on
success or failure of individual parameters. The formats and
semantics of all flags are given in Section 6.1.
- the content of the INFO_SPEC [QoS-SIG], which carries a code
indicating the outcome of reservations.
- the generation of a RESPONSE message to the QNI containing both
QSPEC and INFO_SPEC objects.
4.5.1 Reservation Failure and Error E-Flag
The QSPEC parameters each have a 'reservation failure error E-flag'
to indicate which (if any) parameters could not be satisfied. When a
resource cannot be satisfied for a particular parameter, the QNE
detecting the problem raises the E-flag in this parameter. Note that
all QSPEC parameters MUST be examined by the RMF and appropriately
flagged. Additionally, the E-flag in the corresponding QSPEC Object
MUST be raised. If the reservation failure problem cannot be located
at the parameter level, only the E-flag in the QSPEC object is
raised.
A QNE detecting that some QSPEC parameters have to be remapped and
possibly downgraded MUST set the <NON QOSM Hop> flag. This condition
might occur, for example, when a QNE's QOSM is different that the
QNI's QOSM, and the QNE's QOSM specifies that some parameters are
Remapped and not strictly interpreted (see the example in Section 4.3
for an illustration of this condition). In this case no E-Flags are
set and the message should continue to be forwarded but with the
<NON QOSM Hop> flag set, and the QNI has the option of not accepting
the reservation.
When an RMF cannot interpret the QSPEC because the coding is
erroneous, it raises corresponding reservation failure E-flags in the
QSPEC. Normally all QSPEC parameters MUST be examined by the RMF
and the erroneous parameters appropriately flagged. In some cases,
however, an error condition may occur and the E-flag of the
error-causing QSPEC parameter is raised (if possible), but the
processing of further parameters may be aborted.
Note that if the QSPEC and/or any QSPEC parameter is found to be
erroneous, then any QSPEC parameters not satisfied are ignored and
the E-Flags in the QSPEC object MUST NOT be set for those parameters
(unless they are erroneous).
Whether E-flags denote reservation failure or error can be determined
by the corresponding error code in the INFO_SPEC in QoS NSLP, as
discussed below.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 16]
Internet Draft QoS-NSLP QSPEC Template June 2006
4.5.2 QSPEC Parameter Not Supported N-Flag
When the QOSM ID is not known to a QNE, it MUST interpret at least
the mandatory parameters.
Each optional QSPEC parameter has an associated 'not supported
N-flag'. If the not supported N-flag is set, then at least one QNE
along the data transmission path between the QNI and QNR cannot
support or interpret the specified optional parameter. A QNE MUST
set the not supported N-flag if it does not support or cannot
interpret the optional parameter, and therefore cannot be sure it can
provide the resources. In that case the message should continue to
be forwarded but with the N-flag set, and the QNI has the option of
not accepting the reservation.
4.5.3 QSPEC Tunneled Parameter T-Flag
Each QSPEC parameter has an associated 'tunneled-parameter T-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 a) it is configured to have the
knowledge to update the parameters correctly, or b) it cannot update
the parameters. In the latter case it MUST set the
tunneled-parameter T-flag to tell the QNI (or QNR) that the
information contained in the read-write parameter is most likely
incorrect (or a lower bound). The T-flag is interpreted by the QNI,
ingress QNE (start of tunnel in a domain), egress QNE (end of tunnel
in a domain), or QNR.
4.5.4 INFO_SPEC coding of reservation outcome
As prescribed by [QoS-SIG], the RESPONSE message always contains the
INFO_SPEC with an appropriate "error" code. It usually also contains
a QSPEC with QSPEC objects, as described in Section 6 on QoS
Procedures. The RESPONSE message MAY omit the QSPEC in case of a
successful reservation.
The following guidelines are provided in setting the error codes in
the INFO_SPEC, based on the codes provided in Section 5.1.3.6 of
[QoS-SIG].
- INFO_SPEC error class 0x02 (Success) / 0x01 (Reservation Success)
This code is set when all QSPEC parameters have been satisfied
(possibly with downgrading). In this case no E-Flag nor the
<NON QOSM Hop> flag is set, however N-flags or T-flags may be set.
This code is also set when one or more mandatory parameters had to
be remapped, as indicated by a <NON QOSM Hop> flag being set.
- INFO_SPEC error class 0x04 (Transient Failure) / 0x08 (Reservation
Failure)
This code is set when at least one parameter could not be
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 17]
Internet Draft QoS-NSLP QSPEC Template June 2006
satisfied. E-flags are set for the parameters that could not be
satisfied up to the QNE issuing the RESPONSE. In this case QNEs
receiving the RESPONSE message MUST remove the corresponding
reservation.
- INFO_SPEC error class 0x03 (Protocol Error)/ 0x0c (Malformed QSPEC)
Some QSPEC parameters had associated errors, E-Flags are set for
parameters that had errors, and the RMF rejects the reservation.
- INFO_SPEC error class 0x06 (QoS Model Error)
QOSM error codes can be defined for future releases of this
document or as defined by QOSM-specific specification documents. A
registry is defined in Section 9 IANA Considerations.
4.5.5 QNE Generation of a RESPONSE message
- Successful Reservation Condition
When a RESERVE message arrives at a QNR and no E-Flag is set, the
reservation is successful. A RESPONSE may be generated with
INFO_SPEC code 'Reservation Success' as described above and QSPEC as
described in Section 6.
A raised <NON QOSM Hop> flag in the QSPEC of the RESERVE message
indicates that at least one mandatory parameter may have been
remapped. The <NON QOSM Hop> flag is sent back in the RESPONSE
message and the QNI then makes the final determination as to
whether to continue or tear down the reservation that has been
established. A QOSM specification MAY specify the conditions for
rejecting a reservation under such conditions. However, in the
absence of such procedures, the default condition SHOULD be
'success' if all QSPEC parameters are met and 'reservation failure'
if one or more QSPEC parameters are not met.
- Reservation Failure Condition
When a QNE detects that a reservation failure occurs for at least one
parameter, the QNE sets the E-Flags for the QSPEC parameters and
QSPEC object that failed to be satisfied. According to [QoS-SIG],
the QNE behavior depends on whether it is stateful or not. When a
stateful QNE determines the reservation failed, it formulates a
RESPONSE message that includes an INFO_SPEC with the 'reservation
failure' error code and QSPEC object, as described above. The QSPEC
in the RESPONSE message includes the QSPEC <QoS Reserved> object with
all parameters values set to zero (or equivalent). Furthermore, the
E-Flags of all QSPEC parameters are transferred with their values
from <QoS Desired>, which arrived in the QSPEC of the corresponding
RESERVE message. The <QoS Available> object can still be used to
transfer information about available QoS to the QNI.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 18]
Internet Draft QoS-NSLP QSPEC Template June 2006
The default action for a stateless QoS NSLP QNE that detects a
reservation failure condition is that it MUST continue to forward the
RESERVE message to the next stateful QNE, with the E-Flags
appropriately set for each QSPEC parameter. The next stateful QNE
will then act as described in [QoS-SIG].
- Malformed QSPEC Error Condition
When a stateful QNE detects that one or more QSPEC parameters are
erroneous, the QNE sets the error code 'malformed QSPEC' in the
INFO_SPEC, as described above. In this case the QSPEC object with
the E-Flags appropriately set for the erroneous parameters is
returned within the INFO_SPEC object. The QSPEC object can be
truncated or fully included within the INFO_SPEC.
The default action for a stateless QoS NSLP QNE that detects such an
error condition is that none of the QSPEC parameters SHOULD be
processed and the RESERVE message SHOULD be forwarded downstream.
A 'malformed QSPEC' error code takes precedence over the 'reservation
failure' error code, and therefore the case of reservation failure
and QSPEC/RMF error conditions are disjoint and the same E-Flag can
be used in both cases without ambiguity.
4.5.6 Special Cases of QSPEC Stacking
When an unsuccessful reservation problem occurs inside a local domain
where QSPEC stacking is used, only the topmost (local) QSPEC is
affected (e.g. E-flags are raised, etc.). The Initiator QSPEC at the
bottom is untouched. When the message (RESPONSE in case of stateful
QNEs, RESERVE in case of stateless QNEs) however reaches the edge of
the stacking domain, the local QSPEC is popped, and its content,
including flags, is translated into the Initiator QSPEC.
4.6 QSPEC Extensibility
This document defines both mandatory and optional parameters. The
set of mandatory parameters defined herein is at this point in time
considered complete. The optional parameters in this document
correspond to some of the optional parameters considered in QOSMs
currently being defined.
Additional mandatory parameters may be defined in the future.
However, since this requires an update of all QNEs, this should be
considered carefully. The definition of new mandatory parameter
requires standards action and an update of this document. Such an
update also needs a new QSPEC version number. Furthermore, all QOSM
definitions must be updated to include how the new mandatory
parameter is to be interpreted in the respective QOSM.
Additional optional QSPEC parameters MAY need to be defined in the
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 19]
Internet Draft QoS-NSLP QSPEC Template June 2006
Future and are defined in separate informational documents specific
to a given QOSM. For example, optional QSPEC parameters are defined
in [RMD-QOSM] and [Y.1541-QOSM].
Guidelines on the technical criteria to be followed in evaluating
requests for new codepoint assignments are given for the overall NSIS
protocol suite in a separate NSIS extensibility document
[NSIS-EXTENSIBILITY].
4.7 QOSM Specification Requirements
A QOSM specification MUST define QSPEC parameter behavior for these
cases: a) new optional QSPEC parameters the QOSM specification
defines, and b) remapping of existing mandatory or optional QSPEC
parameters, as described in Section 4.2. Unless otherwise specified
in the QOSM specification document, the behaviors to strictly
interpret the mandatory and optional QSPEC parameters are defined in
this document through the references to RFCs that precisely define
the QSPEC parameter behaviors.
A QOSM specification MUST define how the mandatory parameters are to
be mapped onto the QSPEC parameters used by the QOSM, however the
mapping MAY result in slight modification to the intended
specification when an exact mapping is not possible. This definition
MUST allow a QNE implementing this QOSM to make a decision as to
whether a reservation described in terms of mandatory parameters can
be admitted. If for a particular mandatory parameter no mapping can
be found that guarantees the desired QoS, the QNE is advised to raise
the <NON QOSM HOP> flag. In other words, for all mandatory
parameters a mapping must be defined, but it is acknowledged that
this mapping may result in slightly bending the original intention of
the QNI.
A QOSM specification MUST define what happens in case of preemption
if the default QNI behavior (tear down preempted reservation) is not
followed (see Section 6.5).
As discussed in Section 4.5.1, a QOSM specification MAY specify the
conditions for a 'partially met' error condition and MAY define
additional QOSM specific errors.
Further content of a QOSM description is given in Appendix A.
5. QSPEC Format Overview
QSPEC = <QSPEC Version> <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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 20]
Internet Draft QoS-NSLP QSPEC Template June 2006
following Sections are mandatory QSPEC parameters unless specifically
designated as optional QSPEC parameters.
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.
<QSPEC Version> identifies the QSPEC version number. Later QSPEC
versions MUST be backward compatible with earlier QSPEC versions.
That is, a version n+1 device must support a version n (or earlier)
QSPEC and QSPEC parameters. If the version n device receives
mandatory parameters (with the M-flag set, as discussed in Section
7) that are not supported in version n (only supported in version
n+1), then the version n device concludes that either a) the M-flag
is set incorrectly for an optional parameter it does not support, or
b) the M-flag is correctly set for a mandatory parameter it does not
support. In either case, the version n device responds with a
'Malformed QSPEC' error code (0x03), as discussed in Section 4.5.1.
A new QSPEC version MUST be defined whenever this document is
reissued, for example, whenever a new mandatory parameter is added.
Mandatory parameters in a new QSPEC version MUST be a superset of
those in the previous QSPEC version.
The <QOSM ID> identifies the particular QOSM being used by the QNI
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. Even
if a QNE does not support the QOSM it MUST interpret at least the
mandatory parameters. Note that more parameters than required by the
QOSM can be included by the QNI. QSPEC version and 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].
<QSPEC Control Information> = <NON QOSM Hop> <Excess Treatment>
Note that <NON QOSM Hop> is a read-write parameter. <Excess
Treatment> is a read-only parameter.
<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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 21]
Internet Draft QoS-NSLP QSPEC Template June 2006
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 PLR> <Path PER>
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>
<Bandwidth> = link bandwidth needed by flow [RFC2212, RFC2215]
<Token Bucket> = <r> <b> <p> <m> <MTU> [RFC2210]
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].
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 22]
Internet Draft QoS-NSLP QSPEC Template June 2006
<Priority> = <Preemption Priority> <Defending Priority>
<Admission Priority> <RPH Priority>
<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. <Admission Priority>
and <RPH Priority> provide 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.
Appropriate security measures need to be taken to prevent abuse of
the <Priority> parameters, see Section 8 on Security Considerations.
[Y.1540] defines packet transfer outcomes, as follows:
Successful: packet arrives within the preset waiting time with no
errors
Lost: packet fails to arrive within the waiting time
Errored: packet arrives in time, but has one or more bit errors
in the header or payload
Packet Loss Ratio (PLR) = total packets lost/total packets sent
Packet Error Ratio (PER) = total errored packets/total packets sent
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> 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 PLR> <Path PER>
<Ctot> <Dtot> <Csum> <Dsum>
When used in the <QoS Available> object, <Traffic Description> refers
to traffic resources available at a QNE in the network.
The <QoS Available> Object collects information on the resources
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 23]
Internet Draft QoS-NSLP QSPEC Template June 2006
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 mean packet delay added by each QNE. This delay
results from speed-of-light propagation delay, from packet processing
limitations, or both. The mean delay reflects the variable queuing
delay that 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 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 [RFC2212]. 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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 24]
Internet Draft QoS-NSLP QSPEC Template June 2006
jitter, or delay variation, is defined in [RFC3393], Section 3.4
(Type-P-One-way-ipdv), and where the selection function includes the
packet with minimum delay such that the distribution is equivalent to
2-point delay variation in [Y.1540]. The suggested evaluation
interval is 1 minute. 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 method for the <Path Jitter> parameter is the combination
of several statistics describing the delay variation distribution
with a clamp on the maximum value (note that the methods of
accumulation and estimation of nominal QNE jitter are specified in
clause 8 of [Y.1541]). 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 [RFC2212].
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 PLR> parameter accumulates the packet loss rate (PLR) of
the packet forwarding process associated with each QNE, where the PLR
is defined to be the PLR added by each QNE. Each QNE MUST add the
PLR of its outgoing link, which includes the QNR adding the
associated PLR for the egress link. Furthermore, the QNI MUST add
the PLR of the ingress link. The composition rule for the <Path
PLR> parameter is summation with a clamp on the maximum value (this
assumes sufficiently low PLR values such that summation error is not
significant, however a more accurate composition function is
specified in clause 8 of [Y.1541]). This quantity, when composed
end-to-end, informs the QNR (or QNI in a RESPONSE message) of the
minimal packet PLR along the path from QNI to QNR.
<Ctot>, <Dtot>, <Csum>, <Dsum>: Error terms C and D represent how the
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.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 25]
Internet Draft QoS-NSLP QSPEC Template June 2006
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 [RFC2212]. 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.
6. 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 prescribe that only a
subset of the procedures listed below may be used.
Note that QoS NSLP does not mandate the usage of a RESPONSE message.
In fact, a RESPONSE message will only be generated if the QNI
includes an RII (Request Identification Information) in the RESERVE
message. Some of the QSPEC procedures below, however, are only
meaningful when a RESPONSE message is possible. The QNI SHOULD in
these cases include an RII.
6.1 Sender-Initiated Reservations
Here the QNI issues a RESERVE, which may be replied to by a RESPONSE.
The following possibilities for QSPEC object usage exist:
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 26]
Internet Draft QoS-NSLP QSPEC Template June 2006
ID | RESERVE | RESPONSE
---------------------------------------------------------------
1 | QoS Desired | QoS Reserved
2 | QoS Desired, QoS Avail. | QoS Reserved, QoS Avail.
3 | QoS Desired, QoS Avail., Min. QoS | QoS Reserved, QoS Avail.
(1) 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. If the
reservation is successful, the RESPONSE can be omitted in this case.
If a RESPONSE was requested by a QNE on the path, the QSPEC in the
RESPONSE can be omitted.
(2) 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
parameter values in QoS Available to those in QoS Desired (except for
cumulative parameters such as <path latency>).
Each QNE downgrades 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 the 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).
All parameters in the QoS Available QSPEC object in the RESPONSE are
copied with their values from the QoS Available QSPEC object in the
RESERVE (irrespective of whether they have also been copied into QoS
Desired). Note that the parameters in QoS Available are read-write
in the RESERVE message, whereas they are read-only in the RESPONSE.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 27]
Internet Draft QoS-NSLP QSPEC Template June 2006
In this case, the QNI SHOULD request a RESPONSE since it will
otherwise not learn what QoS is available.
(3) this case is handled as case (2), 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 there is no minimum value for this
parameter.
Regarding Control Information, the rule is that all parameters that
have been included in the RESERVE message by the QNI MUST also be
included in the RESPONSE message by the QNR with the value they had
when arriving at the QNR. When traveling in the RESPONSE message,
all Control Information parameters are read-only.
Also in this case, the QNI SHOULD request a RESPONSE.
6.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.
ID| QUERY | RESERVE | RESPONSE
---------------------------------------------------------------------
1 |QoS Des. | QoS Des. | QoS Res.
2 |QoS Des.,Min. QoS | QoS Des.,QoS Avl.,(Min QoS)| QoS Res.,QoS Avl.
3 |Qos Des. QoS Avl. | QoS Des., QoS Avl. | QoS Res.
(1) and (2) 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
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.
For a successful reservation, the RESPONSE message in case (1) is
optional (as is the QSPEC inside). In case (2) however, the RESPONSE
is necessary in order for the QNI to learn about the QoS available.
(3) This is the "RSVP-style" scenario. The sender (QNR) issues a
QUERY with QoS Desired informing the receiver (QNI) about the QoS it
desires as above. It also includes a QoS Available object to collect
path properties. Note that here, path properties are collected with
the QUERY message, whereas in the previous model (2), path properties
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 28]
Internet Draft QoS-NSLP QSPEC Template June 2006
were collected in the RESERVE message.
Some parameters in QoS Available may the same as in QoS Desired. For
these parameters the implicit message is that the sender would be
satisfied by a reservation with lower parameter values than specified
in QoS Desired.
It is possible for QoS Available to contain parameters that do not
appear in QoS Desired. It is assumed that the value of these
parameters is collected for informational purposes only (e.g. path
latency).
Parameter values in QoS Available are seeded according to the senders
capabilities. Each QNE downgrades or cumulates the parameter values
according to its current capabilities.
The receiver (QNI) signals QoS Desired as follows: For those
parameters that appear in both QoS Available and QoS Desired in the
QUERY message, it takes the (possibly downgraded) parameter values
from QoS Available. For those parameters that only appear in QoS
Desired, it adopts the parameter values from QoS Desired.
The parameters in the QoS Available QSPEC object in the RESERVE
message are copied with their values from the QoS Available QSPEC
object in the QUERY message. Note that the parameters in QoS
Available are read-write in the QUERY message, whereas they are
read-only in the RESERVE message.
The advantage of this model compared to the sender-initiated
reservation (model 2) 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.
Regarding Control Information in receiver-initiated reservations, the
sender includes all Control Information it cares about in the QUERY
message. Read-write parameters are updated by QNEs as the QUERY
message travels towards the receiver. The receiver includes all
Control Information parameters arriving in the QUERY message also in
the RESERVE message, as read-only parameters with the value they had
when arriving at the receiver.
Also in this scenario, the QNI SHOULD request a RESPONSE.
6.3 Resource Queries
Here the QNI issues a QUERY in order to investigate what resources
are currently available. The QNR replies with a RESPONSE.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 29]
Internet Draft QoS-NSLP QSPEC Template June 2006
ID | QUERY | RESPONSE
--------------------------------------------
1 | QoS Available | QoS Available
Note QoS Available when traveling in the QUERY is read-write, whereas
in the RESPONSE it is read-only.
6.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.
6.5 Preemption
A flow can be preempted by a QNE based on the values of the QSPEC
Priority parameter (see Section 7.2.7). In this case the reservation
state for this flow is torn down in this QNE, and the QNE sends a
NOTIFY message to the QNI, as described in [QoS-SIG]. No QSPEC is
carried in the NOTIFY message. The NOTIFY message carries only the
Session ID and a INFO_SPEC with the error code as described in
[QoS-SIG]. The QNI would normally tear down the preempted
reservation by sending a RESERVE with the TEAR flag set using the SII
of the preempted reservation. However, the QNI can follow other
procedures as specified in its QOSM.
7. 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
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. However, in a given QSPEC object, all objects are either
read-write or read-only. In order to simplify keeping track of
whether an object is read-write or read-only, a corresponding flag is
associated with each object.
Network byte order ('big-endian') for all 16- and 32-bit integers, as
well as 32-bit floating point numbers, are as specified in [RFC1832,
IEEE754, NETWORK-BYTE-ORDER].
7.1 General QSPEC Formats
The format of the QSPEC closely follows that used in GIST [GIST] and
QoS NSLP [QoS-SIG]. Every object (and parameter) has the following
general format:
o The overall format is Type-Length-Value (in that order).
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 30]
Internet Draft QoS-NSLP QSPEC Template June 2006
o Some parts of the type field are set aside for control flags.
o Length has the units of 32-bit words, and measures the length of
Value. If there is no Value, Length=0. The Object length
excludes the header.
o Value is a whole number of 32-bit words. If there is any padding
required, the length and location MUST be defined by the
object-specific format information; objects that contain variable
length types may need to include additional length subfields to do
so.
o Any part of the object used for padding or defined as reserved("r")
MUST be set to 0 on transmission and MUST be ignored on reception.
o Empty QSPECs and empty QSPEC Objects MUST NOT be used.
o Duplicate objects, duplicate parameters, and/or multiple
occurrences of a parameter MUST NOT be used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common QSPEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC Control Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// QSPEC QoS Objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Common QSPEC Header is a fixed 4-byte long object containing the
QOSM ID and an identifier for the QSPEC Procedure (see Section 6.1):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers. | QOSM ID | QSPEC Proc. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that a length field is not necessary since the overall length of
the QSPEC is contained in the higher level QoS NSLP data object.
Vers.: Identifies the QSPEC version number. It is assigned by IANA.
QOSM ID: Identifies the particular QOSM being used by the QNI. It is
assigned by IANA.
QSPEC Proc.: Is composed of two times 4 bits. The first set of bits
identifies the Message Sequence, the second set
identifies the QSPEC Object Combination used for this
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 31]
Internet Draft QoS-NSLP QSPEC Template June 2006
particular message sequence:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Mes.Sq |Obj.Cmb|
+-+-+-+-+-+-+-+-+
The Message Sequence field can attain the following
values:
0: Sender-Initiated Reservations, as defined in Section
6.1.1
1: Receiver-Initiated Reservations, as defined in
Section 6.1.2
2: Resource Queries, as defined in Section 6.1.3
The Object Combination field can take the values between
1 and 3 indicated in the tables in Section 6.1.1 to
6.1.3.
The QSPEC Control Information is a variable length object containing
one or more parameters. The QSPEC Objects field is a collection of
QSPEC objects (QoS Desired, QoS Available, etc.), which share a
common format and each contain several parameters.
Both the QSPEC Control Information object and the QSPEC QoS objects
share a common header format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|r|r| Object Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R Flag: If set the parameters contained in the object are read-only.
Otherwise they are read-write. Note that in the case of
Object Type = 0 (Control Information), this value is
overwritten by parameter-specific values.
E Flag: Set if an error occurs on object level
Object Type = 0: control information
= 1: QoS Desired
= 2: QoS Available
= 3: QoS Reserved
= 4: Minimum QoS
The r-flags are reserved.
Each optional or mandatory parameter within an object can be
similarly encoded in TLV format using a similar parameter header:
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 32]
Internet Draft QoS-NSLP QSPEC Template June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|E|N|T| Parameter ID |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag: When set indicates the subsequent parameter is a mandatory
parameter and MUST be interpreted. Otherwise the parameter is
optional and can be ignored if not understood.
E Flag: When set indicates an error occurred when this parameter was
being interpreted.
N Flag: Not-supported Flag (see Section 4.5). For mandatory
parameters the value of this flag is always zero.
T Flag: Tunneled-parameter Flag (see Section 4.5)
Parameter Type: Assigned to each parameter (see below)
7.2 Parameter Coding
Parameters are usually coded individually, for example, the Bandwidth
Parameter (Section 7.2.3). However, it is also possible to combine
several parameters into one parameter field, which is called
"container coding". This coding is useful if either a) the
parameters always occur together, as for example the several
parameters that jointly make up the token bucket, or b) in order to
make coding more efficient because the length of each parameter value
is much less than a 32-bit word (as for example described in
[RMD-QOSM]). Use of containers avoids header overload QSPEC, and
parameters bound together in a container are usually used together in
any QOSM. When a container is defined, the Parameter ID, the M, E,
N, and T flags refer to the container. An example for containers is
the <Token Bucket>, or the PHR Container specified in [RMD-QOSM].
7.2.1 <NON QOSM Hop> Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 0 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NON QOSM Hop | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. It is a read-write
parameter.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 33]
Internet Draft QoS-NSLP QSPEC Template June 2006
7.2.2 <Excess Treatment> Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 1 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Excess Treatment: Indicates how the QNE SHOULD process out-of-profile
Traffic, that is, traffic not covered by the Traffic Description.
The excess treatment parameter is set by the QNI. It is a read-only
parameter. Allowed values are as follows:
0: drop
1: shape
2: remark
3: no metering or policing is permitted
If the excess treatment is unspecified, then the <Excess Treatment>
parameter SHOULD be omitted. The default excess treatment in case
that none is specified is that there are no guarantees to excess
traffic, i.e. a QNE can do whatever it finds suitable.
If 'no metering or policing is permitted' is signaled, the QNE should
accept the <Excess Treatment> parameter set by the sender with
special care so that excess traffic should not cause a problem. To
request the Null Meter [RFC3290] is especially strong, and should be
used with caution.
A NULL metering application [RFC2997] would not include the traffic
profile, and conceptually it should be possible to support this with
the QSPEC. A QSPEC without a traffic profile is not excluded by the
current specification. However, note that the traffic profile is
important even in those cases when the excess treatment is not
specified, e.g., in negotiating bandwidth for the best effort
aggregate. However, a "NULL Service QOSM" would need to be specified
where the desired QNE Behavior and the corresponding QSPEC format are
described.
As an example behavior for a NULL metering, in the properly
configured DiffServ router, the resources are shared between the
aggregates by the scheduling disciplines. Thus, if the incoming rate
increases, it will influence the state of a queue within that
aggregate, while all the other aggregates will be provided sufficient
bandwidth resources. NULL metering is useful for best effort and
signaling data, where there is no need to meter and police this data
as it will be policed implicitly by the allocated bandwidth and,
possibly, active queue management mechanism.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 34]
Internet Draft QoS-NSLP QSPEC Template June 2006
7.2.3 <Bandwidth> [RFC2212, RFC2215]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 2 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
7.2.4 <Slack Term> Parameter [RFC2212, RFC2215]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 3 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
7.2.5 <Token Bucket> Parameters [RFC2215]
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 unsigned integer is the minimum policed unit (m), and the
second unsigned 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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 35]
Internet Draft QoS-NSLP QSPEC Template June 2006
applications (see Section 7.2).
Token Bucket #1 Parameter ID = 4
Token Bucket #1: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 4 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Token Bucket #2 Parameter ID = 5
Token Bucket #2: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 5 |r|r|r|r| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size [MTU] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When r, b, and p 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
all ones (255) and a sign bit and mantissa of all zeroes.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 36]
Internet Draft QoS-NSLP QSPEC Template June 2006
7.2.6 <QoS Class> Parameters
7.2.6.1 <PHB Class> Parameter [RFC3140]
As prescribed in RFC 3140, 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 6 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| Reserved |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
7.2.6.2 <Y.1541 QoS Class> Parameter [Y.1541]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 7 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|Y.1541 QoS Cls.| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently
allowed are 0, 1, 2, 3, 4, 5, 6, 7.
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.
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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 37]
Internet Draft QoS-NSLP QSPEC Template June 2006
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.
Class 6:
Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5.
Applications that are highly sensitive to loss, such as television
transport, high-capacity TCP transfers, and TDM circuit emulation.
Class 7:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5.
Applications that are highly sensitive to loss, such as television
transport, high-capacity TCP transfers, and TDM circuit emulation.
7.6.2.3 <DSTE Class Type> Parameter [RFC3564]
DSTE class type is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 8 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|DSTE Cls. Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DSTE Class Type: Indicates the DSTE class type. Values currently
allowed are 0, 1, 2, 3, 4, 5, 6, 7.
7.2.7 Priority Parameters
7.2.7.1 <Preemption Priority> & <Defending Priority> Parameters
[RFC3181]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The priority of the new flow compared with the
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 38]
Internet Draft QoS-NSLP QSPEC Template June 2006
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.
As specified in [RFC3181], <Preemption Priority> and <Defending
Priority> are 16-bit integer values and both MUST be populated if the
parameter is used.
7.2.7.2 <Admission Priority> Parameter [PRIORITY-RQMTS]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Admission | Reserved |
+ 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:
0 - best-effort priority flow
1 - normal priority flow
2 - high priority flow
A reservation without an <Admission Priority> parameter MUST be
treated as a reservation with an <Admission Priority> = 1.
7.2.7.3 <RPH Priority> Parameter [SIP-PRIORITY]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|E|0|T| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ RPH Namespace | RPH Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[SIP-PRIORITY] defines a resource priority header (RPH) with
parameters "RPH Namespace" and "RPH Priority" combination, and if
populated is applicable only to flows with high reservation priority,
as follows:
RPH Namespace:
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 39]
Internet Draft QoS-NSLP QSPEC Template June 2006
0 - dsn
1 - drsn
2 - q735
3 - ets
4 - wps
5 - not used
RPH Priority:
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 the <Admission Priority> parameter MAY be used in
combination with the <RPH Priority> parameter, which depends on the
supported QOSM. Furthermore, if more then one RPH namespace is
supported by a QOSM, then the QOSM MUST specify how the mapping
between the priorities belonging to the different RPH namespaces are
mapped to each other.
Note also that additional work is needed to communicate these flow
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 40]
Internet Draft QoS-NSLP QSPEC Template June 2006
priority values to bearer-level network elements
[VERTICAL-INTERFACE].
7.2.8 <Path Latency> Parameter [RFC2210, RFC2215]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 12 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency is a single 32-bit integer in network byte order.
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The latencies are
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
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
not-supported flagand either leave the value of Path Latency as is,
or add its best estimate of its lower bound. A raised not-supported
flagflag 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.
7.2.9 <Path Jitter> Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 13 |r|r|r|r| 3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Jitter is a set of three 32-bit integers in network byte
order. The Path Jitter parameter is the combination of three
statistics describing the Jitter distribution with a clamp of
(2**32 - 1) on the maximum of each value. The jitter STATs are
reported in units of one microsecond. A system with resolution less
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 41]
Internet Draft QoS-NSLP QSPEC Template June 2006
than one microsecond MUST set unused digits to zero. An individual
QNE can advertise jitter values between 1 and 2**28 (somewhat over
two minutes) and the total jitter computed across all QNEs can range
as high as (2**32)-2. If the combination of the different element
values 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 not-supported flag
and either leave the value of Path Jitter as is, or add its best
estimate of its STAT values. A raised not-supported 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 that cannot accurately predict the jitter of packets
it is processing SHOULD set its local parameter to this value.
Because the composition function limits the total 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.
NOTE: The Jitter composition function makes use of the <Path Latency>
parameter. Composition functions for loss, latency and jitter may be
found in [Y.1541].
7.2.10 <Path PLR> Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 14 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PLR is a single 32-bit single precision IEEE floating point
number in network byte order. The composition rule for the <Path
PLR> parameter is summation with a clamp of 10^-1 on the maximum
value. The PLRs are reported in units of 10^-11. A system with
resolution less than one microsecond MUST set unused digits to zero.
An individual QNE can advertise a PLR value between zero and 10^-2
and the total PLR added across all QNEs can range as high as 10^-1.
If the sum of the different elements values exceeds 10^-1, the
end-to-end advertised PLR SHOULD be reported as indeterminate. A QNE
that cannot accurately predict the PLR of packets it is processing
MUST raise the not-supported flag and either leave the value of Path
PLR as is, or add its best estimate of its lower bound. A raised
not-supported flag indicates the value of Path PLR is a lower bound
of the real Path PLR. The distinguished value 10^-1 is taken to mean
indeterminate PLR. A QNE which cannot accurately predict the PLR 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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 42]
Internet Draft QoS-NSLP QSPEC Template June 2006
indicates that the true path PLR 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.
7.2.11 <Path PER> Parameter
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 15 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PER is a single 32-bit single precision IEEE floating point
number in network byte order. The composition rule for the <Path
PER> parameter is summation with a clamp of 10^-1 on the maximum
value. The PERs are reported in units of 10^-11. A system with
resolution less than one microsecond MUST set unused digits to zero.
An individual QNE can advertise a PER value between zero and 10^-2
and the total PER added across all QNEs can range as high as 10^-1.
If the sum of the different elements values exceeds 10^-1, the
end-to-end advertised PER SHOULD be reported as indeterminate. A QNE
that cannot accurately predict the PER of packets it is processing
MUST raise the not-supported flag and either leave the value of Path
PER as is, or add its best estimate of its lower bound. A raised
not-supported flag indicates the value of Path PER is a lower bound
of the real Path PER. The distinguished value 10^-1 is taken to mean
indeterminate PER. A QNE which cannot accurately predict the PER 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 PER 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.
7.2.12 <Ctot> <Dtot> <Csum> <Dsum> Parameters [RFC2210, RFC2212,
RFC2215]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 16 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| End-to-end composed value for C [Ctot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 43]
Internet Draft QoS-NSLP QSPEC Template June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 17 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| End-to-end composed value for D [Dtot] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 18 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Since-last-reshaping point composed C [Csum] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| 19 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 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.
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)
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 44]
Internet Draft QoS-NSLP QSPEC Template June 2006
9. IANA Considerations
This section defines the registries and initial codepoint assignments
for the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].
It also defines the procedural requirements to be followed by IANA in
allocating new codepoints.
This specification allocates the following codepoints in existing
registries:
PHB Class Parameter [RFC3140] (Section 7.2.6.1)
The registries needed to use RFC 3140 already exist [DSCP-REGISTRY,
PHBID-CODES-REGISTRY].
This specification creates the following registries with the
structures as defined below:
Object Types (12 bits):
The following values are allocated by this specification:
0-4: assigned as specified in Section 7.
The allocation policies for further values are as follows:
5-63: Standards Action
64-127: Private/Experimental Use
128-4095: Reserved
QSPEC Version (4 bits):
The following value is allocated by this specification:
0: assigned to Version 0 QSPEC
The allocation policies for further values are as follows:
1-15: Standards Action
QOSM ID (12 bits):
The allocation policies are as follows:
0-63: Specification Required
64-127: Private/Experimental Use
128-4095: Reserved
Note that QOSM ID assignments are normally requested in QOSM
specification documents.
QSPEC Procedure (8 bits):
Broken down into
Message Sequence (4 bits):
The following values are allocated by this specification:
0-2: assigned as specified in Section 7.1
The allocation policies for further values are as follows:
3-15: Standards Action
Object Combination:
The following values are allocated by this specification:
0-2: assigned as specified in tables in Section 6.1.1 --> 6.1.3
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 45]
Internet Draft QoS-NSLP QSPEC Template June 2006
The allocation policies for further values are as follows:
3-15: Standards Action
Error Code (16 bits)
The following values are allocated by this specification:
1-3: assigned as specified in Section 4.5.1
The allocation policies for further values are as follows:
4-127: Specification Required (e.g., QOSM specification document)
128-255: Private/Experimental Use
255-65535: Reserved
Parameter ID (12 bits):
The following values are allocated by this specification:
0-18: assigned as specified in Sections 7.2.1 --> 7.2.12.
The allocation policies for further values are as follows:
19-63: Standards Action (for mandatory parameters)
64-127: Specification Required (for optional parameters)
128-255: Private/Experimental Use
255-4095: Reserved
Note that if additional mandatory parameters are defined in the
future, this requires a standards action equivalent to reissuing
this document as a QSPEC-bis.
Excess Treatment Parameter (8 bits):
The following values are allocated by this specification:
0-3: assigned as specified in Section 7.2.2
The allocation policies for further values are as follows:
4-63: Standards Action
64-255: Reserved
Y.1541 QoS Class Parameter (12 bits):
The following values are allocated by this specification:
0-7: assigned as specified in Section 7.2.6.2
The allocation policies for further values are as follows:
8-63: Standards Action
64-4095: Reserved
DSTE Class Type Parameter (12 bits):
The following values are allocated by this specification:
0-7: assigned as specified in Section 7.2.6.3
The allocation policies for further values are as follows:
8-63: Standards Action
64-4095: Reserved
Admission Priority Parameter (8 bits):
The following values are allocated by this specification:
0-2: assigned as specified in Section 7.2.6.2
The allocation policies for further values are as follows:
3-63: Standards Action
64-255: Reserved
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 46]
Internet Draft QoS-NSLP QSPEC Template June 2006
RPH Namespace Parameter (16 bits):
The following values are allocated by this specification:
0-5: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
6-63: Standards Action
64-65535: Reserved
RPH Priority Parameter (8 bits):
dsn namespace:
The following values are allocated by this specification:
0-4: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
5-63: Standards Action
64-255: Reserved
drsn namespace:
The following values are allocated by this specification:
0-5: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
6-63: Standards Action
64-255: Reserved
Q735 namespace:
The following values are allocated by this specification:
0-4: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
5-63: Standards Action
64-255: Reserved
ets namespace:
The following values are allocated by this specification:
0-4: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
5-63: Standards Action
64-255: Reserved
wts namespace:
The following values are allocated by this specification:
0-4: assigned as specified in Section 7.2.7.2
The allocation policies for further values are as follows:
5-63: Standards Action
64-255: Reserved
10. Acknowledgements
The authors would like to thank (in alphabetical order) David Black,
Anna Charny, Adrian Farrel, Matthias Friedrich, Xiaoming Fu, Robert
Hancock, Chris Lang, Jukka Manner, Dave Oran, Tom Phelan, Alexander
Sayenko, Bernd Schloer, Hannes Tschofenig, and Sven van den Bosch
for their very helpful suggestions.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 47]
Internet Draft QoS-NSLP QSPEC Template June 2006
11. Normative References
[DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry
[PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes
[GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet
Signaling Transport," work in progress.
[QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service
Signaling," work in progress.
[RFC1832] Srinivasan, R., "XDR: External Data Representation
Standard," RFC 1832, August 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification," RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality
of Service," September 1997.
[RFC2215] Shenker, S., Wroclawski, J., "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215, Sept.
1997.
[RFC2475] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3140] Black, D., et. al., "Per Hop Behavior Identification
Codes," June 2001.
12. Informative References
[CMSS] "PacketCable (TM) CMS to CMS Signaling Specification,
PKT-SP-CMSS-103-040402, April 2004.
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard
754-1985, August 1985.
[INTSERV-QOSM] Kappler, C., "A QoS Model for Signaling IntServ
Controlled-Load Service with NSIS," work in progress.
[NETWORK-BYTE-ORDER] Wikipedia, "Endianness,"
http://en.wikipedia.org/wiki/Endianness.
[NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", 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
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs," RFC 3181, October 1998.
[RFC2997] Bernet, Y., et. al., "Specification of the Null Service
Type," RFC 2997, November 2000.
[RFC3140] Black, D., et. al., "Per Hop Behavior Identification
Codes," RFC 3140, June 2001.
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 48]
Internet Draft QoS-NSLP QSPEC Template June 2006
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element,"
RFC 3181, October 2001.
[RFC3290] Bernet, Y., et. al., "An Informal Management Model for
Diffserv Routers," RFC 3290, May 2002.
[RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002.
[RFC3564] Le Faucheur, F., et. al., Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering, RFC 3564,
July 2003
[RFC3726] Brunner, M., et. al., "Requirements for Signaling
Protocols", RFC 3726, April 2004.
[RMD-QOSM] Bader, A., et. al., " RMD-QOSM: An NSIS QoS Signaling
Policy Model for Networks
Using Resource Management in DiffServ (RMD)," work in progress.
[SIP-PRIORITY] Schulzrinne, H., Polk, J., "Communications Resource
Priority for the Session Initiation Protocol(SIP)." work in
progress.
[VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion
on Associating of Control Signaling Messages with Media Priority
Levels," T1S1.7 & PRQC, October 2004.
[Y.1540] ITU-T Recommendation Y.1540, "Internet Protocol Data
Communication Service - IP Packet Transfer and Availability
Performance Parameters," December 2002.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
for IP-Based Services," May 2002.
[Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for
Networks Using Y.1541 QoS Classes," work in progress.
13. Authors' Addresses
Jerry Ash (Editor)
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 (Editor)
Traffic Lab
Ericsson Research
Ericsson Hungary Ltd.
Laborc u. 1 H-1037
Budapest Hungary
Email: Attila.Bader@ericsson.com
Cornelia Kappler (Editor)
Siemens AG
Siemensdamm 62
Berlin 13627
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 49]
Internet Draft QoS-NSLP QSPEC Template June 2006
Germany
Email: cornelia.kappler@siemens.com
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 must include the following information:
- Role of QNEs in this QOSM: E.g., location, frequency, statefulness,
etc.
- QSPEC Definition: A QOSM must specify the QSPEC, including a value
for the QOSM ID, and which QSPEC parameters must be included.
Furthermore it needs to explain how QSPEC parameters not used in
this QOSM are mapped onto parameters defined therein.
- QSPEC procedures: A QOSM must describe which QSPEC procedures are
applicable to this QOSM.
- Processing rules in QNEs: 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).
- QSPEC example: It includes at least one bit-level QSPEC example.
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-10.txt> [Page 50]
Internet Draft QoS-NSLP QSPEC Template June 2006
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
Version -05:
- 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
Version -06:
- defined "not-supported flag" and "tunneled parameter flag"
(subsumes "optional parameter flag")
- defined "error flag" for error handling
- updated bit error rate (BER) parameter to packet loss ratio (PLR)
parameter
- added packet error ratio (PER) parameter
- coding checked by independent expert
- coding updated to include RE flags in QSPEC objects and MENT flags
in QSPEC parameters
Version -07:
- added text (from David Black) on DiffServ QSPEC example in Section
6
- re-numbered QSPEC parameter IDs to start with 0 (Section 7)
- expanded IANA Considerations Section 9
Version -08:
- update to 'RSVP-style' reservation in Section 6.1.2 to mirror what
is done in RSVP
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 51]
Internet Draft QoS-NSLP QSPEC Template June 2006
- modified text (from David Black) on DiffServ QSPEC example in
Section 6.2
- update to general QSPEC parameter formats in Section 7.1 (length
restrictions, etc.)
- re-numbered QSPEC parameter IDs in Section 7.2
- modified <Excess Treatment> parameter values in Section 7.2.2
- update to reservation priority Section 7.2.7
- specify the 3 "STATS" in the <Path Jitter> parameter, Section
7.2.9.4
- minor updates to IANA Considerations Section 9
Version -09:
- remove the DiffServ example in Section 6.2 (intent is use text as a
basis for a separate DIFFSERV-QOSM I-D)
- update wording in example in Section 4.3, to reflect use of default
QOSM and QOSM selection by QNI
- make minor changes to Section 7.2.7.2, per the exchange on the list
- add comment on error codes, after the first paragraph in Section
4.5.1
Version -10:
- rewrote Section 2.0 for clarity
- added clarifications on mandatory parameters in Section 4.2; added
discussion of forwarding options when a domain supports a different
QOSM than the QNI
- expanded Section 4.5 on error code handling, including redefined
E-Flag and editorial changes to the N-Flag and T-Flag discussions
- made some editorial clarifications in Section 4.6 on defining new
mandatory parameters, and also reference the [NSIS-EXTENSIBILITY]
document
- Section 4.7 added to identify what a QOSM specification document
must include
- clarified the requirements in Section 5.0 for defining a new QSPEC
Version
- made editorial changes to Section 6, and added procedures for
handling preemption
- removed QOSM ID assignments in Section 9.0; clarified procedures
for defining new mandatory parameters; added registry of QOSM error
codes
C.2 Open Issues
None.
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
Ash, et. al. <draft-ietf-nsis-qspec-10.txt> [Page 52]
Internet Draft QoS-NSLP QSPEC Template June 2006
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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-10.txt> [Page 53]
| PAFTECH AB 2003-2026 | 2026-04-22 17:41:41 |