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

Versions: 00 01

Network Working Group                                         E. Marocco
Internet-Draft                                            Telecom Italia
Intended status: Standards Track                                 E. Ivov
Expires: December 17, 2007                     L. Pasteur University/SIP
                                                            Communicator
                                                           June 15, 2007


 XPP Extensions for Implementing a Passive P2PSIP Overlay Network based
                   on the CAN Distributed Hash Table
                    draft-marocco-p2psip-xpp-pcan-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 17, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Marocco & Ivov          Expires December 17, 2007               [Page 1]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


Abstract

   This document defines a set of extensions for the Extensible Peer
   Protocol (XPP) required for creating a P2PSIP overlay network based
   on the CAN distributed hash table algorithm.  It specifies how peers
   and clients must behave in order to maintain the overlay and use it
   for the establishment of multimedia communication sessions.

   To limit the overhead due to maintenance operations and to allow the
   adoption of security policies for preventing malicious nodes to
   damage the overlay, joins are always initiated and controlled by
   existing peers (hence the passive in PCAN).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  The Passive Approach . . . . . . . . . . . . . . . . . . .  5
     1.2.  Why CAN? . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  General Design . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  Peer Join  . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  Failure Recovery . . . . . . . . . . . . . . . . . . . . . 10
   3.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Peer Behavior  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Key-Point Mapping  . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Internal State . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.1.  Zone States  . . . . . . . . . . . . . . . . . . . . . 12
       4.2.2.  Neighbor Evaluation for Takeover . . . . . . . . . . . 17
     4.3.  Routing XPP Messages . . . . . . . . . . . . . . . . . . . 18
     4.4.  Handling SIP Registrations . . . . . . . . . . . . . . . . 18
     4.5.  Routing SIP Requests . . . . . . . . . . . . . . . . . . . 19
     4.6.  Inviting a Client to Join  . . . . . . . . . . . . . . . . 20
     4.7.  Generating PUT Operation Requests  . . . . . . . . . . . . 21
     4.8.  Handling PUT Operation Requests  . . . . . . . . . . . . . 22
     4.9.  Generating GET Operation Requests  . . . . . . . . . . . . 22
     4.10. Handling GET Operation Requests  . . . . . . . . . . . . . 22
     4.11. Generating QUERY Operation Requests  . . . . . . . . . . . 22
     4.12. Handling QUERY Operation Requests  . . . . . . . . . . . . 23
     4.13. Generating UPDATE Operation Requests . . . . . . . . . . . 23
     4.14. Handling UPDATE Operation Requests . . . . . . . . . . . . 24
     4.15. Generating JOIN Operation Requests . . . . . . . . . . . . 24
     4.16. Handling JOIN Operation Requests . . . . . . . . . . . . . 25
     4.17. Generating TAKEOVER Operation Requests . . . . . . . . . . 25
     4.18. Handling TAKEOVER Operation Requests . . . . . . . . . . . 26
   5.  XPP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 27
     5.1.  Parameter Formats  . . . . . . . . . . . . . . . . . . . . 27



Marocco & Ivov          Expires December 17, 2007               [Page 2]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


       5.1.1.  Integer  . . . . . . . . . . . . . . . . . . . . . . . 27
       5.1.2.  String . . . . . . . . . . . . . . . . . . . . . . . . 27
       5.1.3.  String List  . . . . . . . . . . . . . . . . . . . . . 28
       5.1.4.  Point  . . . . . . . . . . . . . . . . . . . . . . . . 28
       5.1.5.  Zone . . . . . . . . . . . . . . . . . . . . . . . . . 29
     5.2.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 30
       5.2.1.  KEY  . . . . . . . . . . . . . . . . . . . . . . . . . 30
       5.2.2.  VALUE  . . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.3.  BINDING-ID . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.4.  EXPIRES  . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.5.  TARGET . . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.6.  SPACE  . . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.7.  OWN-AOR  . . . . . . . . . . . . . . . . . . . . . . . 31
       5.2.8.  OWN-CONTACT  . . . . . . . . . . . . . . . . . . . . . 32
       5.2.9.  OWN-ZONE . . . . . . . . . . . . . . . . . . . . . . . 32
       5.2.10. YOUR-ZONE  . . . . . . . . . . . . . . . . . . . . . . 32
       5.2.11. PEER-AOR . . . . . . . . . . . . . . . . . . . . . . . 32
       5.2.12. PEER-CONTACT . . . . . . . . . . . . . . . . . . . . . 33
       5.2.13. PEER-ZONE  . . . . . . . . . . . . . . . . . . . . . . 33
       5.2.14. PEER-VOLUME  . . . . . . . . . . . . . . . . . . . . . 33
       5.2.15. DEAD-AOR . . . . . . . . . . . . . . . . . . . . . . . 33
       5.2.16. DEAD-CONTACT . . . . . . . . . . . . . . . . . . . . . 33
       5.2.17. DEAD-ZONE  . . . . . . . . . . . . . . . . . . . . . . 34
     5.3.  Operations . . . . . . . . . . . . . . . . . . . . . . . . 34
       5.3.1.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 34
       5.3.2.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 34
       5.3.3.  QUERY  . . . . . . . . . . . . . . . . . . . . . . . . 35
       5.3.4.  UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 35
       5.3.5.  JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 35
       5.3.6.  TAKEOVER . . . . . . . . . . . . . . . . . . . . . . . 36
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 39
     8.1.  Data Replication . . . . . . . . . . . . . . . . . . . . . 39
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 40
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 41
     10.2. Informative References . . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 45











Marocco & Ivov          Expires December 17, 2007               [Page 3]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


1.  Introduction

   This document describes a possible solution for a P2PSIP Overlay
   Network [I-D.willis-p2psip-concepts] currently implemented in the
   SIPDHT [WWW.sipdht] open source project.  The passive approach that
   the solution adopts is relatively uncommon in related work.  Yet it
   seems to be well-suited for addressing issues arising from the wide
   spread deployment of NAT devices, high churn rate and possible
   participation of malicious peers.  This solution is intended to:

   o  easily support deployments where many peers are located behind NAT
      boxes, adopting NAT traversal mechanisms such as STUN
      [I-D.ietf-behave-rfc3489bis] and ICE [I-D.ietf-mmusic-ice];

   o  provide mechanisms for keeping overlay size to an optimal minimum.
      Allowing peers located behind NAT devices to become members of the
      the overlay network implies frequent exchange of keep alive
      messages.  XPP-PCAN addresses this issue by only allowing the best
      available clients (i.e. those offering most significant resources)
      and doing so only when their participation is really necessary.

   o  provide mechanisms for limiting the effects of malicious nodes
      attempting to degrade the service.

   XPP-PCAN is based on the following key points:

   1.  the overlay is organized as a distributed database or hash table
       based on the CAN [WWW.icir.can] algorithm and it only offers
       functionalities for storing and retrieving data and for routing
       SIP [RFC3261] messages;

   2.  the P2P overlay is transparent to clients.  A client can maintain
       SIP outbound flows [I-D.ietf-sip-outbound] and register its
       location with any peer (causing the insertion of a routing record
       on the peer authoritative for its address);

          It would also be possible for clients, not participating in
          the overlay, to allow others to maintain outbound flows with
          them, as this would significantly lighten the load of the
          overlay.  At the moment such an option has been put aside for
          simplicity, but is listed as an open issue.

   3.  peers use XPP [I-D.marocco-p2psip-xpp] for performing maintenance
       operations;

   4.  peers use SIP (and possibly ICE) for establishing XPP sessions;





Marocco & Ivov          Expires December 17, 2007               [Page 4]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   5.  for every client using the overlay there is at least one
       registrar peer that the client uses as point of attachment to the
       overlay, and one authoritative peer (the one keeping location and
       routing information for the client (in some cases the two may
       coincide).

   6.  a peer can invite any client it is authoritative for to join the
       overlay.

   Once again, one of the main characteristics of XPP-PCAN is the fact
   that it is not possible for a node to decide whether it would simply
   use the overlay network as a client or become a part of it as a peer.
   One could therefore imagine the network as a free service which, in
   some cases, could invite any of its clients to provide resources for
   use by others.  Answering positively to an invitation is the only way
   for a client to become a peer.

      It is worth noting that points 1 and 4 allow peers and clients to
      use the SIP routing functionality provided by the overlay for
      establishing XPP sessions, which, in turn, are needed for
      maintaining the overlay itself.

   The remainder of this document, after giving a short overview of the
   CAN-based algorithm, specifies XPP extensions and defines operations
   each peer must perform in order to consistently maintain the overlay.
   However, it does not specify how a peer decides to invite a client to
   join the overlay; implementations must apply their own criteria for
   deciding both when and which node to invite.

1.1.  The Passive Approach

   Networks using XPP-PCAN would manage joins in a "passive" way, and
   only allow nodes to become members of the overlay once they have been
   invited by existing peers.  Overlays, used by file-sharing
   applications, would generally adopt the opposite approach and let
   clients decide whether or not to become peers.  A well known
   exception to this trend is the Skype network [WWW.columbia.skype],
   arguably one of the most popular overlay networks used for real-time
   communications today.  Instances of the Skype application may operate
   as super-nodes or ordinary-nodes and the "promotions" are decided by
   the higher levels of the hierarchy.

   The passive approach seems appropriate for P2PSIP because:

   o  all peer candidates are actually clients that have already
      registered with the service and are therefore known to the
      overlay.




Marocco & Ivov          Expires December 17, 2007               [Page 5]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   o  the overlay only needs to provide a limited amount of
      functionalities to clients and these could be handled by a
      relatively small subset of the nodes that actually use them.

   o  providing SIP connectivity to clients, storing their location,
      routing messages,in addition to maintaining tens or even hundreds
      of connections with neighbor peers could be very resource
      consuming.  It is therefore important to confirm availability of
      such resources prior to inviting a client to join the overlay as a
      peer.

   An additional advantage of passive joins is the fact that they allow
   the overlay to select peers among candidates based virtually any kind
   of performance and security characteristics.

      It is possible, for example, to limit the effects of malicious
      peers by only inviting trusted nodes to join the overlay.
      Assessing the level of trust could be handled in many different
      ways like provider maintained white-lists or social networks.

1.2.  Why CAN?

   The choice of the distributed hash table algorithm has been heavily
   influenced by our goal to have robust overlay networks even in cases
   when many peers are behind a NAT.  This requires maintaining
   persistent connections between peers and CAN fits this requirement
   quite well, because:

   1.  it is symmetric [I-D.baset-sipping-p2pcommon] (unlike Chord
       [WWW.mit.chord]).  Without such a property, each connection is
       efficiently used by only one of the endpoints;

   2.  peers maintain a stable routing table with a limited number of
       entries (which is not the case with Pastry [WWW.microsoft.pastry]
       and Kademlia [WWW.rice.kademlia]).

   A possible drawback when using the CAN algorithm is its relatively
   low performance.  While other popular algorithms claim to always be
   logarithmic in complexity, overlays based on CAN cannot scale
   indefinitely.  CAN based overlays need to be configured during
   deployment with parameters (e.g the number of dimensions for the hash
   space) depending on the size of the intended network.

   However, in the case of P2PSIP, the service could be provided by a
   subset of interested nodes.  This and the possibility to use delay
   measurements between peers when selecting best routes within the
   overlay, could help achieving acceptable performance even with a
   limited number of peers.



Marocco & Ivov          Expires December 17, 2007               [Page 6]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


1.3.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described RFC 2119 [RFC2119].













































Marocco & Ivov          Expires December 17, 2007               [Page 7]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


2.  Algorithm Overview

   The algorithm implemented by the overlay is a version of CAN
   [WWW.icir.can] slightly customized to fit the "passive" approach.
   This section briefly describes the overall design and the procedures
   for routing, joining the overlay and recovery after failures.
   Section 3 and Section 4 will then define how clients and peers
   establish and use XPP sessions for implementing these procedures.

2.1.  General Design

   The functionality on which the overlay is based, like all other
   distributed hash table algorithms, is the mapping of keys over the
   peers.  Such a functionality, unlike in algorithms based on the
   concept of consistent hashing [WWW.mit.chord] [WWW.microsoft.pastry]
   [WWW.rice.kademlia], is implemented in a virtual d-dimensional
   Cartesian coordinate space on a d-torus.

      The d-torus is the generalization of the Chord ring in d
      dimensions.  In fact, while in Chord keys are uni-dimensional and
      can be represented on a ring (i.e. a circular line), in CAN -- and
      so in the algorithm described here -- they are at least bi-
      dimensional and thus require a torus (i.e. a circular plane).

      A d-dimensional key can easily be obtained by splitting in d parts
      a uni-dimensional value returned by a common hash function.

   Any peer is assigned a distinct zone of the overall space and is
   authoritative for all the keys falling in it.  Zones are always
   defined by the coordinates of their lower left and top right corner,
   and contain the area locked between the borders including the bottom
   and left edges (thus excluding the right and top edges).  At any
   point in time, the overlay is consistent if the whole space is
   completely covered.  Figure 1 shows a bi-dimensional space
   partitioned among 5 peers.

   A peer maintains XPP sessions with all its immediate neighbors, along
   with information about the zones they are authoritative for.  When a
   peer receives an operation request for a key which falls out of its
   zone, it routes the request to the most appropriate neighbor.

      The most appropriate neighbor is generally the one whose center of
      mass is closer to the requested key; however, an implementation
      may also take into account link speed and so select not just
      according to geometric distance.  In any case, in order to avoid
      loops, peers must not route messages to neighbors which are not
      geometrically closer to the targeted key.




Marocco & Ivov          Expires December 17, 2007               [Page 8]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


                                     <10, 0>           <0, 0>
                  +-----------------*-----------------*
                  |                 |                 |
                  |                 |        E        |
                  |                 |<10, 15>         |<0, 15>
                  |        C        *-----------------*
                  |                 |                 |
                  |                 |        D        |
                  |<0, 10>          |<10, 10>         |<0, 10>
                  *-----------------*-----------------*
                  |                 |                 |
                  |                 |                 |
                  |                 |                 |
                  |        A        |        B        |
                  |                 |                 |
                  |                 |                 |
                  |<0, 0>           |<10, 0>          |
                  *-----------------*-----------------+


   A bi-dimensional space with 5 peers.  For simplicity, the space is
   shown in two dimensions.  In reality the figure is actually a torus.

                                 Figure 1

2.2.  Peer Join

   The decision when to invite a client to join the overlay is always
   taken by existing peers.  After choosing the best candidate to
   "promote", the inviting peer would either select a fragment recovered
   from a dead neighbor (see Section 2.3) or obtain a new one by
   splitting its zone through the longest edge into two equal parts.  It
   would then assign the new fragment to the entering peer.

      The selection process of the candidate to invite may be based on
      the evaluation of parameters like bandwidth, connectivity, uptime
      and trust; such a process strongly depends on the deployment and
      is outside the scope of this document.

      It is worth noting that, in the case of P2PSIP, a peer may choose
      the most appropriate node to invite among the clients it stores a
      registration for, that is the client whose address fall under its
      authority.

   After identifying the zone and the node to invite, the inviting peer
   sends a SIP INVITE request to the new peer and establishes an XPP
   session.  Once the XPP session established, the join is completed in
   the following six steps:



Marocco & Ivov          Expires December 17, 2007               [Page 9]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   1.  the inviting peer transfers to the new peer all data bound to
       keys located in the new zone;

   2.  the inviting peer notifies all the neighbors of the zone being
       transferred that a peer is about to join, and that they should be
       ready to establish XPP sessions with their new neighbor;

   3.  if the zone of the inviting peer has been split, it notifies all
       its current neighbors of its new coordinates;

   4.  the inviting peer sends to the invitee the list of all neighbors
       it will have after joining the overlay;

   5.  the entering peer establishes XPP sessions with all its new
       neighbors using SIP;

   6.  the inviting peer updates its neighbor list and ends all XPP
       sessions with peers which are no longer its neighbors.

2.3.  Failure Recovery

   When a peer fails, one or more zones of the overlay need to be
   recovered through a distributed election.  Elections are run by peers
   neighboring orphaned zones.  The exact algorithm is describe in
   Section 4.2.2.

   When a peer loses connectivity with one of is neighbors, it starts a
   timer waiting for other neighbors to also detect the failure.  The
   exact value of the timer depends on XPP timers and must therefore be
   greater than the maximum allowed interval between two subsequent keep
   alive responses plus the time necessary for neighbors to complete
   retransmissions of their last keep alive message.  When the timer
   fires, the peers would start the election algorithm.

   At this point all neighbors of the failed peer start exchanging
   messages for electing the one to take over the orphaned zone.  Every
   one of them would store the identity of the most appropriate
   candidate it sees and, after a stabilization interval Section 4.2.1,
   consider it authoritative on that zone.

   When a peer is elected for taking over a zone, it is likely that it
   does not know all of its new neighbors; if this is the case, it must
   query the neighbors it knows in order to discover new ones and
   establish XPP connections with them.







Marocco & Ivov          Expires December 17, 2007              [Page 10]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


3.  Client Behavior

   The overlay is intended to be transparent to conventional SIP user
   agents.  Once such a client has discovered the location of one or
   more peers (how exactly it has done so is outside the scope of this
   document), it MAY set any of them as its outbound proxy.  It SHOULD
   then register using the peer as a registrar and following the
   registration procedures described in [RFC3261] and.  If needed, the
   SIP client MAY direct SIP outbound flows [I-D.ietf-sip-outbound] to
   this peer in order to allow NAT traversal for SIP messages.

   If the client wants to be able to join the overlay, it MUST use a SIP
   contact which routes to itself from each point in the overlay (e.g. a
   global scope IP address); if it does not have such a contact, it MAY
   request a public GRUU [I-D.ietf-sip-gruu] from all peers it is
   sending SIP REGISTER requests to.

   When additional resources are necessary for the maintenance of the
   overlay, a client MAY receive a SIP INVITE request asking to join the
   overlay, as described in Section 4.6.  Since such a request MUST list
   the 'pcan' tag in the 'Require' header field, clients not
   implementing this specification, will answer with a 420 (Bad
   Extension) error message, as specified in [RFC3261].




























Marocco & Ivov          Expires December 17, 2007              [Page 11]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


4.  Peer Behavior

4.1.  Key-Point Mapping

   At any point in time, every peer is authoritative for one or more
   geometric zones, which means that it is responsible for storing all
   data bound to keys that correspond to points in these zones.

   In order to obtain the coordinates of a d-dimensional point, one has
   to split into 'd' equal components the 20 byte-long hash string
   returned by applying the SHA-1 [RFC3174] function on the key stripped
   of any URI parameters (i.e. all characters up to the first occurrence
   of a semi-colon - ';').

      The number of components MUST be equal to the number of dimensions
      indicated in the initial JOIN request; allowed values are 2, 4, 5
      and 10.

4.2.  Internal State

   The state of a peer participating in an overlay can be represented as
   a list of zones the local peer is authoritative for or which border
   on zones the local peer is authoritative for.  For each zone, a peer
   MUST store the SIP address-of-record and contact of the responsible
   peer, the coordinates of the geometric area and a state variable
   which can be set according to the state diagram in Figure 2.  When
   keeping track of the states of all neighbor zones (as defined in
   Section 4.2.1), a peer MAY assign each one of them one of three
   timers -- timer TC1, timer TC2 or timer TC3.

      Timers are named TC1, TC2 and TC3 for differentiating from XPP
      timers T1, T2 and T3.

   At any point in time a peer SHOULD have active XPP sessions with all
   its neighbors.  It MUST handle failures occurring in such sessions as
   explained in Section 4.2.1.

4.2.1.  Zone States

   Every peer maintains a list of all zones bordering on its own.  Every
   such zone may be in one of the following states.










Marocco & Ivov          Expires December 17, 2007              [Page 12]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


                              +-----------+
                       +------|           |
              TAKEOVER |      | BORDERING |<-------------------------+
                       +----->|           |                          |
                              +-----------+                Timer TC3 |
             +-----+     JOIN of ^  |                          fires |
             |     |  a new peer |  |                                |
    +--------| OWN |-------------+  |                                |
    |        |     |                |                                |
    |        +-----+                |                                |
    | Timer                         |                                |
    | TC2 fires             Failure |                                |
    |                     detection |                                |
    |                         event |                                |
    |                               v                                |
    |                       +---------------+                        |
    |                       |               |                        |
    |   Timer TC1 fires +---| SYNCHRONIZING |------+ TAKEOVER and    |
    |   or TAKEOVER and |   |               |      | local peer is   |
    |     local peer is |   +---------------+      | not appropriate |
    |       appropriate |                          |                 |
    |                   |                          |                 |
    |                   |                          |                 |
    |                   v                          v                 |
    |             +-----------+                +-------------+       |
    |             |           |                |             |       |
    +-------------| ACQUIRING |--------------->| STABILIZING |-------+
                  |           | TAKEOVER and   |             |
                  +-----------+ and local peer +-------------+
                    ^       |   not appropr.     ^       |
                    |       |                    |       |
                    +-------+                    +-------+
                    TAKEOVER                     TAKEOVER
                    and local peer
                    is appropriate



   Zone state diagram.

                                 Figure 2

   The states have the following meaning:

   o  BORDERING: a neighbor peer is authoritative for the zone and the
      XPP session with this peer is active.





Marocco & Ivov          Expires December 17, 2007              [Page 13]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   o  SYNCHRONIZING: the neighbor authoritative for the zone is
      unreachable.  The peer waits until all neighbors detect the
      failure.

   o  STABILIZING: a neighbor has been elected to take over the orphan
      zone.  The local peer is waiting to make sure that no one else
      claims ownership of this zone.

   o  ACQUIRING: the local peer is about to take over a zone but it is
      still waiting in case a more appropriate neighbor would claim it.

   o  OWN: the local peer is authoritative for the zone.

   In most cases, zones would be in either an OWN or a BORDERING state.
   States like SYNCHRONIZING, STABILIZING and ACQUIRING are only entered
   when a failure is detected and a zone needs to be taken over by
   another peer.  The recovery algorithm uses three timers -- TC1, TC2,
   and TC3 -- and is completed through several exchanges of TAKEOVER
   messages.  A peer MUST therefore be able to handle five different
   events for each of its neighbor zones, as defined in the remainder of
   this section.  The transition from state OWN to BORDERING, which
   occurs only when a new peer joins the overlay, is separately
   described in Section 4.6.

4.2.1.1.  Failure Detection Event

   The event is fired when an XPP session between the local peer and one
   of its neighbors has failed.  Upon According to the state that the
   neighbor zone had in the local zone list the local peer would do one
   of the following:

   State: BORDERING

   Set the zone state to SYNCHRONIZING; Start Timer TC1 for this zone
   and set it to 'tc1'.  The 'tc1' value is proportional to the total
   volume of the zones under the authority of the local peer and always
   greater than the maximum time required for detecting a failure.  Such
   a value MUST be calculated using the following formula (where r, t0,
   t1 and t2 are values used for handling retransmissions and keep alive
   in XPP [I-D.marocco-p2psip-xpp], v is the total volume under the
   authority authority of the local peer and V is the volume of the
   whole hash space):

      r' = min(ceil(log2(t1/t0)), r)

      tc0 = t0 * 2 ^ r' + (r - r') * t1 + t2





Marocco & Ivov          Expires December 17, 2007              [Page 14]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


      tc1 = tc0 * (1 + v / V)

   State: SYNCHRONIZING, STABILIZING, ACQUIRING or OWN

   Not possible.

4.2.1.2.  Timer TC1 Event

   State: SYNCHRONIZING

   Set the zone state to ACQUIRING; start Timer TC2 with value tc2
   (default: 6 seconds) and send a TAKEOVER operation request to all
   neighbors which are also neighbors of the zone to recover.  The
   Takeover request MUST be generated as defined in Section 4.17.

   State: BORDERING, STABILIZING, ACQUIRING or OWN

   Not possible.

4.2.1.3.  Timer TC2 Event

   State: ACQUIRING

   Set the zone state to OWN; the local peer is authoritative for the
   orphaned zone and the recovery algorithm is terminated.  All
   neighbors are aware of the new owner, but the local peer may need to
   discover and establish XPP sessions with new neighbors acquired as a
   result of the recovery, and to notify its neighbors about possible
   changes in the geometry due to one or more merges between its
   previous zones and the recovered one.

   New neighbors MUST be discovered sending QUERY operation requests to
   known neighbors, as defined in Section 4.11.  The local peer MUST
   establish XPP sessions with all discovered neighbors using SIP.

      A peer MUST NOT establish XPP sessions with peers it does not
      know; however, after the recovery process, all neighbors of the
      dead zone will know the identity of the new peer and MUST accept
      incoming SIP requests from it.

   If the recovered zone is mergeable with any of the zones previously
   owned by the local peer (i.e. they share an edge in 2-dimensional
   spaces, a plane in 3-dimensional ones and so on), all the neighbors
   MUST be notified of the merge through an UPDATE operation requests,
   as defined in Section 4.13.

   State: BORDERING, SYNCHRONIZING, STABILIZING or OWN




Marocco & Ivov          Expires December 17, 2007              [Page 15]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   Not possible.

4.2.1.4.  TAKEOVER Operation Request Event

   State: BORDERING

   Leave the zone in a BORDERING state; send back a TAKEOVER operation
   request on behalf of the peer authoritative for the zone.  The
   TAKEOVER request MUST be generated as defined in Section 4.17.

      This event would only occur when the failure is only detected by
      some of the neighbors, while others are still able to communicate
      with the peer.

   State: SYNCHRONIZING

   If, according to the rules defined in Section 4.2.2, the local peer
   is more appropriate than the one sending the TAKEOVER request, set
   the zone state to ACQUIRING; cancel Timer TC1, set Timer TC2 with
   value tc2 (default: 6 seconds) and send a TAKEOVER operation request
   to all neighbors that are also neighbors of the zone to recover.  The
   TAKEOVER request MUST be generated as defined in Section 4.17.

   Otherwise, if the local peer is less appropriate than the one sending
   the TAKEOVER request, set the zone state to STABILIZING; cancel Timer
   TC1, set Timer TC3 with value tc3 (default: 4 seconds), temporary
   store the identity of the peer candidate to take over the zone and
   send a TAKEOVER operation request to all neighbors which are also
   neighbors of the zone to recover on behalf of such peer.  The
   TAKEOVER MUST be generated as defined in Section 4.17.

   State: ACQUIRING

   If, according to the rules defined in Section 4.2.2, the local peer
   is more appropriate than the one reported in the TAKEOVER request,
   keep the zone state as ACQUIRING; reset Timer TC2 to value tc2
   (default: 6 seconds) and send a TAKEOVER operation request to all
   neighbors that are also neighbors of the zone to recover.  The
   TAKEOVER request MUST be generated as defined in Section 4.17.

   Otherwise, if the local peer is less appropriate than the one
   reported in the TAKEOVER request, set the zone state to STABILIZING;
   cancel Timer TC2, start Timer TC3 for a period of tc3 (default: 4
   seconds), store the identity of the peer as the best candidate to
   take over the zone and send a TAKEOVER operation request to all
   neighbors which are also neighbors of the zone to recover on behalf
   of such peer.  The TAKEOVER MUST be generated as defined in
   Section 4.17.



Marocco & Ivov          Expires December 17, 2007              [Page 16]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   State: STABILIZING

   If, according to rules defined in Section 4.2.2, the peer previously
   stored as the best candidate is more appropriate than the one
   reported in the TAKEOVER request, keep the zone in a STABILIZING
   state; reset Timer TC3 to tc3 (default: 4 seconds) and, on behalf of
   the old candidate, send TAKEOVER requests to all neighbors that are
   also neighbors of the zone to recover.  The TAKEOVER request MUST be
   generated as defined in Section 4.17.

   If the peer previously stored as the best candidate is less
   appropriate than the one reported in the TAKEOVER request, stay in
   STABILIZING; reset Timer TC3 with value tc3 (default: 4 seconds),
   store the identity of the latter as the best candidate and send a
   TAKEOVER operation request to all neighbors which are also neighbors
   of the zone to recover on behalf of such peer.

   Otherwise, if the peer previously stored as the best candidate is the
   same as the one reported in the TAKEOVER request, keep the zone in a
   STABILIZING state and do nothing further.

   State: OWN

   Not possible.

4.2.1.5.  Timer TC3 Event

   State: BORDERING, SYNCHRONIZING, ACQUIRING or OWN

   Not possible.

   STABILIZING

   Set the zone state to BORDERING; set the peer that has qualified as
   the best candidate as the new owner of the zone.

      The local peer may or may not have a connection with the new
      neighbor; in case it doesn't, it MUST be ready to accept a request
      for establishing one.

4.2.2.  Neighbor Evaluation for Takeover

   In order to determine whether one peer is more appropriate than
   another for taking over a zone, a list of conditions need to be taken
   into account in the following order:

   1.  if one of the peers is the current owner (e.g. the failure was
       temporary or just limited to some connections), it wins the



Marocco & Ivov          Expires December 17, 2007              [Page 17]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


       election;

   2.  if only one of the peers can merge the uncovered zone with its
       own, it wins the election.  Note: two zones can be merged if they
       share a border component (an edge for 2d, a surface for 3d and so
       on);

   3.  if the sums of the zone volumes are different for the two peers,
       the one with the smallest value wins the election;

   4.  if none of the above produces a winner, the peer with the first
       identity in lexicographic order wins the election.

4.3.  Routing XPP Messages

   When a peer receives a GET, a PUT or a QUERY operation request for a
   key or a target which is not contained in any of its zones, it MUST
   route it to the most appropriate neighbor.

      The most appropriate neighbor is generally the one whose center of
      mass is closest to the target; however, an implementation MAY also
      take in account link speed and so select not just according to
      geometric distance.  In any case, in order to avoid loops, peers
      MUST NOT route messages to neighbors which are not geometrically
      closer than them to the destination zone.

   XPP responses MUST be returned through the path that the originating
   request came through.  When routing an XPP request, a peer MUST
   therefore locally store information for routing responses back on the
   same session it was received.  Neither the XPP specification
   [I-D.marocco-p2psip-xpp] nor this document currently define for how
   long peers should keep state information about routed requests (this
   is for the moment an open issue, listed in (Section 8).  However, it
   is still worth noting that as GET and PUT operations are supposed to
   be used for handling SIP transactions, it is RECOMMENDED that such an
   interval is not shorter than 32 seconds.

4.4.  Handling SIP Registrations

   All peers MUST be able to process SIP REGISTER requests sent directly
   by clients or routed by other peers in the overlay's domain, and
   update routing records in the distributed database with XPP PUT
   operations (see Section 4.7).  Moreover, to overcome issues related
   to connectivity restrictions, such as NAT devices, peers MUST support
   the SIP outbound [I-D.ietf-sip-outbound] and GRUU [I-D.ietf-sip-gruu]
   extensions.

   If the Contact header field in the incoming REGISTER contains the



Marocco & Ivov          Expires December 17, 2007              [Page 18]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   'reg-id' parameter, the connection from which it was received MUST be
   kept alive as described in [I-D.ietf-sip-outbound] and the routing
   record MUST consist of a path where the first element is the URI
   identifying the peer (a SIP contact or a GRUU), the last element is
   the value in the Contact header field, and the elements in between
   are copied from those read in the Path header field [RFC3327], if one
   is set.  Otherwise, if the registration does not require outbound
   support, the record MUST only contain the first value in the Contact
   header field.

   If the REGISTER request has a Supported or Require header field
   containing the 'gruu' tag, the peer MUST generate a GRUU appending a
   'gr' parameter with a value equal to the instance ID (reported in the
   '+sip.instance' parameter in the Contact header field) to the
   address-of-record of the registering peer.  In such cases, the peer
   MUST insert records for both the address-of-record and the GRUU into
   the distributed database, and return the GRUU in the SIP response as
   specified in [I-D.ietf-sip-gruu].

      It is worth mentioning that, according to mapping rules in
      Section 4.1, the same peer will be authoritative on both the GRUU
      and the address-of-record.

   In general, a peer handling a REGISTER request is not necessarily the
   one storing the corresponding routing record; A registrar peer MUST
   send an XPP PUT operation request as described in Section 4.7 and
   wait for the XPP response to generate the SIP response.  Since the
   XPP request could silently fail, if a response is not received after
   a "reasonable" time, it SHOULD close the SIP transaction with a 504
   "Server Time-out" error code.

      The "reasonable" time period depends on several parameters, such
      as the overlay size and the transport protocol used for the SIP
      registration.  It is RECOMMENDED that, if the REGISTER request was
      sent over UDP, such period is shorter than SIP's Timer F value
      (default: 32 seconds) [RFC3261].  The matter is still considered
      an open issue (Section 8).

4.5.  Routing SIP Requests

   When a peer receives a SIP request not addressed to itself and with
   no Route header field set, it MUST first determine if the target (the
   request URI) belongs to the overlay domain.  If not, it SHOULD route
   it according to rules defined in [RFC3263].  Otherwise, if the target
   of the request is a SIP URI in the overlay domain, it MUST retrieve
   the routing record bound to the URI in the request line, generating
   an XPP GET operation request as defined in Section 4.9.




Marocco & Ivov          Expires December 17, 2007              [Page 19]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   The corresponding GET operation response, returned by the peer
   authoritative for the destination URI, MUST contain the path SIP
   requests need to follow to reach the target.  After receiving the GET
   operation response, the peer MUST recursively resolve all path
   components that are represented as URIs belonging to the overlay
   domain.  Next, it MUST add Route header fields reflecting the
   resolved path and use it to route the request.

   If the peer does not receive a GET response after a "reasonable"
   amount of time, it SHOULD close the SIP transaction with a 504
   "Server Time-out" error code.  As already mentioned , this
   "reasonable" amount of time is currently considered an open issue
   (Section 8).

      As noted in Section 4.4, the "reasonable" time interval depends on
      several parameters, such as the overlay size and the transport
      protocol used for sending the SIP message.  It is RECOMMENDED
      that, if the SIP request was sent over UDP, such period is shorter
      than 32 seconds.

4.6.  Inviting a Client to Join

   When a peer needs to invite a new client to join the overlay it first
   needs to select the "best" available among those it stores an active
   SIP registration for.  This document does not specify how it could be
   done; implementations will apply their own criteria.

   After identifying the client to invite and a zone to transfer (either
   one recovered from a dead peer or one obtained by splitting its own),
   the inviting peer MUST send a SIP INVITE request to the joining
   client in order to establish an XPP session with it.  The INVITE
   request MUST have a Require header field containing the 'pcan'
   extension tag and will be routed as specified in Section 4.5.

      In network environments where it is expected that peers might be
      located behind NAT devices, the session negotiation SHOULD be
      completed using the ICE [I-D.ietf-mmusic-ice] mechanism.

   If the client answers positively and after the XPP session has been
   correctly established as described in [I-D.marocco-p2psip-xpp], the
   join procedure would continue through the following steps:

   1.  the inviting peer sends a PUT request generated as described in
       Section 4.7 to the entering peer for transferring all the data
       bound to keys located in the new zone;

   2.  the inviting peer sends an UPDATE request to all its neighbors.
       Generated UPDATE requests is described in Section 4.13.  This



Marocco & Ivov          Expires December 17, 2007              [Page 20]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


       request would report all zones of authority of the inviting peer
       as well as the one transferred to the entering peer.  Peers
       receiving an UPDATE request MUST take into account any changes of
       the overlay topology and, in case they are also going to be
       neighbors of the new peer, prepare to establish XPP sessions with
       it.

   3.  the inviting peer then sends a JOIN request generated as
       described in Section 4.15 to the entering peer.  The request
       contains coordinates of the zone being transfered and the list of
       its neighbors;

   4.  the entering peer establishes XPP sessions with all its new
       neighbors using SIP;

   5.  the inviting peer updates its zone list and closes sessions with
       peers that, as a result of the transfer, are no longer its
       neighbors.

4.7.  Generating PUT Operation Requests

   PUT operations insert key-value pairs in the distributed database.
   In general, such requests would be used when storing SIP
   registrations.  Every such request is composed of one or more tuples
   containing:

   o  KEY: a SIP URI, usually an address-of-record or a GRUU
      [I-D.ietf-sip-gruu];

   o  VALUE: the route-path SIP messages addressed to the user SHOULD
      follow;

   o  BINDING-ID: the token identifying the key-value pair instance.
      Two subsequent PUT operations with same KEY and same BINDING-ID
      overwrite the same record; two PUT operations with same KEY and a
      different BINDING-ID would cause the insertion of two different
      records.  For PUT requests generated upon SIP registrations, the
      BINDING-ID SHOULD contain the value of the Call-ID header field in
      the REGISTER request;

   o  EXPIRES: the amount of time (in seconds) that the record needs to
      be kept.

   It is RECOMMENDED that requests containing more than one tuple are
   generated only if all tuples fall under the authority of the same
   peer; this could be the case, for example, during a join
   (Section 4.6) or when handling a registration requesting a GRUU
   (Section 4.4).



Marocco & Ivov          Expires December 17, 2007              [Page 21]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


4.8.  Handling PUT Operation Requests

   Upon reception of a PUT operation request, a peer MUST first check if
   it is responsible for the KEY parameter contained in the first tuple.
   If it is not, it MUST route the request as defined in Section 4.3;
   otherwise, for each tuple in the request it is responsible for, it
   MUST update or insert a record in its local table, respectively if
   one with same KEY and BINDING-ID previously existed or not.

   Once stored records it is responsible for, the peer MUST return in a
   PUT operation response, all records in its local table bound to keys
   matching one of those contained in the initial request.  PUT
   operation responses are thus syntactically identical to PUT requests
   (see Section 4.7).

4.9.  Generating GET Operation Requests

   GET operation requests retrieve data in the distributed database.
   Most often, GET requests would be used when querying the location of
   clients and peers for routing SIP messages.  Such requests contain
   one or more KEY parameters, typically a SIP address-of-record or a
   GRUU [I-D.ietf-sip-gruu].

   It is RECOMMENDED that requests containing more than one KEY
   parameter be generated only when all keys fall under the authority of
   the same peer.

4.10.  Handling GET Operation Requests

   Upon reception of a GET operation request, a peer MUST first check if
   it is responsible for the first KEY parameter.  If it is not, it MUST
   route the request as defined in Section 4.3; otherwise, it MUST
   return in a GET operation response, all records in its local table
   bound to keys matching one of those contained in the initial request.

   GET operation responses are syntactically identical to PUT responses
   (see Section 4.8).

4.11.  Generating QUERY Operation Requests

   QUERY operations are used by peers to gather information about the
   overlay topology, for example, for discovering new neighbors after a
   recovery.  QUERY requests consist of one TARGET parameter used for
   routing the operation.







Marocco & Ivov          Expires December 17, 2007              [Page 22]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


4.12.  Handling QUERY Operation Requests

   Upon reception of a QUERY operation request, a peer MUST first check
   if the TARGET parameter belongs to one of the zones it is
   authoritative for.  If not, it MUST route the request as explained in
   Section 4.3; otherwise, it MUST return a representation of the zones
   it is aware of in a QUERY response containing:

   o  a list describing zones the answering peer is authoritative for,
      each one containing:

      *  OWN-CONTACT: contact of the answering peer;

      *  OWN-AOR: address-of-record the answering peer is registered
         for;

      *  OWN-ZONE: coordinates of the zone;

   o  [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are
      currently redundantly copied in every record.  We should fix this
      in the next draft version.]

   o  a list describing zones neighboring those of the answering peer.
      Every list entry contains:

      *  PEER-CONTACT: contact of the neighbor peer;

      *  PEER-AOR: address-of-record the neighbor peer is registered
         for;

      *  PEER-ZONE: coordinates of the zone.

4.13.  Generating UPDATE Operation Requests

   UPDATE operations are used for advertising changes in the overlay
   topology, such as joins, recoveries or zone merges.  UPDATE requests
   MUST report information related to zones the sending peer is
   authoritative for or is currently transferring.  They contain the
   following parameters:

   o  a list describing zones the sending peer is currently
      authoritative for, each one containing:

      *  OWN-CONTACT: contact of the sending peer;

      *  OWN-AOR: address-of-record the sending peer is registered with;





Marocco & Ivov          Expires December 17, 2007              [Page 23]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


      *  OWN-ZONE: coordinates of the zone;

   o  [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are
      currently redundantly copied in every record.  We should fix this
      in the next draft version.]

   o  a list containing all zones neighboring those of the sending peer.
      The list may also contain zones that used to be under the
      authority of the sending peer but have just been transfered to a
      joining node.  List tuples MUST contain the following parameters:

      *  PEER-CONTACT: contact of the neighbor peer;

      *  PEER-AOR: address-of-record the neighbor peer is registered
         for;

      *  PEER-ZONE: coordinates of the zone.

   Contrary to QUERY responses, UPDATE requests MUST only report details
   that the sending peer is authoritative for, or zones that it is in
   the process of transfer to a joining peer after inviting it. (see
   Section 4.6).

4.14.  Handling UPDATE Operation Requests

   Upon reception of an UPDATE operation request, a peer MUST first
   remove from its zone list all zones overlapping with any of those
   reported in the request.  It MUST then insert all zones from the
   UPDATE request that border zones it is authoritative for.  UPDATE is
   a responseless request and MUST not be routed.

4.15.  Generating JOIN Operation Requests

   JOIN operations are used to pass the data that a client needs in
   order to join the overlay and become a peer.  JOIN requests are
   generated by the inviting peer as described in Section 4.6 and
   contain the following parameters:

   o  SPACE: coordinates of the whole space;

   o  YOUR-ZONE: coordinates of the zone the entering peer will be
      authoritative for;

   o  a list describing zones the inviting peer is authoritative for,
      each one containing:

      *  OWN-CONTACT: contact of the inviting peer;




Marocco & Ivov          Expires December 17, 2007              [Page 24]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


      *  OWN-AOR: address-of-record the inviting peer is registered for;

      *  OWN-ZONE: coordinates of the zone;

   o  [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are
      currently redundantly copied in every record.  We should fix this
      in the next draft version.]

   o  a list describing zones bordering on the one the entering peer
      will be authoritative for, each one containing:

      *  PEER-CONTACT: contact of the neighbor peer;

      *  PEER-AOR: address-of-record the neighbor peer is registered
         for;

      *  PEER-ZONE: coordinates of the zone.

4.16.  Handling JOIN Operation Requests

   JOIN operation requests can only be received during the join phase,
   as described in Section 4.6.  JOIN is a responseless end-to-end
   operation and MUST not be routed; a peer receiving an unexpected JOIN
   request MUST ignore it.

4.17.  Generating TAKEOVER Operation Requests

   TAKEOVER operations are used for electing the most appropriate peer
   to take over a zone left by a peer that has become unreachable.
   TAKEOVER requests are generated and exchanged by neighbors of the
   dead peer and contain the following parameters:

   o  DEAD-CONTACT: contact of the dead peer;

   o  DEAD-AOR: the address-of-record the dead peer was registered with;

   o  DEAD-ZONE: coordinates of the dead zone;

   o  PEER-CONTACT: contact of the peer candidate to take over the dead
      zone;

   o  PEER-AOR: address-of-record the peer candidate to take over the
      zone is registered for;

   o  PEER-ZONE: coordinates of a zone the peer candidate to take over
      the zone is authoritative for.  If one or more of the zones the
      candidate peer is authoritative for is mergeable with the dead
      one, it SHOULD be reported in this parameter as it would increase



Marocco & Ivov          Expires December 17, 2007              [Page 25]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


      the probability for the peer to be elected (see Section 4.2.2);

   o  PEER-VOLUME: the total volume of the zones the candidate peer is
      authoritative for.

4.18.  Handling TAKEOVER Operation Requests

   TAKEOVER operation requests are received only when recovering from
   failures and are handled according to the state diagram defined in
   Section 4.2.1.

   Unexpected TAKEOVER requests, for example referring to non-bordering
   zones, MUST be ignored.






































Marocco & Ivov          Expires December 17, 2007              [Page 26]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


5.  XPP Extensions

   This section extends the XPP specification [I-D.marocco-p2psip-xpp]
   and defines codes and formats for operations and parameters used in
   XPP sessions between peers.

5.1.  Parameter Formats

   For convenience purposes we define a non-exclusive set of formats
   that we later use when defining PCAN related XPP parameters.

5.1.1.  Integer

   Length:  the total number of bytes transported in the value.  The
      length MUST always be divisible by 4.

   Value:  numeric, encoded in network byte order.

   Example:


                   +--+--+--+--+
    Type/Length:   |XX XX|00 08|
                   +--+--+--+--+
          Value:   |00 00 00 AA|
                   +--+--+--+--+
                   |BB CC DD EE|
                   +--+--+--+--+


      Encoding of an integer parameter with value 0xAABBCCDDEE.

5.1.2.  String

   Length:  the total number of characters.  If the length is not
      divisible by 4; the value field MUST be padded as defined in
      [I-D.marocco-p2psip-xpp].

   Value:  a sequence of ASCII characters.

   Example:










Marocco & Ivov          Expires December 17, 2007              [Page 27]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


                   +--+--+--+--+
    Type/Length:   |XX XX|00 0A|
                   +--+--+--+--+
          Value:   |61 61 62 62|
                   +--+--+--+--+
                   |63 63 64 64|
                   +--+--+--+--+
                   |65 65 00 00|
                   +--+--+--+--+


      Encoding of a string parameter with value "AABBCCDDEE".

5.1.3.  String List

   Value:  a list of ASCII strings terminated by a byte with value zero.

   Length:  the total number of characters, including the terminator
      bytes.  If the length is not divisible by 4 it MUST be padded as
      defined in [I-D.marocco-p2psip-xpp].

   Example:


                   +--+--+--+--+
    Type/Length:   |XX XX|00 0F|
                   +--+--+--+--+
          Value:   |73 69 70 3A|
                   +--+--+--+--+
                   |6D 65 00 73|
                   +--+--+--+--+
                   |69 70 3A 79|
                   +--+--+--+--+
                   |6F 75 00 00|
                   +--+--+--+--+


      Encoding of a URI list parameter with value {"sip:me", "sip:you"}.

5.1.4.  Point

   Value:

      1.  one 4 byte-long numeric value encoded in network byte order,
          representing the number of bytes used for encoding each one of
          the following components.  The value of this field MUST always
          be divisible by 4.




Marocco & Ivov          Expires December 17, 2007              [Page 28]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


      2.  a sequence of numeric values representing the components of a
          multidimensional point, each one encoded in network byte order
          and taking the number of bytes reported as the the first value
          of the parameter.

   Length:  the total number of bytes occupied by the length value and
      by the components.  Such a value MUST be divisible by 4.

   Example:


                   +--+--+--+--+
    Type/Length:   |XX XX|00 14|
                   +--+--+--+--+
          Value:   |00 00 00 08|
                   +--+--+--+--+
                   |00 00 00 AA|
                   +--+--+--+--+
                   |BB CC DD EE|
                   +--+--+--+--+
                   |00 00 00 01|
                   +--+--+--+--+
                   |02 03 04 05|
                   +--+--+--+--+


      Encoding of a point parameter with components 0xAABBCCDDEE and
      0x0102030405.

5.1.5.  Zone

   Value:

      1.  one 4 byte-long numeric value encoded in network byte order,
          representing the number of bytes used for encoding each one of
          the following components.  The value of this field MUST always
          be divisible by 4;

      2.  a sequence of numeric values representing the components of
          two multidimensional points, each one encoded in network byte
          order and taking the number of bytes reported as the the first
          value of the parameter.  The point defined by the first half
          of values represents the start vertex (the bottom-left corner
          of a rectangular zone in a bi-dimensional space) and the other
          defines the end vertex (the top-right corner, in a bi-
          dimensional zone).





Marocco & Ivov          Expires December 17, 2007              [Page 29]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   Length:  the total length of the Value field.  Values of the length
      field must always be divisible by 4.

   Example:


                   +--+--+--+--+
    Type/Length:   |XX XX|00 24|
                   +--+--+--+--+
          Value:   |00 00 00 08|
                   +--+--+--+--+
                   |00 00 00 AA|
                   +--+--+--+--+
                   |BB CC DD EE|
                   +--+--+--+--+
                   |00 00 00 01|
                   +--+--+--+--+
                   |02 03 04 05|
                   +--+--+--+--+
                   |00 00 00 FF|
                   +--+--+--+--+
                   |FF FF FF FF|
                   +--+--+--+--+
                   |00 00 00 FF|
                   +--+--+--+--+
                   |FF FF FF FF|
                   +--+--+--+--+


      Encoding of a zone parameter represented by points (0xAABBCCDDEE,
      0x0102030405) and (0xFFFFFFFFFF, 0xFFFFFFFFFF).

5.2.  Parameters

   This section describes all TLV parameters used by XPP-PCAN.

5.2.1.  KEY

   Code:  0x8001.

   Format:  String (Section 5.1.2).

   Semantic:  the key identifying a record to insert or to retrieve.








Marocco & Ivov          Expires December 17, 2007              [Page 30]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


5.2.2.  VALUE

   Code:  0x8002.

   Format:  String list (Section 5.1.3).

   Semantic:  the set of peer URIs to traverse for reaching a client or
      a peer, as described in RFC 3327 [RFC3327].  Every URI MUST be
      encoding according to the rules defined in [RFC3986].

5.2.3.  BINDING-ID

   Code:  0x8003.

   Format:  string (Section 5.1.2).

   Semantic:  the token identifying a key-value pair.

5.2.4.  EXPIRES

   Code:  0x8004.

   Format:  integer (Section 5.1.1).

   Semantic:  the expiration time of a key-value pair, in seconds.

5.2.5.  TARGET

   Code:  0x8005.

   Format:  point (Section 5.1.4).

   Semantic:  the point in the overlay that a request is addressed to.

5.2.6.  SPACE

   Code:  0x8006.

   Format:  zone (Section 5.1.5).

   Semantic:  the bounds of the space used in the crrent overlay.

5.2.7.  OWN-AOR








Marocco & Ivov          Expires December 17, 2007              [Page 31]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   Code:  0x8007.

   Format:  String (Section 5.1.2).

   Semantic:  the SIP URI identifying the user who owns the sending
      peer, as defined in RFC 3261 [RFC3261] and RFC 3986 [RFC3986].

5.2.8.  OWN-CONTACT

   Code:  0x8008.

   Format:  String (Section 5.1.2).

   Semantic:  the SIP URI identifying the sending peer.

         It is worth noting that, when the peer has restricted
         connectivity (e.g. it is located in a NAT-ted network), the
         value of this parameter SHOULD be a GRUU [I-D.ietf-sip-gruu].

5.2.9.  OWN-ZONE

   Code:  0x8009.

   Format:  zone (Section 5.1.5).

   Semantic:  a zone the sending peer is authoritative for.

5.2.10.  YOUR-ZONE

   Code:  0x800A.

   Format:  zone (Section 5.1.5).

   Semantic:  a zone the receiving peer is going to be authoritative for
      (usually sent to joining peers).

5.2.11.  PEER-AOR

   Code:  0x800B.

   Format:  String (Section 5.1.2).

   Semantic:  the SIP URI identifying a user whose peer is known by the
      sending peer, as defined in RFC 3261 [RFC3261] and RFC3986
      [RFC3261].






Marocco & Ivov          Expires December 17, 2007              [Page 32]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


5.2.12.  PEER-CONTACT

   Code:  0x800C.

   Format:  String (Section 5.1.2).

   Semantic:  the SIP URI identifying a peer known by the sending peer.

         It is worth noting that, when the peer has restricted
         connectivity, the value will be a GRUU [I-D.ietf-sip-gruu].
         URI values MUST be encoded as specified in RFC3986 [RFC3986]

5.2.13.  PEER-ZONE

   Code:  0x800D.

   Format:  zone (Section 5.1.5).

   Semantic:  a zone a peer known by the sending peer is authoritative
      for.

5.2.14.  PEER-VOLUME

   Code:  0x800E.

   Format:  integer (Section 5.1.1).

   Semantic:  the total volume owned by a peer known by the sending
      peer.

5.2.15.  DEAD-AOR

   Code:  0x800F.

   Format:  String (Section 5.1.2).

   Semantic:  the SIP URI identifying a user whose peer is known by the
      sending peer, as defined in RFC 3261 [RFC3261].  URI values MUST
      be encoded as specified in RFC3986 [RFC3986]

5.2.16.  DEAD-CONTACT

   Code:  0x8010.

   Format:  String (Section 5.1.2).






Marocco & Ivov          Expires December 17, 2007              [Page 33]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   Semantic:  the SIP URI identifying a peer known by the sending peer.

         It is worth noting that, when the peer has restricted
         connectivity, the value will be a GRUU [I-D.ietf-sip-gruu].
         URI values MUST be encoded as specified in RFC3986 [RFC3986]

5.2.17.  DEAD-ZONE

   Code:  0x8011.

   Format:  zone (Section 5.1.5).

   Semantic:  a zone a peer known by the sending peer is authoritative
      for.

5.3.  Operations

5.3.1.  PUT

   Code:  0x80000001.

   Request parameters:

      +[ KEY VALUE BINDING-ID EXPIRES

   Response parameters:

      +[ KEY VALUE BINDING-ID EXPIRES

   Semantic:  insert one or more records in the distributed database.

   Routing:  requests MUST be routed to the peer responsible for the
      first key; responses MUST follow the reverse path of requests.

5.3.2.  GET

   Code:  0x80000002.

   Request parameters:

      +[ KEY

   Response parameters:

      *[ KEY VALUE BINDING-ID EXPIRES






Marocco & Ivov          Expires December 17, 2007              [Page 34]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


   Semantic:  retrieve one or more records in the distributed database.

   Routing:  requests MUST be routed to the peer responsible for the
      first key; responses MUST follow the reverse path of requests.

5.3.3.  QUERY

   Code:  0x80000003.

   Request parameters:

       [ TARGET

   Response parameters:

      +[ OWN-CONTACT OWN-AOR OWN-ZONE

      *[ PEER-CONTACT PEER-AOR PEER-ZONE

   Semantic:  query the status of the peer authoritative for the zone a
      given point falls in.

   Routing:  requests MUST be routed to the peer authoritative on the
      zone which include the point encoded in TARGET parameter;
      responses MUST follow the reverse path of requests.

5.3.4.  UPDATE

   Code:  0x80000004.

   Request parameters:

      +[ OWN-CONTACT OWN-AOR OWN-ZONE

      *[ PEER-CONTACT PEER-AOR PEER-ZONE

   Semantic:  status update upon a change.

   Routing:  end-to-end, MUST NOT be routed.

5.3.5.  JOIN

   Code:  0x80000005.

   Request parameters:






Marocco & Ivov          Expires December 17, 2007              [Page 35]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


       [ SPACE YOUR-ZONE

      +[ OWN-CONTACT OWN-AOR OWN-ZONE

      *[ PEER-CONTACT PEER-AOR PEER-ZONE

   Semantic:  join the overlay becoming authoritative on a given zone.

   Routing:  end-to-end, MUST NOT be routed.

5.3.6.  TAKEOVER

   Code:  0x80000006.

   Request parameters:

       [ DEAD-CONTACT DEAD-AOR DEAD-ZONE

       [ PEER-CONTACT PEER-AOR PEER-ZONE PEER-VOLUME

   Semantic:  candidate a peer for taking over a zone.

   Routing:  end-to-end, MUST NOT be routed.




























Marocco & Ivov          Expires December 17, 2007              [Page 36]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


6.  Security Considerations

   It is possible to identify (at least) four different categories of
   security issues:

   1.  XPP transport issues, that can be addressed by securing the
       transport channels using a mechanism like DTLS [RFC4347];

   2.  eavesdropping and message forgery of SIP and media traffic by
       seemingly benign peers.  While media can be encrypted using SRTP
       [RFC3711], SIP end-to-end security is still an open issue;

   3.  unsolicited XPP session establishments.  Procedures for join and
       recovery are defined so that any peer needs to allow session
       establishments to peers whose identity have already been
       presented by one of its neighbors.  Such a mechanism builds a
       sort of "overlay trust", which requires further investigation,
       because, while it seems one of the most powerful techniques for
       managing authorization in peer-to-peer environments, it could be
       exploited by malicious peers that have entered the overlay
       through an error or deceit;

   4.  overlay damages caused by malicious peers.  This kind of issue is
       characteristic for peer-to-peer systems and, in general, is the
       hardest to deal with.  However, with the "passive" approach, a
       malicious node cannot determine when it will become peer, which
       zone of the overlay it will be assigned and can only cause
       damages proportional to the area under its authority; moreover,
       implementations can apply their own methods, possibly based on
       both performance and social information, to filter malicious
       nodes and select the best ones to upgrade.




















Marocco & Ivov          Expires December 17, 2007              [Page 37]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


7.  IANA Considerations

   This document makes use following values which need to be registered
   with IANA:

   1.  'pcan' SIP option tag.













































Marocco & Ivov          Expires December 17, 2007              [Page 38]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


8.  Open Issues

   1.  Other than peer identities, credentials for authentication should
       be exchanged too.  How to do that?

   2.  Can clients allow other clients to establish SIP outbound flows
       with them?  In case, they need to implement RFC3327, don't they?

   3.  For the time being this document does not define the amount of
       time that peers should keep state information about routed
       requests, and whether this should be indicated in the requests.
       Shouldn't this be the case?

8.1.  Data Replication

   So far, this document only specifies the algorithm necessary for
   maintaining a consistent overlay structure, and does not deal with
   data reliability.  Up to now, the most promising approach seems to be
   the following:

   1.  upon reception of a PUT request, a peer may send REPLICA requests
       (syntactically identical to PUT) to a set of neighbors that
       answer some reliability conditions (e.g. have been up for more
       than a certain amount of time).

   2.  upon reception of a REPLICA request, a peer stores the data in an
       local "replica" hash table;

   3.  when a peer changes the state of one of its neighbor zones from
       STABILIZING to BORDERING (when timer TC3 fires during a takeover
       process), it sends a PUT request to the election winner with all
       the replicated records that belong to the zone it recovered.



















Marocco & Ivov          Expires December 17, 2007              [Page 39]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


9.  Acknowledgments

   This document is a mere description of what has been implemented
   initially in SIPDHT [WWW.sipdht] and then in SIP Communicator
   [WWW.sip-communicator] opensource projects.  Thanks to all the smart
   developers contributing there; special thanks to Stefano Marengo, who
   wrote almost all the code in the second version of SIPDHT.

   Thanks also to many people working in IETF for providing input in
   various discussions; thanks in particular to Vijay Gurbani, Henning
   Schulzrinne and Salman Abdul Baset for giving useful feedback in the
   very initial phase of this work.







































Marocco & Ivov          Expires December 17, 2007              [Page 40]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


10.  References

10.1.  Normative References

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-12 (work in progress),
              March 2007.

   [I-D.ietf-sip-outbound]
              Jennings, C. and R. Mahy, "Managing Client Initiated
              Connections in the Session Initiation Protocol (SIP)",
              draft-ietf-sip-outbound-07 (work in progress),
              January 2007.

   [I-D.marocco-p2psip-xpp]
              Marocco, E. and E. Ivov, "Extensible Peer Protocol (XPP)",
              draft-marocco-p2psip-xpp-00 (work in progress), June 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, December 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

10.2.  Informative References

   [I-D.baset-sipping-p2pcommon]
              Baset, S., "A Protocol for Implementing Various DHT
              Algorithms", draft-baset-sipping-p2pcommon-00 (work in
              progress), October 2006.

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., "Simple Traversal Underneath Network



Marocco & Ivov          Expires December 17, 2007              [Page 41]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


              Address Translators (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-05 (work in progress),
              October 2006.

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

   [I-D.willis-p2psip-concepts]
              Willis, D., Bryan, D., Matthews, P., and E. Shim,
              "Concepts and Terminology for Peer to Peer SIP",
              draft-willis-p2psip-concepts-00 (work in progress),
              June 2006.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [WWW.columbia.skype]
              Baset, S. and H. Schulzrinne, "An Analysis of the Skype
              Peer-to-Peer Internet Telephony Protocol",
              <http://www1.cs.columbia.edu/~salman/publications/skype1
              _4.pdf>.

   [WWW.icir.can]
              Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S.
              Shenker, "A Scalable Content-Addressable Network",
              <http://www.icir.org/sylvia/cans.ps>.

   [WWW.microsoft.pastry]
              Rowstron, A. and P. Druschel, "Pastry: Scalable,
              decentralized object location and routing for large-scale
              peer-to-peer systems",
              <http://research.microsoft.com/~antr/PAST/pastry.pdf>.

   [WWW.mit.chord]
              Stoica, I., Morris, R., Karger, D., and Frans Kaashoek,
              M., "Chord: A Scalable Peer-to-peer Lookup Service for
              Internet Applications",



Marocco & Ivov          Expires December 17, 2007              [Page 42]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


              <http://pdos.csail.mit.edu/papers/chord:sigcomm01/chord_
              sigcomm.pdf>.

   [WWW.rice.kademlia]
              Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
              Information System Based on the XOR Metric",
              <http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf>.

   [WWW.sip-communicator]
              "SIP Communicator - the Java VoIP and Instant Messaging
              client", <https://sip-communicator.dev.java.net/>.

   [WWW.sipdht]
              "SIPDHT: A SIP-based Distributed Hash-table",
              <http://sipdht.sourceforge.net>.




































Marocco & Ivov          Expires December 17, 2007              [Page 43]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 2007


Authors' Addresses

   Enrico Marocco
   Telecom Italia
   Via G. Reiss Romoli, 274
   Turin  10148
   Italy

   Email: enrico.marocco@telecomitalia.it


   Emil Ivov
   Louis Pasteur University and SIP Communicator
   4 rue Blaise Pascal
   Strasbourg Cedex  F-67070
   France

   Email: emcho@sip-communicator.org

































Marocco & Ivov          Expires December 17, 2007              [Page 44]


Internet-Draft      Passive CAN-based P2PSIP Overlay           June 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).





Marocco & Ivov          Expires December 17, 2007              [Page 45]


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