[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-Lucent)
  Intended Status: Informational    Jean-Louis Le Roux (France Telecom)
                                     Martin Vigoureux (Alcatel-Lucent)
                                               Deborah Brungard (AT&T)
 
  Expires: July 2008                                      January 2008
 
 
               Requirements for GMPLS-Based Multi-Region and
                      Multi-Layer Networks (MRN/MLN)
 
                 draft-ietf-ccamp-gmpls-mln-reqs-08.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 in April 2008.
 
 
 
 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 July 2008                  [Page 1]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 ....................................................
 1.1. Scope .........................................................
 2. Conventions Used in this Document ...............................
 2.1. List of Acronyms ..............................................
 3. Positioning .....................................................
 3.1. Data Plane Layers and Control Plane Regions ...................
 3.2. Service Layer Networks .. .....................................
 3.3. Vertical and Horizontal Interaction and Integration ...........
 3.4. Motivation ....................................................
 4. Key Concepts of GMPLS-Based MLNs and MRNs .......................
 4.1. Interface Switching Capability ................................
 4.2. Multiple Interface Switching Capabilities .....................
 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes .....
 4.3. Integrated Traffic Engineering (TE) and Resource Control ......
 4.3.1. Triggered Signaling .........................................
 4.3.2. FA-LSPs .....................................................
 4.3.3. Virtual Network Topology (VNT) ..............................
 5. Requirements ....................................................
 5.1. Handling Single-Switching and Multi-Switching-Type-Capable
 Nodes .......................................................
 5.2. Advertisement of the Available Adjustment Resource ............
 5.3. Scalability ...................................................
 5.4. Stability .....................................................
 5.5. Disruption Minimization .......................................
 5.6. LSP Attribute Inheritance .....................................
 5.7. Computing Paths With and Without Nested Signaling .............
 5.8. LSP Resource Utilization ......................................
 5.8.1. FA-LSP Release and Setup ....................................
 5.8.2. Virtual TE-Links ............................................
 5.9. Verification of the LSPs ......................................
 6. Security Considerations .........................................
 7. IANA Considerations ............................................
 8. Acknowledgements ................................................
 9. References ......................................................
 9.1. Normative Reference ...........................................
 9.2. Informative References ........................................
 
                          Expires July 2008                  [Page 2]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
 10. Authors' Addresses .............................................
 11. Contributors' Addresses ........................................
 12. Intellectual Property Considerations ...........................
 13. Full Copyright Statement .......................................
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
                          Expires July 2008                  [Page 3]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
 
 
 1. Introduction
 
    Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
    technologies: packet switching, layer-2 switching, TDM switching,
    wavelength switching, and fiber switching (see [RFC3945]). The
    Interface Switching Capability (ISC) concept is introduced for
    these switching technologies and is designated as follows: PSC
    (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time
    Division Multiplex capable), LSC (lambda switch capable), and FSC
    (fiber switch capable).
 
    The representation, in a GMPLS control plane, of a switching
    technology domain is referred to as a region [RFC4206]. A switching
    type describes the ability of a node to forward data of a
    particular data plane technology, and uniquely identifies a network
    region. A 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  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 LSRs:
    - Each LSR may support just one ISC.
      Such LSRs are known as single-switching-type-capable LSRs.
      The MLN may comprise a set of single-switching-type-capable LSRs
        some of which support different ISCs.
    - 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 July 2008                  [Page 4]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    -
    - - 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 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 resources 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.
 
 1.1. Scope
 
    This document describes the requirements to support multi-region/
    multi-layer networks. There is no intention to specify solution-
    specific and/or protocol 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].
 
    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
 
                          Expires July 2008                  [Page 5]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 TE domain to interoperate with edge nodes/domains
    supporting non-GMPLS interfaces (such as those defined by other
    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].
 
 2.1. List of Acronyms
 
    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 Ling Group
    TDM: Time-Division Switch Capable
    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
 
                          Expires July 2008                  [Page 6]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 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 LSR hosting different
    switching technologies because change 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.
 
 
 
                          Expires July 2008                  [Page 7]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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
 
    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 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.
 
 
 
                          Expires July 2008                  [Page 8]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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.
 
    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 lambda switching capable areas
    relate to horizontal integration. On the other hand, the
    collaborative mechanisms in place between a packet switching
    capable (e.g., IP/MPLS) domain and a separate time division
    switching capable (e.g., VC4 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
    Traffic Engineering (TE) capabilities. For instance, this enables
    effective network resource utilization of both the Packet/Layer2
    LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP
    regions in high capacity networks.
 
    The rationales for GMPLS controlled multi-layer/multi-region
    networks are summarized below:
 
    - The maintenance of multiple instances of the control plane on
      devices hosting more than one switching capability not only
      increases the complexity of their interactions but also increases
      the total amount of processing individual instances would handle.
 
    - The unification of the addressing spaces helps in avoiding
      multiple identifiers for the same object (a link, for instance,
      or more generally, any network resource). On the other hand such
      aggregation does not impact the separation between the control
      plane and the data plane.
 
                          Expires July 2008                  [Page 9]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
 
    - By maintaining a single routing protocol instance and a single TE
      database per LSR, a unified control plane model removes the
      requirement to maintain a dedicated routing topology per layer
      and therefore does not mandate a full mesh of routing adjacencies
      as is the case with overlaid control planes.
 
    - The collaboration between technology layers where the control
      channel is associated with the data channel (e.g. packet/framed
      data planes) and technology layers where the control channel is
      not directly associated with the data channel (SONET/SDH, G.709,
      etc.) is facilitated by the capability within GMPLS to associate
      in-band control plane signaling to the IP terminating interfaces
      of the control plane.
 
    - Resource management and policies to be applied at the edges of
      such a MRN/MLN is made more simple (fewer control to management
      interactions) and more scalable (through the use of aggregated
      information).
 
    - Multi-region/multi-layer traffic engineering is facilitated as
      TE-links from distinct regions/layers are stored within the same
      TE Database.
 
 4. Key Concepts of GMPLS-Based MLNs and MRNs
 
    A network comprising transport nodes with multiple data plane
    layers of either the same ISC or different ISCs, controlled by a
    single GMPLS control plane instance, is called a Multi-Layer
    Network (MLN). A 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
 
     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.
 
 
 
 
                          Expires July 2008                 [Page 10]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 (following
      the rules defined in [RFC4206]). 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   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 capacity between the switching technologies
    supported. The term "adjustment" capacity refers to the property of
    an hybrid node to interconnect different switching capabilities it
    provides through its external interfaces.. This information allows
    path computation to select an end- to-end multi-layer or multi-
 
                          Expires July 2008                 [Page 11]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    region path that includes links of different switching capabilities
    that are joined by LSRs that can adapt the signal between the links.
 
 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,
 
                          Expires July 2008                 [Page 12]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 [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
 
 
                          Expires July 2008                 [Page 13]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    [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
    tearing down the lower layer LSPs. By using GMPLS signaling and
    routing protocols, the virtual network topology can be adapted to
    traffic demands.
 
 
 
                          Expires July 2008                 [Page 14]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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.
 
 5.2. Advertisement of the Available Adjustment Resource
 
     A hybrid node SHOULD maintain resources on its internal links (the
    links required for vertical (layer) integration) and SHOULD
 
                          Expires July 2008                 [Page 15]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    advertise the resource information for those links. Likewise, path
    computation elements SHOULD be prepared to use the availability of
    termination/ adjustment 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/adjustment
    resources in the lower layer(s).
 
    The advertisement of the adjustment 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 unified routing and traffic engineering
    models.
 
    - Unified routing model: By maintaining a single routing protocol
      instance and a single TE database per LSR, a unified control
      plane   model removes the requirement to maintain a dedicated
      routing   topology per layer, and therefore does not mandate a
      full mesh of   routing adjacencies per layer.
 
    - Unified TE model: The TED in each LSR is populated with TE-links
      from all layers of all regions (TE link interfaces on multiple-
      switching-capability LSRs can be advertised with multiple ISCDs).
      This may lead to an increase in the amount of information that
      has   to be flooded and stored within the network.
 
    Furthermore, path computation times, which may be of great
    importance during restoration, will depend on the size of the TED.
 
    Thus MRN/MLN routing mechanisms MUST be designed to scale well with
    an increase of any of the following:
 
     - Number of nodes
     - Number of TE-links (including FA-LSPs)
     - Number of LSPs  - Number of regions and layers
     - Number of ISCDs per TE-link.
 
    Further, design of the routing protocols MUST NOT prevent TE
    information filtering based on ISCDs. The path computation
    mechanism and the signaling protocol SHOULD be able to operate on
    partial TE information.
 
 
                          Expires July 2008                 [Page 16]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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
    (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.
 
    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:
 
 
 
                          Expires July 2008                 [Page 17]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
 
    - 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
    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
 
                          Expires July 2008                 [Page 18]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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 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
 
 
 
                          Expires July 2008                 [Page 19]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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.
 
    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
 
                          Expires July 2008                 [Page 20]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    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.
 
    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 resource 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 resource in the lower-layer.
 
    Virtual TE-links MAY be added, removed or modified dynamically (by
    changing their capacity) according to the change of the (forecast)
    traffic demand and the available resource in the lower-layer. The
    maximum number of virtual TE links that can be defined SHOULD be
    configurable.
 
    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 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 advertisement 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. Such mechanisms are data technology-specific and
 
                          Expires July 2008                 [Page 21]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    are beyond the scope of this document, but may be coordinated
    through the GMPLS control plane.
 
 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 a MLN/MRN network are
    operated as different administrative domains, additional security
    considerations may be given to the mechanisms for allowing inter-
    layer LSP setup, 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. IANA Considerations
 
    This informational document makes no requests to IANA for action.
 
 8. Acknowledgements
 
    The authors would like to thank Adrian Farrel and the participants
    of ITU-T Study Group 15 Question 14 for their careful review.
 
 
 9. References
 
 9.1. Normative Reference
 
     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 
     [RFC3945]  E. Mannie (Editor), "Generalized Multi-Protocol Label
                Switching (GMPLS) Architecture", RFC 3945, October 2004.
 
     [RFC4202]  Kompella, K., and Rekhter, Y., "Routing Extensions in
                Support of Generalized Multi-Protocol Label Switching
                (GMPLS)," RFC4202, October 2005.
 
     [RFC4206]  Kompella, K., and Rekhter, Y., "Label Switched Paths
                (LSP) Hierarchy with Generalized Multi-Protocol Label
 
 
                          Expires July 2008                 [Page 22]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
                Switching (GMPLS) Traffic Engineering (TE)," RFC4206,
                Oct. 2005.
 
     [RFC4397]  Bryskin, I., and Farrel, A., "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, JP., and Ayyangar, A., "A
                Framework for Inter-Domain Multiprotocol Label
                Switching Traffic Engineering", RFC 4726, November 2006.
 
 9.2. Informative References
 
     [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.
 
     [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 Network (MLN/MRN) Requirements", draft-
                 ietf-ccamp-gmpls- mln-eval, work in progress.
     [MPLS-GMPLS]
                 K. Kumaki (Editor), "Interworking Requirements to
                 Support Operation of MPLS-TE over GMPLS Networks",
                 draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in
                 progress.
 
     [MPLS-SEC]  Fang, L., et al., "Security Framework for MPLS and
                 GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-
                 security-framework, work in progress.
 
     [RFC4847]   T. Takeda (Editor), " Framework and Requirements for
                 Layer 1 Virtual Private Networks", RFC 4847, April
                 2007.
 
     [RFC4972]   Vasseur, JP., Le Roux, JL., et al., "Routing
                 Extensions for Discovery of Multiprotocol (MPLS)
                 Label Switch Router (LSR) Traffic Engineering (TE)
                 Mesh Membership", RFC 4972, July 2007.
 
 10. 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
 
 
                          Expires July 2008                 [Page 23]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
 
    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-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
 
 11. 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,
 
                          Expires July 2008                 [Page 24]


                draft-ietf-ccamp-gmpls-mln-reqs-08.txt   January 2008
 
 
 
    91461 Marcoussis cedex,
    France
    Phone : +33 1 6963 4723
    Email: emmanuel.dotaro@alcatel-lucent.fr
 
 12. 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
    this standard.  Please address the information to the IETF at ietf-
    ipr@ietf.org.
 
 13. 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.
 
 
 
 
                          Expires July 2008                 [Page 25]
 

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