idnits 2.17.1 draft-jiang-p2psip-sep-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 2021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2045. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: KEEPALIVE message is used by a peer to make sure whether the neighbor peers are still alive. If a peer has not received KEEPALIVE response from the destination peer for several times, it could conclude that the destination peer is not alive and then should start to update its routing or neighbor table. After receiving KEEPALVIE request, the destination peer MUST convey its status information in the KEEPALVIE response. If a peer has received a KEEPALIVE message with a peer's current status which shows this peer is in the busy state, the peer SHOULD not forward packets to that congested peer until that peer reaches the normal state again. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The source peer MUST insert a Service Peer Info attribute in the request to collect service peers whose types may be STUN, STUN relay, etc, and send it to the destination peer by choosing a given destination ID. The source peer should specify the maximum number of service peers in the request. If the number of peers reaches the maximum number, the successive intermediate peer or destination peer won't need to find satisfied peers. In the resulting Service Peer Info attribute, none of the peer has the same Peer-ID attribute. If the successive intermediate peer or the destination peer finds the service peer has already been in the Service Peer Info attribute, they MUST not be put into the Service Peer info attribute. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. The Source Peer, Destination ID, message type and the transaction ID MUST not be changed in the response. These fields should be kept the same as the request. 2. Response Attribute MUST be included in the response; 3. Destination Peer Info MUST be included in the response. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 167 == Missing Reference: 'EVENT' is mentioned on line 1275, but not defined == Missing Reference: 'STATUS INFO' is mentioned on line 1275, but not defined == Missing Reference: 'Routing-table' is mentioned on line 1323, but not defined == Unused Reference: 'RFC3261' is defined on line 1944, but no explicit reference was found in the text == Unused Reference: 'Concept' is defined on line 1953, but no explicit reference was found in the text == Unused Reference: 'TURN' is defined on line 1961, but no explicit reference was found in the text == 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. 'Concept') Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP XingFeng. Jiang 3 Internet-Draft HeWen. Zheng 4 Intended status: Standards Track Huawei Tech. 5 Expires: August 4, 2008 C. Macian 6 V. Pascual 7 Pompeu Fabra University 8 February 1, 2008 10 Service Extensible P2P Peer Protocol 11 draft-jiang-p2psip-sep-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 4, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes the Service Extensible Protocol (SEP), which 45 is the peer protocol spoken between P2PSIP Overlay peers to share 46 information and organize the P2PSIP Overlay Network. SEP uses a 47 flexible forwarding mechanism to avoid congestion in the Overlay. It 48 also proposes a general service discovery method and a built-in NAT 49 traversal mechanism. By using these methods, SEP tries to improve 50 the success rate and reduce the latency of the transaction. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Routing States . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2. Data Operations . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Data Transfer During the Overlay Churn . . . . . . . . . . 7 60 4. Design Choice . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 8 62 4.2. Relaying Peer . . . . . . . . . . . . . . . . . . . . . . 10 63 4.2.1. Cases in which Relaying Peers Help . . . . . . . . . . 10 64 4.2.2. Locating Relaying Peer . . . . . . . . . . . . . . . 10 65 4.2.3. How to Use Relaying Peer . . . . . . . . . . . . . . . 11 66 4.3. Routing Mode . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. Flexible Routing Mechanism . . . . . . . . . . . . . . . . 12 68 4.5. End-to-end Reliability . . . . . . . . . . . . . . . . . . 12 69 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 14 71 5.2. Message Attribute . . . . . . . . . . . . . . . . . . . . 15 72 5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . 15 73 5.2.2. Peer Address Info . . . . . . . . . . . . . . . . . . 15 74 5.2.3. Peer service capability . . . . . . . . . . . . . . . 16 75 5.2.4. Peer-ID . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.2.5. Source Peer Info . . . . . . . . . . . . . . . . . . . 17 77 5.2.6. Destination Peer Info . . . . . . . . . . . . . . . . 18 78 5.2.7. Resource Info . . . . . . . . . . . . . . . . . . . . 18 79 5.2.8. Negotiation Info . . . . . . . . . . . . . . . . . . . 20 80 5.2.9. Response Attribute . . . . . . . . . . . . . . . . . . 20 81 5.2.10. Service Peer Info . . . . . . . . . . . . . . . . . . 20 82 5.2.11. Relaying Peer Info . . . . . . . . . . . . . . . . . . 22 83 5.2.12. Source Reflexive Address attribute . . . . . . . . . . 22 84 5.2.13. Routing table . . . . . . . . . . . . . . . . . . . . 23 85 5.2.14. Status Info . . . . . . . . . . . . . . . . . . . . . 23 86 5.2.15. Event Info . . . . . . . . . . . . . . . . . . . . . . 23 87 5.2.16. Update Type . . . . . . . . . . . . . . . . . . . . . 24 88 5.2.17. Overlay Configuration Info . . . . . . . . . . . . . . 24 89 6. Peer Protocol Message . . . . . . . . . . . . . . . . . . . . 25 90 6.1. Overlay Maintenance . . . . . . . . . . . . . . . . . . . 25 91 6.1.1. JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 6.1.2. LEAVE . . . . . . . . . . . . . . . . . . . . . . . . 27 93 6.1.3. KEEPALIVE . . . . . . . . . . . . . . . . . . . . . . 28 94 6.1.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 29 95 6.1.5. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 29 96 6.1.6. SearchPeer . . . . . . . . . . . . . . . . . . . . . . 30 97 6.1.7. TRANSFER . . . . . . . . . . . . . . . . . . . . . . . 31 98 6.2. Data Operations . . . . . . . . . . . . . . . . . . . . . 31 99 6.2.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 6.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 6.2.3. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . 33 102 6.3. Additional messages . . . . . . . . . . . . . . . . . . . 33 103 6.3.1. LookUpServicePeer . . . . . . . . . . . . . . . . . . 33 104 7. Routing Operations . . . . . . . . . . . . . . . . . . . . . . 35 105 7.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 35 106 7.2. Response Routing . . . . . . . . . . . . . . . . . . . . . 36 107 7.2.1. Response Routing on the Destination Peer . . . . . . . 36 108 7.2.2. Response Routing on the Intermediate Peer . . . . . . 36 109 8. General Peer Behavior . . . . . . . . . . . . . . . . . . . . 37 110 8.1. Source Peer Behavior . . . . . . . . . . . . . . . . . . . 37 111 8.1.1. Generating the Request and Sending the Request . . . . 37 112 8.1.2. Processing the Response . . . . . . . . . . . . . . . 38 113 8.2. Intermediate Peer Behavior . . . . . . . . . . . . . . . . 39 114 8.2.1. Request Processing . . . . . . . . . . . . . . . . . . 39 115 8.2.2. Response Processing . . . . . . . . . . . . . . . . . 39 116 8.3. Destination Peer Behavior . . . . . . . . . . . . . . . . 40 117 8.3.1. Request Processing . . . . . . . . . . . . . . . . . . 40 118 8.3.2. Response Generation and Sending the Response . . . . . 40 119 9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 40 120 9.1. Gather ICE candidates . . . . . . . . . . . . . . . . . . 41 121 9.2. Response from the Destination Peer to the Source Peer . . 42 122 9.2.1. How to Make JOIN Response Return to Source Peer . . . 42 123 9.3. Exchange Candidates for the Direct Communication . . . . . 43 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 125 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 126 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 128 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 129 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 131 Intellectual Property and Copyright Statements . . . . . . . . . . 46 133 1. Introduction 135 This document proposes a Service Extensible Protocol (SEP), which is 136 spoken between P2PSIP peers. The SEP conforms to the definition of 137 P2PSIP Peer protocol in [concept]. Like the definition, SEP not only 138 maintains the P2PSIP overlay topology, but also provides distributed 139 database service. 141 1. SEP uses a flexible packet forwarding mechanism so that peers 142 could choose the best peer to route the packet further. For 143 example, if a peer selects a downstream peer which has no enough 144 resource at that time, then the requests may be discarded by the 145 downstream peer. So the upstream peer could choose another 146 downstream peer which is in good condition. 147 2. In P2PSIP, peers offer storage and transport services to allow 148 the distributed database function and distributed transport 149 function to be implemented. It is expected that individual peers 150 may also offer other services. SEP provides a common method for 151 service discovery, i.e. to discover which peers could provide a 152 specific service. Some of these additional services (for 153 example, a STUN server [STUN]) may be required to allow the 154 overlay to form and operate, while others (for example, a 155 voicemail service) may be enhancements to the basic P2PSIP 156 functionality [concept]. 157 3. The routing modes taken by the SEP attempts to make the 158 transaction with lower latency and higher success rate even if 159 the intermediate peers fail or NATs are between the source and 160 the destination peers. 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [1]. 168 Some of the terminologies are borrowed from the [concept]. 170 O Routing states: it is a general description of the information used 171 to route packets through the overlay. Several kinds of routing 172 states exist. Routing table and neighbor table are two examples. 174 O Service peer: peers who provide one or more services in addition to 175 routing and storage service. 177 O Public peer: peers who are on the public Internet. In case P2PSIP 178 system uses a private addressing scheme, the address realm is also 179 considered public if the peers in the realm could be reached by any 180 other peer. 182 O Upstream peer/downstream peer: they are paired with each other. 183 Downstream peers often appear in the routing states of a upstream 184 peer and receives packets from upstream peer directly. 186 O Transaction: a transaction is initiated by the source peer and 187 comprises a request and several responses. Transaction is an end-to- 188 end concept and is uniquely identified by the tuple, including a 189 source peer-ID, a destination ID, a message type, transaction ID 190 (chosen by the source peer). 192 O Relaying peer: peers are willing to relay response destined to the 193 source peer of the request. One example of relaying peers is a peer 194 which is located on the public Internet and could be directly reached 195 by any peer without any prior negotiations between them so long as 196 other peers have the relay peer's transport address. 198 O Dialog: is a peer-to-peer long-term relationship between two peers 199 and is uniquely identified by a dialog identifier. It represents a 200 context that facilitates the sequencing of messages (i.e. maintain 201 states) between the peers and proper routing of requests between both 202 of them. Not all peer protocol requests create dialogs. The 203 requests that create the dialogs need well-defined mechanisms of 204 establishing and tearing down the dialog. An example of a dialog may 205 be the long-term relationship between a peer X and its replica Y. 206 Peer X is a responsible peer which has several replicas (Peers which 207 are responsible for maintaining and storing the same information) 208 within the overlay. Peer X may establish a long-term relationship 209 (i.e. one dialog) with each replica and may need to maintain their 210 information and state. When a replica Y decides to stop serving as 211 such or Peer X decides to leave the overlay, the dialog should be 212 torn down. Other example may be when a peer joins or (gracefully) 213 leaves the P2P overlay network, data transfer operations will be 214 triggered. The joining peer will be responsible for some pairs and the leaving node SHOULD transfer its stored pairs to its neighbors. When several transfer transactions 217 take place between two nodes a dialog may be established to keep 218 control over the status of the relationship. 220 3. Overview 222 Each peer in the overlay keeps its own routing states, including a 223 routing table, a neighbor table or other states which are maintained 224 by the DHT algorithms. According to the DHT algorithms, the peer 225 must learn other peers' information and communicate with them. So 226 the routing states not only keep the network reachability information 227 of its downstream peers, but can also be extended to store other 228 information of its downstream peers, for example, service capability, 229 processing status, etc. 231 Peers with heterogeneous capability make up of the P2PSIP overlay. 232 SEP attempts to benefit from the heterogeneity among the peers and 233 mitigates the bad effect resulting from it at the same time. Some 234 peers could provide other service in addition to the routing and 235 storage service which are the required services for peers. These 236 additional services include STUN, STUN Relay, etc, which are needed 237 by other peers, for example, which are behind the NAT. In terms of 238 processing resource, such as bandwidth, CPU cycles, they are also 239 heterogeneous. This kind of heterogeneity may make the less powerful 240 peer congested by the messages from the more powerful peers and fail 241 the transactions processed by the congested peers. In this case, a 242 simple flow control mechanism between immediate peers combined with a 243 flexible forwarding mechanism would make the situation better. 245 The communication between peers may not work in the presence of the 246 NAT. The IETF has developed the STUN/TURN/ICE protocols to address 247 this problem. SEP works with these proposals and also provides a 248 relay peers to facilitate the NAT traversal. 250 3.1. Routing States 252 Each peer should maintain routing states and route packets by 253 choosing the next hop peer from the routing states. The routing 254 states should be updated as the overlay topology changes. Here, we 255 give an example data organization of routing states, and explain each 256 item in the entry. Although this is an implementation issue, 257 comprehension on the routing states will make reader understand SEP 258 easier. 260 In current DHT algorithms, there are often two kinds of routing 261 states: routing table and neighbor table. Routing table is often 262 asymmetric and neighbor table is symmetric. Peers in the routing 263 states are also called P2PSIP neighbors defined in the [concept]. It 264 means the peer could reach these peers directly without further 265 lookup. 267 The routing states are often comprised of several entries. Each 268 entry keeps the information about the P2PSIP neighbors. The 269 information about the P2PSIP neighbors might be organized as follows. 271 O Peer-ID: which uniquely identifies a peer in the overlay. 273 O Workable candidate pairs: this item records several candidate pairs 274 which are found by using ICE procedure. By using them, peers could 275 communicate with its neighbors directly. Two or more workable 276 candidate pairs could improve the stability of the P2PSIP peer 277 control connection. 279 O Current processing status: this item reflects the processing status 280 of the peer's neighbors. The possible status may be simply 281 classified into normal or busy. They also may be measured by some 282 quantitative parameters, such as CPU idle percentage, available 283 bandwidth, etc. 285 O Service capability: it gives information about additional services 286 supported by the peer. Having this kind of information in mind, the 287 peer learns which neighbors could provide a specific service. 289 Note: here, we just list some basic items of the information about 290 the P2PSIP neighbors. This information is not exhaustive and will be 291 extended to support new functions if needed. 293 3.2. Data Operations 295 A peer may put multiple resource objects in the overlay under the 296 same resource ID, and some peers may put various resource objects 297 with the same resource ID. Therefore, there may be multiple resource 298 objects under the same resource ID. SEP uses the owner identity and 299 hash code accompanied with resource ID to locate the unique resource 300 object. 302 A resource object in the P2P overlay network can be any type of data, 303 such as a contact address, a file, etc. The size varies from one 304 resource object to another. Resource objects with small size can 305 directly be put to or got from the overlay by carrying them in the 306 PUT or GET message. If the size is over some limit, it's more 307 efficient to exchange the resource object using a direct connection. 308 SEP supports both kinds of operation. Negotiation information is put 309 into the PUT or GET message to negotiate a direct data transport for 310 the latter. 312 The resource objects should be transferred from one peer to another 313 when the overlay churns. But the sending peer may not be aware of 314 the state of the receiving peer, and whether the receiving peer is 315 really responsible for the pairs to be transferred. SEP 316 provides a TRANSFER operation with negotiation capability to solve 317 these problems. 319 3.3. Data Transfer During the Overlay Churn 321 In P2P overlay, peers can join and leave the overlay at any time. 322 Therefore two operations of data moving and routing states update 323 should be performed accordingly. During the churn, some data may be 324 placed on the wrong peer because the two operations can't keep pace 325 with each other. In the meantime, a lookup operation for a key may 326 fail in that the data associated with the key is not on the correct 327 root peer. 329 SEP attempts to reduce the failure possibility of the transaction 330 during the overlay churn. The idea is to make the joining peer or 331 leaving peer work together with its neighbors to serve the coming 332 lookup operations. For example, when a peer is about to leave the 333 network, it could transfer pairs to its neighbors and 334 notify other peers its departure simultaneously. Before the transfer 335 completes, both the leaving peer and its neighbors may be the target 336 of the lookup operation due to routing states update in other peers. 337 So they could serve the lookup operation together by leading the 338 requests to which if they have no answer to the others. 340 4. Design Choice 342 In this section, some considerations about the SEP's design are 343 presented. The principle behind the design is to make the 344 transaction with shorter latency and higher success rate even in the 345 environment where peers churn frequently and some peers may be 346 overloaded by traffic. So we choose the semi-recursive routing mode 347 combined with overlay native routing mode and propose a flexible 348 forwarding mechanism to avoid the congestion in the overlay. Other 349 design choices such as end-to-end reliability and service discovery 350 are also discussed in this section. 352 4.1. Service Discovery 354 The nature of peer-to-peer computing is that each peer offers 355 services to other peers to allow the overlay to collectively provide 356 larger functions [concept]. For example, routing and storage service 357 provided by each peer enable the distributed database function of the 358 overlay, where any peer may store any data under a key and any other 359 peer may fetch it using the same key. Since there exists 360 heterogeneity in peers' capabilities, as pointed out by the 361 descriptions in section 2.1 of [concept], some additional services 362 other than routing and storage will be needed. Thus, two kind of 363 services may exist: those well-known and common in most overlays and 364 required to allow the overlay to form and operate (for example, a 365 STUN server [rfc3489bis]), and others which are enhancements to the 366 basic P2PSIP functionality (for example, a voicemail service) and are 367 specific for a given overlay. In both cases, service discovery 368 procedures are required in order to discover services and their 369 operation. SEP proposes three methods to do the service discovery, 370 i.e. service search based on well-known service names, random walk 371 through the overlay and neighbors' service publication. 373 The first method consists on performing a regular overlay search 374 based on the well-known Resource ID of a given service. To that end, 375 the responsible node must have previously published (i.e., PUT) the 376 Resource ID in the overlay.The second one, random walk through the 377 overlay, tries to get the Peer ID of the responsible service peers by 378 walking hop-by-hop through the ovelay and getting information 379 provided by intermediate peers until one peer gives a response. In 380 the last method, each peer's routing state intends to store its 381 neighbors' service capabilities, i.e. which kinds of service its 382 neighbors could provide. Then, the service capability information is 383 advertised through the overlay maintenance mechanism as is described 384 in section 3.1. 386 SEP provides a message LookUpServicePeer for the peer to attempt to 387 collect the service peers providing a non-well-known service by 388 walking through the overlay. The peer in need of a specific service 389 will send a LookUpServicePeer message in which the service taxonomy 390 type is indicated and the destination ID could be chosen at random. 391 Then the intermediate peers receiving the message will check whether 392 there are peers in its routing states providing the desired service. 393 If there is at least one peer, the intermediate peer would insert the 394 information in the request and route the request further. In the 395 end, the destination peer will return the information to the source 396 peer in the response. So, the service discovery is made by randomly 397 routing the packet through the overlay. The source peer could try 398 different destination IDs and make sure to get more service peers' 399 information. If LookUpServicePeer messages are sent several times, 400 we could choose different destination IDs to make the message go 401 through different paths, so that the source peer will have a chance 402 to ask more peers. 404 What information SEP intends to get is to learn the reachability 405 information of these service peers. It does not care about whether 406 the service peers are capable of serving the peers in need of this 407 service at the moment. With several service peers in mind, the peer 408 in need of the service could try all service peers until it gets 409 served. As for how to choose the best service peer, it is hard to 410 achieve. But in SEP, if every peer which provides a specific service 411 could update its service status and keep it in the routing states as 412 described in section 2.1, the peers who look for service peers may 413 choose based on their associated service status. Service delivery is 414 done by setting up a session to a service provider peer or any other 415 way of interaction with the specified peer. This procedure is out of 416 the scope of this draft. However, in this process the current status 417 of the service COULD be communicated, so that the requesting node can 418 make an updated decision as to which serving node to contact. 420 4.2. Relaying Peer 422 Some peers may be visited directly by other peers. This kind of 423 peers will help communications between peers who need to exchange 424 information, but have no direct connection yet. These peers could 425 relay messages between peers mentioned above. Here, we call these 426 peers realying peer. 428 4.2.1. Cases in which Relaying Peers Help 430 The use of relaying peer could help message traverse NAT and reach 431 its recipient. Further, it could also improve transactions' 432 reliability due to fewer hops. Here, we list cases where relaying 433 peers are suited to be applied. 435 1. In semi-recursive routing mode, if the source peer sending a 436 request is behind NAT, the response is hard to be returned to the 437 source peer directly. With the use of a relaying peer, the 438 relaying peer receives the response from a peer and relays it to 439 the source peer. 440 2. In recursive routing mode, peers often use the reverse 441 connections to its upstream peers to route the response. 442 However, the reverse connections may break down when the peer 443 receives a response. The reasons for the breakdown are various, 444 for example, when the upstream peer has left the overlay, or TURN 445 server between two peers has failed, or NATs between two peers 446 reboot, etc. In this case, the peer could attempt to send the 447 response to the source peer with the hlep from a relaying peer. 449 4.2.2. Locating Relaying Peer 451 Before asking for help from relaying peers, a peer should locate 452 where the relaying peers are. There are two requirements on the 453 peers who are eligible for a relaying peer. 455 1. The peer SHOULD have a unrestricted connectivity. It may be on 456 the Internet or behind the p2p-friendly NAT. All in all, other 457 peer could reach it so long as they have relaying peers' 458 transport address. 459 2. The relaying peer SHOULD know how to send a response to the 460 source peer when the source peer is behind NAT. It could be 461 achieved at least by two means. One is to choose its own 462 neighbor peer as its relaying peer because they have already 463 established direct connections. The other is to send the request 464 directly to the its chosen relaying peer and the relaying peer 465 keeps state of the source peer's transport address based on the 466 incoming request or carry the address in the request and get from 467 the response again the source peer's transport address which will 468 be used to relay response to the source peer. 470 We could think of the relaying peer as a service, so service 471 discovery method in section 4.1 could be used to locate relaying 472 peer. On the other side, the peer could also check whether there are 473 peers which could be relaying peers in its neighbor peer set. 475 4.2.3. How to Use Relaying Peer 477 A few general steps will be followed if the peer want to get the help 478 from the relaying peer. 479 1. Locating relaying peers first; 480 2. The peer stores the information about its chosen relaying peer in 481 the request and convey them to other peer which may send it 482 response back directly; 483 3. Based on whether direct connection between the peer and the 484 relaying peer exists or not, the peer may either send the request 485 directly to the relaying peer or not; 486 4. The destination peer will send the response to the relaying peer 487 which has been communicated to the destination peer in the 488 request. 490 4.3. Routing Mode 492 Several routing modes are often used to realize the P2PSIP 493 transaction. P2PSIP requests have to be routed through the overlay 494 by using the overlay routing states, but the responses have several 495 choices to return to the source peer, either directly or in the 496 reverse path or in a sepearte path based on the source peer ID. 498 In the following figure, we compare four routing modes from three 499 perspectives: difficulty of NAT traversal, resilient from the failure 500 of intermediate peers and the latency of the transaction. 502 +----------------+--------------+---------------------+-------------+ 503 | Routing Mode | Difficulty | Resilient from the | Latency of | 504 | | of NAT | failure of | the | 505 | | traversal | intermediate peers | transaction | 506 +----------------+--------------+---------------------+-------------+ 507 | iterative | high | high | high | 508 | recursive | low | high | medium | 509 | semi-recursive | medium | high | low | 510 | overlay native | low | high | high | 511 +----------------+--------------+---------------------+-------------+ 513 Figure 1 the comparison of the four routing modes 515 For iterative mode, NAT traversal is a big problem and the 516 transaction latency is higher. Recursive mode has little trouble in 517 traversing NAT, but transaction will be prolonged due to the 518 breakdown of any reverse connection in the reverse path. As for 519 overlay native mode, the response is still routed to the source peer 520 through the overlay and hence the transaction's latency is also high. 521 Semi-recursive mode has good balance between the three perspectives. 522 The response is returned to the source peer directly. The only 523 problem in the semi-recursive mode is that the response may not reach 524 the source peer due to the existence of NAT. 526 SEP takes the two routing modes from them, semi-recursive mode and 527 overlay native routing mode. In most cases, semi-recursive mode 528 works. Overlay native mode may be used once semi-recursive mode has 529 failed. As for NAT traversal in semi-recursive mode, SEP's solution 530 is for the source peer to convey some relaying peers to the 531 destination peer so that the destination peer could send the response 532 to these peers who relays the response to the source peer. Of 533 course, if the source peer is on the public Internet, the destination 534 peer could reach the source peer directly. 536 4.4. Flexible Routing Mechanism 538 Because of the heterogeneity in peers' bandwidth, processing power 539 and traffic load, some less powerful peers may be overloaded by 540 excess messages. Under this condition, the connection between the 541 peer with its overloaded downstream peers seems in a good state, but 542 its processing capability has decreased greatly. If the upstream 543 peer still route message to the overloaded downstream peer, the 544 message may be discarded or experience longer delay. 546 On the other hand, there are often a great number of paths between 547 two peers in the overlay. The peer will have several downstream 548 peers at hand as its candidate next hop peers when routing a specific 549 message. So it could choose the next hop peer based on the 550 downstream current status. 552 SEP supports status notification from the downstream peers and also 553 do flexible routing based on the advertised status. 555 4.5. End-to-end Reliability 557 Reliability is very important for the transaction in the peer 558 protocol. The transaction comprises of requests and responses. 559 Because peer protocol messages will be delivered to the destination 560 hop-by-hop, it is hard to achieve end-to-end reliability for the 561 transaction. The reason for this is that source peer does not know 562 where the destination peer is before the request really reaches the 563 destination. So it could not rely on TCP to ensure end-to-end 564 reliability. Although every hop in the path could be TCP 565 connections, it only guarantees the reliability between the immediate 566 peers. The behavior of the intermediate peers may break the end-to- 567 end reliability, for example, dropping packets. 569 It seems that application retransmission mechanism is the only answer 570 to the end-to-end reliability. If the source peer could not receive 571 the response within the expected time, it could retransmit the 572 request. It works for the simple request-response communication. 574 Open issue 1: how does the source peer set the retransmission timeout 575 timer? Does the value used in the conventional SIP work well in P2P 576 case? 578 5. Message Syntax 580 SEP protocol messages comprises of two parts: message header and some 581 attributes expressed in a TLV style. 583 O Message header: it contains some information for forwarding 584 operations, for example, destination ID, message type and some 585 options; and other information used to for the source peer to match 586 the response with the request, including source peer ID, destination 587 ID, transaction ID. 589 O Attributes: in order to make SEP extensible, TLV-style attributes 590 is used to express attributes. In order to support new operations, 591 we are not only able to add new messages, but able to add new 592 attributes. Every attribute may be composed of other attributes with 593 the TLV-style. 595 5.1. Message Header 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |Version|R|H|D|F|J| Reserved | Message Type | TTL | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Message Length | Reserved | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Transaction-ID | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Source Peer ID = 128bit | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Destination ID = 128bit | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Version (4 bit): Indicates the version of the SEP protocol. The 612 current version is 0x01; 614 R (1 bit): If it is set, used to indicate that this message is a 615 response. 617 H (1 bit): If it is set, used to indicate to the intermediate peers 618 that this message should be processed in terms of the message type in 619 addition to forwarding operation. 621 D (1 bit): If it is set, it indicates to the destination peer that 622 the source peer thinks that a direct connection SHOULD be negotiated 623 and established after this transaction. 625 F (1 bit): If it is set, it means the response should be processed in 626 the relay mode. 628 J (1 bit): If it is set, it means that it has been processed only by 629 the source peer. 631 Message type (8 bit): type of the message. 633 TTL (8 bit): time-to-live. It indicates the number of hops which a 634 message is allowed to traverse before it is discarded. 636 Message Length (16 bit): indicates the length of the message, 637 including the message header and the following variable attributes. 639 Transaction-ID (32 bit): It is randomly assigned by the source peer 640 and in order to match the response with the request. 642 Source Peer-ID (128 bit): indicates the Peer-ID of the source peer 643 who initiates the request. 645 Destination ID (128 bit): either a destination Peer-ID or a 646 destination key. Its function is for the P2P overlay to get the 647 packet delivered to the destination peer. 649 5.2. Message Attribute 651 In this draft, we define several message attributes that are 652 expressed in a TLV-style. 654 5.2.1. TLV Format 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |M| Reserved | Type | Length | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | | 662 + Value - variable length + 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 M (1 bit): It indicates that the attribute MUST be understood by the 667 peers who intend to process them. If the attribute could not be 668 understood by the processing peers, the message MUST be discarded or 669 return a error response. 671 Type (8 bit): It indicates the type of the attribute. 673 Length (16 bit): the byte length of the attribute. 675 5.2.2. Peer Address Info 677 Attribute type: 0x00 ( to be assigned by IANA) 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 |M| Reserved | Type | Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Trans | Type | Reserved | Port | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Priority | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | IPv4 Address | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Trans (4 bit): it indicates the type of the transport protocol. In 691 this draft, we define two types: 0x00(TCP), 0x01(UDP). 693 Type (4 bit): host (0x0), server reflexive (0x01), peer reflexive 694 (0x02), relayed address (0x03). The classification is the same as 695 that in [ICE]. 697 Port (16bit): the port on which this peer listens for requests. 699 Priority (32bit): It is used by ICE procedure to sort the candidate 700 pair. It is computed as suggested in [ICE]. 702 IPv4 Address: the IPv4 address of the peer. 704 5.2.3. Peer service capability 706 Attribute type: 0x01 ( to be assigned by IANA) 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |M| Reserved | Type | Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 |N|S|T| Reserved | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 This attribute is to express which services the peer could provide to 717 the other peers. Every bit in the value is used to indicate a 718 specific service. In this draft, we recommend the length of this 719 attribute is 16 bit long and three services are defined. 721 N (1 bit): if N flag is set, it means the peer is behind NAT. 722 Otherwise the peer is on the public Internet. 724 S (1 bit): STUN service. If it is set, it means the peer supports 725 STUN service. 727 T (1 bit): STUN relay service. When it is set, it means the peer 728 supports STUN relay service. 730 5.2.4. Peer-ID 732 Attribute type: 0x02 ( to be assigned by IANA) 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 |M| Reserved | Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Peer-ID = 128bit | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Peer-ID conveys the Peer-ID of the specific peer. The length of this 743 field is 128bit. Although not all DHT algorithms use 128 bit as the 744 length of the Peer-ID, we think that 128 bit works for all DHT 745 algorithms. 747 5.2.5. Source Peer Info 749 Source Peer Info is a composite attributes. It is comprised of 750 Peer-ID attribute, peer service capability attribute and several peer 751 address info attributes. This attribute carries a few source peer 752 related information to other peers. 754 Attribute type: 0x03 ( to be assigned by IANA) 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |M| Reserved | Type | Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Peer-ID | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Peer service capability | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Peer Address Info - 1 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | ............ | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Peer Address Info - N | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 5.2.6. Destination Peer Info 774 Destination Peer Info is also a composite attribute. Like the source 775 peer info attribute, it is also comprised of Peer-ID attribute, peer 776 service capability attribute and several peer address info 777 attributes. This attribute carries a few destination peer related 778 information to the source peer. 780 Attribute type: 0x04 ( to be assigned by IANA) 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |M| Reserved | Type | Length | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Peer-ID | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Peer service capability | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Peer Address Info - 1 | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | ............ | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Peer Address Info - N | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 5.2.7. Resource Info 800 Attribute type: 0x05 ( to be assigned by IANA) 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 |M| Reserved | Type | Length | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 |E|O|H|C| Value Type | Value Length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 + Resource ID(16Bytes) + 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Expiration Time(4Bytes,Optional) | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | | 815 + Owner Identity(16Bytes,Optional) + 816 | | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | 819 + Hash Code(16Bytes,Optional) + 820 | | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 + Value Content(variable length,Optional) + 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 E (1 bit): If this bit is set, Expiration Time field MUST be 828 included; otherwise not. 830 O (1 bit): If this bit is set, Owner Identity field MUST be included; 831 otherwise not. 833 H (1 bit): If this bit is set, Hash Code field MUST be included; 834 otherwise not. 836 C (1 bit): If this bit is set, Value Content field MUST be included; 837 otherwise not. 839 Value Type: A 12-bit value, the type of application in which the 840 value is used. How to assign this value depends on the content to be 841 stored in the overlay. It will be developed in the later version. 843 Value length: The number of Bytes in the value. 845 Resource ID: A 16-byte value, the hash function result of the 846 resource unique property. 848 Expiration Time: Optional in the Resource Info, A 4-byte value 849 indicate the expiration time of the resource object. 851 Owner Identity: it specifies the owner of the Resource object. 853 Hash Code: It is computed by hashing the resource objects. It is 854 used for integrity check. A resource object must be put into the 855 overlay with its owner identity and the hash code of the resource 856 object. The owner uses the owner identity and the hash code to 857 refresh and modify the unique resource object, because a user may put 858 several resource objects under the same resource ID. 860 Value Content: when presented, its length is specified by the "Value 861 Length" parameter. 863 5.2.8. Negotiation Info 865 Attribute type: 0x06 ( to be assigned by IANA) 867 This attribute is used to negotiate the transport parameters for PUT 868 or GET or TRANSFER operations. Its format is to be determined. 870 5.2.9. Response Attribute 872 Attribute type: 0x07 ( to be assigned by IANA) 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 |M| Reserved | Type | Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Response code | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 The following response codes are defined in this version. 883 200: Successful request; 885 401: Bad parameters; 887 402: Could not find the corresponding data; 889 403: The request is rejected for some reason; 891 5.2.10. Service Peer Info 893 Attribute type: 0x08 ( to be assigned by IANA) 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |M| Reserved | Type | Length | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Num of Peers | Service Type | Max. Num | Reserved | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 // Peer-ID attribute 1 // 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 // Peer Address Info attribute 1 // 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 // ............. // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 // ............. // 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 // Peer-ID attribute N // 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 // Peer Address Info attribute N // 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 It is also a composite attribute. It intends to collect the 915 reachability information of peers which could support the service 916 specified in the attribute. 918 O Num of Peers (8 bit): this field records how many peers in this 919 attribute. It is set to zero while the source peer creates this 920 attribute. The number will be modified by the intermediate peers and 921 destination peers when new peers are added. This attribute should be 922 returned to the source peer in the response from the destination 923 peer. 925 O Service type (8 bit): this field indicates which type of service 926 the source peer wants to know. In this draft, three service types 927 are recommended. They are STUN (0x00), TRUN relay (0x01) and 928 Relaying Peer (0x02). 930 O Max. Num (8 bit): this field indicates the maximum number of the 931 service peers what the source peer wants. 933 O Peer-ID attribute: this field has a type of Peer-ID attribute and 934 records the Peer-ID information of the peers who provides the 935 specified type of service. 937 O Peer address info attribute: this field has a type of Peer Address 938 Info attribute and records the transport address of the peers who 939 could provide the specified type of service. 941 5.2.11. Relaying Peer Info 943 Attribute type: 0x09 ( to be assigned by IANA) 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 |M| Reserved | Type | Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Num of Peers | Reserved | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Peer Address Info attribute 1 | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | ............. | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | ............. | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Peer Address Info attribute N | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 This attributes intends to convey relaying peer information to the 962 peer which would return response to the source peer directly. 964 O Num of Peers: this field records the number of relaying peers 965 supplied by the source peer. It won't be changeed in transit. 967 O Peer Address Info attribute: this filed has a type of the Peer 968 Address Info attribute and records the reachability information of 969 the relaying peers. 971 5.2.12. Source Reflexive Address attribute 973 Attribute type: 0x0A ( to be assigned by IANA) 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 |M| Reserved | Type | Length | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Port | Transport pro.| Reserved | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | IPv4 Address | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 This attribute is often used in the case where bootstrap peer 986 processes the JOIN request and record the source transport address of 987 the JOIN request including IP address and the port observed by 988 bootstrap peer. This attribute will be delivered in the request and 989 later in response unmodified. When the Join response returns to the 990 bootstrap peer, it will check this attribute and make it as the 991 destination transport address of the JOIN response relayed by the 992 bootstrap peer. In this way, bootstrap peer won't keep state for the 993 joining peer and make the response return to the Joining peer even 994 though the Joining peer is behind NAT. 996 O Port (16 bit): the port number observed by the bootstrap peer. 998 O Transport Pro. : The type of transport protocol. In this draft, 999 two types are defined. TCP (0x00) and UDP (0x01). 1001 O IPv4 address: the IP address observed by the bootstrap peer. 1003 5.2.13. Routing table 1005 Attribute type: 0x0B ( to be assigned by IANA) 1007 The attribute format depends on detailed DHT algorithm, so its format 1008 is TBD. 1010 5.2.14. Status Info 1012 Attribute type: 0x0C ( to be assigned by IANA) 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 |M| Reserved | Type | Length | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Congestion State | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 Congestion State: indicates the current state of a peer. 0x00, a peer 1023 which states the peer is in good condition; 0x01, which means the 1024 peer is busy;. 1026 5.2.15. Event Info 1028 Attribute type: 0x0D ( to be assigned by IANA) 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 |M| Reserved | Type | Length | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Event Type | Event Description (Variable length) | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 O Event Type: Indicates that what kind of event has happened. 0x00 1038 means the sending peer is about to leave the overlay. Others TBD. 1040 O Event Description: give the detailed description of this event. It 1041 is informational. 1043 5.2.16. Update Type 1045 Attribute type: 0x0E ( to be assigned by IANA) 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 |M| Reserved | Type | Length | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Update Type | 1053 +-+-+-+-+-+-+-+-+ 1055 Update Type: indicate what kind of Update operation the sending peer 1056 want the destination peer do. 0x00 means the receiving peer should 1057 check whether it should update its routing state; 0x01 means the 1058 sending peer requests routing table of the receving peer. 1060 5.2.17. Overlay Configuration Info 1062 Attribute type: 0x0F ( to be assigned by IANA) 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 |M| Reserved | Type | Length | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Num of DHT Algorithms | Reserved | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | DHT Algorithm Attribute 1 | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | ............. | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | ............. | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | DHT Algorithm attribute N | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Other configuration parameters | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | (Authentication credentials, etc.) | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Num of Algorithms: The length of the DHT Algorithm Attribute list (N) 1084 The DHT Algorithm attribute is tbd, and could be dependent upon the 1085 characteristics of each DHT and its associated hash functions. 1087 The element MAY also contain additional configuration parameters, 1088 such as the authentication credentials of the joining node, an 1089 overlay ID specifying the Overlay to join (supposing that the 1090 bootstrap server is the admitting node for several overlays), etc. 1092 6. Peer Protocol Message 1094 6.1. Overlay Maintenance 1096 6.1.1. JOIN 1098 A peer MUST learn some necessary information before it wants to join 1099 the overlay, such as DHT algorithm, bootstrap peer list, its Peer ID, 1100 hash algorithm used to get the key and the like. It could get that 1101 information by enrollment procedure or some other means which is not 1102 within the scope of this draft. In SEP, the bootstrap peer MUST be 1103 on the public Internet. 1105 The joining procedure follows the general rules for setting up a 1106 session using SIP, combined with the authentication procedure: A 1107 first message is sent, specifying the desire to join and a summary of 1108 the joining node's capabilities; a challenge is sent back to the 1109 sender, and a new request containing the necessary credentials is 1110 resent to the entry point to the network. Finally, a response with 1111 the chosen communication parameters is sent to the joining node, 1112 serving as acknowledgment. 1114 The joining peer send an initial JOIN request to the bootstrap peer. 1115 This initial JOIN includes the Overlay Configuration Info attribute, 1116 containing the full list of supported DHT algorithms, in priority 1117 order, as well as supported hash functions. Other Overlay-relevant 1118 configuration elements MAY also be included (tbd; e.g. the 1119 authentication credentials of the joining node). The joining node 1120 MUST leave the Source Peer ID and Destination ID empty, since it 1121 initially does not know its own Peer ID. 1123 The bootstrap server, upon receiving the JOIN message, checks the 1124 Overlay Configuration Info element and compares it with the actual 1125 Overlay configuration parameters. If this is the first joining node, 1126 then the initial joining node MAY define the working parameters for 1127 the Overlay, if the bootstrap node so allows. Otherwise, the 1128 bootstrap node defines the working parameters. How the bootstrap 1129 node gets this configuration information is out of the scope of this 1130 draft. Nevertheless, manual configuration, taking into account 1131 factors such as the application scenario, number of potential peers, 1132 expected geographical distribution, etc. MAY be taken into account. 1134 The bootstrap server then sends a JOIN Response to the joining node, 1135 including the Overlay Configuration Info attribute. This attribute 1136 MUST contain the selected set of Overlay working parameters, 1137 including the chosen DHT algorithm and the hash function to calculate 1138 the Peer ID. 1140 Upon receiving the response, the joining node MUST calculate its own 1141 Peer ID according to the hash function and the DHT algorithm. It 1142 MUST send a second JOIN message to the bootstrap peer, filling the 1143 Source Peer ID and the Destination ID with its own Peer ID. If the 1144 joining peer is behind a NAT, it SHOULD set D flag in the message 1145 header to indicate to the destination peer that they should start an 1146 ICE negotiation with each other to find a direct connection for later 1147 communication. Source Peer Info MUST be carried in the JOIN request. 1149 Join request = 1150 Message Header 1151 Overlay Configuration Info 1152 Source Peer Info 1153 [Relaying Peer Info] 1154 [Source Reflexive Address] 1156 When a peer receives JOIN request, it checks the Destination ID to 1157 determine whether it is the destination of the join request. if it is 1158 not, the peer forwards the message to next peer which is closer to 1159 the destination. If the peer is the destination of the JOIN request, 1160 the peer processes the message and sends JOIN response to the joining 1161 peer.The destination peer often sends its routing table to the 1162 joining peer in the response. If the destination peer learns that 1163 source peer is behind NAT by check the Source Peer Info, it MUST set 1164 the D flag in the response. 1166 Join response = 1167 Message Header 1168 Overlay Configuration Info 1169 Response Attribute 1170 Destination Peer Info 1171 [Source Reflexive Address] 1172 [Routing Table] 1174 In the end, the joining peer receives the response. If it is a 200 1175 OK response, the joining peer MAY use the routing table in the 1176 response to construct its own routing table. If the D flag is set in 1177 the response, the joining peer SHOULD start ICE procedure to find out 1178 a direct path between them. 1180 JOIN operation will trigger data transfer from other peers to the 1181 joining peer. These peers who will transfer data to the joining 1182 peers are often the neighbors of the joining peer. After the 1183 transfer finishes, these neighbors will update their routing table to 1184 reflect the existence of the joining peer. 1186 6.1.2. LEAVE 1188 Before it leaves the overlay, a peer should transfer all the data to 1189 other peers, and other peers should update their routing table. So 1190 the leave process MAY include the following steps: 1192 1. The leaving peer sends LEAVE request to its neighbor peer(s); 1193 2. the neighbor peer(s) expands the key region and updates the 1194 routing table; 1196 3. the leaving peer notifies its upstream peers its departure; 1197 4. the leaving peer starts data transfer process; 1198 5. the leaving peer and the neighbor peer work together to serve the 1199 new requests; 1200 6. After data transfer finishes, the leaving peer leaves the 1201 overlay; 1203 A leaving peer sends leave message to it's neighbor peers which 1204 depend on the DHT algorithms in use. 1206 Leave request = 1207 Message Header 1208 Source Peer Info 1210 The peer receiving the LEAVE message SHOULD consider whether it's 1211 responsible space in the overlay has changed due to the source peer's 1212 leave and then expand the responsible space accordingly. If the 1213 neighbor peer receives message, the peer MAY either reply this 1214 request on its own if the associated data has been transferred from 1215 the leaving peer, or lead this request to the leaving peer. 1217 Leave response = 1218 Message Header 1219 Response Attribute 1220 Destination Peer Info 1222 When the leaving peer receives the response, it could start data 1223 transfer operation to its neighbors and at the same time, it could 1224 notify any of its upstream peers its departure to accelerate the 1225 convergence of the overlay. Before the transfer finishes, the 1226 leaving peer and its neighbors could work together to serve the 1227 requests in the overlay. (TO DO: how they work together with various 1228 messages is to be developed further.) 1230 Open issue: How do the leaving peer and the neighbor peer work 1231 together to serve the new request? 1233 6.1.3. KEEPALIVE 1235 KEEPALIVE message is used by a peer to make sure whether the neighbor 1236 peers are still alive. If a peer has not received KEEPALIVE response 1237 from the destination peer for several times, it could conclude that 1238 the destination peer is not alive and then should start to update its 1239 routing or neighbor table. After receiving KEEPALVIE request, the 1240 destination peer MUST convey its status information in the KEEPALVIE 1241 response. If a peer has received a KEEPALIVE message with a peer's 1242 current status which shows this peer is in the busy state, the peer 1243 SHOULD not forward packets to that congested peer until that peer 1244 reaches the normal state again. 1246 KEEPALIVE Request = 1247 Message Header 1248 Source Peer Info 1250 (preamble) 1251 KEEPALIVE Response = 1252 Message Header 1253 Response Attriubute 1254 Destination Peer Info 1255 Status info 1256 (postamble) 1258 6.1.4. NOTIFY 1260 The continuity and quality of service contributed by a peer is 1261 concerned by the other peers in the overlay. After receiving an 1262 indication that a specified peer is interested in the status of the 1263 contributed service, the peer who contributed the service starts to 1264 monitor its service status for the specified peer, and then it 1265 informs the specified peer about the interesting service status 1266 information through a NOTIFY message when it finds that the service 1267 status changes (e.g. service quality degraded or service 1268 interrupted). Those information includes: a)an event means that the 1269 peer will leave; b)an event means that the peer is coming into 1270 congestion state, etc. 1272 NOTIFY message = 1273 Message Header 1274 Source Peer Info 1275 [EVENT] [STATUS INFO] 1277 When receiving notify message, peer MAY choose to update 1278 corresponding status according to the information in the request. 1280 Open Issue: As proposed in the section 4.4, current status 1281 advertisement from downstream peers will be useful to ease the 1282 congestion of the downstream peers. How do these downstream peers 1283 measure its status? When is the right time for them to advertise the 1284 status change? 1286 6.1.5. UPDATE 1288 UPDATE message is used to notify its existence in the overlay to its 1289 neighbors or request routing table from its neighbors. The target 1290 peers of the UPDATE request depends on the DHT algorithms. For 1291 example, neighbor may just mean the successor or predecessor in 1292 Chord, but it means all peers in its leaf set in Pastry. 1294 UPDATE provides two options for peers to update its own or its 1295 neighbors routing states. One option is for the peer to notify its 1296 existence to its neighbors. For example, after the joining peer 1297 finished JOIN transaction in Pastry, it should notify other neighbors 1298 to let them update its leaf set. The other option is for the peer to 1299 request routing table from its neighbors. In Pastry, peers may want 1300 to update its routing states after it checks some peers have been 1301 dead. They often request routing table from its neighbors to achieve 1302 this. Of course, SEP could support the two options in the single 1303 UPDATE transaction. 1305 Before UPDATE request is sent, the source peer should set the UPDATE 1306 Type attribute to determine option type. 1308 When the destination peer receives the UPDATE request, it first 1309 checks the UPDATE Type. If the UPDATE is for a routing table, the 1310 destination peer should convey the routing table according to the 1311 request in the response. 1313 UPDATE Request = 1314 Message Header 1315 Source Peer Info 1316 Update Type 1318 UPDATE Response = 1319 Message Header 1320 Response Attribute 1321 Destination Peer Info 1322 Update Type 1323 [Routing-table] 1325 6.1.6. SearchPeer 1327 One Peer sends a SearchPeer request to find the responsible peer for 1328 a destination ID. The destination peer information MAY be used to 1329 maintain the overlay routing table. The source peer MAY establish a 1330 direct connection with the destination peer. If it is the case, the 1331 D flag MUST be set to indicate to the responsible peer they SHOULD 1332 exchange ICE candidate for the NAT traversal. In Chord, one peer 1333 uses SearchPeer request to lookup the responsible peer for its finger 1334 table. The responsible peer MUST make a response to the request with 1335 its own peer information. Current status of the responsible peer MAY 1336 also be included in the response. 1338 SearchPeer Request = 1339 Message Header 1340 Source Peer Info 1341 [Relaying Peer Info] 1343 SearchPeer Response = 1344 Message Header 1345 Response Attribute 1346 Destination Peer Info 1347 [Status Info] 1349 6.1.7. TRANSFER 1351 When a peer joins or leaves the P2P overlay network, data transfer 1352 operation will be triggered. The joining peer will be responsible 1353 for some pairs and the leaving node SHOULD transfer its 1354 stored pairs to its neighbors. When the transfer 1355 operation takes place, the source peer does not know whether the peer 1356 receiving the pair is leaving the overlay or it is busy. 1357 So SEP provides a mechanism to make both peers could negotiate some 1358 transfer parameters and the time when will the tranfer start. 1360 The source peer sends a TRANSFER request with the negotiation of the 1361 range of the resource ID to be transferred and the destination peer 1362 responds with the negotiation result by taking its current state into 1363 account. If the the destination peer is about to leave the overlay, 1364 it MAY reject the request and sugguest the source peer tries another 1365 peer some time later. The destination MAY accept, redirect or deny 1366 the transfer operation. After that, the source peer transfers 1367 resource objects to the destination peer if the request was accepted. 1368 Peers MAY also negotiate transport parameters, such as transport 1369 protocol, to transfer resource objects. 1371 TRANSFER Request = 1372 Message Header 1373 Source Peer Info 1374 [Negotiation Info] 1375 [Resource Info] 1377 TRANSFER Response = 1378 Message Header 1379 Destination Peer Info 1380 [Negotiation Info] 1382 6.2. Data Operations 1383 6.2.1. PUT 1385 A peer sends a PUT request to publish its resource object in the P2P 1386 overlay. A peer may also send a PUT request to refresh or modify the 1387 resource object. A hash code must be used with the owner identity to 1388 identify the unique resource object under the same resource ID. 1389 Every resource object has an owner identity to verify the owner of 1390 the resource object and a hash code to check the integrity of the 1391 resource object. Every resource object also has an expiration time. 1392 One peer can refresh the resource object by modifying the expiration 1393 time, otherwise the destination peer SHOULD remove the resource 1394 object when it expires. 1396 A PUT request may take the resource object within the request. A PUT 1397 request may also include negotiation information to negotiate the 1398 transport parameter to set up a direct connection between the source 1399 peer and the destination peer, and then the resource object 1400 transports through a direct connection. When the resource object 1401 transport completes, the source peer may notify the destination peer 1402 of the completion. When the put request is used to refresh the 1403 resource object, there is no resource object in the request but the 1404 resource ID, expiration time, owner identity and hash code are 1405 needed. 1407 PUT Request = 1408 Message Header 1409 Source Peer Info 1410 [Relaying Peer Info] 1411 Resource Info 1412 [Negotiation Info] 1414 PUT Response = 1415 Message Header 1416 Response Attribute 1417 Destination Peer Info 1418 [Negotiation Info] 1420 6.2.2. GET 1422 The source peer sends a GET message with the resource ID and content 1423 type to retrieve the resource object. The resource objects can be 1424 sent back with the Get response. If the size of the resource objects 1425 is large(over some limit), the transport parameters can be negotiated 1426 using the GET request and response to figure out the transport type 1427 of the resource objects in a following direct connection. When the 1428 resource objects transport completes, the source peer must notify the 1429 destination peer of the completion. 1431 GET Request = 1432 Message Header 1433 Source Peer Info 1434 [Relaying Peer Info] 1435 Resource Info 1436 [Negotiation Info] 1438 GET Response = 1439 Message Header 1440 Response Attribute 1441 Destination Peer Info 1442 [Resource Info] [Negotiation Info] 1444 6.2.3. REMOVE 1446 A peer sends a REMOVE request to delete the resource object in the 1447 P2P overlay network. A resource ID is used to locate in which peer 1448 the resource object is stored. The owner identity and the hash code 1449 is used to distinguish the resource object from others under the same 1450 resource ID. One responsible peer should delete all information 1451 about the resource object including replicas immediately when it 1452 receives the remove request. 1454 REMOVE Request = 1455 Message Header 1456 Source Peer Info 1457 [Relaying Peer Info] 1458 Resource Info 1460 REMOVE Response = 1461 Message Header 1462 Response Attribute 1463 Destination Peer Info 1465 6.3. Additional messages 1467 6.3.1. LookUpServicePeer 1469 Some messages could be used to discover service peers who could 1470 provide a specific service, for example, STUN or TURN Relay service. 1471 Source peer MUST carry Service Peer Info in the request. In SEP, we 1472 choose the LookUpServicePeer to collect the service peer's 1473 information. This message will be forwarded through the overlay in a 1474 hop-by-hop way, so intermediate peers and the destination peer could 1475 collect the service peers based on its local knowledge of the 1476 overlay. Every peer other than the source peer SHOULD put the 1477 searched results in the Service Peer Info attributes which will be 1478 returned back to the source peer. 1480 The source peer MUST insert a Service Peer Info attribute in the 1481 request to collect service peers whose types may be STUN, STUN relay, 1482 etc, and send it to the destination peer by choosing a given 1483 destination ID. The source peer should specify the maximum number of 1484 service peers in the request. If the number of peers reaches the 1485 maximum number, the successive intermediate peer or destination peer 1486 won't need to find satisfied peers. In the resulting Service Peer 1487 Info attribute, none of the peer has the same Peer-ID attribute. If 1488 the successive intermediate peer or the destination peer finds the 1489 service peer has already been in the Service Peer Info attribute, 1490 they MUST not be put into the Service Peer info attribute. 1492 When the peers process LookUpServicePeer request or response, some 1493 message-specific actions should be done in addition to basic actions 1494 proposed in section 9. 1496 The source peer SHOULD choose a destination ID which will determine 1497 the path the request will traverse. The source peer SHOULD set the H 1498 flags in the message header and put in the request a Service Peer 1499 Info attribute which SHOULD set the maximum number of the expected 1500 service peers. When source peer receives the response, it should 1501 check whether Service Peer Info attribute exists. If it is, the 1502 source peer gets service peers from it for later use. 1504 While intermediate peers and the destination peer receive the 1505 LookUpServicePeer request, it first checks if the number in the 1506 Service Peer attribute reaches the maximum value. If it is not the 1507 case, the intermediate peer should get the service type what the 1508 source peer wants and try to search the satisfied peers in the 1509 locally stored states. If the intermediate peer gets some service 1510 peers, it should put it in the Service Peer info attribute. If the 1511 number of the discovered peers equals the maximum number, they will 1512 not be put in the attribute. At the same time, every intermediate 1513 peer or the destination peer should guarantee that every service peer 1514 is unique in this set. 1516 When the destination peer generates the response, it should carry the 1517 Service Peer attribute which is copied from the request unmodified. 1518 In the end, the discovered service peers are learned by the source 1519 peer by carrying them in the Service Peer Info attribute. 1521 LookUpServicePeer Request = 1522 Message Header 1523 Source Peer Info 1524 Service Peer Info 1525 [Relaying Peer Info] 1527 LookUpServicePeer Response = 1528 Message Header 1529 Source Peer Info 1530 [Service Peer Info] 1532 7. Routing Operations 1534 Routing operation is the basic and the important function of the peer 1535 in the overlay. Peers choose the next hop peer for the packet 1536 regardless of where packets are from. The packets as the input to 1537 the routing operation may come from the upper applications in the 1538 same peer, or from the network. But the general forwarding operation 1539 applies to all of them. 1541 SEP protocol takes the semi-recursive and overlay native routing 1542 modes by considering the difficulty of NAT traversal and simultaneous 1543 failures of the intermediate peers. 1545 7.1. Request Routing 1547 If the packet is a request, it should be routed through the overlay 1548 by looking up the downstream peer based on the destination-ID in the 1549 packet. The destination ID may be a Resource-ID or a Peer-ID which 1550 depends on the message type. 1552 In order to improve the reliability of the packets, SEP makes a 1553 flexible routing decision, not only complying with the DHT 1554 algorithms, but also based on the status of the downstream peers. 1555 The flexible routing operations may introduce latency for the packet, 1556 but it does improve the reliability. Certainly, the tradeoff between 1557 the reliability and the additional latency from the additional hops 1558 should be evaluated independently by the routing peer. 1560 Note: if there are several candidate downstream peers at the same 1561 level in the overlay, for example, peers in the successor list in 1562 chord, the flexible routing operation would not introduce additional 1563 significant latency. 1565 The routing rules for the request are listed as follows: 1567 1. Get the destination ID from the request; 1568 2. Check whether the peer itself is responsible for the destination 1569 ID. If it is, then deliver the packet up to the message specific 1570 function; 1571 3. If it is not, get a few downstream peers closer to the 1572 destination ID in the routing states and get their associated 1573 processing status; 1574 4. It is up to the implementation to decide which peer the request 1575 will be sent to by evaluating the trade-off between the 1576 reliability and the latency; 1578 7.2. Response Routing 1580 If the packet is a response, the first choice is to send the response 1581 back to the source peer directly, because the destination peer could 1582 get IP address of the source peer from the Peer Address Info 1583 attribute. Due to the existence of the NAT, response MAY be returned 1584 to source peer by using some special mechnisms. The routing behavior 1585 on intermediate peers or destination peer is different which are 1586 described below respectively. 1588 7.2.1. Response Routing on the Destination Peer 1590 1. Before the destination peer sends the response back to the source 1591 peer, it should check the N flag of Service Capability Info to 1592 learn whether the source peer is on the public Internet; 1593 2. If the source peer is on the public Internet, the transport 1594 address in the Peer address Info could be used to send the 1595 response back directly. 1596 3. If the source peer is behind the NAT, the destination peer checks 1597 whether the Relaying Peer Info attribute is carried in the 1598 request. If the destination peer has not found them, the 1599 response should be sent back by routing through the overlay and F 1600 flag in the message header MUST be cleared. 1601 4. If the Relaying Peer Info is carried in the request, then 1602 destination peer could send the response to the transport address 1603 of these relaying peers which will relay the response to the 1604 source peer and the F flag MUST be set. Note: destination peer 1605 could send the response to these relaying peers parallelly or 1606 sequentially. The response could also be returned by using 1607 overlay native routing. It is up to the destination peer to 1608 choose the right ways to send the response back. 1610 7.2.2. Response Routing on the Intermediate Peer 1612 1. The intermediate peers check the F flag in the message header 1613 first. If it is cleared, the response SHOULD be treated via 1614 overlay routing according to the forwarding rule described in the 1615 section 8.1. 1616 2. If the F flag is set, it means that the response want to be 1617 relayed by the intermediate peer to the source peer. So the 1618 intermediate peer gets the source peer-ID and checks whether the 1619 peer has the direct connection with the source peer. 1620 3. If the direct connection exists, the intermediate peer sends the 1621 response to the source peer through the established connection 1622 with it. 1623 4. If there is no direct connection between them, then it will check 1624 whether Source Reflexive attribute is carried in the response. 1625 If the Source Reflexive attribute exists, the intermediate peer 1626 will send the response directly to the transport address recorded 1627 in the Source Reflexive attribute; 1628 5. If it does not exist, the intermediate peer MAY discard the 1629 response silently. The intermediate peer also route the packet 1630 further based on the source peer ID. 1632 8. General Peer Behavior 1634 A few kinds of peers are involved in the transaction, including 1635 source peer, destination peer, intermediate peers. The request is 1636 generated by the source peer and then forwarded through the overlay 1637 by traversing several intermediate peers and reaches the destination 1638 peer in the end. The response from the destination peer may either 1639 be sent via IP routing, or forwarded by the intermediate peers 1640 through the overlay. In this section, we give the general behavior 1641 of the peers who plays different roles in the transaction. 1643 8.1. Source Peer Behavior 1645 8.1.1. Generating the Request and Sending the Request 1647 The fields in the message header and some required attributes of the 1648 new message MUST be determined before the message would be sent. 1650 O Version: the current version number is 1; 1652 O F flag: this bit MUST be cleared in the request; 1654 O D flag: If the source peer realizes that it is behind NAT and needs 1655 a direct connection with destination peer after this transaction 1656 completes, the D flag MUST be set. 1658 O H flag: If the source peer wants the intermediate peers to process 1659 this message hop-by-hop, the H flag MUST be set. 1661 O R flag: this bit MUST be cleared in the request. 1663 O J flag: if this is the JOIN request, it should be set. 1665 O TTL: Every overlay MAY specify a default TTL in terms of the size 1666 of the overlay peers. This default values MAY be obtained through 1667 the enrollment procedure. It is up to the source peer to decide the 1668 value of the TTL. 1670 O Transaction ID: a 32 bit random number which is used to match the 1671 response with the request. The method to get the transaction ID is 1672 implementation dependent. 1674 After the requests are generated, the routing operation described in 1675 section 8 MUST be followed to find out who is the next peer to the 1676 destination ID, and then send the requests directly to the next peer 1677 by using the established control connection between them. 1679 Source peer should keep the state for the request and wait for the 1680 response. In order to make sure the reliability, the source peer MAY 1681 set a retransmit timer. If the timer fires, the source peer should 1682 send the request again until maximum retransmit times reached. 1684 8.1.2. Processing the Response 1686 When the peer receives a response from the network, the routing 1687 operation will decide how to process it. If the Source Peer ID in 1688 the response equals to the Peer ID of the routing peer, the routing 1689 peer knows it is the destination of the response and it will deliver 1690 the response to the upper layer and perform the message-specific 1691 processing. 1693 Before the message-specific processing, the peer MUST check the 1694 message in the following rules: 1696 1. Check the value in the TTL field whether it is zero. If it is, 1697 dicard the response. 1698 2. Make sure Destination Peer Info attribute and the Response 1699 Attribute are carried in the response. If any of them 1700 disappears, the peer MUST discard the response. 1701 3. Extract Source Peer ID, destination ID, transaction ID and the 1702 message type from the message header, and match them with the 1703 pending requests. If there is no matched one, it means that the 1704 response MAY either arrive at a wrong destination or be a delayed 1705 response, therefore the response MUST be discarded. If there is 1706 a matched one, the response should be processed according to the 1707 message-specific procedure; 1709 8.2. Intermediate Peer Behavior 1711 When the peer receives a message from the network, it first checks if 1712 it is the destination of the message. If it is not, it plays the 1713 intermediate peer role. For the intermediate peer, the main task is 1714 to forward the message through the overlay or relay the messages to 1715 their destination. 1717 SEP introduces the hop-by-hop option which means that the 1718 intermediate peers should perform some message-specific actions in 1719 addition to routing operations. These message-specific actions would 1720 provide some information which will be carried in the message and 1721 learned by the source peer in the end. For example, source peer MAY 1722 want to get a route log of a request, so every intermediate peer 1723 should put itself into the request and later the route log will be 1724 returned to source peer. 1726 SEP also sets a J flag in the JOIN request which means that the JOIN 1727 request has not been processed by any peer in this overlay. So when 1728 a peer receives a JOIN request, it would take the role of the 1729 bootstrap peer if J flag is set. What the bootstrap peer could do to 1730 the JOIN request is to clear the J flag and get the source transport 1731 address of the JOIN request, and then record it into the Source 1732 Reflexive Address attribute in the request. 1734 Intermediate peer could decide whether the message is a request or 1735 response by only looking at the R flag in the message header. 1737 8.2.1. Request Processing 1739 When the intermediate peer receives a request, it first checks 1740 whether the hop-by-hop flag is set. If it is set, it should perform 1741 some message-specific actions according to the message type. Whether 1742 the H flag is set or not, the basic routing operations MUST be 1743 performed. 1745 The intermediate peer should also check the J flag if the message is 1746 JOIN request. If the J flag is set, the intermediate peer should do 1747 some message-specific action. If it is not set, only basic routing 1748 operations is performed. 1750 The TTL should be decreased by 1 and if the result is 0, the 1751 intermediate peer MUST discard the request. 1753 8.2.2. Response Processing 1755 When the intermediate peer receives a response, it should check the F 1756 flag and determined what kinds of routing mode will be preferred by 1757 the destination peer. If F flag is set, it means the response should 1758 be relayed by the intermediate peer; if it is not, the response 1759 should be routed on the overlay level like what the requests are 1760 treated. 1762 8.3. Destination Peer Behavior 1764 8.3.1. Request Processing 1766 When the peer receives a request, it should consult their routing 1767 states to decide whether it is the destination peer for the request. 1768 If it is the destination peer, some routine checks MUST be performed 1769 before the message-specific actions are to be performed. 1771 1. Check whether TTL is zero. If it is, MUST discard the message; 1772 2. Check whether the Source Peer Info attribute is in the request. 1773 If it is absent, MUST discard the message; 1775 8.3.2. Response Generation and Sending the Response 1777 After processing the request, the destination SHOULD send a response 1778 to the source peer. The rules below should be followed: 1780 1. The Source Peer, Destination ID, message type and the transaction 1781 ID MUST not be changed in the response. These fields should be 1782 kept the same as the request. 1783 2. Response Attribute MUST be included in the response; 1784 3. Destination Peer Info MUST be included in the response. 1786 How to send the response depends on the routing modes chosen by the 1787 destination peer. Please refer to the section 7.2.1 for more detail. 1789 9. NAT Traversal 1791 The existence of NAT makes the communication between peers becomes 1792 harder. IETF has developed a suite of tools, STUN/TURN/ICE to 1793 address the issue. SEP intends to reuse these tools and work with 1794 them in a harmonious way. For example, SEP provides a method to 1795 exchange the candidate for the ICE protocol and SEP has the 1796 capability for the peer to discover the STUN or TURN server. 1798 An overlay is made up of the peers and the connections between peers. 1799 Peers could reach its neighbors directly. For some operations like 1800 GET or PUT, source peers may only request the service provided by the 1801 destination peer and would not communicate with the destination peer 1802 any more. In that case, the requests are delivered over the 1803 established connections and later reach the destination peer. There 1804 is nothing needed to do to address the NAT traversal of the request. 1805 But for the response, if it is forwarded on the overlay layer, it 1806 also would not be interfered by the existence of the NAT for the same 1807 reason as the request; But if it is forwarded on the IP layer, NAT 1808 MAY fail the response. SEP introduces relaying peers to make 1809 response go back to the source peer by traversing NAT. 1811 For some other operations like JOIN, SearchPeer, source peers not 1812 only request the service provided by the destination peer, but also 1813 expect the direct connection between them. If a new peer wants to 1814 join the overlay, it sends JOIN request to the destination peer. The 1815 destination peer for the request must be the new peer's neighbor; 1816 therefore they would communicate directly later. SEP provides a 1817 method to exchange the candidates for the source peers and 1818 destination peers and ICE could make use of them to attempt to find 1819 out one or more candidate pairs by which they could reach each other 1820 directly even in the presence of NAT between them. 1822 Before a peer joins the overlay, it should initiate an enrollment 1823 procedure. The joining peer MUST learn some bootstrap peers with 1824 public address. These public bootstrap peers could provide STUN 1825 service for other peers, therefore the joining peer could learn 1826 whether it is behind NAT or not with the help from these public 1827 bootstrap peer or some other STUN servers. 1829 The peer MAY uses STUN protocol to detect whether it is behind the 1830 NAT. If it is, it may need a TURN server if it is behind a p2p- 1831 unfriendly NAT. Service peer discovery method proposed in SEP could 1832 be used to find service peers which could provide TURN service. 1833 Alternatively, it also could get a TURN server in other ways, for 1834 example, from the enrollment server. 1836 9.1. Gather ICE candidates 1838 A peer could learn whether it is behind NAT by means of STUN. If it 1839 is, it should gather ICE candidates and put them into the Source Peer 1840 Info or Destination Peer Info respectively. By using these two 1841 attributes, the source peer and the destination peer could exchange 1842 the ICE candidates with each other and the ICE process would be 1843 started as suggested by [ICE]. 1845 The method to gather ICE candidates is similar to that described in 1846 [ICE]. ICE candidates are often carried by using SDP, but the Peer 1847 Address Info is used in the SEP. 1849 9.2. Response from the Destination Peer to the Source Peer 1851 If the source peer is on the public Internet, the response could be 1852 sent back directly from the destination peer to the source peer. If 1853 the source peer is behind the NAT, it should either relies on the 1854 relaying peer to relay response or use the overlay native routing. 1855 It should follow the routing operations described in section 7. 1857 9.2.1. How to Make JOIN Response Return to Source Peer 1859 JOIN message has a little difference from other message, because the 1860 joining peer has not joined the overlay and has no neighbors at that 1861 time. What the joining peer knows are only one or more bootstrap 1862 peers which are required to be on the public Internet. 1864 In order to make the JOIN response return to the source peer in the 1865 presence of NAT, the joining peer SHOULD set the J flag in the 1866 message header to show that the JOIN request has not been processed 1867 by any peer in the overlay. In the meantime, the joining peer SHOULD 1868 get the transport address of the bootstrap peer which will be the 1869 next hop of the JOIN request and fill it into the Relaying Peer Info. 1870 After finishing above tasks, the joining peer sends the JOIN request 1871 to the bootstrap peer. 1873 The bootstrap peer SHOULD check the J flag and decide whether it is 1874 the bootstrap peer of the JOIN request. If it is the bootstrap peer, 1875 it should record the source transport address of the JOIN request and 1876 fill it into the Source Reflexive Address attribute. The J flag MUST 1877 be cleared by the bootstrap peer. 1879 When the destination peer receives the JOIN request, if the source 1880 peer is behind NAT, sending the response by routing through the 1881 overlay won't make sense in that the joining peer has not been known 1882 by any peer in the overlay. So the only choice in SEP is for 1883 destination peer to relay the response to the source peer with the 1884 help of the relaying peer. In that case, the destination peer will 1885 send the response directly to the relaying peer and SHOULD put the 1886 Source Reflexive Address attribute unmodified into the response. 1888 After the bootstrap peer (now, it plays relaying peer role) receives 1889 JOIN response, it checks whether Source Reflexive Address attribute 1890 is carried in the response. If it is, JOIN response will be 1891 forwarded to the transport address which could be got from the Source 1892 Reflexive Address. Then the JOIN response returns to the source 1893 peer. 1895 9.3. Exchange Candidates for the Direct Communication 1897 Some operations may require a direct connection after the associated 1898 transaction finishes. But due to the existence of NAT, both peers 1899 should exchange their own candidates with each other and then use ICE 1900 to find out one or more workable candidate pairs. The transaction 1901 before the direct connection could be used as a signaling channel to 1902 exchange candidates. In order to achieve this, the source peer 1903 SHOULD set the D flag in the message header if it requires a later 1904 direct connection with the destination peer. 1906 After exchange candidates, ICE process will be started. (TO DO: how 1907 is SEP seamlessly integrated with the ICE process will explored in 1908 the next version.) 1910 10. Security Considerations 1912 Security considerations will be dicussed in the next version. 1914 11. IANA Considerations 1916 +-------------------+--------------+ 1917 | Message | Message Type | 1918 +-------------------+--------------+ 1919 | JOIN | 0 | 1920 | LEAVE | 1 | 1921 | KEEPALIVE | 2 | 1922 | NOTIFY | 3 | 1923 | UPDATE | 4 | 1924 | SearchPeer | 5 | 1925 | TRANSFER | 6 | 1926 | PUT | 7 | 1927 | GET | 8 | 1928 | REMOVE | 9 | 1929 | LookUpServicePeer | 10 | 1930 +-------------------+--------------+ 1932 12. Acknowledgements 1934 A team of guys contribute to this documents. Thanks for the effort 1935 from Alex, Watw, Justin and Rake. 1937 13. References 1939 13.1. Normative References 1941 RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1942 Requirement Levels", BCP 14, RFC 2119, March 1997. 1944 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1945 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1946 Session Initiation Protocol", RFC 3261, June 2002. 1948 [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1949 Methodology for Network Address Translator (NAT) Traversal for Offer/ 1950 Answer Protocols", Internet Draft draft-ietf-mmusic-ice (Work in 1951 Progress). 1953 [Concept] Bryan, D., Matthews, P., Shim, E., Willis, D., " Concepts 1954 and Terminology for Peer to Peer SIP " Internet Draft 1955 draft-ietf-p2psip-concepts-00 (Work in progress) 1957 [STUN] Rosenberg, J., Huitema, C., Mahy, R., Willis, D., "Session 1958 Traversal Utilities for (NAT) (STUN)" Internet Draft 1959 draft-ietf-behave-rfc3489bis (Work in Progress) 1961 [TURN] Rosenberg, J., Mahy, R., Huitema, C., "Obtaining Relay 1962 Addresses from Simple Traversal Underneath NAT (STUN)" Internet Draft 1963 draft-ietf-behave-turn(Work in Progress) 1965 13.2. Informative References 1967 [STUN Discovery] XingFeng Jiang, "A mechanism to discover STUN/TURN 1968 nodes in P2PSIP" Internet Draft draft-jiang-p2psip-STUN-discovery 1969 (Work in Progress) 1971 Authors' Addresses 1973 XingFeng Jiang 1974 Huawei Tech. 1975 Huihong Mansion,No.91 Baixia Rd. 1976 Nanjing, Jiangsu 210001 1977 P.R.China 1979 Phone: +86(25)84565468 1980 Email: jiang.x.f@huawei.com 1981 HeWen Zheng 1982 Huawei Tech. 1983 Huihong Mansion,No.91 Baixia Rd. 1984 Nanjing, Jiangsu P.R.China 1986 Phone: +86(25)84565467 1987 Email: hwzheng@huawei.com 1989 Carlos Macian Ruiz 1990 Pompeu Fabra University 1991 Barcelona, Passeig de la Circumval.lacio 8 08003 1992 Spain 1994 Phone: +34-93-5421498 1995 Fax: +34-93-5422517 1996 Email: carlos.macian@upf.edu 1998 Victor Pascual Avila 1999 Pompeu Fabra University 2000 Barcelona, Passeig de la Circumval.lacio 8 08003 2001 Spain 2003 Phone: +34-93-5421561 2004 Fax: +34-93-5422517 2005 Email: victor.pascuala@upf.edu 2007 Full Copyright Statement 2009 Copyright (C) The IETF Trust (2008). 2011 This document is subject to the rights, licenses and restrictions 2012 contained in BCP 78, and except as set forth therein, the authors 2013 retain all their rights. 2015 This document and the information contained herein are provided on an 2016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2018 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2019 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2020 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2023 Intellectual Property 2025 The IETF takes no position regarding the validity or scope of any 2026 Intellectual Property Rights or other rights that might be claimed to 2027 pertain to the implementation or use of the technology described in 2028 this document or the extent to which any license under such rights 2029 might or might not be available; nor does it represent that it has 2030 made any independent effort to identify any such rights. Information 2031 on the procedures with respect to rights in RFC documents can be 2032 found in BCP 78 and BCP 79. 2034 Copies of IPR disclosures made to the IETF Secretariat and any 2035 assurances of licenses to be made available, or the result of an 2036 attempt made to obtain a general license or permission for the use of 2037 such proprietary rights by implementers or users of this 2038 specification can be obtained from the IETF on-line IPR repository at 2039 http://www.ietf.org/ipr. 2041 The IETF invites any interested party to bring to its attention any 2042 copyrights, patents or patent applications, or other proprietary 2043 rights that may cover technology that may be required to implement 2044 this standard. Please address the information to the IETF at 2045 ietf-ipr@ietf.org. 2047 Acknowledgment 2049 Funding for the RFC Editor function is provided by the IETF 2050 Administrative Support Activity (IASA).