idnits 2.17.1 draft-ietf-p2psip-rpr-06.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 (May 07, 2013) is 4004 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 560, but no explicit reference was found in the text == Unused Reference: 'DTLS' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'I-D.lowekamp-mmusic-ice-tcp-framework' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 581, 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: November 08, 2013 Huawei Technologies 6 Y. Zhang 7 May 07, 2013 9 An extension to RELOAD to support Relay Peer Routing 10 draft-ietf-p2psip-rpr-06 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 November 08, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4 72 3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5 73 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 74 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 6 75 3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6 76 4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6 77 4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6 78 4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6 79 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 80 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 81 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 8 82 6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8 83 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8 84 6.2. Modification to RELOAD message structure . . . . . . . . 8 85 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8 86 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 87 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9 88 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10 89 6.4. Request and response processing . . . . . . . . . . . . . 10 90 6.4.1. Destination peer: receiving a request and sending a 91 response . . . . . . . . . . . . . . . . . . . . . . 10 92 6.4.2. Sending peer: receiving a response . . . . . . . . . 11 93 6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11 94 7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 97 9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 101 11.2. Informative References . . . . . . . . . . . . . . . . . 13 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 Appendix A. Optional methods to investigate peer connectivity . 13 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 106 1. Introduction 108 RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing 109 (SRR) for routing messages and describes the extensions that would be 110 required to support additional routing algorithms. Other than SRR, 111 two other routing options: direct response routing (DRR) and relay 112 peer routing (RPR) are also discussed in Appendix A of [I-D.ietf- 113 p2psip-base]. As we show in section 3, RPR is advantageous over SRR 114 in some scenarios reducing load (CPU and link bandwidth) on 115 intermediate peers. RPR works better in a network where relay peers 116 are provisioned in advance so that relay peers are publicly reachable 117 in the P2P system. In other scenarios, using a combination of RPR 118 and SRR together is more likely to bring benefits than if SRR is used 119 alone. 121 Note that in this document, we focus on RPR routing mode and its 122 extensions to RELOAD to produce a standalone solution. Please refer 123 to DRR document [I-D.ietf-p2psip-drr] for DRR routing mode. 125 We first discuss the problem statement in Section 3, then how to 126 combine RPR and SRR is presented in Section 4. In Section 5, we give 127 comparison on the cost of SRR and RPR in both managed and open 128 networks. An extension to RELOAD to support RPR is proposed in 129 Section 6. Discovery of relay peers is introduced in Section 7. 130 Some optional methods to check peer connectivity are introduced in 131 Appendix A. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 We use the terminology and definitions from the Concepts and 140 Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft 141 extensively in this document. We also use terms defined in NAT 142 behavior discovery [RFC5780]. Other terms used in this document are 143 defined inline when used and are also defined below for reference. 145 Publicly Reachable: A peer is publicly reachable if it can receive 146 unsolicited messages from any other peer in the same overlay. 147 Note: "publicly" does not mean that the peers must be on the 148 public Internet, because the RELOAD protocol may be used in a 149 closed system. 151 Relay Peer: A type of publicly reachable peer that can receive 152 unsolicited messages from all other peers in the overlay and 153 forward the responses from destination peers towards the sender of 154 the request. 156 Relay Peer Routing (RPR): refers to a routing mode in which 157 responses to P2PSIP requests are sent by the destination peer to a 158 relay peer transport address who will forward the responses 159 towards the sending peer. For simplicity, the abbreviation RPR is 160 used instead in the rest of the document. 162 Symmetric Recursive Routing (SRR): refers to a routing mode in 163 which responses follow the reverse path of the request to get to 164 the sending peer. For simplicity, the abbreviation SRR is used 165 instead in the rest of the document. 167 3. Overview 169 RELOAD is expected to work under a great number of application 170 scenarios. The situations where RELOAD is to be deployed differ 171 greatly. For instance, some deployments are global, such as a Skype- 172 like system intended to provide public service, while others run in 173 closed networks of small scale. SRR works in any situation, but RPR 174 may work better in some specific scenarios. 176 3.1. RPR 178 RELOAD is a simple request-response protocol. After sending a 179 request, a peer waits for a response from a destination peer. There 180 are several ways for the destination peer to send a response back to 181 the source peer. In this section, we will provide detailed 182 information on RPR. 184 Note that the same illustrative settings can be found in DRR document 185 [I-D.ietf-p2psip-drr]. 187 3.1.1. Relay Peer Routing (RPR) 189 If peer A knows it is behind a NAT or NATs, and knows one or more 190 relay peers with whom they have a prior connections, peer A can try 191 RPR. Assume A is associated with relay peer R. When sending the 192 request, peer A includes information describing peer R transport 193 address in the request. When peer X receives the request, peer X 194 sends the response to peer R, which forwards it directly to Peer A on 195 the existing connection. Figure 1 illustrates RPR. Note that RPR 196 also allows a shorter route for responses compared to SRR, which 197 means less overhead on intermediate peers. Establishing a connection 198 to the relay with TLS requires multiple round trips. Please refer to 199 Section 5 for cost comparison between SRR and RPR. 201 A B C D X R 202 | Request | | | | | 203 |----------->| | | | | 204 | | Request | | | | 205 | |----------->| | | | 206 | | | Request | | | 207 | | |----------->| | | 208 | | | | Request | | 209 | | | |----------->| | 210 | | | | | Response | 211 | | | | |---------->| 212 | | | | Response | | 213 |<-----------+------------+------------+------------+-----------| 214 | | | | | | 216 Figure 1. RPR routing mode 218 This technique relies on the relative population of peers such as A 219 that require relay peers, and peers such as R that are capable of 220 serving as a relay peers. It also requires a mechanism to enable 221 peers to know which peers can be used as their relays. This 222 mechanism may be based on configuration, for example as part of the 223 overlay configuration an initial list of relay peers can be supplied. 224 Another option is in a response message, the responding peer can 225 announce that it can serve as a relay peer. 227 3.2. Scenarios where RPR can be beneficial 229 In this section, we will list several scenarios where using RPR would 230 provide an improved performance. 232 3.2.1. Managed or closed P2P systems 234 As described in Section 3.2.1 of DRR draft [I-D.ietf-p2psip-drr], 235 many P2P systems run in a closed or managed environment so that 236 network administrators can better manage their system. For example, 237 the network administrator can deploy several relay peers which are 238 publicly reachable in the system and indicate their presence in the 239 configuration file. After learning where these relay peers are, 240 peers behind NATs can use RPR with the help from these relay peers. 241 Peers MUST also support SRR in case RPR fails. 243 Another usage is to install relay peers on the managed network 244 boundary allowing external peers to send responses to peers inside 245 the managed network. 247 3.2.2. Using bootstrap nodes as relay peers 249 Bootstrap nodes are typically publicly reachable in a RELOAD 250 architecture. As a result, one possible architecture would be to use 251 the bootstrap nodes as relay peers for use with RPR. A relay peer 252 SHOULD be publicly accessible and maintain a direct connection with 253 its client. As such, bootstrap nodes are well suited to play the 254 role of relay peers. 256 3.2.3. Wireless scenarios 258 In some mobile deployments, using RPR may help reducing radio battery 259 usage and bandwidth by the intermediate peers. The service provider 260 may recommend using RPR based on his knowledge of the topology. 262 4. Relationship between SRR and RPR 264 4.1. How RPR works 266 Peers using RPR MUST maintain a connection with their relay peer(s). 267 This can be done in the same way as establishing a neighbor 268 connection between peers by using the Attach method. 270 A requirement for RPR is for the source peer to convey their relay 271 peer (or peers) transport address in the request, so the destination 272 peer knows where the relay peer are and send the response to a relay 273 peer first. The request SHOULD include also the requesting peer 274 information enabling the relay peer to route the response back to the 275 right peer. 277 Note that being a relay peer does not require that the relay peer has 278 more functionality than an ordinary peer. As discussed later, relay 279 peers comply with the same procedure as an ordinary peer to forward 280 messages. The only difference is that there may be a larger traffic 281 burden on relay peers. Relay peers can decide whether to accept a 282 new connection based on their current burden. 284 4.2. How SRR and RPR work together 286 RPR is not intended to replace SRR. It is better to use these two 287 modes together to adapt to each peer's specific situation. Note that 288 the informative suggestions on how to transition between SRR and RPR 289 (e.g. compute success rate of RPR, fall back to SRR, etc) are the 290 same with that of DRR. Please refer to DRR document [I-D.ietf- 291 p2psip-drr] for more details. Similarly, the peer can decide whether 292 to try RPR based on other information such as configuration file 293 information. If a relay peer is provided by the service provider, 294 peers MAY prefer RPR over SRR. 296 5. Comparison on cost of SRR and RPR 298 The major advantage of the use of RPR is that it reduces the number 299 of intermediate peers traversed by the response. By doing that, it 300 reduces the load on those peers' resources like processing and 301 communication bandwidth. 303 5.1. Closed or managed networks 305 As described in Section 3, many P2P systems run in a closed or 306 managed environment (e.g. carrier networks) so that network 307 administrators would know that they could safely use RPR. 309 The number of hops for a response in SRR and RPR are listed in the 310 following table. Note that the same illustrative settings can be 311 found in DRR document [I-D.ietf-p2psip-drr]. 313 Mode | Success | No. of Hops | No. of Msgs 314 ---------------------------------------------------- 315 SRR | Yes | log(N) | log(N) 316 RPR | Yes | 2 | 2 317 RPR(DTLS) | Yes | 2 | 7+2 319 Table 1. Comparison of SRR and RPR in closed networks 321 From the above comparison, it is clear that: 323 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 324 Using a shorter route means less overhead and resource usage on 325 intermediate peers, which is an important consideration for adopting 326 RPR in the cases where the resources such as CPU and bandwidth are 327 limited, e.g. the case of mobile, wireless networks. 329 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 330 SRR. 332 3) In the cases when N < 512, RPR uses more messages than SRR (but 333 still uses fewer hops than SRR). So the consideration on whether 334 using RPR or SRR depends on other factors like using less resources 335 (bandwidth and processing) from the intermediate peers. Section 4 336 provides use cases where RPR has better chance to work or where the 337 intermediary resources considerations are important. 339 5.2. Open networks 341 In open networks where RPR is not guaranteed to work, RPR can fall 342 back to SRR if it fails after trial, as described in Section 4. 343 Based on the same settings of Section 5.1, the number of hops, number 344 of messages for a response in SRR and RPR are listed in the following 345 table. 347 Mode | Success | No. of Hops | No. of Msgs 348 ----------------------------------------------------------- 349 SRR | Yes | log(N) | log(N) 350 RPR | Yes | 2 | 2 351 | Fail&Fall back to SRR | 2+log(N)| 2+log(N) 352 RPR(DTLS) | Yes | 2 | 7+2 353 | Fail&Fall back to SRR | 2+log(N)| 9+log(N) 355 Table 2. Comparison of SRR and RPR in open networks 357 From the above comparison, it can be observed that trying to first 358 use RPR could still provide an overall number of hops lower than 359 directly using SRR. The detailed analysis is same as DRR case and 360 can be found in DRR document [I-D.ietf-p2psip-drr]. 362 6. RPR extensions to RELOAD 364 Adding support for RPR requires extensions to the current RELOAD 365 protocol. In this section, we define the extensions required to the 366 protocol, including extensions to message structure and to message 367 processing. 369 6.1. Basic requirements 371 All peers MUST be able to process requests for routing in SRR, and 372 MAY support RPR routing requests. 374 6.2. Modification to RELOAD message structure 376 RELOAD provides an extensible framework to accommodate future 377 extensions. In this section, we define a ForwardingOption structure 378 and present a state-keeping flag to support RPR mode. 380 6.2.1. State-keeping flag 381 flag : 0x08 IGNORE-STATE-KEEPING 383 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 384 which is not the destination of the message SHOULD forward the 385 message with the full via_list and SHOULD NOT maintain any internal 386 state. 388 6.2.2. Extensive routing mode 390 We first define a new type to define the new option, 391 extensive_routing_mode: 393 The option value is illustrated in the following figure, defining the 394 ExtensiveRoutingModeOption structure: 396 enum {(0),DRR(1),RPR(2),(255)} RouteMode; 397 struct { 398 RouteMode routemode; 399 OverlayLinkType transport; 400 IpAddressPort ipaddressport; 401 Destination destinations<1..2^8-1>; 402 } ExtensiveRoutingModeOption; 404 Note that DRR value in RouteMode is defined in DRR document [I-D 405 .ietf-p2psip-drr]. 407 RouteMode: refers to which type of routing mode is indicated to the 408 destination peer. 410 OverlayLinkType: refers to the transport type which is used to 411 deliver responses from the destination peer to the relay peer. 413 IpAddressPort: refers to the transport address that the destination 414 peer should use to send the response to. This will be a relay peer 415 address for RPR. 417 Destination: refers to the relay peer itself. If the routing mode is 418 RPR, then the destination contains two destinations, which are the 419 relay peer's Node-ID and the sending peer's Node-ID. 421 6.3. Creating a request 422 6.3.1. Creating a request for RPR 424 When using RPR for a transaction, the sending peer MUST set the 425 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 426 peer MUST construct and include a ForwardingOptions structure in the 427 ForwardingHeader. When constructing the ForwardingOption structure, 428 the fields MUST be set as follows: 430 1) The type MUST be set to extensive_routing_mode. 432 2) The ExtensiveRoutingModeOption structure MUST be used for the 433 option field within the ForwardingOptions structure. The fields MUST 434 be defined as follows: 436 2.1) routemode set to 0x02 (RPR). 438 2.2) transport set as appropriate for the relay peer. 440 2.3) ipaddressport set to the transport address of the relay peer 441 that the sender wishes the message to be relayed through. 443 2.4) destination structure MUST contain two values. The first MUST 444 be defined as type node and set with the values for the relay peer. 445 The second MUST be defined as type node and set with the sending 446 peer's own values. 448 6.4. Request and response processing 450 This section gives normative text for message processing after RPR is 451 introduced. Here, we only describe the additional procedures for 452 supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD 453 base procedures. 455 6.4.1. Destination peer: receiving a request and sending a response 457 When the destination peer receives a request, it will check the 458 options in the forwarding header. If the destination peer can not 459 understand extensive_routing_mode option in the request, it MUST 460 attempt using SRR to return an "Error_Unknown_Extension" response 461 (defined in Section 6.3.3.1 and Section 14.9 of [I-D.ietf-p2psip- 462 base]) to the sending peer. 464 If the routing mode is RPR, the destination peer MUST construct a 465 destination_list for the response with two entries. The first MUST 466 be set to the relay peer Node-ID from the option in the request and 467 the second MUST be the sending peer Node-ID from the option of the 468 request. 470 In the event that the routing mode is set to RPR and there are not 471 exactly two destinations, the destination peer MUST try to send an 472 "Error_Unknown_Extension" response (defined in Section 6.3.3.1 and 473 Section 14.9 of [I-D.ietf-p2psip-base]) to the sending peer using 474 SRR. 476 After the peer constructs the destination_list for the response, it 477 sends the response to the transport address which is indicated in the 478 ipaddressport field in the option using the specific transport mode 479 in the Forwardingoption. If the destination peer receives a 480 retransmit with SRR preference on the message it is trying to 481 response to now, the responding peer SHOULD abort the RPR response 482 and use SRR. 484 6.4.2. Sending peer: receiving a response 486 Upon receiving a response, the peer follows the rules in [I-D.ietf- 487 p2psip-base]. If the sender used RPR and does not get a response 488 until the timeout, it MAY either resend the message using RPR but 489 with a different relay peer (if available), or resend the message 490 using SRR. 492 6.4.3. Relay peer processing 494 Relay peers are designed to forward responses to peers who are not 495 publicly reachable. For the routing of the response, this document 496 still uses the destination_list. The only difference from SRR is 497 that the destination_list is not the reverse of the via_list. 498 Instead, it is constructed from the forwarding option as described 499 below. 501 When a relay peer receives a response, it MUST follow the rules in 502 [I-D.ietf-p2psip-base]. It receives the response, validates the 503 message, re-adjust the destination_list and forward the response to 504 the next hop in the destination_list based on the connection table. 505 There is no added requirement for relay peer. 507 7. Discovery of relay peers 508 There are several ways to distribute the information about relay 509 peers throughout the overlay. P2P network providers can deploy some 510 relay peers and advertise them in the configuration file. With the 511 configuration file at hand, peers can get relay peers to try RPR. 512 Another way is to consider relay peer as a service and then some 513 service advertisement and discovery mechanism can also be used for 514 discovering relay peers, for example, using the same mechanism as 515 used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. 516 Another option is to let a peer advertise his capability to be a 517 relay in the response to ATTACH or JOIN. 519 8. Security Considerations 521 As a routing alternative, the security part of RPR conforms to 522 section 13.6 of the base draft [I-D.ietf-p2psip-base] which describes 523 routing security. RPR behave like a DRR requesting node towards the 524 destination node. The RPR relay node is not an arbitrary node but 525 SHOULD be a trusted one (managed network, bootstrap nodes or 526 configured relay) which will make it less of a risk as outlined in 527 section13 of the based draft. 529 9. IANA Considerations 531 9.1. A new RELOAD Forwarding Option 533 A new RELOAD Forwarding Option type is added to the Forwarding Option 534 Registry defined in [I-D.ietf-p2psip-base]. 536 Type: 0x02 - extensive_routing_mode 538 10. Acknowledgements 540 David Bryan has helped extensively with this document, and helped 541 provide some of the text, analysis, and ideas contained here. The 542 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 543 Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and 544 Carlos Jesus Bernardos Cano for their constructive comments. 546 11. References 548 11.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 554 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 555 (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in 556 progress), February 2013. 558 11.2. Informative References 560 [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the 561 USENIX Annual Technical Conference. Handling Churn in a DHT, June 562 2004. 564 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of 565 Datagram TLS", 11th Network and Distributed System Security Symposium 566 (NDSS), 2004. 568 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 569 Using STUN", RFC5780, May 2010. 571 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 572 Srisuresh, "NAT Behavioral Requirements for TCP", RFC5382, October 573 2008. 575 [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, 576 "A Proposal to Define Interactive Connectivity Establishment for the 577 Transport Control Protocol (ICE-TCP) as an Extensible Framework", 578 draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), 579 October 2008. 581 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 582 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 583 January 2007. 585 [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 586 "An extension to RELOAD to support Direct Response Routing", draft- 587 ietf-p2psip-drr-05, April 2013. 589 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 590 D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", 591 draft-ietf-p2psip-concepts-04 (work in progress), October 2011. 593 12. References 595 Appendix A. Optional methods to investigate peer connectivity 597 This section is for informational purposes only for providing some 598 mechanisms that can be used when the configuration information does 599 not specify if RPR can be used. It summarizes some methods which can 600 be used for a peer to determine its own network location compared 601 with NAT. These methods may help a peer to decide which routing mode 602 it may wish to try. Note that there is no foolproof way to determine 603 if a peer is publically reachable, other than via out-of-band 604 mechanisms. As such, peers using these mechanisms may be able to 605 optimize traffic, but must be able to fall back to SRR routing if the 606 other routing mechanisms fail. 608 For RPR to function correctly, a peer may attempt to determine 609 whether it is publicly reachable. If it is not, RPR may be chosen to 610 route the response with the help from relay peers, or the peers 611 should fall back to SRR. NATs and firewalls are two major 612 contributors preventing RPR from functioning properly. There are a 613 number of techniques by which a peer can get its reflexive address on 614 the public side of the NAT. After obtaining the reflexive address, a 615 peer can perform further tests to learn whether the reflexive address 616 is publicly reachable. If the address appears to be publicly 617 reachable, the peers to which the address belongs can be a candidate 618 to serve as a relay peer. Peers which are not publicly reachable may 619 still use RPR to shorten the response path with the help from relay 620 peers. 622 Some conditions are unique in P2PSIP architecture which could be 623 leveraged to facilitate the tests. In P2P overlay network, each peer 624 only has partial a view of the whole network, and knows of a few 625 peers in the overlay. P2P routing algorithms can easily deliver a 626 request from a sending peer to a peer with whom the sending peer has 627 no direct connection. This makes it easy for a peer to ask other 628 peers to send unsolicited messages back to the requester. 630 The approaches for a peer to get the addresses needed for the further 631 tests, as well as the test for learning whether a peer may be 632 publicly reachable is same as the DRR case. Please refer to DRR 633 document [I-D.ietf-p2psip-drr] for more details. 635 Authors' Addresses 637 Ning Zong 638 Huawei Technologies 640 Email: zongning@huawei.com 642 Xingfeng Jiang 643 Huawei Technologies 645 Email: jiang.x.f@huawei.com 646 Roni Even 647 Huawei Technologies 649 Email: roni.even@mail01.huawei.com 651 Yunfei Zhang 653 Email: hishigh@gmail.com