idnits 2.17.1 draft-bryan-p2psip-usecases-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack 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 (July 2, 2007) is 6137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP D. Bryan 3 Internet-Draft SIPeerior Technologies, Inc. 4 Intended status: Informational E. Shim 5 Expires: January 3, 2008 Locus Telecom 6 B. Lowekamp 7 SIPeerior; William & Mary 8 July 2, 2007 10 Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP) 11 draft-bryan-p2psip-usecases-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document attempts to identify and classify use cases of P2P 45 based SIP. It does not attempt to exhaustively enumerate these 46 cases, and is focused exclusively on cases related to real-time IP 47 communication. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Global Internet Environment . . . . . . . . . . . . . . . 4 55 3.1.1. Public P2P VoIP Service Providers . . . . . . . . . . 4 56 3.1.2. Open Global P2P VoIP Network . . . . . . . . . . . . . 4 57 3.1.3. Presence Using Multimedia Consumer Electronics 58 Devices . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1.4. Multimedia content sharing via Application Layer 60 Multicasting . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Security Demanding Environments . . . . . . . . . . . . . 5 62 3.2.1. Impeded Access . . . . . . . . . . . . . . . . . . . . 5 63 3.2.2. Anonymous Communications . . . . . . . . . . . . . . . 6 64 3.2.3. Security Conscious Small Organizations . . . . . . . . 6 65 3.3. Environments with Limited Connectivity to the Internet 66 or Infrastructure . . . . . . . . . . . . . . . . . . . . 6 67 3.3.1. Ad-Hoc and Ephemeral Groups . . . . . . . . . . . . . 7 68 3.3.2. Emergency First Responder Networks . . . . . . . . . . 7 69 3.3.3. Extending the Reach of Mobile Devices . . . . . . . . 8 70 3.3.4. Deployments in the Developing World . . . . . . . . . 8 71 3.4. Managed, Private Network Environments . . . . . . . . . . 8 72 3.4.1. Serverless or Small Scale IP-PBX . . . . . . . . . . . 8 73 3.4.2. P2P for Redundant SIP Proxies . . . . . . . . . . . . 9 74 3.4.3. Failover for Centralized Systems . . . . . . . . . . . 9 75 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 82 Intellectual Property and Copyright Statements . . . . . . . . . . 12 84 1. Introduction 86 This document attempts to identify and classify use cases for Peer- 87 to-Peer (P2P) based Session Initiation Protocol (SIP)[RFC3261]. 88 Identifying use cases will help to understand and clarify 89 requirements of P2P SIP. In particular, these use cases will assist 90 in identifying commonalities and differences between requirements for 91 P2P SIP for different use cases, which in turn will help define the 92 near-term scope of specifications and provide a perspective on future 93 specifications. 95 Only use cases related to real-time IP communications, such as VoIP, 96 Instant Messaging (IM), and presence are considered in this document. 97 Use cases of other kinds, even if interesting and possibly useful 98 applications of P2P SIP, are out of scope for this document. Thus, 99 use cases described herein are use cases of P2P IP real-time 100 communications, and P2P SIP is a protocol choice rather than a 101 constraining factor for most of them. In describing use cases, no 102 deliberation on implementation is provided. Some of the use cases 103 presented may already be implemented or deployed, possibly using 104 proprietary technology. 106 Some of these use cases, while difficult to implement using a 107 traditional client server SIP (CS SIP) architecture may not require 108 P2P and could be implemented in other ways. While these have often 109 been presented as scenarios calling for P2P communication, the 110 authors recognize that other technologies may also be applicable to 111 these use cases. 113 Since the original iteration of this document, the P2PSIP WG has been 114 formed and numerous documents have been submitted that include some 115 number of use cases. We will not try to enumerate them here. This 116 draft draws from these documents, as well as discussions at the P2P 117 SIP ad-hoc and WG meetings and numerous mailing list and personal 118 conversations of the authors. The list of use cases compiled here is 119 by no means a complete list of uses cases of P2P SIP, and further 120 cases would be limited only by the imagination. 122 2. Terminology 124 In this document, words which are normally key words, such as "MUST", 125 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 126 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used 127 COLLOQUIALLY and are not intended to be interpreted as described in 128 RFC2119 [RFC2119]. 130 We use the terminology and definitions from the Concepts and 131 Terminology for Peer to Peer SIP [I-D.willis-p2psip-concepts] draft 132 in this document without further definition. Terminology defined in 133 RFC3261 [RFC3261] is used without definition. 135 3. Use Cases 137 Use cases are grouped according to the characteristics of the network 138 environment in which the end users or devices participating in the 139 P2P overlay are communicating with each other. 141 3.1. Global Internet Environment 143 The global Internet environment consists of a large number of 144 autonomous networks with diverse characteristics. Thus, there is no 145 central administration or network control of the physical network on 146 a global scale. Communication paths between two remote devices may 147 span multiple administrative domains and should be assumed to be 148 insecure. Note that most well-known P2P file sharing overlay 149 networks have operated in this environment. 151 3.1.1. Public P2P VoIP Service Providers 153 Skype is an outstanding example of a public VoIP service provider 154 using P2P technology among end user devices, although using a 155 proprietary protocol. Recent research has shown [skypestudy]that 156 Skype uses a central login server, responsible for management of 157 registered user names. End users are authenticated via certificate 158 signed by a central server. End user devices are distributed across 159 the global Internet. The number of participating end user devices is 160 very large. A major motivation of using P2P between end user devices 161 for a commercial VoIP service is a reduction in infrastructure and 162 operational costs. 164 3.1.2. Open Global P2P VoIP Network 166 This is a global P2P VoIP network in which there is no central 167 authority such as a single service provider. Anyone can join and 168 leave the network freely and anyone can implement the software to 169 participate in the overlay network. In such a system, the protocols 170 used must be based on open standards. This P2P VoIP network 171 resembles the global Internet itself in that it has distributed 172 management and growth, enables anyone to reach anyone else in the 173 overlay network, and any device supporting the standard protocols can 174 be used. 176 3.1.3. Presence Using Multimedia Consumer Electronics Devices 178 Presence is a useful and important feature for instant messaging and 179 VoIP applications. Well-known instant messaging application software 180 provides presence, text and media messaging, and supports file 181 transfer between online users. As more and more multimedia consumer 182 electronics devices such as cameras, camcorders and televisions 183 become network aware, instant sharing of multimedia content such as 184 photos and video clips between family members and friends will be 185 desirable. VoIP may not be needed on some of these consumer 186 electronics devices, however presence that enables instant content 187 sharing will be required for many types of consumer electronics 188 devices. A global P2P network supporting presence is an important 189 infrastructure component for this use case. 191 3.1.4. Multimedia content sharing via Application Layer Multicasting 193 IP-layer multicasting is not generally available beyond the boundary 194 of single IP subnet. Application layer multicasting has become a 195 fausible alternative to IP-layer multicasting. In application layer 196 multicasting, the nodes that need to receive the content from the 197 same source form a distribution network, typically of a tree-like 198 topology, and relay the received content to other nodes in the 199 distribution network. This technique can be used to multicasting 200 video or audio stream to a number of nodes distributed over the 201 Internet (or across multiple IP subnets). This can be used to 202 realize large-scale commercial audio or video distribution/ 203 broadcasting services such as Internet radio or TV services or to ad- 204 hoc video sharing among a group of friends. 206 3.2. Security Demanding Environments 208 There are situations where, despite having connectivity to the 209 Internet or even to client server SIP infrastructure such as SIP 210 proxies, users may not like to use the infrastructure because of 211 security concerns or may not be allowed to use the infrastructure. 212 Such situations are referred to here as involving a security 213 demanding environment. Maintaining privacy of communication and 214 secrecy of identities are important in this environment and the P2P 215 architecture's distributed nature may be more attractive than a 216 client server approach. 218 3.2.1. Impeded Access 220 Certain groups may have their ability to communicate impeded. These 221 users should be able to communicate without the need to connect to 222 any centralized servers, which may be blocked by providers upstream 223 of the user. A fully decentralized system cannot be completely 224 disconnected without removing connectivity at the basic Internet 225 level. 227 Examples: A user wishes to use an IP telephony service to communicate 228 PC to PC with a friend, but the ports commonly used by these 229 services, or the the servers used for authentication, are blocked by 230 the ISP because the ISP also offers communications systems and have a 231 vested interest in denying access. 233 A user with an Internet enabled PDA devices wishes to connect with 234 colleagues, but traditional services are blocked to ensure that SMS 235 or voice minutes are used (at additional cost) instead. 237 3.2.2. Anonymous Communications 239 Users occasionally have need to communicate among themselves in a 240 completely anonymous fashion, whether due to political persecution, 241 need for secrecy for commercial reasons, or threats of violence. In 242 such a case, the need for a self organizing, server-less system is 243 imperative. Users on such a system could communicate with reduced 244 risk of the system being monitored or their identities discovered. 245 As with the impeded access scenario, the only way to disable such 246 networks would be to completely disable Internet connectivity. 248 3.2.3. Security Conscious Small Organizations 250 Certain security conscious small organizations may have need for 251 communications systems that allow members of the organization to 252 communicate directly with one another regardless of their location, 253 with encryption, and without any connectivity to or use of servers, 254 either internal or external to the organization. For these 255 organizations, traditional client-server SIP implementations and more 256 importantly hosted solutions for communications are unacceptable. 257 These entities need a system to facilitate such communications 258 without central servers. Note that these users may overlap with the 259 anonymized communications case also described in this document. 261 Examples: Organizations who are developing technology that might be 262 of interest to a hosted service provider, but because of small size 263 may have no desire or time to maintain centralized servers. 264 Organizations with security needs that preclude any traffic flowing 265 through a central server such as military, national security, or 266 intelligence organizations. 268 3.3. Environments with Limited Connectivity to the Internet or 269 Infrastructure 271 When there is no physical network available for stable deployment of 272 client server SIP or an instant deployment of real-time communication 273 systems is required, the P2P approach may be the only feasible 274 solution. Examples of such environment are isolated wireless ad-hoc 275 networks with no connection to the Internet or ad-hoc networks with 276 limited connectivity to the Internet in situations like outdoor 277 public events, emergencies, and battlefields. Any type of manual 278 configuration is difficult to achieve because technical support is 279 not readily available in such environment. In some cases, 280 connectivity to the global Internet may be available, but be very 281 expensive, of limited capacity, or unstable, such as satellite 282 connections. In such cases, it is preferable to localize 283 communications as much as possible, reducing dependency on any 284 infrastructure in the global Internet. 286 3.3.1. Ad-Hoc and Ephemeral Groups 288 Groups of individuals meeting together have need for collaborative 289 communications systems that are ephemeral in nature, have minimum 290 (ideally zero) configuration, and do not depend on connectivity to 291 the Internet. These scenarios require an arbitrary number of users 292 to connect communications devices. 294 Example: A group gets together for a meeting, but there is no 295 Internet connectivity. If the users establish a wireless ad hoc 296 network or have a base station, all users may connect and establish 297 chat sessions using an IM protocol with no need for server 298 configuration. 300 3.3.2. Emergency First Responder Networks 302 Following a large scale disaster such as a tsunami, earthquake, 303 hurricane, or terrorist attack, access to traditional communications 304 devices of any kind -- Internet, cellular, or traditional PSTN -- may 305 be compromised. Recent events have shown that current first 306 responder radio systems cannot be relied upon to interoperate 307 effectively. A network of devices that can grow organically as 308 responders arrive, requiring only wireless access, is required. As 309 more personnel show up, they should be able to join the network, 310 locate other personnel, and communicate without any centralized 311 configuration required. 313 Example: Following a disaster, the local fire department arrives. 314 Each fire fighter has a wireless handset, and one or more trucks have 315 wireless base stations. When a nearby locality sends additional 316 rescuers, their wireless handsets should be able to instantly join 317 the communications network and communicate. 319 3.3.3. Extending the Reach of Mobile Devices 321 A network of mobile devices can relay traffic between themselves to 322 reach a base station, even if the base station is out of reach of 323 that device. 325 Example: A user has a handset for communication that cannot reach a 326 base station. Some other user is within range of both that user and 327 a base station. This intermediate user can serve as a relay for the 328 caller who is out of range. A system might make this feature 329 optional for standard communication and mandatory for E911. 331 3.3.4. Deployments in the Developing World 333 Certain locations in the developing world have limited, intermittent, 334 or non-existent connectivity to the Internet. These locations also 335 typically lack experienced people with the specialized skills needed 336 to administer or maintain centralized SIP proxies. Even DNS servers 337 may not exist. A communications system that is able to function 338 reliably for internal communications, even in the presence of 339 degraded or absent connectivity, is clearly needed. Such a system 340 must also scale easily with little or no configuration and ideally 341 should interface easily to existing communications systems when 342 connectivity is available. 344 Example: A village in the developing world has connectivity that is 345 limited by weather (microwave connection) or is solar powered. It 346 would be desirable for intra-village communication to continue to 347 function in the absence of Internet connectivity. 349 3.4. Managed, Private Network Environments 351 A corporate network or a school campus network is an example of the 352 managed, private network environment. Most likely client server SIP 353 can be used and managed for real-time communication applications in 354 these environment. However, in certain scenarios, P2P SIP may be 355 used instead or as a complementary means, to achieve various goals 356 such as cost and management overhead reduction, scalability, and 357 system robustness. 359 3.4.1. Serverless or Small Scale IP-PBX 361 Many small enterprises have a need for integrated communications 362 systems. These systems have slightly different requirements than 363 more traditional IP PBXs. For small enterprises, there may be no 364 administrator for these systems, requiring the systems to be 365 essentially self-configuring and/or self-organizing. Additional 366 endpoints should be able to be added with no requirements for 367 configuration on central devices. 369 These systems should offer the feature sets similar to those of 370 client server type PBX systems. Connectivity to the PSTN is an 371 important feature for these systems. In addition, they may support 372 features such as call transfer, voice mail, and possibly even other 373 communications modes such as instant messaging or media features such 374 as video or conference services. There are already commercial 375 products of this type. 377 Example: Small organizations without centralized IT 379 3.4.2. P2P for Redundant SIP Proxies 381 Service providers may wish to connect a farm of proxies together in a 382 transparent way, passing resources (user registrations or other call 383 information) between themselves with as little configuration or 384 traffic as possible. Ideally, the redundancy and exchange of 385 information should require a minimum of configuration between the 386 devices. A P2P architecture between the proxies allows proxy farms 387 to be organizing and operated in this way. With this approach, it is 388 easy to add more proxies with minimal service disruptions and 389 increases the robustness of the system. 391 3.4.3. Failover for Centralized Systems 393 A traditional centralized SIP server, such as used in an IP-PBX, 394 forms a single point of failure of an otherwise fault-independent 395 network. Relying on P2P SIP as a backup to the centralized server 396 allows the communications system to continue functioning normally in 397 the event of planned or unplanned service interruptions of the 398 central IP-PBX. 400 Example: A small company has a central IP-PBX. When that device 401 experiences a failure, the handsets are able to transparently 402 continue operation for the 24 hours it takes to obtain a replacement 403 switch. 405 4. Acknowledgments 407 The following persons have contributed use case suggestions or ideas 408 to this document: 410 Cullen Jennings, Philip Matthews, Henry Sinnreich, Adam Roach, Robert 411 Sparks, Kundan Singh, Henning Schulzrinne, K. Kishore Dhara, and 412 Salman A. Baset. 414 5. Security Considerations 416 The security requirements of the various use-cases vary tremendously. 417 They should be discussed in more detail in this document. 419 6. IANA Considerations 421 This document has no IANA Considerations. 423 7. References 425 7.1. Normative References 427 [I-D.willis-p2psip-concepts] 428 Willis, D., "Concepts and Terminology for Peer to Peer 429 SIP", draft-willis-p2psip-concepts-04 (work in progress), 430 March 2007. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 436 A., Peterson, J., Sparks, R., Handley, M., and E. 437 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 438 June 2002. 440 7.2. Informative References 442 [skypestudy] 443 Baset, S. and H. Schulzrinne, "An Analysis of the Skype 444 Peer-to-Peer Internet Telephony Protocol", Technical 445 Report, Department of Computer Science, Columbia 446 University 0309-04, September 2004. 448 Authors' Addresses 450 David A. Bryan 451 SIPeerior Technologies, Inc. 452 3000 Easter Circle 453 Williamsburg, VA 23188 454 USA 456 Phone: +1 757 565 0101 457 Email: dbryan@sipeerior.com 458 Eunsoo Shim 459 Locus Telecommunications, Inc. 460 2200 Fletcher Ave. 6th FL 461 Fort Lee, NJ 07024 462 USA 464 Email: eunsoo@locus.net 466 Bruce B. Lowekamp 467 SIPeerior; William & Mary 468 3000 Easter Circle 469 Williamsburg, VA 23188 470 USA 472 Phone: +1 757 565 0101 473 Email: lowekamp@sipeerior.com 475 Full Copyright Statement 477 Copyright (C) The IETF Trust (2007). 479 This document is subject to the rights, licenses and restrictions 480 contained in BCP 78, and except as set forth therein, the authors 481 retain all their rights. 483 This document and the information contained herein are provided on an 484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 486 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 487 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 488 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Intellectual Property 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Acknowledgment 517 Funding for the RFC Editor function is provided by the IETF 518 Administrative Support Activity (IASA).