| rfc9316xml2.original.xml | rfc9316.xml | |||
|---|---|---|---|---|
| <?xml version='1.0' encoding='utf-8'?> | <?xml version="1.0" encoding="UTF-8"?> | |||
| <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
| <!ENTITY I-D.irtf-nmrg-ibn-concepts-definitions SYSTEM "https://xml2rfc.ietf.org | ||||
| /public/rfc/bibxml3/reference.I-D.irtf-nmrg-ibn-concepts-definitions.xml"> | ||||
| <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.2119.xml"> | ||||
| <!ENTITY RFC7575 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.7575.xml"> | ||||
| <!ENTITY RFC8328 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.8328.xml"> | ||||
| <!ENTITY RFC3198 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.3198.xml"> | ||||
| <!ENTITY RFC6020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.6020.xml"> | ||||
| <!ENTITY RFC7285 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | ||||
| C.7285.xml"> | ||||
| <!ENTITY I-D.du-anima-an-intent SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx | ||||
| ml3/reference.I-D.du-anima-an-intent.xml"> | ||||
| <!ENTITY I-D.ietf-supa-generic-policy-info-model SYSTEM "https://xml2rfc.ietf.or | ||||
| g/public/rfc/bibxml3/reference.I-D.ietf-supa-generic-policy-info-model.xml"> | ||||
| <!ENTITY I-D.ietf-anima-prefix-management SYSTEM "https://xml2rfc.ietf.org/publi | ||||
| c/rfc/bibxml3/reference.I-D.draft-ietf-anima-prefix-management-07.xml"> | ||||
| <!ENTITY I-D.ietf-anima-prefix-management SYSTEM "https://xml2rfc.ietf.org/publi | ||||
| c/rfc/bibxml3/reference.I-D.ietf-anima-prefix-management.xml"> | ||||
| ]> | ||||
| <rfc submissionType="IETF" docName="draft-irtf-nmrg-ibn-intent-classification-08 | ||||
| " category="info" ipr="trust200902"> | ||||
| <!-- Generated by id2xml 1.5.0 on 2022-06-23T22:24:54Z --> | ||||
| <?rfc strict="yes"?> | ||||
| <?rfc compact="yes"?> | ||||
| <?rfc subcompact="no"?> | ||||
| <?rfc symrefs="yes"?> | ||||
| <?rfc sortrefs="no"?> | ||||
| <?rfc text-list-symbols="oo*+-"?> | ||||
| <?rfc toc="yes"?> | ||||
| <front> | ||||
| <title>Intent Classification</title> | ||||
| <author initials="C." surname="Li" fullname="Chen Li"> | ||||
| <organization>China Telecom</organization> | ||||
| <address><postal><street>No.118 Xizhimennei street, Xicheng District</str | ||||
| eet> | ||||
| <city>Beijing</city> | ||||
| <code>100035</code> | ||||
| <country>P.R. China</country> | ||||
| </postal> | ||||
| <email>lichen.bri@chinatelecom.cn</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="O." surname="Havel" fullname="Olga Havel"> | ||||
| <organization>Huawei Technologies</organization> | ||||
| <address><postal> | ||||
| <street></street> | ||||
| <country>Ireland</country> | ||||
| </postal> | ||||
| <email>olga.havel@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="A." surname="Olariu" fullname="Adriana Olariu"> | ||||
| <organization>Huawei Technologies</organization> | ||||
| <address><postal> | ||||
| <street></street> | ||||
| <country>Ireland</country> | ||||
| </postal> | ||||
| <email>adriana.olariu@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="P." surname="Martinez-Julia" fullname="Pedro Martinez-J | ||||
| ulia"> | ||||
| <organization>NICT</organization> | ||||
| <address><postal> | ||||
| <street></street> | ||||
| <country>Japan</country> | ||||
| </postal> | ||||
| <email>pedro@nict.go.jp</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="J." surname="Nobre" fullname="Jeferson Campos Nobre"> | <!DOCTYPE rfc [ | |||
| <organization abbrev="UFRGS">Federal University of Rio Grande do Sul</org | <!ENTITY nbsp " "> | |||
| anization> | <!ENTITY zwsp "​"> | |||
| <address><postal> | <!ENTITY nbhy "‑"> | |||
| <street></street> | <!ENTITY wj "⁠"> | |||
| <city>Porto Alegre</city> | ]> | |||
| <country>Brazil</country> | ||||
| </postal> | ||||
| <email>jcnobre@inf.ufrgs.br</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="D." surname="Lopez" fullname="Diego R. Lopez"> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category=" | |||
| <organization abbrev="Telefonica, I+D">Telefonica I+D</organization> | info" consensus="true" docName="draft-irtf-nmrg-ibn-intent-classification-08" nu | |||
| <address><postal><street>Don Ramon de la Cruz, 82</street> | mber="9316" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="tru | |||
| <city>Madrid</city> | e" sortRefs="true" tocInclude="true" version="3"> | |||
| <code>28006</code> | ||||
| <country>Spain</country> | ||||
| </postal> | ||||
| <email>diego.r.lopez@telefonica.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <date year="2022" month="June"/> | <front> | |||
| <title>Intent Classification</title> | ||||
| <seriesInfo name="RFC" value="9316"/> | ||||
| <author initials="C." surname="Li" fullname="Chen Li"> | ||||
| <organization>China Telecom</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <extaddr>Xicheng District</extaddr> | ||||
| <street>No.118 Xizhimennei street</street> | ||||
| <city>Beijing</city> | ||||
| <code>100035</code> | ||||
| <country>China</country> | ||||
| </postal> | ||||
| <email>lichen6@chinatelecom.cn</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="O." surname="Havel" fullname="Olga Havel"> | ||||
| <organization>Huawei Technologies</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <street/> | ||||
| <country>Ireland</country> | ||||
| </postal> | ||||
| <email>olga.havel@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="A." surname="Olariu" fullname="Adriana Olariu"> | ||||
| <organization>Huawei Technologies</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <street/> | ||||
| <country>Ireland</country> | ||||
| </postal> | ||||
| <email>adriana.olariu@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="P." surname="Martinez-Julia" fullname="Pedro Martinez-Juli | ||||
| a"> | ||||
| <organization>NICT</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <street/> | ||||
| <country>Japan</country> | ||||
| </postal> | ||||
| <email>pedro@nict.go.jp</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="J." surname="Nobre" fullname="Jeferson Campos Nobre"> | ||||
| <organization abbrev="UFRGS">Federal University of Rio Grande do Sul (UFRG | ||||
| S)</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <street/> | ||||
| <city>Porto Alegre</city> | ||||
| <region>RS</region> | ||||
| <country>Brazil</country> | ||||
| </postal> | ||||
| <email>jcnobre@inf.ufrgs.br</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="D." surname="Lopez" fullname="Diego R. Lopez"> | ||||
| <organization abbrev="Telefonica, I+D">Telefonica I+D</organization> | ||||
| <address> | ||||
| <postal> | ||||
| <street>Don Ramon de la Cruz, 82</street> | ||||
| <city>Madrid</city> | ||||
| <code>28006</code> | ||||
| <country>Spain</country> | ||||
| </postal> | ||||
| <email>diego.r.lopez@telefonica.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <date year="2022" month="October"/> | ||||
| <workgroup>Network Management</workgroup> | ||||
| <workgroup>Network Management</workgroup> | <keyword>intent taxonomy</keyword> | |||
| <keyword>intent-based network</keyword> | ||||
| <keyword>intent users</keyword> | ||||
| <keyword>intent categories</keyword> | ||||
| <keyword>intent types</keyword> | ||||
| <keyword>network management</keyword> | ||||
| <keyword>network automation</keyword> | ||||
| <keyword>network intent</keyword> | ||||
| <keyword>network service</keyword> | ||||
| <keyword>network orchestration</keyword> | ||||
| <keyword>intent translation</keyword> | ||||
| <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> | <abstract> | |||
| <keyword>example</keyword> | <t> | |||
| <abstract><t> | Intent is an abstract, high-level policy used to operate a network. | |||
| Intent is an abstract, high-level policy used to operate the network. | An intent-based management system includes an interface for users to | |||
| Intent-based management system includes an interface for users to | ||||
| input requests and an engine to translate the intents into the | input requests and an engine to translate the intents into the | |||
| network configuration and manage their life-cycle.</t> | network configuration and manage their life cycle.</t> | |||
| <t> | ||||
| <t> | This document mostly discusses the concept of network intents, but | |||
| This document discusses mostly the concept of network intents, but | other types of intents are also considered. Specifically, this document | |||
| other types of intents are also being considered. Specifically, it | ||||
| highlights stakeholder perspectives of intent, methods to classify | highlights stakeholder perspectives of intent, methods to classify | |||
| and encode intent, the associated intent taxonomy, and defines | and encode intent, and the associated intent taxonomy; it also defines | |||
| relevant intent terms where necessary. This document provides a | relevant intent terms where necessary, provides a | |||
| foundation for intent related research and facilitates solution | foundation for intent-related research, and facilitates solution | |||
| development.</t> | development.</t> | |||
| <t> | ||||
| <t> | ||||
| This document is a product of the IRTF Network Management Research | This document is a product of the IRTF Network Management Research | |||
| Group (NMRG).</t> | Group (NMRG).</t> | |||
| </abstract> | ||||
| </front> | ||||
| <middle> | ||||
| <section anchor="sect-1" numbered="true" toc="default"> | ||||
| <name>Introduction</name> | ||||
| </abstract> | <t> | |||
| </front> | The vision of intent-based networks has attracted a lot of attention | |||
| because it promises to simplify the management of networks by human | ||||
| <middle> | ||||
| <section title="Introduction" anchor="sect-1"><t> | ||||
| The vision of intent-based networks has attracted a lot of attention, | ||||
| as it promises to simplify the management of networks by human | ||||
| operators. This is done by simply specifying what should happen on | operators. This is done by simply specifying what should happen on | |||
| the network, without giving any instructions on how to do it. This | the network without giving any instructions on how to do it. This | |||
| promise led many researcher-led activities and telecom companies to | promise caused many researcher-led activities and telecom companies to | |||
| start researching this new vision, and many Standards Development | start researching this new vision and many Standards Development | |||
| Organization (SDOs) to propose different intent frameworks.</t> | Organizations (SDOs) to propose different intent frameworks.</t> | |||
| <t> | ||||
| <t> | This document proposes an intent classification methodology and an | |||
| This draft proposes an intent classification methodology and an | ||||
| intent taxonomy. The scope of these proposals is to ensure a common | intent taxonomy. The scope of these proposals is to ensure a common | |||
| understanding in the research community in terms of what are the | understanding in the research community in terms of what the | |||
| intent users, intent types, or intent solutions, etc. for specific | intent users, intent types, or intent solutions, etc., are for specific | |||
| scenarios that are being considered.</t> | scenarios that are being considered.</t> | |||
| <t> | ||||
| <t> | ||||
| The document represents the consensus of the Network Management | The document represents the consensus of the Network Management | |||
| Research Group (NMRG). It has been reviewed extensively by the | Research Group (NMRG). It has been reviewed extensively by the | |||
| Research Group (RG) members who are actively involved in the research | Research Group (RG) members who are actively involved in the research | |||
| and development of the technology covered by this document. It is not | and development of the technology covered by this document. It is not | |||
| an IETF product and is not a standard.</t> | an IETF product and is not a standard.</t> | |||
| <section anchor="sect-1.1" numbered="true" toc="default"> | ||||
| <section title="Research activities" anchor="sect-1.1"><t> | <name>Research Activities</name> | |||
| Intent-based networking is an active research topic which spans | <t> | |||
| Intent-based networking is an active research topic spanning | ||||
| across different areas that could benefit from an intent | across different areas that could benefit from an intent | |||
| classification and taxonomy.</t> | classification and taxonomy.</t> | |||
| <t> | <t>Some examples include: | |||
| One such area is intent expression and recognition ([Bezahaf21], | </t> | |||
| [Bezahaf19]), NILE [Jacobs18]). The use of a common classification | ||||
| can provide consistency in the understanding of the various forms of | ||||
| intent expressions being proposed and investigated.</t> | ||||
| <t> | <ul> | |||
| Another area where this intent classification could contribute is the | <li> | |||
| orchestration of cognitive autonomous RANs [Banerjee21] where intents | intent expression and recognition (<xref | |||
| are classified based on their content.</t> | target="Bezahaf21" format="default"/>, <xref target="Bezahaf19" | |||
| format="default"/>, <xref target="Jacobs18" format="default"/>). | ||||
| The use of a common classification could provide consistency in the | ||||
| understanding of the various forms of intent expressions being proposed and | ||||
| investigated. | ||||
| <t> | </li> | |||
| The work carried in intent network verification <xref target="Tian19"/> where | ||||
| the | ||||
| authors are proposing new intent language is another candidate where | ||||
| intent classification could be used advantageously.</t> | ||||
| <t> | <li> | |||
| Furthermore, this draft is proving itself already extremely relevant | the orchestration of cognitive autonomous radio access networks (RANs) <xref | |||
| to the research community as it has been used as the basis for | target="Banerjee21" format="default"/> where intents are | |||
| proposing self-generated Intent-based systems [Bezhaf19], for | classified based on their content. | |||
| advancing IBN-based VNF placement solutions that rely on defining | ||||
| user intent profiles corresponding to abstract network services | ||||
| [Leivadeas21], for improving existing solutions in provisioning | ||||
| intent-based networks, and proposing new approaches to service | ||||
| management <xref target="Davoli21"/>, or even for defining grammars for users | ||||
| to | ||||
| specify the high-level requirements for blockchain selection in the | ||||
| form of intent <xref target="Padovan20"/>. As well, the draft has been mentio | ||||
| ned in | ||||
| surveys addressing the topic of intelligent intent-based autonomous | ||||
| networks <xref target="Mehmood21"/>, <xref target="Szilagyi21"/>.</t> | ||||
| <t> | </li> | |||
| This document describes as well an example on how this proposal has | ||||
| been successfully applied in an academic environment [IBN-POC] by | ||||
| researchers in the area of SDN/NFV for defining the scope of their | ||||
| project. The specific problem addressed by researches is how to | ||||
| apply intent concepts at different levels that correspond to | ||||
| different stakeholders.</t> | ||||
| <t> | <li> | |||
| IEEE Communications Society Technical Committee on Network Operation | intent network verification <xref target="Tian19" | |||
| and Management (IEEE-CNOM), IRTF-NMRG and IFIP WG6.6 have developed a | format="default"/>, where the authors are working to propose new | |||
| taxonomy for network and service management [IFIP-NSM] that is used | intent language. | |||
| by the research community in network management and operations to | ||||
| structure the research area through a well-defined set of keywords | ||||
| and to improve quality of reviews in submissions to journals, | ||||
| conferences and workshops. The proposed intent taxonomy may be | ||||
| contributed as an extension to this taxonomy for intent driven | ||||
| management.</t> | ||||
| </section> | </li> | |||
| <section title="Standards and open source activities" anchor="sect-1.2">< | </ul> | |||
| t> | ||||
| Several SDOs and open source projects, such as Internet Research Task | <t> | |||
| Force (IRTF)/ Network Management Research Group (NMRG), Open | ||||
| Networking Foundation (ONF) [ONF] / Open Network Operating System | Furthermore, this document is already proving to be extremely relevant to the | |||
| (ONOS) [ONOS], European Telecommunications Standards Institute | research community as it has been used as the basis for proposing | |||
| (ETSI)/Experiential Networked Intelligence (ENI), TMF with its | self-generated Intent-based systems <xref target="Bezahaf19" | |||
| Autonomous Networks, have proposed intents for defining a set of | format="default"/>, for advancing Virtual Network Function (VNF) placement so | |||
| network operations to execute in a declarative manner.</t> | lutions based on Internet-Based Networks (IBNs) that rely on defining user inten | |||
| t profiles corresponding to abstract network | ||||
| services <xref target="Leivadeas21" format="default"/>, for improving | ||||
| existing solutions in provisioning intent-based networks, for proposing new | ||||
| approaches to service management <xref target="Davoli21" | ||||
| format="default"/>, and even for defining grammars for users to specify the | ||||
| high-level requirements for blockchain selection in the form of intent | ||||
| <xref target="Padovan20" format="default"/>. As well, the document has been | ||||
| mentioned in surveys addressing the topic of intelligent intent-based | ||||
| autonomous networks <xref target="Mehmood21" format="default"/> <xref | ||||
| target="Szilagyi21" format="default"/>.</t> | ||||
| <t> | ||||
| This document also describes an example on how this proposal has been | ||||
| successfully applied in an academic environment <xref target="POC-IBN" | ||||
| format="default"/> by researchers in the area of Software-Defined Networking | ||||
| / Network Function Virtualization (SDN/NFV) for defining the | ||||
| scope of their project. The specific problem addressed by researchers is how | ||||
| to apply intent concepts at different levels that correspond to different | ||||
| stakeholders.</t> | ||||
| <t> | ||||
| The IEEE Communications Society Technical Committee on Network Operation and | ||||
| Management (IEEE-CNOM), IRTF Network Management Research Group, and IFIP WG6. | ||||
| 6 have developed a taxonomy | ||||
| for network and service management <xref target="IFIP-NSM" | ||||
| format="default"/> that is used by the research community in network | ||||
| management and operations to structure the research area through a | ||||
| well-defined set of keywords and to improve quality of reviews in | ||||
| submissions to journals, conferences, and workshops. The proposed intent | ||||
| taxonomy may be contributed as an extension to this taxonomy for intent-drive | ||||
| n management.</t> | ||||
| </section> | ||||
| <section anchor="sect-1.2" numbered="true" toc="default"> | ||||
| <name>Standards and Open-Source Activities</name> | ||||
| <t> | <t> | |||
| More recently, the IRTF NMRG is working on the Intent-based Networking - | Several SDOs and open-source projects, such as the IRTF NMRG, Open Networking | |||
| Concepts and Definitions document, <xref | Foundation (ONF) <xref target="ONF" format="default"/> / Open Network | |||
| target="I-D.irtf-nmrg-ibn-concepts-definitions"/>. This document clarifies | Operating System (ONOS) <xref target="ONOS" format="default"/>, European | |||
| Telecommunications Standards Institute (ETSI) / Experiential Networked | ||||
| Intelligence (ENI), and TMF with its autonomous networks, have proposed inten | ||||
| ts | ||||
| for defining a set of network operations to execute in a declarative | ||||
| manner.</t> | ||||
| <t> | ||||
| More recently, the IRTF NMRG is working on "Intent-Based Networking - | ||||
| Concepts and Definitions" <xref target="RFC9315" format="default"/>. This doc | ||||
| ument clarifies | ||||
| the concept of "Intent" and provides an overview of the functionality that | the concept of "Intent" and provides an overview of the functionality that | |||
| is associated with it. The goal is to contribute towards a common and | is associated with it. The goal is to contribute towards a common and | |||
| shared understanding of terms, concepts, and functionality that can be used | shared understanding of terms, concepts, and functionality that can be used | |||
| as the foundation to guide further definition of associated research and | as the foundation to guide further definition of associated research and | |||
| engineering problems and their solutions.</t> | engineering problems and their solutions.</t> | |||
| <t> | ||||
| <t> | The present document, together with <xref target="RFC9315" format="default"/> | |||
| The present document, together with <xref | , aims to become the | |||
| target="I-D.irtf-nmrg-ibn-concepts-definitions"/>, aims to become the | ||||
| foundation for future intent-related topic discussions regarding the | foundation for future intent-related topic discussions regarding the | |||
| NMRG.</t> | NMRG.</t> | |||
| <t> | <t> | |||
| The SDOs usually came up with their own way of specifying an intent, and | The SDOs usually come up with their own way of specifying an intent and | |||
| with their own understanding of what an intent is. Besides that, each SDO | their own understanding of what an intent is. | |||
| defines a set of terms and level of abstraction, its intended intent users, | ||||
| and the applications and usage scenarios.</t> | ||||
| <t> | Additionally, each SDO defines a set of terms and level of abstraction, its i | |||
| However, most intent approaches proposed by SDOs share the same following | ntent users, and the applications and usage scenarios. | |||
| features:</t> | ||||
| <t><list style="symbols"><t>It must be declarative in nature, meaning tha | </t> | |||
| t an intent user | <t> | |||
| However, most intent approaches proposed by SDOs share the same features:</t> | ||||
| <ul spacing="normal"> | ||||
| <li>It must be declarative in nature, meaning that an intent user | ||||
| specifies the goal on the network without specifying how to achieve | specifies the goal on the network without specifying how to achieve | |||
| that goal.</t> | that goal.</li> | |||
| <li>It must be vendor agnostic in the sense that it abstracts the | ||||
| <t>It must be vendor agnostic, in the sense that it abstracts the | network capabilities or the network infrastructure from the intent | |||
| network capabilities, or the network infrastructure from the intent | user, and it can be ported across different platforms.</li> | |||
| user, and it can be ported across different platforms.</t> | <li>It must provide an easy-to-use interface, which simplifies the | |||
| interaction of the intent users with the intent system through the usage | ||||
| <t>It must provide an easy-to-use interface, which simplifies the | of familiar terminology or concepts.</li> | |||
| intent users' interaction with the intent system through the usage | ||||
| of familiar terminology or concepts.</t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | <li> | |||
| It should be able to detect and resolve intent conflicts, which | It should be able to detect and resolve intent conflicts, which include, | |||
| include, for example, static (compile-time) conflicts and dynamic | for example, static (compile-time) conflicts and dynamic (run-time) | |||
| (run-time) conflicts.</t> | conflicts. | |||
| </li> | ||||
| </ul> | ||||
| </section> | </section> | |||
| <section anchor="sect-1.3" numbered="true" toc="default"> | ||||
| <name>Scope</name> | ||||
| <section title="Scope" anchor="sect-1.3"><t> | <t> | |||
| The focus of this document is on the definition of criteria enabling | The focus of this document is on the definition of criteria enabling | |||
| to categorize intents from the stakeholders' viewpoint. Concepts and | the categorization of intents from viewpoint of the stakeholders. Concepts a | |||
| definitions related to IBN are provided in <xref target="I-D.irtf-nmrg-ibn-co | nd | |||
| ncepts-definitions"/>.</t> | definitions related to IBN are provided in <xref target="RFC9315" format="def | |||
| ault"/>.</t> | ||||
| <t> | <t> | |||
| This document mostly addresses intents in the context of network | This document mostly addresses intents in the context of network | |||
| intents, however other types of intents are not excluded, as | intents; however, other types of intents are not excluded, as | |||
| presented in section 4.4. and section 6.2. .</t> | presented in Sections <xref target="sect-4.4" format="counter"/> and <xref ta | |||
| rget="sect-6.2" format="counter"/>.</t> | ||||
| <t> | <t> | |||
| It is impossible to fully differentiate intents only by the common | It is impossible to fully differentiate intents only by the common | |||
| characteristics followed by concepts, terms and intentions. This | characteristics followed by concepts, terms, and intentions. This | |||
| document clarifies what an intent represents for different | document clarifies what an intent represents for different | |||
| stakeholders through a classification on various dimensions, such as | stakeholders through a classification on various dimensions, such as | |||
| solutions, intent users, and intent types. This classification | solutions, intent users, and intent types. This classification | |||
| ensures common understanding among all participants and is used to | ensures common understanding among all participants and is used to | |||
| determine the scope and priority of individual projects, | determine the scope and priority of individual projects, | |||
| proof-of-concept (PoCs), research initiatives, or open source projects.</t> | proof of concepts (PoCs), research initiatives, or open-source projects.</t> | |||
| <t> | ||||
| <t> | ||||
| The scope of intent classification in this document includes | The scope of intent classification in this document includes | |||
| solutions, intent users and intent types, and the initial | solutions, intent users, and intent types; the initial | |||
| classification table is made according to this scope. The | classification table is made according to this scope. The | |||
| methodology presented can be used to update the classification | methodology presented can be used to update the classification | |||
| tables by adding or removing different solutions, intent users, or | tables by adding or removing different solutions, intent users, or | |||
| intent types to cater for future scenarios, applications or domains.</t> | intent types to cater to future scenarios, applications, or domains.</t> | |||
| </section> | ||||
| </section> | ||||
| <section anchor="sect-2" numbered="true" toc="default"> | ||||
| <name>Abbreviations</name> | ||||
| </section> | <dl> | |||
| <dt>AI: | ||||
| </dt> | ||||
| <dd>Artificial Intelligence | ||||
| </dd> | ||||
| </section> | <dt>CE: | |||
| </dt> | ||||
| <dd> Customer Equipment | ||||
| </dd> | ||||
| <section title="Acronyms" anchor="sect-2"><t> | <dt>CFS: | |||
| </dt> | ||||
| <dd>Customer Facing Service | ||||
| </dd> | ||||
| <list> | <dt>CLI: | |||
| <t>AI: Artificial Intelligence</t> | </dt> | |||
| <t>CE: Customer Equipment</t> | <dd>Command-Line Interface | |||
| <t>CFS: Customer Facing Service</t> | </dd> | |||
| <t>CLI: Command Line Interface</t> | ||||
| <t>DB: Database</t> | ||||
| <t>DC: Data Center</t> | ||||
| <t>ECA: Event-Condition-Action</t> | ||||
| <t>GBP: Group-Based Policy</t> | ||||
| <t>GPU: Graphics Processing Unit</t> | ||||
| <t>IBN: Intent Based Network</t> | ||||
| <t>NFV: Network Function Virtualization</t> | ||||
| <t>O&M: Operations & Maintenance</t> | ||||
| <t>ONF: Open Networking Foundation</t> | ||||
| <t>ONOS: Open Network Operating System</t> | ||||
| <t>PNF: Physical Network Function</t> | ||||
| <t>QoE: Quality of Experience</t> | ||||
| <t>RFS: Resource Facing Service</t> | ||||
| <t>SDO: Standards Development Organization</t> | ||||
| <t>SD-WAN: Software-Defined Wide-Area Network</t> | ||||
| <t>SLA: Service Level Agreement</t> | ||||
| <t>SUPA: Simplified Use of Policy Abstractions</t> | ||||
| <t>VM: Virtual Machine</t> | ||||
| <t>VNF: Virtual Network Function</t> | ||||
| </list> | ||||
| </t> | ||||
| </section> | <dt>DB: | |||
| </dt> | ||||
| <dd>Database | ||||
| </dd> | ||||
| <section title="Definitions" anchor="sect-3"><t> | <dt>DC: | |||
| A common and shared understanding of terms and definitions related | </dt> | |||
| to IBN is provided in <xref target="I-D.irtf-nmrg-ibn-concepts-definitions"/> | <dd>Data Center | |||
| , as follows: | </dd> | |||
| <list style="hanging" hangIndent="3"> | <dt>ECA: | |||
| </dt> | ||||
| <dd>Event Condition Action | ||||
| </dd> | ||||
| <t hangText="Intent:">A set of operational goals (that a network should meet) | <dt>GBP: | |||
| and outcomes (that a network is supposed to deliver), defined | </dt> | |||
| in a declarative manner without specifying how to achieve or | <dd>Group-Based Policy | |||
| implement them.</t> | </dd> | |||
| <t hangText="Intent-Based Network:">A network that can be managed using inten | <dt>GPU: | |||
| t.</t> | </dt> | |||
| <dd>Graphics Processing Unit | ||||
| </dd> | ||||
| <t hangText="Policy:">A set of rules that governs the choices in behaviour of | <dt>IBN: | |||
| a system.</t> | </dt> | |||
| <dd>Intent-Based Network | ||||
| </dd> | ||||
| <t hangText="Intent User:">A user that defines and issues the intent request | <dt>NFV: | |||
| to the | </dt> | |||
| intent-based management system.</t> | <dd>Network Function Virtualization | |||
| </dd> | ||||
| </list> | <dt>O&M: | |||
| </t> | </dt> | |||
| <dd>OAM & Maintenance | ||||
| </dd> | ||||
| <t> | <dt>ONF: | |||
| Other definitions relevant to this draft, such as intent scope, | </dt> | |||
| intent network scope, intent abstraction, intent abstraction, and | <dd>Open Networking Foundation | |||
| intent lifecycle are available in section 5.</t> | </dd> | |||
| </section> | <dt>ONOS: | |||
| </dt> | ||||
| <dd>Open Network Operating System | ||||
| </dd> | ||||
| <section title="Abstract Intent Requirements" anchor="sect-4"><t> | <dt>PNF: | |||
| </dt> | ||||
| <dd>Physical Network Function | ||||
| </dd> | ||||
| <dt>QoE: | ||||
| </dt> | ||||
| <dd>Quality of Experience | ||||
| </dd> | ||||
| <dt>RFS: | ||||
| </dt> | ||||
| <dd>Resource Facing Service | ||||
| </dd> | ||||
| <dt>SDO: | ||||
| </dt> | ||||
| <dd>Standards Development Organization | ||||
| </dd> | ||||
| <dt>SD-WAN: | ||||
| </dt> | ||||
| <dd>Software-Defined Wide-Area Network | ||||
| </dd> | ||||
| <dt>SLA: | ||||
| </dt> | ||||
| <dd>Service Level Agreement | ||||
| </dd> | ||||
| <dt>SUPA: | ||||
| </dt> | ||||
| <dd>Simplified Use of Policy Abstractions | ||||
| </dd> | ||||
| <dt>VM: | ||||
| </dt> | ||||
| <dd>Virtual Machine | ||||
| </dd> | ||||
| <dt>VNF: | ||||
| </dt> | ||||
| <dd>Virtual Network Function | ||||
| </dd> | ||||
| </dl> | ||||
| </section> | ||||
| <section anchor="sect-3" numbered="true" toc="default"> | ||||
| <name>Definitions</name> | ||||
| <t> | ||||
| A common and shared understanding of terms and definitions related | ||||
| to IBN is provided in <xref target="RFC9315" format="default"/> as follows: | ||||
| </t> | ||||
| <dl newline="false" spacing="normal" indent="3"> | ||||
| <dt>Intent:</dt> | ||||
| <dd>A set of operational goals (that a network should meet) | ||||
| and outcomes (that a network is supposed to deliver) defined | ||||
| in a declarative manner without specifying how to achieve or | ||||
| implement them.</dd> | ||||
| <dt>Intent-Based Network:</dt> | ||||
| <dd>A network that can be managed using intent.</dd> | ||||
| <dt>Policy:</dt> | ||||
| <dd>A set of rules that governs the choices in behavior of a system.</dd | ||||
| > | ||||
| <dt>Intent User:</dt> | ||||
| <dd>A user that defines and issues the intent request to the | ||||
| intent-based management system.</dd> | ||||
| </dl> | ||||
| <t> | ||||
| Other definitions relevant to this document, such as intent scope, | ||||
| intent network scope, intent abstraction, intent abstraction, and | ||||
| intent life cycle are available in <xref target="sect-5"/>.</t> | ||||
| </section> | ||||
| <section anchor="sect-4" numbered="true" toc="default"> | ||||
| <name>Abstract Intent Requirements</name> | ||||
| <t> | ||||
| In order to understand the different intent requirements that would | In order to understand the different intent requirements that would | |||
| drive intent classification, we first need to understand what intent | drive intent classification, we first need to understand what intent | |||
| means for different intent users.</t> | means for different intent users.</t> | |||
| <section anchor="sect-4.1" numbered="true" toc="default"> | ||||
| <section title="What is Intent?" anchor="sect-4.1"><t> | <name>What is intent?</name> | |||
| The term Intent has become very widely used in the industry for | <t> | |||
| different purposes, sometimes it is not even in agreement with SDO | The term "Intent" has become very widely used in the industry for different | |||
| shared principles mentioned in the Introduction section.<xref target="I-D.irt | purposes; sometimes its use is not even in agreement with SDO-shared principl | |||
| f-nmrg-ibn-concepts-definitions"/> draft | es | |||
| brings clarification with relation to what an intent is and how it | mentioned in <xref target="sect-1" format="default"></xref>. <xref target="RF | |||
| differentiates from policies and services.</t> | C9315" | |||
| format="default"/> brings clarification with relation to what an intent is | ||||
| <t> | and how it differentiates from policies and services.</t> | |||
| Different stakeholders have different perspective of the network and | <t> | |||
| therefore have different intent requirements. Their intent is sometimes | Different stakeholders have different perspectives of the network; | |||
| technical, non-technical, abstract or technology specific. Therefore, it | therefore, they have different intent requirements. Their intent is sometimes | |||
| is important to start a discussion in the industry and academia communities | technical, non-technical, abstract, or technology specific. Therefore, it | |||
| is important to start a discussion in the industry and academic communities | ||||
| about what intent is for different solutions and intent users. It is also | about what intent is for different solutions and intent users. It is also | |||
| imperative to try to propose some intent categories/ classifications that | imperative to try to propose some intent categories/classifications that | |||
| could be understood by a wider audience. This would help us define intent | could be understood by a wider audience. This would help us define intent | |||
| interfaces, domain-specific languages, and models.</t> | interfaces, domain-specific languages, and models.</t> | |||
| </section> | ||||
| </section> | <section anchor="sect-4.2" numbered="true" toc="default"> | |||
| <name>Intent Solutions and Intent Users</name> | ||||
| <section title="Intent Solutions and Intent Users" anchor="sect-4.2"><t> | <t> | |||
| Intent types are defined by all aspects that are required to profile | Intent types are defined by all aspects that are required to profile | |||
| different requirements to easily distinguish among them. However, in order | different requirements to easily distinguish between them. However, in order | |||
| to facilitate a clustered classification, we can focus on two aspects, the | to facilitate a clustered classification, we can focus on two aspects: the | |||
| solution and intent user. They can be considered as the main keys to | solution and intent user. They can be considered to be the main keys to | |||
| classify intents, as we can easily group requirements by solution and intent | classify intents, as we can easily group requirements by solution and intent | |||
| user.</t> | user.</t> | |||
| <t> | ||||
| <t> | ||||
| On the one hand, different solutions and intent users have different | On the one hand, different solutions and intent users have different | |||
| requirements, expectations and priorities for intent-based | requirements, expectations, and priorities for intent-based | |||
| networking. Therefore, intent users require different intent types, | networking. Therefore, intent users require different intent types, | |||
| depending on their context, since they participate in different use | depending on their context, since they participate in different use | |||
| cases. For instance, some intent users are more technical and require | cases. For instance, some intent users are more technical and require | |||
| intents that expose more technical information. Other intent users do not | intents that expose more technical information. Other intent users do not | |||
| have knowledge of the network infrastructure and require intents that shield | have knowledge of the network infrastructure and require intents that shield | |||
| them from different networking concepts and technologies.</t> | them from different networking concepts and technologies.</t> | |||
| <t> | ||||
| <t> | ||||
| The following are the solutions and intent users that intent-based | The following are the solutions and intent users that intent-based | |||
| networking needs to support:</t> | networking needs to support:</t> | |||
| <table anchor="tab-intent-solutions-and-intent-users" align="center"> | ||||
| <name>Intent Solutions and Intent Users</name> | ||||
| <thead> | ||||
| <tr> | ||||
| <th align="left"> Solutions</th> | ||||
| <th align="left"> Intent Users</th> | ||||
| </tr> | ||||
| </thead> | ||||
| <tbody> | ||||
| <tr> | ||||
| <td align="left">Carrier Networks </td> | ||||
| <texttable title="- Intent Solutions and Intent Users" anchor="tab-intent | <td align="left">Network Operators, Service Designers / App Develop | |||
| -solutions-and-intent-users" style="all"><ttcol> Solutions</ttcol> | ers, Service Operators, Customers / Subscribers</td> | |||
| <ttcol> Intent Users</ttcol> | </tr> | |||
| <c>Carrier Networks </c> | <tr> | |||
| <c>Network Operator Service Designers/App Developer Service Operators Cus | <td align="left">DC Networks </td> | |||
| tomers/Subscribers</c> | <td align="left">Cloud Administrators, Underlay Network Administra | |||
| <c>DC Networks </c> | tors, Application Developers, Customers / Tenants</td> | |||
| <c>Cloud Administrator Underlay Network Administrator Application Develop | </tr> | |||
| ers Customer/Tenants</c> | <tr> | |||
| <c>Enterprise Networks </c> | <td align="left">Enterprise Networks </td> | |||
| <c>Enterprise Administrator Application Developers End-Users</c> | <td align="left">Enterprise Administrators, Application Developers | |||
| </texttable> | , End Users</td> | |||
| <t> | </tr> | |||
| </tbody> | ||||
| </table> | ||||
| <t> | ||||
| These intent solutions and intent users represent a starting point | These intent solutions and intent users represent a starting point | |||
| for the classification and are expendable through the methodology | for the classification and are expendable through the methodology | |||
| presented in section 6.1. .</t> | presented in <xref target="sect-6.1"/>.</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>For carrier networks scenario, for example, i f a | <li>For carrier network scenarios, for example, if a | |||
| customer/subscriber wants to watch high-definition video, then the | customer/subscriber wants to watch high-definition video, then the | |||
| intent is to convert the video image to 1080p rate.</t> | intent is to convert the video image to 1080p.</li> | |||
| <li>For DC network scenarios, administrators have their own clear | ||||
| <t>For DC networks scenario, administrators have their own clear | ||||
| network intent such as load balancing. For all traffic flows that | network intent such as load balancing. For all traffic flows that | |||
| need NFV service chaining, restrict the maximum load of any VNF | need NFV service chaining, they can restrict the maximum load of any VNF | |||
| node/container below 50% and the maximum load of any network link | node / container below 50% and the maximum load of any network link | |||
| below 70%.</t> | below 70%.</li> | |||
| <li>For enterprise network scenarios, when hosting a video conference, | ||||
| <t>For enterprise networks scenario, when hosting a video conference | ||||
| multiple remote accesses are required. An example of the intent | multiple remote accesses are required. An example of the intent | |||
| from the network administrator is: for any end-user of this | from the network administrator is as follows: for any end user of this | |||
| application, the arrival time of hologram objects of all the | application, the arrival time of hologram objects of all the | |||
| remote tele-presenters should be synchronised within 50ms to reach | remote tele-presenters should be synchronized within 50 ms to reach | |||
| the destination viewer for each conversation session.</t> | the destination viewer for each conversation session.</li> | |||
| </ul> | ||||
| <t></t> | ||||
| </list> | ||||
| </t> | ||||
| </section> | ||||
| <section title="Benefits of Intents for Different Stakeholders" anchor="s | </section> | |||
| ect-4.3"><t> | <section anchor="sect-4.3" numbered="true" toc="default"> | |||
| <name>Benefits of Intents for Different Stakeholders</name> | ||||
| <t> | ||||
| Current network APIs and CLIs are too complex because they are highly | Current network APIs and CLIs are too complex because they are highly | |||
| integrated with the low level concepts exposed by networks. Customers, | integrated with the low-level concepts exposed by networks. | |||
| application developers and end-users must not be required to set IP | ||||
| addresses, VLANs, subnets, ports, while operators may still want to have | ||||
| more technical and network visibility. All stakeholders would benefit from | ||||
| the simpler interfaces, like:</t> | ||||
| <t><list style="symbols"><t>Request gold VPN service between my sites A, | ||||
| B and C</t> | ||||
| <t>Provide CE redundancy for the customer sites</t> | Customers, application developers, and end users must not be required to set | |||
| IP addresses, VLANs, subnets, or ports, whereas operators may still want to | ||||
| have both more technical and network visibility. | ||||
| <t>Add access rules to the network service</t> | All stakeholders would benefit from simpler interfaces, such as:</t> | |||
| </list> | <ul spacing="normal"> | |||
| </t> | <li>request gold VPN service between sites A, B, and C</li> | |||
| <li>provide CE redundancy for the customer sites</li> | ||||
| <li>add access rules to the network service</li> | ||||
| </ul> | ||||
| <t> | ||||
| <t> | ||||
| Operators and administrators manually troubleshoot and fix their networks | Operators and administrators manually troubleshoot and fix their networks | |||
| and services. They instead want to:</t> | and services. They instead want to:</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>simplify and automate network operations</t> | <li>simplify and automate network operations</li> | |||
| <li>simplify definitions of network services</li> | ||||
| <t>simplify definitions of network services</t> | <li>provide simple customer APIs for value-added services (operators)< | |||
| /li> | ||||
| <t>provide simple customer APIs for value added services (operators)</t> | <li>be informed if the network or service is not behaving as requested | |||
| </li> | ||||
| <t>be informed if the network or service is not behaving as requested</t> | <li>enable automatic optimization and correction for selected scenario | |||
| s</li> | ||||
| <t>enable automatic optimization and correction for selected scenarios</t | <li>have systems that learn from historic information and behavior</li | |||
| > | > | |||
| </ul> | ||||
| <t>have systems that learn from historic information and behaviour</t> | <t> | |||
| </list> | ||||
| </t> | ||||
| <t> | ||||
| Currently, intent users cannot build their own services and policies | Currently, intent users cannot build their own services and policies | |||
| without becoming technical experts and performing manual maintenance | without becoming technical experts and performing manual maintenance | |||
| actions. They instead want to be able to:</t> | actions. They instead want to be able to:</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>build their own network services with their o | <li>build their own network services with their own policies via | |||
| wn policies via | simple interfaces, without becoming networking experts</li> | |||
| simple interfaces, without becoming networking experts</t> | <li>have their network services up and running based on intent and | |||
| automation only, without any manual actions or maintenance</li> | ||||
| <t>have their network services up and running based on intent and | </ul> | |||
| automation only, without any manual actions or maintenance</t> | </section> | |||
| <section anchor="sect-4.4" numbered="true" toc="default"> | ||||
| <t></t> | <name>Intent Types That Need to Be Supported</name> | |||
| <t> | ||||
| </list> | ||||
| </t> | ||||
| </section> | ||||
| <section title="Intent Types that need to be supported" anchor="sect-4.4" | ||||
| ><t> | ||||
| Next to the intent solutions and intent users, another way to | Next to the intent solutions and intent users, another way to | |||
| categorize the intent is through the intent types. The following | categorize the intent is through the intent types. The following | |||
| intent types and subtypes need to be supported, in order to address | intent types and subtypes need to be supported in order to address | |||
| the requirements from different solutions and intent users:</t> | the requirements from different solutions and intent users.</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>Customer service intent<list style="symbols"> | <li> | |||
| <t>for customer self-service with SLA</t> | <t>Customer service intent</t> | |||
| <ul spacing="normal"> | ||||
| <t>for service operator orders</t> | <li>for customer self service with SLA</li> | |||
| <li>for service operator orders</li> | ||||
| </list> | </ul> | |||
| </t> | </li> | |||
| <li> | ||||
| <t>Network and underlay network service intent<list style="symbols"><t>fo | <t>Network and underlay network service intent</t> | |||
| r service operator orders</t> | <ul spacing="normal"> | |||
| <li>for service operator orders</li> | ||||
| <t>for intent driven network configuration, verification, correction and | <li>for intent-driven network configuration, verification, correct | |||
| optimization</t> | ion, and | |||
| optimization</li> | ||||
| <t>for intent created and provided by the underlay network administrator< | <li>for intent created and provided by the underlay network admini | |||
| /t> | strator</li> | |||
| </ul> | ||||
| </list> | </li> | |||
| </t> | <li> | |||
| <t>Network and underlay network intent</t> | ||||
| <t>Network and underlay network intent<list style="symbols"><t>for networ | <ul spacing="normal"> | |||
| k configuration</t> | <li>for network configuration</li> | |||
| <li>for automated life-cycle management of network configurations< | ||||
| <t>for automated lifecycle management of network configurations</t> | /li> | |||
| <li>for network resources (switches, routers, routing, policies, a | ||||
| <t>for network resources (switches, routers, routing, policies, underlay) | nd underlay)</li> | |||
| </t> | </ul> | |||
| </li> | ||||
| </list> | <li> | |||
| </t> | <t>Cloud management intent</t> | |||
| <ul spacing="normal"> | ||||
| <t>Cloud management intent<list style="symbols"><t>for DC configuration, | <li>for DC configuration, VMs, DB servers, and Application servers | |||
| VMs, DB servers, APP servers</t> | </li> | |||
| <t>for communication between VMs</t> | ||||
| </list> | ||||
| </t> | ||||
| <t>Cloud resource management intent<list style="symbols"><t>for cloud res | ||||
| ource life-cycle management (policy driven self-configuration and auto-scaling a | ||||
| nd recovery/optimization)</t> | ||||
| </list> | ||||
| </t> | ||||
| <t>Strategy intent<list style="symbols"><t>for security, QoS, application | ||||
| policies, traffic steering, etc.</t> | ||||
| <t>for configuring and monitoring policies, alarms generation for | ||||
| non-compliance, auto-recovery</t> | ||||
| <t>for design models and policies for network and network service design< | ||||
| /t> | ||||
| <t>for design workflows, models and policies for operational task intents | ||||
| </t> | ||||
| </list> | ||||
| </t> | ||||
| <t>Operational task intents<list style="symbols"><t>for network migration | ||||
| </t> | ||||
| <t>for device replacements</t> | ||||
| <t>for network software upgrades</t> | ||||
| <t>for automating any other tasks that operators/administrator often perf | ||||
| orm</t> | ||||
| </list> | ||||
| </t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | <li>for communication between VMs</li> | |||
| It is important to mention there all of the previously mentioned types and | </ul> | |||
| </li> | ||||
| <li> | ||||
| <t>Cloud resource management intent</t> | ||||
| <ul spacing="normal"> | ||||
| <li>for cloud resource life-cycle management (policy-driven self-c | ||||
| onfiguration and auto-scaling and recovery/optimization)</li> | ||||
| </ul> | ||||
| </li> | ||||
| <li> | ||||
| <t>Strategy intent</t> | ||||
| <ul spacing="normal"> | ||||
| <li>for security, QoS, application policies, traffic steering, etc | ||||
| .</li> | ||||
| <li>for configuring and monitoring policies, alarm generation for | ||||
| non-compliance, and auto-recovery</li> | ||||
| <li>for design models and policies for network and network service | ||||
| design</li> | ||||
| <li>for design workflows, models, and policies for operational tas | ||||
| k intents</li> | ||||
| </ul> | ||||
| </li> | ||||
| <li> | ||||
| <t>Operational task intents</t> | ||||
| <ul spacing="normal"> | ||||
| <li>for network migration</li> | ||||
| <li>for device replacements</li> | ||||
| <li>for network software upgrades</li> | ||||
| <li>for automating any other tasks that operators/administrator of | ||||
| ten perform</li> | ||||
| </ul> | ||||
| </li> | ||||
| </ul> | ||||
| <t> | ||||
| It is important to mention all of the previously mentioned types and | ||||
| subtypes may affect other intents. For example, operational task intent can | subtypes may affect other intents. For example, operational task intent can | |||
| modify many other intents. The task itself is short-lived, but the | modify many other intents. The task itself is short lived, but the | |||
| modification of other intents has an impact on their life-cycle, so those | modification of other intents has an impact on their life cycle, so those | |||
| changes must continue to be continuously monitored and | changes must continue to be continuously monitored and | |||
| self-corrected/self-optimized.</t> | self corrected/optimized.</t> | |||
| </section> | ||||
| </section> | </section> | |||
| <section anchor="sect-5" numbered="true" toc="default"> | ||||
| </section> | <name>Functional Characteristics and Behavior</name> | |||
| <t> | ||||
| <section title="Functional Characteristics and Behaviour" anchor="sect-5" | ||||
| ><t> | ||||
| Intent can be used to operate immediately on a target (much like | Intent can be used to operate immediately on a target (much like | |||
| issuing a command), or whenever it is appropriate (e.g., in response | issuing a command) or whenever it is appropriate (e.g., in response | |||
| to an event). In either case, intent has a number of behaviours that | to an event). In either case, intent has a number of behaviors that | |||
| serve to further organize its purpose, as described by the following | serve to further organize its purpose, as described by the following | |||
| subsections.</t> | subsections.</t> | |||
| <section anchor="sect-5.1" numbered="true" toc="default"> | ||||
| <section title="Abstracting Intent Operation" anchor="sect-5.1"><t> | <name>Abstracting Intent Operation</name> | |||
| The modelling of intents can be abstracted using the following three-tuple:</ | <t> | |||
| t> | The modeling of intents can be abstracted using the following three-tuple:</t | |||
| > | ||||
| <t>{Context, Capabilities, Constraints}</t> | <t>{Context, Capabilities, Constraints}</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>Context grounds the intent, and determines if | <li>Context grounds the intent and determines if it is relevant or | |||
| it is relevant or | ||||
| not for the current situation. Thus, context selects intents based | not for the current situation. Thus, context selects intents based | |||
| on applicability.</t> | on applicability.</li> | |||
| <li>Capabilities describe the functionality that the intent can | ||||
| <t>Capabilities describe the functionality that the intent can | perform. Capabilities take different forms depending on the | |||
| perform. Capabilities take different forms, depending on the | ||||
| expressivity of the intent as well as the programming paradigm(s) | expressivity of the intent as well as the programming paradigm(s) | |||
| used.</t> | used.</li> | |||
| <li>Constraints define any restrictions on the capabilities to be used | ||||
| <t>Constraints define any restrictions on the capabilities to be used | for that particular context.</li> | |||
| for that particular context.</t> | </ul> | |||
| <t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | ||||
| Metadata can be attached via strategy templates to each of the | Metadata can be attached via strategy templates to each of the | |||
| elements of the three-tuple, and may be used to describe how the | elements of the three-tuple and may be used to describe how the | |||
| intent should be used and how it operates, as well as prescribe any | intent should be used and how it operates as well as prescribe any | |||
| operational dependencies that must be taken into account.</t> | operational dependencies that must be taken into account.</t> | |||
| <t> | ||||
| <t> | ||||
| Although different intent categories share the same abstracted intent | Although different intent categories share the same abstracted intent | |||
| model, each category will have its own specific context, capabilities | model, each category will have its own specific context, capabilities, | |||
| and constraints.</t> | and constraints.</t> | |||
| </section> | ||||
| </section> | <section anchor="sect-5.2" numbered="true" toc="default"> | |||
| <name>Intent User Types</name> | ||||
| <section title="Intent User Types" anchor="sect-5.2"><t> | <t> | |||
| Expanding on the introduction in section 4.2. , intent user types | Expanding on the introduction in <xref target="sect-4.2"/>, intent user | |||
| represent the intent users that define and issue the intent request. | types represent the intent users that define and issue the intent request. | |||
| Depending on the intent solutions, there are specific intent users. | Depending on the intent solutions, there are specific intent users. | |||
| Examples of intent users are customers, network operators, service | Examples of intent users are customers, network operators, service | |||
| operators, enterprise administrators, cloud administrators, and | operators, enterprise administrators, cloud administrators, underlay | |||
| underlay network administrators, or application developers.</t> | network administrators, or application developers.</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>Customers and end-users do not necessarily kn | <li>Customers and end users do not necessarily know the functional and | |||
| ow the functional and | ||||
| operational details of the network that they are using. | operational details of the network that they are using. | |||
| Furthermore, they lack skills to understand such details; in fact, | Furthermore, they lack skills to understand such details; in fact, | |||
| such knowledge is typically not relevant to their job. In | such knowledge is typically not relevant to their job. In | |||
| addition, the network may not expose these details to its intent | addition, the network may not expose these details to its intent | |||
| users. This class of intent users focuses on the applications that | users. This class of intent users focuses on the applications that | |||
| they run, and uses services offered by the network. Hence, they | they run and uses services offered by the network. Hence, they | |||
| want to specify policies that provide consistent behaviour | want to specify policies that provide consistent behavior | |||
| according to their business needs. They do not have to worry about | according to their business needs. They do not have to worry about | |||
| how the intents are deployed onto the underlying network, and | how the intents are deployed onto the underlying network and | |||
| especially, whether the intents need to be translated to different | especially whether the intents need to be translated to different | |||
| forms to enable network elements to understand them.</t> | forms to enable network elements to understand them.</li> | |||
| <li>Application developers work in a set of abstractions defined by | ||||
| <t>Application developers work in a set of abstractions defined by | ||||
| their application and programming environment(s). For example, | their application and programming environment(s). For example, | |||
| many application developers think in terms of objects (e.g., a | many application developers think in terms of objects (e.g., a | |||
| VPN). While this makes sense to the application developer, most | VPN). While this makes sense to the application developer, most | |||
| network devices do not have a VPN object per se; rather, the VPN | network devices do not have a VPN object per se; rather, the VPN | |||
| is formed through a set of configuration statements for that | is formed through a set of configuration statements for that | |||
| device in concert with configuration statements for the other | device in concert with configuration statements for the other | |||
| devices that together make up the VPN. Hence, the view of | devices that together make up the VPN. Hence, the view of | |||
| application developers matches the services provided by the | application developers matches the services provided by the | |||
| network, but may not directly correspond to other views of other | network but may not directly correspond to other views of other | |||
| intent users.</t> | intent users.</li> | |||
| <li>Network operators may have the knowledge of the underlying | ||||
| <t>Network operators may have the knowledge of the underlying | ||||
| network. However, they may not understand the details of the | network. However, they may not understand the details of the | |||
| applications and services of customers.</t> | applications and services of customers.</li> | |||
| </ul> | ||||
| </list> | </section> | |||
| </t> | <section anchor="sect-5.3" numbered="true" toc="default"> | |||
| <name>Intent Scope</name> | ||||
| </section> | <t> | |||
| Intents are used to manage the behavior of the networks they are | ||||
| <section title="Intent Scope" anchor="sect-5.3"><t> | ||||
| Intents are used to manage the behaviour of the networks they are | ||||
| applied to and all intents are applied within a specific scope, such | applied to and all intents are applied within a specific scope, such | |||
| as:</t> | as:</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>Connectivity scope, if the intent creates or | <li>connectivity scope, if the intent creates or modifies a connection | |||
| modifies a connection.</t> | </li> | |||
| <li>security/privacy scope, if the intent specifies the security | ||||
| <t>Security/privacy scope, if the intent specifies the security | characteristics of the network, customers, or end users</li> | |||
| characteristics of the network, customers, or end-users.</t> | <li>application scope, when the intent specifies the applications to | |||
| be affected by the intent request</li> | ||||
| <t>Application scope, when the intent specifies the applications to | <li>QoS scope, when the intent specifies the QoS characteristics of | |||
| be affected by the intent request.</t> | the network</li> | |||
| </ul> | ||||
| <t>QoS scope, when the intent specifies the QoS characteristics of | <t> | |||
| the network.</t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | ||||
| These intent scopes are expendable through the methodology presented | These intent scopes are expendable through the methodology presented | |||
| in section 6.1. .</t> | in <xref target="sect-6.1"/>.</t> | |||
| </section> | ||||
| </section> | <section anchor="sect-5.4" numbered="true" toc="default"> | |||
| <name>Intent Network Scope</name> | ||||
| <section title="Intent Network Scope" anchor="sect-5.4"><t> | <t> | |||
| Regardless on the intent user type, their intent request is affecting | Regardless of the intent user type, their intent request affects | |||
| the network, or network components, which are representing the intent | the network, or network components, which are representing the intent | |||
| targets.</t> | targets.</t> | |||
| <t> | ||||
| <t> | Thus, the intent network scope, or policy target as known in the area of | |||
| Thus, intent network scope, or policy target as known in the area of | ||||
| declarative policy, can represent VNFs or PNFs, physical network | declarative policy, can represent VNFs or PNFs, physical network | |||
| elements, campus networks, SD-WAN networks, radio access networks, | elements, campus networks, SD-WANs, RANs, | |||
| cloud edge, cloud core, branch, etc.</t> | cloud edges, cloud cores, branches, etc.</t> | |||
| </section> | ||||
| </section> | <section anchor="sect-5.5" numbered="true" toc="default"> | |||
| <name>Intent Abstraction</name> | ||||
| <section title="Intent Abstraction" anchor="sect-5.5"><t> | <t> | |||
| Intent can be classified by whether it is necessary to feedback | Intent can be classified by whether it is necessary to feed back | |||
| technical network information or non-technical information to the | technical network information or non-technical information to the | |||
| intent user after the intent is executed. As well, intent abstraction | intent user after the intent is executed. As well, intent abstraction | |||
| covers the level of technical details in the intent itself.</t> | covers the level of technical details in the intent itself.</t> | |||
| <ul spacing="normal"> | ||||
| <t><list style="symbols"><t>For non-technical intent users, they do not c | <li>Non-technical intent users do not care how the intent is | |||
| are how the intent is | executed nor do they care about the details of the network. As a result, th | |||
| executed, or the details of the network. As a result, they do not | ey do not | |||
| need to know the configuration information of the underlying | need to know the configuration information of the underlying | |||
| network. They only focus on whether the intent execution result | network. They only focus on whether the intent execution result | |||
| achieves the goal, and the execution effect such as the quality of | achieves the goal and the execution effect such as the quality of | |||
| completion and the length of execution. In this scenario, we refer | completion and the length of execution. In this scenario, we refer | |||
| to an abstraction without technical feedback.</t> | to an abstraction without technical feedback.</li> | |||
| <li>Administrators, such as network administrators, perform | ||||
| <t>For administrators, such as network administrators, they perform | ||||
| intents, such as allocating network resources, selecting | intents, such as allocating network resources, selecting | |||
| transmission paths, handling network failures, etc. They require | transmission paths, handling network failures, etc. They require | |||
| multiple feedback indicators for network resource conditions, | multiple feedback indicators for network resource conditions, | |||
| congestion conditions, fault conditions, etc. after execution. In | congestion conditions, fault conditions, etc., after execution. In | |||
| this case, we refer to an abstraction with technical feedback.</t> | this case, we refer to an abstraction with technical feedback.</li> | |||
| </ul> | ||||
| </list> | <t> | |||
| </t> | As per the definition of "intent" provided in <xref target="RFC9315" format=" | |||
| default"/>, lower-level intents are not | ||||
| <t> | ||||
| As per intent definition provided in <xref target="I-D.irtf-nmrg-ibn-concepts | ||||
| -definitions"/>, lower-level intents are not | ||||
| considered to qualify as intents. However, we kept this classification to | considered to qualify as intents. However, we kept this classification to | |||
| identify any PoCs/Demos/Use Cases that still either require or implement | identify any PoCs / Demos / Use Cases that still either require or implement | |||
| lower level of abstraction for intents.</t> | a lower level of abstraction for intents.</t> | |||
| </section> | ||||
| </section> | ||||
| <section title="Intent Life-cycle" anchor="sect-5.6"><t> | <section anchor="sect-5.6" numbered="true" toc="default"> | |||
| <name>Intent Life Cycle</name> | ||||
| <t> | ||||
| Intents can be classified into transient and persistent intents:</t> | Intents can be classified into transient and persistent intents:</t> | |||
| <dl spacing="normal"> | ||||
| <t><list style="symbols"><t>If the intent is transient, it has no life-cy | <dt>Transient:</dt><dd>The intent has no life-cycle management. As | |||
| cle management. As | ||||
| soon as the specified operation is successfully carried out, the | soon as the specified operation is successfully carried out, the | |||
| intent is finished, and can no longer affect the target object.</t> | intent is finished and can no longer affect the target object.</dd> | |||
| <dt>Persistent:</dt><dd>The intent has life-cycle management. Once | ||||
| <t>If the intent is persistent, it has life-cycle management. Once | ||||
| the intent is successfully activated and deployed, the system will | the intent is successfully activated and deployed, the system will | |||
| keep all relevant intents active until they are deactivated or | keep all relevant intents active until they are deactivated or | |||
| removed.</t> | removed.</dd> | |||
| </dl> | ||||
| </list> | </section> | |||
| </t> | <section anchor="sect-5.7" numbered="true" toc="default"> | |||
| <name>Autonomous Driving Levels</name> | ||||
| </section> | <t> | |||
| In different phases of the autonomous driving network <xref | ||||
| <section title="Autonomous Driving Levels" anchor="sect-5.7"><t> | target="TMF-AUTO" format="default"/>, the intents are different. Depending | |||
| In different phases of the autonomous driving network [TMF-auto], the | on the Autonomous Network Level of the overall solution, we may have | |||
| intents are different. Depending on the Autonomous Network Level of | different intent requirements and types. For example, at lower levels, the | |||
| the overall solution, we may have different intent requirements and | customer intent is:</t> | |||
| types. For example, at lower level the customer intent is | <ul spacing="normal"> | |||
| automatically converted to configuration policies only, while at the | <li>automatically converted to configuration policies only | |||
| higher levels the customer intent is covering the full life cycle, it | while at the higher levels,</li> | |||
| is converted to both configuration and monitoring policies and is | <li>covering the full life | |||
| self-assured using AI.</t> | cycle,</li> | |||
| <li>converted to both configuration and monitoring policies, and</li> | ||||
| <t> | <li> self assured using AI.</li> | |||
| A typical example of autonomous driving network level 0 to 5 are | </ul> | |||
| listed as below.</t> | <t> | |||
| Typical examples of autonomous driving networks level 0 to 5 are | ||||
| shown below.</t> | ||||
| <t><list style="symbols"><t>Level 0 - Traditional manual network: O&M | <dl newline="true"> | |||
| personnel manually | ||||
| control the network and obtain network alarms and logs. - No | ||||
| intent</t> | ||||
| <t>Level 1 - Partially automated network: Automated scripts are used | <dt>Level 0 - Traditional manual network: | |||
| to automate service provisioning, network deployment, and | </dt> | |||
| maintenance. Shallow perception of network status and decision | <dd><t>O&M personnel manually control the network and obtain network alarms | |||
| making suggestions of machine; - No intent</t> | and logs.</t><t>- No intent</t> | |||
| </dd> | ||||
| <t>Level 2 - Automated network: Automation of most service | <dt>Level 1 - Partially automated network: | |||
| provisioning, network deployment, and maintenance of a | </dt> | |||
| comprehensive perception of network status and local machine | <dd><t>Automated scripts are used to automate service provisioning, network | |||
| decision making; - simple intent on service provisioning</t> | deployment, and maintenance. The network provides shallow perception of the | |||
| network status and decision making suggestions. | ||||
| </t><t>- No intent</t> | ||||
| </dd> | ||||
| <t>Level 3 - Self-optimization network: Deep awareness of network | <dt>Level 2 - Automated network: | |||
| status and automatic network control, meeting requirements of | </dt> | |||
| intent users of the network. - Intent based on network status | ||||
| cognition</t> | ||||
| <t>Level 4 - Partial autonomous network: In a limited environment, | <dd><t> | |||
| people do not need to participate in decision-making and networks | ||||
| can adjust itself. - Intent based on limited AI</t> | ||||
| <t>Level 5 - Autonomous network: In different network environments | This entails the automation of most service provisioning, network deployment, | |||
| and network conditions, the network can automatically adapt to and | and maintenance of a comprehensive perception of network status and local | |||
| adjust to meet people's intentions. - Intent based on AI</t> | machine decision-making.</t> <t>- simple intent on service provisioning</t> | |||
| </dd> | ||||
| </list> | <dt>Level 3 - Self-optimization network: | |||
| </t> | </dt> | |||
| <dd><t> This entails a deep awareness of network status and automatic network | ||||
| control, meeting requirements of intent users of the network.</t> <t>- Intent ba | ||||
| sed on | ||||
| network status cognition</t> | ||||
| </dd> | ||||
| </section> | <dt>Level 4 - Partial autonomous network: | |||
| </dt> | ||||
| <dd><t>In a limited environment, people do not need to participate in | ||||
| decision-making and networks can adjust themselves.</t> <t>- Intent based on lim | ||||
| ited AI</t> | ||||
| </dd> | ||||
| </section> | <dt>Level 5 - Autonomous network: | |||
| </dt> | ||||
| <dd><t>In different network environments and network conditions, the network can | ||||
| automatically adapt and adjust to meet people's intentions.</t> <t>- Intent base | ||||
| d on AI</t> | ||||
| </dd> | ||||
| <section title="Intent Classification" anchor="sect-6"><t> | </dl> | |||
| This section proposes an intent classification approach that may help | ||||
| to classify mainstream intent related demos/tools.</t> | ||||
| <t> | </section> | |||
| </section> | ||||
| <section anchor="sect-6" numbered="true" toc="default"> | ||||
| <name>Intent Classification</name> | ||||
| <t> | ||||
| This section proposes an approach to intent classification that may help | ||||
| to classify mainstream intent-related demos/tools.</t> | ||||
| <t> | ||||
| The three classifications in this document have been proposed from | The three classifications in this document have been proposed from | |||
| scratch, following the methodology presented, through three | scratch (following the methodology presented) through three | |||
| iterations: one for carrier network intent solution, one for DC | iterations: one for a carrier network intent solution, one for a DC | |||
| intent solution, and one for enterprise intent solution. For each | intent solution, and one for an enterprise intent solution. For each | |||
| intent solution, we identified the specific intent users and intent | intent solution, we identified the specific intent users and intent | |||
| types. Then, we further identified intent scope, network scope, | types. Then, we further identified intent scope, network scope, | |||
| abstractions, and life-cycle requirements.</t> | abstractions, and life-cycle requirements.</t> | |||
| <t> | ||||
| <t> | ||||
| These classifications and the generated tables can be easily | These classifications and the generated tables can be easily | |||
| extended. For example, for the DC intent solution, a new category is | extended. | |||
| identified, i.e. resource scope, and the classification table has | ||||
| been extended accordingly.</t> | ||||
| <t> | For example, for the DC intent solution, a new category "resource scope" is | |||
| In the future, as new scenarios, applications, and domains are | identified, and the classification table has | |||
| emerging, new classifications and taxonomies can be identified, | been extended accordingly.</t> | |||
| <t> | ||||
| In the future, as new scenarios, applications, and domains emerge, new classi | ||||
| fications and taxonomies can be identified, | ||||
| following the proposed methodology.</t> | following the proposed methodology.</t> | |||
| <t> | ||||
| <t> | ||||
| The intent classifications have been documented to the best of our | The intent classifications have been documented to the best of our | |||
| knowledge at this point in time. Additional classifications will most | knowledge at the time of writing. Additional classifications will most | |||
| probably see the light in the future.</t> | likely come to light in the future.</t> | |||
| <t> | ||||
| <t> | ||||
| The output of the intent classification is the intent taxonomy | The output of the intent classification is the intent taxonomy | |||
| introduced in the next sections.</t> | introduced in the subsections of this section.</t> | |||
| <t> | ||||
| <t> | Thus, the subsections of <xref target="sect-6" format="default"/> introduce | |||
| Thus, this section first introduces the proposed intent | the proposed intent | |||
| classification methodology, followed by consolidated intent taxonomy | classification methodology, the consolidated intent taxonomy | |||
| for three intent solutions, and then by concrete examples of intent | for three intent solutions, and the concrete examples of intent | |||
| classifications for three different intent solutions (e.g. carrier | classifications for three different intent solutions (e.g., carrier | |||
| network, data center, and enterprise) that were derived using the | network, data center, and enterprise) that were derived using the | |||
| proposed methodology and then can be filled in for PoCs, demos, | proposed methodology and can be filled in for PoCs, demos, | |||
| research projects or future drafts.</t> | research projects, or future documents.</t> | |||
| <section anchor="sect-6.1" numbered="true" toc="default"> | ||||
| <section title="Intent Classification Methodology" anchor="sect-6.1"><t> | <name>Intent Classification Methodology</name> | |||
| <t> | ||||
| This section describes the methodology used to derive the initial | This section describes the methodology used to derive the initial | |||
| classification proposed in the draft. The proposed methodology can be | classification proposed in the document. The proposed methodology can be | |||
| used to create new intent classifications from scratch, by analysing | used to create new intent classifications from scratch by analyzing | |||
| the solution knowledge. As well, the methodology can be used to | the solution knowledge. As well, the methodology can be used to | |||
| update existing classification tables by adding or removing different | update existing classification tables by adding or removing different | |||
| solutions, intent users or intent types in order to cater for future | solutions, intent users, or intent types in order to cater to future | |||
| scenarios, applications or domains.</t> | scenarios, applications, or domains.</t> | |||
| <figure anchor="fig-1"> | ||||
| <figure title="- Intent Classification Methodology" anchor="fig-1"><artwork><![C | <name>Intent Classification Methodology</name> | |||
| DATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
| +------------------------------------------+ | +------------------------------------------+ | |||
| |Solution Knowledge (requirements, | | |Solution Knowledge (requirements, | | |||
| |use cases, technologies, network, intent | | |use cases, technologies, network, intent | | |||
| |users, intent requirements) | | |users, intent requirements) | | |||
| +----------------+-------------------------+ | +----------------+-------------------------+ | |||
| | Input Rx=Read | | Input Rx=Read | |||
| | Ux=Update (Add/Remove) | | Ux=Update (Add/Remove) | |||
| +--------V--------+ | +--------V--------+ | |||
| |1.Identify Intent| | |1.Identify Intent| | |||
| | Solution +------------+ | | Solution +------------+ | |||
| skipping to change at line 858 ¶ | skipping to change at line 936 ¶ | |||
| R1 | | U1 | | R1 | | U1 | | |||
| +---------------+ U8 | | R2 +--v----------------+ | +---------------+ U8 | | R2 +--v----------------+ | |||
| |8.Identify New +---------+ | | +-----------> 2.Identify | | |8.Identify New +---------+ | | +-----------> 2.Identify | | |||
| | Categories | R8 | | | | U2 | Intent | | | Categories | R8 | | | | U2 | Intent | | |||
| | <-------- | | | | +---------+ User Types | | | <-------- | | | | +---------+ User Types | | |||
| +--------^------+ | | | | | | +-------|-----------+ | +--------^------+ | | | | | | +-------|-----------+ | |||
| | | | | | | | | | | | | | | | | | | |||
| | ++-+-v-v---+-v-+ | | | ++-+-v-v---+-v-+ | | |||
| +--------+------+ U7 | | R3 +------v------------+ | +--------+------+ U7 | | R3 +------v------------+ | |||
| |7.Identify +------> Intent +--------> 3.Identify | | |7.Identify +------> Intent +--------> 3.Identify | | |||
| | Life-cycle | R7 |Classification| U3 | Type | | | Life-Cycle | R7 |Classification| U3 | Type | | |||
| | Requirements <------+ <--------+ of Intent | | | Requirements <------+ <--------+ of Intent | | |||
| +--------^------+ +^--^-+--^-+---+ +------|------------+ | +--------^------+ +^--^-+--^-+---+ +------|------------+ | |||
| | || | | | | | | | || | | | | | | |||
| | || | | | | | | | || | | | | | | |||
| +--------+-----+ || | | | | R4 +-------v-----------+ | +--------+-----+ || | | | | R4 +-------v-----------+ | |||
| |6.Identify | U6 || | | | +-----------> 4.Identify | | |6.Identify | U6 || | | | +-----------> 4.Identify | | |||
| | Abstractions+---------| | | | U4 | Intent | | | Abstractions+---------| | | | U4 | Intent | | |||
| | <---------+ | | +-------------+ Scope | | | <---------+ | | +-------------+ Scope | | |||
| +-------^------+ R6 | | +-------+-----------+ | +-------^------+ R6 | | +-------+-----------+ | |||
| | | | | | | | | | | |||
| | U5 | |R5 | | | U5 | |R5 | | |||
| | +-------+-v--------+ | | | +-------+-v--------+ | | |||
| | |5.Identify Network| | | | |5.Identify Network| | | |||
| +----------+ Scope <---------------+ | +----------+ Scope <---------------+ | |||
| +------------------+ | +------------------+ | |||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| <t> | <t> | |||
| The intent classification workflow starts from the solution | The intent classification workflow starts from the solution | |||
| knowledge, which can provide information on requirements, use cases, | knowledge, which can provide information on requirements, use cases, | |||
| technologies used, network properties, intent users that define and | technologies used, network properties, intent users that define and | |||
| issue the intent request, and requirements. The following, defines | issue the intent request, and requirements. The following defines | |||
| the steps to classify an intent: | the steps to classify an intent: | |||
| <list style="numbers"> | </t> | |||
| <t> | <ol spacing="normal" type="1"><li> | |||
| The information provided in the solution knowledge is given as | Receive the information provided in the solution knowledge as | |||
| input for identifying the intent solution (e.g. carrier, enterprise, | input for identifying the intent solution (e.g., carrier, enterprise, | |||
| and data center). Intent solutions are reviewed against the existing | and data center). Intent solutions are reviewed against the existing | |||
| classification and they can either be used if present or added if not | classification and can either be used if present or added if not | |||
| there or removed if not needed, from the classification. (R1-U1).</t> | there; if not needed, they can be removed from the classification (R1-U1).</l | |||
| i> | ||||
| <t> | <li> | |||
| Identify the intent user types (e.g. customer, network operators, | Identify the intent user types (e.g., customer, network operators, service | |||
| service operators, etc.), review existing intent classification and | operators, etc.). Review the existing intent classification. Then use the in | |||
| use the intent user type if present, add if it is not there or remove | tent | |||
| it if not needed (R2-U2).</t> | user type if present; add it if it is not there or remove it if not needed | |||
| (R2-U2).</li> | ||||
| <t> | <li> | |||
| Identify the types of intent (e.g. network intent, customer | Identify the types of intent (e.g., network intent, customer | |||
| service intent) and then review existing classification and | service intent). Review the existing classification and | |||
| use/add/remove the intent type (R3-U3).</t> | then use, add, or remove the intent type (R3-U3).</li> | |||
| <li> | ||||
| <t> | Identify the intent scopes (e.g., connectivity, application) based | |||
| Identify the intent scopes (e.g. connectivity, application) based | on the solution knowledge. Then, review the existing classification. | |||
| on the solution knowledge and then review existing classification and | Use, add, or remove the identified intent scope (R4-U4).</li> | |||
| use/add/remove the identified intent scope (R4-U4).</t> | <li> | |||
| Identify the network scopes (e.g., campus, radio access). Then, | ||||
| <t> | review the existing classification. Either use, add, or remove the | |||
| Identify the network scopes (e.g. campus, radio access) and then | identified network scope (R5-U5).</li> | |||
| review existing classification and either use it or add/remove the | <li> | |||
| identified network scope (R5-U5).</t> | Identify the abstractions (e.g., technical, non-technical). | |||
| Then, review the existing classification and either use, add, or remove the | ||||
| <t> | abstractions (R6-U6).</li> | |||
| Identify the abstractions (e.g. technical, non-technical) and | <li> | |||
| then review existing classification and use/add/remove the | Identify the life-cycle requirements (e.g., persistent, transient). | |||
| abstractions (R6-U6).</t> | Then, review the existing classification. Either use, add, or remove the | |||
| life-cycle requirements (R7-U7).</li> | ||||
| <t> | <li> | |||
| Identify the life-cycle requirements (e.g. persistent, transient) | ||||
| and then review existing classification and use/add/remove the | ||||
| life-cycle requirements (R7-U7).</t> | ||||
| <t> | ||||
| Identify any new categories and use/add the newly identified | ||||
| categories. New categories can be identified as new domains or | ||||
| applications are emerging, or new areas of concern (e.g. privacy, | ||||
| compliance) might arise, which are not listed in the current | ||||
| methodology.</t> | ||||
| </list> | Identify any new categories. Use and add the newly identified categories. New | |||
| </t> | categories can be identified as new domains or applications emerge or as new | |||
| </section> | areas of concern (e.g., privacy, compliance) arise that are not listed in the | |||
| current methodology.</li> | ||||
| </ol> | ||||
| </section> | ||||
| <section title="Intent Taxonomy" anchor="sect-6.2"><t> | <section anchor="sect-6.2" numbered="true" toc="default"> | |||
| <name>Intent Taxonomy</name> | ||||
| <t> | ||||
| The following taxonomy describes the various intent solutions, intent | The following taxonomy describes the various intent solutions, intent | |||
| user types, intent types, intent scopes, network scopes, abstractions | user types, intent types, intent scopes, network scopes, abstractions, | |||
| and life-cycle and represents the output of the intent classification | and life cycles. The taxonomy represents the output of the intent classifica | |||
| tables for each of the solutions addressed (i.e. carrier, data | tion | |||
| tables for each of the solutions addressed (i.e., carrier, data | ||||
| center, and enterprise solutions).</t> | center, and enterprise solutions).</t> | |||
| <t> | ||||
| The intent scope categories in <xref target="fig-2"/> are shared among the ca | ||||
| rrier, | ||||
| DC, and enterprise solutions. The abbreviations (Cx) in Sections | ||||
| <xref target="sect-6.3.2" format="counter"/> and <xref target="sect-6.4.2" fo | ||||
| rmat="counter"/> are introduced with the scope of fitting as column | ||||
| title in the following tables.</t> | ||||
| <t> | <figure anchor="fig-2"> | |||
| The intent scope categories in Figure 2 are shared among the carrier, | <name>Intent Taxonomy</name> | |||
| DC, and enterprise solutions. The abbreviations (Cx) in sections | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
| 6.3.2. 6.4.2. are introduced with the scope of fitting as column | ||||
| title in the following tables.</t> | ||||
| <figure title="- Intent Taxonomy" anchor="fig-2"><artwork><![CDATA[ | ||||
| +--------------------------------+ | +--------------------------------+ | |||
| +-->|Carrier Enterprise Data Center| | +-->|Carrier Enterprise Data Center| | |||
| | +--------------------------------+ | | +--------------------------------+ | |||
| | +--------------------------------+ | | +--------------------------------+ | |||
| | |Customer/Subscriber/End-User | | | |Customer/Subscriber/End User | | |||
| +----------+ | |Network or Service Operator | | +----------+ | |Network or Service Operator | | |||
| +>+Solutions +--+ |Application Developer | | +>+Solution +--+ |Application Developer | | |||
| | +----------+ +->|Enterprise Administrator | | | +----------+ +->|Enterprise Administrator | | |||
| | | |Cloud Administrator | | | | |Cloud Administrator | | |||
| | +----------+ | |Underlay Network Administrator | | | +----------+ | |Underlay Network Administrator | | |||
| +>+Intent +---+ +--------------------------------+ | +>+Intent +---+ +--------------------------------+ | |||
| | |User | +--------------------------------+ | | |User | +--------------------------------+ | |||
| | |Types | |Customer Service Intent | | | |Type | |Customer Service Intent | | |||
| | +----------+ |Strategy Intent | | | +----------+ |Strategy Intent | | |||
| | +----------+ |Network Service Intent | | | +----------+ |Network Service Intent | | |||
| +>+Intent +----->|Underlay Network Service Intent | | +>+Intent +----->|Underlay Network Service Intent | | |||
| +------+ | |Type | |Network Intent | | +------+ | |Type | |Network Intent | | |||
| |Intent+-+ +----------+ |Underlay Network Intent | | |Intent+-+ +----------+ |Underlay Network Intent | | |||
| +------+ | |Operational Task Intent | | +------+ | |Operational Task Intent | | |||
| | +----------+ |Cloud Management Intent | | | +----------+ |Cloud Management Intent | | |||
| +>+Intent +---+ |Cloud Resource Management Intent| | +>+Intent +---+ |Cloud Resource Management Intent| | |||
| | |Scope | | +--------------------------------+ | | |Scope | | +--------------------------------+ | |||
| | +----------+ | +--------------------------------+ | | +----------+ | +--------------------------------+ | |||
| | +->|Connectivity Application QoS | | | +->|Connectivity Application QoS | | |||
| | +----------+ |Security/Privacy Storage Compute| | | +----------+ |Security/Privacy Storage Compute| | |||
| +>+Network +---+ +--------------------------------+ | +>+Network +---+ +--------------------------------+ | |||
| | |Scope | | +--------------------------------+ | | |Scope | | +--------------------------------+ | |||
| | +----------+ | |Radio Access Branch | | | +----------+ | |Radio Access Branch | | |||
| | +->|Transport Access SD-WAN | | | +->|Transport Access SD-WAN | | |||
| | +----------+ |Transport Aggr. VNF PNF | | | +----------+ |Transport Aggr. VNF PNF | | |||
| +>+Abstrac +----+ |Transport Core Physical | | +>+Abstrac- +----+ |Transport Core Physical | | |||
| | |tion | | |Cloud Edge Logical | | | |tion | | |Cloud Edge Logical | | |||
| | +----------+ | |Cloud Core Campus | | | +----------+ | |Cloud Core Campus | | |||
| | +----------+ | +--------------------------------+ | | +----------+ | +--------------------------------+ | |||
| +>+Life | | +--------------------------------+ | +>+Life | | +--------------------------------+ | |||
| |cycle +--+ +>|Technical Non-Technical | | |Cycle +--+ +>|Technical Non-Technical | | |||
| +----------+ | +--------------------------------+ | +----------+ | +--------------------------------+ | |||
| | +--------------------------------+ | | +--------------------------------+ | |||
| +-->|Persistent Transient | | +-->|Persistent Transient | | |||
| +--------------------------------+ | +--------------------------------+ | |||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| </section> | </section> | |||
| <section anchor="sect-6.3" numbered="true" toc="default"> | ||||
| <section title="Intent Classification for Carrier Solution" anchor="sect- | <name>Intent Classification for Carrier Solution</name> | |||
| 6.3"><section title="Intent Users and Intent Types" anchor="sect-6.3.1"><t> | <section anchor="sect-6.3.1" numbered="true" toc="default"> | |||
| This section addresses step 1, 2, and 3 from Figure 1 and the | <name>Intent Users and Intent Types</name> | |||
| <t> | ||||
| This section addresses steps 1, 2, and 3 from <xref target="fig-1"/>. The | ||||
| following table describes the intent users in carrier solutions and | following table describes the intent users in carrier solutions and | |||
| intent types with their descriptions for different intent users.</t> | intent types with their descriptions for different intent users.</t> | |||
| <figure><artwork><![CDATA[ | <table anchor="intent" align="center"> | |||
| +-------------+-------------+---------------------------------------+ | <name>Intent Classification for Carrier Solution</name> | |||
| | Intent User | Intent Type | Intent Type Description | | <thead> | |||
| +-------------------------------------------------------------------+ | <tr> | |||
| | Customer/ |Customer |Customer self-service with SLA and | | <th>Intent User</th> | |||
| | Subscriber |Service |value added service | | <th>Intent Type</th> | |||
| | |Intent |Example: Always maintain high quality | | <th>Intent Type Description</th> | |||
| | | |of service and high bandwidth for gold | | </tr> | |||
| | | |level subscribers. | | </thead> | |||
| | | |Operational statement: Measure the | | ||||
| | | |network congestion status, give | | ||||
| | | |different adaptive parameters to | | ||||
| | | |stations of different priority, thus in| | ||||
| | | |heavy load situation, make the | | ||||
| | | |bandwidth of the high-priority | | ||||
| | | |customers guaranteed. | | ||||
| | | |At the same time ensure the overall | | ||||
| | | |utilization of system, improve | | ||||
| | | |the overall throughput of the system. | | ||||
| | +-----------------------------------------------------+ | ||||
| | |Strategy |Customer designs models and policy | | ||||
| | |Intent |intents to be used by customer service | | ||||
| | | |intents. | | ||||
| | | |Example: Request reliable service | | ||||
| | | |during peak traffic periods for apps | | ||||
| | | |of type video. | | ||||
| +-------------------------------------------------------------------+ | ||||
| |Network |Network |Service provided by network service | | ||||
| |Operator |Service |operator to the customer | | ||||
| | |Intent |(e.g. the service operator) | | ||||
| | | |Example: Request network service with | | ||||
| | | |delay guarantee for access customer A. | | ||||
| | +-------------+---------------------------------------+ | ||||
| | |Network |Network operator requests network-wide | | ||||
| | |Intent |(service underlay or other network-wide| | ||||
| | | |configuration) or network resource | | ||||
| | | |configurations (switches, routers, | | ||||
| | | |routing, policies). Includes | | ||||
| | | |connectivity, routing, QoS, security, | | ||||
| | | |application policies, traffic steering | | ||||
| | | |policies, configuration policies, | | ||||
| | | |monitoring policies, alarm generation | | ||||
| | | |for non-compliance, auto-recovery, etc.| | ||||
| | | |Example: Request high priority queueing| | ||||
| | | |for traffic of class A. | | ||||
| | +-----------------------------------------------------+ | ||||
| | |Operational |Network operator requests execution of | | ||||
| | |Task |any automated task other than network | | ||||
| | |Intent |service intent and network intent | | ||||
| | | |(e.g. network migration, server | | ||||
| | | |replacements, device replacements, | | ||||
| | | |network software upgrades). | | ||||
| | | |Example: Request migration of all | | ||||
| | | |services in network N to backup path P.| | ||||
| | +-----------------------------------------------------+ | ||||
| | |Strategy |Network operator designs models, policy| | ||||
| | |Intent |intents and workflows to be used by | | ||||
| | | |network service Intents, network | | ||||
| | | |intents and operational task intents. | | ||||
| | | |Workflows can automate any tasks that | | ||||
| | | |network operator often performed in | | ||||
| | | |addition to network service intents and| | ||||
| | | |network intents | | ||||
| | | |Example: Ensure the load on any link in| | ||||
| | | |the network is not higher than 50%. | | ||||
| +-------------+-------------+---------------------------------------+ | ||||
| +-------------+-------------+---------------------------------------+ | ||||
| | Service | Customer | Service operator's customer orders, | | ||||
| | Operator | Service | customer service / SLA | | ||||
| | | Intent | Example: Provide service S with | | ||||
| | | | guaranteed bandwidth for customer A. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Network | Service operator's network orders / | | ||||
| | | Service | network SLA | | ||||
| | | Intent | Example: Provide network guarantees in| | ||||
| | | | terms of security, low latency and | | ||||
| | | | high bandwidth | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Operational | Service operator requests execution of| | ||||
| | | Task | any automated task other than | | ||||
| | | Intent | customer service intent and network | | ||||
| | | | service intent | | ||||
| | | | Example: Update service operator | | ||||
| | | | portal platforms and their software | | ||||
| | | | regularly. Move services from network | | ||||
| | | | operator 1 to network operator 2. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Strategy | Service operator designs models, | | ||||
| | | Intent | policy intents and workflows to be | | ||||
| | | | used by customer service intents, | | ||||
| | | | network service intents and | | ||||
| | | | operational task intents. Workflows | | ||||
| | | | can automate any tasks that service | | ||||
| | | | operator often performed in addition | | ||||
| | | | to network service intents and network| | ||||
| | | | intents. | | ||||
| | | | Example: Request network service | | ||||
| | | | guarantee to avoid network congestion | | ||||
| | | | during special periods | | ||||
| | | | such as black Friday, and Christmas. | | ||||
| +-------------+-------------+---------------------------------------+ | ||||
| | Application | Customer | Customer service intent API provided | | ||||
| | Developer | Service | to the application developers | | ||||
| | | Intent | Example: API to request network to | | ||||
| | | | watch HD video 4K/8K. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Network | Network service intent API provided to| | ||||
| | | Service | the application developers | | ||||
| | | Intent | Example:API to request network service| | ||||
| | | | , monitoring and traffic grooming. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Network | Network intent API provided to the | | ||||
| | | Intent | application developers | | ||||
| | | | Example: API to request network | | ||||
| | | | resources configuration. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Operational | Operational task intent API provided | | ||||
| | | Task | to the application developers. This is| | ||||
| | | Intent | for the trusted internal operator / | | ||||
| | | | service providers / customer DevOps | | ||||
| | | | Example: API to request server | | ||||
| | | | migrations. | | ||||
| | +-----------------------------------------------------+ | ||||
| | | Strategy | Application developer designs models, | | ||||
| | | Intent | policy and workflows to be used by | | ||||
| | | | customer service intents, network | | ||||
| | | | service intents and operational | | ||||
| | | | task intents. This is for the trusted | | ||||
| | | | internal operator/service provider/ | | ||||
| | | | customer DevOps | | ||||
| | | | Example: API to design network load | | ||||
| | | | balancing strategies during peak times| | ||||
| +-------------+-------------+---------------------------------------+ | ||||
| Table 2 - Intent Classification for Carrier Solution | <tbody> | |||
| ]]></artwork> | <tr> | |||
| </figure> | <td rowspan="2" colspan="1">Customer/Subscriber</td> | |||
| </section> | <td>Customer Service Intent</td> | |||
| <td><t>Customer self service with SLA and value-added service.</t> | ||||
| <t>Example: Always maintain a high quality of service and high bandwidth | ||||
| for gold-level subscribers. </t> | ||||
| <t>Operation statement: Measure the network congestion status, give | ||||
| different adaptive parameters to stations of different priority; | ||||
| thus, in a heavy load situation, make the bandwidth of the | ||||
| high-priority customers guaranteed. At the same time, ensure the | ||||
| overall utilization of the system and improve the overall throughput of the | ||||
| system.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td><t>Customer designs models and policy intents to be used by | ||||
| customer service intents.</t> | ||||
| <t>Example: Request reliable service during peak traffic periods for | ||||
| video-type apps.</t></td> | ||||
| </tr> | ||||
| <section title="Intent Categories" anchor="sect-6.3.2"><t> | <tr> | |||
| This subsection addresses step 4 to 7 from Figure 1, and the | <td rowspan="4">Network Operator</td> | |||
| following are the proposed categories: | <td>Network Service Intent</td> | |||
| <td> <t>Service provided by the network service operator to the customer | ||||
| (e.g., the service operator).</t> | ||||
| <t>Example: Request network service with delay guarantee for | ||||
| access customer A.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Network Intent</td> | ||||
| <td> <t>Network operator requests network-wide (service underlay or other | ||||
| network-wide configuration) or network-resource configurations | ||||
| (switches, routers, routing, or policies). Includes connectivity, routing, Q | ||||
| oS, | ||||
| security, application policies, traffic steering policies, alarm | ||||
| generation for non-compliance, auto-recovery, etc.</t> | ||||
| <t>Example: Request high priority queuing for traffic of class A.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td> <t>Network operator requests execution of any automated task other than | ||||
| network service intent and network intent (e.g., network migration, server | ||||
| replacements, device replacements, or network software upgrades).</t> | ||||
| <t>Example: Request migration of all services in network N to backup path P.</t | ||||
| ></td> | ||||
| </tr> | ||||
| <list style="symbols"> | <tr> | |||
| <td>Strategy Intent</td> | ||||
| <td> <t>Network operator designs models, policy intents, and workflows to be | ||||
| used | ||||
| by network service intents, network intents, and operational task intents. | ||||
| Workflows can automate any tasks that the network operator often performs in | ||||
| addition to network service intents and network intents.</t> <t>Example: En | ||||
| sure the | ||||
| load on any link in the network is not higher than 50%.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td rowspan="4">Service Operator</td> | ||||
| <td>Customer Service Intent</td> | ||||
| <td> <t>Service operator's customer orders, | ||||
| customer service, or SLA.</t> | ||||
| <t>Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, C4=Q | <t>Example: Provide service S with | |||
| oS</t> | guaranteed bandwidth for customer A.</t></td> | |||
| </tr> | ||||
| <tr> | ||||
| <td>Network Service Intent</td> | ||||
| <td> <t>Service operator's network orders / | ||||
| network SLA.</t> | ||||
| <t>Example: Provide network guarantees in | ||||
| terms of security, low latency, and | ||||
| high bandwidth.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td> <t>Service operator requests execution of | ||||
| any automated task other than | ||||
| customer service intent and network | ||||
| service intent.</t> | ||||
| <t>Example: Update service operator | ||||
| portal platforms and their software | ||||
| regularly. Move services from network | ||||
| operator 1 to network operator 2.</t> </td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td> <t>Service operator designs models, | ||||
| policy intents, and workflows to be | ||||
| used by customer service intents, | ||||
| network service intents, and | ||||
| operational task intents. Workflows | ||||
| can automate any task that the service | ||||
| operator often performs in addition | ||||
| to network service intents and network | ||||
| intents.</t> | ||||
| <t>Example: Request network service | ||||
| guarantee to avoid network congestion | ||||
| during special periods | ||||
| such as Black Friday and Christmas.</t> </td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td rowspan="5">Application Developer</td> | ||||
| <td>Customer Service Intent</td> | ||||
| <td> <t>Customer service intent API provided | ||||
| to the application developers.</t> | ||||
| <t>Example: API to request network to | ||||
| watch HD video (4K/8K).</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Network Service Intent</td> | ||||
| <td> <t>Network service intent API provided to | ||||
| the application developers.</t> | ||||
| <t>Example: API to request network service, | ||||
| monitoring, and traffic grooming.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Network Intent</td> | ||||
| <td> <t>Network intent API provided to the | ||||
| application developers.</t> | ||||
| <t>Example: API to request network | ||||
| resource configurations.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td> <t>Operational task intent API provided | ||||
| to the application developers. This is | ||||
| for the trusted internal operator / service providers / customer DevOps.</t> | ||||
| <t>Example: API to request server | ||||
| migrations.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td> <t>Application developer designs models, | ||||
| policy, and workflows to be used by | ||||
| customer service intents, network | ||||
| service intents, and operational | ||||
| task intents. This is for the trusted | ||||
| internal operator / service provider / customer DevOps.</t> | ||||
| <t>Example: API to design network load-balancing strategies during peak tim | ||||
| es.</t></td> | ||||
| </tr> | ||||
| </tbody> | ||||
| </table> | ||||
| <t>Network Scope: | </section> | |||
| <section anchor="sect-6.3.2" numbered="true" toc="default"> | ||||
| <name>Intent Categories</name> | ||||
| <list style="symbols"> | <t> | |||
| This subsection addresses steps 4 to 7 from <xref target="fig-1"/>. The | ||||
| following are the proposed categories: | ||||
| <t>Network Domain: C1=Radio Access, C2=Transport Access, C3=Transport | </t> | |||
| Aggregation, C4=Transport Core, C5=Cloud Edge, C6=Cloud Core)</t> | <dl> | |||
| <t>Network Function (NF) Scope: C1=VNFs, C2=PNFs</t> | <dt>Intent Scope: | |||
| </dt> | ||||
| <dd>C1=Connectivity, C2=Security/Privacy, C3=Application, C4=QoS | ||||
| </dd> | ||||
| <dt>Network Scope: | ||||
| </dt> | ||||
| <dd> | ||||
| <dl> | ||||
| <dt> | ||||
| </dt> | ||||
| <dd> | ||||
| </dd> | ||||
| <dt>Network Domain: | ||||
| </dt> | ||||
| <dd>C1=Radio Access, C2=Transport Access, C3=Transport Aggregatio | ||||
| n, C4=Transport Core, C5=Cloud Edge, C6=Cloud Core | ||||
| </dd> | ||||
| </list></t> | <dt>Network Function (NF) Scope: | |||
| </dt> | ||||
| <dd>C1=VNFs, C2=PNFs | ||||
| </dd> | ||||
| <t>Abstraction (ABS): C1=Technical (with technical feedback), | </dl> | |||
| C2=Non-technical (without technical feedback) see section 5.2. .</t> | </dd> | |||
| <dt>Abstraction (ABS): | ||||
| </dt> | ||||
| <dd>C1=Technical (with technical feedback), C2=Non-technical (without | ||||
| technical feedback) (see <xref target="sect-5.2"/>). | ||||
| </dd> | ||||
| <t>Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient | <dt>Life cycle (L-C): | |||
| (short lived)</t> | </dt> | |||
| <dd>C1=Persistent (full life cycle), C2=Transient (short lived) | ||||
| </list></t> | </dd> | |||
| </dl> | ||||
| </section> | </section> | |||
| <section anchor="sect-6.3.3" numbered="true" toc="default"> | ||||
| <name>Intent Classification Example</name> | ||||
| <section title="Intent Classification Example" anchor="sect-6.3.3"><t> | <t> | |||
| This section depicts an example on how the methodology described in | This section contains an example of how the methodology described in | |||
| section 6.1. can be used in order to classify intents introduced in | <xref target="sect-6.1"/> can be used in order to classify intents introduced | |||
| the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. This | in the "A | |||
| PoC is led by academics carrying research in the area of SDN/NFV and | Multi-Level Approach to IBN" PoC demonstration <xref target="POC-IBN" | |||
| the specific problem they are addressing is to apply the intent | format="default"/>. This PoC is led by academics carrying out research in the | |||
| concept at different levels that correspond to different | area of SDN/NFV, and the specific problem they are addressing is the applicat | |||
| stakeholders. For this research work, they considered two types of | ion of | |||
| intents: slice intents and service chain intents.</t> | the intent concept at different levels that correspond to different | |||
| stakeholders. For this research work, they considered two types of intents: | ||||
| slice intents and service chain intents.</t> | ||||
| <t> | ||||
| <t> | In this PoC <xref target="POC-IBN" format="default"/>, a slice intent | |||
| In this PoC [POC-IBN], a slice intent expresses a request for a | expresses a request for a network slice with two types of components: a set | |||
| network slice with two types of components: a set of top layer | of top-layer virtual functions and a set of virtual switches and/or | |||
| virtual functions, and a set of virtual switches and/or routers of | routers of L2/L3 VNFs. A service chain intent expresses a request for a | |||
| L2/L3 VNFs. A service chain intent expressed a request for a service | service operated through a chain of service components running in L4-L7 | |||
| operated through a chain of service components running in L4-L7 | ||||
| virtual functions.</t> | virtual functions.</t> | |||
| <t> | ||||
| <t> | ||||
| Following the intent classification methodology described | Following the intent classification methodology described | |||
| step-by-step in section 6.1. , the following can be derived:</t> | step by step in <xref target="sect-6.1"/>, the following can be derived:</t> | |||
| <ol spacing="normal" type="1"><li>The intent solution for both intents | ||||
| <t><list style="numbers"><t>The intent solution for both intents is carri | is carrier network.</li> | |||
| er network.</t> | <li>The intent user type is network operator for the slice intent an | |||
| d | ||||
| <t>The intent user type is network operator for the slice intent, and | service operator for the service chain intent.</li> | |||
| service operator for the service chain intent.</t> | <li>The type of intent is a network service intent for the slice | |||
| intent and a customer service intent for the service chain intent.</li> | ||||
| <t>The type of intent, is a network service intent for the slice | <li>The intent scopes are connectivity and application.</li> | |||
| intent, and a customer service intent for the service chain intent.</t> | <li>The network scope is VNF, cloud edge, and cloud core.</li> | |||
| <li>The abstractions are with technical feedback for the slice inten | ||||
| <t>The intent scopes are connectivity and application.</t> | t | |||
| and without technical feedback for the service chain intent.</li> | ||||
| <t>The network scope is VNF, cloud edge, and cloud core.</t> | <li>The life cycle is persistent.</li> | |||
| </ol> | ||||
| <t>The abstractions are with technical feedback for the slice intent, | <t> | |||
| and without technical feedback for the service chain intent</t> | ||||
| <t>The life-cycle is persistent.</t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | ||||
| The following table shows how to represent this information in a | The following table shows how to represent this information in a | |||
| tabular form. The 'X' in the table refers to the slice intent, and | tabular form. The "X" in the table refers to the slice intent; | |||
| the 'Y' in the table refers to the service chain intent. </t> | the "Y" in the table refers to the service chain intent. </t> | |||
| <figure><artwork><![CDATA[ | ||||
| +---------+---------+-----------+-----+-----------------+-----+-----+ | ||||
| | Intent | Intent | Intent | NF | Network | ABS |L-C | | ||||
| | User | Type | Scope |Scope| Scope | | | | ||||
| | | +-----------+-----+-----------------+-----+-----+ | ||||
| | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| | ||||
| +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Customer |Customer | | | | | | | | | | | | | | | | | | ||||
| |/ Sub- |Service | | | | | | | | | | | | | | | | | | ||||
| | scriber |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Network |Network |X | |X | |X | | | | | |X | |X | |X | | | ||||
| |Operator |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Operatio-| | | | | | | | | | | | | | | | | | ||||
| | |nal Task | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | | | ||||
| |Operator |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Op Task | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |App |Customer | | | | | | | | | | | | | | | | | | ||||
| |Developer|Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Op Task | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| Table 3 - Intent Classification Example for Carrier Solution | <figure title="Intent Classification Example for Carrier Solution"><artwork><![C | |||
| DATA[ | ||||
| +==========+===========+===========+=====+=================+=====+=====+ | ||||
| |Intent |Intent Type|Intent |NF |Network |ABS |L-C | | ||||
| |User | |Scope |Scope|Scope | | | | ||||
| | | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | ||||
| | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| | ||||
| +==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | ||||
| |Customer/ |Customer | | | | | | | | | | | | | | | | | | ||||
| |Subscriber|Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Network |Network |X | |X | |X | | | | | |X | |X | |X | | | ||||
| |Operator |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Operational| | | | | | | | | | | | | | | | | | ||||
| | |Task Intent| | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | | | ||||
| |Operator |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Op Task | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |App |Customer | | | | | | | | | | | | | | | | | | ||||
| |Developer |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Service | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Network | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Op Task | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | |Strategy | | | | | | | | | | | | | | | | | | ||||
| | |Intent | | | | | | | | | | | | | | | | | | ||||
| +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| </section> | ||||
| </section> | </section> | |||
| </section> | ||||
| <section anchor="sect-6.4" numbered="true" toc="default"> | ||||
| <name>Intent Classification for Data Center Network Solutions</name> | ||||
| <section anchor="sect-6.4.1" numbered="true" toc="default"> | ||||
| <name>Intent Users and Intent Types</name> | ||||
| <section title="Intent Classification for Data Center Network Solutions" anchor="sect-6.4"><section title="Intent Users and Intent Types" anchor="sect-6. 4.1"><t> | <t> | |||
| The following table describes the intent users in DC network | The following table describes the intent users in DC network | |||
| solutions and intent types with their descriptions for different | solutions and intent types with their descriptions for different | |||
| intent users.</t> | intent users.</t> | |||
| <figure><artwork><![CDATA[ | <table anchor="intent-classification-DCNS" align="center"> | |||
| +---------------+-------------+-------------------------------------+ | <name>Intent Classification for Data Center Network Solutions</name> | |||
| | Intent User | Intent Type | Intent Type Description | | <thead> | |||
| +-------------------------------------------------------------------+ | <tr> | |||
| | Customer / | Customer | Customer self-service via tenant | | <th>Intent User</th> | |||
| | Tenants | Service | portal. | | <th>Intent Type</th> | |||
| | | | Example: Request GPU computing and | | <th>Intent Type Description</th> | |||
| | | | storage resources to meet 10k video | | </tr> | |||
| | | | surveillance services. | | </thead> | |||
| | +---------------------------------------------------+ | <tbody> | |||
| | | Strategy | This includes models and policy | | <tr> | |||
| | | Intent | intents designed by customers/ | | <td rowspan="2" colspan="1">Customer/Tenants</td> | |||
| | | | tenants to be reused later during | | <td>Customer Service</td> | |||
| | | | instantiation. | | <td><t>Customer self service via tenant portal.</t> | |||
| | | | Example: Request dynamic computing | | <t>Example: Request GPU computing and | |||
| | | | and storage resources of the service| | storage resources to meet 10k video | |||
| | | | in special and daily times. | | surveillance services.</t></td> | |||
| | | | | | </tr> | |||
| +-------------------------------------------------------------------+ | <tr> | |||
| | | Cloud | Configuration of VMs, DB Servers, | | <td>Strategy Intent</td> | |||
| | Cloud | Management | app servers, connectivity, | | <td><t>This includes models and policy | |||
| | Administrator | Intent | communication between VMs. | | intents designed by customers/tenants to be reused later during | |||
| | | | Example: Request connectivity | | instantiation.</t> | |||
| | | | between VMs A,B,and C in network N1.| | <t>Example: Request dynamic computing | |||
| | +---------------------------------------------------+ | and storage resources of the service | |||
| | | Cloud | Policy-driven self-configuration and| | in special and daily times.</t></td> | |||
| | | Resource | and recovery / optimization | | </tr> | |||
| | | Management | Example: Request automatic life | | <tr> | |||
| | | Intent |-cycle management of VM cloud | | <td rowspan="4" colspan="1">Cloud Administrator</td> | |||
| | | | resources. | | <td>Cloud Management Intent</td> | |||
| | +---------------------------------------------------+ | ||||
| | | Operational | Cloud administrator requests | | ||||
| | | Task Intent | execution of any automated task | | ||||
| | | | other than cloud management | | ||||
| | | | intents and cloud resource | | ||||
| | | | management intents. | | ||||
| | | | Example: Request upgrade operating | | ||||
| | | | system to version X on all VMs | | ||||
| | | | in network N1. | | ||||
| | | |Operational statement: an intent to | | ||||
| | | |update a system might reconfigure the| | ||||
| | | |system topology (connect to a service| | ||||
| | | |and to peers), exchange data (update | | ||||
| | | |the content), and uphold a certain | | ||||
| | | |QoE level (allocate sufficient | | ||||
| | | |network resources). The network, | | ||||
| | | |thus, carries out the necessary | | ||||
| | | |configuration to best serve such an | | ||||
| | | |intent; e.g. setting up direct | | ||||
| | | |connections between terminals, and | | ||||
| | | |allocating fair shares of router | | ||||
| | | |queues considering other network | | ||||
| | | |services. | ||||
| | +---------------------------------------------------+ | ||||
| | | Strategy | Cloud administrator designs models, | | ||||
| | | Intent | policy intents and workflows to be | | ||||
| | | | used by other intents. Automate any | | ||||
| | | | tasks that administrator often | | ||||
| | | | performs, in addition to life-cycle | | ||||
| | | | of cloud management intents and | | ||||
| | | | cloud management resource intents. | | ||||
| | | | Example: In case of emergency, | | ||||
| | | | automatically migrate all cloud | | ||||
| | | | resources to DC2. | | ||||
| +---------------+---------------------------------------------------+ | ||||
| | Underlay | Underlay | Service created and provided by | | ||||
| | Network | Network | the underlay network administrator. | | ||||
| | Administrator | Service | Example: Request underlay service | | ||||
| | | Intent | between DC1 and DC2 with | | ||||
| | | | bandwidth B. | | ||||
| | +---------------------------------------------------+ | ||||
| | | Underlay | Underlay network administrator | | ||||
| | | Network | requests some DCN-wide underlay | | ||||
| | | Intent | network configuration or network | | ||||
| | | | resource configurations. | | ||||
| | | | Example: Establish and allocate | | ||||
| | | | DHCP address pool. | | ||||
| | +---------------------------------------------------+ | ||||
| | | Operational | Underlay network administrator | | ||||
| | | Task Intent | requests execution of the any | | ||||
| | | | automated task other than underlay | | ||||
| | | | network service and resource | | ||||
| | | | intent. | | ||||
| | | | Example: Request automatic rapid | | ||||
| | | | detection of device failures and | | ||||
| | | | pre-alarm correlation. | | ||||
| | +---------------------------------------------------+ | ||||
| | | Strategy | Underlay network administrator | | ||||
| | | Intent | designs models, policy intents & | | ||||
| | | | workflows to be used by other | | ||||
| | | | intents. Automate any tasks that | | ||||
| | | | administrator often performs. | | ||||
| | | | Example: For all traffic flows | | ||||
| | | | that need NFV service chaining, | | ||||
| | | | restrict the maximum load of any | | ||||
| | | | VNF node/container below 50% and | | ||||
| | | | the maximum load of any network | | ||||
| | | | link below 70%. | | ||||
| +-------------------------------------------------------------------+ | ||||
| | | Cloud | Cloud management intent API | | ||||
| | | Management | provided to the application | | ||||
| | | Intent | developers. | | ||||
| | | | Example: API to request | | ||||
| | | | configuration of VMs, or DB Servers.| | ||||
| | Application +---------------------------------------------------+ | ||||
| | Developer | Cloud | Cloud resource management intent | | ||||
| | | Resource | API provided to the application | | ||||
| | | Management | developers. | | ||||
| | | Intent | Example: API to request automatic | | ||||
| | | | life-cycle management of cloud | | ||||
| | | | resources. | | ||||
| | +---------------------------------------------------+ | ||||
| | | Underlay | Underlay network service API | | ||||
| | | Network | provided to the application | | ||||
| | | Service | developers. | | ||||
| | | Intent | Example: API to request real-time | | ||||
| | | | monitoring of device condition. | | ||||
| | +---------------------------------------------------+ | ||||
| | | Underlay | Underlay network resource API | | ||||
| | | Network | provided to the application | | ||||
| | | Intent | developers. | | ||||
| | | | Example: API to request dynamic | | ||||
| | | | management of IPv4 address pool | | ||||
| | | | resources. | | ||||
| | | | | | ||||
| | +---------------------------------------------------+ | ||||
| | | Operational | Operational task intent API | | ||||
| | | Task Intent | provided to the trusted | | ||||
| | | | application developer (internal | | ||||
| | | | DevOps). | | ||||
| | | | Example: API to request automatic | | ||||
| | | | rapid detection of device failures | | ||||
| | | | and pre-alarm correlation | | ||||
| | | | | | ||||
| | +---------------------------------------------------+ | ||||
| | | Strategy | Application developer designs | | ||||
| | | Intent | models, policy intents and | | ||||
| | | | building blocks to be used by | | ||||
| | | | other intents. This is for the | | ||||
| | | | trusted internal DCN DevOps. | | ||||
| | | | Example: API to request load | | ||||
| | | | balancing thresholds. | | ||||
| +---------------+-------------+-------------------------------------+ | ||||
| Table 4 - Intent Classification for Data Center Network Solutions | ||||
| ]]></artwork> | ||||
| </figure> | ||||
| </section> | ||||
| <section title="Intent Categories" anchor="sect-6.4.2"><t> | ||||
| The following are the proposed categories: | ||||
| <list style="symbols"> | ||||
| <t>Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, | <td><t>Configuration of VMs, DB Servers, app servers, and communication betw | |||
| C4=QoS C5=Storage C6=Compute</t> | een servers and VMs. | |||
| </t> | ||||
| <t>Example: Request connectivity | ||||
| between VMs A, B, and C in network N1.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Cloud Resource Management Intent</td> | ||||
| <td><t>Policy-driven self configuration | ||||
| and recovery/optimization.</t> | ||||
| <t>Example: Request automatic life-cycle | ||||
| management of VM cloud resources.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td><t>Cloud administrator requests | ||||
| execution of any automated task | ||||
| other than cloud management | ||||
| intents and cloud resource | ||||
| management intents. </t> | ||||
| <t>Example: Request upgrade operating | ||||
| system to version X on all VMs | ||||
| in network N1. </t> | ||||
| <t>Operational statement: An intent to | ||||
| update a system might reconfigure the | ||||
| system topology (connect to a service | ||||
| and to peers), exchange data (update | ||||
| the content), and uphold a certain | ||||
| QoE level (allocate sufficient | ||||
| network resources). Thus, the network | ||||
| carries out the necessary | ||||
| configuration to best serve such an | ||||
| intent, e.g., setting up direct | ||||
| connections between terminals and | ||||
| allocating fair shares of router | ||||
| queues considering other network services.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td><t>Cloud administrator designs models, | ||||
| policy intents, and workflows to be | ||||
| used by other intents. Automate any | ||||
| tasks that administrator often | ||||
| performs in addition to life cycle | ||||
| of cloud management intents and | ||||
| cloud management resource intents.</t> | ||||
| <t>Example: In case of emergency, | ||||
| automatically migrate all cloud | ||||
| resources to DC2.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td rowspan="4" colspan="1">Underlay Network Administrator</td> | ||||
| <td>Underlay Network Service Intent</td> | ||||
| <td><t>Service created and provided by | ||||
| the underlay network administrator.</t> | ||||
| <t>Example: Request underlay service | ||||
| between DC1 and DC2 with bandwidth B.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Underlay Network Intent</td> | ||||
| <td><t>Underlay network administrator | ||||
| requests some DCN-wide underlay | ||||
| network configuration or network | ||||
| resource configurations.</t> | ||||
| <t>Example: Establish and allocate | ||||
| DHCP address pool.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td><t>Underlay network administrator | ||||
| requests execution of any | ||||
| automated task other than underlay | ||||
| network service and resource intent.</t> | ||||
| <t>Example: Request automatic rapid | ||||
| detection of device failures and | ||||
| pre-alarm correlation.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td><t>Underlay network administrator | ||||
| designs models, policy intents, and | ||||
| workflows to be used by other | ||||
| intents. Automate any tasks that | ||||
| the administrator often performs.</t> | ||||
| <t>Example: For all traffic flows | ||||
| that need NFV service chaining, | ||||
| restrict the maximum load of any | ||||
| VNF node/container below 50% and | ||||
| the maximum load of any network | ||||
| link below 70%.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td rowspan="6" colspan="1">Application Developer</td> | ||||
| <td>Cloud Management Intent</td> | ||||
| <td><t>Cloud management intent API | ||||
| provided to the application developers.</t> | ||||
| <t>Example: API to request configuration of VMs or DB Servers. | ||||
| </t></td> | ||||
| </tr> | ||||
| <t>Network Scope | <tr> | |||
| <td>Cloud Resource Management Intent</td> | ||||
| <td><t>Cloud resource management intent | ||||
| API provided to the application developers.</t> | ||||
| <t>Example: | ||||
| API to request automatic | ||||
| life-cycle management of cloud resources.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Underlay Network Service Intent</td> | ||||
| <td><t>Underlay network service API | ||||
| provided to the application | ||||
| developers. </t> | ||||
| <t>Example: API to request real-time | ||||
| monitoring of device condition.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Underlay Network Intent</td> | ||||
| <td><t>Underlay network resource API | ||||
| provided to the application developers.</t> | ||||
| <t>Example: API to request dynamic | ||||
| management of IPv4 address pool resources.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td><t>Operational task intent API | ||||
| provided to the trusted | ||||
| application developer (internal DevOps).</t> | ||||
| <t>Example: API to request automatic | ||||
| rapid detection of device failures | ||||
| and pre-alarm correlation.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td><t>Application developer designs | ||||
| models, policy intents, and | ||||
| building blocks to be used by | ||||
| other intents. This is for the | ||||
| trusted internal DCN DevOps. </t> | ||||
| <t>Example: API to request load-balancing thresholds.</t></td> | ||||
| </tr> | ||||
| </tbody> | ||||
| </table> | ||||
| <list style="symbols"> | </section> | |||
| <section anchor="sect-6.4.2" numbered="true" toc="default"> | ||||
| <name>Intent Categories</name> | ||||
| <t> | ||||
| The following are the proposed categories: | ||||
| <t>Network Domain: DC Network</t> | </t> | |||
| <dl> | ||||
| <t>DCN Network (DCN Net) Scope: C1=Logical, C2=Physical</t> | <dt>Intent Scope: | |||
| </dt> | ||||
| <dd>C1=Connectivity, C2=Security/Privacy, C3=Application, C4=QoS, C5=Storage, C6 | ||||
| =Compute | ||||
| </dd> | ||||
| <t>DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical</t> | <dt>Network Scope | |||
| </list></t> | </dt> | |||
| <dd> | ||||
| </dd> | ||||
| <dt> | ||||
| </dt> | ||||
| <dd> | ||||
| <dl> | ||||
| <dt>Network Domain: | ||||
| </dt> | ||||
| <dd>DC Network | ||||
| </dd> | ||||
| <dt>DCN Network (DCN Net) Scope: | ||||
| </dt> | ||||
| <dd>C1=Logical, C2=Physical | ||||
| </dd> | ||||
| <dt>DCN Resource (DCN Res) Scope: | ||||
| </dt> | ||||
| <dd>C1=Virtual, C2=Physical | ||||
| </dd> | ||||
| </dl> | ||||
| </dd> | ||||
| <t>Abstraction (ABS): C1=Technical (with technical feedback), | <dt>Abstraction (ABS): | |||
| C2=Non-technical (without technical feedback), see section 5.2.</t> | </dt> | |||
| <dd>C1=Technical (with technical feedback), C2=Non-technical (without | ||||
| technical feedback) (see <xref target="sect-5.2"/>). | ||||
| </dd> | ||||
| <t>Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient | <dt>Life cycle (L-C): | |||
| (short lived)</t> | </dt> | |||
| </list></t> | <dd>C1=Persistent (full life cycle), C2=Transient (short lived) | |||
| </section> | </dd> | |||
| <section title="Intent Classification Example" anchor="sect-6.4.3"><t> | </dl> | |||
| This section depicts an example on how the methodology described in | ||||
| section 6.1. can be used by the research community to classify | ||||
| intents. As mentioned in 6.3.3. a successful use of the | ||||
| classification proposed in this draft is introduced in the 'A | ||||
| Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. The PoC is led by | ||||
| academics carrying research in the area of SDN/NFV and the specific | ||||
| problem they are addressing is to apply the intent concept at | ||||
| different levels that correspond to different stakeholders.</t> | ||||
| <t> | </section> | |||
| <section anchor="sect-6.4.3" numbered="true" toc="default"> | ||||
| <name>Intent Classification Example</name> | ||||
| <t> | ||||
| This section depicts an example on how the methodology described in <xref tar | ||||
| get="sect-6.1"/> | ||||
| can be used by the research community to classify intents. As | ||||
| mentioned in <xref target="sect-6.3.3"/>, a successful use of the classificat | ||||
| ion proposed in this | ||||
| document is introduced in the PoC demonstration titled "A Multi-Level Approac | ||||
| h to IBN" <xref target="POC-IBN" format="default"/>. The PoC is led by | ||||
| academics carrying out research in the area of SDN/NFV; the specific problem | ||||
| they are addressing is the application of the intent concept at different lev | ||||
| els that | ||||
| correspond to different stakeholders.</t> | ||||
| <t> | ||||
| For their research work, they considered two types of intents: slice | For their research work, they considered two types of intents: slice | |||
| intents and service chain intents. For the data center solution, only | intents and service chain intents. For the data center solution, only | |||
| the slice intent is relevant.</t> | the slice intent is relevant.</t> | |||
| <t> | ||||
| <t> | As already mentioned in <xref target="sect-6.3.3"/>, a slice intent expresses | |||
| As already mentioned in section 6.3.3. , a slice intent expresses a | a | |||
| request for a network slice with two types of components: a set of | request for a network slice with two types of components: a set of | |||
| top layer virtual functions, and a set of virtual switches and/or | top-layer virtual functions and a set of virtual switches and/or | |||
| routers of L2/L3 VNFs.</t> | routers of L2/L3 VNFs.</t> | |||
| <t> | ||||
| <t> | ||||
| Following the intent classification methodology described | Following the intent classification methodology described | |||
| step-by-step in section 6.1. , we identify the following:</t> | step by step in <xref target="sect-6.1"/>, we identify the following:</t> | |||
| <t><list style="numbers"><t>The intent solution is for the data center.</ | ||||
| t> | ||||
| <t>The intent user type is the cloud administrator for the slice | ||||
| intent and service chain intent.</t> | ||||
| <t>The type of intent, is a cloud management intent, for the slice | ||||
| intent.</t> | ||||
| <t>The intent scopes are connectivity and application.</t> | ||||
| <t>The network scope is logical, and the resource scope is virtual.</t> | ||||
| <t>The abstractions are with technical feedback for the slice intent.</t> | ||||
| <t>The life-cycle is persistent.</t> | ||||
| </list> | ||||
| </t> | ||||
| <t> | <ol spacing="normal" type="1"><li>The intent solution is data center.</li> | |||
| <li>The intent user type is the cloud administrator for the slice | ||||
| intent and service chain intent.</li> | ||||
| <li>The type of intent is a cloud management intent for the slice | ||||
| intent.</li> | ||||
| <li>The intent scopes are connectivity and application.</li> | ||||
| <li>The network scope is logical; the resource scope is virtual.</li | ||||
| > | ||||
| <li>The abstractions are with technical feedback for the slice inten | ||||
| t.</li> | ||||
| <li>The life cycle is persistent.</li> | ||||
| </ol> | ||||
| <t> | ||||
| The following table shows how to represent this information in a | The following table shows how to represent this information in a | |||
| tabular form, where the 'X' in the table refers to the slice intent.</t> | tabular form; the "X" in the table refers to the slice intent.</t> | |||
| <figure><artwork><![CDATA[ | ||||
| +---------+-------------+-----------------+-----+-----+-----+-----+ | ||||
| |Intent | Intent | Intent | DCN | DCN | ABS | L-C | | ||||
| |User | Type | Scope | Res | Net | | | | ||||
| | | +-----------------+-----+-----+-----+-----+ | ||||
| | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| | ||||
| +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Customer | Customer | | | | | | | | | | | | | | | | ||||
| |/Tenants | Service | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | Cloud | Cloud | | | | | | | | | | | | | | | | ||||
| | Admin | Management |X | |X | | | |X | |X | |X | |X | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Cloud | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Underlay | Underlay | | | | | | | | | | | | | | | | ||||
| |Network | Network | | | | | | | | | | | | | | | | ||||
| |Admin | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |App | Cloud | | | | | | | | | | | | | | | | ||||
| |Developer| Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Cloud | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| Table 5 - Intent Classification Example for Data Center Network | <figure title="Intent Classification Example for Data Center Network Solutions"> | |||
| Solutions | <artwork><![CDATA[ | |||
| +===========+=============+=================+=====+=====+=====+=====+ | ||||
| |Intent User| Intent Type |Intent |DCN |DCN |ABS |L-C | | ||||
| | | |Scope |Res |Net | | | | ||||
| | | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | ||||
| | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| | ||||
| +===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | ||||
| |Customer/ | Customer | | | | | | | | | | | | | | | | ||||
| |Tenants | Service | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Cloud Admin| Cloud |X | |X | | | |X | |X | |X | |X | | | ||||
| | | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Cloud | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |Underlay | Underlay | | | | | | | | | | | | | | | | ||||
| |Network | Network | | | | | | | | | | | | | | | | ||||
| |Admin | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| |App | Cloud | | | | | | | | | | | | | | | | ||||
| |Developer | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Cloud | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Management | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Underlay | | | | | | | | | | | | | | | | ||||
| | | Network | | | | | | | | | | | | | | | | ||||
| | | Resource | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Operational | | | | | | | | | | | | | | | | ||||
| | | Task Intent | | | | | | | | | | | | | | | | ||||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| | | Strategy | | | | | | | | | | | | | | | | ||||
| | | Intent | | | | | | | | | | | | | | | | ||||
| +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ||||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| </section> | ||||
| </section> | ||||
| <section title="Intent Classification for Enterprise Solution" anchor="se | </section> | |||
| ct-6.5"><section title="Intent Users and Intent Types" anchor="sect-6.5.1"><t> | </section> | |||
| <section anchor="sect-6.5" numbered="true" toc="default"> | ||||
| <name>Intent Classification for Enterprise Solution</name> | ||||
| <section anchor="sect-6.5.1" numbered="true" toc="default"> | ||||
| <name>Intent Users and Intent Types</name> | ||||
| <t> | ||||
| The following table describes the intent users in enterprise | The following table describes the intent users in enterprise | |||
| solutions and their intent types.</t> | solutions and their intent types.</t> | |||
| <figure><artwork><![CDATA[ | <table anchor="int-class-enterprise-solution"> | |||
| +--------------+-------------+-------------------------------------+ | <name>Intent Classification for Enterprise Solution</name> | |||
| | Intent User | Intent Type | Intent Type Description | | <thead> | |||
| +--------------+---------------------------------------------------+ | <tr> | |||
| | End-User | Customer | Enterprise end-user self-service or | | <td>Intent User</td> | |||
| | | Service | applications, enterprise may have | | <td>Intent Type</td> | |||
| | | Intent | multiple types of end-users. | | <td>Intent Type Description</td> | |||
| | | | Example: Request access to VPN | | </tr> | |||
| | | | service. | | </thead> | |||
| | | | Request video conference between | | <tbody> | |||
| | | | end-user A and B. | | <tr> | |||
| | +---------------------------------------------------+ | <td rowspan="2">End User</td> | |||
| | | Strategy | This includes models and policy | | <td>Customer Service Intent</td> | |||
| | | Intent | intents designed by end-users to be | | <td><t>Enterprise end user self service or | |||
| | | | used by end-user intents and their | | applications; enterprise may have | |||
| | | | applications. | | multiple types of end users.</t> | |||
| | | | Example: Create a video conference | | <t>Example: Request access to VPN service. | |||
| | | | type for a weekly meeting. | | Request video conference between | |||
| +------------------------------------------------------------------+ | end user A and B.</t></td> | |||
| |Enterprise | Network | Service provided by the | | </tr> | |||
| |Administrator | Service | administrator to the end-users | | <tr> | |||
| |(internal or | Intent | and their applications. | | <td>Strategy Intent</td> | |||
| | MSP) | | Example: For any end-user of | | <td><t>This includes models and policy | |||
| | | | application X, the arrival of | | intents designed by end users to be | |||
| | | | hologram objects of all the remote | | used by end-user intents and their applications.</t> | |||
| | | | tele-presenters should be | | <t>Example: Create a video conference | |||
| | | | synchronised within 50ms to reach | | type for a weekly meeting.</t></td> | |||
| | | | the destination viewer for each | | </tr> | |||
| | | | conversation session. | | <tr> | |||
| | | | Create management VPN connectivity | | <td rowspan="4">Enterprise Administrator (internal or MSP)</td> | |||
| | | | for type of service A. | | <td>Network Service Intent</td> | |||
| | | | Operational statement: The job of | | <td><t>Service provided by the | |||
| | | | the network layer is to ensure that | | administrator to the end users | |||
| | | | the delay is between 50-70ms through| | and their applications. </t> | |||
| | | | the routing algorithm. At the same | | <t>Example: For any end user of | |||
| | | | time,the node resources need to meet| | application X, the arrival of | |||
| | | | the bandwidth requirements of 4K | | hologram objects of all the remote | |||
| | | | video conferences. | | tele-presenters should be | |||
| +------------------------------------------------------------------+ | synchronized within 50 ms to reach | |||
| | | Network | Administrator requires network wide | | the destination viewer for each | |||
| | | Intent | configuration (e.g. underlay, | | conversation session. | |||
| | | | campus) or resource configuration | | Create management VPN connectivity | |||
| | | | (switches, routers, policies). | | for type of service A. </t> | |||
| | | | Example: Configure switches in | | <t>Operational statement: The job of | |||
| | | | campus network 1 to prioritise | | the network layer is to ensure that | |||
| | | | traffic of type A. | | the delay is between 50-70 ms through | |||
| | | | Configure YouTube as business | | the routing algorithm. At the same | |||
| | | | non-relevant. | | time, the node resources need to meet | |||
| | +---------------------------------------------------+ | the bandwidth requirements of 4K | |||
| | | Operational | Administrator requests execution of | | video conferences.</t></td> | |||
| | | Task Intent | any automated task other than | | </tr> | |||
| | | | network service intents and network | | <tr> | |||
| | | | intents. | | <td>Network Intent</td> | |||
| | | | Example: Request network security | | <td><t>Administrator requires network-wide | |||
| | | | automated tasks such as web | | configuration (e.g., underlay or | |||
| | | | filtering and DDOS cloud protection.| | campus) or resource configuration | |||
| | +---------------------------------------------------+ | (switches, routers, or policies). </t> | |||
| | | Strategy | Administrator designs models, policy| | <t>Example: Configure switches in | |||
| | | Intent | intents and workflows to be used by | | campus network 1 to prioritize | |||
| | | | other intents. Automate any tasks | | traffic of type A. | |||
| | | | that administrator often performs. | | Configure YouTube as business | |||
| | | | Example: In case of emergency, | | non-relevant.</t></td> | |||
| | | | automatically shift all traffic of | | </tr> | |||
| | | | type A through network N. | | <tr> | |||
| | | | | | <td>Operational Task Intent</td> | |||
| +--------------+-------------+-------------------------------------+ | <td><t>Administrator requests execution of | |||
| | Application | End-User | End-user service / application | | any automated task other than | |||
| | Developer | Intent | intent API provided to the | | network service intents and network intents.</t> | |||
| | | | application developers. | | <t>Example: Request network security | |||
| | | | Example: API for request to open a | | automated tasks such as web | |||
| | | | VPN service. | | filtering and DDoS cloud protection.</t></td> | |||
| | +---------------------------------------------------+ | </tr> | |||
| | | Network | Network service API provided to | | <tr> | |||
| | | Service | application developers. | | <td>Strategy Intent</td> | |||
| | | Intent | Example: API for request network | | <td><t>Administrator designs models, policy | |||
| | | | bandwidth and latency for | | intents, and workflows to be used by | |||
| | | | hosting video conference. | | other intents. Automate any tasks | |||
| | +---------------------------------------------------+ | that the administrator often performs. </t> | |||
| | | Network | Network API provided to application | | <t>Example: In case of emergency, | |||
| | | Intent | developers. | | automatically shift all traffic of | |||
| | | | Example: API for request of network | | type A through network N.</t></td> | |||
| | | | devices configuration. | | </tr> | |||
| | +---------------------------------------------------+ | <tr> | |||
| | | Operational | Operational task intent API provided| | <td rowspan="5">Application Developer</td> | |||
| | | Task Intent | to the trusted application developer| | <td>End-User Intent</td> | |||
| | | | (internal DevOps). | | <td><t>End-user service / application | |||
| | | | Example: API for requesting | | intent API provided to the | |||
| | | | automatic monitoring and | | application developers.</t> | |||
| | | | interception for network security | | <t>Example: API for request to open a | |||
| | +---------------------------------------------------+ | VPN service.</t></td> | |||
| | | Strategy | Application developer designs | | </tr> | |||
| | | Intent | models, policy intents and building | | <tr> | |||
| | | | blocks to be used by other intents. | | <td>Network Service Intent</td> | |||
| | | | This is for the trusted internal | | <td><t>Network service API provided to | |||
| | | | DevOps. | | application developers. </t> | |||
| | | | Example: API for strategy intent in | | <t>Example: API for request network | |||
| | | | case of emergencies. | | bandwidth and latency for | |||
| | | | | | hosting a video conference.</t></td> | |||
| +--------------+-------------+-------------------------------------+ | </tr> | |||
| <tr> | ||||
| Table 6 - Intent Classification for Enterprise Solution | <td>Network Intent</td> | |||
| ]]></artwork> | <td><t>Network API provided to application | |||
| </figure> | developers.</t> | |||
| </section> | <t>Example: API for requesting network | |||
| device configuration.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Operational Task Intent</td> | ||||
| <td><t>Operational task intent API provided | ||||
| to the trusted application developer | ||||
| (internal DevOps).</t> | ||||
| <t>Example: API for requesting | ||||
| automatic monitoring and | ||||
| interception for network security.</t></td> | ||||
| </tr> | ||||
| <tr> | ||||
| <td>Strategy Intent</td> | ||||
| <td><t>Application developer designs | ||||
| models, policy intents, and building | ||||
| blocks to be used by other intents. | ||||
| This is for the trusted internal DevOps.</t> | ||||
| <t>Example: API for strategy intent in | ||||
| case of emergencies.</t></td> | ||||
| </tr> | ||||
| </tbody> | ||||
| </table> | ||||
| <section title="Intent Categories" anchor="sect-6.5.2"><t> | </section> | |||
| <section anchor="sect-6.5.2" numbered="true" toc="default"> | ||||
| <name>Intent Categories</name> | ||||
| <t> | ||||
| The following are the proposed categories: | The following are the proposed categories: | |||
| <list style="symbols"> | </t> | |||
| <t>Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, | <dl> | |||
| C4=QoS</t> | ||||
| <t>Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN</t> | <dt>Intent Scope: | |||
| </dt> | ||||
| <dd>C1=Connectivity, C2=Security/Privacy, C3=Application, C4=QoS | ||||
| </dd> | ||||
| <t>Abstraction (ABS): C1=Technical (with technical feedback), | <dt>Network (Net) Scope: | |||
| C2=Non-technical (without technical feedback), see section 5.2.</t> | </dt> | |||
| <dd>C1=Campus, C2=Branch, C3=SD-WAN | ||||
| </dd> | ||||
| <t>Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient | <dt>Abstraction (ABS): | |||
| (short lived)</t> | </dt> | |||
| <dd>C1=Technical (with technical feedback), C2=Non-technical | ||||
| (without technical feedback) (see <xref target="sect-5.2"/>) | ||||
| </dd> | ||||
| </list></t> | <dt>Life cycle (L-C): | |||
| <t> | </dt> | |||
| <dd>C1=Persistent (full life cycle), C2=Transient (short lived) | ||||
| </dd> | ||||
| </dl> | ||||
| <t> | ||||
| The following is the intent classification table example for | The following is the intent classification table example for | |||
| enterprise solutions.</t> | enterprise solutions.</t> | |||
| <figure><artwork><![CDATA[ | <figure title="Intent Categories for Enterprise Solution "><artwork><![CDATA[ | |||
| +---------------+-------------+-----------+--------+-----+-----+ | +---------------+-------------+-----------+--------+-----+-----+ | |||
| | Intent User | Intent Type | Intent | Net | ABS | L-C | | | Intent User | Intent Type | Intent | Net | ABS | L-C | | |||
| | | | Scope | | | | | | | | Scope | | | | | |||
| | | +-----------+--------+-----+-----+ | | | +-----------+--------+-----+-----+ | |||
| | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| | | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| | |||
| +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| | End-User | Customer | | | | | | | | | | | | | | End User | Customer | | | | | | | | | | | | | |||
| | | Service | | | | | | | | | | | | | | | Service | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| | | Strategy | | | | | | | | | | | | | | | Strategy | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| | Enterprise | Network | | | | | | | | | | | | | | Enterprise | Network | | | | | | | | | | | | | |||
| | Administrator | Service | | | | | | | | | | | | | | Administrator | Service | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| skipping to change at line 1760 ¶ | skipping to change at line 1934 ¶ | |||
| | | Network | | | | | | | | | | | | | | | Network | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| | | Operational | | | | | | | | | | | | | | | Operational | | | | | | | | | | | | | |||
| | | Task | | | | | | | | | | | | | | | Task | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| | | Strategy | | | | | | | | | | | | | | | Strategy | | | | | | | | | | | | | |||
| | | Intent | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | |||
| +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | |||
| Table 7 - Intent Categories for Enterprise Solution | ||||
| ]]></artwork> | ]]></artwork> | |||
| </figure> | </figure> | |||
| </section> | </section> | |||
| </section> | ||||
| </section> | </section> | |||
| <section anchor="sect-7" numbered="true" toc="default"> | ||||
| </section> | <name>Conclusions</name> | |||
| <t> | ||||
| <section title="Conclusions" anchor="sect-7"><t> | ||||
| This document is aligned with the RG objectives and supports | This document is aligned with the RG objectives and supports | |||
| investigations into intent-based networking by proposing an intent | investigations into intent-based networking by proposing an intent | |||
| categorization methodology and taxonomy. It brings clarification on | categorization methodology and taxonomy. It brings clarification to | |||
| what an intent represents for different stakeholders through the | what an intent represents for different stakeholders through the | |||
| proposal of an Intent Classification approach, ensuring that a | proposal of an intent classification approach, ensuring that a | |||
| common understanding among all the participants exists. This, | common understanding among all the participants exists. This, | |||
| together with the proposed intent taxonomy provides a solid | together with the proposed intent taxonomy provides a solid | |||
| foundation for future intent-related topic discussions within NMRG.</t> | foundation for future intent-related discussions within the NMRG.</t> | |||
| <t> | ||||
| <t> | The benefits of this intent classification document in the research community | |||
| The benefits of this intent classification draft in the research | have been demonstrated through a PoC implementation <xref target="POC-IBN" | |||
| community have been demonstrated through a PoC implementation | format="default"/> in which the document's concepts have been applied at diff | |||
| [POC-IBN] in which the draft's concepts at different levels corresponding | erent levels | |||
| to different stakeholders have been applied to.</t> | corresponding to different stakeholders.</t> | |||
| </section> | ||||
| </section> | <section anchor="sect-8" numbered="true" toc="default"> | |||
| <name>Security Considerations</name> | ||||
| <section title="Security Considerations" anchor="sect-8"><t> | <t> | |||
| This document identifies the security and privacy as categories of | This document identifies security and privacy as categories of | |||
| the intent scope. The intents could be solely security intents and | the intent scope. The intents could be solely security intents and | |||
| privacy intents or security can be embedded in the intents that | privacy intents, or security can be embedded in the intents that | |||
| include also connectivity, application, and QoS scope.</t> | include also connectivity, application, and QoS scope.</t> | |||
| <t> | ||||
| Security and privacy scope is when the intent specifies the security | ||||
| characteristics of the network, customers, or end users, and privacy | ||||
| for customers and end users.</t> | ||||
| <t> | ||||
| <t> | More details of these security intents will be described in future | |||
| Security and privacy scope, is when the intent specifies the security | documents that specify architecture, functionality, user intents, and | |||
| characteristics of the network, customers, or end-users, and privacy | models. An analysis of the security considerations of the | |||
| for customers and end-users.</t> | overall intent-based system is provided in <xref target="RFC9315" sectionForm | |||
| at="of" section="9" format="default"/>.</t> | ||||
| <t> | </section> | |||
| More details of these security intents would be described in future | ||||
| documents that specify architecture, functionality, user intents and | ||||
| models. As well, an analysis of the security considerations of the | ||||
| overall intent-based system is provided in section 10 of <xref target="I-D.ir | ||||
| tf-nmrg-ibn-concepts-definitions"/>.</t> | ||||
| </section> | ||||
| <section title="IANA Considerations" anchor="sect-9"><t> | ||||
| This document has no actions for IANA.</t> | ||||
| </section> | ||||
| <section title="Contributors" anchor="sect-10"><t> | ||||
| The following people all contributed to creating this document:</t> | ||||
| <t>Contributed significant text:</t> | ||||
| <figure><artwork><![CDATA[ | ||||
| Xueyuan Sun, China Telecom | ||||
| Will (Shucheng) Liu, Huawei | ||||
| ]]></artwork> | ||||
| </figure> | ||||
| <t>Contributed text in early drafts:</t> | ||||
| <figure><artwork><![CDATA[ | ||||
| Ying Chen, China Unicom | ||||
| John Strassner, Huawei | ||||
| Weiping Xu, Huawei | ||||
| Richard Meade, Huawei | ||||
| ]]></artwork> | ||||
| </figure> | ||||
| </section> | ||||
| <section title="Acknowledgments" anchor="sect-11"><t> | ||||
| This document has benefited from reviews, suggestions, comments and | ||||
| proposed text provided by the following members, listed in | ||||
| alphabetical order: Mehdi Bezahaf, Brian E Carpenter, Laurent | ||||
| Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome | ||||
| Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav | ||||
| Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff | ||||
| Tantsura.</t> | ||||
| <t> | <section anchor="sect-9" numbered="true" toc="default"> | |||
| We thank to Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide | <name>IANA Considerations</name> | |||
| Borsatti, for contributing with their 'A multi-level approach to | <t> | |||
| IBN' PoC demonstration a first attempt to adopt the intent | This document has no IANA actions. | |||
| classification methodology.</t> | </t> | |||
| </section> | ||||
| </section> | </middle> | |||
| </middle> | <back> | |||
| <back> | <references> | |||
| <references title="Informative References"> | <name>Informative References</name> | |||
| <!-- | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9315. | |||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1684): Warning: Faile | xml"/> | |||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C. and Race, N., "To All | ||||
| Intents and Purposes: Towards Flexible Intent Expression," | ||||
| 2021 IEEE 7th International Conference on Network | ||||
| Softwarization (NetSoft), 2021. --> | ||||
| <reference anchor="Bezahaf21"> | <reference anchor="Bezahaf21"> | |||
| <front> | <front> | |||
| <title>To All Intents and Purposes: Towards Flexible Intent Expression< /title> | <title>To All Intents and Purposes: Towards Flexible Intent Expression </title> | |||
| <author initials="M." surname="Bezahaf" fullname="M. Bezahaf"> | <author initials="M." surname="Bezahaf" fullname="M. Bezahaf"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="E." surname="Davies" fullname="E. Davies"> | <author initials="E." surname="Davies" fullname="E. Davies"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="C." surname="Rotsos" fullname="C. Rotsos"> | <author initials="C." surname="Rotsos" fullname="C. Rotsos"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="N." surname="Race" fullname="N. Race"> | <author initials="N." surname="Race" fullname="N. Race"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2021"/> | <date month="July" year="2021"/> | |||
| </front> | </front> | |||
| <seriesInfo name="IEEE 7th International Conference on Network | <seriesInfo name="DOI" value="10.1109/NetSoft51509.2021.9492554"/> | |||
| Softwarization (NetSoft)" value=""/> | <refcontent>IEEE 7th International Conference on Network Softwarization | |||
| (NetSoft)</refcontent> | ||||
| </reference> | </reference> | |||
| <!-- | <reference anchor="Bezahaf19"> | |||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1689): Warning: | ||||
| Failed parsing a reference. Are all elements separated by commas (not | ||||
| periods, not just spaces)?: [Bezhaf19] Bezahaf, M., Hernandez, MP, | ||||
| Bardwell, L., Davies, E., Broadbent, M.,King, D. and Hutchison, D. , | ||||
| "Self-Generated Intent-Based System," 2019 10th International Conference on | ||||
| Networks of the Future (NoF), 2019. | ||||
| --> | ||||
| <reference anchor="Bezhaf19"> | ||||
| <front> | <front> | |||
| <title>Self-Generated Intent-Based System</title> | <title>Self-Generated Intent-Based System</title> | |||
| <author initials="M." surname="Bezahaf" fullname="M. Bezahaf"> | <author initials="M." surname="Bezahaf" fullname="M. Bezahaf"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="M." surname="Hernandez" fullname="M. Hernandez"> | <author initials="M." surname="Hernandez" fullname="M. Hernandez"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="L." surname="Bardwell" fullname="L. Bardwell"> | <author initials="L." surname="Bardwell" fullname="L. Bardwell"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="E." surname="Davies" fullname="E. Davies"> | <author initials="E." surname="Davies" fullname="E. Davies"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="M." surname="Broadbent" fullname="M. Broadbent"> | <author initials="M." surname="Broadbent" fullname="M. Broadbent"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="D." surname="King" fullname="D. King"> | <author initials="D." surname="King" fullname="D. King"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="D." surname="Hutchison" fullname="D. Hutchison"> | <author initials="D." surname="Hutchison" fullname="D. Hutchison"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2019"/> | <date month="October" year="2019"/> | |||
| </front> | </front> | |||
| <seriesInfo name="10th International Conference on Networks of the Futur | <seriesInfo name="DOI" value="10.1109/NoF47743.2019.9015045"/> | |||
| e (NoF)" value=""/> | <refcontent>10th International Conference on Networks of the Future (NoF | |||
| )</refcontent> | ||||
| </reference> | </reference> | |||
| <!-- | ||||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1694): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [Jacobs18] Jacobs, A.S., Pfitscher,R.J., Ferreira, R.A., and Granville, | ||||
| L.Z., "Refining Network Intents for Self-Driving Networks", | ||||
| Proceedings of the Afternoon Workshop on Self-Driving Networks | ||||
| (SelfDN 2018), 2018. | ||||
| --> | ||||
| <reference anchor="Jacobs18"> | <reference anchor="Jacobs18"> | |||
| <front> | <front> | |||
| <title>Refining Network Intents for Self-Driving Networks</title> | <title>Refining Network Intents for Self-Driving Networks</title> | |||
| <author initials="A." surname="Jacobs" fullname="A. Jacobs"> | <author initials="A." surname="Jacobs" fullname="A. Jacobs"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="R." surname="Pfitscher" fullname="R. Pfitscher"> | <author initials="R." surname="Pfitscher" fullname="R. Pfitscher"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="R." surname="Ferreira" fullname="R. Ferreira"> | <author initials="R." surname="Ferreira" fullname="R. Ferreira"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="L." surname="Granville" fullname="L. Granville"> | <author initials="L." surname="Granville" fullname="L. Granville"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2018"/> | <date month="August" year="2018"/> | |||
| </front> | </front> | |||
| <seriesInfo name="Proceedings of the Afternoon Workshop on Self-Driving | <seriesInfo name="DOI" value="10.1145/3229584.3229590"/> | |||
| Networks (SelfDN)" value=""/> | <refcontent>Proceedings of the Afternoon Workshop on Self-Driving Networ | |||
| ks (SelfDN)</refcontent> | ||||
| </reference> | </reference> | |||
| <!-- | ||||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1699): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [Banerjee21] Banerjee,A., Mwanje. S. and Carle, G., "Contradiction | ||||
| Management in Intent-driven Cognitive Autonomous RAN", | ||||
| 2021. | ||||
| --> | ||||
| <reference anchor="Banerjee21"> | <reference anchor="Banerjee21"> | |||
| <front> | <front> | |||
| <title>Contradiction Management in Intent-driven Cognitive Autonomous R AN</title> | <title>Contradiction Management in Intent-driven Cognitive Autonomous RAN</title> | |||
| <author initials="A." surname="Banerjee" fullname="A. Banerjee"> | <author initials="A." surname="Banerjee" fullname="A. Banerjee"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="S." surname="Mwanje" fullname="S. Mwanje"> | <author initials="S." surname="Mwanje" fullname="S. Mwanje"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="G." surname="Carle" fullname="G. Carle"> | <author initials="G." surname="Carle" fullname="G. Carle"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2021"/> | <date month="September" year="2021"/> | |||
| </front> | </front> | |||
| </reference> | </reference> | |||
| <reference anchor="Tian19"><front> | <reference anchor="Tian19"> | |||
| <title>Safely and automatically updating in-network ACL configurations wi | <front> | |||
| th intent language</title> | <title>Safely and automatically updating in-network ACL configurations | |||
| <author initials="B." surname="Tian" fullname="B. Tian"> | with intent language</title> | |||
| <author initials="B." surname="Tian" fullname="B. Tian"> | ||||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="X." surname="Zhang" fullname="X. Zhang"> | <author initials="X." surname="Zhang" fullname="X. Zhang"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="E." surname="Zhai" fullname="E. Zhai"> | <author initials="E." surname="Zhai" fullname="E. Zhai"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="H." surname="Liu" fullname="H. Liu"> | <author initials="H." surname="Liu" fullname="H. Liu"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="Q." surname="Ye" fullname=""> | <author initials="Q." surname="Ye" fullname="Q. Ye"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="C." surname="Wang" fullname="C. Wang"> | <author initials="C." surname="Wang" fullname="C. Wang"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="X." surname="Wu" fullname="X. Wu"> | <author initials="X." surname="Wu" fullname="X. Wu"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="Z." surname="Ji" fullname="Z. Ji"> | <author initials="Z." surname="Ji" fullname="Z. Ji"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="Y." surname="Sang" fullname="Y. Sang"> | <author initials="Y." surname="Sang" fullname="Y. Sang"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="M." surname="Zhang" fullname="M. Zhang"> | <author initials="M." surname="Zhang" fullname="M. Zhang"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="D." surname="Yu" fullname="D. Yu"> | <author initials="D." surname="Yu" fullname="D. Yu"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="C." surname="Tian" fullname="C. Tian"> | <author initials="C." surname="Tian" fullname="C. Tian"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="H." surname="Zheng" fullname="H. Zheng"> | <author initials="H." surname="Zheng" fullname="H. Zheng"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="B." surname="Zhao" fullname="B. Zhao"> | <author initials="B." surname="Zhao" fullname="B. Zhao"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date year="2019"/> | <date month="August" year="2019"/> | |||
| </front> | </front> | |||
| <seriesInfo name="SIGCOMM" value="'19"/> | <seriesInfo name="DOI" value="10.1145/3341302.3342088"/> | |||
| </reference> | <refcontent>SIGCOMM '19: Proceedings of the ACM Special Interest Group o | |||
| n Data Communication</refcontent> | ||||
| <!-- | </reference> | |||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1708): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [Leivadeas21] Leivadeas, A. and Falkner, M., "VNF Placement Problem: | ||||
| A Multi-Tenant Intent-Based Networking Approach," 24th | ||||
| Conference on Innovation in Clouds, Internet and Networks | ||||
| and Workshops (ICIN), 2021. --> | ||||
| <reference anchor="Leivadeas21"> | <reference anchor="Leivadeas21"> | |||
| <front> | <front> | |||
| <title>VNF Placement Problem: A Multi-Tenant Intent-Based Networking Ap proach</title> | <title>VNF Placement Problem: A Multi-Tenant Intent-Based Networking A pproach</title> | |||
| <author initials="A." surname="Leivadeas" fullname="A. Leivadeas"> | <author initials="A." surname="Leivadeas" fullname="A. Leivadeas"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="M." surname="Falkner" fullname="M. Falkner"> | <author initials="M." surname="Falkner" fullname="M. Falkner"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2021"/> | <date month="March" year="2021"/> | |||
| </front> | </front> | |||
| <seriesInfo name="24th Conference on Innovation in Clouds, Internet and | <seriesInfo name="DOI" value="10.1109/ICIN51074.2021.9385553"/> | |||
| Networks and Workshops (ICIN)" value=""/> | <refcontent>24th Conference on Innovation in Clouds, Internet and Networ | |||
| ks and Workshops (ICIN)</refcontent> | ||||
| </reference> | </reference> | |||
| <reference anchor="Davoli21"><front> | <reference anchor="Davoli21"> | |||
| <title>Programmability and Management of Software-defined Network Infrast | <front> | |||
| ructures</title> | <title>Programmability and Management of Software-Defined Network Infr | |||
| <author initials="G." surname="Davoli" fullname="G. Davoli"> | astructures</title> | |||
| <author initials="G." surname="Davoli" fullname="G. Davoli"> | ||||
| </author> | </author> | |||
| <date year="2021"/> | <date year="2021"/> | |||
| </front> | </front> | |||
| </reference> | ||||
| </reference> | <reference anchor="Padovan20"> | |||
| <reference anchor="Padovan20"><front> | <front> | |||
| <title>Design and Implementation of a Blockchain Intent Management System | <title>Design and Implementation of a Blockchain Intent Management Sys | |||
| </title> | tem</title> | |||
| <author initials="S." surname="Padovan" fullname="S. Padovan"> | <author initials="S." surname="Padovan" fullname="S. Padovan"> | |||
| </author> | </author> | |||
| <date year="2020"/> | <date month="November" year="2020"/> | |||
| </front> | </front> | |||
| </reference> | ||||
| </reference> | <reference anchor="Mehmood21"> | |||
| <reference anchor="Mehmood21"><front> | <front> | |||
| <title>Intent-driven Autonomous Network and Service Management in Future | <title>Intent-driven Autonomous Network and Service Management in Futu | |||
| Networks: A Structured Literature Review</title> | re Networks: A Structured Literature Review</title> | |||
| <author initials="K." surname="Mehmood" fullname="K. Mehmood"> | <author initials="K." surname="Mehmood" fullname="K. Mehmood"> | |||
| </author> | </author> | |||
| <author initials="K." surname="Kralevska" fullname="K. Kralevska"> | <author initials="K." surname="Kralevska" fullname="K. Kralevska"> | |||
| </author> | </author> | |||
| <author initials="D." surname="Palma" fullname="Palma, D."> | <author initials="D." surname="Palma" fullname="D. Palma"> | |||
| </author> | </author> | |||
| <date year="2021"/> | <date month="August" year="2021"/> | |||
| </front> | </front> | |||
| <seriesInfo name="DOI" value="10.48550/arXiv.2108.04560"/> | ||||
| </reference> | ||||
| </reference> | <reference anchor="Szilagyi21"> | |||
| <reference anchor="Szilagyi21"><front> | <front> | |||
| <title>I2BN: Intelligent Intent Based Networks</title> | <title>I2BN: Intelligent Intent Based Networks</title> | |||
| <author initials="P." surname="Szilagyi" fullname="P. Szilagyi"> | <author initials="P." surname="Szilágyi " fullname="P. Szilágyi"> | |||
| </author> | </author> | |||
| <date year="2021"/> | <date month="June" year="2021"/> | |||
| </front> | </front> | |||
| <seriesInfo name="Journal" value="of ICT Standardization"/> | <seriesInfo name="DOI" value="10.13052/jicts2245-800X.926"/> | |||
| </reference> | <refcontent>Journal of ICT Standardization</refcontent> | |||
| <refcontent>Volume 9, Issue 2</refcontent> | ||||
| <!-- | </reference> | |||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1726): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [POC-IBN] Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide | ||||
| Borsatti, "A multi-level approach to IBN", July 2020, | ||||
| https://www.ietf.org/proceedings/108/slides/slides-108-nmrg- | ||||
| ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02 | ||||
| --> | ||||
| <reference anchor="POC-IBN" target="https://www.ietf.org/proceedings/108/s lides/slides-108-nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02 "> | <reference anchor="POC-IBN" target="https://www.ietf.org/proceedings/108/s lides/slides-108-nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02 "> | |||
| <front> | <front> | |||
| <title>A multi-level approach to IBN</title> | <title>A Multi-Level Approach to IBN</title> | |||
| <author initials="B." surname="Martini" fullname="B. Martini"> | <author initials="B." surname="Martini" fullname="B. Martini"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="W." surname="Cerroni" fullname="W. Cerroni"> | <author initials="W." surname="Cerroni" fullname="W. Cerroni"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="M." surname="Gharbaoui" fullname="M. Gharbaoui"> | <author initials="M." surname="Gharbaoui" fullname="M. Gharbaoui"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <author initials="D." surname="Borsatti" fullname="D. Borsatti"> | <author initials="D." surname="Borsatti" fullname="D. Borsatti"> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="July" year="2020"/> | <date month="July" year="2020"/> | |||
| </front> | </front> | |||
| <refcontent>IETF 108 Hackathon Report</refcontent> | ||||
| </reference> | </reference> | |||
| <!-- | ||||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1729): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [IFIP-NSM] IFIP - Network and Service Management Taxonomy, | ||||
| https://www.simpleweb.org/ifip/taxonomy.html | ||||
| --> | ||||
| <reference anchor="IFIP-NSM" target="https://www.simpleweb.org/ifip/taxono my.html"> | <reference anchor="IFIP-NSM" target="https://www.simpleweb.org/ifip/taxono my.html"> | |||
| <front> | <front> | |||
| <title>IFIP - Network and Service Management Taxonomy</title> | <title>Network and Service Management Taxonomy</title> | |||
| <author initials="." surname="" fullname=""> | <author> | |||
| <organization/> | <organization>IFIP</organization> | |||
| </author> | </author> | |||
| <date month="" year=""/> | ||||
| </front> | </front> | |||
| <seriesInfo name="" value=""/> | ||||
| </reference> | </reference> | |||
| <!-- | <reference anchor="ONF" target="https://opennetworking.wpengine.com/wp-content/u | |||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1732): Warning: Faile | ploads/2014/10/TR-523_Intent_Definition_Principles.pdf"> | |||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [ONF] ONF, "Intent Definition Principles", 2017, | ||||
| [<https://www.opennetworking.org/images/stories/downloads/sdn- | ||||
| [resources/technical-reports/TR-523_Intent_Definition_Principles.pdf>. | ||||
| --> | ||||
| <reference anchor="ONF" target="https://www.opennetworking.org/images/stor | ||||
| ies/downloads/sdn-resources/technical-reports/TR-523_Intent_Definition_Principle | ||||
| s.pdf"> | ||||
| <front> | <front> | |||
| <title>Intent Definition Principles</title> | <title>Intent NBI - Definition and Principles</title> | |||
| <author initials="." surname="" fullname=""> | <author> | |||
| <organization/> | <organization>Open Networking Foundation</organization> | |||
| </author> | </author> | |||
| <date month="" year="2017"/> | <date month="October" year="2016"/> | |||
| </front> | </front> | |||
| <seriesInfo name="" value=""/> | ||||
| </reference> | </reference> | |||
| <!-- | ||||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1734): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [ONOS] ONOS, "ONOS Intent Framework", 2017, | ||||
| [<https://wiki.onosproject.org/display/ONOS/Intent+Framework/>. | ||||
| --> | ||||
| <reference anchor="ONOS" target="https://wiki.onosproject.org/display/ONOS /Intent+Framework/"> | <reference anchor="ONOS" target="https://wiki.onosproject.org/display/ONOS /Intent+Framework/"> | |||
| <front> | <front> | |||
| <title>ONOS Intent Framework</title> | <title>Intent Framework</title> | |||
| <author initials="." surname="" fullname=""> | <author initials="A" surname="Koshibe" fullname="A. Koshibe"> | |||
| <organization/> | ||||
| </author> | ||||
| <author initials="." surname="" fullname=""> | ||||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="" year="2017"/> | <date year="2016"/> | |||
| </front> | </front> | |||
| <seriesInfo name="" value=""/> | ||||
| </reference> | </reference> | |||
| &I-D.irtf-nmrg-ibn-concepts-definitions; | <reference anchor="TMF-AUTO"> | |||
| <!-- [rfced] [TMF-auto] URL https://www.tmforum.org/wp-content/uploads/2019/05/2 | ||||
| 2553-Autonomous-Networks-whitepaper.pdf --> | ||||
| <!-- | ||||
| draft-irtf-nmrg-ibn-intent-classification-08-manual.txt(1741): Warning: Faile | ||||
| d | ||||
| parsing a reference. Are all elements separated by commas (not periods, not | ||||
| just spaces)?: | ||||
| [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of | ||||
| Autonomous Networks: Empowering Digital Transformation For | ||||
| the Telecoms Industry, inform.tmforum.org, 15 May, 2019. | ||||
| --> | ||||
| <reference anchor="TMF-auto"> | ||||
| <front> | <front> | |||
| <title>A whitepaper of Autonomous Networks: Empowering Digital Transfor mation | <title>Autonomous Networks: Empowering Digital Transformation | |||
| For The Telecoms Industry</title> | For The Telecoms Industry</title> | |||
| <author initials="A." surname="Boasman-Patel" fullname="A. Boasman-Pat el "> | <author initials="A." surname="Boasman-Patel" fullname="A. Boasman-Pat el "> | |||
| <organization/> | <organization/> | |||
| </author> | </author> | |||
| <date month="May" year="2019"/> | <author initials="D." surname="Sun" fullname="D. Sun"> | |||
| <organization/> | ||||
| </author> | ||||
| <author initials="Y." surname="Wang" fullname="Y. Wang"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="C." surname="Maitre" fullname="C. Maitre"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="J." surname="Domingos" fullname="J. Domingos"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="Y." surname="Troullides" fullname="Y. Troullides"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="I." surname="Mas" fullname="I. Mas"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="G." surname="Traver" fullname="G. Traver"> | ||||
| <organization/> | ||||
| </author> | ||||
| <author initials="G." surname="Lupo" fullname="G. Lupo"> | ||||
| <organization/> | ||||
| </author> | ||||
| <date month="May" year="2019"/> | ||||
| </front> | </front> | |||
| <seriesInfo name="" value=""/> | ||||
| </reference> | </reference> | |||
| &RFC2119; | </references> | |||
| &RFC7575; | ||||
| &RFC8328; | ||||
| &RFC3198; | ||||
| &RFC6020; | ||||
| &RFC7285; | ||||
| &I-D.du-anima-an-intent; | ||||
| &I-D.ietf-supa-generic-policy-info-model; | ||||
| &I-D.ietf-anima-prefix-management; | ||||
| </references> | ||||
| </back> | ||||
| </rfc> | <section anchor="sect-11" numbered="false" toc="default"> | |||
| <name>Acknowledgments</name> | ||||
| <t> | ||||
| This document has benefited from reviews, suggestions, comments, and | ||||
| proposed text provided by the following members listed in | ||||
| alphabetical order: <contact fullname="Mehdi Bezahaf"/>, <contact fullname="B | ||||
| rian E. Carpenter"/>, <contact fullname="Laurent | ||||
| Ciavaglia"/>, <contact fullname="Benoit Claise"/>, <contact fullname="Alexand | ||||
| er Clemm"/>, <contact fullname="Yehia Elkhatib"/>, <contact fullname="Jerome | ||||
| Francois"/>, <contact fullname="Pedro Andres Aranda Gutierrez"/>, <contact fu | ||||
| llname="Daniel King"/>, <contact fullname="Branislav | ||||
| Meandzija"/>, <contact fullname="Bob Natale"/>, <contact fullname="Juergen Sc | ||||
| hoenwaelder"/>, <contact fullname="Xiaolin Song"/>, and <contact fullname="Jeff | ||||
| Tantsura"/>.</t> | ||||
| <t> | ||||
| We thank <contact fullname="Barbara Martini"/>, <contact fullname="Walter Cer | ||||
| roni"/>, <contact fullname="Molka Gharbaoui"/>, and <contact fullname="Davide | ||||
| Borsatti"/> for contributing with their "A multi-level approach to | ||||
| IBN" PoC demonstration, a first attempt to adopt the intent | ||||
| classification methodology.</t> | ||||
| </section> | ||||
| <section anchor="sect-10" numbered="false" toc="default"> | ||||
| <name>Contributors</name> | ||||
| <t>The following people all contributed to creating this document:</t> | ||||
| <t>Contributed significant text:</t> | ||||
| <author initials="X" surname="Sun" fullname="Xueyuan Sun"> | ||||
| <organization>China Telecom</organization> | ||||
| </author> | ||||
| <author initials="W" surname="Liu" fullname="Will (Shucheng) Liu"> | ||||
| <organization>Huawei</organization> | ||||
| </author> | ||||
| <t>Contributed text in early draft versions of this document:</t> | ||||
| <author initials="Y" surname="Chen" fullname="Ying Chen"> | ||||
| <organization>China Unicom</organization> | ||||
| </author> | ||||
| <author initials="J" surname="Strassner" fullname="John Strassner"> | ||||
| <organization>Huawei</organization> | ||||
| </author> | ||||
| <author initials="W" surname="Xu" fullname="Weiping Xu"> | ||||
| <organization>Huawei </organization> | ||||
| </author> | ||||
| <author initials="R" surname="Meade" fullname="Richard Meade"> | ||||
| <organization>Huawei</organization> | ||||
| </author> | ||||
| </section> | ||||
| </back> | ||||
| </rfc> | ||||
| End of changes. 279 change blocks. | ||||
| 1756 lines changed or deleted | 1822 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||