idnits 2.17.1 draft-ietf-p2psip-rpr-11.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 date (October 21, 2013) is 3839 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP N. Zong, Ed. 3 Internet-Draft X. Jiang 4 Intended status: Standards Track R. Even 5 Expires: April 24, 2014 Huawei Technologies 6 Y. Zhang 7 CoolPad 8 October 21, 2013 10 An Extension to REsource LOcation And Discovery (RELOAD) Protocol to 11 Support Relay Peer Routing 12 draft-ietf-p2psip-rpr-11 14 Abstract 16 This document proposes an optional extension to REsource LOcation And 17 Discovery (RELOAD) protocol to support relay peer routing mode. 18 RELOAD recommends symmetric recursive routing for routing messages. 19 The new optional extension provides a shorter route for responses 20 reducing the overhead on intermediate peers and describes the 21 potential use cases where this extension can be used. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 24, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Scenarios where RPR can be used . . . . . . . . . . . . . 5 62 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 63 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 5 64 3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6 65 4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6 66 4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6 68 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 69 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 70 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 7 71 6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8 72 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8 73 6.2. Modification to RELOAD message structure . . . . . . . . 8 74 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8 75 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 76 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9 77 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 9 78 6.4. Request and response processing . . . . . . . . . . . . . 10 79 6.4.1. Destination peer: receiving a request and sending a 80 response . . . . . . . . . . . . . . . . . . . . . . 10 81 6.4.2. Sending peer: receiving a response . . . . . . . . . 11 82 6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11 83 7. Overlay configuration extension . . . . . . . . . . . . . . . 11 84 8. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 88 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 12.2. Informative References . . . . . . . . . . . . . . . . . 12 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 Appendix A. Optional methods to investigate peer connectivity . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 REsource LOcation And Discovery (RELOAD) protocol [I-D.ietf-p2psip- 99 base] recommends symmetric recursive routing (SRR) for routing 100 messages and describes the extensions that would be required to 101 support additional routing algorithms. Other than SRR, two other 102 routing options: direct response routing (DRR) and relay peer routing 103 (RPR) are also discussed in Appendix A of [I-D.ietf-p2psip-base]. As 104 we show in section 3, RPR is advantageous over SRR in some scenarios 105 reducing load (CPU and link bandwidth) on intermediate peers. RPR 106 works better in a network where relay peers are provisioned in 107 advance so that relay peers are publicly reachable in the P2P system. 108 In other scenarios, using a combination of RPR and SRR together is 109 more likely to bring benefits than if SRR is used alone. 111 Note that in this document, we focus on RPR routing mode and its 112 extensions to RELOAD to produce a standalone solution. Please refer 113 to DRR document [I-D.ietf-p2psip-drr] for DRR routing mode. 115 We first discuss the problem statement in Section 3, then how to 116 combine RPR and SRR is presented in Section 4. In Section 5, we give 117 comparison on the cost of SRR and RPR in both managed and open 118 networks. An extension to RELOAD to support RPR is proposed in 119 Section 6. Discovery of relay peers is introduced in Section 7. 120 Some optional methods to check peer connectivity are introduced in 121 Appendix A. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 We use the terminology and definitions from the RELOAD base draft 130 [I-D.ietf-p2psip-base] extensively in this document. We also use 131 terms defined in NAT behavior discovery [RFC5780]. Other terms used 132 in this document are defined inline when used and are also defined 133 below for reference. 135 Publicly Reachable: A peer is publicly reachable if it can receive 136 unsolicited messages from any other peer in the same overlay. 137 Note: "publicly" does not mean that the peers must be on the 138 public Internet, because the RELOAD protocol may be used in a 139 closed network. 141 Relay Peer: A type of publicly reachable peer that can receive 142 unsolicited messages from all other peers in the overlay and 143 forward the responses from destination peers towards the sender of 144 the request. 146 Relay Peer Routing (RPR): refers to a routing mode in which 147 responses to P2PSIP requests are sent by the destination peer to a 148 relay peer transport address who will forward the responses 149 towards the sending peer. For simplicity, the abbreviation RPR is 150 used instead in the rest of the document. 152 Symmetric Recursive Routing (SRR): refers to a routing mode in 153 which responses follow the reverse path of the request to get to 154 the sending peer. For simplicity, the abbreviation SRR is used 155 instead in the rest of the document. 157 3. Overview 159 RELOAD is expected to work under a great number of application 160 scenarios. The situations where RELOAD is to be deployed differ 161 greatly. For instance, some deployments are global, such as a Skype- 162 like system intended to provide public service, while others run in 163 closed networks of small scale. SRR works in any situation, but RPR 164 may work better in some specific scenarios. 166 3.1. RPR 168 RELOAD is a simple request-response protocol. After sending a 169 request, a peer waits for a response from a destination peer. There 170 are several ways for the destination peer to send a response back to 171 the source peer. In this section, we will provide detailed 172 information on RPR. Note that the same illustrative settings can be 173 found in DRR document [I-D.ietf-p2psip-drr]. 175 If peer A knows it is behind a NAT or NATs, and knows one or more 176 relay peers with whom they have a prior connections, peer A can try 177 RPR. Assume A is associated with relay peer R. When sending the 178 request, peer A includes information describing peer R transport 179 address in the request. When peer X receives the request, peer X 180 sends the response to peer R, which forwards it directly to Peer A on 181 the existing connection. Figure 1 illustrates RPR. Note that RPR 182 also allows a shorter route for responses compared to SRR, which 183 means less overhead on intermediate peers. Establishing a connection 184 to the relay with TLS requires multiple round trips. Please refer to 185 Section 5 for cost comparison between SRR and RPR. 187 A B C D X R 188 | Request | | | | | 189 |----------->| | | | | 190 | | Request | | | | 191 | |----------->| | | | 192 | | | Request | | | 193 | | |----------->| | | 194 | | | | Request | | 195 | | | |----------->| | 196 | | | | | Response | 197 | | | | |---------->| 198 | | | | Response | | 199 |<-----------+------------+------------+------------+-----------| 200 | | | | | | 202 Figure 1. RPR routing mode 204 This technique relies on the relative population of peers such as A 205 that require relay peers, and peers such as R that are capable of 206 serving as a relay peers. It also requires a mechanism to enable 207 peers to know which peers can be used as their relays. This 208 mechanism may be based on configuration, for example as part of the 209 overlay configuration an initial list of relay peers can be supplied. 210 Another option is in a response message, the responding peer can 211 announce that it can serve as a relay peer. 213 3.2. Scenarios where RPR can be used 215 In this section, we will list several scenarios where using RPR would 216 provide an improved performance. 218 3.2.1. Managed or closed P2P systems 220 As described in Section 3.2.1 of DRR draft [I-D.ietf-p2psip-drr], 221 many P2P systems run in a closed or managed environment so that 222 network administrators can better manage their system. For example, 223 the network administrator can deploy several relay peers which are 224 publicly reachable in the system and indicate their presence in the 225 configuration file. After learning where these relay peers are, 226 peers behind NATs can use RPR with the help from these relay peers. 227 Peers MUST also support SRR in case RPR fails. 229 Another usage is to install relay peers on the managed network 230 boundary allowing external peers to send responses to peers inside 231 the managed network. 233 3.2.2. Using bootstrap nodes as relay peers 234 Bootstrap nodes are typically publicly reachable in a RELOAD 235 architecture. As a result, one possible architecture would be to use 236 the bootstrap nodes as relay peers for use with RPR. A relay peer 237 SHOULD be publicly accessible and maintain a direct connection with 238 its client. As such, bootstrap nodes are well suited to play the 239 role of relay peers. 241 3.2.3. Wireless scenarios 243 In some mobile deployments, using RPR may help reducing radio battery 244 usage and bandwidth by the intermediate peers. The service provider 245 may recommend using RPR based on his/her knowledge of the topology. 247 4. Relationship between SRR and RPR 249 4.1. How RPR works 251 Peers using RPR MUST maintain a connection with their relay peer(s). 252 This can be done in the same way as establishing a neighbor 253 connection between peers by using the Attach method. 255 A requirement for RPR is for the source peer to convey their relay 256 peer (or peers) transport address in the request, so the destination 257 peer knows where the relay peer are and send the response to a relay 258 peer first. The request SHOULD include also the requesting peer 259 information enabling the relay peer to route the response back to the 260 right peer. 262 Note that being a relay peer does not require that the relay peer has 263 more functionality than an ordinary peer. As discussed later, relay 264 peers comply with the same procedure as an ordinary peer to forward 265 messages. The only difference is that there may be a larger traffic 266 burden on relay peers. Relay peers can decide whether to accept a 267 new connection based on their current burden. 269 4.2. How SRR and RPR work together 271 RPR is not intended to replace SRR. It is better to use these two 272 modes together to adapt to each peer's specific situation. Note that 273 the informative suggestions on how to transition between SRR and RPR 274 are the same with that of DRR. Please refer to DRR document [I-D 275 .ietf-p2psip-drr] for more details. If a relay peer is provided by 276 the service provider, peers MAY prefer RPR over SRR. Otherwise, 277 using RPR SHOULD be discouraged in the open Internet or if the 278 administrator does not feel he have enough information about the 279 overlay. A new overlay configuration element specifying the usage of 280 DRR is defined in Section 7. 282 5. Comparison on cost of SRR and RPR 284 The major advantage of the use of RPR is that it reduces the number 285 of intermediate peers traversed by the response. By doing that, it 286 reduces the load on those peers' resources like processing and 287 communication bandwidth. 289 5.1. Closed or managed networks 291 As described in Section 3, many P2P systems run in a closed or 292 managed environment (e.g., carrier networks) so that network 293 administrators would know that they could safely use RPR. 295 The number of hops for a response in SRR and RPR are listed in the 296 following table. Note that the same illustrative settings can be 297 found in DRR document [I-D.ietf-p2psip-drr]. 299 Mode | Success | No. of Hops | No. of Msgs 300 ---------------------------------------------------- 301 SRR | Yes | log(N) | log(N) 302 RPR | Yes | 2 | 2 303 RPR(DTLS) | Yes | 2 | 7+2 305 Table 1. Comparison of SRR and RPR in closed networks 307 From the above comparison, it is clear that: 309 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 310 Using a shorter route means less overhead and resource usage on 311 intermediate peers, which is an important consideration for adopting 312 RPR in the cases where the resources such as CPU and bandwidth are 313 limited, e.g., the case of mobile, wireless networks. 315 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 316 SRR. 318 3) In the cases when N < 512, RPR uses more messages than SRR (but 319 still uses fewer hops than SRR). So the consideration on whether 320 using RPR or SRR depends on other factors like using less resources 321 (bandwidth and processing) from the intermediate peers. Section 4 322 provides use cases where RPR has better chance to work or where the 323 intermediary resources considerations are important. 325 5.2. Open networks 327 In open networks (e.g., Internet) where RPR is not guaranteed to 328 work, RPR can fall back to SRR if it fails after trial, as described 329 in Section 4. Based on the same settings of Section 5.1, the number 330 of hops, number of messages for a response in SRR and RPR are listed 331 in the following table. 333 Mode | Success | No. of Hops | No. of Msgs 334 ----------------------------------------------------------- 335 SRR | Yes | log(N) | log(N) 336 RPR | Yes | 2 | 2 337 | Fail&Fall back to SRR | 2+log(N)| 2+log(N) 338 RPR(DTLS) | Yes | 2 | 7+2 339 | Fail&Fall back to SRR | 2+log(N)| 9+log(N) 341 Table 2. Comparison of SRR and RPR in open networks 343 From the above comparison, it can be observed that trying to first 344 use RPR could still provide an overall number of hops lower than 345 directly using SRR. The detailed analysis is same as DRR case and 346 can be found in DRR document [I-D.ietf-p2psip-drr]. 348 6. RPR extensions to RELOAD 350 Adding support for RPR requires extensions to the current RELOAD 351 protocol. In this section, we define the extensions required to the 352 protocol, including extensions to message structure and to message 353 processing. 355 6.1. Basic requirements 357 All peers MUST be able to process requests for routing in SRR, and 358 MAY support RPR routing requests. 360 6.2. Modification to RELOAD message structure 362 RELOAD provides an extensible framework to accommodate future 363 extensions. In this section, we define a ForwardingOption structure 364 and present a state-keeping flag to support RPR mode. 366 6.2.1. State-keeping flag 368 flag : 0x08 IGNORE-STATE-KEEPING 370 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 371 which is not the destination of the message SHOULD forward the 372 message with the full via_list and SHOULD NOT maintain any internal 373 state. 375 6.2.2. Extensive routing mode 377 We first define a new type to define the new option, 378 extensive_routing_mode: 380 The option value is illustrated as below, defining the 381 ExtensiveRoutingModeOption structure: 383 enum {(0),DRR(1),RPR(2),(255)} RouteMode; 384 struct { 385 RouteMode routemode; 386 OverlayLinkType transport; 387 IpAddressPort ipaddressport; 388 Destination destinations<1..2^8-1>; 389 } ExtensiveRoutingModeOption; 391 Note that DRR value in RouteMode is defined in DRR document [I-D 392 .ietf-p2psip-drr]. 394 RouteMode: refers to which type of routing mode is indicated to the 395 destination peer. 397 OverlayLinkType: refers to the transport type which is used to 398 deliver responses from the destination peer to the relay peer. 400 IpAddressPort: refers to the transport address that the destination 401 peer should use to send the response to. This will be a relay peer 402 address for RPR. 404 Destination: refers to the relay peer itself. If the routing mode is 405 RPR, then the destination contains two destinations, which are the 406 relay peer's Node-ID and the sending peer's Node-ID. 408 6.3. Creating a request 410 6.3.1. Creating a request for RPR 412 When using RPR for a transaction, the sending peer MUST set the 413 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 414 peer MUST construct and include a ForwardingOptions structure in the 415 ForwardingHeader. When constructing the ForwardingOption structure, 416 the fields MUST be set as follows: 418 1) The type MUST be set to extensive_routing_mode. 420 2) The ExtensiveRoutingModeOption structure MUST be used for the 421 option field within the ForwardingOptions structure. The fields MUST 422 be defined as follows: 424 2.1) routemode set to 0x02 (RPR). 426 2.2) transport set as appropriate for the relay peer. 428 2.3) ipaddressport set to the transport address of the relay peer 429 that the sender wishes the message to be relayed through. 431 2.4) destination structure MUST contain two values. The first MUST 432 be defined as type node and set with the values for the relay peer. 433 The second MUST be defined as type node and set with the sending 434 peer's own values. 436 6.4. Request and response processing 438 This section gives normative text for message processing after RPR is 439 introduced. Here, we only describe the additional procedures for 440 supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD 441 base procedures. 443 6.4.1. Destination peer: receiving a request and sending a response 445 When the destination peer receives a request, it will check the 446 options in the forwarding header. If the destination peer can not 447 understand extensive_routing_mode option in the request, it MUST 448 attempt using SRR to return an "Error_Unknown_Extension" response 449 (defined in Section 6.3.3.1 and Section 14.9 of [I-D.ietf-p2psip- 450 base]) to the sending peer. 452 If the routing mode is RPR, the destination peer MUST construct a 453 destination_list for the response with two entries. The first MUST 454 be set to the relay peer Node-ID from the option in the request and 455 the second MUST be the sending peer Node-ID from the option of the 456 request. 458 In the event that the routing mode is set to RPR and there are not 459 exactly two destinations, the destination peer MUST try to send an 460 "Error_Unknown_Extension" response (defined in Section 6.3.3.1 and 461 Section 14.9 of [I-D.ietf-p2psip-base]) to the sending peer using 462 SRR. 464 After the peer constructs the destination_list for the response, it 465 sends the response to the transport address which is indicated in the 466 ipaddressport field in the option using the specific transport mode 467 in the Forwardingoption. If the destination peer receives a 468 retransmit with SRR preference on the message it is trying to 469 response to now, the responding peer SHOULD abort the RPR response 470 and use SRR. 472 6.4.2. Sending peer: receiving a response 474 Upon receiving a response, the peer follows the rules in [I-D.ietf- 475 p2psip-base]. If the sender used RPR and does not get a response 476 until the timeout, it MAY either resend the message using RPR but 477 with a different relay peer (if available), or resend the message 478 using SRR. 480 6.4.3. Relay peer processing 482 Relay peers are designed to forward responses to peers who are not 483 publicly reachable. For the routing of the response, this document 484 still uses the destination_list. The only difference from SRR is 485 that the destination_list is not the reverse of the via_list. 486 Instead, it is constructed from the forwarding option as described 487 below. 489 When a relay peer receives a response, it MUST follow the rules in 490 [I-D.ietf-p2psip-base]. It receives the response, validates the 491 message, re-adjust the destination_list and forward the response to 492 the next hop in the destination_list based on the connection table. 493 There is no added requirement for relay peer. 495 7. Overlay configuration extension 497 This document uses the new RELOAD overlay configuration element, 498 "route-mode", inside each "configuration" element, as defined in 499 Section 7 of the DRR document [I-D.ietf-p2psip-drr]. 501 8. Discovery of relay peers 503 There are several ways to distribute the information about relay 504 peers throughout the overlay. P2P network providers can deploy some 505 relay peers and advertise them in the configuration file. With the 506 configuration file at hand, peers can get relay peers to try RPR. 507 Another way is to consider relay peer as a service and then some 508 service advertisement and discovery mechanism can also be used for 509 discovering relay peers, for example, using the same mechanism as 510 used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. 511 Another option is to let a peer advertise its capability to be a 512 relay in the response to ATTACH or JOIN. 514 9. Security Considerations 515 The normative security recommendations of Section 13 of base draft 516 [I-D.ietf-p2psip-base] are applicable to this document. As a routing 517 alternative, the security part of RPR conforms to Section 13.6 of the 518 base draft which describes routing security. RPR behaves like a DRR 519 requesting node towards the destination node. The RPR relay node is 520 not an arbitrary node but SHOULD be a trusted one (managed network, 521 bootstrap nodes or configured relay) which will make it less of a 522 risk as outlined in section13 of the based draft. 524 10. IANA Considerations 526 10.1. A new RELOAD Forwarding Option 528 A new RELOAD Forwarding Option type is added to the Forwarding Option 529 Registry defined in [I-D.ietf-p2psip-base]. 531 Type: 0x02 - extensive_routing_mode 533 11. Acknowledgments 535 David Bryan has helped extensively with this document, and helped 536 provide some of the text, analysis, and ideas contained here. The 537 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 538 Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and 539 Carlos Jesus Bernardos Cano for their constructive comments. 541 12. References 543 12.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC2119, March 1997. 548 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 549 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 550 (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in 551 progress), February 2013. 553 [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 554 "An extension to RELOAD to support Direct Response Routing", draft- 555 ietf-p2psip-drr-11 (work in progress), October 2013. 557 12.2. Informative References 559 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 560 Using STUN", RFC5780, May 2010. 562 [RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address 563 Fixing (UNSAF) Across Network Address Translation", RFC3424, November 564 2002. 566 13. References 568 Appendix A. Optional methods to investigate peer connectivity 570 This section is for informational purposes only for providing some 571 mechanisms that can be used when the configuration information does 572 not specify if RPR can be used. It summarizes some methods which can 573 be used for a peer to determine its own network location compared 574 with NAT. These methods may help a peer to decide which routing mode 575 it may wish to try. Note that there is no foolproof way to determine 576 if a peer is publically reachable, other than via out-of-band 577 mechanisms. This document addresses the UNSAF [RFC3424] concerns by 578 specifying a fallback plan to SRR [p2psip-base-draft]. SRR is not an 579 UNSAF mechanism. The document does not define any new UNSAF 580 mechanisms. 582 For RPR to function correctly, a peer may attempt to determine 583 whether it is publicly reachable. If it is not, RPR may be chosen to 584 route the response with the help from relay peers, or the peers 585 should fall back to SRR. NATs and firewalls are two major 586 contributors preventing RPR from functioning properly. There are a 587 number of techniques by which a peer can get its reflexive address on 588 the public side of the NAT. After obtaining the reflexive address, a 589 peer can perform further tests to learn whether the reflexive address 590 is publicly reachable. If the address appears to be publicly 591 reachable, the peers to which the address belongs can be a candidate 592 to serve as a relay peer. Peers which are not publicly reachable may 593 still use RPR to shorten the response path with the help from relay 594 peers. 596 Some conditions are unique in P2PSIP architecture which could be 597 leveraged to facilitate the tests. In P2P overlay network, each peer 598 only has partial a view of the whole network, and knows of a few 599 peers in the overlay. P2P routing algorithms can easily deliver a 600 request from a sending peer to a peer with whom the sending peer has 601 no direct connection. This makes it easy for a peer to ask other 602 peers to send unsolicited messages back to the requester. 604 The approaches for a peer to get the addresses needed for the further 605 tests, as well as the test for learning whether a peer may be 606 publicly reachable is same as the DRR case. Please refer to DRR 607 document [I-D.ietf-p2psip-drr] for more details. 609 Authors' Addresses 611 Ning Zong (editor) 612 Huawei Technologies 614 Email: zongning@huawei.com 616 Xingfeng Jiang 617 Huawei Technologies 619 Email: jiang.x.f@huawei.com 621 Roni Even 622 Huawei Technologies 624 Email: roni.even@mail01.huawei.com 626 Yunfei Zhang 627 CoolPad 629 Email: hishigh@gmail.com