[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                              Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                     Huawei Technologies
Expires: March 11, 2021                                         D. Voyer
                                                             Bell Canada
                                                                   C. Li
                                                           China Telecom
                                                                 L. Geng
                                                            China Mobile
                                                                  C. Cao
                                                            China Unicom
                                                              K. Ebisawa
                                                Toyota Motor Corporation
                                                              S. Previdi
                                                              Individual
                                                             J. Guichard
                                             Futurewei Technologies Ltd.
                                                       September 7, 2020


              Application-aware Networking (APN) Framework
                       draft-li-apn-framework-01

Abstract

   A multitude of applications are carried over the network, which have
   varying needs for network bandwidth, latency, jitter, and packet
   loss, etc.  Some new emerging applications (e.g. 5G) have very
   demanding performance requirements.  However, in current networks,
   the network and applications are decoupled, that is, the network is
   not aware of the applications' requirements in a fine granularity.
   Therefore, it is difficult to provide truly fine-granularity traffic
   operations for the applications and guarantee their SLA requirements.

   This document proposes a new framework, named Application-aware
   Networking (APN), where application characteristic information such
   as application identification and its network performance
   requirements is carried in the packet encapsulation in order to
   facilitate service provisioning, perform application-level traffic
   steering and network resource adjustment.

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



Li, et al.               Expires March 11, 2021                 [Page 1]


Internet-Draft                APN Framework               September 2020


   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 March 11, 2021.

Copyright Notice

   Copyright (c) 2020 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 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.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  APN Framework and Key Components  . . . . . . . . . . . . . .   4
   5.  APN Requirements  . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Application-aware Information Conveying Requirements  . .   6
     5.2.  Application-aware Information Handling Requirements . . .   8
       5.2.1.  App-aware SLA Guarantee . . . . . . . . . . . . . . .   8
       5.2.2.  App-aware network slicing . . . . . . . . . . . . . .   8
       5.2.3.  App-aware deterministic networking  . . . . . . . . .   9
       5.2.4.  App-aware service function chaining . . . . . . . . .   9
       5.2.5.  App-aware network measurement . . . . . . . . . . . .  10
     5.3.  Security requirements . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12



Li, et al.               Expires March 11, 2021                 [Page 2]


Internet-Draft                APN Framework               September 2020


1.  Introduction

   A multitude of applications are carried over the network, which have
   varying needs for network bandwidth, latency, jitter, and packet
   loss, etc.  Some applications such as online gaming and live video
   streaming has very demanding network requirements and therefore
   require special treatment in the network.  However, in current
   networks, the network and applications are decoupled, that is, the
   network is not aware of the applications' requirements in a fine
   granularity.  Therefore, it is difficult to provide truly fine-
   granularity traffic operations for the applications and guarantee
   their SLA requirements accordingly.
   [I-D.li-apn6-problem-statement-usecases] describes the challenges of
   traditional differentiated service provisioning methods, such as five
   tuples used for ACL/PBR causing coarse granularity, DPI imposing high
   CAPEX & OPEX and security issues, as well as orchestration and SDN-
   based solution causing long control loops.

   This document proposes a new framework, named Application-aware
   Networking (APN), aiming to guarantee fine-granularity SLA
   requirements of applications, where application characteristic
   information such as application identification and its network
   performance requirements is carried in the packet encapsulation in
   order to determine the path, steer traffic, and perform network
   resource adjustment.

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document is not a protocol specification and the key words in
   this document are used for clarity and emphasis of requirements
   language.

3.  Terminology

   ACL: Access Control List

   APN: Application-aware Networking

   APN6: Application-aware Networking for IPv6/SRv6

   DPI: Deep Packet Inspection

   MPLS: Multiprotocol Label Switching




Li, et al.               Expires March 11, 2021                 [Page 3]


Internet-Draft                APN Framework               September 2020


   PBR: Policy Based Routing

   QoE: Quality of Experience

   SDN: Software Defined Networking

   SLA: Service Level Agreement

   SR: Segment Routing

   SR-MPLS: Segment Routing over MPLS dataplane

   SRv6: Segment Routing over IPv6 dataplane

4.  APN Framework and Key Components

   The APN framework is shown in Figure 1.  The key components include
   Service-aware App, App-aware Edge Device, App-aware-process Head-End,
   App-aware-process Mid-Point, and App-aware-process End-Point.

   Packets carry application characteristic information (i.e.
   application-aware information) which includes the following
   information:

   o  Application-aware identification information: identifies the
      application, the user of the application, i.e, the packets of the
      traffic flow belonging to a specific SLA level/Application/User;

   o  Network performance requirements information that specify at least
      one of the following parameters: bandwidth, delay, delay
      variation, packet loss ratio, security, etc.

  Client                                                         Server
  +-----+                                                        +-----+
  |App x|-\                                                   /->|App x|
  +-----+ |   +-----+ +---------+   +---------+   +---------+ |  +-----+
           \->|App- | |App-aware|-A-|App-aware|-A-|App-aware|-/
  User side   |aware|-|process  |-B-|process  |-B-|process  |
           /->|Edge | |Head-End |-C-|Mid-Point|-C-|End-Point|-\
  +-----+ |   +-----+ +---------+   +---------+   +---------+ |  +-----+
  |App y|-/                                                   \->|App y|
  +-----+           ---------  Uplink   ---------->              +-----+

                  Figure 1: Framework and Key Components

   The key components are introduced as follows.





Li, et al.               Expires March 11, 2021                 [Page 4]


Internet-Draft                APN Framework               September 2020


   1.  Service-aware App: the host obtains the application
       characteristic information of the Service-aware App and generates
       the packets which carry the application characteristic
       information in the encapsulation.  If carried in the packets,
       this information is used by the App-aware-process Head-End to
       determine the path between the App-aware-process Head-End and the
       App-aware-process End-Point for forwarding the packets to their
       destination, that is, to steer the packet into a given policy
       which satisfies the application requirements.  In the APN
       framework, the application is not mandatory to be service-aware.

   2.  App-aware Edge Device: this network device receives packets from
       applications and obtains the application characteristic
       information.  If the application is not Service-aware App, the
       application characteristic information can be retrieved by packet
       inspection, derived from services information such as double VLAN
       tagging (C-VLAN and S-VLAN), or added according to the local
       policies which is out of the scope of this document.  The App-
       aware Edge Device adds the application characteristic information
       in the encapsulation on behalf of the application.  The packets
       carrying the application characteristic information will be sent
       to the App-aware-process Head-End, and the application
       characteristic information will be used to determine the path
       between the App-aware-process Head-End and the App-aware-process
       End-Point for forwarding the packets.

   3.  App-aware-process Head-End: This network device receives packets
       and obtains the application characteristic information.  A set of
       paths, tunnels or SR policy, exist between the App-aware-process
       Head-End and the App-aware-process End-Point.  The App-aware-
       process Head-End maintains the matching relationship between the
       application characteristic information and the paths between the
       App-aware-process Head-End and the App-aware-process End-Point.
       The App-aware-process Head-End determines the path between the
       App-aware-process Head-End and the App-aware-process End-Point
       according to the application characteristic information carried
       in the packets and the matching relationship with it, which
       satisfies the service requirements of the application.  If there
       is no such matching path found, the App-aware-process Head-End
       can set up a path towards the App-aware-process End-Point, and
       the matching relationship will be stored.  The App-aware-process
       Head-End forwards the packets along the path.  The application
       information conveyed by the packet received from the App-aware
       Edge Device can also be copied or be mapped to the outgoing
       packet header, e.g, IPv6 header followed by an extension header
       for further application-aware process.





Li, et al.               Expires March 11, 2021                 [Page 5]


Internet-Draft                APN Framework               September 2020


   4.  App-aware-process Mid-Point: the Mid-Point provides the path
       service according to the path set up by the App-aware-process
       Head-End which satisfies the service requirements conveyed by the
       packets.  The Mid-Point may also adjust the resource locally to
       guarantee the service requirements depending on a specific policy
       and the application-aware information conveyed by the packet.
       Policy definitions and mechanisms are out of the scope of this
       document.

   5.  App-aware-process End-Point: the process of the specific service
       path will end at the End-Point.  The service requirements
       information can be removed at the End-Point together with the
       outer encapsulation or go on to be conveyed with the packets.

   In this way the network is aware of the service requirements
   expressed by the applications explicitly.  According to the service
   requirement information carried in the packets the network is able to
   adjust its resources fast in order to satisfy the service requirement
   of applications.  The flow-driven method also reduces the challenges
   of interoperability and long control loop.

5.  APN Requirements

   APN doesn't mandate a specific encapsulation however it is reasonable
   to assume that most of the APN benefits are achieved when utilizing
   IPv6 encapsulation (e.g.  IPv6 header as well as, possibly, extension
   headers).  APN6 (the APN architecture applied to the IPv6/SRv6 data
   plane) consists of the application-aware information conveyed into
   the network through the use of IPv6 header and Extension Headers and
   where the network performs service provisioning, traffic steering,
   and SLA guarantee according to such information.  This section
   specifies the requirements for supporting the APN framework,
   including the requirements for conveying and handling the
   application-aware information and related security requirements.
   Other encapsulation may be used with some obvious constraint such as,
   as in the case of MPLS, the limited space available in the header
   (i.e., 20-bit label size).

5.1.  Application-aware Information Conveying Requirements

   The application-aware information includes application-aware
   identification information and network performance requirements
   information.

   1.  Application-aware identification information includes the
       following identifiers (IDs),





Li, et al.               Expires March 11, 2021                 [Page 6]


Internet-Draft                APN Framework               September 2020


       *  SLA level: indicates the level of SLA requirement of the
          application such as Gold, Silver, Bronze.  In some cases,
          color (e.g. red, green) can be used to indicate the SLA level.

       *  Application ID: identifies an application.

       *  User ID: identifies the user of the application.

       *  Flow ID: identifies the flow which the application traffic
          belongs to.

       The different combinations of the IDs can be used to provide
       different granularity of the service provisioning and SLA
       guarantee for the traffic.

   2.  Network performance requirements information includes the
       following parameters:

       *  Bandwidth: the bandwidth requirement of the application
          traffic

       *  Latency: the latency requirement of the application

       *  Packet loss ratio: the packet loss ratio requirement of the
          application

       *  Jitter: the jitter requirement of the application

       The different combinations of the parameters are for further
       expressing the more detailed service requirements of an
       application, conveyed together with the Application-aware
       identifiers, which can be used to match to appropriate tunnels/SR
       Policies, queues that can satisfy these service requirements.  If
       not available, new tunnels/SR Policies can also be triggered to
       be set up.

   [REQ 1a].  Application-aware identification information MUST include
   Application ID to indicate the application that generates the packet.

   [REQ 1b].  SLA level is RECOMMENDED to be included in the
   Application-aware identification information.

   [REQ 1c].  User ID and Flow ID are OPTIONAL to be included in the
   Application-aware identification information.

   [REQ 1d].  Network performance requirements information is OPTIONAL.





Li, et al.               Expires March 11, 2021                 [Page 7]


Internet-Draft                APN Framework               September 2020


   [REQ 1e].  All the nodes along the path SHOULD be able to process the
   application-aware information if needed.

   [REQ 1f].  The application-aware information can be generated
   directly by application, or by the application-aware edge devices
   though packet inspection or local policy.

   [REQ 1g].  The application-aware information SHOULD be kept intact
   when directly copied from the application-aware edge devices and
   carried in the packet.

5.2.  Application-aware Information Handling Requirements

   The app-aware-process Head-End and app-aware-process Mid-Point
   perform matching operation against the application-aware information,
   that is, to match IDs and/or service requirements to the
   corresponding network resources (tunnels/SR policies, queues).

5.2.1.  App-aware SLA Guarantee

   In order to achieve better Quality of Experience (QoE) of end users
   and engage customers, the network needs to be able to provide fine-
   granularity and even application-level SLA guarantee
   [I-D.li-apn6-problem-statement-usecases].

   [REQ 2-1a].  With the application-aware information, the App-aware-
   process Head-End SHOULD be able to steer the traffic to the tunnel/SR
   policy that satisfies the matching operation.

   [REQ 2-1b].  With the application-aware information, the App-aware-
   process Head-End SHOULD be able to trigger the setup of the tunnel/SR
   policy that satisfies the matching operation.

   [REQ 2-1c].  With the application-aware information, the App-aware-
   process Head-End and Mid-Point SHOULD be able to steer the traffic to
   the queue that satisfies the matching operation.

   [REQ 2-1d].  With the application-aware information, the App-aware-
   process Head-End and Mid-Point SHOULD be able to trigger the
   configuration of the queue that satisfies the matching operation.

5.2.2.  App-aware network slicing

   Network slicing provides ways to partition the network infrastructure
   in either control plane or data plane into multiple network slices
   that are running in parallel.  The resources on each node need to be
   associated to corresponding slices.




Li, et al.               Expires March 11, 2021                 [Page 8]


Internet-Draft                APN Framework               September 2020


   [REQ 2-2a].  With the application-aware information, the App-aware-
   process Head-End SHOULD be able to steer the traffic to the slice
   that satisfies the matching operation.

   [REQ 2-2a].  With the application-aware information, the App-aware-
   process Mid-Point SHOULD be able to associate the traffic to the
   resources in the slice that satisfies the matching operation.

5.2.3.  App-aware deterministic networking

   Along the path each node needs to provide guaranteed bandwidth,
   bounded latency, and other properties relevant to the transport of
   time-sensitive data for the Detnet flows that coexist with the best-
   effort traffic.

   [REQ 2-3a].  With the application-aware information, the App-aware-
   process Head-End SHOULD be able to steer the traffic to the
   appropriate path that satisfies the matching operation.

   [REQ 2-3b].  With the application-aware information, the App-aware-
   process Head-End SHOULD be able to trigger the setup of the
   appropriate path that satisfies the matching operation for the Detnet
   flows.

   [REQ 2-3c].  With the application-aware information, the App-aware-
   process Mid-Point SHOULD be able to associate the traffic to the
   resources along the path that satisfies the performance guarantee.

   [REQ 2-3d].  With the application-aware information, the App-aware-
   process Mid-Point SHOULD be able to reserve the resources for the
   Detnet flows along the path that satisfies the performance guarantee.

5.2.4.  App-aware service function chaining

   The end-to-end service delivery often needs to go through various
   service functions, including traditional network service functions
   such as firewalls, DPI as well as new application-specific functions,
   both physical and virtual.  SFC is applicable to both fixed and
   mobile networks as well as data center networks.

   [REQ 2-4a].  With the application-aware information, the App-aware-
   process devices SHOULD be able to steer the traffic to the
   appropriate service function.

   [REQ 2-4b].  The App-aware-process devices SHOULD be able to process
   the application-aware information carried in the packets.





Li, et al.               Expires March 11, 2021                 [Page 9]


Internet-Draft                APN Framework               September 2020


5.2.5.  App-aware network measurement

   Network measurement can be used for locating silent failure and
   predicting QoE satisfaction, which enables real-time SLA awareness/
   proactive OAM.

   [REQ 2-5a].  With the application-aware identification information,
   the App-aware-process devices SHOULD be able to perform IOAM based on
   the Application ID.

   [REQ 2-5a].  With the application-aware information, the network
   measurement results can be reported based on the Application ID and
   verify whether the performance requirements of the application are
   satisfied.

5.3.  Security requirements

   [REQ 3a].  The security mechanism defined for APN MUST allow an
   operator to prevent applications sending arbitrary application-aware
   information without agreement with the operator.

   [REQ 3b].  The security mechanism defined for APN MUST prevent an
   application requesting a service which it is not entitled to get.

6.  IANA Considerations

   This document does not include an IANA request.

7.  Security Considerations

   [I-D.li-apn6-problem-statement-usecases] and describe the security
   considerations and requirements for APN.

8.  Acknowledgements

   The authors would like to acknowledge Robert Raszuk (Bloomberg LP)
   and Yukito Ueno (NTT Communications Corporation) for their valuable
   reviews and comments.

9.  Contributors

   Daniel Bernier
   Bell Canada
   Canada

   Email: daniel.bernier@bell.ca





Li, et al.               Expires March 11, 2021                [Page 10]


Internet-Draft                APN Framework               September 2020


   Chongfeng Xie
   China Telecom
   China

   Email: xiechf@chinatelecom.cn

   Peng Liu
   China Mobile
   China

   Email: liupengyjy@chinamobile.com

   Zhuangzhuang Qin
   China Unicom
   China

   Email: qinzhuangzhuang@chinaunicom.cn

   Chang Liu
   China Unicom
   China

   Email: liuc131@chinaunicom.cn

10.  References

10.1.  Normative References

   [I-D.li-apn6-problem-statement-usecases]
              Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C.,
              Ebisawa, K., Previdi, S., and J. Guichard, "Problem
              Statement and Use Cases of Application-aware IPv6
              Networking (APN6)", draft-li-apn6-problem-statement-
              usecases-01 (work in progress), November 2019.

   [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/info/rfc2119>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.







Li, et al.               Expires March 11, 2021                [Page 11]


Internet-Draft                APN Framework               September 2020


   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
              RFC 8578, DOI 10.17487/RFC8578, May 2019,
              <https://www.rfc-editor.org/info/rfc8578>.

10.2.  Informative References

   [RFC3272]  Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X.
              Xiao, "Overview and Principles of Internet Traffic
              Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002,
              <https://www.rfc-editor.org/info/rfc3272>.

Authors' Addresses

   Zhenbin Li
   Huawei Technologies
   China

   Email: lizhenbin@huawei.com


   Shuping Peng
   Huawei Technologies
   China

   Email: pengshuping@huawei.com


   Daniel Voyer
   Bell Canada
   Canada

   Email: daniel.voyer@bell.ca


   Cong Li
   China Telecom
   China

   Email: licong@chinatelecom.cn







Li, et al.               Expires March 11, 2021                [Page 12]


Internet-Draft                APN Framework               September 2020


   Liang Geng
   China Mobile
   China

   Email: gengliang@chinamobile.com


   Chang Cao
   China Unicom
   China

   Email: caoc15@chinaunicom.cn


   Kentaro Ebisawa
   Toyota Motor Corporation
   Japan

   Email: ebisawa@toyota-tokyo.tech


   Stefano Previdi
   Individual
   Italy

   Email: stefano@previdi.net


   James N Guichard
   Futurewei Technologies Ltd.
   USA

   Email: jguichar@futurewei.com


















Li, et al.               Expires March 11, 2021                [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/