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