Network Working Group Y. Lee Internet-Draft J. Zhu Expires: December 1, 2006 Huawei May 30, 2006 Framework for the Policy-Based Recovery Mechanism in GMPLS Network draft-lee-ccamp-pce-policy-recovery-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a framework for policy-based protection/ restoration mechanism in GMPLS network. This document provides the definition for recovery policy, architecture framework and the protocol requirements to be able to support policy-based recovery mechanism. Lee & Zhu Expires December 1, 2006 [Page 1] Internet-Draft Policy-based Recovery in GMPLS May 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recovery Policy Definition . . . . . . . . . . . . . . . . . . 6 4. Recovery Policy Architecture . . . . . . . . . . . . . . . . . 8 4.1. Recovery Policy Architecture in the context of the PCE . . 8 4.2. Recovery Policy Architecture with a Direct Interface with the Signaling Engine . . . . . . . . . . . . . . . . 10 5. Communication Protocol Requirements . . . . . . . . . . . . . 13 6. Recovery Policy Object/TLV Definition . . . . . . . . . . . . 14 7. Areas for Standardization . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Lee & Zhu Expires December 1, 2006 [Page 2] Internet-Draft Policy-based Recovery in GMPLS May 2006 1. Terminology The terminology explained herein complies with [RFC 4427], [RFC 4397], [PCE ARCH] and [RFC 2748]. A Switching layer (a Network Layer, a Layer): A set of data links with interfaces that have the same switching and data encoding types and switching bandwidth granularity. Examples of switching layers are 2.5G/10G wavelength, SDH VC12, SDH VC4, ATM VP/VC, Ethernet, IP, etc. Integrated Mode: Recovery process that is performed integrating multiple layers of the network. PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PDP: Policy Decision Point: A policy server that contains policy related information. PEP: Policy Enforcement Point: A policy client that enforces policy for its application. Protected Path: A path subject to protection against faults. Protection: A class of service recovery that does not require any provisioning signaling for the alternative LSP after the failure indication. Protection Path: A path used for protecting a protected path in case of failures. Recovery: A generic term that encompasses both the service protection and restoration. R-PDP: Recovery Policy Decision Point: A policy server that is responsible for making decisions on recovery policy and directives and communicating them to the client for enforcement. R-PEP: Recovery Policy Enforcement Point: A policy client that is responsible for enforcing recovery policy for its application based on the R-PDP information. Restoration: A class of service recovery that requires some Lee & Zhu Expires December 1, 2006 [Page 3] Internet-Draft Policy-based Recovery in GMPLS May 2006 provisioning of the signaling for the alternative path after the failure indication. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. Vertical Integration: A set of collaborative mechanisms within a single node driving multiple (at least two) network layers, and the adaptation between those layers. Lee & Zhu Expires December 1, 2006 [Page 4] Internet-Draft Policy-based Recovery in GMPLS May 2006 2. Motivation Recovery mechanism in telecommunication networks has been simplistic as the scope of recovery has been segmented into a specific layer or a particular switching capability. Typically different organizations are responsible for the protection/restoration of the specific layer and/or the switching capability. As vertical and horizontal integration is promised in the emerging GMPLS network, it is evident that the complexity of recovery mechanism has increased. The complexity of the recovery mechanism in the GMPLS integrated network has many dimensions that include technical complexity as well as organizational complexity. This complexity arises partly due to diversity of views and practices inherent to the individual organizations/networks that comprise of GMPLS network integration [OKI], [MLN-RQMT]. Therefore, it is important that operators of the GMPLS networks should be given the capability to choose recovery policies that best fit to the practices and philosophies of the operators. To accommodate this flexibility and need, it is necessary to define recovery policy model. While implementation and enforcement of policy is largely a local matter, it is important to provide operators with the capability to choose preferred recovery policy for their recovery operation. This document provides a set of recovery policies. This document also provides a high level framework for recovery policy architecture and the protocol requirements. 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]. Lee & Zhu Expires December 1, 2006 [Page 5] Internet-Draft Policy-based Recovery in GMPLS May 2006 3. Recovery Policy Definition This section provides policy definition for recovery. In order to discuss recovery policy constraints, it is essential to understand the scope of specific protection and restoration mechanism currently defined by the GMPLS CCAMP Working Group. Based on the discussions in RFC 4426, 4427, 3471 and [RECOVERY], there are two types of protection/restoration have been defined: (i) Span (Link) Protection and (ii) End-to-End (Path) Protection and Restoration. Under Span (Link) Protection, the following protection types have been defined: - Unprotected (0:1) - (Full) Re-routing - Re-routing without Extra Traffic - Unidirectional 1+1 dedicated protection - Bi-directional 1+1 dedicated protection - Dedicated 1:1 protection with extra traffic - Shared M:N protection Under End-to-End (Path) protection and restoration, the following mechanisms have been defined: - Unidirectional 1+1 Protection - Bi-directional 1+1 Protection - Dedicated 1:1 Protection - Unprotected - Extra Traffic Given the aforementioned Protection/Restoration schemes, there are numbers of criteria in which operator's recovery policy can be defined. The recovery policy constraints specified below can be applied per protection type or globally applied to all protection types. The list specified below is not meant to be extensive or complete. Some of these policies are mono-layer oriented while others are multi-layer oriented. As more recovery related policies are identified, the list will be expanded. - Computation of the Protection Path/Link: (i) the protection path Lee & Zhu Expires December 1, 2006 [Page 6] Internet-Draft Policy-based Recovery in GMPLS May 2006 can be computed before the failure (pre-computed) or (ii) the protection path is computed after the failure (post-computed). - Selection of the Protection Path/Link: (i) the selection of the protection path is pre-selected before the failure (pre-selected) or (ii) the selection of the protection path is selected after the failure (post-selected). - Signaling of the Protection Path/Link: (i) the protection path setup is signaled before the failure (pre-signaled) or (ii) the protection path setup is signaled after the failure (post-signaled). - Allocation of Bandwidth on the Protection Path/Link: (i) pre- allocated (the protection bandwidth is pre-allocated and therefore reserved prior to the failure of the protected path; or (ii) post- allocated (the protection bandwidth is allocated after the failure of the protected path). - Composition of the Protection Path/Link: (i) only single-layer path/link is allowed; or (ii) multi-layer path/link is allowed. - Protection Reversion: (i) allowed (the switching of the user traffic from the protecting to the protected path after recovery is allowed); or (ii) disallowed (the switching of the user traffic from the protection to the protected path after recovery is not allowed). We can easily see that there is a place for policy-based recovery mechanism that would allow operators to choose appropriate policies depending on the operator's need and integration directives. It is to be noted that these policy-based capability provides flexibility to the operators and facilitates operator's horizontal and vertical integration effort. Given the complexities and varieties of the service protection and the network conditions, the operators should be given an ability to flexibly adapt and enforce their preferences. Lee & Zhu Expires December 1, 2006 [Page 7] Internet-Draft Policy-based Recovery in GMPLS May 2006 4. Recovery Policy Architecture This section provides recovery policy architecture and its key components. As seen in the previous section, some of the recovery policies defined in the previous section are closely related to the path computation element (PCE). Recovery policy architecture, therefore, can be built on top of the existing PCE architecture as defined in [PCE ARCH]. On the other hand, it should be also possible to build recovery policy architecture that has a direct interface with the Signaling Engine. This approach is based on a distributed philosophy. Presented in this section, therefore, are the two base architecture: (i) Recovery Policy Architecture in the context of the PCE (ii) Recovery Policy Architecture with a direct interface with he Signaling Engine. 4.1. Recovery Policy Architecture in the context of the PCE Figure 1 depicts recovery policy architecture in the context of the PCE architecture. +---------+ Routing Protocol | TED |<---------------------------> +---------+ | | | \/ +------------+ +------------+ PCE-PCE Protocol | Recovery |-->| PCE |<-------------------------> | PDP | +------------+ +------------+ /\ | PCE-PCC Protocol | \/ Service Request +------------+ Signaling Protocol ---------------->| Signaling |<-------------------------> | Engine | +------------+ Figure 1: Recovery Policy Architecture in the Context of the PCE. Lee & Zhu Expires December 1, 2006 [Page 8] Internet-Draft Policy-based Recovery in GMPLS May 2006 Figure 1 depicts that recovery policy decision is conveyed to the PCE by which enforcement of the recovery policy is to be performed. As recovery and path computation are closed related, the recovery policy can be viewed as an additional component to the PCE with this architecture. The invocation of the recovery policy is typically independent of the service request or signaling flow. When operator's recovery policy is communicated to the Recovery Policy Decision Point (R-PDP), the R-PDP, then, communicates the recovery policy to the PCE. There are many ways for the R-PDP to communicate the recovery policy to the PCE. The choice of the protocol between the R-PDP and the PCE is not the focus of this draft. Whether the R-PDP is local to the PCE or external is also beyond the scope of this draft. With respect to the R-PDP, the PCE depicted in Figure 1 serves as the Policy Enforcement Point (PEP) as defined in [RFC 2748] and [Bryskin]. The responsibility of the PCE is to disseminate the recovery policy information to the nodes that need to implement recovery policy during the path establishment stage. There may be several options for the PCE to disseminate the recovery policy information to the nodes during the path etablishment stage. One obvious way is through the Signaling Protocol. This requires the PCE to request to the Signaling Engine to include the recovery policy Object/TLV during path establishment. This particular method will be discussed in more detail in section 4.2. With the PCE architecture where the PCE is an external entity from the LSR, the PCE could establish a direct interface to each node under its domain control and disseminate the recovery policy information via the PCE-PCC protocol. The PCE is also responsible for enforcing the recovery policy in its path computation process. It is to be noted that some of the recovery policy may be enforced at the PCE level while others may be enforced at the Signaling Engine. For instance, if recovery policy for bandwidth allocation were 'allocation before failure' on the protection path, then this policy should be applied in the process of reservation. The enforcement of this policy would be expected at the Signaling Engine. On the other hand, recovery policy related to computation (for instance, whether the protection path is computed before the failure or not) would be enforced by the PCE as such function is an integral part of the PCE. Important aspect is that both the PCE and the Signaling Engine share the same policy and coordinate each other in the enforcement of the recovery policy. While the recovery policy information is to be disseminated from the PCE to the Signaling Engine with this architecture, the Signaling Engine should communicate the level of Lee & Zhu Expires December 1, 2006 [Page 9] Internet-Draft Policy-based Recovery in GMPLS May 2006 protection associated with a service request to the PCE. When the Signaling Engine requests path computation to the PCE, the recovery level (protection/restoration) should be communicated to the PCE so that the PCE would be able to enforce the recovery policy associated with the recovery level. For example, let's suppose that the Signaling Engine requests path computation for 1:1 protection for a given source-destination pair. The PCE inspects if there are any policy constraints for 1:1 protection. Let say the recovery policies for the protection path are: pre-computed, pre-signaled, pre-selected, pre-allocated, inter- layer path allowed, protection reversion allowed. Then the path computation would proceed subject to these policy constraints where possible. In order for the policy realized across the network domain, the recovery policy information should be communicated between the PCE and the Signaling Engine via the PCE-PCC protocol [PCEP], and/or between the PCEs. Proper Object/TLV should be defined in both PCE- PCC Protocol and/or the PCE-PCE Protocol to achieve policy realization and dissemination across the network domain. 4.2. Recovery Policy Architecture with a Direct Interface with the Signaling Engine Figure 2 shows recovery policy architecture that has a direct communication interface with the Signaling Engine. +---------+ Routing Protocol | TED |<-------------------------> +---------+ | | | \/ +------------+ +------------+ PCE-PCE Protocol | Recovery | | PCE |<-----------------------> | PDP | +------------+ +------------+ /\ |______ | PCE-PCC Protocol | | \/ \/ Service Request +------------+ Signaling Protocol ---------------->| Signaling |<-----------------------> | Engine | +------------+ Lee & Zhu Expires December 1, 2006 [Page 10] Internet-Draft Policy-based Recovery in GMPLS May 2006 Figure 2: Recovery Policy Architecture with a direct communication interface with the Signaling Engine. This architectural option does not depend on the PCE architecture as heavily as the previous option. While the PCE component is still needed in order to enforce recovery policy, the role of the PCE is secondary as compared to the previous architecture option. The Recovery-Policy Decision Point (R-PDP) conveys the recovery policy information directly to the Signaling Engine. The Signaling Engine is the main policy enforcement point (PEP) with this model. The Signaling Engine is responsible for the dissemination of the recovery policy information to the PCE as well as to adjacent nodes. Upon a service request, the Signaling Engine would request path computation to the PCE via the PCE-PCC protocol. In doing so, the recovery policy information should be conveyed from the Signaling Engine to the PCE as part of the request message so that the PCE would apply relevant recovery policy in path computation. As the recovery policy information resides at the Signaling Engine, the dissemination of the recovery policy is to be performed by the Signaling Engine to adjacent nodes associated with the path during the path establishment stage. The Signaling Engine at the headend node, upon a service request, would request path computation to the PCE. The PCE would then apply the pertinent recovery policy associated with the path request and proceed with the path computation. The PCE then would send the reply message back to the Signaling Engine with the result. As the Signaling Engine proceed with the signaling to the nodes along the path, the recovery policy information is to be sent to downstream nodes. The recovery policy information is then stored in the Signaling Engine in each and every downstream node on the both the protection and protected paths. The recovery policy information can be defined as an object/TLV of the RSVP-TE signaling. Compared to the previous architecture, the role of the Signaling Engine is more significant. The dissemination of the recovery policy information is based on distributed and as-needed basis through the Signaling Protocol. When a path is set up, the recovery policy information should be communicated to all the nodes associated with the path such that recovery policy would be enforced if necessary at each node along the path. To illustrate, let's consider the following topology. Lee & Zhu Expires December 1, 2006 [Page 11] Internet-Draft Policy-based Recovery in GMPLS May 2006 A------B------C-------D-------E \ / \ / \ / F-------G Figure 3: An Example topology. Let say that the path (A-B-C-D-E) is the protected path whereas the path (B-F-G-D) is the protection path for the segment (B-C-D) of the path (A-B-C-D-E). Assume that the operator wants to enforce the following recovery policy: pre-computed protection path, pre-selected protection path, pre-signaled protection path, pre-allocated bandwidth, multi-layer protection allowed, reversion not allowed. As the Path message is signaled to downstream nodes along the path (A-B- C-D-E), the recovery policy information is included as an object/TLV in the PATH message so that each node is updated with the recovery policy sent by the headend node A. As the RESV message is sent back from node E, node B would initiate the path set up for the protection path enforcing the recovery policy it previously received. All the relevant recovery policy would be applied where possible by node B. According to the recovery policy, node B would request computation and selection of the protection path to the PCE. Notice that since the policy allows multi-layer links for its protection path, node B should communicate this policy to the PCE so that the PCE would apply this particular policy in its path compuation process. Upon the receipt of the reply message sent from the PCE, node B would then proceed the signaling of the path to the adjacent node F while allocating bandwidth for the path according to the policy. Assume that a link failure takes place on link (C-D). Based on the protection scheme, traffic on the protected path would be rerouted to the protection path (A-B-F-G-D-E). After the failure is fixed, based on the recovery policy, traffic will not be reverted back to the protected path. This example illustrates why the recovery policy object/TLV should be disseminated to the nodes that are part of the recovery. It also shows how the recovery policy information is used in the nodes along the protection path. Lee & Zhu Expires December 1, 2006 [Page 12] Internet-Draft Policy-based Recovery in GMPLS May 2006 5. Communication Protocol Requirements This section discusses communication protocol requirements to support the recovery policy architecture presented in the previous section. There are four key communication interfaces whereby communication protocol support is required to support recovery policy architecture defined in the previous section. - Communication between the Recovery Policy Decision Point (R-PDP) and the Signaling Engine - Communication between the Recovery Policy Decision Point (R-PDP) and the PCE - Communication between the PCE and the Signaling Engine - Communication between the Signaling Engines (i.e., between nodes) Communications between the R-PDP and the Signaling Engine and between the R-PDP and the PCE can be the Common Open Policy Service (COPS) protocol [RFC 2748], although not limited to that. Communication between the PCE and the Signaling Engine can be done via the Path Computation Element communication Protocol (PCEP) which is described in [PCEP]. The notification message is intended to notify useful information between the PCE and the Path Computation Client (PCC) according to [PCEP]. Recovery related policy information should to be defined as an Object/TLV compliant to the PCEP message format. RSVP-TE Object/TLV should be defined to be able to disseminate recovery policy information to other nodes along the path during the path establishment stage. When recovery policy information is reached to other nodes, this would invoke an update to the existing policy if any. The recovery policy information would be also used to enforce any local decision associated with protection/restoration. Lee & Zhu Expires December 1, 2006 [Page 13] Internet-Draft Policy-based Recovery in GMPLS May 2006 6. Recovery Policy Object/TLV Definition This section provides the definition for the Recovery Policy (RP) Object/TLV. The format of the RP Object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|C|S|G|B|L|R| Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|C|S|G|B|L|R| Reserved | Path Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Protected (P): 1 bit When set to 1, it indicates that the Path/Link is a protected path/ link. When set to 0 (default), this bit indicates that the Path/Link is a protection path/link. - Computation (C): 1 bit When set to 1, this bit indicates that the protection path/link is computed after failure. When set to 0 (default), this bit indicates that the protection path/link is computed before failure. - Selection (S): 1 bit When set to 1, this bit indicates that the protection path/link is selected after failure. When set to 0 (default), this bit indicates that protection path/link is selected before failure. - Signaling (G): 1 bit When set to 1, this bit indicates that the protection path/link setup is signaled after failure. When set to 0 (default), this bit indicates that protection path/link setup is signaled before failure. - Bandwidth (B): 1 bit When set to 1, this bit indicates that the protection bandwidth is allocated after failure of the protected path/link. When set to 0, this bit indicates that the protection bandwidth allocation is pre- allocated prior to failure of the protected path/link. - Layer (L): 1 bit Lee & Zhu Expires December 1, 2006 [Page 14] Internet-Draft Policy-based Recovery in GMPLS May 2006 When set to 1, this bit indicates that multi-layer path/link is allowed for the path/link. When set to 0 (default), this indicates that multi-layer path/link is not allowed for the path/link. - Reversion (R): 1 bit When set to 1, this bit indicates that the switching of the user traffic from the protection to the protected path/link after recovery is allowed. When set to 0 (default), this indicates that protection reversion is not allowed. - Reserved: 19 bits - Link Flags: 6 bits This indicates the desired link protection type (per [RFC 3471]). Currently, the following link protection types have been defined in [RFC 3471]: Enhanced, Dedicated 1+1, Dedicated 1:1, Shared, Unprotected, Extra Traffic. - Path Flag: 6 bits This indicates the desired path recovery type. Currently, the following path recovery types have been defined in [RECOVERY]: Unprotected, Re-routing, Re-routing without extra traffic, 1:N Protection with Extra Traffic, 1+1 Unidirectional Protection, 1+1 Bi- directional Protection. The format defined above would allow recovery policy constraints for both the protection path/link and the protected path/link by the P bit. It allows recovery policy constraints to be defined per recovery type and is expandable to accommodate variety of recovery types and their recovery policies. Lee & Zhu Expires December 1, 2006 [Page 15] Internet-Draft Policy-based Recovery in GMPLS May 2006 7. Areas for Standardization The following areas require standardization in order to support policy recovery mechanism discussed in this draft. - Definition of the recovery policy and the MIB - The Recovery Policy Object/TLV structure - PCEP Protocol modifications to adopt the Recovery Policy Object/TLV - RSVP-TE Extension modifications to adopt the Recovery Policy Object/TLV Lee & Zhu Expires December 1, 2006 [Page 16] Internet-Draft Policy-based Recovery in GMPLS May 2006 8. Security Considerations The current version of this document does not introduce any new security considerations as it only lists a set of requirements. In the future versions, new security requirements may be added. Lee & Zhu Expires December 1, 2006 [Page 17] Internet-Draft Policy-based Recovery in GMPLS May 2006 9. IANA Considerations There are no IANA actions requested in this specification. Lee & Zhu Expires December 1, 2006 [Page 18] Internet-Draft Policy-based Recovery in GMPLS May 2006 10. References 10.1. Normative References [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006. [RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. 10.2. Informative References [BRYSKIN] Bryskin, I., Papadimitriou, D., and L. Berger, "Policy- enabled Path Computation Communication Requirements, draft-bryskin-pce-policy-enabled-path-comp-00.txt, work in progress", October 2005. [MLN-RQMT] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- region and multi-layer networks (MRN/MLN), draft-ietf-ccamp-gmpls-mln-reqs-00.txt, work in progress", January 2006. [OKI] Oki, E., Ed., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering, draft-ietf-pce-inter-layer-frwk-00.txt, work in progress", April 2006. Lee & Zhu Expires December 1, 2006 [Page 19] Internet-Draft Policy-based Recovery in GMPLS May 2006 [PCE ARCH] Farrel, A., Vasseur, A., and J. Ash, "A Path Computation Element (PCE) Based Architecture, draft-ietf-pce-architecture-05.txt, work in progress", February 2006. [PCEP] Vasseur, J., Ed., "Path Computation Element (PCE) communication Protocol (PCEP) Version 1, draft-ietf-pce-pcep-01.txt, work in progress", February 2006. [RECOVERY] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)- based recovery, draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt", April 2005. Lee & Zhu Expires December 1, 2006 [Page 20] Internet-Draft Policy-based Recovery in GMPLS May 2006 Authors' Addresses Young Lee Huawei Technologies (USA) 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 0309 Fax: +1 469 229 5397 Email: ylee@huawei.com James Zhu Huawei Technologies (USA) 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 0309 Fax: +1 469 229 5397 Email: zhujiangyun@huawei.com Lee & Zhu Expires December 1, 2006 [Page 21] Internet-Draft Policy-based Recovery in GMPLS May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee & Zhu Expires December 1, 2006 [Page 22]