CCAMP working Group W. Imajuku Internet-Draft NTT Proposed Status: Standards Track 　 T. Otani Expires: April 23, 2007 　 KDDI R&D Labs. 　　 Y. Sone Y.Sameshima NTT October 23 2006 Requirements for Inter-Domain LSP Recovery draft-imajuku-ccamp-inter-domain-recovery-req-01.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 April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Generalized MPLS(GMPLS) suite of protocols h as 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 23, 2007 [Page 1] draft-imajuku-ccamp-inter-domain-recovery-req-01.txt October 2006 Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Conventions used in this document. . . . . . . . . . . . . 4 2.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 4 3. Note to Recovery Schemes . . . . . . . . . . . . . . . . . . . 6 3.1. End-to-End Recovery . . . . . . . . . . . . . . . . . . . 6 3.2. MPLS Fast Re-Route . . . . . . . . . . . . . . . . . . . . 6 3.3. Segment Recovery . . . . . . . . . . . . . . . . . . . . 6 4. Recovery Schemes for inter-domain LSP . . . . . . . . . . . . 7 4.1. Inter-domain End-to-End Recovery . . . . . . . . . . . . 8 4.2. Per-Domain Recovery . . . . . . . . . . . . . . . . . . . 8 4.3. Inter-domain Link Failure Recovery . . . . . . . . . . . . 9 4.4. Domain Border Node Failure Recovery . . . . . . . . . . . 9 4.5. Comments on Described Recovery . . . . . . . . . . . . . 10 5. Problem Statements and Requirements . . . . . . . . . . . . . 10 5.1. Per-domain Recovery . . . . . . . . . . . . . . . . . . . 10 5.2. Inter-domain Link Failure Recovery . . . . . . . . . . . . 11 5.3. Domain Border Node Failure Recovery . . . . . . . . . . . 1 1 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . .. . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative references . . . . . . . . . . . . . . . . . . 12 8.2. Informative references . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502 Japan Imajuku, et al. Expires April 23, 2007 [Page 2] draft-imajuku-ccamp-interdomain-reco very-req-01.txt October 2006 Email: ogaki@kddilabs.jp Shuichi Okamoto KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502 Japan Email: okamoto@jgn2.jp Atsushi Taniguchi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan E-mail: taniguchi.astushi@lab.ntt.co.jp 2. Introduction CCAMP WG has so far proposed two kinds of GMPLS based recovery mechanisms, end-to-end recovery [e2e-recovery] and segment recovery [seg-recovery]. These proposals can provide a promising solution to enhancing the resiliency and the reliability of networks and they represent a key motivation toward deploying GMPLS controlled networks. Recently, activities in many international R&E test-beds require the standardization of inter-domain GMPLS frameworks, and these opportunities for experimentation are expected to provide a promising indication to the deployment of future commercialized inter-domain GMPLS networks as observed in the historical evolution of the Internet. In addition, initiation of the standardization process in the L1-VPN framework [L1VPN-FW] requires the inter-domain GMPLS signaling architecture for a 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 the GMPLS signaling mechanism to simplify the problems mentioned above, although a mixed strategy of routing and signaling is essential. Alternatively, this version of the document extracts the requirements for GMPLS signaling functionality for not only the end-to-end recovery strategy, but also seg ment recovery. Therefore, those who wish to consider routing extensions applicable to an inter-domain framework should refer to other documents such as [RFC4105], [RFC4216], [RFC PCE-Arch], [brpc], and [GMPLS-AS]. Note Imajuku et al. Expires April 23, 2007 [Page 3] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 that there is a comprehensive study on inter-domain TE LSP recovery considering both existing GMPLS routing and signaling [id-recov-anl]. The scope of this document does not include a nested domain 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]. 2.3 Terminology Terminology frequently used in this docume nt conforms to the definitions in [RFC4427], [inter-domain-frwk], [inter-domain-rsvp], and so on. However, terminology concerning MPLS Fast Reroute (MPLS FRR) defined in [RFC4090] is updated to GMPLS terminology for segment recovery in [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: A Label Switching Router at the domain boundary. Specifically, a domain border node is the border of an AS. The node terminates an inter-domain link connected to a peer AS border node. ERO: Explicit Route Object FA: Forwarding Adjacency FA-LSP: Forwarding Adjacency LSP Inter-domain TE LSP: An LSP that is 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 re covery LSP NHOP recovery LSP: Next-Hop recovery LSP. A backup LSP that bypasses Imajuku et al. Expires April 23, 2007 [Page 4] draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006 a single link of the working LSP. NNHOP recovery LSP: Next-Next-Hop recovery Tunnel. A backup LSP that 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 protection LSP. RRO - Record Route Object TE: Traffic Engineering TE-link: Traffic Engineering link Working LSP: See [RFC4427]. A working LSP transports normal user traffic. One main issue in this do cument focuses on the signaling method for inter-domain TE-LSPs. Therefore, the reader should be particularly familiar with the 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. An inter-domain stitched TE LSP is a TE LSP comprising different TE LSP segments within each domain that 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, different LSP segments are signaled as distinct RSVP sessions, which are independent from the RSVP session for the inter-domain LSP. Imajuku et al. Expires April 23, 2007 [Page 5] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 3. Note to Recovery Schemes 3.1. End-to-End Recovery The end-to-end recovery scheme is described in [e2e-recovery]. This scheme achieves end-to-end protection and restoration. This document extends the Protection Object [RFC3471] and defines how to control the 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 nested or stitched inter-domain TE LSP assigns the recovery type of the FA-LSP or LSP segment by using these flags. 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 (pack et) 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 achieves protection and restoration over a portion of the end-to-end TE LSP even for non-PSC switching technologies. In each portion of the segment recovery, the usage of the S/P/N/O bit and LSP flags is the same as that in 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 the 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 the recovery LSPs by using the Secondary ERO (SERO). In addition, the segment recovery scheme further extends a new control b it, i.e., I/R bit, in the Protection Object. Imajuku et al. Expires April 23, 2007 [Page 6] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 The I bit indicates that the desired segment recovery type indicated in the LSP Segment Recovery Flag is already in place for the associated LSP. The R bit indicates that a 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 cases, the branch and merge nodes of the recovery LSPs coincide with the domain border nodes. Here, note that segment recovery does not mean the recovery of an LSP segment. 4. Recovery Schemes for inter-domain TE LSPs This section categorize s the recovery schemes for inter-domain TE LSPs considering failure scenarios. The failure scenarios for inter-domain TE LSPs are categorized as follows. The first one is a node or link failure within a domain. The second one is a failure of a domain boundary link, and the last one is a failure of a domain boundary node. This document considers four recovery schemes. (1) Inter-domain end-to-end recovery End-to-end recovery performed irrespective of the failure scenario. (2) Per-domain recovery Sub-path recovery performed for failure scenarios within a domain except for the failure of a domain border node. (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 "sub-path recovery" is u sed so as not to limit the recovery scheme such as segment recovery. This section explains the recovery schemes based on the figure below. For the purpose of consistency, this figure is taken from [inter-domain-rsvp]. Imajuku et al. Expires April 23, 2007 [Page 7] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 :<----- 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 Inter-domain LSPs can be protected using end-to-end recovery irrespective of the failure scenario. In this recov ery mode, the working and protection LSPs are created based on the results of diverse path route computation. In this example, working and protection LSPs, R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7 and R0-R2-ASBR3-ASBR6-R4-ASBR8- ASBR10-R7, respectively, are created. The diversity may be nodal, SRLG, or AS diverse. The path computation strategy may be a per-domain hop calculation with the subsequent use of a stand-alone Path Computation Elements (PCEs) or per-domain hop calculation [per-domain-calc] with the cooperation of multiple PCEs located in each domain. The important point within the scope of this document is the Link Flags in the Protection Object. The Link Flag values except 0x01 (Extra Traffic) or 0x02 (Unprotected) result 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 a domain as "per-domain recovery." In this example, a working LSP, R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7, is created and recovery LSPs in AS1, AS2, and AS3, R0-R2-ASBR3- ASBR2-ASBR1, ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR7, and ASBR9-ASBR10-R7, respectively, can be created. 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 branch/merge nodes that 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 represents the dynamic identification of the branch and merge nodes on a per-domain basis. Thus, the branch or merge nodes are selected based on the local policy in each domain. On 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 a case, the processing of the SERO in the domain boundary node Imajuku et al. Expires April 23, 2007 [Page 8] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 becomes the issue, if the network operator of the domain has a local policy that conflicts 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 a value except 0x01 (Extra Traffic) or 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 perf ormed 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 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 a 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 the arrival of the PATH message of the inter-domain LSP. The advantage of “Nesting and Stitching” from the signaling aspect is the ease in achieving 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 define s the recovery scheme for the link failure between a pair of domain boundary nodes as "inter-domain link failure recovery." In this example, a working LSP, R0-X1- ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7, is created and recovery LSPs between AS1 and AS2, and between AS2 and AS3, ASBR1-ASBR2-ASBR4 and ASBR7-ASBR8-ASBR10-ASBR9, respectively, can be created. In addition, the creation of a NHOP recovery LSP may be required if there are multiple links between pairs of domain border nodes. Inter-domain link recovery can employ all three signaling schemes as discussed in Section 4.2. However, the advantage of the stitching LSP described 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 domain boundary nodes as "Domain border node recovery." In this example, a working LSP, R0-X1-ASBR1-ASBR4-R3-ASBR7- ASBR9-R6-R7, is crea ted and recovery LSPs between AS1 and AS2, and between AS2 and Imajuku et al. Expires April 23, 2007 [Page 9] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 AS3, X1-ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and R3-ASBR8-ASBR10-R7, respectively, can be created. Inter-domain link recovery can employ all three signaling schemes as discussed in Section 4.2. Likewise, as in the previous section, the advantage of the stitching LSP diminishes in this case. 4.5 Comments on 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 a topological constraint around the pair of border nodes. There is no guarantee that a separate route of the recovery LSPs will be established for the domain border link failure recovery and the domain border node failure recovery LSPs. 5. Pro blem Statements and Requirements 5.1 Problem Statements and Requirements for Per-Domain Recovery Problem statements: The signaling method is basically selected on a domain-to-domain basis following the policy of LSP and its management architecture in each domain. It seems trivial, but a difference in the LSP architecture results in a difference in the functional design and database in the network management system in each domain. Therefore, the inter-domain TE LSP should secure the independency of the 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 the setting scheme of the signaling method is outside the scope of this document. However, there is one consideration in the case that per-domain recovery is performed. As described in Section 4.2, the creation of a recovery LSP in each domain is performed following 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 select 0x10 (1+1 Bi-directional Protection/Dedicated 1+1), some domains may try to create four LSPs (two pairs of LSP segments with 1+1 Bi-directional Protection) against the intension of an operator who tries to create an inter-domain TE LSP. Requirements: The extension of a control bit can be a solution to this problem, and this extension will indicate the selection of one flag out of Segment Recovery Flags and Link Flags. This indication enables successful selection of the proper recovery type for the inter-domain Imajuku et al. Expires April 23, 2007 [Page 10] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 LSP without any constraint in selecting the signaling method in each domain. 5.2 Problem Stateme nts and Requirements for Inter-Domain Link Failure Recovery Problem statements: The probability of link failure becomes trivial when a pair of border nodes is co-located in the same housing space or building as in many cases. In such a 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. In addition, the introduction of a new procedure helps to reduce the amount of required network resources. For example, let us consider the case of network AS1, AS2, and AS3 comprising Lambda Switch Capable (LSC) and the inter-domain links such as link ASBR7-ASBR9 and link ASBR8-ASBR10 as bundled TE links. In such a case, a lambda inter-domain TE LSP can be recovered within each bundled domain border TE link for the scenario of a one-component link failure, if these TE links co ntain shared back-up component links. The introduction of such a recovery technique greatly reduces the complexity of network design issues for network operators. Requirements: For the first problem statement, a possible solution is the addition of a new control bit in the Protection Object which indicates the necessity of the inter-domain link failure recovery similar to the R bit defined in Section [seg-recovery]. For the second problem statement, Sub-Network Connection Protection (SNCP) can be a solution. However, the introduction of the SNCP into GMPLS signaling mechanism provides a more generic solution to achieve SNCP switchover. The GMPLS based solution can achieve equivalent operation to the SNCP even if the domain border nodes have different switching capabilities. 5.3 Problem Statements and Requirements for Domain Border Node Failure Recovery Problem statements: The problem that aris es 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 pertains to the functionality of the I bit which Imajuku et al. Expires April 23, 2007 [Page 11] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 aids in the understanding of the status of whether the recovery LSP is in-place or not at the downstream side of the inter-domain TE LSPs. However, the use of the I bit cannot provide sufficient information to the downstream side of the inter-domain TE LSPs regarding whether or not the recovery LSP for the domain border node failure is in-place. Let us consider the case of working inter-domain TE LSP, R0-R1-R2- ASBR3-ASBR6-R4-ASBR8-ASBR10-R7, and the recovery LSP for a node or link failure within AS1, R0-X1-ASBR2-ASBR3, based on the 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, a possible solution is the same as that described in Section 5.2. For the second problem statement, a possible solution is the addition of a new control bit in the Protection Object which indicates the necessity of the inter-domain link failure recovery similar to the I bit defined in Section [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 the I bit representing the status of the recovery LSPs for the per-domain failure recovery. The above requirements do not require further extension to the GMPLS signaling mechanism su ch as ERO/RRO processing. 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", Imajuku et al. Expires April 23, 2007 [Page 12] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 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. [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 Imajuku et al. Expires April 23, 2007 [Page 13] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 [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. [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-recov-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 Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Imajuku et al. Expires April 23, 2007 [Page 14] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 Japan National Institute of Information and Communications Technology 2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031 Japan E mail: otani@kddilabs.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 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 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 R FC 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 Imajuku et al. Expires April 23, 2007 [Page 15] draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006 "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 23, 2007 [Page 16]