draft-ietf-ccamp-gmpls-architecture-04.txt   draft-ietf-ccamp-gmpls-architecture-05.txt 
CCAMP Working Group Eric Mannie - Editor Network Working Group Eric Mannie - Editor
Internet Draft Internet Draft
Category: Standard Track
Expiration date: August 2003 February 2003 Expiration date: September 2003 March 2003
Generalized Multi-Protocol Label Switching (GMPLS) Architecture Generalized Multi-Protocol Label Switching Architecture
draft-ietf-ccamp-gmpls-architecture-04.txt draft-ietf-ccamp-gmpls-architecture-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Future data and transmission networks will consist of elements such Future data and transmission networks will consist of elements such
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), as routers, switches, Dense Wavelength Division Multiplexing (DWDM)
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. systems, Add-Drop Multiplexors (ADMs), photonic cross-connects
that will use Generalized MPLS (GMPLS) to dynamically provision (PXCs), optical cross-connects (OXCs), etc. that will use
resources and to provide network survivability using protection and Generalized Multi-Protocol Label Switching (GMPLS) to dynamically
restoration techniques. provision resources and to provide network survivability using
protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extends This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709), MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main focus of GMPLS is on the fiber to outgoing port or fiber). The focus of GMPLS is on the
control plane of these various layers since each of them can use control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane. cover both the signaling and the routing part of that control plane.
E. Mannie (Editor) et. al. û Expires: August 2003 1 E. Mannie (Editor) et al. Standard Track 1
1. Table of Contents 1. Table of Contents
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
1. Table of Contents ............................................. 2 1. Table of Contents ............................................. 2
2. Conventions used in this document ............................. 3 2. Conventions used in this document ............................. 3
3. Introduction .................................................. 3 3. Introduction .................................................. 3
3.1. Acronyms & Abbreviations .................................... 4 3.1. Acronyms & Abbreviations .................................... 4
3.2. Multiple Types of Switching and Forwarding Hierarchies ...... 4 3.2. Multiple Types of Switching and Forwarding Hierarchies ...... 4
skipping to change at line 104 skipping to change at line 106
9.8. Label Suggestion by the Upstream ........................... 30 9.8. Label Suggestion by the Upstream ........................... 30
9.9. Label Restriction by the Upstream .......................... 31 9.9. Label Restriction by the Upstream .......................... 31
9.10. Bi-directional LSP ........................................ 31 9.10. Bi-directional LSP ........................................ 31
9.11. Bi-directional LSP Contention Resolution .................. 32 9.11. Bi-directional LSP Contention Resolution .................. 32
9.12. Rapid Notification of Failure ............................. 32 9.12. Rapid Notification of Failure ............................. 32
9.13. Link Protection ........................................... 33 9.13. Link Protection ........................................... 33
9.14. Explicit Routing and Explicit Label Control ............... 34 9.14. Explicit Routing and Explicit Label Control ............... 34
9.15. Route Recording ........................................... 34 9.15. Route Recording ........................................... 34
9.16. LSP Modification and LSP Re-routing ....................... 35 9.16. LSP Modification and LSP Re-routing ....................... 35
9.17. LSP Administrative Status Handling ........................ 35 9.17. LSP Administrative Status Handling ........................ 35
9.18. Control Channel Separation ................................ 36
E. Mannie (Editor) et. al. - Expires August 2003 2 E. Mannie (Editor) et al. Standard Track 2
9.18. Control Channel Separation ................................ 36
10. Forwarding Adjacencies (FA) ................................. 37 10. Forwarding Adjacencies (FA) ................................. 37
10.1. Routing and Forwarding Adjacencies ........................ 38 10.1. Routing and Forwarding Adjacencies ........................ 38
10.2. Signaling Aspects ......................................... 39 10.2. Signaling Aspects ......................................... 38
10.3. Cascading of Forwarding Adjacencies ....................... 39 10.3. Cascading of Forwarding Adjacencies ....................... 39
11. Routing and Signaling Adjacencies ........................... 39 11. Routing and Signaling Adjacencies ........................... 39
12. Control Plane Fault Handling ................................ 40 12. Control Plane Fault Handling ................................ 40
13. LSP Protection and Restoration .............................. 41 13. LSP Protection and Restoration .............................. 41
13.1. Protection Escalation across Domains and Layers ........... 42 13.1. Protection Escalation across Domains and Layers ........... 42
13.2. Mapping of Services to P&R Resources ...................... 43 13.2. Mapping of Services to P&R Resources ...................... 43
13.3. Classification of P&R Mechanism Characteristics ........... 43 13.3. Classification of P&R Mechanism Characteristics ........... 43
13.4. Different Stages in P&R ................................... 44 13.4. Different Stages in P&R ................................... 44
13.5. Recovery Strategies ....................................... 44 13.5. Recovery Strategies ....................................... 44
13.6. Recovery mechanisms: Protection schemes ................... 45 13.6. Recovery mechanisms: Protection schemes ................... 45
13.7. Recovery mechanisms: Restoration schemes .................. 45 13.7. Recovery mechanisms: Restoration schemes .................. 45
13.8. Schema Selection Criteria ................................. 46 13.8. Schema Selection Criteria ................................. 46
14. Network Management .......................................... 48 14. Network Management .......................................... 47
14.1. Network Management Systems (NMS) .......................... 48 14.1. Network Management Systems (NMS) .......................... 48
14.2. Management Information Base (MIB) ......................... 48 14.2. Management Information Base (MIB) ......................... 48
14.3. Tools ..................................................... 49 14.3. Tools ..................................................... 49
14.4. Fault Correlation Between Multiple Layers ................. 49 14.4. Fault Correlation Between Multiple Layers ................. 49
15. Security Considerations ..................................... 50 15. Security Considerations ..................................... 49
16. Acknowledgements ............................................ 50 16. Acknowledgements ............................................ 50
17. Intellectual Property Considerations ........................ 52 17. Intellectual Property Considerations ........................ 50
18. References .................................................. 52 18. References .................................................. 51
18.1 Normative References ....................................... 52 18.1 Normative References ....................................... 51
18.2 Information References ..................................... 54 18.2 Information References ..................................... 53
19. Author's Address ............................................ 55 19. Author's Address ............................................ 54
20. Contributors ................................................ 55 20. Contributors ................................................ 54
Full Copyright Statement ........................................ 57 Full Copyright Statement ........................................ 57
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in [RFC2119].
3. Introduction 3. Introduction
The architecture presented in this document covers the main building The architecture presented in this document covers the main building
blocks needed to build a consistent control plane for multiple blocks needed to build a consistent control plane for multiple
switching layers. It does not restrict the way that these layers switching layers. It does not restrict the way that these layers
work together. Different models can be applied: e.g. overlay, work together. Different models can be applied: e.g. overlay,
augmented or integrated. Moreover, each pair of contiguous layers augmented or integrated. Moreover, each pair of contiguous layers
may collaborate in different ways, resulting in a number of possible may collaborate in different ways, resulting in a number of possible
combinations, at the discretion of manufacturers and operators. combinations, at the discretion of manufacturers and operators.
This architecture clearly separates the control plane and the This architecture clearly separates the control plane and the
forwarding plane. In addition, it also clearly separates the control forwarding plane. In addition, it also clearly separates the control
plane in two parts, the signaling plane containing the signaling plane in two parts, the signaling plane containing the signaling
protocols and the routing plane containing the routing protocols. protocols and the routing plane containing the routing protocols.
This document is a generalization of the MPLS architecture This document is a generalization of the Multi-Protocol Label
[RFC3031], and in some cases may differ slightly from that Switching (MPLS) architecture [RFC3031], and in some cases may
architecture since non packet-based forwarding planes are now
E. Mannie (Editor) et. al. - Expires August 2003 3 E. Mannie (Editor) et al. Standard Track 3
considered. It is not the intention of this document to describe differ slightly from that architecture since non packet-based
concepts already described in the current MPLS architecture. The forwarding planes are now considered. It is not the intention of
goal is to describe specific concepts of Generalized MPLS (GMPLS). 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 However, some of the concepts explained hereafter are not part of
the current MPLS architecture and are applicable to both MPLS and the current MPLS architecture and are applicable to both MPLS and
GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy). GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy).
Since these concepts were introduced together with GMPLS and since Since these concepts were introduced together with GMPLS and since
they are of paramount importance for an operational GMPLS network, they are of paramount importance for an operational GMPLS network,
they will be discussed here. they will be discussed here.
The organization of the remainder of this draft is as follows. We The organization of the remainder of this draft is as follows. We
begin with an introduction of GMPLS. We then present the specific begin with an introduction of GMPLS. We then present the specific
GMPLS building blocks and explain how they can be combined together GMPLS building blocks and explain how they can be combined together
to build an operational GMPLS network. Specific details of the to build an operational GMPLS network. Specific details of the
separate building blocks can be found in the corresponding separate building blocks can be found in the corresponding
documents. documents.
3.1. Acronyms & Abbreviations 3.1. Acronyms & Abbreviations
ABR Area Border Router
AS Autonomous System AS Autonomous System
ASBR Autonomous System Boundary Router
BGP Border Gateway Protocol BGP Border Gateway Protocol
CR-LDP Constraint-based Routing LDP CR-LDP Constraint-based Routing LDP
CSPF Constraint-based Shortest Path First CSPF Constraint-based Shortest Path First
DWDM Dense Wavelength Division Multiplexing DWDM Dense Wavelength Division Multiplexing
FA Forwarding Adjacency FA Forwarding Adjacency
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multi-Protocol Label Switching
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
LDP Label Distribution Protocol LDP Label Distribution Protocol
LMP Link Management Protocol LMP Link Management Protocol
LSA Link State Advertisement LSA Link State Advertisement
LSR Label Switching Router LSR Label Switching Router
LSP Label Switched Path LSP Label Switched Path
MIB Management Information Base MIB Management Information Base
MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching
NMS Network Management System NMS Network Management System
OXC Optical Cross-Connect OXC Optical Cross-Connect
PXC Photonic Cross-Connect PXC Photonic Cross-Connect
RSVP ReSource reserVation Protocol RSVP ReSource reserVation Protocol
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Networks
STM(-N) Synchronous Transport Module (-N) STM(-N) Synchronous Transport Module (-N)
STS(-N) Synchronous Transport Signal-Level N (SONET) STS(-N) Synchronous Transport Signal-Level N (SONET)
TDM Time Division Multiplexing
TE Traffic Engineering TE Traffic Engineering
3.2. Multiple Types of Switching and Forwarding Hierarchies 3.2. Multiple Types of Switching and Forwarding Hierarchies
Generalized MPLS (GMPLS) differs from traditional MPLS in that it Generalized MPLS (GMPLS) differs from traditional MPLS in that it
supports multiple types of switching, i.e. the addition of support supports multiple types of switching, i.e. the addition of support
for TDM, lambda, and fiber (port) switching. The support for the for TDM, lambda, and fiber (port) switching. The support for the
additional types of switching has driven GMPLS to extend certain additional types of switching has driven GMPLS to extend certain
E. Mannie (Editor) et al. Standard Track 4
base functions of traditional MPLS and, in some cases, to add base functions of traditional MPLS and, in some cases, to add
functionality. These changes and additions impact basic LSP functionality. These changes and additions impact basic LSP
E. Mannie (Editor) et. al. - Expires August 2003 4
properties: how labels are requested and communicated, the properties: how labels are requested and communicated, the
unidirectional nature of LSPs, how errors are propagated, and unidirectional nature of LSPs, how errors are propagated, and
information provided for synchronizing the ingress and egress LSRs. information provided for synchronizing the ingress and egress LSRs.
The MPLS architecture [RFC3031] was defined to support the The MPLS architecture [RFC3031] was defined to support the
forwarding of data based on a label. In this architecture, Label forwarding of data based on a label. In this architecture, Label
Switching Routers (LSRs) were assumed to have a forwarding plane Switching Routers (LSRs) were assumed to have a forwarding plane
that is capable of (a) recognizing either packet or cell boundaries, that is capable of (a) recognizing either packet or cell boundaries,
and (b) being able to process either packet headers (for LSRs and (b) being able to process either packet headers (for LSRs
capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs
capable of recognizing cell boundaries). capable of recognizing cell boundaries).
The original MPLS architecture is here being extended to include The original MPLS architecture is here being extended to include
LSRs whose forwarding plane recognizes neither packet, nor cell LSRs whose forwarding plane recognizes neither packet, nor cell
boundaries, and therefore, can't forward data based on the boundaries, and therefore, can't forward data based on the
information carried in either packet or cell headers. Specifically, information carried in either packet or cell headers. Specifically,
such LSRs include devices where the forwarding decision is based on such LSRs include devices where the switching decision is based on
time slots, wavelengths, or physical ports. So, the new set of LSRs, time slots, wavelengths, or physical ports. So, the new set of LSRs,
or more precisely interfaces on these LSRs, can be subdivided into or more precisely interfaces on these LSRs, can be subdivided into
the following classes: the following classes:
1. Packet Switch Capable (PSC) interfaces: 1. Packet Switch Capable (PSC) interfaces:
Interfaces that recognize packet boundaries and can forward data Interfaces that recognize packet boundaries and can forward data
based on the content of the packet header. Examples include based on the content of the packet header. Examples include
interfaces on routers that forward data based on the content of the interfaces on routers that forward data based on the content of the
IP header and interfaces on routers that forward data based on the IP header and interfaces on routers that switch data based on the
content of the MPLS "shim" header. content of the MPLS "shim" header.
2. Layer-2 Switch Capable (L2SC) interfaces: 2. Layer-2 Switch Capable (L2SC) interfaces:
Interfaces that recognize frame/cell boundaries and can forward data Interfaces that recognize frame/cell boundaries and can switch data
based on the content of the frame/cell header. Examples include based on the content of the frame/cell header. Examples include
interfaces on Ethernet bridges that forward data based on the interfaces on Ethernet bridges that switch data based on the content
content of the MAC header and interfaces on ATM-LSRs that forward of the MAC header and interfaces on ATM-LSRs that forward data based
data based on the ATM VPI/VCI. on the ATM VPI/VCI.
3. Time-Division Multiplex Capable (TDM) interfaces: 3. Time-Division Multiplex Capable (TDM) interfaces:
Interfaces that forward data based on the data's time slot in a Interfaces that switch data based on the data's time slot in a
repeating cycle. An example of such an interface is that of a repeating cycle. An example of such an interface is that of a
SDH/SONET Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop
Multiplexer (ADM). Other examples include interfaces providing G.709 Multiplexer (ADM). Other examples include interfaces providing G.709
TDM capabilities (the "digital wrapper") and PDH interfaces. TDM capabilities (the "digital wrapper") and PDH interfaces.
4. Lambda Switch Capable (LSC) interfaces: 4. Lambda Switch Capable (LSC) interfaces:
Interfaces that forward data based on the wavelength on which the Interfaces that switch data based on the wavelength on which the
data is received. An example of such an interface is that of a data is received. An example of such an interface is that of a
Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can
operate at the level of an individual wavelength. Additional operate at the level of an individual wavelength. Additional
examples include PXC interfaces that can operate at the level of a examples include PXC interfaces that can operate at the level of a
E. Mannie (Editor) et al. Standard Track 5
group of wavelengths, i.e. a waveband and G.709 interfaces providing group of wavelengths, i.e. a waveband and G.709 interfaces providing
optical capabilities. optical capabilities.
E. Mannie (Editor) et. al. - Expires August 2003 5
5. Fiber-Switch Capable (FSC) interfaces: 5. Fiber-Switch Capable (FSC) interfaces:
Interfaces that forward data based on a position of the data in the Interfaces that switch data based on a position of the data in the
(real world) physical spaces. An example of such an interface is (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 that of a PXC or OXC that can operate at the level of a single or
multiple fibers. multiple fibers.
A circuit can be established only between, or through, interfaces of A circuit can be established only between, or through, interfaces of
the same type. Depending on the particular technology being used for the same type. Depending on the particular technology being used for
each interface, different circuit names can be used, e.g. SDH each interface, different circuit names can be used, e.g. SDH
circuit, optical trail, light-path, etc. In the context of GMPLS, circuit, optical trail, light-path, etc. In the context of GMPLS,
all these circuits are referenced by a common name: Label Switched all these circuits are referenced by a common name: Label Switched
Path (LSP). Path (LSP).
The concept of nested LSP (LSP within LSP), already available in the The concept of nested LSP (LSP within LSP), already available in the
traditional MPLS, facilitates building a forwarding hierarchy, i.e. traditional MPLS, facilitates building a forwarding hierarchy, i.e.
a hierarchy of LSPs. This hierarchy of LSPs can occur on the same a hierarchy of LSPs. This hierarchy of LSPs can occur on the same
interface, or between different interfaces. interface, or between different interfaces.
For example, a hierarchy can be built if an interface is capable of For example, a hierarchy can be built if an interface is capable of
multiplexing several LSPs from the same technology (layer), e.g. a 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 lower order SONET/SDH LSP (e.g. VT2/VC-12) nested in a higher order
LSP (VC-4). Several levels of signal (LSP) nesting are defined in SONET/SDH LSP (e.g. STS-3c/VC-4). Several levels of signal (LSP)
the SDH/SONET multiplexing hierarchy. nesting are defined in the SONET/SDH multiplexing hierarchy.
The nesting can also occur between interfaces. At the top of the The nesting can also occur between interface types. At the top of
hierarchy are FSC interfaces, followed by LSC interfaces, followed the hierarchy are FSC interfaces, followed by LSC interfaces,
by TDM interfaces, followed by L2SC, and followed by PSC interfaces. followed by TDM interfaces, followed by L2SC, and followed by PSC
This way, an LSP that starts and ends on a PSC interface can be interfaces. This way, an LSP that starts and ends on a PSC interface
nested (together with other LSPs) into an LSP that starts and ends can be nested (together with other LSPs) into an LSP that starts and
on a L2SC interface. This LSP, in turn, can be nested (together with ends on a L2SC interface. This LSP, in turn, can be nested (together
other LSPs) into an LSP that starts and ends on a TDM interface. In with other LSPs) into an LSP that starts and ends on a TDM
turn, this LSP can be nested (together with other LSPs) into an LSP interface. In turn, this LSP can be nested (together with other
that starts and ends on a LSC interface, which in turn can be nested LSPs) into an LSP that starts and ends on a LSC interface, which in
(together with other LSPs) into an LSP that starts and ends on a FSC turn can be nested (together with other LSPs) into an LSP that
interface. starts and ends on a FSC interface.
3.3. Extension of the MPLS Control Plane 3.3. Extension of the MPLS Control Plane
The establishment of LSPs that span only Packet Switch Capable (PSC) The establishment of LSPs that span only Packet Switch Capable (PSC)
or Layer-2 Switch Capable (L2SC) interfaces is defined for the or Layer-2 Switch Capable (L2SC) interfaces is defined for the
original MPLS and/or MPLS-TE control planes. GMPLS extends these original MPLS and/or MPLS-TE control planes. GMPLS extends these
control planes to support each of the five classes of interfaces control planes to support each of the five classes of interfaces
(i.e. layers) defined in the previous section. (i.e. layers) defined in the previous section.
Note that the GMPLS control plane supports an overlay model, an Note that the GMPLS control plane supports an overlay model, an
augmented model, and a peer (integrated) model. In the near term, augmented model, and a peer (integrated) model. In the near term,
GMPLS is very suitable for controlling each layer independently. GMPLS appears to be very suitable for controlling each layer
This elegant approach will facilitate the future deployment of other independently. This elegant approach will facilitate the future
models. deployment of other models.
E. Mannie (Editor) et al. Standard Track 6
The GMPLS control plane is made of several building blocks are The GMPLS control plane is made of several building blocks are
described in more detail in the following sections. These building described in more detail in the following sections. These building
E. Mannie (Editor) et. al. - Expires August 2003 6
blocks are based on well-known signaling and routing protocols that blocks are based on well-known signaling and routing protocols that
have been extended and/or modified to support GMPLS. They use IPv4 have been extended and/or modified to support GMPLS. They use IPv4
and/or IPv6 addresses. Only one new specialized protocol is required and/or IPv6 addresses. Only one new specialized protocol is required
to support the operations of GMPLS, a signaling protocol for link to support the operations of GMPLS, a signaling protocol for link
management [LMP]. management [LMP].
GMPLS is indeed based on the Traffic Engineering (TE) extensions to GMPLS is indeed based on the Traffic Engineering (TE) extensions to
MPLS, a.k.a. MPLS-TE. This, because most of the technologies that MPLS, a.k.a. MPLS-TE. This, because most of the technologies that
can be used below the PSC level requires some traffic engineering. can be used below the PSC level requires some traffic engineering.
The placement of LSPs at these levels needs in general to consider The placement of LSPs at these levels needs in general to consider
skipping to change at line 382 skipping to change at line 385
Thus, GMPLS extends the two signaling protocols defined for MPLS-TE Thus, GMPLS extends the two signaling protocols defined for MPLS-TE
signaling, i.e. RSVP-TE and CR-LDP. However, GMPLS does not specify 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 which one of these two signaling protocols must be used. It is the
role of manufacturers and operators to evaluate the two possible role of manufacturers and operators to evaluate the two possible
solutions for their own interest. solutions for their own interest.
Since GMPLS is based on RSVP-TE and CR-LDP, it mandates a Since GMPLS is based on RSVP-TE and CR-LDP, it mandates a
downstream-on-demand label allocation and distribution, with ingress downstream-on-demand label allocation and distribution, with ingress
initiated ordered control. Liberal label retention is normally used, initiated ordered control. Liberal label retention is normally used,
but conservative label retention mode could also be used. but conservative label retention mode could also be used.
E. Mannie (Editor) et al. Standard Track 7
Furthermore, there is no restriction on the label allocation Furthermore, there is no restriction on the label allocation
strategy, it can be request/signaling driven (obvious for circuit strategy, it can be request/signaling driven (obvious for circuit
E. Mannie (Editor) et. al. - Expires August 2003 7
switching technologies), traffic/data driven, or even topology switching technologies), traffic/data driven, or even topology
driven. There is also no restriction on the route selection; driven. There is also no restriction on the route selection;
explicit routing is normally used (strict or loose) but hop-by-hop explicit routing is normally used (strict or loose) but hop-by-hop
routing could be used as well. routing could be used as well.
GMPLS also extends two traditional intra-domain link-state routing GMPLS also extends two traditional intra-domain link-state routing
protocols already extended for TE purposes, i.e. OSPF-TE and IS-IS- protocols already extended for TE purposes, i.e. OSPF-TE and IS-IS-
TE. However, if explicit (source) routing is used, the routing TE. However, if explicit (source) routing is used, the routing
algorithms used by these protocols no longer need to be algorithms used by these protocols no longer need to be
standardized. Extensions for inter-domain routing (e.g. BGP) are for standardized. Extensions for inter-domain routing (e.g. BGP) are for
skipping to change at line 438 skipping to change at line 441
LMP is defined in the context of GMPLS, but is specified LMP is defined in the context of GMPLS, but is specified
independently of the GMPLS signaling specification since it is a independently of the GMPLS signaling specification since it is a
local protocol running between data-plane adjacent nodes. local protocol running between data-plane adjacent nodes.
Consequently, LMP can be used in other contexts with non-GMPLS Consequently, LMP can be used in other contexts with non-GMPLS
signaling protocols. signaling protocols.
MPLS signaling and routing protocols require at least one bi- MPLS signaling and routing protocols require at least one bi-
directional control channel to communicate even if two adjacent directional control channel to communicate even if two adjacent
nodes are connected by unidirectional links. Several control nodes are connected by unidirectional links. Several control
E. Mannie (Editor) et al. Standard Track 8
channels can be used. LMP can be used to establish, maintain and channels can be used. LMP can be used to establish, maintain and
manage these control channels. manage these control channels.
E. Mannie (Editor) et. al. - Expires August 2003 8
GMPLS does not specify how these control channels must be GMPLS does not specify how these control channels must be
implemented, but GMPLS requires IP to transport the signaling and implemented, but GMPLS requires IP to transport the signaling and
routing protocols over them. Control channels can be either in-band 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 or out-of-band, and several solutions can be used to carry IP. Note
also that one type of LMP message (the Test message) is used in-band also that one type of LMP message (the Test message) is used in-band
in the data plane and may not be transported over IP, but this is a 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. particular case, needed to verify connectivity in the data plane.
3.4. GMPLS Key Extensions to MPLS-TE 3.4. GMPLS Key Extensions to MPLS-TE
skipping to change at line 465 skipping to change at line 469
- In MPLS-TE, links traversed by an LSP can include an intermix of - In MPLS-TE, links traversed by an LSP can include an intermix of
links with heterogeneous label encoding (e.g. links between routers, links with heterogeneous label encoding (e.g. links between routers,
links between routers and ATM-LSRs, and links between ATM-LSRs. links between routers and ATM-LSRs, and links between ATM-LSRs.
GMPLS extends this by including links where the label is encoded as 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) a time slot, or a wavelength, or a position in the (real world)
physical space. physical space.
- In MPLS-TE, an LSP that carries IP has to start and end on a - 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 router. GMPLS extends this by requiring an LSP to start and end on
similar type of LSR. similar type of interfaces.
- The type of a payload that can be carried in GMPLS by an LSP is - The type of a payload that can be carried in GMPLS by an LSP is
extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb
Ethernet, etc. Ethernet, etc.
- The use of Forwarding Adjacencies (FA) provides a mechanism that - The use of Forwarding Adjacencies (FA) provides a mechanism that
can improve bandwidth utilization, when bandwidth allocation can be can improve bandwidth utilization, when bandwidth allocation can be
performed only in discrete units. It offers also a mechanism to performed only in discrete units. It offers also a mechanism to
aggregate forwarding state, thus allowing the number of required aggregate forwarding state, thus allowing the number of required
labels to be reduced. labels to be reduced.
skipping to change at line 494 skipping to change at line 498
the entire LSP path. This feature is useful in photonic networks the entire LSP path. This feature is useful in photonic networks
where wavelength conversion may not be available. where wavelength conversion may not be available.
- While traditional TE-based (and even LDP-based) LSPs are - While traditional TE-based (and even LDP-based) LSPs are
unidirectional, GMPLS supports the establishment of bi-directional unidirectional, GMPLS supports the establishment of bi-directional
LSPs. LSPs.
- GMPLS supports the termination of an LSP on a specific egress - GMPLS supports the termination of an LSP on a specific egress
port, i.e. the port selection at the destination side. port, i.e. the port selection at the destination side.
E. Mannie (Editor) et. al. - Expires August 2003 9 E. Mannie (Editor) et al. Standard Track 9
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid - GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid
failure notification. failure notification.
Note also some other key differences between MPLS-TE and GMPLS: Note also some other key differences between MPLS-TE and GMPLS:
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP - For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP
can be performed only in discrete units. can be performed only in discrete units.
- It is expected to have (much) fewer labels on TDM, LSC or FSC - It is expected to have (much) fewer labels on TDM, LSC or FSC
links than on PSC or L2SC links, because the former are physical links than on PSC or L2SC links, because the former are physical
skipping to change at line 541 skipping to change at line 545
Re-using existing IP routing protocols allows for non-PSC layers to Re-using existing IP routing protocols allows for non-PSC layers to
take advantages of all the valuable developments that took place take advantages of all the valuable developments that took place
since years for IP routing, in particular in the context of intra- since years for IP routing, in particular in the context of intra-
domain routing (link-state routing) and inter-domain routing (policy domain routing (link-state routing) and inter-domain routing (policy
routing). routing).
In an overlay model, each particular non-PSC layer can be seen as a In an overlay model, each particular non-PSC layer can be seen as a
set of Autonomous Systems (ASs) interconnected in an arbitrary way. set of Autonomous Systems (ASs) interconnected in an arbitrary way.
Similarly to the traditional IP routing, each AS is managed by a Similarly to the traditional IP routing, each AS is managed by a
single administrative authority. For instance, an AS can be an single administrative authority. For instance, an AS can be an
SDH/SONET network operated by a given carrier. The set of SONET/SDH network operated by a given carrier. The set of
interconnected ASs being an SDH/SONET Internetwork. interconnected ASs can be viewed as SONET/SDH internetworks.
Exchange of routing information between ASs can be done via an Exchange of routing information between ASs can be done via an
inter-domain routing protocol like BGP-4. There is obviously a huge inter-domain routing protocol like BGP-4. There is obviously a huge
value of re-using well-known policy routing facilities provided by value of re-using well-known policy routing facilities provided by
BGP in a non-PSC context. Extensions for BGP traffic engineering BGP in a non-PSC context. Extensions for BGP traffic engineering
E. Mannie (Editor) et. al. - Expires August 2003 10 E. Mannie (Editor) et al. Standard Track 10
(BGP-TE) in the context of non-PSC layers are left for further (BGP-TE) in the context of non-PSC layers are left for further
study. study.
Each AS can be sub-divided in different routing domains, and each Each AS can be sub-divided in different routing domains, and each
can run a different intra-domain routing protocol. In turn, each can run a different intra-domain routing protocol. In turn, each
routing-domain can be divided in areas. routing-domain can be divided in areas.
A routing domain is made of GMPLS enabled nodes (i.e. a network A routing domain is made of GMPLS enabled nodes (i.e. a network
device including a GMPLS entity). These nodes can be either edge device including a GMPLS entity). These nodes can be either edge
nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs. nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs.
An example of non-PSC host is an SDH/SONET Terminal Multiplexer An example of non-PSC host is an SONET/SDH Terminal Multiplexer
(TM). Another example is an SDH/SONET interface card within an IP (TM). Another example is an SONET/SDH interface card within an IP
router or ATM switch. router or ATM switch.
Note that traffic engineering in the intra-domain requires the use Note that traffic engineering in the intra-domain requires the use
of link-state routing protocols like OSPF or IS-IS. of link-state routing protocols like OSPF or IS-IS.
GMPLS defines extensions to these protocols. These extensions are GMPLS defines extensions to these protocols. These extensions are
needed to disseminate specific TDM, LSC and FSC static and dynamic needed to disseminate specific TDM, LSC and FSC static and dynamic
characteristics related to nodes and links. The current focus is on characteristics related to nodes and links. The current focus is on
intra-area traffic engineering. However, inter-area traffic intra-area traffic engineering. However, inter-area traffic
engineering is also under investigation. engineering is also under investigation.
4.1. Addressing of PSC and non-PSC Layers 4.1. Addressing of PSC and non-PSC Layers
The fact that IPv4 and/or IPv6 addresses are used doesn't imply at 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 all that they should be allocated in the same addressing space than
public IPv4 and/or IPv6 addresses used for the Internet. Private IP public IPv4 and/or IPv6 addresses used for the Internet. Private IP
addresses can be used if they don't require to be exchanged with any addresses can be used if they don't require to be exchanged with any
other operator; public IP addresses are otherwise required. Of other operator; public IP addresses are otherwise required. Of
course, if an integrated model is used, two layers could share the course, if an integrated model is used, two layers could share the
same addressing space. same addressing space. Finally, TE links may be "unnumbered" i.e.
not have any IP addresses, in case IP addresses are not available,
or the overhead of managing them is considered too high.
Note that there is a benefit of using public IPv4 and/or IPv6 Note that there is a benefit of using public IPv4 and/or IPv6
Internet addresses for non-PSC layers if an integrated model with Internet addresses for non-PSC layers if an integrated model with
the IP layer is foreseen. the IP layer is foreseen.
If we consider the scalability enhancements proposed in the next If we consider the scalability enhancements proposed in the next
section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing
spaces are both more than sufficient to accommodate any non-PSC spaces are both more than sufficient to accommodate any non-PSC
layer. We can reasonably expect to have much less non-PSC devices 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. (e.g. SONET/SDH nodes) than we have today IP hosts and routers.
4.2. GMPLS Scalability Enhancements 4.2. GMPLS Scalability Enhancements
TDM, LSC and FSC layers introduce new constraints on the IP TDM, LSC and FSC layers introduce new constraints on the IP
addressing and routing models since several hundreds of parallel addressing and routing models since several hundreds of parallel
physical links (e.g. wavelengths) can now connect two nodes. Most of physical links (e.g. wavelengths) can now connect two nodes. Most of
the carriers already have today several tens of wavelengths per the carriers already have today several tens of wavelengths per
fiber between two nodes. New generation of DWDM systems will allow fiber between two nodes. New generation of DWDM systems will allow
several hundreds of wavelengths per fiber. several hundreds of wavelengths per fiber.
E. Mannie (Editor) et al. Standard Track 11
It becomes rather impractical to associate an IP address with each It becomes rather impractical to associate an IP address with each
end of each physical link, to represent each link as a separate end of each physical link, to represent each link as a separate
E. Mannie (Editor) et. al. - Expires August 2003 11
routing adjacency, and to advertise and to maintain link states for routing adjacency, and to advertise and to maintain link states for
each of these links. For that purpose, GMPLS enhances the MPLS each of these links. For that purpose, GMPLS enhances the MPLS
routing and addressing models to increase their scalability. routing and addressing models to increase their scalability.
Two optional mechanisms can be used to increase the scalability of Two optional mechanisms can be used to increase the scalability of
the addressing and the routing: unnumbered links and link bundling. the addressing and the routing: unnumbered links and link bundling.
These two mechanisms can also be combined. They require extensions 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) to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE)
protocols. protocols.
skipping to change at line 657 skipping to change at line 662
rules for different non-PSC layers. Generic bandwidth attributes are rules for different non-PSC layers. Generic bandwidth attributes are
however defined by the TE routing extensions and by GMPLS, such as however defined by the TE routing extensions and by GMPLS, such as
the unreserved bandwidth, the maximum reservable bandwidth and the the unreserved bandwidth, the maximum reservable bandwidth and the
maximum LSP bandwidth. maximum LSP bandwidth.
It is expected in a dynamic environment to have frequent changes of It is expected in a dynamic environment to have frequent changes of
bandwidth accounting information. A flexible policy for triggering bandwidth accounting information. A flexible policy for triggering
link state updates based on bandwidth thresholds and link-dampening link state updates based on bandwidth thresholds and link-dampening
mechanism can be implemented. mechanism can be implemented.
E. Mannie (Editor) et al. Standard Track 12
TE properties associated with a link should also capture protection TE properties associated with a link should also capture protection
and restoration related characteristics. For instance, shared and restoration related characteristics. For instance, shared
protection can be elegantly combined with bundling. Protection and protection can be elegantly combined with bundling. Protection and
E. Mannie (Editor) et. al. - Expires August 2003 12
restoration are mainly generic mechanisms also applicable to MPLS. restoration are mainly generic mechanisms also applicable to MPLS.
It is expected that they will first be developed for MPLS and later It is expected that they will first be developed for MPLS and later
on generalized to GMPLS. on generalized to GMPLS.
A TE link between a pair of LSRs doesn't imply the existence of an 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 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 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 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 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 that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE
skipping to change at line 684 skipping to change at line 688
5. Unnumbered Links 5. Unnumbered Links
Unnumbered links (or interfaces) are links (or interfaces) that do Unnumbered links (or interfaces) are links (or interfaces) that do
not have IP addresses. Using such links involves two capabilities: not have IP addresses. Using such links involves two capabilities:
the ability to specify unnumbered links in MPLS TE signaling, and the ability to specify unnumbered links in MPLS TE signaling, and
the ability to carry (TE) information about unnumbered links in IGP the ability to carry (TE) information about unnumbered links in IGP
TE extensions of ISIS-TE and OSPF-TE. TE extensions of ISIS-TE and OSPF-TE.
A. The ability to specify unnumbered links in MPLS TE signaling A. The ability to specify unnumbered links in MPLS TE signaling
requires extensions to RSVP-TE and CR-LDP. The MPLS-TE signaling requires extensions to RSVP-TE [RSVP-TE-UNNUM] and CR-LDP [CR-LDP-
doesn't provide support for unnumbered links, because it doesnÆt UNNUM]. The MPLS-TE signaling doesn't provide support for
provide a way to indicate an unnumbered link in its Explicit Route unnumbered links, because it doesn't provide a way to indicate an
Object/TLV and in its Record Route Object (there is no such TLV unnumbered link in its Explicit Route Object/TLV and in its Record
for CR-LDP). GMPLS defines simple extensions to indicate an Route Object (there is no such TLV for CR-LDP). GMPLS defines
unnumbered link in these two Objects/TLVs, using a new Unnumbered simple extensions to indicate an unnumbered link in these two
Interface ID sub-object/sub-TLV. Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub-
TLV.
Since unnumbered links are not identified by an IP address, then Since unnumbered links are not identified by an IP address, then
for the purpose of MPLS TE each end need some other identifier, for the purpose of MPLS TE each end need some other identifier,
local to the LSR to which the link belongs. LSRs at the two end- local to the LSR to which the link belongs. LSRs at the two end-
points of an unnumbered link exchange with each other the points of an unnumbered link exchange with each other the
identifiers they assign to the link. Exchanging the identifiers identifiers they assign to the link. Exchanging the identifiers
may be accomplished by configuration, by means of a protocol such may be accomplished by configuration, by means of a protocol such
as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case as LMP ([LMP]), by means of RSVP/CR-LDP (especially in the case
where a link is a Forwarding Adjacency, see below), or by means of where a link is a Forwarding Adjacency, see below), or by means of
IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]).
Consider an (unnumbered) link between LSRs A and B. LSR A chooses Consider an (unnumbered) link between LSRs A and B. LSR A chooses
an identifier for that link. So is LSR B. From A's perspective we an identifier for that link. So does LSR B. From A's perspective
refer to the identifier that A assigned to the link as the "link we refer to the identifier that A assigned to the link as the
local identifier" (or just "local identifier"), and to the "link local identifier" (or just "local identifier"), and to the
identifier that B assigned to the link as the "link remote identifier that B assigned to the link as the "link remote
identifier" (or just "remote identifier"). Likewise, from B's identifier" (or just "remote identifier"). Likewise, from B's
perspective the identifier that B assigned to the link is the perspective the identifier that B assigned to the link is the
local identifier, and the identifier that A assigned to the link local identifier, and the identifier that A assigned to the link
is the remote identifier. is the remote identifier.
E. Mannie (Editor) et al. Standard Track 13
The new Unnumbered Interface ID sub-object/sub-TLV for the ER 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 Object/TLV contains the Router ID of the LSR at the upstream end
of the unnumbered link and the outgoing interface identifier or of the unnumbered link and the link local identifier with respect
the link local identifier with respect to that upstream LSR. to that upstream LSR.
E. Mannie (Editor) et. al. - Expires August 2003 13
The new Unnumbered Interface ID sub-object for the RR Object The new Unnumbered Interface ID sub-object for the RR Object
contains the outgoing interface identifier with respect to the LSR contains the link local identifier with respect to the LSR that
that adds it in the RR Object. adds it in the RR Object.
B. The ability to carry (TE) information about unnumbered links in B. The ability to carry (TE) information about unnumbered links in
IGP TE extensions requires new sub-TLVs for the extended IS IGP TE extensions requires new sub-TLVs for the extended IS
reachability TLV defined in ISIS-TE and for the TE LSA (which is reachability TLV defined in ISIS-TE and for the TE LSA (which is
an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV
and a Link Remote Identifier sub-TLV are defined. and a Link Remote Identifier sub-TLV are defined.
5.1. Unnumbered Forwarding Adjacencies 5.1. Unnumbered Forwarding Adjacencies
If an LSR that originates an LSP advertises this LSP as an If an LSR that originates an LSP advertises this LSP as an
skipping to change at line 752 skipping to change at line 757
6. Link Bundling 6. Link Bundling
The concept of link bundling is essential in certain networks The concept of link bundling is essential in certain networks
employing the GMPLS control plane as is defined in [BUNDLE]. A employing the GMPLS control plane as is defined in [BUNDLE]. A
typical example is an optical meshed network where adjacent optical typical example is an optical meshed network where adjacent optical
cross-connects (LSRs) are connected by several hundreds of parallel cross-connects (LSRs) are connected by several hundreds of parallel
wavelengths. In this network, consider the application of link state wavelengths. In this network, consider the application of link state
routing protocols, like OSPF or IS-IS, with suitable extensions for routing protocols, like OSPF or IS-IS, with suitable extensions for
resource discovery and dynamic route computation. Each wavelength resource discovery and dynamic route computation. Each wavelength
must be advertised separately in order to be used, except if link must be advertised separately to be used, except if link bundling is
bundling is used. used.
When a pair of LSRs is connected by multiple links, it is possible 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 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 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 bundling. The resulting logical link is called a bundled link as its
physical links are called component links (and are identified by physical links are called component links (and are identified by
interface indexes). interface indexes).
It results that a combination of three identifiers ((bundled) link The result is that a combination of three identifiers ((bundled)
identifier, component link identifier, label) is sufficient to link identifier, component link identifier, label) is sufficient to
unambiguously identify the appropriate resources used by an LSP. unambiguously identify the appropriate resources used by an LSP.
E. Mannie (Editor) et al. Standard Track 14
The purpose of link bundling is to improve routing scalability by The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the aggregation/abstraction, this results in losing some of the
E. Mannie (Editor) et. al. - Expires August 2003 14
information. To limit the amount of losses one need to restrict the information. To limit the amount of losses one need to restrict the
type of the information that can be aggregated/abstracted. type of the information that can be aggregated/abstracted.
6.1. Restrictions on Bundling 6.1. Restrictions on Bundling
The following restrictions are required for bundling links. All The following restrictions are required for bundling links. All
component links in a bundle must begin and end on the same pair of component links in a bundle must begin and end on the same pair of
LSRs; and share some common characteristics or properties defined in LSRs; and share some common characteristics or properties defined in
[OSPF-TE] and [ISIS-TE], i.e. they must have the same: [OSPF-TE] and [ISIS-TE], i.e. they must have the same:
skipping to change at line 821 skipping to change at line 825
Note that advertising a (bundled) TE link between a pair of LSRs 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 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 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 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 IGP adjacency at all between the LSR (e.g. when the TE link is an
FA). FA).
Forming a bundled link consist in aggregating the identical TE Forming a bundled link consist in aggregating the identical TE
parameters of each individual component link to produce aggregated parameters of each individual component link to produce aggregated
E. Mannie (Editor) et al. Standard Track 15
TE parameters. A TE link as defined by [GMPLS-ROUTING] has many TE parameters. A TE link as defined by [GMPLS-ROUTING] has many
parameters; adequate aggregation rules must be defined for each one. parameters; adequate aggregation rules must be defined for each one.
Some parameters can be sums of component characteristics such as the Some parameters can be sums of component characteristics such as the
unreserved bandwidth and the maximum reservable bandwidth. Bandwidth unreserved bandwidth and the maximum reservable bandwidth. Bandwidth
E. Mannie (Editor) et. al. - Expires August 2003 15
information is an important part of a bundle advertisement and it information is an important part of a bundle advertisement and it
must be clearly defined since an abstraction is done. must be clearly defined since an abstraction is done.
A GMPLS node with bundled links must apply admission control on a A GMPLS node with bundled links must apply admission control on a
per-component link basis. per-component link basis.
6.3. Signaling Considerations 6.3. Signaling Considerations
Typically, an LSP's explicit route (e.g. contained in an explicit Typically, an LSP's explicit route (e.g. contained in an explicit
route TLV/Object) will choose the bundled link to be used for the route TLV/Object) will choose the bundled link to be used for the
skipping to change at line 876 skipping to change at line 880
(see [RSVP-TE-GMPLS]/[CR-LDP-GMPLS], respectively). For a bi- (see [RSVP-TE-GMPLS]/[CR-LDP-GMPLS], respectively). For a bi-
directional LSP, a component link is provided for each direction by directional LSP, a component link is provided for each direction by
the upstream node. the upstream node.
This mechanism does not require each component link to have its own This mechanism does not require each component link to have its own
control channel. In fact, it doesn't even require the whole control channel. In fact, it doesn't even require the whole
(bundled) link to have its own control channel. (bundled) link to have its own control channel.
6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID
E. Mannie (Editor) et al. Standard Track 16
With this mechanism, each component link that is unnumbered is With this mechanism, each component link that is unnumbered is
assigned a unique Interface Identifier (32 bits value). The upstream assigned a unique Interface Identifier (32 bits value). The upstream
node indicates the choice of the component link by including a new node indicates the choice of the component link by including a new
IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message
[RSVP-TE-GMPLS] [CR-LDP-GMPLS]. [RSVP-TE-GMPLS] [CR-LDP-GMPLS].
E. Mannie (Editor) et. al. - Expires August 2003 16
This object/TLV carries the component interface ID in the downstream This object/TLV carries the component interface ID in the downstream
direction for a unidirectional LSP, and in addition, the component direction for a unidirectional LSP, and in addition, the component
interface ID in the upstream direction for a bi-directional LSP. interface ID in the upstream direction for a bi-directional LSP.
The two LSRs at each end of the bundled link exchange these The two LSRs at each end of the bundled link exchange these
identifiers. Exchanging the identifiers may be accomplished by identifiers. Exchanging the identifiers may be accomplished by
configuration, by means of a protocol such as LMP (preferred configuration, by means of a protocol such as LMP (preferred
solution), by means of RSVP/CR-LDP (especially in the case where a solution), by means of RSVP/CR-LDP (especially in the case where a
component link is a Forwarding Adjacency), or by means of IS-IS or component link is a Forwarding Adjacency), or by means of IS-IS or
OSPF extensions. OSPF extensions.
skipping to change at line 930 skipping to change at line 934
rules sequentially to produce bundles. rules sequentially to produce bundles.
For instance, the first property on which component links may be For instance, the first property on which component links may be
correlated could be the Interface Switching Capability [GMPLS- correlated could be the Interface Switching Capability [GMPLS-
ROUTING], the second property could be the Encoding [GMPLS-ROUTING], ROUTING], the second property could be the Encoding [GMPLS-ROUTING],
the third property could be the Administrative Weight (cost), the the third property could be the Administrative Weight (cost), the
fourth property could be the Resource Classes and finally links may fourth property could be the Resource Classes and finally links may
be correlated based on other metrics such as SRLG (Shared Risk Link be correlated based on other metrics such as SRLG (Shared Risk Link
Groups). Groups).
E. Mannie (Editor) et al. Standard Track 17
When routing an alternate path for protection purposes, the general When routing an alternate path for protection purposes, the general
principle followed is that the alternate path is not routed over any principle followed is that the alternate path is not routed over any
link belonging to an SRLG that belongs to some link of the primary link belonging to an SRLG that belongs to some link of the primary
path. Thus, the rule to be followed is to group links belonging to path. Thus, the rule to be followed is to group links belonging to
exactly the same set of SRLGs. exactly the same set of SRLGs.
E. Mannie (Editor) et. al. - Expires August 2003 17
This type of sequential sub-division may result in a number of This type of sequential sub-division may result in a number of
bundles between two adjacent nodes. In practice, however, the link bundles between two adjacent nodes. In practice, however, the link
properties may not be very heterogeneous among component links properties may not be very heterogeneous among component links
between two adjacent nodes. Thus, the number of bundles in practice between two adjacent nodes. Thus, the number of bundles in practice
may not be large. may not be large.
7. Relationship with the UNI 7. Relationship with the UNI
The interface between an edge GMPLS node and a GMPLS LSR on the 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 network side may be referred to as a User to Network Interface
skipping to change at line 965 skipping to change at line 969
is expected that in most of the cases it will not (see also section 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). 7.2 and the section about signaling with an explicit route).
Conceptually, a difference between UNI and NNI make sense either if Conceptually, a difference between UNI and NNI make sense either if
both interface uses completely different protocols, or if they use both interface uses completely different protocols, or if they use
the same protocols but with some outstanding differences. In the the same protocols but with some outstanding differences. In the
first case, separate protocols are often defined successively, with first case, separate protocols are often defined successively, with
more or less success. more or less success.
The GMPLS approach consisted in building a consistent model from day The GMPLS approach consisted in building a consistent model from day
one, considering both the UNI and NNI interfaces at the same time. one, considering both the UNI and NNI interfaces at the same time
For that purpose, a very few specific UNI particularities have been [GMPLS-OVERLAY]. For that purpose, a very few specific UNI
ignored in a first time. GMPLS has been enhanced to support such particularities have been ignored in a first time. GMPLS has been
particularities at the UNI by some other standardization bodies (see enhanced to support such particularities at the UNI by some other
hereafter). standardization bodies (see hereafter).
7.1. Relationship with the OIF UNI 7.1. Relationship with the OIF UNI
This section is only given for reference to the OIF work related to This section is only given for reference to the OIF work related to
GMPLS. The current OIF UNI specification [OIF-UNI] defines an GMPLS. The current OIF UNI specification [OIF-UNI] defines an
interface between a client SDH/SONET equipment and an SDH/SONET interface between a client SONET/SDH equipment and an SONET/SDH
network, each belonging to a distinct administrative authority. It network, each belonging to a distinct administrative authority. It
is designed for an overlay model. The OIF UNI defines additional is designed for an overlay model. The OIF UNI defines additional
mechanisms on the top of GMPLS for the UNI. mechanisms on the top of GMPLS for the UNI.
For instance, the OIF service discovery procedure is a precursor to For instance, the OIF service discovery procedure is a precursor to
obtaining UNI services. Service discovery allows a client to obtaining UNI services. Service discovery allows a client to
determine the static parameters of the interconnection with the determine the static parameters of the interconnection with the
network, including the UNI signaling protocol, the type of network, including the UNI signaling protocol, the type of
E. Mannie (Editor) et al. Standard Track 18
concatenation, the transparency level as well as the type of concatenation, the transparency level as well as the type of
diversity (node, link, SRLG) supported by the network. diversity (node, link, SRLG) supported by the network.
Since the current OIF UNI interface does not cover photonic Since the current OIF UNI interface does not cover photonic
networks, G.709 Digital Wrapper, etc, it is from that perspective a networks, G.709 Digital Wrapper, etc, it is from that perspective a
subset of the GMPLS Architecture at the UNI. subset of the GMPLS Architecture at the UNI.
E. Mannie (Editor) et. al. - Expires August 2003 18
7.2. Reachability across the UNI 7.2. Reachability across the UNI
This section discusses the selection of an explicit route by an edge 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 node. The selection of the first LSR by an edge node connected to
multiple LSRs is part of that problem. multiple LSRs is part of that problem.
An edge node (host or LSR) can participate more or less deeply in 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 GMPLS routing. Four different routing models can be supported at
the UNI: configuration based, partial peering, silent listening and the UNI: configuration based, partial peering, silent listening and
full peering. full peering.
skipping to change at line 1040 skipping to change at line 1044
- Full peering: in addition to silent listening, the edge node - Full peering: in addition to silent listening, the edge node
participates within the routing, establish adjacencies with its participates within the routing, establish adjacencies with its
neighbors and advertises LSAs. This is useful only if there are neighbors and advertises LSAs. This is useful only if there are
benefits for edge nodes to advertise themselves traffic engineering benefits for edge nodes to advertise themselves traffic engineering
information. GMPLS does not preclude this model. information. GMPLS does not preclude this model.
8. Link Management 8. Link Management
In the context of GMPLS, a pair of nodes (e.g., a photonic switch) 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 may be connected by tens of fibers, and each fiber may be used to
E. Mannie (Editor) et al. Standard Track 19
transmit hundreds of wavelengths if DWDM is used. Multiple fibers transmit hundreds of wavelengths if DWDM is used. Multiple fibers
and/or multiple wavelengths may also be combined into one or more and/or multiple wavelengths may also be combined into one or more
bundled links for routing purposes. Furthermore, to enable bundled links for routing purposes. Furthermore, to enable
communication between nodes for routing, signaling, and link communication between nodes for routing, signaling, and link
management, control channels must be established between a node management, control channels must be established between a node
pair. pair.
E. Mannie (Editor) et. al. - Expires August 2003 19
Link management is a collection of useful procedures between Link management is a collection of useful procedures between
adjacent nodes that provide local services such as control channel adjacent nodes that provide local services such as control channel
management, link connectivity verification, link property management, link connectivity verification, link property
correlation, and fault management. The Link Management Protocol correlation, and fault management. The Link Management Protocol
(LMP) has been defined to fulfill these operations. LMP has been (LMP) has been defined to fulfill these operations. LMP has been
initiated in the context of GMPLS but is a generic toolbox that can initiated in the context of GMPLS but is a generic toolbox that can
be also used in other contexts. be also used in other contexts.
Control channel management and link property correlation procedures Control channel management and link property correlation procedures
are mandatory per LMP. Link connectivity verification and fault are mandatory per LMP. Link connectivity verification and fault
skipping to change at line 1095 skipping to change at line 1100
to be physically diverse from the associated data-bearing links is to be physically diverse from the associated data-bearing links is
that the health of a control channel does not necessarily correlate that the health of a control channel does not necessarily correlate
to the health of the data-bearing links, and vice-versa. Therefore, to the health of the data-bearing links, and vice-versa. Therefore,
new mechanisms have been developed in LMP to manage links, both in new mechanisms have been developed in LMP to manage links, both in
terms of link provisioning and fault isolation. terms of link provisioning and fault isolation.
LMP does not specify the signaling transport mechanism used in the LMP does not specify the signaling transport mechanism used in the
control channel, however it states that messages transported over a control channel, however it states that messages transported over a
control channel must be IP encoded. Furthermore, since the messages 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 are IP encoded, the link level encoding is not part of LMP. A 32-bit
E. Mannie (Editor) et al. Standard Track 20
non-zero integer Control Channel Identifier (CCId) is assigned to non-zero integer Control Channel Identifier (CCId) is assigned to
each direction of a control channel. each direction of a control channel.
Each control channel individually negotiates its control channel Each control channel individually negotiates its control channel
parameters and maintains connectivity using a fast Hello protocol. parameters and maintains connectivity using a fast Hello protocol.
The latter is required if lower-level mechanisms are not available The latter is required if lower-level mechanisms are not available
to detect link failures. to detect link failures.
E. Mannie (Editor) et. al. - Expires August 2003 20
The Hello protocol of LMP is intended to be a lightweight keep-alive The Hello protocol of LMP is intended to be a lightweight keep-alive
mechanism that will react to control channel failures rapidly so mechanism that will react to control channel failures rapidly so
that IGP Hellos are not lost and the associated link-state that IGP Hellos are not lost and the associated link-state
adjacencies are not removed uselessly. adjacencies are not removed uselessly.
The Hello protocol consists of two phases: a negotiation phase and a The Hello protocol consists of two phases: a negotiation phase and a
keep-alive phase. The negotiation phase allows negotiation of some keep-alive phase. The negotiation phase allows negotiation of some
basic Hello protocol parameters, like the Hello frequency. The keep- basic Hello protocol parameters, like the Hello frequency. The keep-
alive phase consists of a fast lightweight bi-directional Hello alive phase consists of a fast lightweight bi-directional Hello
message exchange. message exchange.
skipping to change at line 1149 skipping to change at line 1155
8.3. Link Connectivity Verification 8.3. Link Connectivity Verification
Link connectivity verification is an optional procedure that may be Link connectivity verification is an optional procedure that may be
used to verify the physical connectivity of data-bearing links as used to verify the physical connectivity of data-bearing links as
well as to exchange the link identifiers that are used in the GMPLS well as to exchange the link identifiers that are used in the GMPLS
signaling. signaling.
The use of this procedure is negotiated as part of the configuration The use of this procedure is negotiated as part of the configuration
exchange that take place during the negotiation phase of the Hello exchange that take place during the negotiation phase of the Hello
protocol. This procedure should be done initially when a data- protocol. This procedure should be done initially when a data-
E. Mannie (Editor) et al. Standard Track 21
bearing link is first established, and subsequently, on a periodic bearing link is first established, and subsequently, on a periodic
basis for all unallocated (free) data-bearing links. basis for all unallocated (free) data-bearing links.
The verification procedure consists of sending Test messages in-band The verification procedure consists of sending Test messages in-band
over the data-bearing links. This requires that the unallocated over the data-bearing links. This requires that the unallocated
links must be opaque; however, multiple degrees of opaqueness (e.g., links must be opaque; however, multiple degrees of opaqueness (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence examining overhead bytes, terminating the payload, etc.), and hence
different mechanisms to transport the Test messages, are specified. different mechanisms to transport the Test messages, are specified.
E. Mannie (Editor) et. al. - Expires August 2003 21
Note that the Test message is the only LMP message that is Note that the Test message is the only LMP message that is
transmitted over the link, and that Hello messages continue to be transmitted over the link, and that Hello messages continue to be
exchanged over the control channel during the link verification exchanged over the control channel during the link verification
process. Data-bearing links are tested in the transmit direction as process. Data-bearing links are tested in the transmit direction as
they are unidirectional. As such, it is possible for LMP neighboring they are unidirectional. As such, it is possible for LMP neighboring
nodes to exchange the Test messages simultaneously in both nodes to exchange the Test messages simultaneously in both
directions. directions.
To initiate the link verification procedure, a node must first To initiate the link verification procedure, a node must first
notify the adjacent node that it will begin sending Test messages notify the adjacent node that it will begin sending Test messages
skipping to change at line 1205 skipping to change at line 1211
the control plane). the control plane).
LMP provides a fault localization procedure that can be used to LMP provides a fault localization procedure that can be used to
rapidly localize link failures, by notifying a fault up to the node rapidly localize link failures, by notifying a fault up to the node
upstream of that fault (i.e. through a fault notification upstream of that fault (i.e. through a fault notification
procedure). procedure).
A downstream LMP neighbor that detects data link failures will send A downstream LMP neighbor that detects data link failures will send
an LMP message to its upstream neighbor notifying it of the failure. an LMP message to its upstream neighbor notifying it of the failure.
When an upstream node receives a failure notification, it can When an upstream node receives a failure notification, it can
E. Mannie (Editor) et al. Standard Track 22
correlate the failure with the corresponding input ports to correlate the failure with the corresponding input ports to
determine if the failure is between the two nodes. Once the failure determine if the failure is between the two nodes. Once the failure
has been localized, the signaling protocols can be used to initiate has been localized, the signaling protocols can be used to initiate
link or path protection/restoration procedures. link or path protection/restoration procedures.
8.5 LMP for DWDM Optical Line Systems (OLSs) 8.5 LMP for DWDM Optical Line Systems (OLSs)
E. Mannie (Editor) et. al. - Expires August 2003 22
In an all-optical environment, LMP focuses on peer communications In an all-optical environment, LMP focuses on peer communications
(e.g. OXC-to-OXC). A great deal of information about a link between (e.g. OXC-to-OXC). A great deal of information about a link between
two OXCs is known by the OLS (Optical Line System or WDM Terminal two OXCs is known by the OLS (Optical Line System or WDM Terminal
multiplexer). Exposing this information to the control plane can multiplexer). Exposing this information to the control plane can
improve network usability by further reducing required manual improve network usability by further reducing required manual
configuration, and by greatly enhancing fault detection and configuration, and by greatly enhancing fault detection and
recovery. recovery.
LMP-WDM [LMP-WDM] defines extensions to LMP for use between and OXC LMP-WDM [LMP-WDM] defines extensions to LMP for use between and OXC
and an OLS. These extensions are intended to satisfy the Optical and an OLS. These extensions are intended to satisfy the Optical
skipping to change at line 1241 skipping to change at line 1248
channel between PXCs. LMP-WDM can then be used by the OLS to provide channel between PXCs. LMP-WDM can then be used by the OLS to provide
this information to the PXC. this information to the PXC.
In addition to the link information known to the OLS that is In addition to the link information known to the OLS that is
exchanged through LMP-WDM, some information known to the OXC may exchanged through LMP-WDM, some information known to the OXC may
also be exchanged with the OLS through LMP-WDM. This information is also be exchanged with the OLS through LMP-WDM. This information is
useful for alarm management and link monitoring (e.g. trace useful for alarm management and link monitoring (e.g. trace
monitoring). Alarm management is important because the monitoring). Alarm management is important because the
administrative state of a connection, known to the OXC (e.g. this administrative state of a connection, known to the OXC (e.g. this
information may be learned through the Admin Status object of GMPLS information may be learned through the Admin Status object of GMPLS
signaling [GMPLS]), can be used to suppress spurious alarms. For signaling [GMPLS-SIG]), can be used to suppress spurious alarms. For
example, the OXC may know that a connection is "up", "down", in a example, the OXC may know that a connection is "up", "down", in a
"testing" mode, or being deleted ("deletion-in-progress"). The OXC "testing" mode, or being deleted ("deletion-in-progress"). The OXC
can use this information to inhibit alarm reporting from the OLS can use this information to inhibit alarm reporting from the OLS
when a connection is "down", "testing", or being deleted. when a connection is "down", "testing", or being deleted.
It is important to note that an OXC may peer with one or more OLSs It is important to note that an OXC may peer with one or more OLSs
and an OLS may peer with one or more OXCs. Although there are many and an OLS may peer with one or more OXCs. Although there are many
similarities between an OXC-OXC LMP session and an OXC-OLS LMP similarities between an OXC-OXC LMP session and an OXC-OLS LMP
session, particularly for control management and link verification, session, particularly for control management and link verification,
there are some differences as well. These differences can primarily there are some differences as well. These differences can primarily
be attributed to the nature of an OXC-OLS link, and the purpose of be attributed to the nature of an OXC-OLS link, and the purpose of
OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the
basis for GMPLS signaling and routing at the optical layer. The basis for GMPLS signaling and routing at the optical layer. The
information exchanged over LMP-WDM sessions is used to augment information exchanged over LMP-WDM sessions is used to augment
knowledge about the links between OXCs. knowledge about the links between OXCs.
In order for the information exchanged over the OXC-OLS LMP sessions In order for the information exchanged over the OXC-OLS LMP sessions
to be used by the OXC-OXC session, the information must be to be used by the OXC-OXC session, the information must be
E. Mannie (Editor) et al. Standard Track 23
coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP
sessions are run independently and must be maintained separately. sessions are run independently and must be maintained separately.
One critical requirement when running an OXC-OLS LMP session is the One critical requirement when running an OXC-OLS LMP session is the
ability of the OLS to make a data link transparent when not doing ability of the OLS to make a data link transparent when not doing
the verification procedure. This is because the same data link may the verification procedure. This is because the same data link may
be verified between OXC-OLS and between OXC-OXC. The verification be verified between OXC-OLS and between OXC-OXC. The verification
procedure of LMP is used to coordinate the Test procedure (and hence procedure of LMP is used to coordinate the Test procedure (and hence
E. Mannie (Editor) et. al. - Expires August 2003 23
the transparency/opaqueness of the data links). To maintain the transparency/opaqueness of the data links). To maintain
independence between the sessions, it must be possible for the LMP independence between the sessions, it must be possible for the LMP
sessions to come up in any order. In particular, it must be possible sessions to come up in any order. In particular, it must be possible
for an OXC-OXC LMP session to come up without an OXC-OLS LMP session for an OXC-OXC LMP session to come up without an OXC-OLS LMP session
being brought up, and vice-versa. being brought up, and vice-versa.
9. Generalized Signaling 9. Generalized Signaling
The GMPLS signaling extends certain base functions of the RSVP-TE The GMPLS signaling extends certain base functions of the RSVP-TE
and CR-LDP signaling and, in some cases, adds functionality. These and CR-LDP signaling and, in some cases, adds functionality. These
skipping to change at line 1292 skipping to change at line 1299
the ingress and egress. the ingress and egress.
The core GMPLS signaling specification is available in three parts: The core GMPLS signaling specification is available in three parts:
1. A signaling functional description [GMPLS-SIG]. 1. A signaling functional description [GMPLS-SIG].
2. RSVP-TE extensions [RSVP-TE-GMPLS]. 2. RSVP-TE extensions [RSVP-TE-GMPLS].
3. CR-LDP extensions [CR-LDP-GMPLS]. 3. CR-LDP extensions [CR-LDP-GMPLS].
In addition, independent parts are available per technology: In addition, independent parts are available per technology:
1. GMPLS extensions for SONET and SDH control [SONETSDH-GMPLS]. 1. GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH].
2. GMPLS extensions for G.709 control [G709-GMPLS]. 2. GMPLS extensions for G.709 control [GMPLS-G709].
The following MPLS profile expressed in terms of MPLS features The following MPLS profile expressed in terms of MPLS features
[RFC3031] applies to GMPLS: [RFC3031] applies to GMPLS:
- Downstream-on-demand label allocation and distribution. - Downstream-on-demand label allocation and distribution.
- Ingress initiated ordered control. - Ingress initiated ordered control.
- Liberal (typical), or conservative (could) label retention - Liberal (typical), or conservative (could) label retention
mode. mode.
- Request, traffic/data, or topology driven label allocation - Request, traffic/data, or topology driven label allocation
strategy. strategy.
skipping to change at line 1316 skipping to change at line 1323
The GMPLS signaling defines the following new building blocks on the The GMPLS signaling defines the following new building blocks on the
top of MPLS-TE: top of MPLS-TE:
1. A new generic label request format. 1. A new generic label request format.
2. Labels for TDM, LSC and FSC interfaces, generically known as 2. Labels for TDM, LSC and FSC interfaces, generically known as
Generalized Label. Generalized Label.
3. Waveband switching support. 3. Waveband switching support.
4. Label suggestion by the upstream for optimization purposes 4. Label suggestion by the upstream for optimization purposes
(e.g. latency). (e.g. latency).
5. Label restriction by the upstream to support some optical 5. Label restriction by the upstream to support some optical
E. Mannie (Editor) et al. Standard Track 24
constraints. constraints.
6. Bi-directional LSP establishment with contention resolution. 6. Bi-directional LSP establishment with contention resolution.
7. Rapid failure notification extensions. 7. Rapid failure notification extensions.
8. Protection information currently focusing on link protection, 8. Protection information currently focusing on link protection,
plus primary and secondary LSP indication. plus primary and secondary LSP indication.
9. Explicit routing with explicit label control for a fine 9. Explicit routing with explicit label control for a fine
degree of control. degree of control.
E. Mannie (Editor) et. al. - Expires August 2003 24
10. Specific traffic parameters per technology. 10. Specific traffic parameters per technology.
11. LSP administrative status handling. 11. LSP administrative status handling.
12. Control channel separation.
These building blocks will be described in mode details in the These building blocks will be described in more details in the
following. A complete specification can be found in the following. A complete specification can be found in the
corresponding documents. corresponding documents.
Note that GMPLS is highly generic and has many options. Only Note that GMPLS is highly generic and has many options. Only
building blocks 1, 2 and 10 are mandatory, and only within the building blocks 1, 2 and 10 are mandatory, and only within the
specific format that is needed. Typically, building blocks 6 and 9 specific format that is needed. Typically, building blocks 6 and 9
should be implemented. Building blocks 3, 4, 5, 7, 8 and 11 are should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are
optional. optional.
A typical SDH/SONET switching network would implement building A typical SONET/SDH switching network would implement building
blocks: 1, 2 (the SDH/SONET label), 6, 9, 10 and 11. Building blocks blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks
7 and 8 are optional since the protection/restoration can be 7 and 8 are optional since the protection/restoration can be
achieved using SDH/SONET overhead bytes. achieved using SONET/SDH overhead bytes.
A typical wavelength switching network would implement building A typical wavelength switching network would implement building
blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building
block 3 is only needed in the particular case of waveband switching. block 3 is only needed in the particular case of waveband switching.
A typical fiber switching network would implement building blocks: A typical fiber switching network would implement building blocks:
1, 2 (the generic format), 6, 7, 8, 9 and 11. 1, 2 (the generic format), 6, 7, 8, 9 and 11.
A typical MPLS-IP network would not implement any of these building A typical MPLS-IP network would not implement any of these building
blocks, since the absence of building block 1 would indicate regular blocks, since the absence of building block 1 would indicate regular
skipping to change at line 1371 skipping to change at line 1379
decide which are the optional elements and procedures of RSVP-TE and decide which are the optional elements and procedures of RSVP-TE and
CR-LDP that need to be implemented. Some optional MPLS-TE elements 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 can be useful for TDM, LSC and FSC layers, for instance the setup
and holding priorities that are inherited from MPLS-TE. and holding priorities that are inherited from MPLS-TE.
9.1. Overview: How to Request an LSP 9.1. Overview: How to Request an LSP
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request A TDM, LSC or FSC LSP is established by sending a PATH/Label Request
message downstream to the destination. This message contains a message downstream to the destination. This message contains a
Generalized Label Request with the type of LSP (i.e. the layer Generalized Label Request with the type of LSP (i.e. the layer
E. Mannie (Editor) et al. Standard Track 25
concerned), and its payload type. An Explicit Route Object (ERO) is concerned), and its payload type. An Explicit Route Object (ERO) is
also normally added to the message, but this can be added and/or also normally added to the message, but this can be added and/or
completed by the first/default LSR. completed by the first/default LSR.
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC
object, or in the CR-LDP Traffic Parameters TLV. Specific parameters object, or in the CR-LDP Traffic Parameters TLV. Specific parameters
for a given technology are given in these traffic parameters, such for a given technology are given in these traffic parameters, such
as the type of signal, concatenation and/or transparency for a as the type of signal, concatenation and/or transparency for a
SONET/SDH LSP. For some other technology there be could just one
E. Mannie (Editor) et. al. - Expires August 2003 25
SDH/SONET LSP. For some other technology there be could just one
bandwidth parameter indicating the bandwidth as a floating-point bandwidth parameter indicating the bandwidth as a floating-point
value. value.
The requested local protection per link may be requested using the The requested local protection per link may be requested using the
Protection Information Object/TLV. The end-to-end LSP protection is Protection Information Object/TLV. The end-to-end LSP protection is
for further study and is introduced LSP protection/restoration for further study and is introduced LSP protection/restoration
section (see after). section (see after).
If the LSP is a bi-directional LSP, an Upstream Label is also 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 specified in the Path/Label Request message. This label will be the
one to use in the upstream direction. one to use in the upstream direction.
Additionally, a Suggested Label, a Label Set and a Waveband Label Additionally, a Suggested Label, a Label Set and a Waveband Label
can also be included in the message. Other operations are defined in can also be included in the message. Other operations are defined in
MPLS-TE. MPLS-TE.
The downstream node will send back a Resv/Label Mapping message The downstream node will send back a Resv/Label Mapping message
including one Generalized Label object/TLV that can contain several including one Generalized Label object/TLV that can contain several
Generalized Labels. For instance, if a concatenated SDH/SONET signal Generalized Labels. For instance, if a concatenated SONET/SDH signal
is requested, several labels can be returned. is requested, several labels can be returned.
In case of SDH/SONET virtual concatenation, a list of labels is In case of SONET/SDH virtual concatenation, a list of labels is
returned. Each label identifying one element of the virtual returned. Each label identifying one element of the virtual
concatenated signal. This limits virtual concatenation to remain concatenated signal. This limits virtual concatenation to remain
within a single (component) link. within a single (component) link.
In case of any type of SDH/SONET contiguous concatenation, only one In case of any type of SONET/SDH contiguous concatenation, only one
label is returned. That label is the lowest signal of the contiguous label is returned. That label is the lowest signal of the contiguous
concatenated signal (given an order specified in [SONETSDH-GMPLS]). concatenated signal (given an order specified in [GMPLS-SONET-SDH]).
In case of SDH/SONET "multiplication", i.e. co-routing of circuits In case of SONET/SDH "multiplication", i.e. co-routing of circuits
of the same type but without concatenation but all belonging to the of the same type but without concatenation but all belonging to the
same LSP, the explicit ordered list of all signals that take part in same LSP, the explicit ordered list of all signals that take part in
the LSP is returned. the LSP is returned.
9.2. Generalized Label Request 9.2. Generalized Label Request
The Generalized Label Request is a new object/TLV to be added in an 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 RSVP-TE Path message instead of the regular Label Request, or in a
CR-LDP Request message in addition to the already existing TLVs. 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 Only one label request can be used per message, so a single LSP can
be requested at a time per signaling message. be requested at a time per signaling message.
The Generalized Label Request gives three major characteristics The Generalized Label Request gives three major characteristics
(parameters) required to support the LSP being requested: the LSP (parameters) required to support the LSP being requested: the LSP
E. Mannie (Editor) et al. Standard Track 26
Encoding Type, the Switching Type that must be used and the LSP Encoding Type, the Switching Type that must be used and the LSP
payload type called Generalized PID (G-PID). payload type called Generalized PID (G-PID).
The LSP Encoding Type indicates the encoding type that will be used 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 with the data associated with the LSP, i.e. the type of technology
being considered. For instance, it can be SDH, SONET, Ethernet, ANSI 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 PDH, etc. It represents the nature of the LSP, and not the nature of
E. Mannie (Editor) et. al. - Expires August 2003 26
the links that the LSP traverses. This is used hop-by-hop by each the links that the LSP traverses. This is used hop-by-hop by each
node. node.
A link may support a set of encoding formats, where support means 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 that a link is able to carry and switch a signal of one or more of
these encoding formats. The Switching Type indicates then the type these encoding formats. The Switching Type indicates then the type
of switching that should be performed on a particular link for that of switching that should be performed on a particular link for that
LSP. This information is needed for links that advertise more than LSP. This information is needed for links that advertise more than
one type of switching capability. one type of switching capability.
skipping to change at line 1469 skipping to change at line 1477
Other technology specific parameters are not transported in the Other technology specific parameters are not transported in the
Generalized Label Request but in technology specific traffic Generalized Label Request but in technology specific traffic
parameters as explained hereafter. Currently, two set of traffic parameters as explained hereafter. Currently, two set of traffic
parameters are defined, one for SONET/SDH and one for G.709. parameters are defined, one for SONET/SDH and one for G.709.
Note that it is expected than specific traffic parameters will be Note that it is expected than specific traffic parameters will be
defined in the future for photonic (all optical) switching. defined in the future for photonic (all optical) switching.
9.3. SONET/SDH Traffic Parameters 9.3. SONET/SDH Traffic Parameters
The GMPLS SDH/SONET traffic parameters [SONETSDH-GMPLS] specify a The GMPLS SONET/SDH traffic parameters [GMPLS-SONET-SDH] specify a
powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T powerful set of capabilities for SONET (ANSI T1.105) and SDH (ITU-T
G.707). Optional non-standard capabilities are also available in G.707).
[SONETSDH-EXT-GMPLS].
The first traffic parameter specifies the type of the elementary The first traffic parameter specifies the type of the elementary
SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6, SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6,
VC-4, STS-3c, etc. Several transforms can then be applied VC-4, STS-3c, etc. Several transforms can then be applied
successively on the elementary Signal to build the final signal successively on the elementary Signal to build the final signal
being actually requested for the LSP. being actually requested for the LSP.
These transforms are the contiguous concatenation, the virtual These transforms are the contiguous concatenation, the virtual
concatenation, the transparency and the multiplication. Each one is concatenation, the transparency and the multiplication. Each one is
optional. They must be applied strictly in the following order: optional. They must be applied strictly in the following order:
E. Mannie (Editor) et al. Standard Track 27
- First, contiguous concatenation can be optionally applied on the - First, contiguous concatenation can be optionally applied on the
Elementary Signal, resulting in a contiguously concatenated Elementary Signal, resulting in a contiguously concatenated
signal. signal.
- Second, virtual concatenation can be optionally applied either - Second, virtual concatenation can be optionally applied either
directly on the elementary Signal, or on the contiguously directly on the elementary Signal, or on the contiguously
concatenated signal obtained from the previous phase. concatenated signal obtained from the previous phase.
E. Mannie (Editor) et. al. - Expires August 2003 27
- Third, some transparency can be optionally specified when - Third, some transparency can be optionally specified when
requesting a frame as signal rather than a container. Several requesting a frame as signal rather than a container. Several
transparency packages are defined. transparency packages are defined.
- Fourth, a multiplication can be optionally applied either directly - Fourth, a multiplication can be optionally applied either directly
on the elementary Signal, or on the contiguously concatenated on the elementary Signal, or on the contiguously concatenated
signal obtained from the first phase, or on the virtually signal obtained from the first phase, or on the virtually
concatenated signal obtained from the second phase, or on these concatenated signal obtained from the second phase, or on these
signals combined with some transparency. signals combined with some transparency.
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new 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 SENDER_TSPEC and FLOWSPEC. The same format is used for both. There
is no Adspec associated with the SENDER_TSPEC, it is omitted or a is no Adspec associated with the SENDER_TSPEC, it is omitted or a
default value is used. The content of the FLOWSPEC object received default value is used. The content of the FLOWSPEC object received
in a Resv message should be identical to the content of the in a Resv message should be identical to the content of the
SENDER_TSPEC of the corresponding Path message. In other words, the SENDER_TSPEC of the corresponding Path message. In other words, the
receiver is normally not allowed to change the values of the traffic receiver is normally not allowed to change the values of the traffic
parameters. However, some level of negotiation may be achieved as parameters. However, some level of negotiation may be achieved as
explained in [SONETSDH-GMPLS] explained in [GMPLS-SONET-SDH].
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
new TLV. new TLV.
Note that a general discussion on SDH/SONET and GMPLS can be found Note that a general discussion on SONET/SDH and GMPLS can be found
in [SDH/SONET-GMPLS-FRAMEWORK]. in [SONET-SDH-GMPLS-FRM].
9.4. G.709 Traffic Parameters 9.4. G.709 Traffic Parameters
Simply said, an ITU-T G.709 based network is decomposed in two major Simply said, an ITU-T G.709 based network is decomposed in two major
layers: an optical layer (i.e. made of wavelengths) and a digital layers: an optical layer (i.e. made of wavelengths) and a digital
layer. These two layers are divided into sub-layers and switching layer. These two layers are divided into sub-layers and switching
occurs at two specific sub-layers: at the OCh (Optical Channel) occurs at two specific sub-layers: at the OCh (Optical Channel)
optical layer and at the ODU (Optical channel Data Unit) electrical optical layer and at the ODU (Optical channel Data Unit) electrical
layer. The ODUk notation is used to denote ODUs at different layer. The ODUk notation is used to denote ODUs at different
bandwidths. bandwidths.
The GMPLS G.709 traffic parameters [G709-GMPLS] specify a powerful The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful
set of capabilities for ITU-T G.709 networks. set of capabilities for ITU-T G.709 networks.
The first traffic parameter specifies the type of the elementary The first traffic parameter specifies the type of the elementary
G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40 G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40
Gbps, etc. Several transforms can then be applied successively on Gbps, etc. Several transforms can then be applied successively on
the elementary Signal to build the final signal being actually the elementary Signal to build the final signal being actually
requested for the LSP. requested for the LSP.
These transforms are the virtual concatenation and the These transforms are the virtual concatenation and the
multiplication. Each one of these transforms is optional. They must multiplication. Each one of these transforms is optional. They must
be applied strictly in the following order: be applied strictly in the following order:
E. Mannie (Editor) et al. Standard Track 28
- First, virtual concatenation can be optionally applied directly on - First, virtual concatenation can be optionally applied directly on
the elementary Signal, the elementary Signal,
- Second, a multiplication can be optionally applied, either - Second, a multiplication can be optionally applied, either
directly on the elementary Signal, or on the virtually directly on the elementary Signal, or on the virtually
concatenated signal obtained from the first phase. concatenated signal obtained from the first phase.
E. Mannie (Editor) et. al. - Expires August 2003 28
Additional ODUk Multiplexing traffic parameters allow indicating an Additional ODUk Multiplexing traffic parameters allow indicating an
ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request.
G.709 supports the following multiplexing capabilities: ODUj into G.709 supports the following multiplexing capabilities: ODUj into
ODUk (k > j); and ODU1 with ODU2 multiplexing into ODU3. ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new 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 SENDER-TSPEC and FLOWSPEC. The same format is used for both. There
is no Adspec associated with the SENDER_TSPEC, it is omitted or a is no Adspec associated with the SENDER_TSPEC, it is omitted or a
default value is used. The content of the FLOWSPEC object received default value is used. The content of the FLOWSPEC object received
in a Resv message should be identical to the content of the in a Resv message should be identical to the content of the
SENDER_TSPEC of the corresponding Path message. SENDER_TSPEC of the corresponding Path message.
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
new TLV. new TLV.
skipping to change at line 1593 skipping to change at line 1599
the representation of not only labels that travel in-band with the representation of not only labels that travel in-band with
associated data packets, but also (virtual) labels that identify associated data packets, but also (virtual) labels that identify
time-slots, wavelengths, or space division multiplexed positions. time-slots, wavelengths, or space division multiplexed positions.
For example, the Generalized Label may identify (a) a single fiber For example, the Generalized Label may identify (a) a single fiber
in a bundle, (b) a single waveband within fiber, (c) a single in a bundle, (b) a single waveband within fiber, (c) a single
wavelength within a waveband (or fiber), or (d) a set of time-slots wavelength within a waveband (or fiber), or (d) a set of time-slots
within a wavelength (or fiber). It may also be a generic MPLS label, 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 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 can be as simple as an integer value such as a wavelength
label or can be more elaborated such as an SDH/SONET or a G.709 label or can be more elaborated such as an SONET/SDH or a G.709
label. label.
E. Mannie (Editor) et al. Standard Track 29
SDH and SONET define each a multiplexing structure. These SDH and SONET define each a multiplexing structure. These
multiplexing structures will be used as naming trees to create multiplexing structures will be used as naming trees to create
unique labels. Such a label will identify the exact position (times- unique labels. Such a label will identify the exact position (times-
lot(s)) of a signal in a multiplexing structure. Since the SONET 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 may be seen as a subset of the SDH
E. Mannie (Editor) et. al. - Expires August 2003 29
multiplexing structure, the same format of label is used for SDH and multiplexing structure, the same format of label is used for SDH and
SONET. A similar concept is applied to build a label at the G.709 SONET. A similar concept is applied to build a label at the G.709
ODU layer. ODU layer.
Since the nodes sending and receiving the Generalized Label know Since the nodes sending and receiving the Generalized Label know
what kinds of link they are using, the Generalized Label does not what kinds of link they are using, the Generalized Label does not
identify its type. Instead, the nodes are expected to know from the identify its type. Instead, the nodes are expected to know from the
context what type of label to expect. context what type of label to expect.
A Generalized Label only carries a single level of label i.e. it is A Generalized Label only carries a single level of label i.e. it is
skipping to change at line 1651 skipping to change at line 1656
9.8. Label Suggestion by the Upstream 9.8. Label Suggestion by the Upstream
GMPLS allows for a label to be optionally suggested by an 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 node. This suggestion may be overridden by a downstream node but in
some cases, at the cost of higher LSP setup time. The suggested some cases, at the cost of higher LSP setup time. The suggested
label is valuable when establishing LSPs through certain kinds of label is valuable when establishing LSPs through certain kinds of
optical equipment where there may be a lengthy (in electrical terms) optical equipment where there may be a lengthy (in electrical terms)
delay in configuring the switching fabric. For example, micro delay in configuring the switching fabric. For example, micro
mirrors may have to be elevated or moved, and this physical motion mirrors may have to be elevated or moved, and this physical motion
E. Mannie (Editor) et al. Standard Track 30
and subsequent damping takes time. If the labels and hence switching and subsequent damping takes time. If the labels and hence switching
fabric are configured in the reverse direction (the norm), the Resv/ fabric are configured in the reverse direction (the norm), the Resv/
MAPPING message may need to be delayed by 10's of milliseconds per MAPPING message may need to be delayed by 10's of milliseconds per
hop in order to establish a usable forwarding path. It can be hop in order to establish a usable forwarding path. It can be
important for restoration purposes where alternate LSPs may need to important for restoration purposes where alternate LSPs may need to
be rapidly established as a result of network failures. be rapidly established as a result of network failures.
E. Mannie (Editor) et. al. - Expires August 2003 30
9.9. Label Restriction by the Upstream 9.9. Label Restriction by the Upstream
An upstream node can optionally restrict (limit) the choice of label An upstream node can optionally restrict (limit) the choice of label
of a downstream node to a set of acceptable labels. Giving lists of a downstream node to a set of acceptable labels. Giving lists
and/or ranges of inclusive (acceptable) or exclusive (unacceptable) and/or ranges of inclusive (acceptable) or exclusive (unacceptable)
labels in a Label Set provides this restriction. If not applied, all labels in a Label Set provides this restriction. If not applied, all
labels from the valid label range may be used. There are at least labels from the valid label range may be used. There are at least
four cases where a label restriction is useful in the "optical" four cases where a label restriction is useful in the "optical"
domain. domain.
skipping to change at line 1707 skipping to change at line 1712
In the remainder of this section, the term "initiator" is used to In the remainder of this section, the term "initiator" is used to
refer to a node that starts the establishment of an LSP; the term refer to a node that starts the establishment of an LSP; the term
"terminator" is used to refer to the node that is the target of the "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 LSP. For a bi-directional LSPs, there is only one initiator and one
terminator. terminator.
Normally to establish a bi-directional LSP when using [RSVP-TE] or Normally to establish a bi-directional LSP when using [RSVP-TE] or
[CR-LDP] two unidirectional paths must be independently established. [CR-LDP] two unidirectional paths must be independently established.
This approach has the following disadvantages: This approach has the following disadvantages:
E. Mannie (Editor) et al. Standard Track 31
1. The latency to establish the bi-directional LSP is equal to one 1. The latency to establish the bi-directional LSP is equal to one
round trip signaling time plus one initiator-terminator signaling round trip signaling time plus one initiator-terminator signaling
transit delay. This not only extends the setup latency for transit delay. This not only extends the setup latency for
successful LSP establishment, but it extends the worst-case latency successful LSP establishment, but it extends the worst-case latency
for discovering an unsuccessful LSP to as much as two times the for discovering an unsuccessful LSP to as much as two times the
E. Mannie (Editor) et. al. - Expires August 2003 31
initiator-terminator transit delay. These delays are particularly initiator-terminator transit delay. These delays are particularly
significant for LSPs that are established for restoration purposes. significant for LSPs that are established for restoration purposes.
2. The control overhead is twice that of a unidirectional LSP. This 2. The control overhead is twice that of a unidirectional LSP. This
is because separate control messages (e.g. Path and Resv) must be is because separate control messages (e.g. Path and Resv) must be
generated for both segments of the bi-directional LSP. generated for both segments of the bi-directional LSP.
3. Because the resources are established in separate segments, route 3. Because the resources are established in separate segments, route
selection is complicated. There is also additional potential race selection is complicated. There is also additional potential race
for conditions in assignment of resources, which decreases the for conditions in assignment of resources, which decreases the
overall probability of successfully establishing the bi-directional overall probability of successfully establishing the bi-directional
connection. connection.
4. It is more difficult to provide a clean interface for SDH/SONET 4. It is more difficult to provide a clean interface for SONET/SDH
equipment that may rely on bi-directional hop-by-hop paths for equipment that may rely on bi-directional hop-by-hop paths for
protection switching. Note that existing SDH/SONET equipment protection switching. Note that existing SONET/SDH equipment
transmits the control information in-band with the data. transmits the control information in-band with the data.
5. Bi-directional optical LSPs (or lightpaths) are seen as a 5. Bi-directional optical LSPs (or lightpaths) are seen as a
requirement for many optical networking service providers. requirement for many optical networking service providers.
With bi-directional LSPs both the downstream and upstream data With bi-directional LSPs both the downstream and upstream data
paths, i.e. from initiator to terminator and terminator to paths, i.e. from initiator to terminator and terminator to
initiator, are established using a single set of signaling messages. initiator, are established using a single set of signaling messages.
This reduces the setup latency to essentially one initiator- This reduces the setup latency to essentially one initiator-
terminator round trip time plus processing time, and limits the terminator round trip time plus processing time, and limits the
skipping to change at line 1763 skipping to change at line 1767
contention: the node with the higher node ID will win the contention: the node with the higher node ID will win the
contention. To reduce the probability of contention, some mechanisms contention. To reduce the probability of contention, some mechanisms
are also suggested. are also suggested.
9.12. Rapid Notification of Failure 9.12. Rapid Notification of Failure
GMPLS defines several signaling extensions that enable expedited GMPLS defines several signaling extensions that enable expedited
notification of failures and other events to nodes responsible for notification of failures and other events to nodes responsible for
restoring failed LSPs, and error handling. restoring failed LSPs, and error handling.
E. Mannie (Editor) et al. Standard Track 32
1. Acceptable Label Set for notification on Label Error: 1. Acceptable Label Set for notification on Label Error:
There are cases in traditional MPLS and in GMPLS that result in an There are cases in traditional MPLS and in GMPLS that result in an
error message containing an "Unacceptable label value" indication. error message containing an "Unacceptable label value" indication.
When these cases occur, it can useful for the node generating the When these cases occur, it can useful for the node generating the
E. Mannie (Editor) et. al. - Expires August 2003 32
error message to indicate which labels would be acceptable. To cover error message to indicate which labels would be acceptable. To cover
this case, GMPLS introduces the ability to convey such information this case, GMPLS introduces the ability to convey such information
via the "Acceptable Label Set". An Acceptable Label Set is carried via the "Acceptable Label Set". An Acceptable Label Set is carried
in appropriate protocol specific error messages. The format of an in appropriate protocol specific error messages. The format of an
Acceptable Label Set is identical to a Label Set. Acceptable Label Set is identical to a Label Set.
2. Expedited notification: 2. Expedited notification:
Extensions to RSVP-TE enable expedited notification of failures and Extensions to RSVP-TE enable expedited notification of failures and
other events to determined nodes. For CR-LDP, there is not currently other events to determined nodes. For CR-LDP, there is not currently
skipping to change at line 1819 skipping to change at line 1822
routing protocols. Path computation algorithms may consider this routing protocols. Path computation algorithms may consider this
information when computing paths for setting up LSPs. information when computing paths for setting up LSPs.
Protection information also indicates if the LSP is a primary or Protection information also indicates if the LSP is a primary or
secondary LSP. A secondary LSP is a backup to a primary LSP. The 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 resources of a secondary LSP are normally not used until the primary
LSP fails, but they may be used by other LSPs until the primary LSP 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 fails over the secondary LSP. At that point, any LSP that is using
the resources for the secondary LSP must be preempted. the resources for the secondary LSP must be preempted.
E. Mannie (Editor) et al. Standard Track 33
Six link protection types are currently defined as individual flags Six link protection types are currently defined as individual flags
and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared,
unprotected, extra traffic. See [GMPLS-SIG] section 7.1 for a unprotected, extra traffic. See [GMPLS-SIG] section 7.1 for a
precise definition of each. precise definition of each.
E. Mannie (Editor) et. al. - Expires August 2003 33
9.14. Explicit Routing and Explicit Label Control 9.14. Explicit Routing and Explicit Label Control
By using an explicit route, the path taken by an LSP can be By using an explicit route, the path taken by an LSP can be
controlled more or less precisely. Typically, the node at the head- controlled more or less precisely. Typically, the node at the head-
end of an LSP finds an explicit route and builds an Explicit Route end of an LSP finds an explicit route and builds an Explicit Route
Object (ERO)/ Explicit Route (ER) TLV that contains that route. Object (ERO)/ Explicit Route (ER) TLV that contains that route.
Possibly, the edge node does not build any explicit route, and just Possibly, the edge node does not build any explicit route, and just
transmit a signaling request to a default neighbor LSR (as IP/MPLS transmit a signaling request to a default neighbor LSR (as IP/MPLS
hosts would). For instance, an explicit route could be added to a hosts would). For instance, an explicit route could be added to a
signaling message by the first switching node, on behalf of the edge signaling message by the first switching node, on behalf of the edge
skipping to change at line 1875 skipping to change at line 1877
containing the IP address, or the interface identifier (in case of containing the IP address, or the interface identifier (in case of
unnumbered interface), associated with the link on which it is to be unnumbered interface), associated with the link on which it is to be
used. used.
This can also be used when it is desirable to "splice" two LSPs 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" together, i.e. where the tail of the first LSP would be "spliced"
into the head of the second LSP. into the head of the second LSP.
When used together with an optimization algorithm, it can provide When used together with an optimization algorithm, it can provide
very detailed explicit routes, including the label (timeslot) to use very detailed explicit routes, including the label (timeslot) to use
on a link, in order to minimize the fragmentation of the SDH/SONET
E. Mannie (Editor) et al. Standard Track 34
on a link, in order to minimize the fragmentation of the SONET/SDH
multiplex on the corresponding interface. multiplex on the corresponding interface.
9.15. Route Recording 9.15. Route Recording
E. Mannie (Editor) et. al. - Expires August 2003 34
In order to improve the reliability and the manageability of the LSP In order to improve the reliability and the manageability of the LSP
being established, the concept of the route recording was introduced being established, the concept of the route recording was introduced
in RSVP-TE to function as: in RSVP-TE to function as:
- First, a loop detection mechanism to discover L3 routing loops, or - First, a loop detection mechanism to discover L3 routing loops, or
loops inherent in the explicit route (this mechanism is strictly loops inherent in the explicit route (this mechanism is strictly
exclusive with the use of explicit routing objects). exclusive with the use of explicit routing objects).
- Second, a route recording mechanism collects up-to-date detailed - Second, a route recording mechanism collects up-to-date detailed
path information on a hop-by-hop basis during the LSP setup process. path information on a hop-by-hop basis during the LSP setup process.
skipping to change at line 1919 skipping to change at line 1922
reservation of resources. Then, the node performing the re-routing reservation of resources. Then, the node performing the re-routing
can swap on the new path and close the old path. This feature is 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 supported with RSVP-TE (using shared explicit filters) and CR-LDP
(using the action indicator flag). (using the action indicator flag).
LSP modification consists in changing some LSP parameters, but LSP modification consists in changing some LSP parameters, but
normally without changing the route. It is supported using the same normally without changing the route. It is supported using the same
mechanism as re-routing. However, the semantic of LSP modification mechanism as re-routing. However, the semantic of LSP modification
will differ from one technology to the other. For instance, further will differ from one technology to the other. For instance, further
studies are required to understand the impact of dynamically studies are required to understand the impact of dynamically
changing some SDH/SONET circuit characteristics such as the changing some SONET/SDH circuit characteristics such as the
bandwidth, the protection type, the transparency, the concatenation, bandwidth, the protection type, the transparency, the concatenation,
etc. etc.
9.17. LSP Administrative Status Handling 9.17. LSP Administrative Status Handling
GMPLS provides the optional capability to indicate the GMPLS provides the optional capability to indicate the
administrative status of an LSP by using a new Admin Status administrative status of an LSP by using a new Admin Status
object/TLV. Administrative Status information is currently used in object/TLV. Administrative Status information is currently used in
two ways. two ways.
E. Mannie (Editor) et al. Standard Track 35
In the first usage, the Admin Status object/TLV is carried in a In the first usage, the Admin Status object/TLV is carried in a
Path/Label Request or Resv/Label Mapping message to indicate the Path/Label Request or Resv/Label Mapping message to indicate the
administrative state of an LSP. In this usage, Administrative Status administrative state of an LSP. In this usage, Administrative Status
information indicates the state of the LSP, which include "up" or information indicates the state of the LSP, which include "up" or
"down", if it in a "testing" mode, and if deletion is in progress. "down", if it in a "testing" mode, and if deletion is in progress.
E. Mannie (Editor) et. al. - Expires August 2003 35
Based on that administrative status, a node can take local Based on that administrative status, a node can take local
decisions, like inhibit alarm reporting when an LSP is in "down" or decisions, like inhibit alarm reporting when an LSP is in "down" or
"testing" states, or report alarms associated with the connection at "testing" states, or report alarms associated with the connection at
a priority equal to or less than "Non service affecting". a priority equal to or less than "Non service affecting".
It is possible that some nodes along an LSP will not support the It is possible that some nodes along an LSP will not support the
Admin Status Object/TLV. In the case of a non-supporting transit Admin Status Object/TLV. In the case of a non-supporting transit
node, the object will pass through the node unmodified and normal node, the object will pass through the node unmodified and normal
processing can continue. processing can continue.
skipping to change at line 1974 skipping to change at line 1977
egress nodes triggering the setting of administrative status. In egress nodes triggering the setting of administrative status. In
particular, this allows intermediate or egress LSRs requesting a particular, this allows intermediate or egress LSRs requesting a
release of an LSP initiated by the ingress node. release of an LSP initiated by the ingress node.
9.18. Control Channel Separation 9.18. Control Channel Separation
In GMPLS, a control channel can be separated from the data channel. In GMPLS, a control channel can be separated from the data channel.
Indeed, the control channel can be implemented completely out-of- Indeed, the control channel can be implemented completely out-of-
band for various reason, e.g. when the data channel cannot carry in- band for various reason, e.g. when the data channel cannot carry in-
band control information. This issue was even originally introduced band control information. This issue was even originally introduced
to MPLS in relation with link bundling. to MPLS in the context of link bundling.
In traditional MPLS, there is an implicit one-to-one association of In traditional MPLS, there is an implicit one-to-one association of
a control channel to a data channel. When such an association is a control channel to a data channel. When such an association is
present, no additional or special information is required to present, no additional or special information is required to
associate a particular LSP setup transaction with a particular data associate a particular LSP setup transaction with a particular data
channel. channel.
Otherwise, it is necessary to convey additional information in Otherwise, it is necessary to convey additional information in
signaling to identify the particular data channel being controlled. signaling to identify the particular data channel being controlled.
GMPLS supports explicit data channel identification by providing GMPLS supports explicit data channel identification by providing
E. Mannie (Editor) et al. Standard Track 36
interface identification information. GMPLS allows the use of a interface identification information. GMPLS allows the use of a
number of interface identification schemes including IPv4 or IPv6 number of interface identification schemes including IPv4 or IPv6
addresses, interface indexes (for unnumbered interfaces) and addresses, interface indexes (for unnumbered interfaces) and
component interfaces (for bundled interfaces), unnumbered bundled component interfaces (for bundled interfaces), unnumbered bundled
interfaces are also supported. interfaces are also supported.
E. Mannie (Editor) et. al. - Expires August 2003 36
The choice of the data interface to use is always made by the sender The choice of the data interface to use is always made by the sender
of the Path/Label Request message, and indicated by including the of the Path/Label Request message, and indicated by including the
data channel's interface identifier in the message using a new data channel's interface identifier in the message using a new
RSVP_HOP object sub-type/Interface TLV. RSVP_HOP object sub-type/Interface TLV.
For bi-directional LSPs, the sender chooses the data interface in For bi-directional LSPs, the sender chooses the data interface in
each direction. In all cases but bundling, the upstream interface is each direction. In all cases but bundling, the upstream interface is
implied by the downstream interface. For bundling, the Path/Label implied by the downstream interface. For bundling, the Path/Label
Request sender explicitly identifies the component interface used in Request sender explicitly identifies the component interface used in
each direction. The new object/TLV is used in Resv/Label Mapping each direction. The new object/TLV is used in Resv/Label Mapping
skipping to change at line 2034 skipping to change at line 2038
increase the scalability of the signaling. increase the scalability of the signaling.
The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) The aggregation is accomplished by (a) an LSR creating a TE LSP, (b)
the LSR forming a forwarding adjacency out of that LSP (advertising the LSR forming a forwarding adjacency out of that LSP (advertising
this LSP as a Traffic Engineering (TE) link into ISIS/OSPF), (c) this LSP as a Traffic Engineering (TE) link into ISIS/OSPF), (c)
allowing other LSRs to use forwarding adjacencies for their path allowing other LSRs to use forwarding adjacencies for their path
computation, and (d) nesting of LSPs originated by other LSRs into 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 that LSP (e.g. by using the label stack construct in the case of
IP). IP).
An LSR may announce (under its local configuration control) an LSP ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs
as a TE link into ISIS/OSPF. When this link is advertised into the just as it floods the information about any other links.
same instance of ISIS/OSPF as the one that determines the route Consequently to this flooding, an LSR has in its TE link state
taken by the LSP, we call such a link a "forwarding adjacency" (FA). database the information about not just conventional links, but FAs
We refer to the LSP as the "forwarding adjacency LSP", or just FA- as well.
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
E. Mannie (Editor) et. al. - Expires August 2003 37
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. Consequently to this flooding, an
LSR has in its TE link state database the information about not just
conventional links, but FAs as well.
E. Mannie (Editor) et al. Standard Track 37
An LSR, when performing path computation, uses not just conventional An LSR, when performing path computation, uses not just conventional
links, but FAs as well. Once a path is computed, the LSR uses RSVP- 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 TE/CR-LDP for establishing label binding along the path. FAs need
simple extensions to signaling and routing protocols. simple extensions to signaling and routing protocols.
10.1. Routing and Forwarding Adjacencies 10.1. Routing and Forwarding Adjacencies
Forwarding adjacencies may be represented as either unnumbered or Forwarding adjacencies may be represented as either unnumbered or
numbered links. A FA can also be a bundle of LSPs between two nodes. numbered links. A FA can also be a bundle of LSPs between two nodes.
skipping to change at line 2101 skipping to change at line 2089
the resulting bundled link carries a Path TLV, the underlying path the resulting bundled link carries a Path TLV, the underlying path
followed by each of the FA-LSPs that form the component links must followed by each of the FA-LSPs that form the component links must
be the same. be the same.
It is expected that forwarding adjacencies will not be used for It is expected that forwarding adjacencies will not be used for
establishing ISIS/OSPF peering relation between the routers at the establishing ISIS/OSPF peering relation between the routers at the
ends of the adjacency. ends of the adjacency.
LSP hierarchy could exist both with the peer and with the overlay LSP hierarchy could exist both with the peer and with the overlay
models. With the peer model, the LSP hierarchy is realized via FAs models. With the peer model, the LSP hierarchy is realized via FAs
E. Mannie (Editor) et. al. - Expires August 2003 38
and an LSP is both created and used as a TE link by exactly the same and an LSP is both created and used as a TE link by exactly the same
instance of the control plane. Creating LSP hierarchies with instance of the control plane. Creating LSP hierarchies with
overlays doesn't involve the concept of FA. With the overlay model overlays doesn't involve the concept of FA. With the overlay model
an LSP created (and maintained) by one instance of the GMPLS control an LSP created (and maintained) by one instance of the GMPLS control
plane is used as a TE link by another instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control
plane. Moreover, the nodes using a TE link are expected to have a plane. Moreover, the nodes using a TE link are expected to have a
routing and signaling adjacency. routing and signaling adjacency.
10.2. Signaling Aspects 10.2. Signaling Aspects
E. Mannie (Editor) et al. Standard Track 38
For the purpose of processing the explicit route in a Path/Request For the purpose of processing the explicit route in a Path/Request
message of an LSP that is to be tunneled over a forwarding 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 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). tail of that FA-LSP as adjacent (one IP hop away).
10.3. Cascading of Forwarding Adjacencies 10.3. Cascading of Forwarding Adjacencies
With an integrated model, several layers are controlled using the With an integrated model, several layers are controlled using the
same routing and signaling protocols. A network may then have links same routing and signaling protocols. A network may then have links
with different multiplexing/demultiplexing capabilities. For with different multiplexing/demultiplexing capabilities. For
example, a node may be able to multiplex/demultiplex individual example, a node may be able to multiplex/demultiplex individual
packets on a given link, and may be able to multiplex/demultiplex packets on a given link, and may be able to multiplex/demultiplex
channels within a SONET payload on other links. channels within a SONET payload on other links.
A new OSPF and IS-IS sub-TLV has been defined to advertise the A new OSPF and IS-IS sub-TLV has been defined to advertise the
multiplexing capability of each interface: PSC, L2SC, TDM, LSC or multiplexing capability of each interface: PSC, L2SC, TDM, LSC or
FSC. This sub-TLV is called the Interface Switching Capability FSC. This sub-TLV is called the Interface Switching Capability
Descriptor sub-TLV, which complements the sub-TLVs defined in [OSPF- Descriptor sub-TLV, which complements the sub-TLVs defined in [OSPF-
TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this sub- TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this sub-
TLV is used to construct LSP regions, and determine regionÆs TLV is used to construct LSP regions, and determine region's
boundaries. boundaries.
Path computation may take into account region boundaries when Path computation may take into account region boundaries when
computing a path for an LSP. For example, path computation may computing a path for an LSP. For example, path computation may
restrict the path taken by an LSP to only the links whose restrict the path taken by an LSP to only the links whose
multiplexing/demultiplexing capability is PSC. When an LSP need to multiplexing/demultiplexing capability is PSC. When an LSP need to
cross a region boundary, it can trigger the establishment of an FA 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 at the underlying layer (i.e. the L2SC layer). This can trigger a
cascading of FAs between layers with the following obvious order: cascading of FAs between layers with the following obvious order:
L2SC, then TDM, then LSC, and then finally FSC. L2SC, then TDM, then LSC, and then finally FSC.
skipping to change at line 2156 skipping to change at line 2143
By definition, two nodes have a routing (ISIS/OSPF) adjacency if By definition, two nodes have a routing (ISIS/OSPF) adjacency if
they are neighbors in the ISIS/OSPF sense. they are neighbors in the ISIS/OSPF sense.
By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency
if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are
RSVP-TE neighbors if they directly exchange RSVP-TE messages RSVP-TE neighbors if they directly exchange RSVP-TE messages
(Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of
[HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE
Hellos. Hellos.
E. Mannie (Editor) et. al. - Expires August 2003 39
By definition, a Forwarding Adjacency (FA) is a TE Link between two By definition, a Forwarding Adjacency (FA) is a TE Link between two
GMPLS nodes whose path transits one or more other (G)MPLS nodes in GMPLS nodes whose path transits one or more other (G)MPLS nodes in
the same instance of the (G)MPLS control plane. If two nodes have the same instance of the (G)MPLS control plane. If two nodes have
one or more non-FA TE Links between them, these two nodes are one or more non-FA TE Links between them, these two nodes are
expected (although not required) to have a routing adjacency. If two expected (although not required) to have a routing adjacency. If two
nodes do not have any non-FA TE Links between them, it is expected nodes do not have any non-FA TE Links between them, it is expected
(although not required) that these two nodes would not have a (although not required) that these two nodes would not have a
routing adjacency. To state the obvious, if the TE links between two routing adjacency. To state the obvious, if the TE links between two
nodes are to be used for establishing LSPs, the two nodes must have nodes are to be used for establishing LSPs, the two nodes must have
a signaling adjacency. a signaling adjacency.
E. Mannie (Editor) et al. Standard Track 39
If one wants to establish routing and/or signaling adjacency between If one wants to establish routing and/or signaling adjacency between
two nodes, there must be an IP path between them. This IP path can two nodes, there must be an IP path between them. This IP path can
be, for example, a TE Link with an interface switching capability of be, for example, a TE Link with an interface switching capability of
PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a
(bi-directional) LSP that with an interface switching capability of (bi-directional) LSP that with an interface switching capability of
PSC). PSC).
A TE link may not be capable of being used directly for maintaining A TE link may not be capable of being used directly for maintaining
routing and/or signaling adjacencies. This is because GMPLS routing routing and/or signaling adjacencies. This is because GMPLS routing
and signaling adjacencies requires exchanging data on a per (IP/ISO) and signaling adjacencies requires exchanging data on a per frame/
packet basis, and a TE link (e.g. a link between OXCs) may not be packet basis, and a TE link (e.g. a link between OXCs) may not be
capable of exchanging data on a per packet basis. In this case, the capable of exchanging data on a per packet basis. In this case, the
routing and signaling adjacencies are maintained via a set of one or routing and signaling adjacencies are maintained via a set of one or
more control channels (see [LMP]). more control channels (see [LMP]).
Two nodes may have a TE link between them even if they don't have a Two nodes may have a TE link between them even if they don't have a
routing adjacency. Naturally, each node must run OSPF/ISIS with routing adjacency. Naturally, each node must run OSPF/ISIS with
GMPLS extensions in order for that TE link to be advertised. More GMPLS extensions in order for that TE link to be advertised. More
precisely, the node needs to run GMPLS extensions for TE Links with precisely, the node needs to run GMPLS extensions for TE Links with
an interface switching capability (see [GMPLS-ROUTING]) other than an interface switching capability (see [GMPLS-ROUTING]) other than
skipping to change at line 2211 skipping to change at line 2198
12. Control Plane Fault Handling 12. Control Plane Fault Handling
Two major types of faults can impact a control plane. The first, Two major types of faults can impact a control plane. The first,
referred to as control channel fault, relates to the case where referred to as control channel fault, relates to the case where
control communication is lost between two neighboring nodes. If the control communication is lost between two neighboring nodes. If the
control channel is embedded with the data channel, data channel control channel is embedded with the data channel, data channel
recovery procedure should solve the problem. If the control channel recovery procedure should solve the problem. If the control channel
is independent of the data channel, additional procedures are is independent of the data channel, additional procedures are
required to recover from that problem. required to recover from that problem.
E. Mannie (Editor) et. al. - Expires August 2003 40
The second, referred to as nodal faults, relates to the case where The second, referred to as nodal faults, relates to the case where
node losses its control state (e.g., after a restart) but does not node loses its control state (e.g., after a restart) but does not
loose its data forwarding state. loose its data forwarding state.
In transport networks, such types of control plane faults should not In transport networks, such types of control plane faults should not
have service impact on the existing connections. Under such have service impact on the existing connections. Under such
circumstances, a mechanism must exist to detect a control circumstances, a mechanism must exist to detect a control
communication failure and a recovery procedure must guarantee communication failure and a recovery procedure must guarantee
connection integrity at both ends of the control channel. connection integrity at both ends of the control channel.
E. Mannie (Editor) et al. Standard Track 40
For a control channel fault, once communication is restored routing For a control channel fault, once communication is restored routing
protocols are naturally able to recover but the underlying signaling protocols are naturally able to recover but the underlying signaling
protocols must indicate that the nodes have maintained their state protocols must indicate that the nodes have maintained their state
through the failure. The signaling protocol must also ensure that through the failure. The signaling protocol must also ensure that
any state changes that were instantiated during the failure are any state changes that were instantiated during the failure are
synchronized between the nodes. synchronized between the nodes.
For a nodal fault, a node's control plane restarts and losses most For a nodal fault, a node's control plane restarts and loses most of
of it's state information. In this case, both upstream and its state information. In this case, both upstream and downstream
downstream nodes must synchronize their state information with the nodes must synchronize their state information with the restarted
restarted node. In order for any resynchronization to occur the node node. In order for any resynchronization to occur the node
undergoing the restart will need to preserve some information, such undergoing the restart will need to preserve some information, such
as it's mappings of incoming to outgoing labels. as it's mappings of incoming to outgoing labels.
These issues are addressed in protocol specific fashions, see [RSVP- These issues are addressed in protocol specific fashions, see [RSVP-
TE-GMPLS] and [CR-LDP-GMPLS]. Note that these cases only apply when TE-GMPLS], [CR-LDP-GMPLS], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note
there are mechanisms to detect data channel failures independent of that these cases only apply when there are mechanisms to detect data
control channel failures. channel failures independent of control channel failures.
The LDP Fault tolerant draft [LDP-FT] specifies the procedures to The LDP Fault tolerance (see [LDP-FT]) specifies the procedures to
recover from a control channel failure. [RSVP-TE-GMPLS] specifies recover from a control channel failure. [RSVP-TE-GMPLS] specifies
how to recover from both a control channel failure and a node how to recover from both a control channel failure and a node
failure. failure.
13. LSP Protection and Restoration 13. LSP Protection and Restoration
This section discusses Protection and Restoration (P&R) issues for This section discusses Protection and Restoration (P&R) issues for
GMPLS LSPs. It is driven by the requirements outlined in [RFC3386] GMPLS LSPs. It is driven by the requirements outlined in [RFC3386]
and some of the principles outlined in [RFC3469]. It will be and some of the principles outlined in [RFC3469]. It will be
enhanced, as more GMPLS P&R mechanisms are defined. The scope of enhanced, as more GMPLS P&R mechanisms are defined. The scope of
skipping to change at line 2265 skipping to change at line 2252
happens in the data/transport plane. Section 11 deals with control happens in the data/transport plane. Section 11 deals with control
plane fault handling for nodal and control channel faults. plane fault handling for nodal and control channel faults.
- This section focuses on P&R at the TDM, LSC and FSC layers. There - This section focuses on P&R at the TDM, LSC and FSC layers. There
are specific P&R requirements at these layers not present at the are specific P&R requirements at these layers not present at the
PSC layer. PSC layer.
- This section focuses on intra-area P&R as opposed to inter-area - This section focuses on intra-area P&R as opposed to inter-area
P&R and even inter-domain P&R. Note that P&R can even be more P&R and even inter-domain P&R. Note that P&R can even be more
restricted, e.g. to a collection of like customer equipment, or a restricted, e.g. to a collection of like customer equipment, or a
E. Mannie (Editor) et. al. - Expires August 2003 41
collection of equipment of like capabilities, in one single collection of equipment of like capabilities, in one single
routing area. routing area.
- This section focuses on intra-layer P&R (horizontal hierarchy as - This section focuses on intra-layer P&R (horizontal hierarchy as
defined in [RFC3386]) as opposed to the inter-layer P&R (vertical defined in [RFC3386]) as opposed to the inter-layer P&R (vertical
hierarchy). hierarchy).
- P&R mechanisms are in general designed to handle single failures, - P&R mechanisms are in general designed to handle single failures,
which makes SRLG diversity a necessity. Recovery from multiple which makes SRLG diversity a necessity. Recovery from multiple
failures requires further study. failures requires further study.
E. Mannie (Editor) et al. Standard Track 41
- Both mesh and ring-like topologies are supported. - Both mesh and ring-like topologies are supported.
In the following, we assume that: In the following, we assume that:
- TDM, LSC and FSC devices are more generally committing recovery - TDM, LSC and FSC devices are more generally committing recovery
resources in a non-best effort way. Recovery resources are either resources in a non-best effort way. Recovery resources are either
allocated (thus used) or at least logically reserved (whether used allocated (thus used) or at least logically reserved (whether used
or not by preemptable extra traffic but unavailable anyway for or not by preemptable extra traffic but unavailable anyway for
regular working traffic). regular working traffic).
skipping to change at line 2321 skipping to change at line 2307
fibers, etc). fibers, etc).
In the absence of adequate P&R coordination, a fault may propagate In the absence of adequate P&R coordination, a fault may propagate
from one level to the next within a P&R hierarchy. It can lead to from one level to the next within a P&R hierarchy. It can lead to
"collisions" and simultaneous recovery actions may lead to race "collisions" and simultaneous recovery actions may lead to race
conditions, reduced resource utilization, or instabilities conditions, reduced resource utilization, or instabilities
[MANCHESTER]. Thus, a consistent escalation strategy is needed to [MANCHESTER]. Thus, a consistent escalation strategy is needed to
coordinate recovery across domains and layers. The fact that GMPLS coordinate recovery across domains and layers. The fact that GMPLS
can be used at different layers could simplify this coordination. can be used at different layers could simplify this coordination.
E. Mannie (Editor) et. al. - Expires August 2003 42
There are two types of escalation strategies: bottom-up and top- There are two types of escalation strategies: bottom-up and top-
down. The bottom-up approach assumes that "lower-level" recovery down. The bottom-up approach assumes that "lower-level" recovery
schemes are more expedient. Therefore we can inhibit or hold off schemes are more expedient. Therefore we can inhibit or hold off
higher-level P&R. The Top-down approach attempts service P&R at higher-level P&R. The Top-down approach attempts service P&R at
the higher levels before invoking "lower level" P&R. Higher-layer the higher levels before invoking "lower level" P&R. Higher-layer
P&R is service selective, and permits "per-CoS" or "per-LSP" re- P&R is service selective, and permits "per-CoS" or "per-LSP" re-
routing. routing.
SLA's between network operators and their clients are needed to Service Level Agreements (SLAs) between network operators and their
determine the necessary time scales for P&R at each layer and at clients are needed to determine the necessary time scales for P&R at
each domain. each layer and at each domain.
E. Mannie (Editor) et al. Standard Track 42
13.2. Mapping of Services to P&R Resources 13.2. Mapping of Services to P&R Resources
The choice of a P&R scheme is a tradeoff between network utilization The choice of a P&R scheme is a tradeoff between network utilization
(cost) and service interruption time. In light of this tradeoff, (cost) and service interruption time. In light of this tradeoff,
network service providers are expected to support a range of network service providers are expected to support a range of
different service offerings or service levels. different service offerings or service levels.
One can classify LSPs into one of a small set of service levels. One can classify LSPs into one of a small set of service levels.
Among other things, these service levels define the reliability Among other things, these service levels define the reliability
skipping to change at line 2375 skipping to change at line 2362
The following figure provides a classification of the possible The following figure provides a classification of the possible
provisioning types of recovery LSPs, and of the levels of provisioning types of recovery LSPs, and of the levels of
overbooking that is possible for them. overbooking that is possible for them.
+-Computed on +-Established +-Resources pre- +-Computed on +-Established +-Resources pre-
| demand | on demand | allocated | demand | on demand | allocated
Recovery LSP | | | Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand on demand
E. Mannie (Editor) et. al. - Expires August 2003 43
+--- Dedicated (1:1, 1+1) +--- Dedicated (1:1, 1+1)
| |
| |
+--- Shared (1:N, Ring, Shared mesh) +--- Shared (1:N, Ring, Shared mesh)
| |
Level of | Level of |
Overbooking ---+--- Best effort Overbooking ---+--- Best effort
E. Mannie (Editor) et al. Standard Track 43
13.4. Different Stages in P&R 13.4. Different Stages in P&R
Recovery from a network fault or impairment takes place in several Recovery from a network fault or impairment takes place in several
stages as discussed in [RFC3469], including fault detection, fault stages as discussed in [RFC3469], including fault detection, fault
localization, notification, recovery (i.e. the P&R itself) and localization, notification, recovery (i.e. the P&R itself) and
reversion of traffic (i.e. returning the traffic to the original reversion of traffic (i.e. returning the traffic to the original
working LSP or to a new one). working LSP or to a new one).
- Fault detection is technology and implementation dependent. In - Fault detection is technology and implementation dependent. In
general, failures are detected by lower layer mechanisms (e.g. general, failures are detected by lower layer mechanisms (e.g.
skipping to change at line 2421 skipping to change at line 2409
Network P&R techniques can be divided into Protection and Network P&R techniques can be divided into Protection and
Restoration. In protection, resources between the protection Restoration. In protection, resources between the protection
endpoints are established before failure, and connectivity after endpoints are established before failure, and connectivity after
failure is achieved simply by switching performed at the protection failure is achieved simply by switching performed at the protection
end-points. In contrast, restoration uses signaling after failure to end-points. In contrast, restoration uses signaling after failure to
allocate resources along the recovery path. allocate resources along the recovery path.
- Protection aims at extremely fast reaction times and may rely on - Protection aims at extremely fast reaction times and may rely on
the use of overhead control fields for achieving end-point the use of overhead control fields for achieving end-point
coordination. Protection for SONET/SDH networks is described in coordination. Protection for SONET/SDH networks is described in
[G.841] and [ANSI-T1.105]. Protection mechanisms can be further [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be
classified by the level of redundancy and sharing. further classified by the level of redundancy and sharing.
- Restoration mechanisms rely on signaling protocols to coordinate - Restoration mechanisms rely on signaling protocols to coordinate
switching actions during recovery, and may involve simple re- switching actions during recovery, and may involve simple re-
provisioning, i.e. signaling only at the time of recovery; or pre- provisioning, i.e. signaling only at the time of recovery; or pre-
signaling, i.e., signaling prior to recovery. signaling, i.e., signaling prior to recovery.
E. Mannie (Editor) et. al. - Expires August 2003 44
In addition, P&R can be applied on a local or end-to-end basis. In In addition, P&R can be applied on a local or end-to-end basis. In
the local approach, P&R is focused on the local proximity of the the local approach, P&R is focused on the local proximity of the
fault in order to reduce delay in restoring service. In the end-to- fault in order to reduce delay in restoring service. In the end-to-
end approach, the LSP originating and terminating nodes control end approach, the LSP originating and terminating nodes control
recovery. recovery.
Using these strategies, the following recovery mechanisms can be Using these strategies, the following recovery mechanisms can be
defined. defined.
E. Mannie (Editor) et al. Standard Track 44
13.6. Recovery mechanisms: Protection schemes 13.6. Recovery mechanisms: Protection schemes
Note that protection schemes are usually defined in technology Note that protection schemes are usually defined in technology
specific ways, but this does not preclude other solutions. specific ways, but this does not preclude other solutions.
- 1+1 Link Protection: Two pre-provisioned resources are used in - 1+1 Link Protection: Two pre-provisioned resources are used in
parallel. For example, data is transmitted simultaneously on two parallel. For example, data is transmitted simultaneously on two
parallel links and a selector is used at the receiving node to parallel links and a selector is used at the receiving node to
choose the best source (see also [FUNCT]). choose the best source (see also [GMPLS-FUNCT]).
- 1:N Link Protection: Working and protecting resources (N working, - 1:N Link Protection: Working and protecting resources (N working,
1 backup) are pre-provisioned. If a working resource fails, the 1 backup) are pre-provisioned. If a working resource fails, the
data is switched to the protecting resource, using a coordination data is switched to the protecting resource, using a coordination
mechanism (e.g. in overhead bytes). More generally, N working and mechanism (e.g. in overhead bytes). More generally, N working and
M protecting resources can be assigned for M:N link protection M protecting resources can be assigned for M:N link protection
(see also [FUNCT]). (see also [GMPLS-FUNCT]).
- Enhanced Protection: Various mechanisms such as protection rings - Enhanced Protection: Various mechanisms such as protection rings
can be used to enhance the level of protection beyond single link can be used to enhance the level of protection beyond single link
failures to include the ability to switch around a node failure or failures to include the ability to switch around a node failure or
multiple link failures within a span, based on a pre-established multiple link failures within a span, based on a pre-established
topology of protection resources (note: no reference available at topology of protection resources (note: no reference available at
publication time). publication time).
- 1+1 LSP Protection: Simultaneous data transmission on working and - 1+1 LSP Protection: Simultaneous data transmission on working and
protecting LSPs and tail-end selection can be applied (see also protecting LSPs and tail-end selection can be applied (see also
[FUNCT]). [GMPLS-FUNCT]).
13.7. Recovery mechanisms: Restoration schemes 13.7. Recovery mechanisms: Restoration schemes
Thanks to the use of a distributed control plane like GMPLS, Thanks to the use of a distributed control plane like GMPLS,
restoration is possible in multiple of tenths of milliseconds. It is restoration is possible in multiple of tenths of milliseconds. It is
much harder to achieve when only an NMS is used and can only be done much harder to achieve when only an NMS is used and can only be done
in that case in a multiple of seconds. in that case in a multiple of seconds.
- End-to-end LSP restoration with re-provisioning: an end-to-end - End-to-end LSP restoration with re-provisioning: an end-to-end
restoration path is established after failure. The restoration restoration path is established after failure. The restoration
path may be dynamically calculated after failure, or pre- path may be dynamically calculated after failure, or pre-
calculated before failure (often during LSP establishment). calculated before failure (often during LSP establishment).
Importantly, no signaling is used along the restoration path Importantly, no signaling is used along the restoration path
before failure, and no restoration bandwidth is reserved. before failure, and no restoration bandwidth is reserved.
Consequently, there is no guarantee that a given restoration path Consequently, there is no guarantee that a given restoration path
is available when a failure occurs. Thus, one may have to is available when a failure occurs. Thus, one may have to
crankback to search for an available path. crankback to search for an available path.
E. Mannie (Editor) et. al. - Expires August 2003 45
- End-to-end LSP restoration with pre-signaled recovery bandwidth - End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and no label pre-selection: an end-to-end restoration reservation and no label pre-selection: an end-to-end restoration
path is pre-calculated before failure and a signaling message is path is pre-calculated before failure and a signaling message is
sent along this pre-selected path to reserve bandwidth, but labels sent along this pre-selected path to reserve bandwidth, but labels
are not selected (see also [FUNCT]). are not selected (see also [GMPLS-FUNCT]).
The resources reserved on each link of a restoration path may be The resources reserved on each link of a restoration path may be
shared across different working LSPs that are not expected to fail shared across different working LSPs that are not expected to fail
simultaneously. Local node policies can be applied to define the simultaneously. Local node policies can be applied to define the
degree to which capacity is shared across independent failures. degree to which capacity is shared across independent failures.
E. Mannie (Editor) et al. Standard Track 45
Upon failure detection, LSP signaling is initiated along the Upon failure detection, LSP signaling is initiated along the
restoration path to select labels, and to initiate the appropriate restoration path to select labels, and to initiate the appropriate
cross-connections. cross-connections.
- End-to-end LSP restoration with pre-signaled recovery bandwidth - End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and label pre-selection: An end-to-end restoration reservation and label pre-selection: An end-to-end restoration
path is pre-calculated before failure and a signaling procedure is path is pre-calculated before failure and a signaling procedure is
initiated along this pre-selected path on which bandwidth is initiated along this pre-selected path on which bandwidth is
reserved and labels are selected (see also [FUNCT]). reserved and labels are selected (see also [GMPLS-FUNCT]).
The resources reserved on each link may be shared across different The resources reserved on each link may be shared across different
working LSPs that are not expected to fail simultaneously. In working LSPs that are not expected to fail simultaneously. In
networks based on TDM, LSC and FSC technology, LSP signaling is networks based on TDM, LSC and FSC technology, LSP signaling is
used after failure detection to establish cross-connections at the used after failure detection to establish cross-connections at the
intermediate switches on the restoration path using the pre- intermediate switches on the restoration path using the pre-
selected labels. selected labels.
- Local LSP restoration: the above approaches can be applied on a - Local LSP restoration: the above approaches can be applied on a
local basis rather than end-to-end, in order to reduce recovery local basis rather than end-to-end, in order to reduce recovery
skipping to change at line 2539 skipping to change at line 2528
paths. The risk of simultaneous failure of the two paths can be paths. The risk of simultaneous failure of the two paths can be
reduced by recalculating the restoration path whenever a failure reduced by recalculating the restoration path whenever a failure
occurs along it. occurs along it.
The pre-selection of a label gives less flexibility for multiple The pre-selection of a label gives less flexibility for multiple
failure scenarios than no label pre-selection. If failures occur failure scenarios than no label pre-selection. If failures occur
that affect two LSPs that are sharing a label at a common node that affect two LSPs that are sharing a label at a common node
along their restoration routes, then only one of these LSPs can be along their restoration routes, then only one of these LSPs can be
recovered, unless the label assignment is changed. recovered, unless the label assignment is changed.
E. Mannie (Editor) et. al. - Expires August 2003 46
The robustness of a restoration scheme is also determined by the The robustness of a restoration scheme is also determined by the
amount of reserved restoration bandwidth - as the amount of amount of reserved restoration bandwidth - as the amount of
restoration bandwidth sharing increases (reserved bandwidth restoration bandwidth sharing increases (reserved bandwidth
decreases), the restoration scheme becomes less robust to decreases), the restoration scheme becomes less robust to
failures. Restoration schemes with pre-signaled bandwidth failures. Restoration schemes with pre-signaled bandwidth
reservation (with or without label pre-selection) can reserve reservation (with or without label pre-selection) can reserve
adequate bandwidth to ensure recovery from any specific set of adequate bandwidth to ensure recovery from any specific set of
failure events, such as any single SRLG failure, any two SRLG failure events, such as any single SRLG failure, any two SRLG
failures etc. Clearly, more restoration capacity is allocated if a failures etc. Clearly, more restoration capacity is allocated if a
greater degree of failure recovery is required. Thus, the degree greater degree of failure recovery is required. Thus, the degree
E. Mannie (Editor) et al. Standard Track 46
to which the network is protected is determined by the policy that to which the network is protected is determined by the policy that
defines the amount of reserved restoration bandwidth. defines the amount of reserved restoration bandwidth.
- Recovery time: In general, the more pre-planning of the - Recovery time: In general, the more pre-planning of the
restoration route, the more rapid the P&R scheme. Protection restoration route, the more rapid the P&R scheme. Protection
schemes generally recover faster than restoration schemes. schemes generally recover faster than restoration schemes.
Restoration with pre-signaled bandwidth reservation are likely to Restoration with pre-signaled bandwidth reservation are likely to
be (significantly) faster than path restoration with re- be (significantly) faster than path restoration with re-
provisioning, especially because of the elimination of any provisioning, especially because of the elimination of any
crankback. Local restoration will generally be faster than end-to- crankback. Local restoration will generally be faster than end-to-
end schemes. end schemes.
Recovery time objectives for SONET/SDH protection switching (not Recovery time objectives for SONET/SDH protection switching (not
including time to detect failure) are specified in [G.841] at 50 including time to detect failure) are specified in [ITUT-G.841] at
ms, taking into account constraints on distance, number of 50 ms, taking into account constraints on distance, number of
connections involved, and in the case of ring enhanced protection, connections involved, and in the case of ring enhanced protection,
number of nodes in the ring. number of nodes in the ring.
Recovery time objectives for restoration mechanisms are being Recovery time objectives for restoration mechanisms are being
defined through a separate effort [RFC3386]. defined through a separate effort [RFC3386].
- Resource Sharing: 1+1 and 1:N link and LSP protection require - Resource Sharing: 1+1 and 1:N link and LSP protection require
dedicated recovery paths with limited ability to share resources: dedicated recovery paths with limited ability to share resources:
1+1 allows no sharing, 1:N allows some sharing of protection 1+1 allows no sharing, 1:N allows some sharing of protection
resources and support of extra (preemptable) traffic. Flexibility resources and support of extra (preemptable) traffic. Flexibility
skipping to change at line 2590 skipping to change at line 2580
the restoration pool. In restoration schemes with re-provisioning, the restoration pool. In restoration schemes with re-provisioning,
a pool of restoration capacity can be defined from which all a pool of restoration capacity can be defined from which all
restoration routes are selected after failure. Thus, the degree of restoration routes are selected after failure. Thus, the degree of
sharing is defined by the amount of available restoration sharing is defined by the amount of available restoration
capacity. In restoration with pre-signaled bandwidth reservation, capacity. In restoration with pre-signaled bandwidth reservation,
the amount of reserved restoration capacity is determined by the the amount of reserved restoration capacity is determined by the
local bandwidth reservation policies. In all restoration schemes, local bandwidth reservation policies. In all restoration schemes,
pre-emptable resources can use spare restoration capacity when pre-emptable resources can use spare restoration capacity when
that capacity is not being used for failure recovery. that capacity is not being used for failure recovery.
E. Mannie (Editor) et. al. - Expires August 2003 47
14. Network Management 14. Network Management
Service Providers (SPs) use network management extensively to Service Providers (SPs) use network management extensively to
configure, monitor or provision various devices in their network. It configure, monitor or provision various devices in their network. It
is important to note that a SP's equipment may be distributed across is important to note that a SP's equipment may be distributed across
geographically separate sites thus making distributed management geographically separate sites thus making distributed management
even more important. The service provider should utilize an NMS even more important. The service provider should utilize an NMS
system and standard management protocols such as SNMP (see system and standard management protocols such as SNMP (see
[RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as [RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as
standard interfaces to configure, monitor and provision devices at standard interfaces to configure, monitor and provision devices at
various locations. The service provider may also wish to use the various locations. The service provider may also wish to use the
command line interface (CLI) provided by vendors with their devices. command line interface (CLI) provided by vendors with their devices.
However, this is not a standard or recommended solution because However, this is not a standard or recommended solution because
there is no standard CLI language or interface, which results in N there is no standard CLI language or interface, which results in N
E. Mannie (Editor) et al. Standard Track 47
different CLIs in a network with devices from N different vendors. different CLIs in a network with devices from N different vendors.
In the context of GMPLS, it is extremely important for standard In the context of GMPLS, it is extremely important for standard
interfaces to the SP's devices (e.g. SNMP) to exist due to the interfaces to the SP's devices (e.g. SNMP) to exist due to the
nature of the technology itself. Since GMPLS comprises many nature of the technology itself. Since GMPLS comprises many
different layers of control-plane and data-plane technology, it is different layers of control-plane and data-plane technology, it is
important for management interfaces in this area to be flexible important for management interfaces in this area to be flexible
enough to allow the manager to manage GMPLS easily, and in a enough to allow the manager to manage GMPLS easily, and in a
standard way. standard way.
14.1. Network Management Systems (NMS) 14.1. Network Management Systems (NMS)
skipping to change at line 2646 skipping to change at line 2636
ubiquitously to provision, configure and monitor devices in non- ubiquitously to provision, configure and monitor devices in non-
heterogeneous networks or across SP's network boundaries. heterogeneous networks or across SP's network boundaries.
14.2. Management Information Base (MIB) 14.2. Management Information Base (MIB)
In the context of GMPLS, it is extremely important for standard In the context of GMPLS, it is extremely important for standard
interfaces to devices to exist due to the nature of the technology interfaces to devices to exist due to the nature of the technology
itself. Since GMPLS comprises many different layers of control-plane itself. Since GMPLS comprises many different layers of control-plane
technology, it is important for SNMP MIB modules in this area to be technology, it is important for SNMP MIB modules in this area to be
flexible enough to allow the manager to manage the entire control flexible enough to allow the manager to manage the entire control
E. Mannie (Editor) et. al. - Expires August 2003 48
plane. This should be done using MIB modules that may cooperate plane. This should be done using MIB modules that may cooperate
(i.e. coordinated row-creation on the agent) or through more (i.e. coordinated row-creation on the agent) or through more
generalized MIB modules that aggregate some of the desired actions generalized MIB modules that aggregate some of the desired actions
to be taken and push those details down to the devices. It is to be taken and push those details down to the devices. It is
important to note that in certain circumstances, it may be necessary important to note that in certain circumstances, it may be necessary
to duplicate some small subset of manageable objects in new MIB to duplicate some small subset of manageable objects in new MIB
modules for management convenience. Control of some parts of GMPLS modules for management convenience. Control of some parts of GMPLS
may also be achieved using existing MIB interfaces (i.e. existing may also be achieved using existing MIB interfaces (i.e. existing
SONET MIB) or using separate ones, which are yet to be defined. MIB SONET MIB) or using separate ones, which are yet to be defined. MIB
modules may have been previously defined in the IETF or ITU. Current modules may have been previously defined in the IETF or ITU. Current
MIB modules may need to be extended to facilitate some of the new MIB modules may need to be extended to facilitate some of the new
functionality desired by GMPLS. In these cases, the working group functionality desired by GMPLS. In these cases, the working group
should work on new versions of these MIB modules so that these should work on new versions of these MIB modules so that these
extensions can be added. extensions can be added.
E. Mannie (Editor) et al. Standard Track 48
14.3. Tools 14.3. Tools
As in traditional networks, standard tools such as traceroute As in traditional networks, standard tools such as traceroute
[RFC1393] and ping [RFC2151] are needed for debugging and [RFC1393] and ping [RFC2151] are needed for debugging and
performance monitoring of GMPLS networks, and mainly for the control performance monitoring of GMPLS networks, and mainly for the control
plane topology, that will mimic the data plane topology. plane topology, that will mimic the data plane topology.
Furthermore, such tools provide network reachability information. Furthermore, such tools provide network reachability information.
The GMPLS control protocols will need to expose certain pieces of The GMPLS control protocols will need to expose certain pieces of
information in order for these tools to function properly and to information in order for these tools to function properly and to
provide information germane to GMPLS. These tools should be made provide information germane to GMPLS. These tools should be made
skipping to change at line 2702 skipping to change at line 2692
That is, if 1000 interfaces at layer B are stacked above a single 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 interface below it at layer A, and the interface at A goes down, the
interfaces at layer B should not emit notifications. Instead, the interfaces at layer B should not emit notifications. Instead, the
interface at layer A should emit a single notification. The NMS interface at layer A should emit a single notification. The NMS
receiving this notification should be able to correlate the fact receiving this notification should be able to correlate the fact
that this interface has many others stacked above it and take that this interface has many others stacked above it and take
appropriate action, if necessary. appropriate action, if necessary.
Devices that support GMPLS should provide mechanisms for Devices that support GMPLS should provide mechanisms for
aggregating, summarizing, enabling and disabling of inter-layer aggregating, summarizing, enabling and disabling of inter-layer
E. Mannie (Editor) et. al. - Expires August 2003 49
notifications for the reasons described above. In the context of notifications for the reasons described above. In the context of
SNMP MIB modules, all MIB modules that are used by GMPLS must SNMP MIB modules, all MIB modules that are used by GMPLS must
provide enable/disable objects for all notification objects. provide enable/disable objects for all notification objects.
Furthermore, these MIBs must also provide notification summarization Furthermore, these MIBs must also provide notification summarization
objects or functionality (as described above) as well. NMS systems objects or functionality (as described above) as well. NMS systems
and standard tools which process notifications or keep track of the and standard tools which process notifications or keep track of the
many layers on any given devices must be capable of processing the many layers on any given devices must be capable of processing the
vast amount of information which may potentially be emitted by vast amount of information which may potentially be emitted by
network devices running GMPLS at any point in time. network devices running GMPLS at any point in time.
15. Security Considerations 15. Security Considerations
GMPLS defines a control plane architecture for multiple types of GMPLS defines a control plane architecture for multiple types of
network elements. In general, since LSPs established using GMPLS are network elements. In general, since LSPs established using GMPLS are
E. Mannie (Editor) et al. Standard Track 49
expected to carry high volumes of data and consume significant expected to carry high volumes of data and consume significant
network resources, security mechanisms are required to safeguard the network resources, security mechanisms are required to safeguard the
underlying network against attacks on the control plane and/or underlying network against attacks on the control plane and/or
unauthorized usage of data transport resources. unauthorized usage of data transport resources.
Security requirements depend on the level of trust between nodes Security requirements depend on the level of trust between nodes
that exchange GMPLS control messages as well as the exposure of the that exchange GMPLS control messages as well as the exposure of the
control channel to third parties. In general, a network node may control channel to third parties. In general, a network node may
apply more relaxed security requirements when exchanging GMPLS apply more relaxed security requirements when exchanging GMPLS
control messages with nodes under the same administrative domain control messages with nodes under the same administrative domain
skipping to change at line 2755 skipping to change at line 2745
Note however that GMPLS itself introduces no new security Note however that GMPLS itself introduces no new security
considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP),
routing protocols (OSPF-TE, IS-IS-TE) or network management routing protocols (OSPF-TE, IS-IS-TE) or network management
protocols (SNMP). protocols (SNMP).
16. Acknowledgements 16. Acknowledgements
This draft is the work of numerous authors and consists of a This draft is the work of numerous authors and consists of a
composition of a number of previous drafts in this area. composition of a number of previous drafts in this area.
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SDH/SONET Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH
discussions we had together. Thanks also to Pedro Falcao, Alexandre discussions we had together. Thanks also to Pedro Falcao, Alexandre
Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from
Ebone for their SONET/SDH and optical technical advice and support.
E. Mannie (Editor) et. al. - Expires August 2003 50
Ebone for their SDH/SONET and optical technical advice and support.
Finally, many thanks also to Krishna Mitra (Consultant), Curtis Finally, many thanks also to Krishna Mitra (Consultant), Curtis
Villamizar (Avici), Ron Bonica (WorldCom) and Bert Wijnen (Lucent) Villamizar (Avici), Ron Bonica (WorldCom) and Bert Wijnen (Lucent)
for its revision effort of Section 14. for its revision effort of Section 14.
A list of the drafts from which material and ideas were incorporated
follows:
[GMPLS-SIG] draft-ietf-mpls-generalized-signaling-07.txt
"Generalized MPLS - Signaling Functional
Description"
[RSVP-TE-GMPLS] draft-ietf-mpls-generalized-rsvp-te-06.txt
"Generalized MPLS Signaling - RSVP-TE Extensions"
[CR-LDP-GMPLS] draft-ietf-mpls-generalized-cr-ldp-05.txt
"Generalized MPLS Signaling - CR-LDP Extensions"
[SONETSDH-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-03.txt
"GMPLS Extensions for SONET and SDH Control"
[SONETSDH-EXT-GMPLS] draft-ietf-ccamp-gmpls-sonet-sdh-extensions-
01.txt. "GMPLS Extensions to Control Non-Standard
SONET and SDH Features"
[G709-GMPLS] draft-ietf-ccamp-gmpls-g709-01.txt
"GMPLS Signaling Extensions for G.709 Optical
Transport Networks Control"
[LDP-FT] draft-ietf-mpls-ldp-ft-02.txt
"Fault Tolerance for LDP and CR-LDP"
[LMP] draft-ietf-mpls-lmp-02.txt
"Link Management Protocol (LMP)"
[LMP-WDM] draft-ietf-ccamp-lmp-wdm-00.txt
"LMP for WDM Optical Line Systems (LMP-WDM)"
[HIERARCHY] draft-ietf-mpls-lsp-hierarchy-04.txt
"LSP Hierarchy with MPLS TE"
[RSVP-TE-UNNUM] draft-ietf-mpls-rsvp-unnum-04.txt
"Signalling Unnumbered Links in RSVP-TE"
[CR-LDP-UNNUM] draft-ietf-mpls-crldp-unnum-04.txt
"Signalling Unnumbered Links in CR-LDP"
[BUNDLE] draft-ietf-mpls-bundle-01.txt
"Link Bundling in MPLS Traffic Engineering"
[GMPLS-ROUTING] draft-ietf-ccamp-gmpls-routing-02.txt
"Routing Extensions in Support of Generalized MPLS"
[OSPF-TE-GMPLS] draft-ietf-ccamp-ospf-gmpls-extensions-04.txt
E. Mannie (Editor) et. al. - Expires August 2003 51
"OSPF Extensions in Support of Generalized MPLS"
[ISIS-TE-GMPLS] draft-ietf-isis-gmpls-extensions-08.txt
"IS-IS Extensions in Support of Generalized MPLS"
[FUNCT] draft-ietf-ccamp-gmpls-recovery-functional-00.txt
"Generalized MPLS Recovery Functional Specification"
17. Intellectual Property Considerations 17. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026]. This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
E. Mannie (Editor) et al. Standard Track 50
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
18. References 18. References
18.1 Normative References 18.1 Normative References
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates,
Formats" ANSI T1.105, 2000. And Formats," ANSI T1.105, 2000.
[G.841] ITU-T Recommendation G.841, "Types and Characteristics [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
of SDH Network Protection Architectures," October 1998. in MPLS Traffic Engineering," Work in Progress.
[CR-LDP] B.Jamoussi (Editor) et al., "Constraint-Based LSP
Setup using LDP," IETF RFC 3212, January 2002.
[CR-LDP-GMPLS] P.Ashwood-Smith and L.Berger (Editors) et al.,
"Generalized MPLS Signaling - CR-LDP Extensions,"
IETF RFC 3472, January 2003.
[CR-LDP-UNNUM] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
Unnumbered Links in CR-LDP," Work in Progress.
[GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al.,
"Generalized MPLS Recovery Functional
Specification," Work in Progress.
[GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling
Extensions for G.709 Optical Transport Networks
Control," Work in progress.
[GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
Overlay Model," Work in Progress.
[GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS," Work in
Progress.
[GMPLS-SIG] L.Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," IETF RFC 3471,
January 2003.
E. Mannie (Editor) et al. Standard Track 51
[GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
"Generalized MPLS Extensions for SONET and SDH
Control," Work in progress.
[HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with
Generalized MPLS TE," Work in Progress.
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841,
October 1998.
[LDP-FT] A.Farrel (Editor) et al., "Fault Tolerance for the
Label Distribution Protocol (LDP)," IETF RFC 3479,
February 2003.
[LMP] J.P.Lang (Editor) et al., "Link Management Protocol
(LMP)," Work in progress.
[LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for
WDM Optical Line Systems (LMP-WDM)," Work in
progress.
[OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
in Support of Generalized MPLS," Work in Progress.
[OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic
Engineering Extensions to OSPF", Work in Progress.
[RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF RFC [RFC1393] G. Malkin, "Traceroute Using an IP Option", IETF RFC
1393, January 1993. 1393, January 1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision [RFC2026] S. Bradner, "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996. 3," BCP 9, IETF RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, IETF RFC 2119, March 1997. Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
[RFC2151] G. Kessler and S. Shepard, "A Primer On Internet and [RFC2151] G. Kessler and S. Shepard, "A Primer On Internet and
TCP/IP Tools and Utilities", IETF RFC 2151, June 1997. TCP/IP Tools and Utilities", IETF RFC 2151, June 1997.
E. Mannie (Editor) et. al. - Expires August 2003 52
[RFC2328] J. Moy, "OSPF Version 2", IETF RFC 2328, April 1998.
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option", IETF RFC 2370,
July 1998.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP
MD5 Signature Option", IETF RFC 2385, August 1998. MD5 Signature Option," IETF RFC 2385, August 1998.
[RFC2402] S. Kent and R. Atkinson, "IP Authentication Header," [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF
IETF RFC 2402, November 1998. RFC 2402, November 1998.
[RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security [RFC2406] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", IETF RFC 2406, November 1998. Payload (ESP)", IETF RFC 2406, November 1998.
[RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange [RFC2409] D. Harkins and D. Carrel, "The Internet Key Exchange
(IKE)", IETF RFC 2409, November 1998. (IKE)", IETF RFC 2409, November 1998.
E. Mannie (Editor) et al. Standard Track 52
[RFC2747] F. Baker et al., "RSVP Cryptographic Authentication," [RFC2747] F. Baker et al., "RSVP Cryptographic Authentication,"
IETF RFC 2747, January 2000. IETF RFC 2747, January 2000.
[RFC2863] K. McCloghrie and F. Kastenholz, "The Interfaces Group
MIB," IETF RFC 2863, June 2000.
[RFC2925] K. White, "Definitions of Managed Objects for Remote [RFC2925] K. White, "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", IETF RFC Ping, Traceroute, and Lookup Operations," IETF RFC
2925, September 2000. 2925, September 2000.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", IETF RFC 3031, January Label Switching Architecture," IETF RFC 3031, January
2001. 2001.
[RFC3032] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D.
Farinacci, T. Li, and A. Conta, "MPLS Label Stack
Encoding," IETF RFC 3032, January 2001.
[RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and
B. Thomas, "LDP Specification", IETF RFC 3036, January B.Thomas, "LDP Specification," IETF RFC 3036, January
2001. 2001.
[RFC3411] D. Harrington, R. Presuhn and B. Wijnen, "An [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture
Architecture for Describing Simple Network Management for Describing Simple Network Management Protocol
Protocol (SNMP) Management Frameworks," IETF RFC 3411, (SNMP) Management Frameworks," IETF RFC 3411, December
December 2002. 2002.
[RFC3414] U. Blumenthal and B. Wijnen, "User-based Security Model [RFC3414] U. Blumenthal and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)," IETF RFC 3414, December 2002. Protocol (SNMPv3)," IETF RFC 3414, December 2002.
[RFC3415] B. Wijnen, R. Presuhn, and K. McCloghrie, "View-based [RFC3415] B. Wijnen, R. Presuhn, and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)," IETF RFC 3415, December Management Protocol (SNMP)," IETF RFC 3415, December
2002. 2002.
E. Mannie (Editor) et. al. - Expires August 2003 53
[RFC3416] R. Presuhn (Editor), "Version 2 of the Protocol [RFC3416] R. Presuhn (Editor), "Version 2 of the Protocol
Operations for the Simple Network Management Protocol Operations for the Simple Network Management Protocol
(SNMP)," IETF RFC 3416, December 2002. (SNMP)," IETF RFC 3416, December 2002.
[RFC3417] R. Presuhn (Editor), "Transport Mappings for the Simple [RFC3417] R. Presuhn (Editor), "Transport Mappings for the Simple
Network Management Protocol (SNMP)," IETF RFC 3417, Network Management Protocol (SNMP)," IETF RFC 3417,
December 2002. December 2002.
[OSPF-TE] D. Katz, D. Yeung, and K. Kompella, "Traffic [RSVP-TE] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for
Engineering Extensions to OSPF", draft-katz-yeung-ospf- LSP Tunnels," IETF RFC 3209, December 2001.
traffic-09.txt, October 2002.
[RSVP-TE-GMPLS] L.Berger (Editor) et al., "Generalized MPLS
Signaling - RSVP-TE Extensions," IETF RFC 3473,
January 2003.
[RSVP-TE-UNNUM] K.Kompella and Y.Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)," IETF RFC 3477, January 2003.
18.2 Informative References 18.2 Informative References
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic
Evolution of Transport Network Survivability," IEEE Engineering," Work in Progress.
Communications, August 1999.
[MPLS-TEO] D. Awduche et al., "Multi-Protocol Lambda Switching: [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS
Combining MPLS Traffic Engineering Control With Optical
Crossconnects," Internet Draft, Work in Progress,
draft-awduche-mpls-te-optical-03.txt, April 2001.
[OLI-REQ] A. Fredette (Editor), "Optical Link Interface E. Mannie (Editor) et al. Standard Track 53
Requirements", Internet Draft, Work in Progress, draft- Extensions in Support of Generalized MPLS," Work in
ietf-ccamp-oli-reqts-00.txt, February 2002. Progress.
[RFC1901] K. McCloghrie, M. Rose, and S. Waldbusser, [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution
"Introduction to Community-based SNMPv2", IETF RFC of Transport Network Survivability," IEEE
1901, January 1996. Communications, August 1999.
[RFC3386] W. Lai, D. McDysan, J. Boyle, et al., "Network [OLI-REQ] A.Fredette (Editor), "Optical Link Interface
Hierarchy and Multi-layer Survivability", IETF RFC Requirements," Work in Progress.
3386, November 2002.
[RFC3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy
and Multi-layer Survivability," IETF RFC 3386, November
2002.
[RFC3410] J. Case, R. Mundy, D. Partain, and B. Stewart, [RFC3410] J. Case, R. Mundy, D. Partain, and B. Stewart,
"Introduction and Applicability Statements for "Introduction and Applicability Statements for
Internet-Standard Management Framework," IETF RFC 3410, Internet-Standard Management Framework," IETF RFC 3410,
December 2002. December 2002.
[RFC3469] V. Sharma and F. Hellstrand (Editors), "Framework for [RFC3469] V. Sharma and F. Hellstrand (Editors), "Framework for
Multi-Protocol Label Switching (MPLS)-based Recovery," Multi-Protocol Label Switching (MPLS)-based Recovery,"
IETF RFC 3469, February 2003. IETF RFC 3469, February 2003.
[SDH/SONET-GMPLS-FRAMEWORK] G. Bernstein, E. Mannie and V. Sharma, [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma,
"Framework for GMPLS-based Control of SDH/SONET "Framework for GMPLS-based Control of SDH/SONET
Networks", Internet Draft, Work in Progress, draft- Networks," Work in Progress.
ietf-ccamp-sdhsonet-control-02.txt, February 2003.
E. Mannie (Editor) et. al. - Expires August 2003 54
19. Author's Address 19. Author's Address
Eric Mannie (Consult) Eric Mannie (Consult)
Phone: +32 2 658-5023 Phone: +32 2 658-5023
Mobile: +32 (0)495-221775 Mobile: +32 (0)495-221775
Email: eric_mannie@hotmail.com Email: eric_mannie@hotmail.com
20. Contributors 20. Contributors
Peter Ashwood-Smith (Nortel) Eric Mannie (Consult) Peter Ashwood-Smith (Nortel) Eric Mannie (Consult)
P.O. Box 3511 Station C, Phone: +32 2 648-5023 P.O. Box 3511 Station C, Phone: +32 2 648-5023
Ottawa, ON K1Y 4H7, Canada Mobile: +32 (0)495-221775 Ottawa, ON K1Y 4H7, Canada Mobile: +32 (0)495-221775
Email: petera@nortelnetworks.com Email: eric_mannie@hotmail.com Email: petera@nortelnetworks.com Email: eric_mannie@hotmail.com
Daniel O. Awduche Thomas D. Nadeau (Cisco) Daniel O. Awduche (Consult) Thomas D. Nadeau (Cisco)
Email: awduche@awduche.com 250 Apollo Drive Email: awduche@awduche.com 250 Apollo Drive
Chelmsford, MA 01824, USA Chelmsford, MA 01824, USA
Email: tnadeau@cisco.com Email: tnadeau@cisco.com
Ayan Banerjee (Calient) Lyndon Ong (Ciena) Ayan Banerjee (Calient) Lyndon Ong (Ciena)
5853 Rue Ferrari 10480 Ridgeview Ct 5853 Rue Ferrari 10480 Ridgeview Ct
San Jose, CA 95138, USA Cupertino, CA 95014, USA San Jose, CA 95138, USA Cupertino, CA 95014, USA
Email: abanerjee@calient.net Email: lyong@ciena.com Email: abanerjee@calient.net Email: lyong@ciena.com
E. Mannie (Editor) et al. Standard Track 54
Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel) Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel)
70 Abele Road, Bldg.1200 Francis Wellesplein, 1 70 Abele Road, Bldg.1200 Francis Wellesplein, 1
Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium
Email: dbasak@accelight.com Email: Email: dbasak@accelight.com Email:
dimitri.papadimitriou@alcatel.be dimitri.papadimitriou@alcatel.be
Lou Berger (Movaz) Dimitrios Pendarakis (Tellium) Lou Berger (Movaz) Dimitrios Pendarakis (Tellium)
7926 Jones Branch Drive 2 Crescent Place, P.O. Box 901 7926 Jones Branch Drive 2 Crescent Place, P.O. Box 901
MCLean VA, 22102, USA Oceanport, NJ 07757-0901, USA MCLean VA, 22102, USA Oceanport, NJ 07757-0901, USA
Email: lberger@movaz.com Email: dpendarakis@tellium.com Email: lberger@movaz.com Email: dpendarakis@tellium.com
Greg Bernstein Bala Rajagopalan (Tellium) Greg Bernstein Bala Rajagopalan (Tellium)
(Grotto Networking) 2 Crescent Place, P.O. Box 901 (Grotto Networking) 2 Crescent Place, P.O. Box 901
Email: greg@ciena.com Oceanport, NJ 07757-0901, USA Email: Oceanport, NJ 07757-0901, USA
Email: braja@tellium.com gregb@grotto-networking.com Email: braja@tellium.com
Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper) Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper)
Email: sudheer@ieee.org 1194 N. Mathilda Ave. Email: sudheer@ieee.org 1194 N. Mathilda Ave.
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
Email: yakov@juniper.net Email: yakov@juniper.net
John Drake (Calient) Debanjan Saha (Tellium) John Drake (Calient) Debanjan Saha
5853 Rue Ferrari 2 Crescent Place 5853 Rue Ferrari IBM Watson Research Center
San Jose, CA 95138, USA Oceanport, NJ 07757-0901, USA San Jose, CA 95138, USA Email: dsaha@us.ibm.com
Email: jdrake@calient.net Email: dsaha@tellium.com Email: jdrake@calient.net
E. Mannie (Editor) et. al. - Expires August 2003 55 Yanhe Fan (Axiowave) Hal Sandick
Yanhe Fan (Axiowave) Hal Sandick (Nortel) 200 Nickerson Road Shepard M.S.
200 Nickerson Road Email: hsandick@nortelnetworks.com Marlborough, MA 01752, USA 2401 Dakota Street
Marlborough, MA 01752, USA Email: yfan@axiowave.com Durham, NC 27705, USA
Email: yfan@axiowave.com Email: sandick@nc.rr.com
Don Fedyk (Nortel) Vishal Sharma (Metanoia) Don Fedyk (Nortel) Vishal Sharma (Metanoia)
600 Technology Park Drive 1600 Villa Street, Unit 352 600 Technology Park Drive 1600 Villa Street, Unit 352
Billerica, MA 01821, USA Mountain View, CA 94041, USA Billerica, MA 01821, USA Mountain View, CA 94041, USA
Email: Email: v.sharma@ieee.org Email: Email: v.sharma@ieee.org
dwfedyk@nortelnetworks.com dwfedyk@nortelnetworks.com
Gert Grammel (Alcatel) George Swallow (Cisco) Gert Grammel (Alcatel) George Swallow (Cisco)
Lorenzstrasse, 10 250 Apollo Drive Lorenzstrasse, 10 250 Apollo Drive
70435 Stuttgart, Germany Chelmsford, MA 01824, USA 70435 Stuttgart, Germany Chelmsford, MA 01824, USA
skipping to change at line 3054 skipping to change at line 3034
Dan Guo (Turin) Z. Bo Tang (Tellium) Dan Guo (Turin) Z. Bo Tang (Tellium)
1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901 1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901
CA 95454, USA Oceanport, NJ 07757-0901, USA CA 95454, USA Oceanport, NJ 07757-0901, USA
Email: dguo@turinnetworks.com Email: btang@tellium.com Email: dguo@turinnetworks.com Email: btang@tellium.com
Kireeti Kompella (Juniper) Jennifer Yates (AT&T) Kireeti Kompella (Juniper) Jennifer Yates (AT&T)
1194 N. Mathilda Ave. 180 Park Avenue 1194 N. Mathilda Ave. 180 Park Avenue
Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA
Email: kireeti@juniper.net Email: jyates@research.att.com Email: kireeti@juniper.net Email: jyates@research.att.com
E. Mannie (Editor) et al. Standard Track 55
Alan Kullberg (NetPlane) George R. Young (Edgeflow) Alan Kullberg (NetPlane) George R. Young (Edgeflow)
888 Washington 329 March Road 888 Washington 329 March Road
St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada
Email: akullber@netplane.com Email: george.young@edgeflow.com Email: akullber@netplane.com Email: george.young@edgeflow.com
Jonathan P. Lang John Yu (Zaffire) Jonathan P. Lang John Yu (Hammerhead Systems)
(Rincon Networks) 2630 Orchard Parkway (Rincon Networks) 640 Clyde Court
Email: jplang@ieee.org San Jose, CA 95134, USA Email: jplang@ieee.org Mountain View, CA 94043, USA
Email: jzyu@zaffire.com Email: john@hammerheadsystems.com
Fong Liaw (Zaffire) Alex Zinin (Alcatel) Fong Liaw (Solas Research) Alex Zinin (Alcatel)
2630 Orchard Parkway 1420 North McDowell Ave Solas Research, LLC 1420 North McDowell Ave
San Jose, CA 95134, USA Petaluma, CA 94954, USA Email: fongliaw@yahoo.com Petaluma, CA 94954, USA
Email: fliaw@zaffire.com Email: alex.zinin@alcatel.com Email: alex.zinin@alcatel.com
E. Mannie (Editor) et. al. - Expires August 2003 56 E. Mannie (Editor) et al. Standard Track 56
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 3098 skipping to change at line 3079
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
E. Mannie (Editor) et. al. - Expires August 2003 57 E. Mannie (Editor) et al. Standard Track 57
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/