CCAMP Working Group D. Brungard (ATT) Internet Draft J.L. Le Roux (FT) Expiration Date: August 2005 E. Oki (NTT) D. Papadimitriou (Alcatel) D. Shimazaki (NTT) K. Shiomoto (NTT) February 2005 IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration draft-oki-ccamp-gmpls-ip-interworking-05.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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document addresses the migration from Multi-Protocol 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 D.Brungard et al. - Expires August 2005 [Page 1] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 Segment Stitching . . . . . . . . . . . . . . . . . . 10 4.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1 LSP nesting . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 Contiguous LSPs . . . . . . . . . . . . . . . . . . . 13 4.2.3 LSP stitching . . . . . . . . . . . . . . . . . . . . 14 4.2.4 Discovery of GMPLS signaling capability . . . . . . . 14 5. Security considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative references . . . . . . . . . . . . . . . . . . . 15 8.2 Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . 20 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 D.Brungard et al. - Expires August 2005 [Page 2] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 infrastructure. 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 capabilities 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 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 D.Brungard et al. - Expires August 2005 [Page 3] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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). ................. .............................. .................. : 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 D.Brungard et al. - Expires August 2005 [Page 4] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 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 D.Brungard et al. - Expires August 2005 [Page 5] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 controlled infrastructure is used to bridge the disconnected GMPLS networks. 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. ................. .............................. : 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 D.Brungard et al. - Expires August 2005 [Page 6] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 across 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 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 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 D.Brungard et al. - Expires August 2005 [Page 7] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 GMPLS RSVP-TE signaling ([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. 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 object used for administration 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 D.Brungard et al. - Expires August 2005 [Page 8] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 signaling mechanisms required in order to bridge the difference between MPLS and GMPLS protocols. 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. D.Brungard et al. - Expires August 2005 [Page 9] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 [24] and [21]). 4.1.2 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.2.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 utilized 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.2.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 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 D.Brungard et al. - Expires August 2005 [Page 10] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 |<-------------------------------------------------------->| |<-------------------------------------------------------->| |<-------------------------------------------------------->| session for FA/LSP tunnel |<--------------------------->| e2e LSP _____________________________ <------------ | FA/LSP tunnel | -----------> <------------ | | -----------> <------------ | | -----------> |_____________________________| D.Brungard et al. - Expires August 2005 [Page 11] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 (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 Fig.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. A (transit) 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]). 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. Virtual FAs are defined in [MRN-REQ]. Note that the transit FA-LSP may be pre-established and advertised as an FA, or advertised as a virtual FA and signaled on demand, or triggered on demand by the GMPLS region border node as the result of an MPLS LSP setup request and then advertised as an FA. D.Brungard et al. - Expires August 2005 [Page 12] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 In the event of a change in traffic demand for the e2e LSP, if a transit FA-LSP 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.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 to give sufficient information to enable an operational path to be computed, or to enable that suitable crankback mechanisms are used. Another option is to make all border nodes capable of this conversion so that there are no issue. 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. D.Brungard et al. - Expires August 2005 [Page 13] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 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 signaling capability It may be useful to advertise into the IGP the capability of a node to support GMPLS signaling. This would allow every node in the network to automatically discover the GMPLS signaling regions. [25] provides GMPLS routing (IS-IS and OSPF) extensions for the advertisement of TE node capabilities, including control plane capabilities such as GMPLS signaling. 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 D.Brungard et al. - Expires August 2005 [Page 14] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 There are no IANA actions required by this draft. 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", RFC 3945, October 2004. 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-02 (work in progress), October 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 Generalized Multi-Protocol Label Switching", Internet-Draft, D.Brungard et al. - Expires August 2005 [Page 15] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 draft-ietf-ccamp-ospf-gmpls-extensions-12, October 2003. [11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized MPLS", Internet-Draft, draft-ietf-isis-gmpls- extensions-19, October 2003. [12] Lang, J., "Link Management Protocol (LMP)", Internet-Draft draft-ietf-ccamp-lmp-10, October 2003. [13] Bryant, S. and P. Pate, "PWE3 Architecture", Internet-Draft, draft-ietf-pwe3-arch-07, March 2004. [15] Shiomoto, K., "Requirements for GMPLS-based multi-region networks", draft-shiomoto-ccamp-gmpls-mrn-reqs-01 (work in progress), February 2005. [16] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)", draft-papadimitriou-ccamp-gmpls-mrn-extensions-01 (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-01 (work in progress), October 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-ietf-ccamp-inter- domain-rsvp-te-02 (work in progress), January 2005. [21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-domain-framework-01 (work in progress), July 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 D.Brungard et al. - Expires August 2005 [Page 16] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 Engineering", draft-ietf-tewg-interarea-mpls-te-req-02.txt (work in progress), June 2004. [25] Vasseur, J.P., Le Roux, J.L., "Routing extensions for discovery of Traffic Engineering Node Capabilities", draft-vasseur- ccamp-te-node-cap-00.txt (work in progress), February 2005. 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 D.Brungard et al. - Expires August 2005 [Page 17] draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005 Phone: +81 422 59 4402 Email: shiomoto.kohei@lab.ntt.co.jp 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. D.Brungard et al. - Expires August 2005 [Page 18]