[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk) 00 01 02 03 04 05 RFC 5145

Network Working Group                                K. Shiomoto(Editor)
Internet Draft                                                     (NTT)
Intended Status: Informational
Created: January 13, 2008
Expires: July 13, 2008

                 Framework for MPLS-TE to GMPLS migration
             draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.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.

Abstract

   The migration from Multiprotocol Label Switching (MPLS) Traffic
   Engineering (TE) to Generalized MPLS (GMPLS) is the process of
   evolving an MPLS-TE control plane to a GMPLS control plane. An
   appropriate migration strategy will be selected based on various
   factors including the service provider's network deployment plan,
   customer demand, and operational policy.

   This document presents several migration models and strategies for
   migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE
   and GMPLS devices, or networks, may coexist which may require
   interworking between MPLS-TE and GMPLS protocols. Aspects of the
   interworking required are discussed as it will influence the choice
   of a migration strategy. This framework document provides a migration
   toolkit to aid the operator in selection of an appropriate strategy.

   This framework document also lists a set of solutions that may aid in
   interworking, and highlights a set of potential issues.

 Shiomoto et al.                                                [Page 1]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008




Table of Contents

   1. Introduction.................................................... 2
   2. Conventions Used in This Document............................... 3
   3. Motivations for Migration....................................... 4
   4. MPLS to GMPLS Migration Models.................................. 4
      4.1. Island Model............................................... 5
         4.1.1. Balanced Islands...................................... 6
         4.1.2. Unbalanced Islands.................................... 6
      4.2. Integrated Model........................................... 7
      4.3. Phased Model............................................... 8
   5. Migration Strategies and Toolkit................................ 8
      5.1. Migration Toolkit.......................................... 9
         5.1.1. Layered Networks...................................... 9
         5.1.2. Routing Interworking................................. 11
         5.1.3. Signaling Interworking............................... 12
         5.1.4. Path Computation Element............................. 13
   6. Manageability Considerations................................... 13
      6.1. Control of Function and Policy............................ 13
      6.2. Information and Data Models............................... 14
      6.3. Liveness Detection and Monitoring......................... 14
      6.4. Verifying Correct Operation............................... 14
      6.5. Requirements on Other Protocols and Functional Components. 14
      6.6. Impact on Network Operation............................... 15
      6.7. Other Considerations...................................... 15
   7. Security Considerations........................................ 15
   8. IANA Considerations............................................ 16
   9. Acknowledgements............................................... 16
   10. Editor's Addresses............................................ 16
   11. Authors' Addresses............................................ 16
   12. References.................................................... 17
      12.1. Normative References..................................... 17
      12.2. Informative References................................... 18
   13. Full Copyright Statement...................................... 19
   14. Intellectual Property......................................... 19



1. Introduction

   Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to
   Generalized MPLS (GMPLS) migration is the process of evolving an
   MPLS-TE-based control plane to a GMPLS-based control plane. The
   network under consideration for migration is, therefore, a packet-
   switching network.



 Shiomoto                                                       [Page 2]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

   There are several motivations for such migration, mainly the desire
   to take advantage of new features and functions added to the GMPLS
   protocols and which are not present in MPLS-TE for packet networks.
   Additionally, before migrating a packet-switching network from MPLS-
   TE to GMPLS, one may choose to first migrate a lower-layer network
   with no control plane (e.g. controlled by a management plane) to
   using a GMPLS control plane, and this may lead to the desire for
   MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE
   support and facilitate the later migration of the packet-switching
   network.

   Although an appropriate migration strategy will be selected based on
   various factors including the service provider's network deployment
   plan, customer demand, deployed network equipments, operational
   policy, etc., the transition mechanisms used should also provide
   consistent operation of newly introduced GMPLS networks, while
   minimizing the impact on the operation of existing MPLS-TE networks.

   This document describes several migration strategies and the
   interworking scenarios that arise during migration. It also examines
   the implications for network deployments and for protocol usage. As
   the GMPLS signaling and routing protocols are different from the
   MPLS-TE control protocols, interworking mechanisms between MPLS-TE
   and GMPLS networks, or network elements, may be needed to compensate
   for the differences.

   Note that MPLS-TE and GMPLS protocols can co-exist as "ships in the
   night" without any interworking issue.

2. Conventions Used in This Document

   This is not a requirements document, nevertheless 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] in order to
   clarify the recommendations that are made.

   In the rest of this document, the term "GMPLS" includes both packet
   switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS"
   or "non-PSC GMPLS" is explicitly used.

   In general, the term "MPLS" is used to indicate MPLS traffic
   engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and
   excludes other MPLS protocols such as the Label Distribution Protocol
   (LDP). TE functionalities of MPLS could be migrated to GMPLS, but
   non-TE functionalities could not. If non-TE MPLS is intended, it is
   explicitly indicated.

   The reader is assumed to be familiar with the terminology introduced
   in [RFC3945].

 Shiomoto                                                       [Page 3]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

3. Motivations for Migration

   Motivations for migration will vary for different service providers.
   This section is presented to provide background so that the migration
   discussions may be seen in context. Sections 4 and 5 provide examples
   to illustrate the migration models and processes.

   Migration of an MPLS-capable LSR to include GMPLS capabilities may be
   performed for one or more reasons, including, not exhaustively:

   o  To add all GMPLS PSC features to an existing MPLS network (upgrade
      MPLS LSRs).

   o  To add specific GMPLS PSC features and operate them within an MPLS
      network (ex. [RFC4872] [RFC4873]).

   o  To integrate a new GMPLS PSC network with an existing MPLS network
      (without upgrading any of the MPLS LSRs).

   o  To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs
      supporting only GMPLS PSC and/or non-PSC features.

   o  To integrate multiple control networks, e.g. managed by separate
      administrative organizations, and which independently utilize MPLS
      or GMPLS.

   o  To build integrated PSC and non-PSC networks. The non-PSC networks
      are controlled by GMPLS.

   The objective of migration from MPLS to GMPLS is that all LSRs, and
   the entire network, support GMPLS protocols. During this process,
   various interim situations may exist, giving rise to the interworking
   situations described in this document. The interim situations may
   exist for considerable periods of time, but the ultimate objective is
   not to preserve these situations. For the purposes of this document,
   they should be considered as temporary and transitory.

4. MPLS to GMPLS Migration Models

   Three reference migration models are described below. Multiple
   migration models may co-exist in the same network.










 Shiomoto                                                       [Page 4]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

4.1. Island Model

   In the island model, "islands" of network nodes operating one
   protocol exist within a "sea" of nodes using the other protocol.

   For example, consider an island of GMPLS-capable nodes (PSC) which is
   introduced into a legacy MPLS network. Such an island might be
   composed of newly added GMPLS nodes, or might arise from the upgrade
   of existing nodes that previously operated MPLS protocols.

   The opposite is also quite possible. That is, there is a possibility
   that an island happens to be MPLS-capable within a GMPLS sea. Such a
   situation might arise in the later stages of migration, when all but
   a few islands of MPLS-capable nodes have been upgraded to GMPLS.

   It is also possible that a lower-layer, manually-provisioned network
   (for example, a TDM network) is constructed under an MPLS PSC
   network. During the process of migrating both networks to GMPLS, the
   lower-layer network might be migrated first. This would appear as a
   GMPLS island within an MPLS sea.

   Lastly, it is possible to consider individual nodes as islands. That
   is, it would be possible to upgrade or insert an individual GMPLS-
   capable node within an MPLS network, and to treat that GMPLS node as
   an island.

   Over time, collections of MPLS devices are replaced or upgraded to
   create new GMPLS islands or to extend existing ones, and distinct
   GMPLS islands may be joined together until the whole network is
   GMPLS-capable.

   From a migration/interworking point of view, we need to examine how
   these islands are positioned and how LSPs connect between the
   islands.

   Four categories of interworking scenarios are considered: (1) MPLS-
   GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS.
   In case 1, the interworking behavior is examined based on whether the
   GMPLS islands are PSC or non-PSC.

   Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS
   interworking. The model consists of a transit GMPLS island in an MPLS
   sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and
   G6) are referred to as "island border nodes". If the GMPLS island was
   non-PSC, all nodes except the island border nodes in the GMPLS-based
   transit island (G3 and G4) would be non-PSC devices, i.e., optical
   equipment (TDM, LSC, and FSC).




 Shiomoto                                                       [Page 5]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


   .................  ..........................  ..................
   :      MPLS      :  :          GMPLS         :  :     MPLS       :
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :      ________/ :  :  _______/  |   _____ / :  :  ________/     :
   :     /          :  : /          |  /        :  : /              :
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :................:  :........................:  :................:

      |<-------------------------------------------------------->|
                                  e2e LSP


              Figure 1 : Example of the island model for
                    MPLS-GMPLS-MPLS interworking.

4.1.1. Balanced Islands

   In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end
   using the same protocols. Possible strategies include:

   - tunneling the signaling across the island network using LSP
     nesting or stitching [STITCH] (the latter is for only with GMPLS-
     PSC)

   - protocol interworking or mapping (both are for only with GMPLS-
     PSC)

4.1.2. Unbalanced Islands

   As previously discussed, there are two island interworking models
   which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
   island cases are likely to arise where the migration strategy is not
   based on a core infrastructure, but has edge nodes (ingress or
   egress) located in islands of different capabilities.

   In this case, an LSP starts or ends in a GMPLS (PSC) island and
   correspondingly ends or starts in an MPLS island. This mode of
   operation can only be addressed using protocol interworking or
   mapping. Figure 2 shows the reference model for this migration
   scenario. Head-end and tail-end LSR are in distinct control plane
   clouds.





 Shiomoto                                                       [Page 6]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


        ............................  .............................
        :            MPLS          :  :       GMPLS (PSC)         :
        :+---+        +---+       +----+        +---+        +---+:
        :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
        :+---+        +---+       +----+        +-+-+        +---+:
        :      ______/  |   _____/ :  :  ______/  |   ______/     :
        :     /         |  /       :  : /         |  /            :
        :+---+        +---+       +----+        +-+-+        +---+:
        :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
        :+---+        +---+       +----+        +---+        +---+:
        :..........................:  :...........................:

          |<-------------------------------------------------->|
                                  e2e LSP


                  Figure 2 : GMPLS-MPLS interworking model.

   It is important to underline that this scenario is also impacted by
   the directionality of the LSP, and the direction in which the LSP is
   established.

4.2. Integrated Model

   The second migration model involves a more integrated migration
   strategy. New devices that are capable of operating both MPLS and
   GMPLS protocols are introduced into the MPLS network.

   In the integrated model there are two types of nodes present during
   migration:

      - support MPLS only (legacy nodes)

      - support MPLS and GMPLS.

   In this model, as existing MPLS devices are upgraded to support both
   MPLS and GMPLS, the network continues to operate with a MPLS control
   plane, but some LSRs are also capable of operating with a GMPLS
   control plane. So, LSPs are provisioned using MPLS protocols where
   one end point of a service is a legacy MPLS node and/or where the
   selected path between end points traverses a legacy node that is not
   GMPLS-capable. But where the service can be provided using only
   GMPLS-capable nodes [RFC5073], it may be routed accordingly and can
   achieve a higher level of functionality by utilizing GMPLS features.

   Once all devices in the network are GMPLS-capable, the MPLS specific
   protocol elements may be turned off, and no new devices need to
   support these protocol elements.


 Shiomoto                                                       [Page 7]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

   In this model, the questions to be addressed concern the co-existence
   of the two protocol sets within the network. Actual interworking is
   not a concern.

4.3. Phased Model

   The phased model introduces GMPLS features and protocol elements into
   an MPLS network one by one. For example, some objects or sub-objects
   (such as the ERO label sub-object, [RFC3473]) might be introduced
   into the signaling used by LSRs that are otherwise MPLS-capable. This
   would produce a kind of hybrid LSR.

   This approach may appear simpler to implement as one is able to
   quickly and easily pick up key new functions without needing to
   upgrade the whole protocol implementation. It is most likely to be
   used where there is a desire to rapidly implement a particular
   function within a network without the necessity to install and test
   the full GMPLS function.

   Interoperability concerns though are exacerbated by this migration
   model, unless all LSRs in the network are updated simultaneously and
   there is a clear understanding of which subset of features are to be
   included in the hybrid LSRs. Interworking between a hybrid LSR and an
   unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
   LSR as described in the previous sections and puts the unchanged LSR
   in the role of an MPLS LSR. The potential for different hybrids
   within the network will complicate matters considerably. This model
   is, therefore, only appropriate for use when the set of new features
   to be deployed is well known and limited, and where there is a clear
   understanding of and agreement on this set of features by the network
   operators of the ISP(s) involved as well as all vendors whose
   equipment will be involved in the migration.

5. Migration Strategies and Toolkit

   An appropriate migration strategy is selected by a network operator
   based on factors including the service provider's network deployment
   plan, customer demand, existing network equipment, operational
   policy, support from its vendors, etc.

   For PSC networks, the migration strategy involves the selection
   between the models described in the previous section. The choice will
   depend upon the final objective (full GMPLS capability, partial
   upgrade to include specific GMPLS features, or no change to existing
   IP/MPLS networks), and upon the immediate objectives (full, phased,
   or staged upgrade).

   For PSC networks serviced by non-PSC networks, two basic migration
   strategies can be considered. In the first strategy, the non-PSC
   network is made GMPLS-capable, first, and then the PSC network is

 Shiomoto                                                       [Page 8]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

   migrated to GMPLS. This might arise when, in order to expand the
   network capacity, GMPLS-based non-PSC sub-networks are introduced
   into the legacy MPLS-based networks. Subsequently, the legacy MPLS-
   based PSC network is migrated to be GMPLS-capable as described in the
   previous paragraph. Finally the entire network, including both PSC
   and non-PSC nodes, may be controlled by GMPLS.

   The second strategy is to migrate the PSC network to GMPLS first, and
   then enable GMPLS within the non-PSC network. The PSC network is
   migrated as described before, and when the entire PSC network is
   completely converted to GMPLS, GMPLS-based non-PSC devices and
   networks may be introduced without any issues of interworking between
   MPLS and GMPLS.

   These migration strategies and the migration models described in the
   previous section are not necessarily mutually exclusive. Mixtures of
   all strategies and models could be applied. The migration models and
   strategies selected will give rise to one or more of the interworking
   cases described in the following section.

5.1. Migration Toolkit

   As described in the previous sections, an essential part of a
   migration and deployment strategy is how the MPLS and GMPLS or hybrid
   LSRs interwork. This section sets out some of the alternatives for
   achieving interworking between MPLS and GMPLS, and identifies some of
   the issues that need to be addressed. This document does not describe
   solutions to these issues.

   Note that it is possible to consider upgrading the routing and
   signaling capabilities of LSRs from MPLS to GMPLS separately.

5.1.1. Layered Networks

   In the balanced island model, LSP tunnels [RFC4206] are a solution to
   carry the end-to-end LSPs across islands of incompatible nodes.
   Network layering is often used to separate domains of different data
   plane technology. It can also be used to separate domains of
   different control plane technology (such as MPLS and GMPLS
   protocols), and the solutions developed for multiple data plane
   technologies can be usefully applied to this situation [RFC3945],
   [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the
   requirements for multi-layered networks.








 Shiomoto                                                       [Page 9]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


   The GMPLS architecture [RFC3945] identifies three architectural
   models for supporting multi-layer GMPLS networks, and these models
   may be applied to the separation of MPLS and GMPLS control plane
   islands.

   - In the peer model, both MPLS and GMPLS nodes run the same routing
     instance, and routing advertisements from within islands of one
     level of protocol support are distributed to the whole network.
     This is achievable only as described in section 5.1.2 either by
     direct distribution or by mapping of parameters.

     Signaling in the peer model may result in contiguous LSPs,
     stitched LSPs [STITCH] (only for GMPLS PSC), or nested LSPs. If
     the network islands are non-PSC then the techniques of [MLN-REQ]
     may be applied, and these techniques may be extrapolated to
     networks where all nodes are PSC, but where there is a difference
     in signaling protocols.

   - The overlay model preserves strict separation of routing
     information between network layers. This is suitable for the
     balanced island model and there is no requirement to handle
     routing interworking. Even though the overlay model preserves
     separation of signaling information between network layers, there
     may be some interaction in signaling between network layers.

     The overlay model requires the establishment of control plane
     connectivity for the higher layer across the lower layer.

   - The augmented model allows limited routing exchange from the lower
     layer network to the higher layer network. Generally speaking,
     this assumes that the border nodes provide some form of filtering,
     mapping or aggregation of routing information advertised from the
     lower layer network. This architectural model can also be used for
     balanced island model migrations. Signaling interworking is
     required as described for the peer model.

   - The border peer architecture model is defined in [MPLS-OVER-GMPLS].
     This is a modification of the augmented model where the layer
     border routers have visibility into both layers, but no routing
     information is otherwise exchanged between routing protocol
     instances. This architectural model is particularly suited to the
     MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands.
     Signaling interworking is required as described for the peer model.







 Shiomoto                                                      [Page 10]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


5.1.2. Routing Interworking

   Migration strategies may necessitate some interworking between MPLS
   and GMPLS routing protocols. GMPLS extends the TE information
   advertised by the IGPs to include non-PSC information and extended
   PSC information. Because the GMPLS information is provided as
   additional TLVs that are carried along with the MPLS information,
   MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS
   PSC LSRs. They will also see other GMPLS information, but will ignore
   it, flooding it transparently across the MPLS network for use by
   other GMPLS LSRs.

   - Routing separation is achieved in the overlay and border peer
     models. This is convenient since only the border nodes need to be
     aware of the different protocol variants, and no mapping is
     required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS-
     GMPLS island migration models.

   - Direct distribution involves the flooding of MPLS routing
     information into a GMPLS network, and GMPLS routing information
     into an MPLS network. The border nodes make no attempt to filter
     the information. This mode of operation relies on the fact that
     MPLS routers will ignore, but continue to flood, GMPLS routing
     information that they do not understand. The presence of
     additional GMPLS routing information will not interfere with the
     way that MPLS LSRs select routes, and although this is not a
     problem in a PSC-only network, it could cause problems in a peer
     architecture network that includes non-PSC nodes as the MPLS nodes
     are not capable of determining the switching types of the other
     LSRs and will attempt to signal end-to-end LSPs assuming all LSRs
     to be PSC. This fact would require island border nodes to take
     triggered action to set up tunnels across islands of different
     switching capabilities.

     GMPLS LSRs might be impacted by the absence of GMPLS-specific
     information in advertisements initiated by MPLS LSRs. Specific
     procedures might be required to ensure consistent behavior by
     GMPLS nodes. If this issue is addressed, then direct distribution
     can be used in all migration models (except the overlay and border
     peer architectural models where the problem does not arise).

   - Protocol mapping converts routing advertisements so that they can
     be received in one protocol and transmitted in the other. For
     example, a GMPLS routing advertisement could have all of its
     GMPLS-specific information removed and could be flooded as an MPLS
     advertisement. This mode of interworking would require careful
     standardization of the correct behavior especially where an MPLS



 Shiomoto                                                      [Page 11]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


     advertisement requires default values of GMPLS-specific fields to
     be generated before the advertisement can be flooded further.
     There is also considerable risk of confusion in closely meshed
     networks where many LSRs have MPLS and GMPLS capable interfaces.
     This option for routing interworking during migration is NOT
     RECOMMENDED for any migration model. Note that converting GMPLS-
     specific sub-TLVs to MPLS-specific ones but not stripping the
     GMPLS-specific ones is considered as a variant of the proposed
     solution in the previous bullet (Unknown sub-TLVs should be
     ignored [RFC3630] but must continue to be flooded).

   - Ships in the night refers to a mode of operation where both MPLS
     and GMPLS routing protocol variants are operated in the same
     network at the same time as separate routing protocol instances.
     The two instances are independent and are used to create routing
     adjacencies between LSRs of the same type. This mode of operation
     may be appropriate to the integrated migration model.

5.1.3. Signaling Interworking

   Signaling protocols are used to establish LSPs and are the principal
   concern for interworking during migration. Issues of compatibility
   arise because of differences in the encodings and codepoints used by
   MPLS and GMPLS signaling, but also because of differences in
   functionality provided by MPLS and GMPLS.

   - Tunneling and stitching [STITCH] (GMPLS-PSC case) mechanisms
     provide the potential to avoid direct protocol interworking during
     migration in the island model, because protocol elements are
     transported transparently across migration islands without being
     inspected. However, care may be needed to achieve functional
     mapping in these modes of operation since one set of features may
     need to be supported across a network designed to support a
     different set of features. In general, this is easily achieved for
     the MPLS-GMPLS-MPLS model, but may be hard to achieve in the
     GMPLS-MPLS-GMPLS model. For example, when end-to-end bidirectional
     LSPs are requested, since the MPLS island does not support
     bidirectional LSPs.

     Note that tunneling and stitching are not available in unbalanced
     island models because in these cases the LSP end points use
     different protocols.

   - Protocol mapping is the conversion of signaling messages between
     MPLS and GMPLS. This mechanism requires careful documentation of
     the protocol fields and how they are mapped. This is relatively
     straightforward in the MPLS-GMPLS unbalanced island model for LSPs



 Shiomoto                                                      [Page 12]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

     signaled in the MPLS-GMPLS direction. However, it may be more
     complex for LSPs signaled in the opposite direction, and this will
     lead to considerable complications for providing GMPLS services
     over the MPLS island and for terminating those services at an
     egress LSR that is not GMPLS-capable. Further, in balanced island
     models, and in particular where there are multiple small
     (individual node) islands, the repeated conversion of signaling
     parameters may lead to loss of information (and functionality) or
     mis-requests.

   - Ships in the night could be used in the integrated migration model
     to allow MPLS-capable LSRs to establish LSPs using MPLS signaling
     protocols and GMPLS LSRs to establish LSPs using GMPLS signaling
     protocols. LSRs that can handle both sets of protocols could work
     with both types of LSRs, and no conversion of protocols would be
     needed.

5.1.4. Path Computation Element

   The Path Computation Element (PCE) [RFC4655] may provide an
   additional tool to aid MPLS to GMPLS migration. If a layered network
   approach (Section 5.1.1) is used, PCEs may be used to facilitate the
   computation of paths for LSPs in the different layers
   [PCE-INTER-LAYER].

6.  Manageability Considerations

   Attention should be given during migration planning to how the
   network will be managed during and after migration. For example, will
   the LSRs of different protocol capabilities be managed separately or
   as one management domain. For example, in the Island Model, it is
   possible to consider managing islands of one capability separately
   from the surrounding sea. In the case of islands that have different
   switching capabilities, it is possible that the islands already have
   separate management in place before the migration: the resultant
   migrated network may seek to merge the management or to preserve the
   separation.

6.1. Control of Function and Policy

   The most critical control functionality to be applied is at the
   moment of changeover between different levels of protocol support.
   Such a change may be made without service halt or during a period of
   network maintenance.

   Where island boundaries exist, it must be possible to manage the
   relationships between protocols and to indicate which interfaces
   support which protocols on a border LSR. Further, island borders are
   a natural place to apply policy, and management should allow
   configuration of such policies.

 Shiomoto                                                      [Page 13]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


6.2. Information and Data Models

   No special information or data models are required to support
   migration, but note that migration in the control plane implies
   migration from MPLS management tools to GMPLS management tools.
   During migration, therefore, it may be necessary for LSRs and
   management applications to support both MPLS and GMPLS management
   data.

   The GMPLS MIB modules are designed to allow support of the MPLS
   protocols and built on the MPLS MIB modules through extensions and
   augmentations. This may make it possible to migrate management
   applications ahead of the LSRs that they manage.

6.3. Liveness Detection and Monitoring

   Migration will not impose additional issues for OAM above those that
   already exist for inter-domain OAM and for OAM across multiple
   switching capabilities.

   Note, however, that if a flat PSC MPLS network is migrated using the
   island model, and is treated as a layered network using tunnels to
   connect across GMPLS islands, then requirements for a multi-layer OAM
   technique may be introduced into what was previously defined in the
   flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking
   will need further consideration.

6.4. Verifying Correct Operation

   The concerns for verifying correct operation (and in particular
   correct connectivity) are the same as for liveness detection and
   monitoring. Specifically, the process of migration may introduce
   tunneling or stitching [STITCH] into what was previously a flat
   network.

6.5. Requirements on Other Protocols and Functional Components

   No particular requirements are introduced on other protocols. As it
   has been observed, the management components may need to migrate in
   step with the control plane components, but this does not impact the
   management protocols, just the data that they carry.

   It should also be observed that providing signaling and routing
   connectivity across a migration island in support of a layered
   architecture may require the use of protocol tunnels (such as GRE)
   between island border nodes. Such tunnels may impose additional
   configuration requirements at the border nodes.



 Shiomoto                                                      [Page 14]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


6.6. Impact on Network Operation

   The process of migration is likely to have significant impact on
   network operation while migration is in progress. The main objective
   of migration planning should be to reduce the impact on network
   operation and on the services perceived by the network users.

   To this end, planners should consider reducing the number of
   migration steps that they perform, and minimizing the number of
   migration islands that are created.

   A network manager may prefer the island model especially when
   migration will extend over a significant operational period because
   it allows the different network islands to be administered as
   separate management domains. This is particularly the case in the
   overlay, augmented network and border peer models where the details
   of the protocol islands remain hidden from the surrounding LSRs.

6.7. Other Considerations

   A migration strategy may also imply moving an MPLS state to a GMPLS
   state for an in-service LSP. This may arise once all of the LSRs
   along the path of the LSP have been updated to be both MPLS and
   GMPLS-capable. Signaling mechanisms to achieve the replacement of an
   MPLS LSP with a GMPLS LSP without disrupting traffic exist through
   make-before-break procedures [RFC3209] and [RFC3473], and should be
   carefully managed under operator control.



7. Security Considerations

   Security and confidentiality is often applied (and attacked) at
   administrative boundaries. Some of the models described in this
   document introduce such boundaries, for example between MPLS and
   GMPLS islands. These boundaries offer the possibility of applying or
   modifying the security as when crossing an IGP area or AS boundary,
   even though these island boundaries might lie within an IGP area or
   AS.

   No changes are proposed to the security procedures built into MPLS
   and GMPLS signaling and routing. GMPLS signaling and routing inherit
   their security mechanisms from MPLS signaling and routing without any
   changes. Hence, there will be no additional issues with security in
   interworking scenarios. Further, since the MPLS and GMPLS signaling
   and routing security is provided on a hop-by-hop basis, and since all
   signaling and routing exchanges described in this document for use



 Shiomoto                                                      [Page 15]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008


   between any pair of LSRs are based on either MPLS or GMPLS, there are
   no changes necessary to the security procedures.

8. IANA Considerations

   This informational framework document makes no requests for IANA
   action.

9. Acknowledgements

   The authors are grateful to Daisaku Shimazaki for discussion during
   initial work on this document. The authors are grateful to Dean Cheng
   and Adrian Farrel for their valuable comments.

10. Editor's Addresses

   Kohei Shiomoto, Editor
   NTT
   Midori 3-9-11
   Musashino, Tokyo 180-8585, Japan
   Phone: +81 422 59 4402
   Email: shiomoto.kohei@lab.ntt.co.jp

11. Authors' Addresses

   Dimitri Papadimitriou
   Alcatel
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240 8491
   Email: dimitri.papadimitriou@alcatel-lucent.be

   Jean-Louis Le Roux
   France Telecom
   av Pierre Marzin 22300
   Lannion, France
   Phone: +33 2 96 05 30 20
   Email: jeanlouis.leroux@orange-ftgroup.com

   Deborah Brungard
   AT&T
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ 07748, USA
   Phone: +1 732 420 1573
   Email: dbrungard@att.com

   Zafar Alli
   Cisco Systems, Inc.
   EMail: zali@cisco.com

 Shiomoto                                                      [Page 16]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460, JAPAN
   Phone: +81-3-6678-3103
   Email: ke-kumaki@kddi.com

   Eiji Oki
   NTT
   Midori 3-9-11
   Musashino, Tokyo 180-8585, Japan
   Phone: +81 422 59 3441
   Email: oki.eiji@lab.ntt.co.jp

   Ichiro Inoue
   NTT
   Midori 3-9-11
   Musashino, Tokyo 180-8585, Japan
   Phone: +81 422 59 3441
   Email: inoue.ichiro@lab.ntt.co.jp

   Tomohiro Otani
   KDDI Laboratories
   Email: otani@kddilabs.jp


12. References

12.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," BCP 14, IETF RFC 2119, March 1997.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
             Tunnels", RFC 3209, December 2001.

   [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.

   [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
             (TE) Extensions to OSPF Version 2", RFC 3630, September
             2003.

   [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
             System (IS-IS) Extensions for Traffic Engineering (TE)",
             RFC 3784, June 2004.


 Shiomoto                                                      [Page 17]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

   [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
             Architecture", RFC 3945, October 2004.

   [RFC4872] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), "
             RSVP-TE Extensions in support of End-to-End Generalized
             Multi-Protocol Label Switching (GMPLS)-based Recovery",
             RFC4872, May 2007.

   [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
             "GMPLS Based Segment Recovery", RFC 4873, May 2007.

   [RFC5073] Vasseur, Le Roux, editors, "IGP Routing Protocol
             Extensions for Discovery of Traffic Engineering Node
             Capabilities", RFC 5073, Decemer 2007.


12.2. Informative References

   [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP)
             Hierarchy with Generalized Multi-Protocol Label Switching
             (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for
             Inter-Domain Multiprotocol Label Switching Traffic
             Engineering", RFC4726, November 2006.

   [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
             M., Brungard, D., "Requirements for GMPLS-based multi-
             region and multi-layer networks (MRN/MLN)", draft-ietf-
             ccamp-gmpls-mln-reqs, work in progress.

   [MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to
             Support operation of MPLS-TE over GMPLS networks", draft-
             ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress.

   [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework
             for PCE-Based Inter-Layer MPLS and GMPLS Traffic
             Engineering," draft-ietf-pce-inter-layer-frwk, work in
             progress.

   [STITCH]  Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching
             with Generalized MPLS Traffic Engineering", draft-ietf-
             ccamp-lsp-stitching, work in progress.





 Shiomoto                                                      [Page 18]

       draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05        January 2008

13. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.

14. 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.












 Shiomoto                                                      [Page 19]


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