idnits 2.17.1 draft-geib-tsvwg-diffserv-intercon-04.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: ---------------------------------------------------------------------------- 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 date (October 18, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5462' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'I-D.polk-tsvwg-rfc4594-update' is defined on line 577, 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 (~~), 4 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 October 18, 2013 4 Expires: April 21, 2014 6 DiffServ interconnection classes and practice 7 draft-geib-tsvwg-diffserv-intercon-04 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 April 21, 2014. 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. Aggregating PHBs of a class by a DSCP Precedence Prefix . . . 5 54 4. An Interconnection class and codepoint scheme . . . . . . . . 6 55 5. Consolidation of QoS standards by the interconnection 56 codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Treatment of Network Control traffic at carrier 58 interconnection interfaces . . . . . . . . . . . . . . . . . . 9 59 7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated 60 classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 8. QoS class name selection . . . . . . . . . . . . . . . . . . . 11 62 9. Allow for DiffServ extendibility on MPLS and Ethernet level . 12 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 This draft proposes a DiffServ interconnection class and codepoint 75 scheme. At least one party of an interconnection often is a network 76 provider. Many network providers operate Aggregated DiffServ 77 classes. This draft contains concepts and current practice relevant 78 for a revised version of RFC5127 [RFC5127]. Its main purpose is to 79 be considered as an input for the latter task. 81 DiffServ sees deployment in many networks for the time being. As 82 described in the introduction of the draft DiffServ problem statement 83 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of 84 packets at domain boundaries is a DiffServ feature. This draft 85 proposes a set of standard QoS classes and codepoints at 86 interconnection points to which and from which locally used classes 87 and codepoints should be mapped. Such a scheme simplifies 88 interconnection negotiations and ensures that end to end class 89 properties remain roughly the same while codepoints may change. 91 The proposed Interconnection class and codepoint scheme tries to 92 reflect and consolidate related DiffServ and QoS standardisation 93 efforts outside of the IETF, namely MEF, GSMA and ITU. 95 IP Precedence has been deprecated when DiffServ was standardised. It 96 is common practice today however to copy the DSCPs Bits 0-2 (called 97 DSCP Precedence Prefix in the following) into MPLS TC or Ethernet 98 P-Bits. This is also reflected by the DiffServ codepoint definitions 99 of AF and EF. Class based PHBs may be applied in core network 100 sections rather than then DSCP based PHBs. 102 The set of available router and traffic management tools to configure 103 and operate DiffServ classes is limited. This should be reflected by 104 class definitions. These may in the end be more related to transport 105 properties than to application requirements. Please interpret 106 transport properties as "congestion aware" and "not congestion aware" 107 rather then TCP or UDP. 109 Finally, this draft proposes to leave some lass Selector Codepoint 110 and by that MPLS TC codepoint space to allow for future DiffServ 111 extensions like ECN/PCN and domain internal classes. An example for 112 an internal PHB may be CS6. Some operators protect their network 113 internal routing and / or management traffic by CS6. This PHB is 114 possibly not available to transport customer or interconnection 115 partner signaling and management traffic. 117 In addition to the standardisation activities which triggered this 118 work, other authors published RFCs or drafts which may benefit from 119 an interconnection class- and codepoint scheme. RFC 5160 suggests 120 Meta-QoS-Classes to enable deployment of standardised end to end QoS 121 classes [RFC5160]. The authors agree that the proposed 122 interconnection class- and codepoint scheme as well as the idea of 123 standardised end to end classes would complement their own work. 124 Work on signaling Class of Service at interconnection interfaces by 125 BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the 126 scope of this draft. Should the basic transport and class properties 127 be standardised as proposed here, signaled access to QoS classes may 128 be of interest. The current BGP drafts focus on exchanging SLA and 129 traffic conditioning parameters. They seem to assume that common 130 interpretation of the PHB properties identified by DSCPs has been 131 established prior to exchanging further details by BGP signaling. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Terminology 141 This draft re-uses existing terminology. 143 DSCP Precedence Prefix The bits 0-2 of the DSCP (marked "x" in this 144 generic DSCP field: xxxddd) are called the DSCP Precedence 145 Prefix [RFC2474] in the following. By ignoring the value of 146 bits 3-6 ( d stands for don' care), a simple aggregation of 147 PHBs differed by DSCP is possible in IP and MPLS backbones, 148 but also if Ethernet transport is applied. This is discussed 149 in more detail below. 151 Class A class is a set of one or more PHBs utilising the same PHB 152 if classified by a single identical DSCP Precedence Prefix 153 (e.g. an AF class [RFC2597]). It is a PHB Scheduling Class 154 [RFC3260] or an Ordered Aggregate. A class is a PHB group 155 [RFC2575]. Different classes must not be aggregated. 157 PHB On IP layer, a single DSCP identifies a single PHB. In 158 addition, this document proposes an MPLS like classification 159 of traffic for a single PHB based on the DSCP Precedence 160 Prefix (see [RFC3270]). 162 The above references may be incomplete and mostly refer to the early 163 DiffServ RFCs only. 165 To gain clarity, "DSCP based PHB selection" is only meant if 166 expressed exactly that way in the remaining document. "PHB" here 167 relates to DSCP Precedence Prefix based PHB selection. 169 The following current practice issues relate to the concept of the 170 DiffServ interconnection class proposal rather than to terminology. 171 They serve as additional motivation of this activity: 173 o Abstract class names like "EF" are preferential over those being 174 close to an application, like "Voice". Unfortunately, non QoS 175 experts can't handle abstract class names. Hence and usually 176 sooner than later, classes are named for applications or groups of 177 them. One consequence however is, that people tend to combine 178 application group class names and SLA parameters. Based on an 179 application specific name and some worst case performance numbers 180 on a paper, they often decide that their application needs a 181 separate new QoS class. 183 o Worse than that, but very present in practice, is the class 184 abstraction level which is preferred by those dealing with QoS (as 185 experts or non experts): the DSCPs or the DSCP Precedence Prefix 186 values. These are the commodity abstractions applied for QoS 187 classes. Most of these persons have fixed class to codepoint 188 mappings in their minds, which they can't easily adapt on per 189 customer or per interconnection partner basis. 191 While these issues aren't to be solved by IETF (QoS experts could and 192 should of course teach staff to use proper Diffserv terminology and 193 concepts), a simple and comprehensible QoS interconnection class 194 scheme also is helpful in this area. 196 3. Aggregating PHBs of a class by a DSCP Precedence Prefix 198 Operation of IP and MPLS networks and router configuration is 199 simplified, if DSCP based PHBs can be aggregated into a single class 200 by simply classifying them by their DSCP Precedence Prefix. As 201 specified above, the DSCP Precedence Prefix are the bits 0-2 od the 202 DSCP. If classification based on DSCP Precedence Prefix is applied 203 in an MPLS domain, the DSCP Precedence Prefix my simply be copied 204 into the MPLS TC field. This is very useful in domains operating 205 Pen-ultimate hop popping. Also in this case, operation and 206 configuration of routers can be simplified significantly as compared 207 to aggregation schemes based on configuring individual DSCPs. 209 A network provider applying DSCP Precedence Prefix based aggregation 210 MAY remark incoming DSCPs so that they can be aggregated by their 211 DSCP Precedence Prefix. To allow for simple carrier interconnection 212 agreements, carriers sending traffic belonging to the same class but 213 marked by DSCPs with differing DSCP Precedence Prefixes SHOULD apply 214 the interconnection marking and codepoint scheme specified below, if 215 they interconnect to a carrier applying DSCP Precedence Prefix based 216 traffic aggregation. An example where this may be required is the 217 Interactive Class of GSMA IR.34 [IR.34] (note that the author of this 218 draft believes that the GSMA specification is breaking RFC 2597). 219 Another option is to negotiate a customised interconnection agreement 220 of course. 222 A node forwarding traffic based the DSCP Precedence Prefix MUST 223 classify this traffic by the DSCP bits 0-2 and it MUST ignore the 224 bits 4-6 of DSCP for classification. Classification by DSCP 225 Precedence Prefix is useful for links aggregating DiffServ traffic. 226 DSCP Precedence Prefix based classification is not recommended as a 227 general mode of operation. Edge systems, QoS policy enforcement 228 nodes, service areas and hosts benefit from fine grained DSCP based 229 classification and should continue to do so. 231 RFC 2474 specifies the Class Selector Codepoints [RFC2474]. These 232 offer a similar concept, but they are strictly limited to xxx000 233 DSCPs. The Class Selector Codepoints don't offer aggregation, they 234 just simplify classification. This draft intents to aggregate 235 several PHBs of a single class by a DSCP Precedence Prefix, which a 236 different concept than that of the Class Selector Codepoints. 238 4. An Interconnection class and codepoint scheme 240 DiffServ deployments mostly follow loose class specification schemes 241 (often one or two AF classes, EF and Best Effort). Especially DSCP 242 assignment for the AF classes varies between deployments. Basic AF 243 class property definitions are often similar however. Applying 244 provider specific DSCPs is in line with the DiffServ architecture. 245 This document doesn't propose to change that. 247 Interconnecting parties face the problem of matching classes to be 248 interconnected and then to agree on codepoint mapping. As stated by 249 draft DiffServ problem statement 250 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a 251 standard behaviour at interconnection interfaces. This draft 252 proposes a standard interconnection set of 4 QoS classes with well 253 defined DSCP and DSCP Precedence Prefix values. A sending party 254 remarks DSCPs from internal schemes to the Interconnection 255 codepoints. The receiving party remarks DSCP Precedence Prefixes and 256 / or DSCPs to her internal scheme. Thus the interconnection 257 codepoint scheme fully complies with the DiffServ architecture. An 258 interconnection class and codepoint scheme was introduced by ITU-T 259 [Y.1566] (there also including Ethernet). It is specified to a 260 higher level of detail in this document. 262 At first glance, this looks like an additional effort. But there are 263 obvious benefits: each party sending or receiving traffic has to 264 specify the mapping from or to the interconnection class and 265 codepoint scheme only once. Without it, this is to be negotiated per 266 interconnection party individually. Further, end-to-end QoS in terms 267 of traffic being classified for the same class in all passed domains 268 is likely to result if an interconnection codepoint scheme is used. 269 It is not necessarily resulting from individual per network mapping 270 negotiations. 272 The standards and deployments known to the author of this draft are 273 limited to 4 DiffServ classes at interconnection points (or 274 less).Draft RFC 4597 update [I-D.polk-tsvwg-rfc4594-update]doesn't 275 seem to generally contradict to this, as it proposes to standardise 276 "many services classes, not all will be used in each network at any 277 period of time." Some reasons favour working with 4 DiffServ 278 interconnection classes: 280 o There should be a coding reserve for interconnection classes. 281 This leaves space for future standards, for private bilateral 282 agreements and for provider internal classes. 284 o MPLS and Ethernet support only 8 PHBs, classes or ECN indications. 285 Assignment of 3 bit codepoints for whatever purpose must be well 286 thought through. Limiting interconnection QoS to four classes is 287 MPLS and Ethernet friendly in that sense. 289 o Migrations from one codepoint scheme to another may require spare 290 QoS codepoints. 292 The proposed class and codepoint scheme is designed for point to 293 point IP layer interconnections. Other types of interconnections are 294 out of scope of this document. The basic class and codepoint scheme 295 is applicable on Ethernet layer too. 297 5. Consolidation of QoS standards by the interconnection codepoint 298 scheme 300 The interconnection class and codepoint scheme proposed by Y.1566 301 also tries to consolidate related DiffServ and QoS standardisation 302 efforts outside of the IETF [Y.1566]. The interconnection class and 303 codepoint scheme may be a suitable approach to consolidate these 304 standards. MEF 23.1 specifies 3 aggregated classes, consuming up to 305 5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5 306 PHBs [MEF23.1]. MEF aggregates AF1 and Default PHB in a single 307 class. This is not recommended for interconnection, as it is not in 308 line with RFC 2597 (which requires separate forwarding resources for 309 each AF class and doesn't foresee aggregation of Default PHB and an 310 AF class). 312 GSMA IR.34 proposes four classes, EF, AF4, another AF class and Best 313 Effort with 7 PHBs in sum [IR.34]. IR.34 specifies an "Interactive" 314 class consisting of 3 PHBs with different priorities. IR.34 assigns 315 the PHBS AF31, AF21 and AF11 to this Interactive class. This breaks 316 RFC 2597. The proposed interconnection class and codepoint scheme 317 supports an GSMA Interactive like class but assigns AF3 with PHBs 318 AF31, AF32 and AF33. 320 If IETF picks up this draft, it may be a good idea to inform MEF and 321 GSMA about conflicts of their standards with DiffServ and suggest 322 joint activities to improve the situation. Information on 323 interworking with MEF 23 and GSMA IR.34 with the interconnection QoS 324 scheme could be given by a later version of this draft. 326 The classes to be supported at interconnection interfaces are 327 specified by Y.1566 as: 329 Class Priority: EF, expecting the figures of merit describing the 330 PHB to be in the range of low single digit milliseconds. See 331 [RFC3246]. 333 Bulk inelastic: Optimised for low loss, low delay, low jitter at 334 high bandwidth. Traffic load in this class must be 335 controlled, e.g. by application servers. One example could 336 be flow admission control. There may be infrequent 337 retransmissions requested by the application layer to 338 mitigate low levels of packet losses. Discard of packets 339 through active queue management should be avoided in this 340 class. Congestion in this class may result in bursty packet 341 loss. If used to carry multimedia traffic, it is recommended 342 to carry audio and video traffic in a single PHB. All of 343 these properties influence the buffer design. 345 Assured: This class may be optimised to transport traffic without 346 bandwidth requirements. It aims on Very low loss at high 347 bandwidths. Retransmissions after losses characterise the 348 class and influence the buffer design. Active queue 349 management with probabilistic dropping may be deployed. 351 Default: Default. This class may be optimised to transport traffic 352 without bandwidth requirements. Retransmissions after losses 353 characterise the class and influence the buffer design. 354 Active queue management with probabilistic dropping may be 355 deployed. 357 Note that other DiffServ related standards trim down class 358 requirements to SLA parameters. To quote e.g. RFC 4594-update, "A 359 "service class" represents a similar set of traffic characteristics 360 for delay, loss, and jitter as packets traverse routers in a 361 network." This draft adds traffic PHB properties corresponding to 362 expected transport layer characteristics as a key factor to a class 363 definition: the desired class performance like delay, jitter and 364 worst case loss are met only if PHB and transport properties meet the 365 ones described by the class definition. This is not to say, the 366 other standards ignore PHB properties. They are e.g. a core part of 367 RFC 4594-update. They do not directly refer to transport protocol 368 properties, as most existing QoS standards prefer the approach of 369 assigning QoS classes to applications or application sets. This may 370 result in undesirable class mappings, if an e.g. IP TV application 371 demanding low loss is matched to a class whose low loss guarantees 372 depend on AQM mechanisms. 374 Y.1566 does not define a complete set of DSCP based PHBs to be 375 supported at an interconnection interface. This information is added 376 by this draft. At interconnection points, the following DSCP based 377 PHBs should be accepted between interconnected parties: 379 Class: PHB (one or more) 381 Class Priority: EF 383 Bulk inelastic: AF41 (AF42 and AF43 are reserved for extension) 385 Assured: AF31, AF32 and AF33 387 Default: Default (i.e. Best Effort) 389 Class names (and property specification) have been picked from Y.1566 390 above. 392 6. Treatment of Network Control traffic at carrier interconnection 393 interfaces 395 As specified by RFC4594, section 3.2, Network Control (NC) traffic 396 marked by CS6 is to be expected at interconnection interfaces. This 397 document does not change NC specifications of RFC4594. The latter 398 specification is detailed on domain internal NC traffic and on 399 traffic exchanged between peering points. Further, it recommends not 400 to forward CS6 marked traffic originating from user-controlled end 401 points by the NC class of a provider domain. 403 As a minor clarification to RFC4594, "peering" shouldn't be 404 interpreted in a commercial sense. The NC PHB is applicable also in 405 the case of a purchased network service based on a transit agreement 406 with an upstream provider. RFC4594 recommendations on NC traffic are 407 applicable for IP carrier interconnections in general. 409 Some CS6 traffic exchanged accross carrier interconnections will 410 terminate at the domain ingress node (e.g., if BGP is running between 411 the two routers on opposite ends of the interconnection link). 413 An IP carrier MAY limit access to the NC PHB for traffic which is 414 recognised as network control traffic relevant to the own domain. 415 Interconnecting carriers SHOULD specify treatment of CS6 marked 416 traffic received at a carrier interconnection which is to be 417 forwarded beyond the ingress node. An SLA covering the following 418 cases is recommended, if a carrier wishes to send CS6 marked traffic 419 accross an interconnection link which isn't terminating at the 420 interconnected ingress node: 422 o classification of traffic which is network control traffic for 423 both domains. This traffic SHOULD be classified for the NC PHB. 425 o classification of traffic which is network control traffic for the 426 sending domain only. This traffic SHOULD be classified for a PHB 427 offering similar properties as the NC class (e.g. AF31 as 428 specified by this document). 430 o any other CS6 marked traffic SHOULD be remarked or dropped. 432 7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes 434 Ethernet and MPLS support 3 bit codepoint fields to differentiate 435 service quality. Mapping of the DSCP Precedence Prefix to these 3 436 Bit fields has been a configuration restriction in the early days of 437 DiffServ. The concept of classifying DiffServ traffic classes by the 438 bits 0-2 of a DSCP has however been part of Diffserv from start on. 439 EF's DSCP Precedence Prefix is 5, that of AF4 is 4 and so on. The 440 interconnection class and codepoint scheme respects properties and 441 limits of a 3 bit PHB coding space in different ways: 443 o it allows to classify four interconnection classes based on Class 444 Selector Codepoints. 446 o it supports a single PHB group (AF3), whose DSCP based PHBs may be 447 mapped to up to three different MPLS TC's or Ethernet P-Bits. 448 Note that this draft doesn's favour or recommend doing that, but 449 it is possible. The author isn't aware of deployed service offers 450 with 3 different drop levels in a single class. 452 The above statement is no requirement to depricate any DSCP to MPLS 453 TC or Ethernet P-Bit mapping functionality. In the opposite, by 454 limiting the interconnection scheme to 7 DSCP based PHBs, each PHB 455 may be mapped to a 3 Bit based PHB scheme. 457 8. QoS class name selection 459 This is more of an informational discussion, proposed best practice, 460 and mainly relates to human behaviour (including QoS experts) rather 461 than technical issues. Above the human preference for conceivable 462 class names has been mentioned. Network engineers (including the 463 former Diffserv WG authors) recommend avoiding application related 464 QoS class names. Focus should be put on class properties. These can 465 be irritating again. Just looking at SLA parameters like Delay, 466 Jitter and packet loss doesn't tell the reader, which transport 467 properties guided the related scheduler engineering of a PHB. A 468 router produces QoS with a scheduling mechanism, a settable queue 469 depth and optional active queue management (including ECN), and may 470 be a policer. Some kind of resource management may be present (also 471 in Diffserv domains). It's beyond the imagination of the author how 472 one would engineer more than half a dozen classes with 473 distinguishable properties using this set of tools. 475 There's no perfect solution to the problem, as PHB configurations are 476 not comprehensible to most readers, even if they were communicated 477 (they are operational secrets of course). There are (or should be) 478 engineering assumptions, when designing QoS PHBs. They closer relate 479 to layer 3 or layer 4 level properties than to specific applications. 480 In most cases, an application responds to congestion by reducing 481 traffic, or it ignores congestion. Active queue management doesn't 482 help to avoid congestion in the latter case, only resource management 483 does. EF may be a special case. If the EF traffic is not responsive 484 to congestion, and packets are assumed to be short, rather small 485 jitter values can be reached if engineering ensures that the packet 486 arrival rate never exceeds the transmission rate of that queue (see 487 RFC 3246 [RFC3246]). There's other non congestion-responsive 488 traffic, for which the EF engineering assumptions may not fit. So 489 support of a PHB like bulk inelastic is reasonable. 491 Active queue management may be deployed for QoS classes designed to 492 transport traffic responding to congestion by traffic reduction. 494 The class names of this document follow Y.1566. TCP_optimised and 495 especially UDP_optimised are inappropriate class names, as some UDP 496 based applications are or may be expected to become TCP friendly. 498 9. Allow for DiffServ extendibility on MPLS and Ethernet level 500 Any aggregated Diffserv deployment faces codepoint depletion issues 501 rather soon, if deployed on MPLS or Ethernet. Coding space should be 502 left for new features, like ECN, PCN or Conex. In addition to 503 carrying customer traffic, internal routing and network management 504 traffic may be protected by using a separate class. Offering 505 interconnection with up to four classes and 4 - 6 MPLS TC's (or 506 Ethernet P-bits) to that respect is probably at least a fair 507 compromise. 509 10. Acknowledgements 511 David Black gave many helpful comments to this work. Al Morton and 512 Sebastien Jobert provided feedback on many aspects during private 513 discussions. Brian Carpenter, Mohamed Boucadair and Thomas Knoll 514 helped adding awareness of further potentially related work. 516 11. IANA Considerations 518 This memo includes no request to IANA. 520 12. Security Considerations 522 This document does not introduce new features, it describes how to 523 use existing ones. The security section of RFC 4597 [RFC4597] 524 applies. 526 13. References 528 13.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 534 "Definition of the Differentiated Services Field (DS 535 Field) in the IPv4 and IPv6 Headers", RFC 2474, 536 December 1998. 538 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 539 Access Control Model (VACM) for the Simple Network 540 Management Protocol (SNMP)", RFC 2575, April 1999. 542 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 543 "Assured Forwarding PHB Group", RFC 2597, June 1999. 545 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 546 J., Courtney, W., Davari, S., Firoiu, V., and D. 547 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 548 Behavior)", RFC 3246, March 2002. 550 [RFC3260] Grossman, D., "New Terminology and Clarifications for 551 Diffserv", RFC 3260, April 2002. 553 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 554 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 555 Protocol Label Switching (MPLS) Support of Differentiated 556 Services", RFC 3270, May 2002. 558 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 559 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 560 Class" Field", RFC 5462, February 2009. 562 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 564 13.2. Informative References 566 [I-D.knoll-idr-cos-interconnect] 567 Knoll, T., "BGP Class of Service Interconnection", 568 draft-knoll-idr-cos-interconnect-10 (work in progress), 569 May 2013. 571 [I-D.polk-tsvwg-diffserv-stds-problem-statement] 572 Polk, J., "The Problem Statement for the Standard 573 Configuration of DiffServ Service Classes", 574 draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work 575 in progress), July 2012. 577 [I-D.polk-tsvwg-rfc4594-update] 578 Polk, J., "Standard Configuration of DiffServ Service 579 Classes", draft-polk-tsvwg-rfc4594-update-03 (work in 580 progress), March 2013. 582 [ID.idr-sla] 583 IETF, "Inter-domain SLA Exchange", IETF, http:// 584 datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, 585 2013. 587 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 588 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ 589 /www.gsma.com/newsroom/wp-content/uploads/2012/03/ 590 ir.34.pdf, 2012. 592 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 593 Class of Service Phase 2", MEF, MEF23.1 http:// 594 metroethernetforum.org/PDF_Documents/ 595 technical-specifications/MEF_23.1.pdf, 2012. 597 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 598 RFC 4597, August 2006. 600 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 601 Diffserv Service Classes", RFC 5127, February 2008. 603 [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- 604 to-Provider Agreements for Internet-Scale Quality of 605 Service (QoS)", RFC 5160, March 2008. 607 [Y.1566] ITU-T, "Quality of service mapping and interconnection 608 between Ethernet, IP and multiprotocol label switching 609 networks", ITU, 610 http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. 612 Appendix A. Change log 614 00 to 01 Added terminology and references. Added details and 615 information to interconnection class and codepoint scheme. 616 Editorial changes. 618 01 to 02 Added some references regarding related work. Clarified 619 class definitions. Further editorial improvements. 621 02 to 03 Consistent terminology. Discussion of Network Management 622 PHB at interconnection interfaces. Editorial review. 624 03 to 04 Again improved terminology. Better wording of Network 625 Control PHB at interconnection interfaces. 627 Author's Address 629 Ruediger Geib (editor) 630 Deutsche Telekom 631 Heinrich Hertz Str. 3-7 632 Darmstadt, 64295 633 Germany 635 Phone: +49 6151 5812747 636 Email: Ruediger.Geib@telekom.de