Transcript ClosedFlow: OpenFlow-like Control over Proprietary Devices

1
ClosedFlow: OpenFlow-like
Control over Proprietary Devices
Ryan Hand, Eric Keller
2
Introduction
• SDN provides centralized control of network to
administrator
• Easy addition of networked services like
seamless mobility, web-server load balancing
• Services run on centralized controller using
standard API such as OpenFlow
3
Problem
• Huge capital invested in existing network
infrastructure
• Cannot simply throw away existing network
devices
• Cost of transition
4
Problem: Abrupt Transition To SDN
5
Alternate Solution
• Panopticon
▫ SDN switches on the edge
▫ legacy switch as a tunnel
• Problem:
▫ requires addition of new hardware
▫ specialized configuration for legacy switch
6
Solution: Smooth Transition To SDN
7
Contributions
• ClosedFlow for smooth transition
• Allows SDN control over existing legacy
hardware
• Architecture mimics OpenFlow but on existing
hardware
• Evaluate the system with 10 year old cisco
switches
• Illustration of functionalities if not limited to
OpenFlow
8
Background Detail
• OpenFlow
▫ Decoupling of control and data plane
▫ Standardized interface to add & remove flow enteries
▫ Allows running experimental protocols
• Ethane:
▫ The immediate predecessor to OpenFlow introduced
in 2006
▫ defined a new architecture for enterprise networks
▫ Focus: using a centralized controller to manage policy
and security in a network
▫ Similar to SDN two components
 a controller to decide if a packet should be forwarded
 Ethane switch consisting of a flow table
9
ClosedFlow
• Allow Layers on top of
OpenFlow
• But use network devices
without OpenFlow support
• Learn about OpenFlow in the
process
10
ClosedFlow
• More focus on OpenFlow: well-defined and open
interface
• But how closely related to OpenFlow?
• Four characteristics:
▫ Communication channel between central
controller and each switch
▫ Topology discovery
▫ Packet matching and Applying Actions
▫ Handling Packet-in events
11
ClosedFlow
• More focus on OpenFlow: well-defined and open
interface
• But how closely related to OpenFlow?
• Four characteristics:
▫ Communication channel between central
controller and each switch
▫ Topology discovery
▫ Packet matching and Applying Actions
▫ Handling Packet-in events
12
Controller Switch Control Channel
• Ability of the central controller to communicate
with each switch
• No need of physical (direct) connectivity
• Use of Spanning Tree Protocol in Ethane: discover
and calculate path
• Challenge: switch to operate over layer 3 interfaces
• Solution: OSPF routing protocol
13
Controller Switch Control Channel
• New Switch Addition?
• Minimum configuration:
▫ Set IP address for interface Loopback 0
▫ Configure ‘routed’ interfaces for switch-to-switch links
▫ Configure OSPF instance and set Router-ID to
loopback 0 IP
▫ Advertise Loopback & point-to-point networks (OSPF)
▫ Set up remote access (SSH or Telnet)
▫ Set enable mode password
14
ClosedFlow
• More focus on OpenFlow: well-defined and open
interface
• But how closely related to OpenFlow?
• Four characteristics:
▫ Communication channel between central
controller and each switch
▫ Topology discovery
▫ Packet matching and Applying Actions
▫ Handling Packet-in events
15
Topology Discovery
• Controller have Network wide view
• ClosedFlow: Two approaches
▫ Ethane approach: switch periodically send link
state information to controller; remote logging
from switch
▫ OSPF link state advertisements
16
ClosedFlow
• More focus on OpenFlow: well-defined and open
interface
• But how closely related to OpenFlow?
• Four characteristics:
▫ Communication channel between central
controller and each switch
▫ Topology discovery
▫ Packet matching and Applying Actions
▫ Handling Packet-in events
17
Packet Matching and Applying Actions
• Ability to control the flows
• Legacy switches use combination of
▫ Access-control lists
▫ Route Map
▫ Interface mapping to route map
• OpenFlow Example:
18
Packet Matching and Applying Actions
• ClosedFlow Example:
19
ClosedFlow
• More focus on OpenFlow: well-defined and open
interface
• But how closely related to OpenFlow?
• Four characteristics:
▫ Communication channel between central
controller and each switch
▫ Topology discovery
▫ Packet matching and Applying Actions
▫ Handling Packet-in events
20
Handling Packet-In Events
• Special action “send to controller” to enable
reactive network
• OpenFlow:
Packet
Arrival
Match a
flow entry
&take
action
If no
match
found;
send to
controller
21
Handling Packet-In Events
• ClosedFlow:
▫ Remote Logging on explicit deny
▫ Send Entire Packet to Controller
22
Handling Packet-In Events
• ClosedFlow:
▫ Remote Logging on explicit deny
▫ Send Entire Packet to Controller
23
Remote Logging on Explicit Deny
• Packet do no match access control criteria in
route map
• ‘explicit deny’ access control entry (ACE)
• Keyword ‘log-input’ for syslog entry on explicit
deny match
• Logging discriminator using regular expression
matching; suppress excessive logging with
threshold limits until flow rule installed
• Header send to controller, packet dropped
24
Remote Logging on Explicit Deny
25
Handling Packet-In Events
• ClosedFlow:
▫ Remote Logging on explicit deny
▫ Send Entire Packet to Controller
26
Send Entire Packet to Controller
• Forward-to-controller action applied
• Example:
27
Prototype
• 2 Independent programs to integrate CISCO
configuration backend with SDN controller
▫ Constantly running topology discovery application
which uses the info received from the remote logs
to display the current adjacencies
▫ Python program equivalent to static flow pusher
which allows flow modification to be specified
28
Experiment Setup
• Cisco 3550 multi-layer switches; IOS 12.2 (44)SE
• Cisco 3560 MLS with IOS 12.2 (55)SE for Cisco
Embedded Event Manager & Tool Command Line
scripting features
• Configure SDM Template
▫ Reformat TCAM table using switch database manager
▫ Optimize for policy based routing and TCAM ACL
entries
▫ Template options: Access, Default, Routing, VLAN
▫ Access: maximize resources for ACL functionality; ACL
entries on layer 3 & 4 are majority configuration
▫ ‘extended-match’ keyword with SDM template used to
enable policy based routing
29
Experiment Setup
• Enable IP Routing and Cisco Express
Forwarding
▫ To match layer 3 & 4 packet fields
▫ Interface forwarding behavior with policy based
routing
▫ CEF uses Forward Information Base and
Adjacency tables performing fast IP switching
with PBR route maps
30
Evaluation/Results
• Direct co-relation between installed flow rules
and TCAM storage
• 3 flow rule datasets used
▫ Realistic enterprise sampling with realistic IP
ranges, port ranges, layer 3&4 matching
▫ Completely random source/destination IP and
source/destination port combination
31
Evaluation/Results
32
Evaluation/Results
33
OpenFlow Extensions
• Use of legacy switches allow to go beyond
OpenFlow capabilities
• OpenFlow caused limitation in terms of security
and monitoring with triggered events
34
Equipment Dependency
• Identical functionality of Cisco 3550 3560 present in
other vendors
• Tested HP and Juniper
• Rich functionality in Cisco newer models
• Some models have added packet classification
granularity with NBAR (Network Based Application
Recognition) allowing deep packet inspection to
classify traffic
• Use of Link Layer Discovery Protocol or logging
Cisco Discovery Protocol adjacency changes aids in
avoiding OSPF
35
Conclusion
• ClosedFlow is layer providing OpenFlow like
programmability to legacy network configs.
▫ Giving some insight into
commonalities/differences
• Eliminates the barrier of transition and costly
upgrades
• Provides custom control applications
36
Limitations
• Topology Discovery
▫ Remote Login considered easy and simple over OSPF;
OSPF method not tested
• Handling Packet-in events
▫ Remote Log-in on explicit deny: header forwarded but
packet dropped unlike openflow
▫ Send entire packet to controller: overhead for reactive
networks
• Prototype not implemented; only functionalities
assuming would provide full functionality as
proposed
37
Questions?
38
References
• ClosedFlow: OpenFlow-like Control over
Proprietary Devices
▫ Ryan Hand, Eric Keller
• A Survey of Software-Defined Networking: Past,
Present, and Future of Programmable Networks
▫ Bruno Nunes Astuto, Marc Mendon¸ca, Xuan
Nam Nguyen, Katia Obraczka, Thierry Turletti