The document discusses requirements for applying Software Defined Networking (SDN) in carrier grade networks using Openflow. It addresses three key requirements: 1) Scalability in terms of supporting a huge number of network elements and flows across multiple network domains. Openflow controllers must be able to scale sustainably to handle this. 2) Availability in that carriers require reliable failover and their networks cannot stop operating. Openflow controllers need to guarantee uninterrupted network function. 3) The IRIS SDN controller from ETRI aims to solve scalability and availability issues through a clustered, hierarchical design that can support large networks split across multiple operational units.

1. Byungjoon Lee
ETRI SDN Technology Research Section
bjlee@etri.re.kr
20/March/2014

2. Byungjoon Lee (bjlee@etri.re.kr)
Metro Ethernet Forum Definition
– describes a set of functionalities and requirements that architectures
should support in order to fulfill the operational part of network operators
• Scalability
• Reliability
• Quality of Service (QoS)
• Service Management
In order to be applied to carrier grade networks, Openflow
must be able to meet these requirements
– D. Staessens et al., “Software Defined Networking: Meeting Carrier
Grade Requirements”, Local & MetropolitanArea Networks (LANMAN),
2011 18th IEEEWorkshop on.
2

3. Byungjoon Lee (bjlee@etri.re.kr)
Scalability
– Problems
• Huge number of network elements, including SDN elements
• Huge number of flows
• Many network domains
– Question
• can a controller provide sustainable scalability for all these problems?
Availability
– Problems
• Service providers do not want their network to stop
• Reliable failover solution is required
– Question
• Is there any controller platform that guarantees non-stop operation of
underlying networks?
3

4. Byungjoon Lee (bjlee@etri.re.kr)
Example: load-balancing application from Broadcom
4
Environment
No of
tables
Configuration
Total number of
flows required
Openflow 1.0 1
• L4 source port, the load balancing factor
• 1 flow entry for each micro flow to load balance the traffic
• Load balancing algorithm on the controller
4K
Openflow 1.3 7
• 4 entries in the VLAN flow table to add 4 ingress ports in the VLAN
of the ingress traffic
• 1 entry in the Termination MAC flow table that configures the ingress
traffic with the router MAC and VLAN
• 1 ECMP group with 4 next hops (and the associated L2 interface, L3
unicast groups). This leverages ECMP capabilities of the hardware and
the controller is offload with the task
• 1 L3 routing table flow entry to match the IP destination and use the
ECMP group as the next hop for the matching traffic
7
Physical
port
Ingress
port
flow
table
VLAN
flow
table
Termination
MAC
flow
table
Unicast
Routing
Multicast
Routing
Bridging
ACL
Policy
flow
table
Apply
actions
Physical
port

5. 5
Group - all
Multicast/broadcast Reduce flow-mod records
Group - indirect
Group – fast failoverGroup – select
ECMP Instead of reactive failover
ReduceFlowTableSizeWithGroupTableEntries

6. Byungjoon Lee (bjlee@etri.re.kr)
Switches are now (almost) ready. How about controllers?
– Can you scale them if you need more PACKET-IN throughput?
– Can you replace the software images without impacting the network?
– Can you make the switches immune to controller failures?
6
Of course there are ‘elastic’ solutions
for this problem, but they are still
not good enough
ElastiCon: HotSDN 2013

7. Byungjoon Lee (bjlee@etri.re.kr)
A Spin-off project from Floodlight
Floodlight
– Openflow-based SDN Controller from BigSwitch (Open Source)
– Supports Openflow 1.0 (and soon will announce 1.3 support)
– Adopted widely by research communities
IRIS (v2.0.0 release is coming)
– Yet another Openflow-based SDN Controller from ETRI
– With an IO engine implemented from scratch on top of Java NIO
– Supports Openflow 1.0~1.3
• Floodlight/Loxigen-basedOpenflowAPI
– Provides an Open-source version: OpenIRIS (http://openiris.etri.re.kr)
– Provides a northbound API which is fully compliant with that of Floodlight
(to support 3rd party applications from various research communities)
– Focus on solving the scalability / availability issues of the
centralized control
7

8. Byungjoon Lee (bjlee@etri.re.kr) 8

9. Byungjoon Lee (bjlee@etri.re.kr) 9
OpenIRIS
httsp://github.com/bjlee72/IRIS
1.3.2-master-xen-final
master
loxigen
Link Discovery,
Topology Manager
Device Manager,
Learning Switch,
Firewall,
State Manager,
Storage Manager,
Link Discovery,
Topology Manager
Device Manager,
Learning Switch,
State Manager,
Storage Manager,
Firewall (Enhanced),
Net Failover (New),
Static Entry Pusher (OF1.3 support)

10. Byungjoon Lee (bjlee@etri.re.kr) 10
OpenIRIS IRIS
Floodlight/Loxigen Performance-Optimized Floodlight/Loxigen
Not Supported
Not Supported
Not Supported
3Q
3Q
Portability

11. Byungjoon Lee (bjlee@etri.re.kr) 11
OFController
queue Thread
queue Thread
queue Thread
queue Thread
process()
handleConnectedEvent()
handlePacketIn()
handleGeneric()
handleReadEvent()
Abstract methods
ClientChannelWatcher
msgs
Connection.read();
(implemented on
OpenflowJ-IRIS)
ClientChannelWatcher
ClientChannelWatcher
* The number of threads is configurable
OFProtocol

12. Byungjoon Lee (bjlee@etri.re.kr) 12
IRIS 1.0.0
IRIS-Xen
IRIS-Loxi-1
11,000,000 flows/sec
10,500,000 flows/sec
2,500,000 flows / sec
Ubuntu 12.04 LTS 64bit (Kernel : 3.5.0-23-generic)
CPU : Intel Xeon E5-2690 v2 3.00GHz (20 physical core)
RAM : 64G
Testing
environment
Benchmarking
Cbench : 1 core
controller: max 19 core
IRIS-Loxi-2 5,000,000 flows / sec (Loxigen + ByteBuffer support)
IRIS-Loxi-3 FUTURE PLAN (Hopefully) 10,000,000 flows / sec
(IRIS-Loxi-2 + Further Optimization)

13. Byungjoon Lee (bjlee@etri.re.kr)
Assumptions
– A (large) network is possibly split into multiple unit networks
– A unit network is managed by a controller (cluster)
Design
– Scalability & Availability for a (large) unit network is
provided by a controller cluster
• A cluster consists of multiple controller instances
• All controller instances are connected by a ‘middleware’
– Interoperability between unit networks is provided by a
controller hierarchy
13

14. Byungjoon Lee (bjlee@etri.re.kr)
Considerations
– Addresses exposed to data plane
– Transparency
– Horizontal scalability
– High availability
– State sharing
Functionalities
– Load balancing among physical
controller instances
– Switch migration
• For failed controller instances
• For newer controller instances
– Security
• Immune to attack such as DDoS
14
OFswitchSAController
Unit
Openflow
Network
IP #1
IP #2
IRIS
Controller
(Cluster)
 Openflow-based
middleware (IRIS-HiSA)
* security, reliability, scalability
Hazelcast
Controller instance
Controller instance
Controller instance
Controller instance
Controller instance
We believe OF-based
brokering middleware
will be one of the promising
applications of Openflow

15. Byungjoon Lee (bjlee@etri.re.kr)
Controllers forms IS-A relationships via
controller hierarchy
Sub-controllers flood their topological information
to super-controllers
15
Unit
Openflow
Network
Unit
Openflow
Network
Unit
Openflow
Network
Controller-to-Super Controller
Communication channels
Controller
Network
Topology
Controllers are able to apply flow records
reactively or proactively to the data plane
elements at network borders
Sub-controllers are able to ask queries to a super-
controller about the destinations that it does not
know

16. Byungjoon Lee (bjlee@etri.re.kr) 16
Floodlight/Indigo
A Network as a “Big Switch”:
Recursive Abstraction of Large Network
into a single switch with many ports

17. 17