draft-ietf-p2psip-concepts-00.txt   draft-ietf-p2psip-concepts-01.txt 
P2PSIP Working Group D. Bryan P2PSIP Working Group D. Bryan
Internet-Draft College of William and Mary and Internet-Draft College of William and Mary and
Intended status: Informational SIPeerior Technologies Intended status: Informational SIPeerior Technologies
Expires: December 3, 2007 P. Matthews Expires: May 18, 2008 P. Matthews
Avaya Avaya
E. Shim E. Shim
Locus Telecommunications Locus Telecommunications
D. Willis D. Willis
Unaffiliated Unaffiliated
November 15, 2007
Concepts and Terminology for Peer to Peer SIP Concepts and Terminology for Peer to Peer SIP
draft-ietf-p2psip-concepts-00 draft-ietf-p2psip-concepts-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2007. This Internet-Draft will expire on May 18, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines concepts and terminology for use of the Session This document defines concepts and terminology for use of the Session
Initiation Protocol in a peer-to-peer environment where the Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar and message routing functions are traditional proxy-registrar and message routing functions are
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. The Distributed Database Function . . . . . . . . . . . . 13 5.1. The Distributed Database Function . . . . . . . . . . . . 13
5.2. Using the Distributed Database Function . . . . . . . . . 15 5.2. Using the Distributed Database Function . . . . . . . . . 15
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 20 5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 20
5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 21 5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 21
5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22 5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22
5.7. Architecture . . . . . . . . . . . . . . . . . . . . . . . 23
6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 23 6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 24
6.1. Selecting between Multiple Peers offering the Same 6.1. Selecting between Multiple Peers offering the Same
Service . . . . . . . . . . . . . . . . . . . . . . . . . 23 Service . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Visibility of Messages to Intermediate Peers . . . . . . . 23 6.2. Visibility of Messages to Intermediate Peers . . . . . . . 24
6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 23 6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 25
6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 24 6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 25
6.5. Relationships of Domains to Overlays . . . . . . . . . . . 24 6.5. Relationships of Domains to Overlays . . . . . . . . . . . 25
6.6. Protocol Layering . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Changes in This Version . . . . . . . . . . . . . . . . . . . 25 9. Changes in This Version . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Background 1. Background
One of the fundamental problems in multimedia communication between One of the fundamental problems in multimedia communication between
Internet nodes is that of discovering the host at which a given user Internet nodes is that of discovering the host at which a given user
can be reached. In the Session Initiation Protocol (SIP) [RFC3261] can be reached. In the Session Initiation Protocol (SIP) [RFC3261]
this problem is expressed as the problem of mapping an Address of this problem is expressed as the problem of mapping an Address of
Record (AoR) for a user into one or more Contact URIs [RFC3986]. The Record (AoR) for a user into one or more Contact URIs [RFC3986]. The
AoR is a name for the user that is independent of the host or hosts AoR is a name for the user that is independent of the host or hosts
skipping to change at page 4, line 45 skipping to change at page 4, line 45
concepts of such a peer-to-peer overlay, and lists the open questions concepts of such a peer-to-peer overlay, and lists the open questions
that still need to be resolved. As the work proceeds, it is expected that still need to be resolved. As the work proceeds, it is expected
that this document will develop into a high-level architecture that this document will develop into a high-level architecture
document for the solution. document for the solution.
2. High Level Description 2. High Level Description
A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer
fashion for the purpose of enabling real-time communication using the fashion for the purpose of enabling real-time communication using the
Session Initiation Protocol (SIP). Collectively, the nodes in the Session Initiation Protocol (SIP). Collectively, the nodes in the
overlay provide a distributed mechanism for mapping names to network overlay provide a distributed mechanism for mapping names to overlay
locations. This provides for the mapping of Addresses of Record locations. This provides for the mapping of Addresses of Record
(AoRs) to Contact URIs, thereby providing the "location server" (AoRs) to Contact URIs, thereby providing the "location server"
function of [RFC3261]. A P2PSIP Overlay also provides a transport function of [RFC3261]. A P2PSIP Overlay also provides a transport
function by which SIP messages can be transported between any two function by which SIP messages can be transported between any two
nodes in the overlay. nodes in the overlay.
A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers.
The peers in the overlay collectively run a distributed database The peers in the overlay collectively run a distributed database
algorithm. This distributed database algorithm allows data to be algorithm. This distributed database algorithm allows data to be
stored on peers and retrieved in an efficient manner. It may also stored on peers and retrieved in an efficient manner. It may also
skipping to change at page 7, line 23 skipping to change at page 7, line 23
This implies that Peer Protocol connections must be able to traverse This implies that Peer Protocol connections must be able to traverse
NATs. It also means that the peers must collectively provide a NATs. It also means that the peers must collectively provide a
distributed transport function that allows a peer to send a SIP distributed transport function that allows a peer to send a SIP
message to any other peer in the overlay - without this function two message to any other peer in the overlay - without this function two
peers in different IP address spaces might not be able to exchange peers in different IP address spaces might not be able to exchange
SIP messages. SIP messages.
3. Reference Model 3. Reference Model
The following diagram shows a P2PSIP Overlay consisting of a number The following diagram shows a P2PSIP Overlay consisting of a number
of P2PSIP Peers and one P2PSIP Client. It also shows an ordinary SIP of P2PSIP Peers, one P2PSIP Client, and an ordinary SIP UA. It
UA. illustrates a typical P2PSIP overlay but does not limit other
compositions or variations; for example, Proxy Peer P might also talk
to a ordinary SIP proxy as well. The figure is not intended to cover
all possible architecture variations in this document.
--->PSTN --->PSTN
+------+ N +------+ +---------+ / +------+ N +------+ +---------+ /
| | A | | | Gateway |-/ | | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |######## | UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # P2PSIP | Peer | N | Peer | | G | # P2PSIP
| E | A | F | +---------+ # Client | E | A | F | +---------+ # Client
| | T | | # Protocol | | T | | # Protocol
+------+ N +------+ # | +------+ N +------+ # |
# A # | # A # |
skipping to change at page 12, line 22 skipping to change at page 12, line 22
data for the overlay. data for the overlay.
P2PSIP Resource Record: A block of data, stored using distributed P2PSIP Resource Record: A block of data, stored using distributed
database mechanism of the P2PSIP Overlay, that includes database mechanism of the P2PSIP Overlay, that includes
information relevant to a specific resource. We presume that information relevant to a specific resource. We presume that
there may be multiple types of resource records. Some may hold there may be multiple types of resource records. Some may hold
data about Users, and others may hold data about Services, and the data about Users, and others may hold data about Services, and the
working group may define other types. The types, usages, and working group may define other types. The types, usages, and
formats of the records are a question for future study. formats of the records are a question for future study.
P2PSIP Responsible Peer The Peer that is responsible for storing the
Resource Record for a Resource. In the literature, the term "Root
Peer" is also used for this concept.
P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay
peers to share information and organize the P2PSIP Overlay peers to share information and organize the P2PSIP Overlay
Network. Network.
P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients
and P2PSIP Peers. It is used to store and retrieve information and P2PSIP Peers. It is used to store and retrieve information
from the P2P Overlay. The nature of this protocol, and even its from the P2P Overlay. The nature of this protocol, and even its
existence, is under discussion. However, if it exists, it has existence, is under discussion. However, if it exists, it has
been agreed that the Client Protocol is a functional subset of the been agreed that the Client Protocol is a functional subset of the
P2P Peer Protocol, but may differ in syntax and protocol P2P Peer Protocol, but may differ in syntax and protocol
skipping to change at page 23, line 5 skipping to change at page 23, line 5
these UAs into the distributed database, and retrieves contact these UAs into the distributed database, and retrieves contact
information when proxying INVITE messages. information when proxying INVITE messages.
Another example is a peer that has a fully-qualified domain name Another example is a peer that has a fully-qualified domain name
(FQDN) that matches the name of the overlay and acts as a SIP proxy (FQDN) that matches the name of the overlay and acts as a SIP proxy
for calls coming into the overlay. A SIP INVITE addressed to for calls coming into the overlay. A SIP INVITE addressed to
"user@overlay-name" arrives at the peer (using the mechanisms in "user@overlay-name" arrives at the peer (using the mechanisms in
[RFC3263]) and this peer then looks up the user in the distributed [RFC3263]) and this peer then looks up the user in the distributed
database and proxies the call onto it. database and proxies the call onto it.
5.7. Architecture
There has been much debate in the group over what an appropriate
architecture for P2PSIP should be. Currently, the group is
investigating architectures that involve a P2P layer that is distinct
from the applications that run on the overlay.
__________________________
| |
| SIP, other apps... |
| ___________________|
| | P2P Layer |
|______|___________________|
| Transport Layer |
|__________________________|
The P2P layer implements the Peer Protocol (and the Client Protocol,
if such a protocol exists). Applications access this P2P layer for
various overlay-related services. Applications are also free to
bypass this layer and access the existing transport layer protocols
(e.g., TCP, UDP, etc.) directly.
A notable feature of this architecture is that it envisions the use
of protocols other than SIP in the overlay. Though the working group
is primarily focused on the use of SIP in peer-to-peer overlays, this
architecture envisions a future in which other protocols can play a
role.
The group initially considered another architecture. In this
alternative architecture, the Peer Protocol was defined as an
extension to SIP. That is, that the necessary operations for forming
and maintaining the overlay and for storing and retrieving resource
records in the distributed database were defined as extensions to
SIP. Each peer in the overlay was viewed as a SIP proxy that would
forward the overlay maintenance and distributed database query
messages (expressed in SIP) on behalf of other peers.
[I-D.bryan-p2psip-dsip] presents a detailed design, and
[I-D.zangrilli-p2psip-whysip] argues for this general approach.
This architecture was eventually rejected by the working group for
the following reasons:
o The architecture was totally focused on SIP, and made it difficult
to use other protocols in the overlay.
o In SIP, proxies are assumed to be trusted parties. Relying on the
peers to route the message as proxies exposes the SIP messages to
attacks from untrusted proxies that SIP's design does not
anticipate. A design that does not allow the peers to modify the
SIP message and ideally prevents them from reading it is
preferable.
o SIP was seen as a "heavy-weight" protocol for this task. SIP uses
a text-based encoding which is very flexible, but leads to both
large messages and slow processing times at proxies. This was
seen to be a poor match for P2PSIP, where a distributed database
lookup operation requires O(log N) peers to receive, process and
forward the message.
More discussion on this alternate approach and why it was rejected
can be found on the P2PSIP mailing list in a thread that started on
20 March 2007.
6. Additional Questions 6. Additional Questions
This section lists some additional questions that the proposed P2PSIP This section lists some additional questions that the proposed P2PSIP
Working Group may need to consider in the process of defining the Working Group may need to consider in the process of defining the
Peer and Client protocols. Peer and Client protocols.
6.1. Selecting between Multiple Peers offering the Same Service 6.1. Selecting between Multiple Peers offering the Same Service
If a P2PSIP network contains two or more peers that offer the same If a P2PSIP network contains two or more peers that offer the same
service, then how does a peer or client that wishes to use that service, then how does a peer or client that wishes to use that
skipping to change at page 24, line 31 skipping to change at page 25, line 45
2. Can there be names from one domain in more than a single overlay? 2. Can there be names from one domain in more than a single overlay?
If so, how do we route Client/Server SIP requests to the right If so, how do we route Client/Server SIP requests to the right
overlay? overlay?
3. Can the domain of an AoR be in more than one overlay? 3. Can the domain of an AoR be in more than one overlay?
4. Should we have a "default overlay" to search for peers in many 4. Should we have a "default overlay" to search for peers in many
domains? domains?
6.6. Protocol Layering
It is possible to define the overlay operations as extensions to SIP
as proposed in [I-D.bryan-p2psip-dsip] or using a lower level
transport protocol (or distinct P2P protocol layer below SIP) as
described in [I-D.matthews-p2psip-hip-hop], [I-D.bryan-p2psip-reload]
and [I-D.marocco-p2psip-xpp-pcan]. Which is the better or more
appropriate model? It seems that this requires analysis along
several axes, presumably described below in descending order of
priority.:
1. Functionality: Which approach more completely meets the
functional requirements implicit in the conceptual model?
2. Simplicity: Ease of implementation. Which approach can be more
readily turned into running code?
3. Generality: Do we have a requirement to only provide P2P support
for SIP operations, or is it likely that other applications will
need this functionality? If we make SIP work for P2P, will this
increase the pressure on SIP to serve as a general transport
protocol because it solves the rendezvous problem using P2P,
despite the warnings of [RFC4485] about using SIP as a transport
protocol?
4. Efficiency: Which approach produces the lesser loading on the
transport layer, the peers themselves, and other infrastructure?
7. Security Considerations 7. Security Considerations
Building a P2PSIP system has many security considerations, many of Building a P2PSIP system has many security considerations, many of
which we have only begun to consider. We anticipate that the which we have only begun to consider. We anticipate that the
protocol documents describing the actual protocols will deal more protocol documents describing the actual protocols will deal more
thoroughly with security topics. thoroughly with security topics.
One critical security issue that will need to be addressed is One critical security issue that will need to be addressed is
providing for the privacy and integrity of SIP messages being routed providing for the privacy and integrity of SIP messages being routed
by peer nodes, when those peer nodes might well be hostile. This is by peer nodes, when those peer nodes might well be hostile. This is
skipping to change at page 26, line 49 skipping to change at page 27, line 35
11.2. Informative References 11.2. Informative References
[I-D.bryan-p2psip-dsip] [I-D.bryan-p2psip-dsip]
Bryan, D., "dSIP: A P2P Approach to SIP Registration and Bryan, D., "dSIP: A P2P Approach to SIP Registration and
Resource Location", draft-bryan-p2psip-dsip-00 (work in Resource Location", draft-bryan-p2psip-dsip-00 (work in
progress), February 2007. progress), February 2007.
[I-D.bryan-p2psip-reload] [I-D.bryan-p2psip-reload]
Bryan, D., "REsource LOcation And Discovery (RELOAD)", Bryan, D., "REsource LOcation And Discovery (RELOAD)",
draft-bryan-p2psip-reload-00 (work in progress), draft-bryan-p2psip-reload-01 (work in progress),
June 2007. July 2007.
[I-D.iab-nat-traversal-considerations] [I-D.iab-nat-traversal-considerations]
Rosenberg, J., "Considerations for Selection of Techniques Rosenberg, J., "Considerations for Selection of Techniques
for NAT Traversal", for NAT Traversal",
draft-iab-nat-traversal-considerations-00 (work in draft-iab-nat-traversal-considerations-00 (work in
progress), October 2005. progress), October 2005.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT) Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in "Session Traversal Utilities for (NAT) (STUN)",
progress), March 2007. draft-ietf-behave-rfc3489bis-12 (work in progress),
November 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sipping-nat-scenarios] [I-D.ietf-sipping-nat-scenarios]
Boulton, C., "Best Current Practices for NAT Traversal for Boulton, C., "Best Current Practices for NAT Traversal for
SIP", draft-ietf-sipping-nat-scenarios-06 (work in SIP", draft-ietf-sipping-nat-scenarios-07 (work in
progress), March 2007. progress), July 2007.
[I-D.marocco-p2psip-xpp-pcan] [I-D.marocco-p2psip-xpp-pcan]
Marocco, E. and E. Ivov, "XPP Extensions for Implementing Marocco, E. and E. Ivov, "XPP Extensions for Implementing
a Passive P2PSIP Overlay Network based on the CAN a Passive P2PSIP Overlay Network based on the CAN
Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00 Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00
(work in progress), June 2007. (work in progress), June 2007.
[I-D.matthews-p2psip-hip-hop] [I-D.matthews-p2psip-hip-hop]
Cooper, E., "A Distributed Transport Function in P2PSIP Cooper, E., "A Distributed Transport Function in P2PSIP
using HIP for Multi-Hop Overlay Routing", using HIP for Multi-Hop Overlay Routing",
draft-matthews-p2psip-hip-hop-00 (work in progress), draft-matthews-p2psip-hip-hop-00 (work in progress),
June 2007. June 2007.
[I-D.zangrilli-p2psip-whysip]
Zangrilli, M. and B. Lowekamp, "Why SIP should be used for
encoding the P2PSIP Peer Protocol.",
draft-zangrilli-p2psip-whysip-00 (work in progress),
March 2007.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", of Extensions to the Session Initiation Protocol (SIP)",
 End of changes. 21 change blocks. 
55 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/