idnits 2.17.1 draft-li-p2psip-node-types-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 22, 2007) is 5998 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group L Ch. Li 3 Internet-Draft Y. Wang 4 Intended status: Informational BUPT 5 Expires: May 25, 2008 November 22, 2007 7 Different types of nodes in P2PSIP 8 draft-li-p2psip-node-types-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 25, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document is an attempt to classify different types of node in 42 peer-to-peer Session Initiation Protocol (P2PSIP). Four possible 43 types of nodes in P2PSIP are discussed based on two characters: 44 whether it offers overlay-routing services and whether it offers 45 storage functions. The behaviors of each type of nodes and their 46 possible necessities are analyzed. This document is dedicated to be 47 a reference for clarifying some controversial terms in P2PSIP working 48 group, such as "client", "low-function peer", etc. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Types of Nodes . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Possible types of nodes . . . . . . . . . . . . . . . . . 3 56 2.2. Naming of different types . . . . . . . . . . . . . . . . 4 57 3. Type B Node . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Type C Node . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Type D Node (Client) . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. P2P Client . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Non-P2P Client . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Introduction 75 In IETF P2PSIP WG, the discussion on the term "client" and its 76 possible behavior has lasted for a long time. But there is still no 77 consensus on the roles and behaviors of non-peer nodes until now. 79 To clarify these concepts, based on two fundamental services provided 80 by P2P overlay, which are overlay-routing and storage, we try to 81 classify different node types within P2PSIP. For each type of nodes, 82 their role and behavior are described firstly; then the necessity of 83 such node is explored. Because not all the node types are necessary, 84 for the node types that can be merged into other types, our arguments 85 are presented. 87 This document is dedicated to be a reference for clarifying some 88 controversial terms in P2PSIP WG, such as "client", "low-function 89 peer", etc. It is hoped that this document could help the WG to 90 reach a rough consensus on the types of node within P2PSIP system and 91 the characters of each type's behavior. 93 Many points and arguments in this document originate from the 94 discussions in the P2PSIP maillist and related Internet-Drafts. The 95 authors of this document appreciate the contributions that are made 96 by the people who joined in the related discussions. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Types of Nodes 106 2.1. Possible types of nodes 108 According to [I-D.ietf-p2psip-concepts], P2PSIP overlay provides 109 distributed database function and distributed transport function for 110 SIP and other applications. In P2PSIP overlay, peers offer storage 111 and transport services to allow the distributed database function and 112 distributed transport function to be implemented. Other types of 113 nodes MAY exist in P2PSIP. 115 Based on the functionalities provided by P2P overlay, say capability 116 of storage and transport services, nodes in P2PSIP can be divided 117 into four types as follow: 119 o Type A Nodes: nodes offering storage and transport services. 121 o Type B Nodes: nodes offering transport services but NOT offering 122 storage services. 124 o Type C Nodes: nodes offering storage services but NOT offering 125 transport services. 127 o Type D Nodes: nodes NEITHER offering storage NOR offering 128 transport services, only using these services. 130 In all these types, Type A nodes have been accepted as "P2PSIP peer" 131 or "peer" by the P2PSIP WG. Thus, in the following sections, we will 132 mainly focus on the other three types of nodes. 134 2.2. Naming of different types 136 Given that the terms such as "client", "low-function peer" are too 137 ambiguous, in this subsection the naming of each type of node are 138 clarified. 140 In the client/server computing model, "client" refers to nodes only 141 using services. In the peer-to-peer computing model, "peer" refers 142 to the nodes both using services and providing services. Thus, type 143 A node can be named as "peer", which has been accepted by the P2PSIP 144 WG. Also type D node can be named "client". For type B and type C 145 nodes, they will be assigned a suitable name based on the analysis of 146 their main characters. 148 3. Type B Node 150 Type B nodes refer to the nodes which offer transport functionality 151 but do not contribute their storage capacity. 153 In the current version of [I-D.ietf-p2psip-concepts], such type of 154 nodes is referred as "peers with bad memory". Some want to call this 155 type of nodes as "clients", and others view this type of nodes as one 156 type of "low-function peers". The behavior of type B node is 157 described as follow. 159 (Note: the term "client" in following description is corresponded to 160 the "type B node" in this document.) 162 "A client has a 'peer-ID' and joins the overlay in the same way as a 163 peer, perhaps establishing the same network of connections that a 164 peer would. Clients participate in the distributed database 165 algorithm, and can help in transporting messages to other peers and 166 clients. However, the distributed database algorithm does not assign 167 resource records to clients." 169 Despite the roles and behaviors of this type of nodes have been 170 described above, the authors of this document could not find any 171 convincing argument on the necessity of defining a separate concept 172 for this type of nodes. If such type of node can "join the overlay 173 in the same way as peer" and "help in transporting messages to other 174 peers and clients", it should be recognized as "non-storage peer" 175 rather than "client". 177 4. Type C Node 179 Type C nodes refer to the nodes which contribute their storage 180 functionality but do not offer transport functions in P2P network. 182 There are two ways to view this type of nodes: one is "low-function 183 peers"; the other is "P2P clients offering storage services". 184 Compared with the former one, the latter view is accepted by more 185 people. 187 With different views, this type of nodes might behave differently. 188 "low-function peers" behave more like peers, while "P2P clients 189 offering storage services" behave more like the P2P clients defined 190 in the following section. As a "low-function peer", a type C node 191 should join overlay, and provides storage service almost the same as 192 peers do. As a "P2P client offering storage service", a type C node 193 can only provides storage service to its associated peer(s), and the 194 type C nodes might be transparent to other peers. 196 Because type C nodes are not overlay-routing nodes, therefore, it 197 should not be recognized as some kind of peer. In addition, because 198 "P2P client offering storage service" doesn't need to join overlay or 199 need to know the distributed database algorithm using in overlay, 200 designing and implementing "P2P client offering storage service" 201 seems to be less complicated. Thus, in this document, the "P2P 202 client offering storage service" is preferred and type C node is 203 named as "storage P2P client", which is a special type of P2P client 204 defined in section 5.1. 206 The necessity of storage P2P client contains two facets: the 207 necessity of P2P client, the necessity of storage service. There is 208 no reason to forbid P2P client from providing storage service. And 209 these storage services can enlarge the capacity of storage of the 210 overlay. The necessity of P2P client will be discussed in section 211 5.1. 213 5. Type D Node (Client) 215 Type D nodes refer to the nodes which neither offer transport 216 functionality nor contribute their storage capacities. In this 217 document, these nodes are named as "client". 219 Based on the way to access the distributed database function and 220 distributed transport function provided by overlay, clients (Type D 221 nodes) can be divided into two categories, P2P client and non-P2P 222 client. A P2P client use one or more peers as its associated peer(s) 223 to access these functions; they can directly execute operations such 224 as PUT, GET, with the help of its associated peer. Non-P2P client 225 access these functions indirectly through application entities 226 residing in peers or P2P clients; for example, a SIP UA has to use 227 SIP proxies coupled with peers to register itself into P2PSIP 228 overlay. 230 5.1. P2P Client 232 The behavior of P2P clients mainly contains three aspects. Firstly, 233 they comply with the common behavior of type D node; that is to say, 234 they neither join the P2P overlay nor contribute the overlay-routing 235 functionalities. Secondly, they are aware of P2P overlay and can 236 execute operations such as PUT and GET via its associated peer to 237 insert a resource into P2P overlay or retrieve it from P2P overlay. 238 Finally, they can be coupled with any application entities. For 239 example, a P2PSIP application can be coupled with P2P client, using 240 the P2P operations as an alternative mechanism to [RFC3263]. 242 Generally speaking, the necessity of P2P client comes from the 243 heterogeneity among the nodes which want to use services provided by 244 P2P overlay. The heterogeneity is explained in different aspects in 245 the following paragraphs. 247 Firstly, the heterogeneity of P2P overlay algorithm makes P2P Client 248 necessary. For example, a P2PSIP node which only supports Chord 249 algorithm, needs to access services of P2PSIP overlay which uses 250 Bamboo DHT. Due to the incompatible P2P algorithms, the Chord-based 251 node can not join in the Bamboo-based DHT overlay. Thus the Chord- 252 based node has to work as P2P Client and use the client protocol to 253 access the services of DHT. 255 Secondly, the heterogeneity among P2PSIP nodes also makes P2P Client 256 necessary. In order to make DHT overlay convergent and efficient, 257 some kinds of nodes, such as nodes with short online time, nodes with 258 limited computational resources, etc, are not suitable to join the 259 overlay. These unqualified nodes can only act as client, using 260 services provided by P2P overlay to avoid introducing badly churns 261 into P2P overlay and (or) making itself overloaded in the maintenance 262 of P2P overlay. 264 The third category of Client candidates comes from the nodes which 265 want to provide services. For example, a STUN/TURN server wants to 266 provide services to other nodes in a P2PSIP system. For two reasons, 267 this server may choose not to join in the P2P overlay. One is for 268 better performance, that is to say, the computational resources for 269 P2P maintenance and routing can be saved for better performance of 270 the service it provided, say STUN/TRUN in this case. The other one 271 is for safety, i.e. if these nodes act as peer in addition to service 272 provider, it may be under the extra threats which comes from its peer 273 role. 275 5.2. Non-P2P Client 277 Similar to that of P2P client, the behavior of non-P2P client also 278 contains three parts. They not only comply with the general behavior 279 of Type D node, but also can be coupled with any application 280 entities. The main difference is the way they use storage and 281 routing services provided by P2P overlay. The non-P2P clients are 282 using these services via SIP entities or other entities coupled with 283 peers or P2P clients. Taking the SIP UA for example, because they 284 are unaware of P2P overlay, they can only use peers or P2P clients 285 coupled with SIP proxy/registrar to register into P2PSIP system and 286 establish SIP sessions. 288 Although people do not believe this kind of nodes and their protocol 289 should be within the scope of P2PSIP WG, we argue that these non-P2P 290 clients are necessary to P2PSIP system. The reasons mainly come from 291 two aspects. 293 Firstly, in some application scenarios, for security or other 294 considerations, some nodes are not entitled to join overlay and also 295 are forbidden to access P2P overlay directly. Here is an example. 296 According to [I-D.bryan-p2psip-app-scenarios], one possible 297 application scenario is "P2P for Redundant SIP Proxies". Under such 298 circumstances, to ensure the security of P2P network formed by SIP 299 proxies, the operator who deployed these SIP proxies will not allow 300 user nodes join the overlay and act as peers. In addition, for the 301 safety of data stored in the overlay, the user nodes would not be 302 allowed to directly use the PUT, GET or other functions of the P2P 303 overlay either. Therefore, these user nodes have to act as non-P2P 304 client. 306 Secondly, for the compatibility with the existing SIP devices, the 307 non-P2P client should exist in P2PSIP system. These non-P2P aware 308 SIP clients can neither join in P2PSIP overlay nor access the P2P 309 services by using client protocol. However, for smooth evolution of 310 P2PSIP, these SIP clients should be taken into consideration at the 311 beginning of P2PSIP's commercial deployment. Therefore, the 312 compatibility with traditional SIP [RFC3261] is indispensable. Non- 313 P2P client may be the only suitable role for these non-P2P aware SIP 314 clients. 316 6. Summary 318 Based on the description of behaviors of different node types and 319 analysis on the necessity of each type, we propose the concept of 320 P2PSIP peer (Type A node, MAY include Type B node), storage P2P 321 client (Type C node), P2P client (Type D nodes) and non-P2P client 322 (Type D nodes) should be integrated into the concept of P2PSIP system 323 and their respective protocols should be taken into consideration in 324 the process of the standardization of P2PSIP if necessary. 326 In these proposed concepts, except P2PSIP peer, all the other types 327 can be merged into a more general term which is "P2PSIP client". 328 Currently, the concept of "P2PSIP client" has not been clearly 329 defined. It is hoped that the WG can reach a rough consensus on 330 "P2PSIP client" based on the analysis of different roles and 331 behaviors in P2PSIP system. 333 6.1. Reference Model 335 --->PSTN 336 +------+ +------+ +---------+ / 337 | UA | | UA | | Gateway |-/ 338 |------|##########|------|#####|---------|######## 339 | Peer | | Peer | | Peer 11 | # P2P 340 | 9 | | 10 | +---------+ # Client 341 | | | | # Protocol 342 +------+ +------+ # | 343 # # | N 344 # # | A 345 # # | T +------+ 346 # +-------------+ v N | UA | 347 # | STUN SERVER |====A==|------| 348 +------+ P2PSIP Overlay |-------------| T | P2P | 349 | UA | | Peer 12 | N |Client| 350 |------| +-------------+ A | 4 | 351 | Peer | # T +------+ 352 | 8 | # 353 | | # 354 +------+ # P2PSIP 355 # # Peer 356 # +-------+ +-------+ # Protocol 357 # | Proxy | | Proxy | # 358 ##############|-------|########|-------|####### +-------+ 359 | | | | | Proxy | 360 | Peer 7| | Peer 6|==============|-------| 361 +-------+ +-------+ P2P |Storage| 362 | Client | P2P | 363 | SIP Protocol /|Client | 364 | / | 3 | 365 +--------+ +--------+ SIP / +-------+ 366 | UA | | UA |-----/ 367 |--------| |--------| 368 |non-P2P | |non-P2P | 369 | Client | | Client | 370 | 1 | | 2 | 371 +--------+ +--------+ 373 P2PSIP Network Reference Model 375 Figure 1 377 Fig 1 illustrates the architecture of P2PSIP networks. This figure 378 is mainly based on the "Figure: P2PSIP Overlay Reference Model" in 379 [I-D.ietf-p2psip-concepts]. In addition, some modifications are made 380 in order to highlight different types of nodes. 382 In Fig 1, each node is separated into two parts. The upper part 383 describes the application entity/entities coupled with the node; 384 while the lower part tells the node's type. 386 Several peers construct a P2PSIP overlay defined in 387 [I-D.ietf-p2psip-concepts] using peer protocol. Some peers may 388 provide extra services, such as STUN/TURN services. 390 P2P Clients and storage P2P clients do not join the P2PSIP overlay 391 but use the distributed database function and distributed transport 392 function provided by overlay. To access these functions, P2P Clients 393 and storage P2P clients used P2P client protocol to communicate with 394 peers. Through P2P client protocol, storage P2P clients can also 395 provide their storage services. 397 Some peers and P2P clients/storage P2P clients are coupled with SIP 398 proxy, thus they can be used as SIP outbound proxies by SIP UAs 399 residing in non-P2P clients. These SIP UAs might be conventional SIP 400 UAs or might support some SIP extensions for P2PSIP. 402 7. IANA Considerations 404 This memo includes no request to IANA.. 406 8. Security Considerations 408 No security consideration in current version 410 9. Acknowledgements 412 This document is mainly inspired by the related discussion in P2PSIP 413 maillist. The authors are grateful to those who have actively 414 participated in the debate on the necessity, behaviors and characters 415 of P2PSIP client. 417 10. References 418 10.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 424 A., Peterson, J., Sparks, R., Handley, M., and E. 425 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 426 June 2002. 428 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 429 Protocol (SIP): Locating SIP Servers", RFC 3263, 430 June 2002. 432 10.2. Informative References 434 [I-D.bryan-p2psip-app-scenarios] 435 Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins, 436 "Application Scenarios for Peer-to-Peer Session Initiation 437 Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00 438 (work in progress), November 2007. 440 [I-D.ietf-p2psip-concepts] 441 Bryan, D., Matthews, P., Shim, E., and D. Willis, 442 "Concepts and Terminology for Peer to Peer SIP", 443 draft-ietf-p2psip-concepts-01 (work in progress), 444 November 2007. 446 Authors' Addresses 448 LiChun Li 449 Beijing University of Posts and Telecommunications. 450 P.O. Box 92, No.10, Xitucheng Road 451 BeiJing, Haidian District 100876 452 P.R.China 454 Email: lilichun@gmail.com 456 Yao Wang 457 Beijing University of Posts and Telecommunications. 458 P.O. Box 92, No.10, Xitucheng Road 459 BeiJing, Haidian District 100876 460 P.R.China 462 Email: yaowang.bupt@gmail.com 464 Full Copyright Statement 466 Copyright (C) The IETF Trust (2007). 468 This document is subject to the rights, licenses and restrictions 469 contained in BCP 78, and except as set forth therein, the authors 470 retain all their rights. 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 475 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 476 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Intellectual Property 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has 487 made any independent effort to identify any such rights. Information 488 on the procedures with respect to rights in RFC documents can be 489 found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use of 494 such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository at 496 http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org. 504 Acknowledgment 506 Funding for the RFC Editor function is provided by the IETF 507 Administrative Support Activity (IASA).