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

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

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

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

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

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

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

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

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

“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

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

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

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

and participating NRENs Collaborations and participating NRENs

andreas.papazois@gmail.com