idnits 2.17.1 draft-ietf-p2psip-rpr-08.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 (July 15, 2013) is 3932 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: 'I-D.ietf-p2psip-concepts' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-p2psip-drr-07 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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: January 16, 2014 Huawei Technologies 6 Y. Zhang 7 CoolPad 8 July 15, 2013 10 An extension to RELOAD to support Relay Peer Routing 11 draft-ietf-p2psip-rpr-08 13 Abstract 15 This document proposes an optional extension to RELOAD to support 16 relay peer routing mode. RELOAD recommends symmetric recursive 17 routing for routing messages. The new optional extension provides a 18 shorter route for responses reducing the overhead on intermediate 19 peers and describes the potential use cases where this extension can 20 be used. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 16, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4 61 3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5 62 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 63 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 6 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 . . . . . . . . . . . . . . 7 68 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 69 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 70 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9 75 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 76 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 10 77 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 12 84 8. Discovery of relay peers . . . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 12.2. Informative References . . . . . . . . . . . . . . . . . 13 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 Appendix A. Optional methods to investigate peer connectivity . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing 99 (SRR) for routing messages and describes the extensions that would be 100 required to support additional routing algorithms. Other than SRR, 101 two other routing options: direct response routing (DRR) and relay 102 peer routing (RPR) are also discussed in Appendix A of [I-D.ietf- 103 p2psip-base]. As we show in section 3, RPR is advantageous over SRR 104 in some scenarios reducing load (CPU and link bandwidth) on 105 intermediate peers. RPR works better in a network where relay peers 106 are provisioned in advance so that relay peers are publicly reachable 107 in the P2P system. In other scenarios, using a combination of RPR 108 and SRR together is more likely to bring benefits than if SRR is used 109 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 system. 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. 174 Note that the same illustrative settings can be found in DRR document 175 [I-D.ietf-p2psip-drr]. 177 3.1.1. Relay Peer Routing (RPR) 178 If peer A knows it is behind a NAT or NATs, and knows one or more 179 relay peers with whom they have a prior connections, peer A can try 180 RPR. Assume A is associated with relay peer R. When sending the 181 request, peer A includes information describing peer R transport 182 address in the request. When peer X receives the request, peer X 183 sends the response to peer R, which forwards it directly to Peer A on 184 the existing connection. Figure 1 illustrates RPR. Note that RPR 185 also allows a shorter route for responses compared to SRR, which 186 means less overhead on intermediate peers. Establishing a connection 187 to the relay with TLS requires multiple round trips. Please refer to 188 Section 5 for cost comparison between SRR and RPR. 190 A B C D X R 191 | Request | | | | | 192 |----------->| | | | | 193 | | Request | | | | 194 | |----------->| | | | 195 | | | Request | | | 196 | | |----------->| | | 197 | | | | Request | | 198 | | | |----------->| | 199 | | | | | Response | 200 | | | | |---------->| 201 | | | | Response | | 202 |<-----------+------------+------------+------------+-----------| 203 | | | | | | 205 Figure 1. RPR routing mode 207 This technique relies on the relative population of peers such as A 208 that require relay peers, and peers such as R that are capable of 209 serving as a relay peers. It also requires a mechanism to enable 210 peers to know which peers can be used as their relays. This 211 mechanism may be based on configuration, for example as part of the 212 overlay configuration an initial list of relay peers can be supplied. 213 Another option is in a response message, the responding peer can 214 announce that it can serve as a relay peer. 216 3.2. Scenarios where RPR can be beneficial 218 In this section, we will list several scenarios where using RPR would 219 provide an improved performance. 221 3.2.1. Managed or closed P2P systems 223 As described in Section 3.2.1 of DRR draft [I-D.ietf-p2psip-drr], 224 many P2P systems run in a closed or managed environment so that 225 network administrators can better manage their system. For example, 226 the network administrator can deploy several relay peers which are 227 publicly reachable in the system and indicate their presence in the 228 configuration file. After learning where these relay peers are, 229 peers behind NATs can use RPR with the help from these relay peers. 230 Peers MUST also support SRR in case RPR fails. 232 Another usage is to install relay peers on the managed network 233 boundary allowing external peers to send responses to peers inside 234 the managed network. 236 3.2.2. Using bootstrap nodes as relay peers 238 Bootstrap nodes are typically publicly reachable in a RELOAD 239 architecture. As a result, one possible architecture would be to use 240 the bootstrap nodes as relay peers for use with RPR. A relay peer 241 SHOULD be publicly accessible and maintain a direct connection with 242 its client. As such, bootstrap nodes are well suited to play the 243 role of relay peers. 245 3.2.3. Wireless scenarios 247 In some mobile deployments, using RPR may help reducing radio battery 248 usage and bandwidth by the intermediate peers. The service provider 249 may recommend using RPR based on his knowledge of the topology. 251 4. Relationship between SRR and RPR 253 4.1. How RPR works 255 Peers using RPR MUST maintain a connection with their relay peer(s). 256 This can be done in the same way as establishing a neighbor 257 connection between peers by using the Attach method. 259 A requirement for RPR is for the source peer to convey their relay 260 peer (or peers) transport address in the request, so the destination 261 peer knows where the relay peer are and send the response to a relay 262 peer first. The request SHOULD include also the requesting peer 263 information enabling the relay peer to route the response back to the 264 right peer. 266 Note that being a relay peer does not require that the relay peer has 267 more functionality than an ordinary peer. As discussed later, relay 268 peers comply with the same procedure as an ordinary peer to forward 269 messages. The only difference is that there may be a larger traffic 270 burden on relay peers. Relay peers can decide whether to accept a 271 new connection based on their current burden. 273 4.2. How SRR and RPR work together 275 RPR is not intended to replace SRR. It is better to use these two 276 modes together to adapt to each peer's specific situation. Note that 277 the informative suggestions on how to transition between SRR and RPR 278 are the same with that of DRR. Please refer to DRR document [I-D 279 .ietf-p2psip-drr] for more details. If a relay peer is provided by 280 the service provider, peers MAY prefer RPR over SRR. Otherwise, 281 using RPR SHOULD be discouraged in the open Internet or if the 282 administrator does not feel he have enough information about the 283 overlay. A new overlay configuration element specifying the usage of 284 DRR is defined in Section 7. 286 5. Comparison on cost of SRR and RPR 288 The major advantage of the use of RPR is that it reduces the number 289 of intermediate peers traversed by the response. By doing that, it 290 reduces the load on those peers' resources like processing and 291 communication bandwidth. 293 5.1. Closed or managed networks 295 As described in Section 3, many P2P systems run in a closed or 296 managed environment (e.g. carrier networks) so that network 297 administrators would know that they could safely use RPR. 299 The number of hops for a response in SRR and RPR are listed in the 300 following table. Note that the same illustrative settings can be 301 found in DRR document [I-D.ietf-p2psip-drr]. 303 Mode | Success | No. of Hops | No. of Msgs 304 ---------------------------------------------------- 305 SRR | Yes | log(N) | log(N) 306 RPR | Yes | 2 | 2 307 RPR(DTLS) | Yes | 2 | 7+2 309 Table 1. Comparison of SRR and RPR in closed networks 311 From the above comparison, it is clear that: 313 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 314 Using a shorter route means less overhead and resource usage on 315 intermediate peers, which is an important consideration for adopting 316 RPR in the cases where the resources such as CPU and bandwidth are 317 limited, e.g. the case of mobile, wireless networks. 319 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 320 SRR. 322 3) In the cases when N < 512, RPR uses more messages than SRR (but 323 still uses fewer hops than SRR). So the consideration on whether 324 using RPR or SRR depends on other factors like using less resources 325 (bandwidth and processing) from the intermediate peers. Section 4 326 provides use cases where RPR has better chance to work or where the 327 intermediary resources considerations are important. 329 5.2. Open networks 331 In open networks where RPR is not guaranteed to work, RPR can fall 332 back to SRR if it fails after trial, as described in Section 4. 333 Based on the same settings of Section 5.1, the number of hops, number 334 of messages for a response in SRR and RPR are listed in the following 335 table. 337 Mode | Success | No. of Hops | No. of Msgs 338 ----------------------------------------------------------- 339 SRR | Yes | log(N) | log(N) 340 RPR | Yes | 2 | 2 341 | Fail&Fall back to SRR | 2+log(N)| 2+log(N) 342 RPR(DTLS) | Yes | 2 | 7+2 343 | Fail&Fall back to SRR | 2+log(N)| 9+log(N) 345 Table 2. Comparison of SRR and RPR in open networks 347 From the above comparison, it can be observed that trying to first 348 use RPR could still provide an overall number of hops lower than 349 directly using SRR. The detailed analysis is same as DRR case and 350 can be found in DRR document [I-D.ietf-p2psip-drr]. 352 6. RPR extensions to RELOAD 354 Adding support for RPR requires extensions to the current RELOAD 355 protocol. In this section, we define the extensions required to the 356 protocol, including extensions to message structure and to message 357 processing. 359 6.1. Basic requirements 361 All peers MUST be able to process requests for routing in SRR, and 362 MAY support RPR routing requests. 364 6.2. Modification to RELOAD message structure 365 RELOAD provides an extensible framework to accommodate future 366 extensions. In this section, we define a ForwardingOption structure 367 and present a state-keeping flag to support RPR mode. 369 6.2.1. State-keeping flag 371 flag : 0x08 IGNORE-STATE-KEEPING 373 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 374 which is not the destination of the message SHOULD forward the 375 message with the full via_list and SHOULD NOT maintain any internal 376 state. 378 6.2.2. Extensive routing mode 380 We first define a new type to define the new option, 381 extensive_routing_mode: 383 The option value is illustrated in the following figure, defining the 384 ExtensiveRoutingModeOption structure: 386 enum {(0),DRR(1),RPR(2),(255)} RouteMode; 387 struct { 388 RouteMode routemode; 389 OverlayLinkType transport; 390 IpAddressPort ipaddressport; 391 Destination destinations<1..2^8-1>; 392 } ExtensiveRoutingModeOption; 394 Note that DRR value in RouteMode is defined in DRR document [I-D 395 .ietf-p2psip-drr]. 397 RouteMode: refers to which type of routing mode is indicated to the 398 destination peer. 400 OverlayLinkType: refers to the transport type which is used to 401 deliver responses from the destination peer to the relay peer. 403 IpAddressPort: refers to the transport address that the destination 404 peer should use to send the response to. This will be a relay peer 405 address for RPR. 407 Destination: refers to the relay peer itself. If the routing mode is 408 RPR, then the destination contains two destinations, which are the 409 relay peer's Node-ID and the sending peer's Node-ID. 411 6.3. Creating a request 413 6.3.1. Creating a request for RPR 415 When using RPR for a transaction, the sending peer MUST set the 416 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 417 peer MUST construct and include a ForwardingOptions structure in the 418 ForwardingHeader. When constructing the ForwardingOption structure, 419 the fields MUST be set as follows: 421 1) The type MUST be set to extensive_routing_mode. 423 2) The ExtensiveRoutingModeOption structure MUST be used for the 424 option field within the ForwardingOptions structure. The fields MUST 425 be defined as follows: 427 2.1) routemode set to 0x02 (RPR). 429 2.2) transport set as appropriate for the relay peer. 431 2.3) ipaddressport set to the transport address of the relay peer 432 that the sender wishes the message to be relayed through. 434 2.4) destination structure MUST contain two values. The first MUST 435 be defined as type node and set with the values for the relay peer. 436 The second MUST be defined as type node and set with the sending 437 peer's own values. 439 6.4. Request and response processing 441 This section gives normative text for message processing after RPR is 442 introduced. Here, we only describe the additional procedures for 443 supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD 444 base procedures. 446 6.4.1. Destination peer: receiving a request and sending a response 448 When the destination peer receives a request, it will check the 449 options in the forwarding header. If the destination peer can not 450 understand extensive_routing_mode option in the request, it MUST 451 attempt using SRR to return an "Error_Unknown_Extension" response 452 (defined in Section 6.3.3.1 and Section 14.9 of [I-D.ietf-p2psip- 453 base]) to the sending peer. 455 If the routing mode is RPR, the destination peer MUST construct a 456 destination_list for the response with two entries. The first MUST 457 be set to the relay peer Node-ID from the option in the request and 458 the second MUST be the sending peer Node-ID from the option of the 459 request. 461 In the event that the routing mode is set to RPR and there are not 462 exactly two destinations, the destination peer MUST try to send an 463 "Error_Unknown_Extension" response (defined in Section 6.3.3.1 and 464 Section 14.9 of [I-D.ietf-p2psip-base]) to the sending peer using 465 SRR. 467 After the peer constructs the destination_list for the response, it 468 sends the response to the transport address which is indicated in the 469 ipaddressport field in the option using the specific transport mode 470 in the Forwardingoption. If the destination peer receives a 471 retransmit with SRR preference on the message it is trying to 472 response to now, the responding peer SHOULD abort the RPR response 473 and use SRR. 475 6.4.2. Sending peer: receiving a response 477 Upon receiving a response, the peer follows the rules in [I-D.ietf- 478 p2psip-base]. If the sender used RPR and does not get a response 479 until the timeout, it MAY either resend the message using RPR but 480 with a different relay peer (if available), or resend the message 481 using SRR. 483 6.4.3. Relay peer processing 485 Relay peers are designed to forward responses to peers who are not 486 publicly reachable. For the routing of the response, this document 487 still uses the destination_list. The only difference from SRR is 488 that the destination_list is not the reverse of the via_list. 489 Instead, it is constructed from the forwarding option as described 490 below. 492 When a relay peer receives a response, it MUST follow the rules in 493 [I-D.ietf-p2psip-base]. It receives the response, validates the 494 message, re-adjust the destination_list and forward the response to 495 the next hop in the destination_list based on the connection table. 496 There is no added requirement for relay peer. 498 7. Overlay configuration extension 500 This document uses the new RELOAD overlay configuration element, 501 "route-mode", inside each "configuration" element, as defined in DRR 502 document [I-D.ietf-p2psip-drr]. 504 8. Discovery of relay peers 506 There are several ways to distribute the information about relay 507 peers throughout the overlay. P2P network providers can deploy some 508 relay peers and advertise them in the configuration file. With the 509 configuration file at hand, peers can get relay peers to try RPR. 510 Another way is to consider relay peer as a service and then some 511 service advertisement and discovery mechanism can also be used for 512 discovering relay peers, for example, using the same mechanism as 513 used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. 514 Another option is to let a peer advertise his capability to be a 515 relay in the response to ATTACH or JOIN. 517 9. Security Considerations 519 As a routing alternative, the security part of RPR conforms to 520 section 13.6 of the base draft [I-D.ietf-p2psip-base] which describes 521 routing security. RPR behave like a DRR requesting node towards the 522 destination node. The RPR relay node is not an arbitrary node but 523 SHOULD be a trusted one (managed network, bootstrap nodes or 524 configured relay) which will make it less of a risk as outlined in 525 section13 of the based draft. 527 10. IANA Considerations 529 10.1. A new RELOAD Forwarding Option 531 A new RELOAD Forwarding Option type is added to the Forwarding Option 532 Registry defined in [I-D.ietf-p2psip-base]. 534 Type: 0x02 - extensive_routing_mode 536 11. Acknowledgements 538 David Bryan has helped extensively with this document, and helped 539 provide some of the text, analysis, and ideas contained here. The 540 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 541 Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and 542 Carlos Jesus Bernardos Cano for their constructive comments. 544 12. References 545 12.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC2119, March 1997. 550 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 551 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 552 (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in 553 progress), February 2013. 555 12.2. Informative References 557 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 558 Using STUN", RFC5780, May 2010. 560 [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 561 "An extension to RELOAD to support Direct Response Routing", draft- 562 ietf-p2psip-drr-07, June 2013. 564 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 565 D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", 566 draft-ietf-p2psip-concepts-04 (work in progress), October 2011. 568 13. References 570 Appendix A. Optional methods to investigate peer connectivity 572 This section is for informational purposes only for providing some 573 mechanisms that can be used when the configuration information does 574 not specify if RPR can be used. It summarizes some methods which can 575 be used for a peer to determine its own network location compared 576 with NAT. These methods may help a peer to decide which routing mode 577 it may wish to try. Note that there is no foolproof way to determine 578 if a peer is publically reachable, other than via out-of-band 579 mechanisms. As such, peers using these mechanisms may be able to 580 optimize traffic, but must be able to fall back to SRR routing if the 581 other routing mechanisms fail. 583 For RPR to function correctly, a peer may attempt to determine 584 whether it is publicly reachable. If it is not, RPR may be chosen to 585 route the response with the help from relay peers, or the peers 586 should fall back to SRR. NATs and firewalls are two major 587 contributors preventing RPR from functioning properly. There are a 588 number of techniques by which a peer can get its reflexive address on 589 the public side of the NAT. After obtaining the reflexive address, a 590 peer can perform further tests to learn whether the reflexive address 591 is publicly reachable. If the address appears to be publicly 592 reachable, the peers to which the address belongs can be a candidate 593 to serve as a relay peer. Peers which are not publicly reachable may 594 still use RPR to shorten the response path with the help from relay 595 peers. 597 Some conditions are unique in P2PSIP architecture which could be 598 leveraged to facilitate the tests. In P2P overlay network, each peer 599 only has partial a view of the whole network, and knows of a few 600 peers in the overlay. P2P routing algorithms can easily deliver a 601 request from a sending peer to a peer with whom the sending peer has 602 no direct connection. This makes it easy for a peer to ask other 603 peers to send unsolicited messages back to the requester. 605 The approaches for a peer to get the addresses needed for the further 606 tests, as well as the test for learning whether a peer may be 607 publicly reachable is same as the DRR case. Please refer to DRR 608 document [I-D.ietf-p2psip-drr] for more details. 610 Authors' Addresses 612 Ning Zong (editor) 613 Huawei Technologies 615 Email: zongning@huawei.com 617 Xingfeng Jiang 618 Huawei Technologies 620 Email: jiang.x.f@huawei.com 622 Roni Even 623 Huawei Technologies 625 Email: roni.even@mail01.huawei.com 627 Yunfei Zhang 628 CoolPad 630 Email: hishigh@gmail.com