Network Working Group                                 J.L. Le Roux (Ed.)  
Internet Draft                                            France Telecom 
Category: Informational                                     
Expires: January 2008                             D. Papadimitriou (Ed.)  
                                                          Alcatel-Lucent 
                                                       
                                                  
                                                         
                                                                         
                                                                         
                                                               July 2007 
 
 
        Evaluation of existing GMPLS Protocols against Multi Layer 
                    and Multi Region Networks (MLN/MRN) 
 
               draft-ietf-ccamp-gmpls-mln-eval-03.txt 
         
 
 
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   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. 
    
    
Abstract 
    
   This document provides an evaluation of Generalized Multi-Protocol 
   Label Switching (GMPLS) protocols and mechanisms against the 
   requirements for Multi-Layer Networks (MLN) and Multi-Region Networks 
   (MRN). In addition, this document identifies areas where additional 
   protocol extensions or procedures are needed to satisfy these 
   requirements, and provides guidelines for potential extensions. 
 
Le Roux et al.      Evaluation of GMPLS against MLN/MRN Reqs    [Page 1] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


 
 
 
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. 
 
Table of Contents 
    
   1.      Introduction................................................3 
   2.      MLN/MRN Requirements Overview...............................4 
   3.      Analysis....................................................4 
   3.1.    Multi Layer Network Aspects.................................4 
   3.1.1.  Support for Virtual Network Topology Reconfiguration........4 
   3.1.1.1.  Control of FA-LSPs Setup/Release..........................5 
   3.1.1.2.  Virtual TE-Links..........................................6 
   3.1.1.3.  Traffic Disruption Minimization During FA Release.........7 
   3.1.1.4.  Stability.................................................8 
   3.1.2.  Support for FA-LSP Attributes Inheritance...................8 
   3.1.3.  FA-LSP Connectivity Verification............................8 
   3.2.    Specific Aspects for Multi-Region Networks..................9 
   3.2.1.  Support for Multi-Region Signaling..........................9 
   3.2.2.  Advertisement of Internal Adaptation Capabilities...........9 
   4.      Evaluation Conclusion......................................12 
   5.      Security Considerations....................................12 
   6.      Acknowledgments............................................12 
   7.      References.................................................13 
   7.1.    Normative..................................................13 
   7.2.    Informative................................................13 
   8.      Editors' Addresses:........................................14 
   9.      Contributors' Addresses:...................................14 
   10.     Intellectual Property Statement............................15 
    
    
    
    
    
    
    
    
    
    
    
    
    
    
 
 
 
 
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 2] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


 
    
1. Introduction 
 
   Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to 
   handle multiple switching technologies: packet switching (PSC), 
   layer-two switching (L2SC), TDM switching (TDM), wavelength switching 
   (LSC) and fiber switching (FSC) (see [RFC 3945]). 
    
   A data plane layer is a collection of network resources capable of 
   terminating and/or switching data traffic of a particular format. For 
   example, LSC, TDM VC-11 and TDM VC-4-64c are three different layers. 
   A network comprising transport nodes with different data plane 
   switching layers controlled by a single GMPLS control plane instance 
   is called a Multi-Layer Network (MLN).  
 
   A GMPLS switching type (PSC, TDM, etc.) describes the ability of a 
   node to forward data of a particular data plane technology, and 
   uniquely identifies a control plane region. The notion of Label 
   Switched Path (LSP) Region is defined in [RFC4206]. A network 
   comprised of multiple switching types (for example PSC and TDM) 
   controlled by a single GMPLS control plane instance is called a 
   Multi-Region Network (MRN). 
    
   Note that the region is a control plane only concept. That is, layers 
   of the same region share the same switching technology and, 
   therefore, need the same set of technology-specific signaling 
   objects.  
 
   Note that a MRN is necessarily a MLN, but not vice versa, as a MLN 
   may consist of multiple data plane layers of the same switching 
   technology. Hence, in the following, we use the term "layer" if the 
   mechanism discussed applies equally to layers and regions (for 
   example VNT, virtual TE-link, etc.), and we specifically use the term 
   "region" if the mechanism applies only to the support of a MRN. 
 
   The objectives of this document are to evaluate existing GMPLS 
   mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471, 
   [RFC3473]]) against the requirements for MLN and MRN, defined in 
   [MLN-REQ]. From this evaluation, we identify several areas where 
   additional protocol extensions and modifications are required to meet 
   these requirements, and provide guidelines for potential extensions. 
    
   A summary of MLN/MRN requirements is provided in section 2. Then 
   section 3 evaluates for each of these requirements, whether current 
   GMPLS protocols and mechanisms meet the requirements. When the 
   requirements are not met by existing protocols, the document 
   identifies whether the required mechanisms could rely on GMPLS 
   protocols and procedure extensions or whether it is entirely out of 
   the scope of GMPLS protocols. 
    

 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 3] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   Note that this document specifically addresses GMPLS control plane   
   functionality for MLN/MRN in the context of a single administrative 
   control plane partition. Partitions of the control plane where 
   separate layers are under distinct administrative control are for 
   future study. 
    
   This document uses terminologies defined in [RFC3945], [RFC4206], and   
   [MLN-REQ].  
    
2. MLN/MRN Requirements Overview 
 
   Section 5 of [MLN-REQ] lists a set of functional requirements for 
   Multi Layer/Region Networks (MLN/MRN). These requirements are 
   summarized below, and a mapping with sub-sections of [MLN-REQ] is 
   provided. 
    
   Here is the list of requirements that apply to MLN: 
    
        - Support for robust Virtual Network Topology (VNT)   
          reconfiguration. This implies the following requirements: 
                - Optimal control of Forwarding Adjacency LSP (FA-LSP)   
                  setup and release (section  5.8.1 of [MLN-REQ]); 
                - Support for virtual TE-links (section 5.8.2 of [MLN- 
                  REQ]); 
                - Traffic Disruption minimization during FA-LSP release  
                  (section 5.5 of [MLN-REQ]); 
                - Stability (section 5.4 of [MLN-REQ]); 
    
        - Support for FA-LSP attributes inheritance (section 5.6 of  
          [MLN-REQ]); 
 
        - Support for FA-LSP data plane connectivity verification   
          (section 5.9 of [MLN-REQ]); 
         
   Here is the list of requirements that apply to MRN only: 
 
        - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); 
 
        - Advertisement of the adaptation capabilities and resources 
           (section 5.2 of [MLN-REQ]); 
    
3. Analysis 
 
3.1. Multi Layer Network Aspects 
    
3.1.1. Support for Virtual Network Topology Reconfiguration 
 
   A set of lower-layer FA-LSPs provides a Virtual Network Topology 
   (VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP 
   setup/release) according to traffic demands between source and 
   destination node pairs within a layer, network performance factors 
   such as maximum link utilization and residual capacity of the network 
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 4] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   can be optimized. Such optimal VNT reconfiguration implies several 
   mechanisms that are analyzed in the following sections. 
    
   Note that the VNT approach is just one possible approach to perform 
   inter-layer Traffic Engineering.   
 
3.1.1.1. Control of FA-LSPs Setup/Release 
         
   In a Multi-Layer Network, FA-LSPs are created, modified, released 
   periodically according to the change of incoming traffic demands from 
   the upper layer. 
    
   This implies a TE mechanism that takes into account the demands 
   matrix, the TE topology and potentially the current VNT, in order to 
   compute and setup a new VNT.  
 
   Several functional building blocks are required to support such TE 
   mechanism: 
    
        - Discovery of TE topology and available resources. 
    
        - Collection of upper layer traffic demands.  
    
        - Policing and scheduling of VNT resources with regard to  
          traffic demands and usage (that is, decision to setup/release  
          FA-LSPs); The functional component in charge of this function  
          is called a VNT Manager (VNTM).  
    
        - VNT Paths Computation according to TE topology, and  
          potentially taking into account the old (existing) VNT to  
          minimize changes. The Functional component in charge of VNT  
          computation may be distributed on network elements or may be  
          centralized on an external tool (such as a Path Computation  
          Element (PCE), [RFC4655]). 
    
        - FA-LSP setup/release. 
    
   GMPLS routing protocols provide TE topology discovery.  
   GMPLS signaling protocols allow setting up/releasing FA-LSPs. 
 
   VNT Management functions (resources policing/scheduling, decision to 
   setup/release FA-LSPs, FA-LSP configuration) are out of the scope of 
   GMPLS protocols. Such functionalities can be achieved directly on 
   layer border LSRs, or through one or more external tools. When an 
   external tool is used, an interface is required between the VNTM and 
   the network elements so as to setup/releases FA-LSPs. This could use 
   standard management interfaces such as [RFC4802]. 
    
   The set of traffic demands of the upper layer is required for the     
   VNT Manager to take decisions to setup/release FA-LSPs. Such 
   traffic demands include satisfied demands, for which one or more 
   upper layer LSP have been successfully satisfied, as well as 
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 5] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   unsatisfied demands and future demands, for which no upper layer LSP 
   has been setup yet. The collection of such information is beyond the 
   scope of GMPLS protocols, but may be partially inferred from 
   parameters carried in GMPLS signaling or advertised in GMPLS routing. 
    
   Finally, the computation of FA-LSPs that form the VNT can be 
   performed directly on layer border LSRs or on an external tool (such 
   as a Path Computation Element (PCE), [RFC4655]), and this is 
   independent of the location of the VNTM. VNT computation is triggered 
   by the VNTM (for example, when the path computation is externalized 
   on a PCE, the VNTM acts as Path Computation Client (PCC)). 
    
   Hence, to summarize, no GMPLS protocol extensions are required to 
   control FA-LSP setup/release. 
 
3.1.1.2. Virtual TE-Links 
         
   A Virtual TE-link is a TE-link between two upper layer nodes that is 
   not actually associated with a fully provisioned FA-LSP in a lower 
   layer. A Virtual TE-link represents the potentiality to setup an FA-
   LSP in the lower layer to support the TE-link that has been 
   advertised. A Virtual TE-link is advertised as any TE-link, following 
   the rules in [RFC4206] defined for fully provisioned TE-links. In 
   particular, the flooding scope of a Virtual TE-link is within an IGP 
   area, as is the case for any TE-link. 
     
   If an upper-layer LSP attempts (through a signalling message) to make 
   use of a Virtual TE-link, the underlying FA-LSP is immediately 
   signalled and provisioned in the process known as triggered 
   signaling. 
    
   The use of Virtual TE-links has two main advantages: 
    
     - Flexibility: allows the computation of an LSP path using TE-links  
       without needing to take into account the actual provisioning  
       status of the corresponding FA-LSP in the lower layer; 
     
     - Stability: allows stability of TE-links in the upper layer, while  
       avoiding wastage of bandwidth in the lower layer, as data plane  
       connections are not established until they are actually needed. 
    
   Virtual TE-links are setup/deleted/modified dynamically, according to 
   the change of the (forecast) traffic demand, operator's policies for 
   capacity utilization, and the available resources in the lower layer. 
    
   The support of Virtual TE-links requires two main building blocks: 
    
   - A TE mechanism for dynamic modification of Virtual TE-link    
     Topology; 
    
   - A signaling mechanism for the dynamic setup and deletion of 
     virtual TE-links. Setting up a virtual TE-link requires a  
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 6] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


     signaling mechanism allowing an end-to-end association  
     between Virtual TE-link end points so as to exchange link   
     identifiers as well as some TE parameters. 
    
   The TE mechanism responsible for triggering/policing dynamic 
   modification of Virtual TE-links is out of the scope of GMPLS 
   protocols. 
    
   Current GMPLS signalling does not allow setting up and releasing 
   Virtual TE-links. Hence GMPLS signalling must be extended to support 
   Virtual TE-links.  
 
   We can distinguish two options for setting up Virtual TE-links: 
    
   - The Soft FA approach that consists of setting up the FA-LSP in the   
     control plane without actually activating cross connections in the    
     data plane. On the one hand, this requires state maintenance on all    
     transit LSRs (N square issue), but on the other hand this may allow    
     for some admission control. Indeed, when a soft-FA is activated,   
     the resources may be no longer available for use by other soft-FAs  
     that have common links. These soft-FA will be dynamically released  
     and corresponding virtual TE-links are deleted. The soft-FA LSPs  
     may be setup using procedures similar to those described in  
     [RFC4872] for setting up secondary LSPs. 
    
   - The remote association approach that simply consists of exchanging  
      virtual TE-links IDs and parameters directly between TE-link end   
      points. This does not require state maintenance on transit LSRs,  
      but reduces admission control capabilities. Such an association  
      between Virtual TE-link end-points may rely on extensions to the  
      RSVP-TE ASON Call procedure ([RSVP-CALL]). 
    
   Note that the support of Virtual TE-links does not require any GMPLS 
   routing extension. 
 
3.1.1.3. Traffic Disruption Minimization During FA Release 
 
   Before deleting a given FA-LSP, all nested LSPs have to be rerouted 
   and removed from the FA-LSP to avoid traffic disruption. 
   The mechanisms required here are similar to those required for 
   graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism 
   allows for the deletion of a TE-link without disrupting traffic of 
   TE-LSPs that were using the TE-link. 
    
   Hence, GMPLS routing and/or signaling extensions are required 
   to support graceful deletion of TE-links. This may utilize the 
   procedures described in [GR-SHUT]: A transit LSR notifies a head-end 
   LSR that a TE-link along the path of a LSP is going to be torn down, 
   and also withdraws the bandwidth on the TE-link so that it is not 
   used for new LSPs. 
    
    
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 7] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


    
 
3.1.1.4. Stability 
         
   The stability of upper-layer LSP may be impaired if the VNT undergoes 
   frequent changes. In this context robustness of the VNT is defined as 
   the capability to smooth the impact of these changes and avoid their 
   subsequent propagation. 
    
   Guaranteeing VNT stability is out of the scope of GMPLS protocols and 
   relies entirely on the capability of the TE and VNT management 
   algorithms to minimize routing perturbations. This requires that the 
   algorithms takes into account the old VNT when computing a new VNT, 
   and try to minimize the perturbation. 
    
   A full mesh of upper-layer LSPs MAY be created between every pair of 
   border nodes between the upper and lower layers. The merit of a full 
   mesh of upper-layer LSPs is that it provides stability to the upper 
   layer routing. That is, forwarding table used in the upper layer is 
   not impacted if the VNT undergoes changes. Further, there is always 
   full reachability and immediate access to bandwidth to support LSPs 
   in the upper layer. But it also has significant drawbacks, since it 
   requires the maintenance of n^2 RSVP-TE sessions, which may be quite 
   CPU and memory consuming (scalability impact). Also this may lead to 
   significant bandwidth wastage. Note that the use of virtual TE-links 
   solves the bandwidth wastage issue, and may reduce the control plane 
   overload. 
    
  
3.1.2. Support for FA-LSP Attributes Inheritance 
 
   When a FA TE Link is advertised, its parameters are inherited from 
   the parameters of the FA-LSP, and specific inheritance rules are 
   applied.  
    
   This relies on local procedures and policies and is out of the scope 
   of GMPLS protocols. Note that this requires that both head-end and 
   tail-end of the FA-LSP are driven by same policies. 
    
3.1.3. FA-LSP Connectivity Verification 
 
   Once fully provisioned, FA-LSP liveliness may be achieved by 
   verifying its data plane connectivity. 
    
   FA-LSP connectivity verification relies on technology specific 
   mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD; 
   etc.) as for any other LSP. Hence this requirement is out of the 
   scope of GMPLS protocols. 
    
    
    
    
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 8] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


    
 
3.2. Specific Aspects for Multi-Region Networks 
    
3.2.1. Support for Multi-Region Signaling 
    
   There are actually several cases where a transit node could choose 
   between multiple SCs to be used for a lower region FA-LSP:  
    
   - ERO expansion with loose hops: The transit node has to expand the  
     path, and may have to select among a set of lower region SCs. 
   
   - Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of  
     an upper region LSP, comprises a multi-SC TE-link, the region  
     border node has to select among these SCs. 
           
   Existing GMPLS signalling procedures does not allow solving this 
   ambiguous choice of SC that may be used along a given path. 
     
   Hence an extension to GMPLS signalling has to be defined to indicate 
   the SC(s) that can be used and the SC(s) that cannot be used along 
   the path.  
 
3.2.2. Advertisement of Internal Adaptation Capabilities 
 
   In the MRN context, nodes supporting more than one switching 
   capability on at least one interface are called Hybrid nodes ([MLN-
   REQ]). Hybrid nodes contain at least two distinct switching elements 
   that are interconnected by internal links to provide adaptation 
   between the supported switching capabilities. These internal links 
   have finite capacities and must be taken into account when computing 
   the path of a multi-region TE-LSP. The advertisement of the internal 
   adaptation capability is required as it provides critical information 
   when performing multi-region path computation. 
 
   Figure 1a below shows an example of hybrid node. The hybrid node has 
   two switching elements (matrices), which support here TDM and PSC 
   switching respectively. The node terminates two PSC and TDM ports 
   (port1 and port2 respectively). It also has internal link connecting 
   the two switching elements.  
    
   The two switching elements are internally interconnected in such a 
   way that it is possible to terminate some of the resources of the TDM 
   port 2 and provide through them adaptation for PSC traffic, 
   received/sent over the internal PSC interface (#b). Two ways are 
   possible to set up PSC LSPs (port 1 or port 2). Available resources 
   advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover 
   both ways. 
    
    
    
    
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs    [Page 9] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


    
    
    
                             Network element  
                        .............................  
                        :            --------       :  
              PSC       :           |  PSC   |      :  
            Port1-------------<->---|#a      |      :  
                        :  +--<->---|#b      |      :  
                        :  |         --------       :  
              TDM       :  |        ----------      :  
              +PSC      :  +--<->--|#c  TDM   |     :  
            Port2 ------------<->--|#d        |     :  
                        :           ----------      :  
                        :............................  
    
                             Figure 1a. Hybrid node.  
 
 
 
   Port 1 and Port 2 can be grouped together thanks to internal DWDM, to 
   result in a single interface: Link 1. This is illustrated in figure 
   1b below. 
    
                             Network element  
                        .............................  
                        :            --------       :  
                        :           |  PSC   |      :  
                        :           |        |      :  
                        :         --|#a      |      :  
                        :        |  |   #b   |      :  
                        :        |   --------       :  
                        :        |       |          :  
                        :        |  ----------      :  
                        :    /|  | |    #c    |     :  
                        :   | |--  |          |     :  
              Link1 ========| |    |    TDM   |     :  
                        :   | |----|#d        |     :  
                        :    \|     ----------      :  
                        :............................  
    
                        Figure 1b. Hybrid node.  
    
    
   Let's assume that all interfaces are STM16 (with VC4-16c capable  
   as Max LSP bandwidth). After, setting up several PSC LSPs via port #a 
   and setting up and terminating several TDM LSPs via port #d and port 
   #b, there is only 155 Mb capacities still available on port #b. 
   However a 622 Mb capacity remains on port #a and VC4-5c capacity on 
   port #d. 
    

 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 10] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   When computing the path for a new VC4-4c TDM LSP, one must know, that 
   this node cannot terminate this LSP, as there is only 155Mb still 
   available for TDM-PSC adaptation. Hence the internal TDM-PSC 
   adaptation capability must be advertised. 
    
   With current GMPLS routing [RFC4202] this advertisement is possible 
   if link bundling is not used and if two TE-links are advertised for 
   link1: 
    
   We would have the following TE-link advertisements: 
    
   TE-link 1 (port 1):  
        - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb 
        - Unreserved bandwidth = 622Mb. 
          
   TE-Link 2 (port 2): 
        - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,               
        - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, 
        - Unreserved bandwidth (equivalent): 777 Mb.  
    
   The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC 
   adaptation capability. 
    
   However if for obvious scalability reasons link bundling is done then 
   the adaptation capability information is lost with current GMPLS 
   routing, as we have the following TE-link advertisement: 
    
   TE-link 1 (port 1 + port 2):  
        - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,  
        - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,  
        - Unreserved bandwidth (equivalent): 1399 Mb.  
     
   With such TE-link advertisement an element computing the path of a 
   VC4-4c LSP cannot know that this LSP cannot be terminated on the 
   node. 
    
   Thus current GMPLS routing can support the advertisement of the 
   internal adaptation capability but this precludes performing link 
   bundling and thus faces significant scalability limitations.  
    
   Hence, GMPLS routing must be extended to meet this requirement. This 
   could rely on the advertisement of the internal adaptation capability 
   as a new TE link attribute (that would complement the Interface 
   Switching Capability Descriptor TE-link attribute).  
    
   Note: Multiple ISCDs MAY be associated to a single switching 
   capability. This can be performed to provide e.g. for TDM interfaces 
   the Min/Max LSP Bandwidth associated to each (set of) layer for that 
   switching capability. As an example, an interface associated to TDM 
   switching capability and supporting VC-12 and VC-4 switching, can be 
   associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, 
   the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to 
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 11] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and 
   the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the 
   Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, 
   in the second ISCD sub-TLV. Hence, in the first case, as long as the 
   Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second 
   case, as long as the first ISCD sub-TLV is advertised there is 
   sufficient capacity across that interface to setup a VC-12 LSP." 
 
4. Evaluation Conclusion 
 
   Most of the required MLN/MRN functions will rely on mechanisms and 
   procedures that are out of the scope of the GMPLS protocols, and thus 
   do not require any GMPLS protocol extensions. They will rely on local 
   procedures and policies, and on specific TE mechanisms and 
   algorithms. 
    
   As regards Virtual Network Topology (VNT) computation and 
   reconfiguration, specific TE mechanisms need to be defined, but these 
   mechanisms are out of the scope of GMPLS protocols. 
    
   Four areas for extensions of GMPLS protocols and procedures have been 
   identified: 
    
        - GMPLS signaling extension for the setup/deletion of    
          the virtual TE-links; 
    
        - GMPLS routing and signaling extension for graceful TE-link  
          deletion; 
 
        - GMPLS signaling extension for constrained multi-region  
          signalling (SC inclusion/exclusion); 
    
        - GMPLS routing extension for the advertisement of the  
          internal adaptation capability of hybrid nodes. 
    
5. Security Considerations 
    
   This document specifically addresses GMPLS control plane   
   functionality for MLN/MRN in the context of a single administrative 
   control plane partition and hence does not introduce additional 
   security threats beyond those described in [RFC3945]. 
 
6. Acknowledgments 
 
   We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel 
   for their useful comments. 
    
    
    
    
    
    
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 12] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


    
 
7. References 
 
7.1. Normative 
    
   [RFC3979]    Bradner, S., "Intellectual Property Rights in IETF 
                Technology", BCP 79, RFC 3979, March 2005. 
 
   [RFC3945]    Mannie, E., et. al. "Generalized Multi-Protocol Label 
                Switching Architecture", RFC 3945, October 2004 
 
   [RFC4202]    Kompella, K., Ed. and Y. Rekhter, Ed., "Routing 
                Extensions in Support of Generalized Multi-Protocol 
                Label Switching", draft-ietf-ccamp-gmpls-routing, 
                RFC4202, October 2005. 
 
   [RFC3471]    Berger, L., et. al. "Generalized Multi-Protocol Label 
                Switching (GMPLS) Signaling Functional Description", RFC 
                3471, January 2003. 
                 
 
7.2. Informative 
    
   [RSVP-CALL]  Papadimitriou, D., Farrel, A., et. al., "Generalized 
                MPLS (GMPLS) RSVP-TE Signaling Extensions in support of 
                Calls", draft-ietf-ccamp-gmpls-rsvp-te-call, work in 
                progress. 
    
   [MLN-REQ]    Shiomoto, K., Papadimitriou, D., Le Roux, J.L., 
                Vigoureux, M., Brungard, D., "Requirements for GMPLS-
                based multi-region and multi-layer networks", draft-
                ietf-ccamp-gmpls-mrn-reqs, work in progess.  
    
   [RFC4206]    K. Kompella and Y. Rekhter, "LSP hierarchy with 
                generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, 
                RFC4206, October 2005. 
 
   [GR-SHUT]    Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic 
                Engineering Network", draft-ietf-ccamp-mpls-graceful-
                shutdown, work in progress.  
    
   [RFC4872]    Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in  
                 support of End-to-End Generalized Multi-Protocol Label 
                Switching (GMPLS)-based Recovery", RFC4872, July 2007. 
    
   [VNTM]       Oki, Le Roux, Farrel, "Definition of Virtual Network  
                 Topology Manager (VNTM) for PCE-based Inter-Layer MPLS 
                and GMPLS Traffic Engineering", draft-oki-pce-vntm-def, 
                work in progress. 
 
   [IW-MIG-FMWK]Shiomoto, K et al., "Framework for IP/MPLS-GMPLS  
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 13] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


                 interworking in support of IP/MPLS to GMPLS migration", 
                draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in 
                progress.   
 
   [RFC3473]   Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",  
                RFC3473, January 2003. 
 
   [RFC4655]   Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based 
                Architecture", RFC4655, August 2006. 
 
   [RFC4802]   Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, 
                February 2007. 
 
8. Editors' Addresses  
  
   Jean-Louis Le Roux 
   France Telecom  
   2, avenue Pierre-Marzin  
   22307 Lannion Cedex, France 
   Email: jeanlouis.leroux@orange-ftgroup.com 
 
   Dimitri Papadimitriou 
   Alcatel-Lucent 
   Francis Wellensplein 1, 
   B-2018 Antwerpen, Belgium 
   Email: dimitri.papadimitriou@alcatel-lucent.be 
    
9. Contributors' Addresses  
    
   Deborah Brungard 
   AT&T 
   Rm. D1-3C22 - 200 S. Laurel Ave. 
   Middletown, NJ, 07748 USA 
   E-mail: dbrungard@att.com 
    
   Eiji Oki 
   NTT 
   3-9-11 Midori-Cho 
   Musashino, Tokyo 180-8585, Japan 
   Email: oki.eiji@lab.ntt.co.jp 
    
   Kohei Shiomoto 
   NTT 
   3-9-11 Midori-Cho 
   Musashino, Tokyo 180-8585, Japan 
   Email: shiomoto.kohei@lab.ntt.co.jp 
    
   M. Vigoureux 
   Alcatel-Lucent France 
   Route de Villejust 
   91620 Nozay 
   FRANCE 
 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 14] 
  
Internet Draft    draft-ietf-ccamp-gmpls-mln-eval-03.txt       July 2007 


   Email: martin.vigoureux@alcatel-lucent.fr 
 
 
10. Intellectual Property Statement 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.   
    
   Disclaimer of Validity 
    
   This document and the information contained herein are provided 
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE  
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE. 
 
   Copyright Statement 
    
   Copyright (C) The IETF Trust (2007). This document is subject to the 
   rights, licenses and restrictions contained in BCP 78, and except as 
   set forth therein, the authors retain all their rights. 
    
  








 
Le Roux, et al.   Evaluation of GMPLS against MLN/MRN Reqs   [Page 15]