• No results found

As shown in Figure 12, the three main components of the network layer are the OpenFlow switches, the network links, and the hosts used to generate network traffic. The OpenFlow switches will be discussed first, followed by the overall network environment, which will also cover the hosts and links used.

4.1.1. OpenFlow Switch

Two categories of switches exist: software switches and hardware switches. Software switches were suitable for use in this work, as the main focus was on the functionality of the controller, and not on switch performance. Software switches allow rapid, comprehensive testing of a control algorithm, and since the southbound interface to the controller (OpenFlow) is standardized, the functionality for both software and hardware switches should be the same. Open vSwitch (OVS) [42] was selected as the OpenFlow software switch, as it is widely used, has high performance, and supports the protocols needed, such as OpenFlow 1.3, BFD, and MPLS.

Per-link BFD is used to monitor the liveness of ports, and report link failures. This liveness information is then used in the selection of the forwarding actions.

OVS by default only supports pushing a maximum of 3 MPLS labels onto a packet. This limitation would likely not cause issues in a normal MPLS deployment, but does limit a segment routing deployment. In particular, it limited the proposed FRR application, as more

35

than three labels were sometimes required. Since OVS is open-source, a patch was found to support more MPLS labels and documented by the community for a previous version of OVS [43]. However, it has not been incorporated into the main codebase. Therefore, it was necessary to port the patch to the latest version of OVS, and re-compile the switch. Further details of the modification can be found in Appendix A.

4.1.2. Network Environment

Two network environments were used in this project. The first, Mininet, consisted of a number of virtual switches and virtual links within a single Linux virtual machine (VM). The second environment, GENI [44], consisted of geographically distributed infrastructure and was used to test the proposed FRR application using distributed virtual switches and physical links.

Mininet

Mininet is a network emulator that uses lightweight process-based virtualization to establish a network of virtual switches and virtual Ethernet links within a single Linux VM [45]. The main design goals of Mininet were to provide a network prototyping platform that is flexible, scalable, and realistic.

Mininet can be viewed as a network orchestrator. The topology is programmatically defined in a Python script, using the Mininet API. Mininet then launches OVS instances for each requested switch, and connects them with virtual Ethernet links. Each OVS instance establishes its own connection to the controller, which is separate from Mininet. Process-based virtualization is then used to launch virtual hosts in isolated network namespaces.

The Mininet API also provides useful functions for debugging and testing, such as administratively bringing links or interfaces down, or testing all-to-all connectivity. These functions can be used to automate testing a link and node failures within the network.

These properties make Mininet ideal for development purposes, as well as verifying the functionality of the control algorithm using many different network topologies, with many nodes.

The Amazon Elastic Cloud Compute (EC2) platform was used to host these virtual machines, as it allowed for thorough testing of the reactive application’s performance, without being restricted by computational resources. This was important to ensure that the reactive application’s response time was not being limited by the available resources.

36

GENI

GENI (Global Environment for Network Innovations) provides computational and network resources which are geographically distributed across the United States [44]. Different sites can be connected with layer 2 (i.e. Ethernet) protocols, which allows for testing of non-IP protocols, like MPLS, between sites.

The same OVS switches were used as in the Mininet environment, but each switch was in a separate Linux VM. Hosts were also implemented as separate Linux VMs.

The GENI testbed allows for verifying that the application can also configure a physical network, as it uses physical network interfaces and physical links. The GENI infrastructure is shared with other researches, and well utilized, which limits the amount of available resources. In particular, the number of links that could be provisioned between different sites was limited. This limited the number of nodes that could be provisioned, and restricted testing to simple topologies.

4.2. Network Operating System

As mentioned in section 2.1.3, there are many different NOSes, with varying levels of performance and functionality. ONOS is a particularly notable controller, as it was specifically developed for the WAN, whereas many other controllers are aimed at the data centre. It has many important features necessary for core networks, such as high performance, control plane resilience, and scalability.

Given the many benefits of ONOS, it was initially chosen for this work, for both the reactive and proactive solutions. The performance and scalability of the ONOS control plane make it particularly well-suited for a reactive approach, which has already been implemented by the ONOS team.

However, it was found that the device drivers in ONOS do not yet support failover groups. This makes it unsuitable for a proactive FRR control strategy. Implementing this functionality was outside the scope of this work, so an alternative NOS, RYU was chosen to implement the proposed proactive strategy, as it does support fast-failover groups.

While RYU is not distributed, and does have some drawbacks in terms of performance and scalability, this is less critical for the proactive approach, since the forwarding rules do not have to be recalculated within 50 ms. RYU is a popular controller in network research literature, possibly due to it allowing for rapid development, making it ideal for developing a prototype

37

application.

Related documents