<?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-framework-00" ipr="trust200902">
  <front>
    <title abbrev="APN6 Framework">Application-aware IPv6 Networking (APN6)
    Framework</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>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.</t>

      <t>This document proposes a new framework, named Application-aware IPv6
      Networking (APN6), which makes use of IPv6 encapsulation to convey the
      application characteristic information such as application
      identification and its network performance requirements into the network
      to facilitate service provisioning, perform application-level traffic
      steering and network resource adjustment.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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. <xref
      target="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 &amp; OPEX and security issues, as well as
      orchestration and SDN-based solution causing long control loops.</t>

      <t>This document proposes a new framework, named Application-aware IPv6
      Networking, aiming to guarantee fine-granularity SLA requirements of
      applications, which make use of IPv6 encapsulation to convey the
      application characteristic such as application identification and its
      network performance requirements into the network to determine the path,
      steer traffic, and perform network resource adjustment.</t>
    </section>

    <section title="Specification of Requirements">
      <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>

      <t>This document is not a protocol specification and the key words in
      this document are used for clarity and emphasis of requirements
      language.</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>
    </section>

    <section title="APN6 Framework and Key Components">
      <t>The APN6 framework is shown in Figure 1. The key components include
      Application-aware App, App-aware Edge Device, App-aware-process
      Head-End, App-aware-process Mid-Point, and App-aware-process
      End-Point.</t>

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

      <t><list style="symbols">
          <t>Application-aware identification information: identifying
          application, the user of application, i.e. the packets as part of
          the traffic flow belonging to a specific SLA
          level/Application/User;</t>

          <t>Network performance requirements information: specifying at least
          one of the following parameters: bandwidth, delay, delay variation,
          packet loss ratio, security, etc.</t>
        </list><figure align="center">
          <artwork><![CDATA[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 APN6 Framework and Key Components]]></artwork>
        </figure></t>

      <t>The key components are introduced as follows.</t>

      <t>1. Application-aware App: The host obtains the application
      characteristic information of the Application-aware App and generates
      the packets which carry the application characteristic information in
      IPv6 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 in to a given policy which satisfies the application
      requirements. In the APN6 framework, the application is not mandatory to
      be application-aware.</t>

      <t>2. App-aware Edge Device: This network device receives packets from
      applications and obtains the application characteristic information. If
      the application is not Application-aware App, the application
      characteristic information can be obtained 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 IPv6 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.</t>

      <t>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 out
      IPv6 extension header for further application-aware process.</t>

      <t>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 IPv6 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.</t>

      <t>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 IPv6 encapsulation
      or go on to be conveyed with the IPv6 packets.</t>

      <t>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 IPv6 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
      inter-operability and long control loop.</t>
    </section>

    <section title="APN6 Requirements ">
      <t>Utilizing IPv6 encapsulation (e.g. IPv6 header as well as, possibly,
      extension headers), the application-aware information is conveyed into
      the network which performs service provisioning, traffic steering, and
      SLA guarantee according to such information. This section specifies the
      requirements for supporting the APN6 framework, including the
      requirements for conveying and handling the application-aware
      information and related security requirements.</t>

      <section title="Application-aware Information Conveying Requirements">
        <t>The application-aware information includes application-aware
        identification information and network performance requirements
        information.</t>

        <t><list style="numbers">
            <t>Application-aware identification information includes the
            following identifiers (IDs),<list style="symbols">
                <t>SLA level: indicating 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.</t>

                <t>Application ID: identifying an application.</t>

                <t>User ID: identifying the user of the application.</t>

                <t>Flow ID: identifying the flow which the application traffic
                belongs to.</t>
              </list>The different combinations of the IDs can be used to
            provide different granularity of the service provisioning and SLA
            guarantee for the traffic.</t>

            <t>Network performance requirements information includes the
            following parameters, <list style="symbols">
                <t>Bandwidth: the bandwidth requirement of the application
                traffic</t>

                <t>Latency: the latency requirement of the application</t>

                <t>Jitter: the jitter requirement of the application</t>
              </list>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.</t>
          </list></t>

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

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

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

        <t>[REQ 1d]. Network performance requirements information is
        OPTIONAL.</t>

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

        <t>[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.</t>

        <t>[REQ 1g]. The application-aware information SHOULD be kept intact
        when directly copied from the application-aware edge devices and
        carried in the IPv6 encapsulation.</t>
      </section>

      <section title="Application-aware Information Handling Requirements">
        <t>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).</t>

        <section title="App-aware SLA Guarantee">
          <t>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 <xref
          target="I-D.li-apn6-problem-statement-usecases"/>.</t>

          <t>[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.</t>

          <t>[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.</t>

          <t>[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.</t>

          <t>[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.</t>
        </section>

        <section title="App-aware network slicing">
          <t>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.</t>

          <t>[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.</t>

          <t>[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.</t>
        </section>

        <section title="App-aware deterministic networking ">
          <t>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.</t>

          <t>[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.</t>

          <t>[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.</t>

          <t>[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.</t>

          <t>[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.</t>
        </section>

        <section title="App-aware service function chaining">
          <t>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.</t>

          <t>[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.</t>

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

        <section title="App-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.</t>

          <t>[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.</t>

          <t>[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.</t>
        </section>
      </section>

      <section title="Security requirements">
        <t>[REQ 3a]. The security mechanism defined for APN6 MUST allow an
        operator to prevent applications sending arbitrary application-aware
        information without agreement with the operator.</t>

        <t>[REQ 3b]. The security mechanism defined for APN6 MUST prevent an
        application requesting a service that is not entitled to get.</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><xref target="I-D.li-apn6-problem-statement-usecases"/> and section
      5.3 describe the security considerations and requirements for APN6.</t>

      <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
      reviews 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"?>

      <?rfc include='reference.I-D.li-apn6-problem-statement-usecases'?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3272"?>
    </references>
  </back>
</rfc>
