This section explores how Flash Network Slice are instantiated, created and mapped to networks relying on flow-based networking, with special focus on using OpenFlow technologies to dynamically
deploy and adapt FNSs according to network conditions and user requirements.
Figure 6.4 depicts an example with two FNSs deployed over cloud platforms and an OpenFlow substrate. Each slice is composed of virtual nodes, provided by cloud providers, and virtual paths offered by network providers and supported by OpenFlow switches.
Figure 6.4: FNS mapping to OpenFlow
The FNS request is composed of a set of virtual nodes (i.e. cloud resources) interconnected via a set of virtual links across a shared substrate network. The FNS resources are jointly allocated by the cloud providers and network providers. The FNS request is split into smaller graphs according to specified optimisation objectives and constraints. Each subgraph is mapped to the appropriate cloud platforms. In Figure 6.4 this corresponds to the two data centres but in a more general case the mapping can involve also the provider network resources and services. To establish the inter- subgraph links between the involved clouds across the substrate network, OpenFlow technology is used to map the FNS paths to the shared substrate network.
We consider two main approaches for mapping FNSs onto OpenFlow networks, which are further outlined in Section 6.2.2 and 6.2.3 below:
1. Through intermediate virtualisation controllers, such as FlowVisor.
2. Through dedicated controllers specifically designed for control and management of FNSs. 6.2.1 OpenFlow Background
OpenFlow is an open standard that enables running experimental or new protocols in existing production networks. It relies on a control and forwarding plane separation paradigm to enable flow-level control and management of switches. The data path of an OpenFlow switch is composed of a flow table with actions associated with each flow table entry. Users control flows by installing appropriate actions in the switches. OpenFlow also provides an open protocol to allow an external controllerto communicate with the OpenFlow switches and control their flow tables. There are sev-
eral initiatives for developing OpenFlow controller software, including NOX1, Maestro2, Beacon3,
Trema4, and ONIX5.
OpenFlow has several characteristics that makes it an interesting candidate for CloNe: 1 http://noxrepo.org 2http://code.google.com/p/maestro-platform/ 3 http://www.openflowhub.org 4https://github.com/trema 5 https://www.usenix.org/events/osdi10/tech/full_papers/Koponen.pdf
• The simplified physical switching infrastructure, which facilitates hardware virtualisation.
• Potential for online modification, migration and backup of network controllers.
• The integration with existing technologies and the development of standalone technologies.
• More dynamic and flexible approach to a network resource than traditional technologies.
There are two main options for routing flows within an OpenFlow network:
1. Native OpenFlow forwarding: flow table entries are installed for the specific header fields representing the traffic within the FNS. In this case the selected fields for the matching must be unique in the entire network, which means that the controller needs to perform conflict resolution to ensure FNS isolation.
2. Tunnelling: Tunnels are between the different ingress and egress points with one of the tunnel technologies supported by OpenFlow, and the packets are encapsulated and decapsulated accordingly. This will eliminate the need for conflict management, and will also reduce the size of the flow tables in the switches. As of OpenFlow v1.1, there is support for two protocols that provide this functionality: MPLS and QinQ VLAN.
Another consideration is how the paths are initialized and deleted. Currently, there are two ways to instantiate paths relying on the OpenFlow rules:
• Permanent path deployment: OpenFlow rules are injected in the flow tables as permanent
entries. This approach potentially suffers from scalability limitations, since entries in the flow table will never be removed and this caps the number of deployed flows to the maximum possible number of entries.
• Online path deployment: OpenFlow rules are injected in the flow tables on demand, as
temporary entries. When a switch cannot find a flow table entry that matches an incoming packet, the switch forwards the packet to the controller to dynamically compute the path ”online” and determine the appropriate policy to be applied and injected. These operations increase the delay for flow setup, but could improve scalability when combined with a suitable replacement policy for flow table entries.
6.2.2 Intermediate Virtualisation Controller
A possible approach for FNS creation is the use of an intermediate virtualisation controller, such as FlowVisor, which acts as a transparent proxy server between the switches and the corresponding controllers. FlowVisor slices an OpenFlow switch into several virtual switches, thereby making it possible to control virtual OpenFlow switches from regular controllers, such as NOX. Figure 6.5 illustrates how we could use FlowVisor to create slices in the single router/switch abstraction using Openflow Enabled Switches.
Let us consider three network slices, orange, green and blue; the FlowVisor node works as a proxy between the OpenFlow enabled switches and the slice controllers (e.g. NOX controller) and is responsible for slice creation and rule management. For each slice, there is a controller responsible for control of the flows within that slice. Suppose that a host in the blue slice starts a new flow and sends a packet through switch sw2; this should trigger a request to the appropriate controller what to do with the packet (unless rules are permanently deployed for the flow by the controller), so sw2 will connect to the FlowVisor node which in turn will direct it to controller 1, in the same way controller1 will send a response to sw2. Hence, the FlowVisor node maintains the rules that
Figure 6.5: Slicing using FlowVisor
define the network slices, manages the connection between slices and controllers, and guarantees isolation between slices.
This model allows different slices to use different network models and routing paradigms: single switch, single router, etc. On-demand creation and modification of FNS can be achieved by chang- ing the FlowVisor configuration. For example, from the infrastructure provider point of view, it would be achived by only changing the slice’s corresponding port in the FlowVisor, this can convert it to a totally different slice in terms of functionality and topology. Convergence is guaranteed by the lifetime of the rules installed in the OpenFlow switches. Changing the slice topology would be more challenging because the infrastructure provider may have a pool of controllers ready to connect to a specific slice with minimum reconfiguration, but will not have prebuilt slices for every possible requested FNS, so an efficient mapping between FNS and the FlowVisor slices is needed.
All the controllers and a FlowVisor could be integrated into one server; this server will be responsible of slice creation and flow management. The use of a centralized FlowVisor may have many advantages but it also constitutes a single point of failure. This could be addressed through redundancy techniques, such as a fully distributed FlowVisor design, or by holding the existing flows in the switches while the backup server is up and fully synchronized.
6.2.3 Dedicated Controllers
A second approach is the use of a dedicated controller for FNSs (Figure 6.6), that is, a controller implementing the FNS abstraction, and that supports dynamic creation, modification, and termi- nation of Flash Network Slices.
OpenFlow Controller
OpenFlow Protocol
Figure 6.6: OpenFlow view
6.2.3.1 FNS Controller as a NOX Module
The NOX controller provides a programmatic interface to support advanced control and man- agement functionality based on events, a name space, and a network view. It is implemented in C++ and Python, and has a modular structure that allows users to add their own network control software.
The NOX’s network view maintains the topology of the entire substrate network. To ensure slice isolation to restrict the view and the scope of each slice, CloNe is:
• developing a new NOX module called ”FNS control module” responsible for establishing and
instantiating FNS paths;
• creating a flash network view (FNS view) derived from the global NOX’s network view to
maintain network topology and slice information.
Once the FNS nodes are mapped to the Cloud platforms (for Figure 6.4, the two data centers), the Cloud providers send the node mapping information to the NOX controller. The FNS control module in the NOX controller extracts the node identifiers (e.g. name or address) and determines the set of OpenFlow switches directly connected to the virtual nodes. Relying on the network view, the FNS control module computes the shortest paths between the virtual nodes while satisfying the user specified link requirements. Next, the FNS control module determines the appropriate OpenFlow policies and rules required to set up the computed paths.
To reduce the delay required to set up the FNS, the paths are precomputed based on the net- work view and stored in a database located in the NOX controller called ”FNS view” database. This database maintains information about the slice network topology and constraints. This so- lution would be an extension of PCE [38] based inter-domain solutions. Likewise, inter-domain communications between controllers would be a similar approach to the implementation of pce in a (G)MPLS network [39].