CCAMP working Group W. Imajuku Internet-Draft NTT Expires: October 16, 2006 Y. Sone NTT October 16 2006 Requirements for Inter-Domain LSP Recovery draft-imajuku-ccamp-inter-domain-recovery-req-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 August 12, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Generalized MPLS(GMPLS) suite of protocols has been defined the protection and restoration mechanisms of Label Switched Paths (LSPs) to realize the highly resilient and reliable networks. The objective of this document is to extract additional requirements for the signaling mechanisms in order to extend the applicability of the protection and restoration mechanisms for inter-domain LSPs. Imajuku, et al. Expires April 16, 2007 [Page 1] draft-imajuku-ccamp-inter-domain-recovery-req-00.txt October 2006 Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions used in this document. . . . . . . . . . . . . 5 2.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 6 3. Note to Recovery Schemes . . . . . . . . . . . . . . . . . . . 7 3.1. End-to-End Recovery . . . . . . . . . . . . . . . . . . . 7 3.2. MPLS Fast Re-Route . . . . . . . . . . . . . . . . . . . . 8 3.3. Segment Recovery . . . . . . . . . . . . . . . . . . . . 8 4. Recovery Schemes for inter-domain LSP . . . . . . . . . . . . 9 4.1. Inter-domain End-to-End Recovery . . . . . . . . . . . . 9 4.2. Per-Domain Recovery . . . . . . . . . . . . . . . . . . . 10 4.3. Inter-domain Link Failure Recovery . . . . . . . . . . . . 11 4.4. Domain Border Node Failure Recovery . . . . . . . . . . . 11 5. Problem Statements and Requirements . . . . . . . . . . . . . 12 5.1. Per-domain Recovery . . . . . . . . . . . . . . . . . . . 12 5.2. Inter-domain Link Failure Recovery . . . . . . . . . . . . 12 5.3. Domain Border Node Failure Recovery . . . . . . . . . . . 13 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . .. . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative references . . . . . . . . . . . . . . . . . . 14 8.2. Informative references . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Imajuku et al. Expires April 16, 2007 [Page 2] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 1. Contributors Tomonori Takeda NTT Network Service System Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo, 180-8585 Japan E-mail: takeda.tomonori@lab.ntt.co.jp Eiji Oki NTT Network Service System Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo, 180-8585 Japan E-mail: oki.eiji@lab.ntt.co.jp Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan National Institute of Information and Communications Technology 2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031 Japan Email: otani@kddilabs.jp Yasunori Sameshima NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan National Institute of Information and Communications Technology 2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031 Japan E-mail: yasunori.sameshima@lab.ntt.co.jp Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan Email: ogaki@kddilabs.jp Imajuku et al. Expires April 16, 2007 [Page 3] Shuichi Okamoto KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan National Institute of Information and Communications Technology 2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031 Japan Email: okamoto@kddilabs.jp Imajuku et al. Expires April 16, 2007 [Page 4] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 2. Introduction CCAMP WG has been so far proposed two kinds of GMPLS based recovery mechanisms, i.e. end-to-end recovery [e2e-recovery] and segment recovery [seg-recovery]. These proposals can provide promising solution to enhance the resiliency and the reliability of networks and one of key motivations to deploy the GMPLS controlled networks. The recent activities in many international R&E test-beds requires the standardization of inter-domain GMPLS frameworks, and these opportunities are expected to provide the promising cue to the deployment of future commercialized inter-domain GMPLS networks as seen in the historical evolution of the Internet. In addition, the initiation of the standardization process in L1-VPN framework [L1VPN-FW] requires the inter-domain GMPLS signaling architecture for the special case of multi-domain networks. The objective of this document is to extract additional requirements for the signaling mechanisms in order to extend the applicability of the protection and restoration mechanisms for inter-domain TE Label Switched Paths (LSPs). 2.1 Document Scope In particular, this document focuses on GMPLS signaling mechanism to simplify the problems, although the mixed strategy of routing and signaling is essential. Alternatively, this version of document extracts the requirements for GMPLS signaling functionality not only the end-to-end recovery strategy, but also the segment recovery. Therefore, the readers want to consider routing extension applicable for inter-domain framework should refer other documents such as [RFC4105], [RFC4216], [RFC PCE-Arch], [brpc], and [GMPLS-AS]. And, note that there is a comprehensive study for inter-domain TE LSP recovery considering both existing GMPLS routing and signaling [inter-dom-recovery-anl]. Also, this document does not include nested domain within the scope conforming to [inter-domain-frwk]. 2.2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Imajuku et al. Expires April 16, 2007 [Page 5] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 2.3 Terminology Terminology frequently used in this document conforms to the definition made in [RFC4427], [inter-domain-frwk], [inter-domain-rsvp], and so on. However, terminology of MPLS FRR defined in [RFC4090] is updated to Terminology of GMPLS segment recovery [seg-recovery]. Branch node: The head-end node of a recovery LSP Domain: A domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Domain border node: Label Switching Routers at the domain boundary. Specifically, the domain border node is the border of an AS. The node terminates inter-domain link connected to peer AS border node. ERO: Explicit Route Object FA: Forwarding Adjacency FA-LSP: Forwarding Adjacency LSP Inter-domain TE LSP:@LSP that established across multiple domains. LSP: Label Switched Path. Note that the term LSP and TE LSP will be used interchangeably. LSP segment: Label Switched Path segment stitched to inter-domain LSPs See [LSP-stitch]. Merge node: The tail-end of a recovery LSP NHOP recovery LSP: Next-Hop recovery LSP. A backup LSP, which bypasses a single link of the working LSP. NNHOP recovery LSP: Next-Next-Hop recovery Tunnel. A backup LSP, which bypasses a single node of the working LSP. Recovery LSP: See [RFC4427]. The recovery LSP transports normal user traffic when the working LSP fails. The recovery LSP may transport user traffic even when the working LSP is transporting normal user traffic (e.g., 1+1 protection). In such a scenario, the recovery LSP is sometimes referred to as a protecting LSP. RRO - Record Route Object TE: Traffic Engineering TE-link: Traffic Engineering link Imajuku et al. Expires April 16, 2007 [Page 6] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 Working LSP: See [RFC4427]. The working LSP transports normal user traffic. One of main issue in this document focuses on the signaling method for inter-domain TE-LSP. Therefore, the reader should particularly familiar with terminology defined in [inter-domain-frwk]. Contiguous TE LSP: This is a single end-to-end TE LSP that is setup across multiple domains using RSVP-TE signaling procedures described in [RFC3473]. No additional TE LSPs are required to signal a contiguous TE LSP and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. Nested TE LSP: Nesting one or more TE LSPs into another TE LSP is described in [RFC4206]. This technique can also be used to nest one or more inter-domain TE LSPs into an intra-domain FA-LSP. While similar to stitching in the control plane, in the data plane, nesting allows for one or more inter-domain LSPs to be transported over a single intra-domain FA-LSP using the label stacking construct. Stitched TE LSP: The concept of LSP stitching as well as the required signaling procedures are described in [LSP-STITCH]. This technique can be used to stitch an inter-domain TE LSP to an intra-domain LSP segment. A inter-domain stitched TE LSP is a TE LSP made up of different TE LSP segments within each domain which are "stitched" together in the data plane so that an end-to-end LSP is achieved in the data plane. In the control plane, however, the different LSP segments are signaled as distinct RSVP sessions which are independent from the RSVP session for the inter-domain LSP. 3. Note to Recovery Schemes 3.1. End-to-End Recovery The end-to-end recovery scheme is described in [e2e-recovery]. This scheme realizes end-to-end protection and restoration. This document extends Protection Object [RFC3471] and defines how to control S/P/N/O bit in this object. LSP Flags assign the recovery type such as 1+1/1:1 protection, 1:n protection, Re-routing without Extra-Traffic (pre-planed rerouting), and Full re-routing. Link Flags assign the desired link protection type used for TE-LSP. The inter-domain TE LSP nested or stitched assign the recovery type of the FA-LSP or LSP segment by using these flags. Imajuku et al. Expires April 16, 2007 [Page 7] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 3.2. MPLS Fast Reroute (MPLS FRR) MPLS Fast Reroute (MPLS FRR) provides a form of segment recovery for packet MPLS-TE networks. Two methods of MPLS FRR are defined in [RFC4090]. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point which is shared by multiple LSPs and uses label stacking. Neither approach supports the full set of recovery types supported by the End-to-End recovery. Additionally, the facility backup method is not applicable to most non-PSC (packet) switching technologies. 3.3. Segment Recovery The segment recovery scheme is described in [seg-recovery]. The basic concept of the segment recovery is compatible with the MPLS FRR. This scheme realizes the protection and restoration over a portion of end-to-end TE LSP even for non-PSC switching technologies. In each portion of the segment recovery, the usage of S/P/N/O bit and LSP flags is same with the end-to-end recovery. The segment recovery scheme provides both dynamic and static Assignment of branch and merge nodes to create recovery LSPs. The non-zero value of Segment Recovery Flag in the Protection Object indicates the dynamic assignment of the branch and merge nodes. On the other hand, an upstream node can identify the branch and merge nodes of recovery LSPs by using the Secondary ERO (SERO). Also, the segment recovery scheme further extends the new control bit, i.e. I/R bit in the Protection Object. I bit indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP. R bit indicates that failure to establish the indicated protection should result in a failure of the LSP being protected. Considering the confidentiality of the routing information within domains, segment recovery for inter-domain TE LSPs dynamically assigns branch and merge nodes of the recovery LSPs. In many case, the branch and merge nodes of the recovery LSPs are coincide with the domain border nodes. Here, note that the segment recovery does not means the recovery for LSP segment. Imajuku et al. Expires April 16, 2007 [Page 8] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 4. Recovery Schemes for inter-domain TE LSPs This section categorizes the recovery schemes for inter-domain TE LSPs considering the failure scenarios. The failure scenarios for inter- domain TE LSPs are categorized as follows. The first one is the node or link failure within a domain. The second one is the failure of domain boundary link. And the last one is the failure of domain boundary node. This document considers the four recovery schemes, (1) Inter-domain End-to-End recovery: End-to-end recovery performed irrespective to failure scenarios. (2) Per-Domain Recovery: Sub-path recovery performed for failure scenarios within domain except the failure of domain border node failure scenario. (3) Inter-Domain Link Failure Recovery: Sub-path recovery performed for failure scenarios at domain boundary links. (4) Domain Border Node Failure Recovery: Sub-path recovery performed for failure scenarios at domain boundary nodes. Here, the term of "sub-path recovery" is used so as not to limit the recovery scheme such as the segment recovery. This section explains the those recovery schemes by using the figure as follows. For the purpose of to keep consistency, this figure is copied from [inter-domain-rsvp]. :<----- AS-1 ----->:<------ AS-2 ------->:<--- AS-3 ---->: : : : : CE1-----R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9-----R6 : : | | | | : / | / | / | : | | : : | | +-ASBR2----/ ASBR5 | / | : | | : : | | | : | | / | : | | : : R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2 : : : : : <================ Inter-AS TE LSP ================> : 4.1 Inter-Domain End-to-End Recovery The inter-domain LSPs can be protected by the end-to-end recovery irrespective to failure scenarios. In this recovery mode, the working and protecting LSPs are created based on the results of diverse path route computation. For example, the working and protecting LSPs are created R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7, and R0-R2-ASBR3-ASBR6-R4-ASBR8-ASBR10-R7, respectively. The diversity may be nodal, SRLG, or AS diverse. The path computation strategy may be the per-domain hop calculation with the subsequent Imajuku et al. Expires April 16, 2007 [Page 9] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 use of stand-alone PCES or per-domain hop calculation [per-domain-calc] with the cooperation of multiple PCEs located in each domain. The important note within the scope of this document is the Link Flags in the Protection Object. The Link Flags values except 0x01 (Extra Traffic) or 0x02 (Unprotected) results in the assignment of per-domain recovery in each domain. 4.2 Per-Domain Recovery This document defines the recovery scheme for the node and/or link failure within domain as gper-domain recoveryh. For example, the working LSP is created R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7. The recovery LSPs in AS1, AS2, and AS3 can be created R0-R2-ASBR3- ASBR2-ASBR1, ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR7, and ASBR9-ASBR10-R7, respectively. The per-domain recovery can employ mainly two kinds of techniques corresponding to the signaling methods in each domain. If the domain employs the contiguous signaling method, the domain boundary nodes perform segment recovery. Namely, the domain boundary nodes may act as the branch/merge nodes which terminate the recovery LSPs in each domain. For this case, the Protection Object of the inter-domain LSP contains the non-zero Segment Recovery Flags. The non-zero value of the segment recovery flag means the dynamic identification of the branch and merge nodes per-domain basis. Thus, the branch or merge nodes are selected based on the local policy in each domain. To the contrary, the upstream node of the inter-domain LSPs may assign the recovery type by using the Protection Sub-Object in the SERO. In such case, the processing of the SERO in the domain boundary node becomes the issue to be discussed, if the network operator of the domain has the local policy which conflict with the Segment Recovery Flags in the Protection Sub-Object in the SERO. If the domain employs the Nesting or Stitching LSP method and the Link Type Flag in the Protection Object of the inter-domain LSPs assigns the value except 0x01 (Extra Traffic) nor 0x02 (Unprotected), the domain boundary node may perform end-to-end recovery for the FA-LSP or the LSP segment which accommodates the inter-domain LSP. The selection of the FA-LSP and the LSP segment is performed based on the local policy with the consideration of the Link Type Flag. Although there is a minor issue resulting from the discrepancy of the defined value between the Link Flag and LSP Flag in the selection process of the LSP Flag value of the FA-LSP from the Link Flag value of the inter-domain LSP, it is obvious that Imajuku et al. Expires April 16, 2007 [Page 10] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 each domain is required to select higher reliability class of FA-LSPs to accommodate the inter-domain LSPs. Similarly, the LSP Flags in the Protection Object of the FA-LSP or segment LSP are dynamically set to higher value than the Link Type Flag in the Protection Object of the inter-domain LSP, if the FA-LSP or LSP segment are dynamically created following to the arrival of the PATH message of the inter-domain LSP. The advantage of gNesting and Stitchingh from the signaling aspect is easiness to achieve control confidentiality for the inter-domain TE LSP, since the switching operation of inter-domain TE LSP can be achieved by controlling the FA-LSP or LSP segment. 4.3 Inter-Domain Link Failure Recovery This document defines the recovery scheme for the link failure between the pair of the domain boundary nodes as ginter-domain link failure recoveryh. For example, the working LSP is created R0-X1- ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7. The recovery LSPs between AS1 and AS2, and between AS2 and AS3 can be created ASBR1-ASBR2-ASBR4 and ASBR7-ASBR8-ASBR10-ASBR9, respectively. Also, the creation of NHOP recovery LSP may be required if there are multiple links between pairs of domain border nodes. The inter-domain link recovery can possibly employ all of three signaling schemes as discussed in the section 4.2. However, the advantage of the stitching LSP pointed in the previous section diminishes in this case. 4.4 Domain Border Node Failure Recovery This document defines the recovery scheme for the nodal failure of the domain boundary nodes as gDomain Border Node recoveryh. For example, the working LSP is created R0-X1-ASBR1-ASBR4-R3-ASBR7- ASBR9-R6-R7. The recovery LSPs between AS1 and AS2, and between AS2 and AS3 can be created X1-ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and R3-ASBR8-ASBR10-R7, respectively. The inter-domain link recovery can possibly employ all of three signaling schemes as discussed in the section 4.2. Likewise with the previous section, the advantage of the stitching LSP diminishes in this case. 4.5 Comments on the described recovery The recovery of the Domain Border Link Failure recovery and the Domain Border Node Failure recovery may be degenerated as the result of topological constraint around the pair of border nodes. There is no guarantee to establish separate route of the recovery LSPs for the Domain Border Link Failure recovery and the Domain Border Node failure recovery LSPs. Imajuku et al. Expires April 16, 2007 [Page 11] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 5. Problem Statements and Requirements 5.1 Problem Statements and Requirements for Per-Domain Recovery Problem statements: The signaling method is basically selected in domain-to-domain basis following to the policy of LSP and its management architecture in each domain. It seems trivial, but the difference of the LSP architecture results in the difference of functional design and database in network management system in each domain. Therefore, the inter-domain TE LSP should secure the independency of signaling method. The selection of contiguous, nesting, and stitching is determined by the domain border node at the upstream side of each domain. The discussion regarding to the setting scheme of the signaling method is out of scope in this document. However, one consideration should be made in the case that the per-domain recovery is performed. As described in section 4.2, the creation of recovery LSP in each domain is performed following to the Segment Recovery Flag or Link Flag in the Protection Object of the inter-domain TE LSPs. Here, one problem arises when the inter-domain TE LSP traverses domains employing the contiguous and the nesting/stitching signaling methods. For example, if both Segment Recovery Flags and Link Flags are Selected 0x10 (1+1 Bi-directional Protection/Dedicated 1+1), some domain may try to create four LSP (two pair of LSP segments with 1+1 Bi-directional Protection) against the intension of the operator who tries to create the inter-domain TE LSP. Requirements: The extension of control bit can be one of solution for the problem, and which indicates selection to one Flags out of Segment Recovery Flags and Link Flags. This indication enables successful selection of proper recovery type for the inter-domain LSP without any constraint in selecting signaling method in each domain. 5.2 Problem Statements and Requirements for Inter-Domain Link Failure Recovery Problem statements: The probability of link failure becomes trivial, when a pair of Border nodes are co-located in the same housing space or building as in many cases. In such case, it is useful to secure arbitrariness in establishing the recovery LSPs for the inter- domain links, because it will help to avoid excess consumption of network resources within both domains. Also, the introduction of new procedure helps to reduce network resources. For example, consider the case of network AS1, AS2, and AS3 comprises Lambda Switch Capable (LSC) and the inter-domain Imajuku et al. Expires April 16, 2007 [Page 12] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 links such as link ASBR7-ASBR9 and link ASBR8-ASBR10 are bundled TE links. In such case, a lambda inter-domain TE LSP can be recovered within each bundled domain border TE link for the scenario of one component link failure, if these TE links contains shared back-up component links. The introduction of such recovery technique greatly reduces the complexity of network design issue for network operators. Requirements: For the first problem statement, one of possible solution is the addition of new control bit in the Protection Object which indicates the necessity of the inter-domain link failure recovery similar to R bit defined section in [seg-recovery]. For the second problem statement, Sub-Network Connection Protection (SNCP) can be one of solution. However, the introduction of the SNCP into GMPLS signaling mechanism provides more generic solution to realize SNCP switchover. The GMPLS based solution can achieve equivalent operation to the SNCP even if the domain border nodes have different switching capability. 5.3 Problem Statements and Requirements for Domain Border Node Failure Recovery Problem statements: The problem arises in the domain border node failure recovery is similar to the first problem statement of the inter-domain link failure recovery. It is useful to secure arbitrariness in establishing the recovery LSPs for the domain border node failure recovery, because it will help to avoid excess consumption of network resources within both domains. The second problem is the functionality of I bit which helps to understand the status whether the recovery LSP is in-placed or not at the downstream side of the inter-domain TE LSPs. However, the use of I bit can not provide enough information to the downstream side of the inter-domain TE LSPs whether the recovery LSP for the domain border node failure is in-placed or not. Consider the case of a working inter-domain TE LSP is created R0-R1-R2-ASBR3-ASBR6-R4-ASBR8-ASBR10-R7, and the recovery LSP for the node or link failure within AS-1 is created R0-X1-ASBR2-ASBR3 based on segment recovery procedure. The in-place bit is set for the working inter-domain TE LSP. This may result in no action, nevertheless R1 or R2 is required to create a NNHOP recovery LSP for ASBR3 and/or ASBR4 failure scenarios. Requirements: For the first problem statement, possible solution is the same with described in section 5.2. Imajuku et al. Expires April 16, 2007 [Page 13] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 For the second problem statement, one of possible solution is the addition of new control bit in the Protection Object which indicates the necessity of the inter-domain link failure recovery similar to I bit defined section in [seg-recovery]. The I bit to understand the status of the recovery LSPs for the border node failure is necessary in order to discriminate the status of I bit representibg the status of the recovery LSPs for the per-domain failure recovery. The above requirements does not requires further extension to the GMPLS signaling mechanism such as ERO/RRO processing, and so on. 6. Security considerations TBD 7. IANA considerations This document requires no further IANA considerations. 8. References 8.1 Normative References [e2e-recovery] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.), "RSVP-TE Extensions in support of End-to- End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in progress. [seg-recovery] Berger, L., Bryskin, I., Papadimitriou, D., and Farrel, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. [L1VPN-FW] Takeda, T., Editor "Framework and Requirements for Layer 1 Virtual Private Networks", draft- ietf-l1vpn-framework, work in progress. [inter-domain-fw] Farrel, A., et al., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp- inter-domain-framework, work in progress. [inter-domain-rsvp] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS Traffic Engineering - RSVP extensions", draft- ietf-ccamp-inter-domain-rsvp-te, work in progress. Imajuku et al. Expires April 16, 2007 [Page 14] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi- Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC3471] Berger, L., et al, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [per-domain-calc] Vasseur, J. P., Ayyanger, A., Zhang, R., "A Per- domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 3471, January 2003. 8.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [LSP-stitch] Ayyangar, A., and Vasseur, JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp- stitching, work in progress. [RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter- Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005 [PCE-Arch] A. Farrel, JP. Vasseur and J. Ash, "Path Computation Element (PCE) Architecture", draft- ietf-pce-architecture, work in progress. Imajuku et al. Expires April 16, 2007 [Page 15] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 [brpc] Vasseur, JP., Zhang, R., and Bitar, N., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path", draft- vasseur-ccamp-brpc, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. [id-recovery-anl] Takeda, T., Ikejiri, Y., Farrel, A., and Vasseur, J. P., "Analysis of Inter-domain Label Switched Path (LSP) Recovery", draft-takeda-ccamp-inter- domain-recovery-analysis, work in progress. 10. Acknowledgements The authors would like to thank Dr. Tatsuzo Koga, representative of NICT Tsukuba RC for the support of this study. 11. Authors' Addresses Wataru Imajuku NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan Phone: +81 46 859 4315 Email: imajuku.wataru@lab.ntt.co. jp Yoshiaki Sone NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan Phone: +81 46 859 2456 Email: sone.yoshiaki@lab.ntt.co.jp 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. Imajuku et al. Expires April 16, 2007 [Page 16] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 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. Imajuku et al. Expires April 16, 2007 [Page 17]