<?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-06"
     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="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>

      <address>
        <postal>
          <street></street>

          <street></street>

          <city>Bangalore</city>

          <region></region>

          <code></code>

          <country>India</country>
        </postal>

        <email>praspati@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>

    <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"></xref> to flexibly manage the IP address
      and port mapping information on NATs and Firewalls 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. <xref
      target="I-D.ietf-v6ops-mobile-device-profile"></xref> recommends
      cellular hosts to be PCP-compliant 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"></xref>.</t>

      <t>This note uses terminology defined in <xref target="RFC5245"></xref>
      and <xref target="RFC6887"></xref>.</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"></xref>. 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 the Session Initiation Protocol (SIP) <xref
        target="RFC3261"></xref>, the Extensible Messaging and Presence
        Protocol (XMPP) <xref target="RFC3921"></xref>, the Internet Mail
        Application Protocol (IMAP) <xref target="RFC2177"></xref> with its
        IDLE command, the WebSocket protocol <xref target="RFC6455"></xref>
        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 mappings at the NAT/FWs and
        use application keepalives to keep the state on the Application
        Server/Peer as mentioned in <xref target="optimize"></xref>.</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"></xref>. 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"></xref>. 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"></xref>.</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"></xref>.
          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"></xref> 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"></xref> and <xref target="App"></xref> 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
        Session Traversal Utilities for NAT (STUN) <xref
        target="RFC5389"></xref> Binding request to the STUN server. If STUN
        server supports the STUN extensions defined in <xref
        target="RFC5780"></xref> 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. The
        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 to refresh state on the application server, which
        typically requires keepalives far less frequently than NATs /FWs
        do.</t>

        <t>Processing the lifetime value of the PEER Opcode is described in
        Sections 10.3 and 15 of <xref target="RFC6887"></xref>. 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"></xref>.</t>
      </section>
    </section>

    <section anchor="heuristics"
             title="Keepalive Interval Determination Procedure when PCP unaware Firewall or NAT is detected ">
      <t>If a 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"></xref>.</t>

          <t>The client then sends a 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 such as UDP, if 2
      seconds elapse without a 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 heuristic to
      determine the keepalive interval, they can continue with the existing
      logic. For example Teredo determines the Refresh interval using the
      procedure in "Optional Refresh Interval Determination Procedure"
      (Section 5.2.7 of <xref target="RFC4380"></xref>).</t>

      <t>Note: The keepalive interval learnt using the above method can be
      inaccurate if a firewall is configured with an 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 mechanism is used to a
      detect PCP unaware NAT/firewall. This ensures that PCP aware FW/NATs do
      not close old mappings with no packet exchange when there is a
      resource-scarcity 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"></xref>. The UA then learns the External IP
        Address and Port using a PCP 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"></xref>.
        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"></xref>.</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"></xref>. The UA then learns
        the External IP address and port using a PCP PEER request/response. If
        the XOR-MAPPED-ADDRESS in the STUN Binding response matches the
        external address and port provided by the PCP PEER response, then the
        UA optimizes the keepalive traffic as described in <xref
        target="optimize"></xref>.</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. 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"></xref>.</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"></xref>. 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 a PCP PEER request/response.</t>

        <t>If the IP address and port learned from the server matches the
        external address and port provided by the PCP PEER response then the
        HTTP client optimizes keepalive traffic as described in <xref
        target="optimize"></xref>.</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"></xref> for an example server side PHP script to
        obtain the client source IP address.</t>

        <t>The HTTP protocol allows intermediaries such as transparent proxies
        to be involved and there is no way for the client to know that a
        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
        PCP MAP opcode. If server reflexive candidates learnt using STUN <xref
        target="RFC5389"></xref> 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"></xref>
        to compute priority for the candidate learnt through PCP, the ICE
        agent MUST 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"></xref>.</t>

        <t>The ICE agent, in addition to the ICE connectivity checks, performs
        the following:</t>

        <t><list style="numbers">
            <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>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"></xref> 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"></xref>.</t>
      </section>

      <section title="Detecting Flow Failure">
        <t>Using the Rapid Recovery technique in section 14 of <xref
        target="RFC6887"></xref> 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"></xref>, 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 the 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>Some 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"></xref>. As described in
          <xref target="optimize"></xref>, 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>This document has no actions for IANA.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations in <xref target="RFC5245"></xref> and
      <xref target="RFC6887"></xref> 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, Dilipan Janarthanan and Mohamed
      Boucadair for their valuable inputs.</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' ietf-v6ops-mobile-device-profile
?>

      <?rfc include='reference.I-D.ietf-v6ops-mobile-device-profile'?>

      <?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 = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
      <---------------------///---------------------------> 
        Application heartbeat (Max Interval = 30 seconds)
             ....
             ....
             ....
             ....

With PCP:
      <------------------>
        PCP PEER request 
     (Max Lifetime = 3600 seconds)
             ....
             ....              
      <------------------>
        PCP PEER request 
     (Max Lifetime = 3600 seconds)
    ]]></artwork>
      </figure>

      <t></t>

      <t>In the example above, let's suppose normally an application would
      need to send a heartbeat every 30s 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/30) = 2880 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 99.16% 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 client's
      path to the internet, e.g., PCP servers at a home gateway and also at a
      CGN, the savings with PCP are the same. The PCP server at the home
      gateway is a PCP proxy that can create associated mappings on the PCP
      server at the 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>
