P2PSIP Working Group L Ch. Li Internet-Draft Y. Wang Intended status: Informational BUPT Expires: May 25, 2008 November 22, 2007 Different types of nodes in P2PSIP draft-li-p2psip-node-types-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document is an attempt to classify different types of node in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible types of nodes in P2PSIP are discussed based on two characters: whether it offers overlay-routing services and whether it offers storage functions. The behaviors of each type of nodes and their possible necessities are analyzed. This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", etc. Li & Wang Expires May 25, 2008 [Page 1] Internet-Draft P2PSIP Node Types November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Types of Nodes . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Possible types of nodes . . . . . . . . . . . . . . . . . 3 2.2. Naming of different types . . . . . . . . . . . . . . . . 4 3. Type B Node . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Type C Node . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Type D Node (Client) . . . . . . . . . . . . . . . . . . . . . 6 5.1. P2P Client . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Non-P2P Client . . . . . . . . . . . . . . . . . . . . . . 7 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Li & Wang Expires May 25, 2008 [Page 2] Internet-Draft P2PSIP Node Types November 2007 1. Introduction In IETF P2PSIP WG, the discussion on the term "client" and its possible behavior has lasted for a long time. But there is still no consensus on the roles and behaviors of non-peer nodes until now. To clarify these concepts, based on two fundamental services provided by P2P overlay, which are overlay-routing and storage, we try to classify different node types within P2PSIP. For each type of nodes, their role and behavior are described firstly; then the necessity of such node is explored. Because not all the node types are necessary, for the node types that can be merged into other types, our arguments are presented. This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP WG, such as "client", "low-function peer", etc. It is hoped that this document could help the WG to reach a rough consensus on the types of node within P2PSIP system and the characters of each type's behavior. Many points and arguments in this document originate from the discussions in the P2PSIP maillist and related Internet-Drafts. The authors of this document appreciate the contributions that are made by the people who joined in the related discussions. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Types of Nodes 2.1. Possible types of nodes According to [I-D.ietf-p2psip-concepts], P2PSIP overlay provides distributed database function and distributed transport function for SIP and other applications. In P2PSIP overlay, peers offer storage and transport services to allow the distributed database function and distributed transport function to be implemented. Other types of nodes MAY exist in P2PSIP. Based on the functionalities provided by P2P overlay, say capability of storage and transport services, nodes in P2PSIP can be divided into four types as follow: Li & Wang Expires May 25, 2008 [Page 3] Internet-Draft P2PSIP Node Types November 2007 o Type A Nodes: nodes offering storage and transport services. o Type B Nodes: nodes offering transport services but NOT offering storage services. o Type C Nodes: nodes offering storage services but NOT offering transport services. o Type D Nodes: nodes NEITHER offering storage NOR offering transport services, only using these services. In all these types, Type A nodes have been accepted as "P2PSIP peer" or "peer" by the P2PSIP WG. Thus, in the following sections, we will mainly focus on the other three types of nodes. 2.2. Naming of different types Given that the terms such as "client", "low-function peer" are too ambiguous, in this subsection the naming of each type of node are clarified. In the client/server computing model, "client" refers to nodes only using services. In the peer-to-peer computing model, "peer" refers to the nodes both using services and providing services. Thus, type A node can be named as "peer", which has been accepted by the P2PSIP WG. Also type D node can be named "client". For type B and type C nodes, they will be assigned a suitable name based on the analysis of their main characters. 3. Type B Node Type B nodes refer to the nodes which offer transport functionality but do not contribute their storage capacity. In the current version of [I-D.ietf-p2psip-concepts], such type of nodes is referred as "peers with bad memory". Some want to call this type of nodes as "clients", and others view this type of nodes as one type of "low-function peers". The behavior of type B node is described as follow. (Note: the term "client" in following description is corresponded to the "type B node" in this document.) "A client has a 'peer-ID' and joins the overlay in the same way as a peer, perhaps establishing the same network of connections that a peer would. Clients participate in the distributed database algorithm, and can help in transporting messages to other peers and Li & Wang Expires May 25, 2008 [Page 4] Internet-Draft P2PSIP Node Types November 2007 clients. However, the distributed database algorithm does not assign resource records to clients." Despite the roles and behaviors of this type of nodes have been described above, the authors of this document could not find any convincing argument on the necessity of defining a separate concept for this type of nodes. If such type of node can "join the overlay in the same way as peer" and "help in transporting messages to other peers and clients", it should be recognized as "non-storage peer" rather than "client". 4. Type C Node Type C nodes refer to the nodes which contribute their storage functionality but do not offer transport functions in P2P network. There are two ways to view this type of nodes: one is "low-function peers"; the other is "P2P clients offering storage services". Compared with the former one, the latter view is accepted by more people. With different views, this type of nodes might behave differently. "low-function peers" behave more like peers, while "P2P clients offering storage services" behave more like the P2P clients defined in the following section. As a "low-function peer", a type C node should join overlay, and provides storage service almost the same as peers do. As a "P2P client offering storage service", a type C node can only provides storage service to its associated peer(s), and the type C nodes might be transparent to other peers. Because type C nodes are not overlay-routing nodes, therefore, it should not be recognized as some kind of peer. In addition, because "P2P client offering storage service" doesn't need to join overlay or need to know the distributed database algorithm using in overlay, designing and implementing "P2P client offering storage service" seems to be less complicated. Thus, in this document, the "P2P client offering storage service" is preferred and type C node is named as "storage P2P client", which is a special type of P2P client defined in section 5.1. The necessity of storage P2P client contains two facets: the necessity of P2P client, the necessity of storage service. There is no reason to forbid P2P client from providing storage service. And these storage services can enlarge the capacity of storage of the overlay. The necessity of P2P client will be discussed in section 5.1. Li & Wang Expires May 25, 2008 [Page 5] Internet-Draft P2PSIP Node Types November 2007 5. Type D Node (Client) Type D nodes refer to the nodes which neither offer transport functionality nor contribute their storage capacities. In this document, these nodes are named as "client". Based on the way to access the distributed database function and distributed transport function provided by overlay, clients (Type D nodes) can be divided into two categories, P2P client and non-P2P client. A P2P client use one or more peers as its associated peer(s) to access these functions; they can directly execute operations such as PUT, GET, with the help of its associated peer. Non-P2P client access these functions indirectly through application entities residing in peers or P2P clients; for example, a SIP UA has to use SIP proxies coupled with peers to register itself into P2PSIP overlay. 5.1. P2P Client The behavior of P2P clients mainly contains three aspects. Firstly, they comply with the common behavior of type D node; that is to say, they neither join the P2P overlay nor contribute the overlay-routing functionalities. Secondly, they are aware of P2P overlay and can execute operations such as PUT and GET via its associated peer to insert a resource into P2P overlay or retrieve it from P2P overlay. Finally, they can be coupled with any application entities. For example, a P2PSIP application can be coupled with P2P client, using the P2P operations as an alternative mechanism to [RFC3263]. Generally speaking, the necessity of P2P client comes from the heterogeneity among the nodes which want to use services provided by P2P overlay. The heterogeneity is explained in different aspects in the following paragraphs. Firstly, the heterogeneity of P2P overlay algorithm makes P2P Client necessary. For example, a P2PSIP node which only supports Chord algorithm, needs to access services of P2PSIP overlay which uses Bamboo DHT. Due to the incompatible P2P algorithms, the Chord-based node can not join in the Bamboo-based DHT overlay. Thus the Chord- based node has to work as P2P Client and use the client protocol to access the services of DHT. Secondly, the heterogeneity among P2PSIP nodes also makes P2P Client necessary. In order to make DHT overlay convergent and efficient, some kinds of nodes, such as nodes with short online time, nodes with limited computational resources, etc, are not suitable to join the overlay. These unqualified nodes can only act as client, using services provided by P2P overlay to avoid introducing badly churns Li & Wang Expires May 25, 2008 [Page 6] Internet-Draft P2PSIP Node Types November 2007 into P2P overlay and (or) making itself overloaded in the maintenance of P2P overlay. The third category of Client candidates comes from the nodes which want to provide services. For example, a STUN/TURN server wants to provide services to other nodes in a P2PSIP system. For two reasons, this server may choose not to join in the P2P overlay. One is for better performance, that is to say, the computational resources for P2P maintenance and routing can be saved for better performance of the service it provided, say STUN/TRUN in this case. The other one is for safety, i.e. if these nodes act as peer in addition to service provider, it may be under the extra threats which comes from its peer role. 5.2. Non-P2P Client Similar to that of P2P client, the behavior of non-P2P client also contains three parts. They not only comply with the general behavior of Type D node, but also can be coupled with any application entities. The main difference is the way they use storage and routing services provided by P2P overlay. The non-P2P clients are using these services via SIP entities or other entities coupled with peers or P2P clients. Taking the SIP UA for example, because they are unaware of P2P overlay, they can only use peers or P2P clients coupled with SIP proxy/registrar to register into P2PSIP system and establish SIP sessions. Although people do not believe this kind of nodes and their protocol should be within the scope of P2PSIP WG, we argue that these non-P2P clients are necessary to P2PSIP system. The reasons mainly come from two aspects. Firstly, in some application scenarios, for security or other considerations, some nodes are not entitled to join overlay and also are forbidden to access P2P overlay directly. Here is an example. According to [I-D.bryan-p2psip-app-scenarios], one possible application scenario is "P2P for Redundant SIP Proxies". Under such circumstances, to ensure the security of P2P network formed by SIP proxies, the operator who deployed these SIP proxies will not allow user nodes join the overlay and act as peers. In addition, for the safety of data stored in the overlay, the user nodes would not be allowed to directly use the PUT, GET or other functions of the P2P overlay either. Therefore, these user nodes have to act as non-P2P client. Secondly, for the compatibility with the existing SIP devices, the non-P2P client should exist in P2PSIP system. These non-P2P aware SIP clients can neither join in P2PSIP overlay nor access the P2P Li & Wang Expires May 25, 2008 [Page 7] Internet-Draft P2PSIP Node Types November 2007 services by using client protocol. However, for smooth evolution of P2PSIP, these SIP clients should be taken into consideration at the beginning of P2PSIP's commercial deployment. Therefore, the compatibility with traditional SIP [RFC3261] is indispensable. Non- P2P client may be the only suitable role for these non-P2P aware SIP clients. 6. Summary Based on the description of behaviors of different node types and analysis on the necessity of each type, we propose the concept of P2PSIP peer (Type A node, MAY include Type B node), storage P2P client (Type C node), P2P client (Type D nodes) and non-P2P client (Type D nodes) should be integrated into the concept of P2PSIP system and their respective protocols should be taken into consideration in the process of the standardization of P2PSIP if necessary. In these proposed concepts, except P2PSIP peer, all the other types can be merged into a more general term which is "P2PSIP client". Currently, the concept of "P2PSIP client" has not been clearly defined. It is hoped that the WG can reach a rough consensus on "P2PSIP client" based on the analysis of different roles and behaviors in P2PSIP system. Li & Wang Expires May 25, 2008 [Page 8] Internet-Draft P2PSIP Node Types November 2007 6.1. Reference Model --->PSTN +------+ +------+ +---------+ / | UA | | UA | | Gateway |-/ |------|##########|------|#####|---------|######## | Peer | | Peer | | Peer 11 | # P2P | 9 | | 10 | +---------+ # Client | | | | # Protocol +------+ +------+ # | # # | N # # | A # # | T +------+ # +-------------+ v N | UA | # | STUN SERVER |====A==|------| +------+ P2PSIP Overlay |-------------| T | P2P | | UA | | Peer 12 | N |Client| |------| +-------------+ A | 4 | | Peer | # T +------+ | 8 | # | | # +------+ # P2PSIP # # Peer # +-------+ +-------+ # Protocol # | Proxy | | Proxy | # ##############|-------|########|-------|####### +-------+ | | | | | Proxy | | Peer 7| | Peer 6|==============|-------| +-------+ +-------+ P2P |Storage| | Client | P2P | | SIP Protocol /|Client | | / | 3 | +--------+ +--------+ SIP / +-------+ | UA | | UA |-----/ |--------| |--------| |non-P2P | |non-P2P | | Client | | Client | | 1 | | 2 | +--------+ +--------+ P2PSIP Network Reference Model Figure 1 Li & Wang Expires May 25, 2008 [Page 9] Internet-Draft P2PSIP Node Types November 2007 Fig 1 illustrates the architecture of P2PSIP networks. This figure is mainly based on the "Figure: P2PSIP Overlay Reference Model" in [I-D.ietf-p2psip-concepts]. In addition, some modifications are made in order to highlight different types of nodes. In Fig 1, each node is separated into two parts. The upper part describes the application entity/entities coupled with the node; while the lower part tells the node's type. Several peers construct a P2PSIP overlay defined in [I-D.ietf-p2psip-concepts] using peer protocol. Some peers may provide extra services, such as STUN/TURN services. P2P Clients and storage P2P clients do not join the P2PSIP overlay but use the distributed database function and distributed transport function provided by overlay. To access these functions, P2P Clients and storage P2P clients used P2P client protocol to communicate with peers. Through P2P client protocol, storage P2P clients can also provide their storage services. Some peers and P2P clients/storage P2P clients are coupled with SIP proxy, thus they can be used as SIP outbound proxies by SIP UAs residing in non-P2P clients. These SIP UAs might be conventional SIP UAs or might support some SIP extensions for P2PSIP. 7. IANA Considerations This memo includes no request to IANA.. 8. Security Considerations No security consideration in current version 9. Acknowledgements This document is mainly inspired by the related discussion in P2PSIP maillist. The authors are grateful to those who have actively participated in the debate on the necessity, behaviors and characters of P2PSIP client. 10. References Li & Wang Expires May 25, 2008 [Page 10] Internet-Draft P2PSIP Node Types November 2007 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 10.2. Informative References [I-D.bryan-p2psip-app-scenarios] Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins, "Application Scenarios for Peer-to-Peer Session Initiation Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00 (work in progress), November 2007. [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., and D. Willis, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-01 (work in progress), November 2007. Authors' Addresses LiChun Li Beijing University of Posts and Telecommunications. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: lilichun@gmail.com Yao Wang Beijing University of Posts and Telecommunications. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 P.R.China Email: yaowang.bupt@gmail.com Li & Wang Expires May 25, 2008 [Page 11] Internet-Draft P2PSIP Node Types November 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). Li & Wang Expires May 25, 2008 [Page 12]