Network Working Group G. Bernstein Internet Draft Ciena Expiration Date: May 2001 B. Rajagopalan Document: draft-bernstein-optical-bgp-00.txt Tellium February 2001 Optical Inter Domain Routing Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 GMPLS is being considered as an extension to the MPLS framework to include optical non-packet switched technologies. This draft discusses requirements for inter domain routing protocols such as BGP for use in the optical domain. 1. Introduction Multi Protocol Label Switching (MPLS) has received much attention recently for use as a control plane for non-packet switched technologies. In particular optical technologies have a need to upgrade their control plane as reviewed in reference [2]. Many different optical switching and multiplexing technologies exist and more are sure to come. For the purposes of this draft we only consider non-packet (i.e. circuit switching) forms of optical switching. As we have looked at requirements and extensions to interior gateway protocols such as OSPF and IS-IS in reference [3], we consider the requirements that optical networking and switching place on an exterior gateway protocol such as BGP. In particular we look at optical path diversity, various optical switching and transport capabilities, and bandwidth/resource status with respect to inter domain routing. draft-bernstein-optical-bgp-00.txt July 2000 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2 Abbreviations LSP Label Switched Path (MPLS terminology) LSR Label Switched Router (MPLS terminology) MPLS Multiprotocol Label Switching SDH Synchronous Digital Hierarchy (ITU standard) SONET Synchronous Optical NETwork (ANSI standard) STM(-N) Synchronous Transport Module (-N) STS(-N) Synchronous Transport Signal-Level N (SONET) TU-n Tributary Unit-n (SDH) TUG(-n) Tributary Unit Group (-n) (SDH) VC-n Virtual Container-n (SDH) VTn Virtual Tributary-n (SONET) 2.0. Motivation for Optical Inter Domain Routing The motivation for inter domain routing in optical networks (circuit switched)is very similar to that in the case of IP datagram routing. 1. Distribute "reachability" information throughout an internetwork. An internetwork consists of an interconnected set of networks under different routing and/or administrative domains. 2. Maintain a clear separation between distinct administrative or routing domains. 3. Provide "information hiding" on the internal structure of the distinct administrative or routing domains. 4. Limit the scope of interior gateway routing protocols. This is for security, scalability and policy reasons. 5. Provide for address/route aggregation. 2.1. Major Differences from IP datagram Routing Although the differences in requirements between an exterior gateway protocol for IP datagram routing and that for optical circuit routing will be explored in detail in the following section. It is useful to review the major difference between routing for optical (circuit switched networks) and IP datagram networks. In particular IP datagram networks packet forwarding is done on a hop-by-hop basis (no connection established ahead of time). While with circuit switched optical networks end to end connections must be explicitly set established based on network topology and resource status information. This topology and resource status information can be draft-bernstein-optical-bgp-00.txt July 2000 obtained via routing protocols. Note that the routing protocols in the circuit switch case are not involved with data (or bit) forwarding, i.e., they are not "service impacting". While in the IP datagram case the routing protocols are explicitly involved with data plane forwarding decisions and hence are very much service impacting. This does not imply routing is unimportant in the optical case but that its service impacting effect is secondary. For example, topology and resource status inaccuracies will affect whether a new connection can be established (or a restoration connection can be established) but will not (and should not) cause an existing connection to be torn down. This tends to lead to a slightly different view towards incorporating new information fields (objects, LSA, etc.) into optical routing protocols versus IP routing protocols. In the optical circuit case any information that can potentially aid in route computations or be used in service differentiation may be incorporated into the route protocol as either a standard element or a vendor specific extension. Whether a route computation algorithm uses this information and whether two route computation algorithms use this information in the same way doesn't matter since the optical connections are explicitly routed (although perhaps loosely). The optical route computation problem is really a constraint-based routing problem. 2.2. Policy Mechanisms BGP-4 [4] provides a number of policy mechanisms that relate to how routing information is used and disseminated. In particular the E- BGP border router model keeps distinct the routing information received from each of a border routers autonomous systems external peers (Adj-RIBs-In -- Adjacent Routing Information Base In), the routing information that the Autonomous System (AS) itself is using (Loc-RIB -- Local Routing Information Base), and the routing information that the AS forwards onto its external peers (Adj-RIBs- Out -- Adjacent Routing Information Base Out). Via this model one can develop policies with regards to which routes get chosen for use in the AS, i.e., which routes from the Adj-RIBs-In are chosen to populate the Loc-RIB. One also develops policies concerning what routing information gets advertised to external peers, i.e., which routes from Loc-RIB gets exported to each of the Adj-RIBs-Out. The choice of which routes get imported for local routes generally is concerned with the "quality" of those advertising the routes since not too much else is known (besides the AS path vector). In deciding which routes to advertise to external peers "transit policies", i.e., whose traffic is allowed to transit this AS is the prime consideration. In the MPLS and in particular the explicitly routed optical case we have a very strong additional policy mechanism, that of connection draft-bernstein-optical-bgp-00.txt July 2000 admission control (CAC). Although an optical AS probably shouldn't advertise transit capabilities that it doesn't wish to support, CAC during connection establishment will be the final arbiter of any transit policy. In addition, some areas that are being addressed by policies in the IP datagram case such as load balancing are much easier to implement via CAC and/or explicit routing. 2.3. Multi-Domain Connection Control MPLS' loose routing allows one to specify a route for an optical connection in terms of a sequence of optical AS numbers. This, for example, is handled via RSVP-TE's abstract node concept [5]. Currently there is nothing in the GMPLS signaling specification that differentiates between intra AS boundaries, i.e., between two neighbor optical LSRs in the same AS, and inter AS boundaries, i.e. between two neighbor optical LSRs in different ASs. Note that these same notions can apply to separate routing domains within an AS. There may however be some useful reasons for differentiating these two cases: 1. Separation of signaling domains, 2. Separation of protection domains. While routing protocols (used for their topology information) in the optical are not "service impacting", signaling protocols most certainly are. It is desirable to build some type of "wall" between optical ASs so that faults in one that lead to "signaling storms" do not get propagated to other ASs. The natural situation where "signaling storms" would be most likely to arise is during network restoration signaling, i.e., signaling to recover connections during major network outages, e.g., natural disasters etc. In this case it may be very advantageous to break up general source reroute forms of restoration into per domain segments or to start reroute at domain boundaries rather than all the way back at the originating node. Such a capability requires some loose coordination between the local, intermediate and global protection mechanisms. This is typically implemented via hold off timers, i.e., one layer of protection will not attempt restoration until a more fundamental (local) form has been given a chance to recover the connection. In other words: prevention of restoration related signaling storms may require the breaking up of a large network into multiple signaling (and hence routing) domains. These domains could be within the same AS. Routing across these domains will require some BGP-like protocol, hence another motivation for a BGP like protocol. 3.0. Diversity in Optical Routing There are two basic demands that drive the need to discover diverse routes for establishing optical paths: draft-bernstein-optical-bgp-00.txt July 2000 1. Reliability/Robustness 2. Bandwidth capacity. Many times multiple optical connections are set up between the same end points. An important constraint on these connections is that they must be diversely routed in some way. In particular they could be link diverse (not traversing the same link) or node diverse (not traversing the same nodes). Additionally insufficient bandwidth may exist to set up all the desired connection across the same path (set of links) and hence we need to know about alternative (diverse) ways of reaching the destination that may still have unused capacity. 3.1 Pick One! (route that is) With datagram routing we need to pick one route to a destination and make sure this choice is consistent throughout the AS. In particular BGP specifically reduces the number of choices according to the following rule [6]: Fundamental to BGP is the rule that an AS advertises to its neighboring AS's only those routes that it uses. This rule reflects the "hop-by-hop" routing paradigm generally used by the current Internet. In the optical circuits case we are not using a "hop-by-hop" routing paradigm. Hence it seems that BGP constrains our knowledge of diverse routes in the optical case. This hits a major difference in use between the optical and IP datagram forwarding case. In the optical case we are really interested in topology information that allows an optical connection path to be computed based on whatever criteria is desired for that connection. In the IP datagram case we are interested in a consistent set of routes for use in hop-by-hop forwarding. Hence the optical case has tended to favor link state protocols since they furnish raw topology information that can be used in computing routes as opposed to distance vector protocols whose output is a set of routes (without necessarily providing complete topology information). 3.2. Some Additional Diversity Issues In a previous section we mentioned node and link diversity and gave a brief definition. Unfortunately these definitions are not really adequate for optical networking. Optical networks may posses a number of hierarchical signaling layers. For example two routers interconnected across an optical network may communicate with IP packets encapsulated within an STS-48c SONET path layer signal. Within the optical network this STS-48c signal may be multiplexed at the SONET line layer into an OC-192 line layer signal. In addition this OC-192 may be wavelength division multiplexed onto a fiber with other OC-192 signals at different wavelengths (lambdas). These WDM signals can then be either lambda switched, wave band switched or fiber switched. Hence when we talk about diversity we need to specify which layer. In the previous example we can talk about draft-bernstein-optical-bgp-00.txt July 2000 diversity with respect to the SONET line layer, wave bands, and optical fibers. A similar situation arises when we consider the definition of node diversity. For example are we talking with respect to a SONET path layer switch or an optical switch or multiplexer? The Shared Risk Link Group concept in reference [7] can help us with this type of information within an AS, but there are some additional complexities in the exterior routing case. First its useful with respect to major outages (cable cuts, natural disasters) to have a few more types of diversity defined: 1. Cable (conduit) diversity (allows us to know which fibers are in the same cable (conduit). This helps avoid sending signals over routes that are most vulnerable to "ordinary" cable cuts (technically known as backhoe fades). 2. Right of Way (ROW) diversity. This helps avoid sending signals over routes that are subject to larger scale disasters such as ship anchor drags, train derailments, etc. 3. Geographic diversity. This type of diversity can help one avoid sending signals over routes that are subject to various larger scale disasters such as earthquakes, floods, tornadoes, hurricanes, etc. We can attempt to extend the SRLG concept to links between ASs but we will need the two ASs to agree on the meaning and number of the list of 32 bit integers that comprise the SRLG, i.e., previously the SRLG concept was one of AS scope. And this is also where things get tricky since it may not be possible to distinguish diverse routes based upon differing path vectors (i.e., AS number traversal list). The reason for this is due the fact that many carriers "fill out" there networks by renting either dark fiber or "lambdas" from a WDM system and hence although the path vectors may be AS diverse they may not even be fiber diverse. Hence there is a need for sharing of diversity information or constraints between ASs when setting up diverse connections across multiple ASs. This gets us somewhat into a quandary over which information needs to be public and how to coordinate. In this sense geographic link information may be the simplest and least contentious to get various players to disclose and standardize. 4.0. AS Capability Advertisement In addition to reachability information from an AS we will want to know: 1. Switching capabilities 2. Protection Capabilities 3. Available Capacity 4. Reliability Measures (if available) draft-bernstein-optical-bgp-00.txt July 2000 The tricky part of advertising any of these properties is that we would like to summarize this information in a reasonable way so as to keep it reasonably brief and suitable for distribution within a routing protocol but at the same time deliver sufficient information to be of use in most path computation situations. This is in general a topology aggregation problem, but to keep in the spirit of AS autonomy and opaqueness at most this would be represented as a "hub and spoke" type of aggregate where the "psuedo links" and the "hub" can posses various attributes corresponding to the previously mentioned capabilities. 5.0 Conclusion and Recommendations This draft highlighted some of the requirements for exterior gateway routing protocol for use in optical internetworking. The similarities and differences between which of these requirements are currently answered by BGP and which would require extensions to BGP were discussed. In addition, information that would need to be shared between optical domains in order for an exterior gateway routing protocol to be viable was discussed. 6. Security Considerations Security considerations are not discussed in this version of the document. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] G. Bernstein, J. Yates, D. Saha, "IP-Centric Control and Management of Optical Transport Networks", IEEE Communications Magazine, October 2000. [3] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based Control of Optical SDH/SONET Networks", <draft-bms-optical- sdhsonet-mpls-control-frmwrk-00.txt>, November 2000. [4] Rekhter Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995. [5] Awduche, D., et. Al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Work in Progress, draft-ietf-mpls-rsvp-lsp-tunnel- 07.txt, August 2000. [6] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995. [7] Kompella, K., et. al. "IS-IS Extensions in Support of Generalized MPLS", Work in Progress, draft-ietf-isis-gmpls- extensions-01.txt, November 2000. 8. Acknowledgments draft-bernstein-optical-bgp-00.txt July 2000 9. Author's Addresses Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014 Phone: (408) 366-4713 Email: greg@ciena.com Bala Rajagopalan Tellium, Inc 2 Crescent Place Ocean Port, NJ 07757 Email: braja@tellium.com