idnits 2.17.1 draft-knoll-idr-cos-interconnect-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (May 11, 2009) is 5463 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 279, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-24) exists of draft-knoll-idr-qos-attribute-03 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 1 error (**), 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 May 11, 2009 5 Expires: November 12, 2009 7 BGP Class of Service Interconnection 8 draft-knoll-idr-cos-interconnect-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 12, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document focuses on Class of Service Interconnection at inter- 47 domain interconnection points. It specifies two new transitive 48 attributes, which enable adjacent peers to signal Class of Service 49 Capabilities and certain Class of Service admission control 50 Parameters. The new "CoS Capability" is deliberately kept simple and 51 denotes the general EF, AF Group BE and LE forwarding support across 52 the advertising AS. The second "CoS Parameter Attribute" is of 53 variable length and contains a more detailed description of available 54 forwarding behaviours using the PHB id Code encoding. Each PHB id 55 Code is associated with rate and size based traffic parameters, which 56 will be applied in the ingress AS Border Router for admission control 57 purposes to a given forwarding behaviour. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definition and Usage of the CoS Capability . . . . . . . . . . 4 69 2.1. Extended Community Type . . . . . . . . . . . . . . . . . 4 70 2.2. Structure of the CoS Capability Attribute . . . . . . . . 4 71 2.3. Usage of the CoS Capability Attribute . . . . . . . . . . 7 72 3. Definition and Usage of the CoS Parameter Attribute . . . . . 7 73 3.1. Definition of the CoS Parameter Attribute . . . . . . . . 7 74 3.2. Usage of the CoS Parameter Attribute . . . . . . . . . . . 8 75 4. Confidentiality Considerations . . . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 AS interconnection is currently based on best effort interconnection 86 only. BGP-4 [RFC4271] is the de-facto interconnection protocol used 87 to exchange reachability information. There is no standardized set 88 of supported traffic classes, no standardized packet marking and no 89 standardized forwarding behaviour, which cross-domain traffic could 90 rely on. QoS policy decisions are taken by AS providers 91 independently and in an uncoordinated fashion. However, many AS 92 providers make use of the Differentiated Services Architecture 93 [RFC2475] as AS internal QoS mechanism. Within this architecture, 94 there are 64 codepoints and an unlimited number of Per Hop Behaviours 95 (PHBs) available. Some PHBs have been defined in separate RFCs, 96 which will be focused on in this document. 98 A Basic Set of supported Classes, called "Basic CoS" is defined 99 inhere, which consists of the primitive "Best Effort (BE)" PHB, the 100 "Expedited Forwarding (EF)" PHB [RFC3246], the "Assured Forwarding 101 (AF)" PHB Group [RFC2597] and the "Lower Effort" Per-Domain Behavior 102 (PDB) [RFC3662]. AS providers, which can support this Basic CoS are 103 asked to signal this capability to their interconnection partners by 104 means of the new CoS Capability Extended Community defined in 105 Section 2 of this draft. 107 4 AF PHB classes have been defined so far, which will be grouped into 108 the generally signalled "AF Group". That is, as long as the AS 109 provider can support at least one out of the 4 AF classes in his 110 externally supported CoS Set, this AS is regarded as AF capable. 112 A second transitive attribute is defined in Section 3, which is used 113 for parameter signalling about the applied access control within the 114 ingress AS border router. The reason for this traffic limitation is 115 the fact, that certain high quality forwarding behaviours can only be 116 achieved, if the percentage of high priority traffic within the 117 traffic mix lies below a certain threshold. This attribute informs 118 the interconnection partner about the applied limitation, which can 119 in turn be used to perform traffic shaping at the neighbouring AS' 120 egress. The attribute allows this limitation signalling either 121 associated to the NLRI within the same UPDATE message or with 122 "global" scope to describe the generally applied ingress limitation. 124 Both attributes are likely to be used together, if ingress class 125 limitation is used for the respective AS. 127 More detailed signalling of forwarding behaviour distinction and 128 associated cross-layer marking can be achieved using the QoS Marking 129 Attribute approach [I-D.knoll-idr-qos-attribute]. 131 2. Definition and Usage of the CoS Capability 133 2.1. Extended Community Type 135 The new CoS Capability is encoded as a BGP Extended Community 136 [RFC4360]. Extended Community Attributes are transitive optional BGP 137 attributes with Type Code 16. An adoption to the simple BGP 138 Community Attribute encoding [RFC1997] is not defined in this 139 document. The actual encoding within the BGP Extended Community 140 Attribute is as follows. 142 The CoS Capability is transitive and of regular type which results in 143 a 1 octet Type field followed by 7 octets for the CoS Capability 144 structure. The Type is IANA-assignable (FCFS procedure) and marks 145 the community as transitive across ASes. The type number has been 146 assigned by IANA to 0xYY (0x00-0x3f). 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |0 0 x x x x x x| | 151 +-+-+-+-+-+-+-+-+ 7 octet CoS Capability structure | 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1 157 2.2. Structure of the CoS Capability Attribute 159 The CoS Capability structure is deliberately kept very simple and is 160 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 | EF | '1' ... "Expedited Forwarding" PHB support [RFC3246] | 185 | AF | '1' ... "Assured Forwarding" PHB group support [RFC2597] | 186 | LE | '1' ... "Lower Effort" PDB support [RFC3662] | 187 +-----+------------------------------------------------------------+ 189 Table 1: CoS support encoding 191 The implied Per-Hop-Behaviour Identification Codes follow the 192 definition as standardized in [RFC3140]. The AF Group needs to 193 consist of at least one of the currently available AF1x, AF2x, 194 AF3x and AF4x. 196 BE: 197 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 | 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 EF: 203 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 | 1 0 1 1 1 0 | 0 0 0 0 0 0 0 0 0 0 | 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 208 AF1x: 209 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 | 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 AF2x: 215 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 216 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 217 | 0 1 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 218 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 AF3x: 221 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 222 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 | 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 AF4x: 227 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 228 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 | 1 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 230 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 LE: 233 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 234 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 | 0 0 1 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 236 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 238 Figure 3 240 2.3. Usage of the CoS Capability Attribute 242 The CoS Capability is used as primitive means to signal the general 243 availability of the set of "Basic CoS" PHBs in the advertising AS. 244 This Extended Community is included within the attribute section of 245 an BGP UPDATE message and is therefore associated to the NLRI 246 information of the same message. Whether the Basic CoS is available 247 and is therefore advertised can easily being judged on for all 248 prefixes, which originate from the advertising AS. 250 All other reachability information MUST be signalled together with 251 this CoS Capability if they were received together with such an 252 Extended Community by neighbouring peers. 254 NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS 255 Capability, if it were not received together with such an attribute. 257 3. Definition and Usage of the CoS Parameter Attribute 259 3.1. Definition of the CoS Parameter Attribute 261 The CoS Parameter Attribute is an optional transitive BGP attribute. 263 The attribute contains one or more of the following: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | PHB id Code | Flags | Reserved = '0'| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | ASN of sending AS | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Token Bucket Size [b] (32-bit IEEE floating point number) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Peak Data Rate [p] (32-bit IEEE floating point number) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Minimum Policed Unit [m] (32-bit integer) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Maximum Packet Size [M] (32-bit integer) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 4 284 PHB ID: 286 This field specifies the targeted Per Hop Behaviour limitations 287 and follows the defined encoding of [RFC3140] as listed in 288 Figure 3. 290 Flags: 291 0 1 2 3 4 5 6 7 292 +--+--+--+--+--+--+--+--+ 293 |G |DR|0 |0 |0 |0 |0 |0 | 294 +--+--+--+--+--+--+--+--+ 296 Only two flags are defined. The remaining bits default to '0' and 297 MUST be ignored on reception. 299 The 'G' flag signals, whether the limitations have global scope on 300 all incoming traffic ('1') or are associated to traffic that is 301 destined to destinations within the NLRI of the UPDATE message 302 ('0'). NLRI specific limitation will supersede globally signalled 303 ones for traffic destined to those NLRI destinations. 305 The 'DR' flag signals the applied handling of non-confirming 306 traffic. DR='0' signals strict dropping of excess traffic. 307 DR='1' signals the performed remarking of excess traffic packets 308 to Best Effort traffic marking. 310 ASN of sending AS: 312 Depending on the 2-octet or 4-octet AS peering type, the sending 313 AS of the attribute MUST encode its AS number as right-aligned 314 32bit number. 316 Peak Data Rate, Token Bucket Rate, Token Bucket Size, Minimum Policed 317 Unit and Maximum Packet Size: 319 The rates and sizes are given in 4 octet IEEE floating point 320 format [IEEE] or 4 octet integer format, respectively. They are 321 parameters to a token bucket ingress filter, which is applied to 322 the packets belonging to the stated PHB id. The parameters follow 323 the definition given in [RFC2210] and [RFC2215]. 325 3.2. Usage of the CoS Parameter Attribute 327 The signalled parameters are used for PHB id Code based ingress 328 limitation. Depending on which PHB id Codes a BGP peer signals in 329 this attribute to its neighbour, it is said, that the respective PHB 330 id Code is supported and will experience the defined limitations. 332 Those limitations can be applied to all incoming traffic of a 333 specific PHB id Code (marked as 'G') or only for incoming traffic, 334 that is destined for the NLRI of the given UPDATE message. 336 The resulting treatment for non-confirming traffic is signalled 337 through the 'DR' flag. 339 All limitations have AS local scope for the advertising AS and the 340 neighbouring AS might or might not adopt its sending behaviour to 341 those advertised limitations. 343 Despite the transitive nature of the new attribute, its usage for 344 ingress limitation is confined to neighbouring ASes. Processing of 345 the conveyed parameters is only valid for peers, who are peering with 346 the AS specified in the ASN field of the attribute. 348 The attribute SHOULD NOT be transitively relayed to non-adjacent 349 interconnection partners. 351 4. Confidentiality Considerations 353 The disclosure of confidential AS intrinsic information by means of 354 the signalled Basic CoS support is of low key security concern. The 355 disclosure of information through CoS Parameter signalling is more 356 detailed. However, all included parameters are exchanged with direct 357 interconnection partners and are the free choice of each AS provider. 359 5. IANA Considerations 361 This document defines a new BGP Extended Community, which needs to be 362 assigned a number by IANA within the Extended Community list. The 363 new CoS Capability is a BGP Extended Community of regular type. It 364 is IANA-assignable (FCFS procedure) and is transitive across ASes. A 365 number assignment application within the numbering range of 0x00-0x3f 366 is made to IANA. 368 Note to RFC Editor: this section may be removed on publication as an 369 RFC. 371 This document defines a new BGP attribute. This attribute is 372 optional and transitive. 374 6. Security Considerations 376 This extension to BGP does not change the underlying security issues 377 inherent in the existing BGP version. 379 The signalled attributes are transitive with limited relay operation 380 in the CoS Parameter Attribute case. AS peers, which use egress 381 traffic shaper on the signalled limitations SHOULD exhaust all 382 available BGP security features to make sure, that the signalled 383 limitation is actually sent by the adjacent peer. 385 7. References 387 7.1. Normative References 389 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 390 Arithmetic", ISBN 1-5593-7653-8, 1985. 392 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 393 Communities Attribute", RFC 1997, August 1996. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 399 Services", RFC 2210, September 1997. 401 [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization 402 Parameters for Integrated Service Network Elements", 403 RFC 2215, September 1997. 405 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 406 "Assured Forwarding PHB Group", RFC 2597, June 1999. 408 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 409 "Per Hop Behavior Identification Codes", RFC 3140, 410 June 2001. 412 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 413 J., Courtney, W., Davari, S., Firoiu, V., and D. 414 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 415 Behavior)", RFC 3246, March 2002. 417 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 418 Protocol 4 (BGP-4)", RFC 4271, January 2006. 420 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 421 Communities Attribute", RFC 4360, February 2006. 423 7.2. Informative References 425 [I-D.knoll-idr-qos-attribute] 426 Knoll, T., "BGP Extended Community Attribute for QoS 427 Marking", draft-knoll-idr-qos-attribute-03 (work in 428 progress), January 2009. 430 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 431 and W. Weiss, "An Architecture for Differentiated 432 Services", RFC 2475, December 1998. 434 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 435 Per-Domain Behavior (PDB) for Differentiated Services", 436 RFC 3662, December 2003. 438 Author's Address 440 Thomas Martin Knoll 441 Chemnitz University of Technology 443 Email: knoll@etit.tu-chemnitz.de