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]