One document matched: draft-jiang-p2psip-peer-protocol-requirement-00.txt
P2PSIP XingFeng. Jiang
Internet-Draft Huawei Tech.
Intended status: Standards Track February 1, 2007
Expires: August 5, 2007
The requirement of P2PSIP Peer protocol
draft-jiang-p2psip-peer-protocol-requirement-00.txt
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 August 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Jiang Expires August 5, 2007 [Page 1]
Internet-Draft P2PSIP February 2007
Abstract
In this draft, we present what P2PSIP should achieve - a distributed
location service. Then we compare the differences between C/S SIP
and P2P SIP and point out that some features which are not
standardized in C/S SIP should be addressed in the P2P SIP case.
After analyzing some problems, some requirements of Peer protocol are
proposed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background of SIP and P2P . . . . . . . . . . . . . . . . . . 5
4. C/S SIP and P2P SIP . . . . . . . . . . . . . . . . . . . . . 6
5. Problem statement . . . . . . . . . . . . . . . . . . . . . . 8
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Jiang Expires August 5, 2007 [Page 2]
Internet-Draft P2PSIP February 2007
1. Introduction
P2P SIP uses P2P technology to build robust, distriubted location
service for SIP entities. Other than C/S SIP servers, peers in P2P
SIP are of differenct characteristics. Peers are unstable, transient
and unmanaged. So the design of Peer protocol should consider these
factors and come out with Peer protocol which could work well with so
highly autonomous Peers.
Availability and efficiency are often ignored in C/S SIP, because SIP
servers are assumed to be powerful enough to process requests. In
order to improve availability and efficiency, backup mechanisms are
often used in real implementations. But in P2P SIP case, these two
features must not be ignored, otherwise the P2P SIP system would not
work or work badly. In this draft, we will compare C/S SIP and P2P
SIP and come to a conclusion that two features must be realized in
P2P SIP case.
The draft is organized as follows. In section 3, some background
information is presented. The comparison between C/S SIP and P2P SIP
is discussed in section 4. Section 5 states some problems inherent
in P2P SIP case. Basic requirements and some advanced requirements
are proposed in Section 6.
Jiang Expires August 5, 2007 [Page 3]
Internet-Draft P2PSIP February 2007
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 .
As for terminology about P2P SIP, we use the terminology defined in
[2].
Jiang Expires August 5, 2007 [Page 4]
Internet-Draft P2PSIP February 2007
3. Background of SIP and P2P
SIP is a protocol to negotiate session parameters and establish the
multimedia communication among participants of the session.
Participants must locate other participants before they can establish
communication. Other than a few control functions, the main task of
Proxy servers or Redirect servers is to look up correspondent's
location in the location database which is populated by the messages
sent from SIP User Agent to SIP Registrar.
P2P technology has been widely used on the Internet in various
applications, including file sharing, VoIP, etc. The systems built
on P2P technology have some attractive features. These systems could
make full use of the resources in all participants so that it does
not rely on central servers. An analysis in [4] has proposed that a
P2P protocol should be standardized in the IETF as a protocol used
between a Registrar/Proxy/Redirect server and a Location Service.
After introducing P2P technology, SIP becomes a true P2P protocol and
no longer needs Proxy/Redirect/Registrar for operation.
Nodes participating in P2PSIP Overlay are classfied into two types:
Peers and Clients. Clients only put and get resource from the
overlay which are made up of Peers. Peers work collectively to
maintain the overlay topology, route messages through the overlay and
store data on behalf of overlay. Peers also perform put and get
operations like what Clients do. In general, the functions of
Clients are a logical subset of Peer's functions.
P2PSIP Peer protocol is spoken between P2PSIP Overlay peers to share
information and organize the P2PSIP Overlay Network. The goal of
P2PSIP WG is to standardize the application of existing P2P
technology to provide robust, distributed location service. Unlike
servers in Client-Server architecture, Peers are unstable, transient,
unmanaged. So designing a Peer protocol that could work well with
such highly autonomous Peers is a challenging task of P2PSIP WG.
Jiang Expires August 5, 2007 [Page 5]
Internet-Draft P2PSIP February 2007
4. C/S SIP and P2P SIP
4.1 Motivation from C/S SIP to P2P SIP
Conventional SIP takes Client-server architecture and has a
centralized location database to store the association between AOR
and its possible contact locations. The location database is
maintained by Registrar which receives REGISTER messages from SIP
UAs. Proxy servers or Redirect servers can look up in the location
database to get the callee's location.
P2P SIP intends to provide the similar location service to SIP
entities, including SIP UA, Proxy server, Redirect server. The
resulting distributed location service will be provided by all the
Peers in the overlay. P2P SIP has some advantages over C/S SIP:
1. No centralized servers: There is no necessary to deploy several
central servers in the system in that Peers in the overlay could
cooperate to get the user's location.
2. Ease of configuration. C/S SIP system needs to do lots of work
to configure central servers, but in P2P SIP case, central
servers are not needed and new peer only need a bootstrap node to
join the overlay.
3. Scalability. when a new Peer joins the overlay, it brings extra
computing and storage resource into the overall system.
4.2 Peers' characteristics in P2P SIP case
P2PSIP Peers have different characteristics than C/S SIP servers.
These characteristics will greatly influence the design of Peer
protocol.
o Transient: Peers join the overlay if they want to communicate with
other members of the overlay. They may leave the overlay at any
time for a variety of reasons. So the time Peers stay in the
overlay is transient because of their frequent join and leave
operations.
o More frequent failure: a Peer often runs on a PC. Its stability
is much lower than that of a server. It is easily subject to
failure without notifying others in overlay. If that happens,
overlay topology is not correct, and must be repaired.
o Limited processing power: The computer which a Peer resides on may
have limited processing power. If one Peer receives more requests
than it can queue and process during a given time period, it will
Jiang Expires August 5, 2007 [Page 6]
Internet-Draft P2PSIP February 2007
delay at least some of the requests and even drop the excess.
o autonomous: The system administrators may not control the Peers as
they control servers. Peers may be highly autonomous and they may
even do something that administrators and other users don't want
them to do. For example, malicious Peers may rewrite the message,
forward message to wrong destination, etc.
4.3 Comparison between C/S SIP and P2P SIP
We will compare C/S SIP and P2P SIP in terms of location service in
the following three perspectives:
o Information distribution: In C/S SIP, location information is
stored on a centralized server for each SIP domain. But the
information is distributed among all Peers in the P2P SIP case.
o Availability: Availability is an important feature of practical
systems. Location service in C/S SIP is not available if the
central server storing the key information does not work. In
order to avoid single point of failure, C/S SIP uses some backup
servers to improve the availability. In P2P SIP, every peer
stores a small part of location information. If some peers fail,
the system only lost a few pieces of information which are stored
on these peers, hence the system has not lost all availability.
The problem in P2P SIP is that in naive P2P implementations there
is only one copy of each user's location information. If Peers
fail, the unique copy will be lost. So the Peer protocol should
be specified in a way that supports the availability of the
distributed location service.
o Efficiency: In C/S SIP, the lookup operation is executed in a
centralized server. So, the efficiency could be ignored in this
case. But in P2P SIP, lookup operation will trigger messages
routed through the overlay, hence introducing a significant
latency. Although all DHT algorithms ensure that the lookup
operation succeeds within Log(N) steps, improving lookup
efficiency makes sense. The distributed location service is used
to support interactive communications which have rigid
requirements for call establishment time. So the Peer protocol
shoud be specified in a way that allows improved efficiency.
Jiang Expires August 5, 2007 [Page 7]
Internet-Draft P2PSIP February 2007
5. Problem statement
In this section, we will present some problems inherent in P2P
overlay. Some assumptions are made before discussing these problems:
o Bootstrap node is assumed to be known by a Peer before the Peer
joins the overlay. The method for Peers to get bootstrap node are
static locations, cached peers, broadcast mechanism, etc.
o How to get credential of a Peer is not within the scope of Peer
protocol, but the format of credential should be standardized in
P2PSIP to improve security.
5.1 A example P2PSIP overlay
+ - - - -+ N + - - - -+
+ Peer A + - - - A- - - - - - -+ Peer B +
+ - - - -+ T + - - - -+
| N |
| A |
N A T N A T N A T N A T |
| |
| |
| |
+ - - - -+ + - - - -+
+ Peer C + - - - - - - - - - -+ Peer D +
+ - - - -+ + - - - -+
Figure 1 Peers in the overlay
In figure 1, Peer A, B, C and D construct a P2PSIP overlay. Peer A
is behind NAT. The topology is like that the above figure shows.
These four peers work together to provide a distributed location
service. Each of them stores information and routes requests in the
overlay. Basically, subsequent discussions are based on the figure.
5.2 Problem 1: NAT traversal
If Peer A wants to join the overlay, it should initiate join
operation as common DHT algorithms do. Assume that Peer D is the
bootstrap node that Peer A knows. If the message goes through the
path like D->C->B->A, then A communicate with B through the NAT. The
method to traverse NAT is more difficult, if Peer B is also behind
another NAT. Peer protocol should make use of the methods which are
proposed in BEHAVE and MMUSIC WG and provide any unique requirements
because of P2P to these working groups.
5.3 Problem 2: Lost Information
Jiang Expires August 5, 2007 [Page 8]
Internet-Draft P2PSIP February 2007
Nearly all DHT algorithms could work well even if the Peers join and
leave the overlay frequently. But if a Peer fails suddenly, the
disaster may happen for a naive implementation. For example, at the
beginning, the whole user location information is stored among all
Peers. All of a sudden, Peer B does not work and does not notify
others in overlay. It means that others in the overlay may not
notice disappearance of Peer B and Peer B has not transferred the
information stored on it to another peer somewhere in the overlay.
As a result, the information stored on Peer B is lost. So, Peer
protocol must address this problem, otherwise P2PSIP will not work,
or may work badly.
5.4 Problem 3: Low efficiency
One major function of Peers is to route messages through the overlay
and find the responsible Peer for the message. Unlike topology in
Figure 1, real P2P systems often have at least thousands of nodes.
In such a large system, latency arising from message routing through
overlay should not be ignored.
To improve the lookup efficiency, we could consider methods in two
lines of attack. One is to optimize routing efficiency and shorten
the hops of the signalling path. The other is to put the requested
information as near to the requesting peer as possible. The latter
consideration may require that the users' location information should
be cached in the overlay other than the original information. The
overlay will need some synchronization operations to keep the caches
correct. The former may require that Peers collect more topology
information to speed up lookup operation.
Jiang Expires August 5, 2007 [Page 9]
Internet-Draft P2PSIP February 2007
6. Requirements
In this section, we will summarize the requirements for Peer
protocol. The basic requirements are DHT topology related and other
requirements concern about availability, efficiency of the
distributed location service.
6.1 Basic requirement for Peer protocol
o Peer protocol should rely on a transport mechanism which could
guarantee reliable message delivery. Whichever candidate
transport protocol will be chosen, it should meet some key
requirements: 1) extensibility. The chosen transport mechanism
should be flexible so that it could accommodate various DHT
algorithms. SIP does well in terms of extensibility. 2)
efficiency. In DHT algorithms, there are a lot of messages which
are triggered by some operations. For example, Chord-based peers
periodically update their finger table. This procedure will
produce a large number of message exchanges. So the ratio of net
payload to message size should be kept as high as possible. One
message or one fragment fails may result in a failed transaction.
o Peer protocol must provide a few primitive functions which are
essential for most DHT algorithms. These primitive functions
include: join, leave, put, get, remove. The above primitive
functions could be thought of as building blocks of Peer protocol.
As Peer protocol evolves, new primitive functions will be added in
the future.
o Peer protocol should provide routing function in the overlay.
Each Peer should forward or redirect messages for the rest of the
overlay.
o Peer protocol should provide redundant storage function in the
overlay.
o Peer protocol should accommodate a few existing DHT algorithms and
at the same time, be extensible enough to support new DHT
algorithms in the future.
o Peer protocol should allow Peers to communicate with each other by
traversing NAT device.
6.2 Availability
Through the comparison between C/S SIP and P2P SIP, we come to a
conclusion that availability must be addressed in Peer protocol.
Various specific methods may be used. After examining some existing
Jiang Expires August 5, 2007 [Page 10]
Internet-Draft P2PSIP February 2007
works, such as PAST[7], CFS[6], we identified some methods for
improving availability and present them in following text.
o Neighbor detection: Peer protocol maintains dynamic topology of
overlay network and keeps adjusting topology as Peers join and
leave overlay, whether gracefully or ungracefully. If a Peer
leaves the overlay ungracefully, the rest of overlay must adjust
the topology. The availability may be lost during the time. So,
Peers who have adjacent relationship should have some methods to
detect if Peers are alive.
o Replication: In case of the unique copy's loss from failed Peers,
a feasible method to improve availability is to replicate the
unique copy and place several copies into the overlay.
Replication function could be thought of as overlay function and
information requestors are not aware of how the replication works.
In [5], David has proposed another replication method in which
information producers explicitly produce replicas and information
requestor should try different replicas until one of them is
found.
6.3 Efficiency
Because location service is used to support interactive communication
applications, Peer protocol should be designed to have high lookup
efficiency, even if the route table does not reflect the dynamic
topology accurately due to Peer's churn. In order to speed up lookup
process, some enhancements have been specified in existing DHT
systems, including PAST[7], CFS[6]. Caching is a commonly used
method. In future, other methods may be identified and proposed.
o Peer protocol should have a cache mechanism to shorten the hops
traversed from requesting Peer to the destination and speed up
lookup operation.
Jiang Expires August 5, 2007 [Page 11]
Internet-Draft P2PSIP February 2007
7. Security Considerations
7.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 .
7.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.
7.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.
Jiang Expires August 5, 2007 [Page 12]
Internet-Draft P2PSIP February 2007
8. IANA Considerations
This document presently raises no IANA considerations.
Jiang Expires August 5, 2007 [Page 13]
Internet-Draft P2PSIP February 2007
9. Acknowledgements
This document draws from contributions from many participants on the
P2PSIP mailing list.
Special mention goes to Salman A. Baset, Henning Schulzrinne, Eunsoo
Shim and Krishna Kishore Dhara, who worked on P2PSIP requirements
early in the BOF process. Some text from "Requirements for SIP-based
Peer-to-Peer Internet Telephony" (draft-baset-sipping-p2preq-00) is
reused in this draft.
Authors are grateful to Spencer Dawkins, who reviewed an early
version of this draft and provided valuable comments.
Jiang Expires August 5, 2007 [Page 14]
Internet-Draft P2PSIP February 2007
10. Normative 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] Willis, D., D. Bryan, P. Matthews, E. Shim, "Concepts and
Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-03
(work in progress), October 2006.
Jiang Expires August 5, 2007 [Page 15]
Internet-Draft P2PSIP February 2007
11. Informative References
[3] Shim, E., "An Architecture for Peer-to-Peer Session Initiation
Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in
progress), March 2006.
[4] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet
Communications", draft-johnston-sipping-p2p-ipcom-02 (work in
progress), March 2006.
[5] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer-to-Peer
Session Initiation Protocol (P2PSIP)", Internet Draft
draft-bryan-sipping-p2p-usecases-00, November 2005.
[6] Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion
Stoica "Wide-area cooperative storage with CFS" ACM, October 2001
[7] Antony Rowstron, Peter Druschel, "Storage management and caching
in PAST, a large-scale,persistent peer-to-peer storage utility" ACM,
November 2001.
[8] Baset, S., Schulzrinne, H., Shim, E., and K. Dhara, "Requirements
for SIP-based Peer-to-Peer Internet Telephony", Internet Draft
draft-baset-sipping-p2preq-00, October 2005.
Jiang Expires August 5, 2007 [Page 16]
Internet-Draft P2PSIP February 2007
Author's Address
XingFeng Jiang
Huawei Tech.
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 210001
P.R.China
Phone: +86(25)84565462
Email: jiang.x.f@huawei.com
Jiang Expires August 5, 2007 [Page 17]
Internet-Draft P2PSIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jiang Expires August 5, 2007 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 23:03:36 |