Difference between revisions of "NaaS-Core"
| Line 2: | Line 2: | ||
* '''Launchpad Entry''': [[NovaSpec]]:network-service | * '''Launchpad Entry''': [[NovaSpec]]:network-service | ||
* '''Created''': 24 March 2011 | * '''Created''': 24 March 2011 | ||
| − | * '''Contributors''': | + | * '''Contributors''': TBD |
== Summary == | == 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". | 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 | + | == Rationale == |
| − | NaaS APIs should be decoupled by the actual implementation of the core service, | + | |
| + | A network created with the core NaaS API can be 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, which should be provided by a plugin implementing the core Naas API. | ||
| + | This implies that NaaS does not mandate any specific model for created networks (e.g.: VLANs, IP tunnels). | ||
| + | |||
| + | The core NaaS service can also be regarded as a container for higher level services, for instance DHCP and NAT. Higher level services will come their own API and implementation and they are discussed in detail here. | ||
| + | The role of the core NaaS service w.r.t. higher level services is merely to register and associate them with networks. | ||
== Goals == | == Goals == | ||
| Line 18: | Line 25: | ||
'''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 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. | + | '''Goal 4''': Allow customers to configure network policies for networks, ports, and devices attached to them. These policies can include, for instance, port security polices, access control lists, or QoS policies (which are typically available on physical network switches). Since a 'minimum set' of policies supported by each possible plugin can hardly be identified, network policies should be assumed as plugin-specific and always be configured through API extension mechanisms. |
| − | '''Goal 5''': Allow CSPs to ... | + | '''Goal 5''': Allow CSPs to register and configure the plugin providing the actual implementation of the core service, as well as register and configure plugins for higher-level services such as DHCP, Firewall or Load Balancing. |
| + | |||
| + | '''Goal 6''': Allow customers to enable or disable higher level services for their networks, using the plugins provided by the CSP. However, a scenario in which the customers provides its own plugin should also be considered. | ||
| − | |||
== Use cases == | == Use cases == | ||
| + | |||
== Assumptions == | == Assumptions == | ||
== Design == | == Design == | ||
Revision as of 14:47, 24 March 2011
- Launchpad Entry: NovaSpec:network-service
- Created: 24 March 2011
- Contributors: TBD
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".
Rationale
A network created with the core NaaS API can be 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, which should be provided by a plugin implementing the core Naas API. This implies that NaaS does not mandate any specific model for created networks (e.g.: VLANs, IP tunnels).
The core NaaS service can also be regarded as a container for higher level services, for instance DHCP and NAT. Higher level services will come their own API and implementation and they are discussed in detail here. The role of the core NaaS service w.r.t. higher level services is merely to register and associate them with networks.
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. These policies can include, for instance, port security polices, access control lists, or QoS policies (which are typically available on physical network switches). Since a 'minimum set' of policies supported by each possible plugin can hardly be identified, network policies should be assumed as plugin-specific and always be configured through API extension mechanisms.
Goal 5: Allow CSPs to register and configure the plugin providing the actual implementation of the core service, as well as register and configure plugins for higher-level services such as DHCP, Firewall or Load Balancing.
Goal 6: Allow customers to enable or disable higher level services for their networks, using the plugins provided by the CSP. However, a scenario in which the customers provides its own plugin should also be considered.
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.
