idnits 2.17.1 draft-li-p2psip-client-protocol-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1051. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 12, 2007) is 6010 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-11 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP Working Group L. Li 3 Internet-Draft Ch. Zhang 4 Intended status: Standards Track Y. Wang 5 Expires: May 15, 2008 Y. Ji 6 MINE/BUPT 7 November 12, 2007 9 A SIP-based P2PSIP Client Protocol 10 draft-li-p2psip-client-protocol-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 15, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document presents the motivation, design guidelines and high 44 level descriptions of peer-to-peer session initiation protocol 45 (P2PSIP) client protocol, which is spoken between P2PSIP peers and 46 P2PSIP clients. In this document, the necessity of P2PSIP Client is 47 identified firstly. Then, two fundamental guidelines for our design 48 are explained in details. Following these guidelines, the design of 49 proposed protocol and new extensions to existing SIP (session 50 initiation protocol) are described. Such a SIP-based protocol not 51 only makes itself backward-compatible with the vast existing SIP 52 devices, but also provides extra functions to satisfy some particular 53 requirements raised by P2PSIP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2. Concepts and Terminologies . . . . . . . . . . . . . . . . . . 5 60 3. The necessity of P2PSIP Client . . . . . . . . . . . . . . . . 6 61 4. Our Design Guidelines . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Why SIP-based? . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Why new SIP extensions are needed? . . . . . . . . . . . . 8 64 5. Client Protocol Design . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Protocols for Accessing Services . . . . . . . . . . . . . 9 67 5.2.1. Accessing Services Offered by Peers . . . . . . . . . 9 68 5.2.2. Accessing Services Offered by Clients . . . . . . . . 9 69 5.3. Event Package Extension . . . . . . . . . . . . . . . . . 9 70 5.3.1. Event packages for clients locating services . . . . . 10 71 5.3.2. Event package for clients announcing services . . . . 10 72 6. Network Architecture . . . . . . . . . . . . . . . . . . . . . 11 73 7. Overview of Operations . . . . . . . . . . . . . . . . . . . . 12 74 8. Event Packages for P2PSIP Clients Locating Services . . . . . 13 75 8.1. Service Type Event Package . . . . . . . . . . . . . . . . 14 76 8.2. Server Peer List Event Package . . . . . . . . . . . . . . 14 77 8.2.1. Server Peer List . . . . . . . . . . . . . . . . . . . 15 78 8.3. Persistent Subscription and Immediate Fetch . . . . . . . 16 79 8.4. Roles in Subscription . . . . . . . . . . . . . . . . . . 16 80 9. Operations for P2PSIP Clients Locating Services . . . . . . . 16 81 9.1. Discover Service Types . . . . . . . . . . . . . . . . . . 16 82 9.2. Locate Server Peer . . . . . . . . . . . . . . . . . . . . 17 83 9.2.1. Query Server Peer List . . . . . . . . . . . . . . . . 17 84 9.2.2. Peers Notify the Changes of Server Peers . . . . . . . 17 85 9.2.3. Peers Notify Clients Before Leave . . . . . . . . . . 18 86 9.3. Serving Peer Selection . . . . . . . . . . . . . . . . . . 18 87 9.3.1. Collecting Serving Peer Candidates . . . . . . . . . . 19 88 9.3.2. Selecting Criteria . . . . . . . . . . . . . . . . . . 19 89 9.3.3. Peer instructs client to select peer . . . . . . . . . 19 90 10. P2PSIP Clients Publish Services . . . . . . . . . . . . . . . 20 91 10.1. Service Entry Event Package . . . . . . . . . . . . . . . 21 92 10.2. Publish Service Entries . . . . . . . . . . . . . . . . . 21 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 94 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 95 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 98 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 100 Intellectual Property and Copyright Statements . . . . . . . . . . 24 102 1. Introduction 104 There are two kinds of nodes in P2PSIP, which are P2PSIP Peer and 105 P2PSIP Client [I-D.ietf-p2psip-concepts]. However, for a long period 106 of time, the concept of P2PSIP Client and its role have been a 107 controversial source in the discussion of IETF P2PSIP WG. 109 According to [I-D.ietf-p2psip-concepts], P2PSIP client is defined as 110 a node participating in a P2PSIP Overlay that is less capable than a 111 P2PSIP Peer in some way. Additionally, P2PSIP Client Protocol is 112 defined as the protocol spoken between P2PSIP Clients and P2PSIP 113 Peers. Besides the definitions, there are quite a lot pros and cons 114 on whether the P2PSIP Client and P2PSIP Client Protocol are 115 necessary. However, despite all these disputes, it has been agreed 116 that P2PSIP Clients do have the ability to add, modify, inspect, and 117 delete information in the overlay if they exist. 119 In this document, based on the analysis of the heterogeneity among 120 all the nodes which want to use P2PSIP services, we argue that the 121 role of P2PSIP Client is indispensable. P2PSIP clients are suitable 122 role for several categories of nodes, such as the nodes whose P2P 123 module is incompatible with the existing P2PSIP overlay, the nodes 124 which want to provide service but not willing to join in the P2P 125 overlay, the nodes with limited computational resource, the existing 126 SIP devices and SIP-based soft phones, etc. Section 3 explains these 127 different cases. 129 To make these clients capable of accessing services in P2PSIP 130 overlay, a P2PSIP Client Protocol is needed. We come up with two 131 basic guidelines for our design. Firstly, the proposed client 132 protocol should be SIP-based. Secondly, new SIP extensions are 133 needed to address the new challenges raised by P2PSIP. The reasons 134 for such decisions are presented in Section 4. 136 Following these guidelines, a client protocol is proposed. This 137 client protocol is mainly based on SIP but with new SIP Event Package 138 Extensions. The high level description on the basic operation of the 139 proposed client protocol, the contents and operations of newly- 140 defined SIP Event Package are also presented. Such an approach not 141 only makes the proposed client protocol compatible with existing SIP 142 devices but also satisfies new challenges raised by P2PSIP. 144 The detailed design and implementation of this client protocol are 145 still in progress. This version of draft aims at demonstrating the 146 necessity of P2PSIP Client, exploring some new challenges for client 147 protocol raised by P2PSIP, defining basic concepts and mechanisms 148 used in client protocol. In the future visions, more detailed work 149 will be presented. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. Concepts and Terminologies 159 This section describes several key concepts used in this document. 160 Generally speaking, the concepts and terminologies used in this 161 document follow the definitions in [I-D.ietf-p2psip-concepts]. 162 However, some definitions are modified and some new concepts are 163 added. Both modified and newly-added concepts are listed as follow. 165 o P2PSIP Client: a kind of nodes which want to use the services 166 provided by P2PSIP overlay and MAY provide services to other nodes 167 but can not join in P2PSIP overlay due to some reasons. Such 168 nodes MAY be the node which supports P2PSIP but its P2P module is 169 incompatible with the existing P2PSIP overlay, the node that is 170 not qualified to join P2P overlay due to its limited resource, 171 etc. The P2PSIP Client defined in this document is designed to be 172 complied with the general agreement in [I-D.ietf-p2psip-concepts], 173 that is to say, it do have the ability to add, modify, inspect, 174 and delete information in the overlay. 176 o P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients 177 and P2PSIP Peers. It is used to provide a mechanism for 178 exchanging information between clients and peers. Clients can use 179 this protocol to ask their serving peers to add, modify, inspect, 180 and delete information in the overlay on behalf of client itself. 181 Peers can use this protocol to tell clients the information on 182 itself, other peers, as well as the services which have been 183 registered into P2PSIP overlay. 185 o Server Peer: a P2PSIP Peer which is capable of providing one or 186 more services to clients. 188 o SIP Server Peer: Server Peer that behaves as registrar and SIP 189 proxy. SIP server peer provides SIP service to clients. 191 o SIP Service: Service provided by SIP server Peer. This service 192 allows clients to create, modify, terminate sessions with other 193 nodes. 195 o STUN Server Peer: Server Peer that behaves as STUN server. STUN 196 server peer provides STUN service to clients. 198 o Serving Peer: a P2PSIP Peer which is offering certain types of 199 services to client. For example, when a P2PSIP client is using a 200 P2PSIP peer as its SIP outbound proxy, the peer is a SIP serving 201 peer. 203 o Associated Peer & Associated Client: The server peer(s) on which a 204 P2PSIP client makes persistent subscription(s) of server peer 205 list(s) are referred to as "associated peer(s)" of the client; the 206 P2PSIP client is referred to as "associated client" of the 207 associated peer(s). 209 3. The necessity of P2PSIP Client 211 The necessity of P2PSIP Client originates from the heterogeneity 212 among all the nodes which want or need to use P2PSIP services. 213 Generally speaking, these nodes can be divided in to several 214 categories which are discussed in details as follow. 216 Firstly, the heterogeneity of P2P overlays makes P2PSIP Client 217 necessary. For example, a P2PSIP node which only supports Chord 218 algorithm, needs to access services of P2PSIP overlay which uses 219 Bamboo as P2P algorithm. Due to the incompatible P2P algorithms, the 220 Chord-based node can not join in the Bamboo-based DHT overlay. Thus 221 the Chord-based node has to work as P2PSIP Client. 223 The second kind of Client candidates comes from the nodes which want 224 to provide services. For example, a conferences server wants to 225 provide conference services to nodes in a P2PSIP system. Because the 226 decoding, mixture and encoding of multiple media streams can be quite 227 a heavy load for its computational resources, this conference server 228 may choose not to join in the P2PSIP overlay. Thus, some extra 229 resources, which would be used for the maintenance of P2P overlay if 230 the server joined overlay, can be utilized for providing better 231 conference services. 233 Thirdly, the heterogeneity among P2PSIP nodes also makes P2PSIP 234 Client necessary. In order to make P2PSIP overlay convergent and 235 efficient, some kinds of nodes, such as fast-moving nodes, are not 236 suitable to join the overlay. These unqualified nodes can only act 237 as client, using services provided by P2PSIP overlay rather than 238 joining in the overlay. 240 The fourth kind of P2PSIP Clients come from the vast existing SIP 241 clients, including hardware-based SIP devices and soft phones which 242 support SIP. Obviously, these non-P2P aware SIP clients can neither 243 join in P2PSIP overlay nor offer services. However, for smooth 244 evolution of P2PSIP, these SIP clients must be taken into 245 consideration at the beginning of P2PSIP's commercially deployment. 246 Therefore, the backward-compatibility with traditional SIP [RFC3261] 247 is indispensable. P2PSIP Client may be the only suitable role for 248 these non-P2P aware SIP clients. 250 The cases listed in this section are neither comprehensive nor 251 exclusive; in other words, client may be needed in other scenarios. 252 However, the comprehensive scenarios where P2PSIP Clients are 253 necessary are out of the scope of this document. 255 4. Our Design Guidelines 257 In this section, two fundamental guidelines that we follow during the 258 design process of our proposed client protocol are presented. One 259 states that the proposed protocol should be SIP-based; the other one 260 is that new SIP extensions are needed. Each principle addresses one 261 different perspective of challenges which client protocol has to 262 face. 264 4.1. Why SIP-based? 266 The first one of our guideline states that SIP is the base of newly- 267 proposed client protocol. There are mainly two reasons for such 268 decision. 270 Firstly, SIP is needed because the client protocol has to meet the 271 basic session control requirement. The client protocol must support 272 peers registering clients' information into P2PSIP overlay and the 273 establishment, modification and termination of sessions between 274 client and another node within P2PSIP system. In order to satisfy 275 such requirements, SIP is ideal due to its simplicity, flexibility, 276 etc. In addition, SIP has been not only standardized but also widely 277 used; therefore, using the existing well-developed SIP technologies 278 will reduce the complexity for developers implementing the client 279 protocol. 281 Secondly, in order to make the proposed client protocol compatible 282 with existing SIP devices, SIP is also indispensable. Vast SIP 283 devices and SIP-based soft phones have already been used widely. 284 Thus, to enlarge the user quantity quickly when P2PSIP is deployed at 285 its initial stage, the backward-compatibility which ensures non-P2P 286 aware SIP devices can access services provided by P2PSIP overlay is 287 important. 289 4.2. Why new SIP extensions are needed? 291 Although the basic session control functions can be implemented by 292 existing SIP, there are still lots of other challenges raised by new 293 scenarios of P2PSIP. The challenges which have been identified are 294 explained as follow. 296 o The service reliability requirement. In RFC 3261 [RFC3261], the 297 outbound proxy is typically manually configured on SIP UA. 298 However, P2PSIP peers are typically unstable and ephemeral 299 compared with SIP proxies in traditional SIP; they may leave the 300 overlay or crash from time to time. Therefore, to ensure that 301 clients can access services reliably even though the peers 302 offering this service are unreliable, new SIP extensions are 303 needed. For example, client can use SIP Event Notification 304 Mechanism [RFC3265] to get all available server peers. If the one 305 currently used crashed suddenly, client can switch to another 306 available one. 308 o The service availability requirement. As mentioned in 309 [I-D.ietf-p2psip-concepts], some individual peers may provide 310 extra services, for example STUN [I-D.ietf-behave-rfc3489bis] 311 services, to the overlay or members in the overlay. To make these 312 services accessible for clients, the client protocol MUST enable 313 peers to tell clients what services are available and the detailed 314 parameters for some services of client's interest. 316 o The service efficiency requirement. Both client and peer need to 317 operate effectively. Taking the load of peers for example, client 318 protocol MUST enable peers indicating clients to choose other 319 peers based on some criteria when the peer becomes overloaded. 320 Similarly, in order to ensure the client's efficiency, the client 321 protocol MUST allow client to choose the most suitable peer as its 322 serving peer. The term "most suitable" can be interpreted as low 323 RTT, high bandwidth, etc. However,the exact meaning of the term 324 "most suitable" SHOULD be determined by the local policy of client 325 which is out of the scope of this document 327 o The service announcing requirements. The client protocol MAY be 328 able to be used for announcing the services that clients offer to 329 the P2PSIP overlay or members of the overlay. It is still an open 330 issue that whether P2PSIP clients should provide services or not, 331 and this issue needs further study. However, if P2PSIP clients 332 provide services, service announcing mechanism needs to be defined 333 in client protocol to support these services. What service P2PSIP 334 clients may offer is still an open issue. Storage is a possible 335 service proposed in [I-D.ietf-p2psip-concepts]. Clients may also 336 help in bootstrap procedure of other peers and/or clients. 338 All these above requirements cannot be satisfied by existing SIP and 339 its extensions, thus new SIP extensions are needed, which become our 340 second guideline in designing a client protocol. 342 5. Client Protocol Design 344 5.1. Overview 346 The client protocol proposed in this document is extended from SIP 347 protocol. Currently we define three new SIP event packages. 348 Additional extensions may need to be added in client protocol in the 349 future. 351 5.2. Protocols for Accessing Services 353 5.2.1. Accessing Services Offered by Peers 355 P2PSIP overlay provides services for P2PSIP clients. P2PSIP clients 356 access the services through P2PSIP server peers, and P2PSIP server 357 peers behave as servers, such as SIP servers and STUN servers. 359 Conventional SIP and related protocols allow P2PSIP clients to use 360 the basic services provided by overlay. For example, SIP enables 361 clients to create, modify and terminate sessions with other nodes in 362 overlay. ICE [I-D.ietf-mmusic-ice] and STUN enable sessions to 363 traverse NATs. 365 P2PSIP overlay MAY provide some additional services to P2PSIP 366 clients. To allow P2PSIP clients accessing these services, other 367 protocols might be used between peers and clients or some extensions 368 might be added to client protocol. 370 5.2.2. Accessing Services Offered by Clients 372 P2PSIP clients MAY provide services. To allow other nodes accessing 373 these services, other protocols might be used between peers and 374 clients or some extensions might be added to client protocol. 376 5.3. Event Package Extension 378 We define three SIP event packages to meet the requirements in P2PSIP 379 described in 4.2. P2PSIP clients can utilize these event packages to 380 locate services and announce services. These SIP event packages are 381 extendable, that is to say, these extensions don't require any 382 modification of SIP protocol implementations. Thus, they are easy to 383 implement. 385 5.3.1. Event packages for clients locating services 387 Two event packages are defined in section 8 for clients to locate 388 service. Operations based on these two event packages are described 389 in section 9.These operations meet the service availability, 390 availability and efficiency requirements described in 4.2. These 391 operations are listed below: 393 o Operations required by service availability. P2PSIP clients 394 discover what services the overlay provides. P2PSIP clients 395 locate server peers that can provide specific service. 397 o Operations required by service reliability. P2PSIP peers notify 398 clients the changes of server peers. P2PSIP peers notify clients 399 before leaving. 401 o Operations required by service efficiency. P2PSIP clients select 402 serving peers. P2PSIP clients search desirable server peers. 403 P2PSIP peers instruct clients to select serving peers. 405 5.3.2. Event package for clients announcing services 407 An event package is defined in section 10 to meet the services 408 announcement requirement described in 4.2. Clients can announce 409 services based on this event packages. The details are described in 410 section 10. 412 6. Network Architecture 414 --->PSTN 415 +------+ +------+ +---------+ / 416 | UA | | UA | | Gateway |-/ 417 |------|########|------|#####|---------|######## 418 | Peer | | Peer | | Peer G | # P2PSIP 419 | E | | F | +---------+ # Client 420 +------+ +------+ # Protocol 421 # # | 422 # # | N 423 # # | A 424 # # | T \__/ 425 # +-------------+ v N / \Extended 426 # | STUN SERVER |====A==/ \SIP UA 427 +------+ P2PSIP Overlay |-------------| T /Client\ 428 | UA | | Peer S | N |___B__| 429 |------| +-------------+ A 430 | Peer | # T 431 | D | # 432 +------+ # 433 # # P2PSIP 434 # # Peer 435 # +-------+ +-------+ # Protocol 436 # | Proxy | | Proxy | # 437 ############|-------|########|-------|####### 438 | | | | \_ / 439 | Peer P| | Peer Q|===============/\ 440 +-------+ +-------+ P2PSIP / \ Extended 441 | Client / \ SIP UA 442 | SIP Protocol +------+ 443 \__/ / |Client| 444 unmodified/ \ / | C | 445 SIP UA / \ +------+ 446 /Client\ 447 |___A__| 449 P2PSIP Network Reference Model 451 Figure 1 453 Fig 1 illustrates the architecture of P2PSIP networks. This figure 454 is mainly based on the "Figure: P2PSIP Overlay Reference Model" in 455 [I-D.ietf-p2psip-concepts]. In addition, some modifications are made 456 in order to highlight different types of P2PSIP clients and the 457 P2PSIP Client Protocol. 459 In Fig 1, each node is separated into two parts. The upper part 460 describes the functionality of this node; while the lower part tells 461 the node's role, client or peer. 463 Several peers construct a P2PSIP overlay defined in 464 [I-D.ietf-p2psip-concepts] using peer protocol. Some of these peers 465 are coupled with SIP proxy, thus they can be used as SIP outbound 466 proxies by clients. Some other peer may provide extra services, such 467 as STUN/TURN services. 469 Client does not join the P2PSIP overlay but use the services provided 470 by P2PSIP overlay. Three types of clients are illustrated in Fig 1, 471 which are unmodified SIP UA, extended SIP UA and extended SIP UA 472 located behind NAT devices. 474 Unmodified SIP UA refers to the SIP UA which do not support P2PSIP 475 Client Protocol defined in this document. For such client, denoted 476 as "Client A" in Fig 1, it treats "peer P", which is a peer coupled 477 with SIP Proxy, as a SIP outbound proxy and communicate with other 478 nodes using SIP. 480 Extended SIP UA refers to SIP UA with extensions defined in this 481 document to support P2PSIP client protocol. For such clients, 482 denoted as "Client C" in Fig 1, they can get information about 483 available alternate peers and other available services in addition to 484 the services unmodified SIP UA can get from "peer Q". The "peer Q" 485 is a peer support both peer protocol and client protocol. 487 Extended SIP UA may be located behind NAT devices, for example 488 "Client B" in Fig 1. In this case, the client itself has to be STUN/ 489 TURN-enabled. When it starts, the client could obtain the address of 490 "peer S", which provides STUN/TURN services. Afterwards, the client 491 can use ICE for establishing sessions based on STUN/TURN services. 493 7. Overview of Operations 495 This section represents the basic operations of the proposed client 496 protocol. Generally speaking, these operations can be divided into 497 two categories. The first category contains operations for accessing 498 services, which contains the operations defined in [RFC3261]. The 499 other category contains operations related to locating services. 501 The first kind of operations includes, 502 o SIP service operations. The client acts as SIP UA, and its 503 serving peer acts as registrar and SIP proxy. These operations 504 include client registering itself to peer, peer proxying client's 505 requests, etc. These operations are defined in SIP [RFC3261] and 506 some existing extensions. 508 o Operations for accessing other services offered by peers. These 509 operations need further study. 511 o Operations for accessing the services offered by clients. These 512 operations need further study. 514 The second kind of operations includes but not limited to, 516 o Client discovers available service types provided by P2PSIP 517 overlay 519 o Client queries the list of available server peers 521 o Peers inform clients the changes of server peers 523 o Peers inform clients before leaving P2PSIP overlay 525 o Clients select serving peers 527 o Peers instruct clients to select serving peers 529 o Clients announce services 531 This kind of operations needs new SIP extensions. In this document, 532 we propose extending SIP Event Package RFC 3265 [RFC3265] to achieve 533 this goal. The high level definition of new event packages and their 534 operations are described in section 8,9,10. 536 8. Event Packages for P2PSIP Clients Locating Services 538 As discussed above, existing protocols can not meet all the 539 requirements of client protocol. To meet the services availability, 540 reliability and efficiency requirements described in 4.2, two event 541 packages are defined in this section. Operations based on these 542 event packages are described in next section. Every server peer MUST 543 support these extensions. But supporting these SIP extensions 544 doesn't mean that a server peer MUST work as registrar and proxy. 546 In this document, event packages are utilized to transfer service 547 information and server peer information from P2PSIP peers to P2PSIP 548 clients. A new event package called STEP (Service Type Event 549 Package) is defined for transferring information about services types 550 from P2PSIP peers to P2PSIP clients. A new event packages called 551 SPLEP (Server Peer List Event Package) is defined for transferring 552 information of server peers from P2PSIP peers to P2PSIP clients. 553 This document only gives high level descriptions on the information 554 contained in STEP and SPLEP. Separated documents SHOULD specify the 555 formats of STEP and SPLEP in details. 557 8.1. Service Type Event Package 559 A new event package called STEP (Service Type Event Package) is 560 defined for transferring service type information from P2PSIP peers 561 to P2PSIP clients. A STEP lists all service types that a P2PSIP 562 overlay can provide to P2PSIP clients. A STEP also contains the 563 overlay's overlay name. We give an example to show the information 564 contained in a STEP as bellow: 566 Overlay Name: example.chord 567 Service Type List: SIP, STUN 569 To generate STEP, peers SHOULD know all service types the overlay 570 provides to P2PSIP clients. P2PSIP peer protocol SHOULD provide a 571 mechanism to make peers aware of these services. This issue is out 572 of the scope of this document. 574 8.2. Server Peer List Event Package 576 A new event packages called SPLEP (Server Peer List Event Package) is 577 defined for transferring information of server peers from P2PSIP 578 peers to P2PSIP clients. SPLEP contains overlay name and one or more 579 server peer list. For example: 581 Overlay Name: example.chord 582 Service Peer List(s): SIP server peer list, STUN server peer list 584 Different server peer list in a SPLEP contains information of 585 different type of server peers. Server peer list can be cataloged by 586 the type of server peer. For example, SIP server peer list contains 587 information of SIP server peers, and STUN server peer list contains 588 information of STUN server peers. As a server peer MAY provide more 589 than one type of service, a server peer's MAY be included in 590 different types of server peer lists. By setting parameters in 591 SUBSCRIBE message's body, a P2PSIP client can specify the type(s) of 592 server peer list(s) that should be contained in SPLEP. 594 8.2.1. Server Peer List 596 In server peer list, the information of a server peer at least 597 includes server peer type, service locating point, service entry (or 598 service entries). The information of a server peer MAY include two 599 optional attributes, weight and priority, and some service-specific 600 information. An example of SIP server peer list is given below: 602 +-------+----------------+----------------+------------+------------+ 603 | Server| Service | service | Priority | Weight | 604 | Peer | Locating Point | entries | (optional) | (optional) | 605 | Type | | | | | 606 | | | | | | 607 +-------+----------------+----------------+------------+------------+ 608 | SIP | 30.3.3.3:5060, | 30.3.3.3:5060, | 1 | 1001 | 609 | | UDP; | UDP; | | | 610 | | 30.3.3.3:5060, | 30.3.3.3:5060, | | | 611 | | TCP | TCP | | | 612 | SIP | 20.2.2.2:9060, | 20.2.2.2:9060, | 1 | 1000 | 613 | | UDP; | UDP; | | | 614 | | 20.2.2.2:9060, | 20.2.2.2:9060, | | | 615 | | TCP | TCP | | | 616 +-------+----------------+----------------+------------+------------+ 618 Table 1: SIP sever peer list example 620 Explanations of server peer's attributes: 622 o Server peer type: Server peer type here is corresponded with the 623 type of server peer list containing the server peer. For example, 624 in a SIP server peer list, every server peer's server peer type is 625 set to SIP. 627 o Service entry: A service entry includes IP address, port, transfer 628 protocol. A server peer MAY have several service entries that 629 provide the same type of service. For example, a SIP server peer 630 MAY provide SIP service via TCP and UDP at the same time. 632 o Service locating point: Service locating point includes IP 633 address, port, transfer protocol. Service locating point is the 634 entry for P2PSIP clients subscribing STEP and SPLEP. Service 635 locating point MAY or MAY not be the same as SIP service entry. 637 o Weight and Priority: Weight and Priority attributes indicate a 638 server peer's capacity and priority separately. The meanings of 639 these attributes are similar with those in DNS SRV records RFC 640 2782 [RFC2782]. Both the Priority attribute and Weight attribute 641 are numbers. The Priority attribute indicates the priority that a 642 peer SHOULD be selected. Lower numeric Priority value means 643 higher priority to be selected. The Weight attribute indicates a 644 peer's capacity to accommodate clients. The peer with higher 645 Weight can accommodate more clients. Peers MAY instruct clients 646 to select serving peers by utilizing these two attributes. 647 Priority and Weight attributes MAY be variables, and server 648 selection MAY be dynamic. 650 8.3. Persistent Subscription and Immediate Fetch 652 With SIP SUBSCRIBE/NOTIFY methods [RFC3265] or PUBLISH method 653 [RFC3903], event packages can be transferred between SIP entities. 654 In this document, SUBSCRIBE/NOTIFY methods are used to transfer STEP 655 and SPLEP. SIP SUBSCRIBE/NOTIFY mechanism provides two types of 656 subscriptions: persistent subscription and immediate fetch. 658 An immediate fetch is a subscription expires immediately. Immediate 659 fetch can be used to fetch current status of the event. An immediate 660 fetch is effected by sending a SUBSCRIBE with an "Expires" header of 661 0. 663 Persistent subscription lasts for some time. If subscribers make 664 persistent subscription, notifiers will notify subscribers every time 665 when the status of the event changes. Both persistent subscription 666 and immediate fetch are used in this client protocol. 668 8.4. Roles in Subscription 670 Every P2PSIP server peer MUST have at least one service locating 671 point, on which P2PSIP clients can subscribe STEP and SPLEP. If a 672 P2PSIP client subscribes STEP, SPLEP or both, it behaves as 673 subscriber. A P2PSIP server peer MUST behave as a notifier, if any 674 P2PSIP client subscribes STEP or SPLEP from it. 676 9. Operations for P2PSIP Clients Locating Services 678 9.1. Discover Service Types 680 P2PSIP client can discover available service types by subscribing 681 STEP (Service Types Event Pacakge) from P2PSIP peers. By parsing 682 STEP, a P2PSIP client can find out all service types the overlay can 683 provide. If the P2PSIP client wants to use any type of service among 684 these services, it can use the way described in 8.2 to locate server 685 peers. 687 9.2. Locate Server Peer 689 SPLEP contains information of one or more types of server peers. In 690 SPLEP, the information of a server peer at least includes its overlay 691 name, server peer type, service locating point, service entry (or 692 service entries), weight and priority. By setting parameters in 693 SUBSCRIBE message's body, a P2PSIP client can specify the type(s) of 694 server peer list(s) that should be contained in SPLEP. By 695 subscribing SPLEP and parsing it, P2PSIP clients can find server 696 peers of given types and the service entries on these server peers. 697 A P2PSIP client MAY subscribe SPLEP from several peers. A P2PSIP 698 client MAY subscribe several types of server peer lists. A P2PSIP 699 client MAY subscribe the same type of server peer lists from 700 different peers. 702 For redundancy, any server peer list in a SPLEP SHOULD contain 703 several server peers if possible. To generate SPLEP, P2PSIP peers 704 MUST collect information about available server peers from other 705 peers. But a P2PSIP peer doesn't need to find all available server 706 peers in the overlay, and it's impossible usually. These issues are 707 out of the scope of this document. Some needed mechanisms SHOULD be 708 defined in P2PSIP peer protocol. 710 Immediate fetch or persistent subscription MAY be used to locate 711 server peer. Immediate fetch and persistent subscription are used to 712 support different operations as described in 9.2.1, 9.2.2 and 9.2.3. 714 9.2.1. Query Server Peer List 716 Immediate fetch SHOULD be used for querying server peer list. P2PSIP 717 clients MAY query server peer list occasionally. For example, a 718 P2PSIP client seldom uses some type of service. To reduce overhead, 719 the P2PSIP client may query this type of server peer list every time 720 before it wants to use this type of service. 722 9.2.2. Peers Notify the Changes of Server Peers 724 P2PSIP server peers are unstable, transient. They may leave or fail 725 any time. New server peers may join the overlay anytime. If P2PSIP 726 clients want to be notified the changes of server peers, they SHOULD 727 make persistent subscriptions. 729 Suppose a client make a persistent subscription on a peer. To 730 generate SPLEP for persistent subscription, the peer MUST generate 731 and maintain the server peer list(s) required in SPLEP. The peer 732 MUST has the ability to detect if any server peer in the server peer 733 list(s) leaves or any server peer (exclude itself) in the server peer 734 list(s) fails. The leaving peer or failed peer MUST be removed from 735 the server peer list(s). The peer MAY add one or more server peers 736 in the server peer list(s) it maintains. When the server peer 737 list(s) changes, the peer SHOULD notify its associated clients. 739 9.2.3. Peers Notify Clients Before Leave 741 Persistent subscriptions are required for peer notifying clients 742 before leave. Suppose a P2PSIP client makes persistent subscription 743 of SPLEP from a peer. The client subscribes one or more server peer 744 lists in the persistent subscription. Then the client can receive 745 notification if any server peer in the server peer list(s) is about 746 to leave. We discuss the notification in two cases: 748 Suppose the leaving peer is not the associated peer. If the 749 associated peer detects a peer in the server peer list(s) is about to 750 leave, the associated peer notify the client a SPLEP from which the 751 leaving peer is removed. Notification in this case requires the 752 associated peer has the ability to detect if any peer in the server 753 peer list(s) is about to leave. The detect means MAY be the leaving 754 peer notifying the associated peer. The detect means is out of the 755 scope of this document. 757 Suppose the leaving peer is the associated peer. To leave 758 gracefully, the leaving peer SHOULD inform the associated client 759 about its leaving and terminate the subscription. This can be done 760 by sending the associated client a SPLEP with NOTIFY method. The 761 leaving peer is removed from the server peer list(s) in the SPLEP. 762 To terminate subscriptions, the NOTIFY message contains a 763 "Subscription-State" header with a value of "terminated" as described 764 in RFC 3265 [RFC3265]. 766 9.3. Serving Peer Selection 768 For some reason, such as getting better services, load balance, a 769 P2PSIP client MAY select one or more server peers from all the 770 reachable server peers it knows as serving peer. And other reachable 771 server peers the P2PSIP client knows are backups of serving peers. 772 P2PSIP clients MAY select serving peers periodically. P2PSIP clients 773 MAY select serving peers every time before requesting services. 775 A P2PSIP client MAY select one or more types of serving peers, such 776 as SIP serving peer, STUN serving peer. Specific type of serving 777 peer selection is among the same type of server peers. For example, 778 SIP serving peer selection is among SIP server peers. In the rest of 779 this section, if no specification, serving peer selection refers to a 780 specific type of serving peer selection. 782 9.3.1. Collecting Serving Peer Candidates 784 For selecting serving peers, a client needs to subscribe SPLEP from 785 one or more peers. If the client subscribes SPLEP from more peers, 786 it MAY find more serving peer candidates. Then, it can find more 787 backup peers and MAY find serving peers which are more desirable. If 788 a P2PSIP client subscribes SPLEP from a peer for collecting serving 789 peer candidates exclusively, immediate fetch SHOULD be used to reduce 790 overhead. 792 9.3.2. Selecting Criteria 794 Selecting serving peers can be based on any criteria, such as 795 latency, SIP session success rate, instruction from server peer. The 796 selecting criterion MAY be dynamic and MAY vary in different P2PSIP 797 overlays. Establishing such a criterion is out of the scope of this 798 document. 800 9.3.3. Peer instructs client to select peer 802 Peers MAY or MAY not give instructions to P2PSIP clients for 803 selecting peers. This document provides the mechanism that peers 804 instruct clients to select peers. This mechanism can be used to 805 distribute the requests initiated by clients among server peers. 806 This mechanism MAY help to avoid the situation that some peers are 807 overload, to achieve load balancing. It also MAY help clients to get 808 better services. 810 As avoiding overload and load balance involve many factors, other 811 mechanisms are also needed. Except for serving clients, P2PSIP peers 812 have other tasks such as maintaining overlay and storing data. The 813 capacities of P2PSIP peers are also heterogeneous. Some mechanisms 814 MAY be deployed in peer protocol for avoiding overload and load 815 balancing. These issues are out of the scope of this document. 817 Peers can instruct P2PSIP clients to select serving peers by 818 utilizing Priority and Weight attributes. There are two types of 819 instruction: strict instruction and loose instruction. 821 o Strict instruction 823 In strict instruction case, the criterion of selecting peers is 824 decided by peers. P2PSIP clients receive instruction from peers and 825 select peers strictly obeying instructions if possible. The rules of 826 strict instruction are the same as the rules in selecting servers 827 defined in RFC 2782 [RFC2782]. Among all the reachable peers, P2PSIP 828 clients MUST select serving peer from the peer(s) with lowest 829 Priority attribute (i.e. highest priority). If there are more than 830 one peers with highest priority, P2PSIP clients SHOULD select 831 according to these peers' weight attributes. Larger weights SHOULD 832 be given a proportionately higher probability of being selected. An 833 example is given as follow. All reachable SIP server peers a P2PSIP 834 client knows is listed as below: 836 +-------------------+----------+--------+ 837 | Service Peer | Priority | Weight | 838 +-------------------+----------+--------+ 839 | SIP server peer A | 1 | 30 | 840 | SIP server peer B | 1 | 20 | 841 | SIP server peer C | 2 | 100 | 842 +-------------------+----------+--------+ 844 Table 2: strict instruction example 846 As server peer A and server peer B have highest priority (lowest 847 Priority attribute value), the serving peer must be selected from 848 them. According to their Weight attributes, the probability of 849 server peer A being selected should be 30/(30+20), and the 850 probability of server peer B being selected should be 20/(30+20). 852 From the view of peers, P2PSIP peers MAY set priority and weight 853 attributes with the consideration of load distribution. As P2PSIP 854 clients select peers only according to Priority and Weight 855 attributes, P2PSIP peers MAY set Priority and Weight attributes with 856 other considerations so that P2PSIP clients can get better services. 857 For example, proximity-aware technologies MAY be deployed and P2PSIP 858 clients can be instructed to select close peers. 860 o Loose instruction 862 In loose instruction, P2PSIP clients select peers with the 863 considerations of other factors besides priority and weight 864 attributes. The selection criterion is out of the scope of this 865 document. But peers with higher priority and peers with higher 866 capacity SHOULD have more chances to be selected. 868 10. P2PSIP Clients Publish Services 870 P2PSIP clients MAY or MAY not provide some services, such as storage. 871 This document is not intent to discuss what services P2PSIP clients 872 SHOULD provide and how to implement these services. These services 873 may be accessed through existing protocols or client protocol. These 874 issues are out of the scope of this document. We only describe how 875 to publish the services provided by P2PSIP clients, if these services 876 exist. In this section, a new SIP event package called SEEP (Service 877 Entry Event Package) is defined for transferring services 878 information. 880 10.1. Service Entry Event Package 882 A SEEP contains information of all entries of services provided by a 883 P2PSIP client. SEEP also contains some related information, such as 884 overlay name. In SEEP, information of a service at least includes 885 service type, service entry (or service entries). Service-specific 886 information and service capacity information MAY be contained in 887 SEEP. Suppose a P2PSIP client provides storage service via FTP, the 888 SEEP MAY look like: 890 +------------+-----------------+------------------------------------+ 891 | Service | Service Entry | Service-specific Information | 892 | Type | | | 893 +------------+-----------------+------------------------------------+ 894 | FTP | 10.0.0.2:21,TCP | username: alice; password: | 895 | | | PasswordOfAlice | 896 +------------+-----------------+------------------------------------+ 898 Table 3: SEEP example 900 10.2. Publish Service Entries 902 P2PSIP clients MAY send SEEP to P2PSIP peers with SIP PUBLISH method. 903 P2PSIP peers MAY or MAY not publish the service information of P2PSIP 904 clients in overlay. P2PSIP clients MAY access the services provided 905 by other clients just like access the services provided by peers. 907 11. IANA Considerations 909 This document proposes several event packages, each of them need IANA 910 considerations such as Package Name, Package or Template-Package, 911 etc. However, because this document only provide a high level 912 description of these event packages, the detailed description of each 913 event package and its own IANA considerations will be defined in 914 respective documents. Thus, no IANA consideration is listed in this 915 document. 917 12. Security Considerations 919 Although some attack and threat models and security mechanisms for 920 SIP are proposed in RFC 3261 [RFC3261], there are still lots of 921 security challenges which the proposed P2PSIP Client Protocol has to 922 face. What is more, compared with Client/Server mode, the nature of 923 peer-to-peer system makes it even more complicated to design a secure 924 client protocol. 926 Currently, we are at the initial stage of designing security 927 mechanism for the proposed client protocol. Thus, in this version of 928 draft the security issues are not covered. In the future version, 929 the security considerations will be presented in a detailed way. 931 13. Acknowledgements 933 The authors wish to thank Tao Ma and Zhenyu Wu for their valuable 934 comments. In addition, the authors also quite appreciate the 935 discussions on the topic of P2PSIP Client in the IETF P2PSIP 936 maillist. 938 14. References 940 14.1. Normative References 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 946 specifying the location of services (DNS SRV)", RFC 2782, 947 February 2000. 949 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 950 A., Peterson, J., Sparks, R., Handley, M., and E. 951 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 952 June 2002. 954 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 955 Event Notification", RFC 3265, June 2002. 957 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 958 for Event State Publication", RFC 3903, October 2004. 960 14.2. Informative References 962 [I-D.ietf-behave-rfc3489bis] 963 Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 964 Wing, "Session Traversal Utilities for (NAT) (STUN)", 965 draft-ietf-behave-rfc3489bis-11 (work in progress), 966 October 2007. 968 [I-D.ietf-mmusic-ice] 969 Rosenberg, J., "Interactive Connectivity Establishment 970 (ICE): A Protocol for Network Address Translator (NAT) 971 Traversal for Offer/Answer Protocols", 972 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 974 [I-D.ietf-p2psip-concepts] 975 Bryan, D., "Concepts and Terminology for Peer to Peer 976 SIP", draft-ietf-p2psip-concepts-00 (work in progress), 977 July 2007. 979 Authors' Addresses 981 LiChun Li 982 Mobile lIfe and New mEdia Lab, BUPT. 983 P.O. Box 92, No.10, Xitucheng Road 984 BeiJing, Haidian District 100876 985 China 987 Email: lilichun@gmail.com 989 Chunhong Zhang 990 Mobile lIfe and New mEdia Lab, BUPT. 991 P.O. Box 92, No.10, Xitucheng Road 992 BeiJing, Haidian District 100876 993 China 995 Email: zhangch@bupt.edu.cn 997 Yao Wang 998 Mobile lIfe and New mEdia Lab, BUPT. 999 P.O. Box 92, No.10, Xitucheng Road 1000 BeiJing, Haidian District 100876 1001 China 1003 Email: yaowang.bupt@gmail.com 1005 Yang Ji 1006 Mobile lIfe and New mEdia Lab, BUPT. 1007 P.O. Box 92, No.10, Xitucheng Road 1008 BeiJing, Haidian District 100876 1009 China 1011 Email: jiyang@bupt.edu.cn 1013 Full Copyright Statement 1015 Copyright (C) The IETF Trust (2007). 1017 This document is subject to the rights, licenses and restrictions 1018 contained in BCP 78, and except as set forth therein, the authors 1019 retain all their rights. 1021 This document and the information contained herein are provided on an 1022 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1023 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1024 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1025 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1026 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1027 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1029 Intellectual Property 1031 The IETF takes no position regarding the validity or scope of any 1032 Intellectual Property Rights or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; nor does it represent that it has 1036 made any independent effort to identify any such rights. Information 1037 on the procedures with respect to rights in RFC documents can be 1038 found in BCP 78 and BCP 79. 1040 Copies of IPR disclosures made to the IETF Secretariat and any 1041 assurances of licenses to be made available, or the result of an 1042 attempt made to obtain a general license or permission for the use of 1043 such proprietary rights by implementers or users of this 1044 specification can be obtained from the IETF on-line IPR repository at 1045 http://www.ietf.org/ipr. 1047 The IETF invites any interested party to bring to its attention any 1048 copyrights, patents or patent applications, or other proprietary 1049 rights that may cover technology that may be required to implement 1050 this standard. Please address the information to the IETF at 1051 ietf-ipr@ietf.org. 1053 Acknowledgment 1055 Funding for the RFC Editor function is provided by the IETF 1056 Administrative Support Activity (IASA).