[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/