Jump to: navigation, search

Difference between revisions of "NetworkContainers"

Line 3: Line 3:
 
* '''Created''': 2011-04-06
 
* '''Created''': 2011-04-06
 
* '''Contributors''':  
 
* '''Contributors''':  
 +
 +
<<[[TableOfContents]]()>>
  
 
== Summary ==
 
== Summary ==
Line 14: Line 16:
 
== Design ==
 
== Design ==
 
OpenStack: NaaS provides a network abstraction layer and set of APIs (Figure 1) to enable:
 
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.
  
* '''a)''' 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.
+
Figure 1<<BR>>
* '''b)''' Network Services (e.g. firewall, load balancers, Wide Area Acceleration Services) insertion at the appropriate virtual networks; and dynamically request “adaptive” network resources.
+
[[Image:NetworkContainers$figure1.png]]
* '''c)''' 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.
 
* '''d)''' Network resources that are required to interconnect OpenStack “Zones” or geographically dispersed compute/storage resources.
 
* '''e)''' Network resources required to support new Services like Virtual Private Cloud, enterprise extensions
 
* '''f)''' In future, this NaaS could be expanded to support SLA, Network level QoS and other network based auditing/monitoring services.
 
  
 
Figure 2 shows OpenStack : NaaS Logical components.
 
Figure 2 shows OpenStack : NaaS Logical components.
 +
[[Image:NetworkContainers$figure2.png]]
  
 
'''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)
 
'''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)
Line 42: Line 47:
 
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 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.
+
Figure 3
 +
[[Image:NetworkContainers$figure3.png]]
  
 
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.
 
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.
Line 49: Line 55:
  
 
Figure 4 shows the OpenStack:NaaS with “network devices” specific plug-ins and various sets of APIs.
 
Figure 4 shows the OpenStack:NaaS with “network devices” specific plug-ins and various sets of APIs.
 +
 +
Figure 4<<BR>>
 +
[[Image:NetworkContainers$figure4.png]]
  
 
NaaS APIs accessibility, in terms of authorization, will follow the same model as of OpenStack:Compute
 
NaaS APIs accessibility, in terms of authorization, will follow the same model as of OpenStack:Compute

Revision as of 02:02, 7 April 2011

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

<<TableOfContents()>>

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

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<
> File:NetworkContainers$figure1.png

Figure 2 shows OpenStack : NaaS Logical components. File:NetworkContainers$figure2.png

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 File:NetworkContainers$figure3.png

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:NaaS with “network devices” specific plug-ins and various sets of APIs.

Figure 4<
> File:NetworkContainers$figure4.png

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;

  1. A NetContainer can be defined/created based on the NC flavors assigned by the CSP(Coud ServiceProvider) to that project
  2. Attach/Create virtual networks for the Net Container
  3. Instantiate/attach Network Services at the "appropriate" Virtual network segment "nodes"
  4. Query/Monitor NetContainer health
  5. Monitoring (Stats?) 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

  1. Select Services/Types Services that a "project" would like to consume and use
  2. "Customize” the services – configure network “insertion” parameters
  3. 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

  1. 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

=== Openstack internal/Private APIs ===
  • We need to discuss if there is validity for this distinction or requirement/usecase to have a private or administrative APIs.

NaaS 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

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

Usecase 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

Usecase 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<
    >

Usecase 4: “ Network Scheduler”

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

TBD :

  • 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.