calculated before failure (often during LSP establishment).
Importantly, no signaling is used along the restoration path
before failure, and no restoration bandwidth is reserved.
Consequently, there is no guarantee that a given restoration path
is available when a failure occurs. Thus, one may have to
crankback to search for an available path.
- End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and no label pre-selection: an end-to-end restoration
path is pre-calculated before failure and a signaling message is
sent along this pre-selected path to reserve bandwidth, but labels
are not selected (see also [GMPLS-FUNCT]).
The resources reserved on each link of a restoration path may be
shared across different working LSPs that are not expected to fail
simultaneously. Local node policies can be applied to define the
degree to which capacity is shared across independent failures.
Upon failure detection, LSP signaling is initiated along the
restoration path to select labels, and to initiate the appropriate
cross-connections.
- End-to-end LSP restoration with pre-signaled recovery bandwidth
reservation and label pre-selection: An end-to-end restoration
path is pre-calculated before failure and a signaling procedure is
initiated along this pre-selected path on which bandwidth is
reserved and labels are selected (see also [GMPLS-FUNCT]).
The resources reserved on each link may be shared across different
working LSPs that are not expected to fail simultaneously. In
networks based on TDM, LSC and FSC technology, LSP signaling is
used after failure detection to establish cross-connections at the
intermediate switches on the restoration path using the pre-
selected labels.
- Local LSP restoration: the above approaches can be applied on a
local basis rather than end-to-end, in order to reduce recovery
time (note: no reference available at publication time).
11.8. Schema Selection Criteria
This section discusses criteria that could be used by the operator in
order to make a choice among the various P&R mechanisms.
- Robustness: In general, the less pre-planning of the restoration
path, the more robust the restoration scheme is to a variety of
failures, provided that adequate resources are available.
Restoration schemes with pre-planned paths will not be able to
recover from network failures that simultaneously affect both the
working and restoration paths. Thus, these paths should ideally
be chosen to be as disjoint as possible (i.e., SRLG and node
disjoint), so that any single failure event will not affect both
paths. The risk of simultaneous failure of the two paths can be
reduced by recalculating the restoration path whenever a failure
occurs along it.
The pre-selection of a label gives less flexibility for multiple
failure scenarios than no label pre-selection. If failures occur
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
recovered, unless the label assignment is changed.
The robustness of a restoration scheme is also determined by the
amount of reserved restoration bandwidth - as the amount of
restoration bandwidth sharing increases (reserved bandwidth
decreases), the restoration scheme becomes less robust to
failures. Restoration schemes with pre-signaled bandwidth
reservation (with or without label pre-selection) can reserve
adequate bandwidth to ensure recovery from any specific set of
failure events, such as any single SRLG failure, any two SRLG
failures etc. Clearly, more restoration capacity is allocated if
a greater degree of failure recovery is required. Thus, the
degree to which the network is protected is determined by the
policy that defines the amount of reserved restoration bandwidth.
- Recovery time: In general, the more pre-planning of the
restoration route, the more rapid the P&R scheme. Protection
schemes generally recover faster than restoration schemes.
Restoration with pre-signaled bandwidth reservation are likely to
be (significantly) faster than path restoration with re-
provisioning, especially because of the elimination of any
crankback. Local restoration will generally be faster than end-
to-end schemes.
Recovery time objectives for SONET/SDH protection switching (not
including time to detect failure) are specified in [ITUT-G.841] at
50 ms, taking into account constraints on distance, number of
connections involved, and in the case of ring enhanced protection,
number of nodes in the ring.
Recovery time objectives for restoration mechanisms are being
defined through a separate effort [RFC3386].
- Resource Sharing: 1+1 and 1:N link and LSP protection require
dedicated recovery paths with limited ability to share resources:
1+1 allows no sharing, 1:N allows some sharing of protection
resources and support of extra (pre-emptable) traffic.
Flexibility is limited because of topology restrictions, e.g.,
fixed ring topology for traditional enhanced protection schemes.
The degree to which restoration schemes allow sharing amongst
multiple independent failures is directly dictated by the size of
the restoration pool. In restoration schemes with re-
provisioning, a pool of restoration capacity can be defined from
which all restoration routes are selected after failure. Thus,
the degree of sharing is defined by the amount of available
restoration capacity. In restoration with pre-signaled bandwidth
reservation, the amount of reserved restoration capacity is
determined by the local bandwidth reservation policies. In all
restoration schemes, pre-emptable resources can use spare
restoration capacity when that capacity is not being used for
failure recovery.
12. Network Management
Service Providers (SPs) use network management extensively to
configure, monitor or provision various devices in their network. It
is important to note that a SP’s equipment may be distributed across
geographically separate sites thus making distributed management even
more important. The service provider should utilize an NMS system
and standard management protocols such as SNMP (see [RFC3410],
[RFC3411] and [RFC3416]) and the relevant MIB modules as standard
interfaces to configure, monitor and provision devices at various
locations. The service provider may also wish to use the command
line interface (CLI) provided by vendors with their devices. However,
this is not a standard or recommended solution because there is no
standard CLI language or interface, which results in N different CLIs
in a network with devices from N different vendors. In the context of
GMPLS, it is extremely important for standard interfaces to the SP’s
devices (e.g., SNMP) to exist due to the nature of the technology
itself. Since GMPLS comprises many different layers of control-plane
and data-plane technology, it is important for management interfaces
in this area to be flexible enough to allow the manager to manage
GMPLS easily, and in a standard way.
12.1. Network Management Systems (NMS)
The NMS system should maintain the collective information about each
device within the system. Note that the NMS system may actually be
comprised of several distributed applications (i.e., alarm
aggregators, configuration consoles, polling applications, etc.)
that collectively comprises the SP’s NMS. In this way, it can make
provisioning and maintenance decisions with the full knowledge of the
entire SP’s network. Configuration or provisioning information
(i.e., requests for new services) could be entered into the NMS and
subsequently distributed via SNMP to the remote devices. Thus,
making the SP’s task of managing the network much more compact and
effortless rather than having to manage each device individually
(i.e., via CLI).
Security and access control can be achieved using the SNMPv3 User-
based Security Model (USM) [RFC3414] and the View-based Access
Control Model (VACM) [RFC3415]. This approach can be very
effectively used within a SP’s network, since the SP has access to
and control over all devices within its domain. Standardized MIBs
will need to be developed before this approach can be used
ubiquitously to provision, configure and monitor devices in non-
heterogeneous networks or across SP’s network boundaries.
12.2. Management Information Base (MIB)
In the context of GMPLS, it is extremely important for standard
interfaces to devices to exist due to the nature of the technology
itself. Since GMPLS comprises many different layers of control-plane
technology, it is important for SNMP MIB modules in this area to be
flexible enough to allow the manager to manage the entire control
plane. This should be done using MIB modules that may cooperate
(i.e., coordinated row-creation on the agent) or through more
generalized MIB modules that aggregate some of the desired actions to
be taken and push those details down to the devices. It is important
to note that in certain circumstances, it may be necessary to
duplicate some small subset of manageable objects in new MIB modules
for management convenience. Control of some parts of GMPLS may also
be achieved using existing MIB interfaces (i.e., existing SONET MIB)
or using separate ones, which are yet to be defined. MIB modules may
have been previously defined in the IETF or ITU. Current MIB modules
may need to be extended to facilitate some of the new functionality
desired by GMPLS. In these cases, the working group should work on
new versions of these MIB modules so that these extensions can be
added.
12.3. Tools
As in traditional networks, standard tools such as traceroute
[RFC1393] and ping [RFC2151] are needed for debugging and performance
monitoring of GMPLS networks, and mainly for the control plane
topology, that will mimic the data plane topology. Furthermore, such
tools provide network reachability information. The GMPLS control
protocols will need to expose certain pieces of information in order
for these tools to function properly and to provide information
germane to GMPLS. These tools should be made available via the CLI.
These tools should also be made available for remote invocation via
the SNMP interface [RFC2925].
12.4. Fault Correlation between Multiple Layers
Due to the nature of GMPLS, and that potential layers may be involved
in the control and transmission of GMPLS data and control
information, it is required that a fault in one layer be passed to
the adjacent higher and lower layers to notify them of the fault.
However, due to nature of these many layers, it is possible and even
probable, that hundreds or even thousands of notifications may need
to transpire between layers. This is undesirable for several
reasons. First, these notifications will overwhelm the device.
Second, if the device(s) are programmed to emit SNMP Notifications
[RFC3417] then the large number of notifications the device may
attempt to emit may overwhelm the network with a storm of
notifications. Furthermore, even if the device emits the
notifications, the NMS that must process these notifications either
will be overwhelmed or will be processing redundant information. That
is, if 1000 interfaces at layer B are stacked above a single
interface below it at layer A, and the interface at A goes down, the
interfaces at layer B should not emit notifications. Instead, the
interface at layer A should emit a single notification. The NMS
receiving this notification should be able to correlate the fact that
this interface has many others stacked above it and take appropriate
action, if necessary.
Devices that support GMPLS should provide mechanisms for aggregating,
summarizing, enabling and disabling of inter-layer notifications for
the reasons described above. In the context of SNMP MIB modules, all
MIB modules that are used by GMPLS must provide enable/disable
objects for all notification objects. Furthermore, these MIBs must
also provide notification summarization objects or functionality (as
described above) as well. NMS systems and standard tools which
process notifications or keep track of the many layers on any given
devices must be capable of processing the vast amount of information
which may potentially be emitted by network devices running GMPLS at
any point in time.
13. Security Considerations
GMPLS defines a control plane architecture for multiple technologies
and types of network elements. In general, since LSPs established
using GMPLS may carry high volumes of data and consume significant
network resources, security mechanisms are required to safeguard the
underlying network against attacks on the control plane and/or
unauthorized usage of data transport resources. The GMPLS control
plane should therefore include mechanisms that prevent or minimize
the risk of attackers being able to inject and/or snoop on control
traffic. These risks depend on the level of trust between nodes that
exchange GMPLS control messages, as well as the realization and
physical characteristics of the control channel. For example, an in-
band, in-fiber control channel over SONET/SDH overhead bytes is, in
general, considered less vulnerable than a control channel realized
over an out-of-band IP network.
Security mechanisms can provide authentication and confidentiality.
Authentication can provide origin verification, message integrity and
replay protection, while confidentiality ensures that a third party
cannot decipher the contents of a message. In situations where GMPLS
deployment requires primarily authentication, the respective
authentication mechanisms of the GMPLS component protocols may be
used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally,
the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409])
may be used to provide authentication, confidentiality or both, for a
GMPLS control channel. IPsec thus offers the benefits of combined
protection for all GMPLS component protocols as well as key
management.
A related issue is that of the authorization of requests for
resources by GMPLS-capable nodes. Authorization determines whether a
given party, presumable already authenticated, has a right to access
the requested resources. This determination is typically a matter of
local policy control [RFC2753], for example by setting limits on the
total bandwidth available to some party in the presence of resource
contention. Such policies may become quite complex as the number of
users, types of resources and sophistication of authorization rules
increases.
After authenticating requests, control elements should match them
against the local authorization policy. These control elements must
be capable of making decisions based on the identity of the
requester, as verified cryptographically and/or topologically. For
example, decisions may depend on whether the interface through which
the request is made is an inter- or intra-domain one. The use of
appropriate local authorization policies may help in limiting the
impact of security breaches in remote parts of a network.
Finally, it should be noted that GMPLS itself introduces no new
security considerations to the current MPLS-TE signaling (RSVP-TE,
CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management
protocols (SNMP).
14. Acknowledgements
This document is the work of numerous authors and consists of a
composition of a number of previous documents in this area.
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH
discussions we had together. Thanks also to Pedro Falcao, Alexandre
Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from
Ebone for their SONET/SDH and optical technical advice and support.
Finally, many thanks also to Krishna Mitra (Consultant), Curtis
Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent)
for their revision effort on Section 12.
15. References
15.1. Normative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu,
R., Wu, L., Doolan, P., Worster, T., Feldman,
N., Fredette, A., Girish, M., Gray, E.,
Heinanen, J., Kilty, T., and A. Malis,
"Constraint-Based LSP Setup using LDP", RFC
3212, January 2002.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized
Multi-Protocol Label Switching (GMPLS)
Signaling Constraint-based Routed Label
Distribution Protocol (CR-LDP) Extensions", RFC
3472, January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
15.2. Informative References
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure,
Rates, And Formats," ANSI T1.105, 2000.
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering", Work in
Progress.
[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed.,
"Generalized MPLS Recovery Functional
Specification", Work in Progress.
[GMPLS-G709] Papadimitriou, D., Ed., "GMPLS Signaling
Extensions for G.709 Optical Transport Networks
Control", Work in Progress.
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Rekhter, "GMPLS UNI: RSVP Support for the
Overlay Model", Work in Progress.
[GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-
Protocol Label Switching", Work in Progress.
[RFC3946] Mannie, E., Ed. and Papadimitriou D., Ed.,
"Generalized Multi-Protocol Label Switching
(GMPLS) Extensions for Synchronous Optical
Network (SONET) and Synchronous Digital
Hierarchy (SDH) Control", RFC 3946, October
2004.
[HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy
with Generalized MPLS TE", Work in Progress.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for
Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-
Protocol Label Switching", Work in Progress.
[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 Protection Architectures,"
Recommendation G.841, October 1998.
[LMP] Lang, J., Ed., "Link Management Protocol
(LMP)", Work in Progress.
[LMP-WDM] Fredette, A., Ed. and J. Lang Ed., "Link
Management Protocol (LMP) for Dense Wavelength
Division Multiplexing (DWDM) Optical Line
Systems", Work in Progress.
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
Evolution of Transport Network Survivability,"
IEEE 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] Fredette, A., Ed., "Optical Link Interface
Requirements," Work in Progress.
[OSPF-TE-GMPLS] Kompella, K., Ed. and Y.
Rekhter, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching",