Difference between revisions of "HigherLayerNetworkServices"

Revision as of 21:51, 16 February 2013

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
• Last updated: 13 April 2011
• Contributors: Ewan Mellor,Salvatore Orlando,Youcef Laribi

<<TableOfContents()>>

Summary

Apart from the basic L2/L3 connectivity provided by NaaS, VM instances in openstack can also benefit from high-level network services, such as DHCP, NAT, VPN access, and Load Balancing. This blueprint does not regard any specific network service, nor it aims at specifying a single service which should provide all these services. It should instead be regarded as a generic specification for any L4/L7 network service; in other words, it is a blueprint for creating blueprints for higher-layer network services.

Rationale

NaaS provides an abstraction of a virtual network switch for connecting instances running in the cloud; L4 to L7 services will use this network abstraction; however they interact with NaaS through its API only. 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 NaaS, APIs are decoupled from the actual implementation of the service which will be provided by an appropriate plugin.

KEEPING TRACK OF WHICH HIGH LEVEL SERVICES ARE ENABLED

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.

For this topology, a VPN service should be together with NaaS.

Topology 2: Firewall service

Similar to Topology 1, but the VPN gateway is replaced by a firewall service. 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, a Firewall service should be running alongside NaaS

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.

Customer would have most of their VMs attached to their isolated networks, but would also 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 is running, the customer might not even be using L3 services provided by NaaS; 2 - Customer-provided network services, for instance DHCP, Firewall, and NAT are running alongside NaaS.

Topology 4: Multi-tier applications

Like Topology 3, 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. For instance these service can include 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 API for high-level network services are 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 network services. 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;

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:

• Each service exposes its own API interface; customers will use this interface in order to configure them for their networks;
• Higher-layer services and NaaS are loosely coupled. However they can access information about the network they manage using the NaaS API;
• There is a manager component, whose task is to enable or disable services for specific networks; for instance a tenant might use a NAT service for a network, whereas a Firewall service can be enabled for another network; this manager component could either be part of the NaaS space or run within the cloud controller;
• Just like NaaS, higher layer services contain the logic for handling API requests and responses, and interacting with their database. Actual implementation of the service will be provided by the plugin.