You are on page 1of 7

Technical white paper

HP SDN Delegation
Scalable, low-risk network deployments using SDN delegation

Table of contents
Audience and Scope ...................................................................................................................................................................... 2
State of SDN ................................................................................................................................................................................... 2
OpenFlow and SDN ....................................................................................................................................................................... 2
Non-delegated SDN ...................................................................................................................................................................... 2
Delegated SDN ............................................................................................................................................................................... 3
Link and End-host Discovery .................................................................................................................................................. 3
Performance & Scaling Benefits ................................................................................................................................................ 4
Visual Representation of the Delegated Approach................................................................................................................ 4
Example Scenarios ........................................................................................................................................................................ 5
Non-delegated SDN network ................................................................................................................................................. 5
Delegated SDN network .......................................................................................................................................................... 6
Hybrid Network Deployment .................................................................................................................................................. 6
Conclusion ....................................................................................................................................................................................... 6

Click here to verify the latest version of this document

Technical white paper | HP SDN Delegation

Audience and Scope


This document describes how HPs SDN solution uses SDN delegation to achieve scalable, low-risk network redeployments.
The HP SDN Controllers delegation approach incorporates the rich feature set and innovation of SDN into existing traditional
networks with minimal impact or reconfiguration of the network infrastructure. The audience of this document may include
potential customers, 3rd party application developers, or solution architects.

State of SDN
Software-defined networking (SDN) is an emerging technology which separates the control plane of a network from the
data plane. In a traditional network, the entity which handles packets (data plane) is also the entity which makes decisions
about how those packets should be handled (control plane). The traditional approach places limits on the power and scope
of control plane decision-making.
In an SDN network, the control plane decision-making is performed by one or more controllers which coordinate to give
consistent control plane decisions. A team of controllers is often used when the control plane must be highly-available. The
control plane dictates all aspects of network operation on the data plane, including forwarding, access, policies, and quality
of service. It is the responsibility of the data plane to implement and enforce decisions made by the controller.
Applications are installed on the controller to add services across the data plane. As administrative needs change,
applications can be installed onto or removed from the controller. Changing installed applications can change data plane
network behavior with no changes to the underlying physical topology. In this way, SDN allows network administrators to
add control plane features without having to coordinate those features across all devices in the data plane.

OpenFlow and SDN


For switches and controllers to communicate, they must use a common communication protocol. OpenFlow is an industrystandard control protocol for SDN. HP has been a key contributor to the OpenFlow standard since version 1.0 in 2009. HP
has been involved with OpenFlow-based research and development since the standards inception and has developed
several award-winning solutions which use the OpenFlow protocol in our switches and controller.
OpenFlow allows matching on fields within packet headers and then taking action on matched packets. The match fields
include combinations of Ethernet type, MAC addressing, IP/IPv6 addressing, and TCP/UDP ports, among others. The
controller sends a rule over the control plane to communicate the match and action criteria to controlled switches. It then
becomes the responsibility of the controlled switches to enforce these rules on the data plane.
In research and industry, the OpenFlow protocol is typically used in one of two ways:
Non-delegated

The controller explicitly makes all forwarding decisions.


The OpenFlow standard refers to this as OpenFlow-only.
Delegated

The controller delegates some forwarding decisions to controlled switches.


The OpenFlow standard refers to this as OpenFlow-hybrid.
Packets with similar characteristics are said to be part of the same flow. Based upon the match criteria specified in the rule,
the flow may include all packets with the same destination MAC, or may only include those packets with the same 5-tuple,
7-tuple, or 12-tuple in the packet header.

Note:
OpenFlow-compliant switches come in two types: OpenFlow-only, and OpenFlow-hybrid. OpenFlow-only switches support
only OpenFlow operation, in those switches all packets are processed by the OpenFlow pipeline, and cannot be processed
otherwise. OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching operation, i.e.
traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing, IPv6 routing...), ACL and QoS processing. 1

Non-delegated SDN
When the controller does not delegate any decision-making, the controlled switches inform the controller of each new flow
thats established. In response, the controller programs rules onto the switches to dictate how future packets with similar
1

OpenFlow Switch Specification, version 1.3.2, section 5.1.

Technical white paper | HP SDN Delegation

characteristics should be forwarded. Since the controller has visibility into every new flow (and potentially every packet) on
the network, the controller is in a unique perspective to make comprehensive decisions about packet forwarding.
There are some cases where a non-delegated SDN is the right choice for a solution. In general, those cases may be
characterized as the network traffic handled directly by the HP SDN Controller being small in comparison to the
programmatic flexibility provided by the HP SDN Controller. Specific instances include:
Using the HP SDN Controller as an SDN-based appliance

For example, the HP SDN Controller may be combined with a single controlled switch to form a customized or low-cost
web proxy or firewall. The network administrator would write a custom application which would control flows through the
switch, and then place the switch in their network as a firewall.
Research Applications

The HP SDN Controller has a feature-rich programmable API which allows application developers to easily explore the
power of SDN. In research settings, performance or scalability are often not as significant concerns as functionality. As
such it is often desirable for research applications to have the controller make the forwarding decision for every packet in
the network.

Delegated SDN
The controller may choose to delegate some portion of the data plane forwarding decisions to the controlled switches. With
SDN delegation the controller still retains control over all packet forwarding on the data plane; however it chooses to
delegate the forwarding decision to controlled switches for the following reasons:
1.
2.

It reduces the complexity and scope of the forwarding decisions that the controller makes
It reduces the amount of traffic on the control plane between the switches and controller

Controlled switches in existing traditional networks have decades of embedded traditional networking logic. The SDN
controller does not add value to the solution if it merely replaces traditional forwarding logic. The value of SDN comes from
innovative functionality which is difficult or impossible to implement using traditional networking concepts. HPs SDN
solution architecture uses SDN delegation.
The HP SDN Controller has a corresponding setting which allows optimized operation with each type of OpenFlow-compliant
switch. Most switches are OpenFlow-hybrid switches and are capable of making the data plane forwarding decision
independently from the controller. The HP SDN Controller supports an optimized mode which takes advantage of this
capability for such switches by delegating some forwarding decisions to them.
The HP SDN Controller makes use of the NORMAL port. Even though support for the NORMAL port is optional in the
OpenFlow specification, most OpenFlow-hybrid switches support the NORMAL port in flow rules pushed by the controller.
The NORMAL port allows the controller to delegate the forwarding decision to the switch in the non-OpenFlow forwarding
pipeline.

Link and End-host Discovery


The controller in a delegated SDN network will selectively send rules to the switches which copy, steal, modify, or redirect
specific flows. The content of these rules is based upon the applications installed on the controller. These specific flows are
the only packets for which the controller explicitly makes the data plane forwarding decision. The forwarding decision for all
other packets is made by the controlled switches without involvement from the controller because the controller has
delegated that decision to the switches.
The HP SDN Controller uses special rules to enable link discovery and end-host discovery. The discovered links and endhosts are combined with the set of controlled switches to form a complete view of the network topology. This topology is
used by HP SDN Controller applications.
Table 1: Generic representation of rules necessary to accomplish link and end-host discovery
Match

Action

ethtype=0x8999

STEAL to controller (link discovery) Injected traffic to learn topology, similar to LLDP

ethtype=ARP

COPY to controller (end-host discovery) ARP Traffic

ethtype=IP,ip_proto=UDP,
udp_src=67,udp_dst=68

COPY to controller (end-host discovery) DHCP Traffic

Technical white paper | HP SDN Delegation

(any)

Forward to port NORMAL (all other packets)

To enable the controller to discover links between controlled switches, the HP SDN Controller injects SDN link-discovery
packets (using ethtype=0x8999) into the controlled network. The controller pushes rules to all controlled switches which
steal SDN link-discovery packets back to the controller. This mechanism allows the controller to discover links between
controlled switches, even when those switches are separated by one or more uncontrolled switches.
To enable the controller to discover end-host locations within the network, the HP SDN Controller pushes rules which send
copies of all ARP and DHCP packets to the controller. This mechanism allows the controller to observe a limited amount of
ARP/IP traffic, yet learn where end-hosts are located within the controlled network.

Performance & Scaling Benefits


When an SDN controller delegates the forwarding decision to traditional, established protocols it achieves performance and
scaling that is on-par with traditional networking, but with the added value of innovative SDN solutions.
Network switches employ custom-tailored ASICs to achieve line-rate forwarding. These ASICs are typically made up of a
collection of lookup tables, only some of which are controllable via OpenFlow. In current switch ASICs, the scalability of the
tables controllable via OpenFlow is typically much smaller than the scalability of tables like MAC or IPv4 forwarding tables.
For example, the HP 3800-series switches support 4K entries in the default OpenFlow TCAM, but support 64K entries in the
MAC table.
By delegating the forwarding decision to controlled switches, the controller prevents normal traffic forwarding from
consuming space in OpenFlow-controllable tables. By reserving all entries in the OpenFlow controllable tables for use by
SDN applications, the HP SDN controller retains maximum line-rate scalability for packets for which it wishes to explicitly
make the forwarding decision.

Visual Representation of the Delegated Approach


The difference between a delegated and non-delegated SDN network can be depicted visually with a representation of all
packets on the network. The answer to the question Who makes the forwarding decision? determines whether it is a
traditional network, delegated SDN network, or non-delegated SDN network.
Figure 1: Visual representation of all packet types on a traditional network.
IPv4
SIP

DNS

FTP

RTP
SMTP

TCP
HTTP

UDP

ARP

FTP
SSH

ICMP

IGMP

DHCP

FCoE

IEEE 802.3

LLDP

Q-in-Q

MPLS

TRILL

Spanning
Tree

IPv6
ICMPv6

DHCPv6

L2 traffic identity

Network
Optimizer

L3 traffic identity
L4 traffic identity
L7 traffic identity

Network
Protector

Technical white paper | HP SDN Delegation

In a non-delegated SDN network, the controller is responsible for the forwarding decision of all packet types on the
network. Some packet types (such as spanning-tree) are no longer necessary in an SDN network, because the controller
replaces the functionality they provided (resolving network loops). However, any packets which are generated by end-hosts
or adjacent traditional networks cannot be ignored by the SDN and must be forwarded properly by the controller.
In a delegated SDN network, the SDN controller can choose (based upon which applications are installed) for which packet
types it wants to explicitly make the forwarding decision. For example, if the Network Protector application were installed on
the HPN SDN controller, the controller would explicitly make the forwarding decision for DNS packets, while leaving other
packets to be forwarded by the traditional network logic. If the Network Optimizer application were installed on the HPN
SDN controller, the controller would explicitly make the forwarding decision for Lync (SIP, RTP) packets.
Since HPs SDN solution uses a delegated SDN approach, the value of SDN can be realized without the disruption of a
complete network overhaul required by a non-delegated SDN implementation. Network functionality can be migrated on an
as-needed basis to SDN, when doing so gives benefits that are too costly or complicated for the traditional network pipeline.

Example Scenarios
To illustrate the difference in scalability between a delegated and non-delegated SDN network, consider the following
examples:
Figure 2: Example network layout with 4 switches and 7 end-hosts.

For illustration purposes, well assume that every host is communicating with every other host on the network. Well also
assume that each OpenFlow rule controls forwarding from a specific source end-host to a specific destination end-host.

Non-delegated SDN network


In a non-delegated SDN network, each switch involved in the forwarding path for a flow must have an OpenFlow rule
installed. The number of OpenFlow rules on each switch in the configuration above would be:
Switch A
22 rules

Switch B
30 rules

Switch C
22 rules

Switch X
32 rules

Rules populate the tables on both edge switches and infrastructure switches. In the example above, the infrastructure
switch X has the most rules installed even though it is not directly connected to any end-hosts. In a real network, the
number of OpenFlow rules on infrastructure switches increases with each new end-host thats added to the network.
Adding a single end-host (A3) to switch A in the network above would change the number of rules on each switch by the
following amounts:

Technical white paper | HP SDN Delegation

Switch A
36 rules (+14)

Switch B
36 rules (+6)

Switch C
26 rules (+4)

Switch X
42 rules (+10)

The scalability of this approach is inherently limited by the OpenFlow-controllable table sizes of each switch in the
controlled network.

Delegated SDN network


In a delegated SDN network, each switch would have only the rules necessary for link and end-host discovery, along with
another rule to instruct switches to make the forwarding decision for all remaining flows:
Switch A
4 rules

Switch B
4 rules

Switch C
4 rules

Switch X
4 rules

The number of table rules in this approach is based on SDN functionality, rather than specific network flows. This means
that the number of rules only grows as new functionality is added to the HP SDN Controller, rather than as new end-hosts
are added to the network. As new applications were installed on the HP SDN Controller, more rules would be pushed to the
controlled switches.
When a new application is installed on the HP SDN Controller, the rules pushed by that application would be a combination
of static or traffic-dependent, based upon the purpose of the application. For instance the HP Network Protector application
inserts a static rule which redirects DNS requests to the HP SDN Controller, but it also inserts traffic-dependent rules to
block malicious hosts.

Hybrid Network Deployment


Figure 3: Hybrid Network Deployment

Delegation is useful not only in reducing the necessary rules on a switch and the traffic between a switch and the controller
but also allows for a mixed environment of both OpenFlow and Non-OpenFlow devices in a network. The traditional
definition of a hybrid switch meant that a switch could be configured with both OpenFlow and Non-OpenFlow VLANs at the
same time. This mode allowed for a demo deployment of an OpenFlow network across an existing network without
disrupitng the existing network.
Now there is a new definition of hybrid, specifically a hybrid network deployment. In this mode, not all devices on a network
need to support OpenFlow. The type of application will dictate which devices require OpenFlow and which do not.
For example, to deploy Network Protector or Network Optimizer, only edge devices need to be OpenFlow enabled. In this
case, the controller doesnt manage the traditional network. The power of this solution is that it eliminates the need to
replace non-OpenFlow capable devices at the core and distribution layers of an existing network.

Conclusion
For SDN network deployments, HP recommends the use of the HP SDN Controller in a delegated mode. The award-winning
Network Protector and Network Optimizer applications utilize the power of SDN in coordination with traditional network
6

Technical white paper | HP SDN Delegation

technologies, without the risk of an extensive network overhaul. The solution is scalable because it delegates scalability to
the traditional network pipeline, while retaining the power of SDN for the purposes of access and optimization.
Resources, contacts, or additional links
OpenFlow Specification
opennetworking.org/sdn-resources/onf-specifications/openflow
OpenDaylight
opendaylight.org

Learn more at
hp.com/go/sdn/infolib

Sign up for updates


hp.com/go/getupdated

Share with colleagues

Rate this document

Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for
HP 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. HP shall not be liable for technical or editorial errors or omissions contained herein.
Trademark acknowledgments, if needed.
4AA4-xxxxENW, Month 20XX

You might also like