CastFlow: Clean-Slate Multicast Approach using In-Advance Path Processing in Programmable Networks

Size: px
Start display at page:

Download "CastFlow: Clean-Slate Multicast Approach using In-Advance Path Processing in Programmable Networks"

Transcription

1 CastFlow: Clean-Slate Multicast Approach using In-Advance Path Processing in Programmable Networks Cesar A. C. Marcondes, Tiago P. C. Santos, Arthur P. Godoy, Caio C. Viel and Cesar A. C. Teixeira Computer Science Dept., Federal University of São Carlos, (UFSCar) São Carlos - SP, Brazil {marcondes, tiagopomponet, arthur.godoy, caio viel, Abstract Multipoint communication is an important requirement for many types of applications such as videoconferencing, IPTV and online radio. However, the division of Internet in autonomous systems hinders the widespread adoption of traditional multicast protocols, which, for using distributed algorithms, delay the group control events processing. This paper proposes a multicast clean-slate approach logically centralized based on programmable networks and anticipated processing for all routes from each possible source, aiming to reduce event delays. A prototype was implemented based on OpenFlow technology. In addition, extensive evaluation was performed and results show promising delays comparable to the requirements of multipoint applications. Keywords : Multicast, Software-Defined Networks, OpenFlow, Network OS, Network Services. I. INTRODUCTION Some types of applications, as chat or video conferencing, require communication between multiple host. While others, like Internet Protocol TV (IPTV), take the services of a content provider, which sends identical data for many subscribers. These last applications could use IP Multicast to perform multipoint communication, avoiding the waste of bandwidth by sending redundant data across multiple unicast connections. Due to the distributed feature of the current Internet, with each router performing part of the routing algorithm, multicast routing protocols, such as Distance Vector Multicast Routing Protocol (DVMRP) or Multicast Open Shortest Path First (MOSPF), are not efficient to make changes in the multicast tree. This is because it is necessary to wait routers exchange information among themselves and update their routing tables, which can be a slow process. In addition, the Internet Group Management Protocol (IGMP), responsible for controlling the host join and leave from the group, may need to send messages to multiple routers to notify the occurrence of group events [1]. Using a logically centralized approach to perform multicast routing may offer several advantages over the distributed approach. For instance the possibility of creating an optimal distribution tree for each occasion, because a centralized algorithm has a complete view of the topology. It would also be possible to process control group events quickly without creating flood of messages, as happens in the distributed approach. Many applications require changes on-the-fly in the multicast group. For example, each channel on an IPTV service could have a related group. A user when zapping would be entering and leaving multicast groups. Using the distributed approach of the IP Multicast would not be an efficient solution for zapping., as IGMP introduces significant delays in join and leave from groups [2]. In the logically centralized approach, the element responsible for routing knows which branches should be added or removed from the multicast tree to respond to joining and leaving hosts. Considering that the process of reconfiguration of the routers is fast, the changes in the multicast group would have a low-latency. With a unified view of all multicast groups, it would also be possible to aggregate in a forest all multicast trees. The forest would use the same multicast trunk for data dissemination. As a consequence, the number of entries in the routing tables could be reduced, promoting greater scalability and even better routing performance. In this paper it is proposed a multicast clean-slate approach on which the calculation of all possible routes from sources to group members is done in advance, in order to speed up the processing of events in multicast groups (join, leave and the source change). A prototype using OpenFlow [3] was implemented to help understanding the initial cost with routes calculation and characterizing the time spent processing the events. Experiments were performed in the emulated topologies generated in a single laptop using Mininet [4]. The topologies analyzed were generated by the tool BRITE [5]. The results obtained with our experiments, as well as with the complexity analysis of the algorithms, indicate that the amount of time to calculate routes and group events processing may be smaller, when compared with values obtained using logically distributed techniques. This way the logical centralized approach is interesting by improving the response time of group events processing, allowing smooth changes in the multicast group and better group management. In section II it is detailed the approach used in distributed multicast in the IP multicast. Section III discusses how to use the OpenFlow technology to implement the clean-slate multicast. Section IV details the developed prototype. In section V it is presented the experiments and results. Section /12/$ IEEE

2 VI discusses the impact of the results in one application. The related works are analyzed in Section VII. Section VIII presents the conclusions and future work. II. IP MULTICAST Multicast is the technique of sending packets to a specific group of hosts on the network, allowing communication in model 1-N or N-N. The main benefit of using multicast is the reduction of the traffic, due to the replication of messages supported by the routres. This is the most appropriate method to disseminate information for many categories of applications from multipoint, streaming, distributed systems and faulttolerant systems. The IETF RFC 1301 specifies two types of protocols that manage the multicast on Internet: the multicast routing protocols and the group control protocols. The multicast routing protocols are responsible for determining how packets are distributed (e.g., using a tree), having the goal of avoiding redundancy of information and preventing loops. Examples of these are DVMRP, MOSPF and Protocol Independent Multicasting (PIM). Complementing the functionality of routing, the protocols for group management are responsible for controlling of join and leave events in the groups. IGMP and the Multicast Listener Discovery (MLD) are the protocols adopted by IPv4 and Ipv6 respectivelly. The DVMRP protocol is a modification of the Routing Information Protocol (RIP). It uses unicast routing tables to keep information of the distance from each router to the destination (IETF RFC 1705). It is the protocol widely used in the network MBone [6].. Nevertheless, scalability problems are faced as it is necessary to update the information in the routing tables every time a host joins or leaves a group [7], which can take several seconds. As MOSPF protocol is based on the Open Shortest Path First (OSPF), which uses link states to build the shortest path trees to the destinations, routers changes require costly operation for the dissemination of link states. Unlike others, the PIM (IETF RFC 2362) is not based on an adaptation of unicast protocols. Instead, it has different operating modes to suit both dense and sparse topologies. This adds complexity, making difficult its setup. The group control protocols, such as IGMP or MLD, function similarly. A router IGMP querier is elected and becomes responsible for managing the events of the groups. The querier sends out periodics IGMP Query to identify which hosts participate in a particular group. Hosts already on the group and entrants to enter the querier must respond with the message IGMP Report. From the IGMPv2, each host leaving a group must notify the querier messages with IGMP Leave Group. When the router detects that a host is out of a group, it checks if there are still entries in the table for active hosts. If there is no other active host left, the querier removes the table entry IGMP groups and promotes the pruning of the multicast tree branch. Note that the IGMP management messages are sent together with the user data generating network overload. III. RESTRUCTURING THE MULTICAST WITH OPENFLOW The OpenFlow protocol is based on programmable switches that combines flexibility in developing new software defined network applications while easing the burden for manufacturers to adapt legacy switches. OpenFlow switches (OF) are capable of forwarding packets using rules defined in the socalled flow tables. In addition, there is a controller element connected to the switches OF. On the controller, network applications process network events, such as flow arrivals and using the OF protocol, it remotely control the OF switches, managing network flows at any granularity [3]. With the programming flexibility promoted by the controller on OF networks, it is possible to completely rethink multicast routing protocols without the use of complex and error-prone distributed algorithms. This is the novel approach used in this work. In this new multicast approach, it was taken into account the following design decisions: (1) separate data plane from control plane, (2) centralize the calculations about the multicast tree, (3) manage events related to multicast groups, (4) allow rapid changes in the multicast tree; and (5) prevent bottlenecks and increase reliability/availability. These decisions enable an optimized multicast from the network point of view, with a high processing rate of joining and leaving participant hosts consistent with stringent requirements of applications, such as IPTV and others. The following describes how these design decisions were incorporated in the solution. A. Separate data plane from control plane In the distributed multicast, the multicast-enabled routers are responsible for both, the forwarding of packets and the exchange of multicast routing messages. This creates an extra overhead, in terms of bandwidth consumption, whenever control messages (such as joins, tree updates, etc) along with traffic data are sent through the same links. This issue was identified early as a limitation in [8]. In that work, there was a proposal for the use of one or more central elements responsible only for the routing algorithm, using a control network separated from the data path. However, it was never deployed due to the ossified nature of the Internet. With the increasing deployment rate and popularity of Openflow, and since, the separation of control and data planes is already in place in OpenFlow. Our multicast solution can rely on a separation of the data and control planes. B. Centralize the calculation about the multicast tree It can be observed that the behavior of multicast trees is unpredictable due to the large number of joins and leaves events from participating hosts over time [8]. Therefore, it is useful to adopt a mechanism that has full knowledge of the network topology and pre-compute optimal multicast trees, opportunistically depending on every occasion. This method would be better than the distributed multicast routing. In the latter, a high rate of hosts joins and leaves can destabilize the optimal tree turning the stabilization process really slow or even impossible /12/$ IEEE

3 The application running on OpenFlow controller would be responsible for calculating opportunistically the multicast tree. Thus, using the information about the topology, the active multicast group, joins and leaves, this application, in every event, step-in and re-calculates the minimum multicast flow tree. C. Management of Multicast Groups The hosts that participate in a particular multicast group need to be managed, as in the IGMP protocol. Thus, a management mechanism that allows hosts to enter and leave a multicast group is needed. In addition, the admission of the host, and further validation through a list of allowed hosts (for example, subscribers of a specific IPTV service) are basic features required. Furthermore, the application must be also responsible for handling multicast source request changes. As in the previous design decision, the group management should be running on the controller, but, it could be using a separate and specialized service of multicast group management. Therefore, it decouples the multicast routing algorithm from the group admission algorithm itself. This removes constraints by allowing multiple co-existing policies for admission without the need to modify the routing algorithm. Another beneficial side effect is that, since the controller is directly connected to OpenFlow switches by out-of-band network and protocol (control plane), there is a desirable higher level of security between the host and controller in terms of multicast group management. D. Rapid Changes in the Multicast Tree For certain types of applications, such as IPTV zapping, there may be intense changes in the multicast group size and dynamics. In such cases, hosts could be joining and leaving the group all the time, as well as changes in the source of the group (as pointed out). Thus, in order to be efficient, it is necessary to have a mechanism capable to modify the multicast tree on-the-fly quickly. The decision made was that the application should calculate in advance all the possible path routes for a given multicast group and kept a fast and efficient list of installed and active links/routes in the controller application. Whenever an event happens, the group controller would notify the OpenFlow controller, which would then remove or add entries in the specific flow tables of the OF switches. E. Bottlenecks, Reliability and Availability A central element can eventually limit the scalability of the system, because it may be unable to meet the demand of the system as it grows, creating a bottleneck. In addition, the reliability and availability may be low, since the central element is a critical point of failure. Although we acknowledge this as a problem, this has been also a criticism point of OpenFlow itself.however, several studies have been proposed to circumvent or reduce these problems. For example, [9] implemented a distributed OF controller that reduces the problem of scalability and is also suitable for fault tolerance. This way, the proposed multicast solution can also leverage from these general OF scalability solutions. IV. CASTFLOW Fig. 1: Multicast Tree Creation Workflow CastFlow is a public and open source proposal for a multicast clean-slate approach in programmable networks.the idea is to handle large amounts of hosts that can dynamically enter and leave the multicast group. Hence, the event processing efficiency of the control group becomes critical. In order to enhance the processing of such events, we make calculations in advance of all possible routes during the setup of the multicast group, avoiding the need for route calculation afterwards, when the events are been processed. In addition, there is a careful scheme based on path differences that performs the fewest possible changes in the flow tables)of the OF switches, in response to group events. The following describes the architecture and workflow of CastFlow, and the main mechanisms for route calculation and the processing of group events. A. Route Calculation We will first introduce the process of route calculation used by CastFlow to create multicast trees (Fig. 1). In order to achieve realism and to ease topologies generation for tests, we use in our prototype the BRITE tool. Using it, it was possible to generate software artifacts that represent a network topology. Afterwards, we parameterize the topology creation process by using an uniform distribution to select a host s subset, from all nodes of the generated topology, to act as active members of the multicast group. Finally, one of the hosts is chosen to be the multicast source. From the graph that represents the topology, a minimum spanning tree (MST) centralized on the multicast source is calculated using the PRIM algorithm. The PRIM algorithm generates the minimum spanning tree as a function of the weights associated to the edges of the graph and has complexity O(E log V) [10]. For the purposes of this study, the weight of each edge was defined as the path cost distance between the edge and the source of the multicast, and this yields optimal MSTs. Proving by contradiction, suppose there is a shorter path (PL) for a given node (Ni) than that found by PRIM (PP). From one point of the graph, the edges of PL have lower weights than those of PP. However, the PRIM is a greedy algorithm 1 https://github.com/caioviel/castflow /12/$ IEEE

4 (a) Shortest Path List (b) Links List (c) Sources Path List Fig. 2: CastFlow Main Data Structures and always uses the smallest edge weight, finding the path PL instead of PP (QED). With the MST and the information for which hosts are part of the multicast group, the paths are calculated between the source and the hosts of the group, generating a list of shortest paths (Fig. 2a). This list of paths is further processed to remove redundancies, generating a list of links inside the MST (Fig. 2b). Through the list of links, the controller can easily add entries in the flow tables of OF switches to create the routes of the multicast tree. B. Prototype Architecture The prototype was developed as a proof of concept for this proposal can be illustrated in Fig. 3. It consists of 4 main components: (1) toposerv, (2) udpapp, (2) mnscript and (3) noxapp. 1) toposerv - Topology Server: This component is responsible for providing information to other components about the network topology and the multicast group configuration. He also receives and validates control group events (such as joins and leaves) and performs analysis from BRITE files in order to define the underlying topologies. In a real situation, the last functionality would not exist, because the topology would be real, instead of an emulated one, as it was performed in our evaluation. Despite, in any case, the information about the topology and events would still be sent from this component. In some aspects, toposerv can be considered as similar to the IGMP protocol, because it is mainly responsible for the multicast group management and control. 2) udpapp - UDP Multicast Application: The udpapp is an application developed specifically for the testing phase of the prototype. It assumes the role of a real multicast application, as for example, a video conferencing application. It has two operational s mode: client and server. In client mode, it only receives packets sent by another instance in server mode and display confirmation messages in the standard output. In server mode it keeps sending continuously data packets at intervals of 33 milliseconds, in order to emulate data traffic from an application performing video streaming at a rate of 30 frames per second. The server is bound to the allocated multicast IP address. The communication performed by udpapp is datagram oriented. In order to proceed with the prototype multicast tests, it was initialized an application in server mode at a random participating host as the multicast source. Then, this instance sends packets to the multicast group IP address, specifically allocated for this group. In the tests, the other hosts of the multicast group run instances in client mode, receiving the packets sent by the multicast source. 3) mnscript - Mininet Script Manager: The tests were instantiated from a network emulation using the component mnscript that uses the Mininet API to build the network topology directly, with nodes and switches, from a BRITE file. It also adds an entry in the ARP table for the multicast group address and initializes instances of udpapp in client mode on each host of the multicast group. Based on requests from the toposerv, it gets the information about the topology that must be created and the description from the multicast group. In a real situation, the mnscript would not exist, because there would be a real network topology and the client applications would be initiated on demand by users. 4) noxapp component: The noxapp is the application that runs in the openflow controller. We decided to use the NOX controller [Gude et al. 2008] in our prototype. During the setup of each experiment, noxapp obtains topologies informations and multicast group by toposerv and perform the calculation in advance of all possible routes, considering a different multicast tree for each possible source of the multicast group. Then it creates entries in the switches flows tables to map the initial multicast tree. Noxapp also register itself in toposerv for receive all multicast group events. When a events occur, toposerv notifies noxapp that will remove or add the entries in switches flows tables to perform the event. C. Multicast Group Processing Events One of the main features of the proposed multicast approach is the fast processing of the multicast group events (joining and leaving participant hosts or changing the main multicast source). For this, it is calculated in advance, during the setup of a multicast group, all possible routes between all possible multicast sources and each hosts of the multicast group. Those routes are stored at noxapp in a data structure called route map. The route map is composed of two linked hash tables (in python), the first table maps the possible multicast sources with a second hash table. Each second hash table maps the hosts of the multicast group with the path between it and the multicast source. Figure 2c contains a graphical representation of the route map /12/$ IEEE

5 Fig. 3: CastFlow Prototype Architecture In addition to the route map, we also maintained a list of installed links at noxapp. This was, whenever an input event is received, the paths between the current source and joining nodes are obtained in constant time through the route map. Afterwards, the list of installed links is traversed in order to verify if any of the link (from the source to the joining node) must be installed or overwritten to add the new paths to the multicast tree. The result of this process is a difference list of links that must be installed in other words, the new branch to be inserted onto the tree. For leaving events the process is similar. We get the paths to the nodes that are leaving from route map and traverse up the list of installed links, to check what links need to be removed or overwritten. The result is the branch of the tree should be pruned. Finally, events of changing a multicast source are the most complex to handle. First, we get the new paths between the source and all active nodes in the multicast group directly, in constant time, from the route map and traverse up the list of installed links to see which links were due to be removed, added or overwritten. V. P ROTOTYPE E VALUATION A. Test Environment The experiments were performed in virtual network topologies emulated by Mininet. We generated five different topologies using BRITE tool with a number of routers ranging from 10 up to 50. In each of the routers we connected a host. The toposerv performed the analysis of the files generated by Brite, mnscript and sent to the topology that should be emulated for a given experiment. Also we used a simplification of the MBone topology in the experiments. A simplification of the real topology, considering each site as an MBone router, totaling 84 routers. The multicast group, multicast source and the initial active hosts were chosen at random, following a uniform distribution. The mnscript start instances of udpapp applications in client mode in each client hosts, this way the udpapps can collect data during the experiments /12/$ IEEE The toposerv was programed to generate input events, output events or source changing events in a given time interval. These events were randomly generated also following a uniform distribution, and sent to noxapp, which installed or removed routes as needed to process the event group. Udpapp instances (running on each host) and noxapp (running on the controller) stored text files containing the collected data. The experiments were repeatedly performed to assure that the data obtained were statistically consistent. B. Experiment 1: Setup Time of a Multicast Group The objective of this experiment is to characterize a setup time of the multicast group. For this was used the simplified topology representation from Mbone and varied the size of the multicast group (number of hosts) of 10 up to 50 hosts. Figure 4a presents the results obtained in experiment 1. We observed that the calculation in advance of the routes was the slowest process during the setup. This was expected, since this is precisely the proposed tradeoff: to make calculation of all possible routes during the setup of the multicast group to minimize the delay in the processing of group events. The time used for the calculation in-advance presents nearly a linear growth, due the time spent processing a MST depends on graph edge number. As the topology was fixed the time is constant. A different tree is computed for each possible source (in this experiment, all the hosts of multicast group are potential sources), the spent time by calculation in-advance is directly proportional to the group size. The processing time of routes, which is small compared to others setup steps, corresponds to the time it takes to noxapp to define which routes will be added to the switches. The flows installation time grows in proportion to the number of installed entries in the flow tables of the routers. C. Experiment 2: Joining and leaving hosts The objective of experiment 2 is to characterize the effect of join and leave events of hosts in the multicast group. For this we used five different BRITE topologies with increasing size. In each topology we fixed multicast group size and the

6 (a) Multicast Group Configuration (b) Event Processing (c) OF Switches Configuration Fig. 4: Setup Times number of active hosts and varied the amount of hosts that joined and leaved. Figure 4b shows the average time required to process the events in the topologies of 40 and 50 switches. Figure 4c shows the reconfiguration time of the switches for some of the scenarios analyzed. Figure 5a presents data relating the number of switches affected by the join events. The processing time of the events is rather small, in the order of milliseconds, and it grows as the size of the topology and the number of hosts involved in the event increases. This shows that the calculation in advance of routes reduces the processing time of the events. The measured time configuration of the switches seems to be proportional to the number of hosts participating in the event that directly influence the number of affected switches. We also can notice that the configuration time of the join events is generally greater than leave events. The time spent to configure the switches, in addition to being large, presents a great variability. For the same scenario, settling an equal number of routes, there were a few times smaller than 0.01 s and others close to 1s. Such variability may be partly explained by the network emulation environment of Mininet. The same machine is running the controller, hosts udpapp applications, besides all the network infrastructure emulated by mininet. All the various processes are competing for machine resources such as CPU, causing interference. These interferences were not detected significantly in experiment 1 because the routes had not yet been installed. Thus the client applications udpapp were blocked waiting for packets sent by the source, the switches were not performing packet forwarding. In a related work, [12] proposes a framework for assessing the performance of OpenFlow switches. In that work the authors evaluate different OpenFlow switches, achieving less than 1 ms for the installation or modification of entries in the flows table. In work [13] built a OpenFlow switch in hardware using the technology NetFPGA that was able to add new entries in its flows table in 11 ms. Despite the high times observed in experiment 2, which suffered greatly influenced by the test environment, we believed that in real scenarios, such as those used in the work of [12] and [13], the total time spent on configuration of the switches is much smaller and grow linearly with the number of switches affected by the event. For example, considering switch setup time of 1 ms, for the scenario of the topology of 50 nodes, with 8 hosts joining in an event we would be spending around 13 ms for the configuration, totaling just over 15 ms between the time that the controller is informed of the event and the route reconfiguration was completed. The time for the switches configuration could be further reduced if a parallel programming adopted. The configuration messages would be sent simultaneously to all or groups of switches, rather than serially, as is the standard controller Nox. Other implementations of controllers can significantly increase the flow of creation or modification of entries in the flows table using multi-threaded approach [14] /12/$ IEEE

7 (a) Join Events (b) Leave Events Fig. 5: Number of Switches/Nodes affected by input/leave events D. Experiment 3: Multicast Source Change The objective of experiment 3 is to characterize the effect of source changing events. For this, we used five different BRITE topologies with increasing complexity. In each topology was fixed the multicast group size and the number of active hosts. Figure 6a shows the average time to process the events. The graph in Figure 6b shows the average number of switches affected by the events. Both the processing time of the events and the number of routers affected by the event presents an upward trend as the number of nodes in the topology increases. The processing time of events is small, similar to that seen in the join and leave of the experiment 2. Note also that, on average, half switches of the topology are affected by the source change. Figure 6c compares the time until complete and proper adequacy of flows in various testing samples, with the average time for the hosts from request join the group until begin receiving data from the new source. It is noticed that in some situations hosts starting to receive data even before the adjustment is completed. Although the complete adequacy of flows likely to be a slow process, many hosts can start receiving the new data source before the process is fully completed. VI. CASE OF STUDY: IP TV To justify the use of CastFlow we considered the case study of IPTV. A typical IPTV service can have a large subscriber base and provide a lot of channels. Each channel can be associated with a different multicast group, in which the multicast source would be the very TV station content servers, and the rest of the multicast group would be composed of subscribers who are watching the channel. In the imagined scenario, the initial multicast group setup would be calculated whenever there was change in the subscriber base. According to the results of experiment 1, the time of this calculation is not prohibitive and grows almost linearly. Furthermore the sources are restricted to the TV stations content servers which makes the calculation of multiple trees, based on multicast source, treatable by CastFlow. In a TV scenario, with a great variety of channels, it is natural for users to zap through channels constantly. Because each channel is represented by a different multicast group, the joining and leaving of hosts in a group tend to be intense. The work of [2] studies the factors that contribute to the increase in latency of channel change in IPTV scenarios using IP multicast. It reaches the conclusion that the IGMP protocol contributes significantly to delays in the order of seconds. In CastFlow approach, as discussed in experiment 2, the join and leave events would be processed in milliseconds and would require minimal changes in switches flow tables, generating optimal multicast trees. VII. RELATED WORK Some works in the literature may be classified as increments of the Internet. Among them [8] presents a centralized multicast proposal that is similar to the logic used in this study, however, does not have the flexibility of programmable networks. In the same context [15] proposed the use of unicast paths to distribute multicast packets forming an overlay network, however this solution does not receive network support acting only at the application level. Considering proposals that require significant change in the network, as well as the proposal of this work, [16] use the Multiprotocol Label Switching (MPLS) Virtual Private Network on to manage multicast traffic, which suffers from scalability problems and also lacks the flexibility of programmable networks. On the other hand, [17] proposes high-level primitives based on OpenFlow to provide a more user friendly network. One of its primitives is a simplified implementation of multicast communication on OpenFlow, but that does not consider changes in the group, tree management and others imports issues. The CastFlow differs from these proposals promoting a more complete approach to multicast, including support for scalable network, calculating in advance multicast tree, and a focus on reducing the processing time of group events in the regular group management. VIII. CONCLUSIONS AND FUTURE WORK This paper proposes a multicast clean-slate approach logically centralized based on programmable networks with Open- Flow. During the setup of the multicast group, the calculation is carried out in advance of all possible routes in order to reduce the delay in processing multicast group events such as joining and leaving hosts or multicast source change. We have implemented a proof of concept of this approach called CastFlow. Experiments were performed to characterize setup time and events processing. The results showed overall satisfactory performance in the order of milliseconds, faster than results published in the literature for IP multicast. The in-advance tree calculation time growth was linear, due to the complexity of the algorithms used in the implementation. Considering real situations (installing flows on real OF switches), the time to process group events proved to be greatly /12/$ IEEE

8 (a) Event Processing (b) Source Change Impact (c) Traffic Adaptation Time and Host Perception Fig. 6: Total Processing Time between source changes or affected switches reduced. It is concluded that the proposal could be beneficial for applications that require multipoint communication and which hosts entry, hosts exit or source change in multcast group are intense, as may occur in IPTV. In future work we intend to exploit mechanisms that allow aggregation OpenFlow flows from several different multicast trees, using wildcards similar to that proposed in [18]. REFERENCES [1] P. Paul and S. V. Raghavan, Survey of multicast routing algorithms and protocols, in Proceedings of the 15th international conference on Computer communication, ser. ICCC 02. Washington, DC, USA: International Council for Computer Communication, 2002, pp [2] E. Kim, J. Liu, B. Rhee, S. Cho, H. Kim, and S. Han, Design and implementation for reducing zapping time of iptv over overlay network, in Proceedings of the 6th International Conference on Mobile Technology, Application & Systems, ser. Mobility 09. New York, NY, USA: ACM, 2009, pp. 41:1 41:7. [3] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, Openflow: enabling innovation in campus networks, SIGCOMM Comput. Commun. Rev., vol. 38, pp , March [4] B. Lantz, B. Heller, and N. McKeown, A network in a laptop: rapid prototyping for software-defined networks, in Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks, ser. Hotnets 10. New York, NY, USA: ACM, 2010, pp. 19:1 19:6. [5] A. Medina, A. Lakhina, I. Matta, and J. Byers, Brite: An approach to universal topology generation, in Proceedings of the Ninth International Symposium in Modeling, Analysis and Simulation of Computer and Telecommunication Systems, ser. MASCOTS 01. Washington, DC, USA: IEEE Computer Society, 2001, pp [6] K. Savetz, N. Randall, and Y. Lepage, MBONE: Multicasting Tomorrow s Internet, 1st ed. Foster City, CA, USA: IDG Books Worldwide, Inc., [7] A. S. Thyagarajan and S. E. Deering, Hierarchical distance-vector multicast routing for the mbone, SIGCOMM Comput. Commun. Rev., vol. 25, pp , October [8] S. Keshav and S. Paul, Centralized multicast, in Proceedings of the Seventh Annual International Conference on Network Protocols, ser. ICNP 99. Washington, DC, USA: IEEE Computer Society, 1999, pp. 59. [9] A. Tootoonchian and Y. Ganjali, Hyperflow: a distributed control plane for openflow, in Proceedings of the 2010 internet network management conference on Research on enterprise networking, ser. INM/WREN 10. Berkeley, CA, USA: USENIX Association, 2010, pp [10] T. H. Cormen, C. Stein, R. L. Rivest, and C. E. Leiserson, Introduction to Algorithms, 2nd ed. McGraw-Hill Higher Education, [11] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker, Nox: towards an operating system for networks, SIGCOMM Comput. Commun. Rev., vol. 38, pp , July [12] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, and A. W. Moore, Oflops: An open framework for openflow switch evaluation, 13th Passive and Active Measurement Conference, 2012, (to appear). [13] J. Naous, D. Erickson, G. A. Covington, G. Appenzeller, and N. McKeown, Implementing an openflow switch on the netfpga platform, in Proceedings of the 4th ACM/IEEE Symposium on Architectures for Networking and Communications Systems, ser. ANCS 08. New York, NY, USA: ACM, 2008, pp [14] Controller performance comparison, November [Online]. Available: Controller Performance Comparisons [15] S. Ratnasamy, A. Ermolinskiy, and S. Shenker, Revisiting ip multicast, SIGCOMM Comput. Commun. Rev., vol. 36, pp , Aug [16] I. Martinez-Yelmo, D. Larrabeiti, I. Soto, and P. Pacyna, Multicast traffic aggregation in mpls-based vpn networks, Communications Magazine, IEEE, vol. 45, no. 10, pp , october [17] K.-K. Yap, T.-Y. Huang, B. Dodson, M. S. Lam, and N. McKeown, Towards software-friendly networks, in Proceedings of the first ACM asia-pacific workshop on Workshop on systems, ser. APSys 10. New York, NY, USA: ACM, 2010, pp [18] R. Wang, D. Butnariu, and J. Rexford, Openflow-based server load balancing gone wild, in Proceedings of the 11th USENIX conference on Hot topics in management of internet, cloud, and enterprise networks and services, ser. Hot-ICE 11. Association, 2011, pp Berkeley, CA, USA: USENIX /12/$ IEEE

Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX

Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX Shie-Yuan Wang Hung-Wei Chiu and Chih-Liang Chou Department of Computer Science, National Chiao Tung University, Taiwan Email: shieyuan@cs.nctu.edu.tw

More information

Xperience of Programmable Network with OpenFlow

Xperience of Programmable Network with OpenFlow International Journal of Computer Theory and Engineering, Vol. 5, No. 2, April 2013 Xperience of Programmable Network with OpenFlow Hasnat Ahmed, Irshad, Muhammad Asif Razzaq, and Adeel Baig each one is

More information

Multiple Service Load-Balancing with OpenFlow

Multiple Service Load-Balancing with OpenFlow 2012 IEEE 13th International Conference on High Performance Switching and Routing Multiple Service Load-Balancing with OpenFlow Marc Koerner Technische Universitaet Berlin Department of Telecommunication

More information

Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management

Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management Research Paper Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management Raphael Eweka MSc Student University of East London

More information

OpenFlow based Load Balancing for Fat-Tree Networks with Multipath Support

OpenFlow based Load Balancing for Fat-Tree Networks with Multipath Support OpenFlow based Load Balancing for Fat-Tree Networks with Multipath Support Yu Li and Deng Pan Florida International University Miami, FL Abstract Data center networks are designed for satisfying the data

More information

A collaborative model for routing in multi-domains OpenFlow networks

A collaborative model for routing in multi-domains OpenFlow networks A collaborative model for routing in multi-domains OpenFlow networks Xuan Thien Phan, Nam Thoai Faculty of Computer Science and Engineering Ho Chi Minh City University of Technology Ho Chi Minh city, Vietnam

More information

CHAPTER 2. QoS ROUTING AND ITS ROLE IN QOS PARADIGM

CHAPTER 2. QoS ROUTING AND ITS ROLE IN QOS PARADIGM CHAPTER 2 QoS ROUTING AND ITS ROLE IN QOS PARADIGM 22 QoS ROUTING AND ITS ROLE IN QOS PARADIGM 2.1 INTRODUCTION As the main emphasis of the present research work is on achieving QoS in routing, hence this

More information

AN OVERVIEW OF QUALITY OF SERVICE COMPUTER NETWORK

AN OVERVIEW OF QUALITY OF SERVICE COMPUTER NETWORK Abstract AN OVERVIEW OF QUALITY OF SERVICE COMPUTER NETWORK Mrs. Amandeep Kaur, Assistant Professor, Department of Computer Application, Apeejay Institute of Management, Ramamandi, Jalandhar-144001, Punjab,

More information

VXLAN: Scaling Data Center Capacity. White Paper

VXLAN: Scaling Data Center Capacity. White Paper VXLAN: Scaling Data Center Capacity White Paper Virtual Extensible LAN (VXLAN) Overview This document provides an overview of how VXLAN works. It also provides criteria to help determine when and where

More information

IP Multicasting. Applications with multiple receivers

IP Multicasting. Applications with multiple receivers IP Multicasting Relates to Lab 10. It covers IP multicasting, including multicast addressing, IGMP, and multicast routing. 1 Applications with multiple receivers Many applications transmit the same data

More information

Cisco Discovery 3: Introducing Routing and Switching in the Enterprise 157.8 hours teaching time

Cisco Discovery 3: Introducing Routing and Switching in the Enterprise 157.8 hours teaching time Essential Curriculum Computer Networking II Cisco Discovery 3: Introducing Routing and Switching in the Enterprise 157.8 hours teaching time Chapter 1 Networking in the Enterprise-------------------------------------------------

More information

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc

Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc (International Journal of Computer Science & Management Studies) Vol. 17, Issue 01 Performance Evaluation of AODV, OLSR Routing Protocol in VOIP Over Ad Hoc Dr. Khalid Hamid Bilal Khartoum, Sudan dr.khalidbilal@hotmail.com

More information

A New Fault Tolerant Routing Algorithm For GMPLS/MPLS Networks

A New Fault Tolerant Routing Algorithm For GMPLS/MPLS Networks A New Fault Tolerant Routing Algorithm For GMPLS/MPLS Networks Mohammad HossienYaghmae Computer Department, Faculty of Engineering, Ferdowsi University of Mashhad, Mashhad, Iran hyaghmae@ferdowsi.um.ac.ir

More information

The necessity of multicast for IPTV streaming

The necessity of multicast for IPTV streaming The necessity of multicast for IPTV streaming ARIANIT MARAJ, ADRIAN SHEHU Telecommunication Department Faculty of Information Technology, Polytechnic University of Tirana Tirana, Republic of Albania arianit.maraj@ptkonline.com,

More information

Flow Based Load Balancing: Optimizing Web Servers Resource Utilization

Flow Based Load Balancing: Optimizing Web Servers Resource Utilization Journal of Applied Computing Research, 1(2):76-83 July-December 2011 2011 by Unisinos - doi: 10.4013/jacr.2011.12.02 Flow Based Load Balancing: Optimizing Web Servers Resource Utilization Daniel Stefani

More information

libnetvirt: the network virtualization library

libnetvirt: the network virtualization library libnetvirt: the network virtualization library Daniel Turull, Markus Hidell, Peter Sjödin KTH Royal Institute of Technology, School of ICT Stockholm, Sweden Email: {danieltt,mahidell,psj}@kth.se Abstract

More information

Limitations of Current Networking Architecture OpenFlow Architecture

Limitations of Current Networking Architecture OpenFlow Architecture CECS 572 Student Name Monday/Wednesday 5:00 PM Dr. Tracy Bradley Maples OpenFlow OpenFlow is the first open standard communications interface that enables Software Defined Networking (SDN) [6]. It was

More information

Data Networking and Architecture. Delegates should have some basic knowledge of Internet Protocol and Data Networking principles.

Data Networking and Architecture. Delegates should have some basic knowledge of Internet Protocol and Data Networking principles. Data Networking and Architecture The course focuses on theoretical principles and practical implementation of selected Data Networking protocols and standards. Physical network architecture is described

More information

Dynamic Security Traversal in OpenFlow Networks with QoS Guarantee

Dynamic Security Traversal in OpenFlow Networks with QoS Guarantee International Journal of Science and Engineering Vol.4 No.2(2014):251-256 251 Dynamic Security Traversal in OpenFlow Networks with QoS Guarantee Yu-Jia Chen, Feng-Yi Lin and Li-Chun Wang Department of

More information

A Study on Software Defined Networking

A Study on Software Defined Networking A Study on Software Defined Networking Yogita Shivaji Hande, M. Akkalakshmi Research Scholar, Dept. of Information Technology, Gitam University, Hyderabad, India Professor, Dept. of Information Technology,

More information

A Survey Study on Monitoring Service for Grid

A Survey Study on Monitoring Service for Grid A Survey Study on Monitoring Service for Grid Erkang You erkyou@indiana.edu ABSTRACT Grid is a distributed system that integrates heterogeneous systems into a single transparent computer, aiming to provide

More information

Introduction to IP Multicast Routing

Introduction to IP Multicast Routing Introduction to IP Multicast Routing by Chuck Semeria and Tom Maufer Abstract The first part of this paper describes the benefits of multicasting, the Multicast Backbone (MBONE), Class D addressing, and

More information

Multicast vs. P2P for content distribution

Multicast vs. P2P for content distribution Multicast vs. P2P for content distribution Abstract Many different service architectures, ranging from centralized client-server to fully distributed are available in today s world for Content Distribution

More information

HyperFlow: A Distributed Control Plane for OpenFlow

HyperFlow: A Distributed Control Plane for OpenFlow HyperFlow: A Distributed Control Plane for OpenFlow Amin Tootoonchian University of Toronto amin@cs.toronto.edu Yashar Ganjali University of Toronto yganjali@cs.toronto.edu Abstract OpenFlow assumes a

More information

ulobal: Enabling In-Network Load Balancing for Arbitrary Internet Services on SDN

ulobal: Enabling In-Network Load Balancing for Arbitrary Internet Services on SDN ulobal: Enabling In-Network Load Balancing for Arbitrary Internet Services on SDN Alex F R Trajano, Marcial P Fernandez Universidade Estadual do Ceará Fortaleza, Ceará, Brazil Email: alex.ferreira@uece.br,

More information

Network Management through Graphs in Software Defined Networks

Network Management through Graphs in Software Defined Networks Network Management through Graphs in Software Defined Networks Gustavo Pantuza, Frederico Sampaio, Luiz F. M. Vieira, Dorgival Guedes, Marcos A. M. Vieira Departament of Computer Science Universidade Federal

More information

Optimizing Enterprise Network Bandwidth For Security Applications. Improving Performance Using Antaira s Management Features

Optimizing Enterprise Network Bandwidth For Security Applications. Improving Performance Using Antaira s Management Features Optimizing Enterprise Network Bandwidth For Security Applications Improving Performance Using Antaira s Management Features By: Brian Roth, Product Marketing Engineer April 1, 2014 April 2014 Optimizing

More information

Demonstrating the high performance and feature richness of the compact MX Series

Demonstrating the high performance and feature richness of the compact MX Series WHITE PAPER Midrange MX Series 3D Universal Edge Routers Evaluation Report Demonstrating the high performance and feature richness of the compact MX Series Copyright 2011, Juniper Networks, Inc. 1 Table

More information

Virtual PortChannels: Building Networks without Spanning Tree Protocol

Virtual PortChannels: Building Networks without Spanning Tree Protocol . White Paper Virtual PortChannels: Building Networks without Spanning Tree Protocol What You Will Learn This document provides an in-depth look at Cisco's virtual PortChannel (vpc) technology, as developed

More information

Autonomicity Design in OpenFlow Based Software Defined Networking

Autonomicity Design in OpenFlow Based Software Defined Networking GC'12 Workshop: The 4th IEEE International Workshop on Management of Emerging Networks and Services Autonomicity Design in OpenFlow Based Software Defined Networking WANG Wendong, Yannan HU, Xirong QUE,

More information

Disaster Recovery Design Ehab Ashary University of Colorado at Colorado Springs

Disaster Recovery Design Ehab Ashary University of Colorado at Colorado Springs Disaster Recovery Design Ehab Ashary University of Colorado at Colorado Springs As a head of the campus network department in the Deanship of Information Technology at King Abdulaziz University for more

More information

QUALITY OF SERVICE METRICS FOR DATA TRANSMISSION IN MESH TOPOLOGIES

QUALITY OF SERVICE METRICS FOR DATA TRANSMISSION IN MESH TOPOLOGIES QUALITY OF SERVICE METRICS FOR DATA TRANSMISSION IN MESH TOPOLOGIES SWATHI NANDURI * ZAHOOR-UL-HUQ * Master of Technology, Associate Professor, G. Pulla Reddy Engineering College, G. Pulla Reddy Engineering

More information

Outline. VL2: A Scalable and Flexible Data Center Network. Problem. Introduction 11/26/2012

Outline. VL2: A Scalable and Flexible Data Center Network. Problem. Introduction 11/26/2012 VL2: A Scalable and Flexible Data Center Network 15744: Computer Networks, Fall 2012 Presented by Naveen Chekuri Outline Introduction Solution Approach Design Decisions Addressing and Routing Evaluation

More information

OMNI: OpenFlow MaNagement Infrastructure

OMNI: OpenFlow MaNagement Infrastructure OMNI: OpenFlow MaNagement Infrastructure Diogo M. F. Mattos, Natalia C. Fernandes, Victor T. da Costa, Leonardo P. Cardoso, Miguel Elias M. Campista, Luís Henrique M. K. Costa, Otto Carlos M. B. Duarte

More information

HPAM: Hybrid Protocol for Application Level Multicast. Yeo Chai Kiat

HPAM: Hybrid Protocol for Application Level Multicast. Yeo Chai Kiat HPAM: Hybrid Protocol for Application Level Multicast Yeo Chai Kiat Scope 1. Introduction 2. Hybrid Protocol for Application Level Multicast (HPAM) 3. Features of HPAM 4. Conclusion 1. Introduction Video

More information

Faculty of Engineering Computer Engineering Department Islamic University of Gaza 2012. Network Chapter# 19 INTERNETWORK OPERATION

Faculty of Engineering Computer Engineering Department Islamic University of Gaza 2012. Network Chapter# 19 INTERNETWORK OPERATION Faculty of Engineering Computer Engineering Department Islamic University of Gaza 2012 Network Chapter# 19 INTERNETWORK OPERATION Review Questions ٢ Network Chapter# 19 INTERNETWORK OPERATION 19.1 List

More information

Towards an Elastic Distributed SDN Controller

Towards an Elastic Distributed SDN Controller Towards an Elastic Distributed SDN Controller Advait Dixit, Fang Hao, Sarit Mukherjee, T.V. Lakshman, Ramana Kompella Purdue University, Bell Labs Alcatel-Lucent ABSTRACT Distributed controllers have been

More information

A NETWORK CONSTRUCTION METHOD FOR A SCALABLE P2P VIDEO CONFERENCING SYSTEM

A NETWORK CONSTRUCTION METHOD FOR A SCALABLE P2P VIDEO CONFERENCING SYSTEM A NETWORK CONSTRUCTION METHOD FOR A SCALABLE P2P VIDEO CONFERENCING SYSTEM Hideto Horiuchi, Naoki Wakamiya and Masayuki Murata Graduate School of Information Science and Technology, Osaka University 1

More information

Path Selection Analysis in MPLS Network Based on QoS

Path Selection Analysis in MPLS Network Based on QoS Cumhuriyet Üniversitesi Fen Fakültesi Fen Bilimleri Dergisi (CFD), Cilt:36, No: 6 Özel Sayı (2015) ISSN: 1300-1949 Cumhuriyet University Faculty of Science Science Journal (CSJ), Vol. 36, No: 6 Special

More information

Router Scheduling Configuration Based on the Maximization of Benefit and Carried Best Effort Traffic

Router Scheduling Configuration Based on the Maximization of Benefit and Carried Best Effort Traffic Telecommunication Systems 24:2 4, 275 292, 2003 2003 Kluwer Academic Publishers. Manufactured in The Netherlands. Router Scheduling Configuration Based on the Maximization of Benefit and Carried Best Effort

More information

Juniper / Cisco Interoperability Tests. August 2014

Juniper / Cisco Interoperability Tests. August 2014 Juniper / Cisco Interoperability Tests August 2014 Executive Summary Juniper Networks commissioned Network Test to assess interoperability, with an emphasis on data center connectivity, between Juniper

More information

Definition. A Historical Example

Definition. A Historical Example Overlay Networks This lecture contains slides created by Ion Stoica (UC Berkeley). Slides used with permission from author. All rights remain with author. Definition Network defines addressing, routing,

More information

Optical interconnection networks with time slot routing

Optical interconnection networks with time slot routing Theoretical and Applied Informatics ISSN 896 5 Vol. x 00x, no. x pp. x x Optical interconnection networks with time slot routing IRENEUSZ SZCZEŚNIAK AND ROMAN WYRZYKOWSKI a a Institute of Computer and

More information

VIDEO STREAMING OVER SOFTWARE DEFINED NETWORKS WITH SERVER LOAD BALANCING. Selin Yilmaz, A. Murat Tekalp, Bige D. Unluturk

VIDEO STREAMING OVER SOFTWARE DEFINED NETWORKS WITH SERVER LOAD BALANCING. Selin Yilmaz, A. Murat Tekalp, Bige D. Unluturk VIDEO STREAMING OVER SOFTWARE DEFINED NETWORKS WITH SERVER LOAD BALANCING Selin Yilmaz, A. Murat Tekalp, Bige D. Unluturk College of Engineering, Koç University, 34450 Sariyer, Istanbul, Turkey ABSTRACT

More information

ICTTEN4215A Install and configure internet protocol TV in a service provider network

ICTTEN4215A Install and configure internet protocol TV in a service provider network ICTTEN4215A Install and configure internet protocol TV in a service provider network Release: 1 ICTTEN4215A Install and configure internet protocol TV in a service provider network Modification History

More information

Efficient Video Distribution Networks with.multicast: IGMP Querier and PIM-DM

Efficient Video Distribution Networks with.multicast: IGMP Querier and PIM-DM Efficient Video Distribution Networks with.multicast: IGMP Querier and PIM-DM A Dell technical white paper Version 1.1 Victor Teeter Network Solutions Engineer This document is for informational purposes

More information

A Method for Load Balancing based on Software- Defined Network

A Method for Load Balancing based on Software- Defined Network , pp.43-48 http://dx.doi.org/10.14257/astl.2014.45.09 A Method for Load Balancing based on Software- Defined Network Yuanhao Zhou 1, Li Ruan 1, Limin Xiao 1, Rui Liu 1 1. State Key Laboratory of Software

More information

Performance Monitoring on Networked Virtual Environments

Performance Monitoring on Networked Virtual Environments ICC2129 1 Performance Monitoring on Networked Virtual Environments Christos Bouras, Eri Giannaka Abstract As networked virtual environments gain increasing interest and acceptance in the field of Internet

More information

Open Source Network: Software-Defined Networking (SDN) and OpenFlow

Open Source Network: Software-Defined Networking (SDN) and OpenFlow Open Source Network: Software-Defined Networking (SDN) and OpenFlow Insop Song, Ericsson LinuxCon North America, Aug. 2012, San Diego CA Objectives Overview of OpenFlow Overview of Software Defined Networking

More information

An Active Packet can be classified as

An Active Packet can be classified as Mobile Agents for Active Network Management By Rumeel Kazi and Patricia Morreale Stevens Institute of Technology Contact: rkazi,pat@ati.stevens-tech.edu Abstract-Traditionally, network management systems

More information

OPENFLOW-BASED LOAD BALANCING GONE WILD

OPENFLOW-BASED LOAD BALANCING GONE WILD OPENFLOW-BASED LOAD BALANCING GONE WILD RICHARD WANG MASTER S THESIS IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE MASTER OF SCIENCE IN ENGINEERING DEPARTMENT OF COMPUTER SCIENCE PRINCETON UNIVERSITY

More information

APPLICATION NOTE. Benefits of MPLS in the Enterprise Network

APPLICATION NOTE. Benefits of MPLS in the Enterprise Network APPLICATION NOTE Benefits of MPLS in the Enterprise Network Abstract As enterprises evolve to keep pace with the ever-changing business climate, enterprises networking needs are becoming more dynamic.

More information

A Review on Quality of Service Architectures for Internet Network Service Provider (INSP)

A Review on Quality of Service Architectures for Internet Network Service Provider (INSP) A Review on Quality of Service Architectures for Internet Network Service Provider (INSP) Herman and Azizah bte Abd. Rahman Faculty of Computer Science and Information System Universiti Teknologi Malaysia

More information

diversifeye Application Note

diversifeye Application Note diversifeye Application Note Test Performance of IGMP based Multicast Services with emulated IPTV STBs Shenick Network Systems Test Performance of IGMP based Multicast Services with emulated IPTV STBs

More information

POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS. Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА. Селчук Язар, Ердем Учар

POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS. Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА. Селчук Язар, Ердем Учар УПРАВЛЕНИЕ И ОБРАЗОВАНИЕ MANAGEMENT AND EDUCATION TOM IX (6) 2013 VOL. IX (6) 2013 POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА Селчук

More information

Performance Monitoring on Networked Virtual Environments

Performance Monitoring on Networked Virtual Environments Performance Monitoring on Networked Virtual Environments C. Bouras 1, 2, E. Giannaka 1, 2 Abstract As networked virtual environments gain increasing interest and acceptance in the field of Internet applications,

More information

Disjoint Path Algorithm for Load Balancing in MPLS network

Disjoint Path Algorithm for Load Balancing in MPLS network International Journal of Innovation and Scientific Research ISSN 2351-8014 Vol. 13 No. 1 Jan. 2015, pp. 193-199 2015 Innovative Space of Scientific Research Journals http://www.ijisr.issr-journals.org/

More information

Testing Software Defined Network (SDN) For Data Center and Cloud VERYX TECHNOLOGIES

Testing Software Defined Network (SDN) For Data Center and Cloud VERYX TECHNOLOGIES Testing Software Defined Network (SDN) For Data Center and Cloud VERYX TECHNOLOGIES Table of Contents Introduction... 1 SDN - An Overview... 2 SDN: Solution Layers and its Key Requirements to be validated...

More information

Configuration Examples. D-Link Switches L3 Features and Examples IP Multicast Routing

Configuration Examples. D-Link Switches L3 Features and Examples IP Multicast Routing Configuration Examples D-Link Switches L3 Features and Examples IP Multicast Routing DVMRP + IGMP + IGMP Snooping PIM-DM + IGMP + IGMP Snooping RIP + Multicast routing Where is IGMP snooping located Multicast

More information

Facility Usage Scenarios

Facility Usage Scenarios Facility Usage Scenarios GDD-06-41 GENI: Global Environment for Network Innovations December 22, 2006 Status: Draft (Version 0.1) Note to the reader: this document is a work in progress and continues to

More information

QoSIP: A QoS Aware IP Routing Protocol for Multimedia Data

QoSIP: A QoS Aware IP Routing Protocol for Multimedia Data QoSIP: A QoS Aware IP Routing Protocol for Multimedia Data Md. Golam Shagadul Amin Talukder and Al-Mukaddim Khan Pathan* Department of Computer Science and Engineering, Metropolitan University, Sylhet,

More information

Autonomous Fast Rerouting for Software Defined Network

Autonomous Fast Rerouting for Software Defined Network Autonomous ast Rerouting for Software Defined Network 2012.10.29 NTT Network Service System Laboratories, NTT Corporation Shohei Kamamura, Akeo Masuda, Koji Sasayama Page 1 Outline 1. Background and Motivation

More information

Axon: A Flexible Substrate for Source- routed Ethernet. Jeffrey Shafer Brent Stephens Michael Foss Sco6 Rixner Alan L. Cox

Axon: A Flexible Substrate for Source- routed Ethernet. Jeffrey Shafer Brent Stephens Michael Foss Sco6 Rixner Alan L. Cox Axon: A Flexible Substrate for Source- routed Ethernet Jeffrey Shafer Brent Stephens Michael Foss Sco6 Rixner Alan L. Cox 2 Ethernet Tradeoffs Strengths Weaknesses Cheap Simple High data rate Ubiquitous

More information

Ryuo: Using High Level Northbound API for Control Messages in Software Defined Network

Ryuo: Using High Level Northbound API for Control Messages in Software Defined Network Ryuo: Using High Level Northbound API for Control Messages in Software Defined Network Shaoyu Zhang, Yao Shen, Matthias Herlich, Kien Nguyen, Yusheng Ji, Shigeki Yamada Department of Computer Science and

More information

Scaling 10Gb/s Clustering at Wire-Speed

Scaling 10Gb/s Clustering at Wire-Speed Scaling 10Gb/s Clustering at Wire-Speed InfiniBand offers cost-effective wire-speed scaling with deterministic performance Mellanox Technologies Inc. 2900 Stender Way, Santa Clara, CA 95054 Tel: 408-970-3400

More information

OpenFlow: Load Balancing in enterprise networks using Floodlight Controller

OpenFlow: Load Balancing in enterprise networks using Floodlight Controller OpenFlow: Load Balancing in enterprise networks using Floodlight Controller Srinivas Govindraj, Arunkumar Jayaraman, Nitin Khanna, Kaushik Ravi Prakash srinivas.govindraj@colorado.edu, arunkumar.jayaraman@colorado.edu,

More information

EventBus Module for Distributed OpenFlow Controllers

EventBus Module for Distributed OpenFlow Controllers EventBus Module for Distributed OpenFlow Controllers Igor Alekseev Director of the Internet Center P.G. Demidov Yaroslavl State University Yaroslavl, Russia aiv@yars.free.net Mikhail Nikitinskiy System

More information

Overlay Networks and Tunneling Reading: 4.5, 9.4

Overlay Networks and Tunneling Reading: 4.5, 9.4 Overlay Networks and Tunneling Reading: 4.5, 9.4 COS 461: Computer Networks Spring 2009 (MW 1:30 2:50 in COS 105) Mike Freedman Teaching Assistants: WyaN Lloyd and Jeff Terrace hnp://www.cs.princeton.edu/courses/archive/spring09/cos461/

More information

Implementing VPN over MPLS

Implementing VPN over MPLS IOSR Journal of Electronics and Communication Engineering (IOSR-JECE) e-issn: 2278-2834,p- ISSN: 2278-8735.Volume 10, Issue 3, Ver. I (May - Jun.2015), PP 48-53 www.iosrjournals.org Implementing VPN over

More information

Research on Video Traffic Control Technology Based on SDN. Ziyan Lin

Research on Video Traffic Control Technology Based on SDN. Ziyan Lin Joint International Mechanical, Electronic and Information Technology Conference (JIMET 2015) Research on Video Traffic Control Technology Based on SDN Ziyan Lin Communication University of China, Beijing

More information

LOAD BALANCING AND EFFICIENT CLUSTERING FOR IMPROVING NETWORK PERFORMANCE IN AD-HOC NETWORKS

LOAD BALANCING AND EFFICIENT CLUSTERING FOR IMPROVING NETWORK PERFORMANCE IN AD-HOC NETWORKS LOAD BALANCING AND EFFICIENT CLUSTERING FOR IMPROVING NETWORK PERFORMANCE IN AD-HOC NETWORKS Saranya.S 1, Menakambal.S 2 1 M.E., Embedded System Technologies, Nandha Engineering College (Autonomous), (India)

More information

OpenTM: Traffic Matrix Estimator for OpenFlow Networks

OpenTM: Traffic Matrix Estimator for OpenFlow Networks OpenTM: Traffic Matrix Estimator for OpenFlow Networks Amin Tootoonchian, Monia Ghobadi, Yashar Ganjali {amin,monia,yganjali}@cs.toronto.edu Department of Computer Science University of Toronto, Toronto,

More information

IPTV AND VOD NETWORK ARCHITECTURES. Diogo Miguel Mateus Farinha

IPTV AND VOD NETWORK ARCHITECTURES. Diogo Miguel Mateus Farinha IPTV AND VOD NETWORK ARCHITECTURES Diogo Miguel Mateus Farinha Instituto Superior Técnico Av. Rovisco Pais, 1049-001 Lisboa, Portugal E-mail: diogo.farinha@ist.utl.pt ABSTRACT IPTV and Video on Demand

More information

I. ADDITIONAL EVALUATION RESULTS. A. Environment

I. ADDITIONAL EVALUATION RESULTS. A. Environment 1 A. Environment I. ADDITIONAL EVALUATION RESULTS The tests have been performed in a virtualized environment with Mininet 1.0.0 [?]. Mininet is tool to create a virtual network running actual kernel, switch

More information

OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS

OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS OVERLAYING VIRTUALIZED LAYER 2 NETWORKS OVER LAYER 3 NETWORKS Matt Eclavea (meclavea@brocade.com) Senior Solutions Architect, Brocade Communications Inc. Jim Allen (jallen@llnw.com) Senior Architect, Limelight

More information

Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol

Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol CCIT Report #835, July 2013, EE Pub No. 1792, Technion, Israel 1 Time-based Updates in : A Proposed Extension to the Protocol Tal Mizrahi, Yoram Moses Department of Electrical Engineering Technion Israel

More information

Michael Jarschel, Thomas Zinner, Tobias Hoßfeld, Phuoc Tran Gia University of Würzburg, Institute of Computer Science, Würzburg, Germany.

Michael Jarschel, Thomas Zinner, Tobias Hoßfeld, Phuoc Tran Gia University of Würzburg, Institute of Computer Science, Würzburg, Germany. 2014 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising

More information

Integrating Internet Protocol (IP) Multicast over Multiprotocol Label Switching (MPLS) for Real Time Video Conferencing Data Transmission

Integrating Internet Protocol (IP) Multicast over Multiprotocol Label Switching (MPLS) for Real Time Video Conferencing Data Transmission Integrating Internet Protocol (IP) Multicast over Multiprotocol Label Switching (MPLS) for Real Time Video Conferencing Data Transmission Majid Ashraf Derwesh Department of Electronics and Communication

More information

Centec s SDN Switch Built from the Ground Up to Deliver an Optimal Virtual Private Cloud

Centec s SDN Switch Built from the Ground Up to Deliver an Optimal Virtual Private Cloud Centec s SDN Switch Built from the Ground Up to Deliver an Optimal Virtual Private Cloud Table of Contents Virtualization Fueling New Possibilities Virtual Private Cloud Offerings... 2 Current Approaches

More information

Enabling Software Defined Networking using OpenFlow

Enabling Software Defined Networking using OpenFlow Enabling Software Defined Networking using OpenFlow 1 Karamjeet Kaur, 2 Sukhveer Kaur, 3 Vipin Gupta 1,2 SBS State Technical Campus Ferozepur, 3 U-Net Solutions Moga Abstract Software Defined Networking

More information

Datagram-based network layer: forwarding; routing. Additional function of VCbased network layer: call setup.

Datagram-based network layer: forwarding; routing. Additional function of VCbased network layer: call setup. CEN 007C Computer Networks Fundamentals Instructor: Prof. A. Helmy Homework : Network Layer Assigned: Nov. 28 th, 2011. Due Date: Dec 8 th, 2011 (to the TA) 1. ( points) What are the 2 most important network-layer

More information

Software Defined Networking (SDN) - Open Flow

Software Defined Networking (SDN) - Open Flow Software Defined Networking (SDN) - Open Flow Introduction Current Internet: egalitarian routing/delivery based on destination address, best effort. Future Internet: criteria based traffic management,

More information

- Multicast - Types of packets

- Multicast - Types of packets 1 Types of packets - Multicast - Three types of packets can exist on an IPv4 network: Unicast A packet sent from one host to only one other host. A hub will forward a unicast out all ports. If a switch

More information

QoS Switching. Two Related Areas to Cover (1) Switched IP Forwarding (2) 802.1Q (Virtual LANs) and 802.1p (GARP/Priorities)

QoS Switching. Two Related Areas to Cover (1) Switched IP Forwarding (2) 802.1Q (Virtual LANs) and 802.1p (GARP/Priorities) QoS Switching H. T. Kung Division of Engineering and Applied Sciences Harvard University November 4, 1998 1of40 Two Related Areas to Cover (1) Switched IP Forwarding (2) 802.1Q (Virtual LANs) and 802.1p

More information

SDN. What's Software Defined Networking? Angelo Capossele

SDN. What's Software Defined Networking? Angelo Capossele SDN What's Software Defined Networking? Angelo Capossele Outline Introduction to SDN OpenFlow Network Functions Virtualization Some examples Opportunities Research problems Security Case study: LTE (Mini)Tutorial

More information

CHAPTER 10 IP MULTICAST

CHAPTER 10 IP MULTICAST CHAPTER 10 IP MULTICAST This chapter is about IP multicast, the network layer mechanisms in the Internet to support applications where data is sent from a sender to multiple receivers. The first section

More information

Orion: A Hybrid Hierarchical Control Plane of Software-Defined Networking for Large-Scale Networks

Orion: A Hybrid Hierarchical Control Plane of Software-Defined Networking for Large-Scale Networks 2014 IEEE 22nd International Conference on Network Protocols Orion: A Hybrid Hierarchical Control Plane of Software-Defined Networking for Large-Scale Networks Yonghong Fu 1,2,3, Jun Bi 1,2,3, Kai Gao

More information

Combined Smart Sleeping and Power Scaling for Energy Efficiency in Green Data Center Networks

Combined Smart Sleeping and Power Scaling for Energy Efficiency in Green Data Center Networks UNIFI@ECTI-CON 2013 (May 14 th 17 th 2013, Krabi, Thailand) Combined Smart Sleeping and Power Scaling for Energy Efficiency in Green Data Center Networks Nguyen Huu Thanh Department of Communications Engineering

More information

Software Defined Networking

Software Defined Networking Software Defined Networking Richard T. B. Ma School of Computing National University of Singapore Material from: Scott Shenker (UC Berkeley), Nick McKeown (Stanford), Jennifer Rexford (Princeton) CS 4226:

More information

Software Defined Networking Basics

Software Defined Networking Basics Software Defined Networking Basics Anupama Potluri School of Computer and Information Sciences University of Hyderabad Software Defined Networking (SDN) is considered as a paradigm shift in how networking

More information

Towards an Ethernet Learning Switch and Bandwidth Optimization using POX Controller

Towards an Ethernet Learning Switch and Bandwidth Optimization using POX Controller Towards an Ethernet Learning Switch and Bandwidth Optimization using POX Controller Abhishek Bagewadi 1, Dr. K N Rama Mohan Babu 2 M.Tech Student, Department Of ISE, Dayananda Sagar College of Engineering,

More information

software networking Jithesh TJ, Santhosh Karipur QuEST Global

software networking Jithesh TJ, Santhosh Karipur QuEST Global software defined networking Software Defined Networking is an emerging trend in the networking and communication industry and it promises to deliver enormous benefits, from reduced costs to more efficient

More information

Design of a SIP Outbound Edge Proxy (EPSIP)

Design of a SIP Outbound Edge Proxy (EPSIP) Design of a SIP Outbound Edge Proxy (EPSIP) Sergio Lembo Dept. of Communications and Networking Helsinki University of Technology (TKK) P.O. Box 3000, FI-02015 TKK, Finland Jani Heikkinen, Sasu Tarkoma

More information

OpenFlow Based Load Balancing

OpenFlow Based Load Balancing OpenFlow Based Load Balancing Hardeep Uppal and Dane Brandon University of Washington CSE561: Networking Project Report Abstract: In today s high-traffic internet, it is often desirable to have multiple

More information

Juniper Networks EX Series/ Cisco Catalyst Interoperability Test Results. May 1, 2009

Juniper Networks EX Series/ Cisco Catalyst Interoperability Test Results. May 1, 2009 Juniper Networks EX Series/ Cisco Catalyst Interoperability Test Results May 1, 2009 Executive Summary Juniper Networks commissioned Network Test to assess interoperability between its EX4200 and EX8208

More information

Assignment 6: Internetworking Due October 17/18, 2012

Assignment 6: Internetworking Due October 17/18, 2012 Assignment 6: Internetworking Due October 17/18, 2012 Our topic this week will be the notion of internetworking in general and IP, the Internet Protocol, in particular. IP is the foundation of the Internet

More information

P2P VoIP for Today s Premium Voice Service 1

P2P VoIP for Today s Premium Voice Service 1 1 P2P VoIP for Today s Premium Voice Service 1 Ayaskant Rath, Stevan Leiden, Yong Liu, Shivendra S. Panwar, Keith W. Ross ARath01@students.poly.edu, {YongLiu, Panwar, Ross}@poly.edu, Steve.Leiden@verizon.com

More information

a new sdn-based control plane architecture for 5G

a new sdn-based control plane architecture for 5G a new sdn-based control plane architecture for 5G With a Case Study on Connectivity Management m. outline what is sdn? 5G proposed control plane connectivity control software-defined networking The needs

More information

A Network Control Plane for Massive Video Delivery

A Network Control Plane for Massive Video Delivery A Network Control Plane for Massive Video Delivery Giuseppe Cofano Politecnico di Bari, Dipartimento di Ingegneria Elettrica e dell Informazione, Via E. Orabona 4 70125 Bari, Italy - giuseppe.cofano@poliba.it

More information

Disaster-Resilient Backbone and Access Networks

Disaster-Resilient Backbone and Access Networks The Workshop on Establishing Resilient Life-Space in the Cyber-Physical Integrated Society, March. 17, 2015, Sendai, Japan Disaster-Resilient Backbone and Access Networks Shigeki Yamada (shigeki@nii.ac.jp)

More information