1. Multi-layer software defined networking in GÉANT
Andreas Papazois GRNET S.A. & University of Patras
TNC17
30th May 2017

2. SD-multilayer in GÉANT: overview
Layers in R&E Service Providers networks:
Service Layer
Packet Layer
Optical Transport Layer
Results are:
Complicated management and configuration
Inefficiencies in network planning (overprovisioning)
Limited, late reaction to various network events
Solution: Software Defined Networking in all these layers
Common control plane for all layers
Logically centralized
Efficient provisioning
Single point for monitoring and taking recovery actions

3. GÉANT Use Cases Multilayer approach followed in GÉANT’s use-cases
Service use cases:
SDX (Layer 2 and Layer 3)
Bandwidth on Demand
Software Defined Optical Transport Network use case:
Leveraging on the benefits of SDN also for OTL
E.g. flexibility at the data-rates, spectrum usage
Provision of optical virtual private lines
Based on Infinera’s Open Transport Switch virtual (OTSv) SDN software

4. ONOS SDN Controller
Single SDN controller for multilayer control
ONOS addresses mainly to Service Providers:
Performance, scalability, high availability
Well-designed APIs  efficient development
Robust architecture:
Mature enough to support mission critical networks
Rich in supported features and
Big and responsive community:
ONOS community has grown to include over 50 partners and collaborators
Intent framework for imposing policies (i.e. endpoint connectivity):
Intents received from NBI as requests from user-applications
Translated to flow-rules installable through SBI

5. Challenges: Optical Transport Layer
Multiple challenges since controllers are designed for packet forwarding devices
Solutions for OTL control prefer solutions other than OpenFlow:
There are extensions to OpenFlow to support OTN
OpenFlow not mature/complete enough to support management and configuration of OTSs
Preference to other alternatives: REST, Netconf
Providers expose OTN through a controller:
Hierarchy of controllers

6. OTL: control plane hierarchy
Communication to optical devices cannot be made directly
Disaggregation at the CP:
Child-controller acting as proxy
Provides topology information
Fulfills requests for services provisioning
Pushes notifications to parent-controller
Common practice: SDN controllers expect to have devices at their SBI

7. Achievements @SBI Development of OTSv driver:
Retrieving topology information
Managing provisioned services
Development of “Domain Topology Provider”:
Communicates with child-controller
Provides transparently sub-topology information
Allows parent-controller to communicate in a “virtually” direct manner to the devices
Abstractions used are not impacted by the existence of sub-controller

8. Achievements @SBI Development of OTSv driver:
Retrieving topology information
Managing provisioned services
Development of “Domain Topology Provider”:
Communicates with child-controller
Provides transparently sub-topology information
Allows parent-controller to communicate in a “virtually” direct manner to the devices
Abstractions used are not impacted by the existence of sub-controller

9. Achievements @Intent f/w and NBI
Idea first developed at ONOS Build 11/2016 (3rd prize):
4 engineers from 3 projects (GÉANT, ACINO, ICONA)
4+1 organizations (CREATE-NET, ADVA Optical Networking, GRNET, Politecnico di Torino, and ON.Lab)
Problem: ONOS translates Intents to instructions on a per-device basis
Solution: introduction of “Domain Intent” concept
Policies are not translated for domains:
They are transferred to child-controller
Child-controller is responsible to compile  install  report status
Multiple applications:
Optical child-controllers
Control of different administrative domains
Control plane disaggregation
Inclusion of “Domain Intent” solution in the fundamental objectives of ONOS Northbound Brigade

10. “Domain Intent” solution: example
Request for connectivity intent received from NB application
Parent-controller computes path for intent
Parent-controller compiles connectivity intent into installable intents, e.g., flow-rules and domain intents
4a. Flow-rules are communicated to devices
4b. Domain intents are communicated to child-controllers
Child-controllers handle domain intent independently
Devices and controller report the installation result 1 4a 2 9 4a 4a 3 4b 4b

11. Achievements: L2 Bandwidth on Demand service:
Support of NSI CS multi-domain protocol for SD- networks
Advanced Path Computation Element in SDN controller
Layer 2 Software Defined Internet Exchange Point (SDX-L2)
Definition of virtual SDX and assign endpoints (physical interfaces or VLANs)
Provision of multi-domain Ethernet Circuits between endpoints

12. Achievements: L3
Layer 3 Software Defined Internet Exchange Point (SDX-L3)
Based on ONOS SDN-IP use case
Traffic exchange between SPs’ Autonomous Systems
SDN network acting as Route Server:
Route Server: exchanges BGP information with participating peers
SDN fabric: forwards traffic based on known routing information (no router intervention)
Major challenge  scalability issues due to huge number of Internet routes:
Intent/flow-rules compression is necessary
Hard to implement for general purpose SDN controllers

13. SD-Multilayer in GÉANT Pilots
Pilot phase has just started
Plans for multilayer pilots:
Combining L2 use cases with SD-Optical Transport
E.g. BoD with SD-OTN

14. and participating NRENs
Collaborations
and participating NRENs