NaaS-Core
- Launchpad Entry: NovaSpec:network-service
- Created: 24 March 2011
- Contributors: Ilya Alekseyev, Patrick Ancillotti, Andrey Brindeyev, Erik Carlin, Rick Clark, Dan Mihai Dumitriu, Ram Durairaj, Søren Hansen, Koji Iida, Hisaharu Ishii, Masanori Itoh, Adam Johnson, Youcef Laribi, Romain Lenglet, Brad McConnell, Eldar Nugaev, Salvatore Orlando, John Purrier, Andy Smith, Troy Toman, Dan Wendlandt, Zhixue Wu
Summary
The core functionality of Openstack Network-as-a-service (NaaS) is to provide a customer-facing service for creating and managing networks intended as "collection of virtual ports with shared connectivity".
A network created with the core NaaS API can be therefore regarded as a virtual network switch which potentially spans over all the compute nodes in the cloud. NaaS APIs should be decoupled by the actual implementation of the core service, meaning that NaaS does not mandate any specific model for created networks (e.g.: VLANs, IP tunnels).
Goals
Goal 1: Allow customers and CSPs to create networks. Networks can either be private, i.e.: available only to a specific customer, or shared. Networks shared only among a specific group of customers can also be considered.
Goal 2: Allow customers to manage virtual ports for their networks, and attach instances or other network appliances (physical or virtual) available in the cloud to them.
Goal 3: Allow customers to extend their networks from the cloud to a remote site, by attaching a bridging device within the cloud to their networks'; the bridging device would then bridge to the appropriate remote site.
Goal 4: Allow customers to configure network policies for networks, ports, and devices attached to them. Network policies can include
Goal 5: Allow CSPs to ...
Rationale
Use cases
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.