CCAMP Working Group Zafar Ali George Swallow Mallik Tatipamula Cisco Systems Tomohiro Otani KDDI R&D Laboratories, Inc. Kenji Kumaki KDDI Corporation Internet Draft Category: BCP Expires: August 2005 February 2005 GMPLS Deployment in Existing IP/MPLS networks draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are 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. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Z. Ali, et al. Page 1 2/14/2005 [Page 1] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 Abstract One of the biggest challenges faced by GMPLS technology is ôhow it can be deployedö in a manner least impacting to existing IP/ MPLS networks. 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. 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 GMPLS deployment aspects. WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? This work fits in the context of GMPLS deployment. WHY IS IT TARGETED AT THIS WG? This document is targeted at ccamp as it addresses GMPLS deployment aspects. RELATED REFERENCES Please refer to the reference section. Table of Contents 1. Introduction...................................................3 2. Augmented Model................................................4 2.1 Routing in Augmented Model.................................4 2.2 Failure Recovery in Augmented Model........................4 Z. Ali, et al. Page 2 2/14/2005 [Page 2] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 2.3 Management in Augmented model..............................5 3. GMPLS Deployment Considerations................................5 3.1 Applicability of virtual FA-LSP............................6 3.2 Applicability of FA Utilization............................6 4. Backward Compatibility Note....................................6 5. Security Considerations........................................6 6. IANA Considerations............................................6 7. Full Copyright Statement.......................................6 8. Intellectual Property..........................................7 9. IPR Disclosure Acknowledgement.................................7 10. Reference.....................................................7 10.1 Normative Reference.......................................7 10.2 Informative Reference.....................................8 11. Author's Addresses............................................8 1. Introduction 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. Z. Ali, et al. Page 3 2/14/2005 [Page 3] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 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. 2. Augmented Model Augmented Model is introduced in GMPLS Architecture document [RFC3945]. It is a hybrid model between the full peer and overlay models. 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 optical region and vice versa. | Optical Transport | | Network | +--------+ +--------+ +-------+ +-------+ +--------+ +---------+ | | | | | | | | | | | | | IP/MPLS+--+ Border +--+--+ OXC1 +--+ OXC2 +-+--+ Border +---+ IP/MPLS | | Service| | Node | | | | | | Node | | Service | | Network| | | | | | | | | | Network | +-----+--+ +---+----+ +-----+-+ +---+---+ +--------+ +---------+ 2.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. 2.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; Z. Ali, et al. Page 4 2/14/2005 [Page 4] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 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 optical network does not affect operations at 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 and IP/MPLS domains share the same topology and routing information, failure in optical domain is visible to IP/MPLS domain and vice versa. 2.3 Management in Augmented model Currently, many service providers 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. 3. 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 deployability 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. Z. Ali, et al. Page 5 2/14/2005 [Page 5] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 3.1 Applicability of virtual FA-LSP 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 network and can establish the LSP statically or dynamically on as needed basis. 3.2 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.3 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. 4. Backward Compatibility Note The procedure presented in this document is backward compatible with [RFC3630], [RFC3784], [RFC3209] and [RFC3473]. 5. Security Considerations This document does not introduce new security issues. 6. IANA Considerations No. 7. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 Z. Ali, et al. Page 6 2/14/2005 [Page 6] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 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. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 10. Reference 10.1 Normative Reference [RFC3945] ôGeneralized Multi-Protocol Label Switching (GMPLS) Architectureö, RFC 3945, E. Mannie, October 2004. [GMPLS-mig] ôIP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migrationö, draft-oki-ccamp-gmpls-ip-interworking-04.txt work in progress, October 2004 . Z. Ali, et al. Page 7 2/14/2005 [Page 7] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, S. Bradner, March 1997. 10.2 Informative Reference [GMPLS-overlay] Generalize Multiprotocol Label Switching(GMPLS)User- Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Modelö, draft-ietf- ccamp-gmpls-overlay-05.txt, work in progress, October 2004. [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. [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, RFC 3209, December 2001. [OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. 11. Author's Addresses Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Phone: 613 254 3498 Kanata, Ontario Email: zali@cisco.com Canada K2K 3E8 George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave, Boxborough, MA 01719 Phone: +1 978 936 1398 Email: swallow@cisco.com Z. Ali, et al. Page 8 2/14/2005 [Page 8] draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt Feb. 2005 Mallik Tatipamula Cisco systems, Inc., 170 W. Tasman Drive San Jose, CA 95134 Phone: 408 525 4568 USA. Email: mallikt@cisco.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN E-mail : ke-kumaki@kddi.com 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 Z. Ali, et al. Page 9 2/14/2005 [Page 9]