Network Working Group Jonathan P. Lang (Calient Networks) Internet Draft John Drake (Calient Networks) Category: Informational Yakov Rekhter (Juniper Networks) Expiration Date: January 2002 Adrian Farrel (Movaz Networks) July 2001 Generalized MPLS Recovery Mechanisms draft-lang-ccamp-recovery-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 [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 draft discusses protection and restoration mechanisms for fault management within the GMPLS framework [GMPLS]. This draft does not propose any new additions to the GMPLS framework. Lang, J., Drake, J., Rekhter, Y. [Page 1] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 NAME OF I-D: www.ietf.org/internet-drafts/draft-lang-ccamp-recovery-00.txt SUMMARY This draft discusses protection and restoration mechanisms for fault management within the GMPLS framework [GMPLS]. RELATED DOCUMENTS www.ietf.org/internet-drafts/draft-many-gmpls-architecture-00.txt www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling- 04.txt www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te- 03.txt www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-02.txt www.ietf.org/internet-drafts/draft-kompella-ospf-gmpls-extensions- 01.txt www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt www.ietf.org/internet-drafts/draft-fredette-lmp-wdm-01.txt www.ietf.org/internet-drafts/draft-kompella-mpls-bundle-05.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This draft fits in the Control part of the sub-ip work. WHY IS IT TARGETED AT THIS WG This draft addresses the following CCAMP work items: - Abstract link and path properties needed for link and path protection. Define signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling and measurement protocols, either separately or in combination. JUSTIFICATION We believe this draft is justified for the CCAMP working group because it identifies signaling/routing mechanisms that can be used for both span and path protection. Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 2] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 1. Introduction A key requirement for the development of a common control plane for both optical and electronic networks is that there must be features in the signaling, routing, and link management protocols to enable intelligent fault management. Fault management requires four steps: fault detection, fault localization, fault notification, and fault recovery. Fault detection should be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is detecting loss of light (LOL); other techniques based on, for example, OSNR, BER, dispersion, crosstalk, and attenuation are still being investigated (see, for example, [OLCP] and [LMP-DWDM]). Fault localization requires communication between nodes to determine where the failure has occurred (for example, SONET AIS is used to localize failures between SONET terminating devices). One interesting consequence of using LOL to detect failures in optical networks is that LOL propagates downstream along the connectionÆs path. The Link Management Protocol (LMP) [LMP] includes a fault localization procedure that is designed to localize failures in both transparent (all-optical) and opaque (opto-electrical) networks, and is independent of the data encoding scheme. Fault notification is the Communication of a failure between the node detecting it and a node equipped to deal with the failure. Fast fault notification is essential for rapid recovery. The Notify mechanism of [RSVP-GEN] is designed to support fast notification of non-adjacent nodes. Once a failure has been detected and localized, and the responsible node has been notified, protection and restoration can be used to recover from the failure. We make the distinction between protection and restoration by the time scales in which they operate. Protection is designed to react to failures rapidly (say, in less than a couple hundred milliseconds) and often involves 100% resource redundancy. For example, SONET automatic protection switching (APS) is designed to switch the traffic from a primary (working) path to a secondary (protection) path in less than 50ms. This requires simultaneous transmission along both the primary and secondary paths (called 1+1 protection) with a selector at the receiving node, and uses twice as many network resources as a non-APS protected path. Restoration, on the other hand, is designed to react to failures quickly, but it typically takes an order of magnitude longer to restore the connection compared to protection switching. This is because restoration typically utilizes pools of shared resources that are more efficient in terms of the network utilization. In addition, restoration may involve rerouting connections, which can be computationally expensive if the paths are not pre-calculated or if the pre-calculated resources are no longer available. Protection and restoration methods have traditionally been addressed using two techniques: path-level recovery, where the failure is addressed at the end nodes (i.e., the initiating and terminating nodes of the path); and span-level recovery, where the failure is Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 3] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 addressed at an intermediate or transit node. Path-level recovery can be further subdivided into path protection, where secondary (or protection) paths are pre-allocated, and path restoration, where connections are rerouted, either dynamically or using pre-calculated (but not pre-allocated) paths. Span-level recovery can be subdivided into span protection, where traffic is switched to an alternate channel or link connecting the same two nodes, and span restoration, where traffic is switched to an alternate route between the two nodes (this involves passing through additional intermediate nodes). To effectively use protection, there must be mechanisms to configure protected links on a span between nodes, advertise the protection bandwidth of a link so that it may be used by a class of traffic that has different availability requirements, establish secondary (protection) LSPs to protect primary LSPs, allow the resources of secondary LSPs to be used by lower priority traffic until a switchover occurs, and signal protection switchover when necessary. In this draft, we discuss protection and restoration in the context of GMPLS signaling. Specifically, we address these issues in the context of RSVP signaling and OSPF and IS-IS routing. 2. Protection Mechanisms Protection is designed to react to failures in the fastest timescale and typically involves pre-provisioning protection resources. In this section we discuss both span and path protection and present mechanisms within GMPLS to implement both protection schemes. 2.1 Protection Levels The level of protection available is a function of the protection resources available for protecting a failed resource. o 1+1 Protection Two pre-provisioned resources are used in parallel. For example, data is transmitted simultaneously on two parallel links and a selector is used at the receiving node to choose the best signal. o 1:1 Protection Two resources (1 primary, 1 backup) are pre-provisioned. If the primary resource fails, then the data is switched to the backup resource. o 1:n Protection n+1 resources (n primary, 1 backup) are pre-provisioned. If there is a failure on any one of the primary resources, then the data is switched to the backup resource. At this point, the remaining n-1 primaries are no longer protected. o m:n Protection Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 4] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 n+m resources (n primary, m backup) are pre-provisioned. If there is a failure on any one of the primary resources, then data is switched to the backup resource. Note that 1:n and 1:1 are special cases of m:n protection. 2.1 Span Protection A span consists of a number of channels between two adjacent nodes that are grouped together into a single link, often called a traffic engineered (TE) link (see [LMP]). Span protection involves switching to a protection channel when a failure occurs on a working channel. At the span level, both dedicated (1+1, 1:1) and shared (M:N) protection may be implemented. The protection type supported by a TE link (LPT) is advertised throughout the network using an IGP so that intelligent routing decisions can be made (see Section 4). The desired protection for a path is signaled as part of the Generalized Label Request in GMPLS signaling. This is needed in signaling if a link supports multiple protection types or if loose routing is used. For dedicated 1+1 span protection, each node must replicate the data onto two separate channels (possibly using separate component links of a bundled link or separate ports of a TE link) and the adjacent node must select the data from only one channel based on the signal integrity. This is the fastest protection mechanism, however, it requires using twice the LSP bandwidth between each pair of nodes and the ability to replicate the data on two separate channels. For shared M:N protection, M protection links are shared between N primary links. Since data is not replicated on both the primary and secondary links, failures must first be localized before the switchover can occur. LMP can be used for fault localization, and the upstream node (upstream in terms of the direction an RSVP Path message traverses) will initiate the local span protection. To initiate span protection, the upstream node SHOULD send an RSVP Path message with a Label Set object including the labels for the available secondary links. If more than one label is included in the Label Set object, the Suggested Label object should be used to indicate the preferred secondary label. If the failure affected a bi-directional LSP, a new Upstream Label may also need to be transmitted. If the reverse direction of the bi-directional LSP uses a distinct component link from the failed forwards direction there is no need to re-signal the reverse path label unless there is a close correspondence between the label values chosen for the two directions. If the failed component link is bi-directional the failure might affect only one direction, but could affect both directions. If both directions fail then both labels must be re-signaled for use on new links. If the component link carrying the reverse path fails, but the forward path is unaffected, the reverse path label must be Resignaled. Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 5] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 In addition, new LinkId, PHOP, and modified ERO may also need to be included based on the shared protection configuration. Note that the benefit of exchanging the shared protection configuration in advance using LMP is that it minimizes the potential label conflict when protection switching. When the downstream node receives the Path message with the new objects, it MUST verify the parameters, update the RSVP Path state, and respond with either an RSVP Resv message with a new label or it should generate a PathError message if the resources are not available. 2.2 Path Protection Path protection is addressed at the end nodes of an LSP (i.e., LSP initiator and terminator) and requires switching to an alternate path when a failure occurs. For 1+1 path protection, a signal is transmitted simultaneously over two disjoint paths and a selector is used at the receiving node to choose the better signal. For M:N path protection, N primary signals are transmitted along disjoint paths, and M secondary paths are pre-established for shared protection switching among the N primary paths. 2.2.1 Simple Path Protection There are a number of path protection variations that may be implemented that provide different levels of protection. The most common notion of path protection is to select two disjoint paths, one primary and one secondary, where each link along both paths is unprotected. This protects against a single link or node failure, depending on how the two paths are disjoint. For example, in the network below it is possible to have a primary path A, B, C, D and a backup path A, E, F, D. These paths are entirely disjoint and are suitable for 1+1 or 1:1 protection. B---C / \ A D \ / E---F m:n path protection is also possible in simple topologies. Consider, for example: B---C---D | E---F | |/ \| A---G---H |\ /| | I---J | K---L---M Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 6] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 In this network there are five disjoint paths: {A, G, H}, {A, E, F, H}, {A, B, C, D, H}, {A, I, J, H} and {A, K, L , M, H}. These can be assigned as primary and backup resources to provide anything from 1:4 through 4:1 path protection. 2.2.2 1+1 Path Protection Using Span Protection One variation of 1+1 path protection is to select a single path where each link individually supports 1+1 span protection as discussed in Subsection 2.1. This protects against a single link failure, but not a node failure. One may also combine the two approaches by ensuring that for every contiguous segment of the path that includes only the links that don't support 1+1 span protection, the head-end LSR has to compute a link-disjoint segment, with the constraint that none of the links in the newly computed segments have link protection. After the two paths are computed, the head-end LSR will originate two LSPs with dedicated 1+1 and unprotected bits set in the LPT. The setup will indicate that these two paths request Shared-Explicit reservations (see [TUNNEL]). At each node where the two paths branch out, the node must replicate the data into both branches. At each node where the two paths merge, the node must select the data from only one path based on the integrity of the signal. For bi-directional LSPs, each branching point is also a merging point and vice versa. As an example consider the following: M / \ A---B C----D \ / N Only links A-B and C-D support 1+1 span protection. Node A wants to establish a 1+1 protected path to D. In this case, A computes a primary path, A, B, M, C, D where the segment B, M, C has links that do not support 1+1 protection. Therefore, A computes a link-disjoint segment, B, N, C, and uses it to construct a secondary path, A, B, N, C, D. A initiates a setup of two LSPs indicating the desire for Shared Explicit (SE) reservations - the first path is routed along A, B, M, C, D, and the second path is routed along A, B, N, C, D. Since the two LSPs branch out at node B, B sends the data it receives from A to both M and N. At node C, the two LSPs merge and C selects the data received over one of these LSPs (based on the integrity of the signal), and forwards this data to D. Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 7] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 When the LSP from A to D is bi-directional, then C must also send the data it receives from D to both M and N, and B must select the data received from either M or N, and forward it the to A. 2.2.3 M:N Path Protection There are a number of M:N path protection variations that may be implemented to provide different levels of protection and to address different network configurations. The most common notion of M:N path protection is to route N node-disjoint primary paths and pre- establish M backup paths that are node disjoint from the primary paths. This protects against M path failures. Another variation of M:N path protection is to select a single path where each link individually supports M:N span protection. This protects against M link failures over each span, but is not robust to node failures. One may also combine the two approaches by ensuring that for every contiguous segment of the path that includes only the links that donÆt support M:N span protection, the head-end node has to compute a node- or link-disjoint segment, with the constraint that none of the links in the newly computed segments need to be protected. An important feature of the GMPLS work is that it allows pre- configuring secondary (backup) LSPs to protect primary LSPs. This is done by indicating the LSP is of type Secondary in the protection field of the Generalized Label Request. Secondary LSPs are used for fast switchover when primary LSPs fail. Although the resources for the secondary LSPs are pre-allocated, lower priority traffic may use the resources with the caveat that the lower priority traffic will be preempted if the primary LSP fails. If lower priority traffic is using resources along the secondary LSPs, the end nodes may need to be notified of the failure in order to complete the switchover. The setup of the primary LSP SHOULD indicate that the LSP initiator and terminator wish to receive Notify messages using the Notify Request object. If a failure occurs, LMP can be used to isolate the failure. Once the failure is isolated, the upstream node (upstream in terms of the direction an RSVP Path message traverses) SHOULD send an RSVP Notify message to the LSP initiator, and the downstream node SHOULD send an RSVP Notify message to the LSP terminator. Upon receipt of the Notify messages, the source and destination nodes MUST switch the traffic from the primary LSP to the pre-configured secondary LSP. Note that if a common initiator-terminator is used for all N primary paths sharing the secondary path (assuming 1:N protection), no further notification is required to indicate that the N primary LSPs are no longer protected. As an example consider the following: A---B E---F / \ / \ I--- C----D ---T \ / \ / Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 8] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 J---K L---M Two node-disjoint routes from initiator I to terminator T cannot be found; however, two node-disjoint routes can be found from node I to node C and from node D to node T. Furthermore, the link from node C to node D is protected using dedicated 1:1 protection. In this case, I computes the primary route R1={I,A,B,C,D,E,F,T} and secondary route R2={I,J,K,C,D,L,M,T} where the segment {C,D} supports 1:1 span protection. A initiates a setup of two LSPs indicating the desire for Shared Explicit reservations; the primary LSP is routed along R1 and the secondary LSP is routed along R2. 3. Shared Resources The protection mechanisms described above are expensive in the resources that need to be dedicated. For example, if all of the LSPs in a network were afforded 1+1 or 1:1 protection, only half of the available network resources (bandwidth) would available for actual data traffic. Since the events that necessitate switching from primary span/path to backup span/path are supposedly rare or at least infrequent, this is a high price to pay for protection. 3.1 Merged Backups A popular way to reduce the pre-provisioned resource requirements is to have backup paths share network resources when the paths that they protect have different ingress points but share an egress. Consider the following topology: A---B---C---D \ \ E-----F-----G / / H---I---J---K The path A,B,C,D,G can be protected by the path A,E,F,G. Similarly, the path H,I,J,K,G can be protected by the path H,E,F,G. However, to achieve this level of protection the links EF and FG need to have available and provisioned the sum of the resources used on the paths A,B,C,D,G and H,I,J,K,G (that is the sum of the bandwidth). This may be impractical if the resources are unavailable, and is undesirable since it ties up excessive resources given that it is unlikely that both of the entirely distinct paths A to G and H to G will fail at the same time. In order to allow the backup paths to share resources using the standard features of GMPLS signaling, they must be signaled requesting Shared-Explicit reservations. Additionally, the LSPs must be identically identified so that the paths can be merged at node E. To achieve this, the Extended Tunnel Id must be set to the same value on both paths (usually zero) and the Tunnel Id must be Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 9] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 set to the same value on the two paths. This requires external co- ordination between the ingress points of the two paths. When a failure is detected on one primary path (say at B), the error is propagated to the ingress (A) which re-routes the data down the backup path. At this point, it is important that a failure on the other path (say at J) does not cause the other ingress (H) to send the data down the backup path since the labels and resources are already in use. This can be achieved by having a Notify message sent to H when B reports the failure. The Notify could be sent direct from B (by specifying H as the Notify recipient in the Notify Request object), could be sent from A after the error has been reported to A, or from E when the backup path starts to be used. 3.2 Sharing Resources without LSP Merging A further variant (shown below) occurs when the two paths to be protected have different ingress points and different egress points. A---B---C---D \ / E---F---G / \ H---I---J---K The paths A,B,C,D and H,I,J,K could be protected by A,E,F,G,D and H,E,F,G,K, respectively. The signaling to allow these backups to share resources cannot be done as described above since in order to achieve resource merging, the LSPs must have the same Session Ids, but the Session Id includes the target (egress) IP address. These addresses are not the same in this example. Resource sharing along E,F,G can only be achieved if the nodes E, F and G recognize the LSP type setting of Secondary in the protection field of the Generalized Label Request and act accordingly. In this case the backup LSPs are not merged (which is useful since the paths diverge at G), but the resources can be shared. When a primary path fails the other primary path ceases to be protected and must be sent a notification as described above. 4. Restoration Mechanisms Restoration is designed to react to failures quickly and use bandwidth efficiently, but typically involves dynamic resource establishment and may also require route calculation, and therefore, takes more time to switch to an alternate path than protection techniques. Restoration can be implemented at the intiator node or at an intermediate node once the responsible node has been notified. Failure notification can be done using the Notify procedures of [GMPLS] or using the standard RSVP PathError messages. In this Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 10] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 section, we briefly discuss span and path restoration and highlight the RSVP mechanisms that can be used to implement them. 4.1 Span Restoration To support span restoration, where traffic is switched to an alternate route around a failure, a new LSP is established at an intermediate node that involves passing through additional intermediate nodes. Span restoration may be beneficial for LSPs that span multiple hops and/or large distances because the latency incurred for failure notification may be significantly reduced and only segments of the LSP are rerouted instead of the entire path. If the protected part of the LSP is a single span, then error detection is sufficient to trigger restoration. If, however, protection is required over a series of more than one span a mechanism is required to notify to the point of repair that an error has occurred and that restoration is required. The RSVP Notify Request object can be used by an intermediate node to request that it be the target of an RSVP Notify message. Span restoration may break traffic-engineering (TE) requirements if a strict-hop route is defined for the connection. Furthermore, the constraints used for routing the connection must be forwarded so that an intermediate node doing span restoration is able to calculate an appropriate alternate route; this is similar to the problems when establishing/maintaining TE requirements that span mult-areas (see [MULTI] for a proposed mechanism). 4.1.1 Local Repair Local repair is a special case of span protection supported by the base RSVP-TE draft [TUNNEL]. The node that detects the failure may, make an alternate routing decision and attempt to re-signal the LSP. This approach may be considered too slow since it could rely on convergence of the routing table at the repair node. However, if there is a close link between routing and path computation components, Local Repair may be equivalent to span protection. 4.2 Path Restoration Path restoration, on the other hand, switches traffic to an alternate route around a failure, where the new route is selected at the LSP initiator and may reuse intermediate nodes used by the original LSP and it may include additional intermediate nodes. For strict-hop routing, TE requirements can be directly applied to the route calculation, and the filed node or link can be avoided. However, if the failure occurred within a loose-routed hop, the source node may not have enough information to reroute the connection around the failure. Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 11] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 The backup route may be calculated on demand (that is, when the failure occurs) or may be pre-calculated and stored for use when the failure is reported. This offers faster restoration time. There is, however, a risk that the backup route will become out of date through other changes in the network - this can be mitigated to some extent by periodic recalculation of idle backup routes. Restoration (span or path) will be initiated by the node that has isolated the failure or by the node that has received either an RSVP Notify message or an RSVP Path Error message indicating that a failure has occurred. The new resources can be established in a make-before-break fashion, where the new LSP is setup before the old LSP is torn down, using the mechanisms of the LSP_Tunnel Session object (see [TUNNEL]) and the Shared-Explicit reservation style. Both the new and old LSPs share resources at nodes common to both LSPs. The Tunnel end point addresses, Tunnel Id, Extended Tunnel Id, Tunnel sender address, and LSP Id are all used to uniquely identify both the old and new LSPs; this ensures new resources are established without double counting resource requirements along common segments. Note that make-before-break is not used to avoid disruption to the data flow (this has already been broken by the failure that is being repaired), but is valuable to retain the resources allocated on the original primary path that will be re- used by the new primary path. 5. Routing Enhancements The GMPLS extensions to OSPF [OSPF-GE] and IS-IS [ISIS-GE] include the advertisement of the LPT. The LPT field is a bit vector that indicates the protection capabilities that are supported for the link. The LPT field may be configured with Dedicated 1+1, Dedicated 1:1, Shared M:N, and Enhanced protection, as well as Unprotected. For a link that has dedicated 1+1 protection or is unprotected, this advertisement provides a complete description of the link capabilities and the usable bandwidth. However, a key argument for using dedicated 1:1 or shared M:N is the efficiency gained by reusing the protection bandwidth for lower priority traffic when the bandwidth would otherwise be idle. To advertise the protection bandwidth for a link that has dedicated 1:1 or shared M:N protection, a link with LPT field Extra Traffic should be advertised. This indicates that bandwidth can be used by LSPs, with the caveat that any LSPs routed over this link will be preempted if the resources are needed as a result of a failure over the primary link. When a failure occurs on a dedicated 1:1 or shared M:N link, the LSPs routed over the link will automatically be switched to the Extra Traffic link that is protecting it. To support the routing of Secondary LSPs for M:N path protection (as described in Section 2.2.2), new extensions must be added to the Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 12] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 current GMPLS routing extensions. In particular, there must be a mechanism to advertise secondary bandwidth and processing rules must be defined for bandwidth accounting when LSP requests arrive at a node. See [BWAcct] for a proposal addressing these issues. 6. Acknowledgments We would like to thank Kireeti Kompella and Ayan Banerjee for their comments and fruitful discussions. 7. Author's Addresses Jonathan P. Lang John Drake Calient Networks Calient Networks 25 Castilian Drive 5853 Rue Ferrari Goleta, CA 93117 San Jose, CA 95138 email: jplang@calient.net email: jdrake@calient.net Yakov Rekhter Adrian Farrel Juniper Networks Movaz Networks Inc. 1194 N. Mathilda Avenue 7926 Jones Branch Drive Sunnyvale, CA 94089 Suite 615 email: yakov@juniper.net McLean, VA 22102 email: afarrel@movaz.net 7. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [GMPLS] Ashwood-Smith, P., Banerjee, A., Berger, L., et al, "Generalized MPLS - signaling functional description," Internet Draft, draft-ietf-mpls-generalized-mpls- signaling-04.txt, (work in progress). [OLCP] Chiu, A., Strand, J., Tkach, R., ôUnique Features and Requirements for The Optical Layer Control Plane, Internet Draft, draft-chiu--strand-unique-OLCP-01.txt, (work in progress). [LMP-DWDM] Fredette, A., Snyder, E., Shantigram, J., et al, ôLink Management Protocol (LMP) for WDM Transmission Systems,ö Internet Draft, draft-fredette-lmp-wdm-00.txt, (work in progress). [LMP] Lang, J. P., Mitra, K., Drake, J., Kompella, K., et al, ôLink Management Protocol (LMP),ö Internet Draft, draft- ietf-mpls-lmp-02.txt, (work in progress). [RSVP-GEN] Ashwood-Smith, P., Banerjee, A., Berger, L., et al, " Generalized MPLS Signaling - RSVP-TE Extensions," Internet Draft, draft-ietf-mpls-generalized-rsvp-te-03.txt, (work in progress). Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 13] Internet Draft draft-lang-ccamp-recovery-01.txt June 2001 [TUNNEL] Awduche, D., Berger, L., Gan, D-H., Li. T., Srinivasan, V., Swallow, G., ôRSVP-TE: Extensions to RSVP for LSP Tunnels,ö Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel- 08.txt, (work in progress). [MULTI] Kompella, K., Rekhter, Y., ôMulti-area MPLS Traffic Engineering,ö Internet Draft, draft-kompella-mpls- multiarea-te-00.txt, (work in progress). [OSPF-GE] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., et al, ôOSPF Extensions in Support of MPL(ambda)S," Internet Draft, draft-kompella-ospf-gmpls-extensions-01.txt, (work in progress). [ISIS-GE] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., et al, ôIS-IS Extensions in Support of Generalized MPLS,ö Internet Draft, draft-ietf-isis-gmpls-extensions-0.2txt, (work in progress). [BWAcct] Kompella, K., Lang, J.P., Drake, J., ôBandwidth Accouting in Support of Secondary LSPs,ö Internet Draft, (work in progress). Lang, J., Drake, J., Rekhter, Y., Farrel, A. [Page 14]