idnits 2.17.1 draft-geib-tsvwg-diffserv-intercon-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 67 lines 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 24, 2013) is 3956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.polk-tsvwg-rfc4594-update' is defined on line 535, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-10 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG R. Geib, Ed. 2 Internet-Draft Deutsche Telekom 3 Intended status: Informational June 24, 2013 4 Expires: December 26, 2013 6 DiffServ interconnection classes and practice 7 draft-geib-tsvwg-diffserv-intercon-03 9 Abstract 11 This document proposes a limited set of interconnection QoS PHBs and 12 PHB groups. It further introduces some DiffServ deployment aspects. 13 The proposals made here should be integrated into a revised version 14 of RFC5127. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 26, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. An Interconnection class and codepoint scheme . . . . . . . . 5 54 4. Consolidation of QoS standards by the interconnection 55 codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. MPLS, Ethernet and Class Selector Codepoints for 57 aggregated classes . . . . . . . . . . . . . . . . . . . . . . 9 58 6. QoS class name selection . . . . . . . . . . . . . . . . . . . 10 59 7. Allow for DiffServ extendibility on MPLS and Ethernet level . 11 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 13 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Introduction 71 This draft proposes a DiffServ interconnection class and codepoint 72 scheme. At least one party of an interconnection often is a network 73 provider. Many network providers operate Aggregated DiffServ 74 classes. This draft contains concepts and current practice relevant 75 for a revised version of RFC5127 [RFC5127]. Its main purpose is to 76 be considered as an input for the latter task. 78 DiffServ sees deployment in many networks for the time being. As 79 described in the introduction of the draft DiffServ problem statement 80 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of 81 packets at domain boundaries is a DiffServ feature. This draft 82 proposes a set of standard QoS classes and codepoints at 83 interconnection points to which and from which locally used classes 84 and codepoints should be mapped. Such a scheme simplifies 85 interconnection negotiations and ensures that end to end class 86 properties remain roughly the same while codepoints may change. 88 The proposed Interconnection class and codepoint scheme tries to 89 reflect and consolidate related DiffServ and QoS standardisation 90 efforts outside of the IETF, namely MEF, GSMA and ITU. 92 IP Precedence has been deprecated when DiffServ was standardised. It 93 is common practice today however to copy the DSCPs Bits 0-2 (called 94 Class Selector Codepoints in the following) into MPLS TC or Ethernet 95 P-Bits. This is also reflected by the DiffServ codepoint definitions 96 of AF and EF. The Class Selector Codepoints shouldn't be used for 97 backward compatibility only. Class based PHBs may be applied in core 98 network sections rather than then DSCP based PHBs. 100 The set of available router and traffic management tools to configure 101 and operate DiffServ classes is limited. This should be reflected by 102 class definitions. These may in the end be more related to transport 103 properties than to application requirements. Please interpret 104 transport properties as "congestion aware" and "not congestion aware" 105 rather then TCP or UDP. 107 Finally, this draft proposes to leave some lass Selector Codepoint 108 and by that MPLS TC codepoint space to allow for future DiffServ 109 extensions like ECN/PCN and domain internal classes. An example for 110 an internal PHB may be CS6. Some operators protect their network 111 internal routing and / or management traffic by CS6. This PHB is 112 possibly not available to transport customer or interconnection 113 partner signaling and management traffic. 115 In addition to the standardisation activities which triggered this 116 work, other authors published RFCs or drafts which may benefit from 117 an interconnection class- and codepoint scheme. RFC 5160 suggests 118 Meta-QoS-Classes to enable deployment of standardised end to end QoS 119 classes [RFC5160]. The authors agree that the proposed 120 interconnection class- and codepoint scheme as well as the idea of 121 standardised end to end classes would complement their own work. 122 Work on signaling Class of Service at interconnection interfaces by 123 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the 124 scope of this draft. Should the basic transport and class properties 125 be standardised as proposed here, signaled access to QoS classes may 126 be of interest. The current BGP drafts focus on exchanging SLA and 127 traffic conditioning parameters. They seem to assume that common 128 interpretation of the PHB properties identified by DSCPs has been 129 established prior to exchanging further details by BGP signaling. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 2. Terminology 139 This draft re-uses existing terminology. 141 Class Selector Codepoints The bits 0-2 of the DSCP (marked "x" in 142 this generic DSCP field: xxx000) are called the Class 143 Selector Codepoints [RFC2474]. As their purpose is not just 144 backwards compatibility, they are used to enable IP to MPLS 145 DiffServ interoperability. 147 Class A class is a set of one or more PHBs utilising the same PHB 148 if classified by a single identical Class Selector Codepoint 149 (e.g. an AF class [RFC2597]). It is a PHB Scheduling Class 150 [RFC3260] or an Ordered Aggregate. A class is a PHB group 151 [RFC2575]. Different classes must not be aggregated. 153 PHB On IP layer, a single DSCP identifies a single PHB. In 154 addition, this document proposes an MPLS like classification 155 of traffic for a single PHB based on the Class Selector 156 Codepoint (see [RFC3270]). 158 The above references may be incomplete and mostly refer to the early 159 DiffServ RFCs only. 161 On MPLS layer, the available DiffServ Coding space is called Traffic 162 Class (TC) [RFC5462]. A Class Selector Codepoint may be set to the 163 same value as the MPLS TC. This allows MPLS DiffServ treatment by 164 MPLS routers if a DSCP is at packet top after a Pen Ultimate Hop 165 label pop (which seems to be best practice by the time of writing). 166 Note that supporting Class Selector Codepoint based DiffServ means 167 support of MPLS like DiffServ only. This document neither argues for 168 nor supports any scheme based on two 3 bit field based PHB assignment 169 on IP layer. 171 To gain clarity, "DSCP based PHB selection" is only meant if 172 expressed exactly that way in the remaining document. "PHB" relates 173 to Class Selector Codepoint based PHB selection. 175 The following current practice issues relate to the concept of the 176 DiffServ interconnection class proposal rather than to terminology. 177 They serve as additional motivation of this activity: 179 o Abstract class names like "EF" are preferential over those being 180 close to an application, like "Voice". Unfortunately, non QoS 181 experts can't handle abstract class names. Hence and usually 182 sooner than later, classes are named for applications or groups of 183 them. One consequence however is, that people tend to combine 184 application group class names and SLA parameters. Based on an 185 application specific name and some worst case performance numbers 186 on a paper, they often decide that their application needs a 187 separate new QoS class. 189 o Worse than that, but very present in practice, is the class 190 abstraction level which is preferred by those dealing with QoS (as 191 experts or non experts): the DSCPs or the Class Selector 192 Codepoints values. These are the commodity abstractions applied 193 for QoS classes. Most of these persons have fixed class to 194 codepoint mappings in their minds, which they can't easily adapt 195 on per customer or per interconnection partner basis. 197 While these issues aren't to be solved by IETF (QoS experts could and 198 should of course teach staff to use proper Diffserv terminology and 199 concepts), a simple and comprehensible QoS interconnection class 200 scheme also is helpful in this area. 202 3. An Interconnection class and codepoint scheme 204 DiffServ deployments mostly follow loose class specification schemes 205 (often one or two AF classes, EF and Best Effort). Especially DSCP 206 assignment for the AF classes varies between deployments. Basic AF 207 class property definitions are often similar however. Applying 208 provider specific DSCPs is in line with the DiffServ architecture. 209 This document doesn't propose to change that. 211 Interconnecting parties face the problem of matching classes to be 212 interconnected and then to agree on codepoint mapping. As stated by 213 draft DiffServ problem statement 214 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a 215 standard behaviour at interconnection interfaces. This draft 216 proposes a standard interconnection set of 4 QoS classes with well 217 defined DSCP and Class Selector Codepoints values A sending party 218 remarks DSCPs from internal schemes to the Interconnection 219 codepoints. The receiving party remarks Class Selector Codepoints 220 and / or DSCPs to her internal scheme. Thus the interconnection 221 codepoint scheme fully complies with the DiffServ architecture. An 222 interconnection class and codepoint scheme was introduced by ITU-T 223 [Y.1566] (there also including Ethernet). It is specified to a 224 higher level of detail in this document. 226 At first glance, this looks like an additional effort. But there are 227 obvious benefits: each party sending or receiving traffic has to 228 specify the mapping from or to the interconnection class and 229 codepoint scheme only once. Without it, this is to be negotiated per 230 interconnection party individually. Further, end-to-end QoS in terms 231 of traffic being classified for the same class in all passed domains 232 is likely to result if an interconnection codepoint scheme is used. 233 It is not necessarily resulting from individual per network mapping 234 negotiations. 236 The standards and deployments known to the author of this draft are 237 limited to 4 DiffServ classes at interconnection points (or 238 less).Draft RFC 4597 update [I-D.polk-tsvwg-rfc4594-update]doesn't 239 seem to generally contradict to this, as it proposes to standardise 240 "many services classes, not all will be used in each network at any 241 period of time." Some reasons favour working with 4 DiffServ 242 interconnection classes: 244 o There should be a coding reserve for interconnection classes. 245 This leaves space for future standards, for private bilateral 246 agreements and for provider internal classes. 248 o MPLS and Ethernet support only 8 PHBs, classes or ECN indications. 249 Assignment of 3 bit codepoints for whatever purpose must be well 250 thought through. Limiting interconnection QoS to four classes is 251 MPLS and Ethernet friendly in that sense. 253 o Migrations from one codepoint scheme to another may require spare 254 QoS codepoints. 256 The proposed class and codepoint scheme is designed for point to 257 point IP layer interconnections. Other types of interconnections are 258 out of scope of this document. The basic class and codepoint scheme 259 is applicable on Ethernet layer too. 261 4. Consolidation of QoS standards by the interconnection codepoint 262 scheme 264 The interconnection class and codepoint scheme proposed by Y.1566 265 also tries to consolidate related DiffServ and QoS standardisation 266 efforts outside of the IETF [Y.1566]. The interconnection class and 267 codepoint scheme may be a suitable approach to consolidate these 268 standards. MEF 23.1 specifies 3 aggregated classes, consuming up to 269 5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5 270 PHBs [MEF23.1]. MEF aggregates AF1 and Default PHB in a single 271 class. This is not recommended for interconnection, as it is not in 272 line with RFC 2597 (which requires separate forwarding resources for 273 each AF class and doesn't foresee aggregation of Default PHB and an 274 AF class). 276 GSMA IR.34 proposes four classes, EF, AF4, another AF class and Best 277 Effort with 7 PHBs in sum [IR.34]. IR.34 specifies an "Interactive" 278 class consisting of 3 PHBs with different priorities. IR.34 assigns 279 the PHBS AF31, AF21 and AF11 to this Interactive class. This breaks 280 RFC 2597. The proposed interconnection class and codepoint scheme 281 supports an GSMA Interactive like class but assigns AF3 with PHBs 282 AF31, AF32 and AF33. 284 If IETF picks up this draft, it may be a good idea to inform MEF and 285 GSMA about conflicts of their standards with DiffServ and suggest 286 joint activities to improve the situation. Information on 287 interworking with MEF 23 and GSMA IR.34 with the interconnection QoS 288 scheme could be given by a later version of this draft. 290 The classes to be supported at interconnection interfaces are 291 specified by Y.1566 as: 293 Class Priority: EF, expecting the figures of merit describing the 294 PHB to be in the range of low single digit milliseconds. See 295 [RFC3246]. 297 Bulk inelastic: Optimised for low loss, low delay, low jitter at 298 high bandwidth. Traffic load in this class must be 299 controlled, e.g. by application servers. One example could 300 be flow admission control. There may be infrequent 301 retransmissions requested by the application layer to 302 mitigate low levels of packet losses. Discard of packets 303 through active queue management should be avoided in this 304 class. Congestion in this class may result in bursty packet 305 loss. If used to carry multimedia traffic, it is recommended 306 to carry audio and video traffic in a single PHB. All of 307 these properties influence the buffer design. 309 Assured: This class may be optimised to transport traffic without 310 bandwidth requirements. It aims on Very low loss at high 311 bandwidths. Retransmissions after losses characterise the 312 class and influence the buffer design. Active queue 313 management with probabilistic dropping may be deployed. 315 Default: Default. This class may be optimised to transport traffic 316 without bandwidth requirements. Retransmissions after losses 317 characterise the class and influence the buffer design. 318 Active queue management with probabilistic dropping may be 319 deployed. 321 Note that other DiffServ related standards trim down class 322 requirements to SLA parameters. To quote e.g. RFC 4594-update, "A 323 "service class" represents a similar set of traffic characteristics 324 for delay, loss, and jitter as packets traverse routers in a 325 network." This draft adds traffic PHB properties corresponding to 326 expected transport layer characteristics as a key factor to a class 327 definition: the desired class performance like delay, jitter and 328 worst case loss are met only if PHB and transport properties meet the 329 ones described by the class definition. This is not to say, the 330 other standards ignore PHB properties. They are e.g. a core part of 331 RFC 4594-update. They do not directly refer to transport protocol 332 properties, as most existing QoS standards prefer the approach of 333 assigning QoS classes to applications or application sets. This may 334 result in undesirable class mappings, if an e.g. IP TV application 335 demanding low loss is matched to a class whose low loss guarantees 336 depend on AQM mechanisms. 338 Y.1566 does not define a complete set of DSCP based PHBs to be 339 supported at an interconnection interface. This information is added 340 by this draft. At interconnection points, the following DSCP based 341 PHBs should be accepted between interconnected parties: 343 Class: PHB (one or more) 345 Class Priority: EF 347 Bulk inelastic: AF41 (AF42 and AF43 are reserved for extension) 349 Assured: AF31, AF32 and AF33 350 Default: Default (i.e. Best Effort) 352 Class names (and property specification) have been picked from Y.1566 353 above. 355 A provider may prefer to operate an internal PHB for the routing and 356 management traffic of own systems. The PHB may not be available for 357 traffic of peers or customers classified for the same HB within their 358 networks. By default, many routers mark this traffic by CS6. 359 Several scenarios are possible: 361 o CS6 marked traffic originating within a domain should be mapped to 362 a suitable PHB at interconnection interfaces, if the receiving 363 provider isn't offering transport with CS6. AF31 is recommended 364 to that purpose. 366 o BGP traffic terminating in the adjacent AS border router could 367 carry any codepoint whose traffic is not dropped by the receiving 368 AS border router. 370 o An AS border router may not be able to mark BGP traffic by any 371 different DSCP than CS6 and this traffic might be destined to a 372 distant BGP peer, like a routing arbiter. In that case, the 373 interconnecting parties should negotiate the treatment of this 374 traffic. Standard DiffServ remarking, picking e.g. AF31 or Best 375 Effort are possible options. 377 Operating a provider internal network management and routing class is 378 an option only. Providers may of course bilaterally agree to 379 exchange CS6 marked traffic without changing the DSCP. 381 Maintaining a separate PHB for network management, routing or 382 signaling traffic also for traffic transiting through or terminating 383 in a remote AS may be desirable. AF31 is recommended to that 384 purpose. This is simple in the case of VPNs or point to point 385 services. If this traffic is multiplexed with arbitrary traffic 386 using this DSCP based PHB, distinction by the codepoint only isn't 387 possible any more. Hence a standard agreement would best solve the 388 issue. This document recommends picking an Assured class DSCP based 389 PHB, AF31. 391 5. MPLS, Ethernet and Class Selector Codepoints for aggregated classes 393 Ethernet and MPLS support 3 bit codepoint fields to differentiate 394 service quality. Mapping of the Class Selector Codepoints to these 3 395 Bit fields has been a configuration restriction in the early days of 396 DiffServ. The concept of classifying DiffServ traffic classes by the 397 bits 0-2 of a DSCP has however been part of Diffserv from start on. 398 EF's Class Selector Codepoints is 5, that of AF4 is 4 and so on. The 399 interconnection class and codepoint scheme respects properties and 400 limits of a 3 bit PHB coding space in different ways: 402 o it allows to classify four interconnection classes based on Class 403 Selector Codepoints. 405 o it supports a single PHB group (AF3), whose DSCP based PHBs may be 406 mapped to up to three different MPLS TC's or Ethernet P-Bits. 407 Note that this draft doesn's favour or recommend doing that, but 408 it is possible. The author isn't aware of deployed service offers 409 with 3 different drop levels in a single class. 411 The above statement is no requirement to depricate any DSCP to MPLS 412 TC or Ethernet P-Bit mapping functionality. In the opposite, by 413 limiting the interconnection scheme to 7 DSCP based PHBs, each PHB 414 may be mapped to a 3 Bit based PHB scheme. 416 6. QoS class name selection 418 This is more of an informational discussion, proposed best practice, 419 and mainly relates to human behaviour (including QoS experts) rather 420 than technical issues. Above the human preference for conceivable 421 class names has been mentioned. Network engineers (including the 422 former Diffserv WG authors) recommend avoiding application related 423 QoS class names. Focus should be put on class properties. These can 424 be irritating again. Just looking at SLA parameters like Delay, 425 Jitter and packet loss doesn't tell the reader, which transport 426 properties guided the related scheduler engineering of a PHB. A 427 router produces QoS with a scheduling mechanism, a settable queue 428 depth and optional active queue management (including ECN), and may 429 be a policer. Some kind of resource management may be present (also 430 in Diffserv domains). It's beyond the imagination of the author how 431 one would engineer more than half a dozen classes with 432 distinguishable properties using this set of tools. 434 There's no perfect solution to the problem, as PHB configurations are 435 not comprehensible to most readers, even if they were communicated 436 (they are operational secrets of course). There are (or should be) 437 engineering assumptions, when designing QoS PHBs. They closer relate 438 to layer 3 or layer 4 level properties than to specific applications. 439 In most cases, an application responds to congestion by reducing 440 traffic, or it ignores congestion. Active queue management doesn't 441 help to avoid congestion in the latter case, only resource management 442 does. EF may be a special case. If the EF traffic is not responsive 443 to congestion, and packets are assumed to be short, rather small 444 jitter values can be reached if engineering ensures that the packet 445 arrival rate never exceeds the transmission rate of that queue (see 446 RFC 3246 [RFC3246]). There's other non congestion-responsive 447 traffic, for which the EF engineering assumptions may not fit. So 448 support of a PHB like bulk inelastic is reasonable. 450 Active queue management may be deployed for QoS classes designed to 451 transport traffic responding to congestion by traffic reduction. 453 The class names of this document follow Y.1566. TCP_optimised and 454 especially UDP_optimised are inappropriate class names, as some UDP 455 based applications are or may be expected to become TCP friendly. 457 7. Allow for DiffServ extendibility on MPLS and Ethernet level 459 Any aggregated Diffserv deployment faces codepoint depletion issues 460 rather soon, if deployed on MPLS or Ethernet. Coding space should be 461 left for new features, like ECN, PCN or Conex. In addition to 462 carrying customer traffic, internal routing and network management 463 traffic may be protected by using a separate class. Offering 464 interconnection with up to four classes and 4 - 6 MPLS TC's (or 465 Ethernet P-bits) to that respect is probably at least a fair 466 compromise. 468 8. Acknowledgements 470 David Black gave many helpful comments to this work. Al Morton and 471 Sebastien Jobert provided feedback on many aspects during private 472 discussions. Brian Carpenter, Mohamed Boucadair and Thomas Knoll 473 helped adding awareness of further potentially related work. 475 9. IANA Considerations 477 This memo includes no request to IANA. 479 10. Security Considerations 481 This document does not introduce new features, it describes how to 482 use existing ones. The security section of RFC 4597 [RFC4597] 483 applies. 485 11. References 486 11.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 492 "Definition of the Differentiated Services Field (DS 493 Field) in the IPv4 and IPv6 Headers", RFC 2474, 494 December 1998. 496 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 497 Access Control Model (VACM) for the Simple Network 498 Management Protocol (SNMP)", RFC 2575, April 1999. 500 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 501 "Assured Forwarding PHB Group", RFC 2597, June 1999. 503 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 504 J., Courtney, W., Davari, S., Firoiu, V., and D. 505 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 506 Behavior)", RFC 3246, March 2002. 508 [RFC3260] Grossman, D., "New Terminology and Clarifications for 509 Diffserv", RFC 3260, April 2002. 511 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 512 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 513 Protocol Label Switching (MPLS) Support of Differentiated 514 Services", RFC 3270, May 2002. 516 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 517 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 518 Class" Field", RFC 5462, February 2009. 520 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 522 11.2. Informative References 524 [I-D.knoll-idr-cos-interconnect] 525 Knoll, T., "BGP Class of Service Interconnection", 526 draft-knoll-idr-cos-interconnect-10 (work in progress), 527 May 2013. 529 [I-D.polk-tsvwg-diffserv-stds-problem-statement] 530 Polk, J., "The Problem Statement for the Standard 531 Configuration of DiffServ Service Classes", 532 draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work 533 in progress), July 2012. 535 [I-D.polk-tsvwg-rfc4594-update] 536 Polk, J., "Standard Configuration of DiffServ Service 537 Classes", draft-polk-tsvwg-rfc4594-update-03 (work in 538 progress), March 2013. 540 [ID.idr-sla] 541 IETF, "Inter-domain SLA Exchange", IETF, http:// 542 datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, 543 2013. 545 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 546 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ 547 /www.gsma.com/newsroom/wp-content/uploads/2012/03/ 548 ir.34.pdf, 2012. 550 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 551 Class of Service Phase 2", MEF, MEF23.1 http:// 552 metroethernetforum.org/PDF_Documents/ 553 technical-specifications/MEF_23.1.pdf, 2012. 555 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 556 RFC 4597, August 2006. 558 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 559 Diffserv Service Classes", RFC 5127, February 2008. 561 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 562 to-Provider Agreements for Internet-Scale Quality of 563 Service (QoS)", RFC 5160, March 2008. 565 [Y.1566] ITU-T, "Quality of service mapping and interconnection 566 between Ethernet, IP and multiprotocol label switching 567 networks", ITU, 568 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 570 Appendix A. Change log 572 00 to 01 Added terminology and references. Added details and 573 information to interconnection class and codepoint scheme. 574 Editorial changes. 576 01 to 02 Added some references regarding related work. Clarified 577 class definitions. Further editorial improvements. 579 02 to 03 Consistent terminology. Discussion of Network Management 580 PHB at interconnection interfaces. Editorial review. 582 Author's Address 584 Ruediger Geib (editor) 585 Deutsche Telekom 586 Heinrich Hertz Str. 3-7 587 Darmstadt, 64295 588 Germany 590 Phone: +49 6151 5812747 591 Email: Ruediger.Geib@telekom.de