GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5212

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):
  1. 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

  1. 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.
  1. 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:
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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).
  1. 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:
  1. 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.
  1. 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):
  1. Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206]

(see Sections 4.3.2 and 4.3.3).

  1. 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.
  1. 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.
  1. 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:
  1. Number of nodes
  2. Number of TE links (including FA-LSPs)
  3. Number of LSPs
  4. Number of regions and layers
  5. 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:
  1. Interface Switching Capability
  2. TE metric
  3. Maximum LSP bandwidth per priority level
  4. Unreserved bandwidth for all priority levels
  5. Maximum reservable bandwidth
  6. Protection attribute
  7. Minimum LSP bandwidth (depending on the switching capability)
  8. 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:
  1. 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.
  1. 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

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc5212.txt · Last modified: 2008/07/09 00:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki