[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5212

  Network Working Group                              Kohei Shiomoto (NTT)
  Internet-Draft                          Dimitri Papadimitriou (Alcatel)
  Intended Status: Informational   Jean-Louis Le Roux (France Telecom)
                                               Martin Vigoureux (Alcatel)
                                                  Deborah Brungard (AT&T)
  
  Expires: October 2007                                        April 2007
  
                Requirements for GMPLS-based multi-region and
                       multi-layer networks (MRN/MLN)
  
                   draft-ietf-ccamp-gmpls-mln-reqs-03.txt
  
  
  Status of this Memo
  
     By submitting this Internet-Draft, each author represents that any
     applicable patent or other IPR claims of which he or she is aware
     have been or will be disclosed, and any of which he or she becomes
     aware will be disclosed, in accordance with Section 6 of BCP 79.
  
     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."
  
     The list of current Internet-Drafts can be accessed at
          http://www.ietf.org/ietf/1id-abstracts.txt
  
     The list of Internet-Draft Shadow Directories can be accessed at
          http://www.ietf.org/shadow.html
  
     This Internet-Draft will expire on April 2007.
  
  
     Copyright Notice
  
     Copyright (C) The IETF Trust (2007).
  
  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.
  
                           Expires October 2007                 [Page 1]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
  
     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 a 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.
  
  Table of Contents
  
     1. Introduction...................................................3
     2. Conventions Used in this Document..............................4
     2.1. List of acronyms.............................................4
     3. Positioning....................................................5
     3.1. Data Plane Layers and Control Plane Regions..................5
     3.2. Service layer networks.......................................6
     3.3. Vertical and Horizontal interaction and integration..........6
     4. Key Concepts of GMPLS-Based MLNs and MRNs......................7
     4.1. Interface Switching Capability...............................7
     4.2. Multiple Interface Switching Capabilities....................8
     4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes....9
     4.3. Integrated Traffic Engineering (TE) and Resource Control.....9
     4.3.1. Triggered Signaling.......................................10
     4.3.2. FA-LSPs...................................................10
     4.3.3. Virtual Network Topology (VNT)............................11
     5. Requirements..................................................12
     5.1. Handling Single-Switching and Multi-Switching-Type-Capable
     Nodes............................................................12
     5.2. Advertisement of the Available Adaptation Resource..........13
     5.3. Scalability.................................................13
     5.4. Stability...................................................13
     5.5. Disruption Minimization.....................................14
     5.6. LSP Attribute Inheritance...................................14
     5.7. Computing Paths With and Without Nested Signaling...........15
     5.8. LSP Resource Utilization....................................16
     5.8.1. FA-LSP Release and Setup..................................16
     5.8.2. Virtual TE-Links..........................................17
     5.9. Verification of the LSPs....................................18
     6. Security Considerations.......................................18
     7. IANA Considerations...........................................19
     8. References....................................................19
     8.1. Normative Reference.........................................19
     8.2. Informative References......................................19
     9. Authors' Addresses............................................20
     10. Contributors' Addresses......................................21
     11. Intellectual Property Considerations.........................21
     12. Full Copyright Statement.....................................22
  
  
                           Expires October 2007                 [Page 2]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
  1. Introduction
  
     Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
     technologies: packet switching, layer-2 switching, TDM switching,
     wavelength switching, and fiber switching (see [RFC3945]). The
     Interface Switching Capability (ISC) concept is introduced for
     these switching technologies and is designated as follows: PSC
     (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time
     Division Multiplex capable), LSC (lambda switch capable), and FSC
     (fiber switch capable).
  
     Service providers may operate networks where multiple different
     switching technologies exist. 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.
  
     A network comprising 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). To
     differentiate a network supporting LSPs of different switching
     types from a single region network, a network supporting more than
     one switching technology and controlled by a single GMPLS control
     plane instance is called a Multi-Region Network (MRN).
  
     MLNs can be categorized according to the distribution of the ISCs
     among the 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 that support different ISCs.
  
     - 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.
  
                           Expires October 2007                 [Page 3]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     - 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 enabling 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.
  
     Consider, for example, a MRN consisting of packet-switch capable
     routers and TDM cross-connects. Assume that a packet 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 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. Further, 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 resources availability (e.g., link bandwidth, or adaptation
     ports between regions) across the regions. The same considerations
     hold when VC4 LSPs are provisioned to provide extra flexibility for
     the VC12 and/or VC11 layers in an MLN.
  
     This document describes the requirements to support multi-
     region/multi-layer networks. There is no intention to specify
     solution-specific elements in this document. The applicability of
     existing GMPLS protocols and any protocol extensions to the MRN/MLN
     is addressed in separate documents [MRN-EVAL].
  
  2. Conventions Used in this Document
  
     Although this is not a protocol specifcation, 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].
  
  2.1.List of acronyms
  
     MLN: Multi-Layer Network
     MRN: Multi-Region Network
  
                           Expires October 2007                 [Page 4]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     ISC: Interface Switching Capability
     ISCD: Interface Switching Capability Descriptor
     PSC: Packet Switching Capable
     L2SC: Layer-2 Switching Capable
     TDM: Time-Division Switch Capable
     LSC: Lambda Switching Capable
     FSC: Fiber Switching Capable
     SRLG: Shared Risk Ling Group
     VNT: Virtual Network Topology
     FA: Forwarding Adjacency
     FA-LSP: Forwarding Adjacency Label Switched Path
     TE: Traffic Engineering
     TED: Traffic Engineering Database
     LSP: Label Switched Path
     LSR: Label Switching Router
  
  
  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 and VC-4 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 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 within the control plane, but layers from
  
                           Expires October 2007                 [Page 5]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     different regions may use different technology-specific objects or
     encodings. This means that there is a control plane discontinuity
     when crossing a region boundary even if a single control plane
     instance is used to manage the whole MRN.
  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
     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.
  
     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 [MPLS-GMPLS]. 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
  
  
                           Expires October 2007                 [Page 6]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     Vertical interaction is defined as the collaborative mechanisms
     within a network element that is capable of supporting more than
     one layer and of realizing the client/server relationships between
     the layers. 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. 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 (i.e., nodes with the same switching capability).
     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.
  
     This distinction needs further clarification when administrative
     domains match layer boundaries. Horizontal interaction is extended
     to cover such cases. For example, the collaborative mechanisms in
     place between two lambda switching capable areas relate to
     horizontal integration. On the other hand, the collaborative
     mechanisms in place in a network that supports IP/MPLS over TDM
     switching could be described as vertical and horizontal integration
     in the case where each network belongs to a separate routing area.
  
  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 sub-set 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
  
  
  
                           Expires October 2007                 [Page 7]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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, 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.
  
     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. For example,
     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
  
                           Expires October 2007                 [Page 8]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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 adaptation capabilities between the switching technologies
     supported. That is, the node's capability to perform layer border
     node functions.
  
  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 adaptation 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/adaptation
     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         :  |        ----------      :
               +PSC       :  +--<->--|#c  TDM   |     :
              Link2 ------------<->--|#d        |     :
                          :           ----------      :
                          :............................
  
                               Figure 1. Hybrid node.
  
  
  4.3. Integrated Traffic Engineering (TE) and Resource Control
  
  
  
                           Expires October 2007                 [Page 9]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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.
  
     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 inter-working can be
     achieved, including (but not limited too):
  
     - 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 [AUTO-MESH]. 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
  
  
                           Expires October 2007                [Page 10]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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
     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 Traffic Engineering (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 of 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 virtual network topology 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 virtual network topology is configured by setting up or
  
                           Expires October 2007                [Page 11]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     tearing down the lower layer LSPs. By using GMPLS signaling and
     routing protocols, the virtual network topology 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. 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 virtual network topology may be triggered by
     traffic demand changes, topology configuration changes, signaling
     requests from the upper layer, and network failures. For instance,
     by reconfiguring the virtual network topology 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
  
  
                           Expires October 2007                [Page 12]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
  5.2. Advertisement of the Available Adaptation Resource
  
     A hybrid node SHOULD maintain resources on its internal links (the
     links required for vertical (layer) integration) and SHOULD
     advertise the resource information for those links. Likewise, path
     computation elements SHOULD be prepared to use the availability of
     termination/adaptation resources as a constraint in MRN/MLN path
     computations to reduce the higher layer LSP setup blocking
     probability caused by the lack of necessary termination/ adaptation
     resources in the lower layer(s).
  
     The advertisement of the adaptation capability to terminate LSPs of
     lower-region and forward traffic in the upper-region is REQUIRED,
     as it provides critical information when performing multi-region
     path computation.
  
     The mechanism SHOULD cover the case where the upper-layer links
     which are directly connected to upper-layer switching element and
     the ones which 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 a unified traffic engineering and routing
     model. The TED in each LSR is populated with TE-links from all
     layers of all regions. This may lead to a huge 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.
  
  
  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
  
  
                           Expires October 2007                [Page 13]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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.
  
     Creation, deletion, and modification of LSPs MAY be triggered by
     adjacent layers or through operational actions to meet traffic
     demand changes, topology changes, signaling requests from the upper
     layer, and network failures. Routing robustness SHOULD be traded
     with adaptability with respect to the change of incoming traffic
     requests.
  
  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.
  
     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 TE
  
                           Expires October 2007                [Page 14]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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 MAY take into account LSP region and layer
     boundaries when computing a path for an LSP. For example, path
     computation MAY restrict the path taken by an LSP to only the links
     whose interface switching capability is PSC.
  
     Interface switching capability is used as a constraint in path
     computation. For example, 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 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.
  
     The upper-layer signaling request may contain an ERO 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
  
                           Expires October 2007                [Page 15]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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 is responsible for decision as to which it should use the path
     contained in the strict ERO or it should re-compute the path within
     in the lower-layer.
  
     Even in case the lower-layer FA-LSPs are already established, a
     signaling request may also be encoded as loose ERO. In this
     situation, it is up to the boundary node to decide whether it
     should a new lower-layer FA-LSP or it should use the existing
     lower-layer FA-LSPs.
  
     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
  
     It MUST be possible to utilize network resources efficiently.
     Particularly, 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
  
     Statistical multiplexing can only be employed in PSC and L2SC
     regions. A PSC or L2SC LSP may or may not consume the maximum
     reservable bandwidth of the TE link (FA LSP) that carries it. On
     the other hand, a TDM, or LSC LSP always consumes a fixed amount of
     bandwidth as long as it exists (and is fully instantiated) because
     statistical multiplexing is not available.
  
     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 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.
  
                           Expires October 2007                [Page 16]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
  
     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 resource 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, and
     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 assumptions that proper hierarchical LSPs in the
     lower layer will be dynamically created (triggered) as needed.
  
     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.
  
  
  
                           Expires October 2007                [Page 17]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     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 ports at the border nodes
     can be avoided.
  
     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 solution SHOULD provide operations to facilitate the build-up
     of such virtual TE-links, taking into account the (forecast)
     traffic demand and available resource in the lower-layer.
  
     Virtual TE-links MAY be modified dynamically (by adding or removing
     virtual TE links, or changing their capacity) according to the
     change of the (forecast) traffic demand and the available resource
     in the lower-layer.
  
     Any solution MUST include measures to protect against network
     destabilization caused by the rapid changes in the virtual network
     topology as traffic demand varies near a threshold.
  
     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).
  
     The maximum number of virtual TE links that can be defined SHOULD
     be configurable.
  
     How to design the VNT and how to manage it are out of scope of this
     document.
  
  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. Such mechanisms are data technology-specific and
     are beyond the scope of this document, but may be coordinated
     through the GMPLS control plane.
  
  
  
  6. Security Considerations
  
     The current version of this document does not introduce any new
     security considerations as it only lists a set of requirements.
  
  
  
                           Expires October 2007                [Page 18]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     It is expected that solution documents will include a full analysis
     of the security issues that any protocol extensions introduce.
  
  7. IANA Considerations
  
     This informational document makes no requests to IANA for action.
  
  8. References
  
  8.1. Normative Reference
  
     [RFC2119]       Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.
  
  
     [RFC4202]  K.Kompella and Y.Rekhter, "Routing Extensions in
                   Support of Generalized Multi-Protocol Label
                   Switching (GMPLS)," RFC4202, October 2005.
  
     [RFC4726]  A.Farrel, J-P. Vasseur, and A.Ayyangar, "A Framework
                   for Inter-Domain Multiprotocol Label Switching
                   Traffic Engineering", RFC 4726, November 2006.
  
     [RFC4206]  K.Kompella and Y.Rekhter, "Label Switched Paths (LSP)
                   Hierarchy with Generalized Multi-Protocol Label
                   Switching (GMPLS) Traffic Engineering (TE),"
                   RFC4206, Oct. 2005.
  
     [RFC3945]  E.Mannie (Ed.), "Generalized Multi-Protocol Label
                   Switching (GMPLS) Architecture", RFC 3945, October
                   2004.
     [RFC4397]  I.Bryskin 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.
  
  8.2. Informative References
  
     [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D.,
                   Shiomoto, K., Vigoureux, M.,"Evaluation of existing
                   GMPLS Protocols against Multi Layer and Multi Region
                   Networks (MLN/MRN)", draft-ietf-ccamp-gmpls-mrn-eval,
                   work in progress.
  
     [MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to
                   Support operation of MPLS-TE over GMPLS networks",
  
  
                           Expires October 2007                [Page 19]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
                   draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in
                   progress.
  
     [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and
                   Ali, Z., "Procedures for Dynamically Signaled
                   Hierarchical Label Switched Paths", draft-ietf-
                   ccamp-lsp-hierarchy-bis, work in progress.
  
     [AUTO-MESH]   Vasseur, JP., Le Roux, JL., et al., "Routing
                   extensions for discovery of Multiprotocol (MPLS)
                   Label Switch Router (LSR) Traffic Engineering (TE)
                   mesh membership", draft-ietf-ccamp-automesh, work in
                   progress.
  
  
  
  9. 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
     Francis Wellensplein 1,
     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-ft.com
  
     Martin Vigoureux
     Alcatel-Lucent
     Route de Nozay, 91461 Marcoussis cedex, France
     Phone: +33 (0)1 69 63 18 52
     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
  
  
                           Expires October 2007                [Page 20]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
  10.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 Nozay,
     91461 Marcoussis cedex,
     France
     Phone : +33 1 6963 4723
     Email: emmanuel.dotaro@alcatel-lucent.fr
  
  11. Intellectual Property Considerations
  
     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
  
  
                           Expires October 2007                [Page 21]


                  draft-ietf-ccamp-gmpls-mln-reqs-03.txt      April 2007
  
  
  
     this standard.  Please address the information to the IETF at ietf-
     ipr@ietf.org.
  
  12. Full Copyright Statement
  
     Copyright (C) The IETF Trust (2007). This document is subject to
     the rights, licenses and restrictions contained in BCP 78, and
     except as set forth therein, the authors retain all their rights.
  
     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.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
                           Expires October 2007                [Page 22]
  

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/