<?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-du-apn6-data-driven-accounting-00"
     ipr="trust200902">
  <front>
    <title abbrev="Data-driven Accounting in APN6">Data-driven Accounting in
    Application-aware IPv6 Networking</title>

    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

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

        <email>duzongpeng@foxmail.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

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

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

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

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

        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <date month="November" year="2020"/>

    <area>Routing Area</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>APN6</keyword>

    <abstract>
      <t>This document introduces a new usecase of Application-aware IPv6
      Networking to enable data-driven accounting.</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/>

      <t>Application-aware IPv6 Networking is a kind of self-identified
      mechanism per packet. In the mechanism of APN6 <xref
      target="I-D.li-apn6-problem-statement-usecases"/>, an IPv6 packet can
      carry the APP ID information and SLA requirements of the traffic in its
      Extension Headers. Therefore, the network equipment can analyze them in
      each packet and handle the packet accordingly.</t>

      <t>In this mechanism, different user traffic can get different
      treatments so that the network resource can be used more efficiently. As
      the emergence of various new services with various requirements, the
      same treatment for all traffic cannot continue to be sustainable in
      future.</t>

      <t>Current usecases in APN6 only mention different treatments of the
      traffic, but do not mention the way to account, which is essential for
      the operator. If the operators can charge for APN services properly, the
      APN technologies will be adopted more quickly.</t>

      <t/>

      <t>This document introduces the usecase and the general process about
      the data-driven accounting in APN6.</t>

      <t/>

      <t/>
    </section>

    <section title="Current Mechanism in APN6">
      <t>As shown in Figure 1, the APN framework <xref
      target="I-D.li-apn-framework"/> includes App (Client and Server),
      App-aware Edge, App-aware-process Head-End, App-aware-process Mid-Point,
      and App-aware-process End-Point.</t>

      <t/>

      <figure>
        <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: Framework and Key Components in APN6

]]></artwork>
      </figure>

      <t/>

      <t>The data-driven process of APN6 is described below.</t>

      <t>The APP or the APP-aware Edge will generate an APN packet which
      carries the application characteristic information in the encapsulation.
      The information may include application-aware identification, such as
      SLA level, application ID, user ID, flow ID, etc., and network
      performance requirements, such as bandwidth, latency, jitter, packet
      loss ratio, etc. The former is recorded in the Application-aware ID
      Options, and the latter is recorded in the Service-Para Options defined
      in the <xref target="I-D.li-apn-framework"/>.</t>

      <t/>

      <t>App-aware-process Head-End can read that information and steer the
      packet into a given policy which satisfies the application requirements.
      It is supposed that a set of paths, tunnels or SR policies, exist
      between the App-aware-process Head-End and the App-aware-process
      End-Point. App-aware-process Head-End can find one existing path or
      establish a new one for the traffic.</t>
    </section>

    <section title="Data-driven Accounting Usecase">
      <t>In the APN architecture, a client can send both normal IPv6 packets
      and APN encapsulated packets simultaneously, which may trigger
      complicated accounting/charging mechanisms.</t>

      <t>As the treatment of the APN packets may be various according to
      multiple factors, such as the time of accessing the network, the network
      conditions, etc., a flexible accounting mechanism is needed. In
      addition, it is better that the accounting mechanism can support
      negotiations between the client and the accounting point.</t>

      <t>For example, a user occasionally needs to transfer an import file or
      attend an important meeting, they can use this APN-based data-driven
      mechanism to trigger a better network service and pay a reasonable
      amount of money.</t>
    </section>

    <section title="General Process of the Data-driven Accounting">
      <t/>

      <t>The general process of data-driven accounting is described as
      below.</t>

      <t>Firstly, the client inform the the accounting point, which is
      normally also the gateway of the client, about the requirement of the
      traffic, and optionally including the cost the user can offer.</t>

      <t>Secondly, the network provide the service accordingly.</t>

      <t>Thirdly, the client can do the accounting itself, and occasionally
      send a specific APN packet to the accounting point to align the
      accounting information.</t>

      <t>Fourthly, the network confirm the accounting information received
      from the client, and make a decision about further treatment of the
      traffic.</t>

      <t>Finally, the client may terminate the service and the accounting.</t>

      <t>As the client and the accounting point can negotiate by using this
      APN mechanism, a more flexible accounting mechanism is enabled. In this
      mechanism, the client can participate the accounting, and the accounting
      point needs to confirm the legality of the APN accounting packets.
      Therefore, the APN accounting packet should include accounting
      information of the flow and the signature of the client for the
      packet.</t>

      <t>The accounting point can notify the client about an SRv6 Accounting
      Function before the service accessing. In this case, the accounting
      information and the signature can be carried in the SRv6 SID list or
      some other places of the SRH.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>
    </section>
  </middle>

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

      <?rfc include='reference.I-D.li-apn-framework'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.li-apn6-problem-statement-usecases'?>
    </references>
  </back>
</rfc>
