Difference between revisions of "HigherLayerNetworkServices"

Revision as of 23:18, 12 April 2011

This blueprint is being redrafted. Ewan Mellor and Salvatore Orlando will be happy to hear from you if you wish to contribute. Nothing here is committed.

Please note that this blueprint is currently being updated. Its content is not currently aligned with wiki.openstack.org/NetworkService

• Launchpad Entry: NovaSpec:network-service
• Created: 24 March 2011
• Contributors: Ewan Mellor,Salvatore Orlando,Youcef Laribi

<<TableOfContents()>>

Summary

Apart from providing basic connectivity to OpenStack instances, NaaS will also provide a number of higher-level network services, such as DHCP, NAT, VPN access, and Load Balancing. This blueprint should be regarded as a generic specification for Layer-3 to Layer-7 network services; in other words, it could be regarded as a blueprint for creating blueprints for higher-layer network services.

Rationale

NaaS-Core provides an abstraction of a virtual network switch for connecting instances running in the cloud, and acts as a manager for higher-lever network services, intended as L3 to L7 services into the ISO/OSI stack. The role of NaaS-Core with regards to higher layer services is merely to register them and allow API users to enable or disable them for specific networks. Higher-layer services will use the network abstraction provided by NaaS-Core, although these services are loosely coupled with the core service.

Each higher layer service will come with its own, generic API. For instance there will be an API for configuring NAT, and an API for configuring Load Balancing. Similarly to Core NaaS, APIs are decoupled from the actual implementation of the service which will be provided by an appropriate plugin.

Among the various possible higher-layer services, IP configuration (L3 networking) probably requires a special mention, due to the fact that it is probably so important that should be part of NaaS core. This topic is discussed in the NaaS-Core wiki page.

Goals

Goal 1: Allow customers to enable or disable higher level services for their networks. Also, the service provider may charge for these services, so enabling one may be a chargeable event.

Goal 2: Given a specific higher-layer network service, allow customers to configure it using the API provided by the service itself;

Goal 3: API for higher-layer services should be based on the features available in an open-source component which should be adopted as the 'reference implementation' for the API itself (i.e.: the API should be representative of a 'maximum common denominator' of the capabilities offered by a number of implementations).

Goal 4: APIs for higher-layer services should define extensibility mechanisms in order to allow customers to use vendor-specific extensions; this will allow 3rd party implementation to offer value-added features;

Goal 5: Allow CSPs to register and configure the plugins providing the actual implementation of the service. CSPs should be able to select and plug in third-party technologies as appropriate. This may be for extended features, improved performance, or reduced complexity or cost. For example, one service provider may choose to offer their firewall service based on hardened Linux VMs, but another one may choose to use commercial firewall software instead. However, a scenario in which the customers is able to provide its own plugin might also be considered.

Goal 6: Support the network topologies already in use today (Topologies 1 and 2 below).

Topologies

Below are a number of example network topologies. For each topology you can consider two use-cases -- the customer who wishes to deploy their resources within such a topology, and the service provider who wants to allow the customer to do that.

As regards IP configuration strategy (e.g.: injection or DHCP) this is orthogonal to the topology choice; any topology may be used in combination with any address injection scheme.

Topology 1: Isolated per-tenant networks

Each tenant has an isolated network, which the tenant accesses via a VPN gateway. 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 today. This is currently implemented using one VLAN per tenant, and with one instance of nova-network per tenant to act as the VPN gateway. Note that this same model could equally be implemented with different technologies (e.g. a commercial VPN gateway, or using GRE tunnels instead of VLANs for isolation). One aim of this blueprint is to consider the model independently from the underlying implementation technology.

In this topology, NaaS will be running VPN and IP addressing services on top of the core service.

Topology 2: Firewall service

Like Topology 1, but the VPN gateway is replaced by a firewall service that can be managed by the customer through the NaaS API. The public side of the firewall would usually be connected directly to the Internet. The firewall itself is provided by the service provider.

In this topology, NaaS will be running Firewall and IP addressing services on top of the core service

Topology 3: Customer-owned gateway

Like Topologies 1 and 2, but instead of the gateway being a service provided by the cloud and managed through the Networking API, the customer instead provides their own gateway, as a virtual appliance.

The customer would have most of their VMs attached to their isolated network, but would be able to configure one (or more) of their VMs to have two interfaces, one connected to the isolated network, and one connected to the Internet. The customer would be responsible for the software within the publicly-connected VMs, and would presumably install a gateway or firewall therein.

In this topology one of the following can happen: 1 - Only NaaS core is running (or at least not higher-level service is enabled for the customer). The customer might not be using even IP addressing services; 2 - NaaS is running DHCP, Firewall, NAT and other customer-provided higher layers services on top of the core service.

Topology 4: Multi-tier applications

Like Topology 4, but rather than running a gateway or a firewall, the customer is expected to run web servers instead. These would serve content to the public interfaces, and would contact the backend tiers via the private network.

In this topology, it's very likely that there would be more than one web server with a public Internet connection and several Higher-Level services enabled on top of NaaS-Core. For instance these service can include IP addressing, Firewall, IDS, and Load Balancing

Plug-in use cases

In this section, we give examples of the technologies that a service provider may wish to plug in at various points in the infrastructure. Some of these technologies are commercial in nature. Where this is the case, the blueprint for the particular higher-layer service will include bindings for an open-source alternative, so that the NaaS API is completely supported by open-source software.

It is a goal of this blueprint that a service provider may select different implementation technologies in each category, whether that's to use a commercial technology or simply to replace one open-source technology with another.

Requirements

R1. Include a facility for allowing CSPs to register/unregister higher layer services in NaaS. This facility should not be exposed to customers, unless they are enabled to provide their own plugins;

R2. Provide a facility for allowing customers to enable or disable higher layer services for their networks;

R3. Include a facility for IPv4 address management for networks within openstack-NaaS. The way on which IP addresses are then assigned to instances running on the network will then depend on the particular IP addressing strategy.

R4. The same as R3, but for IPv6.

Note: R3 and R4 will become requirements for NaaS core if IP addressing will be part of the Core API

Also, each specific network service will have its own set of requirements. As specifications for these services are published, we will link them to this blueprint.

And, of course, lots more 'generic' requirements coming here don't worry!

Design Ideas

At this stage any attempt to provide a design for higher-level network services would be quite unrealistic. This section should be therefore regarded as a first attempt to define general design guidelines. Moreover, rather than dealing with specific higher-level services, the aim of this is to present an abstract model for a higher-layer service.

The following diagram provides an overview of how higher layer services interact with the core service and expose the API to customers:

File:HigherLayerNetworkServices$NaaS-HL-overview.png

• Each higher-layer network service exposes its own API interface; customers will use this interface in order to configure services for their networks; for instance, the configuration of the DHCP service might include an IP adress range, one or more exclusion ranges, a set of DHCP options, and a lease time;
• Higher-layer services and Core NaaS are loosely coupled. However they can access information about the network they manage using the Core NaaS API; for instance the DHCP service might need to enumerate the MACs of the VIFs attached a particular network.
• Higher-layer services are 'managed' by Core-NaaS, which registers services and plugin, and enables or disables them for specific networks; for instance a tenant might use the DHCP service for providing IP address to a network, and an IP Injection service for another network; similarly, NAT service ban enabled for a network, whereas a Firewall service can be enabled for another network;
• Just like NaaS-Core, higher layer services contain the logic for handling API requests and responses, and interacting with the nova database. Actual implementation of the service will be provided by the plugin;
• Each higher-layer service will have its own table(s) in the Nova database. There should then be a FK reference to the 'networks; table (the one managed by Core NaaS) in order to be able to associate the configuration of the service to a specific network;