CCAMP Working Group Deborah Brungard (AT&T) Internet Draft Jean-Louis Le Roux (France Telecom) Expiration Date: December 2004 Eiji Oki (NTT) Dimitri Papadimitriou (Alcatel) Daisaku Shimazaki (NTT) Kohei Shiomoto (NTT) July 2004 Migrating from IP/MPLS to GMPLS networks draft-oki-ccamp-gmpls-ip-interworking-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. [Page 1] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Abstract This document is addressing the migration from Multi-protocol label switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to expand the capacity of the existing MPLS-based infrastructure network, the optical network consisting of L2SC, TDM, LSC, and FSC devices will be deployed, which is controlled by the GMPLS protocols. GMPLS protocols are, however, subtly different from MPLS protocols. In this document we describe possible migration scenarii, the mechanisms to compensate the difference between MPLS and GMPLS protocols, and how the mechanisms are applied to migrate from the MPLS to the GMPLS network. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 1. Introduction Multi-protocol label switching (MPLS) is widely deployed with applica- tions such as traffic engineering and virtual private network (VPN). Various kinds of services such as VoIP, IPv6, L2VPN/L3VPN, pseudo wire emulation are expected to be converged over the MPLS-based infrastruc- ture network. Traffic volume is tremendously increasing as broadband service enabled by ADSL and FTTH is rapidly penetrating the market and the processing performance of terminal and server is ever increasing. In order to cope with such increase of the traffic volume, optical networks, which con- sists of L2SC, TDM, LSC, and FSC devices, will be introduced. Generalized MPLS (GMPLS) is being standardized by extending MPLS to con- trol such optical networks (see [RFC3471], [RFC3473], [GMPLS-ROUTING], [GMPLS-OSPF], [GMPLS-ISIS], [GMPLS-LMP]). GMPLS network 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 com- pletely migrated to the GMPLS network. GMPLS protocols are, however, subtly extending MPLS protocols' capabili- ties. In order to migrate from the existing MPLS to the GMPLS network, we need to define mechanisms to compensate the difference between MPLS [Page 2] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 and GMPLS. In this document we discuss the migration scenarii from MPLS to GMPLS networks, the mechanisms to compensate the difference between MPLS and GMPLS, and the applicability of the mechanisms to the possible migration scenarii. We should note that GMPLS covers Packet Switching Capable (PSC) networks [GMPLS-ARCH]. In the rest of this document, when dealing with GMPLS, it means both PSC and non-PSC. Otherwise PSC GMPLS or non-PSC GMPLS is explicitly mentioned. GMPLS introduces new features such as bidirectional LSPs, label sugges- tion, label restriction, graceful restart, graceful teardown, and for- warding adjacencies (see [GMPLS-ARCH]). Also several features are pro- vided in a distinct manner. For instance local protection is provided using distinct mechanisms in MPLS (see [MPLS-FRR]) and GMPLS (see [GMPLS-SR]). Migration from MPLS to GMPLS should bring these features and such distinct mechanisms in the existing MPLS-based infrastructure network. The rest of this document is organized as follows. In Section 2, we taxonomize the migration scenarii from MPLS to GMPLS networks. In Sec- tion 3, we describe the problems caused by the difference between MPLS and GMPLS protocols. In Section 4, we present the required mechanisms, which bridge the difference between MPLS and GMPLS protocols. Some of those mechanisms are available today and others are not. In Section 5, we present the applicability of the required mechanisms to a reference network model for the migration from MPLS to GMPLS networks. 2. Migration scenarii Two categories of migration scenarii are considered: (1) MPLS-GMPLS-MPLS and (2) GMPLS-MPLS-GMPLS. In case of (1) MPLS-GMPLS-MPLS scenario, source and destination nodes of the Label Switched path (LSP) are in MPLS and a set of its intermediate nodes take part of GMPLS. In case of (2) GMPLS-MPLS-GMPLS scenario, LSP source and destination nodes are in GMPLS network and a set of its intermediate nodes take part of MPLS net- work. Each category is subdivided in two sub-categories as to whether GMPLS is PSC or non-PSC. MPLS-GMPLS (PSC) migration scenario, where LSP start/end in an MPLS net- work and end/start in a GMPLS PSC network, will be addressed in a future revision. [Page 3] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2.1. MPLS-GMPLS(non-PSC)-MPLS Introduction of a GMPLS-based optical core network to increase the capacity is an example of this category. TDM, LSC, and/or FSC LSPs are established between MPLS networks across the GMPLS network. A set of those LSPs provide virtual network topology for MPLS networks. This topology may be reconfigurable by adding and/or removing those LSPs [MRN]. MPLS LSRs and subnetworks interconnected at the edges of the vir- tual network topology may form a single MPLS network. Figure 1 shows the reference network model for the MPLS-GMPLS(non- PSC)-MPLS migration. The reference network 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 node" hereafter. All nodes except the border nodes in the GMPLS-based transit region (G3 and G4) are non-PSC device, i.e., optical equipment (TDM, LSC, and FSC). An MPLS LSP can be provi- sioned 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 "e2e" LSP hereafter. The switching capability of both end points of 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. [Page 4] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2.2. MPLS-GMPLS(PSC)-MPLS MPLS-based converged network can be migrated to GMPLS (PSC)-based con- verged network. The rationale of this type of migration scenario is supported by two factors: (1) GMPLS-based advanced feature, (2) stepwise migration for the GMPLS-based optical core network. Regarding the GMPLS-based advanced feature, numerous features are being developed in GMPLS context (and MPLS) including bi-directional LSP, label control, graceful restart, graceful teardown and forwarding adjacencies. Exist- ing MPLS-based converged network could be migrated to GMPLS (PSC)-based converged network to deliver the advanced features. Once the PSC network is migrated to GMPLS-based one, it could be migrated to GMPLS-based optical core network with less effort. 2.3. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS net- work, which is partly disconnected. In case the MPLS-based infrastruc- ture network is widely deployed, it is used to bridge the disconnected GMPLS networks. Moreover, pseudo wire emulation is used edge-to-edge in the MPLS-based converged network to carry those LSPs [PWE3]. Figure 2 shows the reference network model for the GMPLS(non-PSC)-MPLS- GMPLS(non-PSC) migration. The reference network model consists of three regions: ingress, transit, and egress. Both the ingress and egress regions are GMPLS-based while the transit region is MPLS-based. The nodes at the boundary of the MPLS and GMPLS regions (G3, G4, G5, and G6) are referred to as "border node" hereafter. All nodes except the border nodes in the GMPLS-based regions (G1, G11, G2, G21, G71, G7, G81, and G8) are non-PSC devices. A 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 LSP is referred to as the "e2e" LSP here- after. The switching capability of both end points of e2e LSP must be the same. [Page 5] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 .................. ............................. .................. : 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 net- work, which is partly disconnected. In case the MPLS-based infrastruc- ture network is widely deployed, it is used to bridge the disconnected GMPLS networks. Since MPLS-based network is PSC, the GMPLS PSC LSP can cross MPLS-based converged network without extra treatment in data plane. 3. Difference between MPLS and GMPLS protocols 3.1. Routing In this document we assume that the OSPF-TE is used as IGP-TE. However the IGP-TE description should apply to both IS-IS and OSPF. Specifics concerning IS-IS will be detailed in the next release of this document. TE-link information is advertised in link state advertisement. It allows collecting the whole topology information, which is stored in traffic-engineering data base (TEDB). Best-effort route and/or traffic- engineered explicit route for the destination are calculated using the TEDB. [Page 6] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 GMPLS extends the set of sub-TLVs for TE-link advertisements. Non-PSC TE-link information used in GMPLS is not supported by MPLS. Even PSC TE- link information used in GMPLS is not fully supported by MPLS (this is particularly the case for the Interface Switching Capability Descriptor sub-TLV). As a result, one cannot compute traffic-engineered explicit route if they are travelling through both MPLS and GMPLS regions. Figure 3 illustrates the problem of mismatch of TE-link information in MPLS and GMPLS. Suppose that an e2e LSP is provisioned between R2 and R4 and that we need to compute the path between R2 and R4 (say, R2-R21-G2-G4-G6-R41-R4). The TE link information for the links R2-R21, R21-G2, G6-R41 and R41-R4 is MPLS-based TE link LSA, while the ones for the links G2-G4 and G4-G6 is GMPLS-based. The node in MPLS-based ingress region (say, R2) cannot compute the path, which consists of mix- ture of MPLS-based and GMPLS-based TE link 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 3 Problem mismatch of TE-link information in MPLS and GMPLS Except for Opaque-LSA associated with TE-link, MPLS and GMPLS use the same set of LSAs, e.g., router-LSA, network-LSA, summary-LSA and etc. These LSAs in GMPLS network construct the topology database of the con- trol plane of GMPLS network. 3.2. Signaling GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and their associated procedures, that can not be processed/inserted by MPLS LSRs: [Page 7] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 - The (Generalized) Label Request object (new C-Type), used to iden- tify the LSP encoding type, the switching type and the generalized protocol ID (G-PID) associated with the LSP. - The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID ERO/RRO subobjects that handle the Control plane/Data plane separa- tion in GMPLS network. - The Suggested Label Object, used to reduce LSP setup delays. - The Label Set Object, used to restrict label allocation to a set of label, which (particularly useful for wavelength conversion inca- pable nodes) - The Upstream Label Object, used for bidirectional LSP setup (see also 3.4) - The Restart Cap object, used for graceful restart. - The Admin Status object, used for LSP administration, and particu- larly for graceful LSP teardown. 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. Con- trol 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 con- trol plane/data plane separation. All control packets share the same network links with data packets. If the GMPLS network consists of non- PSC devices, there is at least a logical C/D separation at least between PSC device and non-PSC device in GMPLS networks and between non-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 [GMPLS-ROUTING]). [Page 8] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 3.4. Bi-directional LSP Since GMPLS supports TDM, LSC, and FSC switching and LSP classes, which are mainly bi-directional channels, it also provides bi-directional LSP setup. In a single signaling session, bi-directional LSPs can be created along the same route in GMPLS network. On the other hand, there is no equivalent mechanism to support bi-directional LSPs in MPLS network. The forward and backward LSPs are created in different signaling sessions. The route taken by those LSPs may be different from each other. Their sessions are treated differently from each other. If MPLS and GMPLS networks are inter-connected, the bi-directional LSPs from GMPLS network need to be carried in MPLS network, which does not support bi-directional LSP setup. At least we need a mechanism allowing to route the forward and backward LSPs on the same route. 4. Required mechanism In this section, we present at set of routing and signalling mechanisms, in order to bridge the difference between MPLS and GMPLS protocols. This section only proposes mechanisms for MPLS-GMPLS-MPLS migration. GMPLS-MPLS-GMPLS (using PWE3 stuff) is for further study. 4.1. Routing The entire network consisiting of ingress, transit, and egress regions (See Fig.1 or 2 for instance) may be either single-area or multi-area from the IGP perspective. 4.1.1. Single-area If the entire network is a single-area, the partial topology of GMPLS- based region, which is consisting of PSC-link, should be visible to MPLS regions. GMPLS TE-links are advertised as MPLS TE-links using MPLS- based TE link information to the MPLS networks so that node in the MPLS region can understand the GMPLS TE-links. This requires some TE-link [Page 9] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 information conversion. If the GMPLS-based region consists of only non-PSC devices except the border nodes, PSC-links should be set up between the border nodes. For example, in Fig. 3, a PSC-link can be set up between G2 and G6. PSC- links are advertised as the forwarding adjacency (FA) in the GMPLS- based region. The e2e LSP can be tunnelled through the FA [HIER]. In the MPLS to GMPLS migration scenarii, FA should be advertised as TE- links in the MPLS regions, using MPLS-based TE-link information. A set of FAs across the GMPLS region provides the virtual network topol- ogy (VNT), which can be reconfigured by creating and/or destroying FAs, to MPLS regions. See [MRN] for details. 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. 4.1.1.1. Virtual FA If the entire network consists of a single IGP area and the GMPLS-based region consists of only non-PSC devices except the border nodes, FAs should be set up between the GMPLS border nodes. To avoid unnecessary bandwidth consumption non-PSC FA LSP should be created only if there exists traffic demand between the end points. In order to compute the path across the GMPLS region, the FA-LSP must be set up for being advertized as per [HIER]. The "virtual" FA-LSP is defined here to cope with the situation. The virtual FA-LSP is not instantiated but is advertised as a TE-link by routing protocol to attract traffic. The virtual FA may be provisioned using the similar method for provisioning the secondary LSP in the shared mesh restoration scheme [P&R]. Or the virtual FA may be just signalled between both end points without having the transit nodes intervene. A set of virtual FAs forms the virtual topology for the best-effort and/or the traffic-engineered route across the GMPLS region. The virtual topology may be designed taking into account the (forecast) traffic demand and the available resource in the transit region. The virtual topology may dynamically change according to the variation of the (fore- cast) traffic demand and the available resource in the transit region to optimize the tradeoff between network performance and the residual net- work capacity. How to design the virtual topology and its changes is out of scope of this document. The virtual topology is changed by setting up and/or tearing down [Page 10] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 virtual FA-LSP. Signaling messages are used to exchange the link iden- tifiers in a similar way of the FA as described in [RFC3477] and [LSP- HIER]. Unlike the case of FA-LSP, the intermediate nodes may not be involved in signaling message processing when the virtual FA-LSP is not provisioned (Just link interface identifiers are exchanged by signaling between ingress and egress nodes). Both unnumbered and numbered virtual FAs should be defined. There is no routing adjacency along the (virtual) FA. There is no hello packets exchanged between the end points of the (virtual) FA. When an e2e MPLS LSP is setup through a virtual FA, this should trigger the setup of a real FA-LSP is the GMPLS network. 4.1.2. Multi-area A simple migration approach can also consist in separating MPLS and GMPLS networks into distinct IGP areas, and then rely on multi-area routing, path computation, and signaling solutions under specification in CCAMP WG (ABR acting as a Path Computation Element for instance). Basicaly there is no backward compatibility issue when MPLS and GMPLS LSRs resides in disctinct IGP areas, as TE-link information is not leaked across area (see see [INTER-AREA-REQ] and [INTER-Domain]). 4.2. Signaling We describe the signaling mechanisms, which can be applied to the migra- tion scenarii from MPLS to GMPLS. Three basic cases for the MPLS-GMPLS- MPLS environment are described in Fig. 4: LSP nesting, LSP converting, and LSP stitching. LSP nesting: One or more packet LSPs is nested into one LSP. LSP converting: The end-to-end packet LSP signaling messages (RFC 3209) is translated at the GMPLS borders into GMPLS RSVP-TE (see RFC 3473). The GMPLS RSVP-TE segment MUST also be PSC. This case requires a ser- vice interworking function 3209/3473 (at the control plane level). LSP stitching: A segment PSC LSP is stitched within an end-to-end packet LSP. This case does require a network interworking function (at the control plane level) since MPLS signaling messages are directed between GMPLS border nodes. [Page 11] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 ................. .............................. .................. : 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 | -----------> <------------ | | -----------> <------------ | | -----------> |_____________________________| (a) LSP nesting e2e session |<-------------------------------------------------------->| ____________ ____________________________ ____________ | MPLS seg. || GMPLS segment || MPLS seg. | |____________||____________________________||____________| (b) LSP converting e2e session |<-------------------------------------------------------->| transit session |<-------------------------->| ____________ ____________________________ ____________ | MPLS seg. || GMPLS segment || MPLS seg. | |____________||____________________________||____________| (c) LSP stitching Figure 4 Comparisons of signaling in MPLS-GMPLS-MPLS migration model. [Page 12] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 4.2.1. LSP nesting Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS refer- ence network model. An FA-LSP is created by setting up the FA-LSP. FA is established between the boundary of the ingress and the transit regions and that of the transit and the egress regions. Three e2e LSPs are provisioned between the nodes in the MPLS-based ingress region (say, R2) and egress region (say, R4). These e2e LSPs are tunnelled inside the same FA-LSP across the transit region. LSP nesting is different from the LSP stitching and the LSP converting with respect to data plane. The e2e LSP is nested inside the FA while there is no nesting in the LSP stitching and the LSP converting. Multi- ple e2e LSPs can be nested inside a single FA-LSP. Scalability is hereby attained. There exist at least two sessions: one for the FA-LSP and the others for e2e LSP(s). Along the FA-LSP, the state is created and maintained dur- ing the life-time of the FA-LSP. When the FA-LSP is re-routed (for example due to re-optimization, failure recovery, etc.), the FA link is not impacted as long as the alternative FA-LSP exists. FA-LSP mechanism applies to MPLS-GMPLS (non PSC)-MPLS and MPLS-GMPLS (PSC)-MPLS migration scenarii. 4.2.2. LSP converting LSP can be converted from MPLS to GMPLS and vice versa at the boundary of MPLS and GMPLS regions while remaining in the same session. This is achieved by delivering an interworking function at the control plane of the GMPLS border nodes. Figure 4 (b) illustrates the LSP converting in the MPLS-GMPLS-MPLS reference network model. The e2e LSP is provisioned between the nodes in the MPLS-based ingress region (say, R2) and egress region (say, R4). 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-seg- ments. The e2e LSP is associated with the single session, which is referred to as the "e2e" session. This is relevant only for MPLS-GMPLS (PSC)-MPLS migration scenario. 4.2.2.1. MPLS->GMPLS LSP is converted from MPLS to GMPLS at the boundary of MPLS ingress and GMPLS transit regions. In case of C/D separation in the GMPLS transit [Page 13] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 region, the signaling message is separated from the data plane network at the boundary. Regarding the control plane, the signaling message associated with the e2e LSP is carried in the control plane network in the GMPLS transit region. Appropriate objects newly defined for GMPLS (say, Generalized label request object) is attached to the signaling message. 4.2.2.2. GMPLS->MPLS LSP is converted from GMPLS to MPLS at the boundary of GMPLS transit and MPLS egress regions. In case of C/D separation in the GMPLS transit region, the signaling message from the data plane network is multiplexed to the data plane message at the boundary. LSP is converted with respect to both the control and the data plane aspects. Regarding the control plane aspect, the signaling message objects, which are not supported by MPLS, are lost. The associated functions are not, therefore, effective in MPLS network accordingly. GMPLS-segment is either uni-directional or bi-directional. There is no mechanism to set up the bi-directional MPLS LSPs within the same session along the same route. 4.2.2.3. ERO/RRO processing There are three cases depending on the level of detail of the transit segment specified as part of the EROs issued in the Path message issued by the ingress of the e2e LSP. 1) The ERO issued by the ingress of the e2e LSP includes the tail-end of the transit segment as a strict subobject. Then, if the head- end of the transit segment is also included as a strict node, in this case ERO processing follows rules described in Section 8.2 of [LSP-HIER] as the sequence of the transit segment is complete once issued by the ingress of the e2e LSP. Otherwise, if the head-end node of the transit segment (or any other subobject preceding the tail-end) is specified as a loose subobject, the preceding strict node inserts the sequence of subobjects within the ERO as specified in [RFC 3209] to reach the next loose node. [Page 14] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 2) The ERO issued by the ingress of the e2e LSP includes both head- (strict or loose) and tail-end (loose) of the transit segment. In this case, the ingress GMPLS border node inserts sequence of subob- jects within the ERO as specified in [RFC 3209] to reach the egress border node. 3) The ERO issued by the ingress of the e2e LSP does not include the tail-end of the transit segment. In this case, the ingress border node should decide the exit point to reach the next loose node being outside of the transit region. RROs in the transit segment may carry the nodes in the transit region. The nodes in the transit segment may be removed from the RROs when they depart from the transit region. The ingress and egress border nodes should be included in the RROs when they are carried in the ingress and the egress regions. 4.2.3. LSP stitching LSP can be stitched at the boundary of MPLS and GMPLS regions [Inter- domain]. The LSP stretches from the ingress through the transit to the egress regions. Figure 4 (c) illustrates the LSP stitching in the MPLS- GMPLS-MPLS reference network model. The e2e LSP is provisioned between the nodes in the MPLS-based ingress region (say, R2) and egress region (say, R4). The e2e LSP consists of two segments: ingress/egress and transit. The transit segment is GMPLS-based and therefore it is referred to as GMPLS-segment while others are referred to as MPLS-seg- ments. The e2e LSP is associated with the two sessions: one for the entire stretch (i.e., ingress to egress regions) and the other for the transit segment. The signaling mechanisms described in [INTER-DOMAIN- SIG] can be applied. 4.2.4. Discovery of GMPLS signalling capability I 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. [TE-INFO] provides a functional description of routing extensions in order to advertise TE router information, including Control Plane Capabilities such as GMPLS signaling. [Page 15] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 5. MPLS-GMPLS-MPLS reference model In this section, the required mechanisms with the MPLS-GMPLS-MPLS refer- ence network model is discussed. FA/LSP tunnel, LSP converting, and LSP stiching are applied to the reference network model. From Figure 1, we consider that the packet LSP is set up between the ingress and the egress regions. The LSP is referred to as "e2e" LSP hereafter. The LSP portion corresponding to the transit GMPLS-base region is referred to as "transit segment". The transit segment is implemented by either (1) LSP nesting, (2) LSP converting, or (3) LSP stitching. 5.1. LSP nesting 5.1.1. Basic description FAs are created between the GMPLS border nodes. The FAs are advertised in the MPLS regions, by the routing protocol, using MPLS TE-link infor- mation ([OSPF-TE] or [ISIS-TE]). The e2e LSP is tunneled through the FA across the GMPLS-based transit region. Multiple e2e LSPs may be tunnelled through a single FA. The e2e LSP may be carried over multiple hops of FAs across the GMPLS-based transit region unless there is no direct FA between the ingress and the egress regions. 5.1.2. Traffic demand change Traffic demand may change after the FA is created. Some FAs, which do not carry any e2e LSP any longer may be released for resource release. They may be also retained for future usage. Release or retention of underutilized FAs is a policy decision. Detail of the policy is out of scope of this document. FAs may be created based on the policy, which might consider residual resource in GMPLS-based transit region and the change of traffic demand. By creating the new FAs, the network performance such as maximum resid- ual capacity may be improved. 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. [Page 16] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Detail of the policy is again out of scope of this document. As part of the reoptimization process, FA-LSPs may be rerouted while keeping interface identifiers of FA links unchanged. However, the rout- ing in MPLS level should be unaffected since there is no change of topology composed of FAs across the GMPLS-based transit region. When residual resource in the GMPLS-based transit region decreases, some FAs may be released according to the policy. Detail of the policy is again out of scope of this document. The FA should be released only after the LSA associated with the FA is deleted throughout the network. Once the LSA is deleted, the e2e LSPs routed over the FA are expected to get rerouted around the FA. 5.1.3. Nest of FAs E2e LSP can be tunneled into the PSC or non-PSC FA LSPs established between GMPLS border nodes. Further nesting can also occur within the GMPLS network (see [LSP-HIER]). Full mesh of PSC FA-LSPs may be created between every border nodes using a set of non-PSC FA-LSPs across the GMPLS-based transit region [MAMLTE]. The merit of this mechanism is to attain the stability of MPLS-level routing, i.e., the forwarding table of the LSR is kept intact even if the topology composed of a set of non-PSC FA-LSPs are modified. There is not topology change from the view point of MPLS-level. Traffic engi- neering is performed by reconfiguring the virtual topology consisting of a set of non-PSC FAs across the GMPLS-based transit region. Thanks to statistical multiplexing gain, there is no waste of bandwidth resource even if a PSC FA-LSP is created. 5.1.4. Virtual FA The virtual FA can be used instead of the FA to allow the path across the GMPLS-based transit region to be computed while avoiding waste of bandwidth and adaptation port occupation by non-PSC FA. A set of the virtual FAs forms the virtual topology for the best-effort and/or the traffic-engineered route across the GMPLS-based transit region. The virtual topology may be designed taking into account the (forecast) traffic demand and available resource in the GMPLS-based transit region. How to design the virtual topology is out of scope of [Page 17] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 this document. The virtual topology may dynamically change according to the change of the (forecast) traffic demand and the available resource in the transit region. The virtual topology is changed by setting up and/or tearing down the virtual FA. 5.2. LSP converting/LSP stitching 5.2.1. One-to-one relationship LSP converting and LSP stitching have common property when they are applied to the reference model for MPLS-GMPLS-MPLS. There is a one-to- one relationship between the e2e LSP and the transit segment. When the e2e LSP is set up and/or torn down, the associated transit segment is set up and/or torn down accordingly. Due to the one-to-one relationship, these mechanisms are relevant only for MPLS - GMPLS (PSC) -MPLS scenario. 5.2.2. Traffic demand change When the traffic demand for the e2e LSP changes, the bandwidth allocated to the transit segment may be modified. When the bandwidth is modified in the SENDER_TSPEC/FLOWSPEC object, the LSP-ID field of SENDER_TEMPLATE object for the e2e LSP is modified in both methods (make-before-break, see [RFC3209]). This modification may trigger the same LSP ID change for the transit segment if its bandwidth needs to be readjusted. 6. Acknowledgements The authors are grateful to Adrian Farrel for his numerous valuable com- ments. [Page 18] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 7. Security Considerations There are not security issues in this draft. 8. References 8.1. Normative references [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003. [RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Exten- sions", RFC 3473, January 2003. [GMPLS-ARCH] E. Mannie (Editor), "Generalized Multi-Protocol Label Switching Architecture," (Work in progress), May 2003. [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of Generalized MPLS", (work in progress), October 2003. [GMPLS-ISIS] "IS-IS extensions in support of generalized multi-protocol label switching," (work in progress), October 2003. [GMPLS-LMP] J. Land, "Link management protocol (LMP)," (work in progress), October 2003. [PWE3] S. Bryant, P. Pate (Editors), "PWE3 Architecture," (work in progress), March 2003. [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998. [Page 19] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 8.2. Informative references [MRN] D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard. J.L. Le Roux, "Generalized MPLS Architecture for Multi-Region Networks," (work in progress), February 2004. [GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Sup- port of Generalized Multi-Protocol Label Switching," (work in progress), October 2003. [Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework for inter-domain MPLS traffic engineering," (work in progress), April 2004. [HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS TE," (work in progress), Septem- ber 2002. [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC3477, January, 2003. [MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks," (work in progress), June 2002. [P&R] J.P. Lang, Y. Rekhter, D. Papadimitriou (Editors), "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", (work in progress), May 2004. [GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay Model," (work in progress), April 2004. [GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized Multi- Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)," (work in Progress), April 2004. [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions for discovery of TE router information", (work in progress), July 2004. [INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS traffic engineering RSVP extensions", (work in progress), July 2004. [MPLS-FRR] Ping Pan et. at., "Fast reroute extensions to RSVP-TE for LSP tunnels," (work in progress), March 2004. [INTER-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements for Inter-Area MPLS Traffic Engineering", , June 2004. 9. Author's Address Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 E-mail: dbrungard@att.com Jean-Louis Le Roux France Telecom R&D av Pierre Marzin 22300 Lannion France E-mail: jeanlouis.leroux@francetelecom.com Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan E-mail: oki.eiji@lab.ntt.co.jp Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 E-mail: dimitri.papadimitriou@alcatel.be Daisaku Shimazaki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan [Page 21] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 E-mail: shimazaki.daisaku@lab.ntt.co.jp Kohei Shiomoto NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan E-mail: shiomoto.kohei@lab.ntt.co.jp 10. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intel- lectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this stan- dard. Please address the information to the IETF Executive Director. 10.1. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to oth- ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided [Page 22] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or ref- erences to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 FIT- NESS FOR A PARTICULAR PURPOSE. [Page 23]