draft-ietf-idr-sla-exchange-05.txt   draft-ietf-idr-sla-exchange-06.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: October 28, 2015 S. Bajaj Expires: May 4, 2016 S. Bajaj
Juniper Networks Juniper Networks
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
France Telecom France Telecom
Apr 26, 2015 November 01, 2015
Inter-domain SLA Exchange Inter-domain SLA Exchange
draft-ietf-idr-sla-exchange-05 draft-ietf-idr-sla-exchange-06
Abstract Abstract
Network administrators typically enforce Quality of Service (QoS) Network administrators typically enforce Quality of Service (QoS)
policies according to Service Level Agreement (SLA) with their policies according to Service Level Agreement (SLA) with their
providers. The enforcement of such policies often relies upon providers. The enforcement of such policies often relies upon
vendor-specific configuration language. Both learning of SLA, either vendor-specific configuration language. Both learning of SLA, either
thru SLA documents or via some other out-of-band method, and thru SLA documents or via some other out-of-band method, and
translating them to vendor specific configuration language is a translating them to vendor specific configuration language is a
complex, many times manual, process and prone to errors. This complex, many times manual, process and prone to errors. This
document proposes an in-band method of SLA signaling which can help document proposes an in-band method of SLA signaling, which can help
to simplify some of the complexities. to simplify some of the complexities, where BGP is available as the
routing protocol.
This document defines an optional transitive attribute to signal SLA This document defines an optional transitive attribute to signal SLA
details in-band, across administrative boundaries (considered as parameters in-band, across administrative boundaries (considered as
Autonomous Systems (AS)), thus simplifying and facilitating some of Autonomous Systems (AS)), thus simplifying and facilitating some of
the complex provisioning tasks. the complex provisioning tasks.
Though the use case with the proposed BGP attribute is explicitly Status of This Memo
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 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 May 4, 2016.
This Internet-Draft will expire on October 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . . 5 3. QoS Attribute Definition . . . . . . . . . . . . . . . . . . 4
3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 6 3.1. SLA, QoS attribute sub-type, Definition . . . . . . . . . 5
4. Originating SLA Notification . . . . . . . . . . . . . . . . . 16 4. Originating SLA Notification . . . . . . . . . . . . . . . . 15
4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. SLA Contexts . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. SLA Advertisement for Point-to-Point Connection . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 Away . . . . . . . . . . . . . . . . . . . . . . . . 16
5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . . 17 5. SLA Attribute Handling at Forwarding Nodes . . . . . . . . . 16
5.1. BGP Node Capable of Processing QoS Attribute . . . . . . . 17 5.1. BGP Node Capable of Processing QoS Attribute . . . . . . 16
5.2. BGP Node not Capable of Processing QoS Attribute . . . . . 18 5.2. SLA Attribute Handling at Receiver . . . . . . . . . . . 17
5.3. Aggregator . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18
6. SLA Attribute Handling at Receiver . . . . . . . . . . . . . . 18 7. Traffic Class Mapping . . . . . . . . . . . . . . . . . . . . 18
6.1. Traffic Class Mapping . . . . . . . . . . . . . . . . . . 19 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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) for
established between Customer and Provider or between providers, QoS established between a customer and a provider or between
possibly using one or the other form of the template [CPP]. This providers. This QoS SLA defines the nature of the various traffic
contractual agreement usually defines the nature of the various classes and services needed within each traffic class. The contract
traffic classes (i.e., traffic match conditions) and services needed may include full line-rate or sub line-rate without additional
for each traffic class. The contract may exist at different levels traffic classes, or it may contain additional traffic classes and
of traffic granularity. The contract could be for the full line-rate service definitions for those traffic classes. Finer granular
or sub line-rate without granular traffic distinction or it could be traffic classes may be based on some standard code points (like DSCP)
for finer granular traffic classes, with services defined. Finer or specific set of prefixes.
granular classes can be based on some standard code-points (like
DSCP) or for a specific set of prefixes or for a set of well-known
application types.
Once the SLA is established, SLA parameters are enforced in some or Once the SLA is established, QoS SLA parameters are enforced in some
all participating devices by deriving SLA parameters into or all participating devices by deriving those parameters into
configuration information on respective devices. SLA parameters may configuration information on respective devices. SLA parameters may
have to be exchanged through organizational boundaries, thru SLA have to be exchanged through organizational boundaries, thru SLA
documents or via some other off-band method to an administrator documents or via some other off-band method to an administrator
provisioning actual devices. In a subsequent step, administrator provisioning actual devices. In a subsequent step, administrator
requires to translate SLA to QoS policies using router (vendor) requires to translate SLA to QoS policies using router (vendor)
specific provisioning language. In a multi-vendor network, specific provisioning language. In a multi-vendor network,
translating SLAs into technology-specific and vendor-specific translating SLAs into technology-specific and vendor-specific
configuration requires to consider specificities of each vendor. 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.
As an example for voice service, the Provider may negotiate QoS As an example for voice service, the Provider may negotiate QoS
parameters (like min/max rates) for such traffic based upon the EF parameters (like min/max rates) for such traffic based upon the EF
code-point in Diffserv-enabled [RFC2475] networks. Administrator at code-point in Diffserv-enabled [RFC2475] networks. The Administrator
the CE side not only will have to know that Provider's service for at the CE side not only will have to know that Provider's service for
voice traffic is EF-based, so that traffic exiting CE is marked voice traffic is EF-based but will also have to know how to implement
properly, but will also have to know how to implement DSCP EF DSCP EF classification rule along with Low Latency Service, and
classification rule along with Low Latency Service, and possibly min/ possibly min/max rate enforcement for the optimal use of bandwidth,
max rate enforcement for the optimal use of bandwidth, as per vendor as per vendor specific provisioning language.
specific provisioning language.
An in-band signaling method of propagating SLA parameters from An in-band signaling method of propagating SLA parameters from the
provider, PE in an example above, to contractual devices, CE in an provider, PE in an example above, to contractual devices, CE in an
example above, can help eliminate manual administrative process example above, can help eliminate manual administrative process
described above. Provider may have SLA negotiated with the Customer described above. The provider may have SLA negotiated with the
via some defined off-band method (based on the specifics defined by Customer via some defined off-band method (based on the specifics
the Provider or using protocols like [CPNP]. The Inter-domain SLA defined by the Provider or using protocols like [CPNP]). The Inter-
exchange proposal described in this document does not pre-requisite domain SLA exchange proposal described in this document does not pre-
any specific method of establishing SLAs). The Provider provisions requisite any specific method of establishing SLAs). The Provider
established SLA on the Provider device. This SLA instance then can provisions established SLA on the Provider device. This SLA instance
be signaled to the Customer via in-band signaling protocol. In then can be signaled to the Customer via in-band signaling protocol.
reaction to this signal, receiver router may translate that to In reaction to this signal, receiver router may translate that to
relevant QoS policy definition on the device. relevant QoS policy definition on the device.
For an in-band signaling, we propose to use BGP as a transport. The For an in-band signaling, we propose to use BGP as a transport. The
details of SLA parameters are specific to the granularity of traffic details of SLA parameters are specific to the granularity of traffic
classes and their respective treatment, which is independent of the classes and their respective treatment, which is independent of the
BGP protocol itself. Though we find BGP as a suitable transport for BGP protocol itself. Though we find BGP as a suitable transport for
inter-domain SLA exchange for the following reasons: inter-domain SLA exchange for the following reasons:
- The need to exchange SLA parameters between domains (Automated - The need to exchange SLA parameters between domains(Autonomous
Systems (AS)), where in use-cases described in this document, Systems (AS)), where in use-cases described in this document,
BGP is a suitable protocol for inter-domain exchange [RFC4271] BGP is a suitable protocol for inter-domain exchange [RFC4271]
[RFC4364] [RFC4364].
- There is no specifically defined protocol available today for - There is no specifically defined protocol available today for
SLA exchange SLA 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 to define a new BGP attribute to advertise/learn SLA The proposal is to define a new BGP attribute to advertise/learn SLA
details in-band. The proposed attribute is intended to advertise SLA details in-band. The proposed attribute is intended to advertise SLA
from one AS to a list of destined ASes. The advertised QoS from one AS to a list of destined ASes. The advertised QoS
information could be for the incoming traffic to the advertiser, that information could be for the incoming traffic to the advertiser, that
is advertising SLA or could be for the outgoing traffic from the is advertising SLA or could be for the outgoing traffic from the
advertiser or could be for both directions. Reception of and advertiser or could be for both directions. Reception of and
reaction to advertised SLAs are optional for the receiver. reaction to advertised SLAs are optional for the receiver.
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 as one of the sub-types of QoS attribute. This is to
attribute. This is to keep the QoS attribute open for extensions. keep the QoS attribute open for extensions. For example, SLA
For example, SLA Negotiation and Assurance is out of scope of this Negotiation and Assurance is out of scope of this document but can be
document but can be envisioned as another sub-type. 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 here is an optional transitive attribute The QoS Attribute proposed here is an optional transitive attribute
(attribute type code to be assigned by IANA). SLA is defined as one (attribute type code to be assigned by IANA). SLA is defined as one
of the sub-types in the QoS attribute. of the sub-types in the QoS attribute. The QoS attribute is only
applicable to the NLRI advertised in the BGP update message.
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 | Attr type QoS | | | Attr flag | Attr type QoS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| QoS Attr length/Value | | QoS Attr length/Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
skipping to change at page 6, line 25 skipping to change at page 5, line 25
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
3.1. SLA, QoS attribute sub-type, Definition 3.1. SLA, QoS attribute sub-type, Definition
The value field of the QoS Attribute contains TLVs, followed to QoS The value field of the QoS Attribute contains TLVs, followed to QoS
Attribute flags described in the previous section. One of the TLVs Attribute flags described in the previous section. One of the TLVs
that we define is a tuple of (SLA sub-type, Length, Value) 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 | subtype Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
The first octet in the Value field of the QoS attribute is QoS QoS Attr flags
attribute specific flags 8-bit = 0000-0000, All the bits are currently un-used. The space
is made available for the purpose of future use. For now
highest order bit (bit 0) - they all MUST be set to 0 when QoS attribute is added in
It defines if update message MUST be dropped (if set to 1) the BGP update message and MUST be ignored when received
without updating routing information base, when this is the
last BGP receiver from the list of destination ASes 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
subType - 8 bits subType
8-bit
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. These details contain subType Length
information about 1) sender and receiver(s) and 2) SLA parameters. 16-bit
SLA Parameters include SLA event type (such as Advertise, Request) Length of the content to follow pertaining to specified
and contents associated to that event type. subType.
Value for the SLA sub-type is as described below. These details
contain information about 1) sender and receiver(s) and 2) SLA
parameters. SLA Parameters include SLA event type (such as
Advertise) and contents associated to that event type.
The format of SLA message is, The format of SLA message is,
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit source AS (Advertiser) | | 32-bit Source AS (Advertiser) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional advertiserid total len| Advertiser id TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit destination AS count | | 32-bit Destination AS count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| variable list of destination AS | | variable list of destination AS |
~ .... ~ ~ .... ~
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
message.
Optional advertiser id total len
16-bit Source address identifier (optional).
0 = No optional identifier
In general any additional qualifier for an advertiser is not
required. The SLA definition is in the context of prefix
advertised in the NLRI definition. The exception is where a BGP
speaker, in the middle of an update path to the destination AS,
aggregates prefixes. 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 Note that AS = 0, used in message outside of QoS attribute,
4-bit type is illegal in normal BGP operations. AS = 0 inside the QoS
0x0 = reserved attribute may be used simply as a flag to tell receiver to
0x1 = ORIGIN_NLRI, variable length ignore Source and Destination AS list from inside the QoS
0x2 to 0xf = for future use, attribute.
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 = QoS attribute is relevant to every receiver of the message 0 = QoS attribute is relevant to every receiver of the message
Destination AS list Destination AS list
32-bit destination AS number 32-bit destination AS number
.... ....
.... [as many as AS count] .... [as many as AS count]
SLA Event Type SLA Event
4-bits 4-bits
0x0 = reserved 0x0 = reserved
0x1 = ADVERTISE 0x1 = ADVERTISE
0x2 = REQUEST 0x2 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 parameters. The SLA identifier source that is advertising SLA parameters. The SLA identifier
is not globally unique but it MUST be unique within the source is not globally unique but it MUST be unique within the source
AS (advertiser). AS (advertiser).
The SLA content is optional for an advertised SLA id. If SLA
content does not exist in BGP update messages with advertised
QoS attribute, that contains the SLA sub-type, 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, If advertised SLA id is different from earlier advertised one,
for the same prefix, previous SLA content MUST be replaced for the same prefix, previous SLA content MUST be replaced
with the new advertised one. with the new advertised one.
SLA is aggregate for all the traffic to prefixes that share SLA is aggregate for all the traffic to prefixes for a given
same source AS and SLA id. AFI/SAFI that share same source AS and SLA id.
SLA Length SLA Length
12-bits 12-bits - Total length of the SLA content to follow
The format of SLA ADVERTISE event message is, Content as per SLA event
The SLA content is optional for an advertised SLA id. The
value of the SLA length field in such case would be 0. If SLA
content does not exist in BGP update messages with advertised
QoS attribute, that contains the SLA sub-type, then receiver
MUST inherit prior advertised SLA content for the same SLA id
from the same Source AS. If there does not exist any prior SLA
to relate to the advertised SLA id, then receiver can ignore
the SLA advertisement and continue with the rest of the BGP
message processing and forwarding rules. Note that such
condition MUST not discard the attribute. All defined
forwarding rules for this attribute still MUST apply.
The only event prescribed in this document is ADVERTISE.
The format of SLA ADVERTISE event message is,
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dir| Traffic Class count | Class Desc Len| | |dir| Traffic Class count | Class Desc Len| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Description ~ ~ Traffic Class Description ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elements Count| |
+-+-+-+-+-+-+-+-+ ~
| | | |
~ Traffic Class Elements count/values ~ ~ Traffic Class Elements TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Count| service type/value pair | | Service Count| |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+ ~
| | | Traffic Class Service TLVs |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ 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 dir (Direction)
02-bit for incoming or outgoing traffic, 02-bit for incoming traffic to source AS or outgoing traffic
from source AS,
0x0 = reserved 0x0 = reserved
0x1 = incoming, from destination AS towards source AS 0x1 = incoming, to source AS from destination 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 any 00 = Advertisement to invalidate previous advertised SLA if any
Traffic Class Descr Length Traffic Class Descr Length
08-bit, size of the length 08-bit, length of the description
0 = No description 0 = No description
Traffic Class Description Traffic Class Description
Ascii Description of the Traffic Class Description of the Traffic Class in UTF-8 encoding
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 that Traffic Class, that has 0 elements, It is RECOMMENDED that Traffic Class that has 0 elements
is present last in the advertised list of Traffic Classes. is present last in the advertised list of Traffic Classes.
If Advertised message has it positioned some-where else, If Advertised message has it positioned somewhere else,
then receiver MUST re-order it, for the forwarding purpose, then receiver MUST re-order it, for the forwarding purpose,
to the last position in the advertised list of Traffic to the last position in the advertised list of Traffic
Classes from a given source AS. QoS attribute advertised Classes from a given source AS. QoS attribute advertised
from a specific source MUST NOT have more than one such from a specific source MUST NOT have more than one such
Traffic Classes (Traffic Class with 0 element count). If Traffic Classes (Traffic Class with 0 elements count). If
there are more than one such Traffic Classes present then there are more than one such Traffic Classes present then
advertised SLA parameters MUST be ignored. It is okay it is an error condition which should follow handling of
though to have none Traffic Class with element count 0. such BGP message as described in Error handling section.
Classifier Element values in a Traffic Class (optional), Classifier Element values (optional),
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
variable-length field = contains actual value
Given IPFIX [RFC5102] has well defined identifier set for a Given IPFIX [RFC5102] has well defined identifier set for a
large number of packet attributes, IPFIX IANA registry is large number of packet attributes, IPFIX IANA registry is
"https://www.ietf.org/assignments/ipfix" chosen to specify ("https://www.ietf.org/assignments/ipfix") chosen to specify
packet classification attributes. However, since not all packet classification attributes. However, since not all
identifiers from IPFIX would be applicable to this proposal, identifiers from IPFIX would be applicable to this proposal,
only a limited set identified here can be supported by BGP only a limited set identified here can be supported by BGP
SLA exchange. Any new element identifier, in future, added SLA exchange. Any new element identifier, in the future added
to the IPFIX IANA registry does not automatically mean to the IPFIX IANA registry, is not automatically supported
supported for this proposal. for this proposal. Only the IPFIX elements indicated in this
document below remain supported.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
| 8 | sourceIPv4Address | | 8 | sourceIPv4Address |
| 27 | sourceIPv6Address | | 27 | sourceIPv6Address |
| 9 | sourceIPv4PrefixLength | | 9 | sourceIPv4PrefixLength |
skipping to change at page 11, line 23 skipping to change at page 10, line 22
| 28 | destinationIPv6Address | | 28 | destinationIPv6Address |
| 13 | destinationIPv4PrefixLength| | 13 | destinationIPv4PrefixLength|
| 30 | destinationIPv6PrefixLength| | 30 | destinationIPv6PrefixLength|
| 45 | destinationIPv4Prefix | | 45 | destinationIPv4Prefix |
|169 | destinationIPv6Prefix | |169 | destinationIPv6Prefix |
| 4 | protocolIdentifier | | 4 | protocolIdentifier |
| 7 | sourceTransportPort | | 7 | sourceTransportPort |
| 11 | destinationTransportPort | | 11 | destinationTransportPort |
+----+----------------------------+ +----+----------------------------+
Any traffic classifier element advertised in the QoS attribute
is only applicable to the NLRI advertised for a given AFI/SAFI
within the BGP update message. If a receiver receives a BGP
update message with QoS/SLA attribute for an NLRI that is not
supported by a receiver then receiver MUST not install an
advertised SLA and continue to forward this attribute further
if it is not the last receiver of an attribute.
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 = Traffic Class Service Type
variable-length = based on type of the service 08-bit = size, in octets, of the value field
variable-length field = contains actual value
- 0x00 = reserved - 0x00 = reserved
- 0x01 = TRAFFIC_CLASS_TSPEC - 0x01 = TRAFFIC_CLASS_TSPEC
160-bits TSpec Parameter 160-bits TSpec Parameter
The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p), The TRAFFIC_CLASS_TSPEC parameter consists of the (r), (b), (p),
(m) and (M) parameters as described in Invocation Information (m) and (M) parameters as described in Invocation Information
section of [RFC2212]. Note that inheriting definition of TSpec section of [RFC2212]. Note that inheriting the definition of
here does not enable RFC2212 functionality. It purely is the TSpec here does not enable RFC2212 functionality. Only the
Traffic Specification that is inherited here for the purpose of values of the Traffic Specification are used in this
SLA exchange. specification.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Rate (r) (32-bit IEEE floating point number) | | Minimum Rate (r) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Size (b) (32-bit IEEE floating point number) | | Burst Size (b) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Rate (p) (32-bit IEEE floating point number) | | Maximum Rate (p) (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit (m) (32-bit integer) | | Minimum Policed Unit (m) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size (M) (32-bit integer) | | Maximum Packet Size (M) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter (r) indicates min-rate of the traffic class. This rate Parameter (r) indicates min-rate of the traffic class. This rate
indicates the minimum rate, measured in bytes of Layer 2 (L2) indicates the minimum rate, measured in octets of Layer 2 (L2)
datagrams per second, service advertiser is providing for a given datagrams per second, that the service advertiser is providing
class of traffic on advertiser's hop. Note that it does not for a given class of traffic on advertiser's hop. Note that it
necessarily translate to a minimum rate service to receiver of an does not necessarily translate to a minimum rate service to the
SLA unless the traffic class definition clearly represents a sole receiver of an SLA unless the traffic class definition clearly
receiver of an SLA. If there is no SLA for min-rate, the value of represents a sole receiver of an SLA. If there is no SLA for
(r) MUST be set to 0. min-rate, the value of (r) MUST be set to 0.
Parameter (b) indicates maximum burst size, measured in bytes of Parameter (b) indicates maximum burst size, measured in octets of
L2 datagram size. Since queuing delay can be considered a L2 datagram size. Since queuing delay can be considered a
function of burst size (b) and min-rate (r), in presence of non- function of burst size (b) and min-rate (r), in presence of non-
zero parameter (r), parameter (b) represents bounded delay for zero parameter (r), parameter (b) represents bounded delay for
the Traffic Class. This delay is a single hop queuing delay when the Traffic Class. This delay is a single hop queuing delay when
SLA is to be implemented at the resource constrained bottleneck. SLA is to be implemented at the resource constrained bottleneck.
In other words this burst size can be considered as a buffer In other words this burst size can be considered as a buffer
size. Value of 0 for parameter (b) means the advertiser does not size. Value of 0 for parameter (b) means the advertiser does not
mandate specific bounded delay. mandate specific bounded delay.
Parameter (p) indicates max-rate of the traffic class. Just like Parameter (p) indicates max-rate of the traffic class. Just like
min-rate, max-rate, measured in bytes of L2 packets per second, min-rate, max-rate, measured in octets of L2 packets per second,
field here also indicates service provided by advertiser. If field here also indicates service provided by advertiser. If
advertiser does not have any specific value to set for a given advertiser does not have any specific value to set for a given
class of traffic, it MAY be set to physical interface line rate class of traffic, it MAY be set to physical interface line rate
or any other indirect limit that may affect this class' maximum or any other indirect limit that may affect this class' maximum
rate. In absence of any such known value, it MUST be set to rate. In absence of any such known value, it MUST be set to
positive infinity. Value 0 is considered an error. positive infinity. Value 0 is considered an error.
Parameters (r), (b) and (p) are each set as 32-bit IEEE floating Parameters (r), (b) and (p) are each set as 32-bit IEEE floating
point numbers. Positive infinity is represented as an IEEE single point numbers. Positive infinity is represented as an IEEE single
precision floating-point number with an exponent of all ones and precision floating-point number with an exponent of all ones and
skipping to change at page 13, line 10 skipping to change at page 12, line 20
The minimum policed unit (m) and maximum packet size (M) The minimum policed unit (m) and maximum packet size (M)
parameters have no relevance for the purpose of SLA exchange. parameters have no relevance for the purpose of SLA exchange.
Thus they MUST be ignored. Thus they MUST be ignored.
- 0x02, L2_OVERHEAD - 0x02, L2_OVERHEAD
08-bit, value 08-bit, value
By default specification of rate and other packet size related By default specification of rate and other packet size related
parameters, advertised in an SLA, includes L2 overhead. For the parameters, advertised in an SLA, includes L2 overhead. For the
receiver next hop, this overhead is the L2 overhead of the local receiver next hop,this overhead is the L2 overhead of the local
link where advertised SLA is received. However, in cases where link where advertised SLA is received. However, in cases where
advertised SLA is for a receiver multiple hops away, L2 overhead advertised SLA is for a receiver multiple hops away, L2 overhead
consideration from the source perspective may be different from consideration from the source perspective may be different from
the local L2 overhead at the receiver. Explicit notification of the local L2 overhead at the receiver. Explicit notification of
size of L2 overhead from a sender, in such cases, is useful for size of L2 overhead from a sender, in such cases, is useful for
a receiver to distinguish local L2 overhead from the sender a receiver to distinguish local L2 overhead from the sender
advertised one. When receiver choose to react to an advertised advertised one. When receiver choose to react to an advertised
SLA and if this service type is present in advertised SLA, SLA and if this service type is present in advertised SLA,
receiver MUST use advertised L2 overhead over local L2 overhead. receiver MUST use advertised L2 overhead over local L2 overhead.
If SLA is required to consider only IP packet size, sender may If SLA is required to consider only IP packet size, sender may
advertise this service with a value of 0. advertise this service with a value of 0.
- 0x03 = MINRATE_IN_PROFILE_MARKING - 0x03 = MINRATE_IN_PROFILE_MARKING
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
variable-length field = contains actual value
00 Identifier = drop, variable-length for this id is 0. 00 Identifier = drop, variable-length for this id is 0.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
- 0x04 = MINRATE_OUT_PROFILE_MARKING - 0x04 = MINRATE_OUT_PROFILE_MARKING
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
variable-length field = contains actual value
00 Identifier = drop, variable-length for this id is 0. 00 Identifier = drop, variable-length for this id is 0.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
- 0x05 = MAXRATE_IN_PROFILE_MARKING - 0x05 = MAXRATE_IN_PROFILE_MARKING
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
variable-length field = contains actual value
00 Identifier = drop, variable-length for this id is 0. 00 Identifier = drop, variable-length for this id is 0.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
- 0x06 = MAXRATE_OUT_PROFILE_MARKING - 0x06 = MAXRATE_OUT_PROFILE_MARKING
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
variable-length field = contains actual value
00 Identifier = drop, variable-length for this id is 0. 00 Identifier = drop, variable-length for this id is 0.
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |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 are all 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
- 0x07 = 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, type-value, burst size) tuple (type, type-value, burst size) tuple
04-bit, drop priority type 04-bit, drop priority type
08-bit = IPFIX Element Identifier 08-bit = IPFIX Element Identifier
variable-length = based on type of the Element 08-bit = size, in octets, of the value field
32-bit, Burst Size (32-bit IEEE floating point number) variable-length field = contains actual value
32-bit = Burst Size
(32-bit IEEE floating point number)
+----+----------------------------+ +----+----------------------------+
| ID | Name | | ID | Name |
+----+----------------------------+ +----+----------------------------+
|195 | ipDiffServCodePoint | |195 | ipDiffServCodePoint |
|203 | mplsTopLabelExp | |203 | mplsTopLabelExp |
|244 | dot1qPriority | |244 | dot1qPriority |
+----+----------------------------+ +----+----------------------------+
This finer granular drop threshold does not require separate This finer granular drop threshold does not require separate
buffer space from the aggregate buffer space. It is just an buffer space from the aggregate buffer space. It is just an
indicator beyond which code-point specific traffic to be indicator beyond which code-point specific traffic to be
discarded when occupancy of aggregate buffers reached to that discarded when occupancy of aggregate buffers reached to that
threshold. threshold.
- 0x08 = RELATIVE_PRIORITY - 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 example Relative priority indicates scheduling priority. For example
voice traffic, which requires lowest latency compare to any voice traffic, which requires lowest latency compared to any
other traffic, may have lowest value advertised in relative other traffic, may have lowest value advertised in relative
priority. For two different traffic classification groups priority. For two different traffic classification groups
where one application group may be considered more important where one application group may be considered more important
than the other but from a scheduling perspective does not than the other but from a scheduling perspective does not
require to be distinguished with a different priority, relative require to be distinguished with a different priority, relative
priority for those classification groups may be advertised with priority for those classification groups may be advertised with
the same value. the same value.
- 0x09 = 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
different sub-services for sub-group of Classifier Elements, different sub-services for a 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 is then defined with
own classifier elements and service types. their own classifier elements and service types.
4. Originating SLA Notification 4. Originating SLA Notification
The QoS attribute to advertise SLA sub-type MUST be added by the The QoS attribute MUST only be added by the originator and MUST NOT
originator of a BGP UPDATE message. be added during BGP propagation.
SLA messages SHOULD NOT be sent periodically just for the purpose of SLA messages SHOULD NOT be sent periodically just for the purpose of
keep alive. Some sort of SLA policy change may be considered as a keep alive. Some sort of SLA policy change may be considered as a
trigger for the advertisement. trigger for the advertisement.
For any modified SLA parameters, the originator MUST re-advertise the For any modified SLA parameters, the originator MUST re-advertise the
entire set of SLA parameters. There is no provision to advertise entire set of SLA parameters. There is no provision to advertise
partial set of parameters. To invalidate previously advertised SLA partial set of parameters. To invalidate previously advertised SLA
parameters, a message MUST be sent with the same SLA id for the same parameters, a message MUST be sent with the same SLA id for the same
source with the Traffic Class count set to 0. source with the Traffic Class count set to 0.
skipping to change at page 16, line 33 skipping to change at page 15, line 45
aggregate traffic over a point-to-point connection between a specific aggregate traffic over a point-to-point connection between a specific
destination and a specific source. A point-to-point connection may destination and a specific source. A point-to-point connection may
be the physical link, that connects two BGP peers, or may be a be the physical link, that connects two BGP peers, or may be a
virtual link (e.g. a tunnel). A BGP update message, in such cases, virtual link (e.g. a tunnel). A BGP update message, in such cases,
with source AS number and NLRI prefix of source end-point can with source AS number and NLRI prefix of source end-point can
uniquely identify physical/virtual link and so establishes advertised uniquely identify physical/virtual link and so establishes advertised
SLA's context for that point to point link. SLA's context for that point to point link.
In the simplest case where Provider (e.g. PE) and Customer (e.g. In the simplest case where Provider (e.g. PE) and Customer (e.g.
CE) devices are directly connected via a physical link and have only CE) devices are directly connected via a physical link and have only
single link between them, CE can uniquely identify the forwarding a single link between them, CE can uniquely identify the forwarding
link to PE with AS number of the PE and NLRI prefix being an IP link to PE with AS number of the PE and NLRI prefix being an IP
address of PE, to CE (that is the next hop address from CE to PE). address of PE, to CE (that is the next hop address from CE to PE).
SLA advertised thru BGP update message from PE to CE, with PE's AS SLA advertised thru BGP update message from PE to CE, with PE's AS
number and IP address, establishes SLA context for the aggregate number and IP address, establishes SLA context for the aggregate
traffic through link CE to PE. SLA advertised thru BGP update traffic through link CE to PE. SLA advertised thru BGP update
message from PE to CE, with PE's AS number and any other prefix message from PE to CE, with PE's AS number and any other prefix
establishes SLA for that specific prefix, subset of traffic under CE establishes SLA for that specific prefix, subset of traffic under CE
to PE link. to PE link.
Even though this example is in the context of IP prefixes, SLA Even though this example is in the context of IP prefixes, SLA
exchange does not have to be limited to the IP address family only. exchange does not have to be limited to the IP address family (IPv4
SLA advertisement is generic to all forms of NLRI types that are and IPv6). SLA advertisement is generic to all forms of NLRI types
supported by the BGP protocol specification (like IPv4, IPv6, VPN- that are supported by the BGP protocol specification (like IPv4,
IPv4, VPN-IPv6). 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, the originator MAY is of the neighbor BGP speaker's. Alternatively, source AS and
not encode source/destination AS numbers (that is the source AS is destination AS count MAY be set to 0.
set to 0 and destination AS count is set to 0), in the QoS attribute.
The most 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
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 a specific list of update message. If such an update is meant to be for a specific list
AS(es) as receivers, then the list of destination AS MUST be of AS(es) as receivers, then the list of destination AS MUST be
explicitly described in the QoS attribute message to avoid flooding explicitly described in the QoS attribute message to avoid flooding
of the QoS attribute data in the network beyond those destinations. of the QoS attribute data in the network beyond those destinations.
When a new prefix is added in the AS, AS for which SLA parameters When a new prefix is added in the AS, AS for which SLA parameters
have already been advertised before for other existing prefixes, and have already been advertised before for other existing prefixes, and
if traffic to this new prefix is subject to the same SLA advertised if traffic to this new prefix is subject to the same SLA advertised
earlier then BGP update for this new prefix may include QoS attribute earlier then BGP update for this new prefix may include QoS attribute
containing just an SLA id, an id that was advertised earlier. The containing just an SLA id, an id that was advertised earlier. The
corresponding Update message does not require to have the whole SLA corresponding Update message does not require to have the whole SLA
content. SLA id is sufficient to relate SLA parameters to new content. SLA id is sufficient to relate SLA parameters to new
advertised prefix. advertised prefix.
When BGP update messages are triggered as a result of SLA policy
change and thus only for the purpose of SLA exchange, 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 a
list of destination ASes, then the message MUST be dropped only after
all 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 a list of destination MAY process the QoS attribute. If advertised SLA has a list of
ASes, it MAY trim list and so count of destination AS to exclude ones destination ASes, it MAY trim the list and so count of destination AS
that are not required in further announcement of BGP updates. 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 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. there is no more AS from the destination list in the forwarding path.
The rest of the QoS attribute contents MAY be forwarded if there The rest of the QoS attribute contents MAY be forwarded if there
exist other sub-types of QoS attribute and forwarding rules meets exist other sub-types of QoS attribute and forwarding rules meets
other sub-types requirements. If there is no other sub-types in the other sub-types requirements. If there is no other sub-types in the
QoS attribute content then the node MUST drop the QoS attribute all QoS attribute content then the node MUST drop the entire QoS
together. The other attributes and NLRI information may be announced attribute all together. The other attributes and NLRI information
further if they meet rules defined by other attributes and BGP may be announced further if they meet rules defined by other
protocol. attributes and BGP protocol.
If the most significant bit in the QoS attribute flag is set to 1
then the entire BGP update message MUST be dropped if there are no
destinations left in the list to advertise to.
Except extracting the entire SLA sub-type of the QoS attribute and Except extracting the entire SLA sub-type of the QoS attribute and
trimming the list of destination AS list and inserting NLRI at the trimming the list of destination AS list, all other content MUST NOT
Aggregator node, all other content MUST NOT be modified by any be modified by any intermediate receivers of the message.
intermediate receivers of the message.
5.2. BGP Node not Capable of Processing QoS Attribute
If the BGP node is not capable of processing QoS attribute, it MUST
forward the QoS attribute message unaltered.
5.3. Aggregator
It is RECOMMENDED to not aggregate prefixes from 2 or more BGP update
messages into one BGP update, when original messages contain the QoS
attribute with SLA sub-type contents. If Aggregator MUST aggregate
them then it MUST copy entire parameter set of an SLA sub-type from
the QoS attribute in the new aggregated BGP update message. At the
same time, it MUST also insert NLRI information, from the original
update message, as an optional advertiser id to go along with source
AS inside the QoS attribute.
To support SLA exchange multiple hops away in the path that has one
of the forwarding node acting as an Aggregator, it is required that
the Aggregator node is capable of processing the QoS attribute.
6. SLA Attribute Handling at Receiver 5.2. SLA Attribute Handling at Receiver
Reception of and processing of advertised QoS SLA content are Reception of and processing of advertised QoS SLA content are
optional for the receiver. optional for the receiver.
While reacting to SLA advertisement While reacting to SLA advertisement
- receiver SHOULD invalidate previous advertised SLA parameters if - receiver SHOULD invalidate previous advertised SLA parameters if
one exists for the same SLA id and source AS. If new advertised one exists for the same SLA id and source AS. If the new
SLA update is with non-zero Traffic Class count, new advertised advertised SLA has a non-zero traffic count, then the new
SLA SHOULD be installed. If new advertised SLA update is with advertised SLA SHOULD be installed. If new advertised SLA update
Traffic Class count 0, no action is required. is with Traffic Class count 0, then no action is required.
- If advertised QoS Attribute, inside an update message, is with a - When BGP update messages are triggered only as a result of SLA
flag set indicating to drop that message, a receiver MUST drop policy change, BGP update message forwarding beyond intended
message if it is the last receiver, in update path, that message receivers are not necessary. If receiver device implementation
is advertised to. supports policy based filtering then receiver MAY implement a
policy to filter such messages based on prefix and attribute.
If the advertised SLA is from the next hop, in the reverse path, the If SLA advertised to the next hop neighbor, the receiver may
receiver may implement advertised SLA for the whole link, the link implement advertised SLA for the whole link, where the link could be
could be physical or virtual link, associated with the next hop. If physical or virtual link, connected to the neighbor. If SLA
NLRI advertised in update message is not of the next hop, receiver advertised to is not the next hop neighbor then receiver may
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 it should accept advertised SLA and for which ones it which prefixes it should accept advertised SLA and for which ones it
won't. won't.
For cases where if earlier messages have not reached the intended 6. Error Handling
receiver yet, a re-signaling is required. A receiver may intend to
request an SLA message from the originator in such case. Since BGP
messages are considered reliable, it is assumed that advertised
messages always reach intended receivers. Thus 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 Error conditions, while processing of the QoS attribute, SHALL be
mentioned in [IDR-ERR] MAY be used in the event QOS attribute parsing handled with the approach of attribute-discard as described in [IDR-
results in any attribute errors. Alternatively, an approach of ERR]. In such condition, receiver SHOULD also cleanup any previously
"treat-as-withdraw" MAY be used as mentioned in [IDR-ERR] if an installed SLA state for the same prefix.
implementation also wishes to withdraw the associated prefix.
6.1. Traffic Class Mapping 7. Traffic Class Mapping
It is possible that switching/routing methods used in 2 different It is possible that switching/routing methods used in 2 different
ASes could be different. For example, Provider may tunnel Customer's ASes could be different. For example, Provider may tunnel Customer's
IP traffic thru MPLS cloud. In such cases traffic class definition IP traffic thru MPLS cloud. In such cases traffic class definition
for QoS services may differ in both ASes. For the meaningful use of for QoS services may differ in both ASes. For the meaningful use of
advertised SLA in such cases, receiver is required to map traffic advertised SLA in such cases, receiver is required to map traffic
class from one type to the other. class from one type to the other.
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 would be MPLS TC-based. Thus for advertised MPLS TC-based SLA would
require to map traffic class from IP Diffserv-based to MPLS TC type. require to map traffic class from IP Diffserv-based to MPLS TC type
[RFC3270].
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, eg. RFC3270 for mapping between
recommendations for traffic class mapping or MAY define its own as DSCP and MPLS TC. Receiver MAY use those defined recommendations for
per its network Traffic Class service definition to map to advertised traffic class mapping or MAY define its own as per its network
Traffic Classes. It is completely up to the receiver how to define Traffic Class service definition to map to advertised Traffic
such traffic class mapping. Classes. It is completely up to the receiver how to define such
traffic class mapping.
7. Deployment Considerations 8. Deployment Considerations
One of the use cases is for a Provider to advertise contracted SLA One of the use cases is for a Provider to advertise contracted SLA
parameters to Customer Edge (CE). The SLA parameters are provisioned parameters to Customer Edge (CE) in cases where eBGP is deployed
by the provider on the PE device (facing CE). This provisioned SLA between PE and CE. The SLA parameters may already be provisioned by
the provider on the PE device (facing CE). This provisioned SLA
parameters are then advertised thru proposed BGP QoS attribute to the parameters are then advertised thru proposed BGP QoS attribute to the
CE device. CE device may read the attribute and SLA sub-type content CE device. CE device may read the attribute and SLA sub-type content
to implement the QoS policy on the device. to implement the QoS policy on the device.
Contracted SLA from PE to CE may be full line-rate or sub line-rate Contracted SLA from PE to CE may be full line-rate or sub line-rate
or finer granular controlled services. SLA advertise can be useful or finer granular controlled services. SLA advertise can be useful
when contracted service is sub-rate of a link and/or when for finer when contracted service is sub-rate of a link and/or when for finer
granular traffic classes that are controlled (e.g. voice, video granular traffic classes that are controlled (e.g. voice, video
services may be capped to certain rate) services may be capped to certain rate)
_______________ _______________
__________ / \ __________ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
|CustomerSite|-----| Provider | |CustomerSite|-----| Provider |
\ C/E P\E / \ C/E P\E /
\__________/ \ / \__________/ \ /
\_______________/ \_______________/
AS 3 AS 2 AS 3 AS 2
skipping to change at page 20, line 42 skipping to change at page 19, line 19
\ 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 SLAs among different network Another use case can be to advertise SLAs among different network
sites within one Enterprise network. In Hub and Spoke deployments, sites within one Enterprise network. In Hub and Spoke deployments,
Administrator, being aware of each Spoke's SLA, may define SLAs for Administrator may define SLAs at spoke and advertise QoS SLA
each of them at the Hub and advertise them thru BGP updates, where at parameters to the Hub thru BGP updates. In the figure below, each
each Spoke, advertised SLA may translate to a forwarding policy. In spoke (AS1 and AS2) are connected to Hub (AS3) via a VPN tunnel. As
a scale network, managing a large number of Spokes can be complex. shown, AS2 can advertise SLA to AS3 in the context of that tunnel ip
The proposal in such cases would be to provision SLA parameters at address.
the Hub only and distribute them to each Spoke with SLA exchange
protocol described here.
Alternatively, in a network that supports SLA parameters signaling
capabilities with the Provider, 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 can advertise the same or a 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 \_______________/ \________/
skipping to change at page 21, line 34 skipping to change at page 20, line 5
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 = AS1 tunnel address NLRI = AS1 tunnel address
Deployment options are not limited to involving CEs, PE-to-CE or CE- Deployment options are not limited to involving CEs, PE-to-CE or CE-
to-CE, only. For any contract between two providers, SLA parameters to-CE, only. For any contract between two providers, SLA parameters
may be advertised from one to the other. may be advertised from one to the other.
8. Acknowledgements 9. Acknowledgements
Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for Thanks to Fred Baker, David Black, Sue Hares and Benoit Claise for
their suggestions and to Christian Jacquenet, Ken Briley, Rahul their suggestions and to Christian Jacquenet, Ken Briley, Rahul
Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier for Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Duvivier,
the review. Bruno Decraene for the review.
9. IANA Considerations 10. IANA Considerations
The proposal in this document defines a new BGP attribute. IANA This document defines a new BGP optional transitive path attribute,
maintains the list of existing BGP attribute types. A new type to be called QoS Attribute. IANA action is required to allocate a new
added in the list for the QoS attribute. code-point in the BGP path Attributes registry.
The proposal also defines a list for Service types associated to IANA is requested to create a registry for QoS Attribute subTypes.
Traffic Class. IANA will be required to maintain this list for This is a registry of 1 octet value, to be assigned on a standards
Traffic Class Service type as a new registry. Where-as Traffic Class action/early allocation basis. The initial assignments are:
Element types, defined in the proposal, refer to existing IPFIX IANA
types.
Proposed definition of Traffic Class Service Types QoS Attribute subTypes
0x00 = reserved - - - - - - - - - - - -
0x01 = TRAFFIC_CLASS_TSPEC Reserved 0x00
0x02 = L2_OVERHEAD SLA 0x01
0x03 = MINRATE_IN_PROFILE_MARKING
0x04 = MINRATE_OUT_PROFILE_MARKING
0x05 = MAXRATE_IN_PROFILE_MARKING
0x06 = MAXRATE_OUT_PROFILE_MARKING
0x07 = DROP_THRESHOLD
0x08 = RELATIVE_PRIORITY
0x09 = SUB_TRAFFIC_CLASSES
10. Security Considerations IANA is requested to create a registry for SLA Event Types. This is
a registry of 4-bits value, to be assigned on a standards action/
early allocation basis. The initial assignments are:
There is a potential for mis-behaved AS to advertise wrong SLA, QoS Attribute SLA Event Types
stealing identity of another AS. This resembles to problems already - - - - - - - - - - - - - - -
identified and resolved, in the routing world, thru reverse path Reserved 0x00
forwarding check. One proposal, inline to RPF, to resolve such ADVERTISE 0x01
threats is to have each BGP speaker node, in the forwarding path,
perform reverse path check on source AS. Since we expect these
messages to originate and distributed in the managed network, there
should not be any risks for identity theft. Thus reverse path check
is not considered in this proposal nor have we considered any
alternates. Such solutions can be explored later if any such need.
11. References IANA is requested to create a registry to define QoS SLA Direction.
This is the direction in forwarding path, advertised QoS SLA is
applicable to.
11.1. Normative References QoS SLA Direction
- - - - - - - - -
Reserved 0x00
to Source AS from destination AS 0x01
from source AS to destination AS 0x02
QoS SLA Traffic Class Element Types will be referring to existing
IPFIX IANA types as described in section 3.1.
IANA is requested to create a registry for QoS SLA Traffic Class
Service Types. This is a registry of 2 octet values, to be assigned
on a standards action/early allocation basis. The initial
assignments are:
Traffic Class Service Type
- - - - - - - - - - - - - -
Reserved 0x00
TRAFFIC_CLASS_TSPEC 0x01
L2_OVERHEAD 0x02
MINRATE_IN_PROFILE_MARKING 0x03
MINRATE_OUT_PROFILE_MARKING 0x04
MAXRATE_IN_PROFILE_MARKING 0x05
MAXRATE_OUT_PROFILE_MARKING 0x06
DROP_THRESHOLD 0x07
RELATIVE_PRIORITY 0x08
SUB_TRAFFIC_CLASSES 0x09
11. Security Considerations
The QOS attribute defined in this document SHOULD be used by the
managed networks for enforcing Quality of Service Policies and so
there should not be any risks for identity thefts. To strengthen the
security for the QOS attribute, RPKI based origin validation
[RFC7115] MAY be used. In addition to the RPKI based origin
validation, BGP Path Validation [I-D.ietf-sidr-bgpsec-protocol]
procedures could be used over BGP QOS attribute and its associated
prefix in producing the digital signature that can be carried within
the signature SLA for the messages. This would help prevent any man-
in-the-middle attracks.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, of Guaranteed Quality of Service", RFC 2212,
September 1997. DOI 10.17487/RFC2212, September 1997,
<http://www.rfc-editor.org/info/rfc2212>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
Protocol 4 (BGP-4)", RFC 4271, January 2006. P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[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, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
STD 67, RFC 4506, May 2006. Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <http://www.rfc-editor.org/info/rfc4506>.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export", Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008. RFC 5102, DOI 10.17487/RFC5102, January 2008,
<http://www.rfc-editor.org/info/rfc5102>.
11.2. Informative References [RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014,
<http://www.rfc-editor.org/info/rfc7115>.
[IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Message, I-D.draft-
ietf-idr-error-handling", June 2012.
12.2. Informative References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[IDR-ERR] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
"Revised Error Handling for BGP UPDATE Message, Connectivity Provisioning Profile (CPP)", RFC 7297,
I-D.draft-ietf-idr-error-handling", June 2012. DOI 10.17487/RFC7297, July 2014,
<http://www.rfc-editor.org/info/rfc7297>.
[CPP] Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS [BGP-SEC] Lepinski, M., "BGPsec Protocol Specification, I-D.draft-
Connectivity Provisioning Profile, I-D.boucadair- ietf-sidr-bgpsec-protocol", June 2015.
connectivity-provisioning-profile", Sep 2012.
[CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning [CPNP] Boucadair, M. and C. Jacquenet, "Connectivity Provisioning
Negotiation Protocol (CPNP), I-D.boucadair-connectivity- Negotiation Protocol (CPNP), I-D.boucadair-connectivity-
provisioning-protocol", May 2013. provisioning-protocol", Sep 2014.
[BGPSLA-IMPL]
Shah, S. and K. Patel, "Inter-domain SLA Exchange
Implementation Report, I-D.draft-svshah-idr-sla-exchange-
impl", Feb 2015.
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
 End of changes. 116 change blocks. 
354 lines changed or deleted 366 lines changed or added

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