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.
IP and port
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.
***
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 tag to
indicate the type of peer list, and removes and
tags.
The method specific XML of the extended FIND message takes the form
shown below:
***
***
true
... more stats ...
The method specific XML of the extended FIND response takes the form
shown below:
Peer list
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:
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:
***
***
...
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]