Internet-Draft | An Intent-Based SDV Framework | March 2024 |
Jeong & Shen | Expires 5 September 2024 | [Page] |
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system like Kubernetes and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Software-Defined Vehicle (SDV) is a new paradigm in Intelligent Transportation Systems (ITS). The SDVs interact with each other and infrastructure (e.g., edge servers) for safe driving and infotainment services through vehicular networks, as shown in Figure 1. SDVs can communicates with each other via Vehicle-to-Vehicle (V2V) communications. They can communicate with infrastructure nodes (e.g., gNodeB in 5G [TS-23.501]) via Vehicle-to-Infrastructure (V2I) communications.¶
SDV is regarded as a future platform for autonomous vehicles and electric vehicles. Many automotive-related companies are developing the platform of SDVs, such as AUTOSAR [AUTOSAR-SDV] and Eclipse SDV [Eclipse-SDV]. An SDV consists of computing devices, operating systems, and a cloud-native platform (e.g., Kubernetes [Kubernetes]). Kubernetes is an open-source platform for managing containerized workloads and services with portability and extendibility. It can facilitate intent-based management with both declarative configuration and automation.¶
An SDV needs an intent-based management for networks and security inside its in-vehicle networks. An intent is a declarative command to request a configuration for a network or security function [TS-28.312][TR-28.812]. It emphasizes more on ``What'' is needed (i.e., declarative command) to be accomplished than ``How'' it should be accomplished (i.e., imperative command). Since there are a huge number of vehicles produced by each automotive company, the networks and security for the SDV needs to be remotely configured and monitored by a control center of each automotive company. The in-vehicle networks are based on Gigabit Ethernet and can be configured as multiple subnets including Electric Control Units (ECU) and infotainment devices. It requires huge overhead for an operator to configure and monitor networks and security for those in-vehicle networks.¶
This document proposes a framework of intent-based management for networks, security, and applications in SDVs that are Service Functions (SFs). Such SFs can be contructed and managed by Software-Defined Networking (SDN) [RFC7149], Network Functions Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2], and Cloud Native Computing Platform (e.g., Kubernetes [Kubernetes]). This framework automates the configuration and monitoring for the networks and security in each SDV through a vehicular cloud and the SDV's mobile network. An SDV User (i.e., administrator) for the management of SDVs can configure and monitor the networks and security through an intent. The intent from the SDV User is delivered to a Cloud Controller in charge of a vehicular cloud for SDVs. The Cloud Controller translates the intent into the corresponding high-level policy, and delivers the high-level policy to an SDV Controller in charge of an SDV. The SDV translates the high-level policy into the corresponding low-level policy and delivered it to an appropriate Network Function (NF) for a specific service (e.g., router, firewall, and navigator) in the SDV.¶
This document uses the terminology described in [RFC8329], [I-D.ietf-i2nsf-applicability], [I-D.jeong-i2nsf-security-management-automation], [I-D.jeong-nmrg-ibn-network-management-automation], and [I-D.yang-i2nsf-security-policy-translation]. In addition, the following terms are defined below:¶
Intent: 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 [RFC9315].¶
Intent-Based Management (IBM): It enforces an intent from a user (or administrator) into a target system (e.g., SDV). An intent can be expressed as a Natural Language (e.g., English) and can be translated into a high-level policy by a Natural Language Processing (NLP) [USENIX-ATC-Lumi][BERT] [Deep-Learning]. In this document, the intent can be translated into the corresponding high-level policy by an intent translator [I-D.jeong-i2nsf-security-management-automation]. The high-level policy can also be translated into the corresponding low-level policy by a policy translator [I-D.yang-i2nsf-security-policy-translation]. The low-level policy is dispatched to appropriate Service Functions (SFs). Through the monitoring of the SFs, the activity and performace of the SFs is monitored and analyzed. If needed, the rules of the high-level or low-level network policy are augmented or new rules are generated and configured to appropriate SFs.¶
SDVs are managed and monitored by the vehicular cloud. They get help for software updates as well as the configuration of their networks and security from the vehicular cloud. Figure 1 shows a vehicular network architecture for SDVs. SDVs as vehicles can communicate with each other via V2V and with infrastructure nodes such as IP Road-Side Unit (IP-RSU), for example, gNodeB in 5G networks, respectively. Edge servers can help SDVs to perform their safe driving by processing environmental data collected by the SDVs and giving maneuver guidance to the SDVs.¶
An SDV has its own internal networks (called in-vehicle networks), as shown in Figure 2. The in-vehicle networks consist of multiple subnets connected with each other through routers. IP On-Board Unit (IP-OBU) is a network device in an SDV that has a basic processing ability and can be driven by a low-power CPU (e.g., ARM) with 5G Vehicle-to-Everything (V2X) communication device [RFC9365]. IP Road-Side Unit (IP-RSU) is a network device situated along the road as an infrastructure node. It has at least two distinct IP-enabled interfaces where one is for 5G V2X and the other is for the wired network connected to the vehicular cloud [RFC9365]. An Edge Network (EN) is a radio access network which has an IP-RSU for wireless communication with other SDVs having an IP-OBU and wired communication with other network devices (e.g., routers, IP-RSUs, and edge servers) [RFC9365]. As shown in Figure 2, the IPv6 prefixes should be configured for the in-vehicle network (called mobile network) and Edge Network (called EN). Also, for V2X IP networking, the wireless interfaces of IP-OBU and IP-RSU should be configured with appropriate IPv6 network prefixes and default gateways towards the infrastructure network connected to the vehicular cloud.¶
For the automatic network configuration of SDVs, an intent-based management is required between the vehicular cloud and SDVs [I-D.jeong-nmrg-ibn-network-management-automation]. Figure 3 shows a framework of intent-based management for SDVs. The framework consists of a vehicular cloud and SDVs. The vehicular cloud consists of SDV User (as network administrator), Cloud Controller (as an orchestrator for a vehicular cloud), SDV Database (as a main repository for SDV management and monitoring), and Cloud Analyzer (as a monitoring data analyzer for SDVs) such as Network Data Analytics Function (NWDAF) in 5G networks [TS-23.288][TS-29.520]. The SDV is composed of SDV Controller (as a manager for an SDV), SDV Analyzer (as a monitoring data analyzer for an SDV) [I-D.jeong-nmrg-ibn-network-management-automation], Vendor's Management System (as a vendor system to provide cloud-native containers) [RFC8329][I-D.ietf-i2nsf-applicability], and Network Functions (NF) such as router, DNS server, and firewall [I-D.jeong-nmrg-ibn-network-management-automation]. In this figure, interfaces are defined between a pair of system components in the vehicular cloud and SDV. The intent, high-level policy, and low-level policy can be either XML documents [RFC6020][RFC7950] or YAML documents [YAML]. They can be delivered to the destination components via NETCONF [RFC6241], RESTCONF [RFC8040], or REST API [REST].¶
As shown in Figure 3, the Intent-Based Management SDV Framework enforces an intent from an SDV User, which as a user (or administrator), into a target system such as SDV. The intent from the SDV User can be translated into the corresponding high-level policy by an intent translator in the Cloud Controller of the Vehicular Cloud [I-D.jeong-i2nsf-security-management-automation]. The high-level policy can also be translated into the corresponding low-level policy by a policy translator in the SDV Controller of the SDV [I-D.yang-i2nsf-security-policy-translation]. The low-level policy is dispatched from the SDV Controller to appropriate Service Functions (SFs) in the SDV, such as Router, Firewall, and Navigator, as shown in the figure. Through the monitoring of the SFs, the activity and performace of the SFs in the SDV is monitored and analyzed by the SDV Analyzer in the SDV. If needed, the rules of the high-level or low-level network policy can be augmented by the SDV Analyzer. Also, new rules can be automatically generated and configured to appropriate SFs by the SDV Analyzer.¶
Therefore, this document proposes a framework of intent-based management for networks in a Software-Defined Vehicle (called SDV). Through this intent-based management, SDVs can communicate with other SDVs and infrastructure nodes (e.g., IP-RSU) via V2X communications for safe driving and infotainment services in vehicular networks. As future work, we will design and implement YANG data models for the system components and interfaces in the intent-based management framework for SDVs.¶
This document does not require any IANA actions.¶
The same security considerations for the Interface to Network Security Functions (I2NSF) Framework [RFC8329] are applicable to the intent-based management framework this document.¶
This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT)(No. 2022-0-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).¶
This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. 2022-0-01199, Regional strategic industry convergence security core talent training business).¶
This document is made by the group effort of OPWAWG, greatly benefiting from inputs and texts by Linda Dunbar (Futurewei) Yong-Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui University). The authors sincerely appreciate their contributions.¶
The following are coauthors of this document:¶