Network Working Group                            Kohei Shiomoto(Editor) 
     Internet Draft                                                    (NTT)  
     Proposed Category: Informational                                         
     Expires: July 2007                                                      
                                                                January 2007
                                         
                      Framework for MPLS-TE to GMPLS migration  
                  draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.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. 
      
      
      
     Shiomoto et al.           Expires July 2007                    [Page 1] 
      
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

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

     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 Solutions.............................8 
           5.1. Solutions Toolkit.........! ................. 
               Layered Networks...........................................9 
              5.1.1.......................................................9 
              5.1.2. Routing Interworking................................11 
              5.1.3. Signaling Interworking..............................12 
        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 Components14 
           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...........................................17 
        11. Authors' Addresses...........................................17 
        12. References...................................................18 
           12.1. Normative References....................................18 
           12.2. Informative References..................................19 
        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                Expires August 6, 2007                 [Page 2] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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. 
      
      
     Shiomoto                Expires August 6, 2007                 [Page 3] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

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

     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.  

        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                Expires August 6, 2007                 [Page 4] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

     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                Expires August 6, 2007                 [Page 5] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        .................  ..........................  .................. 
        :      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 (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                Expires August 6, 2007                 [Page 6] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

             ............................  .............................  
             :            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, it may be routed accordingly and can achieve a 
        higher level of functionality by utilizing GMPLS features.  



      
      
     Shiomoto                Expires August 6, 2007                 [Page 7] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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. 

        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.  

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


      
      
     Shiomoto                Expires August 6, 2007                 [Page 8] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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 
        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 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.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                Expires August 6, 2007                 [Page 9] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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 (only for GMPLS PSC), or nested LSPs. If the network 
          islands are non-PSC then the techniques of [MLN] 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                Expires August 6, 2007                [Page 10] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

     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                Expires August 6, 2007                [Page 11] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

          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 (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                Expires August 6, 2007                [Page 12] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

          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.  

         

     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                Expires August 6, 2007                [Page 13] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

     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 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                Expires August 6, 2007                [Page 14] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

     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                Expires August 6, 2007                [Page 15] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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. 

         
































      
      
     Shiomoto                Expires August 6, 2007                [Page 16] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

     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.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  
         
        Kenji Kumaki 
        KDDI Corporation  
        Garden Air Tower  
        Iidabashi, Chiyoda-ku,  
        Tokyo 102-8460, JAPAN  
        Phone: +81-3-6678-3103  
        Email: ke-kumaki@kddi.com 
         
        Zafar Alli 
        Cisco Systems, Inc. 
        EMail: zali@cisco.com 
         
        Eiji Oki  
        NTT  
        Midori 3-9-11  
      
      
     Shiomoto                Expires August 6, 2007                [Page 17] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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. 

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

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

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

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

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

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

      
      
     Shiomoto                Expires August 6, 2007                [Page 18] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 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. 

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

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

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

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

      

     13. Full Copyright Statement 

        Copyright (C) The IETF Trust (2007). 

        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 
      
      
     Shiomoto                Expires August 6, 2007                [Page 19] 
         
          draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02 February 2007 
         

        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                Expires August 6, 2007                [Page 20]