Internet Draft Internet Draft Z. Bo Tang Expiration Date: September, 2000 Debanjan Saha Bala Rajagopalan Tellium Inc. Extensions to CR-LDP for Path Establishment in Optical Networks draft-tang-crldp-optical-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 extensions to the CR-LDP for establishing optical switched paths (OSP). This document does not advocate CR-LDP as the sole mechanism for setting up such paths. RSVP extensions for path set-up are described in [1]. 3. Introduction This document describes the extensions to CR-LDP [2] for establishing switched paths in optical networks. The optical network model considered in this draft consists of multiple Optical Cross- Connects (OXCs) interconnected by optical links in a general topology referred to as an "optical mesh network". In general, it can be expected that topologically adjacent OXCs in an optical mesh network will be connected via multiple, parallel bi-directional links. Each link can carry one or more optical channels or wavelengths. Each wavelength can be further demultiplexed into multiple TDM channels. We also assumed that one or more control channels exist between neighboring OXCs for signaling purposes. Tang, et al. [Page 1] Internet Drat draft-tang-crldp-optical-00.txt March 2000 Each OXC is capable of switching a wavelength from a given input port to a given output port. This switching function is controlled by appropriately configuring a cross-connect table. In the most general case, the cross-connect table consists of entries of the form , indicating that the TDM channel k, in wavelength j entering input port i will be switched to TDM channel p in output wavelength n at 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. Automated establishment of optical paths involves setting up the cross-connect table entries in the appropriate OXCs in a coordinated manner such that the desired physical path is realized. 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 the ingress and the egress OXC as endpoints of the optical path. In addition, it may also optionally specify the input and output ports, wavelengths, and TDM channels. The request may also include bandwidth parameters and channel type (e.g., OC-48/OC-192, 10 GE/N), 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 CR-LDP to set up the path. 4. Overview of the Extensions 4.1 Overview of the Key Concepts and Semantics of the CR-LDP First, it is necessary to review the semantics of some of the CR-LDP concepts [2, 4] in the optical network setting: o Label: Under MPLS, labels are used for packet forwarding. Labels are autonomously administered by each MPLS LSR [4]. In the context of setting up an optical path, the labels as defined in [2] are no longer directly applicable. o FEC: As per [2] and [4], Forwarding Equivalence Class is captured in the label used, and all packets classified as belonging to the same FEC will be forwarded with the same label. There is no similar semantics in optical networks. o Label mapping/binding: The main function of LDP/CR-LDP is to assign and distribute Label-FEC mapping information among LSRs. In optical networks, the equivalent function is the assignment of input or output ports for paths by optical switches and the communication of this information to the appropriate neighbors. o Label Request message: As described in [2, 4], a Label Request Tang, et al. [Page 2] Internet Drat draft-tang-crldp-optical-00.txt March 2000 message is used by an upstream LSR to request a label binding from the downstream LSR for a specified FEC and CR-LSP. In optical networks, a Label request message may be used by the upstream OXC to request a port (and wavelength) assignment from the downstream OXC for the optical path being established. Such a Label request message may carry all the information presently defined under CR- LDP except the TE-TLV which is not relevant. Using downstream-on- demand and ordered control mode, a Label request message is initially generated at the ingress OXC and is propagated to the egress OXC. o Label Mapping message: As described in [2, 4], a Label Mapping message is used for a downstream LSR to distribute label mapping information to its upstream peer. In optical networks, a Label mapping message is first generated by the egress OXC. It indicates the port (and wavelength) assignment to the upstream peer for the specified path. After receiving a Label mapping message, an intermediate OXC selects an input port and connects it to the appropriate output port derived from the port indication received from the downstream OXC. It also sends a Label mapping message to its upstream peer indicating the selected input port (and wavelength). It is implicitly assumed here that each OXC knows the identity of its output port that connects to a given input port of a neighbor [3]. This indeed is the dependency in label assignment. A protocol is required to determine the port mappings. 4.2 Overview of Extensions The proposed extensions to the CR-LDP are aimed at accomplishing the following tasks. o Signaling Port ID: A new TLV(OPTICAL_LABEL) is introduced to specify ports to be assigned for setting up the path. Such a "label" must be assigned in a coordinated manner by a pair of adjacent OXCs [3], since the "label" at one OXC is tied to a specific "label" at a neighboring OXC based on physical connectivity. o Signaling optical switched path identifier: A new TLV (OSP_ID) is introduced to provide the identifier to the optical path being established. The OSP_ID TLV is independent of LSP_ID TLV of the base CR-LDP. This provides the flexibility of establishing LSPs on the top of an optical path being setup when needs arise. o Signaling the two end points of the path being set up: A new TLV (END_POINTS) is introduced to signal the two end points at the port level of the optical path. When the two end points are already selected before the path is set up, at least the port already selected for the egress node should be propagated to the egress node. o Signaling requirements for both span and path protection: A new TLV (PROT_REQ) is introduced to signal what protection levels are Tang, et al. [Page 3] Internet Drat draft-tang-crldp-optical-00.txt March 2000 required for both span (or local) and path protection. Examples of span (or local) protection include SONET 1+1 and 1:N APS. Examples of path protection include various levels regarding how an alternate path is shared such as in a style of 1+1 or 1:N analogous to span protection. The values indicating both span and path protection levels encapsulated in the TLV are opaque to the extended CR-LDP process and are interpreted by the "protection policy controller". o Recording the precise route of the path being established: A new TLV (ROUTE_RECORD) is introduced to capture the precise route of the path being set up with port level information. This is done by letting each OXC insert its node ID and the both output and input port selected for the path in the Label Mapping message. The message received by the ingress OXC will have the complete route at the port level. This information is useful for network management functions. 5. Configuration Recommendations to the Base CR-LDP Specification 5.1 Multiple Hello Adjacencies per LDP Session It is very likely that neighboring OXCs will have multiple physical links between them. In this case, only a single LDP session between the two LDP peers will be established. A Hello Adjacency should be maintained for each physical connection between the two adjacent OXCs. 6. Extended Protocol Specifications 6.1 Optical Label TLV Optical Label TLV is used to specify the output port ID and the associated wavelength when an OXC sends a Label Mapping message to its upstream peer for a path setup. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Optical Label ( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength ID | Sub-channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Port ID 32-bit field. Wavelength ID 16-bit field. Sub-channel ID Tang, et al. [Page 4] Internet Drat draft-tang-crldp-optical-00.txt March 2000 16-bit field. 6.2 OSP ID TLV The TLV is used to provide the identifier to the optical path being established. The format is similar to that of LSP_ID TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| OSPID (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |D| Local OSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress OSP OXC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (14 bits) TBD Length (16 bits) Specifies the length of the value field in bytes. Reserved (15 bits) Zero on transmission. Ignored on receipt. D (1 bit) Direction dimension indicator of the path. 0: indicates unidirection path being set up 1: indicates bidirection path being set up Local OSP ID (16 bits) The Local OSP ID is locally unique within the Ingress OXC originating the OSP. Ingress OSP OXC ID (32 bits) This node ID with the Local OSP ID provide the unique identifier of the OSP within the network. 6.3 Endpoints TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| ENDPOINTS (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress OSP OXC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress OSP OXC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Port ID at the Ingress OXC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Port ID at the egress OXC | Tang, et al. [Page 5] Internet Drat draft-tang-crldp-optical-00.txt March 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ingress OXC ID (32 bits) Ingress OXC ID together with the other IDs provide the two end point addresses for the path. 6.4 Protection Requirement TLV This new TLV is present in the Label Request message to indicate which protection mode is requested for the optical path. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Protection Req.( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LocalProt.Mode|Path Prot. Mode| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Local Protection Mode (8 bits) The value is opaque to CR-LDP process and is used by the local "protection controller" for local protection configuration. Path Protection Mode (8 bits) The value is opaque to CR-LDP process and is to inform the OXC receiving the TLV what protection level is associated with the optical path. Sub-TLVs Sub-TLVs can be used to provide and identify the associations among the paths that are under the specified protection scheme. The format details are to be determined. 6.5 Route Record TLV The encoding for the Route Record TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Route Record ( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OXC ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In port of OXC ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out port Id of OXC ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // OXC ID n // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In port of OXC ID n | Tang, et al. [Page 6] Internet Drat draft-tang-crldp-optical-00.txt March 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out port of OXC ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One or more OXC IDs A list of router-ids indicating the path of OXCs the message has traversed. One or more in port IDs A list of port IDs indicating the incoming ports of OXCs for the optical path. One or more out port IDs A list of port IDs indicating the out going ports of OXCs for the optical path. 7. Issues 7.1 Bidirectional Path Establishment CR-LDP is designed under the assumption that explicit LSPs are fundamentally unidirectional and point-to-point virtual path connection abstraction. In optical networks, it is currently common practice that an optical path set up is in fact bi-directional. Racing condition that will not occur at unidirectional cases with MPLS downstream on demand and ordered control mode for label distribution can happen for bi-directional cases. We propose a simple solution to avoid racing condition. The solution suggests forming a master and slave relationship between two adjacent OXCs. The OXC with the higher node ID is the master to the other. It is always the master node that makes port assignment for both itself and its slave peer. 6.2 Improve Availability of MPLS control plan. An availability issue may rise when the MPLS control plan is down and then comes back a while later. All relevant databases containing the information prior to the breakdown should be recovered. The solution is TBD. 7. Acknowledgements The ideas and texts presented in this document are stimulated from a numerous discussions. Particularly, we would like to thank Mike Rugiero and Tom Damiano. 8. References [1] D. Saha, B. Rajagopalan, and B. Tang, "RSVP Extensions for Signaling Optical Paths", draft-saha-rsvp-optical-signaling-00.txt, March, 2000. Tang, et al. [Page 7] Internet Drat draft-tang-crldp-optical-00.txt March 2000 [2] L. Andersson, A. Fredette, B. Jamoussi, et al., "Constraint- Based LSP Setup using LDP", Work in Progress, January, 1999. [3] B. Rajagopalan, D. Saha, B. Tang, and K. Bala, "Signaling Framework for Automated Establishment and Restoration of Paths in Optical Mesh Networks," draft-rstb-optical-signaling-framework 00.txt, March, 2000 [4] L. Anderson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", Work in Progress, October, 1999. [5] 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. 9. Author's Addresses Z. Bo Tang Debanjan Saha Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Ocean Port, NJ 07757 Email: {btang, dsaha, braja}@tellium.com