Intent Translation Engine for Intent-Based Networking
draft-pedro-ite-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Pedro Martinez-Julia , Jaehoon Paul Jeong , Takuya Miyasaka , Diego Lopez | ||
| Last updated | 2025-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pedro-ite-02
TBD P. Martinez-Julia, Ed.
Internet-Draft NICT
Intended status: Standards Track J. Jeong, Ed.
Expires: 23 April 2026 Sungkyunkwan University
T. Miyasaka
KDDI Corporation
D. R. Lopez
Telefonica
20 October 2025
Intent Translation Engine for Intent-Based Networking
draft-pedro-ite-02
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.
Status of This Memo
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 23 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Martinez-Julia, et al. Expires 23 April 2026 [Page 1]
Internet-Draft Intent Translation Engine October 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Intent Translation Engine . . . . . . . . . . . . . . . . . . 3
3.1. Interaction Between the ITE and Network Tenants . . . . . 3
3.2. Interaction Between the ITE and Network Management
Systems . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Interaction Between the ITE and VIM . . . . . . . . . . . 4
3.4. Interaction Between the ITE and External Services . . . . 5
4. Translation Process . . . . . . . . . . . . . . . . . . . . . 5
4.1. Incomplete Translations . . . . . . . . . . . . . . . . . 6
5. Distributed Translation . . . . . . . . . . . . . . . . . . . 7
6. Orchestration Interfaces . . . . . . . . . . . . . . . . . . 8
7. Information Model -- YANG Module . . . . . . . . . . . . . . 8
8. Implementation Guide . . . . . . . . . . . . . . . . . . . . 11
9. Relation to Other IETF/IRTF Initiatives . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from draft-pedro-ite-01 . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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).
Martinez-Julia, et al. Expires 23 April 2026 [Page 2]
Internet-Draft Intent Translation Engine October 2025
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.
3.1. Interaction Between the ITE and Network Tenants
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 interfaces 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.
Martinez-Julia, et al. Expires 23 April 2026 [Page 3]
Internet-Draft Intent Translation Engine October 2025
* [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.
3.2. Interaction Between the ITE and Network Management Systems
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 interfaces 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.
3.3. Interaction Between the ITE and VIM
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) [OSM].
Martinez-Julia, et al. Expires 23 April 2026 [Page 4]
Internet-Draft Intent Translation Engine October 2025
The interfaces 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.
3.4. Interaction Between the ITE and External Services
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 network intents, 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 interfaces 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.
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:
Martinez-Julia, et al. Expires 23 April 2026 [Page 5]
Internet-Draft Intent Translation Engine October 2025
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.
4.1. Incomplete Translations
When a network intent cannot be fully translated, the tenant must be
somehow asked for further information and a new translation process
will be launched. The new process will however start using the
result of the previous process and the new information provided. The
overall stages remain the same.
Future versions of this document will detail the particular
procedures, interfaces, and models related to this situation.
Martinez-Julia, et al. Expires 23 April 2026 [Page 6]
Internet-Draft Intent Translation Engine October 2025
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.
Martinez-Julia, et al. Expires 23 April 2026 [Page 7]
Internet-Draft Intent Translation Engine October 2025
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:
Martinez-Julia, et al. Expires 23 April 2026 [Page 8]
Internet-Draft Intent Translation Engine October 2025
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 ([email protected])";
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 {
Martinez-Julia, et al. Expires 23 April 2026 [Page 9]
Internet-Draft Intent Translation Engine October 2025
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 "";
Martinez-Julia, et al. Expires 23 April 2026 [Page 10]
Internet-Draft Intent Translation Engine October 2025
}
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-i
2nsf-security-policy-translation].
The inputs are:
Martinez-Julia, et al. Expires 23 April 2026 [Page 11]
Internet-Draft Intent Translation Engine October 2025
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
10. IANA Considerations
This document does not require any IANA actions.
11. Security Considerations
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.
12. Acknowledgments
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).
13. References
13.1. Normative References
Martinez-Julia, et al. Expires 23 April 2026 [Page 12]
Internet-Draft Intent Translation Engine October 2025
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/info/rfc9232>.
[RFC9316] Li, C., Havel, O., Olariu, A., Martinez-Julia, P., Nobre,
J., and D. Lopez, "Intent Classification", RFC 9316,
DOI 10.17487/RFC9316, October 2022,
<https://www.rfc-editor.org/info/rfc9316>.
13.2. Informative References
[I-D.jeong-nmrg-ibn-network-management-automation]
Jeong, J. P., Ahn, Y., Gu, M., Kim, Y., and J. Jung-Soo,
"Intent-Based Network Management Automation in 5G
Networks", Work in Progress, Internet-Draft, draft-jeong-
nmrg-ibn-network-management-automation-06, 9 June 2025,
<https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-
ibn-network-management-automation-06>.
[I-D.pedro-nmrg-ai-framework]
Martinez-Julia, P., Homma, S., and D. Lopez, "Artificial
Intelligence Framework for Network Management", Work in
Progress, Internet-Draft, draft-pedro-nmrg-ai-framework-
05, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-pedro-nmrg-
ai-framework-05>.
[I-D.yang-i2nsf-security-policy-translation]
Jeong, J. P., Lingga, P., and J. Yang, "Guidelines for
Security Policy Translation in Interface to Network
Security Functions", Work in Progress, Internet-Draft,
draft-yang-i2nsf-security-policy-translation-16, 7
February 2024, <https://datatracker.ietf.org/doc/html/
draft-yang-i2nsf-security-policy-translation-16>.
[OCL] Adaptive Analytics, Inc., "Object Constraint Language",
Available: https://www.omg.org/spec/OCL/2.4, 2014.
[OSM] ETSI - OSM, "OSM Release Five Technical Overview", 2019.
Martinez-Julia, et al. Expires 23 April 2026 [Page 13]
Internet-Draft Intent Translation Engine October 2025
[SWRL] Ian Horrocks, Peter F. Patel-Schneider, Harold Boley, Said
Tabet, Benjamin Grosof, and Mike Dean, "SWRL - A Semantic
Web Rule Language Combining OWL and RuleML",
Available: https://www.w3.org/submissions/SWRL/, 2004.
[TBD] TBD, "TBD", 2025.
[TNSM-2018]
P. Martinez-Julia, V. P. Kafle, and H. Harai, "Exploiting
External Events for Resource Adaptation in Virtual
Computer and Network Systems, in IEEE Transactions on
Network and Service Management. Vol. 15, n. 2, pp. 555--
566, 2018.", 2018.
[TR-28.812]
"Study on Scenarios for Intent Driven Management Services
for Mobile Networks", Available:
https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3553, December
2020.
[TS-28.312]
"Intent Driven Management Services for Mobile Networks",
Available:
https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3554, September
2023.
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.
Authors' Addresses
Pedro Martinez-Julia (editor)
NICT
4-2-1, Nukui-Kitamachi, Koganei, Tokyo
184-8795
Japan
Phone: +81 42 327 7293
Email: [email protected]
Martinez-Julia, et al. Expires 23 April 2026 [Page 14]
Internet-Draft Intent Translation Engine October 2025
Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Email: [email protected]
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Takuya Miyasaka
KDDI Corporation
Email: [email protected]
Diego R. Lopez
Telefonica
Don Ramon de la Cruz, 82
28006 Madrid
Spain
Email: [email protected]
Martinez-Julia, et al. Expires 23 April 2026 [Page 15]