Internet Draft Murali Krishnaswamy Leah Zhang Antonio Rodriguez-Moral Photuris Inc. Expires August 2001 22 February 2001 Lightpath Route Extensions to RSVP-TE for optical channel connection setup 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. 1. Abstract We propose an extension to RSVP-TE [1][2]that would permit setting up OCh (optical channel) connections whose paths form a topology that is independent of the control layer topology. This separation of an OCh connection path and the associated control layer network may be necessary for many reasons. First, it may not be possible to provide a control channel connection to each one of an optical network element (ONE)'s neighbor - for many reasons explained in Sec. 2. (ONE as used in this draft includes optical cross-connect (OXC), optical add-drop multiplexer (OADM) or even optical terminal multiplexer (OTM). Secondly by providing the means to signal OCh connections through different multiple control paths, we achieve network resilience against control channel failure. We propose a new Krishnaswamy, et al. [Page 1] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt extension to RSVP-TE called Lightpath Route Object (LRO) which is a list of nodes along OCh connection path. This is carried in the Path message by RSVP-TE as an Opaque Object for interpretation and use by the optical nodes. This facilitates setting up OCh connections between nodes that have no adjacency at the IP layer. 2. Introduction OCh connections can be setup using a signaling scheme similar to those proposed in the Generalized MPLS signaling drafts [3][4]. Due to the multiple influencing parameters, the end-to-end path for OCh connections is always predetermined and signaled as ERO using RSVP- TE. An implicit (and required) assumption in such cases is that, the OCh path aligns with the control path. This OCh and control path association is necessary as RSVP-TE requires IP adjacency. Further the proposed OSPF extensions to support MPlambdaS [5] and the opaque TE extensions in general [6], advertise only those TE parameters (both control and OCh) that are specific to that control channel (link). (Note: Even if an OCh connection that doesn't belong to a particular link is advertised over that link, still there is no way of signaling an OCh path that is different from the control path (ERO). Control Channel ++++++++++++++ +-------+ ++++++++++++++ + -------------| A |------------- + + | | | OCh-Ring-1 | + + | --------- | | --------- | + + | | +-------+ OCh-Ring| | + + | | -2 | | + +-------+ +-------+ | D |-------------------------| B | | | | | +-------+ +-------+ + | | + + | | + + | +-------+ | + + |------------| C |------------| + +++++++++++++++| |+++++++++++++++ +-------+ Fig. 1 - Multiple Rings. OCh-Ring 1 - A-B-C-D OCh-Ring 2 - A-B-D (No control channel between B-D) This dependency makes it impossible to set up OCh connections between two nodes if they have no adjacency at the IP layer - ie. if there is no control channel between them (B-D in Fig.1). Hence a network Krishnaswamy, et al. [Page 2] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt operator can't configure and offer ring configurations similar to OCh-Ring-2. Thus this control/OCh layers topology association puts limitations in the deployment and features that can be offered by a network operator. Some of the reasons for not providing control channel between adjacent nodes are: o Since the control channels are terminated in each node, optics/hardware architecture may limit the total number of con- trol channels in an optical node. This may be especially true in a low cost access/metro WDM system or in highly meshed network. o Where an out-of-fiber separate control channel (eg. ethernet) is deployed, it is difficult to colocate the controls channel along all of the optical paths. A more compelling reason for LRO is the case of optical ring networks where a network operator would typically prefer to setup "short side" connections even in the event of the control channel failure along this path (Fig. 2). As the control channel uses a separate wave- length, for eg. its transmitter/receiver could fail, while all the other wavelengths (that carry user data) remain unaffected. One less obvious disadvantage of a long side connection is that it could increase the blocking probability for future wavelength allocations. +-------+ Control Channel Failure +++++++++++++++| A |+++++++++ X X X + ----------| |---------- X + | +-------+ OCh | X + | | + + | | + +-------+ +-------+ | D | | B | | | | | +-------+ +-------+ + | | + + | | + + | +-------+ | + + ----------| C |---------- + +++++++++++++++| |+++++++++++++++ +-------+ Fig. 2 - Control Channel Failure between A-B Krishnaswamy, et al. [Page 3] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt When the control channel between A and B fails, it is not possible to setup short side (A-B) OCh connections between A and B using RSVP-TE even though the data channels between them remain unaffected. With LRO extensions we would be able to signal and setup the short side A- B OCh connection (by specifying LRO as A-B) while letting the control message go through the longer path A-D-C-B (or B-C-D-A). Note: Link Management Protocol [7] proposes protection control chan- nels for maintaining link connectivity. The protection control chan- nel takes over when the primary one fails. However such proposals may not be feasible in many systems for architectural and economic reasons. 3. Lightpath Route Object (LRO) Owing to the above reasons we propose an extension to RSVP-TE called Lightpath Route Object and this is a list of the nodes in the OCh connection path. LRO is carried in the Path message and is treated as an Opaque Object by RSVP-TE. It is up to the applications on the nodes to use the path information in LRO to set up the OCh connec- tions. RSVP-TE (control path) itself follows the ERO path only. The lightpath routes are specified by the LIGHTPATH_ROUTE object (LRO). 3.1 Path Message The format of the Path message is as follows: ::= [ ] [ ] [ ] [ ] [ ... ] ::= [ ] [ ] The relative placement of LIGHTPATH_ROUTE object is simply a Krishnaswamy, et al. [Page 4] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt recommendation. The ordering of the objects is not important, so an implementation MUST be prepared to accept objects in any order. We define a new Lightpath route class = 22 (check), c_type = 1. 3.2 LIGHTPATH_ROUTE Format LIGHTPATH_ROUTE has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of an LIGHTPATH_ROUTE object are a series of variable- length data items called subobjects. Each subobject has the form: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ L The L bit is reserved. Type The Type indicates the type of contents of the subobject. Currently defined values are: 0 Reserved 1 IPv4 prefix 2 IPv6 prefix Length The Length contains the total length of the subobject in bytes, including the L, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4. Krishnaswamy, et al. [Page 5] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt Two Subobjects are defined - for IPv4 and IPv6. Subobject 1: IPv4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit is reserved. Type 0x01 IPv4 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8. IPv4 address An IPv4 address (of the optical node). Padding Zero on transmission. Ignored on receipt. Subobject 2: IPv6 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Krishnaswamy, et al. [Page 6] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt L The L bit is reserved. Type 0x02 IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20. IPv6 address An IPv6 address (of the optical node). Padding Zero on transmission. Ignored on receipt. 4. LRO and ERO Though LRO is an Opaque object as far as RSVP-TE is concerned, a few guidelines are provided regarding its usage and its co-existence with ERO. o First of all to help implementation LRO is defined such that its format is similar to ERO. o When the RSVP-TE message has no LRO, then the optical nodes must use the path specified in the ERO for the OCh connection. o When the RSVP-TE message carries LRO, then the optical nodes must use the path specified in the LRO for the OCh connection. o The LRO nodes must be a sub-set of the ERO nodes. o The source and destination nodes of the LRO and ERO must be the same. o On an implementation note a source node must reject a connection request if the above two requirements are not satisfied. 5. Label operation in the presence of LRO Krishnaswamy, et al. [Page 7] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt In switched optical networks the labels carried in the Resv message are generally encoded to represent the WDM channels or lambdas that have been selected by the downstream neighbors. In cases where the LRO is not the same as ERO (normally this should be the case as oth- erwise no LRO is required), the label allocation and usage is slightly different. When LRO is specified, those intermediate nodes which are not a part of LRO (non-LRO nodes) must generate "dummy" or some "pre-assigned" labels that are recognized by LRO nodes. (A node determines if it is a LRO or non-LRO node by looking in to the PSB). Only the LRO nodes generate valid labels useful for setting up OCh connections. If a LRO member node upon receiving the Resv message, finds that the top label is a dummy one, it must then ignore that and look down in to the stack till it finds a valid label. (This label will obviously correspond to that of its predecessor LRO node). It is this label that a LRO node must use for setting up OCh connections. Note: This draft doesn't modify the RSVP-TE behavior. 6. Security Considerations This draft doesn't raise any security considerations. 7. References [1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, September 1997. [2] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, August 2000. [3] Ashwood-Smith, P. et. al., "Generalised MPLS - Signaling Func- tional Description", Internet Draft, draft-ietf-mpls-generalised- signaling -00.txt, October 2000. [4] Ashwood-Smith, P. et. al., "Generalised MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalised-rsvp-te -00.txt, November 2000. [5] Kompella, K. et. al., "OSPF Extensions in Support of MPL(ambda)S", Internet Draft, draft-kompella-ospf-ompls-extensions-00.txt, July 2000. Krishnaswamy, et al. [Page 8] I.D. draft-krishnaswamy-optical-rsvp-extn-00.txt [6] Katz, D. et. al., "Traffic Engineering Extensions to OSPF", Inter- net Draft, draft-katz-yeung-ospf-traffic-03.txt, September 2000. [7] Lang, J. et. al., "Link Management Protocol [LMP]", Internet Draft, draft-lang-mpls-lmp-02.txt, July 2000. 8. Authors' Addresses Murali Krishnaswamy, Leah Zhang, Antonio Rodriguez-Moral Photuris Inc. 20 Corporate Place South Piscataway NJ 08854 Tel: +1 (732) 465 1000 x1220, x1252, x1343 Fax: +1 (732) 465 1010 E-mail: murali, lzhang, arodmor@photuris.com Krishnaswamy, et al. [Page 9]