release Nov Sep Aug Jul Jun May Mar Feb Jan’15 Dec’14 Apr Oct • Target for use cases –Cardinal release (May 2015) • But work for use cases is already in progress. Some parts get into master in Blackbird and majority in Cardinal. ONOS Use Cases Planning Session: Timelines
• Sync up on the current status and the priori[zed list of to-‐do items for each use case (targeted for Cardinal Release) • Introduce the Use Cases Steering team • Tom Anschutz, AT&T • Yoichi Sato, NTT • Introduce team leads for each use case. • Iden[fy concrete ways in which the ONOS community can par[cipate and collaborate on ONOS use cases. COMMUNITY PLANNING STEERING TEAM
of forwarding, configura[on and monitoring in mul[-‐layer networks ¡ Scale out, HA, and high performance ¡ Current status ¡ Demonstrated converged L0 and L3 bandwidth provisioning and restora[on ¡ Running on emulated network (LINC-‐OE, OVS, and Mininet) ¡ Southbound fully based on OpenFlow ¡ Missing features ¡ No real hardware ¡ No real scale
through SDN • Provide L3 functionalities using OF switches Features • 6 universities distributed around the country will communicate together through SDN • The SDN will act as a transit network • SDN-IP: the SDN and the external networks will exchange routes through BGP • SDN benefits + ONOS added values • 43 switches of different vendors
is an applica[on running on top of ONOS Features • It allows your SDN to scale and connect to the rest of the Internet • You can migrate your exis[ng network to SDN incrementally • You can scale your SDN control plane Technology • It exchanges routes peering with external edge routers (BGP – vendor independent) • HA func[onali[es (both in data plane and control plane)
stable, even if it’s always the first ONOS release • Integration automatic tests missed, but in progress • Collaboration with I2: SDN-IP (almost) deployed in the Internet2 testlab • Issues with a vendor not supporting dst_mac re-write (blocking) To be done • Understand the feasibility of the deployment • Internet2 would validate the platform before moving to the “official” deployment • Involving interested universities. Deployment on AL2S with I2 support • Performances improvements not needed for the specific deployment
Finish the deployment in the Internet2 testlab - ONOS-494 o More discussions on the feasibility of the deployment o Validation of the solution and discussion with I2 • Deploy on Internet2 AL2S - ONOS-495 o Re-build with the Internet2 staff the production testbed o Involve interested universities and support them along the deployment
we would appreciate the help of the community! • Performances tests and improvements (up to 600,000 routes) - ONOS-62 • Understand the network modeling and configuration refactoring - ONOS-642/65 • Security: explicit BGP configuration for SDN-IP - ONOS-2 • Finish the integration with IPv6 (only tests needed) - ONOS-646 • Disable LinkDiscovery on the access ports - ONOS-429 • Cancel host monitoring in SDN-IP when it not longer has routes to the next hop – ONOS-424 • Use intent replace operation instead of withdraw and submit - ONOS-430
SR Labels imposed by controller OSR FIB built by controller Rou[ng Service Requests ONOS Discovery Service Open Segment Routers (OSR) Forwarding Service Open Segment Routers (OSR) USE CASE OVERVIEW
demonstrated on a development version of ONOS as part of Dec 2014 Open source release • Dell 4810 Open Networking switches • hlps://wiki.onosproject.org/display/ONOS/Segment+Rou[ng • ONOS-‐Cardinal Release Goals • Change parts of official ONOS to accommodate SR and other apps that need OF1.3 features -‐-‐ eg. pipeline support in drivers, flow-‐rule subsystem • Introduce new features in official ONOS to accommodate SR and other apps that need such capabili[es -‐-‐ eg. group-‐subsystem & network-‐config-‐manager • Port SR applica[on onto official version of ONOS • Con[nue suppor[ng Dell 4810 switches • ONS demo in June 2015
use case in Cardinal Release • Mul[ple table support for Flow Rule subsystem (ONOS-‐682) • New Group subsystem (ONOS-‐679) • Network configura[on management framework (ONOS-‐685) • Segment Rou[ng Applica[on • Default Rou[ng Handling and Recovery (ONOS-‐686, 687) • Default Group Handling and Recovery • Policy Rou[ng support (ONOS-‐688, 689, 690) • Policy Group Handling and Recovery • CLI (ONOS-‐691) • GUI (ONOS-‐692)
-‐ Segment Rou[ng allows the crea[on of policies that fall into several categories: tunnel-‐flow, load-‐balance, avoid, deny etc. Help us make these policies beler/stronger and more feature-‐full (eg. add protec[on), or implement a new policy!! • CLI -‐ SR applica[on currently uses a CLI from a different project. We can use help to inves[gate the integra[on of that CLI with ONOS-‐Cardinal. We can also use help to explore possible changes to the Karaf CLI • GUI -‐ We need help to figure out how to expose SR features on the GUI
applica[ons – SDN – Programmable control plane – NFV – Programmable data plane • Bring all Three Together in the Central Office – Leverage cloud technology to reduce CAPEX/OPEX • e.g., virtual machines, virtual networks, elas[c scaling – Offer local value-‐add to global cloud services • e.g., CDN, Object Store, NoSQL DB, Data Analy[cs – Offer control plane based services • e.g., VPN, Traffic Engineering, Firewall, Load Balancing – Offer data plane based services • e.g., BNG, Web Access Control, CG-‐NAT, WAN Accelera[on Opportunity / Challenge
“S” deployed on a scalable set of VMs S BNG Access Subscriber … Subscriber AUTH RR HPC Internet Wide-‐Area Acquisi[on Net running on ONOS Demonstra[on Services URL Filter SDN-‐IP running as an ONOS applica[on (enterprise VPN in a similar manner) Caching Hierarchy running on ONOS Scales on private OVX-‐based VN Explicit OVX-‐based VN interconnec[on
– XOS provisions each service as a scalable set of VMs – OVX provides per-‐service VNs for scaling – ONOS applica[ons are a source of services • XOS supports arbitrary service composi[on – Expressed in terms of high-‐level specifica[on – Implies isola[on (security policy) • OVX manages VNs according to 2 orthogonal policies – Topology of the VNs associated with each service – VN interconnec[on in support of service composi[on • XOS manages VM placement according to 2 policies – Service-‐specific: to meet global demands – Site-‐specific: to op[mally u[lize Central Office resources
¡ Design and implement an east-‐west applica[on for ONOS clusters (each one made by mul[ple ONOS instances), allowing a single ISP to manage a geographically distribute control plane. ¡ Current status: ¡ ICONA (Inter Cluster Onos Network App) design done. ¡ Topology discovery done (modifica[on to the LLDP discovery to include cluster id). ¡ Messaging system between clusters, based on mul[cast Hazelcast done. ¡ Currently implemen[ng MPLS-‐based tunnels between clusters. ¡ Missing features (May release goals): ¡ Finalize the tunneling mechanism ¡ Implement the recovery mechanism to manage data-‐plane failures
¡ Descrip[on: Michele extended the ONOS Intent framework, adding the MPLS intent (currently under review -‐ hlps://jira.onosproject.org/browse/ONOS-‐631 ). Leveraging on this new Intent, we are currently sexng up the mul[ cluster tunneling mechanism. ¡ Stories: ¡ Implement the distributed mechanism to install/update/remove pseudo-‐wires (e.g. tunnels) crossing mul[ple clusters. ¡ Test the features in real environments, such as OFELIA and GEANT testbeds. ¡ Epic 2: Recovery mechanism to manage data-‐plane failures ¡ Descrip[on: we already leverage on ONOS to automa[cally redirect traffic inside a single cluster. With ICONA, we need to take care of the inter-‐clusters links and switches. To minimize the down[me, we have designed a solu[on that preinstall some backup paths. (more details if required…) ¡ Stories: ¡ Implement a two-‐stack MPLS Intent (ICONA only, not ONOS). ¡ Implement the failure detec[on and recovery in ICONA. ¡ Test the solu[on both with Mininet and real testbeds.
Helping in the design and implementa[on of the data plane recovery mechanism. ¡ Epic 1: ¡ Improving the MPLS Intent designing and implemen[ng a general purpose intent with mul[ple tags (e.g. VLAN, MPLS, GRE, …) ¡ Tes[ng of ICONA.
[email protected] ¡ maleo.gerola@create-‐net.org ¡ Michele Santuari (developer) ¡ michele.santuari@create-‐net.org ¡ Documenta[on is available offline (European project), just ask and I’ll send to you ¡ Some slides are available in the ONOS Google drive
produc[on traffic ¡ We have a deployment opportunity set up for March, to be presented at a conference on March 24/25 ¡ This deployment is to take one Corsa switch and turn it into a BGP-‐speaking IP router ¡ Corsa switch has a OF1.3 mul[-‐table pipeline that ONOS needs to work with
the specific pipeline ¡ Needs to set up sta[c flows in correct tables on switch join ¡ Needs to place dynamic flows in the correct table ¡ Introduce no[on of group in the flow API alongside selectors and treatments ¡ Modify SDN-‐IP to set up a new group when a new next hop is resolved ¡ Introduce abstract table no[on in flow API ¡ Extend flow{mod,entry} builders for groups and mul[ple tables ¡ Allow BGP packet tunnelling through OpenFlow pk[n/pktout ¡ Extend IP edge configura[on to support VLANs ¡ proxyarp needs to take VLANs into account ¡ Set up an automated integra[on testbed for this specific deployment ¡ Test & Debug on the Corsa switch
provides hierarchical network abstrac[on model, to enable easily extensible & customizable SDN deployment Applica[on A 48 Packet Transport Network PTN This research is executed under a part of a “Research and Development of Network Virtualiza[on Technology” program commissioned by the Ministry of Internal Affairs and Communica[ons.
WAN use case using ODENOS and ONOS ONOS ODENOS L0 Topo LinkLayerizer L2 Topo (Layerized) L2 Topo WDM Network Packet Transport Network OpenFlow Network ü Makes best use of ODENOS network abstracOon feature into ONOS ü Models pracOcal telecom carriers’ and service providers’ network systems 50
ONS2015 L2 Topo LinkLayerizer L0 Topo (Layerized ) L2 Topo ONOS abstrac[on model Enable applica[on developers to u[lize hierarchical network abstrac[on model on ONOS L2 To po LinkLa yerize r L0 To po (La yer ize d) L2 To po 51
(NTT Communica[ons and NEC) integrates ONOS and ODENOS to provide network abstrac[on features into ONOS. Ø Tes[ng its feasibili[es and effec[veness Open the project to discuss how to bring in the key essence of ODENOS network abstrac[on into ONOS We’re looking forward to collaborate with ON.lab and ONOS community 52 Today 26th Jan
network (SDN & Legacy) ConfiguraOon Support Following configura[ons should be possible for Mul[cast with legacy devices at the core • Mul[cast source behind SDN network, Receivers behind legacy network • Source behind legacy network, Receivers behind SDN network • Both sources and receivers behind SDN networks
& IGMP • Controller capabili[es to receive and interpret IGMP join requests from the receivers (receivers behind SDN network) • Controller capabili[es to install mul[cast flows depending on ac[ve join requests by the receivers (source behind SDN switch)
on ONOS summit 2014 2. Current Status q Huawei SNC(in-house controller) integration solution (NB/SB Agent) q PCE is implemented in App q Service Data Model (e.g. L3VPN, LB) q NB Flow Rule API Extension (Ready for Code Review) q SB Provider for Huawei Devices
and ON.LAB ONOS team on the following Stories q Service Data Installation (FlowRule Service Extension) q MPLS Label Service/Management (New) q Broadcast Network Topology Support (Topology Manager Enhancement) q Packet In/Out Service q MPLS Tunnel Priority
providers) • NB: external ML-‐PCE leverages global topology provided by ONOS for E2E op[mized TE-‐LSP computa[on by considering rich policies • Core: integra[ng ONOS distributed core for HA, global database (e.g, to accommodate TEDB/LSPDB) • SB: using the PCEP/IGP protocols for mul[-‐layer topology auto-‐discovery to support commercial IP/ Op[cal NEs • Current Status ü External ML-‐PCE implementa[on ü Internal NB/SB soeware agent ü NB API Extension ü Intent Extension ü SB Provider PCEP/IGP protocols v System Integra[on/Test for a Testbed (not finished yet) Current Status