Software

Defined Networks (SDN) and OpenFlow

Technologies around Software Defined Networks and Openflow are receiving significant
attention in the networking industry. The goal of this white paper is to explain the
concepts and use cases around SDN and outline the efforts of Alcatel-Lucent to lead the
industry in this area.

Introduction
Reviewing todays datacentre networking eco-system, an overarching approach to
network resource abstraction and network programmability is required. In decoupling
users (applications consuming resources) from the physical network resources,
applications can evolve independently of networking capabilities. SDN aims to achieve
this by defining a framework that utilises standardised interfaces between applications
and networks.

Currently, industry attention is being focussed on southbound API interfaces, detailing

how an SDN framework interacts with the network. A number of communication
protocols and interfaces, including existing protocols such as NetConf and SNMP or new
approaches based on Web services and ReST/SOAP APIs are being discussed and can
be used to realise this. OpenFlow is another such protocol.

In contrast, little attention has been given to defining northbound API interfaces
between an SDN framework and the applications themselves. Alcatel-Lucent believes
that the key to network programmability is through the standardisation of this interface,
abstracting and generalizing the way applications interact and consume networking
resources. RESTful/SOAP based interfaces are possible approaches for such API.

Applications and Networks

Network service providers are increasingly facing the challenge of meeting the
requirements of application developers for rapid network service deployment. Cloud and
virtualization technologies together with distributed systems techniques enable the
rapid deployment of applications with dynamic scaling and new reliability models. These
applications need to rely on a network that can rapidly adapt to service requests. Even
though network technologies have evolved to meet the scale demanded of cloud
applications both in the control and data planes, network programmability is still
missing.

Page 1 of 10 |
 Figure 1 SDN bridging the gap between applications and networks.

The gap between networks and applications is usually a matter of perspective. The
application centric view often ignores network resource limitations, such as latencies,
bandwidth availability, redundancy domains, etc. It also prevents applications from
using advanced network services such as security, load balancing, and traffic
optimization that can simplify the application design. Long before the advent of cloud
computing, P. Deutch, a Sun Systems scientist posited the eight fallacies of distributed
computing that are directly applicable today. These fallacies include assumptions that
the network is reliable, latency is zero, bandwidth is infinite, and the network is secure
etc. These fallacies highlight the network considerations that any cloud based
application design must account for.

On the other hand, the network centric view sees the applications as black boxes
without a mechanism of understanding their requirements. Requirements for Layer 2 or
Layer 3 resource isolation, separation of reliability domains, application bandwidth
requirements and burstiness characteristics are unknown to the network operator.

The goal of SDN is to bridge the gap between applications and networks and enable the
rapid consumption of network services, by providing visibility and control to applications
There are two main components of SDN: The first is the configuration and consumption
of new services by applications. Ideally, applications must be able to define their
network requirements in abstract terms, that are independent of the underlying
network technologies. These requirements are mapped to a specific network design
that can be implemented utilizing a specific network technology. A binding process is
the used, to dynamically associate these network designs with specific network
elements. The second component is related to visibility, and exposes performance and
fault monitoring services to applications.

The industry is aggressively moving to address this gap, and Alcatel-Lucent is actively
participating and leading these activities both in standards organization as well as in the
development of specific products.

Page 2 of 10 |
SDN Controllers and APIs

Figure 2 SDN framework

Software Defined Networks expose an abstraction layer that bridges the gap between
the application requirements and the network capabilities. This abstraction layer is often
referred to as an SDN Controller. The control path of an SDN controller provides two
different types of interfaces.

1. Application APIs define a standard method that enable an SDN controller to

expose the type of network services that can be consumed by applications, as
well as allowing applications to request the network services that meet their
needs.

2. Network APIs, are mechanisms used by the SDN controller to communicate

with individual network elements and/or network management systems for
provisioning services, forwarding behaviors and other OA&M functions. These
mechanisms can utilize a range of protocols. Specifically, the SDN controller
interface may utilize:
a. Direct management of network elements through CLI/SNMP/Netconf or
policy based interfaces (Radius/DIAMETER) that enable provisioning of
resources and/or distributed protocols when such protocols are utilized.
For example an SDN configuration might require the instantiation of a VRF
component or an ACL in a router. Such configuration can always be
performed through existing interfaces.
b. Network management systems that manage end-to-end services such as
the 5620 Service Aware Manager. The 5620 SAM allows the end-to-end
service provisioning and can be used for example for the instantiation of

Page 3 of 10 |
 MPLS or VPLS services. SAM provides a rich northbound API based on
SOAP/XML technologies that allow such interfaces.
c. Openflow controllers that manage specific parts of the network and
provision individual forwarding in network elements by utilizing the
Openflow protocol. Unlike the above techniques, Openflow controllers
offer the capability to program individual forwarding entries in switches
and routers and enable flow-level granularity in network management.

Another important characteristic of SDN is the ability to provide to applications real

time visibility of the network in terms of faults, performance, capacity, location etc.
This data is aggregated by the SDN controller and made available to the applications.
The ALTO protocol work currently led by Alcatel-Lucent in the IETF provides location
function. Classic technologies such SNMP traps have to be extended to provide
exposure of failures to applications.

Openflow and its role in SDN

Figure 3 Openflow model

As mentioned above, one of the possible mechanisms that can be used for
programming the network behaviour is Openflow and it mainly applies to the control
path of SDN. This is a new protocol that is being standardized by the Open Networking
Forum. The goal in defining OpenFlow is to enable network operators to introduce new
methods for controlling and managing network resources.

OpenFlow technologies are based on the separation of the control and forwarding plane
and define the standard protocol between a logically centralized controller and one or
more forwarding elements that are distributed in the network. Forwarding elements can
be based on hardware or software implementations and can have a variety of
processing power capabilities. Openflow can be especially useful in some use cases
where it is not architecturally feasible for network elements to participate in distributed
control protocols. These can include virtualized servers with software virtual switches
and remote access devices such as CPEs, WiFI access points, etc.

Page 4 of 10 |
Alcatel-Lucent is in the process of joining ONF where OpenFlow/SDN is being developed
with the aim of ensuring that an industry-wide converged approach to SDN is realized.

Important Standardization Activities

Alcatel-Lucent believes that SDN is a powerful framework that will enable networks to
provide new value to applications. By combining network intelligence with open
application APIs, application developers will be able to better utilize network services
and rapidly create applications that are portable across a range of network technologies
and vendors. This will create new value for the network and unleash innovation. Our
emphasis is therefore on the definition of the SDN controller Application API.

Network APIs with their respective network configuration protocols are deemed less
important, as SDN controllers will utilize a range of existing protocols such as SNMP,
XMPP, NetConf, ReST/XML, as well as new protocols such as Openflow.

Alcatel-Lucent fully supports programmable networks and as such will continue its
involvement and leadership in the IETF which is the key organization for the
standardization of network protocols.

Page 5 of 10 |
FAQ
What is OpenFlow?

OpenFlow (OF) is a standard being developed by the Open Networking

Foundation (ONF) that defines the protocol between switches and routers and an
external controller, or in other words a standard method to interface between
the control and data planes. In todays network switches, the data forwarding
path and the control path (e.g., routing protocols) execute in the same device.
The OpenFlow specification defines a new operational model for these devices
that separates these two functions with the packet processing path on the switch
but with the control functions such as routing protocols, ACL definition moved
from the switch to a separate controller. The specification defines the protocol
and messages that are communicated between the controller and network
elements to manage their forwarding operation.

What is SDN (Software Defined Networks)?

Software Defined Networks refers to a set of mechanisms and protocols that will
enable network management systems and end-user applications to interact with
network elements, and provides visibility and control for both the data path and
control layer functions. The concept of Software Defined Networks encompasses
not only the configuration of the data path by an control path as provided by
OpenFlow - but can also define the interaction between applications and the
network that will allow application developers to define their requirements and
dynamically consume network services.

What is OpenFlows focus?

OpenFlow is currently focused mostly on data center and isolated enterprise

network implementations. Google is deploying an intra-DC network deployment
with Openflow, where Openflow is used as a traffic engineering tool, similarly to
what MPLS has been used for so far. Other implementations are focused on
network virtualization in cloud computing environments where Openflow is used
to control overlay networks.

At present, potential Service Provider use-cases are around traffic-steering and

hybrid-cloud/cloud-bursting, although there is no clear view on whether existing
network features/protocols can be re-used or a new set of control and
forwarding toolkits need to be defined.

Page 6 of 10 |
What are the OpenFlow components?

An OpenFlow switch has the ability to use generic matching criteria, based on
any field of the packet header, to determine the forwarding behaviour for each
packet or flow. The switch forwarding entries are programmed by an Openflow
controller, that can be an external control process, that determines how each
flow must be forwarded based on the application requirements. The controller
and switch utilize the Openflow protocol for exchanging information.

What are the expected benefits of implementing OpenFlow?

Innovation / service velocity - Control functions (instead of protocols) are

decoupled from forwarding elements and can be implemented in external
servers. This is especially useful in use cases where forwarding elements do
not have the processing capacity to participate in distributed control plane
processing.
Fine grain dynamic control of per-flow forwarding behavior can be applied at
the edges of the network to better manage resources.

Although there is a potential for cost improvements by using merchant only

silicon, it has yet to be validated and does not reflect use-cases depicting service
rich edge or core platforms required by service providers and enterprises to roll-
out carrier-grade application aware and application fluent networks.

What is the OpenFlow specification evolution path and possible timelines?

Although the evolution of OpenFlow is yet to be determined and is being

discussed, indications of ONF suggests the following:

OF 1.0 (03/2010): Most widely used version, MAC, IPv4, single table
OF 1.1 (02/2011): MPLS tags/tunnels, multiple tables, counters
OF 1.2 (12/2011): Wire protocol, IPv6, basic configuration, extensible
expression
OF 1.3 (04/2012): Enhancements for IPv6, PBB, Per flow metering, etc.
OF 1.4 (08/2012): Capability discovery, test labs, etc.

What are the areas not currently covered by the OpenFlow specification?

Off-loading some control functions to network elements (without sacrificing

controller centralized visibility) to support interaction with local, time-critical
control functions, (for example, protection-switching including APS and
ERPS/G.8032, MC-LAG, and FRR, OAM including BFD, CC, and DM; Subscriber
H-QoS, IGMP tracking, etc.)

Page 7 of 10 |
 Support for service edge "high-touch" functions (metro edge services, H-QoS,
charging, DPI, CDN, video, voice, etc.)
Controller capabilities and functions related to scalability and availability, as
well as interoperability between OpenFlow controllers provided by different
vendors. In addition, interactions with other policy elements, path
computation elements, network management systems, and applications are
undefined.

What are the current limitations with OpenFlow?

There is no definition for a controller hierarchy or inter-controller

communications. This creates the risk for network providers and enterprises
to be locked into a single vendor controller technology.
OpenFlow activity has focused on resolving flow-table manipulation in
network elements and has not taken a holistic approach to resolve key issues
(service-AD, OAM, load-sharing, etc.).
Scalability and reliability of the centralized approach is unproven.
The ability of a centralized control plane to support failover and recovery in
latency sensitive data center environments is unproven
Limited protocol support
o Ethernet encapsulation support only. Service providers and enterprise may
require legacy interfaces
o IEEE forwarding plane encapsulations limit OpenFlow matching capabilities
o OA&M, registration protocols, multicast capabilities are not defined

What are the differences between OpenFlow and Software Defined

Networks?

SDN and OpenFlow are complementary technologies. OpenFlow is one of several

mechanisms for controlling the forwarding behaviour of network elements. The
goal of SDN is to enable existing networks to become more adaptable to
applications. More importantly, the SDN technology can be used to communicate
application requirements between different network technologies and provides
an evolutionary path to network programmability. The goal of SDN is to provide
the means to control OpenFlow networks as well as existing networks.

Is OpenFlow the only way to realize Software Defined Networks?

OpenFlow is one of the potential building blocks towards SDNs. It provides the
basic mechanisms to program flow entries from an external controller. It should
be noted that several other methods already exist to achieve the same functions.
Since OpenFlow does not define the mechanisms for interacting with existing
control plane and network management infrastructure, additional functions will
be necessary to realize SDNs

Page 8 of 10 |
 Alcatel-Lucent envisions that SDN platforms might be used to define edge
policies, while existing control protocols are utilized at the core of the network.
For example, OpenFlow could be used to define how traffic from a virtual
machine is mapped into a VLAN in a virtual switch running in the hypervisor
while network infrastructure protocols are used to determine how to transport
the traffic across the data center network or how traffic is mapped to an LSPs at
the edge of an MPLS network, while existing protocols (e.g., LDP and BGP) are
still used to signal the MPLS LSPs in the core.

What work is being done in the IETF to define SDN?

At IETF 82, a BoF was held with the objective of soliciting contributions and
fostering general discussions on the definition and scope of SDN. At the
BoF, Alcatel-Lucent submitted a draft document to IETF on the use cases and
framework for SDN (draft-stiliadis-sdnp-framework-use-cases) articulating a
framework for network abstraction and programmability that is applicable to both
existing distributed and new logically centralized control-planes as provided by
OpenFlow. Although discussions are ongoing, a second BoF has been scheduled
for IETF84, whereby it is expected that a problem statement draft proposal will
be submitted for discussions.

When can OpenFlow be expected on ALU products?

Alcatel-Lucent is actively engaged with our enterprise and service provider

customers to obtain feedback on the OpenFlow use cases that might be of
interest to them. OpenFlow use cases are mostly being discussed in the data
center environments at this time. Select customers have shown interest in
OpenFlow for the future deployments with existing focus on evaluation and lab
trials.

When can Software Defined Networks be expected on ALU products?

Alcatel-Lucent already provides capabilities that are aligned with the SDN
framework throughout its product families. The 5620 Service Aware Manager
provides a rich set of APIs that enable customers to programmatically interact
with the network and introduce new policies and capabilities. This set of APIs will
be expanded over the next releases in order to realize the vision of SDN.

The OmniSwitch and Service Router product families also provide native
programmability capabilities through scripting. These capabilities will be
extended with the support of Web services in future product releases.

Page 9 of 10 |
 ALU also fully supports programmable network models, in line with SDN, as
highlighted in the IETF ALTO working group. This work is spearheaded by ALU
Bell Labs.ALU also provides a comprehensive policy management framework that
can be used as part of the transition to SDN, by correlating service creation with
service provider policy and charging mechanisms. This architecture is already in
existence in several wireless and wireline networks.

Page 10 of 10 |