Internet Draft MPLS Working Group Murali Krishnaswamy Internet Draft George Newsome Joe Gajewski Antonio Rodriguez-Moral Lucent Technologies Stephen Shew Michael Mayer Nortel Networks Expires August 24 2000 25 February 2000 MPLS control plane for Switched Optical Networks <draft-krishnaswamy-mpls-son-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. Krishna MPLS control plane for Switched Optical Networks [Page 1] Internet Draft February 2000 Abstract The advent of switched multi-channel (WDM) optical networks using OXCs (Optical Cross-connects) presents many new opportunities for supporting faster and more flexible provision of IP services. Key to realizing such opportunities is providing the ability to automatically set-up and tear-down paths (optical channels) across the optical network, and provide means for IP services to leverage this capability. Therefore, it is necessary to establish supporting protocols and mechanisms. In this draft we study the requirements and mechanisms for optical network topology discovery, signaling path setup, data path computation, and optical channel set-up. We leverage MPLS and other IP based protocols as a basis for achieving the above objectives. 1. Introduction Within an optical transport network (OTN), OXCs switch optical channels, analogous to how routers switch packets in an IP network. However, there are a number of differences, such as bandwidth granularity, which is much coarser for an OXC than that for an IP router. Additionally, routers need to inspect each IP packet for route computation. Even when a LSP is setup, the routers still need to inspect ingress traffic and perform label swapping operations. On the other hand, OXCs operate on per optical channel (wavelength) basis, and there is no equivalent IP packet routing or label swapping operation involved (Optical Label Switching). Instead the entire traffic on any optical channel at an ingress port in an OXC (or networks) is switched to an egress port. This optical channel can be carrying any client payload traffic type and rate and is totally transparent as far as the OXC is concerned. The second difference between an "OXC switched path" and a LSP is the frequency of path set-up/tear- down requests and the duration of the connection. In an OXC network, because of the high bandwidth nature of each connection, one would expect them to persist for a much longer duration and involve relatively infrequent connection set- up/tear-down requests when compared to per packet routing operations. This has an important bearing on path signaling requirements. Strongly connected to this is the difference in resource cost of establishing a LSP as opposed to establishing a connection in the optical layer. When an LSP is established, the only resource consumed is the storage necessary to specify the label mappings. When a circuit is established, the entire capacity of that circuit is removed from the available capacity in the network. This leads to the observation that LSP's can be quickly established, perhaps as a Krishna MPLS control plane for Switched Optical Networks [Page 2] Internet Draft February 2000 response to a single packet, and can be held at little cost to see whether future traffic makes it worthwhile to keep the LSP up. In contrast, a high capacity circuit is unlikely to be established without a priori knowledge of substantial traffic being available for this circuit. For this reason, the means of deciding to establish a circuit is likely to be very different from the means of deciding to establish an LSP. [1] and [2] clearly spell out the need for automating the setup of an end-to-end optical channel connection. The needs expressed in [1] and [2] have been elaborated with some architectural considerations and published as [3]. This document has been approved by the USA to communicate current work in the US to ITU-T SG13, which currently controls Optical Transport Network architecture and requirements. [4] discusses in detail the role of MPLS [5, 6, 7] as a control plane for the management of OXCs. 2. Optical IP Networking Scenario Fig. 1 shows an optical IP network with optical line systems (consisting of multiplexers and demultiplexers) and OXCs, with subtending IP switch routers. The figure shows LSRs (Label Switched Routers) connected to the OXCs by both single channel and multi- channel networks. Note that the single connection between the LSR (Optical Transport Network client) and OXC (OTN) actually represents two connections, one which will eventually carry the high rate traffic, and a much lower rate one that provides IP access to optical network services (e.g., signaling to trigger optical channel connection set-up). Note: The LSRs have two functions - the first is to aggregate IP traffic on a coarse scale into a few number of LSPs - the second is to setup optical channel connections for the data paths. Krishna MPLS control plane for Switched Optical Networks [Page 3] Internet Draft February 2000 +-----+ +-----+ | | | | | LSR | | LSR | +-----+ +-----+ \\\ / \\\ +----+ \\\ |OMD | \\\ +----+ \\\ /// +-------+ | | +----+ +----+ | | +----+ +----+ | | | |-----| |------| | | | |OMD |-----|OMD |-----| OXC |------|OMD |------|OMD | | | | |-----| |------| | | | +----+ +----+ | | +----+ +----+ ||| | | ||| ||| +-------+ ||| ||| ||| ||| ||| ||| ||| +-------+ +-------+ | | +----+ +----+ | | | |-----| | | |------| | | OXC |-----|OMD |-----------------|OMD |------| OXC | | |-----| | | |------| | | | +----+ +----+ | | +-------+ +-------+ /// \\\ /// \\\ /// +----+ /// +----+ /// | OMD| /// | OMD| /// +----+ /// +----+ /// \ /// \ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | LSR | | LSR | | LSR | | LSR | +-----+ +-----+ +-----+ +-----+ ----- Multi-channel (WDM) connection ----- ----- Single-channel connections (Multiple fiber) ----- OMD - Optical Multiplexer/Demultiplexer Fig. 1 - Optical IP Network with OXCs and Label Switch Routers Krishna MPLS control plane for Switched Optical Networks [Page 4] Internet Draft February 2000 As the bandwidth for carriage of IP services increases beyond 10 Gb/s, one would expect to see more bandwidth routed and processed at an optical channel level of granularity (via OXCs) and less processed at the IP level (via routers). Thus, we should expect to see an evolution from purely IP router based networking towards a mixture of router and circuit switched networking. 3. IP and Optical Network Signaling Distinctions +-------+ +-------+ | | | | +-----+ SCI | | SC | | SCI +-----+ | |____________| |_____________| |_______| | | | | OXC | | OXC | | | | LSR |------------| |-------------| |-------| LSR | | |------------| |-------------| |-------| | | |------------| |-------------| |-------| | | | DC | | | | | | +-----+ | | | | +-----+ +-------+ +-------+ SC - Signaling channel SCI - Signaling channel Interface DC - Data channels (customer traffic)) Fig. 2 - Signaling channels and interfaces In a router based IP network there is no physical separation of the data and control (signaling, routing etc.) path. Both flow on the same link (or channel in a WDM network) and the topology of the signaling network is identical to that of the traffic network. Referring to Fig. 2 we see that in an OTN network a separate signaling channel may be required. This signaling channel carries information necessary to setup the data paths, but the actual paths taken by a signaling and data connection between the same source/destination pair could be different. In any case there is no physical constraint forcing or ensuring this identity. This is an important issue especially when considering OTN network restoration requirements. Hence in a meshed optical network, which may not be fully interconnected, the signaling protocol must be capable of setting up a data path that is different from the signaling path topology. Krishna MPLS control plane for Switched Optical Networks [Page 5] Internet Draft February 2000 Thus, we need to talk in terms of two different network topologies, one for the signaling infrastructure and the other for data carried on optical channels within the OTN. Within the OTN, the signaling channels are terminated at each OXC (just as in a router based network) as they carry information regarding network connection set- up (and tear-down). The data channels are, however, end-to-end optical channels with no termination points in the middle of the OTN. 4. Connection setup details in a switched optical network There are three fundamental steps involved in setting up a connection in a switched optical network. A. OXC signaling network topology discovery and signaling path setup B. OXC traffic adjacency and port interconnection discovery C. Data path computation Note: The connection setup above is generally called the primary path (also called the working path), meaning the path along which data will flow under normal conditions for a source/destination address/port. For network survivability reasons, alternate restoration path(s) for the primary paths need to be computed and allocated. These may be pre-computed or calculated and allocated dynamically. When the primary path fails for whatever reason, a fault is triggered and automatic switching onto the restoration path takes place. This restoration path may be 1+1, meaning it is dedicated for a particular primary path only, or this may involve restoration resources shared among several primary paths. In the later case contentions may arise and a priority based reservation scheme may be needed. 5. OXC network topology discovery and Signaling path setup To discover the network topology, the OXC control plane (but not necessarily all OXC's) must be associated with a routing function. This routing function may be built-in to an OXC or can be a separate equipment, with necessary i/o connections to one or more OXC controllers. The DCN (Data Communications Network) can be a part of the OTN embedded communications channel (Optical Supervisory Channel) or a dedicated wavelength could be allocated for this purpose. In this regard, the OTN would be no different than any other circuit switched network using traffic capacity to provide a signaling network. The DCN could also be an out-of-band LAN. A link state routing protocol like OSPF can be used for calculating the best path between destinations. Krishna MPLS control plane for Switched Optical Networks [Page 6] Internet Draft February 2000 When the number of nodes (OXC) becomes large, hierarchical partitioning of the network will be necessary to ensure that routing can be scaled up. This DCN routing protocol is only for setting up the signaling paths between the OXCs, and this protocol instance should not be confused with different instances of the same protocol handling the OTN traffic network topology, or for that matter, the topology of the IP client network. 6. OXC adjacency and port interconnection discovery It is essential for the adjacent OXCs to have knowledge of how the ports (or wavelengths) are interconnected between them. While not desirable in the long run this could be manually provisioned or a separate protocol (or instance of it) to disseminate the port mapping information could be run. (This protocol will be a part of a future submission.) In either case a port map table is maintained in each OXC. This table is consulted and updated while setting up and tearing down data connections. Fig. 3. +-----+ +-----+ | |-----| | | |1 1| | | | | | | OXC |\ | OXC | | A |2\ | B | | | \ | | | | \ | | | | 6\| | | |\6 | | +-----+ \ +-----+ \ \ +-----+ 1\| | | | | | | OXC | | C | | | | | | | +-----+ Krishna MPLS control plane for Switched Optical Networks [Page 7] Internet Draft February 2000 Adjacent Local Port Remote Port Link Availability OXC Status B 1 1 y B 2 6 n C 6 1 y Fig. 3 - OXC Adjacency and Port Interconnection Table (For OXC A) Note: Link Availability Status indicates whether the link is available for a new connection request or not. Fig. 3 shows the port interconnection table for an OXC marked A. Hence a selection of a particular data path depends on the availability of wavelengths. Additionally an administrative cost could be assigned to each port and this could be an additional selection criteria. Where no wavelengths are available, the link connection between the two OXCs is not possible. Note: In order to avoid the need to signal the existence of every optical channel, which in the circuit switched world is called a link connection, we may aggregate link connections into links, where a link is the collection of link connections that are equivalent for the purpose of routing. This equivalence for the purpose of routing may include attributes for link connection rate or geographically diverse routing, so two OXCs may have more than one link between them. This leads to the notion that link capacity should be exchanged so that traffic can be routed in such a way as to balance traffic on the various links in the network. 7. Optical Channel connection setup - Two types of networks In this draft we study the mechanisms of setting up optical channel connections for two networking situations. The first is the case of a CPE (Customer Premises Equipment) connected to OXCs through dark fibers - a simple scenario wherein only the networking of OXCs need to be taken in to consideration without any regard to client payload, in setting up an optical channel connection. The second is the complex case of CPEs (routers in this case) networked to OXCs through LSRs. This requires a careful Krishna MPLS control plane for Switched Optical Networks [Page 8] Internet Draft February 2000 network topology layout and policy based routing is required. 8. CPE networking to OXCs by dark fibers In this scenario a CPE is connected to the OXC network by a dark fiber or even by a lambda (wavelength). The client may require of the service provider to route the traffic transparently over the OXC network - without ever looking in to the payload - this may be due to highly sensitive data, client VPN, non-standard protocols etc. Under such cases, the ingress and egress OXC nodes need to be pre- computed and arranged with the client. Thus this is the case of setting up optical channel connections between the ingress and egress OXCs. There are no LSRs. A routing protocol like OSPF discovers the OXC network topology. In the simple case the optical channels connection follow the signaling (route) path. Hence we need explicit routing to balance traffic and meet other traffic engineering considerations. CR-LDP [8] or RSVP with EXPLICIT ROUTE and LABEL REQUEST Objects [9] could be used to setup the path connections. 8.1 The role of MPLS On receiving a Label Request Message the egress OXC finds the right label to be carried in the Label Mapping Message (or RESV message in RSVP) to its upstream OXC. This label has much significance to the optical network. as it is derived from the OXC Adjacency and Port Interconnection Table in Fig. 3. Thus a label selected is a representation of the OXC port selected for setting up the optical channel connection. Once the MPLS LSP is determined, cross-connects are made completing the optical channel connection setup. If the connection request fails due to lack of resources at any particular node, then a special label that represents the node id and reason thereof could be sent upstream to the ingress OXC. The ingress OXC may try a new explicit path that will not include the problem node. 9. Client networking to OXCs by LSR However a more typical scenario is the case where traffic from one or more client network are input to the service provider's OXC network. Krishna MPLS control plane for Switched Optical Networks [Page 9] Internet Draft February 2000 The traffic then needs to be routed over the OXC network. This involves introduction of LSRs and several additional steps (and policies) on the part of the service provider. Primary to this, the need to separate the networking topologies of the optical networking elements like OXCs and the services (IP) they carry must be understood. 9.1 Need for separation of optical transport and service layer topologies and Control There are many compelling reasons to have separate network topologies, whether it is physical or logical for the OTN and the service layer. Most important, perhaps, is that these two layers are likely to be under different administrative controls (or ownership) and policies. Under such circumstances the service provider who owns the OTN will wish to maintain full control of his network. Such an operator would not wish to give a client insight into the structure of the OTN layer as this is his business value. Apart from this strong need to protect a business value, there is no client service which would depend on having a view of the internal structure of the OTN. Three examples have been suggested. The first involves a pair of connections diversely routed for restoration purposes. The second involves a connection required at a future time, while the third involves being able to know which LSR's can be reached via the OTN. (This is somewhat similar to the VPN neighbor discovery problem) The first two examples are met by correct OTN interface design, in which appropriate parameters convey the constraint desired. The third sounds more attractive than it really is. The definition of a network is the set of enties that are interconnectable, so the LSRs that are reachable via the OTN is the set of all LSRs connected to the OTN. In a large network, this list could be extremely long and a subset of all LSRs is what's probably meant. This need seems to be better met by directories (or brokers) than by exposing the inner details of the OTN. Krishna MPLS control plane for Switched Optical Networks [Page 10] Internet Draft February 2000 9.2 Networking of CPE routers through OXC networks +----+ |LSR | -----------------| A |-------------- | +----+ | | || | | || | | || | | +----+ | | | OXC| | | | | | | +----+ | | ~ ~ | | ~ ~ | | ~ ~ | +----+ +----+ +----+ +----+ |LSR |======| OXC| | OXC|======|LSR | | B | | |~~~~~~~| | | C | +----+ +----+ +----+ +----+ | | | | | | ------------------------------------- ~~~~~~~~ OXC Network ________ LSR Network ======== OXC-LSR Interconnection Fig. 4. Distinct OXC and LSR Networks (Physical and/or Logical) This is the case of routing customer traffic through the OXC network. The CPE equipments are in this case connected to service providers' LSRs and not OXCs. Referring to Fig. 4. this could then be a LSR A trying to send traffic to LSR C. (For LSR A to know that it needs to send traffic to LSR D in the first hand, may require sharing of routing information. This is dealt with in subsequent paragraphs). The first step in configuring this network is to aggregate the client traffic in to several LSPs on a coarse granularity. The reason is Krishna MPLS control plane for Switched Optical Networks [Page 11] Internet Draft February 2000 that the IP traffic is carried over optical channels and the number of wavelengths in a OXC (or fiber) are limited, unlike the labels in a MPLS environment. Around the OXC network is the service provider's edge network consisting of several LSRs and they aggregate the client traffic into several LSPs. Generally the number of LSPs in a LSR is equal to the total number of ports (or channels) in its connection to the adjacent OXCs. These LSRs are interconnected by a network which is physically and/or logically separated from the OXC network. A routing protocol like OSPF discovers the LSR networking topology. Again this routing protocol (or the instance of it) is different from the one that discovers the OXC network topology. Or more probably the LSRs and OXCs may have two instances of the network topology database of the same routing protocol or even two views of a single topology database. Thus the LSRs facilitate a knowledge of full network connectivity from router A to router C, outside of the OXC network. The OXCs have their own view of the network topology, and also have information as to which LSR is connected to which OXC. In this scenario an optical channel connection is setup between the ingress and egress LSRs over the OXC network. The ingress LSR only sends its request to its connected OXC. It is the OXC network that determines the path to the egress LSR. The OXC Adjacency and Port Interconnection Table then needs to be extended to include LSR port connections as well. Fig. 5. Krishna MPLS control plane for Switched Optical Networks [Page 12] Internet Draft February 2000 +-----+ +-----+ | |-----| | | |1 1| | | | | | | OXC |\ | LSR | | A |2\ | B | | | \ | | | | \ | | | | 6\| | | |\6 | | +-----+ \ +-----+ \ \ +-----+ 1\| | | | | | | OXC | | C | | | | | | | +-----+ Adjacent Local Port Remote Port Link Availability OXC/LSR Status B 1 1 y B 2 6 n C 6 1 y Fig. 5 - LSR-OXC Adjacency and Port Interconnection Table (For OXC A) 10. Signaling optical channel connection request (UNI) The request to setup an optical channel connection is initiated either by the CPE (Section 8) or by the service provider's LSR (Section 9). In the simplest case this UNI request will be to setup an optical channel connection setup between two OXCs or two LSRs. The mechanisms of setting up the connections in such cases were discussed in Sec. 8 and 9. Krishna MPLS control plane for Switched Optical Networks [Page 13] Internet Draft February 2000 However it is envisaged that the UNI request may specify many other connection requirements - uni or bi-directional link connection, network protection type required (if any) like 1+1, shared etc. Also where the optical nodes have capabilities for providing service specific connections like OC-192, GbE or multiplexing traffic (SONET or even lambdas) the UNI could specify these as well. The optical network nodes then need to authenticate the request, setup priorities in allocating the resources and finally signal an optical channel connection request based on these. This calls for extensions to the routing and signaling protocols. The proposed extensions to OSPF/IS-IS and CR-LDP/RSVP are listed in [10] and [11]. If the CPE or LSR is not capable of signaling over the UNI, the OXC path could also be set up in a proxy signaled manner from a network management device. Then, the client is informed via some other method of the availability of the path. 11. Network survivability - Fault detection and network restoration These topics will be discussed in detail in a future contribution. 12. Extensions/Modifications of IP protocols for OXC based WDM network From the above discussions it is clear that IP based protocols can be used for controlling Switched Optical Networks. However we feel some extensions/modifications to these protocols may be necessary. In this draft we have tried to explain the OXC based optical networking scenario which necessitates some additional work on the IP protocols. The objective of this draft is thus to initiate discussions on these. 13. Summary In this draft we study the role of MPLS and other IP based protocols in the control plane of a OXC based WDM optical network. The architecture of the OXC network to support setting up optical channels for data paths was briefly discussed. The three important steps in setting up an optical channel viz. a) signaling path setup, b) OXC interconnection details and c) data path (optical channel itself) were studied. Two typical cases of client connections to the OXC networks were discussed in detail. The first is the CPE connecting to OXC through dark fibers. The second is the case of CPEs connecting to OXCs through LSRs. In both cases we try to show how protocols like OSPF, MPLS, CR-LDP, RSVP etc. could be used Krishna MPLS control plane for Switched Optical Networks [Page 14] Internet Draft February 2000 to setup the connections. We then clearly spell out the need for separation of the optical layer topology and the client services (IP) that it carries. Lastly we stress the need for IETF to initiate work on extending some of the standard protocols to meet the additional requirements of OXC based Switched Optical Networks. 14. Security Considerations This draft proposes the use of MPLS and other IP based protocols for the control of Switched Optical Networks. Security considerations associated with these protocols are applicable to this proposal also. 15. Acknowledgements The authors would like to thank Bharat Doshi, John Ellson, Patrice Lamy, Eve Varma and Ren Wu for their helpful comments on this work. 16. References: [1] G. Newsome and P. Bonenfant, "The Automatic Switched Optical Network," Contribution to T1 STANDARDS PROJECT - T1X1.5, 1999. [2] P. Bonenfant and and X. Liu, "A Proposal for Automatically Switched Optical Channel Networks (ASON)," Contribution to T1 STANDARDS PROJECT - T1X1.5, 1999. [3] G. Newsome and M. Mayer, "Work on the Automatic Switched Opti- cal Network," Contribution to T1 STANDARDS PROJECT - T1X1.5, 2000. [4] D. Awduche, Y. Rekhter, J. Drake, R. Colton, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects," Internet Draft, Work in Progress, 1999. [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,A. Viswanathan, "A Framework for Multiprotocol Label Switching,"Internet Draft, Work in Progress, 1999. [6] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," Internet Draft, Work in Progress, 1999. Krishna MPLS control plane for Switched Optical Networks [Page 15] Internet Draft February 2000 [7] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus,"Requirements for Traffic Engineering Over MPLS," RFC- 2702, September 1999. [8] 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. [9] B. Jamoussi et al, "Constraint-Based LSP Setup using LDP,"Internet Draft, Work in Progress, 1999. [10] G. Wang et al, "Extensions to OSPF/IS-IS for Optical Routing," Internet Draft, Work in Progress, 2000. [11] G. Wang et al, "Extensions to CR-LDP and RSVP for Optical Path Set-up," Internet Draft, Work in Progress, 2000. 17. Authors' Addresses Murali Krishnaswamy Lucent Technologies 3C-512 101 Crawfords Corner Rd. Holmdel NJ 07733 Voice: +1 732 949 3611 Email: murali@lucent.com George Newsome Lucent Technologies 3C-505 101 Crawfords Corner Rd. Holmdel NJ 07733 Voice: +1 732 949 0812 Email: gnewsome@lucent.com Joe Gajewski Lucent Technologies 3F-517A 101 Crawfords Corner Rd. Holmdel NJ 07733 Voice: +1 732 332 5981 Email: joegajewski@lucent.com Antonio Rodriguez-Moral Lucent Technologies 3C-502A 101 Crawfords Corner Rd. Krishna MPLS control plane for Switched Optical Networks [Page 16] Internet Draft February 2000 Holmdel NJ 07733 Voice: +1 732 949 2164 Email: arodmor@lucent.com Stephen Shew Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Voice: +1 613 763 2462 Email: sdshew@nortelnetworks.com Michael Mayer Nortel Networks P.O. Box 402 Ogdensburg NY 13669 Voice: +1 613 765 4153 Email: mgm@nortelnetworks.com Krishna MPLS control plane for Switched Optical Networks [Page 17]