<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-apn6-problem-statement-usecases-01"
     ipr="trust200902">
  <front>
    <title abbrev="Problem Statement and Use cases of APN6">Problem Statement
    and Use Cases of Application-aware IPv6 Networking (APN6)</title>

    <author fullname="Zhenbin Li" initials="Z. " surname="Li">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>China</country>
        </postal>

        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

    <author fullname="Shuping Peng" initials="S. " surname="Peng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>China</country>
        </postal>

        <email>pengshuping@huawei.com</email>
      </address>
    </author>

    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>Canada</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>daniel.voyer@bell.ca</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C." surname="Xie">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>xiechf.bri@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Peng Liu" initials="P." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>liupengyjy@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chang Liu" initials="C." surname="Liu">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>liuc131@chinaunicom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Kentaro Ebisawa" initials="K." surname="Ebisawa">
      <organization>Toyota Motor Corporation</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>Japan</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>ebisawa@toyota-tokyo.tech</email>

        <uri/>
      </address>
    </author>

    <author fullname="Stefano Previdi" initials="S." surname="Previdi">
      <organization>Individual</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>Italy</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>stefano@previdi.net</email>

        <uri/>
      </address>
    </author>

    <author fullname="James N Guichard" initials="J." surname="Guichard">
      <organization>Futurewei Technologies Ltd.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>jguichar@futurewei.com</email>

        <uri/>
      </address>
    </author>

    <date day="04" month="November" year="2019"/>

    <abstract>
      <t>Network operators are facing the challenge of providing better
      network services for users. As the ever developing 5G and industrial
      verticals evolve, more and more services that have diverse network
      requirements such as ultra-low latency and high reliability are
      emerging, and therefore differentiated service treatment is desired by
      users. However, network operators are typically unaware of which
      applications are traversing their network infrastructure, which means
      that only coarse-grained services can be provided to users. As a result,
      network operators are only evolving their infrastructure to be large but
      dumb pipes without corresponding revenue increases that might be enabled
      by differentiated service treatment. As network technologies evolve
      including deployments of IPv6 and SRv6, the programmability provided by
      IPv6 and SRv6 encapsulations can be augmented by conveying application
      related information into the network. Adding application knowledge to
      the network layer allows applications to specify finer granularity
      requirements to the network operator.</t>

      <t>This document analyzes the existing problems caused by lack of
      application awareness, and outlines various use cases that could benefit
      from an Application-aware IPv6 Networking (APN6) architecture.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Due to the requirement for differentiated traffic treatment driven by
      diverse new services, the ability to convey the characteristics of an
      application's traffic flow and program the network infrastructure
      accordingly to provide fine-grained service assurance is becoming
      increasingly necessary for network operators. The Application-aware IPv6
      Networking (APN6) architecture is being defined to address the
      requirements and use cases described in this document. APN6 takes
      advantage of network programmability by conveying application related
      information in the data plane allowing applications to specify finer
      grained requirements to the network infrastructure.</t>
    </section>

    <section title="Terminology">
      <t>ACL: Access Control List</t>

      <t>APN6: Application-aware IPv6 Networking</t>

      <t>DPI: Deep Packet Inspection</t>

      <t>PBR: Policy Based Routing</t>

      <t>QoE: Quality of Experience</t>

      <t>SDN: Software Defined Networking</t>
    </section>

    <section title="Problem Statement">
      <t>This section summarizes the challenges currently faced by network
      operators when attempting to provide fine-grained traffic operations to
      satisfy the various application-awareness requirements demanded by new
      services that require differentiated service treatment.</t>

      <section title="Large but Dumb Pipe">
        <t>In today's networks, the infrastructure through which user traffic
        is forwarded is not able to determine information about the packet,
        including which application the traffic belongs to, without the
        introduction of middleware such as DPI, that is, the network and
        applications are decoupled. It is therefore difficult for network
        operators to provide fine-grained traffic operations for
        performance-demanding applications. In order to satisfy the SLA
        requirements network operators continue to increase the network
        bandwidth but only carrying very light traffic load (around 30%-40% of
        its capacity). This situation greatly increases the CAPEX and OPEX but
        only brings very little revenue from the carried services.</t>
      </section>

      <section title="Network on Its Own">
        <t>As the network evolves, technologies such as VPN/TE/FRR play
        important roles in satisfying service isolation, SLA guarantee, and
        high reliability, etc. These network technologies have themselves been
        evolving, introducing new features that forces the network operator to
        be continuously upgrading their network infrastructure. However, none
        of these network technologies make the network aware of which
        application traffic belongs to and the fine granularity requirements
        of the application. Therefore, such continuous network infrastructure
        upgrade doesn't always enable true fine-grained traffic operation,
        therefore reducing the ability to bring corresponding revenue
        increase.</t>
      </section>

      <section title="Decoupling of Network and Applications">
        <t>MPLS played a very important role in helping the network enter the
        generation of All-IP successfully. However, MPLS doesn't allow a close
        interworking with the application layer since MPLS encapsulation is,
        typically, not used by the packet source.</t>

        <t>As new services continuously evolve, more encapsulations are
        required, and this isolation and decoupling has further become the
        blockage towards the seamless convergence of the network and
        applications.</t>
      </section>

      <section title="Challenges of Traditional Differentiated Service Provisioning">
        <t>Several IETF activities have been reviewed which are primarily
        intended to evolve the IP architecture to support new service
        definitions which allow preferential or differentiated treatment to be
        accorded to certain types of traffic. The challenge when using
        traditional ways to guarantee an SLA is that the packets are not able
        to carry enough information for indicating applications and expressing
        their service/SLA requirements. The network devices mainly rely on the
        5-tuple of the packets or DPI. However, there are some challenges for
        these traditional methods in differentiated service provisioning:</t>

        <t>1. Five Tuples used for ACL/PBR</t>

        <t>Five tuples are widely used for ACL/PBR matching of traffic.
        However, these features cannot provide enough information for the
        fine-grained service process, and can only provide indirect
        application information which needs to be translated in order to
        indicate a specific application.</t>

        <t>2. Deep Packet Inspection (DPI)</t>

        <t>If more information is needed, it must be extracted using DPI which
        can inspect deep into the packets for application specific
        information. However, this will introduce more CAPEX and OPEX for the
        network operator and imposes security challenges.</t>

        <t>3. Orchestration and SDN-based Solution</t>

        <t>In the era of SDN, typically, an SDN controller is used to manage
        and operate the network infrastructure and orchestrator elements
        introduce application requirements so that the network is programmed
        accordingly. The SDN controller can be aware of the service
        requirements of the applications on the network through the interface
        with the orchestrator, and the service requirement is used by the
        controller for traffic management over the network. However, this
        method raises the following problems:</t>

        <t>1) The whole loop is long and time-consuming which is not suitable
        for fast service provisioning for critical applications;</t>

        <t>2) Too many interfaces are involved in the loop, as shown in Figure
        1, which introduce challenges of standardization and
        inter-operability.</t>

        <t><figure>
            <artwork><![CDATA[                     +--------------+
               /-----| Orchestrator | -------------------\
              /      +--------------+     Resource        \
APP Req.     /                     \        Management      \
       +---------+            +---------+       &        +---------+
       |SDN Ctrl1|            |SDN Ctrl2|    Service     |SDN Ctrl3|
       +---------+            +---------+  Provisioning  +---------+
APP Req. /     \             /           \              /           \
      +-/-+  +--\--+  +----------+  +----------+  +----------+  +----------+
      |APP|  | DCN |  |Network D1|..|Network D3|  |Network D4|..|Network D6|
      +---+  +-----+  +----------+  +----------+  +----------+  +----------+

Figure 1. Many interfaces involved in the long service-provisioning loop 
]]></artwork>
          </figure></t>
      </section>

      <section title="Challenges of Supporting New 5G and Edge Computing Technologies">
        <t>New technologies such as 5G, IoT, and edge computing, are
        continuously developing leading to more and more new types of services
        accessing the network. Large volumes of network traffic with diverse
        requirements such as low latency and high reliability are therefore
        rapidly increasing. If traditional methods for differentiation of
        traffic continue to be utilized, it will cause much higher CAPEX and
        OPEX to satisfy the ever-developing applications' diverse
        requirements.</t>
      </section>
    </section>

    <section title="Key Elements of Application-aware IPv6 Networking (APN6)">
      <t>Application-aware IPv6 Networking (APN6) aims to address the
      aforementioned problems associated with fine-grained traffic operations
      that are required in order to satisfy the various application-awareness
      requirements demanded by new services that need differentiated service
      treatment. APN6 conveys information into the network infrastructure
      about the characteristics of the application associated with a traffic
      flow (including application identification and network performance
      requirements), allowing the network to quickly adapt and perform the
      necessary network resource adjustments to maintain SLA performance
      guarantees, and hence better serve application fine-grained service
      requirements.</t>

      <t>The advantages of using IPv6 to support APN6 include,</t>

      <t><list style="numbers">
          <t>Simplicity: Conveying application information with IPv6
          encapsulation can just be based on IP reachability.</t>

          <t>Seamless convergence: Much easier to achieve seamless convergence
          between applications and network since both are based on IPv6.</t>

          <t>Great extensibility: IPv6 encapsulation including its extension
          headers can be used to carry very rich information relevant to
          applications.</t>

          <t>Good compatibility: On-demand network upgrade and service
          provisioning. If the application information is not recognized by
          the node, the packet will be forwarded based on pure IPv6, which
          ensure backward compatibility.</t>

          <t>Little dependency: Information conveying and service provisioning
          are only based on the forwarding plane of devices, which is
          different from the Orchestration and SDN-based solution which
          involves multiple elements and diverse interfaces.</t>

          <t>Quick response: Flow-driven and direct response from devices
          since it is based on the forwarding plane.</t>
        </list></t>

      <t>APN6 has the following key elements:</t>

      <t><list style="numbers">
          <t>Application information should be conveyed in the data plane
          through augmentation of existing encapsulations such as IPv6 and/or
          SRv6. The conveyed application characteristic information
          (application-aware information) includes application identification
          and/or its network performance requirements. This element should not
          be enforced but provide an open option for applications to decide
          whether to input this application-aware information into their data
          stream.</t>

          <t>Application information and network service provisioning matching
          providing fine-granularity network service provisioning (traffic
          operations) and SLA guarantee based on the application-aware
          information carried in APN6 packets. This element provides the
          network capabilities to applications. According to the
          application-aware information, appropriate network services are
          selected, provisioned, and provided to the demanding applications to
          satisfy their performance requirements.</t>

          <t>Network measurement of network performance and update the match
          between the applications and corresponding network services for
          better fine-granularity SLA compliance. The network measurement
          methods include in-band and out-of-band, passive, active,
          per-packet, per-flow, per node, end-to-end, etc. These methods can
          also be integrated.</t>
        </list></t>

      <t><figure>
          <artwork><![CDATA[   
          Applications         |          Network 

Element 1: Conveying  ------------------->
                              /|\
          Application Info     |     Network capabilities 
                               |       (SLA guarantee)
                               |             /|\
                      Element 2: Matching     |
                                              | 
                                     Element 3: Network Measurement

Figure 2. Illustration of the key elements of APN6
]]></artwork>
        </figure></t>
    </section>

    <section title="Use cases for Application-aware IPv6 Networking (APN6)">
      <t>This section provides the use cases that can benefit from the
      application awareness introduced by APN6. The corresponding requirements
      for APN6 are also outlined.</t>

      <section title="Application-aware SLA Guarantee">
        <t>One of the key objectives of APN6 is for network operators to
        provide fine-granularity SLA guarantees instead of coarse-grain
        traffic operations. Among various applications being carried and
        running in the network, some revenue-producing applications such as
        online gaming, video streaming, and enterprise video conferencing have
        much more demanding performance requirements such as low network
        latency and high bandwidth. In order to achieve better Quality of
        Experience (QoE) for end users and engage customers, the network needs
        to be able to provide fine-granularity and even application-level SLA
        guarantee. Differentiated service provisioning is also desired.</t>

        <t>One of the key objective of APN6 is for network operators to
        provide fine-granularity SLA guarantees instead of coarse-grain
        traffic operations. This will enable them to provide differentiated
        services for different applications and increase revenue
        accordingly.</t>

        <t>The APN6 architecture design MUST address the following
        requirements:</t>

        <t><list style="symbols">
            <t>APN6 needs to perform the three key elements as described in
            Section 4.</t>

            <t>Support application-level fine-granularity traffic operation
            that may include finer QoS scheduling.</t>
          </list></t>
      </section>

      <section title="Application-aware network slicing">
        <t>More and more applications/services with diverse requirements are
        being carried over and sharing the network operators' network
        infrastructure. However, it is still desirable to have customized
        network transport that can support some application's specific
        requirements, taking into consideration service and resource
        isolation, which drives the concept of network slicing.</t>

        <t>Network slicing provides ways to partition the network
        infrastructure in either the control plane or data plane into multiple
        network slices that are running in parallel. These network slices can
        serve diverse services and fulfill their various requirements at the
        same time. For example, the mission critical application that requires
        ultra-low latency and high reliability can be provisioned over a
        separate network slice.</t>

        <t>The APN6 architecture design MUST address the following
        requirements:</t>

        <t><list style="symbols">
            <t>APN6 needs to perform the three key elements as described in
            Section 4 in the context of network slicing. To be more specific,
            for element 2, it needs to match to a specific network slice
            according to the application information carried in the APN6
            packets. The network measurement in element 3 also needs to happen
            within each network slice.</t>
          </list></t>
      </section>

      <section title="Application-aware Deterministic Networking ">
        <t><xref target="RFC8578"/> documents use cases for diverse industry
        applications that require deterministic flows over multi-hop paths.
        Deterministic flows provide guaranteed bandwidth, bounded latency, and
        other properties relevant to the transport of time-sensitive data, and
        can coexist on an IP network with best-effort traffic. It also
        provides for highly reliable flows through provision for redundant
        paths.</t>

        <t>The APN6 architecture design MUST address the following
        requirements:</t>

        <t><list style="symbols">
            <t>APN6 needs to perform the three key elements as described in
            Section 4 in the context of deterministic networking. To be more
            specific, for the element 2, it needs to match to a specific
            deterministic path according to the application information
            carried in the APN6 packets. The network measurement in element 3
            also needs to be performed on each application-aware deterministic
            path.</t>
          </list></t>
      </section>

      <section title="Application-aware Service Function Chaining">
        <t>End-to-end service delivery often needs to go through various
        service functions, including traditional network service functions
        such as firewalls, DPIs as well as new application-specific functions,
        both physical and virtual. The definition and instantiation of an
        ordered set of service functions and subsequent steering of the
        traffic through them is called Service Function Chaining (SFC) <xref
        target="RFC7665"/>. SFC is applicable to both fixed and mobile
        networks as well as data center networks.</t>

        <t>Generally, in order to manipulate a specific application traffic
        along the SFC, a DPI needs to be deployed as the first service
        function of the chain to detect the application, which will impose
        high CAPEX and consume long processing times. For encrypted traffic,
        it even becomes impossible to inspect the application.</t>

        <t>The APN6 architecture design MUST address the following
        requirements:</t>

        <t><list style="symbols">
            <t>APN6 needs to perform the three key elements as described in
            Section 4 in the context of service function chaining. To be more
            specific, for element 1 class information can be conveyed. For
            element 2, it needs to match to a specific service function chain
            and subsequent steering according to the application information
            carried in the APN6 packets. The network measurement in element 3
            also needs to happen within each app-aware service function
            chain.</t>
          </list></t>
      </section>

      <section title="Application-aware Network Measurement">
        <t>Network measurement can be used for locating silent failure and
        predicting QoE satisfaction, which enables real-time SLA
        awareness/proactive OAM. Operations, Administration, and Maintenance
        (OAM) refers to a toolset for fault detection and isolation, and
        network performance measurement. In-situ Operations, Administration,
        and Maintenance (IOAM) records operational and telemetry information
        in the packet while the packet traverses a path between two points in
        the network.</t>

        <t>The APN6 architecture MUST address the following requirements:</t>

        <t><list style="symbols">
            <t>APN6 needs to perform the two key elements as described in
            Section 4 in the context of network measurement. The network
            measurement in element 3 does not need to be considered here.</t>
          </list></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not include an IANA request.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Since the application information is conveyed into the network, it
      does involve some security and privacy issues.</t>

      <t>First, APN6 only provides the capability to the applications to
      provide their profiles and requirements to the network, but it leaves
      the applications to decide whether to input this information. If the
      applications decide not to provide any information, they will be treated
      in the same way as today's network and cannot get the benefits from
      APN6.</t>

      <t>Once the application information has been carried in the IPv6 packets
      and conveyed into the network, the IPv6 extension headers, AH and ESP,
      can be used to guarantee the authenticity of the added application
      information.</t>

      <t>Any scheme involving an information exchange between layers
      (application and network layers in this case) will obviously require an
      accurate valuation of security mechanism in order to prevent any leak of
      critical information. Some additional considerations may be required for
      multi-domain use cases. For example, how to agree upon which application
      information/ID to use and guarantee authenticity for packets traveling
      through multiple domains (network operators).</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to acknowledge Robert Raszuk (Bloomberg LP)
      and Yukito Ueno (NTT Communications Corporation) for their valuable
      review and comments.</t>
    </section>

    <section title="Contributors">
      <t><figure>
          <artwork><![CDATA[Liang Geng
China Mobile
China]]></artwork>
        </figure></t>

      <t>Email: gengliang@chinamobile.com</t>

      <t><figure>
          <artwork><![CDATA[Chang Cao
China Unicom
China]]></artwork>
        </figure></t>

      <t>Email: caoc15@chinaunicom.cn</t>

      <t><figure>
          <artwork><![CDATA[Cong Li
China Telecom
China]]></artwork>
        </figure></t>

      <t>Email: licong.bri@chinatelecom.cn</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include='reference.RFC.8200'?>

      <?rfc include="reference.RFC.8578"?>

      <?rfc include="reference.RFC.7665"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-spring-srv6-network-programming'?>

      <?rfc include='reference.I-D.ietf-6man-segment-routing-header'?>
    </references>
  </back>
</rfc>
