idnits 2.17.1 draft-hautakorpi-p2psip-peer-protocol-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 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 22, 2007) is 6244 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. '3') == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP J. Hautakorpi 3 Internet-Draft G. Camarillo 4 Expires: August 26, 2007 Ericsson 5 February 22, 2007 7 The Peer Protocol for P2PSIP Networks 8 draft-hautakorpi-p2psip-peer-protocol-00.txt 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 26, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes the P2PSIP Peer Protocol that is used between 42 the peers in P2PSIP networks. The described Peer Protocol is not an 43 entirely new protocol, it is a combination of the new SIP method, 44 LOCSER, and the well-defined, XML-based body. 46 Note: At the current moment, the purpose of this document is just to 47 present a relatively high level abstraction from the Peer Protocol, 48 rather than give a very detailed description. 50 1. Introduction 52 P2PSIP is a mechanism which incorporates Peer-to-Peer (P2P) 53 technologies and the Session Initiation Protocol (SIP) [2] signaling 54 in a way which allows the transfer of proxy-registrar functionality 55 to the end-hosts. In P2PSIP network, the storage and routing 56 services are provided by Peers which participate to the overlay. 57 These Peers need a protocol for mutual message exchange, and this 58 document specifies just that, referred as Peer Protocol hereafter. 60 The Peer Protocol is not an entirely new protocol, it is a 61 combination of the new SIP method, LOCSER, and the well defined, 62 Extensible Markup Language (XML)-based body. The LOCSER method is 63 defined in this document, and the substantial parts of the body are 64 documented in [4]. Furthermore, this document defines how the Peer 65 Procol can be used to provide a location service for P2PSIP. 67 Most of the terminology and concepts presented in this document are 68 aligned with the [3]. Other terms are defined when used. 70 The rest of this document is organized as follows. Section 3 71 introduces the Peer Protocol on a high level and Section 4 gives an 72 example from LOCSER method. Section 5 compares LOCSER approach to 73 other proposals. Section 6 present a call flow example and Section 7 74 outlines how LOCSER could be utilized in client/server SIP. 75 Section 8 enumerates topics for furher study. Section 9 and 76 Section 10 present topics for further study and IANA considerations 77 respectively. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [1]. 85 3. The Peer Protocol 87 From practical standpoint, this document defines only one new SIP 88 method, LOCSER, and its use for providing a location service. In 89 order to implement a location service, also the work by other needs 90 to be used. 92 The described Peer Protocol has two distinct parts: The LOCSER SIP 93 request and its well-defined XML body. Frank Dabek et al have 94 studied how to create an Application Programming Interface (API) for 95 structured P2P overlays. In [8] they have introduced a multi-tier 96 approach for the common P2P API. Tier 0 is a Key-Based Routing (KBR) 97 layer, tier 1 is a higher layer abstraction, which is built on top of 98 tier 0, and tier 2 represent the application on top of tier 1. The 99 LOCSER SIP request corresponds to tier 0 and its XML body corresponds 100 to tier 1. In other words, the LOCSER SIP request provides a routing 101 based on a key, and the rest of the functionalities (like put and 102 get) are handled in the XML body. Naturally, the actual P2PSIP 103 application represents tier 2. 105 4. Example 107 An example from Peer Protocol message is presented in Figure 1. It 108 has one new header field, Overlay-Key. The Overlay-Key contains the 109 key that is used overlay routing. The content of the Overlay-Key 110 header field is similar to the ResourceID and PeerID tokens, which 111 are explained in [6] (see Sections 8.2.1 and 8.2.2). The difference 112 is that there is no need to make a separation between the resource 113 and peer id in Overlay-Key header field; the routing will be the same 114 in both cases. 116 LOCSER sip:bob@biloxi.example.com SIP/2.0 117 Overlay-Key: C83B247AC4F5D91E23A9B6CD2F32B912CAD7209E 118 From: Alice ;tag=2948351372 119 To: Bob 120 Via: SIP/2.0/UDP sip:alice@100.101.102.103;branch=y9gG4bL376csuhks 121 CSeq: 1 LOCSER 122 Call-ID: 12345601@atlanta.example.com 123 Max-Forwards: 70 124 Content-Type: text/xml 125 Content-length: 277 127 128 129 get 130 131 132 133 bob@biloxi.example.com 134 135 C83B247AC4F5D91E23A9B6CD2F32B912CAD7209E 136 137 138 139 140 142 Figure 1: Example Message 144 The XML body of the LOCSER message is re-using the XML data 145 structures and interfaces specified in [4]. The example message in 146 Figure 1 presents a case where XML body is used to resolve the 147 location of bob@biloxi.example.com. 149 The interfaces presented in [4] does not specify how the XML body 150 could be used for overlay maintenance. The XML body in LOCSER 151 message has to support overlay maintenance, so the definitions in [4] 152 needs to be extended. For example, the XML body should be able to 153 accomodate the functions Chord [9] needs for injecting information 154 about newly joined node to the finger tables of others. 156 There are two notable benefits from using SIP as a base for Peer 157 Protocol: No need for yet-another protocol stack, and the possibility 158 to re-use the SIP-compliant mechanisms. The first advantage is 159 especially useful in mobile devices, which have relatively scarse 160 memory resources. The second advantage is especially beneficial in a 161 case of NAT traversal; existing mechanisms, like SIP Outbound [5], 162 can be used with LOCSER method. 164 5. Commonalities and Differences to Other Proposals 166 5.1. A P2P Approach to SIP Registration and Resource Location 168 P2P based approach for SIP registration and resource discovery has 169 been presented in [6]. The current document and [6] are similar in a 170 sense that they both define a Peer Protocol for P2PSIP and they both 171 use SIP. The current document also re-uses some of work done in [6]. 172 For example, the Overlay-Key header field is based on the ResourceID 173 and PeerID tokens. 175 The biggest difference between the current document and [6] is that 176 the former utilizes the LOCSER method with well-defined XML body, and 177 the latter utilized modified REGISTER requests. 179 The main reason why we chose not to use REGISTER request in this 180 document is to avoid its semantic overloading. The RF3261 [2], 181 Section 10.2, says the following about REGISTER request: 183 REGISTER requests add, remove, and query bindings. 185 In a P2P scenario it would be desirable to be able to use the Peer 186 Protocol for all overlay management functions, for example for 187 injecting information about newly joined node to the finger tables of 188 others. This kind of functionality is out of scope for REGISTER 189 request. 191 Another reason why REGISTER was not chosen is that the REGISTER 192 method is already strictly defined. Some of the existing definitions 193 are not well-suited for a P2P scenario. For example, strict 194 processing rules, defined in Section 10.3 on RFC3261 [2], are 195 suboptimal for P2P scenario. 197 The LOCSER SIP method and its well-defined XML body have been 198 designed to be compatible with existing specifications. The RFC3621 199 [2], Section 6, says the following about location service: 201 The bindings can be created and removed in many ways; this 202 specification defines a REGISTER method that updates the bindings. 204 Given this, the LOCSER method and its XML body can be seen as an 205 alternative method, which is well suited of P2P scenario, for binding 206 management. 208 5.2. Data format and Interface to P2P network for SIP Location Service 210 The data format and interface for decentralized location service are 211 defined in [4]. The current document and the [4] has a lot in 212 common. The main link between the documents is the fact that the 213 Peer Protocol defined in this document re-uses the data format and 214 the interface specified in [4]. 216 There are also some differences. This document uses SIP as a 217 underlying transport while [4] indirectly proposes the use of 218 Hypertext Transfer Protocol (HTTP). Another difference is that [4] 219 suggest to use two separate protocols for DHT maintenance and 220 location service, while this document uses the same protocol for 221 both. 223 6. Call Flow Example 225 The following example call flow, in Figure 2, illustrates a case 226 where the caller, Alice, initiates a phone call to callee, Bob. Prior 227 to this event, Bob has placed his Resource Record to an overlay 228 network. In this example, all the nodes are Peers for the sake of 229 simplicity. 231 Alice Peer Peer Bob 232 | | | | 233 | LOCSER | | | 234 |---------------->| LOCSER | | 235 | [get in xml] |---------------->| | 236 | | [get in xml] |[Bob's ] | 237 | | |[resource] | 238 | | 200 OK |[record ] | 239 | 200 OK |<----------------| | 240 |<----------------| [answer in xml] | | 241 | [answer in xml] | | | 242 | | | | 243 | | INVITE | | 244 |---------------------------------------------------->| 245 | | | | 246 | | 200 OK | | 247 |<----------------------------------------------------| 248 | | | | 249 |<===================================================>| 250 | | | | 252 Figure 2: Call Flow Example 254 First Alice generates a LOCSER request containing an Overlay-Key, 255 which is a hash from Bob's URI. The LOCSER request contains also a 256 well-defined XML body, which has a 'get' method. After generating 257 the request, Alice send it to the most suitable peer candidate in the 258 overlay. The mechanims for determining which peer is the best 259 candidate is up to the used overlay routing mechanism. 261 When the next peer, second from the left, receives the LOCSER 262 request, it check whether the request is targeted to itself or not. 263 It this case it is not and the peer forwards it to the most suitable 264 peer candidate it knows. Then the next peer, third from the left, 265 receives it and performs the same check. Now the result is that the 266 current peer is the target peer, because it has Bob's resource 267 record, and therefore the peer generates 200 OK response. The 200 OK 268 response contains Bob's contact information, typically IP and port, 269 and it is returned to Alice. 271 When Alice receives the 200 OK, it learns the Bob's contact 272 information and is able to initiate a call to him. After this point 273 the signaling takes place directly between Alice and Bob. First Alice 274 send a typical INVITE request to Bob and Bob accepts the connection 275 by sending back the 200 OK response. Finally, the media can start 276 flowing between Alice and Bob. 278 7. Usage with Client/Server SIP 280 The idea from Location Service Protocol (LSP) is introduces in [7] 281 According to [7], the LSP could be used in client/server SIP and P2P 282 scenarios. The LSP in client/server SIP would be the protocol used 283 between a registrar and a location service or a proxy and a location 284 service. 286 The LOCSER method can also be used in the client/server scenario. In 287 that case, LOCSER method does not need to carry Overlay-Key header 288 field, because key-based routing is not required. The semantics of 289 the LOCSER are the same in client/server and P2P scenarios. 291 8. For Further Study 293 The purpose of this document, at the current moment, is to present a 294 relatively high level abstraction from the described Peer Protocol, 295 rather that give very detailed information. Naturally, all the 296 details needs to be worked on and the following is a list from topics 297 that require further attention: 299 1. Specify the interfaces and data structures used for overlay 300 maintenance in XML. These should be developed in the spirit of 301 [4]. 302 2. Specify the exact syntax of the LOCSER message. The Overlay-Key 303 header field needs exact description as well. 304 3. Specify how peers should handle incoming LOCSER messages. 305 4. Specify how SIP Outbound [5] can be used with LOCSER method. 306 5. Specify how the presence and offline messaging can be implemented 307 in a decentralized fashion by using the XML body. 309 9. Security Considerations 311 For further study. 313 10. IANA Considerations 315 For further study. At least the LOCSER method and the Overlay-Key 316 header field need to be registered to the IANA. 318 11. References 319 11.1. Normative References 321 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 322 Levels", BCP 14, RFC 2119, March 1997. 324 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 325 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 326 Session Initiation Protocol", RFC 3261, June 2002. 328 [3] Willis, D., "Concepts and Terminology for Peer to Peer SIP", 329 draft-willis-p2psip-concepts-03 (work in progress), 330 October 2006. 332 [4] Singh, K. and H. Schulzrinne, "Data format and interface to an 333 external peer-to-peer network for SIP location service", 334 draft-singh-p2p-sip-01 (work in progress), December 2006. 336 11.2. Informational References 338 [5] Jennings, C. and R. Mahy, "Managing Client Initiated Connections 339 in the Session Initiation Protocol (SIP)", 340 draft-ietf-sip-outbound-07 (work in progress), January 2007. 342 [6] Bryan, D., "A P2P Approach to SIP Registration and Resource 343 Location", draft-bryan-sipping-p2p-03 (work in progress), 344 October 2006. 346 [7] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet 347 Communications", draft-johnston-sipping-p2p-ipcom-02 (work in 348 progress), March 2006. 350 [8] Dabek, F., Zhao, B., Druschel, P., Kubiatowicz, J., and I. 351 Stoica, "Towards a Common API for Structured Peer-to-Peer 352 Overlays", Proceedings of the 2nd International Workshop on 353 Peer-to-Peer Systems (IPTPS03), 2003. 355 [9] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Frans 356 Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable 357 Peer-to-peer Lookup Service for Internet Applications", 358 IEEE Transactions on Networking, 2003. 360 Authors' Addresses 362 Jani Hautakorpi 363 Ericsson 364 Hirsalantie 11 365 Jorvas 02420 366 Finland 368 Email: Jani.Hautakorpi@ericsson.com 370 Gonzalo Camarillo 371 Ericsson 372 Hirsalantie 11 373 Jorvas 02420 374 Finland 376 Email: Gonzalo.Camarillo@ericsson.com 378 Full Copyright Statement 380 Copyright (C) The IETF Trust (2007). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Intellectual Property 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org. 418 Acknowledgment 420 Funding for the RFC Editor function is provided by the IETF 421 Administrative Support Activity (IASA).