Difference between revisions of "NetworkContainers"

Latest revision as of 23:31, 17 February 2013

• Launchpad Entry: NovaSpec:netcontainers
• Created: 2011-04-06
• Contributors:

Summary

Cisco’s Proposal on OpenStack:Network as a Service (NaaS)

We are proposing OpenStack:Network as a Service, a first class OpenStack service. Though we share the requirements and many of the design concepts/principles with the other NetworkService proposal (many of the contributors are participants in both proposals), the main motivation for this blueprint is to provide OpenStack community a preview of the overall proposal and some of the new ideas, concepts for the OpenStack: NaaS consideration. This proposal also extends the NetworkService requirements specified in its draft.

Release Note

TBD

Design

Overview

OpenStack: NaaS provides a network abstraction layer and set of APIs (Figure 1) to enable: * Requesting and acquiring network connectivity by OpenStack:Compute for interconnecting two VM instances , both single virtual network (single vnic) or multi vnics to different virtual networks.<
> * Network Services (e.g. firewall, load balancers, Wide Area Acceleration Services) insertion at the appropriate virtual networks; and dynamically request “adaptive” network resources.<
> * Any OpenStack applications or services that needs Network resources visibility or consumption, examples: DR applications, Network Health / Monitoring Services, Chargeback / Billing services and so on.<
> * Network resources that are required to interconnect OpenStack “Zones” or geographically dispersed compute/storage resources.<
> * Network resources required to support new Services like Virtual Private Cloud, enterprise extensions.<
> * In future, this NaaS could be expanded to support SLA, Network level QoS and other network based auditing/monitoring services.<
>

Figure 1<
>

Figure 2 shows OpenStack:Network Logical components.

Virtual Networks

Today’s nova:network supports three “network models” (a)FlatNetwork (b)FlatNetworkwithDHCP (c) VLAN with VPN GW instance. The shortcomings of this model are well documented in other proposals and it’s rather restrictive. In this new Naas model, the Network Abstraction completely hides the technology used for achieving the network segmentation, example: Initially this may be achieved by VLAN tags, in future different vendors may employ their proprietary/ future standards based segmentation schemes, to provide scalability and flexibility. With that in mind, the Virtual networks are primarily L2 segments (with L3 services offered in future). This simplifies the network segment notion for all the other !Openstack services and hides the “platform specific” complexity to the network devices.(both physical and virtual form factors)

=== NetContainer(NC) === A logical entity that is initially created per OpenStack "Project". Each NetContainer contains one or more virtual network segments, with one or more network services and in the future may have one or more NetContainers embedded.

NetContainers can be instantiated based on already defined NC flavors or from ground up.

NC Flavors

NC Flavors provides a Cloud Service Provider opportunity to “package” its offerings,

• based on Qos , Examples: Gold, Silver or Bronze<
  > * Flavors that specify application/service specific NC falvors, example: HIPPA complaint Network<
  > * simple Network resources based definition for a particular tenant or a Project, example: how many virtual networks that the Project’s user allowed to create, Max VMs, type of services supported, ...<
  >

NC Flavors are envisioned similar to the VM flavors like m1.tiny, m1.large and so on. There will be default basic NC flavors that can be further modified for a particular project requirement.

NC Plugins:Plug-ins are Network device/vendor specific “wrappers” that are invoked for configuring required network resources at the physical/virtual switches and services.

Figure 3 shows a hierarchical model of NaaS and its layers. Though the NetContainers can be requested and instantiated from already defined and available NC Flavors, NaaS will also provide direct NaaS APIs to request the NC with fine grained parameters, to provide flexibility.

Figure 3

In the above diagram a logical representation of network segments shown. A cloud Service provider, P1 with a tenant T1, creating a project Pr1, that hosts Application A1 with three virtual networks AT1, AT2 and AT3.

All NetContainers should be instantiated based on a NC flavor. Some flavors will support modification beyond the initial configuration, and some will be locked into the fairly rigid configurations that are initially instantiated. This would depend on the plugin’s capabilities, and gives a lot of flexibility to the plugin implementer. Those that provide more flexible containers will have an advantage, but it won’t preclude those that are more basic from being useful.

Figure 4 shows the OpenStack:Network with “network devices” specific plug-ins and various sets of APIs.

Figure 4<
>

NaaS APIs accessibility, in terms of authorization, will follow the same model as of OpenStack:Compute

API Set 1: NC APIs

These APIs provide the ability to create and "manage" NetContainers for a project; * A NetContainer can be defined/created based on the NC flavors assigned by the CSP(Coud ServiceProvider) to that project * Attach/Create virtual networks for the Net Container * Instantiate/attach Network Services at the "appropriate" Virtual network segment "nodes" * Query/Monitor NetContainer health * Monitoring in future

API Set 2: Network Services APIs

These are sub-set of APIs that enable us to define services insertion and "bootstrap" parameters for the services.

"Configuring/managing” the services itself is out of scope of this API set. "Configuring/Managing" of each service is vendor specific and its challenging to align them all under one model. Moreover each of the services may have their own SDK and different deployment model to support which is very complex to have it all under this set. However, OpenStack should provide a “generic” Network services configuration for well known services such as Firewall , Load balancer.

Using this API, a tenant can

• Select Services/Types Services that a "project" would like to consume and use<
  > * "Customize” the services – configure network “insertion” parameters<
  > * List/identify the services consumed and health<
  >

API Set 3: NC Flavors API

This set of APIs primarily used by CSP for defining "resources"/services offering buckets related to Network & Network Services. Open For discussion : how much of these APIs are opened up further for a Project/tenant for customizing the “flavors”.

Example of a flavor : Three tier App with Private, Public Virtual Networks with FW and LB services, VPN GW attached,

Using this API set, CSP/Tenant can: * Create/Manage templates for a project and services offering.<
>

In the next section we discuss, how two main layers, NaaS:Core and Naas:Plugins, interact and their respective responsibilities

Components responsibilities

NaaS:Core

Hold references to NetContainer instances

• Provides API for container provisioning <
  > * Exposes catalog of available NetContainers and their attributes <
  > * Allows for operational/runtime control of NetContainers <
  > * Discussion point: Map compute/storage to container? Or does Compute service manage that?
• Choice 1: NaaS owns connections, thus compute registers VMs with NaaS using params
• Choice 2: NaaS advertises container to compute, and compute manages connections

NaaS:Plug-ins

• Owns what offerings are available (what containers are available)<
  > * Owns mapping container to Network Devices environment (example : Network segment schemes – VLAN IDs, QinQ and so on)<
  > * Owns container provisioning, including resource allocation, location, services, etc<
  > * Support standard but extensible formats for !netcontainer type definitions and !netcontainer instance requests<
  > * Standard way of reporting errors, such as missing information, unknown element, invalid config, etc<
  > * APIs for querying actual availability of specific container types (knows what resources are available, and which are consumed)<
  > * Handles asynchronous conversation with NaaS :Core

Use Cases

Use case 1: Create a Network resource for an Openstack project

Workflow for provisioning a container:

• Customer selects !netcontainer service from NaaS offering,if any<
  > * Customer provides required parameters to specify config preferences, policies, etc<
  > * NaaS creates request document from customer information<
  > * NaaS passes request document to plug-in<
  > * Plug-in parses document and maps to resource requirements<
  > * Plug-in evaluates resource req's against available resources<
  > * Plug-in provisions resources as defined by container request<
  > * Plug-in returns handle to new container (REST URL)<
  >

Use case 2: Network Services request network resources

• Insertion of a firewall requests another internal virtual network and external network segment

Use case 3: Virtual Private Cloud/Enterprise Extensions

• Create a virtual network in a NC<
  > * Create a VPN/Acceleration service instance and attach to the “private” network segment<
  >

Use case 4: Network Scheduler

• To support multiple !Openstack:Compute Zones and schedule network resources in conjunction with nova-scheduler.

API Definitions

This set of APIs allow Openstack services and "Applications" to request for Network Containers, Delete Network containers, modify Network containers (NC) attributes, List all the available NC flavors and create new NC flavors. These APIs are consumed programmatically by Openstack compute or other services.

API definitions and data model will try and follow the Openstack:Compute API 1.1 as specified at http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf

JSON is the default data serialization for OpenStack:Network APIs.

Authentication:

OpenStack: Network APIs will follow the same authentication model as that of OpenStack:Compute and may support multiple authentication schemes (OAuth, Basic Auth, Token) and so on.

Key Concepts:

Tenants: This may be mapped to a project or a org based on the NaaS API invoking system. It’s a unique name/label that identifies the NC ownership. Tenant could be mapped to a Project in Openstack:compute service invocation. The tenant construct could be used in future by “Data Services” to create a Network container for storage related services. This also makes it future proof from changes that may happen at OpenStack:compute and other consumer apps/services, example: OpenStack: Computer evolving from projects to ORG/vDC/vApp kind of constructs.

Flavor: Container definitions in terms - network resources properties. Example : # of Virtual Networks, Network Services attached, Zone affinity in future.

Summary of APIs ( work in progress)

Tenant Operations:

example: Create Tenant

POST {APP-URI}/config/tenant/create

Request Body

<tenant>
  <name>TenantABC1</name>
  <description>Optional description here</description>
</tenant>

Response Codes:

• 201 Created – Tenant has been created. Location header gives URL of created tenant. <
  >400 Bad Request – Something was wrong with the request, such as missing data
• 404 Not Found – Domain specified by domainId was not found.
• 409 Conflict – Name conflicts with existing tenant

NC Flavor Operations

NetContainer Operations

Network Services attachement

Open Questions

• NetContainers Definitions – How is it related to OVF netspec. How much we can overlap and make use of the OVF spec?<
  > * How do we resolve "dependency" while instantiating the NC or deleting it?<
  > * Explicit supported Services Enumeration?<
  > * How about supporting models like Security groups? Flexibility<
  >

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.