idnits 2.17.1 draft-knoll-idr-cos-interconnect-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2015) is 3076 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) == Missing Reference: 'M' is mentioned on line 282, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-24) exists of draft-knoll-idr-qos-attribute-16 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 TU Chemnitz 4 Intended status: Standards Track November 16, 2015 5 Expires: May 19, 2016 7 BGP Class of Service Interconnection 8 draft-knoll-idr-cos-interconnect-15 10 Abstract 12 This document focuses on Class of Service Interconnection at inter- 13 domain interconnection points. It specifies two new transitive 14 attributes, which enable adjacent peers to signal Class of Service 15 Capabilities and certain Class of Service admission control 16 Parameters. The new "CoS Capability" is deliberately kept simple and 17 denotes the general EF, AF Group BE and LE forwarding support across 18 the advertising AS. The second "CoS Parameter Attribute" is of 19 variable length and contains a more detailed description of available 20 forwarding behaviours using the PHB id Code encoding. Each PHB id 21 Code is associated with rate and size based traffic parameters, which 22 will be applied in the ingress AS Border Router for admission control 23 purposes to a given forwarding behaviour. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 19, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Definition and Usage of the CoS Capability . . . . . . . . . 3 67 2.1. Extended Community Type . . . . . . . . . . . . . . . . . 3 68 2.2. Structure of the CoS Capability Attribute . . . . . . . . 4 69 2.3. Usage of the CoS Capability Attribute . . . . . . . . . . 6 70 3. Definition and Usage of the CoS Parameter Attribute . . . . . 6 71 3.1. Definition of the CoS Parameter Attribute . . . . . . . . 6 72 3.2. Usage of the CoS Parameter Attribute . . . . . . . . . . 8 73 4. Confidentiality Considerations . . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 7.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 AS interconnection is currently based on best effort interconnection 84 only. BGP-4 [RFC4271] is the de-facto interconnection protocol used 85 to exchange reachability information. There is no standardized set 86 of supported traffic classes, no standardized packet marking and no 87 standardized forwarding behaviour, which cross-domain traffic could 88 rely on. QoS policy decisions are taken by AS providers 89 independently and in an uncoordinated fashion. However, many AS 90 providers make use of the Differentiated Services Architecture 91 [RFC2475] as AS internal QoS mechanism. Within this architecture, 92 there are 64 codepoints and an unlimited number of Per Hop Behaviours 93 (PHBs) available. Some PHBs have been defined in separate RFCs, 94 which will be focused on in this document. 96 A Basic Set of supported Classes, called "Basic CoS" is defined 97 inhere, which consists of the primitive "Best Effort (BE)" PHB, the 98 "Expedited Forwarding (EF)" PHB [RFC3246], the "Assured Forwarding 99 (AF)" PHB Group [RFC2597] and the "Lower Effort" Per-Domain Behavior 100 (PDB) [RFC3662]. AS providers, which can support this Basic CoS are 101 asked to signal this capability to their interconnection partners by 102 means of the new CoS Capability Extended Community defined in 103 Section 2 of this draft. 105 4 AF PHB classes have been defined so far, which will be grouped into 106 the generally signalled "AF Group". That is, as long as the AS 107 provider can support at least one out of the 4 AF classes in his 108 externally supported CoS Set, this AS is regarded as AF capable. 110 A second transitive attribute is defined in Section 3, which is used 111 for parameter signalling about the applied access control within the 112 ingress AS border router. The reason for this traffic limitation is 113 the fact, that certain high quality forwarding behaviours can only be 114 achieved, if the percentage of high priority traffic within the 115 traffic mix lies below a certain threshold. This attribute informs 116 the interconnection partner about the applied limitation, which can 117 in turn be used to perform traffic shaping at the neighbouring AS' 118 egress. The attribute allows this limitation signalling either 119 associated to the NLRI within the same UPDATE message or with 120 "global" scope to describe the generally applied ingress limitation. 122 Both attributes are likely to be used together, if ingress class 123 limitation is used for the respective AS. 125 More detailed signalling of forwarding behaviour distinction and 126 associated cross-layer marking can be achieved using the QoS Marking 127 Attribute approach [I-D.knoll-idr-qos-attribute]. 129 2. Definition and Usage of the CoS Capability 131 2.1. Extended Community Type 133 The new CoS Capability is encoded as a BGP Extended Community 134 [RFC4360]. Extended Community Attributes are transitive optional BGP 135 attributes with Type Code 16. An adoption to the simple BGP 136 Community Attribute encoding [RFC1997] is not defined in this 137 document. The actual encoding within the BGP Extended Community 138 Attribute is as follows. 140 The CoS Capability is transitive and of regular type which results in 141 a 1 octet Type field followed by 7 octets for the CoS Capability 142 structure. The Type is IANA-assignable (FCFS procedure) and marks 143 the community as transitive across ASes. The type number has been 144 assigned by IANA to 0xYY (0x00-0x3f). 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |0 0 x x x x x x| | 150 +-+-+-+-+-+-+-+-+ 7 octet CoS Capability structure | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1 156 2.2. Structure of the CoS Capability Attribute 158 The CoS Capability structure is deliberately kept very simple and is 159 defined as follows. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |B E A L| Currently Unused - default to '0' | 165 |E F F E| | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Currently Unused - default to '0' | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 2 172 The Currently Unused bits default to '0' and MUST be ignored on 173 reception. 175 Leading "BE, EF, AF and LE" encoding. 177 This encoding signals the BE, EF, AF Group and LE support of the 178 respective AS. 180 +-----+------------------------------------------------------------+ 181 | Bit | Encoding | 182 +-----+------------------------------------------------------------+ 183 | BE | Default to '1' to signal general "Best Effort" PHB support | 184 +-----+------------------------------------------------------------+ 185 | EF | '1' ... "Expedited Forwarding" PHB support [RFC3246] | 186 +-----+------------------------------------------------------------+ 187 | AF | '1' ... "Assured Forwarding" PHB group support [RFC2597] | 188 +-----+------------------------------------------------------------+ 189 | LE | '1' ... "Lower Effort" PDB support [RFC3662] | 190 +-----+------------------------------------------------------------+ 192 Table 1: CoS support encoding 194 The implied Per-Hop-Behaviour Identification Codes follow the 195 definition as standardized in [RFC3140]. The AF Group needs to 196 consist of at least one of the currently available AF1x, AF2x, AF3x 197 and AF4x. 199 BE: 200 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 | 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 203 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 EF: 206 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 207 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 208 | 1 0 1 1 1 0 | 0 0 0 0 0 0 0 0 0 0 | 209 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 AF1x: 212 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 213 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 | 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 215 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 217 AF2x: 218 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 | 0 1 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 221 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 AF3x: 224 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 225 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 | 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 227 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 AF4x: 230 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 | 1 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 233 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 234 LE: 235 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 236 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 237 | 0 0 1 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 238 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 240 Figure 3 242 2.3. Usage of the CoS Capability Attribute 244 The CoS Capability is used as primitive means to signal the general 245 availability of the set of "Basic CoS" PHBs in the advertising AS. 246 This Extended Community is included within the attribute section of 247 an BGP UPDATE message and is therefore associated to the NLRI 248 information of the same message. Whether the Basic CoS is available 249 and is therefore advertised can easily being judged on for all 250 prefixes, which originate from the advertising AS. 252 All other reachability information MUST be signalled together with 253 this CoS Capability if they were received together with such an 254 Extended Community by neighbouring peers. 256 NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS 257 Capability, if it were not received together with such an attribute. 259 3. Definition and Usage of the CoS Parameter Attribute 261 3.1. Definition of the CoS Parameter Attribute 263 The CoS Parameter Attribute is an optional transitive BGP attribute. 265 The attribute contains one or more of the following: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | PHB id Code | Flags | Reserved = '0'| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | ASN of sending AS | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Token Bucket Size [b] (32-bit IEEE floating point number) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Peak Data Rate [p] (32-bit IEEE floating point number) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Minimum Policed Unit [m] (32-bit integer) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Maximum Packet Size [M] (32-bit integer) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 4 287 PHB ID: 289 This field specifies the targeted Per Hop Behaviour limitations 290 and follows the defined encoding of [RFC3140] as listed in Figure 291 3. 293 Flags: 295 0 1 2 3 4 5 6 7 296 +--+--+--+--+--+--+--+--+ 297 |G |DR|0 |0 |0 |0 |0 |0 | 298 +--+--+--+--+--+--+--+--+ 300 Only two flags are defined. The remaining bits default to '0' and 301 MUST be ignored on reception. 303 The 'G' flag signals, whether the limitations have global scope on 304 all incoming traffic ('1') or are associated to traffic that is 305 destined to destinations within the NLRI of the UPDATE message 306 ('0'). NLRI specific limitation will supersede globally signalled 307 ones for traffic destined to those NLRI destinations. 309 The 'DR' flag signals the applied handling of non-confirming 310 traffic. DR='0' signals strict dropping of excess traffic. 311 DR='1' signals the performed remarking of excess traffic packets 312 to Best Effort traffic marking. 314 ASN of sending AS: 316 Depending on the 2-octet or 4-octet AS peering type, the sending 317 AS of the attribute MUST encode its AS number as right-aligned 318 32bit number. 320 Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed 321 Unit and Maximum Packet Size: 323 The rates and sizes are given in 4 octet IEEE floating point 324 format [IEEE] or 4 octet integer format, respectively. They are 325 parameters to a token bucket ingress filter, which is applied to 326 the packets belonging to the stated PHB id. The parameters follow 327 the definition given in [RFC2210] and [RFC2215]. 329 3.2. Usage of the CoS Parameter Attribute 331 The signalled parameters are used for PHB id Code based ingress 332 limitation. Depending on which PHB id Codes a BGP peer signals in 333 this attribute to its neighbour, it is said, that the respective PHB 334 id Code is supported and will experience the defined limitations. 336 Those limitations can be applied to all incoming traffic of a 337 specific PHB id Code (marked as 'G') or only for incoming traffic, 338 that is destined for the NLRI of the given UPDATE message. 340 The resulting treatment for non-confirming traffic is signalled 341 through the 'DR' flag. 343 To withdraw a previously signalled limitation, a CoS Parameter 344 Attribute for the respective PHB id Code MUST be sent with a rate 345 value [r] of zero. Using the 'G' flag, this can be withdrawn 346 globally for all traffic of the given PHB id Code or withdrawn only 347 for traffic destined to the prefixes given in the NLRI of the UPDATE. 348 Previously signalled non-global (i.e. NLRI specific) limitations are 349 also waived, if the same prefix is advertised without a CoS Parameter 350 Attribute later on. In this case, the missing attribute is 351 considered as the above described 'rate zero update' for those 352 prefixes. Waived prefix specific limitations do not supersede global 353 limitations for the respective PHB id Code. In turn, a withdrawal of 354 a global limitation does also withdraw any possibly existing prefix 355 specific ones for the respective PHB id Code. 357 All limitations have AS local scope for the advertising AS and the 358 neighbouring AS might or might not adopt its sending behaviour to 359 those advertised limitations. 361 Despite the transitive nature of the new attribute, its usage for 362 ingress limitation is confined to neighbouring ASes. Processing of 363 the conveyed parameters is only valid for peers, who are peering with 364 the AS specified in the ASN field of the attribute. 366 The attribute SHOULD NOT be transitively relayed to non-adjacent 367 interconnection partners. 369 4. Confidentiality Considerations 371 The disclosure of confidential AS intrinsic information by means of 372 the signalled Basic CoS support is of low key security concern. The 373 disclosure of information through CoS Parameter signalling is more 374 detailed. However, all included parameters are exchanged with direct 375 interconnection partners and are the free choice of each AS provider. 377 5. IANA Considerations 379 This document defines a new BGP Extended Community, which needs to be 380 assigned a number by IANA within the Extended Community list. The 381 new CoS Capability is a BGP Extended Community of regular type. It 382 is IANA-assignable (FCFS procedure) and is transitive across ASes. A 383 number assignment application within the numbering range of 0x00-0x3f 384 is made to IANA. 386 Note to RFC Editor: this section may be removed on publication as an 387 RFC. 389 This document defines a new BGP attribute. This attribute is 390 optional and transitive. 392 6. Security Considerations 394 This extension to BGP does not change the underlying security issues 395 inherent in the existing BGP version. 397 The signalled attributes are transitive with limited relay operation 398 in the CoS Parameter Attribute case. AS peers, which use egress 399 traffic shaper on the signalled limitations SHOULD exhaust all 400 available BGP security features to make sure, that the signalled 401 limitation is actually sent by the adjacent peer. 403 7. References 405 7.1. Normative References 407 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 408 Arithmetic", ISBN 1-5593-7653-8, 1985. 410 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 411 Communities Attribute", RFC 1997, August 1996. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 417 Services", RFC 2210, September 1997. 419 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 420 Parameters for Integrated Service Network Elements", RFC 421 2215, September 1997. 423 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 424 "Assured Forwarding PHB Group", RFC 2597, June 1999. 426 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 427 "Per Hop Behavior Identification Codes", RFC 3140, June 428 2001. 430 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 431 J., Courtney, W., Davari, S., Firoiu, V., and D. 432 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 433 Behavior)", RFC 3246, March 2002. 435 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 436 Protocol 4 (BGP-4)", RFC 4271, January 2006. 438 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 439 Communities Attribute", RFC 4360, February 2006. 441 7.2. Informative References 443 [I-D.knoll-idr-qos-attribute] 444 Knoll, T., "BGP Extended Community for QoS Marking", 445 draft-knoll-idr-qos-attribute-16 (work in progress), July 446 2015. 448 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 449 and W. Weiss, "An Architecture for Differentiated 450 Services", RFC 2475, December 1998. 452 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 453 Per-Domain Behavior (PDB) for Differentiated Services", 454 RFC 3662, December 2003. 456 Author's Address 458 Thomas Martin Knoll 459 TU Chemnitz 461 Email: thomas.m.knoll@gmail.com