--- 1/draft-ietf-dime-qos-parameters-01.txt 2008-02-25 10:12:19.000000000 +0100 +++ 2/draft-ietf-dime-qos-parameters-02.txt 2008-02-25 10:12:19.000000000 +0100 @@ -1,19 +1,19 @@ Diameter Maintenance and J. Korhonen, Ed. Extensions (DIME) TeliaSonera Internet-Draft H. Tschofenig 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 - draft-ietf-dime-qos-parameters-01.txt + draft-ietf-dime-qos-parameters-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,25 +24,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 1, 2008. + This Internet-Draft will expire on August 28, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. @@ -60,36 +60,40 @@ 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 4.9. Preemption Priority amp; Defending Priority Parameters . . 9 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 - 4.11. RPH Priority Parameter . . . . . . . . . . . . . . . . . . 10 - 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 12 - 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 13 - 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 14 - 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14 - 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 16 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 + 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 + 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 + 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 + 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 + 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 + 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 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 - Intellectual Property and Copyright Statements . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. @@ -364,23 +368,23 @@ follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 7 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The Slack Term parameter S is nonnegative and is measured in - microseconds. S is represented as a 32-bit integer. Its value can - range from 0 to (2**32)-1 microseconds. + 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 + integer. Its value can range from 0 to (2**32)-1 microseconds. 4.9. Preemption Priority amp; Defending Priority Parameters A description of the semantic of the parameter values can be found in [RFC3181]. The coding for the & sub- parameters is as follows: 0 1 2 3 @@ -393,131 +397,92 @@ Preemption Priority: The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority. Defending Priority: Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows. As specified in [RFC3181], & are 16-bit integer values. + Priority> are 16-bit integer values. They are represented in network + byte order. 4.10. Admission Priority Parameter A description of the semantic of the parameter values can be found in [Y.1571]. The coding for the parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 9 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 flows can have access to resources depending on their admission priority value as follows: Admission Priority: 0 - best-effort priority flow 1 - normal priority flow 2 - high priority flow 255 - not used A reservation without an parameter (i.e., set to 255) MUST be treated as a reservation with an = 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 - [RFC4412]. The coding for the parameter is as - follows: + [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for + parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 - "RPH Namespace" and "RPH Priority" combination, and if populated is - applicable only to flows with high admission priority, as follows: - - 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: [Y.1571] - 2 parameters: , [RFC4412] - 2 parameters: , [RFC3181] - 3 parameters: , , - [3GPP-1, 3GPP-2, 3GPP-3] - 4 parameters: , , - , [3GPP-1, 3GPP-2, - 3GPP-3] - It is permissible to have without , but not permissible to have without - (alternatively is ignored in - instances without ). + [RFC4412] defines a resource priority header and established the + initial registry; that registry was later extended by + [I-D.ietf-tsvwg-emergency-rsvp]. 4.12. Excess Treatment Parameter The coding for the parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 11 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Trtmnt | Remark Value | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Excess Treatment: Indicates how the QoS aware node should process - out-of-profile traffic, that is, traffic not covered by the + Excess Treatment (8 bit unsigned integer value in network byte + order): Indicates how the QoS aware node should process out-of- + profile traffic, that is, traffic not covered by the parameter. Allowed values are as follows: 0: drop 1: shape 2: remark 3: no metering or policing is permitted 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 do what it finds suitable. @@ -537,20 +502,23 @@ packets arrive marked as belonging to a certain QoS class, and when they are identified as excess, they should then be remarked to a different QoS Class. If 'no metering or policing is permitted' is signaled, the QoS aware node should accept the excess treatment parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter [RFC3290] is especially strong, and should be used with caution. + The Remark Value is an 8 bit unsigned integer value in network byte + order. + 4.13. PHB Class Parameter A description of the semantic of the parameter values can be found in [RFC3140]. The coding for the parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 12 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -703,31 +673,27 @@ vendor field are 0x00000000, then the value is standards-specified and the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID). IANA created registry is split into two value ranges; one range uses the "Standards Action" and the second range uses "Specification Required" allocation policy. The latter range is meant to be used by organizations outside the IETF. 6. IANA Considerations - This document reuses the namespace created in [I-D.ietf-nsis-qspec] - for - 1. Admission Priority Parameter - 2. RPH Namespace Parameter - 3. RPH Priority Parameter - 4. Excess Treatment Parameter - 5. DSTE Class Type Parameter - 6. Y.1541 QoS Class Parameter + This section defines the registries and initial codepoint + assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also + defines the procedural requirements to be followed by IANA in + allocating new codepoints. - IANA is requested to create the following registries: QoS Profile (32 - bits), and Parameter ID (12 bits) + IANA is requested to create the following registries listed in the + subsections below. 6.1. QoS Profile 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 indicates the type as either standards-specified or vendor-specific. If the four octets of the vendor field are 0x00000000, then the value is standards-specified and the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID). @@ -760,54 +724,123 @@ (0): (1): (2): (3): (4): (5): (6): (7): & (8): - (9): + (9): (10): (11): (12): (13): The allocation policies for further values are as follows: - 14-127: Standards Action - 128-255: Private/Experimental Use - 255-4095: Specification Required A standards track document is required to depreciate, delete, or 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 This document does not raise any security concerns as it only defines QoS parameters. 8. Acknowledgements The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 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. 9. 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. @@ -850,25 +883,33 @@ Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [Y.1541] "Network Performance Objectives for IP-Based Services", , 2006. + [Y.1571] "Admission Control Priority Levels in Next Generation + Networks", , July 2006. + 9.2. Informative References [I-D.ietf-nsis-qspec] - Ash, J., "QoS NSLP QSPEC Template", - draft-ietf-nsis-qspec-17 (work in progress), July 2007. + Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP + 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 Transfer and Availability Performance Parameters", , December 2002. Authors' Addresses Jouni Korhonen (editor) TeliaSonera Teollisuuskatu 13 @@ -881,21 +922,21 @@ Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com 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 contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF