5. Relationship with the UNI
The interface between an edge GMPLS node and a GMPLS LSR on the
network side may be referred to as a User to Network Interface (UNI),
while the interface between two-network side LSRs may be referred to
as a Network to Network Interface (NNI).
GMPLS does not specify separately a UNI and an NNI. Edge nodes are
connected to LSRs on the network side, and these LSRs are in turn
connected between them. Of course, the behavior of an edge node is
not exactly the same as the behavior of an LSR on the network side.
Note also, that an edge node may run a routing protocol, however it
is expected that in most of the cases it will not (see also section
5.2 and the section about signaling with an explicit route).
Conceptually, a difference between UNI and NNI make sense either if
both interface uses completely different protocols, or if they use
the same protocols but with some outstanding differences. In the
first case, separate protocols are often defined successively, with
more or less success.
The GMPLS approach consisted in building a consistent model from day
one, considering both the UNI and NNI interfaces at the same time
[GMPLS-OVERLAY]. For that purpose, a very few specific UNI
particularities have been ignored in a first time. GMPLS has been
enhanced to support such particularities at the UNI by some other
standardization bodies (see hereafter).
5.1. Relationship with the OIF UNI
This section is only given for reference to the OIF work related to
GMPLS. The current OIF UNI specification [OIF-UNI] defines an
interface between a client SONET/SDH equipment and an SONET/SDH
network, each belonging to a distinct administrative authority. It
is designed for an overlay model. The OIF UNI defines additional
mechanisms on the top of GMPLS for the UNI.
For instance, the OIF service discovery procedure is a precursor to
obtaining UNI services. Service discovery allows a client to
determine the static parameters of the interconnection with the
network, including the UNI signaling protocol, the type of
concatenation, the transparency level as well as the type of
diversity (node, link, SRLG) supported by the network.
Since the current OIF UNI interface does not cover photonic networks,
G.709 Digital Wrapper, etc, it is from that perspective a subset of
the GMPLS Architecture at the UNI.
5.2. Reachability across the UNI
This section discusses the selection of an explicit route by an edge
node. The selection of the first LSR by an edge node connected to
multiple LSRs is part of that problem.
An edge node (host or LSR) can participate more or less deeply in the
GMPLS routing. Four different routing models can be supported at the
UNI: configuration based, partial peering, silent listening and full
peering.
- Configuration based: this routing model requires the manual or
automatic configuration of an edge node with a list of neighbor
LSRs sorted by preference order. Automatic configuration can be
achieved using DHCP for instance. No routing information is
exchanged at the UNI, except maybe the ordered list of LSRs. The
only routing information used by the edge node is that list. The
edge node sends by default an LSP request to the preferred LSR.
ICMP redirects could be send by this LSR to redirect some LSP
requests to another LSR connected to the edge node. GMPLS does
not preclude that model.
- Partial peering: limited routing information (mainly reachability)
can be exchanged across the UNI using some extensions in the
signaling plane. The reachability information exchanged at the
UNI may be used to initiate edge node specific routing decision
over the network. GMPLS does not have any capability to support
this model today.
- Silent listening: the edge node can silently listen to routing
protocols and take routing decisions based on the information
obtained. An edge node receives the full routing information,
including traffic engineering extensions. One LSR should forward
transparently all routing PDUs to the edge node. An edge node can
now compute a complete explicit route taking into consideration
all the end-to-end routing information. GMPLS does not preclude
this model.
- Full peering: in addition to silent listening, the edge node
participates within the routing, establish adjacencies with its
neighbors and advertises LSAs. This is useful only if there are
benefits for edge nodes to advertise themselves traffic
engineering information. GMPLS does not preclude this model.
6. Link Management
In the context of GMPLS, a pair of nodes (e.g., a photonic switch)
may be connected by tens of fibers, and each fiber may be used to
transmit hundreds of wavelengths if DWDM is used. Multiple fibers
and/or multiple wavelengths may also be combined into one or more
bundled links for routing purposes. Furthermore, to enable
communication between nodes for routing, signaling, and link
management, control channels must be established between a node pair.
Link management is a collection of useful procedures between adjacent
nodes that provide local services such as control channel management,
link connectivity verification, link property correlation, and fault
management. The Link Management Protocol (LMP) [LMP] has been
defined to fulfill these operations. LMP has been initiated in the
context of GMPLS but is a generic toolbox that can be also used in
other contexts.
In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data links
between those nodes. Moreover, the control channels that are used to
exchange the GMPLS control-plane information exist independently of
the links they manage. Hence, LMP was designed to manage the data
links, independently of the termination capabilities of those data
links.
Control channel management and link property correlation procedures
are mandatory per LMP. Link connectivity verification and fault
management procedures are optional.
6.1. Control Channel and Control Channel Management
LMP control channel management is used to establish and maintain
control channels between nodes. Control channels exist independently
of TE links, and can be used to exchange MPLS control-plane
information such as signaling, routing, and link management
information.
An "LMP adjacency" is formed between two nodes that support the same
LMP capabilities. Multiple control channels may be active
simultaneously for each adjacency. A control channel can be either
explicitly configured or automatically selected, however, LMP
currently assume that control channels are explicitly configured
while the configuration of the control channel capabilities can be
dynamically negotiated.
For the purposes of LMP, the exact implementation of the control
channel is left unspecified. The control channel(s) between two
adjacent nodes is no longer required to use the same physical medium
as the data-bearing links between those nodes. For example, a
control channel could use a separate wavelength or fiber, an Ethernet
link, or an IP tunnel through a separate management network.
A consequence of allowing the control channel(s) between two nodes to
be physically diverse from the associated data-bearing links is that
the health of a control channel does not necessarily correlate to the
health of the data-bearing links, and vice-versa. Therefore, new
mechanisms have been developed in LMP to manage links, both in terms
of link provisioning and fault isolation.
LMP does not specify the signaling transport mechanism used in the
control channel, however it states that messages transported over a
control channel must be IP encoded. Furthermore, since the messages
are IP encoded, the link level encoding is not part of LMP. A 32-bit
non-zero integer Control Channel Identifier (CCId) is assigned to
each direction of a control channel.
Each control channel individually negotiates its control channel
parameters and maintains connectivity using a fast Hello protocol.
The latter is required if lower-level mechanisms are not available to
detect link failures.
The Hello protocol of LMP is intended to be a lightweight keep-alive
mechanism that will react to control channel failures rapidly so that
IGP Hellos are not lost and the associated link-state adjacencies are
not removed uselessly.
The Hello protocol consists of two phases: a negotiation phase and a
keep-alive phase. The negotiation phase allows negotiation of some
basic Hello protocol parameters, like the Hello frequency. The
keep-alive phase consists of a fast lightweight bi-directional Hello
message exchange.
If a group of control channels share a common node pair and support
the same LMP capabilities, then LMP control channel messages (except
Configuration messages, and Hello’s) may be transmitted over any of
the active control channels without coordination between the local
and remote nodes.
For LMP, it is essential that at least one control channel is always
available. In case of control channel failure, it may be possible to
use an alternate active control channel without coordination.
6.2. Link Property Correlation
As part of LMP, a link property correlation exchange is defined. The
exchange is used to aggregate multiple data-bearing links (i.e.,
component links) into a bundled link and exchange, correlate, or
change TE link parameters. The link property correlation exchange
may be done at any time a link is up and not in the Verification
process (see next section).
It allows, for instance, the addition of component links to a link
bundle, change of a link’s minimum/maximum reservable bandwidth,
change of port identifiers, or change of component identifiers in a
bundle. This mechanism is supported by an exchange of link summary
messages.
6.3. Link Connectivity Verification
Link connectivity verification is an optional procedure that may be
used to verify the physical connectivity of data-bearing links as
well as to exchange the link identifiers that are used in the GMPLS
signaling.
This procedure should be performed initially when a data-bearing link
is first established, and subsequently, on a periodic basis for all
unallocated (free) data-bearing links.
The verification procedure consists of sending Test messages in-band
over the data-bearing links. This requires that the unallocated
links must be opaque; however, multiple degrees of opaqueness (e.g.,
examining overhead bytes, terminating the payload, etc.), and hence
different mechanisms to transport the Test messages, are specified.
Note that the Test message is the only LMP message that is
transmitted over the data-bearing link, and that Hello messages
continue to be exchanged over the control channel during the link
verification process. Data-bearing links are tested in the transmit
direction as they are unidirectional. As such, it is possible for
LMP neighboring nodes to exchange the Test messages simultaneously in
both directions.
To initiate the link verification procedure, a node must first notify
the adjacent node that it will begin sending Test messages over a
particular data-bearing link, or over the component links of a
particular bundled link. The node must also indicate the number of
data-bearing links that are to be verified; the interval at which the
test messages will be sent; the encoding scheme, the transport
mechanisms that are supported, the data rate for Test messages; and,
in the case where the data-bearing links correspond to fibers, the
wavelength over which the Test messages will be transmitted.
Furthermore, the local and remote bundled link identifiers are
transmitted at this time to perform the component link association
with the bundled link identifiers.
6.4. Fault Management
Fault management is an important requirement from the operational
point of view. Fault management includes usually: fault detection,
fault localization and fault notification. When a failure occurs and
is detected (fault detection), an operator needs to know exactly
where it happened (fault localization) and a source node may need to
be notified in order to take some actions (fault notification).
Note that fault localization can also be used to support some
specific (local) protection/restoration mechanisms.
In new technologies such as transparent photonic switching currently
no method is defined to locate a fault, and the mechanism by which
the fault information is propagated must be sent "out of band" (via
the control plane).
LMP provides a fault localization procedure that can be used to
rapidly localize link failures, by notifying a fault up to the node
upstream of that fault (i.e., through a fault notification
procedure).
A downstream LMP neighbor that detects data link failures will send
an LMP message to its upstream neighbor notifying it of the failure.
When an upstream node receives a failure notification, it can
correlate the failure with the corresponding input ports to determine
if the failure is between the two nodes. Once the failure has been
localized, the signaling protocols can be used to initiate link or
path protection/restoration procedures.
6.5. LMP for DWDM Optical Line Systems (OLSs)
In an all-optical environment, LMP focuses on peer communications
(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
multiplexer). Exposing this information to the control plane can
improve network usability by further reducing required manual
configuration, and by greatly enhancing fault detection and recovery.
LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC
and an OLS. These extensions are intended to satisfy the Optical
Link Interface Requirements described in [OLI-REQ].
Fault detection is particularly an issue when the network is using
all-optical photonic switches (PXC). Once a connection is
established, PXCs have only limited visibility into the health of the
connection. Although the PXC is all-optical, long-haul OLSs
typically terminate channels electrically and regenerate them
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
this information to the PXC.
In addition to the link information known to the OLS that is
exchanged through LMP-WDM, some information known to the OXC may also
be exchanged with the OLS through LMP-WDM. This information is
useful for alarm management and link monitoring (e.g., trace
monitoring). Alarm management is important because the
administrative state of a connection, known to the OXC (e.g., this
information may be learned through the Admin Status object of GMPLS
signaling [RFC3471]), can be used to suppress spurious alarms. For
example, the OXC may know that a connection is "up", "down", in a
"testing" mode, or being deleted ("deletion-in-progress"). The OXC
can use this information to inhibit alarm reporting from the OLS when
a connection is "down", "testing", or being deleted.
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
similarities between an OXC-OXC LMP session and an OXC-OLS LMP
session, particularly for control management and link verification,
there are some differences as well. These differences can primarily
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
basis for GMPLS signaling and routing at the optical layer. The
information exchanged over LMP-WDM sessions is used to augment
knowledge about the links between OXCs.
In order for the information exchanged over the OXC-OLS LMP sessions
to be used by the OXC-OXC session, the information must be
coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP
sessions are run independently and must be maintained separately. 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 the
verification procedure. This is because the same data link may be
verified between OXC-OLS and between OXC-OXC. The verification
procedure of LMP is used to coordinate the Test procedure (and hence
the transparency/opaqueness of the data links). To maintain
independence between the sessions, it must be possible for the LMP
sessions to come up in any order. In particular, it must be possible
for an OXC-OXC LMP session to come up without an OXC-OLS LMP session
being brought up, and vice-versa.
7. Generalized Signaling
The GMPLS signaling extends certain base functions of the RSVP-TE and
CR-LDP signaling and, in some cases, adds functionality. These
changes and additions impact basic LSP properties: how labels are
requested and communicated, the unidirectional nature of LSPs, how
errors are propagated, and information provided for synchronizing the
ingress and egress.
The core GMPLS signaling specification is available in three parts:
1. A signaling functional description [RFC3471].
2. RSVP-TE extensions [RFC3473].
3. CR-LDP extensions [RFC3472].
In addition, independent parts are available per technology:
1. GMPLS extensions for SONET and SDH control [RFC3946].
2. GMPLS extensions for G.709 control [GMPLS-G709].
The following MPLS profile expressed in terms of MPLS features
[RFC3031] applies to GMPLS:
- Downstream-on-demand label allocation and distribution.
- Ingress initiated ordered control.
- Liberal (typical), or conservative (could) label retention mode.
- Request, traffic/data, or topology driven label allocation
strategy.
- Explicit routing (typical), or hop-by-hop routing.
The GMPLS signaling defines the following new building blocks on the
top of MPLS-TE:
1. A new generic label request format.
2. Labels for TDM, LSC and FSC interfaces, generically known as
Generalized Label.
3. Waveband switching support.
4. Label suggestion by the upstream for optimization purposes (e.g.,
latency).
5. Label restriction by the upstream to support some optical
constraints.
6. Bi-directional LSP establishment with contention resolution.
7. Rapid failure notification extensions.
8. Protection information currently focusing on link protection,
plus primary and secondary LSP indication.
9. Explicit routing with explicit label control for a fine degree of
control.
10. Specific traffic parameters per technology.
11. LSP administrative status handling.
12. Control channel separation.
These building blocks will be described in more details in the
following. A complete specification can be found in the
corresponding documents.
Note that GMPLS is highly generic and has many options. Only
building blocks 1, 2 and 10 are mandatory, and only within the
specific format that is needed. Typically, building blocks 6 and 9
should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are
optional.
A typical SONET/SDH switching network would implement building
blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks
7 and 8 are optional since the protection can be achieved using
SONET/SDH overhead bytes.
A typical wavelength switching network would implement 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.
A typical fiber switching network would implement building blocks:
1, 2 (the generic format), 6, 7, 8, 9 and 11.
A typical MPLS-IP network would not implement any of these building
blocks, since the absence of building block 1 would indicate regular
MPLS-IP. Note however that building block 1 and 8 can be used to
signal MPLS-IP as well. In that case, the MPLS-IP network can
benefit from the link protection type (not available in CR-LDP, some
very basic form being available in RSVP-TE). Building block 2 is
here a regular MPLS label and no new label format is required.
GMPLS does not specify any profile for RSVP-TE and CR-LDP
implementations that have to support GMPLS - except for what is
directly related to GMPLS procedures. It is to the manufacturer to
decide which are the optional elements and procedures of RSVP-TE and
CR-LDP that need to be implemented. Some optional MPLS-TE elements
can be useful for TDM, LSC and FSC layers, for instance the setup and
holding priorities that are inherited from MPLS-TE.
7.1. Overview: How to Request an LSP
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request
message downstream to the destination. This message contains a
Generalized Label Request with the type of LSP (i.e., the layer
concerned), and its payload type. An Explicit Route Object (ERO) is
also normally added to the message, but this can be added and/or
completed by the first/default LSR.
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC
object, or in the CR-LDP Traffic Parameters TLV. Specific parameters
for a given technology are given in these traffic parameters, such as
the type of signal, concatenation and/or transparency for a SONET/SDH
LSP. For some other technology there be could just one bandwidth
parameter indicating the bandwidth as a floating-point value.
The requested local protection per link may be requested using the
Protection Information Object/TLV. The end-to-end LSP protection is
for further study and is introduced LSP protection/restoration
section (see after).
If the LSP is a bi-directional LSP, an Upstream Label is also
specified in the Path/Label Request message. This label will be the
one to use in the upstream direction.
Additionally, a Suggested Label, a Label Set and a Waveband Label can
also be included in the message. Other operations are defined in
MPLS-TE.
The downstream node will send back a Resv/Label Mapping message
including one Generalized Label object/TLV that can contain several
Generalized Labels. For instance, if a concatenated SONET/SDH signal
is requested, several labels can be returned.
In case of SONET/SDH virtual concatenation, a list of labels is
returned. Each label identifying one element of the virtual
concatenated signal. This limits virtual concatenation to remain
within a single (component) link.
In case of any type of SONET/SDH contiguous concatenation, only one
label is returned. That label is the lowest signal of the contiguous
concatenated signal (given an order specified in [RFC3946]).
In case of SONET/SDH "multiplication", i.e., co-routing of circuits
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
the LSP is returned.
7.2. Generalized Label Request
The Generalized Label Request is a new object/TLV to be added in an
RSVP-TE Path message instead of the regular Label Request, or in a
CR-LDP Request message in addition to the already existing TLVs. Only
one label request can be used per message, so a single LSP can be
requested at a time per signaling message.
The Generalized Label Request gives three major characteristics
(parameters) required to support the LSP being requested: the LSP
Encoding Type, the Switching Type that must be used and the LSP
payload type called Generalized PID (G-PID).
The LSP Encoding Type indicates the encoding type that will be used
with the data associated with the LSP, i.e., the type of technology
being considered. For instance, it can be SDH, SONET, Ethernet, ANSI
PDH, etc. It represents the nature of the LSP, and not the nature of
the links that the LSP traverses. This is used hop-by-hop by each
node.
A link may support a set of encoding formats, where support means
that a link is able to carry and switch a signal of one or more of
these encoding formats. The Switching Type indicates then the type
of switching that should be performed on a particular link for that
LSP. This information is needed for links that advertise more than
one type of switching capability.
Nodes must verify that the type indicated in the Switching Type is
supported on the corresponding incoming interface; otherwise, the