Intent Translation Engine for Intent-Based Networking

Abstract

This document specifies the schemas and models required to realize the data formats and interfaces for Intent-Based Networking (IBN). They are needed to enable the composition of services to build a translation engine for IBN-based network management. This intent translation engine (called an intent translator) is an essential function for network intents to be enforced into a target network for the configuration and management of the network and its security.¶

1. Introduction

The increased difficulty to define management goals and policies enforced to networks and security has raised the definition of Intent-Based Networking (IBN). It abstracts the definition of those goals and policies in the form of network intents.¶

An intent is a declarative statement to request a configuration or management for a network or security function [TS-28.312][TR-28.812]. It addresses more on "What" is needed (i.e., declarative statement) to be fulfilled than "How" it should be fulfilled (i.e., imperative statement).¶

For IBN to be properly realized, it is envisioned that many stakeholders would be involved in the translation of network intents to particular policies and configurations. Thus, there will be many components and services that would be composed to construct a solution to implement network intents.¶

This document specifies the schemas and models required to realize the data formats and interfaces for IBN-based network management. They are needed to enable the composition of services to build a translation engine for network intents, namely Intent Translation Engine (or Intent Translator).¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶

3. Intent Translation Engine

This document specifies the required data formats and interfaces that MUST be implemented by the components of an Intent Translation Engine (ITE), that is, an Intent Translator. Therefore, this extends the Intent Classification in [RFC9316] and drives the implementation of the specifications REQUIRED to properly classify network intents.¶

4. Translation Process

The translation process begins with a network intent fully written in natural language and ends with a formal specification of network service. The output specification MUST include a definition of static elements and a definition of operational policies. The former consists of a formal document, such as NSD for OSM [OSM], which is written in a formal language, such as XML, JSON, or YAML, that describes the components involved in the network intent and their connections. The latter consists of a set of rules, goals, and operational boundaries, expressed in a formal language like OCL [OCL] or SWRL [SWRL].¶

The translation process SHOULD be divided in several stages. The following stages are RECOMMENDED:¶

1. Dividing the network intent expressed in natural language into several self-contained sentences.¶

2. Converting each sentence into a list of language tokens.¶

3. Extending language tokens with network concepts contained in a network ontology (and YANG model, explained below).¶

4. Organizing the tokens in a hierarchy of components---with a single outer most component, which is the network service, and as many inner most components as needed, which are the atomic elements---network functions, links, operating rules, etc.¶

5. Separating the token hierarchy into as many hierarchies as domains identified in the hierarchy itself.¶

6. Communicating each domain-specific hierarchy to the ITE agent that represents its corresponding domain---including a copy of the original intent if approved by policies.¶

7. Matching the token hierarchy with available resources, replacing language tokens with formal resource descriptions and identifiers.¶

8. Constructing a final structure that can be understood by the target system---such as NSD.¶

9. Registering the final structure into the IBN knowledge base.¶

These stages involve several interfaces and data formats. However, the most general interfaces can be fulfilled by NETCONF, as specified in the models below, and the data formats are flexible enough to support different internal structures, as also specified in the models detailed below.¶

5. Distributed Translation

The translation process REQUIRES communication between several domains to realize the translation of multi-domain network intents. Such communication abilities MUST be discoverable through NETCONF, involving the data models disclosed below.¶

The communication abilities MAY also be used to translate single-domain network intents. In this case, they take advantage of the collective knowledge of all agents involved in the process. This REQUIRES to canonically obtain a set of structures that will be processed separately from a network intent or an intermediate processing structure obtained by an intermediate stage of the process.¶

To ensure the canonical result, the separation of the network intent into such structures, and their assignation to domain agents, SHOULD be done through the following procedure:¶

1. If required by administrative policies of the agents that originate the separation process, the network intent or intermediate structure MUST be anonymized.¶

2. The network intent or intermediate structure is sent to all agents of the multi-domain platform.¶

3. Each agent evaluates its ability to advance the structure to a later state. For early stages, the agent evaluates its ability to tokenize and re-structure the requirements of the network intent. For later stages, the agent evaluates its ability to extend tokenized structures with network-oriented meta-data. For final stages, the agent evaluates its ability to transform enlarged tokenized structures into NSD for topology concepts and/or OCL or SWRL for policy concepts.¶

4. The result of the evaluation is sent back to the agent that originated the request. It is a number that represents the ability of the agent to manage the current structure.¶

5. The agent sorts the domains by the numbers contained in the answers into a list of agents-to-request.¶

6. The agent sends the structure to be processed to the first agent in the list of agents-to-request.¶

7. The receiving agent processes the input, obtains its output, and sens back its response to the requester agent.¶

8. The requester agents sends a new request to the next agent in the list of agents-to-request.¶

9. The process continues until all structures have been fully processed or all agents have been involved. If needed, a new round is done starting from the first step.¶

This procedure maximizes the processing outcomes while minimizing the amount of information shared among the agents, as demonstrated in [TBD].¶

6. Orchestration Interfaces

Particular ITE interfaces are REQUIRED to perform the orchestration of network services. These interfaces expect network intents that only reference existing elements and operational goals. The translation process MUST support such particularity to be indicated, so that no new element instantiation are considered. In response to this indication, the agents that process the network intents and intermediate structures MUST only use the knowledge base that includes already-deployed elements. This applies to both the overall translation process and distributed processing.¶

Apart from the basic operations for intent translation, the orchestration interfaces MUST offer the following functions:¶

• Instantiating a network service: Receives the resulting structure of the translation of network intents and constructs the network service by configuring and connecting the existing elements as specified in these structures.¶

• TBD -- Additional orchestration functions will be gathered here.¶

The orchestration agents that form part of the distributed platform to support the distributed translation MUST also manage the instantiation of the resulting structures after translating the network intent.¶

In future version of this document we will add information models for the orchestration interfaces.¶

7. Information Model -- YANG Module

Agent configuration interface (RPC) definitions:¶

module agent-cai {
  namespace "urn:ietf:params:xml:ns:yang:ietf-cai";
  prefix cai;

  import ietf-inet-types {
    prefix "inet";
  }

  organization "NICT";
  contact "Pedro Martinez-Julia (pedro@nict.go.jp)";
  description "CAI -- Collaborative artificial intelligence";

  revision 2024-04-25 {
    description "Initial version";
    reference "AINEMA";
  }

  container settings {
    description "Settings";
    leaf self {
      type string;
      description "";
    }
    leaf port {
      type inet:port-number;
      description "";
    }
    list agent {
      key "name";
      description "List of other agents";
      leaf name {
        type string;
        description "Agent name";
      }
      leaf host {
        type string;
        description "Host";
      }
      leaf port {
        type inet:port-number;
        description "Port";
      }
    }
  }

  grouping knowledge-object {
    description "Knowledge Object";
    leaf source {
      type string;
      mandatory true;
      description "";
    }
    list disjunction {
      description "Conjunction of disjunctions";
      leaf source {
        type string;
        mandatory true;
        description "";
      }
      list literal {
        min-elements 1;
        description "Disjunction of literals";
        leaf source {
          type string;
          mandatory true;
          description "";
        }
        leaf object {
          type string;
          mandatory true;
          description "";
        }
        leaf negated {
          type boolean;
          mandatory true;
          description "";
        }
      }
    }
  }

  container knowledge-base {
    config false;
    description "Knowledge Base";
    container logic {
      description "Logic Rules";
      uses knowledge-object;
    }
    container regex {
      description "Regular Expressions";
      list item {
        description "Regular Expressions Substitutions";
        leaf pattern {
          type string;
          mandatory true;
          description "";
        }
        leaf replacement {
          type string;
          mandatory true;
          description "";
        }
      }
    }
  }

  grouping knowledge-q {
    description "Knowledge Question";
    container object {
      description "Input Object";
      uses knowledge-object;
    }
    container goal {
      description "Goal";
      uses knowledge-object;
    }
  }

  rpc achieve-goal {
    description "Try to achieve goal from input object";
    input {
      uses knowledge-q;
    }
    output {
      container output {
        description "Output";
        uses knowledge-object;
      }
    }
  }

}

8. Implementation Guide

This document will specify an abstract algorithm that allows an ITE (i.e., intent translator) to obtain a set of network service definitions and the composition of management mechanisms that implements the required policies or rules from a set of inputs. The ITE can translate an intent into a network policy for a target network [I-D.jeong-nmrg-ibn-network-management-automation][I-D.yang-i2nsf-security-policy-translation].¶

The inputs are:¶

1. The intent provided by the tenant or some external agent.¶

2. A set of management mechanisms -- retrieved from some management system available.¶

3. A set of VNFs and network resources -- retrieved from some VIM.¶

The abstract algorithm helps obtaining validated network service definitions and management mechanism compositions which are valid for the available instantiation infrastructure.¶

9. Relation to Other IETF/IRTF Initiatives

TBD¶

13. References

Appendix A. Changes from draft-pedro-ite-01

The following changes are made from draft-pedro-ite-01:¶

• Added sections for translation process, distributed processing, and orchestration interfaces.¶

• Added YANG models.¶