One document matched: draft-boucadair-pcp-sfc-classifier-control-00.xml

<?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-00"
     ipr="trust200902">
  <front>
    <title abbrev="PCP & 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="15" month="April" 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>) is a
      protocol that has been specified to control an upstream function such
      NATs or firewalls. PCP can be used to interact with 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.</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 typical example of packet classifier is DiffServ Classifier <xref
      target="RFC2475"></xref> that responsible to select packets in a traffic
      stream based on the content of some portion of the packet header: this
      can be solely on the DSCP field or based on a combination of one or 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></t>

      <t>Another classifier is SFC Classifier (e.g., <xref
      target="I-D.ietf-sfc-problem-statement"></xref><xref
      target="I-D.boucadair-sfc-framework"></xref>). This classifier is
      responsible for classifying flows to determine which Service Function
      Chain they belong to. Similar to Diffserv, an SFC Classifier can rely on
      a variety of classifying rules.</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>

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

    <section title="Scope of this Document">
      <t>Early versions of the document explains the motivations, basic
      assumptions, and identify 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 of this document.</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>PCP allows the following:</t>

      <t><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: PREFERE_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="Candidate 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.</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 might be useful for the
          firewall 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).</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.boucadair-sfc-framework'?>

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

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

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

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