draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 CCAMP Working Group Kenji Kumaki KDDI Corporation Zafar Ali Cisco Systems Tomohiro Otani KDDI R&D Laboratories, Inc. George Swallow Mallik Tatipamula Cisco Systems Internet Draft Category: BCP Expires: January 2006 July 2005 Operational, Deployment and Interworking Considerations for GMPLS draft-kumaki-ccamp-mpls-gmpls-interworking-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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. K. Kumaki, et al. Page 1 [Page 1] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 Abstract In order to deploy GMPLS technology in the existing IP/MPLS networks, various operation, deployment and interworking aspect of MPLS/GMPLS needs to be addressed. From the deployment perspective, GMPLS architecture document lists [RFC3945] three different scenarios in which GMPLS technology can be deployed: overlay, augmented and integrated. Reference [GMPLS-mig] addresses the problem of migration from MPLS to GMPLS networks using the integrated model. This draft addresses the same problem space for augmented model and illustrates the applicability of augmented model in deploying GMPLS technology in existing IP/MPLS networks. Another very important aspect of MPLS/GMPLS interworking is ability to effectively use GMPLS services in IP/MPLS networks. This includes ability to specify GMPLS LSPs in signaling requests based on the type of the setup desired, as well as considerations for the operation aspects of using GMPLS LSPs. In this draft, we highlight some deployment and MPLS/GMPLS interworking requirements and propose solutions to address them. We also highlight some operation aspects and the possible solution and provide applicability statement for the available options. 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]. Routing Area ID Summary (This section to be removed before publication.) SUMMARY This document addresses some MPLS/ GMPLS deployment, operational and interworking aspects. WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? K. Kumaki, et al. Page 2 [Page 2] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 This work fits in the context of MPLS/GMPLS deployment, operational and interworking. WHY IS IT TARGETED AT THIS WG? This document is targeted at ccamp as it addresses some MPLS/GMPLS deployment, operational and interworking aspects. RELATED REFERENCES Please refer to the reference section. Table of Contents 1. Introduction..................................................4 2. Terminology...................................................5 3. MPLS/GMPLS Deployment,Operational and interworking requirements5 3.1 Software Upgrade Requirement.................................5 3.2 Use of GMPLS network resources in IP/MPLS networks...........6 3.3 Interworking of MPLS and GMPLS protection....................6 3.4 Separation of IP/MPLS domain and GMPLS domain................6 3.5 Failure recovery.............................................6 4. Augmented model...............................................6 4.1 Routing in Augmented Model...................................7 4.2 Failure Recovery in Augmented Model..........................7 4.3 Management in Augmented model................................8 4.4 GMPLS Deployment Considerations..............................8 4.5 Applicability of real/virtual FA-LSP.........................8 4.6 Applicability of FA Utilization..............................9 4.7 Bundling FA-LSP..............................................9 5. MPLS/GMPLS Interworking aspects...............................9 5.1 Static vs. signaling triggered dynamic FA-LSPs...............9 5.2 MPLS/GMPLS LSP Resource Affinity Mapping....................10 5.3 MPLS/GMPLS LSP Priority Mapping.............................10 5.4 Signaling Protected MPLS LSPs...............................11 6. Operational Considerations...................................12 6.1 Applicability of the Priority Management Options............12 6.2 Applicability of the Signaling Triggered Dynamic FA-LSP.....13 7. Backward Compatibility Note..................................13 8. Security Considerations......................................13 9. Intellectual Property Considerations.........................13 10.Acknowledgement..............................................14 11.Reference....................................................14 11.1 Normative Reference........................................14 11.2 Informative Reference......................................14 12.Author's Addresses...........................................15 13.Full Copyright Statement.....................................16 K. Kumaki, et al. Page 3 [Page 3] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 1. Introduction Introduction of GMPLS technology in existing IP/MPLS networks and migration of IP/MPLS services to GMPLS core poses some new requirements that do not exist while using point to point physical links in the core network. One of the biggest challenges in today's network is "how to deploy GMPLS technology" in a manner least impact on the existing IP/MPLS networks. It is neither feasible nor desired to upgrade all existing nodes to GMPLS technology. In fact, it is required to minimize the impact of migration to GMPLS on the existing IP/MPLS network. It is also desired to respect the administrative boundaries between IP/MPLS and Optical domains. There are several architectural alternatives including overlay, integrated and augmented models proposed in GMPLS architecture document [RFC3945]. The key difference among these models is how much and what kind of network information can be shared between packet and Optical domains. Peer model is suitable, where optical transport and Internet/Intranet Service networks are operated by a single entity. Currently, many service providers have traditionally built their networks, where Optical transport and IP/MPLS service networks belong to different operation, management, ownership. Most important thing is that service providers wants to operate and manage their networks independently, and deploy them without changing existing IP/MPLS network topologies, protocols and scalability. Overlay model is suitable for such scenario, however does not offer the benefits of peer model approach for efficient resource utilization, optimal routing and protection and restoration between IP/MPLS and Optical networks. Augmented model is suitable in this scenario, where Optical transport and IP/MPLS service networks administrated by different entities and would like to maintain a separation between IP/MPLS and Optical layers, at the same time, get the benefits of integrated model approach. Reference [GMPLS-mig] addresses the problem of migration from MPLS to GMPLS networks using the integrated model. This draft addresses the GMPLS deployment considerations using augmented model and illustrates how it can be used in existing IP, MPLS and non-IP/MPLS networks. In this regard, there are three different considerations taken into account while comparing these approaches. They are: Deployment considerations, routing aspects, and failure recovery considerations. MPLS/GMPLS interworking is also an important aspect that needs to be considered in deploying GMPLS technology in existing IP/MPLS networks. MPLS/GMPLS interworking function refers to methods deployed for mapping between MPLS LSPs and GMPLS LSPs. From a Packet Switching K. Kumaki, et al. Page 4 [Page 4] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 Capable (PSC) network point of view, a router in the PSC network sees GMPLS LSP (signaled in non-PSC network) as a point-to-point link. How effectively IP/MPLS networks can utilize these TE links (FA-LPSs) created in GMPLS networks is an important aspect that needs to be considered. Resource affinity and Priority management are operational aspect that must be considered in deploying GMPLS technology. Specifically, GMPLS technology is equipped with features like resource affinity and priority management, protection and restoration. These features have some implications on how IP/MPLS networks can utilize forwarding and/or routing adjacencies established on top of GMPLS networks. Especially, these management can be a local decision. In this draft, we highlight these implications/requirements and propose solutions to address them. In this fashion this draft complements [GMPLS-mig] draft, which formalizes the MPLS/GMPLS interworking problem. However, [GMPLS-mig] draft does not address MPLS/GMPLS interworking problems such as a mapping between protected MPLS LSPs and protected GMPLS LSPs. Feature richness of MPLS and GMPLS technology allows service providers to use a set of options on how GMPLS services can be used by IP/MPLS networks. However, there are some operational considerations and pros and cons associated with the individual options. This draft also highlights some operations considerations associated with use of GMPLS services by IP/MPLS networks. 2. Terminology SP: Service provider MPLS LSP setup request: MPLS rsvp path message MPLS signaling request: MPLS rsvp path message MPLS TE topology: MPLS TE database (TED) 3. MPLS/GMPLS Deployment,Operational and interworking requirements In this section, we highlight requirements that service providers have in order to deploy GMPLS technology in existing IP/MPLS networks. 3.1 Software Upgrade Requirement Generally speaking, it is not practical to upgrade all IP/MPLS routers to GMPLS capable routers in real SP networks due to a number of reasons. Especially, in case of accommodating enterprise customer, we do not allow IP/MPLS routers to upgrade GMPLS capable routers. This means in the real IP/MPLS networks some routers would not be upgraded to support GMPLS and some routers support would it. K. Kumaki, et al. Page 5 [Page 5] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 3.2 Use of GMPLS network resources in IP/MPLS networks Most SPs have different networks for various services; their GMPLS deployment plans are to have these service networks use a common GMPLS controlled optical core. We need a way to make effective use of GMPLS network resources (e.g. bandwidth) by the IP/MPLS service networks. 3.3 Interworking of MPLS and GMPLS protection If MPLS LSPs are protected using MPLS FRR [RFC4090], when an FRR protected packet LSP is signaled, we should be able to select protected FA-LSPs from GMPLS network. In terms of MPLS protection, MPLS path message can be included some flags in FAST REROUTE object and SESSION_ATTRIBUTE object. In terms of GMPLS protection, there are both signaling aspects [RFC3471] [RFC3473] and routing aspects [GMPLS-routing]. Protected MPLS LSPs should be able to select GMPLS protection type with the option. 3.4 Separation of IP/MPLS domain and GMPLS domain Most SPs have had different networks for every service, where optical networks and IP/MPLS networks belong to different operation, management, ownership. Most important thing is that SPs want to operate and manage their networks independently, and deploy them without changing existing IP/MPLS network topologies, protocols and affecting scalability. 3.5 Failure recovery Failure in optical routing domain should not affect services in IP/MPLS routing domain, and failure can be restored/repaired in optical domain without impacting IP/MPLS domain and vice versa. 4. Augmented model Augmented Model is introduced in GMPLS Architecture document [RFC3945]. It is a hybrid model between the full peer and overlay models as shown in figure1. Border nodes at the edge of IP/MPLS domain and optical domain receive routing information from the optical devices (in optical domain) and nodes (in IP/MPLS domain). Based on this information, border node keeps the optical and IP/MPLS routing domain topology information in separate topology database. No routing information from the router region is carried into the K. Kumaki, et al. Page 6 [Page 6] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 optical region and vice versa. These are quite useful aspects from MPLS/GMPLS deployment, operations as well as interworking requirements. | Optical Transport | | Network | +--------+ +--------+ +-------+ +-------+ +--------+ +---------+ | | | | | | | | | | | | | IP/MPLS+--+ Border +--+--+ OXC1 +--+ OXC2 +-+--+ Border +---+ IP/MPLS | | Service| | Node | | | | | | Node | | Service | | Network| | | | | | | | | | Network | +-----+--+ +---+----+ +-----+-+ +---+---+ +--------+ +---------+ Figure 1. Augmented Model 4.1 Routing in Augmented Model Augmented model maintains a separation between optical and routing topologies; unlike integrated model approach, where topology information is shared between IP/MPLS and Optical domains. Nonetheless, as the border node has full knowledge of the optical network, it can compute routes for GMPLS LSPs within the optical domain. This allows augmented model to be more efficient in resource utilization than overlay model, such that router and optical domain resource can be optimized. At the same time, it can yield more efficient use of resources, similar to the full peer model. In the full peer model, however, since all the devices in optical and routing domains share the same topology and routing information with same IGP instance, it requires all the devices within peer model to be MPLS/GMPLS aware. 4.2 Failure Recovery in Augmented Model Both integrated model and augmented model offer a tighter coordination between IP/MPLS and optical layers, which helps to resolve uncorrelated failures. This is unlike overlay model, which offers no coordination between optical and IP/MPLS layers; consequently a single failure in one layer may trigger uncorrelated failures in the other domain, which may complicate the fault handling. Another important aspect in augmented model is failure transparency, i.e., a failure in an optical network does not affect operations at a router network and vice versa. Specifically, failure in the optical domain does not affect services in routing (IP/MPLS) domain, and failure can be restored/repaired in optical domain without impacting IP/MPLS domain and vice versa. Where as in peer model, since optical K. Kumaki, et al. Page 7 [Page 7] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 and IP/MPLS domains share the same topology and routing information, failure in optical domain is visible to IP/MPLS domain and vice versa. 4.3 Management in Augmented model Currently, many SPs have traditionally built their networks, where Optical transport and IP/MPLS service networks belong to different operation, management, ownership. In augmented model, each network administrator can operate and manage his network independently because this model maintains a complete separation between these networks. 4.4 GMPLS Deployment Considerations In the integrated model, since all the devices in optical and routing domains share the same topology and routing information with same IGP instance, it requires all the devices within peer model to be MPLS/GMPLS aware. Reference [GMPLS-mig] discusses various aspects of migration from MPLS to GMPLS technology using integrated model. In augmented model, as shown in figure 1, devices within optical and its routing domains have no visibility into others topology and/or routing information, except the border nodes. This will help augmented model to accommodate both MPLS based or non-MPLS based service networks connected to border nodes, as long as Border node in augmented model can support GMPLS control plane. One of the main advantages of the augmented model in the context of GMPLS deployment is that it does not require existing IP/MPLS networks to be GMPLS aware. Only border nodes need to be upgraded with the GMPLS functionality. In this fashion, augmented model renders itself for incremental deployment of the optical regions, without requiring reconfiguration of existing areas/ASes, changing operation of IGP and EGP or software upgrade of the existing IP/MPLS service networks. 4.5 Applicability of real/virtual FA-LSP Real/Virtual FA-LSPs discussed in [GMPLS-mig] are equally applicable to the integrated and augmented models. Specifically, in augmented model, the border node can advertise virtual GMPLS FA-LSPs into IP/MPLS networks and can establish the LSP statically or dynamically on as needed basis. The only additional requirement posed by the augmented model is to have at least one full routing adjacency over the GMPLS LSP, such that TE topology exchange for the individual service network can happen. K. Kumaki, et al. Page 8 [Page 8] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 4.6 Applicability of FA Utilization There are several possible schemes for determining how many FAs to provision, when to enable the FAs, and whether to choose FAs of virtual FAs as discussed in [GMPLS-mig] for integrated model. These aspects of FA Utilization are equally applicable to augmented model, with intelligence of FA Utilization implemented at the border node. 4.7 Bundling FA-LSP In augmented model, it is also possible to bundle GMPLS FA-LSPs at the border nodes. Since IP/MPLS network will only see a bundled link with TE or IGP attributes, operations on the bundled link, e.g., adding a new component link, failure of a component link, etc., are completely transparent to the rest of the network. 5. MPLS/GMPLS Interworking aspects This section outlines some MPLS/GMPLS interworking aspects. 5.1 Static vs. signaling triggered dynamic FA-LSPs From signaling perspective, clearly there are two alternatives in which setup for GMPLS tunnel can be triggered: Static (pre- configured) and Dynamic (on-demand based on signaling setup request). Decision to establish new Static GMPLS LSPs are made either by the operator or automatically (e.g., using features like TE auto-mesh). In either case, Static FA-LSP are established and advertised prior to setup of MPLS LSPs using them in the ERO. In case of static FA-LSP, if MPLS LSP setup request cannot be satisfied by existing Static FA- LSPs, it is rejected. Dynamic FA-LSP is triggered by MPLS LSP setup request for an MPLS LSP. Please note that dynamic FA-LSPs can be virtual FAs from routing perspective. In either case, LSP creation from signaling perspective is triggered by the MPLS RSVP Path message received at a MPLS/GMPLS border router. In the case of Static or Virtual FA-LSPs, the FA may be specified in an ERO encoded as strict ERO. In the case where FA-LSPs are dynamic and are not advertised as virtual links in the MPLS TE topology, MPLS signaling request contains a loose ERO, and GMPLS LSP selection is a local decision at the border router. In the case of Static or Virtual FA-LSPs, a signaling request may also be encoded as loose ERO. K. Kumaki, et al. Page 9 [Page 9] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 When the border router receives the signaling setup request and determines that in order for it to expand the loose ERO content, it needs to create GMPLS FA-LSP. Consequently, it signals a GMPLS LSP respecting MPLS/GMPLS signaling interworking aspects discussed in this sections. Once the GMPLS FA-LSP is fully established, the ERO contents for the MPLS signaling setup request are expanded to use the GMPLS LSP and signaling setup for the FA-LSP are carried in-band of the GMPLS LSP. The GMPLS LSP can then also be advertised as an FA-LSP in MPLS TE topology or an IGP adjacency can be brought up on the GMPLS LSP. 5.2 MPLS/GMPLS LSP Resource Affinity Mapping In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled for specific resource class affinities [RFC3209], [RFC3473]. This can be viewed as "colors". In terms of routing aspects, resource classes are associated with links and advertised by routing protocol in IP/MPLS domain [RFC3630] and GMPLS domain, respectively. A real or virtual GMPLS FA-LSP or a full Routing Adjacency (RA) over GMPLS LSP can be advertised as TE-links with resource class. In this case, MPLS routers can select a GMPLS FA/RA that has a specific color. If MPLS signaling request contains a loose ERO, and GMPLS LSP selection is a local decision at the border router. This is possible for the cases when GMPLS LSP is not advertised into IP/MPLS networks. In this case, any mapping combination may be defined manually and dynamically based on some policies at the border router. 5.3 MPLS/GMPLS LSP Priority Mapping In terms of signaling aspects, both MPLS and GMPLS LSPs are signaled for specific setup and hold priority [RFC3209], [RFC3473], based on the importance of traffic carried over them. For proper operation of the network, it is desirable to create/use GMPLS LSPs of specified setup and hold priority, based on the setup and hold priority of the MPLS LSPs using them. In terms of routing aspects, unreserved bandwidth sub-TLV is used for the amount of bandwidth not yet reserved at each of the eight priority levels in MPLS domain [RFC3630] and max lsp bandwidth at priority 0-7 in interface switching capability descriptor sub-TLV is used for the amount of bandwidth that can be reserved at each of the eight priority levels in GMPLS domain [GMPLS-ospf-routing]. K. Kumaki, et al. Page 10 [Page 10] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 In an MPLS/GMPLS interworking, if a GMPLS LSP is advertised into IP/MPLS networks as an FA/RA, an LSR in the packet network can see it a TE-link with unreserved bandwidth as advertised by the border router. In this case, MPLS routers can select links that meet a bandwidth depending on a priority level. If MPLS signaling request contains a loose ERO, the GMPLS LSP selection is a local decision at the border router. This is possible in the case where GMPLS LSP is not advertised as an FA into IP/MPLS networks. In this case, following approaches are possible for mapping setup and hold priority of MPLS LSPs to GMPLS FA-LSPs. These mapping functions can be applied, either manually or dynamically, depending on some policies at the border router. 1) Exact Match: In this case setup and hold priority of the GMPLS FA-LSP is same as setup and hold priority of MPLS LSP using it. In other words, GMPLS LSP Priority set = MPLS LSP Priority set. 2) Better Priority: In this case GMPLS FA-LSP can be of setup and hold priority equal better than the MPLS LSP using it. In other words, GMPLS LSP Priority set <= MPLS LSP Priority set. 3) Dynamic Priority for GMPLS LSP: In this case priority of GMPLS LSP is dynamically changed based on priority of the MPLS LSPs using it. In other words, GMPLS LSP Priority set = min (MPLS LSP Priority set). 4) Any to Any Mapping Matrix: Based on some policies, it is possible to have an any-to-any mapping for MPLS/GMPLS priority mapping at the MPLS/GMPLS border router. 5) No Priority Management in GMPLS core: In this simple minded approach all GMPLS LSPs can be establish with setup and hold priority of "0", i.e., the GMPLS LSPs are already set as better match. In this case, priority management is handled purely at MPLS layer, with GMPLS network providing L1 connectivity without priority management. 5.4 Signaling Protected MPLS LSPs When MPLS LSPs are protected using MPLS-FRR mechanism [RFC4090] and it may be desired to signal MPLS LSP such that it uses protected GMPLS tunnel FA-LSPs. In this section we discuss MPLS/GMPLS interworking aspect for protected MPLS LSPs. K. Kumaki, et al. Page 11 [Page 11] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 In the case of loose ERO, where selection of GMPLS FA-LSP is a left for the border nodes and "One-to-One backup desired" or "facility backup desired" flag of the FAST REROUTE object, "Local protection desired" and/or "bandwidth protection desired" and/or "node protection desired" flag of the SESSION_ATTRIBUTE object is set, the border router SHOULD try to map the signaling setup request to a GMPLS LSP which is protected within GMPLS domain. However, in the case of strict ERO, the selection of GMPLS FA-LSP is based on the contents of the ERO and these flags are ignored. When a GMPLS LSP is advertised as FA or RA in MPLS network, Protection Capabilities attribute of the Link Protection Type is a sub-TLV of the Link TLV can be used for selecting GMPLS LSP of desired protection capability. 6. Operational Considerations In this section, we discuss some operational considerations and pros and cons associated with the individual options listed in Section 5.3. 6.1 Applicability of the Priority Management Options In section 5.3, various options from exact match to no priority management in GMPLS network are discussed. This section provides an applicability of these options. The benefit of Priority Management in GMPLS Core comes at the cost of bandwidth fragmentation. E.g., in simplest approach of exact match, we need at least as many GMPLS LSPs, as there are priority combination in the network, while the other extreme of no priority management in GMPLS network does allow full aggregation of MPLS traffic on GMPLS FAs, i.e. avoids bandwidth fragmentation. If IGP adjacency is to be established over the GMPLS LSPs, having more GMPLS LSP leads to more links in the IGP/IP topology. The same is true of MPLS TE topology with the exception that FA-LSPs can be bundled to avoid flooding of multiple TE links. With priority management within GMPLS network, there is a danger of creating oscillations in the IP/MPLS network using GMPLS. This is because when a new FA-LSP is established based on a local routing decision made at the border router; we can have undesirable preemption affecting MPLS LSPs carried over the GMPLS LSP that is being preempted. This can have cascading affect leading to oscillations on the operation of MPLS traffic. K. Kumaki, et al. Page 12 [Page 12] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 6.2 Applicability of the Signaling Triggered Dynamic FA-LSP In this section, we discussed applicability of static vs. dynamic FA- LSPs. It is important to realize that we can have FA-LSPs that are created dynamically based on triggers like configuration, link utilization level, etc. However, in the context of this document, such FA-LSPs are considered as static FAs. In this document, the term dynamic FA-LSPs are used for FA-LSPs that are triggered by RSVP Path message for MPLS LSP. Signaling triggered dynamic FA-LSPs are addressing a problem space where traffic pattern cannot be predicted or objective is to optimize operations of the network based on actually signaled request rather than predicted use of the network resource (i.e., off-line traffic engineering). The problem with the use of signaling triggered dynamic FA-LSPs is that we loose ability to better aggregate the traffic request at the border routers. This leads to potential cases of bandwidth fragmentation inside GMPLS core, which has disadvantages discussed in Section 6.1. Furthermore, signaling triggered dynamic FA-LSPs coupled with preemption can lead to oscillations in the operation of the network. This is because when a new FA-LSP is dynamically established based on a local routing decision made at the border router; we can have undesirable preemption affecting MPLS LSPs carried over the GMPLS LSP that is being preempted. This can have cascading affect leading to oscillations on the operation of MPLS traffic. 7. Backward Compatibility Note The procedure presented in this document is backward compatible with [RFC3630], [RFC3784], [RFC3209] and [RFC3473]. 8. Security Considerations This document does not introduce new security issues. 9. Intellectual Property Considerations 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 K. Kumaki, et al. Page 13 [Page 13] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 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. 10.Acknowledgement The author would like to express the thanks to Arthi Ayyangar for helpful comments and feedback. 11.Reference 11.1 Normative Reference [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, RFC 3209, December 2001. [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, S. Bradner, March 1997. [GMPLS-mig] "IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration", draft-oki-ccamp-gmpls-ip-interworking-05.txt, D. Brungard, et al, February 2005. [RFC3945] "Generalized Multi-Protocol Label Switching (GMPLS) Architecture",RFC 3945, E. Mannie,October 2004. 11.2 Informative Reference [GMPLS-routing] "Routing Extensions in Support of Generalized Multi- Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09.txt (work in progress), October 2003. K. Kumaki, et al. Page 14 [Page 14] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 [GMPLS-ospf-routing] "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls- extensions-12.txt (work in progress), October 2003. [RFC2205] "Resource Reservation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, Braden, et al, September 1997. [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, L. Berger, et al, January 2003. [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP- TE) Extensions", RFC 3473, L. Berger, et al, January 2003. [RFC4090] "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Pan, et al, May 2005. 12.Author's Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN E-mail : ke-kumaki@kddi.com Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Phone: 613 254 3498 Kanata, Ontario Email: zali@cisco.com Canada K2K 3E8 Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719 Phone: +1 978 936 1398 Email: swallow@cisco.com K. Kumaki, et al. Page 15 [Page 15] draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt July.2005 Mallik Tatipamula Cisco systems, Inc., 170 W. Tasman Drive San Jose, CA 95134 Phone: 408 525 4568 USA. Email: mallikt@cisco.com 13.Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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. K. Kumaki, et al. Page 16 [Page 16]