A Novel Service Modeling Framework for NFV Networking Bin Hu (AT&T), Georg Kunz (Ericsson) and Sukhdev Kapur (Juniper) May 11, 2017 / Boston, MA
Contents • New Paradigm Shift • Business Goals • What is Gluon (10,000 ft. View) • Current Implementation (3,000 ft. View) • Gluon Backend Communication • Creating a New Network API (1,000 ft. View) • Gluon Roadmap - Integration Path with Neutron
New Paradigm Shift • NFV demands change in traditional networking paradigms, and requires: • Multiple networking back-ends • Quick development and deployment of new network services APIs • Need to make new APIs agnostic of the back-ends • New networking service model on-demand
Business Goals • A Working Solution Integrated with OpenStack • Able to Use Both Neutron and New NFV Network Services Together • No impact on happy users of conventional OpenStack Networking • Our solution is : Gluon Model-Driven, Extensible Framework for NFV Networking Services
What is Gluon • 10,000 ft View bind port to VM • Gluon – a Port Arbiter that Gluon • Maintains a mapping of ports of different networking back- register port ends • Forwards port-related requests A Set of Protons to the correct back-end etcd • Proton – a set of APIs of a shim shim shim shim particular NFV Networking Service (i.e. standard NBI) Proprietary ODL ONOS Contrail SDN-C • Proton Server – an API server EVPN & MPLS/GRE that hosts multiple Protons L3VPN & MPLS/GRE • Shim – the adaptor of Proton EVPN & VxLAN to native SDN-C API
Current Gluon Implementation • 3,000 ft View Bind port to VM Nova • Gluon Core Plugin Model Neutron Server Definitions • Extended ML2 Plugin Gluon Port YAML • Port Arbiter Function Gluon Core Plugin Actions Files Core Plugin • Proton Server Backend Neutron • API Server supporting Proton Updates Port Server Actions multiple Protons • Shim Layer Server etcd L2 Agent Database Updates • Adaptation and Shim Other Configuration Server Neutron MySQL SDN • for SDN Controllers Backends Controller
Creating a New Network API (Proton) • Philosophy of separating “Design” from “Execution” • Design Time • Define the model of your API in YAML • Execution Time • Use ParticleGenerator.py to generate • REST API with validation • Database schema • Backend synchronization using etcd • A CLI application to exercise the API • Proton Server serves new Protons at runtime
Model-driven API Creation • Goals 1. Provide flexibility for creating novel networking APIs • Impose minimal set of assumptions and requirements on APIs • Basic set of data types and semantics for building hierarchical object models 2. Facilitate coexistence of multiple APIs and network services • Design paradigm for binding of multiple services to a vNIC
API Object Model • Object oriented API model BaseObject ApiObject • attribute_1 extends BaseObject • attribute_2 • attribute_4 • attribute_3 • attribute_5 • attribute_6 • • Defines set of attributes for use in Concrete API object with auto-generated • RESTful endpoints other objects • • “Abstract class” data base tables • “Concrete class”
Generated API Endpoints • Generated API Endpoints for API Objects Example: service APIObject of API example_api POST /proton/example_api/service Create service object PUT /proton/example_api/service/<service_id> Modify service object GET /proton/example_api/service Get all service objects GET /proton/example_api/service/<service_id> Get one service object DELETE /proton/example_api/service/<service_id> Delete a service object • The content type for all of the operations is *application/json*.
Model-driven API Creation • Goals 1. Provide flexibility for creating novel networking APIs • Impose minimal set of assumptions and requirements on APIs • Basic set of data types and semantics for building hierarchical object models 2. Facilitate coexistence of multiple APIs and network services • Design paradigm for binding of multiple services to a vNIC
Port and Service Binding Model • Design paradigm for binding multiple network services to a vNIC BasePort • port_id • mac_address • … 1 * BaseInterface BaseServiceBinding BaseService 1 1 1 • port_id • interface_id * • segmentation_id • service_id • …
L3VPN Model • API for BGP VPNs Port extends BasePort Interface VpnBinding VpnService extends BaseInterface extends BaseServiceBinding extends BaseService • port_id • interface_id • ipv4_targets • service_id • ipv6_targets • IP_address • route_distinguishers • subnet_prefix • gateway
Models under Development • Point-to-Point links with guaranteed bandwidth P2pService Port Interface P2pBinding extends BaseInterface extends BaseServiceBinding extends BaseService extends BasePort • protocol • port_id • interface_id • service_id • bandwidth • IETF SFC • Mapping of IETF SFC data model to Gluon • Current version of IETF SFC model in Gluon very simplified • Extension to full scale IETF SFC model required • Validate Gluon modelling approach against complex real world model
Future of Gluon • Gluon to become a service plugin in Neutron • Come, participate, and contribute • Will fully integrate with rest of neutron drivers and service plugins (networking-xxx, including newly kicked off networking-opencontrail) • Huge win for Users/Operators • Can deploy new NFV functions along with their existing neutron services without any forklift upgrades • Multiple SDN controllers, along with traditional neutron services
Gluon Integration Path with Neutron Neutron Extension APIs Core APIs Gluon APIs API Neutron Model Definitions Proton Server Other Plugins and Extensions e.g. YAML Plugins Core Plugin Proton API & Particle ML3 Plugin, Security Groups Plugin, Files LBaaS Extensions Generator etcd SDN-C SDN-C Driver Driver Networking SDN SDN Backends Controller Controller • Neutron Service Plugin for Proton & Particle Generator – to be started • Interact with backend via etcd and respective SDN-C Drivers
Future of Gluon – food for thoughts • Gluon service plugin will introduce a “generic CLI/API” • Base objects/resources owned by Gluon • Two new resources to be introduced: • Gluon-endpoint • Gluon-net-function • Proton API extends the base objects/resources by adding new NFV function specific attributes to base objects (described earlier) • One can connect/bind: • Gluon-endpoints with neutron networks/subnets – e.g. gateways • Gluon-endpoints to Gluon-endpoints – e.g. point-to-point • Gluon-endpoints to gluon-net-functions – e.g. SFC use case
Questions
Recommend
More recommend