idnits 2.17.1 draft-ietf-idr-sla-exchange-09.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (August 1, 2016) is 2809 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) == Unused Reference: 'RFC2434' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC6793' is defined on line 1299, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4272 ** Downref: Normative reference to an Informational RFC: RFC 7132 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-15 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-17 -- 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: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Shah 3 Internet-Draft K. Patel 4 Intended status: Standards Track Cisco Systems 5 Expires: February 2, 2017 S. Bajaj 6 Juniper Network 7 L. Tomotaki 8 Verizon 9 M. Boucadair 10 Orange 11 August 1, 2016 13 Inter-domain SLA Exchange Attribute 14 draft-ietf-idr-sla-exchange-09.txt 16 Abstract 18 Network administrators typically enforce Quality of Service (QoS) 19 policies according to Service Level Agreement (SLA) with their 20 providers. The enforcement of such policies often relies upon 21 vendor-specific configuration language. Both learning of SLA, either 22 thru SLA documents or via some other out-of-band method, and 23 translating them to vendor specific configuration language is a 24 complex, often manual, process and prone to errors. 26 This document specifies an optional transitive attribute to signal 27 SLA parameters in-band, across administrative boundaries (considered 28 as Autonomous Systems (AS)), thus simplifying and facilitating some 29 of the complex provisioning tasks in situations where BGP is 30 available as a routing protocol. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 2, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 5 69 3.1. QoS Attribute SubType . . . . . . . . . . . . . . . . . . 6 70 3.2. SLA SubType . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.3. SLA Content for ADVERTISE SLA Event . . . . . . . . . . . 9 72 3.3.1. Supported IPFIX identifiers for Traffic Class 73 Elements . . . . . . . . . . . . . . . . . . . . . . 13 74 3.3.2. Traffic Class Service types and respective TLVs . . . 14 75 4. Originating SLA Notification . . . . . . . . . . . . . . . . 21 76 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 21 77 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 21 78 4.1.2. SLA Advertisement for Destination AS Multiple Hops 79 Away . . . . . . . . . . . . . . . . . . . . . . . . 22 80 5. QoS Attribute Handling at Forwarding Nodes . . . . . . . . . 22 81 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 23 82 5.2. QoS Attribute Handling at Receiver . . . . . . . . . . . 23 83 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23 84 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 90 11.2. Informative References . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 Typically there is a contractual Service Level Agreement (SLA) for 96 QoS established between a customer and a provider or between 97 providers [RFC7297]. This QoS SLA defines the nature of the various 98 traffic classes and services needed within each traffic class. The 99 contract may include full line-rate or sub line-rate without 100 additional traffic classes, or it may contain additional traffic 101 classes and service definitions for those traffic classes. Finer 102 granular traffic classes may be based on some standard code points 103 (e.g., based on DSCP (Differentiated Services Code Point)) or 104 specific set of prefixes. 106 Once the contractual QoS SLA is established, QoS SLA parameters are 107 enforced in some or all participating devices by deriving those 108 parameters into configuration information on respective devices. The 109 network administrator translates the QoS SLA to QoS policies using 110 router (vendor) specific provisioning language. In a multi-vendor 111 network, translating SLAs into technology-specific and vendor- 112 specific configuration requires the network administrator to consider 113 specific configuration of each vendor. There does not exist any 114 standard protocol to translate SLA agreements into technical clauses 115 and configurations and thus both the steps of out of band learning of 116 negotiated SLA and provisioning them in a vendor specific language 117 can be complex and error-prone. 119 SLA parameters may have to be exchanged through organizational 120 boundaries, thru SLA documents or via some other off-band method, to 121 an administrator provisioning actual devices. For example, to 122 provide voice services, the provider may negotiate QoS parameters 123 (like min/max rates) for such traffic classified under the EF 124 (Expedited Forwarding) codepoint in Diffserv-enabled [RFC2475] 125 networks. The Administrator at the CE (Customer Edge) not only will 126 have to know that provider's service for voice traffic is EF-based 127 but will also have to know how to implement DSCP EF classification 128 rule along with Low Latency Service, and possibly min/max rate 129 enforcement for the optimal use of bandwidth, as per vendor specific 130 provisioning language. 132 The Inter-domain exchange of QoS SLA policy described in this 133 document does not require any specific method for the provider in 134 establishing SLAs. It only requires that the provider wishes to send 135 the QoS SLA policy via BGP UPDATE [RFC4271] messages from the 136 provider to a set of receivers (BGP peers). In reaction to, a 137 receiving router may translate that to relevant QoS policy definition 138 on the device. The SLA negotiation and assurance is outside the 139 scope of this document. 141 This document defines a new optional BGP transitive attribute, 142 referred as QoS Attribute, which has as one of its sub-types the SLA 143 policy. The BGP node of the originating AS sends this QoS Attribute, 144 for prefixes this QoS SLA Policy applies to, in a BGP UPDATE message 145 that will be distributed to a list of destination ASes. The QoS SLA 146 policy can be for inbound traffic to the advertising AS or outbound 147 traffic from the advertising AS, or both. 149 Protocols and data models are being created to standardize setting 150 routing configuration parameters within networks. YANG data models 151 [RFC6020] are being developed so that NETCONF ([RFC6241] or RESTConf 152 ([I-D.ietf-netconf-restconf]) can set these standardize in 153 configuration mechanisms. For ephemeral state, the I2RS protocol is 154 being developed to set ephemeral state. While these protocols 155 provide valid configuration within a domain or across domains, some 156 providers desire to exchange QoS parameters in-band utilizing BGP 157 peering relationships. This is similar to the distribution of Flow 158 Specification information via BGP peering relationships (see 159 [RFC5575] and [RFC7674]). 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 BGP Speaker: A functional component on a BGP capable device that 168 functions as per BGP specification. 170 BGP Peers: BGP Speakers adjacent to each other. 172 QoS Attribute Speaker: A functional component on a BGP capable device 173 that produces and/or processes content of the QoS Attribute. A 174 device that is QoS Attribute Speaker is also always a BGP Speaker. 175 However, a BGP Speaker not necessarily always a QoS Attribute 176 Speaker. 178 QoS Attribute content is produced and processed outside the function 179 of the BGP Speaker and thus content of the QoS Attribute is 180 completely opaque to the BGP Speaker. At BGP capable device where 181 QoS Attribute content is produced, length and value of the QoS 182 Attribute is passed from QoS Attribute Speaker to the BGP Speaker 183 where BGP Speaker inserts the attribute into the BGP UPDATE message 184 with appropriate attribute flags, attribute type, and length and 185 value passed from the QoS Attribute Speaker. Similarly, a BGP 186 capable device when receives QoS Attribute in the BGP UPDATE message, 187 BGP Speaker extracts QoS Attribute value from the message and passes 188 it to the QoS Attribute Speaker where QoS Attribute Speaker processes 189 the content from that passed down value. How the content of the QoS 190 Attribute is passed from the QoS Attribute Speaker to the BGP Speaker 191 and vice versa is implementation specific. 193 In the context of use of QoS Attribute for SLA parameters exchange, 194 following roles are defined further within the scope of the QoS 195 Attribute Speaker. 197 SLA Producer: This is a QoS Attribute Speaker that produces QoS 198 Attribute for the SLA SubType. 200 SLA Consumer: This is a QoS Attribute Speaker that is intended 201 receiver of QoS Attribute with the SLA SubType. 203 3. QoS Attribute Definition 205 The QoS Attribute is an optional transitive attribute (TBD - 206 attribute code to be assigned by IANA) which is applicable to the 207 Source AS and NLRIs advertised in the BGP UPDATE message this 208 attribute is included in. The format of the QoS Attribute is shown 209 in Figure 1. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Attr flag | Attr type QoS | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 216 ~ ~ 217 | QoS Attr length/value | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 220 Figure 1 222 Attribute flags - 8-bits field 224 highest order bit (bit 0) - MUST be set to 1, since this is an 225 optional attribute 227 2nd higher order bit (bit 1) - MUST be set to 1, since this is a 228 transitive attribute 230 The content of the QoS Attribute is further specified with flags, 231 applicable to QoS Attribute content, and a SubType in a TLV form. 233 3.1. QoS Attribute SubType 235 The Value field of the QoS Attribute contains the following: 237 QoS Attribute flags 239 Tuple (SubType of the QoS Attribute, SubType length, SubType 240 value) 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 | QoS Attr flags| SubType | SubType length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 ~ ~ 248 | SubType value | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.........................+ 251 Figure 2 - Format of QoS Attribute 253 QoS Attr flags - 8-bits field 255 All bits of this field are currently un-used. The space is 256 provided for future use. All bits MUST be set to zero when sent. 257 The values (0x01-0xFF) are reserved, and MUST be ignored when 258 received. 260 SubType - 8-bits field with following values: 262 0x00 = reserved 264 0x01 = SLA 266 0x02 - 0xf0 = reserved for future use (Standards Action) 268 0xf1 - 0xff = Private use 270 The only SubType of the QoS Attribute defined in this 271 specification is the SLA SubType. 273 SubType length - 16-bits field that specifies length of the SubType 274 value in number of octets. 276 SubType value - variable length field, as expressed in SubType 277 length, that contains information about a specified SubType. For 278 the SLA SubType the information is about sender and receiver(s), 279 and SLA parameters as described in Section 3.2. 281 3.2. SLA SubType 283 Format of the SLA SubType Value field is shown in Figure 3. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | SLA SubType flags | Destination AS count | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Source AS (Advertiser) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | variable list of Destination AS | 293 ~ .... ~ 294 | .... | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |SLAEvnt| SLA ID | SLA length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | SLA Content for SLA Event | 299 ~ ~ 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3 - Format of the SLA SubType of the QoS attribute 305 SLA SubType flags - 16-bits field 307 highest order bit (bit 0) - 309 If set to 1 indicates that SLA ID and SLA Content, specified in 310 this SLA SubType, is from the source AS to the list of 311 Destination AS specified in the same SLA SubType. 313 If set to 0 indicates to ignore Source AS and list of 314 Destination AS specified in this SLA SubType field. SLA ID and 315 SLA Content, specified in this SLA SubType, are intended for 316 the peer receiver of the BGP UPDATE message. In such a case, 317 on reception of such a message, QoS Attribute Speaker SHOULD 318 drop the QoS Attribute from the BGP UPDATE message and rest of 319 the BGP UPDATE message should be processed by BGP Speaker as 320 per BGP specification. 322 Rest all other bits are currently un-used. 324 Destination AS count - 16-bits field that specifies count of 325 destination ASNs present in the Destination AS list. 327 This count has no functional value when highest order bit in the 328 SLA SubType flags field is set to 0. When highest order bit is 329 set to 1 and if this count is 0 then that is an error condition 330 which should be handled as described in Section 6. 332 Source AS - 32-bits field (AS number space as defined in RFC6793) 334 This is the AS where SLA Content is originated from. The Source 335 AS MUST be of the same AS that is originating SLA ID and SLA 336 Content. 338 When highest order bit in the SLA SubType flags field is set to 0, 339 this Source AS value MUST be ignored. In such a case SLA ID and 340 SLA Content of this SLA SubType is intended for the peer receiver 341 of the BGP UPDATE message. 343 When highest order bit in the SLA SubType flags field is set to 1, 344 the Source AS value of 0 is illegal and thus should be considered 345 an error which should be handled as described in Section 6. 347 Destination AS list - variable length field that holds as many ASN 348 identifiers, each is 32-bits (AS number space is defined in 349 RFC6793), as specified in the Destination AS count field. 351 List of ASNs for which the SLA is relevant to, each of which is a 352 32-bit number. If Destination AS count is set to 0 then this 353 field MUST NOT be included. 355 SLA Event - 4-bits field with following values: 357 0x0 = reserved 359 0x1 = ADVERTISE 361 0x2 to 0xf = Reserved for future use 363 The only SLA Event defined in this specification is ADVERTISE. 365 SLA ID - 16-bits field that specifies identifier which is unique in 366 the scope of Source AS. 368 The significance of an SLA ID is in the context of the source that 369 is advertising SLA Content. The SLA ID is not globally unique but 370 it MUST be unique within the source AS. 372 The SLA ID applies to aggregate traffic to prefixes for a given 373 AFI/SAFI that share the same Source AS and SLA ID. 375 If an advertised SLA ID is different from earlier advertised one, 376 for the same prefix and from the same Source AS, indicates Source 377 AS is advertising new SLA Content to replace the previous one 378 advertised with the same SLA ID. 380 SLA Length - 12-bits field that specifies the length of the SLA 381 Content. The length is expressed in octets. The SLA Content is 382 optional for an advertised SLA ID. If the SLA Content need not be 383 there, the SLA length field MUST be set to zero in such a case. 385 SLA Content - A variable length field (optional field) 387 The SLA Content field contains SLA parameters relevant to 388 specified SLA SubType. Since the only defined SLA SubType is 389 ADVERTISE, this specification describes SLA Content only for the 390 ADVERTISE SLA Event. 392 If SLA Content field exists in a BGP UPDATE message that contains 393 the QoS Attribute with an SLA SubType for SLA Event ADVERTISE, 394 format of the SLA Content is as described in Section 3.3. 396 If the SLA Content field does not exist, then the advertised 397 message refers to SLA Content advertised in the previous message 398 for the same SLA ID. If there does not exist any prior SLA 399 Content to relate to the advertised SLA ID, then receiver, SLA 400 Consumer, can ignore the SLA advertisement and it may simply 401 update Destination AS count and Destination AS list. 403 The lack of a valid prior SLA Content field does not make this 404 attribute invalid, so the QoS Attribute MUST be forwarded as a 405 valid BGP optional transitive attribute. 407 3.3. SLA Content for ADVERTISE SLA Event 409 The only SLA Event described in this specification is ADVERTISE. The 410 format of SLA Content for the ADVERTISE Event is shown in Figure 4. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |dir| Traffic Class count | Class Desc Len| | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 417 | | 418 ~ Traffic Class Description ~ 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Element Count | | 422 +-+-+-+-+-+-+-+-+ ~ 423 | | 424 ~ Traffic Class Element TLVs ~ 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Service Count| | 428 +-+-+-+-+-+-+-+-+ ~ 429 | Traffic Class Service TLVs | 430 ~ ~ 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 ~ Repeat from Traffic Class Description for next Traffic Class ~ 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 ~ Repeat from direction for SLA in the other direction ~ 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 4 - SLA-Content for ADVERTISE SLA Event 444 SLA Content contains set of Traffic Class Elements (Classifiers) and 445 Traffic Class Service TLVs for a list of Traffic Classes. This list 446 of Traffic Classes MUST be specified for one direction first and then 447 optionally followed by the specification for the other direction. 449 dir (Direction) - 2-bits field that specifies Direction of the 450 traffic SLA is applicable to. The following values are defined: 452 0x0 = reserved 454 0x1 = incoming, traffic to source AS from destination AS 456 0x2 = outgoing, traffic from source AS towards destination AS 458 0x3 = for future use 460 Traffic Class (Classifier Group) count - 16 bits field that 461 specifies number of Traffic Classes. 463 The value of zero (0x00) in this field is a special value which 464 means no SLA for the traffic in a specified direction. When 465 Traffic Class count is 0, for a specific direction, the rest of 466 the SLA Content fields MUST NOT be encoded, for that specific 467 direction. 469 Traffic Class Description Len - 8-bits field that specifies the 470 length of the Traffic Class Description field. The length is 471 expressed in octets. 473 The value of zero in this field indicates that no Traffic Class 474 Description field follows. 476 Traffic Class Description - variable length field, as expressed in 477 The Traffic Class Description Len field, MUST carry UTF-8 encoded 478 [RFC3629] description. 480 Traffic Class Elements (Classifier) Count - 8-bits field that 481 specifies the count of Traffic Class Elements. 483 The value zero (0x00) means there are no Traffic Class Elements in 484 the traffic class, and thus the Traffic Class is to classify rest 485 of the traffic not captured otherwise by other Traffic Classes in 486 the set for a specified direction. 488 Traffic Class that has 0 elements MUST be presented last in the 489 advertised list of Traffic Classes for a specific Direction. 490 Otherwise it is considered an error condition which should be 491 handled as described in Section 6. 493 The QoS Attribute advertised from a specific source MUST NOT 494 have more than one such Traffic Classes (Traffic Class with 0 495 elements count). If there are more than one such Traffic 496 Classes present then it is an error condition which should be 497 handled as described in Section 6. 499 Traffic Class Element TLVs - (optional) variable length field 500 holding as many TLVs specified by the Traffic Class Elements Count 501 field. Each TLV has the following format: 503 IPFIX Element Identifier - 8-bits field that specifies IPFIX 504 Identifiers listed in Table 1. 506 Length of Value field - 8-bits field that specifies the length, 507 expressed in octets, of the value field. 509 Value - A variable field that specifies a value appropriate for 510 the IPFIX Element Identifier. It is an error, if the value 511 field does not contain the appropriate format, which should be 512 handled as described in Section 6. Only the IPFIX elements 513 shown in Table 1 are supported. 515 Any Traffic Class Element advertised in the QoS Attribute only 516 applies to the advertised AFI/SAFI NLRI within the BGP UPDATE 517 message the QoS Attribute is contained in. If a receiver, SLA 518 Consumer, receives a BGP UPDATE message with QoS Attribute for an 519 unsupported AFI/SAFI then SLA Consumer MAY ignore advertised SLA. 520 SLA Consumer MAY update only Destination AS count and Destination 521 AS list, and then QoS Attribute and rest of the BGP UPDATE message 522 MUST be forwarded as per QoS Attribute and BGP protocol 523 specification. 525 Traffic Class Service Count - 8-bits field that specifies count of 526 Traffic Class Service TLVs. 528 A value of zero is a special value indicating "no bounded service" 529 (a.k.a., Best Effort (BE)). 531 Traffic Class Service TLVs - (optional) variable length field with 532 the following format for the TLVs 534 Traffic Class Service type - 16-bits field that specifies a 535 service type. Each service type is detailed in Section 3.3.2. 536 The list of available service types are, 538 0x00 = reserved 540 0x01 = TRAFFIC_CLASS_TSPEC 542 0x02 = L2_OVERHEAD 544 0x03 = MINRATE_IN_PROFILE_MARKING 546 0x04 = MINRATE_OUT_PROFILE_MARKING 548 0x05 = MAXRATE_IN_PROFILE_MARKING 550 0x06 = MAXRATE_OUT_PROFILE_MARKING 552 0x07 = DROP_THRESHOLD 554 0x08 = RELATIVE_PRIORITY 556 0x09 = SUB_TRAFFIC_CLASSES 558 Length of Value field - 08-bits field that specifies the length 559 of the value field. The length of the value is expressed in 560 octets. 562 Value - a variable length field that specifies the value 563 appropriate for each of the Service Types. It is an error, if 564 this field does not contain the appropriate format, which 565 should be handled as described in Section 6. The format of the 566 value for each of the service types is described in 567 Section 3.3.2 569 3.3.1. Supported IPFIX identifiers for Traffic Class Elements 571 IPFIX [RFC7012] has well defined identifier set for a large number of 572 packet attributes; an IPFIX IANA registry maintains values for packet 573 classifier attributes (https://www.ietf.org/assignments/ipfix/ 574 ipfix.xml#ipfix-information-elements). Only the IPFIX attributes 575 listed in Table 1 are supported. Any new attribute to be supported 576 by SLA SubType MUST be a Standards Action as described in IANA 577 section. 579 +----+----------------------------+ 580 | ID | Name | 581 +----+----------------------------+ 582 |195 | ipDiffServCodePoint | 583 |203 | mplsTopLabelExp | 584 |244 | dot1qPriority | 585 | 8 | sourceIPv4Address | 586 | 27 | sourceIPv6Address | 587 | 9 | sourceIPv4PrefixLength | 588 | 29 | sourceIPv6PrefixLength | 589 | 44 | sourceIPv4Prefix | 590 |170 | sourceIPv6Prefix | 591 | 12 | destinationIPv4Address | 592 | 28 | destinationIPv6Address | 593 | 13 | destinationIPv4PrefixLength| 594 | 30 | destinationIPv6PrefixLength| 595 | 45 | destinationIPv4Prefix | 596 |169 | destinationIPv6Prefix | 597 | 4 | protocolIdentifier | 598 | 7 | sourceTransportPort | 599 | 11 | destinationTransportPort | 600 +----+----------------------------+ 602 Table 1 604 3.3.2. Traffic Class Service types and respective TLVs 606 3.3.2.1. TRAFFIC_CLASS_TSPEC 608 The TRAFFIC_CLASS_TSPEC TLV definition: 610 Type - 0x01 612 Length - 8-bits field that specifies length, expressed in octets, 613 of the value field. The length of the value field MUST be 614 specified to be 12 octets to hold the value defined as per format 615 below. 617 Value - TRAFFIC_CLASS_TSPEC value consists of the (r), (b), (p) 618 parameters as described in Invocation Information section of 619 [RFC2212] and shown in Figure 5. Note that inheriting the 620 definition of TSPEC (Traffic SPECification) here does not enable 621 RFC2212 functionality. Only the format of the Traffic 622 Specification is used in this specification. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Minimum Rate (r) (32-bit IEEE floating point number) | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Burst Size (b) (32-bit IEEE floating point number) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Maximum Rate (p) (32-bit IEEE floating point number) | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 5 - Traffic Class TSPEC 636 Format of Parameters (r), (b) and (p): are 32-bit IEEE floating 637 point numbers. Positive infinity is represented as an IEEE single 638 precision floating-point number with an exponent of all ones and a 639 sign mantissa of all zeros. The format of IEEE floating-point 640 numbers is further summarized in [RFC4506]. 642 Parameter (r): indicates min-rate of the traffic class. This rate 643 indicates the minimum rate, measured in octets of Layer 2 (L2) 644 datagrams per second (a.k.a, bytes per second), that the service 645 advertiser is providing for a given class of traffic on 646 advertiser's hop. Note that it does not necessarily translate to 647 a minimum rate service to the receiver of an SLA unless the 648 traffic class definition clearly represents a sole receiver of an 649 SLA. If there is no SLA for min-rate, the value of (r) MUST be 650 set to 0. 652 Parameter (b): indicates maximum burst size, measured in octets of 653 L2 datagram size. Since queuing delay can be considered a 654 function of burst size (b) and min-rate (r), in presence of non- 655 zero parameter (r), parameter (b) represents bounded delay for the 656 Traffic Class. This delay is a single hop queuing delay when SLA 657 is to be implemented at the resource constrained bottleneck. In 658 other words this burst size can be considered as a buffer size. 659 Value of 0 for parameter (b) means the advertiser does not mandate 660 specific bounded delay. 662 Parameter (p): indicates max-rate of the traffic class. Just like 663 min-rate, max-rate, measured in octets of L2 datagrams per second 664 (a.k.a., bytes per second), field here also indicates service 665 provided by advertiser. If advertiser does not have any specific 666 value to set for a given class of traffic, it MAY be set to 667 physical interface line rate or any other indirect limit that may 668 affect this class' maximum rate. In absence of any such known 669 value, it MUST be set to positive infinity. Value 0 is considered 670 an error which should be handled as described in Section 6. 672 3.3.2.2. L2_OVERHEAD 674 The L2_OVERHEAD TLV definition: 676 Type - 0x02 678 Length - 8-bits field that specifies length, expressed in octets, 679 of the value field. 681 Value - Layer 2 overhead in octets 683 L2_OVERHEAD defines Layer 2 (L2) specific data in octets, on top of 684 IP datagram size, in a layer 2 frame. By default the rate and burst 685 advertised in the TRAFFIC_CLASS_TSPEC TLV are applicable to the 686 packet size including L2 packet overhead. For the SLA Consumer 687 directly connected to the SLA Producer, this overhead is the L2 688 overhead of the local link where advertised SLA is received. 690 However, in cases where advertised SLA is for a SLA Consumer multiple 691 hops away, L2 overhead from the source, SLA Producer, perspective may 692 be different from the local link L2 overhead at the receiver, SLA 693 Consumer. In such cases, explicit notification of size of L2 694 overhead from the SLA Producer suggests what per packet L2 overhead 695 is applicable to the rate and burst advertised in the 696 TRAFFIC_CLASS_TSPEC TLV. L2_OVERHEAD TLV SHOULD BE ignored by the 697 SLA Consumer if there does not exist TRAFFIC_CLASS_TSPEC TLV for the 698 specified direction. 700 Advertised L2 value of 0 means SLA advertised is for IP packet size. 702 3.3.2.3. MINRATE_IN_PROFILE_MARKING 704 This Traffic Class Service Type defines action performed, by the SLA 705 Producer, on packets that are compliant to the min-rate specified in 706 the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the 707 TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service 708 Type SHOULD NOT be advertised. MINRATE_IN_PROFILE_MARKING TLV SHOULD 709 BE ignored by the SLA Consumer if there does not exist 710 TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate 711 specified in the TRAFFIC_CLASS_TSPEC TLV is 0. 713 The MINRATE_IN_PROFILE_MARKING TLV definition: 715 Type - 0x03 717 Length - 8-bits field that specifies length, expressed in octets, 718 of the value field. The length of the value field MUST be 719 specified to be 2 octets to hold the value defined as per format 720 below. 722 Value - contains the Marking code-point type and value 724 Marking code-point type - 8-bits IPFIX Element Identifier. 726 Marking code-point value - 8-bits code-point number. 728 The marking code-point type of 0x00 is a drop identifier. When 729 marking code-point type value is 0x00 (that is drop), the marking 730 code-point value in this case has no meaning and thus the value in 731 this field should be ignored. 733 The following table lists the supported IPFIX Identifiers. Any value 734 other than 0 or identifier from the following table is an error 735 condition which should be handled as described in Section 6. 737 +----+----------------------------+ 738 | ID | Name | 739 +----+----------------------------+ 740 |195 | ipDiffServCodePoint | 741 |203 | mplsTopLabelExp | 742 |244 | dot1qPriority | 743 +----+----------------------------+ 745 Table 2 747 3.3.2.4. MINRATE_OUT_PROFILE_MARKING 749 This Traffic Class Service Type defines action performed, at the SLA 750 Producer, on packets that are not compliant to the min-rate specified 751 in the TRAFFIC_CLASS_TSPEC TLV. If min-rate specified in the 752 TRAFFIC_CLASS_TSPEC TLV is 0 then TLV for this Traffic Class Service 753 Type SHOULD NOT be advertised. MINRATE_OUT_PROFILE_MARKING TLV 754 SHOULD BE ignored by the SLA Consumer if there does not exist 755 TRAFFIC_CLASS_TSPEC TLV for the specified direction, or min-rate 756 specified in the TRAFFIC_CLASS_TSPEC TLV is 0. 758 The MINRATE_OUT_PROFILE_MARKING TLV definition: 760 Type - 0x04 762 Length - 8-bits field that specifies length, expressed in octets, 763 of the value field. The length of the value field MUST be 764 specified to be 2 octets to hold the value defined as per format 765 below. 767 Value - contains the Marking code-point type and value 769 Marking code-point type - 8-bits IPFIX Element Identifier 771 Marking code-point value - 8-bits code-point number 773 The marking code-point type of 0x00 is a drop identifier. When 774 marking code-point type value is 0x00 (that is drop), the marking 775 code-point value in this case has no meaning and thus the value in 776 this field should be ignored. 778 Table 2 lists the supported IPFIX Identifiers. Any value other than 779 0 or identifier from the Table 2 is an error condition which should 780 be handled as described in Section 6. 782 3.3.2.5. MAXRATE_IN_PROFILE_MARKING 784 This Traffic Class Service Type defines action performed, at the SLA 785 Producer, on packets that are compliant to the max-rate specified in 786 the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_IN_PROFILE_MARKING TLV SHOULD 787 BE ignored by the SLA Consumer if there does not exist 788 TRAFFIC_CLASS_TSPEC TLV for the specified direction. 790 The MAXRATE_IN_PROFILE_MARKING TLV definition: 792 Type - 0x05 793 Length - 8-bits field that specifies length, expressed in octets, 794 of the value field. The length of the value field MUST be 795 specified to be 2 octets to hold the value defined as per format 796 below. 798 Value - contains the Marking code-point type and value 800 Marking code-point type - 8-bits IPFIX Element Identifier 802 Marking code-point value - 8-bits code-point number 804 The marking code-point type of 0x00 is a drop identifier. When 805 marking code-point type value is 0x00 (that is drop), the marking 806 code-point value in this case has no meaning and thus the value in 807 this field should be ignored. 809 Table 2 lists the supported IPFIX Identifiers. Any value other than 810 0 or identifier from the Table 2 is an error condition which should 811 be handled as described in Section 6. 813 3.3.2.6. MAXRATE_OUT_PROFILE_MARKING 815 This Traffic Class Service Type defines action performed, at the SLA 816 Producer, on packets that are not compliant to the max-rate specified 817 in the TRAFFIC_CLASS_TSPEC TLV. MAXRATE_OUT_PROFILE_MARKING TLV 818 SHOULD BE ignored by the SLA Consumer if there does not exist 819 TRAFFIC_CLASS_TSPEC TLV for the specified direction. 821 The MAXRATE_OUT_PROFILE_MARKING TLV definition: 823 Type - 0x06 825 Length - 8-bits field that specifies length, expressed in octets, 826 of the value field. The length of the value field MUST be 827 specified to be 2 octets to hold the value defined as per format 828 below. 830 Value - contains the Marking code-point type and value 832 Marking code-point type - 8-bits IPFIX Element Identifier 834 Marking code-point value - 8-bits code-point number 836 The marking code-point type of 0x00 is a drop identifier. When 837 marking code-point type value is 0x00 (that is drop), the marking 838 code-point value in this case has no meaning and thus the value in 839 this field should be ignored. 841 Table 2 lists the supported IPFIX Identifiers. Any value other than 842 0 or identifier from the Table 2 is an error condition which should 843 be handled as described in Section 6. 845 3.3.2.7. Precedence between MINRATE and MAXRATE 847 The precedence between MINRATE_IN_PROFILE_MARKING, 848 MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING, and 849 MAXRATE_OUT_PROFILE_MARKING when all four are advertised is: 851 - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is 852 over MAXRATE_IN_PROFILE_MARKING), 854 - MAXRATE_IN_PROFILE_MARKING takes precedence over 855 MINRATE_OUT_PROFILE_MARKING, and 857 - MAXRATE_OUT_PROFILE_MARKING takes precedence over 858 MINRATE_OUT_PROFILE_MARKING 860 3.3.2.8. DROP_THRESHOLD 862 The DROP_THRESHOLD TLV definition: 864 Type - 0x07 866 Length - 8-bits field that specifies length, expressed in octets, 867 of the value field. 869 Value - Count of drop thresholds, followed by content for each 870 drop threshold in the form of (code-point type, count of code- 871 points, list of code-points, threshold value). 873 Count of drop thresholds - 8-bits field that specifies number 874 of drop thresholds specified in this TLV. Content of each drop 875 threshold is to follow following format 877 Code-point type - 8-bits IPFIX Element Identifier from the list 878 shown in Table 6. 880 Count of code-points - 8-bits field that specifies number of 881 code-point values to follow for a specified code-point type. 883 List of code-points - each code-point value is specified in 884 size of 8 bits and thus total size for this field is 8 bits 885 multiplied by as many number of code-points specified. 887 Burst value - This is a fixed size 32-bits IEEE floating point 888 number that specifies burst value in unit of bytes. 890 +----+----------------------------+ 891 | ID | Name | 892 +----+----------------------------+ 893 |195 | ipDiffServCodePoint | 894 |203 | mplsTopLabelExp | 895 |244 | dot1qPriority | 896 +----+----------------------------+ 898 Table 3 900 3.3.2.9. RELATIVE_PRIORITY 902 The RELATIVE_PRIORITY TLV definition: 904 Type - 0x08 906 Length - 8-bits field that specifies length, expressed in octets, 907 of the value field. Given supported range of priority values in 908 this specification, the length of the value field MUST be limited 909 to and thus MUST be specified exactly as 1 octet. 911 Value - A value from range of 0 - 255. Lower the value means 912 higher the priority 914 Relative priority indicates scheduling priority of this traffic 915 class. Voice traffic, for example, which requires lowest latency 916 compared to any other traffic, may have lowest value advertised in 917 relative priority. For two different traffic classification groups 918 where one application group may be considered more important than the 919 other but from a scheduling perspective does not require to be 920 distinguished with a different priority, relative priority for those 921 classification groups may be advertised with the same value. 923 3.3.2.10. SUB_TRAFFIC_CLASSES 925 The SUB_TRAFFIC_CLASSES TLV definition: 927 Type - 0x09 929 Length - 16-bits field that specifies total length, expressed in 930 octets, of a subset of Traffic Class TLVs encoded in the value 931 field 933 Value - A subset of Traffic Class TLVs 935 For SLAs where a specific Traffic Class may further be defined by a 936 subset of more granular Traffic Classes, each with its own set of 937 Traffic Class Elements and Service types definitions, 938 SUB_TRAFFIC_CLASSES service type SHOULD be used to specify them. 940 4. Originating SLA Notification 942 The QoS Attribute for the SLA SubType MUST only be added to the BGP 943 UPDATE message at the node that is SLA Producer. Any QoS Attribute 944 Speaker, in the path to the SLA Consumer MUST NOT modify content of 945 that attribute except modification of the Destination AS list. 947 QoS Attribute with the SLA SubType SHOULD NOT be advertised 948 periodically just for the purpose of KEEPALIVE between SLA Producer 949 and SLA Consumer. Some sort of SLA policy change, at the SLA 950 Producer, may be considered as a trigger for the advertisement. 952 For any modified SLA policy at the SLA Producer, SLA Producer MUST 953 re-advertise the entire set of SLA parameters. There is no provision 954 to advertise partial set of SLA parameters. If modified SLA policy 955 is to mean no SLA between SLA Producer and SLA Consumer, then SLA 956 Content MUST be sent with the same SLA ID with the same AS Source and 957 NLRI prefix, as were used to advertise earlier SLA parameters, and 958 the Traffic Class count set to 0. 960 4.1. SLA Contexts 962 4.1.1. SLA Advertisement for Point-to-Point Connection 964 In certain cases, the advertisement of an SLA is intended to relate 965 to aggregate traffic over a point-to-point connection between a 966 specific destination and a specific source. A point-to-point 967 connection may be a physical link or a virtual link (e.g. a tunnel). 968 In such cases, a BGP UPDATE message with source AS number and NLRI 969 prefix as an IP address of an SLA Producer can uniquely identify 970 physical/virtual link in order to establish the context for the 971 advertised SLA for that point to point link. 973 In the simplest case where Provider (e.g., PE) and Customer (e.g., 974 CE) devices are directly connected via a physical link and have only 975 a single link between them, the CE can uniquely identify the 976 forwarding link to the PE with the following: 978 o AS number of the PE, 980 o NLRI prefix being an IP address of the PE, that is the next hop 981 address from CE to PE. 983 The SLA advertised in the QoS Attribute in the BGP UPDATE message 984 sent from the PE to a CE, along with the PE's AS number and PE's IP 985 address, establishes SLA context for the aggregate traffic through 986 CE-to-PE link. 988 The SLA advertised in the QoS Attribute in the BGP UPDATE message 989 from PE to CE, with PE's AS number and any other prefix, means SLA 990 for that specific prefix based traffic, a subset of traffic through 991 CE-to-PE link. 993 Even though this example is in the context of IP prefixes, QoS 994 Attribute's SLA exchange does not have to be limited to the IP 995 address family (IPv4 and IPv6). SLA advertisement is generic to all 996 forms of NLRI types that are supported by the BGP specification (like 997 IPv4, IPv6, VPN-IPv4, VPN-IPv6). 999 When BGP UPDATE message with the QoS Attribute, containing SLA 1000 SubType, is triggered for a point-to-point connection (physical or 1001 logical), the Source AS number in the SLA SubType SHOULD BE set to 1002 SLA Producer's AS number and destination AS number SHOULD BE set to 1003 AS number of BGP peer's that is targeted SLA Consumer. 1004 Alternatively, highest order bit in the SLA SubType flags MAY BE set 1005 to ignore Source AS and destination AS values from the SLA SubType 1006 content since SLA advertised is meant specifically for the BGP peer. 1008 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away 1010 When advertised SLA is not for the BGP peer of an SLA Producer, the 1011 Source AS field, in the SLA SubType, MUST be set. The list of 1012 destination AS(es) also MUST be set, in the SLA SubType, to avoid 1013 flooding of the QoS Attribute data in the network beyond those 1014 destinations. Destination AS(es) is a list of SLA Consumers the 1015 advertised SLA is intended for. 1017 If a new prefix is learned and traffic with this new prefix is 1018 subject to SLA parameters that have already been advertised before 1019 for other existing prefixes, then the BGP UPDATE for this new prefix 1020 MAY include QoS Attribute containing just an SLA ID that was 1021 advertised earlier. This BGP UPDATE message does not require to have 1022 the whole SLA Content. The SLA ID is sufficient to relate SLA 1023 parameters to new advertised prefixes. 1025 5. QoS Attribute Handling at Forwarding Nodes 1027 The propagation of the QoS Attribute in the BGP UPDATE messages 1028 depends on the rules detailed in the following sub-sections. 1030 5.1. BGP Node Capable of Processing QoS Attribute 1032 If a BGP peer is also a QoS Attribute Speaker, it MAY process the QoS 1033 Attribute. If BGP UPDATE message has a QoS Attribute with a list of 1034 destination ASes, QoS Attribute Speaker MAY trim the list and adjust 1035 the count of the destination AS to exclude ones that are not required 1036 in further announcement of BGP UPDATE messages. 1038 A QoS Attribute Speaker MUST drop SLA SubType from the QoS Attribute, 1039 if there are no more ASes left in the QoS Attribute's destination 1040 list. The rest of the QoS Attribute contents may be forwarded if 1041 there exist other SubTypes of QoS Attribute and forwarding rules meet 1042 other SubTypes requirements. If there is no other SubTypes in that 1043 QoS Attribute content then QoS Attribute Speaker MUST drop the entire 1044 QoS Attribute all together. BGP Speaker MAY announce further other 1045 attributes and NLRI information, if they meet rules defined by other 1046 attributes and BGP specification. 1048 Except extracting the entire SLA SubType of the QoS Attribute and 1049 trimming the list of Destination AS list, all other content MUST NOT 1050 be modified by any QoS Attribute Speaker or BGP Speaker in the path 1051 of a BGP UPDATE message. 1053 5.2. QoS Attribute Handling at Receiver 1055 Once QoS Attribute with the SLA SubType is received at intended 1056 receiver (SLA Consumer) , processing of advertised SLA Content is 1057 optional for the SLA Consumer. SLA Consumer MAY just trim the 1058 Destination AS list as per rules described in this specification, 1059 without processing any other content of the Attribute. If intended 1060 receiver is not a QoS Attribute Speaker than BGP Speaker MUST forward 1061 this attribute without any change if rest of the BGP UPDATE message 1062 also meets forwarding rules as per BGP specification. 1064 When BGP UPDATE messages are triggered only as a result of SLA policy 1065 change, propagating BGP UPDATE message beyond intended SLA Consumers 1066 is not necessary. If the SLA Consumer device implementations are 1067 capable of policy based filtering, it may implement a policy to 1068 filter such BGP UPDATE messages based on prefixes and QoS Attribute 1069 containing SLA SubType. 1071 6. Error Handling 1073 Error conditions, while processing of the QoS Attribute content, MUST 1074 be handled with the approach of attribute discard as described in 1075 [RFC7606]. Processing of QoS Attribute content is done by QoS 1076 Attribute Speaker and thus in case of errors, resulting in attribute 1077 discard, QoS Attribute Speaker SHOULD convey such indication to the 1078 BGP Speaker and rest of the BGP message SHOULD BE processed by the 1079 BGP Speaker as per BGP specification. 1081 7. Deployment Considerations 1083 One of the use cases is for a provider to advertise contracted SLA 1084 parameters to a Customer Edge (CE) in cases where eBGP is deployed 1085 between PE and CE. The SLA parameters may already be provisioned by 1086 the provider on the PE device (facing CE). This provisioned SLA 1087 parameters are then advertised thru proposed QoS Attribute to the CE 1088 device. The CE device may read the QoS Attribute and SLA SubType 1089 content to implement the QoS policy on the device. 1091 Contracted SLA from PE to CE may be full line-rate or sub line-rate 1092 or finer granular controlled services. The advertised SLA can be 1093 useful when contracted service is sub-rate of a link and/or when for 1094 finer granular traffic classes that are controlled (e.g. voice, video 1095 services may be capped to certain rate). 1097 _______________ 1098 __________ / \ 1099 / \ / \ 1100 / \ / \ 1101 |CustomerSite|-----| Provider | 1102 \ C/E P\E / 1103 \__________/ \ / 1104 \_______________/ 1105 AS 3 AS 2 1107 SLA_ADVERTISE: AS2 to AS3 1108 NLRI = PE ip address 1110 Figure 6 - Example 1 1112 Another use case can be to advertise SLAs among different network 1113 sites within one Enterprise network. In Hub and Spoke deployments, 1114 Administrator may define SLAs at spoke and advertise QoS SLA 1115 parameters to the Hub thru BGP updates. In Figure 7, each spoke (AS1 1116 and AS2) are connected to Hub (AS3) via a VPN tunnel. As shown in 1117 Figure 7, AS2 can advertise SLA to AS3 in the context of that tunnel 1118 ip address. 1120 AS 2 1121 _______________ ________ 1122 / \ / \ 1123 _____ / \-----| Spoke2 | 1124 / \ / \ \________/ 1125 | Hub |-----| Provider | ________ 1126 \______/ \ / / \ 1127 \ /-----| Spoke1 | 1128 AS 3 \_______________/ \________/ 1129 AS 1 1131 SLA_ADVERTISE: AS2 to AS3 1132 NLRI = AS2 tunnel address 1134 SLA_ADVERTISE: AS1 to AS3 1135 NLRI = AS1 tunnel address 1137 Figure 7 - Example 2 1139 Deployment options are not limited to involving CEs, PE-to-CE or CE- 1140 to-CE, only. For any contract between two providers, SLA parameters 1141 may be advertised from one to the other. 1143 8. Acknowledgements 1145 Thanks to Fred Baker, David Black, Sue Hares, Benoit Claise and 1146 Alvaro Retana for their suggestions and to Christian Jacquenet, Ken 1147 Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand 1148 Duvivier, Bruno Decraene for the review. 1150 9. IANA Considerations 1152 This document defines a new BGP optional transitive path attribute, 1153 called QoS Attribute. IANA action is required to allocate a new 1154 code-point in the BGP path Attributes registry. 1156 IANA is requested to create a registry for QoS Attribute SubTypes. 1157 This is a registry of 1 octet value, divided into two pools.One pool 1158 of numbers to be assigned on a standards action/early allocation 1159 basis. The initial assignments are as shown below. The other pool 1160 is for the private use,available range for which is as shown below. 1162 QoS Attribute SubTypes 1163 ====================== 1164 Reserved 0x00 1165 SLA 0x01 1166 Reserved 0x02-0xf0 (Standards Action) 1167 Private use 0xf1-0xff 1169 IANA is requested to create a registry for QoS Attribute SLA SubType 1170 flags. This is registry for 8-bits. The initial assignments are as 1171 shown below. 1173 QoS Attribute SLA SubType Flags 1174 =============================== 1175 Highest order bit (bit 0) - to indicate source and destination AS context 1176 Reserved - bits 1 to 15 (Standards Action) 1178 IANA is requested to create a registry for QoS Attribute SLA Event 1179 Types. This is a registry of 4-bits value, divided into two pools. 1180 One pool of numbers to be assigned on a standards action/early 1181 allocation basis. One pool of numbers to be assigned on a standards 1182 action/early allocation basis. The initial assignments are as shown 1183 below. The other pool is for the private use, available range for 1184 which is as shown below. 1186 QoS Attribute SLA Event Types 1187 ============================= 1188 Reserved 0x0 1189 ADVERTISE 0x1 1190 Reserved 0x2 - 0xc (Standards Action) 1191 Private use 0xd - 0xf 1193 IANA is requested to create a registry to define QoS Attribute SLA 1194 Direction. This is the direction in forwarding path, advertised QoS 1195 SLA is applicable to. This is a 2-bit registry. Values for QoS 1196 Attribute SLA direction are: 1198 QoS Attribute SLA Direction 1199 =========================== 1200 Reserved 0x0 1201 To source AS from destination AS 0x1 1202 From source AS to destination AS 0x2 1203 Reserved (Standards Action) 0x3 1205 QoS Attribute SLA Traffic Class Element Types will be referring to 1206 existing IPFIX IANA types as listed in Table 1. While IPFIX registry 1207 is maintained by IANA out of scope of this specification, the use of 1208 IPFIX identifiers for this specification are limited to what is 1209 described in Table 1. Any new addition of IPFIX identifiers to this 1210 table should be a Standards Action. 1212 IANA is requested to create a registry for QoS Attribute SLA Traffic 1213 Class Service Types. This is a registry of 2 octet values, to be 1214 assigned on a standards action/early allocation basis. The initial 1215 assignments are: 1217 Traffic Class Service Type Value 1218 ============================ ====== 1219 Reserved 0x00 1220 TRAFFIC_CLASS_TSPEC 0x01 1221 L2_OVERHEAD 0x02 1222 MINRATE_IN_PROFILE_MARKING 0x03 1223 MINRATE_OUT_PROFILE_MARKING 0x04 1224 MAXRATE_IN_PROFILE_MARKING 0x05 1225 MAXRATE_OUT_PROFILE_MARKING 0x06 1226 DROP_THRESHOLD 0x07 1227 RELATIVE_PRIORITY 0x08 1228 SUB_TRAFFIC_CLASSES 0x09 1229 Standards Action 0x0A - 0x3FFF 1230 FCFS 0x4000 - 0x4FF0 1232 10. Security Considerations 1234 BGP security vulnerabilities analysis is documented in [RFC4272] 1235 while BGP-related security considerations are discussed in [RFC4271]. 1236 Also, the reader may refer to [RFC7132] for more details about BGP 1237 path threat model. Rest of the content in this section discusses 1238 additional privacy and security considerations that are applicable to 1239 the attribute defined in this document. 1241 The information conveyed in the QoS Attribute SLA SubType reveals 1242 sensitive data that should not be exposed publicly to non-authorized 1243 parties. Deployment considerations mainly target use of QoS 1244 Attribute and SLA SubType in managed networks and those where a trust 1245 relationship is in place (Customer to Provider, or Provider to 1246 Provider). It is NOT RECOMMENDED to enable this attribute at the 1247 scale of the Internet unless if means to prevent leaking sensitive 1248 information are enforced. 1250 The attribute may be advertised by a misbehaving node to communicate 1251 SLA parameters that are not aligned with the SLA agreements. Though 1252 the enforcement of SLA parameters is outside the scope of this 1253 document, it is RECOMMENDED that the SLA Consumer to enforce a set of 1254 validation checks before translating the SLA parameters conveyed in 1255 the QoS attributes into provisioning actions. Such validations MAY 1256 rely on SLA parameters lime the origin AS or SLA ID, like generating 1257 SLA ID using pseudo-random schemes [RFC4086]. 1259 Means to prevent route hijacking SHOULD BE considered. Such means 1260 include RPKI based origin validation [RFC7115] and BGP Path 1261 validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). 1263 11. References 1265 11.1. Normative References 1267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, 1269 DOI 10.17487/RFC2119, March 1997, 1270 . 1272 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1273 of Guaranteed Quality of Service", RFC 2212, 1274 DOI 10.17487/RFC2212, September 1997, 1275 . 1277 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1278 IANA Considerations Section in RFCs", RFC 2434, 1279 DOI 10.17487/RFC2434, October 1998, 1280 . 1282 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1283 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1284 2003, . 1286 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1287 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1288 DOI 10.17487/RFC4271, January 2006, 1289 . 1291 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1292 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1293 . 1295 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 1296 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 1297 2006, . 1299 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1300 Autonomous System (AS) Number Space", RFC 6793, 1301 DOI 10.17487/RFC6793, December 2012, 1302 . 1304 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1305 for IP Flow Information Export (IPFIX)", RFC 7012, 1306 DOI 10.17487/RFC7012, September 2013, 1307 . 1309 [RFC7115] Bush, R., "Origin Validation Operation Based on the 1310 Resource Public Key Infrastructure (RPKI)", BCP 185, 1311 RFC 7115, DOI 10.17487/RFC7115, January 2014, 1312 . 1314 [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", 1315 RFC 7132, DOI 10.17487/RFC7132, February 2014, 1316 . 1318 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1319 Patel, "Revised Error Handling for BGP UPDATE Messages", 1320 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1321 . 1323 11.2. Informative References 1325 [I-D.ietf-netconf-restconf] 1326 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1327 Protocol", draft-ietf-netconf-restconf-15 (work in 1328 progress), July 2016. 1330 [I-D.ietf-sidr-bgpsec-protocol] 1331 Lepinski, M. and K. Sriram, "BGPsec Protocol 1332 Specification", draft-ietf-sidr-bgpsec-protocol-17 (work 1333 in progress), June 2016. 1335 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1336 and W. Weiss, "An Architecture for Differentiated 1337 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1338 . 1340 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1341 "Randomness Requirements for Security", BCP 106, RFC 4086, 1342 DOI 10.17487/RFC4086, June 2005, 1343 . 1345 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1346 and D. McPherson, "Dissemination of Flow Specification 1347 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1348 . 1350 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1351 the Network Configuration Protocol (NETCONF)", RFC 6020, 1352 DOI 10.17487/RFC6020, October 2010, 1353 . 1355 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1356 and A. Bierman, Ed., "Network Configuration Protocol 1357 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1358 . 1360 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1361 Connectivity Provisioning Profile (CPP)", RFC 7297, 1362 DOI 10.17487/RFC7297, July 2014, 1363 . 1365 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1366 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1367 October 2015, . 1369 Authors' Addresses 1371 Shitanshu Shah 1372 Cisco Systems 1373 170 W. Tasman Drive 1374 San Jose, CA 95134 1375 US 1377 Email: svshah@cisco.com 1379 Keyur Patel 1380 Cisco Systems 1381 170 W. Tasman Drive 1382 San Jose, CA 95134 1383 US 1385 Email: keyupate@cisco.com 1387 Sandeep Bajaj 1388 Juniper Network 1389 1194 N. Mathilda Avenue 1390 Sunnyvale, CA 94089 1391 US 1393 Email: sbajaj@juniper.net 1394 Luis Tomotaki 1395 Verizon 1396 400 International 1397 Richardson, TX 75081 1398 US 1400 Email: luis.tomotaki@verizon.com 1402 Mohamed Boucadair 1403 Orange 1404 Rennes 1405 35000 1406 France 1408 Email: mohamed.boucadair@orange.com