Network Working Group                               Kohei Shiomoto(NTT)
     Internet Draft                           Dimitri Papadimitriou(Alcatel)
     Proposed Category: Informational     Jean-Louis Le Roux(France Telecom)
     Expires: October 2006                           Deborah Brungard (AT&T)
                                                         Kenji Kumaki (KDDI)
                                      Zafar Ali (Cisco)
                                                               Eiji Oki(NTT)
                                                           Ichiro Inoue(NTT)
                                                       Tomohiro Otani (KDDI)
                      Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS MPLS-TE to GMPLS migration
                  draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt
                  draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt

     Status of this Memo

        By submitting this Internet-Draft, each author represents that any
        applicable patent or other IPR claims of which he or she is aware
        have been or will be disclosed, and any of which he or she becomes
        aware will be disclosed, in accordance with Section 6 of BCP 79.

        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups.  Note that
        other groups may also distribute working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time.  It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."

        The list of current Internet-Drafts can be accessed at

        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed at

        http://www.ietf.org/shadow.html.

     Abstract

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

        In the course of migration, policy.

        This document presents several interworking cases may exist
        where MPLS and GMPLS devices or networks must coexist. During the migration process, standard interworking functions are needed models and strategies for
        migrating from MPLS-TE to
        allow graceful deployment of GMPLS technologies while keeping
        existing IP/MPLS networks unaffected.

        Since GMPLS signaling and routing protocols are different from the
        MPLS control protocols, notes that in order for MPLS and GMPLS to interwork, we
        need mechanisms to compensate for the differences between MPLS and
        GMPLS. This document provides a landscape course of techniques, practices
        migration MPLS-TE and an overview of GMPLS devices or networks may coexist which may
        require interworking between MPLS MPLS-TE and GMPLS in support protocols. The
        applicability? of
        IP/MPLS to GMPLS migration, which the interworking that is also beneficial for graceful
        deployment required is discussed as
        it appears to influence the choice of GMPLS technologies into existing IP/MPLS networks. We
        discuss issues, models, a migration scenarios, operation, and
        requirements. strategy.

     Table of Contents

        1. Introduction...................................................3
        2. Conventions Used in This Document..............................4 Document..............................3
        3. Motivations for Migration......................................4
        4. MPLS to GMPLS migration........................................5
           4.1. Migration models..........................................5
              4.1.1. Models.................................5
           4.1. Island model.........................................5 model..............................................5
              4.1.1. Balanced Islands.....................................6
              4.1.2. Unbalanced Islands...................................6
           4.2. Integrated model.....................................6
              4.1.3. model..........................................7
           4.3. Phased model.........................................7
           4.2. Migration strategies......................................8 model..............................................8
        5. Island model interworking cases................................9
           5.1. MPLS-GMPLS(PSC)-MPLS Islands..............................9
           5.2. MPLS-GMPLS(non-PSC)-MPLS Islands..........................9
           5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands........................9
           5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands................9
           5.5. GMPLS(PSC)-MPLS Migration Strategies and MPLS-GMPLS(PSC) Islands...............9
        6. Interworking issues Solutions.............................9
           5.1. Solutions Toolkit.........................................9
              5.1.1. Layered Networks....................................10
              -  The overlay model preserves strict separation of routing
              information between MPLS and GMPLS....................10
           6.1. Signaling................................................11
              6.1.1. GMPLS specific RSVP objects network layers. This is suitable for the
              balanced island model and Messages............11
                 6.1.1.1. Direct interworking............................12
                 6.1.1.2. Mapping........................................13
                 6.1.1.3. Transfer.......................................13
              6.1.2. Bidirectional LSP...................................13
              6.1.3. Failure recovery....................................14
           6.2. Routing..................................................14
              6.2.1. Interworking of Routing Protocols...................15
              6.2.2. Mapping there is no requirement to handle
              routing interworking. Signaling interworking is still required
              as described for the peer model.  The overlay model requires
              the establishment of control plane connectivity for the higher
              layer across the lower layer...............................10
              5.1.2. Routing Protocols........................15
           6.3. Layered Networks.........................................15
              6.3.1. Peer Model..........................................17
              6.3.2. Overlay Model.......................................18
              6.3.3. Augmented Model.....................................18
        7. Interworking................................11
              5.1.3. Signaling Interworking..............................12
        6. Manageability Considerations..................................18
           7.1. Considerations..................................13
           6.1. Control of Function and Policy...........................19
           7.2. Policy...........................13
           6.2. Information and Data Models..............................19
           7.3. Models..............................14
           6.3. Liveness Detection and Monitoring........................19
           7.4. Monitoring........................14
           6.4. Verifying Correct Operation..............................20
           7.5. Operation..............................14
           6.5. Requirements on Other Protocols and Functional Components20
           7.6. Components14
           6.6. Impact on Network Operation..............................20
           7.7. Operation..............................15
           6.7. Other Considerations.....................................20
        8. Considerations.....................................15
        7. Security Considerations.......................................20 Considerations.......................................15
        8. Recommendations for Migration.................................16
        9. IANA Considerations...........................................21 Considerations...........................................16
        10. Full Copyright Statement.....................................21 Statement.....................................16
        11. Intellectual Property........................................21 Property........................................16
        12. Acknowledgements.............................................22 Acknowledgements.............................................17
        13. Authors' Addresses...........................................23 Addresses...........................................18
        14. References...................................................24 References...................................................19
           14.1. Normative References....................................24 References....................................19
           14.2. Informative References..................................24 References..................................20
     1. Introduction

        MPLS

        Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to GMPLS
        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 is, therefore, a packet-switching network.

        There are several motivations for such migration and they focus
        mainly on the desire to take advantage of new features and functions
        that have been added to the GMPLS protocols but which are not present
        in MPLS. MPLS-TE.

        Although an appropriate migration strategy can be selected based on
        various factors including the service provider's network deployment
        plan, customer demand, available deployed network equipment implementation, equipments, operational
        policy, etc, etc., the smooth transition mechanism should be
        investigated from the mechanisms used should also provide
        consistent operation of GMPLS networks, networks while
        less impacting minimizing the impact on
        the operation of existing MPLS MPLS-TE networks.

        In the course of migration, several interworking cases may arise
        where MPLS migration MPLS-TE and GMPLS devices or networks must may
        need to coexist. Such cases may occur as parts of the network are converted
        migrated from MPLS MPLS-TE protocols to GMPLS protocols, or protocols. Additionally, as
        part of the preparation for migrating a packet-switching network from
        MPLS-TE to GMPLS, it may arise if be desirable to first migrate a lower layer lower-layer
        network is made GMPLS-
        capable (from from having no MPLS or control plane to using a GMPLS control plane) in advance of
        the migration of plane, and
        this can also lead to the higher layer network. need for MPLS-TE/GMPLS interworking.

        This document examines describes several migration strategies and shows the
        interworking scenarios that arise during migration, and examines the
        implications for network deployments and for protocol usage. Since
        GMPLS signaling and routing protocols are different from the MPLS MPLS-TE
        control protocols, interworking between MPLS MPLS-TE and GMPLS networks or
        network elements needs mechanisms to compensate for the differences. This document provides a framework for MPLS and
        GMPLS interworking in support of migration from IP/MPLS to GMPLS by
        discussing issues, models, migration scenarios, operation and
        requirements. Solutions for interworking MPLS and GMPLS will be
        developed in companion documents.

        Note that both MPLS MPLS-TE and GMPLS protocols can co-exist as "ships in the
        night" without any interworking issue. This document addresses
        interworking to allow migration from MPLS to GMPLS. We should also

        Also note that, in this document, a MPLS control plane means a the term "MPLS" is used to refer to
        MPLS-TE
        control plane (RSVP-TE [RFC3209], IGP-TE [RFC3630] [RFC3784]), protocols only ([RFC3209], [RFC3630], [RFC3473]) and
        not a LDP-based control plane [RFC3036]. This document does not
        address excludes
        other MPLS protocols such as the migration from LDP controlled Label Distribution Protocol (LDP).TE
        functionalities of MPLS networks could be migrated to G/MPLS
        RSVP-TE at this moment, GMPLS-TE, but may consider it in the future version. non-TE
        functionalities could not.

     2. Conventions Used in This Document

        The

        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]. [RFC2119] in order to
        clarify the recommendations that are made.

        In the rest of this document, the term GMPLS "GMPLS" includes both packet
        switch
        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). If non-TE MPLS is intended, it is explicitly
        indicated.

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

     3. Motivations for Migration

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

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

        o  To add all GMPLS capabilities to an existing MPLS PSC network.

        o  To add a GMPLS network without sacrificing the upgrading existing MPLS PSC
           LSR implementation. LSRs.

        o  To pick up specific GMPLS features and operate them within an MPLS
           PSC network.

        o  To allow MPLS capable existing MPLS-capable LSRs to interoperate with new LSRs
           that only support GMPLS.

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

        o  To build integrated PSC and non-PSC networks where the non-PSC
           networks can only be controlled by GMPLS since MPLS does not
           operate in non-PSC networks.

     4.

        It must be understood that the ultimate objective of migration from
        MPLS to GMPLS migration

     4.1. Migration models

        MPLS to GMPLS migration is a that all LSRs and the entire network end up running
        GMPLS protocols. During this process various interim situations may
        exist giving rise to the interworking situations described in this
        document. Those interim situations may persist for considerable
        periods of evolving an MPLS-TE-based
        control plane time, but the ultimate objective is not to a GMPLS-based control plane. preserve these
        situations, and for the purpose of this document, they should be
        considered as temporary.

     4. MPLS to GMPLS Migration Models

        Three migration models are considered as described below. Practically speaking, multiple Multiple migration models
        may be deployed at co-exists in the same time.

     4.1.1. network.

     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.

        The most obvious example is to consider an island of GMPLS-capable
        nodes which is introduced into a legacy MPLS network. Such an island
        might be composed of newly added GMPLS network 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) supports an MPLS PSC network. During the
        process of migrating from both networks to GMPLS, the situation might
        arise where the lower-layer network has been
        might be migrated and operates
        GMPLS, but the packet network still operates MPLS. 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 run 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 each case, case 1 the interworking behavior is examined based on whether the
        GMPLS islands are PSC or non-PSC. These scenarios are considered
        further in section 5.

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

        ................. ..............................  ..........................  ..................
        :      MPLS      :  :          GMPLS         :  :     MPLS       :
        :+---+  +---+   +----+         +---+          +---+          +---+        +----+   +---+  +---+:
        :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
        :+---+  +---+   +---+   +----+         +-+-+          +---+        +----+   +---+  +---+:
        :      ________/ :  :  ________/  _______/  |   ________/   _____ / :  :  ________/     :
        :     /          :  : /          |  /        :  : /              :
        :+---+  +---+   +---+   +----+         +-+-+          +---+        +----+   +---+  +---+:
        :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |__|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. Available strategies include:

        - tunneling the signaling across the island network using LSP
          nesting or stitching (only with GMPLS-PSC)

        - protocol interworking or mapping (only with GMPLS-PSC)

     4.1.2. Integrated model

        The second model involves a more integrated migration strategy. New
        devices that Unbalanced Islands

        As just mentioned, there are capable two island interworking models
        consisting of operating both MPLS abutting islands. GMPLS(PSC)-MPLS and GMPLS protocols MPLS-GMPLS(PSC)
        islands cases are introduced into the MPLS network. We should note that likely to arise where the GMPLS-
        capable device may migration strategy is not support
        based on a full set core infrastructure, but has edge nodes (ingress or
        egress) located in islands of MPLS functionalities.
        For example, different capabilities.

        In this case, an LSP starts or ends in a GMPLS-capable device may support protection GMPLS (PSC) island and
        restoration mechanisms
        correspondingly ends or starts in [E2E-recovery, SEGMENT-recovery] but may
        not support an MPLS island. This mode of
        operation can only be addressed using protocol interworking or
        mapping. Figure 2 shows the fast reroute mechanism defined reference model for this migration
        scenario. Head-end and tail-end LSR are in [RFC4090]. This
        fact highlights distinct control plane
        clouds.

             ............................  .............................
             :            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 difference between directionality of the island LSP, and the integrated
        models. That is to say, 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 island model, a GMPLS node GMPLS-capable device does not support the MPLS features (signaling code points, FRR, etc),
        protocols except border nodes , while in the integrated model, model there
        are two types of node present during migration:

           - those that support MPLS only (legacy nodes)

           - those that support MPLS and GMPLS.

        In the new device supports island model only island border nodes may support both MPLS
        and GMPLS
        features.

        Further, while in the integrated model all GMPLS LSRs also support
        MPLS.

        That is, in integrated model, existing MPLS devices will be are upgraded to
        support both MPLS and GMPLS. The network continues to operate providing provide MPLS
        services,
        but and also offers GMPLS services. So, where one end point of
        a service is a legacy MPLS node, the service can be provided is supported using MPLS
        protocols. Similarly, where the selected path between end points
        traverses a legacy node that is not GMPLS-capable, MPLS protocols are
        used. But where the service can be provided using only GMPLS functionality,
        it may be routed accordingly over only such MPLS-GMPLS-capable
        devices GMPLS-capable
        nodes, 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 (signaling code points, FRR, etc) may be turned off, and no new devices need to
        support these elements.

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

        The integrated migration model results in a single network in which
        both MPLS-capable and MPLS-GMPLS-capable LSRs co-exist. Some LSRs
        will be capable of only MPLS, and some of both MPLS and GMPLS. The
        migration strategy here involves introducing MPLS-GMPLS-capable LSRs
        into an existing MPLS-capable network (i.e. upgrading MPLS LSRS)
        until all LSRs are MPLS-GMPLS-capable at which time all MPLS
        functionalities can be disabled, and there are no interworking issues
        in the data plane. In the control plane, the migration issues concern
        the separation of MPLS and GMPLS protocols, and the choice of routes
        that may be signaled with only one protocol.

     4.1.3.

     4.3. Phased model

        The phased model introduces GMPLS features and protocol elements into
        an MPLS network one by one. For example, some object or sub-object
        (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.

        The interoperability concerns (e.g. LABEL REQUEST object [RFC3473] 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 LABEL object [RFC3209], for RSVP-TE signaling) though test
        the full GMPLS function.

        Interoperability concerns are exacerbated by this migration model,
        unless all LSRs in the network are updated simultaneously. 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 in the role of a GMPLS LSR as
        described in the previous
        sections, while interworking between a hybrid LSR sections and a GMPLS LSR puts the hybrid in the role of
        an MPLS LSR. The potential for different hybrids within the network
        will complicate matters considerably. Thus, this piecemeal migration from MPLS to GMPLS is
        NOT RECOMMENDED.

     4.2.

     5. Migration strategies Strategies and Solutions

        An appropriate migration strategy is selected by a network operator
        based on various factors including the service provider's network deployment
        plan, customer demand, available 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 or capability, partial
        upgrade to include specific GMPLS features features, or no change of to existing
        IP/MPLS networks), and upon the immediate objectives (full, phased,
        or staged upgrade).

        For PSC networks supported 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
        migrated to GMPLS. This might arise when, in order to expand the
        network capacity, GMPLS-based non-PSC sub-networks are introduced
        into or underneath 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 for PSC and non-PSC networks is to migrate from
        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. Island model interworking cases

     5.1. MPLS-GMPLS(PSC)-MPLS Islands

        The migration of an MPLS-based packet network to become a GMPLS
        (PSC)-based network may be performed to provide GMPLS-based advanced
        features Solutions Toolkit

        As described in the network, or to facilitate interworking with previous sections, an essential part of a GMPLS-
        based optical core network.

        The
        migration may give rise to islands of and deployment strategy is how the MPLS and GMPLS support within a sea or hybrid
        LSRs interwork. This section sets out some of the alternatives for
        achieving interworking between MPLS nodes such that an end-to-end LSP begins and ends on MPLS-
        capable LSRs. The GMPLS PSC island may be used to "hide" islands GMPLS, and points out some of
        GMPLS non-PSC functionality
        the issues that are completely contained within need to be addressed if the
        GMPLS PSC islands. alternatives are adopted.
        This would protect the MPLS LSRs from having document does not describe solutions to be
        aware of non-PSC technologies.

     5.2.  MPLS-GMPLS(non-PSC)-MPLS Islands

        The introduction of a GMPLS-based controlled optical core network these issues.

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

     5.1.1. Layered Networks

        In the balanced island model, LSP tunnels [RFC4206] is an example that may
        give rise a solution to this scenario. Until
        carry the MPLS network end-to-end LSPs across islands of incompatible nodes.
        Network layering is upgraded often used to separate domains of different data
        plane technology. It can also be
        GMPLS-capable, the used to separate domains of
        different control plane technology (such as MPLS and GMPLS networks must interwork. The
        interworking challenges may protocols),
        and the solutions developed for multiple data plane technologies can
        be reduced by wrapping usefully applied to this situation [RFC3945], [RFC4206], and
        [INTER-DOM]. [MLN-REQ] gives a discussion of the non-PSC requirements for
        multi-layered networks.

        The GMPLS
        island entirely within a architecture [RFC3945] identifies three architectural
        models for supporting multi-layer GMPLS PSC island as described in the
        previous section.

     5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands

        This case might arise as networks, and these models
        may be applied to the result separation of installing new GMPLS-capable
        islands around a legacy MPLS network, or as and GMPLS control plane
        islands.

        - In the result peer model, both MPLS and GMPLS nodes run the same routing
          instance, and routing advertisements from within islands of controlled
        migration one
          level of some islands protocol support are distributed to become GMPLS-capable.

     5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands the whole network.
          This case is out achievable only as described in section 5.1.2 either by
          direct distribution or by mapping of scope for this document. Since parameters.

          Signaling in the MPLS island is
        necessarily packet capable (i.e. PSC), this scenario requires that
        non-PSC peer model may result in contiguous LSPs,
          stitched LSPs (only for GMPLS PSC), or nested LSPs. If the network
          islands are carried across a PSC network. Such a situation does
        not arise through simple control plane migration, although non-PSC then the
        interworking scenario might occur for other reasons, and techniques of [MLN] may be supported,
        for example, by pseudo wires.

     5.5. GMPLS(PSC)-MPLS applied,
          and MPLS-GMPLS(PSC) Islands

        These cases are likely these techniques may be extrapolated to arise networks where the migration strategy is not
        based on a core infrastructure, but has edge all
          nodes (ingress or
        egress) located in islands of different capabilities.

        In this case, an LSP starts or ends in are PSC, but where there is a GMPLS (PSC) island and
        correspondingly ends or starts difference in an MPLS island. Some signaling and
          protocols.

        - The overlay model preserves strict separation of routing conversion
          information between network layers. This is required on island border LSRs. Figure 2 shows suitable for the reference
          balanced island model for this migration scenario. Head-end and tail-
        end LSR are in distinct control plane clouds.

        Since both islands are PSC there is no data plane conversion at requirement to handle
          routing interworking. Even though the
        island boundaries. However, from a control plane point of view this overlay model may prove challenging because the protocols must share or
        convert preserves
          separation of signaling information between the islands rather than tunnel it across
        an island.

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

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

                       Figure 2 GMPLS-MPLS interworking model.

        It is also important to underline that this scenario is also impacted
        by the directionality of the LSP, and the direction network layers, there
          may be some interaction in which the LSP
        is established. Indeed, a unidirectional packet LSP from R1 to G5 is
        more easily accommodated at G1 than a bidirectional PSC LSP from G5
        to R1.

     6. Interworking issues signaling between MPLS and GMPLS

        As described in network layers.

          The overlay model requires the previous sections, interworking between MPLS and
        GMPLS may form an essential part of a migration and deployment
        strategy. This section sets out some establishment of the alternatives control plane
          connectivity for
        achieving interworking between MPLS and GMPLS, and points out some of
        the issues that need to be addressed if the alternatives are adopted.
        This document does not describe solutions to these issues.

        Note that it is possible to consider upgrading higher layer across the lower layer.

        - The augmented model allows limited routing and
        signaling capabilities of LSRs exchange from MPLS to GMPLS separately.

     6.1. Signaling

        Signaling protocols are used the lower
          layer network to establish LSPs and are the principal
        concern for interworking. This section outlines some of the issues
        that may arise when MPLS and GMPLS signaling interworking is
        attempted. Solutions to these issues will be described in separate
        documents, but possibly rely on tunneling techniques (as described
        above) or message mapping.

     6.1.1. GMPLS specific RSVP objects and Messages

        GMPLS RSVP-TE signaling ([RFC3473]) introduces new RSVP-TE objects,
        and their associated procedures, that are not processed/generated by
        MPLS LSRs. Clearly an MPLS LSR cannot be expected to originate LSPs
        that use these objects and will, therefore, not have access to the
        additional GMPLS functions. However, the new RSVP-TE objects listed
        below need to be handled in interworking scenarios where the LSP
        ingress and/or egress is GMPLS-capable, and MPLS LSRs are required to
        process the signaling messages:

        o  The (Generalized) Label Request object (new C-Type), used to
           identify the LSP encoding type, the switching type and the
           generalized protocol ID (G-PID) associated with the LSP.

        o  The (Generalized) Label object (new C-Type)

        o  The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
           ERO/RRO sub objects that handle the Control plane/Data plane
           separation in GMPLS network.

        o  The Suggested Label Object, used to reduce LSP setup delays.

        o  The Label Set Object, used to restrict label allocation to a set
           of labels, (particularly useful for wavelength conversion
           incapable nodes)

        o  The Upstream Label Object, used for bidirectional LSP setup

        o  The Restart Cap object, used for graceful restart.

        o  The Admin Status object, used for LSP administration, and
           particularly for graceful LSP teardown.

        o  The Recovery Label object used for Graceful Restart

        o  The Notify Request object used to solicit notification of errors
           and events.

        o  The Protection and Association objects used for LSP recovery

        Future GMPLS extensions are likely to add further new objects.

        Some of these objects can be passed transparently by MPLS LSRs to
        carry them across MPLS islands because their C-Nums are of the form
        11bbbbbb, but others would cause an MPLS LSR to reject the message
        that carries them because their C-Nums are of the form 0bbbbbbb.

        Even when objects are inherited from MPLS by GMPLS they can be
        expected to cause problems. For example, the Label object in GMPLS
        uses a new C-Type to indicate 'Generalized Label'. This C-Type is
        unknown to MPLS LSRs that will reject any message carrying it.

        GMPLS also introduces new message flags and fields (including new
        sub-objects and TLVs) that will have no meaning to MPLS LSRs. This
        data will normally be forwarded untouched by transit MPLS LSRs, but
        they cannot be expected to act on it.

        Also GMPLS introduces two new messages, the Notify message, and the
        Recovery Path message that are not supported by MPLS nodes.

     6.1.1.1. Direct interworking

        A possible solution is to allow direct signaling between MPLS and
        GMPLS LSRs. However, a fundamental issue is that MPLS and GMPLS use
        incompatible code points (C-Types) to request labels (LABEL_REQUEST
        and GENERALIZED_LABEL_REQUEST) and to signal labels (LABEL and
        GENERALIZED LABEL).

        Note, however, that the Phased Model may offer a solution that
        resembles signaling interworking. In this approach LSRs are upgraded
        to support some GMPLS features but continue to use MPLS code points.

        MPLS LSPs may be established across an island of enhanced signaling
        capabilities, where some GMPLS features have been added to MPLS LSRs.
        This may be relatively simple, and indeed may also be compatible with
        the Integrated Model.

        On the other hand, enhanced MPLS LSPs (i.e. LSPs signaled using some
        GMPLS features) may be carried across an MPLS island. Success in this
        case will depend on the particular GMPLS features in use (some
        features, such as bi-directionality, cannot be achieved by a native
        MPLS network without additional assistance) and the code points that
        are used to signal the features (some objects can be carried
        transparently across an MPLS network by virtue of their Class Number
        encoding, but others will be silently dropped or will cause the
        message to be rejected).

     6.1.1.2. Mapping

        An alternative to interworking signaling protocols is to map each
        other between MPLS and GMPLS. That is, to convert the objects carried
        in one message to different objects carried in the message that is
        actually sent. This mapping would be performed in an upgraded LSR at
        island borders since existing LSRs would not be aware of the required
        mappings. This mapping is local decision and should be pre-configured
        or dynamically done at border nodes.

        It would be relatively simple to map signaling messages for LSPs
        initiated on MPLS LSRs (MPLS-GMPLS-MPLS and MPLS-GMPLS) since the
        LSPs will not need to implement advanced GMPLS features. On the other
        hand, however, mapping signaling messages for LSPs initiated by a
        GMPLS LSR (GMPLS-MPLS-GMPLS and GMPLS-MPLS) may be considerably
        harder depending on the GMPLS features demanded by the LSP. For
        example, if the GMPLS LSP is bidirectional, additional function will
        be needed at the border LSR that maps the signaling messages in order
        to create a pair of unidirectional MPLS LSPs to carry the
        bidirectional service across the MPLS network that does not have
        native support for bidirectionality. Indeed, in the GMPLS-MPLS case,
        a bidirectional service would not be possible unless the egress MPLS
        LSR was also upgraded to provide this function.

     6.1.1.3. Transfer

        A migration strategy may also imply moving an MPLS state to a GMPLS
        state. For instance, a LSR hosting MPLS states is upgraded such that
        its controller can run both MPLS and GMPLS. In this case, a signaling
        mechanism is needed to migrate from the MPLS LSP state to the GMPLS
        state.

     6.1.2. Bidirectional LSP

        GMPLS provides bidirectional LSP setup - a single signaling message
        exchange manages the bidirectional LSP, and forward and reverse data
        paths follow the same route in the GMPLS network. There is no
        equivalent in MPLS networks: forward and backward LSPs must be
        created in different signaling sessions - the route taken by those
        LSPs may be different from each other, and their sessions are treated
        separately. Common routes and fate sharing require additional,
        higher-level coordination in MPLS.

        If MPLS and GMPLS networks are inter-connected, bidirectional LSPs
        from the GMPLS network need to be carried in the MPLS network.

        Note that this issue arises only in the cases where an LSP is
        originated by GMPLS-capable LSRs. In other words, it applies only to
        the GMPLS-MPLS-GMPLS and GMPLS-MPLS island model.

        Note that the island border LSRs will bear the responsibility for
        achieving the bidirectional service across the central MPLS island.

        In the MPLS-GMPLS-MPLS and MPLS-GMPLS models, the ingress LSR is
        unaware of the concept of a bidirectional LSP and cannot attempt the
        service even if it could find some way to request it through the
        network. In the case of GMPLS-MPLS, a similar issue exists because
        the egress MPLS-capable LSR is unaware of the concept of
        bidirectional LSPs.

     6.1.3. Failure recovery

        Failure recovery mechanism is provided using different mechanisms in
        MPLS (see [RFC4090]) and GMPLS (see [E2E-RECOVERY, SEGMENT-RECOVERY]).
        Local protection of island border nodes may be a particular problem.

     6.2. Routing

        Some attention should also be given to the use of routing protocols
        in interworking scenarios since this may allow routing information
        from islands to be visible within the surrounding seas.

        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" GMPLS LSRs as
        though they were PSC LSRs. They will also see other GMPLS information,
        but will ignore it, passing it transparently across the MPLS network
        for use by other GMPLS LSRs.

        This means that MPLS LSRs may use the MPLS information advertised by
        MPLS LSRs and GMPLS LSRs to compute a traffic-engineered explicit
        route across a mixed network. However, it is likely that a path
        computation component in an MPLS network will only be aware of MPLS
        TE information and will not understand concepts such as switching
        capability type. This may result in that an incorrect path will be
        computed for an e2e LSP from one MPLS island to another across a
        GMPLS island if different switching capabilities exist.

     6.2.1. Interworking of Routing Protocols

        GMPLS TE advertisements are based on MPLS TE advertisements with the
        addition of extra sub-TLVs. The processing rules for unknown TLVs
        mean that they can be ignored by a router, but must be forwarded when
        the Link State Advertisement (OSPF LSA or IS-IS LSP) is flooded.

        This means that MPLS and GMPLS LSRs may operate as routing peers, and
        will redistribute each other's TE information. MPLS LSRs will be
        granted full TE visibility at an MPLS level into GMPLS islands, while
        GMPLS LSRs will have limited (i.e. MPLS-level) TE visibility into
        MPLS islands.

        This type of routing exchange may be very useful in particular for
        MPLS-GMPLS-MPLS PSC networks. GMPLS LSRs, however, must either modify
        their computation algorithms or must generate appropriate defaults
        for GMPLS TE parameters that are not advertised by MPLS LSRs.

     6.2.2. Mapping of Routing Protocols

        The alternatives to interworking routing protocols are to impose
        protocol boundaries (such as routing area, AS boundaries) or to
        attempt to map the protocol advertisements as they cross island
        borders. This latter option is simple for advertisements coming from
        GMPLS islands since the GMPLS sub-TLVs may be discarded, but is
        pointless because those sub-TLVs are benign within the MPLS network
        and are impossible to accurately recreate on re-entry into a GMPLS
        network. On the other hand, advertisements initiated by MPLS LSRs
        could have default GMPLS sub-TLVs added when they are flooded into a
        GMPLS network. These defaults would be similar to those described in
        the previous section, and would have the advantage that GMPLS LSRs
        within the network (i.e. not border nodes) would not need to apply
        the defaults. Care is needed to ensure higher layer network. Generally speaking,
          this assumes that the mechanism for
        applying defaults is identical on all border nodes.

        Note that any alternative using routing protocol mapping relies on
        each border LSR knowing which neighbors are MPLS or GMPLS capable.

     6.3. Layered Networks

        In addition to the difference between MPLS and GMPLS protocols,
        control and data plane separation needs to be considered at the
        boundary of PSC and non-PSC domains.

        Note that the boundary nodes provide some form of PSC and non-PSC domains may filtering,
          mapping or may not be
        coincident with the boundary of MPLS and GMPLS domains. In the case
        where the boundaries are not coincident, the boundary between the PSC
        and non-PSC domains must exist in the GMPLS domain because the MPLS
        domain cannot support a non-PSC data plane. Here we distinguish two
        cases: interworking between PSC and non-PSC networks, and
        interworking between MPLS and GMPLS networks.

        Figure 3 shows the network model, where the ingress PSC domain and
        the egress PSC domains are interconnected via the transit non-PSC
        domain.

        ................. .............................. ..................
        : Ingress PSC   : :       Transit non-PSC      : :  Egress PSC    :
        :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
        :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
        :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
        :      ________/ : :  ________/  |   ________/ : :  ________/     :
        :     /          : : /           |  /          : : /              :
        :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
        :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
        :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
        :................: :...........................: :................:

                  Figure 3 Interworking aggregation of PSC and non-PSC domains.

        In routing information advertised from the PSC domain,
          lower layer network. This architectural model can also be used for
          balanced island model migrations. Signaling interworking is
          required as described for the control plane traffic (signaling and routing) peer model.

        - The border peer architecture model is carried in-band with data. defined in [MPLS-OVER-GMPLS].
          This means that there is fate sharing
        between a data link and the control traffic on modification of the link. On augmented model where the other
        hand, in layer
          border routers have visibility into both layers, but no routing
          information is otherwise exchanged between models. This
          architectural model is particularly suited to the non-PSC domain (TDM, LSC, MPLS-GMPLS-MPLS
          island model for PSC and FSC domains), where packet
        delineation non-PSC GMPLS islands.  Signaling
          interworking is not recognized, required as described for the peer model.

     5.1.2. Routing Interworking

        Migration strategies may necessitate some interworking between MPLS
        and in-band control channels cannot be
        terminated, dedicated control channels (separated from GMPLS routing protocols. GMPLS extends the data
        channels) are used. In TE information
        advertised by the IGPs to include non-PSC domain, the control channel can be
        logically or physically separated (i.e., in-fiber out-of-band or out-
        of-fiber out-of-bound) from information and extended
        PSC information. Because the data channel depending on GMPLS information is provided as
        additional TLVs that are carried along with the
        capabilities of 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 devices and for use by
        other GMPLS LSRs.

        - Routing separation is achieved in the operational requirements.

        A dedicated control channel must not be used to carry user data
        traffic. overlay, and border peer
          models. This is particularly important when convenient since only the control channels are
        of low capacity and are not designed to carry user traffic.

        A possible method border nodes need to protect the control plane channel be
          aware of a non-PSC
        domain the different protocol variants, and no mapping is that packets coming from PSC domains are not allowed
          required. It is suitable to use the control plane channel. The method, however, causes another
        problem: lack MPLS-GMPLS-MPLS and GMPLS-MPLS-
          GMPLS island migration models.

        - Direct distribution involves the flooding of signaling MPLS routing
          information into a GMPLS network, and GMPLS routing adjacencies across information
          into an MPLS network. The border nodes make no attempt to filter
          the non-PSC
        domain. information. This problem is explained using Fig. 3. LSAs in mode of operation relies on the egress PSC domain
        are fact that
          MPLS routers will ignore, but continue to flood, GMPLS routing
          information that they do not advertised in the ingress PSC domain unless understand. The presence of
          additional GMPLS routing
        adjacencies are established between information will not interfere with the PSC domain
          way that MPLS LSRs select routes, and non-PSC domain
        or unless routing adjacencies are established directly between PSC
        domains. Therefore the ingress LSR in the ingress PSC domain although this is not
        able to find the egress LSR a
          problem in the egress PSC domain unless these
        adjacencies are formed. The signaling messages are not passed across
        the a PSC-only network, it could cause problems in a peer
          architecture network that includes non-PSC domain between the ingress and the egress PSC domains
        unless nodes as the signaling adjacencies MPLS nodes
          are established between the PSC
        domain and not capable of determining the non-PSC domain or directly between PSC domains.

        Interworking between PSC and non-PSC networks can be regarded as a
        layered network. Layered networks are described in many places
        including [RFC3945] and [RFC4206]. [MRN-REQ] gives a good background
        and discusses some switching types of the requirements for multi-layered networks.

        Network layering is often used other
          LSRs and will attempt to separate domains of different data
        plane technology. It can also be used signal end-to-end LSPs assuming all LSRs
          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 PSC. This fact would require island border nodes to this situation.

        The GMPLS architecture [RFC3945] identifies three architectural
        models for supporting multi-layer take
          triggered action to set up tunnels across islands of different
          switching capabilities.

          GMPLS networks, and these models
        may LSRs might be applied to impacted by the separation absence of GMPLS-specific
          information in advertisements initiated by MPLS and LSRs. Specific
          procedures might be required to ensure consistent behavior by
          GMPLS control plane
        islands. The applicability of the different nodes. If this issue is addressed, then direct distribution
          can be used in all migration models to (except the
        three overlay and border
          peer architectural models may provide additional input to the choice
        of an architectural model.

     6.3.1. Peer Model

        In the peer model, both MPLS and GMPLS nodes run where the same routing
        instance and problem does not arise).

        - Protocol mapping converts routing advertisements, from within islands of advertisements so that they can
          be received in one level
        of protocol support are distributed to the whole network. This is
        achievable as described in section 6.2 either by direct distribution
        or by mapping of parameters.

        If the entire network (MPLS and GMPLS capable LSRs) is PSC, signaling
        may establish end-to-end LSPs using the techniques described transmitted in
        section 6.1. On the other hand, if the other. For
          example, a GMPLS network is of some other
        switching type, or if the protocol islands are managed as separate
        network layers, the signaling request can give rise to the creation routing advertisement could have all of a hierarchical LSP [RFC4206] or stitching segment [STITCH] that
        spans an island its
          GMPLS-specific information removed and is triggered when the LSP request reaches the
        island border. The end-to-end LSP from the higher layer network (the
        protocol sea) is carried across the lower layer network (the protocol
        island) by the tunnel or stitching segment.

        Note that could be flooded as an MPLS sea is not capable
          advertisement. This mode of determining whether the
        entire network is interworking would require careful
          standardization of the same switching type and will consequently
        attempt to signal end-to-end LSPs assuming them correct behavior especially where an MPLS
          advertisement requires default values of GMPLS-specific fields to
          be PSC all generated before the way. 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 requires that the island border take option for routing interworking during migration is NOT
          RECOMMENDED for any migration model.

        - Ships in the appropriate action night refers to
        set up tunnels across islands of different switching capabilities.

     6.3.2. Overlay Model

        The overlay model preserves strict separation a mode of operation where both MPLS
          and GMPLS routing information
        between network layers. Thus, protocol variants are operated in the interworking case, there is no
        requirement to handle routing interworking. Signaling interworking is
        still required same
          network at the same time as described in section 6.1.

        Note, however, that there is a requirement to create signaling higher
        layer adjacencies between island border nodes, separate routing protocol instances.
          The two instances are independent and that it is highly
        desirable are used to create routing
          adjacencies in between LSRs of the same way. Such
        adjacencies type. This mode of operation
          may use be appropriate to the control plane 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 simple changes in the lower layer network encodings and
        be independent codepoints used
        by MPLS and GMPLS signaling, but also because of changes in function
        levels provided by MPLS and GMPLS.

        - Tunneling and stitching (GMPLS-PSC case) mechanisms are a good way
          to avoid any requirement for direct protocol interworking during
          migration in the existence 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 data plane connectivity across the
        lower layer network. Care may features must
          be required carried across a network designed to prevent the swamping support a different set of
          features. In general, this is easily achieved for the lower layer control plane when it has limited capacity.
        Alternatively, such adjacencies MPLS-GMPLS-
          MPLS model, but may rely on the existence of data
        plane connectivity across be hard to achieve in the lower layer network.

     6.3.3. Augmented Model

        The augmented GMPLS-MPLS-GMPLS
          model allows limited routing exchange from the lower
        layer network to for example, when end-to-end bidirectional LSPs are
          requested since the higher layer network. Generally speaking, this
        assumes MPLS island does not support bidirectional
          LSPs.

          Note that tunneling and stitching are not available in unbalanced
          island models because in these cases the border nodes provide some form of filtering, LSP end points use
          different protocol variants.

        - Protocol mapping
        or aggregation is the conversion of signaling messages between
          MPLS and GMPLS variants. This mechanism requires careful
          documentation of routing information advertised from the lower layer
        network, protocol fields and this how they are mapped, but
          is compatible with the mechanisms described relatively simple in
        section 6.2.2.

        Note however, that part of this assumption allows the border nodes to
        have full visibility into both MPLS-GMPLS unbalanced island model.
          However, the higher and lower layer networks
        without further advertising MPLS-GMPLS island model may manifest as the information from GMPLS-
          MPLS model for LSPs signaled in the lower layer
        network opposite direction and this
          will lead to considerable complications for providing GMPLS
          services over the higher layer network meaning MPLS island and for terminating those services
          at an egress LSR that no mapping or
        interworking of routing protocols is required. Particularly, this
        includes 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 or mis-requests.

        - Ships in the case where night could be used in the integrated migration model
          to allow MPLS-capable LSRs to establish LSPs using MPLS signaling
          protocols and GMPLS clouds run distinct routing
        instances, and the border nodes run both routing instances.

        Note that the same observations about routing and LSRs to establish LSPs using GMPLS signaling
        adjacencies apply as for the overlay model.

     7.
          protocols. LSRs that can handle both sets of protocols could play
          a part in either case, but no conversion of protocols would be
          applied.

     6.  Manageability Considerations

        Some attention

        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 a whole. This is most clear in the Island Model where 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 had
        different management in place before the migration: the resultant
        migrated network may seek to merge the management or to preserve it.

     7.1.

     6.1. Control of Function and Policy

        The most important control to be applied is at the moment of
        changeover between different levels of protocol support. Such a
        change may be made dynamically 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.

     7.2.

     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 variants of
        management data.

        The GMPLS MIB modules are designed to allow support of the MPLS
        protocols and build 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.

     7.3.

     6.3. Liveness Detection and Monitoring

        Migration will not imposes 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
        may be described in more detail in a later version.

     7.4.

     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. Principally, the process of migration may introduce
        tunneling or stitching into what was previously a flat network.

     7.5.

     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.

     7.6.

     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 and augmented network models where the details of the
        protocol islands remain hidden from the surrounding LSRs.

     7.7.

     6.7. Other Considerations

        No other management considerations arise.

     8.

        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 one might 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 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 between any
        pair of LSRs are based on either MPLS or GMPLS, there are no changes
        necessary to the security procedures.

     9.

     8. IANA Considerations

        This information informational framework document makes no requests for IANA
        action.

     10.

     9. Full Copyright Statement

        Copyright (C) The Internet Society (2006).

        This document is subject to the rights, licenses and restrictions
        contained in BCP 78, and except as set forth therein, the authors
        retain all their rights.

        This document and the information contained herein are provided on an
        "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
        OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
        ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
        INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
        INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

     11.

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

     12.

     11. Acknowledgements

        The authors are grateful to Daisaku Shimazaki for discussion during
        initial work on this document.

     13. The authors are grateful to Dean Cheng
        for his valuable comments.

     12. Authors' Addresses

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

        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

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

        Jean-Louis Le Roux
        France Telecom R&D
        av Pierre Marzin 22300
        Lannion, France
        Phone: +33 2 96 05 30 20
        Email: jeanlouis.leroux@francetelecom.com jeanlouis.leroux@orange-ft.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

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

     14.

        Zafar Alli
        Cisco Systems, Inc.
        EMail: zali@cisco.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

     13. References

     14.1.

     13.1. Normative References

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

        [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions
                  to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

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

        [SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft-
                  ietf-ccamp-gmpls-segment-recovery, work in progress.

        [E2E-RECOVERY] 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",
                  draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in
                  progress.

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

     14.2.

        [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol
        Extensions for Discovery of Traffic Engineering Node Capabilities",
        draft-ietf-ccamp-te-node-cap, work in progress.

     13.2. Informative References

        [MRN-REQ]

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

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

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