RTGWG Working Group F. Yang Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: April 20, 2023 New H3C Technologies October 20, 2024 Application-Responsive Network Framework draft-yang-rtgwg-arn-framework-02 Abstract With the deployment of increasingly advanced technologies on a large scale, such as SRv6 and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 20, 2023. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. YANG, et al. Expire April 20, 2023 [Page 1] Internet-Draft Application-Responsive Network Framework October 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................2 2. Requirements Language..........................................3 3. Terminology....................................................3 4. Gaps...........................................................3 5. Design Goal....................................................4 6. ARN Framework and Components...................................6 6.1. ARN ID....................................................6 6.2. Application...............................................6 6.3. User Edge Device..........................................7 6.4. The network edge device...................................7 6.5. Controller................................................8 6.6. The Southbound Interface (SBI) of the Controller:.........8 7. ARN Encapsulation..............................................8 7.1. Locations for IPv6 ARN....................................8 7.2. Locations for IPv4 ARN....................................9 8. Use case......................................................10 9. Security Considerations.......................................11 10. IANA Considerations..........................................11 11. References...................................................11 11.1. Normative References....................................11 Authors' Addresses...............................................12 1. Introduction With the widespread application of new technologies such as 5G, cloud computing, big data, and AI, network traffic patterns are becoming increasingly complex and diversified. Various emerging services have higher requirements for QoS parameters such as network latency, bandwidth, jitter, and packet loss. Networks typically need to prioritize critical services. For example, in office networks, video conferencing requires network priority to ensure that video and voice services do not experience buffering and excessive delays. However, the applications used for video and voice services may vary in different industries and office YANG, et al. Expires April 20, 2023 [Page 2] Internet-Draft Application-Responsive Network Framework October 2024 network scenarios, so it is necessary to identify these applications to further ensure the quality of service. Some specific services have explicit SLA (Service Level Agreement) requirements. In business scenarios such as autonomous driving, industrial control, and remote control, there are clear SLA requirements for the network, such as latency not exceeding 50ms and jitter not exceeding 1ms. In traditional IP networks, ACLs are typically used on critical network devices to implement application identification and policy configuration. Based on packet characteristics such as the five- tuple, network can provide guaranteed service for specific users or applications. Different network services have their own ACL matching entries and policies, which need to be continuously adjusted as services evolve. Over time, configurations become invalid due to not being revoked or modified in a timely manner. This is not sufficient for general solution. This article proposes a new framework called Application Responsive Network (ARN), which abstracts and represents personalized network services based on user demand awareness, provided through ARN Service identifiers (ARN IDs). Network services can be encapsulated by ARN IDs, thus it can be called by user. The vision is to enable applications to access network resources like they access an operating system. The application here can be network service implemented on a gateway or software that can program the ARN ID. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology ARN: Application-Responsive Networking ACL: Access Control List 4. Gaps There are still the following key gaps in current network technology: YANG, et al. Expires April 20, 2023 [Page 3] Internet-Draft Application-Responsive Network Framework October 2024 Application-aware features. It is necessary to provide differentiated services based on the different services of the same user. For example, video conferencing needs to avoid stuttering or screen tearing due to congestion and packet loss to ensure a customer experience, while general web browsing services can strive for the best. Data plane programming capabilities. Identify and classify user application data, and transfer it to the appropriate service-level tunnel based on the results. Ability to perceive the user experience. Through real-time detection and perception of user-level service experience, it works with intelligent routing to ensure service assurance for high-priority services. Currently, there is a lack of traffic identification for rapid classification and statistical analysis of the user experience of this type of traffic. Ability to prevent leakage of network services. The security of the access network is relatively poor, and there is a risk of leakage of information related to user applications. 5. Design Goal As shown in Figure 1, an ARN intermediate layer is added between the application and the network, mapping is accomplished using ARN IDs. The ARN ID is a simple number that encapsulates network capabilities internally and hides network information externally, thus avoiding the exposure of application privacy and facilitating user application invocation. +---+ +-----+ | A | +-------+ |App |--->| R |--->|Network| +-----+ | N | +-------+ +---+ Figure 1: ARN Intermediate Layer Diagram ARN Network Design Goals: * Open and programmable network capabilities One of the design principles of ARN is to open and program network capabilities based on the data plane. By opening programming interfaces on the data plane in a software-based manner, applications can call network resources like calling an operating YANG, et al. Expires April 20, 2023 [Page 4] Internet-Draft Application-Responsive Network Framework October 2024 system. In today's digital world, user demands for the network far exceed simple connectivity functions. Users expect the network to provide stable, high-speed connections to meet diverse application requirements. Even for the same type of application, usage requirements may vary across different industries and scenarios. Allowing applications to call on network capabilities through data plane programming provides corresponding guarantees for different types of packets. * Decoupling of addresses and services Another design principle of ARN is to decouple addresses and services. Traditional network design is based on addresses, managing and routing based on destination addresses to determine the forwarding services provided by the network. However, with the increasing variety of user applications, relying on addresses to carry service levels has made network management increasingly complex. Therefore, it is necessary to manage and optimize the network based on the characteristics and requirements of user applications, separating addresses from services to provide multidimensional forwarding services. * Decoupling of network and applications The third design principle of ARN is to decouple the network and applications. By adding an ARN layer between the network and applications, the network does not need to directly perceive the applications, thus shielding the diversity of applications and preventing direct access to network capabilities. Through ARN, the network and applications can be encapsulated separately, achieving application privacy and the concealment of internal network information. At the same time, based on this encapsulation, access control can be implemented during the application's network calls, realizing an authorization token-based calling mechanism similar to software programming. * Unified abstraction of network resources The fourth design principle of ARN is the unified abstraction of multiple network resources. With the development of personalized and diversified network services, the network resources used in forwarding user packets are becoming increasingly rich, such as computing power, network slicing, service chaining, and more. During the use of these network resources, additional identifiers are often carried in the packets to determine the mapping relationship between users or applications and network resources, or ACLs are used to parse and match the feature information in the packet to determine the associated network resources. In the ARN network, multiple network resources can be uniformly represented by ARN IDs, reducing YANG, et al. Expires April 20, 2023 [Page 5] Internet-Draft Application-Responsive Network Framework October 2024 the complexity of data plane identifiers and simplifying operational deployments. 6. ARN Framework and Components ARN Framework, as illustrated in Figure 2, consists of key components including user edge devices, network edge devices, and network controllers at different levels. +----------------------+ | Controller | +----------------------+ | | | |SBI | SBI | +----+ +----+ +----+ +----+ +-------+ |App |---->|User|----->| | | | | | +----+ |Edge| |Net | |Net | |Cloud | +----+ |work|--|work|------>| | +----+ |Edge| |Edge| |Service| |App |---------------->| | | | | | +----+ +----+ +----+ +-------+ Access Backbone Figure 2: Framework and Key Components 6.1. ARN ID The ARN ID can be generated by the controller based on the user service subscription information and network service information, and the generated ARN ID will be configured to both user edge devices and network edge devices. User service subscription information may include user information, e.g. PPPoE, and application information, e.g. 5 tuple. The network service information can be pre-planed network pathes, e.g. SR policies. The ARN ID represents the application's invocation of network capabilities and/or the network's ability to be open to the application. The ARN ID also represents a contractual relationship, and therefore requires lifecycle management of ARN ID, e.g., revocation, loss reporting, replacing, aging, and deferring operations. 6.2. Application User applications require networks to provide differentiated services, especially those based on SR technology. There are two scenarios. YANG, et al. Expires April 20, 2023 [Page 6] Internet-Draft Application-Responsive Network Framework October 2024 The first scenario is that the user's application supports ARN. By delivering ARN ID to user, user can encapsulate ARN ID for certain application to achieve differentiated services. In this case, the application needs to insert the ARN ID into the extension header of the IPv6 packet. The second scenario is that the user's application does not support ARN. In this case, network service provider needs to deliver ARN ID to user edge device and map application traffic to the ARN ID to achieve differentiated services. 6.3. User Edge Device The user edge devices are responsible for accessing the user applications and are the boundary of the access network. The access network will not be a part of SRv6 or MPLS domains. The ARN IDs are configured between the user edge device and the network edge device, and the controller only needs to ensure that the ARN ID generated based on different user subscription information and network service information is unique within this range. The user edge device will identify the relevant IP traffic and mark the packet based on the received ARN ID, and then transmits it to network edge device.The ARN ID may be encapsulated into the extension header of the IPv6 packet, which will be explained in detail in section 7. In this case, an extra IPv6 header is needed. 6.4. The network edge device The network edge devices aggregate the traffic from access network, which is the edge of the backbone network. The backbone network runs SRv6 and MPLS. The network edge device is the boundary of the backbone network, which is the starting point of network service, e.g. tunnels such as SR Policies with various characteristics. Of course, SR Policies are pre-planned by the network. The network edge devices will receive both ARN IDs and the mapping of ARN IDs to those pre-planed tunnels from the network controller. Upon receiving a packet from user edge device, the network edge devices extract the ARN ID, aggregate the services, and provide the corresponding network service guarantees during the forwarding process based on the ARN ID. YANG, et al. Expires April 20, 2023 [Page 7] Internet-Draft Application-Responsive Network Framework October 2024 After receiving a packet containing ARN ID from a user edge device, a network edge device must first verify the validity of the packet, also known as access control. Access Control: Controls whether to trust the incoming ARN ID of the packet and performs verification. If ARN ID is valid, the network edge device will perform path mapping function and rate limiting, then do packet forwarding. Otherwise, the ARN ID is cleared or the packet is discarded. Path Mapping: The network edge device should map the IPv6 packet to the corresponding network service, e.g. SR Policy, based on the ARN ID in the packet, that is, SR Policies. Rate Limiting: Imposes traffic limits on specific ARN IDs, typically deployed at the network edge device. 6.5. Controller The controller generates ARN IDs in the way mentioned in section 6.1. The controller also configures user edge devices and network edge devices, and manages the lifecycle of ARN IDs. The controller will send the ARN ID and the application characteristics corresponding to the ARN ID to the user edge device. The controller will send user information and ARN ID preset correspondence information to network edge device, which is used for access control. At the same time, the controller will send the path information and the preset correspondence of the ARN ID to the network edge device, and the path information can be SR Policy. A single controller can be centrally used, or multiple controllers can be utilized to collectively fulfill the functions across various stages of the network. 6.6. The Southbound Interface (SBI) of the Controller: The ARN ID and ARN service policies are communicated from the controller to the relevant network devices through this interface for execution. Potential protocols for this interface include PCEP, BGP, and YANG-based protocols such as NETCONF/RESTCONF. 7. ARN Encapsulation 7.1. Locations for IPv6 ARN The ARN carries the ARN ID option, including the ARN ID, through the extension of the IPv6 data plane. This information can be located YANG, et al. Expires April 20, 2023 [Page 8] Internet-Draft Application-Responsive Network Framework October 2024 within the IPv6 Destination Options Header (DOH) or the IPv6 Hop-by- Hop Options Header (HBH). The ARN ID option may reside in the IPv6 Destination Options Header, allowing the destination node to read the information while it remains unseen by other nodes along the path. Alternatively, the ARN ID option can be placed in the IPv6 Hop-by- Hop Options Header, enabling every node along the path to read the information. If the originating application places the ARN ID, it uses the IPv6 HBH option in the IPv6 packet it sends. Conversely, if the user agent adds the ARN ID based on the controller's configuration, it encapsulates the application packet in an outer IPv6 header, addresses that header to the network agent, and includes the ARN ID in a DOH option for processing by the network agent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ARN ID Option Option Type: 8 Bits, ARN option, value to be allocated ARN ID: 32 Bits 7.2. Locations for IPv4 ARN TBD. YANG, et al. Expires April 20, 2023 [Page 9] Internet-Draft Application-Responsive Network Framework October 2024 8. Use case Network Controller | | | | +----+ A +----+ +-------+ +-----+ |Back|------|Back| |DC | | HGW |------>|bone| B |bone| |Cloud | +-----+ |Edge|------|Edge|-----| | User | | C | | | | |Bras|------| | |Service| +----+ +----+ +-------+ Figure 7: Use case of ARN This is a typical network where users access the network through a Bras server, then via the backbone network, and finally access the data center cloud services. Functions implemented by each device: Home Gate Way(HGW): Acts as the user edge device, ARN ID can be directly marked by it based on the services user has purchased and flow characteristics of the application. Bras: Provides functions such as access control based on Service-ID, path mapping, service aggregation, and rate limiting. If the incoming datagram carries an ARN ID, and the receiving interface has turned on ARN. The legitimacy of the ARN ID can be verified. If the ARN ID does not belong to the user, the verification will fail, and the ARN ID will be cleared or the entire datagram will be discarded. Otherwise, it will perform Path Mapping based on incoming ARN ID. Network Controller: Configure user information and ARN ID mappings for HGW. Configure access control, path mapping, and rate limiting based on ARN ID for Bras. Cloud Services: Provides specific application services. Based on the different types of ARN services purchased by users, when mapping paths in the domain for forwarding user traffic, three network paths can be chosen according to the rules deployed by the controller to meet the users' network requirements. As different applications may have varying network demands, the five-tuple of the datagrams is mapped to corresponding ARN IDs for different network services. This enables the network's entry router to select different network paths based on the different ARN IDs: YANG, et al. Expires April 20, 2023 [Page 10] Internet-Draft Application-Responsive Network Framework October 2024 Network Path A: Network path characterized by high bandwidth Network Path B: Network path characterized by low latency Network Path C: Network path characterized by low packet loss If a user's different applications have varying network requirements, the user can directly include the corresponding network service's ARN ID in the transmitted datagrams. This allows the network's entry router to select different network paths based on the different ARN IDs. 9. Security Considerations TBD. 10. IANA Considerations TBD. 11. References 11.1. Normative References RFC2460 S. Deering, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 YANG, et al. Expires April 20, 2023 [Page 11] Internet-Draft Application-Responsive Network Framework October 2024 Authors' Addresses Feng Yang China Mobile Beijing China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com YANG, et al. Expires April 20, 2023 [Page 12]