NEMO Language

Team

Overview

NEMO language is a domain specific language (DSL) based on abstraction of network models and conclusion of operation patterns. It provides NBI fashion in the form of language. Instead of tons of abstruse APIs, with limited number of key words and expressions, NEMO language enables network users/applications to describe their demands for network resources, services and logical operations in an intuitive way.  And finally the NEMO language description can be explained and executed by a language engine.

NEMO has the following features:

• User/application centric abstraction: To simply the operation, applications or users can use NEMO directly to describe their requirements for the network without taking care of the implementation. All the parameters without user concern will be concealed by the NBI.
• Consistent NBI model and pattern: While existing NBIs are proposed by use cases (e.g. virtual network, QoS, traffic engineering, service chaining), NEMO with consistent model and pattern is promising as easier to use and to extend for future proof applications.
• Intuitive to use: The expression of NEMO is human-friendly and can be easily understood by network developers. Using a language style NBI is more like the application talks to the network. Another advantage to use language is that its flexibility for northbound application developer.
• Platform independent: With NEMO, the application or user can describe network demands in a generic way, so that any platform or system can get the identical knowledge and consequently execute to the same result. Any low-level and device/vendor specific configurations and dependencies can be avoided. Any technology related network solution can be concealed.

NEMO Model

In order that the SDN controller can understand the intent requests, formalize models are required for intent expression. Let’s firstly conclude the intent expression from our real life. There will be two expression patterns:

• The Operation expression, expresses what I want to do.
• The Result expression, expresses the expected final state.

We can also find the following network domain intents:

• I want to CREATE a Network for HR (Customer Facing Node)
• I want to BLOCK the http flow (Flow)
• I want to ADJUST the bandwidth (Connection) to 10G  
• I want to AVOID the bandwidth utilization on the connection greater than 80%. (Result)

We can generate the following OOR (Object-Operation-Result) model for the intent expression according to above network examples.

There are two patterns for intent expression: the Object+Operation and the Object+Result. On the network service layer:

• Object, includes: Customer Facing Node (CFN), Connection, and Service Flow.
• Operation, describes the expected behavior. It can be generally formalized with “on condition, do action, with the constraint”.
• Result, describes the expected state. We can use the clause “expect to achieve the state” or “avoid the state”.

Implementation Framework

To impellent this feature in ONOS, we need to develop two modules.

One is the NEMO editor in Eclipse. It can implemented as an external application. It will provide functions like syntax check, and auto complete. It also encapsulates the NEMO script into the REST API.

The other one is NEMO language engine. It will be a new internal application in ONOS platform. It parses the NEMO script and interacts with the ONOS core, and call the core APIs to execute network control.

Hybrid Cloud Example

This is an example of using NEMO language to create a hybrid cloud.

The user wants to create DMZ and interior in the vDC. On one hand, they want to access the internet. On the other hand, they want to connect to the existing enterprise site. And they want to enable the BoD capability on the connection between the interior and the existing site, so that the bandwidth can augment at night for backup traffic.

• We can use NEMO language to capture this intent.
• We import the enterprise site information
• Import the internet access information
• And we create the DMZ and the interior
• Then we generate connections among all the nodes
• Finally, we apply operations on the connections