Internet Draft Debashis Basak Expires: August, 2000 Marconi <draft-basak-mpls-oxc-issues-01.txt> Daniel O. Awduche UUNet (MCI WorldCom) John Drake Chromisys, Inc Yakov Rekhter Cisco Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Cross-connects 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 the domain specific enhancements required to adapt MPLS traffic engineering control plane constructs to control optical cross-connects 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 required enhancements to both OXCs and to existing MPLS traffic engineering control plane objects (routing and signaling protocols) to support the application to OXCs. Basak Expires August, 2000 [Page 1]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 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. The MPLS traffic engineering control plane has been shown to be an extensible general purpose control plane technology for a variety of data-centric network elements. For example, the MPLS control plane has been used previously in conjunction with data planes that have specific limitations e.g. ATM-LSRs and frame relay LSRs (FR-LSRs). The adaptation of MPLS traffic engineering control plane concepts to OXCs, which results in OXC-LSRs, needs to consider and reflect the domain specific peculiarities of the OXC data plane. This consideration was noted in [1], but details of the needed extensions were not provided. This memo describes a number of required domain specific enhancements that are necessary to map the MPLS traffic engineering control plane constructs to OXCs. Specifically, this memo describes required enhancements to OXCs and associated WDM devices to support incorporation of the MPLS traffic engineering control plane approach. Additionally, this memo discusses required extensions to the existing MPLS traffic engineering control plane constructs to better accommodate the needs of optical transport network elements. 2. Terminology and Definitions This section introduces terminology which is pertinent to the Multiprotocol Lambda Switching concept. We discuss the notions of termination-capable interfaces and termination-incapable interfaces, and a related concept of termination-incapable domain. A termination-capable (TC) interface on an LSR is an interface which is capable of terminating a label switched path (LSP) and subsequently demultiplexing the data carried by the LSP to make further routing/switching decisions. This definition does not pertain to management and control traffic destined for the LSR. A point-to- point interface terminating on an IP router that implements MPLS is an example of a TC interface. A termination-incapable (TI) interface is one which is incapable of Basak Expires August, 2000 [Page 2]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 terminating LSPs and demultiplexing the data carried by the LSPs to make further routing/switching decisions. A fiber connected to a pure OXC is an example of a TI interface. The definition of TI does not pertain to interfaces which terminate management and control traffic destined for the LSR. For a given bidirectional link, the interfaces associated with the endpoints of the link may be of different types with respect to their capability to terminate LSPs. For example, consider a link between a pure OXC and a (frame-based) LSR (e.g., an IP router); the interface with the OXC is TI while the interface with the frame-based LSR is TC. A single network element may simultaneously have both TC and TI interfaces. For example, it is easy to envision an optical device that switches traffic on some interfaces based on the wavelength or the optical channel trail through which the traffic was received, and switches traffic on other interfaces based on the label information carried by packets. It is also easy to envision a hybrid physical interface in which traffic on certain wavelengths or optical channel trails are forwarded based on the wavelength or optical channel trail through which the traffic was received, and traffic on other wavelengths or optical channel trails are forwarded based on the label information carried by the packets. Such physical interfaces may be considered as two separate logical interfaces, one TC and the other TI. If all the interfaces on an LSR are TI interfaces, then such an LSR will be referred to as a TI-LSR. A contemporary OXC-LSR which provides transit services for data traffic is an example of a TI-LSR (an ATM-LSR within the context of IP-over-ATM is another example of a TI-LSR). If an LSR has at least one TC interface, then such an LSR is referred to as a TC-LSR. A router that implements MPLS is an example of a TC- LSR. We now discuss the concept of a TI-LSR domain. A TI-LSR domain is a set of TI-LSRs which are mutually interconnected by TI interfaces. A transit optical transport network (OTN) composed of contemporary OXC-LSRs is an example of a TI-LSR domain. The Edge set of a TI-LSR domain is the set of TC-LSRs that 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 include client network elements and access Basak Expires August, 2000 [Page 3]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 devices that interconnect to the OTN. Figure 1 below depicts an illustrative 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 LSRs within a TI-LSR domain. LSPs can, however, start and terminate on TC-LSRs belonging to the Edge set of a T1-LSR domain as well as on devices situated beyond the edge set. _________________ 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: An illustrative 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 discussion contains a list of some basic required enhancements to OXCs and other WDM devices to support MPL(ambda)S: - There should be a mechanism to exchange control information between OXCs, and between OXCs and other LSRs. This can be accomplished in-band or quasi-in-band using the same links (fibers) that are used to carry data-plane traffic, or out-of-band via a separate network. A combination of in-band and out-of-band mechanisms may also be appropriate under certain circumstances. - An OXC must be able to provide the MPLS traffic engineering control plane with pertinent information regarding the state of individual fibers attached to that OXC, as well the state of individual ligthpaths or optical channel trails within each fiber. - An edge LSR might not have intrinsic WDM capabilities. Instead, Basak Expires August, 2000 [Page 4]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 it might interface to an external WDM device, using a suitable technology such as SONET, GigEthernet, etc. Even when an edge LSR does not have WDM capabilities, it should still have the capability to exchange control information with the OXCs in the domain. 4. Required Enhancements to the current MPLS control plane. This section describes some basic required enhancements to the MPLS traffic engineering control plane components (including ISIS/OSPF and RSVP) in order to support MPL(ambda)S. Part (A) of this section covers general enhancements while part (B) covers enhancements that are specific to the nesting of LSPs. A) General enhancements - An MPLS domain may consist of links with different properties depending upon the type of network elements at the endpoints of the links (e.g., some of links may interconnect OXCs, some links may interconnect frame-based LSRs and OXCs, while other links may interconnect frame-based LSRs). Within the context of Multiprotocol Lambda Switching, the properties of a link consisting of a fiber with WDM that interconnects two OXCs are different from the properties of a SONET link that interconnects two LSRs. For example, a conventional LSP cannot be terminated on a link connected to a pure OXC. However, a conventional LSP can certainly be terminated on a link connected to a frame-based LSR. These differences should be taken into account when performing path computations to determine an explicit route for an LSP. Additionally, since the performance characteristics of an LSP will depend on the characteristics of the links traversed by the LSP, it may be useful to have the capability to restrict the path of some LSPs to links with certain characteristics. The concept of resource class attributes defined in [2] is one approach to accomplish this containment, but other mechanisms may also be feasible. Thus, for example, it may be desirable for an IGP to carry information regarding whether a particular link is TC or TI. Path computation algorithms may then take this information into account when computing paths LSPS. - In certain contexts there may be multiple control channels and bearer channels between a pair of adjacent OXCs. Procedures are needed, therefore, to associate control Basak Expires August, 2000 [Page 5]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 channels to bearer channels in such circumstances. Furthermore, if a control channel is associated with multiple bearer channels, then procedures are required to demultiplex the control traffic for different bearer channels. Procedures are also needed to activate and deactivate bearer channels, to verify proper operation of bearer channels, and to assign bearer channels to an LSP during the process of LSP establishment. The procedures needed to accomplish the objectives include the following aspects: a method to identify the bearer channels associated with any given physical link, methods to identify spare bearer channels for protection purposes (e.g., 1+1, 1:1, and 1:N protection schemes), and methods to identify an impaired bearer channel -- especially in the situation where the physical links carrying the bearer channel are not impaired. - To perform the signaling function in Multiprotocol Lambda Switching networks, RSVP should be extended with Objects, such that when used in conjunction with available information propagated through the IGP, the RSVP Objects will be able to provide sufficient details to establish reconfiguration parameters for OXC switch elements. - When a pair of OXCs are directly connected by multiple links (fibers), an IGP needs to carry information about the physical diversity of the fibers. - Because conventional LSRs and OXCs may support different granularities of bandwidth allocation, an IGP should be able to distribute information regarding the allocatable bandwidth granularity of any particular link. This information should allow multiple granularities within a single link. It should also allow different granularities per priority. Additional requirements which may be imposed by OXCs that cannot perform wavelength translation are outside the scope of this document. B) As indicated in reference [1], the capability to aggregate LSPs through the notion of nested LSPs is an important aspect of using the MPLS traffic engineering control plane with OXCs. Using the MPLS traffic engineering control plane, several methods can be used to implement nested LSPs. One way to accomplish this is to have a single MPLS traffic engineering control plane instance for both conventional LSRs and OXCs, but to allow the control plane to treat subsets of the LSPs as links Basak Expires August, 2000 [Page 6]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 for the purpose of establishing new LSPs (by the same control plane). In this way, the MPLS traffic engineering control plane could use an LSP (which it had previously instantiated) as a link to establish a new LSP. In principle, this technique can be applied recursively to form several depths of LSP nesting. Another way to accomplish LSP nesting is to have more than one instance of the MPLS traffic engineering control plane, and to allow LSPs created by one instance of the control plane to be used as links by another instance of the control plane. In general, irrespective of whether a single instance of the MPLS traffic engineering control plane is used, or whether multiple instances are used, the LSPs that serve as links for other LSPs could be established by: (a) methods outside the scope of the MPLS traffic engineering control plane (e.g., by administrative configuration), or (b) via the MPLS traffic engineering control plane. The following paragraphs present a list of required enhancements to the MPLS traffic engineering control plane components (ISIS/OSPF and RSVP) in order to support the capability to aggregate and nest LSPs in MPL(ambda)S: - The LSP setup procedures should include support for an LSR at the edge of a TI-LSR domain to aggregate multiple LSPs coming from outside of the TI-LSR domain into an LSP that consists of an optical channel trail. - An LSR should be able to advertise into an IGP a link that is formed from an LSP originated by the LSR, The IGP should be able to advertise the link state for such links. The link state information can be used subsequently for path computations for other LSPs. - In scenarios with more than one instance of the MPLS traffic engineering control plane, one instance of the control plane should be able to advertise LSPs created and maintained by that instance as links to another instance of the MPLS traffic engineering control plane. The instances of the control plane may reside on the same network element or on different network elements. It should be noted that the capability to aggregate LSPs through nesting may be useful in contexts outside of the OXC environment. Therefore the required enhancements specified above to support aggregation of LSPs through nesting should be implemented Basak Expires August, 2000 [Page 7]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 in a manner such that they remain applicable in conventional non-OXC environments. The detailed specification of the enhancements to the MPLS traffic engineering control component to support the MPL(ambda)S concept will be covered in a supplementary 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. [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 Basak Expires August, 2000 [Page 8]
Internet Draft draft-basak-mpls-oxc-issues-01.txt Feb 2000 [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) 22001 Loudoun County Parkway Ashburn, VA 20147 Phone: 703-886-5277 Email: awduche@uu.net John Drake Chromisys, Inc Phone: (408) 738-4194 x252 Email: jdrake@chromisys.com Yakov Rekhter Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: yakov@cisco.com Basak Expires August, 2000 [Page 9]