idnits 2.17.1 draft-ietf-dime-qos-parameters-09.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.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 22, 2009) is 5567 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: 'RFC3290' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 522, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tsvwg-emergency-rsvp-09 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-21 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) H. Tschofenig 4 Internet-Draft Nokia Siemens Networks 5 Intended status: Standards Track E. Davies 6 Expires: July 26, 2009 Folly Consulting 7 January 22, 2009 9 Quality of Service Parameters for Usage with Diameter 10 draft-ietf-dime-qos-parameters-09.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 26, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document defines a number of Quality of Service (QoS) parameters 50 that can be reused for conveying QoS information within Diameter. 52 The defined QoS information includes data traffic parameters for 53 describing a token bucket filter, bandwidth, defending and preemption 54 priority, admission priority, application-level resource priority, 55 per-hop behavior class, and DiffServ-aware Multiprotocol Label 56 Switching (MPLS) traffic engineering. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 62 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 63 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 66 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 67 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 68 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 70 3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 72 3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 73 3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 74 3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 76 3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 77 3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 78 3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 79 3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 80 3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 81 3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8 82 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 This document defines a number of Quality of Service (QoS) parameters 94 that can be reused for conveying QoS information within the Diameter 95 protocol. 97 This document defines an initial QoS profile containing a set of QoS 98 AVPs. 100 The traffic model (TMOD) AVPs are containers consisting of four AVPs 101 and is a way to describe the traffic source. 103 o rate (r) 104 o bucket size (b) 105 o peak rate (p) 106 o minimum policed unit (m) 108 The encoding of and can be found in Section 3.1 and 109 Section 3.2 and the semantic is described in [RFC2210] and in 110 [RFC2215]. is, for example, needed by some DiffServ 111 applications. It is typically assumed that DiffServ EF traffic is 112 shaped at the ingress by a single rate token bucket. Therefore, a 113 single TMOD parameter is sufficient to signal DiffServ EF traffic. 114 However, for DiffServ AF traffic two sets of token bucket parameters 115 are needed, one token bucket for the average traffic and one token 116 bucket for the burst traffic. [RFC2697] defines a Single Rate Three 117 Color Marker (srTCM), which meters a traffic stream and marks its 118 packets according to three traffic parameters, Committed Information 119 Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), 120 to be either green, yellow, or red. A packet is marked green if it 121 does not exceed the CBS, yellow if it does exceed the CBS, but not 122 the EBS, and red otherwise. [RFC2697] defines specific procedures 123 using two token buckets that run at the same rate. Therefore, two 124 TMOD AVPs are sufficient to distinguish among three levels of drop 125 precedence. An example is also described in the appendix of 126 [RFC2597]. 128 The AVP refers to the priority of a new flow 129 compared with the AVP of previously admitted 130 flows. Once a flow is admitted, the preemption priority becomes 131 irrelevant. The AVP is used to compare with the 132 preemption priority of new flows. For any specific flow, its 133 preemption priority is always less than or equal to the defending 134 priority. 136 The AVP and AVP provide an essential way 137 to differentiate flows for emergency services, ETS, E911, etc., and 138 assign them a higher admission priority than normal priority flows 139 and best-effort priority flows. 141 Resource reservations might refer to a packet processing with a 142 particular DiffServ per-hop behavior (PHB) [RFC2475] (using the AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS 144 traffic engineering (DSTE) class type, as described in [RFC3564] and 145 in [RFC4124], using the AVP. 147 2. Terminology and Abbreviations 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC2119 [RFC2119]. 153 3. QoS Parameter Encoding 155 3.1. TMOD-1 AVP 157 The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The 158 structure of the AVP is as follows: 160 TMOD-1 ::= < AVP Header: TBD > 161 { TMOD-Rate } 162 { TMOD-Size } 163 { Peak-Data-Rate } 164 { Minimum-Policed-Unit } 166 3.1.1. TMOD-Rate AVP 168 The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the 169 rate (r). 171 3.1.2. TMOD-Size AVP 173 The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the 174 bucket size (b). 176 3.1.3. Peak-Data-Rate AVP 178 The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains 179 the peak rate (p). 181 3.1.4. Minimum-Policed-Unit AVP 183 The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and 184 contains the minimum policed unit (m). 186 3.2. TMOD-2 AVP 188 A description of the semantic of the parameter values can be found in 189 [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The 190 coding for the TMOD-2 AVP is as follows: 192 TMOD-2 ::= < AVP Header: TBD > 193 { TMOD-Rate } 194 { TMOD-Size } 195 { Peak-Data-Rate } 196 { Minimum-Policed-Unit } 198 3.3. Bandwidth AVP 200 The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured 201 in bytes of IP datagrams per second. 203 3.4. Priority AVP 205 The Priority AVP is a grouped AVP consisting of two AVPs, the 206 Preemption-Priority and the Defending-Priority AVP. A description of 207 the semantic can be found in [RFC3181]. 209 Priority ::= < AVP Header: TBD > 210 { Preemption-Priority } 211 { Defending-Priority } 213 3.4.1. Preemption-Priority AVP 215 The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and 216 it indicates the priority of the new flow compared with the defending 217 priority of previously admitted flows. Higher values represent 218 higher priority. 220 3.4.2. Defending-Priority AVP 222 The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. 223 Once a flow is admitted, the preemption priority becomes irrelevant. 224 Instead, its defending priority is used to compare with the 225 preemption priority of new flows. 227 3.5. Admission-Priority AVP 229 The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. 231 The admission control priority of the flow, in terms of access to 232 network bandwidth in order to provide higher probability of call 233 completion to selected flows. Higher values represent higher 234 priority. A given admission priority is encoded in this information 235 element using the same value as when encoded in the Admission- 236 Priority AVP defined in Section 3.1 of 237 [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). 239 3.6. ALRP AVP 241 The Application-Level Resource Priority (ALRP) AVP is a grouped AVP 242 consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. 244 A description of the semantic of the parameter values can be found in 245 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 246 parameter is as follows: 248 ALRP ::= < AVP Header: TBD > 249 { ALRP-Namespace } 250 { ALRP-Priority } 252 3.6.1. ALRP-Namespace AVP 254 The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 256 3.6.2. ALRP-Priority AVP 258 The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. 260 [RFC4412] defines a resource priority header and established the 261 initial registry. That registry was later extended by 262 [I-D.ietf-tsvwg-emergency-rsvp]. 264 3.7. PHB-Class AVP 266 The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. 268 A description of the semantic of the parameter values can be found in 269 [RFC3140]. The registries needed for usage with [RFC3140] already 270 exist and hence no new registry needs to be created by this document. 271 The encoding requires three cases need to be differentiated. All 272 bits indicated as "reserved" MUST be set to zero (0). 274 3.7.1. Case 1: Single PHB 276 As prescribed in [RFC3140], the encoding for a single PHB is the 277 recommended DSCP value for that PHB, left-justified in the 16 bit 278 field, with bits 6 through 15 set to zero. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 3.7.2. Case 2: Set of PHBs 288 The encoding for a set of PHBs is the numerically smallest of the set 289 of encodings for the various PHBs in the set, with bit 14 set to 1. 290 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 291 bit 14 set to 1.) 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 3.7.3. Case 3: Experimental or Local Use PHBs 301 PHBs not defined by standards action, i.e., experimental or local use 302 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 303 identification code, assigned by the IANA, is placed left-justified 304 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 305 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 307 Bits 12 and 13 are reserved either for expansion of the PHB 308 identification code, or for other use, at some point in the future. 310 In both cases, when a single PHBID is used to identify a set of PHBs 311 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 312 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 313 intra-microflow traffic reordering when different PHBs from the set 314 are applied to traffic in the same microflow). The set of AF1x PHBs 315 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 316 do not constitute a PHB Scheduling Class can be identified by using 317 more than one PHBID. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | PHD ID CODE |0 0 1 0| (Reserved) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 3.8. DSTE-Class-Type AVP 327 The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A 328 description of the semantic of the parameter values can be found in 329 [RFC4124]. 331 Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, 332 6, 7. The value of zero (0) is marked as reserved in [RFC4124]. 333 Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in 334 length with 29 bits reserved. 336 4. Extensibility 338 This document is designed with extensibility in mind given that 339 different organizations and groups are used to define their own 340 Quality of Service parameters. This document provides an initial QoS 341 profile with common set of parameters. Ideally, these parameters 342 should be used whenever possible but there are cases where additional 343 parameters might be needed, or where the parameters specified in this 344 document are used with a different semantic. In that case it is 345 advisable to define a new QoS profile that may consist of new 346 parameters in addition to parameters defined in this document or an 347 entirely different set of parameters. Finally, it is also possible 348 to register a specific QoS profile that defines a specific set of QoS 349 values rather than parameters that need to be filled with values in 350 order to be used. 352 To enable the definition of new QoS profiles a 8 octet registry is 353 defined field that is represented by a 4-octet vendor and 4-octet 354 specifier field. The vendor field indicates the type as either 355 standards-specified or vendor-specific. If the four octets of the 356 vendor field are 0x00000000, then the value is standards-specified 357 and the registry is maintained by IANA as Enterprise Numbers defined 358 in [RFC2578], and any other value represents a vendor-specific Object 359 Identifier (OID). IANA created registry is split into two value 360 ranges; one range uses the "Standards Action" and the second range 361 uses "Specification Required" allocation policy. The latter range is 362 meant to be used by organizations outside the IETF. 364 5. IANA Considerations 366 5.1. AVP Codes 368 IANA is requested to allocate AVP codes for the following AVPs that 369 are defined in this document. 371 +------------------------------------------------------------------+ 372 | AVP Section | 373 |AVP Name Code Defined Data Type | 374 +------------------------------------------------------------------+ 375 |TMOD-1 TBD 3.1 Grouped | 376 |TMOD-Rate TBD 3.1.1 Float32 | 377 |TMOD-Size TBD 3.1.2 Float32 | 378 |Peak-Data-Rate TBD 3.1.3 Float32 | 379 |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | 380 |TMOD-2 TBD 3.2 Grouped | 381 |Bandwidth TBD 3.3 Float32 | 382 |Priority TBD 3.4 Grouped | 383 |Preemption-Priority TBD 3.4.1 Unsigned32 | 384 |Defending-Priority TBD 3.4.2 Unsigned32 | 385 |Admission-Priority TBD 3.5 Unsigned32 | 386 |ALRP TBD 3.6 Grouped | 387 |ALRP-Namespace TBD 3.6.1 Unsigned32 | 388 |ALRP-Priority TBD 3.6.2 Unsigned32 | 389 |PHB-Class TBD 3.7 Unsigned32 | 390 |DSTE-Class-Type TBD 3.8 Unsigned32 | 391 +------------------------------------------------------------------+ 393 5.2. QoS Profile 395 IANA is requested to create the following registry. 397 The QoS Profile refers to a 64 bit long field that is represented by 398 a 4-octet vendor and 4-octet specifier field. The vendor field 399 indicates the type as either standards-specified or vendor-specific. 400 If the four octets of the vendor field are 0x00000000, then the value 401 is standards-specified and the registry is maintained by IANA, and 402 any other value represents a vendor-specific Object Identifier (OID). 404 The specifier field indicates the actual QoS profile. The vendor 405 field 0x00000000 is reserved to indicate that the values in the 406 specifier field are maintained by IANA. This document requests IANA 407 to create such a registry and to allocate the value zero (0) for the 408 QoS profile defined in this document. 410 For any other vendor field, the specifier field is maintained by the 411 vendor. 413 For the IANA maintained QoS profiles the following allocation policy 414 is defined: 415 0 to 511: Standards Action 416 512 to 4095: Specification Required 418 Standards action is required to depreciate, delete, or modify 419 existing QoS profile values in the range of 0-511 and a specification 420 is required to depreciate, delete, or modify existing QoS profile 421 values in the range of 512-4095. 423 6. Security Considerations 425 This document does not raise any security concerns as it only defines 426 QoS parameters and does not yet describe how they are exchanged in a 427 AAA protocol. Security considerations are described in documents 428 using this specification. 430 7. Acknowledgements 432 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 433 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 434 NSIS working group chairs (John Loughney and Martin Stiemerling) and 435 the former Transport Area Directors (Allison Mankin, Jon Peterson) 436 for their help. The authors of this document are thankful for the 437 suggestions and input received from the NSIS QSPEC 438 [I-D.ietf-nsis-qspec] authors. 440 We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, 441 Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James 442 Polk, Martin Stiemerling, and Magnus Westerlund for their help with 443 resolving problems regarding the Admission Priority and the ALRP 444 parameter. 446 Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided 447 help with the semantic of some QSPEC parameters. 449 We would like to thank Dan Romascanu for his detailed Area Director 450 review comments and Scott Bradner for his Transport Area Directorate 451 review. 453 8. References 455 8.1. Normative References 457 [I-D.ietf-tsvwg-emergency-rsvp] 458 Faucheur, F., Polk, J., and K. Carlberg, "Resource 459 ReSerVation Protovol (RSVP) Extensions for Emergency 460 Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in 461 progress), October 2008. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 467 Services", RFC 2210, September 1997. 469 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 470 Parameters for Integrated Service Network Elements", 471 RFC 2215, September 1997. 473 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 474 "Definition of the Differentiated Services Field (DS 475 Field) in the IPv4 and IPv6 Headers", RFC 2474, 476 December 1998. 478 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 479 Schoenwaelder, Ed., "Structure of Management Information 480 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 482 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 483 "Assured Forwarding PHB Group", RFC 2597, June 1999. 485 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 486 "Per Hop Behavior Identification Codes", RFC 3140, 487 June 2001. 489 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 490 RFC 3181, October 2001. 492 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 493 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 494 June 2005. 496 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 497 Priority for the Session Initiation Protocol (SIP)", 498 RFC 4412, February 2006. 500 8.2. Informative References 502 [I-D.ietf-nsis-qspec] 503 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 504 Template", draft-ietf-nsis-qspec-21 (work in progress), 505 November 2008. 507 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 508 and W. Weiss, "An Architecture for Differentiated 509 Services", RFC 2475, December 1998. 511 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 512 Marker", RFC 2697, September 1999. 514 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 515 Informal Management Model for Diffserv Routers", RFC 3290, 516 May 2002. 518 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 519 Differentiated Services-aware MPLS Traffic Engineering", 520 RFC 3564, July 2003. 522 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 523 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 524 May 2008. 526 Authors' Addresses 528 Jouni Korhonen (editor) 529 Nokia Siemens Networks 530 Linnoitustie 6 531 Espoo 02600 532 Finland 534 Email: jouni.korhonen@nsn.com 536 Hannes Tschofenig 537 Nokia Siemens Networks 538 Linnoitustie 6 539 Espoo 02600 540 Finland 542 Phone: +358 (50) 4871445 543 Email: Hannes.Tschofenig@gmx.net 544 URI: http://www.tschofenig.priv.at 546 Elwyn Davies 547 Folly Consulting 548 Soham 549 UK 551 Phone: +44 7889 488 335 552 Email: elwynd@dial.pipex.com