NeMo

An Application’s Interface to

Intent Based Networks

                    Contact the NeMo Team

What’s NeMo – A Network Modeling Language?

 

NeMo is a transaction based North Bound (NB) API which allows applications to use intent-based policy to create virtual networks comprised of nodes with policy-controlled flows. Intent based policy is prescriptive (“go to the store”) rather than descriptive (“follow this route to the store”) leaving the details to the network.  NeMo’s NB API connects the application to a controller and operates using 10 commands which include: 4 basic network commands (Node, Link, Flow, Policy) and 6 basic controller communication commands (connect, disconnect, transact, commit, notification, query).  NeMo sends these 10 commands via the REST protocol when exchanging commands with the controller. 

Why NeMo?

 

Software Defined Networking (SDN) and Network Function Virtualization (NFV) are moving the IT world from a network-centric view to an application view.  Google considers the datacenter to be comprised of compute devices, storage devices, and networks. Applications running on the Google Cloud must be rewritten to run within this Cloud environment that takes care of placing applications on compute devices that have the appropriate amount of storage and network connections. NeMo provides a simple NB API which gives the application the power to setup and take down virtual networks between virtual nodes.  

 

Controllers

 

Applications

 

Mini-net

 

 

IETF 93

·         Meeting Name: IBNemo

·         Assigned Room: Tyrolka

·         Assigned Date: 07/20/2015

·         Assigned Start Time: 13:00:00

·         Assigned End Time: 15:00:00

Frequently Asked Questions

Q1: There are many industry forums working on an Intent-based policy  interface for applications.  Why should the IETF form a Working Group  to examine an Intent-Based language?

Q2: Can Intent North Bound Interfaces (NBIs) control more than networks?

Q3: Why a minimal size language?  How will you control all of the network management devices that control the network?

Q4: Is it time for IETF standardization?

Q5: What data models will IB-Nemo focus on?

Further Information

Introduction

·         Introduction to Nemo

·         draft-hares-ibnemo-overview-01 (txt)

Presentations

·         NeMo NFV Presentation Slides for IEFT 91

·         NeMo SDN Presentation Slides for IETF 91

·         NeMo Presentation at HP Summit on Intent Based Networking

·         NeMo Demo 1 (Flash)

·         NeMo Demo 2 (Flash)

·         ONS 2015 ONF Marketing Opportunity

Related Projects

·         OPNFV NeMo Project

·         Open Daylight NeMo Project

References

·         NeMo Language Technical Reference Manual

·         NeMo Compared with Yang and Open Daylight Group Policy

·         draft-xia-sdnrg-nemo-language-02.pdf

·         draft-xia-sdnrg-service-description-language-02.pdf

·         draft-xia-ibnemo-icim-00.pdf

·         draft-zhou-netmod-intent-nemo-00.pdf

The NeMo Team

·         Wayne (Wei) Cao wayne.caowei@huawei.com

·         Tianran Zhou         zhoutianran@huawei.com

·         Sheng Jiang            jiangsheng@huawei.com

·         Yinben Xiao           xiayinben@huawei.com

·         Susan Hares           shares@ndzh.com

Frequently Asked Questions

 

Q1: There are many industry forums working on an Intent-based policy  interface for applications.  Why should the IETF form a Working Group  to examine an Intent-Based language?

Over the years industry forums have tried to create a mosaic of standards groups where each standards group focuses on it's key role. IETF has focused its efforts on protocols that communicate across the IP network, and management protocols to manage these efforts. The Intent-Based Network Modeling (IB-Nemo) language is a language which communicates between an application and a network management system that controls traffic through the network.  Different forums may call this network management different names (E.g.  SDN controller or centralized controller or others).  The IB-Nemo language seeks to provide a minimal set of language statements to pass the intent from an application to the network management system which is controlling the networks.

Q2: Can Intent North Bound Interfaces (NBIs) control more than networks?

A user may use Intent language to control storage or CPU cycles, but an intent-based networking language focuses on networks.  Why?

Many operators supporting this work want to control virtual networks, service-based forwarding in networks or data center networks, home- networks, and mobile networks.  If Intent based networking is successful, then the community may turn to controlling networks plus storage plus CPU.  The group is starting with what they know.

The [I-D.xia-sdnrg-nemo-language] focuses on three basic components:  logical node, logical link, and a logical data flow.

Q3: Why a minimal size language?  How will you control all of the network management devices that control the network?

The purpose behind the minimal language set is provide a very simple language that most applications can use for simple operations.  Often in languages, most users (say 80%)of the language utilize only 20% of the commands.  We'll call this within this paper as the 80/20 rule of languages.  To be available for most applications, the language must be standardized, interoperate between different implementations, and have management interfaces.

The IB-Nemo language [I-D.xia-sdnrg-nemo-language] allows groups of applications to simplify the interface by providing the capability to transfer a data model that can store common information (e.g. names or addresses) for nodes and links plus rate of data flow (e.g. 10Gigbit).  As an example, an application for a home-network on a cable network can simply load one set of data from a library and pass them to the network management system. Applications for virtual networks for a company could load a different set of data from a library and send it to the network management system.

The goal of this language is not to support all possible Intent language commands nor all network management systems.  The intent is to work within the 80/20 rule.

   Open-Daylight (ODL) has three Intent-Based Code projects:

   o  Network Intent Composition (NIC)

      (https://wiki.opendaylight.org/view/

      Project_Proposals:Network_Intent_Composition) (ODL:NIC),

   o  Open Daylight Nemo (ODL Nemo) https://wiki.opendaylight.org/view/

      NEMO:Main, and

   o  Group Based Policy (ODL-GBP) (https://wiki.opendaylight.org/view/

      Group_Based_Policy_(GBP)).

 

The ODL-NIC project is creating a Intent based interface that provides all necessary Intent.  The ODL Nemo project is focusing on creating a minimal size language interface using the 80/20 rule of languages.  The ODL-GBP sees Group-based policy as the automation of Intent by creating contracts between groups of endpoints.

   Q4: Is it time for IETF standardization?

An Open Source release of the Open Daylight code for IB-Nemo (ODL Nemo)under the Open Daylight Nemo will occur in July of 2015.  A demonstration of this was shown at ONS 2015.  The Open Daylight code for the Network Intent Composition (ODL-NIC) and the Group Based Policy (ODL-GBP) was released with the Lithium release in June 2015. Demonstrations were shown at ONS 2015 of these three source projects. Both ODL-NIC and ODL-GBP are full-features (aka non-minimal size) north-bound interface.

The Open Daylight code base has been transitioned to products with a number of vendors.  Some of the ODL source code is headed for the Open Platform for NFV (OPNFV) project (https://www.opnfv.org).  The IB-Nemo project team is working on the OPNFV Movie project (https://wiki.opnfv.org/movie) to provide use cases that will allow matching the ODL code bases with the OPNFV deployments.  Much of the open source code from ODL and OPNFV open source projects has moved into the product code bases of vendors.

Now is the time for the IETF to begin to standardize the interoperability of the IB-Nemo interface as the code enters these open source bases.

Operators in carrier and cable (MSO) see this as a key way to speed up provisioning by obtaining their users desires via the Intent Interface.  Operators like Telefonica wish to plug IB-Nemo into their Net-IDE interface.

   Q5: What data models will IB-Nemo focus on?

IB-Nemo is focusing on the data modeling that will allow development of a minimal size language.  The process of developing a reduced set of language commands involves choosing the use cases that must be solved, and then attempting to design the language to pass the right information from the application to the network management system.

The best way to validate the language is to have prototypical application use cases and then use the language to pass the intent plus the additional contextual information needed in order for the network management system to create the virtual network needed.  A good way to summarize the information the network management system stores is in a yang data model.  Therefore, the working group scopeincludes the creation of these data models to test the language.  Long-term these test cases can be used to test language implementations.

Like All protocols, IB-Nemo will be created with yang data modules to configure and manage the protocol.  However, these are different than the modules used to validate the subset of interoperable commands.  These data models are not information models for generic Intent-based or declarative policy.  SUPA is working on generic information models  for Event-Condition-Action (ECA) and declarative policy.  As these   models develop, it is hoped their insights on policy may help those   working in the Intent-based policy.

 

IB-Nemo work plan does not focus on being an automation architecture or protocol.  ANIMA is working on this in the IETF.