1. ©2015 Extreme Networks, Inc. All rights reserved. Software Defined Networking (SDN) v2.0 Mikael Holmberg Senior Global Consulting Engineer mikael@extremenetworks.com

2. ©2015 Extreme Networks, Inc. All rights reserved. If I get an email with a PowerPoint attachment then save it to Google Drive My stock portfolio went up. Send me an alert to sell. If I’m within 500m from home, then open the garage door, set the heat to 20C and turn on the kitchen light If I send a text msg to IFTTT containing the string ‘#help’ then ring my cell phone Wikipedia: IFTTT is a web-based service that allows users to create chains of simple conditional statements

3. ©2015 Extreme Networks, Inc. All rights reserved. So what does this have to do with SDN? “Codify” your IT knowledge into your network

4. ©2015 Extreme Networks, Inc. All rights reserved. DNS/DHCP SDN AAATopology Services FirewallSkype for Business AnalyticsSIEMSIP/Voice ServicesBusiness Applications Location Services VPN

5. ©2015 Extreme Networks, Inc. All rights reserved. DNS/DHCP SDN AAATopology Services FirewallSkype for Business AnalyticsSIEMSIP/Voice ServicesBusiness Applications Location Services VPN If a medical device connects to the network then send its traffic through the firewall If a Skype (Lync) video call is initiated then apply dynamic priority and optimal network path for the call. If a device is found with a vulnerability then automatically redirect traffic to remediation server. If network demand from business applications is high then rate limit any Netflix traffic

6. ©2015 Extreme Networks, Inc. All rights reserved. OpenDaylight Basics: Overview  ODL is an Open Source project under the Linux Foundation with the goal of furthering the adoption and innovation of SDN through the creation of a common industry supported platform.  OpenDaylight provides a common platform to which applications and networking hardware can communicate with each other to provide a service to users.  Crucial component between network elements is communications. –Forwarding plane elements and controller –Controller and the applications or business logic.

7. ©2015 Extreme Networks, Inc. All rights reserved. OpenDaylight Basics: Modules & Bundles  Java chosen as an enterprise-grade, cross-platform compatibility language.  Java Interfaces are used for event listening, specifications and forming patterns  Maven – build system for Java  OSGi: –Allows dynamic loading bundles –Allows registering dependencies and services exported –For exchanging information across bundles  Karaf: Light-weight runtime for loading modules & bundles. –OSGi based. Primary distribution mechanism for Helium Release. Feature A Feature A Feature B Feature B SAL Karaf OSGi Framework (Equinox) OSGi Framework (Equinox) …

8. ©2015 Extreme Networks, Inc. All rights reserved. Southbound/Northbound API  Northbound – Interacts with the controller –Six constraints an API must follow to communicate with the controller designed to:  Maximize scalability  Independence and interoperability –Application generally written to interface at this level –Web based (REST)  Southbound - Interacts with network elements –Lower level interface  Modular approach –Communicates via open protocols to hardware.  Openflow  OVSDB –MD-SAL (Model Driven Service Abstraction Layer) –AD-SAL deprecated in this version but still used. Service Abstraction Layer (SAL)

9. ©2015 Extreme Networks, Inc. All rights reserved. REST API Constraints  REST API maps HTTP operations (PUT, POST, GET, DELETE, HEAD) into CRUD operations  URLs identify objects that the CRUD operations apply to  URLs can also trigger actions (e.g. Backup, Restore, Upgrade)  The actual commands and data are in the URL itself or in accompanying data files (usually JSON or XML) accompanying the URL on its way to the server  Reponses from the server can just by standard HTTP return codes or can include additional data (messages, requested files, etc).  Pretty much every programming language has libraries for consuming REST APIs  REST API access (for platform, except for account mgmt.) Six Constraints Client/S erver Stateles s Caching Layered System Uniform Interface Code on Demand

10. ©2015 Extreme Networks, Inc. All rights reserved. Service Abstraction Layer (SAL)  Abstraction is part of the key philosophies on which OpenDaylight has been modeled.  SAL distinguishes among various plugins based on the service they provide and consume –Service Providers or producers (Protocol Plugins) –Service consumers (Applications) –Inter-plugin communications.  As a framework, the key OpenDaylight aspires to provide developers is independence from device specifications. –Allows developers to focus on application logic and business problems.

11. ©2015 Extreme Networks, Inc. All rights reserved. Service Abstraction Layer (SAL) MD-SAL vs AD-SAL  Request routing  Service Adaption  Request (RPC) and notification routing  Data Storage

12. ©2015 Extreme Networks, Inc. All rights reserved. Service Abstraction Layer (SAL) AD-SAL 1.A packet arriving at Switch 1 will be sent to the appropriate plugin managing the switch 2.The plugin will parse the packet, generate an event for SAL 3.SAL will dispatch the packet to the modules listening for Data Packet. 4.Modules handles packet and sends packet_out through IDataPacketService 5.SAL dispatches the packet to the modules listening for Data Packet 6.Openflow message sent to appropriate switch ARP Handler L2 Learning s/w Service Abstraction Layer (SAL) Openflow Protocol plugin Openflow Protocol plugin OPenFlowJ Switch 1 Switch 2 Switch 3 (1) (2) (3) (4) (5) (6) IListenDataPacket IDataPacketService IListenDataPacket IPluginOutDataPacketService IPluginIntDataPacketService OpenFlow

13. ©2015 Extreme Networks, Inc. All rights reserved. Service Abstraction Layer (SAL) MD-SAL  Allows developers to work in a silo, agnostic of the service interface exposed by the modules providing services.  Designed to glue together the modules horizontally by allowing developers to use generic interfaces for service discovery and consumption.  Key differences from AD-SAL –Providers create model of the data or service they expose. –Models are in the form of YANG definitions. –YANG complier is used to create uniform APIs –APIS are tool generated, high level of uniformity between each in terms of usage and definitions.

14. ©2015 Extreme Networks, Inc. All rights reserved. Service Abstraction Layer MD-SAL Packet sent to Controller OpenFlow parses the packet OpenFlow translates it to MD-SAL routes notification MD-SAL Routes the RPC to OpenFlow plugin Plugin process packet Programm Flow Update MD-SAL Database Flowmode sent to switch

15. ©2015 Extreme Networks, Inc. All rights reserved. MD-SAL “Add Flow” 1.Registrations are performed when the controller and its plugins or applications are started. a)The Flow Programmer Service registers with the MD SAL for Flow configuration data notifications, and b) The OF Plugin registers (among others) the ‘AddFlow’ RPC implementation with the SAL. Note that the RPC is defined in the OF Plugin model, and that the API is generated during build time. 2.A client application requests a flow add through the REST API of the controller. (Note that in the AD-SAL, there is a dedicated NB REST API on top of the Flow Programming Service. The MD-SAL provides a common infrastructure where data and functions defined in models can be accessed by means of a common REST API. The client application provides all parameters for the flow in the REST call. 3.Data from the ‘Add Flow’ request is deserialized, and a new flow is created in the Flow Service configuration data tree. (Note that in this example, the configuration and operational data trees are separated; this may be different for other services). Note also that the REST call returns success to the caller as soon as the flow data is written to the configuration data tree. 4.Since the Flow Programmer Service is registered to receive notifications for data changes in the Flow Service data tree, the MD-SAL generates a ‘data changed’ notification to the Flow Programmer Service.

16. ©2015 Extreme Networks, Inc. All rights reserved. MD-SAL “Add Flow” Contd.. 5.The Flow Programmer Service reads the newly added flow, and performs a flow add operation (which is basically the same as in the AD- SAL). 6.At some point during the flow addition operation, the Flow Programmer Service needs to tell the OF Plugin to add the flow in the appropriate switch. The Flow Programmer Service uses the OF Plugin generated API to create the RPC input parameter DTO for the “AddFlow” RPC of the OF Plugin. 7.The Flow Programmer Service gets the service instance (actually, a proxy), and invokes the “AddFlow” RPC on the service. The MD-SAL will route the request to the appropriate OF Plugin (which implements the requested RPC). 8.The “AddFlow” RPC request is routed to the OF Plugin, and the implementation method of the “AddFlow” RPC is invoked. 9.The “AddFlow” RPC implementation uses the OF Plugin API to read values from the DTO of the RPC input parameter. (Note that the implementation will use the getter methods of the DTO generated from the yang model of the RPC to read the values from the received DTO.) 10.The "AddFlow" RPC is further processed (pretty much the same as in the AD-SAL) and at some point, the corresponding flowmod is sent to the corresponding switch.

17. ©2015 Extreme Networks, Inc. All rights reserved. SDN Demo Overview SDN MPLS Java App  Show IXIA –Traffic tx, –No traffic rx  Go to switches –Show OpenFlow flows & groups –None exist  Show ODL –Switches have been discovered  Run SDNMPLS.jar  Look at IXIA –Traffic rx after flows installed.  Go to switches: –Show OpenFlow flows & groups: –Flows & groups exist  Show ODL –Switch names appear. 17  MPLS Pseudo-wire support is being added to enable users to control a Pseudo-wire overlay network. The primary reference network for this would be an IXP Internet Exchange use case. The goals for this network is to use Software Defined Networking (SDN) to do the following:  Increase the Scale of a IXP Network –A flow based MPLS architecture provides more granular control than traditional solution.  Support Rapid Service Turn-Up –Using centralized SDN controller and application.  Enable New Services –Use SDN to enable full control over communications across the network.

18. ©2015 Extreme Networks, Inc. All rights reserved.