One document matched: draft-ietf-pcp-optimize-keepalives-04.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-ietf-pcp-optimize-keepalives-04"
ipr="trust200902">
<front>
<title abbrev="Optimizing Keepalives with PCP">Optimizing NAT and Firewall
Keepalives Using Port Control Protocol (PCP)</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Markus Isomaki" initials="M." surname="Isomaki">
<organization>Nokia</organization>
<address>
<postal>
<street>Keilalahdentie 2-4</street>
<city>FI-02150 Espoo</city>
<country>Finland</country>
</postal>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc</organization>
<address>
<postal>
<street/>
<street/>
<city>Bangalore</city>
<region/>
<code/>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<date/>
<workgroup>PCP</workgroup>
<abstract>
<t>This document describes how Port Control Protocol is useful in
reducing NAT and firewall keepalive messages for a variety of
applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many types of applications need to keep their Network Address
Translator (NAT) and Firewall (FW) mappings alive for long periods of
time, even when they are otherwise not sending or receiving any traffic.
This is typically done by sending periodic keep-alive messages just to
prevent the mappings from expiring. As NAT/FW mapping timers may be
short and unknown to the endpoint, the frequency of these keepalives may
be high. An IPv4 or IPv6 host can use the Port Control Protocol
(PCP)<xref target="RFC6887"/> to flexibly manage the IP address and port
mapping information on NATs and FWs to facilitate communications with
remote hosts. This document describes how PCP can be used to reduce
keepalive messages for both client-server and peer-to-peer type of
communication.</t>
<t>The mechanism described in this document is especially useful in
cellular mobile networks, where frequent keepalive messages make the
radio transition between active and power-save states causing congestion
in the signaling path. The excessive time spent on the active state due
to keepalives also greatly reduces the battery life of the cellular
connected devices such as smartphones or tablets. According to
requirement #14 in <xref
target="I-D.binet-v6ops-cellular-host-reqs-rfc3316update"/> a cellular
host SHOULD support PCP in order to save battery consumption exacerbated
by keepalive messages.</t>
</section>
<section anchor="notation" title="Notational Conventions">
<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"/>.</t>
<t>This note uses terminology defined in <xref target="RFC5245"/> and
<xref target="RFC6887"/>.</t>
</section>
<section title="Overview of Operation">
<section title="Application Scenarios">
<t>PCP can help both client-server and peer-to-peer applications to
reduce their keepalive rate. The relevant applications are the ones
that need to keep their NAT/FW mappings alive for long periods of
time, for instance to be able to send or receive application messages
in both directions at any time.</t>
<t>A typical client-server scenario is depicted in <xref
target="figure1"/>. A client, who may reside behind one or multiple
layers of NATs/FWs, opens a connection to a globally reachable server,
and keeps it open to be able to receive messages from the server at
any time. The connection may be a connection-oriented transport
protocol such as TCP or SCTP or connection-less transport protocol
such as UDP. Protocols operating in this manner include Session
Initiation Protocol (SIP) <xref target="RFC3261"/>, Extensible
Messaging and Presence Protocol (XMPP) <xref target="RFC3921"/>,
Internet Mail Application Protocol (IMAP) <xref target="RFC2177"/>
with its IDLE command, the WebSocket protocol <xref target="RFC6455"/>
and the various HTTP long-polling protocols. There are also a number
of proprietary instant messaging, Voice over IP, e-mail and
notification delivery protocols that belong in this category. All of
these protocols aim to keep the client-server connection alive for as
long as the application is running. When the application has otherwise
no traffic to send, specific keepalive messages are sent periodically
to ensure that the NAT/FW state in the middle does not expire. The
client can use PCP to keep the required mapping at the NAT/FW and use
application keepalives to keep the state on the Application
Server/Peer as mentioned in <xref target="optimize"/>.</t>
<t><figure anchor="figure1"
title="PCP with Client-Server applications">
<artwork><![CDATA[
PCP PCP
Client Server __________
+-----------+ +------+ / \ +-----------+
|Application|___| NAT/ |____| Internet |___|Application|
| Client | | FW | | | | Server |
+-----------+ +------+ \__________/ +-----------+
(multiple
layers)
------------> PCP
----------------------------------------->
Application keepalive
]]></artwork>
</figure></t>
<t>There are also scenarios where the long-term communication
association is between two peers, both of whom may reside behind one
or more layers of NAT/FW. This is depicted in <xref
target="figure2"/>. The initiation of the association may have
happened using mechanisms such as Interactive Communications
Establishment (ICE), perhaps first triggered by a "signaling" protocol
such as SIP or XMPP or WebRTC <xref
target="I-D.ietf-rtcweb-overview"/>. Examples of the peer-to-peer
protocols include RTP and WebRTC data channel. A number of proprietary
VoIP or video call or streaming or file transfer protocols also exist
in this category. Typically the communication is based on UDP, but TCP
or SCTP may be used. If there is no traffic flowing, the peers have to
inject periodic keepalive packets to keep the NAT/FW mappings on both
sides of the communication active. Instead of application keepalives,
both peers can use PCP to control the mappings on the NAT/FWs to
reduce the keepalive frequency as explained in <xref
target="optimize"/>.</t>
<t><figure anchor="figure2" title="PCP with Peer-to-Peer applications">
<artwork><![CDATA[
PCP PCP PCP PCP
Client Server __________ Server Client
+-----------+ +------+ / \ +------+ +-----------+
|Application|___| NAT/ |____| Internet |___| NAT/ |___|Application|
| Peer | | FW | | | | FW | | Peer |
+-----------+ +------+ \__________/ +------+ +-----------+
(multiple (multiple
layers) layers)
------------> PCP PCP <------------
<--------------------------------------------------->
Application keepalive
]]></artwork>
</figure></t>
</section>
<section title="NAT Topologies and Detection">
<t>Before an application can reduce its keepalive rate, it has to make
sure it has all of the NATs and firewalls on its path under control.
This means it has to detect the presence of any PCP-unaware NATs and
firewalls on its path to the Internet.</t>
<section anchor="PCPb" title="PCP based detection">
<t>PCP itself is able to detect unexpected NATs between the PCP
client and PCP server as depicted in <xref target="figure3"/>. The
PCP client includes its own IP address and UDP port within the PCP
request. The PCP server compares them to the source IP address and
UDP port it sees on the packet. If they differ, there are one or
more additional NATs between the PCP client and PCP server, and the
server will return an error. Unless the application has some other
means (like UPnP) to control these PCP unaware NATs, it has to fall
back to its default keepalive mechanism.</t>
<t><figure anchor="figure3"
title="PCP unaware NAT between PCP client and PCP server">
<artwork><![CDATA[
PCP PCP PCP
Client Unaware Aware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT |___| NAT/ |____| Internet |___|Application|
| Client | | | | FW | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<-----------///---------->
PCP based detection
]]></artwork>
</figure></t>
</section>
<section anchor="App" title="Application based detection">
<t><xref target="figure4"/> shows a topology where one or more PCP
unaware NATs are deployed on the exterior of the PCP capable
NAT/FWs. To detect this, the application client must have the
capability to request from its application server or peer what IP
and transport address it sees. If those differ from the IP and
transport address given by the PCP aware NAT/FW then the application
client can determine that there is at least one PCP unaware NAT on
the path. In this case, the application client has to fall back to
its default keepalive mechanism.</t>
<t><figure anchor="figure4"
title="PCP unaware NAT external to the last PCP aware NAT">
<artwork><![CDATA[
PCP PCP PCP
Client Aware Unaware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT/ |___| NAT |____| Internet |___|Application|
| Client | | FW | | | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<------------>
PCP
<---------------------///--------------------------->
Application based detection
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="Detect" title="Detection of PCP unaware firewalls">
<t>PCP and application based detection mechanisms explained in <xref
target="PCPb"/> and <xref target="App"/> are based on change in the
address and will not detect PCP unaware firewalls. In order to detect
a PCP unaware firewall, the application client sends a STUN <xref
target="RFC5389"/> Binding request to the STUN server. If STUN server
supports the STUN extensions defined in <xref target="RFC5780"/> then
it returns its alternate IP address and alternate port in
OTHER-ADDRESS attribute in the STUN Binding response. The client then
uses PCP to send MAP request with FILTER option to PCP server to
permit STUN server to reach the client using the STUN servers
alternate IP address and alternate port. The client then sends a
Binding request to the primary address of the STUN server with the
CHANGE-REQUEST attribute set to change-port and change-IP. This will
cause the server to send its response from its alternate IP address
and alternate port. If the client receives a response then the client
is aware that on path firewall devices are PCP aware. If the client
does not receive a response then the client is aware that there could
be one or more on path PCP unaware firewall devices. Application
client will perform the tests separately for each transport protocol.
If no response is received, the client will then repeat the test at
most three times for connectionless transport protocols.</t>
<t><figure anchor="figure5" title="PCP unaware firewall">
<artwork><![CDATA[
PCP PCP PCP
Client Aware Unaware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT/ |___| FW |____| Internet |___| STUN |
| Client | | FW | | | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<--------------------------------------------------->
STUN
<------------>
PCP
X<---------------------------
STUN based detection
]]></artwork>
</figure></t>
<t>This procedure can be adopted by other protocols to detect PCP
unaware firewalls.</t>
</section>
<section anchor="optimize" title="Keepalive Optimization">
<t>If the application determines that all NATs and firewalls on its
path to the Internet support PCP, it can start using PCP instead of
its default keepalives to maintain the NAT/FW state. It can use PCP
PEER Request with the Requested Lifetime set to an appropriate value.
The application may still send some application-specific heartbeat
messages end-to-end.</t>
<t>Processing the lifetime value of the PEER Opcode is described in
Sections 10.3 and 15 of <xref target="RFC6887"/>. Sending a PEER
request with a very short Requested Lifetime can be used to query the
lifetime of an existing mapping. PCP recommends that lifetimes of
mapping created or lengthened with PEER be longer than the lifetimes
of implicitly-created NAT and firewall mappings. Thus PCP can be used
to reduce power consumption by making PCP PEER message interval longer
than what the application would normally use to the keep the middle
box state alive, and strictly shorter than the server state refresh
interval.</t>
<t>An example of savings with PCP is described in <xref
target="savings"/>.</t>
</section>
</section>
<section anchor="heuristics"
title="Keepalive Interval Determination Procedure when PCP unaware Firewall or NAT is detected ">
<t>If PCP unaware NAT/firewall is detected then a client can use the
following heuristics method to determine the keepalive interval:</t>
<t><list style="numbers">
<t>The client sends a STUN Binding request to the STUN server. This
connection is called the Primary Channel. STUN server will return
its alternate IP address and alternate port in OTHER-ADDRESS in the
Binding response <xref target="RFC5780"/>.</t>
<t>The client then sends STUN Binding request to the STUN server
using alternate IP address and alternate port. This connection is
called the Secondary Channel.</t>
<t>The Client will initially set the default keepalive interval for
NAT/FW mappings to 60 seconds (FWa).</t>
<t>After FWa seconds the Client will send a Binding request to the
STUN server using the Primary Channel with the CHANGE-REQUEST
attribute set to change-port and change-IP. This will cause the STUN
server to send its response from the Secondary channel.</t>
<t>If the client receives response from the server then it will
increase the keepalive interval value FWa = (old FWa) + (old FWa)/2.
This indicates that NAT/FW mappings are alive.</t>
<t>Steps 4 and 5 will be repeated until there is no response from
the STUN server. If there is no response from the STUN server then
the client will use the old FWa value as Keepalive interval to
refresh FW/NAT mappings.</t>
</list></t>
<t>The above procedure will be done separately for each transport
protocol. For connectionless transport protocols like UDP if timer of 2
seconds elapses without response from the STUN server then the client
will repeat step 4 at most three times to handle packet loss.</t>
<t>This procedure can be adopted by other protocols to use Primary and
Secondary channels, so that the client can determine the keepalive
interval to refresh FW/NAT mapping. This procedure only serves as a
guideline and if applications already use some other heuristics method
to determine keepalive, they can continue with the existing logic. For
example Teredo determines Refresh interval using the procedure in
"Optional Refresh Interval Determination Procedure" (Section 5.2.7 of
<xref target="RFC4380"/>).</t>
<t>Note: The keepalive interval learnt using the above described
heuristics method can be inaccurate if a firewall is configured with
application specific inactivity timeout.</t>
<t>To improve reliability, applications SHOULD continue to use PCP to
lengthen the FW/NAT mappings even if the above described mechanism is
used to detect PCP unaware NAT/firewall. This ensures that PCP aware
FW/NAT do not close old mappings with no packet exchange when there is a
resource-crunch situation.</t>
</section>
<section anchor="apps" title="Application-Specific Operation">
<t>This section describes how PCP is used with specific application
protocols.</t>
<section title="SIP">
<t>For connection-less transports the User Agent (UA) sends a STUN
Binding request over the SIP flow as described in section 4.4.2 of
<xref target="RFC5626"/>. The UA then learns the External IP Address
and Port using a PEER request/response. If the XOR-MAPPED-ADDRESS in
the STUN Binding response matches the external address and port
provided by PCP PEER response then the UA optimizes the keepalive
traffic as described in <xref target="optimize"/>. There is no further
need to send STUN Binding requests over the SIP flow to keep the NAT
Binding alive.</t>
<t>If the XOR-MAPPED-ADDRESS in the STUN Binding response does not
match the external address and port provided by the PCP PEER response
then PCP will not be used to keep the NAT bindings alive for the flow
that is being used for the SIP traffic. This means that multiple
layers of NAT are involved and intermediate NATs are not PCP aware. In
this case the UA will continue to use the technique in section 4.4.2
of <xref target="RFC5626"/>.</t>
<t>For connection-oriented transports, the UA sends a STUN Binding
request multiplexed with SIP over the TCP connection. STUN multiplexed
with other data over a TCP or TLS-over-TCP connection is explained in
section 7.2.2 of <xref target="RFC5389"/>. The UA then learns the
External IP address and port using a PEER request/response. If the
XOR-MAPPED-ADDRESS in the STUN Binding response matches the external
address and port provided by PCP PEER response then the UA optimizes
the keepalive traffic as described in <xref target="optimize"/>.</t>
<t>If the XOR-MAPPED-ADDRESS in the STUN Binding response does not
match the external address and port provided by PCP PEER response then
PCP will not be used to keep the NAT bindings alive. In this case the
UA performs a keepalive check by sending a double-CRLF (the "ping")
then waits to receive a single CRLF (the "pong") using the technique
in section 4.4.1 of <xref target="RFC5626"/>.</t>
</section>
<section title="HTTP">
<t>Web Applications that require persistent connections use techniques
such as HTTP long polling and Websockets for session keep alive as
explained in section 3.1 of <xref
target="I-D.isomaki-rtcweb-mobile"/>. In such scenarios, after the
client establishes a connection with the HTTP server, it can execute
server side scripts such as PHP residing on the server to provide the
transport address and port of the HTTP client seen at the HTTP server.
In addition, the HTTP client also learns the external IP Address and
port using the PCP PEER request/response.</t>
<t>If the IP address and port learned from the server matches the
external address and port provided by PCP PEER response then the HTTP
client optimizes keepalive traffic as described in <xref
target="optimize"/>.</t>
<t>If the IP address and port do not match then PCP will not be used
to keep the NAT bindings alive for the flow that is being used for the
HTTP traffic. This means that there are NATs or HTTP proxies between
the PCP server and the HTTP server. The HTTP client will have to
resort to use existing techniques for keep alive. Please see <xref
target="example"/> for an example server side PHP script to obtain the
client source IP address.</t>
<t>HTTP protocol allows intermediaries like transparent proxies to be
involved and there is no way for the client to know that
request/response is relayed through a proxy.</t>
</section>
<section title="Media and data channels with ICE">
<t>The ICE agent learns the External IP Addresses and Ports using the
MAP opcode. If server reflexive candidates learnt using STUN <xref
target="RFC5389"/> and external IP addresses learnt using PCP are
different then candidates learnt through both STUN and PCP are encoded
in the ICE offer and answer . When using the Recommended Formula
explained in section 4.1.2.1 of <xref target="RFC5245"/> to compute
priority for the candidate learnt through PCP, the ICE agent should
use a preference value greater than the server reflexive candidate and
hence tested before the server reflexive candidate. The recommended
type preference value is 105 for candidates discovered using PCP and
is explained in section 4.2 of <xref target="RFC6544"/>.</t>
<t>The ICE agent, in addition to the ICE connectivity checks, performs
the following:</t>
<t>The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN
Binding response received as part of ICE connectivity check matches
the External IP address and Port provided by PCP MAP response.</t>
<t><list style="numbers">
<t>If the match is successful then PCP will be used to keep the
NAT bindings alive. The ICE agent optimizes keepalive traffic by
refreshing the mapping via a new PCP MAP request containing
information from the earlier PCP response.</t>
<t>If the match is not successful then PCP will not be used for
keep NAT binding alive. The ICE agent will use the technique in
section 4.4 of <xref target="RFC6263"/> to keep NAT bindings
alive. This means that multiple layers of NAT are involved and
intermediate NATs are not PCP aware.</t>
</list></t>
<t>Some network operators deploying a PCP Server may allow PEER but
not MAP. In such cases the ICE agent learns the external IP address
and port using a STUN Binding request/response during ICE connectivity
checks. The ICE agent also learns the external IP Address and port
using a PCP PEER request/response. If the IP address and port learned
from the STUN Binding response matches the external address and port
provided by the PCP PEER response then the ICE agent optimizes
keepalive traffic as described in <xref target="optimize"/>.</t>
</section>
<section title="Detecting Flow Failure">
<t>Using the Rapid Recovery technique in section 14 of <xref
target="RFC6887"/> upon receiving a PCP ANNOUNCE from a PCP server, a
PCP client becomes aware that the PCP server has rebooted or lost its
mapping state. The PCP client issues new PCP requests to recreate any
lost mapping state and thus reconstructs lost mappings fast enough
that existing media, HTTP and SIP flows do not break. If the NAT state
cannot be recovered the endpoint will find the new external address
and port as part of the Rapid Recovery technique in PCP itself and
reestablish a connection with the peer.</t>
</section>
<section title="Firewalls">
<t>PCP allows applications to communicate with firewall devices with
PCP functionality to create mappings for incoming connections. In such
cases PCP can be used by the endpoint to create an explicit mapping on
firewall in order to permit inbound traffic. The endpoint can further
use PCP to send keepalives to keep the firewall mappings alive.</t>
<section title="IPv6 Network with Firewalls">
<t>For scenarios where the client uses the ICE Lite implementation
explained in section 2.7 of <xref target="RFC5245"/>, the ICE Lite
endpoint will not generate its own ICE connectivity checks, by
definition. As part of the call setup, the ICE Lite endpoint would
gather its host candidates and relayed candidate from a TURN server
and send the candidates in the offer to the peer endpoint. On
receiving the answer from the peer endpoint, the ICE Lite endpoint
sends a PCP MAP request with FILTER opcode to create a dynamic
mapping in firewall to permit ICE connectivity checks and subsequent
media traffic from the remote peer. This way, the ICE Lite endpoint
and its network are protected from unsolicited incoming UDP traffic,
and can still operate using ICE Lite (rather than full ICE).</t>
</section>
<section title="Mobile Network with Firewalls">
<t>Mobile Networks are also making use of a firewall to protect
their customers from various attacks like downloading malicious
content. The firewall is usually configured to block all unknown
inbound connections as explained in section 2.1 of <xref
target="I-D.chen-pcp-mobile-deployment"/>. As described in <xref
target="optimize"/>, in such cases PCP can be used by Mobile devices
to create an explicit mapping on the firewall to permit inbound
traffic and optimize the keepalive traffic. This would result in
saving of radio and power consumption of the Mobile device while
protecting it from attacks.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Security Considerations">
<t>The security considerations in <xref target="RFC5245"/> and <xref
target="RFC6887"/> apply to this use.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Authors would like to thank Dave Thaler, Basavaraj Patil, Anca
Zamfir, Reinaldo Penno, Suresh Kumar and Dilipan Janarthanan for
valuable inputs to the document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include='reference.RFC.6887'?>
<?rfc include="reference.RFC.6263"?>
<?rfc include="reference.RFC.5626"
?>
<?rfc include="reference.RFC.5780"?>
<?rfc include="reference.RFC.6544"?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3261"
?>
<?rfc include="reference.RFC.3921"
?>
<?rfc include="reference.RFC.2177"?>
<?rfc include='reference.I-D.chen-pcp-mobile-deployment'?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.isomaki-rtcweb-mobile'
?>
<?rfc include='reference.I-D.binet-v6ops-cellular-host-reqs-rfc3316update'?>
<?rfc include="reference.RFC.4380"
?>
<?rfc include="reference.RFC.6455"?>
<?rfc ?>
<!---->
</references>
<section anchor="example" title="Example PHP script">
<figure>
<artwork><![CDATA[<html>
Connected to <?PHP echo gethostname(); ?> on port <?PHP echo
getenv(SERVER_PORT)?> on <?PHP echo date("d-M-Y H:i:s");?>
Pacific Time
<p>
Your IP address is: <?PHP echo getenv(REMOTE_ADDR); ?>,
port <?PHP echo getenv(REMOTE_PORT); ?>
</p>;
</html>]]></artwork>
</figure>
</section>
<section anchor="savings" title="Savings with PCP">
<t>The following example illustrates the savings in keepalive messages
with PCP.</t>
<figure anchor="figure6" title="Savings with PCP">
<artwork><![CDATA[
PCP PCP
Client Server __________
+-----------+ +------+ / \ +-----------+
|Application|________| NAT/ |_______| Internet |___|Application|
| Client | | FW | | | | Server |
+-----------+ +------+ \__________/ +-----------+
With Application Heartbeat (without PCP):
<---------------------///--------------------------->
Application heartbeat (Max Interval = 120 seconds)
<---------------------///--------------------------->
Application heartbeat (Max Interval = 120 seconds)
<---------------------///--------------------------->
Application heartbeat (Max Interval = 120 seconds)
<---------------------///--------------------------->
Application heartbeat (Max Interval = 120 seconds)
....
....
....
....
With PCP:
<------------------>
PCP PEER request
(Max Lifetime = 3600 seconds)
....
....
<------------------>
PCP PEER request
(Max Lifetime = 3600 seconds)
]]></artwork>
</figure>
<t/>
<t>In the example above, let's suppose normally an application would
need to send a heartbeat every 120s to keep mappings active on the
NAT/firewall device. In 24 hours, in the absence of PCP, the number of
packets sent by the application to keep those mappings active would be
(86400/120) = 720 packets.</t>
<t>If the same application uses PCP PEER to create a mapping, with a
lifetime of 3600 seconds, on a PCP controlled NAT/firewall device, the
number of packets sent by the application to keep those mappings active
would be (86400/3600) = 24 packets.</t>
<t>With the above assumptions, using PCP saves 96.67% of keepalive
traffic. As the number of applications running on a host increase,
savings in cost of sending application heartbeats are significant with
the use of PCP.</t>
<t><figure>
<artwork><![CDATA[
PCP PCP PCP
Client Proxy/ Server
Server __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|_________| NAT/ |_________| NAT/ |__| Internet |___|Application|
| Client | | FW | | FW | | |
+-----------+ +------+ +------+ \__________/ +-----------+
<-multiple NAT/FW->
<------------------> <------------------>
PCP PEER request PCP PEER request
]]></artwork>
</figure></t>
<t>If there are multiple PCP aware NAT/firewall devices on a clients
path to the internet eg., PCP server at home CPE and also at CGN,
savings with PCP are the same. The PCP server at the home CPE is a PCP
proxy that can create associated mappings on the PCP server at CGN. The
client will only have to communicate with the PCP proxy and receives a
single mapping lifetime that needs to be refreshed.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:22:28 |