Internet Draft Debashis Basak Expires: July, 2000 Marconi Daniel O. Awduche UUNet (MCI WorldCom) John Drake Marconi Yakov Rekhter Cisco Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Crossconnects 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. Abstract This document describes domain specific enhancements needed to adapt MPLS traffic engineering control plane constructs to control optical crossconnects in emerging automatically switched optical transport networks. These enhancements are within the framework of Multiprotocol LAMBDA switching proposed in [1]. Specifically, this memo investigates the behavior of the MPLS based control plane technique for OXCs, and identifies enhancements required to both OXCs and to existing MPLS control constructs (routing and signaling protocols) to support the application to OXCs. Basak Expires July, 2000 [Page 1] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 1. Introduction Recently, a new paradigm for the design of control planes for OXCs intended for data-centric automatically switched optical transport networks was proposed in [1]. This new paradigm is termed Multiprotocol Lambda Switching and exploits recent advances in MPLS traffic engineering control plane technology to foster the expedited development and deployment of a new class of versatile OXCs that specifically address the optical transport needs of the Internet. This memo describes a number of domain specific enhancements required to map the MPLS control plane constructs to OXCs. The memo describes enhancements to OXCs and WDM devices to the support MPLS based control plane approach. It also discusses extensions to the existing MPLS control plane constructs to better accommodate the needs of the optical transport network elements. 2. Definitions The MPLS control plane has been used (adapted) earlier in conjunction with data planes with specific limitations e.g. ATM-LSRs, FR-LSRs. The adaptation of MPLS control plane to OXCs, resulting in OXC-LSRs, needs to consider specific limitations of the OXC data plane, as identified in [1]. This section presents some definitions that take into account such peculiarities of the OXC data plane. A termination-capable (TC) interface on a label switching router (LSR) is one which is capable of terminating an LSP and demultiplexing data carried by the LSP to make further routing/switching decisions. A point-to-point interface terminating on a router that implements MPLS is an example of a TC interface. A termination-incapable (TI) interface is one which is incapable of terminating LSPs and demultiplexing data carried by the LSP to make further routing/switching decisions. Thus, an LSP incoming on a TI interface of a network device cannot be carrying data destined to different egress points of the device. A fiber connected to an OXC is an example of a TI interface. For a given unidirectional link the interfaces associated with the link's endpoints may be of different types with respect to their ability to terminate an LSP. For example, for a link from a (frame- based) LSR (e.g., router) to an OXC, the interface with the OXC is TI while the one with the LSR is TC. The property of TI or TC is associated with the head of a link, as well, because in a given MPLS Basak Expires July, 2000 [Page 2] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 box it may be possible for an LSP to come in through one interface, be switched across the box, and then terminated at the far end (at the head of a link). If all the interfaces of an LSR are TI interfaces, we'll refer to such an LSR as a TI-LSR. An OXC-LSR today is an example of a TI-LSR (an ATM-LSR is another example of a TI-LSR). If an LSR has at least one TC interface, we'll refer to such an LSR as TC-LSR. A router that implements MPLS is an example of a TC-LSR. A single box may have TC and TI interfaces. For example, one could imagine an optical box that on some interfaces forwards data based on the wavelength/optical trail the data was received and on other interfaces based on the label information carried by packets. One can also envision a hybrid physical interface in which data on certain wavelengths/optical trails is forwarded based on the wavelength/optical trail the data was received and on other wavelengths/optical trails based on the label information carried by packets. Such physical interfaces may be considered as two separate logical interfaces, one TC and the other TI. A TI-LSR domain is a set of TI-LSRs which are mutually interconnected by TI interfaces. An OTN made of a mesh of today's OXC-LSRs is an example of a TI-LSR domain. The Edge set of an TI-LSR domain is the set of TC-LSRs which are interconnected to members of the domain by links with a TC interface on a TC-LSR and a TI interface on a TI-LSR. A TC-LSR which is a member of an Edge set of a TI-LSR domain is called an Edge LSR. Examples of Edge LSRs are access devices to an OTN. Figure 1 below depicts an example network with a single TI-LSR domain consisting of OXCs (O1 through O8) surrounded by an Edge set of TC-LSRs consisting of access routers (M0 through M4). By definition LSPs cannot start/terminate on the LSRs within a TI-LSR domain. LSPs can start/terminate at TC-LSR belonging to the Edge set or beyond. Basak Expires July, 2000 [Page 3] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 _________________ M0---/--O2-----O9 \ / / \ \ M1--|--O1 --O3--O4---O6-|---M3 \ \ / / M2--\--O5 -- O7 --O8--/---M4 \_______________/ TI-LSR domain Mk: A TC-LSR (access routers), Ox: A TI-LSR (OXC) Figure 1: A sample network with a TI-LSR domain surrounded by an Edge set of TC-LSRs. 3. Required Enhancements to OXCs and WDM devices to support MPLS The following contains the list of required enhancements to OXCs and other WDM devices to support MPL(ambda)S: - there should be a way to exchange control information between OXCs, either using the same links (fiber) that is used to carry data, or via a separate network. - an OXC must be able to provide the MPLS control plane with the information about the state of individual fibers attached to that OXC, as well as with the state of individual ligthpaths within each such fiber. - an edge LSR may not have build-in WDM capabilities, but rather may use external WDM device that acts as SONET-to-WDM multiplexor/demultiplexor. That still should allow that LSR to exchange control information with the OXCs. 4. Required Enhancements to the current MPLS control plane. The section describes enhancements to the MPLS TE control component (ISIS/OSPF and RSVP) in order to support MPL(ambda)S. The required enhancements are divided into two sets (A) and (B). A) The first set concerns enhancements to adapt to the peculiarities of OXCs: Basak Expires July, 2000 [Page 4] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 - the RSVP Label Object, in combination with already available IGP and RSVP information, should be able to provide sufficient information to program cross-connect matrix on OXCs. - when a pair of OXCs are connected by multiple links (fibers), an IGP needs to carry information about physical diversity of the fiber. - since bandwidth allocation on an OXC is discrete, an IGP should be able to carry the information about bandwidth granularity of a particular link. This information should allow support for multiple granularities within a single link, as well as for different granularities per priority. Additional requirements imposed by OXCs that can't perform wavelength translation are outside the scope of the discussion in this document. B) As indicated in [1], essential to the use of MPLS with OXCs is the ability to aggregate LSPs by using the notion of "nested" LSP. MPLS allows several ways to implement nested LSPs. One way to accomplish this is to have a single MPLS control plane, but allow this control plane to treat some of the LSPs created and maintained by the control plane as links for the purpose of establishing new LSPs (by the same control plane). That is the MPLS control plane could use an LSP as a link to form another LSP, and that other LSP, in turn, could be used as a link to form some other LSP, etc... Another way to accomplish this is to have multiple instances of the MPLS control plane, and allow LSPs created by one instance of the control plane to be used as links by some other instance of the control plane. Regardless of whether one uses a single or multiple instances of the MPLS control plane, the LSPs that are used as links could be established by either (a) means outside of the MPLS control plane (e.g., by configuration), or (b) by means of the MPLS control plane itself. The following contains the list of required enhancements to the MPLS TE control component (ISIS/OSPF and RSVP) in order to support the ability to aggregate LSPs in MPL(ambda)S: Basak Expires July, 2000 [Page 5] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 - an IGP should carry information about whether a particular link is termination capable (TC) or not (TI). OSPF should be able to take this information into account when computing paths for optical trails. - the LSP setup procedures should include support for an LSR at the edge of TI-LSR domain to aggregate multiple LSPs coming from outside of the TI-LSR domain into an LSP that is an optical trail. - an LSR should be able to advertise into an IGP a link that is formed out of an LSP originated by the LSR, and SPF/OSPF procedures should be able to use such a link for path computation. - one instance of MPLS should be able to present LSPs created/maintained by that instance as links to another instance of MPLS. The two instances may reside either on the same, or on different devices. Note that the ability to aggregate LSPs by nesting may be useful outside of the OXC environment as well. The enhancements specified above in support of aggregate LSPs have to implemented in such a way as to allow non-OXC environments. The specifications of the enhancements to the MPLS TE control component in support of MPL(ambda)S will be covered in a supplimentary document to follow. 5. Security Considerations Security considerations are for future study. 6. References [1] D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", Internet Draft, Work in Progress. [2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC-2702, September 1999. Basak Expires July, 2000 [Page 6] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 [3] D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE Communications Magazine, December 1999. [4] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, and V. Srinivasan, "Extensions to RSVP for LSP Tunnels," Internet Draft, Work in Progress, 1999 [5] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP," Internet Draft, Work in Progress, 1999 [6] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A. Viswanathan, "A Framework for Multiprotocol Label Switching," Internet Draft, Work in Progress, 1999 [7] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," Internet Draft, Work in Progress, 1999 [8] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," Internet Draft, Work in Progress, 1999 [9] H. Smith and T. Li, "IS-IS extensions for Traffic Engineering," Internet Draft, Work in Progress, 1999 [10] D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF," Internet Draft, Work in Progress, 1999 7. Author's Addresses Debashis Basak Marconi 1000 FORE Drive Warrendale, PA 15086-7502 Phone: 724-742-7026 Email: dbasak@fore.com Daniel O. Awduche UUNET (MCI WorldCom) Loudoun County Parkway Ashburn VA Phone: 703-886-5277 Email: awduche@uu.net John Drake Marconi 1000 FORE Drive Warrendale, PA 15086-7502 Basak Expires July, 2000 [Page 7] Internet Draft draft-basak-mpls-oxc-issues-00.txt Jan 2000 Phone: 724-742-6798 Email: drake@fore.com Yakov Rekhter Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: yakov@cisco.com Basak Expires July, 2000 [Page 8]