Internet DRAFT - draft-bonaventure-bgp-qos
draft-bonaventure-bgp-qos
Internet Engineering Task Force Olivier Bonaventure
INTERNET DRAFT FUNDP
<draft-bonaventure-bgp-qos-00.txt> February, 2001
Expires August, 2001
Using BGP to distribute flexible QoS information
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes a flexible QoS attribute that can be used to
distribute QoS information with BGP. The proposed attribute allows
to associate a set of supported PHB, transit delay and bandwidth
information to an UPDATE message. The flexibility of the proposed
attribute allows each AS to decide independently which QoS
information to redistribute to its peers.
1 Introduction
In this document, we propose a mechanism to associate QoS
information to prefixes that are announced by BGP. Inside a single
autonomous system, recent work has focussed on the definition of QoS
information that can be distributed by link state routing protocols.
In the case of Interior Gateway Protocols (IGP), the focus was the
definition of the minimum set of QoS attributes that can be
Bonaventure [Page 1]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
associated to a link to support the QoS or traffic engineering
features without overloading the flooding protocol or the route
computation [SL99, KY00, KRB^+00]. At the interdomain level, the
issue to be considered is different. There are many different
autonomous systems on the global Internet with very different
requirements and needs in terms of Quality of Service. For example,
the autonomous systems that are part of a confederation could want to
distribute detailed QoS information inside the confederation while
announcing far fewer QoS information on the global Internet. An ISP
could also want to provide different types of QoS information to its
clients than to other ISPs at public interconnection points. An ISP
could want to distribute different QoS information to private peers
than to public peers. When dealing with differentiated services, an
ISP could want to announce a bandwidth limit on routes associated
with the EF PHB while no limit for routes associated with the AF
PHB.Many other situations are possible. To support these various
requirements, a flexible method to distribute QoS information is
necessary for BGP. The solution proposed in this document is equally
applicable to the global Internet as well as to BGP-based VPN
solutions [RR99, KLV^+00, CTS00].Many complex routing policies,
including some related to QoS, can be implemented by using the
communities [CTL96] or the extended communities attribute [RTR01].
However, those communities have a local semantics and their
utilization must be agreed between each pair of routers. When
considering the support of QoS across interdomain boundaries, it
would be more useful to have a flexible QoS attribute that can be
used for this purpose instead of letting each AS define its private
set of communities for almost the same purpose.
2 The QoS attribute
This document defines a new QoS attribute that can be used to
associate QoS information to an UPDATE message. This QoS attribute
applies to all NLRI information contained inside the UPDATE message.
The QoS attribute is a variable length non-transitive optional
attribute. It is encoded as follows :
- The attribute flags shall indicate that the QoS attribute is
optional, non-transitive and the extended length bit is set to
one
since the QoS attribute may be longer than 256 bytes.
- The attribute type code is to be assigned by IANA
- The length of the entire attribute is encoded in two octets
- The value of the QoS attribute is encoded as a list of triples :
Bonaventure [Page 2]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
+-------------------------------+
| PHB identification (2 octets) |
+------------------+------------+
| QoS Type(1 octet)|
+------------------+-----------------------------------+
| QoS value (4 octets) |
+------------------------------------------------------+
The QoS type code allows the definition of 256 different types of
QoS values. Out of these 256 possible values, value 0 is reserved for
future utilization, values 1-127 are to be defined by IANA while
values 128-255 are reserved for vendor specific QoS attributes. This
document defines QoS types 1-6.
2.1 PHB identification
The PHB identification is used for two purposes. First, it allows a
border router to announce the PHB that it supports. Second, by using
the the various QoS values, it is impossible to associate a specific
QoS metric to each PHB. The PHB shall be encoded as specified in
[BBCF01].
2.2 Empty QoS value
This special QoS value shall be used by a border router wishing to
announce the support of a specific PHB towards the associated prefix
without associating detailed QoS information. The QoS type for this
value is 1. In this case, the QoS value field shall be equal to
0x00000000.
2.3 Maximum Bandwidth
The maximum bandwidth QoS value shall be used by a border router to
associate a maximum bandwidth to a given PHB. This attribute shall be
used by a border router to announce, with eBGP or iBGP, the maximum
bandwidth along the path towards the associated prefix. This QoS
value differs from the maximum bandwidth community defined in
[RTR01] that is only used for iBGP.The maximum bandwidth QoS value is
reported in bytes per second and encoded as an IEEE single precision
floating point number by using the same format as proposed in
[RTR01]. The QoS type field for the maximum bandwidth QoS value is 2.
2.4 Available Bandwidth
Bonaventure [Page 3]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
The available bandwidth QoS value shall be used by a border router
to announce the available bandwidth associated with an announced
prefix. This information shall correspond to the amount of available
bandwidth on the path towards the associated prefix.The available
bandwidth QoS value is reported in bytes per second and encoded as an
IEEE single precision floating point number by using the same format
as proposed in [RTR01]. The QoS type field for the maximum bandwidth
QoS value is 3.We expect that an information that potentially varies
frequently such as the Available Bandwidth will not be distributed
through the whole Internet and that filters will be used to limit its
distribution. It could for example be used within a confederation or
for specific VPN purposes without being re-exported.
2.5 Maximum Transit delay
This QoS value is used by a border router to associate a maximum
transit delay to an announced prefix. This QoS value is an indication
of the maximum (one-way) transit delay required to reach the
farthest IP address of the associated prefix.The maximum transit
delay is reported in units of one microsecond and encoded as an
unsigned 32 bits number. The QoS type field of the maximum transit
delay QoS value is 4.
2.6 Minimum Transit delay
This QoS value is used by a border router to associate a minimum
transit delay to an announced prefix. This QoS value is an indication
of the minimum (one-way) transit delay required to reach the closest
IP address of the associated prefix.The minimum transit delay is
reported in units of one microsecond and encoded as an unsigned 32
bits number. The QoS type field of the minimum transit delay QoS
value is 5.
2.7 Required signalling
This QoS value may be used by a border router to indicate whether
or not an explicit signalling operation is required to reach the NLRI
included in the UPDATE message. A border router may wish to enforce
an explicit signalling operation to be able to perform admission
control for example. This QoS value is encoded as a 32 bits field
that contains a list of bit flags. Each flag indicates the type of
signalling operation required to utilize the route.
Bonaventure [Page 4]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Signalling |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit0 : No explicit signalling required
Bit1 : Supports RSVP for Integrated services
Bit2 : Supports RSVP for MPLS LSP
Bit3 : Supports CR-LDP for MPLS LSP
When Bit0 is set (reset), this indicates that the border router
sending the UPDATE message is able (refuses) to accept normal IP
packet towards the associated NLRI. When Bit1 is set (reset), this
indicates that the border router is willing (refuses) to process the
establishment of Integrated Services flows with RSVP towards the
associated NLRI. When Bit2 is set (reset), this indicates that the
border router is willing (refuses) to process MPLS LSP establishment
request with RSVP towards the associated NLRI. When Bit3 is set
(reset), this indicates that the border router is willing (refuses)
to process MPLS LSP establishment request with CR-LDP. The QoS type
field of the required signalling QoS value is 6. Additional bit
flags may be defined to cover other signalling methods [BPSA01]
2.8 Routes without a QoS attribute
When a BGP router receives an UPDATE message that does not contain
a QoS attribute, it may assume the following defaults :
- The set of supported PHB should be set to BE.
- The Maximum and Available bandwidth should be set to infinite or
the bandwidth of the link from which the UPDATE message is
received
(if known).
- The required signalling flags should indicate that no explicit
signalling is required
- The Minimum Transit Delay should be set to 0.
- The Maximum Transit Delay should be set to infinite.
Similar rules apply when the received QoS attribute that not
contain a value for each QoS type.
3 Aggregation and QoS attributes
Bonaventure [Page 5]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
A key issue for the scalability of the interdomain routing system
is the possibility to aggregate routes in a single announcement
[CS99]. When QoS information is associated with a prefix, the
accuracy of the QoS information may conflict with the need for
aggregation. For example, consider the network shown in figure 1.
+===========================+
| +---------------+ |
| | 12.0.0.0/8 | |
| | | |
| | EF | |
| +---------------+ |
| 10msec\ | +---------------+
| \ | | AS10 |
| AS20 R|----------|R1 R2|
| / |<-------> | AF+EF |
| 5msec / | 5msec +---------------+
| +---------------+ | <--------------->
| | 13.0.0.0/8 | | 5 msec
| | | |
| | AF+EF | |
| +---------------+ |
+===========================+
Figure 1: Simple interdomain topology
Assume that in this network, AS20 wants to advertise detailed
information about networks 12.0.0.0/8 and 13.0.0.0/8 to AS10. It this
case, the border router of AS20 would associate a maximum delay of 10
msec and the EF PHB to prefix 12.0.0.0/8. Network 13.0.0.0/8 would be
announced with the AF and EF PHB and a maximum delay of 5 msec. Based
on this information, AS10 would have to decide how to announce these
two prefixes through router R2. If AS10 wants to provide detailed QoS
information, then it should announce prefix 12.0.0.0/8 with the EF
PHB and a maximum transit delay of 20 msec and prefix 13.0.0.0/8 with
both the AF and EF PHB and a maximum transit delay of 15 msec.On the
other hand, if AS10 wants to reduce the amount of prefix announced,
then it should aggregate 12.0.0.0/8 and 13.0.0.0/8 in a single
prefix. In this case, AS10 would announce that network 12.0.0.0/7
supports the EF PHB and that the maximum transit delay to reach this
network is 20 msec.In many cases, a border router will need to
aggregate several specific routes into a single less specific route.
This aggregation will inevitably introduce approximation in the route
announced. The only way to avoid loosing QoS information is to avoid
aggregating routes. However, this solution suffers from scalability
problems.Border routers should have the highest flexibility to decide
Bonaventure [Page 6]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
which QoS information should be announced to each peer, possibly on a
prefix-by-prefix basis. We believe that it is not possible in such a
document to impose strict conditions on how a border router
propagates QoS information received from a peer. There are however
some guidelines that should be followed in the mechanisms used by a
border router to manipulate QoS information :
- When redistributing a route, a border router should try,
depending
on its policy, and whenever possible, to reduce the number of
prefixes announced.
- When a border router needs to redistribute a route, it may modify
the QoS attribute. The border router may add any QoS value
associated
with one of the PHB identifications explicitly indicated in the
received QoS attribute. It cannot add a new PHB to the set of PHB
included in the received QoS attribute. The only exception to
this
rule is when a border router receives an UPDATE message that does
not
contain the QoS attribute. In this case, this route is implicitly
valid for the Best-Effort PHB and thus the border route may add
QoS
values provided that they are associated with the Best-Effort PHB.
- A border router that receives routes with QoS information from a
peer and needs to redistribute it is in principle allowed to
update
or remove any received QoS information. The only exception to this
rule is that if a router receives a QoS attribute that does not
contain the Best-Effort PHB. In this case, the border router
cannot
entirely remove the QoS attribute. This implies that in this case
the
route should not be distributed towards a BGP router that does not
support the QoS attribute defined in this document.
- When a border router needs to update the maximum (resp.
available)
bandwidth included in a QoS attribute, it may decrease this
maximum
(resp. available) bandwidth, but cannot increase it. When
updating
the bandwidth values, it should ensure that, for each PHB, the
maximum bandwidth remains larger than the available bandwidth.
- When a border router needs to update the maximum (resp. minimum)
transit delay included in a QoS attribute, it may increase this
maximum (resp. minimum) transit delay, but cannot increase it.
When
updating the delay values, it should ensure that, for each PHB,
Bonaventure [Page 7]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
the
maximum transit delay remains larger than the minimum transit
delay.
4 Capability negotiation
To advertise the QoS capability to a peer, a BGP speaker uses the
BGP Capabilities Advertisement [CS00] This capability is advertised
using the Capability code TBD_IANA (to be defined by IANA).The fields
in the Capabilities Optional Parameter are set as follows. The
Capability Code field is set to TBD_IANA (to be defined by IANA). The
Capability Length field is set to 1. The Capability Value contains
the version of the QoS attribute. This document defines version 1 of
the QoS attribute.To obtain a bi-directional exchange of QoS
attributes between a pair of border routers, each border router must
advertise to the other the support of the QoS attribute.
5 Related work
Two extensions to BGP have been proposed recently to advertise QoS
information with BGP [AV00, Jac00].In [Jac00], the QoS information is
associated to a prefix by defining a new QOS_NLRI attribute. This
optional transitive attribute is used to associate QoS information
to an announced prefix. This document defines several types of QoS
information (reserved bandwidth, available bandwidth, minimum,
maximum and average transit delay) and the support of the AF PHB.
However, it only allows to associate a single QoS information to each
prefix. In contrast, our proposal is to define a flexible QoS
attributes that can be manipulated by BGP speakers to support
different QoS policies. We expect for example than inside a
confederation or for VPN applications, the QoS information will be
richer than on the global Internet. The flexibility of our solution
allows to easily support these requirements.
[AV00] proposes on the other hand to define new optional attributes
used to compute TE weights. This document also proposes methods to
aggregate these traffic engineering weights. The intended application
of [AV00] is to provide a mechanism similar to the BGP Multi Exit
Discriminator without being limited to adjacent AS.
6 Conclusion
In this document, we have a flexible QoS attribute that can be used
to distribute QoS information with BGP. The proposed attribute can be
Bonaventure [Page 8]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
used by a BGP speaker to announce the set of PHB that it supports and
to optionally associate specific QoS values (minimum and maximum
transit delay, available and maximum bandwidth) to each supported
PHB.
Acknowledgements
We would like to thank Christian Jacquenet, Guy Leduc, Stefaan De
Cnodder and Steve Uhlig for their very useful comments on this
document. This work was partially funded by the European Commission,
within the ATRIUM IST project.
References
[AV00] B. Abarbanel and S. Venkatachalam. Bgp-4 support for traffic
engineering. Internet draft, draft-abarbanel-idr-bgp4-te-00.txt, work
in progress, May 2000.
[BBCF01] D. Black, S. Brim, B. Carpenter, and F. Le Faucheur. Per hop
behavior identification codes. Internet draft, draft-ietf-
diffserv-2836bis-00.txt, work in progress, January 2001.
[BPSA01] M. Blanchet, F. Parent, and B. St-Arnaud. Optical bgp
(obgp): Interas lightpath provisioning. Internet draft, draft-parent-
obgp-00.txt, work in progress, January 2001.
[CS99] E. Chen and J. Stewart. A framework for inter-domain route
aggregation. Internet RFC 2519, February 1999.
[CS00] R. Chandra and J. Scudder. Capabilities negotiation with
BGP-4. Internet RFC2842, May 2000.
[CTL96] R. Chandra, P. Traina, and T. Li. BGP communities attribute.
Internet RFC 1997, August 1996.
[CTS00] J. De Clercq, Y. T'Joens, and P. De Schrijver. BGP/IPsec
VPN. Internet draft, draft-declercq-bgp-ipsec-vpn-00.txt, work in
progress, July 2000.
[Jac00] C. Jacquenet. Providing quality of service indication by the
BGP-4 protocol : the QoS_NLRI attribute. Internet draft, draft-
jacquenet-qos-nlri-01.txt, work in progress, November 2000.
[KLV^+00] K. Kompella, M. Leelanivas, Q. Vohra, J. Achirica, R.
Bonica, C. Liljenstolpe, E. Metz, C. Sargor, and V. Srinivasan.
MPLS-based Layer 2 VPNs. Internet draft, draft-kompella-mpls-
Bonaventure [Page 9]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
l2vpn-02.txt, work in progress, November 2000.
[KRB^+00] K. Kompella, Y. Rekther, A. Banerjee, J. Drake, G.
Bernstein, D. Fedyk, E. Mannie, D. Saha, and V. Sharma. IS-IS
extensions in support of MPL(ambda)S. Internet draft, draft-kompella-
isis-ompls-extensions-00.txt, work in progress, July 2000.
[KY00] D. Katz and D. Yeung. Traffic engineering extensions to ospf.
Internet draft, draft-katz-yeung-ospf-traffic-02.txt, work in
progress, August 2000.
[RR99] E. Rosen and Y. Rekhter. BGP/MPLS VPNs. Internet RFC2547,
March 1999.
[RTR01] S. Ramachandra, D. Tappan, and Y. Rekhter. Bgp extended
communities attribute. Internet draft,draft-ramachandra-bgp-ext-
communities-08.txt, work in progress, January 2001.
[SL99] H. Smit and T. Li. Is-is extensions for traffic engineering.
Internet draft, draft-ietf-isis-traffic-01.txt, work in progress,
February 1999.
A Examples
In this appendix, we provide a few examples of the utilization of
the QoS attribute. Assume first that AS1 wishes to announce to its
peers its ability to support three different PHB : Best-Effort, EF
and AF. Assume also that AS1 wishes to announce a maximum bandwidth
of 100 Mbps for BE traffic, 10 Mbps for AF traffic and 1 Mbps for EF.
In this case, it will send a set QoS attribute composed of :
{
PHB=BE;QoS-Type=2 [Maximum Bandwidth];MaxBW=100,
PHB=AF;QoS-Type=2 [Maximum Bandwidth];MaxBW=10,
PHB=EF;QoS-Type=2 [Maximum Bandwidth];MaxBW=1
}
Assume now that a border router wants to indicate that it supports
the BE PHB without associating any QoS information to this PHB. In
this case, the QoS attribute would be composed of :
{
PHB=BE;QoS-Type=1 [Empty]
}
Bonaventure [Page 10]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
Assume now a special border router (e.g. a router controlling a
label switch router) that is not able to forward IP packets at line
rate but is able to support the establishment of label switched
paths with RSVP and CR-LDP. Also assume that this router supports AF
and BE. In this case, this router should associate the following QoS
attribute to each route it is sending to a peer :
{
PHB=BE;QoS-Type=6 [Required
Signalling];[Bit0:Reset,Bit1:Reset,Bit2:Set,Bit3:Set],
PHB=AF;QoS-Type=6 [Required
Signalling];[Bit0:Reset,Bit1:Reset,Bit2:Set,Bit3:Set]
}
Another possibility is a border router that provides best-effort
service to normal IP packets but is able to provide QoS to label
switched paths established by RSVP only. In this case, it could
associate the following QoS attribute to routes announced to a peer :
{
PHB=BE;QoS-Type=6 [Required
Signalling];[Bit0:Set,Bit1:Reset,Bit2:Reset,Bit3:Reset]
PHB=AF;QoS-Type=6 [Packet switching
capability];[Bit0:Set,Bit1:Reset,Bit2:Set,Bit3:Reset]
PHB=AF;Qos-Type=2 [Maximum Bandwidth];MaxBW=100
PHB=EF;QoS-Type=6 [Packet switching
capability];[Bit0:Set,Bit1:Reset,Bit2:Reset,Bit3:Reset]
PHB=EF;Qos-Type=2 [Maximum Bandwidth];MaxBW=10
PHB=EF;Qos-Type=4 [Minimum Delay];MinTD=10msec
PHB=EF;Qos-Type=5 [Maximum Delay];MaxTD=100msec
}
This QoS information indicates that the border router supports the
BE, AF and EF PHB. For the BE PHB, there are no specified QoS
values. For the AF PHB, a LSP must be established before actual
traffic can flow and the maximum reservable bandwidth is 100 Mbps.
For the EF PHB, a LSP must also be established before actual traffic
can flow and the transit delay is expected to be between 10 and 100
msec. The maximum bandwidth reservable for EF is set to 10 Mbps.
Bonaventure [Page 11]
Internet Draft draft-bonaventure-bgp-qos-00.txt February 2001
Author's Address
Olivier Bonaventure
Infonet group
Institut d'Informatique
Facultes Universitaires Notre-Dame de la Paix
Rue Grandgagnage 21, B-5000 Namur, Belgium.
E-mail: Olivier.Bonaventure@info.fundp.ac.be
URL : http://www.infonet.fundp.ac.be
Bonaventure [Page 12]
