One document matched: draft-jiang-p2psip-stun-turn-discovery-00.txt
P2PSIP XingFeng. Jiang
Internet-Draft Huawei Tech.
Intended status: Standards Track June 20, 2007
Expires: December 22, 2007
A mechanism to discover STUN/TURN nodes in P2PSIP
draft-jiang-p2psip-stun-turn-discovery-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft proposes a lightweight method used to discover P2PSIP
peers or clients distributed throughout Peer-to-Peer overlay that
provide Network Address Translator-traversal functionality.
Jiang Expires December 22, 2007 [Page 1]
Internet-Draft P2PSIP STUN TURN June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview and concept . . . . . . . . . . . . . . . . . . . . . 4
3.1. Problem statement . . . . . . . . . . . . . . . . . . . . 5
3.2. Use case and assumptions . . . . . . . . . . . . . . . . . 6
3.2.1. Assumption . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Use case . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Procedure to discover STUN/TURN server candidate . . . . . 7
3.3.1. Construction of STUN/TURN candidate table . . . . . . 7
3.3.2. Discovery procedure . . . . . . . . . . . . . . . . . 9
3.3.3. Success ratio of discovery operations . . . . . . . . 9
4. NATed peer joins the overlay . . . . . . . . . . . . . . . . . 10
4.1. Joining peer's behavior . . . . . . . . . . . . . . . . . 10
4.2. Intermediate peers' behavior . . . . . . . . . . . . . . . 10
5. NATed peer routine maintenance . . . . . . . . . . . . . . . . 11
5.1. NATed peer's behavior . . . . . . . . . . . . . . . . . . 11
5.2. Intermediate peers' behavior . . . . . . . . . . . . . . . 11
6. NATed nodes get/put resource . . . . . . . . . . . . . . . . . 12
6.1. NATed node's behavior . . . . . . . . . . . . . . . . . . 12
6.2. Behavior of peers processing the request . . . . . . . . . 12
7. Security considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Ackknowlegement . . . . . . . . . . . . . . . . . . . . . . . 12
10. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informational References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Jiang Expires December 22, 2007 [Page 2]
Internet-Draft P2PSIP STUN TURN June 2007
1. Introduction
The P2PSIP working group intends to make use of Peer-to-peer (P2P)
technology to provide distributed location service. A P2PSIP overlay
is comprised of P2PSIP peers, each of which provides transport and
storage service for other nodes in the overlay. Therefore
critically-important messages will be transported through the overlay
between peers which may not know each other's existence and location
in advance. For a variety of reasons described in [RFC4787], NATs
may cause the communication between peers to fail. Similarly,
applications residing on the peers or clients experience the same
problem.
According to the data from [Illuminati], 74% PCs on the Internet are
behind NAT. The methods used to make applications traverse NAT are
complicated because of diversity of NAT implementations, also
described in [RFC4787]. In IETF, there are a suite of proposals to
address this issue, named STUN/TURN/ICE. The essence of these
protocols is to make a well-known server with public address to help
nodes behind NAT learn the mappings on the NATs or on the TURN
server, then follow ICE process to negotiate a workable address pair.
STUN/TURN servers play a very important role for the successful
communication in environments where NATs are located between
communication endpoints, but this also imposes significant demand on
the processing capability of STUN/TURN servers. In use cases where
the demand is to be met by deploying centralized STUN/TURN servers,
carriers will incur expensive investment on these servers and the
resulting system will not scale well. Fortunately, there are a great
number of peers and clients with public address in the overlay which
could take the role of STUN/TURN server if network operators (or
network users) are willing to equip these nodes with STUN/TURN server
functions and are willing to help nodes behind NAT and their
contributed processing power could help satisfy the demand for
computing and network resources.
The general service discovery mechanism in DHT encodes the service
first and puts contact information of the service provider into the
overlay under the key K computed by applying hash function to the
encoded service. When a node wants to get one or more service
providers, it will send a GET message keyed by K and get the service
nodes finally. But this method will cause the admitting peer for Key
K overwhelmed with huge numbers of requests and it will also be
subject to DOS attack.
This draft proposes a lightweight method to discover peers or clients
with STUN/TURN server functionality distributed through the overlay.
Jiang Expires December 22, 2007 [Page 3]
Internet-Draft P2PSIP STUN TURN June 2007
2. Definition
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].
Terms defined in [concept] are re-used without further definition in
this document.
Some new concepts are defined in this section.
o Sending node: It identifies the node, either a peer or a client,
who sends a request.
o Intermediate peers: it identify all peers on the path from the
sending node to the message destination, including the peer which
is the message destination.
o STUN/TURN server candidates: The nodes which are willing to play
the STUN/TURN server role. Various types of nodes could be the
candidate, including peer, client. Short form of name: server
candidate.
o STUN/TURN candidate table: It stores information about STUN/TURN
server candidates. Every peer MUST have this table, but the
number of entry in the candidate table may be zero because of
distribution of server candidates in the overlay. Each entry of
the table is learned dynamically. Peers in the routing table or
neighbor table or connection table which are willing to be server
candidates MUST be filled into the table. The peer which is ready
to provide STUN/TURN service SHOULD include its own information in
the table. Clients which are associated with the peers and ready
to provide STUN/TURN service SHOULD be also filled. The
information about each candidate includes the candidate's
transport address at least. Short form of name: candidate table.
o STUN/TURN candidate set: It is often carried in messages at the
request of the sending node. It will be returned to the sending
node of this message. Its content includes server candidates
which are chosen and put into the candidate set. Short form of
name: candidate set.
o NATed node: refer to peers or clients which are behind NAT. They
need STUN/TURN servers' help to traverse NAT. NATed peers and
NATed clients are refer to peers and clients who are behind NAT.
o routing table, routing state: In this document, routing means
overlay level routing, not IP network level routing.
3. Overview and concept
This section provides a non-normative description of the procedure
used to select STUN/TURN server candidates. It also describes the
Jiang Expires December 22, 2007 [Page 4]
Internet-Draft P2PSIP STUN TURN June 2007
STUN/TURN candidate table saved in every peer whose content could be
learned from routing table, neighbor table or some other sources, for
example, client's characteristics. Normative text is found in the
subsequent sections.
3.1. Problem statement
The existence of NAT in the Internet challenges P2P communications.
In P2PSIP case, both peer protocol and other applications which
invoke services provided by P2PSIP overlay have to deal with NAT
traversal issue.
As for NAT traversal for peer protocol, [bootstrap] and [dSIP-NAT]
have proposed some mechanisms. It makes use of bootstrap server to
introduce joining peer to bootstrap peer and finally to admitting
peer. Peers on the path between the joining peer and the admitting
peer play the role of the rendezvous server to help two peers wishing
to communicate with each other exchange their candidate addresses in
order to obtain a workable candidate address pair in the following
ICE process. Because the joining peer hasn't joined the overlay at
that time, STUN/TURN server could be chosen in several ways, either
among centralized servers configured statically or in the results
from the enrollment procedure which may return addressing information
that points to some stable peers with STUN/TURN server function.
As for other applications beyond the peer protocol, they often look
up necessary information, for example other SIP UA's contact address
in VoIP application, then communicate with each other after getting
the results stored in the overlay. This kind of potential
communication requires that these applications should work even if
NATs are between them, so they should find out STUN/TURN servers to
help them. These servers could be obtained in various ways,
including mechanisms described above. But taking distributed
processing power of the overlay into account, choosing nodes, either
clients or peers, in the overlay with STUN/TURN server capability is
also a good choice.
How do the peers discover the STUN/TURN server candidates?
Certainly, general service discovery mechanism is a viable option,
but the peer being responsible for storing the associated key with
the service potentially has to serve a large number of requests in
some deployment scenarios and is subject to DOS attack.
So a lightweight discovery method which makes use of routine traffic,
for example, JOIN, GET, PUT, or some routing state maintenance
message, to do this work is preferable over the general service
discovery mechanism. Certainly, this method makes some assumptions
and couldn't guarantee success for each discovery operation. But it
Jiang Expires December 22, 2007 [Page 5]
Internet-Draft P2PSIP STUN TURN June 2007
could complement to the general service discovery mechanism or
similiar methods.
3.2. Use case and assumptions
In this section, we will present some assumptions for this proposals
first, then give some scenarios which are chosen from the [USE CASE],
and explain why this proposal is more suited in these scenarios.
3.2.1. Assumption
There are some assumptions for this proposal described in the
following text.
1. In many deployments, there should be some peers or clients who
have public addresses and are willing to share their processing
resource, mainly including CPU cycles, bandwidth, to help NATed
nodes to traverse the NAT to communicate with others in the
ovelay. The ratio of the number of this kinds of nodes ( which
would play the STUN/TURN role ) to the number of the all nodes in
the overlay could be as low as possible. From our analysis in
the following section, even the ratio which is as low as 1% could
make the successful discovery with high probability.
2. Peers/clients SHOULD know whether it is NATed or not before the
communication begins. It could be achieved after they get their
server-reflexive candidates using STUN protocol. If the server-
reflexive candidate does not equal to one of its own local
interface address, we could conclude that there is at least a NAT
between them and the public Internet. But how peers/clients
learn this information will not be discussed in this document.
3.2.2. Use case
P2PSIP intends to work in several scenarios which are proposed in
[USE CASE]. Here we will present two use cases which is more
appropriate place for the proposed discovery mechanism to be used.
1. Open global P2P VoIP network. This is a global P2P VoIP network
in which there is no central authority such as a single service
provider. So, there are often no centralized servers in the
overlay except bootstrap servers which will help joining node,
either peers or clients, participate in the overlay. It is a
good scenario to make full use of various resources, for example,
bandwidth, CPU cycles, etc, distributed among each participants.
With the help from participants who are able and willing to be
the STUN/TURN servers, participants in the overlay could succeed
to communicate with each other even in the presence of the NAT.
Jiang Expires December 22, 2007 [Page 6]
Internet-Draft P2PSIP STUN TURN June 2007
2. Impeded access. Certain groups may have their ability to
communicate impeded. These users should be able to communicate
without the need to connect to any centralized servers, which may
be blocked by providers upstream of the user. A fully
decentralized system cannot be completely disconnected without
removing connectivity at the basic Internet level. Likely, no
centralized servers exist in this scenario. The possible method
in this case for participants to communicate with each other in
the presence of NAT is to choose some participants to take on the
STUN/TURN task.
Besides the two above cases, there are a few scenarios where some
participants, which are eligible STUN/TURN servers, could be chosen
to help NATed nodes. Usually, some centralized STUN/TURN servers MAY
be deployed for NAT traversal. These servers MAY fail simultaneously
or could not serve new requests due to limit on the processing power.
So these eligible participants distributed in the overlay could be
the last resort for NATed nodes to get STUN/TURN service.
3.3. Procedure to discover STUN/TURN server candidate
In this section, we will give a overview of the procedure for
discovering STUN/TURN server candidates with a lightweight method
which will make full use of existing techniques in the P2PSIP.
There are a great number of messages routed through the overlay in
recursive or iterative mode. These messages comprise of JOIN, PUT,
GET, etc. Most of requests will be relayed peer by peer until it
reaches its destination. It is the right time for the peers the
request has traversed to collect information on STUN/TURN server
candidates for the sending node.
If the sending node, either a peer or a client, is behind NAT, it
could indicate its willingness in the requests that server candidates
are needed. When intermediate peers receive the request, they
examine whether the sending node wants to collect server candidates
first. If it does, the intermediate peers MUST look up its STUN/TURN
candidate table, and put the server candidates chosen according to
specific criteria into the candidate set in the response or request,
which depends on routing mode, for example, iterative or recursive.
Finally candidate set MUST be returned to the sending node. So the
discovery work could be done in a piggyback mode which hardly bring
any bad effect on the P2PSIP overlay.
3.3.1. Construction of STUN/TURN candidate table
Intermediate peers look up the STUN/TURN candidate table. In the
current proposal, the following sources are explored to select server
Jiang Expires December 22, 2007 [Page 7]
Internet-Draft P2PSIP STUN TURN June 2007
candidates. In the future, there may be other sources due to richer
information of Peers.
1. Routing state. It includes routing table, neighbor table and
connection table. Either in dSIP or in P2PP, two proposal for
peer protocol, routing state SHOULD keep other peers' transport
addresses to allow further communication. Usually, information
about the sending peers is carried in the peer protocol message,
which is required in either [dSIP] or [P2PP]. P2PP uses Peer-
Info to achieve this goal and dSIP uses DHT-PeerID header. Each
peer could indicate to other peers whether it is willing to be a
STUN/TURN server . So it is easily for the peer to store other
peers' features with the routing state. Every peer MUST include
peers which show their willingness to be a STUN/TURN server into
candidate table by examing every peer in the routing state.
2. Peer's feature. Every peer knows whether it is willing to be a
STUN/TURN server. If it is, it SHOULD be put into the STUN/TURN
candidate table.
3. Associated clients' feature. In P2PSIP architecture, a client
need peer's help to access overlay, i,e, GET/PUT/REMOVE
operations. Although the interaction between the peer and the
client has not been agreed in WG discussions, it is easy for the
peer to learn the feature of its associated clients. So the peer
will know whether the client is willing to be a STUN/TURN server.
Peers SHOULD also add the clients which are willing to be a STUN/
TURN server into the candidate table.
The peer may prioritize the resulting server candidates according its
source. For example, routing state may has the highest priority, and
associated clients have the lowest, because peers is often more
powerful than the clients. In order to make the service load
distributed through the candidates, peer could choose candidates for
sending nodes according to some algorithms, for example, choose the
candidates randomly.
We have listed three sources in the peer, but the source list is not
exhaustive. New sources may be added in the future.
Each entry of the candidate table may include the following
parameters:
o transport address: transport address for STUN/TURN service.
o Role of this candidate in the overlay: peers or clients.
o Priority: used in choosing the candidate. The priority for each
server candidate may change according to a specific algorithm to
balance load among these server candidates.
o Some performance parameters: it will be a criteria for peers to
choose the server candidate. They may include their CPU
processing power, bandwidth,etc.
Jiang Expires December 22, 2007 [Page 8]
Internet-Draft P2PSIP STUN TURN June 2007
3.3.2. Discovery procedure
NATed nodes needs STUN/TURN server candidates to address NAT
traversal issue, then initiated discovery procedure in a piggyback
mode. There are several messages which could be used to piggyback to
discover STUN/TURN server candidate.
In this draft, we suggest three types of messages to collect STUN/
TURN server candidate: JOIN message, periodical maintenance message
and GET/PUT message. The reason for choosing these messages is that
they are common used message in the overlay and routed through the
overlay, so using them does not bring extra traffic in the overlay.
The procedure while using different messages is almost identical.
The following text shows the simple procedure. Although this
procedure is more helpful to NATed nodes, non-NATed nodes could also
execute this procedure to discover server candidates, which may be
passed to other NATed nodes.
1. NATed nodes send the message and set associated options to
express their demand for STUN/TURN server candidate in the
message.
2. Intermediate peers check the sending node's demand for server
candidate. If associated option is set, peers look up their
STUN/TURN candidate table and put the results into the candidate
set carried in the request or response which depends on routing
mode. If recursive mode is used, candidate set will be carried
in the request and later be returned to the sending node hop by
hop in the response. If iterative mode is used, candidate set
will be returned to the sending node in response immediately.
3. Finally, NATed nodes get the results in the response and use them
in the future communications.
3.3.3. Success ratio of discovery operations
NATed nodes could use the above procedure to discover server
candidates. In rare case, one piggyback operation may fail because
there is no STUN/TURN server candidate on the intermediate peers.
The candidate set returned from the overlay to NATed nodes is NULL in
this case. Using another message which traverse different path may
identify a non-NULL candidate set with higher capability.
Reasoning is presented here to prove that the method makes sense for
discovering server candidates. First, Let us assume that the ratio
of the number of the peers which are willing to be STUN/TURN server
to all peers is about f = 10% . Then we could deduce that there is
about 10 percent of peers which could be STUN/TURN server candidates
in the routing state of every peer. For example, in [Pastry], a
Jiang Expires December 22, 2007 [Page 9]
Internet-Draft P2PSIP STUN TURN June 2007
simulation result shows that with the b = 4, and 10 ** 6 nodes in the
overlay, a routing table contains on average 75 entries and the
expected number of routing hops is 5. So the number of entry in
candidate table would be about 7.5( 75 * 10%) in each peer, and
ultimately choice could be made based on these 38(7.5 * 5) server
candidates. Even if f equals 2%, there are still about 7 server
candidates.
4. NATed peer joins the overlay
4.1. Joining peer's behavior
Before a joining peer joins the overlay, it MUST learn whether it is
a NATed peer. Other than performing standard P2PSIP peer protocol
procedure, NATed peer MUST perform the below procedure to discover
server candidates. Certainly, non-NATed peers also could perform
this procedure.
1. Joining peer MUST express its demand on STUN/TURN server
candidates in the JOIN message for intermediate peers of the JOIN
request to invoke discovery operation. How the joining peer
express his demand is not determined at present because P2PSIP
peer protocol has not been standardized. But it will be easy to
achieve this goal as soon as P2PSIP peer protocol is fixed. The
joining peer MAY specify the number of server candidates it wants
in the requests.
2. When the joining peer receives the response from the peers in the
overlay, if it has expressed the demand on server candidate, it
MUST check the candidate set in the response and save the
candidate set locally for later use.
4.2. Intermediate peers' behavior
Intermediate peers of the JOIN message MUST do their routine
processing based on standardized P2PSIP peer protcol. If they find
that the sending peer has expressed his demand on server candidates,
they MUST follow below procedure additionally.
1. If the message is a response, intermediate peers don't do
additional processing beyond forwarding;
2. If the message is a request, peers receives a STUN/TURN candidate
set in the request. If the sending peer has set the number of
candidate it wants in the message, set the N to this number. If
it has not been set in the message, we MAY choose a default value
for N, for example, 10;
Jiang Expires December 22, 2007 [Page 10]
Internet-Draft P2PSIP STUN TURN June 2007
3. If the number K in STUN/TURN candidate set equals or exceeds N,
peers don't do anything;
4. Peers fetch candidates from its candidate table according to a
specific criteria, for example, priority, or performance
parameters;
5. Peers perform comparison operation before adding a new STUN/TURN
candidate into the candidate set. The comparison criteria MAY be
based on IP address and keeps the candidate in the candidate set
unique;
6. Each time peer places a server candidate into the candidate set,
set K to K + 1;
7. The lookup operation in the candidate table will stop because
either the K equals N or all server candidates in the candidate
table has been examined.
5. NATed peer routine maintenance
Peers often do routine maintenance work to keep the routing table
consistent with the ovelay topology as much as possible. For
example, the Chord algorithm checks whether peers in the finger table
has changed due to topology change of the overlay by sending
periodical message. So if NATed peers like, they could use this type
of message to discover server candidates.
5.1. NATed peer's behavior
The processing of this type of message MUST follow procedure in the
P2PSIP peer protocol. If NATed peers would like to collect STUN/TURN
server candidate, they MUST also follow the procedure below. Of
course, Non-NATed peers could also perform the below procedure.
1. When NATed peers want to collect STUN/TURN server candidate, they
MUST express their interest in the corresponding message. They
MAY specify the number of the server candidate they want in the
message.
2. When the NATed peer receives the response from the peers in the
overlay, if it has expressed the demand, it MUST check the
candidate set in the response and save the candidate set locally
for later use.
5.2. Intermediate peers' behavior
The procedure is the same as the procedure defined in section 4.2.
Jiang Expires December 22, 2007 [Page 11]
Internet-Draft P2PSIP STUN TURN June 2007
6. NATed nodes get/put resource
When NATed clients of the overlay wants to get some candidates for
their future communication, they MAY make use of the GET/PUT messages
to achieve this goal. Certainly, GET/PUT messages are also to be
used by NATed Peers to discover server candidate.
6.1. NATed node's behavior
The processing of GET/PUT messages MUST follow procedures in the
P2PSIP peer and client protocol. If they would like to discover
STUN/TURN server candidate, they MUST follow the additional procedure
below.
1. When NATed nodes want to discover server candidate, they MUST
express their desire in the GET or PUT messages. They MAY
specify the number of the server candidates they want in the
message.
2. When the NATed node receives the response from the peers in the
overlay, if it has expressed the desire for STUN/TURN server
candidate, it check the candidate set in the response and save
the candidate set locally for later use.
6.2. Behavior of peers processing the request
The procedure is the same as the procedure defined in section 4.2.
7. Security considerations
Security considerations will be discussed in a future version of this
document.
8. IANA considerations
IANA considerations will be discussed in a future version of this
document.
9. Ackknowlegement
The authors are especially grateful for the comments and constructive
advice from Spencer Dawkins and Philip Matthews.
Jiang Expires December 22, 2007 [Page 12]
Internet-Draft P2PSIP STUN TURN June 2007
10. Reference
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Offer/
Answer Protocols", Internet Draft draft-ietf-mmusic-ice (Work in
Progress).
[Concept] Bryan, D., Matthews, P., Shim, E., Willis, D., " Concepts
and Terminology for Peer to Peer SIP " Internet Draft
draft-willis-p2psip-concepts-04 (Work in progress)
[TURN] Rosenberg, J., Mahy, R., Huitema, C., "Obtaining Relay
Addresses from Simple Traversal Underneath NAT (STUN)" Internet Draft
draft-ietf-behave-turn-03 (Work in Progress)
[STUN] Rosenberg, J., Huitema, C., Mahy, R., Willis, D., "Session
Traversal Utilities for (NAT) (STUN)" Internet Draft
draft-ietf-behave-rfc3489bis-06 (Work in Progress)
10.2. Informational References
[dSIP] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P
Approach to SIP Registration and Resource Location", Internet Draft
draft-bryan-p2psip-dsip-00 (Work in Progress), February 2007.
[Illuminati] Cadaco, M. and M. Freedman, "Illuminati - Opportunistic
Network and Web Measurement",http://illuminati.coralcdn.org/stats/,
February 2007.
[dSIP-NAT] Cooper, E., Matthews, P., Bryan, D., and B. Lowekamp, "NAT
Traversal for dSIP", Internet Draft
draft-matthews-p2psip-dsip-nat-traversal-00 (Work in Progress),
February 2007.
[Bootstrap] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap
Mechanisms for P2PSIP", Internet Draft
draft-matthews-p2psip-bootstrap-mechanisms (Work in Progress).
[P2PP] Baset, S., Schulzrinne, H., "Peer-to-Peer Protocol (P2PP)"
Jiang Expires December 22, 2007 [Page 13]
Internet-Draft P2PSIP STUN TURN June 2007
Internet Draft draft-baset-p2psip-p2pcommon-01 (Work in Progress )
[PASTRY] Rowstron, A., Druschel, R., "Pastry: Scalable, decentralized
object location and routing for large-scale peer-to-peer systems"
Proc. of the 18th IFIP/ACM International Conference on Distributed
Systems Platforms (Middleware 2001). Heidelberg, Germany, November
2001.
[Use case] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-
to-Peer Session Initiation Protocol (P2PSIP)", Internet Draft
draft-bryan-sipping-p2p-usecases-00, November 2005.
Author's Address
XingFeng Jiang
Huawei Tech.
Phone: +86(25)84565468
Email: jiang.x.f@huawei.com
Jiang Expires December 22, 2007 [Page 14]
Internet-Draft P2PSIP STUN TURN June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jiang Expires December 22, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 11:11:05 |