One document matched: draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt

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