CCAMP Working Group D. Brungard Internet-Draft AT&T Expires: April 25, 2005 J-L. Le Roux FT E. Oki NTT D. Papadimitriou Alcatel D. Shimazaki K. Shiomoto NTT October 25, 2004 IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration draft-oki-ccamp-gmpls-ip-interworking-04.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Brungard, et al. Expires April 25, 2005 [Page 1] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 This document addresses the migration from Multiprotocol Label Switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to expand the capacity of existing MPLS-based controlled infrastructure, networks consisting of L2SC, TDM, LSC, and FSC devices will be deployed, and these will be controlled by the GMPLS protocols. GMPLS protocols are, however, subtly different from MPLS protocols. This document describes possible migration scenarios, the mechanisms to compensate for the differences between MPLS and GMPLS protocols, and how the mechanisms are applied to migrate from a MPLS to a GMPLS network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Migration scenarios . . . . . . . . . . . . . . . . . . . . . 4 2.1 MPLS-GMPLS(non-PSC)-MPLS . . . . . . . . . . . . . . . . . 4 2.2 MPLS-GMPLS(PSC)-MPLS . . . . . . . . . . . . . . . . . . . 5 2.3 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) . . . . . . . . . . . . 5 2.4 GMPLS(PSC)-MPLS-GMPLS(PSC) . . . . . . . . . . . . . . . . 6 2.5 GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) . . . . . . . . . . . 6 3. Difference between MPLS and GMPLS protocols . . . . . . . . . 7 3.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Control plane/data plane separation . . . . . . . . . . . 9 3.4 Bi-directional LSPs . . . . . . . . . . . . . . . . . . . 9 4. Required mechanisms . . . . . . . . . . . . . . . . . . . . . 9 4.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1 TE link . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2 Forwarding adjacencies . . . . . . . . . . . . . . . . 10 4.1.3 Segment Stitching . . . . . . . . . . . . . . . . . . 13 4.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1 LSP nesting . . . . . . . . . . . . . . . . . . . . . 15 4.2.2 Contiguous LSPs . . . . . . . . . . . . . . . . . . . 16 4.2.3 LSP stitching . . . . . . . . . . . . . . . . . . . . 16 4.2.4 Discovery of GMPLS signalling capability . . . . . . . 17 5. Security considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Normative references . . . . . . . . . . . . . . . . . . . . 18 8.2 Informative references . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 22 Brungard, et al. Expires April 25, 2005 [Page 2] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 1. Introduction Multi-protocol label switching (MPLS) is widely deployed with applications such as traffic engineering and virtual private networks (VPN). Various kinds of services such as VoIP, IPv6, L2VPN/L3VPN, and pseudo wire emulation are expected to be converged over the MPLS-based controlled 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 Switching Capable (PSC) networks [6]). GMPLS networks will be deployed as a part of the existing MPLS infractructure. MPLS and GMPLS devices will coexist in the network until the existing MPLS network is completely migrated to the GMPLS network. GMPLS protocols are, however, subtly extending the capablities of 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, the mechanisms to compensate for the differences between MPLS and GMPLS, and the applicability of the mechanisms to the possible migration scenarios. 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. GMPLS introduces new features such as bi-directional LSPs, label suggestion, label restriction, graceful restart, graceful teardown, and forwarding adjacencies (see [6] ). Also, GMPLS 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 should bring these features and such distinct mechanisms into the existing MPLS-based controlled infrastructure network. The rest of this document is organized as follows. Section 2 outlines the migration scenarios from MPLS to GMPLS networks. Section 3 describes the problems caused by the differences between Brungard, et al. Expires April 25, 2005 [Page 3] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 MPLS and GMPLS protocols. Section 4 presents the required mechanisms which bridge the differences between MPLS and GMPLS protocols. Some of those mechanisms are available today and others are not. 2. Migration scenarios Three categories of migration scenarios are considered: (1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS and (3) MPLS-GMPLS. In the case of the MPLS-GMPLS-MPLS scenario, source and destination nodes of the Label Switched Path (LSP) are in MPLS networks, and a set of the LSP's transit nodes are in a GMPLS network. In the case of the GMPLS-MPLS-GMPLS scenario, the LSP source and destination nodes are in a GMPLS network, and a set of the LSP's transit nodes are in an MPLS network. Each category is subdivided in two sub-categories as to whether GMPLS is PSC or non-PSC except the category (3). Finally in the case of the MPLS-GMPLS migration scenario, LSP starts/ends in an MPLS network and ends/starts in a GMPLS PSC network. 2.1 MPLS-GMPLS(non-PSC)-MPLS 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 LSRs and subnetworks interconnected at the edges of the virtual network topology may form a single MPLS network. Figure 1 shows the reference network model for the MPLS-GMPLS(non-PSC)-MPLS migration. The model consists of three regions: ingress, transit, and egress. Both the ingress and egress regions are MPLS-based while the transit region is GMPLS-based. The nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5, and G6) are referred to as "border nodes". All nodes except the border nodes in the GMPLS-based transit region (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 region (say, R2) to a node in the egress MPLS-based region (say, R4). The LSP is referred to as the end-to-end (e2e) LSP. The switching capability of both end points of the e2e LSP are the same (PSC). Brungard, et al. Expires April 25, 2005 [Page 4] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 ................. .............................. .................. : MPLS : : GMPLS (non-PSC) : : MPLS : :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |: :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: : ________/ : : ________/ | ________/ : : ________/ : :| / : : / | / : : / : :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |: :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :................: :...........................: :................: |<-------------------------------------------------------->| e2e LSP Figure 1: MPLS-GMPLS(non-PSC)-MPLS migration model. 2.2 MPLS-GMPLS(PSC)-MPLS An MPLS-based network can be migrated to 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 stepwise migration from MPLS to a 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, such as bi-directional LSPs, label control, graceful restart, graceful teardown, and forwarding adjacencies. 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. 2.3 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) In this scenario, TDM or L2SC e2e LSPs are provisioned in the GMPLS network, which is disconnected. Since the MPLS-based controlled infrastructure network is widely deployed, it is used to bridge the disconnected GMPLS network. Pseudo wire emulation is used edge-to-edge in the MPLS-based converged network to carry those LSPs [13]. Figure 2 shows the reference network model for the GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration. Both the ingress and egress regions are GMPLS-based while the transit region is MPLS-based. All nodes in the GMPLS-based regions except the border Brungard, et al. Expires April 25, 2005 [Page 5] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 nodes (G1, G11, G2, G21, G71, G7, G81, and G8) are non-PSC devices. An e2e GMPLS LSP can be provisioned from a node in the ingress GMPLS-based region (say, G2) to a node in the egress GMPLS-based region (say, G8). The switching capability of both end points of e2e LSP must be the same. .................. ............................. .................. : GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) : :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |: :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: : ________/ : : ________/ | ________/ : : ________/ : :| / : : / | / : : / : :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: :|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |: :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :................: :...........................: :................: |<-------------------------------------------------------->| e2e LSP Figure 2: GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model. 2.4 GMPLS(PSC)-MPLS-GMPLS(PSC) In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS network, which is disconnected. The MPLS-based controleed infrastructure is used to bridge the disconnected GMPLS network. Since the MPLS-based controlled network is PSC, the GMPLS PSC LSP can cross MPLS-based converged network without extra treatment in data plane. 2.5 GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) In this scenario a LSP starts/ends in the GMPLS (PSC) network and ends/starts in the MPLS network. Some signaling conversion is required on border LSRs. Since both networks are PSC there is no data plane conversion at network boundaries. Figure 3 shows the reference model for this migration scenario. Head-End and Tail-end LSR are in distinct control plane regions." Brungard, et al. Expires April 25, 2005 [Page 6] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 ................. .............................. : MPLS : : GMPLS (PSC) : :+---+ +---+ +---+ +---+ +---+ :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 | :+---+ +---+ +---+ +-+-+ +---+ : ________/ : : ________/ | ________/ : : :| / : : / | / : : :+---+ +---+ +---+ +-+-+ +---+ :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 | :+---+ +---+ +---+ +---+ +---+ :................: :...........................: |<-------------------------------------------->| e2e LSP Figure 3: GMPLS-MPLS migration model.. 3. Difference between MPLS and GMPLS protocols 3.1 Routing TE-link information is advertised by the IGP using TE extensions. This allows LSRs to collect topology information for the whole network and to store it in the traffic-engineering data base (TEDB). Best-effort routes and/or traffic-engineered explicit routes are calculated using the TEDB. GMPLS extends the TE information advertised by the IGPs to include non-PSC information. The GMPLS extensions also apply to PSC networks. The GMPLS extensions may be carried transparently across MPLS networks and may be used 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. This may mean that it is impossible to compute a correct e2e LSP from one MPLS domain to another acorss a GMPLS domain. Figure 4 illustrates this problem. Suppose that an e2e LSP is provisioned 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 Brungard, et al. Expires April 25, 2005 [Page 7] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 capablities. 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 4: Problem mismatch of TE-link information in MPLS and GMPLS. MPLS and GMPLS use the same set of link state advertisements, to communicate network link state information, but the GMPLS network uses several additional TLVs/sub-TLVs not defined for MPLS (see [4], [5], [10], [11]). 3.2 Signaling GMPLS RSVP-TE signalling ([2]) introduces new objects, and their associated procedures, that can not be processed/inserted 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. Brungard, et al. Expires April 25, 2005 [Page 8] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 o The Admin Status object, used for LSP administration, and particularly for graceful LSP teardown. o The Recovery Label object used for Graceful Restart o The ADMIN-STATUS objedct used for administation and graceful deletion Also GMPLS introduces a new message, the Notify message, that is not supported by MPLS nodes." 3.3 Control plane/data plane separation TDM, LSC, FSC networks do not recognize packet delineation. In GMPLS, the control channel can be logically (in-band) or physically (out-of- band) separated from the data channel in those networks. The control channels between adjacent nodes constitute a control plane network. Control packets of routing and signaling protocols are transmitted over the control plane network. If the GMPLS network consists of only PSC devices, there can be no control plane/data plane separation. If the GMPLS network consists of PSC and non-PSC devices, there is at least a logical C/D separation between non-PSC devices, and between PSC and non-PSC devices. The GMPLS control plane, which is designed to carry the control packet in GMPLS network, is not likely to have enough capacity to carry the user-data traffic from MPLS network. Therefore, the control plane must ensure is it not carrying data traffic from the MPLS network (see [9]). 3.4 Bi-directional LSPs GMPLS provides bi-directional LSP setup - a single signaling session manages the bi-directional LSP, and forward and reverse 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, bi-directional LSPs from GMPLS network need to be carried in MPLS network. 4. Required mechanisms This section details the set of routing and signalling mechanisms required in order to bridge the difference between MPLS and GMPLS protocols. Brungard, et al. Expires April 25, 2005 [Page 9] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 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. A simple migration approach can also consist of separating MPLS and GMPLS networks into distinct IGP areas (possibly in distinct ASs), and then relying on multi-area (multi-AS) routing, path computation, and signaling solutions worked on in the CCAMP WG. Note: This section only proposes mechanisms for MPLS-GMPLS-MPLS migration scenario. GMPLS-MPLS-GMPLS and MPLS-GMPLS migration scenarios requirements will be addressed in a future revision of this document 4.1 Routing 4.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 regions. GMPLS TE-links are advertised into the MPLS regions as MPLS TE-links using MPLS-based TE link information. This requires some TE-link information conversion at the border nodes. 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. MPLS TE-links may be understood by the nodes in the GMPLS network, which can transform MPLS-based TE-link information into GMPLS-based TE-link information. This transformation can be performed by the border nodes or left to the individual GMPLS nodes. 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 see [24] and [21]). 4.1.2 Forwarding adjacencies FAs may be established within or across the GMPLS region. The FAs may be full FAs [19] or virtual FAs (see Section 4.1.2.2) and are advertised into the MPLS regions, by the routing protocol using MPLS TE-link information ( [10] and [11]). 4.1.2.1 Provisioned FAs PSC links may be advertised as forwarding adjacencies (FAs) in the Brungard, et al. Expires April 25, 2005 [Page 10] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 GMPLS-based region and advertised in the MPLS regions as TE links using MPLS-based TE information. Any FA that is established across the GMPLS region must be of type PSC so that is can be used by the MPLS PSC network. If the GMPLS network is not PSC, the border nodes are responsible for the appropriate adaptation. An e2e MPLS LSP may be tunnelled through one or more FAs across the GMPLS-based transit region. Multiple e2e MPLS LSPs may be tunnelled through a single FA [19]. Statistical multiplexing can be used to carry multiple e2e MPLS LSPs through a single FA-LSP thus making full use of bandwidth in the GMPLS region. Traffic engineering can be achieved within the GMPLS region by repositioning the FA-LSPs without impacting the e2e MPLS LSPs. Traffic engineering within the MPLS regions is performed by repositioning the e2e MPLS LSPs and possibly utilizing different FA-LSPs. A full mesh of FAs may be created between every border node. The merit of a full mesh of PSC FAs is that it provides stability to the MPLS-level routing. That is, the forwarding table of an MPLS LSR is not impacted by re-routing changes within the GMPLS region. Further, there is always full MPLS reachability and immediate access to bandwidth to support MPLS LSPs. However, the full mesh approach means that bandwidth is always pre-allocated within the GMPLS region. This might lead to congestion in the core of the region depending on the topology and number of border nodes. If the traffic demand does not necessitate a full mesh of FAs, the congestion could be avoided. 4.1.2.2 Virtual FAs If PSC FAs are used to enable MPLS PSC connectivity over part or all of a non-PSC GMPLS region it may be considered disadvantageous to pre-provision the FA-LSPs since this may reserve bandwidth within the GMPLS network that could be used for other LSPs in the absence of MPLS packet-based traffic. However, in order that the MPLS regions can route traffic across the GMPLS region, the FAs must still be advertised into the MPLS regions as TE links. Such TE links that represent the possibility of an FA are termed "virtual FAs". If an MPLS LSP is set up that makes use of a virtual FA, the underlying FA-LSP is immediately instantiated. The virtual FA-LSP may be initially pre-provisioned using techniques described in [8] for secondary LSPs in shared mesh restoration. A set of virtual FAs combined with a PSC links and pre-established Brungard, et al. Expires April 25, 2005 [Page 11] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 FAs forms the virtual topology for best-effort and/or traffic-engineered routes across the GMPLS region. The virtual topology may be designed taking into account the (forecast) traffic demand and the available resources in the GMPLS transit region. The virtual topology may change dynamically according to variations in the (forecast) traffic demand and the available resources to optimize the tradeoff between network performance and the residual network capacity. The virtual topology can be changed by setting up and/or tearing down virtual FA-LSP as well as by changes to real links and to real FAs. How to design the virtual topology and its changes is out of scope of this document. If virtual FAs are used in place of FAs, the TE links across the GMPLS-based transit region can remain stable using pre-computed paths while wastage of bandwidth within the GMPLS region, and unnecessary reservation of adaptation ports at the border nodes is avoided. Some consideration might be given to assigning higher costs to the TE links for virtual FAs when the underlying FA-LSP has not been established. This ensures that traffic is placed on existing FA-LSPs before new FA-LSPs are established. Note that, as for FAs, a virtual FA do not give rise to a routing adjacency. Further, until the supporting FA-LSP is established there can be no exchange of routing or signaling (e.g. RSVP Hello) messages between the end points of the virtual FA. 4.1.2.3 FA Utilization There are several possible schemes for determining how many FAs to provision, when to enable the FAs, and whether to choose FAs of virtual FAs, leading to specific mechanisms required for transitioning: 1. If there is low traffic demand, some FAs, which do not carry any e2e MPLS LSPs may be released so that resources in the GMPLS region are released. Alternatively, the FAs may be retained for future usage. Release or retention of under utilized FAs is a policy decision. Additional FAs may also be created based on policy, which might consider residual resources in the GMPLS-based transit region and the change of traffic demand across the region. By creating the new FAs, the network performance such as maximum residual capacity may be improved. 2. As the number of FAs grows, the residual resource in the GMPLS-based transit region may decrease. In this case, re-optimization may be invoked in the GMPLS-based transit region according the the policy. As part of the reoptimization process, FA-LSPs may be rerouted while keeping interface identifiers of FA links unchanged. The routing at the MPLS level is unaffected since there is no change to the topology of TE links composed of Brungard, et al. Expires April 25, 2005 [Page 12] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 FAs across the GMPLS-based transit region. 3. When residual resource in the GMPLS-based transit region decreases to a certain level, some FAs may be released according to policy. Ideally, only FAs that are not carrying e2e MPLS LSPs would be released, but in some cases it may be necessary to release FAs that are carrying traffic. The FA should be released only after the LSA associated with the FA has been withdrawn throughout the entire (MPLS and GMPLS) network. Once the LSA has been withdrawn, any e2e MPLS LSPs routed over the FA will be rerouted to use other FAs (by using other border nodes). The effect of this process on e2e MPLS LSPs that use the FAs that are being withdrawn can be reduced by using the graceful link withdrawal procedures described in [22]. 4.1.3 Segment Stitching There is a direct, one to one relationship between the e2e MPLS LSP and the stitched segment LSP that carries it across the transit region. In the control plane it is clear that there are two LSPs, but in the data plane, the stitching process means that there is actually a single end-to-end label switched path. If the transit region is PSC, the composite LSP is a simple PSC path from ingress to egress. But stitching is also applicable with non-PSC transit domains if appropriate adaptation function is available to map (or encapsulate) the packets to the appropriate signal. 4.1.3.1 Stitchable Segments with associated FAs Stitchable transit segments may be managed as FAs or virtual FAs with the consequent advertisement into the MPLS regions as TE links. Note, however, that because of the one-to-one relationship between the stitched segment and the e2e LSP, the TE link must be advertised as fully utilised as soon as a single e2e LSP is carried regardless of the relative bandwidths. Thus a stitching technique in a non-PSC GMPLS transit region may make inefficient use of resources. As an FA is in use, the ingress region will attempt to use make-before-break with resource sharing to modify the e2e LSP as required, and this may result in the e2e LSP being moved to a distinct FA TE link. 4.1.3.2 Stitchable Segments without associated FAs Stitching may also be used in the absence of FAs (or virtual FAs). This is particularly feasible when the network is partitioned into areas or ASs and the responsibility for routing the e2e MPLS LSP Brungard, et al. Expires April 25, 2005 [Page 13] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 across the transit domain is delegated to the border node. See [21] for more details of this applicability. As FAs are not used, the change in bandwidth requirement will be signaled as for the contiguous case with the expectation that the e2e MPLS LSP will be modified using resource sharing. When this happens the control plane managing the stitched segment must also act to increase the reserved bandwidth. This operation might not be necessary if cross-technology stitching (such as PSC to TDM) is in use. 4.2 Signaling Three basic cases for the MPLS-GMPLS-MPLS environment are described in Figure 4 : LSP nesting, LSP converting, and LSP stitching. 1. LSP nesting: One or more e2e MPLS packet LSPs is nested into one GMPLS LSP that may be PSC or non-PSC. 2. Contiguous LSP: The e2e MPLS packet LSP signaling messages ([7]) are translated at the GMPLS region border into GMPLS RSVP-TE messages (see [3]), and are converted back again at the MPLS region border. The GMPLS RSVP-TE segment MUST also be PSC. This case requires a service interworking function mapping between [1] and [3] at the control plane level. 3. LSP stitching: An e2e packet LSP is constructed by stitching MPLS PSC LSP segments together with a transit GMPLS LSP. The transit LSP would normally be PSC, but there is no reason to exclude non-PSC LSPs provided that the right adaptation is available in the data plane at the border nodes. The stitching model requires identical function in the control plane to that used for nesting, but a strict one-to-one relationship between LSP segments must be maintained. ................. .............................. .................. : MPLS : : GMPLS (PSC) : : MPLS : :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |: :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: : ________/ : : ________/ | ________/ : : ________/ : :| / : : / | / : : / : :+---+ +---+ +---+ +-+-+ +---+ +---+ +---+: :|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |: :+---+ +---+ +---+ +---+ +---+ +---+ +---+: :................: :...........................: :................: session for e2e LSPs |<-------------------------------------------------------->| |<-------------------------------------------------------->| Brungard, et al. Expires April 25, 2005 [Page 14] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 |<-------------------------------------------------------->| session for FA/LSP tunnel |<-------------------------->| e2e LSP _____________________________ <------------ | FA/LSP tunnel | -----------> <------------ | | -----------> <------------ | | -----------> |_____________________________| (a) LSP nesting e2e session |<-------------------------------------------------------->| ____________ ____________________________ ____________ | MPLS seg. || GMPLS segment || MPLS seg. | |____________||____________________________||____________| (b) Contiguous LSP e2e session |<-------------------------------------------------------->| transit session |<-------------------------->| ____________ ____________________________ ____________ | MPLS seg. || GMPLS segment || MPLS seg. | |____________||____________________________||____________| (c) LSP stitching Figure 5: Comparisons of signaling in MPLS-GMPLS-MPLS migration model. 4.2.1 LSP nesting LSP nesting applies to the MPLS-GMPLS(non PSC)-MPLS and the MPLS-GMPLS(PSC)-MPLS migration scenarios. Figure 5 (a) illustrates LSP nesting in the MPLS-GMPLS-MPLS reference network. An FA-LSP is created across the GMPLS region to carry one or more e2e MPLS PSC LSPs. The FA-LSP is advertised as a TE link. Signaling messages are used to exchange the link identifiers for FAs/virtual FAs in a similar way to that described in [7] and [19] for FA-LSPs. The LSP_TUNNEL_INTERFACE_ID object is forwarded transparently by transit LSRs to the FA tail-end (see [7]). Brungard, et al. Expires April 25, 2005 [Page 15] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 Activation of the virtual FA may use techniques similar to those described in [8] for secondary LSPs in mesh recovery and is for further study. Both unnumbered and numbered link identifiers for FAs/virtual FAs should be supported. 4.2.2 Contiguous LSPs The contiguous LSP technique is only applicable when the GMPLS-based transit region is PSC i.e. only applicable for the MPLS-GMPLS(PSC)-MPLS migration scenario. Figure 5 (b) illustrates a contiguous LSP in the MPLS-GMPLS-MPLS reference network model. The e2e LSP consists of three segments: ingress, transit, egress. The transit segment is GMPLS-based and therefore it is referred to as GMPLS-segment while others are referred to as MPLS-segments. The e2e MPLS LSP is associated with the single session, which is referred to as the "e2e" session. Contiguous LSPs rely on the availability of control plane conversion or mapping of the signaling messages as they cross the region boundaries and are, therefore, only available when a significant set of border nodes have this capability. Specifically the entry and exit points to the GMPLS-based transit region used by an e2e MPLS LSP must be capable of converting the signaling messages. If either node is not capable of this function, the LSP setup will fail. Therefore, the node capabilities SHOULD be advertised by the border nodes give sufficient information to enable an operational path to be computed, or that suitable crankback mechanisms are used. Another option is to make all border nodes capable of this conversion so that there are no issues. Contiguous LSPs may be modified according to traffic demand changes for the e2e LSP just as modifications may be made to a simple MPLS LSP. That is, make-before-break with resource sharing may be used to increase or decrease the bandwidth of the whole LSP. 4.2.3 LSP stitching LSP stitching applies to the MPLS-GMPLS(non PSC)-MPLS and the MPLS-GMPLS(PSC)-MPLS migration scenarios. Figure 5 (c) illustrates LSP stitching in the MPLS-GMPLS-MPLS reference network. A single e2e LSp is constructed in the data plane from one segment in each region - the segments are stitched together simply if all segments are packet-based, or through an adaptation function if the middle segment is not a PSC LSP. Brungard, et al. Expires April 25, 2005 [Page 16] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 In the control plane there are two sessions as there would be for LSP nesting. However, only one e2e MPLS LSP can be carried by a single transit segment if stitching is used. Note that the transit segment may be pre-established and advertised as an FA, advertised as a virtual FA and signaled on demand, or established on demand by the GMPLS region border node as the result of an MPLS LSP setup request. In the event of a change in traffic demand for the e2e LSP the behavior depends on whether FAs are being used: - If an FA is in use, the ingress region will attempt to use make-before-break with resource sharing to modify the e2e LSP as required, and this may result in the e2e LSP being moved to a distinct FA TE link. - If FAs are not used, the change in bandwidth requirement will be signaled as for the contiguous case with the expectation that the e2e LSP will be modified using resource sharing. When this happens the control plane managing the stitched segment must also act to increase the reserved bandwidth. This operation might not be necessary if cross-technology stitching (such as PSC to TDM) is in use. 4.2.4 Discovery of GMPLS signalling capability It may be useful to advertise into the IGP the capability of a node to support GMPLS signalling. This would allow every node in the network to automatically discover the GMPLS signalling regions. [25] provides a functional description of routing extensions in order to advertise TE router information, including control plane capabilities such as GMPLS signaling. As there are several options for how the regions 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 may make sense to only advertise the border nodes that are capable of signaling conversion since it is impossible to set up e2e LSPs through other border nodes. In the first case, however, the full topology is visible across the entire network and it is important that the specific conversion capabilities of the border nodes are advertised [25]. Note that in the case of contiguous LSPs, there is a one-to-one relationship between LSPs in the MPLS region and LSPs in the GMPLS region. 5. Security considerations There are not security issues in this draft. 6. IANA Considerations There are no IANA actions required by this draft. Brungard, et al. Expires April 25, 2005 [Page 17] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 7. Acknowledgments The authors are grateful to Adrian Farrel for his numerous valuable comments. 8. References 8.1 Normative references [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", draft-ietf-ccamp-gmpls-architecture-07 (work in progress), May 2003. 8.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-01 (work in progress), May 2004. [9] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09 (work in progress), October 2003. [10] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Brungard, et al. Expires April 25, 2005 [Page 18] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in progress), October 2003. [11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19 (work in progress), October 2003. [12] Lang, J., "Link Management Protocol (LMP)", draft-ietf-ccamp-lmp-10 (work in progress), October 2003. [13] Bryant, S. and P. Pate, "PWE3 Architecture", draft-ietf-pwe3-arch-07 (work in progress), March 2004. [14] Vigoureux, M., "Generalized MPLS Architecture for Multi-Region Networks", draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04 (work in progress), February 2004. [15] Shiomoto, K., "Requirements for GMPLS-based multi-region and multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs-00 (work in progress), October 2004. [16] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)", draft-papadimitriou-ccamp-gmpls-mrn-extensions-00 (work in progress), October 2004. [17] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07 (work in progress), September 2004. [18] Berger, L., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery-00 (work in progress), April 2004. [19] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress), September 2002. [20] Ayyangar, A. and J. Vasseur, "Inter domain MPLS Traffic Engineering - RSVP-TE extensions", draft-ayyangar-ccamp-inter-domain-rsvp-te-00 (work in progress), July 2004. [21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel-ccamp-inter-domain-framework-01 (work in progress), July 2004. Brungard, et al. Expires April 25, 2005 [Page 19] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 [22] Ali, Z., "Graceful Shutdown in MPLS Traffic Engineering Networks", draft-ali-ccamp-mpls-graceful-shutdown-00 (work in progress), June 2004. [23] Shiomoto, K., "Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks", draft-shiomoto-multiarea-te-01.txt (work in progress), June 2002. [24] Le Roux, J., "Requirements for Inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req-02.txt (work in progress), June 2004. [25] Vasseur, J. and J. Le Roux, "Routing extensions for discovery of TE router information", draft-vasseur-ccamp-te-router-info-00.txt (work in progress), July 2004. 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: EMail: jeanlouis.leroux@francetelecom.com Brungard, et al. Expires April 25, 2005 [Page 20] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 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 Brungard, et al. Expires April 25, 2005 [Page 21] Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004 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. 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. 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Brungard, et al. Expires April 25, 2005 [Page 22]