One document matched: draft-lee-mpls-te-exchange-02.txt
Differences from draft-lee-mpls-te-exchange-01.txt
Internet Engineering Task Force CY Lee
INTERNET DRAFT Alcatel
Expires January 2003 S Ganti
Tropic Networks Inc
A Celer
Nortel Networks
Gerald Ash
AT&T
July 2002
Distributed Route Exchangers
<draft-lee-mpls-te-exchange-02.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 path computation
is only performed 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
Lee, Ganti [Page 1]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
exchangers. Route exchangers store traffic engineering link states
and other types of constraint information and compute on demand, the
explicit routes required by routers establishing paths. Hence, link
state information need only be distributed to the subset of nodes
that 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
Lee, Ganti [Page 2]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
collect traffic engineering link states and exchange it with other
route exchangers. Route exchangers store traffic engineering link
state information 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 (DR 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
Lee, Ganti [Page 3]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
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
Lee, Ganti [Page 4]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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. In a full-meshed network of n nodes, the reduction is from
O(n^3) to O(n). 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-
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. The DR and BDR TE-Xs in turn
propagate the te-summary-LSAs to other TE-Xs in their area. 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
Lee, Ganti [Page 5]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
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
Lee, Ganti [Page 6]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
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.
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
Lee, Ganti [Page 7]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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 (the flooding scope is on virtual interfaces within an area)
instead of opaque type 10 (where the flooding scope is within an
area). Instead of flooding these te-LSAs out of every adjancencies,
an OSPF node sends the te-LSAs out on virtual interfaces only. A
virtual interface allows a node to be logically connected to another
node even though they are not physically connected. Virtual
interfaces can be realized by generalizing the virtual link
implementation in [OSPF] to allow non area border routers to have
virtual links as well. This type of virtual links are called general
virtual links in this memo.
The remote end of a general virtual link on a router R1, in this
case, as shown below can be a TE-X. The remote end of a gneral
virtual link on TE-X1 can be TE-X2, and the remote end of a general
virtual link on TE-X2 can be TE-X1. Note that TE-X1 does not have a
general virtual link where the remote end is not a TE-X (a normal
OSPF router). The remote end of a general virtual link can be
configured or learned. In this memo, the remote end of a general
virtual link is a TE-X and this remote end is learned as described in
"Discovering TE-Exchanges".
TE-X1 <---------- R1
^ ^
| |
| |
| +------------ R2
|
|
|
|
|
v
TE-X2 <---------- R3
The following text from [OSPF], Section 5 "Virtual links configured"
is modified for a general virtual link and constrast the differences
between a virtual link and a general virtual link. The remote Router
Id of general virtual links may be configured or learned on any
Lee, Ganti [Page 8]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
router and are not restricted to area border routers. General virtual
links may not be part of the backbone. They behave as if they were
unnumbered point-to-point networks between two routers. General
virtual links are brought up and down through the building of
shortest-path trees.
An OSPF node functioning as a TE-X, TE-X1 receives te-LSAs and send
them out the general virtual interfaces to the DR and BDR TE-Xs in
the area, as shown in the figure below. The remote end of the
virtual links are set to the elected DR and BDR TE-Xs in the area. A
DR TE-X must send the te-LSAs out other general virtual interfaces to
other TE-Xs in the area. The remote end of its virtual interfaces
are set to other TE-Xs in the area.
DR TE-X
^ | ^
| | |
| | |
| | |
| | |
<--+ | +--->
TE-X1 --+ | +--- TE-X2
^ ^ | | | ^ ^
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
R1 R2 | | | R3 R4
v v v
BDR TE-X
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
Lee, Ganti [Page 9]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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.
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.
Lee, Ganti [Page 10]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
OSPF router does 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 does 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
Lee, Ganti [Page 11]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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
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
Lee, Ganti [Page 12]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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. The DR TE-X 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.
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.
Lee, Ganti [Page 13]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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 sufficient 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
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. There are choices for this
update. For example, an OSPF-TE router can update the TE-X of the
change in resources immediately after every path setup or update only
when there is a siginificant change in the available resources. The
update method has significant performance impact on the constraint
Lee, Ganti [Page 14]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
path calculation as the TE_LSDB may not reflect the actual resource
usage even within one area. Updating after every path setup may have
impact on flooding traffic. 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
as it is not necessary that all path computation requests a TE-X
receives may not be successfully established.
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)
Lee, Ganti [Page 15]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
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 like to thank Radia Perlman, Darek Skalecki, Don
Fedyk, Jim Boyle, Dave Katz, Loa Andersson, Tony Przygienda for their
helpful comments and suggestions.
Lee, Ganti [Page 16]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
Appendix A - Packet Format
A.1 Options Field in LSA Header
+------------------------------------+
| X | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options Field
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [MOSPF].
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[NSSA].
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [DEMD].
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [EAL].
O-bit
This bit describes the router's willingness to receive and
forward Opaque-LSAs as specified in [rfc2370].
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, ("flooding" scope is restricted to
Lee, Ganti [Page 17]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
other virtual interfaces of the same area as described earlier), not
Type 10 (flooded out every adjacencies in an area). Another type of
flooding scope, restricted to virtual interfaces in an AS may be
defined in future.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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].
References
The following references are available at http://www.oiforum.org
[OIF-CONSTRAINT] 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
[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-06.txt
[OMPLS] draft-kompella-ospf-ompls-extensions-00.txt
Lee, Ganti [Page 18]
INTERNET DRAFT draft-lee-mpls-te-exchange-02.txt July 2002
[CR-LDP] draft-ietf-mpls-crldp-03.txt
[RFC1793] RFC 1793 Extending OSPF to Support Demand Circuits.
J. Moy. April 1995.
[PATH_QUERY] http://search.ietf.org/internet-drafts/draft-lee-mpls-path-request-03.txt
[TE-X Slides] http://www.ietf.org/proceedings/00dec/slides/TEWG-6/index.html
Authors' Information
Cheng-Yin Lee Cheng-Yin.Lee@alcatel.com
Alicja Celer aceler@nortelnetworks.com
Sudhakar Ganti sganti@tropicnetworks.com
Gerald Ash gash@att.com
Lee, Ganti [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:23 |