James Kempf

Moving the mobile Evolved Packet Core to the cloud

In this paper, we describe an evolution of the mobile Evolved Packet Core (EPC) utilizing Software Defined Networking (SDN) that allows the EPC control plane to be moved into a data center. The EPC is a mobile aggregation network standardized by 3GPP for deployment of fixed and 4G mobile broadband services, having interoperability features for 3G and 2G mobile services. While mobile networks already deploy a considerable amount of software control, the ability of OpenFlow to decouple the control and data planes for IP routing provides the opportunity to simplify the configuration and maintenance of mobile aggregation networks by eliminating the distributed IP routing control plane. We extend OpenFlow 1.2 with two vendor extensions, one defining virtual ports to allow encapsulation and decapsulation and another to allow flow routing using the GTP Tunnel Endpoint Identifier (TEID). The result enables an architecture where the GTP control plane can be lifted up out of network elements such as the Serving Gateway and the Packet Data Network Gateway (PDN Gateway) and moved into a controller running in a virtual machine in a data center. The EPC network elements then run a simplified OpenFlow control plane, enhanced with GTP TEID routing extensions. We discuss a few new features that are enabled with GTP TEID routing and the status of a prototype.

Scalable fault management for OpenFlow

In the OpenFlow based split architecture, data-plane forwarding is separated from control and management functions. Forwarding elements make only simple forwarding decisions based on flow table entries populated by the controller. While OpenFlow does not specify how topology monitoring is performed, the centralized controller can use Link-Layer Discovery Protocol (LLDP) messages to discover link and node failures and trigger restoration actions. This monitoring and recovery model has serious scalability limitations because the controller has to be involved in the processing of all of the LLDP monitoring messages. For fast recovery, monitoring messages must be sent with millisecond interval over each link in the network. This poses a significant load on the controller. In this paper we propose to implement a monitoring function on OpenFlow switches, which can emit monitoring messages without posing a processing load on the controller. We describe how the OpenFlow 1.1 protocol should be extended to support the monitoring function. Our experimental results show that data plane fault recovery can be achieved in a scalable way within 50 milliseconds using this function.

Realizing packet-optical integration with SDN and OpenFlow 1.1 extensions

This paper discusses the benefits of applying software defined networking (SDN) to circuit based transport networks. It first establishes the need for SDN in the context of transport networks. This paper argues that the use of SDN in the transport layers could be the enabler for both packet-optical integration and improved transport network applications. Then, this paper proposes extensions to OpenFlow 1.1 to achieve control of switches in multi-technology transport layers. The approach presented in this paper is simple, yet it distinguishes itself from similar work by its friendliness with respect to the current transport layer control plane based on generalized multiprotocol label switching (GMPLS). This is important as it will enable an easier and gradual injection of SDN into existing transport networks. This paper is completed with a few use case applications of SDN in transport networks.

Distributed Cloud Computing: Applications, Status Quo, and Challenges

A distributed cloud connecting multiple, geographically distributed and smaller datacenters, can be an attractive alternative to todays massive, centralized datacenters. A distributed cloud can reduce communication overheads, costs, and latencies by o ering nearby computation and storage resources. Better data locality can also improve privacy. In this paper, we revisit the vision of distributed cloud computing, and identify di erent use cases as well as research challenges. This article is based on the Dagstuhl Seminar on Distributed Cloud Computing, which took place in February 2015 at Schloss Dagstuhl.

Cloud Atlas: A Software Defined Networking Abstraction for Cloud to WAN Virtual Networking

One of the primary principles of Software Defined Networking (SDN) is that representing networks as a collection of simple abstractions implemented as an API - rather than as a collection of standardized and proprietary protocols and command line interfaces - will lead to networks that are easier to build and manage. Application of this principle has advanced furthest in cloud computing, where the OpenStack Quantum network service provides tenants in a data center with an abstraction of an enterprise LAN. The Quantum API implements a virtual network through a plug-in, which might in fact require protocols and command line interfaces to drive the physical hardware. However, existing OpenStack support for wide area connectivity is restricted to L3 IPsec and SSL VPNs which do not in general support quality of service (QoS). In this paper, we present Cloud Atlas, a SDN abstraction and API extending the Quantum virtual network into the WAN. Cloud Atlas is built on top of existing WAN network services (L1-, L2-, and L3VPNs) that do support QoS. Cloud Atlas makes these services available to OpenStack through a tight integration with Quantum. We discuss two prototypes we have built of Cloud Atlas, one based on command line scripts and one based on a network management system. We conclude the paper with some observations on applying the cloud service model to networking and the value of SDN abstractions in supporting such a service model.

Zeppelin - A third generation data center network virtualization technology based on SDN and MPLS

Just like computation and storage, networks in data centers require virtualization in order to provide isolation between multiple co-existing tenants. Existing data center network virtualization approaches can be roughly divided into two generations: a first generation approach using simple VLANs and MAC addresses in various ways to achieve isolation and a second generation approach using IP overlay networks. These approaches suffer drawbacks. VLAN and MAC based approaches are difficult to manage and tie VM networking directly into the physical infrastructure, reducing flexibility in VM placement and movement. IP overlay networks typically have an relatively low scalability limit in the number of tenant VMs that can participate in a virtual network and problems are difficult to debug. In addition, none of the approaches meshes easily with existing provider wide area VPN technology, which uses MPLS. In this paper, we propose a third generation approach: multiple layers of tags to achieve isolation and designate routes through the data center network. The tagging protocol can be either carrier Ethernet or MPLS, both of which support multiple layers of tags. We illustrate this approach with a scheme called Zeppelin: packet tagging using MPLS with a centralized SDN control plane implementing Openflow control of the data center switches.

Handling Performance Sensitive Native Cloud Applications with Distributed Cloud Computing and SLA Management

Cloud computing has been used as a platform to reduce cost and increase deployment flexibility for traditional enterprise three-tier web, and some video streaming applications. Typically these types of applications have fairly simple and self-understood performance requirements. Fine-grained constraints on the computation, storage, and networking resources are required support mission-critical enterprise use-cases at a reasonable cost. They are spelled out by service level agreements (SLAs) between the application and the cloud platform. Moreover, new distributed cloud platforms allow for additional deployment patterns, supporting more performance sensitive applications. For example, a specific gaming component will benefit being deployed in the proximity of the (mobile) end-user due to low-latency requirements. In this paper, we motivate the need for more complex performance requirement support with two use cases, electric utility metering and control and public safety. We describe an application management tool, called the Abstract Service Manager (ASM), which is designed to allow the expression of performance requirements in the automated deployment of distributed cloud-native applications. Together with a distributed cloud orchestration system, the ASM automatically mitigates the complexity of constructing performance sensitive applications and their deployment on a distributed cloud.

Innovation and the Next Generation Internet

In the last few years, academic researchers have begun to question whether the basic Internet architecture is sufficiently sound for long term growth. In this paper, we look at one underlying premise behind the argument: that innovation in the basic Internet infrastructure has become stalled and that the Internet architecture no longer supports innovation. We use Clayton Christensens innovation theory to frame the present work. We discuss two innovation trends - cloud computing and control/data plane separation - that are not likely to change the Internet architecture, and a new global communication network architecture under investigation - Information centric Networking - that could. Our conclusion is that, based on the commercial forces that have driven the Internets evolution since the mid-1990s, and absent a major change in the expected performance metric from customers, an innovative new global communication architecture different from the Internet is unlikely to be deployed.

Fostering rapid, cross-domain service innovation in operator networks through Service Provider SDN

Software defined networking (SDN) and Network Function Virtualization (NFV) are new approaches to next generation network architecture for operator networks that have received much discussion in the research literature and in new forums organized to standardize their interfaces. While these approaches to network architecture are important, they only cover part of the problem. A fundamental property required from any next generation architecture is support for rapid, cross-domain service innovation. In this paper, we discuss Service Provider SDN (SP-SDN), an architectural approach to rapid service innovation based on exposure of functionality for cross-domain control at the service layer. The functionality is exposed through Web-style interfaces that feature abstractions crafted by suppressing detail irrelevant for the majority of the created services. The control spans mobile, fixed and cloud operator networks, allowing the rapid and flexible provisioning of services across all three domains. We compare this approach to SDN and NFV, and find that SP-SDN complements rather than competes with the two. We present two examples of prototype systems built with SP-SDN.

LegoFi the wifi building blocks!: the case for a modular wifi architecture

The increasing demand for flexibility in WiFi network deployments along with more stringent requirements on performance and security stand in stark contrast to todays ossified and expensive WiFi architecture. In particular, todays WiFi networks consists of a large number of control and data plane network functions that are either bundled into a single access controller running on proprietary hardware or are distributed across the network to run on WiFi access points. This approach does not properly reflect the broad and evolving diversity of scenarios in which WiFi is deployed. This paper makes the case for a functional decomposition of the WiFi: we want to support the allocation and composition of individual (virtualized and programmable) WiFi function blocks, where and when they are most useful. This allocation may also be adjusted dynamically, e.g., during a failover or a scale-out. We present our vision and a rough functional decomposition, describe our proposed LegoFi architecture, and explore how LegoFi can benefitial in four different deployment scenarios.