idnits 2.17.1 draft-knoll-idr-cos-interconnect-11.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 10, 2013) is 3813 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 276, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-24) exists of draft-knoll-idr-qos-attribute-12 -- 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 Chemnitz University of Technology 4 Intended status: Standards Track November 10, 2013 5 Expires: May 14, 2014 7 BGP Class of Service Interconnection 8 draft-knoll-idr-cos-interconnect-11 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 14, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definition and Usage of the CoS Capability . . . . . . . . . . 4 66 2.1. Extended Community Type . . . . . . . . . . . . . . . . . 4 67 2.2. Structure of the CoS Capability Attribute . . . . . . . . 4 68 2.3. Usage of the CoS Capability Attribute . . . . . . . . . . 7 69 3. Definition and Usage of the CoS Parameter Attribute . . . . . 7 70 3.1. Definition of the CoS Parameter Attribute . . . . . . . . 7 71 3.2. Usage of the CoS Parameter Attribute . . . . . . . . . . . 8 72 4. Confidentiality Considerations . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 AS interconnection is currently based on best effort interconnection 83 only. BGP-4 [RFC4271] is the de-facto interconnection protocol used 84 to exchange reachability information. There is no standardized set 85 of supported traffic classes, no standardized packet marking and no 86 standardized forwarding behaviour, which cross-domain traffic could 87 rely on. QoS policy decisions are taken by AS providers 88 independently and in an uncoordinated fashion. However, many AS 89 providers make use of the Differentiated Services Architecture 90 [RFC2475] as AS internal QoS mechanism. Within this architecture, 91 there are 64 codepoints and an unlimited number of Per Hop Behaviours 92 (PHBs) available. Some PHBs have been defined in separate RFCs, 93 which will be focused on in this document. 95 A Basic Set of supported Classes, called "Basic CoS" is defined 96 inhere, which consists of the primitive "Best Effort (BE)" PHB, the 97 "Expedited Forwarding (EF)" PHB [RFC3246], the "Assured Forwarding 98 (AF)" PHB Group [RFC2597] and the "Lower Effort" Per-Domain Behavior 99 (PDB) [RFC3662]. AS providers, which can support this Basic CoS are 100 asked to signal this capability to their interconnection partners by 101 means of the new CoS Capability Extended Community defined in 102 Section 2 of this draft. 104 4 AF PHB classes have been defined so far, which will be grouped into 105 the generally signalled "AF Group". That is, as long as the AS 106 provider can support at least one out of the 4 AF classes in his 107 externally supported CoS Set, this AS is regarded as AF capable. 109 A second transitive attribute is defined in Section 3, which is used 110 for parameter signalling about the applied access control within the 111 ingress AS border router. The reason for this traffic limitation is 112 the fact, that certain high quality forwarding behaviours can only be 113 achieved, if the percentage of high priority traffic within the 114 traffic mix lies below a certain threshold. This attribute informs 115 the interconnection partner about the applied limitation, which can 116 in turn be used to perform traffic shaping at the neighbouring AS' 117 egress. The attribute allows this limitation signalling either 118 associated to the NLRI within the same UPDATE message or with 119 "global" scope to describe the generally applied ingress limitation. 121 Both attributes are likely to be used together, if ingress class 122 limitation is used for the respective AS. 124 More detailed signalling of forwarding behaviour distinction and 125 associated cross-layer marking can be achieved using the QoS Marking 126 Attribute approach [I-D.knoll-idr-qos-attribute]. 128 2. Definition and Usage of the CoS Capability 130 2.1. Extended Community Type 132 The new CoS Capability is encoded as a BGP Extended Community 133 [RFC4360]. Extended Community Attributes are transitive optional BGP 134 attributes with Type Code 16. An adoption to the simple BGP 135 Community Attribute encoding [RFC1997] is not defined in this 136 document. The actual encoding within the BGP Extended Community 137 Attribute is as follows. 139 The CoS Capability is transitive and of regular type which results in 140 a 1 octet Type field followed by 7 octets for the CoS Capability 141 structure. The Type is IANA-assignable (FCFS procedure) and marks 142 the community as transitive across ASes. The type number has been 143 assigned by IANA to 0xYY (0x00-0x3f). 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |0 0 x x x x x x| | 148 +-+-+-+-+-+-+-+-+ 7 octet CoS Capability structure | 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1 154 2.2. Structure of the CoS Capability Attribute 156 The CoS Capability structure is deliberately kept very simple and is 157 defined as follows. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |B E A L| Currently Unused - default to '0' | 162 |E F F E| | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Currently Unused - default to '0' | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 2 169 The Currently Unused bits default to '0' and MUST be ignored on 170 reception. 172 Leading "BE, EF, AF and LE" encoding. 174 This encoding signals the BE, EF, AF Group and LE support of the 175 respective AS. 177 +-----+------------------------------------------------------------+ 178 | Bit | Encoding | 179 +-----+------------------------------------------------------------+ 180 | BE | Default to '1' to signal general "Best Effort" PHB support | 181 | EF | '1' ... "Expedited Forwarding" PHB support [RFC3246] | 182 | AF | '1' ... "Assured Forwarding" PHB group support [RFC2597] | 183 | LE | '1' ... "Lower Effort" PDB support [RFC3662] | 184 +-----+------------------------------------------------------------+ 186 Table 1: CoS support encoding 188 The implied Per-Hop-Behaviour Identification Codes follow the 189 definition as standardized in [RFC3140]. The AF Group needs to 190 consist of at least one of the currently available AF1x, AF2x, 191 AF3x and AF4x. 193 BE: 194 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 | 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 197 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 EF: 200 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 | 1 0 1 1 1 0 | 0 0 0 0 0 0 0 0 0 0 | 203 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 AF1x: 206 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 207 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 208 | 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 209 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 AF2x: 212 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 213 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 | 0 1 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 215 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 217 AF3x: 218 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 | 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 221 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 AF4x: 224 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 225 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 | 1 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 227 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 LE: 230 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 | 0 0 1 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 233 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 Figure 3 237 2.3. Usage of the CoS Capability Attribute 239 The CoS Capability is used as primitive means to signal the general 240 availability of the set of "Basic CoS" PHBs in the advertising AS. 241 This Extended Community is included within the attribute section of 242 an BGP UPDATE message and is therefore associated to the NLRI 243 information of the same message. Whether the Basic CoS is available 244 and is therefore advertised can easily being judged on for all 245 prefixes, which originate from the advertising AS. 247 All other reachability information MUST be signalled together with 248 this CoS Capability if they were received together with such an 249 Extended Community by neighbouring peers. 251 NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS 252 Capability, if it were not received together with such an attribute. 254 3. Definition and Usage of the CoS Parameter Attribute 256 3.1. Definition of the CoS Parameter Attribute 258 The CoS Parameter Attribute is an optional transitive BGP attribute. 260 The attribute contains one or more of the following: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | PHB id Code | Flags | Reserved = '0'| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | ASN of sending AS | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Token Bucket Size [b] (32-bit IEEE floating point number) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Peak Data Rate [p] (32-bit IEEE floating point number) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Minimum Policed Unit [m] (32-bit integer) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Maximum Packet Size [M] (32-bit integer) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 4 281 PHB ID: 283 This field specifies the targeted Per Hop Behaviour limitations 284 and follows the defined encoding of [RFC3140] as listed in 285 Figure 3. 287 Flags: 288 0 1 2 3 4 5 6 7 289 +--+--+--+--+--+--+--+--+ 290 |G |DR|0 |0 |0 |0 |0 |0 | 291 +--+--+--+--+--+--+--+--+ 293 Only two flags are defined. The remaining bits default to '0' and 294 MUST be ignored on reception. 296 The 'G' flag signals, whether the limitations have global scope on 297 all incoming traffic ('1') or are associated to traffic that is 298 destined to destinations within the NLRI of the UPDATE message 299 ('0'). NLRI specific limitation will supersede globally signalled 300 ones for traffic destined to those NLRI destinations. 302 The 'DR' flag signals the applied handling of non-confirming 303 traffic. DR='0' signals strict dropping of excess traffic. 304 DR='1' signals the performed remarking of excess traffic packets 305 to Best Effort traffic marking. 307 ASN of sending AS: 309 Depending on the 2-octet or 4-octet AS peering type, the sending 310 AS of the attribute MUST encode its AS number as right-aligned 311 32bit number. 313 Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed 314 Unit and Maximum Packet Size: 316 The rates and sizes are given in 4 octet IEEE floating point 317 format [IEEE] or 4 octet integer format, respectively. They are 318 parameters to a token bucket ingress filter, which is applied to 319 the packets belonging to the stated PHB id. The parameters follow 320 the definition given in [RFC2210] and [RFC2215]. 322 3.2. Usage of the CoS Parameter Attribute 324 The signalled parameters are used for PHB id Code based ingress 325 limitation. Depending on which PHB id Codes a BGP peer signals in 326 this attribute to its neighbour, it is said, that the respective PHB 327 id Code is supported and will experience the defined limitations. 329 Those limitations can be applied to all incoming traffic of a 330 specific PHB id Code (marked as 'G') or only for incoming traffic, 331 that is destined for the NLRI of the given UPDATE message. 333 The resulting treatment for non-confirming traffic is signalled 334 through the 'DR' flag. 336 To withdraw a previously signalled limitation, a CoS Parameter 337 Attribute for the respective PHB id Code MUST be sent with a rate 338 value [r] of zero. Using the 'G' flag, this can be withdrawn 339 globally for all traffic of the given PHB id Code or withdrawn only 340 for traffic destined to the prefixes given in the NLRI of the UPDATE. 341 Previously signalled non-global (i.e. NLRI specific) limitations are 342 also waived, if the same prefix is advertised without a CoS Parameter 343 Attribute later on. In this case, the missing attribute is 344 considered as the above described 'rate zero update' for those 345 prefixes. Waived prefix specific limitations do not supersede global 346 limitations for the respective PHB id Code. In turn, a withdrawal of 347 a global limitation does also withdraw any possibly existing prefix 348 specific ones for the respective PHB id Code. 350 All limitations have AS local scope for the advertising AS and the 351 neighbouring AS might or might not adopt its sending behaviour to 352 those advertised limitations. 354 Despite the transitive nature of the new attribute, its usage for 355 ingress limitation is confined to neighbouring ASes. Processing of 356 the conveyed parameters is only valid for peers, who are peering with 357 the AS specified in the ASN field of the attribute. 359 The attribute SHOULD NOT be transitively relayed to non-adjacent 360 interconnection partners. 362 4. Confidentiality Considerations 364 The disclosure of confidential AS intrinsic information by means of 365 the signalled Basic CoS support is of low key security concern. The 366 disclosure of information through CoS Parameter signalling is more 367 detailed. However, all included parameters are exchanged with direct 368 interconnection partners and are the free choice of each AS provider. 370 5. IANA Considerations 372 This document defines a new BGP Extended Community, which needs to be 373 assigned a number by IANA within the Extended Community list. The 374 new CoS Capability is a BGP Extended Community of regular type. It 375 is IANA-assignable (FCFS procedure) and is transitive across ASes. A 376 number assignment application within the numbering range of 0x00-0x3f 377 is made to IANA. 379 Note to RFC Editor: this section may be removed on publication as an 380 RFC. 382 This document defines a new BGP attribute. This attribute is 383 optional and transitive. 385 6. Security Considerations 387 This extension to BGP does not change the underlying security issues 388 inherent in the existing BGP version. 390 The signalled attributes are transitive with limited relay operation 391 in the CoS Parameter Attribute case. AS peers, which use egress 392 traffic shaper on the signalled limitations SHOULD exhaust all 393 available BGP security features to make sure, that the signalled 394 limitation is actually sent by the adjacent peer. 396 7. References 398 7.1. Normative References 400 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 401 Arithmetic", ISBN 1-5593-7653-8, 1985. 403 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 404 Communities Attribute", RFC 1997, August 1996. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 410 Services", RFC 2210, September 1997. 412 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 413 Parameters for Integrated Service Network Elements", 414 RFC 2215, September 1997. 416 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 417 "Assured Forwarding PHB Group", RFC 2597, June 1999. 419 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 420 "Per Hop Behavior Identification Codes", RFC 3140, 421 June 2001. 423 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 424 J., Courtney, W., Davari, S., Firoiu, V., and D. 425 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 426 Behavior)", RFC 3246, March 2002. 428 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 429 Protocol 4 (BGP-4)", RFC 4271, January 2006. 431 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 432 Communities Attribute", RFC 4360, February 2006. 434 7.2. Informative References 436 [I-D.knoll-idr-qos-attribute] 437 Knoll, T., "BGP Extended Community for QoS Marking", 438 draft-knoll-idr-qos-attribute-12 (work in progress), 439 July 2013. 441 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 442 and W. Weiss, "An Architecture for Differentiated 443 Services", RFC 2475, December 1998. 445 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 446 Per-Domain Behavior (PDB) for Differentiated Services", 447 RFC 3662, December 2003. 449 Author's Address 451 Thomas Martin Knoll 452 Chemnitz University of Technology 454 Email: knoll@etit.tu-chemnitz.de