idnits 2.17.1 draft-zangrilli-p2psip-dsip-dhtchord-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2020. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2033. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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: In periodic stabilization, peers MUST perform an arbitrary query for their current successor's Peer-ID. The peer should examine the response from their successor. The predecessor reported should be the peer that made the request. If it is not, the peer MUST update their own successor with the predecessor returned, and additionally MUST send a REGISTER to this peer, structured as if the stabilizing peer had just entered the system. However, the peer sending this message MUST not process the response, but simply discard it, as this is intended only to pass information. This will serve to properly update the overlay. This is analogous to the notify procedure in Chord. -- 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 (February 25, 2007) is 6270 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 (-04) exists of draft-willis-p2psip-concepts-03 ** Downref: Normative reference to an Informational draft: draft-willis-p2psip-concepts (ref. 'I-D.willis-p2psip-concepts') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP M. Zangrilli 3 Internet-Draft D. Bryan 4 Intended status: Standards Track SIPeerior Technologies 5 Expires: August 29, 2007 February 25, 2007 7 A Chord-based DHT for Resource Lookup in P2PSIP 8 draft-zangrilli-p2psip-dsip-dhtchord-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes how a structured peer-to-peer algorithm is 42 used for resource lookup by a P2PSIP Peer Protocol. Specifically, 43 this work describes how to integrate a DHT based on Chord with dSIP, 44 a proposed P2PSIP Peer Protocol. This document extends the dSIP 45 draft to provide one possible implementation of a pluggable DHT 46 algorithm. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Chord . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Routing Table and Connection Table . . . . . . . . . . . . . . 5 56 4.1. Finger Table . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Message Routing . . . . . . . . . . . . . . . . . . . . . 6 58 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. The DHT-PeerID Header . . . . . . . . . . . . . . . . . . 6 60 5.1.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . 6 61 5.1.2. DHT Name Parameter . . . . . . . . . . . . . . . . . . 7 62 5.2. The DHT-Link Header . . . . . . . . . . . . . . . . . . . 7 63 5.2.1. The linktype and depth values . . . . . . . . . . . . 7 64 6. Chord Overlay Algorithm . . . . . . . . . . . . . . . . . . . 8 65 6.1. Finger Table, Successors, and Predecessors . . . . . . . . 8 66 6.2. Starting a New Overlay . . . . . . . . . . . . . . . . . . 9 67 6.3. Peer Admission . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3.1. Constructing a Peer Registration . . . . . . . . . . . 9 69 6.3.2. Processing and Routing the Peer Registration . . . . . 10 70 6.3.3. Admitting the Joining Peer . . . . . . . . . . . . . . 10 71 6.4. Chord Query Processing . . . . . . . . . . . . . . . . . . 12 72 6.5. Chord Graceful Leaving . . . . . . . . . . . . . . . . . . 12 73 6.6. DHT Maintenance . . . . . . . . . . . . . . . . . . . . . 13 74 6.6.1. Chord Finger Table Updates . . . . . . . . . . . . . . 13 75 6.6.2. Chord Periodic Stabilization . . . . . . . . . . . . . 13 76 6.7. Peer Failure . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.8. Resource Replicas . . . . . . . . . . . . . . . . . . . . 14 78 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Example of a Peer Registration . . . . . . . . . . . . . . 16 80 7.2. Example of a User Registration . . . . . . . . . . . . . . 19 81 7.3. Example of a Session Establishment . . . . . . . . . . . . 21 82 7.4. Example of Moving From Empty Overlay to Stable 3 Peer 83 System . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 7.5. Example of a Peer Leaving the System . . . . . . . . . . . 44 85 7.6. Example of a Successful User Search . . . . . . . . . . . 44 86 7.7. Example of an Unsucessful User Search . . . . . . . . . . 45 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 88 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 90 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 91 12. Changes to this Version . . . . . . . . . . . . . . . . . . . 46 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 46 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 96 Intellectual Property and Copyright Statements . . . . . . . . . . 48 98 1. Introduction 100 This draft describes an overlay algorithm for use by dSIP 101 [I-D.bryan-p2psip-dsip], a proposed P2PSIP Peer Protocol. This 102 overlay algorithm is derived from the Chord algorithm [Chord], but 103 has been adapted to use SIP messages, as specified by dSIP, to 104 communicate between peers in the overlay. Chord is selected because 105 of its simplicity, convergence properties, and general familiarity 106 within the P2P community. This work reflects experience gained in 107 actually building a full commercially available P2PSIP product based 108 on using a Chord-like DHT for resource location in the dSIP protocol, 109 as well as from work/insight gleaned from the P2PSIP mailing list. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 Terminology defined in RFC 3261 [RFC3261] is used without definition. 119 We use the terminology and definitions from the dSIP: A P2P Approach 120 to SIP Registration and Resource Location [I-D.bryan-p2psip-dsip] and 121 the Concepts and Terminology for Peer to Peer SIP 122 [I-D.willis-p2psip-concepts] drafts extensively in this document. 123 Other terms relating to P2P or new to this document are defined when 124 used and are also defined in Definitions (Section 2.1). We suggest 125 reviewing these drafts and the Definitions (Section 2.1) section 126 before reading the remainder of this document.. 128 In many places in this document, 10 hexadecimal digit values are used 129 in examples as SHA-1 hashes. In reality, these hashes are 40 digit. 130 They are shortened in this document for clarity only. 132 2.1. Definitions 134 Please also see the dSIP: A P2P Approach to SIP Registration and 135 Resource Location [I-D.bryan-p2psip-dsip] draft and the P2PSIP 136 concepts and terminology [I-D.willis-p2psip-concepts] draft for 137 additional terminology. We do not redefine terms from that draft 138 here. 139 Chord: A particular algorithm/approach to implementing a DHT, 140 described by Stoica et al. [Chord]. Uses a circular arrangement 141 for the namespace. 143 Finger Table: The list of peers that a peer uses to send messages 144 to. The finger table contains many entries about peers with 145 similar IDs, and fewer entries about more remote IDs. 146 Predecessor Peer: Refers to a peer directly before a particular peer 147 in the address space. This does not mean that the predecessor's 148 Peer-ID is one less than the peer, it simply means that there are 149 no other peers in the namespace between the peer and the 150 predecessor peer. 151 Successor Peer: Refers to a peer directly after a particular peer in 152 the address space. This does not mean that the successor peer's 153 Peer-ID is one more that that peer, rather there are no other 154 peers in the namespace between that peer and the successor peer. 155 Note that the first peer in a finger table is typically also the 156 first successor peer. 158 3. Background 160 3.1. Chord 162 The Chord [Chord] system is one particular popular DHT algorithm. 163 Chord uses a ring-type structure for the peers in the overlay. In 164 this structure, a peer with a hash of 0 would be located adjacent to 165 a peer that hashes to the highest possible hash value. In Chord, 166 resource with Resource-ID k will be stored by the first peer with 167 Peer-ID equal to or greater (mod the size of the namespace) than k, 168 ensuring that every Resource-ID is associated with some peer. 170 4. Routing Table and Connection Table 172 Each peer keeps information about how to contact some number of other 173 peers in the overlay. In terms of the overlay network, these are the 174 neighbors of the peer, since they are reachable in one hop. In Chord 175 the peer keeps track of one or more of its immediate predecessor 176 peers, as well as one or more successor peers. The peer also keeps a 177 table of information about other neighbors called a finger table, 178 consisting of peers distributed around the overlay. 180 Note that dSIP defines a routing table as the set of peers that a 181 peer knows about and uses to send messages to when routing. The 182 routing table is the combination of the predecessor, successor and 183 finger table. 185 4.1. Finger Table 187 If the hash has 2^n bits in the range, each peer will keep a "finger 188 table" of pointers to at most n other peers. The ith entry in the 189 finger table contains a pointer to a peer at least 2^(i) units away 190 in the hash space. The highest finger table entry thus point to a 191 range 1/2 of the way across the hash space, the next highest 1/4, the 192 next 1/8, and the smallest entry points to a range only 1 away in the 193 hash space. The set of peers pointed to by these finger table 194 entries are referred to as the neighbors of the peer, since they can 195 be reached directly. 197 4.2. Message Routing 199 Messages are routed by taking advantage of a key property of these 200 finger tables. A peer has more detailed, fine grained information 201 about peers near it than further away, but it knows at least a few 202 more distant peers. When locating a a particular ID (either 203 Resource-ID or Peer-ID), the peer will send the request to the finger 204 table entry with the Peer-ID closest to the desired ID. Because the 205 peer receiving the request has many neighbors with similar Peer-IDs, 206 it will presumably know of a peer with a Peer-ID closer to the ID, 207 and suggests this peer to in response. The request is then resent to 208 this closer peer. The process is repeated until the peer responsible 209 for the ID is located, which can then determine if it is storing the 210 information. 212 5. Message Syntax 214 5.1. The DHT-PeerID Header 216 The routing algorithms used to implement the overlay is specified in 217 the dht-param parameter in the DHT-PeerID header. The format of the 218 DHT-PeerID header is defined in the dSIP [I-D.bryan-p2psip-dsip] 219 draft. 221 5.1.1. Hash Algorithms 223 Implementations MUST support the SHA-1 [RFC3174] algorithm, which 224 produces a 160 bit hash value. An implementation MAY rely on a 225 secret initialization vector, key, or other shared secret to use the 226 identifier as an HMAC, from from RFC 2104 [RFC2104] such that no peer 227 may join the overlay without knowledge of the shared secret, however 228 this technique by itself does not protect the overlay against replay 229 attacks. Security Extensions to dSIP 230 [I-D.lowekamp-p2psip-dsip-security] provides information on how to 231 protect against replay attacks and hash algorithms defined in that 232 draft MAY be used in Chord implementations. 234 5.1.2. DHT Name Parameter 236 For this protocol, the dht-param token MUST be set to "Chord1.0". 238 A peer receiving a message with a dht-param other than "Chord1.0" 239 SHOULD reject the message and return a 488 Not Acceptable Here 240 response message. 242 Examples: 243 A peer with an SHA-1 hashed Peer-ID of a04d371e24 on IP 192.0.2.1. 244 We include the required algorithm, and overlay as well as the 245 optional expires header parameter. 247 DHT-PeerID: ;algorithm=sha1; 248 dht=Chord1.0;overlay=chat;expires=600 250 5.2. The DHT-Link Header 252 The DHT-Link header is used to transfer information about where in 253 the DHT other peers are located. In particular, it is used by peers 254 to pass information about the predecessor, successors, and finger 255 table information stored by a peer. 257 The linktype and depth values are dependent on the DHT routing 258 algorithm employed by the peer. We define a linktype-token and 259 depth-token in the DHT-Link Header to be used by peers implementing 260 the Chord1.0 DHT algorithm. 262 link-value = linktype-token depth-token 263 linktype-token = "P" / "F" / "S" / other-token 264 depth-token = 1*DIGIT 266 and an example, the header might look like (using a shortened digit 267 Peer-ID for clarity): 269 DHT-Link: ;link=S1;expires=600 271 5.2.1. The linktype and depth values 273 The linktype MUST be one of three single characters, P, S, or F. P 274 MUST be used to indicate that the information provided describes a 275 predecessor of the sending peer. S MUST indicate that the 276 information describes a successor peer, and F MUST indicate that it 277 is a finger table peer from the sending peer. 279 The depth MUST be a non-negative integer representing which 280 predecessor, successor, or finger table entry is being described. 282 For predecessors and successors, this MUST indicate numeric depth. 283 In other words, "P1" indicates the peers immediate predecessor, while 284 "S5" would indicate the fifth successor. "P0" or "S0" would indicate 285 the sending peer itself. In the case of finger table entries, the 286 depth MUST indicate the exponent of the offset. Since finger tables 287 point to ranges in the hash table that are offset from the current 288 peer in the hash space by a power of two. That is, finger table 289 entry i points to a range that begins with a peer 2^i away in the 290 hash space, and there are a maximum of k finger table entries, where 291 k is the size of the hash result in bits. For an finger table entry, 292 the depth corresponds to this exponent i. In other words, "F0" would 293 correspond to a finger table entry pointing to the peer for a range 294 starting a distance 2^0 = 1 from the Peer-ID in the hash space, while 295 "F6" would point to peer used to search for resources in a range 296 starting 2^6 = 64 away from the Peer-ID in the hash space. 298 6. Chord Overlay Algorithm 300 6.1. Finger Table, Successors, and Predecessors 302 Each peer MUST have keep track of at least one predecessor peer in 303 its routing table. This predecessor peer CANNOT be set to itself, 304 but CAN be NULL if the current peer is the only peer in the overlay. 305 Each peer MUST also have at least one successor peer in its routing 306 table. This successor peer can be set to itself. Peers MAY keep 307 additional successor and predecessor information in their routing 308 tables for reliability. 310 Chord recommends keeping a number of finger table entries equal to 311 the size in bits of the hash space, for example 160 for SHA-1. These 312 entries point to the first peer at least 2^i away from the peer, for 313 0 <= i <= 159, mod 2^160. Essentially, the peer divides the overlay 314 hash circle up into segments, the first being the segment from 315 [2^0-2^1) away from the peer, the second being from [2^1-2^2), the 316 third being from [2^2-2^3), etc., all the way to the segment from 317 [2^158-2^159) away from peer. It then stores an entry in the finger 318 table for the first peer with a Peer-ID greater than or equal to the 319 start of this interval. In this way, the peer has many entries 320 pointing to nearby peers, and less and less entries about more remote 321 peers. These tables are populated when the peer joins the overlay, 322 and are kept up to date by periodically updating them. 324 We recommend that, while using the full SHA-1 hash algorithm, peers 325 maintain less than the full 160 entries in the finger table, perhaps 326 16 entries for small networks, 32 for larger networks. As this 327 affects only the efficiency of the client, it is left to the 328 implementer to determine a useful value. Note that a client can 329 easily store enough finger table entries to exceed the maximum MTU 330 size when transmitting the full finger table. In this case, a client 331 may need to reduce the number of finger table entries reported in 332 DHT-Link headers. 334 6.2. Starting a New Overlay 336 A peer starting an overlay for the first time need not do anything 337 special in order to construct the overlay. The peer MUST initialize 338 its finger table. To create the finger table, a peer MUST take its 339 Peer-ID and, by applying the exponential offsets for each finger, 340 calculate the Resource-IDs corresponding to the start of each finger 341 interval. See Finger Table, Successors and Predecessors 342 (Section 6.1) for more details. After the finger table is created, 343 the peer MUST initialize the finger table entries such that all 344 entries point to itself. The peer MUST set its successor to itself, 345 and MUST set its predecessor to NULL. 347 6.3. Peer Admission 349 A peer that wishes to join an overlay (called the joining peer), 350 constructs a Peer Registration message and sends it to the bootstrap 351 peer. The Peer Registration is routed to the admitting peer, which 352 is the peer that is currently responsible for the joining peer's 353 portion of the overlay. 355 6.3.1. Constructing a Peer Registration 357 To initiate the joining process, the joining peer constructs a Peer 358 Registration and sends it to the bootstrap peer. The joining peer 359 MUST construct the Peer Registration according the rules outlined in 360 the dSIP [I-D.bryan-p2psip-dsip] draft. The joining peer MUST 361 provide a DHT-PeerID header field in the Peer Registration and the 362 dht-param part of the DHT-PeerID MUST be set to "*" or the token 363 specified in the DHT Name Parameter (Section 5.1.2) section of this 364 document. 366 Assume that a peer running on IP address 192.0.2.2 on port 5060 367 attempts to join the network by contacting a bootstrap peer at 368 address 192.0.2.129. Further assume that 192.0.2.2 hashes to 369 463ac4b449 under SHA-1 (using a 10 digit hash for example 370 simplicity), and that the overlay name is chat. An example message 371 would look like this (neglecting tags): 373 REGISTER sip:192.0.2.129 SIP/2.0 374 To: 375 From: 376 Contact: 377 Expires: 600 378 DHT-PeerID: ;algorithm=sha1; 379 dht-param=Chord1.0;overlay=chat;expires=600 380 Require: dht 381 Supported: dht 383 6.3.2. Processing and Routing the Peer Registration 385 The Peer Registration is processed and routed according the rules 386 outlined in the dSIP [I-D.bryan-p2psip-dsip] draft. 388 6.3.3. Admitting the Joining Peer 390 The admitting peer recognizes that it is presently responsible for 391 this region of the hash space -- that is, it is currently the peer 392 storing the information that the joining peer will eventually be 393 responsible for. The admitting peer knows this because the joining 394 peer's Peer-ID falls between the admitting peer's predecessor's 395 Peer-ID and the admitting peer's Peer-ID. The admitting peer is 396 responsible for helping the joining peer become a member of the 397 overlay. 399 When handling a Peer Registration from a joining peer, the admitting 400 peer MUST reply with a 200 response if the joining peer has a Peer-ID 401 between the admitting peer's predecessor's Peer-ID and the admitting 402 Peer-ID, or the admitting peer's predecessor is NULL. In the special 403 case where the admitting peer's predecessor is NULL (as can happen if 404 the admitting peer is the peer that started the overlay), that peer 405 MUST reply with a 200 response to any peer validly attempting to join 406 the system, regardless of Peer-ID. 408 The admitting peer MUST verify that the joining peer's Peer-ID is 409 valid. If the joining peer's credentials are not valid, the message 410 should be rejected with a response of 493 Undecipherable. In 411 addition to verifying that the joining peer's Peer-ID is valid, the 412 admitting peer MAY require an authentication challenge to the 413 REGISTER message. Once any challenge has been met, the admitting 414 will reply with a 200 OK message to the joining peer. As in a 415 traditional registration, the Contact in the 200 OK will be the same 416 as in the request, and the expiry time MUST be provided. 418 The 200 response that is constructed MUST provide information about 419 the admitting peer's neighbors and finger table entries in the DHT- 420 Link headers of the 200 response. This enables the joining peer to 421 initialize its neighbors and finger table entries. Additionally, the 422 admitting peer MUST include its DHT-PeerID header containing the 423 admitting peer's Peer-ID and IP. If the admitting peer's predecessor 424 is not NULL, it MUST provide the joining peer with its current 425 predecessor and successor in the 200. If the predecessor is NULL, 426 the 200 MUST NOT include a value for the predecessor but MUST include 427 a value for the successor. These MUST be placed placed in DHT-Link 428 headers, as described in The DHT-Link Header (Section 5.2) section of 429 this document. The predecessor MUST be transmitted in a DHT-Link 430 header using a type of P and a depth of 1. The successor MUST be 431 transmitted in a DHT-Link header using a type of S and a depth of 1. 433 The admitting peer SHOULD send a copy of the entries in their finger 434 table to the joining peer, using DHT-Link headers of the F type. As 435 the joining peer will likely be nearby the admitting peer in the hash 436 space (at least for an overlay with a reasonable number of peers), 437 this finger table information can likely improve the performance of 438 the queries required to obtain a correct finger table information. 440 Continuing the example Peer Registration from the section above, 441 assume now that the peer with Peer-ID 47e46fa2cd and IP address 442 192.0.2.7 is currently responsible for 463ac4b449 in the namespace. 443 The admitting peer here does send the finger table, but we show only 444 the first entry entry for clarity. We also omit the additional 445 successors used to support redundancy for clarity. The response 446 would look something like: 448 SIP/2.0 200 OK 449 To: 450 From: 451 Contact: 452 Expires: 600 453 DHT-PeerID: ;algorithm=sha1; 454 dht-param=Chord1.0;overlay=chat;expires=600 455 DHT-Link: ;link=P1;expires=412 456 DHT-Link: ;link=S1;expires=816 457 DHT-Link: ;link=F2;expires=121 458 Require: dht 459 Supported: dht 461 The joining peer obtains the Peer-ID and address of the admitting 462 peer from the DHT-Peer header, and the information about the 463 admitting peer's predecessor from the DHT-Link P 1 header. The 464 joining peer MUST set its successor to be the admitting peer and its 465 predecessor to be the admitting peer's predecessor. If the admitting 466 peer did not provide a predecessor (which MUST only occur if the 467 admitting peer's predecessor is NULL), the joining peer should leave 468 their predecessor as NULL. 470 *After* the admitting peer sends the 200 response, it MUST set its 471 predecessor to be the joining peer, and MUST obtain the information 472 from the DHT-Peer header in the register request. It MUST NOT change 473 the value of the predecessor prior to sending the 200. The admitting 474 peer's successor is unchanged. Note that at this point the joining 475 can also set all fingers pointing to intervals before the successor 476 in the finger table to point to the successor. 478 Following the admission, the joining peer MUST run periodic 479 stabilization as described in DHT Maintenance (Section 6.6). The 480 admitting peer should perform periodic stabilization as well. 482 6.4. Chord Query Processing 484 A reply that is constructed to a query by the responsible peer MUST 485 provide the current predecessor (if not NULL) and successor in the 486 200 or 404 message. These MUST be placed placed in DHT-Link headers, 487 as described in The DHT-Link Header (Section 5.2) section of this 488 document. If the predecessor is not NULL it MUST be transmitted in a 489 DHT-Link header using a type of P and a depth of 1. It must be 490 omitted if NULL. The successor MUST be transmitted in a DHT-Link 491 header using a type of S and a depth of 1. The 200 or 404 SHOULD 492 contain a copy of entries in their finger table, using DHT-Link 493 headers with type F. Additionally, the replying peer MUST include its 494 DHT-PeerID header. 496 6.5. Chord Graceful Leaving 498 Peers MUST send their resource registrations to their successor 499 before leaving the overlay. Additionally, peers MUST unregister 500 themselves with both their successor and predecessor. This 501 unregister is constructed exactly the same as the Peer Registration 502 message used to join, with the following exceptions. The expires 503 parameter or header MUST be provided, and MUST be set to 0. 505 When a peer sends its unregister message to its successor and 506 predecessor, it MUST include DHT-Link headers listing its predecessor 507 and successor peers. This allows the peers receiving the requests to 508 obtain the information needed to correct their predecessor and 509 successor peers, as well as keep their successor lists needed for 510 redundancy current. 512 OPEN ISSUE: should it be possible to trigger another peer to check 513 its predecessor? 515 6.6. DHT Maintenance 517 In order to keep the overlay stable, peers must periodically perform 518 book keeping operations to take into account peer failures. 519 Periodically (we suggest 60-360 seconds), peers MUST perform finger 520 table updates and periodic stabilization. 522 6.6.1. Chord Finger Table Updates 524 To update the finger table, a peer performs a Peer Query search for 525 ID corresponding to the start of each of its finger intervals. These 526 intervals are described in Finger Table, Successors and Predecessors 527 (Section 6.1) and Peer Queries are described in the dSIP 528 [I-D.bryan-p2psip-dsip] draft. 530 The 200 response to each Peer Query will contain the peer responsible 531 for that ID in the DHT-PeerID header. The peer information in the 532 DHT-PeerID header is entered into the corresponding finger table 533 entry. 535 6.6.2. Chord Periodic Stabilization 537 In periodic stabilization, peers MUST perform an arbitrary query for 538 their current successor's Peer-ID. The peer should examine the 539 response from their successor. The predecessor reported should be 540 the peer that made the request. If it is not, the peer MUST update 541 their own successor with the predecessor returned, and additionally 542 MUST send a REGISTER to this peer, structured as if the stabilizing 543 peer had just entered the system. However, the peer sending this 544 message MUST not process the response, but simply discard it, as this 545 is intended only to pass information. This will serve to properly 546 update the overlay. This is analogous to the notify procedure in 547 Chord. 549 OPEN ISSUE: this operation is identical to the original chord 550 operation, but it seems like we can pay attention to the response and 551 observe if there have been multiple peers inserted and the peer we 552 sent the REGISTER to knows a better successor peer, but this goes 553 away with the next stabilize, anyway. 555 6.7. Peer Failure 557 Peer failure is handled by the periodic stabilization and responses 558 to failed requests discussed above. Redundancy prevents against lost 559 registrations. 561 6.8. Resource Replicas 563 When a resource is registered, the registering peer SHOULD create at 564 least 2 redundant replicas to ensure the registry information is 565 secure in the DHT. The registering peer is responsible for 566 maintaining these replicas along with the primary entry. 568 7. Examples 570 For our examples, we use a simplified network. Rather than use a 571 full SHA-1 hash, and the resulting 2^160 namespace, we instead use a 572 smaller 4 bit hash, leading to a namespace of size 16. All hash 573 results in our examples are contrived. We list the Peer-ID and 574 Resource-IDs as xx, where xx is a number between 0 and 15 (2^4 575 namespace). In a real situation, the full 40 hex chars would be 576 used. Additionally, because the number of finger table entries is so 577 small in this case, we use the full 4 entries, where in a real case 578 we suggest that one uses less than the number of bits in the 579 namespace. 581 The empty overlay can be visualized as a circle with 16 possible 582 vacant points, each corresponding to one possible location in the 583 hash space. On the left, we have labeled these locations in the hash 584 space as 0-15, starting in the upper left, and have used 0s to 585 indicate vacant spaces in the hash space. On the right, we show the 586 same network with 3 operating peers, denoted by capital Ns, with 587 Peer-IDs of 3, 5, and 10. We will use this sample network state as 588 the starting point for all our networks: 590 0 1 2 0 1 2 591 0----0----0 0----0----0 592 / \ / \ 593 15 0 0 3 15 0 N 3 594 / \ / \ 595 14 0 0 4 14 0 0 4 596 | | | | 597 13 0 0 5 13 0 N 5 598 | | | | 599 12 0 0 6 12 0 0 6 600 \ / \ / 601 11 0 0 7 11 0 0 7 602 \ / \ / 603 0----0----0 N----0----0 604 10 9 8 10 9 8 606 Further, for the sake of example simplicity, assume the peer Peer-ID 607 3 has IP address 192.0.2.3, the peer peer with Peer-ID 5 has IP 608 address 192.0.2.5, etc. 610 Data that hashes to a Resource-ID is stored by the next peer whose 611 Peer-ID is equal to or larger than the Resource-ID, mod the size of 612 the hash. As such, Peer 3 is responsible for any resources hashing 613 from 11-15, as well as 0-3. Peer 5 is responsible for resources with 614 Resource-IDs from 4-5, and Peer 10 is responsible for resources with 615 Resource-IDs from 6-10. From this illustration, you follow a 616 location clockwise until you encounter a peer, and this is the peer 617 responsible for storing the information. This is illustrated below: 619 0 1 2 620 0----0----0 621 / \ 622 15 0 N 3 623 / 624 14 0 0 4 625 | | 626 13 0 N 5 627 | 628 12 0 0 6 629 \ / 630 11 0 0 7 631 / 632 N----0----0 633 10 9 8 635 Finger tables give pointers to nearby peers. For our system, with 4 636 bit identifiers, we have 4 finger table entries. These finger tables 637 point to the peer nearest to Peer-ID + 2^0, Peer-ID + 2^1, Peer-ID + 638 2^2 and Peer-ID + 2^3. If no peer is present at that location, the 639 next available peer will be used. Thus, for our 3 peers, the finger 640 tables look like the following, with ranges (indicated in traditional 641 mathematical form) mapping to the peer those requests will be sent 642 to: 644 Peer 3 Peer 5 Peer 10 645 2^0 Entry [4,5) -> 5 [6,7) -> 10 [11,12) -> 3 646 2^1 Entry [5,7) -> 5 [7,9) -> 10 [12,14) -> 3 647 2^2 Entry [7,11) -> 10 [9,13) -> 10 [14,2) -> 3 648 2^3 Entry [11,3) -> 3 [13,5) -> 3 [2,10) -> 3 650 Assume further our sample network is called sipchat, and that 2 users 651 are currently registered. User alice has a Resource-ID of 5, so her 652 registration information is stored at peer 5. User bob is also 653 registered, and has a Resource-ID of 12, so his registration 654 information is stored by peer 3. Assume further that bob's UA is co- 655 located with Peer 10, so his contact is sipchat/bob@192.0.2.10, and 656 that alice is running a UA on a completely separate IP of 192.0.2.99, 657 but is using an adapter peer running on Peer 3, therefore Peer 3 will 658 send messages on alice's behalf, but alice's contact is 659 sipchat/alice@192.0.2.99. 661 In each of the examples below, we assume we start from the network 662 described above. Changes to the example network from previous 663 examples are discarded. 665 Note that for simplicity we do not show user registration redundancy 666 in any examples. This includes responses -- we only send predecessor 667 and successor, as well as finger table -- not redundant successors. 669 7.1. Example of a Peer Registration 671 Assume a new peer wishes to join the system. The peer has an IP 672 address of 192.0.2.14, which we shall assume hashes to a Peer-ID of 673 14. From an out of band mechanism, this peer discovers peer 5. This 674 peer constructs a REGISTER and sends it to peer 5. Peer 5 verifies 675 that 192.0.2.14 hashes to 14, then checks to see if it controls that 676 portion of the namespace. Since it does not, it looks up in its 677 finger table where it would route a search for 14, and determines it 678 would send it to peer 3. The peer then sends a 302 back to peer 14, 679 with a contact of peer 3. 681 Peer 14 the constructs a new REGISTER and sends it to Peer 3. Again, 682 Peer 3 verifies the hash, and determines it is currently responsible 683 for 14 in the hash space. After an optional challenge, it replies 684 with a 200 OK message to admit the peer to the system. Finally, Peer 685 3 sends a third party registration on behalf of bob to Peer 14, 686 transferring bob's registration to the new peer. 688 Peer 14 Peer 5 Peer 3 689 | | | 690 |(1) REGISTER | | 691 |------------------>| | 692 | | | 693 |(2) 302 | | 694 |<------------------| | 695 | | | 696 |(3) REGISTER | | 697 |-------------------------------------->| 698 | | | 699 |(4) 200 | | 700 |<--------------------------------------| 701 | | | 702 |(5) REGISTER | | 703 |<--------------------------------------| 704 | | | 705 |(6) 200 | | 706 |-------------------------------------->| 707 | | | 709 Peer 14 -> Peer 5 711 REGISTER sip:192.0.2.5 SIP/2.0 712 To: 713 From: 714 Contact: 715 Expires: 600 716 DHT-PeerID: ;algorithm=sha1; 717 dht=Chord1.0;overlay=chat;expires=600 718 Require: dht 719 Supported: dht 721 Peer 5 -> Peer 14 723 SIP/2.0 302 Moved Temporarily 724 To: 725 From: 726 Contact: 727 DHT-PeerID: ;algorithm=sha1; 728 dht=Chord1.0;overlay=chat;expires=1200 729 DHT-Link: ;link=P1;expires=427 730 DHT-Link: ;link=S1;expires=387 731 Require: dht 732 Supported: dht 734 Peer 14 -> Peer 3 736 REGISTER sip:192.0.2.3 SIP/2.0 737 To: 738 From: 739 Contact: 740 Expires: 600 741 DHT-PeerID: ;algorithm=sha1; 742 dht=Chord1.0;overlay=chat;expires=600 743 Require: dht 744 Supported: dht 746 Peer 3 -> Peer 14 748 SIP/2.0 200 OK 749 To: 750 From: 751 Contact: 752 Expires: 600 753 DHT-PeerID: ;algorithm=sha1; 754 dht=Chord1.0;overlay=chat;expires=600 755 DHT-Link: ;link=P1;expires=125 756 DHT-Link: ;link=S1;expires=919 757 DHT-Link: ;link=F0;expires=919 758 DHT-Link: ;link=F1;expires=919 759 DHT-Link: ;link=F2;expires=125 760 DHT-Link: ;link=F3;expires=600 761 Require: dht 762 Supported: dht 764 Peer 3 -> Peer 14 766 REGISTER sip:192.0.2.14 SIP/2.0 767 To: 768 From: 769 Contact: 770 Expires: 201 771 DHT-PeerID: ;algorithm=sha1; 772 dht=Chord1.0;overlay=chat;expires=600 773 Require: dht 774 Supported: dht 776 Peer 14 -> Peer 3 778 SIP/2.0 200 OK 779 To: 780 From: 781 Contact: 782 Expires: 201 783 DHT-PeerID: ;algorithm=sha1; 784 dht=Chord1.0;overlay=chat;expires=600 785 Require: dht 786 Supported: dht 788 7.2. Example of a User Registration 790 Assume user Carl starts a UA co-located with peer 5. Carl's contact 791 will be carl@192.0.2.5, and his user name will be carl@p2psip.org. 792 Carl's Peer hashes his user id and determines that the corresponding 793 Resource-ID will be 11 -- that is, Carl's registration will be stored 794 by the peer responsible for Resource-ID 11 -- ultimately Peer 3 in 795 our example. 797 Carl's UA begins by constructing a SIP REGISTER message. Carl's UA 798 consults its finger table, and determines that it should route 799 requests pertaining to a Resource-ID of 11 to Peer 10. The REGISTER 800 is sent to Peer 10, which observes that it is not responsible for 801 that portion of the namespace, and consults the finger table, finding 802 Peer 3 in the appropriate entry. Peer 10 sends a 302 containing Peer 803 3 as a contact. 805 Peer 5 constructs a new REGISTER on behalf of carl, and sends it to 806 Peer 3. Peer 3 recognizes that it is responsible for storing this 807 registration, and replies with a 200 OK (although in reality it might 808 challenge in some way). The 200 contains some number of successor 809 peers -- in this case 2 (although in our contrived example, one is 810 peer 5 itself) that Carl's peer could send redundant registrations 811 to. In our example, we do not show these. The 200 also (like 302s) 812 must contain successors/predecessors in case the request is being 813 used for stabilization. Again, in the tiny contrived example it 814 looks odd since the second successor is the same as the predecessor. 815 In a larger example this would not be the case. 817 [To Do: Maybe use a bigger example to fix these problems? That might 818 be to big and ugly. Need a good way to show this] 820 Peer 5 Peer 10 Peer 3 821 | | | 822 |(1) REGISTER | | 823 |------------------>| | 824 | | | 825 |(2) 302 | | 826 |<------------------| | 827 | | | 828 |(3) REGISTER | | 829 |-------------------------------------->| 830 | | | 831 |(4) 200 | | 832 |<--------------------------------------| 833 | | | 835 Peer 5 -> Peer 10 837 REGISTER sip:192.0.2.10 SIP/2.0 838 To: 839 From: 840 Contact: 841 Expires: 600 842 DHT-PeerID: ;algorithm=sha1; 843 dht=Chord1.0;overlay=chat;expires=1200 844 Require: dht 845 Supported: dht 847 Peer 10 -> Peer 5 849 SIP/2.0 302 Moved Temporarily 850 Contact: 851 DHT-PeerID: ;algorithm=sha1; 852 dht=Chord1.0;overlay=chat;expires=800 853 DHT-Link: ;link=P1;expires=1200 854 DHT-Link: ;link=S1;expires=412 855 Require: dht 856 Supported: dht 858 Peer 5 -> Peer 3 860 REGISTER sip:192.0.2.3 SIP/2.0 861 To: 862 From: 863 Contact: 864 Expires: 600 865 DHT-PeerID: ;algorithm=sha1; 866 dht=Chord1.0;overlay=chat;expires=1200 867 Require: dht 868 Supported: dht 870 Peer 3 -> Peer 5 872 SIP/2.0 200 OK 873 To: 874 From: 875 Contact: 876 Expires: 600 877 DHT-PeerID: ;algorithm=sha1; 878 dht=Chord1.0;overlay=chat;expires=600 879 DHT-Link: ;link=P1;expires=405 880 DHT-Link: ;link=S1;expires=1200 881 DHT-Link: ;link=S2;expires=405 882 Require: dht 883 Supported: dht 885 7.3. Example of a Session Establishment 887 Assume user Bob wishes to call user Alice. Bob's peer hashes Alice's 888 user id, resulting in a Resource-ID of 5. Bob's peer (recall that 889 Bob's UA is co-located with peer 10) consults its finger table, and 890 determines that a request for Resource-ID 5 should be routed to Peer 891 3. A REGISTER query message is constructed and routed to Peer 3. 892 Peer 3 determines it is not responsible for a Resource-ID of 5, looks 893 up the ID in its finger table and determines it should be routed to 894 Peer 5, so it returns a 302 referring to Peer 5. Bob's peer resends 895 the REGISTER to Peer 5, which stores Alice's information. It sends a 896 200 with Alice's contact -- sipchat/alice@192.0.2.99. Bob finally 897 sends an INVITE to Alice's UA, and session establishment is completed 898 as normal. 900 Peer 10 Peer 3 Peer 5 Alice UA 901 | | | | 902 |(1) REGISTER | | | 903 |------------------>| | | 904 | | | | 905 |(2) 302 | | | 906 |<------------------| | | 907 | | | | 908 |(3) REGISTER | | | 909 |----------------------------------->| | 910 | | | | 911 |(4) 200 | | | 912 |<-----------------------------------| | 913 | | | | 914 |(5) INVITE | | | 915 |------------------------------------------------------>| 916 | | | | 917 |(6) 180 | | | 918 |<------------------------------------------------------| 919 | | | | 920 |(7) 200 | | | 921 |<------------------------------------------------------| 922 | | | | 923 |(8) ACK | | | 924 |------------------------------------------------------>| 925 | | | | 927 Peer 10 -> Peer 3 929 REGISTER sip:192.0.2.3 SIP/2.0 930 To: 931 From: 932 DHT-PeerID: ;algorithm=sha1; 933 dht=Chord1.0;overlay=chat;expires=800 934 Require: dht 935 Supported: dht 937 Peer 3 -> Peer 10 939 SIP/2.0 302 Moved Temporarily 940 To: 941 From: 942 Contact: 943 DHT-PeerID: ;algorithm=sha1; 944 dht=Chord1.0;overlay=chat;expires=600 945 DHT-Link: ;link=P1;expires=421 946 DHT-Link: ;link=S1;expires=1004 947 Require: dht 948 Supported: dht 950 Peer 10 -> Peer 5 952 REGISTER sip:192.0.2.5 SIP/2.0 953 To: 954 From: 955 DHT-PeerID: ;algorithm=sha1; 956 dht=Chord1.0;overlay=chat;expires=800 957 Require: dht 958 Supported: dht 960 Peer 5 -> Peer 10 962 SIP/2.0 200 OK 963 To: 964 From: 965 Contact: 966 DHT-PeerID: ;algorithm=sha1; 967 dht=Chord1.0;overlay=chat;expires=1200 968 DHT-Link: ;link=P1;expires=108 969 DHT-Link: ;link=S1;expires=492 970 Require: dht 971 Supported: dht 973 Peer 10 -> Alice UA 975 INVITE sip:alice@p2psip.org SIP/2.0 976 To: 977 From: 978 Contact: 979 DHT-PeerID: ;algorithm=sha1; 980 dht=Chord1.0;overlay=chat;expires=800 981 Supported: dht 983 The remainder of the call is completed as any other SIP call. Note 984 that if Alice's UA is DHT-compliant, then it will recognize the 985 Supported field and DHT-PeerID header, and may respond with similar 986 fields. However, if it does not support DHT extensions, it will 987 simply ignore those values and complete the call as any normal non- 988 P2P SIP UA. 990 7.4. Example of Moving From Empty Overlay to Stable 3 Peer System 992 In this example, we track the system state from overlay creation to a 993 stable 3 peer overlay with 2 resources (user registrations) 994 registered and stored in the system. This example will show how 995 successor, predecessor, and finger table entries are updated during 996 each step as well as show the P2P SIP messages exchanged. 998 Assume we start with an empty overlay with a namespace of 16. Each 999 peer in the system will have one successor, one predecessor and 4 1000 finger table entries (2^4 namespace). Peer state will be shown in 1001 the following way: 1003 PeerID 1004 Successor 1005 Predecessor 1006 2^0 Entry 1007 2^1 Entry 1008 2^2 Entry 1009 2^3 Entry 1010 Resources 1012 0 1 2 1013 0----0----0 1014 / \ 1015 15 0 0 3 1016 / \ 1017 14 0 0 4 1018 | | 1019 13 0 0 5 1020 | | 1021 12 0 0 6 1022 \ / 1023 11 0 0 7 1024 \ / 1025 0----0----0 1026 10 9 8 1028 Additionally, we will track the location of resources with a resource 1029 map. 1031 A peer with PeerID 3, IP address 192.0.2.3, and port 5060 starts the 1032 overlay called chat. When a peer starts a new overlay, it sets its 1033 successor to be its PeerID and sets its predecessor to be NULL. 1034 Additionally, the peer initializes its finger table and sets all 1035 fingers to be its PeerID. 1037 The resulting state of the system is: 1039 0 1 2 1040 0----0----0 1041 / \ 1042 15 0 P 3 1043 / \ 1044 14 0 0 4 1045 | | 1046 13 0 0 5 1047 | | 1048 12 0 0 6 1049 \ / 1050 11 0 0 7 1051 \ / 1052 0----0----0 1053 10 9 8 1055 Peer 3 1056 Successor 3 1057 Predecessor NULL 1058 2^0 Entry [4,5) -> 3 1059 2^1 Entry [5,7) -> 3 1060 2^2 Entry [7,11) -> 3 1061 2^3 Entry [11,3) -> 3 1062 Resources 1064 Resource Map 1066 For peer 3, there is a resource called alice that must be registered 1067 with the system. alice's peer hashes her user id and determines that 1068 the corresponding resource will be 8. alice's contact will be 1069 sipchat/alice@192.0.2.3 and her user name will be alice@p2psip.org. 1070 Because there are no other peers in the system, peer 3 is responsible 1071 for all resources including alice's registration. Note that we use 1072 "resID" as a short form for "resource-ID" to save room in the figure 1073 only -- resource-ID is used in the actual messages. 1075 As a result the system state changes to: 1077 0 1 2 1078 0----0----0 1079 / \ 1080 15 0 P 3 1081 / \ 1082 14 0 0 4 1083 | | 1084 13 0 0 5 1085 | | 1086 12 0 0 6 1087 \ / 1088 11 0 0 7 1089 \ / 1090 0----0----0 1091 10 9 8 1093 Peer 3 1094 Successor 3 1095 Predecessor NULL 1096 2^0 Entry [4,5) -> 3 1097 2^1 Entry [5,7) -> 3 1098 2^2 Entry [7,11) -> 3 1099 2^3 Entry [11,3) -> 3 1100 Resources alice;resID=8 -> 3 1102 Resource Map 1103 Resource name ResID ResLocation ResStorage Location 1104 alice 8 3 3 1106 Next a peer with PeerID 10, IP address 192.0.2.10, and port 5060 1107 decides to join the overlay called chat. From an out of band 1108 mechanism, such as one of the ones listed in the Bootstrapping 1109 section of this document, this peer discovers peer 3. This new peer 1110 10, constructs a REGISTER and sends it to peer 3. 1112 Peer 3 verifies that 192.0.2.10 hashes to 10, then checks to see if 1113 it controls that portion of the namespace. Since Peer 3's 1114 predecessor is NULL and no other peers are in the system, Peer 3 1115 determines that is currently responsible for peer 10 in the hash 1116 space. After an optional challenge, peer 3 replies with a 200 OK 1117 message to admit peer 10 into the system. 1119 Peer 3 then sets its predecessor to be Peer 10. When Peer 10 1120 receives the 200 OK message, it will set its successor to be Peer 3 1121 and keeps its predecessor set to NULL (because no predecessor was in 1122 the 200 response). 1124 Finally, Peer 3 sends a third party registration on behalf of alice 1125 to Peer 10, transferring alice's registration to the new peer. 1127 Peer 10 Peer 3 1128 | | 1129 |(1) REGISTER | 1130 |------------------>| 1131 | | 1132 |(2) 200 | 1133 |<------------------| 1134 | | 1135 |(3) REGISTER | 1136 |<------------------| 1137 | | 1138 |(4) 200 | 1139 |------------------>| 1140 | | 1142 Peer 10 -> Peer 3 1144 REGISTER sip:192.0.2.3 SIP/2.0 1145 To: 1146 From: 1147 Contact: 1148 Expires: 600 1149 DHT-PeerID: ;algorithm=sha1; 1150 dht=Chord1.0;overlay=chat;expires=600 1151 Require: dht 1152 Supported: dht 1154 Peer 3 -> Peer 10 1156 SIP/2.0 200 OK 1157 To: 1158 From: 1159 Contact: 1160 Expires: 600 1161 DHT-PeerID: ;algorithm=sha1; 1162 dht=Chord1.0;overlay=chat;expires=600 1163 DHT-Link: ;link=S1;expires=919 1164 DHT-Link: ;link=F0;expires=919 1165 DHT-Link: ;link=F1;expires=919 1166 DHT-Link: ;link=F2;expires=125 1167 DHT-Link: ;link=F3;expires=600 1168 Require: dht 1169 Supported: dht 1171 Peer 3 -> Peer 10 1173 REGISTER sip:192.0.2.10 SIP/2.0 1174 To: 1175 From: 1176 Contact: 1177 Expires: 201 1178 DHT-PeerID: ;algorithm=sha1; 1179 dht=Chord1.0;overlay=chat;expires=600 1180 Require: dht 1181 Supported: dht 1183 Peer 10 -> Peer 3 1185 SIP/2.0 200 OK 1186 To: 1187 From: 1188 Contact: 1189 Expires: 201 1190 DHT-PeerID: ;algorithm=sha1; 1191 dht=Chord1.0;overlay=chat;expires=600 1192 DHT-Link: ;link=S1;expires=919 1193 DHT-Link: ;link=F0;expires=919 1194 DHT-Link: ;link=F1;expires=919 1195 DHT-Link: ;link=F2;expires=125 1196 DHT-Link: ;link=F3;expires=600 1197 Require: dht 1198 Supported: dht 1200 The system state is now: 1202 0 1 2 1203 0----0----0 1204 / \ 1205 15 0 P 3 1206 / \ 1207 14 0 0 4 1208 | | 1209 13 0 0 5 1210 | | 1211 12 0 0 6 1212 \ / 1213 11 0 0 7 1214 \ / 1215 P----0----0 1216 10 9 8 1218 Peer 3 Peer 10 1219 Successor 3 3 1220 Predecessor 10 NULL 1221 2^0 Entry [4,5) -> 3 [11,12) -> 3 1222 2^1 Entry [5,7) -> 3 [12,14) -> 3 1223 2^2 Entry [7,11) -> 3 [14, 2) -> 3 1224 2^3 Entry [11,3) -> 3 [2, 10) -> 3 1225 Resources alice;resID=8 -> 3 1227 Resource Map 1228 Resource name ResID ResLocation ResStorage Location 1229 alice 8 3 10 1231 Peer 10 runs its periodic stabilization. It constructs a REGISTER as 1232 described in the Peer Query section, and sends it to its successor, 1233 Peer 3, querying for its successor's PeerID. 1235 Peer 3 checks the query to determine if it is responsible for the 1236 region the search key lies within. Because Peer 3's PeerID directly 1237 matches the search key, it sends a 200 OK response message with its 1238 current successor and predecessor specified in the DHT-Link headers. 1240 Peer 10 examines the response from Peer 3. Because the predecessor 1241 in the response from Peer 3 is the same as Peer 10, the stabilizing 1242 peer, Peer 10 is not required to do any more work. Peer 10 should 1243 perform searches to update its finger table, but these are omitted 1244 for clarity. 1246 Peer 10 Peer 3 1247 | | 1248 |(1) REGISTER | 1249 |------------------>| 1250 | | 1251 |(2) 200 | 1252 |<------------------| 1254 Peer 10 -> Peer 3 1256 REGISTER sip:192.0.2.3 SIP/2.0 1257 To: 1258 From: 1259 DHT-PeerID: ;algorithm=sha1; 1260 dht=Chord1.0;overlay=chat;expires=600 1261 Require: dht 1262 Supported: dht 1264 Peer 3 -> Peer 10 1266 SIP/2.0 200 OK 1267 To: 1268 From: 1269 Contact: 1270 Expires: 600 1271 DHT-PeerID: ;algorithm=sha1; 1272 dht=Chord1.0;overlay=chat;expires=600 1273 DHT-Link: ;link=P1;expires=0 1274 DHT-Link: ;link=S1;expires=919 1275 DHT-Link: ;link=F0;expires=919 1276 DHT-Link: ;link=F1;expires=919 1277 DHT-Link: ;link=F2;expires=125 1278 DHT-Link: ;link=F3;expires=600 1279 Require: dht 1280 Supported: dht 1282 The state stays unchanged after Peer 10's periodic stabilization. 1284 0 1 2 1285 0----0----0 1286 / \ 1287 15 0 P 3 1288 / \ 1289 14 0 0 4 1290 | | 1291 13 0 0 5 1292 | | 1293 12 0 0 6 1294 \ / 1295 11 0 0 7 1296 \ / 1297 P----0----0 1298 10 9 8 1300 Peer 3 Peer 10 1301 Successor 3 3 1302 Predecessor 10 NULL 1303 2^0 Entry [4,5) -> 3 [11,12) -> 3 1304 2^1 Entry [5,7) -> 3 [12,14) -> 3 1305 2^2 Entry [7,11) -> 3 [14, 2) -> 3 1306 2^3 Entry [11,3) -> 3 [2, 10) -> 3 1307 Resources alice;resID=8 -> 3 1309 Resource Map 1310 Resource name ResID ResLocation ResStorage Location 1311 alice 8 3 10 1313 For peer 10, there is a resource called bob that must be registered 1314 with the system. bob's contact will be sipchat/bob@192.0.2.10 and his 1315 user name will be bob@p2psip.org. bob's peer hashes his user id and 1316 determines that the corresponding resource will be 11. 1318 Bob's UA begins by constructing a SIP REGISTER message as described 1319 in Resource Registrations (Resource Registrations). Bob's UA 1320 consults its finger table, and determines that it should route 1321 requests pertaining to a Resource-ID of 5 to Peer 3. The REGISTER is 1322 sent to Peer 3, which observes that it is responsible for that 1323 portion of the namespace and replies with a 200 OK containing Peer 1324 3's predecessor and successor information in the DHT-Link headers. 1326 Peer 10 Peer 3 1327 | | 1328 |(1) REGISTER | 1329 |------------------>| 1330 | | 1331 |(2) 200 | 1332 |<------------------| 1333 | | 1335 Peer 10 -> Peer 3 1337 REGISTER sip:192.0.2.3 SIP/2.0 1338 To: 1339 From: 1340 Contact: 1341 Expires: 231 1342 DHT-PeerID: ;algorithm=sha1; 1343 dht=Chord1.0;overlay=chat;expires=600 1344 Require: dht 1345 Supported: dht 1347 Peer 3 -> Peer 10 1349 SIP/2.0 200 OK 1350 To: 1351 From: 1352 Contact: 1353 Expires: 231 1354 DHT-PeerID: ;algorithm=sha1; 1355 dht=Chord1.0;overlay=chat;expires=600 1356 DHT-Link: ;link=P1;expires=600 1357 DHT-Link: ;link=S1;expires=919 1358 DHT-Link: ;link=F0;expires=919 1359 DHT-Link: ;link=F1;expires=919 1360 DHT-Link: ;link=F2;expires=125 1361 DHT-Link: ;link=F3;expires=600 1362 Require: dht 1363 Supported: dht 1365 After bob's registration, the system state is: 1367 0 1 2 1368 0----0----0 1369 / \ 1370 15 0 P 3 1371 / \ 1372 14 0 0 4 1373 | | 1374 13 0 0 5 1375 | | 1376 12 0 0 6 1377 \ / 1378 11 0 0 7 1379 \ / 1380 P----0----0 1381 10 9 8 1383 Peer 3 Peer 10 1384 Successor 3 3 1385 Predecessor 10 NULL 1386 2^0 Entry [4,5) -> 3 [11,12) -> 3 1387 2^1 Entry [5,7) -> 3 [12,14) -> 3 1388 2^2 Entry [7,11) -> 3 [14, 2) -> 3 1389 2^3 Entry [11,3) -> 3 [2, 10) -> 3 1390 Resources bob;resID=11 -> 10 alice;resID=8 -> 3 1392 Resource Map 1393 Resource name ResID ResLocation ResStorage Location 1394 alice 8 3 10 1395 bob 11 10 3 1397 Peer 3 now runs its periodic stabilization. It constructs a REGISTER 1398 as described in the Peer Query section, and sends it to its 1399 successor, Peer 3, querying for its successor's PeerID. 1401 Peer 3 checks the query to determine if it is responsible for the 1402 region the search key lies within. Because Peer 3's PeerID directly 1403 matches the search key, it sends a 200 OK response message with its 1404 current successor and predecessor specified in the DHT-Link headers. 1406 Peer 3 examines the response from itself. Because the predecessor in 1407 the response from Peer 3 is Peer 10, Peer 3 updates its successor to 1408 be Peer 10 and sends a REGISTER to Peer 10, structured as if Peer 3 1409 had just entered the system. 1411 When Peer 10 receives the message, it then sends a 200 OK response to 1412 Peer 3. Then, Peer 10 sets its predecessor to be Peer 3 because Peer 1413 10's predecessor was NULL. 1415 Then Peer 3 should perform searches to update its finger table, but 1416 these are simple peer queries and are omitted in this example. We 1417 show the finger table as though these searches were performed. 1419 Note that because Peer 3's successor is Peer 3, we do not show such a 1420 REGISTER message being sent because implementations may choose to 1421 remove this step for efficiency. Rather we show the message sent 1422 from Peer 3 to Peer 10 that notifies Peer 10 that Peer 3 is its 1423 predecessor. 1425 Peer 3 Peer 10 1426 | | 1427 |(1) REGISTER | 1428 |------------------>| 1429 | | 1430 |(2) 200 | 1431 |<------------------| 1432 | | 1434 Peer 3 -> Peer 10 1436 REGISTER sip:192.0.2.10 SIP/2.0 1437 To: 1438 From: 1439 Contact: 1440 Expires: 600 1441 DHT-PeerID: ;algorithm=sha1; 1442 dht=Chord1.0;overlay=chat;expires=600 1443 Require: dht 1444 Supported: dht 1446 Peer 10 -> Peer 3 1448 SIP/2.0 200 OK 1449 To: 1450 From: 1451 Contact: 1452 Expires: 600 1453 DHT-PeerID: ;algorithm=sha1; 1454 dht=Chord1.0;overlay=chat;expires=600 1455 DHT-Link: ;link=S1;expires=919 1456 DHT-Link: ;link=F0;expires=919 1457 DHT-Link: ;link=F1;expires=919 1458 DHT-Link: ;link=F2;expires=125 1459 DHT-Link: ;link=F3;expires=600 1460 Require: dht 1461 Supported: dht 1463 After Peer 3's stabilization, the system state is: 1465 0 1 2 1466 0----0----0 1467 / \ 1468 15 0 P 3 1469 / \ 1470 14 0 0 4 1471 | | 1472 13 0 0 5 1473 | | 1474 12 0 0 6 1475 \ / 1476 11 0 0 7 1477 \ / 1478 P----0----0 1479 10 9 8 1481 Peer 3 Peer 10 1482 Successor 10 3 1483 Predecessor 10 3 1484 2^0 Entry [4,5) -> 10 [11,12) -> 3 1485 2^1 Entry [5,7) -> 10 [12,14) -> 3 1486 2^2 Entry [7,11) -> 10 [14, 2) -> 3 1487 2^3 Entry [11,3) -> 3 [2, 10) -> 3 1488 Resources bob;resID=11 -> 10 alice;resID=8 -> 3 1490 Resource Map 1491 Resource name ResID ResLocation ResStorage Location 1492 alice 8 3 10 1493 bob 11 10 3 1495 Next a peer with PeerID 2, IP address 192.0.2.2, and port 5060 1496 decides to join the overlay called chat. From an out of band 1497 mechanism, such as one of the ones listed in the Bootstrapping 1498 section of this document, this peer discovers peer 10. This new peer 1499 2, constructs a REGISTER and sends it to peer 10. 1501 Peer 10 verifies that 192.0.2.2 hashes to 2, then checks to see if it 1502 controls that portion of the namespace. Since it does not, it looks 1503 up in its finger table where it would route a search for 2, and 1504 determines it would send it to peer 3. The peer then sends a 302 1505 back to peer 2, with a contact of peer 3. 1507 Peer 2 then constructs a new REGISTER and sends it to Peer 3. Again, 1508 Peer 3 verifies the hash, and determines it is currently responsible 1509 for 2 in the hash space. After an optional challenge, it replies 1510 with a 200 OK message to admit the peer to the system. 1512 After sending the 200 response, Peer 3 then sets its predecessor to 1513 be Peer 2. When Peer 2 receives the 200 OK message, it will set its 1514 successor to be Peer 3 and set its predecessor to be Peer 10 (because 1515 that was the predecessor in the 200 response). Peer 2 should also 1516 perform searches to ensure that the finger table is up to date. 1517 These searches are omitted, but we update the finger table. 1519 Finally, Peer 3 sends a third party registration on behalf of bob to 1520 Peer 2, transferring bob's registration to the new peer. 1522 Peer 2 Peer 10 Peer 3 1523 | | | 1524 |(1) REGISTER | | 1525 |------------------>| | 1526 | | | 1527 |(2) 302 | | 1528 |<------------------| | 1529 | | | 1530 |(3) REGISTER | | 1531 |-------------------------------------->| 1532 | | | 1533 |(4) 200 | | 1534 |<--------------------------------------| 1535 | | | 1536 |(5) REGISTER | | 1537 |<--------------------------------------| 1538 | | | 1539 |(6) 200 | | 1540 |-------------------------------------->| 1541 | | | 1543 Peer 2 -> Peer 10 1545 REGISTER sip:192.0.2.10 SIP/2.0 1546 To: 1547 From: 1548 Contact: 1549 Expires: 600 1550 DHT-PeerID: ;algorithm=sha1; 1551 dht=Chord1.0;overlay=chat;expires=600 1552 Require: dht 1553 Supported: dht 1555 Peer 10 -> Peer 2 1557 SIP/2.0 302 Moved Temporarily 1558 To: 1559 From: 1560 Contact: 1561 Expires: 600 1562 DHT-PeerID: ;algorithm=sha1; 1563 dht=Chord1.0;overlay=chat;expires=600 1564 DHT-Link: ;link=P1;expires=919 1565 DHT-Link: ;link=S1;expires=919 1566 Require: dht 1567 Supported: dht 1569 Peer 2 -> Peer 3 1571 REGISTER sip:192.0.2.3 SIP/2.0 1572 To: 1573 From: 1574 Contact: 1575 Expires: 600 1576 DHT-PeerID: ;algorithm=sha1; 1577 dht=Chord1.0;overlay=chat;expires=600 1578 Require: dht 1579 Supported: dht 1581 Peer 3 -> Peer 2 1583 SIP/2.0 200 OK 1584 To: 1585 From: 1586 Contact: 1587 Expires: 600 1588 DHT-PeerID: ;algorithm=sha1; 1589 dht=Chord1.0;overlay=chat;expires=600 1590 DHT-Link: ;link=P1;expires=419 1591 DHT-Link: ;link=S1;expires=419 1592 DHT-Link: ;link=F0;expires=919 1593 DHT-Link: ;link=F1;expires=919 1594 DHT-Link: ;link=F2;expires=125 1595 DHT-Link: ;link=F3;expires=600 1596 Require: dht 1597 Supported: dht 1599 Peer 3 -> Peer 2 1601 REGISTER sip:2.0.0.2 SIP/2.0 1602 To: 1603 From: 1604 Contact: 1605 Expires: 201 1606 DHT-PeerID: ;algorithm=sha1; 1607 dht=Chord1.0;overlay=chat;expires=600 1608 Require: dht 1609 Supported: dht 1611 Peer 2 -> Peer 3 1613 SIP/2.0 200 OK 1614 To: 1615 From: 1616 Contact: 1617 Expires: 201 1618 DHT-PeerID: ;algorithm=sha1; 1619 dht=Chord1.0;overlay=chat;expires=600 1620 DHT-Link: ;link=S1;expires=919 1621 DHT-Link: link=P1;expires=800 1622 DHT-Link: ;link=F0;expires=919 1623 DHT-Link: ;link=F1;expires=919 1624 DHT-Link: ;link=F2;expires=125 1625 DHT-Link: ;link=F3;expires=600 1626 Require: dht 1627 Supported: dht 1629 After Peer 2's insertion, the system state is: 1631 0 1 2 1632 0----0----P 1633 / \ 1634 15 0 P 3 1635 / \ 1636 14 0 0 4 1637 | | 1638 13 0 0 5 1639 | | 1640 12 0 0 6 1641 \ / 1642 11 0 0 7 1643 \ / 1644 P----0----0 1645 10 9 8 1647 Peer 2 Peer 3 Peer 10 1648 Successor 3 10 3 1649 Predecessor 10 2 3 1650 2^0 Entry [3,4) -> 3 [4,5) -> 10 [11,12) -> 3 1651 2^1 Entry [4,6) -> 10 [5,7) -> 10 [12,14) -> 3 1652 2^2 Entry [6,10) -> 10 [7,11) -> 10 [14, 2) -> 3 1653 2^3 Entry [10,2) -> 10 [11, 3) -> 3 [2, 10) -> 3 1654 Resources bob;resID=11 -> 10 alice;resID=8 -> 3 1656 Resource Map 1657 Resource name ResID ResLocation ResStorage Location 1658 alice 8 3 10 1659 bob 11 10 2 1661 Peer 3 now runs its periodic stabilization. It constructs a REGISTER 1662 as described in the Peer Query section, and sends it to its 1663 successor, Peer 10, querying for its successor's PeerID. 1665 Peer 10 checks the query to determine if it is responsible for the 1666 region the search key lies within. Because Peer 10's PeerID directly 1667 matches the search key, it sends a 200 OK response message with its 1668 current successor and predecessor specified in the DHT-Link headers. 1670 Peer 3 examines the response from itself. Because the predecessor in 1671 the response form Peer 10 is the same as Peer3, the stabilizing peer, 1672 Peer 3 does not need to send any messages to the predecessor. At 1673 this point Peer 3 should send queries to ensure that the finger table 1674 is up to date. We do not show the SIP messages for this process, but 1675 do show the resulting changes in Peer 3's finger table. 1677 Peer 3 Peer 10 1678 | | 1679 |(1) REGISTER | 1680 |------------------>| 1681 | | 1682 |(2) 200 | 1683 |<------------------| 1685 Peer 10 -> Peer 3 1687 REGISTER sip:192.0.2.10 SIP/2.0 1688 To: 1689 From: 1690 DHT-PeerID: ;algorithm=sha1; 1691 dht=Chord1.0;overlay=chat;expires=600 1692 Require: dht 1693 Supported: dht 1695 Peer 10 -> Peer 3 1697 SIP/2.0 200 OK 1698 To: 1699 From: 1700 Contact: 1701 Expires: 600 1702 DHT-PeerID: ;algorithm=sha1; 1703 dht=Chord1.0;overlay=chat;expires=600 1704 DHT-Link: ;link=P1;expires=0 1705 DHT-Link: ;link=S1;expires=919 1706 DHT-Link: ;link=F0;expires=919 1707 DHT-Link: ;link=F1;expires=919 1708 DHT-Link: ;link=F2;expires=125 1709 DHT-Link: ;link=F3;expires=600 1710 Require: dht 1711 Supported: dht 1713 The state after Peer 3's periodic stabilization: 1715 0 1 2 1716 0----0----P 1717 / \ 1718 15 0 P 3 1719 / \ 1720 14 0 0 4 1721 | | 1722 13 0 0 5 1723 | | 1724 12 0 0 6 1725 \ / 1726 11 0 0 7 1727 \ / 1728 P----0----0 1729 10 9 8 1731 Peer 2 Peer 3 Peer 10 1732 Successor 3 10 3 1733 Predecessor 10 2 3 1734 2^0 Entry [3,4) -> 3 [4,5) -> 10 [11,12) -> 3 1735 2^1 Entry [4,6) -> 10 [5,7) -> 10 [12,14) -> 3 1736 2^2 Entry [6,10) -> 10 [7,11) -> 10 [14, 2) -> 3 1737 2^3 Entry [10,2) -> 10 [11, 3) -> 2 [2, 10) -> 3 1738 Resources bob;resID=11->10 alice;resID=8 -> 3 1740 Resource Map 1741 Resource name ResID ResLocation ResStorage Location 1742 alice 8 3 10 1743 bob 11 10 2 1745 Peer 10 now runs its periodic stabilization. It constructs a 1746 REGISTER as described in the Peer Query section, and sends it to its 1747 successor, Peer 3, querying for its successor's PeerID. 1749 Peer 3 checks the query to determine if it is responsible for the 1750 region the search key lies within. Because Peer 3's PeerID directly 1751 matches the search key, it sends a 200 OK response with its current 1752 successor and predecessor in the response. 1754 Because the predecessor in the response from Peer 3 is Peer 2, Peer 1755 10 updates its successor to be Peer 2 and sends a REGISTER to Peer 2, 1756 structured as if Peer 10 had just entered the system. 1758 When Peer 2 receives the message, it then sends a 200 OK response to 1759 Peer 10. Then, Peer 2 updates its predecessor to be Peer 10. 1761 Then Peer 10 should perform searches to update its finger table. 1763 These are simple peer queries and are omitted in this example, but we 1764 have updated the finger table. 1766 Peer 10 Peer 3 Peer 2 1767 | | | 1768 |(1) REGISTER | | 1769 |------------------>| | 1770 | | | 1771 |(2) 200 | | 1772 |<------------------| | 1773 | | | 1774 |(3) REGISTER | | 1775 |-------------------------------------->| 1776 | | | 1777 |(4) 200 | | 1778 |<--------------------------------------| 1779 | | | 1781 Peer 10 -> Peer 3 1783 REGISTER sip:3.0.0.3 SIP/2.0 1784 To: 1785 From: 1786 DHT-PeerID: ;algorithm=sha1; 1787 dht=Chord1.0;overlay=chat;expires=600 1788 Require: dht 1789 Supported: dht 1791 Peer 3 -> Peer 10 1793 SIP/2.0 200 OK 1794 To: 1795 From: 1796 Contact: 1797 Expires: 600 1798 DHT-PeerID: ;algorithm=sha1; 1799 dht=Chord1.0;overlay=chat;expires=600 1800 DHT-Link: ;link=P1;expires=0 1801 DHT-Link: ;link=S1;expires=919 1802 DHT-Link: ;link=F0;expires=919 1803 DHT-Link: ;link=F1;expires=919 1804 DHT-Link: ;link=F2;expires=125 1805 DHT-Link: ;link=F3;expires=600 1806 Require: dht 1807 Supported: dht 1808 Peer 10 -> Peer 2 1810 REGISTER sip:192.0.2.2 SIP/2.0 1811 To: 1812 From: 1813 Contact: 1814 Expires: 600 1815 DHT-PeerID: ;algorithm=sha1; 1816 dht=Chord1.0;overlay=chat;expires=600 1817 Require: dht 1818 Supported: dht 1820 Peer 2 -> Peer 10 1822 SIP/2.0 200 OK 1823 To: 1824 From: 1825 Contact: 1826 Expires: 600 1827 DHT-PeerID: ;algorithm=sha1; 1828 dht=Chord1.0;overlay=chat;expires=600 1829 DHT-Link: ;link=P1;expires=419 1830 DHT-Link: ;link=S1;expires=419 1831 DHT-Link: ;link=F0;expires=919 1832 DHT-Link: ;link=F1;expires=919 1833 DHT-Link: ;link=F2;expires=125 1834 DHT-Link: ;link=F3;expires=600 1835 Require: dht 1836 Supported: dht 1838 After Peer 10's stabilization, the system state is: 1840 0 1 2 1841 0----0----P 1842 / \ 1843 15 0 P 3 1844 / \ 1845 14 0 0 4 1846 | | 1847 13 0 0 5 1848 | | 1849 12 0 0 6 1850 \ / 1851 11 0 0 7 1852 \ / 1853 P----0----0 1854 10 9 8 1856 Peer 2 Peer 3 Peer 10 1857 Successor 3 10 2 1858 Predecessor 10 2 3 1859 2^0 Entry [3,4) -> 3 [4,5) -> 10 [11,12) -> 3 1860 2^1 Entry [4,6) -> 10 [5,7) -> 10 [12,14) -> 3 1861 2^2 Entry [6,10) -> 10 [7,11) -> 10 [14, 2) -> 3 1862 2^3 Entry [10,2) -> 10 [11, 3) -> 2 [2, 10) -> 2 1863 Resources bob;resID=11 -> 10 alice;resID=8 -> 3 1865 Resource Map 1866 Resource name ResID ResLocation ResStorage Location 1867 alice 8 3 10 1868 bob 11 10 2 1870 This system now has 3 peers in a stable state, such that all 1871 predecessor and successor information is correct, and two user 1872 resources are stored in the overlay. 1874 7.5. Example of a Peer Leaving the System 1876 [To Do: Add an example here] 1878 7.6. Example of a Successful User Search 1880 [To Do: Add an example here] 1882 7.7. Example of an Unsucessful User Search 1884 [To Do: Add an example here] 1886 8. Security Considerations 1888 There are no new security considerations introduced in this draft 1889 beyond those already mentioned in the dSIP [I-D.bryan-p2psip-dsip] 1890 and Security for P2PSIP [I-D.lowekamp-p2psip-dsip-security] drafts. 1892 9. Open Issues 1894 There are certainly many open issues. Here are a few. 1896 Should it be possible to trigger a node to recheck a finger table 1897 entry after it 302s to a node that appears to be down? Presumably 1898 this can be integrated together with the loose routing NAT traversal. 1900 During graceful exit, should it be possible to trigger another peer 1901 to check its predecessor? 1903 The periodic stabilization operation is identical to the original 1904 chord operation, but it seems like we can pay attention to the 1905 response and observe if there have been multiple peers inserted and 1906 the peer we sent the REGISTER to knows a better successor peer, but 1907 this goes away with the next stabilize, anyway. 1909 10. Acknowledgements 1911 A team of people have worked on the various drafts related to the 1912 dSIP protocol and extensions thereof. The team consists of: David 1913 Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, 1914 Philip Matthews, and Marcia Zangrilli. 1916 Thanks to all who have been actively participating in the P2PSIP 1917 efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and 1918 Jean-Francois Wauthy for providing editorial feedback, and Henry 1919 Sinnreich, Eric Rescorla, and Alan Johnston for various discussions 1920 related to this work. 1922 11. IANA Considerations 1924 This document defines the valid "link-value" values, and defines the 1925 "dht-param" value to be "Chord1.0". 1927 12. Changes to this Version 1929 While this is a -00 document, it has grown from sections of the 1930 earlier draft-bryan-sipping-p2p-xx. 1932 13. References 1934 13.1. Normative References 1936 [I-D.bryan-p2psip-dsip] 1937 Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P 1938 Approach to SIP Registration and Resource Location", 1939 Internet Draft draft-bryan-p2psip-dsip-00, February 2007. 1941 [I-D.lowekamp-p2psip-dsip-security] 1942 Lowekamp, B. and J. Deverick, "Authenticated Identity 1943 Extensions to dSIP", Internet 1944 Draft draft-lowekamp-p2psip-dsip-security-00, 1945 February 2007. 1947 [I-D.willis-p2psip-concepts] 1948 Willis, D., "Concepts and Terminology for Peer to Peer 1949 SIP", draft-willis-p2psip-concepts-03 (work in progress), 1950 October 2006. 1952 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1953 Hashing for Message Authentication", RFC 2104, 1954 February 1997. 1956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1957 Requirement Levels", BCP 14, RFC 2119, March 1997. 1959 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1960 (SHA1)", RFC 3174, September 2001. 1962 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1963 A., Peterson, J., Sparks, R., Handley, M., and E. 1964 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1965 June 2002. 1967 13.2. Informative References 1969 [Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., 1970 Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A 1971 Scalable Peer-to-peer Lookup Service for Internet 1972 Applications", IEEE/ACM Transactions on Networking Volume 1973 11, Issue 1, 17-32, Feb 2003. 1975 Authors' Addresses 1977 Marcia Zangrilli 1978 SIPeerior Technologies 1979 3000 Easter Circle 1980 Williamsburg, VA 23188 1981 USA 1983 Phone: +1 757 565 0101 1984 Email: marcia@sipeerior.com 1986 David A. Bryan 1987 SIPeerior Technologies 1988 3000 Easter Circle 1989 Williamsburg, VA 23188 1990 USA 1992 Phone: +1 757 565 0101 1993 Email: dbryan@sipeerior.com 1995 Full Copyright Statement 1997 Copyright (C) The IETF Trust (2007). 1999 This document is subject to the rights, licenses and restrictions 2000 contained in BCP 78, and except as set forth therein, the authors 2001 retain all their rights. 2003 This document and the information contained herein are provided on an 2004 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2005 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2006 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2007 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2008 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2009 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2011 Intellectual Property 2013 The IETF takes no position regarding the validity or scope of any 2014 Intellectual Property Rights or other rights that might be claimed to 2015 pertain to the implementation or use of the technology described in 2016 this document or the extent to which any license under such rights 2017 might or might not be available; nor does it represent that it has 2018 made any independent effort to identify any such rights. Information 2019 on the procedures with respect to rights in RFC documents can be 2020 found in BCP 78 and BCP 79. 2022 Copies of IPR disclosures made to the IETF Secretariat and any 2023 assurances of licenses to be made available, or the result of an 2024 attempt made to obtain a general license or permission for the use of 2025 such proprietary rights by implementers or users of this 2026 specification can be obtained from the IETF on-line IPR repository at 2027 http://www.ietf.org/ipr. 2029 The IETF invites any interested party to bring to its attention any 2030 copyrights, patents or patent applications, or other proprietary 2031 rights that may cover technology that may be required to implement 2032 this standard. Please address the information to the IETF at 2033 ietf-ipr@ietf.org. 2035 Acknowledgment 2037 Funding for the RFC Editor function is provided by the IETF 2038 Administrative Support Activity (IASA).