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