idnits 2.17.1 draft-ietf-idr-sla-exchange-13.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 date (January 29, 2018) is 2279 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) == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-22 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7674 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Shah 3 Internet-Draft 4 Intended status: Standards Track K. Patel 5 Expires: August 2, 2018 Arrcus, Inc 6 S. Bajaj 7 Viptela 8 L. Tomotaki 9 Verizon 10 M. Boucadair 11 Orange 12 January 29, 2018 14 Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute 15 draft-ietf-idr-sla-exchange-13.txt 17 Abstract 19 Network administrators typically enforce Quality of Service (QoS) 20 policies according to Traffic Conditioning Agreement (TCA) with their 21 providers. The enforcement of such policies often relies upon 22 vendor-specific configuration language. Both learning of TCA, either 23 thru TCA documents or via some other out-of-band method, and 24 translating them to vendor specific configuration language is a 25 complex, often manual, process and prone to errors. 27 This document specifies an optional transitive attribute to signal 28 TCA parameters in-band, across administrative boundaries (considered 29 as Autonomous Systems (AS)), thus simplifying and facilitating some 30 of the complex provisioning tasks in situations where BGP is 31 available as a routing protocol. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 2, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 5 70 3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6 71 3.2. TCA SubType . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3. TCA Content for ADVERTISE TCA Event . . . . . . . . . . . 9 73 3.3.1. Supported IPFIX identifiers for Traffic Class 74 Elements . . . . . . . . . . . . . . . . . . . . . . 12 75 3.3.2. Traffic Class Service types and respective TLVs . . . 15 76 4. Originating TCA Notification . . . . . . . . . . . . . . . . 22 77 4.1. TCA Contexts . . . . . . . . . . . . . . . . . . . . . . 23 78 4.1.1. TCA Advertisement for Point-to-Point Connection . . . 23 79 4.1.2. TCA Advertisement for Destination AS Multiple Hops 80 Away . . . . . . . . . . . . . . . . . . . . . . . . 24 81 5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 24 82 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 24 83 5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 25 84 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 85 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 25 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 91 11.2. Informative References . . . . . . . . . . . . . . . . . 30 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 94 1. Introduction 96 Typically there is a contractual Traffic Conditioning Agreement (TCA) 97 for Quality of Service (QoS) established between a customer and a 98 provider or between providers [RFC7297]. This QoS TCA defines the 99 nature of the various traffic classes and services needed within each 100 traffic class. The contract may include full line-rate or sub line- 101 rate without additional traffic classes, or it may contain additional 102 traffic classes and service definitions for those traffic classes. 103 Finer granular traffic classes may be based on some standard code 104 points (e.g., based on DSCP (Differentiated Services Code Point)) or 105 specific set of prefixes. 107 Once the contractual QoS TCA is established, QoS TCA parameters are 108 enforced in some or all participating devices by deriving those 109 parameters into configuration information on respective devices. The 110 network administrator translates the QoS TCA to QoS policies using 111 router (vendor) specific provisioning language. In a multi-vendor 112 network, translating TCAs into technology-specific and vendor- 113 specific configuration requires the network administrator to consider 114 specific configuration of each vendor. There does not exist any 115 standard protocol to translate TCA agreements into technical clauses 116 and configurations and thus both the steps of out of band learning of 117 negotiated TCA and provisioning them in a vendor specific language 118 can be complex and error-prone. 120 TCA parameters may have to be exchanged through organizational 121 boundaries, thru TCA documents or via some other off-band method, to 122 an administrator provisioning actual devices. For example, to 123 provide voice services, the provider may negotiate QoS parameters 124 (like min/max rates) for such traffic classified under the EF 125 (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475] 126 networks. The Administrator at the CE (Customer Edge) not only will 127 have to know that provider's service for voice traffic is EF-based 128 but will also have to know how to implement DSCP EF classification 129 rule along with Low Latency Service, and possibly min/max rate 130 enforcement for the optimal use of bandwidth, as per vendor specific 131 provisioning language. 133 The Inter-domain exchange of QoS TCA policy described in this 134 document does not require any specific method for the provider in 135 establishing TCAs. It only requires that the provider wishes to send 136 the QoS TCA policy via BGP UPDATE [RFC4271] messages from the 137 provider to a set of receivers (BGP peers). In reaction to, a 138 receiving router may translate that to relevant QoS policy definition 139 on the device. The TCA negotiation and assurance is outside the 140 scope of this document. 142 This document defines a new optional BGP transitive attribute, 143 referred as QoS Attribute, which has as one of its sub-types the TCA 144 policy. The BGP node of the originating AS sends this QoS Attribute, 145 for prefixes this QoS TCA Policy applies to, in a BGP UPDATE message 146 that will be distributed to a list of destination ASes. The QoS TCA 147 policy can be for inbound traffic to the advertising AS or outbound 148 traffic from the advertising AS, or both. 150 Protocols and data models are being created to standardize setting 151 routing configuration parameters within networks. YANG data models 152 [RFC6020] are being developed so that NETCONF ([RFC6241]) or RESTCONF 153 [RFC8040] can set these standardize in configuration mechanisms. For 154 ephemeral state, the I2RS protocol is being developed to set 155 ephemeral state. While these protocols provide valid configuration 156 within a domain or across domains, some providers desire to exchange 157 QoS parameters in- band utilizing BGP peering relationships. This is 158 similar to the distribution of Flow Specification information via BGP 159 peering relationships (see [RFC5575] and [RFC7674]). 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 [RFC2119]. 168 This document makes use of the following terms: 170 o BGP Speaker: A functional component on a BGP capable device that 171 functions as per BGP specification. 173 o BGP peers: BGP Speakers adjacent to each other. 175 o QoS Attribute Speaker: A functional component on a BGP capable 176 device that produces and/or processes content of the QoS 177 Attribute. A device that is QoS Attribute Speaker is also always 178 a BGP Speaker. However, a BGP Speaker not necessarily always a 179 QoS Attribute Speaker. 181 o QoS Attribute content is produced and processed outside the 182 function of the BGP Speaker and thus content of the QoS Attribute 183 is completely opaque to the BGP Speaker. At BGP capable device 184 where QoS Attribute content is produced, length and value of the 185 QoS Attribute is passed from QoS Attribute Speaker to the BGP 186 Speaker where BGP Speaker inserts the attribute into the BGP 187 UPDATE message with appropriate attribute flags, attribute type, 188 and length and value passed from the QoS Attribute Speaker. 189 Similarly, a BGP capable device when receives QoS Attribute in the 190 BGP UPDATE message, BGP Speaker extracts QoS Attribute value from 191 the message and passes it to the QoS Attribute Speaker where QoS 192 Attribute Speaker processes the content from that passed down 193 value. How the content of the QoS Attribute is passed from the 194 QoS Attribute Speaker to the BGP Speaker and vice versa is 195 implementation specific. 197 In the context of use of QoS Attribute for TCA parameters 198 exchange, following roles are defined further within the scope of 199 the QoS Attribute Speaker. 201 o TCA Producer: This is a QoS Attribute Speaker that produces QoS 202 Attribute for the TCA SubType. 204 o TCA Consumer: This is a QoS Attribute Speaker that is intended 205 receiver of QoS Attribute with the TCA SubType. 207 3. QoS Attribute Definition 209 The QoS Attribute is an optional transitive attribute (TBD - 210 attribute code to be assigned by IANA) which is applicable to the 211 Source AS and NLRIs advertised in the BGP UPDATE message this 212 attribute is included in. The format of the QoS Attribute is shown 213 in Figure 1. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Attr flag | Attr type QoS | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 220 ~ ~ 221 | QoS Attr length/value | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 224 Figure 1: QoS attribute 226 Attribute flags - 8-bits field 228 highest order bit (bit 0) - MUST be set to 1, since this is an 229 optional attribute 231 2nd higher order bit (bit 1) - MUST be set to 1, since this is a 232 transitive attribute 234 The content of the QoS Attribute is further specified with flags, 235 applicable to QoS Attribute content, and a SubType in a TLV form. 237 3.1. QoS Attribute SubType 239 The Value field of the QoS Attribute contains the following: 241 QoS Attribute flags 243 Tuple (SubType of the QoS Attribute, SubType length, SubType 244 value) 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | QoS Attr flags| SubType | SubType length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 ~ ~ 252 | SubType value | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+ 255 Figure 2: Format of QoS Attribute 257 QoS Attr flags - 8-bits field 259 All bits of this field are currently un-used. The space is 260 provided for future use. All bits MUST be set to zero when sent. 261 The values (0x01-0xFF) are reserved, and MUST be ignored when 262 received. 264 SubType - 8-bits field with following values: 266 0x00 = reserved 268 0x01 = TCA 270 0x02 - 0xf0 = reserved for future use (Standards Action) 272 0xf1 - 0xff = Private use 274 The only SubType of the QoS Attribute defined in this 275 specification is the TCA SubType. 277 SubType length - 16-bits field that specifies length of the SubType 278 value in number of octets. 280 SubType value - variable length field, as expressed in SubType 281 length, that contains information about a specified SubType. For 282 the TCA SubType the information is about sender and receiver(s), 283 and TCA parameters as described in Section 3.2. 285 3.2. TCA SubType 287 Format of the TCA SubType Value field is shown in Figure 3. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | TCA SubType flags | Destination AS count | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Source AS (Advertiser) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | variable list of Destination AS | 297 ~ .... ~ 298 | .... | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |TCAEvnt| TCA ID | TCA length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | TCA Content for TCA Event | 303 ~ ~ 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 3: Format of the TCA SubType of the QoS attribute 309 TCA SubType flags - 16-bits field 311 Currently un-used. All bits in this field MUST be set to 0. The 312 field is defined for the future use. 314 Destination AS count - 16-bits field that specifies count of 315 destination ASNs present in the Destination AS list. 317 If this count is 0 then that is an error condition which should be 318 handled as described in Section 6. 320 Source AS - 32-bits field AS number space as defined in [RFC6793] 322 This is the AS where TCA Content is originated from. The Source 323 AS MUST be of the same AS that is originating TCA ID and TCA 324 Content. 326 The Source AS value of 0 is illegal and thus should be considered 327 an error which should be handled as described in Section 6. 329 Destination AS list - variable length field that holds as many ASN. 330 identifiers, each is 32-bits AS number space is defined in 331 [RFC6793], as specified in the Destination AS count field. 333 List of ASNs for which the TCA is relevant to, each of which is a 334 32-bit number. 336 TCA Event - 4-bits field with following values: 338 0x0 = reserved 340 0x1 = ADVERTISE 342 0x2 to 0xf = Reserved for future use 344 The only TCA Event defined in this specification is ADVERTISE. 346 TCA ID - 16-bits field that specifies identifier which is unique in 347 the scope of Source AS. 349 The significance of a TCA ID is in the context of the source that 350 is advertising TCA Content. The TCA ID is not globally unique but 351 it MUST be unique within the source AS. 353 The TCA ID applies to aggregate traffic to prefixes for a given 354 AFI/SAFI that share the same Source AS and TCA ID. 356 TCA Length - 12-bits field that specifies the length of the TCA 357 Content. The length is expressed in octets. The TCA Content is 358 optional for an advertised TCA ID. If the TCA Content need not be 359 there, the TCA length field MUST be set to zero in such a case. 361 TCA Content - A variable length field (optional field) 363 The TCA Content field contains TCA parameters relevant to 364 specified TCA SubType. Since the only defined TCA SubType is 365 ADVERTISE, this specification describes TCA Content only for the 366 ADVERTISE TCA Event. 368 If TCA Content field exists in a BGP UPDATE message that contains 369 the QoS Attribute with a TCA SubType for TCA Event ADVERTISE, 370 format of the TCA Content is as described in Section 3.3. 372 If the TCA Content field does not exist, then the advertised 373 message refers to TCA Content advertised in the previous message 374 for the same TCA ID. If there does not exist any prior TCA 375 Content to relate to the advertised TCA ID, then receiver, TCA 376 Consumer, can ignore the TCA advertisement and it may simply 377 update Destination AS count and Destination AS list. 379 The lack of a valid prior TCA Content field does not make this 380 attribute invalid, so the QoS Attribute MUST be forwarded as a 381 valid BGP optional transitive attribute. 383 3.3. TCA Content for ADVERTISE TCA Event 385 The only TCA Event described in this specification is ADVERTISE. The 386 format of TCA Content for the ADVERTISE Event is shown in Figure 4. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |dir| Traffic Class count | Class Desc Len| | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 393 | | 394 ~ Traffic Class Description ~ 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Element Count | | 398 +-+-+-+-+-+-+-+-+ ~ 399 | | 400 ~ Traffic Class Element TLVs ~ 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Service Count| | 404 +-+-+-+-+-+-+-+-+ ~ 405 | Traffic Class Service TLVs | 406 ~ ~ 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 ~ Repeat from Traffic Class Description for next Traffic Class ~ 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 ~ Repeat from direction for TCA in the other direction ~ 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 4: TCA-Content for ADVERTISE TCA Event 420 TCA Content contains Traffic Class TLVs that is a set of Traffic 421 Class Elements (Classifiers) and Traffic Class Service TLVs for a 422 list of Traffic Classes specified by Traffic Class count. This 423 Traffic Class TLVs MUST be specified for one direction first and then 424 optionally followed by the specification for the other direction. 426 dir (Direction) - 2-bits field that specifies Direction of the 427 traffic TCA is applicable to. The following values are defined: 429 0x0 = reserved 431 0x1 = incoming, traffic to source AS from destination AS 433 0x2 = outgoing, traffic from source AS towards destination AS 435 0x3 = for future use 437 Traffic Class (Classifier Group) count - 16 bits field that 438 specifies number of Traffic Classes. 440 The value of zero (0x00) in this field is a special value which 441 means no TCA for the traffic in a specified direction. When 442 Traffic Class count is 0, for a specific direction, the rest of 443 the TCA Content fields MUST NOT be encoded, for that specific 444 direction. 446 Traffic Class Description Len - 8-bits field that specifies the 447 length of the Traffic Class Description field. The length is 448 expressed in octets. 450 The value of zero in this field indicates that no Traffic Class 451 Description field follows. 453 Traffic Class Description - variable length field, as expressed in 454 The Traffic Class Description Len field, MUST carry UTF-8 encoded 455 ([RFC3629]) description. 457 Traffic Class Elements (Classifier) Count - 8-bits field that 458 specifies the count of Traffic Class Elements. 460 The value zero (0x00) means there are no Traffic Class Elements in 461 the traffic class, and thus the Traffic Class is to classify rest 462 of the traffic not captured otherwise by other Traffic Classes in 463 the set for a specified direction. 465 Traffic Class that has 0 elements MUST be presented last in the 466 advertised list of Traffic Classes for a specific Direction. 468 Otherwise it is considered an error condition which should be 469 handled as described in Section 6. 471 The QoS Attribute advertised from a specific source MUST NOT have 472 more than one such Traffic Classes (Traffic Class with 0 elements 473 count). If there are more than one such Traffic Classes present 474 then it is an error condition which should be handled as described 475 in Section 6. 477 Traffic Class Element TLVs - (optional) variable length field 478 holding as many TLVs specified by the Traffic Class Elements Count 479 field. Each TLV has the following format: 481 IPFIX Element Identifier - 8-bits field that specifies IPFIX 482 Identifiers listed in Table 1. 484 Length of Value field - 8-bits field that specifies the length, 485 expressed in octets, of the value field. 487 Value - A variable field that specifies a value appropriate for 488 the IPFIX Element Identifier. It is an error, if the value field 489 does not contain the appropriate format, which should be handled 490 as described in Section 6. Only the IPFIX elements shown in 491 Table 1 are supported. 493 Any Traffic Class Element advertised in the QoS Attribute only 494 applies to the advertised AFI/SAFI NLRI within the BGP UPDATE 495 message the QoS Attribute is contained in. If a receiver, TCA 496 Consumer, receives a BGP UPDATE message with QoS Attribute for an 497 unsupported AFI/SAFI then TCA Consumer MAY ignore advertised TCA. 498 TCA Consumer MAY update only Destination AS count and Destination 499 AS list, and then QoS Attribute and rest of the BGP UPDATE message 500 MUST be forwarded as per QoS Attribute and BGP protocol 501 specification. 503 Traffic Class Service Count - 8-bits field that specifies count of 504 Traffic Class Service TLVs. 506 A value of zero is a special value indicating "no bounded service" 507 (a.k.a., Best Effort (BE)). 509 Traffic Class Service TLVs - (optional) variable length field with 510 the following format for the TLVs 512 Traffic Class Service type - 16-bits field that specifies a 513 service type. Each service type is detailed in Section 3.3.2. 514 The list of available service types are, 515 0x00 = reserved 517 0x01 = COMMITTED_TSPEC 519 0x02 = PEAK_TSPEC 521 0x03 = COMMITTED_IN_PROFILE_MARKING 523 0x04 = COMMITTED_OUT_PROFILE_MARKING 525 0x05 = PEAK_OUT_PROFILE_MARKING 527 0x06 = DROP_THRESHOLD 529 0x07 = RELATIVE_PRIORITY 531 0x08 = EFFECTIVE_MAX_RATE 533 Length of Value field - 08-bits field that specifies the length of 534 the value field. The length of the value is expressed in octets. 536 Value - a variable length field that specifies the value 537 appropriate for each of the Service Types. It is an error, if 538 this field does not contain the appropriate format, which should 539 be handled as described in Section 6. The format of the value for 540 each of the service types is described in Section 3.3.2 542 3.3.1. Supported IPFIX identifiers for Traffic Class Elements 544 IPFIX [RFC7012] has well defined identifier set for a large number of 545 packet attributes; an IPFIX IANA registry maintains values for packet 546 classifier attributes ( ipfix.xml#ipfix-information- 548 elements). Only the IPFIX attributes listed in Table 1 are 549 supported. Any new attribute to be supported by TCA SubType MUST be 550 a Standards Action as described in IANA section. 552 +-----+-----------------------------+-------------------------------+ 553 | ID | Name | Context | 554 +-----+-----------------------------+-------------------------------+ 555 | 195 | ipDiffServCodePoint | Indicates the value of the | 556 | | | marking used in the link(s) | 557 | | | between the TCA Consumer and | 558 | | | TCA Producer domains. | 559 +-----+-----------------------------+-------------------------------+ 560 | 203 | mplsTopLabelExp | Indicates the value of the | 561 | | | marking used in the link(s) | 562 | | | between the TCA Consumer and | 563 | | | TCA Producer domains. | 564 +-----+-----------------------------+-------------------------------+ 565 | 244 | dot1qPriority | Indicates the value of the | 566 | | | marking used in the link(s) | 567 | | | between the TCA Consumer and | 568 | | | TCA Producer domains. | 569 +-----+-----------------------------+-------------------------------+ 570 | 8 | sourceIPv4Address | Indicates the source IPv4 | 571 | | | address of an aggregate | 572 | | | traffic over a connection | 573 | | | subject to a TCA; the | 574 | | | direction is being explicitly | 575 | | | indicated in the ADVERTISE | 576 | | | Event message. | 577 +-----+-----------------------------+-------------------------------+ 578 | 27 | sourceIPv6Address | Indicates the source IPv6 | 579 | | | address of an aggregate | 580 | | | traffic over a connection | 581 | | | subject to a TCA; the | 582 | | | direction is being explicitly | 583 | | | indicated in the ADVERTISE | 584 | | | Event message. | 585 +-----+-----------------------------+-------------------------------+ 586 | 9 | sourceIPv4PrefixLength | Indicates the length of the | 587 | | | source IPv4 prefix. | 588 +-----+-----------------------------+-------------------------------+ 589 | 29 | sourceIPv6PrefixLength | Indicates the length of the | 590 | | | source IPv6 prefix. | 591 +-----+-----------------------------+-------------------------------+ 592 | 44 | sourceIPv4Prefix | Indicates the source IPv4 | 593 | | | prefix of an aggregate | 594 | | | traffic over a connection | 595 | | | subject to a TCA; the | 596 | | | direction is being explicitly | 597 | | | indicated in the ADVERTISE | 598 | | | Event message. | 599 +-----+-----------------------------+-------------------------------+ 600 | 170 | sourceIPv6Prefix | Indicates the source IPv6 | 601 | | | prefix of an aggregate | 602 | | | traffic over a connection | 603 | | | subject to a TCA; the | 604 | | | direction is being explicitly | 605 | | | indicated in the ADVERTISE | 606 | | | Event message. | 607 +-----+-----------------------------+-------------------------------+ 608 | 12 | destinationIPv4Address | Indicates the destination | 609 | | | IPv4 address of an aggregate | 610 | | | traffic over a connection | 611 | | | subject to a TCA; the | 612 | | | direction is being explicitly | 613 | | | indicated in the ADVERTISE | 614 | | | Event message. | 615 +-----+-----------------------------+-------------------------------+ 616 | 28 | destinationIPv6Address | Indicates the destination | 617 | | | IPv6 address of an aggregate | 618 | | | traffic over a connection | 619 | | | subject to a TCA; the | 620 | | | direction is being explicitly | 621 | | | indicated in the ADVERTISE | 622 | | | Event message. | 623 +-----+-----------------------------+-------------------------------+ 624 | 13 | destinationIPv4PrefixLength | Indicates the length of the | 625 | | | destination IPv4 prefix. | 626 +-----+-----------------------------+-------------------------------+ 627 | 30 | destinationIPv6PrefixLength | Indicates the length of the | 628 | | | destination IPv6 prefix. | 629 +-----+-----------------------------+-------------------------------+ 630 | 45 | destinationIPv4Prefix | Indicates the destination | 631 | | | IPv4 prefix of an aggregate | 632 | | | traffic over a connection | 633 | | | subject to a TCA; the | 634 | | | direction is being explicitly | 635 | | | indicated in the ADVERTISE | 636 | | | Event message. | 637 +-----+-----------------------------+-------------------------------+ 638 | 169 | destinationIPv6Prefix | Indicates the destination | 639 | | | IPv6 prefix of an aggregate | 640 | | | traffic over a connection | 641 | | | subject to a TCA; the | 642 | | | direction is being explicitly | 643 | | | indicated in the ADVERTISE | 644 | | | Event message. | 645 +-----+-----------------------------+-------------------------------+ 646 | 4 | protocolIdentifier | Indicates whether any or a | 647 | | | specific protocol for the | 648 | | | traffic class. | 649 +-----+-----------------------------+-------------------------------+ 650 | 7 | sourceTransportPort | This parameter is used only | 651 | | | for protocols with port | 652 | | | identifiers. It indicates the | 653 | | | source port number for the | 654 | | | transport protocol identified | 655 | | | by "protocolIdentifier". | 656 +-----+-----------------------------+-------------------------------+ 657 | 11 | destinationTransportPort | This parameter is used only | 658 | | | for protocols with port | 659 | | | identifiers. It indicates the | 660 | | | destination port number for | 661 | | | the transport protocol | 662 | | | identified by | 663 | | | "protocolIdentifier". | 664 +-----+-----------------------------+-------------------------------+ 666 Table 1 668 3.3.2. Traffic Class Service types and respective TLVs 670 3.3.2.1. COMMITTED_TSPEC 672 The COMMITTED_TSPEC TLV definition: 674 Type - 0x01 676 Length - 8-bits field that specifies length, expressed in octets, 677 of the value field. The length of the value field MUST be 678 specified to be 8 octets to hold the value defined as per format 679 below. 681 Value - COMMITTED_TSPEC value consists of the (r), (b) parameters 682 as described in Invocation Information section of [RFC2212] and 683 shown in Figure 5. Note that inheriting the definition of TSPEC 684 (Traffic SPECification) here does not enable RFC2212 685 functionality. Only the format of the Traffic Specification is 686 used in this specification. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Rate (r) (32-bit IEEE floating point number) | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Burst Size (b) (32-bit IEEE floating point number) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure 5: Traffic Class COMMITTED_TSPEC 698 Format of Parameters (r) and (b): are 32-bit IEEE floating point 699 numbers. Positive infinity is represented as an IEEE single 700 precision floating-point number with an exponent of all ones and a 701 sign mantissa of all zeros. The format of IEEE floating-point 702 numbers is further summarized in [RFC4506]. 704 Parameter (r): indicates committed-rate of the traffic class. This 705 rate indicates the minimum rate, measured in octets of IP 706 datagrams per second (a.k.a, bytes per second), that the service 707 advertiser is providing for a given class of traffic on 708 advertiser's hop. Note that it does not necessarily translate to 709 a minimum rate service to the receiver of a TCA unless the traffic 710 class definition clearly represents a sole receiver of a TCA. 712 Parameter (b): indicates maximum burst size, measured in octets of 713 IP datagram size. Since queuing delay can be considered a 714 function of burst size (b) and committed-rate (r), in presence of 715 non-zero parameter (r), parameter (b) represents bounded delay for 716 the Traffic Class. This delay is a single hop queuing delay when 717 TCA is to be implemented at the resource constrained bottleneck. 718 In other words this burst size can be considered as a buffer size. 719 Value of 0 for parameter (b) means the advertiser does not mandate 720 specific bounded delay. 722 3.3.2.2. PEAK_TSPEC 724 The PEAK_TSPEC TLV definition: 726 Type - 0x01 728 Length - 8-bits field that specifies length, expressed in octets, 729 of the value field. The length of the value field MUST be 730 specified to be 8 octets to hold the value defined as per format 731 below. 733 Value - PEAK_TSPEC value consists of the (r), (b) parameters as 734 described in Invocation Information section of [RFC2212] and shown 735 in Figure 5. Note that inheriting the definition of TSPEC 736 (Traffic SPECification) here does not enable RFC2212 737 functionality. Only the format of the Traffic Specification is 738 used in this specification. 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Rate (r) (32-bit IEEE floating point number) | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Burst Size (b) (32-bit IEEE floating point number) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 Figure 6: Traffic Class PEAK_TSPEC 750 Format of Parameters (r) and (b): are 32-bit IEEE floating point 751 numbers. Positive infinity is represented as an IEEE single 752 precision floating-point number with an exponent of all ones and a 753 sign mantissa of all zeros. The format of IEEE floating-point 754 numbers is further summarized in [RFC4506]. 756 Parameter (r): indicates peak-rate of the traffic class. This rate 757 indicates the maximum rate, measured in octets of IP datagrams per 758 second (a.k.a, bytes per second), that the service advertiser is 759 providing for a given class of traffic on advertiser's hop. 761 Parameter (b): indicates maximum burst size, measured in octets of 762 IP datagram size. 764 When PEAK_TSPEC TLV is advertised, COMMITTED_TSPEC TLV MUST be 765 present in the advertisement. Advertisement of PEAK_TSPEC TLV 766 without COMMITTED_TSPEC TLV MUST be considered an error condition 767 which should be handled as described in Section 6. If committed-rate 768 of the TCA is 0 then rate advertised in the COMMITTED_TSPEC shall be 769 0. Note that existence of COMMITTED_TSPEC in TCA advertisement is 770 not mandatory nor is it a mandate that COMMITTED_TSPEC and PEAK_TSPEC 771 must always go together. COMMITTED_TSPEC TLV is optional but only 772 when there is no PEAK_TSPEC TLV present in the advertised TCA. 774 PEAK_TSPEC TLV with rate value of 0 MUST be considered an error 775 condition which should be handled as described in Section 6. 777 3.3.2.3. COMMITTED_IN_PROFILE_MARKING 779 This Traffic Class Service Type defines action performed, by the TCA 780 Producer, on packets that are compliant to the committed-rate 781 specified in the COMMITTED_TSPEC TLV. If committed-rate specified in 782 the COMMITTED_TSPEC TLV is 0 then TLV for this Traffic Class Service 783 Type SHOULD NOT be advertised. COMMITTED_IN_PROFILE_MARKING TLV 784 SHOULD be ignored by the TCA Consumer if there does not exist 785 COMMITTED_TSPEC TLV for the specified direction, or committed-rate 786 specified in the COMMITTED_TSPEC TLV is 0. 788 The COMMITTED_IN_PROFILE_MARKING TLV definition: 790 Type - 0x03 792 Length - 8-bits field that specifies length, expressed in octets, 793 of the value field. The length of the value field MUST be 794 specified to be 2 octets to hold the value defined as per format 795 below. 797 Value - contains the Marking code-point type and value 798 Marking code-point type - 8-bits IPFIX Element Identifier. 800 Marking code-point value - 8-bits code-point number. 802 The marking code-point type of 0x00 is a drop identifier. When 803 marking code-point type value is 0x00 (that is drop), the marking 804 code-point value in this case has no meaning and thus the value in 805 this field should be ignored. 807 The following table lists the supported IPFIX Identifiers. Any value 808 other than 0 or identifier from the following table is an error 809 condition which should be handled as described in Section 6. 811 +-----+---------------------+ 812 | ID | Name | 813 +-----+---------------------+ 814 | 195 | ipDiffServCodePoint | 815 | 203 | mplsTopLabelExp | 816 | 244 | dot1qPriority | 817 +-----+---------------------+ 819 Table 2 821 3.3.2.4. COMMITTED_OUT_PROFILE_MARKING 823 This Traffic Class Service Type defines action performed, at the TCA 824 Producer, on packets that are not compliant to the committed-rate 825 specified in the COMMITTED_TSPEC TLV, and compliant to rate specified 826 in the PEAK_TSPEC TLV if PEAK_TSPEC TLV exists. 828 The COMMITTED_OUT_PROFILE_MARKING TLV definition: 830 Type - 0x04 832 Length - 8-bits field that specifies length, expressed in octets, 833 of the value field. The length of the value field MUST be 834 specified to be 2 octets to hold the value defined as per format 835 below. 837 Value - contains the Marking code-point type and value 839 Marking code-point type - 8-bits IPFIX Element Identifier 841 Marking code-point value - 8-bits code-point number 843 The marking code-point type of 0x00 is a drop identifier. When 844 marking code-point type value is 0x00 (that is drop), the marking 845 code-point value in this case has no meaning and thus the value in 846 this field should be ignored. 848 Table 2 lists the supported IPFIX Identifiers. Any value other than 849 0 or identifier from the Table 2 is an error condition which should 850 be handled as described in Section 6. 852 3.3.2.5. PEAK_OUT_PROFILE_MARKING 854 This Traffic Class Service Type defines action performed, at the TCA 855 Producer, on packets that are not compliant to the max-rate specified 856 in the PEAK_TSPEC TLV. PEAK_OUT_PROFILE_MARKING TLV SHOULD be 857 ignored by the TCA Consumer if there does not exist PEAK_TSPEC TLV 858 for the specified direction. 860 The PEAK_OUT_PROFILE_MARKING TLV definition: 862 Type - 0x06 864 Length - 8-bits field that specifies length, expressed in octets, 865 of the value field. The length of the value field MUST be 866 specified to be 2 octets to hold the value defined as per format 867 below. 869 Value - contains the Marking code-point type and value 871 Marking code-point type - 8-bits IPFIX Element Identifier 873 Marking code-point value - 8-bits code-point number 875 The marking code-point type of 0x00 is a drop identifier. When 876 marking code-point type value is 0x00 (that is drop), the marking 877 code-point value in this case has no meaning and thus the value in 878 this field should be ignored. 880 Table 2 lists the supported IPFIX Identifiers. Any value other than 881 0 or identifier from the Table 2 is an error condition which should 882 be handled as described in Section 6. 884 3.3.2.6. DROP_THRESHOLD 886 The DROP_THRESHOLD TLV definition: 888 Type - 0x07 890 Length - 8-bits field that specifies length, expressed in octets, 891 of the value field. 893 Value - Count of drop thresholds, followed by content for each 894 drop threshold in the form of (code-point type, count of code- 895 points, list of code-points, threshold value). 897 Count of drop thresholds - 8-bits field that specifies number of 898 drop thresholds specified in this TLV. Content of each drop 899 threshold is to follow following format 901 Code-point type - 8-bits IPFIX Element Identifier from the list 902 shown in Table 6. 904 Count of code-points - 8-bits field that specifies number of code- 905 point values to follow for a specified code-point type. 907 List of code-points - each code-point value is specified in size 908 of 8 bits and thus total size for this field is 8 bits multiplied 909 by as many number of code-points specified. 911 Burst value - This is a fixed size 32-bits IEEE floating point 912 number that specifies burst value in unit of bytes. 914 All advertised drop thresholds, for a specific traffic class, are 915 applicable to a single queue associated with that traffic class. A 916 threshold for a set of code-points is a logical marker where an 917 arrived packet is to be dropped if overall depth of a queue is beyond 918 a threshold of a code-point set a packet is classified into. Choice 919 of dropping discipline is implementation specific. If a packet can 920 not be classified into any of the advertised code-point set then that 921 means the TCA Producer is not defining any specific dropping behavior 922 and thus dropping behavior is subject to implementation specific of 923 the TCA Consumer. 925 +-----+---------------------+ 926 | ID | Name | 927 +-----+---------------------+ 928 | 195 | ipDiffServCodePoint | 929 | 203 | mplsTopLabelExp | 930 | 244 | dot1qPriority | 931 +-----+---------------------+ 933 Table 3 935 3.3.2.7. RELATIVE_PRIORITY 937 The RELATIVE_PRIORITY TLV definition: 939 Type - 0x08 941 Length - 8-bits field that specifies length, expressed in octets, 942 of the value field. Given supported range of priority values in 943 this specification, the length of the value field MUST be limited 944 to and thus MUST be specified exactly as 1 octet. 946 Value - A value from range of 0 - 255. Lower the value means 947 higher the priority 949 Relative priority indicates scheduling priority of this traffic 950 class. Voice traffic, for example, which requires lowest latency 951 compared to any other traffic, may have lowest value advertised in 952 relative priority. For two different traffic classification groups 953 where one classification group may be considered more important than 954 the other, but from a scheduling perspective does not require to be 955 distinguished with a different priority, relative priority for those 956 classification groups should be advertised with the same value. 958 A higher priority class of traffic to be served without pre-empted by 959 lower priority class of traffic for more than a packet time at the 960 configured rate. 962 For a system that implements WRR only (i.e., no priority queuing), it 963 is possible to use a hierarchical WRR scheduling to achieve a 964 behavior close to priority queueing where a root scheduling node has 965 two child nodes. One child node is a queue assigned with a maximum 966 possible value of a weight and advertised rate of highest priority 967 Traffic Class as output bandwidth. The other child node is a 968 scheduling node serving group of rest other advertised Traffic 969 Classes (in the form of queues or yet another level of hierarchical 970 WRR scheduler). Note that implementation specifics are out of the 971 scope of this specification and this is an example to highlight how 972 relative priority attribute can be relevant and treated by a system 973 that implements only WRR. A system may choose to implement alternate 974 methods to achieve a similar behavior. 976 3.3.2.8. EFFECTIVE_MAX_RATE 978 The EFFECTIVE_MAX_RATE TLV definition: 980 Type - 0x02 981 Length - 8-bits field that specifies length, expressed in octets, 982 of the value field. The length of the value field MUST be 983 specified to be 5 octets to hold the value defined as per format 984 below. 986 Value - Contains value of rate and per packet overhead 988 Aggregate max rate - 32-bits IEEE floating point number 990 Per packet overhead - 8-bits specifying value of overhead 991 octets 993 Aggregate max rate indicates rate measured based on combined octets 994 of packet's IP datagram size and advertised per packet overhead. 996 A packet traversing from the TCA Producer to the TCA Consumer or 997 vice-versa may see packet overhead, additional octets on top of IP 998 datagram size, difference between the Producer and the Consumer sent 999 or received over a physical link. In cases, where advertised TCA is 1000 for a Consumer where total traffic between Consumer and Producer is 1001 to be capped to a specific sub-rate of a physical link, due to packet 1002 overhead differences between Producer and Consumer, sum of traffic 1003 from each TRAFFIC CLASS may overrun that total cap causing undesired 1004 behavior. In such cases, Producer can explicitly notify this TLV in 1005 advertised TCA. 1007 4. Originating TCA Notification 1009 The QoS Attribute for the TCA SubType MUST only be added to the BGP 1010 UPDATE message at the node that is TCA Producer. Any QoS Attribute 1011 Speaker, in the path to the TCA Consumer MUST NOT modify content of 1012 that attribute except modification of the Destination AS list. 1014 QoS Attribute with the TCA SubType SHOULD NOT be advertised 1015 periodically just for the purpose of KEEPALIVE between TCA Producer 1016 and TCA Consumer. Some sort of TCA policy change, at the TCA 1017 Producer, may be considered as a trigger for the advertisement. 1019 For any modified TCA policy at the TCA Producer, the TCA Producer 1020 MUST re-advertise the entire set of TCA parameters. There is no 1021 provision to advertise partial set of TCA parameters. Announcing a 1022 TCA ID different from an earlier advertised one, for the same prefix 1023 and from the same Source AS, indicates Source AS is advertising new 1024 TCA Content to replace the previous one advertised with the same TCA 1025 ID. 1027 In order to withdraw a given TCA between TCA Producer and TCA 1028 Consumer, the TCA Produced MUST sent TCA Content with the same TCA 1029 ID, AS Source, and NLRI prefix, as were used to advertise earlier TCA 1030 parameters, and the Traffic Class count MUST be set to 0. 1032 4.1. TCA Contexts 1034 4.1.1. TCA Advertisement for Point-to-Point Connection 1036 In certain cases, the advertisement of a TCA is intended to relate to 1037 aggregate traffic over a point-to-point connection between a specific 1038 destination and a specific source. A point-to-point connection may 1039 be a physical link or a virtual link (e.g. a tunnel). In such cases, 1040 a BGP UPDATE message with source AS number and NLRI prefix as an IP 1041 address of a TCA Producer can uniquely identify physical/virtual link 1042 in order to establish the context for the advertised TCA for that 1043 point to point link. 1045 In the simplest case where Provider (e.g., PE) and Customer (e.g., 1046 CE) devices are directly connected via a physical link and have only 1047 a single link between them, the CE can uniquely identify the 1048 forwarding link to the PE with the following: 1050 o AS number of the PE, 1052 o NLRI prefix being an IP address of the PE, that is the next hop 1053 address from CE to PE. 1055 The TCA advertised in the QoS Attribute in the BGP UPDATE message 1056 sent from the PE to a CE, along with the PE's AS number and PE's IP 1057 address, establishes TCA context for the aggregate traffic through 1058 CE-to-PE link. 1060 The TCA advertised in the QoS Attribute in the BGP UPDATE message 1061 from PE to CE, with PE's AS number and any other prefix, means TCA 1062 for that specific prefix based traffic, a subset of traffic through 1063 CE-to-PE link. 1065 Even though this example is in the context of IP prefixes, QoS 1066 Attribute's TCA exchange does not have to be limited to the IP 1067 address family (IPv4 and IPv6). TCA advertisement is generic to all 1068 forms of NLRI types that are supported by the BGP specification (like 1069 IPv4, IPv6, VPN-IPv4, VPN-IPv6). 1071 When BGP UPDATE message with the QoS Attribute, containing TCA 1072 SubType, is triggered for a point-to-point connection (physical or 1073 logical), the Source AS number in the TCA SubType SHOULD be set to 1074 TCA Producer's AS number and destination AS number SHOULD be set to 1075 AS number of BGP peer's that is targeted TCA Consumer. 1077 4.1.2. TCA Advertisement for Destination AS Multiple Hops Away 1079 When advertised TCA is not for the BGP peer of a TCA Producer, the 1080 Source AS field, in the TCA SubType, MUST be set. The list of 1081 destination AS(es) also MUST be set, in the TCA SubType, to avoid 1082 flooding of the QoS Attribute data in the network beyond those 1083 destinations. Destination AS(es) is a list of TCA Consumers the 1084 advertised TCA is intended for. 1086 If a new prefix is learned and traffic with this new prefix is 1087 subject to TCA parameters that have already been advertised before 1088 for other existing prefixes, then the BGP UPDATE for this new prefix 1089 MAY include QoS Attribute containing just a TCA ID that was 1090 advertised earlier. This BGP UPDATE message does not require to have 1091 the whole TCA Content. The TCA ID is sufficient to relate TCA 1092 parameters to new advertised prefixes. 1094 5. QoS Attribute Handling at Forwarding Nodes 1096 The propagation of the QoS Attribute in the BGP UPDATE messages 1097 depends on the rules detailed in the following sub-sections. 1099 5.1. BGP Node Capable of Processing QoS Attribute 1101 If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS 1102 Attribute. If BGP UPDATE message has a QoS Attribute with a list of 1103 destination ASes, QoS Attribute Speaker MAY trim the list and adjust 1104 the count of the destination AS to exclude ones that are not required 1105 in further announcement of BGP UPDATE messages. 1107 A QoS Attribute Speaker MUST drop TCA SubType from the QoS Attribute, 1108 if there are no more ASes left in the QoS Attribute's destination 1109 list. The rest of the QoS Attribute contents may be forwarded if 1110 there exist other SubTypes of QoS Attribute and forwarding rules meet 1111 other SubTypes requirements. If there is no other SubTypes in that 1112 QoS Attribute content then QoS Attribute Speaker MUST drop the entire 1113 QoS Attribute all together. BGP Speaker MAY announce further other 1114 attributes and NLRI information, if they meet rules defined by other 1115 attributes and BGP specification. 1117 Except extracting the entire TCA SubType of the QoS Attribute and 1118 trimming the list of Destination AS list, all other content MUST NOT 1119 be modified by any QoS Attribute Speaker or BGP Speaker in the path 1120 of a BGP UPDATE message. 1122 5.2. QoS Attribute Handling at Receiver 1124 Once QoS Attribute with the TCA SubType is received at intended 1125 receiver (TCA Consumer) , processing of advertised TCA Content is 1126 optional for the TCA Consumer. TCA Consumer MAY just trim the 1127 Destination AS list as per rules described in this specification, 1128 without processing any other content of the Attribute. If Receiver 1129 chooses to process advertised TCA content, it may encounter errors 1130 beyond the ones described in this document, errors like 1131 unavailability of resources if Receiver chooses to implement policies 1132 for advertised TCA. In such a case Receiver MAY simply log a 1133 message. QoS attribute still MUST be forwarded as per rules defined 1134 in this document and rest of the BGP UPDATE message MUST be processed 1135 as per BGP specification. If intended receiver is not a QoS 1136 Attribute Speaker than BGP Speaker MUST forward this attribute 1137 without any change if rest of the BGP UPDATE message also meets 1138 forwarding rules as per BGP specification. 1140 When BGP UPDATE messages are triggered only as a result of TCA policy 1141 change, propagating BGP UPDATE message beyond intended TCA Consumers 1142 is not necessary. If the TCA Consumer device implementations are 1143 capable of policy based filtering, it may implement a policy to 1144 filter such BGP UPDATE messages based on prefixes and QoS Attribute 1145 containing TCA SubType. 1147 6. Error Handling 1149 Error conditions, while processing of the QoS Attribute content, MUST 1150 be handled with the approach of attribute discard as described in 1151 [RFC7606]. Processing of QoS Attribute content is done by QoS 1152 Attribute Speaker and thus in case of errors, resulting in attribute 1153 discard, QoS Attribute Speaker SHOULD convey such indication to the 1154 BGP Speaker and rest of the BGP message SHOULD be processed by the 1155 BGP Speaker as per BGP specification. 1157 7. Deployment Considerations 1159 One of the use cases is for a provider to advertise contracted TCA 1160 parameters to a Customer Edge (CE) in cases where eBGP is deployed 1161 between PE and CE. The TCA parameters may already be provisioned by 1162 the provider on the PE device (facing CE). This provisioned TCA 1163 parameters are then advertised thru proposed QoS Attribute to the CE 1164 device. The CE device may read the QoS Attribute and TCA SubType 1165 content to implement the QoS policy on the device. 1167 Contracted TCA from PE to CE may be full line-rate or sub line-rate 1168 or finer granular controlled services. The advertised TCA can be 1169 useful when contracted service is sub-rate of a link and/or when for 1170 finer granular traffic classes that are controlled (e.g. voice, video 1171 services may be capped to certain rate). 1173 _______________ 1174 __________ / \ 1175 / \ / \ 1176 / \ / \ 1177 |CustomerSite|-----| Provider | 1178 \ C/E P\E / 1179 \__________/ \ / 1180 \_______________/ 1181 AS 3 AS 2 1183 TCA_ADVERTISE: AS2 to AS3 1184 NLRI = PE ip address 1186 Figure 7: - Example 1 1188 Another use case can be to advertise TCAs among different network 1189 sites within one Enterprise network. In Hub and Spoke deployments, 1190 Administrator may define TCAs at spoke and advertise QoS TCA 1191 parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1 1192 and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in 1193 Figure 7, AS2 can advertise TCA to AS3 in the context of that tunnel 1194 ip address. 1196 AS 2 1197 _______________ ________ 1198 / \ / \ 1199 _____ / \-----| Spoke2 | 1200 / \ / \ \________/ 1201 | Hub |-----| Provider | ________ 1202 \______/ \ / / \ 1203 \ /-----| Spoke1 | 1204 AS 3 \_______________/ \________/ 1205 AS 1 1207 TCA_ADVERTISE: AS2 to AS3 1208 NLRI = AS2 tunnel address 1210 TCA_ADVERTISE: AS1 to AS3 1211 NLRI = AS1 tunnel address 1213 Figure 7 - Example 2 1215 Deployment options are not limited to involving CEs, PE-to-CE or CE- 1216 to-CE, only. For any contract between two providers, TCA parameters 1217 may be advertised from one to the other. 1219 8. IANA Considerations 1221 This document defines a new BGP optional transitive path attribute, 1222 called QoS Attribute. IANA action is required to allocate a new 1223 code-point in the BGP path Attributes registry. 1225 IANA is requested to create a registry for QoS Attribute SubTypes. 1226 This is a registry of 1 octet value, divided into two pools.One pool 1227 of numbers to be assigned on a standards action/early allocation 1228 basis. The initial assignments are as shown below. The other pool 1229 is for the private use,available range for which is as shown below. 1231 QoS Attribute SubTypes 1232 ====================== 1233 Reserved 0x00 1234 TCA 0x01 1235 Reserved 0x02-0xf0 (Standards Action) 1236 Private use 0xf1-0xff 1238 IANA is requested to create a registry for QoS Attribute TCA Event 1239 Types. This is a registry of 4-bits value, divided into two pools. 1240 One pool of numbers to be assigned on a standards action/early 1241 allocation basis. One pool of numbers to be assigned on a standards 1242 action/early allocation basis. The initial assignments are as shown 1243 below. The other pool is for the private use, available range for 1244 which is as shown below. 1246 QoS Attribute TCA Event Types 1247 ============================= 1248 Reserved 0x0 1249 ADVERTISE 0x1 1250 Reserved 0x2 - 0xc (Standards Action) 1251 Private use 0xd - 0xf 1253 IANA is requested to create a registry to define QoS Attribute TCA 1254 Direction. This is the direction in forwarding path, advertised QoS 1255 TCA is applicable to. This is a 2-bit registry. Values for QoS 1256 Attribute TCA direction are: 1258 QoS Attribute TCA Direction 1259 =========================== 1260 Reserved 0x0 1261 To source AS from destination AS 0x1 1262 From source AS to destination AS 0x2 1263 Reserved (Standards Action) 0x3 1265 QoS Attribute TCA Traffic Class Element Types will be referring to 1266 existing IPFIX IANA types as listed in Table 1. While IPFIX registry 1267 is maintained by IANA out of scope of this specification, the use of 1268 IPFIX identifiers for this specification are limited to what is 1269 described in Table 1. Any new addition of IPFIX identifiers to this 1270 table should be a Standards Action. 1272 IANA is requested to create a registry for QoS Attribute TCA Traffic 1273 Class Service Types. This is a registry of 2 octet values, to be 1274 assigned on a standards action/early allocation basis. The initial 1275 assignments are: 1277 Traffic Class Service Type Value 1278 ============================ ====== 1279 Reserved 0x00 1280 COMMITTED_TSPEC 0x01 1281 PEAK_TSPEC 0x02 1282 COMMITTED_IN_PROFILE_MARKING 0x03 1283 COMMITTED_OUT_PROFILE_MARKING 0x04 1284 PEAK_OUT_PROFILE_MARKING 0x05 1285 DROP_THRESHOLD 0x06 1286 RELATIVE_PRIORITY 0x07 1287 EFFECTIVE_MAX_RATE 0x08 1288 Standards Action 0x09 - 0x3FFF 1289 FCFS 0x4000 - 0x4FF0 1291 9. Security Considerations 1293 BGP security vulnerabilities analysis is documented in [RFC4272], 1294 while BGP-related security considerations are discussed in [RFC4271]. 1295 Also, the reader may refer to [RFC7132] for more details about BGP 1296 path threat model. Means to prevent route hijacking SHOULD be 1297 enabled. Such means include RPKI based origin validation [RFC7115] 1298 and BGP Path validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). 1299 Rest of the content in this section discusses additional privacy and 1300 security considerations that are applicable to the attribute defined 1301 in this document. 1303 The information conveyed in the QoS Attribute TCA SubType reveals 1304 sensitive data that should not be exposed publicly to non-authorized 1305 parties. Deployment considerations mainly target use of QoS 1306 Attribute and TCA SubType in managed networks and those where a trust 1307 relationship is in place (Customer to Provider, or Provider to 1308 Provider). Administrators MUST disable this attribute to be sent to 1309 a remote peer which whom no trust relationship is in place. Both TCA 1310 Producer and Consumer SHOULD NOT publish valid TCA IDs to non- 1311 authorized nodes. 1313 The attribute may be advertised by a misbehaving node to communicate 1314 TCA parameters that are not aligned with the TCA agreements. The 1315 enforcement of TCA parameters is outside the scope of this document. 1317 The attribute defined in this document may be used by a misbehaving 1318 node for denial-of-service (e.g., inadequately rate-limit or drop 1319 some critical traffic). As a mitigation, a BGP peer MUST accept this 1320 attribute only from trusted BGP peers. For example, ACLs may be 1321 configured to identify the trusted ASes that are allowed to send the 1322 attribute. Further, administrators of a TCA Consumer's domain are 1323 RECOMMENDED to generate TCA ID using pseudo-random schemes [RFC4086]. 1324 Using robust TCA IDs make it hard to guess a valid TCA. 1326 10. Acknowledgements 1328 Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and 1329 Alvaro Retana for their suggestions and to Christian Jacquenet, Ken 1330 Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand 1331 Duvivier, Bruno Decraene, David Black, and Ron Bonica for the review. 1333 11. References 1335 11.1. Normative References 1337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1338 Requirement Levels", BCP 14, RFC 2119, 1339 DOI 10.17487/RFC2119, March 1997, 1340 . 1342 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1343 of Guaranteed Quality of Service", RFC 2212, 1344 DOI 10.17487/RFC2212, September 1997, 1345 . 1347 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1348 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1349 2003, . 1351 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1352 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1353 DOI 10.17487/RFC4271, January 2006, 1354 . 1356 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 1357 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 1358 2006, . 1360 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1361 for IP Flow Information Export (IPFIX)", RFC 7012, 1362 DOI 10.17487/RFC7012, September 2013, 1363 . 1365 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1366 Resource Public Key Infrastructure (RPKI)", BCP 185, 1367 RFC 7115, DOI 10.17487/RFC7115, January 2014, 1368 . 1370 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1371 Patel, "Revised Error Handling for BGP UPDATE Messages", 1372 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1373 . 1375 11.2. Informative References 1377 [I-D.ietf-sidr-bgpsec-protocol] 1378 Lepinski, M. and K. Sriram, "BGPsec Protocol 1379 Specification", draft-ietf-sidr-bgpsec-protocol-22 (work 1380 in progress), January 2017. 1382 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1383 and W. Weiss, "An Architecture for Differentiated 1384 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1385 . 1387 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1388 "Randomness Requirements for Security", BCP 106, RFC 4086, 1389 DOI 10.17487/RFC4086, June 2005, 1390 . 1392 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1393 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1394 . 1396 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1397 and D. McPherson, "Dissemination of Flow Specification 1398 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1399 . 1401 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1402 the Network Configuration Protocol (NETCONF)", RFC 6020, 1403 DOI 10.17487/RFC6020, October 2010, 1404 . 1406 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1407 and A. Bierman, Ed., "Network Configuration Protocol 1408 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1409 . 1411 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1412 Autonomous System (AS) Number Space", RFC 6793, 1413 DOI 10.17487/RFC6793, December 2012, 1414 . 1416 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1417 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1418 . 1420 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1421 Connectivity Provisioning Profile (CPP)", RFC 7297, 1422 DOI 10.17487/RFC7297, July 2014, 1423 . 1425 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1426 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1427 October 2015, . 1429 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1430 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1431 . 1433 Authors' Addresses 1435 Shitanshu Shah 1437 Email: shitanshu_shah@hotmail.com 1439 Keyur Patel 1440 Arrcus, Inc 1442 Email: keyur@arrcus.com 1444 Sandeep Bajaj 1445 Viptela 1446 Luis Tomotaki 1447 Verizon 1448 400 International 1449 Richardson, TX 75081 1450 US 1452 Email: luis.tomotaki@verizon.com 1454 Mohamed Boucadair 1455 Orange 1456 Rennes 1457 35000 1458 France 1460 Email: mohamed.boucadair@orange.com