Internet Draft Network Working Group Dan Dovolsky Igor Bryskin Internet Draft Virata Corporation Document: draft-dovolsky-bryskin-ospf-pathprotect- June 2000 proxy-00.txt Category: Informational Calculation of protection paths and proxy interfaces in optical networks using OSPF draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt Status 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 The first part of this document describes a proposal about how to calculate non-overlapping primary and redundant path(s) in optical networks using the OSPF routing protocol and Traffic Engineering Extensions to OSPF, as defined in [KATZ]. The second part of the document introduces the concept of a Proxy Interface and describes a method to avoid unnecessary OSPF traffic activity in networks where adjacent nodes are interconnected via multiple interfaces. 1. Introduction In today's world, many companies are developing fiber optic equipment that use various wavelengths ("lambda") in order to forward different flows of data over the same fiber pipe. This approach results in dramatic increases in data throughput over a single fiber. Another benefit of this approach is the ability to forward data using only the wavelength value, which may be performed on a very low hardware level. Dovolsky/Bryskin Expires December 2000 1 draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt June 2000 Numerous companies selected MPLS technology because it provides the best solution for both the control and data planes. MPLS works in conjunction with one or several routing protocols (preferably with the Traffic Engineering extensions) in order to calculate "Explicitly Routed" or "Next Hop Routed" paths that have the greatest likelihood of satisfying the policy and bandwidth constraints. For the purpose of path protection, it is often necessary to calculate one or more alternative paths, in addition to a primary path. One of these alternative paths may be used in cases when the primary path fails. It is very important to constrain the alternative path computation by excluding all fiber pipes through which the primary path passes. The rationale for this is that the most likely cause of the primary path failure is fiber disconnection, and, in this case, all channels of the fiber (not just the one being used by the primary path) must be excluded from the path computation. Implementing this constraint is not straightforward because all "lambda" channels should be advertised to the routing protocol (e.g. OSPF) as interfaces in order to make them available for data forwarding. The OSPF assumes no dependencies between these interfaces, whether or not they belong to the same fiber pipe. There are two undesirable consequences of this assumption. First, the computed alternative path might pass the same fiber pipes as the primary path. Second, the OSPF-controlled traffic repeats itself on all channels belonging to the same fiber pipe, unnecessarily wasting bandwidth and the CPU power. 2. Alternative path calculation We propose the following solution for the alternative path calculation, which is based on the Traffic Engineering (TE) Extension to OSPF, as defined by [KATZ]. All OSPF interfaces ("lambda"-channels) that belong to the same fiber pipe are grouped together and marked by a global group identifier. This global group identifier is advertised to the routing domain via the "Resource Class/Color" sub-TLV of the Link TLV of the Traffic Engineering LSA for each interface. It is important to note that [KATZ] specifies the Resource Class/Color sub-TLV as an administrative group membership for a link in terms of bit masks. Although different meanings may be applied to this field, we propose to use this field, in the context of the optical network, as a group identifier of the fiber pipe, which uniquely identifies the topology segment (fiber pipe) in the network. This approach should not cause interoperability problems because it does not require modifying any of the OSPF messages. Nor does it Dovolsky/Bryskin Expires December 2000 2 draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt June 2000 require changing how the Traffic Engineering LSAs are injected into the routing domain. When the "Group ID" capable OSPF router is requested to define a primary path to a certain destination, it passes the Group IDs of path segments to the requestor along with the computed path. When the requestor needs to define one or more alternative paths, the requestor may specify the list of GroupIDs to exclude from the path computation as part of the topology constraints. Also, the requestor may pass a list of GroupIDs to specify one or more fiber pipes through which the path should be forced or through which it is preferable to go. 3. Proxy OSPF Interface Because all channels of the same fiber pipe have to be advertised to OSPF as interfaces, there is a lot of unnecessary OSPF activities on the fiber. Assuming that a fiber pipe interconnects two adjacent routers, it is sufficient to use only one interface/channel for exchanging OSPF Hellos, synchronizing the topology databases, etc., and sharing the output of these activities with all other interfaces for the purpose of path computation. This would decrease significantly the amount of control plane overhead in terms of the bandwidth, CPU and memory consumption. The current draft proposes the following solution: - A new interface type (we call it Passive) must be introduced; - Interfaces of the Passive type must not send any OSPF Control messages (e.g. Hellos); - All OSPF Control messages received on these interfaces must be dropped; - One or more Passive interfaces must be associated with exactly one Active (regular) OSPF interface, which performs the Proxy function for them; - The neighboring router parameters for the passive interface must be extracted from the Proxy interface database; - All Passive interfaces in the UP state must be advertised in the Router LSA as unnumbered point-to-point interfaces; - All Passive interfaces in the UP state must be advertised in the TE LSA; - When the Proxy interface goes DOWN or UP all associated Passive interfaces must be considered DOWN or UP respectively. - All Passive interfaces must be considered in the path computation algorithm as regular OSPF interfaces. Dovolsky/Bryskin Expires December 2000 3 draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt June 2000 4. Compatibility Issues There should be no interoperability issues with routers that do not implement this proposal. 5. Security Considerations This document raises no new security issues for OSPF. 6. References [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [KATZ] Dave Katz, Derek Yeung, "Traffic Engineering Extensions to OSPF", <draft-katz-yeung-ospf-traffic-01.txt>, October 1999. 7. Author's Addresses Dan Dovolsky Virata Corporation Kanfei Nesharim 24(b), Jerusalem, Israel Phone: +972-2-654-1734 Email: dan@virata.com Igor Bryskin Virata Corporation 65 Boston Post Road West, Marlborough, MA. 01752 Phone: +1-508-786-1920, ext 103 Email: ibryskin@virata Dovolsky/Bryskin Expires December 2000 4