RTGWG Working Group F. Yang Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: November 10, 2024 New H3C Technologies May 10, 2024 Application-Responsive Network Framework draft-yang-rtgwg-arn-framework-01 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 November 10, 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. YANG, et al. Expire November 10, 2024 [Page 1] Internet-Draft Application-Responsive Network Framework May 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 2. Requirements Language..........................................3 3. Terminology....................................................4 4. Gasp...........................................................4 5. Design Goal....................................................4 6. ARN Framework and Components...................................6 6.1. User Edge Device..........................................7 6.2. The network boundary entry device.........................7 6.3. Controller................................................8 6.4. 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...................................10 8. Use case......................................................11 9. Security Considerations.......................................12 10. IANA Considerations..........................................12 11. References...................................................13 11.1. Normative References....................................13 Authors' Addresses...............................................14 YANG, et al. Expires November 10, 2024 [Page 2] Internet-Draft Application-Responsive Network Framework May 2024 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 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 identifiers (ARN IDs). Users are identified based on ARN IDs and provided with corresponding personalized network services. 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 YANG, et al. Expires November 10, 2024 [Page 3] Internet-Draft Application-Responsive Network Framework May 2024 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. Gasp The current network technology still has the following key gaps: Application awareness capability. Differentiated services need to be provided based on different businesses of the same user. For example, video conferences need to avoid freezing or screen tearing caused by congestion and packet loss to ensure customer experience, while general web browsing services can strive to do their best. Data plane programming capability. Identify and classify user application data, and divert it into corresponding service-level tunnels based on the identification. Ability to perceive user experience. Perceive user-level service experience through on-the-fly detection, coordinate with intelligent routing functions to ensure the service guarantee of high-priority businesses. Currently, there is a lack of traffic identification for quick classification and statistical analysis of the user experience of such traffic. Ability to provide consistent service experience for outbound and inbound journeys. For multi-party video conferences and online interactions, attention needs to be paid to both upstream and downstream data reception. Ability to prevent network service leaks. The access network security is relatively poor, which poses the risk of leakage of user application-related network service information. 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. YANG, et al. Expires November 10, 2024 [Page 4] Internet-Draft Application-Responsive Network Framework May 2024 +---+ +-----+ | 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 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 YANG, et al. Expires November 10, 2024 [Page 5] Internet-Draft Application-Responsive Network Framework May 2024 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 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 boundary devices, and network controllers at different levels. Controller Controller Controller Controller | / \ / \ | |SBI | SBI | | SBI | |SBI +----+ +----+ +----+ +----+ +----+ +----+ +-------+ | | |User| |Net | |Net | |Net | |Net | |Cloud | |App |->|- |--|work|--|work|--|work|--|work|-->| | | | |Edge| |Edge| |Edge| |Edge| |Edge| |Service| +----+ +----+ +----+ +----+ +----+ +----+ +-------+ Figure 2: Framework and Key Components ARN Specific Functions: Access Control: Controls whether to trust the incoming ARN ID of the packet and performs verification. If verification fails, the ARN ID is cleared or the packet is discarded. Path Mapping: Can steer the packet to the corresponding forwarding path based on the ARN ID in the packet. YANG, et al. Expires November 10, 2024 [Page 6] Internet-Draft Application-Responsive Network Framework May 2024 Service Aggregation: Aggregates multiple different ARNs into a single ARN, enhancing network resource utilization and scalability. Business Rate Limiting: Imposes traffic limits on specific ARNs, typically deployed at the metropolitan area network ingress. Inter-Domain Mapping: Based on policies of different management domains, maps ARN IDs to local values. For example, the egress device of the metropolitan area network can translate ARN IDs into backbone network ARN IDs. When ARNs are inter-domain, network edge devices support inter-domain mapping technology, allowing the translation of ARN IDs into local ARN IDs or the aggregation of multiple ARN IDs into the same local ARN ID at the ingress device. It can also translate or aggregate ARN IDs into the ARN ID of the next domain at the egress device. Access control functionality can be deployed on network edge devices in each domain, filtering incoming packets based on matching policies of the packet's incoming interface to determine whether to trust the ARN ID in the inter- domain packet. For trusted inter-domain packets, further verification based on packet characteristics and ARN ID mapping relationships can be performed. 6.1. User Edge Device The network controller distributes the mapping strategy of the five- tuple, service information, and ARN ID generated based on user service subscription information to the user/ARN user edge devices. The user edge devices identify the relevant business data for labeling, encapsulate the access-side ARN ID in the packets, and transmit it. 6.2. The network boundary entry device The ARN network edge devices receive the aggregated relationship and path planning information of ARN IDs issued by the network controller. Upon receiving a packet, the ARN network edge devices extract the ARN ID, aggregate the ARN services, map the ARN IDs with similar network capability demands to the corresponding network-side ARN ID information, and provide the corresponding network service guarantees during the forwarding process based on the network-side ARN ID. When packets need to traverse domains, the egress ARN network edge devices use cross-domain mapping information to locate the next domain's ARN network edge devices and perform the necessary cross-domain ARN ID conversion. YANG, et al. Expires November 10, 2024 [Page 7] Internet-Draft Application-Responsive Network Framework May 2024 6.3. Controller Deploy corresponding ARN rules in various stages of the network. In the user network, deploy the mapping relationship between the user's five-tuple and ARN ID; in the backbone network, deploy the mapping relationship between ARN ID and the selected route. 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.4. The Southbound Interface (SBI) of the Controller: The ARN ID and ARN service policies are transmitted from the controller to the relevant network devices for execution through this interface. Candidate protocols for this interface include PCEP, BGP, and YANG-based protocols (NETCONF/RESTCONF). 7. ARN Encapsulation 7.1. Locations for IPv6 ARN ARN carries ARN ID and related information through the extension of the IPv6 data plane. The location for carrying this information is within the IPv6 Destination Options Header (DOH) or IPv6 Hop-by-Hop Options Header (HBH). The ARN ID option can be carried in the IPv6 Destination Options Header. By using the DOH Options Header, the information carried can be read by the destination node but would not normally be seen by other nodes along the path. The ARN ID option can be carried in the IPv6 Hop-by-Hop Options Header. By using the HBH Options Header, the information carried can be read by every node along the path. YANG, et al. Expires November 10, 2024 [Page 8] Internet-Draft Application-Responsive Network Framework May 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARN ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ARN ID Option Option Type: 8 Bits, ARN option, value to be allocated Type: 8 Bits, ARN type, 0: Reserved; 1: Contains only network ARN ID; 2: Contains only resource ARN ID 3: Contains network ARN ID and resource ARN ID; Reserved: 24 Bits ARN ID: 32 Bits, when the Type is 1 and 2, it represents the network ARN ID and resource ARN ID, respectively; when Type is 3, it rerepresents both network and resource ARN ID ARN ID (Optional): 32 Bits, when Type is 2, it represents the resource ARN ID Specific encapsulation formats for the three Types are as shown in the diagram: YANG, et al. Expires November 10, 2024 [Page 9] Internet-Draft Application-Responsive Network Framework May 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. ARN Header with Type 1 ARN ID 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. ARN Header with Type 2 ARN ID 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. ARN Header with Type 3 ARN ID 7.2. Locations for IPv4 ARN TBD. YANG, et al. Expires November 10, 2024 [Page 10] Internet-Draft Application-Responsive Network Framework May 2024 8. Use case Metropolitan backone Access area network network DC Controller Controller Controller Controller | / \ / \ | | | | | | | +----+ +-------+ A+-------+ +----+ A+----+ +-------+ |Bras| |Metro |--|Metro | |Back|--|Back| |DC | | | |politan| B|politan| |bone| B|bone| |Cloud | | |--|Area |--|Area |--| |--| |--| | User->| | | | C| | | | C| | | | | | |Edge |--|Edge | |Edge|--|Edge| |Service| +----+ +-------+ +-------+ +----+ +----+ +-------+ Figure 7: Use case of ARN This is a typical network where users access the network through a Bras server, then via the metropolitan area network, backbone network, and finally access the data center cloud services. Functions implemented by each device: Bras: Acts as the user edge device, converting user information into ARN-ID. ARN ID can be directly labeled by users on the application side based on the services they have purchased, or it can be labeled by the network devices at the user edge based on the flow characteristics of the user application. If the user datagram already carries an ARN ID, on the user's boundary, 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. Access Controller: Issues user information and ARN-ID mappings. Metropolitan Area Network Ingress: Provides functions such as access control based on ARN-ID, path mapping, service aggregation, and business rate limiting. Metropolitan Area Network Egress: Provides functions such as access control based on ARN-ID, inter-domain mapping, and service aggregation. Metropolitan Area Network Controller: Issues rules for access control, path mapping, inter-domain mapping, service aggregation, and business rate limiting based on ARN-ID to the metropolitan area network ingress and egress devices. YANG, et al. Expires November 10, 2024 [Page 11] Internet-Draft Application-Responsive Network Framework May 2024 Backbone Network Ingress: Provides functions such as access control based on ARN-ID, path mapping, and service aggregation. Backbone Network Egress: Provides functions such as access control, inter-domain mapping, and service aggregation. Backbone Network Controller: Issues rules for access control, path mapping, inter-domain mapping, service aggregation, and business rate limiting based on ARN-ID to the backbone network ingress and egress devices. Cloud Services: Provides specific application services. DC Controller: Data Center Controller, issues ARN-ID-based cloud service rules to the data center devices. This situation is based on the innovation of future applications, where customized cloud services can be tailored based on ARN-ID. 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: 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. YANG, et al. Expires November 10, 2024 [Page 12] Internet-Draft Application-Responsive Network Framework May 2024 11. References 11.1. Normative References RFC2460 S. Deering, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 YANG, et al. Expires November 10, 2024 [Page 13] Internet-Draft Application-Responsive Network Framework May 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 November 10, 2024 [Page 14]