idnits 2.17.1 draft-ietf-dime-qos-parameters-08.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 (December 18, 2008) is 5608 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 502, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 510, 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 December 18, 2008 6 Expires: June 21, 2009 8 Quality of Service Parameters for Usage with Diameter 9 draft-ietf-dime-qos-parameters-08.txt 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 This Internet-Draft will expire on June 21, 2009. 34 Copyright Notice 36 Copyright (c) 2008 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document defines a number of Quality of Service (QoS) parameters 49 that can be reused for conveying QoS information within Diameter. 51 The payloads used to carry these QoS parameters are opaque for the 52 AAA client and the AAA server itself and interpreted by the 53 respective Resource Management Function. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 59 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 60 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 62 3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 63 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 64 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 65 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 68 3.3.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 69 3.4. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 70 3.5. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.5.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 72 3.5.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 73 3.6. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 74 3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 75 3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 76 3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 77 3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 7 78 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 This document defines a number of Quality of Service (QoS) parameters 90 that can be reused for conveying QoS information within the Diameter 91 protocol. 93 This document defines an initial QoS profile containing a set of QoS 94 AVPs. 96 The traffic model (TMOD) AVPs are containers consisting of four AVPs 97 and is a way to describe the traffic source. 99 o rate (r) 100 o bucket size (b) 101 o peak rate (p) 102 o minimum policed unit (m) 104 The encoding of and can be found in Section 3.1 and 105 Section 3.2 and the semantic is described in [RFC2210] and in 106 [RFC2215]. is, for example, needed by some DiffServ 107 applications. I t is typically assumed that DiffServ EF traffic is 108 shaped at the ingress by a single rate token bucket. Therefore, a 109 single TMOD parameter is sufficient to signal DiffServ EF traffic. 110 However, for DiffServ AF traffic two sets of token bucket parameters 111 are needed, one token bucket for the average traffic and one token 112 bucket for the burst traffic. [RFC2697] defines a Single Rate Three 113 Color Marker (srTCM), which meters a traffic stream and marks its 114 packets according to three traffic parameters, Committed Information 115 Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), 116 to be either green, yellow, or red. A packet is marked green if it 117 does not exceed the CBS, yellow if it does exceed the CBS, but not 118 the EBS, and red otherwise. [RFC2697] defines specific procedures 119 using two token buckets that run at the same rate. Therefore, two 120 TMOD AVPs are sufficient to distinguish among three levels of drop 121 precedence. An example is also described in the appendix of 122 [RFC2597]. 124 The AVP refers to the priority of a new flow 125 compared with the AVP of previously admitted 126 flows. Once a flow is admitted, the preemption priority becomes 127 irrelevant. The AVP is used to compare with the 128 preemption priority of new flows. For any specific flow, its 129 preemption priority is always less than or equal to the defending 130 priority. 132 The AVP and AVP provide an essential way 133 to differentiate flows for emergency services, ETS, E911, etc., and 134 assign them a higher admission priority than normal priority flows 135 and best-effort priority flows. 137 Resource reservations might refer to a packet processing with a 138 particular DiffServ per-hop behavior (PHB) [RFC2475] (using the AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS 140 traffic engineering (DSTE) class type, as described in [RFC3564] and 141 in [RFC4124], using the AVP. 143 2. Terminology and Abbreviations 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC2119 [RFC2119]. 149 3. QoS Parameter Encoding 151 3.1. TMOD-1 AVP 153 The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The 154 structure of the AVP is as follows: 156 TMOD-1 ::= < AVP Header: TBD > 157 { TMOD-Rate } 158 { TMOD-Size } 159 { Peak-Data-Rate } 160 { Minimum-Policed-Unit } 162 3.1.1. TMOD-Rate AVP 164 The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the 165 rate (r). 167 3.1.2. TMOD-Size AVP 169 The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the 170 bucket size (b). 172 3.1.3. Peak-Data-Rate AVP 174 The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains 175 the peak rate (p). 177 3.1.4. Minimum-Policed-Unit AVP 179 The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and 180 contains the minimum policed unit (m). 182 3.2. TMOD-2 AVP 184 A description of the semantic of the parameter values can be found in 185 [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The 186 coding for the TMOD-2 AVP is as follows: 188 TMOD-2 ::= < AVP Header: TBD > 189 { TMOD-Rate } 190 { TMOD-Size } 191 { Peak-Data-Rate } 192 { Minimum-Policed-Unit } 194 3.3. Priority AVP 196 The Priority AVP is a grouped AVP consisting of two AVPs, the 197 Preemption-Priority and the Defending-Priority AVP. A description of 198 the semantic can be found in [RFC3181]. 200 Priority ::= < AVP Header: TBD > 201 { Preemption-Priority } 202 { Defending-Priority } 204 3.3.1. Preemption-Priority AVP 206 The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and 207 it indicates the priority of the new flow compared with the defending 208 priority of previously admitted flows. Higher values represent 209 higher priority. 211 3.3.2. Defending-Priority AVP 213 The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. 214 Once a flow is admitted, the preemption priority becomes irrelevant. 215 Instead, its defending priority is used to compare with the 216 preemption priority of new flows. 218 3.4. Admission-Priority AVP 220 The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. 222 The admission control priority of the flow, in terms of access to 223 network bandwidth in order to provide higher probability of call 224 completion to selected flows. Higher values represent higher 225 priority. A given admission priority is encoded in this information 226 element using the same value as when encoded in the Admission- 227 Priority AVP defined in Section 3.1 of 228 [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). 230 3.5. ALRP AVP 232 The Application-Level Resource Priority (ALRP) AVP is a grouped AVP 233 consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. 235 A description of the semantic of the parameter values can be found in 236 [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for 237 parameter is as follows: 239 ALRP ::= < AVP Header: TBD > 240 { ALRP-Namespace } 241 { ALRP-Priority } 243 3.5.1. ALRP-Namespace AVP 245 The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 247 3.5.2. ALRP-Priority AVP 249 The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. 251 [RFC4412] defines a resource priority header and established the 252 initial registry. That registry was later extended by 253 [I-D.ietf-tsvwg-emergency-rsvp]. 255 3.6. PHB-Class AVP 257 The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. 259 A description of the semantic of the parameter values can be found in 260 [RFC3140]. The registries needed for usage with [RFC3140] already 261 exist and hence no new registry needs to be created by this document. 262 The encoding requires three cases need to be differentiated. All 263 bits indicated as "reserved" MUST be set to zero (0). 265 3.6.1. Case 1: Single PHB 267 As prescribed in [RFC3140], the encoding for a single PHB is the 268 recommended DSCP value for that PHB, left-justified in the 16 bit 269 field, with bits 6 through 15 set to zero. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 3.6.2. Case 2: Set of PHBs 279 The encoding for a set of PHBs is the numerically smallest of the set 280 of encodings for the various PHBs in the set, with bit 14 set to 1. 281 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with 282 bit 14 set to 1.) 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 3.6.3. Case 3: Experimental or Local Use PHBs 292 PHBs not defined by standards action, i.e., experimental or local use 293 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB 294 identification code, assigned by the IANA, is placed left-justified 295 in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a 296 single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 298 Bits 12 and 13 are reserved either for expansion of the PHB 299 identification code, or for other use, at some point in the future. 301 In both cases, when a single PHBID is used to identify a set of PHBs 302 (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB 303 Scheduling Class (i.e., use of PHBs from the set MUST NOT cause 304 intra-microflow traffic reordering when different PHBs from the set 305 are applied to traffic in the same microflow). The set of AF1x PHBs 306 [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that 307 do not constitute a PHB Scheduling Class can be identified by using 308 more than one PHBID. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | PHD ID CODE |0 0 1 0| (Reserved) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 3.7. DSTE-Class-Type AVP 318 The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A 319 description of the semantic of the parameter values can be found in 320 [RFC4124]. 322 Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, 323 6, 7. The value of zero (0) is marked as reserved in [RFC4124]. 324 Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in 325 length with 29 bits reserved. 327 4. Extensibility 329 This document is designed with extensibility in mind given that 330 different organizations and groups are used to define their own 331 Quality of Service parameters. This document provides an initial QoS 332 profile with common set of parameters. Ideally, these parameters 333 should be used whenever possible but there are cases where additional 334 parameters might be needed, or where the parameters specified in this 335 document are used with a different semantic. In this case it is 336 advisable to define a new QoS profile that may consist of new 337 parameters in addition to parameters defined in this document or an 338 entirely different set of parameters. 340 To enable the definition of new QoS profiles a 8 octet registry is 341 defined field that is represented by a 4-octet vendor and 4-octet 342 specifier field. The vendor field indicates the type as either 343 standards-specified or vendor-specific. If the four octets of the 344 vendor field are 0x00000000, then the value is standards-specified 345 and the registry is maintained by IANA as Enterprise Numbers defined 346 in [RFC2578], and any other value represents a vendor-specific Object 347 Identifier (OID). IANA created registry is split into two value 348 ranges; one range uses the "Standards Action" and the second range 349 uses "Specification Required" allocation policy. The latter range is 350 meant to be used by organizations outside the IETF. 352 5. IANA Considerations 354 5.1. AVP Codes 356 IANA is requested to allocate AVP codes for the following AVPs that 357 are defined in this document. 359 +------------------------------------------------------------------+ 360 | AVP Section | 361 |AVP Name Code Defined Data Type | 362 +------------------------------------------------------------------+ 363 |TMOD-1 TBD 3.1 Grouped | 364 |TMOD-Rate TBD 3.1.1 Float32 | 365 |TMOD-Size TBD 3.1.2 Float32 | 366 |Peak-Data-Rate TBD 3.1.3 Float32 | 367 |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | 368 |TMOD-2 TBD 3.2 Grouped | 369 |Priority TBD 3.3 Grouped | 370 |Preemption-Priority TBD 3.3.1 Unsigned32 | 371 |Defending-Priority TBD 3.3.2 Unsigned32 | 372 |Admission-Priority TBD 3.4 Unsigned32 | 373 |ALRP TBD 3.5 Grouped | 374 |ALRP-Namespace TBD 3.5.1 Unsigned32 | 375 |ALRP-Priority TBD 3.5.2 Unsigned32 | 376 |PHB-Class TBD 3.6 Unsigned32 | 377 |DSTE-Class-Type TBD 3.7 Unsigned32 | 378 +------------------------------------------------------------------+ 380 5.2. QoS Profile 382 IANA is requested to create the following registry. 384 The QoS Profile refers to a 64 bit long field that is represented by 385 a 4-octet vendor and 4-octet specifier field. The vendor field 386 indicates the type as either standards-specified or vendor-specific. 387 If the four octets of the vendor field are 0x00000000, then the value 388 is standards-specified and the registry is maintained by IANA, and 389 any other value represents a vendor-specific Object Identifier (OID). 391 The specifier field indicates the actual QoS profile. The vendor 392 field 0x00000000 is reserved to indicate that the values in the 393 specifier field are maintained by IANA. This document requests IANA 394 to create such a registry and to allocate the value zero (0) for the 395 QoS profile defined in this document. 397 For any other vendor field, the specifier field is maintained by the 398 vendor. 400 For the IANA maintained QoS profiles the following allocation policy 401 is defined: 402 0 to 511: Standards Action 403 512 to 4095: Specification Required 405 Standards action is required to depreciate, delete, or modify 406 existing QoS profile values in the range of 0-511 and a specification 407 is required to depreciate, delete, or modify existing QoS profile 408 values in the range of 512-4095. 410 6. Security Considerations 412 This document does not raise any security concerns as it only defines 413 QoS parameters and does not yet describe how they are exchanged in a 414 AAA protocol. Security considerations are described in documents 415 using this specification. 417 7. Acknowledgements 419 The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] 420 authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the 421 NSIS working group chairs (John Loughney and Martin Stiemerling) and 422 the former Transport Area Directors (Allison Mankin, Jon Peterson) 423 for their help. This document re-uses content from the NSIS QSPEC 424 [I-D.ietf-nsis-qspec] specification. 426 We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, 427 Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James 428 Polk, Martin Stiemerling, and Magnus Westerlund for their help with 429 resolving problems regarding the Admission Priority and the ALRP 430 parameter. 432 Elwyn Davies provided a detailed review of the specification. Elwyn 433 helped to investigate what QoS mechanisms are deployed in networks 434 today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu 435 provided help with the semantic of some QSPEC parameters. 437 We would like to thank Dan Romascanu for his detailed Area Director 438 review comments and Scott Bradner for his Transport Area Directorate 439 review. 441 8. References 443 8.1. Normative References 445 [I-D.ietf-tsvwg-emergency-rsvp] 446 Faucheur, F., Polk, J., and K. Carlberg, "Resource 447 ReSerVation Protovol (RSVP) Extensions for Emergency 448 Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in 449 progress), October 2008. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 455 Services", RFC 2210, September 1997. 457 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 458 Parameters for Integrated Service Network Elements", 459 RFC 2215, September 1997. 461 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 462 "Definition of the Differentiated Services Field (DS 463 Field) in the IPv4 and IPv6 Headers", RFC 2474, 464 December 1998. 466 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 467 Schoenwaelder, Ed., "Structure of Management Information 468 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 470 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 471 "Assured Forwarding PHB Group", RFC 2597, June 1999. 473 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 474 "Per Hop Behavior Identification Codes", RFC 3140, 475 June 2001. 477 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 478 RFC 3181, October 2001. 480 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 481 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 482 June 2005. 484 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 485 Priority for the Session Initiation Protocol (SIP)", 486 RFC 4412, February 2006. 488 8.2. Informative References 490 [I-D.ietf-nsis-qspec] 491 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 492 Template", draft-ietf-nsis-qspec-21 (work in progress), 493 November 2008. 495 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 496 and W. Weiss, "An Architecture for Differentiated 497 Services", RFC 2475, December 1998. 499 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 500 Marker", RFC 2697, September 1999. 502 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 503 Informal Management Model for Diffserv Routers", RFC 3290, 504 May 2002. 506 [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 507 Differentiated Services-aware MPLS Traffic Engineering", 508 RFC 3564, July 2003. 510 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 511 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 512 May 2008. 514 Authors' Addresses 516 Jouni Korhonen (editor) 517 Nokia Siemens Networks 518 Linnoitustie 6 519 Espoo 02600 520 Finland 522 Email: jouni.korhonen@nsn.com 524 Hannes Tschofenig 525 Nokia Siemens Networks 526 Linnoitustie 6 527 Espoo 02600 528 Finland 530 Phone: +358 (50) 4871445 531 Email: Hannes.Tschofenig@gmx.net 532 URI: http://www.tschofenig.priv.at