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

Versions: 00 01

Network Working Group                                           S. Baset
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                     Columbia University
Expires: May 22, 2008                                     M. Matuszewski
                                                                   Nokia
                                                       November 19, 2007


                      Peer-to-Peer Protocol (P2PP)
                       draft-baset-p2psip-p2pp-01

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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Baset, et al.             Expires May 22, 2008                  [Page 1]

Internet-Draft            Peer-to-Peer Protocol            November 2007


Abstract

   This document defines the Peer-to-Peer Protocol (P2PP), an
   application-layer binary 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
   Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a
   secure transport, supports an application API, has mechanisms for NAT
   and firewall traversal, exchanging node capabilities, and diagnostic
   information.  P2PP is designed to support a P2P Session Initiation
   Protocol (SIP) network, but it can be used for other applications as
   well.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Design Overview  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  High-Level Requirements  . . . . . . . . . . . . . . . . . 10
     3.2.  Node Model . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.1.  P2PP Node Stack  . . . . . . . . . . . . . . . . . . . 12
     3.3.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.4.  Message Model  . . . . . . . . . . . . . . . . . . . . . . 15
     3.5.  Reliability Model  . . . . . . . . . . . . . . . . . . . . 16
     3.6.  Security Model . . . . . . . . . . . . . . . . . . . . . . 18
       3.6.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . 19
     3.7.  NAT and Firewall Traversal . . . . . . . . . . . . . . . . 20
     3.8.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 20
       3.8.1.  Peer Mobility  . . . . . . . . . . . . . . . . . . . . 20
       3.8.2.  Client Mobility  . . . . . . . . . . . . . . . . . . . 21
       3.8.3.  Session Mobility . . . . . . . . . . . . . . . . . . . 22
     3.9.  Overview of Operations . . . . . . . . . . . . . . . . . . 22
       3.9.1.  Enrollment, Authentication, and Bootstrap  . . . . . . 22
       3.9.2.  Overlay Maintenance  . . . . . . . . . . . . . . . . . 23
       3.9.3.  Data Storage and Retrieval . . . . . . . . . . . . . . 24
       3.9.4.  Connection Management and Other  . . . . . . . . . . . 24
     3.10. Overlay Migration  . . . . . . . . . . . . . . . . . . . . 25
   4.  Overlay Layer  . . . . . . . . . . . . . . . . . . . . . . . . 26
     4.1.  Peer State . . . . . . . . . . . . . . . . . . . . . . . . 26
     4.2.  Key Components of a P2PP Message . . . . . . . . . . . . . 27
     4.3.  Request, Response, and Indications Processing  . . . . . . 29
       4.3.1.  ACK generation . . . . . . . . . . . . . . . . . . . . 32
       4.3.2.  Recursive and Iterative Routing  . . . . . . . . . . . 33
     4.4.  Message Encoding Guidelines  . . . . . . . . . . . . . . . 35
     4.5.  Enrollment and Authentication  . . . . . . . . . . . . . . 36
       4.5.1.  HTTP Digest Authentication . . . . . . . . . . . . . . 37
       4.5.2.  Authentication without a Central Authority . . . . . . 38



Baset, et al.             Expires May 22, 2008                  [Page 2]

Internet-Draft            Peer-to-Peer Protocol            November 2007


     4.6.  Bootstrap  . . . . . . . . . . . . . . . . . . . . . . . . 38
     4.7.  Joining, Leaving . . . . . . . . . . . . . . . . . . . . . 38
       4.7.1.  Join . . . . . . . . . . . . . . . . . . . . . . . . . 39
       4.7.2.  Leave  . . . . . . . . . . . . . . . . . . . . . . . . 41
     4.8.  Publish, LookupObject, LookupPeer  . . . . . . . . . . . . 42
       4.8.1.  Publish  . . . . . . . . . . . . . . . . . . . . . . . 42
       4.8.2.  LookupObject . . . . . . . . . . . . . . . . . . . . . 42
       4.8.3.  LookupPeer . . . . . . . . . . . . . . . . . . . . . . 43
     4.9.  Maintenance  . . . . . . . . . . . . . . . . . . . . . . . 43
       4.9.1.  Node Timers  . . . . . . . . . . . . . . . . . . . . . 44
     4.10. Replication  . . . . . . . . . . . . . . . . . . . . . . . 44
     4.11. Capabilities and Diagnostics . . . . . . . . . . . . . . . 45
   5.  P2PP Processing  . . . . . . . . . . . . . . . . . . . . . . . 46
     5.1.  Resources and Services . . . . . . . . . . . . . . . . . . 46
     5.2.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 47
       5.2.1.  NAT Traversal Service Advertisement and Discovery  . . 48
       5.2.2.  Gathering of Candidates and NAT Behavior Discovery . . 48
       5.2.3.  Communicating with a Peer Behind a NAT . . . . . . . . 48
       5.2.4.  Maintenance of NAT Bindings  . . . . . . . . . . . . . 49
       5.2.5.  Load Balancing for Media Flows . . . . . . . . . . . . 49
       5.2.6.  ICE Overhead . . . . . . . . . . . . . . . . . . . . . 49
     5.3.  Route Log  . . . . . . . . . . . . . . . . . . . . . . . . 50
     5.4.  P2PP and SIP . . . . . . . . . . . . . . . . . . . . . . . 50
   6.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . . . 51
     6.1.  Transaction Identifier . . . . . . . . . . . . . . . . . . 51
     6.2.  Message State Machine  . . . . . . . . . . . . . . . . . . 51
       6.2.1.  State Machine for Unreliable Transports  . . . . . . . 51
       6.2.2.  State Machine for Reliable Transports  . . . . . . . . 53
     6.3.  Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 55
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 56
     7.1.  Routing Security . . . . . . . . . . . . . . . . . . . . . 56
       7.1.1.  Peer-ID Assignment . . . . . . . . . . . . . . . . . . 56
       7.1.2.  Message Forwarding and Message Integrity . . . . . . . 56
       7.1.3.  Routing and Neighbor Table Management  . . . . . . . . 56
       7.1.4.  Admission Control  . . . . . . . . . . . . . . . . . . 56
       7.1.5.  Residual Attacks . . . . . . . . . . . . . . . . . . . 57
     7.2.  Storage Security . . . . . . . . . . . . . . . . . . . . . 57
       7.2.1.  Integrity  . . . . . . . . . . . . . . . . . . . . . . 57
       7.2.2.  Permissions  . . . . . . . . . . . . . . . . . . . . . 57
       7.2.3.  Quota  . . . . . . . . . . . . . . . . . . . . . . . . 57
       7.2.4.  Residual Attacks . . . . . . . . . . . . . . . . . . . 57
   8.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 58
     8.1.  Enroll . . . . . . . . . . . . . . . . . . . . . . . . . . 58
     8.2.  Authenticate . . . . . . . . . . . . . . . . . . . . . . . 58
     8.3.  Bootstrap  . . . . . . . . . . . . . . . . . . . . . . . . 59
     8.4.  Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
     8.5.  Leave  . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     8.6.  KeepAlive  . . . . . . . . . . . . . . . . . . . . . . . . 60



Baset, et al.             Expires May 22, 2008                  [Page 3]

Internet-Draft            Peer-to-Peer Protocol            November 2007


     8.7.  LookupPeer . . . . . . . . . . . . . . . . . . . . . . . . 60
     8.8.  ExchangeTable  . . . . . . . . . . . . . . . . . . . . . . 61
     8.9.  Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 61
     8.10. Replicate  . . . . . . . . . . . . . . . . . . . . . . . . 61
     8.11. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 62
     8.12. PublishObject  . . . . . . . . . . . . . . . . . . . . . . 62
     8.13. LookupObject . . . . . . . . . . . . . . . . . . . . . . . 62
     8.14. RemoveObject . . . . . . . . . . . . . . . . . . . . . . . 63
     8.15. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 63
     8.16. Connect  . . . . . . . . . . . . . . . . . . . . . . . . . 63
     8.17. Invite . . . . . . . . . . . . . . . . . . . . . . . . . . 63
   9.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 65
     9.1.  Common Header  . . . . . . . . . . . . . . . . . . . . . . 65
     9.2.  General Object Format  . . . . . . . . . . . . . . . . . . 67
     9.3.  P2PP TLV Objects . . . . . . . . . . . . . . . . . . . . . 67
       9.3.1.  Peer-Info  . . . . . . . . . . . . . . . . . . . . . . 67
       9.3.2.  Unhashed-Id  . . . . . . . . . . . . . . . . . . . . . 69
       9.3.3.  Request-Options  . . . . . . . . . . . . . . . . . . . 69
       9.3.4.  P2P-Options  . . . . . . . . . . . . . . . . . . . . . 71
       9.3.5.  Routing-Table  . . . . . . . . . . . . . . . . . . . . 71
       9.3.6.  Neighbor-table . . . . . . . . . . . . . . . . . . . . 72
       9.3.7.  PLookup  . . . . . . . . . . . . . . . . . . . . . . . 72
       9.3.8.  Resource-ID  . . . . . . . . . . . . . . . . . . . . . 73
       9.3.9.  RLookup  . . . . . . . . . . . . . . . . . . . . . . . 73
       9.3.10. Resource-Object  . . . . . . . . . . . . . . . . . . . 74
       9.3.11. Expires  . . . . . . . . . . . . . . . . . . . . . . . 75
       9.3.12. Owner  . . . . . . . . . . . . . . . . . . . . . . . . 75
       9.3.13. Certificate  . . . . . . . . . . . . . . . . . . . . . 76
       9.3.14. Signature  . . . . . . . . . . . . . . . . . . . . . . 76
       9.3.15. Capabilities and Diagnostics . . . . . . . . . . . . . 76
     9.4.  Response Codes and Errors  . . . . . . . . . . . . . . . . 78
       9.4.1.  Response Codes . . . . . . . . . . . . . . . . . . . . 78
       9.4.2.  Error Object . . . . . . . . . . . . . . . . . . . . . 79
   10. Application Layer  . . . . . . . . . . . . . . . . . . . . . . 80
     10.1. Query  . . . . . . . . . . . . . . . . . . . . . . . . . . 80
     10.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
     10.3. Leave  . . . . . . . . . . . . . . . . . . . . . . . . . . 80
     10.4. Publish  . . . . . . . . . . . . . . . . . . . . . . . . . 80
     10.5. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 80
     10.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 81
   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 82
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 84
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 89
     14.2. Informative References . . . . . . . . . . . . . . . . . . 89
   Appendix A.  Background  . . . . . . . . . . . . . . . . . . . . . 92
   Appendix B.  Message Flow  . . . . . . . . . . . . . . . . . . . . 93



Baset, et al.             Expires May 22, 2008                  [Page 4]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
   Intellectual Property and Copyright Statements . . . . . . . . . . 95

















































Baset, et al.             Expires May 22, 2008                  [Page 5]

Internet-Draft            Peer-to-Peer Protocol            November 2007


1.  Introduction

   This document defines Peer-to-Peer Protocol (P2PP) for creating and
   maintaining an overlay of participant nodes.  The design of P2PP
   exploits commonalities in the peer-to-peer (p2p) protocols such as
   Bamboo [22] 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.  P2PP defines mechanisms for
   NAT and firewall traversal, uses a secure transport, and has
   mechanisms for exchanging node capabilities and diagnostic
   information.  P2PP allows non-participant nodes to use overlay
   services through participant nodes.






































Baset, et al.             Expires May 22, 2008                  [Page 6]

Internet-Draft            Peer-to-Peer Protocol            November 2007


2.  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].

   User:  A human user running the P2PP application and is identified by
      a user-ID.

   User Identifier (User-ID):  A user identifier is an information that
      represents a user in the overlay.

   Node:  A node is an entity that runs an overlay protocol (peer) or
      can access the services provided by an overlay network (client).

   Peer:  A peer is a node participating in an overlay that provides
      storage and routing services to other nodes in the overlay [8].

   Client:  A client is a node participating in an overlay that provides
      neither routing nor storage and retrieval functions [8].

   Peer Protocol:  A structured or unstructured protocol such as Chord,
      Kademlia, Pastry, Gia.

   Joining Peer (JP):  The peer which intends to join the overlay
      network.

   Admitting Peer (AP):  An admitting peer is a peer that receives a
      join request from a joining peer.

   Identifier (ID):  An identifier is 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.

   Peer-ID:  A Peer-ID is information that uniquely identifies a peer
      within a given overlay [8].  In DHT-based overlays, this is a hash
      of a unique node identifier such as an IP address.  In
      unstructured overlays, this is typically an unhashed unique
      identifier.

   Routing Table:  A routing table (known as finger table in Chord) is
      used by a peer to locate a peer or a resource-object.  Peers in a
      DHT-based overlay contain a routing table which is a list of
      overlay peer-IDs and their IP addresses stored against identifiers



Baset, et al.             Expires May 22, 2008                  [Page 7]

Internet-Draft            Peer-to-Peer Protocol            November 2007


      that are exponentially away from the peer's identifier and thus
      has a particular structure.  The routing-table size is
      algorithmically bounded.  In unstructured networks, peers 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.

   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
      (known as successor list in Chord and leaf-set in Pastry) contains
      a list of overlay peer-IDs and their IP addresses which are
      'immediately' close to the node's identifier according to the DHT
      metric.  The purpose of the neighbor table is to maintain
      correctness.  In an unstructured overlay, nodes typically only
      maintain a routing table.

   Neighbor Peers:  The list of peers stored in a neighbor table are
      called neighbor peers.

   Resource Object:  A resource-object is a blob of data stored in the
      overlay and is identified by a resource-ID.  Examples of resource-
      objects are SIP URIs, routing-records, file-names, and service
      identifiers such as those identifying STUN or TURN servers.  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 defined by the user.  Resource Object is known as resource
      record in the concepts document [8].

   Service:  A node can offer services such as NAT and firewall
      traversal and may relay traffic for other nodes.  A node
      advertises its service capabilities in the overlay using a
      resource-object.  Different nodes can advertise the same service.
      The nodes store service advertisements as resource-objects in the
      overlay.

   Heterogeneous Network Environments:  A heterogeneous network
      environment comprises of nodes that use different mechanisms for
      network connectivity such as dialup, DSL, or wireless.

   Overlay Operator:  An entity that uses P2PP to implement an overlay.






Baset, et al.             Expires May 22, 2008                  [Page 8]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Enrollment and Authentication Server:  An entity which enrolls and
      authenticates a user.

   Bootstrap Server:  An entity which provides an IP address and port
      number of an existing node in the overlay to the joining peers.

   Diagnostic Server:  An entity which gathers diagnostic information
      from peers in the overlay.  This information can be used to
      construct a geographical map of the overlay to visually identify
      load hotspots in the overlay.









































Baset, et al.             Expires May 22, 2008                  [Page 9]

Internet-Draft            Peer-to-Peer Protocol            November 2007


3.  Design Overview

3.1.  High-Level Requirements

   There are five high-level requirements for a peer protocol.

   Overlay formation  The protocol should allow nodes to form an overlay
      using well-known structured or unstructured peer-to-peer
      protocols.

   Overlay maintenance:  The protocol should provide mechanisms to
      maintain connectivity and resource availability in an overlay.

   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.

   Heterogeneous capabilities and connectivity:  The protocol should
      allow nodes with heterogeneous capabilities and connectivity (such
      as NATs) to form an overlay.

   Security  The protocol should provide mechanisms to protect against
      well-known threats against overlays.

3.2.  Node Model

   P2PP is an application layer protocol that allows participating nodes
   to form an overlay using a structured or unstructured peer protocol.
   The participating nodes typically represent a human user.  There is a
   one-to-many relationship between the human user and the nodes, i.e.,
   a user can participate in the overlay through one or multiple nodes.
   P2PP defines two types of nodes, namely, peers and clients.  A peer
   is a node participating in an overlay that provides storage and
   routing services to other nodes in the overlay.  A client is a node
   that does not participate in the overlay and hence does not provide
   any storage or routing services.  Instead, it communicates with one
   or more peers to make use of the storage and routing services
   provided by peers.  A peer can participate in more than one overlay
   and a client can also communicate with peers in different overlays.











Baset, et al.             Expires May 22, 2008                 [Page 10]

Internet-Draft            Peer-to-Peer Protocol            November 2007


              User
             / | \
           /   |   \
         /     |     \
       /       |       \
   +-----+  +-----+  +-------+
   |Peer1|  |Peer2|  |Client1|
   +-----+  +-----+  +-------+

   Figure 1: Relationship between user, peers and clients.

   P2PP does not define a priori which nodes can act as peers or clients
   and leaves the decision to overlay operator.  The rationale is that
   P2PP can be used to form an overlay of participating nodes in many
   different network environments.  These include Internet, a
   corporation, a small office, mobile networks and so on.  Nodes which
   are suitable candidates for becoming a peer in one environment may
   not necessarily be suitable in other environment.  CPU, memory,
   uptime and network connectivity are some issues which determine
   whether the node can act as a peer or a client.

   The classification of a node as a peer or a client is not permanent;
   a client can join the overlay as a peer or a peer can invite a client
   to join the overlay.  Similarly, a peer can leave the overlay and
   join as a client.

   In P2PP, peers and clients are identified by a fixed length
   identifier and are chosen from the same identifier space.  To some
   extent, the identifier assignment depends on the underlying peer
   protocol.  For structured protocols such as DHTs, a peer and a client
   identifier is a randomly chosen identifier whose length depends on
   the underlying hash function.  For unstructured protocols, the
   identifier can be chosen in an appropriate way.  Peers and clients
   can choose their own identifiers or have a central authority choose
   their identifiers.  The human users are identified by an identifier
   such as SIP AOR or an email address.  The user identifiers are chosen
   in a distributed fashion and may or may not be managed by a central
   authority.

   The lack of central management authority for choosing a user
   identifier implies that two users can potentially select the same
   user identifier.  Likewise, the possibility of collision also arises
   if peers and clients were to choose their own identifiers.  Further,
   lack of a central authority on user and node identifier assignment
   opens the system to Sybil attack [23].  To address these issues, P2PP
   defines an entity called an enrollment and authentication (E&A)
   server.  The E&A server authenticates the users, and ensures that
   user and node identifiers are unique.  A peer can act as an E&A



Baset, et al.             Expires May 22, 2008                 [Page 11]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   server.

   Bootstraping is a fundamental issue in the overlay as the peers must
   somehow discover the address of other peers in the overlay.
   Similarly, clients also need to discover the address of one or more
   peers in the overlay.  There are different mechanisms for discovering
   a peer already in the overlay [21].  P2PP describes a bootstrap
   server based mechanism, and defines an entity, called bootstrap
   server.  The bootstrap server provides the peers and clients with the
   IP address of participating peers.  The bootstrap server may be co-
   located with the E&A server.  A peer can also act as a bootstrap
   server.

   For diagnostic purposes, an overlay operator may like to construct a
   'map' of nodes.  This allows the overlay operator to identify
   problematic hotspots in the overlay and take remedial actions.  P2PP,
   defines an entity called diagnostic server, which crawls the overlay
   and gathers diagnostic information.

   Purists can argue that the use of enrollment and authentication
   server, bootstrap server, and diagnostic server violates the
   distributed nature of the overlay.  We do not disagree with the
   argument and note that an overlay operator may dispense with these
   entities provided it is aware of the issues that may arise as a
   consequence.  From our experience, we think that the practical issues
   involved in running an overlay necessitate their usage.

   P2PP allows peers to provide services such as NAT traversal.  Many
   peers can provide the same service.  Besides storage and routing,
   P2PP also allows clients to provide services.  Besides, peers and
   clients can store and retrieve data from the overlay.

   P2PP represents both clients and peers by a peer-info object.

3.2.1.  P2PP Node Stack

   The protocol stack of a P2PP node comprises of three conceptual
   layers, namely, application, overlay, and transport layers.  Figure 2
   shows the three layers.












Baset, et al.             Expires May 22, 2008                 [Page 12]

Internet-Draft            Peer-to-Peer Protocol            November 2007


            ^
            |
            |
        Application         +------------+     +-----------+
          Layer             |SIP Proxy/UA|     |Application|
            |               +------------+     +-----------+
            V                      |                 |
                   ================|=================|========= P2PP API
                                   |                 |
            ^            +---------------------+--------------+
            |            |    routing          |   routing    |
         Overlay         |    maintenance      |    state     |
          Layer          |    replication      +--------------|
            |            |    NAT traversal    |  resource    |
            |            |    storage          |   objects    |
            V            +---------------------+--------------+
                                   |        |        |
            ^                 +---------------------------+
            |                 |  -state-machine for       |
            |                 |  reliable and unreliable  |
            |                 |  transports               |
            |                 +---------------------------+
        Transport                  |        |        |
          Layer         ..........................................
            |           . Transport Layer Security (TLS or DTLS) .
            |           ..........................................
            |                      |        |
            |                   +-----+  +-----+
            |                   | UDP |  | TCP |  ... other
            |                   +-----+  +-----+      protocols
            |                      |        |
            |                .............................
            |                .     IP Layer Security     .
            |                .............................
            V                      |        |        |
  =================================|========|========|=============
                                   |        |        |
                          +------------------------------------+
                          |                IP                  |
                          +------------------------------------+

   Figure 2: Protocol stack of a P2PP peer.

3.2.1.1.  Application Layer

   The application layer defines an asynchronous application-level API.
   An application can issue these API to the overlay layer to accomplish
   functions such as joining or leaving an overlay, and to search for



Baset, et al.             Expires May 22, 2008                 [Page 13]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   another peer or resource-object in the overlay.

3.2.1.2.  Overlay Layer

   The overlay layer is the 'brain' of P2PP protocol stack.  It has
   mechanisms for routing, overlay maintenance, replication, NAT
   traversal, and storage management.  The overlay layer receives API
   requests from the usage layer and accomplishes the requested
   function.  The routing mechanism routes the requests in a recursive,
   iterative, or parallel manner.  The overlay maintenance mechanism
   strives to preserve routing correctness and connectivity in the
   presence of churn.  The replication mechanism maintains availability
   of resource-objects in the system.  The NAT traversal mechanism uses
   ICE (TODO: and variants?) to traverse NATs.  The client does not have
   routing, storage, or replication mechanisms.  (TODO: split the
   layer?)

3.2.1.3.  Transport Layer

   P2PP allows sending messages over an unreliable or a reliable
   transport.  It, however, prefers the use of reliable transport such
   as TCP or TLS.  For unreliable transports such as UDP and DTLS, it
   provides an ACK-based hop-by-hop reliability mechanism.  For reliable
   transports, reliability is provided by the underlying transport
   protocol.

3.2.1.3.1.  Listening Ports

   The specification proposes a standard UDP and TCP listening port to
   be assigned by IANA.  The current implementation uses port 7080 as a
   listening port for UDP and TCP, and 7081 for DLTS and TLS.

3.3.  Data Model

   The peers in P2PP provide storage services.  This allows other peers
   and clients to store data on a peer or a set of peers.  In P2PP, the
   data to be stored is defined as a resource-object.  A resource-object
   has a resource-ID which acts as the object locator.  For structured
   overlays such as DHTs, resource-ID is a fixed length identifier.  For
   unstructured overlays, resource-ID can have a variable length.  A
   resource-object has a type and sub-type which identify the
   information being stored.  The type and sub-type define a name-space,
   i.e., resource-objects having same resource-ID but a different type
   and sub-type belong to a different namespace.  An example of a type
   is a user or a service identifier.  Each resource-object has a
   'value' whose description depends on the type and sub-type.  The
   relationship between resource-ID, type, sub-type, and value is shown
   in Figure 3.



Baset, et al.             Expires May 22, 2008                 [Page 14]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Each resource-object has certain properties, namely, the owner of the
   object, the node storing the object and the cryptographic signature
   of the object.  P2PP allows peers to store data having the same
   resource-ID, type and sub-type but different owners.  Similarly, P2PP
   allows nodes to search for resource-objects published by different
   owners.

   Examples of data-types include buddy lists, user-record, and services
   such as NAT and firewall traversal.


   +-----------------------------------------------------------+
   | +-------------------------------------------------------+ |
   | |                       Resource-ID                     | |
   | +-------------------------------------------------------+ |
   |  +-------------------------+  +-------------------------+ |
   |  |           Type1         |  |           Type2         | |
   |  | +---------+ +---------+ |  | +---------+ +---------+ | |
   |  | |Sub-type1| |Sub-type2| |  | |Sub-type1| |Sub-type2| | |
   |  | +---------+ +---------+ |  | +---------+ +---------+ | |
   |  |  +------+    +------+   |  |  +------+    +------+   | |
   |  |  |Value1|    |Value1|   |  |  |Value1|    |Value1|   | |
   |  |  +------+    +------+   |  |  +------+    +------+   | |
   |  |                         |  |                         | |
   |  |  +------+    +------+   |  |  +------+    +------+   | |
   |  |  |Value2|    |Value2|   |  |  |Value2|    |Value2|   | |
   |  |  +------+    +------+   |  |  +------+    +------+   | |
   |  |                         |  |                         | |
   |  +-------------------------+  +-------------------------+ |
   |                                                           |
   +-----------------------------------------------------------+

   Figure 3: Resource-object.

3.4.  Message Model

   P2PP messages begin with a header followed by a sequence of type-
   length-value (TLV) objects.  P2PP defines five types of message.
   However, the three key messages are requests, responses, and
   indications.  The requests always generate a response, where as
   indications do not require any.  Indications are useful in scenarios
   such as informing other peers about a routing table change.  The
   response have a response code which is inspired from HTTP and SIP
   response codes.

   P2PP allows nodes to forward requests in a recursive or an iterative
   manner.  In recursive routing, a request is forwarded from one peer
   to the other until it reaches its destination.  The response is then



Baset, et al.             Expires May 22, 2008                 [Page 15]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   sent along the same path on which the request was received.  In
   iterative routing, if a peer determines that it is not the
   destination of the message, it sends in its response the IP address
   of the next hop.  The request originator then sends the request to
   the next hop.  Peers never forward the indications.  Figure 4 and 5
   show a conceptual diagram of request routing in a recursive and
   iterative manner, respectively.


   Peer1          Peer2          Peer3
    |    Request    |              |
    |-------------->|    Request   |
    |               |------------->|
    |               |    Response  |
    |               |<-------------|
    |    Response   |              |
    |<--------------|              |

   Figure 4: A conceptual diagram showing request routing in a recursive
   manner.


   Peer1          Peer2          Peer3
    |    Request    |              |
    |-------------->|              |
    |    Response   |              |
    |<--------------|              |
    |            Request           |
    |-----------------------------<|
    |            Response          |
    |<-----------------------------|
    |                              |

   Figure 5: A conceptual diagram showing request routing in an
   iterative manner.

3.5.  Reliability Model

   P2PP defines a hop-by-hop reliability model, i.e., the request,
   response, and indications originators are only responsible for
   ensuring that the message reaches the next hop.  P2PP allows nodes to
   send messages over a reliable and unreliable transport.  For
   unreliable transports, P2PP provides an acknowledgement (ACK) based
   mechanism to ensure reliability of message delivery.  The
   acknowledgement is the fourth type of P2PP message.

   P2PP does not support message fragmentation and instead makes use of
   the underlying reliable transport such as TCP or TLS larger than MTU



Baset, et al.             Expires May 22, 2008                 [Page 16]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   messages.

   For recursive routing, the hop-by-hop reliability model allows the
   routing path to be a mix of reliable and unreliable transports.
   Figure 4 and 5 showed the message forwarding in a recursive manner
   and iterative manner over reliable transport.  Figure 6(a) and 7(a)
   show the unoptimized message forwarding in a recursive and iterative
   manner over unreliable transport.  In recursive routing, the peer
   responsible for generating a response sends an ACK and then
   immediately sends a response.  In iterative routing, every node must
   acknowledge the request and immediately send the response.  To avoid
   the transmission of an ACK followed by a response, P2PP, defines a
   fifth type of message, namely, responseACK which combines the
   response and acknowledgement in one message.


Peer1          Peer2          Peer3  Peer1          Peer2          Peer3
 |    Request    |              |      |    Request    |              |
 |-------------->|              |      |-------------->|              |
 |     ACK       |              |      |     ACK       |              |
 |<--------------|    Request   |      |<--------------|    Request   |
 |               |------------->|      |               |------------->|
 |               |      ACK     |      |               | ResponseACK  |
 |               |<-------------|      |               |<-------------|
 |               |   Response   |      |               |      ACK     |
 |               |<-------------|      |               |------------->|
 |               |      ACK     |      |   Response    |              |
 |               |------------->|      |<--------------|              |
 |   Response    |              |      |     ACK       |              |
 |<--------------|              |      |-------------->|              |
 |     ACK       |              |      |               |              |
 |-------------->|              |
             (a)                                      (b)

   Figure 6: Request routing in a recursive manner over unreliable
   transport. (a) unoptimized forwarding (b) optimized forwarding.















Baset, et al.             Expires May 22, 2008                 [Page 17]

Internet-Draft            Peer-to-Peer Protocol            November 2007


Peer1          Peer2          Peer3  Peer1          Peer2          Peer3
 |    Request    |              |      |    Request    |              |
 |-------------->|              |      |-------------->|              |
 |      ACK      |              |      |  ResponseACK  |              |
 |<--------------|              |      |<--------------|              |
 |    Response   |              |      |      ACK      |              |
 |<--------------|              |      |-------------->|              |
 |      ACK      |              |      |                              |
 |-------------->|              |      |            Request           |
 |                              |      |----------------------------->|
 |            Request           |      |           ResponseACK        |
 |----------------------------->|      |<-----------------------------|
 |              ACK             |      |              ACK             |
 |<-----------------------------|      |----------------------------->|
 |            Response          |      |                              |
 |<-----------------------------|
 |              ACK             |
 |----------------------------->|

               (a)                                     (b)

   Figure 7: Request routing in an iterative manner over unreliable
   transport. (a) unoptimized forwarding (b) optimized forwarding.

   Thus, P2PP defines five types of message, namely, request, response,
   responseACK, indication, and acknowledgement.  A response or
   responseACK must match to the request.  Similarly, an ACK must match
   to the request, response, or responseACK that it acknowledges.  The
   transmission of a request, response, responseACK, and an indication
   is governed by a transaction state-machine described in Section 6.2.

3.6.  Security Model

   P2PP provides a hop-by-hop security model.  The nodes in P2PP
   establish an unreliable or reliable secure channel with other nodes
   using DTLS or TLS.  However, peers establish a secure SIP session in
   an end-to-end manner.

   P2PP uses an enrollment and authentication (E&A) server to enroll new
   users in the overlay and to authenticate existing users.  Once
   authenticated, it issues a certificate that binds the user-identifier
   and public key of the user.  Further, it also generates a peer or a
   client identifier and adds it to the certificate.

   P2PP also allows nodes to operate without a central enrollment and
   authentication server.  In such a scenario, nodes use self-signed
   certificates and generate their own identifiers.




Baset, et al.             Expires May 22, 2008                 [Page 18]

Internet-Draft            Peer-to-Peer Protocol            November 2007


3.6.1.  Threat Model

   This section lists the security threats and discusses mechanisms P2PP
   provides to protect against some of these threats.  The threats
   against overlays can be loosely classified into routing, storage, and
   replay threats.  Below we list some of the possible attacks within
   each threat.  P2PP provides protection against some of these attacks.

   Routing Threats

   1.  Obtain a significant portion of user or peer identifiers to
       launch a Sybil attack.

   2.  Sniff on the messages between peers.

   3.  Corrupt a message flow between peers, thereby violating message
       integrity.

   4.  Infer user or flow identity from the legitimately received
       messages.

   5.  Incorrectly route or drop a message.

   6.  Poison routing or neighbor tables.

   7.  Launch a DoS or DDoS against a peer or set of peers.

   Storage Threats

   1.  Corrupt a stored object, thereby violating storage integrity.

   2.  Unauthorized storage or lookup.

   3.  Launch a storage DoS attack against a peer or set of peers.

   4.  Does not invalidate storage cache, thereby returning old copies
       of the stored object.

   Replay Threats

   1.  Replay a message.

   Currently, P2PP provides protection against (1)-(3) of routing
   threats, (1)-(3) of storage threats, and (1) of replay threats.  The
   next section discusses mechanism provided by P2PP for protection
   against these threats.





Baset, et al.             Expires May 22, 2008                 [Page 19]

Internet-Draft            Peer-to-Peer Protocol            November 2007


3.7.  NAT and Firewall Traversal

   P2PP allows any node to act as a NAT traversal server.  The node
   providing the NAT traversal service allows the node behind a NAT to
   discover their NAT types and to determine their reachable address
   using STUN [5] or TURN [6].  Many nodes can provide the NAT traversal
   service and a key issue is how this information is published in the
   overlay and how to discover an appropriate NAT traversal server.
   P2PP provides RTT and autonomous-system (AS) number based mechanisms
   for a node to discover a close-by NAT traversal server.  In a large
   corporation, peers may also use an IP-prefix based mechanism to
   discover a close by NAT traversal server.  P2PP leaves the selection
   of this mechanism to overlay operator.  P2PP also allows an
   overloaded node providing NAT traversal service to redirect NAT
   traversal requests to unloaded nodes.

   In a peer-to-peer network, there is no guarantee on the availability
   of a node.  A node whose reachability depends on a peer providing NAT
   traversal service may discover that the peer is no longer online.
   Consequently, the reachable IP address of a node obtained through a
   peer providing a NAT traversal service that is no longer online
   becomes invalid.  Therefore, a node may need to discover another peer
   providing NAT traversal service, determine its new reachable address,
   readvertise this information in the overlay, and establish new
   connections with routing and neighbor peers.  Depending on the churn
   rate, this can incur a significant communication overhead.

   The requests can be routed in a recursive or an iterative manner.
   The choice of routing mechanism has an impact on the performance of
   NAT traversal mechanism.  We discuss these issues in Section 4.3.2
   and suggest that the non significant overhead of ICE [7] as-is does
   not lead to its automatic selection as a NAT traversal mechanism.

   TODO: Besides NATs, the firewalls can hinder connectivity and result
   in non-transitivity of connection.

3.8.  Mobility

   We classify P2PSIP mobility into three subcategories: peer mobility,
   client mobility, and session mobility.  The following sections
   discuss different aspects of P2PSIP mobility in details.

3.8.1.  Peer Mobility

   Mobile devices such as mobile and WiFi phones or laptops may move
   from one network to another by doing handover between different
   access networks or moving from one WLAN access point to another.
   Whenever a peer changes its access network (e.g., from WCDMA to



Baset, et al.             Expires May 22, 2008                 [Page 20]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   WLAN), its IP address also changes.  In P2PSIP networks where P2PSIP
   peer software runs also in mobile terminals, peer-IDs must not be
   assigned based on IP addresses.  If a peer-ID was constructed using
   an IP address of a peer, any change in the IP address would cause the
   change of the peer-ID, introducing instability in the DHT network.
   Further, a peer needs to inform its routing and neighbor peers about
   any change in the IP address.

   Any change in the peer-ID computed using IP address require a peer to
   leave the P2PSIP overlay network and join the overlay network once
   again with the new peer-ID.  Besides updates to the DHT do not take
   place immediately after a node has gone.  It may take some time until
   all the data is again in the proper place, including the re-creation
   of routing tables.  This may cause network instability and require
   additional resources to handle network adaptation especially in a
   battery powered mobile devices.  Besides in the transition period
   search delay for user contact information may be higher, delaying the
   call establishment.

   Rather than constructing peer-IDs by hashing the IP address or a
   random peer-ID, which is no longer static for the duration of the
   connection to the DHT, P2PP allows P2PSIP networks to assign a static
   and unique (within a DHT ring) peer-IDs.  The enrollment and peer-ID
   assignment is presented in Section 4.5.  In addition, P2PP allows
   peers to advertise changes of their IP addresses to other peers.
   When a peer moves to another subnet after a handover, it receives a
   new IP address.  Since the peer-ID does not change, it does not
   introduce instability into the DHT.  However, the peer has to inform
   its neighbors about its new IP address.  To each neighbor, the peer
   presents the new IP address, and authentication data (a certificate)
   that also includes the existing peer-ID.  The neighbor authenticates
   the update request and stores the new IP address bound to that
   peer-ID.

3.8.2.  Client Mobility

   Mobile clients may change IP address in the same way as mobile peers
   do.  The main difference between the client mobility and the peer
   mobility is that the client mobility does not influence the structure
   of the overlay.  However, the client mobility may have impact on the
   reachability of the client itself.  In case of a handover, a mobile
   client must update user records in DHT in real time if it still wants
   to be reachable.  In order to fulfill this requirement, the client
   must contact the peer that stores the user record.  When the client
   changes its IP address, it must update the user record by sending
   publish request directly to the peer storing the record.  If the peer
   is not reachable, the client must send the publish request to any of
   the available peers using either recursive or iterative routing.



Baset, et al.             Expires May 22, 2008                 [Page 21]

Internet-Draft            Peer-to-Peer Protocol            November 2007


3.8.3.  Session Mobility

   Session mobility is related to the mobility of SIP user agent during
   a SIP session.  This may happen when one or more endpoints that are
   participating in the same SIP session change their IP addresses
   because of a handover.  In order to preserve the service continuity,
   clients need to support a method that will minimize session
   interruption due to handovers.  This memo does not provide any
   solution for SIP session mobility.  Instead, it is expected that a
   generic SIP solution for session mobility will be re-utilized in
   P2PSIP once such solution is developed.

3.9.  Overview of Operations

   The following table gives a brief description of P2PP messages and
   their message type.  It also indicates which messages may be sent by
   a peer or a client.  The messages have been grouped together by
   relevant functions.

3.9.1.  Enrollment, Authentication, and Bootstrap

   +--------------+---------+--------+---------------------------------+
   | Operation    | Message | Peer   | Description                     |
   |              | Type    | or     |                                 |
   |              |         | Client |                                 |
   +--------------+---------+--------+---------------------------------+
   | Enroll       | R       | P|C    | Enrolls the user in the         |
   |              |         |        | overlay.                        |
   |              |         |        |                                 |
   | Authenticate | R       | P|C    | Authenticate the user and       |
   |              |         |        | generates a certificate binding |
   |              |         |        | user-ID, peer or client ID, and |
   |              |         |        | public key of the peer.         |
   |              |         |        |                                 |
   | Bootstrap    | R       | P|C    | Clients and peers send this     |
   |              |         |        | request to a bootstrap server   |
   |              |         |        | or a peer to discover the IP    |
   |              |         |        | address of a peer in the        |
   |              |         |        | overlay.                        |
   +--------------+---------+--------+---------------------------------+











Baset, et al.             Expires May 22, 2008                 [Page 22]

Internet-Draft            Peer-to-Peer Protocol            November 2007


3.9.2.  Overlay Maintenance

   +---------------+---------+--------+--------------------------------+
   | Operation     | Message | Peer   | Description                    |
   |               | Type    | or     |                                |
   |               |         | Client |                                |
   +---------------+---------+--------+--------------------------------+
   | Join          | R       | P|C    | Peers send this request to     |
   |               |         |        | join the overlay.  Depending   |
   |               |         |        | on the peer protocol being     |
   |               |         |        | used, the join request is      |
   |               |         |        | forwarded to the peer where    |
   |               |         |        | this peer will join.  Client   |
   |               |         |        | sends a join request to a peer |
   |               |         |        | discovered using bootstrap     |
   |               |         |        | mechanism and becomes attached |
   |               |         |        | to the peer.                   |
   |               |         |        |                                |
   | Leave         | I       | P|C    | Peers send the leave           |
   |               |         |        | indication to their routing    |
   |               |         |        | and peers indicating their     |
   |               |         |        | departure.  Clients            |
   |               |         |        | periodically send the leave    |
   |               |         |        | message to their respective    |
   |               |         |        | peers.                         |
   |               |         |        |                                |
   | KeepAlive     | I       | P|C    | Peers periodically send a      |
   |               |         |        | keepalive indication to their  |
   |               |         |        | routing and neighbor peers to  |
   |               |         |        | check whether they are alive.  |
   |               |         |        | Clients send a keepalive to    |
   |               |         |        | their peers to check whether   |
   |               |         |        | they are alive.                |
   |               |         |        |                                |
   | LookupPeer    | R       | P      | Peers send this request to     |
   |               |         |        | discover a peer that may fill  |
   |               |         |        | or update a missing entry in   |
   |               |         |        | their routing or neighbor      |
   |               |         |        | table.                         |
   |               |         |        |                                |
   | ExchangeTable | R       | P      | Peers periodically send this   |
   |               |         |        | request to their routing and   |
   |               |         |        | neighbor peers obtain their    |
   |               |         |        | routing and neighbor tables.   |
   |               |         |        |                                |






Baset, et al.             Expires May 22, 2008                 [Page 23]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   | Replicate     | R       | P      | Peers periodically send this   |
   |               |         |        | request to replicate the       |
   |               |         |        | resource-objects for           |
   |               |         |        | availability.  The choice of   |
   |               |         |        | peers on which to replicate    |
   |               |         |        | the objects depends on the     |
   |               |         |        | peer protocol.                 |
   |               |         |        |                                |
   | Transfer      | R       | P      | After a successful join or     |
   |               |         |        | graceful or ungraceful failure |
   |               |         |        | of peers, a peer transfers the |
   |               |         |        | ownership of resource-objects  |
   |               |         |        | using a transfer request.      |
   +---------------+---------+--------+--------------------------------+

3.9.3.  Data Storage and Retrieval

   +---------------+---------+--------+--------------------------------+
   | Operation     | Message | Peer   | Description                    |
   |               | Type    | or     |                                |
   |               |         | Client |                                |
   +---------------+---------+--------+--------------------------------+
   | PublishObject | R       | P|C    | Publish a resource-object.     |
   |               |         |        | Also, used to refresh or       |
   |               |         |        | update an existing             |
   |               |         |        | resource-object.               |
   |               |         |        |                                |
   | LookupObject  | R       | P|C    | Search for a resource-object.  |
   |               |         |        |                                |
   | RemoveObject  | R       | P|C    | Remove the resource-object.    |
   +---------------+---------+--------+--------------------------------+

3.9.4.  Connection Management and Other

   +-----------+---------+--------+------------------------------------+
   | Operation | Message | Peer   | Description                        |
   |           | Type    | or     |                                    |
   |           |         | Client |                                    |
   +-----------+---------+--------+------------------------------------+
   | Tunnel    | R       | P|C    | Tunnel an application layer        |
   |           |         |        | protocol message into a P2PP       |
   |           |         |        | message.  Mostly used for sending  |
   |           |         |        | SIP messages to peers or clients   |
   |           |         |        | behind a NAT.                      |
   |           |         |        |                                    |
   | Connect   | R       | P|C    | Send an ICE offer (TBD).           |
   |           |         |        |                                    |




Baset, et al.             Expires May 22, 2008                 [Page 24]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   | Invite    | R       | P      | Peers send an invite request to a  |
   |           |         |        | client, inviting them to become a  |
   |           |         |        | peer.                              |
   |           |         |        |                                    |
   | Query     | R       | P|C    | Query a peer or a client to        |
   |           |         |        | discover the services they provide |
   |           |         |        | or the resource-objects they       |
   |           |         |        | store.                             |
   +-----------+---------+--------+------------------------------------+

3.10.  Overlay Migration

   This mechanism allows nodes to migrate from one overlay protocol to
   the other and to download a software update for the overlay protocol.
   (TBD.)




































Baset, et al.             Expires May 22, 2008                 [Page 25]

Internet-Draft            Peer-to-Peer Protocol            November 2007


4.  Overlay Layer

4.1.  Peer State

   A 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.

   Base:  The logarithm base for a DHT, if a DHT is used as a peer
      protocol.

   Routing Table:  A table of other peers in the overlay.  For each
      peer, the 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 and port: The IP address and port 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, the 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 and port: The IP address and port of the peer.

      RTT: The round-trip-time of this peer.

      Uptime: The uptime of the peer (overlay software).

   Number of Neighbors:  Total number of peers in routing and neighbor
      tables.





Baset, et al.             Expires May 22, 2008                 [Page 26]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Publish Table:  The resource-objects this peer has published in the
      overlay.  It must periodically refresh the resource-objects before
      the passage of their refresh time interval.

   Resource Table:  Resource-objects this peer is responsible for.

   Replicated Resource Table:  Resource-objects this peer stores as
      backup for other objects.

   Transaction Table:  A transaction table which keeps track of in-
      progress transactions.  The transaction can be a request,
      response, or an indication transaction.

   Uptime:  The uptime of this peer.

   Number of Clients:  Number of clients connected to this peer.

   Media Relay Flows:  The number and bandwidth of media flows being
      relayed through this peer.

   Additionally, it may keep track of the following diagnostic
   information:

   Bandwidth:  The current bandwidth being used.

   Number of Messages:  The number and cumulative size of messages
      received within the last x seconds.

   Autonomous System Number:  The AS number of the peer.  It can be used
      to advertise STUN or TURN services.

4.2.  Key Components of a P2PP Message

   This section describes the key TLV objects defined by P2PP.

   Common Header: The common header is a fixed length header which is
   part of every message (Section 9.1.  It contains the message type,
   request or indication type, TTL, a magic cookie to differentiate P2PP
   from other protocols, transaction-ID, source-ID and a response-ID.
   The message type defines the type of the message, namely, request,
   response, responseACK, or indication where as the request or
   indication type defines the type of request or indication being sent.
   The transaction-ID is a unique number chosen by the request or
   indication originator.  The source-ID represents the peer-ID of the
   message originator peer.  Response-ID is only included in the ACK,
   response, or a responseACK, and represents the peer-ID of the peer
   generating the response, responseACK, or ACK.  Since peer-IDs must be
   unique and peers must choose a locally unique transaction-ID, the



Baset, et al.             Expires May 22, 2008                 [Page 27]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   combination of source-ID and transaction-ID can uniquely identify a
   message.

   Peer-Info: Peer-Info TLV represents a peer in the overlay.  A peer
   has a fixed length identifier and a set of reachable IP address and
   port numbers gathered using ICE.  Further, a peer maintains its
   uptime information, number of connected clients, routing and neighbor
   peers, a certificate, and bandwidth.  This information is encoded as
   follows:

   Peer-Info = Peer-ID
               [Address-Info]
               [Uptime]
               [Certificate]
               [Connections]
               [Node-Resource-Utilization]
               [ext]

   Similar to peers, clients also have an identifier derived from the
   same identifier space as peers.  There is almost no difference
   between the peer-info TLV representing a peer and peer-info TLV
   representing a client, except that other peers must not update their
   routing and neighbor tables with the client.  Peers can also invite
   clients to become peers in the overlay and therefore, it made sense
   that clients already have an identifier when they receive such an
   invitation as they can then immediately join the overlay, without
   going through an E&A server and obtaining a certified peer-ID.

   This specification represents both peers and clients with a peer-info
   object.  When forwarding messages, the message originated by a peer
   or a client is differentiated based on a 'peer or client' flag in the
   common header.

   An approximate size of a peer-info object for a 20 byte peer-ID, and
   an address info object containing host, server-reflexive, and relay
   candidates is (4+4+20+4+46)=78 bytes.

   Resource-Object: Resource-object represents the information that
   peers store in the overlay.  As discussed in Section 3.2, a resource-
   object has a resource-ID, type, sub-type, and a value.  Further, a
   resource-object has additional properties, namely, owner, peer who
   inserted or updated the object, and a signature.  Resource-ID is a
   fixed length identifier for DHTs and could be a variable length
   identifier for unstructured overlays.  The size of the resource-
   object is limited to 65,536 bytes.  A resource-object is encoded as
   follows:





Baset, et al.             Expires May 22, 2008                 [Page 28]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Resource-Object = Resource-ID
               [Peer-Info]
               [Owner]
               [Signature]
               Value
               [ext]

4.3.  Request, Response, and Indications Processing

   To send a request, response, responseACK, or an indication, a peer
   creates a transaction and passes it the message.  The peer identifies
   a transaction using a source-ID and transaction-ID tuple as described
   in Section 6.1.  For response and responseACK, an additional
   consideration is that it must contain the same source-ID and
   transaction-ID as the request for which the response is being
   generated.  Similar considerations hold for ACK which acknowledges
   requests, responses, or indications over unreliable transport.
   Following considerations apply when sending a message.

   1.  A node may set request-routing-table or request-neighbor-table
       flags requesting to receive the peer-info objects containing
       peer-ID and address-info objects.  If the message was sent over
       unreliable transport, the node issuing the request SHOULD always
       set the in-separate-request flag in the Request-Options object.
       For a routing table that contains 100 nodes, which can be typical
       for a million user overlay, and an average peer-info object size
       of 78 bytes, the routing or neighbor table is not likely to fit
       within response UDP packet.

   A message can be received over UDP or TCP.  A message received over
   unreliable is processed according to the following steps:

   1.  The peer checks whether a transaction already exists in the
       transaction table.  As described in Section 4.1, a peer keeps
       track of in-progress transactions in a transaction table.  If a
       transaction exists, the peer sends an ACK response and terminates
       the message processing.  The received requests are matched
       against the response transaction having the same source-ID and
       transaction-ID where as the received responses are matched
       against request and response transactions.

   2.  If the transaction does not exist in the transaction table, the
       peer checks the TTL field in the common header.  If TTL is equal
       to zero, and the message was a request, it MUST reply with a 410
       (TTL Hops Exceeded) response and include its Peer-ID in the
       Response-ID field in the common header.  Additionally, it MUST
       send an ACK to the received request.  If a peer receives a
       response, indication or an ACK with a TTL equal to zero, it



Baset, et al.             Expires May 22, 2008                 [Page 29]

Internet-Draft            Peer-to-Peer Protocol            November 2007


       ignores the message.  Instead of sending a separate ACK and a
       response message, it sends a responseACK message.  It creates a
       responseACK transaction as shown in Figure 3 and passes it the
       responseACK message.  The transaction has the same source-ID as
       the one received in the request.  The response-ID is set to the
       ID of the peer generating response or responseACK.  The response
       is always sent to the peer from whom the request was received and
       not to the peer who issued the request.

   3.  If TTL is greater than zero, recursive routing was being used (R
       flag is set in the common header), and the peer cannot generate a
       response for the received request, it determines the next hop
       from its routing or neighbor tables, creates a request
       transaction, and passes it the request after decrementing TTL by
       one in the common header.  The transaction has the same
       identifier (source-ID, transaction-ID) as the one received in the
       request.  The rest of the forwarded request remains unchanged.
       Also, it sends an ACK message to the peer from whom it received
       the request and sets its own peer-ID in the response-ID of the
       ACK message.  If a response is received for which a corresponding
       request transaction exists, the peer immediately terminates the
       request transaction, creates a response transaction and passes it
       the received response for delivery to the upstream peer.

   4.  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 creates a
       responseACK transaction and passes it a 302 (Next Hop) response.
       The peer includes its Peer-Info and the next hop Peer-Info object
       in the responseACK message.

   5.  If a peer can generate a response for a received request, it must
       create a responseACK transaction.  If a peer receiving the
       request determines that it can generate a response, 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 RA and RB seconds, and sends a copy of
       its routing or neighbor table or both in an ExchangeTable request
       to the peer which issued the request (not the peer which
       forwarded the request).  If in-separate-request was not set, the
       peer includes in the response as much of the requested routing or
       neighbor table entries as permitted by the UDP MTU.

   6.  If the peer receiving the request determines that it can generate
       a response 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



Baset, et al.             Expires May 22, 2008                 [Page 30]

Internet-Draft            Peer-to-Peer Protocol            November 2007


       retry the request over TCP.  A 413 response is not sent if the
       response can fit within UDP MTU but requested routing or neighbor
       table cannot fit within MTU.

   7.  A peer should always send an ACK to any retransmissions of the
       request, response, or indication.

   8.  The peer checks if it can update its routing and neighbor tables
       from the received request or response.

   9.  If a peer receives a response, it immediately replies with an ACK
       message.  It then searches for the corresponding request
       transaction in its transaction table.  If a request transaction
       is found, and if the peer receiving the response was the request
       originator it passes the response to the overlay layer.
       Otherwise, it creates a response transaction and passes it the
       received response.  The response is sent to the same IP address
       and port number from which the request was received.  If a
       request transaction is not found and the peer receiving the
       response was not the request originator, the response is
       discarded.  However, an ACK is still generated for the discarded
       response.  The transmission of ACK is an indication that the peer
       receiving the response is still alive.

   A peer sending an indication sets the TTL field to one.  A peer
   receiving an indication over unreliable transport immediately
   generates an ACK.  An indication is never forwarded so R flag is
   never set for an indication.

   To send a message over a reliable transport, a peer creates an
   appropriate transaction as shown in Figure 4 and 5 and passes it the
   message.

   A request or response received over a reliable transport is processed
   according to the following steps.

   1.  The peer checks whether a transaction already exists in the
       transaction table.  This transaction can either be a request,
       response transaction.

   2.  If the transaction does not exist in the transaction table, the
       peer checks the TTL field in the common header.  If TTL is equal
       to zero, it MUST reply with a 410 (TTL Hops Exceeded) response
       and include its Peer-ID in the Response-ID field in the common
       header.  It creates a response transaction as shown in Figure 5
       and passes it the response .  The transaction has the same
       identifier as the one received in the request.  The response is
       always sent to the peer from whom the request was received and



Baset, et al.             Expires May 22, 2008                 [Page 31]

Internet-Draft            Peer-to-Peer Protocol            November 2007


       not to the peer who issued the request.

   3.  If TTL is greater than zero, recursive routing was being used (R
       flag is set in the common header), and the peer cannot generate a
       response for the received request, it determines the next hop
       from its routing or neighbor tables, creates a request
       transaction, and passes it the request after decrementing TTL by
       one in the common header.  The transaction has the same
       identifier (source-ID, transaction-ID) as the one received in the
       request.  The rest of the forwarded request remains unchanged.

   4.  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 creates a
       response transaction and passes it a 302 (Next Hop) response.
       The peer includes its Peer-Info and the next hop Peer-Info object
       in the response.

   5.  If a peer receiving the request determines that it can generate a
       response, it checks if the Request-Options object was present and
       whether request-routing-table or request-neighbor-table and in-
       separate-request flags were set.  If set, the peer waits for a
       random time between RA and RB 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 in the response up to 256 routing and
       neighbor table entries each.

   6.  The peer checks if it can update its routing and neighbor tables
       from the received request or response.

   7.  The peer receiving the response searches for the corresponding
       request transaction in its transaction table.  If a request
       transaction is found, and if the peer receiving the response was
       the request originator it passes the response to the overlay
       layer.  Otherwise, it terminates the request transaction, creates
       a response transaction and passes it the received response.  The
       response is sent to the same IP address and port number from
       which the request was received.  If a request transaction is not
       found and the peer receiving the response was not the request
       originator, the response is discarded.

4.3.1.  ACK generation

   A node MUST send an ACK for every request, response, responseACK, or
   indication received over unreliable transport.  The following diagram
   depicts the message for requests forwarded in a recursive manner over
   unreliable transport.



Baset, et al.             Expires May 22, 2008                 [Page 32]

Internet-Draft            Peer-to-Peer Protocol            November 2007


     A                        B                         C
   (idA)                    (idB)                     (idB)
     |  req(sid=idA,rid=)     |                         |
     |----------------------->|                         |
     |  ACK(sid=idA,rid=idB)  |                         |
     |<-----------------------|    req(sid=idA,rid=)    |
     |                        |------------------------>|
     |                        | respACK(sid=idA,rid=idC)|
     |                        |<------------------------|
     |                        |   ACK(sid=idA,rid=idC)  |
     |                        |------------------------>|
     |respACK(sid=idA,rid=idC)|                         |
     |<-----------------------|                         |
     |  ACK(sid=idA,rid=idC)  |                         |
     |----------------------->|                         |

   Figure 6: Message flow for requests forwarded in a recursive manner
   over unreliable transport.

   The encoding of response-ID field in the ACK is according to the
   following rule: If no response-ID was received in the message, then
   the node generating an ACK MUST include its own peer-ID as the
   response-ID.  If the source-ID and response-ID field were already
   present in the message, then the ACK message should copy back
   source-ID and response-ID fields.

4.3.2.  Recursive and Iterative Routing

   P2PP does not require all peers must use either recursive or
   iterative routing.  Based on their connectivity information, peers
   may choose to send requests in a recursive or iterative manner.  The
   request routing mechanism is determined by a recursive or iterative
   flag in the common header.  Only requests can be sent in a recursive
   or iterative manner.  Below, we discuss the issues involved in the
   use of recursive and iterative routing that highlight the need to
   support both mechanisms.  Further, we also discuss the issues that
   are peculiar to the recursive or iterative forwarding of requests.

4.3.2.1.  Loop Detection

   Iterative routing does not require the design of complicated
   mechanisms, such as route-log, for detecting forwarding loops nor is
   there a need to design mechanisms for message forking and fork
   explosion.







Baset, et al.             Expires May 22, 2008                 [Page 33]

Internet-Draft            Peer-to-Peer Protocol            November 2007


4.3.2.2.  Rogue Peer

   If the message is forwarded in a recursive manner, a rogue peer along
   the request path may simply drop the message.  It will be a while
   before the request originator realizes such a behavior.  In iterative
   routing, a peer has control of the messages and it could quickly
   determine if its messages are being dropped.

4.3.2.3.  Secure Channel Establishment

   In recursive routing, a peer sends a message to its routing or
   neighbor peers.  It is likely that a node sending the message has a
   secure reliable or unreliable channel with its routing or neighbor
   peers.  In iterative routing, a node may need to communicate with
   previously uncontacted peers.  It is quite possible that the peers
   contacted during iterative routing may never be contacted again.
   When requests are routed in an iterative manner, and if a peer
   somehow has certificate of the communicating peer, it may use DTLS or
   TLS.

   In DTLS the secure channel establishment at least requires two RTT of
   setup time.  In addition, for TLS, a TCP connection must be
   established.  This requires 1.5 RTT of setup time.  The nodes can
   securely communicate after the establishment of secure and/or
   reliable channel.

   If a node uses DTLS or TLS to establish a secure channel with other
   nodes while forwarding requests in an iterative manner, it could
   incur a per hop setup overhead of 2 and 3.5 RTT for DTLS and TLS,
   respectively.  Recursive routing does not have this setup overhead
   because nodes typically only communicate with peers in their routing
   and neighbor tables with which they have a long lived secure
   connection.  This makes the choice of iterative routing less
   attractive than recursive routing.

   As discussed in Section 4.3.2 iterative routing has three nice
   properties.  First, unlike recursive routing, the request originator
   has control over which nodes it should contact.  Second, the number
   of message hops is always one which prevents complicated routing bugs
   and schemes for loop detection.  Finally, it prevents fork explosion
   when parallel copies of the request are issued in a recursive manner.

   Thus, we believe, there is a need to incorporate iterative routing
   mechanism as part of P2PP and ensure that the use of underlying
   transport protocol such as DTLS does not impact the performance of
   iterative routing vis-a-vis recursive routing.  Clearly, DTLS is
   unsuitable for iterative routing due to it's per hop secure channel
   setup overhead.  Therefore, we propose a to design a new secure and



Baset, et al.             Expires May 22, 2008                 [Page 34]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   unreliable transport protocol which preserves message confidentiality
   and integrity, and is geared towards iterative routing in overlay
   networks.  This suggestion is open to discussion.

4.3.2.4.  NAT Traversal

   Recursive routing is more friendly towards NATs and firewalls since a
   peer sends a message to the peers that have been recently
   communicated with.  In iterative routing, a peer will likely have to
   send a message to a previously unknown peer.  This unknown peer could
   be behind a NAT.  A mechanism based on an offer/exchange mechanism of
   ICE will incur a significant communication overhead (REF:sec).
   Further, it is possible that a peer may not need to subsequently
   communicate with this peer behind the NAT and the overhead of ICE
   connectivity checks is perhaps overkill.  The other mechanism to
   communicate with a peer behind a NAT is that a peer simultaneously
   sends the message to the host, server reflexive, and relay address of
   the peer behind a NAT.  This requires the peer behind a NAT to
   publish and periodically refresh this information.

4.3.2.5.  Route Log

   The recursive forwarding of requests require intermediate peers to
   maintain state.  The peers forwarding the request in a recursive
   manner may avoid the need of maintaining state by adding their Peer-
   Info objects to the route-log.  The peers can only add their Peer-
   Info objects to the route-log if it was explicitly requested by the
   request originator.

   As discussed in Section 4.2, the approximate size of a peer-info
   object containing peer-ID and host, server-reflexive, and relay
   addresses is 78 bytes.  If the request traverses approximately 20
   hops, the route-log size can easily exceed UDP MTU (assuming UDP is
   1,500 bytes).  Route-logs are not needed when messages are forwarded
   in an iterative manner.

4.4.  Message Encoding Guidelines

   The message originator sets the source-ID in the message header and
   includes its peer-info object in the message.  It may set the peer-ID
   object in the peer-info object.  The peer generating an ACK or a
   response retains the request originator peer-ID in source-ID field.
   Additionally, it sets its own peer-ID in the response-ID field in the
   common header and includes its peer-info object.  Unless requested by
   the message originator, the ACK or response message does not include
   the request originator's peer-info object.  The rationale is that the
   request originator's peer-info has already been seen by the peers
   along the request path and its inclusion in the response or an ACK



Baset, et al.             Expires May 22, 2008                 [Page 35]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   gives no further information.

   If the message originator requested a route log, then peers along the
   message path MUST add their peer-info objects after the peer-info
   objects in the received message.

4.5.  Enrollment and Authentication

   This section describes secure enrollment and authentication in a
   P2PSIP network using PKCS#10 on top of TLS and an optional HTTP
   digest mechanism.  The secure enrollment assumes the existence of a
   Registration Authority (RA) and Certificate Authority (CA).  The
   functions of RA and CA can be implemented in separate network
   entities, however for simplicity assume we that they are collocated
   in one entity called an enrollment and authentication (E&A) server.

   To enroll in an overlay, a user chooses an identifier and a password.
   The user identifier can be an email address, a SIP AoR, or any
   appropriate blob.  The node then generates a public/private key pair
   and embeds the user and node identifier in the distinguished name of
   a certificate signing request (CSR).  The node must store the private
   key as securely as possible.  The CSR is encoded using PKCS#10
   [REF:].  The node then establishes a TLS connection with the server
   (without client certificate authentication) and sends the CSR with
   H(password) to the enrollment and authentication server (E&A) in an
   enroll request.

   If the request is authenticated, the server creates a random or a
   static peer-ID and embeds it in a DER encoded X.509 certificate along
   with the user identifier.  It then sends this X.509 certificate
   containing user-ID, peer-Id and the expiration time in a 200 (Ok)
   response to the peer that sent the enroll request.  If a bootstrap
   server is co-located with the E&A server, the 200 response includes a
   P2P-Options TLV and a list of bootstrap peers.

   One reason for the server to choose a peer-ID for the peer instead of
   the peer randomly generating its peer-ID is that a joining peer is
   unaware of the hash algorithm being used.  The other reason is that
   it prevents a node from selecting a peer-ID or set of peer-IDs that
   it may use occupy a certain position in a structured overlay.  In a
   mobility based deployment of P2PP, the server may assign the same
   peer-ID to the peer during its subsequent runs to minimize the effect
   of churn.

   A node which is already enrolled does not generate a new public /
   private key pair.  Instead, it uses its existing public key and
   user-ID to generate a CSR and sends it along with a H(password) to
   the E&A server in an authenticate request.  (TODO: certificate reuse



Baset, et al.             Expires May 22, 2008                 [Page 36]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   before expiry)

   The enrollment and authentication mechanism is separate from the
   bootstrap mechanism because overlay may be formed in a non-secure
   environment.  The E&A and bootstrap servers may be co-located.  This
   is useful in a small network scenario.

   A first peer in the overlay or any peer can also act as an E&A
   server.

   The separation of user-ID and peer-ID allows multiple devices
   representing the same user to participate in the overlay.  An
   structured overlay implementer may use peer-ID=H(user-ID), which
   would mean that a node publishing the user-info object is the one
   responsible for it.

4.5.1.  HTTP Digest Authentication

   TODO: draw figure.

   The message flow describes enrollment process in P2PSIP including the
   certificate request originated by a P2PSIP node using PKCS#10 with
   HTTP Digest on top of TLS.  The flow starts with a P2PSIP node
   generating a public-private key pair.  Next the P2PSIP node
   establishes a TLS connection with an enrollment server.  It may
   registers its user-ID and password.  The user-ID is in the form of
   SIP URI: username@domain.  The registration of a user-ID and password
   can be separated from the enrollment process; however in this example
   we assume that both processes happen at the same time.

   Next the P2PSIP node sends a POST HTTP request to the enrollment
   server which generates an 403 Unauthorized response.  The response
   contains a WWW-Authenticate header which instructs the node to use
   HTTP Digest authentication.  The node creates a PKCS#10 request with
   the user-ID, public key, and optionally additional attributes and
   extensions.  It sends the PKCS#10 request in the HTTP request by
   calculating the Authorization header values using the username and
   password.

   When the enrollment server receives the request, it verifies the
   Authorization header using user name and password as specified in RFC
   2617 [X].  If the verification succeeds, the incoming PKCS#10 request
   is taken in for further processing.  After the PKCS#10 request has
   been processed and certificate(s) has been created, the enrolment
   server generates a HTTP response containing the certificate.  The
   enrolment server generates a single certificate that includes both
   the user-ID and a peer-ID.  When P2PSIP peer/client receives the
   certificate(s), it stores the certificate (or set of certificates) to



Baset, et al.             Expires May 22, 2008                 [Page 37]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   the local certificate management system.

   OPEN ISSUE: Is it more reasonable to include the user-ID and the
   peer-ID in a single certificate or to have separate certificates?

4.5.2.  Authentication without a Central Authority

   TBD.  Shared secret is one of the mechanisms.

4.6.  Bootstrap

   To join an overlay, a joining peer (JP) must determine the peer
   protocol that is being run in the overlay and must discover a peer
   that is already part of the overlay, thereafter called an admitting
   peer (AP).  The bootstrap process assumes that JP has already been
   enrolled and authenticated.

   There are different mechanisms to discover a node already in the
   overlay as specified by Matthews [21].  This specification defines
   one mechanism, namely, bootstrap node or server that a joining peer
   can use to discover a peer already in the overlay.  This mechanism
   assumes that the joining node already knows the IP address and port
   number of a bootstrap node or server.  The bootstrap node may or may
   not be part of the overlay and it may be co-located with the
   enrollment and authentication server.

   To discover the peers already in the overlay, a JP sends a bootstrap
   request to the bootstrap node or server.  The bootstrap node or
   server replies with its own peer-info object, the peer-info object of
   the peer that sent the bootstrap request along with its randomly
   generated peer-ID, a list of peer-info objects representing peers in
   the overlay, and a P2P-Options TLV.  The JP then sends the join
   request to one of the peers in the list.  If the list is empty, then
   the joining peer is the first peer in the overlay.

   A node sending the bootstrap request sets a 32-bit source-ID of
   0x00000000.  The bootstrap node sets a 32-bit response-ID of
   0x00000001 in its response, even if it is part of the overlay,
   because the peer sending the bootstrap request may not be aware of
   the overlay parameters.

   If a JP has obtained a list of bootstrap peers in response to
   authenticate request, it does not need to send a bootstrap request.

4.7.  Joining, Leaving






Baset, et al.             Expires May 22, 2008                 [Page 38]

Internet-Draft            Peer-to-Peer Protocol            November 2007


4.7.1.  Join

   A JP discovers the overlay protocol and existing peer in the overlay
   using the bootstrap mechanism described in Section 4.6.  It then
   sends a join request to the peer in the overlay.  The overlay nodes
   are connected in a graph and conceptually, a JP adds a new vertex to
   this graph.  Thus, the join process should correctly inform the JP's
   immediate neighbor peer(s) and take ownership of any resource-objects
   from them.  Overall, the join operation involves the following steps:

   1.  Determine its reachable address.

   2.  Discover the peer(s) where the node will join.

   3.  Inform the discovered peer(s) about itself.

   4.  Build routing and neighbor tables (if any).

   5.  Get ownership of any resource-objects.

   6.  Publish user-info, the reachable address for the user.

   A JP searches for an appropriate STUN and TURN server in the overlay.
   The criteria for searching a STUN and/or a TURN server depends on the
   overlay implementer.  After searching for the appropriate server, a
   JP determines its host, server-reflexive, and relay addresses.

   The JP MAY request the join request to be forwarded in a recursive
   (R=1) or an iterative manner (R=0).  It does so by setting the
   appropriate value of R flag in the common header.  A peer receiving
   the join request with the recursive routing flag set forwards it to
   the peer where JP will join.  A peer receiving the join request with
   iterative routing flag set replies with a 302 (Next Hop) response if
   the JP will not be its immediate neighbor.

   If a peer receiving the request determines that the JP 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 JP should send a keepalive message.  The response may also
   contain a copy of the neighbor table of the peer.

   Once the JP 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 the peers in the received neighbor
   table.  The join request with S flag set indicates the overlay peers
   that the JP will be their new neighbor.  It is up to the peer
   generating the 200 (Ok) response to decide, based on the p2p
   algorithm being used, which neighbors (successors, predecessors) a



Baset, et al.             Expires May 22, 2008                 [Page 39]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   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.  If the structured
   peer protocol does not require a neighbor table, then the join
   request with S flag is not sent.

   A JP MAY request to receive a copy of routing and neighbor tables of
   the peers that receive the join request.  It does so by following the
   rules defined in Section 4.3.

   Finally, a JP publishes the user-info object in the overlay as
   described in Section 4.8.1.  The user-info object contains the X.509
   certificate, and the host, server-reflexive, and relay addresses of
   the peer.  The successful response contains an Expires header.  A
   node keeps track of the resource-objects and their expire times in a
   'Publish Table' (Section 4.1).  A JP should resend a publish request
   with the user-info object before the passage of time in Expires
   header.

   Once, the JP has successfully joined the overlay, its neighbor peers
   transfer it the ownership of appropriate resource-objects, using a
   Transfer request.  The JP may also establish secure connections with
   its routing or neighbor peers.

4.7.1.1.  Rejecting or Deferring a Join Request

   Peers in the overlay may decide to reject a join request with a 406
   (Request Rejected) response because it does not satisfy the overlay
   policy for peers.  NAT and node resources are examples of such
   policies.  This specification does not specify any policy for peer
   admission and defers this decision to the overlay operator.

   Peer(s) in the overlay may not be willing to admit a JP 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
   reissue the join request.  The JP receiving this response should join
   as a client in the overlay.  It should reissue the join request
   without setting the peer flag in the common header.

   After the passage of time in Expires header, a client may attempt to
   insert itself again as a peer in the overlay.  The AP or other peers
   may explicitly invite the client to join the overlay before the
   passage of time in the Expires field by sending an Invite request.

4.7.1.2.  Client Join

   A client enrolls and authenticates itself and discovers a peer
   already in the overlay using mechanisms defined in Section 4.5 and



Baset, et al.             Expires May 22, 2008                 [Page 40]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Section 4.6, respectively.  It gathers its reachable addresses
   (Section 4.7.1.3) and sends a join request without setting the peer
   flag in the common header.  The peer receiving the join request may
   immediately reply with a 200 (Ok) request if it can support a new
   client.  It is up to the overlay implementer to decide how many
   clients may connect to a peer.  If a AP determines that it already
   has a certain number of clients, it replies with a 302 (Redirect)
   response containing a list of peers to which a client may send the
   join request.

   After receiving a 200 response to its join request, the client
   publishes its user-info as a resource-object object in the overlay.
   The resource-object types are defined in Section 13.  If the
   resource-object insertion is successful, the AP sends a 200 (Ok)
   response to the client and includes an Expires header.  The client
   then establishes a TCP connection with the AP and periodically send
   it a keepalive.  It sends all subsequent requests to its connected
   peer.

4.7.1.3.  NAT traversal

   A peer receiving a join request MUST include a resource-list object
   in its response indicating whether it is acting as a STUN or a TURN
   server.  A peer may then gather its ICE candidates.

   The recommended operation mode is that each peer acts as a STUN or
   TURN server.

4.7.2.  Leave

   A peer sends a Leave indication to gracefully inform its routing or
   neighbor peers about its departure.  It includes in the leave message
   a list of resource-objects the neighbor nodes should take over.  The
   peers receiving a leave message must update their routing or neighbor
   tables appropriately.

   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 client MAY also send a leave message to inform its peer(s) about
   its impending departure.

   (Open Issue: The user should not have to wait for the p2p application
   to shut down.  The p2p application is waiting for the receipt of
   Leave ACK.)





Baset, et al.             Expires May 22, 2008                 [Page 41]

Internet-Draft            Peer-to-Peer Protocol            November 2007


4.8.  Publish, LookupObject, LookupPeer

4.8.1.  Publish

   A node sends a publish request to a peer already in the overlay to
   publish a new resource-object or update an existing resource-object.
   A node typically sends a publish request in response to a usage layer
   API call.  The resource-object have a content-type and a sub-type;
   the commonly used types are User-Info, STUN, TURN, and STUN+TURN.
   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 publisher of the resource-object MUST also include information
   about its owner in the publish request because it may not necessarily
   be the owner of the resource-object.  It is possible for multiple
   owners to publish or update an existing resource-object, as a peer
   may be interested in retrieving the resource-object published or
   updated by a certain owner.

   Additionally, a publisher must ensure that the integrity of the
   resource-object is preserved.  It computes a digital signature over
   the whole resource-object, and includes the Signature object and its
   X.509 certificate as a sub-TLV of the resource-object.  The signature
   is encoded using PKCS#7.

   The format of the Owner TLV is left to the overlay implementer.  It
   can be a user-ID or a peer-ID.  (TODO: can we leave it to the overlay
   implementer?)

   A peer generating a 200 (Ok) response to a Publish request MUST
   include an Expires header.  The publisher of the resource-object MUST
   reissue the Publish request before the passage of time in Expires.

   A peer storing the resource-object MUST store the object signature
   and X.509 certificate of the resource publisher.

4.8.2.  LookupObject

   A node issues a LookupObject request to retrieve a resource-object
   from the overlay.  It sets the content-type, sub-type, and
   resource-ID fields in the Rlookup TLV.  Additionally, it may set the
   owner field in RLookup TLV.

   A peer receiving the LookupObject request must include in its 200
   response the certificate of the object publisher.  If multiple owners
   had published data under the resource-ID being searched, and if the
   owner is not specified, the peer storing the resource-object includes



Baset, et al.             Expires May 22, 2008                 [Page 42]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   all objects in its response.

   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 query originator, on
   receiving this response, reissues the LookupObject request over TCP
   to the peer responsible for the resource-object.

   The peer generating a 200 response for a LookupObject request MUST
   include the X.509 certificate of the publisher in its response.

4.8.3.  LookupPeer

   A peer issues a LookupPeer request to discover another peer in the
   overlay.  For example, in Bamboo [22], a peer uses global tuning and
   local tuning to update its routing table.  In these methods, a peer
   issues a lookup on an identifier which has L digits in common with
   peer-ID but differs in the (L+1)st digit (global tuning), or
   periodically contacts a random member of its routing table and
   requests all members at a certain level (local tuning).  To
   accomplish this, a peer can issue a LookupPeer request.  (TODO:
   reword)

   A peer can issue a LookupPeer request to locate a single peer,
   multiple peers or range of peers.  The 'Num' field controls the
   maximum number of peer-info objects returned in the response.

4.9.  Maintenance

   A peer performs various maintenance operations to maintain links with
   other peers in the overlay.  The maintenance operations use the
   messages provided by P2PP to maintain links with other peers in the
   overlay.  This involves the following two operations:

   1.  KeepAlive to neighbor and routing peers after the expiry of KAT
       timer.

   2.  Periodic update of neighbor and routing tables after the expiry
       of RMT and NMT timer.

   A client sends a periodic keepalive to its peer to maintain its link
   with the peer.

   P2PP provides three messages namely, KeepAlive, ExchangeTable, and
   LookupPeer for overlay maintenance.  KeepAlive is used to determine
   the liveness of the destination peer; ExchangeTable is used to obtain
   the routing and/or neighbor table of the peer; and LookupPeer is used
   to search for a specific peer to fill a routing-table entry.  The



Baset, et al.             Expires May 22, 2008                 [Page 43]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   transmission of these requests is governed by timers in
   Section 4.9.1.  Additionally, a receipt of a message from a neighbor
   or routing peer results in updating its keepalive timer.  It is up to
   the overlay implementer to adjust the values of these timers.

   The maintenance algorithms are DHT specific and are specified in a
   separate draft (TODO).  However, the messages to accomplish
   maintenance operations are defined in this draft.

4.9.1.  Node Timers

   This section defines node-specific timers for overlay maintenance and
   ExchangeTable requests.  The timer values are only provided as a
   reference.  The overlay implementer is free to choose a suitable
   value depending on the system requirements.

   Timer   Value    Description
   ---------------------------------
   KAT      10s     KeepAlive timer
   RMT      30s     Routing-table maintenance timer
   NMT      30s     Neighbor-table maintenance timer
   RT       30s     Replication management timer
   RRT      Var.    Resource refresh timer
   RA       10s     Start of range-time for message transmission
   RB       30s     End of range-time for message transmission

   (TODO: a separate draft for overlay maintenance operations)

4.10.  Replication

   The replication mechanism describes how resource-objects are
   replicated in the overlay.  It is necessary to replicate resource-
   objects in the overlay to maintain their availability during churn.
   Resource-objects can be replicated by the publisher or by the node at
   which they are stored.  The number of replicas depends on the
   availability requirements.

   Either the node which publishes the resource or the node at which the
   resource-object is stored can initiate replication.  P2PP provides a
   replicate request to replicate a group of resource-objects.

   The replication process is triggered after the expiry of RT
   (replication management timer).  If there has not been any change in
   the routing or neighbor table of a peer, there is no need to
   replicate.






Baset, et al.             Expires May 22, 2008                 [Page 44]

Internet-Draft            Peer-to-Peer Protocol            November 2007


4.11.  Capabilities and Diagnostics

   (TODO: This section needs to be elaborated.)

   P2PP provides a mechanism to allow nodes with heterogeneous
   capabilities to exchange their capabilities and their current
   resource utilization.  Nodes exchange their resource-utilization and
   their capabilities during maintenance and at join.  Nodes should
   exchange capabilities when establishing communication for the first
   time.  The capabilities and diagnostic information is included as
   part of Peer-Info object.

   P2PP provides a GetDiagnostic request message.  Peers can use this
   message to send their current capabilities and diagnostic information
   to another peer or a central server.  This is useful for debugging
   purposes.

   Peers can use Query request (Section 8.9 to explicitly request the
   capabilities of another peer.
































Baset, et al.             Expires May 22, 2008                 [Page 45]

Internet-Draft            Peer-to-Peer Protocol            November 2007


5.  P2PP Processing

5.1.  Resources and Services

   The resource-object represents the resources a node is responsible
   for or the services it may provide.  A resource-object has a type, a
   sub-type, a resource-ID, and a value.  It has additional attributes,
   namely, owner, expires, signature, peer-info, and X.509 certificate.
   The type and sub-type identify the type of resource-object that is
   being published or searched.  The resource-ID represents a searchable
   identifier for a resource or a service and is qualified by the type
   and sub-type fields.  It is possible for different resource-objects
   and services to have the same resource-ID (representing a
   discoverable identifier), but a different type and sub-type.  Thus,
   type and sub-type represent a unique namespace in the system.  The
   peer-info represents the publisher of the resource-object.

   It is possible for a peer or a set of peers to provide the same
   service.  Many peers may be interested in using the service provided
   by different peers.  The protocol should provide a mechanism for
   peers to publish their service information, to discover the peers
   providing the same service and to judiciously balance the load on the
   service peers.  We discuss four different ways in which a peer can
   advertise their service information for appropriate discovery by
   interested peers.

   Standard Service Name: All peers use a standard service name to
   advertise the same service.  The standard service name represents a
   discoverable identifier and is published in resource-ID field of the
   resource-object.  In structured networks such as DHTs, keys are
   stored against identifiers.  If a standard service name was used, it
   will always hash to a particular value.  The information about all
   peers providing the same service will be stored at a peer with an
   identifier closest to the hash value of a service name.  A peer which
   happens to have a peer-ID that is closest in the DHT sense to the
   hash of the service name will end up storing information about all
   peers providing this service, and will need to replicate it to
   neighbor peers for availability.  In a large system where hundreds or
   thousands of peers may provide the same service, this scheme
   overburdens the storage and bandwidth capacity of the peer
   responsible for this information.

   ReDiR: ReDiR is a mechanism proposed by OpenDHT [10] that addresses
   the issues discussed above.  ReDiR proposes to build a two-
   dimensional quad-tree of the nodes that have joined under a key and
   embeds them in the DHT using Publish/LookupObject interface.  Using
   this tree, ReDiR performs lookup in logarithmic number of operations
   and based on past lookups, it can reduce the average lookup to a



Baset, et al.             Expires May 22, 2008                 [Page 46]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   constant number of operations.  To publish its service advertisement,
   a node picks a random level l, and computes a hash of service name
   and l H(service_name,l).  If node(s) providing the service exist at
   this level, it recomputes H(service_name,l+1) and searches for the
   next level.  It then publishes its service information at the next
   available level.

   Random Id: Another mechanism to prevent service advertisement and
   lookup requests always going to a certain peer is to pick k random
   identifiers and publish the service advertisement under those random
   identifiers.  A node searching for a peer providing a certain service
   picks up a random identifier and searches it in the overlay for
   corresponding service name.  The idea is that it will likely hit upon
   a node which provides this service if a sufficient number of
   advertisements were published in the overlay.

   Random Walk and Learning: One option is not to explicitly publish
   information about the nodes providing the service and instead spread
   this information implicitly.  A node must have a routing table and
   may have a neighbor table.  The routing and neighbor peers of a node
   inform it about the list of services they are providing in a
   Resource-List TLV.  Since a node's routing table may contain few
   hundred (realistic?) entries, it is possible that some of them may
   provide the service.  A node searching for a peer providing certain
   service performs a random walk over its routing or neighbor peers
   till it finds an appropriate peer.

   Note that the first three schemes are geared towards DHTs while the
   last scheme is applicable to unstructured networks.  The resource
   (service) publishing and discovery uses the APIs provided the
   underlying peer protocol and is not tied to the underlying peer
   protocol.  The peers can also learn about the nodes providing a
   certain service as a side effect of other messages received.  This is
   exactly what random walk and learning scheme achieves.

5.2.  NAT Traversal

   The easiest and simplest way solve NAT traversal issues in a global
   deployment is to only allow nodes with unrestricted network
   connectivity to become peers.  In such a scenario, all peers act as
   STUN and TURN servers.  This is however not realistic on the Internet
   as is or applicable for P2PSIP providers that cannot afford large
   numbers of public peers required to support large overlays.  Thus,
   P2PP allows peers behind NATs to participate in the overlay.

   The following issues are related to NAT traversal.





Baset, et al.             Expires May 22, 2008                 [Page 47]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   1.  Publishing and discovery of NAT traversal service in the overlay.

   2.  Gathering of candidates and NAT behavior discovery.

   3.  Communicating with a peer behind a NAT.

   4.  Maintenance of NAT bindings.

   5.  Load balancing

5.2.1.  NAT Traversal Service Advertisement and Discovery

   P2PP allows peers to provide NAT traversal service.  Peers providing
   such a service publish this information in the overlay may use one of
   the four mechanism described in Section 5.1.  Additionally, for
   structured overlays, peers may use hash of the autonomous system
   number of their host or server-reflexive IP address as a resource-ID.

   It is possible for peers at various NAT levels to offer STUN and TURN
   service.  Peers behind p2p-friendly NATs may also provide STUN and
   TURN service [25].

5.2.2.  Gathering of Candidates and NAT Behavior Discovery

   At join, a JP searches for an appropriate peer providing STUN or TURN
   server in the overlay using LookupObject request.  It then gathers
   its host, server-reflexive, and relay candidates using the discovered
   peers.  Note that the relay candidate is used for relaying P2PP
   messages.  A JP may also use NAT behavior discovery mechanisms
   defined in [24] to discover the type of NAT it is behind.  A JP may
   use this information to determine if it should join as a peer or a
   client (although this is not recommended by [24].  Alternatively, the
   AP (admitting peer) decides based on the gathered candidates whether
   JP satisfies the overlay implementer guidelines for a peer.

   It is impossible to determine uptime guarantees for a peer providing
   a STUN or TURN service.  A peer should keep a list of peers providing
   STUN or TURN service and may maintain and advertise more than one
   server-reflexive and relay candidates.

5.2.3.  Communicating with a Peer Behind a NAT

   The choice of recursive or iterative routing has an impact on the
   mechanisms to communicate peers behind a NAT.  If a all nodes in the
   overlay use recursive routing, then under low churn they only need to
   communicate with their routing and neighbor peers.  The nodes behind
   NATs can form a communication channel with their routing and neighbor
   peers by exchanging their gathered candidates in a Connect request



Baset, et al.             Expires May 22, 2008                 [Page 48]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   and response.

   The situation changes when the overlay has moderate or heavy churn or
   uses iterative routing.  During these circumstances, a peer behind a
   NAT may need to communicate with other peers only once; and it may
   never subsequently communicate with them.  Since these peers have
   published their host, server-reflexive, and relay candidates in the
   overlay, a peer intending to communicate with them simply sends a
   copy of the message to these addresses.

5.2.4.  Maintenance of NAT Bindings

   A peer sends the STUN Binding request to maintain NAT bindings.

5.2.5.  Load Balancing for Media Flows

5.2.6.  ICE Overhead

   ICE is geared towards establishing long-lived sessions.  In a typical
   ICE usage scenario, a peer planning to establish communication with
   other peers gathers its address candidates and sends them in an offer
   to the remote peer.  The assumption is that a peer is unaware of the
   address candidates of the remote peer and they must exchange this
   information and discover the address candidates best suitable for
   subsequent exchange.

   In P2PP, peers gather their address candidates at join and publish
   them in the overlay.  Further, a node will have all the address
   candidates for peers in its routing table or neighbor table.  When a
   user-info object is published, all the address-candidates are also
   published along with it.  Thus, when a user-info object is retrieved
   or a peer-info object is in returned in a 302 response, they will
   contain all the address candidates of the peer.  A peer forwarding
   requests in an iterative manner can simply send copies of the message
   to all the address candidates of the peer.  If subsequent
   communication is desired, then the address candidates be
   appropriately pruned.

   TODO: Discuss below.

   Encoding overhead: User and password, foundation and component-id
   size.  P2PP ICE encoding removed user password, and reduced
   foundation and comp-id size.

   TURN message exchange overhead: Allocate an address and then create
   permissions in a separate message.





Baset, et al.             Expires May 22, 2008                 [Page 49]

Internet-Draft            Peer-to-Peer Protocol            November 2007


5.3.  Route Log

   TODO: Only needed for recursive routing.

5.4.  P2PP and SIP

   SIP [2] messages to peers with restricted connectivity are tunneled
   through peers with unrestricted connectivity.  The SIP message is
   encapsulated in a resource-object and is sent to the peer responsible
   for the node with restricted connectivity.









































Baset, et al.             Expires May 22, 2008                 [Page 50]

Internet-Draft            Peer-to-Peer Protocol            November 2007


6.  Transport Layer

   This section defines mechanisms for reliably delivering a message to
   the next hop.  For requests, a transaction constitutes of a single
   request followed by acknowledgements (if any), and a response.  For
   responses, reponseACKs, and indications, a transaction consists of
   single response, responseACK, or indication, followed by an ACK if
   unreliable transport is used.  Section 3.4 and Section 3.5 discussed
   the need for acknowledgements and responseACKs.

6.1.  Transaction Identifier

   A transaction is identified by a source-ID, transaction-ID tuple, and
   a transaction-type triple.  This is used to match acknowledgements
   (ACK) to requests, responses and indications.  However, the responses
   and responseACKs are matched to requests using only source-ID and
   transaction-ID tuple.  A transaction can be of four types, namely,
   request, response, responseACK, or an indication.  The source-ID,
   transaction-ID, and transaction-type must be preserved in the ACKs.
   Each request or indication has a locally unique 32-bit
   transaction-ID.

6.2.  Message State Machine

   This section defines state machine for unreliable and unreliable
   transports.

6.2.1.  State Machine for Unreliable Transports

   For unreliable transports, the transaction state machine for requests
   is shown in Figure 8 whereas state machine for responses and
   indications is shown in Figure 9.

   The "Trans_Msg" (abbreviation for transmit message) state is entered
   when a peer sends a request, response, responseACK, or an indication.
   When entering this state, the transaction should set timer T1 and T2.
   Timer T1 governs retransmissions and is updated after ith
   retransmission as follows: T1=2^i*T0.  If timer T2 fires, the state
   machine transitions to "Failed" state and is terminated.

   If a request was sent and an acknowledgement was received, the state
   machine transitions to "Wait_Resp" state.  When entering this state,
   the transaction should set timer T3.  If timer T3 fires, the state
   machine transitions to "Failed" state and is terminated.  If a
   responseACK was received, the transaction sends an ACK and is
   terminated.

   If a response, responseACK, or an indication was sent and ACK was



Baset, et al.             Expires May 22, 2008                 [Page 51]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   received, the state-machine immediately transitions to the
   "Terminated" state.


                         +-----------+
                         |           |
                         |  Initial  |
                         |           |
                         +-----------+
                               |
                               | tx_Msg / set Timer T1 and T2
   Timer T1 fires  /           |
    T1=2^i*T0                  V              Transport Err. or
     tx_Msg              +------------+       Timer T2 fires
                  +------|            |       Inform App.
                  |      | Trans_Msg  |----------------->+
                  +----->|            |                  |
                         +------------+                  |
                           |   | ACK received /          |
    +----------------------+   | set Timer T3            |
    |                          | stop Timer T1, T2       |
    |                          V                         |
    |                    +-----------+ Transport Err.    |
    | responseACK rcvd / |           | or Timer T3 fires |
    | stop Timer T1, T2  | Wait_Resp |------------------>|
    | send ACK           |           |                   |
    |                    +-----------+                   |
    |                          |                         |
    |                          | Resp received /         |
    |                          | send ACK                |
    |                          V                         |
    |                    +------------+                  |
    |                    |            |                  |
    +------------------->| Terminated |                  |
                         |            |                  |
                         +------------+                  |
                                                         |
                         +-----------+                   |
                         |           |                   |
                         |  Failure  |<------------------+
                         |           |
                         +-----------+

   Figure 8: Transaction state machine for requests for unreliable
   transport






Baset, et al.             Expires May 22, 2008                 [Page 52]

Internet-Draft            Peer-to-Peer Protocol            November 2007


                         +-----------+
                         |           |
                         |  Initial  |
                         |           |
                         +-----------+
                               |
                               | tx_Msg / set Timer T1 and T2
   Timer T1 fires  /           |
    T1=2^i*T0                  V              Transport Err. or
     tx_Msg              +------------+       Timer T2 fires
                  +------|            |       Inform App.
                  |      | Trans_Msg  |----------------->+
                  +----->|            |                  |
                         +------------+                  |
                               |                         |
                               | ACK received            |
                               | stop Timer T1, T2       |
                               V                         |
                         +------------+                  |
                         |            |                  |
                         | Terminated |----------------->|
                         |            |                  |
                         +------------+                  |
                                                         |
                         +-----------+                   |
                         |           |                   |
                         |  Failure  |<------------------+
                         |           |
                         +-----------+

   Figure 9: Transaction state machine for responses and indications for
   unreliable transport

6.2.2.  State Machine for Reliable Transports

   For reliable transports, the transaction state machine for requests
   is shown in Figure 10; the state machine for responses and
   indications is shown in Figure 11.

   The "Trans_Msg" state is entered, when a peer issues or forwards the
   request, response, or an indication.  If the message was a response
   or an indication and was successfully sent, the state machine
   transitions to "Terminated" state.  If the message was a request and
   was successfully sent, the transaction sets Timer T3 and transitions
   to "Wait_Resp" state.  If a response is received, the transaction is
   terminated.  No ACK is sent for requests, responses, and indications
   sent over reliable transport.  Similarly, no responseACK is generated
   for a request.



Baset, et al.             Expires May 22, 2008                 [Page 53]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   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 application MAY terminate
   the reliable transport connection if it does not anticipate its
   reuse.


                         +-----------+
                         |           |
                         |  Initial  |
                         |           |
                         +-----------+
                               |
                               | tx_Msg
                               |
                               V
                         +------------+       Transport Err.
                         |            |       Inform App.
                         | Trans_Msg  |----------------->+
                         |            |                  |
                         +------------+                  |
                               | Msg successfully sent / |
                               | set Timer T3            |
                               |                         |
                               V                         |
                         +-----------+ Transport Err.    |
                         |           | or Timer T3 fires |
                         | Wait_Resp |------------------>|
                         |           |                   |
                         +-----------+                   |
                               |                         |
                               | Resp received           |
                               |                         |
                               V                         |
                         +------------+                  |
                         |            |                  |
                         | Terminated |                  |
                         |            |                  |
                         +------------+                  |
                                                         |
                         +-----------+                   |
                         |           |                   |
                         |  Failure  |<------------------+
                         |           |
                         +-----------+

   Figure 10: Transaction state machine for requests for a reliable
   transport



Baset, et al.             Expires May 22, 2008                 [Page 54]

Internet-Draft            Peer-to-Peer Protocol            November 2007


                         +-----------+
                         |           |
                         |  Initial  |
                         |           |
                         +-----------+
                               |
                               | tx_Msg
                               |
                               V
                         +------------+       Transport Err.
                         |            |       Inform App.
                         | Trans_Msg  |---------------+
                         |            |               |
                         +------------+               |
                               |                      |
                               | Msg successfully sent|
                               V                      |
                         +------------+               |
                         |            |               |
                         | Terminated |               |
                         |            |               |
                         +------------+               |
                                                      |
                                                      |
                         +-----------+                |
                         |           |                |
                         |  Failure  |<---------------+
                         |           |
                         +-----------+

   Figure 11: Transaction state machine for responses and indications
   for a reliable transport

6.3.  Timers

   This section defines timers for message state machines.


   Timer    Value
   ----------------------
   T0       500 ms
   T1       T0
   T2       5s
   T3       5s







Baset, et al.             Expires May 22, 2008                 [Page 55]

Internet-Draft            Peer-to-Peer Protocol            November 2007


7.  Security Considerations

7.1.  Routing Security

7.1.1.  Peer-ID Assignment

   In P2PP, user-IDs and peer-IDs are assigned in a centralized and
   secure manner.  This provides protection against Sybil attacks [23].
   The user-IDs are typically chosen by a user at the time of enrollment
   and peer-IDs are chosen in a manner which preserves their uniqueness
   across different network environments such as NAT.  During enrollment
   and/or authentication, a node sends its peer-ID and user-ID in a DER
   encoded certificate signing request (CSR) to a central trusted
   authority, typically the entity providing overlay software.  If
   approved, the CA responds with a DER encoded X.509 signed
   certificate, which binds the public key of the node to the user-ID
   and peer-ID.  Peers and clients must enroll themselves before
   participating in the overlay.  Section 4.5 discusses the enrollment
   process.

   There are circumstances in which a central trusted authority may not
   be available or has a significant establishment overhead.  The
   examples are overlays setup for a meeting or in a small office
   environment.  One of the peers, typically the first peer in the
   overlay, may act as a central authority.  Additionally, self-signed
   certificates may be used.  (TODO: Can we deprecate this mechanism?)

7.1.2.  Message Forwarding and Message Integrity

   P2PP provides protection against routing threats (2)-(4) by sending
   and forwarding messages over secure and [un]reliable transports,
   namely, DTLS or TLS.  Message integrity is also provided by these
   transports.  P2PP provides protection against (4) by only a hash
   identifier of a user-ID in its certificate or messages.

7.1.3.  Routing and Neighbor Table Management

   Despite secure ID assignment and message forwarding, the peers can be
   compromised in an overlay.  An attacker with a secure ID performing
   secure forwarding can poison the routing and neighbor tables of non-
   faulty nodes.  (TODO: Use schemes in various p2p security papers.  Is
   there a need to standardize it?)

7.1.4.  Admission Control

   TBD.





Baset, et al.             Expires May 22, 2008                 [Page 56]

Internet-Draft            Peer-to-Peer Protocol            November 2007


7.1.5.  Residual Attacks

   TBD.

7.2.  Storage Security

7.2.1.  Integrity

   P2PP provides protection against storage integrity threats by
   mandating peers to digitally sign a message in a PKCS#7 format (TODO:
   evaluate its overhead.)  Peers store their X.509 certificates with
   the stored data which allows nodes searching for the stored data to
   verify its integrity.

7.2.2.  Permissions

   TODO

7.2.3.  Quota

   TODO

7.2.4.  Residual Attacks

   TODO


























Baset, et al.             Expires May 22, 2008                 [Page 57]

Internet-Draft            Peer-to-Peer Protocol            November 2007


8.  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].

   P2PP defines eighteen messages as shown below.  The messages are
   grouped together by related functions they perform.

   P2PP-Msg = Enroll / Authenticate / Bootstrap /
              Join / Leave / KeepAlive /
              LookupPeer / ExchangeTable / Query
              Replicate / Transfer /
              Publish / LookupObject / RemoveObject /
              Tunnel / Connect
              Invite /
              GetDiagnostics

8.1.  Enroll

   Enrolls the user in the overlay.


   Enroll = Common-header
            [Request-Options]
            Peer-Info
            Certificate-Sign-Request
            Password


   Enroll (Resp) = Common Header
               Peer-Info
               X.509-Certificate
               [P2P-Options]
               [Peer-Info]*
               [Ext]

8.2.  Authenticate

   Authenticate the user and generates a certificate binding user-ID,
   peer or client ID, and public key of the peer.


   Authenticate = Common-header
            [Request-Options]
            Peer-Info
            Certificate-Sign-Request
            Password



Baset, et al.             Expires May 22, 2008                 [Page 58]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Authenticate (Resp) = Common Header
               Peer-Info
               X.509-Certificate
               [P2P-Options]
               [Peer-Info]*
               [Ext]

8.3.  Bootstrap

   A request sent by a peer or a client to a bootstrap server or peer to
   discover the IP address of a peer already in the overlay.


   Bootstrap = Common-header
             Peer-Info


   Bootstrap (Resp) = Common Header
               Peer-Info (bootstrap peer)
               Peer-Info (request originator)
               P2P-Options
               [Peer-Info]*
               [Ext]

   P2P-options = Hash-algorithm
              Hash-algorithm-length
              DHT-algorithm
              OverlayID-length
              Overlay-ID

8.4.  Join

   A request sent by a peer to join the overlay.  The join request sent
   by a client is not forwarded to other peers.


   Join = Common-header
        [Request-Options]
        Peer-Info












Baset, et al.             Expires May 22, 2008                 [Page 59]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Join (Resp) = Common Header
               Peer-Info
               [Peer-Info]*
               [Expires]
               [Routing-Table]
               [Neighbor-Table]
               [Ext]

   Routing-table = Num-entries
                 [Peer-Info]*

   Neighbor-peers = Num-entries
                  [Peer-Info]*

8.5.  Leave

   Peers send the leave indication to their routing and peers indicating
   their departure.  Clients periodically send the leave message to
   their respective peers.

   Leave = Common-header
         Peer-Info
         [Peer-Info]*
         [Resource-object]*

8.6.  KeepAlive

   Peers periodically send a keepalive indication to their routing and
   neighbor peers to check whether they are alive.  Clients send a
   keepalive to their peers to check whether they are alive.

   KeepAlive = Common-header
              Peer-Info
              Expires


   KeepAlive (Resp) = Common-header
                     Peer-Info
                     Expires

8.7.  LookupPeer

   Peers send this request to discover a peer that may fill or update a
   missing entry in their routing or neighbor table.

   LookupPeer = Common-Header
              [Request-Options]
              Peer-Info



Baset, et al.             Expires May 22, 2008                 [Page 60]

Internet-Draft            Peer-to-Peer Protocol            November 2007


              PLookup


   LookupPeer (resp) = Common-Header
                     Peer-Info
                     [Peer-Info]*
                     [Ext]

8.8.  ExchangeTable

   Peers periodically send this request to their routing and neighbor
   peers obtain their routing and neighbor tables.

   ExchangeTable = Common-Header
                 Peer-Info
                 Request-Options


   ExchangeTable (resp) = Common-Header
                        Peer-Info
                        [Routing-table]
                        [Neighbor-peers]
                        [Ext]

8.9.  Query

   Query a peer or a client to discover the services they provide or the
   resource-objects they store.

   Query = Common-Header
         Peer-Info


   Query (resp) = Common-Header
                Peer-Info
                [P2P-Options]
                [Resource-List]
                [Ext]

8.10.  Replicate

   Peers periodically send this request to replicate the resource-
   objects for availability.  The choice of peers on which to replicate
   the objects depends on the peer protocol.







Baset, et al.             Expires May 22, 2008                 [Page 61]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Replicate = Common-header
               Peer-Info
               [Resource-Object]*
               [Ext]

   Replicate (Resp) = Common-header
                    Peer-Info

8.11.  Transfer

   After a successful join or graceful or ungraceful failure of peers, a
   peer transfers the ownership of resource-objects using a transfer
   request.

   Transfer = Common-header
            Peer-Info
            [Resource-object]+
            [Ext]

   Transfer (Resp) = Common-header
                   Peer-Info

8.12.  PublishObject

   Publish a resource-object.  Also, used to refresh or update an
   existing resource-object.

   PublishObject = Common-header
           [Request-Options]
           Peer-Info
           Resource-Object


   Publish (Resp) = Common-header
            Peer-Info
            Expires

8.13.  LookupObject

   Search for a resource-object.

   LookupObject = Common-header
          [Request-Options]
          Peer-Info
          RLookup






Baset, et al.             Expires May 22, 2008                 [Page 62]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   LookupObject (resp) = Common-header
                 Peer-Info
                 Resource-Object

8.14.  RemoveObject

   Remove a resource-object.

   RemoveObject = Common-header
          [Request-Options]
          Peer-Info
          Resource-Object

   Remove (Resp) = Common-header
                 Peer-Info

8.15.  Tunnel

   Tunnel an application layer protocol message into a P2PP message.
   Mostly used for sending SIP messages to peers or clients behind a
   NAT.

   Tunnel = Common-header
          [Request-Options]
          Peer-Info
          Resource-Object

   Tunnel (Resp) = Common-header
                 Peer-Info

8.16.  Connect

   Send an ICE offer (TBD).

   Connect = Common-header
          [Request-Options]
          Peer-Info

   Connect (Resp) = Common-header
                 Peer-Info

8.17.  Invite

   Peers send an invite request to a client, inviting them to become a
   peer.






Baset, et al.             Expires May 22, 2008                 [Page 63]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Invite = Common-header
          Peer-Info

   Invite (Resp) = Common-header
                 Peer-Info














































Baset, et al.             Expires May 22, 2008                 [Page 64]

Internet-Draft            Peer-to-Peer Protocol            November 2007


9.  Packet Formats

   This section defines PDUs for the messages and their methods defined
   above.

9.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=2| T |A|P|R|    Reserved     | Request Type  |      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic Cookie                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Transaction-ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Source-ID                           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version (2 bits):  The protocol version number.  The current version
      is 1.

   T (2 bits):  Indicates the message type: (00) for a request, (01) for
      an indication, (10) for a response, (11) for a responsACK.

   A flag:  If set (A=1), the message is an acknowledgement for the
      request, response, responseACK, or an indication.  The A flag is
      never set for reliable transports.

   P flag:  If set (P=1), the message is sent by a peer.  Otherwise, a
      client sends the message.

   R flag:  If set (R=1), the request is sent in a recursive manner.
      Otherwise, it is sent in an iterative manner.  The flag is not set
      for responses or indications.

   Request or Indication Type (8 bits):  The request or indication
      message type such as join and leave.






Baset, et al.             Expires May 22, 2008                 [Page 65]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   TTL (8 bits):  A hop count for the number of peers this request can
      traverse.

   Magic cookie (32 bits):  A field with a fixed value (0x596ABF0D) to
      differentiate P2PP messages from other protocol messages such as
      STUN.

   Transaction-ID (32 bits):  A unique number to match responses with
      the originated requests.  Along with source-ID, it can uniquely
      identify a message in the system.

   Message Length (32 bits):  The byte length of the message after the
      common header itself.

   Source-ID (variable):  The Peer-ID of the peer of client sending the
      request.  For DHTs, it is the fixed length output of the hash
      function.  For unstructured networks, it is a fixed length
      identifier.  The length of this field is determined at Join.  For
      bootstrap and authenticate requests, its length is always four
      bytes.

   For responses, the rightmost 9-bits of the Reserved field contain the
   response code.  The response contains a destination-ID field, which
   is the peer-ID of the node generating the provisional or final
   response.

    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=2| T |A|P|R|  Response code  | Request Type  |      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic Cookie                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Transaction-ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Source-ID                           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        Response-ID                          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Peer-ID of the peer or client sending the response.  For DHTs,
      it is the fixed length output of the hash function.  For
      unstructured networks, it is a fixed length identifier.  The
      length of this field is determined during bootstrap.  For
      responses to bootstrap and authenticate requests, its length is
      always four bytes.



Baset, et al.             Expires May 22, 2008                 [Page 66]

Internet-Draft            Peer-to-Peer Protocol            November 2007


9.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Object-Type  |A|B| Reserved  |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                          Value                              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Object-Type (8 bits):  An IANA-assigned identifier for the type of
      the object.

   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.

   Length (16 bits):  The byte length of the object.

   The combination AB=10 and AB=11 are reserved.

9.3.  P2PP TLV Objects

9.3.1.  Peer-Info

   Type:  Peer-Info

   Length:  Variable (depends on the length of Peer-ID, IP version and
      unhashed key if any.  The Peer-Info MUST include an address-info
      object or a peer-ID.  It may also include additional objects such
      as unhashed-ID, uptime, neighbor/resource utilization, and expires
      which defines the keepalive interval.  The peer issuing the
      request may not include its peer-ID in the peer-Info object as it
      is already included in the common header.  However, peers in the
      request path must include their peer-ID as well as address-info
      objects.

   Peer-ID:







Baset, et al.             Expires May 22, 2008                 [Page 67]

Internet-Draft            Peer-to-Peer Protocol            November 2007


    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                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Peer-ID (variable):  It is an identifier of the node (client or peer)
      issuing or forwarding the request.  For DHTs, it is a fixed-length
      output of a hash function.  For unstructured networks, it is also
      a fixed-length identifier.

   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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Uptime (32 bits):  The uptime of this peer in number of seconds.

   Resource-List:

    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      |Resource-Type1 |Resource-Type2 |Resource-Type3 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Num (8 bits):  Number of resource-lists.

   Resource-Type (8 bits):  Same as Cont-Type in Resource-Info object.
      Typically, only included for the services such as STUN or TURN
      that the node is currently providing.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Num      |R|Resv.| IP-ver|   Foundation  | Component-ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Priority                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TT  |   HT  |           Port                | Peer address //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Baset, et al.             Expires May 22, 2008                 [Page 68]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Num (4 bits):  Number of ICE candidates.

   R flag:  If set, rel-addr and rel-port are included as defined in ICE
      [7].

   IP-Ver (4 bits):  The IP version number, 4 or 6.

   Foundation (8 bits):  The foundation field as defined by ICE.  Note
      that the length of this field is only 8-bits as compared to 64-
      bits as defined by ICE specification.

   Component-ID (8 bits):  The component-ID field as defined by ICE.

   Priority (32 bits):  The priority of the address obtained through
      ICE.

   TT (4 bits):  The transport type of the address.  One of UDP (0000),
      or TCP (0001).

   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).

   Port (16 bits):  The port on which this peer listens for requests.

   Peer Address (variable):  The IP address of the peer.  Its length
      depends on the IP-Ver field.

9.3.2.  Unhashed-Id

   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 a user, resource, or peer
      identifier. this peer.  This is only included in a DHT-based
      overlay.

9.3.3.  Request-Options








Baset, et al.             Expires May 22, 2008                 [Page 69]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P|R|N|E|A|S|L|                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 either in a response
      or in a separate ExchangeTable request.  The transmission of the
      routing-table copy is governed by the in-separate-request (E flag)
      and partial-copy (A flag) flags.

   N (1 bit) request-neighbor-table:  If set (N=1), send a copy of the
      neighbor table to the peer issuing the request in a response or
      ExchangeTable request.  The transmission of routing-table copy is
      governed by the in-separate-request and partial-copy flags.

   E (1 bit) in-separate-request:  If set (E=1), and if R or N are also
      set, the peer is requesting to receive routing or neighbor table
      in an ExchangeTable request.  If not set (E=0), and if R or N are
      also set, each peer along the request path can add a copy of its
      routing or neighbor table before forwarding the response.  The
      number of entries in all routing-tables should not exceed 256.
      Peers along the request path may remove routing-table entries
      added by a previous hop, if their own routing-tables have a better
      performance metric (such as uptime) than the ones received in the
      message.  The size of routing-table is likely to exceed UDP MTU.
      The specification recommends that the ExchangeTable request should
      always be sent over TCP.

   A (1 bit) partial-reply for routing or neighbor table:  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 ExchangeTable request.  The number of entries
      in all neighbor-tables should not exceed 256.






Baset, et al.             Expires May 22, 2008                 [Page 70]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   S (1 bit):  If set (S=1), the request is being sent to the immediate
      neighbors of the newly joining peer.  The request must be a join
      request.

   L (1 bit):  If set (L=1), each peer along the request must add its
      peer-info object that includes peer-ID, address-info, and
      resource-list objects.

9.3.4.  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Hash-Algorithm |H-Algorithm-Len| P2P-Algorithm |      Base     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OverlayID Len |           Overlay-ID                         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hash-Algorithm (8 bits):  An IANA-assigned identifier for the hash
      algorithm.

   H-Algorithm-Len (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.

   Base:  The base for hash algorithms.  It is set to zero for
      unstructured overlays.

   OverlayID-Length (8 bits):  The byte length of overlay-ID.

   Overlay-ID (variable):  Overlay-ID.

9.3.5.  Routing-Table

   Type:  Routing-Table

   Length:  Variable (depends on the number of Peer-Info objects)







Baset, et al.             Expires May 22, 2008                 [Page 71]

Internet-Draft            Peer-to-Peer Protocol            November 2007


    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 routing
      table.

   Peer-Info (variable):  One or more Peer-Info objects.

9.3.6.  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.

9.3.7.  PLookup

   Type:  PLookup

   Length:  Variable (depends on the length of Peer-ID and whether this
      is a range lookup)










Baset, et al.             Expires May 22, 2008                 [Page 72]

Internet-Draft            Peer-to-Peer Protocol            November 2007


    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    |E|R|              Peer-IDa                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                             Peer-IDb                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Num (6 bits):  Number of peers to look for.

   E (1 bit):  If set (E=1), then search for a peer whose peer-ID is the
      same as peer-IDa.  Otherwise, return up to Num peers whose ID is
      'closest' to Peer-IDa

   R (1 bit):  If set (R=1), then it is a range lookup.  It is only set,
      if E is not set.

   Peer-IDa (variable):  Peer-ID.  The length of Peer-ID is determined
      at join.

   Peer-IDb (variable):  Peer-ID.  The length of Peer-ID is determined
      at join.

9.3.8.  Resource-ID

   Resource-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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Resource-ID                         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Resource-ID (variable):  It is an identifier of the resource.  For
      DHTs, it is a fixed-length output of a hash function.  For
      unstructured networks, its length is variable.

9.3.9.  RLookup

   Type:  Resource-Object

   Length:  Variable (depends on the size of resource-object)









Baset, et al.             Expires May 22, 2008                 [Page 73]

Internet-Draft            Peer-to-Peer Protocol            November 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cont-type   |   Sub-Type    |         Resource-ID          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Additional Information                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Cont-type:  An IANA assigned identifier for the type of content
      contained in this resource-object.

   Sub-type:  An IANA assigned identifier which further classifies the
      content type as defined by cont-type.

   Resource-ID (variable):  The Resource-ID TLV of the resource object.

   Additional Information:  Owner

9.3.10.  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cont-type   |   Sub-Type    |         Resource-ID          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Resource-Object-Value                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Additional Information                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Cont-type:  An IANA assigned identifier for the type of content
      contained in this resource-object.

   Sub-type:  An IANA assigned identifier which further classifies the
      content type as defined by cont-type.

   Resource-ID (variable):  The Resource-ID TLV of the resource object.

   Resource-Object-Value (variable):  Variable length.  Its value
      depends on the content-type and sub-type.






Baset, et al.             Expires May 22, 2008                 [Page 74]

Internet-Draft            Peer-to-Peer Protocol            November 2007


9.3.10.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.

   Signature (Variable):  The cryptographic signature of the resource-
      object.

   X509 (fixed):  The X509 certificate of the peer publishing the
      resource-object.

9.3.11.  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

9.3.12.  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.







Baset, et al.             Expires May 22, 2008                 [Page 75]

Internet-Draft            Peer-to-Peer Protocol            November 2007


9.3.13.  Certificate

   An X.509 certificate.

   Type:  Certificate

   Sub-Type:  Self-Signed (0x00), Server-Signed (0x01).

   Length:  Variable.  Depends on the size of X.509 certificate.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Certificate                         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Certificate (variable):  The length of X.509 certificate.

9.3.14.  Signature

   The signature of the resource-object.

   Type:  Signature

   Length:  Variable.  Depends on the type of signature algorithm being
      used.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                         Signature                           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Signature (variable):  The signature length of resource-object.

9.3.15.  Capabilities and Diagnostics

   Time Window:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Time Window                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Baset, et al.             Expires May 22, 2008                 [Page 76]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Time Window (32 bits):  The elapsed time in seconds since the
      gathering of message statistics.  This can be included as part of
      every diagnostic TLV.

   AS Number:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Autonomous System Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Autonomous System Number (32 bits):  The autonomous system of node's
      IP address, if available.

   Connections:

    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 Neighbor Peers     |   Number of Routing Peers   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Number of clients            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Number of Neighbor Peers (16 bits):  The number of neighbor peers of
      this peer.

   Number of Routing Peers (16 bits):  The number of routing peers of
      this peer.

   Number of Clients (16 bits):  The number of clients connected with
      this peer.

   Node-Resource-Utilization:

    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 bandwidth                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   CPU Util.   |   BW. Util.   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Baset, et al.             Expires May 22, 2008                 [Page 77]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Peer Bandwidth (32 bits):  Estimated peer bandwidth in kilo bits per
      second.  This is tricky to determine and is TBD.

   CPU Utilization (8 bits):  CPU Utilization of this peer on a scale of
      1 to 100.  Represent the percentage of CPU being used.  If should
      be an average over the last five seconds.

   Bandwidth Utilization (8 bits):  Bandwidth utilization of this peer
      on a scale of 1 to 100.  Represent the percentage of bandwidth
      being used.  It should be an average over the last five seconds.

   Messages-Received:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Msg Type    |           Number of messages                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ......                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Msg Type (8 bits):  The message types as defined in Section 13.  The
      number 254 is reserved for responses and 255 for ACKs.

   Number of messages (24 bits):  The number of messages received for
      the 'msg type' since the elapsed time.

9.4.  Response Codes and Errors

9.4.1.  Response Codes

   There are four different types of response codes.  They are no
   provisional response codes.  The description is given below:

   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.

9.4.1.1.  2xx (Successful) Responses







Baset, et al.             Expires May 22, 2008                 [Page 78]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   200 Ok.   A successful answer to the request.

9.4.1.2.  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.

9.4.1.3.  4xx-511 (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.

9.4.2.  Error Object

   TBD.















Baset, et al.             Expires May 22, 2008                 [Page 79]

Internet-Draft            Peer-to-Peer Protocol            November 2007


10.  Application Layer

   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.

10.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)

10.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.

10.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.

10.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.

10.5.  Remove

   Remove([in]Resource-ID)

   An application uses this API to explicitly remove a resource-object
   from the overlay.





Baset, et al.             Expires May 22, 2008                 [Page 80]

Internet-Draft            Peer-to-Peer Protocol            November 2007


10.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, et al.             Expires May 22, 2008                 [Page 81]

Internet-Draft            Peer-to-Peer Protocol            November 2007


11.  Open Issues

   1.   Mandatory DHT: P2PP supports bamboo but elaborate.

   2.   SIP record insertion and lookup.

   3.   ICE overhead analysis for recursive and iterative routing and in
        the presence of churn.

   4.   Redirecting media relaying requests.

   5.   Overlay migration.

   6.   Reactive vs. periodic maintenance.

   7.   How can a node estimate its CPU and bandwidth utilization?

   8.   Non-SIP usage of P2PP

   9.   Secure protocol for iterative routing.

   10.  HTTP authentication.





























Baset, et al.             Expires May 22, 2008                 [Page 82]

Internet-Draft            Peer-to-Peer Protocol            November 2007


12.  Acknowledgements

   The authors will like to thank the following (in alphabetical order)
   for their helpful comments and suggestions.  Christian Schmidt,
   Christian Dickmann, Miguel Garcia, Jae W. Lee, Esko Kokkonen, Kundan
   Singh, Henry Sinnreich, Eunsoo Shim and Marc Willekens.













































Baset, et al.             Expires May 22, 2008                 [Page 83]

Internet-Draft            Peer-to-Peer Protocol            November 2007


13.  IANA Considerations

   Listening Port:  The port on which a peer listens for request.  The
      current implementation uses 7080 for UDP and TCP and 7081 for DTLS
      and TLS.

   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
      and indication messages.

                     +--------------+----------------+
                     | Message Type | Message        |
                     +--------------+----------------+
                     | 0            | Enroll         |
                     |              |                |
                     | 1            | Authenticate   |
                     |              |                |
                     | 2            | Bootstrap      |
                     |              |                |
                     | 3            | Join           |
                     |              |                |
                     | 4            | Leave          |
                     |              |                |
                     | 5            | KeepAlive      |
                     |              |                |
                     | 6            | LookupPeer     |
                     |              |                |
                     | 7            | ExchangeTable  |
                     |              |                |
                     | 8            | Query          |
                     |              |                |
                     | 9            | Publish        |
                     |              |                |
                     | 10           | LookupObject   |
                     |              |                |
                     | 11           | RemoveObject   |
                     |              |                |
                     | 12           | Replicate      |
                     |              |                |
                     | 13           | Transfer       |
                     |              |                |
                     | 14           | Tunnel         |
                     |              |                |
                     | 15           | Connect        |
                     |              |                |
                     | 16           | GetDiagnostics |
                     +--------------+----------------+



Baset, et al.             Expires May 22, 2008                 [Page 84]

Internet-Draft            Peer-to-Peer Protocol            November 2007


   Object Types:  There is a one byte field in the object header.  The
      following values for object types are defined by this
      specification.

                  +-------+-----------------------------+
                  | OType | Object Type                 |
                  +-------+-----------------------------+
                  | 0     | Peer-Info                   |
                  |       |                             |
                  | 1     | Peer-ID                     |
                  |       |                             |
                  | 2     | Address-Info                |
                  |       |                             |
                  | 3     | Unhashed-ID                 |
                  |       |                             |
                  | 4     | Uptime                      |
                  |       |                             |
                  | 5     | P2P-Options                 |
                  |       |                             |
                  | 6     | Request-Options             |
                  |       |                             |
                  | 7     | Diagnostic-Options          |
                  |       |                             |
                  | 8     | Routing-Table               |
                  |       |                             |
                  | 9     | Neighbor-Table              |
                  |       |                             |
                  | 10    | PLookup                     |
                  |       |                             |
                  | 11    | Resource-ID                 |
                  |       |                             |
                  | 12    | RLookup                     |
                  |       |                             |
                  | 13    | Resource-Object             |
                  |       |                             |
                  | 14    | Expires                     |
                  |       |                             |
                  | 15    | Owner                       |
                  |       |                             |
                  | 16    | Certificate-Signing-Request |
                  |       |                             |
                  | 17    | X.509-Cer7-Signature        |
                  |       |                             |
                  | 19    | Time-Window                 |
                  |       |                             |
                  | 20    | Connections                 |
                  |       |                             |
                  | 21    | Node-Resource-Utilization   |



Baset, et al.             Expires May 22, 2008                 [Page 85]

Internet-Draft            Peer-to-Peer Protocol            November 2007


                  | 22    | Messages-Received           |
                  |       |                             |
                  | 23    | AS-Number                   |
                  |       |                             |
                  | 24    | 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.

                           +-------+-----------+
                           | 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.




















Baset, et al.             Expires May 22, 2008                 [Page 86]

Internet-Draft            Peer-to-Peer Protocol            November 2007


                         +-------+---------------+
                         | PType | P2P-Algorithm |
                         +-------+---------------+
                         | 0     | Chord         |
                         |       |               |
                         | 1     | CAN           |
                         |       |               |
                         | 2     | Kademlia      |
                         |       |               |
                         | 3     | Pastry        |
                         |       |               |
                         | 4     | Bamboo        |
                         |       |               |
                         | 5     | Tapestry      |
                         |       |               |
                         | 6     | Accordion     |
                         |       |               |
                         | 7     | SkipNet       |
                         |       |               |
                         | 8     | Mercury       |
                         |       |               |
                         | 9     | Gia           |
                         +-------+---------------+

   Cont-Type:  This is a one-byte field in the Resource-Info object
      which defines the content-type of the object.  The following types
      are currently defined.

                       +-----------+---------------+
                       | Cont-Type | Description   |
                       +-----------+---------------+
                       | 0         | User-Info     |
                       |           |               |
                       | 1         | STUN          |
                       |           |               |
                       | 2         | TURN          |
                       |           |               |
                       | 3         | STUN+TURN+ICE |
                       +-----------+---------------+

   Component-ID:  The component ID as defined by ICE.










Baset, et al.             Expires May 22, 2008                 [Page 87]

Internet-Draft            Peer-to-Peer Protocol            November 2007


                      +--------------+-------------+
                      | Component-ID | Description |
                      +--------------+-------------+
                      | 0            | RTP         |
                      |              |             |
                      | 1            | RTCP        |
                      |              |             |
                      | 2            | SIP         |
                      |              |             |
                      | 2            | P2PP        |
                      +--------------+-------------+








































Baset, et al.             Expires May 22, 2008                 [Page 88]

Internet-Draft            Peer-to-Peer Protocol            November 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., Mahy, R., Matthews, P., and D. Wing, "Simple
         Traversal Underneath Network Address Translators (NAT) (STUN)",
          draft-ietf-behave-rfc3489bis-13 (work in progress),
         November 2007.

   [6]   Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay
         Addresses from Simple Traversal Underneath NAT (STUN)",
          draft-ietf-behave-turn-05 (work in progress), November 2007.

   [7]   Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Offer/Answer Protocols",  draft-ietf-mmusic-ice-19 (work in
         progress), October 2007.

14.2.  Informative References

   [8]   Willis, D., Bryan, D., Matthews, P., and E. Shim, "Concepts and
         Terminology for Peer-to-Peer SIP",
         draft-ietf-p2psip-concepts-01 (work in progress),
         November 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,



Baset, et al.             Expires May 22, 2008                 [Page 89]

Internet-Draft            Peer-to-Peer Protocol            November 2007


         pp. 73-84, 2005.

   [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



Baset, et al.             Expires May 22, 2008                 [Page 90]

Internet-Draft            Peer-to-Peer Protocol            November 2007


         computer communications. New York, NY, USA, pp. 407-418, 2003.

   [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.

   [22]  Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling
         Churn in a DHT", Proceedings of the 2004 USENIX Annual
         Technical Conference (USENIX '04) Boston, Massachusetts,
         June 2004.

   [23]  Docuer, J., "The Sybil Attack", IPTPS '02 , March 2002.

   [24]  MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using
         STUN",  draft-ietf-behave-nat-behavior-discovery-01 (work in
         progress), June 2007.

   [25]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
         Peer(P2P) Communication Across Network Address
         Translators(NATs)",  draft-srisuresh-behave-p2p-state-04,
         September 2006.
























Baset, et al.             Expires May 22, 2008                 [Page 91]

Internet-Draft            Peer-to-Peer Protocol            November 2007


Appendix A.  Background


















































Baset, et al.             Expires May 22, 2008                 [Page 92]

Internet-Draft            Peer-to-Peer Protocol            November 2007


Appendix B.  Message Flow


















































Baset, et al.             Expires May 22, 2008                 [Page 93]

Internet-Draft            Peer-to-Peer Protocol            November 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


   Marcin Matuszewski
   Nokia
   Helsinki,
   Finland

   Email: marcin.matuszewski@nokia.com























Baset, et al.             Expires May 22, 2008                 [Page 94]

Internet-Draft            Peer-to-Peer Protocol            November 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, et al.             Expires May 22, 2008                 [Page 95]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/