Open stack gluon + opnfv netready
•Download as PPTX, PDF•
0 likes•490 views
OpenStack Gluon is a model-driven, extensible framework that enables telecom network operators to provide customers with NFV networking services on-demand by generating APIs from a YAML file which models the NFV Networking Service. We’ll give an overview of Gluon and share a demonstration that will show how Gluon enables quick development and accelerates deployment of new networking service APIs (a.k.a. Protons). We’ll also provide an overview of the OPNFV NetReady project, whose goal is to investigate how the current OpenStack networking architecture needs to be evolved in order to ensure that NFV-related use cases can be flexibly and efficiently supported.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Open stack gluon + opnfv netready
Similar to Open stack gluon + opnfv netready (20)
More from OPNFV
More from OPNFV (15)
Recently uploaded
Recently uploaded (20)
Open stack gluon + opnfv netready
- 1. OpenStack Gluon and OPNFV NetReady Bin Hu (AT&T) and Georg Kunz (Ericsson) May 8, 2017 / Boston, MA
- 2. New Paradigm Shift • NFV brings new networking use cases • NFV brings multiple networking back-ends in OpenStack • NFV needs quick development and deployment of new APIs • Need to make new APIs agnostic of the back-ends • NFV brings new networking service model on-demand
- 3. What is Gluon • 10,000 ft View • Gluon – a Port Arbiter that • Maintains a mapping of ports of different networking back- ends • Forwards port-related requests to the correct back-end • Proton – a set of APIs of a particular NFV Networking Service (i.e. standard NBI) • Proton Server – an API server that hosts multiple Protons • Shim – the adaptor of Proton to native SDN-C API Gluon A Set of Protons ODL Proprietary SDN-C register port bind port to VM ONOS Contrail EVPN & MPLS/GRE L3VPN & MPLS/GRE EVPN & VxLAN etcd shim shim shim shim
- 4. Current Gluon Implementation • 3,000 ft View • Gluon Core Plugin • Extended ML2 Plugin • Port Arbiter Function • Proton Server • API Server supporting multiple Protons • Shim Layer Server • Adaptation and Configuration • for SDN Controllers Neutron Server Nova Proton Server SDN Controller Contrail Mechanism Driver Bind port to VM Shim Server etcd Gluon Core Plugin Core Plugin Neutron Port Actions Gluon Port Actions YAML Files Model Definitions Backend Updates MySQL Database Updates Contrail
- 5. Creating a New Network API (Proton) • Philosophy of separating “Design” from “Execution” • Consistent with ECOMP • 1,000 ft View • Design Time: • Define the model of your API in YAML • Use ParticleGenerator.py to generate • REST API with validation • Database Processing • Table Schemas with Migration • Backend synchronization using etcd • A CLI application to exercise the API • Execution Time: • Gluon and Proton Server serves new Protons at runtime
- 6. OPNFV NetReady • Investigate and evolve OpenStack networking to support NFV use cases • Approach • identify NFV use case and collect requirements from them • perform a gap analysis • propose architectural solutions • and evaluate them
- 7. Work items during Colorado cycle • Collection of NFV use cases • L3VPN • Any-to-any connectivity • ECMP load spreading • Hub-and-spoke • Programmable provisioning of provider networks • Service binding model • Backlog of use cases managed in Jira • Gap analysis with respect to Neutron • Documentation of analysis and the gaps
- 8. Use Case: L3VPN Hub and Spoke vFW VNF1 VNF2 VNF3 host 1 host 2 VRF – Hub I-RT – HUB I-RT – SPOKE E-RT – HUB 10.1.1.5 10.3.7.9 10.3.7.1010.1.1.6 VRF – Spoke I-RT – HUB E-RT – SPOKE VRF – Spoke I-RT – HUB E-RT – SPOKE VRF – Spoke I-RT – HUB E-RT – SPOKE
- 9. Use Case: L3VPN Hub and Spoke Workflow in currently available solution • Neutron + BGPVPN extension • Network association: Create a VRF per network Create one network for each VRF Identified Gaps • Creation of one network per VRF is a work- around • Circumvent current Neutron L2 • Limited scalability • Port-association needed • Creation of a VRF per port • Design in BGPVPN project work ongoing vFW VNF1 VNF2 VNF3 host 1 host 2 VRF – Hub I-RT – HUB I-RT – SPOKE E-RT – HUB 10.1.1.5 10.3.7.9 10.3.7.1010.1.1.6 VRF – Spoke I-RT – HUB E-RT – SPOKE VRF – Spoke I-RT – HUB E-RT – SPOKE VRF – Spoke I-RT – HUB E-RT – SPOKE
- 10. Contributions to upstream Gluon • Service Binding Model • Pattern for binding multiple services to a vNIC Port ServiceInterface ServiceBinding 1 n n 1 11
- 11. Gluon Integration in OPNFV during Danube • Gluon Scenario os-odl-gluon-noha • OpenStack + Gluon + Gluon Shim + L3VPN model + OpenDaylight • Based on L3VPN functionality provided by SDNVPN project • Integrated into Apex installer • Functest Test Case • Verify connectivity between two VMs in a L3VPN • Configure L3VPN through API exposed by L3VPN proton • Boot two VMs with Gluon ports associated to L3VPN • Send pings between both VMs to verify connectivity
- 12. Euphrates Release Work Items • Release planning items for Euphrates • Integration of Gluon scenario with XCI • Maintenance of existing Apex scenario • Migration to OpenStack Ocata + OpenDaylight Carbon • Integration of additional test cases • Tests of API generation based on different models • Evaluation and adaption of tests of SDNVPN project for L3VPN model • Continuation of the requirements and gap analysis
- 13. References • OPNFV NetReady project wiki • https://wiki.opnfv.org/display/netready • Gluon project wiki • https://wiki.openstack.org/wiki/Gluon
Editor's Notes
- For Enterprise, SaaS or Public Cloud, networking typically is not the bottleneck, stability and interoperability is the key so we need to be very careful of changes to APIs. For ISP and telco SPs, use cases are typically high throughput and traffic is typically pass-through instead of being terminated. Stability and interoperability is important, but rapid development and deployment is the key to business success. We know we need more networking APIs than we have today. We know that the APIs we have today is a good start, but not the end. But we don’t know what we don’t know. So we have to be open to new ideas of new APIs.