[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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: 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]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/