Network Working Group                               Kohei Shiomoto(NTT)
Internet Draft                           Dimitri Papadimitriou(Alcatel)
Proposed Category: Informational     Jean-Louis Le Roux(France Telecom)
Expires: April 2006                             Deborah Brungard (AT&T)
                                                          Eiji Oki(NTT)
                                                      Ichiro Inoue(NTT)
                                                           October 2005

     Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to
                              GMPLS migration

           draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.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

   MPLS to GMPLS migration is the process of evolving MPLS-TE-based
   control plane to GMPLS-based control plane. An appropriate migration
   strategy is selected based on various factors including the service
   provider's network deployment plan, customer demand, available
   network equipment implementation, etc.

   In the course of migration several interworking cases may exist where
   MPLS and GMPLS devices or networks must coexist. Such cases may arise
   as parts of the network are converted from MPLS protocols to GMPLS
   protocols, or may occur if a lower layer network is made GMPLS-
   capable (from having no MPLS or GMPLS control plane) in advance of
   the migration of the higher layer packet switched layer.

                          Expires April 2006                    [Page 1]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005



   Since GMPLS signaling and routing protocols are different from the
   MPLS protocols, in order for MPLS and GMPLS to interwork, we need
   mechanisms to compensate for the difference between MPLS and GMPLS.

   This document provides a framework for MPLS and GMPLS interworking to
   allow transition from MPLS to GMPLS. We discuss issues, models,
   migration scenarios, and requirements. Solutions for MPLS and GMPLS
   interworking will be developed in companion documents.

   We should note that both MPLS and GMPLS protocols can co-exist as
   "ships in the night" without any interworking issue. This document is
   mainly addressing interworking to allow transition from MPLS to GMPLS.



Table of Contents

   1. Introduction.....................................................3
   2. Conventions Used in This Document................................4
   3. Motivations for Migration........................................4
   4. MPLS to GMPLS migration..........................................4
   4.1. Migration models...............................................4
   4.1.1. Island model.................................................4
   4.1.2. Integrated model.............................................6
   4.1.3. Phased model.................................................6
   4.2. Migration strategies...........................................7
   5. Island model interworking cases..................................8
   5.1. MPLS-GMPLS(PSC)-MPLS Islands...................................8
   5.2. MPLS-GMPLS(non-PSC)-MPLS Islands...............................8
   5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands.............................8
   5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands.....................8
   5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands....................9
   6. Interworking issues between MPLS and GMPLS.......................9
   6.1. Control and data plane separation.............................10
   6.2. New features..................................................10
   6.2.1. Signaling...................................................11
   6.2.2. Routing.....................................................12
   6.2.3. New mechanisms..............................................13
   6.3. Interworking between PSC and non-PSC..........................13
   6.3.1. Lack of routing and signaling adjacencies...................13
   6.3.2. Control plane resource exhaustion...........................14
   6.3.3. TE path computation over the border between MPLS and GMPLS
   domains............................................................14
   7. History of this document work...................................14
   8. Security Considerations.........................................16
   9. IANA Considerations.............................................16
   10. Full Copyright Statement.......................................17

                          Expires April 2006               [Page 2]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   11. Intellectual Property..........................................17
   12. Acknowledgements...............................................17
   13. Authors' Addresses.............................................18
   14. References.....................................................18
   14.1. Normative References.........................................19
   14.2. Informative References.......................................19


1. Introduction

   MPLS to GMPLS migration is the process of evolving MPLS-TE-based
   control plane to GMPLS-based control plane.

   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.

   An appropriate migration strategy is selected based on various
   factors including the service provider's network deployment plan,
   customer demand, available network equipment implementation, etc.

   In the course of migration several interworking cases may arise where
   MPLS and GMPLS devices or networks must coexist. Such cases may occur
   as parts of the network are converted from MPLS protocols to GMPLS
   protocols, or may arise if a lower layer network is made GMPLS-
   capable (from having no MPLS or GMPLS control plane) in advance of
   the migration of the higher layer network.

   This document examines 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 protocols, interworking between MPLS 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, and requirements.
   Solutions for interworking MPLS and GMPLS will be developed in
   companion documents.

   We should note that both MPLS and GMPLS protocols can co-exist as
   "ships in the night" without any interworking issue. This document is
   mainly addressing interworking to allow transition from MPLS to GMPLS.
   We should also note that MPLS control plane means MPLS-TE control
   plane (RSVP-TE, IGP-TE) and not LDP-based control plane. This
   document does not address the migration from LDP controlled MPLS
   networks to GMPLS RSVP-TE


                          Expires April 2006               [Page 3]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005



2. Conventions Used in This Document

   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 the rest of this document, the term GMPLS includes both PSC and
   non-PSC. Otherwise the term "PSC GMPLS" or "non-PSC GMPLS" is
   explicitly used.

3. Motivations for Migration

   Motivations for migration will vary for different service providers.
   This section is only present to provide background so that the
   migration discussions may be seen in context. Sections 5 and 6
   illustrate the migration models and processes by means of some
   example scenarios.

   Migration of an MPLS capable LSR to include GMPLS capabilities may be
   performed for one or more reasons.

   - To add all GMPLS functions to an MPLS PSC network.
   - To pick up specific GMPLS features and operate them within an MPLS
     PSC network.
   - To allow interoperation of equipment with new LSRs that only
     support GMPLS.
   - To integrate networks that have been under separate administration
     and where one network utilizes MPLS and another uses GMPLS.
   - 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. MPLS to GMPLS migration

4.1. Migration models

   MPLS to GMPLS migration is a process of evolving MPLS-TE-based
   control plane to GMPLS-based control plane  to GMPLS. Three migration
   models are considered as described below. Practically speaking, both
   migration models may be deployed at the same time.

4.1.1. Island model

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



                          Expires April 2006               [Page 4]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   The most obvious example is to consider an island of nodes with GMPLS
   capability that is introduced into the legacy network. Such an island
   might be composed of newly added network nodes, or might arise from
   the upgrade of existing nodes that previously operated MPLS protocols.

   Clearly there is no requirement that an island be GMPLS-capable
   within an MPLS sea; the opposite is quite possible. That is, there is
   a possibility that an island happens to be MPLS-capable within an
   GMPLS sea in some cases. Such 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 both networks to GMPLS the situation might arise
   where the lower-layer network has been migrated and operates GMPLS,
   but the packet network still operates MPLS. 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, 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 the 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       :
   :+---+  +---+   +---+          +---+          +---+   +---+  +---+:

                          Expires April 2006               [Page 5]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   :|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.2. Integrated model

   The second 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. Further, existing MPLS devices
   are upgraded to support both MPLS and GMPLS. The network continues to
   operate providing MPLS services, but where the service can be
   provided using only GMPLS functionality it may be routed accordingly
   over only such GMPLS-capable devices and achieve a higher level of
   functionality by utilizing GMPLS features. Once all devices in the
   network are GMPLS-capable, the MPLS protocols may be turned off, and
   no new devices need to support MPLS.

   In this second model the questions to be addressed concern the 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 GMPLS-capable LSRs co-exist. Some LSRs will be
   capable of only one protocol, and some of both. The migration
   strategy here involves introducing GMPLS-capable LSRs into an
   existing MPLS-capable network until such time as all LSRs are GMPLS-
   capable at which time all MPLS functionality is disabled. Since we
   are starting with an MPLS network all devices are PSC 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. 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

                          Expires April 2006               [Page 6]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   (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 their whole protocol implementation.

   The interoperability concerns (LABEL REQUEST and LABEL object, for
   instance, when speaking about RSVP-TE signaling) are exacerbated by
   this migration model unless all LSRs in the network are updated
   simultaneously. 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 and
   a GMPLS LSR puts the hybrid in the role of an MPLS LSR. The potential
   for different hybrids within the network only serves to complicate
   matters considerably. Thus the piecemeal migration from MPLS to GMPLS
   is NOT RECOMMENDED.

4.2. Migration strategies

   An appropriate migration strategy is selected based on various
   factors including the service provider's network deployment plan,
   customer demand, available network equipment, 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 partial
   upgrade to include specific GMPLS features), and upon the immediate
   objectives (phased upgrade or staged upgrades).

   For PSC networks supported 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 where, 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 is controlled by GMPLS.

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


                          Expires April 2006               [Page 7]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   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 in the network or to facilitate interworking with GMPLS-
   based optical core network.

   The migration may give rise to islands of GMPLS support within a sea
   of 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 of
   GMPLS non-PSC functionality that are completely contained within the
   GMPLS PSC islands. This would protect the MPLS LSRs from having 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 to
   increase the capacity of a MPLS packet network is an example that may
   give rise to this scenario. Until the MPLS network is upgraded to be
   GMPLS-capable, the MPLS and GMPLS networks must interwork. The
   interworking challenges may be reduced by wrapping the non-PSC GMPLS
   island entirely within a GMPLS PSC island as described in the
   previous section.

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

   This case might arise as the result of installing new GMPLS-capable
   islands around a legacy MPLS network, or as the result of controlled
   migration of some islands to become GMPLS-capable.

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

   This case is out of scope for this document. Since the MPLS island is
   necessarily packet capable (i.e. PSC), this scenario requires that
   non-PSC LSPs are carried across a PSC network. Such a situation does
   not arise through simple control plane migration although the


                          Expires April 2006               [Page 8]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   interworking scenario might occur for other reasons and be supported,
   for example, by pseudowires.

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

   This case is 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. Some signaling and
   routing conversion is required on island border LSRs. Figure 2 shows
   the reference 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 the
   island boundaries. However, from a control plane point of view this
   model may prove challenging because the protocols must share or
   convert 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 establishment. Indeed, a
   unidirectional packet LSP from R1 to G5 is more easily accommodated
   at G1 than a bi-directional PSC LSP from G5 to R1.


6. Interworking issues between MPLS and GMPLS



                          Expires April 2006               [Page 9]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   Issues of MPLS and GMPLS interworking stem from the difference
   between MPLS and GMPLS protocols and architecture. These issues are
   categorized into four groups:
    (1) control and data plane separation,
    (2) new features introduced by GMPLS,
    (3) new methods introduced by GMPLS, and
    (4) interworking between PSC and non-PSC.

   Note that a GMPLS PSC island may be treated in the same way as an
   island of non-PSC LSRs, and much can be gained by applying the
   techniques described in section 6.4 to the other scenarios described
   here.

6.1. Control and data plane separation

   In MPLS, the control plane traffic (signaling and routing) is carried
   in-band with data. This means that there is fate sharing between a
   data link and the control traffic on the link. The control plane
   keep-alive techniques can be used to detect some data plane failures.

   TDM, LSC, FSC networks do not recognize packet delineation, so in-
   band control channels cannot be terminated, and GMPLS must support
   dedicated control channels (separated from the data channels). In
   GMPLS, the control channel can be logically or physically separated
   (i.e., in-fiber out-of-band or out-of-fiber out-of-bound) from the
   data channel depending on the capabilities of the network devices and
   the operational requirements.

   The GMPLS control plane, which is designed to carry the control
   packets, offers the possibility to use dedicated control channels
   that must not be used to carry data. This is particularly important
   when the control channels are of low capacity and are not designed to
   carry user traffic.

   Since GMPLS introduces a separation between control and data channels,
   control traffic may use different channels than the data traffic, and
   this requires new routing and signaling protocol elements (e.g.
   identification of data channels within the control plane).


6.2. New features

   New features introduced by GMPLS and not available in MPLS include
   bidirectional LSPs, label suggestion, label restriction, graceful
   restart, and graceful teardown, as well as GMPLS's support of
   networks with multiple switching capabilities (see [RFC3945]).



                          Expires April 2006              [Page 10]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


6.2.1. Signaling

   GMPLS RSVP-TE signaling ([RFC3471]) 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 will 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 subobjects 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 bi-directional 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.

   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 will 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E This C-Type is
   unknown to MPLS LSRs which 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
   RecoveryPath message that are not supported by MPLS nodes.

                          Expires April 2006              [Page 11]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005



   6.2.1.1 Bi-directional LSP

   GMPLS provides bidirectional LSP setup - a single signaling session
   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 differently from each
   other. 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 island model and to the island migration model.

   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 and cannot initiate a return LSP.

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

6.2.2. Routing

   TE-link information is advertised by the IGP using TE extensions.
   This allows LSRs to collect topology information for the whole TE
   network and to store it in the traffic-engineering database (TED).
   Traffic-engineered explicit routes are calculated using the network
   graphs derived from the TED.

   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 extensions to 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 combination of MPLS information
   advertised by MPLS LSRs and a restricted subset of the information
   advertised by GMPLS LSRs to compute a traffic-engineered explicit
   route across a mixed network. However, it is likely that a path

                          Expires April 2006              [Page 12]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   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 mean 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.3. New mechanisms

   GMPLS also provides several features in a distinct manner from MPLS.
   For instance local protection is provided using different mechanisms
   in MPLS (see [RFC4090]) and GMPLS (see [SEGMENT-RECOVERY]). Local
   protection of island border nodes may be a particular problem.

6.3. Interworking between PSC and non-PSC

   Three issues of interworking between MPLS-based packet networks and
   GMPLS-based optical transport network result from the fact that
   control and data planes are separated in GMPLS-based optical
   transport networks. These three issues are:
    (a) Lack of routing and signaling adjacencies,
    (b) Control plane resource exhaustion, and
    (c) TE path computation over the border between MPLS and GMPLS
         domains.

   There are several architectural alternatives for interworking between
   packet network and optical transport network: overlay, peer and
   augmented models [RFC3945]. Impacts of each issue on each model are
   different.

   These issues are explained using an example network shown in Figure 3.

   ................. .............................. ..................
   : Ingress MPLS  : :      GMPLS-based optical   : :  Egress MPLS   :
   :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
   :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
   :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
   :      ________/ : :  ________/  |   ________/ : :  ________/     :
   :     /          : : /           |  /          : : /              :
   :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
   :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
   :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
   :................: :...........................: :................:

   Figure 3: Interworking of MPLS-TE networks and GMPLS-based optical
   transport networks.

6.3.1. Lack of routing and signaling adjacencies


                          Expires April 2006              [Page 13]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


   The ingress MPLS and the egress MPLS domains are interconnected via a
   GMPLS-based optical network as shown in Fig 3. LSAs in the egress
   MPLS domain are not advertised in the ingress MPLS domain unless
   routing adjacencies are established between the IP/MPLS domain and
   GMPLS domain or unless routing adjacencies are established directly
   between IP/MPLS domains (overlay model). Therefore the ingress LSR in
   the ingress MPLS domain is not able to find the egress LSR in the
   egress MPLS domain. The signaling messages are not passed across the
   GMPLS domain between the ingress and the egress MPLS domains unless
   the signaling adjacencies are established between the MPLS domain and
   the GMPLS domain or directly between MPLS domains (overlay model).

   This issue appears in the augmented and the overlay model when there
   are no links provided between MPLS domains across the GMPLS domain.

6.3.2. Control plane resource exhaustion

   It is a danger that only arises at a PSC LSR that uses an out of band
   control channel at the border between MPLS and GMPLS domains. This
   issue is already mentioned at the head of section 6.1.

   This issue can appear in the peer, the augmented, and the overlay
   models depending on how the border node handles the data forwarding
   and manages the address space.

6.3.3. TE path computation over the border between MPLS and GMPLS
    domains

   If the ingress LSR in the ingress MPLS domain does not understand the
   GMPLS TE protocols and information elements, it assumes that there is
   no available TE-path across the GMPLS domain unless MPLS-compatible
   TE LSAs representing the available TE-paths in the GMPLS domain are
   advertised into the ingress and egress MPLS domains.

   This issue appears in the peer and the augmented models.

   A different issue, which has very similar results, appears in the
   overlay model. In the overlay model, mechanism to discover
   connectivity is out of scope and we need to find connectivity between
   IP/MPLS domains across the core GMPLS domain. This issue is referred
   to as the "unknown adjacency" problem.


7. History of this document work

   This document has been spun off from the internet draft entitled
   "IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration
   <draft-oki-ccamp-gmpls-ip-interworking-06.txt>".

                          Expires April 2006              [Page 14]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005



   This document provides a framework for IP/MPLS-GMPLS interworking in
   support of IP/MPLS to GMPLS migration. Solutions for IP/MPLS-GMPLS
   interworking in support of IP/MPLS to GMPLS migration will be
   developed in companion documents.












































                          Expires April 2006              [Page 15]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005




8. 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 either fully MPLS or fully GMPLS, there are no
   changes necessary to the security procedures.


9. IANA Considerations

   This information framework document makes no requests for IANA action.























                          Expires April 2006              [Page 16]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


10. Full Copyright Statement

   Copyright (C) The Internet Society (2005).

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

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



                          Expires April 2006              [Page 17]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


13. Authors' Addresses

   Kohei Shiomoto
   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

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


14. References



                          Expires April 2006              [Page 18]


draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.txt       October 2005


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

   [RFC3471]     Berger, L., "Generalized Multi-Protocol Label
                 Switching (GMPLS) Signaling Functional Description",
                 RFC 3471, January 2003.


14.2. Informative References

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

   [MRN-SOL]     Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
                 Brungard, D., Le Roux, J.L., "Generalized Multi-
                 Protocol Label Switching (GMPLS) Protocol Extensions
                 for  Multi-Region Networks (MRN)", draft-
                 papadimitriou-ccamp-gmpls-mrn-extensions, work in
                 progress.

   [MRN-EVAL]    Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou,
                 D., Shiomoto, K., Vigoureux, M.,"Evaluation of
                 existing GMPLS Protocols against Multi Layer and Multi
                 Region Networks (MLN/MRN)", draft-leroux-ccamp-gmpls-
                 mrn-eval, work in progress.









                          Expires April 2006              [Page 19]