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] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conventions used in this document . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . . . 3 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 3. Difference between MPLS and GMPLS protocols . . . . . . . . . . . 6 3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Control plane/data plane separation . . . . . . . . . . . . . 8 3.4. Bi-directional LSP . . . . . . . . . . . . . . . . . . . . . . 9 4. Required mechanism . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. LSP converting . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2.3. ERO/RRO processing . . . . . . . . . . . . . . . . . . . . 14 4.2.3. LSP stitching . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. Discovery of GMPLS signalling capability . . . . . . . . . . 15 5. MPLS-GMPLS-MPLS reference model . . . . . . . . . . . . . . . . . 16 5.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . . . 16 5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. LSP converting/LSP stitching . . . . . . . . . . . . . . . . . 18 5.2.1. LSP One-to-one relationship . . . . . . . . . . . . . . . . . 18 5.2.2. LSP Traffic demand change . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative references . . . . . . . . . . . . . . . . . . . . . 19 8.2. Informative references . . . . . . . . . . . . . . . . . . . . 20 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Intellectual Property Rights Notices . . . . . . . . . . . . . . 22 10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 22 [Page 1] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 [Page 2] ================================ TXT file end ================================ ================================ NORFF file begin============================= .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF .ds RF [Page %] .ds CF .ds LH E. Oki et al. .ds RH July 2004 .ds CH draft-oki-ccamp-gmpls-ip-interworking-03.txt .ad l .in 0 .nh .hy 0 .nf 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 .ce Migrating from IP/MPLS to GMPLS networks .ce draft-oki-ccamp-gmpls-ip-interworking-03.txt .ti 0 Status of this Memo .fi .in 3 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. .ti 0 Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. .SH Abstract .XS Abstract .XE 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. .SH Conventions used in this document .XS Conventions used in this document .XE 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. .NH 1 Introduction .XS \*(SN Introduction .XE Multi-protocol label switching (MPLS) is widely deployed with applications 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 infrastructure 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 consists of L2SC, TDM, LSC, and FSC devices, will be introduced. Generalized MPLS (GMPLS) is being standardized by extending MPLS to control 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 completely migrated to the GMPLS network. GMPLS protocols are, however, subtly extending MPLS protocols' capabilities. 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 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 suggestion, label restriction, graceful restart, graceful teardown, and forwarding adjacencies (see [GMPLS-ARCH]). Also several features are provided 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 Section 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. .NH 1 Migration scenarii .XS \*(SN Migration scenarii .XE 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 network. 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 network and end/start in a GMPLS PSC network, will be addressed in a future revision. .NH 2 MPLS-GMPLS(non-PSC)-MPLS .XS \*(SN MPLS-GMPLS(non-PSC)-MPLS .XE 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 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 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 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 "e2e" LSP hereafter. The switching capability of both end points of e2e LSP are the same (PSC). .KS ................. .............................. .................. : 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. .KE .NH 2 MPLS-GMPLS(PSC)-MPLS .XS \*(SN MPLS-GMPLS(PSC)-MPLS .XE MPLS-based converged network can be migrated to GMPLS (PSC)-based converged 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. Existing 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. .NH 2 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) .XS \*(SN GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) .XE In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS network, which is partly disconnected. In case the MPLS-based infrastructure 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 hereafter. The switching capability of both end points of e2e LSP must be the same. .KS .................. ............................. .................. : 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. .KE .NH 2 GMPLS(PSC)-MPLS-GMPLS(PSC) .XS \*(SN GMPLS(PSC)-MPLS-GMPLS(PSC) .XE In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS network, which is partly disconnected. In case the MPLS-based infrastructure 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. .NH 1 Difference between MPLS and GMPLS protocols .XS \*(SN Difference between MPLS and GMPLS protocols .XE .NH 2 Routing .XS \*(SN Routing .XE 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. 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 mixture of MPLS-based and GMPLS-based TE link information. .KS ................. .............................. .................. : 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 .KE 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 control plane of GMPLS network. .NH 2 Signaling .XS \*(SN Signaling .XE GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and their associated procedures, that can not be processed/inserted by MPLS LSRs: .IP - 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. .IP - 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. .IP - The Suggested Label Object, used to reduce LSP setup delays. .IP - The Label Set Object, used to restrict label allocation to a set of label, which (particularly useful for wavelength conversion incapable nodes) .IP - The Upstream Label Object, used for bidirectional LSP setup (see also 3.4) .IP - The Restart Cap object, used for graceful restart. .IP - The Admin Status object, used for LSP administration, and particularly for graceful LSP teardown. .NH 2 Control plane/data plane separation .XS \*(SN Control plane/data plane separation .XE 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. 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]). .NH 2 Bi-directional LSP .XS \*(SN Bi-directional LSP .XE 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. .NH 1 Required mechanism .XS \*(SN Required mechanism .XE 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. .NH 2 Routing .XS \*(SN Routing .XE 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. .NH 3 Single-area .XS \*(SN Single-area .XE 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 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 topology (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. .NH 4 Virtual FA .XS \*(SN Virtual FA .XE 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 (forecast) traffic demand and the available resource in the transit region to optimize the tradeoff between network performance and the residual network 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 virtual FA-LSP. Signaling messages are used to exchange the link identifiers 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. .NH 3 Multi-area .XS \*(SN Multi-area .XE 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]). .NH 2 Signaling .XS \*(SN Signaling .XE We describe the signaling mechanisms, which can be applied to the migration 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 service 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. .KS ................. .............................. .................. : 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. .KE .NH 3 LSP nesting .XS \*(SN LSP nesting .XE Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS reference 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. Multiple 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 during 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. .NH 3 LSP converting .XS \*(SN LSP converting .XE 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-segments. 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. .NH 4 MPLS->GMPLS .XS \*(SN MPLS->GMPLS .XE 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 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. .NH 4 GMPLS->MPLS .XS \*(SN GMPLS->MPLS .XE 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. .NH 4 ERO/RRO processing .XS \*(SN ERO/RRO processing .XE 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. .IP 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. .IP 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 subobjects within the ERO as specified in [RFC 3209] to reach the egress border node. .IP 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. .LP 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. .NH 3 LSP stitching .XS \*(SN LSP stitching .XE 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-segments. 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. .NH 3 Discovery of GMPLS signalling capability .XS \*(SN Discovery of GMPLS signalling capability .XE 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. .NH 1 MPLS-GMPLS-MPLS reference model .XS \*(SN MPLS-GMPLS-MPLS reference model .XE In this section, the required mechanisms with the MPLS-GMPLS-MPLS reference 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. .NH 2 LSP nesting .XS \*(SN LSP nesting .XE .NH 3 Basic description .XS \*(SN Basic description .XE FAs are created between the GMPLS border nodes. The FAs are advertised in the MPLS regions, by the routing protocol, using MPLS TE-link information ([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. .NH 3 Traffic demand change .XS \*(SN Traffic demand change .XE 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 residual 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. 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 routing 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. .NH 3 Nest of FAs .XS \*(SN Nest of FAs .XE 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 engineering 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. .NH 3 Virtual FA .XS \*(SN Virtual FA .XE 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 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. .NH 2 LSP converting/LSP stitching .XS \*(SN LSP converting/LSP stitching .XE .NH 3 One-to-one relationship .XS \*(SN LSP One-to-one relationship .XE 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. .NH 3 Traffic demand change .XS \*(SN LSP Traffic demand change .XE 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. .NH Acknowledgements .XS \*(SN Acknowledgements .XE The authors are grateful to Adrian Farrel for his numerous valuable comments. .NH Security Considerations .XS \*(SN Security Considerations .XE There are not security issues in this draft. .NH 1 References .XS \*(SN References .XE .NH 2 Normative references .XS \*(SN Normative references .XE [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003. [RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Extensions", 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. .NH 2 Informative references .XS \*(SN Informative references .XE [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 Support 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), September 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. .NH Author's Address .XS \*(SN Author's Address .XE .nf 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 .nf 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 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 .NH Intellectual Property Rights Notices .XS \*(SN Intellectual Property Rights Notices .XE The IETF takes no position regarding the validity or scope of any intellectual 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 standard. Please address the information to the IETF Executive Director. .NH 2 IPR Disclosure Acknowledgement .XS \*(SN IPR Disclosure Acknowledgement .XE 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. .SH Full Copyright Statement .XS Full Copyright Statement .XE Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided 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 references 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 FITNESS FOR A PARTICULAR PURPOSE. .TC ================================ NORFF file end ============================= Dinara Suleymanova wrote: > Resubmit this draft to my e-mail address ASAP in a just plain TXT file > attachment. > > > At 07:36 PM 7/18/2004, you wrote: > >> Dear IETF Secretariat, >> CC: Kireeti and Adrian, >> >> I would like to submit a 03-version draft in the following. >> Attached please find draft files (txt and nroff). >> This draft is targeted as CCAMP WG. >> Thank you. >> --- >> Kohei Shiomoto >> --------------------------------------------------------------------------- >> >> Title: Migrating from IP/MPLS to GMPLS networks >> >> Authors: Deborah Brungard, Jean-Louis Le Roux, Eiji Oki, >> Dimitri Papadimitriou, Daisaku Shimazaki, Kohei Shiomoto >> 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. >> >> -- >> Kohei Shiomoto, Ph.D >> NTT Network Service Systems Laboratories >> 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan >> Phone +81 422 59 4402 Fax +81 422 59 4549 >> >> 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," > vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt> (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," > te-01.txt> (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", > ccamp-gmpls-recovery-e2e-signaling-01.txt> (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", >> > draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 te-00.txt> >> (work in progress), July 2004. [MPLS-FRR] Ping Pan et. at., "Fast >> reroute extensions to RSVP-TE for LSP tunnels," >> > 2004. [GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, >> Adrian Farrel, "GMPLS Based Segment >> Recovery," (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] E. Oki et al. >> draft-oki-ccamp-gmpls-ip-interworking-03.txt July >> 2004 Table of Contents Abstract . . . . . >> . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conventions >> used in this document . . . . . . . . . . . . . . . . . 2 1. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . . >> . 3 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 3. Difference between MPLS and GMPLS protocols >> . . . . . . . . . . . 6 3.1. Routing . . . . . . . . . . . . . . . >> . . . . . . . . . . . . . 6 3.2. Signaling . . . . . . . . . . . . >> . . . . . . . . . . . . . . . 7 3.3. Control plane/data plane >> separation . . . . . . . . . . . . . 8 3.4. Bi-directional LSP . >> . . . . . . . . . . . . . . . . . . . . . 9 4. Required mechanism >> . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Routing . . . >> . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. >> Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9 >> 4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . >> 10 4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . . >> . 11 4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . >> . . . 11 4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . . >> . . . . . 13 4.2.2. LSP converting . . . . . . . . . . . . . . . . >> . . . . . . . 13 4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . . >> . . . . . . . . . 13 4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . . >> . . . . . . . . . . . 14 4.2.2.3. ERO/RRO processing . . . . . . . >> . . . . . . . . . . . . . 14 4.2.3. LSP stitching . . . . . . . . . >> . . . . . . . . . . . . . . . 15 4.2.4. Discovery of GMPLS >> signalling capability . . . . . . . . . . 15 5. MPLS-GMPLS-MPLS >> reference model . . . . . . . . . . . . . . . . . 16 5.1. LSP >> nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16 >> 5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . . >> 16 5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . . >> . 16 5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . >> . . . 17 5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . . >> . . . . . 17 5.2. LSP converting/LSP stitching . . . . . . . . . . >> . . . . . . . 18 5.2.1. LSP One-to-one relationship . . . . . . . . >> . . . . . . . . . 18 5.2.2. LSP Traffic demand change . . . . . . . >> . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . >> . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . >> . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . >> . . . . . . . . . . . . . . . . . 19 8.1. Normative references . . >> . . . . . . . . . . . . . . . . . . . 19 8.2. Informative >> references . . . . . . . . . . . . . . . . . . . . 20 9. Author's >> Address . . . . . . . . . . . . . . . . . . . . . . . . 21 10. >> Intellectual Property Rights Notices . . . . . . . . . . . . . . 22 >> 10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . >> 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . >> . 22 [Page 1] E. Oki et al. >> draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 [Page 2] >> .pl 10.0i >> .po 0 >> .ll 7.2i >> .lt 7.2i >> .nr LL 7.2i >> .nr LT 7.2i >> .ds LF >> .ds RF [Page %] >> .ds CF >> .ds LH E. Oki et al. >> .ds RH July 2004 >> .ds CH draft-oki-ccamp-gmpls-ip-interworking-03.txt >> .ad l >> .in 0 >> .nh >> .hy 0 >> >> .nf >> 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 >> >> .ce >> Migrating from IP/MPLS to GMPLS networks >> >> .ce >> draft-oki-ccamp-gmpls-ip-interworking-03.txt >> >> .ti 0 >> Status of this Memo >> >> .fi >> .in 3 >> 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. >> >> .ti 0 >> Copyright Notice >> >> Copyright (C) The Internet Society (2004). All Rights Reserved. >> >> .SH >> Abstract >> .XS >> Abstract >> .XE >> >> 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. >> >> .SH >> Conventions used in this document >> .XS >> Conventions used in this document >> .XE >> >> >> 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. >> >> >> >> .NH 1 >> Introduction >> .XS >> \*(SN Introduction >> .XE >> >> >> Multi-protocol label switching (MPLS) is widely deployed with >> applications 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 >> infrastructure 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 consists of L2SC, TDM, LSC, >> and FSC devices, will be >> introduced. >> >> Generalized MPLS (GMPLS) is being standardized by extending MPLS to >> control 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 >> completely migrated to the >> GMPLS network. >> >> GMPLS protocols are, however, subtly extending MPLS protocols' >> capabilities. 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 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 >> suggestion, label restriction, graceful restart, graceful teardown, >> and forwarding adjacencies (see [GMPLS-ARCH]). >> Also several features are provided 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 Section 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. >> >> .NH 1 >> Migration scenarii >> .XS >> \*(SN Migration scenarii >> .XE >> >> 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 network. 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 >> network and end/start in a GMPLS PSC network, will be addressed in a >> future revision. >> >> >> .NH 2 >> MPLS-GMPLS(non-PSC)-MPLS >> .XS >> \*(SN MPLS-GMPLS(non-PSC)-MPLS >> .XE >> >> >> >> 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 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 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 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 "e2e" LSP hereafter. >> The switching capability of both end points of e2e LSP are the same >> (PSC). >> >> .KS >> ................. .............................. .................. >> : 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. >> .KE >> >> >> >> .NH 2 >> MPLS-GMPLS(PSC)-MPLS >> .XS >> \*(SN MPLS-GMPLS(PSC)-MPLS >> .XE >> >> MPLS-based converged network can be migrated to GMPLS (PSC)-based >> converged >> 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. >> Existing >> 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. >> >> >> >> >> .NH 2 >> GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) >> .XS >> \*(SN GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) >> .XE >> >> In this scenario, TDM, L2SC e2e LSPs are provisioned in the GMPLS >> network, which is partly disconnected. >> In case the MPLS-based infrastructure 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 hereafter. >> The switching capability of both end points of e2e LSP must be the same. >> >> .KS >> >> .................. ............................. .................. >> : 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. >> .KE >> >> >> >> .NH 2 >> GMPLS(PSC)-MPLS-GMPLS(PSC) >> .XS >> \*(SN GMPLS(PSC)-MPLS-GMPLS(PSC) >> .XE >> >> In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS >> network, which is partly disconnected. >> In case the MPLS-based infrastructure 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. >> >> >> >> .NH 1 >> Difference between MPLS and GMPLS protocols >> .XS >> \*(SN Difference between MPLS and GMPLS protocols >> .XE >> >> >> .NH 2 >> Routing >> .XS >> \*(SN Routing >> .XE >> >> 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. >> >> 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 mixture of MPLS-based and GMPLS-based TE link >> information. >> >> .KS >> ................. .............................. .................. >> : 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 >> .KE >> >> 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 control plane of GMPLS >> network. >> >> >> >> .NH 2 >> Signaling >> .XS >> \*(SN Signaling >> .XE >> >> >> GMPLS RSVP-TE signalling ([RFC 3473]) introduces new objects, and >> their associated procedures, that can not be processed/inserted by >> MPLS LSRs: >> .IP - >> 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. >> .IP - >> 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. >> .IP - >> The Suggested Label Object, used to reduce LSP setup delays. >> .IP - >> The Label Set Object, used to restrict label allocation to a set of >> label, which (particularly useful for wavelength conversion incapable >> nodes) >> .IP - >> The Upstream Label Object, used for bidirectional LSP setup (see also >> 3.4) >> .IP - >> The Restart Cap object, used for graceful restart. >> .IP - >> The Admin Status object, used for LSP administration, and >> particularly for graceful LSP teardown. >> >> >> .NH 2 >> Control plane/data plane separation >> .XS >> \*(SN Control plane/data plane separation >> .XE >> >> >> 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. >> 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]). >> >> >> .NH 2 >> Bi-directional LSP >> .XS >> \*(SN Bi-directional LSP >> .XE >> >> >> 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. >> >> >> >> >> >> .NH 1 >> Required mechanism >> .XS >> \*(SN Required mechanism >> .XE >> >> >> 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. >> >> .NH 2 >> Routing >> .XS >> \*(SN Routing >> .XE >> >> >> 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. >> >> .NH 3 >> Single-area >> .XS >> \*(SN Single-area >> .XE >> >> >> 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 >> 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 >> topology (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. >> >> .NH 4 >> Virtual FA >> .XS >> \*(SN Virtual FA >> .XE >> >> 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 >> (forecast) traffic demand and the available resource in the transit >> region to >> optimize the tradeoff between network performance and the residual >> network 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 >> virtual FA-LSP. >> Signaling messages are used to exchange the link identifiers 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. >> >> >> >> .NH 3 >> Multi-area >> .XS >> \*(SN Multi-area >> .XE >> >> 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]). >> >> >> >> .NH 2 >> Signaling >> .XS >> \*(SN Signaling >> .XE >> >> We describe the signaling mechanisms, which can be applied to the >> migration 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 service 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. >> >> >> .KS >> ................. .............................. .................. >> : 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. >> .KE >> >> >> .NH 3 >> LSP nesting >> .XS >> \*(SN LSP nesting >> .XE >> >> Figure 4 (a) illustrates the LSP nesting in the MPLS-GMPLS-MPLS >> reference 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. Multiple 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 during 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. >> >> >> >> .NH 3 >> LSP converting >> .XS >> \*(SN LSP converting >> .XE >> >> 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-segments. >> 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. >> >> .NH 4 >> MPLS->GMPLS >> .XS >> \*(SN MPLS->GMPLS >> .XE >> >> 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 >> 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. >> >> >> >> .NH 4 >> GMPLS->MPLS >> .XS >> \*(SN GMPLS->MPLS >> .XE >> >> 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. >> >> >> >> .NH 4 >> ERO/RRO processing >> .XS >> \*(SN ERO/RRO processing >> .XE >> >> 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. >> >> .IP 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. >> .IP 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 >> subobjects within the ERO as specified in [RFC 3209] to reach the >> egress border node. >> .IP 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. >> >> .LP >> 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. >> >> >> >> .NH 3 >> LSP stitching >> .XS >> \*(SN LSP stitching >> .XE >> >> 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-segments. >> 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. >> >> .NH 3 >> Discovery of GMPLS signalling capability >> .XS >> \*(SN Discovery of GMPLS signalling capability >> .XE >> >> 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. >> >> >> >> >> >> >> >> >> >> >> >> >> >> .NH 1 >> MPLS-GMPLS-MPLS reference model >> .XS >> \*(SN MPLS-GMPLS-MPLS reference model >> .XE >> >> In this section, the required mechanisms with the MPLS-GMPLS-MPLS >> reference 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. >> >> >> .NH 2 >> LSP nesting >> .XS >> \*(SN LSP nesting >> .XE >> >> .NH 3 >> Basic description >> .XS >> \*(SN Basic description >> .XE >> >> FAs are created between the GMPLS border nodes. >> The FAs are advertised in the MPLS regions, by the routing protocol, >> using MPLS TE-link information ([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. >> >> >> .NH 3 >> Traffic demand change >> .XS >> \*(SN Traffic demand change >> .XE >> >> 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 residual 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. 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 >> routing 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. >> >> .NH 3 >> Nest of FAs >> .XS >> \*(SN Nest of FAs >> .XE >> >> 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 >> engineering 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. >> >> >> >> >> .NH 3 >> Virtual FA >> .XS >> \*(SN Virtual FA >> .XE >> >> >> 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 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. >> >> >> >> >> .NH 2 >> LSP converting/LSP stitching >> .XS >> \*(SN LSP converting/LSP stitching >> .XE >> >> >> .NH 3 >> One-to-one relationship >> .XS >> \*(SN LSP One-to-one relationship >> .XE >> >> 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. >> >> .NH 3 >> Traffic demand change >> .XS >> \*(SN LSP Traffic demand change >> .XE >> >> 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. >> >> >> >> >> >> .NH >> Acknowledgements >> .XS >> \*(SN Acknowledgements >> .XE >> >> The authors are grateful to Adrian Farrel for his numerous valuable >> comments. >> >> >> .NH >> Security Considerations >> .XS >> \*(SN Security Considerations >> .XE >> >> There are not security issues in this draft. >> >> >> >> .NH 1 >> References >> .XS >> \*(SN References >> .XE >> >> >> >> .NH 2 >> Normative references >> .XS >> \*(SN Normative references >> .XE >> >> [RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional >> Description", RFC 3471, January 2003. >> >> [RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE >> Extensions", >> 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. >> >> >> .NH 2 >> Informative references >> .XS >> \*(SN Informative references >> .XE >> >> [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 >> Support >> 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), >> September 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," > progress), May 2004. >> >> [GMPLS-SR] Louis Berger, Igor Bryskin, Dimitri Papadimitriou, Adrian >> Farrel, >> "GMPLS Based Segment >> Recovery," (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. >> >> .NH >> Author's Address >> .XS >> \*(SN Author's Address >> .XE >> >> .nf >> 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 >> >> .nf >> 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 >> 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 >> >> >> >> >> .NH >> Intellectual Property Rights Notices >> .XS >> \*(SN Intellectual Property Rights Notices >> .XE >> >> The IETF takes no position regarding the validity or scope of any >> intellectual 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 standard. Please address the >> information to the >> IETF Executive Director. >> >> .NH 2 >> IPR Disclosure Acknowledgement >> .XS >> \*(SN IPR Disclosure Acknowledgement >> .XE >> >> 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. >> >> .SH >> Full Copyright Statement >> .XS >> Full Copyright Statement >> .XE >> >> Copyright (C) The Internet Society (2003). All Rights Reserved. >> >> This document and translations of it may be copied and furnished to >> others, and >> derivative works that comment on or otherwise explain it or assist in >> its >> implementation may be prepared, copied, published and distributed, in >> whole or in >> part, without restriction of any kind, provided 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 references 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 FITNESS FOR A PARTICULAR >> PURPOSE. >> >> >> >> >> >> .TC > 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] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conventions used in this document . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Migration scenarii . . . . . . . . . . . . . . . . . . . . . . . 3 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 3. Difference between MPLS and GMPLS protocols . . . . . . . . . . . 6 3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Control plane/data plane separation . . . . . . . . . . . . . 8 3.4. Bi-directional LSP . . . . . . . . . . . . . . . . . . . . . . 9 4. Required mechanism . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Single-area . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.1. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Multi-area . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. LSP converting . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2.1. MPLS->GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2.2. GMPLS->MPLS . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2.3. ERO/RRO processing . . . . . . . . . . . . . . . . . . . . 14 4.2.3. LSP stitching . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. Discovery of GMPLS signalling capability . . . . . . . . . . 15 5. MPLS-GMPLS-MPLS reference model . . . . . . . . . . . . . . . . . 16 5.1. LSP nesting . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Basic description . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Traffic demand change . . . . . . . . . . . . . . . . . . . . 16 5.1.3. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Virtual FA . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. LSP converting/LSP stitching . . . . . . . . . . . . . . . . . 18 5.2.1. LSP One-to-one relationship . . . . . . . . . . . . . . . . . 18 5.2.2. LSP Traffic demand change . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative references . . . . . . . . . . . . . . . . . . . . . 19 8.2. Informative references . . . . . . . . . . . . . . . . . . . . 20 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Intellectual Property Rights Notices . . . . . . . . . . . . . . 22 10.1. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 22 [Page 1] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-03.txt July 2004 [Page 2]