marios log

blog

/etc

about

A look at networking in CIMI and Openstack

First off I should note that the following is not really a head-to-head comparison; that wouldn’t be fair. CIMI is still a work in progress - current version at time of writing is 1.0.0c. Similarly, the Openstack Networking API - Quantum - is still an incubator document.

Furthermore, whilst CIMI contains all the ‘bits’ of the Networking API required to (for example) put two Machines on the same subnet, Quantum is only 2/3 of the story. Quantum defines the network entities but relies on Nova (i.e. the ‘compute’ bit of Openstack) to manage the Virtual Interfaces. The current Nova API doesn’t have any notion of Virtual Interfaces or how these are to be associated with servers.

Thus the following is more of a summary of the networking entities and concepts in each API, followed by some high-level conclusions.

Openstack Quantum networking API:

The main entities are:

Network is a “virtual isolated layer-2 broadcast domain”. Networks have ports and ports have Attachments (aka ‘Virtual Interfaces’ VIFs). As I understand it, each Network represents a single logical (layer 2) network switch.
Port is a “port on a logical network switch”. Each port can have an Attachment ‘plugged into’ it (attachments are VIFs - virtual interfaces).
Attachment is a VIF - Virtual Interface. These are owned/managed by an “external service” such as Nova. Once you have a VIF, you can use it as an attachment into a port of a network.

###Network

Standard CRUD operations are offered for each of these entities. Each of the GET ops come in two flavors: ‘standard’ and ‘detail’.

For instance, a ‘standard’ GET on a specified Network (examples shamelessly copied from the Quantum API:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3

<network id="8bec1293-16bd-4568-ba75-1f58bec0b4c3" name="test_network"/>

and a ‘detail’ GET on the same Network:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/detail

<network id="8bec1293-16bd-4568-ba75-1f58bec0b4c3" name="test_network">
  <ports>
    <port id="98017ddc-efc8-4c25-a915-774b2a633855" status="DOWN"/>
    <port id="b832be00-6553-4f69-af33-acd554e36d08" status="ACTIVE">
      <attachment id="some_VIF_id"/>
    </port>
  </ports>
</network>

Networks are created by specifying only a ‘name’:

POST /tenants/foo/networks

<network name="test_create_network"/>

(the operations of adding Port(s) is actually done on the ports collection).

###Port

As with Network, the GET operation has a ‘standard’ and a ‘detail’ version. Ports have an ‘id’ and a ‘state’ - which is either DOWN or ACTIVE.

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/detail

<port id="98017ddc-efc8-4c25-a915-774b2a633855" state="DOWN">
  <attachment id="test_interface_identifier"/>
</port>

You create a port on a Network specified in the POST URL. A message body is optional for this operation - you may specify the state in which the port will be created (defaults to ‘DOWN’):

Request:

POST /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports

<port state="ACTIVE"/>

Response:

<port id="98017ddc-efc8-4c25-a915-774b2a633855"/>

Ports are deleted with a DELETE operation specifying the port and network in the DELETE URL (failing if the port has Attachments):

DELETE /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855

###Attachment

These are ‘owned’ by an external service “which uses Quantum, for instance the OpenStack Compute service, Nova”. Thus the Quantum API does not provide operations for creating or deleting Attachments; rather Quantum provides operations for plugging and unplugging an Attachment from a specified Network port.

Attach operation (I assume that the ‘test_interface_identified’ is provided by the service which created the VIF/Attachment, like Nova):

PUT /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment/

<attachment id="test_interface_identifier"/>

Detach operation:

DELETE /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment

Show Attachment in a given port:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment

<attachment id="test_interface_identifier"/>

###CIMI networking API:

The main entities are:

Network - is an “Abstraction of a layer 2 broadcast domain”. As such a Network has a number of attributes which define the operational properties of the physical Network which is being abstracted. These include a state, bandwidthLimit, trafficPriority, access (public/privately routable network), maxTrafficDelay, maxTrafficLoss, maxTrafficJitter and a routingGroup. As with Openstack Quantum, my understanding is that a Network is essentially a logical layer-2 network switch.
VSP - is a Virtual Switch Port and thus defines the “connection parameters of a network port.” The attributes of a VSP include the Network (i.e. layer-2 switch) to which the port is associated: state, network, bandwidthReservation, trafficPriority, maxTrafficDelay, maxTrafficLoss, maxTrafficJitter
RoutingGroup - is simply a “collection of Networks that route to each other”.

The link between the Network and the Compute entities of CIMI is through the CIMI Machine entity. A Machine has an array of NetworkInterfaces - each NetworkInterface includes a reference to a VSP (and other attributes such as MAC address, protocol, IP address etc).

Before looking at some of the API operations for the network entities, it is necessary to provide a little background on the creation pattern common to all CIMI entities:

Each entity has an equivalent collection which is the grouping of all instances of the given entity. So Network also has a NetworkCollection. Besides the grouping, the collection also provides the URI to which a consumer (a ‘client’ in CIMI parlance) should POST for creation of the given entity.
Each entity has a configuration which is the collection of values used in the instantiation of the given entity. Thus, a NetworkConfiguration is used to define the parameters of a to-be-created Network.
The actual creation of a given entity is achieved through an entity template. Thus, a Network is created using a NetworkTemplate, which in turn contains a NetworkConfiguration together with any other values required for the creation.

The above explains why at first sight, the number of entities defined by the CIMI API may seem overwhelming. The CIMI Primer may be a good place to start when looking at the CIMI API (DSP 2027). Using Network as an example, the CIMI API defines six related entities in total:

Network,
NetworkCollection,
NetworkConfiguration,
NetworkConfigurationCollection,
NetworkTemplate,
NetworkTemplateCollection.

Network

A Network is created using a NetworkTemplate. A NetworkTemplate contains the NetworkConfiguration and the RoutingGroup to which the created Network will belong (if any):

POST /example.com/networks

<NetworkCreate>
  <name> my_test_network </name>
  <description> A test network </description>
  <networkTemplate>
    <networkConfig>
      <access> public </access>
      <bandwidthLimit> 2 <bandwidthLimit>
      <trafficPriority> 1 </trafficPriority>
      <maxTrafficDelay> 500,000 </maxTrafficDelay>
      <maxTrafficLoss> 100 </maxTrafficLoss>
      <maxTrafficJitter> 100,000 </maxTrafficJitter>
    </networkConfig>
    <routingGroup href="http://example.com/routinggroups/group1">
  </networkTemplate>
</NetworkCreate>

Note that the above specifies the NetworkConfiguration by-value; it is possible for a client to specify this by-reference, that is, using a pre-defined NetworkConfiguration given by the cloud service provider. In such a case, the body for create operation is simplified:

<NetworkCreate>
  <name> my_test_network </name>
  <description> A test network </description>
  <networkTemplate>
    <networkConfig href="http://example.com/networkconfigs/config1"/>
    <routingGroup href="http://example.com/routinggroups/group1">
  </networkTemplate>
</NetworkCreate>

A GET on the URL of a Network will return the serialized (xml or json) format of that Network. Note that the serialization, as with all CIMI entities, will contain the ‘DELETE’ URL (i.e. the URL to be used for a DELETE operation on that entity):

GET /example.com/networks/my_test_network

<Network xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/networks/my_test_network </id>
  <name> my_test_network </name>
  <description> A test network </description>
  <created> Mar 1 12:55:02 EET 2012 </created>
  <updated> Mar 1 12:55:02 EET 2012 </updated>
  <state>STARTED</state>
  <access> public </access>
  <bandwidthLimit> 2 <bandwidthLimit>
  <trafficPriority> 1 </trafficPriority>
  <maxTrafficDelay> 500,000 </maxTrafficDelay>
  <maxTrafficLoss> 100 </maxTrafficLoss>
  <maxTrafficJitter> 100,000 </maxTrafficJitter>
  <routingGroup href="http://example.com/routinggroups/group1"/>
  <eventLog href="http://example.com/events/networks/event1"/>
  <operation rel="edit" href="http://example.com/networks/my_test_network"/>
  <operation rel="delete" href="http://example.com/networks/my_test_network"/>
</Network>

A Network is deleted using the URL for the ‘delete’ operation returned in the xml/json serialization:

DELETE /example.com/networks/my_test_network

###VSP

As with Network, the URL to be used for the VSP creation operation is provided by the VSPCollection. Similarly, a VSP is created using a VSPTemplate, which defines a VSPConfiguration. The VSPTemplate also includes a ‘network’ attribute, identifying the Network to which this VSP will be associated:

POST /example.com/vsps

<VSPCreate>
  <name> my_switchport </name>
  <description> A test switchport </description>
  <vspTemplate>
    <network href="http://example.com/networks/my_test_network"/>
    <vspConfig>
      <bandwidthReservation> 1 </bandwidthReservation>
      <trafficPriority> 2 </trafficPriority>
      <maxTrafficDelay> 500,000 </maxTrafficDelay>
      <maxTrafficLoss> 100 </maxTrafficLoss>
      <maxTrafficJitter> 100,000 </maxTrafficJitter>
    </vspConfig>
  </vspTemplate>
</VSPCreate>

Again and as with Network a VSPConfiguration may be passed by-reference rather than by-value (i.e. as shown above) simplifying the body of the create operation.

GET /example.com/vsps/my_switchport

<VSP xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/vsps/my_switchport </id>
  <name> my_switchport </name>
  <description> A test switchport </description>
  <state> STARTED </state>
  <created> Mar 1 12:56:02 EET 2012 </created>
  <updated> Mar 1 12:56:02 EET 2012 </updated>
  <network href="http://example.com/networks/my_test_network"/>
  <bandwidthReservation> 1 </bandwidthReservation>
  <trafficPriority> 2 </trafficPriority>
  <maxTrafficDelay> 500,000 </maxTrafficDelay>
  <maxTrafficLoss> 100 </maxTrafficLoss>
  <maxTrafficJitter> 100,000 </maxTrafficJitter>
  <eventLog href="http://example.com/events/vsps/event1"/>
  <operation rel="edit" href="http://example.com/vsps/my_switchport"/>
  <operation rel="delete" href="http://example.com/vsps/my_switchport"/>
</VSP>

Following the same pattern as Network (and all CIMI entities for that matter), retrieving the xml/json serialization of a VSP will also provide the DELETE URL:

DELETE /example.com/vsps/my_switchport

###RoutingGroup

Finally, as with all other CIMI entities, the URL for creation of a RoutingGroup is provided by the RoutingGroupCollection. Furthermore, creation of a RoutingGroup is achieved by specifying a RoutingGroupTemplate:

POST /example.com/routing_groups

<RoutingGroupCreate>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <routingGroupTemplate>
    <network href="http://example.com/networks/my_test_network"/>
    <network href="http://example.com/networks/my_test_network2"/>
  </routingGroupTemplate>
</RoutingGroupCreate>

Retrieving a RoutingGroup provides the DELETE and EDIT URLs:

GET /example.com/routing_groups/developer_net_group

<RoutingGroup xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/routing_groups/developer_net_group </id>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <created> Mar 1 12:57:02 EET 2012 </created>
  <updated> Mar 1 12:57:02 EET 2012 </updated>
  <network href="http://example.com/networks/my_test_network"/>
  <network href="http://example.com/networks/my_test_network2"/>
  <operation rel="edit" href="http://example.com/routing_groups/developer_net_group"/>
  <operation rel="delete" href="http://example.com/routing_groups/developer_net_group"/>
</RoutingGroup>

Using the DELETE URL returned above to Delete a Network:

DELETE /example.com/routing_groups/developer_net_group

A client may use the EDIT URL to add a new network to the RoutingGroup. In CIMI Update/Edit operations are achieved with HTTP PUT and must include the full description of the entity, together with any new/updated values. Thus, to add the new “dev_net1” Network to the RoutingGroup:

PUT /example.com/routing_groups/developer_net_group

<RoutingGroup xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/routing_groups/developer_net_group </id>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <network href="http://example.com/networks/my_test_network"/>
  <network href="http://example.com/networks/my_test_network2"/>
  <network href="http://example.com/networks/dev_net1"/>
</RoutingGroup>

###Conclusions As stated earlier, I will not attempt to judge which of the 2 APIs is ‘better’; for starters that would be entirely subjective and will depend on the use-case. Furthermore, the Quantum API is not a ‘stand-alone’ Networking API and relies on parts of Nova which are yet to be implemented (management of the VIFs/Attachments).

Both APIs have a similar concept of ‘Network’. Essentially a Network defines a logical layer-2 network switch.
A CIMI VSP is essentially a Quantum Port plus VIF/Attachment. That is, a VSP defines the operational parameters of the network port, but also serves as the connection for a given CIMI Machine (remember, a Machine has a reference to a VSP). On the other hand, a Quantum Port needs an Attachment to achieve a connection with a given Openstack Compute server.
The CIMI concept of RoutingGroup is missing from Quantum.
The CIMI Network API is undoubtedly the more complex of the two though it allows for more fine-grained control of specific Network parameters, exposing concepts such as bandwidthLimit, trafficPriority, maxTrafficDelay, maxTrafficLoss, maxTrafficJitter and routingGroup.
Equivalently, one might say that Quantum is more ‘elegant’ but is of course much simpler and affords less control over the virtualised network. It may be that Quantum will evolve before it is finalised, adding similar concepts to the CIMI network API, though this is entirely speculative.
In general, the CIMI API is an attempt at a unified interface that can be implemented and provided by cloud service providers with heterogeneous back-end infrastructure. That is, CIMI API makes no assumptions about the hardware or more simply the ‘internal workings’ of the cloud provider infrastructure (e.g. virtualisation technology being used). However, the Openstack API by definition is designed to be served as the interface to an Openstack installation. This may in part explain the (potential) perceived complexity inherent in CIMI networking.

blog comments powered by Disqus

site.xml

tripleo.xml

marios@ ~]$ /var/log

Openstack Quantum networking API:

Network