|
|
| (21 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| + | |
| | ---------- | | ---------- |
| | <span style="font-size: larger">'''This blueprint is being redrafted. [https://launchpad.net/~ewanmellor Ewan Mellor] and [https://launchpad.net/~salvatore-orlando Salvatore Orlando] will be happy to hear from you if you wish to contribute. Nothing here is committed.'''</span> | | <span style="font-size: larger">'''This blueprint is being redrafted. [https://launchpad.net/~ewanmellor Ewan Mellor] and [https://launchpad.net/~salvatore-orlando Salvatore Orlando] will be happy to hear from you if you wish to contribute. Nothing here is committed.'''</span> |
| | | | |
| | + | The content of this wiki page has been moved to http://wiki.openstack.org/NetworkService |
| | ---------- | | ---------- |
| − | * '''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 ==
| |
| − | === Use case 1: Create private network and attach instance to it ===
| |
| − | ''Related topology:'' Each tenant has an isolated network. Tenants are free to do whatever they want on their network, because it is completely isolated from those of other tenants. This is the NASA Nebula model as of today, implemented using one VLAN per tenant. Note that although this same model could equally be implemented with different technologies (e.g. GRE tunnels instead of VLANs for isolation), this would not change the nature of the model itself.
| |
| − |
| |
| − | # Customer uses the Core NaaS API to create a Network;
| |
| − | # On success, Core NaaS API return a unique identifier for the newly created network;
| |
| − | # Customer uses Core NaaS API for configuring a logical port on the network;
| |
| − | # Customer invokes Cloud Controller API to run an instance, specifying network and virtual port for it;
| |
| − | # Cloud Controller API dispatches request to compute service;
| |
| − | # Compute service creates VM and VIFs. For each VIF, it asks Naas Core to plug it into port and network specified by Customer in (4).
| |
| − |
| |
| − | === Use case 2: Attach instance to default public network ===
| |
| − | ''Related topology:'' Similar to the 'Flat' mode currently supported by nova network. Instances from different customers are all deployed on the same virtual network. In this case, the Core NaaS service can provide port isolation policy in order to ensure VM security.
| |
| − |
| |
| − | # Customer uses Core Naas API to retrieve public networks;
| |
| − | # On success, Core Naas API returns a list of unique network identifiers; Customer selects a networks from this list;
| |
| − | # Customer uses Core NaaS API for configuring a logical port on the network;
| |
| − | # Customer invokes Cloud Controller API to run an instance, specifying network and virtual port for it;
| |
| − | # Cloud Controller API dispatches request to compute service;
| |
| − | # Compute service creates VM and VIFs. For each VIF, it asks Naas Core to plug it into port and network specified by Customer in (4).
| |
| − |
| |
| − | The main difference between this use case and the previous one is that the Customer uses a pre-configured network instead of creating it. Another point that needs to be discussed is whether customers should be allowed to manage ports for public networks. Alternatively, the compute service can implicitly create a port when it contacts the Core NaaS API.
| |
| − |
| |
| − | === Use case 3: Register bridge for connecting cloud network to other site ===
| |
| − | ''Related topology: '' Customer on-premise data centre extending into the cloud, interconnecting networks in distinct cloud. Although actual implementation can be provided in several ways. we are interested in the abstract model: a single connectivity domain spanning two ore more networks in distinct administrative domains.
| |
| − |
| |
| − | # Customer uses Core NaaS API to register a bridge for its network;
| |
| − | # On success the Core NaaS API returns the bridge identifier;
| |
| − | # Customer uses Core NaaS API to provide bridge configuration (e.g.: remote endpoint, port, credentials);
| |
| − | # Customer uses Core NaaS API to create a virtual port on the network for the bridge device;
| |
| − | # Customer uses Core NaaS API to plug bridge device into network
| |
| − |
| |
| − | == Design Ideas ==
| |
| − | At this stage any attempt to provide a design for Core NaaS would be quite unrealistic. This section should be therefore regarded as a first attempt to define general design guidelines for NaaS.
| |
| − |
| |
| − | At a very high-level view Core NaaS and its interactions with other entities (compute service, nova database, plugins) can be summarized as follows:
| |
| − |
| |
| − | [[Image:NaaS-Core$NaasCore-highlevel.png]]
| |
| | | | |
| − | ----
| |
| | [[Category:Spec]] | | [[Category:Spec]] |
