idnits 2.17.1 draft-zheng-p2psip-client-protocol-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1452. 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 (February 22, 2008) is 5905 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) == Unused Reference: 'RFC3261' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1304, but no explicit reference was found in the text == Unused Reference: 'RFC4485' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-requirement' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-dsip' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: 'I-D.bryan-p2psip-reload' is defined on line 1356, but no explicit reference was found in the text == Unused Reference: 'I-D.baset-p2psip-p2pp' is defined on line 1360, but no explicit reference was found in the text == Unused Reference: 'I-D.Jennings-p2psip-asp' is defined on line 1363, but no explicit reference was found in the text == Unused Reference: 'I-D.marocco-p2psip-xpp-pcan' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'I-D.matthews-p2psip-hip-hop' is defined on line 1371, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4485 -- No information found for draft-ietf-behave- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-behave-rfc3489bis' == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-00 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') ** Downref: Normative reference to an Informational draft: draft-pascual-p2psip-clients (ref. 'I-D.pascual-p2psip-clients') == Outdated reference: A later version (-01) exists of draft-jiang-p2psip-sep-00 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-17 ** Downref: Normative reference to an Informational draft: draft-bryan-p2psip-requirements (ref. 'I-D.bryan-p2psip-requirement') -- Possible downref: Non-RFC (?) normative reference: ref. 'P2PSIP-Concepts-Terminology' == Outdated reference: A later version (-04) exists of draft-bryan-p2psip-reload-00 == Outdated reference: A later version (-01) exists of draft-baset-p2psip-p2pp-00 == Outdated reference: A later version (-01) exists of draft-marocco-p2psip-xpp-pcan-00 Summary: 5 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yongchao. Song 3 Internet-Draft Xingfeng. Jiang 4 Intended status: Standards Track Hewen. Zheng 5 Expires: August 25, 2008 Huawei 6 Hui. Deng 7 China Mobile 8 February 22, 2008 10 P2PSIP Client Protocol 11 draft-zheng-p2psip-client-protocol-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 25, 2008. 38 Abstract 40 This document defines P2PSIP client protocol, one protocol for 41 client-peer communication, which is used to create, implement and 42 maintain the services between a client and its associated peers. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Overview of Functions . . . . . . . . . . . . . . . . . . . . 4 48 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . . 7 50 4.1. High-level Descriptions . . . . . . . . . . . . . . . . . 7 51 4.2. Messages Routing . . . . . . . . . . . . . . . . . . . . . 8 52 4.3. Messages Transporting . . . . . . . . . . . . . . . . . . 8 53 4.4. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . 8 54 4.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9 55 4.6. Node Capability . . . . . . . . . . . . . . . . . . . . . 10 56 4.7. Node Status . . . . . . . . . . . . . . . . . . . . . . . 10 57 5. Packets Formats . . . . . . . . . . . . . . . . . . . . . . . 10 58 5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 10 59 5.2. Message Attributes . . . . . . . . . . . . . . . . . . . . 11 60 5.2.1. Response Attribute . . . . . . . . . . . . . . . . . . 12 61 5.2.2. Status Attribute . . . . . . . . . . . . . . . . . . . 13 62 5.2.3. Service Capability . . . . . . . . . . . . . . . . . . 14 63 5.2.4. Uptime Attribute . . . . . . . . . . . . . . . . . . . 15 64 5.2.5. Overlay Info Attribute . . . . . . . . . . . . . . . . 15 65 5.2.6. Security Attribute . . . . . . . . . . . . . . . . . . 16 66 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 6.1. Inquire . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 6.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 6.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 21 70 6.4. Notify . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 6.5. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 6.6. Put . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 6.7. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 24 74 6.8. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 6.9. LookUpServicePeer . . . . . . . . . . . . . . . . . . . . 25 76 7. Contribute Storage Capacity . . . . . . . . . . . . . . . . . 26 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 85 Intellectual Property and Copyright Statements . . . . . . . . . . 33 87 1. Introduction 89 Conventional centralized function is provided by a single node using 90 Client/Server mode, e.g. STUN and FTP. Distributed function is 91 provided by many nodes using peer-to-peer mode, in this mode, each 92 node contributes its services to other nodes to allow the overlay 93 consisting of all individual nodes to collectively provide function, 94 e.g. P2PSIP. A node can solely provide centralized function, but it 95 must cooperate with other nodes to collectively provide distributed 96 function. 98 In P2PSIP, nodes participating in a P2PSIP Overlay that provides 99 storage and transport services to other nodes in that P2PSIP Overlay 100 are called P2PSIP peers. P2PSIP overlay can provision services to 101 nodes that participate in the overlay but don't provide distributed 102 transport service in the overlay, those nodes are called P2PSIP 103 Clients, and at the same time those P2PSIP Peers which are associated 104 with P2PSIP Clients and provide P2PSIP functions to P2PSIP Clients 105 are called Host Peers or Associated Peers. Host Peers or Associated 106 Peers must be P2PSIP neighbors of P2PSIP Clients. In this document, 107 we call P2PSIP Peer as Peer and P2PSIP Client as Client unless 108 special explanation. 110 Essentially Peers are P2PSIP overlay routing nodes, and Clients are 111 non-overlay-routing nodes [P2PSIP-Concepts-Terminology]. Any Peer 112 owns a unique identifier known as Peer-ID in P2PSIP overlay, and 113 P2PSIP overlay is transparent to Clients. 115 Peers participate in structuring P2PSIP overlay, they collectively 116 provide P2PSIP overlay functions - distributed storage function and 117 distributed transport function, the peers in the overlay collectively 118 run a distributed database algorithm. Clients participate in the 119 P2PSIP overlay, but they are unable or unwilling to provide 120 distributed storage function or distributed transport function. 122 A client interacts with the P2PSIP overlay through an associated peer 123 (or perhaps several peers) using the client protocol. The client 124 does not run the distributed database algorithm, and is not involved 125 in routing messages to other peers or clients. Through interactions 126 with its associated peer, a client can insert, modify, examine, and 127 remove resource records. 129 What services a client can contribute to the overlay can be found in 130 the client draft[I-D.pascual-p2psip-clients]. We support the 131 function that a client can contribute its storage space to its 132 associated peer in our p2psip client protocol. It can be easily 133 realized by sending a PUT or Get message from a peer to its 134 associated client after receiving knowleadge of the contributable 135 storage space from its associated client. 137 P2PSIP client protocol is used to create, implement and maintain the 138 services between a client and its associated peer. 140 One communication protocol known as "P2PSIP Peer protocol" is used to 141 create and maintain all participant peers topology and distributed 142 function in the overlay, i.e., to share information and organize 143 P2PSIP overlay network. It has been agreed that the client protocol 144 is a functional subset of the P2P Peer Protocol, but may differ in 145 syntax and protocol implementation (i.e., may not be syntactically 146 related). 148 This document defines the P2PSIP client protocol basing on one P2PSIP 149 peer protocol "Service Extensible P2P Peer Protocol" [I-D. jiang- 150 p2psip-sep], i.e. the defined P2PSIP client protocol reuses the 151 P2PSIP peer protocol if possible, and certainly they may be different 152 in syntax. 154 2. Overview of Functions 156 P2PSIP client protocol is used to communicate between a client and 157 its associated peer depicted as Figure 1, the peer Q is not coupled 158 with SIP entity such as SIP UA, SIP proxy or SIP redirector, but the 159 client C is coupled with SIP UA, and the client C uses P2PSIP client 160 protocol to retrieve the callee's contact info from P2PSIP overlay 161 through Peer Q. 163 --->PSTN 164 +------+ N +------+ +---------+ / 165 | | A | | | Gateway |-/ 166 | UA |####T#####| UA |#####| Peer |######## 167 | Peer | N | Peer | | G | # P2PSIP 168 | E | A | F | +---------+ # Client 169 | | T | | # Protocol 170 +------+ N +------+ # | 171 # A # | 172 NATNATNATNAT # | 173 # # | \__/ 174 NATNATNATNAT +-------+ v / \ 175 # N | |=====/ UA \ 176 +------+ A P2PSIP Overlay | Peer | /Client\ 177 | | T | Q | |___C__| 178 | UA | N | | 179 | Peer | A +-------+ 180 | D | T # 181 | | N # 182 +------+ A # P2PSIP 183 # T # Peer 184 # N +-------+ +-------+ # Protocol 185 # A | | | | # 186 #########T####| Proxy |########| Redir |####### 187 N | Peer | | Peer | 188 A | P | | R | 189 T +-------+ +-------+ 190 | / 191 | SIP / 192 \__/ / / 193 /\ / ______________/ SIP 194 / \/ / 195 / UA \/ 196 /______\ 197 SIP UA A 199 Figure1 P2PSIP Overlay Reference Model 201 P2PSIP client protocol: 203 O Provides a bootstrap mechanism for clients to join the overlay. A 204 centralized bootstrap server mechanism is proposed in this draft. 206 O Provides mechanisms for clients to create, maintain and terminate 207 service relationship with the selected associated peer. 209 O Provides a mechanism for clients to publish/retrieve resource 210 records to/from the overlay through its associated peer. 212 O Provides a mechanism for clients to get candidate associated peers 213 through its now associated peer. Any peer that is willing to be a 214 candidate associated peer advertise its service in the 215 overlay(SEP[I-D. jiang-p2psip-sep] provides a general service 216 advertisement and lookup mechanism). A client sends a 217 LookUpServicePeer request to find its candidate associated peers. 219 O Provides a notification mechanism for a client to choose one best 220 service peer from its multiple associated peers. When a peer or a 221 client changes its status due to some reasons, it must generate a 222 Notify message to its associated client/peer. (Open Issue: Is there 223 a Primary associated Peer among a client's multiple associated peers, 224 a client should get service through this primary peer until it fails? 225 Or it is just the client's local policy to choose which peer to serve 226 him? ). The notification can also be used for other purposes. 228 O If possible and required, provides a mechanism for a peer to store/ 229 retrieve resource records to/from its associated clients. 231 O If possible and required, e.g. there are many clients associated 232 with a same peer and communication among these clients are regular. 233 The peer can store the resource objects that its associated clients 234 published on both itself and the overlay. Then it can resolve many 235 requests from its associated clients locally, and if it can't, it 236 tries to get a result from the overlay. 238 3. Terminology 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [RFC2119]. 244 This section defines some key concepts using in this document. 246 Host Peer: A peer that provides P2PSIP overlay function to clients, 247 it is also called as "associated peer". A client can have more than 248 one host peer. 250 Host Peer Candidate: A peer that has the ability of providing P2PSIP 251 overlay function to clients. A client can learn multiple Host Peer 252 Candidates through a bootstrap server, or through its Host Peer. A 253 client can choose one or more Host Peer Candidate(s) to be its Host 254 Peer(s). It also has the name "candidate host peer", or "candidate 255 associated peer". 257 P2PSIP Overlay Services: Those distributed functions that provided 258 collectively by all peers in the P2PSIP overlay, such as distributed 259 storage function, distributed transport function. 261 Resource Name: A human-friendly name that unique resource, such as 262 URI. 264 The other concepts used in this document are compatible with P2PSIP 265 Work Group Draft "Concepts and Terminology for Peer to Peer SIP" 266 [I-D.ietf-p2psip-concepts]. 268 4. Overview of Protocol 270 4.1. High-level Descriptions 272 From the viewpoint of service provision, P2PSIP client protocol 273 mainly meets three basic requirements: 275 (1).Client-peer relationship maintenance, this protocol should 276 provide mechanisms to maintain service relationship between a client 277 and its host peer; 279 (2).Resource publication and retrieve, this protocol should provide a 280 mechanism for a client to publish/retrieve resource records to/from 281 the overlay through its host peer, a mechanism for a peer to store 282 and retrieve resource records to and from its associated clients; 284 (3).Heterogeneous network support, this protocol should provide a 285 mechanism for a client to learn candidate host peers' capability and 286 status to select one or more appropriate peers as its host peers, a 287 mechanism for a peer to learn its clients' capability (i.e., 288 contributable storage capacity) to enlarge its storage capability. 290 Multiple clients can have the same host peer and one client can also 291 have multiple host peers. One peer can serve more than one client 292 simultaneously, one client can communicate with more than one peer 293 simultaneously to enhance redundancy for service continuity. 295 P2PSIP client protocol is a request-response protocol. Requests from 296 clients are responded with necessary response info by its host peer 297 or any responsible peer in the overlay network. Requests sent 298 directly from a peer to its associated client are responded with 299 required response info by its associated client. Message routing is 300 described in Section 4.3. 302 Host peer candidates for a client are learned from its bootstrap 303 server or through its host peers. 305 A client can provide capability info such as network bandwidth, 306 contributable storage capacity to its host peer. A peer must provide 307 status info (e.g., congestion status info based on CPU utilization) 308 to its clients so that clients can do appropriate actions based upon 309 some policies to guarantee uninterrupted overlay service. 311 4.2. Messages Routing 313 A client sends requests using IP routing directly to its host peer, 314 the host peer returns responses using IP routing directly to the 315 client. The host peer tries to locally resolve the requests if 316 possible; it tries to get the results from the P2PSIP overlay when 317 failed to resolve the requests itself. 319 A client may require that the response from the responsible peer must 320 come back to it via IP routing directly, it can include its contact 321 address such as IP address and port in the request for this purpose. 323 A peer sends out a request using IP routing directly to one client, 324 the client dispose the request and then returns the response using IP 325 routing directly to the host peer. 327 Requests and responses are limited to between a client and its host 328 peer and use IP routing. 330 4.3. Messages Transporting 332 P2PSIP client protocol proposed in this document follows the messages 333 transporting specification defined in the SEP protocol [I-D. jiang- 334 p2psip-sep], e.g. they adopt the same transport layer listening port. 336 4.4. Enrollment and Bootstrap 338 When a client wishes to use the service of the overlay, it must get a 339 client ID from the Enrollment server. And then it must contact the 340 bootstrap server to get some host peer candidates information. It 341 inquire these host peer candidates to choose its host peers and it 342 get the service of the overlay from its host peers. A client can 343 have multiple host peers. Enrollment server and bootstrap server may 344 be collocated in one entity. We just propose this kind of mechanism 345 using centralized server for simplicity. We agree that there are 346 none centralized mechanisms(e.g. mDNS) for the enrollment and 347 bootstrap and they are very useful in the specific application 348 scenarios. 350 The enrollment and bootstrap procedure MUST address two issues. One 351 is to issue a client ID which does not conflict with the existing 352 client ID to the joining client, as for the security considerations, 353 some additional mechanism may be added(e.g. with a signed 354 certificate). The other is to learn candidate host peers information 355 and choose one or more to be the host peer(s). 357 There are some proposed methods are not based on the Bootstrap Server 358 Mechanism. Some of them are listed in the following: 360 (1).Static Locations: Some number of peers in the overlay may be 361 persistent and have well known addresses. These addresses could be 362 configured into the client application or obtained using an out-of- 363 band mechanism such as a web page; 365 (2).Cached Peers: While this mechanism cannot be used when a client 366 runs the first time, on subsequent attempts to join the overlay a 367 client might attempt to use a previously contacted host peer as a 368 host peer candidates; 370 (3).Broadcast/multicast mechanisms: Clients can use a broadcast or 371 another local discovery mechanism to locate the initial peers; 373 (4).DNS: An overlay can list well-known and capable peers in 374 appropriate DNS entries so that current host peers can be located by 375 any client when it wishes to use the overlay's service. DNS-SD 376 bootstrapping mechanism[I-D.garcia-p2psip-dns-sd-bootstrapping] is an 377 example. 379 When a client finds some peers as host peer candidates, it MUST 380 decide which of them to be the host peer(s) through the inquiry 381 result with each host peer candidates. 383 4.5. NAT Traversal 385 In P2PSIP, it is possible that some clients are behind NAT and some 386 peers are behind NAT. 388 If some clients are behind NAT and its host peer is reachable, NAT is 389 not a problem because the client can send requests to the host peer 390 and the response can be sent back through the host peer. 392 If some peers are behind NAT, the problem is how to set up a 393 connection between the client and the NATed host peer. STUN 394 [I-D.ietf-behave-rfc3489bis], TURN [I-D.ietf-behave-turn] and ICE 395 [I-D.ietf-mmusic-ice] can be used to solve this problem. 397 NAT traversal is relevant to network deployment; the implementer may 398 use an Enrollment Server to publish reachable contact info of peers 399 behind NAT. We suggest that peers with global addresses should be 400 preferred as candidate host peers, but peers behind NAT should also 401 be taken into account to ensure enough service peers. 403 4.6. Node Capability 405 The capabilities of host peer obviously impact the QoS of P2PSIP 406 overlay service for its clients. Clients need to learn the 407 capabilities of candidate host peers such as link bandwidth so that 408 the clients choose one or more peers with better capabilities to be 409 its host peers. 411 The capability of a client (i.e., contributable storage capacity) 412 directly impacts its associated peers' decision whether and how to 413 use clients to expand their storage capacity. 415 4.7. Node Status 417 In fact, the most important factor impacting QoS of P2PSIP overlay 418 service for clients is peers' status, such as congestion info, peer- 419 to-overlay connectivity etc. 421 Upon perceiving the service degrading event or the service 422 interruption event of host peer timely, clients can choose other 423 peers as host peers to keep continuous QoS of providing P2PSIP 424 overlay service. 426 5. Packets Formats 428 On packets formats, P2PSIP client protocol follows P2PSIP peer 429 protocol specification, the introduced messages adopt the same 430 message format with existing P2PSIP peer protocol messages, and those 431 message uses the common message header. Different types of messages 432 convey different contents according to the protocol design, and then 433 those different contents are described by different TLV (Type-Length- 434 Value) style objects combinations. Those objects are called as 435 "Attributes". 437 P2PSIP client protocol reuses messages (including format and 438 semantic) defined the P2PSIP peer protocol if possible, extend them 439 and introduce new types of messages if necessary. 441 5.1. Message Header 443 P2PSIP client protocol messages also use a common message header, 444 after which some TLV style attributes follow, as in the P2PSIP peer 445 protocol. 447 P2PSIP client protocol reuses the message header defined in the 448 P2PSIP peer protocol. At the same time it introduces two control 449 flags - 'C' flag and 'E' flag. The message header format is depicted 450 as Figure 2. Please refer to P2PSIP peer protocol [I-D.jiang-p2psip- 451 sep] for the detailed format of message header. 453 0 1 2 3 454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |Version|R|H|D|F|J|C|E|Reserved | Message Type | TTL | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Message Length | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Transaction-ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Source ID = 128bit | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Destination ID = 128bit | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 2 Message Header Format 469 C-flag (1 bit): If it is set, it means that this message is P2PSIP 470 client protocol message; 472 E-flag (1 bit): If it is set, it means that suppressing response 473 message is desirable, for example, a Notify request message from a 474 peer to its client can require the client to suppress response 475 message through setting E flag. 477 Source ID: If the message is generated by a peer, the source ID is 478 filled with the source peer ID, if the message is generated by a 479 client, the source ID is filled with the client ID. 481 This document introduces one new type of message as below: 483 Message Type Name 484 12 Inquire 485 If the message's final destination is the associated peer or client, 486 e.g. it's a Notify message, then the destination ID is filled with 487 the associated peer's ID or associated client's ID. If the message's 488 destination is a peer that responsible for the searched resource 489 object, e.g. it's a Get message generated by a client, then the 490 destination ID is filled with the resource ID of the searched 491 resource object. 493 5.2. Message Attributes 495 As P2PSIP peer protocol, P2PSIP client protocol message contains 496 zero, one or multiple Attributes which describe the specified 497 contents. All attributes follow P2PSIP peer protocol specification 498 and adopt TLV style. Please refer to P2PSIP peer protocol 499 [I-D.jiang-p2psip-sep] for the detailed format of Message Attributes. 501 This document introduces three new types of attributes as below: 503 Attribute Type Name 504 17 Uptime 505 18 Overlay Info 506 19 Security 508 In addition to the newly introduced Client attribute, Security 509 attribute, Uptime attribute and Overlay Info attribute, this document 510 extends the Response attribute, Status attribute, and Service 511 Capability attribute defined in P2PSIP peer protocol specification. 512 Every attribute in SEP peer protocol can also be used in P2PSIP 513 client protocol without change except that its meaning is not limited 514 only to the peer, but adapted to both peer and client. 516 5.2.1. Response Attribute 518 This document extends the Response attribute defined in the P2PSIP 519 peer protocol to describe the result of disposing the P2PSIP client 520 protocol request message. 522 Response attribute format is shown as Figure 3: 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 |M| Reserved |Attribute Type | Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Response code | Response sub-code | 530 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 532 Figure 3 Response Attribute Format 534 M-flag: the value is 1; 536 Reserved (7 bits): those bits are reserved and ignored; 538 Attribute Type (8 bits): the value is 7 (0x07); 540 Length (16 bits): the length in bytes of this attribute; 542 Response Code (16 bits): response code determined by the initiator, 543 this field is necessary for any response attribute; 544 Response Sub-Code (16 bits): response sub-code determined by the 545 initiator, this field is optional for one response attribute. 547 This document introduces new response codes as below: 549 Response Code Meaning 550 404 Authentication Required 551 405 Authentication Failed 552 406 Contributed Space Required 553 407 Not Found 554 408 Request Failed 555 409 Request Rejected 556 410 Join Request Deferred 557 431 Leave Request Deferred 558 432 Overlay Service Interrupt 559 433 Message Too Large 560 434 Unrecognized message type 561 435 Unrecognized object type 562 436 Request Timeout 564 5.2.2. Status Attribute 566 This document extends the Response attribute defined in the P2PSIP 567 peer protocol to describe the status of a peer (e.g., congestion, or 568 overlay service interrupt). 570 Status attribute format is shown as Figure 4: 572 0 1 2 3 573 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |M| Reserved | Type | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Status Code | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 4 Status Attribute Format 582 M-flag: the value is 1; 584 Reserved (7 bits): those bits are reserved and ignored; 586 Attribute Type (8 bits): the value is 12 (0x0C); 588 Length (16 bits): the length in bytes of this attribute; 590 Status Code (16 bits): indicates the current state of a peer. The 591 value 0x00 means that the peer is in good condition; the value 0x01 592 means that the peer is busy. 594 This document introduces a new type of status codes as below: 596 Status Code Meanings 597 2 Overlay Service Interrupt 599 5.2.3. Service Capability 601 This document extends the Peer Service Capability attribute defined 602 in the P2PSIP peer protocol to describe the service capability of a 603 peer or a client (e.g., provide the service of a TURN server, or a 604 client can contribute certain space of storage to the associated peer 605 ). 607 Service capability attribute format is shown as Figure 5: 609 0 1 2 3 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |M| Reserved | Type | Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |N|S|T|H|C| Reserved | Contributable Storage Space | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Contributable Storage Space | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Figure 5 Service Capability attribute Format 621 M-flag: the value is 1; 623 Reserved (7 bits): those bits are reserved and ignored; 625 Attribute Type (8 bits): the value is 0x01; 627 Length (16 bits): the length in bytes of this attribute; 629 N (1 bit): if N flag is set, it means the node is behind NAT. 630 Otherwise the node is on the public Internet. 632 S (1 bit): STUN service. If it is set, it means the peer supports 633 STUN service. 635 T (1 bit): STUN relay service. When it is set, it means the peer 636 supports STUN relay service. 638 H(1 bit): Host peer service. If this bit is set, it means that the 639 peer supports host peer service, it can be chosen as a host peer 640 candidate. 642 C(1 bit): Contributable storage. If it is set, the size of storage 643 space(32bits integer in bytes) that the client can provide to its 644 associated peer is following the reserved field. 646 5.2.4. Uptime Attribute 648 This document introduces a new type of attribute to describe the 649 uptime of a node, this attribute is called as "Uptime attribute", and 650 its format is shown as Figure 6: 652 0 1 2 3 653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |M| Reserved | Type | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Uptime(seconds) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 6 Uptime Attribute Format 662 M-flag: the value is 1; 664 Reserved (7 bits): those bits are reserved and ignored; 666 Attribute Type (8 bits): the value is 17 (0x11); 668 Length (16 bits): the length in bytes of this attribute; 670 Uptime (16 bits): the uptime of the node in seconds. 672 5.2.5. Overlay Info Attribute 674 This document introduces a new type of attribute to describe the 675 information of the overlay network which a peer participates in or a 676 client wants to access, this attribute is called as "Overlay Info 677 attribute", and its format is shown as Figure 7: 679 0 1 2 3 680 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |M| Reserved | Type | Length | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 |Hash algorithm | Overlay ID | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Overlay Name (variable length) | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Figure 7 Overlay Info Attribute Format 691 M-flag: the value is 1; 693 Reserved (7 bits): those bits are reserved and ignored; 695 Attribute Type (8 bits): the value is 18 (0x12); 697 Length (16 bits): the length in bytes of this attribute; 699 Hash algorithm (8 bits): the hash algorithm used by the P2PSIP 700 overlay. The destination ID field of the message is the hashing 701 result of the resource name when the message is used to retrieve a 702 resource object in the overlay. 0x00 is reserved, 0x01 for SHA-1; 704 Overlay ID (24 bits): an identifier that uniquely identifies each 705 P2PSIP overlay network. This value is not human-friendly; 707 Overlay Name: A human-friendly name that identifies a specific P2PSIP 708 Overlay. This is in the format of (a portion of) a URI, but may or 709 may not have a related record in the DNS. This field is optional in 710 an Overlay Info attribute. 712 5.2.6. Security Attribute 714 This document introduces a new type of attribute to describe the 715 security information for a node, this attribute is called as 716 "Security attribute", and its header format is shown as Figure 8: 718 0 1 2 3 719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |M| Reserved | Type | Length | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Figure 8 Security Attribute Header Format 726 M-flag: the value is 1; 728 Reserved (7 bits): those bits are reserved and ignored; 730 Attribute Type (8 bits): the value is 19(0x13); 732 Length (16 bits): the length in bytes of this attribute including its 733 sub attributes. 735 A Security attribute is a composite attribute; it owns some private 736 sub-attribute especially for itself. This document defines several 737 sub-attributes for Security attribute: authentication & crypto type, 738 username, password, challenge. 740 Authentication & Crypto Type Sub-Attribute Format is shown as Figure 741 9: 743 0 1 2 3 744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |M| Reserved | Sub-Type | Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Auth Type | Crypto Type | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 9 Authentication & Crypto Type Sub-Attribute Format 753 M-flag: the value is 1; 755 Reserved (7 bits): those bits are reserved and ignored; 757 Sub-attribute Type (8 bits): the value is 1 (0x01); 759 Length (16 bits): the length in bytes of this sub-attribute; 761 Auth Type (8 bits): authentication type. This document defines two 762 types of authentication: 1 for PAP; 2 for CHAP. The value Zero means 763 that no any authentication is required; 765 Crypto Type (8 bits): crypto algorithm. This document defines 2 766 types of crypto algorithms: 1 for DES, 2 for RC4. The value Zero 767 means that no any crypto algorithm is required and specified. The 768 crypto algorithm is used to encrypt/decrypt the P2PSIP client 769 protocol message over the transport layer. 771 Username Sub-Attribute Format is shown as Figure 10: 773 0 1 2 3 774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 |M| Reserved | Sub-Type | Length | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Username (variable length) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Figure 10 Username Sub-Attribute Format 783 M-flag: the value is 1; 785 Reserved (7 bits): those bits are reserved and ignored; 787 Sub-attribute Type (8 bits): the value is 2 (0x02); 789 Length (16 bits): the length in bytes of this sub-attribute; 791 Username: the human-friendly string which uniquely identifies the 792 P2PSIP client. 794 Password Sub-Attribute is shown as Figure 11: 796 0 1 2 3 797 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 |M| Reserved | Sub-Type | Length | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Password (variable length) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 11 Password Sub-Attribute Format 806 M-flag: the value is 1; 808 Reserved (7 bits): those bits are reserved and ignored; 810 Sub-attribute Type (8 bits): the value is 3 (0x03); 812 Length (16 bits): the length in bytes of this sub-attribute; 813 Password: the human-friendly password of the user. 815 Challenge Sub-Attribute Format is shown as Figure 12: 817 0 1 2 3 818 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |M| Reserved | Sub-Type | Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Challenge (variable length) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Figure 12 Challenge Sub-Object Format 827 M-flag: the value is 1; 829 Reserved (7 bits): those bits are reserved and ignored; 831 Sub-attribute Type (8 bits): the value is 4 (0x04); 833 Length (16 bits): the length in bytes of this sub-attribute; 835 Challenge: a non-human-friendly challenge in binary. 837 6. Messages 839 P2PSIP client protocol reuses Join, Leave, Keep-alive and Notify 840 messages to maintain topology, it reuses Put, Get and Remove messages 841 to operate resource records. It reuses LookUpServicePeer message to 842 look up peers or clients that can provide certain services in the 843 overlay(e.g. STUN server, TURN server, host peer candidates). 844 Besides those messages, it introduces one new type of message - 845 Inquire and some attributes. 847 Each type of message contains the request form and its response form. 848 The request messages are used to require the specified receiver to 849 dispose the specified event or provide the specified info, and the 850 response messages are used to return the initiator the disposal 851 result. 853 6.1. Inquire 855 The introduced Inquire messages are used to request capabilities 856 info, status info and P2PSIP overlay info of candidate host peers. 858 A client must generate one Inquire message to obtain service 859 capabilities info, status info and P2PSIP overlay info of the peer 860 before establishing service relationship between the client and its 861 host peer candidate. 863 Upon the receipt of an Inquire message, the peer returns directly a 864 response message with possible info to the client. 866 An Inquire request message must contain a message header; it may 867 contain a source peer Info attribute and a Security attribute. If 868 the initiator is a client, the "Peer ID" field in the Source Peer 869 Info is actually a Client ID, and other fields are suchlike. 871 Inquire request = Message Header 872 [Source Peer Info Attribute] 873 [Security Attribute] 875 An Inquire response message must contain a message header and a 876 Response attribute; it may contain a Destination Peer Info attribute 877 and a Status attribute. 879 Inquire response = Message Header 880 Response Attribute 881 [Destination Peer Info Attribute] 882 [Status Attribute] 884 6.2. Join 886 In this document, Join messages are reused to create service 887 relationship with the selected host peer. 889 After obtaining interesting info of candidate host peers by Inquire 890 messages, a client choose one or more peers as host peers according 891 to local policy such as capabilities of candidate host peers, 892 response delay of candidate host peers, then it structures and sends 893 out a Join message to the selected peer to setup service 894 relationship. 896 Upon the receipt of a Join message without any required 897 authentication info from a client, the peer may return a Join 898 response message with the response code "405 Authentication Required" 899 to require authentication info from the client, the response message 900 uses a Security attribute to indicate specified authentication type. 902 Upon the receipt of a Join message without the required contributable 903 storage info from a client, the peer may return a Join response 904 message with the response code "406 Contributed Space Required" to 905 require contributable storage capacity from the client. 907 Upon the receipt of a Join message, the peer may return a Join 908 response message with the response code "410 Join Request Deferred" 909 when the peer finds itself busy or considers other causes. 911 A client must provide the required authentication info in the 912 following Join message according to the received Security attribute 913 in the response message with the response code 405. 915 A client must provide contributable storage capacity info in the 916 following Join message according to the received response message 917 with the response code 406. 919 A client may resend another Join message after the specified interval 920 according to the received response message with the response code 921 410. 923 After receiving a Join message from a client, the peer returns a Join 924 response message with the response code "200 OK" when the peer is 925 ready to serve the client. 927 A Join request message must contain a message header and a Source 928 Peer Info attribute; it may contain a Security attribute and an 929 Overlay Info Attribute. 931 Join request = Message Header 932 Source Peer Info Attribute 933 [Security Attribute] 934 [Overlay Info Attribute] 936 A Join response message must contain a message header and a Response 937 attribute; it may contain a Destination Peer Info attribute. 939 Join response = Message Header 940 Response Attribute 941 [Destination Peer Info Attribute] 943 6.3. Keep-alive 945 In this document, Keep-alive messages are sent out periodically to 946 check the availability for a client and its host peers, especially 947 when one or more nodes are behind NAT. Certainly any other P2PSIP 948 client messages can be used to check the availability, the keep-alive 949 timer between two immediate nodes (i.e., a client and its host peer) 950 can be heuristics. 952 A Keep-alive request message must contain a message header; it may 953 contain a Status attribute and a Source Peer Info attribute. 955 Keep-alive request = Message Header 956 [Status Attribute] 957 [Source Peer Info Attribute] 959 A Keep-alive response message must contain a message header; it may 960 contain a Status attribute a Destination Peer Info attribute. 962 Keep-alive response = Message Header 963 [Status Attribute] 964 [Destination Peer Info Attribute] 966 6.4. Notify 968 In this document, Notify messages are reused to announce the host 969 peer's event such as the congestion event or the overlay connection 970 unexpected disruption event. 972 A client concerns about the continuity and quality of P2PSIP overlay 973 service provided by its host peer. A client may access multiple 974 peers to enhance redundancy of P2PSIP overlay service, and at the 975 same time a client expresses implicitly its interest in monitoring 976 the status of P2PSIP overlay service provided by its host peer 977 through a Join message. After a client joins the overlay, the 978 associated peer monitors its service status for this client. When 979 the peer finds that the service status changes (e.g. congested or its 980 overlay connection disrupted by itself or others), the peer sends out 981 a Notify message to tell its client the service status change (e.g. 982 service degradation due to the congestion or the service interruption 983 due to the disconnection from the overlay network), the client then 984 choose other appropriate peers as host peers to avoid impacting 985 negatively the continuity and quality of P2PSIP overlay service. 987 A Notify request may indicate that the response is suppressed. 989 A Notify request must contain a message header and a Status 990 attribute. 992 Notify request = Message Header 993 Status Attribute 995 A Notify response message must contain a message header and a 996 Response attribute. 998 Notify response = Message Header 999 Response Attribute 1001 6.5. Leave 1003 In this document, Leave message are reused to tell the host peer that 1004 the client wants to terminate the service relationship between the 1005 client and the peer. 1007 Before sending out a Leave message, a client may use Remove messages 1008 to remove the published resource records by itself through the host 1009 peer. 1011 The host peer returns a Leave response message with the response code 1012 "200 OK" if it is ready for the client's leave. If the client 1013 contributes its storage space to the host peer, the host peer need 1014 retrieve those resource records stored in the contributed storage 1015 space of the client before the client leave. 1017 Upon the receipt of a Leave response message with the response code 1018 "409 Leave Request Deferred", the client may resend out another Leave 1019 message after some time. 1021 A Leave request message must contain a message header; it may contain 1022 a Source Peer Info attribute. 1024 Leave request = Message Header 1025 [Source Peer Info Attribute] 1027 A Leave response message must contain a message header and a Response 1028 attribute. 1030 Leave response = Message Header 1031 Response Attribute 1033 6.6. Put 1035 In this document, Put messages are used to insert and modify resource 1036 records between a client and its host peer. 1038 A client uses Put messages to insert and modify the resource records 1039 through its host peer. A peer uses Put messages to transfer resource 1040 records to the client, update the transferred resource records on the 1041 client. 1043 The resource records should be deleted when it expires. 1045 A host peer may locally cache the resource records published by its 1046 clients, and then the host peer prefers locating the resource records 1047 first locally on itself than in the overlay when receiving the 1048 consequent requests for the resource records from its other clients, 1049 at last the host peer returns the requested resource records within 1050 the response messages, it is more effective especially for local 1051 communication between clients served by the same host peer. 1053 A Put request message must contain a message header and a Resource 1054 Info attribute. It may contain a Source Peer Info attribute. 1056 Put request = Message Header 1057 Resource Info Attribute 1058 [Source Peer Info Attribute] 1059 [Destination Info Attribute] 1061 A Put response message must contain a message header and a Response 1062 attribute. 1064 Put response = Message Header 1065 Response Attribute 1067 6.7. Remove 1069 In this document, Remove messages are used to remove resource records 1070 between a client and its host peer. 1072 A client uses Remove messages to remove the resource records through 1073 its host peer. A peer uses Remove messages to remove resource 1074 records to the client. 1076 A Remove message should remove cached resource records published by 1077 clients on a peer. 1079 A Remove request message must contain a message header and a Resource 1080 Info attribute. It may contain a Source Peer Info attribute. 1082 Remove request = Message Header 1083 Resource Info Attribute 1084 [Source Peer Info Attribute] 1086 A Remove response message must contain a message header and a 1087 Response attribute. 1089 Remove response = Message Header 1090 Response Attribute 1092 6.8. Get 1094 In this document, Get messages are reused to retrieve the specified 1095 resource records. 1097 A client uses Get messages to obtain the specified resource record 1098 from the P2PSIP overlay through the host peer. A peer uses Get 1099 messages to obtain the specified resource record from its clients. 1101 A Get request message must contain a message header and a Resource 1102 Info attribute. It may contain a Source Peer Info attribute. 1104 Get request = Message Header 1105 Resource Info Attribute 1106 [Source Peer Info Attribute] 1108 A Get response message must contain a message header, a Response 1109 attribute and a Resource Info attribute. 1111 Get response = Message Header 1112 Response Attribute 1113 Resource Info Attribute 1115 6.9. LookUpServicePeer 1117 As the SEP peer protocol, a client sends a LookUpServicePeer request 1118 to its associated peer to lookup peers that have the certain service 1119 capability in the overlay, e.g. STUN server, TURN server and so on. 1120 A client can also get its host peer candidates with this request. 1122 A LookUpServicePeer request must contain a message header and a 1123 Service Peer Info attribute. 1125 LookUpServicePeer Request = Message Header 1126 Service Peer Info 1127 Source Peer Info 1129 A LookUpServicePeer response must contain a message header and a 1130 Source Peer Info. If service peers are found in the overlay, the 1131 result is returned to the source peer with a Service Peer Info 1132 attribute. 1134 LookUpServicePeer Response = Message Header 1135 Source Peer Info 1136 [Service Peer Info] 1138 7. Contribute Storage Capacity 1140 Some strong P2PSIP clients may be able and willing to share storage 1141 pressure for its host peer, but those clients do not run distributed 1142 database algorithm, they only simply contribute their storage 1143 capacity for host peers. 1145 When a client joins its host peer, the client tells the peer its 1146 contributable storage capacity in the Join message. If a Join 1147 message does not carry this info, the peer can return a Join response 1148 message with the response code "406 Contributed Space Requested" to 1149 require this info in the following Join message. 1151 A peer uses Put message to store resource records into its clients; 1152 the clients return results with Put response messages. 1154 A peer uses Resource-ID through Get messages to retrieve resource 1155 records from its clients; the clients return results with Get 1156 response messages. 1158 8. Acknowledgments 1160 Some of the consideration in the draft came from the discussion in 1161 the P2PSIP mailing list. Thanks to Spencer Dawkins, Victor Pascual. 1163 9. Security Considerations 1165 We can't complete all security considerations section in this 1166 revision, but in at least some application scenarios, client 1167 vulnerability to peers would be of concern to a network operator, and 1168 the current version focuses on peer vulnerabilities to clients. 1170 Currently those threats from clients mainly include: 1172 (1).DoS Attack 1174 DoS attack appears on the host peer when malicious clients send out 1175 Inquire or Join messages to the host peer simultaneously. It may be 1176 weakened using some enrollment control, but there is no any efficient 1177 method to resolve it. 1179 (2).Cheat Attack 1181 Cheat attack appears on the host peer when malicious clients 1182 counterfeit authenticated clients. One method to resolve this 1183 problem is to use encryption to keep communication privacy. 1185 10. IANA Considerations 1187 Message Type: this document introduces a new type of message as 1188 below: 1190 Message Type Name 1191 12 Inquire 1193 Attribute Type: this document introduces two new types of attributes 1194 as below: 1196 Attribute Type Name 1197 17 Uptime 1198 18 Overlay Info 1199 19 Security 1201 Response Code: this document introduces some new response definitions 1202 as below: 1204 Response Code Name 1205 404 Authentication Required 1206 405 Authentication Failed 1207 406 Contributed Space Required 1208 407 Not Found 1209 408 Request Failed 1210 409 Request Rejected 1211 410 Join Request Deferred 1212 431 Leave Request Deferred 1213 432 Overlay Service Interrupt 1214 433 Message Too Large 1215 434 Unrecognized message type 1216 435 Unrecognized object type 1217 436 Request Timeout 1219 11. Appendix 1221 Here is a sample of P2PSIP client protocol, depicted as Figure 13. 1223 Client-1 Peer-1 Peer-2 Peer-3 1224 | | | | 1225 | (1).Inquire | | | 1226 |------------------->| | | 1227 | | (2).Inquire | | 1228 |--------------------|-------------------->| | 1229 | | | | 1230 | (3).Response w/200 | | | 1231 |<-------------------| | | 1232 | | (4).Response w/200 | | 1233 |<-------------------|---------------------| | 1234 | | | | 1235 | | (5).Join | | 1236 |--------------------|-------------------->| | 1237 | | (6).Response w/404 | | 1238 |<-------------------|---------------------| | 1239 | | | | 1240 | | (7).Join | | 1241 |--------------------|-------------------->| | 1242 | | (8).Response w/200 | | 1243 |<-------------------|---------------------| | 1244 | | | | 1245 | | (9).Put | | 1246 |--------------------|-------------------->| | 1247 | | | (10).Put | 1248 | | |-------------------->| 1249 | | | (11).Response w/200 | 1250 | | |<--------------------| 1251 | | (12).Response w/200 | | 1252 |<-------------------|---------------------| | 1253 | | | | 1254 | | (13).Get | | 1255 |--------------------|-------------------->| | 1256 | | (14).Get | | 1257 | |<--------------------| | 1258 | | (15).Response w/200 | | 1259 | |-------------------->| | 1260 | | (16).Response w/200 | | 1261 |<-------------------|---------------------| | 1262 | | | | 1263 | | (17).Keep-alive | | 1264 |--------------------|-------------------->| | 1265 | | (18).Response w/200 | | 1266 |<-------------------|---------------------| | 1267 | | | | 1268 | | (19).Keep-alive | | 1269 |--------------------|-------------------->| | 1270 | | (20).Response w/200 | | 1271 |<-------------------|---------------------| | 1272 | | | | 1273 | | (Congest) | 1274 | | (21).Notify | | 1275 |<-------------------|---------------------| | 1276 | | (22).Response w/200 | | 1277 |--------------------|-------------------->| | 1278 | (23).Join | | | 1279 |------------------->| | | 1280 |(24).Response w/404 | | | 1281 |<-------------------| | | 1282 | (25).Join | | | 1283 |------------------->| | | 1284 |(26).Response w/200 | | | 1285 |<-------------------| | | 1286 | | | | 1288 Figure 13 P2PSIP Client Protocol Sample 1290 12. References 1292 12.1. Normative References 1294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1295 Requirement Levels", BCP 14, RFC 2119, March 1997. 1297 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1298 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1299 Session Initiation Protocol", RFC 3261, June 2002. 1301 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1302 Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. 1304 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1305 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 1306 2005. 1308 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 1309 of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, 1310 May 2006. 1312 [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R., 1313 and D. Wing, "Simple Traversal Underneath Network Address Translators 1314 (NAT) (STUN)", draft-ietf-behave- rfc3489bis-08 (work in progress), 1315 July 2007. 1317 [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for 1318 Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress), 1319 June 2007. 1321 [I-D.pascual-p2psip-clients] Pascual, V., "P2PSIP Clients", 1322 draft-pascual-p2psip-clients-01 (work in progress), February 2008. 1324 [I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer 1325 Protocol", draft-jiang-p2psip-sep-00 (work in progress), November 1326 2007. 1328 [I-D.garcia-p2psip-dns-sd-bootstrapping], "P2PSIP bootstrapping using 1329 DNS-SD", draft-garcia-p2psip-dns-sd-bootstrapping-00(work in 1330 progress), October 2007. 1332 [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and C. Huitema, 1333 "Obtaining Relay Addresses from Simple Traversal Underneath NAT 1334 (STUN)", draft-ietf-behave-turn-04 (work in progress), July 2007. 1336 [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity 1337 Establishment (ICE): A Methodology for Network Address Translator 1338 (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-17 1339 (work in progress), July 2007 1341 [I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework 1342 and Requirements", draft-bryan-p2psip-requirements-00 (work in 1343 progress), July 2007 1345 [P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and 1346 Terminology", 1347 http://www3.ietf.org/proceedings/07jul/slides/p2psip-13.pdf, July 1348 2007 1350 12.2. Informative References 1352 [I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP 1353 Registration and Resource Location", draft-bryan-p2psip-dsip-00 (work 1354 in progress), February 2007. 1356 [I-D.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery 1357 (RELOAD)", draft-bryan-p2psip-reload-00 (work in progress), June 1358 2007. 1360 [I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)", 1361 draft-baset-p2psip-p2pp-00 (work in progress), July 2007. 1363 [I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to 1364 Peer", draft-jennings-p2psip-asp-00 (work in progress), July 2007. 1366 [I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP 1367 Extensions for Implementing a Passive P2PSIP Overlay Network based on 1368 the CAN Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00 1369 (work in progress), June 2007. 1371 [I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport 1372 Function in P2PSIP using HIP for Multi-Hop Overlay Routing", 1373 draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. 1375 Authors' Addresses 1377 Song Yongchao 1378 Huawei 1379 Baixia Road No. 91 1380 Nanjing, Jiangsu Province 210001 1381 P.R.China 1383 Phone: +86-25-84565081 1384 Fax: +86-25-84565070 1385 Email: melodysong@huawei.com 1387 Jiang Xingfeng 1388 Huawei 1389 Baixia Road No. 91 1390 Nanjing, Jiangsu Province 210001 1391 P.R.China 1393 Phone: +86-25-84565079 1394 Fax: +86-25-84565070 1395 Email: jiang.x.f@huawei.com 1397 Zheng Hewen 1398 Huawei 1399 Baixia Road No. 91 1400 Nanjing, Jiangsu Province 210001 1401 P.R.China 1403 Phone: +86-25-84565467 1404 Fax: +86-25-84565354 1405 Email: hwzheng@huawei.com 1406 Hui Deng 1407 China Mobile 1408 53A, Xibianmennei Ave. Xuanwu District 1409 Beijing 100053 1410 P.R.China 1412 Email: denghui@chinamobile.com 1414 Full Copyright Statement 1416 Copyright (C) The IETF Trust (2008). 1418 This document is subject to the rights, licenses and restrictions 1419 contained in BCP 78, and except as set forth therein, the authors 1420 retain all their rights. 1422 This document and the information contained herein are provided on an 1423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1425 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1426 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1427 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1430 Intellectual Property 1432 The IETF takes no position regarding the validity or scope of any 1433 Intellectual Property Rights or other rights that might be claimed to 1434 pertain to the implementation or use of the technology described in 1435 this document or the extent to which any license under such rights 1436 might or might not be available; nor does it represent that it has 1437 made any independent effort to identify any such rights. Information 1438 on the procedures with respect to rights in RFC documents can be 1439 found in BCP 78 and BCP 79. 1441 Copies of IPR disclosures made to the IETF Secretariat and any 1442 assurances of licenses to be made available, or the result of an 1443 attempt made to obtain a general license or permission for the use of 1444 such proprietary rights by implementers or users of this 1445 specification can be obtained from the IETF on-line IPR repository at 1446 http://www.ietf.org/ipr. 1448 The IETF invites any interested party to bring to its attention any 1449 copyrights, patents or patent applications, or other proprietary 1450 rights that may cover technology that may be required to implement 1451 this standard. Please address the information to the IETF at 1452 ietf-ipr@ietf.org.