idnits 2.17.1 draft-matthews-sipping-p2p-industrial-strength-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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 372), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (February 11, 2005) is 7014 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: '7' is defined on line 303, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 310, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-00 == Outdated reference: A later version (-02) exists of draft-johnston-sipping-p2p-ipcom-00 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group P. Matthews 2 Internet Draft Nimcat Networks 3 Expires: August 2005 4 B. Poustchi 5 Nimcat Networks 7 February 11, 2005 9 Industrial-Strength P2P SIP 10 draft-matthews-sipping-p2p-industrial-strength-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 11, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 If internet telephony networks based on peer-to-peer and Session 44 Initiation Protocol (SIP) technology are to become as viable as 45 existing centralized telephony services, the peer-to-peer SIP 46 technology must offer all the features of existing technologies. This 47 draft lists some features which are in some way "challenging" for 48 peer-to-peer SIP to support, and proposes a structure for the 49 resulting protocol suite. 51 1. Introduction 53 Peer-to-peer technology offers the promise of being able to replace 54 centralized services with distributed systems, thus eliminating the 55 need for a centralized server. Our interest lies in the application 56 of peer-to-peer technology to telephony networks based on SIP [1]. 57 Specifically, we are interested in constructing peer-to-peer 58 telephony networks that offer the same feature set as existing 59 centralized networks, but at a lower cost. The lower cost comes from 60 eliminating the need to buy and set up central servers. 62 In order for networks based on peer-to-peer SIP technology 63 (henceforth called P2P SIP) to become as viable as existing networks, 64 the new P2P SIP technology must offer the same feature set and 65 performance as existing technology. We apply the term "industrial- 66 strength" to P2P SIP technology that meets this goal, in order to 67 contrast it with other P2P SIP technology that has less-stringent 68 goals. 70 Recently, a couple of other drafts [2][3] on P2P SIP technology have 71 been submitted to the SIPPING working group. The contribution of this 72 draft is the focus on "industrial-strength" P2P SIP and its 73 implications. 75 Specifically, this draft does two things. In section 2, it lists some 76 features that must be supported by an "industrial-strength" P2P SIP 77 network. In section 3, it presents a structure for the resulting P2P 78 SIP protocol suite. 80 This draft is being discussed on the SIPPING Working Group mailing 81 list (sipping@ietf.org). 83 2. Features for "industrial-strength" P2P SIP networks 85 It may be that there will be different types of P2P SIP networks. One 86 type that that has been mentioned by others is ad-hoc networks, 87 formed to allow people with similar interests to set up a private 88 overlay network for communication. These are usually envisioned to be 89 temporary and/or have a reasonably high membership churn. 91 We, however, are interested in more permanent networks that replace 92 existing telephony systems. An example is placing P2P SIP technology 93 inside phones in an office to give the illusion that the phones are 94 connected to a centralized PBX system. Here the advantage of P2P 95 technology is that there is no need to buy and maintain a centralized 96 PBX server. 98 For these more permanent P2P SIP networks to be successful, they must 99 duplicate most of the features of existing telephony systems. In 100 particular, some of the necessary features that might be considered 101 more "challenging" are: 103 o Support for heterogeneous networks 105 o Support for call handling for an unreachable device 107 o Support for dividing the network into zones 109 o Support for network management 111 o Security 113 These features are discussed in more detail in the sub-sections 114 below. 116 2.1. Heterogeneous networks 118 The P2P SIP network must support a mixture of devices with different 119 attachment bandwidths, storage capacities, network availabilities, 120 and mobility capabilities. For example, the network may consist of a 121 mixture of phones (either soft or hard) that sit on users' desks and 122 are almost always connected to the network, with some mobile wireless 123 handsets that connect and disconnect frequently and may have lower 124 attachment bandwidths and local storage capacities. The challenge 125 here is to devise protocols that take these different device 126 capabilities into account. 128 For example, some P2P lookup protocols (like Jxta [4]) assume that 129 devices join and leave the network frequently and are thus optimized 130 for this case. Other P2P protocols (like CAN [5] and Chord [6]) are 131 more concerned with reducing lookup time, and thus device-join and 132 device-leave operations are relatively more expensive. 134 2.2. Call handling for an unreachable device 136 The P2P SIP network must support call handling features such as call 137 forwarding and voicemail. The challenge here is to support these 138 features in a P2P network where devices are not always reachable. 140 For example, consider a handheld SIP phone using WiFi for network 141 connectivity. When the device becomes unreachable because it is out- 142 of-range (or turned off), the phone's owner might like callers to be 143 forwarded to another number or to be able to leave a voicemail 144 message. How does the system remember this preference when the user's 145 phone is not available, and how does it store any voicemail message? 146 In a pure P2P system, both pieces of information must be stored on 147 another user's device. And since that second device might also become 148 unreachable, we must duplicate the information and store copies on a 149 number of devices to ensure that the information (both call treatment 150 information and any received voicemail message) is available when it 151 is needed (e.g., when a call comes in or the user wants to retrieve 152 stored voicemail messages). Here the characteristics of different 153 device comes into account: storing this information on other handheld 154 WiFi devices is likely to result in more messaging and be perhaps 155 less-reliable compared to storing copies on stationary desktop 156 devices. 158 2.3. Dividing the network into zones 160 As a network of any type grows larger, any security, stability or 161 scalability problems the network might have tend to get magnified. As 162 a result, the network is often divided into zones to try to keep 163 problems in one part of the network for affecting another part. 165 An example is the deployment of BGP, which can be considered an early 166 P2P protocol. Here, service providers run one flavor of BGP (iBGP) 167 internally, and another flavor (eBGP) when connecting to other 168 carriers. Moreover, larger service providers often divide up their 169 internal networks (for example, by using BGP confederation or 170 multiple autonomous system (AS) numbers) to achieve greater 171 scalability and to try to restrict problems to a portion of their 172 network. 174 We believe that any "industrial-strength" P2P SIP protocol suite will 175 need ways to divide the network up into zones. 177 Note that dividing a network into zones may also make it easier to 178 support heterogeneous networks. 180 2.4. Network Management 182 The P2P SIP network must provide a way for an authorized 183 administrator to perform typical network management functions, such 184 as: 186 o Diagnose and correct network problems 187 ("Why can't I reach Alice?") 189 o Configure network settings 190 ("Store a maximum of 3 minutes of voicemail for each user") 192 o Change user privileges or perform other per-user operations 193 ("Please reset my password?") 195 The details of how network management is done will likely vary from 196 vendor to vendor, but the P2P SIP protocol suite needs to provide 197 some basic support for this function. 199 2.5. Security 201 Security in an "industrial-strength" P2P SIP network is very 202 important, perhaps even more important than in ad-hoc networks. 204 Other documents ([2][3]) have discussed various security issues in 205 P2P SIP networks. Here we mention some of the additional security 206 issues raised by the features discussed in this draft: 208 o If a voicemail message is left for Alice when Alice's phone is not 209 available, then the message must be stored somewhere on the 210 network. This will involve storing a copy (or part of a copy) in 211 the phones of various users. If Bob is one of those users, then 212 Bob should not be able to hear it or tamper with it. 214 o Say Alice sets her desktop phone's call handling preferences so 215 that most missed calls get redirected to voicemail, but calls from 216 certain friends get redirected to her mobile phone. If Charlie 217 (who is not on Alice's list of friends) phones Alice, then he 218 should not be able to learn the address of her mobile phone 219 (unless Alice wishes it). 221 And, of course, anyone who attempts to do network management 222 operations must be authenticated. 224 3. Structure of the P2P SIP protocol suite 226 Based on the above feature set, we suggest the P2P SIP protocol suite 227 be divided into the following parts: 229 o P2P layer 231 o SIP layer 232 o Call Services layer 234 The P2P layer provides basic P2P services for registering and 235 locating nodes and resources. This should be a generic P2P layer that 236 can be used for many different P2P applications. This layer needs to 237 take the capabilities of different devices into account, but should 238 need no special knowledge of P2P SIP. 240 The SIP layer includes SIP and any extensions (e.g., SIMPLE). This 241 layer is basically the SIP protocol and extensions as they are today 242 -- little or no changes should be required. 244 The Call Services layer provides the protocols that support call 245 forwarding, voicemail, and similar services. This layer builds upon 246 the services of the P2P and SIP layers and defines protocols as 247 necessary. In essence, this is glue layer that takes the independent 248 P2P and SIP layers and brings them together into the cohesive whole 249 we call P2P SIP. 251 Structuring P2P SIP in this manner has the following properties: 253 o It leaves the SIP layer basically untouched. This maintains two 254 often-citied advantages of SIP over H.323: simplicity and narrow 255 focus. 257 o It leaves the P2P layer independent of SIP. Thus the P2P layer can 258 evolve independently of SIP, and can be used for other 259 applications that run on the devices in the network that have 260 nothing to do with SIP. 262 By way of analogy, consider the relationship between SIP and SDP. 263 Though SDP is commonly used with SIP, there is nothing in the SIP 264 protocol that gives SDP any special consideration, and it is easy to 265 substitute another protocol in place of SDP. The above structure 266 supports the same relationship between SIP and P2P. 268 4. Security Considerations 270 See section 2.5. 272 5. Acknowledgments 274 We thank Eric Cooper, Mahshad Koohgoli, and Jim Stelzig for useful 275 discussions leading up to this draft. 277 6. Informative References 279 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 280 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 281 Session Initiation Protocol", RFC 3261, June 2002. 283 [2] Bryan, D. and Jennings, C., "A P2P approach to SIP 284 Registration", Internet-Draft draft-bryan-sipping-p2p-00, 285 January 2005. 287 [3] Johnston, A., "SIP, P2P, and Internet Communications", 288 Internet-Draft draft-johnston-sipping-p2p-ipcom-00, January 289 2005. 291 [4] Traversat, B. et al. "Project JXTA 2.0 Super-Peer Virtual 292 Network", May 2003. 293 Available at http://www.jxta.org/white_papers.html. 295 [5] Ratnasamy, S. P. Francis, M. Handley, R. Karp, and S. Shenker 296 "A Scalable Content-Addressable Network", SIGCOMM 2001 297 Conference, August 2001. 299 [6] Stoica, I., R. Morris, D. Karger, M.F. Kaashoek, and H. 300 Balakrishnan "Chord: A Scalable Peer-to-peer Lookup Service for 301 Internet Applications", SIGCOMM 2001 Conference, August 2001. 303 [7] Zhao, B.Y., J. Kubiatowicz, and A.D.Joseph "Tapestry: An 304 Infrastructure for Fault-tolerant Wide-area Location and 305 Routing", UC Berkeley Technical Report UCB/CSD-01-1141, April 306 2001. 307 Available at http://www.cs.berkeley.edu/~ravenben/publications/ 308 CSD-01-1141.pdf 310 [8] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed 311 object location and routing for large-scale peer-to-peer 312 systems", IFIP/ACM Int. Conf. on Distributed Systems Platforms, 313 November 2001. 314 Available at http://research.microsoft.com/~antr/Pastry/ 315 pubs.htm 317 Authors' Addresses 319 Philip Matthews 320 Nimcat Networks 321 1135 Innovation Drive 322 Ottawa, Ontario K2K 3G7 323 Email: matthews@nimcatnetworks.com 325 Behrouz Poustchi 326 Nimcat Networks 327 1135 Innovation Drive 328 Ottawa, Ontario K2K 3G7 329 Email: poustchi@nimcatnetworks.com 331 Intellectual Property Statement 333 The IETF takes no position regarding the validity or scope of any 334 Intellectual Property Rights or other rights that might be claimed to 335 pertain to the implementation or use of the technology described in 336 this document or the extent to which any license under such rights 337 might or might not be available; nor does it represent that it has 338 made any independent effort to identify any such rights. Information 339 on the procedures with respect to rights in RFC documents can be 340 found in BCP 78 and BCP 79. 342 Copies of IPR disclosures made to the IETF Secretariat and any 343 assurances of licenses to be made available, or the result of an 344 attempt made to obtain a general license or permission for the use of 345 such proprietary rights by implementers or users of this 346 specification can be obtained from the IETF on-line IPR repository at 347 http://www.ietf.org/ipr. 349 The IETF invites any interested party to bring to its attention any 350 copyrights, patents or patent applications, or other proprietary 351 rights that may cover technology that may be required to implement 352 this standard. Please address the information to the IETF at 353 ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that 354 any applicable patent or other IPR claims of which I am aware have 355 been disclosed, and any of which I become aware will be disclosed, in 356 accordance with RFC 3668. 358 Disclaimer of Validity 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 365 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Copyright Statement 370 Copyright (C) The Internet Society (2005). This document is subject 371 to the rights, licenses and restrictions contained in BCP 78, and 372 except as set forth therein, the authors retain all their rights. 374 Acknowledgment 376 Funding for the RFC Editor function is currently provided by the 377 Internet Society.