One document matched: draft-boucadair-pcp-deployment-cases-01.xml
<?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-01"
ipr="trust200902">
<front>
<title abbrev="PCP Deployment Cases">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="02" month="December" year="2013" />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>This document lists a set of PCP deployment models.</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>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 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 client denotes a PCP software instance responsible for
issuing PCP requests to a PCP server. Refer to <xref
target="RFC6887"></xref>.</t>
</list><?rfc subcompact="no" ?></t>
</section>
<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. </t>
<t><figure>
<artwork><![CDATA[
+-------------+
| PCP |
| Client |----+ ,-----------.
+-------------+ | +------------+ ,' `--.
+---| CPE | / :
| PCP server |_______; ISP |
+---| NAT+FW+.. | : |
+-------------+ | +------------+ \ |
| PCP |----+ -------------------.
| Client |
+-------------+
]]></artwork>
</figure></t>
<t></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 are used to interwork with IPv4-only devices.</t>
<t>NPTv6 function 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 is for illustration purposes; other
functions can be enabled.</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>
<t></t>
</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 in front of PCP
clients PCP Proxies <xref target="I-D.ietf-pcp-proxy"></xref> that are
responsible for relaying PCP requests to the appropriate PCP
servers:<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>Multiple PCP Proxies can be enabled; each of them manages a set
of 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
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 use of anycast address (<xref
target="I-D.ietf-pcp-anycast"></xref>) is not convenient in this model
if available PCP servers do not manage the same set of state entries.
Deterministic means should be used instead.</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 relay on HTTP to invoke the PCP service. This model can
also 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 is provided to the user
to create flow-bases forwarding rules.</t>
<t>The HTTP GUI can be part of a CPE management interface or be
provided as part of the customer care portal.</t>
<t>HTTP requests are translated into appropriate PCP requests in
order to install the requested state. The HTTP server embeds also
a PCP client.</t>
<t>The PCP client uses THIRD_PARTY option.</t>
<t>The PCP client should be configured with 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 also be explicitly configured.
The procedure defined in <xref
target="I-D.ietf-pcp-server-selection"></xref> is used to contact
those servers. </t>
<t>The use of a well-known address (<xref
target="I-D.ietf-pcp-anycast"></xref>) to reach internal PCP
servers is not be convenient if all PCP server do not manage the
same set of state 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 & 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 IP address can be provisioned to PCP
clients.</t>
<t>If PCP servers do not interact with the same set of
PCP-controlled devices, appropriate IP address(es) are to be
returned to each requesting PCP client.</t>
</list></t>
</list>Note, PCP is not used as interface between the PCP server and
the PCP-controlled device. Other protocols (e.g., H.248) can be used for
that purpose.</t>
<t></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.</t>
<t>Because of the statefull nature of PCP, 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 title="Single Homed CPE Model: PCP Proxy Model">
<t>This model assumes no PCP-controlled function is located in the CPE
(e.g., DS-Lite case). The ultimate PCP server is located in ISP side.
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 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>
<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>) will induce failures in
communicating with external peers (e.g., incoming packets will be
dropped by one of the firewalls).</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>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBC.</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.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>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:45 |