draft-ietf-p2psip-concepts-01.txt   draft-ietf-p2psip-concepts-02.txt 
P2PSIP Working Group D. Bryan P2PSIP Working Group D. Bryan
Internet-Draft College of William and Mary and Internet-Draft SIPeerior Technologies
Intended status: Informational SIPeerior Technologies Intended status: Informational P. Matthews
Expires: May 18, 2008 P. Matthews Expires: January 8, 2009 Unaffiliated
Avaya
E. Shim E. Shim
Locus Telecommunications Locus Telecommunications
D. Willis D. Willis
Unaffiliated Softarmor Systems
November 15, 2007 S. Dawkins
Huawei (USA)
July 7, 2008
Concepts and Terminology for Peer to Peer SIP Concepts and Terminology for Peer to Peer SIP
draft-ietf-p2psip-concepts-01 draft-ietf-p2psip-concepts-02
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 40 skipping to change at page 1, line 41
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 May 18, 2008. This Internet-Draft will expire on January 8, 2009.
Copyright Notice
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
replaced by a distributed mechanism that might be implemented using a replaced by a distributed mechanism implemented using a distributed
distributed hash table or other distributed data mechanism with hash table or other distributed data mechanism with similar external
similar external properties. This document includes a high-level properties. This document includes a high-level view of the
view of the functional relationships between the network elements functional relationships between the network elements defined herein,
defined herein, a conceptual model of operations, and an outline of a conceptual model of operations, and an outline of the related open
the related open problems being addressed by the P2PSIP working problems being addressed by the P2PSIP working group. As this
group. As this document matures, it is expected to define the document matures, it is expected to define the general framework for
general framework for P2PSIP. P2PSIP.
Table of Contents Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Author's Notes and Changes To This Version . . . . . . . . . . 4
1.1. Author's Notes . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Changes from Previous Version . . . . . . . . . . . . . . 4
2. High Level Description . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Relationship of Peer and Client Protocols . . . . . . . . 6
2.5. Relationship Between P2PSIP and SIP . . . . . . . . . . . 6
2.6. Relationship Between P2PSIP and Other AoR
Dereferencing Approaches . . . . . . . . . . . . . . . . . 6
2.7. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7 3. High Level Description . . . . . . . . . . . . . . . . . . . . 5
3.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Relationship of Peer and Client Protocols . . . . . . . . 7
3.5. Relationship Between P2PSIP and SIP . . . . . . . . . . . 7
3.6. Relationship Between P2PSIP and Other AoR
Dereferencing Approaches . . . . . . . . . . . . . . . . . 7
3.7. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. The Distributed Database Function . . . . . . . . . . . . 13
5.2. Using the Distributed Database Function . . . . . . . . . 15
5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 20
5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 21
5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22
5.7. Architecture . . . . . . . . . . . . . . . . . . . . . . . 23
6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 24 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Selecting between Multiple Peers offering the Same 6.1. The Distributed Database Function . . . . . . . . . . . . 14
Service . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Using the Distributed Database Function . . . . . . . . . 16
6.2. Visibility of Messages to Intermediate Peers . . . . . . . 24 6.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 25 6.4. Locating and Joining an Overlay . . . . . . . . . . . . . 21
6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 25 6.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 22
6.5. Relationships of Domains to Overlays . . . . . . . . . . . 25 6.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22
6.7. Architecture . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Additional Questions . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7.1. Selecting between Multiple Peers offering the Same
Service . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Visibility of Messages to Intermediate Peers . . . . . . . 25
7.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 25
7.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 25
7.5. Relationships of Domains to Overlays . . . . . . . . . . . 25
9. Changes in This Version . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Background 1. Author's Notes and Changes To This Version
1.1. Author's Notes
The editors are currently considering a rather substantial revision
to this document to better reflect the evolving direction of the
working group. This version incorporates only minor revisions from
the -01 version of the document.
In particular, the authors intend to make the following more
substantial changes, and solicit the opinion of the WG on these
changes, as well as to solicit suggestions for text for the new
sections:
o Document the current view of the working group that the protocols
being developed in P2PSIP should be more broadly applicable than
just for peer-to-peer networks of SIP endpoints.
o The authors plan to add a section that documents the history of
various design decisions, and at the same time remove this
discussion from other parts of the text. The authors feel that
this historical information is important, but also feel that a
reader needs to be able to quickly see what the current state of
the P2PSIP work is today. An exception would be an early
explanation of the fact that P2PSIP doesn't use SIP for the peer
protocol, a frequent source of confusion to many people new to the
WG.
o The definition text is somewhat out of date, and should be revised
(with some terms added and others eliminated, as appropriate)
o Incorporate the descriptions of the applications scenarios
currently described in draft-bryan-p2psip-app-scenarios-00 into
this document.
1.2. Changes from Previous Version
Changes to this version include removal of the prefix "P2PSIP" before
each definition, and clarification on the issue of clients,
reflecting the consensus of the WG.
2. 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
where the user can be contacted, while a Contact URI indicates the where the user can be contacted, while a Contact URI indicates the
host where the user can be contacted. host where the user can be contacted.
skipping to change at page 4, line 40 skipping to change at page 5, line 33
registrar nodes but are instead distributed amongst the peers in the registrar nodes but are instead distributed amongst the peers in the
overlay. overlay.
The details of this alternative solution are currently being worked The details of this alternative solution are currently being worked
out in the P2PSIP working group. This document describes the basic out in the P2PSIP working group. This document describes the basic
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 3. 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 overlay 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]. An Overlay also provides a transport function
function by which SIP messages can be transported between any two by which SIP messages can be transported between any two nodes in the
nodes in the overlay. overlay.
A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. A P2PSIP Overlay consists of one or more nodes called Peers. The
The peers in the overlay collectively run a distributed database 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
ensure that a copy of a data item is stored on more than one peer, so ensure that a copy of a data item is stored on more than one peer, so
that the loss of a peer does not result in the loss of the data item that the loss of a peer does not result in the loss of the data item
to the overlay. to the overlay.
One use of this distributed database is to store the information One use of this distributed database is to store the information
required to provide the mapping between AoRs and Contact URIs for the required to provide the mapping between AoRs and Contact URIs for the
distributed location function. This provides a location function distributed location function. This provides a location function
within each overlay that is an alternative to the location functions within each overlay that is an alternative to the location functions
described in [RFC3263]. However, the model of [RFC3263] is used described in [RFC3263]. However, the model of [RFC3263] is used
between overlays. between overlays.
2.1. Services 3.1. Services
The nature of peer-to-peer computing is that each peer offers The nature of peer-to-peer computing is that each peer offers
services to other peers to allow the overlay to collectively provide services to other peers to allow the overlay to collectively provide
larger functions. In P2PSIP, peers offer storage and transport larger functions. In P2PSIP, peers offer storage and transport
services to allow the distributed database function and distributed services to allow the distributed database function and distributed
transport function to be implemented. It is expected that individual transport function to be implemented. It is expected that individual
peers may also offer other services. Some of these additional peers may also offer other services. Some of these additional
services (for example, a STUN server service services (for example, a STUN server service
[I-D.ietf-behave-rfc3489bis]) may be required to allow the overlay to [I-D.ietf-behave-rfc3489bis]) may be required to allow the overlay to
form and operate, while others (for example, a voicemail service) may form and operate, while others (for example, a voicemail service) may
be enhancements to the basic P2PSIP functionality. be enhancements to the basic P2PSIP functionality.
To allow peers to offer these additional services, the distributed To allow peers to offer these additional services, the distributed
database may need to store information about services. For example, database may need to store information about services. For example,
it may need to store information about which peers offer which it may need to store information about which peers offer which
services, and perhaps what sort of capacity each peer has for services, and perhaps what sort of capacity each peer has for
delivering each listed service. delivering each listed service.
2.2. Clients 3.2. Clients
An overlay may or may not also include one or more nodes called An overlay may or may not also include one or more nodes called
P2PSIP Clients. The role of a client in the P2PSIP model is still clients. The role of a client in the P2PSIP model is still under
under discussion, with a number of suggestions for roles being put discussion, with a number of suggestions for roles being put forth.
forth, and some arguing that clients are not needed at all. However, The group has reached consensus that clients will be able to store
if they exist, then people agree that they will also be able to store and retrieve information from the overlay. Section 6.5 discusses the
and retrieve information from the overlay. Section 5.5 discusses the
possible roles of a client in more detail. possible roles of a client in more detail.
2.3. Protocol 3.3. Protocol
Peers in an overlay need to speak some protocol between themselves to Peers in an overlay need to speak some protocol between themselves to
maintain the overlay and to store and retrieve data. Until a better maintain the overlay and to store and retrieve data. Until a better
name is found, this protocol has been dubbed the P2PSIP Peer name is found, this protocol has been dubbed the P2PSIP Peer
Protocol. The details of this protocol are still very much under Protocol. While the use of SIP for this protocol was proposed as the
debate: some have suggested that the protocol should be SIP with some working group was forming, the group is currently working toward a
extensions, while others have suggested that it should be an entirely
new protocol. new protocol.
2.4. Relationship of Peer and Client Protocols 3.4. Relationship of Peer and Client Protocols
If the P2PSIP model also contains clients, then a protocol is needed To allow clients to communicate with peers, another protocol is
for client - peer communication. Until a better name is found, this required. Until a better name is found, this protocol has been
protocol has been dubbed the P2PSIP Client Protocol. The details of dubbed the P2PSIP Client Protocol. The details of this protocol are
this protocol are also very much under debate. However, if the also very much under debate. However, if the client protocol exists,
client protocol exists, then it is agreed that it should be a logical then it is agreed that it should be a logical subset of the peer
subset of the peer protocol. In other words, the syntax of the peer protocol. In other words, the syntax of the peer and client
and client protocols may be completely different, but any operation protocols may be completely different, but any operation supported by
supported by client protocol is also supported by the peer protocol. client protocol is also supported by the peer protocol. This implies
This implies that clients cannot do anything that peers cannot also that clients cannot do anything that peers cannot also do.
do.
2.5. Relationship Between P2PSIP and SIP 3.5. Relationship Between P2PSIP and SIP
Since P2PSIP is about peer-to-peer networks for real-time Since P2PSIP is about peer-to-peer networks for real-time
communication, it is expected that most (if not all) peers and communication, it is expected that most (if not all) peers and
clients will be coupled with SIP entities. For example, one peer clients will be coupled with SIP entities. For example, one peer
might be coupled with a SIP UA, another might be coupled with a SIP might be coupled with a SIP UA, another might be coupled with a SIP
proxy, while a third might be coupled with a SIP-to-PSTN gateway. proxy, while a third might be coupled with a SIP-to-PSTN gateway.
For such nodes, we think of the peer or client portion of the node as For such nodes, we think of the peer or client portion of the node as
being distinct from the SIP entity portion. However, there is no being distinct from the SIP entity portion. However, there is no
hard requirement that every P2PSIP node (peer or client) be coupled hard requirement that every P2PSIP node (peer or client) be coupled
to a SIP entity, and some proposed architectures include peer nodes to a SIP entity, and some proposed architectures include peer nodes
that have no SIP function whatsoever. that have no SIP function whatsoever.
2.6. Relationship Between P2PSIP and Other AoR Dereferencing Approaches 3.6. Relationship Between P2PSIP and Other AoR Dereferencing Approaches
As noted above, the fundamental task of P2PSIP is turning an AoR into As noted above, the fundamental task of P2PSIP is turning an AoR into
a Contact. This task might be approached using zeroconf techniques a Contact. This task might be approached using zeroconf techniques
such as multicast DNS and DNS Service Discovery (as in Apple's such as multicast DNS and DNS Service Discovery (as in Apple's
Bonjour protocol), link-local multicast name resolution [RFC4795], Bonjour protocol), link-local multicast name resolution [RFC4795],
and dynamic DNS [RFC2136]. and dynamic DNS [RFC2136].
These alternatives were discussed in the P2PSIP Working Group, and These alternatives were discussed in the P2PSIP Working Group, and
not pursued as a general solution for a number of reasons related to not pursued as a general solution for a number of reasons related to
scalability, the ability to work in a disconnected state, partition scalability, the ability to work in a disconnected state, partition
recovery, and so on. However, there does seem to be some continuing recovery, and so on. However, there does seem to be some continuing
interest in the possibility of using DNS-SD and mDNS for interest in the possibility of using DNS-SD and mDNS for
bootstrapping of P2PSIP overlays. bootstrapping of P2PSIP overlays.
2.7. NAT Issues 3.7. NAT Issues
Network Address Translators (NATs) are impediments to establishing Network Address Translators (NATs) are impediments to establishing
and maintaining peer-to-peer networks, since NATs hinder direct and maintaining peer-to-peer networks, since NATs hinder direct
communication between peers. Some peer-to-peer network architectures communication between peers. Some peer-to-peer network architectures
avoid this problem by insisting that all peers exist in the same avoid this problem by insisting that all peers exist in the same
address space. However, in the P2PSIP model, it has been agreed that address space. However, in the P2PSIP model, it has been agreed that
peers can live in multiple address spaces interconnected by NATs. peers can live in multiple address spaces interconnected by NATs.
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 4. 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, one P2PSIP Client, and an ordinary SIP UA. It of Peers, one Client, and an ordinary SIP UA. It illustrates a
illustrates a typical P2PSIP overlay but does not limit other typical P2PSIP overlay but does not limit other compositions or
compositions or variations; for example, Proxy Peer P might also talk variations; for example, Proxy Peer P might also talk to a ordinary
to a ordinary SIP proxy as well. The figure is not intended to cover SIP proxy as well. The figure is not intended to cover all possible
all possible architecture variations in this document. 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 8, line 44 skipping to change at page 9, line 44
\__/ / / \__/ / /
/\ / ______________/ SIP /\ / ______________/ SIP
/ \/ / / \/ /
/ UA \/ / UA \/
/______\ /______\
SIP UA A SIP UA A
Figure: P2PSIP Overlay Reference Model Figure: P2PSIP Overlay Reference Model
Here, the large perimeter depicted by "#" represents a stylized view Here, the large perimeter depicted by "#" represents a stylized view
of the P2PSIP Overlay (the actual connections could be a mesh, a of the Overlay (the actual connections could be a mesh, a ring, or
ring, or some other structure). Around the periphery of the P2PSIP some other structure). Around the periphery of the Overlay
Overlay rectangle, we have a number of P2PSIP Peers. Each peer is rectangle, we have a number of Peers. Each peer is labeled with its
labeled with its coupled SIP entity -- for example, "Proxy Peer P" coupled SIP entity -- for example, "Proxy Peer P" means that peer P
means that peer P which is coupled with a SIP proxy. In some cases, which is coupled with a SIP proxy. In some cases, a peer or client
a peer or client might be coupled with two or more SIP entities. In might be coupled with two or more SIP entities. In this diagram we
this diagram we have a PSTN gateway coupled with peer "G", three have a PSTN gateway coupled with peer "G", three peers ("D", "E" and
peers ("D", "E" and "F") which are each coupled with a UA, a peer "P" "F") which are each coupled with a UA, a peer "P" which is coupled
which is coupled with a SIP proxy, an ordinary peer "Q", and one peer with a SIP proxy, an ordinary peer "Q", and one peer "R" which is
"R" which is coupled with a SIP Redirector. Note that because these coupled with a SIP Redirector. Note that because these are all
are all P2PSIP Peers, each is responsible for storing P2PSIP Resource Peers, each is responsible for storing Resource Records and
Records and transporting messages around the P2PSIP Overlay. transporting messages around the Overlay.
To the left, two of the peers ("D" and "E") are behind network To the left, two of the peers ("D" and "E") are behind network
address translators (NATs). These peers are included in the P2PSIP address translators (NATs). These peers are included in the P2PSIP
overlay and thus participate in storing resource records and routing overlay and thus participate in storing resource records and routing
messages, despite being behind the NATs. messages, despite being behind the NATs.
Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is Below the Overlay, we have a conventional SIP UA "A" which is not
not part of the P2PSIP Overlay, either directly as a peer or part of the Overlay, either directly as a peer or indirectly as a
indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP client. It speaks neither the Peer nor Client protocols. Instead,
Client protocols. Instead, it uses SIP to interact with the P2PSIP it uses SIP to interact with the Overlay.
Overlay.
On the right side, we have a P2PSIP client "C", which uses the P2PSIP On the right side, we have a client "C", which uses the Client
Client Protocol depicted by "=" to communicate with Proxy Peer "Q". Protocol depicted by "=" to communicate with Proxy Peer "Q". The
The P2PSIP client "C" could communicate with a different peer, for Client "C" could communicate with a different peer, for example peer
example peer "F", if it establishes a connection to "F" instead of or "F", if it establishes a connection to "F" instead of or in addition
in addition to "Q". The exact role that this client plays in the to "Q". The exact role that this client plays in the network is
network is still under discussion (see Section 5.5). still under discussion (see Section 6.5).
Both the SIP proxy coupled with peer "P" and the SIP redirector Both the SIP proxy coupled with peer "P" and the SIP redirector
coupled with peer "R" can serve as adapters between ordinary SIP coupled with peer "R" can serve as adapters between ordinary SIP
devices and the P2PSIP Overlay. Each accepts standard SIP requests devices and the Overlay. Each accepts standard SIP requests and
and resolves the next-hop by using the P2PSIP overlay Peer Protocol resolves the next-hop by using the P2PSIP overlay Peer Protocol to
to interact with the routing knowledge of the P2PSIP Overlay, then interact with the routing knowledge of the Overlay, then processes
processes the SIP requests as appropriate (proxying or redirecting the SIP requests as appropriate (proxying or redirecting towards the
towards the next-hop). Note that proxy operation is bidirectional - next-hop). Note that proxy operation is bidirectional - the proxy
the proxy may be forwarding a request from an ordinary SIP device to may be forwarding a request from an ordinary SIP device to the
the P2PSIP overlay, or from the P2PSIP overlay to an ordinary SIP Overlay, or from the P2PSIP overlay to an ordinary SIP device.
device.
The PSTN Gateway at peer "G" provides a similar sort of adaptation to The PSTN Gateway at peer "G" provides a similar sort of adaptation to
and from the public switched telephone network (PSTN). and from the public switched telephone network (PSTN).
4. Definitions 5. Definitions
This section defines a number of concepts that are key to This section defines a number of concepts that are key to
understanding the P2PSIP work. understanding the P2PSIP work.
Overlay Network: An overlay network is a computer network which is Overlay Network: An overlay network is a computer network which is
built on top of another network. Nodes in the overlay can be built on top of another network. Nodes in the overlay can be
thought of as being connected by virtual or logical links, each of thought of as being connected by virtual or logical links, each of
which corresponds to a path, perhaps through many physical links, which corresponds to a path, perhaps through many physical links,
in the underlying network. For example, many peer-to-peer in the underlying network. For example, many peer-to-peer
networks are overlay networks because they run on top of the networks are overlay networks because they run on top of the
skipping to change at page 10, line 32 skipping to change at page 11, line 30
P2PSIP: A suite of communications protocols related to the Session P2PSIP: A suite of communications protocols related to the Session
Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer- Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer-
to-peer techniques for resolving the targets of SIP requests, to-peer techniques for resolving the targets of SIP requests,
providing SIP message transport, and providing other SIP-related providing SIP message transport, and providing other SIP-related
functions. The exact contents of this protocol suite are still functions. The exact contents of this protocol suite are still
under discussion, but is likely to include the P2PSIP Peer under discussion, but is likely to include the P2PSIP Peer
Protocol and may include a P2PSIP Client Protocol (see definitions Protocol and may include a P2PSIP Client Protocol (see definitions
below). below).
P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or User: A human that interacts with the overlay through SIP UAs
federation of nodes that provides SIP registration, SIP message located on peers and clients (and perhaps other ways).
transport, and similar functions using a P2P organization, as
defined by "P2P Network" above.
P2PSIP Overlay Name: A human-friendly name that identifies a The following terms are defined here only within the scope of
specific P2PSIP Overlay. This is in the format of (a portion of) P2PSIP. These terms may have conflicting definitions in other
a URI, but may or may not have a related record in the DNS. bodies of literature. Some earlier versions of this document
prefixed each term with "P2PSIP" to clarify the term's scope.
This prefixing has been eliminated from the text; however the
scoping still applies.
P2PSIP Peer: A node participating in a P2PSIP Overlay that provides Overlay Name: A human-friendly name that identifies a specific
storage and transport services to other nodes in that P2PSIP P2PSIP Overlay. This is in the format of (a portion of) a URI,
Overlay. Each P2PSIP Peer has a unique identifier, known as a but may or may not have a related record in the DNS.
Peer-ID, within the P2PSIP Overlay. Each P2PSIP Peer may be
coupled to one or more SIP entities. Within the P2PSIP Overlay,
the peer is capable of performing several different operations,
including: joining and leaving the overlay, transporting SIP
messages within the overlay, storing information on behalf of the
overlay, putting information into the overlay, and getting
information from the overlay.
P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP Peer: A node participating in a P2PSIP Overlay that provides storage
Peer within a given P2PSIP Overlay. This value is not human- and transport services to other nodes in that P2PSIP Overlay.
friendly -- in a DHT approach, this is a numeric value in the hash Each Peer has a unique identifier, known as a Peer-ID, within the
space. These Peer-IDs are completely independent of the Overlay. Each Peer may be coupled to one or more SIP entities.
identifier of any user of a user agent associated with a peer. Within the Overlay, the peer is capable of performing several
(Note: This is often called a "Node-ID" in the P2P literature). different operations, including: joining and leaving the overlay,
transporting SIP messages within the overlay, storing information
on behalf of the overlay, putting information into the overlay,
and getting information from the overlay.
P2PSIP Client: A node participating in a P2PSIP Overlay that is less Peer-ID: Information that uniquely identifies each Peer within a
capable than a P2PSIP Peer in some way. The role of a P2PSIP given Overlay. This value is not human-friendly -- in a DHT
Client is still under debate, with a number of competing approach, this is a numeric value in the hash space. These Peer-
proposals, and some have suggested removing the concept entirely IDs are completely independent of the identifier of any user of a
(see the discussion on this later in the document). If clients user agent associated with a peer. (Note: This is often called a
exist, then it has been agreed that they do have the ability to "Node-ID" in the P2P literature).
add, modify, inspect, and delete information in the overlay. Note
that the term client does not imply that this node is a SIP UAC.
Some have suggested that the word 'client' be changed to something
else to avoid both this confusion and the implication of a client-
server relationship.
User: A human that interacts with the overlay through SIP UAs Client: A node participating in a P2PSIP Overlay that is less
located on peers and clients (and perhaps other ways). capable than a Peer in some way. The role of a Client is still
under debate, with a number of competing proposals (see the
discussion on this later in the document). It has been agreed
that they do have the ability to add, modify, inspect, and delete
information in the overlay. Note that the term client does not
imply that this node is a SIP UAC. Some have suggested that the
word 'client' be changed to something else to avoid both this
confusion and the implication of a client-server relationship.
P2PSIP User Name: A human-friendly name for a user. This name must User Name: A human-friendly name for a user. This name must be
be unique within the overlay, but may be unique in a wider scope. unique within the overlay, but may be unique in a wider scope.
User Names are formatted so that they can be used within a URI User Names are formatted so that they can be used within a URI
(likely a SIP URI), perhaps in combination with the Overlay Name. (likely a SIP URI), perhaps in combination with the Overlay Name.
P2PSIP Service: A capability contributed by a peer to an overlay or Service: A capability contributed by a peer to an overlay or to the
to the members of an overlay. It is expected that not all peers members of an overlay. It is expected that not all peers and
and clients will offer the same set of services, so a means of clients will offer the same set of services, so a means of finding
finding peers (and perhaps clients) that offer a particular peers (and perhaps clients) that offer a particular service is
service is required. Services might include routing of requests, required. Services might include routing of requests, storing of
storing of routing data, storing of other data, STUN discovery, routing data, storing of other data, STUN discovery, STUN relay,
STUN relay, and many other things. This model posits a and many other things. This model posits a requirement for a
requirement for a service locator function, possibly including service locator function, possibly including supporting
supporting information such as the capacity of a peer to provide a information such as the capacity of a peer to provide a specific
specific service or descriptions of the policies under which a service or descriptions of the policies under which a peer will
peer will provide that service. We currently expect that we will provide that service. We currently expect that we will need to be
need to be able to search for available service providers within able to search for available service providers within each
each overlay. We think we might need to be able to make searches overlay. We think we might need to be able to make searches based
based on network locality or path minimalization. on network locality or path minimalization.
P2PSIP Service Name: A unique, human-friendly, name for a service. Service Name: A unique, human-friendly, name for a service.
P2PSIP Resource: Anything about which information can be stored in Resource: Anything about which information can be stored in the
the overlay. Both Users and Services are examples of Resources. overlay. Both Users and Services are examples of Resources.
P2PSIP Resource-ID: A non-human-friendly value that uniquely Resource-ID: A non-human-friendly value that uniquely identifies a
identifies a resource and which is used as a key for storing and resource and which is used as a key for storing and retrieving
retrieving data about the resource. One way to generate a data about the resource. One way to generate a Resource-ID is by
Resource-ID is by applying a mapping function to some other unique applying a mapping function to some other unique name (e.g., User
name (e.g., User Name or Service Name) for the resource. The Name or Service Name) for the resource. The Resource-ID is used
Resource-ID is used by the distributed database algorithm to by the distributed database algorithm to determine the peer or
determine the peer or peers that are responsible for storing the peers that are responsible for storing the data for the overlay.
data for the overlay.
P2PSIP Resource Record: A block of data, stored using distributed Resource Record: A block of data, stored using distributed database
database mechanism of the P2PSIP Overlay, that includes mechanism of the Overlay, that includes information relevant to a
information relevant to a specific resource. We presume that specific resource. We presume that there may be multiple types of
there may be multiple types of resource records. Some may hold resource records. Some may hold data about Users, and others may
data about Users, and others may hold data about Services, and the hold data about Services, and the working group may define other
working group may define other types. The types, usages, and types. The types, usages, and formats of the records are a
formats of the records are a question for future study. question for future study.
P2PSIP Responsible Peer The Peer that is responsible for storing the Responsible Peer The Peer that is responsible for storing the
Resource Record for a Resource. In the literature, the term "Root Resource Record for a Resource. In the literature, the term "Root
Peer" is also used for this concept. Peer" is also used for this concept.
P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay Peer Protocol: The protocol spoken between P2PSIP Overlay peers to
peers to share information and organize the P2PSIP Overlay share information and organize the P2PSIP Overlay Network.
Network.
P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients Client Protocol: The protocol spoken between Clients and Peers. It
and P2PSIP Peers. It is used to store and retrieve information is used to store and retrieve information from the P2P Overlay.
from the P2P Overlay. The nature of this protocol, and even its The nature of this protocol, and even its existence, is under
existence, is under discussion. However, if it exists, it has discussion. However, if it exists, it has been agreed that the
been agreed that the Client Protocol is a functional subset of the Client Protocol is a functional subset of the P2P Peer Protocol,
P2P Peer Protocol, but may differ in syntax and protocol but may differ in syntax and protocol implementation (i.e., may
implementation (i.e., may not be syntactically related). not be syntactically related).
P2PSIP Peer Protocol Connection / P2PSIP Client Protocol Connection: Peer Protocol Connection / P2PSIP Client Protocol Connection: The
The TCP, UDP or other transport layer protocol connection over TCP, UDP or other transport layer protocol connection over which
which the P2PSIP Peer Protocol (or respectively the Client the Peer Protocol (or respectively the Client protocol) is
protocol) is transported. transported.
P2PSIP Neighbors: The set of P2PSIP Peers that either a P2PSIP Peer Neighbors: The set of P2PSIP Peers that either a Peer or Client know
or P2PSIP Client know of directly and can reach without further of directly and can reach without further lookups.
lookups.
P2PSIP Joining Peer: A node that is attempting to become a P2PSIP Joining Peer: A node that is attempting to become a Peer in a
Peer in a particular P2PSIP Overlay. particular Overlay.
P2PSIP Bootstrap Peer: A P2PSIP Peer in the P2PSIP Overlay that is Bootstrap Peer: A Peer in the Overlay that is the first point of
the first point of contact for a P2PSIP Joining Peer. It selects contact for a Joining Peer. It selects the peer that will serve
the peer that will serve as the P2PSIP Admitting Peer and helps as the Admitting Peer and helps the joining peer contact the
the joining peer contact the admitting peer. admitting peer.
P2PSIP Admitting Peer: A P2PSIP Peer in the P2PSIP Overlay which Admitting Peer: A Peer in the Overlay which helps the Joining Peer
helps the P2PSIP Joining Peer join the Overlay. The choice of the join the Overlay. The choice of the admitting peer may depend on
admitting peer may depend on the joining peer (e.g., depend the the joining peer (e.g., depend on the joining peer's Peer-ID).
joining peer's P2PSIP Peer-ID). For example, the admitting peer For example, the admitting peer might be chosen as the peer which
might be chosen as the peer which is "closest" in the logical is "closest" in the logical structure of the overlay to the future
structure of the overlay to the future position of the joining position of the joining peer. The selection of the admitting peer
peer. The selection of the admitting peer is typically done by is typically done by the bootstrap peer. It is allowable for the
the bootstrap peer. It is allowable for the bootstrap peer to bootstrap peer to select itself as the admitting peer.
select itself as the admitting peer.
P2PSIP Bootstrap Server: A network node used by P2PSIP Joining Peers Bootstrap Server: A network node used by Joining Peers to locate a
to locate a P2PSIP Bootstrap Peer. Typically, a P2PSIP Bootstrap Bootstrap Peer. A Bootstrap Server may act as a proxy for
Server acts as a proxy for messages between the P2PSIP Joining messages between the Joining Peer and the Bootstrap Peer. The
Peer and the P2PSIP Bootstrap Peer. The P2PSIP Bootstrap Server Bootstrap Server itself is typically a stable host with a DNS name
itself is typically a stable host with a DNS name that is somehow that is somehow communicated (for example, through configuration)
communicated (for example, through configuration) to peers that to peers that want to join the overlay. A Bootstrap Server is NOT
want to join the overlay. A P2PSIP Bootstrap Server is NOT
required to be a peer or client, though it may be if desired. required to be a peer or client, though it may be if desired.
P2PSIP Peer Admission: The act of admitting a node (the "P2PSIP Peer Admission: The act of admitting a node (the "Joining Peer")
Joining Peer") into a P2PSIP Overlay as a P2PSIP Peer. After the into an Overlay as a Peer. After the admission process is over,
admission process is over, the joining peer is a fully-functional the joining peer is a fully-functional peer of the overlay.
peer of the overlay. During the admission process, the joining During the admission process, the joining peer may need to present
peer may need to present credentials to prove that it has credentials to prove that it has sufficient authority to join the
sufficient authority to join the overlay. overlay.
P2PSIP Resource Record Insertion: The act of inserting a P2PSIP Resource Record Insertion: The act of inserting a P2PSIP Resource
Resource Record into the distributed database. Following Record into the distributed database. Following insertion, the
insertion, the data will be stored at one or more peers. The data data will be stored at one or more peers. The data can be
can be retrieved or updated using the P2PSIP Resource-ID as a key. retrieved or updated using the Resource-ID as a key.
5. Discussion 6. Discussion
5.1. The Distributed Database Function 6.1. The Distributed Database Function
A P2PSIP Overlay functions as a distributed database. The database A P2PSIP Overlay functions as a distributed database. The database
serves as a way to store information about things called Resources. serves as a way to store information about things called Resources.
A piece of information, called a Resource Record, can be stored by A piece of information, called a Resource Record, can be stored by
and retrieved from the database using a key associated with the and retrieved from the database using a key associated with the
Resource Record called its Resource-ID. Each Resource must have a Resource Record called its Resource-ID. Each Resource must have a
unique Resource-ID. In addition to uniquely identifying the unique Resource-ID. In addition to uniquely identifying the
Resource, the Resource-ID is also used by the distributed database Resource, the Resource-ID is also used by the distributed database
algorithm to determine the peer or peers that store the Resource algorithm to determine the peer or peers that store the Resource
Record in the overlay. Record in the overlay.
skipping to change at page 15, line 20 skipping to change at page 16, line 8
acceptable format for each. To ensure interoperability, it is acceptable format for each. To ensure interoperability, it is
expected that at least one of these formats will be specified as expected that at least one of these formats will be specified as
"mandatory-to-implement". "mandatory-to-implement".
A class of algorithms known as Distributed Hash Tables A class of algorithms known as Distributed Hash Tables
<http://en.wikipedia.org/wiki/P2P_overlay> are one way to implement <http://en.wikipedia.org/wiki/P2P_overlay> are one way to implement
the Distributed Database. In particular, both the Chord and Bamboo the Distributed Database. In particular, both the Chord and Bamboo
algorithms have been suggested as good choices for the distributed algorithms have been suggested as good choices for the distributed
database algorithm. However, no decision has been taken so far. database algorithm. However, no decision has been taken so far.
5.2. Using the Distributed Database Function 6.2. Using the Distributed Database Function
There are a number of ways the distributed database described in the There are a number of ways the distributed database described in the
previous section might be used to establish multimedia sessions using previous section might be used to establish multimedia sessions using
SIP. In this section, we give four possibilities as examples. It SIP. In this section, we give four possibilities as examples. It
seems likely that the working group will standardize at least one way seems likely that the working group will standardize at least one way
(not necessarily one of the four listed here), but no decisions have (not necessarily one of the four listed here), but no decisions have
been taken yet. been taken yet.
The first option is to store the contact information for a user in The first option is to store the contact information for a user in
the resource record for the user. A peer Y that is a contact point the resource record for the user. A peer Y that is a contact point
skipping to change at page 18, line 29 skipping to change at page 19, line 29
| INVITE(To:U) | | | | INVITE(To:U) | | |
|---------------->| INVITE(To:U) | | |---------------->| INVITE(To:U) | |
| |--------------------------------->| | |--------------------------------->|
| | | INVITE(To:U) | | | | INVITE(To:U) |
| | |<----------------| | | |<----------------|
| | | | | | | |
The pros and cons of option 1 and 3 are briefly discussed in The pros and cons of option 1 and 3 are briefly discussed in
[Using-an-External-DHT]. [Using-an-External-DHT].
5.3. NAT Traversal 6.3. NAT Traversal
Two approaches to NAT Traversal for P2PSIP Peer Protocol have been Two approaches to NAT Traversal for P2PSIP Peer Protocol have been
suggested. The working group has not made any decision yet on the suggested. The working group has not made any decision yet on the
approach that will be selected. approach that will be selected.
The first, the traditional approach adopted by most peer-to-peer The first, the traditional approach adopted by most peer-to-peer
networks today, divides up the peers in the network into two groups: networks today, divides up the peers in the network into two groups:
those with public IP addresses and those without. The networks then those with public IP addresses and those without. The networks then
select a subset of the former group and elevate them to "super peer" select a subset of the former group and elevate them to "super peer"
status, leaving the remaining peers as "ordinary peers". Since super status, leaving the remaining peers as "ordinary peers". Since super
skipping to change at page 20, line 6 skipping to change at page 21, line 6
and Client Protocol connections: this could be done either by and Client Protocol connections: this could be done either by
encapsulating the SIP messages inside Peer and Client Protocol encapsulating the SIP messages inside Peer and Client Protocol
messages or by multiplexing SIP with the Peer (resp.Client) Protocol messages or by multiplexing SIP with the Peer (resp.Client) Protocol
on a Peer (resp. Client) Protocol connection. on a Peer (resp. Client) Protocol connection.
Finally, it should be noted that the NAT traversal problem for media Finally, it should be noted that the NAT traversal problem for media
connections signaled using SIP is outside the scope of the P2PSIP connections signaled using SIP is outside the scope of the P2PSIP
working group. As discussed in [I-D.ietf-sipping-nat-scenarios], the working group. As discussed in [I-D.ietf-sipping-nat-scenarios], the
current recommendation is to use ICE. current recommendation is to use ICE.
5.4. Locating and Joining an Overlay 6.4. Locating and Joining an Overlay
Before a peer can attempt to join a P2PSIP overlay, it must first Before a peer can attempt to join a P2PSIP overlay, it must first
obtain a Peer-ID and optionally a set of credentials. The Peer-ID is obtain a Peer-ID and optionally a set of credentials. The Peer-ID is
an identifier that will uniquely identify the peer within the an identifier that will uniquely identify the peer within the
overlay, while the credentials show that the peer is allowed to join overlay, while the credentials show that the peer is allowed to join
the overlay. the overlay.
The P2PSIP WG will not standardize how the peer-ID and the The P2PSIP WG will not standardize how the peer-ID and the
credentials are obtained, but merely standardize at least one credentials are obtained, but merely standardize at least one
acceptable format for each. To ensure interoperability, it is acceptable format for each. To ensure interoperability, it is
skipping to change at page 21, line 16 skipping to change at page 22, line 16
whatever else is required to help the joining peer become a fully- whatever else is required to help the joining peer become a fully-
functional peer. The details of how this is done will depend on the functional peer. The details of how this is done will depend on the
distributed database algorithm used in the overlay. distributed database algorithm used in the overlay.
At various stages in this process, the joining peer may be asked to At various stages in this process, the joining peer may be asked to
present its credentials to show that it is authorized to join the present its credentials to show that it is authorized to join the
overlay. Similarly, the various peers contacted may be asked to overlay. Similarly, the various peers contacted may be asked to
present their credentials so the joining peer can verify that it is present their credentials so the joining peer can verify that it is
really joining the overlay it wants to. really joining the overlay it wants to.
5.5. Possible Client Behavior 6.5. Possible Client Behavior
As mentioned above, a number of people have proposed a second type of As mentioned above, a number of people have proposed a second type of
P2PSIP entity, known as a "P2PSIP client". The question of whether P2PSIP entity, known as a "P2PSIP client". The consensus of the
the concept of a "client" is needed and, if it is needed, its exact group is that the need for entities to store and retrieve information
nature, is still very much under debate. This section presents some from the Overlay without participating is recognized, but that for
of the alternatives that have been suggested for the possible role of now, little time will spent. This section presents some of the
a client. alternatives that have been suggested for the possible role of a
client.
In one approach, a client interacts with the P2PSIP overlay through In one approach, a client interacts with the P2PSIP overlay through
an associated peer (or perhaps several such peers) using the Client an associated peer (or perhaps several such peers) using the Client
Protocol. The client does not run the distributed database Protocol. The client does not run the distributed database
algorithm, does not store resource records, and is not involved in algorithm, does not store resource records, and is not involved in
routing messages to other peers or clients. Through interactions routing messages to other peers or clients. Through interactions
with its associated peer, a client can insert, modify, examine, and with its associated peer, a client can insert, modify, examine, and
remove resource records. A client can also send SIP messages to its remove resource records. A client may also send SIP messages to its
associated peer for routing through the overlay. In this approach, a associated peer for routing through the overlay. In this approach, a
client is a node that wants to take advantage of the overlay, but is client is a node that wants to take advantage of the overlay, but is
unable or unwilling to contribute resources back to the overlay. unable or unwilling to contribute resources back to the overlay.
This may be achieved using a subset of the Peer Protocol. Such a
device need not speak SIP.
One way to realize this alternative is for a peer to behave as a For SIP devices, another way to realize this functionality is for a
[RFC3261] proxy/registrar. Clients then use standard SIP mechanisms Peer to behave as a [RFC3261] proxy/registrar. SIP devices then use
to add, update, and remove registrations and to send SIP messages to standard SIP mechanisms to add, update, and remove registrations and
peers and other clients. If this is done, there is no need for a to send SIP messages to peers and other clients. The authors here
separate Client Protocol and no need for P2PSIP to define a distinct refer to these devices simply as a "SIP UA", not a "P2PSIP Client",
"P2PSIP Client" concept. to distinguish it from the concept described above.
In a second alternative, a client behaves in a way similar to the way
described in first alternative, except that it does store resource
records. In essence, the client contributes its storage capacity to
its associated peer. A peer which needs to store a resource record
may elect to store this on one or more of its associated clients
instead, thus boosting its effective storage capacity.
In a third alternative, a client acts almost the same as a peer,
except that it does not store any resource records. In this
alternative, a client has a "peer-ID" and joins the overlay in the
same way as a peer, perhaps establishing the same network of
connections that a peer would. Clients participate in the
distributed database algorithm, and can help in transporting messages
to other peers and clients. However, the distributed database
algorithm does not assign resource records to clients. The role of a
client in this model has been described as "a peer with bad memory".
Another way to look at this distinction is that a client is simply a
peer that is not currently offering some or all services to the
overlay, possibly due to a run-time decision about available
resources such as bandwidth or storage capacity. With this approach,
the distinction between client and peer becomes much less distinct,
and probably eliminates the requirement to have two distinct terms
for the roles. Rather, we might speak in terms such as "high-
function" vs "low-function" peers. This approach would also seem to
eliminate the requirement for a distinct P2PSIP Client Protocol.
It has also been proposed that the client role could be fulfilled by
conventional SIP UAs served by a peer that is also acting as a proxy/
registrar. While this might fulfill the requirement, the authors
contend that such as device is a "SIP UA", not a "P2PSIP Client" as
defined in this document, and that exclusively using SIP UAs in this
role eliminates the need for P2PSIP Clients and P2PSIP Client
Protocol from the architecture.
5.6. Interacting with non-P2PSIP entities 6.6. Interacting with non-P2PSIP entities
It is possible for network nodes that are not peers or clients to It is possible for network nodes that are not peers or clients to
interact with a P2PSIP overlay. Such nodes would do this through interact with a P2PSIP overlay. Such nodes would do this through
mechanisms not defined by the P2PSIP working group provided they can mechanisms not defined by the P2PSIP working group provided they can
find a peer or client that supports that mechanism and which will do find a peer or client that supports that mechanism and which will do
any related P2PSIP operations necessary. In this section, we briefly any related P2PSIP operations necessary. In this section, we briefly
describe two ways this might be done. (Note that these are just describe two ways this might be done. (Note that these are just
examples and the descriptions here are not recommendations). examples and the descriptions here are not recommendations).
One example is a peer that also acts as a standard SIP proxy and One example is a peer that also acts as a standard SIP proxy and
skipping to change at page 23, line 5 skipping to change at page 23, line 21
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 6.7. Architecture
There has been much debate in the group over what an appropriate There has been much debate in the group over what an appropriate
architecture for P2PSIP should be. Currently, the group is architecture for P2PSIP should be. Currently, the group is
investigating architectures that involve a P2P layer that is distinct investigating architectures that involve a P2P layer that is distinct
from the applications that run on the overlay. from the applications that run on the overlay.
__________________________ __________________________
| | | |
| SIP, other apps... | | SIP, other apps... |
| ___________________| | ___________________|
| | P2P Layer | | | P2P Layer |
skipping to change at page 23, line 40 skipping to change at page 24, line 8
role. role.
The group initially considered another architecture. In this The group initially considered another architecture. In this
alternative architecture, the Peer Protocol was defined as an alternative architecture, the Peer Protocol was defined as an
extension to SIP. That is, that the necessary operations for forming extension to SIP. That is, that the necessary operations for forming
and maintaining the overlay and for storing and retrieving resource and maintaining the overlay and for storing and retrieving resource
records in the distributed database were defined as extensions to records in the distributed database were defined as extensions to
SIP. Each peer in the overlay was viewed as a SIP proxy that would SIP. Each peer in the overlay was viewed as a SIP proxy that would
forward the overlay maintenance and distributed database query forward the overlay maintenance and distributed database query
messages (expressed in SIP) on behalf of other peers. 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 This architecture was eventually rejected by the working group for
the following reasons: the following reasons:
o The architecture was totally focused on SIP, and made it difficult o The architecture was totally focused on SIP, and made it difficult
to use other protocols in the overlay. to use other protocols in the overlay.
o In SIP, proxies are assumed to be trusted parties. Relying on the 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 peers to route the message as proxies exposes the SIP messages to
attacks from untrusted proxies that SIP's design does not attacks from untrusted proxies that SIP's design does not
skipping to change at page 24, line 18 skipping to change at page 24, line 33
a text-based encoding which is very flexible, but leads to both a text-based encoding which is very flexible, but leads to both
large messages and slow processing times at proxies. This was large messages and slow processing times at proxies. This was
seen to be a poor match for P2PSIP, where a distributed database seen to be a poor match for P2PSIP, where a distributed database
lookup operation requires O(log N) peers to receive, process and lookup operation requires O(log N) peers to receive, process and
forward the message. forward the message.
More discussion on this alternate approach and why it was rejected 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 can be found on the P2PSIP mailing list in a thread that started on
20 March 2007. 20 March 2007.
6. Additional Questions 7. 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 7.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
service select the peer to use? This question comes up in a number service select the peer to use? This question comes up in a number
of contexts: of contexts:
o When two or more peers are willing to serve as a STUN Relay, how o When two or more peers are willing to serve as a STUN Relay, how
do we select a peer that is close in the netpath sense and is do we select a peer that is close in the netpath sense and is
otherwise appropriate for the call? otherwise appropriate for the call?
o When two or more peers are willing to serve as PSTN gateways, how o When two or more peers are willing to serve as PSTN gateways, how
do we select an appropriate gateway for a call that is both do we select an appropriate gateway for a call that is both
netpath efficient and provides good quality or inexpensive PSTN netpath efficient and provides good quality or inexpensive PSTN
routing? routing?
It has been suggested that, at least initially, the working group It has been suggested that, at least initially, the working group
should restrict itself to defining a mechanism that can return a list should restrict itself to defining a mechanism that can return a list
of peers offering a service and not define the mechanism for of peers offering a service and not define the mechanism for
selecting a peer from that list. selecting a peer from that list.
skipping to change at page 24, line 45 skipping to change at page 25, line 14
o When two or more peers are willing to serve as PSTN gateways, how o When two or more peers are willing to serve as PSTN gateways, how
do we select an appropriate gateway for a call that is both do we select an appropriate gateway for a call that is both
netpath efficient and provides good quality or inexpensive PSTN netpath efficient and provides good quality or inexpensive PSTN
routing? routing?
It has been suggested that, at least initially, the working group It has been suggested that, at least initially, the working group
should restrict itself to defining a mechanism that can return a list should restrict itself to defining a mechanism that can return a list
of peers offering a service and not define the mechanism for of peers offering a service and not define the mechanism for
selecting a peer from that list. selecting a peer from that list.
6.2. Visibility of Messages to Intermediate Peers 7.2. Visibility of Messages to Intermediate Peers
When transporting SIP messages through the overlay, are the headers When transporting SIP messages through the overlay, are the headers
and/or bodies of the SIP messages visible to the peers that the and/or bodies of the SIP messages visible to the peers that the
messages happen to pass through? If they are, what types of security messages happen to pass through? If they are, what types of security
risks does this pose in the presence of peers that have been risks does this pose in the presence of peers that have been
compromised in some way? compromised in some way?
6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA 7.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA
If a given UA is capable of operating in both P2PSIP and conventional If a given UA is capable of operating in both P2PSIP and conventional
SIP modalities (especially simultaneously), is it possible for it to SIP modalities (especially simultaneously), is it possible for it to
use and respond to the same AOR using both conventional and P2PSIP? use and respond to the same AOR using both conventional and P2PSIP?
An example of such a topology might be a UA that registers an AOR An example of such a topology might be a UA that registers an AOR
(say, "sip:alice@example.com") conventionally with a registrar and (say, "sip:alice@example.com") conventionally with a registrar and
then inserts a resource record for that resource into a P2PSIP then inserts a resource record for that resource into a P2PSIP
topology, such that both conventional SIP users and P2PSIP users topology, such that both conventional SIP users and P2PSIP users
(within the overlay or a federation thereof) would be able to contact (within the overlay or a federation thereof) would be able to contact
the user without necessarily traversing some sort of gateway. Is the user without necessarily traversing some sort of gateway. Is
this something that we want to make work? this something that we want to make work?
6.4. Clients, Peers, and Services 7.4. Clients, Peers, and Services
1. Do all peers providing routing, storage, and all other services, 1. Do all peers providing routing, storage, and all other services,
or do only some peers provide certain services? or do only some peers provide certain services?
2. What services, if any, must all peers provide? 2. What services, if any, must all peers provide?
3. Do we need clients as a discrete class, or do SIP UAs and/or low- 3. How we can we describe the capacity of a peer for delivering a
function peers completely satisfy the requirements?
4. How we can we describe the capacity of a peer for delivering a
given service? given service?
6.5. Relationships of Domains to Overlays 7.5. Relationships of Domains to Overlays
1. Can there be names from more than one domain in a single overlay? 1. Can there be names from more than one domain in a single overlay?
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?
7. Security Considerations 8. 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
a departure from Client/Server SIP, where the proxies are generally a departure from Client/Server SIP, where the proxies are generally
operated by enterprises or service providers with whom the users of operated by enterprises or service providers with whom the users of
SIP UAs have a trust relationship. SIP UAs have a trust relationship.
8. IANA Considerations 9. IANA Considerations
This document presently raises no IANA considerations. This document presently raises no IANA considerations.
9. Changes in This Version
1. Revised "Open Questions" to reflect current discussion.
2. Resolved conflict between "services provided by overlay" and
"named services provided by peers" by calling all overlay-level
operations "functions". Thus, we would now speak of an overlay
providing a "distributed transport function".
3. Resolved open issue "Does P2PSIP provide a distributed location
function or an alternative mechanism to RFC 3263? The answer
seems to be both, but what is the relationship between these?" by
documenting that each overlay provides an alternative to
[RFC3263] within that overlay, but that [RFC3263] is used in the
conventional manner between overlays.
4. Revised abstract to include SIP message routing within the scope.
5. Added brief mention of peer's capacity for services offered in
overview section on distributed database.
6. Revised definition of P2PSIP Service.
7. Revised abstract and high level discussion.
8. Added discussion of proposed peer models and relationship to SIP
UAs.
9. Revised reference model diagram to clarify client behavior.
10. Acknowledgements 10. Acknowledgements
This document draws heavily from the contributions of many This document draws heavily from the contributions of many
participants in the P2PSIP Mailing List but the authors are participants in the P2PSIP Mailing List. Particular thanks to
especially grateful for the support of Spencer Dawkins, Cullen Henning Schulzrinne and Cullen Jennings who spent time on phone calls
Jennings, and Henning Schulzrinne, all of whom spent time on phone related to this text.
calls about this document or provided text. In addition, Spencer
contributed the Reference Model figure.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
11.2. Informative References 11.2. Informative References
[I-D.bryan-p2psip-dsip]
Bryan, D., "dSIP: A P2P Approach to SIP Registration and
Resource Location", draft-bryan-p2psip-dsip-00 (work in
progress), February 2007.
[I-D.bryan-p2psip-reload] [I-D.bryan-p2psip-reload]
Bryan, D., "REsource LOcation And Discovery (RELOAD)", Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
draft-bryan-p2psip-reload-01 (work in progress), H. Schulzrinne, "REsource LOcation And Discovery
July 2007. (RELOAD)", draft-bryan-p2psip-reload-04 (work in
progress), June 2008.
[I-D.camarillo-hip-bone]
Camarillo, G., Nikander, P., and J. Hautakorpi, "HIP BONE:
Host Identity Protocol (HIP) Based Overlay Networking
Environment", draft-camarillo-hip-bone-01 (work in
progress), February 2008.
[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., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-12 (work in progress), draft-ietf-behave-rfc3489bis-16 (work in progress),
November 2007. July 2008.
[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-19 (work in progress), October 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., Rosenberg, J., and G. Camarillo, "Best
SIP", draft-ietf-sipping-nat-scenarios-07 (work in Current Practices for NAT Traversal for SIP",
progress), July 2007. draft-ietf-sipping-nat-scenarios-08 (work in progress),
April 2008.
[I-D.marocco-p2psip-xpp-pcan] [I-D.jiang-p2psip-sep]
Marocco, E. and E. Ivov, "XPP Extensions for Implementing Jiang, X. and H. Zhang, "Service Extensible P2P Peer
a Passive P2PSIP Overlay Network based on the CAN Protocol", draft-jiang-p2psip-sep-01 (work in progress),
Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00 February 2008.
(work in progress), June 2007.
[I-D.matthews-p2psip-hip-hop] [I-D.li-p2psip-node-types]
Cooper, E., "A Distributed Transport Function in P2PSIP Wang, Y., "Different types of nodes in P2PSIP",
using HIP for Multi-Hop Overlay Routing", draft-li-p2psip-node-types-00 (work in progress),
draft-matthews-p2psip-hip-hop-00 (work in progress), December 2007.
June 2007.
[I-D.zangrilli-p2psip-whysip] [I-D.matthews-p2psip-id-loc]
Zangrilli, M. and B. Lowekamp, "Why SIP should be used for Cooper, E., Johnston, A., and P. Matthews, "An ID/Locator
encoding the P2PSIP Peer Protocol.", Architecture for P2PSIP", draft-matthews-p2psip-id-loc-01
draft-zangrilli-p2psip-whysip-00 (work in progress), (work in progress), February 2008.
March 2007.
[I-D.pascual-p2psip-clients]
Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S.
Yongchao, "P2PSIP Clients",
draft-pascual-p2psip-clients-01 (work in progress),
February 2008.
[I-D.zheng-p2psip-client-protocol]
Yongchao, S., Jiang, X., Zhang, H., and H. Deng, "P2PSIP
Client Protocol", draft-zheng-p2psip-client-protocol-01
(work in progress), February 2008.
[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
skipping to change at page 29, line 11 skipping to change at page 29, line 8
Singh, K. and H. Schulzrinne, "Using an External DHT as a Singh, K. and H. Schulzrinne, "Using an External DHT as a
SIP Location Service", Columbia University Computer SIP Location Service", Columbia University Computer
Science Dept. Tech Report 388). Science Dept. Tech Report 388).
Copy available at http://mice.cs.columbia.edu/ Copy available at http://mice.cs.columbia.edu/
getTechreport.php?techreportID=388/ getTechreport.php?techreportID=388/
Authors' Addresses Authors' Addresses
David A. Bryan David A. Bryan
College of William and Mary and SIPeerior Technologies SIPeerior Technologies
3000 Easter Circle 3000 Easter Circle
Williamsburg, Virginia 23188 Williamsburg, Virginia 23188
USA USA
Phone: +1 757 565 0101 Phone: +1 757 565 0101
Email: bryan@sipeerior.com Email: bryan@sipeerior.com
Philip Matthews Philip Matthews
Avaya Unaffiliated
1135 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: +1 613 592 4343 x224 Phone: +1 613 592 4343 x224
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
Eunsoo Shim Eunsoo Shim
Locus Telecommunications Locus Telecommunications
111 Sylvan Avenue 111 Sylvan Avenue
Englewood Cliffs, New Jersey 07632 Englewood Cliffs, New Jersey 07632
USA USA
Phone: unlisted Phone: unlisted
Email: eunsooshim@gmail.com Email: eunsooshim@gmail.com
Dean Willis Dean Willis
Unaffiliated Softarmor Systems
3100 Independence Pkwy #311-164 3100 Independence Pkwy #311-164
Plano, Texas 75075 Plano, Texas 75075
USA USA
Phone: unlisted Phone: unlisted
Email: dean.willis@softarmor.com Email: dean.willis@softarmor.com
Spencer Dawkins
Huawei Technologies (USA)
Phone: +1 214 755 3870
Email: spencer@wonderhamster.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 30, line 44 skipping to change at line 1300
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 99 change blocks. 
384 lines changed or deleted 357 lines changed or added

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