Data Center Technologists
Showing results for 
Search instead for 
Do you mean 

Why Physical Network Topology API is relevant for OpenStack

by Juniper Employee ‎05-19-2015 08:37 AM - edited ‎05-22-2015 03:45 PM

In the blog about Network-aware VM placement, we explored how Nova scheduler can leverage the physical network topology information available in Neutron. Given the distributed architecture of OpenStack, Nova should not directly access the information in the Neutron database. The most appropriate approach is to use a REST API that exposes the physical network topology.

 

Today, the Neutron REST API revolves around few key network related entities such as Network, Subnet, and Port etc. These are abstract entities and rightfully they do not directly relate to the physical network entities. In this blog, we argue about the need to have the physical network topology available as a REST API.

 

The case for an API

 

OpenStack considers compute, storage and network as the three pillars of cloud platforms. For compute, the underlying hypervisor (a physical device) information is available via Nova and even Horizon. This includes CPU capacity – available and utilized, disk space – available and utilized etc. These pieces of information are used for various purposes inside OpenStack. On the same lines it is important to leverage the physical network resources and provide rich virtual network connectivity among the virtual machines.

 

If the REST API for the physical network topology was available, Nova scheduler can access the information for better VM placement. The API approach decouples Nova and Neutron. It also provides a way for vendors to uniformly support network topology that can be leveraged by other OpenStack services.

 

The REST API Resources

 

Here is an example of a simple REST API extension for Neutron to support Physical Network topology. It recommends three resources to model the physical network:

 

  • Device: represents a physical device in the OpenStack deployment. Device could be a switch, a router or any other networking device. It could even be a server (hypervisor or bare-metal).
  • Endpoint: represents a port on the Device, in case of a switch the endpoint can be a port, in case of a server it can be a NIC.
  • Link: represents the connection between two Endpoints

 Slide3.jpg

Device

 

Device represents a physical device in the network.

 

Attribute

Type

Required

CRUD

Default Value

Validation Constraints

id

uuid-str

N/A

CR

Generated

UUID_PATTERN

device_name

String

Yes

CRU

None

N/A

device_ip

String

Yes

CR

Generated by DNS resolver

Valid IP address

device_roles

String

Yes

CR

None

List of valid roles

 

  • C - the attribute can be used in create operations;
  • R - the attribute is returned in the response for show or list operations;
  • U - the value of attribute can be updated;
  • D - the value of the attribute can be removed

Endpoint

 

An Endpoint is a port on a device; it could be a NIC on a server or a port on a switch or router.

 

Attribute

Type

Required

CRUD

Default Value

Validation Constraints

id

uuid-str

N/A

CR

Generated

UUID_PATTERN

device_id

String

No

CRU

None

UUID_PATTERN

device_port

String

No

CRU

None

N/A

 

Link

 

A Link is a connection between two Endpoints.

 

Attribute

Type

Required

CRUD

Default Value

Validation Constraints

id

uuid-str

N/A

CR

Generated

UUID_PATTERN

endpoint_a

uuid-str

No

CRU

None

UUID_PATTERN

endpoint_b

uuid-str

No

CRU

None

UUID_PATTERN

 

Uses for the Physical Network Topology API

Example 1: Network-aware VM Placement

 

In the previous blog about Network-aware VM placement, we showed that Nova required the hypervisor to switch port connectivity. The following REST API can be used by the Network Health Filter to accomplish that.

 

GET /v2.0/devices

 

Example 2: Ceilometer

 

Another service that can use the physical network topology is Ceilometer. Ceilometer supports telemetry information for virtual machines, hypervisors and virtual networks. It can leverage the physical network topology API and retrieve useful network statistics like latency, bandwidth utilization using Cloud Analytics Engine and the Network Director. This information, correlated with the virtual network information can provide advanced analytics inside OpenStack. Here is an API that could be used by Ceilometer.

 

Individual topology resources can be retrieved using as follows:

 

GET /v2.0/devices

GET /v2.0/endpoints

GET /v2.0/links

 

The road ahead

 

The REST API shown in this blog are simple examples where physical network topology can be leveraged to solve end user problems. These REST APIs will be supported in the future releases of the Neutron plugin. We are also committed to working with the OpenStack community to enhance and standardize these APIs.

 

REST API Specification

 

Creating a Device

 

Resource

Device

Rest API

POST v2.0/devices.json

Content-Type: application/json

Accept: application/json

Body

{

"device":

{

    "device_name": "sample_device",

   “device_roles”: [“role1” , “role2”]

   }

}

Response

{

  "device":

{

    "device_name": "sample_device",

   “device_ip”: “<dev.ice.ip.addr>”,

   “device_roles”: [“role1” ,”role2”],

   "id": "3a06dfc7-d239-4aad-9a57-21cd171c72e5"

}

}

 

 

Get a Device

 

Resource

Device

Rest API

GET /v2.0/devices/3a06dfc7-d239-4aad-9a57-21cd171c72e5

Accept: application/json

Response

{

  "device":

{

    "device_name": "sample_device",

   “device_ip”: “<dev.ice.ip.addr>”,

   “device_roles”: [“role1”, “role2”],

   "id": "3a06dfc7-d239-4aad-9a57-21cd171c72e5",

   “endpoints”: [“endpoint_1”, “endpoint_2”]

}

}

 

 

Creating an Endpoint

 

Resource

Endpoint

Rest API

GET /v2.0/endpoints

Content-Type: application/json

Accept: application/json

Body

{

"endpoint":

{

   "device_id": "sample_device_id",

    "device_port": “sample_device_port”

}

}

Response

{

"endpoint":

{

   “id”: “d2b620c4-f86c-11e4-9e0f-080027ce03f2”,

   "device_id": "sample_device_id",

    "device_port": “sample_device_port”

}

}

 

 

Creating a Link

 

Resource

Link

Rest API

POST v2.0/links.json

Content-Type: application/json

Accept: application/json

Body

{

"link":

{

    "endpoint_a": "sample_ep_1",

    "endpoint_b": “sample_ep_2”

}

}

Response

{

"link":

{

   “id”: “b1b27de6-f86c-11e4-b13a-080027ce03f2”,

    "endpoint_a": "sample_ep_1",

    "endpoint_b": “sample_ep_2”

}

}

Comments
by Juniper Employee
on ‎08-05-2015 11:21 AM

Chandan, very well explained article.

Keep up the good work !!!

Announcements
Juniper Networks Technical Books
About the Author
  • Anil Lohiya is a Principal Engineer in the Campus and Data Center Business unit in Juniper Networks. In his current role, he is leading some of the SDN and Network Virtualization initiatives.
  • I am an Engineer with expertise in Data Packet Forwarding, Software Design & Programming with major domain expertise in QoS (Quality of Services). I have worked across the domains in Data communications field. I love water and am a good swimmer too.
  • Remarkably organized stardust. https://google.com/+JamesKelly
  • I have been in the networking industry for over 35 years: PBXs, SNA, Muxes, ATM, routers, switches, optical - I've seen it all. Twelve years in the US, over 25 in Europe, at companies like AT&T, IBM, Bay Networks, Nortel Networks and Dimension Data. Since 2007 I have been at Juniper, focusing on solutions and services: solving business problems via products and projects. Our market is characterized by amazing technological innovations, but technology is no use if you cannot get it to work and keep it working. That is why services are so exciting: this is where the technology moves out of the glossy brochures and into the real world! Follow me on Twitter: @JoeAtJuniper For more about me, go to my LinkedIn profile: http://fr.linkedin.com/pub/joe-robertson/0/4a/34a
  • Ken Briley is Data Center TME at Juniper Networks focused on Juniper switching product lines. Prior to Juniper Networks, Ken worked at Cumulus Networks as a TME supporting the dis-aggregation movement and before that he spent 15 years at Cisco Systems working in various roles: Technical Support, Technical Marketing Engineer, Network Consulting Engineer and Product Management. Ken has an MS in Electrical Engineering and is CCIE # 9754.
  • Michael Pergament, JNCIE-SP #510, JNCIE-ENT #23, JNCIP-SEC
  • Raj is a Sr. Cloud Technology Architect with Juniper Networks and focuses on technologies such as VMware, SDN, and OpenStack etc.
  • Rakesh Dubey is the engineering head for Campus and Data Center business unit at Juniper Networks. He has been with Juniper for past six years leading multiple switching products.
  • Sarath Chandra Mekala is a staff engineer with Juniper networks and focuses on implementing Juniper's Openstack Neutron plugins in the areas of Switching, Routing, Firewall and VPN. He is an official contributor to Openstack Neutron FWaaS v2.
  • Sriram is a Sr. Manager in the Campus and Datacenter Business Unit. He is part of the Network Director team and focuses on technologies such as VMware integration, OpenStack etc.