INTERNET DRAFT
Expiration Date: February 2003
Vijayanand C
HCL Technologies
Fast Reroute Extensions to CRLDP
draft-vijay-mpls-crldp-fastreroute-01.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.
Abstract
This document describes the use of CR-LDP [CRLDP] to establish
backup LSP tunnels for local repair of LSP tunnels established by
CR-LDP.
This document proposes extensions to existing CR-LDP for setting up
backup tunnels for protecting LSPs on an exclusive bandwidth basis
or shared bandwidth basis as desired by the initiator of the tunnel
at the head end node. Several backup segments are maintained for a
single LSP and they are meant to provide link and node failure
protection along various segments of the LSP. Control over the
location of the backup segments can be exercised by the tunnel
initiator. Sharing of backup segments across multiple LSPs is also
facilitated to achieve scalability
1. Introduction
MPLS serves as a high speed switching mechanism which leverages
existing layer 2 protocols with popular layer 3 routing protocols
and serves to establish a common control and management plane. High
Vijayanand C [Page 1]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
availability, fault tolerance and failure recovery are expected out
of MPLS solutions. CR-LDP is an extension to LDP[LDP] for
establishing traffic engineered LSPs across the network to meet the
needs of real-time applications and QoS conscious applications. The
need for quick responses to failures and recovery from such failures
is all the more important in such a scenario. Several solutions and
approaches have been proposed for providing protection and recovery
for MPLS CR-LDP tunnels in [MPLS-FRR], [CRLDP-PP].
This document describes the use of CR-LDP [CRLDP] to establish
backup LSP segments to take over traffic while local repair is in
progress for LSP tunnels. These backup segments exists across
sections of the LSP protecting it selectively against node and link
failures. These backup segments have the provision to be shared
across multiple LSPs traversing the protected set of links and
nodes, thus providing a scalable solution. Exclusive bandwidth
protection, Shared bandwidth protection and protection without
bandwidth guarantee are the options proposed in this document. By
the term LSP we mean an explicitly routed LSP with or without
bandwidth constraints.
In order to meet the needs of real-time applications such as voice
and video, in case of failure, it is required to re-direct such
traffic onto alternate paths in a few milliseconds. Since the local
repair mechanism cannot compute and establish an alternate path in
such a short time back up tunnels are used to take over the traffic
in the intervening time. Traffic will not be lost or delayed much
due to the latency in the local repair mechanism. Once the backup
segments are in place then on failure of a node or link the traffic
is switched to the back up tunnel from the point of local repair.
The backup segments are intended to cover both node and link
failures till the local repair mechanism computes an alternate path
for the primary LSP. Since the back up segments operate for a short
time they can be chosen to provide shared bandwidth protection or no
bandwidth guarantee at all depending on the application requirement
and the anticipated time for local repair.
2. Terminology
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 RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [CRLDP]
LSR - Label Switch Router
LSP - An MPLS Label Switched Path
Vijayanand C February 2003 [page 2 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
Local Repair - Techniques used to repair LSP tunnels quickly
when a node or link along the LSPs path fails.
Protected/Primary LSP - An LSP is said to be protected at a
given hop if it has one or multiple associated backup segments
originating at that hop.
Backup Segment - An LSP segment that is used to backup up one
or more primary LSPs traversing a set of nodes and links
PLR - Point of Local Repair. The head-end of a backup segment
MP - Merge Point. The LSR where one or more backup segments
rejoin the path of the protected LSP, downstream of the potential
failure.
One to Many backup segment - A backup segment which protects
multiple LSPs by bandwidth sharing along its links though the labels
for them along the links would be different. The bandwidth of this
segment is the highest of bandwidths shared by all individual LSPs.
3. CR-LDP Extensions
We propose two additional TLVs, TUNNEL_PROTECT TLV and BACKUP TLV to
CR-LDP. The TUNNEL PROTECT TLV has the U and F bit set to 1 .The
BACKUP TLV has the U and F bits set to zero. TUNNEL_PROTECT TLV will
be used in the Label Request message while the BACKUP TLV will be
used in the Label Request message and Label Release message.
3.1 TUNNEL_PROTECT TLV
The tunnel protect object is used by the Ingress LSR to indicate
that the tunnel needs to be backed up while local repair is in
progress.
The format of the tunnel protect TLV is given below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|11| Type( TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC limit | Flags | PLR Flag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLR ID 1 ( Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Avoid Node ID 1 ( Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLR ID n ( Optional) |
Vijayanand C February 2003 [page 3 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Avoid Node ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HC Limit:
The hop count limit indicates the maximum number of hops a backup
segment can have.
Flags :
0x00 - Bandwidth protection not needed
0x01 - Shared Bandwidth protection needed
0x02 - Exclusive Bandwidth protection needed
If shared bandwidth protection is desired then tunnels that desire
such protection can share bandwidth along the links of the backup
segment, else each tunnel should be given exclusive bandwidth in the
back up segment.
Bandwidth protection not needed indicates that backup segments need
not have any bandwidth reservation in the back up segment. This and
shared bandwidth can be chosen when no bandwidth guarantees are
needed for the short time when local repair is going on.
PLR Flag :
0x00 - No PLRs and avoid nodes are specified
0x01 - List of PLRs and avoid nodes are specified
The PLR IDs and Avoid Node IDs are processed only if the PLR Flag is
set to one. Setting the PLR flag to one gives the flexibility for
the head end LSR to specify the list of nodes, which will act as
points of local repair along with the nodes that they should avoid
in the backup segments they originate. If the PLR Flag is set to
zero, then all the nodes along the path which recognize the TUNNEL
PROTECT TLV and implement this extension should initiate backup
segments.
PLR ID (1 - n):
IPv4 address identifying the beginning point of a backup segment
which is a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n)
IP address identifying the immediate downstream node that the PLR
is trying to avoid. Router ID of downstream node is preferred.
The PLR Node ID and Avoid Node ID are optional. If the PLR Flag is
not set then all the nodes in the path of the label request which
recognize the Tunnel protect TLV can act as PLR nodes.
Vijayanand C February 2003 [page 4 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
The format of the request message with the TUNNEL PROTECT TLV is
given below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP,mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV (CR-LDP,optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TUNNEL PROTECT TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pinning TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pre-emption TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 BACKUP TLV
The back up TLV is used along the backed up section of the tunnel
while signaling the same.
The format of the TLV is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00| Type( TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLR Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Merge Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vijayanand C February 2003 [page 5 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
The PLR Node ID indicates the point of local repair. This is the
node which serves as the starting point of the backup segment
The Merge Node ID indicates the node where the backup segment merges
with the primary LSP
The flags field has the same meaning as in TUNNEL PROTECT TLV
This TLV is originated by the PLR itself
The format of the label request message with the BACKUP TLV is
given below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BACKUP TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pinning TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pre-emption TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Signaling for Back up Tunnels and Operational Overview
While setting up the LSP tunnel, at the head-end LSR, the TUNNEL
PROTECT TLV is sent in the label request message for tunnels which
need to be protected/backed up. If the TUNNEL PROTECT TLV has the
PLR Flag set then only those nodes whose node IDs appear as PLR
Nodes IDs should initiate backup segments. Each of these backup
segments avoid the node whose ID is mentioned as the avoid node ID
for the respective PLRs. After the PLR node processes the TLV it
should propagate the label request further after removing the PLR
Vijayanand C February 2003 [page 6 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
Node ID and Avoid ID pertaining to it. If the PLR flag is not set in
the TUNNEL PROTECT TLV, each node along the path which recognizes
this TLV and is capable of rapidly switching over traffic to backup
segments in case of failure initiates the setting up of backup
segments, in addition to the usual CR- LDP request message
processing. An alternate path is computed by the node and a label
request with the BACKUP TLV is sent along the back up path. The
BACKUP TLV is constructed at the PLR after the backup segment is
computed. The ER TLV that is sent along the back up segment must
contain hops upto the Merge Point(MP) only, where the protected LSP
and backup segments merge. The list of ER HOPs in the primary LSP
is used along with the topology information to compute the merge
point. The MP, when it processes the label request, recognizes that
it is the end of a back up segment and merges it with the
primary/protected LSP whose LSPID is present in the LSPID TLV. The
BACKUP TLV is used by the MP to recognize it as a request for
setting up the backup segment. This request must not be propagated
any further. Label mapping must be sent towards the PLR when label
mapping is received for the primary/protected LSP. Thus the MP will
send two label mappings one along the primary LSP and another along
the backup segment. The PLR node can distinguish the two mappings as
belonging to the primary LSP and backup segment since the requests
were sent by itself. In case any of the nodes along the backup
segment including the MP do not recognize the BACKUP_TLV an unknown
TLV notification must be sent towards the PLR and the backup segment
establishment would fail.
If no PLR and avoid Node IDs are mentioned each node along the path
would have a backup segment starting from it and ending at a node
which is atleast more than one hop away along the PLR, to ensure
link and node protection.
[R1]---[R2]----[R3]----[R4]---[R5]
\\ //
[R6]===[R7]
In the above example, R2 in this case would build a backup segment
[R2->R6->R7->R4]. The doubled lines represent this segment. The
backup tunnel for [R1->R2->R3->R4->R5] again rejoins the original
path at R4. R2 is the PLR and R4 the MP.
Similarly there would be backup segments across R1 to R3 and R3 to
R5 if R1 and R3 are candidate PLRs. The above scenario would also
arise when the TUNNEL PROTECT TLV has PLR, Avoid Node IDs sequence
as R1-R2 , R2-R3 and R3-R4.
Multiple back-up segments of the same LSP could merge into a single
backup segment if paths computed by nodes on the same primary LSP
for the same primary LSP have links in common. The common nodes
start from a node on the backup segment called the point of backup
Vijayanand C February 2003 [page 7 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
merger upto the MP with the primary LSP. The nodes recognize this
and propagate only a single label request from the point of backup
merger of the backup segments. For this, the path from the point of
backup merger to the merge point with the primary LSP should be
exactly same in the ER HOP TLV, otherwise merging should not be
done. In this case when the mapping message arrives at the point of
backup merger in the backup segment it sends out two label mappings
towards each of the PLR nodes upstream.
[R1]---[R2]----[R3]----[R4]---[R5]---[R6]
\\ \\ //
[R7]=== [R8]=== [R9]
In the above example, the backup segments from R2 and R3 have R5 as
the MP as per the computation done by them. The two backup segments
merge at R8.Hence R8 is the point of backup merger, while R5 is the
MP with the primary LSP.
Another scenario for merger occurs in the back up path when two
different tunnels requesting shared bandwidth protection have links
in common from point of backup merger in back up path to merge point
with primary LSP. The flags field in the BACKUP TLV, will be used to
determine whether sharing can be done from point of backup merger in
the backup segment. In this case, since shared bandwidth protection
is desired, the higher of the bandwidths is used. However
different label request messages have to be propagated to maintain
the identity of the individual LSPs. This results in a scenario
where LSPs share bandwidth. This choice is useful because the backup
tunnels operate for a very short time when local repair of primary
LSP is in progress. This results in a one to many backup segment
because the bandwidth in the backup segment is shared by multiple
primary LSPs.
When there is a node or link failure the traffic is immediately
switched to the backup segment at the PLR even while the local
repair mechanism is initiated in the PLR. Thus the traffic is not
lost/delayed because of the computation and set up latency of the
local repair mechanism.
When the local repair mechanism completes, the primary LSP is
complete once again. Let this be called as the new primary LSP.
Traffic is switched back to the new primary LSP from the backup
segment. The repaired segment of the new primary LSP would traverse
a different set of links and nodes compared to the failed segment.
Hence the new primary LSP segment needs to be protected. For this,
the existing backup segment is first released. The release is
initiated by the PLR. The release message contains the BACKUP TLV to
indicate that it is for the back up segment. The MP uses the BACKUP
TLV to identify that the release is for the back up segment. After
Vijayanand C February 2003 [page 8 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
the backup segment is released a new backup segment is initiated by
the PLR and established as described earlier.
The new primary LSP may not be an optimal path from a network-wide
perspective. The head-end LSR periodically re-computes the traffic
engineered LSPs in order to accomodate the topology changes detected
by the IGPs and arrives at an optimal path. This mechanism, which is
an inherent part of traffic engineered LSPs and outside the scope of
this document, ensures that topology changes and local repair
mechanisms do not leave the network in a sub-optimal state for long.
When a primary LSP is released from its head end via a release
message, each of the PLR nodes which have initiated back up segments
have to release the back up segments in addition to the primary
segments by means of release message along the backup segments.
These release messages must contain BACKUP TLV in addition to the
usual list of TLVs.
If the LSP is torn from a node downstream of MP, by means of
withdraw messages, each of the MPs long the path back to the head-
end propagate withdraw to both the primary and back up segments.
There is however, no need for the BACKUP TLV in the withdraw message
as the PLR can identify the back up segment.
In case a failure occurs along the backup segment, the existing
backup segment is torn down by withdraw and release messages from
the point of failure. The PLR then reinitiates a new backup segment.
Label mapping and withdraw messages sent on the back up segment from
the MP to the PLR should not be propagated towards the head end by
the PLR
5. Back up Path Computation
Back up path computation is done by the PLR taking the following
aspects into consideration (apart from the usual CRLDP constraints
parameters):
- The Avoid Node IDs, if specified in the TUNNEL PROTECT TLV
- Whether shared or exclusive bandwidth protection is needed. If
shared bandwidth reservation is only needed then bandwidth used by
existing shared bandwidth LSPs can be re-used. This involves
knowledge of existing LSPs, which are open to sharing bandwidth in
their back up paths.
- The hop count limit for the back up segment. The hop count of the
segment computed should be within the specified path count limit
Vijayanand C February 2003 [page 9 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
- The backup segment should provide link and node protection for
atleast one node and one link if the PLR and Avoid Node IDs are not
specified in the TUNNEL PROTECT TLV.
- The list of ER HOPS in the label request for the primary LSP needs
to be taken into account so that the backup segment does not deviate
too much from the requested ER HOPs.
The algorithm used for this computation is outside the scope of this
document.
6. Interoperability Considerations
The PLR nodes, the merge point nodes and all nodes along the back up
tunnel must recognize this extension to CRLDP in order to provide
this feature. Nodes in the primary LSP which donot support this
feature will ignore the additional TLVs and silently forward them
since the U and F bits are set in the TUNNEL PROTECT TLV. This will
result in they not being part of any back up paths established as
per this document.
7. Open Issues
Rapid Notification of failure to the PLR node is outside the scope
of this document and may affect the effectiveness of this solution
8. Acknowledgements
The auth or expresses his deep sense of gratitude and heartfelt
thanks to Manikantan Srinivasan for his extremely valuable feedbacks
on this effort. The author also recalls Shankaranarayanan Ramamurthy
who inspired MPLS ideas and the discussions had with him on issues
in contemporary networks. The author thanks Kannan for his valuable
suggestions and comments.
9. Authors Address
Vijayanand C
HCL Technologies Limited
Technologies Division
184-188,NSK Salai,
Vadapalani,
Chennai - 600 026, India
Phone : +91-44-3728366/367 Ext: 1318
Email : vijayc@ctd.hcltech.com
10. References
Vijayanand C February 2003 [page 10 ]
INTERNET DRAFT Fast Reroute Extensions to CR-LDP September 2002
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "
LDP Specification ",RFC3036, January 2001
[CRLDP] B. Jamoussi, L. Andersson, R. Callon, R. Dantu, L. Wu, P.
Doolan,N. Feldman,A. Fredette,M. Girish, E. Gray,J. Heinanen, T.
Kilty, A. Malis, "Constraint-Based LSP Setup using LDP",RFC 3212,
January 2002.
[MPLS-FRR] Atsushi Iwata, Norihito Fujita, Tetsurou Nishida "MPLS
Signaling Extensions for Shared Fast Rerouting", work in progress,
<draft-iwata-mpls-shared-fastreroute-01.txt>, July 2001.
[CRLDP-PP] Ken Owens,Vishal Sharma,Srinivas Makam,Ben Mack-
Crane,Changcheng Huang,Bora Akyol "Extensions to CRLDP for MPLS Path
Protection",work in progress <draft-owens-crldp-path-protection-ext-
01.txt>, July 2001
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
draft-katz-yeung-ospf-traffic-05.txt, June 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-traffic-03.txt, June 2001.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.
Vijayanand C February 2003 [page 11 ]