PCP Deployment ModelsFrance TelecomRennes35000Francemohamed.boucadair@orange.comPCP Working GroupThis document lists a set of PCP deployment models.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 RFC 2119.This document lists a set of PCP
deployment models. This document makes use of the following terms: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 .PCP client denotes a PCP software instance responsible for
issuing PCP requests to a PCP server. Refer to .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. 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 example shown in the
following figure:NAT64 device are used to interwork with IPv4-only devices.NPTv6 function is used for engineering motivation internal to the
ISP.Internal PCP client 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.The use of anycast-based addressing model is not recommended for this
deployment case because two state entries are to be created in both
NAT64 and NPTv6.The use of NAT64 and NPTv6 is for illustration purposes; other
functions can be enabled.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 that are responsible for relaying PCP requests to
appropriate PCP servers:In order to prevent single failure scenarios, multiple PCP
proxies can be hosted within an administrative domain.A PCP Proxy can be configured with one or multiple servers.Multiple PCP Proxies can be enabled; each of them manages a set
of PCP servers.A PCP Proxy can be configured with the logic indicating how it
should proceed to contact upstream PCP servers.Internal PCP clients are configured with the IP address(es) of
the appropriate PCP proxy.If all PCP Proxies interact with the same PCP Server(s),
the same IP address can be provisioned to PCP clients.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.Another deployment model to hide deployed PCP servers is to relay
on HTTP to interact with the PCP service. This model can also be used
by operators to accommodate cases where the PCP client is not
available at the customer side. The deployment model relies on the following:An HTTP administration based interface is provided to the user
to create flow-bases forwarding rules.The HTTP GUI can be part of a CPE management interface or be
provided as part of the customer care portal.HTTP requests are translated into appropriate PCP servers in
order to install the requested state. The HTTP server embeds also
a PCP client.The PCP client uses THIRD_PARTY option.The PCP Client should be configured with PCP server that
controls the on-path PCP-controlled device for that user.One or multiple PCP Servers can be deployed.The use of a well-known address to reach internal PCP servers
may not be convenient if all PCP server do not manage the same set
of states.This model assumes the PCP server is not co-located with the
PCP-controlled device. Moreover:In order to prevent single failure scenarios, multiple PCP
servers can be hosted within an administrative domain.A PCP server can be control one or many PCP-controlled
devices.Multiple PCP servers can be enabled; each of them manages a set
of PCP-controlled devices.Internal PCP clients are configured with the IP address(es) of
the appropriate PCP server.If all PCP servers interact with the same PCP-controlled
devices., the same IP address can be provisioned to PCP
clients.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.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.This model assumes cascaded PCP-controlled devices are deployed. A
typical example is provided below.This model requires a PCP Proxy function be deployed in intermediate
PCP-controlled devices:The PCP client is not aware of the presence of more than one
level of PCP servers.Each intermediate PCP proxy must contact the appropriate next hop
PCP server.Because of the statefull nature of PCP, anycast-based addressing
model may not be appropriate when the PCP Server is co-located with
the PCP-controlled device.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.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).This model is specified in . The
interworking function must be provisioned with the IP address(es) of
remote PCP server(s).A typical example of this model is shown in the following figure:Internal PCP clients can interact with one single PCP servers.A typical example of this model is shown in the following figure:The PCP client must interact with all PCP servers; otherwise
complications arise to communicate with remote peers. The use of
anycast-based model will induce failures in communicating with external
peers (e.g., incoming packets will be dropped by one of the
firewalls).PCP-related security considerations are discussed in .This document does not require any action from IANA.TBC.