CCAMP Working Group D. Papadimitriou (Alcatel) Internet Draft M. Vigoureux (Alcatel) Expiration Date: Janurary 2004 K. Shiomoto (NTT) D. Brungard (AT&T) J.L. Le Roux (FT) July 2004 Generalized MPLS architecture for multi-region networks draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments of single switching capability devices e.g. one data plane layer, as such, the complexity raised by the control of such data planes is similar to the one expected in classical IP/MPLS net- works. The fundamental reason being that an IP-based control plane pro- tocol suite for Label Switch Routers (LSR) or Optical Cross-Connects (OXC) has exactly the same Level (i.e. single data plane layer) [Page 1] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 complexity. The present document analyses the various GMPLS signaling and routing aspects when considering network environments consisting of multiple switching data layers e.g. supporting combined Packet/Layer-2 Switching - OXC devices. The examples provide an overview of the trade- offs in using a GMPLS control plane for combined Ethernet MAC - opaque, service transparent, and/or fully transparent data planes. The intent of this memo is also to demonstrate that these aspects may not be as straightforward as they may first appear. 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 GMPLS extends MPLS to various switching technologies including PSC, TDM, LSC, and FSC. GMPLS enables us to provide mechanisms for rapid service provisioning and efficient network resource usage for the carrierfs net- work, which consists of network elements based on those multiple switch- ing technologies. Network elements of different switching technologies are administered by different administrative divisions. Provisioning the paths across multi- ple administrative divisions, therefore, requires coordination and/or negotiation for administrative resources, which could result in long delay for service provisioning.Since network resource is independently administered in different administrative divisions, the entire network resource may not be efficiently used. Since GMPLS provides a comprehensive framework for the control mechanism different switching technologies, the carrierfs network can be con- trolled in a unified framework and therefore the rapid service provi- sioning and the efficient network usage are attained. The network consisting of network elements based on different switching technologies controlled by GMPLS is referred to as gmulti-regionh net- work in this document. So far the horizontal aspect of GMPLS has been discussed in the CCAMP [Page 2] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 WG, where each network element drives a single multiple switching tech- nology. The horizontal aspect is defined between nodes hosting the same switching capability (For instance, the control plane interconnection between lambda switching capable routing areas defines a horizontal integration). In order to construct the framework to facilitate the efficient network resource usage and rapid service provisioning in car- rierfs network based on multiple switching technologies, we argue that the vertical aspect of GMPLS should be highlighted, where collaborative mechanisms within a network element driving multiple switching technolo- gies. In this document, we address the GMPLS-based multi-region network, and the multi-layer service scenarios based on the multi-region network con- cept, where different switching capability (layer) connections treated in a seamless way so that efficient resource usage and traffic engineer- ing can be realized over such different layer regions. 2. Multi-region network GMPLS-based network, which consists of network elements based on multi- ple switching technologies, are referred to as Multi LSP-Region Networks or simply Multi-Region Networks (MRN). In the MRN, at least two differ- ent switching capabilities are present and where these capabilities are both hosted by the same device and/or hosted by different devices involves a vertical integration within the GMPLS control plane. Switching capability concept is introduced in GMPLS protocol to support various kinds of switching technologies in a unified way. Four classes of switching capability are defined: PSC (packet switch capable), TDM (TDM capable), LSC (lambda switch capable), and FSC (fiber switch capa- ble). The domain, in which the same switching technology is used, is referred to as "region" [HIER]. The region is a hierarchical concept: PSC, TDM, LSC, and FSC regions are defined from the upper to the lower regions (See Fig. 1). When the LSP is crossing the boundary of region from the upper to the lower regions, the LSP can be nested in the lower-region FA or be converted to the lower-region LSPs. [Page 3] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 ..................................................................... : ..................................................... : : : .................................... : : : : : ................... : : : : PSC : TDM : LSC : FSC : : : : : +--+ : +--+ : +--+ : +--+ +--+ :@+--+ : +--+ : +--+ : : |P1|_____|T1|_____|L1|_____|F1|____|F3| ____|L3|_____|T3|____|P3| : : +--+ : +--+ : +--+ : +--+ +--+ : +--+ : +--+ : +--+ : : | : | : | : | | : | : | : | : : | : | : | : | | : | : | : | : : +--+ : +--+ : +--+ : +--+ +--+ : +--+ : +--+ : +--+ : : |P2|_____|T2|_____|L2|_____|F2|____|F4| ____|L4|_____|T4|____|P4| : : +--+ : +--+ : +--+ : +--+ +--+ : +--+ : +--+: +--+ : : : : ................... : : ; : : .................................... : : : ................................................... : ..................................................................... Fig.1 Multi-region network. The network resources are efficiently utilized by administrating in the entire network resource in GMPLS-based multi-region network (MRN). The GMPLS-based MRN provides a rapid service provisioning mechanism by provisioning the LSP in various region to customer PSC, TDM, LSC, and FSC LSP can be rapidly provisioned. In the multi-region network, two types of network elements are defined: plain node and hybrid node. The plain node has only single switching capability links on its side of endpoint. On the other hand, the hybrid node has both single switching capability links and multiple switching capability links on its side of endpoint. 2.1. Plain node model The MRN network can consist of only plain nodes. PSC, TDM, LSC, and FSC plain nodes are deployed in the MRN network (See Fig. 2). We should note that the node, which has links of various switching capabilities, is a plain node as long as the end point of the link is associated with a single switching capability. For example the node TL2 in Fig.2 is a plain node, which has the two links associated with TDM and the two links associated with LSC. At the region boundary, the interface switching capabilities of both ends of link are different. When the LSP [Page 4] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 is crossing the boundary of region from the upper to the lower regions, the LSP can be nested in the lower-region FA or be converted to the lower-region LSPs. ..................................................................... : ..................................................... : : : .................................... : : : : : ................... : : : : PSC : TDM : LSC : FSC : : : : : +--+ : +--+ : +--+ : +--+ +--+ :@+--+ : +--+ : +--+ : : |P1|_____|T1|_____|L1|_____|F1|____|F3| ____|L3|_____|T3|____|P3| : : +--+ : +--+ : +--+ : +--+ +--+ : +--+ : +--+ : +--+ : : | : | : | : | | : | : | : | : : | : | : | : | | : | : | : | : : +--+ : +-----------+ : +--+ +--+ : +--+ : +--+ : +--+ : : |P2|_____| TL2 |_____|F2|____|F4| ____|L4|_____|T4|____|P4| : : +--+ : +-----------+ : +--+ +--+ : +--+ : +--+: +--+ : : : : ................... : : ; : : .................................... : : : ................................................... : ..................................................................... Fig. 2 Plain node MRN model. 2.2. Hybird node model The plain and hybrid nodes may co-exist in the MRN. Figure 3 shows an example of hybrid node. The hybrid node has two switching elements, which have capabilities of ISC1 and ISC2. It has two external inter- faces (Link1 and 2), which are directly connected to the switching ele- ment of ISC1. The two switching elements are interconnected via an internal link, which is not disclosed outside the network element. The internal interface is used to facilitate gadaptationh between different switching capabilities: ISC1 and ISC2. By cross-connecting the port#a and the port#b in the ISC1 switching element, the Link 1 is capable of ISC2 not ISC1. [Page 5] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 Network element ............................. : -------- : : | ISC2 | : : +--<->---| | : : | -------- : ISC1 : | ---------- : +ISC2 : +--<->--|#a ISC1 | : Link1 ------------<->--|#b | : Link2 ------------<->--|#c | : : ---------- : :............................ Fig.3 Hybrid node. 3. Mechanism The MRN is implemented by a set of following mechanisms: triggered sig- naling and forwarding adjacency. 3.1. Forwarding adjacency (FA) Once the FA-LSP is created, it can be advertised as a TE-link called forwarding adjacency (FA), allowing other nodes to use FAs as TE links for their path computation [HIER]. FA is a useful and powerful tool for improving the scalability of Generalized MPLS (GMPLS) Traffic Engineer- ing (TE) capable networks. Through the aggregation of TE Label Switched Paths (LSPs) this concept enables the creation of a vertical (nested) TE-LSP Hierarchy. A set of the lower region FAs is used for the upper region path computation. In the MRN, FAs in the various regions are included in the traffic engi- neering database (TEDB). FAfs region is identified by the interface switching capability attached to the LSA associated with the FA [OSPF- ROUTING]. [Page 6] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 3.1.1. Interface switching capability Interface switching capability concept is introduced in GMPLS protocol to support various kinds of switching technologies in a unified way. PSC (packet switch capable), TDM(TDM capable), LSC (lambda switch capa- ble), and FSC (fiber switch capable) are defined. Each end of the link in GMPLS network is associated with at least one switching capability. For example, PSC is associated with interface which can delineate IP/MPLS packets (e.g., node's interface) while LSC is associated with the interface which can switch individual wavelengths multiplexed in a fiber link (e.g., OXC's interface). Every link in the link state database has switching capabilities on both ends. Note that an interface may have multiple interface switching capabili- ties. Plain node has only interfaces with single switching capability while hybrid node has mixture of interfaces with single and multiple switching capabilities. 3.1.1.1. Case I: Single interface switching capability Recall the plain node model shown in Fig.2. Plain node has only inter- faces with single switching capability. Switching capability of both ends of TE-link may or may not be the same. If the TE-link between the LSR and the TDM switch, the switching capability of the end-point on the LSR-side is PSC while the one on the TDM switch-side is TDM. If the TE- link between the TDM switches, the switching capability of the both end- points are TDM. 3.1.1.2. Case II: Multiple inteface switching capability Recall the hybrid node shown in Fig. 3 has interfaces with multiple switching capabilities: ISC1 and ISC2. Those two link is advertise as a TE-link with multiple interface switching capability: ISC1 and ISC2. Once the cross-connection between the port#a and the port#b in the ISC1 switching element are made, the Link 1 is capable of ISC2 not ISC1. The Link1 is advertised as a new FA with a single switching capability: ISC2. There is no available internal links to connect the port #b to the ISC-2 after that. The Link 2 is still advertised as being capable of ISC1 and ISC2 but there is no available resources to provide ISC2. [Page 7] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 3.1.2. Routing rule: compatibility In computing the path in the MRN, we define a concept "compatibility" between interface switching capabilities. If two TE-links are compati- ble, those two links can be connected in the computed path. Two classes of compatibility are defined as to whether the lower-region FA-LSP needs to be created or not in the computed path. 3.1.2.1. Class 1: Compatible w/o need to set up new FAs Path computation may take into account region boundaries when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose interface switching capability is PSC-1. Interface switching capability is used to compute the path. TDM-LSP is routed over the topology composed of link state, either of whose ends is TDM. In Fig. 4 a TDM-LSP is routed from LSR-P1, TDM_SW-T1, TDM_SW-T2, and LSR-P2. The path for the TDM-LSP is composed of links, either of whose ends is TDM. Once the optical LSP is set up, it is advertised as FA- LSP, both ends of which are PSC. In calculating the path for PSC-LSP, link-state database is filtered to include the link, both ends of which include only PSC. In this way hierarchical routing of PSC-LSP and TDM- LSP is done by using link-state database filtered with respect to switching capability. .................................. : .................. : : : : : : PSC : TDM : : : +--+ : +--+ +--+ : +--+ : : |P1|_____|T1|_____|T2|____|P2| : : +--+ : +--+ +--+ : +--+ : : : : : : .................. : .................................. Fig. 4 Path computation in MRN. [Page 8] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 3.1.2.2. Class 2: Compatible iff new FAs setup There may be a case, in which we can set up the LSP if we set new lower- region LSPs along the computed path. Suppose that we set up the TDM-LSP between P1 and P2 in Fig. 5, The TDM-LSP is routed over the path T1-L1-L2-T2. At this time, there is not direct link between T1 and T2. Then, the LSC-LSP is set up between the T1 and T2. The LSC-LSP setup request (between T1 and T2) is triggered by the TDM-LSP setup request (between P1 and P2). If the triggered signaling is allowed, the path computation mechanism may produce the route containing the multiple level of regions. .................................................. : .................................. : : : ................. : : : : : : : : : PSC : TDM : LSC : : : : +--+ : +--+ : +--+ @+--+ : +--+ : +--+ : : |P1|_____|T1|_____|L1|___|L2|_____|T2|____|P2| : : +--+ : +--+ : +--+ +--+ : +--+ : +--+ : : : ................. : : : .................................. : .................................................. Fig. 5 Path computation in MRN. 3.1.3. Adaptation capability In an MRN, as described here above, some node could contain, under the control of a single GMPLS instance, multiple interface switching capa- bilities (Recall Fig. 3). These nodes, hosting multiple Interface Switching Capabilities (ISC), are required to hold and advertise resource information on link states and topology. They also may have to consider certain portions of inter- nal adaptation resources to terminate hierarchical label switched paths (LSPs), since circuit switch capable units such as TDMs, LSCs, and FSCs require rigid resources. For example, a node with PSC+LSC switching capability can switch a LSC- LSP but can never terminate the LSC-LSP if there is no unused adaptation capability between the LSC and the PSC layers. [Page 9] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 Therefore, within multi-region networks, the advertisement the so-called adaptation capability to terminate LSPs provides critical information to take into account when performing multi-region path computation. This concept enables a local node to discriminate remote nodes (and thus allows their selection during path computation) with respect to their adaptation capability e.g. to terminate LSC-LSPs at the PSC level. Hence, here we introduce the idea of discriminating the (internal) adap- tation capability from the (interface) switching capability by consider- ing an interface adaptation capability descriptor. 3.2. Triggered signaling When the LSP is crossing the boundary of region from the upper to the lower regions, the LSP can be nested in the lower-region FA. If such FA does not exist, the FA-LSP is established. Such mechanism is referred to as "triggered signaling" here. In the triggered lower-region LSP setup, a higher-region LSP setup invokes the lower-region LSP setup when the lower-region LSP setup is needed. The triggered lower-region LSP setup are required because there is no lower-region LSP whose residual bandwidth is larger than the requested higher-region bandwidth, or because the network provider judges that establishing a new lower-region LSP is more cost effective than using an existing lower- region LSP even it is available. Two routing policies are considered here. When a new higher-region LSP is requested with specified bandwidth, both policies first try to allo- cate the new requested higher-region LSP to an lower-region FA that directly connects the source and destina- tion nodes. If such a lower- region FA does not exist, the two policies invoke different procedures. Policy 1 tries to find multiple hops of existing lower-region FAs from source to destination nodes while policy 2 tries to setup a new one hop lower-region FA-LSP between source and destination nodes. Those policies are incorporated within the multi-region routing algo- rithm described later in this document. Namely, once the routing is determined, the LSP setup request is transmitted along the route. The route for the requested LSP is calculated using the TEDB, which consists of multi-region LSAs. The route information is carried in the ERO. The ERO may contain the node-ids and the link-ids in various regions. The intermidiate node processes the LSP setup request signaling messages and invokes the triggered signaling procesure if neccessary. If the hybird node exists in the MRN, the ERO could be ambiguous. [Page 10] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 Namely, the node id and the link id is not sufficient to identify the region for the interface of the hybrid node, which has multiple switch- ing capability. How to sovle the ambiguity is for further research. 3.3. Virtual network topology A set of lower-region FAs provides the virtual network topology to the upper-region LSP network. For instance A set of FAs, each of which is instantiated by LSC-LSP, provides the virtual network topology to the PSC-LSPs. Virtual network topology is configured by setting up or tear- ing down the LSC-LSPs. By using GMPLS signalling and routing protocol, the virtual network topology can be altered easily. FA is either PSC or non-PSC. Statistical multiplexing can be employed in PSC network. PSC FA may or may not consume the fixed bandwidth. Statis- tical multiplexing cannot be employed in non-PSC network. Non-PSC FA consumes the fixed bandwidth as long as it exists. Non-PSC FA is used for the traffic engineering purpose in a similar way as a normal physical link between adjacent routers. FA is used for cal- culating the best-effort route and/or the traffic-engineered explicit route. FA is advertised as a TE-link by the routing protocol. There is no rout- ing adjacency along the FA. There is no hello packets exchanged between the end points of the FA. When FA is to be destroyed, the associated FA-LSP should be removed only after the LSA associated with the FA is deleted throughout the network in order to avoid and/or minize disruption. Once the LSA is deleted, the upper-region LSPs routed over the FA are expected to get rerouted around the FA. Routing is dependent on the network topology and associated link state. Routing stability may be impaired if the Virtual Network Topology fre- quently changes and/or if the status of links in the Virtual Network [Page 11] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 Topology frequently changes. In this context, robustness of the Virtual Network Topology is defined as the capability to smooth changes that may occur and avoid their subsequent propagation. Changes of the Virtual Network Topology may be caused by the creation and/or deletion of sev- eral LSPs. Creation and deletion of LSPs may be triggered by adjacent regions or through operational actions to meet change of traffic demand. Routing robustness should be traded with adaptability with respect to the change of incoming traffic requests. 4. Service application scenarios GMPLS-based MRN provide mechanisms for rapid service provisioning and efficient network resource usage for the carrierfs network, in which network elements based on various switching technologies coexist. In this section, we describe service application scenarios based on the multi-region network concept, where different switching capability (layer) connections treated in a seamless way so that efficient resource usage and traffic engineering can be realized over such different layer regions. Traffic engineering based on the virtual network topology reconfigura- tion, migration from MPLS to GMPLS [MPLSGMPLS] are explained as service application examples. 4.1. Traffic engineering based on the virtual network topology By changing the virtual network topology, we can implement traffic engi- neering. The virtual network topology is altered to adjust the traffic demand of the PSC layer. Traffic engineering in multi layer network should have features which handles different regions' traffic and resource information for maximum efficiency in the traffic engineering. By reconfiguring the virtual network topology according the traffic demand between source-destination [Page 12] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 node pairs, the network performance such as maximum link utilization and residual capacity of the network is optimized. Virtual network topology (VNT) algorithm is a key component in the traf- fic-engineering in GMPLS-based multi-region network. The VNT algorithm computes the new VNT from the current VNT and the traffic demand matrix under constraint of the multi-region traffic engineering database. The VNT algorithm, which is out of scope of this document, may be tailored according to the service provider's policy regarding the network perfor- mance and quality of service (delay, loss/disruption, utilization, residual capacity, reliability). 4.1.1. Traffic demand change The VNT may change to adapt the traffic demand change [MAMLTE]. Figure 6 shows how the VNT is reconfigured by creating and/or destorying FAs. By creating two FAs between P1 and P2, P2 and P3, the VNT 1 is created. When the traffic demand between P 1 and P 2 decreases and that between P1 and P3 increases, the FA between the P1 and P2 is destroyed and that between P1 and P3 is created. The VNT 1 is reconfigured to the VNT 2. [Page 13] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 -------------+ +--------------+ +---------- PSC | | TDM | | PSC +-----+ | | +-----+ | | +-----+ | | | | | | | | | | --+ P1 +----------+ T1 +----------+ P2 +-- | | | | | | | | | | +-----+ | | +--+--+ | | +-----+ | | | | | | | +--+--+ | | ------------+ | | | | +----------- | | T2 | | +---------- | +-----+ | | PSC | | | | | +--+--+ | | +-----+ | | | | | | | | | T3 +----------+ P3 +- | | | | | | | | +-----+ | | +-----+ +--------------+ +---------- (a) Physical topology +-------+ +-------+ +-------+ +-------+ |PSC | |PSC | |PSC | |PSC | | P1 +-----+ P2 | | P1 | | P2 | | | | | | | | | +-------+ +---+---+ +---+---+ +---+---+ | | | | | | +---+---+ | +---+---+ |PSC | | |PSC | | P3 | +---------+ P3 | | | | | +-------+ +-------+ (b) VNT 1 (c) VNT 2 Figure 6 VNT reconfiguration by creating/destorying FAs. [Page 14] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 4.2. Migration from MPLS to GMPLS GMPLS-based optical core network is introduced in the existing MPLS- based infrastructure network to increase the capacity. TDM, LSC, FSC LSPs are established between MPLS networks across the GMPLS network. A set of those LSPs provide virtual network topology for MPLS networks. The virtual network topology is reconfigured by connecting and/or dis- connecting those LSPs. MPLS networks at both ends and the virtual net- work topology may form a single MPLS network. Figure 7 shows the reference network model for the migration from GMPSL to MPLS. 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). LSP is provisioned from the node in the ingress MPLS-based region (say, R2) to the 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 |__________|G1 |__________|G3 |__________|G5 |__________|R3 |: :+---+ +---+ +-+-+ +---+ +---+: : ________/ : : ________/ | ________/ : : ________/ : :| / : : / | / : : / : :+---+ +---+ +-+-+ +---+ +---+: :|R2 |__________|G2 |__________|G4 |__________|G6 |__________|R4 |: :+---+ +---+ +---+ +---+ +---+: :................: :...........................: :................: |<-------------------------------------------------------->| e2e LSP Figure 7 Migration from MPLS to GMPLS. We consider the 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-based region is referred to as "tran- sit segment". [Page 15] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 FAs are created between the border nodes. The FAs are advertised by routing protocol. They are advertised as Opaque-LSA as TE-link [OSPF- TE] or router-LSA as normal link [OSPF]. When they are advertise as router-LSA, there must be routing adjacency between their end points [OSPF]. The e2e LSP is tunneled through the FA across the GMPLS-based transit region. Multiple e2e LSPs are tunneled 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 [MAMLTE]. 4.2.1. Traffic demand change Traffic demand may change after the FA is created. Some FAs, which do not carry any e2eLSP any longer, exist. They may be released for resource reclamation. They may be retained for future usage. Decision as to release or retention of unutilized FAs may depend on the policy, which might consider the residual resource in GMPLS-based transit region and the traffic demand between the ingress and the egress MPLS-based regions. 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. Detail of the policy is again out of scope of this document. FA-LSPs may be rerouted while keeping the associated FA intact, i.e., keeping inter- face identifiers of FAs unchanged. We should note that the routing in MPLS level is kept intact 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. [Page 16] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 4.2.2. Nest of FAs FAs can be nested. PSC FA can be tunneled into the non-PSC FA. The e2e LSP can be tunneled into the PSC FA (See Fig. 8). PSC FA is created between border nodes (G1 and G3). PSC FA is carried using non-PSC FA, which is not shown in Fig. 8. Thanks to statistical multiplexing, there is no waste of bandwidth resource even if PSC FA is created. Full-mesh PSC FAs may be created between every border nodes if reachability between every pair of MPLS-based regions using a set of non-PSC FAs, which are not shown in Fig. 8, between border nodes across the GMPLS- based transit region [MAMLTE]. The merit of this mechanism is to attain the stability of MPLS-level routing. 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. ------------+ +-----------------+ +----------- MPLS region | | GMPLS region | | MPLS region (Ingress) | | (transit) | | (Egress) | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | ---+ R1 +--+ G1 +---+ G2 +---+ G3 +--+ R2 +-- | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | -------------------------------------> | | e2e LSP | | | | --------------->| | | | PSC FA | | ------------+ +-----------------+ +----------- Figure 8 Nest of FA. Acknowledgements We would like to thank here, Sven Van Den Bosch, Richard Douville, Olivier Audouin, Amaury Jourdan, Emmanuel Desmet and Bernard sales. The authors would like to thank Mr. Wataru Imajuku for the discussions [Page 17] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 on adaptation between regions [MLRT]. Security Considerations There are not security issues in this draft. References 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-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-12.txt (work in progress). [GMPLS-LMP] J. Land, "Link management protocol (LMP)," draft-ietf-ccamp- lmp-10.txt (work in progress), October 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. Informative references [MPLSGMPLS] D. Brungard, J. L. Roux, E. Oki, D. Papadimitriou, D. Shi- mazaki, K. Shiomoto, "Migrating from IP/MPLS to GMPLS networks," draft- oki-ccamp-gmpls-ip-interworking-03.txt (work in progress) July 2004. [GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Sup- port of Generalized Multi-Protocol Label Switching," draft-ietf-ccamp- gmpls-routing-09.txt, Octorber 2003 (work in progress). [Page 18] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 [Inter-domain] A. Farrel, J-P. Vasseur, and A. Ayyangar, "A framework for inter-domain MPLS traffic engineering," April 2004. [HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS TE," Sept. 2002. [MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks", draft-shiomoto-multiarea- te-01.txt (work in progress). Author's Address Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 E-mail: dimitri.papadimitriou@alcatel.be Martin Vigoureux (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 (0)1 69 63 18 52 E-mail: martin.vigoureux@alcatel.fr Kohei Shiomoto NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp 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 [Page 19] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 France Email: jeanlouis.leroux@francetelecom.com Contributors Eiji Oki (NTT Network Innovation Laboratories) 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585, Japan Phone : +81 422 59 3441 E-mail: oki.eiji@lab.ntt.co.jp Emmanuel Dotaro (Alcatel) Route de Nozay, 91461 Marcoussis cedex, France Phone : +33 1 6963 4723 E-mail: emmanuel.dotaro@alcatel.fr 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. 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. [Page 20] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 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 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 21] draft-vigoureux-shiomoto-ccamp-gmpls-mrn-05.txt July 2004 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Conventions used in this document . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Multi-region network . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Plain node model . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Hybird node model . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Forwarding adjacency (FA) . . . . . . . . . . . . . . . . . . . 6 3.1.1. Interface switching capability . . . . . . . . . . . . . . . 7 3.1.1.1. Case I: Single interface switching capability . . . . . . . 7 3.1.1.2. Case II: Multiple interface switching capability . . . . . 7 3.1.2. Routing rule: compatibility . . . . . . . . . . . . . . . . . 8 3.1.2.1. Class 1: Compatible w/o need to set up new FAs . . . . . . 8 3.1.2.2. Class 2: Compatible iff new FAs setup . . . . . . . . . . . 9 3.1.3. Adaptation capability . . . . . . . . . . . . . . . . . . . . 9 3.2. Triggered signaling . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Virtual network topology . . . . . . . . . . . . . . . . . . . 11 4. Service application scenarios . . . . . . . . . . . . . . . . . . 12 4.1. Traffic engineering based on the virtual network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Traffic demand change . . . . . . . . . . . . . . . . . . . . 13 4.2. Migration from MPLS to GMPLS . . . . . . . . . . . . . . . . . 15 4.2.1. Traffic demand change . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Nest of FAs . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Normative references . . . . . . . . . . . . . . . . . . . . . . . . 18 Informative references . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property Rights Notices . . . . . . . . . . . . . . . . 20 IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 21 [Page 1]