OSPF IN OPTICAL NETWORKS

Analysis of Enhanced OSPF for Routing Lightpaths in Optical Mesh Networks Sudipta Sengupta, Debanjan Saha, and Sid Chaudhuri Tellium, Inc., 2 Crescent Place PO Box 91 Oceanport, NJ 7757-91, USA. Abstract - We discuss enhancements to the OSPF protocol for routing and topology discovery in optical mesh networks. OSPF s opaque LSA mechanism is used to extend OSPF to disseminate optical resource related information through optical LSAs. Standard link-state database flooding mechanisms are used for distribution of optical LSAs. Each optical LSA carries optical resource information pertaining to a single optical link bundle between two adjacent OXCs, allowing for fine granularity changes in topology to be incorporated in path computation algorithms. OSPF packets are carried over a single IP control channel between adjacent OXCs. We analyze the performance of OSPF with optical extensions. Specifically, we compute control channel bandwidth used due to LSA updates. We also estimate the amount of memory required to store the LSA database. Finally, we study CPU usage for computing primary and backup lightpaths. Our analysis shows that the control channel bandwidth usage, memory requirement, and CPU usage are small enough to not be limiting factors for designing optical networks with single OSPF areas consisting of a large number (more than 5) of OXCs. OSPF allows hierarchical routing, whereby a large network may be treated as a collection of smaller areas with limited information exchange between areas. For smaller networks, a simpler organization consisting of the backbone area is sufficient. As a matter of fact, service providers typically start with a backbone area and add other areas as the network grows. I INTRODUCTION In an optical network, multiple optical crossconnects/switches (OXCs) are interconnected via WDM links in a general topology, referred to as an optical mesh network [1]. An OXC has multiple ports and is capable of switching an optical wavelength channel (e.g., at OC-48, OC-192 rates) from an input port to an output port. An optical network allows the dynamic provisioning of optical layer connections between clients connected to the network. The provisioning activity consists of establishing suitable cross-connects in each OXC in the connection path such that end-to-end connectivity is realized. Routing in an optical network presents new challenges for dissemination of optical link resource information and diverse routing of primary and backup paths. In this paper, we discuss extensions to the standard OSPF routing protocol [2] to facilitate routing and topology discovery in optical mesh networks. We also present an analytical model for evaluating the performance of OSPF with optical extensions. More specifically, we quantify the bandwidth requirement for disseminating link state information through router and optical LSAs, storage requirement for the LSAs, and CPU overhead for primay-backup path computation. We investigate the maximum size of an OSPF area that is feasible without pushing the limits of available control channel bandwidth, OXC memory, or CPU processing power. II OSPF IN OPTICAL NETWORKS Topology discovery and routing in traditional IP networks has been accomplished by running an enhanced version of the IP routing protocol, Open Shortest Path First (OSPF) [2]. Figure 1: Optical network arranged as an OSPF hierarchy. Figure 1 shows OXCs arranged in a two-tier OSPF hierarchy. As shown in the figure, this arrangement consists of a backbone area and a number of other areas hanging off the backbone area. Each OXC broadcasts the local link state information periodically, as well as when a change occurs in topology or resource availability. For reasons of scalability, broadcasts are contained within the area boundaries and only summarized topology information is disseminated across area boundaries. We first define some terminology for optical networks and then discuss the motivation for and details of OSPF extensions for optical networks. II.A Terminology Channel: An assigned wavelength on a physical fiber link connecting two OXCs, carrying a basic optical signal like OC-48 (2.4 Gbps). Optical Line (OL): An optical line is an optical connection between two ports on two adjacent OXCs. Shared Risk Link Group (SRLG): This identifies a point of failure (a fiber, cable or conduit) which could affect all channels belonging to that SRLG. A channel may pass through one or more SRLGs. Optical Line Group (OLG): A set of optical lines between

two neighboring OXCs that belong to the same set of SRLGs and are of the same type (e.g. OC-48, OC-192) are said form an optical line group. Figure 2: Optical line, line group, and link bundle. Optical Link Bundle (OLB): Multiple OLGs may be grouped together into an OLB. All OLGs between two neighbors are bundled together to form a single OLB. Control Channel: The IP control channel between two neighboring OXCs is used for carrying control for OSPF, lightpath signaling, etc. One way of implementing this control channel is to use the SONET overhead bytes. II.B Optical Line Optical Line Group OSPF Extensions Optical Link Bundle SRLG-1 SRLG-2 SRLG-3 In this section, we discuss extensions to OSPF required for routing and topology discovery in optical networks. We motivate the need in each case. 1. Link bundling: Under standard OSPF, each physical link between a pair of OXCs would result in a routing adjacency. This means that routing protocol messages would be exchanged over each such link and each such link would be advertised to other OXCs in broadcast messages. Since the number of physical links between a pair of nodes could be large in optical networks, this would result in increased message broadcasting and processing overhead. To eliminate this, all the links between a pair of neighbors could be treated as a single logical routing adjacency. This procedure is called bundling [5]. With link bundling, routing protocol messages are sent over exactly one link even if there are multiple links connecting a pair of OXCs. Furthermore, the entire set of links is advertised in a single message. 2. Resource parameters: In an optical network, link state and resource information is used to compute primary and backup paths for a lightpath connection. This information consists of the representation of links and nodes in the network along with certain associated resource parameters (e.g., link cost, resource type and availability, SRLG information, etc.) that are critical to optimal and diverse routing of lightpaths. Standard OSPF does not provide the mechanism to disseminate such information through link state messages. Hence, the need to introduce optical LSAs, using OSPF s opaque LSA mechanism [3]. 3. Link state advertisement thresholds : Because link state advertisements capture resource availability, care must be taken to ensure that this information is not generated too frequently with minor changes in resource status. A configurable thresholding scheme (as discussed in Section II.D) can be used whereby an OXC would generate an LSA update only if the resource information changes significantly. This modification reduces the number of optical LSA updates. 4. Source routing methodology: Standard OSPF is designed for routing IP datagrams. Hence, under standard OSPF, each participating node would use an identical algorithm to compute a forwarding table that allows packets to be routed based on the destination address. Routing of an optical layer connection, on the other hand, requires that the entire path for connection be computed at the source OXC and signaled to other OXCs in the path. Since route computation is triggered by path setup requests only, we need to run the path computation algorithm at an ingress OXC only when the lightpath request arrives. The standard OSPF [2] uses Network LSAs and Router LSAs to distribute topology information within an area. Across areas, Summary LSAs are used to disseminate reachability information. Additionally, OSPF also uses External LSAs to import/export routes from other non-ospf routing domains. Network and External LSAs (used to insert static routes into OSPF) are not required in an optical network under the overlay model [9]. In this model, a set of IP routers are interconnected through a core network of OXCs which is used to setup connectivity between the routers. Thus, the core optical network does not require any knowledge of external routes, since lightpath requests originate and terminate at edge OXCs. II.C Optical LSAs A new opaque LSA, referred to as the Optical LSA, is used to disseminate optical resource related information. Standard link-state database flooding mechanisms are used for distribution of optical LSAs. Each optical LSA carries optical resource information pertaining to a single OLB, allowing for fine granularity changes in topology. The information is summarized at the OLG level, i.e., for each OLG contained in the OLB, the following is specified: (i) number of available, primary, and backup channels, (ii) set of SRLGs that the OLG belongs to, and (iii) cost associated with the OLG. The above extensions to OSPF are currently being standardized by the IETF [1]. OLs are discovered automatically as Link Management Protocol (LMP) [6] discovers new neighbors. OLs are grouped into OLGs (as discussed above) and this summarized information is included in optical LSAs.

II.D Link State Advertisement Thresholds In absence of any change in the network state, the optical LSAs are refreshed at regular refresh intervals of 3 min, just like other LSAs [2]. In addition to regular refreshes, LSAs need to be updated to reflect changes in the network state (topology and resource information). The following configurable mechanisms are used to reduce the number of optical LSA updates: Relative change based triggers: An update is triggered when the relative difference between the current and the previously advertised link state exceeds a certain threshold expressed as a percentage value. Anytime the number of available OLs in an OLG increases or decreases by more than the specified thresholds, an update should be generated. Absolute change based triggers: This differs from the above in that the measure of change is absolute, i.e., an update is triggered when the number of available OLs in an OLG crosses a certain configurable constant. II.E Lightpath Routing A lightpath consists of an SRLG-disjoint primary and backup path. Channels on the backup path can be shared among different mesh-restored lightpaths. The method of sharing [7] ensures that any single failure on the primary path of any lightpath can be restored. An enumeration based algorithm is used to generate candidate primary paths in increasing order of cost. The best sharable backup is computed for each primary and the least cost primary-backup pair is chosen. III ANALYSIS OF OSPF WITH OPTICAL EXTENSIONS In this section, we present an analytical model for estimating the control channel bandwidth usage due to optical LSA and router LSA updates. We also estimate the memory requirement for storing the LSAs, and the CPU utilization for lightpath computation. III.A Packet Sizes Type Size (in bytes) IP header 2 OSPF header 24 Optical/Router LSA header 2 Optical LSA body 152 Router LSA body 4 + #links x 12 We use the above packet sizes for IP and OSPF protocols. We assume that at the IP layer, the maximum size of an unfragmented packet is 1 bytes. Packet sizes for optical LSAs are obtained from a prototype specification at Tellium. We assume two diverse SRLGs per link, and hence, the number of OLGs per link is 4 (since OC-48/192 lines belong to different OLGs). III.B Bandwidth usage due to Optical LSA updates The maximum number of optical LSAs per IP packet is (1-2 - 24)/(2 + 152) = 5. The actual average number of optical LSAs per IP packet (= t < 5) depends on the number of such LSAs that the OSPF layer is able to pack into an IP packet. We assume a value of t = 3, as reported in [3] for three OSPF testbed scenarios. Hence, the effective length of an optical LSA is (172 + 44/t) bytes. The normal LSA refresh time per link is 3 min. Let the number of nodes in the network be n and the average node degree be d. Note that number of links (OLBs) is given by m = nd/2. Let H p and H b denote the average number of hops on primary and backup paths respectively in the network. If α is the average ratio of backup path hop count to primary path hop count, then H b = αh p. Let r denote the average number of backup paths sharing a backup channel. Then, the average channel usage by a lightpath demand is H p + H b /r = (1 + α/r)h p. Let λ denote the average rate of arrival of lightpath demands in the network. Then, the average rate of channel usage increase per link per second is λ(1 + α/r)h p. Assuming an uniform distribution over m links, average rate of OL decrease per link per second is λ(1 + α/r)h p /m. With an absolute change based LSA trigger threshold value of c, the average number of optical LSA updates associated with a given link per second due to change is λ(1 + α/r)h p /mc. We now consider two cases, depending on how the above update rate (triggered by changes) compares with the routine refresh rate of once every 3 min. Case 1: 1/3 min = 1/18 sec < λ(1 + α/r)h p /mc In this case, the average interval between change-based updates is less than 3 min. Hence, we can assume that refresh updates do not occur. Thus, the effective rate of optical LSA updates associated with a given link (per second) is given by R = λ(1 + α/r)h p /mc per sec. Case 2: 1/3 min = 1/18 sec > λ(1 + α/r)h p /mc. In this case, the average interval between change-based updates is more than 3 min. Let T (in seconds) be the interval between change triggered LSA updates. It is given by T = mc/[λ(1 + α/r)h p ]. Note that T/18 refreshes will have occurred before a change triggered update. Thus, the multiplicative factor for the effective LSA update rate in this case is ( T/18 + 1). Hence, the effective rate of optical LSA updates associated with a given link (per second) is given by R = kλ(1 + α/r)h p /mc, where k = T/18 + 1. Note that the expression for case 2 also holds for case 1, since if T < 18, then T/18 =. Hence, we will use the general expression for case 2 always. Since each link is advertised by both of its adjacent nodes, the bandwidth (bytes/sec) on an IP control channel due to optical LSA updates is (2m)[kλ(1 + α/r)h p /mc](172 + 44/t) = 2kλ(1 + α/r)h p (172 + 44/t)/c. Observe that this is linear in λ and H p. It turns out that case 2 is valid all the time for the data range

we considered. That is, the interval T for optical LSA updates due to resource change is more than the refresh interval of 3 min. In short, change triggered optical LSA updates are infrequent. Note that in the above analysis, we considered only the arrival of lightpath requests into the network. If λ is the steady state arrival of lightpath requests into the network, then lightpaths are also being deleted from the network at rate λ. A lightpath deletion causes a decrease in the channel usage on its links. Thus, in the worst case, the OSPF traffic generated due to lightpaths deletions could be similar to that for lightpath creations. Hence, we need to multiply the above formula by a factor of 2 to obtain the steady state OSPF traffic due to optical LSAs. Note that this is a conservative overestimation, since if the threshold c is greater than 1, then creation of lightpaths involving a given link could offset the channel usage decrease caused by deletion of lightpaths involving that same link, thus decreasing the variation in channel usage (from the last advertised value) on that link. To estimate λ, we assume that each OXC has 248 (2K) ports, 25% of which are drop ports. Thus, the total number of drop ports in the network is 512n. Since a lightpath uses exactly two drop ports, the maximum number of lightpaths that can exist in the network at any given time is 256n. If each lightpath exists in the network for an average of t h seconds (also called the hold time), then, by Little s formula [8], the steady state arrival of lightpaths into the network is given by λ = 256n/t h. An OXC in a typical PoP/CO (central office) has a small adjacency, i.e., it is connected to two, sometimes three, and rarely four other PoPs/COs. Hence, optical mesh networks have small average node degree, ranging from around 2.5 to less than 4. In this paper, we present the results for an average node degree of 3.5 unless otherwise stated. For networks with small average node degree d ( 4), the average primary (shortest) path hop count H p grows linearly with network size n, i.e., H p = an + b. The constants a and b (which depend on d) were determined by experimentation on a family of degree d networks of increasing size, generated by starting with a ring (uniform degree d = 2) and adding chordal edges. The values α and r have been fixed at α = 1.5 and r = 3.. These values have been found, through simulation [11], to be fairly representative of a wide range of network topologies. III.C Bandwidth usage due to Router LSA updates The maximum number of router LSAs per IP packet is (1-2 - 24)/(2 + 4 + 12d) = 956/(24 + 12d), where d is the node degree of the OXC. For an average node degree d = 3.5, this number is 14. As for optical LSAs, we assume the average number of router LSAs per IP packet to be s = 3 [3]. Hence, the effective length of a router LSA is (24 + 12d + 44/s) bytes. The normal refresh time for a router LSA is 3 min. Router LSA updates due to change are rare this happens only when no IP control channel is available between two adjacent nodes, i.e., the entire OLB on a link or a node fails. Hence, we ignore change-triggered router LSA updates for our calculation. Thus, the bandwidth (bytes/sec) on IP control channel due to router LSA updates is given by n(24 + 12d + 44/s)/18. Control Channel bandwidth (kbps) Optical and Router LSA bandwidth usage (absolute change based trigger threshold c = 1) 25 2 15 1 5 Figure 3: Bandwidth usage for optical and router LSAs with varying network size and lightpath hold time. Control channel bandwidth (kbps) 1 8 6 4 2 Optical and Router LSA bandwidth usage (lightpath hold time of 12 hrs) 3 min 1 hr 12 hrs 1 day 1 month c = 1 c = 5 c = 1 c = 15 c = 2 Figure 4: Bandwidth usage for router and optical LSAs with varying network size and triggering thresholds. Figure 3 shows the bandwidth requirement for optical and router LSA updates for OSPF areas of different sizes for different lightpath hold times. The trigger threshold is fixed at a typical value of c = 1. Lower hold time values of upto t h = 3 min represent a somewhat extreme real-time ondemand bandwidth provisioning scenario. Figure 4 shows the bandwidth usage for networks of different sizes and for different triggering thresholds. The lightpath hold time is fixed at a typical value of t h = 12 hrs. For both these plots, the average node degree is fixed at d = 3.5. Note that for a typical lightpath hold time of t h = 12 hours and trigger threshold value of c = 1, the peak bandwidth usage is just 88 Kbps for an OSPF area as big as 5 nodes.

III.D CPU Utilization for Path Computation Figure 5 shows the OXC processor utilization for path computation for different OSPF area sizes and lightpath hold times. The average node degree is fixed at d = 3.5. The algorithm is run on a randomly generated connected graph. Running times were converted to CPU utilization by multiplying with the lightpath arrival rates corresponding to different hold times. The peak utilization is observed to be 3.4% on a PowerPC 75 processor, for an OSPF area size of 5 nodes and a lightpath holding time of 3 minutes. % CPU utilization III.E 4 3.5 % CPU Utilization for Path Computation 3 2.5 2 1.5 1.5 Figure 5: CPU utilization for path computation. OXC Memory Requirement Figure 6 shows the OXC memory requirement for running OSPF with optical extensions. Since there are m optical LSAs and n router LSAs, the router memory (bytes) required to store all LSAs is given by 172m + (24 + 12d)n. Note that we ignore the support data stored with LSAs, which is minimal. As shown in the figure, memory requirement for a 5-node OSPF area with nodes of average degree 4 is a little above 2 KB. Memory requirement (KBytes) 2 175 15 125 1 75 5 25 LSA storage memory requirement Figure 6: OXC memory requirement for storing LSAs. IV CONCLUSION 3 min 1 hr 12 hrs 1 day 1 month d = 3. d = 3.25 d = 3.5 d = 3.75 d = 4. We discussed optical extensions to OSPF for routing and topology discovery in optical networks. Analytical performance analysis of these OSPF extensions shows that IP control channel bandwidth usage, OXC memory requirement, and CPU utilization should not be limiting factors for designing optical networks with single OSPF areas, even as big as 5 nodes. Our results contradict the common perception that single area OSPF does not scale beyond 5 to 1 nodes. There are several reasons for these apparently contradictory results: 1. A typical IP router network handles a large number of external LSAs originated by networks running other routing protocols. Since an optical network does not import external routes from other networks in the overlay model [9], it does not have to process external LSAs. Consequently, it can do away with much of the processing overhead [3] of external LSAs for a typical router in an OSPF network. 2. The OXC CPU processor used for running OSPF is much more powerful compared to the last generation of CPUs used in the routers and switches that led to the perception of OSPF s poor scalability, as reported in [3]. 3. In an optical network, paths are computed only by the ingress OXC when the path setup request arrives. This is very different from a typical router network where each node in the network has to compute the routing table each time an LSA is updated. Finally, note that for a lightpath spanning multiple OSPF areas in an optical network, restoration occurs independently in each area, since there is a backup segment protecting the primary path segment in each area. Hence, smaller restoration latency and higher reliability of service (and not OSPF scalability issues) could dictate a multi-area OSPF deployment with smaller area sizes. REFERENCES [1] T. E. Stern and K. Bala, Multiwavelength Optical Networks: A Layered Approach, Prentice Hall, May 1999. [2] J. Moy, OSPF: Anatomy of an Internet Routing Protocol, Addison-Wesley, 1998. [3] R. Coltun, The OSPF Opaque LSA Option, RFC 237, FORE Systems, August 1998. [4] J. Moy, OSPF Protocol Analysis, RFC 1245, July 1991. [5] K. Kompella, et al., Link Bundling in MPLS Traffic Engineering, draft-ietf-mpls-bundle-1.txt, November 21. [6] Jonathan P. Lang, et al., Link Management Protocol (LMP), draft-ietf-ccamp-lmp-2.txt, November 21. [7] Sudipta Sengupta and Ramu Ramamurthy, From Network Design to Dynamic Provisioning and Restoration in Optical Cross-Connect Mesh Networks: An Architectural and Algorithmic Overview, IEEE Network Magazine, July/August 21. [8] Leonard Kleinrock, Queueing Systems: Theory, Volume 1, John Wiley & Sons, January 1975. [9] B. Rajagopalan, et al., IP over Optical Networks: Architectural Aspects, IEEE Communications Magazine, September 2. [1] K. Kompella, et al., "OSPF Extensions in Support of Generalized MPLS", Internet Draft, <draft-ietf-ccamp-ospfgmpls-extensions-2.txt>, January 22. [11] StarNet Modeler TM, Tellium, Inc., http://www.tellium.com.