]> China Mobile

CN yangfeng@chinamobile.com

New H3C Technologies

CN linchangwang.04414@h3c.com

RTG RTGWG 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.

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 a 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 because operators do not revoke or modify them in a timely manner. This is not sufficient for a 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 a network service implemented on a gateway or software that can program the ARN ID.

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 when, and only when, they appear in all capitals, as shown here.

Terminology ARN: Application-Responsive Networking ACL: Access Control List Subscriber: the user who subscribed to a network service, which can be represented by an ARN ID

Gaps There are still the following key gaps in current network technology: 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. Real-time detection and perception of user-level service experience work 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.

Design Goal As shown in , 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.

| R |--->|Network| +-----+ | N | +-------+ +---+ ]]>

ARN Network Design Goals: Openness of network services. 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 networks 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 the complexity of data plane identifiers and simplifying operational deployments.

ARN Framework and Components ARN Framework, as illustrated in , consists of key components including User Edge Devices, Network Edge Devices, and network controllers at different levels.

|User |--->| | | | | | +----+ |Edge | | Net | | Net | | Cloud | +-----+ | work|--->| work|--->| | +----+ | Edge| | Edge| |Service| |App |-------------->| | | | | | +----+ +-----+ +-----+ +-------+ Access Backbone ]]>

ARN ID The ARN ID represents the application's invocation of network capabilities and/or the network's ability to be open to the application. It needs to be implemented on both User Edge Devices and Network Edge Devices. 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. 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-planned network paths, e.g. SR policies. A method of allocating ARN ID by PPPoE mechanism is as follows: Firstly, the User Edge Device such as BRAS sends the configuration request used to query ARN ID which characterizes a service subscribed by a user. The request includes at least one or more of protocol type, protocol length, and service id based on the pre-set protocol. The network device connected to the user device receives the request according to the pre-set protocol(e.g. NCP) and allocates the configuration with ARN ID to the user device based on the request. According to pre-set service information including service type and identification information of user device, network device determines the service type of user device. Furthermore, it determines ARN ID of the user device based on the said service type information. Secondly, the user device sends the configuration request with ARN ID to confirm that the ARN ID is correct. The network device receives the message and sends the confirmation message to the user device based on the confirmation request, which is used to characterize whether ARN ID is correct. When the ARN ID in the configuration request sent from the user device matches the ARN ID in the configuration information sent from the network device, the network device sends the confirmation message characterizing the accuracy of ARN ID which is allocated to the user device.

Application User applications require networks to provide differentiated services, especially those based on SR technology. There are two scenarios. 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.

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 User Edge Device obtains the ARN ID sent by the controller, where the ARN ID is assigned by the controller to the User Edge Device based on user information, application information, and network service information. The ARN ID generated by the controller includes user information, and the User Edge Device inserts this ARN ID into IPv6 packet and transmits it to Network Edge Device.

ARN ID Marking ARN ID will be applied on a User Edge Device, and include the following operations: Obtain the ARN ID; The ARN ID represents the invocation relationship of the application to network capabilities and/or the network capabilities exposed to the application; Based on the ARN ID to mark the original IP packet, generate IPv6 packet accordingly, and transmit the IPv6 packet. The ARN ID SHOULD be encapsulated into the extension header of the IPv6 packet, which will be explained in detail in . In this case, an extra IPv6 header is needed. Optionally, marking the original IPv6 packet based on the ARN ID includes either inserting the ARN ID into an extension header of the original IPv6 packet, or inserting the ARN ID into the Source Address field of the original IPv6 packet header.

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 operator. When ARN is applied to Network Edge Devices, the ARN performs the following primary functions: Receives packet generated by the User Edge Device that carry an ARN ID; the packet is created by the User Edge Device by marking the original IP packet based on the obtained ARN ID; The ARN ID represents the invocation relationship of the application to network capabilities and/or the network capabilities exposed to the application. If the Network Edge Device is a PE, it is desired that VPN services are carried by multiple SRv6 Policies with different color. In this case, the ARN ID in the packet from user can be used to select the appropriate SRv6 Policy.

Ingress Processing The processing of ARN occurs on the edge devices at the boundary of the ARN domain. Upon receiving an IP packet containing an ARN ID, the Network Edge Device must: *Parse the IP packet to extract the ARN ID; *Validate the legitimacy of the ARN ID against a pre-configured ARN ID validation table, which stores predefined mappings between user information and ARN IDs; *If the validation result confirms that the user's ARN ID is valid, map the ARN-tagged IP packet to the corresponding network path or network slice based on that ARN ID. When external packets with ARN ID enter the ARN domain, they will be mapped to SRv6 Policy or slice through the ARN Ingress mapping table. At this point, the ARN ID can be considered as the Color of the data plane, corresponding to the Color of the SRv6 Policy.

Egress Processing When packets leave the ARN domain, the SRv6 Policy can also be mapped to the ARN ID of the next domain. Like ingress processing, there will be an egress mapping table. The mapping operation is quite similar to VLAN translation.

Access Control Before trusting the incoming ARN ID of the packet outside limited domain, verification is necessary. The user facing interface should support configuration option to enable or disable the ARN function. When a Network Edge Device receives a packet carrying an ARN ID, if the ARN function on the interface is enabled, it should perform ARN related access control and forwarding processing on the packet. If the ARN function on the interface is disabled, the ARN ID in the packet should be ignored, that is, the processing associated with ARN should be skipped. The verification of the source information and the ARN ID is based on a pre-configured ARN ID verification table, which keeps records of the correspondence between the source information and the ARN ID, including: The source information of the packet, which represents the subscriber. The subscribed ARN ID. The mapping relationship between the ARN ID and network services (such as SR Policy/Flex Algo). The received packet contains source information of the packet, such as source address, PPPoE, tunnel, interface and other information, which is used to identify subscribers. When the ARN function is enabled on the interface, the network edge device MUST verify the source information and the ARN ID of the packet. If the packet passes verification, the Network Edge Device SHALL map the IPv6 packet to the corresponding network path or network slice based on that ARN ID. If the packet verification fails, the interface SHOULD skip the ARN ID related processing of the packet. If the verification is failed, the following actions may be performed: Ignore the ARN ID carried in the packet or discard the IPv6 packet; Map the IPv6 packet to the default path or slice associated with packets that do not carry an ARN ID.

Cross-domain Aggregation and Mapping The edge network device in the current domain(Domain A) receives the packet carrying the ARN ID 1 which is sent by another edge network device, and queries the ARN ID 2 which is mapped to ARN ID 1 in the target domain from a preset cross-domain mapping relationship. Then it replaces ARN ID 1 with ARN ID 2 to obtain the new packet and sends it to the device in target domain(Domain B). The preset cross-domain mapping relationship is established as follows: after receiving the ARN ID assigned in the current domain and the ARN ID assigned in the target domain, the service orchestration system establishes a mapping relationship between the two ARN IDs for the network path required by the same application, and then delivers it to the edge network device via the domain controller of the current domain. The ARN ID 1 configured in flow label, Destination Option Header(DOH), or Hop-by-Hop Option Header(HBH) of the packet is changed to the ARN ID 2 to generate the modified packet and then the modified packet is sent to the target domain.

Service Function Chain Based on ARN In the SRv6 SFC scenario, the traditional solution of SRv6 SFC requires allocating SIDs for each service (including each SF or each user) and advertising relevant routes, leading to high complexity in the number of SIDs and routes, which makes it impossible to truly implement. The ARN-based approach can greatly simplify this SID and route allocation mechanism. It only uses ARN IDs to integrate network and service capabilities, while SIDs are only used as network path identifiers, reducing the coupling with services. The gateway device of SFC receives and parses the SID in the service flow. According to the instruction information of the SID function, the IPv6 packet in the service flow and the corresponding extension header are parsed to obtain the application and network capability identifier(that is ARN ID), which is used to indicate the service function SF. Furthermore, the outgoing interface or IP address to the next-hop node corresponding to the SF indicated by the ARN ID is obtained. According to the association table sent by the controller device (or statically configured), the outgoing interface or IP address to the next-hop node corresponding to the SF indicated by ARN ID is searched, including the association between SF and destination IP address or between SF and virtual interface.

Rate Limiting Imposes traffic limits on specific ARN IDs, typically deployed at the Network Edge Device.

Controller The controller generates ARN IDs in the way mentioned in . 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 MAY generate ARN ID verification table and send to Network Edge Device, which is used for access control. Alternately, the ARN ID verification table MAY also be populated by routing protocols. 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.

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).

ARN Encapsulation

Locations for IPv6 ARN ARN carries ARN ID option including ARN ID 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.

Locations for IPv4 ARN TBD.

Use Cases

| bone | B | bone | | Cloud | +-----+ | Edge +------+ Edge +-----+ | User | | C | | | | | Bras +------+ | |Service| +------+ +------+ +-------+ ]]>

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. Configuring 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: 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.

IANA Considerations Option type number in the header should be allocated.

Security Considerations This document will not affect the security of the Internet.

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Contributors

jmh@joelhalpern.com

Many thanks to Joel Halpern for reviewing the ARN ID mapping mechanism.