draft-ietf-ccamp-gmpls-architecture-06.txt   draft-ietf-ccamp-gmpls-architecture-07.txt 
Network Working Group Eric Mannie - Editor Network Working Group Eric Mannie - Editor
Internet Draft Internet Draft
Category: Standard Track Category: Standard Track
Expiration date: October 2003 April 2003 Expiration date: November 2003 May 2003
Generalized Multi-Protocol Label Switching Architecture Generalized Multi-Protocol Label Switching Architecture
draft-ietf-ccamp-gmpls-architecture-06.txt draft-ietf-ccamp-gmpls-architecture-07.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. 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.
skipping to change at line 87 skipping to change at line 87
6.4. Unnumbered Bundled Link .................................... 17 6.4. Unnumbered Bundled Link .................................... 17
6.5. Forming Bundled Links ...................................... 17 6.5. Forming Bundled Links ...................................... 17
7. Relationship with the UNI .................................... 18 7. Relationship with the UNI .................................... 18
7.1. Relationship with the OIF UNI .............................. 18 7.1. Relationship with the OIF UNI .............................. 18
7.2. Reachability across the UNI ................................ 19 7.2. Reachability across the UNI ................................ 19
8. Link Management .............................................. 19 8. Link Management .............................................. 19
8.1. Control Channel and Control Channel Management ............. 20 8.1. Control Channel and Control Channel Management ............. 20
8.2. Link Property Correlation .................................. 21 8.2. Link Property Correlation .................................. 21
8.3. Link Connectivity Verification ............................. 21 8.3. Link Connectivity Verification ............................. 21
8.4. Fault Management ........................................... 22 8.4. Fault Management ........................................... 22
8.5 LMP for DWDM Optical Line Systems (OLSs) .................... 22 8.5. LMP for DWDM Optical Line Systems (OLSs) ................... 23
9. Generalized Signaling ........................................ 24 9. Generalized Signaling ........................................ 24
9.1. Overview: How to Request an LSP ............................ 25 9.1. Overview: How to Request an LSP ............................ 25
9.2. Generalized Label Request .................................. 26 9.2. Generalized Label Request .................................. 26
9.3. SONET/SDH Traffic Parameters ............................... 27 9.3. SONET/SDH Traffic Parameters ............................... 27
9.4. G.709 Traffic Parameters ................................... 28 9.4. G.709 Traffic Parameters ................................... 28
9.5. Bandwidth Encoding ......................................... 29 9.5. Bandwidth Encoding ......................................... 29
9.6. Generalized Label .......................................... 29 9.6. Generalized Label .......................................... 29
9.7. Waveband Switching ......................................... 30 9.7. Waveband Switching ......................................... 30
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 ............................. 33
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 ........................................... 35 9.15. Route Recording ........................................... 35
9.16. LSP Modification and LSP Re-routing ....................... 35 9.16. LSP Modification and LSP Re-routing ....................... 35
9.17. LSP Administrative Status Handling ........................ 36 9.17. LSP Administrative Status Handling ........................ 36
9.18. Control Channel Separation ................................ 36
E. Mannie (Editor) et al. Standard Track 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 ......................................... 39
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
skipping to change at line 137 skipping to change at line 137
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 ..................................... 50
16. Acknowledgements ............................................ 51 16. Acknowledgements ............................................ 51
17. Intellectual Property Considerations ........................ 51 17. Intellectual Property Considerations ........................ 51
18. References .................................................. 51 18. References .................................................. 51
18.1 Normative References ....................................... 51 18.1 Normative References ....................................... 51
18.2 Information References ..................................... 54 18.2 Information References ..................................... 54
19. Author's Address ............................................ 55 19. Author's Address ............................................ 55
20. Contributors ................................................ 55 20. Contributors ................................................ 55
Full Copyright Statement ........................................ 57 Full Copyright Statement ........................................ 58
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 [RFC2119]. 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 described 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 Multi-Protocol Label This document is a generalization of the Multi-Protocol Label
Switching (MPLS) architecture [RFC3031], and in some cases may Switching (MPLS) architecture [RFC3031], and in some cases may
differ slightly from that architecture since non packet-based
E. Mannie (Editor) et al. Standard Track 3 E. Mannie (Editor) et al. Standard Track 3
differ slightly from that architecture since non packet-based
forwarding planes are now considered. It is not the intention of forwarding planes are now considered. It is not the intention of
this document to describe concepts already described in the current this document to describe concepts already described in the current
MPLS architecture. The goal is to describe specific concepts of MPLS architecture. The goal is to describe specific concepts of
Generalized MPLS (GMPLS). 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 document 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
AS Autonomous System AS Autonomous System
BGP Border Gateway Protocol BGP Border Gateway Protocol
skipping to change at line 218 skipping to change at line 218
STS(-N) Synchronous Transport Signal-Level N (SONET) STS(-N) Synchronous Transport Signal-Level N (SONET)
TDM Time Division Multiplexing 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
base functions of traditional MPLS and, in some cases, to add
E. Mannie (Editor) et al. Standard Track 4 E. Mannie (Editor) et al. Standard Track 4
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
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
skipping to change at line 340 skipping to change at line 340
E. Mannie (Editor) et al. Standard Track 6 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
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 [RFC2702]. This, because most of the
can be used below the PSC level requires some traffic engineering. technologies that can be used below the PSC level requires some
The placement of LSPs at these levels needs in general to consider traffic engineering. The placement of LSPs at these levels needs in
several constraints (such as framing, bandwidth, protection general to consider several constraints (such as framing, bandwidth,
capability, etc) and to bypass the legacy Shortest-Path First (SPF) protection capability, etc) and to bypass the legacy Shortest-Path
algorithm. Note, however, that this is not mandatory and that in First (SPF) algorithm. Note, however, that this is not mandatory and
some cases SPF routing can be applied. that in some cases SPF routing can be applied.
In order to facilitate constrained-based SPF routing of LSPs, nodes In order to facilitate constrained-based SPF routing of LSPs, nodes
that perform LSP establishment need more information about the links that perform LSP establishment need more information about the links
in the network than standard intra-domain routing protocols provide. in the network than standard intra-domain routing protocols provide.
These TE attributes are distributed using the transport mechanisms These TE attributes are distributed using the transport mechanisms
already available in IGPs (e.g. flooding) and taken into already available in IGPs (e.g. flooding) and taken into
consideration by the LSP routing algorithm. Optimization of the LSP consideration by the LSP routing algorithm. Optimization of the LSP
routes may also require some external simulations using heuristics routes may also require some external simulations using heuristics
that serve as input for the actual path calculation and LSP that serve as input for the actual path calculation and LSP
establishment process. establishment process.
By definition, a TE link is a representation in the ISIS/OSPF Link By definition, a TE link is a representation in the IS-IS/OSPF Link
State advertisements and in the link state database of certain State advertisements and in the link state database of certain
physical resources, and their properties, between two GMPLS nodes. physical resources, and their properties, between two GMPLS nodes.
TE Links are used by the GMPLS control plane (routing and signaling) TE Links are used by the GMPLS control plane (routing and signaling)
for establishing LSPs. for establishing LSPs.
Extensions to traditional routing protocols and algorithms are Extensions to traditional routing protocols and algorithms are
needed to uniformly encode and carry TE link information, and needed to uniformly encode and carry TE link information, and
explicit routes (e.g. source routes) are required in the signaling. explicit routes (e.g. source routes) are required in the signaling.
In addition, the signaling must now be capable of transporting the In addition, the signaling must now be capable of transporting the
required circuit (LSP) parameters such as the bandwidth, the type of required circuit (LSP) parameters such as the bandwidth, the type of
signal, the desired protection and/or restoration, the position in a signal, the desired protection and/or restoration, the position in a
particular multiplex, etc. Most of these extensions have already particular multiplex, etc. Most of these extensions have already
been defined for PSC and L2SC traffic engineering with MPLS. GMPLS been defined for PSC and L2SC traffic engineering with MPLS. GMPLS
primarily defines additional extensions for TDM, LSC, and FSC primarily defines additional extensions for TDM, LSC, and FSC
traffic engineering. A very few elements are technology specific. traffic engineering. A very few elements are technology specific.
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 [RFC3209] and CR-LDP [RFC3212]. However,
which one of these two signaling protocols must be used. It is the GMPLS does not specify which one of these two signaling protocols
role of manufacturers and operators to evaluate the two possible must be used. It is the role of manufacturers and operators to
solutions for their own interest. evaluate the two possible solutions for their own interest.
Since GMPLS is based on RSVP-TE and CR-LDP, it mandates a Since GMPLS signalling 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 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
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 [OSPF-TE]
TE. However, if explicit (source) routing is used, the routing and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is
algorithms used by these protocols no longer need to be used, the routing algorithms used by these protocols no longer need
standardized. Extensions for inter-domain routing (e.g. BGP) are for to be standardized. Extensions for inter-domain routing (e.g. BGP)
further study. are for further study.
The use of technologies like DWDM (Dense Wavelength Division The use of technologies like DWDM (Dense Wavelength Division
Multiplexing) implies that we can now have a very large number of Multiplexing) implies that we can now have a very large number of
parallel links between two directly adjacent nodes (hundreds of parallel links between two directly adjacent nodes (hundreds of
wavelengths, or even thousands of wavelengths if multiple fibers are wavelengths, or even thousands of wavelengths if multiple fibers are
used). Such a large number of links was not originally considered used). Such a large number of links was not originally considered
for an IP or MPLS control plane, although it could be done. Some for an IP or MPLS control plane, although it could be done. Some
slight adaptations of that control plane are thus required if we slight adaptations of that control plane are thus required if we
want to better reuse it in the GMPLS context. want to better reuse it in the GMPLS context.
skipping to change at line 677 skipping to change at line 677
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
objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF
or ISIS adjacencies are established "control channels". or IS-IS adjacencies are established "control channels".
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 IS-IS-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 [RSVP-TE-UNNUM] and CR-LDP [CR-LDP- requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. The
UNNUM]. The MPLS-TE signaling doesn't provide support for MPLS-TE signaling doesn't provide support for unnumbered links,
unnumbered links, because it doesn't provide a way to indicate an because it doesn't provide a way to indicate an unnumbered link in
unnumbered link in its Explicit Route Object/TLV and in its Record its Explicit Route Object/TLV and in its Record Route Object
Route Object (there is no such TLV for CR-LDP). GMPLS defines (there is no such TLV for CR-LDP). GMPLS defines simple extensions
simple extensions to indicate an unnumbered link in these two to indicate an unnumbered link in these two Objects/TLVs, using a
Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub- new Unnumbered Interface ID sub-object/sub-TLV.
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-TE/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-TE-GMPLS], [OSPF-TE-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 does LSR B. From A's perspective an identifier for that link. So does LSR B. From A's perspective
we refer to the identifier that A assigned to the link as the we refer to the identifier that A assigned to the link as the
"link 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
skipping to change at line 729 skipping to change at line 728
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 link local identifier with respect of the unnumbered link and the link local identifier with respect
to that upstream LSR. to that upstream LSR.
The new Unnumbered Interface ID sub-object for the RR Object The new Unnumbered Interface ID sub-object for the RR Object
contains the link local identifier with respect to the LSR that contains the link local identifier with respect to the LSR 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 IS-IS-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
unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an
unnumbered component link of a bundled link, the LSR must allocate unnumbered component link of a bundled link, the LSR must allocate
an Interface ID to that FA. If the LSP is bi-directional, the tail an Interface ID to that FA. If the LSP is bi-directional, the tail
end does the same and allocates an Interface ID to the reverse FA. end does the same and allocates an Interface ID to the reverse FA.
skipping to change at line 805 skipping to change at line 804
6.2. Routing Considerations for Bundling 6.2. Routing Considerations for Bundling
A bundled link is just another kind of TE link such as those defined A bundled link is just another kind of TE link such as those defined
by [GMPLS-ROUTING]. The liveness of the bundled link is determined by [GMPLS-ROUTING]. The liveness of the bundled link is determined
by the liveness of each its component links. A bundled link is alive by the liveness of each its component links. A bundled link is alive
when at least one of its component links is alive. The liveness of a when at least one of its component links is alive. The liveness of a
component link can be determined by any of several means: IS-IS or component link can be determined by any of several means: IS-IS or
OSPF hellos over the component link, or RSVP Hello (hop local), or OSPF hellos over the component link, or RSVP Hello (hop local), or
LMP hellos (link local), or from layer 1 or layer 2 indications. LMP hellos (link local), or from layer 1 or layer 2 indications.
Note that (according to the RSVP-TE Tunnel specification) the RSVP Note that (according to the RSVP-TE specification [RFC3209]) the
Hello mechanism is intended to be used when notification of link RSVP Hello mechanism is intended to be used when notification of
layer failures is not available and unnumbered links are not used, link layer failures is not available and unnumbered links are not
or when the failure detection mechanisms provided by the link layer used, or when the failure detection mechanisms provided by the link
are not sufficient for timely node failure detection. layer are not sufficient for timely node failure detection.
Once a bundled link is determined to be alive, it can be advertised Once a bundled link is determined to be alive, it can be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links. restricted to just one of the component links.
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
skipping to change at line 841 skipping to change at line 840
unreserved bandwidth and the maximum reservable bandwidth. Bandwidth unreserved bandwidth and the maximum reservable bandwidth. Bandwidth
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 Object/TLV) will choose the bundled link to be used for the
LSP, but not the component link(s). This because information about LSP, but not the component link(s). This because information about
the bundled link is flooded but information about the component the bundled link is flooded but information about the component
links is not. links is not.
The choice of the component link to use is always made by an The choice of the component link to use is always made by an
upstream node. If the LSP is bi-directional, the upstream node upstream node. If the LSP is bi-directional, the upstream node
chooses a component link in each direction. chooses a component link in each direction.
Three mechanisms for indicating this choice to the downstream node Three mechanisms for indicating this choice to the downstream node
are possible. are possible.
skipping to change at line 870 skipping to change at line 869
signaling channel can be in-band or out-of-band. In this last case, signaling channel can be in-band or out-of-band. In this last case,
the association between the signaling channel and that component the association between the signaling channel and that component
link need to be explicitly configured. link need to be explicitly configured.
6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID 6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID
This mechanism requires that the component link has a unique remote This mechanism requires that the component link has a unique remote
IP address. The upstream node indicates the choice of the component IP address. The upstream node indicates the choice of the component
link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying
either an IPv4 or an IPv6 address in the Path/Label Request message either an IPv4 or an IPv6 address in the Path/Label Request message
(see [RSVP-TE-GMPLS]/[CR-LDP-GMPLS], respectively). For a bi- (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a
directional LSP, a component link is provided for each direction by 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
E. Mannie (Editor) et al. Standard Track 16
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]. (see [RFC3473]/[RFC3472], respectively).
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-TE/CR-LDP (especially in the case where
component link is a Forwarding Adjacency), or by means of IS-IS or a component link is a Forwarding Adjacency), or by means of IS-IS or
OSPF extensions. OSPF extensions.
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.4. Unnumbered Bundled Link 6.4. Unnumbered Bundled Link
A bundled link may itself be numbered or unnumbered independent of A bundled link may itself be numbered or unnumbered independent of
whether the component links are numbered or not. This affects how whether the component links are numbered or not. This affects how
skipping to change at line 934 skipping to change at line 933
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
E. Mannie (Editor) et al. Standard Track 17
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.
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
skipping to change at line 988 skipping to change at line 988
GMPLS. The current OIF UNI specification [OIF-UNI] defines an GMPLS. The current OIF UNI specification [OIF-UNI] defines an
interface between a client SONET/SDH equipment and an SONET/SDH 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.
E. Mannie (Editor) et al. Standard Track 18
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.
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.
skipping to change at line 1044 skipping to change at line 1043
- 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
E. Mannie (Editor) et al. Standard Track 19
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.
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) [LMP] has been defined to fulfill these operations. LMP has
initiated in the context of GMPLS but is a generic toolbox that can been initiated in the context of GMPLS but is a generic toolbox that
be also used in other contexts. can be also used in other contexts.
In GMPLS, the control channels between two adjacent nodes are no In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data links longer required to use the same physical medium as the data links
between those nodes. Moreover, the control channels that are used to between those nodes. Moreover, the control channels that are used to
exchange the GMPLS control-plane information exist independently of exchange the GMPLS control-plane information exist independently of
the links they manage. Hence, LMP was designed to manage the data the links they manage. Hence, LMP was designed to manage the data
links, independently of the termination capabilities of those data links, independently of the termination capabilities of those data
links. links.
Control channel management and link property correlation procedures Control channel management and link property correlation procedures
skipping to change at line 1100 skipping to change at line 1099
channel is left unspecified. The control channel(s) between two channel is left unspecified. The control channel(s) between two
adjacent nodes is no longer required to use the same physical medium adjacent nodes is no longer required to use the same physical medium
as the data-bearing links between those nodes. For example, a as the data-bearing links between those nodes. For example, a
control channel could use a separate wavelength or fiber, an control channel could use a separate wavelength or fiber, an
Ethernet link, or an IP tunnel through a separate management Ethernet link, or an IP tunnel through a separate management
network. network.
A consequence of allowing the control channel(s) between two nodes A consequence of allowing the control channel(s) between two nodes
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
E. Mannie (Editor) et al. Standard Track 20
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.
E. Mannie (Editor) et al. Standard Track 20
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
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
skipping to change at line 1149 skipping to change at line 1147
8.2. Link Property Correlation 8.2. Link Property Correlation
As part of LMP, a link property correlation exchange is defined. As part of LMP, a link property correlation exchange is defined.
The exchange is used to aggregate multiple data-bearing links (i.e. The exchange is used to aggregate multiple data-bearing links (i.e.
component links) into a bundled link and exchange, correlate, or component links) into a bundled link and exchange, correlate, or
change TE link parameters. The link property correlation exchange change TE link parameters. The link property correlation exchange
may be done at any time a link is up and not in the Verification may be done at any time a link is up and not in the Verification
process (see next section). process (see next section).
It allows for instance to add component links to a link bundle, It allows for instance to add component links to a link bundle,
change a link's protection mechanism, change port identifiers, or change link's minimum/maximum reservable bandwidth, change port
change component identifiers in a bundle. This mechanism is identifiers, or change component identifiers in a bundle. This
supported by an exchange of link summary messages. mechanism is supported by an exchange of link summary messages.
8.3. Link Connectivity Verification 8.3. Link Connectivity Verification
E. Mannie (Editor) et al. Standard Track 21
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 E. Mannie (Editor) et al. Standard Track 21
exchange that take place during the negotiation phase of the Hello This procedure should be performed initially when a data-bearing
protocol. This procedure should be done initially when a data- link is first established, and subsequently, on a periodic basis for
bearing link is first established, and subsequently, on a periodic 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.
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 data-bearing link, and that Hello messages
exchanged over the control channel during the link verification continue to be exchanged over the control channel during the link
process. Data-bearing links are tested in the transmit direction as verification process. Data-bearing links are tested in the transmit
they are unidirectional. As such, it is possible for LMP neighboring direction as they are unidirectional. As such, it is possible for
nodes to exchange the Test messages simultaneously in both LMP neighboring nodes to exchange the Test messages simultaneously
directions. in both 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
over a particular data-bearing link, or over the component links of over a particular data-bearing link, or over the component links of
a particular bundled link. The node must also indicate the number of a particular bundled link. The node must also indicate the number of
data-bearing links that are to be verified; the interval at which data-bearing links that are to be verified; the interval at which
the test messages will be sent; the encoding scheme, the transport the test messages will be sent; the encoding scheme, the transport
mechanisms that are supported, the data rate for Test messages; and, mechanisms that are supported, the data rate for Test messages; and,
in the case where the data-bearing links correspond to fibers, the in the case where the data-bearing links correspond to fibers, the
wavelength over which the Test messages will be transmitted. wavelength over which the Test messages will be transmitted.
skipping to change at line 1210 skipping to change at line 1206
be notified in order to take some actions (fault notification). be notified in order to take some actions (fault notification).
Note that fault localization can also be used to support some Note that fault localization can also be used to support some
specific (local) protection/restoration mechanisms. specific (local) protection/restoration mechanisms.
In new technologies such as transparent photonic switching currently In new technologies such as transparent photonic switching currently
no method is defined to locate a fault, and the mechanism by which no method is defined to locate a fault, and the mechanism by which
the fault information is propagated must be sent "out of band" (via the fault information is propagated must be sent "out of band" (via
the control plane). the control plane).
E. Mannie (Editor) et al. Standard Track 22
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).
E. Mannie (Editor) et al. Standard Track 22
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
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)
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 an OXC
and an OLS. These extensions are intended to satisfy the Optical and an OLS. These extensions are intended to satisfy the Optical
Link Interface Requirements described in [OLI-REQ]. Link Interface Requirements described in [OLI-REQ].
Fault detection is particularly an issue when the network is using Fault detection is particularly an issue when the network is using
all-optical photonic switches (PXC). Once a connection is all-optical photonic switches (PXC). Once a connection is
established, PXCs have only limited visibility into the health of established, PXCs have only limited visibility into the health of
the connection. Although the PXC is all-optical, long-haul OLSs the connection. Although the PXC is all-optical, long-haul OLSs
typically terminate channels electrically and regenerate them typically terminate channels electrically and regenerate them
optically. This provides an opportunity to monitor the health of a optically. This provides an opportunity to monitor the health of a
channel between PXCs. LMP-WDM can then be used by the OLS to provide 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-SIG]), can be used to suppress spurious alarms. For signaling [RFC3471]), 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
E. Mannie (Editor) et al. Standard Track 23
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.
E. Mannie (Editor) et al. Standard Track 23
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
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
the transparency/opaqueness of the data links). To maintain the transparency/opaqueness of the data links). To maintain
skipping to change at line 1299 skipping to change at line 1294
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
changes and additions impact basic LSP properties: how labels are changes and additions impact basic LSP properties: how labels are
requested and communicated, the unidirectional nature of LSPs, how requested and communicated, the unidirectional nature of LSPs, how
errors are propagated, and information provided for synchronizing errors are propagated, and information provided for synchronizing
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 [RFC3471].
2. RSVP-TE extensions [RSVP-TE-GMPLS]. 2. RSVP-TE extensions [RFC3473].
3. CR-LDP extensions [CR-LDP-GMPLS]. 3. CR-LDP extensions [RFC3472].
In addition, independent parts are available per technology: In addition, independent parts are available per technology:
1. GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH]. 1. GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH].
2. GMPLS extensions for G.709 control [GMPLS-G709]. 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.
- Explicit routing (typical), or hop-by-hop routing. - Explicit routing (typical), or hop-by-hop routing.
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:
E. Mannie (Editor) et al. Standard Track 24
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.
E. Mannie (Editor) et al. Standard Track 24
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
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.
skipping to change at line 1353 skipping to change at line 1349
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, 11 and 12 are should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are
optional. optional.
A typical SONET/SDH switching network would implement building A typical SONET/SDH switching network would implement building
blocks: 1, 2 (the SONET/SDH 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 protection can be achieved using SONET/
achieved using SONET/SDH overhead bytes. 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 1376 skipping to change at line 1372
signal MPLS-IP as well. In that case, the MPLS-IP network can signal MPLS-IP as well. In that case, the MPLS-IP network can
benefit from the link protection type (not available in CR-LDP, some benefit from the link protection type (not available in CR-LDP, some
very basic form being available in RSVP-TE). Building block 2 is very basic form being available in RSVP-TE). Building block 2 is
here a regular MPLS label and no new label format is required. here a regular MPLS label and no new label format is required.
GMPLS does not specify any profile for RSVP-TE and CR-LDP GMPLS does not specify any profile for RSVP-TE and CR-LDP
implementations that have to support GMPLS - except for what is implementations that have to support GMPLS - except for what is
directly related to GMPLS procedures. It is to the manufacturer to directly related to GMPLS procedures. It is to the manufacturer to
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
E. Mannie (Editor) et al. Standard Track 25
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
E. Mannie (Editor) et al. Standard Track 25
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
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
skipping to change at line 1432 skipping to change at line 1427
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 [GMPLS-SONET-SDH]). concatenated signal (given an order specified in [GMPLS-SONET-SDH]).
In case of SONET/SDH "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
E. Mannie (Editor) et al. Standard Track 26
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.
E. Mannie (Editor) et al. Standard Track 26
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
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
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
skipping to change at line 1482 skipping to change at line 1477
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 SONET/SDH traffic parameters [GMPLS-SONET-SDH] 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). G.707].
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,
E. Mannie (Editor) et al. Standard Track 27
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.
E. Mannie (Editor) et al. Standard Track 27
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:
- 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.
skipping to change at line 1530 skipping to change at line 1524
explained in [GMPLS-SONET-SDH]. 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 SONET/SDH and GMPLS can be found Note that a general discussion on SONET/SDH and GMPLS can be found
in [SONET-SDH-GMPLS-FRM]. 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
layers: an optical layer (i.e. made of wavelengths) and a digital major layers: an optical layer (i.e. made of wavelengths) and a
layer. These two layers are divided into sub-layers and switching digital layer. These two layers are divided into sub-layers and
occurs at two specific sub-layers: at the OCh (Optical Channel) switching occurs at two specific sub-layers: at the OCh (Optical
optical layer and at the ODU (Optical channel Data Unit) electrical Channel) optical layer and at the ODU (Optical channel Data Unit)
layer. The ODUk notation is used to denote ODUs at different electrical layer. The ODUk notation is used to denote ODUs at
bandwidths. different bandwidths.
The GMPLS G.709 traffic parameters [GMPLS-G709] 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
E. Mannie (Editor) et al. Standard Track 28
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.
E. Mannie (Editor) et al. Standard Track 28
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:
- 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.
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 G.709 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 G.709 traffic parameters are simply carried in a new
new TLV. TLV.
9.5. Bandwidth Encoding 9.5. Bandwidth Encoding
Some technologies that do not have (yet) specific traffic parameters Some technologies that do not have (yet) specific traffic parameters
just require a bandwidth encoding transported in a generic form. just require a bandwidth encoding transported in a generic form.
Bandwidth is carried in 32-bit number in IEEE floating-point format Bandwidth is carried in 32-bit number in IEEE floating-point format
(the unit is bytes per second). Values are carried in a per protocol (the unit is bytes per second). Values are carried in a per protocol
specific manner. For non-packet LSPs, it is useful to define specific manner. For non-packet LSPs, it is useful to define
discrete values to identify the bandwidth of the LSP. discrete values to identify the bandwidth of the LSP.
skipping to change at line 1599 skipping to change at line 1592
the Peak and Committed Data Rate fields of the CR-LDP Traffic the Peak and Committed Data Rate fields of the CR-LDP Traffic
Parameters TLV. Parameters TLV.
9.6. Generalized Label 9.6. Generalized Label
The Generalized Label extends the traditional MPLS label by allowing The Generalized Label extends the traditional MPLS label by allowing
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.
E. Mannie (Editor) et al. Standard Track 29
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,
E. Mannie (Editor) et al. Standard Track 29
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 SONET/SDH or a G.709 label or can be more elaborated such as an SONET/SDH or a G.709
label. label.
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
skipping to change at line 1655 skipping to change at line 1649
In the context of waveband switching, the generalized label used to In the context of waveband switching, the generalized label used to
indicate a waveband contains three fields, a waveband ID, a Start indicate a waveband contains three fields, a waveband ID, a Start
Label and an End Label. The Start and End Labels are channel Label and an End Label. The Start and End Labels are channel
identifiers from the sender perspective that identify respectively, identifiers from the sender perspective that identify respectively,
the lowest value wavelength and the highest value wavelength making the lowest value wavelength and the highest value wavelength making
up the waveband. up the waveband.
9.8. Label Suggestion by the Upstream 9.8. Label Suggestion by the Upstream
E. Mannie (Editor) et al. Standard Track 30
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
E. Mannie (Editor) et al. Standard Track 30
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
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.
skipping to change at line 1709 skipping to change at line 1704
9.10. Bi-directional LSP 9.10. Bi-directional LSP
GMPLS allows establishment of bi-directional symmetric LSPs (not of GMPLS allows establishment of bi-directional symmetric LSPs (not of
asymmetric LSPs). A symmetric bi-directional LSP has the same asymmetric LSPs). A symmetric bi-directional LSP has the same
traffic engineering requirements including fate sharing, protection traffic engineering requirements including fate sharing, protection
and restoration, LSRs, and resource requirements (e.g. latency and and restoration, LSRs, and resource requirements (e.g. latency and
jitter) in each direction. jitter) in each direction.
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
E. Mannie (Editor) et al. Standard Track 31
"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 E. Mannie (Editor) et al. Standard Track 31
[CR-LDP] two unidirectional paths must be independently established. Normally to establish a bi-directional LSP when using RSVP-TE
This approach has the following disadvantages: [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be
independently established. This approach has the following
disadvantages:
1. The latency to establish the bi-directional LSP is equal to one 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
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
skipping to change at line 1764 skipping to change at line 1759
directional LSP setup is indicated by the presence of an Upstream directional LSP setup is indicated by the presence of an Upstream
Label in the appropriate signaling message. Label in the appropriate signaling message.
9.11. Bi-directional LSP Contention Resolution 9.11. Bi-directional LSP Contention Resolution
Contention for labels may occur between two bi-directional LSP setup Contention for labels may occur between two bi-directional LSP setup
requests traveling in opposite directions. This contention occurs requests traveling in opposite directions. This contention occurs
when both sides allocate the same resources (ports) at effectively when both sides allocate the same resources (ports) at effectively
the same time. GMPLS signaling defines a procedure to resolve that the same time. GMPLS signaling defines a procedure to resolve that
contention: the node with the higher node ID will win the contention: the node with the higher node ID will win the
E. Mannie (Editor) et al. Standard Track 32
contention. To reduce the probability of contention, some mechanisms contention. To reduce the probability of contention, some mechanisms
are also suggested. are also suggested.
E. Mannie (Editor) et al. Standard Track 32
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.
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.
skipping to change at line 1802 skipping to change at line 1797
expedited event notification with a Notify message. Such extensions expedited event notification with a Notify message. Such extensions
can be used by fast restoration mechanisms. Notifications may be can be used by fast restoration mechanisms. Notifications may be
requested in both the upstream and downstream directions. requested in both the upstream and downstream directions.
The Notify message is a generalized notification mechanism that The Notify message is a generalized notification mechanism that
differs from the currently defined error messages in that it can be differs from the currently defined error messages in that it can be
"targeted" to a node other than the immediate upstream or downstream "targeted" to a node other than the immediate upstream or downstream
neighbor. The Notify message does not replace existing error neighbor. The Notify message does not replace existing error
messages. The Notify message may be sent either (a) normally, where messages. The Notify message may be sent either (a) normally, where
non-target nodes just forward the Notify message to the target node, non-target nodes just forward the Notify message to the target node,
similar to ResvConf processing in [RSVP]; or (b) encapsulated in a similar to ResvConf processing in [RFC2205]; or (b) encapsulated in
new IP header whose destination is equal to the target IP address. a new IP header whose destination is equal to the target IP address.
3. Faster removal of intermediate states: 3. Faster removal of intermediate states:
A specific RSVP optimization allowing in some cases the faster A specific RSVP optimization allowing in some cases the faster
removal of intermediate states. This extension is used to deal with removal of intermediate states. This extension is used to deal with
specific RSVP mechanisms. specific RSVP mechanisms.
9.13. Link Protection 9.13. Link Protection
Protection information is carried in the new optional Protection Protection information is carried in the new optional Protection
Information Object/TLV. It currently indicates the desired link Information Object/TLV. It currently indicates the desired link
protection for each link of an LSP. If a particular protection type, protection for each link of an LSP. If a particular protection type,
i.e. 1+1, or 1:N, is requested, then a connection request is i.e. 1+1, or 1:N, is requested, then a connection request is
processed only if the desired protection type can be honored. Note processed only if the desired protection type can be honored. Note
that GMPLS advertises the protection capabilities of a link in the that GMPLS advertises the protection capabilities of a link in the
E. Mannie (Editor) et al. Standard Track 33
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.
E. Mannie (Editor) et al. Standard Track 33
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.
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 [RFC3471] section 7.1 for a precise
precise definition of each. definition of each.
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
skipping to change at line 1875 skipping to change at line 1869
This explicit route was extended to include interface numbers as This explicit route was extended to include interface numbers as
abstract nodes to support unnumbered interfaces; and further abstract nodes to support unnumbered interfaces; and further
extended by GMPLS to include labels as abstract nodes. Having labels extended by GMPLS to include labels as abstract nodes. Having labels
in an explicit route is an important feature that allows controlling in an explicit route is an important feature that allows controlling
the placement of an LSP with a very fine granularity. This is more the placement of an LSP with a very fine granularity. This is more
likely to be used for TDM, LSC and FSC links. likely to be used for TDM, LSC and FSC links.
In particular, the explicit label control in the explicit route In particular, the explicit label control in the explicit route
allows terminating an LSP on a particular outgoing port of an egress allows terminating an LSP on a particular outgoing port of an egress
node. Indeed, a label sub-object/TLV must follow a sub-object/TLV node. Indeed, a label sub-object/TLV must follow a sub-object/TLV
E. Mannie (Editor) et al. Standard Track 34
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.
E. Mannie (Editor) et al. Standard Track 34
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 SONET/SDH 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
skipping to change at line 1931 skipping to change at line 1924
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 SONET/SDH circuit characteristics such as the changing some SONET/SDH circuit characteristics such as the
E. Mannie (Editor) et al. Standard Track 35
bandwidth, the protection type, the transparency, the concatenation, bandwidth, the protection type, the transparency, the concatenation,
etc. etc.
E. Mannie (Editor) et al. Standard Track 35
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.
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
skipping to change at line 1970 skipping to change at line 1963
to set the administrative status of an LSP to "being deleted" before to set the administrative status of an LSP to "being deleted" before
tearing it down in order to avoid non-useful generation of alarms. tearing it down in order to avoid non-useful generation of alarms.
The ingress LSR precedes an LSP deletion by inserting an appropriate The ingress LSR precedes an LSP deletion by inserting an appropriate
Admin Status Object/TLV in a Path/Label Request (with the Admin Status Object/TLV in a Path/Label Request (with the
modification action indicator flag set to modify) message. Transit modification action indicator flag set to modify) message. Transit
LSRs process the Admin Status Object/TLV and forward it. The egress LSRs process the Admin Status Object/TLV and forward it. The egress
LSR answers in a Resv/Label Mapping (with the modification action LSR answers in a Resv/Label Mapping (with the modification action
indicator flag set to modify) message with the Admin Status object. indicator flag set to modify) message with the Admin Status object.
Upon receiving this message and object, the ingress node sends a Upon receiving this message and object, the ingress node sends a
PathTear/Release message downstream to remove the LSP and normal PathTear/Release message downstream to remove the LSP and normal
RSVP/CR-LDP processing takes place. RSVP-TE/CR-LDP processing takes place.
In the second usage, the Admin Status object/TLV is carried in a In the second usage, the Admin Status object/TLV is carried in a
Notification/Label Mapping (with the modification action indicator Notification/Label Mapping (with the modification action indicator
flag set to modify) message to request that the ingress node change flag set to modify) message to request that the ingress node change
the administrative state of an LSP. This allows intermediate and the administrative state of an LSP. This allows intermediate and
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 the context of link bundling. to MPLS in the context of link bundling.
E. Mannie (Editor) et al. Standard Track 36
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
E. Mannie (Editor) et al. Standard Track 36
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
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.
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 IF_ID
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
message to indicate the downstream node's usage of the indicated message to indicate the downstream node's usage of the indicated
interface(s). interface(s).
skipping to change at line 2040 skipping to change at line 2034
To improve scalability of MPLS TE (and thus GMPLS) it may be useful To improve scalability of MPLS TE (and thus GMPLS) it may be useful
to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate
nodes see the external LSP only. They don't have to maintain nodes see the external LSP only. They don't have to maintain
forwarding states for each internal LSP, less signaling messages forwarding states for each internal LSP, less signaling messages
need to be exchanged and the external LSP can be somehow protected need to be exchanged and the external LSP can be somehow protected
instead (or in addition) to the internal LSPs. This can considerably instead (or in addition) to the internal LSPs. This can considerably
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 IS-IS/OSPF), (c)
allowing other LSRs to use forwarding adjacencies for their path allowing other LSRs to use forwarding adjacencies for their path
E. Mannie (Editor) et al. Standard Track 37
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).
ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs E. Mannie (Editor) et al. Standard Track 37
IS-IS/OSPF floods the information about "Forwarding Adjacencies" FAs
just as it floods the information about any other links. just as it floods the information about any other links.
Consequently to this flooding, an LSR has in its TE link state Consequently to this flooding, an LSR has in its TE link state
database the information about not just conventional links, but FAs database the information about not just conventional links, but FAs
as well. as well.
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.
FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. FAs are advertised as GMPLS TE links such as defined in [HIERARCHY].
GMPLS TE links are advertised in OSPF and ISIS such as defined in GMPLS TE links are advertised in OSPF and IS-IS such as defined in
[OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications
enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link. enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.
When a FA is created dynamically, its TE attributes are inherited When a FA is created dynamically, its TE attributes are inherited
from the FA-LSP that induced its creation. [HIERARCHY] specifies how from the FA-LSP that induced its creation. [HIERARCHY] specifies how
each TE parameter of the FA is inherited from the FA-LSP. Note that each TE parameter of the FA is inherited from the FA-LSP. Note that
the bandwidth of the FA must be at least as big as the FA-LSP that the bandwidth of the FA must be at least as big as the FA-LSP that
induced it, but may be bigger if only discrete bandwidths are induced it, but may be bigger if only discrete bandwidths are
available for the FA-LSP. In general, for dynamically provisioned available for the FA-LSP. In general, for dynamically provisioned
forwarding adjacencies, a policy-based mechanism may be needed to forwarding adjacencies, a policy-based mechanism may be needed to
skipping to change at line 2093 skipping to change at line 2086
It is possible that the underlying path information might change It is possible that the underlying path information might change
over time, via configuration updates, or dynamic route over time, via configuration updates, or dynamic route
modifications, resulting in the change of that TLV. modifications, resulting in the change of that TLV.
If forwarding adjacencies are bundled (via link bundling), and if If forwarding adjacencies are bundled (via link bundling), and if
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 IS-IS/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. Standard Track 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
E. Mannie (Editor) et al. Standard Track 38
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
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
skipping to change at line 2143 skipping to change at line 2136
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.
11. Routing and Signaling Adjacencies 11. Routing and Signaling Adjacencies
By definition, two nodes have a routing (ISIS/OSPF) adjacency if By definition, two nodes have a routing (IS-IS/OSPF) adjacency if
they are neighbors in the ISIS/OSPF sense. they are neighbors in the IS-IS/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. Standard Track 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
E. Mannie (Editor) et al. Standard Track 39
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.
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
skipping to change at line 2181 skipping to change at line 2175
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 frame/ 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/IS-IS 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
PSC. Moreover, this node needs to run either GMPLS or MPLS PSC. Moreover, this node needs to run either GMPLS or MPLS
extensions for TE links with an interface switching capability of extensions for TE links with an interface switching capability of
PSC. PSC.
The mechanisms for Control Channel Separation [GMPLS-SIG] should be The mechanisms for Control Channel Separation [RFC3471] should be
used (even if the IP path between two nodes is a TE link). I.e., used (even if the IP path between two nodes is a TE link). I.e.,
RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object
to specify a particular TE link when establishing an LSP. to specify a particular TE link when establishing an LSP.
The IP path could consist of multiple IP hops. In this case, the The IP path could consist of multiple IP hops. In this case, the
mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used
(in addition to Control Channel Separation). (in addition to Control Channel Separation).
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. Standard Track 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 loses 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.
E. Mannie (Editor) et al. Standard Track 40
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.
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 loses most of For a nodal fault, a node's control plane restarts and loses most of
its state information. In this case, both upstream and downstream its state information. In this case, both upstream and downstream
nodes must synchronize their state information with the restarted nodes must synchronize their state information with the 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
TE-GMPLS], [CR-LDP-GMPLS], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that
that these cases only apply when there are mechanisms to detect data these cases only apply when there are mechanisms to detect data
channel failures independent of control channel failures. channel failures independent of control channel failures.
The LDP Fault tolerance (see [LDP-FT]) specifies the procedures to The LDP Fault tolerance (see [RFC3479]) specifies the procedures to
recover from a control channel failure. [RSVP-TE-GMPLS] specifies recover from a control channel failure. [RFC3473] specifies how to
how to recover from both a control channel failure and a node 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
this section is clarified hereafter: this section is clarified hereafter:
- This section is only applicable when a fault impacting LSP(s) - This section is only applicable when a fault impacting LSP(s)
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. Standard Track 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).
E. Mannie (Editor) et al. Standard Track 41
- 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.
- 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
skipping to change at line 2318 skipping to change at line 2310
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. Standard Track 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
E. Mannie (Editor) et al. Standard Track 42
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.
Service Level Agreements (SLAs) between network operators and their Service Level Agreements (SLAs) between network operators and their
clients are needed to determine the necessary time scales for P&R at clients are needed to determine the necessary time scales for P&R at
each layer and at each domain. each layer and at each domain.
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
skipping to change at line 2373 skipping to change at line 2366
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. Standard Track 43
+--- Dedicated (1:1, 1+1) +--- Dedicated (1:1, 1+1)
| |
| |
+--- Shared (1:N, Ring, Shared mesh) +--- Shared (1:N, Ring, Shared mesh)
E. Mannie (Editor) et al. Standard Track 43
| |
Level of | Level of |
Overbooking ---+--- Best effort Overbooking ---+--- Best effort
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
skipping to change at line 2427 skipping to change at line 2421
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
[ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be
further 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. Standard Track 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-
E. Mannie (Editor) et al. Standard Track 44
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.
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.
skipping to change at line 2482 skipping to change at line 2477
- 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. Standard Track 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
E. Mannie (Editor) et al. Standard Track 45
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 [GMPLS-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.
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.
skipping to change at line 2537 skipping to change at line 2533
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. Standard Track 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
E. Mannie (Editor) et al. Standard Track 46
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
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.
skipping to change at line 2770 skipping to change at line 2767
appropriate local authorization policies may help in limiting the appropriate local authorization policies may help in limiting the
impact of security breaches in remote parts of a network. impact of security breaches in remote parts of a network.
Finally, it should be noted that GMPLS itself introduces no new Finally, it should be noted that GMPLS itself introduces no new
security considerations to the current MPLS-TE signaling (RSVP-TE, security considerations to the current MPLS-TE signaling (RSVP-TE,
CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management CR-LDP), 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 document 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 SONET/SDH 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. Ebone for their SONET/SDH 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.
skipping to change at line 2815 skipping to change at line 2812
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, Description Including Multiplex Structure, Rates,
And Formats," ANSI T1.105, 2000. And Formats," ANSI T1.105, 2000.
E. Mannie (Editor) et al. Standard Track 51 E. Mannie (Editor) et al. Standard Track 51
[BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling
in MPLS Traffic Engineering," Work in Progress. in MPLS Traffic Engineering," Work in Progress,
draft-ietf-mpls-bundle-04.txt.
[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., [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al.,
"Generalized MPLS Recovery Functional "Generalized MPLS Recovery Functional
Specification," Work in Progress. Specification," Work in Progress, draft-ietf-ccamp-
gmpls-recovery-functional-01.txt.
[GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling
Extensions for G.709 Optical Transport Networks Extensions for G.709 Optical Transport Networks
Control," Work in progress. Control," Work in progress, draft-ietf-ccamp-gmpls-
g709-03.txt.
[GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the
Overlay Model," Work in Progress. Overlay Model," Work in Progress, draft-ietf-ccamp-
gmpls-overlay-01.txt.
[GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing
Extensions in Support of Generalized MPLS," Work in Extensions in Support of Generalized MPLS," Work in
Progress. Progress, draft-ietf-ccamp-gmpls-routing-05.txt.
[GMPLS-SIG] L.Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," IETF RFC 3471,
January 2003.
[GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
"Generalized MPLS Extensions for SONET and SDH "Generalized MPLS Extensions for SONET and SDH
Control," Work in progress. Control," Work in progress, draft-ietf-ccamp-gmpls-
sonet-sdh-08.txt.
[HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with
Generalized MPLS TE," Work in Progress. Generalized MPLS TE," Work in Progress, draft-ietf-
mpls-lsp-hierarchy-08.txt.
[ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy", Recommendation G.707, October
2000.
[ITUT-G.709] ITU-T, "Interface for the Optical Transport Network
(OTN)," Recommendation G.709 version 1.0 (and
Amendment 1), February 2001 (and October 2001).
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network [ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, Protection Architectures," Recommendation G.841,
October 1998. 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] J.P.Lang (Editor) et al., "Link Management Protocol
(LMP)," Work in progress. (LMP)," Work in progress, draft-ietf-ccamp-lmp-
09.txt.
[LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for
WDM Optical Line Systems (LMP-WDM)," Work in WDM Optical Line Systems (LMP-WDM)," Work in
progress. progress, draft-ietf-ccamp-lmp-wdm-02.txt.
E. Mannie (Editor) et al. Standard Track 52
[OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions
in Support of Generalized MPLS," Work in Progress. in Support of Generalized MPLS," Work in Progress,
E. Mannie (Editor) et al. Standard Track 52
draft-ietf-ccamp-ospf-gmpls-extensions-09.txt.
[OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic
Engineering Extensions to OSPF", Work in Progress. Engineering Extensions to OSPF", Work in Progress,
draft-katz-yeung-ospf-traffic-09.txt.
[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, IETF 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.
[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," IETF [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," 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.
[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.
[RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for [RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for
Policy-based Admission Control," IETF RFC 2753, January Policy-based Admission Control," IETF RFC 2753, January
2000. 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.
[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.
[RFC3209] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," IETF RFC 3209, December 2001.
[RFC3212] B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup
using LDP," IETF RFC 3212, January 2002.
E. Mannie (Editor) et al. Standard Track 53
[RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture
for Describing Simple Network Management Protocol for Describing Simple Network Management Protocol
(SNMP) Management Frameworks," IETF RFC 3411, December (SNMP) Management Frameworks," IETF RFC 3411, December
2002. 2002.
E. Mannie (Editor) et al. Standard Track 53
[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.
[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.
[RSVP-TE] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered
LSP Tunnels," IETF RFC 3209, December 2001. Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)," IETF RFC 3477, January 2003.
[RSVP-TE-GMPLS] L.Berger (Editor) et al., "Generalized MPLS [RFC3471] L.Berger (Editor) et al., "Generalized MPLS -
Signaling - RSVP-TE Extensions," IETF RFC 3473, Signaling Functional Description," IETF RFC 3471,
January 2003. January 2003.
[RSVP-TE-UNNUM] K.Kompella and Y.Rekhter, "Signalling Unnumbered [RFC3472] P.Ashwood-Smith and L.Berger (Editors) et al.,
Links in Resource ReSerVation Protocol - Traffic "Generalized MPLS Signaling - CR-LDP Extensions," IETF
Engineering (RSVP-TE)," IETF RFC 3477, January 2003. RFC 3472, January 2003.
[RFC3473] L.Berger (Editor) et al., "Generalized MPLS
Signaling - RSVP-TE Extensions," IETF RFC 3473, January
2003.
[RFC3479] A.Farrel (Editor) et al., "Fault Tolerance for the
Label Distribution Protocol (LDP)," IETF RFC 3479,
February 2003.
[RFC3480] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling
Unnumbered Links in CR-LDP," IETF RFC 3480, February
2003.
18.2 Informative References 18.2 Informative References
[ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic
Engineering," Work in Progress. Engineering," Work in Progress, draft-ietf-isis-
traffic-04.txt.
[ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS
E. Mannie (Editor) et al. Standard Track 54
Extensions in Support of Generalized MPLS," Work in Extensions in Support of Generalized MPLS," Work in
Progress. Progress, draft-ietf-isis-gmpls-extensions-16.txt.
[MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution
of Transport Network Survivability," IEEE of Transport Network Survivability," IEEE
Communications, August 1999. Communications Magazine, August 1999.
[OIF-UNI] The Optical Internetworking Forum, "User Network
Interface (UNI) 1.0 Signaling Specification -
Implementation Agreement OIF-UNI-01.0," October 2001.
[OLI-REQ] A.Fredette (Editor), "Optical Link Interface [OLI-REQ] A.Fredette (Editor), "Optical Link Interface
Requirements," Work in Progress. Requirements," Work in Progress.
[RFC2702] D.Awduche, et al., "Requirements for Traffic
Engineering Over MPLS," IETF RFC 2702, September 1999.
[RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi- [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi-
layer Survivability," IETF RFC 3386, November 2002. 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.
E. Mannie (Editor) et al. Standard Track 54
[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.
[SONET-SDH-GMPLS-FRM] 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," Work in Progress. Networks," Work in Progress.
19. Author's Address 19. Author's Address
skipping to change at line 3004 skipping to change at line 3029
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 (Consult) 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
E. Mannie (Editor) et al. Standard Track 55
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
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
skipping to change at line 3030 skipping to change at line 3056
Greg Bernstein (Grotto) Bala Rajagopalan (Tellium) Greg Bernstein (Grotto) Bala Rajagopalan (Tellium)
Email: 2 Crescent Place, P.O. Box 901 Email: 2 Crescent Place, P.O. Box 901
gregb@grotto-networking.com Oceanport, NJ 07757-0901, USA gregb@grotto-networking.com Oceanport, NJ 07757-0901, USA
Email: braja@tellium.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
E. Mannie (Editor) et al. Standard Track 55 John Drake (Calient) Debanjan Saha
John Drake (Calient) Debanjan Saha (Tellium) 5853 Rue Ferrari (IBM Watson Research Center)
5853 Rue Ferrari 2 Crescent Place San Jose, CA 95138, USA Email: dsaha@us.ibm.com
San Jose, CA 95138, USA Oceanport, NJ 07757-0901, USA Email: jdrake@calient.net
Email: jdrake@calient.net Email: dsaha@tellium.com
Yanhe Fan (Axiowave) Hal Sandick Yanhe Fan (Axiowave) Hal Sandick
200 Nickerson Road Shepard M.S. 200 Nickerson Road Shepard M.S.
Marlborough, MA 01752, USA 2401 Dakota Street Marlborough, MA 01752, USA 2401 Dakota Street
Email: yfan@axiowave.com Durham, NC 27705, USA Email: yfan@axiowave.com Durham, NC 27705, USA
Email: sandick@nc.rr.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
skipping to change at line 3058 skipping to change at line 3083
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
Email: gert.grammel@alcatel.de Email: swallow@cisco.com Email: gert.grammel@alcatel.de Email: swallow@cisco.com
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
E. Mannie (Editor) et al. Standard Track 56
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
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 (Hammerhead Systems) Jonathan P. Lang John Yu (Hammerhead Systems)
(Rincon Networks) 640 Clyde Court (Rincon Networks) 640 Clyde Court
Email: jplang@ieee.org Mountain View, CA 94043, USA Email: jplang@ieee.org Mountain View, CA 94043, USA
Email: john@hammerheadsystems.com Email: john@hammerheadsystems.com
Fong Liaw (Solas Research) Alex Zinin (Alcatel) Fong Liaw (Solas Research) Alex Zinin (Alcatel)
Solas Research, LLC 1420 North McDowell Ave Solas Research, LLC 1420 North McDowell Ave
Email: fongliaw@yahoo.com Petaluma, CA 94954, USA Email: fongliaw@yahoo.com Petaluma, CA 94954, USA
Email: alex.zinin@alcatel.com Email: alex.zinin@alcatel.com
E. Mannie (Editor) et al. Standard Track 56 E. Mannie (Editor) et al. Standard Track 57
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 3107 skipping to change at line 3133
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. Standard Track 57 E. Mannie (Editor) et al. Standard Track 58
 End of changes. 

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