idnits 2.17.1 draft-knoll-idr-cos-interconnect-00.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 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 437. 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 7, 2008) is 5772 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' == Outdated reference: A later version (-24) exists of draft-knoll-idr-qos-attribute-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 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 7, 2008 5 Expires: January 8, 2009 7 BGP Class of Service Interconnection 8 draft-knoll-idr-cos-interconnect-00 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 8, 2009. 35 Abstract 37 This document focuses on Class of Service Interconnection at inter- 38 domain peering points. It specifies two new non-transitive 39 attributes, which enable adjacent peers to signal Class of Service 40 Capabilities and certain Class of Service admission control 41 Parameters. The new "CoS Capability Attribute" is deliberately kept 42 simple and denotes the general EF, AF Group and BE forwarding support 43 across the advertising AS. The second "CoS Parameter Attribute" is 44 of variable length and contains a more detailed description of 45 available forwarding behaviours using the PHB id Code encoding. Each 46 PHB id Code is associated with rate and size based traffic 47 parameters, which will be applied in the ingress AS Border Router for 48 admission control purposes to a given forwarding behaviour. The 49 denoted Class of Service forwarding support is meant as the AS 50 externally available (transit) Class of Service support. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definition and Usage of the CoS Capability Attribute . . . . . 4 62 2.1. Extended Community Type . . . . . . . . . . . . . . . . . 4 63 2.2. Structure of the CoS Capability Attribute . . . . . . . . 4 64 2.3. Usage of the CoS Capability Attribute . . . . . . . . . . 6 65 3. Definition and Usage of the CoS Parameter Attribute . . . . . 6 66 3.1. Definition of the CoS Parameter Attribute . . . . . . . . 6 67 3.2. Usage of the CoS Parameter Attribute . . . . . . . . . . . 7 68 4. Confidentiality Considerations . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Intellectual Property and Copyright Statements . . . . . . . . . . 10 77 1. Introduction 79 AS interconnection is currently based on best effort peering only. 80 BGP-4 [RFC4271] is the de-facto peering protocol used to exchange 81 reachability information. There is no standardized set of supported 82 traffic classes, no standardized packet marking and no standardized 83 forwarding behaviour, which cross-domain traffic could rely on. QoS 84 policy decisions are taken by AS providers independently and in an 85 uncoordinated fashion. However, many AS providers make use of the 86 Differentiated Services Architecture [RFC2475] as AS internal QoS 87 mechanism. Within this architecture, there are 64 codepoints and an 88 unlimited number of Per Hop Behaviours (PHBs) possible. Some PHBs 89 have been defined in separate RFCs, which will be focused on in this 90 document. 92 A Basic Set of supported Classes, called "Basic CoS" is defined 93 inhere, which consists of the primitive "Best Effort (BE)" PHB, the 94 "Expedited Forwarding (EF)" PHB [RFC3246] and the "Assured Forwarding 95 (AF)" PHB Group [RFC2597]. AS providers, which can support this 96 Basic CoS are asked to signal this capability to their peering 97 partners by means of the new CoS Capability Attribute defined in 98 Section 2 of this draft. 100 4 AF PHB classes have been defined so far, which will be grouped into 101 the generally signalled "AF Group". That is, as long as the AS 102 provider can support at least one out of the 4 AF classes in his 103 externally supported CoS Set, this AS is regarded as AF capable. 105 A second non-transitive attribute is defined in Section 3, which is 106 used for parameter signalling about the applied access control within 107 the ingress AS Border Router. The reason for this traffic limitation 108 is the fact, that certain high quality forwarding behaviours can only 109 be achieved, if the percentage of high priority traffic within the 110 traffic mix lies below a certain threshold. This attribute informs 111 the peering partner about the applied limitation, which can in turn 112 be used to perform traffic shaping at the neighbouring AS egress. 113 The attribute allows this limitation signalling either associated to 114 the NLRI within the same UPDATE message or with "global" scope to 115 describe the generally applied ingress limitation. 117 Both attributes are likely to be used together, if ingress class 118 limitation is used for the respective AS. 120 More detailed signalling of forwarding behaviour distinction and 121 associated cross-layer marking can be achieved using the QoS Marking 122 Attribute approach [I-D.knoll-idr-qos-attribute]. 124 2. Definition and Usage of the CoS Capability Attribute 126 2.1. Extended Community Type 128 The new CoS Capability Attribute is encoded as a BGP Extended 129 Community Attribute [RFC4360]. Extended Community Attributes are 130 transitive optional BGP attribute with Type Code 16. An adoption to 131 the simple BGP Community Attribute encoding [RFC1997] is not defined 132 in this document. The actual encoding within the BGP Extended 133 Community Attribute is as follows. 135 The CoS Capability Attribute is non-transitive and of regular type 136 which results in a 1 octet Type field followed by 7 octets for the 137 CoS Capability structure. The Type is IANA-assignable (FCFS 138 procedure) and marks the community as non-transitive across ASes. 139 The type number has been assigned by IANA to 0xYY (0x40-0x7f). 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |0 1 x x x x x x| | 144 +-+-+-+-+-+-+-+-+ 7 octet CoS Capability Attribute structure | 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1 150 Note to RFC Editor: The actual type number needs to replace the '0xYY 151 (0x40-0x7f)' after the IANA assignment has occurred. 153 2.2. Structure of the CoS Capability Attribute 155 The CoS Capability Attributes structure is deliberately kept very 156 simple and is defined as follows. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |1 1 1| Currently Unused - default to '0' | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Currently Unused - default to '0'| 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 2 167 The Currently Unused bits default to '0' and must be ignored on 168 reception. 170 Leading "111" encoding. 172 This encoding signals the BE, EF and AF Group support of the 173 respective AS. The implied Per-Hop-Behaviour Identification Codes 174 follow the definition as standardized in [RFC3140]. The AF Group 175 needs to consist of at least one of the available AF1x, AF2x, AF3x 176 and AF4x. 178 BE: 179 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 180 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 181 | 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 | 182 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 184 EF: 185 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 186 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 187 | 1 0 1 1 1 0 | 0 0 0 0 0 0 0 0 0 0 | 188 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 190 AF1x: 191 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 192 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 | 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 AF2x: 197 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 | 0 1 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 AF3x: 203 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 205 | 0 1 1 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 208 AF4x: 209 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 211 | 1 0 0 0 1 0 | 0 0 0 0 0 0 0 0 1 0 | 212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 Figure 3 216 2.3. Usage of the CoS Capability Attribute 218 The CoS Capability Attribute is used as primitive means to signal the 219 general availability of the set of "Basic CoS" PHBs in the 220 advertising AS. The attribute is included within the attribute 221 section of an BGP UPDATE message and is therefore associated to the 222 NLRI information of the same message. Whether the Basic CoS is 223 available and is therefore advertised can easily being judged on for 224 all prefixes, which originate from the advertising AS. 226 All other reachability information MUST be signalled together with 227 this CoS Capability Attribute if they were received together with 228 such an Attribute by neighbouring peers. 230 NLRI MUST NOT be marked as supporting "Basic CoS" by means of the CoS 231 Capability Attribute, if it were not received together with such an 232 Attribute. 234 3. Definition and Usage of the CoS Parameter Attribute 236 3.1. Definition of the CoS Parameter Attribute 238 The CoS Parameter Attribute is an optional non-transitive BGP 239 attribute. 241 The attribute contains one or more of the following: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | PHB id Code | Flags | Reserved = '0'| 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Peak Rate | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Token Bucket Rate | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Token Bucket Size | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 4 256 PHB ID: 258 This field specifies the targeted Per Hop Behaviour limitations 259 and follows the defined encoding of [RFC3140] 261 Flags: 263 0 1 2 3 4 5 6 7 264 +--+--+--+--+--+--+--+--+ 265 |G |DR|0 |0 |0 |0 |0 |0 | 266 +--+--+--+--+--+--+--+--+ 268 Only two flags are defines. The resulting bits default to '0' and 269 must be ignored on reception. 271 The 'G' flag signals, whether the limitations have global scope on 272 all incoming traffic ('1') or are associated to traffic that is 273 destined to destinations within the NLRI of the UPDATE message 274 ('0'). NLRI specific limitation will supersede globally signalled 275 ones for traffic destined to those NLRI destinations. 277 The 'DR' flags signals the applied handling of non-confirming 278 traffic. DR='0' signals strict dropping of excess traffic. 279 DR='1' signals the performed remarking of excess traffic packets 280 to Best Effort traffic marking. 282 Peak Rate, Token Bucket Rate and Token Bucket Size: 284 The rates and sizes are given in 4 octet IEEE floating point 285 format [IEEE] . 287 3.2. Usage of the CoS Parameter Attribute 289 The signalled Parameter as used of PHB id Code based ingress 290 limitation. Depending on which PHB id Codes a BGP peer signals in 291 this attribute to its neighbour, it is said, that the respective PHB 292 id Code is supported and will experience the defined limitations. 294 Those limitations can be applied to all incoming traffic of a 295 specific PHB id Code (marked as 'G') or only for incoming traffic, 296 that is destined for the NLRI of the given UPDATE message. 298 The resulting treatment for non-confirming traffic is signalled 299 through the 'DR' flag. 301 All limitations have AS local scope for the advertising AS and the 302 peering AS might or might not adopt its sending behaviour to those 303 advertised limitations. 305 4. Confidentiality Considerations 307 The disclosure of confidential AS intrinsic information by means of 308 the signalled Basic CoS support is certainly of low key security 309 concern. The disclosure of information through CoS Parameter 310 signalling is more detailed. However, the attribute is non- 311 transitive and all included parameters are the free choice of each AS 312 provider. 314 5. IANA Considerations 316 This document defines a new BGP Extended Community Attribute, which 317 needs to be assigned a number by IANA within the Extended Community 318 Attribute list. 320 The new CoS Capability Attribute is a BGP Extended Community 321 Attribute of regular type. It is IANA-assignable (FCFS procedure) 322 and is non-transitive across ASes. 324 An number assignment application within the numbering range of 0x40- 325 0x7f is made to IANA. 327 Note to RFC Editor: this section may be removed on publication as an 328 RFC. 330 This document defines a second BGP attribute. This attribute is 331 optional and non-transitive and need to be assigned an appropriate 332 number as well. 334 6. Security Considerations 336 This extension to BGP does not change the underlying security issues 337 inherent in the existing BGP. 339 The signalled attributes are non-transitive, which limits the reach 340 of possibly applied malicious attribute modifications. AS peers, 341 which use egress traffic shaper on the signalled limitations should 342 exhaust all available BGP security features to make sure, that the 343 signalled limitation is actually sent by the adjacent peer. 345 7. References 347 7.1. Normative References 349 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point 350 Arithmetic", ISBN 1-5593-7653-8, 1985. 352 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 353 Communities Attribute", RFC 1997, August 1996. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 359 "Assured Forwarding PHB Group", RFC 2597, June 1999. 361 [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, 362 "Per Hop Behavior Identification Codes", RFC 3140, 363 June 2001. 365 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 366 J., Courtney, W., Davari, S., Firoiu, V., and D. 367 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 368 Behavior)", RFC 3246, March 2002. 370 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 371 Protocol 4 (BGP-4)", RFC 4271, January 2006. 373 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 374 Communities Attribute", RFC 4360, February 2006. 376 7.2. Informative References 378 [I-D.knoll-idr-qos-attribute] 379 Knoll, T., "BGP Extended Community Attribute for QoS 380 Marking", draft-knoll-idr-qos-attribute-01 (work in 381 progress), July 2008. 383 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 384 and W. Weiss, "An Architecture for Differentiated 385 Services", RFC 2475, December 1998. 387 Author's Address 389 Thomas Martin Knoll 390 Chemnitz University of Technology 391 Reichenhainer Str. 70 /331 392 Chemnitz, 09126 393 GERMANY 395 Phone: +49-371-531-33246 396 Fax: +49-371-531-833246 397 Email: knoll@etit.tu-chemnitz.de 399 Full Copyright Statement 401 Copyright (C) The IETF Trust (2008). 403 This document is subject to the rights, licenses and restrictions 404 contained in BCP 78, and except as set forth therein, the authors 405 retain all their rights. 407 This document and the information contained herein are provided on an 408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 410 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 411 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 412 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 415 Intellectual Property 417 The IETF takes no position regarding the validity or scope of any 418 Intellectual Property Rights or other rights that might be claimed to 419 pertain to the implementation or use of the technology described in 420 this document or the extent to which any license under such rights 421 might or might not be available; nor does it represent that it has 422 made any independent effort to identify any such rights. Information 423 on the procedures with respect to rights in RFC documents can be 424 found in BCP 78 and BCP 79. 426 Copies of IPR disclosures made to the IETF Secretariat and any 427 assurances of licenses to be made available, or the result of an 428 attempt made to obtain a general license or permission for the use of 429 such proprietary rights by implementers or users of this 430 specification can be obtained from the IETF on-line IPR repository at 431 http://www.ietf.org/ipr. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights that may cover technology that may be required to implement 436 this standard. Please address the information to the IETF at 437 ietf-ipr@ietf.org.