node must generate a notification message with a "Routing
problem/Switching Type" indication.
The LSP payload type (G-PID) identifies the payload carried by the
LSP, i.e., an identifier of the client layer of that LSP. For some
technologies, it also indicates the mapping used by the client layer,
e.g., byte synchronous mapping of E1. This must be interpreted
according to the LSP encoding type and is used by the nodes at the
endpoints of the LSP to know to which client layer a request is
destined, and in some cases by the penultimate hop.
Other technology specific parameters are not transported in the
Generalized Label Request but in technology specific traffic
parameters as explained hereafter. Currently, two set of traffic
parameters are defined, one for SONET/SDH and one for G.709.
Note that it is expected than specific traffic parameters will be
defined in the future for photonic (all optical) switching.
7.3. SONET/SDH Traffic Parameters
The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful
set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707].
The first traffic parameter specifies the type of the elementary
SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6,
VC-4, STS-3c, etc. Several transforms can then be applied
successively on the elementary Signal to build the final signal being
actually requested for the LSP.
These transforms are the contiguous concatenation, the virtual
concatenation, the transparency and the multiplication. Each one is
optional. They must be applied strictly in the following order:
- First, contiguous concatenation can be optionally applied on the
Elementary Signal, resulting in a contiguously concatenated
signal.
- Second, virtual concatenation can be optionally applied either
directly on the elementary Signal, or on the contiguously
concatenated signal obtained from the previous phase.
- Third, some transparency can be optionally specified when
requesting a frame as signal rather than a container. Several
transparency packages are defined.
- Fourth, a multiplication can be optionally applied either directly
on the elementary Signal, or on the contiguously concatenated
signal obtained from the first phase, or on the virtually
concatenated signal obtained from the second phase, or on these
signals combined with some transparency.
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new
SENDER_TSPEC and FLOWSPEC. The same format is used for both. There
is no Adspec associated with the SENDER_TSPEC, it is omitted or a
default value is used. The content of the FLOWSPEC object received
in a Resv message should be identical to the content of the
SENDER_TSPEC of the corresponding Path message. In other words, the
receiver is normally not allowed to change the values of the traffic
parameters. However, some level of negotiation may be achieved as
explained in [RFC3946].
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a
new TLV.
Note that a general discussion on SONET/SDH and GMPLS can be found in
[SONET-SDH-GMPLS-FRM].
7.4. G.709 Traffic Parameters
Simply said, an [ITUT-G.709] based network is decomposed in two major
layers: an optical layer (i.e., made of wavelengths) and a digital
layer. These two layers are divided into sub-layers and switching
occurs at two specific sub-layers: at the OCh (Optical Channel)
optical layer and at the ODU (Optical channel Data Unit) electrical
layer. The ODUk notation is used to denote ODUs at different
bandwidths.
The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful
set of capabilities for ITU-T G.709 networks.
The first traffic parameter specifies the type of the elementary
G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40
Gbps, etc. Several transforms can then be applied successively on
the elementary Signal to build the final signal being actually
requested for the LSP.
These transforms are the virtual concatenation and the
multiplication. Each one of these transforms is optional. They must
be applied strictly in the following order:
- First, virtual concatenation can be optionally applied directly on
the elementary Signal,
- Second, a multiplication can be optionally applied, either
directly on the elementary Signal, or on the virtually
concatenated signal obtained from the first phase.
Additional ODUk Multiplexing traffic parameters allow indicating an
ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request.
G.709 supports the following multiplexing capabilities: ODUj into
ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.
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
is no Adspec associated with the SENDER_TSPEC, it is omitted or a
default value is used. The content of the FLOWSPEC object received
in a Resv message should be identical to the content of the
SENDER_TSPEC of the corresponding Path message.
For CR-LDP, the G.709 traffic parameters are simply carried in a new
TLV.
7.5. Bandwidth Encoding
Some technologies that do not have (yet) specific traffic parameters
just require a bandwidth encoding transported in a generic form.
Bandwidth is carried in 32-bit number in IEEE floating-point format
(the unit is bytes per second). Values are carried in a per protocol
specific manner. For non-packet LSPs, it is useful to define
discrete values to identify the bandwidth of the LSP.
It should be noted that this bandwidth encoding do not apply to
SONET/SDH and G.709, for which the traffic parameters fully define
the requested SONET/SDH or G.709 signal.
The bandwidth is coded in the Peak Data Rate field of Int-Serv
objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in
the Peak and Committed Data Rate fields of the CR-LDP Traffic
Parameters TLV.
7.6. Generalized Label
The Generalized Label extends the traditional MPLS label by allowing
the representation of not only labels that travel in-band with
associated data packets, but also (virtual) labels that identify
time-slots, wavelengths, or space division multiplexed positions.
For example, the Generalized Label may identify (a) a single fiber in
a bundle, (b) a single waveband within fiber, (c) a single wavelength
within a waveband (or fiber), or (d) a set of time-slots within a
wavelength (or fiber). It may also be a generic MPLS label, a Frame
Relay label, or an ATM label (VCI/VPI). The format of a label can be
as simple as an integer value such as a wavelength label or can be
more elaborated such as an SONET/SDH or a G.709 label.
SDH and SONET define each a multiplexing structure. These
multiplexing structures will be used as naming trees to create unique
labels. Such a label will identify the exact position (times-lot(s))
of a signal in a multiplexing structure. Since the SONET
multiplexing structure may be seen as a subset of the SDH
multiplexing structure, the same format of label is used for SDH and
SONET. A similar concept is applied to build a label at the G.709
ODU layer.
Since the nodes sending and receiving the Generalized Label know what
kinds of link they are using, the Generalized Label does not identify
its type. Instead, the nodes are expected to know from the context
what type of label to expect.
A Generalized Label only carries a single level of label i.e., it is
non-hierarchical. When multiple levels of labels (LSPs within LSPs)
are required, each LSP must be established separately.
7.7. Waveband Switching
A special case of wavelength switching is waveband switching. A
waveband represents a set of contiguous wavelengths, which can be
switched together to a new waveband. For optimization reasons, it
may be desirable for a photonic cross-connect to optically switch
multiple wavelengths as a unit. This may reduce the distortion on
the individual wavelengths and may allow tighter separation of the
individual wavelengths. A Waveband label is defined to support this
special case.
Waveband switching naturally introduces another level of label
hierarchy and as such the waveband is treated the same way, all other
upper layer labels are treated. As far as the MPLS protocols are
concerned, there is little difference between a waveband label and a
wavelength label. Exception is that semantically the waveband can be
subdivided into wavelengths whereas the wavelength can only be
subdivided into time or statistically multiplexed labels.
In the context of waveband switching, the generalized label used to
indicate a waveband contains three fields, a waveband ID, a Start
Label and an End Label. The Start and End Labels are channel
identifiers from the sender perspective that identify respectively,
the lowest value wavelength and the highest value wavelength making
up the waveband.
7.8. Label Suggestion by the Upstream
GMPLS allows for a label to be optionally suggested by an upstream
node. This suggestion may be overridden by a downstream node but in
some cases, at the cost of higher LSP setup time. The suggested
label is valuable when establishing LSPs through certain kinds of
optical equipment where there may be a lengthy (in electrical terms)
delay in configuring the switching fabric. For example, micro
mirrors may have to be elevated or moved, and this physical motion
and subsequent damping takes time. If the labels and hence switching
fabric are configured in the reverse direction (the norm), the
Resv/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
important for restoration purposes where alternate LSPs may need to
be rapidly established as a result of network failures.
7.9. Label Restriction by the Upstream
An upstream node can optionally restrict (limit) the choice of label
of a downstream node to a set of acceptable labels. Giving lists
and/or ranges of inclusive (acceptable) or exclusive (unacceptable)
labels in a Label Set provides this restriction. If not applied, all
labels from the valid label range may be used. There are at least
four cases where a label restriction is useful in the "optical"
domain.
Case 1: the end equipment is only capable of transmitting and
receiving on a small specific set of wavelengths/wavebands.
Case 2: there is a sequence of interfaces, which cannot support
wavelength conversion and require the same wavelength be used
end-to-end over a sequence of hops, or even an entire path.
Case 3: it is desirable to limit the amount of wavelength conversion
being performed to reduce the distortion on the optical signals.
Case 4: two ends of a link support different sets of wavelengths.
The receiver of a Label Set must restrict its choice of labels to one
that is in the Label Set. A Label Set may be present across multiple
hops. In this case, each node generates its own outgoing Label Set,
possibly based on the incoming Label Set and the node’s hardware
capabilities. This case is expected to be the norm for nodes with
conversion incapable interfaces.
7.10. Bi-directional LSP
GMPLS allows establishment of bi-directional symmetric LSPs (not of
asymmetric LSPs). A symmetric bi-directional LSP has the same
traffic engineering requirements including fate sharing, protection
and restoration, LSRs, and resource requirements (e.g., latency and
jitter) in each direction.
In the remainder of this section, the term "initiator" is used to
refer to a node that starts the establishment of an LSP; the term
"terminator" is used to refer to the node that is the target of the
LSP. For a bi-directional LSPs, there is only one initiator and one
terminator.
Normally to establish a bi-directional LSP when using RSVP-TE
[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
round trip signaling time plus one initiator-terminator signaling
transit delay. This not only extends the setup latency for
successful LSP establishment, but it extends the worst-case
latency for discovering an unsuccessful LSP to as much as two
times the initiator-terminator transit delay. These delays are
particularly significant for LSPs that are established for
restoration purposes.
2. The control overhead is twice that of a unidirectional LSP. This
is because separate control messages (e.g., Path and Resv) must be
generated for both segments of the bi-directional LSP.
3. Because the resources are established in separate segments, route
selection is complicated. There is also additional potential race
for conditions in assignment of resources, which decreases the
overall probability of successfully establishing the bi-
directional connection.
4. It is more difficult to provide a clean interface for SONET/SDH
equipment that may rely on bi-directional hop-by-hop paths for
protection switching. Note that existing SONET/SDH equipment
transmits the control information in-band with the data.
5. Bi-directional optical LSPs (or lightpaths) are seen as a
requirement for many optical networking service providers.
With bi-directional LSPs both the downstream and upstream data paths,
i.e., from initiator to terminator and terminator to initiator, are
established using a single set of signaling messages. This reduces
the setup latency to essentially one initiator-terminator round trip
time plus processing time, and limits the control overhead to the
same number of messages as a unidirectional LSP.
For bi-directional LSPs, two labels must be allocated. Bi-
directional LSP setup is indicated by the presence of an Upstream
Label in the appropriate signaling message.
7.11. Bi-directional LSP Contention Resolution
Contention for labels may occur between two bi-directional LSP setup
requests traveling in opposite directions. This contention occurs
when both sides allocate the same resources (ports) at effectively
the same time. GMPLS signaling defines a procedure to resolve that
contention: the node with the higher node ID will win the contention.
To reduce the probability of contention, some mechanisms are also
suggested.
7.12. Rapid Notification of Failure
GMPLS defines several signaling extensions that enable expedited
notification of failures and other events to nodes responsible for
restoring failed LSPs, and error handling.
1. Acceptable Label Set for notification on Label Error:
There are cases in traditional MPLS and in GMPLS that result in an
error message containing an "Unacceptable label value" indication.
When these cases occur, it can useful for the node generating the
error message to indicate which labels would be acceptable. To
cover this case, GMPLS introduces the ability to convey such
information via the "Acceptable Label Set". An Acceptable Label
Set is carried in appropriate protocol specific error messages.
The format of an Acceptable Label Set is identical to a Label Set.
2. Expedited notification:
Extensions to RSVP-TE enable expedited notification of failures
and other events to determined nodes. For CR-LDP, there is not
currently a similar mechanism. The first extension identifies
where event notifications are to be sent. The second provides for
general expedited event notification with a Notify message. Such
extensions can be used by fast restoration mechanisms.
Notifications may be requested in both the upstream and downstream
directions.
The Notify message is a generalized notification mechanism that
differs from the currently defined error messages in that it can
be "targeted" to a node other than the immediate upstream or
downstream neighbor. The Notify message does not replace existing
error messages. The Notify message may be sent either (a)
normally, where non-target nodes just forward the Notify message
to the target node, similar to ResvConf processing in [RFC2205];
or (b) encapsulated in a new IP header whose destination is equal
to the target IP address.
3. Faster removal of intermediate states:
A specific RSVP optimization allowing in some cases the faster
removal of intermediate states. This extension is used to deal
with specific RSVP mechanisms.
7.13. Link Protection
Protection information is carried in the new optional Protection
Information Object/TLV. It currently indicates the desired link
protection for each link of an LSP. If a particular protection type,
i.e., 1+1, or 1:N, is requested, then a connection request is
processed only if the desired protection type can be honored. Note
that GMPLS advertises the protection capabilities of a link in the
routing protocols. Path computation algorithms may consider this
information when computing paths for setting up LSPs.
Protection information also indicates if the LSP is a primary or
secondary LSP. A secondary LSP is a backup to a primary LSP. The
resources of a secondary LSP are normally not used until the primary
LSP fails, but they may be used by other LSPs until the primary LSP
fails over the secondary LSP. At that point, any LSP that is using
the resources for the secondary LSP must be preempted.
Six link protection types are currently defined as individual flags
and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared,
unprotected, extra traffic. See [RFC3471] section 7.1 for a precise
definition of each.
7.14. Explicit Routing and Explicit Label Control
By using an explicit route, the path taken by an LSP can be
controlled more or less precisely. Typically, the node at the head-
end of an LSP finds an explicit route and builds an Explicit Route
Object (ERO)/ Explicit Route (ER) TLV that contains that route.
Possibly, the edge node does not build any explicit route, and just
transmit a signaling request to a default neighbor LSR (as IP/MPLS
hosts would). For instance, an explicit route could be added to a
signaling message by the first switching node, on behalf of the edge
node. Note also that an explicit route is altered by intermediate
LSRs during its progression towards the destination.
The explicit route is originally defined by MPLS-TE as a list of
abstract nodes (i.e., groups of nodes) along the explicit route.
Each abstract node can be an IPv4 address prefix, an IPv6 address
prefix, or an AS number. This capability allows the generator of the
explicit route to have incomplete information about the details of
the path. In the simplest case, an abstract node can be a full IP
address (32 bits) that identifies a specific node (called a simple
abstract node).
MPLS-TE allows strict and loose abstract nodes. The path between a
strict node and its preceding node must include only network nodes
from the strict node and its preceding abstract node. The path
between a loose node and its preceding abstract node may include
other network nodes that are not part of the loose node or its
preceding abstract node.
This explicit route was extended to include interface numbers as
abstract nodes to support unnumbered interfaces; and further extended
by GMPLS to include labels as abstract nodes. Having labels in an
explicit route is an important feature that allows controlling the
placement of an LSP with a very fine granularity. This is more
likely to be used for TDM, LSC and FSC links.
In particular, the explicit label control in the explicit route
allows terminating an LSP on a particular outgoing port of an egress
node. Indeed, a label sub-object/TLV must follow a sub-object/TLV
containing the IP address, or the interface identifier (in case of
unnumbered interface), associated with the link on which it is to be
used.
This can also be used when it is desirable to "splice" two LSPs
together, i.e., where the tail of the first LSP would be "spliced"
into the head of the second LSP.
When used together with an optimization algorithm, it can provide
very detailed explicit routes, including the label (timeslot) to use
on a link, in order to minimize the fragmentation of the SONET/SDH
multiplex on the corresponding interface.
7.15. Route Recording
In order to improve the reliability and the manageability of the LSP
being established, the concept of the route recording was introduced
in RSVP-TE to function as:
- First, a loop detection mechanism to discover L3 routing loops, or
loops inherent in the explicit route (this mechanism is strictly
exclusive with the use of explicit routing objects).
- Second, a route recording mechanism collects up-to-date detailed
path information on a hop-by-hop basis during the LSP setup
process. This mechanism provides valuable information to the
source and destination nodes. Any intermediate routing change at
setup time, in case of loose explicit routing, will be reported.
- Third, a recorded route can be used as input for an explicit
route. This is useful if a source node receives the recorded
route from a destination node and applies it as an explicit route
in order to "pin down the path".
Within the GMPLS architecture, only the second and third functions
are mainly applicable for TDM, LSC and FSC layers.
7.16. LSP Modification and LSP Re-routing
LSP modification and re-routing are two features already available in
MPLS-TE. GMPLS does not add anything new. Elegant re-routing is
possible with the concept of "make-before-break" whereby an old path
is still used while a new path is set up by avoiding double
reservation of resources. Then, the node performing the re-routing
can swap on the new path and close the old path. This feature is
supported with RSVP-TE (using shared explicit filters) and CR-LDP
(using the action indicator flag).
LSP modification consists in changing some LSP parameters, but
normally without changing the route. It is supported using the same
mechanism as re-routing. However, the semantic of LSP modification
will differ from one technology to the other. For instance, further
studies are required to understand the impact of dynamically changing
some SONET/SDH circuit characteristics such as the bandwidth, the
protection type, the transparency, the concatenation, etc.
7.17. LSP Administrative Status Handling
GMPLS provides the optional capability to indicate the administrative
status of an LSP by using a new Admin Status object/TLV.
Administrative Status information is currently used in two ways.
In the first usage, the Admin Status object/TLV is carried in a
Path/Label Request or Resv/Label Mapping message to indicate the
administrative state of an LSP. In this usage, Administrative Status
information indicates the state of the LSP, which include "up" or
"down", if it in a "testing" mode, and if deletion is in progress.
Based on that administrative status, a node can take local decisions,
like inhibit alarm reporting when an LSP is in "down" or "testing"
states, or report alarms associated with the connection at a priority
equal to or less than "Non service affecting".
It is possible that some nodes along an LSP will not support the
Admin Status Object/TLV. In the case of a non-supporting transit
node, the object will pass through the node unmodified and normal
processing can continue.
In some circumstances, particularly optical networks, it is useful to
set the administrative status of an LSP to "being deleted" before
tearing it down in order to avoid non-useful generation of alarms.
The ingress LSR precedes an LSP deletion by inserting an appropriate
Admin Status Object/TLV in a Path/Label Request (with the
modification action indicator flag set to modify) message. Transit
LSRs process the Admin Status Object/TLV and forward it. The egress
LSR answers in a Resv/Label Mapping (with the modification action
indicator flag set to modify) message with the Admin Status object.