Network Working Group Eric Mannie (Ebone) - Editor
Internet Draft
Expiration date: Dec. 2001 Peter Ashwood-Smith (Nortel)
Daniel Awduche (Movaz)
Ayan Banerjee (Calient)
Debashis Basak (Accelight)
Lou Berger (Movaz)
Greg Bernstein (Ciena)
John Drake (Calient)
Yanhe Fan (Axiowave)
Don Fedyk (Nortel)
Gert Grammel (Alcatel)
Kireeti Kompella (Juniper)
Alan Kullberg (NetPlane)
Jonathan P. Lang (Calient)
Fong Liaw (Zaffire)
Thomas D. Nadeau (Cisco)
Dimitri Papadimitriou (Alcatel)
Dimitrios Pendarakis (Tellium)
Bala Rajagopalan (Tellium)
Yakov Rekhter (Juniper)
Debanjan Saha (Tellium)
Hal Sandick (Nortel)
Vishal Sharma (Metanoia)
George Swallow (Cisco)
Z. Bo Tang (Tellium)
John Yu (Zaffire)
Alex Zinin (Cisco)
June 2001
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
draft-ietf-ccamp-gmpls-architecture-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
E. Mannie et. al. Internet-Draft December 2001 1
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Table of Contents
1. Abstract........................................................4
1.1 List of open issues............................................4
2. Conventions used in this document...............................4
3. Introduction....................................................4
3.1. Acronyms & abbreviations......................................5
3.2. Multiple Types of Switching and Forwarding Hierarchies........5
3.3. Extension of the MPLS Control Plane...........................7
3.4. Key Differences Between MPLS-TE and GMPLS....................10
4. Routing and addressing model...................................11
4.1 Addressing of PSC and non-PSC layers..........................12
4.2 GMPLS scalability enhancements................................12
4.3 Extensions to IP TE routing protocols.........................13
5. Unnumbered links...............................................14
5.1 Unnumbered Forwarding Adjacencies.............................15
6. Link bundling..................................................15
6.1 Restrictions on bundling......................................16
6.2 Routing considerations for bundling...........................16
6.3 Signaling considerations......................................17
6.3.1 Mechanism 1: Implicit Indication............................17
6.3.2 Mechanism 2: Explicit Indication by IP Address..............17
6.3.3 Mechanism 3: Explicit Indication by Component Interface ID..17
6.4 Unnumbered Bundled Link.......................................18
6.5 Forming TE links..............................................18
7. UNI and NNI....................................................19
7.1 OIF UNI versus GMPLS..........................................19
7.2 Routing at the UNI............................................20
8. Link Management................................................20
8.1 Control channel and control channel management................21
8.2 Link property correlation.....................................22
8.3 Link connectivity verification................................22
8.4 Fault management..............................................23
9. Generalized Signaling..........................................23
9.1. Overview: How to Request an LSP..............................25
9.2. Generalized Label Request....................................26
9.3. SONET/SDH Traffic Parameters.................................27
9.4. Bandwidth Encoding...........................................28
9.5. Generalized Label............................................28
9.6. Waveband Switching...........................................29
9.7. Label Suggestion by the Upstream.............................29
9.8. Label Restriction by the Upstream............................29
9.9. Bi-directional LSP...........................................30
9.10. Bi-directional LSP Contention Resolution....................31
9.11. Rapid Notification of Failure...............................31
9.12. Link Protection.............................................31
9.13. Explicit Routing and Explicit Label Control.................32
9.14. LSP modification and LSP re-routing.........................33
E. Mannie et. al. Internet-Draft December 2001 2
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
9.15. Route recording.............................................33
10. Forwarding Adjacencies (FA)...................................34
10.1 Routing and Forwarding Adjacencies...........................34
10.2. Signaling aspects...........................................35
10.3 Cascading of Forwarding Adjacencies..........................35
11.1 Network Management Systems (NMS).............................36
12. Security considerations.......................................38
13. Acknowledgements..............................................39
14. References....................................................39
15. Author's Addresses............................................41
Full Copyright Statement..........................................43
Appendix 1 Brief overview of the ITU-T work on G.ASTN/G.ASON......45
A.1 Terminology issues............................................45
A.2 Common Equipment Management [G.cemr]..........................45
A.3 Data Communications Network [G.dcn]...........................46
A.4 Distributed Connection Management [G.dcm].....................46
A.5 Generalized Automatic Neighbor Discovery [G.ndisc]............47
A.6 Generalized Automatic Service Discovery [G.sdisc].............47
A.7 OTN routing [G.rtg]...........................................47
A.8 OTN Connection Admission Control [G.cac]......................47
A.9 OTN Link Management [G.lm]....................................48
E. Mannie et. al. Internet-Draft December 2001 3
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
1. Abstract
Future data and transmission networks will consist of elements such
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs),
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc
that will use Generalized MPLS (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. SDH/SONET, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main 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.
1.1 List of open issues
This section lists several open issues on which the various people
are currently working.
- Inter-domain operations (e.g. routing with BGP-4).
- Protection and restoration for GMPLS.
- Multicasting in GMPLS.
- Extensions for new technologies like G.709.
- VPN support.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Introduction
The architecture presented 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 layer may
work jointly in a different way, resulting in a number of possible
combinations, at the discretion of manufacturers and operators.
This document is a generalization of the MPLS architecture [MPLS-
ARCH], 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).
E. Mannie et. al. Internet-Draft December 2001 4
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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 draft 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 networks. Specific details of the
separate building blocks can be found in the corresponding
documents.
3.1. Acronyms & abbreviations
ABR Area Border Router
AS Autonomous System
ASBR Autonomous System Boundary Router
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
STM(-N) Synchronous Transport Module (-N)
STS(-N) Synchronous Transport Signal-Level N (SONET)
TE Traffic Engineering
3.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 [MPLS-ARCH] 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
E. Mannie et. al. Internet-Draft December 2001 5
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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, can't forward data based on the
information carried in either packet or cell headers. Specifically,
such LSRs include devices where the forwarding 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 forward 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 forward data
based on the content of the frame/cell header. Examples include
interfaces on Ethernet bridges that forward 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 forward data based on the data's time slot in a
repeating cycle. An example of such an interface is that of a
SDH/SONET Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop
Multiplexer (ADM). Other examples include interfaces implementing
G.709 (the "digital wrapper") and PDH interfaces.
4. Lambda Switch Capable (LSC) interfaces:
Interfaces that forward 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.
5. Fiber-Switch Capable (FSC) interfaces:
Interfaces that forward 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.
E. Mannie et. al. Internet-Draft December 2001 6
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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 SDH/SONET LSP (VC-12) nested in a higher order SDH/SONET
LSP (VC-4). Several levels of signal (LSP) nesting are defined in
the SDH/SONET multiplexing hierarchy.
The nesting can also occur between interfaces. 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 an TDM interface,
which in turn 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.
3.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 is 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 are
described in more detail 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].
E. Mannie et. al. Internet-Draft December 2001 7
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
GMPLS is indeed based on the Traffic Engineering (TE) extensions to
MPLS, a.k.a. MPLS-TE. This is because most of the technologies that
can be used below the PSC level require some traffic engineering.
The placement of LSPs at these levels needs in general to take
several constraints into consideration (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, the
nodes performing 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
trajectories may also require some external simulations using
heuristics that serve as input for the actual path calculation and
LSP establishment process.
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, 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 adds
additional extensions for TDM, LSC, and FSC traffic engineering.
Only a very few elements are technology specific.
Thus, GMPLS extends the two signaling protocols defined for MPLS-TE
signaling, i.e. RSVP-TE and CR-LDP. 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 is based on RSVP-TE and CR-LDP, it mandates a
downstream-on-demand label allocation and distribution, with an
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, i.e. OSPF-TE and IS-IS-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.
E. Mannie et. al. Internet-Draft December 2001 8
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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. Some slight adaptations of that
control plane are thus required if we want to 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, verify the physical connectivity of the data-
bearing links, correlate the link property information, and manage
link failures. A unique feature of LMP is that it is able to
localize faults in both opaque and transparent networks, 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 run between data-plane adjacent nodes. As a result,
LMP can be reused in other contexts with non-GMPLS signaling
protocols.
The 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 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.
E. Mannie et. al. Internet-Draft December 2001 9
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
3.4. Key Differences Between MPLS-TE and GMPLS
Some key differences between MPLS-TE and GMPLS 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 LSR.
- 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, 1 or 10Gb
Ethernet, etc.
- 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.
- The use of Forwarding Adjacencies (FA), provides a mechanism that
can improve bandwidth utilization, when bandwidth allocation can be
performed only in discrete units, as well as a mechanism to
aggregate forwarding state, thus allowing the number of required
labels to be reduced
- GMPLS allows for a label to be suggested 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
along 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.
E. Mannie et. al. Internet-Draft December 2001 10
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
4. 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 and
that traditional (distributed) IP routing protocols are also 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, one cannot do
anymore the assumption that control-plane neighbors (i.e. IGP-learnt
neighbors) are 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, and are also used to find
routes for non-PSC circuits by using a CSPF algorithm.
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 to
take advantages 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).
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 SDH/SONET
network operated by a given carrier. The set of interconnected ASs
being an SDH/SONET Internetwork.
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 in
the context of non-PSC layers are for further study.
Each AS can be subdivided 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 nodes. 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 SDH/SONET Terminal
Multiplexer (TM). Another example, is an SDH/SONET interface card
within an IP router or ATM switch.
E. Mannie et. al. Internet-Draft December 2001 11
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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
intra-area traffic engineering. However, inter-area traffic
engineering is also under investigation.
4.1 Addressing of PSC and non-PSC layers
The fact that IPv4 and/or IPv6 addresses are used doesn't imply at
all that they should be allocated in the same addressing space than
public IPv4 and/or IPv6 addresses used for the Internet. Each layer
could have a different addressing authority responsible for address
allocation and re-using the full addressing space, completely
independently.
Private IP addresses can be used if they don't 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.
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. SDH/SONET nodes) than we have today IP hosts and routers.
Other kinds of addressing schemes (e.g. NSAP) are not considered
here since this would imply a modification of the already existing
signaling and routing protocols that uses IPv4 and/or IPv6
addresses. This would be incompatible to our objectives of re-using
existing IP protocols.
4.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.
E. Mannie et. al. Internet-Draft December 2001 12
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
4.3 Extensions to IP TE 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,
and 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 cannot 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 a
separate section.
- 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 which may be configured
on the advertising LSR, others which may be obtained from other LSRs
by means of some protocol, and yet others which 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, 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.
E. Mannie et. al. Internet-Draft December 2001 13
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
A TE link between a pair of LSRs doesn't 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 ISIS adjacencies are established "control channels".
5. 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 ISIS-TE and OSPF-TE.
A. The ability to specify unnumbered links in MPLS TE signaling
requires extensions to RSVP-TE and CR-LDP. The MPLS-TE signaling
doesn't provide support for unnumbered links, because it doesnÆt
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. Note that links are directed,
i.e., a link l is from some LSR A to some other LSR B. LSR A chooses
the interface identifier for link l, we call this the "outgoing
interface identifier from LSR A's point of view". If there is a
reverse link from LSR B to LSR A, B chooses the outgoing interface
identifier for the reverse link, we call this the linkÆs "incoming
interface identifier" from LSR AÆs point of view. There is no a
priori relationship between the two interface identifiers. Both ends
must also agree on each of these identifiers.
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 outgoing interface identifier with
respect to that upstream LSR.
The new Unnumbered Interface ID sub-object/sub-TLV for the RR Object
contains the outgoing interface 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 ISIS-TE and for the TE LSA (which is an
opaque LSA) defined in OSPF-TE. An Outgoing Interface Identifier
sub-TLV and an Incoming Interface Identifier sub-TLV are defined.
E. Mannie et. al. Internet-Draft December 2001 14
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
5.1 Unnumbered Forwarding Adjacencies
If an LSR that originates an LSP advertises this LSP as an
unnumbered FA in IS-IS or OSPF, the LSR must allocate an Interface
ID to that FA. If the LSP is bi-directional, the tail end LSR
advertises the reverse LSP as an unnumbered FA, the tail end LSR
must allocate an Interface ID to the reverse FA.
Signaling has been enhanced to carry the Interface ID. When an LSP
is created which will be advertised as an FA, the head-end LSR
includes its Interface ID in the Path/REQUEST. The tail end LSR
responds by including its reverse LSPÆs Interface ID in the
Resv/MAPPING.
The Interface ID is transported in the new LSP Tunnel Interface ID
object/TLV called the Forward Interface ID when it appears in a
Path/REQUEST message, and the Reverse Interface ID when it appears
in the Resv/MAPPING message.
The LSP Tunnel Interface ID object/TLV contains the Router ID of the
LSR that generates it, and the Interface ID. Note that if the
forward or reverse LSP is part of a bundled link, the Interface ID
is set to the Component Interface ID of that LSP (as defined in the
next section).
6. Link bundling
The concept of link bundling is essential in certain networks
employing the GMPLS control plane. 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 in order 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.
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.
E. Mannie et. al. Internet-Draft December 2001 15
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
6.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, i.e. they
must have the same:
- Link Type (i.e. point-to-point or multi-access) [OSPF-TE/ISIS-TE],
- TE Metric (i.e. an administrative cost) [OSPF- TE/ISIS-TE],
- Set of Resource Classes (i.e. colors) [OSPF-TE/ISIS-TE],
- Link Multiplex Capability (e.g. FSC, LSC or TDM) [HIERARCHY].
Note that bundling may be applied recursively; a component link may
itself be a bundled link. An FA may also be a component link. In
fact, a bundle can consist of a mix of point-to-point links, FAs,
and bundled links, but all sharing some common properties.
6.2 Routing considerations for bundling
A bundled link is just another kind of TE link such as those defined
by OSPF-TE or IS-IS-TE. The liveness of the bundled link is
determined by the liveness of each of the component links within the
bundled link. 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 Tunnel specification 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.
Note that advertising a (bundled) TE link between a pair of LSRs
doesn't 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 [OSPF-TE-GMPLS] and [ISIS-TE-
GMPLS] 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
E. Mannie et. al. Internet-Draft December 2001 16
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
6.3 Signaling considerations
Typically, an LSP's explicit route (contained in an explicit route)
will choose the bundled link to be used for the LSP, but not the
component link(s), since information about the bundled link is
flooded, but information about the component links is kept local to
the LSR.
The choice of the component link to use is always made by an
upstream node. If the LSP is bidirectional, the upstream node
chooses a component link in each direction.
Three mechanisms for indicating this choice to the downstream node
are possible.
6.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.
6.3.2 Mechanism 2: Explicit Indication by IP Address
This mechanism requires that each component link has a unique remote
IP address. The upstream node can either send messages addressed to
the remote IP address for the component link or encapsulate messages
in an IP header whose destination address is the remote IP address.
This mechanism does not require each component link to have its own
control channel. In fact, it doesn't even require the whole
(bundled) link to have its own control channel.
6.3.3 Mechanism 3: Explicit Indication by Component Interface ID
With this mechanism, each component link in unnumbered and is
assigned a unique Component Interface Identifier (32 bits value).
The two LSRs at each end of the bundled link exchange these
identifiers. An upstream node indicates the choice of a component
link by including the corresponding identifier in signaling
messages.
Discovering Component Interface Identifiers at bootstrap may be
accomplished by configuration, by means of a protocol such as LMP
(preferred solution), by means of RSVP/CR-LDP (especially in the
E. Mannie et. al. Internet-Draft December 2001 17
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
case where a component link is a Forwarding Adjacency), or by means
of IS-IS or OSPF extensions.
New objects are needed to indicate Component Interface Identifiers
in signaling. GMPLS defines one Component Upstream Interface ID
object/TLV used to indicate the component interface to be used for
traffic flowing in the upstream direction; and one Component
Downstream Interface ID object/TLV used to indicate the component
interface to be used for traffic flowing in the downstream
direction. Since the choice of the component link to use is always
made by an upstream node, these objects/TLVs are included in the
Path/REQUEST message send downstream. With RSVP-TE they are included
in the sendor descriptor of the Path message.
6.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.
6.5 Forming TE 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 Link Multiplex Capability, the second
property could be the Link Type, 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) or delay.
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 some link in the primary path belongs
to. 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
E. Mannie et. al. Internet-Draft December 2001 18
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
between two adjacent nodes. Thus, the number of bundles in practice
may not be large.
7. UNI and NNI
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
7.2 and the section about signaling with an explicit route).
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.
For that purpose a very few specific UNI particularities have been
ignored in a first time. GMPLS is being enhanced to support such
particularities at the UNI by some other standardization bodies,
like the OIF.
7.1 OIF UNI versus GMPLS
The current OIF UNI specification [OIF-UNI] defines an interface
between a client SDH/SONET equipment and an SDH/SONET network, each
belonging to a distinct administrative authority. 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 protocols, the type of
concatenation, the transparency levels 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 a sub-set of the GMPLS
Architecture.
E. Mannie et. al. Internet-Draft December 2001 19
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
7.2 Routing at 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.
- 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 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.
- 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.
- 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.
- 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.
8. 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.
E. Mannie et. al. Internet-Draft December 2001 20
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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) has been defined to fulfill these operations. LMP was
initiated in the context of GMPLS but is a generic toolbox that can
be also used in other contexts.
Control channel management and link property correlation are
mandatory procedures of LMP. Link connectivity verification and
fault management are optional procedures.
8.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.
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 must be developed to manage links, both in terms of
link provisioning and fault isolation.
LMP does not specify how control channels are implemented, 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.
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.
E. Mannie et. al. Internet-Draft December 2001 21
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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 unnecessarily.
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) 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 the event of a control channel failure, it may be
possible to use an alternate active control channel without
coordination.
8.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 to add component links to a link bundle,
change a link's protection mechanism, change port identifiers, or
change component identifiers in a bundle. This mechanism is
supported by an exchange of link summary messages.
8.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.
The use of this procedure is negotiated as part of the configuration
exchange that take place during the negotiation phase of the Hello
protocol. This procedure should be done 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.
E. Mannie et. al. Internet-Draft December 2001 22
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
Note that the Test message is the only LMP message that is
transmitted over the 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 both nodes to
exchange the Test messages simultaneously.
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
mechanism that are supported, 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.
8.4 Fault management
Fault management is an important requirement from the operational
point of view. When a failure occurs an operator needs to know
exactly where it happened. It can also be used to support some
specific local protection/restoration mechanisms. Logically, fault
localization can occur only after a fault is detected. LMP provides
a fault notification procedure that can be used to rapidly localize
link failures.
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).
As part of the fault notification procedure, the 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 span or path
protection/restoration procedures.
9. 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.
E. Mannie et. al. Internet-Draft December 2001 23
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
The core GMPLS signaling specification is available in three parts:
1. A signaling functional description [GMPLS-SIG].
2. RSVP-TE extensions [RSVP-TE-GMPLS].
3. CR-LDP extensions [CR-LDP-GMPLS].
In addition, independent parts are available per technology:
1. GMPLS extensions for SONET and SDH control [SONETSDH-GMPLS].
The following MPLS profile applies to GMPLS:
- Downstream-on-demand label allocation and distribution.
- Ingress initiated ordered control.
- Liberal (typical), or conservative (could) label retention
mode.
- Request, traffic/data, or topology driven label allocation
strategy.
- Explicit routing (typical), or hop-by-hop routing (could).
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 to ingress node.
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.
These building blocks will be described in mode 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 and 8 are
optional.
A typical SDH/SONET switching network would implement building
blocks: 1, 2 (the SDH/SONET label), 6, 9 and 10. Building blocks 7
and 8 are optional since the protection/restoration can be achieved
using SDH/SONET overhead bytes.
E. Mannie et. al. Internet-Draft December 2001 24
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
A typical wavelength switching network would implement building
blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8 and 9. 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 and 9.
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.
9.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 (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
SDH/SONET LSP. For some other technology there 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 protection type is
for further study.
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 downstream to 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.
E. Mannie et. al. Internet-Draft December 2001 25
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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 SDH/SONET signal
is requested, several labels can be returned.
In case of SDH/SONET 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 SDH/SONET contiguous concatenation, only one
label is returned. That label is the lowest signal of the contiguous
concatenated signal (given an order specified in [SONETSDH-GMPLS]).
In case of SDH/SONET "multiplication", i.e. co-routing of circuits
of the same type but without concatenation but all belonging to the
same LSP, the explicit list of all signals that take part in the LSP
is returned.
9.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 two major characteristics
(parameters) required to support the LSP being requested: the LSP
encoding type, 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.
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 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 of the LSP 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
E. Mannie et. al. Internet-Draft December 2001 26
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
parameters as explained hereafter. Currently, only one specific set
of traffic parameters is defined, for SONET/SDH.
Note that it is expected than specific traffic parameters will be
defined in the future for photonic (all optical) switching.
9.3. SONET/SDH Traffic Parameters
The SDH/SONET traffic parameters [SONETSDH-GMPLS] specify indeed a
powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T
G.707). Optional non-standard capabilities are also available.
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:
- First, contiguous concatenation can be optionally applied on the
Elementary Signal, resulting in a contiguously concatenated
signal.
- Second, virtual concatenation can be optionally applied either
directly on the elementary Signal, or on the contiguously
concatenated signal obtained from the previous phase.
- Third, some transparency can be optionally specified when
requesting a frame as signal rather than a container. Several
transparency packages are defined.
- 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, either it is omitted
or a default value is used. The content of the FLOWSPEC object
received in a Resv message must be identical to the content of the
SENDER_TSPEC of the corresponding Path message. In other words, the
receiver is not allowed to change the values of the traffic
parameters. However some level of negotiation may be achieved as
explained in [SONETSDH-GMPLS]
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
new TLV.
E. Mannie et. al. Internet-Draft December 2001 27
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
9.4. 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, for which bandwidth the traffic parameters fully defined
the requested SONET/SDH signal.
The bandwidth is coded in the Peak Data Rate field of Int-Serv
objects for RSVP-TE and in the Peak and Committed Data Rate fields
of the CR-LDP Traffic Parameters TLV.
9.5. 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 time-slot 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 SDH/SONET 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.
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.
E. Mannie et. al. Internet-Draft December 2001 28
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
9.6. 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
wavelength label except that semantically the waveband can be
subdivided into wavelengths whereas the wavelength can only be
subdivided into time or statistically multiplexed labels.
9.7. 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
MAPPING/Resv 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.
9.8. 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 four cases
where a label restriction is useful in the "optical" domain.
1. The first case is where the end equipment is only capable of
transmitting and receiving on a small specific set of
wavelengths/bands.
2. The second case is where 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.
E. Mannie et. al. Internet-Draft December 2001 29
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
3. The third case is where it is desirable to limit the amount of
wavelength conversion being performed to reduce the distortion on
the optical signals.
4. The last case is where two ends of a link support different sets
of wavelengths.
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 it's 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.
9.9. 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 and 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] or
[CR-LDP] 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.
4. It is more difficult to provide a clean interface for SDH/SONET
equipment that may rely on bi-directional hop-by-hop paths for
protection switching. Note that existing SDH/SONET gear transmits
the control information in-band with the data.
E. Mannie et. al. Internet-Draft December 2001 30
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
9.10. 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. The GMPLS signaling defines a procedure to resolve
that contention, basically the node with the higher node ID will win
the contention. To reduce the probability of contention, some
mechanisms are also suggested.
9.11. Rapid Notification of Failure
GMPLS defines three signaling extensions for RSVP-TE that enable
expedited notification of failures and other events to nodes
responsible for restoring failed LSPs, and modify error handling.
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.
Such extensions can be used by fast restoration mechanisms.
The final extension is an RSVP optimization to allow the faster
removal of intermediate states in some cases.
9.12. 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 take this
information into account 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
E. Mannie et. al. Internet-Draft December 2001 31
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
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 [GMPLS-SIG] section 7.1 for a
precise definition of each.
9.13. Explicit Routing and Explicit Label Control
Using an explicit route can control the path taken by an LSP more or
less precisely. Typically, the node at the head-end of an LSP finds
a more or less precise explicit route and builds an Explicit Route
Object (ERO)/ Explicit Route (ER) TLV that contains that route.
Possibly, the edge node doesnÆt build any explicit route, and just
transmit a signaling request to a default neighbor LSR (as IP hosts
today). 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 imperfect 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 node may include other
network nodes that are not part of the strict 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 to an egress
node.
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.
E. Mannie et. al. Internet-Draft December 2001 32
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
Another use is when an optimization algorithm is used for an
SDH/SONET network. This algorithm can provide very detailed explicit
routes, including the label (time-slot) to use on a link, in order
to minimize the fragmentation of the SDH/SONET multiplex on the
corresponding interface.
Another use is when the label indicates a particular component in a
bundle in order to stay diverse with other components of that
bundle, i.e. to control the usage of components in a bundle for
different LSPs.
9.14. 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
studies are required to understand the impact of dynamically
changing some SDH/SONET circuit characteristics such as the
bandwidth, the protection type, the transparency, the concatenation,
etc.
9.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:
- 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).
- 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.
- 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.
E. Mannie et. al. Internet-Draft December 2001 33
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
10. 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 don't 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 unidirectional link into ISIS/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).
An LSR may (under its local configuration control) announce an LSP
as a link into ISIS/OSPF. When this link is advertised into the
same instance of ISIS/OSPF as the one that determines the route
taken by the LSP, we call such a link a "forwarding adjacency" (FA).
We refer to the LSP as the "forwarding adjacency LSP", or just FA-
LSP. Note that since the advertised entity is a link in ISIS/OSPF,
both the endpoint LSRs of the FA-LSP must belong to the same ISIS
level/OSPF area (intra-area improvement of scalability).
In general, creation/termination of a FA and its FA-LSP could be
driven either by mechanisms outside of MPLS (e.g., via configuration
control on the LSR at the head-end of the adjacency), or by
mechanisms within MPLS (e.g., as a result of the LSR at the head-end
of the adjacency receiving LSP setup requests originated by some
other LSRs).
ISIS/OSPF floods the information about FAs just as it floods the
information about any other links. As a result of 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.
10.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 ISIS 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.
E. Mannie et. al. Internet-Draft December 2001 34
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
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 ISIS/OSPF peering relation between the routers at the
ends of the adjacency.
10.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).
10.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 named the Link Multiplex Capability sub-TLV and
complements the sub-TLVs defined in [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
E. Mannie et. al. Internet-Draft December 2001 35
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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.
11. 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, making distributed management even
more important. The service provider should utilize an NMS system
and standard management protocols such as SNMP [RFC1901] [RFC1902]
[RFC1903] [RFC1904] [RFC1905] [RFC1906] and its associated MIBs 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,
but this however, is not a standard or recommended solution due to
the fact that there is no standard CLI language or interface, which
results in N different CLIÆs 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 (SNMP) to
exist due to the nature of the technology itself. Since GMPLS
comprises many different layers of control-plane 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.
11.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 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, making the
SPÆs job of managing the network much more compact and effortless
than having to manage each device individually (i.e.: via CLI).
Security and access control can be achieved through the use of
SNMPv3 and the View Access Control Model [SNMPv3VACM]. This approach
can be very effectively used within an SP 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 boundaries.
E. Mannie et. al. Internet-Draft December 2001 36
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
11.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 MIBs in this area to be
flexible enough to allow the manager to manage the entire control
plane. This should be through a set of MIBs that may cooperate
(i.e.: coordinated row-creation on the agent), or through more
generalized MIBs 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 MIBs for the
convenience of management. Control of some parts of GMPLS may also
be achieved though the use of existing MIB interfaces (i.e.:
existing SONET MIB), or though separate ones, which are yet to be
defined. MIBs may have been previously defined in the IETF or ITU.
Existing MIBs may need to be extended to facilitate some of the new
functionality desired by GMPLS. In these cases, the working group
should work on new versions of these MIBs so that these extensions
can be added.
11.3 Tools
As in traditional networks, standard tools such as traceroute
[RFC1393] and ping [RFC1739] 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].
11.4 Fault Correlation Between Multiple Layers
Due to the nature of GMPLS and the fact that potential layers may be
involved in the control and transmission of GMPLS data and control
information, it is therefore required that a fault in one layer be
passed to the adjacent higher and lower layers in an effort 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 [RFC1901] 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 will either 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
E. Mannie et. al. Internet-Draft December 2001 37
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
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 MIBs, all MIBs 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 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.
12. Security considerations
GMPLS defines a new control plane architecture for multiple types of
network elements. In general, since LSPs established using GMPLS are
expected to 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.
Security requirements depend on the level of trust between nodes
that exchange GMPLS control messages as well as the exposure of the
control channel to third parties. In general, a network node may
apply more relaxed security requirements when exchanging GMPLS
control messages with nodes under the same administrative domain
than when talking to nodes in a different domain. In this respect,
network to user (UNI) and network-to-network interfaces are expected
to have higher security requirements than node-to-node interfaces.
Security mechanisms can provide two main properties: 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 ([RFC2747], [LDP], [RFC2385],
[LMP]). Additionally, the IPSEC suite of protocols ([RFC2402],
[RFC2406], [RFC2409]) may be used to provide authentication,
confidentiality or both, for a GMPLS control channel; this option
offers the benefit of combined protection of all GMPLS component
protocols.
Note however 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).
E. Mannie et. al. Internet-Draft December 2001 38
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
13. Acknowledgements
This draft is the work of numerous authors and consists of a
composition of a number of previous drafts in this area.
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SDH/SONET
discussions that we had together. Thanks also to Pedro Falcao
(Ebone) and Michael Moelants (Ebone) for their SDH/SONET and optical
technical advice and support. Finally, many thanks also to Krishna
Mitra (Calient) and Curtis Villamizar (Avici).
A list of the drafts from which material and ideas were incorporated
follows:
[GMPLS-SIG] draft-ietf-mpls-generalized-signaling-04.txt
Generalized MPLS - Signaling Functional Description
[RSVP-TE-GMPLS] draft-ietf-mpls-generalized-rsvp-te-03.txt
Generalized MPLS Signaling - RSVP-TE Extensions
[CR-LDP-GMPLS] draft-ietf-mpls-generalized-cr-ldp-03.txt
Generalized MPLS Signaling - CR-LDP Extensions
[SONETSDH-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-01.txt
GMPLS Extensions for SONET and SDH Control
[LMP] draft-ietf-mpls-lmp-01.txt
Link Management Protocol (LMP)
[HIERARCHY] draft-ietf-mpls-lsp-hierarchy-02.txt
LSP Hierarchy with MPLS TE
[RSVP-TE-UNNUM] draft-ietf-mpls-rsvp-unnum-01.txt
Signalling Unnumbered Links in RSVP-TE
[CR-LDP-UNNUM] draft-ietf-mpls-crldp-unnum-01.txt
Signalling Unnumbered Links in CR-LDP
[BUNDLE] draft-kompella-mpls-bundle-05.txt
Link Bundling in MPLS Traffic Engineering
[OSPF-TE-GMPLS] draft-kompella-ospf-gmpls-extensions-01.txt
OSPF Extensions in Support of Generalized MPLS
[ISIS-TE-GMPLS] draft-ietf-isis-gmpls-extensions-02.txt
IS-IS Extensions in Support of Generalized MPLS
14. References
[RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF
RFC 1393, January 1993.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based
E. Mannie et. al. Internet-Draft December 2001 39
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
SNMPv2", IETF RFC 1901, January 1996.
[RFC1902] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management Information for
Version 2 of the Simple Network Management Protocol
(SNMPv2)", IETF RFC 1901, January 1996.
[RFC1903] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version 2 of the
Simple Network Management Protocol (SNMPv2)",
IETF RFC 1901, January 1996.
[RFC1904] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Conformance Statements for Version 2 of
the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1901, January 1996.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1905, January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)",
IETF RFC 1906, January 1996.
[SNMPv3VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-
based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)", IETF RFC 2575,
April 1999.
[RFC1739] G. Kessler, S. Shepard , "A Primer On Internet and
TCP/IP Tools", RFC1739, December 1994.
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, Standard
Track, April 1998.
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option", RFC 2370
Standard Track, July 1998.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP
MD5 Signature Option," IETF RFC 2385.
[RFC2402] S. Kent and R. Atkinson, "IP Authentication Header,"
RFC 2402.
[RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)," IETF RFC 2406.
[RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange
(IKE)", IETF RFC 2409.
[RFC2747] F. Baker et al. "RSVP Cryptographic Authentication",
E. Mannie et. al. Internet-Draft December 2001 40
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
IETF RFC 2747.
[RFC2925] K. White , "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", IETF RFC
2925, September 2000.
[LPD] L. Andersson, P. Doolan, N. Feldman, A. Fredette,
B. Thomas, "LDP Specification", IETF RFC 3036, January
2001.
[OSPF-TE] D. Katz, D. Yeung, and K. Kompella, "Traffic
Engineering Extensions to OSPF" draft-katz-yeung-ospf-
traffic-05.txt.
[LMP-WDM] A. Fredette et al., "Link Management Protocol (LMP) for
WDM Transmission Systems," Internet Draft, Work in
Progress, draft-fredette-lmp-wdm-01.txt, March 2001.
[MPLS-TEO] D. Awduche et al., "Multi-Protocol Lambda Switching:
Combining MPLS Traffic Engineering Control With Optical
Crossconnects," Internet Draft, Work in Progress,
draft-awduche-mpls-te-optical-03.txt, April 2001.
15. Author's Addresses
Peter Ashwood-Smith Eric Mannie (editor)
Nortel Networks Corp. Ebone (GTS)
P.O. Box 3511 Station C, Terhulpsesteenweg 6A
Ottawa, ON K1Y 4H7 1560 Hoeilaart
Canada Belgium
Phone: +1 613 763 4534 Phone: +32 2 658 56 52
Email: Email: eric.mannie@gts.com
petera@nortelnetworks.com
Daniel O. Awduche Thomas D. Nadeau
Movaz Networks Cisco Systems, Inc.
7296 Jones Branch Drive 250 Apollo Drive
Suite 615 Chelmsford, MA 01824
McLean, VA 22102 USA
USA Phone: +1 978 244 3051
Phone: +1 703 847-7350 Email: tnadeau@cisco.com
Email: awduche@movaz.com
Ayan Banerjee Dimitri Papadimitriou
Calient Networks Alcatel - IPO NSG
5853 Rue Ferrari Francis Wellesplein, 1
San Jose, CA 95138 B-2018 Antwerpen
USA Belgium
Phone: +1 408 972-3645 Phone: +32 3 240-84-91
Email: abanerjee@calient.net Email:
dimitri.papadimitriou@alcatel.be
E. Mannie et. al. Internet-Draft December 2001 41
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
Debashis Basak Dimitrios Pendarakis
Accelight Networks Tellium, Inc.
70 Abele Road, Bldg.1200 2 Crescent Place
Bridgeville, PA 15017 P.O. Box 901
USA Oceanport, NJ 07757-0901
Phone: +1 412 220-2102 (ext115) USA
email: dbasak@accelight.com Email: DPendarakis@tellium.com
Lou Berger Bala Rajagopalan
Movaz Networks, Inc. Tellium, Inc.
7926 Jones Branch Drive 2 Crescent Place
Suite 615 P.O. Box 901
MCLean VA, 22102 Oceanport, NJ 07757-0901
USA USA
Phone: +1 703 847-1801 Phone: +1 732 923 4237
Email: lberger@movaz.com Email: braja@tellium.com
Greg Bernstein Yakov Rekhter
Ciena Corporation Juniper
10480 Ridgeview Court Email: yakov@juniper.net
Cupertino, CA 94014
USA
Phone: +1 408 366 4713
Email: greg@ciena.com
John Drake Hal Sandick
Calient Networks Nortel Networks
5853 Rue Ferrari Email:
San Jose, CA 95138 hsandick@nortelnetworks.com
USA
Phone: +1 408 972 3720
Email: jdrake@calient.net
Yanhe Fan Debanjan Saha
Axiowave Networks, Inc. Tellium Optical Systems
100 Nickerson Road 2 Crescent Place
Marlborough, MA 01752 Oceanport, NJ 07757-0901
USA USA
Phone: +1 508 460 6969 Ext. 627 Phone: +1 732 923 4264
Email: yfan@axiowave.com Email: dsaha@tellium.com
Don Fedyk Vishal Sharma
Nortel Networks Corp. Metanoia, Inc.
600 Technology Park Drive 335 Elan Village Lane
Billerica, MA 01821 San Jose, CA 95134
USA USA
Phone: +1-978-288-4506 Phone: +1 408 943 1794
Email: Email: vsharma87@yahoo.com
dwfedyk@nortelnetworks.com
E. Mannie et. al. Internet-Draft December 2001 42
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
Gert Grammel George Swallow
Alcatel Cisco Systems, Inc.
Via Trento, 30 250 Apollo Drive
20059 Vimercate (Mi) Chelmsford, MA 01824
Italy USA
Email: gert.grammel@alcatel.it Phone: +1 978 244 8143
Email: swallow@cisco.com
Kireeti Kompella Z. Bo Tang
Juniper Networks, Inc. Tellium, Inc.
1194 N. Mathilda Ave. 2 Crescent Place
Sunnyvale, CA 94089 P.O. Box 901
USA Oceanport, NJ 07757-0901
Email: kireeti@juniper.net USA
Phone: +1 732 923 4231
Email: btang@tellium.com
Alan Kullberg John Yu
NetPlane Systems, Inc. Zaffire Inc.
888 Washington 2630 Orchard Parkway
St.Dedham, MA 02026 San Jose, CA 95134
USA USA
Phone: +1 781 251-5319 Email: jzyu@zaffire.com
Email: akullber@netplane.com
Jonathan P. Lang Alex Zinin
Calient Networks Cisco Systems
25 Castilian 150 W. Tasman Dr.
Goleta, CA 93117 San Jose, CA 95134
Email: jplang@calient.net Email: azinin@cisco.com
Fong Liaw
Zaffire Inc.
2630 Orchard Parkway
San Jose, CA 95134
USA
Email: fliaw@zaffire.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
E. Mannie et. al. Internet-Draft December 2001 43
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
E. Mannie et. al. Internet-Draft December 2001 44
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
Appendix 1 Brief overview of the ITU-T work on G.ASTN/G.ASON
This appendix gives a brief overview of the work performed in ITU-T
related to the control plane for transport networks, and briefly
links it to the IETF related work.
In ITU-T the work is performed in Study Group (SG) 13/Question 10
for G.astn, SG15/Q12 for G.ason and SG15/Q14 for G.dcn, G.dcm,
G.ndisc, G.sdisc and G.cemr.
G.astn describes the network level requirements for the control plane
of Automatically Switched Transport Networks (ASTNs). Such a network
provides a set of control functions for the purpose of setting up and
releasing connections across a network. It is recognized that
transport networks support multiple clients. As such, ASTNs are
intended to be client independent.
A.1 Terminology issues
A common misunderstanding is related to the usage of terms like
layer, LSP and client/server. In IETF the expression "layer" is
attached to a technology present in a network like e.g. OTN, SDH,
ATM, IP. However ITU-T uses the term "layer" for any kind of
mapping. This includes the mapping between different technologies
like SDH/SONET in OTN as well as internal mappings like SDH/SONET
low order layer and high order layer. In this case a client server
relationship between layers is automatically present. In order to
avoid misunderstandings the term "technology" is used hereafter to
represent the IETF understanding of a layer.
In GMPLS the notion of Label Switched Path (LSP) is defined to
describe connections between two Label Switch Routers (LSRs). In
packet switched networks LSPs can be "tunneled" by encapsulating a
packet into another packet within the same technology (also known as
"label stacking"). What is considered to be encapsulation in IETF is
considered to be a mapping in ITU-T that implies the use of a
client-server layer relationship.
In ITU-T the terms "client" and "server" are used to define the role
of a layer with respect to another layer e.g. SDH can be the client
layer of an OTN server layer network. This distinction is not used
in IETF where a layer is associated to a certain type of technology.
Instead the term "client" is used for a customer device attached to
a service provider network, both belonging to distinct
administrative authorities.
A.2 Common Equipment Management [G.cemr]
The G.cemr recommendation specifies those Equipment Management
Functions (EMF) requirements that are common for SDH and OTN.
The equipment management function (EMF) provides the means through
which a Network Element Level manager manages the Network Element
Function (NEF).
E. Mannie et. al. Internet-Draft December 2001 45
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
These kinds of functions are not detailed in the current GMPLS work
since it is focused on control plane related aspects. Network
Management aspects are subject of other working groups in IETF.
A.3 Data Communications Network [G.dcn]
According to G.dcn the various functions, which constitute a
telecommunications network, can be classified into two broad
functional groups. One is the transport functional group, which
transfers any telecommunications information from one point to
another point(s). The other is the control functional group, which
realizes various ancillary services and operations and maintenance
functions.
The Data Communications Network (DCN) provides transport for the
applications associated with the control functional group. Examples
of such applications that are transported by the DCN are: transport
network operations/management applications, DCN
operations/management applications, Automatic Switched Transport
Services (ASTN) control plane applications, voice communications,
etc.
The IP-based DCN provides Layer 1 (physical), Layer 2 (data-link)
and Layer 3 (network) functionality and consists of
routing/switching functionality interconnected via links. These
links can be implemented over various interfaces, including WAN and
LAN interfaces.
This recommendation provides the architecture requirements for an
IP-based DCN, the requirements for inter-working between an IP-based
DCN and an OSI-based DCN, and the IP-based DCN interface
specifications.
Since in GMPLS the signaling and management plane are orthogonal to
each other, different kinds of networks can be used for both tasks.
In GMLS, LMP defines mechanisms for the control channel management,
which is used to establish and maintain control channels between
nodes. However, GMPLS assume that messages are transported by IP but
doesnÆt specify how the DCN should be implemented.
A.4 Distributed Connection Management [G.dcm]
The G.dcm Recommendation covers the areas associated with the
signaling aspects of automatic switched transport network, such as
attribute specifications, the message sets, the interface
requirements, the DCM state diagrams, and the interworking functions
for the distributed connection management
This is the main purpose of the GMPLS signaling, using extensions to
protocols like CR-LDP and RSVP-TE.
E. Mannie et. al. Internet-Draft December 2001 46
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
A.5 Generalized Automatic Neighbor Discovery [G.ndisc]
The G.ndisc Recommendation provides the requirements and message
sets for the automatic neighbor for the User-to-Network Interface
(UNI), Internal Node-to-Node Interface (I-NNI), External Node-to-
Node Interface (E-NNI) and Physical Interface (PI). These
requirements determine the discovery process across these interfaces
that aid automated connection management.
GMPLS is an IP centric control plane incorporating protocols defined
for routing and neighbor discovery such OSPF and IS-IS. In addition,
LMP fulfills some of these requirements as well, especially for the
component links of bundled link.
A.6 Generalized Automatic Service Discovery [G.sdisc]
The G.sdisc Recommendation provides the requirements and message
sets for the automatic service discovery for the User-to-Network
Interface (UNI), Internal Node-to-Node Interface (I-NNI), External
Node-to-Node Interface (E-NNI) and Physical Interface (PI). These
requirements determine the discovery process across these interfaces
that aid automated connection management.
GMPLS signaling and routing protocols LMP allows some level of
automatic service discovery.
A.7 OTN routing [G.rtg]
No ITU-T contribution available yet.
IP based intra-domain (e.g. OSPF, IS-IS) and inter-domain (e.g. BGP-
4) routing protocols are the strength of a GMPLS control plane.
Moreover, BGP-4 is the only practical solution for policy routing
between different operators that was proved on a very large scale.
GMPLS extends the TE extensions to OSPF and IS-IS. Work on BGP-4 is
ongoing.
A.8 OTN Connection Admission Control [G.cac]
According to G.astn, Connection Admission Control (CAC) is necessary
for authentication of the user and controlling access to network
resources. CAC shall be provided as part of the control plane
functionality. It is the role of the CAC function to determine if
there is sufficient free resource available to allow a new
connection. If there is, the CAC may permit the connection request to
proceed, alternatively, if there is not, it shall notify the
originator of the connection request that the request has been
denied. Connections may be denied on the basis of available free
capacity or alternatively on the basis of prioritization. CAC
policies are outside the scope of standardization.
GMPLS achieves authentication (and other security related features)
using the broad range of security mechanisms available in the GMPLS
protocols themselves and/or using IPSEC.
E. Mannie et. al. Internet-Draft December 2001 47
draft-ietf-ccamp-gmpls-architecture-00.txt June 2001
A.9 OTN Link Management [G.lm]
No ITU-T contribution available yet.
The Link Management Protocol (LMP) of GMPLS is a collection of
procedures between adjacent nodes that provide local services such
as control channel management, link connectivity verification, link
property correlation, and fault management.
E. Mannie et. al. Internet-Draft December 2001 48
Datatracker
draft-ietf-ccamp-gmpls-architecture-00
This is an older version of an Internet-Draft that was ultimately published as RFC 3945.
