idnits 2.17.1 draft-ietf-p2psip-rpr-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 08, 2013) is 4035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ChurnDHT' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'DTLS' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'I-D.lowekamp-mmusic-ice-tcp-framework' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 586, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-p2psip-drr-05 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP N. Zong 3 Internet-Draft X. Jiang 4 Intended status: Standards Track R. Even 5 Expires: October 10, 2013 Huawei Technologies 6 Y. Zhang 7 April 08, 2013 9 An extension to RELOAD to support Relay Peer Routing 10 draft-ietf-p2psip-rpr-05 12 Abstract 14 This document proposes an optional extension to RELOAD to support 15 relay peer routing mode. RELOAD recommends symmetric recursive 16 routing for routing messages. The new optional extension provides a 17 shorter route for responses reducing the overhead on intermediate 18 peers and describes the potential use cases where this extension can 19 be used. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 10, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Backgrounds . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4 73 3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5 74 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 75 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 6 76 3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6 77 4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6 78 4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6 79 4.2. How SRR and RPR Work Together . . . . . . . . . . . . . . 7 80 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 81 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 82 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 8 83 6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8 84 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8 85 6.2. Modification to RELOAD message structure . . . . . . . . 9 86 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 9 87 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 88 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 10 89 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10 90 6.4. Request and response processing . . . . . . . . . . . . . 10 91 6.4.1. Destination peer: receiving a request and sending a 92 response . . . . . . . . . . . . . . . . . . . . . . 10 93 6.4.2. Sending peer: receiving a response . . . . . . . . . 11 94 6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11 95 7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 12 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 102 11.2. Informative References . . . . . . . . . . . . . . . . . 13 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 Appendix A. Optional methods to investigate peer connectivity . 13 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 107 1. Introduction 109 1.1. Backgrounds 111 RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing 112 (SRR) for routing messages and describes the extensions that would be 113 required to support additional routing algorithms. Other than SRR, 114 two other routing options: direct response routing (DRR) and relay 115 peer routing (RPR) are also discussed in Appendix A of [I-D.ietf- 116 p2psip-base]. As we show in section 3, RPR is advantageous over SRR 117 in some scenarios reducing load (CPU and link bandwidth) on 118 intermediate peers. RPR works better in a network where relay peers 119 are provisioned in advance so that relay peers are publicly reachable 120 in the P2P system. In other scenarios, using a combination of RPR 121 and SRR together is more likely to bring benefits than if SRR is used 122 alone. 124 Note that in this document, we focus on RPR routing mode and its 125 extensions to RELOAD to produce a standalone solution. Please refer 126 to DRR draft [I-D.ietf-p2psip-drr] for DRR routing mode. 128 We first discuss the problem statement in Section 3, then how to 129 combine RPR and SRR is presented in Section 4. In Section 5, we give 130 comparison on the cost of SRR and RPR in both managed and open 131 networks. An extension to RELOAD to support RPR is proposed in 132 Section 6. Discovery of relay peers is introduced in Section 7. 133 Some optional methods to check peer connectivity are introduced in 134 Appendix A. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 We use the terminology and definitions from the Concepts and 143 Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft 144 extensively in this document. We also use terms defined in NAT 145 behavior discovery [RFC5780]. Other terms used in this document are 146 defined inline when used and are also defined below for reference. 148 Publicly Reachable: A peer is publicly reachable if it can receive 149 unsolicited messages from any other peer in the same overlay. 150 Note: "publicly" does not mean that the peers must be on the 151 public Internet, because the RELOAD protocol may be used in a 152 closed system. 154 Relay Peer: A type of publicly reachable peer that can receive 155 unsolicited messages from all other peers in the overlay and 156 forward the responses from destination peers towards the sender of 157 the request. 159 Relay Peer Routing (RPR): refers to a routing mode in which 160 responses to P2PSIP requests are sent by the destination peer to a 161 relay peer transport address who will forward the responses 162 towards the sending peer. For simplicity, the abbreviation RPR is 163 used instead in the rest of the document. 165 Symmetric Recursive Routing (SRR): refers to a routing mode in 166 which responses follow the reverse path of the request to get to 167 the sending peer. For simplicity, the abbreviation SRR is used 168 instead in the rest of the document. 170 3. Introduction 172 RELOAD is expected to work under a great number of application 173 scenarios. The situations where RELOAD is to be deployed differ 174 greatly. For instance, some deployments are global, such as a Skype- 175 like system intended to provide public service, while others run in 176 closed networks of small scale. SRR works in any situation, but RPR 177 may work better in some specific scenarios. 179 3.1. Overview 181 RELOAD is a simple request-response protocol. After sending a 182 request, a peer waits for a response from a destination peer. There 183 are several ways for the destination peer to send a response back to 184 the source peer. In this section, we will provide detailed 185 information on RPR. 187 Note that the same illustrative settings can be found in DRR draft 188 [I-D.ietf-p2psip-drr]. 190 3.1.1. Relay Peer Routing (RPR) 191 If peer A knows it is behind a NAT or NATs, and knows one or more 192 relay peers with whom they have a prior connections, peer A can try 193 RPR. Assume A is associated with relay peer R. When sending the 194 request, peer A includes information describing peer R transport 195 address in the request. When peer X receives the request, peer X 196 sends the response to peer R, which forwards it directly to Peer A on 197 the existing connection. Figure 1 illustrates RPR. Note that RPR 198 also allows a shorter route for responses compared to SRR, which 199 means less overhead on intermediate peers. Establishing a connection 200 to the relay with TLS requires multiple round trips. Please refer to 201 Section 5 for cost comparison between SRR and RPR. 203 A B C D X R 204 | Request | | | | | 205 |----------->| | | | | 206 | | Request | | | | 207 | |----------->| | | | 208 | | | Request | | | 209 | | |----------->| | | 210 | | | | Request | | 211 | | | |----------->| | 212 | | | | | Response | 213 | | | | |---------->| 214 | | | | Response | | 215 |<-----------+------------+------------+------------+-----------| 216 | | | | | | 218 Figure 1, RPR 220 This technique relies on the relative population of peers such as A 221 that require relay peers, and peers such as R that are capable of 222 serving as a relay peers. It also requires a mechanism to enable 223 peers to know which peers can be used as their relays. This 224 mechanism may be based on configuration, for example as part of the 225 overlay configuration an initial list of relay peers can be supplied. 226 Another option is in a response message, the responding peer can 227 announce that it can serve as a relay peer. 229 3.2. Scenarios where RPR can be beneficial 231 In this section, we will list several scenarios where using RPR would 232 provide an improved performance. 234 3.2.1. Managed or closed P2P systems 236 As described in Section 3.2.1 of DRR draft [I-D.ietf-p2psip-drr], 237 many P2P systems run in a closed or managed environment so that 238 network administrators can better manage their system. For example, 239 the network administrator can deploy several relay peers which are 240 publicly reachable in the system and indicate their presence in the 241 configuration file. After learning where these relay peers are, 242 peers behind NATs can use RPR with the help from these relay peers. 243 Peers MUST also support SRR in case RPR fails. 245 Another usage is to install relay peers on the managed network 246 boundary allowing external peers to send responses to peers inside 247 the managed network. 249 3.2.2. Using bootstrap nodes as relay peers 251 Bootstrap nodes are typically publicly reachable in a RELOAD 252 architecture. As a result, one possible architecture would be to use 253 the bootstrap nodes as relay peers for use with RPR. A relay peer 254 SHOULD be publicly accessible and maintaining a direct connection 255 with its client. As such, bootstrap nodes are well suited to play 256 the role of relay peers. 258 3.2.3. Wireless scenarios 260 In some mobile deployments, using RPR may help reducing radio battery 261 usage and bandwidth by the intermediate peers. The service provider 262 may recommend using RPR based on his knowledge of the topology. 264 4. Relationship between SRR and RPR 266 4.1. How RPR works 268 Peers using RPR MUST maintain a connection with their relay peer(s). 269 This can be done in the same way as establishing a neighbor 270 connection between peers by using the Attach method. 272 A requirement for RPR is for the source peer to convey their relay 273 peer (or peers) transport address in the request, so the destination 274 peer knows where the relay peer are and send the response to a relay 275 peer first. The request SHOULD include also the requesting peer 276 information enabling the relay peer to route the response back to the 277 right peer. 279 Note that being a relay peer does not require that the relay peer has 280 more functionality than an ordinary peer. As discussed later, relay 281 peers comply with the same procedure as an ordinary peer to forward 282 messages. The only difference is that there may be a larger traffic 283 burden on relay peers. Relay peers can decide whether to accept a 284 new connection based on their current burden. 286 4.2. How SRR and RPR Work Together 288 RPR is not intended to replace SRR. It is better to use these two 289 modes together to adapt to each peer's specific situation. Note that 290 the informative suggestions on how to transition between SRR and RPR 291 (e.g. compute success rate of RPR, fall back to SRR, etc) are the 292 same with that of DRR. Please refer to DRR draft [I-D.ietf-p2psip- 293 drr] for more details. Similarly, the peer can decide whether to try 294 RPR based on other information such as configuration file 295 information. If a relay peer is provided by the service provider, 296 peers MAY prefer RPR over SRR. 298 5. Comparison on cost of SRR and RPR 300 The major advantage of the use of RPR is that it reduces the number 301 of intermediate peers traversed by the response. By doing that, it 302 reduces the load on those peers' resources like processing and 303 communication bandwidth. 305 5.1. Closed or managed networks 307 As described in Section 3, many P2P systems run in a closed or 308 managed environment (e.g. carrier networks) so that network 309 administrators would know that they could safely use RPR. 311 The number of hops for a response in SRR and RPR are listed in the 312 following table. Note that the same illustrative settings can be 313 found in DRR draft [I-D.ietf-p2psip-drr]. 315 Mode | Success | No. of Hops | No. of Msgs 316 ---------------------------------------------------- 317 SRR | Yes | log(N) | log(N) 318 RPR | Yes | 2 | 2 319 RPR(DTLS) | Yes | 2 | 7+2 321 Table 1, comparison of SRR and RPR in closed networks 323 From the above comparison, it is clear that: 325 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 326 Using a shorter route means less overhead and resource usage on 327 intermediate peers, which is an important consideration for adopting 328 RPR in the cases where the resources such as CPU and bandwidth are 329 limited, e.g. the case of mobile, wireless networks. 331 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 332 SRR. 334 3) In the cases when N < 512, RPR uses more messages than SRR (but 335 still uses fewer hops than SRR). So the consideration on whether 336 using RPR or SRR depends on other factors like using less resources 337 (bandwidth and processing) from the intermediate peers. Section 4 338 provides use cases where RPR has better chance to work or where the 339 intermediary resources considerations are important. 341 5.2. Open networks 343 In open networks where RPR is not guaranteed to work, RPR can fall 344 back to SRR if it fails after trial, as described in Section 4. 345 Based on the same settings in Section 5.1, the number of hops, number 346 of messages for a response in SRR and RPR are listed in the following 347 table. 349 Mode | Success | No. of Hops | No. of Msgs 350 ----------------------------------------------------------- 351 SRR | Yes | logN | logN 352 RPR | Yes | 2 | 2 353 | Fail&Fall back to SRR | 2+logN | 2+logN 354 RPR(DTLS) | Yes | 2 | 7+2 355 | Fail&Fall back to SRR | 2+logN | 9+logN 357 Table 2, comparison of SRR and RPR in open networks 359 From the above comparison, it can be observed that trying to first 360 use RPR could still provide an overall number of hops lower than 361 directly using SRR. The detailed analysis is same as DRR case and 362 can be found in DRR draft [I-D.ietf-p2psip-drr]. 364 6. RPR extensions to RELOAD 366 Adding support for RPR requires extensions to the current RELOAD 367 protocol. In this section, we define the extensions required to the 368 protocol, including extensions to message structure and to message 369 processing. 371 6.1. Basic requirements 373 All peers MUST be able to process requests for routing in SRR, and 374 MAY support RPR routing requests. 376 6.2. Modification to RELOAD message structure 378 RELOAD provides an extensible framework to accommodate future 379 extensions. In this section, we define a ForwardingOption structure 380 and present a state-keeping flag to support RPR mode. 382 6.2.1. State-keeping flag 384 flag : 0x08 IGNORE-STATE-KEEPING 386 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 387 which is not the destination of the message SHOULD forward the 388 message with the full via_list and SHOULD NOT maintain any internal 389 state. 391 6.2.2. Extensive routing mode 393 We first define a new type to define the new option, 394 extensive_routing_mode: 396 The option value is illustrated in the following figure, defining the 397 ExtensiveRoutingModeOption structure: 399 enum {(0),DRR(1),RPR(2),(255)} RouteMode; 400 struct { 401 RouteMode routemode; 402 OverlayLinkType transport; 403 IpAddressPort ipaddressport; 404 Destination destinations<1..2^8-1>; 405 } ExtensiveRoutingModeOption; 407 Note that DRR value in RouteMode is defined in DRR draft [I-D.ietf- 408 p2psip-drr]. 410 RouteMode: refers to which type of routing mode is indicated to the 411 destination peer. 413 OverlayLinkType: refers to the transport type which is used to 414 deliver responses from the destination peer to the relay peer. 416 IpAddressPort: refers to the transport address that the destination 417 peer should use to send the response to. This will be a relay peer 418 address for RPR. 420 Destination: refers to the relay peer itself. If the routing mode is 421 RPR, then the destination contains two destinations, which are the 422 relay peer's Node-ID and the sending peer's Node-ID. 424 6.3. Creating a request 426 6.3.1. Creating a request for RPR 428 When using RPR for a transaction, the sending peer MUST set the 429 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 430 peer MUST construct and include a ForwardingOptions structure in the 431 ForwardingHeader. When constructing the ForwardingOption structure, 432 the fields MUST be set as follows: 434 1) The type MUST be set to extensive_routing_mode. 436 2) The ExtensiveRoutingModeOption structure MUST be used for the 437 option field within the ForwardingOptions structure. The fields MUST 438 be defined as follows: 440 2.1) routemode set to 0x02 (RPR). 442 2.2) transport set as appropriate for the relay peer. 444 2.3) ipaddressport set to the transport address of the relay peer 445 that the sender wishes the message to be relayed through. 447 2.4) destination structure MUST contain two values. The first MUST 448 be defined as type node and set with the values for the relay peer. 449 The second MUST be defined as type node and set with the sending 450 peer's own values. 452 6.4. Request and response processing 454 This section gives normative text for message processing after RPR is 455 introduced. Here, we only describe the additional procedures for 456 supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD 457 base procedures. 459 6.4.1. Destination peer: receiving a request and sending a response 461 When the destination peer receives a request, it will check the 462 options in the forwarding header. If the destination peer can not 463 understand extensive_routing_mode option in the request, it MUST 464 attempt using SRR to return an "Error_Unknown_Extension" response 465 (defined in Section 6.3.3.1 and Section 14.9 of [I-D.ietf-p2psip- 466 base]) to the sending peer. 468 If the routing mode is RPR, the destination peer MUST construct a 469 destination_list for the response with two entries. The first MUST 470 be set to the relay peer Node-ID from the option in the request and 471 the second MUST be the sending peer Node-ID from the option of the 472 request. 474 In the event that the routing mode is set to RPR and there are not 475 exactly two destinations, the destination peer MUST try to send an 476 "Error_Unknown_Extension" response (defined in Section 6.3.3.1 and 477 Section 14.9 of [I-D.ietf-p2psip-base]) to the sending peer using 478 SRR. 480 After the peer constructs the destination_list for the response, it 481 sends the response to the transport address which is indicated in the 482 ipaddressport field in the option using the specific transport mode 483 in the Forwardingoption. If the destination peer receives a 484 retransmit with SRR preference on the message it is trying to 485 response to now, the responding peer SHOULD abort the RPR response 486 and use SRR. 488 6.4.2. Sending peer: receiving a response 490 Upon receiving a response, the peer follows the rules in [I-D.ietf- 491 p2psip-base]. If the sender used RPR and does not get a response 492 until the timeout, it MAY either resend the message using RPR but 493 with a different relay peer (if available), or resend the message 494 using SRR. 496 6.4.3. Relay peer processing 498 Relay peers are designed to forward responses to peers who are not 499 publicly reachable. For the routing of the response, this document 500 still uses the destination_list. The only difference from SRR is 501 that the destination_list is not the reverse of the via_list. 502 Instead, it is constructed from the forwarding option as described 503 below. 505 When a relay peer receives a response, it MUST follow the rules in 506 [I-D.ietf-p2psip-base]. It receives the response, validates the 507 message, re-adjust the destination_list and forward the response to 508 the next hop in the destination_list based on the connection table. 509 There is no added requirement for relay peer. 511 7. Discovery of relay peers 513 There are several ways to distribute the information about relay 514 peers throughout the overlay. P2P network providers can deploy some 515 relay peers and advertise them in the configuration file. With the 516 configuration file at hand, peers can get relay peers to try RPR. 517 Another way is to consider relay peer as a service and then some 518 service advertisement and discovery mechanism can also be used for 519 discovering relay peers, for example, using the same mechanism as 520 used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. 521 Another option is to let a peer advertise his capability to be a 522 relay in the response to ATTACH or JOIN. 524 8. Security Considerations 526 As a routing alternative, the security part of RPR conforms to 527 section 13.6 of the base draft [I-D.ietf-p2psip-base] which describes 528 routing security. RPR behave like a DRR requesting node towards the 529 destination node. The RPR relay node is not an arbitrary node but 530 SHOULD be a trusted one (managed network, bootstrap nodes or 531 configured relay) which will make it less of a risk as outlined in 532 section13 of the based draft. 534 9. IANA Considerations 536 9.1. A new RELOAD Forwarding Option 538 A new RELOAD Forwarding Option type is added to the Forwarding Option 539 Registry defined in [I-D.ietf-p2psip-base]. 541 Type: 0x02 - extensive_routing_mode 543 10. Acknowledgements 545 David Bryan has helped extensively with this document, and helped 546 provide some of the text, analysis, and ideas contained here. The 547 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 548 Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and 549 Carlos Jesus Bernardos Cano for their constructive comments. 551 11. References 553 11.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 559 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 560 (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in 561 progress), February 2013. 563 11.2. Informative References 565 [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the 566 USENIX Annual Technical Conference. Handling Churn in a DHT, June 567 2004. 569 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of 570 Datagram TLS", 11th Network and Distributed System Security Symposium 571 (NDSS), 2004. 573 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 574 Using STUN", RFC5780, May 2010. 576 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 577 Srisuresh, "NAT Behavioral Requirements for TCP", RFC5382, October 578 2008. 580 [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, 581 "A Proposal to Define Interactive Connectivity Establishment for the 582 Transport Control Protocol (ICE-TCP) as an Extensible Framework", 583 draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), 584 October 2008. 586 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 587 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 588 January 2007. 590 [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 591 "An extension to RELOAD to support Direct Response Routing", draft- 592 ietf-p2psip-drr-05, April 2013. 594 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 595 D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", 596 draft-ietf-p2psip-concepts-04 (work in progress), October 2011. 598 12. References 600 Appendix A. Optional methods to investigate peer connectivity 602 This section is for informational purposes only for providing some 603 mechanisms that can be used when the configuration information does 604 not specify if RPR can be used. It summarizes some methods which can 605 be used for a peer to determine its own network location compared 606 with NAT. These methods may help a peer to decide which routing mode 607 it may wish to try. Note that there is no foolproof way to determine 608 if a peer is publically reachable, other than via out-of-band 609 mechanisms. As such, peers using these mechanisms may be able to 610 optimize traffic, but must be able to fall back to SRR routing if the 611 other routing mechanisms fail. 613 For RPR to function correctly, a peer may attempt to determine 614 whether it is publicly reachable. If it is not, RPR may be chosen to 615 route the response with the help from relay peers, or the peers 616 should fall back to SRR. NATs and firewalls are two major 617 contributors preventing RPR from functioning properly. There are a 618 number of techniques by which a peer can get its reflexive address on 619 the public side of the NAT. After obtaining the reflexive address, a 620 peer can perform further tests to learn whether the reflexive address 621 is publicly reachable. If the address appears to be publicly 622 reachable, the peers to which the address belongs can be a candidate 623 to serve as a relay peer. Peers which are not publicly reachable may 624 still use RPR to shorten the response path with the help from relay 625 peers. 627 Some conditions are unique in P2PSIP architecture which could be 628 leveraged to facilitate the tests. In P2P overlay network, each peer 629 only has partial a view of the whole network, and knows of a few 630 peers in the overlay. P2P routing algorithms can easily deliver a 631 request from a sending peer to a peer with whom the sending peer has 632 no direct connection. This makes it easy for a peer to ask other 633 peers to send unsolicited messages back to the requester. 635 The approaches for a peer to get the addresses needed for the further 636 tests, as well as the test for learning whether a peer may be 637 publicly reachable is same as the DRR case. Please refer to DRR 638 draft [I-D.ietf-p2psip-drr] for more details. 640 Authors' Addresses 642 Ning Zong 643 Huawei Technologies 645 Email: zongning@huawei.com 647 Xingfeng Jiang 648 Huawei Technologies 650 Email: jiang.x.f@huawei.com 651 Roni Even 652 Huawei Technologies 654 Email: roni.even@mail01.huawei.com 656 Yunfei Zhang 658 Email: hishigh@gmail.com