idnits 2.17.1 draft-geib-tsvwg-diffserv-intercon-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 2012) is 4189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-polk-tsvwg-rfc4594-update-02 Summary: 0 errors (**), 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 November 6, 2012 4 Expires: May 10, 2013 6 DiffServ interconnection classes and practice 7 draft-geib-tsvwg-diffserv-intercon-00 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 May 10, 2013. 33 Copyright Notice 35 Copyright (c) 2012 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 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. An Interconnection class and codepoint scheme . . . . . . . . . 4 66 4. Consolidation of QoS standards by the interconnection 67 codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. MPLS, Ethernet and IP Precedence for aggregated classes . . . . 6 69 6. QoS class name selection . . . . . . . . . . . . . . . . . . . 6 70 7. Allow for DiffServ extendability on MPLS and Ethernet level . . 7 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 This draft deals proposes a DiffServ interconnection class and 81 codepoint scheme. At least one party of an interconnection often is 82 a network provider. Aggregated DiffServ classes are often deployed 83 within provider networks. To respect this, this draft also contains 84 concepts and current practice relevant for a revised version of 85 RFC5127 [RFC5127]. Its main purpose is to be considered as an input 86 for the latter task 88 DiffServ sees deployment in many networks for the time being. As 89 described in the introduction of the draft diffserv problem statement 90 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of 91 packets at domain boundaries is a DiffServ feature. This draft 92 proposes a set of standard QoS classes and codepoints at 93 interconnection points to which and from which locally used classes 94 and codepoints may be mapped. Such a scheme simplifies 95 interconnection negotiations and ensures that class properties remain 96 roughly the same, even if codepoints change. 98 The proposed Interconnection class and codepoint scheme tries to 99 reflect and consolidate related DiffServ and QoS standardisation 100 efforts outside of the IETF, namely MEF, GSMA and ITU. 102 IP Precedence has been depricated when DiffServ was standardised. It 103 is common practice today however to copy the DSCPs "IP Precedence 104 Bits" into MPLS TC or Ethernet P-Bits, whenever possible. This is 105 reflected by the DiffServ codepoint definitions of AF and EF. This 106 practice and it's limits deserve to be documented and disussed 107 briefly. 109 The draft further adds proposals by which philosophy to add or pick 110 aggregated DiffServ classes. The set of available router and traffic 111 management tools to configure and operate DiffServ classes is 112 limited. This should be reflected by class definitions, which may in 113 the end more strongly be related transport properties than 114 application requirements. Please read that "congestion aware" and 115 "not congestion aware" rather then TCP or UDP. 117 Finally, this draft proposes to leave some MPLS TC codepoint space to 118 allow for future DiffServ extensions like ECN/PCN and domain internal 119 classes (network management traffic is a good example) 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Terminology 129 A later version of this draft needs to be clearer on that. The 130 author prefers to talk of QoS classes. PHB or PHB groups are not 131 commonly used, although they are better defined. An issue is, that 132 PHB groups, which e.g. allow to offer two or more different drop 133 levels (PHB's) within one PHB group , hardly saw commercial 134 deployment. This may change with more Ethernet services being 135 offered. 137 Some rather concept than terminology related real world issues are 138 additional motivations of this activity: 140 o Abstract class names like "EF" are preferrential over those being 141 close to an application, like "Voice". Unfortunately, non QoS 142 experts can't handle abstract class names. Hence and usually 143 sooner than later, classes are named for applications or groups of 144 them. One consequence however is, that people tend to combine 145 application group class names and SLA parameters and often decide, 146 based on a name and some numbers on a paper, that their 147 application needs separate QoS class. 149 o Worse than that, but very present in real life, is the class 150 abstraction level which is preferred by those dealing with QoS (as 151 experts or non experts): the DSCPs or the IP precedence. So DSCPs 152 or IP Precedence values are the commodity real life abstractions 153 applied for QoS classes. Most of these persons hav fixed class to 154 codepoint mappings in their minds, which they can't easily adapt 155 on a per customer and interconnection partner basis. 157 While these issues aren't to be solved by IETF (QoS experts could and 158 should of course teach staff to use proper Diffserv terminology and 159 concepts), a simple QoS interconnection scheme also is helpful in 160 this area. Those dealing with QoS on any level need to understand 161 the interconnection classes and their codepoints, and they are able 162 to deal with the mappings of those to their own networks class and 163 codepoint scheme. Simplicity is important, however. 165 3. An Interconnection class and codepoint scheme 167 DiffServ deployments mostly follow loose class specification schemes 168 (often one or two AF PHBs or PHB groups, EF and Best Effort). 169 Especially DSCP assignment for the AF classes varies between 170 deployment, while basic class defeinitions are often similar. This 171 is in line with the DiffServ architecture. This document doesn't 172 propose to change that. 174 Interconnecting parties usually face the problem of matching classes 175 to be interconnected and then to agree on codepoint mapping. As 176 stated by draft diffserv prolebm statement 177 [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a 178 standard behaviour at interconnection interfaces. This draft propses 179 a set of 4 QoS classes with a set of well defined DSCPs as 180 interconnection codepoint scheme. As the idea is that a sending 181 party remarks DSCPs from internal schemes to the Interconnection 182 codepoints and the receiving party remarks to their internal scheme, 183 the interconnection codepoint scheme fully complies with the DiffServ 184 architecture. 186 While this may look like an additional step at first, there are 187 obvious benefits: each party sending or receiving traffic has to 188 specify the mapping from or to the interconnection class and 189 codepoint scheme only once. Without it, this is to be negotiated 190 once per interconnection party. Further, end-to-end QoS in terms of 191 traffic being classified for the same class in all passed domains is 192 likely to result if an interconnection codepoint scheme is used, 193 while it is not necessarily resulting from individual per network 194 interconnection negotiations. 196 The Interconnection scheme is supporting aggregated DiffServ classes, 197 as proposed by RFC 5127 [RFC5127]. Note that draft RFC 4597 update 198 [I-D.polk-tsvwg-rfc4594-update] doesn't expect any network to deploy 199 all possible QoS classes (and proposes to standardise DSCPs for all 200 while maintaining deployment of classes a network specific issue). 201 RFC2597 does not allow to aggregate separate AF classes [RFC2597]. 202 Hence a low number of interconnection classes on aggregated level 203 makes sense, as some codepoint space for carrier internal services 204 and future features like ECN should be left also for aggregatd 205 classes. MPLS and Ethernet only support up to 8 QoS classes. IP 206 over Ethernet and / or MPLS is acommodity in todays operational 207 environments, and inter layer QoS likely will be a commodity too. 209 4. Consolidation of QoS standards by the interconnection codepoint 210 scheme 212 The interconnection class and codepoint scheme proposed by Y.1566 213 also tries to consolidate related DiffServ and QoS standardisation 214 efforts outside of the IETF [Y.1566]. MEF 23.1 specifies 3 215 aggregated classes, consuming up to 5 bit codepoints (EF, two AF 216 classes and Best Effort) and 8 DSCPs [MEF23.1]. GSMA IR.34 proposes 217 four aggregated DiffServ classes, EF, 2 AF and Best Effort with 7 218 DSCPs (PHBs) in sum [IR.34]. Consolidation may be reached for EF, 219 one AF class and Best Effort, meaning three aggregated or 5 DSCPs. 220 Consolidation here aims on similar class definitions and DiffServ 221 codepoints in all standards, MEF23.1, GSMA IR.34 and Y.1566. This 222 will again simplify product design and interconnection negotiations 223 for customers and parties following these standards. 225 5. MPLS, Ethernet and IP Precedence for aggregated classes 227 IP Precedence has been depricated when DiffServ was standardised. 228 Ethernet and MPLS support 3 bit codepoint fields to differntiate 229 service quality. Mapping of the IP precedence to these 3 Bit fields 230 has been a configuration restriction in the early days of DiffServ. 231 The concept of paying attention to the three most significant bits of 232 a DSCP has however been part of Diffserv from start on (EF's IP 233 Precedence is 5, that of AF4 is 4 and so on). The interconnection 234 class and codepoint scheme respects this in different ways: 236 o it allows to classify four aggregated classes based on IP 237 precedence. 239 o It supports a single PHB group (AF3), which may be mapped to up to 240 three different MPLS TC's or Ethernet P-Bits. Note that the 241 author doesn's favour or recommend doing that, but it is possible. 242 The author isn't aware of deployed service offers with 3 different 243 drop levels in a single class. 245 This is of course no requirement to depricate any DSCP to MPLS TC or 246 Ethernet P-Bit mapping functionality. This functionalities are very 247 important as well. 249 6. QoS class name selection 251 This is more of an informational discussion, proposed best practice, 252 and mainly relates to human behviour (including QoS experts) rather 253 than technical issues. Above the human preference for conceivable 254 class names has been mentioned. Network engineers (including the 255 former Diffserv WG authors) recommend to avoid application related 256 QoS class names. Focus should be put on class properties. But these 257 can be irritating again, as just looking at a few SLA numbers doesn't 258 tell the reader, which engineering assumptions resulted in the 259 scheduler configurations of a class. A router produces QoS with a 260 scheduling mechanism, a settable queue depth and optional active 261 queue management (including ECN), and may be a policer. Some kind of 262 resource management may be presendt (also in Diffserv domains). It's 263 beyond the imagination of the author how one would engineer more than 264 half a dozen classes with distinguishable properties with this set of 265 tools. 267 There's no perfect solution to the problem, as scheduler 268 configurations are not comprehensible to most readers, even if they 269 were communicated (they are operational secrets of course). There 270 are (or should be) engineering assumptions, when designing QoS 271 schedulers. But they closer relate to layer 3 or layer 4 level 272 properties than to specific applications. In general, an application 273 responds to congestion by reducing traffic, or it ignores congestion. 274 Active queue management doesn't help to avoid congestion in the 275 latter case, only resource management does. EF may be a special 276 case. If the EF traffic is not responsive to congestion, and packets 277 are assumed to be short, rather small jitter values can be reached if 278 enginieering ensures that the packet arrival rate never exceeds the 279 transmision rate of that queue (see RFC 3246 [RFC3246]). There's 280 other non congestion-responsive traffic, for which the EF engineering 281 assumptions may not fit. So a second class with EF like properties 282 (but a different engineering) may be present. 284 Active queue management may be deployed for QoS classes, which are 285 designed to transport traffic responding to congestion by traffic 286 reduction. 288 The author couldn't yet find conceivable class names. TCP_optimised 289 and especially UDP_optimised are inappropriate, as some UDP based 290 application are or may be expected to become TCP friendly. 292 7. Allow for DiffServ extendability on MPLS and Ethernet level 294 Any aggregated Diffserv deployment faces codepoint depletion issues 295 rather soon, if deployed on MPLS or Ethernet. Coding space should be 296 left for new features, like ECN, PCN or Conex. In addition to 297 carrying customer traffic, internal routing and network management 298 traffic may be protected by using a separate class. offering 299 interconnection with up to four classes and 4 - 6 MPLS TC's (or 300 Ethernet P-bits) to that respect is probably at least a fair 301 compromise. 303 8. IANA Considerations 305 This memo includes no request to IANA. 307 9. Security Considerations 309 This document does not introduce new features, it describes how to 310 use existing ones. The security section of RFC 4597 [RFC4597] 311 applies. 313 10. References 315 10.1. Normative References 317 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 318 "Assured Forwarding PHB Group", RFC 2597, June 1999. 320 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 321 J., Courtney, W., Davari, S., Firoiu, V., and D. 322 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 323 Behavior)", RFC 3246, March 2002. 325 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 327 10.2. Informative References 329 [I-D.polk-tsvwg-diffserv-stds-problem-statement] 330 Polk, J., "The Problem Statement for the Standard 331 Configuration of DiffServ Service Classes", 332 draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work 333 in progress), July 2012. 335 [I-D.polk-tsvwg-rfc4594-update] 336 Polk, J., "Standard Configuration of DiffServ Service 337 Classes", draft-polk-tsvwg-rfc4594-update-02 (work in 338 progress), October 2012. 340 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP 341 Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ 342 /www.gsma.com/newsroom/wp-content/uploads/2012/03/ 343 ir.34.pdf, 2012. 345 [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet 346 Class of Service Phase 2", MEF, MEF23.1 http:// 347 metroethernetforum.org/PDF_Documents/ 348 technical-specifications/MEF_23.1.pdf, 2012. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", 354 RFC 4597, August 2006. 356 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 357 Diffserv Service Classes", RFC 5127, February 2008. 359 [Y.1566] ITU-T, "Quality of service mapping and interconnection 360 between Ethernet, IP and multiprotocol label switching 361 networks", ITU, draft Y.QoSmap (now Y.61566) https:// 362 datatracker.ietf.org/documents/LIAISON/ 363 liaison-2012-07-03-itu-t-sg-12-tsvwg-development-of- 364 informative-codepoint-mapping-in-itu-t-study-group-12- 365 attachment-1.zip, 2012. 367 Author's Address 369 Ruediger Geib (editor) 370 Deutsche Telekom 371 Heinrich Hertz Str. 3-7 372 Darmstdadt, 64297 373 Germany 375 Phone: +49 6151 5812747 376 Email: Ruediger.Geib@telekom.de