Network Working Group                                J.L. Le Roux (Ed.)
Internet Draft                                           France Telecom
Category: Informational
Created: December 17, 2007
Expires: January 2009                           D.  Papadimitriou (Ed.)
Expires: June 17, 2008
                                                         Alcatel-Lucent
        Evaluation of existing Existing GMPLS Protocols against Against Multi Layer
                    and Multi Region Networks (MLN/MRN)

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

               draft-ietf-ccamp-gmpls-mln-eval-06.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.      Introduction................................................3
   2.      MLN/MRN Requirements Overview...............................4
   3.      Analysis....................................................4      Analysis....................................................5
   3.1.    Multi Layer Network Aspects.................................4 Aspects.................................5
   3.1.1.  Support for Virtual Network Topology Reconfiguration........4 Reconfiguration........5
   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.1.4.  Scalability.................................................9
   3.1.5.  Operations and Management of the MLN/MRN...................10
   3.1.5.1.  MIB Modules..............................................10
   3.1.5.2.  OAM......................................................10
   3.2.    Specific Aspects for Multi-Region Networks..................9 Networks.................11
   3.2.1.  Support for Multi-Region Signaling..........................9 Signaling.........................11
   3.2.2.  Advertisement of Adjustment Capacities......................9 Capacities.....................12
   4.      Evaluation Conclusion......................................12 Conclusion......................................15
   4.1.    Traceability of Requirements...............................15
   5.      Security Considerations....................................13 Considerations....................................19
   6.      IANA Considerations........................................13 Considerations........................................19
   7.      Acknowledgments............................................13      Acknowledgments............................................19
   8.      References.................................................13      References.................................................19
   8.1.    Normative References.......................................13 References.......................................19
   8.2.    Informative References.....................................14 References.....................................20
   9.      Editors' Addresses:........................................14 Addresses.........................................21
   10.     Contributors' Addresses:...................................15 Addresses....................................22
   11.     Intellectual Property Statement............................15 Statement............................22

1. Introduction

   Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
   technologies: packet switching, layer-2 switching, TDM switching,
   wavelength switching, and fiber switching (see [RFC3945]). The
   Interface Switching Capability (ISC) concept is introduced for
   these switching technologies and is designated as follows: PSC
   (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time
   Division Multiplex capable), LSC (Lambda Switch Capable), and FSC
   (Fiber Switch Capable). The representation, in a GMPLS control
   plane, of a switching technology domain is referred to as a region
   [RFC4206]. A switching type describes the ability of a node to
   forward data of a particular data plane technology, and uniquely
   identifies a network region.

   A data plane switching layer describes a data plane switching
   granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are
   three different layers.  [MLN-REQ] defines a Multi Layer Network
   (MLN) to be a TE domain comprising multiple data plane switching
   layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM
   and PSC) and controlled by a single GMPLS control plane instance.
   [MLN-REQ] further define defines a particular case of MLNs. A Multi Region
   Network (MRN) is defined as a TE domain supporting at least two
   different switching types (e.g., PSC and TDM), either hosted on the
   same device or on different ones, and under the control of a single
   GMPLS control plane instance.

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

   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 (and thus to MRN):

   - 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]);

   - MLN Scalability (section 5.3 of [MLN-REQ]);

   - MLN OAM (section 5.10 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 adjustment capacity (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
   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) [PCE-INTER].

   - 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 performed on an external
     tool
     element (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.

   VNTM 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/release 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 setup, as well as 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. Note that it may be partially inferred from
   parameters carried in GMPLS signalling 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 element
   (such as a Path Computation Element (PCE), [RFC4655]), and this is
   independent of the location of the VNTM.

   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 signaling message) to make
   use of a Virtual TE-link, the underlying FA-LSP is immediately
   signalled
   signaled and provisioned (provided there are available resources in
   the lower layer) 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 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 signaling does not allow setting up and releasing
   Virtual TE-links. Hence GMPLS signalling signaling 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 ([RFC4974]).

   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.

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 take into account the old VNT when computing a new VNT,
   and try to minimize the perturbation.

   Note that a full mesh of lower-layer LSPs may be created between
   every pair of border nodes between the upper and lower layers. The
   merit of a full mesh of lower-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, where n is the number of border nodes, 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.

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 GMPLS protocols should provide mechanisms for the ERO coordination
   of a FA LSP, included data link verification 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 layer network where data
   links are lower layer LSPs.
     o GMPLS signalling procedures do not allow solving this
   ambiguous choice of SC that may be used along a given path.

   Hence signaling allows an extension to GMPLS signalling has LSP to be defined to indicate
   the SC(s) that put into 'test' mode
       [RFC3473].
     o The link Management Protocol [RFC4204] is a targeted protocol and
       can be used and the SC(s) that cannot run end-to-end across lower-layer LSPs.
     o Coordination of testing procedures in different layers is an
       operational matter.

3.1.4. Scalability

   As discussed in [MLN-REQ]), MRN/MLN routing mechanisms must be used along
   the path.

3.2.2. Advertisement
   designed to scale well with an increase of any of Adjustment Capacities

   In the MRN context, following:
     - Number of nodes supporting more than one switching
   capability
     - Number of TE-links (including FA-LSPs)
     - Number of LSPs
     - Number of regions and layers
     - Number of ISCDs per TE-link.

   GMPLS routing provides the necessary advertisement functions and is
   based on at least one interface IETF-designed IGPs. These are called Hybrid nodes ([MLN-
   REQ]). Conceptually, hybrid nodes can be viewed as containing at
   least two distinct switching elements interconnected by internal
   links which provide adjustment between the supported switching
   capabilities. These internal links have finite capacities and must be
   taken into account when computing known to scale relatively well
   with the path number of nodes and links. Where there are multiple regions
   or layers there are two possibilities.
   1. If a multi-region TE-LSP.
   The advertisement of single routing instance distributes information about
   multiple network layers, the adjustment capacities effect is required as it
   provides critical information when performing multi-region path
   computation.

   The term adjustment capacity refers no more than to increase the property
   number of a hybrid node
   to interconnect different switching capabilities it provides though
   its external interfaces [MLN-REQ]. This information allows path
   computation to select an end-to-end multi-region path that includes nodes and links of different switching capabilities that are joined by LSRs
   that can adapt in the signal between network.
   2. If the links.

   Figure 1a below shows MLN is fully integrated (i.e., constructed from hybrid
   nodes), there is an example increase in the number of hybrid node. The hybrid node has
   two switching elements (matrices), which support here TDM and PSC
   switching respectively. The node has two PSC nodes and TDM ports (port1 links
   as just mentioned, and
   port2 respectively). It also has internal link connecting a potential increase in the two amount
   of ISCD information advertised per link. This is a relatively
   small amount of information (e.g., 36 bytes in OSPF [RFC4203])
   per switching elements.

   The type, and each interface is unlikely to have more
   than two or three switching elements are internally interconnected types.

   The number of LSPs in such a
   way that it is possible to terminate some lower layer, advertised as TE-links may
   impact the scaling of the resources routing protocol. A full mesh of FA-LSPs in
   the TDM
   port 2 and provide through them adjustment lower layer would lead to n^2 TE-links where n is the number of
   layer border LSRs. This must be taken into consideration in the VNT
   management process. This is an operational matter beyond the scope of
   GMPLS protocols.

   As regards the scalability of GMPLS signaling, a full mesh of LSPs in
   the lower layer may impact the salability since it requires the
   maintenance of n^2 RSVP-TE sessions, which may be quite CPU and
   memory consuming. The use of virtual TE-links may reduce the control
   plane overload (see section 3.1.1.2).

3.1.5. Operations and Management of the MLN/MRN

   [MLN-REQ] identifies various requirements for PSC traffic,
   received/sent over effective management
   and operation of the internal PSC interface (#b). Two ways MLN. Some features already exist within the
   GMPLS protocol set, some more are
   possible under development, and some
   requirements are not currently addressed and will need new
   development work in order to set up PSC LSPs (port 1 or port 2). Available resources
   advertisement e.g. Unreserved support them.

3.1.5.1. MIB Modules

   MIB modules have been developed to model and Min/Max LSP Bandwidth should cover
   both ways.

                             Network element
                        .............................
                        :            --------       :
              PSC       :           |  PSC   |      :
            Port1-------------<->---|#a      |      :
                        :  +--<->---|#b      |      :
                        :  |         --------       :
                        :  |        ----------      :
              TDM       :  +--<->--|#c  TDM   |     :
            Port2 ------------<->--|#d        |     :
                        :           ----------      :
                        :............................

                             Figure 1a. Hybrid node.

   Port 1 control GMPLS switches
   [RFC4803] and Port 2 can be grouped together thanks to internal DWDM, control and report on the operation of the signaling
   protocol [RFC4802]. These may be successfully used to
   result in manage the
   operation of a single interface: Link 1. This is illustrated instance of the control plane protocols that
   operate across multiple layers.

   [RFC4220] provides a MIB module for managing TE links, and this may
   be particularly useful in figure
   1b below.

                             Network element
                        .............................
                        :            -------- the context of the MLN as LSPs in the lower
   layers are made available as TE links in the higher layer.

   The traffic engineering database provides a repository for all
   information about the existence and current status of TE links within
   a network. This information is typically flooded by the routing
   protocol operating within the network, and is used when LSP routes
   are computed. [TED-MIB] provides a way to inspect the TED to view the
   TE links at the different layers of the MLN.

   As observed in [MLN-REQ], although it would be possible to manage the
   MLN using only the existing MIB modules, a further MIB module could
   be produced to coordinate the management of separate network layers
   in order to construct a single MLN entity. Such a MIB module would
   effectively link together entries in the MIB modules already
   referenced.

3.1.5.2. OAM

   At the time of writing, the development of OAM tools for GMPLS
   networks is at an early stage. GMPLS OAM requirements are addressed
   in [GMPLS-OAM].

   In general, the lower layer network technologies contain their own
   technology-specific OAM processes (for example, SDH/SONET, Ethernet,
   and MPLS). In these cases, it is not necessary to develop additional
   OAM processes, but GMPLS procedures may be desirable to coordinate
   the operation and configuration of these OAM processes.
   [ETH-OAM] describes some early ideas for this function, but more work
   is required to generalize the technique to be applicable to all
   technologies and to MLN. In particular OAM function operating within
   a server layer must be controllable from the client layer, and client
   layer control plane mechanisms must map and enable OAM in the server
   layer.

   Where a GMPLS-controlled technology does not contain its own OAM
   procedures, this is usually because the technology cannot support
   in-band OAM (for example, WDM networks). In these cases, there is
   very little that a control plane can add to the OAM function since
   the presence of a control plane cannot make any difference to the
   physical characteristics of the data plane. However, the existing
   GMPLS protocol suite does provide a set of tools that can help to
   verify the data plane through control plane. These tools are equally
   applicable to network technologies that do contain their own OAM.

   - Route recording is available through the GMPLS signaling protocol
     [RFC3473] making it possible to check the route reported by the
     control plane against the expected route. This mechanism also
     includes the ability to record and report the interfaces and labels
     used for the LSP at each hop of its path.

   - The status of TE links is flooded by the GMPLS routing protocols
     [RFC4203] and [RFC4205] making it possible to detect changes in the
     available resources in the network as an LSP is set up.

   - The GMPLS signaling protocol [RFC3473] provides a technique to
     place an LSP into a "test" mode so that end-to-end characteristics
     (such as power levels) may be sampled and modified.

   - The Link Management Protocol [RFC4204] provides a mechanism for
     fault isolation on an LSP.

   - GMPLS signaling [RFC3473] provides a Notify message that can be
     used to report faults and issues across the network. The message
     includes scaling features to allow one message to report the
     failure of multiple LSPs.

   - Extensions to GMPLS signaling [RFC4783] enable alarm information to
     be collected and distributed along the path of an LSP for more easy
     coordination and correlation.

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:

   - Explicit Route Object (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 signaling procedures do not allow solving this
   ambiguous choice of SC that may be used along a given path.

   Hence an extension to GMPLS signaling 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 Adjustment Capacities

   In the MRN context, nodes supporting more than one switching
   capability on at least one interface are called Hybrid nodes ([MLN-
   REQ]). Conceptually, hybrid nodes can be viewed as containing at
   least two distinct switching elements interconnected by internal
   links which provide adjustment 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 adjustment capacities is required as it
   provides critical information when performing multi-region path
   computation.

   The term adjustment capacity refers to the property of a hybrid node
   to interconnect different switching capabilities it provides through
   its external interfaces [MLN-REQ]. This information allows path
   computation to select an end-to-end multi-region path that includes
   links of different switching capabilities that are joined by LSRs
   that can adapt the signal between the links.

   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 has two PSC and TDM ports (port1 and
   port2 respectively). It also has an 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 adjustment 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      |      :
                        :  +--<->---|#b      |      :
                        :  |         --------       :
                        :  |        ----------      :
              TDM       :  +--<->--|#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 adjustment. Hence the TDM-PSC adjustment
   capacity 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   |      :
                        :           |        |      :
                        :         --|#a      |      :
                        :        |  |   #b   |      :
                        :        |   --------       :
                        :        |       |          :
                        :        |  ----------      :
                        :    /|  | |    #c    |     :
                        :   | |--  |          |     :
              Link1 ========| |    | with Max LSP bandwidth = 622Mb
     - Unreserved bandwidth = 622Mb.

   TE-Link 2 (port 2):
     - ISCD #1 sub-TLV: TDM   |     :
                        :   | |----|#d        |     :
                        :    \|     ----------      :
                        :............................

                             Figure 1b. Hybrid 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 TDM-PSC adjustment
   capacity.

   However if for obvious scalability reasons link bundling is done then
   the adjustment capacity 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.

   Let's assume

   Thus current GMPLS routing can support the advertisement of the
   adjustment capacities 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 adjustment capacities 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
   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.

   Six areas for extensions of GMPLS protocols and procedures have been
   identified:

   - GMPLS signaling extension for the setup/deletion of the virtual
     TE-links;

   - GMPLS signaling extension for graceful TE-link deletion;

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

   - GMPLS routing extension for the advertisement of the adjustment
     capacities of hybrid nodes.

   - A MIB module for coordination of other MIB modules being operated
     in separate layers.

   - GMPLS signaling extensions for the control and configuration of
     technology-specific OAM processes.

4.1. Traceability of Requirements

   This section provides a brief cross-reference to the requirements set
   out in [MLN-REQ] so that it is possible to verify that all interfaces of the
   requirements listed in that document have been examined in this
   document.

   - Path computation mechanism should be able to compute paths and
     handle topologies consisting of any combination of (simplex) nodes
     ([MLN-REQ], Section 5.1).
     o Path computation mechanisms are STM16 (with VC4-16c capable beyond the scope of protocol
       specifications, and out of scope for this document.

   - A hybrid node should maintain resources on its internal links
     ([MLN-REQ], Section 5.2).
     o This is an implementation requirement and is beyond the scope of
       protocol specifications, and out of scope for this document.

   - Path computation mechanisms should be prepared to use the
     availability of termination/adjustment resources as Max LSP bandwidth). After, setting up several PSC a constraint in
     path computation ([MLN-REQ], Section 5.2).
     o Path computation mechanisms are beyond the scope of protocol
       specifications, and out of scope for this document.

   - The advertisement of a node's ability to terminate lower-region
     LSPs via port #a and setting up to forward traffic in the upper-region (adjustment
     capability) is required ([MLN-REQ], Section 5.2).
     o See Section 3.2.2 of this document.

   - The path computation mechanism should support the coexistence of
     upper-layer links directly connected to upper-layer switching
     elements, and terminating several TDM upper-layer links connected through internal links
     between upper-layer and lower-layer switching elements ([MLN-REQ],
     Section 5.2).
     o Path computation mechanisms are beyond the scope of protocol
       specifications, and out of scope for this document.

   - MRN/MLN routing mechanisms must be designed to scale well with an
     increase of any of the following:
     - Number of nodes
     - Number of TE-links (including FA-LSPs)
     - Number of LSPs via port #d
     - Number of regions and port
   #b, there is only 155 Mb capacities still available layers
     - Number of ISCDs per TE-link.
     ([MLN-REQ], Section 5.3).
     o See Section 3.1.4 of this document.

   - Design of the routing protocols must not prevent TE information
     filtering based on port #b.
   However ISCDs, ([MLN-REQ], Section 5.3).
     o All advertised information carries the ISCD and so a 622 Mb capacity remains on port #a receiving
       node may filter as required.

   - The path computation mechanism and VC4-5c capacity the signaling protocol should be
     able to operate on
   port #d.

   When computing partial TE information, ([MLN-REQ], Section
     5.3).
     o Path computation mechanisms are beyond the path scope of protocol
       specifications, and out of scope for a new VC4-4c TDM LSP, one must know, that this node cannot terminate document.

   - Protocol mechanisms must be provided to enable creation, deletion,
     and modification of LSPs triggered through operational actions,
     ([MLN-REQ], Section 5.4).
     o Such mechanisms are standard in GMPLS signaling [RFC3473].

   - Protocol mechanisms should be provided to enable similar functions
     triggered by adjacent layers, ([MLN-REQ], Section 5.4).

     o Such mechanisms are standard in GMPLS signaling [RFC3473].

   - Protocol mechanisms may be provided to enable adaptation to changes
     such as traffic demand, topology, and network failures. Routing
     robustness should be traded with adaptability of those changes,
     ([MLN-REQ], Section 5.4).
     o See section 3.1.1 of this LSP, as there is only 155Mb still
   available for TDM-PSC adjustment. Hence document.

   - Reconfiguration of the TDM-PSC adjustment
   capacity VNT must be advertised.

   With current GMPLS routing [RFC4202] this advertisement is as non-disruptive as possible
   if link bundling is not used
     and if two TE-links are advertised for
   link1:

   We would have must be under 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, control of policy configured by the operator,
    ([MLN-REQ], Section 5.5).
     o See Section 3.1.1.3 of this document

   - ISCD #2 sub-TLV: PSC with Max Parameters of a TE link in an upper should be inherited from the
     parameters of the lower-layer LSP bandwidth = 155 Mb, that provides the TE-link, based
     on polices configured by the operator, ([MLN-REQ], Section 5.6).
     o See Section 3.1.2 of this document.

   - Unreserved bandwidth (equivalent): 777 Mb. The ISCD 2 upper-layer signaling request may contain an ERO that includes
     only hops in TE-link 2 represents actually the TDM-PSC adjustment
   capacity.

   However if upper layer, ([MLN-REQ], Section 5.7).
     o Standard for obvious scalability reasons link bundling is done then
   the adjustment capacity 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, signaling [RFC3473]. See also Section 3.2.1.

   - Unreserved bandwidth (equivalent): 1399 Mb.

   With such TE-link advertisement The upper-layer signaling request may contain an element computing the path of a
   VC4-4c LSP cannot know that this LSP cannot be terminated on the
   node.

   Thus current ERO specifying the
     lower layer FA-LSP route, ([MLN-REQ], Section 5.7).
     o Standard for GMPLS routing can support signaling [RFC3473]. See also Section 3.2.1.

   - As part of the advertisement re-optimization of the
   adjustment capacities but this precludes performing link bundling and
   thus faces significant scalability limitations.

   Hence, GMPLS routing MLN, it must be extended possible to meet this requirement. This
   could rely on the advertisement
     reroute a lower-layer FA-LSP while keeping interface identifiers of
     the adjustment capacities as a new corresponding TE link attribute (that would complement the Interface Switching
   Capability Descriptor TE-link attribute).

   Note: Multiple ISCDs MAY be associated links unchanged and causing only minimal
     disruption to a single switching
   capability. This can be performed higher-layer traffic, ([MLN-REQ], Section 5.8.1).
     o See Section 3.1.1.3.

   - The solution must include measures to provide e.g. for TDM interfaces protect against network
     destabilization caused by 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 rapid setup and supporting VC-12 teardown of lower-
     layer LSPs as traffic demand varies near a threshold, ([MLN-REQ],
     Sections 5.8.1 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 5.8.2).
     o See Section 3.1.1.4.

   - Signaling of lower-layer LSPs should include a mechanism to VC-12 and rapidly
     advertise the Max LSP Bandwidth to
   VC-4. In as a TE link in the second case, upper layer, and to
     coordinate into which routing instances the Min TE link should be
     advertised, ([MLN-REQ], Section 5.8.1).
     o This is provided by [RFC4206] and enhanced by [HIER-BIS]. See
       also Section 3.1.1.2.

   - If an upper-layer LSP Bandwidth is set to VC-12 and up making use of a virtual TE-Link,
     the Max underlying LSP Bandwidth to VC-12, must immediately be signaled in the first ISCD sub-TLV; and the
   Min LSP Bandwidth is set lower layer,
     ([MLN-REQ], Section 5.8.2).
     o See Section 3.1.1.2.

   - The solution should provide operations to VC-4 and facilitate the build-up
     of virtual TE-links, taking into account the Max LSP Bandwidth to VC-4, forecast upper-layer
     traffic demand and available resource in the second ISCD sub-TLV. Hence, in lower-layer,
     ([MLN-REQ], Section 5.8.2).
     o See Section 3.1.1.2 of this document.

   - The GMPLS protocols should provide mechanisms for the first case, as long as coordination
     of data link verification in the

   Min LSP Bandwidth is set upper layer network where data
     links are lower layer LSPs, ([MLN-REQ], Section 5.9).
     o See Section 3.1.3 of this document.

   - Multi-layer protocol solutions should be manageable through MIB
     modules, ([MLN-REQ], Section 5.10).
     o See section 3.1.5.1.

   - Choices about how to VC-12 (and not VC-4) coordinate errors and in the second
   case, as long as alarms, and how to
     operate OAM across administrative and layer boundaries must be left
     open for the first ISCD sub-TLV is advertised there operator, ([MLN-REQ], Section 5.10).
     o This is
   sufficient capacity across that interface an implementation matter, subject to setup a VC-12 operational
       policies.

   - It must be possible to enable end-to-end OAM on an upper-layer LSP.

4. Evaluation Conclusion

   Most of
     This function appears to the required MLN/MRN functions will rely ingress LSP as normal LSP-based OAM
     [GMPLS-OAM], but at layer boundaries, depending on mechanisms and
   procedures that are out of the scope of technique
     used to span 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 lower layers, client-layer OAM operations may need
     to be defined, but these mapped to server-layer OAM operations ([MLN-REQ], Section
     5.10).
     o See Section 3.1.5.2.

   - Client layer control plane mechanisms are out of the scope of GMPLS protocols.

   Four areas for extensions of GMPLS protocols must map and procedures have been
   identified: enable OAM in
     the server layer, ([MLN-REQ], Section 5.10).
     o See Section 3.1.5.2.

   - GMPLS signaling extension OAM operation enabled for an LSP in a client layer must operate for
     that LSP along its entire length, ([MLN-REQ], Section 5.10).
     o See Section 3.1.5.2.

   - OAM function operating within a server layer must be controllable
     from the setup/deletion client layer. Such control should be subject to policy at
     the layer boundary, ([MLN-REQ], Section 5.10).
     o This is an implementation matter.

   - The status of a server layer LSP must be available to 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 client
     layer. This information should be configurable to be automatically
     notified to the advertisement of client layer at the adjustment
     capacities of hybrid nodes. layer boundary, and should be
     subject to policy, ([MLN-REQ], Section 5.10).
     o This is an implementation matter.

   - Implementations may use standardized techniques (such as MIB
     modules) to convey status information between layers.
     o This is an implementation matter.

5. Security Considerations

   [MLN-REQ] sets out the security requirements for operating a MLN or
   MRN. These requirements are, in general, no different from the
   security requirements for operating any GMPLS network. As such, the
   GMPLS protocols already provide adequate security features. An
   evaluation of the security features for GMPLS networks may be found
   in [MPLS-SEC], and where issues or further work is identified by that
   document, new security features or procedures for the GMPLS protocols
   will need to be developed.

   [MLN-REQ] also identifies that where the separate layers of a MLN/MRN
   network are operated as different administrative domains, additional
   security considerations may be given to the mechanisms for allowing
   inter-layer LSP setup. However, this document is explicitly limited
   to the case where all layers under GMPLS control are part of the same
   administrative domain.

   Lastly, as noted in [MLN-REQ], it is expected that solution documents
   will include a full analysis of the security issues that any protocol
   extensions introduce.

6. IANA Considerations

   This informational document makes no requests for IANA action.

7. Acknowledgments

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

   Thanks also to Question 14 of Study Group 15 of the ITU-T for their
   thoughtful review.

8. References

8.1. Normative References

    [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
    Switching (GMPLS) Signaling Functional Description", RFC
    3471, January 2003.

    [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", RFC4202, October 2005.

    [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-mln-reqs, work in progess.

8.2. Informative References

    [RFC3473] Berger, L., et al. "GMPLS Singlaling Signaling RSVP-TE
    extensions", RFC3473, January 2003.

    [RFC4203] K. Kompella, and Y. Rekhter, "OSPF Extensions in
    Support of Generalized Multi-Protocol Label
    Switching", RFC4203, Oct. 2005.

    [RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC
    4204, September 2005.

    [RFC4205] K. Kompella, and Y. Rekhter, "Intermediate System to
    Intermediate System (IS-IS) Extensions in Support of
    Multi-Protocol Label Switching (GMPLS)", RFC 4205,
    October 2005.

    [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with
    generalized MPLS TE", RFC4206, October 2005.

    [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic
    Engineering Link Management Information Base", RFC 4220,
    November 2005.

    [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based
    Architecture", RFC4655, August 2006.

    [RFC4802] Nadeau, T., Ed. and A. Farrel, A., "GMPLS TE MIB", RFC4802, Ed., "Generalized
    Multiprotocol Label Switching (GMPLS) Traffic
    Engineering Management Information Base", RFC 4802,
    February 2007.

    [RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized
    Multiprotocol Label Switching (GMPLS) Label Switching
    Router (LSR) Management Information Base", RFC 4803,
    February 2007.

    [RFC4783] L. Berger, Ed., "GMPLS - Communication of Alarm
    Information", RFC 4783, December 2006.

    [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
    support of End-to-End Generalized Multi-Protocol Label
    Switching (GMPLS)-based Recovery", RFC4872, May 2007.

    [RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized
    MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
    Calls", RFC 4974, August 2007.

    [ETH-OAM] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to
    Control Ethernet OAM", draft-takacs-ccamp-rsvp-te-eth-
    oam-ext, work in progress.

    [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and Farrel, A.,
    "OAM Requirements for Generalized Multi-Protocol Label Switching
    (GMPLS) Networks", draft-ietf-ccamp-gmpls-oam-requirements, work in
    progress.

    [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
    Engineering Network", draft-ietf-ccamp-mpls-graceful-
    shutdown, work in progress.

   [MLN-REQ]

    [HIER-BIS] Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
                Vigoureux, M., Brungard, D., "Requirements for GMPLS-
                based multi-region Rabbat, R., Ayyangar, A., Farrel, A., and multi-layer networks", draft-
                ietf-ccamp-gmpls-mln-reqs,
    Ali, Z., "Procedures for Dynamically Signaled
    Hierarchical Label Switched Paths", draft-ietf-ccamp-
    lsp-hierarchy-bis, work in progess. progress.

    [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS
    Networks draft-fang-mpls-gmpls-security-framework, work
    in progress.

    [PCE-INTER]  Oki, E., Le Roux , J-L., and Farrel, A., "Framework for
    PCE-Based Inter-Layer MPLS and GMPLS Traffic
    Engineering", draft-ietf-pce-inter-layer-frwk, work in
    progress.

    [TED-MIB] Miyazawa, M., Otani, T., Kunaki, K. and Nadeau, T.,
    "Traffic Engineering Database Management Information
    Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted-
    mib, work in progress.

9. Editors' Addresses: 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

10. Contributors' Addresses: 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
   Email: martin.vigoureux@alcatel-lucent.fr

11. 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, 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). (2008). 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.