I am pleased to report that there are diverse, and sometimes overlapping, groups of people actively engaged in building Intent-based systems solutions across the Open Networking Foundation, OpenDayLight, ON.Lab, OpenStack, and various NFV projects. We still need plenty of help from smart, dedicated people, but we are on our way to providing fungible components from which network solutions can easily be built.

We are poised to offer true choice and head-to-head “bake-offs” between system components and architectural choices without onerous integration costs. The much sought-after and rarely seen “second source” option will actually be made available to network operators, and vendor-specific lock-in and high-friction changes will be largely eliminated by agreeing to this critical inter-system interface. To insure success we are rapidly making multiple implementations available in order to appeal to diverse stake-holders and reduce barriers to entry for innovators.

The Network Effect

In order to succeed, it will be necessary to create a “network effect.” This concept is based on the idea that in an ecosystem, there is a non-linear growth pattern that develops from a virtuous cycle. Facebook, for example, saw explosive growth due to the fact that the value of the service is a function of how many people use it.

In software platform terms, the forces acting are operators and vendors. For a given API/SDK/ecosystem, if more vendors support it, more customers will seek it, which will lead more vendors to support it, a winner-take-all network effect that can establish a dominant platform. We hope to create a network effect of adoption of IBN, by proliferating a common, community-developed North-Bound Interface (NBI) with compelling value for both operators and vendors.

Thinking Different

In an Intent-based system, we model the interface between network service consuming systems and network infrastructure (e.g., the SDN controller NBI) based on what the connected workloads need from the network (their communications intent). Because we are not specifically describing any aspect of the network implementation (protocols, ports, channels, addresses, packet headers), we get portability benefits allowing the “Intent description” for a given set of workloads to be utilized, unchanged, across different vendors, protocols, media, operating systems, etc.

In addition, the operator who understands the distributed applications and their communication needs doesn’t need to know anything about protocols, vendors, or media to create an Intent description that supports the targeted workloads. Because the Intent description provides rich context describing the what (rather than the how), it is possible to create an integrated system where multiple, discrete SDN services are offered, while resolving and avoiding potential conflicts over shared resources such as forwarding tables. (This property is formally known as “composability” of the offered services, and is not offered by existing SDN systems.)

An intent-based system is more secure than a less abstracted interface to network controller resources. The primary vulnerabilities identified in traditional SDN interfaces (raw flow-table manipulation, etc.) are not possible in a system where the only NBI exposed is Intent-based.

JVM Analogy

To understand the conceptual approach represented by an Intent-based network system, it is helpful to consider the Java Virtual Machine as analogous.

Creating code to deliver features in multiple browsers and operating systems was complex and expensive with lots of duplication of effort. As a result, Java, a more abstract language, was developed and proliferated based on a “write once, run anywhere” value proposition. This innovation was based on the observation that removing platform- and infrastructure-specific aspects from the language allowed the language interpreter run-time (JVM) to be ported once to each of the diverse platforms. Java became ubiquitous by enabling and riding the network effect around write-once, run-anywhere.

Operation of network solutions is largely done at the level of individual devices and is based on what is essentially custom code for each of the different vendor/protocol/ASIC combinations available. The Intent NBI turns the SDN controller into a black box that accepts a write-once, run-anywhere description of some set of network-attached entities. We refer to this description as a set of “Intent expressions.”

The common Intent NBI being developed in the ONF NBI Working Group under the leadership of Ciena VP Chris Janz, is defining operating principles and information models for an Intent NBI (analogous to the Java language definition) that will be implemented on as many network controller platforms as possible to encourage a network effect. The Intent “engine” is the JVM equivalent that networked application designers can use to create a write-once description of their network infrastructure needs.

An Improved Ecosystem

In general, the existence of a common NBI across multiple diverse infrastructure controllers (ODL, ONOS, OpenStack, OPNFV) creates new opportunities for choice, competition, and differentiation for both free, open-source solutions and for commercial, value-added solutions. The clean layering established between the orchestration platforms and the network infrastructure controller allows vertical specialization by a set of folks who don’t care at all how the infrastructure gets implemented, and allows customization and differentiation in terms of implementation and resulting properties such as scale, performance, robustness, and ease of use.

A network effect initiated by high-profile adopters could drive both the infrastructure and the business solutions creators to build a large, complementary set of choices.

ONF

The Open Networking Foundation is defining common Intent NBI principles and an information model. In the ONF North Bound Interface Working Group, Ciena’s Janz is Vice Chairman running the Intent networking activities currently being consolidated under the OSSDN Boulder Project. The primary work items in progress currently are:

A “Principles of Operation” document that describes at a high level how an Intent-based network system operates and how the operating requirements get split between completely portable “Intent Expressions” and “Intent Mapping” descriptions capturing non-portable (implementation dependent) descriptions of how to realize a given intent on a given system. This designs the system in which the intent NBI exists.

A group of Information Models that describe the Intent and Intent Mapping interfaces. These software artifacts are provided to “downstream” network infrastructure controller projects for inclusion in Intent-based system implementations.

Within the OSSDN repository there will be simultaneously “approved” IM fragments that have been discussed and have achieved broad consensus by the community, and “proposed” fragments where anyone can customize and experiment in the root of the Intent IM tree.

Downstream projects entirely control the selection of IM fragments to include in building any controller instance. As of this writing, there are no approved fragments, and the process of getting to some is being developed in the community.

Initial work on the Boulder project provided a demonstration of end-to-end service function chaining, using OSSDN Boulder artifacts, across both an Open DayLight domain and an ONOS domain using the common Boulder Intent interface. Inocybe Technologies did this work, partially sponsored by the ONF.

ODL NIC Project

The OpenDayLight Network Intent Composition (NIC) project has been established as a place to build one of the reference implementations for Intent-based networking based on the ONF Intent NBI artifacts. The OpenDayLight Helium Release includes demo/experimental features supporting a demo of service function chaining using the NIC interface based on ONF artifacts from Boulder.

ON.Lab

The ON.Lab ONOS SDN controller also supports an Intent interface and can be expected to support ONF Intent NBI artifacts in the future. In June 2015, ONOS was demonstrated with initial support for implementing service function chaining based on Boulder artifacts.

OpenStack

Some work has been done on defining Intent-based interfaces for service function chaining. In addition, there are conversations taking place among major stakeholders from Neutron and from controller projects to understand how to offer additional benefits of Intent-based systems to OpenStack workloads and developers.

OPNFV

There are multiple projects within OPNFV that can be supported by network infrastructure using the Intent interface. Community discussions are ongoing about consolidating the diverse Intent needs for OPNFV projects and providing this as a requirements-input for the ONF NBI Info Modeling work.

ETSI NFV

Intent-based networking approaches are being discussed and will be contributed to ETSI documents from NFV, EVE, and IF working groups.

Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.

While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDxCentral cannot guarantee that inaccuracies will not occur. SDxCentral will not be held responsible for any claim, loss, damage, or inconvenience caused as a result of any information within this site, or any information accessed through this site.

The content of any third-party website that you are linked to from the SDxCentral site is entirely out of the control of SDxCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDxCentral's endorsement or association. The copyright and any other intellectual property right, as well as any third-party content, belong to the author and/or other applicable third party.

SPONSORED

David Lenrow is Chief Architect for Next Generation Data Center and Distinguished Engineer at Huawei. He participates in a wide variety of open source networking projects including ONOS, OpenDaylight, OPNFV, ONFSDN, and Open-O. He is Chairman of the ONF North Bound Interface (NBI) WG, and a leader in the Boulder open source intent software project. He was trained as a computer scientist and has spent more than 20 years driving innovation in digital technology with an emphasis on networks, storage and media. He is passionate about open innovation and seeking to make contributions to the cloud revolution currently sweeping the tech industry.

Win a $200 Amazon Gift Card

New Report: 2016 Cloud Automation and DevOps Report – What’s Next for Networking in the Cloud?

2016 Cloud Automation and DevOps Report: What’s Next for Networking in the Cloud? is available for free download. This FREE Report examines how cloud management, automation, and DevOps are likely to influence and integrate with networking and SDx technology in the future.

About SDxCentral

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDNCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.