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]