Internet Draft

Internet Draft                                      Dimitris Pendarakis
Expiration Date:  May, 24, 2001                     Bala Rajagopalan
                                                    Debanjan Saha
                                                       Tellium Inc.


               Routing Information Exchange in Optical Networks 

                    draft-prs-optical-routing-01.txt

1. 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.


2. Abstract
  
   The objective of this draft is to describe mechanisms for exchanging 
   routing information between IP routers and optical networks, 
   and between optical sub-networks. Such information exchange would 
   allow automated establishment of end-to-end paths in an optical 
   network comprising of  multiple sub-networks. Furthermore, it would 
   allow optical network clients, specifically IP routers, to discover 
   their remote peers dynamically. Determination of reachability could 
   be the first step in dynamic provisioning of optical paths using 
   signaling. 
   
   (A postscript version of this draft with figures is available as
    draft-prs-optical-routing-01.ps). 
   
   
3. Introduction

   Consider the optical networking model as shown in Figure 1. Here, 
   clients (e.g., IP routers) are attached to an optical core network, 
   and connected to their peers over dynamically established switched 
   optical paths. The interaction between the clients and the optical 
   core is over a well-defined signaling and routing interface, shown 
   as the User-Network Interface (UNI).
      
   The optical network shown in Figure 1 consists of multiple Optical 
   Cross-Connects (OXCs) interconnected by optical links in a general 
   topology refered to as an ôoptical mesh networkö. This network may be 
   multi-vendor, where individual vendor OXCs constitute sub-networks. 
   Each sub-network itself is assumed to be mesh-connected. The 
   interaction between the sub-networks is over a well-defined signaling 
   and routing interface, shown as the Network-Network Interface (NNI).
   
   The optical network essentially provides point-to-point connectivity 
   between clients in the form of fixed bandwidth optical paths. The 
   collection of optical paths therefore defines the topology of the 
   virtual network interconnecting the clients. This topology may be 
   static by design. In this case, the optical paths may be provisioned 
   ômanuallyö, i.e., without any need for signaling protocols at the UNI. 
   The more interesting case is when the interconnection topology can 
   change dynamically.  In this case, control protocols at the UNI, as 
   well as at the NNI, are necessary for dynamic provisioning of paths. 
   
   Figures 2a and 2b illustrate some applications of dynamic provisioning. 
   In Figure 2a, a Virtual Private Optical Network (VPON) for IP routers 
   is shown. Here, optical paths are provisioned between routers 
   belonging to the same VPON, but the interconnection topology may 
   change with time depending on traffic demands between the VPON 
   nodes. Figure 2b illustrates the case where two logically separate 
   VPONs are interconnected dynamically based on policy decisions. 
   Both these cases require routing interaction between the optical 
   network and the IP networks to facilitate the automatic configuration 
   of the VPON topology. 
   
   In the next section, the model for routing across the UNI is 
   considered.  Routing information exchange across the NNI is considered 
   in Section 4. Finally, summary and conclusion are presented in 
   Section 5.
   

4. Routing Information Exchange over the UNI
   
   Let us consider the network model shown in Figure 1 and assume that 
   the dynamic provisioning of an optical path is initiated by a client 
   device using UNI signaling. Such a provisioning request must specify 
   the destination endpoint in the optical network. This  information can 
   be made available to the client device in a number of ways. To describe 
   these methods, let us consider the case where the client devices are IP 
   routers. Let us designate the routers directly connected to the optical 
   networks as "border" routers. The OXCs they are connected to are 
   referred to as "border" OXCs.
   
   1. The endpoint information may be configured in the client device. For 
      example, each border router can be configured with optical endpoint 
      addresses corresponding to IP destinations in other sites. This 
      configured information, together with configured rules on dynamic 
      provisioning, may be used to establish dynamic VPON topologies.

   2.  The endpoint information is obtained using a limited reachability 
       protocol across the UNI. In this case, each border router runs the 
       reachability protocol with the corresponding border OXC and 
       obtains the address of every other border router belonging to the 
       same VPON. Using this information, an initial set of IP routing 
       adjacencies are established between border routers. The border 
       routers then run an IP routing protocol amongst themselves to 
       determine all the IP destinations reachable over the optical 
       network.

   3. The endpoint information is obtained using a routing protocol 
      running across the UNI. In this case too, each border router runs 
      the routing protocol (e.g., BGP) with the corresponding border 
      OXC. Unlike (2) above, this protocol allows border routers to 
      advertise all destinations reachable in their site to the 
      corresponding border OXCs. The full reachability information is 
      then conveyed to other border routers over the UNI. There is no 
      need for border OXCs to establish IP routing adjacencies among 
      themselves.
   
   The last two options are referred to as "peer" routing organizations 
   to reflect the fact that the client devices and OXCs are routing 
   peers running a common routing protocol. We may, however, distinguish 
   partial peering (option 2) which requires additional routing exchanges 
   between clients across the optical network from full peering (option 3) 
   which does not require these exchanges. (Here, it is important to 
   distinguish between the data and control planes over the UNI. The 
   optical network provides a service to external entities in the form of
   fixed bandwidth transport pipes (optical paths). IP routers at the edge 
   of the optical networks must necessarily establish such paths before  
   communication at the IP layer can begin. Thus, the IP data plane over 
   optical networks is realized over an overlay network of optical paths. 
   On the other hand, IP routers and OXCs can have a "peer" relation on 
   the control plane, especially for the implementation of a routing 
   protocol that allows dynamic discovery of IP endpoints attached to 
   the optical network.) 

   Clearly, not all of these three options may make sense in different 
   networking scenarios. Specifically, with non-IP client devices 
   configuration may be more convenient than other options. If the other 
   options are considered in such settings, the reachability or routing 
   protocols must convey non-IP client addresses across the optical 
   network. The following descriptions are limited to the case where the 
   clients are IP devices. It is easy to generalize the descriptions to 
   non-IP clients. In the next two sub-sections, we consider full and 
   partial peer routing models, respectively.
   
4.1 Full Peer Routing Models
   
   We describe two different full peer routing organizations. First, a 
   "flat" routing organization may be developed that allows a single 
   routing protocol instance to run in both client and optical networks. 
   Given that optical networks use IP-centric protocols, this organization 
   is possible only with client networks that run the same IP routing 
   protocols internally.  Furthermore, this type of routing may be 
   practical only when both the optical and client networks are 
   administered by the same entity. Second, client and optical networks 
   can be functionally separated, each running its own routing protocol, 
   but exchanging full reachability information across the UNI using a 
   standard protocol. This is a convenient solution, since it allows the 
   development of provisioning and restoration procedures for optical 
   sub-networks independent of client network routing. Also, this 
   approach supports the common scenario where the optical network and 
   client networks are administered by different entities. Additionally, 
   there is a practical aspect to following this approach: it allows the 
   same standard routing protocol to be used across the NNI for routing 
   across disparate optical sub-networks (Section 3). In the following, 
   these approaches are described in some detail.

4.1.1 Flat Routing Organization
   
   Since the optical network implements IP-centric control protocols, it 
   should be possible to export a representation of its internal topology
   to routers at the edge of the network. For example, an IP routing 
   protocol like the Open Shortest-Path First (OSPF) [1] may be used 
   across the IP/optical domains. 
   
   Figure 3 depicts flat routing organization using OSPF, where IP routers 
   maintain a single topology database for the joint network consisting of 
   IP and optical nodes. Here, the sample network topology has five IP 
   routers and three optical switches. The OSPF Link State Advertisements 
   (LSAs) at router R1 is represented abstractly in the table. Here, all 
   the nodes and (unidirectional) links in the combined network are 
   listed. Optical links are distinguished from other links, since the 
   characterization of these links may include optical-link-specific 
   information such as link type, composition of bundled links, etc. 
   Thus, with flat routing, a router must maintain information that 
   potentially has no meaning in the router network, but meaningful only 
   within the optical network.
   
   Assuming that routers are programmed to apply the correct semantics 
   for the optical network information, IP routers can compute full paths 
   to other IP destinations across the network. For example, router R1 
   can compute the path R1-R2-R3-O2-O3-R4-R5. This path may be signaled 
   hop-by-hop from R1 to R5, using the appropriate  protocols across the 
   UNI and the NNI, and within router networks and optical sub-networks. 
   Once the path is established, however, the segment R3-O2-O3-R4 must be 
   treated as a single virtual link R3-R4 of fixed capacity (e.g., OC-48) 
   and perhaps advertised as such in further OSPF updates. The 
   restoration of the optical path within the optical network may be 
   visible to all nodes in the network, thereby complicating the process.

4.1.2 Domain-Specific Routing Organization
   
   Routing within the optical and IP domains may be separated, with a 
   standard routing protocol running between domains. This is similar to 
   the IP interdomain routing model. In this section, the focus is on the 
   routing information exchange at the IP-optical UNI. There are two 
   possibilities for this. We first consider the interdomain IP routing 
   protocol, BGP [2], which may be adapted for exchanging routing 
   information between IP and optical domains. We then consider the use 
   of OSPF areas to facilitate routing across the UNI. 

4.1.2.1 Routing Information Exchange using BGP
   
   This would allow the routers to advertise IP address prefixes within 
   their network to the optical network and to receive external IP address 
   prefixes from the optical network. The optical network transports the 
   reachability information from one IP network to others, as shown in 
   Figure 4. Here, networks N1-N3 are assigned the address spaces 
   indicated by the network prefixs x.y.c.*, a.b.c.*, and {x.y.a.*, 
   x.y.b.*}. 

   The propagation of the address prefixes from R4 to R3 through the 
   optical network is shown.  Exterior BGP (EBGP) is assumed to run 
   between the IP routers and OXCs over the UNI (between border 
   routers and border OXCs).  Within the optical network, it is assumed 
   that interior BGP (IBGP) is used between border OXCs within the 
   same sub-network and EBGP is used over the optical NNI (in Figure 4, 
   however, only a single optical sub-network is shown. Here, IBGP runs 
   between border routers O1-O3). The IP address prefixes within the 
   optical network are not advertised to routers using BGP. 

   A border OXC receiving external IP prefixes from a router includes 
   its own IP address as the egress point before propagating these 
   prefixes to other border OXCs or border routers. For instance, in the
   example illustrated in Figure 4, the address of OXC O2 will be 
   advertised along with the prefixes {x.y.a.*, x.y.b.*}. A border router 
   receiving this information need not propagate the OXC address further, 
   but it must keep the association between external IP addresses and 
   egress OXC addresses. When a specific external IP address is to be 
   reached, the border router  can determine if an optical path has 
   already been established to the appropriate egress OXC or a path 
   must be newly established. Specific BGP mechanisms for propagating 
   egress OXC addresses are to be determined, considering prior 
   examples described in [3,4]. When VPONs are implemented, the address 
   prefixes advertised by the border OXCs must be accompanied by some 
   VPON identification (for example, VPN IPv4 addresses, as defined in 
   [3], may be used). Border OXCs can then filter external addresses 
   based on VPON identifiers before propagating them to routers, i.e., 
   a router would only receive external IP addresses belonging to its 
   own VPON. Once a router has determined reachability to external 
   destinations, the dynamic provisioning of optical paths to reach 
   these destinations may be based on traffic engineering mechanism 
   implemented in the router.
   
4.1.2.2 Routing Information Exchange using OSPF 
   
   When the optical network and all client networks belong to a single 
   routing domain, the routing information exchanged across the IP-
   optical UNI could be summarized using a hierarchical routing protocol 
   such as OSPF. 
   
   OSPF supports a two-level hierarchical routing scheme through the use 
   of OSPF areas. Routing within each area is flat, while detailed 
   knowledge of an areaÆs topology is hidden from all other areas. Routers 
   attached to two or more areas are called Area Border Routers (ABRs). 
   ABRs propagate IP addressing information from one area to another 
   using summary LSAs. Within an OSPF routing domain, all areas are 
   attached directly to a special area called the OSPF backbone area. The 
   exchange of information between areas in some way is similar to BGP 
   method of propagating reachability. 
   
   The use of a single OSPF routing domain with multiple areas is 
   beneficial from the point of view of ease of migration, as providers 
   migrate to optically switched backbones. Figure 5 shows a single 
   autonomous system organized into multiple OSPF areas. This sample 
   network consists of 3 OSPF areas (0.0.0.1, 0.0.0.2 and 0.0.0.3) 
   connected to the OSPF backbone area, denoted by 0.0.0.0. As shown in 
   this figure, all areas are constructed using IP routers. Routers R2, R4, 
   R7, R11, R12, R14 are ABRs and  R2, R4, R7, R10-15 are backbone 
   routers. 
   
   In Figure 6, the physical backbone router network of Figure 5 has been 
   replaced with an optical network; this is simply achieved by replacing 
   each backbone router with an optical switch. While the data plane 
   characteristics of the optical network are completely different than 
   those of the router backbone, the control plane remains essentially the 
   same. As long as optical switches participate in the OSPF protocol, the 
   optical network can serve as the OSPF backbone area, flooding 
   summary LSAs between different areas. The optical network advertises 
   external addresses into each area, along with the address of the ABR 
   corresponding to each address and a cost metric. For example, switch 
   O11 advertises addresses in an external area 0.0.0.3 into area 0.0.0.1. 
   For those destinations advertised, it also indicates the address of R7, 
   the ABR in area 0.0.0.3 and the cost of the path from O11 to O12 (to 
   reach R7). The information about R7 is needed by R2 to determine where 
   to establish a lightpath when communicating with destinations in area 
   0.0.0.3. The cost information may be used to select among multiple 
   alternatives when a client network is multiply homed. 

4.2 Partial Peer Routing Model

   Running a protocol like BGP across the UNI may be considered too 
   involved, at least for initial implementations of the UNI. A simpler 
   approach would be to limit the reachability information  passed through 
   the optical network as follows:
   
   1. Each border router belonging to a VPON registers a set of   pairs (or a set of VPN IPv4 addresses) 
      to a border OXC across the UNI.

   2. The IP addresses of all border routers belonging to a VPON are 
      propagated across the optical network (see Section 4)

   3. These addresses are conveyed to each router that registers as a 
      border router in the VPON.
   
   The propagation of reachability information is illustrated in Figure 7. 
   Here, three IP networks that are part of the same VPON are shown. The 
   border routers have assigned addresses as shown. The flow of 
   registration messages from border routers to border OXCs and the flow 
   of reachability information (i.e.,  pair) in the 
   reverse direction are shown. Within the optical network, a border OXC 
   is assumed to originate routing advertisements for external IP 
   addresses registered with it. This would allow interior OXCs to route 
   optical paths destined to external IP addresses to the correct 
   destination OXCs.  

   Now, once border routers in a VPON receive the address of other 
   border routers within their own VPON, they may construct a VPON 
   topology dynamically through UNI signaling. Assuming that each 
   router has at least two interfaces to the optical network, a linear 
   topology may be built automatically, as shown in Figure 8 (the initial 
   topology may also be built based on configured information about 
   routing adjacencies). Over this topology, the border routers may run 
   their own IP routing protocol, for example, OSPF. In this case, the 
   optical paths between the border routers will be represented as virtual 
   links in the OSPF link state database. The initial topology may be 
   modified dynamically, based on traffic engineering algorithms that are 
   implemented in the border routers, as shown in Figure 2. Thus, the 
   simple reachability protocol described above provides a mechanism for 
   bootstrapping end-to-end IP routing within the VPONs across the 
   optical network.


5. Routing Information Exchange over the NNI
   
   Provisioning an end-to-end optical path across multiple sub-networks 
   involves the establishment of path segments in each sub-network 
   sequentially. Thus, a path segment is established from the source OXC 
   to a border OXC in the source sub-network. From this border OXC, 
   signaling across the NNI is to establish a path segment to a border OXC 
   in the next sub-network. Provisioning then continues in the next sub-
   network and so on until the destination OXC is reached. This procedure 
   is shown in Figure 9, assuming CR-LDP signaling within sub-networks 
   and a standardized NNI signaling for path set-up. To automate this 
   process, it must be possible to determine the route to the destination 
   OXC from within the source sub-network. A routing protocol must 
   therefore run across the NNI between sub-networks. It is desirable that 
   such a protocol allows the separation of routing between sub-networks. 
   This allows proprietary provisioning schemes to be implemented within 
   sub-networks while end-to-end provisioning is performed.
   
   These objectives may be satisfied by running a version of BGP between 
   border OXCs. For this, it is essential that the OXC IP addresses are 
   unique network-wide. Using exterior BGP, adjacent border OXCs in 
   different sub-networks can exchange reachability of OXCs and other 
   external IP endpoints (border routers). Using interior BGP, the same 
   information is propagated from one border OXC to others in the same 
   sub-network. Thus, every border OXC eventually learns of all IP 
   addresses reachable across different neighboring sub-networks. These 
   addresses may be propagated to other OXCs within the sub-network 
   thereby allowing them to select appropriate border OXCs as exit points 
   for external destinations. To support the routing model described in 
   Section 2.1, the external reachability information should include VPON 
   identifiers.
   
   It is clear that border OXCs must keep track of many IP addresses 
   corresponding to different remote OXCs. The overhead for storage and 
   propagating these addresses can be reduced if OXC addresses within a 
   sub-network can be aggregated to a relatively few IP network prefixes. 
   This is indeed possible if OXC addresses within a sub-network are 
   derived from a small set of IP network prefixes.
   
   Once border OXCs acquire reachability information regarding remote 
   destinations, this information may be shared with other OXCs within 
   the sub-network to enable end-to-end path provisioning. In short, a 
   source OXC within a sub-network must determine the border OXC 
   through which the ultimate destination can be reached. Also, if there 
   is more than one such border OXC, a procedure must be available to 
   select one of them. Finally, policy decisions may be involved in 
   selecting a particular route. These issues are similar to interdomain 
   routing in the Internet as discussed in [2].

5.1 Dynamic Provisioning Model
   
   The model for provisioning an optical path across sub-networks is as 
   follows. A provisioning request may be received by a source OXC 
   from a management system, specifying the source and destination end-
   points. Such a request must explicitly specify the  pair identifying each end-point. On the other hand, a 
   provisioning request may be received from an IP border router. In this 
   case, the source end-point is implicit and the destination endpoint is 
   identified by the IP address. In both cases, the routing of an optical
   path is done as follows:
   
   1. The source OXC looks up its routing information corresponding to 
      the specified destination IP address:

      a. If the destination is an OXC in the source sub-network, a path 
         maybe directly computed to it. 

      b. If the destination is an external address, the routing 
         information will indicate a border OXC that would terminate 
         the path in the source sub-network. A path is computed to the 
         border OXC.

   2. The computed path is signaled from the source to the destination 
      OXC within the source sub-network. The complete destination 
      endpoint address specified in the provisioning request (either 
       or ) is carried in the 
      signaling message.

   3. The destination OXC in the source sub-network determines if it is 
      the ultimate destination of the path. 

      a. If so, it checks if the destination endpoint identifier 
         specified in the message includes a port index. In this case, 
         it completes the optical path set-up using the port index. If 
         the port index is not included, the address corresponds to a 
         border router. In this case, the port through which the border 
         router performed registration is used to complete the path 
         set-up.

      b. If  the OXC is not the ultimate destination, it determines the 
         address of a border OXC in an adjacent sub-network that leads 
         to the final destination. The path set-up is signaled to this 
         OXC using NNI signaling. The next OXC then acts as the 
         source for the path and steps 1-3 are followed.


6. Summary and Conclusions
   
   This contribution considered several models for routing information 
   exchange across the UNI and NNI. These models were classified into 
   configuration-based, partial peering and full peering routing models. 
   In summary, for UNI routing:
   
   o Configuration-based: Requires optical end-point information to be 
     configured in client systems. No routing protocol exchange across 
     the UNI.

   o Partial peering: Limited routing information is exchanged across 
     the UNI. This information may be used for bootstrapping client 
     specific routing exchange over the optical network.

   o Full peering: Full routing information is exchanged across the 
     UNI. 
   
   It was pointed out that not all of the UNI routing exchange models may 
   be appropriate for all types of client networks. The descriptions in 
   this draft were mostly based on IP client networks. With other type 
   of client networks, it is possible to carry non-IP addresses in routing 
   protocols. The partial peering model can also accommodate other address 
   types.  For routing across the NNI, the full-peering model using BGP was 
   described.  

   The routing models were described in abstract in this draft. Further 
   details of their operation are required. Also, the issue of how 
   client devices determine which endpoints to establish an optical path 
   is an issue. That was not considered in this draft.
   

7. References
   
   1. J. Moy, "OSPF Version 2," RFC 1247, July, 1991.
   2. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)," 
      RFC 1771, March, 1995.
   3. T. Bates, R. Chandra, D. Katz, and Y. Rekhter, "Multiprotocol 
      Extensions for BGP-4," RFC 2283, Feb., 1998.
   4. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March, 1999.
   
   
8. Author Information

    Dimitris Pendarakis
    Bala Rajagopalan
    Debanjan Saha
     Tellium Inc.
     2 Crescent Place
     P.O Box 901
     Ocean Port, NJ  07757
     Email: {dpendarakis, braja, dsaha}@tellium.com


                ***** This draft expires on May, 24, 2001 *****