< draft-ietf-nsis-qspec-14.txt   draft-ietf-nsis-qspec-15.txt >
IETF Internet Draft NSIS Working Group G. Ash IETF Internet Draft NSIS Working Group G. Ash
Internet Draft AT&T Internet Draft AT&T
<draft-ietf-nsis-qspec-14.txt> A. Bader <draft-ietf-nsis-qspec-15.txt> A. Bader
Expiration Date: July 2007 Ericsson Expiration Date: August 2007 Ericsson
C. Kappler C. Kappler
Siemens GmbH&Co KG Siemens Networks GmbH & Co KG
D. Oran D. Oran
Cisco Systems, Inc. Cisco Systems, Inc.
January 2007 February 2007
QoS NSLP QSPEC Template QoS NSLP QSPEC Template
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 6 4. QSPEC Framework . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 QSPEC Objects . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 10 4.3 QSPEC Parameters . . . . . . . . . . . . . . . . . . . . . 10
4.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10 4.3.1 Traffic Model Parameter . . . . . . . . . . . . . . . 10
4.3.2 Constraints Parameters . . . . . . . . . . . . . . . 11 4.3.2 Constraints Parameters . . . . . . . . . . . . . . . 11
4.3.3 Traffic Handling Directives . . . . . . . . . . . . . 13 4.3.3 Traffic Handling Directives . . . . . . . . . . . . . 13
4.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 13 4.3.4 Traffic Classifiers . . . . . . . . . . . . . . . . . 13
4.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 13 4.4 Example of QSPEC Processing . . . . . . . . . . . . . . . . 14
5. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 16 5. QSPEC Processing & Procedures . . . . . . . . . . . . . . . . . 17
5.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 17 5.1 Local QSPEC Definition & Processing . . . . . . . . . . . . 17
5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC 5.2 Reservation Success/Failure, QSPEC Error Codes, & INFO_SPEC
Notification . . . . . . . . . . . . . . . . . . . . . . . 18 Notification . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Reservation Failure & Error E-Flag . . . . . . . . . 18 5.2.1 Reservation Failure & Error E-Flag . . . . . . . . . 19
5.2.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 19 5.2.2 QSPEC Parameter Not Supported N-Flag . . . . . . . . 20
5.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 19 5.2.3 INFO_SPEC Coding of Reservation Outcome . . . . . . . 20
5.2.4 QNE Generation of a RESPONSE message . . . . . . . . 20 5.2.4 QNE Generation of a RESPONSE message . . . . . . . . 21
5.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 21 5.2.5 Special Case of Local QSPEC . . . . . . . . . . . . . 22
5.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 21 5.3 QSPEC Procedures . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Sender-Initiated Reservations . . . . . . . . . . . . 22 5.3.1 Sender-Initiated Reservations . . . . . . . . . . . . 22
5.3.2 Receiver-Initiated Reservations . . . . . . . . . . . 23 5.3.2 Receiver-Initiated Reservations . . . . . . . . . . . 24
5.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 25 5.3.3 Resource Queries . . . . . . . . . . . . . . . . . . 26
5.3.4 Bidirectional Reservations . . . . . . . . . . . . . 25 5.3.4 Bidirectional Reservations . . . . . . . . . . . . . 26
5.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 25 5.3.5 Preemption . . . . . . . . . . . . . . . . . . . . . 26
5.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 26 5.4 QSPEC Extensibility . . . . . . . . . . . . . . . . . . . . 27
6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 26 6. QSPEC Functional Specification . . . . . . . . . . . . . . . . 27
6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 26 6.1 General QSPEC Formats . . . . . . . . . . . . . . . . . . . 27
6.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 29 6.2 QSPEC Parameter Coding . . . . . . . . . . . . . . . . . . 30
6.2.1 <TMOD-1> Parameter . . . . . . . . . . . . . . . . . 29 6.2.1 <TMOD-1> Parameter . . . . . . . . . . . . . . . . . 30
6.2.2 <TMOD-2> Parameter . . . . . . . . . . . . . . . . . 30 6.2.2 <TMOD-2> Parameter . . . . . . . . . . . . . . . . . 31
6.2.3 <Path Latency> Parameter . . . . . . . . . . . . . . 30 6.2.3 <Path Latency> Parameter . . . . . . . . . . . . . . 32
6.2.4 <Path Jitter> Parameter . . . . . . . . . . . . . . . 31 6.2.4 <Path Jitter> Parameter . . . . . . . . . . . . . . . 32
6.2.5 <Path PLR> Parameter . . . . . . . . . . . . . . . . 32 6.2.5 <Path PLR> Parameter . . . . . . . . . . . . . . . . 33
6.2.6 <Path PER> Parameter . . . . . . . . . . . . . . . . 32 6.2.6 <Path PER> Parameter . . . . . . . . . . . . . . . . 34
6.2.7 <Slack Term> Parameter . . . . . . . . . . . . . . . 33 6.2.7 <Slack Term> Parameter . . . . . . . . . . . . . . . 34
6.2.8 <Preemption Priority> & <Defending Priority> 6.2.8 <Preemption Priority> & <Defending Priority>
Parameters . . . . . . . . . . . . . . . . . . . . . 33 Parameters . . . . . . . . . . . . . . . . . . . . . 35
6.2.9 <Admission Priority> Parameter . . . . . . . . . . . 34 6.2.9 <Admission Priority> Parameter . . . . . . . . . . . 35
6.2.10 <RPH Priority> Parameter . . . . . . . . . . . . . . 34 6.2.10 <RPH Priority> Parameter . . . . . . . . . . . . . . 36
6.2.11 <Excess Treatment> Parameter . . . . . . . . . . . . 36 6.2.11 <Excess Treatment> Parameter . . . . . . . . . . . . 37
6.2.12 <PHB Class> Parameter . . . . . . . . . . . . . . . 37 6.2.12 <PHB Class> Parameter . . . . . . . . . . . . . . . 39
6.2.13 <DSTE Class Type> Parameter . . . . . . . . . . . . 38 6.2.13 <DSTE Class Type> Parameter . . . . . . . . . . . . 40
6.2.14 <Y.1541 QoS Class> Parameter . . . . . . . . . . . . 39 6.2.14 <Y.1541 QoS Class> Parameter . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 40 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 41
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
10. Normative References . . . . . . . . . . . . . . . . . . . . . 45 10. Normative References . . . . . . . . . . . . . . . . . . . . . 46
11. Informative References . . . . . . . . . . . . . . . . . . . . 46 11. Informative References . . . . . . . . . . . . . . . . . . . . 47
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 48
Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved Appendix A. Mapping of QoS Desired, QoS Available and QoS Reserved
of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 47 of NSIS onto AdSpec, TSpec and RSpec of RSVP IntServ . 48
Appendix B. Change History & Open Issues . . . . . . . . . . . . . 48 Appendix B. Change History & Open Issues . . . . . . . . . . . . . 49
B.1 Change History (since Version -04) . . . . . . . . 48 B.1 Change History (since Version -04) . . . . . . . . 49
B.2 Open Issues . . . . . . . . . . . . . . . . . . . 51 B.2 Open Issues . . . . . . . . . . . . . . . . . . . 53
Intellectual Property Statement . . . . . . . . . . . . . . . . . 52 Intellectual Property Statement . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 52 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 54
Conventions Used in This Document Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Contributors 1. Contributors
This document is the result of the NSIS Working Group effort. In This document is the result of the NSIS Working Group effort. In
skipping to change at page 7, line 18 skipping to change at page 7, line 18
controlled load [CL-QOSM], resource management with DiffServ controlled load [CL-QOSM], resource management with DiffServ
[RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM]. [RMD-QOSM], and QoS signaling for Y.1541 QoS classes [Y.1541-QOSM].
A QOSM specifies a set of QSPEC parameters that describe the QoS A QOSM specifies a set of QSPEC parameters that describe the QoS
desired and how resources will be managed by the RMF. The RMF desired and how resources will be managed by the RMF. The RMF
implements functions that are related to resource management and implements functions that are related to resource management and
processes the QSPEC parameters. processes the QSPEC parameters.
QOSMs affect the operation of the RMF in NSIS-capable nodes, the QOSMs affect the operation of the RMF in NSIS-capable nodes, the
information carried in QSPEC objects, and may under some information carried in QSPEC objects, and may under some
circumstances (e.g. aggregation) cause a separate NSLP session to be circumstances (e.g. aggregation) cause a separate NSLP session to be
instantiated by having the RMF as a QNI. QOSMs all utilize the common instantiated by having the RMF as a QNI. QOSM specifications may
data, state machines, and APIs of the underlying NSIS protocols and define RMF triggers that cause the QoS NSLP to run semantics within
are not expected to re-define or extend these in any way. the underlying QoS NSLP signaling state and messaging processing
rules, as defined in Section 5.2 of [QoS-SIG]. New QoS NSLP message
processing rules can only be defined in Standards Track extensions to
the QoS NSLP. If a QOSM specification defines triggers that deviate
from existing standard QoS NSLP processing rules (must be standards
track in that case), the fallback for QNEs not supporting that QOSM
is to use the standard QoS NSLP state transition/message processing
rules.
The QOSM specification includes how the requested QoS resources will The QOSM specification includes how the requested QoS resources will
be described and how they will be managed by the RMF. For this be described and how they will be managed by the RMF. For this
purpose, the QOSM specification defines a set of QSPEC parameters it purpose, the QOSM specification defines a set of QSPEC parameters it
uses to describe the desired QoS and resource control in the RMF, and uses to describe the desired QoS and resource control in the RMF, and
it may define additional QSPEC parameters. it may define additional QSPEC parameters.
When a QoS NSLP message travels through different domains, it may When a QoS NSLP message travels through different domains, it may
encounter different QOSMs. Since QOSM use different QSPEC parameters encounter different QOSMs. Since QOSM use different QSPEC parameters
for describing resources, the QSPEC parameters included by the QNI for describing resources, the QSPEC parameters included by the QNI
skipping to change at page 13, line 31 skipping to change at page 13, line 31
The <Defending Priority> parameter is used to compare with the The <Defending Priority> parameter is used to compare with the
preemption priority of new flows. For any specific flow, its preemption priority of new flows. For any specific flow, its
preemption priority MUST always be less than or equal to the preemption priority MUST always be less than or equal to the
defending priority. <Admission Priority> and <RPH Priority> provide defending priority. <Admission Priority> and <RPH Priority> provide
an essential way to differentiate flows for emergency services, ETS, an essential way to differentiate flows for emergency services, ETS,
E911, etc., and assign them a higher admission priority than normal E911, etc., and assign them a higher admission priority than normal
priority flows and best-effort priority flows. priority flows and best-effort priority flows.
4.3.3 Traffic Handling Directives 4.3.3 Traffic Handling Directives
An application MAY like to reserve resources for packets and also
specify a specific traffic handling behavior, such as <Excess
Treatment>. In addition, an application MAY like to define RMF
triggers that cause the QoS NSLP to run semantics within the
underlying QoS NSLP signaling state and messaging processing rules,
as defined in Section 5.2 of [QoS-SIG]. Note, however, that new QoS
NSLP message processing rules can only be defined in Standards Track
extensions to the QoS NSLP.
As with constraints parameters and other QSPEC parameters,
traffic-handling-directives parameters may be defined in QOSM
specifications in order to provide support for QOSM-specific resource
management functions. Such QOSM-specific parameters are already
defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM].
The <Excess Treatment> parameter describes how the QNE will process The <Excess Treatment> parameter describes how the QNE will process
excess traffic, that is, out-of-profile traffic. Excess traffic MAY excess traffic, that is, out-of-profile traffic. Excess traffic MAY
be dropped, shaped and/or remarked. The excess treatment parameter is be dropped, shaped and/or remarked. The excess treatment parameter is
initially set by the QNI and cannot be overwritten. initially set by the QNI and cannot be overwritten.
Note that QOSM specifications SHOULD NOT define new RMF functions
required by a QOSM UNLESS such NSIS signaling functionality is
defined in QoS NSLP [QoS-SIG]. That is, a QOSM is not allowed to
extend QoS NSLP signaling functionality; new RMF functions are
specified only within a QoS NSLP signaling framework.
4.3.4 Traffic Classifiers 4.3.4 Traffic Classifiers
An application MAY like to reserve resources for packets with a An application MAY like to reserve resources for packets with a
particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB particular DiffServ per-hop behavior (PHB) [RFC2475]. Note that PHB
class is normally set by a downstream QNE to tell the QNI how to mark class is normally set by a downstream QNE to tell the QNI how to mark
traffic to ensure treatment committed by admission control. An traffic to ensure treatment committed by admission control. An
application MAY like to reserve resources for packets with a application MAY like to reserve resources for packets with a
particular QoS class, e.g. Y.1541 QoS class [Y.1541] or particular QoS class, e.g. Y.1541 QoS class [Y.1541] or
DiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564, DiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564,
RFC4124]. These parameters are useful in various QOSMs, e.g., RFC4124]. These parameters are useful in various QOSMs, e.g.,
skipping to change at page 23, line 49 skipping to change at page 24, line 18
otherwise not learn what QoS is available. otherwise not learn what QoS is available.
Case 3: Case 3:
This case is handled as case 2, except that the reservation fails This case is handled as case 2, except that the reservation fails
when QoS Available becomes less than Minimum QoS for one parameter. when QoS Available becomes less than Minimum QoS for one parameter.
If a parameter appears in the QoS Available object but not in the If a parameter appears in the QoS Available object but not in the
Minimum QoS object it is assumed that there is no minimum value for Minimum QoS object it is assumed that there is no minimum value for
this parameter. this parameter.
Regarding <Traffic Handling Directives>, the default rule is that all
QSPEC parameters that have been included in the RESERVE message by
the QNI are also 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 <Traffic Handling Directives> parameters are
read-only. Note that a QOSM specification may define its own
<Traffic Handling Directives> parameters and processing rules.
5.3.2 Receiver-Initiated Reservations 5.3.2 Receiver-Initiated Reservations
Here the QNR issues a QUERY message which is replied to by the QNI Here the QNR issues a QUERY message which is replied to by the QNI
with a RESERVE message if the reservation was successful. The QNR in with a RESERVE message if the reservation was successful. The QNR in
turn sends a RESPONSE message to the QNI. The following 3 cases for turn sends a RESPONSE message to the QNI. The following 3 cases for
QSPEC object usage exist: QSPEC object usage exist:
ID| QUERY | RESERVE | RESPONSE ID| QUERY | RESERVE | RESPONSE
--------------------------------------------------------------------- ---------------------------------------------------------------------
1 |QoS Des. | QoS Des. | QoS Res. 1 |QoS Des. | QoS Des. | QoS Res.
skipping to change at page 25, line 34 skipping to change at page 26, line 11
message. Parameters that can be overwritten are updated by QNEs as message. Parameters that can be overwritten are updated by QNEs as
the QUERY message travels towards the receiver. The receiver the QUERY message travels towards the receiver. The receiver
includes all QSPEC parameters arriving in the QUERY message also in includes all QSPEC parameters arriving in the QUERY message also in
the RESERVE message, with the value they had when arriving at the the RESERVE message, with the value they had when arriving at the
receiver. Again, QOSM-specific QSPEC parameters and procedures may receiver. Again, QOSM-specific QSPEC parameters and procedures may
be defined in QOSM specification documents. be defined in QOSM specification documents.
Also in this scenario, the QNI SHOULD request a RESPONSE message Also in this scenario, the QNI SHOULD request a RESPONSE message
since it will otherwise not learn what QoS is available. since it will otherwise not learn what QoS is available.
Regarding <Traffic Handling Directives>, the default rule is that all
QSPEC parameters that have been included in the RESERVE message by
the QNI are also 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 <Traffic Handling Directives> parameters are
read-only. Note that a QOSM specification may define its own
<Traffic Handling Directives> parameters and processing rules.
5.3.3 Resource Queries 5.3.3 Resource Queries
Here the QNI issues a QUERY message in order to investigate what Here the QNI issues a QUERY message in order to investigate what
resources are currently available. The QNR replies with a RESPONSE resources are currently available. The QNR replies with a RESPONSE
message. message.
ID | QUERY | RESPONSE ID | QUERY | RESPONSE
-------------------------------------------- --------------------------------------------
1 | QoS Available | QoS Available 1 | QoS Available | QoS Available
Note that the QoS Available object when traveling in the QUERY Note that the QoS Available object when traveling in the QUERY
message can be overwritten, whereas in the RESPONSE message cannot be message can be overwritten, whereas in the RESPONSE message cannot be
overwritten. overwritten.
Regarding <Traffic Handling Directives>, the default rule is that all
QSPEC parameters that have been included in the RESERVE message by
the QNI are also 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 <Traffic Handling Directives> parameters are
read-only. Note that a QOSM specification may define its own
<Traffic Handling Directives> parameters and processing rules.
5.3.4 Bidirectional Reservations 5.3.4 Bidirectional Reservations
On a QSPEC level, bidirectional reservations are no different from On a QSPEC level, bidirectional reservations are no different from
uni-directional reservations, since QSPECs for different directions uni-directional reservations, since QSPECs for different directions
never travel in the same message. never travel in the same message.
5.3.5 Preemption 5.3.5 Preemption
A flow can be preempted by a QNE based on the values of the QSPEC A flow can be preempted by a QNE based on the values of the QSPEC
Priority parameter (see Section 6.2.8). In this case the reservation Priority parameter (see Section 6.2.8). In this case the reservation
skipping to change at page 26, line 51 skipping to change at page 27, line 42
QSPEC parameters for the NSIS protocol suite are given in a separate QSPEC parameters for the NSIS protocol suite are given in a separate
NSIS extensibility document [NSIS-EXTENSIBILITY]. NSIS extensibility document [NSIS-EXTENSIBILITY].
6. QSPEC Functional Specification 6. QSPEC Functional Specification
This section defines the encodings of the QSPEC parameters. We first This section defines the encodings of the QSPEC parameters. We first
give the general QSPEC formats and then the formats of the QSPEC give the general QSPEC formats and then the formats of the QSPEC
objects and parameters. objects and parameters.
Network byte order ('big-endian') for all 16- and 32-bit integers, as 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, well as 32-bit floating point numbers, are as specified in [RFC4506,
IEEE754, NETWORK-BYTE-ORDER]. IEEE754, NETWORK-BYTE-ORDER].
6.1 General QSPEC Formats 6.1 General QSPEC Formats
The format of the QSPEC closely follows that used in GIST [GIST] and The format of the QSPEC closely follows that used in GIST [GIST] and
QoS NSLP [QoS-SIG]. Every object (and parameter) has the following QoS NSLP [QoS-SIG]. Every object (and parameter) has the following
general format: general format:
o The overall format is Type-Length-Value (in that order). o The overall format is Type-Length-Value (in that order).
skipping to change at page 45, line 15 skipping to change at page 46, line 15
7: Y.1541 QoS Class 7 7: Y.1541 QoS Class 7
The allocation policies for further values are as follows: The allocation policies for further values are as follows:
8-63: Standards Action 8-63: Standards Action
64-255: Reserved 64-255: Reserved
9. Acknowledgements 9. Acknowledgements
The authors would like to thank (in alphabetical order) David Black, The authors would like to thank (in alphabetical order) David Black,
Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger Ken Carlberg, Anna Charny, Christian Dickman, Adrian Farrel, Ruediger
Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock, Geib, Matthias Friedrich, Xiaoming Fu, Janet Gunn, Robert Hancock,
Chris Lang, Jukka Manner, An Nguyen, Dave Oran, Tom Phelan, James Chris Lang, Jukka Manner, Martin Stiemerling, An Nguyen, Dave Oran,
Polk, Alexander Sayenko, John Rosenberg, Bernd Schloer, Hannes Tom Phelan, James Polk, Alexander Sayenko, John Rosenberg, Bernd
Tschofenig, and Sven van den Bosch for their very helpful Schloer, Hannes Tschofenig, and Sven van den Bosch for their very
suggestions. helpful suggestions.
10. Normative References 10. Normative References
[3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd [3GPP-1] 3GPP TS 22.067 V7.0.0 (2006-03) Technical Specification, 3rd
Generation Partnership Project; Technical Specification Group Generation Partnership Project; Technical Specification Group
Services and System Aspects; enhanced Multi Level Precedence and Services and System Aspects; enhanced Multi Level Precedence and
Preemption service (eMLPP) - Stage 1 (Release 7). Preemption service (eMLPP) - Stage 1 (Release 7).
[3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd [3GPP-2] 3GPP TS 23.067 V7.1.0 (2006-03) Technical Specification, 3rd
Generation Partnership Project; Technical Specification Group Core Generation Partnership Project; Technical Specification Group Core
Network; enhanced Multi-Level Precedence and Preemption service Network; enhanced Multi-Level Precedence and Preemption service
(eMLPP) - Stage 2 (Release 7). (eMLPP) - Stage 2 (Release 7).
[3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd [3GPP-3] 3GPP TS 24.067 V6.0.0 (2004-12) Technical Specification, 3rd
Generation Partnership Project; Technical Specification Group Core Generation Partnership Project; Technical Specification Group Core
Network; enhanced Multi-Level Precedence and Preemption service Network; enhanced Multi-Level Precedence and Preemption service
(eMLPP) - Stage 3 (Release 6). (eMLPP) - Stage 3 (Release 6).
[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 [GIST] Schulzrinne, H., Hancock, R., "GIST: General Internet
Signaling Transport," work in progress. Signaling Transport," work in progress.
[QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service [QoS-SIG] Manner, J., et. al., "NSLP for Quality-of-Service
Signaling," work in progress. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality [RFC2212] Shenker, S., et. al., "Specification of Guaranteed Quality
of Service," September 1997. of Service," September 1997.
[RFC2215] Shenker, S., Wroclawski, J., "General Characterization [RFC2215] Shenker, S., Wroclawski, J., "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215, Sept. Parameters for Integrated Service Network Elements", RFC 2215, Sept.
1997. 1997.
[RFC2475] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3140] Black, D., et. al., "Per Hop Behavior Identification [RFC3140] Black, D., et. al., "Per Hop Behavior Identification
Codes," June 2001. Codes," June 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element," [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element,"
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC3290] Bernet, Y., et. al., "An Informal Management Model for
Diffserv Routers," RFC 3290, May 2002.
[RFC4124] Le Faucheur, F., et. al., "Protocol Extensions for Support [RFC4124] Le Faucheur, F., et. al., "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005. of Diffserv-aware MPLS Traffic Engineering," RFC 4124, June 2005.
[RFC4412] Schulzrinne, H., Polk, J., "Communications Resource [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource
Priority for the Session Initiation Protocol(SIP)," RFC 4412, Priority for the Session Initiation Protocol(SIP)," RFC 4412,
February 2006. February 2006.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard,"
RFC 4506, May 2006.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
for IP-Based Services," February 2006. for IP-Based Services," February 2006.
[Y.1571] ITU-T Recommendation Y.1571, "Admission Control Priority [Y.1571] ITU-T Recommendation Y.1571, "Admission Control Priority
Levels in Next Generation Networks," July 2006. Levels in Next Generation Networks," July 2006.
11. Informative References 11. Informative References
[DQOS] Cablelabs, "PacketCable Dynamic Quality of Service [DQOS] Cablelabs, "PacketCable Dynamic Quality of Service
Specification," CableLabs Specification PKT-SP-DQOS-I12-050812, Specification," CableLabs Specification PKT-SP-DQOS-I12-050812,
August 2005. August 2005.
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE [IEEE754] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard Standard for Binary Floating-Point Arithmetic," ANSI/IEEE Standard
754-1985, August 1985. 754-1985, August 1985.
[CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ [CL-QOSM] Kappler, C., "A QoS Model for Signaling IntServ
Controlled-Load Service with NSIS," work in progress. Controlled-Load Service with NSIS," work in progress.
[DSCP-REGISTRY] http://www.iana.org/assignments/dscp-registry
[NETWORK-BYTE-ORDER] Wikipedia, "Endianness," [NETWORK-BYTE-ORDER] Wikipedia, "Endianness,"
http://en.wikipedia.org/wiki/Endianness. http://en.wikipedia.org/wiki/Endianness.
[NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work [NSIS-EXTENSIBILITY] Loughney, J., "NSIS Extensibility Model", work
in progress. in progress.
[PHBID-CODES-REGISTRY] http://www.iana.org/assignments/phbid-codes
[Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling [Q.2630] ITU-T Recommendation Q.2630.3: "AAL Type 2 Signaling
Protocol - Capability Set 3" Sep. 2003 Protocol - Capability Set 3" Sep. 2003
[RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) [RFC2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification," RFC 2205, September 1997. -- Version 1 Functional Specification," RFC 2205, September 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs," RFC 3181, October 1998. IANA Considerations Section in RFCs," RFC 3181, October 1998.
[RFC2474] Nichols, K., et. al., "Definition of the Differentiated [RFC2474] Nichols, K., et. al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC [RFC2597] Heinanen, J., et. al., "Assured Forwarding PHB Group," RFC
2597, June 1999. 2597, June 1999.
[RFC2997] Bernet, Y., et. al., "Specification of the Null Service [RFC2997] Bernet, Y., et. al., "Specification of the Null Service
Type," RFC 2997, November 2000. Type," RFC 2997, November 2000.
[RFC3140] Black, D., et. al., "Per Hop Behavior Identification [RFC3140] Black, D., et. al., "Per Hop Behavior Identification
Codes," RFC 3140, June 2001. Codes," RFC 3140, June 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 [RFC3393] Demichelis, C., Chimento, P., "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002. Metric for IP Performance Metrics (IPPM), RFC 3393, November 2002.
[RFC3564] Le Faucheur, F., et. al., Requirements for Support of [RFC3564] Le Faucheur, F., et. al., Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering, RFC 3564, Differentiated Services-aware MPLS Traffic Engineering, RFC 3564,
July 2003 July 2003
[RFC3726] Brunner, M., et. al., "Requirements for Signaling [RFC3726] Brunner, M., et. al., "Requirements for Signaling
Protocols", RFC 3726, April 2004. Protocols", RFC 3726, April 2004.
[RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management [RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management
in Diffserv QOS Model," work in progress. in Diffserv QOS Model," work in progress.
[VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion [VERTICAL-INTERFACE] Dolly, M., Tarapore, P., Sayers, S., "Discussion
skipping to change at page 47, line 35 skipping to change at page 48, line 35
Attila Bader (Editor) Attila Bader (Editor)
Traffic Lab Traffic Lab
Ericsson Research Ericsson Research
Ericsson Hungary Ltd. Ericsson Hungary Ltd.
Laborc u. 1 H-1037 Laborc u. 1 H-1037
Budapest Hungary Budapest Hungary
Email: Attila.Bader@ericsson.com Email: Attila.Bader@ericsson.com
Cornelia Kappler (Editor) Cornelia Kappler (Editor)
Siemens GmbH&Co KG Siemens Networks GmbH & Co KG
Siemensdamm 62 Siemensdamm 62
Berlin 13627 Berlin 13627
Germany Germany
Email: cornelia.kappler@siemens.com Email: cornelia.kappler@siemens.com
David R. Oran (Editor) David R. Oran (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
7 Ladyslipper Lane 7 Ladyslipper Lane
Acton, MA 01720, USA Acton, MA 01720, USA
Email: oran@cisco.com Email: oran@cisco.com
skipping to change at page 52, line 26 skipping to change at page 53, line 26
new RMF functions new RMF functions
- Section 5.1 added text that both mechanisms can be used - Section 5.1 added text that both mechanisms can be used
simultaneously: a) tunneling a QSPEC through a local domain and b) simultaneously: a) tunneling a QSPEC through a local domain and b)
defining a local QSPEC and encapsulating the initiator QSPEC defining a local QSPEC and encapsulating the initiator QSPEC
- Section 4.1 added text that signaling functionality is only defined - Section 4.1 added text that signaling functionality is only defined
by the QoS NSLP document by the QoS NSLP document
- Section 4.1 added text that QOSMs are free to extend QSPECs by - Section 4.1 added text that QOSMs are free to extend QSPECs by
adding parameters but are not permitted to reinterpret or redefine adding parameters but are not permitted to reinterpret or redefine
the standard QSPEC parameters specified in this document the standard QSPEC parameters specified in this document
Version -15:
- editorial revisions made to Sections 4.1, 4.3.3, 5.3.1, 5.3.2, and
5.3.3 according to agreements on NSIS discussion list archive.
B.2 Open Issues B.2 Open Issues
None. None.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
 End of changes. 28 change blocks. 
70 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/