Internet Draft Alia Atlas
Expires: January 2002 Curtis Villamizar
- Avici Systems
Caren Litvanyi
- Qwest Communications
July 2001
MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute
draft-atlas-rsvp-local-protect-interop-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Routers implementing the local protection enhancements given in
[draft-ietf-mpls-rsvp-lsp-tunnel-08.txt], whose usage is clarified in
[draft-swallow-rsvp-bypass-label-01.txt], and routers implementing
solely [draft-gan-fast-reroute-00.txt] do not interoperate to provide
local protection. Those routers which follow the guidelines given in
this draft should be able to interoperate with either type of
implementation. The guidelines also specify how to support make-
before-break with backup LSPs.
Atlas et al. [Page 1]
Internet Draft July 2001
Contents
1. Introduction .............................................. 3
2. Terminology ............................................... 3
3. Ingress Support ........................................... 4
3.1 Requesting Local Protection .............................. 4
3.2 Detecting Protection Information ......................... 5
4. PLR Behavior .............................................. 6
4.1 Selecting Backup LSP Type ................................ 7
4.2 Bypass Tunnels ........................................... 8
4.3 Make-Before-Break on Backup Tunnels ...................... 8
4.3.1 Shared-Explicit and Backup LSPs ........................ 9
4.3.2 Make-Before-Break with Sender Addresses ................ 9
4.4 Catching ResvTears and Appropriate PathErrs .............. 10
4.5 Handling Resource Preemption ............................. 11
5. Merge Node Behavior ....................................... 11
5.1 Label Space .............................................. 11
5.2 Ignore Path Tears Unless From Ingress .................... 11
5.3 Simple and Detour Backup LSPs ............................ 12
5.4 ResvTears ................................................ 12
6. Security Considerations ................................... 13
7. References ................................................ 13
8. Authors' Addresses ........................................ 14
Atlas et al. [Page 2]
Internet Draft July 2001
1. Introduction
Routers may implement the local protection enhancements given in
[RSVP-TE], whose usage is clarified in [BYPASS], but not implement
[DETOUR]. Routers may also implement [DETOUR] without implementing
the local protection enhancements given in [RSVP-TE]. These two sets
of routers will not interoperate to provide local protection.
This draft assumes that a router falls into one of the following
three sets:
A. Implements both the local protection enhancements given in
[RSVP-TE] and [DETOUR] as described in this draft.
B. Implements only [DETOUR].
C. Implements only the local protection enhancements given in
[RSVP-TE], according to the guidelines in [BYPASS].
The guidelines given in this draft should allow routers in set A to
interoperate with either of the other two sets of routers, but not
both. A network with routers in set A and set B will be able to
provide local protection. A network with routers in set A and set C
will be able to provide local protection. A network that contains
routers from both set B and set C will not be able to provide local
protection in some cases involving paths with a mix of the two types
of routers, irrespective of the presence or absence of routers from
set A.
This draft also describes a modification to identifying LSPs
specified for Shared-Explicit which distinguish between primary and
backup bandwidth reservations. This is necessary to support make-
before-break on backup tunnels; how to support make-before-break on
backup tunnels is described.
More details on handling PathErrs and resource preemption is
provided.
2. Terminology
PLR (Point-of-Local-Repair): Any node along the primary LSP's path is
a potential PLR. A node becomes an active PLR when it takes action
to transfer traffic from the primary LSP to a backup tunnel when a
failure is locally detected. When discussed in examples, the
specific potential PLR of interest is the node which originates the
specific backup tunnel under discussion.
Atlas et al. [Page 3]
Internet Draft July 2001
Backup Tunnel: A backup tunnel is logically created from the PLR to a
merge node on the primary LSP's path; which specific merge node is
used can vary between the backup LSPs contained in the backup tunnel.
The backup tunnel can contain one or more backup LSPs for a given
primary LSP. The concept of a backup tunnel permits make-before-
break for backup LSPs.
Backup LSP: A backup LSP extends from its origin at the PLR to a
specific merge node, where it rejoins the primary LSP. A backup LSP
is part of a Backup Tunnel. There are three types of backup LSPs -
simple, detour and unsignalled.
Simple Backup LSP: A Simple Backup LSP is a backup LSP whose PATH
message does not include the DETOUR object. The ERO contains the
selected backup path to the merge node and then an exact duplicate of
the primary LSP's ERO from that merge node to the egress.
Detour Backup LSP: A Detour Backup LSP is a backup LSP whose PATH
message includes the DETOUR object. The ERO simply contains the
selected backup path to the merge node.
Bypass Tunnel: A tunnel from the PLR of interest to a specific merge
node through which traffic across unsignalled backup LSPs can be
passed. This is used as defined in [BYPASS].
Unsignalled Backup LSP: An Unsignalled Backup LSP can only exist if
there is an appropriate bypass tunnel. This bypass tunnel is used so
that the Unsignalled Backup LSP is logically one hop away from the
merge node. No RSVP signalling is done to create or indicate the
existence of the Unsignalled Backup LSP. The Unsignalled Backup LSP
uses the label provided by the merge node, via the Label sub-object,
to forward traffic to the merge node, as described in [BYPASS].
Fully Protected: A primary LSP is considered to be fully protected
when each potential PLR in its path has a current backup tunnel
available.
3. Ingress Support
3.1 Requesting Local Protection
The [DETOUR] and [BYPASS] propose different methods for the ingress
to signal that an LSP desires local protection. These methods are
not mutually incompatible. The ingress must both include the
FAST_REROUTE object in the PATH message and set the two flags, "Label
Recording desired" and "Local Protection desired", in the
SESSION_ATTRIBUTE object[RSVP-TE].
Atlas et al. [Page 4]
Internet Draft July 2001
By including the FAST_REROUTE object, any nodes on the primary LSP
which implement [DETOUR] will know that the primary LSP requires
protection. By setting the "Local Protection desired" flag in the
SESSION_ATTRIBUTE object, any nodes which implement [BYPASS] will
know that the primary LSP requires protection. The FAST_REROUTE
object provides constraints on the backup tunnel; those constraints
can be configured solely at the primary tunnel's ingress and can
differ easily differ between primary LSPs.
If the ingress sets the "Label Recording desired" flag in the
SESSION_ATTRIBUTE, the resulting Label subobjects in the RRO permit
those PLRs which implement [BYPASS] to create Unsignalled Backup
LSPs. If there are nodes in the primary LSP's path which do not
understand Label subobjects and do not ignore the unrecognized
subobjects, as they SHOULD according to [RSVP-TE], then the ingress
should not set the "Label Recording desired" flag in the SESSION
ATTRIBUTE. If this flag is not set, the interoperability affected
will be with routers which only support Unsignalled Backup LSPs.
This must be a configured option at the ingress. It is assumed that
the network operator knows whether routers in the network support
LRO, don't support but correctly ignore request for LRO, or handle
the LRO in violation of the specification.
3.2 Detecting Protection Information
The primary tunnel's ingress is responsible for determining when
rerouting of the primary path is desirable. For instance, if local
protection is in use on the current primary LSP, it would be
desirable to compute a new primary LSP.
The ingress must also determine when to move from a current LSP to a
new LSP, via make-before-break. For instance, it will take time
before a newly created primary LSP will be fully protected. If the
new primary LSP were to be created due to a configuration change or
adaptation to network changes, then the ingress might wait to move
traffic to the new primary LSP until that is fully protected.
Alternatively, if the new primary LSP were to be created because
local protection is in use on the current primary LSP, the ingress
may move traffic immediately to the new primary LSP or it may wait
until the new primary LSP is as locally protected along its path as
the current primary LSP is.
For both of the reasons above, the ingress must know what nodes along
an LSP's path are currently providing local protection and which have
that local protection in use. The "Local protection available" and
"Local protection in use" in the IPv4 address and IPv6 address
subobjects of the RRO [RSVP-TE] provide the necessary information to
Atlas et al. [Page 5]
Internet Draft July 2001
the ingress. The ingress may be notified that local protection is in
use via a PathErr message with an error code of "Notify"(25) and an
error value of "Tunnel locally repaired"(3) by nodes implementing
[BYPASS].
Routers implementing only [DETOUR] without the local protection
enhancements given in [RSVP-TE] may not set the "Local protection
available" and "Local protection in use" flags in the IPv4 and IPv6
address subobjects of the RRO.
To permit the ingress behavior described early in this section, the
ingress should be configured with information about which nodes
implement only [DETOUR] and, therefore, do not support a means to
indicate that local protection is available at that node. Such nodes
can be ignored at the ingress in any decision regarding whether the
protection is fully available (it must be assumed that protection is
available for any such node when any RSVP RESV arives).
4. PLR Behavior
Once an ingress or midpoint node has determined that a given LSP is
requesting local protection, that node, acting in the role of a PLR,
must determine the link(s) and/or node(s) that the backup tunnel must
avoid. Then, the PLR must determine the backup path and merge node.
Finally, the PLR must determine what type of backup LSP to use and
create it.
A link or node could fail for a variety of reasons. Links for which
failure may be correlated are determined through the use of Shared
Risk Link Groups (SRLGs). SRLGs may be signaled via [GMPLS IS-IS]
and [GMPLS OSPF]. The PLR can determine what SRLGs are present
through this signaling or through configuration at each node of all
SRLGs in the entire network.
Some routers may support only signaled SRLGs and therefore SRLG
signaling must be originated. Some routers may only support
configured SRLGs and therefore cannot originate signaled SRLGs and
therefore the ability to configure SRLGs for external links must be
supported.
4.1 Selecting Backup LSP Type
The PLR may decide to create a backup LSP either when it has received
the primary LSP's PATH message or after it has received the primary
LSP's RESV message. The latter case is required if unsignalled
backup paths are desirable. The former case is reasonable if most
Atlas et al. [Page 6]
Internet Draft July 2001
LSPs are expected to be created successfully and if the ERO is
primarily strict hops, so that a reasonable merge node can be
determined.
To determine which type of backup LSP to create, the PLR must infer
what type of routers share the local domain. If the other routers
implement [BYPASS], then either a simple backup LSP or an unsignalled
backup LSP should be created. If the other routers implement
[DETOUR], then a detour backup LSP should be created.
If the PLR is to create a backup LSP when it has received the primary
LSP's PATH message, then the PLR must determine the type of backup
LSP based upon the inferred type of the ingress. If the primary's
PATH message contains a FAST_REROUTE object, it is assumed that other
routers will support the [DETOUR]. The PLR will attempt to create a
detour backup LSP. If no FAST_REROUTE object is found or if the
detour creation is rejected, as indicated by a PathErr with the error
code "Unknown object class", then a simple backup LSP can be
attempted. The latter case can only occur in a mixed network where
the ingress supports [DETOUR] but a node along the selected backup
path does not. In this case, the backup LSP must be resignaled
without a DETOUR object.
When the PLR creates a backup LSP after it has received the primary
LSP's RESV message, the decision as to backup LSP type is based upon
inferring the behavior of the merge node. If the merge node has
recorded a label, via a subobject in the RRO, then the PLR can assume
that the merge node implements [BYPASS] with the RSVP enhancements
given in [RSVP-TE]. Otherwise the merge node is assumed to implement
[DETOUR] and a detour backup LSP is signalled. If the selected merge
node does not support, or is assumed to not support, the DETOUR
object, then a simple backup path can be used. Using this method, the
PLR can provide the most efficient backup LSP feasible given the
capabilites of the downstream LSRs.
4.2 Bypass Tunnels
The use of the tunnel heirarchy described in [BYPASS] provides
enhanced scalability for local protection. The midpoint nodes along
the active LSP of the bypass tunnel are aware of and reserve for only
one LSP, but multiple backup LSPs can use the same bypass tunnel.
This use of a label stack is not limited to the unsignalled backup
LSPs discussed in [BYPASS]. It is also possible to have simple
backup LSPs or detour backup LSPs be tunneled through a bypass
tunnel. To do this, the simple or detour backup LSP's PATH message
must be sent through the bypass tunnel; it will emerge at the merge
Atlas et al. [Page 7]
Internet Draft July 2001
node. The backup path part of the ERO would simply be the merge
node. To support this, the merge node and the PLR must trust each
other to provide legitimate RSVP messages.
A bypass LSP may also be used by the PLR to avoid sending a DETOUR
object through a node which does not support [DETOUR] to reach a
merge node that does support [DETOUR] and does not support LRO.
4.3 Make-Before-Break on Backup Tunnels
In supporting make-before-break on backup tunnels, the option of
using a different LSP-ID is not available. As described in [RSVP-TE],
when doing a make-before-break on a regular tunnel, the ingress will
allocate a new LSP ID to be used when creating a new LSP. Because
the SESSION object of the current LSP and that of the new LSP are the
same and Shared-Explicit (SE) is specified, resources will be shared.
When signalling a backup LSP, the LSP ID used (sent in the
SENDER_TEMPLATE and the FILTER_SPEC objects) is that of the primary
LSP which the backup LSP is protecting. The SESSION object used when
signalling the backup LSP is the same as the SESSION object of the
primary LSP. This behavior is common in [BYPASS] and [DETOUR].
4.3.1 Shared-Explicit and Backup LSPs
To properly support make-before-break on a backup tunnel, shared-
explicit must be used on that backup tunnel. However, if this were
done simply based upon the SESSION object, as is specified in [RSVP-
TE], then the backup LSPs and the primary LSPs would share resources.
This is undesirable, as demonstrated by the following topology.
I---------J
/| |
/ | |
A----B E----F----G
| /| | /
| / | | /
| / | | /
|/ | |/
C----D----H
Consider a primary LSP which goes A-B-C-D-E-F-G. The backup LSP for
E might go E-C-D-H-G. In this case, both the primary LSP and the
backup LSP traverse the link C-D in the same direction. If the
Shared-Explicit means that the primary LSP and backup LSP share
resources, then only the maximum of the primary LSP's bandwidth and
Atlas et al. [Page 8]
Internet Draft July 2001
the backup LSP's bandwidth would be reserved on C-D. This would mean
that insufficient resources are reserved in the event of a failure of
link E-F.
Consider if the backup LSP at B is B-I-J-F. If the link B-C failed
and A tried to create a new primary LSP, the new LSP would have to
travel across the I-J link. It is possible that the link I-J has
only enough bandwidth for either the backup LSP or the new primary
LSP.
From these two cases, it is clear that, backup LSPs cannot share
bandwidth with the primary LSP that they are protecting and that
backup LSPs must share bandwidth with primary LSPs that they are not
protecting. All primary LSPs must share bandwidth with each other,
as described in [RSVP-TE], to permit make-before-break.
To resolve this requires that the "LSP ID" of the FILTER_SPEC (or
SENDER_TEMPLATE) be considered when determining whether LSPs should
share resources once Shared-Explicit is specified. If the LSP IDs in
two different RESV (or PATH) messages are different, then they can
share resources. If the LSP IDs are the same, then they cannot share
resources. This does not result in transitive sharing.
i) Backup LSPs for LSP n
ii) Primary LSP n
iii) Primary LSP k
iv) Backup LSPs for LSP k
Consider the above four groups of LSPs. (i) can share with (iii) and
(iv). (ii) can share with (iii) and (iv). (iii) can share with (i)
and (ii). (iv) can share with (i) and (ii).
A router following these guidelines should implement this enhancement
of the rules for shared-explicit. If all backup LSPs always have zero
bandwidth reserved, then this enhancement is not needed.
Constraining all backup LSPs to use zero bandwidth is a severe
restriction and unacceptable in some situations.
4.3.2 Make-Before-Break with Sender Addresses
The prior subsection clarifies how Shared-Explicit can be specified
for backup LSPs. The Shared-Explicit is required for make-before-
break, as explained in [RSVP-TE]. The other piece necessary for
make-before-break is a way of distinguishing the current backup LSP
from the new backup LSP. For a regular TE tunnel, this is done by
changing the LSP ID. However, the LSP ID is used to associate the
backup tunnel with a specific primary LSP. Therefore, the LSP ID
Atlas et al. [Page 9]
Internet Draft July 2001
cannot be changed to do a make-before-break on the backup tunnel.
The other content of the SENDER_TEMPLATE (and FILTER_SPEC) is the
"IPv4 (IPv6) tunnel sender address". As suggested in [BYPASS], the
PLR will fill out this address with one of the PLR's addresses for
simple backup LSPs. A router implementing [DETOUR] may not modify
this address in the SENDER_TEMPLATE; when a PLR, this router will put
the PLR's address in the "Source ID" field in the DETOUR object.
Any router which can distinguish a backup LSP from a primary LSP must
do so based upon either the "IPv4 (IPv6) tunnel sender address" in
the SENDER_TEMPLATE (and FILTER_SPEC) or upon the "Source ID" in the
DETOUR object. Therefore, to signal two different backup LSPs from
the same PLR for the same primary LSP, the PLR must use different IP
addresses, which are put into the SENDER_TEMPLATE and/or the DETOUR
object.
To effect a reroute or a bandwidth change on a backup tunnel, the PLR
picks one of its IP addresses which is different from that used for
the current backup LSP in that backup tunnel and which is different
from that used for primary LSP. Then the PLR signals the new backup
LSP and proceeds with a make-before-break as described in [RSVP-TE].
To support make-before-break on backup tunnels in this manner, the
PLR must have ownership of two distinct IP addresses. If the PLR is
also ingress, then it requires a third distinct IP address, which it
uses when signalling primary LSPs. Only the router ID needs to be
routable. All three addresses MUST be unique within the MPLS domain,
and MUST be globally unique if chosen from public address space.
4.4 Catching ResvTears and Appropriate PathErrs
The PLR behavior described in this section should only start after
the primary LSP is known to be successfully created. If the backup
tunnel is created after a RESV is received for the primary LSP, then
it suffices to check whether the backup tunnel is up. If the backup
tunnel is created when a PATH message is received for the primary
LSP, then it is necessary that the backup tunnel be up and that a
RESV has been received for the primary LSP.
Under those circumstances, the PLR must not forward ResvTear
[DETOUR]. Instead, when a ResvTear is received, the PLR should move
traffic to the backup tunnel, if it is up, and then not propagate the
ResvTear upstream towards the ingress.
The PLR must also handle certain PathErrs similarly to how it handles
ResvTears. If the PLR receives a PathErr with an error code of
Atlas et al. [Page 10]
Internet Draft July 2001
"Policy Control failure", as happens when the primary LSP is
preempted, or a PathErr with an error code of "Routing Problem" and a
sub-code of "No route available toward destination", as may happen
when a link or node fails, then the PLR should similarly move traffic
to the backup tunnel, if it is up, and then not propagate the PathErr
upstream towards the ingress.
According to [RSVP-TE], the PathErr with the code "Policy Control
failure" occurs when the primary LSP to be preempted as the result of
another LSP being setup. This LSP failure caused by resource
preemption cannot be detected at the ingress based upon IGP (IS-IS or
OSPF) information. Therefore the ingress must be explicitly notified
if the PLR receives this type of PathErr and does not propagate it
further upstream toward the ingress; if so, the PLR should send a
PathErr with an error code of "Notify" and an error value of "Tunnel
locally repaired".
4.5 Handling Resource Preemption
It is possible for a primary LSP to have its resources preempted, due
to the arrival and admission of another LSP. If the PLR is making
this determination and has a backup tunnel, which is currently up,
for that primary LSP, then the PLR should move traffic from the
primary LSP to the backup tunnel and then send a PathErr with an
error code of "Notify" and an error value of "Tunnel locally
repaired". When this type of PathErr is received at the ingress, the
ingress should reroute the tunnel onto a new primary LSP using make-
before-break.
5. Merge Node Behavior
5.1 Label Space
To support all types of backup LSPs, a merge node must use a
platform-wide (aka global) label for an LSP which has requested local
protection.
If an implemention does not normally provide platform-wide labels for
unprotected RSVP-TE LSPs, additional behavior should be defined to
handle an LSP which changes from requesting local protection to not
and vice versa. It is not recommended to change this attribute of a
TE tunnel without doing a reroute.
5.2 Ignore Path Tears Unless From Ingress
Atlas et al. [Page 11]
Internet Draft July 2001
/--F----G----H--\
/ | | | \
A----B----C----D----E
Primary LSP: A-B-C-D-E
Bypass Tunnel's LSP: B-F-G-H-D
In the above example, consider what occurs when the link B-C fails.
B will start using its unsignalled backup path, which goes through
the bypass tunnel, and C will send a PathTear to D. If D acts upon
the PathTear received from C, then D would tear down the remainder of
the primary (D-E) which is required to deliver traffic sent over the
unsignalled backup path to the egress. Because B is using an
unsignalled backup path, D cannot determine that it is a merge node.
This example indicates that PathTears must be ignored for primary
LSPs which request local protection.
However, ignoring all PathTears means that the ingress cannot destroy
the primary LSP. This unfortunate loss of capability can be remedied
by examination of the PathTear message. If the PathTear's IP
packet's source IP address matches the "IPv4 (IPv6) tunnel sender
address" in the SENDER_TEMPLATE object, then the PathTear came from
the LSP's ingress and should not be ignored.
5.3 Simple and Detour Backup LSPs
A router can determine that it is the merge node of either a simple
backup LSP or a detour backup LSP. In the latter case, the DETOUR
object contains one of the merge node's IP addresses. In the former
case, if the matching primary LSP is known at the router and the ERO
in the simple backup LSP's PATH message matches the ERO in the
primary LSP's PATH message, then the node is the merge node. If the
router is the merge node for a simple backup LSP, then the simple
backup LSP's PATH message is not sent all the way to the egress, but
is instead merged to the primary LSP and handled at the merge node.
The merge node is responsible for constructing a RESV based upon the
primary LSP's RESV, including the RRO, and sending that.
As long as a router knows that it is the merge node for an existing
backup LSP, the router will not tear down the primary LSP to the
egress.
5.4 ResvTears
When a router receives a ResvTear for an LSP and it is not a PLR for
that LSP, then the router should propagate the ResvTear towards the
Atlas et al. [Page 12]
Internet Draft July 2001
LSP's ingress. For each backup LSP where the router is the merge
node, the ResvTear should also be propagated along the backup LSP
towards the backup LSP's ingress, a PLR.
This propagation clearly works for simple and detour backup LSPs.
For unsignalled backup LSPs, the router does not know it is a merge
node.
A----B----C----D
| | | |
E----F----G----H
Primary LSP: A-B-C-D
Bypass Tunnel 1: A-E-F-G-C
Bypass Tunnel 2: B-F-G-H-D
Bypass Tunnel 3: C-G-H-D
In the above example, consider the behavior when router D fails. C
will determine that both the primary LSP and bypass tunnel 3 are
down. Therefore, C will send a ResvTear to B. B will determine that
bypass tunnel 2 is down and that the primary LSP has been torn down,
due to receiving the ResvTear. Therefore, B will send a ResvTear to
A. A will determine that the primary LSP is down and will switch to
using an unsignalled backup path through bypass tunnel 1. Bypass
tunnel 1 is still up.
A will send a PATH message for the primary LSP through bypass tunnel
1 to C. C will determine the the next hop in the PATH's ERO is
unreachable and send a PathErr with error code "Routing Problem" and
a sub-code of "No route available toward destination". When A
receives this PathErr, A will determine that the unsignalled backup
LSP is no longer available and will propagate that error upstream.
6. Security Considerations
This draft provides guidlelines for the use of existing protocol
mechanisms defined in [RSVP-TE], [BYPASS], and [DETOUR] which are
designed to maximize interoperability. No new protocol is defined.
The usage or existing protocol described here does not introduce any
additional security risks.
7. References
[RSVP-TE] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt,
February 2001.
Atlas et al. [Page 13]
Internet Draft July 2001
[BYPASS] Swallow, G. and Goguen, R., "RSVP Label Allocation for
Backup Tunnels", Internet Draft, draft-swallow-rsvp-bypass-label-
01.txt, November 2000
[DETOUR] Gan, D. et al., "A Method for MPLS LSP Fast-Reroute Using
RSVP Detours", Internet Draft, draft-gan-fast-reroute-00.txt, April
2001
[GMPLS IS-IS] Kompella, K. et al., "IS-IS Extensions in Support of
Generalized MPLS", Internet Draft, draft-ietf-isis-gmpls-extensions-
02.txt, February 2001
[GMPLS OSPF] Kompella, K. et al., "OSPF Extensions in Support of
Generalized MPLS", Internet Draft, draft-kompella-ospf-gmpls-
extensions-01.txt, February 2001
8. Authors' Addresses
Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
Voice: +1 (978) 964-2070
Email: aatlas@avici.com
Curtis Villamizar
Email: curtis@avici.com
Caren Litvanyi
PO Box 2535
Cupertino, CA 95015
Email: litvanyi@synack.net
Atlas et al. [Page 14]