idnits 2.17.1 draft-zong-p2psip-rpr-01.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 (September 19, 2011) is 4600 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 600, but no explicit reference was found in the text == Unused Reference: 'DTLS' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-tcp' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'I-D.lowekamp-mmusic-ice-tcp-framework' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 623, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-18 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-03 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-behavior-discovery-04 Summary: 1 error (**), 0 flaws (~~), 10 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: March 22, 2012 Huawei Technologies 6 Y. Zhang 7 China Mobile 8 September 19, 2011 10 An extension to RELOAD to support Relay Peer Routing 11 draft-zong-p2psip-rpr-01 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 intermediary 19 peers and describes the potential cases where this extension can be 20 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 March 22, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Backgrounds . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . . 6 74 3.2. Scenarios Where RPR Benefits . . . . . . . . . . . . . . . 6 75 3.2.1. Managed or Closed P2P System . . . . . . . . . . . . . 6 76 3.2.2. Using Bootstrap Peers as Relay Peers . . . . . . . . . 7 77 3.2.3. Wireless Scenarios . . . . . . . . . . . . . . . . . . 7 78 4. Relationship Between SRR and RPR . . . . . . . . . . . . . . . 7 79 4.1. How RPR Works . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. How SRR and RPR Work Together . . . . . . . . . . . . . . 8 81 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 8 82 5.1. Closed or managed networks . . . . . . . . . . . . . . . . 8 83 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 9 84 6. Extensions to RELOAD . . . . . . . . . . . . . . . . . . . . . 9 85 6.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 9 86 6.2. Modification To RELOAD Message Structure . . . . . . . . . 10 87 6.2.1. State-keeping Flag . . . . . . . . . . . . . . . . . . 10 88 6.2.2. Extensive Routing Mode . . . . . . . . . . . . . . . . 10 89 6.3. Creating a Request . . . . . . . . . . . . . . . . . . . . 10 90 6.3.1. Creating a request for RPR . . . . . . . . . . . . . . 10 91 6.4. Request And Response Processing . . . . . . . . . . . . . 11 92 6.4.1. Destination Peer: Receiving a Request And Sending 93 a Response . . . . . . . . . . . . . . . . . . . . . . 11 94 6.4.2. Sending Peer: Receiving a Response . . . . . . . . . . 12 95 6.4.3. Relay Peer Processing . . . . . . . . . . . . . . . . 12 96 7. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 12 97 8. Optional Methods to Investigate Node Connectivity . . . . . . 12 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 99 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 1.1. Backgrounds 110 RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing 111 (SRR) for routing messages and describes the extensions that would be 112 required to support additional routing algorithms. Other than SRR, 113 two other routing options: direct response routing (DRR) and relay 114 peer routing (RPR) are also discussed in Appendix D in [I-D.ietf- 115 p2psip-base]. DRR is specified in [I-D.zong-p2psip-drr]. As we show 116 in section 3, RPR is advantageous over SRR in some scenarios reducing 117 load (CPU and link BW) on intermediary peers . RPR works better in a 118 network where relay peers are provisioned in advance so that relay 119 peers are publicly reachable in the P2P system. In other scenarios, 120 using a combination of RPR and SRR together is more likely to bring 121 benefits than if SRR is used alone. Some discussion on connectivity 122 is in Non-Transitive Connectivity and DHTs 123 [http://srhea.net/papers/ntr-worlds05.pdf]. 125 Note that in this draft, we focus on RPR routing mode and its 126 extensions to RELOAD. Some text such as modification to RELOAD 127 message structure, optional methods to investigate node connectivity 128 described in DRR draft [I-D.zong-p2psip-drr] are also relevent to 129 RPR. 131 We first discuss the problem statement in Section 3, then how to 132 combine RPR and SRR is presented in Section 4. In Section 5, we give 133 comparison on the cost of SRR and RPR in both managed and open 134 networks. An extension to RELOAD to support RPR is proposed in 135 Section 6. Discovery of relay peers is introduced in Section 7. 136 Some optional methods to check node connectivity is introduced in 137 Section 8. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 We use the terminology and definitions from the Concepts and 146 Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft 147 extensively in this document. We also use terms defined in NAT 148 behavior discovery [I-D.ietf-behave-nat-behavior-discovery]. Other 149 terms used in this document are defined inline when used and are also 150 defined below for reference. 152 There are two types of roles in the RELOAD architecture: peer and 153 client. Node is used when describing both peer and client. In 154 discussions specific to behavior of a peer or client, the term peer 155 or client is used instead. 157 Publicly Reachable: A node is publicly reachable if it can receive 158 unsolicited messages from any other node in the same overlay. Note: 159 "publicly" does not mean that the nodes must be on the public 160 Internet, because the RELOAD protocol may be used in a closed system. 162 Relay Peer: A type of publicly reachable peer that can receive 163 unsolicited messages from all other nodes in the overlay and forward 164 the responses from destination peers towards the request sender. 166 Relay Peer Routing (RPR): refers to a routing mode in which responses 167 to P2PSIP requests are sent by the destination peer to a relay peer 168 transport address who will forward the responses towards the sending 169 peer. For simplicity, the abbreviation RPR is used instead in the 170 following text. 172 Symmetric Recursive Routing (SRR): refers to a routing mode in which 173 responses follow the request path in the reverse order to get back to 174 the sending peer. For simplicity, the abbreviation SRR is used 175 instead in the following text. 177 3. Problem Statement 179 RELOAD is expected to work under a great number of application 180 scenarios. The situations where RELOAD is to be deployed differ 181 greatly. For instance, some deployments are global, such as a Skype- 182 like system intended to provide public service. Some run in closed 183 networks of small scale. SRR works in any situation, but RPR may 184 work better in some specific scenarios. 186 3.1. Overview 188 RELOAD is a simple request-response protocol. After sending a 189 request, a node waits for a response from a destination node. There 190 are several ways for the destination node to send a response back to 191 the source node. In this section, we will provide detailed 192 information on RPR. 194 Note that the same illustrative settings can be found in DRR draft 195 [I-D.zong-p2psip-drr]. 197 3.1.1. Relay Peer Routing (RPR) 199 If peer A knows it is behind a NAT or NATs, and knows one or more 200 relay peers with whom they have a prior connections, peer A can try 201 RPR. Assume A is associated with relay peer R. When sending the 202 request, peer A includes information describing peer R transport 203 address in the request. When peer X receives the request, peer X 204 sends the response to peer R, which forwards it directly to Peer A on 205 the existing connection. Note that RPR also allows a shorter route 206 for responses compared to SRR, which means less overhead on 207 intermediary peers. Establishing a connection to the relay with TLS 208 requires multiple round trips. Please refer to Section 5 for cost 209 comparison between SRR and RPR. 211 This technique relies on the relative population of nodes such as A 212 that require relay peers and peers such as R that are capable of 213 serving as a relay peers. It also requires mechanism to enable peers 214 to know which nodes can be used as their relays. This mechanism may 215 be based on configuration, for example as part of the overlay 216 configuration an initial list of relay peers can be supplied. 217 Another option is in a response to ATTACH request the peer can signal 218 that it can be used as a relay peer. 220 A B C D X R 221 | Request | | | | | 222 |----------->| | | | | 223 | | Request | | | | 224 | |----------->| | | | 225 | | | Request | | | 226 | | |----------->| | | 227 | | | | Request | | 228 | | | |----------->| | 229 | | | | | Response | 230 | | | | |---------->| 231 | | | | Response | | 232 |<-----------+------------+------------+------------+-----------| 233 | | | | | | 235 3.2. Scenarios Where RPR Benefits 237 In this section, we will list several scenarios where using RPR would 238 provide improved performance. 240 3.2.1. Managed or Closed P2P System 242 As described in Section 3.2.1, many P2P systems run in a closed or 243 managed environment so that network administrators can better manage 244 their system. For example, the network administrator can deploy 245 several relay peers which are publicly reachable in the system and 246 indicate their presence in the configuration file. After learning 247 where these relay peers are, peers behind NATs can use RPR with the 248 help from these relay peers. Peers must also support SRR in case RPR 249 fails. 251 Another usage is to install relay peers on the managed network 252 boundary allowing external peers to send responses to peers inside 253 the managed network. 255 3.2.2. Using Bootstrap Peers as Relay Peers 257 Bootstrap peers must be publicly reachable in a RELOAD architecture. 258 As a result, one possible architecture would be to use the bootstrap 259 peers as relay peers for use with RPR. The requirements for being a 260 relay peer are publicly accessible and maintaining a direct 261 connection with its client. As such, bootstrap peers are well suited 262 to play the role of relay peers. 264 3.2.3. Wireless Scenarios 266 While some mobile deployments may use clients, in mobile networks 267 using peers, RPR may reduce radio battery usage and bandwidth usage 268 by the intermediary peers. The service provider may recommend in the 269 configuration using RPR based on his knowledge of the topology. Such 270 relay peers may also help connectivity to external networks. 272 4. Relationship Between SRR and RPR 274 4.1. How RPR Works 276 Peers using RPR must maintain a connection with their relay peer(s). 277 This can be done in the same way as establishing a neighbor 278 connection between peers by using the Attach method. 280 A requirement for RPR is for the source peer to convey their relay 281 peer (or peers) transport address in the request, so the destination 282 peer knows where the relay peer are and send the response to a relay 283 peer first. The request should include also the requesting peer 284 information enabling the relay peer to route the response back to the 285 right peer. 287 (Editor's Note: Being a relay peer does not require that the relay 288 peer have more functionality than an ordinary peer. As discussed 289 later, relay peers comply with the same procedure as an ordinary peer 290 to forward messages. The only difference is that there may be a 291 larger traffic burden on relay peers. Relay peers can decide whether 292 to accept a new connection based on their current burden.) 294 4.2. How SRR and RPR Work Together 296 RPR is not intended to replace SRR. As seen from Section 3, RPR has 297 better performance in some scenarios, but have limitations as well, 298 see for example section 4.3 in Non-Transitive Connectivity and DHTs 299 [http://srhea.net/papers/ntr-worlds05.pdf]. As a result, it is 300 better to use these two modes together to adapt to each peer's 301 specific situation. Note that the informative suggestions on how to 302 transition between SRR and RPR (e.g. compute success rate of RPR, 303 fall back to SRR, etc) are same with that on DRR and RPR. Please 304 refer to DRR draft [I-D.zong-p2psip-drr] for more details. 305 Similarly, the node can decide whether to try RPR based on other 306 information such as configuration file information. If a relay peer 307 is provided by the service provider, nodes may prefer RPR over SRR. 309 5. Comparison on cost of SRR and RPR 311 The major advantages in using RPR are in going through less 312 intermediary peers on the response. By doing that it reduces the 313 load on those peers' resources like processing and communication 314 bandwidth. 316 5.1. Closed or managed networks 318 As described in Section 3, many P2P systems run in a closed or 319 managed environment (e.g. carrier networks) so that network 320 administrators would know that they could safely use RPR. 322 The number of hops for a response in SRR and RPR are listed in the 323 following table. Note that the same illustrative settings can be 324 found in DRR draft [I-D.zong-p2psip-drr]. 326 Mode | Success | No. of Hops | No. of Msgs 327 ---------------------------------------------------- 328 SRR | Yes | logN | logN 329 RPR | Yes | 2 | 2 330 RPR(DTLS) | Yes | 2 | 7+2 332 From the above comparison, it is clear that: 334 1) In most cases of N > 4 (2^2), RPR has fewer hops than SRR. 335 Shorter route means less overhead and resource usage on intermediary 336 peers, which is an important consideration for adopting RPR in the 337 cases where the resource such as CPU and BW is limited, e.g. the case 338 of mobile, wireless network. 340 2) In the cases of N > 512 (2^9), RPR also has fewer messages than 341 SRR. 343 3) In the cases where N < 512, RPR has more messages than SRR (but 344 still has fewer hops than SRR). So the consideration to use RPR or 345 SRR depends on other factors like using less resources (bandwidth and 346 processing) from the intermediaries peers. Section 4 provides use 347 cases where RPR has better chance to work or where the intermediary 348 resources considerations are important. 350 5.2. Open networks 352 In open network where RPR is not guaranteed, RPR can fall back to SRR 353 If it fails after trial, as described in Section 4. Based on the 354 same settings in Section 5.1, the number of hops, number of messages 355 for a response in SRR and RPR are listed in the following table. 357 Mode | Success | No. of Hops | No. of Msgs 358 ----------------------------------------------------------- 359 SRR | Yes | logN | logN 360 RPR | Yes | 2 | 2 361 | Fail&Fall back to SRR | 2+logN | 2+logN 362 RPR(DTLS) | Yes | 2 | 7+2 363 | Fail&Fall back to SRR | 2+logN | 9+logN 365 From the above comparison, it can be observed that: 367 1) Trying RPR would still have a good chance of fewer hops than SRR. 368 The detailed analysis is same as DRR case and can be found in DRR 369 draft [I-D.zong-p2psip-drr]. 371 2) In the cases of large network and the success rate of RPR is good, 372 it is still possible that RPR has fewer messages than SRR. 373 Otherwise, the consideration to use RPR or SRR depends on other 374 factors like using less resources from the intermediaries peers. 376 6. Extensions to RELOAD 378 Adding support for RPR requires extensions to the current RELOAD 379 protocol. In this section and in DRR[I-D.zong-p2psip-drr], we define 380 the changes required to the protocol, including changes to message 381 structure and to message processing. 383 6.1. Basic Requirements 385 The basic requirements to peers for supporting RPR are same as DRR 386 case. Please refer to DRR draft [I-D.zong-p2psip-drr]. 388 6.2. Modification To RELOAD Message Structure 390 RELOAD provides an extensible framework to accommodate future 391 extensions. In this section and in DRR[I-D.zong-p2psip-drr], we 392 define a ForwardingOption structure to support RPR mode. 394 6.2.1. State-keeping Flag 396 The state-keeping flag to support RPR is same as DRR case. Please 397 refer to DRR draft [I-D.zong-p2psip-drr]. 399 6.2.2. Extensive Routing Mode 401 The ForwardingOption structure to support RPR is same as DRR case. 402 Please refer to DRR draft [I-D.zong-p2psip-drr]. The definition of 403 the fields is as follow: 405 Route mode: refers to which type of routing mode is indicated to the 406 destination peer. Currently, only DRR (specified in DRR draft 407 [I-D.zong-p2psip-drr]) and RPR are defined. 409 Transport: refers to the transport type which is used to deliver 410 responses from the destination peer to the relay peer. 412 IpAddressPort: refers to the transport address that the destination 413 peer should use to send the response to. This will be a relay peer 414 address for RPR. 416 Destination: refers to the relay peer itself. If the routing mode is 417 RPR, then the destination contains two destinations, which are the 418 relay peer's node-id and the sending node's node-id. 420 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_TYPE. 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 peer and set with the values for the relay peer. 445 The second MUST be defined as type peer 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 to use SRR to return an "Error_Unknown_Extension" response 461 (defined in Section 5.3.3.1 and Section 13.9 in [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 node 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 5.3.3.1 and 473 Section 13.9 in [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 nodes who are not 495 publicly reachable. For the routing of the response, this draft 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, instead 498 it is constructed from the forwarding option as described below. 500 When a relay peer receives a response, it MUST follow the rules in 501 [I-D.ietf-p2psip-base]. It receives the response, validates the 502 message, re-adjust the destination-list and forward the response to 503 the next hop in the destination list based on the connection table. 504 There is no added requirement for relay peer. 506 7. Discovery Of Relay Peer 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 Editor note: This section will be extended if we adopt RPR, but like 520 other configuration information, there may be many ways to obtain 521 this. 523 8. Optional Methods to Investigate Node Connectivity 525 This section is for informational purposes only for providing some 526 mechanisms that can be used when the configuration information does 527 not specify if RPR can be used. It summarizes some methods which can 528 be used for a node to determine its own network location compared 529 with NAT. These methods may help a node to decide which routing mode 530 it may wish to try. Note that there is no foolproof way to determine 531 if a node is publically reachable, other than via out- of-band 532 mechanisms. As such, peers using these mechanisms may be able to 533 optimize traffic, but must be able to fall back to SRR routing if the 534 other routing mechanisms fail. 536 For RPR to function correctly, a node may attempt to determine 537 whether it is publicly reachable. If it is not, RPR may be chosen to 538 route the response with the help from relay peers, or the peers 539 should fall back to SRR. NATs and firewalls are two major 540 contributors preventing RPR from functioning properly. There are a 541 number of techniques by which a node can get its reflexive address on 542 the public side of the NAT. After obtaining the reflexive address, a 543 peer can perform further tests to learn whether the reflexive address 544 is publicly reachable. If the address appears to be publicly 545 reachable, the nodes to which the address belongs can be a candidate 546 to serve as a relay peer. Nodes which are not publicly reachable may 547 still use RPR to shorten the response path with the help from relay 548 peers. 550 Some conditions are unique in P2PSIP architecture which could be 551 leveraged to facilitate the tests. In P2P overlay network, each node 552 only has partial a view of the whole network, and knows of a few 553 nodes in the overlay. P2P routing algorithms can easily deliver a 554 request from a sending node to a peer with whom the sending node has 555 no direct connection. This makes it easy for a node to ask other 556 nodes to send unsolicited messages back to the requester. 558 The approaches for a node to get the addresses needed for the further 559 tests, as well as the test for learning whether a peer may be 560 publicly reacheable is same as the DRR case. Please refer to DRR 561 draft [I-D.zong-p2psip-drr] for more details. 563 9. Security Considerations 565 TBD 567 10. IANA Considerations 569 No IANA action is needed. 571 11. Acknowledgements 573 David Bryan has helped extensively with this document, and helped 574 provide some of the text, analysis, and ideas contained here. The 575 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 576 Lakshminath and Bruce Lowekamp for their constructive comments. 578 12. References 580 12.1. Normative References 582 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 583 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 584 (RELOAD) Base Protocol", draft-ietf-p2psip-base-18 (work in 585 progress), August 2011. 587 [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, 588 D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", 589 draft-ietf-p2psip-concepts-03 (work in progress), October 2010. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [I-D.zong-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 595 "An extension to RELOAD to support Direct Response Routing", 596 draft-zong-p2psip-drr-01, September 2011. 598 12.2. Informative References 600 [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the 601 USENIX Annual Technical Conference. Handling Churn in a DHT, June 602 2004. 604 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of 605 Datagram TLS", 11th Network and Distributed System Security Symposium 606 (NDSS), 2004. 608 [I-D.ietf-behave-nat-behavior-discovery] MacDonald, D. and B. 609 Lowekamp, "NAT Behavior Discovery Using STUN", 610 draft-ietf-behave-nat-behavior-discovery-04 (work in progress), July 611 2008. 613 [I-D.ietf-behave-tcp] Guha, S., Biswas, K., Ford, B., Sivakumar, S., 614 and P. Srisuresh, "NAT Behavioral Requirements for TCP", 615 draft-ietf-behave-tcp-08 (work in progress), September 2008. 617 [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, "A 618 Proposal to Define Interactive Connectivity Establishment for the 619 Transport Control Protocol (ICE-TCP) as an Extensible Framework", 620 draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), 621 October 2008. 623 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 624 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, 625 January 2007. 627 Authors' Addresses 629 Ning Zong 630 Huawei Technologies 632 Email: zongning@huawei.com 634 Xingfeng Jiang 635 Huawei Technologies 637 Email: jiang.x.f@huawei.com 639 Roni Even 640 Huawei Technologies 642 Email: even.roni@huawei.com 644 Yunfei Zhang 645 China Mobile 647 Email: zhangyunfei@chinamobile.com