tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3945

 Errata 
Proposed STD
Pages: 69
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CCAMP

Generalized Multi-Protocol Label Switching (GMPLS) Architecture

Part 1 of 3, p. 1 to 16
None       Next RFC Part

Updated by:    6002


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
       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

Top      ToC       Page 4 
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

Top      ToC       Page 5 
   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:

Top      ToC       Page 6 
   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).

Top      ToC       Page 7 
   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

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   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.

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

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

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

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

Top      ToC       Page 11 
   -  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.

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

   -  While traditional TE-based (and even LDP-based) LSPs are
      unidirectional, GMPLS supports the establishment of bi-directional
      LSPs.

   -  GMPLS supports the termination of an LSP on a specific egress
      port, i.e., the port selection at the destination side.

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

   Note also some other key differences between MPLS-TE and GMPLS:

   -  For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP
      can be performed only in discrete units.

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

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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:

   -  First, links that are non-PSC may yet have TE properties; however,
      an OSPF adjacency could not be brought up directly on such links.

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

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

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
      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.



(page 16 continued on part 2)

Next RFC Part