NATIONAL & KAPODISTRIAN UNIVERSITY OF ATHENS INTERDEPARTMENTAL GRADUATE PROGRAM IN MANAGEMENT AND ECONOMICS OF TELECOMMUNICATION NETWORKS Master Thesis Software Defined Networking OpenDaylight Experimentation and Business Case Author: Achilleas P Grigoriadis Athens December 2014 Supervisor: Stathes Hadjiefthymiades

Agenda Introduction Software Defined Networking Openflow Protocol Openflow Switch Openflow Controller OpenDaylight SDN experimentation Business Case Conclusion

Introduction Data networking architecture Today’s Internet success Central Control model Decentralized/Distributed model Current IT market Change in data patterns Consumerization of IT Cloud Services Big Data Limitations

Software Defined Networking Network Architecture Network Control decoupled from Forwarding Centralized Intelligence Global view of the Network Applications & Services Vendor independence Easy to operate and monitor and provision Open APIs Northbound (Applications) Southbound (Network Devices) Adoption Providers: Google, Amazon Vendors: Cisco, Juniper, Alcatel

Openflow Protocol 2008 Stanford University Defines a protocol Controller to Switches Set of operations in the Switches Forwarding Instructions based on flows Packets sharing common set of characteristics Communications Interface : Control Layer --- Forwarding Layer SDN aware devices Switches Routers Access Points

Openflow Protocol Messaging Controller-to-switch messages are sent by the controller to: - Specify, modify or delete flow definitions - Request/Retrieve information from the switch - Send a packet back to a switch Asynchronous messages are sent by the switch to: - Send the controller a packet - Inform the controller that a flow has been removed (timer) - Inform the controller of a change in port status or switch error Symmetric messages can be sent by both the switch and the controller and are used for: - Hello messages on startup - Echo messages checking latency and connection verification - Experimenter messages to provide a path for future extensions

Openflow Switch Consists of three parts: Flow Table A Secure Channel Openflow Protocol Idea based on Switch table (TCAM) Flow table entry Dedicated Openflow enabled header fields to match against packets counters to update for matching packet actions to apply to matching packets - Required and Optional Categories

Openflow Controller Application running on a server Centralized intelligence and global network view Main concept in SDN architecture Maintain rules and performs network tasks Distributes instructions Add/Remove flows Neighbor discovery Device Capabilities Gather statistics Process packets Provide APIs Analytics Management Interface Modules: Topology Discovery Statistics AAA Southbound plugins Open northbound APIs

OpenDaylight 1/2 Collaborative open source project SDN described in layers Network Apps & Orchestration Controller platform Physical and virtual network devices Modular – Pluggable – Flexible Controller Java Virtual Machine Northbound APIs (REST,OSGi) Southbound interface (BGP-LS,Openflow) Service Abstraction Layer (SAL) Runtime modularity and extensibility Multitenancy/Slicing Clustering

OpenDaylight 2/2

SDN experimentation 1/4 OpenDaylight Controller – Openflow – Openflow enabled switch Implement SDN architecture Add/Remove flows Enable/Disable communication Verify Flow table Get statistics/info northbound API

SDN experimentation 2/4

SDN experimentation 3/4

SDN experimentation 4/4 Flow table Northbound API (REST)

Business Case 1/6 LOWER CAPEX SDN equipment is 30% more economic to Standard Networking equipment Lower OPEX Less Engineering expertise Less provisioning complexity Faster troubleshooting Easy real time monitoring SDN vs Standard Networking architecture New kind of Services (more flexible and customer oriented)

Business Case 2/6 ISP Offering internet access to ADSL users and P2P circuits to corporate customers ISP has point of presence in Athens and Salonika A new corporate customer (Big Data) needs 1Gbps circuit between Athens - Salonika Data replication once a week 02:00 – 05:00 The case is: What kind of service will the ISP offer the customer ? What kind of network architecture will the ISP use (standard or SDN) ? Is there an architecture that both the ISP and the Customer will benefit ? ISP uses 95% of its core infrastructure in peak hours

Business Case 3/6 ISP’s Traffic Pattern between Athens and Salonika 75% of the bandwidth is unused Option 1  ISP using Standard Networking architecture: - need to upgrade its core - can offer only fixed term contracts (1Gbps annual fee) - the Corporate Customer will pay an annual fee just for using the circuit once a week - high risk in case Corporate Customer leaves the service

Business Case 4/6 Option 2  With SDN the ISP can offer the Corporate Customer a flexible service “BW on demand” Pay to use the 1Gbps once a week 02:00 – 05:00 - Risk averse method for both ISP and Corporate Customer - BW is more efficiently used - Corporate Customer will pay less - ISP does not need to upgrade its Core - ISP can offer “flexible pay” contracts (time based) - Faster provisioning and easier to control/monitor

Business Case 5/6 ISP’s Investment. Ten year plan Option 1 : Standard Network (Upgrading core network) - Investment euro. Annual fee euro Option 2 : Software Defined Networking - Investment euro. 450 euro/week (23400 annually)

Business Case 6/6 ISP revenues based on NPVs Corporate Customer will save euros in this ten year plan using SDN rather than Standard Networking architecture - With SDN pays: euro/year (BW on Demand) - With Standard Networking pays: euro/year (annual fee)

Conclusion IT Megatrends have changed today’s network demands SDN provides a new, dynamic network architecture that transforms traditional network backbones into rich service-delivery platforms OpenDaylight discriminates among other SDN platforms offering unlimited capabilities SDN expected to reduce OpEx and CapEx Openflow protocol considered as the enabler of SDN allowing the Controller to interact with the Forwarding plane OpenDaylight will provide a common platform on top of which vendor products and services can be built The future of networking will rely more and more on software, which will accelerate the pace of innovation.

Questions ?

Athens December 2014 Thank you for your time Achilleas P Grigoriadis