TBD                                               P. Martinez-Julia, Ed.Internet-Draft                                                      NICTIntended 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-02Abstract   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  . . . . . . . . . . . . . . . . . . . . . . .  141.  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 20255.  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 (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 {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   TBD10.  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.  References13.1.  Normative ReferencesMartinez-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: pedro@nict.go.jpMartinez-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: pauljeong@skku.edu   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php   Takuya Miyasaka   KDDI Corporation   Email: ta-miyasaka@kddi.com   Diego R. Lopez   Telefonica   Don Ramon de la Cruz, 82   28006 Madrid   Spain   Email: diego.r.lopez@telefonica.comMartinez-Julia, et al.    Expires 23 April 2026                [Page 15]