Application-Responsive Network Framework
draft-yang-rtgwg-arn-framework-09
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Feng Yang , Changwang Lin | ||
| Last updated | 2026-11-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yang-rtgwg-arn-framework-09
RTGWG F. Yang
Internet-Draft China Mobile
Intended status: Standards Track C. Lin
Expires: 5 May 2027 New H3C Technologies
1 November 2026
Application-Responsive Network Framework
draft-yang-rtgwg-arn-framework-09
Abstract
With the deployment of increasingly advanced technologies on a large
scale, such as SRv6[RFC8402] 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 5 May 2027.
Yang & Lin Expires 5 May 2027 [Page 1]
Internet-Draft ARN Framework November 2026
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Goal . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. ARN Framework and Components . . . . . . . . . . . . . . . . 6
4.1. ARN ID . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Application . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. User Edge Device . . . . . . . . . . . . . . . . . . . . 8
4.3.1. ARN ID Marking . . . . . . . . . . . . . . . . . . . 8
4.4. Network Edge Device . . . . . . . . . . . . . . . . . . . 9
4.4.1. Ingress Processing . . . . . . . . . . . . . . . . . 9
4.4.2. Egress Processing . . . . . . . . . . . . . . . . . . 10
4.4.3. Access Control . . . . . . . . . . . . . . . . . . . 10
4.4.4. Cross-domain Aggregation and Mapping . . . . . . . . 11
4.4.5. Service Function Chain Based on ARN . . . . . . . . . 11
4.4.6. Rate Limiting . . . . . . . . . . . . . . . . . . . . 12
4.5. Controller . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. The Southbound Interface (SBI) of the Controller . . . . 12
5. ARN Encapsulation . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Locations for IPv6 ARN . . . . . . . . . . . . . . . . . 13
5.2. Locations for IPv4 ARN . . . . . . . . . . . . . . . . . 13
6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Yang & Lin Expires 5 May 2027 [Page 2]
Internet-Draft ARN Framework November 2026
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 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.
Yang & Lin Expires 5 May 2027 [Page 3]
Internet-Draft ARN Framework November 2026
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. 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
2. 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.
Yang & Lin Expires 5 May 2027 [Page 4]
Internet-Draft ARN Framework November 2026
3. 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:
* 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.
Yang & Lin Expires 5 May 2027 [Page 5]
Internet-Draft ARN Framework November 2026
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.
4. 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
Yang & Lin Expires 5 May 2027 [Page 6]
Internet-Draft ARN Framework November 2026
Figure 2: Framework and Key Components
4.1. 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.
Yang & Lin Expires 5 May 2027 [Page 7]
Internet-Draft ARN Framework November 2026
4.2. 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.
4.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 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.
4.3.1. 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 Section 5. In this
case, an extra IPv6 header is needed.
Yang & Lin Expires 5 May 2027 [Page 8]
Internet-Draft ARN Framework November 2026
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.
4.4. 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.
4.4.1. 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.
Yang & Lin Expires 5 May 2027 [Page 9]
Internet-Draft ARN Framework November 2026
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.
4.4.2. 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.
4.4.3. 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 ingress mapping 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[RFC9256]/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.
Yang & Lin Expires 5 May 2027 [Page 10]
Internet-Draft ARN Framework November 2026
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.
4.4.4. 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.
4.4.5. 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
Yang & Lin Expires 5 May 2027 [Page 11]
Internet-Draft ARN Framework November 2026
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.
4.4.6. Rate Limiting
Imposes traffic limits on specific ARN IDs, typically deployed at the
Network Edge Device.
4.5. Controller
The controller generates ARN IDs in the way mentioned in Section 4.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 MAY generate ARN ingress mapping table and send to
Network Edge Device, which is used for access control. Alternately,
the ARN ingress mapping 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.
4.6. 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 & Lin Expires 5 May 2027 [Page 12]
Internet-Draft ARN Framework November 2026
5. ARN Encapsulation
5.1. 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type: 8 Bits, ARN option, value to be allocated
ARN ID: 32 Bits
Figure 3: ARN ID Option
5.2. Locations for IPv4 ARN
TBD.
6. Use Cases
Yang & Lin Expires 5 May 2027 [Page 13]
Internet-Draft ARN Framework November 2026
+---------------------+
| Network Controller |
+----+------------+---+
| |
+---+--+ +--+---+ +-------+
| | A | | | |
+-----+ | Back +------+ Back | | DC |
| HGW |------>| bone | B | bone | | Cloud |
+-----+ | Edge +------+ Edge +-----+ |
User | | C | | | |
| Bras +------+ | |Service|
+------+ +------+ +-------+
Figure 4: 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. 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
Yang & Lin Expires 5 May 2027 [Page 14]
Internet-Draft ARN Framework November 2026
* 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. IANA Considerations
Option type number in the header should be allocated.
8. Security Considerations
This document will not affect the security of the Internet.
9. Normative References
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Contributors
Joel Halpern
Email: jmh@joelhalpern.com
Many thanks to Joel Halpern for reviewing the ARN ID mapping
mechanism.
Yang & Lin Expires 5 May 2027 [Page 15]
Internet-Draft ARN Framework November 2026
Authors' Addresses
Feng Yang
China Mobile
China
Email: yangfeng@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Yang & Lin Expires 5 May 2027 [Page 16]