OpenDaylight powered OpenStack Federation unlocks NFV Agility With the ability to connect OpenStack networks across multiple sites, Telco networks become more flexible and efficient

Contents Fulfilling the promise of network virtualization ............................................................................................................................................................................................. 2 OpenStack networking limitations............................................................................................................................................................................................................................. 2 OpenStack Federation using OpenDaylight (HPE OpenSDN) ........................................................................................................................................................ 3 Inside OpenStack Federation ......................................................................................................................................................................................................................................... 3

Enabling multisite networking connectivity ............................................................................................................................................................................................... 4 OpenStack Federation in action ............................................................................................................................................................................................................................ 5

Unlocking NFV Agility .......................................................................................................................................................................................................................................................... 6 Powering the Telco Cloud ................................................................................................................................................................................................................................................. 7

Technical white paper

Technical white paper Page 2

Communications Service Providers (CSPs) are turning to Network Functions Virtualization to design and deliver customized services faster. But today, NFV platforms like OpenStack® are limited to a narrow set of services operating at a single location. The bottleneck: the networking functions in OpenStack were not designed for complex, distributed CSP networks. Even when paired with software-defined networking (SDN) controllers like OpenDaylight, network programmability is still typically limited to a single location. Now, new carrier-grade SDN capabilities from Hewlett Packard Enterprise can empower CSPs to extend open-source SDN programmability across multiple OpenStack sites. They can interconnect virtualized networking resources at dozens, or even hundreds of locations—at Layer 2 or Layer 3, without network address translation (NAT) and with fully automated control. For the first time, they can create a flexible, carrier-grade open-source networking fabric that can continually adapt to changing business needs.

Fulfilling the promise of network virtualization The emergence of Network Functions Virtualization (NFV) holds enormous potential for communication service providers. With the ability to implement network functions in software running on general-purpose servers, instead of dedicated physical appliances, CSPs can unlock unprecedented agility. They can quickly design and deliver a wide range of customized services to meet diverse client needs, and operate their networks much more efficiently. At least, in theory.

In practice, for CSPs seeking to become agile digital service providers, the advantages of NFV have been limited to a narrow set of workloads at limited scale. The real efficiencies of virtualization are achievable only when virtualized functions are truly elastic, with the ability to move and scale many types of workloads, anywhere, as needed. NFV platforms like OpenStack can provide that kind of flexibility within a relatively homogenous data center. But CSP networks—hosting myriad network functions and services running on multivendor infrastructures with thousands of physical and virtual devices—are another matter entirely.

To truly capitalize on virtualization, CSPs need to be able to treat all of the heterogeneous devices in their networks as programmable elements. They need to be able to adapt forwarding logic dynamically according to business policy, customer demand, and system status. They need to be able to provision and scale virtualized networking resources just as quickly and easily as compute or storage. Furthermore, to fully unlock the business agility of NFV, they need distributed SDN-controlled connectivity—not just at a single location but between OpenStack clouds spanning multiple data centers and geographic locations.

OpenStack networking limitations As a flexible, open-source NFV platform, OpenStack provides an excellent framework for managing virtualized resources, and CSPs worldwide have been moving to adopt it. However, OpenStack’s networking model—enabled through the Neutron service—was not designed to exchange networking information with external networking entities, and in particular, other OpenStack instances. Instead, the Neutron network model is designed to operate within a single geographic domain, or even a single rack. Anything outside of that is treated as “external,” requiring NAT (which means that direct Layer-2 connectivity isn’t possible), and requiring CSPs to configure floating IPs on VMs to be able to reach remote VMs. As a result, OpenStack alone is poorly suited for complex, distributed CSP networks. It can’t support the advanced multisite networking capabilities (VXLAN tunneling, multitenant network overlay topologies) that would afford CSPs true agility in managing and provisioning elastic services.

Now, Hewlett Packard Enterprise has enhanced the OpenDaylight (ODL) open-source SDN controller to make it possible to overcome these limitations and implement flexible, high-performance open-source NFV networking in demanding carrier environments. As part of its carrier-grade OpenSDN solution portfolio, HPE is helping CSPs enable automated, programmable network connectivity across distributed OpenStack sites.

Technical white paper Page 3

OpenStack Federation using OpenDaylight (HPE OpenSDN) OpenDaylight provides an open-source platform for SDN programmability of networking in OpenStack. It provides a programmable communication layer between Neutron and the CSP network. Today, however, ODL is still typically implemented on a site-by-site basis. In a single OpenStack instance, Neutron defines the network model for that OpenStack cloud and works with ODL to enable higher-performance, more carrier-grade forwarding logic than when using Neutron alone. But in a second OpenStack instance—at a different location, with different underlying networking devices—Neutron defines a different network model, working with a separate ODL instance. In other words, ODL and Neutron have a 1:1 relationship. However, to support large-scale distributed services, CSPs need to move to a multisite model, where each site can retain one ODL cluster and one OpenStack, but the ODL clusters at different sites federate for the purpose of connecting OpenStack networks.

Now, Hewlett Packard Enterprise has developed new enhancements to ODL to support OpenStack Federation and provide a framework to connect ODL instances across multiple sites. It acts as a control center to collect Neutron information from multiple OpenStack instances, derive the networks defined in those locations, and automatically federate the networking elements of OpenStack to enable network sharing among virtual machines (VMs) across sites. ODL creates virtual overlay networks between sites, so that VM instances can communicate as if they have a single network spanning multiple locations.

By adding these multisite federation capabilities, ODL is now empowered to enable a wide range of new use cases for managing CSP networks that are not possible with OpenStack alone: service function chaining across the WAN, load-balancing across sites, routing across thousands of virtual customer premises equipment (vCPE) instances, and many others.

Inside OpenStack Federation To understand how the OpenStack Federation works, let’s start by reviewing how ODL works with Neutron in a single site. Figure 1 illustrates a highly available (HA) OpenStack cluster at a single site running HPE’s CSP-optimized OpenStack implementation, Helion OpenStack Carrier Grade. In this example, three Neutron control nodes are connected to two compute nodes running virtualized network functions (VNFs), with forwarding logic controlled by ODL.

Figure 1. Single-site OpenStack networking with ODL

Neutron defines the networking model for the site. When running with ODL, OpenStack uses the Networking ODL (N-ODL) plugin in the control node to subscribe to Neutron events (e.g., creation of a Neutron network, port, or router) and translate them into a format that can be communicated to the ODL controller. The ODL controller receives these events and configures the underlying virtual networks required by Neutron, applying the required forwarding logic to virtual switches on each node. In Figure 1, these are vanilla Open vSwitch (OVS) on the control nodes and accelerated OVS-DPDK virtual switches on the compute nodes.

Technical white paper Page 4

In a single-site implementation, ODL enables two layers of interconnectivity between compute hosts. At the bottom layer is the infrastructure connectivity, called the provider network layer. This could be, for example, a VXLAN tunneled network (shown in Figure 1 as red lines) or a VLAN-based network. On top of that provider network is the virtual networking layer—the Neutron user/tenant networks interconnecting the VMs. While the figure illustrates only compute nodes with virtualized functions, the provider network can also be extended to legacy physical hardware using top-of-rack switches acting as a hardware virtual tunnel endpoint (HWVTEP) with a Layer-2 gateway.

Enabling multisite networking connectivity Figure 2 illustrates how OpenStack Federation support on OpenDaylight extends SDN programmability to a multisite scenario.

Figure 2. Dual-site networking with ODL and OpenStack Federation

Here, we see two HCG OpenStack instances at two different locations, along with a new element added through HPE’s ODL enhancements: the Federation Platform, consisting of message queue nodes in each site and a Federation Manager. Note that while just two sites are shown here, the platform can support hundreds.

To enable a multisite implementation, the Federation Platform instructs the ODL controllers in each OpenStack instance to cooperate and create a provider network (e.g., VXLAN tunnel) not just between compute nodes in a single site, but between compute nodes in different sites, on an on-demand basis. In the underlying networking data path, VMs across sites can now communicate with each other as if they were at a single site. Nothing in Neutron has changed—each OpenStack instance is still using its own respective Neutron networking model. But now, VMs at remote sites can communicate as if they were in the same location. Effectively, the VXLAN mesh has been extended between sites.

The Federation Manager communicates with ODL controllers at all subscribed Neutron sites via a Federation Platform to collect state information from all of the various OpenStack networks at each location. Networks at each site are compared to determine if they are compatible for the purpose of sharing network resources. Networks can be compatible for sharing with other locations if, for instance, they are using the same IP subnet, without overlapping IP addresses, or the same segmentation ID (VLAN).

When networks are compatible, that information is automatically presented by the Federation Manager. Operators can address the Federation Manager via an orchestration system or directly via a web-based GUI, and select the compatible networks to be shared (connected) between sites. From that point on, the ODL instances share information via the Federation Platform regarding VM ports and switches connected to the selected shared networks for the purpose of federating those networks. That information is consumed by the ODL instances at all other sites subscribing to the Federation Platform, so that those controllers can extend their domain of control to send traffic to other compatible sites.

Technical white paper Page 5

OpenStack Federation in action Figures 3 and 4 illustrate what the process of defining shared networks across multiple OpenStack sites looks like in practice. In Figure 3, we see three OpenStack locations, each with two groups of networking resources that are compatible for sharing with other locations: Blue, Green, and Orange may be such compatible networks, and Cyan, Purple, and Gray are also compatible.

Figure 3. Multiple OpenStack instances with compatible networking resources

Using the Federation Manager, the operator can select the Blue, Green, and Orange networks to function as one global Dark Steel network, and the Cyan, Purple, and Gray as one global Bronze network (Figure 4).

Figure 4. Defining shared networks across sites

The Federation Manager instructs the relevant ODL instance to communicate over the Federation Platform in order to exchange information to allow federation. So, for example, the ODL controller on Site A may receive information regarding the VM ports on the Orange network, and enable the VM instances at Site A on the Blue network to interconnect with VM ports on the Orange network. This is done by extending the VXLAN mesh to compute hosts with VM ports on the Orange network. In a similar way, the reverse direction is also enabled by the ODL in Site C. Figure 5 provides an overview of the network sharing provisioning process.

Technical white paper Page 6

Figure 5. Defining a shared network across OpenStack instances

Unlocking NFV Agility With the ability to extend OpenStack networking beyond a single location, a number of powerful use cases now become possible:

• Cloud bursting network resources: A CSP with a network spanning multiple sites can now design the network to consume networking resources wherever they are available. So if the CSP has data centers in San Francisco and New York, for example, they now have the flexibility to consume resources at the less loaded data center at certain times of day, and shift back to the other when more resources become available—without changing anything in the network architecture. As a result, they can maintain fewer compute platforms at each data center, while ensuring they can accommodate usage spikes.

• Shared high availability resource pools: To ensure the availability of resources for all services, CSPs today typically overprovision compute nodes at each data center. Now, they can create a single pool of high-availability resources that can be shared by multiple locations. In the event of a failure, they can shift networking resources to other data centers while preserving a networking infrastructure that looks exactly the same to running services. They create a more resilient infrastructure and substantially reduce total cost of ownership (TCO).

• Service function chaining: With the ability to federate OpenStack instances, CSPs can now support service function chaining of applications spread over a distributed cloud. By applying service chaining function chaining to virtualized networks or value-added service functions, they can dramatically boost efficiency by distributing or instantiating appropriate functions at the right location (data center or distributed edge).

• vCPE routing: Virtual CPE use cases, especially for enterprise applications, might involve customer premise equipment that has the ability to host applications/network functions. In such hybrid deployment scenarios, the virtualized functions are spread across customer premise equipment and the CSP cloud. Federation and support for networking across hundreds of OpenStack instances allows CSPs to simplify deployment models and expand the services that they can support with their vCPE solutions.

In all of these examples, and many others, CSPs benefit from a more flexible and adaptable virtualized platform. All of a sudden, they can re-architect their networks in myriad ways, whenever and however it makes business sense. And they can begin to realize the full potential of NFV business agility in their networks.

Technical white paper

Sign up for updates

© Copyright 2016–2017 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

The OpenStack Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. Pivotal and Cloud Foundry are trademarks and/or registered trademarks of Pivotal Software, Inc. in the United States and/or other countries. All other third-party trademark(s) is/are property of their respective owner(s).

4AA6-8007ENW, March 2017, Rev. 1

Powering the Telco Cloud At Hewlett Packard Enterprise, we see carrier-grade SDN as an integral part of the Telco Cloud architecture, which aims to transform CSP infrastructures to be more programmable, operations to be more automated, and CSP services to be more personalized and on demand. SDN and NFV play a vital role in that infrastructure transformation.

HPE carrier-grade SDN solutions under the HPE OpenSDN portfolio are designed to complement our industry-leading NFV solutions to enable network agility on par with compute and storage agility. Our solutions enable automated, policy-driven, real-time network programmability to support distributed VNF deployments and VNF mobility. And they are redefining the user experience by enabling personalization of services at massive scales.

The HPE OpenSDN portfolio consists of an OpenDaylight-based carrier-grade SDN controller. We add value to the base controller with a rich set of application packs that form the basis of our pre-tested solutions for most commonly used use cases. The OpenStack Federation support described in this paper is part of the value added functionality that HPE OpenSDN Controller provides. HPE OpenSDN application packs include:

• Data center networking with multisite federation

• Subscriber-aware service function chaining for consumer broadband value-added services

• Service function chaining for enterprise virtual customer premises equipment (vCPE)

• CSP-provided enterprise virtual private networks (VPNs)

Learn more at hpe.com/dsp/infrastructure