<?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-boucadair-pcp-sfc-classifier-control-01"
     ipr="trust200902">
  <front>
    <title abbrev="PCP &amp; Traffic Classification">PCP as a Traffic
    Classifier Control Protocol</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date day="" month="" year="2014" />

    <workgroup>PCP Working Group</workgroup>

    <abstract>
      <t>This document specifies how PCP (Port Control Protocol) can be used
      as a classifier control protocol.</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>PCP (Port Control Protocol, <xref target="RFC6887"></xref>) has been
      specified to control an upstream function such as NATs or firewalls. PCP
      can be used to interact with both statefull and stateless functions.</t>

      <t>PCP can be abstracted as a means to notify an upstream network with
      the flow characteristics that would trigger decisions on the appropriate
      policies to be applied on these flows at the network side. This document
      focuses on a typical function that is present in operational networks:
      Traffic Classifier Function. Two examples are listed below:<list
          style="hanging">
          <t hangText="DiffServ Classifiers">A typical example of packet
          classifier is DiffServ Classifier <xref target="RFC2475"></xref>
          that is responsible to select packets in a traffic stream based on
          the content of some portion of the packet header: this can be based
          solely on the DSCP field or based on a combination of more header
          fields, such as source address, destination address, DSCP field,
          protocol ID, source port and destination port numbers, and other
          information such as incoming interface. These classifiers must be
          configured by some means as documented in <xref
          target="RFC2475"></xref>:<list style="empty">
              <t>"Classifiers are used to "steer" packets matching some
              specified rule to an element of a traffic conditioner for
              further processing. Classifiers must be configured by some
              management procedure in accordance with the appropriate TCA
              (Traffic Conditioning Agreemet)."</t>
            </list><vspace blankLines="1" />This document proposes PCP to
          configure DiffServ Classifiers.</t>

          <t hangText="SFC Classifiers">Another classifier is SFC Classifier
          (e.g., <xref target="I-D.ietf-sfc-problem-statement"></xref> <xref
          target="I-D.ietf-sfc-architecture"></xref>). This classifier is
          responsible for classifying flows to determine which Service
          Function Chain (SFC) they belong to. <vspace
          blankLines="1" />Similar to DiffServ, an SFC Classifier can rely on
          a variety of classifying rules. <vspace blankLines="1" />PCP can be
          used to instruct SFC Classifier policies.</t>
        </list></t>

      <t>A traffic classifier (or classifier for short) is a function that is
      responsible for classifying flows based on (pre-defined) rules. Once the
      traffic is classified, it can be marked to bear its class of service
      (DSCP re-marking <xref target="RFC2474"></xref>), dropped, shaped, or
      any other action instructed by the matching rule. This document focuses
      on classification rules that manipulate L3/L4 fields of IP packets.</t>

      <t>A Classifier can be seen as a statefull service function that applies
      a set of policies for packets and/or flows matching a set of criteria.
      This document specifies how PCP can be used as a classifier control
      protocol.</t>

      <t>Note a classifier can be co-located with a CGN (Carrier Grade NAT,
      <xref target="RFC6888"></xref>), or a firewall. PCP can be used to
      install policies in all these functions.</t>
    </section>

    <section title="Scope of this Document">
      <t>This version of the document explains the motivations, basic
      assumptions, and identifies some missing features. Detailed
      specification of required extensions will be elaborated in future
      versions of the document.</t>

      <t>This document focuses on the control of L2/L3/L4 Classifiers.
      Sophisticated classifiers based on heuristics (e.g., those involving DPI
      (Deep Packet Inspection) modules) are out of scope.</t>
    </section>

    <section title="Objectives for Controlling Classifiers">
      <t>Below are listed some objectives for a classifier control means:</t>

      <t><list style="symbols">
          <t>Rationalize the management of classification rules.</t>

          <t>Help assessing the impact of removing or modifying a
          classification rule.</t>

          <t>Check the coherency of instantiated classification rules.</t>

          <t>Help aggregating rules: this allows to optimize the
          classification rule table and therefor accelerate packet/flow
          processing (mainly reduce lookup delays).</t>

          <t>Adjust classification rules when rules are based on volatile
          identifiers (e.g., IP address).</t>

          <t>Maintain an global overview of instantiated rules in involved
          Network Elements.</t>

          <t>Rapidly restore state during failure events.</t>

          <t>Network Elements can retrieve their table after failure events
          whiteout requiring permanent storage capacity.</t>
        </list></t>

      <t></t>
    </section>

    <section title="PCP as a Traffic Classifier Control Protocol">
      <t>PCP fulfils most of the objectives listed in the previous section.
      Concretely, PCP allows for the following:<list style="symbols">
          <t>Directionality</t>

          <t>Classification involving port sets</t>

          <t>Classification rules involving IPv4 addresses</t>

          <t>Classification rules involving IPv4 prefixes</t>

          <t>Classification rules involving IPv6 addresses</t>

          <t>Classification rules involving IPv6 prefixes</t>

          <t>Classification rules with or without NAT</t>

          <t>Feedback loop to assess whether a classification rule has been
          successfully enforced: PREFER_FAILURE</t>

          <t>Associate a description with classification rules</t>

          <t>Classification rules are associated with lifetimes</t>

          <t>PCP client can re-install states if a loss is detected</t>

          <t>PCP server does not need to store the entries in a permanent
          storage; state can be installed by the PCP client</t>

          <t>PCP client detects rapidly any state loss, including reboot of
          the PCP server</t>

          <t>Multiple PCP clients can control the same PCP server</t>

          <t>2-way exchange is needed to install new state</t>

          <t>No need to lock the server waiting when concurrent clients are in
          contact with the server.</t>
        </list></t>
    </section>

    <section title="Deployment Model">
      <t>The reference architecture adopted in this document assumes that both
      the PCP client and server are managed by the same administrative entity
      (e.g., an operator).</t>

      <t>Classification rules are not exposed outside an administrative
      domain. In particular, subscribers are not aware of these policies.</t>

      <t>PCP requests received in the subscriber-faced interfaces are not
      allowed to manage policies enforced in the classifiers.</t>
    </section>

    <section title="Missing PCP Extensions">
      <t>Some candidate extensions are listed below:</t>

      <t><list style="symbols">
          <t>Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC
          address), an opaque subscriber-identifier, an IMSI, etc. A candidate
          option is defined in <xref
          target="I-D.ripke-pcp-tunnel-id-option"></xref>.<vspace
          blankLines="1" />This extension is also needed to control NATs that
          are Layer-2 Aware (see Section 2.1 of <xref
          target="RFC6887"></xref>).</t>

          <t>Extended FILTER to include a remote range of ports. This
          extension might be useful for the firewall case.</t>

          <t>DSCP-based filtering. This extension is also useful for the
          firewall control case.</t>

          <t>DSCP re-marking: this is to be enforced at the boundaries of a
          domain. The marking at the access segment may not the same as the
          core network. Marking must be enforced by a trusted device.</t>

          <t>Explicit actions: re-mark, drop, shape (can be used with FLOWDATA
          <xref target="I-D.wing-pcp-flowdata"></xref>).</t>

          <t>A means to indicate the SFC binding.</t>
        </list></t>
    </section>

    <section title="Detailed Specification">
      <t>This section will be completed if the working group agrees with the
      problem to be solved.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>To be completed.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"></xref>
      MUST be taken into account.</t>
    </section>

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

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

      <?rfc include='reference.RFC.2119'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-sfc-architecture'?>

      <?rfc include='reference.I-D.ietf-sfc-problem-statement'?>

      <?rfc include='reference.I-D.ripke-pcp-tunnel-id-option'?>

      <?rfc include='reference.I-D.wing-pcp-flowdata'?>

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

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

      <?rfc include='reference.RFC.2474'?>
    </references>
  </back>
</rfc>
