draft-peng-apn-scope-gap-analysis-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com 
     This can be converted using the Web service at http://xml.resource.org/ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- You want a table of contents -->
<!-- Use symbolic labels for references -->
<!-- This sorts the references -->
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<rfc category="info" docName="draft-peng-apn-scope-gap-analysis-01" ipr="trust200902">
  <front>
    <title abbrev="APN Scope and Gap Analysis">APN Scope and Gap Analysis</title>

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

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

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

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

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

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

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

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

    <date day="26" month="January" year="2021"/>

    <area>Networking</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>APN; Scope; Gap Analysis</keyword>

    <abstract>
<t>The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an identifier to allow for the implementation of fine-grain user (group)-, application (group)-, and service-level requirements at the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, that is, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to realise this composite network service provisioning along the path very efficiently. This document further clarifies the scope of the APN work and describesthe solution gap analysis. </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>Application-aware Networking (APN) is introduced in <xref target="I-D.li-apn-framework"/> and <xref target="I-D.li-apn-problem-statement-usecases"/>. APN conveys an identifier along with data packets into network and make the network aware of fine-grain user (group)-, application (group)-, and service-level requirements.</t>
	  
<t>Such an identifier is acquired, constructed in a structured value, and then encapsulated in the packets. Such structured value is treated as an opaque object in the network, to which the network operator applies policies in various nodes/service functions along the path and provide corresponding services. The identifier may represent the traffic of a particular user/application group and/or service-level requirement but does not directly identify the actual user nor the actual application on the wire.</t>

<t>This structured identifier can be encapsulated in various data plane adopted within a Network Operator controlled limited domain, e.g. MPLS, VXLAN, SR/SRv6 and other tunnel technologies, which waits to be further specified. In an IPv6 network, a design proposal of the structured value can refer to <xref target="I-D.li-6man-app-aware-ipv6-network"/>. </t>

<t>With APN, it becomes possible to apply various policies in different nodes along a network path onto a traffic flow altogether in a more efficient way, that is, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to realise this composite network service provisioning along the path very efficiently. It may be possible to stack those various policies in a list of TLVs at the headend. However, this approach would introduce great complexities and impose big challenges on the hardware processing and forwarding.</t>
	  
<t>The example use-case presented in this draft further expands on the rationale for such an identifier and how it can be derived and used in that specific context.</t>

<t>This document further clarifies the scope of the APN work and describes the solution gap analysis.</t>

</section>

<section title="Terminologies">

<t>APN: Application-aware Networking</t>
<t>CPE: Customer Premises Equipment</t>
<t>DPI: Deep Packet Inspection</t>
<t>OS: Operating System</t>

</section>

<section title="APN Framework and Scope">

<t>The APN framework is introduced in <xref target="I-D.li-apn-framework"/>, as shown in the Figure 1.</t>

      <t><figure align="center">
        <artwork><![CDATA[
		
+-----+                                                    +-----+
|App x|-\                                                /-|App x|
+-----+ |  +-----+   +-----------------------+   +-----+ | +-----+
         \-|App- |   |   Application-aware   |   |App- |-/           
           |aware|---|        Network        |---|aware|               
         /-|Edge |   |  Service Provisioning |   |Edge |-\           
+-----+ |  +-----+   +-----------------------+   +-----+ | +-----+
|App y|-/     |                                     |    \-|App y|
+-----+       |<--- Network Operator Controlled --->|      +-----+
                          Limited Domain
                    
					]]>

                 Figure 1. APN Framework and Scope
		</artwork>
        </figure></t>

<t>With APN, the identifier is added to the data packets (e.g. in the IPv6 extensions headers <xref target="I-D.li-6man-app-aware-ipv6-network"/>) and delivered to the network, wherein, according to this identifier, corresponding network services are provisioned.</t>

<t>The identifier can be added either directly by the application (e.g. App x in the Figure 1) or at the network edge devices (i.e. App-aware Edge in the Figure 1), named as host-side solution and network-side solution, respectively. </t>

<t>With the host-side solution, after the identifier is obtained by application, it will be added to the data packets during its encapsulation process going through the protocol stack in the OS. The host-side solution may require an update of the underlying operating system in order to allow the application element to pass the identifier to the socket service when building the packet header.</t>

<t>With the network-side solution, the identifier is added according to the configured policy at the network edge device. For the APN work to be conducted in IETF, we will focus on the network-side solution.</t>

<t>APN works within a limited trusted domain. Typically, an APN domain is defined as a Network Operator controlled limited domain (see Figure 1), in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to provide network services.</t>

</section>

<section title="Example Use Case and Existing Issues">
<t>To be more specific and more concrete, here we use SD-WAN as an example use case to further expand on the rationale for such identifier and how it can be derived and used in that specific context.</t>

<t>In the case of SD-WAN, an enterprise obtains WAN services from an SD-WAN provider so that its employees have access to the applications in the Cloud, and then the SD-WAN provider may buy WAN lines from a Network Operator. The enterprise may know what applications will use the SD-WAN services, but it will only provide the 5 tuples (i.e., source IP address, source port, destination IP address, destination port, transport protocol) of those applications to the SD-WAN provider. So, the SD-WAN provider does not know what applications it is serving, and will only provide 5 tuples to the Network Operator and the service performance requirements for steering their customer's traffic. In this way, the Network Operator does not know anything else about the traffic except the 5 tuples and requirements. Nowadays, SD-WAN is usually using 5-tuple to steer the traffic into corresponding WAN lines across the Network Operator's network <xref target="SD-WAN"/>.</t> 

<t>However, there are two main issues in the current SD-WAN deployments.</t>

<t>1) It is complicated to resolve the 5 tuples. Even worse, as the traffic is encrypted, it becomes impossible to obtain any transport layer information. Moreover, in the IPv6 data plane, with the extension headers being added before the upper layer, in some implementations it becomes very difficult and even impossible to obtain transport layer information because that information is so deep in the packet. So, there is no 5 tuples anymore, and maybe only 2 tuples are available.</t>

<t>2) Currently there is still no way to apply various policies in different nodes along the network path onto a traffic flow altogether, that is, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. It may be possible to stack those various policies in a list of TLVs at the headend. However, this approach would introduce great complexities and impose big challenges on the hardware processing and forwarding.</t>

</section>

<section title="Basic Solution and Benefits">

<t>With APN, at the edge node, i.e. CPE, of the SD-WAN (see Figure 2), the 5-tuple, plus information related to user or application requirements is constructed into a structured value. Please note, here the structured value is just a bit string and does not indicate actual application or user identification. This information is only meaningful for the network operators to apply various policies in different nodes/service functions, which can be enforced from the Controllers. </t>

      <t><figure align="center">
        <artwork><![CDATA[
                        +-----------------+
              +---------|SD-WAN Controller|---------+
              |         +--------|--------+         |
              |                  |                  |
              |          +-------|-------+          |
              |          |SDN  Controller|          |
              |          +-------|-------+          |
+-----+       |                  |                  |      +-----+
|App x|-\     |                  |                  |    /-|App x|
+-----+ |  +--|--+   +-----------|-----------+   +--|--+ | +-----+
         \-|     |   |   Application-aware   |   |     |-/           
           |CPE 1|---|        Network        |---|CPE 2|               
         /-|     |   |  Service Provisioning |   |     |-\           
+-----+ |  +-----+   +-----------------------+   +-----+ | +-----+
|App y|-/     |                                     |    \-|App y|
+-----+       |<--- Network Operator Controlled --->|      +-----+
                          Limited Domain
                    
					]]>
                 Figure 2. SD-WAN using the APN Framework
		</artwork>
        </figure></t>

<t>With such an identifier in the network, we can easily solve the two issues above-mentioned.
It is not necessary to resolve the 5-tuple and perform the deep inspection in every node along the path. This structured value is encapsulated in the IP layer and can be easily read by the routers and service functions. If the data plane is SRv6, for example, such an identifier can be encapsulated in an SRH TLV where it represents the policy corresponding to the application requirements.</t>

<t>Since this identifier is taken as an object to the network, the network operators will simply place the policies in the nodes/service functions where this indicated traffic will go through, and the corresponding node/service function will just apply policies for this object. This can be easily done by utilizing this structured value, which is not possible with any current existing mechanism.</t>

<t>Such structured value will also bring other benefits, for example,</t>

<t><list style="symbols">

<t>Improve the forwarding performance since it will only use 1 field in the IP layer instead of resolving 5 tuples, which will also improve the scalability.</t>

<t>Very flexible policy enforcement in various nodes and service functions along the network path.</t>

</list></t>

<t>Furthermore, with such structured value, more new services could be enabled, for example,</t>

<t><list style="symbols">

<t>Even more fine-granularity performance measurement could be achieved and the granularity to be monitored and visualized can be controllable, which is able to relieve the processing pressure on the controller when it is facing the massive monitoring data.</t>

<t>The policy execution on the service function can be based only on this value and not based on 5-tuple, which can eliminate the need of deep packet inspection.</t>

<t>The underlay performance guarantee could be achieved for SD-WAN overlay services, such as explicit traffic engineering path satisfying SLA and selective visualized accurate performance measurement.</t>

</list></t>

</section>

<section title="Solution Gap Analysis">
<t>There are already some solutions specified in IETF, which use identifier to perform traffic steering and service provisioning. However, none of them is the same as APN and able to achieve the same effects. </t>

	<section title="IPv6/MPLS Flow Label">
	<t><xref target="RFC6437"/> specifies the IPv6 flow label which enables the IPv6 flow classification. However, the IPv6 flow label is mainly used for Equal Cost Multipath Routing (ECMP) and Link Aggregation <xref target="RFC6438"/>.</t>
	  
	<t>Similarly, <xref target="RFC6391"/> describes a method of adding an additional Label Stack Entry (LSE) at the bottom of the stack in order to facilitate the load balancing of the flows within a pseudowire (PW) over the available ECMPs. A similar design for general MPLS use has also been proposed in <xref target="RFC6790"/> using the concept of Entropy Label.</t>

	</section>

	<section title="SFC ServiceID">
	<t>Subscriber Identifier and Performance Policy Identifier are specified in <xref target="I-D.ietf-sfc-serviceid-header"/>. These identifiers are carried only in the Network Service Header (NSH) [RFC8300] Context Header, as shown in Figure 3, while the APN identifier can be carried in various data plane encapsulations. </t> 	
	
	      <t><figure align="center">
        <artwork><![CDATA[
		
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                      Subscriber Identifier                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  
	  
	  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     Performance Policy Identifier             ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

				]]>
      Figure 3. Subscriber Identifier and Performance Policy Identifier
		</artwork>
        </figure></t>
		
	<t>In this draft <xref target="I-D.ietf-sfc-serviceid-header"/>, the Subscriber Identifier carries an opaque local identifier that is assigned to a subscriber by a network operator, and the Performance Policy Identifier represents an opaque value pointing to specific performance policy to be enforced. In this way, in order to apply various policies in different nodes along the network path onto a traffic flow altogether, e.g., at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies, those various policies would have to be stacked in a list of TLVs at the headend, introducing great complexities and big challenges on the hardware processing and forwarding.</t>

	<t>The APN identifier, which is a structured value, is treated as an opaque object in the network, to which the network operator applies policies in various nodes/service functions along the path and provide corresponding services. The identifier may represent the application traffic of a particular user but does not identify the actual user nor the actual application for network operators. </t> 
	</section>
	
	<section title="IOAM Flow ID">
	<t>A 32-bit Flow ID is specified in <xref target="I-D.ietf-ippm-ioam-direct-export"/>, which is used to correlate the exported data of the same flow from multiple nodes and from multiple packets, while the APN identifier can serve more various purposes. </t>
	</section>
	
	<section title="Binding SID">
	<t>The Binding SID (BSID) <xref target="RFC8402"/> is bound to an SR Policy, instantiation of which may involve a list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy. A BSID may be either a local or a global SID. While the APN identifier is not bound to SRv6 only, and it can be carried in various data plane encapsulations. </t>
	</section>
	
	<section title="FlowSpec Label">
	<t>The flow specification (FlowSpec) <xref target="RFC5575"/> is actually an n-tuple consisting of several matching criteria that can be applied to IP traffic, which include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers. In BGP VPN/MPLS networks, BGP FlowSpec can be extended to identify and change (push/swap/pop) the label(s) for traffic that matches a particular FlowSpec rule in <xref target="I-D.ietf-idr-flowspec-mpls-match"/> and <xref target="I-D.ietf-idr-bgp-flowspec-label"/>. In <xref target="I-D.liang-idr-bgp-flowspec-route"/>, BGP is used to distribute the FlowSpec rule bound with label(s). While the APN identifier is not bound to MPLS only, and it can be carried in various data plane encapsulations.</t>

	</section>
	
	<section title="Summary">
	<t>As driven by ever-emerging new 5G services, fine-granularity service provisioning becomes urgent. The existing solutions are either specific to a particular scenario or data plane. While APN aims to define a generalized identifier used for fine-granularity service provisioning, and can be carried in various data plane encapsulations.</t>
	</section>
	
</section>



<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA considerations in this document.</t>
</section>

<section title="Acknowledgements">
      <t>The authors would like to acknowledge Martin Vigoureux, Alvaro Retana, Barry Leiba, Stefano Previdi, Adrian Farrel, and Daniel King for their valuable review and comments.</t>
    </section>

</middle>

	<back>
		<references title="Informative References">
			<?rfc include="reference.RFC.2119"?>
			<?rfc include="reference.RFC.6437"?>
			<?rfc include="reference.RFC.6438"?>
			<?rfc include="reference.RFC.6391"?>
			<?rfc include="reference.RFC.6790"?>
			<?rfc include="reference.RFC.8402"?>
			<?rfc include="reference.I-D.li-apn-framework"?>
			<?rfc include="reference.I-D.li-apn-problem-statement-usecases"?>
			<?rfc include="reference.I-D.li-6man-app-aware-ipv6-network"?>
			<?rfc include="reference.I-D.peng-apn-security-privacy-consideration"?>
			<?rfc include="reference.I-D.ietf-ippm-ioam-direct-export"?>
			<?rfc include="reference.I-D.ietf-sfc-serviceid-header"?>
			<?rfc include="reference.RFC.5575"?>
			<?rfc include="reference.I-D.ietf-idr-flowspec-mpls-match"?>		
			<?rfc include="reference.I-D.liang-idr-bgp-flowspec-route"?>
			<?rfc include="reference.I-D.ietf-idr-bgp-flowspec-label"?>
			
		    <reference anchor="SD-WAN">
				<front>
					<title>SD-WAN Service Attributes and Service Framework</title>
					<author initials="" surname="MEF 70.1 Draft (R1), available at https://www.mef.net/wp-content/uploads/2020/08/MEF-70-1-Draft-R1.pdf/" />		  
					<date year="August 2020"/>
				</front>
            </reference>		
		</references>	  
	</back>
</rfc>