On the Practical Applicability of SDN Researchcompunet/www/docs/roberto/sdn...IEEE/IFIP Network...

On the Practical Applicability of SDN Research

Roberto di Lallo

Gabriele Lospoto

Massimo Rimondini

UNIVERSITÀ DEGLI STUDI

ROMA

TRE

Mirko Gradillo

Claudio Pisa

IEEE/IFIP Network Operations and Management Symposium Istanbul – Turkey – 25/29 April 2016


ROMA

TREIEEE/IFIP Network Operations and Management Symposium Istanbul – Turkey – 25/29 April 2016

4050

SDN has been the Future…


ROMA


4050

Number of citations of the original OpenFlow paper

Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev. 38, 2 (March 2008), 69-74.

…now is the Present


ROMA


Why?


ROMA


Why?


ROMA


Because SDN lets us innovate in a very flexible and customizable way

Why?


ROMA



Before SDN

Why?


ROMA



Before SDN

Closed HW

Why?


ROMA



Before SDN

Closed SW

Closed HW

Why?


ROMA



Before SDN After SDN

Closed SW

Closed HW

Why?


ROMA




Closed SW

Closed HW

Standard HW

Why?


ROMA




Closed SW

Closed HW

Standard HW

Standard Interface (OpenFlow)

Why?


ROMA




Closed SW

Closed HW

Standard HW


Control Software running on general purpose HW

Why?


ROMA



Closed SW

Closed HW

Standard HW


Control Software running on HW general purpose



ROMA


Problem

• How much do network devices support SDN functionalities through the implementation of the OpenFlow protocol?


ROMA


Problem

• How much do network devices support SDN functionalities through the implementation of the OpenFlow protocol?

Our contribution

A critical review of the literature about SDN by: • Defining a methodology to verify the support of SDN-related

functionalities in a network device • Applying our methodology to devices from 7 different vendors

(A selection of the) Literature on SDN


ROMA




ROMA


• SDN has been attracting the interest of the research community for at least a decade, resulting in a very rich body of contributions



ROMA



• We sampled the literature according to the following criteria: • recent contributions • dependence on a correct implementation of OpenFlow functions



ROMA




• Grouped in three class:



ROMA


Languages Deployment Rules Optimization




(A selection on the) Literature on SDN


ROMA


Languages Deployment


• Selection of the most recent ones that we consider most directly impacted by the accuracy of OpenFlow implementations


Rules Optimization Main goal: reducing the size of flow tables Works: • Optimizing the “One Big Switch” abstraction in software-defined

networks • Palette: Distributing tables in software-defined networks • Scalable flow-based networking with DIFANE • DevoFlow: Scaling flow management for high- performance networks • SwitchReduce: Reducing switch state and controller involvement in

openflow networks • Optimizing rules placement in OpenFlow networks: Trading routing for

better efficiency



ROMA


Languages Rules Optimizer




Deployment

Main goal: deploying SDN in well-known application scenarios Works: • SDX: A software defined Internet exchange • Rethinking Virtual Private Networks in the software-defined era • Scalable programmable inbound traffic engineering • Wireless mesh software defined networks (wmSDN)



ROMA


Deployment Rules Optimizer




Languages

Main goal: introducing languages for an abstract specification of packet forwarding policies Works: • A compiler and run-time system for network programming languages • Frenetic: A network programming language • Modular SDN programming with Pyretic


ROMA


Limitation HP Dell Brocade Arista Networks

Extreme Networks

Flow table size constraints

Restricted match conditions

Single flow table

No MPLS support

Hybrid-port mode unsupported

NORMAL port unsupported

OpenFlow implementation limitations for some top switch vendors

Device Testing Methodology


ROMA




ROMA


1. Goals: 1. Verifying basic and advanced packet handling functions 2. Assessing the switching performance of the datapaths



ROMA



2. Test conditions: 1. Various network topologies 2. Different SDN controllers



ROMA




3. Testing tools: 1. Ryu Openflow 1.3 Compliance Test Suite

1. Publicly available 2. Very rich set of test cases 3. Constantly updated 4. Also used by some vendors for compliance tests



ROMA




3. Testing tools: 1. Ryu Openflow 1.3 Compliance Test Suite

1. Publicly available 2. Very rich set of test cases 3. Constantly updated 4. Also used by some vendors for compliance tests

2. Custom Tests 1. Manual interaction with the tested datapaths 2. Ad hoc written controllers

Ryu Test


ROMA


1. Four classes of test cases

Ryu Test


ROMA



1. Action: verifies packet forwarding and manipulation function

2. Group: verifies support for group actions

3. Match: verifies an extensive assortment of match conditions

4. Meter: verifies support for the meter table

Ryu Test


ROMA



1. Action: verifies packet forwarding and manipulation function

2. Group: verifies support for group actions

3. Match: verifies an extensive assortment of match conditions

4. Meter: verifies support for the meter table

2. Every test case is repeated multiple times with test packets that have

different sets of headers or transport different protocols

Custom tests


ROMA


Functional tests

Support for the Normal reserved port

Behaviour with multiple configured controllers

Existence of hidden flow tables with default entries

Targeted versions of selected Ryu test cases

Operation of group actions

Operation of bitmasks applied on matched header fields

Support for pushing/popping single or multiple VLAN tags

Support for pushing/popping single or multiple MPLS labels; assessment of label stack size limits

Support for metadata in match conditions and actions

Performance tests

Switching performance as a function of flow table size

CPU usage for flow entry matching and packet switching

Time required to install entries in the flow table

Custom tests


ROMA


Functional tests

Support for the Normal reserved port

Behaviour with multiple configured controller

Existence of hidden flow tables with default entries

Targeted versions of selected Ryu test cases

Operation of group actions

Operation of bitmasks applied on matched header fields

Support for pushing/popping single or multiple VLAN tags

Support for pushing/popping single or multiple MPLS labels; assessment of label stack size limits

Support for metadata2in match conditions and actions

Performance tests

Switching performance as a function of flow table size

CPU usage for flow entry matching and packet switching

Time required to install entries in the flow table

http://www.dia.uniroma3.it/~compunet/projects/sdn-dptest/

Devices under test


ROMA


ID 10GbE Ports Switching Fabric Capacity

CAM OpenFlow version

OVS based

S1 8 About 2 Tbps CAM 1.3 No

S2 128 About 2 Tbps TCAM 1.3 No

S3 64 About 1 Tbps n/a 1.3, 1.4 Yes

S4 4 About 500 Gbps TCAM 1.3 No

S5 4 About 500 Gbps TCAM 1.3 No

S6 72 About 1 Tbps n/a 1.3 No

S7 40 About 500 Gbps n/a 1.3 Yes

OVS n/a n/a (sw switch) No 1.x Yes

Results – Count of passed Ryu tests


ROMA


991

Results – Per test class


ROMA


Results – Per protocol


ROMA


Results – Insertion time


ROMA


OpenFlow Implementation Limitations (revised)


ROMA




ROMA


From documentation



ROMA


From documentation Outcomes of Ryu tests

+



ROMA


From documentation Outcomes of Ryu tests Outcomes of custom tests

+

+



ROMA



+

+

=



ROMA



+

+

=

- Dependencies among header fields in flow entries - Ineffective (but admissible) combinations of match

conditions

Constraints on the structure

of flow entries



ROMA



+

+

=

- Wilcards consume a lot of space in flow tables - Matching headers of layer 3+ consumes a lot of space

in flow tables

Flow table capacity

restrictions



ROMA



+

+

=

- Flow entries failing to be stored - Ineffective table-miss flow entry - Incorrectly updated matched packet counters - Non-deterministic behavior - Malformed OpenFlow packets - Improper flow table IDs - Incorrectly inherited header fields for pushed/popped MPLS

tags - Unexpectedly discarded packets - Rules failing to be installed at a high rate

Erroneous and inconsistent

behaviors



ROMA



+

+

=

- (mostly) missing MPLS support Unsupported functions

Literature on SDN


ROMA


Constraints on the structure of flow

entries

Flow table capacity restrictions

Erroneous and inconsistent

behaviors

Unsupported functions

Rules Optimization

Optimizing the “One Big Switch” abstraction in software-defined networks

Palette: Distributing tables in software-defined networks

Scalable flow-based networking with DIFANE

SwitchReduce: Reducing switch state and controller involvement in openflow networks

DomainFlow: Practical flow management method using multiple flow tables in commodity switches

Deployment

SDX: A software defined Internet exchange

Rethinking Virtual Private Networks in the software-defined era

Scalable programmable inbound traffic engineering

Wireless mesh software defined networks (wmSDN)

Languages

A compiler and run-time system for network programming languages

Frenetic: A network programming language

Modular SDN programming with Pyretic

Conclusions and Future Work


ROMA




ROMA


SDN Research in the field of SDN is largely unaware of several restrictions encountered when it comes to deploying a proposed architecture on real devices



ROMA



This work estimates the gap between research results and their practical applicability on currently available devices



ROMA



This work estimates the gap between research results and their practical applicability on currently available devices

Apply our methodology to additional devices Extend our set of custom tests


ROMA


http://www.dia.uniroma3.it/~compunet/projects/sdn-dptest/

Date post:	23-Oct-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

On the Practical Applicability of SDN Researchcompunet/www/docs/roberto/sdn...IEEE/IFIP Network...

Documents