doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5212.txt b/doc/rfc/rfc5212.txt
new file mode 100644
index 0000000..d502485
--- /dev/null
+++ b/doc/rfc/rfc5212.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                        K. Shiomoto
+Request for Comments: 5212                                           NTT
+Category: Informational                                 D. Papadimitriou
+                                                          Alcatel-Lucent
+                                                             JL. Le Roux
+                                                          France Telecom
+                                                            M. Vigoureux
+                                                          Alcatel-Lucent
+                                                             D. Brungard
+                                                                    AT&T
+                                                               July 2008
+
+
+                     Requirements for GMPLS-Based
+            Multi-Region and Multi-Layer Networks (MRN/MLN)
+
+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
+
+   Most of the initial efforts to utilize Generalized MPLS (GMPLS) have
+   been related to environments hosting devices with a single switching
+   capability.  The complexity raised by the control of such data planes
+   is similar to that seen in classical IP/MPLS networks.  By extending
+   MPLS to support multiple switching technologies, GMPLS provides a
+   comprehensive framework for the control of a multi-layered network of
+   either a single switching technology or multiple switching
+   technologies.
+
+   In GMPLS, a switching technology domain defines a region, and a
+   network of multiple switching types is referred to in this document
+   as a multi-region network (MRN).  When referring in general to a
+   layered network, which may consist of either single or multiple
+   regions, this document uses the term multi-layer network (MLN).  This
+   document defines a framework for GMPLS based multi-region / multi-
+   layer networks and lists a set of functional requirements.
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 1]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Scope ......................................................4
+   2. Conventions Used in This Document ...............................5
+      2.1. List of Acronyms ...........................................6
+   3. Positioning .....................................................6
+      3.1. Data Plane Layers and Control Plane Regions ................6
+      3.2. Service Layer Networks .....................................7
+      3.3. Vertical and Horizontal Interaction and Integration ........8
+      3.4. Motivation .................................................9
+   4. Key Concepts of GMPLS-Based MLNs and MRNs ......................10
+      4.1. Interface Switching Capability ............................10
+      4.2. Multiple Interface Switching Capabilities .................11
+           4.2.1. Networks with Multi-Switching-Type-Capable
+                  Hybrid Nodes .......................................12
+      4.3. Integrated Traffic Engineering (TE) and Resource Control ..12
+           4.3.1. Triggered Signaling ................................13
+           4.3.2. FA-LSPs ............................................13
+           4.3.3. Virtual Network Topology (VNT) .....................14
+   5. Requirements ...................................................15
+      5.1. Handling Single-Switching and
+           Multi-Switching-Type-Capable Nodes ........................15
+      5.2. Advertisement of the Available Adjustment Resources .......15
+      5.3. Scalability ...............................................16
+      5.4. Stability .................................................17
+      5.5. Disruption Minimization ...................................17
+      5.6. LSP Attribute Inheritance .................................17
+      5.7. Computing Paths with and without Nested Signaling .........18
+      5.8. LSP Resource Utilization ..................................19
+           5.8.1. FA-LSP Release and Setup ...........................19
+           5.8.2. Virtual TE Links ...................................20
+      5.9. Verification of the LSPs ..................................21
+      5.10. Management ...............................................22
+   6. Security Considerations ........................................24
+   7. Acknowledgements ...............................................24
+   8. References .....................................................25
+      8.1. Normative References ......................................25
+      8.2. Informative References ....................................25
+   9. Contributors' Addresses ........................................26
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 2]
+
+RFC 5212                  MRN/MLN Requirements                 July 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
+   layer describes a data plane switching granularity level (e.g., VC4,
+   VC-12).  A data plane layer is associated with a region in the
+   control plane (e.g., VC4 is associated with TDM, MPLS is associated
+   with PSC).  However, more than one data plane layer can be associated
+   with the same region (e.g., both VC4 and VC12 are associated with
+   TDM).  Thus, a control plane region, identified by its switching type
+   value (e.g., TDM), can be sub-divided into smaller-granularity
+   component networks based on "data plane switching layers".  The
+   Interface Switching Capability Descriptor (ISCD) [RFC4202],
+   identifying the interface switching capability (ISC), the encoding
+   type, and the switching bandwidth granularity, enables the
+   characterization of the associated layers.
+
+   In this document, we define 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.  We further define 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.
+
+   MLNs can be further categorized according to the distribution of the
+   ISCs among the Label Switching Routers (LSRs):
+
+   - Each LSR may support just one ISC.
+     Such LSRs are known as single-switching-type-capable LSRs.  The MLN
+     may comprise a set of single-switching-type-capable LSRs some of
+     which support different ISCs.
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 3]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   - Each LSR may support more than one ISC at the same time.
+     Such LSRs are known as multi-switching-type-capable LSRs, and can
+     be further classified as either "simplex" or "hybrid" nodes as
+     defined in Section 4.2.
+
+   - The MLN may be constructed from any combination of single-
+     switching-type-capable LSRs and multi-switching-type-capable LSRs.
+
+   Since GMPLS provides a comprehensive framework for the control of
+   different switching capabilities, a single GMPLS instance may be used
+   to control the MLN/MRN.  This enables rapid service provisioning and
+   efficient traffic engineering across all switching capabilities.  In
+   such networks, TE links are consolidated into a single Traffic
+   Engineering Database (TED).  Since this TED contains the information
+   relative to all the different regions and layers existing in the
+   network, a path across multiple regions or layers can be computed
+   using this TED.  Thus, optimization of network resources can be
+   achieved across the whole MLN/MRN.
+
+   Consider, for example, a MRN consisting of packet-switch-capable
+   routers and TDM cross-connects.  Assume that a packet Label Switched
+   Path (LSP) is routed between source and destination packet-switch-
+   capable routers, and that the LSP can be routed across the PSC region
+   (i.e., utilizing only resources of the packet region topology).  If
+   the performance objective for the packet LSP is not satisfied, new TE
+   links may be created between the packet-switch-capable routers across
+   the TDM-region (for example, VC-12 links) and the LSP can be routed
+   over those TE links.  Furthermore, even if the LSP can be
+   successfully established across the PSC-region, TDM hierarchical LSPs
+   (across the TDM region between the packet-switch capable routers) may
+   be established and used if doing so is necessary to meet the
+   operator's objectives for network resource availability (e.g., link
+   bandwidth).  The same considerations hold when VC4 LSPs are
+   provisioned to provide extra flexibility for the VC12 and/or VC11
+   layers in an MLN.
+
+   Sections 3 and 4 of this document provide further background
+   information of the concepts and motivation behind multi-region and
+   multi-layer networks.  Section 5 presents detailed requirements for
+   protocols used to implement such networks.
+
+1.1.  Scope
+
+   Early sections of this document describe the motivations and
+   reasoning that require the development and deployment of MRN/MLN.
+   Later sections of this document set out the required features that
+   the GMPLS control plane must offer to support MRN/MLN.  There is no
+   intention to specify solution-specific and/or protocol elements in
+
+
+
+Shiomoto, et al.             Informational                      [Page 4]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   this document.  The applicability of existing GMPLS protocols and any
+   protocol extensions to the MRN/MLN is addressed in separate documents
+   [MRN-EVAL].
+
+   This document covers the elements of a single GMPLS control plane
+   instance controlling multiple layers within a given TE domain.  A
+   control plane instance can serve one, two, or more layers.  Other
+   possible approaches such as having multiple control plane instances
+   serving disjoint sets of layers are outside the scope of this
+   document.  It is most probable that such a MLN or MRN would be
+   operated by a single service provider, but this document does not
+   exclude the possibility of two layers (or regions) being under
+   different administrative control (for example, by different Service
+   Providers that share a single control plane instance) where the
+   administrative domains are prepared to share a limited amount of
+   information.
+
+   For such a TE domain to interoperate with edge nodes/domains
+   supporting non-GMPLS interfaces (such as those defined by other
+   standards development organizations (SDOs)), an interworking function
+   may be needed.  Location and specification of this function are
+   outside the scope of this document (because interworking aspects are
+   strictly under the responsibility of the interworking function).
+
+   This document assumes that the interconnection of adjacent MRN/MLN TE
+   domains makes use of [RFC4726] when their edges also support inter-
+   domain GMPLS RSVP-TE extensions.
+
+2.  Conventions Used in This Document
+
+   Although this is not a protocol specification, the key words "MUST",
+   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED",  "MAY", and "OPTIONAL" are used in this document to
+   highlight requirements, and are to be interpreted as described in RFC
+   2119 [RFC2119].
+
+   In the context of this document, an end-to-end LSP is defined as an
+   LSP that starts in some client layer, ends in the same layer, and may
+   cross one or more lower layers.  In terms of switching capabilities,
+   this means that if the outgoing interface on the head-end LSR has
+   interface switching capability X, then the incoming interface on the
+   tail-end LSR also has switching capability X.  Further, for any
+   interface traversed by the LSP at any intermediate LSR, the switching
+   capability of that interface, Y, is such that Y >= X.
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 5]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+2.1.  List of Acronyms
+
+   ERO: Explicit Route Object
+   FA: Forwarding Adjacency
+   FA-LSP: Forwarding Adjacency Label Switched Path
+   FSC: Fiber Switching Capable
+   ISC: Interface Switching Capability
+   ISCD: Interface Switching Capability Descriptor
+   L2SC: Layer-2 Switching Capable
+   LSC: Lambda Switching Capable
+   LSP: Label Switched Path
+   LSR: Label Switching Router
+   MLN: Multi-Layer Network
+   MRN: Multi-Region Network
+   PSC: Packet Switching Capable
+   SRLG: Shared Risk Link Group
+   TDM: Time-Division Multiplexing
+   TE: Traffic Engineering
+   TED: Traffic Engineering Database
+   VNT: Virtual Network Topology
+
+3.  Positioning
+
+   A multi-region network (MRN) is always a multi-layer network (MLN)
+   since the network devices on region boundaries bring together
+   different ISCs.  A MLN, however, is not necessarily a MRN since
+   multiple layers could be fully contained within a single region.  For
+   example, VC12, VC4, and VC4-4c are different layers of the TDM
+   region.
+
+3.1.  Data Plane Layers and Control Plane Regions
+
+   A data plane layer is a collection of network resources capable of
+   terminating and/or switching data traffic of a particular format
+   [RFC4397].  These resources can be used for establishing LSPs for
+   traffic delivery.  For example, VC-11 and VC4-64c represent two
+   different layers.
+
+   From the control plane viewpoint, an LSP region is defined as a set
+   of one or more data plane layers that share the same type of
+   switching technology, that is, the same switching type.  For example,
+   VC-11, VC-4, and VC-4-7v layers are part of the same TDM region.  The
+   regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC.
+   Hence, an LSP region is a technology domain (identified by the ISC
+   type) for which data plane resources (i.e., data links) are
+   represented into the control plane as an aggregate of TE information
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 6]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   associated with a set of links (i.e., TE links).  For example, VC-11
+   and VC4-64c capable TE links are part of the same TDM region.
+   Multiple layers can thus exist in a single region network.
+
+   Note also that the region may produce a distinction within the
+   control plane.  Layers of the same region share the same switching
+   technology and, therefore, use the same set of technology-specific
+   signaling objects and technology-specific value setting of TE link
+   attributes within the control plane, but layers from different
+   regions may use different technology-specific objects and TE
+   attribute values.  This means that it may not be possible to simply
+   forward the signaling message between LSRs that host different
+   switching technologies.  This is due to changes in some of the
+   signaling objects (for example, the traffic parameters) when crossing
+   a region boundary even if a single control plane instance is used to
+   manage the whole MRN.  We may solve this issue by using triggered
+   signaling (see Section 4.3.1).
+
+3.2.  Service Layer Networks
+
+   A service provider's network may be divided into different service
+   layers.  The customer's network is considered from the provider's
+   perspective as the highest service layer.  It interfaces to the
+   highest service layer of the service provider's network.
+   Connectivity across the highest service layer of the service
+   provider's network may be provided with support from successively
+   lower service layers.  Service layers are realized via a hierarchy of
+   network layers located generally in several regions and commonly
+   arranged according to the switching capabilities of network devices.
+
+   For instance, some customers purchase Layer-1 (i.e., transport)
+   services from the service provider, some Layer 2 (e.g., ATM), while
+   others purchase Layer-3 (IP/MPLS) services.  The service provider
+   realizes the services by a stack of network layers located within one
+   or more network regions.  The network layers are commonly arranged
+   according to the switching capabilities of the devices in the
+   networks.  Thus, a customer network may be provided on top of the
+   GMPLS-based multi-region/multi-layer network.  For example, a Layer-1
+   service (realized via the network layers of TDM, and/or LSC, and/or
+   FSC regions) may support a Layer-2 network (realized via ATM Virtual
+   Path / Virtual Circuit (VP/VC)), which may itself support a Layer-3
+   network (IP/MPLS region).  The supported data plane relationship is a
+   data plane client-server relationship where the lower layer provides
+   a service for the higher layer using the data links realized in the
+   lower layer.
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 7]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   Services provided by a GMPLS-based multi-region/multi-layer network
+   are referred to as "multi-region/multi-layer network services".  For
+   example, legacy IP and IP/MPLS networks can be supported on top of
+   multi-region/multi-layer networks.  It has to be emphasized that
+   delivery of such diverse services is a strong motivator for the
+   deployment of multi-region/multi-layer networks.
+
+   A customer network may be provided on top of a server GMPLS-based
+   MRN/MLN which is operated by a service provider.  For example, a pure
+   IP and/or an IP/MPLS network can be provided on top of GMPLS-based
+   packet-over-optical networks [RFC5146].  The relationship between the
+   networks is a client/server relationship and, such services are
+   referred to as "MRN/MLN services".  In this case, the customer
+   network may form part of the MRN/MLN or may be partially separated,
+   for example, to maintain separate routing information but retain
+   common signaling.
+
+3.3.  Vertical and Horizontal Interaction and Integration
+
+   Vertical interaction is defined as the collaborative mechanisms
+   within a network element that is capable of supporting more than one
+   layer or region and of realizing the client/server relationships
+   between the layers or regions.  Protocol exchanges between two
+   network controllers managing different regions or layers are also a
+   vertical interaction.  Integration of these interactions as part of
+   the control plane is referred to as vertical integration.  Thus, this
+   refers to the collaborative mechanisms within a single control plane
+   instance driving multiple network layers that are part of the same
+   region or not.  Such a concept is useful in order to construct a
+   framework that facilitates efficient network resource usage and rapid
+   service provisioning in carrier networks that are based on multiple
+   layers, switching technologies, or ISCs.
+
+   Horizontal interaction is defined as the protocol exchange between
+   network controllers that manage transport nodes within a given layer
+   or region.  For instance, the control plane interaction between two
+   TDM network elements switching at OC-48 is an example of horizontal
+   interaction.  GMPLS protocol operations handle horizontal
+   interactions within the same routing area.  The case where the
+   interaction takes place across a domain boundary, such as between two
+   routing areas within the same network layer, is evaluated as part of
+   the inter-domain work [RFC4726], and is referred to as horizontal
+   integration.  Thus, horizontal integration refers to the
+   collaborative mechanisms between network partitions and/or
+   administrative divisions such as routing areas or autonomous systems.
+
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 8]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   This distinction needs further clarification when administrative
+   domains match layer/region boundaries.  Horizontal interaction is
+   extended to cover such cases.  For example, the collaborative
+   mechanisms in place between two LSC areas relate to horizontal
+   integration.  On the other hand, the collaborative mechanisms in
+   place between a PSC (e.g., IP/MPLS) domain and a separate TDM capable
+   (e.g., VC4 Synchronous Digital Hierarchy (SDH)) domain over which it
+   operates are part of the horizontal integration, while it can also be
+   seen as a first step towards vertical integration.
+
+3.4.  Motivation
+
+   The applicability of GMPLS to multiple switching technologies
+   provides a unified control and management approach for both LSP
+   provisioning and recovery.  Indeed, one of the main motivations for
+   unifying the capabilities and operations of the GMPLS control plane
+   is the desire to support multi-LSP-region [RFC4206] routing and TE
+   capabilities.  For instance, this enables effective network resource
+   utilization of both the Packet/Layer2 LSP regions and the TDM or
+   Lambda LSP regions in high-capacity networks.
+
+   The rationales for GMPLS-controlled multi-layer/multi-region networks
+   are summarized below:
+
+   - The maintenance of multiple instances of the control plane on
+     devices hosting more than one switching capability not only
+     increases the complexity of the interactions between control plane
+     instances, but also increases the total amount of processing each
+     individual control plane instance must handle.
+
+   - The unification of the addressing spaces helps in avoiding multiple
+     identifiers for the same object (a link, for instance, or more
+     generally, any network resource).  On the other hand such
+     aggregation does not impact the separation between the control
+     plane and the data plane.
+
+   - By maintaining a single routing protocol instance and a single TE
+     database per LSR, a unified control plane model removes the
+     requirement to maintain a dedicated routing topology per layer and
+     therefore does not mandate a full mesh of routing adjacencies as is
+     the case with overlaid control planes.
+
+   - The collaboration between technology layers where the control
+     channel is associated with the data channel (e.g., packet/framed
+     data planes) and technology layers where the control channel is not
+     directly associated with the data channel (SONET/SDH, G.709, etc.)
+
+
+
+
+
+Shiomoto, et al.             Informational                      [Page 9]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+     is facilitated by the capability within GMPLS to associate in-band
+     control plane signaling to the IP terminating interfaces of the
+     control plane.
+
+   - Resource management and policies to be applied at the edges of such
+     an MRN/MLN are made more simple (fewer control-to-management
+     interactions) and more scalable (through the use of aggregated
+     information).
+
+   - Multi-region/multi-layer traffic engineering is facilitated as TE
+     links from distinct regions/layers are stored within the same TE
+     Database.
+
+4.  Key Concepts of GMPLS-Based MLNs and MRNs
+
+   A network comprising transport nodes with multiple data plane layers
+   of either the same ISC or different ISCs, controlled by a single
+   GMPLS control plane instance, is called a multi-layer network (MLN).
+   A subset of MLNs consists of networks supporting LSPs of different
+   switching technologies (ISCs).  A network supporting more than one
+   switching technology is called a multi-region network (MRN).
+
+4.1.  Interface Switching Capability
+
+   The Interface Switching Capability (ISC) is introduced in GMPLS to
+   support various kinds of switching technology in a unified way
+   [RFC4202].  An ISC is identified via a switching type.
+
+   A switching type (also referred to as the switching capability type)
+   describes the ability of a node to forward data of a particular data
+   plane technology, and uniquely identifies a network region.  The
+   following ISC types (and, hence, regions) are defined:  PSC, L2SC,
+   TDM capable, LSC, and FSC.  Each end of a data link (more precisely,
+   each interface connecting a data link to a node) in a GMPLS network
+   is associated with an ISC.
+
+   The ISC value is advertised as a part of the Interface Switching
+   Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end
+   associated with a particular link interface [RFC4202].  Apart from
+   the ISC, the ISCD contains information including the encoding type,
+   the bandwidth granularity, and the unreserved bandwidth on each of
+   eight priorities at which LSPs can be established.  The ISCD does not
+   "identify" network layers, it uniquely characterizes information
+   associated to one or more network layers.
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 10]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   TE link end advertisements may contain multiple ISCDs.  This can be
+   interpreted as advertising a multi-layer (or multi-switching-
+   capable) TE link end.  That is, the TE link end (and therefore the TE
+   link) is present in multiple layers.
+
+4.2.  Multiple Interface Switching Capabilities
+
+   In an MLN, network elements may be single-switching-type-capable or
+   multi-switching-type-capable nodes.  Single-switching-type-capable
+   nodes advertise the same ISC value as part of their ISCD sub-TLV(s)
+   to describe the termination capabilities of each of their TE link(s).
+   This case is described in [RFC4202].
+
+   Multi-switching-type-capable LSRs are classified as "simplex" or
+   "hybrid" nodes.  Simplex and hybrid nodes are categorized according
+   to the way they advertise these multiple ISCs:
+
+   - A simplex node can terminate data links with different switching
+     capabilities where each data link is connected to the node by a
+     separate link interface.  So, it advertises several TE links each
+     with a single ISC value carried in its ISCD sub-TLV (following the
+     rules defined in [RFC4206]).  An example is an LSR with PSC and TDM
+     links each of which is connected to the LSR via a separate
+     interface.
+
+   - A hybrid node can terminate data links with different switching
+     capabilities where the data links are connected to the node by the
+     same interface.  So, it advertises a single TE link containing more
+     than one ISCD each with a different ISC value.  For example, a node
+     may terminate PSC and TDM data links and interconnect those
+     external data links via internal links.  The external interfaces
+     connected to the node have both PSC and TDM capabilities.
+
+   Additionally, TE link advertisements issued by a simplex or a hybrid
+   node may need to provide information about the node's internal
+   adjustment capabilities between the switching technologies supported.
+   The term "adjustment" refers to the property of a hybrid node to
+   interconnect the different switching capabilities that it provides
+   through its external interfaces.  The information about the
+   adjustment capabilities of the nodes in the network allows the path
+   computation process to select an end-to-end multi-layer or multi-
+   region path that includes links with different switching capabilities
+   joined by LSRs that can adapt (i.e., adjust) the signal between the
+   links.
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 11]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+4.2.1.  Networks with Multi-Switching-Type-Capable Hybrid Nodes
+
+   This type of network contains at least one hybrid node, zero or more
+   simplex nodes, and a set of single-switching-type-capable nodes.
+
+   Figure 1 shows an example hybrid node.  The hybrid node has two
+   switching elements (matrices), which support, for instance, TDM and
+   PSC switching, respectively.  The node terminates a PSC and a TDM
+   link (Link1 and Link2, 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, say,
+   Link2 and provide adjustment for PSC traffic received/sent over the
+   PSC interface (#b).  This situation is modeled in GMPLS by connecting
+   the local end of Link2 to the TDM switching element via an additional
+   interface realizing the termination/adjustment function.  There are
+   two possible ways to set up PSC LSPs through the hybrid node.
+   Available resource advertisement (i.e., Unreserved and Min/Max LSP
+   Bandwidth) should cover both of these methods.
+
+                         .............................
+                         : Network element           :
+                         :            --------       :
+                         :           |  PSC   |      :
+             Link1 -------------<->--|#a      |      :
+                         :           |        |      :
+                         :  +--<->---|#b      |      :
+                         :  |         --------       :
+                         :  |        ----------      :
+             TDM         :  +--<->--|#c  TDM   |     :
+              +PSC       :          |          |     :
+             Link2 ------------<->--|#d        |     :
+                         :           ----------      :
+                         :............................
+
+                               Figure 1.  Hybrid node.
+
+4.3.  Integrated Traffic Engineering (TE) and Resource Control
+
+   In GMPLS-based multi-region/multi-layer networks, TE links may be
+   consolidated into a single Traffic Engineering Database (TED) for use
+   by the single control plane instance.  Since this TED contains the
+   information relative to all the layers of all regions in the network,
+   a path across multiple layers (possibly crossing multiple regions)
+   can be computed using the information in this TED.  Thus,
+   optimization of network resources across the multiple layers of the
+   same region and across multiple regions can be achieved.
+
+
+
+Shiomoto, et al.             Informational                     [Page 12]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   These concepts allow for the operation of one network layer over the
+   topology (that is, TE links) provided by other network layers (for
+   example, the use of a lower-layer LSC LSP carrying PSC LSPs).  In
+   turn, a greater degree of control and interworking can be achieved,
+   including (but not limited to):
+
+   - Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206]
+     (see Sections 4.3.2 and 4.3.3).
+
+   - Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs.
+
+   Note that in a multi-layer/multi-region network that includes multi-
+   switching-type-capable nodes, an explicit route used to establish an
+   end-to-end LSP can specify nodes that belong to different layers or
+   regions.  In this case, a mechanism to control the dynamic creation
+   of FA-LSPs may be required (see Sections 4.3.2 and 4.3.3).
+
+   There is a full spectrum of options to control how FA-LSPs are
+   dynamically established.  The process can be subject to the control
+   of a policy, which may be set by a management component and which may
+   require that the management plane is consulted at the time that the
+   FA-LSP is established.  Alternatively, the FA-LSP can be established
+   at the request of the control plane without any management control.
+
+4.3.1.  Triggered Signaling
+
+   When an LSP crosses the boundary from an upper to a lower layer, it
+   may be nested into a lower-layer FA-LSP that crosses the lower layer.
+   From a signaling perspective, there are two alternatives to establish
+   the lower-layer FA-LSP: static (pre-provisioned) and dynamic
+   (triggered).  A pre-provisioned FA-LSP may be initiated either by the
+   operator or automatically using features like TE auto-mesh [RFC4972].
+   If such a lower-layer LSP does not already exist, the LSP may be
+   established dynamically.  Such a mechanism is referred to as
+   "triggered signaling".
+
+4.3.2.  FA-LSPs
+
+   Once an LSP is created across a layer from one layer border node to
+   another, it can be used as a data link in an upper layer.
+
+   Furthermore, it can be advertised as a TE link, allowing other nodes
+   to consider the LSP as a TE link for their path computation
+   [RFC4206].  An LSP created either statically or dynamically by one
+   instance of the control plane and advertised as a TE link into the
+   same instance of the control plane is called a Forwarding Adjacency
+   LSP (FA-LSP).  The FA-LSP is advertised as a TE link, and that TE
+   link is called a Forwarding Adjacency (FA).  An FA has the special
+
+
+
+Shiomoto, et al.             Informational                     [Page 13]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   characteristic of not requiring a routing adjacency (peering) between
+   its end points yet still guaranteeing control plane connectivity
+   between the FA-LSP end points based on a signaling adjacency.  An FA
+   is a useful and powerful tool for improving the scalability of
+   GMPLS-TE capable networks since multiple higher-layer LSPs may be
+   nested (aggregated) over a single FA-LSP.
+
+   The aggregation of LSPs enables the creation of a vertical (nested)
+   LSP hierarchy.  A set of FA-LSPs across or within a lower layer can
+   be used during path selection by a higher-layer LSP.  Likewise, the
+   higher-layer LSPs may be carried over dynamic data links realized via
+   LSPs (just as they are carried over any "regular" static data links).
+   This process requires the nesting of LSPs through a hierarchical
+   process [RFC4206].  The TED contains a set of LSP advertisements from
+   different layers that are identified by the ISCD contained within the
+   TE link advertisement associated with the LSP [RFC4202].
+
+   If a lower-layer LSP is not advertised as an FA, it can still be used
+   to carry higher-layer LSPs across the lower layer.  For example, if
+   the LSP is set up using triggered signaling, it will be used to carry
+   the higher-layer LSP that caused the trigger.  Further, the lower
+   layer remains available for use by other higher-layer LSPs arriving
+   at the boundary.
+
+   Under some circumstances, it may be useful to control the
+   advertisement of LSPs as FAs during the signaling establishment of
+   the LSPs [DYN-HIER].
+
+4.3.3.  Virtual Network Topology (VNT)
+
+   A set of one or more lower-layer LSPs provides information for
+   efficient path handling in upper layer(s) of the MLN, or, in other
+   words, provides a virtual network topology (VNT) to the upper layers.
+   For instance, a set of LSPs, each of which is supported by an LSC
+   LSP, provides a VNT to the layers of a PSC region, assuming that the
+   PSC region is connected to the LSC region.  Note that a single
+   lower-layer LSP is a special case of the VNT.  The VNT is configured
+   by setting up or tearing down the lower-layer LSPs.  By using GMPLS
+   signaling and routing protocols, the VNT can be adapted to traffic
+   demands.
+
+   A lower-layer LSP appears as a TE link in the VNT.  Whether the
+   diversely-routed lower-layer LSPs are used or not, the routes of
+   lower-layer LSPs are hidden from the upper layer in the VNT.  Thus,
+   the VNT simplifies the upper-layer routing and traffic engineering
+   decisions by hiding the routes taken by the lower-layer LSPs.
+   However, hiding the routes of the lower-layer LSPs may lose important
+   information that is needed to make the higher-layer LSPs reliable.
+
+
+
+Shiomoto, et al.             Informational                     [Page 14]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   For instance, the routing and traffic engineering in the IP/MPLS
+   layer does not usually consider how the IP/MPLS TE links are formed
+   from optical paths that are routed in the fiber layer.  Two optical
+   paths may share the same fiber link in the lower-layer and therefore
+   they may both fail if the fiber link is cut.  Thus the shared risk
+   properties of the TE links in the VNT must be made available to the
+   higher layer during path computation.  Further, the topology of the
+   VNT should be designed so that any single fiber cut does not bisect
+   the VNT.  These issues are addressed later in this document.
+
+   Reconfiguration of the VNT may be triggered by traffic demand
+   changes, topology configuration changes, signaling requests from the
+   upper layer, and network failures.  For instance, by reconfiguring
+   the VNT according to the traffic demand between source and
+   destination node pairs, network performance factors, such as maximum
+   link utilization and residual capacity of the network, can be
+   optimized.  Reconfiguration is performed by computing the new VNT
+   from the traffic demand matrix and optionally from the current VNT.
+   Exact details are outside the scope of this document.  However, this
+   method may be tailored according to the service provider's policy
+   regarding network performance and quality of service (delay,
+   loss/disruption, utilization, residual capacity, reliability).
+
+5.  Requirements
+
+5.1.  Handling Single-Switching and Multi-Switching-Type-Capable Nodes
+
+   The MRN/MLN can consist of single-switching-type-capable and multi-
+   switching-type-capable nodes.  The path computation mechanism in the
+   MLN should be able to compute paths consisting of any combination of
+   such nodes.
+
+   Both single-switching-type-capable and multi-switching-type-capable
+   (simplex or hybrid) nodes could play the role of layer boundary.
+   MRN/MLN path computation should handle TE topologies built of any
+   combination of nodes.
+
+5.2.  Advertisement of the Available Adjustment Resources
+
+   A hybrid node should maintain resources on its internal links (the
+   links required for vertical integration between layers).  Likewise,
+   path computation elements should be prepared to use information about
+   the availability of termination and adjustment resources as a
+   constraint in MRN/MLN path computations.  This would reduce the
+   probability that the setup of the higher-layer LSP will be blocked by
+   the lack of necessary termination/adjustment resources in the lower
+   layers.
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 15]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   The advertisement of a node's MRN adjustment capabilities (the
+   ability to terminate LSPs of lower regions and forward the traffic in
+   upper regions) is REQUIRED, as it provides critical information when
+   performing multi-region path computation.
+
+   The path computation mechanism should cover the case where the
+   upper-layer links that are directly connected to upper-layer
+   switching elements and the ones that are connected through internal
+   links between upper-layer element and lower-layer element coexist
+   (see Section 4.2.1).
+
+5.3.  Scalability
+
+   The MRN/MLN relies on unified routing and traffic engineering models.
+
+   - Unified routing model: By maintaining a single routing protocol
+     instance and a single TE database per LSR, a unified control plane
+     model removes the requirement to maintain a dedicated routing
+     topology per layer, and therefore does not mandate a full mesh of
+     routing adjacencies per layer.
+
+   - Unified TE model: The TED in each LSR is populated with TE links
+     from all layers of all regions (TE link interfaces on multiple-
+     switching-type-capable LSRs can be advertised with multiple ISCDs).
+     This may lead to an increase in the amount of information that has
+     to be flooded and stored within the network.
+
+   Furthermore, path computation times, which may be of great importance
+   during restoration, will depend on the size of the TED.
+
+   Thus, 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.
+
+   Further, design of the routing protocols MUST NOT prevent TE
+   information filtering based on ISCDs.  The path computation mechanism
+   and the signaling protocol SHOULD be able to operate on partial TE
+   information.
+
+   Since TE links can advertise multiple Interface Switching
+   Capabilities (ISCs), the number of links can be limited (by
+   combination) by using specific topological maps referred to as VNTs
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 16]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   (Virtual Network Topologies).  The introduction of virtual
+   topological maps leads us to consider the concept of emulation of
+   data plane overlays.
+
+5.4.  Stability
+
+   Path computation is dependent on the network topology and associated
+   link state.  The path computation stability of an upper layer may be
+   impaired if the VNT changes frequently and/or if the status and TE
+   parameters (the TE metric, for instance) of links in the VNT changes
+   frequently.  In this context, robustness of the VNT is defined as the
+   capability to smooth changes that may occur and avoid their
+   propagation into higher layers.  Changes to the VNT may be caused by
+   the creation, deletion, or modification of LSPs.
+
+   Protocol mechanisms MUST be provided to enable creation, deletion,
+   and modification of LSPs triggered through operational actions.
+   Protocol mechanisms SHOULD be provided to enable similar functions
+   triggered by adjacent layers.  Protocol mechanisms MAY be provided to
+   enable similar functions to adapt to the environment changes such as
+   traffic demand changes, topology changes, and network failures.
+   Routing robustness should be traded with adaptability of those
+   changes.
+
+5.5.  Disruption Minimization
+
+   When reconfiguring the VNT according to a change in traffic demand,
+   the upper-layer LSP might be disrupted.  Such disruption to the upper
+   layers must be minimized.
+
+   When residual resource decreases to a certain level, some lower-layer
+   LSPs may be released according to local or network policies.  There
+   is a trade-off between minimizing the amount of resource reserved in
+   the lower layer and disrupting higher-layer traffic (i.e., moving the
+   traffic to other TE-LSPs so that some LSPs can be released).  Such
+   traffic disruption may be allowed, but MUST be under the control of
+   policy that can be configured by the operator.  Any repositioning of
+   traffic MUST be as non-disruptive as possible (for example, using
+   make-before-break).
+
+5.6.  LSP Attribute Inheritance
+
+   TE link parameters should be inherited from the parameters of the LSP
+   that provides the TE link, and so from the TE links in the lower
+   layer that are traversed by the LSP.
+
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 17]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   These include:
+
+      - Interface Switching Capability
+      - TE metric
+      - Maximum LSP bandwidth per priority level
+      - Unreserved bandwidth for all priority levels
+      - Maximum reservable bandwidth
+      - Protection attribute
+      - Minimum LSP bandwidth (depending on the switching capability)
+      - SRLG
+
+   Inheritance rules must be applied based on specific policies.
+   Particular attention should be given to the inheritance of the TE
+   metric (which may be other than a strict sum of the metrics of the
+   component TE links at the lower layer), protection attributes, and
+   SRLG.
+
+   As described earlier, hiding the routes of the lower-layer LSPs may
+   lose important information necessary to make LSPs in the higher-layer
+   network reliable.  SRLGs may be used to identify which lower-layer
+   LSPs share the same failure risk so that the potential risk of the
+   VNT becoming disjoint can be minimized, and so that resource-disjoint
+   protection paths can be set up in the higher layer.  How to inherit
+   the SRLG information from the lower layer to the upper layer needs
+   more discussion and is out of scope of this document.
+
+5.7.  Computing Paths with and without Nested Signaling
+
+   Path computation can take into account LSP region and layer
+   boundaries when computing a path for an LSP.  Path computation may
+   restrict the path taken by an LSP to only the links whose interface
+   switching capability is PSC.  For example, suppose that a TDM-LSP is
+   routed over the topology composed of TE links of the same TDM layer.
+   In calculating the path for the LSP, the TED may be filtered to
+   include only links where both end include requested LSP switching
+   type.  In this way hierarchical routing is done by using a TED
+   filtered with respect to switching capability (that is, with respect
+   to particular layer).
+
+   If triggered signaling is allowed, the path computation mechanism may
+   produce a route containing multiple layers/regions.  The path is
+   computed over the multiple layers/regions even if the path is not
+   "connected" in the same layer as where the endpoints of the path
+   exist.  Note that here we assume that triggered signaling will be
+   invoked to make the path "connected", when the upper-layer signaling
+   request arrives at the boundary node.
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 18]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   The upper-layer signaling request MAY contain an ERO (Explicit Route
+   Object) that includes only hops in the upper layer; in which case,
+   the boundary node is responsible for triggered creation of the
+   lower-layer FA-LSP using a path of its choice, or for the selection
+   of any available lower-layer LSP as a data link for the higher layer.
+   This mechanism is appropriate for environments where the TED is
+   filtered in the higher layer, where separate routing instances are
+   used per layer, or where administrative policies prevent the higher
+   layer from specifying paths through the lower layer.
+
+   Obviously, if the lower-layer LSP has been advertised as a TE link
+   (virtual or real) into the higher layer, then the higher-layer
+   signaling request MAY contain the TE link identifier and so indicate
+   the lower-layer resources to be used.  But in this case, the path of
+   the lower-layer LSP can be dynamically changed by the lower layer at
+   any time.
+
+   Alternatively, the upper-layer signaling request MAY contain an ERO
+   specifying the lower-layer FA-LSP route.  In this case, the boundary
+   node MAY decide whether it should use the path contained in the
+   strict ERO or re-compute the path within the lower layer.
+
+   Even in the case that the lower-layer FA-LSPs are already
+   established, a signaling request may also be encoded as a loose ERO.
+   In this situation, it is up to the boundary node to decide whether it
+   should create a new lower-layer FA-LSP or it should use an existing
+   lower-layer FA-LSP.
+
+   The lower-layer FA-LSP can be advertised just as an FA-LSP in the
+   upper layer or an IGP adjacency can be brought up on the lower-layer
+   FA-LSP.
+
+5.8.  LSP Resource Utilization
+
+   Resource usage in all layers should be optimized as a whole (i.e.,
+   across all layers), in a coordinated manner (i.e., taking all layers
+   into account).  The number of lower-layer LSPs carrying upper-layer
+   LSPs should be minimized (note that multiple LSPs may be used for
+   load balancing).  Lower-layer LSPs that could have their traffic
+   re-routed onto other LSPs are unnecessary and should be avoided.
+
+5.8.1.  FA-LSP Release and Setup
+
+   If there is low traffic demand, some FA-LSPs that do not carry any
+   higher-layer LSP may be released so that lower-layer resources are
+   released and can be assigned to other uses.  Note that if a small
+   fraction of the available bandwidth of an FA-LSP is still in use, the
+   nested LSPs can also be re-routed to other FA-LSPs (optionally using
+
+
+
+Shiomoto, et al.             Informational                     [Page 19]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   the make-before-break technique) to completely free up the FA-LSP.
+   Alternatively, unused FA-LSPs may be retained for future use.
+   Release or retention of underutilized FA-LSPs is a policy decision.
+
+   As part of the re-optimization process, the solution MUST allow
+   rerouting of an FA-LSP while keeping interface identifiers of
+   corresponding TE links unchanged.  Further, this process MUST be
+   possible while the FA-LSP is carrying traffic (higher-layer LSPs)
+   with minimal disruption to the traffic.
+
+   Additional FA-LSPs may also be created based on policy, which might
+   consider residual resources and the change of traffic demand across
+   the region.  By creating the new FA-LSPs, the network performance
+   such as maximum residual capacity may increase.
+
+   As the number of FA-LSPs grows, the residual resources may decrease.
+   In this case, re-optimization of FA-LSPs may be invoked according to
+   policy.
+
+   Any solution MUST include measures to protect against network
+   destabilization caused by the rapid setup and teardown of LSPs as
+   traffic demand varies near a threshold.
+
+   Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly
+   advertise the LSP as a TE link and to coordinate into which routing
+   instances the TE link should be advertised.
+
+5.8.2.  Virtual TE Links
+
+   It may be considered disadvantageous to fully instantiate (i.e.,
+   pre-provision) the set of lower-layer LSPs that provide the VNT since
+   this might reserve bandwidth that could be used for other LSPs in the
+   absence of upper-layer traffic.
+
+   However, in order to allow path computation of upper-layer LSPs
+   across the lower layer, the lower-layer LSPs may be advertised into
+   the upper layer as though they had been fully established, but
+   without actually establishing them.  Such TE links that represent the
+   possibility of an underlying LSP are termed "virtual TE links".  It
+   is an implementation choice at a layer boundary node whether to
+   create real or virtual TE links, and the choice (if available in an
+   implementation) MUST be under the control of operator policy.  Note
+   that there is no requirement to support the creation of virtual TE
+   links, since real TE links (with established LSPs) may be used.  Even
+   if there are no TE links (virtual or real) advertised to the higher
+   layer, it is possible to route a higher-layer LSP into a lower layer
+   on the assumption that proper hierarchical LSPs in the lower layer
+   will be dynamically created (triggered) as needed.
+
+
+
+Shiomoto, et al.             Informational                     [Page 20]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   If an upper-layer LSP that makes use of a virtual TE link is set up,
+   the underlying LSP MUST be immediately signaled in the lower layer.
+
+   If virtual TE links are used in place of pre-established LSPs, the TE
+   links across the upper layer can remain stable using pre-computed
+   paths while wastage of bandwidth within the lower layer and
+   unnecessary reservation of adaptation resources at the border nodes
+   can be avoided.
+
+   The solution SHOULD provide operations to facilitate the build-up of
+   such virtual TE links, taking into account the (forecast) traffic
+   demand and available resources in the lower layer.
+
+   Virtual TE links can be added, removed, or modified dynamically (by
+   changing their capacity) according to the change of the (forecast)
+   traffic demand and the available resources in the lower layer.  It
+   MUST be possible to add, remove, and modify virtual TE links in a
+   dynamic way.
+
+   Any solution MUST include measures to protect against network
+   destabilization caused by the rapid changes in the VNT as traffic
+   demand varies near a threshold.
+
+   The concept of the VNT can be extended to allow the virtual TE links
+   to form part of the VNT.  The combination of the fully provisioned TE
+   links and the virtual TE links defines the VNT provided by the lower
+   layer.  The VNT can be changed by setting up and/or tearing down
+   virtual TE links as well as by modifying real links (i.e., the fully
+   provisioned LSPs).  How to design the VNT and how to manage it are
+   out of scope of this document.
+
+   In some situations, selective advertisement of the preferred
+   connectivity among a set of border nodes between layers may be
+   appropriate.  Further decreasing the number of advertisements of the
+   virtual connectivity can be achieved by abstracting the topology
+   (between border nodes) using models similar to those detailed in
+   [RFC4847].
+
+5.9.  Verification of the LSPs
+
+   When a lower-layer LSP is established for use as a data link by a
+   higher layer, the LSP may be verified for correct connectivity and
+   data integrity before it is made available for use.  Such mechanisms
+   are data-technology-specific and are beyond the scope of this
+   document, but the GMPLS protocols SHOULD provide mechanisms for the
+   coordination of data link verification.
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 21]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+5.10.  Management
+
+   An MRN/MLN requires management capabilities.  Operators need to have
+   the same level of control and management for switches and links in
+   the network that they would have in a single-layer or single-region
+   network.
+
+   We can consider two different operational models: (1) per-layer
+   management entities and (2) cross-layer management entities.
+
+   Regarding per-layer management entities, it is possible for the MLN
+   to be managed entirely as separate layers, although that somewhat
+   defeats the objective of defining a single multi-layer network.  In
+   this case, separate management systems would be operated for each
+   layer, and those systems would be unaware of the fact that the layers
+   were closely coupled in the control plane.  In such a deployment, as
+   LSPs were automatically set up as the result of control plane
+   requests from other layers (for example, triggered signaling), the
+   management applications would need to register the creation of the
+   new LSPs and the depletion of network resources.  Emphasis would be
+   placed on the layer boundary nodes to report the activity to the
+   management applications.
+
+   A more likely scenario is to apply a closer coupling of layer
+   management systems with cross-layer management entities.  This might
+   be achieved through a unified management system capable of operating
+   multiple layers, or by a meta-management system that coordinates the
+   operation of separate management systems each responsible for
+   individual layers.  The former case might only be possible with the
+   development of new management systems, while the latter is feasible
+   through the coordination of existing network management tools.
+
+   Note that when a layer boundary also forms an administrative
+   boundary, it is highly unlikely that there will be unified multi-
+   layer management.  In this case, the layers will be separately
+   managed by the separate administrative entities, but there may be
+   some "leakage" of information between the administrations in order to
+   facilitate the operation of the MLN.  For example, the management
+   system in the lower-layer network might automatically issue reports
+   on resource availability (coincident with TE routing information) and
+   alarm events.
+
+   This discussion comes close to an examination of how a VNT might be
+   managed and operated.  As noted in Section 5.8, issues of how to
+   design and manage a VNT are out of scope for this document, but it
+   should be understood that the VNT is a client-layer construct built
+   from server-layer resources.  This means that the operation of a VNT
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 22]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   is a collaborative activity between layers.  This activity is
+   possible even if the layers are from separate administrations, but in
+   this case the activity may also have commercial implications.
+
+   MIB modules exist for the modeling and management of GMPLS networks
+   [RFC4802] [RFC4803].  Some deployments of GMPLS networks may choose
+   to use MIB modules to operate individual network layers.  In these
+   cases, operators may desire to coordinate layers through a further
+   MIB module that could be developed.  Multi-layer protocol solutions
+   (that is, solutions where a single control plane instance operates in
+   more than one layer) SHOULD be manageable through MIB modules.  A
+   further MIB module to coordinate multiple network layers with this
+   control plane MIB module may be produced.
+
+   Operations and Management (OAM) tools are important to the successful
+   deployment of all networks.
+
+   OAM requirements for GMPLS networks are described in [GMPLS-OAM].
+   That document points out that protocol solutions for individual
+   network layers should include mechanisms for OAM or make use of OAM
+   features inherent in the physical media of the layers.  Further
+   discussion of individual-layer OAM is out of scope of this document.
+
+   When operating OAM in a MLN, consideration must be given to how to
+   provide OAM for end-to-end LSPs that cross layer boundaries (that may
+   also be administrative boundaries) and how to coordinate errors and
+   alarms detected in a server layer that need to be reported to the
+   client layer.  These operational choices MUST be left open to the
+   service provider and so MLN protocol solutions MUST include the
+   following features:
+
+   - Within the context and technology capabilities of the highest
+     technology layer of an LSP (i.e., the technology layer of the first
+     hop), it MUST be possible to enable end-to-end OAM on a MLN 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 mapped to server-layer OAM operations.  Most such requirements
+     are highly dependent on the OAM facilities of the data plane
+     technologies of client and server layers.  However, control plane
+     mechanisms used in the client layer per [GMPLS-OAM] MUST map and
+     enable OAM in the server layer.
+
+   - OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP
+     MUST operate for that LSP along its entire length.  This means that
+     if an LSP crosses a domain of a lower-layer technology, the
+     client-layer OAM operation must operate seamlessly within the
+     client layer at both ends of the client-layer LSP.
+
+
+
+Shiomoto, et al.             Informational                     [Page 23]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   - OAM functions operating within a server layer MUST be controllable
+     from the client layer such that the server-layer LSP(s) that
+     support a client-layer LSP have OAM enabled at the request of the
+     client layer.  Such control SHOULD be subject to policy at the
+     layer boundary, just as automatic provisioning and LSP requests to
+     the server layer are subject to policy.
+
+   - The status including errors and alarms applicable to 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 so that the
+     server layer may filter or hide information supplied to the client
+     layer.  Furthermore, the client layer SHOULD be able to select to
+     not receive any or all such information.
+
+   Note that the interface between layers lies within network nodes and
+   is, therefore, not necessarily the subject of a protocol
+   specification.  Implementations MAY use standardized techniques (such
+   as MIB modules) to convey status information (such as errors and
+   alarms) between layers, but that is out of scope for this document.
+
+6.  Security Considerations
+
+   The MLN/MRN architecture does not introduce any new security
+   requirements over the general GMPLS architecture described in
+   [RFC3945].  Additional security considerations form MPLS and GMPLS
+   networks are described in [MPLS-SEC].
+
+   However, where the separate layers of an MLN/MRN network are operated
+   as different administrative domains, additional security
+   considerations may be given to the mechanisms for allowing LSP setup
+   crossing one or more layer boundaries, for triggering lower-layer
+   LSPs, or for VNT management.  Similarly, consideration may be given
+   to the amount of information shared between administrative domains,
+   and the trade-off between multi-layer TE and confidentiality of
+   information belonging to each administrative domain.
+
+   It is expected that solution documents will include a full analysis
+   of the security issues that any protocol extensions introduce.
+
+7.  Acknowledgements
+
+   The authors would like to thank Adrian Farrel and the participants of
+   ITU-T Study Group 15, Question 14 for their careful review.  The
+   authors would like to thank the IESG review team for rigorous review:
+   special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu,
+   and Dave Ward.
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 24]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [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.
+
+   [RFC4397]   Bryskin, I. and A. Farrel, "A Lexicography for the
+               Interpretation of Generalized Multiprotocol Label
+               Switching (GMPLS) Terminology within the Context of the
+               ITU-T's Automatically Switched Optical Network (ASON)
+               Architecture", RFC 4397, February 2006.
+
+   [RFC4726]   Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
+               for Inter-Domain Multiprotocol Label Switching Traffic
+               Engineering", RFC 4726, November 2006.
+
+8.2.  Informative References
+
+   [DYN-HIER]  Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A.  and
+               Z. Ali, "Procedures for Dynamically Signaled Hierarchical
+               Label Switched Paths", Work in Progress, February 2008.
+
+   [MRN-EVAL]  Le Roux, J.L., Ed., and D. Papadimitriou, Ed.,
+               "Evaluation of existing GMPLS Protocols against Multi
+               Layer and Multi Region Networks (MLN/MRN)", Work in
+               Progress, December 2007.
+
+   [RFC5146]   Kumaki, K., Ed., "Interworking Requirements to Support
+               Operation of MPLS-TE over GMPLS Networks", RFC 5146,
+               March 2008.
+
+   [MPLS-SEC]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+               Networks", Work in Progress, February 2008.
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 25]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+   [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.
+
+   [RFC4847]   Takeda, T., Ed., "Framework and Requirements for Layer 1
+               Virtual Private Networks", RFC 4847, April 2007.
+
+   [RFC4972]   Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
+               Previdi, S., Psenak, P., and P. Mabbey, "Routing
+               Extensions for Discovery of Multiprotocol (MPLS) Label
+               Switch Router (LSR) Traffic Engineering (TE) Mesh
+               Membership", RFC 4972, July 2007.
+
+   [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.
+
+9.  Contributors' Addresses
+
+   Eiji Oki
+   NTT Network Service Systems Laboratories
+   3-9-11 Midori-cho, Musashino-shi
+   Tokyo 180-8585
+   Japan
+   Phone: +81 422 59 3441
+   EMail: oki.eiji@lab.ntt.co.jp
+
+   Ichiro Inoue
+   NTT Network Service Systems Laboratories
+   3-9-11 Midori-cho, Musashino-shi
+   Tokyo 180-8585
+   Japan
+   Phone: +81 422 59 3441
+   EMail: ichiro.inoue@lab.ntt.co.jp
+
+   Emmanuel Dotaro
+   Alcatel-Lucent
+   Route de Villejust
+   91620 Nozay
+   France
+   Phone: +33 1 3077 2670
+   EMail: emmanuel.dotaro@alcatel-lucent.fr
+
+
+
+Shiomoto, et al.             Informational                     [Page 26]
+
+RFC 5212                  MRN/MLN Requirements                 July 2008
+
+
+Authors' Addresses
+
+   Kohei Shiomoto
+   NTT Network Service Systems Laboratories
+   3-9-11 Midori-cho, Musashino-shi
+   Tokyo 180-8585
+   Japan
+   EMail: shiomoto.kohei@lab.ntt.co.jp
+
+   Dimitri Papadimitriou
+   Alcatel-Lucent
+   Copernicuslaan 50
+   B-2018 Antwerpen
+   Belgium
+   Phone : +32 3 240 8491
+   EMail: dimitri.papadimitriou@alcatel-lucent.be
+
+   Jean-Louis Le Roux
+   France Telecom R&D
+   Av Pierre Marzin
+   22300 Lannion
+   France
+   EMail: jeanlouis.leroux@orange-ftgroup.com
+
+   Martin Vigoureux
+   Alcatel-Lucent
+   Route de Villejust
+   91620 Nozay
+   France
+   Phone: +33 1 3077 2669
+   EMail: martin.vigoureux@alcatel-lucent.fr
+
+   Deborah Brungard
+   AT&T
+   Rm. D1-3C22 - 200
+   S. Laurel Ave.
+   Middletown, NJ 07748
+   USA
+   Phone: +1 732 420 1573
+   EMail: dbrungard@att.com
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 27]
+
+RFC 5212                  MRN/MLN Requirements                 July 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto, et al.             Informational                     [Page 28]
+