SIPPING Working Group P. Matthews Internet Draft Nimcat Networks Expires: August 2005 B. Poustchi Nimcat Networks February 11, 2005 Industrial-Strength P2P SIP draft-matthews-sipping-p2p-industrial-strength-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 11, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract If internet telephony networks based on peer-to-peer and Session Initiation Protocol (SIP) technology are to become as viable as existing centralized telephony services, the peer-to-peer SIP Matthews & Poustchi Expires August 11, 2005 [Page 1] Internet-Draft Industrial-Strength P2P SIP February 2005 technology must offer all the features of existing technologies. This draft lists some features which are in some way "challenging" for peer-to-peer SIP to support, and proposes a structure for the resulting protocol suite. 1. Introduction Peer-to-peer technology offers the promise of being able to replace centralized services with distributed systems, thus eliminating the need for a centralized server. Our interest lies in the application of peer-to-peer technology to telephony networks based on SIP [1]. Specifically, we are interested in constructing peer-to-peer telephony networks that offer the same feature set as existing centralized networks, but at a lower cost. The lower cost comes from eliminating the need to buy and set up central servers. In order for networks based on peer-to-peer SIP technology (henceforth called P2P SIP) to become as viable as existing networks, the new P2P SIP technology must offer the same feature set and performance as existing technology. We apply the term "industrial- strength" to P2P SIP technology that meets this goal, in order to contrast it with other P2P SIP technology that has less-stringent goals. Recently, a couple of other drafts [2][3] on P2P SIP technology have been submitted to the SIPPING working group. The contribution of this draft is the focus on "industrial-strength" P2P SIP and its implications. Specifically, this draft does two things. In section 2, it lists some features that must be supported by an "industrial-strength" P2P SIP network. In section 3, it presents a structure for the resulting P2P SIP protocol suite. This draft is being discussed on the SIPPING Working Group mailing list (sipping@ietf.org). 2. Features for "industrial-strength" P2P SIP networks It may be that there will be different types of P2P SIP networks. One type that that has been mentioned by others is ad-hoc networks, formed to allow people with similar interests to set up a private overlay network for communication. These are usually envisioned to be temporary and/or have a reasonably high membership churn. We, however, are interested in more permanent networks that replace existing telephony systems. An example is placing P2P SIP technology Matthews & Poustchi Expires August 11, 2005 [Page 2] Internet-Draft Industrial-Strength P2P SIP February 2005 inside phones in an office to give the illusion that the phones are connected to a centralized PBX system. Here the advantage of P2P technology is that there is no need to buy and maintain a centralized PBX server. For these more permanent P2P SIP networks to be successful, they must duplicate most of the features of existing telephony systems. In particular, some of the necessary features that might be considered more "challenging" are: o Support for heterogeneous networks o Support for call handling for an unreachable device o Support for dividing the network into zones o Support for network management o Security These features are discussed in more detail in the sub-sections below. 2.1. Heterogeneous networks The P2P SIP network must support a mixture of devices with different attachment bandwidths, storage capacities, network availabilities, and mobility capabilities. For example, the network may consist of a mixture of phones (either soft or hard) that sit on users' desks and are almost always connected to the network, with some mobile wireless handsets that connect and disconnect frequently and may have lower attachment bandwidths and local storage capacities. The challenge here is to devise protocols that take these different device capabilities into account. For example, some P2P lookup protocols (like Jxta [4]) assume that devices join and leave the network frequently and are thus optimized for this case. Other P2P protocols (like CAN [5] and Chord [6]) are more concerned with reducing lookup time, and thus device-join and device-leave operations are relatively more expensive. 2.2. Call handling for an unreachable device The P2P SIP network must support call handling features such as call forwarding and voicemail. The challenge here is to support these features in a P2P network where devices are not always reachable. Matthews & Poustchi Expires August 11, 2005 [Page 3] Internet-Draft Industrial-Strength P2P SIP February 2005 For example, consider a handheld SIP phone using WiFi for network connectivity. When the device becomes unreachable because it is out- of-range (or turned off), the phone's owner might like callers to be forwarded to another number or to be able to leave a voicemail message. How does the system remember this preference when the user's phone is not available, and how does it store any voicemail message? In a pure P2P system, both pieces of information must be stored on another user's device. And since that second device might also become unreachable, we must duplicate the information and store copies on a number of devices to ensure that the information (both call treatment information and any received voicemail message) is available when it is needed (e.g., when a call comes in or the user wants to retrieve stored voicemail messages). Here the characteristics of different device comes into account: storing this information on other handheld WiFi devices is likely to result in more messaging and be perhaps less-reliable compared to storing copies on stationary desktop devices. 2.3. Dividing the network into zones As a network of any type grows larger, any security, stability or scalability problems the network might have tend to get magnified. As a result, the network is often divided into zones to try to keep problems in one part of the network for affecting another part. An example is the deployment of BGP, which can be considered an early P2P protocol. Here, service providers run one flavor of BGP (iBGP) internally, and another flavor (eBGP) when connecting to other carriers. Moreover, larger service providers often divide up their internal networks (for example, by using BGP confederation or multiple autonomous system (AS) numbers) to achieve greater scalability and to try to restrict problems to a portion of their network. We believe that any "industrial-strength" P2P SIP protocol suite will need ways to divide the network up into zones. Note that dividing a network into zones may also make it easier to support heterogeneous networks. 2.4. Network Management The P2P SIP network must provide a way for an authorized administrator to perform typical network management functions, such as: Matthews & Poustchi Expires August 11, 2005 [Page 4] Internet-Draft Industrial-Strength P2P SIP February 2005 o Diagnose and correct network problems ("Why can't I reach Alice?") o Configure network settings ("Store a maximum of 3 minutes of voicemail for each user") o Change user privileges or perform other per-user operations ("Please reset my password?") The details of how network management is done will likely vary from vendor to vendor, but the P2P SIP protocol suite needs to provide some basic support for this function. 2.5. Security Security in an "industrial-strength" P2P SIP network is very important, perhaps even more important than in ad-hoc networks. Other documents ([2][3]) have discussed various security issues in P2P SIP networks. Here we mention some of the additional security issues raised by the features discussed in this draft: o If a voicemail message is left for Alice when Alice's phone is not available, then the message must be stored somewhere on the network. This will involve storing a copy (or part of a copy) in the phones of various users. If Bob is one of those users, then Bob should not be able to hear it or tamper with it. o Say Alice sets her desktop phone's call handling preferences so that most missed calls get redirected to voicemail, but calls from certain friends get redirected to her mobile phone. If Charlie (who is not on Alice's list of friends) phones Alice, then he should not be able to learn the address of her mobile phone (unless Alice wishes it). And, of course, anyone who attempts to do network management operations must be authenticated. 3. Structure of the P2P SIP protocol suite Based on the above feature set, we suggest the P2P SIP protocol suite be divided into the following parts: o P2P layer o SIP layer Matthews & Poustchi Expires August 11, 2005 [Page 5] Internet-Draft Industrial-Strength P2P SIP February 2005 o Call Services layer The P2P layer provides basic P2P services for registering and locating nodes and resources. This should be a generic P2P layer that can be used for many different P2P applications. This layer needs to take the capabilities of different devices into account, but should need no special knowledge of P2P SIP. The SIP layer includes SIP and any extensions (e.g., SIMPLE). This layer is basically the SIP protocol and extensions as they are today -- little or no changes should be required. The Call Services layer provides the protocols that support call forwarding, voicemail, and similar services. This layer builds upon the services of the P2P and SIP layers and defines protocols as necessary. In essence, this is glue layer that takes the independent P2P and SIP layers and brings them together into the cohesive whole we call P2P SIP. Structuring P2P SIP in this manner has the following properties: o It leaves the SIP layer basically untouched. This maintains two often-citied advantages of SIP over H.323: simplicity and narrow focus. o It leaves the P2P layer independent of SIP. Thus the P2P layer can evolve independently of SIP, and can be used for other applications that run on the devices in the network that have nothing to do with SIP. By way of analogy, consider the relationship between SIP and SDP. Though SDP is commonly used with SIP, there is nothing in the SIP protocol that gives SDP any special consideration, and it is easy to substitute another protocol in place of SDP. The above structure supports the same relationship between SIP and P2P. 4. Security Considerations See section 2.5. 5. Acknowledgments We thank Eric Cooper, Mahshad Koohgoli, and Jim Stelzig for useful discussions leading up to this draft. Matthews & Poustchi Expires August 11, 2005 [Page 6] Internet-Draft Industrial-Strength P2P SIP February 2005 6. Informative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bryan, D. and Jennings, C., "A P2P approach to SIP Registration", Internet-Draft draft-bryan-sipping-p2p-00, January 2005. [3] Johnston, A., "SIP, P2P, and Internet Communications", Internet-Draft draft-johnston-sipping-p2p-ipcom-00, January 2005. [4] Traversat, B. et al. "Project JXTA 2.0 Super-Peer Virtual Network", May 2003. Available at http://www.jxta.org/white_papers.html. [5] Ratnasamy, S. P. Francis, M. Handley, R. Karp, and S. Shenker "A Scalable Content-Addressable Network", SIGCOMM 2001 Conference, August 2001. [6] Stoica, I., R. Morris, D. Karger, M.F. Kaashoek, and H. Balakrishnan "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", SIGCOMM 2001 Conference, August 2001. [7] Zhao, B.Y., J. Kubiatowicz, and A.D.Joseph "Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing", UC Berkeley Technical Report UCB/CSD-01-1141, April 2001. Available at http://www.cs.berkeley.edu/~ravenben/publications/ CSD-01-1141.pdf [8] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems", IFIP/ACM Int. Conf. on Distributed Systems Platforms, November 2001. Available at http://research.microsoft.com/~antr/Pastry/ pubs.htm Matthews & Poustchi Expires August 11, 2005 [Page 7] Internet-Draft Industrial-Strength P2P SIP February 2005 Authors' Addresses Philip Matthews Nimcat Networks 1135 Innovation Drive Ottawa, Ontario K2K 3G7 Email: matthews@nimcatnetworks.com Behrouz Poustchi Nimcat Networks 1135 Innovation Drive Ottawa, Ontario K2K 3G7 Email: poustchi@nimcatnetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Matthews & Poustchi Expires August 11, 2005 [Page 8] Internet-Draft Industrial-Strength P2P SIP February 2005 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Matthews & Poustchi Expires August 11, 2005 [Page 9]