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