draft-ietf-idr-sla-exchange-00.txt   draft-ietf-idr-sla-exchange-01.txt 
Network Working Group S. Shah Network Working Group S. Shah
Internet-Draft K. Patel Internet-Draft K. Patel
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 7, 2013 S. Bajaj Expires: December 29, 2013 S. Bajaj
Juniper Networks Juniper Networks
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
France Telecom France Telecom
Jan 03, 2013 Jun 27, 2013
Inter-domain SLA Exchange Inter-domain SLA Exchange
draft-ietf-idr-sla-exchange-00 draft-ietf-idr-sla-exchange-01
Abstract Abstract
Network administrators typically provision QoS policies for their Network administrators typically provision QoS (Quality of Service)
application traffic (such as voice, video) based on SLAs negotiated policies for their application traffic (such as voice, video) based
with their providers, and translate those SLAs to vendor specific on SLAs (Service Level Agreements) negotiated with their providers,
configuration language. Both learning of SLA, either thru SLA and translate those SLAs to vendor specific configuration language.
documents or via some other out-of-band method, and translating them Both learning of SLA, either thru SLA documents or via some other
to vendor specific configuration language is a complex, many times out-of-band method, and translating them to vendor specific
manual, process and prone to errors. This document proposes an in- configuration language is a complex, many times manual, process and
band method of SLA signaling which can help to simplify some of the prone to errors. This document proposes an in-band method of SLA
complexities. signaling which can help to simplify some of the complexities.
This document defines an operational transitive attribute to signal This document defines an operational transitive attribute to signal
SLA details in-band, across administrative boundaries (considered as SLA details in-band, across administrative boundaries (considered as
Autonomous Systems (AS)), and thus simplify/speed-up some of the Autonomous Systems (AS)), thus simplify and speed-up some of the
complex tasks. complex provisioning tasks.
Though the use-case with the proposed attribute is explicitly defined Though the use case with the proposed attribute is explicitly defined
in this document, purpose of this attribute is not limited to this in this document, purpose of this attribute is not limited to this
use-case only. use case only.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 7, 2013. This Internet-Draft will expire on December 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 6 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 6
3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 6 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 7
4. Originating SLA Notification . . . . . . . . . . . . . . . . . 14 4. Originating SLA Notification . . . . . . . . . . . . . . . . . 16
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. SLA advertisement for point to point connection . . . 15 4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16
4.1.2. SLA advertisement for destination AS multiple hops 4.1.2. SLA Advertisement for Destination AS Multiple Hops
away . . . . . . . . . . . . . . . . . . . . . . . . . 15 Away . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. SLA Attribute handling at forwarding nodes . . . . . . . . . . 16 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . . 17
5.1. BGP node capable of processing QoS attribute . . . . . . . 16 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . . 17
5.2. BGP node not capable of processing QoS attribute . . . . . 17 5.2. BGP Node not Capable of Processing QoS Attribute . . . . . 18
5.3. Aggregator . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Aggregator . . . . . . . . . . . . . . . . . . . . . . . . 18
6. SLA attribute handling at Receiver . . . . . . . . . . . . . . 17 6. SLA Attribute Handling at Receiver . . . . . . . . . . . . . . 18
6.1. Traffic class mapping . . . . . . . . . . . . . . . . . . 18 6.1. Traffic Class Mapping . . . . . . . . . . . . . . . . . . 19
7. Deployment Consideration . . . . . . . . . . . . . . . . . . . 18 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Typically there is a contractual Service Level Agreement (SLA) Typically there is a contractual Service Level Agreement (SLA)
negotiated between Customer and Provider or between one Provider to negotiated between Customer and Provider or between one Provider to
another Provider [CPP]. This contractual agreement defines the another Provider [CPP]. This contractual agreement defines the
nature of the various traffic classes (i.e. traffic match conditions) nature of the various traffic classes (i.e., traffic match
and services needed for each traffic class. The contract may exist conditions) and services needed for each traffic class. The contract
at different levels of traffic granularity. The contract could be may exist at different levels of traffic granularity. The contract
full line-rate or sub rate for aggregate traffic. Or it could be could be full line-rate or sub rate for aggregate traffic or it could
even finer granular traffic distinction with services defined for be even finer granular traffic distinction with services defined for
standard code-points or for specific set of prefix or for set of standard code-points or for specific set of prefix or for set of
well-known application types. well-known application types.
Once the SLA is negotiated, it needs to be translated into enforcing Once the SLA is negotiated, it needs to be translated into enforcing
configuration data and policies on the Provider's Edge (PE) as well configuration data and policies on the Provider's Edge (PE) as well
as on the Customer's Edge (CE). At the Customer, a person as on the Customer's Edge (CE). At the Customer side, a person
administering the CE device may be a different person, or even a administering the CE device may be a different person, or even a
different department, from the ones negotiating SLA contracts with different department, from the ones negotiating SLA contracts with
the Provider and thus an administrator at the CE first requires to the Provider and thus an administrator at the CE first requires to
manually learn negotiated SLA, thru SLA documents or via some other manually learn negotiated SLA, thru SLA documents or via some other
off-band method. In a subsequent step an administrator requires to off-band method. In a subsequent step an administrator requires to
translate SLA to QoS policies using router (vendor) specific translate SLA to QoS policies using router (vendor) specific
provisioning language. In a multi-vendor environment, translating provisioning language. In a multi-vendor environment, translating
the SLA into technology-specific configuration and then enforcing the SLA into technology-specific configuration and then enforcing
that configuration requires to consider specificities of each vendor. that configuration requires to consider specificities of each vendor.
There does not exist any standard protocol to translate SLA There does not exist any standard protocol to translate SLA
agreements into technical clauses and configurations and thus both agreements into technical clauses and configurations and thus both
the steps of out of band learning of negotiated SLA and provisioning the steps of out of band learning of negotiated SLA and provisioning
them in a vendor specific language can be complex and error-prone. them in a vendor specific language can be complex and error-prone.
For an example for voice service, the Provider may negotiate service As an example for voice service, the Provider may negotiate service
for such traffic thru EF code-point in Diffserv networks. for such traffic thru use of EF code-point in Diffserv-enabled
Administrator at the CE not only will have to know that Provider's [RFC2475] networks. Administrator at the CE side not only will have
service for voice traffic is EF based but will also have to implement to know that Provider's service for voice traffic is EF-based but
DSCP EF classification rule along with Low Latency Service rule as will also have to implement DSCP EF classification rule along with
per vendor's provisioning language. Low Latency Service rule as per vendor's provisioning language.
Given the Provider also maintains established contracts, which very Given the Provider also maintains established contracts, which very
well may even be enforced at the PE, an in-band method of signaling well may even be enforced at the PE, an in-band method of signaling
it from the PE to the CE can help eliminate manual administrative it from the PE to the CE can help eliminate manual administrative
process described above. Provider may have SLA negotiated with the process, at the CE, described above. Provider may have SLA
Customer via some defined off-band method. Once negotiated, the negotiated with the Customer via some defined off-band method (could
Provider may translate that SLA in networking language on the PE be specifics defined by Provider or could be based on some protocols
(this process remains same as is done today). This SLA instance then like [CPNP]), orthogonal to actual SLA exchange proposal described in
can be signaled to the CE via some in-band protocol exchange. In this document. Once negotiated, the Provider may translate that SLA
reaction to that message, receiver CE router may automatically in networking language on the PE (this process remains same as is
translate that to relevant QoS policy definition on the box. This done today). This SLA instance then can be signaled to the CE via
in-band signaling method helps eliminate manual complex process some in-band protocol exchange. In reaction to that message,
required by administrator at the CE. Taking same voice service as an receiver CE router may automatically translate that to relevant QoS
example, given Provider already may provision definition of EF code- policy definition on the box. This in-band signaling method helps
point for such, signaling this code-point traffic class from PE to CE eliminate manual complex process required by administrator at the CE.
along with low latency service definition, omits administrator at the Taking same voice service as an example, a given Provider might
CE to worry about such translation. already provision definition of EF code-point for such traffic.
Signaling EF code-point for this traffic class along with signaling
low latency service definition, would avoid manual administration at
the CE.
For in-band signaling, we propose use of BGP transport. The details For in-band signaling, we propose to use BGP as a transport. The
of SLAs are independent of BGP and are specific to the granularity of details of SLAs are independent of BGP and are specific to the
traffic classes and their subsequent treatment. Though we find BGP granularity of traffic classes and their subsequent treatment.
as a suitable transport for inter-domain SLA exchange for the Though we find BGP as a suitable transport for inter-domain SLA
following reasons: exchange for the following reasons:
- The most common use-case of SLA exchange is across Autonomous - The most common use case of SLA exchange is across Autonomous
Systems. And BGP is the most suitable protocol for any Systems. And BGP is the most suitable protocol for any inter-
inter-domain exchange domain exchange [RFC4271][RFC4364]
- There is no other suitable protocol available today for SLA - There is no other suitable protocol available today for SLA
exchange exchange
- BGP updates already advertise specific set of prefixes (flow - BGP updates already advertise specific set of prefixes (flow
or flow-group). Other QoS-related attributes, apart from the or flow-group). Other QoS-related attributes, apart from the
the use of SLA advertisement, can be added to these updates the use of SLA advertisement, can be added to these updates
in the future in the future
The proposal is a definition of a new BGP attribute to advertise/ The proposal is to define a new BGP attribute to advertise/learn SLA
learn SLA details in-band. The BGP attribute proposed, in this details in-band. The proposed attribute is intended to advertise SLA
document, is intended to advertise SLA from one AS to a list of from one AS to a list of interested ASes. QoS services advertised
interested AS. QoS services advertised could be for the incoming could be for the incoming traffic to the AS community, that is
traffic to the AS community, that is advertising SLA or could be for advertising SLA or could be for the outgoing traffic from the
the outgoing traffic from the advertiser or could be for both advertiser or could be for both directions. Reception of and
directions. Reception of and reaction to advertised SLAs are reaction to advertised SLAs are optional for the receiver.
optional for the receiver.
The aim with the signaling of this attribute, across administrative The aim with the signaling of this attribute, across administrative
boundaries, is to help network administrators speed up and simplify boundaries, is to help network administrators speed up and simplify
QoS provisioning with automatic learning of SLAs and thus avoiding QoS provisioning with automatic learning of SLAs and thus avoiding
complexities and possible errors with manual learning. complexities and possible errors with manual learning.
We propose QoS as an optional transitive attribute, keeping SLA We propose QoS as an optional transitive attribute, keeping SLA
advertisement and discovery (request) as one of the sub-types of QoS advertisement and discovery (request) as one of the sub-types of QoS
attribute. This is to keep QoS attribute open for extensions, in attribute. This is to keep QoS attribute open for extensions, in
future, for other SLA specific requirements or even beyond SLA future, for other SLA specific requirements or even beyond SLA
specific needs. For example, SLA Negotiation and Assurance is out of specific needs. For example, SLA Negotiation and Assurance is out of
scope of this document which can be envisioned as another sub-type. scope of this document which can be envisioned as another sub-type.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119. document are to be interpreted as described in [RFC2119].
3. QoS Attribute Definition 3. QoS Attribute Definition
The QoS Attribute proposed, in BGP, is an optional transitive The QoS Attribute proposed here is an optional transitive attribute
attribute (attribute type code to be assigned by IANA). SLA is (attribute type code to be assigned by IANA). SLA is defined as one
defined as one of the sub-types in the QoS attribute. of the sub-types in the QoS attribute.
0 1 2 3 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 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 | | | Attr flag | QoS Attr type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| QoS Attr length/Value | | QoS Attr length/Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Attribute flags Attribute flags
highest order bit (bit 0) - highest order bit (bit 0) -
MUST be set to 1, since this is an optional attribute MUST be set to 1, since this is an optional attribute
2nd higher order bit (bit 1) - 2nd higher order bit (bit 1) -
MUST be set to 1, since this is a transitive attribute MUST be set to 1, since this is a transitive attribute
The first octet in the Value field of the QoS attribute is QoS The first octet in the Value field of the QoS attribute is QoS
Attribute specific flags attribute specific flags
highest order bit (bit 0) - highest order bit (bit 0) -
It defines if update message MUST be dropped (if set to It defines if update message MUST be dropped (if set to 1)
1) without updating routing data-base, when this is the without updating routing information base, when this is the
last BGP receiver from the list of AS this attribute is last BGP receiver from the list of AS this attribute is
announced to, or MUST announce (if set to 0) further to announced to, or MUST announce (if set to 0) further to BGP
BGP peers peers
The purpose of this bit is discussed further in The purpose of this bit is discussed further in subsequent
subsequent sections. sections.
Remaining bits are currently unused and MUST be set to 0 Remaining bits are currently unused and MUST be set to 0
3.1. SLA, QoS attribute sub-type, Definition 3.1. SLA, QoS attribute sub-type, Definition
The value field of the QoS Attribute contains further TLVs, following The value field of the QoS Attribute contains further TLVs, following
QoS Attribute flags described in the previous section. One of the QoS Attribute flags described in the previous section. One of the
TLVs that we define is a tuple of (SLA sub-type, Length, Value) TLVs that we define is a tuple of (SLA sub-type, Length, Value)
0 1 2 3 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 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 | | QoS Attr flags| subType | sub type Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
subType - 8 bits subType - 8 bits
0x00 = reserved 0x00 = reserved
0x01 = SLA 0x01 = SLA
0x02 - 0x0f = for future use 0x02 - 0x0f = for future use
SLA sub-type specific value field details 1) sender and receiver(s) SLA sub-type specific value field details 1) sender and receiver(s)
and 2) SLA parameters. SLA Parameters include SLA event type (such and 2) SLA parameters. SLA Parameters include SLA event type (such
as Advertise, Request) and content associated to that event type. as Advertise, Request) and content associated to that event type.
The format of SLA message is,
The format of SLA message is,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit source AS (Advertiser) | | 32-bit source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional advertiserid total len| Advertiser id TLVs | |Optional advertiserid total len| Advertiser id TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| | | |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit destination AS count | | 32-bit destination AS count |
skipping to change at page 7, line 47 skipping to change at page 8, line 5
~ .... ~ ~ .... ~
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event | SLA id | SLA length | | Event | SLA id | SLA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content as per SLA Event | | Content as per SLA Event |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source AS Source AS
32-bit source AS number. This is the AS that is advertising SLA 32-bit source AS number. This is the AS that is advertising SLA
0 = ignore Source and Destination AS list from this Value field. 0 = ignore Source and Destination AS list from this Value field.
Instead refer to Source and Destination AS as defined by BGP Instead refer to Source and Destination AS as defined by BGP
message. SLA sub-type specifics, from the QoS attribute, message. SLA sub-type specifics, from the QoS attribute,
MUST be removed by the receiver in such case. MUST be removed by the receiver in such case.
Optional advertiser id total len Optional advertiser id total len
16-bit Source address identifier (optional). 16-bit Source address identifier (optional).
0 = No optional identifier 0 = No optional identifier
In general any additional qualifier for an advertiser is not In general any additional qualifier for an advertiser is not
required. The SLA definition is in the context of prefix required. The SLA definition is in the context of prefix
advertised in the NLRI definition. The exception is where a BGP advertised in the NLRI definition. The exception is where a BGP
speaker, in the middle of an update path to the destination AS, speaker, in the middle of an update path to the destination AS,
aggregates prefixes. We will refer this middle BGP speaker,that aggregates prefixes. We will refer this middle BGP speaker,that
aggregates routes, as an Aggregator. Aggregator is then required aggregates routes, as an Aggregator. Aggregator is then required
to insert original NLRI details in the optional advertiser field to insert original NLRI details in the optional advertiser field
Optional Advertiser id TLV Optional Advertiser id TLV
4-bit type 4-bit type
0x0 = reserved 0x0 = reserved
0x1 = ORIGIN_NLRI, variable length 0x1 = ORIGIN_NLRI, variable length
0x2 to 0xf = for future use, 0x2 to 0xf = for future use,
Destination AS count Destination AS count
32-bit destination AS count to take variable length AS list. 32-bit destination AS count to take variable length AS list.
This count has no functional value when Source AS is 0 This count has no functional value when Source AS is 0
0 = broadcast 0 = broadcast
Destination AS list Destination AS list
32-bit destination AS number, this field is omitted if broadcast 32-bit destination AS number, this field is omitted if broadcast
.... ....
.... [as many as AS count] .... [as many as AS count]
....
SLA Event Type SLA Event Type
4-bits 4-bits
0x0 = reserved 0x0 = reserved
0x1 = ADVERTISE 0x1 = ADVERTISE
0x2 = REQUEST 0x2 = REQUEST
0x3 to 0xf, for future use 0x3 to 0xf, for future use
SLA Id SLA Id
16-bit identifier unique within the scope of source AS 16-bit identifier unique within the scope of source AS
The significance of an SLA identifier is in the context of the The significance of an SLA identifier is in the context of the
source that is advertising SLA. SLA identifier is not globally source that is advertising SLA. SLA identifier is not globally
unique but it MUST be unique in the context of the source unique but it MUST be unique in the context of the source
AS (advertiser). AS (advertiser).
The SLA content is optional for an advertised SLA id. If SLA The SLA content is optional for an advertised SLA id. If SLA
content does not exist in BGP update messages with advertised content does not exist in BGP update messages with advertised
SLA attribute then receiver MUST inherit prior advertised SLA SLA attribute then receiver MUST inherit prior advertised SLA
content for the same SLA id from the same Source AS. content for the same SLA id from the same Source AS.
If advertised SLA id is different from earlier advertised one, If advertised SLA id is different from earlier advertised one,
for the same prefix, previous SLA MUST be replaced with the new for the same prefix, previous SLA MUST be replaced with the new
advertised one. advertised one.
SLA is aggregate for all the traffic to prefixes that share SLA is aggregate for all the traffic to prefixes that share
same source AS and SLA id. same source AS and SLA id.
SLA Length SLA Length
12-bits 12-bits
The format of SLA ADVERTISE event is, The format of SLA ADVERTISE event message is,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dir| Traffic Class count | Class Desc Len| | |dir| Traffic Class count | Class Desc Len| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Description ~ ~ Traffic Class Description ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Traffic Class Elements count/values ~ ~ Traffic Class Elements count/values ~
skipping to change at page 10, line 9 skipping to change at page 10, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Repeat from Traffic Class Description for next Traffic Class ~ ~ Repeat from Traffic Class Description for next Traffic Class ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Repeat from direction for SLA in the other direction ~ ~ Repeat from direction for SLA in the other direction ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Direction Direction
02-bit for incoming or outgoing traffic, 02-bit for incoming or outgoing traffic,
0x0 = reserved 0x0 = reserved
0x1 = incoming, from destination AS towards source AS 0x1 = incoming, from destination AS towards source AS
0x2 = outgoing, from source AS towards destination AS 0x2 = outgoing, from source AS towards destination AS
0x3 = for future use 0x3 = for future use
Traffic Class count (Classifier Groups count) Traffic Class count (Classifier Groups count)
16-bit, count of number of classifier groups 16-bit, count of number of classifier groups
00 = Advertisement to invalidate previous advertised SLA if was 00 = Advertisement to invalidate previous advertised SLA if was
any any
Traffic Class Descr Length Traffic Class Descr Length
08-bit, size of the length 08-bit, size of the length
0 = No description 0 = No description
Traffic Class Description Traffic Class Description
Ascii Description of the Traffic Class Ascii Description of the Traffic Class
Traffic Class Elements Count in a Traffic Class, Traffic Class Elements Count in a Traffic Class,
08-bit count of classifier elements in a specific Traffic Class 08-bit count of classifier elements in a specific Traffic Class
00 = this has relative definition. It means classify rest all 00 = this has relative definition. It means classify rest all
traffic that is not classified via earlier described traffic that is not classified via earlier described
Traffic Classes. Traffic Classes.
It is RECOMMENDED to have 0 elements Traffic Class It is RECOMMENDED to have 0 elements Traffic Class
definition last in the ordered list.If Advertised SLA does definition last in the ordered list.If Advertised SLA does
not have this Traffic Class last in the advertised list, not have this Traffic Class last in the advertised list,
receivers MUST re-order it, for the forwarding purpose, as receivers MUST re-order it, for the forwarding purpose, as
the last Traffic Class, in the ordered list, from the the last Traffic Class, in the ordered list, from the
source AS. It is MUST that advertisement from a specific source AS. It is MUST that advertisement from a specific
source does not have more than one Traffic classes with source does not have more than one Traffic classes with
element count 0. If there are more than one such Traffic element count 0. If there are more than one such Traffic
Classes then advertised SLA MUST be ignored. It is okay Classes then advertised SLA MUST be ignored. It is okay
for SLA message though to have none Traffic Class with for SLA message though to have none Traffic Class with
element count 0. element count 0.
Classifier Element values in a Traffic Class (optional), Classifier Element values in a Traffic Class (optional),
08-bit = type of the Element 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element variable-length = based on type of the Element
Given IPFIX [RFC5102] has well defined identifier set for a
large number of packet attributes, IPFIX IANA registry is
"https://www.ietf.org/assignments/ipfix" chosen to specify
packet classification attributes. However, since not all
identifiers from IPFIX would be applicable to this proposal,
only a limited set identified here can be supported by BGP
SLA exchange. Any new element identifier, in future, added
to the IPFIX IANA registry does not automatically mean
supported for this proposal.
Element Types (08-bit) +----+----------------------------+
0x00 = Invalid | ID | Name |
0x01 = Reserved +----+----------------------------+
0x02 = IP_DSCP, (length = 06-bits, value = 0..63) |195 | ipDiffServCodePoint |
0x03 = MPLS_TC, (length = 03-bits, value = 0..7) |203 | mplsTopLabelExp |
0x04 = 802_1Q_COS,(length = 03-bits, value = 0..7) |244 | dot1qPriority |
0x05 = 802_1Q_DEI,(length = 01-bit, value = 0..1) | 8 | sourceIPv4Address |
0x06 = PHB_ID, (length = 12-bits, value = 0..4095) | 27 | sourceIPv6Address |
0x07 to 0xff = for future use | 9 | sourceIPv4PrefixLength |
| 29 | sourceIPv6PrefixLength |
| 44 | sourceIPv4Prefix |
|170 | sourceIPv6Prefix |
| 12 | destinationIPv4Address |
| 28 | destinationIPv6Address |
| 13 | destinationIPv4PrefixLength|
| 30 | destinationIPv6PrefixLength|
| 45 | destinationIPv4Prefix |
|169 | destinationIPv6Prefix |
| 4 | protocolIdentifier |
| 7 | sourceTransportPort |
| 11 | destinationTransportPort |
+----+----------------------------+
Traffic Class Service count (for a Traffic Class under definition) Traffic Class Service count (for a Traffic Class under definition)
08-bit count of service attributes fields to follow with 08-bit count of service attributes fields to follow with
type/value pair type/value pair
List of service types and relevant values are discussed below List of service types and relevant values are discussed below
00 = no bounded service (also means Best Effort) 00 = no bounded service (also means Best Effort)
Traffic Class Service (optional), Traffic Class Service (optional),
16-bit = type of the field
16-bit = type of the field variable-length = based on type of the service
variable-length = based on type of the service
- 0x00 = reserved - 0x00 = reserved
- 0x01 = MINRATE - 0x01 = TRAFFIC_CLASS_TSPEC
04-bit, unit type 160-bits TSpec Parameter
0x00 = reserved
0x04 = PERCENT
0x05 = KBPS
0x06 to 0x0f = for future use
32-bit, value in unit kbps
- 0x02 = MINRATE_BURST The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p),
32-bit, value in bytes (m) and (M) parameters as described in Invocation Information
section of [RFC2212].
- 0x03 = MINRATE_IN_PROFILE_MARKING +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04-bit, re-mark type | Minimum Rate (r) (32-bit IEEE floating point number) |
0x00 = Invalid +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x01 = Reserved | Burst Size (b) (32-bit IEEE floating point number) |
0x02 = IP_DSCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x03 = MPLS_TC | Maximum Rate (p) (32-bit IEEE floating point number) |
0x04 = 802_1Q_COS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x05 = 802_1Q_DEI | Minimum Policed Unit (m) (32-bit integer) |
0x06 to 0x0f = for future use +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size (M) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter (r) indicates min-rate of the traffic class. This rate
indicates the minimum rate, measured in bytes of Layer 2 (L2)
datagrams per second, service advertiser is providing for a given
class of traffic on advertiser's hop. Note that it does not
necessarily translate to a minimum rate service to receiver of an
SLA unless the traffic class definition clearly represents a sole
receiver of an SLA. If there is no SLA for min-rate, the value of
(r) MUST be set to 0.
Parameter (b) indicates maximum burst size, measured in bytes of
L2 datagram size. Since queuing delay can be considered a
function of burst size (b) and min-rate (r), in presence of non-
zero parameter (r), parameter (b) represents bounded delay for
the Traffic Class. This delay is a single hop queuing delay when
SLA is to be implemented at the resource constrained bottleneck.
In another words this burst size can be considered buffer size.
Value of 0 for parameter (b) means advertiser does not mandate
specific bounded delay.
Parameter (p) indicates max-rate of the traffic class. Just like
min-rate, max-rate, measured in bytes of L2 datagrams per second,
field here also indicates service provided by advertiser. If
advertiser does not have any specific value to set for a given
class of traffic, it MAY be set to physical interface line rate
or any other indirect limit that may affect this class' maximum
rate. In absence of any such known value, it MUST be set to
positive infinity. Value 0 is considered an error.
Parameters (r), (b) and (p) are set each as 32-bit IEEE floating
point numbers. Positive infinity is represented as an IEEE single
precision floating-point number with an exponent of all ones and
a sign mantissa of all zeros. The format of IEEE floating-point
numbers is further summarized in [RFC4506].
The minimum policed unit (m) and maximum packet size (M)
parameters have no relevance for the purpose of SLA exchange.
Thus they MUST be ignored.
- 0x02, L2_OVERHEAD
08-bit, value 08-bit, value
By default specification of rate and other packet size related
parameters, advertised in an SLA, includes L2 overhead. This
overhead by default is L2 overhead of the local link to which SLA
is advertised to. However, in cases where advertised SLA is for a
receiver multiple hops away, L2 overhead consideration from the
source perspective may be different from the local L2 overhead at
the receiver. Explicit notification of size of L2 overhead from a
sender, in such cases, is useful for a receiver to distinguish
local L2 overhead from the sender advertised one. When receiver
choose to react to an advertised SLA and if this service type is
present in advertised SLA, receiver MUST use advertised L2
overhead over local L2 overhead.
If SLA is required to consider only IP datagram size, sender can
advertise this service with a value of 0.
- 0x03 = MINRATE_IN_PROFILE_MARKING
08-bit = IPFIX Element Identifier
variable-length = based on type of the Element
+----+----------------------------+
| ID | Name |
+----+----------------------------+
|195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp |
|244 | dot1qPriority |
+----+----------------------------+
- 0x04 = MINRATE_OUT_PROFILE_MARKING - 0x04 = MINRATE_OUT_PROFILE_MARKING
04-bit, re-mark type 08-bit = IPFIX Element Identifier
0x00 = Invalid variable-length = based on type of the Element
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 +----+----------------------------+
04-bit, unit type | ID | Name |
0x00 = reserved +----+----------------------------+
0x04 = PERCENT |195 | ipDiffServCodePoint |
0x05 = KBPS |203 | mplsTopLabelExp |
0x06 to 0x0f = for future use |244 | dot1qPriority |
32-bit, value +----+----------------------------+
- 0x06 = MAXRATE_BURST - 0x05 = MAXRATE_IN_PROFILE_MARKING
32-bit, value in bytes 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element
- 0x07 = MAXRATE_IN_PROFILE_MARKING +----+----------------------------+
04-bit, re-mark type | ID | Name |
0x00 = Invalid +----+----------------------------+
0x01 = Reserved |195 | ipDiffServCodePoint |
0x02 = IP_DSCP |203 | mplsTopLabelExp |
0x03 = MPLS_TC |244 | dot1qPriority |
0x04 = 802_1Q_COS +----+----------------------------+
0x05 = 802_1Q_DEI
0x06 to 0x0f = for future use
08-bit, value
- 0x08 = MAXRATE_OUT_PROFILE_MARKING - 0x06 = MAXRATE_OUT_PROFILE_MARKING
04-bit, re-mark type 08-bit = IPFIX Element Identifier
0x00 = Invalid variable-length = based on type of the Element
0x01 = DROP
0x02 = IP_DSCP +----+----------------------------+
0x03 = MPLS_TC | ID | Name |
0x04 = 802_1Q_COS +----+----------------------------+
0x05 = 802_1Q_DEI |195 | ipDiffServCodePoint |
0x06 to 0x0f = for future use |203 | mplsTopLabelExp |
08-bit, value |244 | dot1qPriority |
+----+----------------------------+
In the case when MINRATE_IN_PROFILE_MARKING, In the case when MINRATE_IN_PROFILE_MARKING,
MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and MINRATE_OUT_PROFILE_MARKING, MAXRATE_IN_PROFILE_MARKING and
MAXRATE_OUT_PROFILE_MARKING all of them are advertised, MAXRATE_OUT_PROFILE_MARKING all of them are advertised,
- MINRATE_IN_PROFILE_MARKING takes highest precedence - MINRATE_IN_PROFILE_MARKING takes highest precedence
(that is over MAXRATE_IN_PROFILE_MARKING) (that is over MAXRATE_IN_PROFILE_MARKING)
- MAXRATE_IN_PROFILE_MARKING takes precedence over - MAXRATE_IN_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING MINRATE_OUT_PROFILE_MARKING
- and MAXRATE_OUT_PROFILE_MARKING takes precedence over - and MAXRATE_OUT_PROFILE_MARKING takes precedence over
MINRATE_OUT_PROFILE_MARKING MINRATE_OUT_PROFILE_MARKING
- 0x09 = DROP_THRESHOLD - 0x07 = DROP_THRESHOLD
03-bit count of drop-priority fields to follow with 03-bit count of drop-priority fields to follow with
(type,value, unit,value) tuple (type, type-value, burst size) tuple
04-bit, drop priority type 04-bit, drop priority type
0x00 = Invalid 08-bit = IPFIX Element Identifier
0x01 = None variable-length = based on type of the Element
0x02 = IP_DSCP 32-bit, Burst Size (32-bit IEEE floating point number)
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 | ID | Name |
0x01 = TIME_US +----+----------------------------+
0x02 = PERCENT |195 | ipDiffServCodePoint |
0x03 to 0x0f = for future use |203 | mplsTopLabelExp |
08-bit, drop threshold value as per unit type |244 | dot1qPriority |
+----+----------------------------+
- 0x0A = RELATIVE_PRIORITY This finer granular drop threshold does not require separate
buffer space from the aggregate buffer space. It is just an
indicator that beyond what size from the aggregate space, this
code-point specific traffic should all be dropped.
- 0x08 = RELATIVE_PRIORITY
04-bit, priority value 04-bit, priority value
lower the value, higher the priority lower the value, higher the priority
Relative priority indicates scheduling priority. For Relative priority indicates scheduling priority. For example
example voice traffic, that requires lowest latency voice traffic, that requires lowest latency compare to any
compare to any other traffic, will have lowest value other traffic, will have lowest value advertised in relative
advertised in relative priority. For two different priority. For two different traffic classification groups
traffic classification groups where one application where one application group may be considered more important
group may be considered more important than the other than the other but from scheduling perspective do not require
but from scheduling perspective do not require to be to be distinguish with different priority, relative priority
distinguish with different priority. Relative priority for those classification groups may be advertised with the
for those classification groups may be advertised with same value.
the same value.
- 0x0B = SUB_TRAFFIC_CLASSES - 0x09 = SUB_TRAFFIC_CLASSES
variable-length, repeats all content described above from Traffic variable-length, repeats all content described above from Traffic
Class count onwards. Class count onwards.
For SLAs where a specific Traffic Class may further have For SLAs where a specific Traffic Class may further have
differentiated services for sub-group of Classifier Elements, different sub-services for sub-group of Classifier Elements,
this service type SHOULD be used to further divide Traffic Class this service type SHOULD be used to further divide Traffic Class
in multiple sub-classes. Each sub-class then defined with their in multiple sub-classes. Each sub-class then defined with their
own classifier elements and service types. own classifier elements and service types.
4. Originating SLA Notification 4. Originating SLA Notification
QoS attribute to advertise SLA MUST be added by the originator of a 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 BGP UPDATE message. Any BGP speaker in the forwarding path of a
message MUST NOT insert QoS attribute for the same prefix. message MUST NOT insert QoS attribute for the same prefix.
skipping to change at page 15, line 24 skipping to change at page 16, line 39
aggregate traffic for that point to point link. aggregate traffic for that point to point link.
In the simplest case where PE and CE are directly connected via a 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 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 identify forwarding link to PE with AS number of the PE and NLRI
prefix being an address of PE, to CE (that is next hop address from prefix being an address of PE, to CE (that is next hop address from
CE to PE). SLA advertised thru BGP update message from PE to CE, 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 with PE's AS number and IP address, establishes SLA context for the
aggregate traffic through link CE to PE. SLA advertised thru BGP 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 update message from PE to CE, with PE's AS number and any other
prefix establishes SLA for that specific prefix that is subset of prefix establishes SLA for that specific prefix, subset of traffic
traffic under CE to PE link. under CE to PE link.
Even though this example is in the context of IP prefix, SLA exchange 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 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 is generic to all forms of NLRI types that are supported by the BGP
protocol specification (like IPV4, IPV6, VPN-IPV4, VPN-IPV6). protocol specification (like IPV4, IPV6, VPN-IPV4, VPN-IPV6).
4.1.1. SLA advertisement for point to point connection 4.1.1. SLA Advertisement for Point-to-Point Connection
When SLA messages are intended to be advertised for the point to When SLA messages are intended to be advertised for the point to
point connection (physical or logical), the message is destined for point connection (physical or logical), the message is destined for
the next hop and advertised message is in the context of the prefix the next hop and advertised message is in the context of the prefix
of the source end-point of the point to point connection. of the source end-point of the point to point connection.
The destination AS number set to, within QoS SLA attribute, typically The destination AS number set to, within QoS SLA attribute, typically
is of the neighbor BGP speaker's. Alternatively, originator MAY not is of the neighbor BGP speaker's. Alternatively, originator MAY not
encode source/destination AS numbers (that is source AS set to 0 and encode source/destination AS numbers (that is source AS set to 0 and
destination AS count set to 0), in the QoS attribute. The most destination AS count set to 0), in the QoS attribute. The most
significant bit of the QoS attribute flag MAY be set to 1, significant bit of the QoS attribute flag MAY be set to 1,
specifically it MUST be set to 1 when intention is to not install specifically it MUST be set to 1 when intention is to not install
route update, at the receiver, for the advertised message. route update, at the receiver, for the advertised message.
4.1.2. SLA advertisement for destination AS multiple hops away 4.1.2. SLA Advertisement for Destination AS Multiple Hops Away
When SLA messages are to be advertised beyond next hop, value of 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 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 update message. If such update is meant to be for a specific list of
AS(es) as receiver then list of destination AS MUST be populated in 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 the QoS attribute message to avoid flooding of the QoS attribute data
in the network beyond those destinations. in the network beyond those destinations.
When a new prefix is added in the AS, AS for which SLA has already When a new prefix is added in the AS, AS for which SLA has already
been advertised before for other existing prefixes, then to advertise been advertised before for other existing prefixes, then to advertise
that new prefix to be part of earlier advertised SLA, a trigger of that new prefix to be part of earlier advertised SLA, a trigger of
new BGP update message with QoS attribute containing SLA id is new BGP update message with QoS attribute containing SLA id is
sufficient. Update message does not require to have whole SLA sufficient. Update message does not require to have whole SLA
content. content.
When BGP update messages are triggered as a result of SLA policy When BGP update messages are triggered as a result of SLA policy
change and so for the purpose of SLA exchange only, forwarding BGP change and thus only for the purpose of SLA exchange, forwarding BGP
update messages beyond intended receivers are not necessary. Highest update messages beyond intended receivers are not necessary. Highest
order bit in the QoS Attribute flag MUST be set to suggest receiver 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 to drop entire BGP update message [Note that it is an indication to
drop entire update message, not only QoS attribute], after all drop entire update message, not only QoS attribute], after all
intended receivers have processed it. If update message contains intended receivers have processed it. If update message contains
list of destination of AS then message MUST be dropped only after all list of destination AS then message MUST be dropped only after all
intended receivers (destinations) have received it. intended receivers (destinations) have received it.
5. SLA Attribute handling at forwarding nodes 5. SLA Attribute Handling at Forwarding Nodes
5.1. BGP node capable of processing QoS attribute 5.1. BGP Node Capable of Processing QoS Attribute
If a BGP node is capable of processing QoS attribute, it optionally If a BGP node is capable of processing QoS attribute, it optionally
MAY process the message. If advertised SLA has list of destination 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 AS, it MAY trim list and so count of destination AS to exclude ones
that are not required in further announcement of BGP updates. that are not required in further announcement of BGP updates.
BGP node MUST drop SLA related sub type from the QoS attribute, if 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. 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 Rest of the QoS attributes message MAY be forwarded if there exist
other sub-types of QoS attribute and forwarding rules meets other other sub-types of QoS attribute and forwarding rules meets other
sub-types requirements. If there is no other sub-types existing in sub-types requirements. If there is no other sub-types existing in
the QoS attribute message then node MUST drop QoS attribute all the QoS attribute message then node MUST drop QoS attribute all
together. Rest other attributes and NLRI may be announced further if together. Rest other attributes and NLRI may be announced further if
it meets rules defined by other attributes and BGP protocol. it meets rules defined by other attributes and BGP protocol.
If most significant bit in the QoS attribute flag is set to 1 then If most significant bit in the QoS attribute flag is set to 1 then
entire BGP update message MUST be dropped if there are no destination entire BGP update message MUST be dropped if there are no destination
left in the list to advertise to. However, If SLA message is meant left in the list to advertise to. However, If SLA message is meant
skipping to change at page 16, line 45 skipping to change at page 18, line 15
Rest of the QoS attributes message MAY be forwarded if there exist Rest of the QoS attributes message MAY be forwarded if there exist
other sub-types of QoS attribute and forwarding rules meets other other sub-types of QoS attribute and forwarding rules meets other
sub-types requirements. If there is no other sub-types existing in sub-types requirements. If there is no other sub-types existing in
the QoS attribute message then node MUST drop QoS attribute all the QoS attribute message then node MUST drop QoS attribute all
together. Rest other attributes and NLRI may be announced further if together. Rest other attributes and NLRI may be announced further if
it meets rules defined by other attributes and BGP protocol. it meets rules defined by other attributes and BGP protocol.
If most significant bit in the QoS attribute flag is set to 1 then If most significant bit in the QoS attribute flag is set to 1 then
entire BGP update message MUST be dropped if there are no destination entire BGP update message MUST be dropped if there are no destination
left in the list to advertise to. However, If SLA message is meant left in the list to advertise to. However, If SLA message is meant
to be broadcast then message MUST not be dropped/trimmed. to be broadcast then message MUST NOT be dropped/trimmed.
Except extracting entire SLA sub-type of the QoS attribute, trimming Except extracting entire SLA sub-type of the QoS attribute and
the list of destination AS list and inserting NLRI at Aggregator trimming the list of destination AS list and inserting NLRI at the
node, rest all other content MUST not be modified by any intermediate Aggregator node, rest all other content MUST NOT be modified by any
receivers of the message. intermediate receivers of the message.
5.2. BGP node not capable of processing QoS attribute 5.2. BGP Node not Capable of Processing QoS Attribute
If BGP node is not capable of processing QoS attribute, it MUST If BGP node is not capable of processing QoS attribute, it MUST
forward attribute message as it is received. forward attribute message as it is received.
5.3. Aggregator 5.3. Aggregator
It is RECOMMENDED to not aggregate prefixes from BGP update messages It is RECOMMENDED to not aggregate prefixes from BGP update messages
that contain QoS SLA attribute. If Aggregator MUST aggregate that contain QoS SLA attribute. If Aggregator MUST aggregate
prefixes then it MUST copy QoS SLA attribute in new aggregated BGP prefixes then it MUST copy QoS SLA attribute in new aggregated BGP
update message. At the same time, it MUST also insert NLRI, from the update message. At the same time, it MUST also insert NLRI, from the
original update message, as an optional advertiser id to go along original update message, as an optional advertiser id to go along
with source AS in the QoS attribute. with source AS inside the QoS attribute.
To support SLA exchange multiple hops away in the path that has one 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 of the forwarding node in the path acting as Aggregator, it is
required Aggregator node to be capable of processing QoS attribute. required Aggregator node to be capable of processing QoS attribute.
6. SLA attribute handling at Receiver 6. SLA Attribute Handling at Receiver
Reception of and reaction to advertised messages are optional for the Reception of and reaction to advertised messages are optional for the
receiver. receiver.
As described in earlier section, while reacting to SLA advertisement As described in earlier section, while reacting to SLA advertisement
- receiver SHOULD invalidate previous advertised SLA and then if one - receiver SHOULD invalidate previous advertised SLA and then if one
exists for advertised NLRI. If new advertised SLA update is with exists for advertised NLRI. If new advertised SLA update is with
non-zero Traffic Class count, new advertised SLA SHOULD be non-zero Traffic Class count, new advertised SLA SHOULD be
installed. If new advertised SLA update is with Traffic Class installed. If new advertised SLA update is with Traffic Class
count 0, no action is required. count 0, no action is required.
- If advertised QoS Attribute is with flag set to indicate to drop - If advertised QoS Attribute, inside an update message, is with a
this message, receiver MUST drop message if it is the last flag set indicating to drop that message, a receiver MUST drop
receiver, in the update path, this message is advertised to. message if it is the last receiver, in update path, that message
is advertised to.
If advertised SLA is from the next hop, in reverse path, the receiver 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 can establish advertised SLA for the whole link, the link could be
physical or virtual link, associated with the next hop. If NLRI physical or virtual link, associated with the next hop. If NLRI
advertised in update message is not of the next hop, receiver may advertised in update message is not of the next hop, receiver may
establish advertised SLA for that specific prefix list under the establish advertised SLA for that specific prefix list under the
relevant link. It is completely up to the receiver to decide for relevant link. It is completely up to the receiver to decide for
which prefixes to accept advertised SLA and for which ones to not. which prefixes to accept advertised SLA and for which ones to not.
For cases where if earlier message has not yet reached to the For cases where if earlier message has not yet reached to the
intended receiver, a re-signaling is required. A signaling event intended receiver, a re-signaling is required. A signaling event
REQUEST is required, for this purpose, to be triggered by intended REQUEST is required, for this purpose, to be triggered by intended
receiver. Since BGP messages are considered reliable, discussion of receiver. Since BGP messages are considered reliable, it is assumed
REQUEST, for this purpose or any other purpose, is considered out of that advertised messages always reach intended receivers. Thus
the scope of this document. discussion of REQUEST message, for this purpose or any other purpose,
is considered out of the scope of this document.
To handle error conditions, the approach of "attribute-discard" as To handle error conditions, the approach of "attribute-discard" as
mentioned in [IDR-ERR] MAY be used in an event if a QOS attribute mentioned in [IDR-ERR] MAY be used in an event if a QOS attribute
parsing results in any attribute errors. Alternatively, an approach parsing results in any attribute errors. Alternatively, an approach
of "treat-as-withdraw" MAY be used as mentioned in [IDR-ERR] if an of "treat-as-withdraw" MAY be used as mentioned in [IDR-ERR] if an
implementation also wishes to withdraw the associated prefix. implementation also wishes to withdraw the associated prefix.
6.1. Traffic class mapping 6.1. Traffic Class Mapping
It is common that switching/routing technologies used in 2 different It is common that switching/routing methods used in 2 different AS
AS could be different. For example, Provider may tunnel Customer's could be different. For example, Provider may tunnel Customer's IP
IP traffic thru MPLS cloud. In such cases traffic class definition traffic thru MPLS cloud. In such cases traffic class definition for
for QoS services is also different in both AS. For the meaningful QoS services may differ in both ASes. For the meaningful use of
use of advertised SLA in such cases, receiver is required to map advertised SLA in such cases, receiver is required to map traffic
traffic class from one type to another. class from one type to another.
In the example given, traffic classification in Customer AS could be In the example given, traffic classification in Customer AS could be
IP Diffserv based whereas traffic classification in Provider AS could IP Diffserv based whereas traffic classification in Provider AS could
be MPLS TC based. Thus for advertised MPLS TC based SLA from PE, CE 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 would require to map traffic class from IP Diffserv based to MPLS TC
type. type.
There are well-defined recommendations that exist for traffic class There are well-defined recommendations that exist for traffic class
mapping between two technologies. Receiver MAY use those defined mapping between two technologies. Receiver MAY use those defined
recommendations for traffic class mapping or MAY define its own as recommendations for traffic class mapping or MAY define its own as
per its network Traffic Class service definition to map to advertised per its network Traffic Class service definition to map to advertised
Traffic Classes. It is completely up to the receiver how to define Traffic Classes. It is completely up to the receiver how to define
such traffic class mapping. such traffic class mapping.
7. Deployment Consideration 7. Deployment Considerations
Typical use-case aimed with this proposal is for Provider to Typical use case aimed with this proposal is for Provider to
advertise contracted SLA to Customer Edge. SLA established between advertise contracted SLA to Customer Edge. SLA established between
customer and Provider is provisioned by the provider on the PE device customer and Provider is provisioned by the provider on the PE device
(facing Customer Edge). This provisioning, in a form supported by (facing Customer Edge). This provisioning, in a form supported by
Provider, is advertised thru proposed BGP QoS attribute to the Provider, is advertised thru proposed BGP QoS attribute to the
Customer Edge. Customer may read thru advertised SLA to provision Customer Edge. Customer may read thru advertised SLA to provision
one on the Customer Edge link facing towards PE. 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 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 link or finer granular controlled services. SLA is not required to
be advertised if the SLA contract is simply a physical link. SLA be advertised if the SLA contract is simply a physical link. SLA
skipping to change at page 19, line 20 skipping to change at page 20, line 42
/ \ / \ / \ / \
|CustomerSite|-----| Provider | |CustomerSite|-----| Provider |
\ C/E P\E / \ C/E P\E /
\__________/ \ / \__________/ \ /
\_______________/ \_______________/
AS 3 AS 2 AS 3 AS 2
SLA_ADVERTISE: AS2 to AS3 SLA_ADVERTISE: AS2 to AS3
NLRI = PE ip address NLRI = PE ip address
Another use-case can be to advertise SLA among different network Another use case can be to advertise SLA among different network
sites within one Enterprise network. In Hub and Spoke deployments, sites within one Enterprise network. In Hub and Spoke deployments,
Hub may define SLA for individual spokes and advertise this SLA thru Administrator, being aware of each Spoke's SLA, may define SLAs for
BGP updates. each of them at the Hub and advertise them thru BGP updates, where at
each Spoke advertised SLA may translate to a forwarding policy.
Today administrator has to manually define SLA based forwarding
policy separately on the Hub as well as on each Spoke. In a scale
network, managing large number of Spokes can be complex. The
proposal in such cases would be to define SLAs, to be implemented
both at the Hub and each Spoke side, on the Hub only and distribute
them to each Spoke with SLA exchange.
Alternatively, in a fully automated SLA exchange network, manual
administration can be avoided or minimized even at the Hub. As shown
in the figure below, AS2 may first learn its SLA with the Provider
from the Provider Edge it is connected to. AS2 then can advertise
the same or subset of that SLA to AS3 in the context of tunnel's ip
address.
AS 2 AS 2
_______________ ________ _______________ ________
/ \ / \ / \ / \
__________ / \-----| Spoke2 | __________ / \-----| Spoke2 |
/ \ / \ \________/ / \ / \ \________/
| Hub |-----| Provider | ________ | Hub |-----| Provider | ________
\__________/ \ / / \ \__________/ \ / / \
\ /-----| Spoke1 | \ /-----| Spoke1 |
AS 3 \_______________/ \________/ AS 3 \_______________/ \________/
AS 1 AS 1
SLA_ADVERTISE: AS2 to AS3 SLA_ADVERTISE: AS2 to AS3
NLRI = AS2 tunnel address NLRI = AS2 tunnel address
SLA_ADVERTISE: AS1 to AS3 SLA_ADVERTISE: AS1 to AS3
NLRI = AS2 tunnel address NLRI = AS1 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 Deployment options are not limited to involving CEs, PE-to-CE or CE-
contract between Provider to Provider, SLA may be advertised from one to-CE, only. For any contract between Provider to Provider, SLA may
PE to another PE also. be advertised from one PE to another PE also.
8. Acknowledgements 8. Acknowledgements
Thanks to Fred Baker for his suggestions and to Ken Briley, Rahul Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for
Patel, Fred Yip, Lou Berger and Brian Carpenter for the review. their suggestions and to Ken Briley, Rahul Patel, Fred Yip, Lou
Thanks to Bertrand Duvivier for his valuable contributions to help Berger, Brian Carpenter, Bertrand Duvivier for the review.
make subsequent revision better.
9. IANA Considerations 9. IANA Considerations
This document defines a new BGP attribute. IANA maintains the list The proposal in this document defines a new BGP attribute. IANA
of existing BGP attribute types. Proposal is to define a new maintains the list of existing BGP attribute types. A new type to be
attribute type code for the QoS attribute. added in the list 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 The proposal also defines a list for Service types associated to
0x00 = Invalid Traffic Class. IANA will be required to maintain this list for
0x01 = Reserved Traffic Class Service type as a new registry. Where-as Traffic Class
0x02 = IP_DSCP, (length = 06-bits, value = 0..63) Element types, defined in the proposal, refer to existing IPFIX IANA
0x03 = MPLS_TC, (length = 03-bits, value = 0..7) types.
0x04 = 802_1Q_COS,(length = 03-bits, value = 0..7)
0x05 = 802_1Q_DEI,(length = 01-bit, value = 0..1)
0x06 = PHB_ID, (length = 12-bits, value = 0..4095)
Proposed definition of Traffic Class Service Types Proposed definition of Traffic Class Service Types
0x00 = reserved 0x00 = reserved
0x01 = MINRATE 0x01 = TRAFFIC_CLASS_TSPEC
0x02 = MINRATE_BURST 0x02 = L2_OVERHEAD
0x03 = MINRATE_IN_PROFILE_MARKING 0x03 = MINRATE_IN_PROFILE_MARKING
0x04 = MINRATE_OUT_PROFILE_MARKING 0x04 = MINRATE_OUT_PROFILE_MARKING
0x05 = MAXRATE 0x05 = MAXRATE_IN_PROFILE_MARKING
0x06 = MAXRATE_BURST 0x06 = MAXRATE_OUT_PROFILE_MARKING
0x07 = MAXRATE_IN_PROFILE_MARKING 0x07 = DROP_THRESHOLD
0x08 = MAXRATE_OUT_PROFILE_MARKING 0x08 = RELATIVE_PRIORITY
0x09 = DROP_THRESHOLD 0x09 = SUB_TRAFFIC_CLASSES
0x0A = RELATIVE_PRIORITY
0x0B = SUB_TRAFFIC_CLASSES
Proposed definition of Unit Types
0x00 = reserved
0x01 = TIME_US
0x02 = PERCENT
0x03 = KBPS
10. Security Considerations 10. Security Considerations
There is a potential for mis-behaved AS to advertise wrong SLA, There is a potential for mis-behaved AS to advertise wrong SLA,
stealing identity of another AS. This resembles to problems already stealing identity of another AS. This resembles to problems already
identified and resolved, in the routing world, thru reverse path identified and resolved, in the routing world, thru reverse path
forwarding check. One proposal, inline to RPF, to resolve such forwarding check. One proposal, inline to RPF, to resolve such
threats is to have each BGP speaker node, in the forwarding path, threats is to have each BGP speaker node, in the forwarding path,
perform reverse path check on source AS. perform reverse path check on source AS. Since we expect these
messages to originate and distributed in the managed network, there
Since we expect these messages to originate and distributed in the should not be any risks for identity theft. Thus reverse path check
managed network, there should not be any risks for identity theft. is not considered in this proposal nor have we considered any
Thus reverse path check is not considered in this proposal nor have alternates. Such solutions can be explored later if any such need.
we considered any alternates. Such solutions can be explored later
if any such need.
11. References 11. References
11.1. Normative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 11.1. Normative References
(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, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Per Hop Behavior Identification Codes", RFC 3140, Requirement Levels", BCP 14, RFC 2119, March 1997.
June 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
Text on Security Considerations", BCP 72, RFC 3552, of Guaranteed Quality of Service", RFC 2212,
July 2003. September 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. 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 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008.
11.2. Informative References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, [IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Message, "Revised Error Handling for BGP UPDATE Message,
I-D.draft-ietf-idr-error-handling", June 2012. I-D.draft-ietf-idr-error-handling", June 2012.
11.2. Informative References
[CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS [CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS
Connectivity Provisioning Profile, I-D.boucadair- Connectivity Provisioning Profile, I-D.boucadair-
connectivity-provisioning-profile", Sep 2012. connectivity-provisioning-profile", Sep 2012.
[CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
Negotiation Protocol (CPNP), I-D.boucadair-connectivity-
provisioning-protocol", May 2013.
Authors' Addresses Authors' Addresses
Shitanshu Shah Shitanshu Shah
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: svshah@cisco.com Email: svshah@cisco.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: keyupate@cisco.com Email: keyupate@cisco.com
Sandeep Bajaj Sandeep Bajaj
Juniper Networks Juniper Networks
 End of changes. 108 change blocks. 
341 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/