draft-ietf-dime-qos-parameters-06.txt   draft-ietf-dime-qos-parameters-07.txt 
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera Extensions (DIME) TeliaSonera
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks Intended status: Standards Track Nokia Siemens Networks
Expires: November 27, 2008 May 26, 2008 Expires: May 5, 2009 November 1, 2008
Quality of Service Parameters for Usage with the AAA Framework Quality of Service Parameters for Usage with the AAA Framework
draft-ietf-dime-qos-parameters-06.txt draft-ietf-dime-qos-parameters-07.txt
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2008. This Internet-Draft will expire on May 5, 2009.
Abstract Abstract
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and that can be reused for conveying QoS information within RADIUS and
Diameter. Diameter.
The payloads used to carry these QoS parameters are opaque for the The payloads used to carry these QoS parameters are opaque for the
AAA client and the AAA server itself and interpreted by the AAA client and the AAA server itself and interpreted by the
respective Resource Management Function. respective Resource Management Function.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5
3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5
4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5
4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5
4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6
4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7
4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7
4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8
4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8
4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 8
4.9. Preemption Priority amp; Defending Priority Parameters . . 9 4.9. Preemption Priority amp; Defending Priority Parameters . . 9
4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 9
4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10
4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11
4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12
4.13.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . 12
4.13.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 12
4.13.3. Case 3: Experimental or Local Use PHBs . . . . . . . 13
4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13
4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17 6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 16
6.4. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.5. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and that can be reused for conveying QoS information within RADIUS and
Diameter. Diameter.
The payloads used to carry these QoS parameters are opaque for the The payloads used to carry these QoS parameters are opaque for the
AAA client and the AAA server itself and interpreted by the AAA client and the AAA server itself and interpreted by the
respective Resource Management Function. respective Resource Management Function.
skipping to change at page 3, line 43 skipping to change at page 3, line 43
TMOD parameter is a mathematically complete way to describe the TMOD parameter is a mathematically complete way to describe the
traffic source. If, for example, TMOD is set to specify bandwidth traffic source. If, for example, TMOD is set to specify bandwidth
only, then set r = peak rate = p, b = large, m = large. As another only, then set r = peak rate = p, b = large, m = large. As another
example if TMOD is set for TCP traffic, then set r = average rate, b example if TMOD is set for TCP traffic, then set r = average rate, b
= large, p = large. = large, p = large.
3.2. Constraints Parameters 3.2. Constraints Parameters
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS
parameters describing the desired path latency, path jitter and path parameters describing the desired path latency, path jitter and path
bit error rate respectively. error rate respectively.
The <Path Latency> parameter refers to the accumulated latency of the The <Path Latency> parameter refers to the accumulated latency of the
packet forwarding process associated with each QoS aware node along packet forwarding process associated with each QoS aware node along
the path, where the latency is defined to be the mean packet delay the path, where the latency is defined to be the mean packet delay
added by each such node. This delay results from speed-of-light added by each such node. This delay results from speed-of-light
propagation delay, from packet processing limitations, or both. The propagation delay, from packet processing limitations, or both. The
mean delay reflects the variable queuing delay that may be present. mean delay reflects the variable queuing delay that may be present.
The purpose of this parameter is to provide a minimum path latency The purpose of this parameter is to provide a minimum path latency
for use with services which provide estimates or bounds on additional for use with services which provide estimates or bounds on additional
skipping to change at page 4, line 30 skipping to change at page 4, line 30
jitter results from packet processing limitations, and includes any jitter results from packet processing limitations, and includes any
variable queuing delay which may be present. The purpose of this variable queuing delay which may be present. The purpose of this
parameter is to provide a nominal path jitter for use with services parameter is to provide a nominal path jitter for use with services
that provide estimates or bounds on additional path delay [RFC2212]. that provide estimates or bounds on additional path delay [RFC2212].
The procedures for collecting path jitter information are outside the The procedures for collecting path jitter information are outside the
scope of this document. scope of this document.
The <Path PLR> parameter refers to the accumulated packet loss rate The <Path PLR> parameter refers to the accumulated packet loss rate
(PLR) of the packet forwarding process associated with each QoS aware (PLR) of the packet forwarding process associated with each QoS aware
node along the path where the PLR is defined to be the PLR added by node along the path where the path PLR is defined to be the PLR added
each such node. by each such node.
The <Path PER> parameter refers to the accumulated packet error rate The <Path PER> parameter refers to the accumulated packet error rate
(PER) of the packet forwarding process associated with each QoS aware (PER) of the packet forwarding process associated with each QoS aware
node, where the PER is defined to be the PER added by each such node. node, where the path PER is defined to be the PER added by each such
node.
The <Slack Term> parameter refers to the difference between desired The <Slack Term> parameter refers to the difference between desired
delay and delay obtained by using bandwidth reservation, and which is delay and delay obtained by using bandwidth reservation, and which is
used to reduce the resource reservation for a flow [RFC2212]. used to reduce the resource reservation for a flow [RFC2212].
The <Preemption Priority> parameter refers to the priority of the new The <Preemption Priority> parameter refers to the priority of the new
flow compared with the <Defending Priority> of previously admitted flow compared with the <Defending Priority> of previously admitted
flows. Once a flow is admitted, the preemption priority becomes flows. Once a flow is admitted, the preemption priority becomes
irrelevant. The <Defending Priority> parameter is used to compare irrelevant. The <Defending Priority> parameter is used to compare
with the preemption priority of new flows. For any specific flow, with the preemption priority of new flows. For any specific flow,
its preemption priority MUST always be less than or equal to the its 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.
3.3. Traffic Handling Directives 3.3. Traffic Handling Directives
The <Excess Treatment> parameter describes how a QoS aware node will The <Excess Treatment> parameter describes how a QoS aware node will
process excess traffic, that is, out-of-profile traffic. Excess process excess traffic, that is, out-of-profile traffic. Dopping,
traffic MAY be dropped, shaped and/or remarked. shaping or remarking are possible actions.
3.4. Traffic Classifiers 3.4. Traffic Classifiers
Resource reservations might refer to a packet processing with a Resource reservations might refer to a packet processing with a
particular DiffServ per-hop behavior (PHB) [RFC2475] or to a particular DiffServ per-hop behavior (PHB) [RFC2475] or to a
particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS
traffic engineering (DSTE) class type [RFC3564], [RFC4124]. traffic engineering (DSTE) class type [RFC3564], [RFC4124].
4. Parameter Encoding 4. Parameter Encoding
skipping to change at page 5, line 39 skipping to change at page 5, line 39
M Flag: When set indicates the subsequent parameter MUST be M Flag: When set indicates the subsequent parameter MUST be
interpreted. If the M flag is set and the parameter is not interpreted. If the M flag is set and the parameter is not
understood then it leads to an error. If the M flag is not understood then it leads to an error. If the M flag is not
set and then not understood then it can be ignored. set and then not understood then it can be ignored.
The r bits are reserved. The r bits are reserved.
Parameter ID: Assigned to each individual QoS parameter Parameter ID: Assigned to each individual QoS parameter
Length: Indicates the length of the subsequent data in 32-bit words.
4.2. TMOD-1 Parameter 4.2. TMOD-1 Parameter
<TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215] <TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215]
The above notation means that the 4 <TMOD-1> sub-parameters must be The above notation means that the 4 <TMOD-1> sub-parameters must be
carried in the <TMOD-1> parameter. The coding for the <TMOD-1> carried in the <TMOD-1> parameter. The coding for the <TMOD-1>
parameter is as follows: parameter is as follows:
0 1 2 3 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 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
skipping to change at page 7, line 31 skipping to change at page 7, line 31
|M|r|r|r| 3 |r|r|r|r| 1 | |M|r|r|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) | | Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency is a single 32-bit integer in network byte order. The Path Latency is a single 32-bit integer in network byte order.
The composition rule for the <Path Latency> parameter is summation The composition rule for the <Path Latency> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The latencies are 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 average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero. resolution less than one microsecond MUST set unused digits to zero.
The total latency added across all QoS aware nodes along the path can
range as high as (2**32)-2.
4.5. Path Jitter Parameter 4.5. Path Jitter Parameter
The coding for the <Path Jitter> parameter is as follows: The coding for the <Path Jitter> parameter is as follows:
0 1 2 3 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 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|r|r|r| 4 |r|r|r|r| 4 | |M|r|r|r| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
skipping to change at page 8, line 27 skipping to change at page 8, line 25
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 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|r|r|r| 5 |r|r|r|r| 1 | |M|r|r|r| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) | | Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PLR is a single 32-bit single precision IEEE floating point The Path PLR is a single 32-bit single precision IEEE floating point
number in network byte order. The PLRs are reported in units of number in network byte order. The PLRs are reported in units of
10^-11. A system with resolution less than one microsecond MUST set 10^-11. A system with resolution less than one microsecond MUST set
unused digits to zero. The total PLR added across all QoS aware unused digits to zero.
nodes can range as high as 10^-1.
4.7. Path PER Parameter 4.7. Path PER Parameter
The coding for the <Path PLR> parameter is as follows: The coding for the <Path PER> parameter is as follows:
0 1 2 3 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 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|r|r|r| 6 |r|r|r|r| 1 | |M|r|r|r| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) | | Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PER is a single 32-bit single precision IEEE floating point The Path PER is a single 32-bit single precision IEEE floating point
number in network byte order. The PERs are reported in units of number in network byte order. The PERs are reported in units of
10^-11. A system with resolution less than one microsecond MUST set 10^-11. A system with resolution less than one microsecond MUST set
unused digits to zero. The total PER added across all QoS aware unused digits to zero.
nodes can range as high as 10^-1.
4.8. Slack Term Parameter 4.8. Slack Term Parameter
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC2212], [RFC2215]. The coding for the <Path PLR> parameter is as [RFC2212], [RFC2215]. The coding for the <Slack Term> parameter is
follows: as follows:
0 1 2 3 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 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|r|r|r| 7 |r|r|r|r| 1 | |M|r|r|r| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term [S] (32-bit integer) | | Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Slack Term parameter S is a 32-bit integer value in network byte The Slack Term parameter S is a 32-bit integer value in network byte
order and is measured in microseconds. S is represented as a 32-bit order and is measured in microseconds. S is represented as a 32-bit
integer. Its value can range from 0 to (2**32)-1 microseconds. integer.
4.9. Preemption Priority amp; Defending Priority Parameters 4.9. Preemption Priority amp; Defending Priority Parameters
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC3181]. [RFC3181].
The coding for the <Preemption Priority> & <Defending Priority> sub- The coding for the <Preemption Priority> & <Defending Priority> sub-
parameters is as follows: parameters is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 10, line 44 skipping to change at page 10, line 40
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
parameter is as follows: parameter is as follows:
0 1 2 3 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 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|r|r|r| 10 |r|r|r|r| 1 | |M|r|r|r| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALRP Namespace | ALRP Priority | (Reserved) | | ALRP Namespace | (Reserved) | ALRP Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ALRP Namespace field is a 16 bits long unsigned integer in The ALRP Namespace field is a 16 bits long unsigned integer in
network byte order and the ALRP Priority field is an 8 bit long network byte order and the ALRP Priority field is an 8 bit long
unsigned integer in network byte order containing the specific unsigned integer in network byte order containing the specific
priority value. priority value.
[RFC4412] defines a resource priority header and established the [RFC4412] defines a resource priority header and established the
initial registry; that registry was later extended by initial registry; the encoding of the values in that registry was
[I-D.ietf-tsvwg-emergency-rsvp]. later extended by [I-D.ietf-tsvwg-emergency-rsvp].
4.12. Excess Treatment Parameter 4.12. Excess Treatment Parameter
The coding for the <Excess Treatment> parameter is as follows: The coding for the <Excess Treatment> parameter is as follows:
0 1 2 3 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 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|r|r|r| 11 |r|r|r|r| 1 | |M|r|r|r| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 31 skipping to change at page 11, line 27
Excess Treatment (8 bit unsigned integer value in network byte Excess Treatment (8 bit unsigned integer value in network byte
order): Indicates how the QoS aware node should process out-of- order): Indicates how the QoS aware node should process out-of-
profile traffic, that is, traffic not covered by the <Traffic> profile traffic, that is, traffic not covered by the <Traffic>
parameter. Allowed values are as follows: parameter. Allowed values are as follows:
0: drop 0: drop
1: shape 1: shape
2: remark 2: remark
3: no metering or policing is permitted 3: no metering or policing is permitted
Further values can be registered as described in Section 6.3.
The default excess treatment in case that none is specified is that The default excess treatment in case that none is specified is that
there are no guarantees to excess traffic, i.e., a QoS aware node can there are no guarantees to excess traffic, i.e., a QoS aware node can
do what it finds suitable. do what it finds suitable.
When excess treatment is set to 'drop', all marked traffic MUST be When excess treatment is set to 'drop', all marked traffic MUST be
dropped by a QoS aware node. dropped by a QoS aware node.
When excess treatment is set to 'shape', it is expected that the QoS When excess treatment is set to 'shape', it is expected that the QoS
Desired object carries a TMOD parameter. Excess traffic is to be Desired object carries a TMOD parameter. Excess traffic is to be
shaped to this TMOD. When the shaping causes unbounded queue growth shaped to this TMOD. When the shaping causes unbounded queue growth
skipping to change at page 12, line 17 skipping to change at page 12, line 14
with special care so that excess traffic should not cause a problem. with special care so that excess traffic should not cause a problem.
To request the Null Meter [RFC3290] is especially strong, and should To request the Null Meter [RFC3290] is especially strong, and should
be used with caution. be used with caution.
The Remark Value is an 8 bit unsigned integer value in network byte The Remark Value is an 8 bit unsigned integer value in network byte
order. order.
4.13. PHB Class Parameter 4.13. PHB Class Parameter
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC3140]. The coding for the <PHB Class> parameter is as follows: [RFC3140]. The registries needed for usage with [RFC3140] already
exist and hence no new registry needs to be created by this document.
The coding for the <PHB Class> parameter is as follows and three
different cases need to be differentiated. The header format is
shown in the subsequent figure below and is used by all three cases
defined in the subsequent sub-sections.
0 1 2 3 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 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|r|r|r| 12 |r|r|r|r| 1 | |M|r|r|r| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4.13.1. Case 1: Single PHB
As prescribed in [RFC3140], the encoding for a single PHB is the As prescribed in [RFC3140], the encoding for a single PHB is the
recommended DSCP value for that PHB, left-justified in the 16 bit recommended DSCP value for that PHB, left-justified in the 16 bit
field, with bits 6 through 15 set to zero. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4.13.2. Case 2: Set of PHBs
The encoding for a set of PHBs is the numerically smallest of the set The encoding for a set of PHBs is the numerically smallest of the set
of encodings for the various PHBs in the set, with bit 14 set to 1. of encodings for the various PHBs in the set, with bit 14 set to 1.
(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with
bit 14 set to 1.) bit 14 set to 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 4.13.3. Case 3: Experimental or Local Use PHBs
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
PHBs not defined by standards action, i.e., experimental or local use PHBs not defined by standards action, i.e., experimental or local use
PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB
identification code, assigned by the IANA, is placed left-justified identification code, assigned by the IANA, is placed left-justified
in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a
single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 X 0|
+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB Bits 12 and 13 are reserved either for expansion of the PHB
identification code, or for other use, at some point in the future. identification code, or for other use, at some point in the future.
In both cases, when a single PHBID is used to identify a set of PHBs In both cases, when a single PHBID is used to identify a set of PHBs
(i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB
Scheduling Class (i.e., use of PHBs from the set MUST NOT cause Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
intra-microflow traffic reordering when different PHBs from the set intra-microflow traffic reordering when different PHBs from the set
are applied to traffic in the same microflow). The set of AF1x PHBs are applied to traffic in the same microflow). The set of AF1x PHBs
[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that
do not constitute a PHB Scheduling Class can be identified by using do not constitute a PHB Scheduling Class can be identified by using
more than one PHBID. more than one PHBID.
The registries needed to use [RFC3140] already exist. Hence, no new 0 1 2 3
registry needs to be created for this purpose. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 1 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4.14. DSTE Class Type Parameter 4.14. DSTE Class Type Parameter
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC4124]. The coding for the <DSTE Class Type> parameter is as [RFC4124]. The coding for the <DSTE Class Type> parameter is as
follows: follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 17 skipping to change at page 14, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 14 |r|r|r|r| 1 | |M|r|r|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) | |Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently
allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means
that the <Y.1541 QoS Class> parameter is not used. that the <Y.1541 QoS Class> parameter is not used.
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 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.
5. Extensibility 5. Extensibility
This document is designed with extensibility in mind given that This document is designed with extensibility in mind given that
different organizations and groups are used to define their own different organizations and groups are used to define their own
Quality of Service parameters. This document provides an initial QoS Quality of Service parameters. This document provides an initial QoS
profile with common set of parameters. Ideally, these parameters profile with common set of parameters. Ideally, these parameters
should be used whenever possible but there are cases where additional should be used whenever possible but there are cases where additional
parameters might be needed, or where the parameters specified in this parameters might be needed, or where the parameters specified in this
document are used with a different semantic. In this case it is document are used with a different semantic. In this case it is
advisable to define a new QoS profile that may consist of new advisable to define a new QoS profile that may consist of new
parameters in addition to parameters defined in this document or an parameters in addition to parameters defined in this document or an
entirely different set of parameters. entirely different set of parameters.
To enable the definition of new QoS profiles a 8 octet registry is To enable the definition of new QoS profiles a 8 octet registry is
defined field that is represented by a 4-octet vendor and 4-octet defined field that is represented by a 4-octet vendor and 4-octet
specifier field. The vendor field indicates the type as either specifier field. The vendor field indicates the type as either
standards-specified or vendor-specific. If the four octets of the standards-specified or vendor-specific. If the four octets of the
vendor field are 0x00000000, then the value is standards-specified vendor field are 0x00000000, then the value is standards-specified
and the registry is maintained by IANA, and any other value and the registry is maintained by IANA as Enterprise Numbers defined
represents a vendor-specific Object Identifier (OID). IANA created in [RFC2578], and any other value represents a vendor-specific Object
registry is split into two value ranges; one range uses the Identifier (OID). IANA created registry is split into two value
"Standards Action" and the second range uses "Specification Required" ranges; one range uses the "Standards Action" and the second range
allocation policy. The latter range is meant to be used by uses "Specification Required" allocation policy. The latter range is
organizations outside the IETF. meant to be used by organizations outside the IETF.
6. IANA Considerations 6. IANA Considerations
This section defines the registries and initial codepoint This section defines the registries and initial codepoint
assignments, in accordance with BCP 26 RFC 5226 [RFC5226]. It also assignments, in accordance with BCP 26 RFC 5226 [RFC5226]. It also
defines the procedural requirements to be followed by IANA in defines the procedural requirements to be followed by IANA in
allocating new codepoints. allocating new codepoints.
IANA is requested to create the following registries listed in the IANA is requested to create the following registries listed in the
subsections below. subsections below.
skipping to change at page 17, line 45 skipping to change at page 16, line 45
Excess Treatment Value 2: remark Excess Treatment Value 2: remark
Excess Treatment Value3: no metering or policing is permitted Excess Treatment Value3: no metering or policing is permitted
Excess Treatment Values 4-63: Standards Action Excess Treatment Values 4-63: Standards Action
Excess Treatment Value 64-255: Reserved Excess Treatment Value 64-255: Reserved
The 8 bit Remark Value allocation policies are as follows: The 8 bit Remark Value allocation policies are as follows:
0-63: Specification Required 0-63: Specification Required
64-127: Private/Experimental Use 64-127: Private/Experimental Use
128-255: Reserved 128-255: Reserved
6.4. DSTE Class Type Parameter
The DSTE Class Type parameter refers to an 8 bit long field.
The following values are allocated by this specification:
DSTE Class Type Value 0: DSTE Class Type 0
DSTE Class Type Value 1: DSTE Class Type 1
DSTE Class Type Value 2: DSTE Class Type 2
DSTE Class Type Value 3: DSTE Class Type 3
DSTE Class Type Value 4: DSTE Class Type 4
DSTE Class Type Value 5: DSTE Class Type 5
DSTE Class Type Value 6: DSTE Class Type 6
DSTE Class Type Value 7: DSTE Class Type 7
DSTE Class Type Values 8-63: Standards Action
DSTE Class Type Values 64-255: Reserved
6.5. Y.1541 QoS Class Parameter
The Y.1541 QoS Class parameter refers to an 8 bit long field.
The following values are allocated by this specification:
Y.1541 QoS Class Value 0: Y.1541 QoS Class 0
Y.1541 QoS Class Value 1: Y.1541 QoS Class 1
Y.1541 QoS Class Value 2: Y.1541 QoS Class 2
Y.1541 QoS Class Value 3: Y.1541 QoS Class 3
Y.1541 QoS Class Value 4: Y.1541 QoS Class 4
Y.1541 QoS Class Value 5: Y.1541 QoS Class 5
Y.1541 QoS Class Value 6: Y.1541 QoS Class 6
Y.1541 QoS Class Value 7: Y.1541 QoS Class 7
Y.1541 QoS Class Values 8-63: Standards Action
Y.1541 QoS Class Values 64-255: Reserved
The ALRP Namespace and ALRP Priority field inside the ALRP Parameter The ALRP Namespace and ALRP Priority field inside the ALRP Parameter
take their values from the registry created by [RFC4412] and extended take their values from the registry created by [RFC4412] and extended
with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are
required by IANA by this specification. required by IANA by this specification.
7. Security Considerations 7. Security Considerations
This document does not raise any security concerns as it only defines This document does not raise any security concerns as it only defines
QoS parameters. QoS parameters.
skipping to change at page 19, line 7 skipping to change at page 17, line 23
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the
NSIS working group chairs (John Loughney and Martin Stiemerling) and NSIS working group chairs (John Loughney and Martin Stiemerling) and
the former Transport Area Directors (Allison Mankin, Jon Peterson) the former Transport Area Directors (Allison Mankin, Jon Peterson)
for their help. for their help.
We would like to thank Francois Le Faucheur, John Loughney, Martin We would like to thank Francois Le Faucheur, John Loughney, Martin
Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars
Eggert, and Magnus Westerlund for their help with resolving problems Eggert, and Magnus Westerlund for their help with resolving problems
regarding the Admission Priority and the ALRP parameter. regarding the Admission Priority and the ALRP parameter.
We would like to thank Dan Romascanu for his detailed Area Director
review comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tsvwg-emergency-rsvp] [I-D.ietf-tsvwg-emergency-rsvp]
Faucheur, F., Polk, J., and K. Carlberg, "Resource Faucheur, F., Polk, J., and K. Carlberg, "Resource
ReSerVation Protovol (RSVP) Extensions for Emergency ReSerVation Protovol (RSVP) Extensions for Emergency
Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in
progress), May 2008. progress), October 2008.
[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., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, of Guaranteed Quality of Service", RFC 2212,
September 1997. September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", Parameters for Integrated Service Network Elements",
RFC 2215, September 1997. RFC 2215, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, "Per Hop Behavior Identification Codes", RFC 3140,
June 2001. 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.
skipping to change at page 20, line 11 skipping to change at page 18, line 34
November 2002. November 2002.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005. June 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006. RFC 4412, February 2006.
[Y.1541] "Network Performance Objectives for IP-Based Services", , [Y.1541] "ITU-T Recommendation Y.1541, Network Performance
2006. Objectives for IP-Based Services", , 2006.
[Y.1571] "Admission Control Priority Levels in Next Generation
Networks", , July 2006.
9.2. Informative References 9.2. Informative References
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-20 (work in QSPEC Template", draft-ietf-nsis-qspec-20 (work in
progress), April 2008. progress), April 2008.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
skipping to change at page 20, line 40 skipping to change at page 19, line 13
May 2002. May 2002.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering", Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003. RFC 3564, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[Y.1540] "Internet Protocol Data Communication Service - IP Packet [Y.1540] "ITU-T Recommendation Y.1540, Internet Protocol Data
Transfer and Availability Performance Parameters", , Communication Service - IP Packet Transfer and
December 2002. Availability Performance Parameters", , December 2002.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
TeliaSonera TeliaSonera
Teollisuuskatu 13 Teollisuuskatu 13
Sonera FIN-00051 Sonera FIN-00051
Finland Finland
Email: jouni.korhonen@teliasonera.com Email: jouni.korhonen@teliasonera.com
 End of changes. 37 change blocks. 
152 lines changed or deleted 87 lines changed or added

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