P2PSIP WG D. Bryan/SIPeerio-editor
Internet Draft S. Baset/Columbia U.
Intended status: Informational M.Matuszewski/Nokia
Expires: Jan 2008 H.Sinnreich/Adobe
P2PSIP Protocol Framework and Requirements
draft-bryan-p2psip-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Though both SIP and various peer-to-peer (p2p) protocols have been
widely deployed, there is no operational experience with SIP using
overlay networks. Also, most p2p networks developed in the research
community do not deal with NAT traversal. This document attempts to
list the design requirements for a P2PSIP protocol taking into
account the experience gained from both the p2p and the SIP
Bryan Expires January 2008 [Page 1]
Internet-Draft P2PSIP Requirements June 2007
communities. Special emphasis has been put on the SIP-DHT interface,
on the overlay performance, on NAT traversal and on security.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction...................................................4
2. Deployment Scenario Examples...................................5
2.1. Peer Protocol Deployment..................................6
2.2. Client Protocol Deployment................................6
3. NAT Traversal..................................................7
4. Bootstrap and Other Servers....................................7
5. SIP-P2P Interface..............................................8
6. APIs for DHT Usage............................................10
7. P2P Overlay Requirements......................................10
7.1. Architecture and Virtual Geometries......................11
7.2. Structured Overlays......................................12
7.3. Data Replication.........................................12
7.4. Load Balancing...........................................13
7.5. Overlay Performance......................................13
7.5.1. Routing Performance.................................14
7.5.2. Routing Tables and Routing State....................15
7.5.3. Iterative and Recursive Routing Styles..............16
7.5.4. Handling of Join/Leave (Churn)......................17
7.5.5. Enabling Mobility...................................18
7.5.6. Fault Tolerance to Non-Transitive Connectivity......19
7.6. Implementation Experience in Selecting DHTs..............20
7.7. Simplicity of Implementation in Selecting a DHT..........21
7.8. Discussion on the Selection of a DHT Overlay.............21
8. Client Protocol Requirements..................................22
8.1. Discussion about the Client Protocol.....................24
9. Security Considerations.......................................25
9.1. DHT Security.............................................25
9.2. SIP Security.............................................27
9.3. Client Protocol Security.................................27
9.4. Security of the SIP-DHT Interface........................28
10. IANA Considerations..........................................29
11. Conclusions..................................................29
12. Acknowledgments..............................................29
13. References...................................................29
Author's Addresses...............................................32
Intellectual Property Statement..................................33
Bryan Expires January 2008 [Page 2]
Internet-Draft P2PSIP Requirements June 2007
Disclaimer of Validity...........................................34
Bryan Expires January 2008 [Page 3]
Internet-Draft P2PSIP Requirements June 2007
1. Introduction
Recently, the IETF has established a P2PSIP WG [2] to discuss the
development of a protocol to allow the establishment of SIP
connections with little or no need for centralized servers of any
kind. The WG (and individuals now composing it prior to the official
formation) have focused on developing a DHT based system that can be
used to achieve these ends. A concepts document [3] has been produced
that outlines the basic ideas and concepts of how such a system would
be structured.
This document attempts to accomplish a few things. It attempts to
combine and present requirements for designing the peer and (if
needed) client protocols, attempts to provide some insight into
selection of mandatory DHTs, and attempts to present requirements for
other DHTs that may be added as well.
Much of what is presented here is also a collection of insights and
references to material assembled by the authors that will assist in
these decisions. As the authors all have different (and sometimes
conflicting!) ideas about how these systems should be implemented,
this document may present multiple alternatives, or even mention
points of contention. As the group reaches more consensus, it is
expected that these differences will diminish.
This is a first revision of this document, and is the result of work
by authors on several continents. As such, inconsistencies and even
outright errors are likely to appear. The authors recognize this and
are happy to have the work criticized to help improve it. In
addition, the document is certainly incomplete, and there are areas
(most notably the security section) where additional help is required
to complete this document. We hope the discussion generated can
offset the early stage of this work.
This document on the requirements for the p2p protocols is based on
published research and also on running code for p2p systems. We have
carefully avoided articulating any requirements that cannot be
substantiated by both usage scenarios and by published work based on
running code, simulations and measurements on deployed P2P systems.
We have provided for this reason references that are pertinent to
each specific requirement.
This document does NOT attempt to replace the concepts [3] in any
way, but rather extend it to discuss requirements.
Bryan Expires January 2008 [Page 4]
Internet-Draft P2PSIP Requirements June 2007
OPEN ISSUE: Should this document eventually be split (either into two
documents or simply within this document) into sections on P2PSIP
protocol decisions vs. DHT decisions?
OPEN ISSUE: Should this document eventually be split (either into two
documents or simply within this document) into sections on P2PSIP
protocol decisions vs. DHT decisions?
2. Deployment Scenario Examples
Generic applications for P2PSIP have been discussed in [4], [5] and
we are adding some more detailed deployment scenarios here.
The use of innovation in the market is usually hard to predict.
Still, P2PSIP can be deployed in many scenarios; out of which we have
selected here examples that could be most frequently related to
present SIP deployments. New scenarios may however emerge with
increased use of P2PSIP.
An overall view of possible deployment scenarios would require a
table that may be too big to fit into the ASCII format of this memo.
For this reason, we will rather enumerate here the main categories
that are encountered in deployment scenarios:
o Degree of mobility: Stable (PC, gateway), nomadic (laptop),
mobile (phone, PDA)
o NAT scenario: Any type of NAT, BEHAVE compliant NAT, no NAT
o IP connectivity: Stable, intermittent.
Of special interest to wireline (DSL, cable, fiber) service providers
is the deployment scenario where the peer nodes are located in the
network access devices of their customers, be they residential
gateways or enterprise gateways.
Peers located in access devices enjoy major benefits, such as:
o High bandwidth on the Internet side
o Stable connectivity
o No NAT in some provider network designs.
Bryan Expires January 2008 [Page 5]
Internet-Draft P2PSIP Requirements June 2007
P2PSIP nodes in the access devices seem to be a valid replacement of
the conventional client-server SIP VoIP infrastructure, while
combining all the benefits of the end-to-end principle of the
Internet with the control desired by service providers or network
administrators via the software in the access device.
Mobile service providers can reap the benefit of P2PSIP by placing
peer nodes into the base station network and using a battery sparing
client protocol in the mobile devices.
The deployment scenarios may suggest a wide variety of protocol
parameters or several DHT types for various deployments.
In the following sections, we will use the terms P2P network and P2P
overlay interchangeably.
2.1. Peer Protocol Deployment
Though the mobility, churn rate and session time are quite different
for adapters and access devices versus a laptop, it still make sense
to use a single peer protocol:
o The IP address changes even for fixed devices
o Devices with higher churn rate and low session time will benefit
from the existence of stable peers
o IP connectivity may be very good for one peer but may be less
satisfactory for other remote peers.
o Interoperability will be improved, making it more likely that many
devices can function together in one overlay.
Designers may be tempted to pick the simplest DHT peer protocol for
the deployment scenario at hand, but run the risk of loosing the
flexibility offered by a full featured peer protocol. Additionally,
choosing a protocol that only works in limited environments means
those devices cannot be used in more challenging environments.
2.2. Client Protocol Deployment
The small battery capacity of handheld mobile devices requires
reducing the amount of messages between the mobile device and the
fixed network to an absolute minimum. The client protocol has
therefore to be designed to avoid the large message exchange required
for the maintenance of the P2P overlay.
Bryan Expires January 2008 [Page 6]
Internet-Draft P2PSIP Requirements June 2007
A single standard client protocol is desirable for interoperability.
Wireless access points, wireless radio base stations may also contain
DHT peers so as to facilitate mobile devices running only the client
protocol.
To date, the working group has not decided if such a protocol is
needed, or if unmodified SIP can serve this role.
3. NAT Traversal
As mentioned in the Concepts and Terminology document on P2PSIP, it
is expected the majority of SIP peers will reside behind NAT. This
raises the issue to what extent can P2PSIP be successfully deployed,
since it will depend on effective NAT traversal techniques.
The state of P2P communications across NAT is discussed in [6]. In
the light of this document, P2PSIP must be a NAT-friendly
application, that is:
"A NAT-friendly P2P application registers with a well-known
rendezvous server, used for node registration and peer node discovery
purposes. Pursuant to registering with rendezvous server, a P2P-
friendly application uses its private endpoint, public endpoint, or a
combination thereof to establish peering sessions."
P2PSIP can be a NAT-friendly application, by using ICE [7]. According
to surveys such as [8], practically all consumer grade NAT devices
are P2P-friendly, so ICE can be used effectively for NAT traversal
consumer devices.
Symmetric NAT is however not P2P-friendly and NAT traversal may not
succeed without using STUN/TURN relay servers [9]. Symmetric NAT is
almost always deployed in private enterprise IT networks. Since
P2PSIP must be used in enterprise networks with the consent and
cooperation with the IT network administrator, measures can be taken
in private IP networks to deploy IETF BEHAVE standard compliant NAT
devices that are P2P friendly. The use of TURN may be required for
facilities where this is not possible, and SHOULD be included in
proposals.
4. Bootstrap and Other Servers
A small number of servers is required for the proper operation of the
overlay network. We discuss here briefly for clarity only these types
of servers though they do not affect the P2PSIP protocol design.
Bryan Expires January 2008 [Page 7]
Internet-Draft P2PSIP Requirements June 2007
o The P2P overlay is established with the help of bootstrap servers.
o As mentioned in the section on NAT traversal, P2PSIP must be NAT-
friendly and thus also requires well-known rendezvous servers,
such as specified for the ICE protocol.
o Security for the overlay must be based on strong authentication
provided by an authentication server. P2PSIP does not depend on
the particular implementation of the authentication server and
therefore the authentication server is not discussed in this
document.
The bootstrap servers and the rendezvous servers may or may not be
placed on the same machines and this is a design decision that does
not affect the P2PSIP protocol.
A recent I-D on NAT traversal specifically for P2PSIP has been
published [10], showing that NAT traversal using ICE techniques are
quite effective.
5. SIP-P2P Interface
In a typical SIP trapezoid, a caller in domainA wishing to contact a
callee in domainB sends a request to its proxy server (proxyA), which
following the guidelines in [1] forwards the request to the proxy
server of domainB (proxyB). When the request arrives at proxyB, it
consults its location service (typically a database) to find the IP
address of the callee, and forwards the request to callee SIP user
agent.
A characteristic of this architecture is that the typical SIP hop-
count is only a few hops; the caller only needs to send its request
to its outbound SIP proxy, which in turn needs to locate the SIP
server of the callee. The key assumptions of this architecture are
that SIP proxy servers use DNS to locate other proxy servers,
maintain a database of SIP user agents in its domain, are fairly
stable and trusted.
Peer-to-peer systems on the other hand distribute the task of
locating the SIP proxy servers, and proxy servers locating SIP user
agents to the peer themselves. This means that SIP requests no longer
traverse through reliable and trusted proxy servers and the SIP hop-
count of a request can be significantly greater than a few hops; in a
DHT it is log(N), where N is the number of peers.
The above discussion suggests at least two paradigms for SIP
operation in a p2p setting: the end-to-end paradigm where a SIP user
Bryan Expires January 2008 [Page 8]
Internet-Draft P2PSIP Requirements June 2007
agent uses the p2p location service to discover the location of
callee, and then send the SIP message directly to the callee, or a
hop-by-hop paradigm where each peer forwards the SIP request to a
peer which is more 'closer' to the callee. The former can be thought
of as a RPC whereas the later can be thought of as a local procedure
call to determine the next hop.
SIP uses an address-of-record (AOR), to locate the user. An AOR is a
SIP or SIPS URI and frequently thought as the "public address" of the
user. DHTs are a prime motivation for P2PSIP and they convert a blob
of text to a unique hash value. A DHT will generate a unique hash for
a SIP or SIPS URI for the same user, and store it on different peers.
Since a peer-to-peer system may suffer through churn, it may lead to
a situation where a SIP URI is reachable but SIPS URI is not or vice
versa. The impact of such distributions due to the underlying P2P
service must carefully be analyzed.
A SIP user agent can participate in the traditional c/s SIP or a
P2PSIP network at the same time. Such a UA must have a predictable
ordering of what to do when presented with a SIP URI.
SIP relies on STUN, TURN and ICE for NAT traversal. The P2P service
will likely incorporate NAT and firewall mechanisms for the
maintenance of the overlay. The SIP application may take advantage of
NAT traversal mechanisms provided by the underlying P2P service.
It is important to note that the SIP-DHT interface and the peer
protocol should not depend on one particular DHT. While having one
DHT as must implement is necessary for interoperability, there is a
danger that specifics from that DHT may creep into the overall
design. Moreover, there is no 'clear winner' out of the DHTs proposed
so far. The research in DHTs is ongoing and therefore the must-
implement DHT should in no way restrict the SIP-DHT interface and the
peer protocol from incorporating a DHT in the future that performs
significantly better. Any attempt to incorporate DHT-specific
information will greatly undermine the flexibility of the SIP-DHT
interface and the peer protocol. The Peer-to-Peer Protocol (P2PP)
[27] is a proposal that attempts to incorporate these concerns.
Req 5-1: The P2PSIP protocol MUST have a clearly defined interface
between the SIP and overlay layers.
Req 5-2: The interface between SIP and the overlay MUST support the
use of various types of overlays.
Bryan Expires January 2008 [Page 9]
Internet-Draft P2PSIP Requirements June 2007
6. APIs for DHT Usage
DHTs provide two conceptual operations, namely, 'Lookup' to locate
peers responsible for a key, and 'Publish' to insert a key-value pair
in the DHT. In addition, a 'Remove' operation allows the publisher to
explicitly remove a key-value pair. These operations suffice for
nodes that do not participate in the DHT overlay. For nodes that do
participate in the overlay, additional operations of 'Join' and
'Leave' are necessary. Thus, at the very least, the following API
must be provided by the P2P layer:
o Join
o Leave
o Lookup
o Publish
o Remove
If a client protocol is implemented, the following API must be used:
o Lookup
o Publish
o Remove
Peer protocol will likely implement mechanisms for overlay
maintenance during churn, and replication. However, an application
using DHT does not need to be aware of them. If there is a need to
fine tune these parameters, an API similar to set[get]sockopt() can
be defined.
OPEN ISSUE: Is there a need to separately define the secure and non-
secure version of these APIs?
7. P2P Overlay Requirements
SIP can be used with various types of P2P overlay networks. This
document focuses on requirements for overlays on the Internet to
leverage the global reach, inherent mobility, resilience and other
attributes of the Internet.
At the same time, these requirements take also into account the
impairments found on the public Internet, the lack of transparency
due to NAT, as well as the various exposures to security for P2PSIP.
An important feature of the P2P design for global reach over the
Internet is the self organizing characteristic of P2P networks, in
Bryan Expires January 2008 [Page 10]
Internet-Draft P2PSIP Requirements June 2007
the sense that no network management and no peer node configuration
is required to be performed manually.
Smaller P2PSIP networks such as found in private IP networks may have
different requirements that are not addressed in this document.
As mentioned in below, designers can have a fair choice of the DHT
they may want to deploy and this can be accommodated by the SIP-DHT
interface discussed in Section 5.
Though the focus of this memo is on SIP applications, we take into
account, whenever is possible, the fact that P2P overlays can be used
for many other non-SIP applications. Implementers of P2PSIP may have
compelling reasons to use an overlay for other applications beyond
SIP that are however out of scope for the P2PSIP WG. For this reason,
the flexibility of using a DHT for other applications must also be
considered.
The default protocol must be a DHT but we should not preclude other
overlay protocols from consideration.
7.1. Architecture and Virtual Geometries
One of the main reasons for selecting DHT overlays for large-scale
systems is their resilience in the event of node failures.
Research on structured, DHT based overlays has revealed multiple
architectures with various pros and cons that go beyond the scope of
this memo, since the DHT routing architecture is only one of several
selection criteria and by itself, is not of exclusive importance.
In this memo we focus only on structured, DHT functionality on
Internet-like scale for the overlay network that can be used for SIP
based multimedia communications.
For illustrative purposes, we assume a large DHT address space such
as 160 bits that can be represented on a virtual circular space. A
virtual circle is however not the only possible geometry. Pastry and
its successor Bamboo also display a virtual tree-like geometry that
facilitates routing based on increasingly matched prefixes.
Various tree-like routing architectures can be used for application
level multicast, for conferencing, collaboration and for prefix based
search - all of which are of interest for use in distributed SIP
conferencing. Highly scalable application layer multicast systems
have been developed in the research community [11]. Application level
multicast can support a wide variety of applications [12].
Bryan Expires January 2008 [Page 11]
Internet-Draft P2PSIP Requirements June 2007
7.2. Structured Overlays
Req 7-1: For scalability and predictability, a structured DHT overlay
MUST be used as the default P2P protocol.
Examples of structured overlays include CAN, Chord, Bamboo, Kademlia,
Pastry, Tapestry, and Viceroy [13].
DHT overlays have natural limitations that must be taken into account
[14]. Two very different deployment scenarios illustrate the
limitations a particular DHT has when trying to address all problems:
o Highly dynamic membership of peers: In this case only small amounts
of data can be stored, limited by the amount of bandwidth available
for the update of data stored in peers. Besides the maintenance of
the overlay network structure may require additional resources such
as bandwidth, CPU and memory. This is especially evident in the
high network churn scenarios.
o Stable membership of peers: In this case large amounts of data can
be stored since no frequent updates are required.
System designers must have the flexibility to target their design
anywhere between these two extremes.
Req 7-2: The peer protocol MUST allow for flexibility in the DHT
selected, to allow for deployments with various tradeoffs for churn,
data size and bandwidth for reliable data storage. One (or a small
number) of DHTs specified as mandatory MUST be supported, but
protocol MUST allow for new DHTs to be added.
7.3. Data Replication
Most DHT schemas provide data replication in neighbor nodes that have
overlay identifiers numerically close to the target node.
High reliability for the availability of replicated data can be
assured because of the wide geographic diversity, IP network
ownership and jurisdiction, etc, of neighbor nodes that have close
neighbor identities [15], [16].
There is a trade-off between data replication being controlled by the
data publisher or by the node storing the data.
Bryan Expires January 2008 [Page 12]
Internet-Draft P2PSIP Requirements June 2007
Req 7-3: The P2PSIP Overlay MUST assure that no data placed in the
overlay is lost before the scheduled timeout. The scheduled timeout
for data on the overlay is a design choice. The protocol selected
MUST allow for flexibility in how redundant a system is, since some
deployments may require higher (or lower to conserve resources)
levels of redundancy.
7.4. Load Balancing
The load balancing mechanism in DHT based overlays is provided by the
statistical nature of the hash function and the algorithm of the DHT
itself. Refinement in overlay protocols, such as reported for PAST
over PASTRY [15] file storage have been described that attempt to
improve the fairness of disk sharing among peers.
There are several other flavors of load balancing: One is to
distribute data request among several replications. The other is to
make the request routed through different overlay paths and reduce
burden of hot spots.
Req 7-4: Dedicated load balancing schemas beyond the natural load
balancing of the DHT MAY be used for fair disk storage sharing
between peers as well as for balanced network usage. The DHT SHOULD
allow an efficient load balancing algorithm that distributes the load
on P2PSIP network entities that are responsible for storing
frequently queried resources. While the authors would prefer to make
this a MUST requirement, it is recognized that some specialized DHTs
may be designed to prefer other factors (for example, geographical
nearness) over fair load balancing. The default DHT MUST provide fair
load balancing.
7.5. Overlay Performance
While other designs may be possible, there are two components of most
DHTs that define how routing works:
1. Neighbor nodes for correct routing to the destination. The
selection of neighbor nodes can take into account network proximity
metrics such as latency, hop count or bandwidth of the neighbor
nodes.
2. A DHT routing algorithm for fast, greedy search, generally a
mechanism for determining which neighbor node to send the message
to.
Bryan Expires January 2008 [Page 13]
Internet-Draft P2PSIP Requirements June 2007
These two components of the DHT architecture will be discussed here
in more detail.
7.5.1. Routing Performance
One of the criteria for selecting a specific DHT geometry is routing
performance, meaning the average number of hops as a function of
overlay network size. If we denote the complexity by O and the number
of nodes in overlay by N, most architectures assure a number of hops
proportional to O*log(N).
The routing performance MAY be improved by parallel queries, which
reduce the delay impact of contacting a dead node.
Req 7-5: The peer protocol MUST accommodate a DHT for a fast routing
algorithm that minimizes hop count to the root node. The routing
algorithm MUST assure real time information retrieval. This also
means that the delay of the information retrieval MUST be acceptable
to users.
There are two fundamental types of neighbor nodes:
o Neighbor nodes in the hash table key space. Chord for example
defines its neighbors as the successor nodes from itself [17],
while Pastry [15] and Bamboo [18] define the so called leaf nodes
that are at an equal distance before and after itself on the
circle. Kademlia uses the mathematical distance based on XOR metric
[19]. Such neighbor nodes may however be widely dispersed across
the underlying IP network and this fact guarantees good geographic
diversity.
o Neighbor nodes learned from the routing process in various searches
that have terminated on the target root node. In Pastry and Bamboo
the target root node makes a neighborhood list and can apply
various routing metrics such as delay, number of IP hops or
bandwidth to select the closest known peers. This is an extremely
valuable feature for real time communications.
Req 7-6: The number of neighbor nodes MUST be selected high enough to
insure the the loss of connectivity to a few nodes does not
disconnect the peer and cause loss of data (although replication
should mitigate this).
Bryan Expires January 2008 [Page 14]
Internet-Draft P2PSIP Requirements June 2007
Req 7-7: The protocol DHTs MUST have the capability of applying
various routing metrics in selecting neighbor nodes. Latency based
neighbor selection (for example for use in NAT traversal) for SIP
based real time communications SHOULD be supported by the peer
protocol.
7.5.2. Routing Tables and Routing State
The number and size of routing tables varies for the different DHT
types. Some DHTs keep only a table of logarithmically distributed
peers, where others keep additional information. For example, Pastry
and Bamboo have the following:
o A routing table of known live peers. This table is used to
execute fast search requests from other peers.
o A list of the leaf set with its identifiers and IP addresses.
The leaf set is used for accuracy in finding the root.
o A neighborhood set selected by some routing metric, such as
delay.
Routing state is understood here to mean the total data amount stored
in the routing tables.
The routing state has to be maintained under churn. Devices may learn
this by a number of ways, including from the routing events or/and by
querying other nodes for their availability. The DHT maintenance
mechanism may require setting up and maintaining TCP or TLS
connections with neighbor nodes or other nodes in the routing tables.
In all battery-powered devices such as laptops, mobile phones, PDAs,
or WiFi phones, power management is one of the key issues. The power
consumption may be impacted by maintenance of the routing state and
by the handling of lookups. These two mainly affect the idle state.
The idle state represent a state when P2PSIP peer software runs in a
battery-powered device but a user does not use any services provided
by the P2PSIP overlay. The power consumption in the idle state
determines how long a battery-powered device can stay online without
recharging. Similarly, small capacity devices such as low-end desktop
phones may have limited CPU and/or memory capacity. These limitations
may result in different requirements for DHTs.
Req 7-8: The size of the routing state, that is the greedy routing
table plus the tables of neighbor nodes SHOULD be kept equal or
minimally larger than required by the routing table for the [14]
routing protocol and MUST not grow faster than the log of the P2P
overlay size. Note however that this does NOT mean that it must be
Bryan Expires January 2008 [Page 15]
Internet-Draft P2PSIP Requirements June 2007
the log of the maximum size possible (for example, 160 neighbors for
systems using 2^160 hash size) of the overlay, since this may be
impractical (and undesirable) for small networks such as ad-hoc or
enterprise. It also does NOT mean that additional neighbors may not
be stored to improve efficiency if capacity is available. Because
routing efficiency and local storage used are tradeoffs that may vary
for different deployments, the balance of this is left to the various
DHTs used (or the overlay designer)
Req 7-9: The maintenance of the routing state MUST consume minimum
node and network resources.
7.5.3. Iterative and Recursive Routing Styles
Routing in the hash identifier space can be iterative or recursive,
each having its advantages and drawbacks depending on the
application.
o Iterative routing allows the source to control the routing process.
The source peers can apply logic for security by checking the
routing integrity. The number of NAT traversals is smaller and NAT
traversal may be therefore easier. Besides the iterative routing
offers increased robustness against message loss since the message
is not relayed by many nodes in the overlay. The disadvantage of
iterative routing is higher message traffic at the source and a
slightly higher search delay. Further, iterative routing over TCP
may result in establishing a per-hop TCP connection.
o Recursive routing is performed hop by hop and its advantages are
that it is faster and has lower message traffic at the source. The
disadvantage of recursive routing is a higher vulnerability to
malicious nodes, since the routing integrity cannot be checked at
the source, lower robustness against message loss and possibly
higher number of required NAT traversals.
Other mechanisms (such as strictly forward routing) may also be
appropriate and should be considered for incorporation here.
Note that because various circumstances (such as the presence of
NATs) may only occur on some links, the protocol must allow a mixture
of these routing mechanisms.
Bryan Expires January 2008 [Page 16]
Internet-Draft P2PSIP Requirements June 2007
7.5.4. Handling of Join/Leave (Churn)
We define here the metrics of churn [20] that is relevant for SIP
applications using as background the application scenarios for
P2PSIP. There are two distinctive metrics for churn:
o Time online: The length of time when a peer node is online for the
purpose of a real time communication session. This includes:
o The length of time a mobile device is online
o A PC online where the user is monitoring the presence list
for buddies of interest or some other SIP events not
related to real time communications
o A network access device for a residential or enterprise
network, which may be very nearly "always on".
o Lifetime: The length of time during which a peer node may appear
online. This happens between the time of enrollment and when
leaving the P2P service.
Churn in P2P networks has been studied extensively for various
applications, but unfortunately not for SIP applications. At this
point in time, we have to rely on studies on the handling of churn
that have been done for other applications on various P2P systems.
The handling of peer nodes joining and leaving the overlay is a most
critical decision. Various DHT algorithms have very different
procedures for new nodes joining the overlay and leaving, mostly
suddenly the overlay. Dealing with nodes leaving the overlay is more
difficult. For example:
o Chord has a stabilization protocol that runs in the background to
check the successor nodes.
o Pastry and Bamboo perform periodic check to verify the existence of
the neighbor nodes and modify the routing tables accordingly.
Both Chord and Pastry may have additional algorithms for handling
churn.
Bryan Expires January 2008 [Page 17]
Internet-Draft P2PSIP Requirements June 2007
Reported test results include [23] comparing Chord and Bamboo for the
latency of routing versus session time between active nodes. Note
that such comparisons do not provide the whole picture in the
presence of network impairments.
There are too many differing factors to compare between differing
architectures and the effects of various features are hard to
isolate. For this reason, it is not practical comparing the
architectural differences of the various DHT implementations but
rather focus on the important issues in handling churn. Simulations
and testing can eliminate DHT types that show no promise and help in
selecting a candidate DHT for the "must implement" DHT. Again,
requiring modularity in DHT selection for the protocol can prevent
the protocol from being tied to a poor choice or limited to only be
appropriate for certain deployments.
Req 7-10: The default DHT selected for the peer protocol MUST
incorporate techniques for handling churn. Joining, leaving, or
searching the P2P overlay under high churn condition SHOULD not be
significantly slower than these operations in the absence of churn.
7.5.5. Enabling Mobility
Handling nodes leaving the overlay introduces an additional traffic
overhead in the overlay and also requires additional processing power
to modify information in routing tables. When a peer rejoins the
overlay network the overlay may have to perform more operations than
in the case when a peer leaves a network. Additionally, updates to
the DHT do not take place immediately after a node leaves.
Laptop computers, mobile phones, PDAs, and WiFi phones may move from
one network to another by doing handover between different access
networks or moving from one WLAN access point to another. When doing
handover they may loose connectivity to the overlay for a short
period of time. Most important for mobility is the fact they may
receive a new IP address from the new access network.
In some DHTs a peer ID is based on the IP address. This means that
when a node receives a new IP address it must also receive a new peer
ID. This is equivalent to a node leaving the overlay network and
joining it again. This may cause network instability and require
additional resources to handle network adaptation (as explained
above). This has impact on battery life of battery-powered as well as
on system reliability. In the transition period search delay for user
contact information may be higher, delaying the call establishment.
For these reasons, the node ID SHOULD not depend on the IP address.
Bryan Expires January 2008 [Page 18]
Internet-Draft P2PSIP Requirements June 2007
The peer protocol SHOULD support a mechanism for DHTs that allows
network nodes to freely move from one access network to another
without a need to reconfigure their peer IDs and without changes in
the overlay network topology such as changes in neighboring sets or
contacts in the routing tables. This requires only that the new
address of a moving node propagates in real-time to the rest of the
peers that need that information.
Req 7-11: The peer protocol MUST not interfere with mobility. A DHT
MUST be available that supports mobility to allow network nodes to
freely move from one access network to another without causing
changes in the overlay network topology and decreasing routing
performance. The information about new address of a node MUST
propagate in real-time to the rest of the peers that need that
information.
7.5.6. Fault Tolerance to Non-Transitive Connectivity
The various DHT architectures assume all peer nodes can communicate
at all times but this is not true in practice [21]. The Internet has
transient failures of connectivity due to link failures, route
flapping due to equipment maintenance, faulty BGP routing table
updates and ISP disputes. During such transient failures, pairs of
nodes such as node A and node B can communicate with node C, but
cannot communicate with each other. This is called non-transitivity.
In addition, the presence of NATs can lead to systemic and semi-
permanent non-transitivity.
Extensive testing on Planet Lab that includes nodes on Internet1,
Internet2 and multihomed nodes has shown amounts of non-transitivity
than can lead to significant problems for various types of DHT. Note
this occurs even on Planet Lab, which is relatively closed, high
quality, NAT-free academic environment which is far more forgiving
than real-world deployments are likely to be.
Non-transitivity is actually rather the rule than the exception on
the Internet since most peer nodes are likely to reside behind one or
more NATs. The section on NAT traversal deals more with this aspect.
Firewalls can be another cause for non-transitivity, but we assume
the network administrator will configure firewalls to pass P2PSIP
messages if this behavior is desired. If local policy should prohibit
the firewall to pass P2PSIP messages then it is not our intent to
write standards requirements to circumvent local firewall policy.
The problems arising due to non-transitivity include the following:
Bryan Expires January 2008 [Page 19]
Internet-Draft P2PSIP Requirements June 2007
o Invisible nodes when a peer learns about a node but cannot
communicate with it
o Routing loops when a search skips a node around the virtual circle
in some implementations
o Broken return paths. This may happen when the root node holding the
information is found by using recursive routing and the result is
sent back directly to the source node, but there is no connectivity
between them.
o Inconsistent roots. The correctness of the key space can be
affected if two nodes that cannot see each other believe each to be
the correct root during a lookup.
Various DHT systems have different specific remedies to counter non-
transitivity.
Req 7-12: DHTs designed for use with the P2PSIP protocol MUST take
into consideration non-transitivity on the Internet.
7.6. Implementation Experience in Selecting DHTs
A significant aspect in choosing a DHT for P2PSIP is the glaring
contrast between the huge number of research papers versus the
extremely limited DHT overlays that have actually been deployed in
large scale systems on the Internet.
There are other considerations as well, besides the routing aspects
in choosing a DHT, such as:
o To what degree has a particular DHT been deployed and tested in
large scale systems over the Internet?
o To what a degree has a particular DHT been researched in depth and
the research results made public?
o To what degree has a DHT been used for various significant
applications and can their use be extrapolated for P2PSIP?
Bamboo was deployed on the openDHT network on Planet Lab. Kademlia is
the only DHT that was deployed in a large scale commercial systems.
Req 7-13: The DHT selected for the default DHT MUST be based on
operational experience from large scale systems and measurements on
the Internet or significant testing and research involving multiple
peers.
Bryan Expires January 2008 [Page 20]
Internet-Draft P2PSIP Requirements June 2007
7.7. Simplicity of Implementation in Selecting a DHT
Selecting a DHT as the "must implement" must also take into account
the fact that many developers will be independently building
implementations. While any algorithm, even one of arbitrary
complexity, may work, and may even be more efficient, the likelihood
of two independent implementations functioning properly together
decreases greatly as the algorithm's complexity increases. While
efficiency is extremely important, the "must implement" should be a
safe fall back that can be easily and correctly implemented. More
complex DHTs can be employed as additional DHTs.
Req 7-14: The DHT selected as the default DHT MUST be as simple and
easy to implement as possible, while addressing the majority of
requirements above.
This selection MUST be driven by an understanding of the difficulty
of different developers producing interoperable, running code.
7.8. Discussion on the Selection of a DHT Overlay
Picking one or a small selection of DHT overlays for P2PSIP is a
difficult proposition, given the very large number of solutions
developed in the research community. To overcome this difficulty it
is useful to look first at the important properties of various DHT
without going into all the specific details for each. After choosing
the key properties, various DHT can be compared as has been done in
[22], [23]. The selection of a DHT for P2PSIP MUST be based on a
thorough comparison and discussions in the IETF P2PSIP WG.
There are a large selection of DHT geometries, including the ring
geometry, the XOR geometry, the tree and hypercube. Some DHT such as
Pastry feature a dual geometry of both ring and tree. It is beyond
the scope of this memo to discuss in detail the various geometries
and we prefer to reference key literature on this topic. A detailed
mathematical analysis of the various geometries in [23] shows the
ring and XOR geometries to have the best performance using the above
criteria, with the ring geometry showing a slight advantage.
Bryan Expires January 2008 [Page 21]
Internet-Draft P2PSIP Requirements June 2007
8. Client Protocol Requirements
Note: While it is not yet clear if a Client protocol will be required
(a number of members of the WG, and even some of the authors of this
document, feel conventional SIP may be enough, although it is too
early to tell), if one is required, the following requirements would
apply to this protocol.
One assumption of DHT networks on the Internet could be that the
network nodes are homogenous, and they have enough processing power
and memory to run DHT networks without any limits. This assumption
does not hold however if we consider mobile devices such as mobile
phones, PDAs, or WiFi phones. Mobile devices are heterogeneous. Low-
end devices may have a little memory, a slow CPU and may not support
fast packet radio interfaces. On the other hand, high-end devices may
have significantly higher capabilities: Fast radio interfaces, more
memory and faster CPU then they their less advanced counterparts.
From this reason we can classify network nodes into two categories:
Mainly those that have enough CPU power, memory and fast network
interface to run P2PSIP peer protocol and those that may not have
enough capabilities to become P2PSIP peers.
Additionally, if we consider the issue of NAT traversal, a very
powerful mobile device can be behind a restrictive NAT. This may
require the device to establish a TCP or TLS connection towards a
TURN server. If the connection has to be maintained for a long
period, it may drain the device battery. From these reasons, not all
battery powered devices though having enough capabilities to run the
peer protocol will still not be able to become P2PSIP peers.
Essentially, any DHT overlay network can support two basic
operations: PUT and GET. In the P2PSIP overlay a PUT operation is
used to insert, modify, or delete data in the overlay,such as user or
resource records. A GET operation is used to retrieve data stored in
the overlay. Clients should be able to store, modify, delete and
retrieve user and resource records from the overlay; in the P2P
language they must support PUT and GET operations.
Req 8-1: The client protocol MUST allow nodes that are not eligible
to become peers to store, modify, delete and retrieve user and
resource records stored in the P2PSIP overlay.
Bryan Expires January 2008 [Page 22]
Internet-Draft P2PSIP Requirements June 2007
In all kinds of battery-powered devices such as laptops, mobile
phones, PDAs, or WiFi phones power management is one of the key
issues. As discussed in this section and section 8.7.2 traffic
introduced by the overlay protocols may significantly reduce the
battery life of battery powered devices. This does not allow some of
the nodes to become peers. Those devices will have to act as clients
and implement the client protocol that conserves the client's
battery.
Req 8-2: The client protocol must be efficient enough to conserve the
client's battery.
As mentioned, there are many situations when powerful mobile devices
cannot be elected as peers. This may happen, e.g. if the access
network provides a small bandwidth interface or if the user is not
willing to assume the cost of increased bandwidth consumption related
to the P2PSIP application.
Req 8-3: The client protocol MUST introduce low message traffic to
preserve bandwidth.
User and resource records may include different data that may be of
no use to some applications. Transferring all of the data stored in
user and resource records over the network interface (especially over
the air interface) may be undesirable in some situations since it
will increase traffic in the network. Additionally a user may make
only small changes to its own records stored in the overlay. In this
case it should be possible to update only a part of the user record
stored in the overlay without a need of uploading the whole user
record to the responsible peer.
From these reasons, there should be a mechanism to allow clients to
indicate what data they want to modify, delete, or retrieve.
Req 8-4: The client protocol MUST enable peer clients to selectively
indicate the data they are interested on. The clients MUST be able to
retrieve, modify or delete a selected part of user and resource
records.
In order to support the iterative routing style the client protocol
must support redirection from a peer to another peer or other network
node. The peer must be able to send redirect response to a request
originated by a client with the address of a node that is better
suited to handle the request.
Req 8-5: The client protocol MUST support redirection of requests
from one peer to another network node.
Bryan Expires January 2008 [Page 23]
Internet-Draft P2PSIP Requirements June 2007
8.1. Discussion about the Client Protocol
The realisation of the client protocol may have many forms. The
widely deployed protocols on the Internet that are used to manipulate
data stored remotely are using HTTP as the transport and such as the
XML data format as the encoding. A Remote Procedure Call (RPC)
protocol such as XML RPC is one of the options for the client
protocol. XML RPC [24] is used in OpenDHT [25] deployed in Planet Lab
[26] that is designed to support long-running services for a client
base. This protocol is also proposed in [28] as an ASCII based client
protocol. A binary protocol is yet another possibility.
In this option SIP is used for multimedia session establishment
between endpoints whereas XML RPC or a similar protocol is used as a
lookup protocol providing an access to SIP data stored in the P2PSIP
overlay that is required to setup a multimedia session.
Another option is to send XML documents in SIP messages or modify SIP
to support functionality needed for the client protocol. It has been
noted that SIP is a session establishment protocol, not a generic
lookup protocol; therefore it should not be used for general Remote
Procedure Call (RPC).
It seems to be a more reasonable solution to support conventional SIP
UAs (unmodified SIP devices). In this alternative the P2PSIP overlay
would have to appear as a conventional SIP network to SIP UAs. This
solution does not require any changes to the existing SIP devices,
which can use SIP services provided by the overlay without even
noticing its existence. However it introduces the very strict
requirement that every peer in the P2PSIP overlay implements the SIP
proxy and redirect server functionality.
The P2PSIP overlay may include STUN/TURN servers that do not
implement a SIP stack but may assist peers/SIP UA in NAT traversal.
These servers must be allowed to register to the DHT and advertise
their services.
It is also possible to combine a client protocol with support for
conventional SIP devices. In this scenario some of the peers would
include a co-located SIP proxy server which implements a P2PSIP API
that allows them to PUT/GET information to/from the overlay on behalf
of unmodified SIP devices. All of the peers (or the subset of
thereof) would implement the (different) client protocol to support
requests.
Bryan Expires January 2008 [Page 24]
Internet-Draft P2PSIP Requirements June 2007
End users and P2P operators may have an equal or even bigger interest
in various other non-SIP applications compared to P2PSIP only. For
this reason, the Client Protocol may be enabled with other interfaces
to the DHT, such as described in [30]. Such interfaces are however
beyond the scope of P2PSIP WG.
9. Security Considerations
P2PSIP security [29] can be decomposed into several parts:
o DHT security
o SIP security
o Client protocol security
o Security of the SIP-DHT interface.
It is a good idea to keep these parts as independent as possible,
though as we will see, DHT security can be enhanced by strong
authentication provided in the SIP application layer.
9.1. DHT Security
The specific security issues for large public P2P networks stem from
the fact that mutually distrusting parties must be able to join the
overlay network in spite of having possibly conflicting interests.
This is also true for large closed P2P networks [30].
A fraction of the nodes may act maliciously and cause the following
problems:
o Misrouted, corrupted or dropped messages,
o Corrupted routing information,
o False identities being presented to the other peers,
o Corrupting or deleting data they are supposed to store.
Bryan Expires January 2008 [Page 25]
Internet-Draft P2PSIP Requirements June 2007
1. The attacker should not be able to easily corrupt, delete, or
overwrite data stored in the P2PSIP overlay, the data stored in
routing tables as well as user records. In order to achieve this, the
node ID assignment process should make sure that a single user
receives only one node ID. Once assigned, the node ID should be
difficult to change. These two requirements prevent the so-called
Sybil [31] attacks, where a malicious party obtains a large number of
valid node IDs. Several measures can be taken by the enrollment
process, for example:
rd o Strong identity such as employment or provided by 3 party,
o Charging for the enrollment,
o Trust may be a useful tool in very large P2PSIP networks [32].
2. It should be possible to verify integrity of data stored in the
overlay by comparing data with neighbor nodes or by checking the
consistency of the routing tables.
3. It should be possible to verify integrity of data stored in the
overlay by comparing data with neighbor nodes or by checking the
consistency of the routing tables.
4. Signature mechanisms can be used to verify data has not been tampered
with while stored.
The security mechanisms should scale from a few nodes to an overlay of
many millions of nodes across the globe. Because of the nature of
P2PSIP the security mechanism SHOULD NOT depend on centralized servers
except for a central certificate authority such as from the P2P overlay
operator. Self signed certificates may also be deployed.
Req 9-1: The security of the underlying DHT in P2P SHOULD use one or a
combination of all four DHT specific security techniques:
1. Secure node IDs obtained from the enrollment server
2. Secure routing table maintenance by checking the routing tables with
the neighbors
3. Secure message forwarding using various failure tests, such as
comparing responses from different nodes when using different source
nodes to launch a request.
4. Originator signed data.
Trust [32] MAY also be used to reduce the reliance on the above
security tools.
Bryan Expires January 2008 [Page 26]
Internet-Draft P2PSIP Requirements June 2007
9.2. SIP Security
The minimal requirements for SIP security for both client-server and
peer-to-peer modes are detailed in [33].
9.3. Client Protocol Security
The client protocol must allow nodes that are not eligible to become
peers to securely store, modify, delete and retrieve user and resource
records stored in the P2PSIP overlay. This includes the following
operations:
1. Authentication
2. Access rights assignment
3. Integrity protection
4. Data encryption
The client protocol must support a method for clients and peers to
authenticate each other. This is important in a distributed scenario
where a client may connect to different unknown peers. The client should
be able to verify that the peer it is connecting to belongs to the
desired overlay. On the other hand the server should also be able to
authenticate the client. Some widely deployed cryptographic protocols
such as (D)TLS use a certificate based authentication.
Req 9-2: The client protocol must support mutual authentication between
peers and clients. The authentication method MUST be implemented by
peers and clients and SHOULD be used by these entities.
The client protocol must support a method that allows setting access
rights to the resources stored in a DHT. When inserting a new user or
resource record into the DHT, the client should be able to allow one or
more network entities to perform one or more of the following
operations: modify, delete, and override the inserted record.
Req 9-3: The client protocol MUST allow setting access rights to the
resources stored in a DHT.
The peer should be able to validate that the data received from a client
was not altered. It should be also possible for a client to verify
integrity of data retrieved from the overlay.
Bryan Expires January 2008 [Page 27]
Internet-Draft P2PSIP Requirements June 2007
Req 9-4: The client protocol MUST support integrity protection of the
data being inserted or retrieved to/from an overlay.
The clients should be provided with option to encrypt data exchanged
with peers, and vice versa.
Req 9-5: The client protocol SHOULD support data encryption.
9.4. Security of the SIP-DHT Interface
Besides the security of the P2PSIP overlay itself that we have discussed
in the sections 10.1 and 10.2, the security of the interface between SIP
and the DHT is also a matter of concern.
Two main attack scenarios have been identified between the DHT and
applications that use it [30]:
o Squatting: Use a valuable key ("coca-cola.com"), similar to domain
names
o Drowning: Putting a vast number of values for the same key.
The security design for the interface to deal with the above can be
summarized as in the following example
1. Authentication
o Assumes the existence of a private + public crypto key pair
o Verify that an authorized and/or trusted entity wrote a value
o A node protects its own value from overwriting.
2. Publish security
o The publishing node signs the key/value pair.
3. Lookup security
o A node verifies the data returned by the Lookup operation.
4. Remove security
o A node verifies the credentials of the requestor to remove
data.
Bryan Expires January 2008 [Page 28]
Internet-Draft P2PSIP Requirements June 2007
Req 9-5: The interface between SIP and the DHT MUST be secured in
case the P2PSIP client is connecting to peer nodes of the P2PSIP
networks or when an external DHT is used:
9-5 a. Authentication credentials MUST be presented, and
9-5 b. All commands to the peer must be secured by encryption and
digital signatures.
10. IANA Considerations
This document has no actions for IANA.
11. Conclusions
The requirements for P2PSIP point to a complex protocol, especially
when choosing a high performing DHT layer that includes system
design based on operational experience and measurements.
NAT traversal and security add to the complexity of P2PSIP.
Given however that all peers run essentially the same software and
P2PSIP is a self organizing network, the operational complexity and
cost is expected to be much less that conventional client-server
SIP networks.
12. Acknowledgments
The authors would like to thank Kundan Singh for useful input to
this document and also for reviewing parts of the draft. In
addition, the many people of the IETF P2PSIP WG that have
contributed to discussions or drafts were invaluable in assembling
this document.
Jiang XingFeng has made valuable comments to this document.
This document was prepared using 2-Word-v2.0.template.dot.
13. References
13.1. Normative References
[1] RFC 3263, "Session Initiation Protocol (SIP): Locating SIP
Servers", by J. Rosernberg and H. Schulzrinne, June 2002.
Bryan Expires January 2008 [Page 29]
Internet-Draft P2PSIP Requirements June 2007
13.2. Informative References
[2] Home page for the P2PSIP WG: http://tools.ietf.org/wg/p2psip/
[3] Bryan, D., Matthews, P., Shim, E. and Willis, D: "Concepts and
Terminology for Peer to Peer SIP", draft-willis-p2psip-
concepts-04 (work in progress), http://www.ietf.org/internet-
drafts/draft-willis-p2psip- concepts-04.txt, March 2007.
[4] D. Bryan et al: "Use Cases for Peer-to-Peer Session Initiation
Protocol (P2P SIP)", I-D, IETF November 2005.
[5] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings,
SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication
System (pdf), Proceedings of the 2005 International Workshop on
Advanced Architectures and Algorithms for Internet Delivery and
Applications (AAA-IDEA 2005), June 2005
[6] "State of P2P Communication Across NATs" by P. Srisuresh et al.
Internet Draft, IETF, February 2007.
[7] "Interactive Connectivity Establishment (ICE)" by J. Rosenberg.
Internet Draft (Version 15), March 2007.
[8] "NAT Classification Results using STUN" by C. Jennings.
Internet Draft, IETF, October 2004 (archive).
[9] "Obtaining Relay Addresses from Simple Traversal Underneath NAT
(STUN)" by J. Rosenberg. Internet Draft, IETF, March 2007, work
in progress.
[10] "The Effects of NATs on the P2P Overlay Architecture" by E.
Cooper and P. Matthews. Internet-Draft, IETF March 2007, work
in progress.
[11] "Scribe: A large-scale and decentralized application level
multicast infrastructure" by M. Castro et al. IEEE Journal on
Selected Areas in Communications, October 2002.
http://freepastry.org/PAST/jsac.pdf
[12] "A Survey and Comparison of End-System Overlay Multicast
Solutions Suitable for Network Centric Warfare" by Cristina
Abad et al., NCSA and CS University of Illinois, SPIE 2004.
[13] "A Survey and Comparison of Peer-to-Peer Overlay Network
Schemes" by E.K. Lua et al. IEEE, March 2004.
http://www.cl.cam.ac.uk/teaching/2005/AdvSysTop/survey.pdf
Bryan Expires January 2008 [Page 30]
Internet-Draft P2PSIP Requirements June 2007
[14] "openDHT: A Public DHT Service, Ph.D. Thesis by Sean C. Rhea,
2005 http://srhea.net/papers/rhea-thesis.pdf
[15] "Pastry: Scalable, decentralized object location and routing
storage for large-scale peer-to-peer systems" by A. Rowstron
and P. Druschel. Proceedings of the IFIP/ACM , Nov. 2001.
[16] "Scalable peer-to-peer substrates: A new foundation for
distributed applications?" by P. Druschel and A. Rowstron. Rice
University and Microsoft Research.
[17] The Chord Project, see http://pdos.csail.mit.edu/chord/
[18] "The Bamboo Distributed Hash Table" web site at http://bamboo-
dht.org/
[19] "Kademlia" A Peer-to-peer Information System Based on XOR
Metric" by P. Mamounkov and D. Mazieres. Rice University 2002.
http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf
[20] "Handling of Churn in a DHT" by S. Rhea et al. USENIX Annual
Technical Conference, June 2004.
[21] "Non-Transitive Connectivity and DHTs" by M. Freedman et al.
Workshop on Real Large Distributed Systems conference 2005.
[22] David A. Bryan, Marcia Zangrilli, and Bruce B. Lowekamp,
Challenges of DHT Design for a Public Communications System
(pdf), William and Mary Technical Report WM-CS-2006-03, June
2006.
[23] "The Impact of DHT Routing Geometry on Resilience and
Proximity" by K. Gummadi et al. SIGCOMM conference 2003,
Karlsruhe, Germany.
http://www.sigcomm.org/sigcomm2003/papers/p381-gummadi.pdf
[24] XML-RPC, online at : http://xmlrpc.com
[25] "OpenDHT", online at: http://www.opendht.org
[26] "PlanetLab", online: http:// https://www.planet-lab.org
[27] S. Baset and H. Schulzrinne: "Peer-to-Peer Protocol (P2PP)",
Internet Draft, IETF, February 2007, work in progress
Bryan Expires January 2008 [Page 31]
Internet-Draft P2PSIP Requirements June 2007
[28] K. Singh and H. Schulzrinne: "Data format and interface to an
external peer-to-peer network for SIP location service", I-D,
IETF, May 2006, expired.
[29] "Security requirements in P2PSIP" by M. Matuszewski et al.
Internet-Draft, IETF, Feb. 2007, work in progress.
[30] S. Rhea, et al: "Open DHT: A Public DHT Service and Its Uses",
SIGCOMM'05, 2005. http://www.sigcomm.org/sigcomm2005/paper-
RheGod.pdf
[31] Douceur, J., "The Sybil Attack", IPTPS '02, March 2002.
[32] "P2P Trust Infrastructure" by R. Nelson et al. UCLA report,
2/13/2005. http://www.cs.ucla.edu/~rlnelson/trust.pdf
[33] "Simple SIP Usage Scenario for Applications in the Endpoints"
by H. Sinnreich et al. Internet-Draft, IETF, Sep. 2007, work in
progress.
Author's Addresses
David A. Bryan
SIPeerior; William & Mary
3000 Easter Circle
Williamsburg, VA 23188
USA
Email: bryan@ethernot.org
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Bryan Expires January 2008 [Page 32]
Internet-Draft P2PSIP Requirements June 2007
Salman A. Baset
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: salman@cs.columbia.edu
Henry Sinnreich
Adobe Systems Incorporated
601 Townsend Street
San Francisco, CA 94103
USA
Email: henrys@adobe.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Bryan Expires January 2008 [Page 33]
Internet-Draft P2PSIP Requirements June 2007
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bryan Expires January 2008 [Page 34]