| Internet-Draft | Intent Translation Engine | March 2024 |
| Martinez-Julia & Jeong | Expires 6 September 2024 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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).¶
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].¶
This document specifes the required data formats and interfaces that MUST be implmeented 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 propertly classify network intents.¶
The data formats required for enabling interaction between the ITE and network tenants are as follows:¶
[TF1] Schema---Resource Description Framework (RDF) ontology and YANG model---that must be used to format intents introduced in the ITE.¶
[TF2] Schema---RDF ontology and YANG model---that must be used to format declarations of intent semantics---namely, the set of concepts, relations, and ontologies that can be present in an intent.¶
The intefaces required for enabling interaction between the ITE and network tenants are as follows:¶
[TI1] Schema---RDF ontology and YANG model---that must be used by a tenant or other external entity to format and transmit an intent to the ITE.¶
[TI2] Schema---RDF ontology and YANG model---that must be used by an ITE to publish---via NETCONF and others---the intent semantics it supports. Particularly, the set of concepts, relations, and ontologies that can be used by tenants to define input intents.¶
This document will also specify the minimum set of semantics that must be supported by any ITE and discovered by the interactions described in this section.¶
The data formats required for enabling interaction between the ITE and network management systems are as follows:¶
[MF1] Schema---RDF ontology and YANG model---that must be used by a management system to format declarations of management mechanisms and by an ITE to format their compositions. This schema and model comprehends the definitions for both management information and commands. Hence, this schema follows the definitions of [RFC9232] to specify data formats for telemetry transmission.¶
The intefaces required for enabling interaction between the ITE and network management systems are as follows:¶
[MI1] Schema---RDF ontology and YANG model---that must be used by a management system to publish---via NETCONF and others---the management mechanisms it provides for being composed to implement policies and network services. This schema also follows the definitions of [RFC9232] to specify telemetry interactions.¶
This document will also specify the minimum set of management mechanisms that must be provided by a management system for proper intent support.¶
The data formats required for enabling interaction between the ITE and the Virtualized Infrastructure Manager (VIM) are as follows:¶
[VF1] Schema---RDF ontology and YANG model---that must be used to format declarations of network resources and Virtual Network Functions (VNFs).¶
[VF2] Schema---RDF ontology and YANG model---that must be used to format Network Service Descriptor (NSD).¶
The intefaces required for enabling interaction between the ITE and the VIM are as follows:¶
[VI1] Schema---RDF ontology and YANG model---that must be used by a VIM to publish---via NETCONF and others---the network resources and Virtual Network Functions (VNFs) it provides.¶
This document will also specify the minimum set of network resources and VNFs that must be provided by a VIM for proper intent support.¶
The data formats required for enabling interaction between the ITE and external services are as follows:¶
[EF1] Schema---RDF ontology and YANG model---that must be used to format declarations of networkintents, network resources, and VNFs. This schema will be used by elements that will use intents to interact with management systems, such as AINEMA [I-D.pedro-nmrg-ai-framework], which enables the ITE with Artificial Intelligence (AI) functions and which will express management decisions in terms of network intents, as shown in [TNSM-2018].¶
The intefaces required for enabling interaction between the ITE and external services are as follows:¶
[EI1] Schema---RDF ontology and YANG model---that must be used by an ITE allow external agents to provide network intents and retrieve information about available resources and VNFs.¶
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:¶
The intent provided by the tenant or some external agent.¶
A set of management mechanisms -- retrieved from some management system available.¶
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.¶
TBD¶
TBD¶
This document does not require any IANA actions.¶
As with other AI mechanisms, a major security concern for the adoption of intelligent reasoning on external events to manage SDN/NFV systems is that the boundaries of the control and management planes are crossed to introduce information from outside. Such communications MUST be highly and heavily secured since some malfunction or explicit attacks might compromise the integrity and execution of the controlled system (i.e., target entity) such as router, switch, and firewall. However, it is up to implementers to deploy the necessary countermeasures to avoid such situations. From the design point of view, since all operations are performed within the control and/or management planes, the security level of reasoning solutions is inherited and thus determined by the security measures established by the systems conforming to such planes.¶
This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT)(No. 2022-0-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).¶
The following changes are made from draft-pedro-ite-00:¶