Experimental Study of Dynamic IP Topology Reconfiguration in IP/WDM Networks

Transcription

1 Experimental Study of Dynamic IP Topology Reconfiguration in IP/WDM Networks Kevin H. Liu, Changdong Liu, Jorge Pastor, Arunendu Roy, and John Y. Wei Network Operations and Management Research Department, Telcordia Technologies 331 Newman Springs Road Red Bank, NJ , USA Abstract -- With the widespread deployment of IP over WDM networks, it becomes necessary to develop dynamic lightpath and topology reconfiguration mechanisms and reconfiguration triggers that can effectively exploit WDM reconfigurability. A reconfiguration model for overlay IP/WDM networks is introduced. An IP over WDM network testbed has been set up using Telcordia MONET WADMs and IP routers. The testbed network and software architecture is presented and the trafficengineering experiments and convergence measurements conducted over the testbed are reported. I. IP/WDM INTERNETWORKING ARCHITECTURE As the emergence of multi protocol lambda switching (MPλS) control technique and optical packet switching equipment, there are two IP over WDM networking architectures: IP over reconfigurable WDM and IP over switched WDM [1], [2]. The former is constructed upon a circuit-switched WDM network whereas the latter is based on a packet or label switched WDM network. Under the first architecture, established circuits form a WDM lightpath topology that is reconfigurable in response to traffic changes and/or network planning. In the second architecture, e.g. in the case of Optical Label Switching, there is a unified IP/WDM topology build upon the packet-switched WDM network. In a switched WDM network, optical headers are attached to the payload data and are processed at each network switch. We focus on IP over reconfigurable WDM networks in this paper. The reconfigurable IP/WDM network we envision consists of IP routers attached to a WDM core network, or interconnected OXCs that are capable of processing IP packets. The reconfigurable IP/WDM inter-networking architecture is defined essentially by the organization of the WDM control plane. Three network models have been proposed, overlay, peer, and augmented model [3]. Under the overlay network model, the IP routing, topology discovery and distribution, and signaling protocols are independent of the routing, topology discovery and distribution, and signaling at the WDM layer. There are two alternatives to interface between IP layer and WDM layer. First, the two layers can communicate through the WDM This research is partially funded by the US Government DARPA NGI SuperNet project under the contract F C network management system. There is no direct interface between IP network and WDM network. This is similar to IP over ATM Soft Permanent Circuits (SPVC). Second, the two networks can interface directly through Optical User Network Interface (O-UNI). O-UNI is an edge module for the WDM network to serve IP client requests. O-UNI only support interfaces of lightpath request, deletion, and query because of the limited information shared between the IP and WDM layer. With the peer network model, control in the IP/WDM network is facilitated by MPLS control plan. Each WDM node consists of an integrated IP router and an OXC. The interaction between the router and OXC is still being developed. Signaling among various nodes is achieved using CR-LDP and with proper extensions. Under this model, the IP layer nodes act as peers of the OXCs, a common addressing scheme, presumably IP, will be used for both IP and WDM networks, such that a single routing protocol instance runs over both the IP and the WDM networks. The augmented network model is located in between the overlay model and the peer model. Under the augmented model, there are actually separated routing instances in the IP and WDM domains, but control information from one routing instance is passed through to another routing instance. An example implementation of the augmented model is that each of the IP and WDM domain runs an IGP instance, and interacts with each another through an EGP. This paper reports a testbed implementation and experimentation over an overlay IP over WDM network. IP and WDM are interfaced through O-UNI. II. A RECONFIGURATION MODEL FOR IP OVER WDM NETWORKS To leverage on the flexibility provided by WDM reconfiguration, IP topology formed by lightpaths can be changed dynamically. Fault, restoration, network provisioning, or traffic engineering can trigger IP/WDM reconfiguration. However, reconfiguration causes network instability. During the process of topology migration, the ongoing IP traffic may be delayed or even lost. If reconfiguration takes considerable time to converge, the transit network may form forwarding loops and therefore wastes network resources. In this section, we detail the reconfiguration processes, introduce reconfiguration convergence, and discuss reconfiguration constraints /01/$ IEEE 76

2 In our work, for reconfiguration and routing purposes, we model non-wavelength interchange WDM switch as a group of nodes, each of which interconnects a bi-directional wavelength channel (see Figure 1). The logical node can still add, drop, or pass through the traffic. λ Channel 1 λ Interchange Node λ Channel 2 λ Non-Interchange Node Traffic Add/Drop Port Fig. 1. WDM node modeling. A. Reconfiguration Processes In an overlay IP/WDM network, there are two tasks associated with IP topology reconfiguration, WDM reconfiguration and IP reconfiguration, respectively. WDM reconfiguration instructs the OXC and OADM to set up the desired lightpath topology and has the following components. Lightpath routing t lr : if the detail hops of a lightpath are not given in the reconfiguration trigger, the end-to-end path has to be computed dynamically. An example approach for wavelength routing and assignment is to use Dkstra SPF algorithm subject to constraints. Constraints that have to be considered include wavelength availability and wavelength continuity. Lightpath topology setup t setup : this includes a distributed signaling procedure and switches setup. Depending on the implementation, signaling may be responsible for local lambda selection as exploited in MPLS. Switch setup may require a reset operation before adding a new connection to the fabric. Routing convergence t wdm-c : this represents the time for the WDM routing information base to resynchronize after update. If a link state protocol is used in wavelength routing, this is the time for the link state database to converge. If WDM network uses a single and centralized connection manager to compute lightpaths, this represents the connection database update time once changes occurred. WDM reconfiguration time T wdm can be defined as ( tlr + t setup + t wdm c ) β t wdm c, 0 β 1, where β represents the overlapping factor between lightpath computation and setup time and WDM convergence time. IP reconfiguration alters IP interfaces status and address if necessary, and then waits for the routing protocol to converge. Hereafter, we use as the IP routing protocol as the link state protocol not only supports multiple metrics but also promises a faster convergence time. IP reconfiguration, T ip, includes the following components. Interface reconfiguration t if : the time to change the IP interfaces as specified in the new topology. Routing protocol convergence t ip-c : the convergence time. This includes the time for detection, propagation, and SPF recalculation. The number of calculations that must be performed given n link-state packets is proportional to nlogn in a modern SPF algorithm. convergence time is related to the size and the type of the network, e.g., the number of routers within each area, the number of neighbors for any one router, the number of areas supported by any one router, and the designated router selection. + t γ t, 0 γ 1, T ip can be written as ( if ip c ) ip c t where γ represents the overlapping factor between interface configuration and convergence. B. Reconfiguration Convergence When IP network topology changes, IP traffic must reroute quickly based on the new lightpath topology. IP convergence time describes the time it takes to an IP router to start using a new route after a topology changes. Reconfiguration convergence refers to the time that an IP/WDM reconfiguration has completed and IP and WDM network has converged. I.e. after a reconfiguration time interval, the new IP/WDM network is ready for another reconfiguration. Reconfiguration convergence time T r can be written as T ip + ( 1 α ) T wdm, 0 α 1, where α is the overlapping factor between IP reconfiguration and WDM reconfiguration. To minimize T r, IP and WDM reconfiguration should be conducted in parallel. However, migration schedule may require serialization between certain IP and WDM reconfiguration processes to reduce instability and/or avoid traffic lost. Application impact due to reconfiguration is within the interval of T r - t wdm-c since applications do not require WDM network convergence. C. Reconfiguration Constraints There are two groups of WDM reconfiguration constraints: client-imposed and network-oriented reconfiguration constraints. Clients may prefer specific path or have special requirement for certain reasons. Client imposed constraints include Source and sink end points: these are usually given in terms of switch names. The network control and management system (NC&M) will also accept port names. Connection directionality: bi-directional or unidirectional. Disjoint path: there are many scenarios that client may demand a disjoint path. For example, client asks for two bidirectional connections between the same source and sink switch with disjoint paths. Another example is requesting a bi-directional wavelength channel with disjoint fiber path. Preferred lambda: different lambda on the same fiber may have different signal quality. 77

3 Number of hops: in all optical networking, in particular with all optical wavelength conversions, end-to-end signal quality may not satisfy user requirement if too many hops are used. Hence, a client would like to enter the number of hops as an explicit routing constraint. Wavelength protection: this indicates whether the client requires wavelength protection. This can be a Boolean value. Or the NC&M may support a number of wavelength protection schemes. Wavelength restoration: if a client prefers a wavelength restoration scheme, the request can be entered in this field. This can be a Boolean value. Client signal type: an OADM may support several client signal formats, such as SONET, Gigabit Ethernet. Line rate: the preferred connection data rate. Other physical link QoS requirements: o Optical Signal-to-Noise Ration (OSNR), o Wavelength dispersion. In addition to client-imposed constraints, there are reconfiguration constraints that are determined by the WDM network properties. These network-oriented constraints include Fabric type: a rather simple classification bases on fabric transparency, according to which a fabric can be either opaque (O-E-O) or transparent (all optical). Certain fabric implies certain routing constraints. For example, minimum number of hops is desirable in a transparent subnet. Number of wavelengths per TI/CI fiber. Wavelength availability. Wavelength interchange capability. Wavelength signal quality: o better OSNR, less dispersion, o path stability, e.g. avoiding fast switching fiber, o preferred wavelength with less cross talk. Protection and Restoration capabilities of network/ems. III. TESTBED NETWORK ARCHITECTURE As shown in Figure 2, the IP/WDM testbed network contains two different types of node: optical lambda routers and electronic IP routers. The lambda routers provide the lightpath switching mechanism that enables IP topology reconfiguration. They are built using Telcordia s MONET WADMs, and PC-based internal IP control routers. The WADMs support wavelength-selective cross-connections. They support eight wavelength channels at the transport interfaces (TI) and corresponding single wavelength channel client interfaces (CI) for add drop. The CIs are used to connect to the electronic IP routers. Each WADM has a corresponding NE controller that connects to its internal IP control router. WDM signaling messages that trigger connection setup and release are translated into NE add, drop or cross-connect messages conveyed across this interface. The internal IP control routers are connected by a point-to-point Ethernet that mirrors the point-to-point topology of our WDM network. The input signals from the electronic IP routers are translated into MONET compliant wavelengths external transponders. The four electronic IP routers connected to the WADMs are actually PCs running Linux. These IP routers are each equipped with two single-mode ATM network interface cards. The routers are connected using IP/ATM OC3 point-to-point PVC connections. All these managed elements are connected to another Ethernet subnet, which serves as our data communication network (DCN). The DCN is used by our GUI and Traffic Engineering (TE) components to communicate with the managed elements. Ethernet DCN IP Routers Transponders IP Host Computer Fig. 2. IV. ATM Links IP Router NE Controller WADM 1 Lambda Router GUI PtoP Ethernet IP Router NE Controller Multiwavelength Fiber WADM 2 Lambda Router Transponders ATM Links Testbed hardware architecture. TESTBED SOFTWARE ARCHITECTURE IP Routers Figure 3 shows the testbed software architecture. In the IP network, each of the Linux based PC router runs to support IP packet routing. To facilitate IP topology reconfiguration, an interface configuration manager () is developed which interacts directly with the Linux kernel and the routing protocol to modify the state and the address of an IP interface. The MONET WADMs are each controlled by corresponding NE controllers that export the MONET NE-NC&M interface that can be used to provide element-level management functionality. To enable reuse of IP control protocols for WDM layer control [4], we extended and modified the and protocols to address WDM specific concerns and to support lightpath routing and setup. Example extensions include wavelength MIB construction and maintenance, WDM link state update, connection discovery, bi-directional LSP setup, and message extensions for explicit lambda path setup. To handle the wavelength constraints of a WDM network, a algorithm is implemented to compute the explicit lightpath. 78

4 A GSMP like optical switch control protocol (OSCP) is designed and implemented. It provides the interface between the NE controllers and the WDM network-control modules and can accommodate network and system heterogeneity among NEs. Four sets of OSCP messages including configuration, connection, reservation, and event notification are implemented in the current version of OSCP. OSCP is transported over TCP socket and message data is encoded using External Data Representation (XDR). GUI IP Virtual Topology Correlation & WDM Capacity IP/WDM Physical Topology Reconfiguration Triggers Traffic Engineering Migration Scheduling Topology Design Algorithm Traffic Monitor Optical User-Network Interface (UNI) IP Network WDM Network Optical Switch Control Protocol (OSCP) Fig. 3. Testbed software architecture. The Traffic-Engineering trigger consists of three modules: traffic monitor, topology design algorithm, and migration scheduling. IP traffic monitoring is based on the libpcap package that provides packet level capture and monitoring. Raw interface-related and source-destination data are first processed, analyzed, and aggregated before being fed into a topology design algorithm. The topology design algorithm in turn is able to compute an optimal or near-optimal IP topology according to the collected traffic demand data. To minimize the impact due to reconfiguration, the migration module schedules topology migration into a series of steps or phases. Fig. 4. Testbed management GUI. Although both the IP and the WDM layers utilize IP addressing, the implementation follows an overlay networking model where topology and resource information are not shared between the layers. Rather a user-network interface (UNI) is defined to bridge the IP layer and the WDM layer. Lightpath request, deletion, and query interfaces are supported in the UNI implementation. UNI messages are also transported over TCP sockets. In addition, a management GUI (see Figure 4) has been developed to display IP/WDM network information, which includes IP topology, IP/WDM physical topology, IP traffic distribution, IP link load utilization, and IP link to WDM route correlation. V. EXPERIMENTATION To evaluate the effectiveness and the network performance of IP topology reconfiguration, we loaded the IP layer with selected traffic patterns and compared their performance under different topologies. Our experimentation shows that traffic engineering can indeed trigger IP topology reconfiguration to increase overall network throughput due to a reduced average weighted-hop-distance, defined as WHD= flow hop flow. We have also conducted a ( i, j) N ( i, j) N simulation study on the performance benefits of topology reconfiguration. The result is reported elsewhere. To study the application impact, the network convergence, and the network performance due to reconfiguration, we designed the following scenario (see Table 1.) The traffic demand is made of four flows, namely f13, f14, f23, and f24. There does not exist a better way, in the topology before reconfiguration, to route/reroute any flows to exploit unused link capacity (e.g. links between and ). Therefore, without reconfiguration, there is no room to further increase the total throughput. The same set of flows, however, can each alone occupy a full link in the reconfigured topology. This scenario clearly shows the additional advantage in reconfiguration-based traffic engineering over fixed topology multi-path routing. We used the ttcp utility to generate the intended UDP flows, and to collect the per flow statistics. The results are listed in Table 1. The average rate at the transmitter side in Table 1 reflects how much demand a transmitter can push into the network under current network loading status. The average rate at the receiver side is the actual sustained throughput, and is normally smaller than its transmitter peer because of packet loss. In this experiment, observe that the two-hop flows (i.e. f14 and f23) got higher throughput than singlehop flows (i.e. f13 and f24). This is because at a router such as, it services two flows: a single hop flow injected from user space, and a two-hop flow forwarded through this router in kernel space. The kernel level forwarding process is favored over the user level injection process. As a result, the two-hop flow gets more share of resource resulting in higher throughput. In contrast, all four flows can be fully 79

5 Table 1 Performance comparison of different network topologies under the same traffic load. topology flow end point total bytes total packets average rate (Mbps) packet size WHD Tx 819,200, , f13 Rx 816,406,528 99, f14 Tx 819,200, , Rx 811,294,720 99, f23 Tx 819,200, , Rx 814,407,680 99, before reconfig. Tx 819,200, , f24 Rx 818,896,896 99, Tx 819,200, , f13 Rx 818,331,648 99, ,192 bytes f14 Tx 819,200, , Rx 818,257,920 99, f23 Tx 819,200, , Rx 815,865,856 99, Tx 819,200, , f24 Rx 818,216,960 99, after reconfig. reconfiguration convergence related measurements over the testbed. Table 2 Reconfiguration time over testbed. Per switch t setup t lr (s) t wdm-c t if t ip-c setup time (s) (s) (s) (s) (s) supported in the new reconfigured topology. Consequently, throughput of each and every flow got increased. Using traffic engineering as a triggering mechanism, we have conducted reconfiguration convergence testing and collected measurements. convergence time is related to its timer tuple setting, (hello interval, router dead interval, poll interval, retransmission interval, transit delay interval). By default, the timer tuple has these values (10s, 40s, 120s, 5s, 1s) as suggested in the specification [5]. By suitably tuning timers, the routing convergence time can be reduced. Based on this tuple setting (5s, 15s, 10s, 5s, 1s), we have observed the reconfiguration convergence time between 19 to 20 seconds. The reconfiguration process time is shown in Table 2. Setting the timer tuple into a much smaller internal, e.g. hello interval in milliseconds, will result in more control traffic in the network. Without QoS mechanisms to queue the control packets in front of data packets, the network may be hard to converge. To study the application impact, we have setup different end-to-end applications including RealVideo and HTTPbased MPEG movie broadcasts over our testbed. We observed and measured the effects of IP topology reconfiguration on these applications flows. In all cases, the TCP data flows of host applications fully recovered when the topology reconfiguration process converges. VI. CONCLUSIONS In this paper, we have introduced a reconfiguration model for overlay IP/WDM networks after reviewing IP over WDM internetworking architectural issues. We have constructed an IP over WDM network testbed using Telcordia MONET WADMs and have developed a trafficengineering triggered reconfiguration system prototype based on the GMPLS/MPλS framework. We performed traffic engineering experiments and collected ACKNOWLEDGEMENT The authors wish to thank Gee-Kung Chang, Brian Meagher, and Jeffery Young, for their help on SuperNet testbed network setup. The material presented here is based partially upon work supported by the Defense Advanced Research Projects Agency under Contract F C Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the Defense Advanced Research Projects Agency, or the US Government. REFERENCES [1] Wei J.Y., et. al, "Network control and management for next generation Internet," IEICE Transactions on Communications, Vol.E83-B, No.10, pp , Oct [2] Mannie E., editor, Generalized Multi-Protocol Label Switching (GMPLS) Architecture, IETF Internet Draft, Feb 2001, [3] Aboul-Magd O. S., et al., "IP over optical networks: a framework", Aug 2000, [4] Kompella K., et al., Extensions to IS-IS/ and in support of MPL(ambda)S, IETF Internet Draft, Feb 2000, [5] Moy J., Version 2, IETF RFC 2328, Apr