draft-ietf-dime-qos-parameters-01.txt   draft-ietf-dime-qos-parameters-02.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: April 1, 2008 September 29, 2007 Expires: August 28, 2008 February 25, 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-01.txt draft-ietf-dime-qos-parameters-02.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 April 1, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 10
4.11. RPH Priority Parameter . . . . . . . . . . . . . . . . . . 10 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10
4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 12 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11
4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 13 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12
4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 14 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13
4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Admission Priority Parameter . . . . . . . . . . . . . . . 17
6.4. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17
6.5. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 18
6.6. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 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 9, line 19 skipping to change at page 9, line 19
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 nonnegative and is measured in The Slack Term parameter S is a 32-bit integer value in network byte
microseconds. S is represented as a 32-bit integer. Its value can order and is measured in microseconds. S is represented as a 32-bit
range from 0 to (2**32)-1 microseconds. integer. Its value can range from 0 to (2**32)-1 microseconds.
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 9, line 48 skipping to change at page 9, line 48
Preemption Priority: The priority of the new flow compared with the Preemption Priority: The priority of the new flow compared with the
defending priority of previously admitted flows. Higher values defending priority of previously admitted flows. Higher values
represent higher priority. represent higher priority.
Defending Priority: Once a flow is admitted, the preemption priority Defending Priority: Once a flow is admitted, the preemption priority
becomes irrelevant. Instead, its defending priority is used to becomes irrelevant. Instead, its defending priority is used to
compare with the preemption priority of new flows. compare with the preemption priority of new flows.
As specified in [RFC3181], <Preemption Priority> & <Defending As specified in [RFC3181], <Preemption Priority> & <Defending
Priority> are 16-bit integer values. Priority> are 16-bit integer values. They are represented in network
byte order.
4.10. Admission Priority Parameter 4.10. Admission Priority 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
[Y.1571]. The coding for the <Admission Priority> parameter is as [Y.1571]. The coding for the <Admission Priority> 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 9 |r|r|r|r| 1 | |M|r|r|r| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admis.Priority| (Reserved) | | Admis.Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Admis.Priority' field is a 8 bit unsigned integer in network
byte order.
High priority flows, normal priority flows, and best-effort priority High priority flows, normal priority flows, and best-effort priority
flows can have access to resources depending on their admission flows can have access to resources depending on their admission
priority value as follows: priority value as follows:
Admission Priority: Admission Priority:
0 - best-effort priority flow 0 - best-effort priority flow
1 - normal priority flow 1 - normal priority flow
2 - high priority flow 2 - high priority flow
255 - not used 255 - not used
A reservation without an <Admission Priority> parameter (i.e., set to A reservation without an <Admission Priority> parameter (i.e., set to
255) MUST be treated as a reservation with an <Admission Priority> = 255) MUST be treated as a reservation with an <Admission Priority> =
1. 1.
4.11. RPH Priority Parameter 4.11. Application-Level Resource Priority (ALRP) 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
[RFC4412]. The coding for the <RPH Priority> parameter is as [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) | | ALRP Namespace | ALRP Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
unsigned integer in network byte order containing the specific
priority value.
[RFC4412] defines a resource priority header (RPH) with parameters [RFC4412] defines a resource priority header and established the
"RPH Namespace" and "RPH Priority" combination, and if populated is initial registry; that registry was later extended by
applicable only to flows with high admission priority, as follows: [I-D.ietf-tsvwg-emergency-rsvp].
RPH Namespace:
0 - dsn
1 - drsn
2 - q735
3 - ets
4 - wps
255 - not used
Each namespace has a finite list of relative priority-values. Each
is listed here in the order of lowest priority to highest priority.
RPH Priority:
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
For the 4 priority parameters, the following cases are permissible
(procedures specified in references):
1 parameter: <Admission Priority> [Y.1571]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]
It is permissible to have <Admission Priority> without <RPH
Priority>, but not permissible to have <RPH Priority> without
<Admission Priority> (alternatively <RPH Priority> is ignored in
instances without <Admission Priority>).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt | Remark Value | Reserved | | Excess Trtmnt | Remark Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Excess Treatment: Indicates how the QoS aware node should process Excess Treatment (8 bit unsigned integer value in network byte
out-of-profile traffic, that is, traffic not covered by the <Traffic> order): Indicates how the QoS aware node should process out-of-
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
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.
skipping to change at page 13, line 11 skipping to change at page 12, line 15
packets arrive marked as belonging to a certain QoS class, and when packets arrive marked as belonging to a certain QoS class, and when
they are identified as excess, they should then be remarked to a they are identified as excess, they should then be remarked to a
different QoS Class. different QoS Class.
If 'no metering or policing is permitted' is signaled, the QoS aware If 'no metering or policing is permitted' is signaled, the QoS aware
node should accept the excess treatment parameter set by the sender node should accept the excess treatment parameter set by the sender
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
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 coding for the <PHB Class> 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| 12 |r|r|r|r| 1 | |M|r|r|r| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 39 skipping to change at page 15, line 46
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, and any other value
represents a vendor-specific Object Identifier (OID). IANA created represents a vendor-specific Object Identifier (OID). IANA created
registry is split into two value ranges; one range uses the registry is split into two value ranges; one range uses the
"Standards Action" and the second range uses "Specification Required" "Standards Action" and the second range uses "Specification Required"
allocation policy. The latter range is meant to be used by allocation policy. The latter range is meant to be used by
organizations outside the IETF. organizations outside the IETF.
6. IANA Considerations 6. IANA Considerations
This document reuses the namespace created in [I-D.ietf-nsis-qspec] This section defines the registries and initial codepoint
for assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also
1. Admission Priority Parameter defines the procedural requirements to be followed by IANA in
2. RPH Namespace Parameter allocating new codepoints.
3. RPH Priority Parameter
4. Excess Treatment Parameter
5. DSTE Class Type Parameter
6. Y.1541 QoS Class Parameter
IANA is requested to create the following registries: QoS Profile (32 IANA is requested to create the following registries listed in the
bits), and Parameter ID (12 bits) subsections below.
6.1. QoS Profile 6.1. QoS Profile
The QoS Profile refers to a 64 bit long field that is represented by The QoS Profile refers to a 64 bit long field that is represented by
a 4-octet vendor and 4-octet specifier field. The vendor field a 4-octet vendor and 4-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If the four octets of the vendor field are 0x00000000, then the value If the four octets of the vendor field are 0x00000000, then the value
is standards-specified and the registry is maintained by IANA, and is standards-specified and the registry is maintained by IANA, and
any other value represents a vendor-specific Object Identifier (OID). any other value represents a vendor-specific Object Identifier (OID).
skipping to change at page 18, line 14 skipping to change at page 17, line 14
(0): <TMOD-1> (0): <TMOD-1>
(1): <TMOD-2> (1): <TMOD-2>
(2): <Path Latency> (2): <Path Latency>
(3): <Path Jitter> (3): <Path Jitter>
(4): <Path PLR> (4): <Path PLR>
(5): <Path PER> (5): <Path PER>
(6): <Slack Term> (6): <Slack Term>
(7): <Preemption Priority> & <Defending Priority> (7): <Preemption Priority> & <Defending Priority>
(8): <Admission Priority> (8): <Admission Priority>
(9): <RPH Priority> (9): <ALRP>
(10): <Excess Treatment> (10): <Excess Treatment>
(11): <PHB Class> (11): <PHB Class>
(12): <DSTE Class Type> (12): <DSTE Class Type>
(13): <Y.1541 QoS Class> (13): <Y.1541 QoS Class>
The allocation policies for further values are as follows: The allocation policies for further values are as follows:
14-127: Standards Action 14-127: Standards Action
128-255: Private/Experimental Use 128-255: Private/Experimental Use
255-4095: Specification Required 255-4095: Specification Required
A standards track document is required to depreciate, delete, or A standards track document is required to depreciate, delete, or
modify existing Parameter IDs. modify existing Parameter IDs.
6.3. Admission Priority Parameter
The Admission Priority parameter refers to a 8 bit long field.
The following values are allocated by this specification:
Admission Priority 0: best-effort priority flow
Admission Priority 1: normal priority flow
Admission Priority 2: high priority flow
Admission Priority 3-63: Standards Action
Admission Priority 64-255: Reserved
6.4. Excess Treatment Parameter
The Excess Treatment parameter refers to an 8 bit long field.
The following values are allocated by this specification:
Excess Treatment Value 0: drop
Excess Treatment Value 1: shape
Excess Treatment Value 2: remark
Excess Treatment Value3: no metering or policing is permitted
Excess Treatment Values 4-63: Standards Action
Excess Treatment Value 64-255: Reserved
The 8 bit Remark Value allocation policies are as follows:
0-63: Specification Required
64-127: Private/Experimental Use
128-255: Reserved
6.5. 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.6. 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
take their values from the registry created by [RFC4412] and extended
with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are
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.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec]
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 Manking, Jon Peterson) the former Transport Area Directors (Allison Mankin, Jon Peterson)
for their help. for their help.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tsvwg-emergency-rsvp]
Faucheur, F., "Resource ReSerVation Protovol (RSVP)
Extensions for Emergency Services",
draft-ietf-tsvwg-emergency-rsvp-05 (work in progress),
January 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.
skipping to change at page 20, line 9 skipping to change at page 20, line 31
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] "Network Performance Objectives for IP-Based Services", ,
2006. 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, J., "QoS NSLP QSPEC Template", Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
draft-ietf-nsis-qspec-17 (work in progress), July 2007. QSPEC Template", draft-ietf-nsis-qspec-18 (work in
progress), October 2007.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[Y.1540] "Internet Protocol Data Communication Service - IP Packet [Y.1540] "Internet Protocol Data Communication Service - IP Packet
Transfer and Availability Performance Parameters", , Transfer and Availability Performance Parameters", ,
December 2002. December 2002.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
TeliaSonera TeliaSonera
Teollisuuskatu 13 Teollisuuskatu 13
skipping to change at page 21, line 7 skipping to change at page 22, line 7
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 29 change blocks. 
96 lines changed or deleted 137 lines changed or added

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