idnits 2.17.1 draft-knoll-idr-cos-interconnect-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 23, 2018) is 1978 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 283, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-24) exists of draft-knoll-idr-qos-attribute-22 -- 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 November 23, 2018 4 Intended status: Standards Track 5 Expires: May 27, 2019 7 BGP Class of Service Interconnection 8 draft-knoll-idr-cos-interconnect-21 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 27, 2019. 48 Copyright Notice 50 Copyright (c) 2018 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 . . . . . . . . . . 7 70 3. Definition and Usage of the CoS Parameter Attribute . . . . . 7 71 3.1. Definition of the CoS Parameter Attribute . . . . . . . . 7 72 3.2. Usage of the CoS Parameter Attribute . . . . . . . . . . 8 73 4. Confidentiality Considerations . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 LE: 236 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 237 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 238 | 0 0 1 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 239 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 241 Figure 3 243 2.3. Usage of the CoS Capability Attribute 245 The CoS Capability is used as primitive means to signal the general 246 availability of the set of "Basic CoS" PHBs in the advertising AS. 247 This Extended Community is included within the attribute section of 248 an BGP UPDATE message and is therefore associated to the NLRI 249 information of the same message. Whether the Basic CoS is available 250 and is therefore advertised can easily being judged on for all 251 prefixes, which originate from the advertising AS. 253 All other reachability information MUST be signalled together with 254 this CoS Capability if they were received together with such an 255 Extended Community by neighbouring peers. 257 NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS 258 Capability, if it were not received together with such an attribute. 260 3. Definition and Usage of the CoS Parameter Attribute 262 3.1. Definition of the CoS Parameter Attribute 264 The CoS Parameter Attribute is an optional transitive BGP attribute. 266 The attribute contains one or more of the following: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | PHB id Code | Flags | Reserved = '0'| 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ASN of sending AS | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Token Bucket Size [b] (32-bit IEEE floating point number) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Peak Data Rate [p] (32-bit IEEE floating point number) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Minimum Policed Unit [m] (32-bit integer) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Maximum Packet Size [M] (32-bit integer) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 4 288 PHB ID: 290 This field specifies the targeted Per Hop Behaviour limitations 291 and follows the defined encoding of [RFC3140] as listed in 292 Figure 3. 294 Flags: 296 0 1 2 3 4 5 6 7 297 +--+--+--+--+--+--+--+--+ 298 |G |DR|0 |0 |0 |0 |0 |0 | 299 +--+--+--+--+--+--+--+--+ 301 Only two flags are defined. The remaining bits default to '0' and 302 MUST be ignored on reception. 304 The 'G' flag signals, whether the limitations have global scope on 305 all incoming traffic ('1') or are associated to traffic that is 306 destined to destinations within the NLRI of the UPDATE message 307 ('0'). NLRI specific limitation will supersede globally signalled 308 ones for traffic destined to those NLRI destinations. 310 The 'DR' flag signals the applied handling of non-confirming 311 traffic. DR='0' signals strict dropping of excess traffic. 312 DR='1' signals the performed remarking of excess traffic packets 313 to Best Effort traffic marking. 315 ASN of sending AS: 317 Depending on the 2-octet or 4-octet AS peering type, the sending 318 AS of the attribute MUST encode its AS number as right-aligned 319 32bit number. 321 Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed 322 Unit and Maximum Packet Size: 324 The rates and sizes are given in 4 octet IEEE floating point 325 format [IEEE] or 4 octet integer format, respectively. They are 326 parameters to a token bucket ingress filter, which is applied to 327 the packets belonging to the stated PHB id. The parameters follow 328 the definition given in [RFC2210] and [RFC2215]. 330 3.2. Usage of the CoS Parameter Attribute 332 The signalled parameters are used for PHB id Code based ingress 333 limitation. Depending on which PHB id Codes a BGP peer signals in 334 this attribute to its neighbour, it is said, that the respective PHB 335 id Code is supported and will experience the defined limitations. 337 Those limitations can be applied to all incoming traffic of a 338 specific PHB id Code (marked as 'G') or only for incoming traffic, 339 that is destined for the NLRI of the given UPDATE message. 341 The resulting treatment for non-confirming traffic is signalled 342 through the 'DR' flag. 344 To withdraw a previously signalled limitation, a CoS Parameter 345 Attribute for the respective PHB id Code MUST be sent with a rate 346 value [r] of zero. Using the 'G' flag, this can be withdrawn 347 globally for all traffic of the given PHB id Code or withdrawn only 348 for traffic destined to the prefixes given in the NLRI of the UPDATE. 349 Previously signalled non-global (i.e. NLRI specific) limitations are 350 also waived, if the same prefix is advertised without a CoS Parameter 351 Attribute later on. In this case, the missing attribute is 352 considered as the above described 'rate zero update' for those 353 prefixes. Waived prefix specific limitations do not supersede global 354 limitations for the respective PHB id Code. In turn, a withdrawal of 355 a global limitation does also withdraw any possibly existing prefix 356 specific ones for the respective PHB id Code. 358 All limitations have AS local scope for the advertising AS and the 359 neighbouring AS might or might not adopt its sending behaviour to 360 those advertised limitations. 362 Despite the transitive nature of the new attribute, its usage for 363 ingress limitation is confined to neighbouring ASes. Processing of 364 the conveyed parameters is only valid for peers, who are peering with 365 the AS specified in the ASN field of the attribute. 367 The attribute SHOULD NOT be transitively relayed to non-adjacent 368 interconnection partners. 370 4. Confidentiality Considerations 372 The disclosure of confidential AS intrinsic information by means of 373 the signalled Basic CoS support is of low key security concern. The 374 disclosure of information through CoS Parameter signalling is more 375 detailed. However, all included parameters are exchanged with direct 376 interconnection partners and are the free choice of each AS provider. 378 5. IANA Considerations 380 This document defines a new BGP Extended Community, which needs to be 381 assigned a number by IANA within the Extended Community list. The 382 new CoS Capability is a BGP Extended Community of regular type. It 383 is IANA-assignable (FCFS procedure) and is transitive across ASes. A 384 number assignment application within the numbering range of 0x00-0x3f 385 is made to IANA. 387 Note to RFC Editor: this section may be removed on publication as an 388 RFC. 390 This document defines a new BGP attribute. This attribute is 391 optional and transitive. 393 6. Security Considerations 395 This extension to BGP does not change the underlying security issues 396 inherent in the existing BGP version. 398 The signalled attributes are transitive with limited relay operation 399 in the CoS Parameter Attribute case. AS peers, which use egress 400 traffic shaper on the signalled limitations SHOULD exhaust all 401 available BGP security features to make sure, that the signalled 402 limitation is actually sent by the adjacent peer. 404 7. References 406 7.1. Normative References 408 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 409 Arithmetic", ISBN 1-5593-7653-8, 1985. 411 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 412 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 413 . 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, 417 DOI 10.17487/RFC2119, March 1997, . 420 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 421 Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, 422 . 424 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 425 Parameters for Integrated Service Network Elements", 426 RFC 2215, DOI 10.17487/RFC2215, September 1997, 427 . 429 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 430 "Assured Forwarding PHB Group", RFC 2597, 431 DOI 10.17487/RFC2597, June 1999, . 434 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 435 "Per Hop Behavior Identification Codes", RFC 3140, 436 DOI 10.17487/RFC3140, June 2001, . 439 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 440 J., Courtney, W., Davari, S., Firoiu, V., and D. 441 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 442 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 443 . 445 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 446 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 447 DOI 10.17487/RFC4271, January 2006, . 450 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 451 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 452 February 2006, . 454 7.2. Informative References 456 [I-D.knoll-idr-qos-attribute] 457 Knoll, T., "BGP Extended Community for QoS Marking", 458 draft-knoll-idr-qos-attribute-22 (work in progress), July 459 2018. 461 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 462 and W. Weiss, "An Architecture for Differentiated 463 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 464 . 466 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 467 Per-Domain Behavior (PDB) for Differentiated Services", 468 RFC 3662, DOI 10.17487/RFC3662, December 2003, 469 . 471 Author's Address 473 Thomas Martin Knoll 475 Email: thomas.m.knoll@gmail.com