One document matched: draft-lee-mpls-te-exchange-00.txt
Internet Engineering Task Force C-Y Lee
INTERNET DRAFT A Celer
N Gammage
S Ghanti
Nortel Networks
November 2000 Gerald Ash
AT & T
Distributed Route Exchangers
<draft-lee-mpls-te-exchange-00.txt>
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The current link state routing protocols flood link states to all
routers so that routers have the information required to compute the
shortest paths to route packets on a hop by hop basis. However, for
the purpose of establishing MPLS paths, constraint paths are only
required at certain nodes, for instance, at the node where path setup
is triggered or at the head-end of a loosely routed segment that
crosses a network (or area) boundary. In addition, it not possible to
have all required constraints present in all nodes in a network, nor
is it always feasible for nodes setting up paths to compute the
constraint paths themselves, a notable example is when a path
traverses network or area boundary. These reasons motivate a
solution using a subset of routers (called route exchangers), to
collect constraint information and exchange it with other route
Expires June 2001 [Page 1]
Internet Draft Distributed Route Exchangers November 2000
exchangers. Route exchangers store traffic engineering link states
and other types of constraint information and compute the explicit
routes required by routers establishing paths. Hence, constraint
information need only be distributed to the subset of nodes which
help compute constraint paths in the network.
1. Introduction
The current link state routing protocols flood link states to all
routers so that routers have the information required to compute the
shortest paths to route packets on a hop by hop basis. However, for
the purpose of establishing MPLS paths, constraint paths are only
required at certain nodes, for instance, at the node where path setup
is triggered or at the head-end of a loosely routed segment that
crosses a network (or area) boundary. In addition, it not possible to
have all required constraints present in all nodes in a network, nor
is it always feasible for nodes setting up paths to compute the
constraint paths themselves.
In particular, summarized inter-area routes do not provide sufficient
information for a node to compute the constraint path required across
areas. In this case, the node can request the transit area border
router (functioning as route exchangers as well) to compute the
explicitly routed path on its behalf. The area border router may
recurse this request if the destination is in yet another area.
Further, it is not always feasible to compute constraint paths
independently at each node, because some constraint information must
be coordinated at a centralized server. Therefore, some constraint
paths must be computed at a constraint route server. To provide
redundancy and load balancing, a number of these servers are
distributed in the network, and they can be co-located with the route
exchangers to facilitate constraint path computation.
The above reasons provides the motivation for a solution which allows
a subset of routers (called route exchangers) to collect traffic
engineering link states and exchange it with other route exchangers.
Route exchangers store traffic engineering link states and other
types of constraint information and compute the explicit routes
required by routers establishing paths.
It should be noted that the total number of link states received by a
route exchanger is no more than, and in general less than the total
number of link states received by a router if the link states are
flooded instead.
2. Overview
The memo describes a solution using distributed route exchangers to
Expires June 2001 [Page 2]
Internet Draft Distributed Route Exchangers November 2000
collect traffic engineering link states and exchange it with other
route exchangers. Route exchangers store traffic engineering link
states and compute the explicit routes requested by routers (e.g.
edge routers or nodes setting up backup segments) establishing paths.
Note that route exchangers may be co-located on edge or border
routers. The rest of this memo focus on how OSPF can be modified to
disseminate constraints to a subset of routers. IS-IS can be extended
in a similar way.
Route exchangers or traffic engineering exchangers (TE-Xs) advertise
their capability via router link state advertisements (router-LSAs),
allowing OSPF routers in an area to discover all the TE-Xs in the
area. An OSPF router sends its traffic engineering link state
advertisements (te-LSAs) directly to the nearest TE-X, instead of
flooding them to all interfaces. A TE-X disseminates link states it
receives from nearby OSPF routers, to other TE-Xs in an area, via a
designated TE-X.
TE-Xs in an area send Hello messages to each other and elect a
designated and backup designated TE-X (DR TE-X, BDR TE-X,
respectively), in the same manner as OSPF DR and BDR are elected.
The DR TE-X peers with all other TE-Xs in an area and distributes the
traffic engineering link states it learnt from a TE-X to other TE-X.
The BDR TE-X peers with all other TE-Xs in an area and but do not
distribute the traffic engineering link states it learnt from a TE-X
to other TE-X. The backup designated TE-X assumes the role of the
designated TE-X when the designated TE-X goes down. The reason for
having the BDR TE-X peers (which involves TE LSDB synchronization)
with other TE-Xs is to reduce the time it takes to "switch" to the
BDR TE-X when a DR TE-X becomes unreachable. Otherwise the BDR TE-X
has to synchronize its TE LSDB with all other TE-Xs before it can
assume the role of DR TE-X.
To setup an explicit path, if a router is a TE-X, it has the traffic
engineering link state database, and is able to compute the explicit
path. If the router is not a TE-X, it : a) discovers TE-Xs via
normal router-LSAs as described above. b) queries the nearest TE-X
for a route satisfying the constraints specified. The TE-X should
return an explicit set of routes (the Explicit Route Object (ERO), as
specified in MPLS). The exact semantics of the query and response
message [PATH_QUERY]is out of scope of this memo.
An area border router (ABR) should be a TE-X in each area it is
attached to by default. This facilitates TE inter-area link states
summarization, dissemination as well as TE path setup. At this point
it is not clear whether it is necessary to mandate ABRs be TE-Xs,
although as mentioned there are advantages in having ABRs be TE-Xs.
In particular if te-summary LSAs are not available, a node may query
Expires June 2001 [Page 3]
Internet Draft Distributed Route Exchangers November 2000
the transit ABR for the explicit constraint path instead. An ABR may
summarize TE link states, i.e te-summary-LSAs in an area and sends
them to the DR and BDR TE-Xs in other areas it is attached to. If
the ABR is not a DR or BDR TE-Xs in an area, it receives te-summary-
LSAs from other areas via the DR in that area.
3. Advantages and Disadvantages
3.1 Advantages
This solution allows link state routing protocols such as OSPF to be
extended to distribute constraint resource information, for the
purpose of establishing explicit paths, using less total network and
routers resources (in terms of bandwidth, processing, and routing
information storage) than if the constraint link states are flooded
instead. The extension is well suited for constraint route
distribution in an optical network where it is not always feasible to
flood large amount of constraint information and where the port
density is high. In particular, it improves the efficiency of
inter-area path setup because it enables a node to determine if an
inter-area path is able to meet the constraints specified and obtain
the complete explicit path if needed, before the inter-area path
setup is attempted. Further, constraint link state database
convergence time is also reduced since constraint link states need
not be: i) processed nor acknowledged hop by hop. ii) "damped" to
reduce the disruption to the network caused by flooding link states.
If each router in a network originates l number of LSAs and flood the
l LSAs on p number of ports, a router in a network could potentially
receive up to n*l*p number of LSAs, in a network with n nodes.
Therefore, the total number of LSAs flooded and processed in the
network is of order n squared (and could potentially be close to
n*n*l*p). If each router in a network originates l number of te-LSAs
and send the l LSAs directly to the TE-X, only the TE-Xs receives n*l
number of LSAs. Note that l LSAs are not flooded on all ports of the
router. In this case, the total number of LSAs processed in the
network is close to x*n*l, where x is the number of TE-Xs in the
network. Since x can be a lot smaller than n, this proposal reduces
the total te-LSAs flooded, processed and stored in a network, or in
other words the total amount of network and node resources required
for te-LSAs, is reduced from O(n squared) to O(n), in a network with
n nodes. Clearly, the total number of link states received by a TE-X
is no more than, and in general significantly less than the total
number of te-LSAs received by a router if the te-LSAs are flooded
instead.
The te-LSAs are not flooded like normal LSAs used to calculate the
"shortest path". Hence a router only sends out one copy of its te-
Expires June 2001 [Page 4]
Internet Draft Distributed Route Exchangers November 2000
LSAses and the te-LSAs are forwarded directly to the nearest TE-X,
without incurring processing delay including acknowledgment on every
hop, which occurs when link states are flooded. Similarly, a TE-X
sends te-LSAs directly to other TE-Xs via the peering with other TE-
Xs. Consequently, the time for the traffic engineering link state
database (TE LSDB) to converge within the routing domain is reduced.
Routers not involved in acquiring explicit paths (e.g for the purpose
of initiating the establishment of explicit paths or to obtain the
explicit hops in the loose segment of a loose source route) are not
burdened with processing and storing additional te-LSAs (in addition
to normal link states) that they do not need.
Inter-area route summarization is done by ABRs which by default (for
reasons mentioned before) are TE-Xs, and the ABRs send the te-
summary-LSA directly to the DR and BDR TE-Xs in other areas, instead
of flooding them in the routing domain. Hence the same advantages
described in the previous paragraph applies here. An important
advantage for inter-area path computation is the feasibility for an
ABR to provide explicit route (which have sufficient resources or
meeting the constraints specified) for another area. For instance
node A in area 1 wants to setup a path to node B, which is in the
backbone. The ABR serving the area where node A is located is able to
provide the route meeting the constraints required by A, all the way
to B, either as a complete explicit route or it may consist of a
loose source route portion for the path between the ABR and B. In
either case, this improves inter-area path setup and reduces the
probability of (a) path setup failures or crankbacks (b) available
resources not being used, due to the lack of inter-area constraint
route summarization or insufficient information provided by route
summarization.
Routers which support constraint or traffic engineering path setup
(called OSPF-TE in this memo) need to have the functions specified in
"Changes to OSPF routers originating te-LSAs" of this memo. However
it is feasible to do only a software upgrade on existing Label
Switching Routers (LSRs) with OSPF-TE support since there are very
little processing and storage impact on the routers, compared to the
case where all routers in a domain have to process te-LSAs. The more
heavy weight processing and storage requirement is at the TE-X, where
the processing and storing of large number of te-LSAs and TE routes
computation is performed. Large number of constraint link states
that are not dynamic in nature can be distributed to TE-Xs during TE
database initialization and downloading and used by TE-Xs for
constraint route computation later.
Constraint information not specific to particular links or or that
cannot be downloaded to every node or that must be configured in a
coordinated manner eg on a server can be distributed to TE-Xs by a
Expires June 2001 [Page 5]
Internet Draft Distributed Route Exchangers November 2000
server which is functioning as a TE-X. This allows a TE-X to take
into account such constraints during constraint path computation.
This proposal avoids the single point of failure and the performance
bottleneck inherent in solutions based on a centralized server, by
disseminating constraint information to distributed TE-Xs.
3.2 Disadvantages
Routers which do not have the constraint information have to obtain
constraint paths from TE-Xs. One question is how much delay this adds
to the process of establishing paths. In general, since the bulk of
time in establishing paths is in the propagation and processing of
path setup messages (including path computation) the latency (order
of msec) to obtain a path from a nearby node is not significant. In
the case where constraint routes are required for on-demand path
recovery or on-demand repair of primary paths/segments of the paths,
the time required for restoration is largely dominated by the time it
takes for routes to converge after a link failure. (Note: smaller
than 50msec recovery requires protection switching of pre-established
backup paths or segments). Again, the path query and response latency
is not significant relative to the route convergence time.
It is worth noting that even though constraint information states are
accessible locally at every node if constraint information are
flooded to every node, the actual path setup time may be longer than
if the constraint route is obtained from a TE-X. The reason is the
local constraint information may not be up to date. To reduce the
disruption cause by the flooding of constraint information,
constraint link state changes cannot simply be flooded whenever there
is a change. It needs need to be "damped" or suppressed for a pre-
defined period of time. Since frequent flooding may cripple a
network, especially in the case of a densely meshed network, the
tendency is to delay flooding for longer periods. The use of stale
information may cause path setup failure which would add significant
delay in the actual path setup time or it may prevent available
resources from being utilized at all.
4. Terminology
In this memo OSPF routers refers to non TE-X. OSPF routers supporting
the TE-LS distribution in this memo is referred to as OSPF-TE
routers. The normal Link State Database is referred to as LSDB and
the TE Link State Database is referred to as LSDB-TE.
5. Assumptions
The routers in the network are assumed to be connected (e.g via a
Expires June 2001 [Page 6]
Internet Draft Distributed Route Exchangers November 2000
control channel) and can be reached via shortest path routes computed
using normal LSAs flooded by OSPF.
To be able to discover another router X, a router Y must already have
connectivity to router X, either via an existing link or a control
channel setup for control messages (for e.g MPLS signalling, OSPF
control messages) between X and Y. Note that if there are multiple
parallel links between two routers, only one control channel is
required to allow the routers to learn about each other.
6. Overview of extensions to OSPF
The following sections describe the extensions required in OSPF for
nodes (i) originating te-LSAs and (ii) functioning as constraint
route or TE exchangers.
Both nodes originating te-LSAs only and nodes functioning as TE-Xs
must be able to discover the addresses of TE-Xs in an area. Only
nodes functioning as TE-Xs need to advertise themselves with the TE
option bit in the Option field of the router-LSA.
The te-LSAs originated by nodes have the same format as te-LSAs (TLVs
and sub-TLVs) described in [OSPF-KY] and [OMPLS], and the LSA is of
type 12 (TE) instead of opaque type 10 (scope area). Instead of
flooding these te-LSAs out of every adjancencies, an OSPF node sends
one copy of the te-LSAs directly to the nearest TE-X. An OSPF node
functioning as a TE-X must be able to receive the te-LSAs and send
them to the DR and BDR TE-Xs in the area. A DR TE-X must send the
te-LSAs to other TE-Xs in the area.
6.1. Changes to OSPF routers originating te-LSAs
OSPF-TE routers (non TE-Xs) originating te-LSAs send Link State
Update (LSU) directly to the nearest TE-X instead of flooding them
out. Te-LSAs are not received by other OSPF routers unless these
routers are TE-Xs.
OSPF-TE routers do not receive te-LSAs originated by other OSPF
routers, nor do they send te-LSAs to other other OSPF routers (unless
they are TE-Xs) or exchange te-LSAs with other OSPF routers.
An OSPF-TE should maintain a list of TE-Xs in an area. Each entry in
the list should contain the distance to the TE-X. How this is
accomplished is implementation dependent. One way of implementing
this is to compute the shortest path to a router which is a TE-X (as
indicated in the router-LSA), during SPF computation and either store
the distance to the TE-X in the "list of TE-Xs" data structure or as
a router entry in the OSPF routing table.
Expires June 2001 [Page 7]
Internet Draft Distributed Route Exchangers November 2000
The Router ID of TE-X should be a unique IP address identifying the
router in the Autonomous System and ideally should not be an
interface address, but an address not assigned to any interfaces. It
may be an address assigned to a "loopback" or dummy interface.
When an OSPF-TE router first comes up, it establishes adjacencies
with its neighbor(s). Once adjacencies are established (Section 7 of
[OSPF]), an OSPF-TE router determines the nearest TE-Xs. The OSPF-TE
goes through its list of TE-Xs, and caches up to two TE-Xs (the
primary TE-X and a backup TE-X), as described in "Determining nearest
TE Exchanges". TE-X capability is advertised in Router-LSA, as
described in the Section "Advertising TE Exchanges".
6.1.1 Originating te-LSAs
At initialization, prior to sending the te-LSAs the OSPF-TE router
should send a TE Database summary list and wait for acknowledgement
from the TE-X. The details of this procedure is described in "Sending
Link State Update te-LSAs".
The OSPF-TE router then proceeds to originate te-LSA describing its
connectivities or links and the constraints associated with these
connectivities and send these te-LSAs to the nearest TE-X. The te-
LSAs are defined in [OSPF-KY] with the following format :
+-----------------------+
| Standard LSA Header |
+-----------------------+
| Type, Length, Value |
+-----------------------+
There are 2 types currently defined: 1) Router TLV - describes the
always reachable address of the router 2) Link TLV - describes a
single link. The following sub-TLVs of the Link TLV - Link type,
Link ID, local/remote interface IP address describes the link and the
maximum bandwidth, maximum reservable bandwidth, resource class,
describes the constraints of that link.
Additional sub-TLVs are defined in "Additional sub-TLVs in te-LSA"
and [OMPLS] and these te-LSAs can be distributed using the mechanisms
described in this proposal.
If the TE-X does not acknowledge the te-LSA sent, the OSPF-TE router
must attempt to retransmit the te-LSA to the backup TE-X.
6.1.1.1 Sending Link State Update te-LSAs
OSPF-TE routers sends te-LSAs directly to the nearest TE-X. If an
Expires June 2001 [Page 8]
Internet Draft Distributed Route Exchangers November 2000
OSPF router do not receive a Link State Acknowledge for a te-LSA sent
to a particular TE-X after a timeout period, it sends the te-LSA to
the next nearest TE-X and reinvoke the "Determining nearest TE-X"
mechanism to find out the current serving TE-Xs.
Initially, a Database Summary List is sent and the OSPF-TE expects to
receive Link State Request of the te-LSAs originated by this OSPF-TE
that the TE-X wants to update in its database. The OSPF-TE sends the
te-LSAs to the TE-X as requested in the Link state Request message.
The difference with the OSPF database synchronization is OSPF-TEs do
not request te-LSAs from the TE-X in this proposal.
An OSPF-TE router do not initiate adjacency establishment nor
maintain adjacency or exchange hellos with a TE-X. An OSPF-TE router
is able to find out the serving TE Exchange via router-LSAs (See
"Determining nearest TE Exchanges").
6.1.2 Discovering TE Exchanges
OSPF-TE routers discover TE Exchanges via normal Router-LSA flooding,
as described in "Advertising the TE Exchange" . When an OSPF-TE
router receives a new router-LSA with "TE-X" capability bit on, it
stores the TE-X IP address in the TE-X data structure. In addition,
once the Dijkstra computation of routes to all destinations in the
network is performed, the OSPF-TE should store the cost to each TE-X
in an area, in the TE-X data structure as well.
Each OSPF-TE maintains a TE-X list for every area.
6.1.3 Determining the nearest TE Exchanges
If the edge router is a TE-X, then the nearest TE-X is itself,
otherwise, the "nearest" TE-X is the TE-X with the smallest link
costs from the router. The link costs to TE-Xs is determined from the
previous section.
Once an OSPF-TE has received the routing information in the domain,
it goes through its list of TE exchanges, starting from the nearest
TE-X, to find out which of the TE-Xs agree to serve the OSPF-TE. The
route to a TE-X is determined from the routing table calculation, in
Section 16.1 of [OSPF]. The OSPF-TE sends a probe message to each of
the TE-X in the list, until two TE-Xs agrees to serve the OSPF-TE, by
acknowledging the probe message. The nearest TE-X acknowledging the
probe message is the primary TE-X, and the next nearest TE-X
acknowledging the probe is the backup TE-X. If two TE-X are of the
same distance away, the one with the smaller difference in address
value as the Router ID of the OSPF-TE, is chosen as the primary TE-X
and the other as the backup TE-X. [Alternatively, the TE-X which
Expires June 2001 [Page 9]
Internet Draft Distributed Route Exchangers November 2000
acknowledges the probe message first is selected as the primary TE-X]
If only one TE-X responds to the probe messages, then the OSPF-TE is
served by only one TE-X, and the OSPF-TE should generate an alert
message to the router management system.
6.2 TE Exchange
TE-Xs must participate in normal OSPF route distribution, although
they may not necessarily be participating in path setup or be able to
"label switch", for instance a TE-X may be a leaf of the network,
setup to function solely as a route exchange.
6.2.1 Advertising the TE-X
A TE-X must advertise its capability in the Router LSA Option field
as shown in the Appendix. A X-bit in the Options field is defined for
this purpose.
6.2.2 TE Exchange Peering
At initialization, a TE-X behaves like a normal OSPF router, creating
adjacencies with its neighbor(s) to exchange normal (non TE) routing
information. Once a TE-X has established adjacencies and downloaded
the domain (non TE) link state database (as defined in the RFC2328),
the TE-X start to establish adjacencies or peering with other TE-Xs
in the area, that it learnt from normal (non-TE) router-LSAs (and
stored in the list of TE-Xs).
The peering with other TE-Xs is established similar to the creation
of adjacencies with OSPF neighbor(s). The TE-X sends to each TE-X in
the area Hello or Keep-Alive (the latter term is used to
differentiate from OSPF Hello) messages. Once the DR TE-X of the area
is discovered via the Keep-Alive message, the TE-X attempts to peer
with the DR TE-X. The TE-X then proceeds to exchange the te-LSAs, in
the same way as Database synchronization and Exchange of normal LSAs,
until it has obtain the full te-LSA of the routing domain.
Designated TE-X (DR TE-X) and backup Designated TE-X (BDR TE-X) in an
area are elected the same way as OSPF DR and BDR. The DR TE-X is
responsible to peer with other TE-Xs in an area.
6.2.2.1 Relaying te-LSAs to other TE-Xs
A TE-X sends te-LSAs to the DR TE-X and BDR TE-X, which in turn sends
the te-LSAs to other TE-Xs. All te-LSAs sent must be acknowledged in
the same way as normal LSAs are acknowledged.
Expires June 2001 [Page 10]
Internet Draft Distributed Route Exchangers November 2000
All TE-Xs maintain a consistent TE LSDB of the routing area by
synchronzing and exchanging te-LSAs via the peering with the DR and
BDR TE-Xs.
[Note: a TE-X does not peer with other (non TE-X) OSPF-TEs.]
6.2.3 TE-X availability
An area of a network should have at least three distributed TE-Xs
such that if one TE-X fail, a primary and secondary TE-X is always
available to serve all the OSPF-TEs, assuming the network is not
partitioned. TE-Xs should be configured in a distributed manner in a
network such that if a primary or secondary TE-X is down or not
reachable, the next closest TE-Xs can be used instead. Preferably,
TE-Xs should be positioned close to edge routers or be routers that
are connected to a large number of edge routers.
If the TE-Xs are well distributed in the network and provisioned in
regions which can easily lose connectivity to the rest of the
network, for instance if the link R2-R4 is down and the network is
partitioned, the edge routers R1 and R6 are still able to reach the
TE-X at R2. Similarly R5 and R7 is able to use the TE-X at R4.
R1---R2---R4--R5
| |
| |
| |
R6 R7
A region of the network may partition from the rest of the network
if there are not suffficient redundant connectivity to the rest of
the network. If no TE-X has been provisioned in a partitioned region
(for e.g. TE-Xs have not been appropriately distributed to compensate
for the region with a high risk of being partitioned from the network
because the region is deemed too small to have a TE-X)), then edge
routers in that partitioned region will not have TE-Xs to serve them.
In this case, (where there are no available TE-Xs in the rare event
that the network partitions) edge routers should advertise themselves
as TE-Xs to enable them to receive te-LSAs. This procedure is added
as a precaution in case not enough redundancy is designed in the
network. It should be noted that in a well designed network, network
partitioning should be a relatively rare occurence.
Hence it is expected that the situation where edge routers have no
available TE-Xs may rarely occur when a smaller region of the network
partitions. Since the total number of te-LSAs in that partitioned
Expires June 2001 [Page 11]
Internet Draft Distributed Route Exchangers November 2000
region of the network should be relatively smaller, the total number
of te-LSAs that must be exchanged between edge routers should be
relatively smaller as well, allowing normal routers to handle the
additional LSA storage and processing.
6.3 Updating resources at OSPF-TE and TE-X
Once the OSPF-TE router has setup a path (the router may be
functioning as a Label Switched Router, LSR), it should update the
TE-X of its currently available resources. The OSPF-TE should
originate new te-LSAs reflecting its available resources. The TE-X
should distribute these new te-LSAs to its peering TE-Xs. It should
be noted that all TE-Xs must have consistent TE-LSDBs, but OSPF-TEs
do not maintain TE-LSDBs. When the connectivity associated with
constraints or TE of an OSPF-TE router changes (eg due to interface
or link failure), the OSPF-TE must originate new te-LSAs reflecting
the connectivity and currently available resources. A TE-X must
replace older te-LSAs from its TE-LSDB with newer te-LSAs from an
OSPF-TE. Other peering TE-Xs should do the same when they receive the
new te-LSAs. This ensures the TE-LSDB in the routing area is
consistently up to date.
There may be instances where during a path setup LSP1, a TE-X, using
the existing TE-LSDB, may compute another path LSP2, which traverses
some of the links of LSP1. However there may not be enough resources
left for LSP2 along those links after LSP1 is established. The
necessity of having absolute up to date information should be
examined carefully. Nevertheless, the timely distribution of
available resources can be improved by leveraging on the TE-X
knowledge of resources that will be allocated, and distributing the
knowledge to other TE-Xs. A TE-X knows how much resources will be
allocated on routers when it responds to constraint route queries or
requests. The need for this optimization is currently being examined.
6.4 Loose source routing
A Label Switching Router (LSR) may obtain explicit route from a TE-X
if it is provided with Loose Source Route in a path setup signalling.
It is expected Loose Source Route will be mainly used in inter-area
path setup (where the explicit route in another area is not known).
However, as described earlier and in the next sections, an TE-X
functioning as an ABR as well is able to provide the complete
explicit route for an inter-area path. Hence a node may specify the
complete explicit route in the path setup signalling message instead
of having to use a Loose Source Route for the inter-area path.
6.5 Area Border Routers (ABRs)
Expires June 2001 [Page 12]
Internet Draft Distributed Route Exchangers November 2000
An ABR in an area should be TE-Xs in all areas that it is attached to
allow the ABR to receive te-LSAs in all the areas it is attached to
and to exchange summary te-LSAs with peering TE-Xs in other areas.
ABR TE-Xs inject te-summary-LSAs into other areas. The definition of
network summary te-LSA is not within the scope of this memo. The next
section describes how te-summary-LSAs are distributed.
As an optimization, a node setting up an inter-area path should
request the constraint path from the transit ABR TE-X. [Note that a
node can choose to request the constraint path from any other TE-X
instead, but the TE-X have to recurse that request to the transit ABR
to the destination in order to obtain the explicit route in another
area. The TE-X must then return the explicit path computed by the
transit ABR to the node. Whether a node request the constraint path
from a TE-X or a transit border router is a local decision and need
not be standardized. How a node request a path [PATH_QUERY] or how a
TE-X recurse a path request is not within the scope of this memo.]
The ABR TE-X should return either a complete explicit path or an
explicit path for the area the node resides, concatenated with loose
segments of paths in other areas. An ABR TE-X may choose to cache
the explicit routes in the loose segment for later use or "expand"
the loose segment during path setup.
6.5.1 TE route summarization distribution
An ABRs summarizes te-LSAs in an area it is attached to and send the
te-summary-LSAs directly to DR and BDR in other areas it is attached.
An ABR which is also the DR TE-X in an area summarizes the te-LSAs in
the area and relays them to DR and BDR TE-Xs in other areas it is
attached to. A DR TE-X in an area relays te-summary-LSAs for other
areas (from other ABRs) to all other TE-Xs in the area A BDR TE-X, in
an area do not relay te-LSAs or te-summary-LSAs that it receives to
any other TE-Xs in the area.
7.0 Acknowledgment
The authors would also like to thank Radia Perlman, Darek Skalecki,
Don Fedyk, Jim Boyle, Dave Katz, Loa Andersson, Tony Przygienda for
their helpful comments and suggestions.
Expires June 2001 [Page 13]
Internet Draft Distributed Route Exchangers November 2000
Appendix A - Packet Format
A.1 Options Field in LSA Header
+------------------------------------+
| X | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options Field^M
E-bit^M
This bit describes the way AS-external-LSAs are flooded, as^M
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].^M
MC-bit^M
This bit describes whether IP multicast datagrams are forwarded^M
according to the specifications in [MOSPF].^M
N/P-bit^M
This bit describes the handling of Type-7 LSAs, as specified in^M
[NSSA].^M
DC-bit^M
This bit describes the router's handling of demand circuits, as^M
specified in [DEMD].^M
EA-bit^M
This bit describes the router's willingness to receive and^M
forward External-Attributes-LSAs, as specified in [EAL].^M
O-bit^M
This bit describes the router's willingness to receive and^M
forward Opaque-LSAs as specified in [rfc2370].^M
X-bit
This bit describes the router willingness to be a TE
Exchanger to receive and distribute constraint routes as well
as compute and provide constraint paths or explicit routes
when queried
A.2 LSA Header
As described in [OSPF-KY], the te-LSA starts with the standard LSA
header, the Type is of value 12 (not flooded in an area like Type 10
Opaque LSA):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Expires June 2001 [Page 14]
Internet Draft Distributed Route Exchangers November 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | Reserved | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The rest of the TLVs and sub-TLVs in the te-LSA are as described in
[OSPF-KY].
Expires June 2001 [Page 15]
Internet Draft Distributed Route Exchangers November 2000
References
The following references are available at http://www.oiforum.org
[OIF-CONSRAINT] oif2000.109.0, "Some Routing Constraints"
Monica Lazer, John Strand
The following references are available at http://www.ietf.org
[RFC2328] RFC 2328 OSPF Version 2. J. Moy. April 1998.
[TE_OPT] draft-awduche-mpls-te-optical-01.txt
[UNIQUE-CONST] draft-chiu-strand-unique-OLCP-00.txt
[QOS_RTG] draft-ash-te-qos-routing-01.txt
[LIGHTPATH] draft-chaudhuri-ip-olxc-control-00.txt
[RFC2370] The OSPF Opaque LSA Option
[OSPF-KY] draft-katz-yeung-ospf-traffic-01.txt
[OMPLS] draft-kompella-ospf-ompls-extensions-00.txt
[CR-LDP] draft-ietf-mpls-crldp-03.txt
[OSPF_FLD] draft-pillay-esnault-ospf-flooding-01.txt
[RFC1793] RFC 1793 Extending OSPF to Support Demand Circuits.
J. Moy. April 1995.
[PATH_QUERY] http://homepages.go.com/~lcyn/draft-lee-mpls-path-
request-00.txt
Authors' Information
Cheng-Yin Lee leecy@nortelnetworks.com
Alicja Celer aceler@nortelnetworks.com
Neil Gammage gammage@nortelnetworks.com
Sudhakar Ganti sganti@nortelnetworks.com
Gerald Ash gash@att.com
Expires June 2001 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:38 |