idnits 2.17.1 draft-knoll-idr-qos-attribute-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 734. 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 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 6, 2008) is 5773 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 (-09) exists of draft-ietf-idr-flow-spec-01 == Outdated reference: A later version (-04) exists of draft-ietf-softwire-bgp-te-attribute-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 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 6, 2008 5 Expires: January 7, 2009 7 BGP Extended Community Attribute for QoS Marking 8 draft-knoll-idr-qos-attribute-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2009. 35 Abstract 37 This document specifies a simple signalling mechanism for inter- 38 domain QoS marking using several instances of a new BGP Extended 39 Community Attribute. Class based packet marking and forwarding is 40 currently performed independently within ASes. The new QoS marking 41 attribute makes the QoS class marking within the IP prefix 42 advertising AS known to all access and transit ASes. This enables 43 individual (re-)marking and possibly forwarding treatment adaptation 44 to the original QoS class setup of the respective originating AS. 45 The attribute provides the means to signal QoS markings on different 46 layers, which are linked together in QoS Class Sets. It provides 47 inter-domain and cross-layer insight into the QoS class mapping of 48 the source AS with minimal signalling traffic. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Definition of the QoS Marking Attribute . . . . . . . . . . . 6 62 4.1. Extended Community Type . . . . . . . . . . . . . . . . . 7 63 4.2. Structure of the QoS Marking Attribute . . . . . . . . . . 7 64 4.3. Technology Type Enumeration . . . . . . . . . . . . . . . 10 65 5. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. QoS Marking Attribute Example . . . . . . . . . . . . . . 11 67 5.2. AS Border Packet Forwarding . . . . . . . . . . . . . . . 11 68 5.3. IP Prefix Aggregation . . . . . . . . . . . . . . . . . . 12 69 6. Confidentiality Considerations . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Appendix A. QoS Marking Attribute Example . . . . . . . . . . . . 14 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Intellectual Property and Copyright Statements . . . . . . . . . . 17 79 1. Introduction 81 A new BGP Extended Community Attribute is defined in this document, 82 which carries QoS marking information for different network layer 83 technologies across ASes. This attribute is called "QoS Marking 84 Attribute". This new attribute provides a mechanism within BGP-4 85 [RFC4271] for associating all advertised prefixes of the AS with its 86 differentiated QoS Class Marking information. It allows for the 87 consistent exchange of class encoding values between BGP peers for 88 physical, data link and network QoS mechanisms. These labels can be 89 used to control the distribution of this information, for the 90 encoding and for treatment adjustments within the AS or for other 91 applications. One globally seen QoS Class Set per AS is required for 92 scalability reasons. It is the AS provider's responsibility to 93 enforce the globally signalled Set throughout the AS. 95 Several QoS Marking Attributes MAY be included in a single BGP UPDATE 96 message. They are virtually linked together by means of an identical 97 "QoS Set Number" field. Each QoS Marking Attribute is encoded as 98 8-octet tuple, as defined in Section 4. Signalled QoS Class Sets are 99 assumed to be valid for traffic crossing this AS. If different QoS 100 strategies are used with an AS, its provider is responsible for 101 consistent transport of transit traffic across this inhomogeneous 102 domain. In all transit forwarding cases, QoS based tunnelling 103 mechanisms are the means of choice for transparent traffic transport. 105 The availability of the "Best Effort" forwarding class is implied and 106 defaults to a zero encoding on all signalled layers. It is therefore 107 not necessary to include QoS Marking Attributes for the Best Effort 108 Class as long as the default encoding is in place. 110 2. Problem Statement 112 Current inter-domain peering is "best effort" peering only. That is, 113 traffic forwarding between ASes is without traffic class 114 differentiation and without any forwarding guarantee. It is common 115 for network providers to reset any IP packet class markings to zero, 116 the best effort DSCP marking, at the AS ingress router, which 117 eliminates any traffic differentiation. Some providers perform 118 higher layer classification at the ingress in order to guess the 119 forwarding requirements and to match on their AS internal QoS 120 forwarding policy. There is no standardized set of classes, no 121 standardized marking (class encoding) and no standardized forwarding 122 behaviour, which cross-domain traffic could rely on. QoS policy 123 decisions are taken by AS providers independently and in an 124 uncoordinated fashion. 126 This general statement does not cover the existing individual 127 agreements, which do offer quality based peering with strict QoS 128 guarantees. However, such SLA based agreements are of bilateral or 129 multilateral nature and do not offer a means for a general "better 130 than best effort" peering. This draft does not aim for making such 131 SLA based agreements become void. On the contrary, those agreements 132 are expected to exist for special traffic forwarding paths with 133 strictly guaranteed QoS. 135 There are many approaches, which propose proper inter-domain QoS 136 strategies including inter-domain parameter signalling, metering, 137 monitoring and misbehaviour detection. Such complex strategies get 138 close to guaranteed QoS based forwarding at the expense of dynamic 139 measurements and adjustments, of state keeping on resource usage vs. 140 traffic load and in particular of possibly frequent inter-domain 141 signalling. 143 The proposed QoS Class marking approach dissociates from the complex 144 latter solutions and targets the general "better than best effort" 145 peering in coexistence with SLA based agreements. It enables ASes to 146 make their supported Class Sets and their encoding globally known. 147 In other words, this support information constitutes a simple map of 148 QoS enabled roads in transit and destination ASes. 150 Signalling the coarse information about the supported class set and 151 its cross-layer encoding within the involved forwarding domains of 152 the selected AS path removes the lack of knowledge about the over-all 153 available traffic differentiation. AS providers are enabled to make 154 an informed decision about supported class encodings and might adopt 155 to them. No guarantees are offered by this "better than best effort" 156 approach, but as much as easily possible traffic differentiation 157 without the need for frequent inter-domain signalling and for costly 158 ingress re-classification will be achieved. 160 Remarking the class encoding of customer traffic in order to match 161 neighbouring class set encodings is reasonable at AS peering points. 162 For AS internal forwarding, the encapsulation within any kind of QoS 163 supporting tunnelling technology is highly recommended. The cross- 164 layer signalling of QoS encoding will further ease the setup of QoS 165 based inter-domain tunnelling. 167 The general confidentiality concern of disclosing AS internal policy 168 information is addressed in Section 6. In short, AS providers can 169 signal a different class set in the QoS Marking Attributes to the one 170 actually used internally. The different class sets (externally 171 signalled vs. internally applied one) require an undisclosed strictly 172 defined mapping at the AS borders between the two. This way, a 173 distinction between internal and external QoS Class Sets can be 174 achieved. 176 The general need for class based accounting is not addressed by this 177 draft. MIB extensions are also required, which separate traffic 178 variables by traffic marking. It is expected for both that existing 179 procedures can be reused in a class based manner. 181 3. Related Work 183 A number of QoS improvement approaches have been proposed before and 184 a selection will be briefly mentioned in this section. 186 Most of the approaches perform parameter signalling. 187 [I-D.jacquenet-bgp-qos] defines the QOS_NLRI attribute, which is used 188 for propagating QoS-related information associated to the NLRI 189 (Network Layer Reachability Information) information conveyed in a 190 BGP UPDATE message. Single so called "QoS routes" are signalled, 191 which fulfil certain QoS requirements. Several information types are 192 defined for the attribute, which concentrate on rate and delay type 193 parameters. 195 [I-D.boucadair-qos-bgp-spec] is based on the specified QOS_NLRI 196 attribute and introduces some modifications to it. The notion of AS- 197 local and extended QoS classes is used, which effectively describes 198 the local set of QoS performance parameters or their cross-domain 199 combined result. Two groups of QoS delivery services are 200 distinguished, where the second group concentrates on ID associated 201 QoS parameter propagation between adjacent peers. The first group is 202 of more interest for this draft since it concentrates on the 203 "identifier propagation" such as the DSCP value for example. 204 However, this signalling is specified for the information exchange 205 between adjacent peers only and assumes the existence of extended QoS 206 classes and offline traffic engineering functions. 208 Another approach is described in [I-D.liang-bgp-qos]. It associates 209 a list of QoS metrics with each prefix by extending the existing 210 AS_PATH attribute format. Hop-by-hop metric accumulation is 211 performed as the AS_PATH gets extended in relaying ASes. Metrics are 212 generically specified as a list of TLV-style attribute elements. The 213 metrics such as bandwidth and delay are exemplary mentioned in the 214 draft. 216 One contribution specialized in the signalling of Type Of Service 217 (TOS) values which are in turn directly mapped to DSCP values in 218 section 3.2 of the draft [I-D.zhang-idr-bgp-extcommunity-qos]. The 219 TOS value is signalled within an Extended Community Attribute and, if 220 it is understood correctly, will be applied to a certain route. An 221 additional value field is used to identify, which routes belong to 222 which signalled TOS community. Who advertises such attributes and 223 whether they are of transitive or non-transitive type remains 224 unspecified. 226 The most comprehensive analysis (although not an IETF draft) is given 227 in [MIT_CFP]. This "Inter- provider Quality of Service" white paper 228 examines the inter-domain QoS requirements and derives a 229 comprehensive approach for the introduction of at least one QoS class 230 with guaranteed delay parameters. The implementation aspects of 231 metering, monitoring, parameter feedback and impairment allocations 232 are all considered in the white paper. However, QoS guarantees and 233 parameter signalling is beyond the intention of this QoS Marking 234 Attribute draft. 236 Other drafts may also be considered as related work as long as they 237 convey QoS marking information and might be "misused" for QoS class 238 signalling. 240 One example is the usage of the "Traffic Engineering Attribute" as 241 defined in [I-D.ietf-softwire-bgp-te-attribute]. However, the 242 attribute is non-transitive and the LSP encoding types are not 243 generally applicable to inter-domain peering types. Its usage of the 244 targeted QoS Marking signalling is not possible. The included 245 maximum bandwidth of each of eight priority classes, could however be 246 used in future draft extensions. 248 The second example is the current "Dissemination of flow 249 specification rules" draft [I-D.ietf-idr-flow-spec]. It defines a 250 new BGP NLRI encoding format, which can be used to distribute traffic 251 flow specifications. Such flow specification can also include DSCP 252 values as type 11 in the NLRI. Furthermore, one could signal 253 configuration actions together with the DSCP encoding, which could be 254 used for filtering purposes or even trigger remarking and route 255 selection with it. Such usage is not defined in the draft and can 256 hardly be achieved because of the following reasons. The flow 257 specification is focused on single flows, which might even be part of 258 an aggregate. Such fine grained specification is counterproductive 259 for the coarse grained general QoS Marking approach of this draft. 260 The novel approach of cross-layer QoS Marking could also not be 261 incorporated, which might be essential for future tunnelled inter- 262 domain peering. 264 4. Definition of the QoS Marking Attribute 265 4.1. Extended Community Type 267 The new QoS Marking Attribute is encoded as a BGP Extended Community 268 Attribute [RFC4360]. It is therefore a transitive optional BGP 269 attribute with Type Code 16. An adoption to the simple BGP Community 270 Attribute encoding [RFC1997] is not defined in this document. The 271 actual encoding within the BGP Extended Community Attribute is as 272 follows. 274 The QoS Marking Attribute is of regular type which results in a 1 275 octet Type field followed by 7 octets for the QoS marking structure. 276 The Type is IANA-assignable and marks the community as transitive 277 across ASes. The type number has been assigned by IANA to 0x00 278 [IANA_EC]. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |0 0 0 0 0 0 0 0| | 283 +-+-+-+-+-+-+-+-+ 7 octet QoS Marking Attribute structure | 284 | | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1 289 4.2. Structure of the QoS Marking Attribute 291 The QoS Marking Attributes provides a flexible encoding structure for 292 various QoS Markings on different layers. This flexibility is 293 achieved by a Flags, a QoS Set Number and a Technology Type field 294 within the 7 octet structure as defined below. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Flags | QoS Set Number|Technology Type| QoS Marking O | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | QoS Marking A | P. Count | C. Unused ='0'| 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2 305 Flags: 306 0 1 2 3 4 5 6 7 307 +--+--+--+--+--+--+--+--+ 308 |0 0 0 |R |I |A |0 |0 | 309 +--+--+--+--+--+--+--+--+ 311 Figure 3 313 All used and unused flags default to a value of '0'. The 314 following table shows the bit encoding of the Flags field. 316 +-----+--------+-----------------------------------------+ 317 | Bit | Flag | Encoding | 318 +-----+--------+-----------------------------------------+ 319 | 0-2 | unused | Default to '0' | 320 | 3 | R | '1' ... remarking occurred | 321 | 4 | I | '1' ... QoS marking ignored | 322 | 5 | A | '1' ... QoS class aggregation occurred | 323 | 6,7 | unused | Default to '0' | 324 +-----+--------+-----------------------------------------+ 326 Table 1 328 The Flags "R, I and A" are set to '0' in the advertisement by the 329 IP prefix originating AS. Transit ASes MUST change the flag value 330 to '1' once the respective event occurred. If the QoS marking 331 actively used in the transit AS internal forwarding is different 332 from the advertised original one, the 'Remarking (R)' flag is set 333 to '1'. This MUST be done separately for each technology type 334 attribute within the attribute set. The same applies to the 335 'Ignore (I)' flag, if the respective advertised QoS marking is 336 ignored in the transit AS internal forwarding. 338 The 'Aggregation (A)' flag MUST be set to '1' by the UPDATE 339 message relaying transit AS, if the respective IP prefixes will be 340 advertised inside an IP prefix aggregate constituted from 341 differing Class Sets. 343 If the defined Flags are cleared - and by means of the zero 'I' 344 flag and the later on explained Processing Count it is shown that 345 no "QoS Class ignorant" is involved in the forwarding path - a 346 consistent class based overall forwarding is available along this 347 path. 349 QoS Set Number: 351 Several single QoS Marking Attributes can be logically grouped 352 into a QoS Marking Attribute Set characterized by a identical QoS 353 Set Number. This grouping of the single QoS Marking Attributes 354 into a set provides a cross-layer linking between the QoS class 355 encodings. The number of signalled QoS Marking Attributes as well 356 as QoS Marking Attribute Sets is at the operator's choice of the 357 originating AS. The enumerated QoS set numbers have BGP UPDATE 358 message local significance starting with set number 0x00. 360 Technology Type: 362 The technology type encoding uses the enumeration list in 363 (Section 4.3). Future version of this draft will need an extended 364 enumeration list administered by IANA. 366 QoS Marking / Enumeration O & A: 368 The interpretation of these identically approached fields depends on 369 the selected layer and technology. ASes, which process the Attribute 370 and support the given QoS Class by means of a QoS mechanism using bit 371 encodings for the targeted priority (e.g. IP DSCP, Ethernet User 372 Priority, MPLS EXP etc.) MUST use a copy of the encoding in this 373 attribute field. Unused higher order bits default to '0'. Other 374 technologies, which use separate forwarding channels for different 375 classes (such as L-LSPs, VPI/VCI inferred ATM classes, lambda 376 inferred priority, etc.) SHALL use class enumerations as encoding in 377 this attribute field. The enumeration count starts with zero for the 378 best effort traffic class and rises by one with each available higher 379 priority class. 381 There are two QoS Marking fields within the QoS Marking Attribute for 382 the "original (O)" and the "active (A)" QoS marking. 384 QoS Marking O (Original QoS Marking): 386 The IP prefix originating AS copies the internally associated QoS 387 encoding of the given Technology Type into this one octet field. 388 The field MUST remain unchanged in BGP UPDATE messages of relaying 389 nodes. 391 QoS Marking A (Active QoS Marking): 393 QoS Marking A and O MUST be identically encoded by the prefix 394 originating AS. 396 All other ASes use this Active QoS Marking field to advertise 397 their internal QoS encoding of the given class and technology. A 398 cleared Marking field (all zero) signals that this traffic class 399 experiences default traffic treatment within the transit AS 400 forwarding technology. 402 Processing Count (P. Count): 404 Each BGP instance, which processes the attribute and appends a 405 different AS number to the AS_PATH, MUST increase this counter by 406 one. The attribute originating instance initializes the counter 407 value to '0x00'. 409 Currently Unused (C. Unused): 411 This one octet field is currently unused and MUST be set to 412 '0x00'. 414 4.3. Technology Type Enumeration 416 A small list of technologies is provided in the table below for the 417 direct encoding of common technology types. The mapping of all 418 virtual channel technologies into a single technology type value is 419 for limiting the number of different attributes in an UPDATE message. 420 It is therefore a contribution to scalability. 422 +-------+-----------------------------------------------------------+ 423 | Value | Technology Type | 424 +-------+-----------------------------------------------------------+ 425 | 0x00 | DiffServ enabled IP (DSCP encoding) | 426 | 0x01 | Ethernet using 802.1q priority tag | 427 | 0x02 | MPLS using E-LSP | 428 | 0x03 | Virtual Channel (VC) encoding using separate channels for | 429 | | QoS forwarding / one channel per class (e.g. ATM VCs, FR | 430 | | VCs, MPLS L-LSPs) | 431 | 0x04 | GMPLS - time slot encoding | 432 | 0x05 | GMPLS - lambda encoding | 433 | 0x06 | GMPLS - fibre encoding | 434 +-------+-----------------------------------------------------------+ 436 Table 2 438 5. Attribute Usage 440 Providers MAY choose to process the QoS Marking Attributes and adopt 441 the priority encoding and tunnel selection according to their local 442 policy. Whether this MAY also lead to different IGP routing 443 decisions or even effect BGP update filters is out of scope for the 444 attribute definition. 446 Only the IP prefix originating AS is allowed to signal the QoS 447 Marking Attributes and Set. AS providers, which make use of this 448 signalling mechanism MUST make sure that only one external Class Set 449 will be advertised for the AS. All advertised prefixes, which 450 originate from that AS will be sent with the same QoS Marking 451 Attribute Set in the respective UPDATE message. Transit ASes MUST 452 NOT modify or extend the QoS Marking Attribute Set except for the 453 update of each 'QoS Marking A' field contained in the Attribute Set, 454 the respective "R, I, A" flags and the Processing Counter. Prefixes 455 with associated identical QoS Marking Attribute Sets are to be 456 advertised together in common UPDATE messages in relaying nodes. 458 Figure 4 shows an AS peering example with different Class Sets. It 459 shows the case in AS 5 where different Class Sets are used internally 460 and externally. The proposed QoS Class Set signalling will always 461 use the external definitions within the UPDATE message QoS Marking 462 Attributes. The example also shows, that IP prefixes, which 463 originate in AS 5 and AS 3 can be advertised together with the same 464 QoS Marking Attribute Set as long as their Layer 2 encoding is 465 identical. 466 AS 5 = Transit AS 467 +------------+ ================= +------------+ 468 + AS 1 + AS internal: + AS 3 + 469 + 4 classes + 5 classes + 3 classes + 470 + L2/L3 + L2/L3 + L2/L3 + 471 +(EF,2xAF,BE)+ AS external: +(EF,AF11,BE)+ 472 + [] + 3 classes +[] + 473 +------------+ L3 (EF,AF11,BE) +------------+ 474 \ +---------------+ / 475 \ | [] | / 476 \ | / \ | / 477 \ | --()---()-- | / 478 \| / | | \ |/ 479 |[] | | []| 480 /| \ | | / |\ 481 / | --()---()-- | \ 482 / | \ / | \ 483 / | [] | \ 484 / +---------------+ \ 485 +------------+ +------------+ 486 + [] + +[] + 487 + AS 2 + + AS 4 + 488 + 2 classes + + 6 classes + 489 + L2/L3 + + L1/L2/L3 + 490 + (EF,BE) + +(EF,4xAF,BE)+ 491 +------------+ +------------+ 492 [] ... AS Border Router 493 () ... AS internal Router 495 Figure 4 497 5.1. QoS Marking Attribute Example 499 See Appendix A for an example QoS Marking Attribute Set. 501 5.2. AS Border Packet Forwarding 503 IP packet forwarding based on packet header QoS encoding might 504 require remarking of packets in order to match AS internal policies 505 and encodings of neighbouring ASes. 507 Identical QoS class sets and encodings between neighbouring ASes do 508 not require any remarking. Different encodings will be matched on 509 the outgoing traffic. 511 Outgoing traffic for a given IP prefix uses the 'QoS Marking A' 512 information of the respective BGP UPDATE message QoS Marking 513 Attribute for adopted remarking of the forwarded packet. 515 If the Process Count is smaller than the number of different AS 516 numbers in the AS PATH or if the 'I' flag is set for a given 517 encoding, the outgoing traffic remarking can not be applied due to 518 this signalled lack of QoS Class forwarding support. 520 'QoS Marking O' information is used for outgoing remarking, if the 521 targeted class is not supported by the neighbouring AS. 523 5.3. IP Prefix Aggregation 525 Several IP prefixes of different IP prefix originating ASes MAY be 526 aggregated to a shorter IP prefix in transit ASes. If the original 527 Class Sets of the aggregated prefixes are identical, the aggregate 528 will use the same Set. In all other cases, the resulting IP prefix 529 aggregate is handled the same as if the transit AS were the 530 originating AS for this aggregated prefix. The transit AS provider 531 MAY care for AS internal mechanisms, which map the signalled 532 aggregate QoS Class Set to the different original Class Sets in the 533 internal forwarding path. 535 In case of IP prefix aggregation with different QoS Class Sets, the 536 'Aggregation (A)' flag of each QoS Marking Attribute within the Set 537 MUST be set to '1'. 539 6. Confidentiality Considerations 541 The disclosure of confidential AS intrinsic information is of no 542 concern since the signalled marking for QoS class encodings can be 543 adopted prior to the UPDATE advertisement of the IP prefix 544 originating AS. This way, a distinction between internal and 545 external QoS Class Sets can be achieved. AS internal cross-layer 546 marking adaptation and policy based update filtering allows for 547 consistent QoS class support despite made up QoS Class Set and 548 encoding information within UPDATE advertisements. In case of such 549 policy hiding strategy, the required AS internal ingress and egress 550 adaptation SHALL be done transparently without explicit "Active 551 Marking" and 'R' flag signalling. 553 7. IANA Considerations 555 This document defines a new BGP Extended Community Attribute, which 556 includes a "Technology Type" field. Section 4.3 enumerates a number 557 of popular technologies. This list is expected to suffice for first 558 implementations. However, future or currently uncovered technologies 559 may arise, which require an extended "Technology Type" enumeration 560 list administered by IANA. 562 8. Security Considerations 564 This extension to BGP does not change the underlying security issues 565 inherent in the existing BGP. 567 Malicious signalling behaviour of QoS marking Attribute advertising 568 ASes can result in misguided neighbours about non existing or 569 maliciously encoded Class Sets. Removal of QoS Marking Attribute 570 Sets leads to the current best effort peering, which is no stringent 571 security concern. 573 The strongest thread is the advertisement of numerous very fine 574 grained Class Sets, which could limit the scalability of this 575 approach. However, neighbouring ASes are free to set the ignore flag 576 of single attributes or to stop processing the QoS Marking Attributes 577 of a certain routing advertisement, once a self-set threshold has 578 been crossed. By means of this self defence mechanism it should not 579 be possible to crash neighbouring peers due to the excessive use of 580 the new attribute. 582 9. References 584 9.1. Normative References 586 [IANA_EC] IANA, "Border Gateway Protocol (BGP) Data Collection 587 Standard Communities", June 2008, 588 . 591 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 592 Communities Attribute", RFC 1997, August 1996. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 598 Protocol 4 (BGP-4)", RFC 4271, January 2006. 600 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 601 Communities Attribute", RFC 4360, February 2006. 603 9.2. Informative References 605 [I-D.boucadair-qos-bgp-spec] 606 Boucadair, M., "QoS-Enhanced Border Gateway Protocol", 607 draft-boucadair-qos-bgp-spec-01 (work in progress), 608 July 2005. 610 [I-D.ietf-idr-flow-spec] 611 Marques, P., Sheth, N., Raszuk, R., Greene, B., and D. 612 McPherson, "Dissemination of flow specification rules", 613 draft-ietf-idr-flow-spec-01 (work in progress), 614 April 2008. 616 [I-D.ietf-softwire-bgp-te-attribute] 617 Ould-Brahim, H., "Traffic Engineering Attribute", 618 draft-ietf-softwire-bgp-te-attribute-00 (work in 619 progress), January 2008. 621 [I-D.jacquenet-bgp-qos] 622 Cristallo, G., "The BGP QOS_NLRI Attribute", 623 draft-jacquenet-bgp-qos-00 (work in progress), 624 February 2004. 626 [I-D.liang-bgp-qos] 627 Benmohamed, L., "QoS Enhancements to BGP in Support of 628 Multiple Classes of Service", draft-liang-bgp-qos-00 (work 629 in progress), June 2006. 631 [I-D.zhang-idr-bgp-extcommunity-qos] 632 Zhang, Z., "ExtCommunity map and carry TOS value of IP 633 header", draft-zhang-idr-bgp-extcommunity-qos-00 (work in 634 progress), November 2005. 636 [MIT_CFP] Amante, S., Bitar, N., Bjorkman, N., and others, "Inter- 637 provider Quality of Service - White paper draft 1.1", 638 November 2006, 639 . 641 Appendix A. QoS Marking Attribute Example 643 The example AS is advertising several IP prefixes, which experience 644 equal QoS treatment from AS internal networks. The IP packet 645 forwarding policy within this originating AS defines e.g. 3 traffic 646 classes for IP traffic (DSCP1, DSCP2 and DSCP3). These three classes 647 are also consistently taken care of within an EXP bit supporting MPLS 648 tunnel forwarding. The BGP UPDATE message for the announced IP 649 prefixes will contain the following QoS Marking Attribute Set 650 together with the IP prefix NLRI. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |0 0 0 0 0 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| 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |0 0 1 0 1 1 1 0|0 0 0 0 0 0 0 0| C. Unused ='0'| 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |0 0 0 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 1 0 1| 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0| C. Unused ='0'| 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |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 0 0 1 1 0 0 0| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |0 0 0 1 1 0 0 0|0 0 0 0 0 0 0 0| C. Unused ='0'| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |0 0 0 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 1 1| 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0| C. Unused ='0'| 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0|0 0 0 0 1 0 0 0| 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0| C. Unused ='0'| 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 |0 0 0 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 1| 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| C. Unused ='0'| 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 The class set as well as the example encodings are arbitrarily chosen. 682 Figure 5 684 Author's Address 686 Thomas Martin Knoll 687 Chemnitz University of Technology 688 Reichenhainer Str. 70 /331 689 Chemnitz, 09126 690 GERMANY 692 Phone: +49-371-531-33246 693 Fax: +49-371-531-833246 694 Email: knoll@etit.tu-chemnitz.de 696 Full Copyright Statement 698 Copyright (C) The IETF Trust (2008). 700 This document is subject to the rights, licenses and restrictions 701 contained in BCP 78, and except as set forth therein, the authors 702 retain all their rights. 704 This document and the information contained herein are provided on an 705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 707 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 708 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 709 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Intellectual Property 714 The IETF takes no position regarding the validity or scope of any 715 Intellectual Property Rights or other rights that might be claimed to 716 pertain to the implementation or use of the technology described in 717 this document or the extent to which any license under such rights 718 might or might not be available; nor does it represent that it has 719 made any independent effort to identify any such rights. Information 720 on the procedures with respect to rights in RFC documents can be 721 found in BCP 78 and BCP 79. 723 Copies of IPR disclosures made to the IETF Secretariat and any 724 assurances of licenses to be made available, or the result of an 725 attempt made to obtain a general license or permission for the use of 726 such proprietary rights by implementers or users of this 727 specification can be obtained from the IETF on-line IPR repository at 728 http://www.ietf.org/ipr. 730 The IETF invites any interested party to bring to its attention any 731 copyrights, patents or patent applications, or other proprietary 732 rights that may cover technology that may be required to implement 733 this standard. Please address the information to the IETF at 734 ietf-ipr@ietf.org.