Network Working Group S. Baset
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia University
Expires: January 3, 2008 July 2, 2007
Peer-to-Peer Protocol (P2PP)
draft-baset-p2psip-p2pp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Baset & Schulzrinne Expires January 3, 2008 [Page 1]
Internet-Draft Peer-to-Peer Protocol July 2007
Abstract
This document defines the Peer-to-Peer Protocol (P2PP), an
application-layer protocol, for creating and maintaining an overlay
of participant nodes. The overlay can be created using various
structured and unstructured peer-to-peer protocols such as Chord,
Pastry, Kademlia, Gnutella, and Gia.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of P2PP Functionality . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overall Design Approach . . . . . . . . . . . . . . . . . 9
4.2. P2PP Interface, Messages, and API . . . . . . . . . . . . 10
4.3. P2PP and SIP . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Request Routing . . . . . . . . . . . . . . . . . . . . . 12
4.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.1. Listening Ports . . . . . . . . . . . . . . . . . . . 14
4.6. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 14
4.7. Node Capabilities . . . . . . . . . . . . . . . . . . . . 14
5. P2PP Processing Overview . . . . . . . . . . . . . . . . . . . 15
5.1. Node State . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Request Generation and Response Processing . . . . . . . . 16
5.2.1. Issues in Recursive Routing . . . . . . . . . . . . . 16
5.2.2. Issues in Iterative Routing . . . . . . . . . . . . . 17
5.3. Request Processing and Response Generation . . . . . . . . 17
5.4. Message State Machine . . . . . . . . . . . . . . . . . . 19
5.4.1. Request State Machine . . . . . . . . . . . . . . . . 19
5.4.2. Response State Machine . . . . . . . . . . . . . . . . 21
5.5. Resource-object . . . . . . . . . . . . . . . . . . . . . 21
5.6. Routing-table Maintenance . . . . . . . . . . . . . . . . 22
5.7. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. LookupPeer . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. ExchangeTable . . . . . . . . . . . . . . . . . . . . . . 27
6.6. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7. Replicate . . . . . . . . . . . . . . . . . . . . . . . . 28
6.8. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.9. Publish (put) . . . . . . . . . . . . . . . . . . . . . . 28
6.10. LookupObject (get) . . . . . . . . . . . . . . . . . . . . 29
6.11. RemoveObject . . . . . . . . . . . . . . . . . . . . . . . 30
7. Bit-Level Formats and Errors . . . . . . . . . . . . . . . . . 31
Baset & Schulzrinne Expires January 3, 2008 [Page 2]
Internet-Draft Peer-to-Peer Protocol July 2007
7.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 31
7.2. General Object Format . . . . . . . . . . . . . . . . . . 32
7.3. P2PP TLV Objects . . . . . . . . . . . . . . . . . . . . . 33
7.3.1. Peer-Info . . . . . . . . . . . . . . . . . . . . . . 33
7.3.2. Request-Options . . . . . . . . . . . . . . . . . . . 35
7.3.3. P2P-Options . . . . . . . . . . . . . . . . . . . . . 36
7.3.4. Routing-Table . . . . . . . . . . . . . . . . . . . . 36
7.3.5. Neighbor-table . . . . . . . . . . . . . . . . . . . . 37
7.3.6. PLookup . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.7. Resource-Object . . . . . . . . . . . . . . . . . . . 38
7.3.8. Expires . . . . . . . . . . . . . . . . . . . . . . . 39
7.3.9. Owner . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3.10. Credentials . . . . . . . . . . . . . . . . . . . . . 39
7.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4.1. Error Object . . . . . . . . . . . . . . . . . . . . . 40
7.4.2. Response Codes . . . . . . . . . . . . . . . . . . . . 40
8. API between P2PP and Applications . . . . . . . . . . . . . . 42
8.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.3. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.4. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.5. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 50
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
14.1. Normative References . . . . . . . . . . . . . . . . . . . 51
14.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 54
A.1. Structured Overlays . . . . . . . . . . . . . . . . . . . 54
A.1.1. Chord . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1.2. Pastry . . . . . . . . . . . . . . . . . . . . . . . . 55
A.1.3. Kademlia . . . . . . . . . . . . . . . . . . . . . . . 56
A.1.4. Bamboo/OpenDHT . . . . . . . . . . . . . . . . . . . . 56
A.2. DHT Commonalities . . . . . . . . . . . . . . . . . . . . 57
A.3. Unstructured Overlays . . . . . . . . . . . . . . . . . . 58
A.3.1. Gia . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix B. Protocol design choices . . . . . . . . . . . . . . . 60
B.1. To SIP or not to SIP . . . . . . . . . . . . . . . . . . . 60
B.2. To ASCII or not to ASCII . . . . . . . . . . . . . . . . . 60
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 62
C.1. Join (Pastry) . . . . . . . . . . . . . . . . . . . . . . 62
C.2. Join (Gia) . . . . . . . . . . . . . . . . . . . . . . . . 65
C.3. Join (Chord) . . . . . . . . . . . . . . . . . . . . . . . 66
C.4. Lookup (Pastry) . . . . . . . . . . . . . . . . . . . . . 66
Baset & Schulzrinne Expires January 3, 2008 [Page 3]
Internet-Draft Peer-to-Peer Protocol July 2007
C.5. Lookup (Gia) . . . . . . . . . . . . . . . . . . . . . . . 67
C.6. Lookup (Chord) . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . . . . . 69
Baset & Schulzrinne Expires January 3, 2008 [Page 4]
Internet-Draft Peer-to-Peer Protocol July 2007
1. Introduction
This document defines Peer-to-Peer Protocol (P2PP) for creating and
maintaining an overlay of participant nodes. P2PP also allows non-
participant nodes to use overlay services through participant nodes.
The design of P2PP exploits commonalities in the peer-to-peer (p2p)
protocols such as Chord [12], CAN [13], Pastry [14], Kademlia [15],
and Gia [19] thereby defining a protocol that does not contain any
peer-to-peer protocol specific details and has an extension mechanism
to incorporate a protocol-specific feature. Though general in scope,
the specification does not claim that P2PP can be used to implement
any peer-to-peer protocol.
Baset & Schulzrinne Expires January 3, 2008 [Page 5]
Internet-Draft Peer-to-Peer Protocol July 2007
2. Overview of P2PP Functionality
P2PP is an application-layer protocol that can be used to form and
maintain an overlay of participant nodes. It provides mechanisms for
nodes to join and leave the overlay, and publish or search for a
resource-object in the overlay. A common aspect of these mechanisms
is to find an appropriate node in the overlay. A node can find an
appropriate node by maintaining tables of other nodes, called routing
and neighbor table. Since, an overlay can comprise a large number of
nodes, these tables only contains a subset of these nodes.
P2PP is a request-response protocol. For every request received, a
node checks if it can accomplish the request. If it cannot complete
the request, it sends the message to node(s) which is(are) most
likely to accomplish the request. A node determines the destination
of the request from its routing-table or neighbor-table by performing
a local nextHop() operation. This method of message forwarding is
known as recursive-routing. The routing methods are explained in
Section 4.4.
It is important to note that a node determines the next hop for a
message solely from its routing table; it does not consult any other
nodes. Different peer-to-peer protocols have different mechanisms
for determining the next hop for a request; however this is done on a
per-node basis. This aspect keeps the design of P2PP independent of
any existing peer-to-peer protocols.
Baset & Schulzrinne Expires January 3, 2008 [Page 6]
Internet-Draft Peer-to-Peer Protocol July 2007
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Some of the terminology has been borrowed from the P2P terminology
draft [8].
Node A node is an entity that runs an overlay protocol (peer) or can
access the services provided by an overlay network (client).
Overlay Peer (or Peer): A peer is a node participating in a P2PSIP
overlay that provides storage and routing services to other nodes
in the overlay and is capable of performing operations such as
join, leave, and routing requests within the overlay [8].
Client: A client is a node participating in a P2PSIP overlay that
provides neither routing nor storage and retrieval functions [8].
Peer-ID (or Peer Key): A Peer-ID is an information that uniquely
identifies a peer within a given P2PSIP overlay [8]. In DHT-based
overlays, this is a hash of the unique node identifier such as an
IP address. In unstructured overlays, this is an unhashed unique
identifier.
Identifier (ID or Key): An identifier is an information that
uniquely identifies a resource-object, a node, or a service.
Peer-ID is a form of identifier. We use the term identifier (ID)
and key interchangeably.
Routing Table: A routing table (finger table in Chord) is used by a
peer to locate a peer that either has a resource-object or offers
a certain service such as routing or NAT traversal. In a DHT-
based overlay, a peer's routing table contains a list of overlay
peer-IDs and their IP addresses stored against identifiers that
are exponentially away from the peer's identifier and thus has a
particular structure. Nodes in unstructured networks also
maintain a routing table. This specification does not put an
upper limit on the number of entries a node can store in its
routing table.
Note that the distinction between neighbor and routing table is an
artifact of structured peer-to-peer networks.
Baset & Schulzrinne Expires January 3, 2008 [Page 7]
Internet-Draft Peer-to-Peer Protocol July 2007
Routing Peers: The list of peers stored in a routing table are
called routing peers.
Neighbor Table: In a DHT-based overlay, a node's neighbor table
(successor list in Chord, leaf-set in Pastry) contains a list of
peers which are 'immediately' close to the node's identifier. The
purpose of the neighbor table is to maintain correctness. In an
unstructured overlay, nodes only maintain a routing table.
Resource-object: A resource-object is a blob of data stored in
P2PSIP overlay and is identified by a resource-ID. Examples of
resource-objects are SIP URIs, routing-records, file-names, and
service identifiers. Each resource-object has meta-data
associated with it such as content-type, content-usage, owner and
expiration-time. The meta-data can also be user defined.
Service: A node can offer services such as NAT and firewall
traversal, and relaying traffic for other nodes. A node
advertises its service capabilities in the overlay using a
resource-object. Different nodes can advertise the same service.
Hetrogeneous Network Environments: An hetrogeneous network
environment comprises of nodes that use different mechanisms for
network connectivity such as dialup, DSL, or broadband.
Overlay Implementer: An entity that uses P2PP to implement an
overlay.
Baset & Schulzrinne Expires January 3, 2008 [Page 8]
Internet-Draft Peer-to-Peer Protocol July 2007
4. Design Overview
4.1. Overall Design Approach
There are three high-level requirements for a peer-to-peer protocol.
P2P network maintenance: The protocol should provide mechanisms to
maintain connectivity and resource availability in a peer-to-peer
network.
Resource publishing and lookup: The protocol should provide a
mechanism for a peer to publish a resource-object or advertise its
service and a mechanism to lookup the resource-object and the node
offering a service.
Heterogenous connectivity: Nodes should be able to form an overlay
in heterogeneous network environments and exchange information
about their uptime and capacity.
P2PP allows nodes to form a structured or an unstructured overlay.
Nodes that participate in the routing and overlay maintenance
decisions are called peers (super-nodes in conventional P2P
terminology). Nodes that do not participate in an overlay are called
clients (ordinary-nodes in conventional P2P terminology). Clients
can use overlay services through peers. Multiple clients can
participate in the overlay through one peer but clients can also
communicate with multiple peers at the same time. Client and peers
communicate using the same protocol as peers do, i.e., there is no
distinct protocol for client-to-peer and peer-to-peer communication.
P2PP is a request-response protocol. Peers or clients can issue
requests which other peers can respond. The transmission of requests
and responses is governed by state machine described in Section 5.4.
The requests can be forwarded in a recursive or an iterative manner
as described in Section 4.4. The requests can also be forwarded in a
sequential or parallel manner.
The process to discover a peer already in the overlay is outside the
scope of this specification. Several techniques such as multicast,
cache of nodes during last connection, or an appropriate rendezvous
mechanism can be used [21] Once a node already in the overlay has
been discovered, a peer may be admitted into an overlay. The
specification does not specify the conditions under which a peer may
or may not be admitted into the overlay and leaves policy decisions
such as admission control to the implementers of an overlay. This
gives P2PP its desired flexibility.
The protocol allows nodes to exchange uptime, CPU and bandwidth
Baset & Schulzrinne Expires January 3, 2008 [Page 9]
Internet-Draft Peer-to-Peer Protocol July 2007
utilization, network bandwidth, and network connectivity information
with other nodes. Nodes can use this information to intelligently
construct their routing tables. However, P2PP does not mandate the
exchange of this information. (Open Issue: The meaning of these
terms needs to be precisely defined.)
The protocol can be used in different network environments. In an
Internet deployment, peers can have heterogeneous connectivity. An
overlay designer may configure a policy such that only peers with a
public IP address can participate in the overlay. In a corporate
deployment, most or all nodes, which participate in the overlay, may
be behind NATs or firewalls. As mentioned earlier, the protocol does
not enforce any restriction on which nodes may participate in the
overlay and leaves this decision to the overlay implementer. (Open
Issue: we will need a BCP draft for Internet and corporate
deployment.)
P2PP exposes an API which allows applications to use overlay
services.
4.2. P2PP Interface, Messages, and API
In P2PP:
An interface is an abstraction which groups together messages that
perform related functions.
API provides a mechanism for an application to use overlay services.
An API call can be accomplished using one or more P2PP messages.
A message is a P2PP protocol message that performs a certain
function.
This specification defines three interfaces for the P2PP protocol
namely:
o Service interface
o Data or resource interface
o Diagnostic interface
Baset & Schulzrinne Expires January 3, 2008 [Page 10]
Internet-Draft Peer-to-Peer Protocol July 2007
^
|
P2PP
Application +------------+ +-----------+
Level |SIP Proxy/UA| |Application|
| +------------+ +-----------+
V | |
================|=================|========= P2PP API
| |
^ +----------------------------------------+
| | P2PP: -service +-------------+|
| | -data | Node State ||
| | -diagnostic | Maintenance ||
| | +-------------+|
| +----------------------------------------+
| | | |
| ..........................................
P2PP . Transport Layer Security (TLS or DTLS) .
Transport ..........................................
Level | |
| +-----+ +-----+
| | UDP | | TCP | ... other
| +-----+ +-----+ protocols
| | |
| .............................
| . IP Layer Security .
| .............................
V | | |
=================================|========|========|=============
| | |
+------------------------------------+
| IP |
+------------------------------------+
Figure 1: Protocol stack architecture for P2PP
The service interface defines operations for node join, leave,
routing-table maintenance and replication. The data interface
defines operations for data (resource) insertion, lookup, and
removal. The diagnostic interface defines operations for gathering
peer statistics such as response time and relay bandwidth.
The implementer of a peer-to-peer service may be interested in
gathering various statistics such as response time and peer
bandwidth. The diagnostic interface defines operations for gathering
these statistics. (Open Issue: Note that some of these statistics
can also be gathered using functions defined in the maintenance
interface. Thus, it is currently not entirely clear whether
Baset & Schulzrinne Expires January 3, 2008 [Page 11]
Internet-Draft Peer-to-Peer Protocol July 2007
diagnostics should be considered as a separate interface or whether
its operations be included in the maintenance interface.)
P2PP messages begin with a header followed by a sequence of type-
length-value (TLV) objects. Each message is either a request or a
response. The response header is the same as a request header except
that it contains a response code. P2PP messages cannot be combined
in one message if an unreliable transport is used.
4.3. P2PP and SIP
SIP [2] is an application-layer protocol that can establish, modify,
and terminate multimedia sessions. SIP nodes can either send
requests to other SIP nodes directly or through a SIP proxy. A SIP
node (user-agent or proxy) typically uses a centralized location
service to determine the destination of the request. SIP nodes can
avoid the use of a centralized location service by sharing the
responsibility of a location service in a distributed way. The use
of P2PP allows a SIP node to accomplish this by creating an overlay
among participant nodes. The interface between P2PP and SIP is
defined through an API discussed in Section 8.
4.4. Request Routing
A peer can issue a request in a recursive or an iterative manner. In
recursive routing, the request traverses the peers until it reaches
the peer responsible for the resource-object if it exists. The peer
issuing the request has no control over the peers which the request
may traverse. In iterative routing, the peer sends a request to
another peer which replies with the network address of the peer to
which the request should be forwarded. The requesting peer then
forwards the request directly to this peer. In this way, the
requesting peer has control over the peers through which the request
is forwarded.
A request can also be forwarded in an iterative parallel way. The
requesting peer can send the request to multiple peers at the same
time. The requesting peer designates one request copy as primary.
(Open Issue: What are the benefits of designating one copy as
primary?)
The choice of using recursive or iterative routing is on a per-
request rather than per-overlay basis.
4.5. Transport
A node may decide to send the request over a reliable or unreliable
transport in a recursive or an iterative manner. This section
Baset & Schulzrinne Expires January 3, 2008 [Page 12]
Internet-Draft Peer-to-Peer Protocol July 2007
explores various tradeoffs in the use of reliable vs. unreliable
transports for request forwarding and recommends the use of reliable
transport such as TCP unless otherwise specifically noted.
The node issuing the request determines the destination for the
request by applying a local nextHop() operation on its routing and
neighbor-table. A node may have a reliable connection such as TCP
with some or all of its routing and neighbor table entries. If
recursive routing is used, a node should send the request over a
reliable transport to the node(s) returned by the nextHop()
operation, if it has a reliable connection with them. Otherwise, it
may send the request over an unreliable transport such as UDP.
If iterative routing is used, the request originator will receive a
302 (Next Hop) reply from the peer it sent the request, if that peer
cannot accomplish the request. The request originator must now send
the request to this next hop. It is quite unlikely that the request
originator will have a reliable transport connection with the next
hop peer received in the 302 response and will have to establish a
reliable transport connection if it were to prefer the use of
reliable transport. Thus, an application may prefer the use of
unreliable transport such as UDP, if iterative routing is used.
In a peer-to-peer network, a node is only concerned with its own
routing peers. It does not necessarily need to know which other
peers have this node in their routing tables. Using TCP for overlay
maintenance will require that a node not only manages TCP connections
for its own routing tables, but also accept incoming TCP connections
for other nodes' routing tables. In a Chord network with N peers, a
peer will need to maintain logN connections for its routing table.
It will also receive logN connections from other peers for their
routing tables. Thus, it will at least need to maintain 2*logN
connections. The typical buffer space per socket is eight kilobytes,
and maintaining 300 connections consumes a total memory of 2.4 MB,
which is a little fraction of the total memory current systems have.
(Open Issue: what are the other implications of maintaining TCP
connections for routing-table entries? What about many simultaneous
connections from one IP address resulting from multiple applications
or NAT?)
Security is a concern for peer-to-peer deployments and peers may
choose TLS over TCP as the underlying transport protocol. Since, the
peers can have heterogeneous capabilities, it is an open issue
whether using a light-weight TLS-like protocol might be better than
TLS over TCP.
A peer receiving the request MUST use the same transport and port to
send the response. If the request was sent over UDP, and the
Baset & Schulzrinne Expires January 3, 2008 [Page 13]
Internet-Draft Peer-to-Peer Protocol July 2007
response size may exceed MTU, the peer should reply with a 413
(Message Too Large) response. It is up to the peer issuing the
request to send the request over a reliable transport such as TCP.
4.5.1. Listening Ports
The specification proposes a standard UDP and TCP listening port to
be assigned by IANA. The current implementation uses port 7080 for
both UDP and TCP listening.
4.6. NAT and Firewall Traversal
In an Internet scale deployment, it is possible that some nodes are
behind NATs and firewalls. It is up to the implementer of the
overlay to decide whether there is a need to perform NAT or firewall
traversal. If so, then the peers SHOULD implement STUN [5], TURN
[6], and ICE [7] protocols and advertise this as a service in the
overlay. Many peers can advertise NAT traversal service under a
particular service name which is stored as a resource-object. One
possible option for peers is to choose the same name for NAT and
firewall traversal service in which case they will publish their
service advertisement at the same peer in the overlay. Node queries
looking for a NAT traversal peer will always end up at the same peer.
Another option is to use ReDiR mechanism [10] which allows
distributing service registration over multiple nodes and still do
logN lookups. (Open Issue: what are the possible approaches for
advertising NAT and firewall traversal service? Perhaps use AS or
network coordiantes? ReDiR mechanism needs further elaboration.)
4.7. Node Capabilities
A peer MAY advertise its capabilities such as its link bandwidth, CPU
and bandwidth utilization. Advertising link bandwidth and its
utilization is useful because it determines whether a peer can be
used as a relay for TURN [6]. It is currently an open issue what is
the best way for a node to reasonably estimate these quantities. One
option is that nodes can advertise a service that uses STUN to
estimate bandwidth. The nodes looking to estimate their link
bandwidth can then locate the peers advertising bandwidth estimation
service.
Baset & Schulzrinne Expires January 3, 2008 [Page 14]
Internet-Draft Peer-to-Peer Protocol July 2007
5. P2PP Processing Overview
5.1. Node State
A P2PP peer maintains the following state:
Peer-to-Peer Algorithm: Peer-to-peer algorithm of the overlay.
Overlay-ID: ID of the overlay this peer is part of.
Hash Algorithm: The hash algorithm, if any, being used.
Uptime: The uptime of this peer.
Routing Table: A table of other peers in the overlay. For each
peer, following information is maintained.
Peer-ID: The ID of the peer. For a structured p2p algorithm,
it is typically the hash of the IP address of the peer.
Otherwise, it can be an IP address or some unique ID.
IP address: The IP address of the peer.
RTT: The round-trip-time of this peer. If TCP is used, an
application may obtain this value from the TCP stack if the
underlying OS supports it.
Uptime: The uptime of the peer.
Neighbor Table: A table of peers with ID adjacent to the peer's ID
in a structured overlay. For each peer, following information is
maintained.
Peer-ID: The ID of the peer. For a structured p2p algorithm,
it is typically the hash of the IP address of the peer.
Otherwise, it can be an IP address.
IP address: The IP address of the peer.
RTT: The round-trip-time of this peer.
Uptime: The uptime of the peer.
Number of Neighbors: Total number of peers in routing and neighbor
tables.
Baset & Schulzrinne Expires January 3, 2008 [Page 15]
Internet-Draft Peer-to-Peer Protocol July 2007
Resource Table: Resource-objects this peer is responsible for.
Replicated Resource Table: Resource-objects this peer stores as
backup for other objects.
5.2. Request Generation and Response Processing
A request can be issued in a recursive or an iterative manner. A
node forwarding a request creates a request transaction and passes it
the request to deliver it to the intended recipient. Each
transaction is identified by a random and unique 32-bit unsigned
integer called transaction-ID. The request is generated and
responses are processed according to the following rules:
1. Requests cannot be combined. (Open Issue: It does not matter
over TCP)
2. The transport of the request SHOULD be preserved, i.e., if the
request was received over TCP, it SHOULD be forwarded over TCP.
See Section 5.2.1 for additional considerations.
3. A peer issuing the request MAY request to receive a copy of the
routing and neighbor tables of the peer to whom the request was
sent. It does so by setting the request-routing-table and
request-neighbor-table flags in the Request-Options object.
Considerations apply for recursive (Section 5.2.1) and iterative
routing (Section 5.2.2).
4. If the peer issuing the request receives a 480 Alternative
Service response, it SHOULD retry the request over TCP directly
to the peer which generated this response.
5. The request SHOULD be sent over TCP if its size exceeds UDP MTU
regardless of whether recursive or iterative routing is being
used.
6. The response is matched to the appropriate request transaction by
the transaction-ID.
Following considerations apply if the request is being issued in a
recursive or an iterative manner.
5.2.1. Issues in Recursive Routing
The request can be sent over TCP or UDP by the originator. (Open
Issue: should only TCP or UDP be used for request forwarding?)
If the request was sent over UDP, the node issuing the request SHOULD
Baset & Schulzrinne Expires January 3, 2008 [Page 16]
Internet-Draft Peer-to-Peer Protocol July 2007
always set the in-separate-request flag in the Request-Options
object. The reason is that the routing and neighbor tables of the
nodes encountered along the path of the request are not likely to fit
within the response UDP packet.
If request was sent over TCP and request-routing-table and request-
neighbor-table flags were set, each node along the request path adds
a copy of its routing or neighbor table in the response (Open Issue:
The response size can explode). If the node issuing the request
wishes to receive a copy of routing or neighbor table not in the
response but in a separate request, it sets the in-separate-request
flag in the Request-Options object.
If recursive routing is being used, and a peer receives a response,
it consults the transaction-association (TA) table. If it finds a
matching entry, it forwards the response to the peer from which it
received the request. If request was sent over TCP and request-
routing-table and request-neighbor-table flags were set and in-
separate-request flags were not set, the peer forwarding the response
adds a copy of its own routing or neighbor table and updates the
message length in the common header.
5.2.2. Issues in Iterative Routing
The request SHOULD be sent over UDP if the request size fits within
UDP MTU.
If the request was sent in an iterative manner over TCP, the node
SHOULD not set the in-separate-request flag.
If the request was sent in an iterative manner over UDP, the node
issuing the request MAY set the partial-reply flag in the Request-
Options object. If set, the node receiving the request includes in
its reply as much routing or neighbor table peers as permitted by the
UDP MTU. A node issuing the request MAY also set partial-reply and
in-separate-request flags in the Request-Options object. A node
receiving the request with these flags set includes in its reply its
routing or neighbor entries as permitted by the UDP MTU. It sends
the remaining portion of routing or neighbor table in a separate
ExchangeTable request.
5.3. Request Processing and Response Generation
A request can be received over UDP or TCP. A request received over
UDP is processed according to the following steps:
1. The peer checks the TTL field in the common header. If TTL is
equal to zero and the peer cannot give a definitive answer, it
Baset & Schulzrinne Expires January 3, 2008 [Page 17]
Internet-Draft Peer-to-Peer Protocol July 2007
MUST reply with a 410 TTL Hops Exceeded response. The response
is always sent to the peer from whom the request was received and
not to the peer who issued the request.
2. If TTL is greater than zero, recursive routing was being used,
and the peer cannot give a definitive answer for the received
request, it determines the next hop from its routing or neighbor
tables, creates a new request transaction, and passes it the
request after decrementing TTL by one in the common header. The
rest of the forwarded request remains unchanged. The peer
creates a transaction association (TA) between the response and
request transactions. Also, the peer MUST immediately send a 100
Trying response using the same transport and port on which the
request was received. (Open Issue: Can we eliminate 100 Trying
altogether?)
3. If TTL is greater than zero, iterative routing was being used,
and the peer cannot satisfy the request, it determines the next
hop from its routing or neighbor tables. It then replies with a
302 Next Hop response and includes its Peer-Info and the next hop
Peer-Info object in the response.
4. If a peer receiving the request determines that it can give a
definitive answer which will fit within UDP MTU, it checks if the
Request-Options object was present and that request-routing-table
or request-neighbor-table and in-separate-request flags were set.
If set, the peer waits for a random time between T2 and T3
seconds, and sends a copy of its routing or neighbor table or
both in an ExchangeTable request to the peer which issued the
request. If in-separate-request was not set, the peer generating
a definite response includes in the response as much of the
requested routing or neighbor table entries as permitted by the
UDP MTU.
5. If the peer receiving the request determines that it can give a
definitive answer but the response will not fit within UDP MTU,
it can reply with a 413 Message Too Large or a 480 Alternative
Service response to indicate to the node issuing the request to
retry the request over TCP.
6. The peer checks if it can update its routing and neighbor tables
from the received request.
A request received over TCP is processed according to the following
steps:
1. The peer checks the TTL field in the common header. If TTL is
equal to zero and the peer cannot give a definitive answer, it
Baset & Schulzrinne Expires January 3, 2008 [Page 18]
Internet-Draft Peer-to-Peer Protocol July 2007
MUST reply with a 410 TTL Hops Exceeded response. The response
is always sent to the peer from whom the request was received and
not to the peer who issued the request.
2. If TTL is greater than zero, recursive routing was being used,
and the peer cannot give a definitive answer for the received
request, it determines the next hop from its routing or neighbor
tables, creates a new request transaction, and passes it the
request after decrementing TTL by one in the common header. The
rest of the forwarded request remains unchanged. The peer
creates a transaction association (TA) between the response and
request transactions.
3. If TTL is greater than zero, iterative routing was being used,
and the peer cannot satisfy the request, it determines the next
hop from its routing or neighbor tables. It then replies with a
302 Next Hop response and includes its Peer-Info and the next hop
Peer-Info objects in the response.
4. If a peer receiving the request determines that it can give a
definite answer, it checks if the Request-Options object was
present and that request-routing-table or request-neighbor-table
and in-separate-request flags were set. If set, the peer waits
for a random time between T2 and T3 seconds, and sends a copy of
its routing or neighbor table or both in an ExchangeTable request
to the peer which issued the request. If in-separate-request was
not set, the peer includes a copy of its routing and neighbor
table in the response.
5.4. Message State Machine
(Open Issue: The state machines for reliable and unreliable
transports need to be combined.)
5.4.1. Request State Machine
The request transaction state machine for unreliable transports is
shown in Figure 1.
The "Trans_Req" (abbreviation for transmit request) state is entered
when a peer issues or forwards a request. When entering this state,
the transaction SHOULD set timer T2 to fire in T1 seconds. It SHOULD
initialize variable n to zero. If Timer T2 fires and n is less than
the maximum allowed retransmissions N, the request is retransmitted,
n is incremented and timer T2 is set to fire in (2^n * T1) seconds.
If timer T2 fires and n is equal to N, the state machine transitions
to "Failed" state and is terminated.
Baset & Schulzrinne Expires January 3, 2008 [Page 19]
Internet-Draft Peer-to-Peer Protocol July 2007
If a 2xx-4xx response is received, the transaction enters "Success"
state and is terminated.
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Request / set Timer T2
Timer T2 fires / |
If n != N V Transport Err. or
reset T2 +------------+ Timer T2 fires and
tx_Request +------| | n == N
| | Trans_Req |---------------+
+----->| | |
+------------+ |
| |
| rx_Resp (2xx-4xx) / |
| Pass to app. |
V |
+-----------+ |
| | |
| Success | |
| | |
+-----------+ |
|
|
+-----------+ |
| | |
| Failure |<---------------+
| |
+-----------+
Figure 2: request transaction for unreliable transports
The request transaction state machine for reliable transports is
shown in Figure 2.
The "Trans_Req" state is entered, when a peer issues or forwards the
request. When entering this state, it SHOULD set timer T5. The
value of T5 is application dependent. If timer T5 fires, the state
machine transitions to "Failed" state and is terminated. If a 2xx-
4xx response is received, the state machine transitions to "Success"
state and is terminated. If the request was forwarded in a recursive
manner, the application MUST not terminate the reliable-transport
connection. If the request was forwarded in an iterative manner, an
Baset & Schulzrinne Expires January 3, 2008 [Page 20]
Internet-Draft Peer-to-Peer Protocol July 2007
application MAY terminate the reliable-transport connection if it
does not anticipate its reuse.
+-----------+
| |
| Initial |
| |
+-----------+
|
| tx_Request / set Timer T5
|
V
+------------+ Transport Err. or
| | Timer T5 fires
| Trans_Req |---------------+
| | |
+------------+ |
| |
| rx_Resp (2xx-4xx) / |
| Pass to app. |
V |
+-----------+ |
| | |
| Success | |
| | |
+-----------+ |
|
|
+-----------+ |
| | |
| Failure |<---------------+
| |
+-----------+
Figure 3: request transaction for reliable transports
5.4.2. Response State Machine
There is no state machine for responses. Each request generates a
response.
If recursive routing is being used and the request is received over
an unreliable transport, a 100 Trying response SHOULD be sent.
5.5. Resource-object
Baset & Schulzrinne Expires January 3, 2008 [Page 21]
Internet-Draft Peer-to-Peer Protocol July 2007
5.6. Routing-table Maintenance
5.7. Timers
This section defines timers for request and response state machines.
Timer Value
----------------------
T0 5s
T1 500ms
T2 T0
T3 2*T0
T5 T0 (Application dependent)
T6 T0 (Application dependent)
Baset & Schulzrinne Expires January 3, 2008 [Page 22]
Internet-Draft Peer-to-Peer Protocol July 2007
6. Message Formats
All P2PP messages begin with a common header, followed by a sequence
of type-length-value (TLV) objects. This section describes all P2PP
messages and their contents at a high level in ABNF [4].
We define eight messages for service interface namely, join, leave,
keep-alive, lookuppeer, exchangetable, query, replicate, and transfer
and three messages for data interface namely, publish, lookupobject
and removeobject.
P2PP-Msg = Join / Leave / Keep-alive /
LookupPeer / ExchangeTable / Query / Replicate / Transfer
Publish / LookupObject / RemoveObject
A node (client) which does not participate in an overlay does not
need to implement all of these messages. Client-to-peer messages are
independent of the p2p algorithm being used. The peer-to-peer
messages are also independent of the p2p algorithm being used because
a peer locally determines the next hop after consulting its routing
or neighbor tables. Note that peers in an overlay only run one type
of p2p algorithm such as Chord, Pastry, Kademlia or Gnutella and
there is no mixing of the p2p algorithm, i.e., it is not possible for
some nodes in the same overlay to only use Chord and some nodes to
only use Pastry. However, a peer can simultaneously participate in
two different overlays.
6.1. Join
To insert itself in the overlay, a node sends a join request to a
peer already in the overlay. The mechanism to discover a peer
already in the p2p network is independent of any particular p2p
algorithm being used [21]. The possible neighbors of this new node
MUST be informed about the join request.
A node MUST send a Query request to a discovered node before a join
request. The Query request is used to determine overlay parameters
such as overlay-ID, peer-to-peer and hash algorithms, and request
routing method (recursive vs. iterative) being used.
The node then constructs a join request and passes it to the request
transaction. The node that wishes to participate in the overlay MUST
set the 'insert' flag in the Request-Options object. The node that
does not wish to participate in the overlay MUST NOT set the 'insert'
flag in the overlay. The peer receiving a join request from a client
does not forward it to other peers in the overlay and immediately
returns a 200 (Ok) response. (ToDo: Remove 'insert' flag and instead
Baset & Schulzrinne Expires January 3, 2008 [Page 23]
Internet-Draft Peer-to-Peer Protocol July 2007
check the P (peer or client) flag in the common header.)
A peer MAY request to receive a copy of routing and neighbor tables
of the nodes which receive the join request. It does so by following
the rules defined in Section 5.2
Join = Common-header
Request-Options
Peer-Info
If a node receiving the join request is not the immediate neighbor of
this joining peer, and recursive routing is being used, it forwards
the request to a suitable peer by following the rules defined in
Section 5.3.
A peer receiving an iterative join request sends a 302 Next Hop
response about the next hop if the joining peer will not be its
immediate neighbor.
If a peer receiving the request determines that the joining node will
be its neighbor, it MUST send a 200 (Ok) response to the node from
which it received the request. The response contains the time before
which the joining peer SHOULD send a keep-alive message. The
response SHOULD also contain a copy of the neighbor table of the
peer.
Once the node issuing the join request receives a 200 (Ok) response,
it checks the received neighbor table. It then sends a join request
with the S flag set in the Request-Options object to each of the
neighbors. The join request with S flag set indicates the nodes that
the joining node will be their new neighbor. It is really up to the
peer generating the 200 (Ok) response to decide, based on the p2p
algorithm being used, which neighbors (successors, predecessors) a
joining peer may contact to insert itself appropriately in the
overlay. The neighbors of this newly joining peer SHOULD update
their neighbor and routing tables appropriately. After the receipt
of the join request, the neighbors wait for a random time before
exchanging their neighbor tables.
Peers in the overlay MAY decide to reject a join request with a 407
Request Rejected response because it does not satisfy the overlay
policy. NAT and node capacity examples of such policies. This
specification does not specify any policy for the node admission and
defers this decision to the overlay implementer.
Peers in the overlay MAY not be willing to admit a new node with no
history about its uptime. If so, they reply with a 407 Join Request
Deferred response and an Expires object after which the peer can
Baset & Schulzrinne Expires January 3, 2008 [Page 24]
Internet-Draft Peer-to-Peer Protocol July 2007
reissue the join request. The peer receiving this response SHOULD
resend the join request with 'insert' flag reset in the Request-
Options object to insert itself as a client in the overlay. It
SHOULD retry the join request after the passage of time in the
Expires object.
Join (Resp) = Common Header
Response-code
Peer-Info
[Peer-Info]
[Expires]
[Routing-table]
[Neighbor-peers]
[Ext]
Routing-table = Num-entries
[Peer-Info]*
Neighbor-peers = Num-entries
[Peer-Info]*
6.2. Leave
A peer sends a leave request to gracefully inform its neighbors about
its departure. The neighbors MUST update their neighbor pointers and
take over the peer-IDs and resource-objects the leaving node is
responsible for.
A peer SHOULD send the leave message over TCP as the size of peer-IDs
and resource-objects is likely to exceed MTU. However, a peer SHOULD
avoid a new TCP connection to send the leave message.
A peer receiving a leave request MUST immediately respond with a 200
(Ok).
A client MAY also send a leave message to inform its routing peers
about its impending departure.
(Open Issue: The user should not have to wait for the p2p application
to shut down, which in turn is waiting for the receipt of leave
response.)
Leave = Common-header
Peer-Info
[Peer-Info]*
[Resource-object]*
Baset & Schulzrinne Expires January 3, 2008 [Page 25]
Internet-Draft Peer-to-Peer Protocol July 2007
Leave (Resp) = Common-header
Peer-Info
6.3. Keep-alive
A peer sends a periodic keep-alive message to its routing and
immediate peers. A peer MUST send keep-alive to its neighbor and
routing table peers before the expiry of their refresh interval. The
two immediate neighbors do not need to send a periodic keep-alive
message to each other and can use various heuristics for keep-alive
timer duration such as randomly sending a keep-alive within an
interval. Also, it is possible that a peer may receive a request
from its neighbors before the expiry of the keep-alive timer. The
arrival of the request should be considered as the receipt of a keep-
alive message and the expiry timers should be updated accordingly.
If a neighbor fails, a peer may have to immediately find a new
neighbor to ensure lookup correctness using LookupPeer request. If a
routing entry fails, a node may choose to repair it immediately or
defer till a lookup request arrives.
Keep-alive can be considered as a lookup message for an existing
entry in the routing table. Keep-alives SHOULD be sent over UDP.
(Open Issue: Should Keep-alives be sent when a node has a TCP
connection with its neighbor and routing peers?)
Keep-alive = Common-header
Peer-Info
Expires
A peer receiving a keep-alive request responds with a 200 (Ok)
response and includes an Expires object. The request originator MUST
send another request before the expiration of this time.
Keep-alive (Resp) = Common-header
Peer-Info
Expires
6.4. LookupPeer
A peer MAY send a lookuppeer message to update its routing or
neighbor table entries. For DHTs, a peer lookup is different from an
ordinary lookup message because the requesting peer is seeking a
peer(s) whose peer-ID may immediately succeed or precede a certain ID
or may lie within a range of IDs.
LookupPeer = Common-Header
Peer-Info
Baset & Schulzrinne Expires January 3, 2008 [Page 26]
Internet-Draft Peer-to-Peer Protocol July 2007
PLookup
A peer receiving an iterative routing-peer lookuppeer request will
send a 302 Next Hop response there is another peer with peer-ID close
to the peer-ID being searched for.
LookupPeer (resp) = Common-Header
Peer-Info
[Peer-Info]
6.5. ExchangeTable
A peer sends a exchangetable request to another peer to request a
copy of its neighbor or routing table. A peer SHOULD send an
exchangetable request over TCP since the size of the routing table is
likely to exceed the MTU size.
ExchangeTable = Common-Header
Peer-Info
ExchangeTable (resp) = Common-Header
Peer-Info
[Routing-table]
[Neighbor-peers]
6.6. Query
A peer sends a query request to any peer in the overlay requesting
information about the overlay algorithm, the hash algorithm (if any),
key size, and overlay-ID. A peer MUST send the query request to an
existing peer in the p2p network before sending a join request.
Query = Common-Header
Peer-Info
Query (resp) = Common-Header
Peer-Info
P2P-options
[Ext]
P2P-options = Hash-algorithm
Hash-algorithm-length
DHT-algorithm
OverlayID-length
Overlay-ID
Baset & Schulzrinne Expires January 3, 2008 [Page 27]
Internet-Draft Peer-to-Peer Protocol July 2007
The Ext denotes that this message is extensible and additional TLV
objects may be added later.
6.7. Replicate
A peer can replicate its resource-objects using the Replicate
request. The choice of nodes on which the resource-objects should be
replicated is left to the implementer of the overlay. Heuristics
such as replicate to the next k neighbors of this node can be used.
A node needs to replicate data to its replica neighbors when a
resource-object is added or modified. The replicate request SHOULD
be sent over TCP.
Replicate = Common-header
Peer-Info
[Peer-Info]*
[Resource-object]*
Replicate (Resp) = Common-header
Peer-Info
6.8. Transfer
A peer already in the overlay uses transfer request to transfer the
resource-objects to the newly joining node. Similarly, a peer
gracefully leaving the p2p network uses transfer request to transfer
its resource-objects to its neighbors.
Transfer = Common-header
Peer-Info
[Peer-Info]*
[Resource-object]+
Transfer (Resp) = Common-header
Peer-Info
6.9. Publish (put)
A peer sends an publish request to a peer already in the p2p network
to insert a resource-object. The publish operation involves locating
the peer responsible for the resource-object and then inserting
either the network address of the resource-object publisher or the
resource-object itself. The publish operation can also be used to
update an existing resource-object.
The publisher of the resource-object MUST also include information
about its owner in the publish request because the it is not
Baset & Schulzrinne Expires January 3, 2008 [Page 28]
Internet-Draft Peer-to-Peer Protocol July 2007
necessarily the owner of the resource-object. It is possible that
multiple owners may wish to publish or update an existing resource-
object and a peer may want to retrieve part of the resource-object
published or updated by a certain owner. (Open Issue: What is the
format of the owner object?)
The semantics of the resource-object are managed by the application.
P2PP only requires each resource to have a resource-ID.
Publish = Common-header
Peer-Info
Request-Options
Resource-Object
Insert (Resp) = Common-header
Response-code
Expires
6.10. LookupObject (get)
A peer issues a lookupobject request to retrieve a resource-object
from the p2p network. It includes the Resource-object TLV in the
request and sets the 'I' flag to zero.
The resource-object size may exceed UDP MTU if the request was sent
over UDP. The node responsible for the resource-object replies with
a 480 (Alternative Service) response. The querier, on receiving this
response, reissues the lookup request over TCP to the peer
responsible for the resource-object.
Lookup = Common-header
Peer-Info
Request-Options
[Owner]
Resource-object
If the resource-object is found, the peer responsible for it replies
with a 200 (Ok) response. If a peer receiving a lookup request
determines that it cannot forward the request, it generates a 404
(Not Found) response.
Lookup (resp) = Common-header
Peer-Info
Resource-object
Baset & Schulzrinne Expires January 3, 2008 [Page 29]
Internet-Draft Peer-to-Peer Protocol July 2007
6.11. RemoveObject
A node sends the remove request to remove the resource-object before
its lifetime expiration.
Remove = Common-header
Peer-Info
[Owner]
[Resource-object]
Remove (Resp) = Common-header
Peer-Info
Baset & Schulzrinne Expires January 3, 2008 [Page 30]
Internet-Draft Peer-to-Peer Protocol July 2007
7. Bit-Level Formats and Errors
This section defines PDUs for the messages and their methods defined
above.
7.1. Common Header
All P2PP messages begin with a common header. It has a fixed format,
as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=3 |T|P| Reserved | Request Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (3 bits): The protocol version number. The current version
is 1.
T flag: If set (T=1), the message is a request. Otherwise, it is a
response.
P flag: If set (P=1), the message is sent by a peer. Otherwise, a
client is request originator.
Request Type (8 bits): The request message type such as join and
leave.
TTL (8 bits): A hop count for the number of peers this request can
traverse. (Open Issue: Upper limit of 256 maybe too stringent.
If TTL becomes zero, a node replies with a 410 TTL hops exceeded
response. The request can then be reissued to the node generating
410 response.)
Magic cookie (32 bits): A field with a fixed value (0x596ABF0D) to
differentiate P2PP messages from other protocol messages from
other protocols such as STUN.
Baset & Schulzrinne Expires January 3, 2008 [Page 31]
Internet-Draft Peer-to-Peer Protocol July 2007
Transaction-ID (32 bits): A unique number to match responses with
the originated requests.
Message Length (32 bits): The byte length of the message after the
common header itself.
For responses, the rightmost 10-bits of the Reserved field contain
the response code.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=3 |T|P|r| Response code | Request Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.2. General Object Format
Each P2PP object begins with a fixed header giving the object type
and length. This is followed by the object Value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Object-Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AB=00 "(Mandatory)": If the object is not understood, the entire
message containing it MUST be rejected with an "Object Type Error"
message with sub code 1 ("Unrecognized Object").
AB=01 "(Ignore)": If the object is not understood, it MUST be
deleted and the rest of the message processed as usual.
Object-Type (8 bits): An IANA-assigned identifier for the type of
the object.
Length (16 bits): The byte length of the object.
The combination AB=10 and AB=11 are reserved.
Baset & Schulzrinne Expires January 3, 2008 [Page 32]
Internet-Draft Peer-to-Peer Protocol July 2007
7.3. P2PP TLV Objects
7.3.1. Peer-Info
Type: Peer-Info
Length: Variable (depends on the length of Peer-ID, IP version and
unhashed key if any. It can include Uptime, Neighbor/
resource-utilization, and NAT and firewall TLV objects.)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Additional Information :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-ID (variable): The fixed-length output of the hash function
negotiated at join. If the Algorithm-Len field queried at join is
zero, a length field of 16 bits MUST be present before Peer-ID.
Unhashed-ID TLV object MUST NOT be included.
Additional Fields: Various additional fields that may be useful for
a particular network environment. Their inclusion is left to the
overlay implementer.
7.3.1.1. Additional Information Fields
Unhashed ID:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Unhashed-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unhashed-ID (variable): Unhashed ID of this peer. This is only
included in a DHT-based overlay. If the unhashed-ID is the same
as IP-address of the peer, it SHOULD NOT be included.
Uptime:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime |
Baset & Schulzrinne Expires January 3, 2008 [Page 33]
Internet-Draft Peer-to-Peer Protocol July 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Uptime (32 bits): The uptime of this peer in number of seconds.
Resource-Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Neighbors | CPU Util. | BW. Util. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Neighbors (16 bits): The number of routing and immediate
neighbors of this peer.
CPU Utilization (8 bits): CPU Utilization of this peer on a scale of
1 to 100.
Bandwidth Utilization (8 bits): Bandwidth utilization of this peer
on a scale of 1 to 100.
Peer Bandwidth (32 bits): Estimated peer bandwidth in kilo bits per
second. This is tricky to determine and is TBD.
Address-Info:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver | Num | HT |Reserved| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Ver (4 bits): The IP version number, 4 or 6.
Num (4 bits): Number of peer IP address, port, transport and address
type 4-tuples gathered using Interactive Connectivity
Establishment (ICE) [7].
HT (4 bits): The address type of the peer as defined in ICE [7].
One of host (0000), server reflexive (0001), peer reflexive
(0010), or relayed candidate (0011).
Baset & Schulzrinne Expires January 3, 2008 [Page 34]
Internet-Draft Peer-to-Peer Protocol July 2007
Peer Address (variable): The IP address of the peer. Its length
depends on the IP-Ver field.
Port (16 bits): The port on which this peer listens for requests.
7.3.2. Request-Options
Type: Request-Options
Length: Fixed (32-bit word)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|P|R|N|E|A|S| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I (1 bit): If set (I=1), then insert this peer in the overlay at
join. A P2PSIP client MUST set this bit to zero.
P (1 bit): If set (P=1), designate one copy as primary for parallel
lookups.
R (1 bit) request-routing-table: If set (R=1), send a copy of the
routing table to the peer issuing the request in a seperate
ExchangeTable request. The transmission of routing-table copy is
governed by the in-separate-request and partial-copy flags.
N (1 bit) request-neighbor-table: If set (N=1), send a copy of the
neighbor table to the peer issuing the request using the mechanism
described for routing-table.
E (1 bit) in-separate-request: If set (E=1), and if P or R are also
set, the peer is requesting to receive routing or neighbor table
in an ExchangeTable request. If not set (E=0), and the request
was received over TCP, each peer along the request path can add a
copy of its routing or neighbor table before forwarding the
response.
A (1 bit) partial-reply: If set (A=1), the peer generating the
definite response sends a copy of the routing or neighbor table as
determined by the P and N flags in its response as permitted by
the UDP MTU. If E (in-separate-request) is also set, the rest of
the routing or neighbor table is sent in a separate Update
request.
Baset & Schulzrinne Expires January 3, 2008 [Page 35]
Internet-Draft Peer-to-Peer Protocol July 2007
S (1 bit): If set (S=1) and if I flag is also set, the request is
being sent to the immediate neighbors of the newly joining peer.
7.3.3. P2P-Options
Type: P2P-Options
Length: Variable (depends on the length of Overlay-ID)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Algorithm-Len | P2P-Algorithm | OverlayID-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base | Overlay-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R flag: If set (R=1), the peers in the overlay use recursive request
forwarding.
Algorithm (6 bits): An IANA-assigned identifier for the hash
algorithm.
Algorithm-Length (8 bits): The byte length of the hash algorithm.
If set to zero, then no hash algorithm is used.
P2P-Algorithm (8 bits): An IANA-assigned identifier for the P2P
algorithm being used.
OverlayID-Length (8 bits): The byte length of overlay-ID.
Overlay-ID (variable): Overlay-ID.
7.3.4. Routing-Table
Type: Routing-Table
Length: Variable (depends on the number of Peer-Info objects)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num entries | |
+-+-+-+-+-+-+-+-+ [Peer-Info]+ +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baset & Schulzrinne Expires January 3, 2008 [Page 36]
Internet-Draft Peer-to-Peer Protocol July 2007
Num-entries (8 bits): Number of Peer-Info objects in the routing
table.
Peer-Info (variable): One or more Peer-Info objects.
7.3.5. Neighbor-table
Type: Neighbor-Table
Length: Variable (depends on the number of Peer-Info objects)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num entries | |
+-+-+-+-+-+-+-+-+ [Peer-Info]+ +
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num-entries (8 bits): Number of Peer-Info objects in the neighbor
table.
Peer-Info (variable): One or more Peer-Info objects.
7.3.6. PLookup
Type: PLookup
Length: Variable (depends on the length of Peer-ID and whether this
is a range lookup)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num |r|r|R| Peer-ID (equal to Algorithm-Len) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num (5 bits): Number of peers to look for.
R (1 bit): If set (R=1), then it is a range lookup.
Baset & Schulzrinne Expires January 3, 2008 [Page 37]
Internet-Draft Peer-to-Peer Protocol July 2007
Peer-ID (variable): Peer-ID. If Algorithm-Len queried at join is
zero, then a length field of 16 bits MUST be present before
Peer-ID.
Peer-ID (variable): Peer-ID. Included only if R is set. If
Algorithm-Len queried at join is zero, then a length field of 16
bits MUST be present before Peer-ID.
7.3.7. Resource-Object
Type: Resource-Object
Length: Variable (depends on the size of resource-object)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| Reserved | Cont-type | Resource-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Resource-object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Additional Information Fields //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I flag: If set (I=1), the resource-object is included.
Cont-type: An IANA assigned idenfitier for the type of content
contained in this resource-object.
Resource-ID (variable): The ID of the resource object. For DHT-
based overlays, its length is equal to the length of the hash
algorithm. If Algorithm-Len field negotiated at join is zero, a
length field of 16-bits must precede resource-ID.
Resource-object (variable): Variable length.
7.3.7.1. Additional Information Fields
The resource-object may use the following TLVs to express additional
information about itself.
Owner (variable): The owner TLV object.
Expires (fixed): The expires TLV object.
Baset & Schulzrinne Expires January 3, 2008 [Page 38]
Internet-Draft Peer-to-Peer Protocol July 2007
7.3.8. Expires
Type: Expires
Length: Fixed (32-bit word)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expire time in seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires (32 bits): Time in seconds
7.3.9. Owner
Type: Owner
Length: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Owner //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Owner (variable): The owner of the Resource-Object. Format TBD.
7.3.10. Credentials
TBD. Need an elaborate credentials mechanism.
Type: Credentials
Length: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Credentials //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Baset & Schulzrinne Expires January 3, 2008 [Page 39]
Internet-Draft Peer-to-Peer Protocol July 2007
Credentials (variable): The credentials of the peer sending the join
request. TBD.
7.4. Errors
7.4.1. Error Object
Type: Error
Length: Variable
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link MTU (16 bits): The MTU for a link along which a message cannot
be sent. Other error info TBD.
7.4.2. Response Codes
There are four different types of response codes. They are:
1xx (Provisional): Response data which provides an update on the
progress of the request. These responses are only sent when
request is sent over an unreliable transport in a recursive
manner.
2xx (Success): Response data which indicates that the request has
been processed successfully in some sense.
3xx (Redirect): Response data which indicates that the request
should be redirected.
4xx (Request Failure): Response data which indicates that the
request has failed.
2xx-4xx responses are classified as definite responses while 1xx are
provisional responses.
7.4.2.1. 1xx (Provisional) Responses
Baset & Schulzrinne Expires January 3, 2008 [Page 40]
Internet-Draft Peer-to-Peer Protocol July 2007
100 Trying. The request is being tried. This response is only sent
if the request was sent in a recursive manner over UDP, and needs
to be forwarded to the next peer.
7.4.2.2. 2xx (Successful) Responses
200 Ok. A successful answer to the request.
7.4.2.3. 3xx (Redirect) Responses
302 Next Hop. This response is only generated for iterative
requests if the peer receiving the request is not the final
destination for the request.
7.4.2.4. 4xx (Permanent-Failure) Responses
400 Bad request. There was an error parsing the request.
404 Not found. This response is generated for a lookup request if
the resource-object being searched for is not found.
405 Error inserting object. There was an error inserting the
resource-object.
406 Request rejected. The request was understood but rejected by
the peer.
407 Join request deferred. The peer issuing the join request should
retry after a certain time.
410 TTL hops The number of TTL hops exceeded.
413 Message too large. The response message size was too large.
This response is typically generated for unreliable transports.
418 Timeout. The request timed out. This response is generated when
request was forwarded in a recursive manner over UDP and no
response was received.
Baset & Schulzrinne Expires January 3, 2008 [Page 41]
Internet-Draft Peer-to-Peer Protocol July 2007
8. API between P2PP and Applications
An application using peer-to-peer protocol issues non-blocking calls
to P2PP layer to accomplish operations, namely, join, leave, publish,
lookup, remove, and query. Since an operation may take long time to
complete, an application supplies a call-back function for each API,
not shown in the parameters. The 'in' parameters are passed to P2PP
in the API call, whereas the 'out' parameters are returned in the
call-back function after the operation is complete. Upon success,
the call-back function returns a value of zero.
8.1. Query
Query([out]Overlay-ID, [out]P2P-Algorithm, [out]Hash-Algorithm,
[out]Hash-Algorithm-Len, [in]Overlay-peer-network-address,
[in]Overlay-peer-port)
8.2. Join
Join([in]Overlay-ID, [in]Overlay-peer-network-address, [in]Overlay-
peer-port)
An application uses this API to inform the P2PP layer to start the
join process.
8.3. Leave
Leave([in]Overlay-ID)
An application uses this API to inform the P2PP layer that it wishes
to leave the overlay immediately. An application does not wait for
this operation to be completed and may shut down immediately.
8.4. Publish
Publish([in]Resource-ID, [in]Resource-Object)
An application uses this API to publish a new resource-object in the
overlay or update an existing one.
8.5. Remove
Remove([in]Resource-ID)
An application uses this API to explicitly remove a resource-object
from the overlay.
Baset & Schulzrinne Expires January 3, 2008 [Page 42]
Internet-Draft Peer-to-Peer Protocol July 2007
8.6. Lookup
Lookup([in]Resource-ID, [out]Resource-Object)
An application uses this API to search for a resource-object in the
overlay. If the resource-object is found, it is returned in the API
call.
(Open Issue: Each operation should have a crypto-signed counterpart.)
Baset & Schulzrinne Expires January 3, 2008 [Page 43]
Internet-Draft Peer-to-Peer Protocol July 2007
9. Security Considerations
TBD.
Baset & Schulzrinne Expires January 3, 2008 [Page 44]
Internet-Draft Peer-to-Peer Protocol July 2007
10. Open Issues
1. Should recursive parallel routing be supported?
2. Peers can invite other peers in the overlay. Should this
mechanism be part of the P2PP messages or should this be a
separate mechanism?
3. How can a node estimate its CPU and bandwidth utilization?
4. Security
5. Should trust mechanism be part of the protocol?
6. Should client Peer-Info objects be inserted in the overlay?
7. Should diagnostic interface be merged with maintenance interface?
Baset & Schulzrinne Expires January 3, 2008 [Page 45]
Internet-Draft Peer-to-Peer Protocol July 2007
11. Acknowledgements
The authors will like to thank the following (in alphabetical order)
for their helpful comments and suggestions. Christian Dickmann, Jae
W. Lee, Kundan Singh, and Eunsoo Shim.
Baset & Schulzrinne Expires January 3, 2008 [Page 46]
Internet-Draft Peer-to-Peer Protocol July 2007
12. IANA Considerations
Listening Port: The port on which a peer listens for request. The
current implementation uses 7080.
Message Types: The P2PP common header contains a one byte message
type field. A message can either be a request or a response. The
following values are allocated by this specification for request
messages.
+--------------+----------------------------+
| Message Type | Message |
+--------------+----------------------------+
| 0 | Join |
| | |
| 1 | Leave |
| | |
| 2 | Keep-alive |
| | |
| 3 | LookupPeer |
| | |
| 4 | ExchangeTable (old Update) |
| | |
| 5 | Query |
| | |
| 6 | Replicate |
| | |
| 7 | Transfer |
| | |
| 21 | Publish (old Insert) |
| | |
| 22 | LookupObject (old Lookup) |
| | |
| 23 | RemoveObject (old Remove) |
+--------------+----------------------------+
Object Types: There is a one byte field in the object header. The
following values for object types are defined by this
specification.
Baset & Schulzrinne Expires January 3, 2008 [Page 47]
Internet-Draft Peer-to-Peer Protocol July 2007
+-------+-----------------+
| OType | Object Type |
+-------+-----------------+
| 0 | Peer-Info |
| | |
| 1 | P2P-options |
| | |
| 2 | Routing-table |
| | |
| 3 | Neighbor-table |
| | |
| 4 | PLookup |
| | |
| 5 | Resource-object |
| | |
| 6 | Expires |
| | |
| 7 | Request-Options |
| | |
| 8 | Owner |
| | |
| 9 | Credentials |
| | |
| 10 | Uptime |
| | |
| 11 | Unhashed-ID |
| | |
| 12 | Capacity-Info |
| | |
| 13 | Address-Info |
| | |
| 14 | Error |
+-------+-----------------+
Algorithm: There is a one byte algorithm field in the P2P-options
object which defines the hash function being used. The following
values are allocated by this specification for this field.
Baset & Schulzrinne Expires January 3, 2008 [Page 48]
Internet-Draft Peer-to-Peer Protocol July 2007
+-------+-----------+
| AType | Algorithm |
+-------+-----------+
| 0 | None |
| | |
| 1 | SHA1 |
| | |
| 2 | SHA-256 |
| | |
| 3 | SHA-512 |
| | |
| 4 | MD4 |
| | |
| 5 | MD5 |
+-------+-----------+
Algorithm: There is a one byte P2P-algorithm field in the P2P-
options object which defines the p2p algorithm being used. The
following values are allocated by this specification for this
field.
+-------+---------------+
| PType | P2P-Algorithm |
+-------+---------------+
| 0 | Chord |
| | |
| 1 | CAN |
| | |
| 2 | Kademlia |
| | |
| 3 | Pastry |
| | |
| 4 | Bamboo |
| | |
| 5 | Tapestry |
| | |
| 6 | Accordion |
| | |
| 7 | SkipNet |
| | |
| 8 | Mercury |
| | |
| 9 | Gia |
+-------+---------------+
Baset & Schulzrinne Expires January 3, 2008 [Page 49]
Internet-Draft Peer-to-Peer Protocol July 2007
13. Change Log
Insert, Remove, Lookup, Peer-Lookup and Update have been renamed as
Publish, RemoveObject, LookupObject, LookupPeer, and ExchangeTable
respectively.
Transfer request has been added.
Baset & Schulzrinne Expires January 3, 2008 [Page 50]
Internet-Draft Peer-to-Peer Protocol July 2007
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Petersen, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of
Extensions to the Session Initiation Protocol (SIP)", RFC 4485,
May 2006.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications:ABNF", RFC 4234, October 2005.
[5] Rosenberg, J., Huitema, C., Mahy, R., and D. Wing, "Simple
Traversal Underneath Network Address Translators (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-06 (work in progress),
March 2007.
[6] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay
Addresses from Simple Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-03 (work in progress), March 2007.
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in
progress), June 2007.
14.2. Informative References
[8] Willis, D., Bryan, D., Matthews, P., and E. Shim, "Concepts and
Terminology for Peer-to-Peer SIP",
draft-willis-p2psip-concepts-04 (work in progress), March 2007.
[9] Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P Approach
to SIP Registration and Resource Location",
draft-bryan-p2psip-dsip-00 (work in progress), February 2007.
[10] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy,
S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT
Service and its Uses", SIGCOMM '05:Proceedings of the 2005
conference on Applications, technologies, architectures, and
protocols for computer communications. Philadelphia, PA,
pp. 73-84, 2005.
Baset & Schulzrinne Expires January 3, 2008 [Page 51]
Internet-Draft Peer-to-Peer Protocol July 2007
[11] Pugh, W., "Skip Lists: A Probabilistic Alternative to Balanced
Trees", Workshop on Algorithms and Data Structures. pp. 437-
449, 1989.
[12] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek,
M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-
peer Lookup Service for Internet Applications", IEEE/ACM
Transactions on Networking, vol. 11, no. 1, pp. 17-32, 2003.
[13] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S.
Shenker, "A Scalable Content-Addressable Network", SIGCOMM '01:
Proceedings of the 2001 conference on Applications,
technologies, architectures, and protocols for computer
communications. San Diego, CA, pp. 161-172, August 2001.
[14] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed
object location and routing for large-scale peer-to-peer
systems", Proceedings of the 18th IFIP/ACM International
Conference on Distributed Systems Platforms (Middleware 2001),
March 2002.
[15] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
Information System Based on the XOR Metric", IPTPS'01: Revised
Papers from the First International Workshop on Peer-to-Peer
Systems London, UK, pp. 53-65, March 2002.
[16] Karger, D., Lehman, E., Leighton, T., Panigraphy, R., Levine,
F., and D. Lewin, "Consistent hashing and random trees:
distributed caching protocols for relieving hot spots on the
World Wide Web", STOC '97: Proceedings of the twenty-ninth
annual ACM symposium on Theory of computing , 1997.
[17] Balakrishnan, H., Kaashoek, F., Karger, D., Morris, R., and I.
Stoica, "Looking up data in P2P systems", Communications of the
ACM, vol. 46, no. 2, pp. 43-48, 2003.
[18] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I.
Stoica, "Towards a Common API for Structured Peer-to-Peer
Overlays", IPTPS'03: Proceedings of the 2nd International
Workshop on Peer-to-Peer Systems. Berkeley, California,
February 2003.
[19] Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N., Kaashoek,
M., and S. Shenker, "Making gnutella-like p2p systems
scalable", SIGCOMM '03: Proceedings of the 2003 conference on
Applications, technologies, architectures, and protocols for
computer communications. New York, NY, USA, pp. 407-418, 2003.
Baset & Schulzrinne Expires January 3, 2008 [Page 52]
Internet-Draft Peer-to-Peer Protocol July 2007
[20] Li, J., Stribling, J., Morris, R., and M. Kaashoek, "Bandwidth-
efficient management of DHT routing tables", in Proceedings of
the 2nd USENIX Symposium on Networked Systems Design and
Implementation (NSDI '05). Boston, MA, USA, 2005.
[21] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap
Mechanisms for P2PSIP",
draft-matthews-p2psip-bootstrap-mechanisms-00 (work in
progress), February 2007.
Baset & Schulzrinne Expires January 3, 2008 [Page 53]
Internet-Draft Peer-to-Peer Protocol July 2007
Appendix A. Background
This section gives a background of various structured and
unstructured peer-to-peer algorithms.
A.1. Structured Overlays
A structured peer-to-peer network is formed when links between nodes
follow a certain pattern or structure. Distributed hash tables
(DHTs) [12][13][14][15] are examples of structured peer-to-peer
networks. DHTs share a fundamental function, namely routing a
message to a node responsible for an identifier (key) in O(log_{b}N)
steps using a certain routing metric where N is the number of nodes
in the system and b is the base of the logarithm.
In this section, we give an overview of Chord [12], Pastry [14] and
Kademlia [15]. These algorithms are based on the idea of consistent
hashing [16] i.e., keys are mapped onto nodes by a hash function that
can be resolved by any node in the system via queries to other nodes
and the arrival or departure of a node does not require all keys to
be rehashed. We compare their algorithm-specific and algorithm-
independent details in Table 1 and 2 and describe the commonalities
that exist between them.
A.1.1. Chord
The identifiers or keys in Chord can be logically considered to be
arranged on a circle. Each node in Chord maintains two data
structures, a 'successor list' (neighbor table) which is the list of
peers immediately succeeding the node ID and a 'finger table'
(routing table). The finger table contains the peer-ID and IP
address of nodes halfway around the ID space from the node, a
quarter-of-the-way, an eighth-of-the-way and so forth in a data
structure that resembles a skiplist [11]. A node forwards a query
for a key k to a node in its finger (routing) table with the highest
ID not exceeding k. The skiplist structure ensures that a key can be
found in O(log_{2}N) steps where N is the number of nodes in the
system.
To join a Chord ring, a node contacts any peer in the Chord network
and requests it to lookup its ID. It then inserts itself at the
appropriate position in the Chord network. The predecessors of the
newly joined node must update their successor lists. The newly
joined node should also update its finger table. Successor list is
the only requirement for correctness while finger table is used to
speedup the lookups.
To guard against node failures, Chord sends keep-alives to its
Baset & Schulzrinne Expires January 3, 2008 [Page 54]
Internet-Draft Peer-to-Peer Protocol July 2007
successors and finger table entries and continuously repairs them.
The routing table size is log_{2}N.
Chord suggests two ways for key and data replication. In the first
method, an application replicates data by storing it under two
different Chord keys derived from the data's key. Alternatively, a
Chord node can replicate key/value pair on each of its r successors.
A.1.2. Pastry
Like Chord, the identifiers or keys in Pastry can be logically
considered to be arranged on a circle; however, the routing is done
in a tree-based (prefix-matching) fashion. Each node in Pastry
contains two data structures, a 'leaf-set' and a 'routing table'.
The leaf-set L (neighbor table) contains |L|/2 closest nodes with
numerically smaller identifiers than the node n and |L|/2 closest
nodes with numerically larger identifiers than n and is conceptually
similar to Chord successor list [17]. The routing table contains the
IP address of nodes with no prefix match, b bits prefix match, 2b
prefix match and so on where b is typically 2, 4, 6, 8 etc. The
maximum size of routing table is log_{2^b}N x 2^b. At each step, a
node n tries to route the message to a node that has a longest
sharing prefix than the node n with the sought key. If there is no
such node, the node n routes the message to a node whose shared
prefix is at least as long as n and whose ID is numerically closer to
the key. The expected number of hops is at most log_{2^b}N.
To join the Pastry network, a node contacts any node in the Pastry
network and builds routing tables and leaf sets by obtaining
information from the nodes along the path from bootstrapping node and
the node closest in ID space to itself. When a node gracefully
leaves the network, the leaf-sets of its neighbors are immediately
updated. The routing table information is corrected only on demand.
The routing table of a Pastry node is initialized such that each
entry i with a common prefix p_{i} is closer to the node (in the
network sense) among all other live nodes having a prefix p_{i}.
This technique is commonly known as proximity neighbor selection
(PNS). Pastry performs recursive lookups. However, PNS and
recursive lookups are orthogonal to the Pastry operation.
Pastry replicates data by storing the key/value pair on k nodes with
the numerically closest node IDs to a key [14]. This method is
conceptually similar to Chord's replication of key/value pairs on its
successor list.
Baset & Schulzrinne Expires January 3, 2008 [Page 55]
Internet-Draft Peer-to-Peer Protocol July 2007
A.1.3. Kademlia
Like Chord and Pastry, identifiers in Kademlia can be logically
considered to be arranged on a circle; however the routing is done in
a tree-based (prefix-matching) fashion. Each node in Kademlia
contains a routing table. Kademlia contains only one data structure
i.e. the routing table. Unlike Chord and Pastry, there are no
successor lists or leaf sets although it is possible for a node to
maintain one.
Kademlia uses XOR metric to compute the distance between two
identifiers, i.e., d(x,y)=x XOR y. XOR metric is non-Euclidean and
it offers the triangle property: d(x,y)+d(y,z) >= d(x,z).
Essentially, XOR metric is a prefix matching algorithm which tries to
route a message to a node with the longest matching prefix and the
smallest XOR value for non-prefix bits.
Kademlia maintains up to k entries per routing table row and allows
parallel lookups to all nodes in a row. However, this is not really
a Kademlia specific feature and other DHT algorithms can implement it
by maintaining multiple entries per routing table row. The latest
incarnation of Chord contains more than one finger entry per row
[20].
The routing table size is log_{2}N. The lookup speed can be increased
by considering IDs b bits at a time instead of one bit at a time
which implies increasing the routing table size. By increasing the
routing table size to 2^b x log_{2^b}N x k entries, the number of
lookup hops can be reduced to log_{2^b}N.
Kademlia replicates data by finding k closest nodes to a key and
storing the key/value pair on them. The Kademlia paper suggests a
value of 20 for k.
A.1.4. Bamboo/OpenDHT
Similar to Pastry. Detailed description ToDo.
Baset & Schulzrinne Expires January 3, 2008 [Page 56]
Internet-Draft Peer-to-Peer Protocol July 2007
Key Recursive/ Sequential/ Routing Neighbor
length Iterative Parallel table nodes
name
---------------------------------------------------------------
Chord 160 Both Sequential Finger Successor
table list
Pastry 128 Recursive Sequential Routing Leaf-set
table
Kademlia 160 Iterative Parallel Routing None
table
Table 1. DHT-independent details of Chord, Pastry and Kademlia.
Routing Routing Symmetric Learning
data table node
structure selection
-------------------------------------------------------------
Chord Skip-list Immediately No No (orig. paper)
succeed the but possible.
interval
(can be a
range)
Pastry Tree-like Any node in Yes Yes
the interval
Kademlia Tree-like Any node in Yes Yes
the interval
Table 2. Algorithm specific details of Chord, Pastry and Kademlia.
A.2. DHT Commonalities
Table 1 and 2 list the DHT-independent and DHT-specific aspects of
Chord, Pastry and Kademlia. From the above discussion, and from
these tables, we can think of following commonalities between Chord,
Pastry and Kademlia.
o The flexibility in selecting a node for a routing table row
impacts whether a routing table can be updated with information
from passing lookup requests. This is useful because a node can
learn about other peers in the DHT without explicitly looking for
them and can refresh its routing table as a side effect of lookup
requests. The flexibility is derived from the underlying geometry
of the DHT which the DHT authors might have overlooked. For
example, in Chord a peer, for its ith routing table entry, selects
Baset & Schulzrinne Expires January 3, 2008 [Page 57]
Internet-Draft Peer-to-Peer Protocol July 2007
a node whose ID must immediately exceed the ith row ID. This
restriction is arbitrary and a peer can pick up any node with ID
between i and i+1 row ID.
o Requests such as join and lookup can be sent in an iterative or
recursive manner. The requests can also be sent in a sequential
or parallel manner.
o It is possible to define replication strategies independent of the
underlying DHT algorithms.
o The time to detect whether a routing entry node has failed is
independent of the DHT algorithm being used.
o The choice of hash function and the length of the key are
independent of the routing algorithm.
A.3. Unstructured Overlays
An unstructured peer-to-peer network is formed when links between
peers are formed arbitrarily. Unlike structured peer-to-peer
systems, they do not necessarily provide a routing guarantee of
O(log_{b}N) hops nor they guarantee finding an identifier if it
exists.
A.3.1. Gia
In this section, we give a brief description of Gia [19], an
unstructured peer-to-peer protocol. Gia extends the Gnutella
topology and search algorithms in order to accommodate natural
heterogeniety present in the peer-to-peer systems. Like other
unstructured protocols, it does not guarantee finding an identifier
if it exists. Unlike Chord and Pastry, a Gia node does not have a
separate routing and neighbor table. Each Gia node maintains a
neighbor table (host cache) comprising a list of other Gia nodes
(their IP address, port number, and capacity). Nodes exchange
capacity and congestion information with each other. A Gia node uses
random walks to locate a resource and biases random walks towards
high capacity nodes.
A node Y attempting to join Gia overlay discovers a node already in
the overlay using some bootstrap mechanism and sends it a join
request. The node receiving the join request selects a small number
of high capacity candidate entries in its neighbor table and forwards
the request towards the highest capacity node. Each node receiving
the join request can add Y as its neighbor if the number of its
neighbors is less than some configured maximum. Otherwise, it drops
a neighbor with the highest capacity exceeding Y's capacity. The
Baset & Schulzrinne Expires January 3, 2008 [Page 58]
Internet-Draft Peer-to-Peer Protocol July 2007
rationale behind dropping the highest capacity node is that it is
least likely to suffer from the loss of this neighbor.
In addition to capacity, a Gia nodes takes neighbor nodes' current
congestion state into account before forwarding the request. Nodes
periodically exchange their congestion state information with each
other. A node can be congested if many peers are accessing a
resource or service advertised by this peer.
A node forwards the lookup request to the least congested and highest
capacity node. Each node remembers the ID of the lookup request it
received. The lookup requests are TTL limited.
The pointer to the resource published by a node are replicated on all
of its immediate neighbors.
Baset & Schulzrinne Expires January 3, 2008 [Page 59]
Internet-Draft Peer-to-Peer Protocol July 2007
Appendix B. Protocol design choices
B.1. To SIP or not to SIP
A SIP [2] application can use the P2PP protocol as an alternate
method of locating SIP servers as defined in RFC 3263. There are
several reasons why we did not choose SIP as the underlying peer-to-
peer protocol.
SIP is a session establishment protocol. SIP is a protocol for
initiating, modifying, and terminating interactive sessions [2].
Communicating with other nodes to form and maintain an overlay
does not create an interactive session.
SIP is not a general Remote Procedure Call (RPC). A peer-to-peer
protocol designed on top of SIP will merely use it as a remote
procedure call (RPC) mechanism. The SIP guidelines document [3]
prohibits the use of SIP as a RPC mechanism.
SIP is not a general purpose transfer protocol. One possible way to
design the peer-to-peer protocol is to incorporate it as a SIP
message body, possibly in XML, leaving the SIP headers unchanged.
The peer-to-peer protocol is, however, unrelated to SIP's
operation and the SIP guideline document [3] prohibits sending
large amounts of data unrelated to SIP's operation. Such a
mechanism would use SIP as a RPC, which, as stated earlier, is
prohibited by the SIP guidelines document.
SIP is not a lookup protocol. SIP is not a lookup protocol; it
relies on DNS to locate an appropriate SIP server. Insert and
lookup functionality is essential for any peer-to-peer protocol.
Using SIP as a peer-to-peer protocol requires integrating lookup
functionality into SIP which goes against its design philosophy.
SIP headers overhead. SIP has headers that are not necessarily
needed for a peer-to-peer protocol. Examples of such headers are
Call-ID, and Contact.
B.2. To ASCII or not to ASCII
Perhaps, the first question facing the designer of a new protocol is
whether it should be ASCII or binary based. DHTs are a primary
motivation for this specification and a message in DHT-based overlay
is likely to carry the hash identifier of a peer or resource-object.
Using an ASCII-based protocol will require converting binary hash
identifier to ASCII and vice versa. This conversion can be avoided
if the underlying peer-to-peer protocol is binary based.
Baset & Schulzrinne Expires January 3, 2008 [Page 60]
Internet-Draft Peer-to-Peer Protocol July 2007
Also, if the protocol were to be ASCII-based, existing ASCII-based
protocols such as XML-RPC could have been used.
Baset & Schulzrinne Expires January 3, 2008 [Page 61]
Internet-Draft Peer-to-Peer Protocol July 2007
Appendix C. Examples
C.1. Join (Pastry)
Consider a Pastry-based overlay below in which node P9 is attempting
to join. It will be inserted between nodes P8 and P11. Recall that
in Pastry, requests are forwarded in a recursive fashion. Using some
bootstrap mechanism outside the scope of this specification, it
discovers node P6 which is already in the overlay. It sends a Query
request to node P6 inquiring about the overlay parameters such as
p2p-algorithm and hash-algorithm. It then sends a join request over
UDP to P6. Node P6 forwards the join request in a recursive manner
till it reaches node P8. P8 decides that P9 will be inserted
immediately after itself in the overlay. It replies with a copy of
its neighbor and routing tables in a 200 (Ok) response. Node P9
eventually receives the response and checks the received neighbor
table which contains a pointer to node P11. The nodes in the
neighbor table will be the neighbors of P9. Node P9 then sends a
Join request to node P11 with S flag set to P11. Node P11 receives
the join request with S flag set and knows that the join request
should not be forwarded and that a neighbor update has been
requested. It then update its left neighbor as P9 instead of P8.
Note that neighbors P8 and P11 do not immediately remove overlay
links to each other. Rather, they wait for a random time and
exchange their neighbor tables with each other using the
ExchangeTable request. Once both P8 and P11 know that their right
and left neighbor links, respectively, have been updated, they choose
to remove the link to each other.
+--+ +--+ +--+ +---+ +---+ +---+
|P9| |P6| |P8| |P11| |P15| |P20|
+--+ +--+ +--+ +---+ +---+ +---+
(1) Query
|---------->|
|(2) 200 |
|<----------|
| | |
|(3) Join |
|---------->| | |
| |(4) Join | |
| |---------->| |
| |(5) 200 | |
| |<----------| |
|(6) 200 | N(P11) | |
|<----------| R(P15,P20) |
| N(P11) |
Baset & Schulzrinne Expires January 3, 2008 [Page 62]
Internet-Draft Peer-to-Peer Protocol July 2007
| R(P15,P20) |
| |
|(7) Join(S=1) |
|------------------------------------------>|
|(8) 200 N(P8,P15) R(P20, P25) |
|<------------------------------------------|
|(9) Update |
| R(P11,P20) |
|<-----------|
|(10) 200 |
|----------->|
|(11) Update |
|<--------------------|
| N(P9,P15)
|(12) 200 |
| N(P6,P9)
|-------------------->|
(1) P9 -> P6 (Query)
P2PP(Header(Msg-type=Request; Request-type=Query; TTL=1;
Trans-Id=0xFDE89F20) )
(2) P6 -> P9 (200 (Ok))
P2PP(Header(Msg-type=Response; Response-code=200; Request-type=Query;
TTL=1; Trans-Id=0xFDE89F20)
Peer-Info(Peer-ID=P6#ID; Uptime=0x000000D0F9; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P6#IP)
P2P-Options(Recursive-routing=1; Algorithm=SHA1;
Algorithm-Length=160; P2P-Algorithm=Pastry;
Overlay-ID="Pastry-overlay")
)
(3) P9 -> P6 (Join) (4) P6 -> P8 (Join) (TTL=159)
P2PP(Header(Msg-type=Request; Request-type=Join; TTL=160;
Trans-Id=0xD59A3BA1)
Request-Options(Request-forwarding(F)=Recursive; Insert-on-join=1;
P=0; Request-routing-table=1;
Request-neighbor-table=0; S=0)
Peer-Info(Peer-ID=P9#ID; Uptime=0x00000000; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P9#IP)
Overlay-ID=("Pastry-overlay")
)
(5) P8 -> P6 (200 (Ok)) (6) P8 -> P9 (200 (Ok))
P2PP(Header(Msg-type=Response; Response-code=200; Request-type=Join;
TTL=159; Trans-Id=0xD59A3BA1)
Peer-Info(Peer-ID=P8#ID; Uptime=0x00000FD21; IP-Ver=4; Num=1;
Baset & Schulzrinne Expires January 3, 2008 [Page 63]
Internet-Draft Peer-to-Peer Protocol July 2007
HT=host; Port=7080; Peer-address=P8#IP)
Neighbor-table(Num=1; Peer-Info(Peer-ID=P11#ID; Uptime=0x00102A5C;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P11#IP))
Routing-table(Num=2; Peer-Info(PeerID=P15#ID; Uptime=0x000000AB;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P15#IP)
Peer-Info(PeerID=P20#ID; Uptime=0x00000EC4;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P20#IP)
)
(7) P9 -> P11 (Join)
P2PP(Header(Msg-type=Request; Request-type=Join; TTL=1;
Trans-Id=0xFA4A3C45)
Request-Options(Request-forwarding(F)=Recursive; Insert-on-join=1;
P=0; Request-routing-table=1;
Request-neighbor-table=0; S=1)
Peer-Info(Peer-ID=P9#ID; Uptime=0x00000000; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P9#IP)
Overlay-ID=("Pastry-overlay"))
(8) 200 (Ok)
P2PP(Header(Msg-type=Response; Response-code=200; Request-type=Join;
TTL=0; Trans-Id=0xFA4A3C45)
Peer-Info(Peer-ID=P11#ID; Uptime=0x00102A5C; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P11#IP))
Neighbor-table(Num=2; Peer-Info(Peer-ID=P8#ID; Uptime=0x00000FD21;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P8#IP)
Peer-Info(PeerID=P15#ID; Uptime=0x000000AB;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P15#IP))
Routing-table(Num=2; Peer-Info(PeerID=P20#ID; Uptime=0x00000EC4;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P20#IP)
Peer-Info(PeerID=P25#ID; Uptime=0x0000015A;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P25#IP))
)
(9) P6 -> P9 (Update)
P2PP(Header(Msg-type=Request; Request-type=Update; TTL=1;
Trans-Id=0x0183FA78)
Peer-Info(Peer-ID=P6#ID; Uptime=0x000000D0FA; IP-Ver=4;
Num=1; HT=host; Port=7080; Peer-address=P6#IP)
Routing-table(Num=2; Peer-Info(Peer-ID=P11#ID; Uptime=0x00102A5E;
Baset & Schulzrinne Expires January 3, 2008 [Page 64]
Internet-Draft Peer-to-Peer Protocol July 2007
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P11#IP)
Peer-Info(PeerID=P20#ID; Uptime=0x00000EC7;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P20#IP)
)
(10) P9 -> P6 (200 (Ok))
P2PP(Header(Msg-type=Request; Response-code=200; Request-type=Update;
TTL=1; Trans-Id=0x0183FA78)
Peer-Info(Peer-ID=P9#ID; Uptime=0x00000003; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P9#IP)
)
(11) P11 -> P8 (Update)
P2PP(Header(Msg-type=Request; Request-type=Update; TTL=1;
Trans-Id=0x2154A526)
Request-Options(Request-forwarding(F)=Recursive; Insert-on-join=0;
P=0; Request-routing-table=0;
Request-neighbor-table=1; S=1)
Peer-Info(Peer-ID=P11#ID; Uptime=0x00102A60; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P11#IP))
Neighbor-table(Num=2; Peer-Info(Peer-ID=P9#ID; Uptime=0x00000001;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P9#IP)
Peer-Info(PeerID=P15#ID; Uptime=0x000000AB;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P15#IP)
)
(12) P8 -> P11 (200)
P2PP(Header(Msg-type=Request; Response-code=200; Request-type=Update;
TTL=0; Trans-Id=0x2154A526)
Peer-Info(Peer-ID=P8#ID; Uptime=0x00000FD24; IP-Ver=4; Num=1;
HT=host; Port=7080; Peer-address=P8#IP)
Neighbor-table(Num=2; Peer-Info(Peer-ID=P6#ID; Uptime=0x000000D0F9;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P6#IP)
Peer-Info(Peer-ID=P9#ID; Uptime=0x00000001;
IP-Ver=4; Num=1; HT=host; Port=7080;
Peer-address=P9#IP)
)
C.2. Join (Gia)
Baset & Schulzrinne Expires January 3, 2008 [Page 65]
Internet-Draft Peer-to-Peer Protocol July 2007
+--+ +--+ +--+ +---+ +---+ +---+
|P9| |P6| |P8| |P11| |P15| |P20|
+--+ +--+ +--+ +---+ +---+ +---+
(1) Query
|---------->|
|(2) 200 |
|<----------|
| | |
|(3) Join |
|---------->| | |
| |(4) Join | |
| |---------->| |
| |(5) 200 | |
| |<----------| |
|(6) 200 |N(P11,P20) | |
|<----------| |
| N(P11,P20) |
| |
| |
|(7) Join(S=1) |
|------------------------------------------>|
|(8) 200 N(P8,P15) |
|<------------------------------------------|
|(9) Update |
| N(P11,P20) |
|<-----------|
|(10) 200 |
|----------->|
|(11) Update |
|<--------------------|
| N(P9,P15)
|(12) 200 |
| N(P6,P9)
|-------------------->|
C.3. Join (Chord)
TBD.
C.4. Lookup (Pastry)
TBD.
Baset & Schulzrinne Expires January 3, 2008 [Page 66]
Internet-Draft Peer-to-Peer Protocol July 2007
C.5. Lookup (Gia)
TBD.
C.6. Lookup (Chord)
TBD.
Baset & Schulzrinne Expires January 3, 2008 [Page 67]
Internet-Draft Peer-to-Peer Protocol July 2007
Authors' Addresses
Salman A. Baset
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: salman@cs.columbia.edu
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
Baset & Schulzrinne Expires January 3, 2008 [Page 68]
Internet-Draft Peer-to-Peer Protocol July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baset & Schulzrinne Expires January 3, 2008 [Page 69]