One document matched: draft-rstb-optical-signaling-framework-00.txt
Internet Draft Bala Rajagopalan
Expiration Date: Sept., 1, 2000 Debanjan Saha
Bo Tang
Krishna Bala
Tellium Inc.
Signaling Framework for Automated Provisioning
and Restoration of Paths in Optical Mesh Networks
draft-rstb-optical-signaling-framework-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstact
This draft describes the issues that must be addressed in developing
signaling mechanisms for automated establishment and restoration of
paths in optical mesh networks. This draft is the first attempt at
developing a framework for RSVP or CR-LDP-based signaling for
interconnected optical networks.
3. Introduction
Optical Networking has evolved considerably in the past few years
and has made its transition from laboratories to field deployed
networks. The first deployments of such networks has been in the form
of opaque architectures [1]. In such networks an optical signal is
converted to electrical and regenerated at each intermediate node.
This allows the removal of accumulated transmission impairments at
intermediate nodes, intermediate node performance monitoring, fault
isolation and wavelength conversion. However, this results in added
cost in terms of the number of extra "transponders" that are required
on an end-to-end path.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
More recently, vendors have introduced products that allow a signal
to be regenerated over longer distances resulting in hybrid network
architectures [1] that comprise of transparent all-optical islands
interconnected with opaque regenerative elements. These advances open
up the possibility for all optical networking for end-to-end
connections. However, one big drawback with all-optical networks is
that they do not yet allow wavelength conversion.
Routing and restoration in such hybrid networks (all-optical
interconnected with opaque regeneration) is a significant challenge.
The major issue arises in routing connections in the absence of
wavelength conversion. In this scenario, the optical channel has to
be assigned the same wavelength on the entire end-to-end path. This
requires that the link state databases at the nodes also keep
wavelength assignment and usage information for the purpose of
wavelength routing. In addition, signaling support for wavelength
assignment may be needed. The problem is much worse during
restoration where a failed wavelength results in co-ordination
across the network to find the same continuous wavelength on a
back-up path.
It is likely that optical networks will incorporate a combination of
technologies (transparent and opaque) from multiple vendors. The
general consensus in the industry is to develop IP-based control
planes for optical networks, utilizing constraint-based routing and,
RSVP or CRLDP-based signaling mechanisms. It is likely that such
control planes will have proprietary components to implement vendor-
specific provisioning and restoration schemes. Automated establishment
and restoration of end-to-end paths in such networks requires
standardized signaling and routing mechanisms across sub-networks.
This draft deals with the signaling issue: what are the specific
concerns that must be taken into account when developing signaling
mechanisms for establishing and restoring optical paths and a model
for standardized signaling across optical sub-networks.
3.1 Optical Network Model
The optical network model considered in this draft consists of
multiple Optical Cross-Connects (OXCs) interconnected by optical
links in a general topology (refered to as an "optical mesh network").
This network may be multi-vendor, where individual vendor OXCs
constitute "clouds" or "sub-networks". Each sub-network itself is
assumed to be mesh-connected.
Each OXC is assumed to be capable of switching a data stream from a
given input port to a given output port. This switching function is
controlled by appropriately configuring a cross-connect table.
Conceptually, the cross-connect table consists of entries of the form
<input port i, output port j>, indicating that data stream entering
input port i will be switched to output port j. An "optical path"
from an ingress port in an OXC to an egress port in a remote OXC is
established by setting up suitable cross-connects in the ingress, the
egress and a set of intermediate OXCs such that a continuous physical
path exists from the ingress to the egress port. Optical paths are
assumed to be bi-directional, i.e., the return path from the egress
port to the ingress port follows the same path as the forward path.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
The switching within the OXC may be accomplished in the electrical
domain, or the OXC may be all-optical. Furthermore, multiple data
streams output from an OXC may be multiplexed onto an optical link
using WDM technology. The WDM functionality may exist outside of the
OXC, and be transparent to the OXC. Or, this function may be built
into the OXC. In the latter case, the cross-connect table
(conceptually) consists of pairs of the form, <{input port i,
wavelength j}, {output port k, wavelength l}>. This indicates that
the data stream received on wavelength j over input port i is
switched to output port k on wavelength l. Automated establishment
of optical paths therefore involves setting up the cross-connect
table entries in the appropriate OXCs in a coordinated manner such
that the desired physical path is realized.
In general, it can be expected that topologically adjacent OXCs in an
optical mesh network will be connected via multiple, parallel
(bi-directional) optical links. It is assumed that one or more control
channels exist between neighboring OXCs for signaling purposes.
The request to establish an optical path may arise from either a
router (or some other device) connected to the OXCs or from a
management system. Such a request must identify ports in an ingress
and an egress OXC as endpoints of the optical path. The request may
also include bandwidth parameters (e.g., OC-48/OC-192), reliability
parameters, restoration options, setup and holding priorities for the
path etc. On receipt of the request, the ingress OXC computes a
suitable route for the requested path, following applicable policies
and constraints. Once the route has been computed, the ingress
invokes a signaling protocol to set up the path. Protocols such as
CR-LDP or RSVP may be suitably modified/enhanced to perform this
signaling. This draft identifies some of the requirements that must
be satisfied by such a signaling protocol.
3.2 End-to-End Scenarios
The Multi-Protocol Lambda Switching (MP-Lambda-S) work earlier has
drawn an analogy between traditional label switching and wavelength
conversion in optical networks [2-4]. This work has considered an
interworking scenario where the OXCs and routers are peers in the same
routing domain and label switching works seamlessly end to end.
In this draft, the emphasis is on examining the signaling requirements
within a multi-vendor optical network. Such a network may consist
of multiple optical sub-networks (or "clouds"), each consisting of
similar OXCs from a given vendor. IP routers are assumed to be
external to this network. How end-to-end routing and signaling is
accomplished between routers is an open issue. Optical network
characteristics and requirements are different from those of router
networks, and a practical model for interworking is to be determined.
This draft does not address the issue further.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
4. Signaling Requirements
4.1 General Requirements
Signaling mechanisms for optical networks should be tailored to the
needs of optical networking. This is specifically an issue when
considering the adoption of RSVP or CRLDP-based signaling. There are
broadly two concerns: first, if there are protocol features or
semantics that are unnecessary or inappropriate in the optical network
setting, there should be no requirement to support them. Second, if
there is a need for new protocol features or semantics, it should be
possible to add them. Addressing both of these issues may mean making
changes to the base protocols.
Some general signaling requirements in optical networks are:
o Signaling mechanisms must minimize the need for manual
configuration of relevant information, such as local topology.
o Optical paths are fixed bandwidth pipes. There is no need to
convey complex traffic characterization or other QoS parameters
in signaling messages. On the other hand, new service related
parameters such as restoration priority, protection scheme
desired, etc., may have to be conveyed.
o Signaling for path establishment must be quick and reliable. It is
especially important to minimize signaling delays during
restoration.
o Optical paths are typically bidirectional. Both directions of the
path must be established along the same physical route.
o OXCs are subject to high reliability requirements. A transient
failure that does not affect the data plane of the established
paths should not result in these paths being torn down.
o Restoration schemes in mesh networks rely on sharing backup paths
among many primary paths. Signaling protocols should support this
feature.
o The interaction between path establishment signaling and automatic
protection schemes must be well-defined to avoid false restoration
attempts during path set-up or tear down.
o End-to-end signaling should not preclude proprietary mechanisms
within sub-networks.
These points are discussed in more detail below.
4.1 Automatic Neighbor Discovery
The first action of coordination between neighbors prior to end-to-end
path establishment involves determining which output port of an OXC
is connected to which input port of an adjacent OXC. The protocol for
this is refered to as the "Optical Link Discovery Protocol (OLDP)".
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
OLDP results in each OXC creating a port state database. This
database lists the local connectivity information, along with
parameters and state of the local links. While this information is of
use to routing protocols [2], it is utilized in the following
specific manner during optical path set-up: The OXC currently
processing a path set-up signal selects the output port for the
optical path and establishes its internal cross-connect table entry.
It then signals the output port information to the "next" OXC in the
optical path. By referring to its port state database, the "next" OXC
infers the input port through which the optical path is being set up.
(It is also possible that an OXC uses its port state database to
determine the inport port of the "next" OXC and indicate this in the
signaling message).
It should be noted that the process described above is not quite the
same as selecting a label under MPLS, since MPLS labels are
independently administered by each node. Here, the output port at an
OXC is physically tied to an input port at its neighbor. This requires
some coordination in the selection of ports at neighboring OXCs, as
described in Section 4.2.
For multivendor interoperability, OLDP should be a standard protocol.
The features of OLDP are to be determined.
4.2 Bi-Directional Path Set-Up
With bi-directional path set up, the output port selected at an OXC
for the forward direction is also the input port for the reverse
direction of the path. Since signaling for optical paths may be
autonomously initiated by different nodes, it is possible that two
path set-up attempts are in progress at the same time. Specifically,
while setting up an optical path, an OXC A may select output port i
which is connected to input port j of the "next" OXC B. Concurrently,
OXC B may select output port j for setting up a different optical
path, where the "next" OXC is A. This results in a "collision".
Similarly, when WDM functionality is built into OXCs, a collision
occurs when adjacent OXCs choose directly connected output ports and
the same wavelength for two different optical paths. There are two
ways to deal with such collisions. First, collisions may be detected
and the involved paths may be torn down and re-established. Or,
collisions may be avoided altogether. The latter solution is
preferred, if the complexity involved is acceptable.
4.3 Optical Paths without Wavelength Conversion
The presence of OXCs without wavelength conversion introduces some
additional complexity while establishing paths. Specifically, it
is necessary to determine a path with wavelength continuity. This
could be done during the path selection phase, using a constraint-
based routing protocol that takes into account available wavelengths
on each link. Or, the means to determine wavelength continuity along
the path may be provided by the signaling mechanism. The latter may
be necessary while establishing paths across optical sub- networks.
Here, complete information about wavelength allocations inside a sub-
network may not be available to sources outside.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
Signaling support for wavelength selection must accommodate the
following. The path establishment message must collect available
wavelegths along the path. A procedure to select a specific
wavelength, along with a phase to actually set-up the path over the
selected wavelength must be available. Furthermore, procedures to
resolve contention between two concurrent path set-up attempts vieing
for the same wavelength must be included.
4.4 Failure Recovery
The impact of transient partial failures must be minimized in an
optical network. Specifically, optical paths that are not directly
affected by a failure must not be torn down due to the failure. For
example, the control processor in an OXC may fail, affecting signaling
and other internodal control communication. Similarly, the control
channel between OXCs may be affected temporarily by a failure. These
failure may not affect already established optical paths passing
through the OXC fabric. The detection of such failures by adjacent
nodes, for example, through a keepalive mechanism between signaling
peers, must not result in these optical paths being torn down.
It is likely that when the above failures occur, a backup processor
or a backup control channel will be activated. The signaling protocol
must be designed such that it is resilient to transient failures.
During failure recovery, it is desirable to recover local state at
the concerned OXC with least disruption to existing optical paths.
4.5 Soft State Issues
An optical path is essentially a hard circuit between two end points.
Path establishment and restoration are bound by strict time
constraints. Established paths tend to stay for relatively long
periods of time. Furthermore, once established, path teardown must
also be carefully coordinated (see below). Hard state signaling
mechanisms with reliable messaging between OXCs, and controlled tear
down seem more appropriate for setting up optical paths compared to
soft state mechanisms. This means that the specific requirements of
optical networks must be carefully considered while adopting RSVP
for signaling. Specifically,
o Reliable messaging: Relying on periodic refresh to ensure eventual
message reception is not approriate for quick establishment of
paths when some messages may be lost in transit. Increasing the
refresh rate leads to unncessary refreshes over paths that change
infrequently. Reliable messaging seems to be the most logical
choice for path set-up.
o Refresh mechanism: In general, the appropriateness of soft state
refreshes must be evaluated. Given that paths are relatively long-
lived and rerouting after failures will be bound by tight time
constraints, the soft state approach looks out of place.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
o Coordinated path teardown: Path tear-down should be carefully
coordinated among OXCs along the path. The lack of coordination
might result in some OXCs detecting a path failure and initiating
fast restoration while others see an intentional tear-down.
Path tear-down therefore must be reliable and two-phase,
whereby each OXC along the path is aware of the tear-down
in progress before any OXC actually deallocates local resources
for the path.
The RSVP-specific issues are further described in [5].
4.6 Restoration
Restoration requirements pose the greatest challenge for developing
a standard signaling mechanism in multi-vendor optical mesh networks.
The following must be considered with regard to restoration:
o Restoration may be based on both 1 + 1 and shared protection
schemes. With 1+1 protection, a pre-reserved backup path must be
established for each protected primary path. Thus, the protection
capacity required is 100% of primary capacity. With shared
protection, the network is provisioned with pre-reserved backup
paths that are shared among different protected primary paths such
that the protection capacity is significantly less than 100% of
primary capacity.
o There will be strict time constraints to restore a failed path
after the failure is detected. Typically, the time to complete
restoration will be in the order of 50 - 200 ms, depending on
specific requirements.
o Restoration path assignment algorithms are many and varied.
Shared protection, together with tight time constraints means that
the signaling mechanisms and real-time restoration path allocation
procedures must be very fast. It is very likely that proprietary
procedures will be developed by OXC vendors to meet their restoration
requirements and to establish a competetive advantage. A uniform
standard restoration procedure is unlikely to emerge. In a multi-
vendor setting, it is more practical to consider a two-level
restoration scenario. Recalling that our network model is
interconnected "clouds" of different vendor sub-networks, the first
level (or immediate) restoration scheme may be based on
proprietary solution within a vendor cloud. When this restoration
attempt fails for some optical paths, a second-level, standard
end-to-end restoration may be attempted. The second level restoration
can be permitted to be relatively slower, with the assumption that
it will be invoked infrequently. It may, however, be required to
speed up signaling for second-level restoration, as compared to
signaling for primary path provisioning.
The signaling for end-to-end restoration (second level) may require
the the specification of policies regarding the computation of
restoration path (e.g, sub-network disjoint paths). To compute
such restoration paths, signaling may have to support the following:
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
o Specification of loose source routes in primary and restoration
path set-up signaling.
o Capacity reservation for 1 + 1 or shared restoration paths. This
feature requires signaling assistance to indicate to OXCs in the
restoration paths that restoration capacity is being reserved for
a given optical path. In the case of shared restoration paths,
many primary paths may request the same shared capacity.
5. Overall Framework
Based on the discussion above, the following approach is suggested
for developing signaling mechanisms for optical networks:
o Develop consensus on the optical interworking model specifying
the required capabilities between sub-networks.
o Identify the functional requirements across sub-network
interfaces. This allows the development of specific signaling
mechanisms.
o Develop a hieararchical model whereby proprietary procedures
for provisioning and restoration may be allowed within sub-
networks, while standard mechanisms are used end-to-end across
sub-networks.
o While adopting RSVP or CRLDP for signaling, consider the specific
needs of optical networking and make suitable changes in the
protocols where necessary.
6. Summary
This draft described some issues that arise in developing signaling
procedures for path provisioning and restoration in optical networks.
The multi-vendor network model considered in this draft consisted of
clouds of individual vendor OXCs interconnected in a general mesh
topology. IP routers were considered external to the network, and
the interworking between IP routers and the optical network was not
considered.
The following signaling requirements were identified: support for
automatic neighbor discovery, support for bi-directional optical
path set-up with collision avoidance features, resiliency in the
presence of transient failures, support for reliable messaging,
support for 1 + 1 and shared protected paths, support for restoration
policies specification and pre-reservation of protected paths. Other
requirements may arise as work proceeds in this area.
This draft is the first attempt at developing a framework for
signaling based on RSVP or CR-LDP for optical networks. This work is
ongoing and future versions of this draft are expected to incorporate
further evolutions of the ideas presented.
Internet-Draft draft-rstb-optical-signaling-framework-00.txt
6. References
1. T. E. Stern and K. Bala, "Multiwavelength Optical Networks:
A Layered Approach", Prentice Hall, May 1999, ISBN 020130967X.
2. Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-
Protocol Lambda Switching: Combining MPLS Traffic Engineering
Control With Optical Crossconnects", draft-awduche-mpls-te-
optical-01.txt.
3. Kompella, K., Rekhter, Y., Awduche, D., et. al, "Extensions to
IS-IS/OSPF and RSVP in support of MPL(ambda)S," draft-kompella-
mpls-optical-00.txt.
4. Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi-
protocol Lambda Switching: Issues in Combining MPLS Traffic
Engineering Control With Optical Crossconnects", draft-basak-
mpls-oxc-issues-00.txt
5. D. Saha, B. Rajagopalan, and B. Tang, "RSVP Extensions for
Signaling Optical Paths", draft-saha-rsvp-optical-signaling-00.txt.
7. Author Information
Bala Rajagopalan, Debanjan Saha, Bo Tang, Krishna Bala
Tellium Inc.
2 Crescent Place
P.O Box 901
Ocean Port, NJ 07757
Email: {braja, dsaha, btang, kbala}@tellium.com
******** This draft expires on Sept., 1, 2000 ***********
| PAFTECH AB 2003-2026 | 2026-04-23 16:49:56 |