One document matched: draft-jiang-p2psip-peer-protocol-requirement-01.txt
Differences from 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-01.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).
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.
Jiang Expires August 5, 2007 [Page 1]
Internet-Draft P2PSIP February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background of SIP and P2P . . . . . . . . . . . . . . . . . . 3
4. C/S SIP and P2P SIP . . . . . . . . . . . . . . . . . . . . . 4
4.1. Motivation from C/S SIP to P2P SIP . . . . . . . . . . . . 4
4.2. Peers' characteristics in P2PSIP case . . . . . . . . . . 5
4.3. Comparison between C/S SIP and P2PSIP . . . . . . . . . . 5
5. Problem statement . . . . . . . . . . . . . . . . . . . . . . 6
5.1. A example P2PSIP overlay . . . . . . . . . . . . . . . . . 6
5.2. Problem 1: NAT traversal . . . . . . . . . . . . . . . . . 6
5.3. Problem 2: Lost Information . . . . . . . . . . . . . . . 7
5.4. Problem 3: Low routing efficiency . . . . . . . . . . . . 7
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Basic requirements for Peer protocol . . . . . . . . . . . 8
6.1.1. Transport requirement . . . . . . . . . . . . . . . . 8
6.1.2. API requirement . . . . . . . . . . . . . . . . . . . 8
6.1.3. Service requirement on peer's functionality . . . . . 8
6.1.4. DHT requirement . . . . . . . . . . . . . . . . . . . 9
6.1.5. NAT traversal requirement . . . . . . . . . . . . . . 9
6.2. Availability . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Efficiency . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security requirements . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . . 11
11. Informative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 Client/Server(C/S) SIP servers,
peers in P2PSIP are of different 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 poorly. 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.
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].
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 and VoIP, etc. The systems
Jiang Expires August 5, 2007 [Page 3]
Internet-Draft P2PSIP February 2007
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.
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.
P2PSIP 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 P2PSIP case, central servers
are not needed and new peer only need a bootstrap node to join
the overlay.
Jiang Expires August 5, 2007 [Page 4]
Internet-Draft P2PSIP February 2007
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 P2PSIP 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
gracefully 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
delay at least some of the requests and even drop the excess.
4.3. Comparison between C/S SIP and P2PSIP
We will compare C/S SIP and P2PSIP 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 P2PSIP 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 P2PSIP, 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 P2PSIP 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 P2PSIP, lookup operation will trigger messages
routed through the overlay, hence introducing a significant
Jiang Expires August 5, 2007 [Page 5]
Internet-Draft P2PSIP February 2007
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.
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
Jiang Expires August 5, 2007 [Page 6]
Internet-Draft P2PSIP February 2007
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
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 routing 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.
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.
Jiang Expires August 5, 2007 [Page 7]
Internet-Draft P2PSIP February 2007
6.1. Basic requirements for Peer protocol
6.1.1. Transport requirement
Most of the P2PSIP peer protocol messages will be delivered through
the overlay hop-by-hop, so any lost message in transit MAY fail the
corresponding transaction, for example, GET operation MAY fail
because of resource limit on any intermediate peer which discards the
message. On the other hand, operations in DHT algorithms often
trigger a great number of messages. 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.
So there are some transport requirments for peer protocol:
1. Peer protocol SHOULD deliver peer protcol messages reliably. It
could use the reliable transport service directly, such as TCP.
If it would use datagram tranport service, the messages should be
kept in a appropriate size so that it would not be fragmented in
transit.
2. Peer protocol SHOULD be efficient enough to keep the ratio of net
payload to message size as high as possible.
6.1.2. API requirement
P2PSIP overlay intends to provide distributed database service for
upper layer applications. For example, it provides distributed
location service for SIP protocol which is used to established
interactive communication.
Peer protocol not only realizes the maintenance work of overlay
topology, but also provides data service for upper layer applications
to store and retrieve information in/from the overlay. The work to
maintain overlay topology is to keep routing states in every peer
consistent with the topology as peers join or leave the overlay.
So 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.
6.1.3. Service requirement on peer's functionality
Peers work together to provide service to upper layer applications,
so they should serve each other to achieve this goal. DHT algorithms
Jiang Expires August 5, 2007 [Page 8]
Internet-Draft P2PSIP February 2007
require that each peer MUST provide routing service and storage
service for other peers. In order to make full use of processing
power, including CPU cycles, bandwidth, distributed through the peers
in the overlay, some special cases MAY impose new service
requirements on peers. For example, in order to traverse NAT between
peers in the overlay, some peers are equipped with STUN service or
TURN relay service. New services MAY emerge in the future.
1. Peer protocol MUST provide routing service and storage service in
the overlay.
2. In some special cases, some peers SHOULD be equipped with STUN
service or TURN relay service.
6.1.4. DHT requirement
There are various DHT algorithms in use, including Chord, CAN,
Pastry, Bamboo, etc. P2PSIP peer protocol SHOULD make the peer
protocol be extensible enough to accommodate differences between
various DHT algorithms, including some new DHT algorithms that may
appear in the future.
6.1.5. NAT traversal requirement
NATs MAY prevent communications between nodes, either peers or
clients. P2PSIP community has agreed roughly that STUN/TURN/ICE will
be used with P2PSIP peer protocol to address NAT traversal issue. So
cooperation with STUN/TURN/ICE may impose new requirments on the peer
protcol.
Before connectivity checks in ICE, agents must exchange their
candidate addresses in SDP messages. When used in SIP, SIP servers
play a rendezvous point to exchange related information. Likely,
there MUST be a mechanism for peers to exchange their candidate
addresses, either in a rendezvous or distributed way, in P2PSIP case.
Peers in the overlay will need STUN/TURN servers to help them
traverse NAT. Because of a large portion of peers being behind NAT,
NAT traversal imposes heavy demands on the processing power of STUN/
TURN servers. In order to make full use of processing power
distributed through the overlay, peers with public address and being
equipped with STUN/TURN functionalities SHOULD take the
responsibility to help peers behind NAT. So peer protocol should
provide a mechanism for peers behind NAT to find peers who could
provide STUN/TURN service.
So there are some requirements from NAT traversal issues:
Jiang Expires August 5, 2007 [Page 9]
Internet-Draft P2PSIP February 2007
1. Peer protocol MUST provide a mechanism for peers to exchange
their candidate addresses, either in a rendezvous or distributed
way.
2. Peer protocol SHOULD provide a mechanism for peers behind NAT to
find peers who could provide STUN/TURN service.
6.2. Availability
Through the comparison between C/S SIP and P2PSIP, we come to a
conclusion that availability must be addressed in Peer protocol.
Various specific methods may be used. After examining some existing
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.
7. Security requirements
There have been a few contributions [9][10][11] which identify
Jiang Expires August 5, 2007 [Page 10]
Internet-Draft P2PSIP February 2007
security issues in P2PSIP case and summarize security requirements
for P2PSIP case. So in this proposal, security requirements will not
be discussed. We hope our contributions could merge with these
security requirements to present an integral requirement document for
P2PSIP peer protocol.
8. IANA Considerations
This document presently raises no IANA considerations.
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, Philip Matthews, Salman A.
Baset, who reviewed an early version of this draft and provided
valuable comments.
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.
11. Informative References
[3] Shim, E., "An Architecture for Peer-to-Peer Session Initiation
Protocol (P2PSIP)", 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.
Jiang Expires August 5, 2007 [Page 11]
Internet-Draft P2PSIP February 2007
[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.
[9] B. Lowekamp, J. Deverick, "Authenticated Identity Extensions to
dSIP", Internet Draft draft-lowekamp-p2psip-dsip-security-00,
February 25, 2007
[10] M. Matuszewski, J-E. Ekberg, P. Laitinen "Security requirements
in P2PSIP" Internet Draft
draft-matuszewski-p2psip-security-requirements-00 February 26, 2007
[11] C. Jennings "Security Mechanisms for Peer to Peer SIP" Internet
Draft draft-jennings-p2psip-security-00 February 24, 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 12]
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 13]
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:43 |