idnits 2.17.1 draft-bryan-sipping-p2p-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 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 490. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (November 29, 2005) is 6723 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) == Unused Reference: '6' is defined on line 437, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG D. A. Bryan 3 Internet-Draft P2PSIP.org/William and Mary 4 Expires: June 2, 2006 E. Shim 5 Panasonic 6 B. B. Lowekamp 7 William and Mary 8 November 29, 2005 10 Use Cases for Peer-to-Peer Session Initiation Protocol (P2P SIP) 11 draft-bryan-sipping-p2p-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 June 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . 5 57 3.1.3 Presence Using Multimedia Consumer Electronics 58 Devices . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2 Security Demanding Environments . . . . . . . . . . . . . 5 60 3.2.1 Impeded Access . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2 Anonymous Communications . . . . . . . . . . . . . . . 6 62 3.2.3 Security Conscious Small Organizations . . . . . . . . 6 63 3.3 Environments with Limited Connectivity to the Internet 64 or Infrastructure . . . . . . . . . . . . . . . . . . . . 6 65 3.3.1 Ad-Hoc and Ephemeral Groups . . . . . . . . . . . . . 7 66 3.3.2 Emergency First Responder Networks . . . . . . . . . . 7 67 3.3.3 Extending the Reach of Mobile Devices . . . . . . . . 7 68 3.3.4 Deployments in the Developing World . . . . . . . . . 8 69 3.4 Managed, Private Network Environments . . . . . . . . . . 8 70 3.4.1 Serverless or Small Scale IP-PBX . . . . . . . . . . . 8 71 3.4.2 P2P for Redundant SIP Proxies . . . . . . . . . . . . 9 72 3.4.3 Failover for Centralized Systems . . . . . . . . . . . 9 73 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 77 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 79 Intellectual Property and Copyright Statements . . . . . . . . 12 81 1. Introduction 83 This document attempts to identify and classify use cases for Peer- 84 to-Peer (P2P) based Session Initiation Protocol (SIP)[2]. 85 Identifying use cases will help to understand and clarify 86 requirements of P2P SIP. In particular, these use cases will assist 87 in identifying commonalities and differences between requirements for 88 P2P SIP for different use cases, which in turn will help define the 89 near-term scope of specifications and provide a perspective on future 90 specifications. 92 Only use cases related to real-time IP communications, such as VoIP, 93 Instant Messaging (IM), and presence are considered in this document. 94 Use cases of other kinds, even if interesting and possibly useful 95 applications of P2P SIP, are out of scope for this document. Thus, 96 use cases described herein are use cases of P2P IP real-time 97 communications, and P2P SIP is a protocol choice rather than a 98 constraining factor for most of them. In describing use cases, no 99 deliberation on implementation is provided. Some of the use cases 100 presented may already be implemented or deployed, possibly using 101 proprietary technology. 103 Some of these use cases, while difficult to implement using a 104 traditional client server SIP (CS SIP) architecture may not require 105 P2P and could be implemented in other ways. While these have often 106 been presented as scenarios calling for P2P communication, the 107 authors recognize that other technologies may also be applicable to 108 these use cases. 110 Several existing documents[3][4][5] have presented limited 111 collections of use case scenarios. This draft draws from these 112 documents, as well as discussions at the P2P SIP ad-hoc meetings at 113 IETFs 62-64, and numerous mailing list and personal conversations of 114 the authors. The list of use cases compiled here is by no means a 115 complete list of uses cases of P2P SIP, and further cases would be 116 limited only by the imagination. 118 2. Terminology 120 In this document, words which are normally key words, such as "MUST", 121 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 122 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are used 123 COLLOQUIALLY and are not intended to be interpreted as described in 124 RFC2119 [1]. 126 Peer-to-Peer (P2P) Architecture: An architecture in which nodes 127 (peers) cooperate together to perform tasks. Each node has 128 essentially equal importance and performs the same tasks within 129 the network. Additionally, nodes communicate directly with one 130 another to perform tasks. Occasionally, nodes with superior 131 resources (such as not being behind NATs) may have a superior 132 role. Contrast this to a Client-Server (CS) architecture. 133 Client-Server (CS) Architecture: An architecture in which some small 134 number of nodes (servers) provide services to a larger number of 135 nodes (clients). Client nodes connect to servers, but typically 136 do not communicate among themselves. 137 Overlay (Network) or P2P Overlay (Network): A virtual network created 138 by the interconnection between the nodes participating in a 139 particular P2P service or application. 141 Terminology defined in RFC3261 [2] is used without definition. 143 3. Use Cases 145 Use cases are grouped according to the characteristics of the network 146 environment in which the end users or devices participating in the 147 P2P overlay are communicating with each other. 149 3.1 Global Internet Environment 151 The global Internet environment consists of a large number of 152 autonomous networks with diverse characteristics. Thus, there is no 153 central administration or network control of the physical network on 154 a global scale. Communication paths between two remote devices may 155 span multiple administrative domains and should be assumed to be 156 insecure. Note that most well-known P2P file sharing overlay 157 networks have operated in this environment. 159 3.1.1 Public P2P VoIP Service Providers 161 Skype is an outstanding example of a public VoIP service provider 162 using P2P technology among end user devices, although using a 163 proprietary protocol. Recent research has shown [6]that Skype uses a 164 central login server, responsible for management of registered user 165 names. End users are authenticated via certificate signed by a 166 central server. End user devices are distributed across the global 167 Internet. The number of participating end user devices is very 168 large. A major motivation of using P2P between end user devices for 169 a commercial VoIP service is a reduction in infrastructure and 170 operational costs. 172 3.1.2 Open Global P2P VoIP Network 174 This is a global P2P VoIP network in which there is no central 175 authority such as a single service provider. Anyone can join and 176 leave the network freely and anyone can implement the software to 177 participate in the overlay network. In such a system, the protocols 178 used must be based on open standards. This P2P VoIP network 179 resembles the global Internet itself in that it has distributed 180 management and growth, enables anyone to reach anyone else in the 181 overlay network, and any device supporting the standard protocols can 182 be used. 184 3.1.3 Presence Using Multimedia Consumer Electronics Devices 186 Presence is a useful and important feature for instant messaging and 187 VoIP applications. Well-known instant messaging application software 188 provides presence, text and media messaging, and supports file 189 transfer between online users. As more and more multimedia consumer 190 electronics devices such as cameras, camcorders and televisions 191 become network aware, instant sharing of multimedia content such as 192 photos and video clips between family members and friends will be 193 desirable. VoIP may not be needed on some of these consumer 194 electronics devices, however presence that enables instant content 195 sharing will be required for many types of consumer electronics 196 devices. A global P2P network supporting presence is an important 197 infrastructure component for this use case. 199 3.2 Security Demanding Environments 201 There are situations where, despite having connectivity to the 202 Internet or even to client server SIP infrastructure such as SIP 203 proxies, users may not like to use the infrastructure because of 204 security concerns or may not be allowed to use the infrastructure. 205 Such situations are referred to here as involving a security 206 demanding environment. Maintaining privacy of communication and 207 secrecy of identities are important in this environment and the P2P 208 architecture's distributed nature may be more attractive than a 209 client server approach. 211 3.2.1 Impeded Access 213 Certain groups may have their ability to communicate impeded. These 214 users should be able to communicate without the need to connect to 215 any centralized servers, which may be blocked by providers upstream 216 of the user. A fully decentralized system cannot be completely 217 disconnected without removing connectivity at the basic Internet 218 level. 220 Examples: A user wishes to use an IP telephony service to communicate 221 PC to PC with a friend, but the ports commonly used by these 222 services, or the the servers used for authentication, are blocked by 223 the ISP because the ISP also offers communications systems and have a 224 vested interest in denying access. 226 A user with an Internet enabled PDA devices wishes to connect with 227 colleagues, but traditional services are blocked to ensure that SMS 228 or voice minutes are used (at additional cost) instead. 230 3.2.2 Anonymous Communications 232 Users occasionally have need to communicate among themselves in a 233 completely anonymous fashion, whether due to political persecution, 234 need for secrecy for commercial reasons, or threats of violence. In 235 such a case, the need for a self organizing, server-less system is 236 imperative. Users on such a system could communicate with reduced 237 risk of the system being monitored or their identities discovered. 238 As with the impeded access scenario, the only way to disable such 239 networks would be to completely disable Internet connectivity. 241 3.2.3 Security Conscious Small Organizations 243 Certain security conscious small organizations may have need for 244 communications systems that allow members of the organization to 245 communicate directly with one another regardless of their location, 246 with encryption, and without any connectivity to or use of servers, 247 either internal or external to the organization. For these 248 organizations, traditional client-server SIP implementations and more 249 importantly hosted solutions for communications are unacceptable. 250 These entities need a system to facilitate such communications 251 without central servers. Note that these users may overlap with the 252 anonymized communications case also described in this document. 254 Examples: Organizations who are developing technology that might be 255 of interest to a hosted service provider, but because of small size 256 may have no desire or time to maintain centralized servers. 257 Organizations with security needs that preclude any traffic flowing 258 through a central server such as military, national security, or 259 intelligence organizations. 261 3.3 Environments with Limited Connectivity to the Internet or 262 Infrastructure 264 When there is no physical network available for stable deployment of 265 client server SIP or an instant deployment of real-time communication 266 systems is required, the P2P approach may be the only feasible 267 solution. Examples of such environment are isolated wireless ad-hoc 268 networks with no connection to the Internet or ad-hoc networks with 269 limited connectivity to the Internet in situations like outdoor 270 public events, emergencies, and battlefields. Any type of manual 271 configuration is difficult to achieve because technical support is 272 not readily available in such environment. In some cases, 273 connectivity to the global Internet may be available, but be very 274 expensive, of limited capacity, or unstable, such as satellite 275 connections. In such cases, it is preferable to localize 276 communications as much as possible, reducing dependency on any 277 infrastructure in the global Internet. 279 3.3.1 Ad-Hoc and Ephemeral Groups 281 Groups of individuals meeting together have need for collaborative 282 communications systems that are ephemeral in nature, have minimum 283 (ideally zero) configuration, and do not depend on connectivity to 284 the Internet. These scenarios require an arbitrary number of users 285 to connect communications devices. 287 Example: A group gets together for a meeting, but there is no 288 Internet connectivity. If the users establish a wireless ad hoc 289 network or have a base station, all users may connect and establish 290 chat sessions using an IM protocol with no need for server 291 configuration. 293 3.3.2 Emergency First Responder Networks 295 Following a large scale disaster such as a tsunami, earthquake, 296 hurricane, or terrorist attack, access to traditional communications 297 devices of any kind -- Internet, cellular, or traditional PSTN -- may 298 be compromised. Recent events have shown that current first 299 responder radio systems cannot be relied upon to interoperate 300 effectively. A network of devices that can grow organically as 301 responders arrive, requiring only wireless access, is required. As 302 more personnel show up, they should be able to join the network, 303 locate other personnel, and communicate without any centralized 304 configuration required. 306 Example: Following a disaster, the local fire department arrives. 307 Each fire fighter has a wireless handset, and one or more trucks have 308 wireless base stations. When a nearby locality sends additional 309 rescuers, their wireless handsets should be able to instantly join 310 the communications network and communicate. 312 3.3.3 Extending the Reach of Mobile Devices 314 A network of mobile devices can relay traffic between themselves to 315 reach a base station, even if the base station is out of reach of 316 that device. 318 Example: A user has a handset for communication that cannot reach a 319 base station. Some other user is within range of both that user and 320 a base station. This intermediate user can serve as a relay for the 321 caller who is out of range. A system might make this feature 322 optional for standard communication and mandatory for E911. 324 3.3.4 Deployments in the Developing World 326 Certain locations in the developing world have limited, intermittent, 327 or non-existent connectivity to the Internet. These locations also 328 typically lack experienced people with the specialized skills needed 329 to administer or maintain centralized SIP proxies. Even DNS servers 330 may not exist. A communications system that is able to function 331 reliably for internal communications, even in the presence of 332 degraded or absent connectivity, is clearly needed. Such a system 333 must also scale easily with little or no configuration and ideally 334 should interface easily to existing communications systems when 335 connectivity is available. 337 Example: A village in the developing world has connectivity that is 338 limited by weather (microwave connection) or is solar powered. It 339 would be desirable for intra-village communication to continue to 340 function in the absence of Internet connectivity. 342 3.4 Managed, Private Network Environments 344 A corporate network or a school campus network is an example of the 345 managed, private network environment. Most likely client server SIP 346 can be used and managed for real-time communication applications in 347 these environment. However, in certain scenarios, P2P SIP may be 348 used instead or as a complementary means, to achieve various goals 349 such as cost and management overhead reduction, scalability, and 350 system robustness. 352 3.4.1 Serverless or Small Scale IP-PBX 354 Many small enterprises have a need for integrated communications 355 systems. These systems have slightly different requirements than 356 more traditional IP PBXs. For small enterprises, there may be no 357 administrator for these systems, requiring the systems to be 358 essentially self-configuring and/or self-organizing. Additional 359 endpoints should be able to be added with no requirements for 360 configuration on central devices. 362 These systems should offer the feature sets similar to those of 363 client server type PBX systems. Connectivity to the PSTN is an 364 important feature for these systems. In addition, they may support 365 features such as call transfer, voice mail, and possibly even other 366 communications modes such as instant messaging or media features such 367 as video or conference services. There are already commercial 368 products of this type. 370 Example: Small organizations without centralized IT 372 3.4.2 P2P for Redundant SIP Proxies 374 Service providers may wish to connect a farm of proxies together in a 375 transparent way, passing resources (user registrations or other call 376 information) between themselves with as little configuration or 377 traffic as possible. Ideally, the redundancy and exchange of 378 information should require a minimum of configuration between the 379 devices. A P2P architecture between the proxies allows proxy farms 380 to be organizing and operated in this way. With this approach, it is 381 easy to add more proxies with minimal service disruptions and 382 increases the robustness of the system. 384 3.4.3 Failover for Centralized Systems 386 A traditional centralized SIP server, such as used in an IP-PBX, 387 forms a single point of failure of an otherwise fault-independent 388 network. Relying on P2P SIP as a backup to the centralized server 389 allows the communications system to continue functioning normally in 390 the event of planned or unplanned service interruptions of the 391 central IP-PBX. 393 Example: A small company has a central IP-PBX. When that device 394 experiences a failure, the handsets are able to transparently 395 continue operation for the 24 hours it takes to obtain a replacement 396 switch. 398 4. Acknowledgments 400 The following persons have contributed use case suggestions or ideas 401 to this document: 403 Cullen Jennings, Philip Matthews, Henry Sinnreich, Adam Roach, Robert 404 Sparks, Kundan Singh, Henning Schulzrinne, K. Kishore Dhara, and 405 Salman A. Baset. 407 5. IANA Considerations 409 This document has no IANA Considerations. 411 6. References 412 6.1 Normative References 414 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 415 Levels", BCP 14, RFC 2119, March 1997. 417 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 418 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 419 Session Initiation Protocol", RFC 3261, June 2002. 421 [3] Bryan, D. and C. Jennings, "A P2P Approach to SIP 422 Registrations", Internet Draft draft-bryan-sipping-p2p-01, 423 July 2005. 425 [4] Baset, S., Schulzrinne, H., Shim, E., and K. Dhara, 426 "Requirements for SIP-based Peer-to-Peer Internet Telephony", 427 Internet Draft draft-baset-sipping-p2preq-00, October 2005. 429 6.2 Informative References 431 [5] Bryan, D., Jennings, C., and B. Lowekamp, "SOSIMPLE: A 432 Serverless, Standards-based, P2P SIP Communication System", 433 Proceedings of the 2005 International Workshop on Advanced 434 Architectures and Algorithms for Internet Delivery and 435 Applications (AAA-IDEA) (IEEE Press) '05, June 2005. 437 [6] Baset, S. and H. Schulzrinne, "An Analysis of the Skype Peer-to- 438 Peer Internet Telephony Protocol", Technical Report, Department 439 of Computer Science, Columbia University 0309-04, 440 September 2004. 442 Authors' Addresses 444 David A. Bryan 445 P2PSIP.org and William and Mary Department of Computer Science 446 P.O. Box 6741 447 Williamsburg, VA 23188 448 USA 450 Email: bryan@ethernot.org 451 Eunsoo Shim 452 Panasonic Digital Networking Laboratory 453 Two Research Way, 3rd Floor 454 Princeton, NJ 08540 455 USA 457 Email: eunsoo@research.panasonic.com 459 Bruce B. Lowekamp 460 William and Mary 461 Department of Computer Science 462 P.O. Box 8795 463 Williamsburg, VA 23187 464 USA 466 Email: lowekamp@cs.wm.edu 468 Intellectual Property Statement 470 The IETF takes no position regarding the validity or scope of any 471 Intellectual Property Rights or other rights that might be claimed to 472 pertain to the implementation or use of the technology described in 473 this document or the extent to which any license under such rights 474 might or might not be available; nor does it represent that it has 475 made any independent effort to identify any such rights. Information 476 on the procedures with respect to rights in RFC documents can be 477 found in BCP 78 and BCP 79. 479 Copies of IPR disclosures made to the IETF Secretariat and any 480 assurances of licenses to be made available, or the result of an 481 attempt made to obtain a general license or permission for the use of 482 such proprietary rights by implementers or users of this 483 specification can be obtained from the IETF on-line IPR repository at 484 http://www.ietf.org/ipr. 486 The IETF invites any interested party to bring to its attention any 487 copyrights, patents or patent applications, or other proprietary 488 rights that may cover technology that may be required to implement 489 this standard. Please address the information to the IETF at 490 ietf-ipr@ietf.org. 492 Disclaimer of Validity 494 This document and the information contained herein are provided on an 495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 497 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 498 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 499 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Copyright Statement 504 Copyright (C) The Internet Society (2005). This document is subject 505 to the rights, licenses and restrictions contained in BCP 78, and 506 except as set forth therein, the authors retain all their rights. 508 Acknowledgment 510 Funding for the RFC Editor function is currently provided by the 511 Internet Society.