Internet DRAFT - draft-ali-ccamp-gmpls-deployment-augmented-model


   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 
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-
   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-
   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 
   The list of Internet-Draft Shadow Directories can be accessed at 
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 
   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 
   this document are to be interpreted as described in RFC 2119 
Routing Area ID Summary 
   (This section to be removed before publication.) 
      This document addresses GMPLS deployment aspects.  
      This work fits in the context of GMPLS deployment.  
      This document is targeted at ccamp as it addresses GMPLS 
   deployment aspects.  
   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 
                          |        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 
   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 
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 
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 
Z. Ali, et al.                  Page 6                       2/14/2005
[Page 6] 
    draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt    Feb. 2005 
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 
   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- 
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 
   [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: 
   Canada K2K 3E8 
   George Swallow 
   Cisco Systems, Inc. 
   1414 Massachusetts Ave, 
   Boxborough, MA 01719 
   Phone:  +1 978 936 1398 
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: 
   Kenji Kumaki 
   KDDI Corporation 
   Garden Air Tower 
   Iidabashi, Chiyoda-ku, 
   Tokyo 102-8460, JAPAN 
   E-mail : 
   Tomohiro Otani 
   KDDI R&D Laboratories, Inc.  
   2-1-15 Ohara Kamifukuoka     Phone:  +81-49-278-7357 
   Saitama, 356-8502. Japan     Email: 

Z. Ali, et al.                  Page 9                       2/14/2005
[Page 9]