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