Network Working Group Ben Abarbanel
Internet Draft IPOptical, Inc.,
Document: draft-abarbanel-idr-bgp4-te-01.txt Senthil Venkatachalam
Expiration Date: September, 2000 Alcatel, U.S.A
BGP-4 support for Traffic Engineering
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [].
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft
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
Currently, constraint routing (CR) and traffic engineering (TE)
models do not take into consideration the big picture view of IP
traffic traversing multiple autonomous systems (AS). Most of the
traffic and constraint routing is based on IGP protocols such as
OSPF/ISIS, etc. The resulting view of the Internet is limited to
one autonomous system and areas or systems within it. Hence, the
routing/forwarding functions do not select the optimum path for
packets that need to traverse several autonomous systems.
The proposal in this draft is that the BGP protocol can be utilized
to choose the best BGP routes based on traffic engineered (TE)
constraint weights. This information can be propagated between all
BGP peers and calculated by the BGP AS border routers before it is
deployed to their forwarding tables.
draft-abarbanel-idr-bgp4-te-01.txt [page 2]
1. 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 [].
2. Overview
The Internet is composed of many autonomous systems(AS). BGP acts as
the road map for selecting the best paths across these systems. Today's
Internet infrastructure does not consider the Internet as one
homogenous system but a collection of systems. Where each system is
managed autonomously by an (ISP) provider. These providers tend to
filter or block routes from each other. This in itself creates a
non-optimum routing. Constraint based routing adds a level of traffic
influence by defining the path (all the hops along the way) that a
packet should take. It does this very well within an autonomous system
and within the limitation of an OSPF/ISIS areas/levels. The area
border routers inside the AS will need to compute the best path to
other areas until the packet arrives at its destination within the
autonomous system or leaves the AS to the next Autonomous System. The
choice of which AS to select is based purely on a one dimensional
level, by looking at the minimum number of AS hops to a given
destination or providing various weights and preferences, that are
local to the AS. The BGP Multi Exit Discriminator (MED)
provides some level of inter-AS metric but is still limited to the
adjacent AS.
The approach discussed here is to view the Internet as one homogenous
entity with many AS's. Each of the AS's can have a summary weight
assigned to it based on a given traffic engineering criteria. This
weight can be a type of quality of service, such as maximum IGP
bandwidth available, maximum number of IGP hops, maximum IGP delay
across the AS from one IBGP router to the other IBGP router, maximum
bandwidth for a service class A, B, C, etc. These criteria levels are
summarized by the IGP for a given network destination in a given AS
and exported to BGP. The summarization within an AS can be achieved
using IGP constraint based routing algorithms used within link state
protocols such as OSPF and ISIS. In the case of OSPF, a new opaque LSA
is defined to propagate the summarized weights between OSPF areas.
This draft is organized as follows. Section 3 details the approach at
the BGP level between ASs and Section 4 discusses the approach at the
IGP level within an AS. The various traffic engineering weights are
discussed in Section 5. The following sections deal with the
redistribution of the traffic engineering weight information from IGP to
BGP, configuration issues, route flapping, and ISP issues. The BGP and
IGP approaches together will provide a comprehensive traffic engineering
routing system across the internet.
draft-abarbanel-idr-bgp4-te-01.txt [page 3]
3. BGP Level
The method used to propagate constraint summarization weights for each AS
is to define a new attribute which contains QOS like sub fields that can
include such parameters as bandwidth, number of hops, delay, various QOS
service classes, and so on. Historical NLRI information is contained
as well. These sub fields will be termed TE weights and each BGP router
would propagate this information to its peers. Making it possible for any
router that handles the data to have a traffic engineering view of all the
paths and their associated TE Weights for a given route to a given router.
When the BGP RIB database is loaded with TE Weight information, a TE
capable BGP router would compute based on TE manual configurations
criteria the best BGP route for a given destination. The BGP Route
Selection process is extended to support a TE way of prioritizing the best
routes for any configured destination. In which the order and preference
of the routes can be changed to give the TE weight attribute a higher
priority than other attributes. Different TE Weight types could be
manually assigned a different level of priority in order to strategize a
system where the BGP route selection criteria could be further optimized.
3.1 BGP Routes Originating in Local AS
Routes that originated within the same AS will not be calculated for
TE weights since there is no BGP optimization that can be achieved.
In this case, all TE Weight calculations are strictly done at the IGP
level. As a rule, IBGP routers will not propagate to other IBGP routers
the new TE Weight attribute for routes that originated in the same AS.
Routes that came from other EBGP peers could contain the new TE Weight
attribute which will be propagated to IBGP peers.
3.2 Route Reflector Functionality
When a Route Reflector receives an update messages with the Aggregated TE
Weight attribute it will simply add it to the BGP RIB-IN/OUT for local
use and propagate it to other IBGP peers without modifying any of its
fields.
3.3 When to Add TE Weight to BGP Update messages
When an IBGP router receives an update message from another IBGP router
for a (route) destination outside its own AS, it will consult the local
FIB database for its reachability via the corresponding update message
BGP Next Hop. Using this BGP Next Hop it will check the associated TE
summary weight provided in the FIB by the extended IGP constraint routing
calculations. It will add or compare the IGP TE summary weight with the
Aggregated TE Weight that was propagated in the update message and create
the next level Aggregated TE weight. Next, it will add the Aggregated TE
weight to the local BGP RIB and use it for the BGP route selection
process. In addition, the current router will propagate the new
Aggregated TE weight value to all of its EBGP peers except the one that
introduced the route.
draft-abarbanel-idr-bgp4-te-01.txt [page 4]
Propagation, aggregating BGP TE Weights, and deploying into the BGP RIB
and FIB tables is performed from one router to the next such that the
only TE weight that is detected by any router along an AS path is
accurate enough to cover the TE measurements from a given router to the
route's point of origin.
3.4 Route Aggregation Impacts
As routes are propagated from one AS to the next, it is possible that
providers have configured their routers to aggregate more specific routes
into general ones. This condition will cause the specific routes and
their TE Weight attributes to get lost or reduced in accuracy. In order
to keep track of this information, it is proposed that the specific
routes and their TE Weights be contained in the new TE Weight attribute
fields. It would be possible at any router along the route propagation
paths to determine the detail accuracy of the TE weights that made up the
super aggregate TE Weight.
Example 1: A single AS-Path with no route aggregation, and TE weights
are aggregated.
In AS1 In AS2 Arriving in Dest AS3
N1N2,AS1,TE1 ----> N1N2,AS2,(TE1+TE2) ----> N1N2,TE12
In AS3 all we need is the routes(N1N2) and the TE weight TE12, which is
the aggregate of TE1 and TE2.
Example 2: Aggregating routes from multiple AS-Paths, and TE weights
are super aggregated too.
In AS1 In AS2 In Dest AS3
N1N2,AS1,TE1 ----> N1N2,AS2,(TE1+TE2) --> N1N2,TE12 --> see below
In AS4 In AS5 In Dest AS3
N3N4,AS5,TE5 ----> N3N4,AS5,(TE5+TE6) --> N3N4,TE56 --> see below
At this point in AS3, routes N1N2 and N3N4 are aggregated together
to form super aggregate route N13N24,
with the aggregated TE weight of (TE12+TE56) = Super aggregated TE WEIGHT
TE1256.
In order to keep track of which routes made up TE12 and TE56 we keep
two TE Weight paths in the super aggregated route N13N24 as follows:
N13N24/TE1256 = (N1N2/TE12, N3N4/TE56) in the TE Weight Attribute field.
This list of historical routes can be as large as the number of route
aggregation points that are performed along the AS-Paths.
*Note: For each list of historical routes and TE weights, there will be
one or several TE Weight types. See section 3.5 for details.
draft-abarbanel-idr-bgp4-te-01.txt [page 5]
3.5 TE Weight Calculation Impacts
As was seen in section 3.4, routes and TE Weights are aggregated together
into less specific information and as a result the TE weights become more
and more global. This affect creates sub optimal data for choosing the
best path across a series of ASs. If there is an historical trace of
route and TE weights that created the global aggregated route, than its
possible to make more accurate decision in choosing the best BGP route.
This is done during the route selection process which is run for the same
route from multiple BGP peers. With the information in the TE Weight
Attribute its possible to look inside an aggregated route and more
precisely see its composition (sub-aggregation of routes and more
specific TE weights) and determine the best TE route and related BGP Next
Hop.
3.6 TE Weight Attribute Format
The BGP update message will contain a new Optional Transitive attribute
called TE Weight (type code ?). This contains one or several aggregated
TE Weight types and their historical sub aggregated routes and TE
weights. The amount of aggregation would depend on the number of AS's the
route had traversed from the point of origin to the current router.
A TE Weight type must have the same consistency or granularity throughout
all the routers that have the software to aggregate, calculate, and
propagate it further.
|-- Optional(1) or well known(0)
| |-- transitive(1) or non-transitive(0)
| | |-Attr Flags
| | | 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
+-|-|-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|1|1| FLAGS | Attr Type (?) | Number TE Weight Lists |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
+==============|===============|===============|===============+
+ 1st Super Aggregated TE Weight list entry |
+==============|===============|===============|===============+
| Number of TE | TE Weight | 1st Super Aggregated TE Weight|
| Weight types | Type 1 | Value |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
| 2nd TE Weight | 2nd Super Aggregated TE Weight |nth TE Weight|
| Type | Value |type |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|nth Super Aggregated TE Weight| Number of Aggregated Route |
| Value | Prefixes |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|route prefix 1| 1st Aggregated IP Route prefix |
|length | 1st, 2nd, 3rd byte |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|1st route pref| route prefix n| nth Aggregated IP route prefix|
| 4th byte | length | 1st, and 2nd byte |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|nth Aggregated IP route prefix| |
| 3rd and 4th byte | ... |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
draft-ietf-abarbanel-bgp4-te.txt [page 6]
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
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
+==============|===============|===============|===============+
+ nth Super Aggregated TE Weight list entry |
+==============|===============|===============|===============+
| Number of TE | TE Weight | 1st Super Aggregated TE Weight|
| Weight types | Type 1 | Value |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
| 2nd TE Weight| 2nd Super Aggregated TE Weight |nth TE Weight |
| Type | Value |type |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|nth Super Aggregated TE Weight| Number of Aggregated Route |
| Value | Prefixes |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|route prefix 1| 1st Aggregated IP Route prefix |
|length | 1st, 2nd, 3rd byte |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|1st route pref| route prefix n| nth Aggregated IP route prefix|
| 4th byte | length | 1st, and 2nd byte |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
|nth Aggregated IP route prefix| |
| 3rd and 4th byte | ... |
+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-++
- Each TE Weight type could be:
o Maximum Bandwidth Available
o Maximum Number of IGP Hops
o Maximum Transit Delay
o Color
o Etc.
- Each TE Weight value can be in units relevant to its use:
o For maximum bandwidth could be Megabits/second.
o For Maximum transit delay could be in milliseconds.
- Aggregated IP Route Prefix: Defines the aggregation of several
routes into a single route for a given AS.
- Route Prefix Length: The number of significant bits from the
left side or high order byte of the IP address. As defined in CIDR.
Example: IP address 10.20.30.40, High order Byte is the 10.
- Super Aggregated TE Weight: Each TE weight will have a different
algorithm for aggregation and meaning. See section 5.0 for details.
3.7 Phasing TE Weights
The use of TE weights can be manually configured on a destination route
prefix basis, and thus its possible to enable/disable TE Weights on any
BGP route. The functionality can be easily phased into an AS where some
BGP routers are TE Weight capable and others are not. The new attribute
will be Optional and Transitive which implies that older BGP routers
will be required to propagate the new attribute in update messages to
their peers.
draft-abarbanel-idr-bgp4-te-01.txt [page 7]
When not all of the BGP routers along a given TE Path support the TE
Weight attribute, the TE weight calculations is not done there and the
best BGP route selection computation will be less than optimal.
4. IGP TE Constraints based Calculations and AS Summarization for TE
The IGP level routing protocol used is generally either OSPF or ISIS.
The basic OSPF and ISIS protocols allow routing based on a static
metric. These protocols can be extended to take into consideration
various traffic engineering criteria such as unreserved bandwidth,
delay, colors, OSPF metric, etc. The approach detailed below is
oriented more toward OSPF, but will be readily extended to ISIS.
If the IGP inside a routing domain is OSPF, the AS is divided into
areas - each of which is a collection of routers and networks. The
routers within an area know the complete topology of the area by means
of LSA database synchronization with their neighbors at all times.
Through the use of the opaque LSAs [8], it is possible to maintain the
traffic engineering topology (in addition to the regular network
topology) and hence perform route calculations based on traffic
engineering criteria within an area inside an AS that runs OSPF.
However, this restricts the traffic engineering calculations to within
an area.
To determine the traffic engineering weight to any network or router
in the AS, the approach proposed for OSPF is to define a new opaque
LSA for traffic engineering that summarizes the traffic engineering
weights of every network from the perspective of an area border router
(ABR), for each area in the AS. This traffic engineering summary LSA
is analogous to the summary LSA in OSPF. More details on this work can
be found in [9].
The destination network could either lie in the same area as the ASBR,
or in a different area. If the destination network and the ASBR are in
the same area, the opaque traffic engineering LSAs as defined in [8]
for the area will suffice to calculate the traffic engineering metric
to the destination network. If the destination network lies in a
different area than the ASBR, the weight is a combination (such as
simple addition, or max) of the weight to the ABR and the weight
described in the traffic engineering summary LSA originated by the ABR
that contains the destination network. In this manner, the traffic
engineering weights for all the networks in an AS can be computed.
Hence the ASBRs will also be able to determine the aggregate traffic
engineering weights across the AS to other ASBRs and use this in the
BGP advertisements.
5. Weights
The traffic engineering weights act as a cost or distance function,
describing the quality of a path to a destination network
in traffic engineering terms. The traffic engineering weights
currently proposed are:
draft-abarbanel-idr-bgp4-te-01.txt [page 8]
1. Available Bandwidth (in bits/sec)
2. Unreserved Bandwidth (in each of several classes)
3. Colors (or class types) (8 types)
4. Transit Delay (in milliseconds)
5. IGP Metric
6. IGP Hops
These traffic engineering weights can be dynamically measured or
statically configured for each interface in a node. The weights can
be propagated within an IGP area using the opaque traffic engineering
LSA. The area border routers (ABRs) can summarize the traffic engineering
weights to destination networks in their area and flood this information
into the backbone through the use of the traffic engineering summary LSA
as proposed in [9]. The summary LSAs can then be flooded by other ABRs
into their areas.
Any ASBR can determine the TE weight to a destination network by
examining its TE database and performing a simple dijkstra like
calculation by its associated IGP. This calculation can be a real
dijkstra if the weight is additive (delay, or hops or IGP metric),
or dijkstra like if the weight is a minimum to maximum constraint
(available bandwidth, unreserved bandwidth, and colors).
Depending on the level of processing desired, the number of supported TE
weights should be configured.
These calculations result in a value for each TE Weight for each
destination network in the AS and for each ASBR across the AS.
The weights from the IGP are then exported into BGP for propagation to
its EBGP peers.
The following two subsections deal specifically with the treatment of the
available bandwidth and delay TE weights, during the calculations:
Maximum Available Bandwidth:
IBGP/IGP router within a given AS will pick the smallest available
Bandwidth link from the ingress to the egress of the IBGP to IBGP path
and use that value as the summary TE weight. Next the egress IGP will
export this information to BGP which will use and propagate it to its
EBGP peers as the first aggregated TE Weight value. As the route is
propagate to each IBGP peer in another AS, the Aggregated TE weight
value in the message is compared with the summary TE weight for the BGP
Next Hop router defined in the message. Whichever value is the smaller
of the two, will be considered the next level of aggregation value and
propagated further to the next AS.
This mechanism will continue till the route reaches the furthest points
in the Internet. This way the smallest available bandwidth value will
be used as the overall Aggregated TE Weight value for any given route
along the TE path.
Maximum Delay:
IBGP/IGP router within a given AS will obtain the delay from the
ingress to the egress of the IBGP to IBGP path and use that value as
the summary TE "delay" weight. Next the egress IGP will export this
information to BGP
draft-abarbanel-idr-bgp4-te-01.txt [page 9]
which will use and propagate it to its EBGP peers as the first aggregated
TE Weight "delay" value. As the route is propagate to each IBGP peer in
another AS, the Aggregated TE weight value in the message is added with
the summary TE "delay" weight for the BGP Next Hop router defined in the
message. The sum of the two is considered the next level of aggregation
and propagated further to the next AS. This mechanism will continue till the
route reaches the furthest points in the Internet.
*Note: See section 3.4 for Route Aggregation Impacts which must be
followed in order for this mechanism to be optimal. As mentioned
in section 3.4, historical routes/TE Weights are carried in this
new attribute for routes that are aggregated several times.
6. TE Weights Redistributed from the IGP to BGP
In order for a given router to inherit the TE weights from IGP, a
mechanism must be provided to do that. What is proposed is that the
standard FDB database contain TE summary weight fields based in each
route entry, with their TE weight type, TE weight value and
associated AS number. In other words, in all the BGP routers, the
running IGP will inject the TE summary weight information into the FDB
database and signal BGP to import it to its BGP RIB database for
propagation to other BGP peers.
7. Configuring the TE feature for BGP and IGP.
In order to minimize the amount of information produced by the TE weight
parameters across the entire Internet as described in section 3.6, it is
recommended that the TE weight be configured on at the network route's
point of origin. Implying that the AS router that originated the route
into BGP will add the TE Weight attribute and all transit routers that
propagate this route will perform the TE Weight processing when they see
the TE Weight Attribute. This way it will be possible to limit the amount
of TE Weight information being propagated across the Internet.
What is needed to manually configure the BGP Best Route Selection
criteria:
I. To Enable TE Weight Feature for a given network prefix.
a. Define each network prefix for TE Weight functionality.
Once enabled all transit BGP TE routers will process the TE Weight
aggregation and propagate the TE Weight attribute to their peers.
II. To manually configure the BGP Best Route Selection Criteria in each
BGP TE Router, configure the following parameters:
a. TE Weight Type
o Maximum Bandwidth Available (Megabits/sec)
o Unreserved Bandwidth (in each of several classes)
o Maximum Number of IGP Hops
o IGP Metric
o Maximum Transit Delay (in Milliseconds)
o Color (or class types) (8 types)
draft-abarbanel-idr-bgp4-te-01.txt [page 10]
b. TE Weight Priority
1st choice = Make this TE Weight the first choice
for best BGP route selection criteria
2nd choice = Make this TE Weight the 2nd choice
for best BGP route selection criteria
nth choice = Make this TE Weight the 2nd choice
for best BGP route selection criteria
c. Example of BGP TE Topology
AS2
+---------+ 70 MB +--------------+
| R6+------------------------------------| R7--net1--R13|
| AS5 ||70MB |/ \ 80MB| |
| R5| / \ | |
|---------+ /| \30MB | |
\ 30MB / | \------R8|
\70MB / +------------+-+
\ AS1 / |
+-------+--------|----------/+ |30MB
| R2 | 30MB | R3|\ +------+-------+
| | /-|--------|---------/ | \ | R9-net2 |
| | / | | | \60MB | 60MB / |
Source--+->R1/ | Area 0 | Area 2 | \ | / |
| \----+--------+--------\ | \ | / |
| Area 1| 30MB | R4 | \---+-R10 AS3 |
+-------+--------|-----------+ +-- -\---------+
\ \
\30MB \30MB
\ \
\+----------- --\----+
|R11----------- R12 |
| 30MB / |
| / |
| AS4 net3 |
+-------------------+
Figure 1. BGP TE Topology
draft-abarbanel-idr-bgp4-te-01.txt [page 11]
Table 1. Router R1 BGP TE Weight Table
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+++-+-+-+-+-+-+-+-+-+-+-+-++
|Entry # | Route | BGP Next Hop | Aggregated TE Weight |
| | | | Bandwidth |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+++-+-+-+-+-+-+-+-+-+-+-+-++
| 1 | NET1 | R7 via R3 | 30 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 2 | *NET1 | R5 via R2 | 70 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 3 | NET1 | R10 via R3 | 60 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 4 | NET1 | R11 via R4 | 30 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 5 | NET2 | R11 via R4 | 30 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 6 | *NET2 | R10 via R3 | 60 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 7 | NET2 | R7 via R3 | 30 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
| 8 | NET2 | R5 via R2 | 30 MB |
+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-
*Note: Although we show only one TE weight type under each AS subfield
it is possible to have multiple TE weight types and have
them prioritized by manual configurations in each BGP TE router.
In Figure 1 we see that R1 is the current router receiving Update
messages from R2, R3, and R4. All the Update message contain
the new BGP TE Weight Attribute with the weights as shown in Table 1.
From this data, we see that for NET1, Entry #2 is the best choice
amongst other NET1 entries, because it guarantees that we get 70MB
bandwidth from AS2 and AS5. Assumption, operator had configured the TE
(bandwidth) weight as the highest priority criteria.
Also for NET2 entries, entry #6 is the best choice, even though it
includes more AS hops, but it guarantees that at least 60MB of
bandwidth will be available. This case shows, how sometimes
sacrificing more AS hops for guaranteed bandwidth service could work.
8. Route Flapping and Impacts on BGP Aggregated TE Weights
In the real world route flapping is a normal occurrence. It is
expected that the router performing TE Weight Aggregation will be
notified by the IGP that routes have gone down/up and it will be
required to recalculate the aggregated TE Weight. Obviously, when a new
aggregated TE weight is defined for an aggregated route, the router
performing this calculation will be required to deploy it to its BGP
peers.
draft-abarbanel-idr-bgp4-te-01.txt [page 12]
9. BGP Confederations
Since the IGP domain will cover the entire AS, any mapping of BGP
Confederation within each of the sub-ASs will not be used for BGP TE
aggregation.
Internal Sub-AS BGP routers running either EBGP or IBGP will not
aggregate the new TE Weight attribute since that job will only be done
By the BGP ASBR routers. They will however, use these attributes in their
Route selection criteria and propagate them further to all inter/intra sub-
AS peers.
10. ISP Issues and Dependencies
TBD
11. Conclusion
As has been shown, the Internet is a complex WEB of systems within
systems. Traffic Engineering is the only solution that attempts to
control/contain the explosion of resources within routers. The technique
described in this manuscript defines a way for BGP routers to influence
and control the routing paths chosen for routes that are bound by
Traffic Engineering Weights. Thereby, enabling the Inter-AS providor a
more uniform method of allocating resources and providing gauranteed
service using BGP TE across multiple Autonomous Systems.
12. Security Considerations
The new BGP TE Weight attribute does not change the underlying security
issues inherent in the existing BGP-4 design.
13. References
[1] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li,
RFC1771, March 1995
[2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,
"Requirements for Traffic Engineering Over MPLS", RFC 2702, September
1999.
[3] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control With
Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt.
[4] Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in
Progress, Internet Draft <draft-ietf-mpls-cr-ldp-03.txt>, September
1999.
[5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",
RFC 2205, September 1997.
[6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Work in
Progress, Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt,
September 1999.
draft-abarbanel-idr-bgp4-te-01.txt [page 13]
[7] Tang, Z. et al "Extensions to CR-LDP for Path Establishment in
Optical Networks", Internet Draft <draft-tang-crldp-optical-00.txt>
September 2000.
[8] Katz, D. and Yeung D., "Traffic Engineering Extensions to OSPF",
Internet Draft <draft-katz-yeung-ospf-traffic-00.txt>
[9] Venkatachalam, Senthil and Abarbanel, B., "Traffic Engineering
Summary Extensions to OSPF", work in progress.
[10] Villamizar, "BGP Route Flap Damping", RFC2439, November 1998
14.Acknowledgments
To be supplied in future revisions.
15. Author's Addresses
Ben Abarbanel
IPOptical, Inc.
11480 Sunset Hills Rd, Suite 200E
Reston, VA 20190
email: ben.abarbanel@ipoptical.com
Senthil Venkatachalam
Alcatel USA
45195 Business Court, Suite 400
Dulles, VA 20166
email: senthil.venkatachalam@usa.alcatel.com