GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3945

Network Working Group E. Mannie, Ed. Request for Comments: 3945 October 2004 Category: Standards Track

  Generalized Multi-Protocol Label Switching (GMPLS) Architecture

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 Future data and transmission networks will consist of elements such
 as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
 systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
 (PXCs), optical cross-connects (OXCs), etc. that will use Generalized
 Multi-Protocol Label Switching (GMPLS) to dynamically provision
 resources and to provide network survivability using protection and
 restoration techniques.
 This document describes the architecture of GMPLS.  GMPLS extends
 MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709),
 wavelength (lambdas), and spatial switching (e.g., incoming port or
 fiber to outgoing port or fiber).  The focus of GMPLS is on the
 control plane of these various layers since each of them can use
 physically diverse data or forwarding planes.  The intention is to
 cover both the signaling and the routing part of that control plane.

Mannie Standards Track [Page 1] RFC 3945 GMPLS Architecture October 2004

Table of Contents

 1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Acronyms & Abbreviations. . . . . . . . . . . . . . . .   4
     1.2.  Multiple Types of Switching and Forwarding Hierarchies.   5
     1.3.  Extension of the MPLS Control Plane . . . . . . . . . .   7
     1.4.  GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . .  10
 2.  Routing and Addressing Model. . . . . . . . . . . . . . . . .  11
     2.1.  Addressing of PSC and non-PSC layers. . . . . . . . . .  13
     2.2.  GMPLS Scalability Enhancements. . . . . . . . . . . . .  13
     2.3.  TE Extensions to IP Routing Protocols . . . . . . . . .  14
 3.  Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . .  15
     3.1.  Unnumbered Forwarding Adjacencies . . . . . . . . . . .  16
 4.  Link Bundling . . . . . . . . . . . . . . . . . . . . . . . .  16
     4.1.  Restrictions on Bundling. . . . . . . . . . . . . . . .  17
     4.2.  Routing Considerations for Bundling . . . . . . . . . .  17
     4.3.  Signaling Considerations. . . . . . . . . . . . . . . .  18
           4.3.1.  Mechanism 1: Implicit Indication. . . . . . . .  18
           4.3.2.  Mechanism 2: Explicit Indication by Numbered
                   Interface ID. . . . . . . . . . . . . . . . . .  19
           4.3.3.  Mechanism 3: Explicit Indication by Unnumbered
                   Interface ID. . . . . . . . . . . . . . . . . .  19
     4.4.  Unnumbered Bundled Link . . . . . . . . . . . . . . . .  19
     4.5.  Forming Bundled Links . . . . . . . . . . . . . . . . .  20
 5.  Relationship with the UNI . . . . . . . . . . . . . . . . . .  20
     5.1.  Relationship with the OIF UNI . . . . . . . . . . . . .  21
     5.2.  Reachability across the UNI . . . . . . . . . . . . . .  21
 6.  Link Management . . . . . . . . . . . . . . . . . . . . . . .  22
     6.1.  Control Channel and Control Channel Management. . . . .  23
     6.2.  Link Property Correlation . . . . . . . . . . . . . . .  24
     6.3.  Link Connectivity Verification. . . . . . . . . . . . .  24
     6.4.  Fault Management. . . . . . . . . . . . . . . . . . . .  25
     6.5.  LMP for DWDM Optical Line Systems (OLSs). . . . . . . .  26
 7.  Generalized Signaling . . . . . . . . . . . . . . . . . . . .  27
     7.1.  Overview: How to Request an LSP . . . . . . . . . . . .  29
     7.2.  Generalized Label Request . . . . . . . . . . . . . . .  30
     7.3.  SONET/SDH Traffic Parameters. . . . . . . . . . . . . .  31
     7.4.  G.709 Traffic Parameters. . . . . . . . . . . . . . . .  32
     7.5.  Bandwidth Encoding. . . . . . . . . . . . . . . . . . .  33
     7.6.  Generalized Label . . . . . . . . . . . . . . . . . . .  34
     7.7.  Waveband Switching. . . . . . . . . . . . . . . . . . .  34
     7.8.  Label Suggestion by the Upstream. . . . . . . . . . . .  35
     7.9.  Label Restriction by the Upstream . . . . . . . . . . .  35
     7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . .  36
     7.11. Bi-directional LSP Contention Resolution. . . . . . . .  37
     7.12. Rapid Notification of Failure . . . . . . . . . . . . .  37
     7.13. Link Protection . . . . . . . . . . . . . . . . . . . .  38
     7.14. Explicit Routing and Explicit Label Control . . . . . .  39

Mannie Standards Track [Page 2] RFC 3945 GMPLS Architecture October 2004

     7.15. Route Recording . . . . . . . . . . . . . . . . . . . .  40
     7.16. LSP Modification and LSP Re-routing . . . . . . . . . .  40
     7.17. LSP Administrative Status Handling. . . . . . . . . . .  41
     7.18. Control Channel Separation. . . . . . . . . . . . . . .  42
 8.  Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . .  43
     8.1.  Routing and Forwarding Adjacencies. . . . . . . . . . .  43
     8.2.  Signaling Aspects . . . . . . . . . . . . . . . . . . .  44
     8.3.  Cascading of Forwarding Adjacencies . . . . . . . . . .  44
 9.  Routing and Signaling Adjacencies . . . . . . . . . . . . . .  45
 10. Control Plane Fault Handling. . . . . . . . . . . . . . . . .  46
 11. LSP Protection and Restoration. . . . . . . . . . . . . . . .  47
     11.1. Protection Escalation across Domains and Layers . . . .  48
     11.2. Mapping of Services to P&R Resources. . . . . . . . . .  49
     11.3. Classification of P&R Mechanism Characteristics . . . .  49
     11.4. Different Stages in P&R . . . . . . . . . . . . . . . .  50
     11.5. Recovery Strategies . . . . . . . . . . . . . . . . . .  50
     11.6. Recovery mechanisms: Protection schemes . . . . . . . .  51
     11.7. Recovery mechanisms: Restoration schemes. . . . . . . .  52
     11.8. Schema Selection Criteria . . . . . . . . . . . . . . .  53
 12. Network Management. . . . . . . . . . . . . . . . . . . . . .  54
     12.1. Network Management Systems (NMS). . . . . . . . . . . .  55
     12.2. Management Information Base (MIB) . . . . . . . . . . .  55
     12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . .  56
     12.4. Fault Correlation Between Multiple Layers . . . . . . .  56
 13. Security Considerations . . . . . . . . . . . . . . . . . . .  57
 14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  58
 15. References. . . . . . . . . . . . . . . . . . . . . . . . . .  58
     15.1. Normative References. . . . . . . . . . . . . . . . . .  58
     15.2. Informative References. . . . . . . . . . . . . . . . .  59
 16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . .  63
 17. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  68
     Full Copyright Statement. . . . . . . . . . . . . . . . . . .  69

Mannie Standards Track [Page 3] RFC 3945 GMPLS Architecture October 2004

1. Introduction

 The architecture described in this document covers the main building
 blocks needed to build a consistent control plane for multiple
 switching layers.  It does not restrict the way that these layers
 work together.  Different models can be applied, e.g., overlay,
 augmented or integrated.  Moreover, each pair of contiguous layers
 may collaborate in different ways, resulting in a number of possible
 combinations, at the discretion of manufacturers and operators.
 This architecture clearly separates the control plane and the
 forwarding plane.  In addition, it also clearly separates the control
 plane in two parts, the signaling plane containing the signaling
 protocols and the routing plane containing the routing protocols.
 This document is a generalization of the Multi-Protocol Label
 Switching (MPLS) architecture [RFC3031], and in some cases may differ
 slightly from that architecture since non packet-based forwarding
 planes are now considered.  It is not the intention of this document
 to describe concepts already described in the current MPLS
 architecture.  The goal is to describe specific concepts of
 Generalized MPLS (GMPLS).
 However, some of the concepts explained hereafter are not part of the
 current MPLS architecture and are applicable to both MPLS and GMPLS
 (i.e., link bundling, unnumbered links, and LSP hierarchy). Since
 these concepts were introduced together with GMPLS and since they are
 of paramount importance for an operational GMPLS network, they will
 be discussed here.
 The organization of the remainder of this document is as follows.  We
 begin with an introduction of GMPLS.  We then present the specific
 GMPLS building blocks and explain how they can be combined together
 to build an operational GMPLS network.  Specific details of the
 separate building blocks can be found in the corresponding documents.

1.1. Acronyms & Abbreviations

 AS           Autonomous System
 BGP          Border Gateway Protocol
 CR-LDP       Constraint-based Routing LDP
 CSPF         Constraint-based Shortest Path First
 DWDM         Dense Wavelength Division Multiplexing
 FA           Forwarding Adjacency
 GMPLS        Generalized Multi-Protocol Label Switching
 IGP          Interior Gateway Protocol
 LDP          Label Distribution Protocol
 LMP          Link Management Protocol

Mannie Standards Track [Page 4] RFC 3945 GMPLS Architecture October 2004

 LSA          Link State Advertisement
 LSR          Label Switching Router
 LSP          Label Switched Path
 MIB          Management Information Base
 MPLS         Multi-Protocol Label Switching
 NMS          Network Management System
 OXC          Optical Cross-Connect
 PXC          Photonic Cross-Connect
 RSVP         ReSource reserVation Protocol
 SDH          Synchronous Digital Hierarchy
 SONET        Synchronous Optical Networks
 STM(-N)      Synchronous Transport Module (-N)
 STS(-N)      Synchronous Transport Signal-Level N (SONET)
 TDM          Time Division Multiplexing
 TE           Traffic Engineering

1.2. Multiple Types of Switching and Forwarding Hierarchies

 Generalized MPLS (GMPLS) differs from traditional MPLS in that it
 supports multiple types of switching, i.e., the addition of support
 for TDM, lambda, and fiber (port) switching.  The support for the
 additional types of switching has driven GMPLS to extend certain base
 functions of traditional MPLS and, in some cases, to add
 functionality.  These changes and additions impact basic LSP
 properties: how labels are requested and communicated, the
 unidirectional nature of LSPs, how errors are propagated, and
 information provided for synchronizing the ingress and egress LSRs.
 The MPLS architecture [RFC3031] was defined to support the forwarding
 of data based on a label.  In this architecture, Label Switching
 Routers (LSRs) were assumed to have a forwarding plane that is
 capable of (a) recognizing either packet or cell boundaries, and (b)
 being able to process either packet headers (for LSRs capable of
 recognizing packet boundaries) or cell headers (for LSRs capable of
 recognizing cell boundaries).
 The original MPLS architecture is here being extended to include LSRs
 whose forwarding plane recognizes neither packet, nor cell
 boundaries, and therefore, cannot forward data based on the
 information carried in either packet or cell headers.  Specifically,
 such LSRs include devices where the switching decision is based on
 time slots, wavelengths, or physical ports.  So, the new set of LSRs,
 or more precisely interfaces on these LSRs, can be subdivided into
 the following classes:

Mannie Standards Track [Page 5] RFC 3945 GMPLS Architecture October 2004

 1. Packet Switch Capable (PSC) interfaces:
    Interfaces that recognize packet boundaries and can forward data
    based on the content of the packet header.  Examples include
    interfaces on routers that forward data based on the content of
    the IP header and interfaces on routers that switch data based on
    the content of the MPLS "shim" header.
 2. Layer-2 Switch Capable (L2SC) interfaces:
    Interfaces that recognize frame/cell boundaries and can switch
    data based on the content of the frame/cell header.  Examples
    include interfaces on Ethernet bridges that switch data based on
    the content of the MAC header and interfaces on ATM-LSRs that
    forward data based on the ATM VPI/VCI.
 3. Time-Division Multiplex Capable (TDM) interfaces:
    Interfaces that switch data based on the data's time slot in a
    repeating cycle.  An example of such an interface is that of a
    SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-
    Drop Multiplexer (ADM).  Other examples include interfaces
    providing G.709 TDM capabilities (the "digital wrapper") and PDH
    interfaces.
 4. Lambda Switch Capable (LSC) interfaces:
    Interfaces that switch data based on the wavelength on which the
    data is received.  An example of such an interface is that of a
    Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that
    can operate at the level of an individual wavelength.  Additional
    examples include PXC interfaces that can operate at the level of a
    group of wavelengths, i.e., a waveband and G.709 interfaces
    providing optical capabilities.
 5. Fiber-Switch Capable (FSC) interfaces:
    Interfaces that switch data based on a position of the data in the
    (real world) physical spaces.  An example of such an interface is
    that of a PXC or OXC that can operate at the level of a single or
    multiple fibers.
 A circuit can be established only between, or through, interfaces of
 the same type.  Depending on the particular technology being used for
 each interface, different circuit names can be used, e.g., SDH
 circuit, optical trail, light-path, etc.  In the context of GMPLS,
 all these circuits are referenced by a common name: Label Switched
 Path (LSP).

Mannie Standards Track [Page 6] RFC 3945 GMPLS Architecture October 2004

 The concept of nested LSP (LSP within LSP), already available in the
 traditional MPLS, facilitates building a forwarding hierarchy, i.e.,
 a hierarchy of LSPs.  This hierarchy of LSPs can occur on the same
 interface, or between different interfaces.
 For example, a hierarchy can be built if an interface is capable of
 multiplexing several LSPs from the same technology (layer), e.g., a
 lower order SONET/SDH LSP (e.g., VT2/VC-12) nested in a higher order
 SONET/SDH LSP (e.g., STS-3c/VC-4).  Several levels of signal (LSP)
 nesting are defined in the SONET/SDH multiplexing hierarchy.
 The nesting can also occur between interface types.  At the top of
 the hierarchy are FSC interfaces, followed by LSC interfaces,
 followed by TDM interfaces, followed by L2SC, and followed by PSC
 interfaces.  This way, an LSP that starts and ends on a PSC interface
 can be nested (together with other LSPs) into an LSP that starts and
 ends on a L2SC interface.  This LSP, in turn, can be nested (together
 with other LSPs) into an LSP that starts and ends on a TDM interface.
 In turn, this LSP can be nested (together with other LSPs) into an
 LSP that starts and ends on a LSC interface, which in turn can be
 nested (together with other LSPs) into an LSP that starts and ends on
 a FSC interface.

1.3. Extension of the MPLS Control Plane

 The establishment of LSPs that span only Packet Switch Capable (PSC)
 or Layer-2 Switch Capable (L2SC) interfaces is defined for the
 original MPLS and/or MPLS-TE control planes.  GMPLS extends these
 control planes to support each of the five classes of interfaces
 (i.e., layers) defined in the previous section.
 Note that the GMPLS control plane supports an overlay model, an
 augmented model, and a peer (integrated) model.  In the near term,
 GMPLS appears to be very suitable for controlling each layer
 independently.  This elegant approach will facilitate the future
 deployment of other models.
 The GMPLS control plane is made of several building blocks as
 described in more details in the following sections.  These building
 blocks are based on well-known signaling and routing protocols that
 have been extended and/or modified to support GMPLS.  They use IPv4
 and/or IPv6 addresses.  Only one new specialized protocol is required
 to support the operations of GMPLS, a signaling protocol for link
 management [LMP].
 GMPLS is indeed based on the Traffic Engineering (TE) extensions to
 MPLS, a.k.a. MPLS-TE [RFC2702].  This, because most of the
 technologies that can be used below the PSC level requires some

Mannie Standards Track [Page 7] RFC 3945 GMPLS Architecture October 2004

 traffic engineering. The placement of LSPs at these levels needs in
 general to consider several constraints (such as framing, bandwidth,
 protection capability, etc) and to bypass the legacy Shortest-Path
 First (SPF) algorithm.  Note, however, that this is not mandatory and
 that in some cases SPF routing can be applied.
 In order to facilitate constrained-based SPF routing of LSPs, nodes
 that perform LSP establishment need more information about the links
 in the network than standard intra-domain routing protocols provide.
 These TE attributes are distributed using the transport mechanisms
 already available in IGPs (e.g., flooding) and taken into
 consideration by the LSP routing algorithm.  Optimization of the LSP
 routes may also require some external simulations using heuristics
 that serve as input for the actual path calculation and LSP
 establishment process.
 By definition, a TE link is a representation in the IS-IS/OSPF Link
 State advertisements and in the link state database of certain
 physical resources, and their properties, between two GMPLS nodes.
 TE Links are used by the GMPLS control plane (routing and signaling)
 for establishing LSPs.
 Extensions to traditional routing protocols and algorithms are needed
 to uniformly encode and carry TE link information, and explicit
 routes (e.g., source routes) are required in the signaling. In
 addition, the signaling must now be capable of transporting the
 required circuit (LSP) parameters such as the bandwidth, the type of
 signal, the desired protection and/or restoration, the position in a
 particular multiplex, etc.  Most of these extensions have already
 been defined for PSC and L2SC traffic engineering with MPLS.  GMPLS
 primarily defines additional extensions for TDM, LSC, and FSC traffic
 engineering.  A very few elements are technology specific.
 Thus, GMPLS extends the two signaling protocols defined for MPLS-TE
 signaling, i.e., RSVP-TE [RFC3209] and CR-LDP [RFC3212].  However,
 GMPLS does not specify which one of these two signaling protocols
 must be used.  It is the role of manufacturers and operators to
 evaluate the two possible solutions for their own interest.
 Since GMPLS signaling is based on RSVP-TE and CR-LDP, it mandates a
 downstream-on-demand label allocation and distribution, with ingress
 initiated ordered control.  Liberal label retention is normally used,
 but conservative label retention mode could also be used.

Mannie Standards Track [Page 8] RFC 3945 GMPLS Architecture October 2004

 Furthermore, there is no restriction on the label allocation
 strategy, it can be request/signaling driven (obvious for circuit
 switching technologies), traffic/data driven, or even topology
 driven.  There is also no restriction on the route selection;
 explicit routing is normally used (strict or loose) but hop-by-hop
 routing could be used as well.
 GMPLS also extends two traditional intra-domain link-state routing
 protocols already extended for TE purposes, i.e., OSPF-TE [OSPF-TE]
 and IS-IS-TE [ISIS-TE].  However, if explicit (source) routing is
 used, the routing algorithms used by these protocols no longer need
 to be standardized.  Extensions for inter-domain routing (e.g., BGP)
 are for further study.
 The use of technologies like DWDM (Dense Wavelength Division
 Multiplexing) implies that we can now have a very large number of
 parallel links between two directly adjacent nodes (hundreds of
 wavelengths, or even thousands of wavelengths if multiple fibers are
 used).  Such a large number of links was not originally considered
 for an IP or MPLS control plane, although it could be done.  Some
 slight adaptations of that control plane are thus required if we want
 to better reuse it in the GMPLS context.
 For instance, the traditional IP routing model assumes the
 establishment of a routing adjacency over each link connecting two
 adjacent nodes.  Having such a large number of adjacencies does not
 scale well.  Each node needs to maintain each of its adjacencies one
 by one, and link state routing information must be flooded throughout
 the network.
 To solve this issue the concept of link bundling was introduced.
 Moreover, the manual configuration and control of these links, even
 if they are unnumbered, becomes impractical.  The Link Management
 Protocol (LMP) was specified to solve these issues.
 LMP runs between data plane adjacent nodes and is used to manage TE
 links.  Specifically, LMP provides mechanisms to maintain control
 channel connectivity (IP Control Channel Maintenance), verify the
 physical connectivity of the data-bearing links (Link Verification),
 correlate the link property information (Link Property Correlation),
 and manage link failures (Fault Localization and Fault Notification).
 A unique feature of LMP is that it is able to localize faults in both
 opaque and transparent networks (i.e., independent of the encoding
 scheme and bit rate used for the data).
 LMP is defined in the context of GMPLS, but is specified
 independently of the GMPLS signaling specification since it is a
 local protocol running between data-plane adjacent nodes.

Mannie Standards Track [Page 9] RFC 3945 GMPLS Architecture October 2004

 Consequently, LMP can be used in other contexts with non-GMPLS
 signaling protocols.
 MPLS signaling and routing protocols require at least one bi-
 directional control channel to communicate even if two adjacent nodes
 are connected by unidirectional links.  Several control channels can
 be used.  LMP can be used to establish, maintain and manage these
 control channels.
 GMPLS does not specify how these control channels must be
 implemented, but GMPLS requires IP to transport the signaling and
 routing protocols over them.  Control channels can be either in-band
 or out-of-band, and several solutions can be used to carry IP.  Note
 also that one type of LMP message (the Test message) is used in-band
 in the data plane and may not be transported over IP, but this is a
 particular case, needed to verify connectivity in the data plane.

1.4. GMPLS Key Extensions to MPLS-TE

 Some key extensions brought by GMPLS to MPLS-TE are highlighted in
 the following.  Some of them are key advantages of GMPLS to control
 TDM, LSC and FSC layers.
  1. In MPLS-TE, links traversed by an LSP can include an intermix of

links with heterogeneous label encoding (e.g., links between

    routers, links between routers and ATM-LSRs, and links between
    ATM-LSRs. GMPLS extends this by including links where the label is
    encoded as a time slot, or a wavelength, or a position in the
    (real world) physical space.
  1. In MPLS-TE, an LSP that carries IP has to start and end on a

router. GMPLS extends this by requiring an LSP to start and end

    on similar type of interfaces.
  1. The type of a payload that can be carried in GMPLS by an LSP is

extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb

    Ethernet, etc.
  1. The use of Forwarding Adjacencies (FA) provides a mechanism that

can improve bandwidth utilization, when bandwidth allocation can

    be performed only in discrete units.  It offers also a mechanism
    to aggregate forwarding state, thus allowing the number of
    required labels to be reduced.

Mannie Standards Track [Page 10] RFC 3945 GMPLS Architecture October 2004

  1. GMPLS allows suggesting a label by an upstream node to reduce the

setup latency. This suggestion may be overridden by a downstream

    node but in some cases, at the cost of higher LSP setup time.
  1. GMPLS extends on the notion of restricting the range of labels

that may be selected by a downstream node. In GMPLS, an upstream

    node may restrict the labels for an LSP along either a single hop
    or the entire LSP path.  This feature is useful in photonic
    networks where wavelength conversion may not be available.
  1. While traditional TE-based (and even LDP-based) LSPs are

unidirectional, GMPLS supports the establishment of bi-directional

    LSPs.
  1. GMPLS supports the termination of an LSP on a specific egress

port, i.e., the port selection at the destination side.

  1. GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid

failure notification.

 Note also some other key differences between MPLS-TE and GMPLS:
  1. For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP

can be performed only in discrete units.

  1. It is expected to have (much) fewer labels on TDM, LSC or FSC

links than on PSC or L2SC links, because the former are physical

    labels instead of logical labels.

2. Routing and Addressing Model

 GMPLS is based on the IP routing and addressing models.  This assumes
 that IPv4 and/or IPv6 addresses are used to identify interfaces but
 also that traditional (distributed) IP routing protocols are reused.
 Indeed, the discovery of the topology and the resource state of all
 links in a routing domain is achieved via these routing protocols.
 Since control and data planes are de-coupled in GMPLS, control-plane
 neighbors (i.e., IGP-learnt neighbors) may not be data-plane
 neighbors.  Hence, mechanisms like LMP are needed to associate TE
 links with neighboring nodes.
 IP addresses are not used only to identify interfaces of IP hosts and
 routers, but more generally to identify any PSC and non-PSC
 interfaces.  Similarly, IP routing protocols are used to find routes
 for IP datagrams with a SPF algorithm; they are also used to find
 routes for non-PSC circuits by using a CSPF algorithm.

Mannie Standards Track [Page 11] RFC 3945 GMPLS Architecture October 2004

 However, some additional mechanisms are needed to increase the
 scalability of these models and to deal with specific traffic
 engineering requirements of non-PSC layers.  These mechanisms will be
 introduced in the following.
 Re-using existing IP routing protocols allows for non-PSC layers
 taking advantage of all the valuable developments that took place
 since years for IP routing, in particular, in the context of intra-
 domain routing (link-state routing) and inter-domain routing (policy
 routing).
 In an overlay model, each particular non-PSC layer can be seen as a
 set of Autonomous Systems (ASs) interconnected in an arbitrary way.
 Similarly to the traditional IP routing, each AS is managed by a
 single administrative authority.  For instance, an AS can be an
 SONET/SDH network operated by a given carrier.  The set of
 interconnected ASs can be viewed as SONET/SDH internetworks.
 Exchange of routing information between ASs can be done via an
 inter-domain routing protocol like BGP-4.  There is obviously a huge
 value of re-using well-known policy routing facilities provided by
 BGP in a non-PSC context.  Extensions for BGP traffic engineering
 (BGP-TE) in the context of non-PSC layers are left for further study.
 Each AS can be sub-divided in different routing domains, and each can
 run a different intra-domain routing protocol.  In turn, each
 routing-domain can be divided in areas.
 A routing domain is made of GMPLS enabled nodes (i.e., a network
 device including a GMPLS entity).  These nodes can be either edge
 nodes (i.e., hosts, ingress LSRs or egress LSRs), or internal LSRs.
 An example of non-PSC host is an SONET/SDH Terminal Multiplexer (TM).
 Another example is an SONET/SDH interface card within an IP router or
 ATM switch.
 Note that traffic engineering in the intra-domain requires the use of
 link-state routing protocols like OSPF or IS-IS.
 GMPLS defines extensions to these protocols.  These extensions are
 needed to disseminate specific TDM, LSC and FSC static and dynamic
 characteristics related to nodes and links.  The current focus is on

Mannie Standards Track [Page 12] RFC 3945 GMPLS Architecture October 2004

 intra-area traffic engineering.  However, inter-area traffic
 engineering is also under investigation.

2.1. Addressing of PSC and non-PSC Layers

 The fact that IPv4 and/or IPv6 addresses are used does not imply at
 all that they should be allocated in the same addressing space than
 public IPv4 and/or IPv6 addresses used for the Internet.  Private IP
 addresses can be used if they do not require to be exchanged with any
 other operator; public IP addresses are otherwise required.  Of
 course, if an integrated model is used, two layers could share the
 same addressing space.  Finally, TE links may be "unnumbered" i.e.,
 not have any IP addresses, in case IP addresses are not available, or
 the overhead of managing them is considered too high.
 Note that there is a benefit of using public IPv4 and/or IPv6
 Internet addresses for non-PSC layers if an integrated model with the
 IP layer is foreseen.
 If we consider the scalability enhancements proposed in the next
 section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing spaces
 are both more than sufficient to accommodate any non-PSC layer.  We
 can reasonably expect to have much less non-PSC devices (e.g.,
 SONET/SDH nodes) than we have today IP hosts and routers.

2.2. GMPLS Scalability Enhancements

 TDM, LSC and FSC layers introduce new constraints on the IP
 addressing and routing models since several hundreds of parallel
 physical links (e.g., wavelengths) can now connect two nodes.  Most
 of the carriers already have today several tens of wavelengths per
 fiber between two nodes.  New generation of DWDM systems will allow
 several hundreds of wavelengths per fiber.
 It becomes rather impractical to associate an IP address with each
 end of each physical link, to represent each link as a separate
 routing adjacency, and to advertise and to maintain link states for
 each of these links.  For that purpose, GMPLS enhances the MPLS
 routing and addressing models to increase their scalability.
 Two optional mechanisms can be used to increase the scalability of
 the addressing and the routing: unnumbered links and link bundling.
 These two mechanisms can also be combined.  They require extensions
 to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE)
 protocols.

Mannie Standards Track [Page 13] RFC 3945 GMPLS Architecture October 2004

2.3. TE Extensions to IP Routing Protocols

 Traditionally, a TE link is advertised as an adjunct to a "regular"
 OSPF or IS-IS link, i.e., an adjacency is brought up on the link.
 When the link is up, both the regular IGP properties of the link
 (basically, the SPF metric) and the TE properties of the link are
 then advertised.
 However, GMPLS challenges this notion in three ways:
  1. First, links that are non-PSC may yet have TE properties; however,

an OSPF adjacency could not be brought up directly on such links.

  1. Second, an LSP can be advertised as a point-to-point TE link in

the routing protocol, i.e., as a Forwarding Adjacency (FA); thus,

    an advertised TE link need no longer be between two OSPF direct
    neighbors.  Forwarding Adjacencies (FA) are further described in
    Section 8.
  1. Third, a number of links may be advertised as a single TE link

(e.g., for improved scalability), so again, there is no longer a

    one-to-one association of a regular adjacency and a TE link.
 Thus, we have a more general notion of a TE link.  A TE link is a
 logical link that has TE properties.  Some of these properties may be
 configured on the advertising LSR, others may be obtained from other
 LSRs by means of some protocol, and yet others may be deduced from
 the component(s) of the TE link.
 An important TE property of a TE link is related to the bandwidth
 accounting for that link.  GMPLS will define different accounting
 rules for different non-PSC layers.  Generic bandwidth attributes are
 however defined by the TE routing extensions and by GMPLS, such as
 the unreserved bandwidth, the maximum reservable bandwidth and the
 maximum LSP bandwidth.
 It is expected in a dynamic environment to have frequent changes of
 bandwidth accounting information.  A flexible policy for triggering
 link state updates based on bandwidth thresholds and link-dampening
 mechanism can be implemented.
 TE properties associated with a link should also capture protection
 and restoration related characteristics.  For instance, shared
 protection can be elegantly combined with bundling.  Protection and
 restoration are mainly generic mechanisms also applicable to MPLS. It
 is expected that they will first be developed for MPLS and later on
 generalized to GMPLS.

Mannie Standards Track [Page 14] RFC 3945 GMPLS Architecture October 2004

 A TE link between a pair of LSRs does not imply the existence of an
 IGP adjacency between these LSRs.  A TE link must also have some
 means by which the advertising LSR can know of its liveness (e.g., by
 using LMP hellos).  When an LSR knows that a TE link is up, and can
 determine the TE link's TE properties, the LSR may then advertise
 that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE
 objects/TLVs.  We call the interfaces over which GMPLS enhanced OSPF
 or IS-IS adjacencies are established "control channels".

3. Unnumbered Links

 Unnumbered links (or interfaces) are links (or interfaces) that do
 not have IP addresses.  Using such links involves two capabilities:
 the ability to specify unnumbered links in MPLS TE signaling, and the
 ability to carry (TE) information about unnumbered links in IGP TE
 extensions of IS-IS-TE and OSPF-TE.
 A. The ability to specify unnumbered links in MPLS TE signaling
    requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480].
    The MPLS-TE signaling does not provide support for unnumbered
    links, because it does not provide a way to indicate an unnumbered
    link in its Explicit Route Object/TLV and in its Record Route
    Object (there is no such TLV for CR-LDP).  GMPLS defines simple
    extensions to indicate an unnumbered link in these two
    Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub-
    TLV.
    Since unnumbered links are not identified by an IP address, then
    for the purpose of MPLS TE each end need some other identifier,
    local to the LSR to which the link belongs.  LSRs at the two end-
    points of an unnumbered link exchange with each other the
    identifiers they assign to the link.  Exchanging the identifiers
    may be accomplished by configuration, by means of a protocol such
    as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially in the case
    where a link is a Forwarding Adjacency, see below), or by means of
    IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]).
    Consider an (unnumbered) link between LSRs A and B.  LSR A chooses
    an identifier for that link.  So does LSR B.  From A's perspective
    we refer to the identifier that A assigned to the link as the
    "link local identifier" (or just "local identifier"), and to the
    identifier that B assigned to the link as the "link remote
    identifier" (or just "remote identifier").  Likewise, from B's
    perspective the identifier that B assigned to the link is the
    local identifier, and the identifier that A assigned to the link
    is the remote identifier.

Mannie Standards Track [Page 15] RFC 3945 GMPLS Architecture October 2004

    The new Unnumbered Interface ID sub-object/sub-TLV for the ER
    Object/TLV contains the Router ID of the LSR at the upstream end
    of the unnumbered link and the link local identifier with respect
    to that upstream LSR.
    The new Unnumbered Interface ID sub-object for the RR Object
    contains the link local identifier with respect to the LSR that
    adds it in the RR Object.
 B. The ability to carry (TE) information about unnumbered links in
    IGP TE extensions requires new sub-TLVs for the extended IS
    reachability TLV defined in IS-IS-TE and for the TE LSA (which is
    an opaque LSA) defined in OSPF-TE.  A Link Local Identifier sub-
    TLV and a Link Remote Identifier sub-TLV are defined.

3.1. Unnumbered Forwarding Adjacencies

 If an LSR that originates an LSP advertises this LSP as an unnumbered
 FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered
 component link of a bundled link, the LSR must allocate an Interface
 ID to that FA.  If the LSP is bi-directional, the tail end does the
 same and allocates an Interface ID to the reverse FA.
 Signaling has been enhanced to carry the Interface ID of a FA in the
 new LSP Tunnel Interface ID object/TLV.  This object/TLV contains the
 Router ID (of the LSR that generates it) and the Interface ID.  It is
 called the Forward Interface ID when it appears in a Path/REQUEST
 message, and it is called the Reverse Interface ID when it appears in
 the Resv/MAPPING message.

4. Link Bundling

 The concept of link bundling is essential in certain networks
 employing the GMPLS control plane as is defined in [BUNDLE].  A
 typical example is an optical meshed network where adjacent optical
 cross-connects (LSRs) are connected by several hundreds of parallel
 wavelengths.  In this network, consider the application of link state
 routing protocols, like OSPF or IS-IS, with suitable extensions for
 resource discovery and dynamic route computation.  Each wavelength
 must be advertised separately to be used, except if link bundling is
 used.
 When a pair of LSRs is connected by multiple links, it is possible to
 advertise several (or all) of these links as a single link into OSPF
 and/or IS-IS.  This process is called link bundling, or just
 bundling.  The resulting logical link is called a bundled link as its
 physical links are called component links (and are identified by
 interface indexes).

Mannie Standards Track [Page 16] RFC 3945 GMPLS Architecture October 2004

 The result is that a combination of three identifiers ((bundled) link
 identifier, component link identifier, label) is sufficient to
 unambiguously identify the appropriate resources used by an LSP.
 The purpose of link bundling is to improve routing scalability by
 reducing the amount of information that has to be handled by OSPF
 and/or IS-IS.  This reduction is accomplished by performing
 information aggregation/abstraction.  As with any other information
 aggregation/abstraction, this results in losing some of the
 information.  To limit the amount of losses one need to restrict the
 type of the information that can be aggregated/abstracted.

4.1. Restrictions on Bundling

 The following restrictions are required for bundling links.  All
 component links in a bundle must begin and end on the same pair of
 LSRs; and share some common characteristics or properties defined in
 [OSPF-TE] and [ISIS-TE], i.e., they must have the same:
  1. Link Type (i.e., point-to-point or multi-access),
  2. TE Metric (i.e., an administrative cost),
  3. Set of Resource Classes at each end of the links (i.e., colors).
 Note that a FA may also be a component link.  In fact, a bundle can
 consist of a mix of point-to-point links and FAs, but all sharing
 some common properties.

4.2. Routing Considerations for Bundling

 A bundled link is just another kind of TE link such as those defined
 by [GMPLS-ROUTING].  The liveness of the bundled link is determined
 by the liveness of each its component links.  A bundled link is alive
 when at least one of its component links is alive.  The liveness of a
 component link can be determined by any of several means: IS-IS or
 OSPF hellos over the component link, or RSVP Hello (hop local), or
 LMP hellos (link local), or from layer 1 or layer 2 indications.
 Note that (according to the RSVP-TE specification [RFC3209]) the RSVP
 Hello mechanism is intended to be used when notification of link
 layer failures is not available and unnumbered links are not used, or
 when the failure detection mechanisms provided by the link layer are
 not sufficient for timely node failure detection.
 Once a bundled link is determined to be alive, it can be advertised
 as a TE link and the TE information can be flooded.  If IS-IS/OSPF
 hellos are run over the component links, IS-IS/OSPF flooding can be
 restricted to just one of the component links.

Mannie Standards Track [Page 17] RFC 3945 GMPLS Architecture October 2004

 Note that advertising a (bundled) TE link between a pair of LSRs does
 not imply that there is an IGP adjacency between these LSRs that is
 associated with just that link.  In fact, in certain cases a TE link
 between a pair of LSRs could be advertised even if there is no IGP
 adjacency at all between the LSR (e.g., when the TE link is an FA).
 Forming a bundled link consist in aggregating the identical TE
 parameters of each individual component link to produce aggregated TE
 parameters.  A TE link as defined by [GMPLS-ROUTING] has many
 parameters; adequate aggregation rules must be defined for each one.
 Some parameters can be sums of component characteristics such as the
 unreserved bandwidth and the maximum reservable bandwidth.  Bandwidth
 information is an important part of a bundle advertisement and it
 must be clearly defined since an abstraction is done.
 A GMPLS node with bundled links must apply admission control on a
 per-component link basis.

4.3. Signaling Considerations

 Typically, an LSP's explicit route (e.g., contained in an explicit
 route Object/TLV) will choose the bundled link to be used for the
 LSP, but not the component link(s).  This because information about
 the bundled link is flooded but information about the component links
 is not.
 The choice of the component link to use is always made by an upstream
 node.  If the LSP is bi-directional, the upstream node chooses a
 component link in each direction.
 Three mechanisms for indicating this choice to the downstream node
 are possible.

4.3.1. Mechanism 1: Implicit Indication

 This mechanism requires that each component link has a dedicated
 signaling channel (e.g., the link is a Sonet/SDH link using the DCC
 for in-band signaling).  The upstream node tells the receiver which
 component link to use by sending the message over the chosen
 component link's dedicated signaling channel.  Note that this
 signaling channel can be in-band or out-of-band.  In this last case,
 the association between the signaling channel and that component link
 need to be explicitly configured.

Mannie Standards Track [Page 18] RFC 3945 GMPLS Architecture October 2004

4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID

 This mechanism requires that the component link has a unique remote
 IP address.  The upstream node indicates the choice of the component
 link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying
 either an IPv4 or an IPv6 address in the Path/Label Request message
 (see [RFC3473]/[RFC3472], respectively).  For a bi-directional LSP, a
 component link is provided for each direction by the upstream node.
 This mechanism does not require each component link to have its own
 control channel.  In fact, it does not even require the whole
 (bundled) link to have its own control channel.

4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID

 With this mechanism, each component link that is unnumbered is
 assigned a unique Interface Identifier (32 bits value).  The upstream
 node indicates the choice of the component link by including a new
 IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message
 (see [RFC3473]/[RFC3472], respectively).
 This object/TLV carries the component interface ID in the downstream
 direction for a unidirectional LSP, and in addition, the component
 interface ID in the upstream direction for a bi-directional LSP.
 The two LSRs at each end of the bundled link exchange these
 identifiers.  Exchanging the identifiers may be accomplished by
 configuration, by means of a protocol such as LMP (preferred
 solution), by means of RSVP-TE/CR-LDP (especially in the case where a
 component link is a Forwarding Adjacency), or by means of IS-IS or
 OSPF extensions.
 This mechanism does not require each component link to have its own
 control channel.  In fact, it does not even require the whole
 (bundled) link to have its own control channel.

4.4. Unnumbered Bundled Link

 A bundled link may itself be numbered or unnumbered independent of
 whether the component links are numbered or not.  This affects how
 the bundled link is advertised in IS-IS/OSPF and the format of LSP
 EROs that traverse the bundled link.  Furthermore, unnumbered
 Interface Identifiers for all unnumbered outgoing links of a given
 LSR (whether component links, Forwarding Adjacencies or bundled
 links) must be unique in the context of that LSR.

Mannie Standards Track [Page 19] RFC 3945 GMPLS Architecture October 2004

4.5. Forming Bundled Links

 The generic rule for bundling component links is to place those links
 that are correlated in some manner in the same bundle.  If links may
 be correlated based on multiple properties then the bundling may be
 applied sequentially based on these properties.  For instance, links
 may be first grouped based on the first property. Each of these
 groups may be then divided into smaller groups based on the second
 property and so on.  The main principle followed in this process is
 that the properties of the resulting bundles should be concisely
 summarizable.  Link bundling may be done automatically or by
 configuration.  Automatic link bundling can apply bundling rules
 sequentially to produce bundles.
 For instance, the first property on which component links may be
 correlated could be the Interface Switching Capability
 [GMPLS-ROUTING], the second property could be the Encoding
 [GMPLS-ROUTING], the third property could be the Administrative
 Weight (cost), the fourth property could be the Resource Classes and
 finally links may be correlated based on other metrics such as SRLG
 (Shared Risk Link Groups).
 When routing an alternate path for protection purposes, the general
 principle followed is that the alternate path is not routed over any
 link belonging to an SRLG that belongs to some link of the primary
 path.  Thus, the rule to be followed is to group links belonging to
 exactly the same set of SRLGs.
 This type of sequential sub-division may result in a number of
 bundles between two adjacent nodes.  In practice, however, the link
 properties may not be very heterogeneous among component links
 between two adjacent nodes.  Thus, the number of bundles in practice
 may not be large.

5. Relationship with the UNI

 The interface between an edge GMPLS node and a GMPLS LSR on the
 network side may be referred to as a User to Network Interface (UNI),
 while the interface between two-network side LSRs may be referred to
 as a Network to Network Interface (NNI).
 GMPLS does not specify separately a UNI and an NNI.  Edge nodes are
 connected to LSRs on the network side, and these LSRs are in turn
 connected between them.  Of course, the behavior of an edge node is
 not exactly the same as the behavior of an LSR on the network side.
 Note also, that an edge node may run a routing protocol, however it
 is expected that in most of the cases it will not (see also section
 5.2 and the section about signaling with an explicit route).

Mannie Standards Track [Page 20] RFC 3945 GMPLS Architecture October 2004

 Conceptually, a difference between UNI and NNI make sense either if
 both interface uses completely different protocols, or if they use
 the same protocols but with some outstanding differences.  In the
 first case, separate protocols are often defined successively, with
 more or less success.
 The GMPLS approach consisted in building a consistent model from day
 one, considering both the UNI and NNI interfaces at the same time
 [GMPLS-OVERLAY].  For that purpose, a very few specific UNI
 particularities have been ignored in a first time.  GMPLS has been
 enhanced to support such particularities at the UNI by some other
 standardization bodies (see hereafter).

5.1. Relationship with the OIF UNI

 This section is only given for reference to the OIF work related to
 GMPLS.  The current OIF UNI specification [OIF-UNI] defines an
 interface between a client SONET/SDH equipment and an SONET/SDH
 network, each belonging to a distinct administrative authority.  It
 is designed for an overlay model.  The OIF UNI defines additional
 mechanisms on the top of GMPLS for the UNI.
 For instance, the OIF service discovery procedure is a precursor to
 obtaining UNI services.  Service discovery allows a client to
 determine the static parameters of the interconnection with the
 network, including the UNI signaling protocol, the type of
 concatenation, the transparency level as well as the type of
 diversity (node, link, SRLG) supported by the network.
 Since the current OIF UNI interface does not cover photonic networks,
 G.709 Digital Wrapper, etc, it is from that perspective a subset of
 the GMPLS Architecture at the UNI.

5.2. Reachability across the UNI

 This section discusses the selection of an explicit route by an edge
 node.  The selection of the first LSR by an edge node connected to
 multiple LSRs is part of that problem.
 An edge node (host or LSR) can participate more or less deeply in the
 GMPLS routing.  Four different routing models can be supported at the
 UNI: configuration based, partial peering, silent listening and full
 peering.
  1. Configuration based: this routing model requires the manual or

automatic configuration of an edge node with a list of neighbor

    LSRs sorted by preference order.  Automatic configuration can be
    achieved using DHCP for instance.  No routing information is

Mannie Standards Track [Page 21] RFC 3945 GMPLS Architecture October 2004

    exchanged at the UNI, except maybe the ordered list of LSRs.  The
    only routing information used by the edge node is that list.  The
    edge node sends by default an LSP request to the preferred LSR.
    ICMP redirects could be send by this LSR to redirect some LSP
    requests to another LSR connected to the edge node.  GMPLS does
    not preclude that model.
  1. Partial peering: limited routing information (mainly reachability)

can be exchanged across the UNI using some extensions in the

    signaling plane.  The reachability information exchanged at the
    UNI may be used to initiate edge node specific routing decision
    over the network.  GMPLS does not have any capability to support
    this model today.
  1. Silent listening: the edge node can silently listen to routing

protocols and take routing decisions based on the information

    obtained.  An edge node receives the full routing information,
    including traffic engineering extensions.  One LSR should forward
    transparently all routing PDUs to the edge node.  An edge node can
    now compute a complete explicit route taking into consideration
    all the end-to-end routing information.  GMPLS does not preclude
    this model.
  1. Full peering: in addition to silent listening, the edge node

participates within the routing, establish adjacencies with its

    neighbors and advertises LSAs.  This is useful only if there are
    benefits for edge nodes to advertise themselves traffic
    engineering information.  GMPLS does not preclude this model.

6. Link Management

 In the context of GMPLS, a pair of nodes (e.g., a photonic switch)
 may be connected by tens of fibers, and each fiber may be used to
 transmit hundreds of wavelengths if DWDM is used.  Multiple fibers
 and/or multiple wavelengths may also be combined into one or more
 bundled links for routing purposes.  Furthermore, to enable
 communication between nodes for routing, signaling, and link
 management, control channels must be established between a node pair.
 Link management is a collection of useful procedures between adjacent
 nodes that provide local services such as control channel management,
 link connectivity verification, link property correlation, and fault
 management.  The Link Management Protocol (LMP) [LMP] has been
 defined to fulfill these operations.  LMP has been initiated in the
 context of GMPLS but is a generic toolbox that can be also used in
 other contexts.

Mannie Standards Track [Page 22] RFC 3945 GMPLS Architecture October 2004

 In GMPLS, the control channels between two adjacent nodes are no
 longer required to use the same physical medium as the data links
 between those nodes.  Moreover, the control channels that are used to
 exchange the GMPLS control-plane information exist independently of
 the links they manage.  Hence, LMP was designed to manage the data
 links, independently of the termination capabilities of those data
 links.
 Control channel management and link property correlation procedures
 are mandatory per LMP.  Link connectivity verification and fault
 management procedures are optional.

6.1. Control Channel and Control Channel Management

 LMP control channel management is used to establish and maintain
 control channels between nodes.  Control channels exist independently
 of TE links, and can be used to exchange MPLS control-plane
 information such as signaling, routing, and link management
 information.
 An "LMP adjacency" is formed between two nodes that support the same
 LMP capabilities.  Multiple control channels may be active
 simultaneously for each adjacency.  A control channel can be either
 explicitly configured or automatically selected, however, LMP
 currently assume that control channels are explicitly configured
 while the configuration of the control channel capabilities can be
 dynamically negotiated.
 For the purposes of LMP, the exact implementation of the control
 channel is left unspecified.  The control channel(s) between two
 adjacent nodes is no longer required to use the same physical medium
 as the data-bearing links between those nodes.  For example, a
 control channel could use a separate wavelength or fiber, an Ethernet
 link, or an IP tunnel through a separate management network.
 A consequence of allowing the control channel(s) between two nodes to
 be physically diverse from the associated data-bearing links is that
 the health of a control channel does not necessarily correlate to the
 health of the data-bearing links, and vice-versa.  Therefore, new
 mechanisms have been developed in LMP to manage links, both in terms
 of link provisioning and fault isolation.
 LMP does not specify the signaling transport mechanism used in the
 control channel, however it states that messages transported over a
 control channel must be IP encoded.  Furthermore, since the messages
 are IP encoded, the link level encoding is not part of LMP.  A 32-bit
 non-zero integer Control Channel Identifier (CCId) is assigned to
 each direction of a control channel.

Mannie Standards Track [Page 23] RFC 3945 GMPLS Architecture October 2004

 Each control channel individually negotiates its control channel
 parameters and maintains connectivity using a fast Hello protocol.
 The latter is required if lower-level mechanisms are not available to
 detect link failures.
 The Hello protocol of LMP is intended to be a lightweight keep-alive
 mechanism that will react to control channel failures rapidly so that
 IGP Hellos are not lost and the associated link-state adjacencies are
 not removed uselessly.
 The Hello protocol consists of two phases: a negotiation phase and a
 keep-alive phase.  The negotiation phase allows negotiation of some
 basic Hello protocol parameters, like the Hello frequency.  The
 keep-alive phase consists of a fast lightweight bi-directional Hello
 message exchange.
 If a group of control channels share a common node pair and support
 the same LMP capabilities, then LMP control channel messages (except
 Configuration messages, and Hello's) may be transmitted over any of
 the active control channels without coordination between the local
 and remote nodes.
 For LMP, it is essential that at least one control channel is always
 available.  In case of control channel failure, it may be possible to
 use an alternate active control channel without coordination.

6.2. Link Property Correlation

 As part of LMP, a link property correlation exchange is defined. The
 exchange is used to aggregate multiple data-bearing links (i.e.,
 component links) into a bundled link and exchange, correlate, or
 change TE link parameters.  The link property correlation exchange
 may be done at any time a link is up and not in the Verification
 process (see next section).
 It allows, for instance, the addition of component links to a link
 bundle, change of a link's minimum/maximum reservable bandwidth,
 change of port identifiers, or change of component identifiers in a
 bundle.  This mechanism is supported by an exchange of link summary
 messages.

6.3. Link Connectivity Verification

 Link connectivity verification is an optional procedure that may be
 used to verify the physical connectivity of data-bearing links as
 well as to exchange the link identifiers that are used in the GMPLS
 signaling.

Mannie Standards Track [Page 24] RFC 3945 GMPLS Architecture October 2004

 This procedure should be performed initially when a data-bearing link
 is first established, and subsequently, on a periodic basis for all
 unallocated (free) data-bearing links.
 The verification procedure consists of sending Test messages in-band
 over the data-bearing links.  This requires that the unallocated
 links must be opaque; however, multiple degrees of opaqueness (e.g.,
 examining overhead bytes, terminating the payload, etc.), and hence
 different mechanisms to transport the Test messages, are specified.
 Note that the Test message is the only LMP message that is
 transmitted over the data-bearing link, and that Hello messages
 continue to be exchanged over the control channel during the link
 verification process.  Data-bearing links are tested in the transmit
 direction as they are unidirectional.  As such, it is possible for
 LMP neighboring nodes to exchange the Test messages simultaneously in
 both directions.
 To initiate the link verification procedure, a node must first notify
 the adjacent node that it will begin sending Test messages over a
 particular data-bearing link, or over the component links of a
 particular bundled link.  The node must also indicate the number of
 data-bearing links that are to be verified; the interval at which the
 test messages will be sent; the encoding scheme, the transport
 mechanisms that are supported, the data rate for Test messages; and,
 in the case where the data-bearing links correspond to fibers, the
 wavelength over which the Test messages will be transmitted.
 Furthermore, the local and remote bundled link identifiers are
 transmitted at this time to perform the component link association
 with the bundled link identifiers.

6.4. Fault Management

 Fault management is an important requirement from the operational
 point of view.  Fault management includes usually: fault detection,
 fault localization and fault notification.  When a failure occurs and
 is detected (fault detection), an operator needs to know exactly
 where it happened (fault localization) and a source node may need to
 be notified in order to take some actions (fault notification).
 Note that fault localization can also be used to support some
 specific (local) protection/restoration mechanisms.
 In new technologies such as transparent photonic switching currently
 no method is defined to locate a fault, and the mechanism by which
 the fault information is propagated must be sent "out of band" (via
 the control plane).

Mannie Standards Track [Page 25] RFC 3945 GMPLS Architecture October 2004

 LMP provides a fault localization procedure that can be used to
 rapidly localize link failures, by notifying a fault up to the node
 upstream of that fault (i.e., through a fault notification
 procedure).
 A downstream LMP neighbor that detects data link failures will send
 an LMP message to its upstream neighbor notifying it of the failure.
 When an upstream node receives a failure notification, it can
 correlate the failure with the corresponding input ports to determine
 if the failure is between the two nodes.  Once the failure has been
 localized, the signaling protocols can be used to initiate link or
 path protection/restoration procedures.

6.5. LMP for DWDM Optical Line Systems (OLSs)

 In an all-optical environment, LMP focuses on peer communications
 (e.g., OXC-to-OXC).  A great deal of information about a link between
 two OXCs is known by the OLS (Optical Line System or WDM Terminal
 multiplexer).  Exposing this information to the control plane can
 improve network usability by further reducing required manual
 configuration, and by greatly enhancing fault detection and recovery.
 LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC
 and an OLS.  These extensions are intended to satisfy the Optical
 Link Interface Requirements described in [OLI-REQ].
 Fault detection is particularly an issue when the network is using
 all-optical photonic switches (PXC).  Once a connection is
 established, PXCs have only limited visibility into the health of the
 connection.  Although the PXC is all-optical, long-haul OLSs
 typically terminate channels electrically and regenerate them
 optically.  This provides an opportunity to monitor the health of a
 channel between PXCs.  LMP-WDM can then be used by the OLS to provide
 this information to the PXC.
 In addition to the link information known to the OLS that is
 exchanged through LMP-WDM, some information known to the OXC may also
 be exchanged with the OLS through LMP-WDM.  This information is
 useful for alarm management and link monitoring (e.g., trace
 monitoring).  Alarm management is important because the
 administrative state of a connection, known to the OXC (e.g., this
 information may be learned through the Admin Status object of GMPLS
 signaling [RFC3471]), can be used to suppress spurious alarms.  For
 example, the OXC may know that a connection is "up", "down", in a
 "testing" mode, or being deleted ("deletion-in-progress").  The OXC
 can use this information to inhibit alarm reporting from the OLS when
 a connection is "down", "testing", or being deleted.

Mannie Standards Track [Page 26] RFC 3945 GMPLS Architecture October 2004

 It is important to note that an OXC may peer with one or more OLSs
 and an OLS may peer with one or more OXCs.  Although there are many
 similarities between an OXC-OXC LMP session and an OXC-OLS LMP
 session, particularly for control management and link verification,
 there are some differences as well.  These differences can primarily
 be attributed to the nature of an OXC-OLS link, and the purpose of
 OXC-OLS LMP sessions.  The OXC-OXC links can be used to provide the
 basis for GMPLS signaling and routing at the optical layer.  The
 information exchanged over LMP-WDM sessions is used to augment
 knowledge about the links between OXCs.
 In order for the information exchanged over the OXC-OLS LMP sessions
 to be used by the OXC-OXC session, the information must be
 coordinated by the OXC.  However, the OXC-OXC and OXC-OLS LMP
 sessions are run independently and must be maintained separately. One
 critical requirement when running an OXC-OLS LMP session is the
 ability of the OLS to make a data link transparent when not doing the
 verification procedure.  This is because the same data link may be
 verified between OXC-OLS and between OXC-OXC.  The verification
 procedure of LMP is used to coordinate the Test procedure (and hence
 the transparency/opaqueness of the data links).  To maintain
 independence between the sessions, it must be possible for the LMP
 sessions to come up in any order.  In particular, it must be possible
 for an OXC-OXC LMP session to come up without an OXC-OLS LMP session
 being brought up, and vice-versa.

7. Generalized Signaling

 The GMPLS signaling extends certain base functions of the RSVP-TE and
 CR-LDP signaling and, in some cases, adds functionality.  These
 changes and additions impact basic LSP properties: how labels are
 requested and communicated, the unidirectional nature of LSPs, how
 errors are propagated, and information provided for synchronizing the
 ingress and egress.
 The core GMPLS signaling specification is available in three parts:
    1. A signaling functional description [RFC3471].
    2. RSVP-TE extensions [RFC3473].
    3. CR-LDP extensions [RFC3472].
 In addition, independent parts are available per technology:
    1. GMPLS extensions for SONET and SDH control [RFC3946].
    2. GMPLS extensions for G.709 control [GMPLS-G709].

Mannie Standards Track [Page 27] RFC 3945 GMPLS Architecture October 2004

 The following MPLS profile expressed in terms of MPLS features
 [RFC3031] applies to GMPLS:
  1. Downstream-on-demand label allocation and distribution.
  1. Ingress initiated ordered control.
  1. Liberal (typical), or conservative (could) label retention mode.
  1. Request, traffic/data, or topology driven label allocation

strategy.

  1. Explicit routing (typical), or hop-by-hop routing.
 The GMPLS signaling defines the following new building blocks on the
 top of MPLS-TE:
 1.  A new generic label request format.
 2.  Labels for TDM, LSC and FSC interfaces, generically known as
     Generalized Label.
 3.  Waveband switching support.
 4.  Label suggestion by the upstream for optimization purposes (e.g.,
     latency).
 5.  Label restriction by the upstream to support some optical
     constraints.
 6.  Bi-directional LSP establishment with contention resolution.
 7.  Rapid failure notification extensions.
 8.  Protection information currently focusing on link protection,
     plus primary and secondary LSP indication.
 9.  Explicit routing with explicit label control for a fine degree of
     control.
 10. Specific traffic parameters per technology.
 11. LSP administrative status handling.
 12. Control channel separation.
 These building blocks will be described in more details in the
 following.  A complete specification can be found in the
 corresponding documents.
 Note that GMPLS is highly generic and has many options.  Only
 building blocks 1, 2 and 10 are mandatory, and only within the
 specific format that is needed.  Typically, building blocks 6 and 9
 should be implemented.  Building blocks 3, 4, 5, 7, 8, 11 and 12 are
 optional.

Mannie Standards Track [Page 28] RFC 3945 GMPLS Architecture October 2004

 A typical SONET/SDH switching network would implement building
 blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11.  Building blocks
 7 and 8 are optional since the protection can be achieved using
 SONET/SDH overhead bytes.
 A typical wavelength switching network would implement building
 blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11.  Building
 block 3 is only needed in the particular case of waveband switching.
 A typical fiber switching network would implement building blocks:
 1, 2 (the generic format), 6, 7, 8, 9 and 11.
 A typical MPLS-IP network would not implement any of these building
 blocks, since the absence of building block 1 would indicate regular
 MPLS-IP.  Note however that building block 1 and 8 can be used to
 signal MPLS-IP as well.  In that case, the MPLS-IP network can
 benefit from the link protection type (not available in CR-LDP, some
 very basic form being available in RSVP-TE).  Building block 2 is
 here a regular MPLS label and no new label format is required.
 GMPLS does not specify any profile for RSVP-TE and CR-LDP
 implementations that have to support GMPLS - except for what is
 directly related to GMPLS procedures.  It is to the manufacturer to
 decide which are the optional elements and procedures of RSVP-TE and
 CR-LDP that need to be implemented.  Some optional MPLS-TE elements
 can be useful for TDM, LSC and FSC layers, for instance the setup and
 holding priorities that are inherited from MPLS-TE.

7.1. Overview: How to Request an LSP

 A TDM, LSC or FSC LSP is established by sending a PATH/Label Request
 message downstream to the destination.  This message contains a
 Generalized Label Request with the type of LSP (i.e., the layer
 concerned), and its payload type.  An Explicit Route Object (ERO) is
 also normally added to the message, but this can be added and/or
 completed by the first/default LSR.
 The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC
 object, or in the CR-LDP Traffic Parameters TLV.  Specific parameters
 for a given technology are given in these traffic parameters, such as
 the type of signal, concatenation and/or transparency for a SONET/SDH
 LSP.  For some other technology there be could just one bandwidth
 parameter indicating the bandwidth as a floating-point value.
 The requested local protection per link may be requested using the
 Protection Information Object/TLV.  The end-to-end LSP protection is
 for further study and is introduced LSP protection/restoration
 section (see after).

Mannie Standards Track [Page 29] RFC 3945 GMPLS Architecture October 2004

 If the LSP is a bi-directional LSP, an Upstream Label is also
 specified in the Path/Label Request message.  This label will be the
 one to use in the upstream direction.
 Additionally, a Suggested Label, a Label Set and a Waveband Label can
 also be included in the message.  Other operations are defined in
 MPLS-TE.
 The downstream node will send back a Resv/Label Mapping message
 including one Generalized Label object/TLV that can contain several
 Generalized Labels.  For instance, if a concatenated SONET/SDH signal
 is requested, several labels can be returned.
 In case of SONET/SDH virtual concatenation, a list of labels is
 returned.  Each label identifying one element of the virtual
 concatenated signal.  This limits virtual concatenation to remain
 within a single (component) link.
 In case of any type of SONET/SDH contiguous concatenation, only one
 label is returned.  That label is the lowest signal of the contiguous
 concatenated signal (given an order specified in [RFC3946]).
 In case of SONET/SDH "multiplication", i.e., co-routing of circuits
 of the same type but without concatenation but all belonging to the
 same LSP, the explicit ordered list of all signals that take part in
 the LSP is returned.

7.2. Generalized Label Request

 The Generalized Label Request is a new object/TLV to be added in an
 RSVP-TE Path message instead of the regular Label Request, or in a
 CR-LDP Request message in addition to the already existing TLVs. Only
 one label request can be used per message, so a single LSP can be
 requested at a time per signaling message.
 The Generalized Label Request gives three major characteristics
 (parameters) required to support the LSP being requested: the LSP
 Encoding Type, the Switching Type that must be used and the LSP
 payload type called Generalized PID (G-PID).
 The LSP Encoding Type indicates the encoding type that will be used
 with the data associated with the LSP, i.e., the type of technology
 being considered.  For instance, it can be SDH, SONET, Ethernet, ANSI
 PDH, etc.  It represents the nature of the LSP, and not the nature of
 the links that the LSP traverses.  This is used hop-by-hop by each
 node.

Mannie Standards Track [Page 30] RFC 3945 GMPLS Architecture October 2004

 A link may support a set of encoding formats, where support means
 that a link is able to carry and switch a signal of one or more of
 these encoding formats.  The Switching Type indicates then the type
 of switching that should be performed on a particular link for that
 LSP.  This information is needed for links that advertise more than
 one type of switching capability.
 Nodes must verify that the type indicated in the Switching Type is
 supported on the corresponding incoming interface; otherwise, the
 node must generate a notification message with a "Routing
 problem/Switching Type" indication.
 The LSP payload type (G-PID) identifies the payload carried by the
 LSP, i.e., an identifier of the client layer of that LSP.  For some
 technologies, it also indicates the mapping used by the client layer,
 e.g., byte synchronous mapping of E1.  This must be interpreted
 according to the LSP encoding type and is used by the nodes at the
 endpoints of the LSP to know to which client layer a request is
 destined, and in some cases by the penultimate hop.
 Other technology specific parameters are not transported in the
 Generalized Label Request but in technology specific traffic
 parameters as explained hereafter.  Currently, two set of traffic
 parameters are defined, one for SONET/SDH and one for G.709.
 Note that it is expected than specific traffic parameters will be
 defined in the future for photonic (all optical) switching.

7.3. SONET/SDH Traffic Parameters

 The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful
 set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707].
 The first traffic parameter specifies the type of the elementary
 SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6,
 VC-4, STS-3c, etc.  Several transforms can then be applied
 successively on the elementary Signal to build the final signal being
 actually requested for the LSP.
 These transforms are the contiguous concatenation, the virtual
 concatenation, the transparency and the multiplication.  Each one is
 optional.  They must be applied strictly in the following order:
  1. First, contiguous concatenation can be optionally applied on the

Elementary Signal, resulting in a contiguously concatenated

    signal.

Mannie Standards Track [Page 31] RFC 3945 GMPLS Architecture October 2004

  1. Second, virtual concatenation can be optionally applied either

directly on the elementary Signal, or on the contiguously

    concatenated signal obtained from the previous phase.
  1. Third, some transparency can be optionally specified when

requesting a frame as signal rather than a container. Several

    transparency packages are defined.
  1. Fourth, a multiplication can be optionally applied either directly

on the elementary Signal, or on the contiguously concatenated

    signal obtained from the first phase, or on the virtually
    concatenated signal obtained from the second phase, or on these
    signals combined with some transparency.
 For RSVP-TE, the SONET/SDH traffic parameters are carried in a new
 SENDER_TSPEC and FLOWSPEC.  The same format is used for both.  There
 is no Adspec associated with the SENDER_TSPEC, it is omitted or a
 default value is used.  The content of the FLOWSPEC object received
 in a Resv message should be identical to the content of the
 SENDER_TSPEC of the corresponding Path message.  In other words, the
 receiver is normally not allowed to change the values of the traffic
 parameters.  However, some level of negotiation may be achieved as
 explained in [RFC3946].
 For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
 new TLV.
 Note that a general discussion on SONET/SDH and GMPLS can be found in
 [SONET-SDH-GMPLS-FRM].

7.4. G.709 Traffic Parameters

 Simply said, an [ITUT-G.709] based network is decomposed in two major
 layers: an optical layer (i.e., made of wavelengths) and a digital
 layer.  These two layers are divided into sub-layers and switching
 occurs at two specific sub-layers: at the OCh (Optical Channel)
 optical layer and at the ODU (Optical channel Data Unit) electrical
 layer.  The ODUk notation is used to denote ODUs at different
 bandwidths.
 The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful
 set of capabilities for ITU-T G.709 networks.
 The first traffic parameter specifies the type of the elementary
 G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40
 Gbps, etc.  Several transforms can then be applied successively on
 the elementary Signal to build the final signal being actually
 requested for the LSP.

Mannie Standards Track [Page 32] RFC 3945 GMPLS Architecture October 2004

 These transforms are the virtual concatenation and the
 multiplication.  Each one of these transforms is optional.  They must
 be applied strictly in the following order:
  1. First, virtual concatenation can be optionally applied directly on

the elementary Signal,

  1. Second, a multiplication can be optionally applied, either

directly on the elementary Signal, or on the virtually

    concatenated signal obtained from the first phase.
 Additional ODUk Multiplexing traffic parameters allow indicating an
 ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request.
 G.709 supports the following multiplexing capabilities: ODUj into
 ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.
 For RSVP-TE, the G.709 traffic parameters are carried in a new
 SENDER-TSPEC and FLOWSPEC.  The same format is used for both.  There
 is no Adspec associated with the SENDER_TSPEC, it is omitted or a
 default value is used.  The content of the FLOWSPEC object received
 in a Resv message should be identical to the content of the
 SENDER_TSPEC of the corresponding Path message.
 For CR-LDP, the G.709 traffic parameters are simply carried in a new
 TLV.

7.5. Bandwidth Encoding

 Some technologies that do not have (yet) specific traffic parameters
 just require a bandwidth encoding transported in a generic form.
 Bandwidth is carried in 32-bit number in IEEE floating-point format
 (the unit is bytes per second).  Values are carried in a per protocol
 specific manner.  For non-packet LSPs, it is useful to define
 discrete values to identify the bandwidth of the LSP.
 It should be noted that this bandwidth encoding do not apply to
 SONET/SDH and G.709, for which the traffic parameters fully define
 the requested SONET/SDH or G.709 signal.
 The bandwidth is coded in the Peak Data Rate field of Int-Serv
 objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in
 the Peak and Committed Data Rate fields of the CR-LDP Traffic
 Parameters TLV.

Mannie Standards Track [Page 33] RFC 3945 GMPLS Architecture October 2004

7.6. Generalized Label

 The Generalized Label extends the traditional MPLS label by allowing
 the representation of not only labels that travel in-band with
 associated data packets, but also (virtual) labels that identify
 time-slots, wavelengths, or space division multiplexed positions.
 For example, the Generalized Label may identify (a) a single fiber in
 a bundle, (b) a single waveband within fiber, (c) a single wavelength
 within a waveband (or fiber), or (d) a set of time-slots within a
 wavelength (or fiber).  It may also be a generic MPLS label, a Frame
 Relay label, or an ATM label (VCI/VPI).  The format of a label can be
 as simple as an integer value such as a wavelength label or can be
 more elaborated such as an SONET/SDH or a G.709 label.
 SDH and SONET define each a multiplexing structure.  These
 multiplexing structures will be used as naming trees to create unique
 labels.  Such a label will identify the exact position (times-lot(s))
 of a signal in a multiplexing structure.  Since the SONET
 multiplexing structure may be seen as a subset of the SDH
 multiplexing structure, the same format of label is used for SDH and
 SONET.  A similar concept is applied to build a label at the G.709
 ODU layer.
 Since the nodes sending and receiving the Generalized Label know what
 kinds of link they are using, the Generalized Label does not identify
 its type.  Instead, the nodes are expected to know from the context
 what type of label to expect.
 A Generalized Label only carries a single level of label i.e., it is
 non-hierarchical.  When multiple levels of labels (LSPs within LSPs)
 are required, each LSP must be established separately.

7.7. Waveband Switching

 A special case of wavelength switching is waveband switching.  A
 waveband represents a set of contiguous wavelengths, which can be
 switched together to a new waveband.  For optimization reasons, it
 may be desirable for a photonic cross-connect to optically switch
 multiple wavelengths as a unit.  This may reduce the distortion on
 the individual wavelengths and may allow tighter separation of the
 individual wavelengths.  A Waveband label is defined to support this
 special case.
 Waveband switching naturally introduces another level of label
 hierarchy and as such the waveband is treated the same way, all other
 upper layer labels are treated.  As far as the MPLS protocols are
 concerned, there is little difference between a waveband label and a

Mannie Standards Track [Page 34] RFC 3945 GMPLS Architecture October 2004

 wavelength label.  Exception is that semantically the waveband can be
 subdivided into wavelengths whereas the wavelength can only be
 subdivided into time or statistically multiplexed labels.
 In the context of waveband switching, the generalized label used to
 indicate a waveband contains three fields, a waveband ID, a Start
 Label and an End Label.  The Start and End Labels are channel
 identifiers from the sender perspective that identify respectively,
 the lowest value wavelength and the highest value wavelength making
 up the waveband.

7.8. Label Suggestion by the Upstream

 GMPLS allows for a label to be optionally suggested by an upstream
 node.  This suggestion may be overridden by a downstream node but in
 some cases, at the cost of higher LSP setup time.  The suggested
 label is valuable when establishing LSPs through certain kinds of
 optical equipment where there may be a lengthy (in electrical terms)
 delay in configuring the switching fabric.  For example, micro
 mirrors may have to be elevated or moved, and this physical motion
 and subsequent damping takes time.  If the labels and hence switching
 fabric are configured in the reverse direction (the norm), the
 Resv/MAPPING message may need to be delayed by 10's of milliseconds
 per hop in order to establish a usable forwarding path.  It can be
 important for restoration purposes where alternate LSPs may need to
 be rapidly established as a result of network failures.

7.9. Label Restriction by the Upstream

 An upstream node can optionally restrict (limit) the choice of label
 of a downstream node to a set of acceptable labels.  Giving lists
 and/or ranges of inclusive (acceptable) or exclusive (unacceptable)
 labels in a Label Set provides this restriction.  If not applied, all
 labels from the valid label range may be used.  There are at least
 four cases where a label restriction is useful in the "optical"
 domain.
 Case 1: the end equipment is only capable of transmitting and
    receiving on a small specific set of wavelengths/wavebands.
 Case 2: there is a sequence of interfaces, which cannot support
    wavelength conversion and require the same wavelength be used
    end-to-end over a sequence of hops, or even an entire path.
 Case 3: it is desirable to limit the amount of wavelength conversion
    being performed to reduce the distortion on the optical signals.
 Case 4: two ends of a link support different sets of wavelengths.

Mannie Standards Track [Page 35] RFC 3945 GMPLS Architecture October 2004

 The receiver of a Label Set must restrict its choice of labels to one
 that is in the Label Set.  A Label Set may be present across multiple
 hops.  In this case, each node generates its own outgoing Label Set,
 possibly based on the incoming Label Set and the node's hardware
 capabilities.  This case is expected to be the norm for nodes with
 conversion incapable interfaces.

7.10. Bi-directional LSP

 GMPLS allows establishment of bi-directional symmetric LSPs (not of
 asymmetric LSPs).  A symmetric bi-directional LSP has the same
 traffic engineering requirements including fate sharing, protection
 and restoration, LSRs, and resource requirements (e.g., latency and
 jitter) in each direction.
 In the remainder of this section, the term "initiator" is used to
 refer to a node that starts the establishment of an LSP; the term
 "terminator" is used to refer to the node that is the target of the
 LSP.  For a bi-directional LSPs, there is only one initiator and one
 terminator.
 Normally to establish a bi-directional LSP when using RSVP-TE
 [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be
 independently established. This approach has the following
 disadvantages:
 1. The latency to establish the bi-directional LSP is equal to one
    round trip signaling time plus one initiator-terminator signaling
    transit delay.  This not only extends the setup latency for
    successful LSP establishment, but it extends the worst-case
    latency for discovering an unsuccessful LSP to as much as two
    times the initiator-terminator transit delay.  These delays are
    particularly significant for LSPs that are established for
    restoration purposes.
 2. The control overhead is twice that of a unidirectional LSP.  This
    is because separate control messages (e.g., Path and Resv) must be
    generated for both segments of the bi-directional LSP.
 3. Because the resources are established in separate segments, route
    selection is complicated.  There is also additional potential race
    for conditions in assignment of resources, which decreases the
    overall probability of successfully establishing the bi-
    directional connection.

Mannie Standards Track [Page 36] RFC 3945 GMPLS Architecture October 2004

 4. It is more difficult to provide a clean interface for SONET/SDH
    equipment that may rely on bi-directional hop-by-hop paths for
    protection switching.  Note that existing SONET/SDH equipment
    transmits the control information in-band with the data.
 5. Bi-directional optical LSPs (or lightpaths) are seen as a
    requirement for many optical networking service providers.
 With bi-directional LSPs both the downstream and upstream data paths,
 i.e., from initiator to terminator and terminator to initiator, are
 established using a single set of signaling messages.  This reduces
 the setup latency to essentially one initiator-terminator round trip
 time plus processing time, and limits the control overhead to the
 same number of messages as a unidirectional LSP.
 For bi-directional LSPs, two labels must be allocated.  Bi-
 directional LSP setup is indicated by the presence of an Upstream
 Label in the appropriate signaling message.

7.11. Bi-directional LSP Contention Resolution

 Contention for labels may occur between two bi-directional LSP setup
 requests traveling in opposite directions.  This contention occurs
 when both sides allocate the same resources (ports) at effectively
 the same time.  GMPLS signaling defines a procedure to resolve that
 contention: the node with the higher node ID will win the contention.
 To reduce the probability of contention, some mechanisms are also
 suggested.

7.12. Rapid Notification of Failure

 GMPLS defines several signaling extensions that enable expedited
 notification of failures and other events to nodes responsible for
 restoring failed LSPs, and error handling.
 1. Acceptable Label Set for notification on Label Error:
    There are cases in traditional MPLS and in GMPLS that result in an
    error message containing an "Unacceptable label value" indication.
    When these cases occur, it can useful for the node generating the
    error message to indicate which labels would be acceptable.  To
    cover this case, GMPLS introduces the ability to convey such
    information via the "Acceptable Label Set".  An Acceptable Label
    Set is carried in appropriate protocol specific error messages.
    The format of an Acceptable Label Set is identical to a Label Set.

Mannie Standards Track [Page 37] RFC 3945 GMPLS Architecture October 2004

 2. Expedited notification:
    Extensions to RSVP-TE enable expedited notification of failures
    and other events to determined nodes.  For CR-LDP, there is not
    currently a similar mechanism.  The first extension identifies
    where event notifications are to be sent.  The second provides for
    general expedited event notification with a Notify message.  Such
    extensions can be used by fast restoration mechanisms.
    Notifications may be requested in both the upstream and downstream
    directions.
    The Notify message is a generalized notification mechanism that
    differs from the currently defined error messages in that it can
    be "targeted" to a node other than the immediate upstream or
    downstream neighbor.  The Notify message does not replace existing
    error messages.  The Notify message may be sent either (a)
    normally, where non-target nodes just forward the Notify message
    to the target node, similar to ResvConf processing in [RFC2205];
    or (b) encapsulated in a new IP header whose destination is equal
    to the target IP address.
 3. Faster removal of intermediate states:
    A specific RSVP optimization allowing in some cases the faster
    removal of intermediate states.  This extension is used to deal
    with specific RSVP mechanisms.

7.13. Link Protection

 Protection information is carried in the new optional Protection
 Information Object/TLV.  It currently indicates the desired link
 protection for each link of an LSP.  If a particular protection type,
 i.e., 1+1, or 1:N, is requested, then a connection request is
 processed only if the desired protection type can be honored.  Note
 that GMPLS advertises the protection capabilities of a link in the
 routing protocols.  Path computation algorithms may consider this
 information when computing paths for setting up LSPs.
 Protection information also indicates if the LSP is a primary or
 secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
 resources of a secondary LSP are normally not used until the primary
 LSP fails, but they may be used by other LSPs until the primary LSP
 fails over the secondary LSP.  At that point, any LSP that is using
 the resources for the secondary LSP must be preempted.

Mannie Standards Track [Page 38] RFC 3945 GMPLS Architecture October 2004

 Six link protection types are currently defined as individual flags
 and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared,
 unprotected, extra traffic.  See [RFC3471] section 7.1 for a precise
 definition of each.

7.14. Explicit Routing and Explicit Label Control

 By using an explicit route, the path taken by an LSP can be
 controlled more or less precisely.  Typically, the node at the head-
 end of an LSP finds an explicit route and builds an Explicit Route
 Object (ERO)/ Explicit Route (ER) TLV that contains that route.
 Possibly, the edge node does not build any explicit route, and just
 transmit a signaling request to a default neighbor LSR (as IP/MPLS
 hosts would).  For instance, an explicit route could be added to a
 signaling message by the first switching node, on behalf of the edge
 node.  Note also that an explicit route is altered by intermediate
 LSRs during its progression towards the destination.
 The explicit route is originally defined by MPLS-TE as a list of
 abstract nodes (i.e., groups of nodes) along the explicit route.
 Each abstract node can be an IPv4 address prefix, an IPv6 address
 prefix, or an AS number.  This capability allows the generator of the
 explicit route to have incomplete information about the details of
 the path.  In the simplest case, an abstract node can be a full IP
 address (32 bits) that identifies a specific node (called a simple
 abstract node).
 MPLS-TE allows strict and loose abstract nodes.  The path between a
 strict node and its preceding node must include only network nodes
 from the strict node and its preceding abstract node.  The path
 between a loose node and its preceding abstract node may include
 other network nodes that are not part of the loose node or its
 preceding abstract node.
 This explicit route was extended to include interface numbers as
 abstract nodes to support unnumbered interfaces; and further extended
 by GMPLS to include labels as abstract nodes.  Having labels in an
 explicit route is an important feature that allows controlling the
 placement of an LSP with a very fine granularity.  This is more
 likely to be used for TDM, LSC and FSC links.
 In particular, the explicit label control in the explicit route
 allows terminating an LSP on a particular outgoing port of an egress
 node.  Indeed, a label sub-object/TLV must follow a sub-object/TLV
 containing the IP address, or the interface identifier (in case of
 unnumbered interface), associated with the link on which it is to be
 used.

Mannie Standards Track [Page 39] RFC 3945 GMPLS Architecture October 2004

 This can also be used when it is desirable to "splice" two LSPs
 together, i.e., where the tail of the first LSP would be "spliced"
 into the head of the second LSP.
 When used together with an optimization algorithm, it can provide
 very detailed explicit routes, including the label (timeslot) to use
 on a link, in order to minimize the fragmentation of the SONET/SDH
 multiplex on the corresponding interface.

7.15. Route Recording

 In order to improve the reliability and the manageability of the LSP
 being established, the concept of the route recording was introduced
 in RSVP-TE to function as:
  1. First, a loop detection mechanism to discover L3 routing loops, or

loops inherent in the explicit route (this mechanism is strictly

    exclusive with the use of explicit routing objects).
  1. Second, a route recording mechanism collects up-to-date detailed

path information on a hop-by-hop basis during the LSP setup

    process. This mechanism provides valuable information to the
    source and destination nodes.  Any intermediate routing change at
    setup time, in case of loose explicit routing, will be reported.
  1. Third, a recorded route can be used as input for an explicit

route. This is useful if a source node receives the recorded

    route from a destination node and applies it as an explicit route
    in order to "pin down the path".
 Within the GMPLS architecture, only the second and third functions
 are mainly applicable for TDM, LSC and FSC layers.

7.16. LSP Modification and LSP Re-routing

 LSP modification and re-routing are two features already available in
 MPLS-TE.  GMPLS does not add anything new.  Elegant re-routing is
 possible with the concept of "make-before-break" whereby an old path
 is still used while a new path is set up by avoiding double
 reservation of resources.  Then, the node performing the re-routing
 can swap on the new path and close the old path.  This feature is
 supported with RSVP-TE (using shared explicit filters) and CR-LDP
 (using the action indicator flag).
 LSP modification consists in changing some LSP parameters, but
 normally without changing the route.  It is supported using the same
 mechanism as re-routing.  However, the semantic of LSP modification
 will differ from one technology to the other.  For instance, further

Mannie Standards Track [Page 40] RFC 3945 GMPLS Architecture October 2004

 studies are required to understand the impact of dynamically changing
 some SONET/SDH circuit characteristics such as the bandwidth, the
 protection type, the transparency, the concatenation, etc.

7.17. LSP Administrative Status Handling

 GMPLS provides the optional capability to indicate the administrative
 status of an LSP by using a new Admin Status object/TLV.
 Administrative Status information is currently used in two ways.
 In the first usage, the Admin Status object/TLV is carried in a
 Path/Label Request or Resv/Label Mapping message to indicate the
 administrative state of an LSP.  In this usage, Administrative Status
 information indicates the state of the LSP, which include "up" or
 "down", if it in a "testing" mode, and if deletion is in progress.
 Based on that administrative status, a node can take local decisions,
 like inhibit alarm reporting when an LSP is in "down" or "testing"
 states, or report alarms associated with the connection at a priority
 equal to or less than "Non service affecting".
 It is possible that some nodes along an LSP will not support the
 Admin Status Object/TLV.  In the case of a non-supporting transit
 node, the object will pass through the node unmodified and normal
 processing can continue.
 In some circumstances, particularly optical networks, it is useful to
 set the administrative status of an LSP to "being deleted" before
 tearing it down in order to avoid non-useful generation of alarms.
 The ingress LSR precedes an LSP deletion by inserting an appropriate
 Admin Status Object/TLV in a Path/Label Request (with the
 modification action indicator flag set to modify) message.  Transit
 LSRs process the Admin Status Object/TLV and forward it.  The egress
 LSR answers in a Resv/Label Mapping (with the modification action
 indicator flag set to modify) message with the Admin Status object.
 Upon receiving this message and object, the ingress node sends a
 PathTear/Release message downstream to remove the LSP and normal
 RSVP-TE/CR-LDP processing takes place.
 In the second usage, the Admin Status object/TLV is carried in a
 Notification/Label Mapping (with the modification action indicator
 flag set to modify) message to request that the ingress node change
 the administrative state of an LSP.  This allows intermediate and
 egress nodes triggering the setting of administrative status.  In
 particular, this allows intermediate or egress LSRs requesting a
 release of an LSP initiated by the ingress node.

Mannie Standards Track [Page 41] RFC 3945 GMPLS Architecture October 2004

7.18. Control Channel Separation

 In GMPLS, a control channel be separated from the data channel.
 Indeed, the control channel can be implemented completely out-of-
 band for various reason, e.g., when the data channel cannot carry
 in-band control information.  This issue was even originally
 introduced to MPLS in the context of link bundling.
 In traditional MPLS, there is an implicit one-to-one association of a
 control channel to a data channel.  When such an association is
 present, no additional or special information is required to
 associate a particular LSP setup transaction with a particular data
 channel.
 Otherwise, it is necessary to convey additional information in
 signaling to identify the particular data channel being controlled.
 GMPLS supports explicit data channel identification by providing
 interface identification information.  GMPLS allows the use of a
 number of interface identification schemes including IPv4 or IPv6
 addresses, interface indexes (for unnumbered interfaces) and
 component interfaces (for bundled interfaces), unnumbered bundled
 interfaces are also supported.
 The choice of the data interface to use is always made by the sender
 of the Path/Label Request message, and indicated by including the
 data channel's interface identifier in the message using a new
 RSVP_HOP object sub-type/Interface TLV.
 For bi-directional LSPs, the sender chooses the data interface in
 each direction.  In all cases but bundling, the upstream interface is
 implied by the downstream interface.  For bundling, the Path/Label
 Request sender explicitly identifies the component interface used in
 each direction.  The new object/TLV is used in Resv/Label Mapping
 message to indicate the downstream node's usage of the indicated
 interface(s).
 The new object/TLV can contain a list of embedded TLVs, each embedded
 TLV can be an IPv4 address, and IPv6 address, an interface index, a
 downstream component interface ID or an upstream component interface
 ID.  In the last three cases, the embedded TLV contains itself an IP
 address plus an Interface ID, the IP address being used to identify
 the interface ID (it can be the router ID for instance).
 There are cases where it is useful to indicate a specific interface
 associated with an error.  To support these cases the IF_ID
 ERROR_SPEC RSVP Objects are defined.

Mannie Standards Track [Page 42] RFC 3945 GMPLS Architecture October 2004

8. Forwarding Adjacencies (FA)

 To improve scalability of MPLS TE (and thus GMPLS) it may be useful
 to aggregate multiple TE LSPs inside a bigger TE LSP.  Intermediate
 nodes see the external LSP only.  They do not have to maintain
 forwarding states for each internal LSP, less signaling messages need
 to be exchanged and the external LSP can be somehow protected instead
 (or in addition) to the internal LSPs.  This can considerably
 increase the scalability of the signaling.
 The aggregation is accomplished by (a) an LSR creating a TE LSP, (b)
 the LSR forming a forwarding adjacency out of that LSP (advertising
 this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c)
 allowing other LSRs to use forwarding adjacencies for their path
 computation, and (d) nesting of LSPs originated by other LSRs into
 that LSP (e.g., by using the label stack construct in the case of
 IP).
 ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs
 just as it floods the information about any other links. Consequently
 to this flooding, an LSR has in its TE link state database the
 information about not just conventional links, but FAs as well.
 An LSR, when performing path computation, uses not just conventional
 links, but FAs as well.  Once a path is computed, the LSR uses RSVP-
 TE/CR-LDP for establishing label binding along the path.  FAs need
 simple extensions to signaling and routing protocols.

8.1. Routing and Forwarding Adjacencies

 Forwarding adjacencies may be represented as either unnumbered or
 numbered links.  A FA can also be a bundle of LSPs between two nodes.
 FAs are advertised as GMPLS TE links such as defined in [HIERARCHY].
 GMPLS TE links are advertised in OSPF and IS-IS such as defined in
 [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  These last two specifications
 enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.
 When a FA is created dynamically, its TE attributes are inherited
 from the FA-LSP that induced its creation.  [HIERARCHY] specifies how
 each TE parameter of the FA is inherited from the FA-LSP.  Note that
 the bandwidth of the FA must be at least as big as the FA-LSP that
 induced it, but may be bigger if only discrete bandwidths are
 available for the FA-LSP.  In general, for dynamically provisioned
 forwarding adjacencies, a policy-based mechanism may be needed to
 associate attributes to forwarding adjacencies.

Mannie Standards Track [Page 43] RFC 3945 GMPLS Architecture October 2004

 A FA advertisement could contain the information about the path taken
 by the FA-LSP associated with that FA.  Other LSRs may use this
 information for path computation.  This information is carried in a
 new OSPF and IS-IS TLV called the Path TLV.
 It is possible that the underlying path information might change over
 time, via configuration updates, or dynamic route modifications,
 resulting in the change of that TLV.
 If forwarding adjacencies are bundled (via link bundling), and if the
 resulting bundled link carries a Path TLV, the underlying path
 followed by each of the FA-LSPs that form the component links must be
 the same.
 It is expected that forwarding adjacencies will not be used for
 establishing IS-IS/OSPF peering relation between the routers at the
 ends of the adjacency.
 LSP hierarchy could exist both with the peer and with the overlay
 models.  With the peer model, the LSP hierarchy is realized via FAs
 and an LSP is both created and used as a TE link by exactly the same
 instance of the control plane.  Creating LSP hierarchies with
 overlays does not involve the concept of FA.  With the overlay model
 an LSP created (and maintained) by one instance of the GMPLS control
 plane is used as a TE link by another instance of the GMPLS control
 plane.  Moreover, the nodes using a TE link are expected to have a
 routing and signaling adjacency.

8.2. Signaling Aspects

 For the purpose of processing the explicit route in a Path/Request
 message of an LSP that is to be tunneled over a forwarding adjacency,
 an LSR at the head-end of the FA-LSP views the LSR at the tail of
 that FA-LSP as adjacent (one IP hop away).

8.3. Cascading of Forwarding Adjacencies

 With an integrated model, several layers are controlled using the
 same routing and signaling protocols.  A network may then have links
 with different multiplexing/demultiplexing capabilities.  For
 example, a node may be able to multiplex/demultiplex individual
 packets on a given link, and may be able to multiplex/demultiplex
 channels within a SONET payload on other links.
 A new OSPF and IS-IS sub-TLV has been defined to advertise the
 multiplexing capability of each interface: PSC, L2SC, TDM, LSC or
 FSC.  This sub-TLV is called the Interface Switching Capability
 Descriptor sub-TLV, which complements the sub-TLVs defined in

Mannie Standards Track [Page 44] RFC 3945 GMPLS Architecture October 2004

 [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  The information carried in this
 sub-TLV is used to construct LSP regions, and determine region's
 boundaries.
 Path computation may take into account region 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
 multiplexing/demultiplexing capability is PSC.  When an LSP need to
 cross a region boundary, it can trigger the establishment of an FA at
 the underlying layer (i.e., the L2SC layer).  This can trigger a
 cascading of FAs between layers with the following obvious order:
 L2SC, then TDM, then LSC, and then finally FSC.

9. Routing and Signaling Adjacencies

 By definition, two nodes have a routing (IS-IS/OSPF) adjacency if
 they are neighbors in the IS-IS/OSPF sense.
 By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency
 if they are neighbors in the RSVP-TE/CR-LDP sense.  Nodes A and B are
 RSVP-TE neighbors if they directly exchange RSVP-TE messages
 (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of
 [HIERARCHY]).  The neighbor relationship includes exchanging RSVP-TE
 Hellos.
 By definition, a Forwarding Adjacency (FA) is a TE Link between two
 GMPLS nodes whose path transits one or more other (G)MPLS nodes in
 the same instance of the (G)MPLS control plane.  If two nodes have
 one or more non-FA TE Links between them, these two nodes are
 expected (although not required) to have a routing adjacency.  If two
 nodes do not have any non-FA TE Links between them, it is expected
 (although not required) that these two nodes would not have a routing
 adjacency.  To state the obvious, if the TE links between two nodes
 are to be used for establishing LSPs, the two nodes must have a
 signaling adjacency.
 If one wants to establish routing and/or signaling adjacency between
 two nodes, there must be an IP path between them.  This IP path can
 be, for example, a TE Link with an interface switching capability of
 PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a
 (bi-directional) LSP that with an interface switching capability of
 PSC).
 A TE link may not be capable of being used directly for maintaining
 routing and/or signaling adjacencies.  This is because GMPLS routing
 and signaling adjacencies requires exchanging data on a per frame/
 packet basis, and a TE link (e.g., a link between OXCs) may not be
 capable of exchanging data on a per packet basis.  In this case, the

Mannie Standards Track [Page 45] RFC 3945 GMPLS Architecture October 2004

 routing and signaling adjacencies are maintained via a set of one or
 more control channels (see [LMP]).
 Two nodes may have a TE link between them even if they do not have a
 routing adjacency.  Naturally, each node must run OSPF/IS-IS with
 GMPLS extensions in order for that TE link to be advertised.  More
 precisely, the node needs to run GMPLS extensions for TE Links with
 an interface switching capability (see [GMPLS-ROUTING]) other than
 PSC.  Moreover, this node needs to run either GMPLS or MPLS
 extensions for TE links with an interface switching capability of
 PSC.
 The mechanisms for Control Channel Separation [RFC3471] should be
 used (even if the IP path between two nodes is a TE link).  I.e.,
 RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object
 to specify a particular TE link when establishing an LSP.
 The IP path could consist of multiple IP hops.  In this case, the
 mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used
 (in addition to Control Channel Separation).

10. Control Plane Fault Handling

 Two major types of faults can impact a control plane.  The first,
 referred to as control channel fault, relates to the case where
 control communication is lost between two neighboring nodes.  If the
 control channel is embedded with the data channel, data channel
 recovery procedure should solve the problem.  If the control channel
 is independent of the data channel, additional procedures are
 required to recover from that problem.
 The second, referred to as nodal faults, relates to the case where
 node loses its control state (e.g., after a restart) but does not
 loose its data forwarding state.
 In transport networks, such types of control plane faults should not
 have service impact on the existing connections.  Under such
 circumstances, a mechanism must exist to detect a control
 communication failure and a recovery procedure must guarantee
 connection integrity at both ends of the control channel.
 For a control channel fault, once communication is restored routing
 protocols are naturally able to recover but the underlying signaling
 protocols must indicate that the nodes have maintained their state
 through the failure.  The signaling protocol must also ensure that
 any state changes that were instantiated during the failure are
 synchronized between the nodes.

Mannie Standards Track [Page 46] RFC 3945 GMPLS Architecture October 2004

 For a nodal fault, a node's control plane restarts and loses most of
 its state information.  In this case, both upstream and downstream
 nodes must synchronize their state information with the restarted
 node.  In order for any resynchronization to occur the node
 undergoing the restart will need to preserve some information, such
 as it's mappings of incoming to outgoing labels.
 These issues are addressed in protocol specific fashions, see
 [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS].  Note that
 these cases only apply when there are mechanisms to detect data
 channel failures independent of control channel failures.
 The LDP Fault tolerance (see [RFC3479]) specifies the procedures to
 recover from a control channel failure.  [RFC3473] specifies how to
 recover from both a control channel failure and a node failure.

11. LSP Protection and Restoration

 This section discusses Protection and Restoration (P&R) issues for
 GMPLS LSPs.  It is driven by the requirements outlined in [RFC3386]
 and some of the principles outlined in [RFC3469].  It will be
 enhanced, as more GMPLS P&R mechanisms are defined.  The scope of
 this section is clarified hereafter:
  1. This section is only applicable when a fault impacting LSP(s)

happens in the data/transport plane. Section 10 deals with

    control plane fault handling for nodal and control channel faults.
  1. This section focuses on P&R at the TDM, LSC and FSC layers. There

are specific P&R requirements at these layers not present at the

    PSC layer.
  1. This section focuses on intra-area P&R as opposed to inter-area

P&R and even inter-domain P&R. Note that P&R can even be more

    restricted, e.g., to a collection of like customer equipment, or a
    collection of equipment of like capabilities, in one single
    routing area.
  1. This section focuses on intra-layer P&R (horizontal hierarchy as

defined in [RFC3386]) as opposed to the inter-layer P&R (vertical

    hierarchy).
  1. P&R mechanisms are in general designed to handle single failures,

which makes SRLG diversity a necessity. Recovery from multiple

    failures requires further study.
  1. Both mesh and ring-like topologies are supported.

Mannie Standards Track [Page 47] RFC 3945 GMPLS Architecture October 2004

 In the following, we assume that:
  1. TDM, LSC and FSC devices are more generally committing recovery

resources in a non-best effort way. Recovery resources are either

    allocated (thus used) or at least logically reserved (whether used
    or not by preemptable extra traffic but unavailable anyway for
    regular working traffic).
  1. Shared P&R mechanisms are valuable to operators in order to

maximize their network utilization.

  1. Sending preemptable excess traffic on recovery resources is a

valuable feature for operators.

11.1. Protection Escalation across Domains and Layers

 To describe the P&R architecture, one must consider two dimensions of
 hierarchy [RFC3386]:
  1. A horizontal hierarchy consisting of multiple P&R domains, which

is important in an LSP based protection scheme. The scope of P&R

    may extend over a link (or span), an administrative domain or
    sub-network, an entire LSP.
    An administrative domain may consist of a single P&R domain or as
    a concatenation of several smaller P&R domains.  The operator can
    configure P&R domains, based on customers' requirements, and on
    network topology and traffic engineering constraints.
  1. A vertical hierarchy consisting of multiple layers of P&R with

varying granularities (packet flows, STS trails, lightpaths,

    fibers, etc).
    In the absence of adequate P&R coordination, a fault may propagate
    from one level to the next within a P&R hierarchy.  It can lead to
    "collisions" and simultaneous recovery actions may lead to race
    conditions, reduced resource utilization, or instabilities
    [MANCHESTER].  Thus, a consistent escalation strategy is needed to
    coordinate recovery across domains and layers.  The fact that
    GMPLS can be used at different layers could simplify this
    coordination.
    There are two types of escalation strategies: bottom-up and top-
    down.  The bottom-up approach assumes that "lower-level" recovery
    schemes are more expedient.  Therefore we can inhibit or hold off

Mannie Standards Track [Page 48] RFC 3945 GMPLS Architecture October 2004

    higher-level P&R.  The Top-down approach attempts service P&R at
    the higher levels before invoking "lower level" P&R.  Higher-layer
    P&R is service selective, and permits "per-CoS" or "per-LSP" re-
    routing.
 Service Level Agreements (SLAs) between network operators and their
 clients are needed to determine the necessary time scales for P&R at
 each layer and at each domain.

11.2. Mapping of Services to P&R Resources

 The choice of a P&R scheme is a tradeoff between network utilization
 (cost) and service interruption time.  In light of this tradeoff,
 network service providers are expected to support a range of
 different service offerings or service levels.
 One can classify LSPs into one of a small set of service levels.
 Among other things, these service levels define the reliability
 characteristics of the LSP.  The service level associated with a
 given LSP is mapped to one or more P&R schemes during LSP
 establishment.  An advantage that mapping is that an LSP may use
 different P&E schemes in different segments of a network (e.g., some
 links may be span protected, whilst other segments of the LSP may
 utilize ring protection).  These details are likely to be service
 provider specific.
 An alternative to using service levels is for an application to
 specify the set of specific P&R mechanisms to be used when
 establishing the LSP.  This allows greater flexibility in using
 different mechanisms to meet the application requirements.
 A differentiator between these service levels is service interruption
 time in case of network failures, which is defined as the length of
 time between when a failure occurs and when connectivity is re-
 established.  The choice of service level (or P&R scheme) should be
 dictated by the service requirements of different applications.

11.3. Classification of P&R Mechanism Characteristics

 The following figure provides a classification of the possible
 provisioning types of recovery LSPs, and of the levels of overbooking
 that is possible for them.

Mannie Standards Track [Page 49] RFC 3945 GMPLS Architecture October 2004

               +-Computed on  +-Established     +-Resources pre-
               | demand       | on demand       | allocated
               |              |                 |
 Recovery LSP  |              |                 |
 Provisioning -+-Pre computed +-Pre established +-Resources allocated
                                                  on demand
                +--- Dedicated (1:1, 1+1)
                |
                |
                +--- Shared (1:N, Ring, Shared mesh)
                |
 Level of       |
 Overbooking ---+--- Best effort

11.4. Different Stages in P&R

 Recovery from a network fault or impairment takes place in several
 stages as discussed in [RFC3469], including fault detection, fault
 localization, notification, recovery (i.e., the P&R itself) and
 reversion of traffic (i.e., returning the traffic to the original
 working LSP or to a new one).
  1. Fault detection is technology and implementation dependent. In

general, failures are detected by lower layer mechanisms (e.g.,

    SONET/SDH, Loss-of-Light (LOL)).  When a node detects a failure,
    an alarm may be passed up to a GMPLS entity, which will take
    appropriate actions, or the alarm may be propagated at the lower
    layer (e.g., SONET/SDH AIS).
  1. Fault localization can be done with the help of GMPLS, e.g., using

LMP for fault localization (see section 6.4).

  1. Fault notification can also be achieved through GMPLS, e.g., using

GMPLS RSVP-TE/CR-LDP notification (see section 7.12).

  1. This section focuses on the different mechanisms available for

recovery and reversion of traffic once fault detection,

    localization and notification have taken place.

11.5. Recovery Strategies

 Network P&R techniques can be divided into Protection and
 Restoration.  In protection, resources between the protection
 endpoints are established before failure, and connectivity after
 failure is achieved simply by switching performed at the protection
 end-points.  In contrast, restoration uses signaling after failure to
 allocate resources along the recovery path.

Mannie Standards Track [Page 50] RFC 3945 GMPLS Architecture October 2004

  1. Protection aims at extremely fast reaction times and may rely on

the use of overhead control fields for achieving end-point

    coordination.  Protection for SONET/SDH networks is described in
    [ITUT-G.841] and [ANSI-T1.105].  Protection mechanisms can be
    further classified by the level of redundancy and sharing.
  1. Restoration mechanisms rely on signaling protocols to coordinate

switching actions during recovery, and may involve simple re-

    provisioning, i.e., signaling only at the time of recovery; or
    pre-signaling, i.e., signaling prior to recovery.
 In addition, P&R can be applied on a local or end-to-end basis.  In
 the local approach, P&R is focused on the local proximity of the
 fault in order to reduce delay in restoring service.  In the end-to-
 end approach, the LSP originating and terminating nodes control
 recovery.
 Using these strategies, the following recovery mechanisms can be
 defined.

11.6. Recovery mechanisms: Protection schemes

 Note that protection schemes are usually defined in technology
 specific ways, but this does not preclude other solutions.
  1. 1+1 Link Protection: Two pre-provisioned resources are used in

parallel. For example, data is transmitted simultaneously on two

    parallel links and a selector is used at the receiving node to
    choose the best source (see also [GMPLS-FUNCT]).
  1. 1:N Link Protection: Working and protecting resources (N working,

1 backup) are pre-provisioned. If a working resource fails, the

    data is switched to the protecting resource, using a coordination
    mechanism (e.g., in overhead bytes).  More generally, N working
    and M protecting resources can be assigned for M:N link protection
    (see also [GMPLS-FUNCT]).
  1. Enhanced Protection: Various mechanisms such as protection rings

can be used to enhance the level of protection beyond single link

    failures to include the ability to switch around a node failure or
    multiple link failures within a span, based on a pre-established
    topology of protection resources (note: no reference available at
    publication time).
  1. 1+1 LSP Protection: Simultaneous data transmission on working and

protecting LSPs and tail-end selection can be applied (see also

    [GMPLS-FUNCT]).

Mannie Standards Track [Page 51] RFC 3945 GMPLS Architecture October 2004

11.7. Recovery mechanisms: Restoration schemes

 Thanks to the use of a distributed control plane like GMPLS,
 restoration is possible in multiple of tenths of milliseconds.  It is
 much harder to achieve when only an NMS is used and can only be done
 in that case in a multiple of seconds.
  1. End-to-end LSP restoration with re-provisioning: an end-to-end

restoration path is established after failure. The restoration

    path may be dynamically calculated after failure, or pre-
    calculated before failure (often during LSP establishment).
    Importantly, no signaling is used along the restoration path
    before failure, and no restoration bandwidth is reserved.
    Consequently, there is no guarantee that a given restoration path
    is available when a failure occurs.  Thus, one may have to
    crankback to search for an available path.
  1. End-to-end LSP restoration with pre-signaled recovery bandwidth

reservation and no label pre-selection: an end-to-end restoration

    path is pre-calculated before failure and a signaling message is
    sent along this pre-selected path to reserve bandwidth, but labels
    are not selected (see also [GMPLS-FUNCT]).
    The resources reserved on each link of a restoration path may be
    shared across different working LSPs that are not expected to fail
    simultaneously.  Local node policies can be applied to define the
    degree to which capacity is shared across independent failures.
    Upon failure detection, LSP signaling is initiated along the
    restoration path to select labels, and to initiate the appropriate
    cross-connections.
  1. End-to-end LSP restoration with pre-signaled recovery bandwidth

reservation and label pre-selection: An end-to-end restoration

    path is pre-calculated before failure and a signaling procedure is
    initiated along this pre-selected path on which bandwidth is
    reserved and labels are selected (see also [GMPLS-FUNCT]).
    The resources reserved on each link may be shared across different
    working LSPs that are not expected to fail simultaneously.  In
    networks based on TDM, LSC and FSC technology, LSP signaling is
    used after failure detection to establish cross-connections at the
    intermediate switches on the restoration path using the pre-
    selected labels.
  1. Local LSP restoration: the above approaches can be applied on a

local basis rather than end-to-end, in order to reduce recovery

    time (note: no reference available at publication time).

Mannie Standards Track [Page 52] RFC 3945 GMPLS Architecture October 2004

11.8. Schema Selection Criteria

 This section discusses criteria that could be used by the operator in
 order to make a choice among the various P&R mechanisms.
  1. Robustness: In general, the less pre-planning of the restoration

path, the more robust the restoration scheme is to a variety of

    failures, provided that adequate resources are available.
    Restoration schemes with pre-planned paths will not be able to
    recover from network failures that simultaneously affect both the
    working and restoration paths.  Thus, these paths should ideally
    be chosen to be as disjoint as possible (i.e., SRLG and node
    disjoint), so that any single failure event will not affect both
    paths.  The risk of simultaneous failure of the two paths can be
    reduced by recalculating the restoration path whenever a failure
    occurs along it.
    The pre-selection of a label gives less flexibility for multiple
    failure scenarios than no label pre-selection.  If failures occur
    that affect two LSPs that are sharing a label at a common node
    along their restoration routes, then only one of these LSPs can be
    recovered, unless the label assignment is changed.
    The robustness of a restoration scheme is also determined by the
    amount of reserved restoration bandwidth - as the amount of
    restoration bandwidth sharing increases (reserved bandwidth
    decreases), the restoration scheme becomes less robust to
    failures.  Restoration schemes with pre-signaled bandwidth
    reservation (with or without label pre-selection) can reserve
    adequate bandwidth to ensure recovery from any specific set of
    failure events, such as any single SRLG failure, any two SRLG
    failures etc.  Clearly, more restoration capacity is allocated if
    a greater degree of failure recovery is required.  Thus, the
    degree to which the network is protected is determined by the
    policy that defines the amount of reserved restoration bandwidth.
  1. Recovery time: In general, the more pre-planning of the

restoration route, the more rapid the P&R scheme. Protection

    schemes generally recover faster than restoration schemes.
    Restoration with pre-signaled bandwidth reservation are likely to
    be (significantly) faster than path restoration with re-
    provisioning, especially because of the elimination of any
    crankback.  Local restoration will generally be faster than end-
    to-end schemes.

Mannie Standards Track [Page 53] RFC 3945 GMPLS Architecture October 2004

    Recovery time objectives for SONET/SDH protection switching (not
    including time to detect failure) are specified in [ITUT-G.841] at
    50 ms, taking into account constraints on distance, number of
    connections involved, and in the case of ring enhanced protection,
    number of nodes in the ring.
    Recovery time objectives for restoration mechanisms are being
    defined through a separate effort [RFC3386].
  1. Resource Sharing: 1+1 and 1:N link and LSP protection require

dedicated recovery paths with limited ability to share resources:

    1+1 allows no sharing, 1:N allows some sharing of protection
    resources and support of extra (pre-emptable) traffic.
    Flexibility is limited because of topology restrictions, e.g.,
    fixed ring topology for traditional enhanced protection schemes.
    The degree to which restoration schemes allow sharing amongst
    multiple independent failures is directly dictated by the size of
    the restoration pool.  In restoration schemes with re-
    provisioning, a pool of restoration capacity can be defined from
    which all restoration routes are selected after failure.  Thus,
    the degree of sharing is defined by the amount of available
    restoration capacity.  In restoration with pre-signaled bandwidth
    reservation, the amount of reserved restoration capacity is
    determined by the local bandwidth reservation policies.  In all
    restoration schemes, pre-emptable resources can use spare
    restoration capacity when that capacity is not being used for
    failure recovery.

12. Network Management

 Service Providers (SPs) use network management extensively to
 configure, monitor or provision various devices in their network.  It
 is important to note that a SP's equipment may be distributed across
 geographically separate sites thus making distributed management even
 more important.  The service provider should utilize an NMS system
 and standard management protocols such as SNMP (see [RFC3410],
 [RFC3411] and [RFC3416]) and the relevant MIB modules as standard
 interfaces to configure, monitor and provision devices at various
 locations.  The service provider may also wish to use the command
 line interface (CLI) provided by vendors with their devices. However,
 this is not a standard or recommended solution because there is no
 standard CLI language or interface, which results in N different CLIs
 in a network with devices from N different vendors. In the context of
 GMPLS, it is extremely important for standard interfaces to the SP's
 devices (e.g., SNMP) to exist due to the nature of the technology
 itself.  Since GMPLS comprises many different layers of control-plane

Mannie Standards Track [Page 54] RFC 3945 GMPLS Architecture October 2004

 and data-plane technology, it is important for management interfaces
 in this area to be flexible enough to allow the manager to manage
 GMPLS easily, and in a standard way.

12.1. Network Management Systems (NMS)

 The NMS system should maintain the collective information about each
 device within the system.  Note that the NMS system may actually be
 comprised of several distributed applications (i.e., alarm
 aggregators, configuration consoles, polling applications, etc.)
 that collectively comprises the SP's NMS.  In this way, it can make
 provisioning and maintenance decisions with the full knowledge of the
 entire SP's network.  Configuration or provisioning information
 (i.e., requests for new services) could be entered into the NMS and
 subsequently distributed via SNMP to the remote devices.  Thus,
 making the SP's task of managing the network much more compact and
 effortless rather than having to manage each device individually
 (i.e., via CLI).
 Security and access control can be achieved using the SNMPv3 User-
 based Security Model (USM) [RFC3414] and the View-based Access
 Control Model (VACM) [RFC3415].  This approach can be very
 effectively used within a SP's network, since the SP has access to
 and control over all devices within its domain.  Standardized MIBs
 will need to be developed before this approach can be used
 ubiquitously to provision, configure and monitor devices in non-
 heterogeneous networks or across SP's network boundaries.

12.2. Management Information Base (MIB)

 In the context of GMPLS, it is extremely important for standard
 interfaces to devices to exist due to the nature of the technology
 itself.  Since GMPLS comprises many different layers of control-plane
 technology, it is important for SNMP MIB modules in this area to be
 flexible enough to allow the manager to manage the entire control
 plane.  This should be done using MIB modules that may cooperate
 (i.e., coordinated row-creation on the agent) or through more
 generalized MIB modules that aggregate some of the desired actions to
 be taken and push those details down to the devices.  It is important
 to note that in certain circumstances, it may be necessary to
 duplicate some small subset of manageable objects in new MIB modules
 for management convenience.  Control of some parts of GMPLS may also
 be achieved using existing MIB interfaces (i.e., existing SONET MIB)
 or using separate ones, which are yet to be defined.  MIB modules may
 have been previously defined in the IETF or ITU.  Current MIB modules
 may need to be extended to facilitate some of the new functionality

Mannie Standards Track [Page 55] RFC 3945 GMPLS Architecture October 2004

 desired by GMPLS.  In these cases, the working group should work on
 new versions of these MIB modules so that these extensions can be
 added.

12.3. Tools

 As in traditional networks, standard tools such as traceroute
 [RFC1393] and ping [RFC2151] are needed for debugging and performance
 monitoring of GMPLS networks, and mainly for the control plane
 topology, that will mimic the data plane topology. Furthermore, such
 tools provide network reachability information. The GMPLS control
 protocols will need to expose certain pieces of information in order
 for these tools to function properly and to provide information
 germane to GMPLS.  These tools should be made available via the CLI.
 These tools should also be made available for remote invocation via
 the SNMP interface [RFC2925].

12.4. Fault Correlation between Multiple Layers

 Due to the nature of GMPLS, and that potential layers may be involved
 in the control and transmission of GMPLS data and control
 information, it is required that a fault in one layer be passed to
 the adjacent higher and lower layers to notify them of the fault.
 However, due to nature of these many layers, it is possible and even
 probable, that hundreds or even thousands of notifications may need
 to transpire between layers.  This is undesirable for several
 reasons.  First, these notifications will overwhelm the device.
 Second, if the device(s) are programmed to emit SNMP Notifications
 [RFC3417] then the large number of notifications the device may
 attempt to emit may overwhelm the network with a storm of
 notifications.  Furthermore, even if the device emits the
 notifications, the NMS that must process these notifications either
 will be overwhelmed or will be processing redundant information. That
 is, if 1000 interfaces at layer B are stacked above a single
 interface below it at layer A, and the interface at A goes down, the
 interfaces at layer B should not emit notifications.  Instead, the
 interface at layer A should emit a single notification.  The NMS
 receiving this notification should be able to correlate the fact that
 this interface has many others stacked above it and take appropriate
 action, if necessary.
 Devices that support GMPLS should provide mechanisms for aggregating,
 summarizing, enabling and disabling of inter-layer notifications for
 the reasons described above.  In the context of SNMP MIB modules, all
 MIB modules that are used by GMPLS must provide enable/disable
 objects for all notification objects. Furthermore, these MIBs must
 also provide notification summarization objects or functionality (as
 described above) as well.  NMS systems and standard tools which

Mannie Standards Track [Page 56] RFC 3945 GMPLS Architecture October 2004

 process notifications or keep track of the many layers on any given
 devices must be capable of processing the vast amount of information
 which may potentially be emitted by network devices running GMPLS at
 any point in time.

13. Security Considerations

 GMPLS defines a control plane architecture for multiple technologies
 and types of network elements.  In general, since LSPs established
 using GMPLS may carry high volumes of data and consume significant
 network resources, security mechanisms are required to safeguard the
 underlying network against attacks on the control plane and/or
 unauthorized usage of data transport resources.  The GMPLS control
 plane should therefore include mechanisms that prevent or minimize
 the risk of attackers being able to inject and/or snoop on control
 traffic.  These risks depend on the level of trust between nodes that
 exchange GMPLS control messages, as well as the realization and
 physical characteristics of the control channel.  For example, an in-
 band, in-fiber control channel over SONET/SDH overhead bytes is, in
 general, considered less vulnerable than a control channel realized
 over an out-of-band IP network.
 Security mechanisms can provide authentication and confidentiality.
 Authentication can provide origin verification, message integrity and
 replay protection, while confidentiality ensures that a third party
 cannot decipher the contents of a message.  In situations where GMPLS
 deployment requires primarily authentication, the respective
 authentication mechanisms of the GMPLS component protocols may be
 used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]).  Additionally,
 the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409])
 may be used to provide authentication, confidentiality or both, for a
 GMPLS control channel.  IPsec thus offers the benefits of combined
 protection for all GMPLS component protocols as well as key
 management.
 A related issue is that of the authorization of requests for
 resources by GMPLS-capable nodes.  Authorization determines whether a
 given party, presumable already authenticated, has a right to access
 the requested resources.  This determination is typically a matter of
 local policy control [RFC2753], for example by setting limits on the
 total bandwidth available to some party in the presence of resource
 contention.  Such policies may become quite complex as the number of
 users, types of resources and sophistication of authorization rules
 increases.
 After authenticating requests, control elements should match them
 against the local authorization policy.  These control elements must
 be capable of making decisions based on the identity of the

Mannie Standards Track [Page 57] RFC 3945 GMPLS Architecture October 2004

 requester, as verified cryptographically and/or topologically.  For
 example, decisions may depend on whether the interface through which
 the request is made is an inter- or intra-domain one.  The use of
 appropriate local authorization policies may help in limiting the
 impact of security breaches in remote parts of a network.
 Finally, it should be noted that GMPLS itself introduces no new
 security considerations to the current MPLS-TE signaling (RSVP-TE,
 CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management
 protocols (SNMP).

14. Acknowledgements

 This document is the work of numerous authors and consists of a
 composition of a number of previous documents in this area.
 Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH
 discussions we had together.  Thanks also to Pedro Falcao, Alexandre
 Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from
 Ebone for their SONET/SDH and optical technical advice and support.
 Finally, many thanks also to Krishna Mitra (Consultant), Curtis
 Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent)
 for their revision effort on Section 12.

15. References

15.1. Normative References

 [RFC3031]             Rosen, E., Viswanathan, A., and R. Callon,
                       "Multiprotocol Label Switching Architecture",
                       RFC 3031, January 2001.
 [RFC3209]             Awduche, D., Berger, L., Gan, D., Li, T.,
                       Srinivasan, V., and G. Swallow, "RSVP-TE:
                       Extensions to RSVP for LSP Tunnels", RFC 3209,
                       December 2001.
 [RFC3212]             Jamoussi, B., Andersson, L., Callon, R., Dantu,
                       R., Wu, L., Doolan, P., Worster, T., Feldman,
                       N., Fredette, A., Girish, M., Gray, E.,
                       Heinanen, J., Kilty, T., and A. Malis,
                       "Constraint-Based LSP Setup using LDP", RFC
                       3212, January 2002.
 [RFC3471]             Berger, L., "Generalized Multi-Protocol Label
                       Switching (GMPLS) Signaling Functional
                       Description", RFC 3471, January 2003.

Mannie Standards Track [Page 58] RFC 3945 GMPLS Architecture October 2004

 [RFC3472]             Ashwood-Smith, P. and L. Berger, "Generalized
                       Multi-Protocol Label Switching (GMPLS)
                       Signaling Constraint-based Routed Label
                       Distribution Protocol (CR-LDP) Extensions", RFC
                       3472, January 2003.
 [RFC3473]             Berger, L., "Generalized Multi-Protocol Label
                       Switching (GMPLS) Signaling Resource
                       ReserVation Protocol-Traffic Engineering
                       (RSVP-TE) Extensions", RFC 3473, January 2003.

15.2. Informative References

 [ANSI-T1.105]         "Synchronous Optical Network (SONET): Basic
                       Description Including Multiplex Structure,
                       Rates, And Formats," ANSI T1.105, 2000.
 [BUNDLE]              Kompella, K., Rekhter, Y., and L. Berger, "Link
                       Bundling in MPLS Traffic Engineering", Work in
                       Progress.
 [GMPLS-FUNCT]         Lang, J.P., Ed. and B. Rajagopalan, Ed.,
                       "Generalized MPLS Recovery Functional
                       Specification", Work in Progress.
 [GMPLS-G709]          Papadimitriou, D., Ed., "GMPLS Signaling
                       Extensions for G.709 Optical Transport Networks
                       Control", Work in Progress.
 [GMPLS-OVERLAY]       Swallow, G., Drake, J., Ishimatsu, H., and Y.
                       Rekhter, "GMPLS UNI: RSVP Support for the
                       Overlay Model", Work in Progress.
 [GMPLS-ROUTING]       Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
                       Extensions in Support of Generalized Multi-
                       Protocol Label Switching", Work in Progress.
 [RFC3946]             Mannie, E., Ed. and Papadimitriou D., Ed.,
                       "Generalized Multi-Protocol Label Switching
                       (GMPLS) Extensions for Synchronous Optical
                       Network (SONET) and Synchronous Digital
                       Hierarchy (SDH) Control", RFC 3946, October
                       2004.
 [HIERARCHY]           Kompella, K. and Y. Rekhter, "LSP Hierarchy
                       with Generalized MPLS TE", Work in Progress.

Mannie Standards Track [Page 59] RFC 3945 GMPLS Architecture October 2004

 [ISIS-TE]             Smit, H. and T. Li, "Intermediate System to
                       Intermediate System (IS-IS) Extensions for
                       Traffic Engineering (TE)", RFC 3784, June 2004.
 [ISIS-TE-GMPLS]       Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS
                       Extensions in Support of Generalized Multi-
                       Protocol Label Switching", Work in Progress.
 [ITUT-G.707]          ITU-T, "Network Node Interface for the
                       Synchronous Digital Hierarchy", Recommendation
                       G.707, October 2000.
 [ITUT-G.709]          ITU-T, "Interface for the Optical Transport
                       Network (OTN)," Recommendation G.709 version
                       1.0 (and Amendment 1), February 2001 (and
                       October 2001).
 [ITUT-G.841]          ITU-T, "Types and Characteristics of SDH
                       Network Protection Architectures,"
                       Recommendation G.841, October 1998.
 [LMP]                 Lang, J., Ed., "Link Management Protocol
                       (LMP)", Work in Progress.
 [LMP-WDM]             Fredette, A., Ed. and J. Lang Ed., "Link
                       Management Protocol (LMP) for Dense Wavelength
                       Division Multiplexing (DWDM) Optical Line
                       Systems", Work in Progress.
 [MANCHESTER]          J. Manchester, P. Bonenfant and C. Newton, "The
                       Evolution of Transport Network Survivability,"
                       IEEE Communications Magazine, August 1999.
 [OIF-UNI]             The Optical Internetworking Forum, "User
                       Network Interface (UNI) 1.0 Signaling
                       Specification - Implementation Agreement OIF-
                       UNI-01.0," October 2001.
 [OLI-REQ]             Fredette, A., Ed., "Optical Link Interface
                       Requirements," Work in Progress.
                       [OSPF-TE-GMPLS]       Kompella, K., Ed. and Y.
                       Rekhter, Ed., "OSPF Extensions in Support of
                       Generalized Multi-Protocol Label Switching",
                       Work in Progress.

Mannie Standards Track [Page 60] RFC 3945 GMPLS Architecture October 2004

 [OSPF-TE]             Katz, D., Kompella, K., and D. Yeung, "Traffic
                       Engineering (TE) Extensions to OSPF Version 2",
                       RFC 3630, September 2003.
 [RFC1393]             Malkin, G., "Traceroute Using an IP Option",
                       RFC 1393, January 1993.
 [RFC2151]             Kessler, G. and S. Shepard, "A Primer On
                       Internet and TCP/IP Tools and Utilities", RFC
                       2151, June 1997.
 [RFC2205]             Braden, R., Zhang, L., Berson, S., Herzog, S.,
                       and S. Jamin, "Resource ReSerVation Protocol
                       (RSVP) -- Version 1 Functional Specification",
                       RFC 2205, September 1997.
 [RFC2385]             Heffernan, A., "Protection of BGP Sessions via
                       the TCP MD5 Signature Option", RFC 2385, August
                       1998.
 [RFC2402]             Kent, S. and R. Atkinson, "IP Authentication
                       Header", RFC 2402, November 1998.
 [RFC2406]             Kent, S. and R. Atkinson, "IP Encapsulating
                       Security Payload (ESP)", RFC 2406, November
                       1998.
 [RFC2409]             Harkins, D. and D. Carrel, "The Internet Key
                       Exchange (IKE)", RFC 2409, November 1998.
                       [RFC2702]             Awduche, D., Malcolm, J.,
                       Agogbua, J., O'Dell, M., and J. McManus,
                       "Requirements for Traffic Engineering Over
                       MPLS", RFC 2702, September 1999.
 [RFC2747]             Baker, F., Lindell, B., and M. Talwar, "RSVP
                       Cryptographic Authentication", RFC 2747,
                       January 2000.
 [RFC2753]             Yavatkar, R., Pendarakis, D., and R. Guerin, "A
                       Framework for Policy-based Admission Control",
                       RFC 2753, January 2000.
 [RFC2925]             White, K., "Definitions of Managed Objects for
                       Remote Ping, Traceroute, and Lookup
                       Operations", RFC 2925, September 2000.

Mannie Standards Track [Page 61] RFC 3945 GMPLS Architecture October 2004

 [RFC3036]             Andersson, L., Doolan, P., Feldman, N.,
                       Fredette, A., and B. Thomas, "LDP
                       Specification", RFC 3036, January 2001.
 [RFC3386]             Lai, W. and D. McDysan, "Network Hierarchy and
                       Multilayer Survivability", RFC 3386, November
                       2002.
 [RFC3410]             Case, J., Mundy, R., Partain, D., and B.
                       Stewart, "Introduction and Applicability
                       Statements for Internet-Standard Management
                       Framework", RFC 3410, December 2002.
 [RFC3411]             Harrington, D., Presuhn, R., and B. Wijnen, "An
                       Architecture for Describing Simple Network
                       Management Protocol (SNMP) Management
                       Frameworks", STD 62, RFC 3411, December 2002.
 [RFC3414]             Blumenthal, U. and B. Wijnen, "User-based
                       Security Model (USM) for version 3 of the
                       Simple Network Management Protocol (SNMPv3)",
                       STD 62, RFC 3414, December 2002.
 [RFC3415]             Wijnen, B., Presuhn, R., and K. McCloghrie,
                       "View-based Access Control Model (VACM) for the
                       Simple Network Management Protocol (SNMP)", STD
                       62, RFC 3415, December 2002.
 [RFC3416]             Presuhn, R., "Version 2 of the Protocol
                       Operations for the Simple Network Management
                       Protocol (SNMP)", STD 62, RFC 3416, December
                       2002.
 [RFC3417]             Presuhn, R., "Transport Mappings for the Simple
                       Network Management Protocol (SNMP)", STD 62,
                       RFC 3417, December 2002.
 [RFC3469]             Sharma, V. and F. Hellstrand, "Framework for
                       Multi-Protocol Label Switching (MPLS)-based
                       Recovery", RFC 3469, February 2003.
 [RFC3477]             Kompella, K. and Y. Rekhter, "Signalling
                       Unnumbered Links in Resource ReSerVation
                       Protocol - Traffic Engineering (RSVP-TE)", RFC
                       3477, January 2003.

Mannie Standards Track [Page 62] RFC 3945 GMPLS Architecture October 2004

 [RFC3479]             Farrel, A., "Fault Tolerance for the Label
                       Distribution Protocol (LDP)", RFC 3479,
                       February 2003.
 [RFC3480]             Kompella, K., Rekhter, Y., and A. Kullberg,
                       "Signalling Unnumbered Links in CR-LDP
                       (Constraint-Routing Label Distribution
                       Protocol)", RFC 3480, February 2003.
 [SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma,
                       "Framework for GMPLS-based Control of SDH/SONET
                       Networks", Work in Progress.

16. Contributors

 Peter Ashwood-Smith
 Nortel
 P.O. Box 3511 Station C,
 Ottawa, ON K1Y 4H7, Canada
 EMail: petera@nortelnetworks.com
 Eric Mannie
 Consult
 Phone:  +32 2 648-5023
 Mobile: +32 (0)495-221775
 EMail: eric_mannie@hotmail.com
 Daniel O. Awduche
 Consult
 EMail: awduche@awduche.com
 Thomas D. Nadeau
 Cisco
 250 Apollo Drive
 Chelmsford, MA 01824, USA
 EMail: tnadeau@cisco.com

Mannie Standards Track [Page 63] RFC 3945 GMPLS Architecture October 2004

 Ayan Banerjee
 Calient
 5853 Rue Ferrari
 San Jose, CA 95138, USA
 EMail: abanerjee@calient.net
 Lyndon Ong
 Ciena
 10480 Ridgeview Ct
 Cupertino, CA 95014, USA
 EMail: lyong@ciena.com
 Debashis Basak
 Accelight
 70 Abele Road, Bldg.1200
 Bridgeville, PA 15017, USA
 EMail: dbasak@accelight.com
 Dimitri Papadimitriou
 Alcatel
 Francis Wellesplein, 1
 B-2018 Antwerpen, Belgium
 EMail: dimitri.papadimitriou@alcatel.be
 Lou Berger
 Movaz
 7926 Jones Branch Drive
 MCLean VA, 22102, USA
 EMail: lberger@movaz.com
 Dimitrios Pendarakis
 Tellium
 2 Crescent Place, P.O. Box 901
 Oceanport, NJ 07757-0901, USA
 EMail: dpendarakis@tellium.com

Mannie Standards Track [Page 64] RFC 3945 GMPLS Architecture October 2004

 Greg Bernstein
 Grotto
 EMail: gregb@grotto-networking.com
 Bala Rajagopalan
 Tellium
 2 Crescent Place, P.O. Box 901
 Oceanport, NJ 07757-0901, USA
 EMail: braja@tellium.com
 Sudheer Dharanikota
 Consult
 EMail: sudheer@ieee.org
 Yakov Rekhter
 Juniper
 1194 N. Mathilda Ave.
 Sunnyvale, CA 94089, USA
 EMail: yakov@juniper.net
 John Drake
 Calient
 5853 Rue Ferrari
 San Jose, CA 95138, USA
 EMail: jdrake@calient.net
 Debanjan Saha
 Tellium
 2 Crescent Place
 Oceanport, NJ 07757-0901, USA
 EMail: dsaha@tellium.com

Mannie Standards Track [Page 65] RFC 3945 GMPLS Architecture October 2004

 Yanhe Fan
 Axiowave
 200 Nickerson Road
 Marlborough, MA 01752, USA
 EMail: yfan@axiowave.com
 Hal Sandick
 Shepard M.S.
 2401 Dakota Street
 Durham, NC 27705, USA
 EMail: sandick@nc.rr.com
 Don Fedyk
 Nortel
 600 Technology Park Drive
 Billerica, MA 01821, USA
 EMail: dwfedyk@nortelnetworks.com
 Vishal Sharma
 Metanoia
 1600 Villa Street, Unit 352
 Mountain View, CA 94041, USA
 EMail: v.sharma@ieee.org
 Gert Grammel
 Alcatel
 Lorenzstrasse, 10
 70435 Stuttgart, Germany
 EMail: gert.grammel@alcatel.de
 George Swallow
 Cisco
 250 Apollo Drive
 Chelmsford, MA 01824, USA
 EMail: swallow@cisco.com

Mannie Standards Track [Page 66] RFC 3945 GMPLS Architecture October 2004

 Dan Guo
 Turin
 1415 N. McDowell Blvd,
 Petaluma, CA 95454, USA
 EMail: dguo@turinnetworks.com
 Z. Bo Tang
 Tellium
 2 Crescent Place, P.O. Box 901
 Oceanport, NJ 07757-0901, USA
 EMail: btang@tellium.com
 Kireeti Kompella
 Juniper
 1194 N. Mathilda Ave.
 Sunnyvale, CA 94089, USA
 EMail: kireeti@juniper.net
 Jennifer Yates
 AT&T
 180 Park Avenue
 Florham Park, NJ 07932, USA
 EMail: jyates@research.att.com
 Alan Kullberg
 NetPlane
 888 Washington
 St.Dedham, MA 02026, USA
 EMail: akullber@netplane.com
 George R. Young
 Edgeflow
 329 March Road
 Ottawa, Ontario, K2K 2E1, Canada
 EMail: george.young@edgeflow.com

Mannie Standards Track [Page 67] RFC 3945 GMPLS Architecture October 2004

 Jonathan P. Lang
 Rincon Networks
 EMail: jplang@ieee.org
 John Yu
 Hammerhead Systems
 640 Clyde Court
 Mountain View, CA 94043, USA
 EMail: john@hammerheadsystems.com
 Fong Liaw
 Solas Research
 Solas Research, LLC
 EMail: fongliaw@yahoo.com
 Alex Zinin
 Alcatel
 1420 North McDowell Ave
 Petaluma, CA 94954, USA
 EMail: alex.zinin@alcatel.com

17. Author's Address

 Eric Mannie (Consultant)
 Avenue de la Folle Chanson, 2
 B-1050 Brussels, Belgium
 Phone:  +32 2 648-5023
 Mobile: +32 (0)495-221775
 EMail:  eric_mannie@hotmail.com

Mannie Standards Track [Page 68] RFC 3945 GMPLS Architecture October 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 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 AND THE
 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed
 to pertain to the implementation or use of the technology
 described in this document or the extent to which any license
 under such rights might or might not be available; nor does it
 represent that it has made any independent effort to identify any
 such rights.  Information on the IETF's procedures with respect to
 rights in IETF 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Mannie Standards Track [Page 69]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3945.txt · Last modified: 2004/10/28 16:40 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki