Network Working Group                                 J.L. Le Roux (France Telecom) (Ed.)
Internet Draft                                        D. Brungard (AT&T)                                            France Telecom
Category: Informational                                     E. Oki (NTT)
Expires: April 2007 January 2008                             D. Papadimitriou (Alcatel)
                                                       K. Shiomoto (NTT)
                                                  M. Vigoureux (Alcatel)

                                                            October 2006 (Ed.)
                                                          Alcatel-Lucent
        Evaluation of existing GMPLS Protocols against Multi Layer
                    and Multi Region Networks (MLN/MRN)

               draft-ietf-ccamp-gmpls-mln-eval-02.txt

               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.

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.      Terminology.................................................3
   2.      Introduction................................................3
   3.
   2.      MLN/MRN Requirements Overview...............................4
   4.
   3.      Analysis....................................................4
   4.1.    Multi-Layer Aspects.........................................4
   4.1.1.
   3.1.    Multi Layer Network Aspects.................................4
   3.1.1.  Support for Virtual Network Topology Reconfiguration........4
   4.1.1.1.
   3.1.1.1.  Control of FA-LSPs Setup/Release..........................5
   4.1.1.2.
   3.1.1.2.  Virtual TE-Links..........................................6
   4.1.1.3.
   3.1.1.3.  Traffic Disruption Minimization During FA Release.........8
   4.1.1.4. Release.........7
   3.1.1.4.  Stability.................................................8
   4.1.2.
   3.1.2.  Support for FA-LSP Attributes Inheritance...................8
   4.1.3.  Support for Triggered Signaling.............................8
   4.1.4.  FA
   3.1.3.  FA-LSP Connectivity Verification................................9
   4.2.    Multi-Region Verification............................8
   3.2.    Specific Aspects...............................9
   4.2.1. Aspects for Multi-Region Networks..................9
   3.2.1.  Support for Multi-Region Signaling..........................9
   4.2.2.
   3.2.2.  Advertisement of Internal Adaptation Capabilities..........10
   5. Capabilities...........9
   4.      Evaluation Conclusion......................................12
   6.
   5.      Security Considerations....................................13 Considerations....................................12
   6.      Acknowledgments............................................12
   7.      Acknowledgments............................................13
   8.      References.................................................13
   8.1.
   7.1.    Normative..................................................13
   8.2.
   7.2.    Informative................................................13
   9.      Authors'
   8.      Editors' Addresses:........................................14
   9.      Contributors' Addresses:...................................14
   10.     Intellectual Property Statement............................15

1. Terminology

   This document uses terminologies defined in [RFC3945], [RFC4206], and
   [MLN-REQ].

2. 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 represent 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 LSP Label
   Switched Path (LSP) Region is defined in [RFC4206]. A network
   comprised of multiple switching types (e.g. (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 technology-specific signaling
   objects.

   Note that a MRN is necessarily a MLN, but not vice versa, as a MLN
   may consist of a single region (control of multiple data plane layers
   within a region). of the same switching
   technology. Hence, in the following, we use the term layer "layer" if the
   mechanism discussed applies equally to layers and regions (e.g. (for
   example VNT, virtual TE-link, etc.), and we specifically use the term region
   "region" if the mechanism applies only for supporting to the support of a MRN.

   The objectives of this document are to evaluate existing GMPLS
   mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471]) [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.

   An overview

   A summary of MLN/MRN requirements is provided in section 3. 2. Then
   section 4 3 evaluates for each of these requirements, whether current
   GMPLS protocols and mechanisms allow addressing meet the requirements. When the
   requirements are not met, met by existing protocols, the document
   identifies whether the required mechanisms could rely on GMPLS
   protocols and procedure extensions or if whether it is entirely out of
   the scope of GMPLS protocols.

   Note that this document specifically addresses GMPLS control plane
   functionality for MLN/MRN in the context of a single administrative
   control plane partition.

3. 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: below, and a mapping with sub-sections of [MLN-REQ] is
   provided.

   Here is the list of requirements that apply to MLN:

        - Support of for robust Virtual Network Topology (VNT)
          reconfiguration. This implies the following requirements:
                - Optimal control of FA-LSP Forwarding Adjacency LSP (FA-LSP)
                  setup and release; release (section  5.8.1 of [MLN-REQ]);
                - Support for virtual TE-links; TE-links (section 5.8.2 of [MLN-
                  REQ]);
                - Traffic Disruption minimization during FA-LSP release
                  (e.g. network reconfiguration events);
                  (section 5.5 of [MLN-REQ]);
                - Stability; Stability (section 5.4 of [MLN-REQ]);

        - Support for FA-LSP attributes inheritance;

        - Support for Triggered Signaling; inheritance (section 5.6 of
          [MLN-REQ]);

        - Support for FA-LSP data plane connectivity verification; verification
          (section 5.9 of [MLN-REQ]);

   Here is the list of requirements that apply to MRN only:

        - Support for Multi-Region signaling; signaling (section 5.7 of [MLN-REQ]);

        - Advertisement of the adaptation capabilities and resources;

4. resources
           (section 5.2 of [MLN-REQ]);

3. Analysis

4.1. Multi-Layer

3.1. Multi Layer Network Aspects

4.1.1.

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. upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP
   setup/release) according to traffic demands between source and
   destination node pairs of within a layer, network performance factors
   such as maximum link utilization and residual capacity of the network
   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 among others, to perform
   inter-layer Traffic Engineering.

4.1.1.1.

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 traffic demands of the upper layer. layer traffic demands.

        - Policing and scheduling of VNT resources policing/scheduling with regards regard to
          traffic demands and usage (i.e. (that is, decision to setup/release FAs);
          FA-LSPs); The functional component in charge of this function
          is called a VNT Manager (VNTM), it may be distributed on network
          elements or centralized on an external tool (see [VNTM]). It
          may also be partially centralized and distributed. (VNTM).

        - VNT Path Paths Computation according to TE topology, and
          potentially taking into account the old (existing) VNT (to to
          minimize changes); 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 e.g. a PCE). Path Computation
          Element (PCE), [RFC4655]).

        - FA-LSP setup/release.

   GMPLS routing protocols support provide TE topology discovery.
   GMPLS signaling protocols allow setting up/releasing FA-LSPs.

   VNT Management functions (resources policing/scheduling, decision to
   setup/release FA, FA FA-LSPs, FA-LSP configuration) are out of the scope of
   GMPLS protocols. Such functionalities can be achieved directly on
   layer border LSRs, and/or on 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 has as to setup/releases FA-LSPs. This may rely on SNMP (TE
   MIB) or on proprietary interfaces. 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 FAs. This requires
   knowledge of the aggregated bandwidth reserved by FA-LSPs. Such
   traffic demands include satisfied demands, for which one or more
   upper layer LSPs
   established between any pair of border LSRs.
   Existing GMPLS routing allows for the collection of traffic demands
   of the upper region. It can be deduced from FA TE-link advertisements.
   The set of traffic demands can be inferred:
      - either directly, based on upper-layer FA TE-link advertisements.

        The traffic demands between two points correspond to the
        cumulated bandwidth reserved by upper-layer LSPs between these
        two points;
      - or indirectly, based on lower-layer FA TE-link advertisements.
        In this case a mechanism to infer the upper-layer traffic demand
        from the aggregated bandwidth reserved in lower-layer LSPs might
        be required, LSP have been successfully satisfied, as all pairs of border nodes may not be directly
        connected by a lower layer LSP.

   Collection of traffic well as
   unsatisfied demands of an and future demands, for which no upper region may actually be
   achieved in several ways depending on the location of VNT Managers:
      - If a VNTM is distributed on border layer LSRs, then the LSP
   has been setup yet. The collection of traffic demands would rely on existing GMPLS
        routing, as per described above;
      - If a VNTM such information is centralized on an external tool, then beyond the
        collection
   scope of traffic demands GMPLS protocols, but may be achieved using existing
        GMPLS routing, provided that the tool relies on partially inferred from
   parameters carried in GMPLS routing to
        discover TE link information, signaling or it may rely on another
        mechanism out of the scope of advertised in GMPLS protocols (e.g. SNMP TE-link
        MIB). routing.

   Finally, VNT the computation of FA-LSPs that form the VNT can be
   performed directly on layer border LSRs or on an external tool (such
   as an external PCE) a Path Computation Element (PCE), [RFC4655]), and this
   independently is
   independent of the location of the VNTM. VNT computation is triggered
   by the VNTM (e.g. (for example, when the Path path computation is externalized
   on a PCE, the VNTM acts as PCC).

   Hence Path Computation Client (PCC)).

   Hence, to summarize, no GMPLS protocol extensions are required to
   control FA-LSP setup/release.

4.1.1.2.

3.1.1.2. Virtual TE-Links

   A Virtual TE-link is a TE-link between two nodes, upper layer nodes that is
   not actually associated to with a fully provisioned FA-LSP. FA-LSP in a lower
   layer. A Virtual TE-link represents the potentiality to setup a FA-LSP. There is no IGP
   adjacency associated an FA-
   LSP in the lower layer to a Virtual TE-link. support the TE-link that has been
   advertised. A Virtual TE-link is advertised as any classical TE-link, i.e. following
   the rules in [RFC4206] defined for fully provisioned TE-links. Particularly, In
   particular, the flooding scope of a Virtual TE-link is within an IGP
   area, as is the case for any TE-
   link.

   During its signalling, if TE-link.

   If an upper-layer LSP makes attempts (through a signalling message) to make
   use of a Virtual TE-link, the underlying FA-LSP is immediately
   signalled and
   provisioned. provisioned in the process known as triggered
   signaling.

   The use of Virtual TE-links has two main advantages:

     - flexibility: Flexibility: allows to compute a the computation of an LSP path using TE-links and this
       without taking needing to take into account the actual provisioning
       status of the corresponding FA-LSP in the lower layer in terms of provisioning; layer;

     - stability: 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. 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 signalling signaling mechanism for the dynamic setup and deletion of
     virtual TE-links. Setting up a virtual TE-link requires a
          signalling
     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, approach that consists of setting up the FA-LSP in the
     control plane without actually activating cross connections in the
     data plane. One 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, there
     the resources may be no longer available resources for use by other soft-
   FAs soft-FAs
     that were sharing have common links, these 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
   [GMPLS-RECOVERY]
     [RFC4872] for setting up secondary LSPs.

        -The

   - The remote association approach, approach that simply consists of exchanging
      virtual TE-links ids IDs and parameters directly between TE-
   link TE-link end
      points. This does not require state maintenance on transit LSRs,
      but reduce reduces admission control capabilities. Such an association
      between Virtual TE-link end-points may rely on extensions to the
      RSVP-TE ASON Call procedure ([ASON-CALL]). ([RSVP-CALL]).

   Note that the support of Virtual TE-link TE-links does not require any GMPLS
   routing extension.

4.1.1.3.

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 where were using the TE-link.
   GMPLS protocols do not provide for explicit indication to trigger
   such operation.

   Hence, GMPLS routing and/or signaling extensions are required
   to support graceful deletion of TE-links. This may rely, for
   instance, on new signaling Error code to notify utilize the
   procedures described in [GR-SHUT]: A transit LSR notifies a head-end LSRs
   LSR that a TE-link along the path of a LSP is going to disappear, be torn down,
   and also withdraws the bandwidth on the TE-link so that it is not
   used for new routing attributes (if limited to a single IGP area), such as
   defined in [GR-SHUT].

4.1.1.4. LSPs.

3.1.1.4. Stability

   The stability of upper-layer LSP stability 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 TE algorithm
   algorithms takes into account the old VNT when computing a new VNT,
   and tries try to minimize the perturbation.

4.1.2.

   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 TE Link is advertised, its parameters are inherited from FA-LSP parameters,
   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.

4.1.3. Support for Triggered Signaling.

   When a LSP crosses the boundary from an upper to a lower layer, it
   may be nested in or stitched to a lower-layer LSP. If such an LSP
   does not exist the LSP may be established dynamically. Such a
   mechanism is referred to as "Triggered signaling".

   Triggered signaling requires the following building blocks:
        - The identification of layer boundaries.
        - A path computation engine capable of computing a path
          containing multiple layers.

        - A mechanism for nested signaling.

   The identification of layer boundaries is supported by GMPLS routing
   protocols. The identification of layer boundaries is performed using
   the interface switching capability descriptor associated to the TE-
   link (see [RFC4206] and [RFC4202]).

   The capability to compute a path containing multiple layers is a
   local implementation issue and is out of the scope of GMPLS protocols.

   A mechanism for nested signaling is defined in [RFC4206].

   Hence, GMPLS protocols already meet this requirement.

4.1.4. FA Connectivity Verification

   Once fully provisioned, FA liveliness

3.1.3. FA-LSP Connectivity Verification

   Once fully provisioned, FA-LSP liveliness may be achieved by
   verifying its data plane connectivity.

   FA

   FA-LSP connectivity verification relies on technology specific
   mechanisms
   (e.g. (e.g., for SDH, G.707, G.783, SDH using G.707 and G.783; for MPLS, BFD, MPLS using BFD;
   etc.) as for any other LSP. Hence this requirement is out of the
   scope of GMPLS protocols.

   Note that the time to establish the FA-LSP must be minimized.

4.2. Multi-Region

3.2. Specific Aspects

4.2.1. for Multi-Region Networks

3.2.1. Support for Multi-Region Signaling

   Applying the triggered signaling procedure discussed above, in

   There are actually several cases where a MRN
   environment may lead to the setup of one-hop FA-LSPs transit node could choose
   between each
   node. Therefore, considering that the path computation is able multiple SCs to
   take into account richness of information be used for a lower region FA-LSP:

   - ERO expansion with regard to the
   Switching Capability (SC) available on given nodes belonging loose hops: The transit node has to expand the
     path, it is consistent to provide enough signaling information and may have to
   indicate select among a set of lower region SCs.

   - Multi-SC TE link: When the SC 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 and on over which link.

   Limited along a given path.

   Hence an extension to existing GMPLS signaling procedures is required
   for this purpose as it only mandates indication of the SCs signalling has to be
   included or excluded before initiating defined to indicate
   the LSP provisioning procedure.
   This enhancement would solve SC(s) that can be used and the ambiguous choice of SC SC(s) that are
   potentially cannot be used along a given path, particularly in case of ERO
   expansion, or when an ERO sub-object identifies a multi-SC TE-link.
   This would give
   the possibility to optimize resource usage on a
   multi-region basis.

4.2.2. 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. 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.

                             Network element
                        .............................
                        :            --------       :
              PSC       :           |  PSC   |      :
            Port1-------------<->--|#a
            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.

   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 622Mb
        - Unreserved bandwidth = 622Mb.

   TE-Link 2 (port 2):
        - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
                           unreserved bandwidth = vc4-5c.
        - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
                           unreserved
        - Unreserved bandwidth = 155 (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,
                           unreserved bandwidth = vc4-5c.
        - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
                           unreserved
        - Unreserved bandwidth = 777 (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).

5.

   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
   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 that could for instance rely
   on PCE based mechanisms and protocols, 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 signalling signaling extension for the setup/deletion of
          the virtual TE-links (as well as exact trigger for its actual
          provisioning); TE-links;

        - GMPLS routing and signalling signaling extension for graceful TE-link
          deletion;

        - GMPLS signalling signaling extension for constrained multi-region
          signalling (SC inclusion/exclusion);

        - GMPLS routing extension for the advertisement of the
          internal adaptation capability of hybrid nodes.

6.

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].

7.

6. Acknowledgments

   We would like to thank Julien Meuric and Meuric, Igor Bryskin and Adrian Farrel
   for their useful comments.

8.

7. References

8.1.

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.

8.2.

7.2. Informative

   [ASON-CALL]

   [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, 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 GMPLS-
                based multi-region and multi-layer networks", draft-ietf-ccamp-gmpls-mrn-reqs, 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, draft-ietf-ccamp-mpls-graceful-
                shutdown, work in progress.

   [GMPLS-RECOVERY]

   [RFC4872]    Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
                 support of End-to-End Generalized Multi-Protocol Label
                Switching (GMPLS)-based Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-
   signaling, work in progress. 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,

   [IW-MIG-FMWK]Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
                 interworking in support of IP/MPLS to GMPLS migration", draft-ietf-
   ccamp-mpls-gmpls-interwork-fmwk,
                draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in
                progress.

9. Authors' Addresses:

   [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 (Editor)
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex, France
   Email: jeanlouis.leroux@orange-ft.com 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

   Dimitri Papadimitriou
   Alcatel
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Email: dimitri.papadimitriou@alcatel.be

   Kohei Shiomoto
   NTT
   3-9-11 Midori-Cho
   Musashino, Tokyo 180-8585, Japan
   Email: shiomoto.kohei@lab.ntt.co.jp
   Martin

   M. Vigoureux
   Alcatel
   Alcatel-Lucent France
   Route de Nozay,
   91461 Marcoussis Cedex, France Villejust
   91620 Nozay
   FRANCE
   Email: martin.vigoureux@alcatel.fr 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.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   Disclaimer of Validity

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 Internet Society (2006). 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.