Skip to main content

Application-Responsive Network Framework
draft-yang-rtgwg-arn-framework-01

Document Type Active Internet-Draft (individual)
Authors Feng Yang , Changwang Lin
Last updated 2024-05-10
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-01
RTGWG Working Group                                             F. Yang
Internet Draft                                             China Mobile
Intended status: Standards Track                                 C. Lin
Expires: November 10, 2024                         New H3C Technologies
                                                           May 10, 2024

                 Application-Responsive Network Framework
                     draft-yang-rtgwg-arn-framework-01

Abstract

   With the deployment of increasingly advanced technologies on a large
   scale, such as SRv6 and network slicing, there is a growing need to
   expose these new capabilities to applications. The current practice
   involves using ACLs to classify packets and then map the traffic
   onto appropriate network resources. This approach results in the
   application being passively perceived by the network, rather than
   the application actively interfacing with the network. Furthermore,
   changes in application characteristics necessitate triggering
   network configuration adjustments, making it challenging to deploy
   at scale.

   The document proposes a new framework called Application Responsive
   Network (ARN), by encapsulating more network functions into ARN ID,
   thus it opens up interfaces to applications. The vision is to enable
   applications to access network resources like they access an
   operating system.

   Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 10, 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors. All rights reserved.

YANG, et al.          Expire November 10, 2024                [Page 1]
Internet-Draft   Application-Responsive Network Framework      May 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................3
   2. Requirements Language..........................................3
   3. Terminology....................................................4
   4. Gasp...........................................................4
   5. Design Goal....................................................4
   6. ARN Framework and Components...................................6
      6.1. User Edge Device..........................................7
      6.2. The network boundary entry device.........................7
      6.3. Controller................................................8
      6.4. The Southbound Interface (SBI) of the Controller:.........8
   7. ARN Encapsulation..............................................8
      7.1. Locations for IPv6 ARN....................................8
      7.2. Locations for IPv4 ARN...................................10
   8. Use case......................................................11
   9. Security Considerations.......................................12
   10. IANA Considerations..........................................12
   11. References...................................................13
      11.1. Normative References....................................13
   Authors' Addresses...............................................14

YANG, et al.          Expires November 10, 2024               [Page 2]
Internet-Draft   Application-Responsive Network Framework      May 2024

1. Introduction

   With the widespread application of new technologies such as 5G,
   cloud computing, big data, and AI, network traffic patterns are
   becoming increasingly complex and diversified. Various emerging
   services have higher requirements for QoS parameters such as network
   latency, bandwidth, jitter, and packet loss.

   Networks typically need to prioritize critical services. For
   example, in office networks, video conferencing requires network
   priority to ensure that video and voice services do not experience
   buffering and excessive delays. However, the applications used for
   video and voice services may vary in different industries and office
   network scenarios, so it is necessary to identify these applications
   to further ensure the quality of service.

   Some specific services have explicit SLA (Service Level Agreement)
   requirements. In business scenarios such as autonomous driving,
   industrial control, and remote control, there are clear SLA
   requirements for the network, such as latency not exceeding 50ms and
   jitter not exceeding 1ms.

   In traditional IP networks, ACLs are typically used on critical
   network devices to implement application identification and policy
   configuration. Based on packet characteristics such as the five-
   tuple, network can provide guaranteed service for specific users or
   applications. Different network services have their own ACL matching
   entries and policies, which need to be continuously adjusted as
   services evolve.  Over time, configurations become invalid due to
   not being revoked or modified in a timely manner. This is not
   sufficient for general solution.

   This article proposes a new framework called Application Responsive
   Network (ARN), which abstracts and represents personalized network
   services based on user demand awareness, provided through ARN
   identifiers (ARN IDs). Users are identified based on ARN IDs and
   provided with corresponding personalized network services. The
   vision is to enable applications to access network resources like
   they access an operating system.

   The application here can be network service implemented on a gateway
   or software that can program the ARN ID.

2. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in

YANG, et al.          Expires November 10, 2024               [Page 3]
Internet-Draft   Application-Responsive Network Framework      May 2024

   BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when,
   they appear in all capitals, as shown here.

3. Terminology

   ARN: Application-Responsive Networking

   ACL: Access Control List

4. Gasp

   The current network technology still has the following key gaps:

   Application awareness capability. Differentiated services need to be
   provided based on different businesses of the same user. For
   example, video conferences need to avoid freezing or screen tearing
   caused by congestion and packet loss to ensure customer experience,
   while general web browsing services can strive to do their best.

   Data plane programming capability. Identify and classify user
   application data, and divert it into corresponding service-level
   tunnels based on the identification.

   Ability to perceive user experience. Perceive user-level service
   experience through on-the-fly detection, coordinate with intelligent
   routing functions to ensure the service guarantee of high-priority
   businesses. Currently, there is a lack of traffic identification for
   quick classification and statistical analysis of the user experience
   of such traffic.

   Ability to provide consistent service experience for outbound and
   inbound journeys. For multi-party video conferences and online
   interactions, attention needs to be paid to both upstream and
   downstream data reception.

   Ability to prevent network service leaks. The access network
   security is relatively poor, which poses the risk of leakage of user
   application-related network service information.

5. Design Goal

   As shown in Figure 1, an ARN intermediate layer is added between the
   application and the network, mapping is accomplished using ARN IDs.
   The ARN ID is a simple number that encapsulates network capabilities
   internally and hides network information externally, thus avoiding
   the exposure of application privacy and facilitating user
   application invocation.

YANG, et al.          Expires November 10, 2024               [Page 4]
Internet-Draft   Application-Responsive Network Framework      May 2024

                           +---+
                +-----+    | A |    +-------+
                |App  |--->| R |--->|Network|
                +-----+    | N |    +-------+
                           +---+

                 Figure 1: ARN Intermediate Layer Diagram

   ARN Network Design Goals:

   * Open and programmable network capabilities

   One of the design principles of ARN is to open and program network
   capabilities based on the data plane. By opening programming
   interfaces on the data plane in a software-based manner,
   applications can call network resources like calling an operating
   system. In today's digital world, user demands for the network far
   exceed simple connectivity functions. Users expect the network to
   provide stable, high-speed connections to meet diverse application
   requirements. Even for the same type of application, usage
   requirements may vary across different industries and scenarios.
   Allowing applications to call on network capabilities through data
   plane programming provides corresponding guarantees for different
   types of packets.

   * Decoupling of addresses and services

   Another design principle of ARN is to decouple addresses and
   services. Traditional network design is based on addresses, managing
   and routing based on destination addresses to determine the
   forwarding services provided by the network. However, with the
   increasing variety of user applications, relying on addresses to
   carry service levels has made network management increasingly
   complex. Therefore, it is necessary to manage and optimize the
   network based on the characteristics and requirements of user
   applications, separating addresses from services to provide
   multidimensional forwarding services.

   * Decoupling of network and applications

   The third design principle of ARN is to decouple the network and
   applications. By adding an ARN layer between the network and
   applications, the network does not need to directly perceive the
   applications, thus shielding the diversity of applications and
   preventing direct access to network capabilities. Through ARN, the
   network and applications can be encapsulated separately, achieving

YANG, et al.          Expires November 10, 2024               [Page 5]
Internet-Draft   Application-Responsive Network Framework      May 2024

   application privacy and the concealment of internal network
   information. At the same time, based on this encapsulation, access
   control can be implemented during the application's network calls,
   realizing an authorization token-based calling mechanism similar to
   software programming.

   * Unified abstraction of network resources

   The fourth design principle of ARN is the unified abstraction of
   multiple network resources. With the development of personalized and
   diversified network services, the network resources used in
   forwarding user packets are becoming increasingly rich, such as
   computing power, network slicing, service chaining, and more. During
   the use of these network resources, additional identifiers are often
   carried in the packets to determine the mapping relationship between
   users or applications and network resources, or ACLs are used to
   parse and match the feature information in the packet to determine
   the associated network resources. In the ARN network, multiple
   network resources can be uniformly represented by ARN IDs, reducing
   the complexity of data plane identifiers and simplifying operational
   deployments.

6. ARN Framework and Components

   ARN Framework, as illustrated in Figure 2, consists of key
   components including user edge devices, network boundary devices,
   and network controllers at different levels.

        Controller  Controller     Controller    Controller
             |        /     \         /    \          |
             |SBI    |  SBI |         | SBI |         |SBI
   +----+  +----+  +----+  +----+  +----+  +----+   +-------+
   |    |  |User|  |Net |  |Net |  |Net |  |Net |   |Cloud  |
   |App |->|-   |--|work|--|work|--|work|--|work|-->|       |
   |    |  |Edge|  |Edge|  |Edge|  |Edge|  |Edge|   |Service|
   +----+  +----+  +----+  +----+  +----+  +----+   +-------+

                  Figure 2: Framework and Key Components

   ARN Specific Functions:

   Access Control: Controls whether to trust the incoming ARN ID of the
   packet and performs verification. If verification fails, the ARN ID
   is cleared or the packet is discarded.

   Path Mapping: Can steer the packet to the corresponding forwarding
   path based on the ARN ID in the packet.

YANG, et al.          Expires November 10, 2024               [Page 6]
Internet-Draft   Application-Responsive Network Framework      May 2024

   Service Aggregation: Aggregates multiple different ARNs into a
   single ARN, enhancing network resource utilization and scalability.

   Business Rate Limiting: Imposes traffic limits on specific ARNs,
   typically deployed at the metropolitan area network ingress.

   Inter-Domain Mapping: Based on policies of different management
   domains, maps ARN IDs to local values. For example, the egress
   device of the metropolitan area network can translate ARN IDs into
   backbone network ARN IDs. When ARNs are inter-domain, network edge
   devices support inter-domain mapping technology, allowing the
   translation of ARN IDs into local ARN IDs or the aggregation of
   multiple ARN IDs into the same local ARN ID at the ingress device.
   It can also translate or aggregate ARN IDs into the ARN ID of the
   next domain at the egress device. Access control functionality can
   be deployed on network edge devices in each domain, filtering
   incoming packets based on matching policies of the packet's incoming
   interface to determine whether to trust the ARN ID in the inter-
   domain packet. For trusted inter-domain packets, further
   verification based on packet characteristics and ARN ID mapping
   relationships can be performed.

   6.1. User Edge Device

   The network controller distributes the mapping strategy of the five-
   tuple, service information, and ARN ID generated based on user
   service subscription information to the user/ARN user edge devices.
   The user edge devices identify the relevant business data for
   labeling, encapsulate the access-side ARN ID in the packets, and
   transmit it.

   6.2. The network boundary entry device

   The ARN network edge devices receive the aggregated relationship and
   path planning information of ARN IDs issued by the network
   controller. Upon receiving a packet, the ARN network edge devices
   extract the ARN ID, aggregate the ARN services, map the ARN IDs with
   similar network capability demands to the corresponding network-side
   ARN ID information, and provide the corresponding network service
   guarantees during the forwarding process based on the network-side
   ARN ID. When packets need to traverse domains, the egress ARN
   network edge devices use cross-domain mapping information to locate
   the next domain's ARN network edge devices and perform the necessary
   cross-domain ARN ID conversion.

YANG, et al.          Expires November 10, 2024               [Page 7]
Internet-Draft   Application-Responsive Network Framework      May 2024

   6.3. Controller

      Deploy corresponding ARN rules in various stages of the network.
      In the user network, deploy the mapping relationship between the
      user's five-tuple and ARN ID; in the backbone network, deploy the
      mapping relationship between ARN ID and the selected route. A
      single controller can be centrally used, or multiple controllers
      can be utilized to collectively fulfill the functions across
      various stages of the network.

   6.4. The Southbound Interface (SBI) of the Controller:

      The ARN ID and ARN service policies are transmitted from the
      controller to the relevant network devices for execution through
      this interface. Candidate protocols for this interface include
      PCEP, BGP, and YANG-based protocols (NETCONF/RESTCONF).

7. ARN Encapsulation

   7.1. Locations for IPv6 ARN

   ARN carries ARN ID and related information through the extension of
   the IPv6 data plane. The location for carrying this information is
   within the IPv6 Destination Options Header (DOH) or IPv6 Hop-by-Hop
   Options Header (HBH).

   The ARN ID option can be carried in the IPv6 Destination Options
   Header. By using the DOH Options Header, the information carried can
   be read by the destination node but would not normally be seen by
   other nodes along the path.

   The ARN ID option can be carried in the IPv6 Hop-by-Hop Options
   Header. By using the HBH Options Header, the information carried can
   be read by every node along the path.

YANG, et al.          Expires November 10, 2024               [Page 8]
Internet-Draft   Application-Responsive Network Framework      May 2024

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  | Option Type   | Opt Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type        |                 Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ARN ID                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ARN ID (Optional)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 3: ARN ID Option

   Option Type: 8 Bits, ARN option, value to be allocated

   Type: 8 Bits, ARN type,

        0: Reserved;

        1: Contains only network ARN ID;

        2: Contains only resource ARN ID

        3: Contains network ARN ID and resource ARN ID;

   Reserved: 24 Bits

   ARN ID: 32 Bits,

        when the Type is 1 and 2, it represents the network ARN ID and
        resource ARN ID, respectively;

        when Type is 3, it rerepresents both network and resource ARN
        ID

   ARN ID (Optional): 32 Bits, when Type is 2, it represents the
   resource ARN ID

   Specific encapsulation formats for the three Types are as shown in
   the diagram:

YANG, et al.          Expires November 10, 2024               [Page 9]
Internet-Draft   Application-Responsive Network Framework      May 2024

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  | Option Type   | Opt Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 1    |                 Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Network ARN ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 4. ARN Header with Type 1 ARN ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  | Option Type   | Opt Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 2    |                 Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Resource ARN ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 5. ARN Header with Type 2 ARN ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  | Option Type   | Opt Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 3    |                 Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Network ARN ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Resource ARN ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 6. ARN Header with Type 3 ARN ID

   7.2. Locations for IPv4 ARN

    TBD.

YANG, et al.          Expires November 10, 2024              [Page 10]
Internet-Draft   Application-Responsive Network Framework      May 2024

8. Use case

                     Metropolitan        backone
         Access      area network        network          DC
       Controller     Controller         Controller     Controller
           |         /        \          /    \            |
           |         |         |         |     |           |
         +----+  +-------+ A+-------+  +----+ A+----+  +-------+
         |Bras|  |Metro  |--|Metro  |  |Back|--|Back|  |DC     |
         |    |  |politan| B|politan|  |bone| B|bone|  |Cloud  |
         |    |--|Area   |--|Area   |--|    |--|    |--|       |
   User->|    |  |       | C|       |  |    | C|    |  |       |
         |    |  |Edge   |--|Edge   |  |Edge|--|Edge|  |Service|
         +----+  +-------+  +-------+  +----+  +----+  +-------+
                         Figure 7: Use case of ARN

   This is a typical network where users access the network through a
   Bras server, then via the metropolitan area network, backbone
   network, and finally access the data center cloud services.

   Functions implemented by each device:

   Bras: Acts as the user edge device, converting user information into
   ARN-ID. ARN ID can be directly labeled by users on the application
   side based on the services they have purchased, or it can be labeled
   by the network devices at the user edge based on the flow
   characteristics of the user application. If the user datagram
   already carries an ARN ID, on the user's boundary, the legitimacy of
   the ARN ID can be verified. If the ARN ID does not belong to the
   user, the verification will fail, and the ARN ID will be cleared or
   the entire datagram will be discarded.

   Access Controller: Issues user information and ARN-ID mappings.

   Metropolitan Area Network Ingress: Provides functions such as access
   control based on ARN-ID, path mapping, service aggregation, and
   business rate limiting.

   Metropolitan Area Network Egress: Provides functions such as access
   control based on ARN-ID, inter-domain mapping, and service
   aggregation.

   Metropolitan Area Network Controller: Issues rules for access
   control, path mapping, inter-domain mapping, service aggregation,
   and business rate limiting based on ARN-ID to the metropolitan area
   network ingress and egress devices.

YANG, et al.          Expires November 10, 2024              [Page 11]
Internet-Draft   Application-Responsive Network Framework      May 2024

   Backbone Network Ingress: Provides functions such as access control
   based on ARN-ID, path mapping, and service aggregation.

   Backbone Network Egress: Provides functions such as access control,
   inter-domain mapping, and service aggregation.

   Backbone Network Controller: Issues rules for access control, path
   mapping, inter-domain mapping, service aggregation, and business
   rate limiting based on ARN-ID to the backbone network ingress and
   egress devices.

   Cloud Services: Provides specific application services.

   DC Controller: Data Center Controller, issues ARN-ID-based cloud
   service rules to the data center devices. This situation is based on
   the innovation of future applications, where customized cloud
   services can be tailored based on ARN-ID.

   Based on the different types of ARN services purchased by users,
   when mapping paths in the domain for forwarding user traffic, three
   network paths can be chosen according to the rules deployed by the
   controller to meet the users' network requirements. As different
   applications may have varying network demands, the five-tuple of the

   datagrams is mapped to corresponding ARN IDs for different network
   services. This enables the network's entry router to select
   different network paths based on the different ARN IDs:

   Network Path A: Network path characterized by high bandwidth

   Network Path B: Network path characterized by low latency

   Network Path C: Network path characterized by low packet loss

   If a user's different applications have varying network
   requirements, the user can directly include the corresponding
   network service's ARN ID in the transmitted datagrams. This allows
   the network's entry router to select different network paths based
   on the different ARN IDs.

9. Security Considerations

   TBD.

10. IANA Considerations

   TBD.

YANG, et al.          Expires November 10, 2024              [Page 12]
Internet-Draft   Application-Responsive Network Framework      May 2024

11. References

   11.1. Normative References

     RFC2460  S. Deering, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC 2460, December 1998

YANG, et al.          Expires November 10, 2024              [Page 13]
Internet-Draft   Application-Responsive Network Framework      May 2024

Authors' Addresses

   Feng Yang
   China Mobile
   Beijing
   China
   Email: yangfeng@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com

YANG, et al.          Expires November 10, 2024              [Page 14]