idnits 2.17.1 draft-marocco-p2psip-xpp-pcan-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1902. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5999 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-12 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-07 ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-05 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 == Outdated reference: A later version (-04) exists of draft-willis-p2psip-concepts-00 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track E. Ivov 5 Expires: May 19, 2008 L. Pasteur University/SIP 6 Communicator 7 November 16, 2007 9 XPP Extensions for Implementing a Passive P2PSIP Overlay Network based 10 on the CAN Distributed Hash Table 11 draft-marocco-p2psip-xpp-pcan-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 19, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines a set of extensions for the Extensible Peer 45 Protocol (XPP) required for creating a P2PSIP overlay network based 46 on the CAN distributed hash table algorithm. It specifies how peers 47 and clients must behave in order to maintain the overlay and use it 48 for the establishment of multimedia communication sessions. 50 To limit the overhead due to maintenance operations and to allow the 51 adoption of security policies for preventing malicious nodes to 52 damage the overlay, joins are always initiated and controlled by 53 existing peers (hence the passive in PCAN). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. The Passive Approach . . . . . . . . . . . . . . . . . . . 5 59 1.2. Why CAN? . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 61 2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 8 62 2.1. General Design . . . . . . . . . . . . . . . . . . . . . . 8 63 2.2. Peer Join . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.3. Failure Recovery . . . . . . . . . . . . . . . . . . . . . 10 65 2.4. Stabilization . . . . . . . . . . . . . . . . . . . . . . 11 66 2.5. Data Replication . . . . . . . . . . . . . . . . . . . . . 11 67 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Peer Behavior . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.1. Key-Point Mapping . . . . . . . . . . . . . . . . . . . . 13 70 4.2. Internal State . . . . . . . . . . . . . . . . . . . . . . 13 71 4.2.1. Zone States . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.2. Neighbor Evaluation for Takeover . . . . . . . . . . . 18 73 4.2.3. Stabilization Procedure . . . . . . . . . . . . . . . 19 74 4.3. Routing XPP Messages . . . . . . . . . . . . . . . . . . . 20 75 4.4. Handling SIP Registrations . . . . . . . . . . . . . . . . 20 76 4.5. Routing SIP Requests . . . . . . . . . . . . . . . . . . . 21 77 4.6. Inviting a Client to Join . . . . . . . . . . . . . . . . 22 78 4.7. Generating PUT Operation Requests . . . . . . . . . . . . 23 79 4.8. Handling PUT Operation Requests . . . . . . . . . . . . . 23 80 4.9. Generating GET Operation Requests . . . . . . . . . . . . 24 81 4.10. Handling GET Operation Requests . . . . . . . . . . . . . 24 82 4.11. Generating REPLICA Operation Requests . . . . . . . . . . 24 83 4.12. Handling REPLICA Operation Requests . . . . . . . . . . . 25 84 4.13. Generating QUERY Operation Requests . . . . . . . . . . . 25 85 4.14. Handling QUERY Operation Requests . . . . . . . . . . . . 25 86 4.15. Generating UPDATE Operation Requests . . . . . . . . . . . 26 87 4.16. Handling UPDATE Operation Requests . . . . . . . . . . . . 27 88 4.17. Generating JOIN Operation Requests . . . . . . . . . . . . 27 89 4.18. Handling JOIN Operation Requests . . . . . . . . . . . . . 27 90 4.19. Generating TAKEOVER Operation Requests . . . . . . . . . . 28 91 4.20. Handling TAKEOVER Operation Requests . . . . . . . . . . . 28 92 5. XPP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 93 5.1. Parameter Formats . . . . . . . . . . . . . . . . . . . . 29 94 5.1.1. Integer . . . . . . . . . . . . . . . . . . . . . . . 29 95 5.1.2. String . . . . . . . . . . . . . . . . . . . . . . . . 29 96 5.1.3. String List . . . . . . . . . . . . . . . . . . . . . 30 97 5.1.4. Point . . . . . . . . . . . . . . . . . . . . . . . . 30 98 5.1.5. Zone . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 32 100 5.2.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 5.2.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . 33 102 5.2.3. BINDING-ID . . . . . . . . . . . . . . . . . . . . . . 33 103 5.2.4. EXPIRES . . . . . . . . . . . . . . . . . . . . . . . 33 104 5.2.5. TARGET . . . . . . . . . . . . . . . . . . . . . . . . 33 105 5.2.6. SPACE . . . . . . . . . . . . . . . . . . . . . . . . 33 106 5.2.7. OWN-AOR . . . . . . . . . . . . . . . . . . . . . . . 33 107 5.2.8. OWN-CONTACT . . . . . . . . . . . . . . . . . . . . . 34 108 5.2.9. OWN-ZONE . . . . . . . . . . . . . . . . . . . . . . . 34 109 5.2.10. YOUR-ZONE . . . . . . . . . . . . . . . . . . . . . . 34 110 5.2.11. PEER-AOR . . . . . . . . . . . . . . . . . . . . . . . 34 111 5.2.12. PEER-CONTACT . . . . . . . . . . . . . . . . . . . . . 35 112 5.2.13. PEER-ZONE . . . . . . . . . . . . . . . . . . . . . . 35 113 5.2.14. PEER-VOLUME . . . . . . . . . . . . . . . . . . . . . 35 114 5.2.15. DEAD-AOR . . . . . . . . . . . . . . . . . . . . . . . 35 115 5.2.16. DEAD-CONTACT . . . . . . . . . . . . . . . . . . . . . 35 116 5.2.17. DEAD-ZONE . . . . . . . . . . . . . . . . . . . . . . 36 117 5.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 36 118 5.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 36 119 5.3.2. GET . . . . . . . . . . . . . . . . . . . . . . . . . 36 120 5.3.3. REPLICA . . . . . . . . . . . . . . . . . . . . . . . 37 121 5.3.4. QUERY . . . . . . . . . . . . . . . . . . . . . . . . 37 122 5.3.5. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 37 123 5.3.6. JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 38 124 5.3.7. TAKEOVER . . . . . . . . . . . . . . . . . . . . . . . 38 125 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 127 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 128 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 129 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 130 10.1. Normative References . . . . . . . . . . . . . . . . . . . 43 131 10.2. Informative References . . . . . . . . . . . . . . . . . . 43 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 133 Intellectual Property and Copyright Statements . . . . . . . . . . 47 135 1. Introduction 137 This document describes a possible solution for a P2PSIP Overlay 138 Network [I-D.willis-p2psip-concepts] currently implemented in the 139 SIPDHT [WWW.sipdht] open source project. The passive approach that 140 the solution adopts is relatively uncommon in related work. Yet it 141 seems to be well-suited for addressing issues arising from the wide 142 spread deployment of NAT devices, high churn rate and possible 143 participation of malicious peers. This solution is intended to: 145 o easily support deployments where many peers are located behind NAT 146 boxes, adopting NAT traversal mechanisms such as STUN 147 [I-D.ietf-behave-rfc3489bis] and ICE [I-D.ietf-mmusic-ice]; 149 o provide mechanisms for keeping overlay size to an optimal minimum. 150 Allowing peers located behind NAT devices to become members of the 151 the overlay network implies frequent exchange of keep alive 152 messages. XPP-PCAN addresses this issue by only allowing the best 153 available clients (i.e. those offering most significant resources) 154 and doing so only when their participation is really necessary. 156 o provide mechanisms for limiting the effects of malicious nodes 157 attempting to degrade the service. 159 XPP-PCAN is based on the following key points: 161 1. the overlay is organized as a distributed database or hash table 162 based on the CAN [WWW.icir.can] algorithm and it only offers 163 functionalities for storing and retrieving data and for routing 164 SIP [RFC3261] messages; 166 2. the P2P overlay is transparent to clients. A client can maintain 167 SIP outbound flows [I-D.ietf-sip-outbound] and register its 168 location with any peer (causing the insertion of a routing record 169 on the peer authoritative for its address); 171 It would also be possible for clients, not participating in 172 the overlay, to allow others to maintain outbound flows with 173 them, as this would significantly lighten the load of the 174 overlay. At the moment such an option has been put aside for 175 simplicity, but is listed as an open issue. 177 3. peers use XPP [I-D.marocco-p2psip-xpp] for performing maintenance 178 operations; 180 4. peers use SIP (and possibly ICE) for establishing XPP sessions; 181 5. for every client using the overlay there is at least one 182 registrar peer that the client uses as point of attachment to the 183 overlay, and one authoritative peer (the one keeping location and 184 routing information for the client (in some cases the two may 185 coincide). 187 6. a peer can invite any client it is authoritative for to join the 188 overlay. 190 Once again, one of the main characteristics of XPP-PCAN is the fact 191 that it is not possible for a node to decide whether it would simply 192 use the overlay network as a client or become a part of it as a peer. 193 One could therefore imagine the network as a free service which, in 194 some cases, could invite any of its clients to provide resources for 195 use by others. Answering positively to an invitation is the only way 196 for a client to become a peer. 198 It is worth noting that points 1 and 4 allow peers and clients to 199 use the SIP routing functionality provided by the overlay for 200 establishing XPP sessions, which, in turn, are needed for 201 maintaining the overlay itself. 203 The remainder of this document, after giving a short overview of the 204 CAN-based algorithm, specifies XPP extensions and defines operations 205 each peer must perform in order to consistently maintain the overlay. 206 However, it does not specify how a peer decides to invite a client to 207 join the overlay; implementations must apply their own criteria for 208 deciding both when and which node to invite. 210 1.1. The Passive Approach 212 Networks using XPP-PCAN would manage joins in a "passive" way, and 213 only allow nodes to become members of the overlay once they have been 214 invited by existing peers. Overlays, used by file-sharing 215 applications, would generally adopt the opposite approach and let 216 clients decide whether or not to become peers. A well known 217 exception to this trend is the Skype network [WWW.columbia.skype], 218 arguably one of the most popular overlay networks used for real-time 219 communications today. Instances of the Skype application may operate 220 as super-nodes or ordinary-nodes and the "promotions" are decided by 221 the higher levels of the hierarchy. 223 The passive approach seems appropriate for P2PSIP because: 225 o all peer candidates are actually clients that have already 226 registered with the service and are therefore known to the 227 overlay. 229 o the overlay only needs to provide a limited amount of 230 functionalities to clients and these could be handled by a 231 relatively small subset of the nodes that actually use them. 233 o providing SIP connectivity to clients, storing their location, 234 routing messages,in addition to maintaining tens or even hundreds 235 of connections with neighbor peers could be very resource 236 consuming. It is therefore important to confirm availability of 237 such resources prior to inviting a client to join the overlay as a 238 peer. 240 An additional advantage of passive joins is the fact that they allow 241 the overlay to select peers among candidates based virtually any kind 242 of performance and security characteristics. 244 It is possible, for example, to limit the effects of malicious 245 peers by only inviting trusted nodes to join the overlay. 246 Assessing the level of trust could be handled in many different 247 ways like provider maintained white-lists or social networks. 249 1.2. Why CAN? 251 The choice of the distributed hash table algorithm has been heavily 252 influenced by our goal to have robust overlay networks even in cases 253 when many peers are behind a NAT. This requires maintaining 254 persistent connections between peers and CAN fits this requirement 255 quite well, because: 257 1. it is symmetric [I-D.baset-sipping-p2pcommon] (unlike Chord 258 [WWW.mit.chord]). Without such a property, each connection is 259 efficiently used by only one of the endpoints; 261 2. peers maintain a stable routing table with a limited number of 262 entries (which is not the case with Pastry [WWW.microsoft.pastry] 263 and Kademlia [WWW.rice.kademlia]). 265 A possible drawback when using the CAN algorithm is its relatively 266 low performance. While other popular algorithms claim to always be 267 logarithmic in complexity, overlays based on CAN cannot scale 268 indefinitely. CAN based overlays need to be configured during 269 deployment with parameters (e.g the number of dimensions for the hash 270 space) depending on the size of the intended network. 272 However, in the case of P2PSIP, the service could be provided by a 273 subset of interested nodes. This and the possibility to use delay 274 measurements between peers when selecting best routes within the 275 overlay, could help achieving acceptable performance even with a 276 limited number of peers. 278 1.3. Terminology 280 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 281 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 282 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 283 described RFC 2119 [RFC2119]. 285 2. Algorithm Overview 287 The algorithm implemented by the overlay is a version of CAN 288 [WWW.icir.can] slightly customized to fit the "passive" approach. 289 This section briefly describes the overall design and the procedures 290 for routing, joining the overlay and recovery after failures. 291 Section 3 and Section 4 will then define how clients and peers 292 establish and use XPP sessions for implementing these procedures. 294 2.1. General Design 296 The functionality on which the overlay is based, like all other 297 distributed hash table algorithms, is the mapping of keys over the 298 peers. Such a functionality, unlike in algorithms based on the 299 concept of consistent hashing [WWW.mit.chord] [WWW.microsoft.pastry] 300 [WWW.rice.kademlia], is implemented in a virtual d-dimensional 301 Cartesian coordinate space on a d-torus. 303 The d-torus is the generalization of the Chord ring in d 304 dimensions. In fact, while in Chord keys are uni-dimensional and 305 can be represented on a ring (i.e. a circular line), in CAN -- and 306 so in the algorithm described here -- they are at least bi- 307 dimensional and thus require a torus (i.e. a circular plane). 309 A d-dimensional key can easily be obtained by splitting in d parts 310 a uni-dimensional value returned by a common hash function. 312 Any peer is assigned a distinct zone of the overall space and is 313 authoritative for all the keys falling in it. Zones are always 314 defined by the coordinates of their lower left and top right corner, 315 and contain the area locked between the borders including the bottom 316 and left edges (thus excluding the right and top edges). At any 317 point in time, the overlay is consistent if the whole space is 318 completely covered. Figure 1 shows a bi-dimensional space 319 partitioned among 5 peers. 321 A peer maintains XPP sessions with all its immediate neighbors, along 322 with information about the zones they are authoritative for. When a 323 peer receives an operation request for a key which falls out of its 324 zone, it routes the request to the most appropriate neighbor. 326 The most appropriate neighbor is generally the one whose center of 327 mass is closer to the requested key; however, an implementation 328 may also take into account link speed and so select not just 329 according to geometric distance. In any case, in order to avoid 330 loops, peers must not route messages to neighbors which are not 331 geometrically closer to the targeted key. 333 <10, 0> <0, 0> 334 +-----------------*-----------------* 335 | | | 336 | | E | 337 | |<10, 15> |<0, 15> 338 | C *-----------------* 339 | | | 340 | | D | 341 |<0, 10> |<10, 10> |<0, 10> 342 *-----------------*-----------------* 343 | | | 344 | | | 345 | | | 346 | A | B | 347 | | | 348 | | | 349 |<0, 0> |<10, 0> | 350 *-----------------*-----------------+ 352 A bi-dimensional space with 5 peers. For simplicity, the space is 353 shown in two dimensions. In reality the figure is actually a torus. 355 Figure 1 357 2.2. Peer Join 359 The decision when to invite a client to join the overlay is always 360 taken by existing peers. After choosing the best candidate to 361 "promote", the inviting peer would either select a fragment recovered 362 from a dead neighbor (see Section 2.3) or obtain a new one by 363 splitting its zone through the longest edge into two equal parts. It 364 would then assign the new fragment to the entering peer. 366 The selection process of the candidate to invite may be based on 367 the evaluation of parameters like bandwidth, connectivity, uptime 368 and trust; such a process strongly depends on the deployment and 369 is outside the scope of this document. 371 It is worth noting that, in the case of P2PSIP, a peer may choose 372 the most appropriate node to invite among the clients it stores a 373 registration for, that is the client whose address fall under its 374 authority. 376 After identifying the zone and the node to invite, the inviting peer 377 sends a SIP INVITE request to the new peer and establishes an XPP 378 session. Once the XPP session established, the join is completed in 379 the following six steps: 381 1. the inviting peer transfers to the new peer all data bound to 382 keys located in the new zone; 384 2. the inviting peer notifies all the neighbors of the zone being 385 transferred that a peer is about to join, and that they should be 386 ready to establish XPP sessions with their new neighbor; 388 3. if the zone of the inviting peer has been split, it notifies all 389 its current neighbors of its new coordinates; 391 4. the inviting peer sends to the invitee the list of all neighbors 392 it will have after joining the overlay; 394 5. the entering peer establishes XPP sessions with all its new 395 neighbors using SIP; 397 6. the inviting peer updates its neighbor list and ends all XPP 398 sessions with peers which are no longer its neighbors. 400 2.3. Failure Recovery 402 When a peer fails, one or more zones of the overlay need to be 403 recovered through a distributed election. Elections are run by peers 404 neighboring orphaned zones. The exact algorithm is describe in 405 Section 4.2.2. 407 When a peer loses connectivity with one of is neighbors, it starts a 408 timer waiting for other neighbors to also detect the failure. The 409 exact value of the timer depends on XPP timers and must therefore be 410 greater than the maximum allowed interval between two subsequent keep 411 alive responses plus the time necessary for neighbors to complete 412 retransmissions of their last keep alive message. When the timer 413 fires, the peers would start the election algorithm. 415 At this point all neighbors of the failed peer start exchanging 416 messages for electing the one to take over the orphaned zone. Every 417 one of them would store the identity of the most appropriate 418 candidate it sees and, after a stabilization interval Section 4.2.1, 419 consider it authoritative on that zone. 421 When a peer is elected for taking over a zone, it is likely that it 422 does not know all of its new neighbors; if this is the case, it must 423 query the neighbors it knows in order to discover new ones and 424 establish XPP connections with them. 426 2.4. Stabilization 428 Race conditions, temporary transport failures and misbehaving peers 429 may cause inconsitencies in the topology of the network. Such 430 inconsistencies most often result in neighbor peers have different 431 representations of the geometry of a certain number of bordering 432 zones. 434 A simple yet efficient stabilization procedure to realign the 435 internal state of a peer with that of its neighbors is accomplished 436 querying all peers in the neighborhood and checking that their 437 geometrical view is consistent with that of the querying peer. Any 438 time an incosistency is detected (i.e. the querying peer discovers a 439 zone whose owner differs from the one it had recorded or whose 440 coordinates overlap with some zones it is aware of), it is resolved 441 on a popularity basis, aligning the internal state with the 442 information reported by the highest number of peers. 444 2.5. Data Replication 446 Persistency of data against peer failures is achieved by making each 447 peer replicate its local hash table on an arbitrary number of 448 neighbors. Upon a peer failure, right after the recovery procedure 449 described in Section 2.3 has completed, all peers which where 450 neighbor of the failed peer check in their replica tables if they 451 have records which are under the authority of the peer elected as the 452 new owner of the recovered zone; if they find any, they immediately 453 send records back to the new peer. 455 As long as peers consistently choose their replica holders (i.e. they 456 send records bound to the same keys always to the same peers whenever 457 this is possible), such a mechanism can recover the data stored by a 458 failed peer unless all its neighbors storing a replica of that data 459 fail at the same time. 461 3. Client Behavior 463 The overlay is intended to be transparent to conventional SIP user 464 agents. Once such a client has discovered the location of one or 465 more peers (how exactly it has done so is outside the scope of this 466 document), it MAY set any of them as its outbound proxy. It SHOULD 467 then register using the peer as a registrar and following the 468 registration procedures described in [RFC3261] and. If needed, the 469 SIP client MAY direct SIP outbound flows [I-D.ietf-sip-outbound] to 470 this peer in order to allow NAT traversal for SIP messages. 472 If the client wants to be able to join the overlay, it MUST use a SIP 473 contact which routes to itself from each point in the overlay (e.g. a 474 global scope IP address); if it does not have such a contact, it MAY 475 request a public GRUU [I-D.ietf-sip-gruu] from all peers it is 476 sending SIP REGISTER requests to. 478 When additional resources are necessary for the maintenance of the 479 overlay, a client MAY receive a SIP INVITE request asking to join the 480 overlay, as described in Section 4.6. Since such a request MUST list 481 the 'pcan' tag in the 'Require' header field, clients not 482 implementing this specification, will answer with a 420 (Bad 483 Extension) error message, as specified in [RFC3261]. 485 4. Peer Behavior 487 4.1. Key-Point Mapping 489 At any point in time, every peer is authoritative for one or more 490 geometric zones, which means that it is responsible for storing all 491 data bound to keys that correspond to points in these zones. 493 In order to obtain the coordinates of a d-dimensional point, one has 494 to split into 'd' equal components the 20 byte-long hash string 495 returned by applying the SHA-1 [RFC3174] function on the key stripped 496 of any URI parameters (i.e. all characters up to the first occurrence 497 of a semi-colon - ';'). 499 The number of components MUST be equal to the number of dimensions 500 indicated in the initial JOIN request; allowed values are 2, 4, 5 501 and 10. 503 4.2. Internal State 505 The state of a peer participating in an overlay can be represented as 506 a list of zones the local peer is authoritative for or which border 507 on zones the local peer is authoritative for. For each zone, a peer 508 MUST store the SIP address-of-record and contact of the responsible 509 peer, the coordinates of the geometric area and a state variable 510 which can be set according to the state diagram in Figure 2. When 511 keeping track of the states of all neighbor zones (as defined in 512 Section 4.2.1), a peer MAY assign each one of them one of three 513 timers -- timer TC1, timer TC2 or timer TC3. 515 Timers are named TC1, TC2 and TC3 for differentiating from XPP 516 timers T1, T2 and T3. 518 At any point in time a peer SHOULD have active XPP sessions with all 519 its neighbors. It MUST handle failures occurring in such sessions as 520 explained in Section 4.2.1. 522 4.2.1. Zone States 524 Every peer maintains a list of all zones bordering on its own. Every 525 such zone may be in one of the following states. 527 +-----------+ 528 +------| | 529 TAKEOVER | | BORDERING |<-------------------------+ 530 +----->| | | 531 +-----------+ Timer TC3 | 532 +-----+ JOIN of ^ | fires | 533 | | a new peer | | | 534 +--------| OWN |-------------+ | | 535 | | | | | 536 | +-----+ | | 537 | Timer | | 538 | TC2 fires Failure | | 539 | detection | | 540 | event | | 541 | v | 542 | +---------------+ | 543 | | | | 544 | Timer TC1 fires +---| SYNCHRONIZING |------+ TAKEOVER and | 545 | or TAKEOVER and | | | | local peer is | 546 | local peer is | +---------------+ | not appropriate | 547 | appropriate | | | 548 | | | | 549 | | | | 550 | v v | 551 | +-----------+ +-------------+ | 552 | | | | | | 553 +-------------| ACQUIRING |--------------->| STABILIZING |-------+ 554 | | TAKEOVER and | | 555 +-----------+ and local peer +-------------+ 556 ^ | not appropr. ^ | 557 | | | | 558 +-------+ +-------+ 559 TAKEOVER TAKEOVER 560 and local peer 561 is appropriate 563 Zone state diagram. 565 Figure 2 567 The states have the following meaning: 569 o BORDERING: a neighbor peer is authoritative for the zone and the 570 XPP session with this peer is active. 572 o SYNCHRONIZING: the neighbor authoritative for the zone is 573 unreachable. The peer waits until all neighbors detect the 574 failure. 576 o STABILIZING: a neighbor has been elected to take over the orphan 577 zone. The local peer is waiting to make sure that no one else 578 claims ownership of this zone. 580 o ACQUIRING: the local peer is about to take over a zone but it is 581 still waiting in case a more appropriate neighbor would claim it. 583 o OWN: the local peer is authoritative for the zone. 585 In most cases, zones would be in either an OWN or a BORDERING state. 586 States like SYNCHRONIZING, STABILIZING and ACQUIRING are only entered 587 when a failure is detected and a zone needs to be taken over by 588 another peer. The recovery algorithm uses three timers -- TC1, TC2, 589 and TC3 -- and is completed through several exchanges of TAKEOVER 590 messages. A peer MUST therefore be able to handle five different 591 events for each of its neighbor zones, as defined in the remainder of 592 this section. The transition from state OWN to BORDERING, which 593 occurs only when a new peer joins the overlay, is separately 594 described in Section 4.6. 596 4.2.1.1. Failure Detection Event 598 The event is fired when an XPP session between the local peer and one 599 of its neighbors has failed. Upon According to the state that the 600 neighbor zone had in the local zone list the local peer would do one 601 of the following: 603 State: BORDERING 605 Set the zone state to SYNCHRONIZING; Start Timer TC1 for this zone 606 and set it to 'tc1'. The 'tc1' value is proportional to the total 607 volume of the zones under the authority of the local peer and always 608 greater than the maximum time required for detecting a failure. Such 609 a value MUST be calculated using the following formula (where r, t0, 610 t1 and t2 are values used for handling retransmissions and keep alive 611 in XPP [I-D.marocco-p2psip-xpp], v is the total volume under the 612 authority authority of the local peer and V is the volume of the 613 whole hash space): 615 r' = min(ceil(log2(t1/t0)), r) 617 tc0 = t0 * 2 ^ r' + (r - r') * t1 + t2 618 tc1 = tc0 * (1 + v / V) 620 State: SYNCHRONIZING, STABILIZING, ACQUIRING or OWN 622 Not possible. 624 4.2.1.2. Timer TC1 Event 626 State: SYNCHRONIZING 628 Set the zone state to ACQUIRING; start Timer TC2 with value tc2 629 (default: 6 seconds) and send a TAKEOVER operation request to all 630 neighbors which are also neighbors of the zone to recover. The 631 Takeover request MUST be generated as defined in Section 4.19. 633 State: BORDERING, STABILIZING, ACQUIRING or OWN 635 Not possible. 637 4.2.1.3. Timer TC2 Event 639 State: ACQUIRING 641 Set the zone state to OWN; the local peer is authoritative for the 642 orphaned zone and the recovery algorithm is terminated. All 643 neighbors are aware of the new owner, but the local peer may need to 644 discover and establish XPP sessions with new neighbors acquired as a 645 result of the recovery, and to notify its neighbors about possible 646 changes in the geometry due to one or more merges between its 647 previous zones and the recovered one. 649 New neighbors MUST be discovered sending QUERY operation requests to 650 known neighbors, as defined in Section 4.13. The local peer MUST 651 establish XPP sessions with all discovered neighbors using SIP. 653 A peer MUST NOT establish XPP sessions with peers it does not 654 know; however, after the recovery process, all neighbors of the 655 dead zone will know the identity of the new peer and MUST accept 656 incoming SIP requests from it. 658 If the recovered zone is mergeable with any of the zones previously 659 owned by the local peer (i.e. they share an edge in 2-dimensional 660 spaces, a plane in 3-dimensional ones and so on), all the neighbors 661 MUST be notified of the merge through an UPDATE operation requests, 662 as defined in Section 4.15. 664 State: BORDERING, SYNCHRONIZING, STABILIZING or OWN 665 Not possible. 667 4.2.1.4. TAKEOVER Operation Request Event 669 State: BORDERING 671 Leave the zone in a BORDERING state; send back a TAKEOVER operation 672 request on behalf of the peer authoritative for the zone. The 673 TAKEOVER request MUST be generated as defined in Section 4.19. 675 This event would only occur when the failure is only detected by 676 some of the neighbors, while others are still able to communicate 677 with the peer. 679 State: SYNCHRONIZING 681 If, according to the rules defined in Section 4.2.2, the local peer 682 is more appropriate than the one sending the TAKEOVER request, set 683 the zone state to ACQUIRING; cancel Timer TC1, set Timer TC2 with 684 value tc2 (default: 6 seconds) and send a TAKEOVER operation request 685 to all neighbors that are also neighbors of the zone to recover. The 686 TAKEOVER request MUST be generated as defined in Section 4.19. 688 Otherwise, if the local peer is less appropriate than the one sending 689 the TAKEOVER request, set the zone state to STABILIZING; cancel Timer 690 TC1, set Timer TC3 with value tc3 (default: 4 seconds), temporary 691 store the identity of the peer candidate to take over the zone and 692 send a TAKEOVER operation request to all neighbors which are also 693 neighbors of the zone to recover on behalf of such peer. The 694 TAKEOVER MUST be generated as defined in Section 4.19. 696 State: ACQUIRING 698 If, according to the rules defined in Section 4.2.2, the local peer 699 is more appropriate than the one reported in the TAKEOVER request, 700 keep the zone state as ACQUIRING; reset Timer TC2 to value tc2 701 (default: 6 seconds) and send a TAKEOVER operation request to all 702 neighbors that are also neighbors of the zone to recover. The 703 TAKEOVER request MUST be generated as defined in Section 4.19. 705 Otherwise, if the local peer is less appropriate than the one 706 reported in the TAKEOVER request, set the zone state to STABILIZING; 707 cancel Timer TC2, start Timer TC3 for a period of tc3 (default: 4 708 seconds), store the identity of the peer as the best candidate to 709 take over the zone and send a TAKEOVER operation request to all 710 neighbors which are also neighbors of the zone to recover on behalf 711 of such peer. The TAKEOVER MUST be generated as defined in 712 Section 4.19. 714 State: STABILIZING 716 If, according to rules defined in Section 4.2.2, the peer previously 717 stored as the best candidate is more appropriate than the one 718 reported in the TAKEOVER request, keep the zone in a STABILIZING 719 state; reset Timer TC3 to tc3 (default: 4 seconds) and, on behalf of 720 the old candidate, send TAKEOVER requests to all neighbors that are 721 also neighbors of the zone to recover. The TAKEOVER request MUST be 722 generated as defined in Section 4.19. 724 If the peer previously stored as the best candidate is less 725 appropriate than the one reported in the TAKEOVER request, stay in 726 STABILIZING; reset Timer TC3 with value tc3 (default: 4 seconds), 727 store the identity of the latter as the best candidate and send a 728 TAKEOVER operation request to all neighbors which are also neighbors 729 of the zone to recover on behalf of such peer. 731 Otherwise, if the peer previously stored as the best candidate is the 732 same as the one reported in the TAKEOVER request, keep the zone in a 733 STABILIZING state and do nothing further. 735 State: OWN 737 Not possible. 739 4.2.1.5. Timer TC3 Event 741 State: BORDERING, SYNCHRONIZING, ACQUIRING or OWN 743 Not possible. 745 STABILIZING 747 Set the zone state to BORDERING; set the peer that has qualified as 748 the best candidate as the new owner of the zone. 750 The local peer may or may not have a connection with the new 751 neighbor; in case it doesn't, it MUST be ready to accept a request 752 for establishing one. 754 4.2.2. Neighbor Evaluation for Takeover 756 In order to determine whether one peer is more appropriate than 757 another for taking over a zone, a list of conditions need to be taken 758 into account in the following order: 760 1. if one of the peers is the current owner (e.g. the failure was 761 temporary or just limited to some connections), it wins the 762 election; 764 2. if only one of the peers can merge the uncovered zone with its 765 own, it wins the election. Note: two zones can be merged if they 766 share a border component (an edge for 2d, a surface for 3d and so 767 on); 769 3. if the sums of the zone volumes are different for the two peers, 770 the one with the smallest value wins the election; 772 4. if none of the above produces a winner, the peer with the first 773 identity in lexicographic order wins the election. 775 4.2.3. Stabilization Procedure 777 Since misbehaving peers, race conditions and temporary network 778 failures may cause inconsistencies in their internal state, peers 779 SHOULD periodically execute the following procedure in order to be 780 sure it is coherent with that of their neighbors: 782 1. send a QUERY operation request targeted to each zone bordering on 783 any of its own zone; 785 2. on reception of a QUERY operation response, update a temporary 786 list for each of the reported zones: 788 * if an equivalent zone with the same owner cannot be found in 789 the list, insert it and assign a default initial score value; 791 * if an equivalent zone with the same owner can be found in the 792 list, increase its score value; 794 3. when QUERY operation responses have been received for all sent 795 requests, resolve conflicting zones (i.e. zones with equal 796 coordinates but different owners or zones with overlapping 797 coordinates) keeping in the temporary list the one with the 798 higher score value and dropping the other; 800 4. remove from the termorary list all zones conflicting with any 801 zone in the effective list whose state is not BORDERING; 803 5. update the internal state replacing in the effective zone list 804 all zones in BORDERING state with those in the temporary list. 806 4.3. Routing XPP Messages 808 When a peer receives a GET, a PUT or a QUERY operation request for a 809 key or a target which is not contained in any of its zones, it MUST 810 route it to the most appropriate neighbor. 812 The most appropriate neighbor is generally the one whose center of 813 mass is closest to the target; however, an implementation MAY also 814 take in account link speed and so select not just according to 815 geometric distance. In any case, in order to avoid loops, peers 816 MUST NOT route messages to neighbors which are not geometrically 817 closer than them to the destination zone. 819 XPP responses MUST be returned through the path that the originating 820 request came through. When routing an XPP request, a peer MUST 821 therefore locally store information for routing responses back on the 822 same session it was received. Neither the XPP specification 823 [I-D.marocco-p2psip-xpp] nor this document currently define for how 824 long peers should keep state information about routed requests (this 825 is for the moment an open issue, listed in (Section 8). However, it 826 is still worth noting that as GET and PUT operations are supposed to 827 be used for handling SIP transactions, it is RECOMMENDED that such an 828 interval is not shorter than 32 seconds. 830 4.4. Handling SIP Registrations 832 All peers MUST be able to process SIP REGISTER requests sent directly 833 by clients or routed by other peers in the overlay's domain, and 834 update routing records in the distributed database with XPP PUT 835 operations (see Section 4.7). Moreover, to overcome issues related 836 to connectivity restrictions, such as NAT devices, peers MUST support 837 the SIP outbound [I-D.ietf-sip-outbound] and GRUU [I-D.ietf-sip-gruu] 838 extensions. 840 If the Contact header field in the incoming REGISTER contains the 841 'reg-id' parameter, the connection from which it was received MUST be 842 kept alive as described in [I-D.ietf-sip-outbound] and the routing 843 record MUST consist of a path where the first element is the URI 844 identifying the peer (a SIP contact or a GRUU), the last element is 845 the value in the Contact header field, and the elements in between 846 are copied from those read in the Path header field [RFC3327], if one 847 is set. Otherwise, if the registration does not require outbound 848 support, the record MUST only contain the first value in the Contact 849 header field. 851 If the REGISTER request has a Supported or Require header field 852 containing the 'gruu' tag, the peer MUST generate a GRUU appending a 853 'gr' parameter with a value equal to the instance ID (reported in the 854 '+sip.instance' parameter in the Contact header field) to the 855 address-of-record of the registering peer. In such cases, the peer 856 MUST insert records for both the address-of-record and the GRUU into 857 the distributed database, and return the GRUU in the SIP response as 858 specified in [I-D.ietf-sip-gruu]. 860 It is worth mentioning that, according to mapping rules in 861 Section 4.1, the same peer will be authoritative on both the GRUU 862 and the address-of-record. 864 In general, a peer handling a REGISTER request is not necessarily the 865 one storing the corresponding routing record; A registrar peer MUST 866 send an XPP PUT operation request as described in Section 4.7 and 867 wait for the XPP response to generate the SIP response. Since the 868 XPP request could silently fail, if a response is not received after 869 a "reasonable" time, it SHOULD close the SIP transaction with a 504 870 "Server Time-out" error code. 872 The "reasonable" time period depends on several parameters, such 873 as the overlay size and the transport protocol used for the SIP 874 registration. It is RECOMMENDED that, if the REGISTER request was 875 sent over UDP, such period is shorter than SIP's Timer F value 876 (default: 32 seconds) [RFC3261]. The matter is still considered 877 an open issue (Section 8). 879 4.5. Routing SIP Requests 881 When a peer receives a SIP request not addressed to itself and with 882 no Route header field set, it MUST first determine if the target (the 883 request URI) belongs to the overlay domain. If not, it SHOULD route 884 it according to rules defined in [RFC3263]. Otherwise, if the target 885 of the request is a SIP URI in the overlay domain, it MUST retrieve 886 the routing record bound to the URI in the request line, generating 887 an XPP GET operation request as defined in Section 4.9. 889 The corresponding GET operation response, returned by the peer 890 authoritative for the destination URI, MUST contain the path SIP 891 requests need to follow to reach the target. After receiving the GET 892 operation response, the peer MUST recursively resolve all path 893 components that are represented as URIs belonging to the overlay 894 domain. Next, it MUST add Route header fields reflecting the 895 resolved path and use it to route the request. 897 If the peer does not receive a GET response after a "reasonable" 898 amount of time, it SHOULD close the SIP transaction with a 504 899 "Server Time-out" error code. As already mentioned , this 900 "reasonable" amount of time is currently considered an open issue 901 (Section 8). 903 As noted in Section 4.4, the "reasonable" time interval depends on 904 several parameters, such as the overlay size and the transport 905 protocol used for sending the SIP message. It is RECOMMENDED 906 that, if the SIP request was sent over UDP, such period is shorter 907 than 32 seconds. 909 4.6. Inviting a Client to Join 911 When a peer needs to invite a new client to join the overlay it first 912 needs to select the "best" available among those it stores an active 913 SIP registration for. This document does not specify how it could be 914 done; implementations will apply their own criteria. 916 After identifying the client to invite and a zone to transfer (either 917 one recovered from a dead peer or one obtained by splitting its own), 918 the inviting peer MUST send a SIP INVITE request to the joining 919 client in order to establish an XPP session with it. The INVITE 920 request MUST have a Require header field containing the 'pcan' 921 extension tag and will be routed as specified in Section 4.5. 923 In network environments where it is expected that peers might be 924 located behind NAT devices, the session negotiation SHOULD be 925 completed using the ICE [I-D.ietf-mmusic-ice] mechanism. 927 If the client answers positively and after the XPP session has been 928 correctly established as described in [I-D.marocco-p2psip-xpp], the 929 join procedure would continue through the following steps: 931 1. the inviting peer sends a PUT request generated as described in 932 Section 4.7 to the entering peer for transferring all the data 933 bound to keys located in the new zone; 935 2. the inviting peer sends an UPDATE request to all its neighbors. 936 Generated UPDATE requests is described in Section 4.15. This 937 request would report all zones of authority of the inviting peer 938 as well as the one transferred to the entering peer. Peers 939 receiving an UPDATE request MUST take into account any changes of 940 the overlay topology and, in case they are also going to be 941 neighbors of the new peer, prepare to establish XPP sessions with 942 it. 944 3. the inviting peer then sends a JOIN request generated as 945 described in Section 4.17 to the entering peer. The request 946 contains coordinates of the zone being transfered and the list of 947 its neighbors; 949 4. the entering peer establishes XPP sessions with all its new 950 neighbors using SIP; 952 5. the inviting peer updates its zone list and closes sessions with 953 peers that, as a result of the transfer, are no longer its 954 neighbors. 956 4.7. Generating PUT Operation Requests 958 PUT operations insert key-value pairs in the distributed database. 959 In general, such requests would be used when storing SIP 960 registrations. Every such request is composed of one or more tuples 961 containing: 963 o KEY: a SIP URI, usually an address-of-record or a GRUU 964 [I-D.ietf-sip-gruu]; 966 o VALUE: the route-path SIP messages addressed to the user SHOULD 967 follow; 969 o BINDING-ID: the token identifying the key-value pair instance. 970 Two subsequent PUT operations with same KEY and same BINDING-ID 971 overwrite the same record; two PUT operations with same KEY and a 972 different BINDING-ID would cause the insertion of two different 973 records. For PUT requests generated upon SIP registrations, the 974 BINDING-ID SHOULD contain the value of the Call-ID header field in 975 the REGISTER request; 977 o EXPIRES: the amount of time (in seconds) that the record needs to 978 be kept. 980 It is RECOMMENDED that requests containing more than one tuple are 981 generated only if all tuples fall under the authority of the same 982 peer; this could be the case, for example, during a join 983 (Section 4.6) or when handling a registration requesting a GRUU 984 (Section 4.4). 986 4.8. Handling PUT Operation Requests 988 Upon reception of a PUT operation request, a peer MUST first check if 989 it is responsible for the KEY parameter contained in the first tuple. 990 If it is not, it MUST route the request as defined in Section 4.3; 991 otherwise, for each tuple in the request it is responsible for, it 992 MUST update or insert a record in its local table, respectively if 993 one with same KEY and BINDING-ID previously existed or not. 995 Once stored records it is responsible for, the peer MUST return in a 996 PUT operation response, all records in its local table bound to keys 997 matching one of those contained in the initial request. PUT 998 operation responses are thus syntactically identical to PUT requests 999 (see Section 4.7). 1001 In general, according to replication policies, after storing data a 1002 peer peer SHOULD replicate it on some of its neighbor peers 1003 generating a REPLICA operation request as described in Section 4.11. 1005 Even if the selection of the neighbor peers to send REPLICA 1006 requests to is not important per se, it needs to be consistent in 1007 a way that, whenever possible, REPLICA operation requests for 1008 records bound to the same keys are sent to the same peers. 1010 4.9. Generating GET Operation Requests 1012 GET operation requests retrieve data in the distributed database. 1013 Most often, GET requests would be used when querying the location of 1014 clients and peers for routing SIP messages. Such requests contain 1015 one or more KEY parameters, typically a SIP address-of-record or a 1016 GRUU [I-D.ietf-sip-gruu]. 1018 It is RECOMMENDED that requests containing more than one KEY 1019 parameter be generated only when all keys fall under the authority of 1020 the same peer. 1022 4.10. Handling GET Operation Requests 1024 Upon reception of a GET operation request, a peer MUST first check if 1025 it is responsible for the first KEY parameter. If it is not, it MUST 1026 route the request as defined in Section 4.3; otherwise, it MUST 1027 return in a GET operation response, all records in its local table 1028 bound to keys matching one of those contained in the initial request. 1030 GET operation responses are syntactically identical to PUT responses 1031 (see Section 4.8). 1033 4.11. Generating REPLICA Operation Requests 1035 REPLICA operations insert key-value pairs in the local replica table 1036 of a neighbor peer. In general, such requests would be generated as 1037 a result of handling PUT operation requests. Every such request is 1038 composed of one or more tuples containing: 1040 o KEY: a SIP URI, usually an address-of-record or a GRUU 1041 [I-D.ietf-sip-gruu]; 1043 o VALUE: the route-path SIP messages addressed to the user SHOULD 1044 follow; 1046 o BINDING-ID: the token identifying the key-value pair instance. 1047 Two subsequent REPLICA operations with same KEY and same 1048 BINDING-ID overwrite the same record; two REPLICA operations with 1049 same KEY and a different BINDING-ID would cause the insertion of 1050 two different records. 1052 o EXPIRES: the amount of time (in seconds) that the record needs to 1053 be kept. 1055 4.12. Handling REPLICA Operation Requests 1057 Upon reception of a REPLICA operation request, a peer MUST update or 1058 insert a record in its local replica table, respectively if one with 1059 same KEY and BINDING-ID previously existed or not. 1061 An entry in the local replica table is stored until either it expires 1062 or a new neighbor peer becomes responsible for it. In the latter 1063 case, other than removing from its replica table all entries the new 1064 neighbor is responsible for, the local peer MUST send a PUT operation 1065 request for all the purged entries, as described in Section 4.7. 1067 4.13. Generating QUERY Operation Requests 1069 QUERY operations are used by peers to gather information about the 1070 overlay topology, for example, for discovering new neighbors after a 1071 recovery. QUERY requests consist of one TARGET parameter used for 1072 routing the operation. 1074 4.14. Handling QUERY Operation Requests 1076 Upon reception of a QUERY operation request, a peer MUST first check 1077 if the TARGET parameter belongs to one of the zones it is 1078 authoritative for. If not, it MUST route the request as explained in 1079 Section 4.3; otherwise, it MUST return a representation of the zones 1080 it is aware of in a QUERY response containing: 1082 o a list describing zones the answering peer is authoritative for, 1083 each one containing: 1085 * OWN-CONTACT: contact of the answering peer; 1087 * OWN-AOR: address-of-record the answering peer is registered 1088 for; 1090 * OWN-ZONE: coordinates of the zone; 1092 o [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are 1093 currently redundantly copied in every record. We should fix this 1094 in the next draft version.] 1096 o a list describing zones neighboring those of the answering peer. 1097 Every list entry contains: 1099 * PEER-CONTACT: contact of the neighbor peer; 1101 * PEER-AOR: address-of-record the neighbor peer is registered 1102 for; 1104 * PEER-ZONE: coordinates of the zone. 1106 4.15. Generating UPDATE Operation Requests 1108 UPDATE operations are used for advertising changes in the overlay 1109 topology, such as joins, recoveries or zone merges. UPDATE requests 1110 MUST report information related to zones the sending peer is 1111 authoritative for or is currently transferring. They contain the 1112 following parameters: 1114 o a list describing zones the sending peer is currently 1115 authoritative for, each one containing: 1117 * OWN-CONTACT: contact of the sending peer; 1119 * OWN-AOR: address-of-record the sending peer is registered with; 1121 * OWN-ZONE: coordinates of the zone; 1123 o [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are 1124 currently redundantly copied in every record. We should fix this 1125 in the next draft version.] 1127 o a list containing all zones neighboring those of the sending peer. 1128 The list may also contain zones that used to be under the 1129 authority of the sending peer but have just been transfered to a 1130 joining node. List tuples MUST contain the following parameters: 1132 * PEER-CONTACT: contact of the neighbor peer; 1134 * PEER-AOR: address-of-record the neighbor peer is registered 1135 for; 1137 * PEER-ZONE: coordinates of the zone. 1139 Contrary to QUERY responses, UPDATE requests MUST only report details 1140 that the sending peer is authoritative for, or zones that it is in 1141 the process of transfer to a joining peer after inviting it. (see 1142 Section 4.6). 1144 4.16. Handling UPDATE Operation Requests 1146 Upon reception of an UPDATE operation request, a peer MUST first 1147 remove from its zone list all zones overlapping with any of those 1148 reported in the request. It MUST then insert all zones from the 1149 UPDATE request that border zones it is authoritative for. UPDATE is 1150 a responseless request and MUST not be routed. 1152 4.17. Generating JOIN Operation Requests 1154 JOIN operations are used to pass the data that a client needs in 1155 order to join the overlay and become a peer. JOIN requests are 1156 generated by the inviting peer as described in Section 4.6 and 1157 contain the following parameters: 1159 o SPACE: coordinates of the whole space; 1161 o YOUR-ZONE: coordinates of the zone the entering peer will be 1162 authoritative for; 1164 o a list describing zones the inviting peer is authoritative for, 1165 each one containing: 1167 * OWN-CONTACT: contact of the inviting peer; 1169 * OWN-AOR: address-of-record the inviting peer is registered for; 1171 * OWN-ZONE: coordinates of the zone; 1173 o [TODO: The OWN-CONTACT and OWN-AOR entries in the above list are 1174 currently redundantly copied in every record. We should fix this 1175 in the next draft version.] 1177 o a list describing zones bordering on the one the entering peer 1178 will be authoritative for, each one containing: 1180 * PEER-CONTACT: contact of the neighbor peer; 1182 * PEER-AOR: address-of-record the neighbor peer is registered 1183 for; 1185 * PEER-ZONE: coordinates of the zone. 1187 4.18. Handling JOIN Operation Requests 1189 JOIN operation requests can only be received during the join phase, 1190 as described in Section 4.6. JOIN is a responseless end-to-end 1191 operation and MUST not be routed; a peer receiving an unexpected JOIN 1192 request MUST ignore it. 1194 4.19. Generating TAKEOVER Operation Requests 1196 TAKEOVER operations are used for electing the most appropriate peer 1197 to take over a zone left by a peer that has become unreachable. 1198 TAKEOVER requests are generated and exchanged by neighbors of the 1199 dead peer and contain the following parameters: 1201 o DEAD-CONTACT: contact of the dead peer; 1203 o DEAD-AOR: the address-of-record the dead peer was registered with; 1205 o DEAD-ZONE: coordinates of the dead zone; 1207 o PEER-CONTACT: contact of the peer candidate to take over the dead 1208 zone; 1210 o PEER-AOR: address-of-record the peer candidate to take over the 1211 zone is registered for; 1213 o PEER-ZONE: coordinates of a zone the peer candidate to take over 1214 the zone is authoritative for. If one or more of the zones the 1215 candidate peer is authoritative for is mergeable with the dead 1216 one, it SHOULD be reported in this parameter as it would increase 1217 the probability for the peer to be elected (see Section 4.2.2); 1219 o PEER-VOLUME: the total volume of the zones the candidate peer is 1220 authoritative for. 1222 4.20. Handling TAKEOVER Operation Requests 1224 TAKEOVER operation requests are received only when recovering from 1225 failures and are handled according to the state diagram defined in 1226 Section 4.2.1. 1228 Unexpected TAKEOVER requests, for example referring to non-bordering 1229 zones, MUST be ignored. 1231 5. XPP Extensions 1233 This section extends the XPP specification [I-D.marocco-p2psip-xpp] 1234 and defines codes and formats for operations and parameters used in 1235 XPP sessions between peers. 1237 5.1. Parameter Formats 1239 For convenience purposes we define a non-exclusive set of formats 1240 that we later use when defining PCAN related XPP parameters. 1242 5.1.1. Integer 1244 Length: the total number of bytes transported in the value. The 1245 length MUST always be divisible by 4. 1247 Value: numeric, encoded in network byte order. 1249 Example: 1251 +--+--+--+--+ 1252 Type/Length: |XX XX|00 08| 1253 +--+--+--+--+ 1254 Value: |00 00 00 AA| 1255 +--+--+--+--+ 1256 |BB CC DD EE| 1257 +--+--+--+--+ 1259 Encoding of an integer parameter with value 0xAABBCCDDEE. 1261 5.1.2. String 1263 Length: the total number of characters. If the length is not 1264 divisible by 4; the value field MUST be padded as defined in 1265 [I-D.marocco-p2psip-xpp]. 1267 Value: a sequence of ASCII characters. 1269 Example: 1271 +--+--+--+--+ 1272 Type/Length: |XX XX|00 0A| 1273 +--+--+--+--+ 1274 Value: |61 61 62 62| 1275 +--+--+--+--+ 1276 |63 63 64 64| 1277 +--+--+--+--+ 1278 |65 65 00 00| 1279 +--+--+--+--+ 1281 Encoding of a string parameter with value "AABBCCDDEE". 1283 5.1.3. String List 1285 Value: a list of ASCII strings terminated by a byte with value zero. 1287 Length: the total number of characters, including the terminator 1288 bytes. If the length is not divisible by 4 it MUST be padded as 1289 defined in [I-D.marocco-p2psip-xpp]. 1291 Example: 1293 +--+--+--+--+ 1294 Type/Length: |XX XX|00 0F| 1295 +--+--+--+--+ 1296 Value: |73 69 70 3A| 1297 +--+--+--+--+ 1298 |6D 65 00 73| 1299 +--+--+--+--+ 1300 |69 70 3A 79| 1301 +--+--+--+--+ 1302 |6F 75 00 00| 1303 +--+--+--+--+ 1305 Encoding of a URI list parameter with value {"sip:me", "sip:you"}. 1307 5.1.4. Point 1309 Value: 1311 1. one 4 byte-long numeric value encoded in network byte order, 1312 representing the number of bytes used for encoding each one of 1313 the following components. The value of this field MUST always 1314 be divisible by 4. 1316 2. a sequence of numeric values representing the components of a 1317 multidimensional point, each one encoded in network byte order 1318 and taking the number of bytes reported as the the first value 1319 of the parameter. 1321 Length: the total number of bytes occupied by the length value and 1322 by the components. Such a value MUST be divisible by 4. 1324 Example: 1326 +--+--+--+--+ 1327 Type/Length: |XX XX|00 14| 1328 +--+--+--+--+ 1329 Value: |00 00 00 08| 1330 +--+--+--+--+ 1331 |00 00 00 AA| 1332 +--+--+--+--+ 1333 |BB CC DD EE| 1334 +--+--+--+--+ 1335 |00 00 00 01| 1336 +--+--+--+--+ 1337 |02 03 04 05| 1338 +--+--+--+--+ 1340 Encoding of a point parameter with components 0xAABBCCDDEE and 1341 0x0102030405. 1343 5.1.5. Zone 1345 Value: 1347 1. one 4 byte-long numeric value encoded in network byte order, 1348 representing the number of bytes used for encoding each one of 1349 the following components. The value of this field MUST always 1350 be divisible by 4; 1352 2. a sequence of numeric values representing the components of 1353 two multidimensional points, each one encoded in network byte 1354 order and taking the number of bytes reported as the the first 1355 value of the parameter. The point defined by the first half 1356 of values represents the start vertex (the bottom-left corner 1357 of a rectangular zone in a bi-dimensional space) and the other 1358 defines the end vertex (the top-right corner, in a bi- 1359 dimensional zone). 1361 Length: the total length of the Value field. Values of the length 1362 field must always be divisible by 4. 1364 Example: 1366 +--+--+--+--+ 1367 Type/Length: |XX XX|00 24| 1368 +--+--+--+--+ 1369 Value: |00 00 00 08| 1370 +--+--+--+--+ 1371 |00 00 00 AA| 1372 +--+--+--+--+ 1373 |BB CC DD EE| 1374 +--+--+--+--+ 1375 |00 00 00 01| 1376 +--+--+--+--+ 1377 |02 03 04 05| 1378 +--+--+--+--+ 1379 |00 00 00 FF| 1380 +--+--+--+--+ 1381 |FF FF FF FF| 1382 +--+--+--+--+ 1383 |00 00 00 FF| 1384 +--+--+--+--+ 1385 |FF FF FF FF| 1386 +--+--+--+--+ 1388 Encoding of a zone parameter represented by points (0xAABBCCDDEE, 1389 0x0102030405) and (0xFFFFFFFFFF, 0xFFFFFFFFFF). 1391 5.2. Parameters 1393 This section describes all TLV parameters used by XPP-PCAN. 1395 5.2.1. KEY 1397 Code: 0x8001. 1399 Format: String (Section 5.1.2). 1401 Semantic: the key identifying a record to insert or to retrieve. 1403 5.2.2. VALUE 1405 Code: 0x8002. 1407 Format: String list (Section 5.1.3). 1409 Semantic: the set of peer URIs to traverse for reaching a client or 1410 a peer, as described in RFC 3327 [RFC3327]. Every URI MUST be 1411 encoding according to the rules defined in [RFC3986]. 1413 5.2.3. BINDING-ID 1415 Code: 0x8003. 1417 Format: string (Section 5.1.2). 1419 Semantic: the token identifying a key-value pair. 1421 5.2.4. EXPIRES 1423 Code: 0x8004. 1425 Format: integer (Section 5.1.1). 1427 Semantic: the expiration time of a key-value pair, in seconds. 1429 5.2.5. TARGET 1431 Code: 0x8005. 1433 Format: point (Section 5.1.4). 1435 Semantic: the point in the overlay that a request is addressed to. 1437 5.2.6. SPACE 1439 Code: 0x8006. 1441 Format: zone (Section 5.1.5). 1443 Semantic: the bounds of the space used in the crrent overlay. 1445 5.2.7. OWN-AOR 1446 Code: 0x8007. 1448 Format: String (Section 5.1.2). 1450 Semantic: the SIP URI identifying the user who owns the sending 1451 peer, as defined in RFC 3261 [RFC3261] and RFC 3986 [RFC3986]. 1453 5.2.8. OWN-CONTACT 1455 Code: 0x8008. 1457 Format: String (Section 5.1.2). 1459 Semantic: the SIP URI identifying the sending peer. 1461 It is worth noting that, when the peer has restricted 1462 connectivity (e.g. it is located in a NAT-ted network), the 1463 value of this parameter SHOULD be a GRUU [I-D.ietf-sip-gruu]. 1465 5.2.9. OWN-ZONE 1467 Code: 0x8009. 1469 Format: zone (Section 5.1.5). 1471 Semantic: a zone the sending peer is authoritative for. 1473 5.2.10. YOUR-ZONE 1475 Code: 0x800A. 1477 Format: zone (Section 5.1.5). 1479 Semantic: a zone the receiving peer is going to be authoritative for 1480 (usually sent to joining peers). 1482 5.2.11. PEER-AOR 1484 Code: 0x800B. 1486 Format: String (Section 5.1.2). 1488 Semantic: the SIP URI identifying a user whose peer is known by the 1489 sending peer, as defined in RFC 3261 [RFC3261] and RFC3986 1490 [RFC3261]. 1492 5.2.12. PEER-CONTACT 1494 Code: 0x800C. 1496 Format: String (Section 5.1.2). 1498 Semantic: the SIP URI identifying a peer known by the sending peer. 1500 It is worth noting that, when the peer has restricted 1501 connectivity, the value will be a GRUU [I-D.ietf-sip-gruu]. 1502 URI values MUST be encoded as specified in RFC3986 [RFC3986] 1504 5.2.13. PEER-ZONE 1506 Code: 0x800D. 1508 Format: zone (Section 5.1.5). 1510 Semantic: a zone a peer known by the sending peer is authoritative 1511 for. 1513 5.2.14. PEER-VOLUME 1515 Code: 0x800E. 1517 Format: integer (Section 5.1.1). 1519 Semantic: the total volume owned by a peer known by the sending 1520 peer. 1522 5.2.15. DEAD-AOR 1524 Code: 0x800F. 1526 Format: String (Section 5.1.2). 1528 Semantic: the SIP URI identifying a user whose peer is known by the 1529 sending peer, as defined in RFC 3261 [RFC3261]. URI values MUST 1530 be encoded as specified in RFC3986 [RFC3986] 1532 5.2.16. DEAD-CONTACT 1534 Code: 0x8010. 1536 Format: String (Section 5.1.2). 1538 Semantic: the SIP URI identifying a peer known by the sending peer. 1540 It is worth noting that, when the peer has restricted 1541 connectivity, the value will be a GRUU [I-D.ietf-sip-gruu]. 1542 URI values MUST be encoded as specified in RFC3986 [RFC3986] 1544 5.2.17. DEAD-ZONE 1546 Code: 0x8011. 1548 Format: zone (Section 5.1.5). 1550 Semantic: a zone a peer known by the sending peer is authoritative 1551 for. 1553 5.3. Operations 1555 5.3.1. PUT 1557 Code: 0x80000001. 1559 Request parameters: 1561 +[ KEY VALUE BINDING-ID EXPIRES 1563 Response parameters: 1565 +[ KEY VALUE BINDING-ID EXPIRES 1567 Semantic: insert one or more records in the distributed database. 1569 Routing: requests MUST be routed to the peer responsible for the 1570 first key; responses MUST follow the reverse path of requests. 1572 5.3.2. GET 1574 Code: 0x80000002. 1576 Request parameters: 1578 +[ KEY 1580 Response parameters: 1582 *[ KEY VALUE BINDING-ID EXPIRES 1584 Semantic: retrieve one or more records in the distributed database. 1586 Routing: requests MUST be routed to the peer responsible for the 1587 first key; responses MUST follow the reverse path of requests. 1589 5.3.3. REPLICA 1591 Code: 0x80000003. 1593 Request parameters: 1595 +[ KEY VALUE BINDING-ID EXPIRES 1597 Response parameters: 1599 +[ KEY VALUE BINDING-ID EXPIRES 1601 Semantic: insert one or more records in the local replica table. 1603 Routing: end-to-end, MUST NOT be routed. 1605 5.3.4. QUERY 1607 Code: 0x80000004. 1609 Request parameters: 1611 [ TARGET 1613 Response parameters: 1615 +[ OWN-CONTACT OWN-AOR OWN-ZONE 1617 *[ PEER-CONTACT PEER-AOR PEER-ZONE 1619 Semantic: query the status of the peer authoritative for the zone a 1620 given point falls in. 1622 Routing: requests MUST be routed to the peer authoritative on the 1623 zone which include the point encoded in TARGET parameter; 1624 responses MUST follow the reverse path of requests. 1626 5.3.5. UPDATE 1627 Code: 0x80000005. 1629 Request parameters: 1631 +[ OWN-CONTACT OWN-AOR OWN-ZONE 1633 *[ PEER-CONTACT PEER-AOR PEER-ZONE 1635 Semantic: status update upon a change. 1637 Routing: end-to-end, MUST NOT be routed. 1639 5.3.6. JOIN 1641 Code: 0x80000006. 1643 Request parameters: 1645 [ SPACE YOUR-ZONE 1647 +[ OWN-CONTACT OWN-AOR OWN-ZONE 1649 *[ PEER-CONTACT PEER-AOR PEER-ZONE 1651 Semantic: join the overlay becoming authoritative on a given zone. 1653 Routing: end-to-end, MUST NOT be routed. 1655 5.3.7. TAKEOVER 1657 Code: 0x80000007. 1659 Request parameters: 1661 [ DEAD-CONTACT DEAD-AOR DEAD-ZONE 1663 [ PEER-CONTACT PEER-AOR PEER-ZONE PEER-VOLUME 1665 Semantic: candidate a peer for taking over a zone. 1667 Routing: end-to-end, MUST NOT be routed. 1669 6. Security Considerations 1671 It is possible to identify (at least) four different categories of 1672 security issues: 1674 1. XPP transport issues, that can be addressed by securing the 1675 transport channels using a mechanism like DTLS [RFC4347]; 1677 2. eavesdropping and message forgery of SIP and media traffic by 1678 seemingly benign peers. While media can be encrypted using SRTP 1679 [RFC3711], SIP end-to-end security is still an open issue; 1681 3. unsolicited XPP session establishments. Procedures for join and 1682 recovery are defined so that any peer needs to allow session 1683 establishments to peers whose identity have already been 1684 presented by one of its neighbors. Such a mechanism builds a 1685 sort of "overlay trust", which requires further investigation, 1686 because, while it seems one of the most powerful techniques for 1687 managing authorization in peer-to-peer environments, it could be 1688 exploited by malicious peers that have entered the overlay 1689 through an error or deceit; 1691 4. overlay damages caused by malicious peers. This kind of issue is 1692 characteristic for peer-to-peer systems and, in general, is the 1693 hardest to deal with. However, with the "passive" approach, a 1694 malicious node cannot determine when it will become peer, which 1695 zone of the overlay it will be assigned and can only cause 1696 damages proportional to the area under its authority; moreover, 1697 implementations can apply their own methods, possibly based on 1698 both performance and social information, to filter malicious 1699 nodes and select the best ones to upgrade. 1701 7. IANA Considerations 1703 This document makes use following values which need to be registered 1704 with IANA: 1706 1. 'pcan' SIP option tag. 1708 8. Open Issues 1710 1. Other than peer identities, credentials for authentication should 1711 be exchanged too. How to do that? 1713 2. Can clients allow other clients to establish SIP outbound flows 1714 with them? In case, they need to implement RFC3327, don't they? 1716 3. For the time being this document does not define the amount of 1717 time that peers should keep state information about routed 1718 requests, and whether this should be indicated in the requests. 1719 Shouldn't this be the case? 1721 9. Acknowledgments 1723 This document is a mere description of what has been implemented 1724 initially in SIPDHT [WWW.sipdht] and then in SIP Communicator 1725 [WWW.sip-communicator] opensource projects. Thanks to all the smart 1726 developers contributing there; special thanks to Stefano Marengo, who 1727 wrote almost all the code in the second version of SIPDHT. 1729 Thanks also to many people working in IETF for providing input in 1730 various discussions; thanks in particular to Vijay Gurbani, Henning 1731 Schulzrinne and Salman Abdul Baset for giving useful feedback in the 1732 very initial phase of this work. 1734 10. References 1736 10.1. Normative References 1738 [I-D.ietf-sip-gruu] 1739 Rosenberg, J., "Obtaining and Using Globally Routable User 1740 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1741 (SIP)", draft-ietf-sip-gruu-12 (work in progress), 1742 March 2007. 1744 [I-D.ietf-sip-outbound] 1745 Jennings, C. and R. Mahy, "Managing Client Initiated 1746 Connections in the Session Initiation Protocol (SIP)", 1747 draft-ietf-sip-outbound-07 (work in progress), 1748 January 2007. 1750 [I-D.marocco-p2psip-xpp] 1751 Marocco, E. and E. Ivov, "Extensible Peer Protocol (XPP)", 1752 draft-marocco-p2psip-xpp-01 (work in progress), June 2007. 1754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1755 Requirement Levels", BCP 14, RFC 2119, March 1997. 1757 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1758 (SHA1)", RFC 3174, September 2001. 1760 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1761 A., Peterson, J., Sparks, R., Handley, M., and E. 1762 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1763 June 2002. 1765 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1766 (SIP) Extension Header Field for Registering Non-Adjacent 1767 Contacts", RFC 3327, December 2002. 1769 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1770 Resource Identifier (URI): Generic Syntax", STD 66, 1771 RFC 3986, January 2005. 1773 10.2. Informative References 1775 [I-D.baset-sipping-p2pcommon] 1776 Baset, S., "A Protocol for Implementing Various DHT 1777 Algorithms", draft-baset-sipping-p2pcommon-00 (work in 1778 progress), October 2006. 1780 [I-D.ietf-behave-rfc3489bis] 1781 Rosenberg, J., "Simple Traversal Underneath Network 1782 Address Translators (NAT) (STUN)", 1783 draft-ietf-behave-rfc3489bis-05 (work in progress), 1784 October 2006. 1786 [I-D.ietf-mmusic-ice] 1787 Rosenberg, J., "Interactive Connectivity Establishment 1788 (ICE): A Methodology for Network Address Translator (NAT) 1789 Traversal for Offer/Answer Protocols", 1790 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 1792 [I-D.willis-p2psip-concepts] 1793 Willis, D., Bryan, D., Matthews, P., and E. Shim, 1794 "Concepts and Terminology for Peer to Peer SIP", 1795 draft-willis-p2psip-concepts-00 (work in progress), 1796 June 2006. 1798 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1799 Protocol (SIP): Locating SIP Servers", RFC 3263, 1800 June 2002. 1802 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1803 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1804 RFC 3711, March 2004. 1806 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1807 Security", RFC 4347, April 2006. 1809 [WWW.columbia.skype] 1810 Baset, S. and H. Schulzrinne, "An Analysis of the Skype 1811 Peer-to-Peer Internet Telephony Protocol", 1812 . 1815 [WWW.icir.can] 1816 Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. 1817 Shenker, "A Scalable Content-Addressable Network", 1818 . 1820 [WWW.microsoft.pastry] 1821 Rowstron, A. and P. Druschel, "Pastry: Scalable, 1822 decentralized object location and routing for large-scale 1823 peer-to-peer systems", 1824 . 1826 [WWW.mit.chord] 1827 Stoica, I., Morris, R., Karger, D., and Frans Kaashoek, 1828 M., "Chord: A Scalable Peer-to-peer Lookup Service for 1829 Internet Applications", 1830 . 1833 [WWW.rice.kademlia] 1834 Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer 1835 Information System Based on the XOR Metric", 1836 . 1838 [WWW.sip-communicator] 1839 "SIP Communicator - the Java VoIP and Instant Messaging 1840 client", . 1842 [WWW.sipdht] 1843 "SIPDHT: A SIP-based Distributed Hash-table", 1844 . 1846 Authors' Addresses 1848 Enrico Marocco 1849 Telecom Italia 1850 Via G. Reiss Romoli, 274 1851 Turin 10148 1852 Italy 1854 Email: enrico.marocco@telecomitalia.it 1856 Emil Ivov 1857 Louis Pasteur University and SIP Communicator 1858 4 rue Blaise Pascal 1859 Strasbourg Cedex F-67070 1860 France 1862 Email: emcho@sip-communicator.org 1864 Full Copyright Statement 1866 Copyright (C) The IETF Trust (2007). 1868 This document is subject to the rights, licenses and restrictions 1869 contained in BCP 78, and except as set forth therein, the authors 1870 retain all their rights. 1872 This document and the information contained herein are provided on an 1873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1875 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1876 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1877 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1880 Intellectual Property 1882 The IETF takes no position regarding the validity or scope of any 1883 Intellectual Property Rights or other rights that might be claimed to 1884 pertain to the implementation or use of the technology described in 1885 this document or the extent to which any license under such rights 1886 might or might not be available; nor does it represent that it has 1887 made any independent effort to identify any such rights. Information 1888 on the procedures with respect to rights in RFC documents can be 1889 found in BCP 78 and BCP 79. 1891 Copies of IPR disclosures made to the IETF Secretariat and any 1892 assurances of licenses to be made available, or the result of an 1893 attempt made to obtain a general license or permission for the use of 1894 such proprietary rights by implementers or users of this 1895 specification can be obtained from the IETF on-line IPR repository at 1896 http://www.ietf.org/ipr. 1898 The IETF invites any interested party to bring to its attention any 1899 copyrights, patents or patent applications, or other proprietary 1900 rights that may cover technology that may be required to implement 1901 this standard. Please address the information to the IETF at 1902 ietf-ipr@ietf.org. 1904 Acknowledgment 1906 Funding for the RFC Editor function is provided by the IETF 1907 Administrative Support Activity (IASA).