Internet Draft 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 , 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 ***********