<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="5"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-boucadair-pcp-deployment-cases-03"
     ipr="trust200902">
  <front>
    <title abbrev="PCP Deployment Cases">Port Control Protocol (PCP)
    Deployment Models</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="03" month="July" year="2014" />

    <workgroup>PCP Working Group</workgroup>

    <abstract>
      <t>This document lists a set of Port Control Protocol (PCP) deployment
      models.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document lists a set of PCP <xref target="RFC6887"></xref>
      deployment models.</t>
    </section>

    <section title="Terminology">
      <t>This document makes use of the following terms:<?rfc subcompact="yes" ?></t>

      <t><list style="symbols">
          <t>PCP client denotes a functional element responsible for issuing
          PCP requests to a PCP server. Refer to <xref
          target="RFC6887"></xref>.</t>

          <t>PCP server denotes a functional element that receives and
          processes PCP requests from a PCP client. A PCP server can be
          co-located with or be separated from the function (e.g., NAT,
          Firewall) it controls. Refer to <xref target="RFC6887"></xref>.</t>

          <t>PCP proxy refers to a functional elements that is responsible for
          relaying PCP requests received from PCP client to upstream PCP
          servers.</t>
        </list><?rfc subcompact="no" ?></t>
    </section>

    <section title="CPE Models">
      <t></t>

      <section title="Single Homed CPE Model: Local PCP Server">
        <t>This model assumes PCP is enabled in the LAN side to control
        functions located in the CPE. The PCP server is reachable with the IP
        address of the private-faced interface of the CPE. Typical functions
        that can be controlled by PCP in this model are NAT and firewall.</t>

        <t><figure>
            <artwork><![CDATA[
   +-------------+
   |    PCP      |
   |   Client    |----+                           ,-----------.
   +-------------+    |   +------------+        ,'             `--.
                      +---|    CPE     |        /                   :
                          | PCP server |_______;        ISP         |
                      +---| NAT+FW+..  |       :                    |
   +-------------+    |   +------------+        \                   |
   |    PCP      |----+                          -------------------.
   |   Client    |
   +-------------+ 

]]></artwork>
          </figure></t>

        <t>PCP client can be configured with their PCP server using DHCP for
        instance <xref target="I-D.ietf-pcp-dhcp"></xref>. If no PCP server is
        configured, PCP clients assume their default gateway is the PCP
        server.</t>

        <t>This model applies for both residential or corporate markets.</t>
      </section>

      <section title="Single Homed CPE Model: Multiple PCP Servers">
        <t>This model assumes a customer site is connected to the same ISP's
        network. One or multiple PCP servers are deployed in the ISP's domain;
        each of them manage distinct set of functions. In the example shown in
        the following figure:<list style="symbols">
            <t>NAT64 device <xref target="RFC6146"></xref> are used to
            interwork with IPv4-only devices.</t>

            <t>NPTv6 function <xref target="RFC6296"></xref> is used for
            engineering motivation internal to the ISP.</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[
   +-------------+
   |    PCP      |
   |   Client    |----+                            ,-----------.
   +-------------+    |   +------------+         ,'    ISP     `--.
                      +---|    CPE     |         /                :
                          |            |________;    NAT64        |
                      +---|            |        :                 |
   +-------------+    |   +------------+         \        NPTv6   |
   |    PCP      |----+                           ----------------.
   |   Client    |
   +-------------+ 

]]></artwork>
          </figure></t>

        <t>The use of NAT64 and NPTv6 functions is for illustration purposes;
        other functions can be enabled in the ISP's network side.</t>

        <t>PCP clients located behind the CPE, must discover both the external
        IPv4 address and port numbers assigned by the NAT64 and the external
        IPv6 address assigned by the NPTv6. These external addresses are used
        for example in referrals to indicate to remote peers both the IPv4
        address and IPv6 address to reach an internal server deployed in an
        IPv6-only domain.</t>

        <t>The use of a PCP anycast address (<xref
        target="I-D.ietf-pcp-anycast"></xref>) is not recommended for this
        deployment case because two state entries must be created in both
        NAT64 and NPTv6. Explicit means such as <xref
        target="I-D.ietf-pcp-dhcp"></xref> must be used instead to provision
        IP addresses of available PCP servers.</t>

        <t><xref target="I-D.ietf-pcp-dhcp"></xref> may be used to provision
        the IP addresses of these PCP servers, or the CPE must embed a PCP
        proxy function that must follow <xref
        target="I-D.ietf-pcp-server-selection"></xref> to contact all PCP
        servers.</t>
      </section>

      <section title="Multi-Homed CPE Model: One Single PCP Server">
        <t>A typical example of this model is shown in the following
        figure:</t>

        <t><figure>
            <artwork><![CDATA[                     ====================
                     |    Internet       |
                     =====================
                        |              |
                        |              |
                   +----+--------+   +-+------------+
                   | ISP1        |   | ISP2         |
                   |             |   |              |
                   +----+--------+   +-+------------+  
                        |              |
                        |              |
      ..............................................................
                        |              |
                        | Port1        | Port2    Subscriber Network
                        |              |
                   +----------------------+
                   |   NAT & PCP servers  |
                   |       GW Router      |
                   +----+-----------------+
                        |
                        |
                        |
                   -----+--------------
                        |
                      +-+-----+
                      | Hosts |  (private address space)
                      +-------+

]]></artwork>
          </figure></t>

        <t>Internal PCP clients can interact with one single PCP server.</t>
      </section>

      <section title="Multi-Homed CPE Model: Multiple PCP Servers">
        <t>A typical example of this model is shown in the following
        figure:</t>

        <t><figure>
            <artwork><![CDATA[                       ==================
                       |    Internet    |
                       ==================
                          |          |
                          |          |
                     +----+-+      +-+----+
                     | ISP1 |      | ISP2 |
                     +----+-+      +-+----+       
                          |          |
    .........................................................
                          |          |
                          |          |        Subscriber Network
                  +-------+---+ +----+------+
                  | rtr1 with | | rtr2 with |
                  |   FW1     | |    FW2    |
                  +-------+---+ +----+------+
                          |          |
                          |          |
                          |          |
                   -------+----------+------
                          |
                        +-+-----+
                        | Hosts |
                        +-------+]]></artwork>
          </figure></t>

        <t>The PCP client must interact with all PCP servers; otherwise
        complications arise to communicate with remote peers. The procedure
        defined in <xref target="I-D.ietf-pcp-server-selection"></xref> is
        used to contact those servers.</t>

        <t>The use of anycast-based model (<xref
        target="I-D.ietf-pcp-anycast"></xref>) might induce failures when
        communicating with external peers (e.g., incoming packets will be
        dropped by one of the firewalls).</t>
      </section>

      <section anchor="proxy" title="PCP Proxy Model">
        <t>This model assumes no PCP-controlled function is located in the CPE
        (e.g., DS-Lite case). The upstream PCP server is located in the ISP's
        network. The PCP server can be deduced from other provisioning
        parameters (e.g., use the IP address of the AFTR as PCP server);
        otherwise the IP address (s) must be discovered by other means.</t>

        <t>The use of an anycast-based model may not be convenient in some
        cases (e.g., multiple PCP-controlled devices are deployed; each of
        them manage a subset of services and state).</t>

        <t><figure>
            <artwork><![CDATA[
   +-------------+
   |   Host      |
   |             |----+                         ,-----------.
   +-------------+    |   +------------+      ,'             `--.
                      +---|    CPE     |      /     ISP           :
                          | PCP proxy  |_____;    PCP server 1    |
                      +---| PCP client |     :    PCP server i    |
   +-------------+    |   +------------+      \                   |
   |    PCP      |----+                        -------------------.
   |   Client    |
   +-------------+ 

]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section anchor="iwf" title="UPnP IGD-PCP Interworking Model">
        <t>This model is specified in <xref target="RFC6970"></xref>. The
        interworking function must be provisioned with the IP address(es) of
        remote PCP server(s).</t>

        <t><figure>
            <artwork><![CDATA[(a) 
   +-------------+
   | IGD Control |
   |   Point     |----+
   +-------------+    |   +-----+  +--------+               +------+
                      +---| IGD-|  |Provider|               |Remote|
                          | PCP |--|  NAT   |--<Internet>---| Host |
                      +---| IWF |  |        |               |      |
   +-------------+    |   +-----+  +--------+               +------+
   | Local Host  |----+
   +-------------+
                        LAN Side  External Side
   <======UPnP IGD==============><=====PCP=====>

(b) 
   +-------------+
   | IGD Control |
   |   Point     |----+
   +-------------+    |   +-----+  +--------+               +------+
                      +---| IGD-|  |Provider|               |Remote|
                          | PCP |--|  NAT   |--<Internet>---| Host |
                      +---| IWF |  |        |               |      |
   +-------------+    |   +-----+  +--------+               +------+
   | Local Host  |----+    NAT1           NAT2
   +-------------+

]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section title="HTTP-based User Interface">
        <t>This deployment model relies on the following:<list style="symbols">
            <t>An HTTP administration based interface (e.g. GUI) is provided
            to the user to manage its flow-based forwarding rules. This
            interface is part of the CPE management interface.</t>

            <t>The CPE embeds a PCP client.</t>

            <t>HTTP requests are translated into appropriate PCP requests in
            order to install the requested state.</t>

            <t>The PCP client uses THIRD_PARTY option.</t>

            <t>The PCP client should be configured with the PCP server that
            controls the on-path PCP-controlled device for that user.</t>

            <t>One or multiple PCP servers can be deployed. The logic of
            contacting these PCP servers may be explicitly configured to the
            PCP client. If not, the procedure defined in <xref
            target="I-D.ietf-pcp-server-selection"></xref> is used to contact
            those PCP servers.</t>

            <t>The use of a well-known address (<xref
            target="I-D.ietf-pcp-anycast"></xref>) to reach internal PCP
            servers might not be convenient if all PCP servers do not manage
            the same set of mapping entries (e.g., NAT64, NPTv6, IPv6
            firewall, etc.).</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[
   +-------------+
   |   Host 1    |----+                         ,-----------.
   +-------------+    |   +------------+      ,'             `--.
                      +---|    CPE     |      /     ISP           :
                          | HTTP Server|_____;                    |
                      +---| PCP client |     :    PCP server i    |
   +-------------+    |   +------------+      \                   |
   |   Host 2    |----+                        -------------------.
   +-------------+ 

]]></artwork>
          </figure></t>

        <t>This model can co-exist with the models discussed in <xref
        target="proxy"></xref> and <xref target="iwf"></xref>.</t>
      </section>

      <section title="Cascaded PCP-controlled Nodes Model">
        <t>This model assumes cascaded PCP-controlled devices are deployed. A
        typical example is provided below.</t>

        <t><figure>
            <artwork><![CDATA[                                                      ,-----------.
                               PCP server           ,'             `--.
   +-------+    +------+      +----------+         /                   :
   |PCP    |____|Home  |______|ISP CPE   |________;     Public         |
   |Client |    |Router|      |NAT Router|        :     Internet       |
   +-------+    +------+      +----------+         \                   |
                                                    \                  ;
                                                     `------.       ,-'
                                                             `-----'
                                                      ,-----------.
                              PCP server            ,'             `--.
   +-------+    +------+      +-------+            /                   :
   |PCP    |____|CPE   |______|CGN/FW |___________;     Public         |
   |Client |    |      |      |       |           :     Internet       |
   +-------+    +------+      +-------+            \                   |
                                                    \                  ;
                                                     `------.       ,-'
                                                             `-----'
                                                      ,-----------.
               PCP proxy               PCP server   ,'             `--.
   +-------+    +------+               +-------+   /                   :
   |PCP    |____|CPE   |_______________|CGN/FW |__;     Public         |
   |Client |    |      |               |       |  :     Internet       |
   +-------+    +------+               +-------+   \                   |
                                                    \                  ;
                                                     `------.       ,-'
                                                             `-----'
                                                      ,-----------.
               PCP server              PCP server   ,'             `--.
   +-------+    +------+               +-------+   /                   :
   |PCP    |____|CPE   |_______________|CGN/FW |__;     Public         |
   |Client |    |      |               |       |  :     Internet       |
   +-------+    +------+               +-------+   \                   |
                                                    \                  ;
                                                     `------.       ,-'
                                                             `-----'
]]></artwork>
          </figure>This model requires a PCP proxy function <xref
        target="I-D.ietf-pcp-proxy"></xref> be deployed in intermediate
        PCP-controlled devices:<list style="symbols">
            <t>The PCP client is not aware of the presence of more than one
            level of PCP servers.</t>

            <t>Each intermediate PCP proxy must contact the appropriate next
            hop PCP server(s).</t>

            <t>The use of PCP anaycast address may not be appropriate when the
            PCP server is co-located with the PCP-controlled device.</t>
          </list></t>
      </section>
    </section>

    <section title="Hide PCP Servers Model">
      <t></t>

      <section title="PCP Proxy Model">
        <t>In order to hide PCP servers deployed within an administrative
        domain, an administrative entity may decide to deploy one or more PCP
        proxies <xref target="I-D.ietf-pcp-proxy"></xref> in front of PCP
        clients. A PCP proxy is responsible for relaying PCP requests to the
        appropriate PCP server(s):<list style="symbols">
            <t>In order to prevent single failure scenarios, multiple PCP
            proxies can be hosted within an administrative domain.</t>

            <t>A PCP proxy can be configured with one or multiple PCP
            servers.</t>

            <t>A PCP proxy can be configured with the logic indicating how it
            should proceed to contact upstream PCP servers. The PCP proxy will
            then follow the procedure defined in <xref
            target="I-D.ietf-pcp-server-selection"></xref> to contact those
            PCP servers.</t>

            <t>Internal PCP clients may be configured with the IP address(es)
            of the appropriate PCP proxy (e.g., <xref
            target="I-D.ietf-pcp-dhcp"></xref>).<list style="symbols">
                <t>If all PCP proxies interact with the same PCP server(s),
                the same IP address can be provisioned to PCP clients.</t>

                <t>If PCP proxies do not interact with the same set of PCP
                server(s), appropriate IP address(es) are to be returned to
                each requesting PCP client.</t>
              </list></t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[               +------------------------------------+
               | Administrative Domain              |
+----------+   |    +-------------------+           |
|PCP client|---|----|    PCP proxy      |           |
+----------+   |    +-------------------+           |
               |        |            |              |
               |        |            |              |
               | +------+------+   +-+------------+ |
               | | PCP server  |   | PCP server   | | 
               | +-------------+   +--------------+ |  
               +------------------------------------+
]]></artwork>
          </figure></t>

        <t>The PCP proxy should not use the PCP anycast address (<xref
        target="I-D.ietf-pcp-anycast"></xref>) if available PCP servers do not
        manage the same PCP-controlled device. Deterministic means should be
        used instead.</t>

        <t>PCP client should not use the PCP anycast address to reach a PCP
        proxy if deployed PCP proxies do not interact with the same PCP
        servers. Explicit provisioning means should be preferred.</t>

        <t>If the PCP proxy is reachable using the PCP anycast address,
        available PCP servers must not be reachable using the same PCP anycast
        address.</t>
      </section>

      <section title="HTTP-Triggered PCP Client Model">
        <t>Another deployment model to hide the identity of back-end PCP
        servers is to rely on HTTP to invoke the PCP service. This model can
        be used by operators to accommodate cases where a PCP client
        implementation is not available at the customer side (e.g., unmanaged
        CPE model).</t>

        <t>The deployment model relies on the following:<list style="symbols">
            <t>An HTTP administration based interface (e.g. GUI) is provided
            to the user to manage its flow-based forwarding rules.</t>

            <t>The HTTP user interface can be part of a CPE management
            interface or be provided as part of the customer care portal.</t>

            <t>The HTTP server embeds also a PCP client.</t>

            <t>HTTP requests are translated into appropriate PCP requests in
            order to install the requested state.</t>

            <t>The PCP client uses THIRD_PARTY option.</t>

            <t>The PCP client should be configured with the PCP server that
            controls the on-path PCP-controlled device for that user.</t>

            <t>One or multiple PCP servers can be deployed. The logic of
            contacting these PCP servers may be explicitly configured to the
            PCP client. If not, the procedure defined in <xref
            target="I-D.ietf-pcp-server-selection"></xref> is used to contact
            those PCP servers.</t>

            <t>The use of a well-known address (<xref
            target="I-D.ietf-pcp-anycast"></xref>) to reach internal PCP
            servers might not be convenient if all PCP servers do not manage
            the same set of mapping entries (e.g., NAT64, NPTv6, IPv6
            firewall, etc.).</t>
          </list></t>

        <t><figure>
            <artwork><![CDATA[               +------------------------------------+
               | Administrative Domain              |
+----------+   |    +----------------------+        |
|  Host    |---|----|HTTP Server+PCP client|        |
+----------+   |    +----------------------+        |
               |        |            |              |
               |        |            |              |
               | +------+------+   +-+------------+ |
               | | PCP server  |   | PCP server   | | 
               | +-------------+   +--------------+ |  
               +------------------------------------+
]]></artwork>
          </figure></t>

        <t></t>
      </section>
    </section>

    <section title="Separated PCP Server &amp; PCP-controlled Device Model">
      <t>This model assumes the PCP server is not co-located with the
      PCP-controlled device. Moreover:</t>

      <t><list style="symbols">
          <t>In order to prevent single failure scenarios, multiple PCP
          servers can be hosted within an administrative domain.</t>

          <t>A PCP server can control one or many PCP-controlled devices.</t>

          <t>Multiple PCP servers can be enabled; each of them manages a set
          of PCP-controlled devices.</t>

          <t>Internal PCP clients are configured with the IP address(es) of
          the appropriate PCP server.<list style="symbols">
              <t>If all PCP servers interact with the same PCP-controlled
              devices, the same PCP server's IP address can be provisioned to
              PCP clients.</t>

              <t>If PCP servers do not interact with the same set of
              PCP-controlled devices, PCP server IP address(es) are to be
              returned to each requesting PCP client.</t>
            </list></t>
        </list>Note, PCP is not used between the PCP server and the
      PCP-controlled device. Other protocols (e.g., H.248) can be used for
      that purpose.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>PCP-related security considerations are discussed in <xref
      target="RFC6887"></xref>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>
  </middle>

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

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

    <references title="Informative References">
      <?rfc include='reference.RFC.6970'?>

      <?rfc include='reference.I-D.ietf-pcp-proxy'?>

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

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

      <?rfc include='reference.I-D.ietf-pcp-anycast'?>

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc include='reference.I-D.ietf-pcp-server-selection'?>
    </references>
  </back>
</rfc>
