[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: MPLS Inter-area TE requirement draft
copying CCAMP for comments.
Thanks.
JP.
Date: Tue, 30 Dec 2003 15:25:20 -0500
To: te-wg@ops.ietf.org
From: Jean Philippe Vasseur <jvasseur@cisco.com>
Subject: MPLS Inter-area TE requirement draft
Cc: ejk@tech.org, Jim Boyle <jboyle@pdnets.com>, bwijnen@lucent.com,
jeanlouis.leroux@francetelecom.com, Raymond_Zhang@infonet.com, Kenji
Kumaki <ke-kumaki@kddi.com>, Yuichi Ikejiri <y.ikejiri@ntt.com>, Parantap
Lahiri <parantap.lahiri@mci.com>, ting_wo.chung@bell.ca
Hi,
Please find attached a new MPLS Inter-area TE requirement draft, which is
truly the collective effort of the SPs on this draft along with comments
we received form others. I took the liberty to send the draft to the list
since it is still not on the IETF site and Bert mentioned that quick
progress should be made on this item.
Jim, as already mentioned on the list, we would be happy to work with you
on this draft in order to quickly come up with a single draft if you will.
Thanks in advance for your comment.
JP.
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
JP Vasseur (Editor)
Cisco Systems, Inc.
Jean-Louis Le Roux (Editor)
France Telecom
Ting-Wo Chung
Bell Canada
Raymond Zhang
Infonet Services Corporation
Kenji Kumaki
KDDI Corporation
Parantap Lahiri
MCI
Yuichi Ikeriji
NTT Communications Corporation
IETF Internet Draft
Expires: June, 2004
December, 2003
draft-leroux-tewg-inter-area-TE-reqs-00.txt
MPLS Inter-area Traffic Engineering requirements
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.
1
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
Abstract
This document lists the detailed set of requirements for the support of
inter-area MPLS Traffic Engineering (inter-area MPLS TE) which could
serve as a guideline to develop the required set of protocol
extensions.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Content
1. Terminology
2. Introduction
3. Overview of the requirements and objectives
3.1 Inter-area resources optimizations
3.2 Inter-area Qos guarantees
3.3 Fast recovery acrros IGP areas
4. Application scenario
5. Detailed requirements for inter-area MPLS Traffic Engineering
5.1 Objective to preserve IGP/RSVP scalability
5.2 Inter-area MPLS TE operations and interoperability
5.3 Protocol signalling and path computation
5.4 Path optimality
5.5 Support of diversely routed inter-area TE LSPs
5.6 Reoptimization of inter-area TE LSP
5.7 Support of fast recovery of inter-area TE LSP
5.8 DS-TE support
5.9 Hierarchical TE LSP support
5.10 Soft preemption
5.11 Auto-discovery
5.12 Mapping of traffic to inter-area TE LSP
5.13 Inter-area MPLS TE management
5.13.1 Inter-area MPLS TE MIB requirement
5.13.2 Inter-area MPLS TE fault management requirements
6 Evaluation criteria
6.1 Scalability
6.2 Performances
6.3 Complexity and risks
6.4 Backward compatibility
7. Security issues
References
2
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
3
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
1. Terminology
LSR: Label Switch Router
LSP: MPLS Label Switched Path
CSPF: Constraint-based Shortest Path First.
Inter-area MPLS TE: TE LSP whose Head-end LSR and Tail-end LSR do
not reside within the same IGP area or both Head-end
LSR and Tail-end LSR are in the same IGP area but the TE LSP
transiting path may be across different areas
IGP area: OSPF area or IS-IS level
ABR: Area Border Router (i.e router used to connect two IGP areas (ABR
in OSPF or L1/L2 router in IS-IS)
2. Introduction
The set of MPLS Traffic Engineering mechanisms documented in [RSVP-TE]
may be deployed by Service Providers to achieve some of the most
important objectives of network traffic engineering as described in
[TE-OVW].
These objectives are summarized as listed below:
- Supporting end-to-end services requiring QoS guarantees
- Performing network resource optimization
- Providing fast recovery
However, the current set of MPLS traffic engineering mechanisms can
only be used within a single IGP area.
This document discusses the set of requirements a solution must or
should satisfy in order to support the same set of functionalities
across multiple IGP areas. Since the scope of requirements will vary
between Operators, some requirements will be mandatory (MUST) whereas
others will be optional (SHOULD).
3. Overview of the requirements and objectives
3.1. Introduction
MPLS Traffic Engineering has been deployed in many Operators? networks
for its capability to efficiently optimize the network bandwidth usage.
One possible approach in the context of inter-area MPLS TE consists in
deploying MPLS TE on a per-area basis but such an approach has several
limitations:
4
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
-Basically per-area TE provides sub-optimal traffic engineering
by optimizing resource independently in each area. And what
many operators want is to optimize their areas as a whole, i.e.
as if there was only one area (flat network).
- The required traffic level aggregation at the ABR levels
implies some constraints that do not lead to efficient traffic
engineering,
- The traffic aggregation does not allow to provide bandwidth
guarantees on a per inter-area TE LSP basis,
- The inter-area traffic cannot be protected with local
protection mechanisms such as [FAST-REROUTE] in case of ABR
node failure.
3.2. Inter-area resource optimization
For the reasons mentioned above, it is desired to extend the current
set of [RSVP-TE] mechanisms in order to be able to set up MPLS TE LSP
across multiple IGP areas in order to efficiently achieve inter-area TE
optimization.
3.3. Inter-area QoS guarantees
The DiffServ IETF working group has defined a set of mechanisms
described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff] that
can be activated at the edge or over a DiffServ domain to contribute to
the enforcement of a (set of) QoS policy(ies), which can be expressed
in terms of maximum one-way transit delay, inter-packet delay
variation, loss rate, etc. Many Operators have some or full deployment
of Diffserv implementations in their networks today, either across the
entire network or at least at the edge of the network. In situations
where strict QoS bounds are required, admission control inside the
backbone of a network is in some cases required in addition to current
Diffserv mechanisms. When the propagation delay can be bounded, the
performance targets, such as maximum one-way transit delay may be
guaranteed by providing bandwidth guarantees along the Diffserv-enabled
path.
It may also be desired to compute inter-area paths offering a shortest
path across multiple areas that satisfy some bandwidth constraints, as
currently possible within a single IGP area. For the sake of
illustration, if the IGP metrics reflects the propagation delay, it may
be needed to be able to find the optimal (shortest) path satisfying
some bandwidth constraints across multiple areas: such a path would be
the path offering the minimal propagation delay.
One typical example of this requirement is to provide bandwidth
guarantees over an end-to-end path for VoIP traffic classified as EF
(Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network.
Another increasing popular deployment is driven by the need to carry
pseudo-wire connection between gateways residing in different IGP
5
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
areas. When the EF path is extended across multiple IGP areas, inter-
area bandwidth guarantee along with other constraints is then required.
3.4. Fast recovery across IGP areas
As traffic sensitive application are getting deployed, one of the key
requirements is to provide fast recovery (on the order of tens of
msecs) mechanisms in case of network element failure (link/SRLG/node),
which cannot be achieved with current IGPs. Hence, a strong requirement
for inter-area MPLS TE is to provide fast recovery mechanisms to
protect (some) inter-area traffic in case of link/node/SRLG failure.
Note that this includes the failure of any link/SRLG/node within any
IGP area and the failure of ABRs. It is worth highlighting that
additional constraint like bandwidth guarantee during failure (while
inter-area protected TE LSP are rerouted onto their respective backup
tunnel) may also be required. This implies the ability to optimize the
backup tunnel path in order to minimize the amount of backup bandwidth
and limit the propagation delay increase during failure (along the
backup tunnel path) for some traffic.
4. Application scenario
<---area1---><---area0---><----area2----->
------R1-ABR1-R2-------ABR3-------
| | | |
| R0 | | R4 |
| R5 | | |
---------ABR2----------ABR4------
- ABR1, ABR2, ABR3 and ABR4 are ABRs
- R0, R1, R5: LSRs in area 1
- R2: an LSR in area 0
- R4: an LSR in area 2
Typically, an inter-area TE LSP will be set up between R0 and R4 where
both LSRS belong to different IGP areas. Note that the solution MUST
support the capability to protect such an inter-area TE LSP from the
failure on any link/SRLG/Node within any area and the failure of any
traversed ABR.
In some cases, it might also be possible to have an inter-area TE LSP
from R0 to R5 transiting via the back-bone area (or any other levels
with IS-IS).
5. Detailed requirements for inter-area MPLS Traffic Engineering
5.1. Objectives to preserve IGP/RSVP scalability
Being able to achieve the requirements listed in this document MUST be
performed while preserving the IGP scalability, which is of the utmost
importance. Hence, the set of mechanisms defined to meet those
6
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
requirements MUST not require IGP extra-load which could compromise the
IGP scalability. In particular, a solution satisfying those
requirements MUST require for the IGP to carry some unreasonable amount
of extra information and MUST not significantly increase the frequency
of IGP flooding. Likewise, the solution MUST also preserve the
scalability of RSVP TE ([RSVP-TE]). Moreover, the solution MUST
preserve the concept of IGP hierarchy (no TE link information flooded
across areas).
5.2. Inter-area MPLS TE operations and interoperability
The inter-area MPLS TE solution MUST be consistent with requirements
discussed in [TE-REQ] and the derived solution MUST be such that it
will interoperate seamlessly with current intra-area MPLS TE mechanism
and inherit its capability sets from [RSVP-TE]. See also [TE-REQ].
The proposed solution MUST allow to provision at the Head/Tail end with
end-to-end RSVP signalling (eventually with loose paths) traversing
across the interconnected ABRs, without further provisioning required
along the transit path.
5.3. Protocol signaling and path computation
The proposed solution MUST provide the ability to explicitly specify a
set of LSRs including ABRs by means of strict or loose hops for the
inter-area TE LSP.
The solution SHOULD also allow the head-end LSR to explicitly specify
the hops across the transit area on which path the constraints are met.
In addition, the proposed solution SHOULD also provide the ability to
specify and signal that certain loose or strict nodes and resources to
be explicitly excluded in the inter-area TE LSP path establishment. If
multiple signaling methods are proposed in the solution (e.g contiguous
LSP, stitched or nested LSP), the Head-end LSR MUST have the ability to
signal the required signaling method on a per-LSP basis.
5.4. Path optimality
As already pointed out, the solution SHOULD provide the capability for
the Head-end LSR to dynamically compute an optimal path satisfying a
set of specified constraints defined in [TE-REQ] across multiple areas.
Note that this requirement document does not mandate that all inter-
area TE LSP require the computation of an optimal inter-area path: some
inter-area TE LSP path may be computed via some mechanisms not
guaranteeing an optimal end to end path whereas some other inter-area
TE LSP paths carrying sensitive traffic could be computed making use of
some mechanisms allowing to dynamically compute an optimal end to end
path. Note that regular constraints like bandwidth, affinities, ? MUST
also be taken into account in the computation of an optimal end to end
path. In the context of this requirement document, an optimal path is
7
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
defined as the shortest path across multiple areas taking into account
either the IGP or TE metric. In other words, such a path is the path
that would have been computed making use of some CSPF algorithm in the
absence of areas.
5.5. Support of diversely routed inter-areas TE LSPs
There are several cases where the ability to compute diversely routed
TE LSP paths may be desirable:
(1) A single TE LSP across multiple areas satisfying the required set
of constraints cannot be found, in which case this may require load
splitting.
(2) Multiple TE paths may be required to limit the impact of a network
element failure to a portion of the traffic. As an example, two VoIP
gateways may load balance the traffic among a set of inter-area TE
LSPs.
(3) Path protection (e.g. 1:1 or 1:N) as discussed in [MPLS-Recov].
Hence, the solution SHOULD be able to provide the ability to compute
diversely routed inter-area TE LSPs paths. In particular, if such paths
obeying the set of constraints exist, the solution SHOULD be able to
compute them. For the sake of illustration, there are some algorithms
that may not always allow to find diversely routed TE LSPs because they
make use of a two steps approach that cannot guarantee to compute two
diversely routed TE LSP paths even if such a solution exist. This is in
contrast with other methods that simultaneously compute the set of
diversely routed paths and that can always find such paths if they
exist.
5.6. Reoptimization of inter-area TE LSP
The solution MUST provide the ability to reoptimize in a non disruptive
fashion (make before break) an inter-area TE LSP, should a more optimal
appear in any traversed area. The Operator should be able to trigger
such a reoptimization on a timer or event-driven basis. It should also
be possible to trigger such a reoptimization manually.
Moreover, the solution SHOULD provide the ability for the Head-end LSR
to be informed of the existence of a more optimal path in a downstream
area and keep a strict control on the reoptimization process. Hence,
the Head-end LSR, once informed of a more optimal path in some
downstream areas, could decide (or not) to gracefully perform an end to
end path reoptimization, according to the inter-area TE LSP
characteristics.
The ABR should check for optimality of the TE LSPs established through
it based on a timer or triggered by an event. Option of providing
manual trigger to check for optimality should also be provided.
8
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
5.7. Support of fast recovery of inter-area TE LSP
The solution MUST provide the ability to benefit from fast recovery
making use of the local protection techniques specified in [FAST-
REROUTE] in both the case of an intra-area network element failure
(link/SRLG/Node) and an ABR node failure. Note that different
protection techniques SHOULD be usable in different part of the network
to protect an inter-area TE LSP. This is of the utmost importance in
particular in the case of an ABR node failure that typically carries a
great deal of inter-area traffic. Moreover, the solution SHOULD allow
to compute and set up a backup tunnel following an optimal path that
offers bandwidth guarantees during failure along with other potential
constraints (like bounded propagation delay increase along the backup
path).
5.8. DS-TE support
The proposed inter-area MPLS TE solution SHOULD also satisfy core
requirements documented in [DS-TE] and interoperate seamlessly with
current intra-AS MPLS DS-TE mechanism [DSTE-PROT].
5.9. Hierarchical LSP support
In case of large inter-area MPLS deployment potentially involving a
large number of edge LSRs, it can be desirable/necessary to introduce
some level of hierarchy in the core in order to reduce the number of
states on core LSRs. Hence, the proposed solution SHOULD allow inter-
area TE LSP aggregation (also referred to as LSP nesting) such that
individual tunnels can be carried onto one or more aggregating LSP.
One such mechanism, for example is described in [MPLS-LSPHIE]. The
solution SHOULD also provide the ability to advertise some TE LSPs as
links as specified in [MPLS-LSPHIE].
5.10. Soft preemption
The solution MUST support the ability to make use of the soft
preemption mechanisms for inter-area TE LSP such as one defined in
[SOFT-PREEMP].
5.11. Auto-discovery
Because the number of LSRs participating in some TE mesh might be quite
large, it might be desirable to provide some discovery mechanisms
allowing an LSR to automatically discover the LSRs members of the TE
mesh(es) that it belongs to. The discovery mechanism SHOULD be
applicable across multiple IGP areas, and SHOULD not impact the IGP
scalability, provided that IGP extensions are used for such a discovery
mechanism.
5.12. Mapping of traffic to inter-area TE LSP
9
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
In the case of intra-area MPLS TE, there are currently several
possibilities to steer traffic to some intra-area TE LSP: the TE LSP
can be automatically taken into account in the RIB computation, static
routing can be used, ? In the case of inter-area TE LSP, the proposed
solution SHOULD at least support static routing coupled with recursive
routing. For instance, an Operator should be able to route all the
traffic sent to the set of routes announced by a (MP-)BGP speaker by
means of a single static route to the corresponding BGP next hop
address.
5.13. Inter-area Path selection policy
For inter-area TE LSPs whose Head-End and Tail-End reside in the same
IGP area, there may be intra-area and inter-area feasible paths. In case
the shortest path is an inter-area path, an operator may either want to
avoid, as far as possible, crossing area and thus prefer selecting a
sub-optimal intra-area path, or conversely may prefer to use a shortest
path, even if it crosses areas. Thus, the solution MUST allow to enable
or disable area crossing, for inter-area TE LSPs whose Head-End and
Tail-End reside in the same area.
5.14. Inter-area routing policy
In case of inter-area TE LSP failure in the backbone or tail-end area,
it may be interesting to allow the ABR upstream to the failure to try to
recover the LSP using a procedure such as defined in [CRANKBACK]. This
may reduce the recovery delay, but with the risk of multiple crankbacks,
sub-optimal path, ? The solution SHOULD provide the ability to
allow/disallow crankback via signaling on a per-LSP basis.
5.15. Inter-area MPLS TE fault management requirements
In a MPLS network, a SP wants to detect both control plane and data
plane failures. But tools for fault detection over LSPs haven't been
widely developed so far. SPs today manually troubleshoot such failures
in a hop-by-hop fashion across the data path. If they detect an error
on the data plane, they have to check the control plane in order to
determine where the faults come from.
The proposed solution SHOULD be able to interoperate with fault
detection mechanisms of intra-area TE.
The solution SHOULD support [LSP-PING] and [MPLS-TTL].
[LSP-PING] provides a mechanism to verify the data plane liveliness of
MPLS TE LSPs. However, the mechanism does not include a method to
verify the link/node protection paths.
As for the backup paths, it is not possible to verify the data plane
until such protection paths are actually in use. A control plane
10
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
mechanism allowing to check the validity of the backup paths is
desired. The solution should be able to automatically verify the backup
paths for inter-area TE LSP.
6. Evaluation criteria
6.1. Performances
The solution SHOULD clearly be evaluated with respects to the following
criteria:
(1) Optimality of the computed inter-area TE LSP path,
(2) Optimality of the computed backup tunnel path protecting against
the failure of an ABR, capability to share bandwidth among backup
tunnels protecting independent facilities.
(3) Inter-area TE LSP set up time,
Other criteria may be added in further revisions of this draft
6.2. Complexity and risks
The proposed solution (s) SHOULD not introduce unnecessary complexity
to the current operating network to such a degree that it would affect
the stability and diminish the benefits of deploying such solution over
SP networks.
6.3. Backward Compatibility
The deployment of inter-area MPLS TE SHOULD not have impact on existing
MPLS TE mechanisms to allow for a smooth migration or co-existence.
7. Security Considerations
Inter-area MPLS-TE does not raise any new security issue, beyond those
of intra-area MPLS-TE.
References
[RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) ? Version
1, Functional Specification?, RFC 2205, September 1997.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[TE-OVW], Awduche, et al, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, May 2002.
[TE-REQ], Awduche et. al., "Requirements for Traffic Engineering
over MPLS", RFC2702, September 1999.
11
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
[REFRESH-REDUCTION] Berger et al, ?RSVP Refresh Overhead Reduction
Extensions?, RFC2961, April 2001.
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December
2003.
[BANDWIDTH-PROTECTION] Vasseur et all, ?MPLS Traffic Engineering Fast
reroute: bypass tunnel path computation for bandwidth protection »,
draft-vasseur-mpls-backup-computation-01.txt, October 2002, Work in
progress.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress).
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-04.txt (work in progress)
[SECOND-METRIC] Le faucheur, ?Use of IGP Metric as a second TE Metric?,
Internet draft, draft-lefaucheur-te-metric-igp-02.txt.
[MULTIPLE-METRICS] Fedyk D., Ghanwani A., Ash J., Vedrenne A. ?Multiple
Metrics for Traffic Engineering with IS-IS and OSPF?, Internet draft,
draft-fedyk-isis-ospf-te-metrics-01.txt
[PATH-COMP] Vasseur et al, ?RSVP Path computation request and reply
messages?, draft-vasseur-mpls-computation-rsvp-04.txt, work in
progress.
[RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP",
(work in progress).
[OSPF-TE-CAP] Vasseur, Psenak. "OSPF TE TLV capabilities", draft-
vasseur-mpls-ospf-te-cap-00.txt, October 2002 (Work in Progress).
[OSPF-CAP] Lindem et all ? Extensions to OSPF for Advertising Optional
Router Capabilities?, draft-ietf-ospf-cap-01.txt, work in progress.
[ISIS-CAP] Aggarwal et all, ?Extensions to IS-IS for Advertising
Optional Router Capabilities?, work in progress
[LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Establishment Using RSVP-TE", (work in progress).
[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay
Model", (work in progress).
[EXCLUDE-ROUTE] Lee et all, Exclude Routes - Extension to RSVP-TE,
draft-ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress.
12
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
[INTER-AREA-TE] Kompella et all,?Multi-area MPLS Traffic Engineering?,
draft-kompella-mpls-multiarea-te-04.txt, June 2003.
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,
Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",
Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. (Work
in Progress)
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443 Updates RFC 3032) ", January 2003
[INTER-AS-TE-REQS] Zhang et al, ?MPLS Inter-AS Traffic Engineering
requirements?, draft-ietf-tewg-interas-mpls-te-req-03.txt (work in
progress).
[LOOSE-PATH-REOPT] Vasseur and Ikejiri, ?Reoptimization of an explicit
loosely routed MPLS TE paths?, draft-vasseur-mpls-loose-path-reopt-
02.txt, June 2003, Work in Progress.
[NODE-ID] Vasseur, Ali and Sivabalan, ?Definition of an RRO node-id
subobject?, draft-ietf-mpls-nodeid-subobject-01.txt, June 2003, Work
in progress.
[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002.
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443 (Updates RFC 3032) ", January 2003.
[INTER-AS-TE-LINK] JP Vasseur, « Inter-ASBR TE Link type », draft-
vasseur-ccamp-inter-as-link-type-00, Work in progress.
[MPLS-Recov] V. Sharma, et al, "Framework for Multi-Protocol Label
Switching (MPLS)-based Recovery", RFC 3469 February 2003
Authors' Address:
JP Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
13
draft-leroux-tewg-inter-area-TE-reqs-00.txt December 2003
E-mail: jeanlouis.leroux@francetelecom.com
Ting-Wo Chung
Bell Canada
181 Bay Street, Suite 350, Toronto, Ontario, Canada, M5J 2T3
Email: ting_wo.chung@bell.ca
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025
USA
Email: raymond_zhang@infonet.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460,
JAPAN
E-mail : ke-kumaki@kddi.com
Yuichi Ikejiri
NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019
JAPAN
Email: y.ikejiri@ntt.com
Parantap Lahiri
MCI
22001 louden county pky
Ashburn, VA 20147
USA
E-mail: parantap.lahiri@mci.com
14