Use Cases and Practices for Intent-Based Networking

Use Cases and Practices for Intent-Based Networking China Mobile

Beijing 100053 China yaokehan@chinamobile.com

China Mobile

Beijing 100053 China chendanyang@chinamobile.com

Department of Computer Science and Engineering

Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea +82 31 299 4957 +82 31 290 7996 pauljeong@skku.edu http://iotlab.skku.edu/people-jaehoon-jeong.php

Huawei

bill.wu@huawei.com

Xidian University

cgyang@xidian.edu.cn

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Networking Internet Research Task Force Intent-based networking, network management, artificial intelligence This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system, the construction of the IBN system, the IBN system integration and deployment, and the evaluation and optimization of the IBN system. Practice learnings are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

gives the concepts and definition of Intent-Based Networking (IBN), and proposes a comprehensive taxonomy of the intent classifications. Although the intent life cycle has been defined, including all the core functional components like intent ingestion, intent translation, policy generation, and intent assurance. However, there is still a gap between defining these high-level functionality and building realistic IBN systems. This document proposes several IBN use cases and summarizes the methodologies and practice learnings when building these IBN systems. Main objectives of this document is to instruct future research directions of IBN and other related network management technologies.

This section summarizes the methodologies to build an IBN system. These methodologies refer to the modelling of IBN life cycle and those high-level core functional components, as well as the specific solutions to implement those components. The methodologies are essential to build a real IBN system, beyond the definition in . The methodologies to an IBN system are composed of several important parts, including the system awareness and data collection, construction of IBN systems, integration and deployment, evaluation, optimization, and reconfiguration of intents and policies.

System awareness requires the collection of various network status indicators, like network traffic and resources. Building a valuable dataset is essential for IBN systems. A comprehensive data collection depends on suitable methods and tools, appropriate sampling metrics, and reasonable granularity for data collection. Methods and Tools There are many existing ways to collect network data which can be primarily classified into two types, active measurement and passive measurement. Active measurement like In-band network telemetry (INT) can grab networking information by inserting timestamps into programmable field of on-path packets. Passive measurement, on the other hand, uses some tools like Tcpdump or wireshark to collect data at specific targets, like endpoint servers. IBN systems need both of the ways to collect data, depending on what scenarios they might be applied to. Metrics Metrics include traffic-related and network-related information. Traffic-related metrics are performance indicators, such as latency, throughput, and traffic congestion signals. Network-related information includes network device information, like the number and health status of ports, and network topology information, such as link connectivity and structures. To meet a specific user intention, such as load balancing and congestion elimination on the entire network, IBN systems need to collect and process traffic and device related information. Granularity Network Traffic. Network traffic is usually collected in various forms, such as per-packet and per-flow, and these are two most typical types of data collection. Per-packet means that each packet is tracked, which is very accurate, but it also means greater monitoring overhead and state maintenance overhead. In contrast, per-flow tracking does not need to maintain too much state, and it generally uses five-tuples to identify each flow, which often brings good observation results. Other collection methods are like per-cell and per-flowlet. Per-cell is to track each cell unit whose length remains unchangeable, which is more friendly to system management and control. This method is often applied to Artificial Intelligent (AI) data center network monitoring. The per-flowlet mode cuts a flow into several small flows at a certain interval, which is more suitable for implementing refined load balancing scenarios. The IBN system should select an appropriate traffic collection granularity. Time granularity. Time granularity means that the data acquisition needs to adopt the appropriate time interval for data sampling. In the extreme case, data is collected without interruption. For example, the status information of each data packet is reported to the monitoring module without interruption. This collection method often brings too much redundant information, which leads to a lot of storage and computing overhead to the system. However, the method of sampling without interruption or at a very low time interval can better observe micro-bursts of the networking system. A micro-burst occurs when a large amount of burst data is received in milliseconds. For some black-box network systems and some high-concurrency network systems, it is necessary to sacrifice a certain amount of storage and computing costs to collect data in a finer granularity time slot, so as to make better trade-offs between system overhead and data acquisition accuracy. By analyzing the historical behavior of IBN systems, a reasonable time interval can be selected for data acquisition. Spatial granularity. Spatial granularity indicates that it is necessary to select an appropriate physical scope of a network for data collection. In some cases, the information collection method based on the whole network and the whole domains may not be suitable for all situations, and sometimes the results obtained from the processing and analysis of the collected data may not be accurate (e.g., RTT-based congestion control in data center networking) or incur too much overhead (e.g., hop-by-hop performance monitoring over the Internet). The best way is to match the most appropriate spatial granularity for user intents. For example, in wide-area data transmission, users need to select an optimal path. In this case, sampling is not required for all paths from a source to a destination. Only partial sampling is required for certain path segments which share endpoints, to ensure the correctness of decision makings on path setup in a scenario of multi-path data transmission.

In the construction of an IBN system, intent translation module, policy generation and mapping module, and intent verification module play an important role. The different construction methods and different construction tools used in these modules may affect the advantages of realizing the intention. For different modules, we summarize the methods and tools that have been used and may be used. Intent Translation Translating and refining intents require the system to explore and exploit the semantic relationships of different service intents, and thus it is necessary to build a general model to extract these key semantic information from the service intents in different representation forms. In the intent translation module, several possible intent expression and translation methods are as follows: A limited range of templates are preset in advance, and users can only express corresponding intentions by filling in or selecting templates. The advantage of this method is that the requirements for users and translation are very low, and all users can use it without learning. The disadvantage is that there are many restrictions, which can only be achieved through the preset template, but the preset template is limited, and cannot really meet the flexible and diverse needs of users; Using natural language processing (NLP), such as BERT, for intent translation is another possible approach. First, natural language processing is used to convert a user intent into a text intent, and then the key parameters of text intent are extracted to form the corresponding intent expression. The advantage of this method is high flexibility, users can directly express their intentions in a natural language according to their own needs, without being limited by templates. The disadvantage is that it is difficult to implement and has high requirements for the intent translation module, which needs to be able to accurately identify the real intent of users, and different intents expression paradigms will affect the generation of subsequent policies, so it is necessary to formalize normative intent expression grammars. On the basis of the above natural language-based approach, with the development of AI technologies such as deep learning in the field of text processing, key information in sentences can be extracted by AI model detection. Therefore, based on different AI models, the translation method of category detection and key information extraction of intent representation statements is another approach to intent translation. The advantage of this method is that the expression of the user's intention is more flexible, and the real intention of the user can be mined to a certain extent. The disadvantage is in the deployment cost. Selecting an appropriate AI model to complete the model training is costly. In addition, there are some pre-set expression languages for IBN networks, such as Nile, and NEMO. In the design of these language expressions, most of them consider the flexibility of expression, which can be extended and adjusted according to the intention scenario of the business under consideration. However, these language designs have some disadvantages (e.g., the capability of intent expression). Most of the users are network practitioners, requiring users to have certain network knowledge background. Policy Generation and Mapping In the intent based network, the generation of the corresponding network policy needs to consider both the input intent and the network state, that is, the policy needs to satisfy the user's intent and ensure that the network can be executed to satisfy the requested intent. The policy generation module can be implemented by setting up a repository of “intent” - “policy”, and new mapping relationship should be stored and updated as knowledge according to various intents and dynamic network state telemetry. Similar to different ways of expressing an intent, there are different approaches for policy generation and mapping. As opposed to the default template-based representation in the intent representation module, the simplest approach to policy generation is based on a default template or rule-based provisioning. After the user completes the corresponding intention expression through the graphical interface (e.g., a web-based graphical user interface(GUI)), the user can select the corresponding policy according to the preset template in the policy generation and matching a module or associate the corresponding rules in the constructed rule-based policy generator. Similar to the above analysis, this approach has the advantage of being very simple to implement, but the disadvantage is that it is too restrictive and only a limited number of preset strategies can be selected. The second common method of policy generation and mapping is inference-based generation, such as reasoning based on keywords or keywords in an intention expression, associating keywords with policies, and using circular reasoning to generate policies. This method is more flexible than the template class description method, but the precision of policy generation is more related to the keyword extraction, and there is some uncertainty. In addition, there are policy generation methods based on network service description, which are widely used in service function chaining (SFC), network slicing or network functions virtualization (NFV). In essence, this approach can also be seen as inference-based strategy generation In addition to the above methods, AI technology-based strategy generation methods have also emerged in recent years, such as machine learning technology, which selects corresponding strategies through model training according to keywords extracted from an intention expression. With the development of AI technology, in addition to selecting preset strategies, for example, based on deep reinforcement learning, reasonable reward functions are set to generate strategies that consider user intentions and network status. Intent Deployment The intent translator delivers a policy with detailed configurations or commands to an intent renderer which deploys the policy into target network entities (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator). The intent renderer delivers the policy to the target network entities with a policy delivery protocol such as NETCONF , RESTCONF , or REST API . Intent Verification Intent verification includes intent conflict detection and checking whether intents meet a specific user's requirements or not. The intent conflict detection includes two types: the conflicts between different intents themselves and the conflicts between policies and network states of the target network to perform the requested intent. The conflict of intentions may be due to the conflict between the network states that different users want to obtain. The simplest example is that both users A and B request to increase the bandwidth of 10Gbps, but the network bandwidth of the shared network for users A and B is less than 20Gbps. This conflict caused by different user requirements can be resolved by checking whether the intents can be deployed in practice, that is, you can choose to execute only the intents that can be executed according to the preset rules, and reject other intents. If the generated policy conflicts with the network state, the network state must be detected when the generated policy is generated to ensure that the generated policy can be executed by the target network. If the generated policy cannot be executed, the policy needs to be re-generated. Otherwise, the policy generation of the intent should be reported of a failure to the intent user. In terms of whether the user's intent is satisfied or not, the first way is to feedback the result to the user, and the user judges whether it is satisfied. This way the execution result can be presented through a graphical interface. The second way is to use AI methods such as deep reinforcement learning to determine whether the results meet the needs. Evaluation Evaluation is to judge whether an intent is satisfied by network entities (e.g., switch, router, firewall, web filter, and DDoS-attack mitigator) or not. The intent is translated into a policy with detailed configurations or commands by an intent translator. The policy may have goals in terms of performance (e.g., throughput and delay) and services (e.g., firewall, web filter, and DDoS-attak mitigator). An evaluation entity (e.g., analyzer) needs to collect monitoring data from the network entities and check whether the required goals for each intent are met with specific metrics from the monitoring data or not. This checking can be performed by Artificial Intelligence (AI) and Machine Learning (ML) algorithms. Evaluation results need to be delivered to an optimizer which can augment the existing policy or generate a new policy. Optimization Optimization is to augment the existing policy or generate a new policy to meet the goals of the requested intent. With the evaluation results, an optimization entity (e.g., optimizer) performs optimization for each registered intent. There are two kinds of optimization, such as Quality of Service (QoS) and Service Provisioning. First, the optimizer for QoS deals with the improvement of performance metrics (e.g., throughput and delay). Second, the optimizer for service provisioning handles the service requirements (e.g., firewall filtering, web filtering, and DDoS-attack mitigation). For each optimization, the optimizer augments the existing policy or generates a new policy. It delivers the policy to the intent renderer so that the rendered can enforce the augmented or generated policy into the target network entities. Thus, the steps from Intent Deployment to Optimization construct a closed-loop control to guarantee the goals of the requested intent in a target network.

In this Section, we will describe several scenarios where IBN can be applied. These use cases can reflect the aforementioned methodologies of IBN systems from different perspectives.

IBN can be applied in building network path and generating routing policies according to network administrators' requests.

We use the intent-based dynamic SFC as an example to solve the network management challenges (e.g., cross-domain orchestration and service functions are tightly coupled with the underlying equipment). At the same time, we developed an Openstack-based IBNM platform. The system architecture is shown as Fig 1, which includes the application layer, the intent-enabled layer and the infrastructure layer. The application layer collects intents from various users and applications, and provides a number of programmable network management services. The intent-enabled layer consists of the intent translation module, intelligent policy mapping module, and intent guarantee module, whose functions are to build a bridge between the application layer and the infrastructure layer. Heterogeneous physical devices are deployed in the infrastructure layer. This layer can execute management instructions from the intent-enabled layer and upload underlying network situation information to the intent-enabled layer. Information interaction between different layers is done through different interfaces, such as the northbound and southbound interfaces.

+----------------------------------------+ | Application Layer | +-------------+---------^----------------+ Intent Ingestion| | Northbound Interface +-------------+---------v----------------+ | | Intent-enabled Layer| | +-----------+-------+ +-------------+ | | | | | | | | | | +--------v----+ | | | | | | | Translation | | | | | | | +-------------+ | | | | | | | | Intelligent | | | | +-------------+ | | | | | | | Verification| | | Guarantee | | | | +-------------+ | | | | | |Intent Translation | | Module | | | | Module | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | |Intelligent Policy | | | | | | Mapping Module | | | | | +-------------------+ +-------------+ | | | +--------------------^-------------------+ | Southbound Interface +--------------------v-------------------+ | Infrastructure Layer | +----------------------------------------+ The system demonstration implements the whole process from intent input to intent translation to intent policy generation to intent deployment, and the details are as follows. The user input cross-domain link-building requests (intent) in natural language at the web-page: Transfer a common-level video service from user A in Beijing to user B in Nanjing while constraining the execution time of the intent. The intent translation module outputs a conflict-free translation result, which indicates that the external input and the translation platform have been communicated. The translation results are intent tuples, which are displayed on the front-end interface in the form of name-value pairs. After the intent translation module, the translation results will be converted to JavaScript Object Notation (JSON) and transmitted to the intelligent policy mapping module. The intelligent policy mapping module divides the JSON request into an SFC: service function 1 (network address translation) service function 2 (firewall), and constructs the SFC request (name, tenant_id, description, service requirements, etc.). Then query whether there is an atomic policy combination that satisfies the current intent requirements in the policy repository. Following that, SFC is constructed based on the SFC interface, which is extended by Neutron. OpenStack schedules network resources, constructs sub-nets and ports, and generates two-dimensional space topology. Meanwhile, during the SFC construction process, the intent guarantee module monitors and manages network resource utilization as well as network failures in real time. Overall, IBNM achieves the decoupling of service application and network, and cross-domain network orchestration, while reducing the complexity of network management.

For the automation of configuration and monitoring of Segment Routing version six (SRv6) routers, an IBN-based secure network management is proposed by . The proposed Intent-Based Network Management (IBNM) framework consists of system components and interfaces, as shown in . This framework builds on the framework for Interface to Network Security Functions (I2NSF) .

+-------------+ +-----------------------------+ | IBN User | | Global Distributed Database | +-------------+ +-----------------------------+ ^ ^ | Consumer-Facing Software Update | | Interface Interface (Up) | v v +-------------------+ Registration +-----------------------+ | IBN Controller |<-------------------->| Vendor's Mgmt System | +-------------------+ Interface +-----------------------+ ^ ^ ^ | | Software Update Interface | | | (Down) | | | Analytics Interface +----------------+ | | +------------------------>| IBN Analyzer | | | +----------------+ | | NSF-Facing Interface ^ | | | | | +---------------------+ | | | Monitoring Interface | | | | +---------+------------------+--------------------------------+----+ | v v SRv6 Nodes v | | +-----------------+ +---------------+ +---------------+ | | | NSF-1 |--| NSF-2 | ....... | NSF-n | | | |(Network Exposure| |(Policy Control| | (Application | | | | Function, NEF) | | Function, PCF)| | Function, AF)| | | +-----------------+ +---------------+ +---------------+ | +------------------------------------------------------------------+ A high-level network policy for SRv6 routers is constructed by the IBN Consumer-Facing Interface YANG data model. On the other hand, a low-level network policy is constructed by the IBN NSF-Facing Interface YANG data model. To automate Network Policy Translation (NPT), IBN Controller needs a network policy translator performing the translation of a high-level network policy into the corresponding low-level network policy (i.e., SRv6 policy ). For this automatic NPT service, the IBN framework needs to associate a high-level YANG data model and a low-level YANG data model in an automatic manner, like a data model mapper , .

Taking Network Service-Level Agreement (SLA) performance metrics (e.g., delay measurement), the simple schematic diagram is as follows. Different thresholds, warning value, and alert value should be set for network delay in advance. When the delay value is below warning, the network is normal and the business is normal. When the delay is between warning value and alert value, the network fluctuation is abnormal, but the business is normal. When the delay exceeds the alert value, both the network and business are abnormal. For delay in different thresholds, different measurement strategies should be adopted: When the network delay exceeds the alert value, or when the historical data predict that the delay will exceed the alert value, passive measurement requires 100% sampling of business data, and the transmission frequency of active measurement is modulated to the maximum. At the same time, the log and alarm data of the whole network equipment are collected to realize the most fine-grained measurement of the network, locate the root cause of the problem and repair the network in time. When the network delay exceeds warning value but is lower than alert value, passive measurement samples 60% of business data, and the transmission message frequency of the active measurement is adjusted to the median value, and the running state data of some key devices in the network is collected synchronously. When the network delay is less than warning value, passive measurement data is sampled at 20%, and active measurement message frequency is adjusted to the lowest, and the network equipment running state of key nodes can be collected as needed.

The Clustered Alternate-Marking framework RFC 9342 adds flexibility to Performance Measurement (PM), because it can reduce the order of magnitude of the packet counters. This allows the NMI Orchestration and pre-Verification module to supervise, control, and manage PM in large networks. RFC 9342 introduces the concept of cluster partition of a network. The monitored network can be considered as a whole or split into clusters that are the smallest subnetworks (group-to-group segments), maintaining the packet loss property for each subnetwork. The clusters can be combined in new connected subnetworks at different levels, forming new clusters, depending on the level of detail to achieve. The clustered performance measurement intent represents the spatial accuracy, that is the size of the subnetworks to consider for the monitoring. It is possible to start without examining in depth and, in case of necessity, the "network zooming" approach can be used. This approach called "network zooming" and can be performed in two different ways: change the traffic filter and select more detailed flows; activate new measurement points by defining more specified clusters. The network-zooming approach implies that some filters, rules or flow identifiers are changed. But these changes must be done in a way that do not affect the performance. Therefore there could be a transient time to wait once the new network configuration takes effect. Anyway, if the performance issue is relevant, it is likely to last for a time much longer than the transient time. The concrete steps of the clustered performance measurement intent are as follows: In NMI Recognition and Acquisition, the clustered performance measurement intent is recognized. Then the NMI Recognition and Acquisition module inputs the clustered performance measurement intent into the NMI Translation module. The NMI Translation module analyzes the clustered performance measurement intent and outputs the executable measurement policy, such as network partition and the spatial accuracy for the monitoring. The NMI Orchestration and pre-Verification module arranges and calibrates the measurement with the specific configuration to split the whole network into clusters at different levels. Note that, for the configuration, the YANG Data Model for the Alternate Marking Method can be used. The Data Collection and Analysis module collects the measurement data from the different clusters, and then send these data to the NMI Compliance Assessment module. It verifies the performance for each cluster and send the measurement results to the user. Note that, for the collection of the measurement data, the On-path Telemetry YANG Data Model or the IPFIX Alternate-Marking Information can be used. The NMI Compliance Assessment module, in case a cluster is experiencing a packet loss or the delay is high, notifies the NMI Orchestration and pre-Verification module to modify the cluster partition of the network for further investigation. The network configuration can be immediately modified in order to perform a new partition of the network but only for the cluster with bad performance. In this way, the problem can be localized with successive approximation up to a flow detailed analysis. This is the so-called "closed loop" performance management.

A Cloud-Based Security Service Management is proposed in . It describes Security Management Automation (SMA) of cloud-based security services in the framework of Interface to Network Security Functions (I2NSF) . The security management automation deals with closed-loop security control, security policy translation, and security audit. To support these three features in SMA, an augmented architecture of the I2NSF framework is proposed by introducing new system components and new interfaces.

+------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | | | Analytics Interface +-----------------------+ | +------------------------>| I2NSF Analyzer | | +-----------------------+ | NSF-Facing Interface ^ ^ ^ | | | | | | | | | +------------------------------+ | | | | +-----------------------+ | | | | Monitoring Interface | v v v v +----------------+ +---------------+ +-----------------------+ | NSF-1 |-| NSF-2 |...| NSF-n | | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| +----------------+ +---------------+ +-----------------------+ shows an IBN-driven I2NSF framework for Security Management Automation (called SMA) of cloud-based security service management. I2NSF User composes a high-level security policy (as an intent) and delivers it to Security Controller. Security Controller translates the high-level security policy into the corresponding low-level security policy that is understandable to Network Security Functions (NSFs) for actual security services. Security Controller has a Security Policy Translator (SPT) for this security policy translation . As shown in , for closed-loop security control, this I2NSF framework has Monitoring Interface and Analytics Interface along with I2NSF Analyzer. I2NSF Analyzer collects monitoring data from NSFs via Monitoring Interface. It analyzes the monitoring data using Artificial Intelligence (AI) and Machine Learning (ML). I2NSF Analyzers delivers a policy re-configuration message (e.g., defense against a new security attack ) or feedback information message (e.g., action for handling computing and communication resources) to Security Controller. Security Controller receives the message and takes an appropriate action for the message, such as a security policy re-configuration for target NSFs and remedy action for the feedback information. Therefore, with a security policy translator and a closed-loop security control, we can provide service customers with IBN-based security services.

A Network Management Automation (NMA) can be provided for cellular network services in 5G networks . This NMA is feasible on top of an IBN-empowered framework. It deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X).

Software-Defined Vehicle (SDV) is an electrical vehicle with a software platform (e.g., AUTOSAR and Eclipse SDV) towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform having a cloud-native system (e.g., Kubernetes) and has its internal network (e.g., a giga-bit Ethernet). For facilitating the easy and efficient configuration of networks, security, and applications in the SDV'S in-vehicle networks, an intent-based management is required. An intent-based management framework for SDVs is proposed by . This framework lets SDVs be configured and monitored by a vehicular cloud in terms of networks, security, and applications in SDVs. In this framework, SDVs can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in ITS.

The Life Cycle of IBS for SDV Management SDV User : Translation/ : Network Ops/ Space : IBS Space : App Space Fulfill : : +----------+ : +------------+ +------------+ : +-----------+ |Recognize/|---->| Translate/ |-->| Learn/ |-->| Configure/| | Generate | : | Refine | | Plan/ | : | Provision | | Intent |<----| | | Render | : | | +----------+ : +------------+ +------------+ : +-----------+ ^ : ^ : | ............|..................................|................|..... | : +----------+ : v | : | Validate | : +----------+ | : +----^-----+<----| Monitor/ | Assure | : | : | Observe | +--------+ : +----------+ +----------+<----| | | Report |<-----| Abstract |<-----| Analyze/ | : +----------+ +--------+ : +----------+ | Aggregate| : : +----------+ : According to the life cycle of IBN in , as shown in , the life cycle of an intent-based system (IBS) can be enforced for SDV management. The life cycle consists of three spaces, namely SDV User Space, Translation & IBS Space, and Network Operations (Ops) & Application (App) Space. These spaces are divided into two sections in the life cycle space, such as fulfillment and assurance. The fulfillment section pipelines the steps for an intent enforcement, such as intent input, translation/refinement, learning/planning/rendering, and configuration/provisioning toward the final SFs (e.g., network functions (NFs) and applications in SDVs). On the other hand, the assurance section performs the steps for an Intent assurance and optimization by collecting final results of the intent fulfillment, and validating and analyzing the resulted NFs and applications for SDVs. If an action for the found problem is needed, the life cycle inserts a reconfigured policy into the fulfillment section or report a required action to SDV User.

<Vehicular Cloud (VC)> +---------------------------------------------------------------------+ | +------------------+ +--------------------+ | | | SDV User | +---------->| SDV Database | | | +------------------+ | +--------------------+ | | ^ | ^ | | | | Database | Database | | | | Interface | Interface | | | Consumer-Facing | V | | | Interface (Intent) | +--------------------+ | | | | +-------->| Cloud Analyzer |<-+ | | | | | +--------------------+ | | | V | |Analytics | | | +------------------+<---------+ |Interface | | | | Cloud Controller |<-----------+ +--------------------+ | | | +------------------+<-------------------->|Vendor's Mgmt System| | | | ^ Registration Interface +--------------------+ | | | | ^ | | +----------|------------------------------------------|-------------|-+ | Controller-Facing Interface VMS-Facing | Analyzer- | | (High-level Policy) Interface | Facing | | | Interface | +----------|------------------------------------------|-------------|-+ | | | | | | v v | | | +------------------+ Registration +--------------------+ | | | | SDV Controller |<-------------------->| SDV Vendor's | | | | +------------------+ Interface | Mgmt System | | | | ^ ^ +--------------------+ | | | | | | | | | | | | | | | Analytics Interface +--------------------+ | | | | +------------------------>| SDV Analyzer |<-+ | | | +--------------------+ | | | SF-Facing Interface ^ | | | (Low-level Policy) | | | | | | | | | | | | +--------------+----------------------+---+ | | | | | Monitoring Interface | | | v v v v | | +---------------+ +---------------+ +---------------+ | | | SF-1 | | SF-2 |........| SF-n | | | | (Router) | | (Firewall) | | (Navigator) | | | +---------------+ +---------------+ +---------------+ | +---------------------------------------------------------------------+ <Software-Defined Vehicle (SDV)> shows a framework of intent-based management for SDVs. The framework consists of a vehicular cloud and SDVs. The two parts of the vehicular cloud and SDV borrow the components and interfaces of the I2NSF framework and customize their components and interfaces for IBN-based SDV management.

New network capabilities based on programmability and virtualization are producing service situations where a connectivity-only approach is not sufficient. The increasing availability of computing capabilities internal to the networks, or attached to them, enable new scenarios where those capabilities can be consumed through the advertisement or exposure of these execution environments (i.e., in terms of compute, storage and associated networking resources). In addition or complementary to that, even services or network functions could be advertised in order to make them available for interconnection. An intent-based evolved interconnection framework is proposed by . captures the intent procedure for the fulfillment phase.

User Space : Translation / IBS : Network Ops : Space : Space : : +----------+ : +----------+ +-----------+ : +-----------+ Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| |generate | | | | plan/ | | provision | |intent |<--- | refine | | render | : | | +----------+ : +----------+ +-----------+ : +-----------+ : : ......................................................................... Provider A : Provider B ---------- : ---------- : - Select interconn. : - Mapping of intent types to : - Establishment of intent type : protocols / APIs for : protocol sessions - Specify targeted : coveying targeted resources : or API requests resources (i.e., : - Parametrization of that : for configure or routes, compute : protocols / APIs, e.g. : provisioning quotes, service : leveraging on data models : targeted resources functions, etc.) : : : : Similarly, sketches the intent procedure for the assurance phase.

: +--------+ : : |validate| : +----------+ : +----^---+ <----| monitor/ | Assure +-------+ : +---------+ +-----+---+ : | observe/ | |report | <---- |abstract |<---| analyze | <----| | +-------+ : +---------+ |aggregate| : +----------+ : +---------+ : ..................................................................... Provider A : Provider B ---------- : ---------- : - Analysis of the : - Checking of monitored data : - Collection of reported metrics : for internal closed loops : telemetry info against the intent : to ensure commited SLOs : related to request : (inner closed loop) : allocated - Trigger of actions : - Aggregation of data : resources (i.e., if needed, e.g., : producing an abstracted view: routes, compute new intent (outer : fitted to the intent request: quotes, service closed loop) : : functions, etc.) Both Fulfillment and Assurance phases are integral part of the interconnection intent.

Network slicing is emerging as the future model for service offering in telecom operator networks. Conceptually, network slicing provides a customer with an apparent dedicated network built on top of logical (i.e. virtual) and/or physical functions and resources supported by a shared infrastructure, provided by one or more telecom operators. As part of an end-to-end network slice it is expected to have a number of network slices at transport level (referred as IETF network slices) providing the necessary connectivity to the rest of components of the end-to-end slice, e.g., mobile packet core slice. With this respect, the GSMA has been developing a universal blueprint that can be used by any vertical customer to request the deployment of a network slice instance (NSI) based on a specific set of service requirements. Such a blueprint is a network slice descriptor called Generic Slice Template (GST). The GST contains multiple attributes that can be used to characterize a network slice. A particular template filled with values generates a specific Network Slice Type (NEST). The previous slice templates provide a number of parameters that functionally characterizes the behavior of the network slice as expected by the slice customer. However, apart from the slice characteristics, further information is needed in order to request the realization of a slice towards the IETF Network Slice controller, such as identification of the slice endpoints, information about the virtual network topology expected to form the requested IETF Network Slice, etc. An intent-based evolved interconnection framework is proposed by . captures the intent procedure for the fulfillment phase.

User Space : Translation / IBS : Network Ops : Space : Space : : +----------+ : +----------+ +-----------+ : +-----------+ Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| |generate | | | | plan/ | | provision | |intent |<--- | refine | | render | : | | +----------+ : +----------+ +-----------+ : +-----------+ : : ....................................................................... Slice Customer : Slice Provider -------------- : -------------- : - Customized Slice : - Identification of IETF : - Slice request Templates : network slice endpoints : to IETF NSC - Service SLOs as : and connectivity pattern : by using slice understood by : - Derivation of network SLOs : NBI YANG model slice customer : and SLEs from high-level : : Customer Service SLOs : : : Similarly, sketches the intent procedure for the assurance phase.

: +--------+ : : |validate| : +----------+ : +----^---+ <----| monitor/ | Assure +-------+ : +---------+ +-----+---+ : | observe/ | |report | <---- |abstract |<---| analyze | <----| | +-------+ : +---------+ |aggregate| : +----------+ : +---------+ : ..................................................................... Slice Customer : Slice Provider -------------- : -------------- : - Analysis of the : - Checking of monitored data : - Collection of reported metrics : for internal closed loops : monitoring info against the slice : to ensure commited SLOs and : related to the request : SLEs (inner closed loop) : slice (i.e., - Trigger of actions : - Aggregation of data : SLOs and SLEs of if needed, e.g., : producing an abstracted view: connectivity slice modification : fitted to the slice request : constructs, sdp, (outer closed loop): : etc.) Both Fulfillment and Assurance phases are integral part of the interconnection intent.

Some key learnings and takeaways can be extracted from the practices and implementation of IBN systems in different use cases. Commonly, there involve the following technical challenges in building IBN systems, incluing handling the dynamic and time variant nature of the network, the efficient management of cross-domain resources, and the reliability of automatic configuration, etc. Take Service Function Chaining as an example to show these challenges. 1. Stability in Dynamic Network Environments: For instance, in the space-terrestrial networks where the network topology is with frequent changes, it is essential to design efficient service function chain reconstruction and service recovery mechanisms. But how to guarantee the effectiveness of the chaining rule in these scenarios is still a challenge. 2. Collaborative Management of Cross-domain SFC: To ensure the network intents across multi-domain networks, intent-based networks should be designed with a cross-domain orchestration and management framework to ensure an end-to-end optimization of Quality of Service. 3. Deployment under Resource-constrained Conditions: It is important to consider how to effectively deploy and manage these service function chains within limited resources. Methods such as intent negotiation can be introduced to optimize resource allocation.

Although there have been extensive research achievements from academic, industrial, and standardization fields, there are the following future research considerations. 1. Generic Intent model for Full Life-Cycle Assurance: It is necessary to construct an intent model for the full life-cycle from both top-to-down and down-to-top perspectives, including the intent input state, the intent execution state, and the intent completion state, etc, merged in a generic logic model. It makes sense of ensuring the end-to-end guaranteed implementation of any network intent and verifying the intent state through consistent mathematical logic. 2. Autonomous End-to-End Network Policy Generation: Intent-based networks should provide the network configuration policies to always well understand network service in time, in particular towards various dynamic on-demand service requirements. Therefore, intent-based networks should make the network quality of service satisfy the users’ quality of experience from a vertical perspective of the network protocol or the different intent holders. Meanwhile, current network is based on domain-specific policy local optimization, and it is hard to ensure an end-to-end quality of service guarantee, in particular a cross-domain global optimization. Therefore, intent-based networks should provide an end-to-end optimization policies across multi-domain networking applications. 3. Intent Implementation with Large language Models (LLMs): Large language models(LLMs) will play an important role in enhancing the accuracy of intent refinement, resulting from the powerful understanding capabilities of LLMs and the entity relationships in knowledge graphs. It is also beneficial to network policy generation according to the network status. Although we have involved different kinds of artificial intelligence models at each intent-based networks’ stages, there still lack of generality and accuracy. Meanwhile, human interference is still in the full life-cycle of intent-based networks, and in the future the knowledge graph assisted LLMs can further reduce the human intervention, and even make the human completely be out of the full life-cycle of the intent-based networks.

The Integration of IBN and Network Digital Twin.(TBD) The Integration of IBN, AI and Green.(TBD)

TBD.

This document has no requests to IANA.

The following people have substantially contributed to this document as co-authors:

Hongwei Yang China Mobile Email: yanghongwei@chinamobile.com Giuseppe Fioccola Huawei Email: giuseppe.fioccola@huawei.com Yiwen Shen Sungkyunkwan University Email: chrisshen@skku.edu Yoseop Ahn Sungkyunkwan University Email: ahnjs124@skku.edu Mose Gu Sungkyunkwan University Email: rna0415@skku.edu Jung-Soo Park Electronics and Telecommunications Research Institute Email: pjs@etri.re.kr Yun-Chul Choi Electronics and Telecommunications Research Institute Email: cyc79@etri.re.kr

Principled Design of the Modern Web Architecture

This work of Jaehoon Paul Jeong is supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea government, Ministry of Science and ICT (MSIT) (No. RS-2024-00398199). The work of Luis M. Contreras has been partially funded by the European Union under Horizon Europe project NEMO (NExt generation Meta Operating system) grant number 101070118.