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]