idnits 2.17.1 draft-carlberg-dime-priority-avps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b. (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 51 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 17 has weird spacing: '...), its areas...' == Line 18 has weird spacing: '...ups may also ...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...me. It is i...' == Line 26 has weird spacing: '... The list ...' == (46 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Oct 19, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3181' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC4124' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-qspec' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 274, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-emergency-rsvp-12 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-21 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and K. Carlberg, Ed. 3 Extensions (DIME) G11 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Oct 19, 2009 8 Diameter Priority Attribute Value Pairs 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This document defines various priority parameters for use with 46 Diameter and the AAA framework. These parameters are defined in 47 several different protocols that operate at either the network or 48 application layer. 50 1. Introduction 52 This document defines a number of priority parameters that can be 53 reused for conveying priority labeled information within the Diameter 54 protocol [RFC3588]. It defines an initial priority profile 55 containing a set of Diameter encoded Attribute Value Pairs (AVPs) 56 described using a modified version of the Augmented Backus-Naur Form 57 (ABNF), see [RFC3588]. The data types are also taken from [RFC3588]. 59 Priority influences the distribution of resources. This influence 60 may be probabilistic ranging between (but not including) 0% and 100%, 61 or it may be binary (in the form of a guarantee to either receive or 62 not receive the resource). 64 The influence attributed to prioritization may also affect QoS, but 65 it is not to be confused as QoS. As an example, if packets of two or 66 more flows are contending for the same shared resources, 67 prioritization helps determine which packet receives the resource. 68 However, this allocation of resource does not correlate directly to 69 any specific delay or loss bounds that have been associated with the 70 packet. 72 One can also argue that the lack of contention (or congested state) 73 of the shared resource implies that packets of flow(s) are forwarded 74 at the same rate (minus a constant processing overhead) they are 75 received with no appreciable difference in QoS experienced by any 76 packet. 78 A third example of how prioritization can be realized is articulated 79 in Appendix A.3 (the priority by-pass model) of [draft.rsvp- 80 priority-extension]. In this case, prioritized flows may grant 81 access to resources that are never shared with non-prioritized flows. 83 2. Terminology and Abbreviations 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC2119 [RFC2119]. 89 3. Priority Parameter Encoding 91 3.1. Dual-Priority AVP 93 The Dual-Priority AVP is a grouped AVP consisting of two AVPs, the 94 Preemption-Priority and the Defending-Priority AVP, which are derived 95 from the corresponding priority fields in the Signaled Policy Element 97 [rfc3181] of RSVP [rfc2205]. The Defending-Priority is set when the 98 reservation has been admitted. The Preemption-Priority of a newly 99 requested reservation and is compared with the Defending Priority of 100 a previously admitted flow. Actions taken upon this comparison is a 101 function of local policy. 103 Dual-Priority ::= < AVP Header: TBD > 104 { Preemption-Priority } 105 { Defending-Priority } 107 3.1.1. Preemption-Priority AVP 109 The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32. 110 Higher values represent higher priority. 112 3.1.2. Defending-Priority AVP 114 The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. 115 Higher values represent higher priority. 117 3.2. Admission-Priority AVP 119 The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. 121 The admission control priority of the flow used to increase the 122 probability of session establishment to selected flows. Higher 123 values represent higher priority. A given admission priority is 124 encoded in this information element using the same value as when 125 encoded in the admission priority parameter defined in Section 3.1 of 126 [I-D.ietf-tsvwg-emergency-rsvp]. 128 3.3. ALRP AVP 130 The Application-Level Resource Priority (ALRP) AVP is a grouped AVP 131 consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. 133 A description of the semantic of the parameter values can be found in 134 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 135 parameter is as follows: 137 ALRP ::= < AVP Header: TBD > 138 { ALRP-Namespace } 139 { ALRP-Priority } 141 3.3.1. ALRP-Namespace AVP 143 The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 145 3.3.2. ALRP-Priority AVP 147 The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. 148 [RFC4412] defines a resource priority header and established the 149 initial registry. That registry was later extended by [I-D.ietf- 150 tsvwg-emergency-rsvp]. 152 3.4. SIP-RPH AVP 154 The SIP-RPH AVP is a grouped AVP consisting of two AVPs, the SIP- 155 Namespace and the SIP-Value AVP, which are derived from the 156 corresponding optional header fields in [rfc4412]. The SIP-Namespace 157 identifies a particular set of priorities. The SIP-Value identifies 158 a specific priority associated with the SIP-Namespace. 160 SIP-RPH ::= { SIP-Namespace } 161 { SIP-Value } 163 3.4.1. SIP-Namespace AVP 165 The SIP-Namespace AVP (AVP Code TBD) is of type UTF8String. 167 3.4.2 SIP-Value AVP 169 The SIP-Value AVP (AVP Code TBD) is of type UTF8String. 171 4. IANA Considerations 173 4.1. AVP Codes 175 IANA is requested to allocate AVP codes for the following AVPs that 176 are defined in this document. 178 +------------------------------------------------------------------+ 179 | AVP Section | 180 |AVP Name Code Defined Data Type | 181 +------------------------------------------------------------------+ 182 |Dual-Priority TBD 3.1 Grouped | 183 |Preemption-Priority TBD 3.1.1 Unsigned32 | 184 |Defending-Priority TBD 3.1.2 Unsigned32 | 185 |Admission-Priority TBD 3.2 Unsigned32 | 186 |ALRP TBD 3.3 Grouped | 187 |ALRP-Namespace TBD 3.3.1 Unsigned32 | 188 |ALRP-Priority TBD 3.3.2 Unsigned32 | 189 |SIP-RPH TBD 3.4 Grouped | 190 |SIP-Namespace TBD 3.4.1 UTF8String | 191 |SIP-Value TBD 3.4.2 UTF8String | 192 +------------------------------------------------------------------+ 194 4.2. QoS Profile 196 IANA is requested to allocate a new value from the registry defined 197 in [I-D.ietf-dime-qos-parameters] for the QoS profile defined in this 198 document. 200 5. Examples 202 +--------+ +--------+ 203 |Diameter| | SIP | 204 | server | | server | 205 +--------+ +--------+ 206 | | 207 | | 208 | | 209 1. SIP INVITE w/ RPH | 210 ------------------------------>| 211 | 2. MAR w/ SIP-RPH AVP | 212 |<----------------------| 213 | 3. MAA. | 214 |---------------------->| 8. SIP INVITE 215 | |----------------> 216 | | 9. SIP 200 (OK) 217 10. SIP 200 (OK) |<---------------- 218 <------------------------------| 219 | | 221 6. Security Considerations 223 TBD 225 7. Acknowledgements 227 We would like to thank Lars Eggert, Jan Engelhardt, Francois 228 LeFaucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin 229 Stiemerling, and Magnus Westerlund for their help with resolving 230 problems regarding the Admission Priority and the ALRP parameter. 231 Additionally, we would like to thank Martin Dolly and Viqar Shaikh 232 for their feedback. 234 8. References 236 8.1. Normative References 238 [I-D.ietf-dime-qos-parameters] 239 Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 240 Service Parameters for Usage with Diameter", 241 draft-ietf-dime-qos-parameters-11 (work in progress) 242 May 2009. 244 [I-D.ietf-tsvwg-emergency-rsvp] 245 Faucheur, F., Polk, J., and K. Carlberg, "Resource 246 ReSerVation Protocol (RSVP) Extensions for Emergency 247 Services", draft-ietf-tsvwg-emergency-rsvp-12 (work in 248 progress), May 2009. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 254 RFC 3181, October 2001. 256 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 257 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 259 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 260 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 261 June 2005. 263 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 264 Priority for the Session Initiation Protocol (SIP)", 265 RFC 4412, February 2006. 267 8.2. Informative References 269 [I-D.ietf-nsis-qspec] 270 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 271 Template", draft-ietf-nsis-qspec-21 (work in progress), 272 November 2008. 274 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 275 Differentiated Services-aware MPLS Traffic Engineering", 276 RFC 3564, July 2003. 278 Authors' Addresses 280 Ken Carlberg (editor) Hannes Tschofenig 281 G11 Nokia Siemens Networks 282 1601 Clarendon Dr Linnoitustie 6 Espoo 02600 283 Arlington, VA 22209 Finland 284 United States Phone: +358 (50) 4871445 286 Email: carlberg@g11.org.uk Email: Hannes.Tschofenig@gmx.net 287 URI:http://www.tschofenig.priv.at