Internet DRAFT - draft-ash-ccamp-multi-area-te-reqmts
draft-ash-ccamp-multi-area-te-reqmts
Network Working Group Jerry Ash
Internet Draft John Strand
<draft-ash-ccamp-multi-area-te-reqmts-00.txt> AT&T
Expiration Date: September 2001
Cheng-Yin Lee
Paragon Networks
Alicja Celer
Nortel Networks
Neil Gammage
Sudhakar Ganti
Tropic Networks
Atsushi Iwata
Norihito Fujita
NEC Corporation
Adrian Farrel
Data Connection Ltd.
Sudheer Dharanikota
Nayna Networks
Senthil Venkatachalam
Dimitri Papadimitriou
Alcatel
March, 2001
Requirements for Multi-Area TE
<draft-ash-ccamp-multi-area-te-reqmts-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."
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.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 1]
Internet Draft Requirements for Multi-Area TE March, 2001
Abstract
This draft describes requirements for multi-area TE. Based on the
requirements, the goal is to eventually protocol extensions needed for
multi-area TE. Various approaches to multi-area TE are considered, based on
the intra-area TE approaches discussed in the [te_framework] and
[te_qos_routing]. These TE approaches include time dependent routing (TDR)
LSP selection, state dependent routing (SDR) LSP selection, and event
dependent routing (EDR) LSP selection. We propose that the needed protocol
capability extensions (information exchange, etc.) should support the
various types of multi-area TE identified in the draft. The focus initially
is on multi-area TE, and not multi-AS TE. IP over optical (IPO)
requirements are considered [mp-lambda-s, gmpls], including the unique
routing requirements of the optical plane [stand1, stand2, unique]. Initial
requirements are given for protocol support of the various multi-area TE
methods, which include needs to support route-server (RS) functionality,
query functionality, crankback functionality, TE feedback functionality, and
summary-LSA functionality.
Table of Contents
Page
1. Introduction 3
2. Requirements for Multi-Area TE 3
3. Multi-Area TE Routing Methods and Requirements 5
3.1 Time-Dependent Routing (TDR) LSP Selection 6
3.2 State-Dependent Routing (SDR) LSP Selection 6
3.3 Event-Dependent Routing (EDR) LSP Selection 8
3.4 Inter-AS LSP Selection 8
4. Requirements for Information Exchange & Topology Data
Base Update 9
5. Comparison of Multi-Area TE Methods 10
5.1 TDR Methods 10
5.2 SDR Methods 10
5.2.1 Distributed SDR (D-SDR) Methods 10
5.2.2 Route Server SDR (RS-SDR) Methods 11
5.3 EDR Methods 12
6. Requirements for Multi-Area TE Protocol Extensions 12
7. Security Considerations 12
8. Acknowledgments 12
9. References 12
10.Authors' Addresses 14
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 2]
Internet Draft Requirements for Multi-Area TE March, 2001
1. Introduction
This draft describes requirements for multi-area TE. Based on the
requirements, the goal is to eventually protocol extensions needed for
multi-area TE. Various approaches to multi-area TE are considered, based on
the intra-area TE approaches discussed in the [te_framework] and
[te_qos_routing]. These multi-area TE approaches are outlined, and include
time dependent routing (TDR) LSP selection, state dependent routing (SDR)
LSP selection, and event dependent routing (EDR) LSP selection. We propose
that the needed protocol capability extensions (information exchange, etc.)
should support the various types of multi-area TE identified in the draft.
The focus initially is on multi-area TE, and not multi-AS TE.
The focus initially is on multi-area TE, and not multi-AS TE. IP over
optical (IPO) requirements are considered [mp-lambda-s, gmpls], including
the unique routing requirements of the optical plane [stand1, stand2,
unique]. Initial requirements are given for protocol support of the various
multi-area TE methods, which include needs to support route-server (RS)
functionality, query functionality, crankback functionality, TE feedback
functionality, and summary-LSA functionality.
Several drafts were presented at the IETF-49 TEWG meeting on multi-area TE,
among them [sudheer1], [sudheer2], [abarbanel], [kompella], [lee]. Several
of these methods propose the use of a route server (RS) capability [lee,
kompella], query capability [query], crankback capability [crankback], and
others suggest the use of summary LSAs [summary_lsa]. These drafts propose
different approaches to multi-area TE, but are related by a common set of
requirements and protocol needs discussed in this draft.
Many potential users are requesting multi-area TE capability [Swallow,
IETF49 TEWG Meeting Minutes].
2. Requirements for Multi-Area TE
There are various requirements to be considered in adopting a multi-area TE
method, which include the following:
a) maximize network utilization, considering QoS objectives
b) minimize network cost, considering QoS objectives
c) minimize routing overhead (includes LSAs, crankbacks, queries, etc.)
d) minimize routing overhead across areas (LSA flooding)
e) maximize scalability
f) allow various multi-area TE routing methods, including TDR, SDR, and
EDR LSP selection [te_framework, te-qos-routing]
g) allow various information exchange methods to be used, including
support for RS functionality, query functionality, crankback functionality,
TE feedback functionality, and summary-LSA functionality
h) support bi-directional LSPs and asymmetrical bi-directional LSPs
i) provide signaling interworking with other technologies, including
BICC, PNNI, and other signaling protocols
j) ensure that multi-area TE supports IP over optical (IPO) control
plane needs, including both overlay models and peer models [mp-lambda-s,
gmpls]
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 3]
Internet Draft Requirements for Multi-Area TE March, 2001
k) ensure that all routing constraints and unique IPO requirements can
be incorporated in multi-area path selection [strand1, strand2, unique]
l) allow routing protocols across areas to be resident on multiple
network elements [strand2]
m) allow LSP restoration to occur separately within each area [strand2]
n) provide metrics capable of modeling transport costs, cross-connect
costs, regeneration/amplification costs [strand2]
o) allow multiple paths which satisfy path diversity needs [strand2]
p) allow topological overlap between areas [strand2]
q) allow partial connectivity in the optical domain [strand2]
r) allow multi-area information exchange of link/switch capabilities in
networks that support mixed switching types
s) allow multi-area information exchange of link protection types in
networks that support mixed link protection types
t) allow multi-area gmpls explicit label control, so that routing
protocols are capable of distributing label availability information with
respect to lambdas and time slots both within and between areas
For IPO needs, support for both an overlay model and peer model are
required. An overlay model provides more separation between optical and
network domains, which affords more routing domain independence, and requires
less routing information exchange across the domain boundaries (e.g., no LSAs
are flooded across the UNI). Further, it is envisioned that within the optical
domain there may be an O-E-O sub-domain layer and an all-optical sub-domain
layer [strand2]. Within the all-optical subdomain, full connectivity may not
be possible. For example, if the all-optical sub-domain is limited by optical
impairment to support only routes of 3 or less links, it may not be possible
to provide more than 3-link connectivity between all nodes [strand2].
GMPLS [gmpls] extends MPLS to allow signaling of labels for other switching
technologies beyond the packet switching. When a new LSP is set up it must
be specified to the LSRs in the path what the transmission commodity being
switched is -- the current choices include packet, Ethernet, PDH, SDH,
SONET, digital wrapper, Lambda, and fiber. In order to perform traffic
engineering correctly, it is not enough to know the IP topology, but we also
need to know the link capabilities.
Similarly, GMPLS allows the LSP requester to specify the link protection
properties required. These are the protection properties of the underlying
link not those of the LSP itself. Link protection possibilities are none,
1:n, 1:1, 1+1, better than 1+1. Again, TE can only do this correctly if the
link protection properties are passed around, and this needs to be supported
for multi-area TE.
GMPLS allows labels to encode sub-resources within a link (e.g., time slots
or lambdas). GMPLS also extends the signaled explicit route to allow it to
encode the labels that should be used for each hop of the route with
Explicit Label Control. Combining these gives the ingress control of the
sub-resources to use through the network. This is only any use if the TE is
centralized or if the IGP is extended to report sub-resource availability.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 4]
Internet Draft Requirements for Multi-Area TE March, 2001
3. Multi-Area TE Routing Methods and Requirements
Internet Traffic Engineering is concerned with the performance optimization
of operational networks. It encompasses the measurement, modeling,
characterization, and control of Internet traffic, and the application of
techniques to achieve specific performance objectives, including the
reliable and expeditious movement of traffic through the network, the
efficient utilization of network resources, and the planning of network
capacity.
Hierarchical multi-area or multi-AS topologies are normally used with IP
routing protocols (e.g., OSPF, BGP). Traffic trunks can be defined by LSPs
between LSRs, and are used to allocate the bandwidth of the logical links to
various LSR pairs. TE LSP routing is characterized by the LSP choices used
in the method and rules to select one LSP for a given connection or
bandwidth-allocation request. When an LSP bandwidth-allocation request is
initiated by an LER, the LER implementing the routing method executes the
LSP selection rules to find an admissible LSP from among the LSPs that
satisfy the request. In a network with source routing, the LER maintains
control of the LSP request.
With source routing, the LER identifies the entire selected LSP including
all intermediate or via LSRs (VLSRs) and egress LSR (ELSR) in the LSP in an
explicit-route (ER) parameter. Some VLSRs may lie on the boundary of areas
and are area border routers (ABRs). If the QoS or traffic parameters cannot
be realized at any one of the VLSRs in the LSP setup request, then the VLSR
generates a crankback parameter which allows a VLSR to return control of the
bandwidth-allocation request to the LER or ABR for further alternate
routing.
LSPs are determined by (normally proprietary) algorithms based on the
network topology and reachable address information. LSPs can cross multiple
areas within an AS, and also cross multiple ASs. An LER may select an LSP
based on the routing rules and the QoS resource management criteria, which
must be satisfied on each link in the LSP. In addition to controlling
bandwidth allocation, the QoS resource management procedures can check other
QoS parameters, such as end-to-end transfer delay, delay variation, and
transmission quality considerations such as loss, echo, and noise.
LSP selection methods are categorized into the following three types:
* time-dependent routing (TDR) LSP selection,
* state-dependent routing (SDR) LSP selection, and
* event-dependent routing (EDR) LSP selection.
LSP choices can be changed dynamically, either in an off-line, preplanned,
time-varying manner, as in TDR, or on-line, in real time, as in SDR or EDR.
With off-line, pre-planned TDR LSP selection, LSP choices might change every
hour or at least several times a day to respond to measured hourly shifts in
traffic loads, and are periodically recalculated, perhaps each week.
Real-time LSP selection does not depend on precalculated LSP choices.
Rather, the LSR or route server (RS) senses the immediate traffic load and
if necessary searches out new LSPs through the network. On-line, real-time
LSP selection methods include EDR and SDR.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 5]
Internet Draft Requirements for Multi-Area TE March, 2001
An LER can fully calculate an ER at the source based on TDR, SDR, or EDR LSP
selection, or the ER can include loose hops which are used at ABRs. In the
latter case, the ER processing rules allow the ABRs to insert a series of
hops to navigate to the next ABR, thus the LSP choice is not constrained to
the LER. This distinction is made in [crankback], but only after the
initial signaling attempt (with the LER-signaled ER) has failed.
3.1 Time-Dependent Routing (TDR) LSP Selection
With TDR methods the LSP choices are altered at a fixed point in time during
the day or week. TDR LSP choices are determined on an off-line, preplanned
basis and are implemented consistently over a time period. The TDR LSP
choices are determined considering the time variation of traffic load in the
network, for example based on measured hourly load patterns. Several TDR
time periods are used to divide up the hours into contiguous routing
intervals. Typically, the TDR LSP choices used in the network are
coordinated to take advantage of noncoincidence of busy hours among the
traffic loads.
In TDR, the LSP choices are preplanned and designed off-line using a
centralized system, which employs a TDR network design model. The off-line
computation determines the optimal routes from a potentially very large
number of possible alternatives, in order to maximize network throughput
and/or minimize the network cost. The designed LSP choices are loaded and
stored in the various LSRs in the TDR network, and periodically recomputed
and updated (e.g., every week) by the central system. In this way an LER
does not require additional network information to construct TDR LSP
choices, once the LSP choices have been loaded. This is in contrast to the
design of LSP choices on-line in real time, such as in the SDR and EDR
methods described below. LSPs in the TDR routing table may consist of time
varying routing choices and use a subset of the available LSPs. That is, we
can distinguish between LSP calculation/choice and LSP establishment. In
TDR, the LSP choices are made off line and are changed by a change in time
period. In SDR and EDR, the LSP choices are determined on line and changed
by a change in the network state and/or an event such as a blocked LSP
request (a variant of SDR and EDR could be to have the LSP choices made off
line).
LSPs in the TDR routing table may consist of several (possibly
multiple-link) LSPs through multiple VLSRs. If a connection on one link in a
LSP is blocked (e.g., because of insufficient bandwidth), the
bandwidth-allocation request then attempts another complete LSP.
Implementation of such a routing method can be done through control from the
LER or ABR, plus a crankback capability that allows a bandwidth-allocation
request blocked on a link in an LSP to return to the LER or ABR for further
alternate routing on other LSPs.
3.2 State-Dependent Routing (SDR) LSP Selection
In SDR, the LSP choices are altered automatically according to the state of
the network. For a given SDR method, the LSP selection rules are
implemented to determine the LSP choices in response to changing network
status, and are used over a relatively short time period. Information on
network status may be collected at a central route server (RS) processor or
distributed to multiple RSs or the LSRs in the network.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 6]
Internet Draft Requirements for Multi-Area TE March, 2001
The information exchange may be performed by
* flooding the information to all the RSs and/or LSRs in the network
* querying RSs or LSRs on an on-demand basis for needed information,
* feeding the information back on LSP signaling messages
* a combination of any of the above
SDR methods route LSP bandwidth-allocation requests on the best available
LSP on the basis of network state information. For example, in the least
loaded routing (LLR) method, the residual capacity of candidate LSPs is
calculated, and the LSP having the largest residual capacity is selected for
the bandwidth-allocation request. Various relative levels of link occupancy
can be used to define link load states, such as lightly-loaded,
heavily-loaded, or bandwidth-not-available states. In general, SDR methods
calculate a LSP cost for each bandwidth-allocation request based on various
factors such as the load-state or congestion state of the links in the
network.
In SDR, the LSP choices are designed on-line by the LER or an RS through the
use of network status and topology information obtained through information
exchange with other LSRs and/or other RSs. There are various
implementations of SDR distinguished by whether the computation of the LSP
choices is
a) distributed among all the LSRs in an AS, or
b) done in a centralized RS per AS, or perhaps several RSs (e.g., 1 or
more per AS area).
This leads to two different implementations of SDR:
a) distributed SDR (D-SDR) -- here each LSR in the AS obtains topology
and status information from all the other LSRs. Normally the topology
status information is flooded throughout each area in the AS, and between
areas with summary-LSAs. In another form of D-SDR, rather than flooding
information an LER queries the other LSRs in the candidate LSPs to obtain
topology and status information. To determine an LSP explicit route, the
LER executes a particular routing optimization procedure such as LLR.
b) route server SDR (RS-SDR) -- here the centralized RS or several RSs
obtain topology and status information from the various LSRs within an AS or
within an AS-area. The topology/status information can be sent on a
periodic basis (e.g., every few seconds) or based on topology/status
changes. The RS performs a computation of the candidate LSPs on a periodic
basis (e.g., every few seconds) or on-demand (e.g., initiated by a query
from an LER). To determine the LSP explicit route, the RS computes the
constrained route by executing a particular routing optimization procedure
such as LLR. The LSPs are either transmitted to the LSRs on a periodic
basis (e.g., every few seconds) or provided on demand from an LER.
The essential distinction between D-SDR and RS-SDR LSP selection is where
the TE routing database is kept and the LSP choices are made. In the D-SDR
case, the database and LSP choices are made at the LSRs themselves. In the
RS-SDR case, the database and LSP choices are made at the RS(s).
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 7]
Internet Draft Requirements for Multi-Area TE March, 2001
In either instance, LSP explicit routes may be determined based on the
constraints specified and analysis of the status data. For example, an LSP
selection method might provide that the primary (shortest) LSP choice is
used if the bandwidth is available. If the bandwidth is unavailable on one
or more links, a second LSP is selected from the list of feasible LSPs on
the basis of having the greatest level of idle bandwidth at the time. This
second LSP may be used to provide bandwidth capacity in addition to that
already provided by the primary LSP between the LER and egress LSR. The
second LSP may be selected from among a pre-stored list of candidate LSPs or
computed on line based on the constraints and network status information in
the TE routing database. Dynamically activated bandwidth reservation can be
used to protect against inefficient LSP usage, and other controls used to
automatically modify LSP choices during network overloads and failures
[te_qos_routing].
3.3 Event-Dependent Routing (EDR) LSP Selection
In EDR, the LSP choices are updated locally on the basis of whether
connections succeed or fail on a given LSP choice. In the EDR learning
approaches, the LSP last tried, which is also successful, is tried again
until blocked, at which time another LSP is selected at random and tried on
the next bandwidth-allocation request. Success-to-the-top (STT) EDR LSP
selection is a decentralized, on-line LSP selection method with update based
on random routing. STT-EDR uses a simplified decentralized learning method:
The primary LSP LSP-p is used first if available, and a currently successful
alternate LSP LSP-s is used until it is blocked. In the case that LSP-s is
blocked (e.g., bandwidth is not available on one or more links), a new
alternate LSP LSP-n is selected at random as the alternate LSP choice for the
next bandwidth-allocation request overflow from the primary LSP. Dynamically
activated bandwidth reservation is used under congestion conditions to
protect traffic on the primary LSP. STT-EDR uses crankback when an alternate
LSP is blocked at a VLSR, and the bandwidth-allocation request advances to a
new random LSP choice. In STT-EDR, many LSP choices can be tried by a given
bandwidth-allocation request before the request is blocked.
The main point of EDR is that is does not require a centralized database of
FIDB information, such as is provided in D-SDR at each LSR through flooding
or query, or in RS-SDR at each RS. In the case of EDR, the FIDB information
is accessed locally at each LSR as the LSP is set up or modified. Hence in
EDR, the FIDB information is decentralized, however with SDR the FIDB
information is kept in one database, either in the LSRs or centralized in an
RS. In the EDR learning approaches, the current alternate LSP choice can be
updated randomly, cyclically, or by some other means, and may be maintained
as long as a connection can be established successfully on the LSP. Hence
the LSP selection is constructed with the information determined during
connection setup, and no additional information is required by the LER.
3.4 Inter-AS LSP Selection
In selecting LSPs between autonomous systems (ASs), which themselves may
consist of multiple areas, inter-AS routing capabilities such as BGP
[abarbanel] need to be considered. Though not specifically addressed in this
draft, some of the multi-area TE methods described herein can very well be
used to address the needs of multi-AS LSP selection as well. Details of
inter-AS LSP selection are TBD.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 8]
Internet Draft Requirements for Multi-Area TE March, 2001
4. Requirements for Information Exchange & Topology Data Base Update
Various means of information exchange, such as with LSAs, query, and
crankback, are required to build the topology database, to construct the LSP
choices, and to determine and establish a LSP from the choices.
LSAs [ospf, isis] are flooded within areas to build the topology database at
each LSR by advertising link status, node status, reachable addresses, and
other information. LSAs could also be advertised between areas; however
this could raise scalability issues since areas are established in the first
place to limit LSA flooding to a reasonable level within the designated
areas (more on this later). Summarized LSAs [summary_lsa] can be flooded
between areas to give useful but reduced information, and also to be scalable.
Query [query] messages are required in some multi-area TE methods, for
example, between an LER and a route server (RS) [lee, kompella], or between
an LER and ABR, to determine topology database information needed to
calculate a path for an LSP. A query could also be used to request that an
RS or ABR compute an LSP path from its topology database, and return it to the
requesting LSR, ABR, or other RS. Various other means of using query-response
may be proposed.
Using the topology database, the LSR or RS generates the LSP choices
according to a number of different LSP selection methods, such as those
described in Section 3. Crankback [crankback] can be used in LSP setup,
or modification, to backtrack to an ABR or LER, if a bottleneck is found
in a candidate LSP (e.g., if there is insufficient bandwidth on a particular
link in the LSP).
One way to view the topology database at each LSR or RS is to consider a
decomposition into the slow information database (SIDB) and the fast
information database (FIDB).
Information in the SIDB changes slowly, for example)
* max link bandwidth
* color
* metric (weight, delay, etc.)
* reachable addresses
* slow available link bandwidth update (e.g., based on >= 5-minute
updates)
Information in the FIDB changes rapidly, for example
* available link bandwidth (e.g., real-time updates)
The LSA overhead to flood information in the SIDB is relatively much less
than the LSA overhead to flood information in the FIDB, because of the
relative rates of change of the database, not because of their relative
sizes. It might well be feasible, for example, to flood the full SIDB
information between areas, whereas it may not be feasible to flood the full
FIDB information (vs. summarized LSA information) between areas. The use
of SIDB and FIDB information by each inter-area TE method is detailed in
the next section.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 9]
Internet Draft Requirements for Multi-Area TE March, 2001
Note that the SIDB and FIDB information needs to be identified for each
class type. TE methods are currently being defined for multiple class types
[class] wherein the amount of SIDB/FIDB information will greatly increase
(multiplicative by the number of classes). This will increase the emphasis
on information exchange methods that decrease the routing overhead in terms
of LSAs, crankbacks, queries, etc. In general, SLAs, PHBs, and class types
may not be consistent across domains or areas, and could be policy specific.
In that case, a consistent meaning for class type needs to be defined.
5. Comparison of Multi-Area TE Methods
In the previous Section we gave routing requirements for multi-area TE,
which included TDR, SDR, and EDR methods. Here is a summary of the
classification of the various methods, use of SIDB/FIDB, and some
similarities, differences, and relative advantages among the methods.
See [te_qos_routing] for more detailed comparisons of these methods on the
basis of performance, network design impacts, and operational impacts.
Multiservice network models are used to evaluate performance, design, and
operation.
5.1 TDR Methods [te_framework, te_qos_routing]
- LSP selection performed by off-line centralized system
- candidate LSPs are pre-planned based on previously measured traffic and
downloaded periodically to LSRs
- LSP selection patterns change periodically (e.g., each hour) to respond to
measured hourly shifts in traffic loads and are periodically recalculated
(e.g., each week)
- advantage: intra-area and inter-area LSA flooding reduction
- disadvantage: LSP choices not adaptive to network status
5.2 SDR Methods
5.2.1 Distributed SDR (D-SDR) Methods
a. [kompella]/scenario 1 approach:
- per area path set up
- SIDB/FIDB flooded intra-area
- normal summary-LSAs inter-area
- use crankback to ABR or LER if LSP setup request fails
- feedback can be used to help build LSR TE routing database
- advantage: reduced LSA flooding between areas
- disadvantage: LSP choices not based on whole topology database
b. [kompella]/scenario 3 approach:
- LER gets TE information from backbone-area and computes path to tail-end
ABR; tail-end ABR computes rest of path
- LER stores both backbone and intra-area SIDB/FIDB
- use crankback if LSP setup request fails
- feedback can be used to help build LSR TE routing database
- advantage: whole topology database used for LSP determination
- disadvantage: large amount of downloaded backbone TE information
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 10]
Internet Draft Requirements for Multi-Area TE March, 2001
c. [sudheer1] approach:
- ABRs flood TE-summary-LSA's to other areas
- LER sets up LSP based on topology database, including summary-LSA
information
- transit LSRs use crankback if LSP setup request fails, ABR or LER may try
another LSP
- SIDB/FIDB flooded intra-area
- summarized SIDB/FIDB flooded inter-area (in TE-summary-LSAs)
- feedback can be used to help build LSR TE routing database
- advantage: reduces flooded information between areas
- disadvantage: LSP choices not based on whole topology database
d. D-SDR query approach [te_qos_routing]:
- ABRs flood SIDB-LSA's to other areas
- LER queries LSRs along candidate LSPs for FIDB information (at time of LSP
setup or modification)
- LER sets up LSP based on SIDB topology database and FIDB query-information
- transit LSRs use crankback if LSP setup request fails, ABR or LER may try
another LSP
- SIDB flooded intra-area & inter-area
- feedback can be used to build LSR TE routing database
- advantage: reduces flooded information within areas and between areas
- disadvantage: requires extensive use of query capability
5.2.2 Route Server SDR (RS-SDR) Methods
a. [lee] approach:
- this is a distributed RS approach wherein RSs could be separate or
combined ABR/RS
- RS(s) within area gather intra-area link-state information (reduces
intra-area flooding)
- LER queries a RS in backbone area for path
- LER does not download TE information from backbone area (reduces flooding
across areas)
- uses crankback if LSP setup request fails
- RS may try path query to another RS within area to determine another LSP
- intra-area SIDB/FIDB flooded only to RSs
- uses LER-RS query
- advantage: requires no TE-summary-LSA flooding between areas; possible
intra-area LSA flooding reduction; whole topology database used for LSP
determination
- disadvantage: requires RS implementation with RS backup
b. [kompella]/scenario 2 approach:
- LER queries ABR/RS for path (this is similar to [lee] approach)
- SIDB/FIDB flooded intra-area
- uses LER-ABR/RS query
- use crankback to ABR/RS or LER if LSP setup request fails
- advantage: requires no TE-summary-LSA flooding between areas; whole
topology database used for LSP determination
- disadvantage: requires RS implementation with RS backup
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 11]
Internet Draft Requirements for Multi-Area TE March, 2001
c. [kompella]/scenario 4 approach:
- LER queries central RS for path
- SIDB/FIDB flooded intra-area and to central RS
- uses LER-RS query
- use crankback if LSP setup request fails
- advantage: requires no TE-summary-LSA flooding between areas; possible
intra-area LSA flooding reduction; whole topology database used for LSP
determination
- disadvantage: requires RS implementation with RS backup
5.3 EDR Methods
Success-to-the-top EDR (STT-EDR) approach [te_qos_routing]:
- LER determines CRLSP based on SIDB
- uses crankback if LSP setup request fails
- SIDB information flooded intra-area and inter-area
- no FIDB flooding required
- feedback used to build LSR TE routing database
- advantage: intra-area and inter-area LSA flooding reduction
- disadvantage: LSP choices not based on whole topology database
6. Requirements for Multi-Area TE Protocol Extensions
Initial requirements are given here for protocol support of the multi-area
TE methods, which include needs to support
* route-server (RS) functionality [lee, kompella],
* query functionality [query],
* crankback functionality [crankback],
* TE feedback functionality [feedback], and
* summary-LSA functionality [summary_lsa].
Details of the proposed protocol upgrades necessitated by the various
multi-area TE solution approaches are already available in the various
drafts referenced.
7. Security Considerations
The multi-area routing extensions for RSVP-TE and CRLDP inherit the same
security mechanisms described in [rsvp_te, crldp] to protect against
spoofing attacks of a session, the privacy of signaling messages, and the
denial of service (DoS) attacks. Different areas may apply distinct
security models and may have different means of signaling security
(especially if one area does not use MPLS). Joining security domains would
introduce security issues that need to be addressed.
8. Acknowledgments
9. References
[sudheer1] Senthil K. Venkatachalam, Sudheer Dharanikota, "A Framework for
the LSP Setup Across IGP Areas for MPLS Traffic Engineering,",
<draft-venkatachalam-interarea-mpls-te-00>, August 2000, work in progress.
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 12]
Internet Draft Requirements for Multi-Area TE March, 2001
[sudheer2] Senthil K. Venkatachalam, Sudheer Dharanikota, Thomas D. Nadeau,
"OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area traffic
engineering using MPLS TE,", <draft-dharanikota-interarea-mpls-te-ext-01>,
[no date on draft], work in progress.
[abarbanel] Ben Abarbanel, Senthil K. Venkatachalam, "BGP-4 support for
Traffic Engineering," <draft-abarbanel-idr-bgp4-te-01.txt>, September 2000,
work in progress.
[kompella] Kireeti Kompella, Yakov Rekhter, "Multi-area MPLS Traffic
Engineering," <draft-kompella-mpls-multiarea-te-00.txt>, December 2000, work
in progress.
[lee] Cheng-Yin Lee, Alicja Celer, Neil Gammage, Sudhakar Ganti, Gerald Ash,
"Distributed Route Exchangers," <draft-lee-mpls-te-exchange-00.txt>,
November 2000, work in progress.
[query] Cheng-Yin Lee, Sudhakar Ganti, "Path Request and Path Reply
Message,", <draft-lee-mpls-path-request-00>, November 2000, work in
progress.
[crankback] Atsushi Iwata, Norihito Fujita, Gerald R. Ash, Adrian Farrel,
"Crankback Routing Extensions for MPLS Signaling,",
<draft-ietf-mpls-crankback-00>, March 2001, work in progress.
[feedback] Peter Ashwood-Smith, Bilel Jamoussi, Don Fedyk, Darek Skalecki
"Improving Topology Data Base Accuracy with LSP Feedback," <
draft-ietf-mpls-te-feed-01>, July 2000, work in progress.
[summary_lsa] Atsushi Iwata, Norihito Fujita, "Traffic Engineering
Extensions to OSPF Summary LSA," IETF draft.
[te_qos_routing] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, &
TDM-Based Multiservice Networks," <draft-ietf-tewg-qos-routing-00.txt>,
November 2000, work in progress.
[te_framework] D. Awduche, et. al., "A Framework for Internet Traffic
Engineering," <draft-ietf-tewg-framework-02.txt>, July 2000, work in
progress.
[te_requirements] D. Awduche, et al., "Requirements for Traffic Engineering
Over MPLS," RFC2702, September 1999.
[unique] Angela Chiu, John Strand, Robert Tkach, "Unique Features and
Requirements for The Optical Layer Control Plane,"
<draft-chiu-strand-unique-olcp-01.txt>, November 2000, work in progress.
[strand1] John Strand, Angela Chiu, Robert Tkach, "Issues for Routing in the
Optical Layer," IEEE Communications Magazine, February 2001.
[strand2] John Strand, Yong Xue, "Routing for Optical Networks With Multiple
Routing Domains," oif2001.046 (for a copy send an email request to
jls@research.att.com).
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 13]
Internet Draft Requirements for Multi-Area TE March, 2001
[mp-lambda-s] D. Awduche, et al., "Multi-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical Crossconnects",
<draft-awduche-mpls-te-optical-02.txt>, July 2000, work in progress.
[gmpls] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS-Signaling
Functional Description,", <draft-ietf-mpls-generalized-signaling-01>,
November 2000, work in progress.
[ldp] L. Andersson, et. al., "LDP Specification," RFC 3036, January 2001.
[crldp] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP,"
<draft-ietf-mpls-cr-ldp-04.txt>, July 2000, work in progress.
[rsvp] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)--Version 1
Functional Specification, RFC2205, September 1997.
[rsvp_te] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels,"
<draft-ietf-mpls-rsvp-lsp-tunnel-07.txt>, February 2001, work in progress.
[ospf] J. Moy, "OSPF Version 2," RFC2328, April 1998.
[isis] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments," RFC1195, December 1990.
[recovery] S. Makam, et. al., "Framework for MPLS-based Recovery,"
<draft-makam-mpls-recovery-frmwrk-01.txt>, July 2000, work in progress.
[class] Francois Le Faucheur, et. al., "Requirements for support of
Diff-Serv-aware MPLS Traffic Engineering,"
<draft-ietf-mpls-diff-te-reqts-00.txt>, November 2000, work in progress.
10. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
John Strand
AT&T
Room MT A5-1D06
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-9036
Fax: +1-(732)-368-9433
Email: jstrand@att.com
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 14]
Internet Draft Requirements for Multi-Area TE March, 2001
Cheng-Yin Lee
Paragon Networks
Email: : leecy@paragon-networks.com
Alicja Celer
Nortel Networks
Email: aceler@nortelnetworks.com
Neil Gammage
Email: neil.g@home.com
Sudhakar Ganti
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: sganti@tropicnetworks.com
Atsushi Iwata
NEC Corporation
Computer & Communication Media Research
1-1, Miyazaki, 4-Chome, Miyamae-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN
Phone: +81-(44)-856-2123
Fax: +81-(44)-856-2230
Email: a-iwata@ah.jp.nec.com
Norihito Fujita
NEC Corporation
Computer & Communication Media Research
1-1, Miyazaki, 4-Chome, Miyamae-ku,
Kawasaki, Kanagawa, 216-8555, JAPAN
Phone: +81-(44)-856-2123
Fax: +81-(44)-856-2230
Email: n-fujita@bk.jp.nec.com
Adrian Farrel
Network Convergence Group
Data Connection Ltd.
Windsor House
Pepper Street
Chester, UK
Phone: +44-(0)-1244-313440
Fax: +44-(0)-1244-312422
Email: af@: af@dataconnection.com
Sudheer Dharanikota
Nayna Networks
157 Topaz Drive
Milpitas, CA 95035
Phone: (408)-956-8000 x357
Email: sudheer@nayna.com
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 15]
Internet Draft Requirements for Multi-Area TE March, 2001
Senthil K. Venkatachalam
Alcatel USA
45195 Business Court, Suite 400
Dulles, VA 20166
Phone: (703)654-8635
Email: Senthil.Venkatachalam@usa.alcatel.com
Dimitri Papadimitriou
Optical Networking Alcatel NSG-NA
Corporate Research Center - Network Strategy Group
Francis Wellesplein, 1
B-2018, Antwerpen - Belgium
Phone: +323-2408491
Email: Dimitri.Papadimitriou@alcatel.be
Ash, et. al. <draft-ash-ccamp-multi-area-te-reqmts-00.txt> [Page 16]
