idnits 2.17.1 draft-knoll-idr-qos-attribute-21.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 24, 2018) is 2278 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) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-23) exists of draft-knoll-idr-cos-interconnect-19 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Working Group Th. Knoll 3 Internet-Draft January 24, 2018 4 Intended status: Standards Track 5 Expires: July 28, 2018 7 BGP Extended Community for QoS Marking 8 draft-knoll-idr-qos-attribute-21 10 Abstract 12 This document specifies a simple signalling mechanism for inter- 13 domain QoS marking using several instances of a new BGP Extended 14 Community. Class based packet marking and forwarding is currently 15 performed independently within ASes. The new QoS marking community 16 makes the targeted Per Hop Behaviour within the IP prefix advertising 17 AS and the currently applied marking at the interconnection point 18 known to all access and transit ASes. This enables individual 19 (re-)marking and possibly forwarding treatment adaptation to the 20 original QoS class setup of the respective originating AS. The 21 extended community provides the means to signal QoS markings on 22 different layers, which are linked together in QoS Class Sets. It 23 provides inter-domain and cross-layer insight into the QoS class 24 mapping of the source AS with minimal signalling traffic. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 28, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Definition of the QoS Marking Community . . . . . . . . . . . 7 70 4.1. Extended Community Type . . . . . . . . . . . . . . . . . 7 71 4.2. Structure of the QoS Marking Community . . . . . . . . . 7 72 4.3. Technology Type Enumeration . . . . . . . . . . . . . . . 10 73 5. Community Usage . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.1. QoS Marking Example . . . . . . . . . . . . . . . . . . . 12 75 5.2. AS Border Packet Forwarding . . . . . . . . . . . . . . . 12 76 5.3. IP Prefix Aggregation . . . . . . . . . . . . . . . . . . 13 77 6. Confidentiality Considerations . . . . . . . . . . . . . . . 13 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Appendix A. QoS Marking Example . . . . . . . . . . . . . . . . 16 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 A new BGP Extended Community is defined in this document, which 89 carries QoS marking information for different network layer 90 technologies across ASes. This extended community is called "QoS 91 Marking". This new community provides a mechanism within BGP-4 92 [RFC4271] for associating all advertised prefixes of the AS with its 93 differentiated QoS Class Marking information. It allows for the 94 consistent exchange of class encoding values between BGP peers for 95 physical, data link and network QoS mechanisms. These labels can be 96 used to control the distribution of this information, for the 97 encoding and for treatment adjustments within the AS or for other 98 applications. One globally seen QoS Class Set per AS is required for 99 scalability reasons. It is the AS provider's responsibility to 100 enforce the globally signalled Set throughout the AS. 102 Several QoS Marking communities MAY be included in a single BGP 103 UPDATE message. They are virtually linked together by means of an 104 identical "QoS Set Number" field. Each QoS Marking community is 105 encoded as 8-octet tuple, as defined in Section 4. Signalled QoS 106 Class Sets are assumed to be valid for traffic crossing this AS. If 107 different QoS strategies are used with an AS, its provider is 108 responsible for consistent transport of transit traffic across this 109 inhomogeneous domain. In all transit forwarding cases, QoS based 110 tunnelling mechanisms are the means of choice for transparent traffic 111 transport. 113 The availability of the "Best Effort" forwarding class is implied and 114 defaults to a zero encoding on all signalled layers. It is therefore 115 not necessary to include QoS Marking communities for the Best Effort 116 Class as long as the default encoding is in place. 118 Class overload prevention can be achieved by means of the signalling 119 described in [I-D.knoll-idr-cos-interconnect]. It is a complementary 120 concept to limit the usage of advertised classes in a fair and square 121 manner. 123 2. Problem Statement 125 Current inter-domain interconnection is "best effort" interconnection 126 only. That is, traffic forwarding between ASes is without traffic 127 class differentiation and without any forwarding guarantee. It is 128 common for network providers to reset any IP packet class markings to 129 zero, the best effort DSCP marking, at the AS ingress router, which 130 eliminates any traffic differentiation. Some providers perform 131 higher layer classification at the ingress in order to guess the 132 forwarding requirements and to match on their AS internal QoS 133 forwarding policy. There is no standardized set of classes, no 134 standardized marking (class encoding) and no standardized forwarding 135 behaviour, which cross-domain traffic could rely on. QoS policy 136 decisions are taken by network providers independently and in an 137 uncoordinated fashion. 139 This general statement does not cover the existing individual 140 agreements, which do offer quality based interconnection with strict 141 QoS guarantees. However, such SLA based agreements are of bilateral 142 or multilateral nature and do not offer a means for a general "better 143 than best effort" interconnection. This draft does not aim for 144 making such SLA based agreements become void. On the contrary, those 145 agreements are expected to exist for special traffic forwarding paths 146 with strictly guaranteed QoS. 148 There are many approaches, which propose proper inter-domain QoS 149 strategies including inter-domain parameter signalling, metering, 150 monitoring and misbehaviour detection. Such complex strategies get 151 close to guaranteed QoS based forwarding at the expense of dynamic 152 measurements and adjustments, of state keeping on resource usage vs. 153 traffic load and in particular of possibly frequent inter-domain 154 signalling. 156 The proposed QoS Class marking approach dissociates from the complex 157 latter solutions and targets the general "better than best effort" 158 interconnection in coexistence with SLA based agreements. It enables 159 ASes to make their supported Class Sets and their encoding globally 160 known. In other words, this support information constitutes a simple 161 map of QoS enabled roads in transit and destination ASes. 163 Signalling the coarse information about the supported class set and 164 its cross-layer encoding within the involved forwarding domains of 165 the selected AS path removes the lack of knowledge about the over-all 166 available traffic differentiation. AS providers are enabled to make 167 an informed decision about supported class encodings and might adopt 168 to them. No guarantees are offered by this "better than best effort" 169 approach, but as much as easily possible traffic differentiation 170 without the need for frequent inter-domain signalling and for costly 171 ingress re-classification will be achieved. 173 Remarking the class encoding of customer traffic in order to match 174 neighbouring class set encodings is reasonable at AS interconnection 175 points. For AS internal forwarding, the encapsulation within any 176 kind of QoS supporting tunnelling technology is highly recommended. 177 The cross-layer signalling of QoS encoding will further ease the 178 setup of QoS based inter-domain tunnelling. 180 The general confidentiality concern of disclosing AS internal policy 181 information is addressed in Section 6. In short, network providers 182 can signal a different class set in the QoS Marking communities to 183 the one actually used internally. The different class sets 184 (externally signalled vs. internally applied one) require an 185 undisclosed strictly defined mapping at the AS borders between the 186 two. This way, a distinction between internal and external QoS Class 187 Sets can be achieved. 189 The general need for class based accounting is not addressed by this 190 draft. MIB extensions are also required, which separate traffic 191 variables by traffic marking. It is expected for both that existing 192 procedures can be reused in a class based manner. 194 3. Related Work 196 A number of QoS improvement approaches have been proposed before and 197 a selection will be briefly mentioned in this section. 199 Most of the approaches perform parameter signalling. 200 [I-D.jacquenet-bgp-qos] defines the QOS_NLRI attribute, which is used 201 for propagating QoS-related information associated to the NLRI 202 (Network Layer Reachability Information) information conveyed in a 203 BGP UPDATE message. Single so called "QoS routes" are signalled, 204 which fulfil certain QoS requirements. Several information types are 205 defined for the attribute, which concentrate on rate and delay type 206 parameters. 208 [I-D.boucadair-qos-bgp-spec] is based on the specified QOS_NLRI 209 attribute and introduces some modifications to it. The notion of AS- 210 local and extended QoS classes is used, which effectively describes 211 the local set of QoS performance parameters or their cross-domain 212 combined result. Two groups of QoS delivery services are 213 distinguished, where the second group concentrates on ID associated 214 QoS parameter propagation between adjacent peers. The first group is 215 of more interest for this draft since it concentrates on the 216 "identifier propagation" such as the DSCP value for example. 217 However, this signalling is specified for the information exchange 218 between adjacent peers only and assumes the existence of extended QoS 219 classes and offline traffic engineering functions. 221 Another approach is described in [I-D.liang-bgp-qos]. It associates 222 a list of QoS metrics with each prefix by extending the existing 223 AS_PATH attribute format. Hop-by-hop metric accumulation is 224 performed as the AS_PATH gets extended in relaying ASes. Metrics are 225 generically specified as a list of TLV-style attribute elements. The 226 metrics such as bandwidth and delay are exemplary mentioned in the 227 draft. 229 One contribution specialized in the signalling of Type Of Service 230 (TOS) values which are in turn directly mapped to DSCP values in 231 section 3.2 of the draft [I-D.zhang-idr-bgp-extcommunity-qos]. The 232 TOS value is signalled within an Extended Community Attribute and, if 233 it is understood correctly, will be applied to a certain route. An 234 additional value field is used to identify, which routes belong to 235 which signalled TOS community. Who advertises such attributes and 236 whether they are of transitive or non-transitive type remains 237 unspecified. 239 The most comprehensive analysis (although not an IETF draft) is given 240 in [MIT_CFP]. This "Inter- provider Quality of Service" white paper 241 examines the inter-domain QoS requirements and derives a 242 comprehensive approach for the introduction of at least one QoS class 243 with guaranteed delay parameters. The implementation aspects of 244 metering, monitoring, parameter feedback and impairment allocations 245 are all considered in the white paper. However, QoS guarantees and 246 parameter signalling is beyond the intention of this QoS Marking 247 draft. 249 Other drafts may also be considered as related work as long as they 250 convey QoS marking information and might be "misused" for QoS class 251 signalling. 253 One example is the usage of the "Traffic Engineering Attribute" as 254 defined in [RFC5543]. However, the attribute is non-transitive and 255 the LSP encoding types are not generally applicable to inter-domain 256 interconnection types. Its usage of the targeted QoS Marking 257 signalling is not possible. The included maximum bandwidth of each 258 of eight priority classes, could however be used in future draft 259 extensions. 261 The second example is the current "Dissemination of flow 262 specification rules" draft [RFC5575]. It defines a new BGP NLRI 263 encoding format, which can be used to distribute traffic flow 264 specifications. Such flow specification can also include DSCP values 265 as type 11 in the NLRI. Furthermore, one could signal configuration 266 actions together with the DSCP encoding, which could be used for 267 filtering purposes or even trigger remarking and route selection with 268 it. Such usage is not defined in the draft and can hardly be 269 achieved because of the following reasons. The flow specification is 270 focused on single flows, which might even be part of an aggregate. 271 Such fine grained specification is counterproductive for the coarse 272 grained general QoS Marking approach of this draft. The novel 273 approach of cross-layer QoS Marking could also not be incorporated, 274 which might be essential for future tunnelled inter-domain 275 interconnection. 277 4. Definition of the QoS Marking Community 279 4.1. Extended Community Type 281 The new QoS Marking community is encoded in a BGP Extended Community 282 Attribute [RFC4360]. It is therefore a transitive optional BGP 283 attribute with Type Code 16. An adoption to the simple BGP Community 284 Attribute encoding [RFC1997] is not defined in this document. The 285 actual encoding within the BGP Extended Community Attribute is as 286 follows. 288 The QoS Marking community is of regular type which results in a 1 289 octet Type field followed by 7 octets for the QoS marking structure. 290 The Type is IANA-assignable and marks the community as transitive 291 across ASes. The type number has been assigned by IANA to 0x04 292 [IANA_EC]. 294 Optionally, a non-transitive Type value assignment of 0x44 is 295 provided, which allows for the AS internal marking information 296 exchange. The community format remains untouched for the non- 297 transitive version. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |0 0 0 0 0 0 0 0| | 303 +-+-+-+-+-+-+-+-+ 7 octet QoS Marking community structure | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1 309 4.2. Structure of the QoS Marking Community 311 The QoS Marking community provides a flexible encoding structure for 312 various QoS Markings on different layers. This flexibility is 313 achieved by a Flags, a QoS Set Number and a Technology Type field 314 within the 7 octet structure as defined below. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Flags | QoS Set Number|Technology Type| QoS Marking Oh| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | QoS Marking Ol| QoS Marking A |0 0 0 0 0 0 0 0| 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2 326 Flags: 328 0 1 2 3 4 5 6 7 329 +--+--+--+--+--+--+--+--+ 330 |0 0 |P |R |I |A |0 |0 | 331 +--+--+--+--+--+--+--+--+ 333 Figure 3 335 All used and unused flags default to a value of '0'. The 336 following table shows the bit encoding of the Flags field. 338 +-----+--------+----------------------------------------+ 339 | Bit | Flag | Encoding | 340 +-----+--------+----------------------------------------+ 341 | 0-1 | unused | Default to '0' | 342 | 2 | P | '1' ... Marking is preserved | 343 | 3 | R | '1' ... Remarking occurred | 344 | 4 | I | '1' ... QoS marking ignored | 345 | 5 | A | '1' ... QoS class aggregation occurred | 346 | 6,7 | unused | Default to '0' | 347 +-----+--------+----------------------------------------+ 349 Table 1 351 The 'P' flag indicates the preservation of incoming markings 352 during the transit forwarding process. The IP prefix originating 353 AS SHOULD set the flag to '1', which is otherwise implied by an 354 AS_PATH length of 1 ASN. Transit ASes MUST set the flag to '1', 355 if the advertised Marking A is accepted at the ingress and is sent 356 out unchanged at the egress. That is, no remarking occurs - 357 neither for marking adoption with the neighbouring downstream AS 358 nor by resetting the markings. This flag field is set and cleared 359 by each relaying AS according to its handling of markings - 360 irrespective of the possible ignorance of the particular Marking A 361 in the internal per hop forwarding behaviour. 363 The Flags "R, I and A" are set to '0' in the advertisement by the 364 IP prefix originating AS. Transit ASes MUST change the flag value 365 to '1' once the respective event occurred. If the QoS marking 366 actively used in the transit AS internal forwarding is different 367 from the advertised original one, the 'Remarking (R)' flag is set 368 to '1'. This MUST be done separately for each technology type 369 community within the community set. The same applies to the 370 'Ignore (I)' flag, if the respective advertised QoS marking is 371 ignored in the transit AS internal forwarding. 373 The 'Aggregation (A)' flag MUST be set to '1' by the UPDATE 374 message relaying transit AS, if the respective IP prefixes will be 375 advertised inside an IP prefix aggregate constituted from 376 differing Class Sets. 378 If the defined "R, I and A" flags are cleared - and by means of 379 the cleared 'Partial' flag of the BGP attribute it is shown, that 380 no "QoS Class ignorant" AS is involved in the forwarding path - a 381 consistent class based overall traffic separated forwarding is 382 available along this path. 384 QoS Set Number: 386 Several single QoS Marking communities can be logically grouped 387 into a QoS Marking community Set characterized by a identical QoS 388 Set Number. This grouping of the single QoS Marking communities 389 into a set provides cross-layer linking between the QoS class 390 encodings. It can also be used for the specification of behaviour 391 sets as given in the [RFC3140]. The number of signalled QoS 392 Marking communities as well as QoS Marking community Sets is at 393 the operator's choice of the originating AS. The enumerated QoS 394 set numbers have BGP UPDATE message local significance starting 395 with set number 0x00. 397 Technology Type: 399 The technology type encoding uses the enumeration list in 400 (Section 4.3). Future version of this draft will need an extended 401 enumeration list administered by IANA. 403 QoS Marking / Enumeration O & A: 405 The interpretation of these fields depends on the selected layer and 406 technology. ASes, which process the community and support the given 407 QoS Class by means of a QoS mechanism using bit encodings for the 408 targeted behaviour (e.g. IP DSCP, Ethernet User Priority, MPLS TC 409 etc.) MUST use a copy of the encoding in the "QoS Marking A" 410 community field. Unused higher order bits default to '0'. Other 411 technologies, which use separate forwarding channels for different 412 classes (such as L-LSPs, VPI/VCI inferred ATM classes, lambda 413 inferred priority, etc.) SHALL use class enumerations as encoding in 414 this community field. The enumeration count starts with zero for the 415 best effort traffic class and rises by one with each available higher 416 priority class. 418 There are two QoS Marking fields within the QoS Marking community for 419 the "original (O)" and the "active (A)" QoS marking. Higher order 420 bits of those fields, which are not used for the respective behaviour 421 encoding, default to zero. 423 QoS Marking O (Original QoS Marking): 425 This field is a 16 bit QoS Marking field, which consists of of a 426 high ("Oh") and a low ("Ol") octet. The IP prefix originating AS 427 copies the internally associated QoS encoding of the given 428 Technology Type into this one octet field. The field value is 429 right-aligned depending on the number of encoded bits. For the IP 430 technology, the encoding of Per Hop Behaviour Codes has to follow 431 the definitions stated in [RFC3140]. The field MUST remain 432 unchanged in BGP UPDATE messages of relaying nodes. 434 QoS Marking A (Active QoS Marking): 436 QoS Marking A and O MUST be identically encoded by the prefix 437 originating AS, except for the case, where IP technology Per Hop 438 Behaviours are addressed. "QoS Marking A" will always contain the 439 locally applied encoding for the targeted PHB. 441 All other ASes use this Active QoS Marking field to advertise 442 their locally applied internal QoS encoding of the given class and 443 technology at the interconnection point. The field value is 444 right-aligned depending on the number of encoded bits. A cleared 445 Marking field (all zero) signals that this traffic class 446 experiences default traffic treatment within the transit AS 447 forwarding technology. 449 4.3. Technology Type Enumeration 451 A small list of technologies is provided in the table below for the 452 direct encoding of common technology types. The mapping of all 453 virtual channel technologies into a single technology type value is 454 for limiting the number of different communities in an UPDATE 455 message. It is therefore a contribution to scalability. 457 +-------+-----------------------------------------------------------+ 458 | Value | Technology Type | 459 +-------+-----------------------------------------------------------+ 460 | 0x00 | DiffServ enabled IP (DSCP encoding) | 461 | 0x01 | Ethernet using 802.1q priority tag | 462 | 0x02 | MPLS using E-LSP | 463 | 0x03 | Virtual Channel (VC) encoding using separate channels for | 464 | | QoS forwarding / one channel per class (e.g. ATM VCs, FR | 465 | | VCs, MPLS L-LSPs) | 466 | 0x04 | GMPLS - time slot encoding | 467 | 0x05 | GMPLS - lambda encoding | 468 | 0x06 | GMPLS - fibre encoding | 469 +-------+-----------------------------------------------------------+ 471 Table 2 473 5. Community Usage 475 Providers MAY choose to process the QoS Marking communities and adopt 476 the behaviour encoding and tunnel selection according to their local 477 policy. Whether this MAY also lead to different IGP routing 478 decisions or even effect BGP update filters is out of scope for the 479 community definition. 481 Only the IP prefix originating AS is allowed to signal the QoS 482 Marking communities and Sets. AS providers, which make use of this 483 signalling mechanism MUST make sure, that only one external Class Set 484 will be advertised for the AS. All advertised prefixes, which 485 originate from that AS will be sent with the same QoS Marking 486 community Set in the respective UPDATE message. Transit ASes MUST 487 NOT modify or extend the QoS Marking community Set except for the 488 update of each 'QoS Marking A' field contained in the community Set 489 and the respective "P, R, I, A" flags. Prefixes with associated 490 identical QoS Marking community Sets are to be advertised together in 491 common UPDATE messages in relaying nodes. 493 Figure 4 shows an AS interconnection example with different Class 494 Sets. It shows the case in AS 5 where different Class Sets are used 495 internally and externally. The proposed QoS Class Set signalling 496 will always use the external definitions within the UPDATE message 497 QoS Marking communities. The example also shows, that IP prefixes, 498 which originate in AS 5 and AS 3 can be advertised together with the 499 same QoS Marking community Set as long as their Layer 2 encoding is 500 identical. 502 AS 5 = Transit AS 503 +------------+ ================= +------------+ 504 + AS 1 + AS internal: + AS 3 + 505 + 4 classes + 5 classes + 3 classes + 506 + L2/L3 + L2/L3 + L2/L3 + 507 +(EF,2xAF,BE)+ AS external: +(EF,AF1,BE)+ 508 + [] + 3 classes +[] + 509 +------------+ L3 (EF,AF1,BE) +------------+ 510 \ +---------------+ / 511 \ | [] | / 512 \ | / \ | / 513 \ | --()---()-- | / 514 \| / | | \ |/ 515 |[] | | []| 516 /| \ | | / |\ 517 / | --()---()-- | \ 518 / | \ / | \ 519 / | [] | \ 520 / +---------------+ \ 521 +------------+ +------------+ 522 + [] + +[] + 523 + AS 2 + + AS 4 + 524 + 2 classes + + 6 classes + 525 + L2/L3 + + L1/L2/L3 + 526 + (EF,BE) + +(EF,4xAF,BE)+ 527 +------------+ +------------+ 528 [] ... AS Border Router 529 () ... AS internal Router 531 Figure 4 533 5.1. QoS Marking Example 535 See Appendix A for an example QoS Marking community Set. 537 5.2. AS Border Packet Forwarding 539 IP packet forwarding based on packet header QoS encoding might 540 require remarking of packets in order to match AS internal policies 541 and encodings of neighbouring ASes. 543 Identical QoS class sets and encodings between neighbouring ASes do 544 not require any remarking. Different encodings will be matched on 545 the outgoing traffic. 547 Outgoing traffic for a given IP prefix uses the 'QoS Marking A' 548 information of the respective BGP UPDATE message QoS Marking 549 community for adopted remarking of the forwarded packet. 551 If the 'I' flag is set for a given encoding, the outgoing traffic 552 remarking SHOULD still be applied despite of the signalled lack of 553 QoS Class forwarding support. This is particularly important, if the 554 preserve flag 'P' is signalled together with the 'I' flag. 556 5.3. IP Prefix Aggregation 558 Several IP prefixes of different IP prefix originating ASes MAY be 559 aggregated to a shorter IP prefix in transit ASes. If the original 560 Class Sets of the aggregated prefixes are identical, the aggregate 561 will use the same Set. In all other cases, the resulting IP prefix 562 aggregate is handled the same as if the transit AS were the 563 originating AS for this aggregated prefix. The transit AS provider 564 MAY care for AS internal mechanisms, which map the signalled 565 aggregate QoS Class Set to the different original Class Sets in the 566 internal forwarding path. 568 In case of IP prefix aggregation with different QoS Class Sets, the 569 'Aggregation (A)' flag of each QoS Marking community within the Set 570 MUST be set to '1'. 572 6. Confidentiality Considerations 574 The disclosure of confidential AS intrinsic information is of no 575 concern since the signalled marking for QoS class encodings can be 576 adopted prior to the UPDATE advertisement of the IP prefix 577 originating AS. This way, a distinction between internal and 578 external QoS Class Sets can be achieved. AS internal cross-layer 579 marking adaptation and policy based update filtering allows for 580 consistent QoS class support despite made up QoS Class Set and 581 encoding information within UPDATE advertisements. In case of such 582 policy hiding strategy, the required AS internal ingress and egress 583 adaptation SHALL be done transparently without explicit "Active 584 Marking" and 'R' flag signalling. 586 7. IANA Considerations 588 This document defines a new BGP Extended Community, which includes a 589 "Technology Type" field. Section 4.3 enumerates a number of popular 590 technologies. This list is expected to suffice for first 591 implementations. However, future or currently uncovered technologies 592 may arise, which will require an extended "Technology Type" 593 enumeration list administered by IANA. 595 A new extended community QoS Marking community is defined, which has 596 been assigned a Type value of 0x04 for a transitive and 0x44 for a 597 non-transitive usage. 599 8. Security Considerations 601 This extension to BGP does not change the underlying security issues 602 inherent in the existing BGP. 604 Malicious signalling behaviour of QoS Marking community advertising 605 ASes can result in misguided neighbours about non existing or 606 maliciously encoded Class Sets. Removal of QoS Marking community 607 Sets leads to the current best effort interconnection, which is no 608 stringent security concern. 610 The IP prefix originating AS MAY place a copy of its marking 611 information into the Internet Routing Registry (IRR) for global 612 reference. 614 The strongest threat is the advertisement of numerous very fine 615 grained Class Sets, which could limit the scalability of this 616 approach. However, neighbouring ASes are free to set the ignore flag 617 of single communities or to stop processing the QoS Marking 618 communities of a certain routing advertisement, once a self-set 619 threshold has been crossed. By means of this self defence mechanism 620 it should not be possible to crash neighbouring peers due to the 621 excessive use of the new community. 623 9. References 625 9.1. Normative References 627 [IANA_EC] IANA, , "Border Gateway Protocol (BGP) Data Collection 628 Standard Communities", June 2008, 629 . 632 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 633 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 634 . 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, . 641 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 642 "Per Hop Behavior Identification Codes", RFC 3140, 643 DOI 10.17487/RFC3140, June 2001, . 646 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 647 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 648 DOI 10.17487/RFC4271, January 2006, . 651 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 652 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 653 February 2006, . 655 [RFC5543] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP Traffic 656 Engineering Attribute", RFC 5543, DOI 10.17487/RFC5543, 657 May 2009, . 659 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 660 and D. McPherson, "Dissemination of Flow Specification 661 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 662 . 664 9.2. Informative References 666 [I-D.boucadair-qos-bgp-spec] 667 Boucadair, M., "QoS-Enhanced Border Gateway Protocol", 668 draft-boucadair-qos-bgp-spec-01 (work in progress), July 669 2005. 671 [I-D.jacquenet-bgp-qos] 672 Cristallo, G., "The BGP QOS_NLRI Attribute", draft- 673 jacquenet-bgp-qos-00 (work in progress), February 2004. 675 [I-D.knoll-idr-cos-interconnect] 676 Knoll, T., "BGP Class of Service Interconnection", draft- 677 knoll-idr-cos-interconnect-19 (work in progress), November 678 2017. 680 [I-D.liang-bgp-qos] 681 Benmohamed, L., "QoS Enhancements to BGP in Support of 682 Multiple Classes of Service", draft-liang-bgp-qos-00 (work 683 in progress), June 2006. 685 [I-D.zhang-idr-bgp-extcommunity-qos] 686 Zhang, Z., "ExtCommunity map and carry TOS value of IP 687 header", draft-zhang-idr-bgp-extcommunity-qos-00 (work in 688 progress), November 2005. 690 [MIT_CFP] Amante, S., Bitar, N., Bjorkman, N., and others, "Inter- 691 provider Quality of Service - White paper draft 1.1", 692 November 2006, 693 . 695 Appendix A. QoS Marking Example 697 The example AS is advertising several IP prefixes, which experience 698 equal QoS treatment from AS internal networks. The IP packet 699 forwarding policy within this originating AS defines e.g. 3 traffic 700 classes for IP traffic (DSCP1, DSCP2 and DSCP3). These three classes 701 are also consistently taken care of within a TC bit supporting MPLS 702 tunnel forwarding. The BGP UPDATE message for the announced IP 703 prefixes will contain the following QoS Marking community Set 704 together with the IP prefix NLRI. 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|1 0 1 1 1 0 0 0| 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |0 0 0 0 0 0 0 0|0 0 1 0 1 1 1 0|0 0 0 0 0 0 0 0| 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0| 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 |0 0 0 0 0 1 0 1|0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0| 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|0 0 1 0 1 0 0 0| 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |0 0 0 0 0 0 1 0|0 0 0 0 1 0 1 0|0 0 0 0 0 0 0 0| 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0| 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0|0 1 0 0 1 0 0 0| 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 |0 0 0 0 0 0 1 0|0 0 0 1 0 0 1 0|0 0 0 0 0 0 0 0| 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |0 0 1 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0| 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0| 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 The class set as well as the example encodings are arbitrarily chosen. 743 Figure 5 745 Author's Address 747 Thomas Martin Knoll 749 Email: thomas.m.knoll@gmail.com