[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Network Working Group M. Boucadair
(Editor)
Internet Draft France Telecom R&D
Document: draft-boucadair-qos-bgp-spec-01.txt July 2005
Category: Experimental
QoS-Enhanced Border Gateway Protocol
< draft-boucadair-qos-bgp-spec-01.txt >
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 2006.
Abstract
This memo describes a proposal for exchanging QoS-enabled
reachability information between service providers. It defines new
BGP attributes to be used in order to convey QoS performance
characteristics between service providers and it describes how to use
these QoS values in order to select the best path. An example of
route selection process that takes into account the QoS performance
values enclosed in BGP messages is also detailed.
Boucadair Experimental - Expires January 2006 [Page 1]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
Table of Contents
1. Introduction................................................2
2. Conventions used in this document...........................3
3. Terminology.................................................3
4. Inter domain QoS delivery services taxonomy.................3
5. q-BGP requirements and behaviors............................4
5.1. Requirements................................................4
5.2. q-BGP behaviors.............................................5
5.3. How to set QoS-related information carried in q-BGP
messages?.................................................5
6. q-BGP specifications........................................5
6.1. Attributes..................................................6
6.1.1. QoS Service Capability......................................6
6.1.2. QoS_NLRI attribute..........................................7
6.1.3. QoS_NLRI attribute for Group-1..............................7
6.1.4. QoS_NLRI attribute for Group-2..............................9
6.1.5. Multiple paths.............................................11
6.2. Processing q-BGP attributes................................11
6.3. q-BGP Route Selection Process..............................12
6.3.1. Group-1 Route Selection Process............................12
6.3.2. Group-2 Route Selection Process............................13
6.3.2.1. QoS comparison logic.....................................14
6.3.2.2. Priority-based route selection process...................14
o Processing of route with QoS holes..........................16
7. Security Considerations....................................18
8. References.................................................18
9. Acknowledgments............................................19
10. Contributors...............................................19
11. Author's Address...........................................19
1. Introduction
QoS delivery services are seen as critical future Internet services
[IAB]. The introduction of such services requires updating network
infrastructures, including network devices capabilities, protocols,
and management tools, with appropriate technologies. From a
reachability perspective, modifications need to be brought to
existing signaling and routing protocols in order to convey richer
information in addition to best effort one. In other words,
reachability information should provide routers with pertinent
information to help the route selection decision-making process. Such
information could be for instance the QoS that will be experienced
along a given path. Therefore, Network Providers have to evolve and
update the protocols deployed in their domains in order to meet the
new requirements and then to be able to offer new sophisticated added
value services. As far as inter-domain is concerned, the issue is
crucial since all providers should deploy means to convey QoS-related
information between their domains so that QoS-based services could
Boucadair Experimental - Expires January 2006 [Page 2]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
have a world-wide scope and then be accessible for a large set of
customers.
The Border Gateway Protocol (BGP) protocol [BGP] is the de facto
protocol deployed by network providers in order to interconnect their
autonomous systems with the ones of their peers. This memo describes
how BGP could be used as a means to convey QoS-related information
between adjacent autonomous systems and then allow deployment of new
inter-domain QoS delivery services. The proposed solution is generic
and could be applied to any kind of inter-domain QoS delivery
solution that is based on the exchange of QoS-related information.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Terminology
This memo makes use of the following terms:
o Local QoS Class: A QoS transfer capability within a single SP
domain, characterized by a set of QoS performance parameters.
o Extended QC: A QoS transfer capability provided using both the
local domain and neighbor domains. An extended QC is provided by
combining the local QC of local domain with the ones of adjacent
domains. The topological scope of an extended QC extends the
boundaries of local domain.
o Domain: within this document it denotes an Autonomous System
o q-BGP (QoS-enhanced BGP): an enhanced BGP that takes into
account QoS information it carries in its messages as an input
to its route selection process.
4. Inter domain QoS delivery services taxonomy
Internet is a collection of domains interconnected together and that
exchange reachability information between them. In order to introduce
inter domain QoS delivery services, providers should exchange QoS
information in addition to best effort one. This information will be
used as an input for the route selection process and will guide the
selection of optimal paths that will be used to carry traffic
belonging to inter-domain QoS services. The QoS-related information
exchange occurs either at the service level or at the routing level.
Boucadair Experimental - Expires January 2006 [Page 3]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
Two groups of QoS delivery services have been identified and are
detailed hereafter:
o The first group of services requires propagating only an
identifier that has been agreed between adjacent peers. This
identifier could be the DSCP value used to signal an extended
QoS class. Additional QoS performance characteristics could be
negotiated but not exchanged in the routing level. In the rest
of this document, we will refer to this group as "group-1".
o The second group requires the propagation of a set of QoS
performance characteristics associated with an identifier. The
nature of the QoS-related information to be exchanged has to be
agreed between adjacent peers. We will refer to this group in
the rest of this document as "group-2".
5. q-BGP requirements and behaviors
5.1. Requirements
As stated in the introduction, BGP is the inter domain routing
protocol used to interconnect domains. This protocol is widely
deployed and activated in a big range of network nodes. One of the
risks to be taken into account when introducing new services like
inter domain QoS ones is to preserve backward compatibility.
Therefore, in order to ease introduction of these value added
services, it is recommended to reuse existing protocols and systems.
Nevertheless, these protocols should be evolved and enhanced with
additional features in order to achieve these new service objectives.
As far as inter domain routing is concerned, we will reuse BGP and
define new features in order to convey QoS-related information. This
information could only be reduced to a DS code point or be a set of
QoS performance characteristics. In the rest of this document we will
refer to this enhanced BGP as q-BGP (QoS-Enhanced BGP) protocol. When
designing extensions to be added to classical BGP, the following
requirements are to be taken into account:
o The q-BGP protocol should, as far as possible, be able to
operate independently of the inter-domain QoS delivery service
it serves. Nevertheless, q-BGP should be able to detect the
group it serves.
o q-BGP should be able to propagate topology changes without any
significant impact on the existing best-effort based network
infrastructure;
o q-BGP should be able to support all kind of services based on an
exchange of QoS-related information especially to serve the two
Boucadair Experimental - Expires January 2006 [Page 4]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
groups described above.
5.2. q-BGP behaviors
q-BGP could have several behaviors depending on the nature of the
QoS-related information carried by its messages. If q-BGP messages
carry only a QC identifier (this identifier could be a DS code-point
or a proprietary identifier), offline traffic engineering functions
are certainly complex but the q-BGP route selection process
complexity is reduced. This complexity increases when a set of QoS
characteristics are associated with each QC identifier. The route
selection process can use either the QC-identifier for all services
that take part of group-1 or the QC-identifier and QoS performance
characteristics for solutions belonging to group-2.
5.3. How to set QoS-related information carried in q-BGP messages?
q-BGP can carry QoS performance characteristics that could be
advantageously taken into account by the q-BGP route selection
process to select an optimal path. This would enable to tune the
route selection process in order to select routes according to more
sophisticated routing policies (e.g route with highest available rate
and lower delay). The QoS information inserted in q-BGP messages
could be of different nature. It could be (1) administratively
enforced. In that case it would not change too frequently. Or, it
could (2) be much more dynamic (result of an active measurement for
instance). In that case the frequency of changes could be much
higher.
Administrative setting of QoS values could be achieved either
statically or periodically. If these values are set statically, the
behavior of q-BGP will be static and the route selection process will
choose the same route. The QoS-related information doesnÆt bring
major added-value to the final behavior of the route decision making
process and freezes the state of the inter-domain routing.
Nevertheless, in the case of QoS performance characteristics values
are set periodically or dynamically, providers will deploy mechanisms
that monitor the network and then guide the setting of these values.
q-BGP will be provided by accurate information in order to select the
optimal path. The frequency between two q-BGP router configuration
operations in an administrative scheme should not be too small and
could be very small in the dynamic scheme. In case of dynamic setting
scheme, the risk is to impact routing table stability and probably
introduce oscillation phenomena.
6. q-BGP specifications
In this section we detail the specification of q-BGP. This
specification encloses new attributes introduced in order to convey
QoS performance characteristics between distinct domains. Also, we
Boucadair Experimental - Expires January 2006 [Page 5]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
detail the processing of QoS_NLRI attribute and the use of QoS
related information enclosed in BGP update message in order to select
an optimal path towards a given prefix. A new capability attribute
that allows negotiation of QoS service capability is also defined.
6.1. Attributes
6.1.1. QoS Service Capability
In order to prevent from BGP session closure due to reception of a
non supported optional parameter, IDR WG has adopted a mechanism
called capability negotiation [CAP]. Capability exchange is achieved
thanks to the specification of a new optional parameter.
As far as q-BGP is concerned, it is useful for a q-BGP peer to know
the capabilities of a q-BGP neighbor with respect to the BGP protocol
extensions. Thus, a new parameter is included in the optional
parameters of the OPEN message of a q-BGP session to indicate that
this peer supports q-BGP related attributes.
In order to indicate that a given inter-domain QoS delivery solution
belongs to a given group (either group-1 or group-2) a new parameter
called QoS Service Capability is introduced. A q-BGP speaker SHOULD
use this capability advertisement in order to indicate the group to
which an offered inter-domain QoS delivery solution belongs to, so
that q-BGP peers can deduce if they can use the 'QoS service'-related
attributes with a q-BGP speaker.
The fields of this optional parameter are set as follows:
o The capability code field is set to a value between 128 and 255
as described in [CAP];
o The capability length is set to 2;
o The capability value field is encoded as shown in Figure below:
+--------------------+--------------------+
| G1QS | G2QS |
| | |
+--------------------+--------------------+
Figure 1. QoS service capability attribute.
o The first octet (G1QS, Group-1 QoS Service) is set to 0xFF if an
offered inter-domain QoS delivery solution that belongs to
group-1 is supported;
Boucadair Experimental - Expires January 2006 [Page 6]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
o The second octet (G2SQ, Group-2 QoS Service) is set to 0xFF if
an offered inter-domain QoS delivery solution that belongs to
group-2 is supported.
6.1.2. QoS_NLRI attribute
In order to convey QoS-related information, we adopt the [QOSNLRI]
proposal that consists at introducing a new optional attribute called
QOS_NLRI attribute as the starting point. This attribute is modified
in order to support the requirements of two groups defined above. The
format of the QoS_NLRI is different depending on the group (group-1
or group-2) it serves.
The modifications are twofold:
o Information carried by this attribute:
o The [QOSNLRI] proposal allows to send only one QoS
performance characteristic per announcement. This
limitation has been relaxed within this specification since
it might be necessary to carry a list of QoS performance
characteristics in a single q-BGP UPDATE message;
o Unlike the [QOSNLRI] proposal, this specification allows to
propagate information about extended QCs that are pre-
negotiated between service peers;
o The [QOSNLRI] proposal adopts the multiple paths [Walton].
The basic q-BGP specification focuses on single path;
o The PHB identifier has been removed from the list of
possible "QoS Information Code" because of the existence of
"QoS Class identifier".
o The format of the QoS_NLRI attribute:
o Add a new field called "QoS Information length": the
purpose of this field is to indicate the number of QoS
performance characteristics that are enclosed in a q-BGP
UPDATE message.
o The lengths of "QoS Information code" and "QoS Information
Sub-code" have been reduced to 4 bits in order to reduce
the total length of the QOS_NLRI attribute. This is also
motivated by the fact that 2^4 values are sufficient to
indicate this information.
6.1.3. QoS_NLRI attribute for Group-1
Boucadair Experimental - Expires January 2006 [Page 7]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
As described above, both group-1 and group-2 solutions need to
exchange a QC identifier. This identifier is used to differentiate
between the extended QCs. Especially this is the unique additional
information that must be carried by q-BGP messages. Therefore, we
define a new QoS_NLRI attribute for group-1 solutions. The format of
this QoS_NLRI attribute is as follows:
0 7 15
+------------------------------+
|QoS Class Identifier |
+------------------------------+------------------------------+
|Address Family Identifier |
+------------------------------+------------------------------+
|SAFI |
+------------------------------+
|Next Hop Address Length |
+------------------------------+----------------------+
|Network Address of next hop (variable) |
+-----------------------------------------------------+
|NLRI (variable) |
+-----------------------------------------------------+
Figure 2. QoS NLRI attribute for Group-1.
The meaning of the fields of the group-1 QOS_NLRI attribute is as
follows:
o QoS class identifier (1 octet): this field indicates the QC
identifier as described in [DS];
o Address Family Identifier (AFI) (2 octet): this field carries
the identity of the Network Layer protocol associated with the
Network Address that follows;
o Subsequent Address Family Identifier (SAFI) (1 octet): this
field provides additional information about the type of the
prefix carried in the QOS_NLRI attribute;
o Next Hop Network address length (1 octet): the length of next
hop network address;
o Network address of Next Hop: this field contains the network
address of the next router on the path to the destination
prefix;
o Network Layer Reachability Information: This variable length
field lists the NLRI information for the feasible routes that
are being advertised by this attribute. The next hop information
carried in the QOS_NLRI path attribute defines the Network Layer
address of the border router that should be used as the next hop
Boucadair Experimental - Expires January 2006 [Page 8]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
to the destinations listed in the QOS_NLRI attribute in the
UPDATE message.
6.1.4. QoS_NLRI attribute for Group-2
As described above, group-2 solutions need to exchange both QC
identifier and a set of QoS performance characteristics. Therefore,
we define a new QoS NLRI attribute that carry several QoS values for
a given extended QC. The format of this new attribute is as follows:
0 3 7
+------------------------------+------------------------------+
|QoS Information length |
+------------------------------+------------------------------+
|QoS Information Code |QoS Information Sub-Code |
+------------------------------+------------------------------+
|QoS Information value |
+ +
| |
+------------------------------+------------------------------+
|QoS Information length |
+------------------------------+------------------------------+
|QoS Information Code |QoS Information Sub-Code |
+------------------------------+------------------------------+
|QoS Information value |
+ +
| |
+------------------------------+------------------------------+
.
+------------------------------+------------------------------+
|QoS Information length |
+------------------------------+------------------------------+
|QoS Information Code |QoS Information Sub-Code |
+------------------------------+------------------------------+
|QoS Information value |
+ +
| |
+------------------------------+------------------------------+
|QoS Class Identifier |
+------------------------------+------------------------------+
|Address Family Identifier |
+ +
| |
+------------------------------+------------------------------+
|SAFI |
+------------------------------+------------------------------+
|Next Hop Address Length |
+-------------------------------------------------------------+
|Network Address of next hop (variable) |
Boucadair Experimental - Expires January 2006 [Page 9]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
+-------------------------------------------------------------+
|NLRI (variable) |
+-------------------------------------------------------------+
Figure 3. QoS NLRI attribute for Group-1.
The meaning of the fields of the group-2 QOS_NLRI attribute is
defined below:
o QoS information length: this field carries the number of the QoS
information Code that will be sent by the q-BGP speaker in a
single q-BGP UPDATE message.
o QoS information Code: this field identifies the type of QoS
information:
o (0) Reserved
o (1) Packet rate
o (2) One-way delay metric
o (3) Inter-packet delay variation
o QoS information Sub-code: this field carries the sub-type of the
QoS information. The following sub-types have been identified:
o (0) None
o (1) Reserved rate
o (2) Available rate
o (3) Loss rate
o (4) Minimum one-way delay
o (5) Maximum one-way delay
o (6) Average one-way delay
o QoS information value: this field indicates the value of the QoS
information. The corresponding units depend on the instantiation
of the QoS information code.
o QoS class identifier: this field indicates the QC identifier as
described in [DS].
o Address Family Identifier (AFI): this field carries the identity
of the Network Layer protocol associated with the Network
Boucadair Experimental - Expires January 2006 [Page 10]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
Address that follows.
o Subsequent Address Family Identifier (SAFI): this field provides
additional information about the type of the prefix carried in
the QOS_NLRI attribute.
o Length of Next HopÆ Network address: this field carries the
length of next hopÆs network address;
o Network address of Next Hop: this field contains the network
address of the next router on the path to the destination
prefix.
o Network Layer Reachability Information: This variable length
field lists the NLRI information for the feasible routes that
are being advertised by this attribute. The next hop information
carried in the QOS_NLRI path attribute defines the Network Layer
address of the border router that should be used as the next hop
to the destinations listed in the QOS_NLRI attribute in the
UPDATE message.
6.1.5. Multiple paths
[Walton] proposes a mechanism that allows the advertisement of
multiple paths for the same prefix without the new path implicitly
replacing any previous ones. This is achieved thanks to the use of an
arbitrary identifier that will identify (in addition to the prefix) a
given path. The QoS_NLRI attributes could support this mechanism by
adding: Flags, Identifier, Length, and Prefix in the QoS NLRI
attribute. The meaning of these fields is described in [WALTON].
6.2. Processing q-BGP attributes
As described above, q-BGP peers could exchange their respective
capabilities through capability negotiation procedure. As a
consequence, q-BGP peers will indicate if they both support QoS_NLRI
attribute or not. If a q-BGP speaker does not support capability
negotiation feature, it will be hard to know in advance its behavior
when receiving QoS_NLRI attribute. Therefore, three scenarios should
be examined in order to describe the processing of QoS_NLRI attribute
by a q-BGP speaker:
o Scenario 1: If a q-BGP speaker does not support capability
feature, QoS_NLRI could be sent to this peer;
o Scenario 2: If a q-BGP speaker does not support QoS Service
Capability, no QoS_NLRI should be sent to this peer;
Boucadair Experimental - Expires January 2006 [Page 11]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
o Scenario 3: Both q-BGP peers support QoS Service Capability. In
this case, q-BGP peers could use QoS_NLRI attribute. The variant
of QoS_NLRI attribute that will be used depends on the nature of
the deployed inter-domain QoS delivery solution, either it is a
group-1 or group-2.
o When sending a QoS_NLRI attribute, the local q-BGP speaker
should set the QC identifier field to the identifier of
extended QC on the corresponding inter-domain link. In
addition, if it is a group-2 solution and if the q-BGP peer
supports group-2 QoS delivery solution, the local q-BGP
speaker should set the value(s) of ôQoS Information valueö
field(s).
o When receiving a QoS_NLRI attribute, q-BGP speaker applies
its inbound policies to grant the received announcement
depending on QC binding list. The local q-BGP speaker gets
the value of the ôQoS Class Identifierö enclosed in the
QoS_NLRI of the received announcement and checks if there
is a binding entry.
o If there is no entry in the binding list: the local
q-BGP speaker drops the received announcement.
o If there is an entry in the binding list: the local
q-BGP speaker updates the values of ôQoS
Information valueö fields enclosed in the QoS_NLRI
with the ones of bound QC.
6.3. q-BGP Route Selection Process
As far as QoS-related information is conveyed in BGP UPDATE messages,
the route selection process should take into account this information
in order to make a choice and make a tie-break between equal paths
and determine the one(s) to be stored in the local FIB. This process
could differ between solutions that belong to group-1 or group-2.
6.3.1. Group-1 Route Selection Process
For inter-domain QoS-delivery solution that belongs to group-1 only
the identifier of the extended QC is to be taken into account in
order to choose a path that will be stored in the local RIB. The
unique modification to be added to the classical route selection
process is to identify routes that serve the same destination with
similar extended QCs. Local policies could be configured by each INP
in their ASBRs.
From this perspective, the pseudo code of the modified route
selection process will be as follows:
Boucadair Experimental - Expires January 2006 [Page 12]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
=====================================================================
1. Identify the received routes that serve the same destination
2. Consider the routes with similar extended QCs
3. Apply local policies (e.g. prefer a given origin AS, cost,à).
4. If only one route has been returned
Store this route in the RIB
5. If more than one route has been returned
Apply the classical BGP route selection process.
=====================================================================
6.3.2. Group-2 Route Selection Process
For inter-domain QoS-delivery solutions that belong to group-2, q-BGP
UPDATE messages carry QoS performance characteristics together with a
QC identifier. q-BGP route selection process should exploit enclosed
QoS performance characteristics in order to determine the path that
will be stored in the local RIB. Modifications that should be added
to the classical route selection process are at least as follows:
o Identify routes that serve the same destination in the same QC
plane;
o Select a route that optimises QoS performance characteristics.
Therefore, the pseudo code of the new route selection process
becomes:
=====================================================================
1. Identify routes that serve the same destination
2. Consider routes that have the same QoS class identifier
3. Compare the QoS performance characteristics associated with
resulting routes with respect to a given comparison logic
4. Return the route that optimises the QoS performance characteristic
5. if more than one route has been returned, apply the classical BGP
route selection process
=====================================================================
Boucadair Experimental - Expires January 2006 [Page 13]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
6.3.2.1. QoS comparison logic
In this section, we discuss several approaches for comparing sets of
QoS values enclosed in q-BGP messages. Consider two QoS tuples X and
Y. These tuples consist of both the attributes (e.g. delay, jitter,
loss rate) and their values. Let the tuples consist of QoS attributes
A, B and C, and let the QoS tuple X have the values (Ax, Bx, Cx) and
let QoS tuple Y have the values (Ay, By, Cy).
Then to compare the two QoS tuples X and Y, a number of mechanisms
can be adopted. To generalise the discussion, here we assume that
ôP>Qö means that P is better than Q, irrespective of whether we are
comparing bandwidth values (where a higher numerical value represents
a better level of QoS) or delay values (where a lower numerical value
represents a better level of QoS). The proposed mechanisms are as
follows:
o Lexicographical ordering method: the QoS attributes are compared
in strict order. Thus if Ax > Ay then X is better than Y,
irrespective of the relative values of Bx, By, Cx or Cy. If Ax
= Ay then the second QoS attributes are compared: if Bx > By
then X is said to be better than Y. We refer to the route
selection process that uses this QoS comparison logic as
priority-based route selection process.
o Simultaneous comparison method: X is better than Y if Ax > Ay
and Bx > By and Cx > Cy. Similarly, Y is better than X if Ay >
Ax and By > Bx and Cy > Cx. This approach does not define a
result if some of the QoS attributes A, B, C of one tuple are
better than the second tuple but some of the QoS attributes are
worse. For example, if Ax > Ay while By > Bx then the result of
the comparison of X with Y is undefined. This approach is not
recommended to be used as QoS comparison logic in route
selection process implementations.
o Weighted ordering method: the QoS attributes are normalised to
create dimensionless values, and summed. This results in a
single value for each QoS tuple, which can be compared to
determine which tuple is better. The dimensionless values could
additionally be weighted so as to prefer one attribute over
others. The advantage of this approach is that it potentially
allows a wider range of QoS metrics to be fairly compared, for
example ôa low delay route with reasonable bandwidthö.
6.3.2.2. Priority-based route selection process
When a route selection process implements lexicographical comparison
logic, priority values must be assigned to QoS performance
Boucadair Experimental - Expires January 2006 [Page 14]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
characteristics. Then, the comparison of available routes should be
based on the use of the priority value that has been affected to each
QoS performance characteristic. The priority ordering of the QoS
performance characteristics could be commonly understood by service
providers or only configured by each provider. The philosophy of this
method is: ôfind the route that optimises the highest priority QoS-
related informationö.
Therefore, the pseudo code of the priority-based route selection
process algorithm is as follows:
=====================================================================
1. Identify routes that serve the same destination
2. Consider routes that have the same QoS class identifier
3. Consider the QoS performance characteristic that has the highest
priority, and return the routes that optimise that QoS
performance characteristic
i. If only one route is returned store this route in the local
RIB
ii. If more than one route are returned
1. Exclude the QoS performance characteristic that has
been used in the step 3 from the list of QoS
performance characteristics.
a. If there is no remaining QoS performance
characteristics, go to step 4
b. Else, go to step 3
4. if more than one route has been returned, apply the classical
BGP route selection process
=====================================================================
Example: Suppose that a q-BGP listener has received the following
routes for reaching the same destination. Each of these routes is
associated with a set of QoS performance values as follows:
o R1: minimum one way delay=150ms, Loss rate=5%
o R2: minimum one way delay=90ms, Loss rate=2%
o R3: minimum one way delay=100ms, Loss rate=3%
o R4: minimum one way delay=200ms, Loss rate=1%
Boucadair Experimental - Expires January 2006 [Page 15]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
If the q-BGP router is configured to prioritize minimum one way
delay, the selected route is R2. But if the q-BGP router is
configured to prioritize loss rate, the selected route is R4.
o Processing of route with QoS holes
Let suppose now that a q-BGP router has received from its peers, the
following routes for reaching the same destination D1. The received
routes enclose the following QoS performance values as detailed
below:
o Route R1: QoS1=90ms, QoS3=150ms, QoS4=5%
o Route R2: QoS2=30ms, QoS3=153ms, QoS4=1%
o Route R3: QoS1= 120ms, QoS2=100ms, QoS3= 60ms, QoS4=3%
o Route R4: QoS2=90ms, QoS3= 50ms, QoS4=8%
The aforementioned routes enclosed different QoS performance
characteristics. The issue is how to compare these routes?
This problem could be caused by a mis-configuration or because
provider does not support some QoS parameters. This risk in both
cases is that providers will not advertise QoS-related information
since if only one AS in the chain does not implement a QoS parameter
it will introduce a "QoS hole" in all routes that it will advertise
and then impact the announcement of this route for downstream ASes.
In order to solve this issue, two solutions could be considered:
o Solution 1: Add a new control level in the definition of l-QC.
This consists in defining mandatory and optional attributes. A
ôMandatory QoS informationö is a parameter that must be present
in the QoS_NLRI. In the case it is missing the announcement will
be dropped by q-BGP receiver. The announcement is not dropped if
an ôOptional QoS Informationö is missing. Nevertheless, the
problem of ensuring route selection consistency when optional
parameters are missing is unsolved. For solving this case, one
of options details under Solution 2 bullet could be implemented.
It is clear that all providers should have the same
understanding of the mandatory and the optional parameters in
order to preserve a consistent and coherent treatment in crossed
ASes.
o Solution 2: No additional control level is introduced in the
local QoS Class definition (all parameters are optional). In
this second solution, the risk is that service providers wonÆt
advertise routes with required QoS information that should be
Boucadair Experimental - Expires January 2006 [Page 16]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
used as guidance to meet service needs. As a consequence, group-
2 solutions become as group-1 ones because there is no control
regarding the enclosed QoS information. When a QoS parameter is
missing, two options could be considered.
o Option 1: Discard unvalued routes but keep them all if they
are all unvalued. In this case, the priority criterion is
respected and the comparison between routes is consistent.
But, the risk is that some destinations could be unreachable
if received routes do not enclose higher priority QoS
performance characteristics.
o Option 2: Always keep routes with unvalued parameter, but
perform selection for the remaining routes. The route
selection process compares between routes that have valued
the QoS parameter used as criterion in a given step. If there
still have equal routes, all routes are considered and the
route selection process checks for the route that encloses
the next QoS parameter to be used as criterion of its
selection even if these routes were not present in the
previous step. The inconvenient of this option is that the
priority criterion is not satisfied.
As a consequence, the updated pseudo code of the route selection
process is as follows:
=====================================================================
1. Identify routes that serve the same destination
2. Group routes having the same QoS class identifier
3. For each route group,
i. If the number of remaining routes is not null, check for
each route, if all mandatory QoS performance
characteristics are valued
i. If yes, add this route to remaining routes
ii. If no, drop this route
4. Consider the remaining routes
i. If the number of remaining routes is not null,
1. Consider the QoS performance characteristic that has
the highest priority, and return the routes that
optimise that QoS performance characteristic
Boucadair Experimental - Expires January 2006 [Page 17]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
a. If only one route is returned store this route in
the local RIB
b. If more than one route is returned
o Exclude the QoS performance characteristic that
has been used in the step 4.i.1 from the list of
QoS performance characteristics.
1. If there is no remaining QoS performance
characteristics, go to step 5
2. Else, go to step 4.i.1
ii. If the number of remaining routes is null, go to
step 5
6. if more than one route has been returned, apply the classical
BGP route selection process
=====================================================================
7. Security Considerations
This document does not change the underlying security issues in the
BGP protocols specifications. The security recommendations related to
BGP should be considered [BGPSEC].
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[Walton] Walton, D., et al., "Advertisement of Multiple Paths in
BGP", draft-walton-bgp-add-paths-01.txt, Work in Progress,
November 2002
[QOSNLRI] Cristallo, G., Jacquenet, C, " Providing Quality of Service
Indication by the BGP-4 Protocol: the QOS_NLRI attribute", <draft-
jacquenet-qos-nlri-00.txt>, work in progress
[DS] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998
[BGP]Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995
Boucadair Experimental - Expires January 2006 [Page 18]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
[BGPSEC] Heffernan, A., "Protection of BGP sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[CAP]Chandra, R., Scudder, J., Capabilities Advertisement with BGP-4,
RFC 3392 November 2002
[IAB]Atkinson, R., Floyd, S., "IAB Concerns & Recommendations
Regarding Internet Research & Evolution", RFC 3869, August 2004
9. Acknowledgments
The authors would also like to thank all the partners of the MESCAL
(Management of End-to-End Quality of Service Across the Internet At
Large, http://www.mescal.org) project for the fruitful discussions.
10. Contributors
o Pierrick Morand (France Telecom)
o Pierre Levis (France Telecom)
o Thibaut Coadic (France Telecom)
o Hamid Asgari (Thales Research and Technology)
o Panagiotis Georgatsos (Algonet)
o David Griffin (University College London)
o Jason Spencer (University College London)
o Micheal Howarth (University of Surrey)
11. Author's Address
Mohamed Boucadair
France Telecom R & D
42, rue des Coutures
BP 6243
14066 Caen Cedex 4
France
Email: mohamed.boucadair@francetelecom.com
Intellectual Property Statement
Boucadair Experimental - Expires January 2006 [Page 19]
Internet Draft QoS-enhanced Border Gateway Protocol July 2005
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTSOR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Boucadair Experimental - Expires January 2006 [Page 20]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/