The document discusses using software defined networking (SDN) and open application programming interfaces (APIs) to automate network operations. It provides examples of using IFTTT-style conditional statements to trigger network actions like prioritizing Skype calls or redirecting vulnerable devices. The SDN controller OpenDaylight is examined, along with its northbound and southbound APIs. Service abstraction layers like MD-SAL and AD-SAL are compared for interfacing with network elements and applications. Case studies demonstrate provisioning MPLS networks on-demand and using SDN for Skype call quality of service.

1. ©2015 Extreme Networks, Inc. All rights reserved.
EMEA & LATAM PARTNER CONFERENCE
Lisbon | October 2014
The Power of The Open Standards API’s
Mikael Holmberg
Senior Global Consulting Engineer
mikael@extremenetworks.com
September 2015

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 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
If I’m within 500m from
home, then open the
garage door, set the heat
to 20C and turn on the
kitchen light

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

4. ©2015 Extreme Networks, Inc. All rights reserved.
DNS/DHCP
SDN
AAA
Topology
Services
Firewall
Skype for
Business
Analytics
SIEM SIP/Voice Services
Business
Applications
Location
Services
VPN

5. ©2015 Extreme Networks, Inc. All rights reserved.
DNS/DHCP
SDN
AAA
Topology
Services
Firewall
Skype for
Business
Analytics
SIEM SIP/Voice Services
Business
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 network demand from
business applications is
high then rate limit any
Netflix traffic
If a device is found
with a vulnerability
then automatically
redirect traffic to
remediation server.

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
B
SAL
Karaf
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/
Server
Stateless
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 (RPC) and notification routing
§ Data Storage
§ Request routing
§ Service Adaption

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
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
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 at Euro IX Forum
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.
Skype for Business with an Open SDN Platform
18
Skype for Business with an Open SDN Platform
§ Leverages Extreme Networks Open Daylight Controller
‘OneController’
§ Support for OpenFlow, OVSDB and other protocols
§ Delivers QoS Prioritization across mixed infrastructures
§ Frees customers from proprietary lock-in
§ SDN solution designed for broaden market applicability

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