Internet DRAFT - draft-baset-sipping-p2preq
draft-baset-sipping-p2preq
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]
