Network Working Group S. Shah Internet-Draft K. Patel Intended status: Standards Track Cisco Systems Expires: September 2, 2012 S. Bajaj Juniper Networks March 1, 2012 BGP attribute for QoS SLA advertisement draft-svshah-bgp-qos-sla-attribute-00 Abstract Out-of-band manual learning of SLA details and provisioning them in general can be complex work for network administrators. For example, Enterprise network administrators not only have to know what is their SLA, for voice, video etc application traffic, with their Provider, but they also require translating application groups to Classifier groups as per provider's definition as well translate SLA to vendor specific provisioning language. An in-band method of QoS signaling can help to simplify some of the complexities. An optional transitive BGP attribute proposed in this document intends to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), and thus simplify/speed-up some of the complex tasks. Though the use-case with the proposed attribute is explicitly defined in this document, purpose of this attribute is not limited to this use-case only. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 2, 2012. Copyright Notice Shah, et al. Expires September 2, 2012 [Page 1] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Shah, et al. Expires September 2, 2012 [Page 2] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 5 2.1. SLA_ADVERTISE sub-type Definition . . . . . . . . . . . . 5 3. Addition of QoS attribute in a BGP update message . . . . . . 11 3.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 12 4. Processing of QoS attribute at forwarding nodes . . . . . . . 13 4.1. BGP node capable of processing QoS attribute . . . . . . . 13 4.2. BGP node not capable of processing QoS attribute . . . . . 13 5. Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Traffic class mapping . . . . . . . . . . . . . . . . . . 14 6. Deployment Consideration . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Shah, et al. Expires September 2, 2012 [Page 3] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 1. Introduction Definition of traffic classes and services for each traffic class between 2 administrative boundaries, typically between Customer's Edge (CE) and Provider's Edge (PE) or between one Provider's Edge to another Provider's Edge, is contracted. The contract may exist in different variations. The contract could be full line-rate or sub- rate for aggregate traffic. Or it could be even with further finer granular traffic distinction with services defined for standard code- points or for specific set of pre-fix or for set of well-known application types. Today, this contract is required to be learned out-of-band. Learning SLAs out-of-band has associated costs with provisioning them. To over-come complexities associated with out-of-band learning of QoS SLA, we are proposing a new BGP attribute to advertise/learn them in- band [In rest of the document we may refer "QoS SLA" simply as "SLA"]. BGP attribute proposed in this document is intended to advertise SLA from one AS to a list of interested AS. QoS services advertised could be for the incoming traffic to the AS community, that is advertising SLA or could be for the outgoing traffic from the advertiser or could be for both directions. Reception of and reaction to advertised SLAs are optional for the receiver. The aim with the signaling of this attribute, across administrative boundaries, is to help network administrators speed up and simplify QoS provisioning with automatic learning of SLAs and thus avoiding complexities and possible errors with manual learning. Requirements of QoS SLA advertisement and definition of its details is generic and independent of BGP protocol. However, we find BGP a suitable transport for reasons, - There is no explicit protocol defined/available today for the purpose of QoS SLA exchange - The most common use-case of QoS SLA exchange is across Autonomous Systems defined by BGP - QoS attribute, apart for the use of SLA advertisement, in BGP can be extended in the future for specific set of prefixes advertised (flow or flow-group), thru BGP updates We propose QoS as an optional transitive attribute, keeping SLA advertisement as an internal of QoS attribute. This is to keep QoS attribute open for extensions, in future, beyond SLA advertisement. Shah, et al. Expires September 2, 2012 [Page 4] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 2. QoS Attribute Definition The QoS Attribute proposed, in BGP, is an optional transitive attribute (attribute type code to be assigned by IANA). SLA_ADVERTISE is defined as one of the sub-types in the QoS attribute value. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr flag | QoS Attr type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | QoS Attr length/Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... Attribute flags highest order bit (bit 0) - MUST be set to 1, since this is an optional attribute 2nd higher order bit (bit 1) - MUST be set to 1, since this is a transitive attribute The first octet in the Value field of the QoS attribute is Attribute specific flag highest order bit (bit 0) - It defines if update message MUST be dropped (if set to 1), when this is the last BGP receiver from the list of AS this attribute is announced to, or MUST announce (if set to 0) further to BGP peers The purpose of this bit is discussed further in subsequent sections. Remaining bits are currently unused and MUST be set to 0 2.1. SLA_ADVERTISE sub-type Definition The Value field for the QoS Attribute contains further TLVs, followed to QoS Attribute flag described in previous section. One of the TLVs we define, what is intended in this document, is tuple of (SLA advertise sub-type, Length, Value) Shah, et al. Expires September 2, 2012 [Page 5] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS Attr flag | subType | sub type Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... subType - 8 bits 0x00 = reserved 0x01 = SLA_ADVERTISE_V1 0x02 - 0x0f = for future use The format of SLA_ADVERTISE_V1 sub-type is, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit source AS (Advertiser) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Optional advertiserid total len| Advertiser id TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit destination AS count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | variable list of destination AS | ~ .... ~ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |dir| Traffic Class count | Class Desc Len| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | | ~ Traffic Class Description ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Traffic Class Elements count/values ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Count| service type/value pair | +-+-+-+-+-+-+-+-+ ~ | | Shah, et al. Expires September 2, 2012 [Page 6] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Repeat from Traffic Class Description for next Traffic Class ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Repeat from direction for SLA in the other direction ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source AS 32-bit source AS number. This is the AS that is advertising SLA 0 = ignore Source and Destination AS list from this Value field. Instead refer to Source and Destination AS as defined by BGP message. QoS SLA sub-type specifics, from the QoS attribute, MUST be removed by the receiver in such case. Optional advertiser id total len 16-bit Source address identifier (optional). 0 = No optional identifier Optional Advertiser id TLV 4-bit type 0x0 = reserved 0x1 = AF_IPV4, length = 32-bits, value = ipv4 prefix/address 0x2 = AF_IPV6, length = 128-bits, value = ipv6 prefix/address 0x3 = Path Identifier, length = 16-bits 0x4 to 0xf = for future use Destination AS count 32-bit destination AS count to take variable length AS list. This count has no functional value when Source AS is 0 0 = broadcast Destination AS list 32-bit destination AS number, this field is omitted if broadcast .... .... [as many as AS count] .... Shah, et al. Expires September 2, 2012 [Page 7] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Direction 02-bit for incoming or outgoing traffic, 0x0 = reserved 0x1 = incoming, from destination AS towards source AS 0x2 = outgoing, from source AS towards destination AS 0x3 = for future use Traffic Class count (Classifier Groups count) 16-bit, count of number of classifier groups 00 = Advertisement to invalidate previous advertised SLA if was advertised Traffic Class Descr Length 08-bit, size of the length 0 = No description Traffic Class Description Ascii Description of the Traffic Class Traffic Class Elements Count in a Traffic Class, 08-bit count of classifier elements in a specific Traffic Class 00 = this has relative definition. It means classify rest all traffic that is not classified via earlier described Traffic Classes. It is RECOMMENDED to have 0 elements Traffic Class definition last in the ordered list. If Advertised SLA does not have this Traffic Class last in the advertised list, receivers MUST re-order it, for the forwarding purpose, as the last Traffic Class, in the ordered list, from the source AS. It is MUST that advertisement from a specific source does not have more than one Traffic classes with element count 0. If there are more than one such Traffic Classes then advertised SLA MUST be ignored. It is okay for SLA message though to have none Traffic Class with element count 0. Classifier Element values in a Traffic Class (optional), 08-bit = type of the Element variable-length = based on type of the Element Shah, et al. Expires September 2, 2012 [Page 8] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Element Types (08-bit) 0x00 = Invalid 0x01 = Reserved 0x02 = IP_DSCP, (length = 08-bits, value = 0..63) 0x03 = MPLS_EXP, (length = 03-bits, value = 0..7) 0x04 = 802_1Q_COS,(length = 03-bits, value = 0..7) 0x05 = 802_1Q_DEI,(length = 01-bit, value = 0..1) 0x06 to 0xff = for future use Traffic Class Service count (for a Traffic Class under definition) 08-bit count of service attributes fields to follow with type/value pair List of service types and relevant values are discussed below 00 = no bounded service (also means Best Effort) Traffic Class Service (optional), 16-bit = type of the field variable-length = based on type of the service - 0x00 = reserved - 0x01 = MINRATE 32-bit, value in unit kbps - 0x02 = MINRATE_BURST 32-bit, value in bytes - 0x03 = MINRATE_IN_PROFILE_MARKING 04-bit, re-mark type 0x00 = Invalid 0x01 = Reserved 0x02 = IP_DSCP 0x03 = MPLS_EXP 0x04 = 802_1Q_COS 0x05 = 802_1Q_DEI 0x06 to 0x0f = for future use 08-bit, value Shah, et al. Expires September 2, 2012 [Page 9] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 - 0x04 = MINRATE_OUT_PROFILE_MARKING 04-bit, re-mark type 0x00 = Invalid 0x01 = Reserved 0x02 = IP_DSCP 0x03 = MPLS_EXP 0x04 = 802_1Q_COS 0x05 = 802_1Q_DEI 0x06 to 0x0f = for future use 08-bit, value - 0x05 = MAXRATE 32-bit, value in unit kbps - 0x06 = MAXRATE_BURST 32-bit, value in bytes - 0x07 = MAXRATE_IN_PROFILE_MARKING 04-bit, re-mark type 0x00 = Invalid 0x01 = Reserved 0x02 = IP_DSCP 0x03 = MPLS_EXP 0x04 = 802_1Q_COS 0x05 = 802_1Q_DEI 0x06 to 0x0f = for future use 08-bit, value - 0x08 = MAXRATE_OUT_PROFILE_MARKING 04-bit, re-mark type 0x00 = Invalid 0x01 = DROP 0x02 = IP_DSCP 0x03 = MPLS_EXP 0x04 = 802_1Q_COS 0x05 = 802_1Q_DEI 0x06 to 0x0f = for future use 08-bit, value In the case when MINRATE_IN_PROFILE_MARKING, MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and MAXRATE_OUT_PROFILE_MARKING all of them are advertised, - MINRATE_IN_PROFILE_MARKING takes highest precedence (that is over MAXRATE_IN_PROFILE_MARKING) Shah, et al. Expires September 2, 2012 [Page 10] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 - MAXRATE_IN_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING - and MAXRATE_OUT_PROFILE_MARKING takes precedence over MINRATE_OUT_PROFILE_MARKING - 0x09 = RELATIVE_PRIORITY 04-bit, priority value lower the value, higher the priority Relative priority indicates scheduling priority. For example voice traffic, that requires lowest latency compare to any other traffic, will have lowest value advertised in relative priority. For two different traffic classification groups where one application group may be considered more important than the other but from scheduling perspective do not require to be distinguish with different priority. Relative priority for those classification groups may be advertised with the same value. - 0x0A = SUB_TRAFFIC_CLASSES variable-length, repeats all content described above from Traffic Class count onwards. For SLAs where a specific Traffic Class may further have differentiated services for sub-group of Classifier Elements, this service type SHOULD be used to further divide Traffic Class in multiple sub-classes. Each sub-class then defined with their own classifier elements and service types. 3. Addition of QoS attribute in a BGP update message QoS attribute to advertise SLA MUST be added by the originator of a BGP update message. Any BGP speaker in the forwarding path of a message MUST NOT insert QoS attribute for the same prefix. These messages in general SHOULD NOT be sent periodically just for the purpose of keep alive. Since SLA changes are in-frequent, some sort of SLA change policy can be considered as a trigger for advertisement. Shah, et al. Expires September 2, 2012 [Page 11] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 For cases where if earlier message has not yet reached to the destination, a re-signaling is required. A new signaling sub-type SLA_REQUEST is required for this purpose. Since BGP messages are considered reliable, discussion of SLA_REQUEST, for this purpose or any other purpose, is considered out of scope of this document. BGP updates triggered as a result of QoS SLA change policy MUST set QoS attribute flag to indicate receiver to not advertise BGP updates further [Note that this flag is to indicate to drop the whole BGP update message, not only QoS attribute]. Alternatively, if receiver is next hop, sender MAY set NO_ADVERTISE community instead to indicate receiver not to advertise BGP update message to other BGP peers beyond next hop. Sender MUST set one of these fields when BGP updates triggered are as a result of QoS SLA change policy. It is RECOMMENDED to always set the QoS attribute flag, to indicate receiver to drop BGP update message, when SLA sub-type message also contains source AS. If source AS is set to 0 then it is RECOMMENDED to use the community attribute NO_ADVERTISE. Community NO_EXPORT MUST be set if QoS SLA not be advertised outside a BGP confederation boundary. For any SLA modification, originator MUST re-advertise entire SLA. There is no provision to advertise partial SLA. To invalidate previously advertised SLA, a message MUST be sent with new SLA advertisement with Traffic Class count as 0. 3.1. SLA Contexts In certain cases, advertisement may be to establish QoS SLA for point to point connection between a specific destination and a specific source. A point to point connection may be a physical link, connecting BGP peers, or may be virtual link (eg. tunnel). A BGP update message, in such cases, with source AS number and NLRI pre-fix of source end-point can uniquely identify physical/virtual link applicable to advertised SLA. In the simplest case where PE and CE are directly connected via a physical link and have only single link between them, CE can uniquely identify forwarding link to PE with AS number of the PE and NLRI prefix being an ip address of PE, to CE (that is next hop ip address from CE to PE). SLA advertised thru BGP update message from PE to CE, with PE's AS number and ip address, establishes SLA context for the aggregate traffic through link CE to PE. SLA advertised thru BGP update message from PE to CE, with PE's AS number and any other pre- fix establishes SLA for that specific pre-fix under CE to PE link. Shah, et al. Expires September 2, 2012 [Page 12] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 4. Processing of QoS attribute at forwarding nodes 4.1. BGP node capable of processing QoS attribute If a BGP node is capable of processing QoS attribute, it optionally MAY process the message. If advertised SLA has list of destination AS, it MAY trim list and so count of destination AS to exclude ones that are not required in further announcement of BGP updates. BGP node MUST drop SLA related sub type from the QoS attribute, if none of the AS from the destination list is in the forwarding path. Rest of the QoS attributes message MAY be forwarded if there exist other sub-types of QoS attribute and forwarding rules meets other sub-types requirements. If there is no other sub-types existing in the QoS attribute message then node MUST drop QoS attribute all together. Rest other attributes and NLRI may be announced further if it meets rules defined by other attributes and BGP protocol. If BGP community, in the update message, is set to NO_ADVERTISE then whole BGP update message MUST not be announced further irrespective of any of the QoS attribute content. If flag in the QoS attribute is set to not announce updates beyond listed destinations then message MUST be dropped if there are no destination left in the list to advertise to. If SLA message is meant to be broadcast then message MUST not be dropped/trimmed. Except extracting entire SLA_ADVERTISE sub-type or trimming the list of destination AS list (this is described more in Section 4), rest all other content MUST not be modified by any intermediate receivers of the message. 4.2. BGP node not capable of processing QoS attribute If BGP node is not capable of processing QoS attribute, it MUST forward attribute message as it is received. 5. Receiver Reception of and reaction to advertised messages are optional for the receiver. Shah, et al. Expires September 2, 2012 [Page 13] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 As described in earlier section, while reacting to SLA advertisement - receiver SHOULD invalidate previous advertised SLA and then if one exists for advertised NLRI. If new advertised SLA update is with non-zero Traffic Class count, new advertised SLA SHOULD be installed. If new advertised SLA update is with Traffic Class count 0, no action is required. - If advertised QoS Attribute is with flag set to indicate to drop this message, receiver MUST drop message if it is the last receiver, in the update path, this message is advertised to. If advertised SLA is for the next hop, in reverse path, the receiver can establish advertised SLA for the whole link, the link could be physical or virtual link, associated with the next hop. If NLRI advertised in update message is not of the next hop, receiver may establish advertised SLA for that specific prefix list under the relevant link. It is completely up to the receiver to decide for which prefix to accept advertised SLA and for which one to not. 5.1. Traffic class mapping It is common where switching/routing method used in 2 different AS could be different. For example, Provider may tunnel Customer's IP traffic thru MPLS cloud. In such cases traffic class definition for QoS services is also different in both AS. For the meaningful use of advertised SLA in such cases, receiver is required to map traffic class from one type to another. In the example given, traffic classification in Customer AS could be IP diffserv based whereas traffic classification in Provider AS could be MPLS EXP based. Thus for advertised MPLS EXP based SLA from PE, CE would require to map traffic class from IP diffserv based to MPLS EXP type. There are well-defined recommendations that exist for traffic class mapping between two technologies. Receiver MAY use those defined recommendations for traffic class mapping or MAY define its own as per its network Traffic Class service definition to map to advertised Traffic Classes. It is completely up to the receiver how to define such traffic class mapping. 6. Deployment Consideration Typical use-case aimed with this proposal is for Provider to advertise contracted SLA to Customer Edge. SLA established between customer and Provider is provisioned by the provider on the PE device (facing Customer Edge). This provisioning, in a form supported by Shah, et al. Expires September 2, 2012 [Page 14] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Provider, is advertised thru proposed BGP QoS attribute to the Customer Edge. Customer may read thru advertised SLA to provision one on the Customer Edge link facing towards PE. Contracted SLA from PE to CE may be full line-rate or sub-rate of a link or finer granular controlled services. SLA is not required to be advertised if the SLA contract is simply a physical link. SLA advertise can be useful when contracted service is sub-rate of a link and/or if for finer granular traffic classes that are controlled. Like voice, video services may be capped to certain rate. _______________ __________ / \ / \ / \ / \ / \ |CustomerSite|-----| Provider | \ C/E P\E / \__________/ \ / \_______________/ AS 3 AS 2 SLA_ADVERTISE: AS2 to AS3 NLRI = PE ip address Another use-case can be to advertise SLA among different network sites within one Enterprise network. In Hub and Spoke deployments, Hub may define SLA for individual spokes and advertise this SLA thru BGP updates. Shah, et al. Expires September 2, 2012 [Page 15] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 AS 2 _______________ ________ / \ / \ __________ / \-----| Spoke2 | / \ / \ \________/ | Hub |-----| Provider | ________ \__________/ \ / / \ \ /-----| Spoke1 | AS 3 \_______________/ \________/ AS 1 SLA_ADVERTISE: AS2 to AS3 NLRI = AS2 tunnel address SLA_ADVERTISE: AS1 to AS3 NLRI = AS2 tunnel address It very well could be possible that AS2 may first learn its SLA with Provider from Provider Edge it is connected to and then advertises same or subset of the SLA to AS3 with AS2 to AS3 tunnel's ip address as NLRI. Deployment options are not limited to involving CEs only. For any contract between Provider to Provider, SLA may be advertised from one PE to another PE also. 7. Acknowledgements Thanks to Fred Baker for his suggestions and thanks to Ken Briley, Rahul Patel and Fred Yip for the review. 8. IANA Considerations This document defines a new BGP attribute. IANA maintains the list of existing BGP attribute types. Proposal is to define a new attribute type code for the QoS attribute. With the proposal, there is a list defined for Traffic Class Elements type and associated Service types. IANA will be required to maintain list of both new types. Shah, et al. Expires September 2, 2012 [Page 16] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Proposed definition of Traffic Class Element Types 0x00 = Invalid 0x01 = Reserved 0x02 = IP_DSCP, (length = 08-bits, value = 0..63) 0x03 = MPLS_EXP, (length = 03-bits, value = 0..7) 0x04 = 802_1Q_COS,(length = 03-bits, value = 0..7) 0x05 = 802_1Q_DEI,(length = 01-bit, value = 0..1) Proposed definition of Traffic Class Service Types 0x00 = reserved 0x01 = MINRATE 0x02 = MINRATE_BURST 0x03 = MINRATE_IN_PROFILE_MARKING 0x04 = MINRATE_OUT_PROFILE_MARKING 0x05 = MAXRATE 0x06 = MAXRATE_BURST 0x07 = MAXRATE_IN_PROFILE_MARKING 0x08 = MAXRATE_OUT_PROFILE_MARKING 0x09 = RELATIVE_PRIORITY 0x0A = SUB_TRAFFIC_CLASSES 9. Security Considerations There is a potential for mis-behaved AS to advertise wrong SLA, stealing identity of another AS. This resembles to problems already identified and resolved, in the routing world, thru reverse path forwarding check. One proposal, inline to RPF, to resolve such threats is to have each BGP speaker node, in the forwarding path, perform reverse path check on source AS. Since we expect these messages to originate and distributed in the managed network, there should not be any risks for identity theft. Thus reverse path check is not considered in this proposal nor have we considered any alternates. Such solutions can be explored later if any such need. 10. Normative References [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Shah, et al. Expires September 2, 2012 [Page 17] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001. Authors' Addresses Shitanshu Shah Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: svshah@cisco.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: keyupate@cisco.com Shah, et al. Expires September 2, 2012 [Page 18] Internet-Draft BGP attribute for QoS SLA advertisement March 2012 Sandeep Bajaj Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US Email: sbajaj@juniper.net Shah, et al. Expires September 2, 2012 [Page 19]