Inter-domain SLA Exchange
draft-svshah-interdomain-sla-exchange-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Shitanshu Shah , Keyur Patel , Sandeep Bajaj | ||
| Last updated | 2012-05-29 | ||
| Replaces | draft-svshah-bgp-qos-sla-attribute | ||
| Replaced by | draft-ietf-idr-sla-exchange, draft-ietf-idr-sla-exchange, draft-ietf-idr-sla-exchange | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-svshah-interdomain-sla-exchange-00
Network Working Group S. Shah
Internet-Draft K. Patel
Intended status: Standards Track Cisco Systems
Expires: November 30, 2012 S. Bajaj
Juniper Networks
May 29, 2012
Inter-domain SLA Exchange
draft-svshah-interdomain-sla-exchange-00
Abstract
Network administrators typically provision QoS policies for their
application traffic (such as voice, video etc) based on SLAs with
their providers and translating those SLAs to vendor specific
provisioning language. Both learning of SLA, either thru SLA
documents or via some other out of band method, and translating them
to vendor specific provisioning language is a complex, many times
manual, process and prone to errors. This draft proposes an in-band
method of SLA signaling which 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 November 30, 2012.
Copyright Notice
Shah, et al. Expires November 30, 2012 [Page 1]
Internet-Draft Inter-domain SLA Exchange attribute May 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 November 30, 2012 [Page 2]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 5
3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 6
4. Originating SLA notifications . . . . . . . . . . . . . . . . 14
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. SLA advertisement for point to point connection . . . 15
4.1.2. SLA advertisement for destination AS multiple hops
away . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. SLA Attribute handling at forwarding nodes . . . . . . . . . . 16
5.1. BGP node capable of processing QoS attribute . . . . . . . 16
5.2. BGP node not capable of processing QoS attribute . . . . . 16
5.3. Aggregator . . . . . . . . . . . . . . . . . . . . . . . . 16
6. SLA attribute handling at Receiver . . . . . . . . . . . . . . 17
6.1. Traffic class mapping . . . . . . . . . . . . . . . . . . 17
7. Deployment Consideration . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Shah, et al. Expires November 30, 2012 [Page 3]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
1. Introduction
Typically there is a contractual service-level-agreement (SLA)
between Customer's Edge (CE) and Provider's Edge (PE) or between one
Provider's Edge to another Provider's Edge. This contractual
agreement defines the nature of the various traffic classes (i.e.
traffic match conditions) and services needed for each traffic class.
The contract may exist at different levels of traffic granularity.
The contract could be full line-rate or sub rate for aggregate
traffic. Or it could be even 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.
In today's deployment, Customer Edge administrator will have to know
such established SLAs and translate them in QoS policies on the
router using router specific provisioning language. Such out of band
learning of SLA and provisioning them is complex, error-prone.
To over-come complexities described, 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"]. the 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.
The details of SLAs are independent of BGP protocol and are specific
to the granularity of traffic classes and their subsequent treatment.
Though we find BGP as a suitable transport for inter-domain SLA
exchange for the following reasons:
- The most common use-case of SLA exchange is across Autonomous
Systems defined by BGP
- There is no other suitable protocol available today for SLA
exchange
- BGP updates already advertise specific set of prefixes (flow
or flow-group). Other QoS attributes, apart from the use of
SLA advertisement, can be added to these updates in the future
Shah, et al. Expires November 30, 2012 [Page 4]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
We propose QoS as an optional transitive attribute, keeping SLA
advertisement as one of the sub-types of QoS attribute. This is to
keep QoS attribute open for extensions, in future, beyond SLA
advertisement.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
3. QoS Attribute Definition
The QoS Attribute proposed, in BGP, is an optional transitive
attribute (attribute type code to be assigned by IANA). SLA is
defined as one of the sub-types in the QoS attribute.
Shah, et al. Expires November 30, 2012 [Page 5]
Internet-Draft Inter-domain SLA Exchange attribute May 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 QoS
Attribute specific flags
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
3.1. SLA, QoS attribute sub-type, Definition
The value field of the QoS Attribute contains further TLVs, following
QoS Attribute flags described in the previous section. One of the
TLVs that we define is a tuple of (SLA sub-type, Length, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Attr flags| subType | sub type Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Shah, et al. Expires November 30, 2012 [Page 6]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
subType - 8 bits
0x00 = reserved
0x01 = SLA
0x02 - 0x0f = for future use
SLA sub-type specific value field details 1) sender and receiver(s)
and 2) SLA parameters. SLA Parameters include SLA event type
(eg. Advertise, Request) and content associated to that event type.
The format of SLA message is,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional advertiserid total len| Advertiser id TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit destination AS count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable list of destination AS |
~ .... ~
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | SLA id | SLA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content as per SLA Event |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. 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
Shah, et al. Expires November 30, 2012 [Page 7]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
In general any additional qualifier for an advertiser is not
required. The SLA definition is in the context of pre-fix
advertised in the NLRI definition. The exception is where a BGP
speaker, in the middle of an update path to the destination AS,
aggregates pre-fixes. We will refer this middle BGP speaker,that
aggregates routes, as an Aggregator. Aggregator is then required
to insert original NLRI details in the optional advertiser field
Optional Advertiser id TLV
4-bit type
0x0 = reserved
0x1 = ORIGIN_NLRI, variable length
0x2 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]
....
SLA Event Type
4-bits
0x0 = reserved
0x1 = ADVERTISE
0x2 = REQUEST
0x3 to 0xf, for future use
SLA Id
16-bit identifier unique within the scope of source AS
The significance of an SLA identifier is in the context of the
source that is advertising SLA. SLA identifier is not globally
unique but it MUST be unique in the context of the source
AS (advertiser).
The SLA content is optional for an advertised SLA id. If SLA
content does not exist in BGP update messages with advertised
Shah, et al. Expires November 30, 2012 [Page 8]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
SLA attribute then receiver MUST inherit prior advertised SLA
content for the same SLA id from the same Source AS.
If advertised SLA id is different from earlier advertised one,
for the same pre-fix, previous SLA MUST be replaced with the new
advertised one.
SLA is aggregate for all the traffic to pre-fixes that share
same source AS and SLA id.
SLA Length
12-bits
The format of SLA ADVERTISE event is,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dir| Traffic Class count | Class Desc Len| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Traffic Class Description ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Traffic Class Elements count/values ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Count| service type/value pair |
+-+-+-+-+-+-+-+-+ ~
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Repeat from Traffic Class Description for next Traffic Class ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Repeat from direction for SLA in the other direction ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Direction
02-bit for incoming or outgoing traffic,
0x0 = reserved
0x1 = incoming, from destination AS towards source AS
Shah, et al. Expires November 30, 2012 [Page 9]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
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
Element Types (08-bit)
0x00 = Invalid
0x01 = Reserved
Shah, et al. Expires November 30, 2012 [Page 10]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
0x02 = IP_DSCP, (length = 08-bits, value = 0..63)
0x03 = MPLS_TC, (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_TC
0x04 = 802_1Q_COS
0x05 = 802_1Q_DEI
0x06 to 0x0f = for future use
08-bit, value
- 0x04 = MINRATE_OUT_PROFILE_MARKING
Shah, et al. Expires November 30, 2012 [Page 11]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
04-bit, re-mark type
0x00 = Invalid
0x01 = Reserved
0x02 = IP_DSCP
0x03 = MPLS_TC
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_TC
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_TC
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 November 30, 2012 [Page 12]
Internet-Draft Inter-domain SLA Exchange attribute May 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 = DROP_THRESHOLD
03-bit count of drop-priority fields to follow with
(type,value, unit,value) tuple
04-bit, drop priority type
0x00 = Invalid
0x01 = None
0x02 = IP_DSCP
0x03 = MPLS_EXP
0x04 = 802_1Q_COS
0x05 = 802_1Q_DEI
0x06 to 0x0f = for future use
08-bit, drop priority type value
04-bit, unit type
0x00 = reserved
0x01 = PACKETS
0x02 = BYTES
0x03 = TIME_US
0x04 = PERCENT
0x06 to 0x0f = for future use
08-bit, drop threshold value as per unit type
- 0x0A = 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.
Shah, et al. Expires November 30, 2012 [Page 13]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
- 0x0B = 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.
4. Originating SLA notifications
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.
SLA 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 policy change can be considered as a trigger for the
advertisement.
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.
4.1. SLA Contexts
In certain cases, the advertisement may be to establish SLA for
aggregate traffic on a 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 a 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 and so establishes advertised SLA's context for
aggregate traffic for that point to point link.
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 that is subset of
Shah, et al. Expires November 30, 2012 [Page 14]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
traffic under CE to PE link.
Even though this example is in the context of ip prefix, SLA exchange
does not have to be limited to IPv4 family only. SLA advertisement
is generic to all forms of NLRI types that are supported by the BGP
protocol specification (like IPV4, VPN-IPV4).
4.1.1. SLA advertisement for point to point connection
When SLA messages are intended to be advertised for the point to
point connection (physical or logical), the message is destined for
the next hop and advertised message is in the context of the pre-fix
of the source end-point of the point to point connection.
The destination AS number set to, within QoS SLA attribute, typically
is of the neighbor BGP speaker's. Alternatively, originator MAY not
encode source/destination AS numbers (that is source AS set to 0 and
destination AS count set to 0), in the QoS attribute, and simply
advertise update with NO_ADVERTISE community set. Later method can
be used only if BGP update message is triggered to advertise SLA only
because of SLA policy change event where purpose is not to advertise/
propagate pre-fixes.
4.1.2. SLA advertisement for destination AS multiple hops away
When SLA messages are to be advertised beyond next hop, value of
source AS, in the QoS attribute, MUST be set by the originator of the
update message. If such update is meant to be for specific list of
AS(es) as receiver then list of destination AS MUST be populated in
the QoS attribute message to avoid flooding of the QoS attribute data
in the network beyond those destinations.
When a new pre-fix is added in the AS, AS for which SLA has already
been advertised before for other existing pre-fixes, then to
advertise that new pre-fix to be part of earlier advertised SLA, a
trigger of new BGP update message with QoS attribute containing SLA
id is sufficient. Update message does not require to have whole SLA
content.
When BGP update messages are triggered as a result of SLA policy
change and so for the purpose of SLA exchange only, forwarding BGP
update messages beyond intended receivers are not necessary. Highest
order bit in the QoS Attribute flag MUST be set to suggest receiver
to drop entire BGP update message [Note that it is an indication to
drop entire update message, not only QoS attribute], after all
intended receivers have processed it. If update message contains
Shah, et al. Expires November 30, 2012 [Page 15]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
list of destination of AS then message MUST be dropped only after all
intended receivers (destinations) have received it.
5. SLA Attribute handling at forwarding nodes
5.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 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. However, If SLA
message is meant to be broadcast then message MUST not be dropped/
trimmed.
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.
Except extracting entire SLA sub-type of the QoS attribute, trimming
the list of destination AS list and inserting NLRI at Aggregator
node, rest all other content MUST not be modified by any intermediate
receivers of the message.
5.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.3. Aggregator
It is RECOMMENDED to not aggregate pre-fixes from BGP update messages
that contain QoS SLA attribute. If Aggregator MUST aggregate pre-
fixes then it MUST copy QoS SLA attribute in new aggregated BGP
update message. At the same time, it MUST also insert NLRI, from the
Shah, et al. Expires November 30, 2012 [Page 16]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
original update message, as an optional advertiser id to go along
with source AS in the QoS attribute.
To support SLA exchange multiple hops away in the path that has one
of the forwarding node in the path acting as Aggregator, it is
required Aggregator node to be capable of processing QoS attribute.
6. SLA attribute handling at Receiver
Reception of and reaction to advertised messages are optional for the
receiver.
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 from 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 prefixes to accept advertised SLA and for which ones to not.
For cases where if earlier message has not yet reached to the
intended receiver, a re-signaling is required. A signaling event
REQUEST is required, for this purpose, to be triggered by intended
receiver. Since BGP messages are considered reliable, discussion of
REQUEST, for this purpose or any other purpose, is considered out of
the scope of this document.
6.1. Traffic class mapping
It is common that switching/routing technologies 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.
Shah, et al. Expires November 30, 2012 [Page 17]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
In the example given, traffic classification in Customer AS could be
IP Diffserv based whereas traffic classification in Provider AS could
be MPLS TC based. Thus for advertised MPLS TC based SLA from PE, CE
would require to map traffic class from IP Diffserv based to MPLS TC
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.
7. 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
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
Shah, et al. Expires November 30, 2012 [Page 18]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
sites within one Enterprise network. In Hub and Spoke deployments,
Hub may define SLA for individual spokes and advertise this SLA thru
BGP updates.
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.
8. Acknowledgements
Thanks to Fred Baker for his suggestions and to Ken Briley, Rahul
Patel, Fred Yip and Lou Berger for the review. Thanks to Bertrand
Duvivier for his valuable contributions to help make subsequent
revision better.
9. IANA Considerations
This document defines a new BGP attribute. IANA maintains the list
of existing BGP attribute types. Proposal is to define a new
Shah, et al. Expires November 30, 2012 [Page 19]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
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.
Proposed definition of Traffic Class Element Types
0x00 = Invalid
0x01 = Reserved
0x02 = IP_DSCP, (length = 08-bits, value = 0..63)
0x03 = MPLS_TC, (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 = DROP_THRESHOLD
0x0A = RELATIVE_PRIORITY
0x0B = SUB_TRAFFIC_CLASSES
Proposed definition of Unit Types
0x00 = reserved
0x01 = PACKETS
0x02 = BYTES
0x03 = TIME_US
10. 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.
Shah, et al. Expires November 30, 2012 [Page 20]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
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.
11. Normative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
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.
Authors' Addresses
Shitanshu Shah
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Email: svshah@cisco.com
Shah, et al. Expires November 30, 2012 [Page 21]
Internet-Draft Inter-domain SLA Exchange attribute May 2012
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Email: keyupate@cisco.com
Sandeep Bajaj
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Email: sbajaj@juniper.net
Shah, et al. Expires November 30, 2012 [Page 22]