| TOC |
|
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 © The Internet Society (2005).
This document defines requirements for designing peer-to-peer voice, text, and real-time multimedia communication system protocols.
1.
Introduction
2.
Terminology
3.
Functional Scope
4.
High-level Requirements
4.1.
Resources for Distribution
4.2.
Protocol Reuse
4.3.
DHT Changeability
4.4.
Small Overhead
4.5.
NAT and Firewall Traversal
4.6.
Voice Transport
4.7.
Deployment Scale
5.
Architectural Requirements
5.1.
Scalability
5.2.
Reliability
5.3.
Namespace
5.4.
Services/Resource Lookup
5.4.1.
Centralized Lookup
5.4.2.
Distributed Lookup
5.5.
Interconnect with P2P, non-P2P and PSTN networks
6.
Protocol Specification Requirements
6.1.
Support for different DHTs
6.2.
Addressing for Heterogeneous Resources
7.
Usage Scenarios
7.1.
Global Telephony Overlay
7.2.
Emergency, Ad-hoc
7.3.
Office Environments, P2P-IP-PBX
8.
Security Considerations
8.1.
Identity
8.2.
Signaling and Media Anonymization
8.3.
Misbehaving Peers
9.
References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Petersen, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) based VoIP systems employ SIP registrars, SIP proxy servers, and STUN [11] (Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” March 2003.) and TURN [12] (Rosenberg, J., Mahy, R., and C. Huitema, “TURN – Traversal Using Relay NAT,” September 2005.) 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] (, “Skype. P2P Internet Telephony Application,” .) and Nimcat [14] (, “Nimcat Networks. P2P Solutions for Enterprise Telephony,” .) 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] (Bryan, D. and C. Jennings, “A P2P Approach to SIP Registration and Resource Location,” July 2005.) and Singh [4] (Singh, K. and H. Schulzrinne, “Peer-to-peer Internet Telephony using SIP,” June 2005.) 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] (Matthews, P. and B. Poustchi, “Industrial-Strength P2P SIP,” February 2005.). A distributed location service for SIP was proposed by Johnston [5] (Johnston, A., “SIP, P2P, and Internet Communications,” March 2005.). With various design options and open issues, identifying requirements for P2P SIP will facilitate making design choices. This document defines a set of requirements for P2P-SIP.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
Terminology defined in RFC 3261 [2] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Petersen, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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.
| TOC |
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.
| TOC |
| TOC |
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.
| TOC |
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.
| TOC |
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] (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,” .), CAN [8] (Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, “A scalable content-addressable network,” August 2001.), and Pastry [9] (Rowstron, A. and P. Druschel, “Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems,” March 2002.). 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.
| TOC |
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.
| TOC |
R1. The peer-to-peer system SHOULD distribute the functionality of NAT and firewall traversal servers to the end-points.
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] (, “Nielsen Ratings Press Release,” September 28 2005.), 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.
| TOC |
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.
| TOC |
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.
| TOC |
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
| TOC |
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.
| TOC |
The peers should be able to perform distributed resource and service lookup in an efficient manner. The number of peers to be contacted SHOULD be minimal in such a lookup.
| TOC |
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.
| TOC |
| TOC |
Any protocol specification SHOULD be able to incorporate different DHT algorithms based on the P2P service provider requirements.
| TOC |
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.
| TOC |
Below, some deployment scenarios for the P2P VoIP system are described.
| TOC |
A global P2P telephony VoIP system which allows its users located in different regions and countries to communicate with each other.
| TOC |
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.
| TOC |
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.
| TOC |
| TOC |
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] (Docuer, J., “The Sybil Attack,” March 2002.).
| TOC |
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.
| TOC |
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.
| TOC |
| [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 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.” |
| [14] | “Nimcat Networks. P2P Solutions for Enterprise Telephony.” |
| [15] | “Nielsen Ratings Press Release,” September 28 2005. |
| TOC |
| 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 |
| TOC |
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.
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 © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.