doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc5339.txt b/doc/rfc/rfc5339.txt
new file mode 100644
index 0000000..6b8b31b
--- /dev/null
+++ b/doc/rfc/rfc5339.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                   JL. Le Roux, Ed.
+Request for Comments: 5339                                France Telecom
+Category: Informational                            D. Papadimitriou, Ed.
+                                                          Alcatel-Lucent
+                                                          September 2008
+
+
+                Evaluation of Existing GMPLS Protocols
+        against Multi-Layer and Multi-Region Networks (MLN/MRN)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document provides an evaluation of Generalized Multiprotocol
+   Label Switching (GMPLS) protocols and mechanisms against the
+   requirements for Multi-Layer Networks (MLNs) and Multi-Region
+   Networks (MRNs).  In addition, this document identifies areas where
+   additional protocol extensions or procedures are needed to satisfy
+   these requirements, and provides guidelines for potential extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 1]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+   2. MLN/MRN Requirements Overview ...................................4
+   3. Analysis ........................................................5
+      3.1. Aspects of Multi-Layer Networks ............................5
+           3.1.1. Support for Virtual Network Topology
+                  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 ..........................8
+                  3.1.1.4. Stability ..................................8
+           3.1.2. Support for FA-LSP Attribute Inheritance ............9
+           3.1.3. FA-LSP Connectivity Verification ....................9
+           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 .......................................11
+      3.2. Specific Aspects of Multi-Region Networks .................12
+           3.2.1. Support for Multi-Region Signaling .................12
+           3.2.2. Advertisement of Adjustment Capacities .............13
+   4. Evaluation Conclusion ..........................................16
+      4.1. Traceability of Requirements ..............................16
+   5. Security Considerations ........................................20
+   6. Acknowledgments ................................................20
+   7. References .....................................................21
+      7.1. Normative References ......................................21
+      7.2. Informative References ....................................21
+   8. Contributors' Addresses ........................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 2]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+1.  Introduction
+
+   Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
+   technologies: packet switching, layer-2 switching, TDM (Time Division
+   Multiplexing) 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 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.  [RFC5212] defines a Multi-Layer Network
+   (MLN) to be a Traffic Engineering (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.  [RFC5212] further 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 MLNs and MRNs, defined in [RFC5212].
+   From this evaluation, we identify several areas where additional
+   protocol extensions and modifications are required in order to meet
+   these requirements, and we provide guidelines for potential
+   extensions.
+
+   A summary of MLN/MRN requirements is provided in Section 2.  Then
+   Section 3 evaluates whether current GMPLS protocols and mechanisms
+   meet each of these 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.
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 3]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   This document uses terminologies defined in [RFC3945], [RFC4206], and
+   [RFC5212].
+
+1.1.  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 [RFC2119].
+
+2.  MLN/MRN Requirements Overview
+
+   Section 5 of [RFC5212] 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 [RFC5212] 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 Label Switched Path
+          (FA-LSP) setup and release (Section 5.8.1 of [RFC5212]);
+
+        - Support for virtual TE links (Section 5.8.2 of [RFC5212]);
+
+        - Minimization of traffic disruption during FA-LSP release
+          (Section 5.5 of [RFC5212]);
+
+        - Stability (Section 5.4 of [RFC5212]);
+
+   - Support for FA-LSP attribute inheritance (Section 5.6 of
+     [RFC5212]);
+
+   - Support for FA-LSP data plane connectivity verification (Section
+     5.9 of [RFC5212]);
+
+   - MLN Scalability (Section 5.3 of [RFC5212]);
+
+   - MLN Operations and Management (OAM) (Section 5.10 of [RFC5212]);
+
+   Here is the list of requirements that apply to MRN only:
+
+   - Support for Multi-Region signaling (Section 5.7 of [RFC5212]);
+
+   - Advertisement of the adjustment capacity (Section 5.2 of
+     [RFC5212]);
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 4]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+3.  Analysis
+
+3.1.  Aspects of Multi-Layer Networks
+
+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 [RFC5212].  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
+   performing inter-layer Traffic Engineering.
+
+3.1.1.1.  Control of FA-LSPs Setup/Release
+
+   In a Multi-Layer Network, FA-LSPs are created, modified, and 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 a 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 Path Computation according to TE topology, potentially taking
+     into account the old (existing) VNT in order to minimize changes.
+     The functional component in charge of VNT computation may be
+     distributed on network elements or may be performed on an external
+     element (such as a Path Computation Element (PCE), [RFC4655]).
+
+   - FA-LSP setup/release.
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 5]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   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 Label Switching Routers (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 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 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 signaling message) to make
+   use of a virtual TE link, the underlying FA-LSP is immediately
+   signaled and provisioned (provided there are available resources in
+   the lower layer) in the process known as triggered signaling.
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 6]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   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 that allows an end-to-end association between virtual TE
+     link end points with the purpose of exchanging 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 signaling does not allow setting up and releasing
+   virtual TE links.  Hence, GMPLS signaling must be extended to support
+   virtual TE links.
+
+   We can distinguish two options for setting up virtual TE links:
+
+   - The Soft FA approach 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 no longer be available for use by
+     other Soft FAs that have common links.  These Soft FA will be
+     dynamically released, and corresponding virtual TE links will be
+     deleted.  The Soft FA LSPs may be setup using procedures similar to
+     those described in [RFC4872] for setting up secondary LSPs.
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 7]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - The remote association approach simply consists of exchanging
+     virtual TE link 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
+     Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
+     Automatically Switched Optical Network (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 an 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 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, the 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
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 8]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   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 Attribute Inheritance
+
+   When an 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
+   Bidrectional Forwarding Detection (BFD); etc.) as for any other LSP.
+   Hence, this requirement is out of the scope of GMPLS protocols.
+
+   The GMPLS protocols should provide mechanisms for the coordination of
+   data link verification in the upper-layer network where data links
+   are lower-layer LSPs.
+
+      o GMPLS signaling allows an LSP to be put into 'test' mode
+        [RFC3473].
+      o The Link Management Protocol [RFC4204] is a targeted protocol
+        and can be 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 [RFC5212]), 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
+      - Number of regions and layers
+      - Number of Interface Switching Capability Descriptors (ISCDs) per
+        TE link.
+
+
+
+Le Roux & Papadimitriou      Informational                      [Page 9]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   GMPLS routing provides the necessary advertisement functions and is
+   based on IETF-designed IGPs.  These are known to scale relatively
+   well with the number of nodes and links.  Where there are multiple
+   regions or layers, there are two possibilities.
+
+      1.  If a single routing instance distributes information about
+         multiple network layers, the effect is no more than to increase
+         the number of nodes and links in the network.
+
+      2.  If the MLN is fully integrated (i.e., constructed from hybrid
+         nodes), there is an increase in the number of nodes and links
+         (as just mentioned), and also a potential increase in the
+         amount of ISCD information advertised per link.  This is a
+         relatively small amount of information (e.g., 36 bytes in OSPF
+         [RFC4203]) per switching type, and each interface is unlikely
+         to have more than two or three switching types.
+
+   The number of LSPs in a lower layer that are advertised as TE links
+   may impact the scaling of the routing protocol.  A full mesh of FA-
+   LSPs in the 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.
+
+   Since it requires the maintenance of n^2 RSVP-TE sessions (which may
+   be quite CPU- and memory-consuming), a full mesh of LSPs in the lower
+   layer may impact the scalability of GMPLS signaling.  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
+
+   [RFC5212] identifies various requirements for effective management
+   and operation of the MLN.  Some features already exist within the
+   GMPLS protocol set, some more are under development, and some
+   requirements are not currently addressed and will need new
+   development work in order to support them.
+
+3.1.5.1.  MIB Modules
+
+   MIB modules have been developed to model and control GMPLS switches
+   [RFC4803] and to control and report on the operation of the signaling
+   protocol [RFC4802].  These may be successfully used to manage the
+   operation of a single instance of the control plane protocols that
+   operate across multiple layers.
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 10]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   [RFC4220] provides a MIB module for managing TE links, and this may
+   be particularly useful in the context of the MLN because 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 [RFC5212], 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, an 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, Wavelength Division Multiplexing (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 the
+   control plane.  These tools are equally applicable to network
+   technologies that do contain their own OAM.
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 11]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - 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 of Multi-Region Networks
+
+3.2.1.  Support for Multi-Region Signaling
+
+   There are actually several cases where a transit node could choose
+   between multiple Switching Capabilities (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 an 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 the 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.
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 12]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+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
+   [RFC5212].  Conceptually, hybrid nodes can be viewed as containing at
+   least two distinct switching elements interconnected by internal
+   links that 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 [RFC5212].  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 a hybrid node.  The hybrid node
+   has two switching elements (matrices), which support 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
+   Port2; also, they can provide adjustment of PSC traffic that is
+   received/sent over the internal PSC interface (#b).  Two ways are
+   possible to set up PSC LSPs (Port1 or Port2).  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.
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 13]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   Port1 and Port2 can be grouped together thanks to internal Dense
+   Wavelength Division Multiplexing (DWDM), to result in a single
+   interface: Link1.  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, a capacity of only 155 Mb is still available on port #b.
+   However, a 622 Mb capacity remains on port #a, and VC4-5c capacity
+   remains 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 a 155 Mb
+   capacity 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 (Port1):
+     - ISCD sub-TLV: PSC with Max LSP bandwidth = 622 Mb
+     - Unreserved bandwidth = 622 Mb.
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 14]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   TE link 2 (Port2):
+     - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
+     - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
+     - Unreserved bandwidth (equivalent): 777 Mb.
+
+   The ISCD #2 in TE link 2 actually represents 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 (Port1 + Port2):
+     - 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 a 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
+   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 with a single switching
+   capability.  This can be performed to provide (e.g., for TDM
+   interfaces) the Min/Max LSP Bandwidth associated to each layer (or
+   set of layers) for that switching capability.  For example, an
+   interface associated to TDM switching capability and supporting VC-12
+   and VC-4 switching can be associated to 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.
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 15]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+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 [RFC5212] so that it is possible to verify that all 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
+     ([RFC5212], Section 5.1).
+     o Path computation mechanisms are beyond the scope of protocol
+     specifications, and out of scope for this document.
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 16]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - A hybrid node should maintain resources on its internal links
+     ([RFC5212], Section 5.2).
+     o This is an implementation requirement and is beyond the scope of
+     protocol specifications, and it is out of scope for this document.
+
+   - Path computation mechanisms should be prepared to use the
+     availability of termination/adjustment resources as a constraint in
+     path computation ([RFC5212], 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 and to forward traffic in the upper-region (adjustment
+     capability) is required ([RFC5212], 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 upper-layer links connected through internal links
+     between upper-layer and lower-layer switching elements ([RFC5212],
+     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
+     - Number of regions and layers
+     - Number of ISCDs per TE link.
+     ([RFC5212], 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 ISCDs ([RFC5212], Section 5.3).
+     o All advertised information carries the ISCD, and so a receiving
+     node may filter as required.
+
+   - The path computation mechanism and the signaling protocol should be
+     able to operate on partial TE information, ([RFC5212], Section
+     5.3).
+     o Path computation mechanisms are beyond the scope of protocol
+     specifications, and out of scope for this document.
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 17]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - Protocol mechanisms must be provided to enable creation, deletion,
+     and modification of LSPs triggered through operational actions
+     ([RFC5212], 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 ([RFC5212], 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
+     ([RFC5212], Section 5.4).
+     o See Section 3.1.1 of this document.
+
+   - Reconfiguration of the VNT must be as non-disruptive as possible
+     and must be under the control of policy configured by the operator
+     ([RFC5212], Section 5.5).
+     o See Section 3.1.1.3 of this document
+
+   - Parameters of a TE link in an upper layer should be inherited from
+     the parameters of the lower-layer LSP that provides the TE link,
+     based on polices configured by the operator ([RFC5212], Section
+     5.6).
+     o See Section 3.1.2 of this document.
+
+   - The upper-layer signaling request may contain an ERO that includes
+     only hops in the upper layer ([RFC5212], Section 5.7).
+     o Standard for GMPLS signaling [RFC3473].  See also Section 3.2.1.
+
+   - The upper-layer signaling request may contain an ERO specifying the
+     lower layer FA-LSP route ([RFC5212], Section 5.7).
+     o Standard for GMPLS signaling [RFC3473].  See also Section 3.2.1.
+
+   - As part of the re-optimization of the MLN, it must be possible to
+     reroute a lower-layer FA-LSP while keeping interface identifiers of
+     the corresponding TE links unchanged and causing only minimal
+     disruption to higher-layer traffic ([RFC5212], Section 5.8.1).
+     o See Section 3.1.1.3.
+
+   - The solution must include measures to protect against network
+     destabilization caused by the rapid setup and tear-down of lower-
+     layer LSPs, as traffic demand varies near a threshold ([RFC5212],
+     Sections 5.8.1 and 5.8.2).
+     o See Section 3.1.1.4.
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 18]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - Signaling of lower-layer LSPs should include a mechanism to rapidly
+     advertise the LSP as a TE link in the upper layer, and to
+     coordinate into which routing instances the TE link should be
+     advertised ([RFC5212], 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 is set up making use of a virtual TE link,
+     the underlying LSP must immediately be signaled in the lower layer
+     ([RFC5212], Section 5.8.2).
+     o See Section 3.1.1.2.
+
+   - The solution should provide operations to facilitate the build-up
+     of virtual TE links, taking into account the forecast upper-layer
+     traffic demand, and available resource in the lower layer
+     ([RFC5212], Section 5.8.2).
+     o See Section 3.1.1.2 of this document.
+
+   - The GMPLS protocols should provide mechanisms for the coordination
+     of data link verification in the upper-layer network where data
+     links are lower layer LSPs ([RFC5212], Section 5.9).
+     o See Section 3.1.3 of this document.
+
+   - Multi-layer protocol solutions should be manageable through MIB
+     modules ([RFC5212], Section 5.10).
+     o See Section 3.1.5.1.
+
+   - Choices about how to coordinate errors and alarms, and how to
+     operate OAM across administrative and layer boundaries must be left
+     open for the operator ([RFC5212], Section 5.10).
+     o This is an implementation matter, subject to operational
+     policies.
+
+   - It must be possible to enable end-to-end OAM on an upper-layer LSP.
+     This function appears to the ingress LSP as normal LSP-based OAM
+     [GMPLS-OAM], but at layer boundaries, depending on the technique
+     used to span the lower layers, client-layer OAM operations may need
+     to be mapped to server-layer OAM operations ([RFC5212], Section
+     5.10).
+     o See Section 3.1.5.2.
+
+   - Client-layer control plane mechanisms must map and enable OAM in
+     the server layer ([RFC5212], Section 5.10).
+     o See Section 3.1.5.2.
+
+   - OAM operation enabled for an LSP in a client layer must operate for
+     that LSP along its entire length ([RFC5212], Section 5.10).
+     o See Section 3.1.5.2.
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 19]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   - OAM function operating within a server layer must be controllable
+     from the client layer.  Such control should be subject to policy at
+     the layer boundary ([RFC5212], Section 5.10).
+     o This is an implementation matter.
+
+   - The status of a server layer LSP must be available to the client
+     layer.  This information should be configurable to be automatically
+     notified to the client layer at the layer boundary, and should be
+     subject to policy ([RFC5212], 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
+
+   [RFC5212] 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.
+
+   [RFC5212] also identifies that where the separate layers of a MLN/MRN
+   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 [RFC5212], it is expected that solution documents
+   will include a full analysis of the security issues that any protocol
+   extensions introduce.
+
+6.  Acknowledgments
+
+   We would like to thank Julien Meuric, Igor 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.
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 20]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3471]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Functional Description", RFC
+               3471, January 2003.
+
+   [RFC3945]   Mannie, E., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+   [RFC4202]   Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+               Extensions in Support of Generalized Multi-Protocol Label
+               Switching (GMPLS)", RFC 4202, October 2005.
+
+   [RFC5212]   Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
+               M., and D. Brungard, "Requirements for GMPLS-Based
+               Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC
+               5212, July 2008.
+
+7.2.  Informative References
+
+   [RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Resource ReserVation
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+   [RFC4203]   Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
+               in Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 4203, October 2005.
+
+   [RFC4204]   Lang, J., Ed., "Link Management Protocol (LMP)", RFC
+               4204, October 2005.
+
+   [RFC4205]   Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
+               System to Intermediate System (IS-IS) Extensions in
+               Support of Generalized Multi-Protocol Label Switching
+               (GMPLS)", RFC 4205, October 2005.
+
+   [RFC4206]   Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+               Hierarchy with Generalized Multi-Protocol Label Switching
+               (GMPLS) Traffic Engineering (TE)", RFC 4206, October
+               2005.
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 21]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   [RFC4220]   Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
+               Link Management Information Base", RFC 4220, November
+               2005.
+
+   [RFC4655]   Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+               Computation Element (PCE)-Based Architecture", RFC 4655,
+               August 2006.
+
+   [RFC4783]   Berger, L., Ed., "GMPLS - Communication of Alarm
+               Information", RFC 4783, December 2006.
+
+   [RFC4802]   Nadeau, T., Ed., and A. Farrel, 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.
+
+   [RFC4872]   Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
+               Ed., "RSVP-TE Extensions in Support of End-to-End
+               Generalized Multi-Protocol Label Switching (GMPLS)
+               Recovery", RFC 4872, May 2007.
+
+   [RFC4974]   Papadimitriou, D. and A. Farrel, "Generalized MPLS
+               (GMPLS) RSVP-TE Signaling Extensions in Support of
+               Calls", RFC 4974, August 2007.
+
+   [ETH-OAM]   Takacs, A., Gero, B., and D. Mohan, "GMPLS RSVP-TE
+               Extensions to Control Ethernet OAM", Work in Progress,
+               July 2008.
+
+   [GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM
+               Requirements for Generalized Multi-Protocol Label
+               Switching (GMPLS) Networks", Work in Progress, October
+               2007.
+
+   [GR-SHUT]   Ali, Z., Zamfir, A., and J. Newton, "Graceful Shutdown in
+               MPLS and Generalized MPLS Traffic Engineering Networks",
+               Work in Progress, July 2008.
+
+   [HIER-BIS]  Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A., and
+               Z. Ali, "Procedures for Dynamically Signaled Hierarchical
+               Label Switched Paths", Work in Progress, February 2008.
+
+   [MPLS-SEC]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+               Networks", Work in Progress, July 2008.
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 22]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+   [PCE-INTER] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for
+               PCE-Based Inter-Layer MPLS and GMPLS Traffic
+               Engineering", Work in Progress, June 2008.
+
+   [TED-MIB]   Miyazawa, M., Otani, T., Nadeau, T., and K. Kunaki,
+               "Traffic Engineering Database Management Information Base
+               in support of MPLS-TE/GMPLS", Work in Progress, July
+               2008.
+
+8.  Contributors' Addresses
+
+   Deborah Brungard
+   AT&T
+   Rm. D1-3C22 - 200 S. Laurel Ave.
+   Middletown, NJ, 07748 USA
+   EMail: 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 23]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+Editors' Addresses
+
+   Jean-Louis Le Roux
+   France Telecom
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex, France
+   EMail: jeanlouis.leroux@orange-ftgroup.com
+
+
+   Dimitri Papadimitriou
+   Alcatel-Lucent
+   Francis Wellensplein 1,
+   B-2018 Antwerpen, Belgium
+   EMail: dimitri.papadimitriou@alcatel-lucent.be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 24]
+
+RFC 5339        Evaluation of GMPLS against MLN/MRN Reqs  September 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux & Papadimitriou      Informational                     [Page 25]
+