Network Working Group                                 D. Brungard (ATT)
  Internet Draft                                        J.L. Le Roux (FT)
  Proposed Category: Standards Track                         E. Oki (NTT)
  Expires: January 2006                        D. Papadimitriou (Alcatel)
                                                       D. Shimazaki (NTT)
                                                        K. Shiomoto (NTT)
  
                                                                July 2005
  
        IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS
                                migration
  
               draft-oki-ccamp-gmpls-ip-interworking-06.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.
  
  Copyright Notice
  
     Copyright (C) The Internet Society (2005). All Rights Reserved.
  
  Abstract
  
     Over time Multi-Protocol Label Switching (MPLS) traffic
     engineered networks may be migrated to use Generalized MPLS
     (GMPLS). This will allow the networks to benefit from many new
     features that have been added to the GMPLS protocols.
     Additionally, such migration will facilitate easy interworking
     of packet networks that are controlled by IP/MPLS-TE protocols
     and networks that are controlled by GMPLS protocols.
  
     During this migration phase MPLS and GMPLS capable elements will
     have to co-exist and interwork. GMPLS signaling and routing
     protocols are subtly different from the MPLS protocols and so
     interworking and migration strategies are needed.
  
     This document describes issues associated with interworking of
     IP/MPLS-TE networks and GMPLS-based optical networks. Then it
     describes possible migration scenarios, mechanisms to compensate
     for the differences between MPLS and GMPLS protocols, and how to
     apply those mechanisms in order to achieve migration from MPLS
     to GMPLS.
  
                          Expires Janurary 2006                [Page 1]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
  
  
  Table of Contents
  
     1. Introduction...................................................2
     2. Interworking between MPLS-based packet network and GMPLS-
     based optical transport network...................................2
     2.1. Issues.......................................................2
     2.1.1. Lack of routing and signaling adjacencies..................2
     2.1.2. Control plane resource exhaustion..........................2
     2.1.3. TE path computation over the border between MPLS and
     GMPLS domains.....................................................2
     3. Migration scenarios............................................2
     3.1. Migration Models.............................................2
     3.2. MPLS-GMPLS(non-PSC)-MPLS Islands.............................2
     3.3. MPLS-GMPLS(PSC)-MPLS Islands.................................2
     3.4. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands...........................2
     3.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands..................2
     3.6. Integrated Migration Model for PSC...........................2
     4. Difference between MPLS and GMPLS protocols....................2
     4.1. Routing......................................................2
     4.2. Signaling....................................................2
     4.3. Control plane/data plane separation..........................2
     4.4. Bidirectional LSPs...........................................2
     5. Required mechanisms for the MPLS-GMPLS-MPLS migration model....2
     5.1. Routing......................................................2
     5.1.1. TE link....................................................2
     5.1.2. Discovery of GMPLS signaling capability....................2
     5.2. Path computation.............................................2
     5.3. Signaling....................................................2
     5.3.1. LSP nesting................................................2
     5.3.2. LSP stitching..............................................2
     5.3.3. Contiguous LSPs............................................2
     6. Required mechanisms for other migration models.................2
     7. Security considerations........................................2
     8. IANA Considerations............................................2
     9. Acknowledgments................................................2
     10. References....................................................2
     10.1. Normative references........................................2
     10.2. Informative references......................................2
     11. Authors' Addresses............................................2
     12. Intellectual Property Statement...............................2
     13. Disclaimer of Validity........................................2
     14. Copyright Statement...........................................2
  
  1. Introduction
  
     Multi-protocol label switching (MPLS) is widely deployed with
     applications such as Traffic Engineering (TE) and Virtual
     Private Networks (VPN). Various kinds of services such as VoIP,
     IPv6, L2VPN/L3VPN, and pseudo wire emulation are expected to
     converge over the MPLS-based controlled packet switching
     infrastructure network.
  
     Many service providers report that traffic volume is increasing
     tremendously as broadband services enabled by ADSL and FTTH are
     rapidly penetrating the market, and the processing performance
     of terminal and server is ever increasing. In order to cope with
     such an increase in the traffic volume, optical networks, which
     consist of TDM, LSC, and FSC devices, are being introduced.
  
     Generalized MPLS (GMPLS) is being standardized by extending MPLS
     to control such optical networks (see [2], [3], [9], [10], [11],
     [12]) in addition to Layer-2 Switching Capable (L2SC) and Packet
  
                           Expires January 2006                   [Page 2]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     Switching Capable (PSC) networks [6]). GMPLS networks will be
     deployed as part of the existing MPLS infrastructure to extend
     the reach and capacity of MPLS networks.
  
     Additionally, GMPLS PSC devices and networks will be deployed to
     take advantage of new features and functions that have been
     added to the GMPLS protocols but which are not present in MPLS.
     These include features such as bi-directional LSPs, label
     suggestion, label restriction, graceful restart, and graceful
     teardown as well as explicit support for network to host
     multiple switching capabilities. (see [6]). GMPLS also provides
     several features in a distinct manner from MPLS. For instance
     local protection is provided using distinct mechanisms in MPLS
     (see [17]) and GMPLS (see [18]). Migration from MPLS to GMPLS
     will bring these features and such distinct mechanisms into the
     existing MPLS-based controlled infrastructure network.
  
     MPLS and GMPLS devices will coexist in the network until the
     existing MPLS network is completely migrated to the GMPLS
     network. This means that MPLS and GMPLS devices must interwork
     to deliver services for the user.
  
     GMPLS protocols are, however, subtly different from the MPLS
     protocols. In order to migrate from the existing MPLS to the
     GMPLS network, we need to define mechanisms to compensate the
     difference between MPLS and GMPLS. In this document we discuss
     the migration scenarios from MPLS to GMPLS networks, mechanisms
     to compensate for the differences between MPLS and GMPLS, and
     the applicability of the mechanisms to the possible migration
     scenarios. Some of the mechanisms described in this document use
     existing techniques; others introduce new techniques.
  
     Note that GMPLS covers Packet Switching Capable (PSC) networks
     [6]. 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.
  
  2. Interworking of IP/MPLS-TE networks and GMPLS-based networks
  
  2.1.   Issues
  
     In order to expand the network capacity, GMPLS-based optical
     networks are likely to be deployed underneath the already-
     deployed MPLS-based networks. We need "interworking" mechanisms
     between MPLS and GMPLS-based optical networks because the LSRs
     in the already-deployed MPLS-based networks may not be GMPLS-
     capable. Even if the control plane of the already-deployed MPLS-
     based networks will be "migrated" from MPLS to GMPLS, such
     interworking mechanisms are also required during the migration
     process because GMPLS-incapable LSRs and GMPLS-capable LSRs
     coexist until all the LSRs become GMPLS-capable. This section is
     devoted to highlight the issues on interworking between MPLS-
     based packet networks and GMPLS-based networks.
  
     There are several architectural alternatives for interworking
     between packet network and optical transport network: overlay,
     integrated and augmented models [RFC3945]. We also address the
     issues from the point of view of these different architectural
     alternatives.
  
     Three issues on 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 (1) lack of
  
                           Expires January 2006                   [Page 3]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     routing and signaling adjacencies, (2) control plane resource
     exhaustion, and (3) TE path computation over the border between
     MPLS and GMPLS domains. These issues are explained using an
     example network shown in Fig. 1.
  
     ................. .............................. ..................
     : Ingress MPLS  : :      GMPLS-based optical   : :  Egress MPLS   :
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :      ________/ : :  ________/  |   ________/ : :  ________/     :
     :     /          : : /           |  /          : : /              :
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :................: :...........................: :................:
  
     Figure 1: Interworking of MPLS-TE networks and GMPLS-based
     optical transport networks.
  
  2.1.1.     Lack of routing and signaling adjacencies
  
     The ingress MPLS and the egress MPLS domains are interconnected
     via a GMPLS-based optical network as shown in Fig X1. 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. 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.
  
     This issue appears in the augmented and the overlay model.
  
  2.1.2.     Control plane resource exhaustion
  
     In GMPLS-based optical domain, the control plane is not designed
     for carrying user data traffic packets separates control and
     data planes. If the user data traffic between ingress and egress
     MPLS domains is routed onto the control plane of the GMPLS-based
     optical domain, it would exhaust the control plane resource. Use
     data traffic between ingress and egress domains MUST NOT be
     carried using the control plane of GMPLS-based optical domain.
  
     This issue can appear in the integrated, the augmented, and the
     overlay models depending on how the border node handles the data
     forwarding and manages the address space.
  
  2.1.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 integrated and the augmented models.
  
     A different issue, which has very similar results, appears in
     the overlay model. In the overlay model, we need to find
     connectivity between IP/MPLS domains across the core GMPLS
  
                           Expires January 2006                   [Page 4]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     domain. This issue is referred to as the ææunknown adjacencyÆÆ
     problem.
  
     2.2 Solutions
  
     The required mechanisms to address the above-mentioned issues
     are described in section 5. Applicability of these mechanisms
     will be addressed in a separate document.
  
  3. Migration scenarios
  
  3.1.   Migration Models
  
     Two migration models are considered.
  
     In the first model, an MPLS network has islands of GMPLS
     capability introduced. These islands may be networks of devices
     operating at a lower network layer (for example, TDM), or may be
     clusters of PSC devices that are controlled by GMPLS protocols.
     The smallest island can contain just one device. Over time,
     collections of MPLS devices are replaced or upgraded to create
     new GMPLS islands or to extend existing ones.
  
     From a migration interworking point of view, we need to examine
     how these islands are positioned and how LSPs run between the
     islands. Three categories of migration scenarios are considered:
     (1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, and (3) MPLS-GMPLS.
     In each case, the interworking behavior is examined based on
     whether the GMPLS islands are PSC or non-PSC.
  
     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-capable
     devices it may be routed accordingly 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.
  
     Practically speaking, both migration models may be deployed at
     the same time giving rise to a network of mixed MPLS and GMPLS
     devices with islands of just MPLS or just GMPLS capability.
  
  3.2.   MPLS-GMPLS(non-PSC)-MPLS Islands
  
     The introduction of a GMPLS-based controlled optical core
     network to increase the capacity is an example of this scenario.
     TDM, LSC, and/or FSC LSPs are established between MPLS networks
     across the GMPLS network. A set of those LSPs provide virtual
     network topology to connect the MPLS networks. This topology may
     be reconfigurable by adding and/or removing those LSPs [15][16].
  
     MPLS domains interconnected at the edges of the virtual network
     topology may form a single MPLS network. Figure 2 shows the
     reference network model for the MPLS-GMPLS(non-PSC)-MPLS
     migration. The model consists of three islands: ingress, transit,
     and egress. Both the ingress and egress islands are MPLS-based
     while the transit island is GMPLS-based. The nodes at the
  
                           Expires January 2006                   [Page 5]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     boundary of the MPLS and GMPLS islands (G1, G2, G5, and G6) are
     referred to as "island border nodes". All nodes except the
     island border nodes in the GMPLS-based transit island (G3 and
     G4) are non-PSC devices, i.e., optical equipment (TDM, LSC, and
     FSC). An MPLS LSP can be provisioned from a node in the ingress
     MPLS-based island (say, R2) to a node in the egress MPLS-based
     island (say, R4). The LSP is referred to as the end-to-end (e2e)
     LSP. The switching capability type of both end points of the e2e
     LSP are the same (PSC).
  
     ................. .............................. ..................
     :      MPLS      : :      GMPLS (non-PSC)      : :     MPLS       :
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :      ________/ : :  ________/  |   ________/ : :  ________/     :
     :     /          : : /           |  /          : : /              :
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :................: :...........................: :................:
  
        |<-------------------------------------------------------->|
                                       e2e LSP
  
        Figure 2: MPLS-GMPLS(non-PSC)-MPLS island migration model.
  
  3.3.   MPLS-GMPLS(PSC)-MPLS Islands
  
  
     An MPLS-based network can be migrated to become a GMPLS (PSC)-
     based network.
     The rationale of this type of migration scenario is supported by
     two factors:
  
     1. to provide GMPLS-based advanced features in the network
     2. to facilitate interworking with GMPLS-based
        optical core network.
  
     Numerous advanced features are being developed in GMPLS and MPLS,
     but many are only currently available in a GMPLS context. An
     existing MPLS-based network could be migrated to become a GMPLS
     (PSC)-based network to deliver the advanced features. Once the
     PSC network has been migrated to use GMPLS, it could be migrated
     to be or work with a GMPLS-based optical core network with less
     effort. Thus, for example, the network might be constructed from
     five islands so that an e2e LSP traversed MPLS-(PSC)GMPLS-(non-
     PSC)GMPLS-(PSC)GMPLS-MPLS. The migration interworking strategy
     would be implemented between MPLS and (PSC)GMPLS islands without
     the complexity of handling the change in switching capability
     described in the previous model.
  
  3.4.   GMPLS(PSC)-MPLS-GMPLS(PSC) Islands
  
     In this scenario, GMPLS PSC e2e LSPs are provisioned in the
     GMPLS network, which is disconnected. The MPLS-based controlled
     infrastructure is used to bridge the disconnected GMPLS networks.
     This scenario 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.
  
     Since the MPLS-based controlled network is PSC, the GMPLS PSC
     LSP can cross MPLS-based converged network without extra
  
                           Expires January 2006                   [Page 6]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     treatment in data plane. Note, however, that the level of
     service available in the GMPLS islands is more extensive than
     that available in the MPLS island because of the differences in
     the signaling protocols. The migration challenge in this model
     is to provide the expected level of service across the MPLS
     island, and to carry the GMPLS signaling and routing information
     across the MPLS island.
  
  3.5.   GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands
  
     This scenario is for further study.
  
  3.6.   GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands
  
     In this scenario an LSP starts/ends in the GMPLS (PSC) island
     and ends/starts in the MPLS island. Some signaling and routing
     conversion is required on island border LSRs. This migration
     model is likely to arise where the migration strategy is not
     based on a core infrastructure, but has edge nodes (ingress or
     egress) located in the islands of different capabilities.
  
     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.
  
     Figure 4 shows the reference model for this migration scenario.
     Head-End and Tail-end LSR are in distinct control plane regions.
  
          .................  .................................
          :      MPLS      : :      GMPLS (PSC)              :
          :+---+  +---+   +---+          +---+          +---+:
          :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |:
          :+---+  +---+   +---+          +-+-+          +---+:
          :      ________/ : :  ________/  |   ________/     :
          :     /          : : /           |  /              :
          :+---+  +---+   +---+          +-+-+          +---+:
          :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |:
          :+---+  +---+   +---+          +---+          +---+:
          :................: :...............................:
  
            |<------------------------------------------->|
                               e2e LSP
  
                  Figure 4: GMPLS-MPLS migration model.
  
  3.7.   Integrated Migration Model for PSC
  
     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 is 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 all devices are PSC 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.
     Note that this is a contrast with the models described above.
  
  4. Difference between MPLS and GMPLS protocols
  
  
                           Expires January 2006                   [Page 7]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
  4.1.   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 data base
     (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 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.
  
     Figure 5 illustrates this problem. Suppose that an e2e LSP is
     required between R2 and R4 and that we need to compute the path
     between R2 and R4. The TE link information for the links R2-R21,
     R21-G2, G6-R41 and R41-R4 is MPLS-based, while the information
     for the links G2-G4, G2-G3, G3-G4 and G4-G6 is GMPLS-based. The
     node in the MPLS-based ingress region (say, R2) may compute a
     path using the TE link information that it is aware of, and may
     produce a path R2-R21-G2-G4-G6-R41-R4. But it may be the case
     that the links G2-G4 and G4-G6 cannot be connected because they
     have different switching capabilities. A path from G2 to G4
     through G3 would, however, be successful. If R2 was able to
     process the GMPLS TE information advertised by the IGP it would
     see the switching capability information and would select the
     correct path, but since it is an MPLS node it selects the wrong
     path based on the limited MPLS TE information.
  
     ................. ............................. ..................
     :      MPLS      : :      GMPLS (non-PSC)      : :     MPLS       :
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :      ________/ : :  ________/  |   ________/ : :  ________/     :
     :     /          : : /           |  /          : : /              :
     :+---+  +---+   +---+          +-+-+          +---+   +---+  +---+:
     :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
     :+---+  +---+   +---+          +---+          +---+   +---+  +---+:
     :................: :...........................: :................:
  
        |<---->|<----->|<------------>|<------------>|<----->|<---->|
          MPLS TE-link   GMPLS TE-link  GMPLS TE-link  MPLS TE-link
  
     Figure 5: Problem mismatch of TE-link information in MPLS and
     GMPLS.
  
  4.2.   Signaling
  
  
  
                           Expires January 2006                   [Page 8]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     GMPLS RSVP-TE signaling ([2]) introduces new RSVP-TE objects,
     and their associated procedures, that are no processed/generated
     by MPLS LSRs:
     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 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
       (see also Section 3.4)
     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 Notify Request object used to solicit notification of
       errors and events.
     o The Protection object used to indicate the required
       protection scheme (and the Association object used to
       associated protected and protecting LSPs).
     O Alarm_Spec object to exchange (per LSP) alarm information
       across the control plane
  
     Some of these objects can be passed transparently by MPLS LSRs
     because their C-Nums are of the form 11bbbbbb, or simply
     discarded and ignored because their C-Nums are of the form
     10bbbbbb, but others will cause an MPLS LSR to reject the
     message that carries them because their C-Nums are of the form
     0bbbbbbb.
  
     Even some objects that GMPLS inherits from MPLS can be expected
     to cause problems. For example, the Label object in GMPLS uses
     two new C-Types to indicate æGeneralized LabelÆ. These C-Types
     are 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 a new message, the Notify message, that is
     not supported by MPLS nodes.
  
     Note also that ongoing GMPLS extensions (P&R, Graceful Restartà)
     add new objects and messages. Future GMPLS extensions are also
     likely to add further messages and objects.
  
  4.3.   Control plane/data plane separation
  
     In MPLS, the control plane traffic (signaling and routing) is
     carried in-band with data. This means that there is fare sharing
     between a data link and the control traffic on the link. The
     control plane keep-alive techniques can be used to detect data
     plane failures.
  
     TDM, LSC, FSC networks do not recognize packet delineation, so
     GMPLS must support control channel that can be logically (in-
     band) or physically (out-of-band) separated from the data
     channel depending on the capabilities of the devices interfaces
     and the operational requirements.
  
                           Expires January 2006                   [Page 9]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
  
     The GMPLS control plane, which is designed to carry the control
     packets in a GMPLS network, does not form part of the data
     network and must not be used to carry data. This is particularly
     important since the control channel may be of low capacity and
     is not designed to carry user traffic.
  
     The problem may be seen at packet-capable LSRs that may see
     unlabeled IP packets, and that also have out-of-band control
     channels on some interfaces. In these cases it is possible that
     the IP traffic will be routed along a control channel according
     to the shortest path determined by the IGP.
  
     Appropriate precautions must be taken to protect out-of-band
     control channels.
  
  4.4.   Bidirectional LSPs
  
     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 GMPLS network need to be carried in MPLS network.
  
     Note that this issue arises only in the cases where an LSP is
     originated and terminated by GMPLS-capable LSRs. In other words,
     it applies only to the GMPLS-MPLS-GMPLS, GMPLS-MPLS and
     integrated migration models. 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 even if it could be told that
     the need existed.
  
     Functionally, this is a reasonable restriction because only
     GMPLS-capable LSRs will need to be the ingress or egress of a
     bidirectional service.
  
     Note that the island border LSRs will bear the responsibility
     for achieving the bidirectional service across the central MPLS
     island.
  
  5. Required mechanisms for the MPLS-GMPLS-MPLS migration model.
  
     This section details the set of routing, path computation and
     signaling mechanisms required in order to bridge the differences
     between MPLS and GMPLS protocols with regards to the MPLS-GMPLS-
     MPLS migration model.
  
     The entire network consisting of ingress, transit, and egress
     regions (See Figure 1 or Figure 2 for instance) may be managed
     either as a single area or as multiple areas from the IGP
     perspective.
  
     Note that a simple migration approach can consist of separating
     MPLS and GMPLS networks into distinct IGP areas (possibly in
  
                           Expires January 2006                  [Page 10]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     distinct ASs), and then relying on multi-area (multi-AS) routing,
     path computation, and signaling solutions worked on in the CCAMP
     and PCE WGs.
  
  5.1.   Routing
  
  5.1.1.     TE link
  
     If the entire network is a single area, the partial topology of
     GMPLS-based region which consists of PSC-links should be made
     visible to the MPLS islands. GMPLS PSC TE-links are also
     advertised into the MPLS islands  as MPLS TE-links using MPLS-
     based TE link information. The GMPLS-capable LSR advertises both
     GMPLS and MPLS TE LSAs for the same TE link. If the GMPLS-based
     region contains non-PSC links or devices (for example, if the
     whole region is non-PSC with the exception of the edge devices)
     PSC links should be set up between the PSC capable devices (for
     example, the border nodes). For example, in Figure 3, a PSC-link
     can be set up between G2 and G6. Note that the FA LSPs that
     realize these PSC links could be statically provisioned in a
     full mesh across the GMPLS island or created dynamically on
     demand although the Virtual Network Topology (VNT) must be
     advertised to the MPLS islands.
     Note also that MPLS TE-links could be advertised even in the
     absence of PSC FA-LSP between two border nodes. Such TE-links
     are called virtual TE-links (see [15]).
  
     MPLS TE-links may be understood by the nodes in the GMPLS
     network, as they build their TEDs.
  
     There is no backward compatibility issue when MPLS and GMPLS
     LSRs resides in distinct IGP areas, as TE-link information is
     not leaked across area boundary (see [24] and [21]).
  
  5.1.2.     Discovery of GMPLS signaling capability
  
     It may be useful to advertise the signaling capabilities
     (specifically, the ability to support GMPLS) using the IGP. This
     would allow every node in the network to automatically discover
     the GMPLS signaling islands.
  
     This could be achieved using the techniques proposed in [25] or
     could be deduced from the presence of GMPLS TE information for
     any link advertised by an LSR (provided that GMPLS routing
     support implies GMPLS signaling support).
  
     There are several options for how the islands are managed from a
     routing perspective. They could all be managed as a single area,
     they could be managed as separate areas, or they could be
     operated as separate ASs. In the second and third cases, it a
     node will sit on the border between the islands and act as an IP
     border node (ABR or ASBR) but only be capable of running MPLS or
     GMPLS within the appropriate island. That is, the ABR or ASBR
     cannot participate in signaling within both islands. Such LSRs
     will be no use as island border LSRs and must be recognized as
     such and excluded from any end-to-end signaling attempts.
  
  5.2.   Path computation
  
     When each of the islands in the MPLS-GMPLS-MPLS scenario is
     located in a separate TE domain, the path computation for TE
     LSPs should be performed strictly following the procedures
     described in the [21]. In that case route resolution can be
  
  
                           Expires January 2006                  [Page 11]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     performed using loose hops (see [26]) or the Path Computation
     Element based approach [27].
  
     However, if all islands are resident within a single TE domain
     (e.g. an IGP area) the explicit end-to-end paths can be
     determined on the ingress LSRs (which are MPLS-capable in this
     scenario). Note that it is implicit in the statement that, when
     the islands are within a single TE domain, the GMPLS-capable
     LSRs advertise both GMPLS and MPLS TE link sub-TLVs.
  
     In this scenario, however, an ingress MPLS-capable LSR may
     compute a path that cannot function because of incompatible
     GMPLS parameters (for example, switching capabilities or per-
     priority bandwidth) as described in section 3.1. Therefore,
     where this issue may arise, FA-LSP sould be setup between border
     nodes and advertised as MPLS TE-links, and/or virtual MPLS TE-
     links may be used (see section 5.1.1)
  
  5.3.   Signaling
  
     There are three mechanisms that could be used for MPLS-GMPLS-
     MPLS interworking irrespective of whether the sections are
     located in the same or separate TE domains. The three mechanisms
     are:
     o LSP nesting
     o LSP stitching
     o Contiguous LSPs with MPLS<->GMPLS signaling translation.
  
     The LSP nesting is recommended when GMPLS and MPLS links belong
     to different network layers (the case of non-PSC GMPLS or PSC1
     MPLS & PSC2 GMPLS for instance). The other two mechanisms could
     be used when all islands provide network topology within the
     same network layer (the case of PSC GMPLS).
  
  5.3.1.     LSP nesting
  
     In the MPLS-GMPLS-MPLS scenario the GMPLS links may have
     different switching capabilities compared to the MPLS links.
     End-to-end LSPs in this case could be carried across the GMPLS
     island by hierarchical LSPs established between the island
     border nodes.
  
     When the setup request for an end-to-end LSP reaches the GMPLS
     island, an attempt is made to find a locally originated H-LSP
     that terminates at the far side of the GMPLS island, and that
     has the required attributes and unreserved bandwidth. The H-LSP
     may be pre-provisioned via management, or may have been created
     dynamically to satisfy some previous request. If such a pre-
     existing H-LSP is not found, the establishment of the end-to-end
     LSP is paused while a new H-LSP is established. Once an H-LSP
     has been found or established, the signaling of the end-to-end
     LSP proceeds using the H-LSP as a data link.
  
     The H-LSPs may optionally be advertised as MPLS TE links into
     the MPLS islands. Such H-LSP is referred to as an FA-LSP [19].
     The H-LSPs advertised as TE links provide the Virtual Network
     Topology for MPLS layer. TE-LSPs guarantee efficient usage of
     their bandwidth because those TE-links are present in the TED
     and can be considered in future path computations for the
     placement of further end-to-end LSPs.
  
     Hierarchical LSPs offer scaling advantages of aggregation across
     the central GMPLS island, and facilitate localized recovery and
  
  
                           Expires January 2006                  [Page 12]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     re-optimization in the GMPLS island without requiring end-to-end
     action.
  
  5.3.2.     LSP stitching
  
     LSP stitching is described in [28]. Stitching may be operated
     exactly as described for FA-LSPs in the previous section. Note,
     however that only one end-to-end LSP can be carried by a
     stitching segment at any time.
     LSP stitching is primarily targeted at the case where all
     islands operate the same switching type. Note that the switching
     capability of an LSP segment TE link MUST be equal to the
     switching type of the underlying LSP segment; i.e. no hierarchy
     (nesting) is possible [28].
  
     LSP stitching does not require the protocol mapping of
     contiguous LSPs (see below) but does require more protocol state
     at the island border nodes. It offers more flexibility with
     regard to LSP recovery and re-optimization since the LSP segment
     across the GMPLS island may be changed without requiring end-to-
     end action.
  
  5.3.3.     Contiguous LSPs
  
     An end-to-end LSP crossing all three islands in the MPLS-GMPLS-
     MPLS scenario could be provisioned as a single contiguous LSP
     without the use of nesting or stitching. In this case, the
     island border LSRs must perform the necessary MPLS to GMPLS
     translation of the signaling messages. Specifically, they need
     to make sure that signaling messages sent into the GMPLS island
     contain GMPLS-format signaling objects, while messages sent into
     an MPLS island are limited to the MPLS RSVP-TE format.
  
     For the MPLS-GMPLS-MPLS scenario, this requirement is to:
     - Map between Label Request and Generalized Label Request
     - Map between Label and Generalized Label
     - Introduce new objects when crossing into the GMPLS island
      where necessary for the successful operation of the GMPLS
      segment of the LSP. For example, to achieve alarm-free setup or
      teardown of the LSP.
     - Terminate GMPLS functionality at the edges of the GMPLS island,
      for example by correctly reflecting the Administrative Status
      object.
     - When the LSP setup reaches the egress from the GMPLS island we
      must try to map to MPLS-only objects. If this makes the LSP
      setup impossible, the setup must fail.
  
     Contiguous LSPs require less signaling state in the network than
     stitched LSPs (see above) and can be set up with a single
     signaling message exchange (that is, without pausing to set up
     the central stitching segment).
  
  6. Required mechanisms for other migration models
  
     The required mechanisms for other migration models are for
     future study.
  
  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
  
                           Expires January 2006                  [Page 13]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     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.
  
  8. IANA Considerations
  
     There are no IANA actions required by this draft.
  
  9. Acknowledgments
  
     The authors are grateful to Adrian Farrel for his numerous
     valuable comments.
  
  10.  References
  
  10.1.    Normative references
  
     [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
               Technology", BCP 79, RFC 3979, March 2005.
  
     [1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and
         G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
         RFC 3209, December 2001.
  
     [2] Berger, L., "Generalized Multi-Protocol Label Switching
         (GMPLS) Signaling Functional Description", RFC 3471, January
         2003.
  
     [3] Berger, L., "Generalized Multi-Protocol Label Switching
         (GMPLS) Signaling Resource ReserVation Protocol-Traffic
         Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
  
     [4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
         (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  
     [5] Smit, H. and T. Li, "Intermediate System to Intermediate
         System (IS-IS) Extensions for Traffic Engineering (TE)", RFC
         3784, June 2004.
  
     [6] Mannie, E., "Generalized Multi-Protocol Label Switching
         Architecture", RFC 3945, October 2004.
  
  10.2.    Informative references
  
     [7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in
         Resource ReSerVation Protocol - Traffic Engineering (RSVP-
         TE)", RFC 3477, January 2003.
  
     [8] Lang, J., "RSVP-TE Extensions in support of End-to-End
         GMPLS-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
         signaling, work in progress.
  
  
  
  
                           Expires January 2006                  [Page 14]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
     [9] Kompella, K. and Y. Rekhter, "Routing Extensions in Support
         of Generalized Multi-Protocol Label Switching", draft-ietf-
         ccamp-gmpls-routing, work in progress.
  
     [10] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
         Generalized Multi-Protocol Label Switching", draft-ietf-
         ccamp-ospf-gmpls-extensions, work in progress.
  
     [11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
         of Generalized MPLS", draft-ietf-isis-gmpls-extensions, work
         in progress.
  
     [12] Lang, J., "Link Management Protocol (LMP)", Internet-Draft,
         draft-ietf-ccamp-lmp, work in progress.
  
     [13] Bryant, S. and P. Pate, "PWE3 Architecture", Internet-Draft,
         draft-ietf-pwe3-arch, work in progress.
  
     [15] Shiomoto, K., "Requirements for GMPLS-based multi-region
         networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in
         progress.
  
     [16] Papadimitriou, D., "Generalized Multi-Protocol Label
         Switching (GMPLS) Protocol Extensions for  Multi-Region
         Networks (MRN)", draft-papadimitriou-ccamp-gmpls-mrn-
         extensions, work in  progress.
  
     [17] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions
         to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
  
     [18] Berger, L., "GMPLS Based Segment Recovery", draft-ietf-
         ccamp-gmpls-segment-recovery, work in progress.
  
     [19] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
         Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in
         progress.
  
     [20] Ayyangar, A. and J. Vasseur, "Inter domain MPLS Traffic
         Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-
         domain-rsvp-te, work in progress.
  
     [21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic
         Engineering", draft-ietf-ccamp-inter-domain-framework, work
         in progress.
  
     [22] Ali, Z., "Graceful Shutdown in MPLS Traffic Engineering
         Networks", draft-ali-ccamp-mpls-graceful-shutdown, work in
         progress.
  
     [23] Shiomoto, K., "Multi-area multi-layer traffic engineering
         using hierarchical LSPs in GMPLS networks", draft-shiomoto-
         multiarea-te, work in progress.
  
     [24] Le Roux, J., "Requirements for Inter-area MPLS Traffic
         Engineering", RFC 4105, June 2005.
  
     [25] Vasseur, J.P., Le Roux, J.L., "Routing extensions for
         discovery of Traffic Engineering Node Capabilities", draft-
         vasseur-ccamp-te-node-cap, work in progress.
  
     [26] Vasseur, JP (Ed.), "A Per-domain path computation method
         for computing Inter-domain Traffic Engineering (TE) Label
         Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-path-
         comp, work in progress.
  
                           Expires January 2006                  [Page 15]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
  
     [27] Farrel, A., Vasseur, JP., and Ash, G., "Path Computation
         Element (PCE) Architecture", draft-ietf-pce-architecture,
         work in progress.
  
     [28] Ayyangar, A., and Vasseur, JP., "Label Switched Path
         Stitching with Generalized MPLS Traffic Engineering", draft-
         ietf-ccamp-lsp-stitching, work in progress.
  
  11.  Authors' Addresses
  
     Deborah Brungard
     AT&T
     Rm. D1-3C22 - 200 S. Laurel Ave.
     Middletown, NJ 07748, USA
     Phone: +1 732 420 1573
     Email: dbrungard@att.com
  
     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
  
     Eiji Oki
     NTT
     Midori 3-9-11
     Musashino, Tokyo 180-8585, Japan
     Phone: +81 422 59 3441
     Email: oki.eiji@lab.ntt.co.jp
  
     Dimitri Papadimitriou
     Alcatel
     Francis Wellensplein 1,
     B-2018 Antwerpen, Belgium
     Phone: +32 3 240 8491
     Email: dimitri.papadimitriou@alcatel.be
  
     Daisaku Shimazaki
     NTT
     Midori 3-9-11
     Musashino, Tokyo 180-8585, Japan
     Phone: +81 422 59 4343
     Email: shimazaki.daisaku@lab.ntt.co.jp
  
     Kohei Shiomoto
     NTT
     Midori 3-9-11
     Musashino, Tokyo 180-8585, Japan
     Phone: +81 422 59 4402
     Email: shiomoto.kohei@lab.ntt.co.jp
  
  12.  Intellectual Property Statement
  
     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.
  
                           Expires January 2006                  [Page 16]


          draft-oki-ccamp-gmpls-ip-interworking-06.txt         July 2005
  
  
     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.
  
  13.  Disclaimer of Validity
  
     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.
  
  14.  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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                           Expires January 2006                  [Page 17]