Network Intent Composition Project (NIC) is a recently created Intent based project in OpenDaylight. It is one of several projects, ONOS is another, to support the controller-agnostic community developed Intent NBI being defined by the Network Intent Project in the ONF’s NBI working group.
Its stated goal is to “enable the controller to manage and direct network services and network resources based on describing the ‘Intent’ for network behaviors and network policies.”
Its purpose is to develop a new extensible northbound interface (NBI) that allows users to describe what they want from the network rather than prescribe how to deliver that service. The NBI Intent interface will be exposed to network orchestration systems, SDN Applications and Network Operators. It may be defined as RESTCONF, and/or Java APIs. It will rely upon existing OpenDaylight southbound plug-ins to control the network devices and is protocol agnostic; it will work with various protocols such as OpenFlow, SNMP, OVSDB, etc.
By developing NIC within the OpenDaylight community the project leverages its combined expertise. It also provides the opportunity to integrate and test the Intent NBI with existing and evolving network services that OpenDaylight supports.
The NIC development process is use-case driven and incremental. The plan is to focus on use cases prioritized from among the broad community of contributors. The project is starting with some very simple use cases and will increase complexity over time. Limitations of the modeling will be identified over time and updated to provide the needed capabilities.
Project deliverables are expected to include:
• An NBI framework built on a modular / pluggable extensible YANG model. The framework will allow users to independently define new NBIs for new services.
• Yang models to enable NBI support of a set of use cases. These will be simple use cases and models initially, evolving in complexity over time.
• A reference design to support an SDN work item in the standards organization, the European
Telecommunications Standards Institute (ETSI) Network Functions Virtualization Industry Specification Group (NFV ISG).
The project will also tackle a significant technical problem, how to identify and resolve conflicts among multiple Intent driven service requests. It is highly likely that intentions and policies defined in the different services will come into conflict. It will be necessary for the NIC solution to resolve these differences, creating a consistent set of network actions. As the project documentation states, “The goal is to solve the multiple-writers/multiservice SDN problem with an intent-only distribution of the controller exposing intent as the intermediate language.
More information can be found on the OpenDaylight NIC website.
Status
The OpenDaylight NIC project has been very active since its inception in January, 2015. The development team includes committers from leading vendors. Some of the work is being funded by the ONF.
The capability is expected to have its initial release included in the Lithium release of OpenDaylight, scheduled for late June, 2015. During its initial planning stage, a large number of use cases were proposed, including, but not limited to, Bandwidth on Demand, QoS control, Service Chaining, DNS Monitoring, and Virtual Tenant Networks. It is expected that the initial release will include support for an Intent NBI for Virtual Tenant Networks and control of Group Based Policy.
13.3.1 NeMo
NeMo provides a simple transaction based Intent-based NBI, enabling applications to create, modify and takedown virtual networks built on virtual nodes with policy-controlled flows. The NeMo Intent NBI allows an application to communicate with a controller, providing ten commands:
• Four network commands: Node, Link, Flow, Policy
• Six controller communication commands: connect, disconnect, transact, commit, notification, query An application exchanges NeMo commands using the REST Protocol to a controller running a Nemo language processing engine to instruct the controller to set up a virtual network of nodes and links with flow policy to control the data flows across the network links.
SDN Architecture for Cable Access Networks Technical Report VNE-TR-SDN-ARCH-V01-150625 node and what constitute a ‘link’ and a ‘flow’. From the application’s viewpoint, it intends to connect two or more nodes in a network. It does not matter to the application if the node is a single Virtual Machine (VM) or a cluster of interconnected compute and storage devices with many network connections. NeMo’s NBI API hides this
complexity, making the application’s commands prescriptive and simple.
Technically, NeMo is a declarative, domain specific policy language. NeMo’s language engine in the controller is associated with a model that allows a group of applications to have a set of pre-loaded definitions (model semantics) for nodes, flows, or policy. For example, a company node could be defined along with the necessary flows for accounting traffic or big-data transfers.
NeMo is progressing as active projects in OpenDaylight, OPNFV and IETF. The goals of the OpenDaylight NeMo project are:
• Design and develop consistent NBI models and patterns for intent networks.
• Design the syntax for a language style NBI.
• Design and develop a NEMO language engine for language parsing and model mapping to SB models. It is possible to reuse the ongoing NIC project in OpenDaylight for the intent manager and model mapping component.
The goals of the OPNFV project2 are:
• Provide a more abstract NBI alternative by extending the general cloud platform to simplify the orchestrator and VNF manager.
• Compose various scenarios with a same set of abstractions.
• Use the MDA approach for NBI consistency and interface automation. The goals of the IETF activity are:
• Provide a clear definition of Intent that can be operationalized in networks.
• Define use cases for intent networking.
• Provide a gap analysis for other work in the IETF.
• Create intent data models and information network models.
• Standardize a protocol language for NeMo.
• Standardize data models.
Figure 54 shows how these activities relate.
Figure 54 - NeMo Relationship to Open Source and IETF
Status
In 2014, the NeMo project provided early proof-of-concept code demos for an Intent-based interface that uses a domain specific language. Nemo is moving this work into open Source projects and the IETF. In 2015, public demonstrations were shown at conferences and at the IETF.
13.3.2 OpenStack Congress
Congress aims to provide an extensible open-source framework for governance and regulatory compliance across any cloud services (e.g., application, network, compute and storage) within a dynamic infrastructure. It is a cloud service whose sole responsibility is policy enforcement.
Congress aims to allow cloud administrators and tenants to use a high-level, general purpose, declarative language to describe business logic. The policy language does not include a fixed collection of policy types or built-in enforcement mechanisms; rather, a policy simply defines which states of the cloud are in compliance and which are not, where the state of the cloud is the collection of data provided by the cloud services available to Congress. Some examples are:
• Application A is only allowed to communicate with Application B.
• Virtual machine owned by Tenant A should always have a public network connection if Tenant A is part of the Group B.
• Virtual Machine A should never be provisioned in a different geographic region than Storage B.
Congress offers a pluggable architecture that connects to any collection of cloud services and can enforce policy:
• Proactively: preventing violations before they occur.
• Reactively: correcting violations after they occur.
• Interactively: give administrators insight into policy and its violations, e.g., identifying violations, explaining their causes, computing potential remediation, simulating a sequence of changes.
The policy language for Congress is Datalog, which is based on SQL but with a syntax that is closer to traditional programming languages. This declarative language was chosen because its semantics are well-known to a broad range of DevOps, but its syntax is more ‘terse’ making it better suited for expressing real-world policies.
SDN Architecture for Cable Access Networks Technical Report VNE-TR-SDN-ARCH-V01-150625
Status
Congress began in late 2013 and is actively progressing code development with reference to policy enforcement capabilities in OpenStack such as Keystone, but also applicable to other policy enforcement enabled entities such as OpenDaylight.
13.3.3 IETF SUPA
IETF SUPA (Simplified Use of Policy Abstractions) is a Birds of a Feather (BoF) proposing an IETF Working Group to develop a set of information models for defining standardized policy rules at different levels of abstraction, and will show how to map these (technology-independent) forms into YANG data models. The working group introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g., IP, VPN, MPLS) network abstractions to address the current separation between development and deployment operations. Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using diverse components and technologies to implement a network service.
Three information models are envisioned:
• A generic information model that defines concepts needed by policy management independent of the form and content of the policy.
• A more specific information model that refines the generic information model to specify how to build policy rules of the event-condition-action paradigm.
• A more specific information model that refines the generic information model to specify how to build policy rules that declaratively specify what goals to achieve (but not how to achieve those goals).
This set of generic policy information models will be mapped to a set of concrete YANG data models. These data models will provide a set of core YANG modules that define how to manage and communicate policies, expressed using the event-condition-action paradigm or the declarative goal-oriented paradigm, between systems.
The proposed working group will focus in the first phase of its work on completing the set of information models required to construct an extensible, policy-based framework. These information models will lead to a set of core YANG data models for a policy-based management framework to monitor and control network services.
The working group will reference the Distributed Data Center (DDC) use case, which includes the dynamic policy- driven provisioning and operation of inter-datacenter VPNs of various types, as a means to validate that the generic policy-framework is implementable and usable.
Status
The main contributors to SUPA come from industry and academia. Today it holds Birds of a Feather status in the IETF. This means it is in a pre-Working Group state and its timeline is still being decided upon. In July 2015, the decision will be made as to whether this will become a working group.