Network Working Group F. Yang Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: October 11, 2024 New H3C Technologies April 11, 2024 Application-Request Network Framework draft-yang-rtgwg-arn-framework-00 Abstract With progress of more and more new technologies have been deployed in large scale, such as SRv6 and network slicing, it is highly desirable to open these new capability to applications. Current practice is using ACLs to classify the packet and then map those traffic onto proper network resources. This is the way the application is passively perceived by the network, rather than the application actively calling the network, and changes in application characteristics require triggering network configuration adjustments, making it difficult to deploy at scale. The document proposes a new framework called Application Request 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 October 11, 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. YANG, et al. Expire October 11, 2024 [Page 1] Internet-Draft Application-Request Network Framework April 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. Design Goal....................................................4 5. ARN Framework and Components...................................5 5.1. User Edge Device..........................................6 5.2. The network boundary entry device.........................6 5.3. The network boundary egress device........................6 5.4. Controller................................................6 5.5. The Southbound Interface (SBI) of the Controller:.........6 6. Use case ......................................................7 7. ARN Encapsulation..............................................8 7.1. Flow Label translated to ARN ID...........................8 7.2. Using ARN Option..........................................9 8. Security Considerations.......................................10 9. IANA Considerations...........................................10 10. References...................................................10 10.1. Normative References....................................10 Authors' Addresses...............................................11 YANG, et al. Expires October 11, 2024 [Page 2] Internet-Draft Application-Request Network Framework April 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 guranteed 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 Request 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 October 11, 2024 [Page 3] Internet-Draft Application-Request Network Framework April 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-request Networking ACL: Access Control List 4. 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 Specific Design Goals: Privacy: Do not expose network tunnel/slice privacy information while also protecting user application privacy. Security: Support access control, prevention of identity theft, and lifecycle management. It should be possible to report the loss or reissue an ARN ID. Network and business separation: Encapsulate network capabilities and make them accessible to users, allowing user-side marking of ARNs while the network side handles tunnel/slice selection. Scalability: ARNs should be able to aggregate and support large- scale deployments. Compatibility: In the absence of ARN support, forwarding should not be affected, and compatibility with ACL for business rate limiting should be maintained. Interoperability: No requirement for global uniqueness, supporting network interoperability and aggregation of network capabilities. YANG, et al. Expires October 11, 2024 [Page 4] Internet-Draft Application-Request Network Framework April 2024 Orthogonality with QoS: Avoid changing QoS PHB behavior and do not interfere with QoS overlays. Application Innovation: Support future applications without requiring changes to the network as applications evolve. 5. 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. 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 YANG, et al. Expires October 11, 2024 [Page 5] Internet-Draft Application-Request Network Framework April 2024 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. 5.1. User Edge Device Based on the information deployed by the controller, map the five- tuple of the datagram to an ARN ID and attach the ARN ID information to the datagram. The specific encapsulation format can be found in Chapter 7. The controller here is generally an access controller. 5.2. The network boundary entry device The network boundary entry device provides access control functionality. If a user datagram carries an ARN ID, ARN ID validation is performed. In case of validation failure, the user's ARN ID is removed from the datagram, or the entire datagram is discarded. Subsequently, based on the policies deployed by the controller, which is typically a metropolitan area network controller or a core network router, path selection is carried out to provide the corresponding network resources and services. 5.3. The network boundary egress device The network boundary egress device offers access control functionality, inter-domain mapping functionality, and service aggregation functionality. 5.4. 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. 5.5. 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). YANG, et al. Expires October 11, 2024 [Page 6] Internet-Draft Application-Request Network Framework April 2024 6. 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 : 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. Backbone Network Ingress: Provides functions such as access control based on ARN-ID, path mapping, and service aggregation. YANG, et al. Expires October 11, 2024 [Page 7] Internet-Draft Application-Request Network Framework April 2024 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. 7. ARN Encapsulation 7.1. Flow Label translated to ARN ID Option 1: Directly embed the ARN ID, containing service information, in the IPv6 header by converting the Flow Label to the ARN ID. During forwarding, network devices do not need to parse or match the fields such as the five-tuple in the packet. They only need to retrieve the IPv6 extension header to obtain the network service information required by the application. This simplifies operational deployment and reduces hardware ACL resource consumption. The Flow Label is 20 bits in length, of which a portion can be utilized for the ARN ID, for example, a 16-bit allocation, with the remaining bits reserved. YANG, et al. Expires October 11, 2024 [Page 8] Internet-Draft Application-Request Network Framework April 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label translated to ARN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ARN ID by Flow Lable 7.2. Using ARN Option Option 2: Introduce the ARN Option to carry the ARN ID. The addition of the ARN Option will facilitate the future expansion of ARN to incorporate other functionalities. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARN-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. The ARN Option ARN-ID: A 32-bit identifier. The ARN Option can be carried in the IPv6 Hop-by-Hop Options Header (HBH), the IPv6 Destination Options Header (DOH), or the segment routing header (SRH). YANG, et al. Expires October 11, 2024 [Page 9] Internet-Draft Application-Request Network Framework April 2024 8. Security Considerations TBD. 9. IANA Considerations TBD. 10. References 10.1. Normative References TBD YANG, et al. Expires October 11, 2024 [Page 10] Internet-Draft Application-Request Network Framework April 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 October 11, 2024 [Page 11]