An
Application’s Interface to
Intent Based
Networks
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
Q2: Can Intent
North Bound Interfaces (NBIs) control more than networks?
Further Information
Introduction
· 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
· ONS 2015 ONF Marketing Opportunity
Related Projects
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.
