PPSP Working Group                                                 L. Li
Internet-Draft                                                   J. Wang
Intended status: Standards Track                         ZTE Corporation
Expires: January 11, 2012                                        W. Chen
                                                            China Mobile
                                                           July 10, 2011


                           PPSP NAT Traversal
                     draft-li-ppsp-nat-traversal-02

Abstract

   This document discusses the necessity and solutions of PPSP NAT
   traversal.  Two NAT traversal solutions based are described in this
   document: PPSP-ICE and RELOAD-ICE solution.  PPSP-ICE and RELOAD-ICE
   solutions both use ICE.  PPSP-ICE solution uses PPSP messages to
   convey ICE parameters, while RELOAD-ICE solution proposes to form a
   RELOAD overlay with PPSP peers and use RELOAD messages to exchange
   ICE parameters.  Extensions to PPSP are also proposed to support
   these solutions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 11, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Li, et al.              Expires January 11, 2012                [Page 1]


Internet-Draft             PPSP NAT traversal                  July 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  The Necessity of NAT Traversal . . . . . . . . . . . . . . . .  5
   4.  NAT Traversal Solution Overview  . . . . . . . . . . . . . . .  6
     4.1.  Candidates and NAT Traversal Service . . . . . . . . . . .  6
     4.2.  NAT Traversal Service Discovery  . . . . . . . . . . . . .  7
   5.  NAT Traversal Solutions  . . . . . . . . . . . . . . . . . . .  9
     5.1.  PPSP-ICE Solution  . . . . . . . . . . . . . . . . . . . .  9
       5.1.1.  PPSP Signal Traversal  . . . . . . . . . . . . . . . .  9
       5.1.2.  PPSP Media Traversal . . . . . . . . . . . . . . . . . 12
     5.2.  RELOAD-ICE Solution  . . . . . . . . . . . . . . . . . . . 14
     5.3.  Solution Comparison  . . . . . . . . . . . . . . . . . . . 15
   6.  Decisions to Implement NAT Traversal . . . . . . . . . . . . . 17
   7.  PPSP Extension for NAT Traversal . . . . . . . . . . . . . . . 18
     7.1.  Tracker's STUN-like Function . . . . . . . . . . . . . . . 18
     7.2.  Proxy Peer . . . . . . . . . . . . . . . . . . . . . . . . 18
       7.2.1.  Relayed by Proxy . . . . . . . . . . . . . . . . . . . 18
       7.2.2.  Connecting and Disconnecting Proxy . . . . . . . . . . 18
     7.3.  STUN/TURN/proxy Ability Report and Querying
           STUN/TURN/proxy Peer List  . . . . . . . . . . . . . . . . 18
     7.4.  Carrying Candidates in PPSP Message  . . . . . . . . . . . 19
     7.5.  Exchanging ICE Parameters  . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

















Li, et al.              Expires January 11, 2012                [Page 2]


Internet-Draft             PPSP NAT traversal                  July 2011


1.  Introduction

   NAT is widely deployed in the Internet.  This document focuses on
   PPSP NAT traversal issues, and proposes extensions to
   [I-D.gu-ppsp-tracker-protocol] and [I-D.gu-ppsp-peer-protocol] to
   support NAT traversal.  It discusses the necessity and solutions of
   PPSP NAT traversal.  Two NAT traversal solutions are described in
   this document: PPSP-ICE solution and RELOAD-ICE solution.  PPSP-ICE
   and RELOAD-ICE solutions both use ICE [RFC5245].  This document also
   discusses the implementation decisions of NAT traversal.

   The major change of this version is adding the No-ICE solution and
   detailing extensions to PPSP.






































Li, et al.              Expires January 11, 2012                [Page 3]


Internet-Draft             PPSP NAT traversal                  July 2011


2.  Terminology

   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 [RFC2119].

   We use the terminology and definitions from "Problem Statement of P2P
   Streaming Protocol" [I-D.zhang-ppsp-problem-statement] and ICE
   [RFC5245] and extensively in this document.  Other terms used in this
   document are defined below.

   STUN peer.  A STUN peer is a peer functioning as a STUN [RFC5389]
   server and providing STUN services to other peers.

   Relay peer.  A relay peer is a peer providing relay service to other
   peers.  The relay service may be provided in PPSP layer or TURN layer
   or both.

   TURN peer.  A TURN peer is a relay peer providing relay service in
   TURN [RFC5766] layer.  In another word, a TURN peer is a peer
   functioning as a TURN server and providing TURN services to other
   peers.

   Proxy peer.  A proxy peer is a relay peer providing relay service in
   PPSP layer.  In another word, a proxy peer is a peer functioning as a
   proxy server and providing PPSP proxy services to other peers.
   Unlike TURN peer, proxy peer only relays PPSP messages.

   Proxy candidate.  As the defined in ICE, a candidate is a transport
   address, which is potential for communication.  A peer's proxy
   candidate is the address of a proxy peer serving for the peer.
   Through a peer's proxy candidate, the peer can be contacted.



















Li, et al.              Expires January 11, 2012                [Page 4]


Internet-Draft             PPSP NAT traversal                  July 2011


3.  The Necessity of NAT Traversal

   Without adopting NAT traversal method, the existence of NATs prevents
   some PPSP peers from connecting to some other peers.  Without NAT
   traversal, peers MAY not be able to download needed chunks, or MAY
   take long time to download needed chunks.  This probably happens when
   the ratio of NATed peer is high in a P2P streaming system or a swarm.

   When there are NATed peers, adopting NAT traversal allows peers to
   download contents from more peers, which can increase download speed,
   avoid NAT-caused download failure and high download latency.

   If there is no NAT or the QoE is satisfied without NAT traversal
   solution, there is no need to apply NAT traversal solution.

   Therefore, NAT traversal is necessary at least in some P2P streaming
   systems.  Some commercial P2P streaming systems like UUSEE are using
   NAT traversal measures.

































Li, et al.              Expires January 11, 2012                [Page 5]


Internet-Draft             PPSP NAT traversal                  July 2011


4.  NAT Traversal Solution Overview

   This document describes two NAT traversal solutions: PPSP-ICE and
   RELOAD-ICE.  These two solutions both use ICE because ICE is an IETF
   standard with following advantage.  ICE can use any combination of
   following NAT traversal methods: NAT assisting (e.g.  UPNP-IGD),
   STUN/STUN-like, TURN, connection reversal and hole punching.  To use
   ICE, ICE parameters must be conveyed by application protocol.  PPSP-
   ICE solution conveys ICE parameters with PPSP messages, while RELOAD-
   ICE solution conveys ICE parameters with RELOAD
   [I-D.ietf-p2psip-base] messages.  These two solutions require
   discovering NAT traversal service and gathering candidates.

4.1.  Candidates and NAT Traversal Service

   As the defined in ICE, a candidate is a transport address, which is
   potential for communication.  ICE defines host candidate, reflexive
   candidate, relayed candidate and NAT-assisted candidate.  This
   document defines one more candidate type called proxy candidate for
   PPSP-ICE solution.

   Among above candidates, host candidate is created by peer itself,
   NAT-assisted candidate is provided by NAT device, while other
   candidates can be obtained from nodes providing NAT traversal
   service.  The types of nodes that might provide NAT traversal
   services in PPSP are listed below.  Among below types, Proxy peer can
   only be used in PPSP-ICE solution.  Other types may be used in both
   NAT traversal solutions in document.

   o  Dedicated STUN/TURN server.  STUN/TURN servers provided by P2P
      streaming service provider or third party may be utilized for NAT
      traversal.  Dedicated servers are powerful and stable, but costly
      compared with STUN/TURN peer.

   o  STUN/TURN peer.  In a P2P system, peers may acts as STUN/TURN
      servers.  These peers are called STUN/TURN peers in this document.
      Utilizing STUN/TURN peers increase the system scalability.  Please
      note that some STUN/TURN peers can also be servers deployed
      streaming service provider.  User nodes acting as STUN/TURN peers
      make NAT traversal service highly scalable.

   o  Proxy peer.  Publicly accessible PPSP peer can act as proxy of
      NATed peer.  Proxy peer receives PPSP messages destined to NATed
      peer and forward to the NATed peer.  Compared with TURN server/
      peer, proxy peer relay only PPSP messages and uses PPSP own
      authentication method.  Please note that a proxy peer can be a
      user node or a server deployed streaming service provider.




Li, et al.              Expires January 11, 2012                [Page 6]


Internet-Draft             PPSP NAT traversal                  July 2011


   o  STUN-like tracker.  Tracker may provide STUN-like service to peers
      using PPSP protocol.  Compared with STUN, providing STUN-like
      services with PPSP protocol can reduce message number.  For
      example, tracker can discover peer's reflexive address in PPSP
      JOIN request, and return the reflexive address to peer in PPSP
      JOIN response.

   Reflexive candidate can be discovered with the help of dedicated STUN
   server, STUN peer or STUN-like tracker.  Relayed candidate can be
   obtained from dedicated TURN server or TURN peer.  Proxy candidate is
   obtained from proxy peer.

   Proxy candidate and proxy peer can only be used in PPSP-ICE solution.
   Other candidates and NAT traversal service node may be used in any
   NAT traversal solution in document.

4.2.  NAT Traversal Service Discovery

   Possible methods to discover NAT traversal services are listed below.

   o  Traditional methods including DNS, DHCP, manual configuration,
      etc.  The traditional ways are suitable to discover stable and
      handful service nodes.  Dedicated STUN/TURN servers can be
      discovered using traditional ways.

   o  Tracker method.  As illustrated in Figure 1, STUN/TURN peers and
      proxy peers can report their ability to tracker.  Then peers can
      discover them through tracker.

   o  RELOAD method.  PPSP peers may found a RELOAD overlay and uses
      RELOAD's TURN discovery method to locate TURN peers.  There are
      two TURN discovery methods defined by RELOAD.  One is defined in
      RELOAD-base draft [I-D.ietf-p2psip-base] for discovering TURN
      service only.  The other is defined in
      [I-D.ietf-p2psip-service-discovery] for discovering any service
      including TURN service.

   o  Gossip method.  PPSP peers gossip to exchange peer list and
      status.  As illustrated in Figure 1, STUN/TURN peer list and proxy
      peer list may also be exchanged using gossip method.  Gossip
      method can be used as complement to tracker or RELOAD method.










Li, et al.              Expires January 11, 2012                [Page 7]


Internet-Draft             PPSP NAT traversal                  July 2011


    +------+ get STUN/relay peer list
    |peer D|-------------------------->+------------+
    +------+                           |            |
        \ exchange                     |            |
         \ STUN/relay                  |            |
          \ peer                       |            |
           \ list                      |            |
        +------+       get peer list   |  tracker   |
        |peer C+---------------------->|            |
        +------+                       |            |
                                       |            |
   +-----------+ report STUN ability   |            |
   |STUN peer A+---------------------->+-------+----+
   +-----------+                               |
                                               |
   +-----------------+                         |
   |  relay   peer  B|report proxy/TURN ability|
   |(proxy/TURN peer)+-------------------------+
   +-----------------+

     Figure 1: NAT traversal discovery with tracker method and gossip
                                  method

   RELOAD-ICE solution can use all NAT traversal service discovery
   methods above, while PPSP-ICE can use all methods except RELOAD
   method.

























Li, et al.              Expires January 11, 2012                [Page 8]


Internet-Draft             PPSP NAT traversal                  July 2011


5.  NAT Traversal Solutions

5.1.  PPSP-ICE Solution

5.1.1.  PPSP Signal Traversal

   The process of PPSP signal traversal is shown in Figure 2.  As shown
   in Figure 2, the process of a peer (peer A) establishing PPSP
   connection to another peer (peer B) includes following seven steps
   (step 5 to step 7 is optional). 1, both peer A and B gather their
   candidates, and report their candidates to tracker when joining
   swarm. 2, peer A gets peer list from tracker or other peer(s) and
   learns peer A's candidates from peer list. 3, peer A does one-
   direction ICE or PPSP connectivity checks from peer A to peer B. 4,
   peer A chooses candidate pair based the result of one-direction ICE
   or PPSP connectivity checks. 5, peer B and peer A exchange ICE
   parameters with PPSP messages. 6, peer A and B performs two-direction
   ICE connectivity checks or one-direction ICE connectivity checks from
   peer B to peer A. 7, peer A or peer B chooses candidate pair.

   After step 4, peer A has established a communication path to peer B.
   But the communication path may not be the optimal one, because the
   path is discovered based on one-direction connectivity checks from
   peer A to peer B. So step 5 to step 7 is used to find a better
   communication path.  Step 5 to step 7 a standard ICE process.  This
   ICE process is optional because the best communication path may have
   been found or may not be necessary.

   Following sections will describe the key steps of PPSP signal
   traversal in details.





















Li, et al.              Expires January 11, 2012                [Page 9]


Internet-Draft             PPSP NAT traversal                  July 2011


            Peer A                                        Peer B
               |                                            |
       +-------+---------+                          +-------+---------+
       |gather candidates|                          |gather candidates|
       |and report  to   |                          |and report  to   |
       |    tracker      |                          |    tracker      |
       +-------+---------+                          +-------+---------+
               |                                            |
       +-------+-----------------+                          |
       |Get peer list from       |                          |
       |tracker or other peers.  |                          |
       |Extract peer B's         |                          |
       |candidates from peer list|                          |
       +-------+-----------------+                          |
          +----+--------------------------------------------+----+
          |one-direction ICE/PPSP connectivity checks from A to B|
          +----+--------------------------------------------+----+
   +-----------+---------+                                  |
   |select candidate pair|                                  |
   +-----------+---------+                                  |
               |                                            |
               | exchange ICE paras with PPSP AttachReq&Ans |
               |<------------------------------------------>|
               |                                            |
            +--+--------------------------------------------+--+
            |  |            ICE connectivity checks         |  |
            +--+--------------------------------------------+--+
               |                                            |
            +--+--------------------------------------------+--+
            |  |           select candidate pair            |  |
            +--+--------------------------------------------+--+
               |                                            |


                      Figure 2: PPSP signal traversal

5.1.1.1.  Gathering Candidates

   Every peer MUST gather candidates for communication.  PPSP-ICE
   solution may use host candidate, NAT-assisted candidate, reflexive
   candidate, proxy candidate and relayed candidate.

   Every peer MUST gather its candidates according to its accessibility
   and the type of connectivity check.  Proxy candidate is used for the
   connectivity check in PPSP layer.  Relayed candidate is used for the
   connectivity check in ICE layer.  Host candidate, NAT-assisted
   candidate and reflexive candidate can be used for the connectivity
   check in both ICE layer and PPSP layer.



Li, et al.              Expires January 11, 2012               [Page 10]


Internet-Draft             PPSP NAT traversal                  July 2011


5.1.1.2.  Conveying Candidates

   Candidates are conveyed by PPSP messages.  When joining a swarm, a
   peer puts its candidates and peer ID in the JOIN message sent to
   tracker.  Peer list in the PPSP message contains each peer's
   candidates and peer ID in the list.

5.1.1.3.  One-direction Connectivity Checks

   Because peer A doesn't know peer B's candidates, the connectivity
   checks are one-direction checks.  The one-direction connectivity
   checks can be performed in ICE layer or PPSP layer.  This document
   recommends PPSP layer check because this step's ICE layer check
   requires modifications to ICE and TURN standard.

   If ICE layer check is used in this step, some modifications to ICE
   and TURN authentication are required because there is no ICE
   parameter exchanging before.

   ICE uses STUN binding request and response to check connectivity.
   Standard ICE [RFC5245] uses offer/answer exchange to exchange STUN
   username fragment and password.  In standard ICE [RFC5245], the
   username part of STUN credential is formed by concatenating a
   username fragment from each ICE agent, separated by a colon.
   However, there is no offer/answer exchange for the one-direction
   connectivity checks here.  A possible solution is to put STUN
   username and password in peer list.  Then in the example shown in
   Figure 2, peer A can extract peer B's STUN username and password from
   peer list.

   According to standard ICE [RFC5245], before certain connectivity
   checks, an ICE agent MUST create permissions in its TURN server for
   the IP addresses learned from its peer in the offer/answer exchange.
   However, in the example shown in Figure 2, peer B can't create
   permissions because peer B doesn't know peer A's IP addresses due to
   the absence of offer/answer exchange.  To address this issue, it
   needs a new TURN authentication method or another way to create
   permissions in peer B's TURN server.

   If the connectivity checks are performed in PPSP layer, PPSP message
   is used to test connectivity.  In the example shown in Figure 2, peer
   A simply tries to reach peer B using different candidate pair until
   it got response from peer B. Connectivity check in PPSP layer can use
   PPSP's own authentication method.







Li, et al.              Expires January 11, 2012               [Page 11]


Internet-Draft             PPSP NAT traversal                  July 2011


5.1.1.4.  Using ICE to Optimize Connection

   After step 4 (selecting candidate pair), connection between peer A
   and peer B is established based on one-direction connectivity checks.
   Because the checks are one-direction, the established connection may
   not be optimal.  A better connection may be established by performing
   a standard ICE with two-direction connectivity checks or one-
   direction connectivity checks of reverse direction.  This document
   proposes to define new PPSP messages called Attach for candidates
   exchanging.

5.1.2.  PPSP Media Traversal

   PPSP-ICE solution uses ICE for media traversal.  The way to use ICE
   here is almost the same as the way defined in [RFC5245].  In ICE as
   defined by [RFC5245], SDP is used to carry the ICE parameters.  This
   document proposes to define a PPSP message called MediaAttach for
   exchanging the ICE parameters including candidates and authentication
   data.

   The use of MediaAttach with ICE for NAT traversal is shown in Figure
   3 and Figure 4.  As shown in these figures, a peer (say peer B) wants
   to establish media connection to another peer (say peer A).  Peer A
   and peer B already have established PPSP signal connection directly
   or via a third-party peer (the method to establish signal connection
   please refers to the above section).  So peer A can send a PPSP
   MediaAttach request to peer B directly or via a third peer.  Then
   Peer B responses to peer A with MediaAttach response message.
   Through MediaAttach request and response, peer A and peer B exchange
   ICE parameters.  After that, the following NAT traversal process
   complies with standard ICE [RFC5245].




















Li, et al.              Expires January 11, 2012               [Page 12]


Internet-Draft             PPSP NAT traversal                  July 2011


          Peer A                                        Peer B
             |                                            |
             |          PPSP  MediaAttachReq              |
             |------------------------------------------->|
             |                                            |
             |          PPSP  MediaAttachAns              |
             |<-------------------------------------------|
             |                                            |
             |                                            |
          +--+--------------------------------------------+--+
          |  |            ICE connectivity checks         |  |
          +--+--------------------------------------------+--+
             |                                            |
             |                                            |
          +--+--------------------------------------------+--+
          |  |           select candidate pair            |  |
          +--+--------------------------------------------+--+
             |                                            |


                     Figure 3: PPSP Media Traversal 1



         Peer A               Peer C(as relay)         Peer B
            |                        |                   |
            | PPSP MediaAttachReq    |                   |
            |----------------------->|PPSP MediaAttachReq|
            |                        |------------------>|
            |                        |                   |
            |                        |PPSP MediaAttachAns|
            | PPSP MediaAttachAns    |<------------------|
            |<-----------------------|                   |
         +--+------------------------+-------------------+--+
         |  |            ICE connectivity checks         |  |
         +--+------------------------+-------------------+--+
            |                        |                   |
            |                        |                   |
         +--+------------------------+-------------------+--+
         |  |           select candidate pair            |  |
         +--+------------------------+-------------------+--+
            |                        |                   |



                     Figure 4: PPSP Media Traversal 2





Li, et al.              Expires January 11, 2012               [Page 13]


Internet-Draft             PPSP NAT traversal                  July 2011


5.2.  RELOAD-ICE Solution

   RELOAD-ICE solution uses ICE for PPSP signal and media traversal.
   RELOAD [I-D.ietf-p2psip-base] defines AppAttach message for
   exchanging the ICE parameters including candidates and authentication
   data.  Candidates MAY include host candidate, NAT-assisted candidate,
   reflexive candidate and relayed candidate.  NAT traversal service
   nodes used by RELOAD-ICE solution MAY include dedicated STUN/TURN
   server, STUN/TURN peer and STUN-like tracker.  RELOAD defines two
   ways to discover TURN service.  RELOAD-ICE solution MAY use any other
   NAT traversal discovery methods described in section 3.2 as well.

   The use of AppAttach with ICE for NAT traversal is shown in Figure 5.
   As shown in this figure, a peer (say peer B) wants to establish PPSP
   signal or media connection to another peer (say peer A).  Peer A can
   send a RELOAD AppAttach request to peer B through RELOAD overlay
   routing.  Then Peer B responses to peer A with AppAttach response
   message through RELOAD overlay routing.  Through MediaAttach request
   and response, peer A and peer B exchange ICE parameters.  After that,
   the following NAT traversal process complies with standard ICE
   [RFC5245].


   Peer A               RELOAD overlay         Peer B
      |                        |                   |
      | RELOAD AppAttachReq    |                   |
      |----------------------->|RELOAD AppAttachReq|
      |                        |------------------>|
      |                        |                   |
      |                        |RELOAD AppAttachAns|
      | RELOAD AppAttachAns    |<------------------|
      |<-----------------------|                   |
   +--+------------------------+-------------------+--+
   |  |            ICE connectivity checks         |  |
   +--+------------------------+-------------------+--+
      |                        |                   |
      |                        |                   |
   +--+------------------------+-------------------+--+
   |  |           select candidate pair            |  |
   +--+------------------------+-------------------+--+
      |                        |                   |



                    Figure 5: NAT Traversal with RELOAD






Li, et al.              Expires January 11, 2012               [Page 14]


Internet-Draft             PPSP NAT traversal                  July 2011


5.3.  Solution Comparison

   NAT traversal solutions in this document all use ICE.  PPSP-ICE
   solution uses modified ICE or ICE-like method to establish PPSP
   signal connection, and optionally uses ICE to optimize connection
   path.  PPSP-ICE solution uses ICE for PPSP media traversal of NAT.
   RELOAD solution uses ICE for both PPSP signal and media traversal of
   NAT.

   Compared with RELOAD-ICE solution, PPSP-ICE solution increases
   tracker's workload.  But the workload is acceptable considering
   tracker's work of maintaining and providing peer status and content
   location.  Compared with PPSP-ICE solution, RELOAD-ICE solution
   requires much more time to traverse NAT, and is more complicated to
   implement.  RELOAD solution can be used in both tracker-based and
   tracker-less P2P streaming systems.

   The major differences between PPSP-ICE solution and RELOAD-ICE
   solution are listed in the table below.


   +----------------+----------------------+---------------------------+
   |                |     PPSP-ICE         |      RELOAD-ICE           |
   +----------------+----------------------+---------------------------+
   |                |   Using proxy        |                           |
   | Using proxy    |   candidate in PPSP  |                           |
   | candidate or   |   connectivity       |                           |
   | relayed        |   checks; using      | Using relayed candidate   |
   | candidate      |  relayed candidate   |                           |
   |                |  in ICE checks       |                           |
   +----------------+----------------------+---------------------------+
   | NAT traversal  |   All methods except |                           |
   | service        |   RELOAD method      |      All methods          |
   | discovery      |                      |                           |
   +----------------+----------------------+---------------------------+
   |                | Establishing PPSP    |                           |
   |                |   signal connection: |                           |
   | candidates     |  one-direction       |                           |
   | conveying for  | conveying candidates |     Exchanging ICE        |
   | PPSP signal    |  with PPSP messages. |      parameters with      |
   | traversal      |Optimizing established|    RELOAD messages        |
   |                |    PPSP signal       |                           |
   |                | connection:          |                           |
   |                | exchanging ICE       |                           |
   |                | parameters with      |                           |
   |                | PPSP messages.       |                           |
   +----------------+----------------------+---------------------------+
   |                | Establishing PPSP    |                           |



Li, et al.              Expires January 11, 2012               [Page 15]


Internet-Draft             PPSP NAT traversal                  July 2011


   | Connectivity   | signal connection:   |                           |
   | checks for PPSP| One-direction PPSP   | ICE connectivity checks   |
   |signal traversal| connectivity checks. |                           |
   |                |Optimizing established|                           |
   |                |    PPSP signal       |                           |
   |                | connection: ICE      |                           |
   |                |  connectivity checks |                           |
   +----------------+----------------------+---------------------------+
   | ICE parameters |   Exchanging ICE     |      Exchanging ICE       |
   | conveying for  |   parameters with    |      parameters with      |
   | PPSP media     |   PPSP messages      |     RELOAD messages       |
   | traversal      |                      |                           |
   +----------------+----------------------+---------------------------+
   |                |                      |                           |
   | Connectivity   |    ICE connectivity  |    ICE connectivity checks|
   | checks for PPSP|    checks            |                           |
   | media traversal|                      |                           |
   +----------------+----------------------+---------------------------+
   | Implementing   |       less           |         more              |
   | work           |                      |                           |
   +----------------+----------------------+---------------------------+
   | Relying on     |                      | RELOAD                    |
   | centralized    |     tracker          | configuration/enrollment  |
   | servers        |                      |server                     |
   +----------------+----------------------+---------------------------+
   | Used in        |                      |                           |
   |  tracker-less  |     no               |          yes              |
   |   P2P streaming|                      |                           |
   |   system       |                      |                           |
   +----------------+----------------------+---------------------------+
   | NAT traversal  |     low              |        high               |
   | latency        |                      |                           |
   +----------------+----------------------+---------------------------+


















Li, et al.              Expires January 11, 2012               [Page 16]


Internet-Draft             PPSP NAT traversal                  July 2011


6.  Decisions to Implement NAT Traversal

   NAT traversal is not a mandatory requirement for PPSP operations, and
   if NAT traversal needs to be implemented there are several possible
   implementation options.  The decision of supporting NAT traversal or
   not and choosing which NAT traversal solution should be left to
   implementation.  If a NAT traversal solution is chosen, there are
   still decisions to make on using which NAT traversal method and NAT
   traversal service node.

   These decisions could be made with following considerations.

   o  First, the success rate of connection.  Unlike P2P VoIP service,
      P2P streaming service doesn't require that any two peers can
      establish connection.  Instead, it only requires that the download
      of streaming media succeed and the download speed is satisfied.

   o  Second, NAT type and its ratio.  For example, in an environment
      that all or most NATs are full cone NATs, a P2P streaming system
      only needs STUN/STUN-like method.

   o  Third, the implementation and maintenance overheads of NAT
      traversal solution/method/service.  For example, a P2P streaming
      system may choose not to use RELOAD-ICE solution due to
      implementing overhead.

   o  Fourth, NAT traversal solution/method/service's performance,
      reliability, etc.  For example, a P2P streaming system may choose
      not to use media relay or use media relay only as the last resort
      because media relay consumes much more resources on relay node.





















Li, et al.              Expires January 11, 2012               [Page 17]


Internet-Draft             PPSP NAT traversal                  July 2011


7.  PPSP Extension for NAT Traversal

   To enable NAT traversal, this section proposes extension to the
   tracker protocol and peer protocol.

7.1.  Tracker's STUN-like Function

   This extension is optional.  Tracker performs STUN-like function by
   putting peer's address it observes in CONNECT response.

   If enabling STUN-like function, this draft proposes to extent tracker
   protocol by adding following tag in CONNECT response.

   <ReflexiveAddr>

   IP and port

   </ReflexiveAddr>

7.2.  Proxy Peer

   This extension is mandatory for PPSP-ICE solution.

7.2.1.  Relayed by Proxy

   Proxy peer relaying messages requires PPSP messages between peers
   containing destination peer's ID.  As shown below, a tag named
   "DestPeerID" containing the destination peer's ID can be used.

   <DestPeerID>***</DestPeerID>

7.2.2.  Connecting and Disconnecting Proxy

   To receive messages via proxy peer, a NATed peer MUST connect to
   proxy peer.  If the NATed leaves the PPSP network, it MUST disconnect
   from its proxy peer.  CONNECT and DISTCONNECT methods can be reused
   to connect and disconnect proxy peer separately.  The messages don't
   need to be changed except for adding DestPeerID in the messages.

7.3.  STUN/TURN/proxy Ability Report and Querying STUN/TURN/proxy Peer
      List

   This extension is mandatory for PPSP-ICE solution.  PPSP tracker
   protocol already supports STUN/TURN ability report with STAT
   messages.  To support proxy ability report, a STAT type name "proxy"
   can be added.  The value of proxy STAT is Boolean value.

   Peer can query STUN/TURN/proxy peer list from tracker or other peer



Li, et al.              Expires January 11, 2012               [Page 18]


Internet-Draft             PPSP NAT traversal                  July 2011


   using extended FIND messages.  The extension uses <Stat> tag to
   indicate the type of peer list, and removes <SwarmID> and <ChunkID>
   tags.

   The method specific XML of the extended FIND message takes the form
   shown below:

   <PeerID>***</PeerID>

   <Peernum>***</Peernum>

   <Stats>

   <Stat property="STUN">true</Stat>

   ... more stats ...

   </Stats>

   The method specific XML of the extended FIND response takes the form
   shown below:

   <Peers> Peer list </Peers>

7.4.  Carrying Candidates in PPSP Message

   This extension is mandatory for PPSP-ICE solution.  A peer MAY have
   multiple IP addresses with different properties.  This document
   proposes to extend the PeerAddresses tag defined by
   [I-D.cruz-ppsp-http-tracker-protocol].  An example of the extended
   PeerAddresses is shown below:

   <PeerAddresses>

   <PeerAddress ip="***" port="***" priority="***" type="host"/>

   <PeerAddress ip="***" port="***" priority="***" type="reflexive"/>

   <PeerAddress ip="***" port="***" priority="***" type="proxy"/>

   </PeerAddresses>

   To use PPSP-ICE solution, all PPSP messages that containing peer
   address MUST use the tag.







Li, et al.              Expires January 11, 2012               [Page 19]


Internet-Draft             PPSP NAT traversal                  July 2011


7.5.  Exchanging ICE Parameters

   This extension is mandatory for PPSP-ICE solution.  This document
   proposes Attach and MediaAttach methods to exanging ICE parameters
   for building PPSP connection and media connection separately.  These
   two methods have different method name, but share the same method
   body as shown below:

   <DestPeerID>***</DestPeerID>

   <PeerID>***</PeerID>

   <SDP>

   ...

   </SDP>

   The ICE parameters are encoded in SDP.
































Li, et al.              Expires January 11, 2012               [Page 20]


Internet-Draft             PPSP NAT traversal                  July 2011


8.  Security Considerations

   Todo: The content of this section need further input.
















































Li, et al.              Expires January 11, 2012               [Page 21]


Internet-Draft             PPSP NAT traversal                  July 2011


9.  IANA Considerations

   TBD
















































Li, et al.              Expires January 11, 2012               [Page 22]


Internet-Draft             PPSP NAT traversal                  July 2011


10.  References

10.1.  Normative References

   [I-D.cruz-ppsp-http-tracker-protocol]
              Cruz, Rui S., Nunes,  Mario S., and Joao P. Taveira,
              "HTTP-based PPSP Tracker Protocol",
              draft-cruz-ppsp-http-tracker-protocol-01 (work in
              progress), June 2011.

   [I-D.gu-ppsp-peer-protocol]
              Gu, Y. and David A. Bryan, "Peer Protocol",
              draft-gu-ppsp-peer-protocol-02 (work in progress),
              June 2011.

   [I-D.gu-ppsp-tracker-protocol]
              Gu, Y., Bryan, David A., and L. Deng, "PPSP Tracker
              Protocol", draft-gu-ppsp-peer-protocol-04 (work in
              progress), May 2011.

   [I-D.zhang-ppsp-problem-statement]
              Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
              "Problem Statement of P2P Streaming Protocol (PPSP)",
              draft-zhang-ppsp-problem-statement-06 (work in progress),
              July 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

10.2.  Informative References

   [I-D.ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
              Base Protocol", draft-ietf-p2psip-base-12 work in
              progress, November 2010.

   [I-D.ietf-p2psip-service-discovery]
              Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
              REsource LOcation And Discovery (RELOAD)",
              draft-maenpaa-p2psip-service-discovery-02 work in
              progress, January 2011.




Li, et al.              Expires January 11, 2012               [Page 23]


Internet-Draft             PPSP NAT traversal                  July 2011


   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5766]  Matthews, P., Rosenberg, J., and R. Mahy, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC RFC5766,
              April 2010.











































Li, et al.              Expires January 11, 2012               [Page 24]


Internet-Draft             PPSP NAT traversal                  July 2011


Authors' Addresses

   Lichun Li
   ZTE Corporation
   RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone:
   Email: lilichun@gmail.com


   Jun Wang
   ZTE Corporation
   RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone:
   Email: wang.jun17@zte.com.cn


   Wei Chen
   China Mobile
   Unit 2, 28 Xuanwumenxi Ave, Xuanwu District,
   Beijing 100053
   P.R.China

   Phone:
   Email: chenweiyj@chinamobile.com





















Li, et al.              Expires January 11, 2012               [Page 25]