idnits 2.17.1 draft-ietf-p2psip-concepts-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1277. 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 == Line 1168 has weird spacing: '...ased on the C...' -- 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 (June 2007) is 6159 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-00 == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-06 == Outdated reference: A later version (-01) exists of draft-marocco-p2psip-xpp-pcan-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group D. Bryan 3 Internet-Draft College of William and Mary and 4 Intended status: Informational SIPeerior Technologies 5 Expires: December 3, 2007 P. Matthews 6 Avaya 7 E. Shim 8 Locus Telecommunications 9 D. Willis 10 Unaffiliated 11 June 2007 13 Concepts and Terminology for Peer to Peer SIP 14 draft-ietf-p2psip-concepts-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 3, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document defines concepts and terminology for use of the Session 48 Initiation Protocol in a peer-to-peer environment where the 49 traditional proxy-registrar and message routing functions are 50 replaced by a distributed mechanism that might be implemented using a 51 distributed hash table or other distributed data mechanism with 52 similar external properties. This document includes a high-level 53 view of the functional relationships between the network elements 54 defined herein, a conceptual model of operations, and an outline of 55 the related open problems being addressed by the P2PSIP working 56 group. As this document matures, it is expected to define the 57 general framework for P2PSIP. 59 Table of Contents 61 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. High Level Description . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4. Relationship of Peer and Client Protocols . . . . . . . . 6 68 2.5. Relationship Between P2PSIP and SIP . . . . . . . . . . . 6 69 2.6. Relationship Between P2PSIP and Other AoR 70 Dereferencing Approaches . . . . . . . . . . . . . . . . . 6 71 2.7. NAT Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. The Distributed Database Function . . . . . . . . . . . . 13 79 5.2. Using the Distributed Database Function . . . . . . . . . 15 80 5.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 81 5.4. Locating and Joining an Overlay . . . . . . . . . . . . . 20 82 5.5. Possible Client Behavior . . . . . . . . . . . . . . . . . 21 83 5.6. Interacting with non-P2PSIP entities . . . . . . . . . . . 22 85 6. Additional Questions . . . . . . . . . . . . . . . . . . . . . 23 86 6.1. Selecting between Multiple Peers offering the Same 87 Service . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 6.2. Visibility of Messages to Intermediate Peers . . . . . . . 23 89 6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA . . 23 90 6.4. Clients, Peers, and Services . . . . . . . . . . . . . . . 24 91 6.5. Relationships of Domains to Overlays . . . . . . . . . . . 24 92 6.6. Protocol Layering . . . . . . . . . . . . . . . . . . . . 24 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 97 9. Changes in This Version . . . . . . . . . . . . . . . . . . . 25 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 106 Intellectual Property and Copyright Statements . . . . . . . . . . 30 108 1. Background 110 One of the fundamental problems in multimedia communication between 111 Internet nodes is that of discovering the host at which a given user 112 can be reached. In the Session Initiation Protocol (SIP) [RFC3261] 113 this problem is expressed as the problem of mapping an Address of 114 Record (AoR) for a user into one or more Contact URIs [RFC3986]. The 115 AoR is a name for the user that is independent of the host or hosts 116 where the user can be contacted, while a Contact URI indicates the 117 host where the user can be contacted. 119 In the common SIP-using architectures that we refer to as 120 "Conventional SIP" or "Client/Server SIP", there is a relatively 121 fixed hierarchy of SIP routing proxies and SIP user agents. To 122 deliver a SIP INVITE to the host or hosts at which the user can be 123 contacted, a SIP UA follows the procedures specified in [RFC3263] to 124 determine the IP address of a SIP proxy, and then sends the INVITE to 125 that proxy. The proxy will then, in turn, deliver the SIP INVITE to 126 the hosts where the user can be contacted. 128 This document gives a high-level description of an alternative 129 solution to this problem. In this alternative solution, the 130 relatively fixed hierarchy of Client/Server SIP is replaced by a 131 peer-to-peer overlay network. In this peer-to-peer overlay network, 132 the various AoR to Contact URI mappings are not centralized at proxy/ 133 registrar nodes but are instead distributed amongst the peers in the 134 overlay. 136 The details of this alternative solution are currently being worked 137 out in the P2PSIP working group. This document describes the basic 138 concepts of such a peer-to-peer overlay, and lists the open questions 139 that still need to be resolved. As the work proceeds, it is expected 140 that this document will develop into a high-level architecture 141 document for the solution. 143 2. High Level Description 145 A P2PSIP Overlay is a collection of nodes organized in a peer-to-peer 146 fashion for the purpose of enabling real-time communication using the 147 Session Initiation Protocol (SIP). Collectively, the nodes in the 148 overlay provide a distributed mechanism for mapping names to network 149 locations. This provides for the mapping of Addresses of Record 150 (AoRs) to Contact URIs, thereby providing the "location server" 151 function of [RFC3261]. A P2PSIP Overlay also provides a transport 152 function by which SIP messages can be transported between any two 153 nodes in the overlay. 155 A P2PSIP Overlay consists of one or more nodes called P2PSIP Peers. 156 The peers in the overlay collectively run a distributed database 157 algorithm. This distributed database algorithm allows data to be 158 stored on peers and retrieved in an efficient manner. It may also 159 ensure that a copy of a data item is stored on more than one peer, so 160 that the loss of a peer does not result in the loss of the data item 161 to the overlay. 163 One use of this distributed database is to store the information 164 required to provide the mapping between AoRs and Contact URIs for the 165 distributed location function. This provides a location function 166 within each overlay that is an alternative to the location functions 167 described in [RFC3263]. However, the model of [RFC3263] is used 168 between overlays. 170 2.1. Services 172 The nature of peer-to-peer computing is that each peer offers 173 services to other peers to allow the overlay to collectively provide 174 larger functions. In P2PSIP, peers offer storage and transport 175 services to allow the distributed database function and distributed 176 transport function to be implemented. It is expected that individual 177 peers may also offer other services. Some of these additional 178 services (for example, a STUN server service 179 [I-D.ietf-behave-rfc3489bis]) may be required to allow the overlay to 180 form and operate, while others (for example, a voicemail service) may 181 be enhancements to the basic P2PSIP functionality. 183 To allow peers to offer these additional services, the distributed 184 database may need to store information about services. For example, 185 it may need to store information about which peers offer which 186 services, and perhaps what sort of capacity each peer has for 187 delivering each listed service. 189 2.2. Clients 191 An overlay may or may not also include one or more nodes called 192 P2PSIP Clients. The role of a client in the P2PSIP model is still 193 under discussion, with a number of suggestions for roles being put 194 forth, and some arguing that clients are not needed at all. However, 195 if they exist, then people agree that they will also be able to store 196 and retrieve information from the overlay. Section 5.5 discusses the 197 possible roles of a client in more detail. 199 2.3. Protocol 201 Peers in an overlay need to speak some protocol between themselves to 202 maintain the overlay and to store and retrieve data. Until a better 203 name is found, this protocol has been dubbed the P2PSIP Peer 204 Protocol. The details of this protocol are still very much under 205 debate: some have suggested that the protocol should be SIP with some 206 extensions, while others have suggested that it should be an entirely 207 new protocol. 209 2.4. Relationship of Peer and Client Protocols 211 If the P2PSIP model also contains clients, then a protocol is needed 212 for client - peer communication. Until a better name is found, this 213 protocol has been dubbed the P2PSIP Client Protocol. The details of 214 this protocol are also very much under debate. However, if the 215 client protocol exists, then it is agreed that it should be a logical 216 subset of the peer protocol. In other words, the syntax of the peer 217 and client protocols may be completely different, but any operation 218 supported by client protocol is also supported by the peer protocol. 219 This implies that clients cannot do anything that peers cannot also 220 do. 222 2.5. Relationship Between P2PSIP and SIP 224 Since P2PSIP is about peer-to-peer networks for real-time 225 communication, it is expected that most (if not all) peers and 226 clients will be coupled with SIP entities. For example, one peer 227 might be coupled with a SIP UA, another might be coupled with a SIP 228 proxy, while a third might be coupled with a SIP-to-PSTN gateway. 229 For such nodes, we think of the peer or client portion of the node as 230 being distinct from the SIP entity portion. However, there is no 231 hard requirement that every P2PSIP node (peer or client) be coupled 232 to a SIP entity, and some proposed architectures include peer nodes 233 that have no SIP function whatsoever. 235 2.6. Relationship Between P2PSIP and Other AoR Dereferencing Approaches 237 As noted above, the fundamental task of P2PSIP is turning an AoR into 238 a Contact. This task might be approached using zeroconf techniques 239 such as multicast DNS and DNS Service Discovery (as in Apple's 240 Bonjour protocol), link-local multicast name resolution [RFC4795], 241 and dynamic DNS [RFC2136]. 243 These alternatives were discussed in the P2PSIP Working Group, and 244 not pursued as a general solution for a number of reasons related to 245 scalability, the ability to work in a disconnected state, partition 246 recovery, and so on. However, there does seem to be some continuing 247 interest in the possibility of using DNS-SD and mDNS for 248 bootstrapping of P2PSIP overlays. 250 2.7. NAT Issues 252 Network Address Translators (NATs) are impediments to establishing 253 and maintaining peer-to-peer networks, since NATs hinder direct 254 communication between peers. Some peer-to-peer network architectures 255 avoid this problem by insisting that all peers exist in the same 256 address space. However, in the P2PSIP model, it has been agreed that 257 peers can live in multiple address spaces interconnected by NATs. 258 This implies that Peer Protocol connections must be able to traverse 259 NATs. It also means that the peers must collectively provide a 260 distributed transport function that allows a peer to send a SIP 261 message to any other peer in the overlay - without this function two 262 peers in different IP address spaces might not be able to exchange 263 SIP messages. 265 3. Reference Model 267 The following diagram shows a P2PSIP Overlay consisting of a number 268 of P2PSIP Peers and one P2PSIP Client. It also shows an ordinary SIP 269 UA. 271 --->PSTN 272 +------+ N +------+ +---------+ / 273 | | A | | | Gateway |-/ 274 | UA |####T#####| UA |#####| Peer |######## 275 | Peer | N | Peer | | G | # P2PSIP 276 | E | A | F | +---------+ # Client 277 | | T | | # Protocol 278 +------+ N +------+ # | 279 # A # | 280 NATNATNATNAT # | 281 # # | \__/ 282 NATNATNATNAT +-------+ v / \ 283 # N | |=====/ UA \ 284 +------+ A P2PSIP Overlay | Peer | /Client\ 285 | | T | Q | |___C__| 286 | UA | N | | 287 | Peer | A +-------+ 288 | D | T # 289 | | N # 290 +------+ A # P2PSIP 291 # T # Peer 292 # N +-------+ +-------+ # Protocol 293 # A | | | | # 294 #########T####| Proxy |########| Redir |####### 295 N | Peer | | Peer | 296 A | P | | R | 297 T +-------+ +-------+ 298 | / 299 | SIP / 300 \__/ / / 301 /\ / ______________/ SIP 302 / \/ / 303 / UA \/ 304 /______\ 305 SIP UA A 307 Figure: P2PSIP Overlay Reference Model 309 Here, the large perimeter depicted by "#" represents a stylized view 310 of the P2PSIP Overlay (the actual connections could be a mesh, a 311 ring, or some other structure). Around the periphery of the P2PSIP 312 Overlay rectangle, we have a number of P2PSIP Peers. Each peer is 313 labeled with its coupled SIP entity -- for example, "Proxy Peer P" 314 means that peer P which is coupled with a SIP proxy. In some cases, 315 a peer or client might be coupled with two or more SIP entities. In 316 this diagram we have a PSTN gateway coupled with peer "G", three 317 peers ("D", "E" and "F") which are each coupled with a UA, a peer "P" 318 which is coupled with a SIP proxy, an ordinary peer "Q", and one peer 319 "R" which is coupled with a SIP Redirector. Note that because these 320 are all P2PSIP Peers, each is responsible for storing P2PSIP Resource 321 Records and transporting messages around the P2PSIP Overlay. 323 To the left, two of the peers ("D" and "E") are behind network 324 address translators (NATs). These peers are included in the P2PSIP 325 overlay and thus participate in storing resource records and routing 326 messages, despite being behind the NATs. 328 Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is 329 not part of the P2PSIP Overlay, either directly as a peer or 330 indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP 331 Client protocols. Instead, it uses SIP to interact with the P2PSIP 332 Overlay. 334 On the right side, we have a P2PSIP client "C", which uses the P2PSIP 335 Client Protocol depicted by "=" to communicate with Proxy Peer "Q". 336 The P2PSIP client "C" could communicate with a different peer, for 337 example peer "F", if it establishes a connection to "F" instead of or 338 in addition to "Q". The exact role that this client plays in the 339 network is still under discussion (see Section 5.5). 341 Both the SIP proxy coupled with peer "P" and the SIP redirector 342 coupled with peer "R" can serve as adapters between ordinary SIP 343 devices and the P2PSIP Overlay. Each accepts standard SIP requests 344 and resolves the next-hop by using the P2PSIP overlay Peer Protocol 345 to interact with the routing knowledge of the P2PSIP Overlay, then 346 processes the SIP requests as appropriate (proxying or redirecting 347 towards the next-hop). Note that proxy operation is bidirectional - 348 the proxy may be forwarding a request from an ordinary SIP device to 349 the P2PSIP overlay, or from the P2PSIP overlay to an ordinary SIP 350 device. 352 The PSTN Gateway at peer "G" provides a similar sort of adaptation to 353 and from the public switched telephone network (PSTN). 355 4. Definitions 357 This section defines a number of concepts that are key to 358 understanding the P2PSIP work. 360 Overlay Network: An overlay network is a computer network which is 361 built on top of another network. Nodes in the overlay can be 362 thought of as being connected by virtual or logical links, each of 363 which corresponds to a path, perhaps through many physical links, 364 in the underlying network. For example, many peer-to-peer 365 networks are overlay networks because they run on top of the 366 Internet. Dial-up Internet is an overlay upon the telephone 367 network. 369 P2P Network: A peer-to-peer (or P2P) computer network is a network 370 that relies primarily on the computing power and bandwidth of the 371 participants in the network rather than concentrating it in a 372 relatively low number of servers. P2P networks are typically used 373 for connecting nodes via largely ad hoc connections. Such 374 networks are useful for many purposes. Sharing content files (see 375 ) containing audio, 376 video, data or anything in digital format is very common, and 377 realtime data, such as telephony traffic, is also exchanged using 378 P2P technology. . A 379 P2P Network may also be called a "P2P Overlay" or "P2P Overlay 380 Network" or "P2P Network Overlay", since its organization is not 381 at the physical layer, but is instead "on top of" an existing 382 Internet Protocol network. 384 P2PSIP: A suite of communications protocols related to the Session 385 Initiation Protocol (SIP) [RFC3261] that enable SIP to use peer- 386 to-peer techniques for resolving the targets of SIP requests, 387 providing SIP message transport, and providing other SIP-related 388 functions. The exact contents of this protocol suite are still 389 under discussion, but is likely to include the P2PSIP Peer 390 Protocol and may include a P2PSIP Client Protocol (see definitions 391 below). 393 P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or 394 federation of nodes that provides SIP registration, SIP message 395 transport, and similar functions using a P2P organization, as 396 defined by "P2P Network" above. 398 P2PSIP Overlay Name: A human-friendly name that identifies a 399 specific P2PSIP Overlay. This is in the format of (a portion of) 400 a URI, but may or may not have a related record in the DNS. 402 P2PSIP Peer: A node participating in a P2PSIP Overlay that provides 403 storage and transport services to other nodes in that P2PSIP 404 Overlay. Each P2PSIP Peer has a unique identifier, known as a 405 Peer-ID, within the P2PSIP Overlay. Each P2PSIP Peer may be 406 coupled to one or more SIP entities. Within the P2PSIP Overlay, 407 the peer is capable of performing several different operations, 408 including: joining and leaving the overlay, transporting SIP 409 messages within the overlay, storing information on behalf of the 410 overlay, putting information into the overlay, and getting 411 information from the overlay. 413 P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP 414 Peer within a given P2PSIP Overlay. This value is not human- 415 friendly -- in a DHT approach, this is a numeric value in the hash 416 space. These Peer-IDs are completely independent of the 417 identifier of any user of a user agent associated with a peer. 418 (Note: This is often called a "Node-ID" in the P2P literature). 420 P2PSIP Client: A node participating in a P2PSIP Overlay that is less 421 capable than a P2PSIP Peer in some way. The role of a P2PSIP 422 Client is still under debate, with a number of competing 423 proposals, and some have suggested removing the concept entirely 424 (see the discussion on this later in the document). If clients 425 exist, then it has been agreed that they do have the ability to 426 add, modify, inspect, and delete information in the overlay. Note 427 that the term client does not imply that this node is a SIP UAC. 428 Some have suggested that the word 'client' be changed to something 429 else to avoid both this confusion and the implication of a client- 430 server relationship. 432 User: A human that interacts with the overlay through SIP UAs 433 located on peers and clients (and perhaps other ways). 435 P2PSIP User Name: A human-friendly name for a user. This name must 436 be unique within the overlay, but may be unique in a wider scope. 437 User Names are formatted so that they can be used within a URI 438 (likely a SIP URI), perhaps in combination with the Overlay Name. 440 P2PSIP Service: A capability contributed by a peer to an overlay or 441 to the members of an overlay. It is expected that not all peers 442 and clients will offer the same set of services, so a means of 443 finding peers (and perhaps clients) that offer a particular 444 service is required. Services might include routing of requests, 445 storing of routing data, storing of other data, STUN discovery, 446 STUN relay, and many other things. This model posits a 447 requirement for a service locator function, possibly including 448 supporting information such as the capacity of a peer to provide a 449 specific service or descriptions of the policies under which a 450 peer will provide that service. We currently expect that we will 451 need to be able to search for available service providers within 452 each overlay. We think we might need to be able to make searches 453 based on network locality or path minimalization. 455 P2PSIP Service Name: A unique, human-friendly, name for a service. 457 P2PSIP Resource: Anything about which information can be stored in 458 the overlay. Both Users and Services are examples of Resources. 460 P2PSIP Resource-ID: A non-human-friendly value that uniquely 461 identifies a resource and which is used as a key for storing and 462 retrieving data about the resource. One way to generate a 463 Resource-ID is by applying a mapping function to some other unique 464 name (e.g., User Name or Service Name) for the resource. The 465 Resource-ID is used by the distributed database algorithm to 466 determine the peer or peers that are responsible for storing the 467 data for the overlay. 469 P2PSIP Resource Record: A block of data, stored using distributed 470 database mechanism of the P2PSIP Overlay, that includes 471 information relevant to a specific resource. We presume that 472 there may be multiple types of resource records. Some may hold 473 data about Users, and others may hold data about Services, and the 474 working group may define other types. The types, usages, and 475 formats of the records are a question for future study. 477 P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay 478 peers to share information and organize the P2PSIP Overlay 479 Network. 481 P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients 482 and P2PSIP Peers. It is used to store and retrieve information 483 from the P2P Overlay. The nature of this protocol, and even its 484 existence, is under discussion. However, if it exists, it has 485 been agreed that the Client Protocol is a functional subset of the 486 P2P Peer Protocol, but may differ in syntax and protocol 487 implementation (i.e., may not be syntactically related). 489 P2PSIP Peer Protocol Connection / P2PSIP Client Protocol Connection: 490 The TCP, UDP or other transport layer protocol connection over 491 which the P2PSIP Peer Protocol (or respectively the Client 492 protocol) is transported. 494 P2PSIP Neighbors: The set of P2PSIP Peers that either a P2PSIP Peer 495 or P2PSIP Client know of directly and can reach without further 496 lookups. 498 P2PSIP Joining Peer: A node that is attempting to become a P2PSIP 499 Peer in a particular P2PSIP Overlay. 501 P2PSIP Bootstrap Peer: A P2PSIP Peer in the P2PSIP Overlay that is 502 the first point of contact for a P2PSIP Joining Peer. It selects 503 the peer that will serve as the P2PSIP Admitting Peer and helps 504 the joining peer contact the admitting peer. 506 P2PSIP Admitting Peer: A P2PSIP Peer in the P2PSIP Overlay which 507 helps the P2PSIP Joining Peer join the Overlay. The choice of the 508 admitting peer may depend on the joining peer (e.g., depend the 509 joining peer's P2PSIP Peer-ID). For example, the admitting peer 510 might be chosen as the peer which is "closest" in the logical 511 structure of the overlay to the future position of the joining 512 peer. The selection of the admitting peer is typically done by 513 the bootstrap peer. It is allowable for the bootstrap peer to 514 select itself as the admitting peer. 516 P2PSIP Bootstrap Server: A network node used by P2PSIP Joining Peers 517 to locate a P2PSIP Bootstrap Peer. Typically, a P2PSIP Bootstrap 518 Server acts as a proxy for messages between the P2PSIP Joining 519 Peer and the P2PSIP Bootstrap Peer. The P2PSIP Bootstrap Server 520 itself is typically a stable host with a DNS name that is somehow 521 communicated (for example, through configuration) to peers that 522 want to join the overlay. A P2PSIP Bootstrap Server is NOT 523 required to be a peer or client, though it may be if desired. 525 P2PSIP Peer Admission: The act of admitting a node (the "P2PSIP 526 Joining Peer") into a P2PSIP Overlay as a P2PSIP Peer. After the 527 admission process is over, the joining peer is a fully-functional 528 peer of the overlay. During the admission process, the joining 529 peer may need to present credentials to prove that it has 530 sufficient authority to join the overlay. 532 P2PSIP Resource Record Insertion: The act of inserting a P2PSIP 533 Resource Record into the distributed database. Following 534 insertion, the data will be stored at one or more peers. The data 535 can be retrieved or updated using the P2PSIP Resource-ID as a key. 537 5. Discussion 539 5.1. The Distributed Database Function 541 A P2PSIP Overlay functions as a distributed database. The database 542 serves as a way to store information about things called Resources. 543 A piece of information, called a Resource Record, can be stored by 544 and retrieved from the database using a key associated with the 545 Resource Record called its Resource-ID. Each Resource must have a 546 unique Resource-ID. In addition to uniquely identifying the 547 Resource, the Resource-ID is also used by the distributed database 548 algorithm to determine the peer or peers that store the Resource 549 Record in the overlay. 551 It is expected that the P2PSIP working group will standardize the 552 way(s) certain types of resources are represented in the distributed 553 database. 555 One type of resource representation that the working group is 556 expected to standardize is information about users. Users are humans 557 that can use the overlay to do things like making and receiving 558 calls. Information stored in the resource record associated with a 559 user might include things like the full name of the user and the 560 location of the UAs that the user is using. 562 Before information about a user can be stored in the overlay, a user 563 needs a User Name. The User Name is a human-friendly identifier that 564 uniquely identifies the user within the overlay. The User Name is 565 not a Resource-ID, rather the Resource-ID is derived from the User 566 Name using some mapping function (often a cryptographic hash 567 function) defined by the distributed database algorithm used by the 568 overlay. 570 The overlay may also require that the user have a set of credentials. 571 Credentials may be required to authenticate the user and/or to show 572 that the user is authorized to use the overlay. 574 Another type of resource representation that the working group is 575 expected to standardize is information about services. Services 576 represent actions that a peer (and perhaps a client) can do to 577 benefit other peers and clients in the overlay. Information that 578 might be stored in the resource record associated with a service 579 might include the peers (and perhaps clients) offering the service. 581 Each service has a human-friendly Service Name that uniquely 582 identifies the service. Like User Names, the Service Name is not a 583 resource-id, rather the resource-id is derived from the service name 584 using some function defined by the distributed database algorithm 585 used by the overlay. 587 It is expected that the working group will standardize at least one 588 service. For each standardized service, the working group will 589 likely specify the service name, the nature and format of the 590 information stored in the resource record associated with the 591 service, and the protocol used to access the service. 593 The overlay may require that the peer (or client) have a set of 594 credentials for a service. For example, credentials might be 595 required to show that the peer (or client) is authorized to offer the 596 service, or to show that the peer (or client) is a providing a 597 trustworthy implementation of the service. 599 It is expected that the P2PSIP WG will not standardize how a User 600 Name is obtained, nor how the credentials associated with a User Name 601 or a Service Name are obtained, but merely standardize at least one 602 acceptable format for each. To ensure interoperability, it is 603 expected that at least one of these formats will be specified as 604 "mandatory-to-implement". 606 A class of algorithms known as Distributed Hash Tables 607 are one way to implement 608 the Distributed Database. In particular, both the Chord and Bamboo 609 algorithms have been suggested as good choices for the distributed 610 database algorithm. However, no decision has been taken so far. 612 5.2. Using the Distributed Database Function 614 There are a number of ways the distributed database described in the 615 previous section might be used to establish multimedia sessions using 616 SIP. In this section, we give four possibilities as examples. It 617 seems likely that the working group will standardize at least one way 618 (not necessarily one of the four listed here), but no decisions have 619 been taken yet. 621 The first option is to store the contact information for a user in 622 the resource record for the user. A peer Y that is a contact point 623 for this user adds contact information to this resource record. The 624 resource record itself is stored with peer Z in the network, where 625 peer Z is chosen by the distributed database algorithm. 627 When the SIP entity coupled with peer X has an INVITE message 628 addressed to this user, it retrieves the resource record from peer Z. 629 It then extracts the contact information for the various peers that 630 are a contact point for the user, including peer Y, and forwards the 631 INVITE onward. 633 This exchange is illustrated in the following figure. The notation 634 "Put(U@Y)" is used to show the distributed database operation of 635 updating the resource record for user U with the contract Y, and 636 "Get(U)" illustrates the distributed database operation of retrieving 637 the resource record for user U. Note that the messages between the 638 peers X, Y and Z may actually travel via intermediate peers (not 639 shown) as part of the distributed lookup process or so as to traverse 640 intervening NATs. 642 Peer X Peer Z Peer Y 643 | | | 644 | | Put(U@Y) | 645 | |<---------------| 646 | | Put-Resp(OK) | 647 | |--------------->| 648 | | | 649 | Get(U) | | 650 |---------------->| | 651 | Get-Resp(U@Y)| | 652 |<----------------| | 653 | INVITE(To:U) | | 654 |--------------------------------->| 655 | | | 657 The second option also involves storing the contact information for a 658 user in the resource record of the user. However, SIP entity at peer 659 X, rather than retrieving the resource record from peer Z, instead 660 forwards the INVITE message to the proxy at peer Z. The proxy at peer 661 Z then uses the information in the resource record and forwards the 662 INVITE onwards to the SIP entity at peer Y and the other contacts. 664 Peer X Peer Z Peer Y 665 | | | 666 | | Put(U@Y) | 667 | |<---------------| 668 | | Put-Resp(OK) | 669 | |--------------->| 670 | | | 671 | INVITE(To:U) | | 672 |-----------------| INVITE(To:U) | 673 | |--------------->| 674 | | | 676 The third option is for a single peer W to place its contact 677 information into the resource record for the user (stored with peer 678 Z). A peer Y that is a contact point for the user retrieves the 679 resource record from peer Z, extracts the contact information for 680 peer W, and then uses the standard SIP registration mechanism 681 [RFC3261] to register with peer W. When the SIP entity at peer X has 682 to forward an INVITE request, it retrieves the resource record and 683 extracts the contact information for W. It then forwards the INVITE 684 to the proxy at peer W, which proxies it onward to peer Y and the 685 other contacts. 687 Peer X Peer Z Peer Y Peer W 688 | | | | 689 | | Put(U@W) | | 690 | |<---------------------------------| 691 | | Put-Resp(OK) | | 692 | |--------------------------------->| 693 | | | | 694 | | | | 695 | | | REGISTER(To:U) | 696 | | |---------------->| 697 | | | 200 | 698 | | |<----------------| 699 | | | | 700 | | | | 701 | Get(U) | | | 702 |---------------->| | | 703 | Get-Resp(U@W)| | | 704 |<----------------| | | 705 | INVITE(To:U) | | | 706 |--------------------------------------------------->| 707 | | | INVITE(To:U) | 708 | | |<----------------| 709 | | | | 711 The fourth option works as in option 3, with the exception that, 712 rather than X retrieving the resource record from Z, peer X forwards 713 the INVITE to a SIP proxy at Z, which proxies it onward to W and 714 hence to Y. 716 Peer X Peer Z Peer Y Peer W 717 | | | | 718 | | Put(U@W) | | 719 | |<---------------------------------| 720 | | Put-Resp(OK) | | 721 | |--------------------------------->| 722 | | | | 723 | | | | 724 | | | REGISTER(To:U) | 725 | | |---------------->| 726 | | | 200 | 727 | | |<----------------| 728 | | | | 729 | | | | 730 | INVITE(To:U) | | | 731 |---------------->| INVITE(To:U) | | 732 | |--------------------------------->| 733 | | | INVITE(To:U) | 734 | | |<----------------| 735 | | | | 737 The pros and cons of option 1 and 3 are briefly discussed in 738 [Using-an-External-DHT]. 740 5.3. NAT Traversal 742 Two approaches to NAT Traversal for P2PSIP Peer Protocol have been 743 suggested. The working group has not made any decision yet on the 744 approach that will be selected. 746 The first, the traditional approach adopted by most peer-to-peer 747 networks today, divides up the peers in the network into two groups: 748 those with public IP addresses and those without. The networks then 749 select a subset of the former group and elevate them to "super peer" 750 status, leaving the remaining peers as "ordinary peers". Since super 751 peers all have public IP addresses, there are no NAT problems when 752 communicating between them. The network then associates each 753 ordinary peer with (usually just one) super peer in a client-server 754 relationship. Once this is done, an ordinary peer X can communicate 755 with another ordinary peer Y by sending the message to X's super 756 peer, which forwards it to Y's super peer, which forwards it to Y. 757 The connection between an ordinary peer and its super peer is 758 initiated by the ordinary peer, which makes it easy to traverse any 759 intervening NATs. In this approach, the number of hops between two 760 peers is at most 3. 762 The second approach treats all peers as equal and establishes a 763 partial mesh of connections between them. Messages from one peer to 764 another are then routed along the edges in the mesh of connections 765 until they reach their destination. To make the routing efficient 766 and to avoid the use of standard Internet routing protocols, the 767 partial mesh is organized in a structured manner. If the structure 768 is based on any one of a number of common DHT algorithms, then the 769 maximum number of hops between any two peers is log N, where N is the 770 number of peers in the overlay. 772 The first approach is significantly more efficient than the second in 773 overlays with large numbers of peers. However, the first approach 774 assumes there are a sufficient number of peers with public IP 775 addresses to serve as super peers. In some usage scenarios 776 envisioned for P2PSIP, this assumption does not hold. For example, 777 this approach fails completely in the case where every peer is behind 778 a distinct NAT. 780 The second approach, while less efficient in overlays with larger 781 numbers of peers, is efficient in smaller overlays and can be made to 782 work in many use cases where the first approach fails. 784 Both of these approaches assume a method of setting up Peer Protocol 785 connections between peers. Many such methods exist; the now expired 786 [I-D.iab-nat-traversal-considerations] is an attempt to give a fairly 787 comprehensive list along with a discussion of their pros and cons. 788 After a consideration of the various techniques, the P2PSIP working 789 group has decided to select the Unilateral Self-Address Fixing method 790 [RFC3424] of NAT Traversal, and in particular the ICE 791 [I-D.ietf-mmusic-ice] implementation of this approach. 793 The above discussion covers NAT traversal for Peer Protocol 794 connections. For Client Protocol connections, the approach depends 795 on the role adopted for clients and we defer the discussion on that 796 point until the role becomes clearer. 798 In addition to Peer Protocol and Client Protocol messages, a P2PSIP 799 Overlay must also provide a solution to the NAT Traversal problem for 800 SIP messages. If it does not, there is no reliable way for a peer 801 behind one NAT to send a SIP INVITE to a peer behind another NAT. 802 One way to solve this problem is to transport SIP messages along Peer 803 and Client Protocol connections: this could be done either by 804 encapsulating the SIP messages inside Peer and Client Protocol 805 messages or by multiplexing SIP with the Peer (resp.Client) Protocol 806 on a Peer (resp. Client) Protocol connection. 808 Finally, it should be noted that the NAT traversal problem for media 809 connections signaled using SIP is outside the scope of the P2PSIP 810 working group. As discussed in [I-D.ietf-sipping-nat-scenarios], the 811 current recommendation is to use ICE. 813 5.4. Locating and Joining an Overlay 815 Before a peer can attempt to join a P2PSIP overlay, it must first 816 obtain a Peer-ID and optionally a set of credentials. The Peer-ID is 817 an identifier that will uniquely identify the peer within the 818 overlay, while the credentials show that the peer is allowed to join 819 the overlay. 821 The P2PSIP WG will not standardize how the peer-ID and the 822 credentials are obtained, but merely standardize at least one 823 acceptable format for each. To ensure interoperability, it is 824 expected that at least one of these formats will be specified as 825 "mandatory-to-implement". 827 Once a peer (the "joining peer") has a peer-ID and optionally a set 828 of credentials, it can attempt to join the overlay. To do this, it 829 needs to locate a bootstrap peer for the Overlay. 831 A bootstrap peer is a peer that serves as the first point of contact 832 for the joining peer. The joining peer uses a bootstrap mechanism to 833 locate a bootstrap peer. Locating a bootstrap peer might be done in 834 any one of a number of different ways: 836 o By remembering peers that were part of the overlay the last time 837 the peer was part of the overlay; 839 o Through a multicast discovery mechanism; 841 o Through manual configuration; or 843 o By contacting a P2PSIP Bootstrap Server, and using its help to 844 locate a bootstrap peer. 846 The joining peer might reasonably try each of the methods (and 847 perhaps others) in some order or in parallel until it succeeds in 848 finding a bootstrap peer. 850 The job of the bootstrap peer is simple: refer the joining peer to a 851 peer (called the "admitting peer") that will help the joining peer 852 join the network. The choice of admitting peer will often depend on 853 the joining node - for example, the admitting peer may be a peer that 854 will become a neighbor of the joining peer in the overlay. It is 855 possible that the bootstrap peer might also serve as the admitting 856 peer. 858 The admitting peer will help the joining peer learn about other peers 859 in the overlay and establish connections to them as appropriate. The 860 admitting peer and/or the other peers in the overlay will also do 861 whatever else is required to help the joining peer become a fully- 862 functional peer. The details of how this is done will depend on the 863 distributed database algorithm used in the overlay. 865 At various stages in this process, the joining peer may be asked to 866 present its credentials to show that it is authorized to join the 867 overlay. Similarly, the various peers contacted may be asked to 868 present their credentials so the joining peer can verify that it is 869 really joining the overlay it wants to. 871 5.5. Possible Client Behavior 873 As mentioned above, a number of people have proposed a second type of 874 P2PSIP entity, known as a "P2PSIP client". The question of whether 875 the concept of a "client" is needed and, if it is needed, its exact 876 nature, is still very much under debate. This section presents some 877 of the alternatives that have been suggested for the possible role of 878 a client. 880 In one approach, a client interacts with the P2PSIP overlay through 881 an associated peer (or perhaps several such peers) using the Client 882 Protocol. The client does not run the distributed database 883 algorithm, does not store resource records, and is not involved in 884 routing messages to other peers or clients. Through interactions 885 with its associated peer, a client can insert, modify, examine, and 886 remove resource records. A client can also send SIP messages to its 887 associated peer for routing through the overlay. In this approach, a 888 client is a node that wants to take advantage of the overlay, but is 889 unable or unwilling to contribute resources back to the overlay. 891 One way to realize this alternative is for a peer to behave as a 892 [RFC3261] proxy/registrar. Clients then use standard SIP mechanisms 893 to add, update, and remove registrations and to send SIP messages to 894 peers and other clients. If this is done, there is no need for a 895 separate Client Protocol and no need for P2PSIP to define a distinct 896 "P2PSIP Client" concept. 898 In a second alternative, a client behaves in a way similar to the way 899 described in first alternative, except that it does store resource 900 records. In essence, the client contributes its storage capacity to 901 its associated peer. A peer which needs to store a resource record 902 may elect to store this on one or more of its associated clients 903 instead, thus boosting its effective storage capacity. 905 In a third alternative, a client acts almost the same as a peer, 906 except that it does not store any resource records. In this 907 alternative, a client has a "peer-ID" and joins the overlay in the 908 same way as a peer, perhaps establishing the same network of 909 connections that a peer would. Clients participate in the 910 distributed database algorithm, and can help in transporting messages 911 to other peers and clients. However, the distributed database 912 algorithm does not assign resource records to clients. The role of a 913 client in this model has been described as "a peer with bad memory". 915 Another way to look at this distinction is that a client is simply a 916 peer that is not currently offering some or all services to the 917 overlay, possibly due to a run-time decision about available 918 resources such as bandwidth or storage capacity. With this approach, 919 the distinction between client and peer becomes much less distinct, 920 and probably eliminates the requirement to have two distinct terms 921 for the roles. Rather, we might speak in terms such as "high- 922 function" vs "low-function" peers. This approach would also seem to 923 eliminate the requirement for a distinct P2PSIP Client Protocol. 925 It has also been proposed that the client role could be fulfilled by 926 conventional SIP UAs served by a peer that is also acting as a proxy/ 927 registrar. While this might fulfill the requirement, the authors 928 contend that such as device is a "SIP UA", not a "P2PSIP Client" as 929 defined in this document, and that exclusively using SIP UAs in this 930 role eliminates the need for P2PSIP Clients and P2PSIP Client 931 Protocol from the architecture. 933 5.6. Interacting with non-P2PSIP entities 935 It is possible for network nodes that are not peers or clients to 936 interact with a P2PSIP overlay. Such nodes would do this through 937 mechanisms not defined by the P2PSIP working group provided they can 938 find a peer or client that supports that mechanism and which will do 939 any related P2PSIP operations necessary. In this section, we briefly 940 describe two ways this might be done. (Note that these are just 941 examples and the descriptions here are not recommendations). 943 One example is a peer that also acts as a standard SIP proxy and 944 registrar. SIP UAs can interact with it using mechanisms defined in 945 [RFC3261]. The peer inserts registrations for users learned from 946 these UAs into the distributed database, and retrieves contact 947 information when proxying INVITE messages. 949 Another example is a peer that has a fully-qualified domain name 950 (FQDN) that matches the name of the overlay and acts as a SIP proxy 951 for calls coming into the overlay. A SIP INVITE addressed to 952 "user@overlay-name" arrives at the peer (using the mechanisms in 953 [RFC3263]) and this peer then looks up the user in the distributed 954 database and proxies the call onto it. 956 6. Additional Questions 958 This section lists some additional questions that the proposed P2PSIP 959 Working Group may need to consider in the process of defining the 960 Peer and Client protocols. 962 6.1. Selecting between Multiple Peers offering the Same Service 964 If a P2PSIP network contains two or more peers that offer the same 965 service, then how does a peer or client that wishes to use that 966 service select the peer to use? This question comes up in a number 967 of contexts: 969 o When two or more peers are willing to serve as a STUN Relay, how 970 do we select a peer that is close in the netpath sense and is 971 otherwise appropriate for the call? 973 o When two or more peers are willing to serve as PSTN gateways, how 974 do we select an appropriate gateway for a call that is both 975 netpath efficient and provides good quality or inexpensive PSTN 976 routing? 978 It has been suggested that, at least initially, the working group 979 should restrict itself to defining a mechanism that can return a list 980 of peers offering a service and not define the mechanism for 981 selecting a peer from that list. 983 6.2. Visibility of Messages to Intermediate Peers 985 When transporting SIP messages through the overlay, are the headers 986 and/or bodies of the SIP messages visible to the peers that the 987 messages happen to pass through? If they are, what types of security 988 risks does this pose in the presence of peers that have been 989 compromised in some way? 991 6.3. Using C/S SIP and P2PSIP Simultaneously in a Single UA 993 If a given UA is capable of operating in both P2PSIP and conventional 994 SIP modalities (especially simultaneously), is it possible for it to 995 use and respond to the same AOR using both conventional and P2PSIP? 996 An example of such a topology might be a UA that registers an AOR 997 (say, "sip:alice@example.com") conventionally with a registrar and 998 then inserts a resource record for that resource into a P2PSIP 999 topology, such that both conventional SIP users and P2PSIP users 1000 (within the overlay or a federation thereof) would be able to contact 1001 the user without necessarily traversing some sort of gateway. Is 1002 this something that we want to make work? 1004 6.4. Clients, Peers, and Services 1006 1. Do all peers providing routing, storage, and all other services, 1007 or do only some peers provide certain services? 1009 2. What services, if any, must all peers provide? 1011 3. Do we need clients as a discrete class, or do SIP UAs and/or low- 1012 function peers completely satisfy the requirements? 1014 4. How we can we describe the capacity of a peer for delivering a 1015 given service? 1017 6.5. Relationships of Domains to Overlays 1019 1. Can there be names from more than one domain in a single overlay? 1021 2. Can there be names from one domain in more than a single overlay? 1022 If so, how do we route Client/Server SIP requests to the right 1023 overlay? 1025 3. Can the domain of an AoR be in more than one overlay? 1027 4. Should we have a "default overlay" to search for peers in many 1028 domains? 1030 6.6. Protocol Layering 1032 It is possible to define the overlay operations as extensions to SIP 1033 as proposed in [I-D.bryan-p2psip-dsip] or using a lower level 1034 transport protocol (or distinct P2P protocol layer below SIP) as 1035 described in [I-D.matthews-p2psip-hip-hop], [I-D.bryan-p2psip-reload] 1036 and [I-D.marocco-p2psip-xpp-pcan]. Which is the better or more 1037 appropriate model? It seems that this requires analysis along 1038 several axes, presumably described below in descending order of 1039 priority.: 1041 1. Functionality: Which approach more completely meets the 1042 functional requirements implicit in the conceptual model? 1044 2. Simplicity: Ease of implementation. Which approach can be more 1045 readily turned into running code? 1047 3. Generality: Do we have a requirement to only provide P2P support 1048 for SIP operations, or is it likely that other applications will 1049 need this functionality? If we make SIP work for P2P, will this 1050 increase the pressure on SIP to serve as a general transport 1051 protocol because it solves the rendezvous problem using P2P, 1052 despite the warnings of [RFC4485] about using SIP as a transport 1053 protocol? 1055 4. Efficiency: Which approach produces the lesser loading on the 1056 transport layer, the peers themselves, and other infrastructure? 1058 7. Security Considerations 1060 Building a P2PSIP system has many security considerations, many of 1061 which we have only begun to consider. We anticipate that the 1062 protocol documents describing the actual protocols will deal more 1063 thoroughly with security topics. 1065 One critical security issue that will need to be addressed is 1066 providing for the privacy and integrity of SIP messages being routed 1067 by peer nodes, when those peer nodes might well be hostile. This is 1068 a departure from Client/Server SIP, where the proxies are generally 1069 operated by enterprises or service providers with whom the users of 1070 SIP UAs have a trust relationship. 1072 8. IANA Considerations 1074 This document presently raises no IANA considerations. 1076 9. Changes in This Version 1078 1. Revised "Open Questions" to reflect current discussion. 1080 2. Resolved conflict between "services provided by overlay" and 1081 "named services provided by peers" by calling all overlay-level 1082 operations "functions". Thus, we would now speak of an overlay 1083 providing a "distributed transport function". 1085 3. Resolved open issue "Does P2PSIP provide a distributed location 1086 function or an alternative mechanism to RFC 3263? The answer 1087 seems to be both, but what is the relationship between these?" by 1088 documenting that each overlay provides an alternative to 1089 [RFC3263] within that overlay, but that [RFC3263] is used in the 1090 conventional manner between overlays. 1092 4. Revised abstract to include SIP message routing within the scope. 1094 5. Added brief mention of peer's capacity for services offered in 1095 overview section on distributed database. 1097 6. Revised definition of P2PSIP Service. 1099 7. Revised abstract and high level discussion. 1101 8. Added discussion of proposed peer models and relationship to SIP 1102 UAs. 1104 9. Revised reference model diagram to clarify client behavior. 1106 10. Acknowledgements 1108 This document draws heavily from the contributions of many 1109 participants in the P2PSIP Mailing List but the authors are 1110 especially grateful for the support of Spencer Dawkins, Cullen 1111 Jennings, and Henning Schulzrinne, all of whom spent time on phone 1112 calls about this document or provided text. In addition, Spencer 1113 contributed the Reference Model figure. 1115 11. References 1117 11.1. Normative References 1119 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1120 A., Peterson, J., Sparks, R., Handley, M., and E. 1121 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1122 June 2002. 1124 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1125 Protocol (SIP): Locating SIP Servers", RFC 3263, 1126 June 2002. 1128 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1129 Resource Identifier (URI): Generic Syntax", STD 66, 1130 RFC 3986, January 2005. 1132 11.2. Informative References 1134 [I-D.bryan-p2psip-dsip] 1135 Bryan, D., "dSIP: A P2P Approach to SIP Registration and 1136 Resource Location", draft-bryan-p2psip-dsip-00 (work in 1137 progress), February 2007. 1139 [I-D.bryan-p2psip-reload] 1140 Bryan, D., "REsource LOcation And Discovery (RELOAD)", 1141 draft-bryan-p2psip-reload-00 (work in progress), 1142 June 2007. 1144 [I-D.iab-nat-traversal-considerations] 1145 Rosenberg, J., "Considerations for Selection of Techniques 1146 for NAT Traversal", 1147 draft-iab-nat-traversal-considerations-00 (work in 1148 progress), October 2005. 1150 [I-D.ietf-behave-rfc3489bis] 1151 Rosenberg, J., "Session Traversal Utilities for (NAT) 1152 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 1153 progress), March 2007. 1155 [I-D.ietf-mmusic-ice] 1156 Rosenberg, J., "Interactive Connectivity Establishment 1157 (ICE): A Protocol for Network Address Translator (NAT) 1158 Traversal for Offer/Answer Protocols", 1159 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 1161 [I-D.ietf-sipping-nat-scenarios] 1162 Boulton, C., "Best Current Practices for NAT Traversal for 1163 SIP", draft-ietf-sipping-nat-scenarios-06 (work in 1164 progress), March 2007. 1166 [I-D.marocco-p2psip-xpp-pcan] 1167 Marocco, E. and E. Ivov, "XPP Extensions for Implementing 1168 a Passive P2PSIP Overlay Network based on the CAN 1169 Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00 1170 (work in progress), June 2007. 1172 [I-D.matthews-p2psip-hip-hop] 1173 Cooper, E., "A Distributed Transport Function in P2PSIP 1174 using HIP for Multi-Hop Overlay Routing", 1175 draft-matthews-p2psip-hip-hop-00 (work in progress), 1176 June 2007. 1178 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1179 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1180 RFC 2136, April 1997. 1182 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1183 Self-Address Fixing (UNSAF) Across Network Address 1184 Translation", RFC 3424, November 2002. 1186 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 1187 of Extensions to the Session Initiation Protocol (SIP)", 1188 RFC 4485, May 2006. 1190 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1191 Multicast Name Resolution (LLMNR)", RFC 4795, 1192 January 2007. 1194 [Using-an-External-DHT] 1195 Singh, K. and H. Schulzrinne, "Using an External DHT as a 1196 SIP Location Service", Columbia University Computer 1197 Science Dept. Tech Report 388). 1199 Copy available at http://mice.cs.columbia.edu/ 1200 getTechreport.php?techreportID=388/ 1202 Authors' Addresses 1204 David A. Bryan 1205 College of William and Mary and SIPeerior Technologies 1206 3000 Easter Circle 1207 Williamsburg, Virginia 23188 1208 USA 1210 Phone: +1 757 565 0101 1211 Email: bryan@sipeerior.com 1213 Philip Matthews 1214 Avaya 1215 1135 Innovation Drive 1216 Ottawa, Ontario K2K 3G7 1217 Canada 1219 Phone: +1 613 592 4343 x224 1220 Email: philip_matthews@magma.ca 1222 Eunsoo Shim 1223 Locus Telecommunications 1224 111 Sylvan Avenue 1225 Englewood Cliffs, New Jersey 07632 1226 USA 1228 Phone: unlisted 1229 Email: eunsooshim@gmail.com 1230 Dean Willis 1231 Unaffiliated 1232 3100 Independence Pkwy #311-164 1233 Plano, Texas 75075 1234 USA 1236 Phone: unlisted 1237 Email: dean.willis@softarmor.com 1239 Full Copyright Statement 1241 Copyright (C) The IETF Trust (2007). 1243 This document is subject to the rights, licenses and restrictions 1244 contained in BCP 78, and except as set forth therein, the authors 1245 retain all their rights. 1247 This document and the information contained herein are provided on an 1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1255 Intellectual Property 1257 The IETF takes no position regarding the validity or scope of any 1258 Intellectual Property Rights or other rights that might be claimed to 1259 pertain to the implementation or use of the technology described in 1260 this document or the extent to which any license under such rights 1261 might or might not be available; nor does it represent that it has 1262 made any independent effort to identify any such rights. Information 1263 on the procedures with respect to rights in RFC documents can be 1264 found in BCP 78 and BCP 79. 1266 Copies of IPR disclosures made to the IETF Secretariat and any 1267 assurances of licenses to be made available, or the result of an 1268 attempt made to obtain a general license or permission for the use of 1269 such proprietary rights by implementers or users of this 1270 specification can be obtained from the IETF on-line IPR repository at 1271 http://www.ietf.org/ipr. 1273 The IETF invites any interested party to bring to its attention any 1274 copyrights, patents or patent applications, or other proprietary 1275 rights that may cover technology that may be required to implement 1276 this standard. Please address the information to the IETF at 1277 ietf-ipr@ietf.org. 1279 Acknowledgment 1281 Funding for the RFC Editor function is provided by the IETF 1282 Administrative Support Activity (IASA).