[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]