[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SIPPING WG                                                      S. Baset
Internet-Draft                                            H. Schulzrinne
Expires: May 1, 2006                                 Columbia University
                                                                 E. Shim
                                                               Panasonic
                                                                K. Dhara
                                                     Avaya Labs Research
                                                        October 28, 2005


       Requirements for SIP-based Peer-to-Peer Internet Telephony
                     draft-baset-sipping-p2preq-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 May 1, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines requirements for designing peer-to-peer voice,
   text, and real-time multimedia communication system protocols.





Baset, et al.              Expires May 1, 2006                  [Page 1]

Internet-Draft          Requirements for P2P SIP            October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Functional Scope . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  High-level Requirements  . . . . . . . . . . . . . . . . . . .  7
     4.1.  Resources for Distribution . . . . . . . . . . . . . . . .  7
     4.2.  Protocol Reuse . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  DHT Changeability  . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Small Overhead . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  NAT and Firewall Traversal . . . . . . . . . . . . . . . .  7
     4.6.  Voice Transport  . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Deployment Scale . . . . . . . . . . . . . . . . . . . . .  8
   5.  Architectural Requirements . . . . . . . . . . . . . . . . . .  9
     5.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Reliability  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Namespace  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Services/Resource Lookup . . . . . . . . . . . . . . . . .  9
       5.4.1.  Centralized Lookup . . . . . . . . . . . . . . . . . .  9
       5.4.2.  Distributed Lookup . . . . . . . . . . . . . . . . . .  9
     5.5.  Interconnect with P2P, non-P2P and PSTN networks . . . . . 10
   6.  Protocol Specification Requirements  . . . . . . . . . . . . . 11
     6.1.  Support for different DHTs . . . . . . . . . . . . . . . . 11
     6.2.  Addressing for Heterogeneous Resources . . . . . . . . . . 11
   7.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Global Telephony Overlay . . . . . . . . . . . . . . . . . 12
     7.2.  Emergency, Ad-hoc  . . . . . . . . . . . . . . . . . . . . 12
     7.3.  Office Environments, P2P-IP-PBX  . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     8.1.  Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.2.  Signaling and Media Anonymization  . . . . . . . . . . . . 13
     8.3.  Misbehaving Peers  . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17
















Baset, et al.              Expires May 1, 2006                  [Page 2]

Internet-Draft          Requirements for P2P SIP            October 2005


1.  Introduction

   This document has the objective of focusing on the requirements for
   designing protocols for peer-to-peer voice, text, and real-time
   multimedia communication systems.

   Peer-to-peer (P2P) technologies enable large-scale overlay networks
   of hosts for various applications such as file sharing, VoIP,
   presence, instant messaging, content distribution, and collaboration.
   In P2P-based systems, physical resources such as computing power,
   storage space, and network bandwidth from participating hosts are
   collectively used to support the application functions and centrally
   managed severs do not exist or perform much less functions than in
   traditional client server based systems.  Hence, P2P-based systems
   can have advantages of good scalability, reduced management and
   deployment costs, and easy setup.

   The traditional SIP [2] based VoIP systems employ SIP registrars, SIP
   proxy servers, and STUN [11] and TURN [12] servers.  SIP registrars
   are used to locate the user contact information, SIP proxy servers
   are used to route the calls, and STUN and TURN servers are used to
   traverse NATs and firewalls.  The SIP RFC does not mandate the use of
   these servers; it specifically says that all servers in SIP are
   optional.  The deployment and maintenance of these servers can
   constitute a significant cost for a SIP-based VoIP service provider.

   Several peer-to-peer voice systems, such as Skype [13] and Nimcat
   [14] have demonstrated the possibility of voice and IM services for
   end users.  Typically, these systems distribute the functionality of
   location servers and NAT and firewall traversal servers to the end-
   points.  Each end-point or peer can potentially participate in the
   routing decisions and spare its CPU and bandwidth for servicing other
   peers in the network.  Most of these systems assume a network of
   peers that are similar in capabilities such as processing power,
   memory, bandwidth, media mixing abilities.  However, heterogeneous
   peer-to-peer voice network do not operate on such assumptions and
   hence require architectures that support communication among users
   with a diverse set of end-points.

   P2P-based SIP or P2P SIP will enable P2P VoIP and other multimedia
   communications based on open standards.  It was demonstrated by Bryan
   [3] and Singh [4] that it is possible to build a P2P SIP network in
   which the location service is distributed to the end-points.  While
   these two pioneering works take designs quite close to each other, a
   different architecture was proposed by Matthews [6].  A distributed
   location service for SIP was proposed by Johnston [5].  With various
   design options and open issues, identifying requirements for P2P SIP
   will facilitate making design choices.  This document defines a set



Baset, et al.              Expires May 1, 2006                  [Page 3]

Internet-Draft          Requirements for P2P SIP            October 2005


   of requirements for P2P-SIP.


















































Baset, et al.              Expires May 1, 2006                  [Page 4]

Internet-Draft          Requirements for P2P SIP            October 2005


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   Terminology defined in RFC 3261 [2] is used without definition.

   Distributed Hash Table (DHT): A mechanism in which resources are
   given a unique key produced by hashing some attribute of the
   resource, locating them in a hash space (see below).  Nodes located
   in this hash space also have a unique id within the hash space.
   Nodes store information about resources with keys that are
   numerically similar to the node's ID in the hash space.

   Node or a Peer: Software running on a user machine that allows
   sharing the machine's resources such as CPU cycles and bandwidth to
   perform functions typically carried out by a centralized server for
   its clients.  In most simple terms, a peer is both a client and a
   server.

   Overlay or Overlay Network: This document refers to the virtual
   network created by the interconnection between the nodes
   participating in the P2P SIP network as the "overlay network", in
   keeping with the terminology used in the P2P community.

   Peer-to-Peer Service Provider: The organization that provides
   services required to run a P2P network, for example, providing a
   centralized authentication service, a centralized bootstrap service
   or a centralized resource location service.





















Baset, et al.              Expires May 1, 2006                  [Page 5]

Internet-Draft          Requirements for P2P SIP            October 2005


3.  Functional Scope

   P2P SIP SHOULD be able to support all or most of the applications and
   services supported by the traditional SIP.  The most important and
   basic functionality of P2P SIP should be the support of real-time
   communications such as basic voice services and video conferencing.
   Additionally, P2P SIP should be flexible to accommodate non-real-time
   communications like asynchronous messaging and presence.











































Baset, et al.              Expires May 1, 2006                  [Page 6]

Internet-Draft          Requirements for P2P SIP            October 2005


4.  High-level Requirements

4.1.  Resources for Distribution

   Location service, NAT and firewall traversal servers, voicemail,
   address book, and configuration storage are examples of centralized
   resources in a conventional VoIP deployment.  A peer-to-peer system
   SHOULD allow a generic mechanism for distributing these centralized
   resources to the peers.

4.2.  Protocol Reuse

   Existing protocols such as SSL, TLS, and SIP SHOULD be reused as much
   as possible such that their usage does not introduce a significant
   overhead.

4.3.  DHT Changeability

   The protocol(s) for maintaining the peer-to-peer network SHOULD be
   flexible to accommodate different DHT algorithms.

   Motivation: There are many different algorithms for maintaining a DHT
   such as Chord [7], CAN [8], and Pastry [9].  The research in DHT is
   on going and it is possible that these algorithms can be improved or
   new algorithms can be devised.  Also, it cannot be assumed that one
   DHT algorithm will fit for all deployments of various scale.  Thus,
   the protocol should be flexible to accommodate various DHT
   algorithms.

4.4.  Small Overhead

   The overhead of the protocol SHOULD be minimal so that it can support
   low capability devices.

   Motivation: The protocol is envisioned to be run on low capability
   mobile devices such as WiFi phones and wireless enabled cameras as
   well as more resourceful devices.  A protocol which has a large
   overhead for P2P network maintenance can devour the device resources,
   the most critical being the battery.

   A better P2P algorithm might need fewer resources, so the ability of
   a system to change the P2P algorithm actually helps low capability
   devices.

4.5.  NAT and Firewall Traversal

   R1.  The peer-to-peer system SHOULD distribute the functionality of
   NAT and firewall traversal servers to the end-points.



Baset, et al.              Expires May 1, 2006                  [Page 7]

Internet-Draft          Requirements for P2P SIP            October 2005


   Motivation: This is one of the main reasons for designing a peer-to-
   peer IP telephony protocol.  According to September 2005 press
   release from Nielsen NetRatings [15], 60% of the US home Internet
   users are using broadband.  Many of these users are likely to use
   some sort of NAT to setup a home network.  An IP telephony system
   supporting these kind of users must provide NAT and firewall
   traversal servers and allocate sufficient bandwidth for them.  A P2P
   IP telephony system can save on the cost of maintaining these servers
   and corresponding bandwidth by distributing the functionality of
   these servers to the end-points.

   R2.  A peer with NAT and firewall traversal capabilities SHOULD be
   selected such that it does not introduce significant delay between
   the communicating peers.

   Motivation: A peer in Australia should not act as a NAT traversal
   server for two communicating voice peers in New York.

4.6.  Voice Transport

   The peers SHOULD support sending and receiving voice packets over TCP
   in addition to UDP.

   Motivation: The typical NAT configurations maintain the binding of a
   TCP connection for its lifetime.  Thus, packets sent over TCP
   'seamlessly' traverse through NATs.  The peers acting as NAT and
   firewall traversal servers should be able to relay voice packets over
   TCP between caller and callee.

4.7.  Deployment Scale

   The P2P system will be deployed in small offices and home networks
   (SOHO), emergency and ad-hoc situations, and globally over the
   Internet.  The protocols SHOULD be flexible to cater for the varying
   scale requirements of these networks.
















Baset, et al.              Expires May 1, 2006                  [Page 8]

Internet-Draft          Requirements for P2P SIP            October 2005


5.  Architectural Requirements

5.1.  Scalability

   The protocol SHOULD achieve an Internet wide scale.

   Motivation: It is envisioned that a global VoIP overlay will be
   deployed which will contain hundreds of thousands of nodes.  The
   protocol(s) should be scalable to support such a deployment.

5.2.  Reliability

   The system MUST continue to function as peers arrive, depart, and
   fail.  No assumptions should be made regarding peer uptime or their
   capabilities.

   Motivation: The peers will run on machines of end-users and it is
   quite difficult to predict the reliability of those machines.  The
   system should allow reallocating the resources of a graceful or
   ungraceful departing peer to existing peers in a seamless way.  Time
   interval for detection of failed peers should be adjustable based on
   scale and other system requirements.

5.3.  Namespace

   The system SHOULD allow centralized and non-centralized naming
   authorities.  In the absence of any naming authority, the system MUST
   be able to determine if two users pick up the same name and SHOULD be
   able to decide which of them should be allowed to use the name.  The
   system SHOULD support both SIP and non-SIP naming (addressing)
   schemes.

   Motivation: A global overlay network will probably require a central
   naming authority to maintain a unique namespace.  A home network may
   not need any central authority due to small number of devices.

5.4.  Services/Resource Lookup

5.4.1.  Centralized Lookup

   Value-added services such as reliable voicemail storage can be
   provided by a central authority in a P2P network.  The system SHOULD
   allow the peers to efficiently locate the centralized service
   providers or resources.

5.4.2.  Distributed Lookup

   The peers should be able to perform distributed resource and service



Baset, et al.              Expires May 1, 2006                  [Page 9]

Internet-Draft          Requirements for P2P SIP            October 2005


   lookup in an efficient manner.  The number of peers to be contacted
   SHOULD be minimal in such a lookup.

5.5.  Interconnect with P2P, non-P2P and PSTN networks

   The P2P system SHOULD be able to interconnect with other P2P or non-
   P2P systems and PSTN networks.  To provide this interconnection, the
   P2P system should be able to discover these networks in a centralized
   or in a distributed away.










































Baset, et al.              Expires May 1, 2006                 [Page 10]

Internet-Draft          Requirements for P2P SIP            October 2005


6.  Protocol Specification Requirements

6.1.  Support for different DHTs

   Any protocol specification SHOULD be able to incorporate different
   DHT algorithms based on the P2P service provider requirements.

6.2.  Addressing for Heterogeneous Resources

   It is envisioned that more than one type of resources will be
   distributed in the overlay network.  Location service and NAT and
   firewall traversal servers are examples of two such resources.  The
   protocol specification SHOULD have a flexible addressing scheme to
   support distinct distributed resources and SHOULD allow new
   distributed resources to be incorporated in an existing network.




































Baset, et al.              Expires May 1, 2006                 [Page 11]

Internet-Draft          Requirements for P2P SIP            October 2005


7.  Usage Scenarios

   Below, some deployment scenarios for the P2P VoIP system are
   described.

7.1.  Global Telephony Overlay

   A global P2P telephony VoIP system which allows its users located in
   different regions and countries to communicate with each other.

7.2.  Emergency, Ad-hoc

   In emergency situations, communication links can break down, and many
   of the servers such as DNS may not be reachable.  An overlay
   communication network can be established in that situation.  Clearly,
   the assumption is that some sort of underlying network infrastructure
   available.

7.3.  Office Environments, P2P-IP-PBX

   A small office or an environment with a heterogeneous network
   infrastructure are good candidates for P2P overlay network.  Small
   offices may not want to be bothered with maintaining yet another
   server.  Server-less P2P systems can help achieve this goal.



























Baset, et al.              Expires May 1, 2006                 [Page 12]

Internet-Draft          Requirements for P2P SIP            October 2005


8.  Security Considerations

8.1.  Identity

   A global overlay network will probably have more stringent
   requirements for identity management and protection than a home based
   network.  The system should allow identities to be verified in a
   reasonable way.  Central naming and certificate authorities can
   provide protection against identity theft.

   Lack of central authority in a large overlay implies that the system
   is susceptible to Sybil Attack [10].

8.2.  Signaling and Media Anonymization

   Since a peer can route signaling messages between peers and can act
   as a NAT or a firewall traversal server for the communicating
   parties, it is imperative that the communication is encrypted.  A
   peer acting as a router or a NAT or a firewall traversal server
   should not be able to listen to the communication.  It is recommended
   that the system should also support IP address and port anonymization
   to the extent it does not significantly delay the real-time media
   stream.

8.3.  Misbehaving Peers

   The system must not assume that all peers will behave correctly.  The
   system must recognize the existence of leachers and free-loaders, and
   must provide a mechanism to detect and penalize them.

   Motivation: Users do not like arbitrary traffic to flow across their
   machines.  Even if the user has agreed with the terms of service of
   the P2P software, he or she may take active steps to block overlay
   traffic.  Misbehaved peers can choose to discard the routing requests
   or route them incorrectly.  Any such action by legitimate or
   illegitimate users can hamper the operation of the P2P network.  The
   protocols must be designed with this perspective.

9.  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Petersen, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [3]   Bryan, D. and C. Jennings, "A P2P Approach to SIP Registration



Baset, et al.              Expires May 1, 2006                 [Page 13]

Internet-Draft          Requirements for P2P SIP            October 2005


         and Resource Location", draft-bryan-sipping-p2p-01 (work in
         progress), July 2005.

   [4]   Singh, K. and H. Schulzrinne, "Peer-to-peer Internet Telephony
         using SIP", Proceedings of the 2005 Network and Operating
         Systems Support for Digital Audio and Video Workshop (NOSSDAV)
         '05 , June 2005.

   [5]   Johnston, A., "SIP, P2P, and Internet Communications",
         draft-johnston-sipping-p2p-ipcom-01 (work in progress),
         March 2005.

   [6]   Matthews, P. and B. Poustchi, "Industrial-Strength P2P SIP",
         draft-matthews-sipping-p2p-industrial-strength-00 (work in
         progress), February 2005.

   [7]   Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek,
         M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-
         peer Lookup Service for Internet Applications", IEEE/ACM
         Transactions on Networking (To Appear).

   [8]   Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S.
         Shenker, "A scalable content-addressable network", Proc. ACM
         SIGCOMM (San Diego, CA), pp. 161-172, August 2001.

   [9]   Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed
         object location and routing for large-scale peer-to-peer
         systems", Proceedings of the 18th IFIP/ACM International
         Conference on Distributed Systems Platforms (Middleware 2001),
         March 2002.

   [10]  Docuer, J., "The Sybil Attack", IPTPS '02 , March 2002.

   [11]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [12]  Rosenberg, J., Mahy, R., and C. Huitema, "TURN - Traversal
         Using Relay NAT", draft-rosenberg-midcom-turn-08 (work in
         progress), September 2005.

   [13]  "Skype. P2P Internet Telephony Application",
         <http://www.skype.com>.

   [14]  "Nimcat Networks. P2P Solutions for Enterprise Telephony",
         <http://www.nimcatnetworks.com>.

   [15]  "Nielsen Ratings Press Release", September 28 2005,



Baset, et al.              Expires May 1, 2006                 [Page 14]

Internet-Draft          Requirements for P2P SIP            October 2005


         <http://www.nielsen-netratings.com/pr/pr_050928.pdf>.


















































Baset, et al.              Expires May 1, 2006                 [Page 15]

Internet-Draft          Requirements for P2P SIP            October 2005


Authors' Addresses

   Salman A. Baset
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027
   USA

   Email: salman@cs.columbia.edu


   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY  10027
   USA

   Email: hgs@cs.columbia.edu


   Eunsoo Shim
   Panasonic Digital Networking Laboratory
   Two Research Way, 3rd Floor
   Princeton, NJ  08540
   USA

   Email: eunsoo@research.panasonic.com


   Krishna Kishore Dhara
   Avaya Labs Research
   307 Middletown Lincroft Road
   Lincroft, NJ  07738-1526

   Email: dhara@avaya.com














Baset, et al.              Expires May 1, 2006                 [Page 16]

Internet-Draft          Requirements for P2P SIP            October 2005


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.


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.




Baset, et al.              Expires May 1, 2006                 [Page 17]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/