idnits 2.17.1 draft-ietf-p2psip-drr-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 3837 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 (~~), 2 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: 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 Direct Response Routing 12 draft-ietf-p2psip-drr-11 14 Abstract 16 This document proposes an optional extension to REsource LOcation And 17 Discovery (RELOAD) protocol to support direct response 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 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. SRR and DRR . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. Symmetric Recursive Routing (SRR) . . . . . . . . . . 4 62 3.1.2. Direct Response Routing (DRR) . . . . . . . . . . . . 5 63 3.2. Scenarios where DRR can be used . . . . . . . . . . . . . 6 64 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 6 65 3.2.2. Wireless scenarios . . . . . . . . . . . . . . . . . 6 66 4. Relationship between SRR and DRR . . . . . . . . . . . . . . 6 67 4.1. How DRR works . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. How SRR and DRR work together . . . . . . . . . . . . . . 7 69 5. Comparison on cost of SRR and DRR . . . . . . . . . . . . . . 8 70 5.1. Closed or managed networks . . . . . . . . . . . . . . . 8 71 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 9 72 6. DRR extensions to RELOAD . . . . . . . . . . . . . . . . . . 9 73 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 9 74 6.2. Modification to RELOAD message structure . . . . . . . . 10 75 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 10 76 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 10 77 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 11 78 6.3.1. Creating a request for DRR . . . . . . . . . . . . . 11 79 6.4. Request and response processing . . . . . . . . . . . . . 12 80 6.4.1. Destination peer: receiving a request and sending a 81 response . . . . . . . . . . . . . . . . . . . . . . 12 82 6.4.2. Sending peer: receiving a response . . . . . . . . . 12 83 7. Overlay configuration extension . . . . . . . . . . . . . . . 12 84 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 85 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9.1. A new RELOAD forwarding option . . . . . . . . . . . . . 13 87 9.2. A new IETF XML registry . . . . . . . . . . . . . . . . . 13 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 11.1. Normative references . . . . . . . . . . . . . . . . . . 14 91 11.2. Informative references . . . . . . . . . . . . . . . . . 14 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 Appendix A. Optional methods to investigate peer connectivity . 14 94 A.1. Getting addresses to be used as candidates for DRR . . . 15 95 A.2. Public reachability test . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 REsource LOcation And Discovery (RELOAD) protocol [I-D.ietf-p2psip- 101 base] recommends symmetric recursive routing (SRR) for routing 102 messages and describes the extensions that would be required to 103 support additional routing algorithms. Other than SRR, two other 104 routing options: direct response routing (DRR) and relay peer routing 105 (RPR) are also discussed in Appendix A of [I-D.ietf-p2psip-base]. As 106 we show in section 3, DRR is advantageous over SRR in some scenarios 107 by reducing load (CPU and link bandwidth) on intermediate peers. For 108 example, in a closed network where every peer is in the same address 109 realm, DRR performs better than SRR. In other scenarios, using a 110 combination of DRR and SRR together is more likely to bring benefits 111 than if SRR is used alone. 113 Note that in this document, we focus on DRR routing mode and its 114 extensions to RELOAD to produce a standalone solution. Please refer 115 to RPR draft [I-D.ietf-p2psip-rpr] for RPR routing mode. 117 We first discuss the problem statement in Section 3, then how to 118 combine DRR and SRR is presented in Section 4. In Section 5, we give 119 comparison on the cost of SRR and DRR in both managed and open 120 networks. An extension to RELOAD to support DRR is proposed in 121 Section 6. Some optional methods to check peer connectivity are 122 introduced in Appendix A. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 We use the terminology and definitions from the RELOAD base draft 131 [I-D.ietf-p2psip-base] extensively in this document. We also use 132 terms defined in NAT behavior discovery [RFC5780]. Other terms used 133 in this document are defined inline when used and are also defined 134 below for reference. 136 Publicly Reachable: A peer is publicly reachable if it can receive 137 unsolicited messages from any other peer in the same overlay. 138 Note: "publicly" does not mean that the peers must be on the 139 public Internet, because the RELOAD protocol may be used in a 140 closed network. 142 Direct Response Routing (DRR): refers to a routing mode in which 143 responses to P2PSIP requests are returned to the sending peer 144 directly from the destination peer based on the sending peer's own 145 local transport address(es). For simplicity, the abbreviation DRR 146 is used instead in the rest of the document. 148 Symmetric Recursive Routing (SRR): refers to a routing mode in 149 which responses follow the reverse path of the request to get to 150 the sending peer. For simplicity, the abbreviation SRR is used 151 instead in the rest of the document. 153 3. Overview 155 RELOAD is expected to work under a great number of application 156 scenarios. The situations where RELOAD is to be deployed differ 157 greatly. For instance, some deployments are global, such as a Skype- 158 like system intended to provide public service, while others run in 159 closed networks of small scale. SRR works in any situation, but DRR 160 may work better in some specific scenarios. 162 3.1. SRR and DRR 164 RELOAD is a simple request-response protocol. After sending a 165 request, a peer waits for a response from a destination peer. There 166 are several ways for the destination peer to send a response back to 167 the source peer. In this section, we will provide detailed 168 information on two routing modes: SRR and DRR. 170 Some assumptions are made in the following illustrations. 172 1) Peer A sends a request destined to a peer who is the responsible 173 peer for Resource-ID k; 175 2) Peer X is the root peer being responsible for resource k; 177 3) The intermediate peers for the path from A to X are peer B, C, D. 179 3.1.1. Symmetric Recursive Routing (SRR) 181 For SRR, when the request sent by peer A is received by an 182 intermediate peer B, C or D, each intermediate peer will insert 183 information on the peer from whom they got the request in the via- 184 list as described in RELOAD. As a result, the destination peer X 185 will know the exact path which the request has traversed. Peer X 186 will then send back the response in the reverse path by constructing 187 a destination list based on the via-list in the request. Figure 1 188 illustrates SRR. 190 A B C D X 191 | Request | | | | 192 |----------->| | | | 193 | | Request | | | 194 | |----------->| | | 195 | | | Request | | 196 | | |----------->| | 197 | | | | Request | 198 | | | |----------->| 199 | | | | | 200 | | | | Response | 201 | | | |<-----------| 202 | | | Response | | 203 | | |<-----------| | 204 | | Response | | | 205 | |<-----------| | | 206 | Response | | | | 207 |<-----------| | | | 208 | | | | | 210 Figure 1. SRR routing mode 212 SRR works in any situation, especially when there are NATs or 213 firewalls. A downside of this solution is that the message takes 214 several hops to return to the peer, increasing the bandwidth usage 215 and CPU/battery load of multiple peers. 217 3.1.2. Direct Response Routing (DRR) 219 In DRR, peer X receives the request sent by peer A through 220 intermediate peer B, C and D, as in SRR. However, peer X sends the 221 response back directly to peer A based on peer A's local transport 222 address. In this case, the response is not routed through 223 intermediate peers. Figure 2 illustrates DRR. Using a shorter route 224 means less overhead on intermediate peers, especially in the case of 225 wireless networks where the CPU and uplink bandwidth is limited. For 226 example, in the absence of NATs, or if the NAT implements endpoint- 227 independent filtering, this is the optimal routing technique. Note 228 that establishing a secure connection requires multiple round trips. 229 Please refer to Section 5 for cost comparison between SRR and DRR. 231 A B C D X 232 | Request | | | | 233 |----------->| | | | 234 | | Request | | | 235 | |----------->| | | 236 | | | Request | | 237 | | |----------->| | 238 | | | | Request | 239 | | | |----------->| 240 | | | | | 241 | | | | Response | 242 |<-----------+------------+------------+------------| 243 | | | | | 245 Figure 2. DRR routing mode 247 3.2. Scenarios where DRR can be used 249 This section lists several scenarios where using DRR would work, and 250 identifies when the increased efficiency would be advantageous. 252 3.2.1. Managed or closed P2P systems 254 The properties that make P2P technology attractive, such as the lack 255 of need for centralized servers, self-organization, etc. are 256 attractive for managed systems as well as unmanaged systems. Many of 257 these systems are deployed on private networks where peers are in the 258 same address realm and/or can directly route to each other. In such 259 a scenario, the network administrator can indicate preference for DRR 260 in the peer's configuration file. Peers in such a system would 261 always try DRR first, but peers MUST also support SRR in case DRR 262 fails. If during the process of establishing a direct connection 263 with the sending peer, the responding peer receives a request with 264 SRR as the preferred routing mode (or it fails to establish the 265 direct connection), the responding peer SHOULD NOT use DRR but switch 266 to SRR. The simple policy is to try DRR and if fails switch to SRR 267 for all connections. A finer grained policy is when a peer keeps a 268 list of unreachable peers based on trying DRR and use only SRR for 269 these peers. The advantage in using DRR is on the network stability 270 since it puts less overhead on the intermediate peers that will not 271 route the responses. The intermediate peers will need to route less 272 messages and save CPU resources as well as the link bandwidth usage. 274 3.2.2. Wireless scenarios 276 In some mobile deployments, using DRR may help with reducing radio 277 battery usage and bandwidth by the intermediate peers. The service 278 provider may recommend using DRR based on his/her knowledge of the 279 topology. 281 4. Relationship between SRR and DRR 282 4.1. How DRR works 284 DRR is very simple. The only requirement is for the source peers to 285 provide their potential (publically reachable) transport address to 286 the destination peers, so that the destination peer knows where to 287 send the response. Responses are sent directly to the requesting 288 peer. 290 4.2. How SRR and DRR work together 292 DRR is not intended to replace SRR. It is better to use these two 293 modes together to adapt to each peer's specific situation. In this 294 section, we give some informative suggestions on how to transition 295 between the routing modes in RELOAD. 297 According to base draft [I-D.ietf-p2psip-base], SRR MUST be 298 supported. An overlay MAY be configured to use alternative routing 299 algorithms, and alternative routing algorithms MAY be selected on a 300 per-message basis. I.e., a node in an overlay which supports SRR and 301 some other routing algorithm, for example DRR, might use SRR some of 302 the time and DRR some of the time. A node joining the overlay should 303 get from the configuration file the preferred routing mode. If an 304 overlay runs within a private network and all peers in the system can 305 reach each other directly, peers MAY send most of the transactions 306 with DRR. On the contrary, using DRR SHOULD be discouraged in the 307 open Internet or if the administrator does not feel he have enough 308 information about the overlay network topology. A new overlay 309 configuration element specifying the usage of DRR is defined in 310 Section 7. 312 Alternatively, a peer can collect statistical data on the success of 313 the different routing modes based on previous transactions and keep a 314 list of non-reachable addresses. Based on this data, the peer will 315 have a clearer view about the success rate of different routing 316 modes. Other than the success rate, the peer can also get data of 317 finer granularity, for example, the number of retransmission the peer 318 needs to achieve a desirable success rate. 320 A typical strategy for the peer is as follows. A peer chooses to 321 start with DRR based on the configuration. Based on the success rate 322 seen from the lost message statistics or responses that used DRR, the 323 peer can either continue to offer DRR first or switch to SRR. Note 324 that a peer should use the DRR success statistic to decide if to 325 continue using DRR or fall back to SRR. It is not recommended to 326 make such decision per specific connection but this is an application 327 decision. 329 5. Comparison on cost of SRR and DRR 331 The major advantages in using DRR are in going through less 332 intermediate peers on the response. By doing that it reduces the 333 load on those peers' resources like processing and communication 334 bandwidth. 336 5.1. Closed or managed networks 338 As described in Section 3, many P2P systems run in a closed or 339 managed environment (e.g., carrier networks) so that network 340 administrators would know that they could safely use DRR. 342 SRR brings out more routing hops than DRR. Assuming that there are N 343 peers in the P2P system and Chord is applied for routing, the number 344 of hops for a response in SRR and DRR are listed in the following 345 table. Establishing a secure connection between the sending peer and 346 the responding peer with (D)TLS requires multiple messages. Note 347 that establishing (D)TLS secure connections for P2P overlay is not 348 optimal in some cases, e.g., direct response routing where (D)TLS is 349 heavy for temporary connections. Therefore, in the following table, 350 we show the cases of: 1) no (D)TLS in DRR; 2) still using DTLS in DRR 351 as sub-optimal. As the worst-cost case, 7 messages are used during 352 the DTLS handshaking [DTLS]. (TLS Handshake is a two round-trip 353 negotiation protocol while DTLS handshake is a three round-trip 354 negotiation protocol.) 356 Mode | Success | No. of Hops | No. of Msgs 357 ---------------------------------------------------- 358 SRR | Yes | log(N) | log(N) 359 DRR | Yes | 1 | 1 360 DRR(DTLS) | Yes | 1 | 7+1 362 Table 1. Comparison of SRR and DRR in closed networks 364 From the above comparison, it is clear that: 366 1) In most cases when N > 2 (2^1), DRR uses fewer hops than SRR. 367 Using a shorter route means less overhead and resource usage on 368 intermediate peers, which is an important consideration for adopting 369 DRR in the cases where the resources such as CPU and bandwidth are 370 limited, e.g., the case of mobile, wireless networks. 372 2) In the cases when N > 256 (2^8), DRR also uses fewer messages than 373 SRR. 375 3) In the cases when N < 256, DRR uses more messages than SRR (but 376 still uses fewer hops than SRR). So the consideration on whether 377 using DRR or SRR depends on other factors like using less resources 378 (bandwidth and processing) from the intermediate peers. Section 4 379 provides use cases where DRR has better chance to work or where the 380 intermediary resources considerations are important. 382 5.2. Open networks 384 In open networks (e.g., Internet) where DRR is not guaranteed to 385 work, DRR can fall back to SRR if it fails after trial, as described 386 in Section 4. Based on the same settings in Section 5.1, the number 387 of hops, number of messages for a response in SRR and DRR are listed 388 in the following table. 390 Mode | Success | No. of Hops | No. of Msgs 391 ----------------------------------------------------------- 392 SRR | Yes | log(N) | log(N) 393 DRR | Yes | 1 | 1 394 | Fail&Fall back to SRR | 1+log(N)| 1+log(N) 395 DRR(DTLS) | Yes | 1 | 7+1 396 | Fail&Fall back to SRR | 1+log(N)| 8+log(N) 398 Table 2. Comparison of SRR and DRR in open networks 400 From the above comparison, it can be observed that trying to first 401 use DRR could still provide an overall number of hops lower than 402 directly using SRR. Suppose that P peers are publicly reachable, the 403 number of hops in DRR and SRR is P*1+(N-P)*(1+logN), N*logN, 404 respectively. The condition for fewer hops in DRR is 405 P*1+(N-P)*(1+logN) < N*logN, which is P/N > 1/logN. This means that 406 when the number of peers N grows, the required ratio of publicly 407 reachable peers P/N for fewer hops in DRR decreases. Therefore, the 408 chance of trying DRR with fewer hops than SRR becomes better as the 409 scale of the network increases. 411 6. DRR extensions to RELOAD 413 Adding support for DRR requires extensions to the current RELOAD 414 protocol. In this section, we define the extensions required to the 415 protocol, including extensions to message structure and to message 416 processing. 418 6.1. Basic requirements 420 All peers MUST be able to process requests for routing in SRR, and 421 MAY support DRR routing requests. 423 6.2. Modification to RELOAD message structure 425 RELOAD provides an extensible framework to accommodate future 426 extensions. In this section, we define a ForwardingOption structure 427 to support DRR mode. Additionally we present a state-keeping flag to 428 inform intermediate peers if they are allowed to not maintain state 429 for a transaction. 431 6.2.1. State-keeping flag 433 RELOAD allows intermediate peers to maintain state in order to 434 implement SRR, for example for implementing hop-by-hop 435 retransmission. If DRR is used, the response will not follow the 436 reverse path, and the state in the intermediate peers will not be 437 cleared until such state expires. In order to address this issue, we 438 propose a new flag, state-keeping flag, in the message header to 439 indicate whether the state keeping is required in the intermediate 440 peers. 442 flag : 0x08 IGNORE-STATE-KEEPING 444 If IGNORE-STATE-KEEPING is set, any peer receiving this message and 445 which is not the destination of the message SHOULD forward the 446 message with the full via_list and SHOULD NOT maintain any internal 447 state. 449 6.2.2. Extensive routing mode 451 This draft introduces a new forwarding option for an extensive 452 routing mode. This option conforms to the description in section 453 6.3.2.3 of [I-D.ietf-p2psip-base]. 455 We first define a new type to define the new option, 456 extensive_routing_mode: 458 The option value is illustrated as below, defining the 459 ExtensiveRoutingModeOption structure: 461 enum {(0),DRR(1),(255)} RouteMode; 462 struct { 463 RouteMode routemode; 464 OverlayLinkType transport; 465 IpAddressPort ipaddressport; 466 Destination destinations<1..2^8-1>; 467 } ExtensiveRoutingModeOption; 468 The above structure reuses OverlayLinkType, Destination and 469 IpAddressPort structure defined in section 6.5.1.1, 6.3.2.2 and 470 6.3.1.1 of [I-D.ietf-p2psip-base]. 472 RouteMode: refers to which type of routing mode is indicated to the 473 destination peer. 475 OverlayLinkType: refers to the transport type which is used to 476 deliver responses from the destination peer to the sending peer. 478 IpAddressPort: refers to the transport address that the destination 479 peer use to send the response to. This will be a sending peer 480 address for DRR. 482 Destination: refers to the sending peer itself. If the routing mode 483 is DRR, then the destination only contains the sending peer's Node- 484 ID. 486 6.3. Creating a request 488 6.3.1. Creating a request for DRR 490 When using DRR for a transaction, the sending peer MUST set the 491 IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the 492 peer MUST construct and include a ForwardingOptions structure in the 493 ForwardingHeader. When constructing the ForwardingOption structure, 494 the fields MUST be set as follows: 496 1) The type MUST be set to extensive_routing_mode. 498 2) The ExtensiveRoutingModeOption structure MUST be used for the 499 option field within the ForwardingOptions structure. The fields MUST 500 be defined as follows: 502 2.1) routemode set to 0x01 (DRR). 504 2.2) transport set as appropriate for the sender. 506 2.3) ipaddressport set to the peer's associated transport address. 508 2.4) The destination structure MUST contain one value, defined as 509 type node and set with the sending peer's own values. 511 6.4. Request and response processing 513 This section gives normative text for message processing after DRR is 514 introduced. Here, we only describe the additional procedures for 515 supporting DRR. Please refer to [I-D.ietf-p2psip-base] for RELOAD 516 base procedures. 518 6.4.1. Destination peer: receiving a request and sending a response 520 When the destination peer receives a request, it will check the 521 options in the forwarding header. If the destination peer can not 522 understand extensive_routing_mode option in the request, it MUST 523 attempt to use SRR to return an "Error_Unknown_Extension" response 524 (defined in Section 6.3.3.1 and Section 14.9 of [I-D.ietf-p2psip- 525 base]) to the sending peer. 527 If the routing mode is DRR, the peer MUST construct the Destination 528 list for the response with only one entry, using the sending peer's 529 Node-ID from the option in the request as the value. 531 In the event that the routing mode is set to DRR and there is not 532 exactly one destination, the destination peer MUST try to return an 533 "Error_Unknown_Extension" response (defined in Section 6.3.3.1 and 534 Section 14.9 of [I-D.ietf-p2psip-base]) to the sending peer using 535 SRR. 537 After the peer constructs the destination list for the response, it 538 sends the response to the transport address which is indicated in the 539 ipaddressport field in the option using the specific transport mode 540 in the Forwardingoption. If the destination peer receives a 541 retransmit with SRR preference on the message it is trying to respond 542 to now, the responding peer SHOULD abort the DRR response and use 543 SRR. 545 6.4.2. Sending peer: receiving a response 547 Upon receiving a response, the peer follows the rules in [I-D.ietf- 548 p2psip-base]. The peer SHOULD note if DRR worked in order to decide 549 if to offer DRR again. If the peer does not receive a response until 550 the timeout it SHOULD resend the request using SRR. 552 7. Overlay configuration extension 554 This document extends the RELOAD overlay configuration (see 555 Section 11.1 of [I-D.ietf-p2psip-base]) by adding one new element, 556 "route-mode", inside each "configuration" element. 558 The Compact Relax NG Grammar for this element is: 560 namespace route-mode = "urn:ietf:params:xml:ns:p2p:route-mode" 562 parameter &= element route-mode:mode { xsd:string }? 564 This namespace is added into the element in the 565 overlay configuration file. The defined routing modes include DRR 566 and RPR. 568 Mode can be DRR or RPR and if specified in the configuration should 569 be the preferred routing mode used by the application. 571 8. Security considerations 573 The normative security recommendations of Section 13 of base draft 574 [I-D.ietf-p2psip-base] are applicable to this document. As a routing 575 alternative, the security part of DRR conforms to Section 13.6 of the 576 base draft which describes routing security. For example, the DRR 577 routing option provides the information about the route back to the 578 source. According to Section 13.6 of the base draft the enter DRR 579 routing message MUST be digitally signed and sent over by protected 580 channel to protect the DRR routing information. 582 9. IANA considerations 584 9.1. A new RELOAD forwarding option 586 A new RELOAD Forwarding Option type is added to the Forwarding Option 587 Registry defined in [I-D.ietf-p2psip-base]. 589 Type: 0x02 - extensive_routing_mode 591 9.2. A new IETF XML registry 593 This section requests IANA to register the following URN in the "XML 594 Namespaces" class of the "IETF XML Registry" in accordance with 595 [RFC3688]. 597 URI: urn:ietf:params:xml:ns:p2p:route-mode 599 Registrant Contact: The IESG 601 XML: This specification 603 10. Acknowledgments 605 David Bryan has helped extensively with this document, and helped 606 provide some of the text, analysis, and ideas contained here. The 607 authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti 608 Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and 609 Carlos Jesus Bernardos Cano for their constructive comments. 611 11. References 613 11.1. Normative references 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC2119, March 1997. 618 [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., 619 Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery 620 (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in 621 progress), February 2013. 623 [RFC3688] Mealling, M., "The IETF XML Registry ", BCP 81, RFC3688, 624 January 2004. 626 11.2. Informative references 628 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of 629 Datagram TLS", 11th Network and Distributed System Security Symposium 630 (NDSS), 2004. 632 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 633 Using STUN", RFC5780, May 2010. 635 [I-D.ietf-p2psip-rpr] Zong, N., Jiang, X., Even, R. and Zhang, Y., 636 "An extension to RELOAD to support Relay Peer Routing", draft-ietf- 637 p2psip-rpr-11 (work in progress), October 2013. 639 [IGD2] UPnP Forum, "WANIPConnection:2 Service (http://upnp.org/specs/ 640 gw/UPnP-gw-WANIPConnection-v2-Service.pdf)", September 2010. 642 [RFC6886] Cheshire, S., Krochmal M., and K. Sekar, "NAT Port Mapping 643 Protocol (NAT-PMP)", RFC6886, April 2013. 645 [RFC3424] Daigle, L., "IAB Considerations for UNilateral Self-Address 646 Fixing (UNSAF) Across Network Address Translation", RFC3424, November 647 2002. 649 12. References 651 Appendix A. Optional methods to investigate peer connectivity 653 This section is for informational purposes only for providing some 654 mechanisms that can be used when the configuration information does 655 not specify if DRR can be used. It summarizes some methods which can 656 be used for a peer to determine its own network location compared 657 with NAT. These methods may help a peer to decide which routing mode 658 it may wish to try. Note that there is no foolproof way to determine 659 if a peer is publically reachable, other than via out-of-band 660 mechanisms. This document addresses the UNSAF [RFC3424] concerns by 661 specifying a fallback plan to SRR [p2psip-base-draft]. SRR is not an 662 UNSAF mechanism. The document does not define any new UNSAF 663 mechanisms. 665 For DRR to function correctly, a peer may attempt to determine 666 whether it is publicly reachable. If it is not, the peers should 667 fall back to SRR. If the peer believes it is publically reachable, 668 DRR may be attempted. NATs and firewalls are two major contributors 669 preventing DRR from functioning properly. There are a number of 670 techniques by which a peer can get its reflexive address on the 671 public side of the NAT. After obtaining the reflexive address, a 672 peer can perform further tests to learn whether the reflexive address 673 is publicly reachable. If the address appears to be publicly 674 reachable, the peers to which the address belongs can use DRR for 675 responses. 677 Some conditions are unique in P2PSIP architecture which could be 678 leveraged to facilitate the tests. In P2P overlay network, each peer 679 only has partial a view of the whole network, and knows of a few 680 peers in the overlay. P2P routing algorithms can easily deliver a 681 request from a sending peer to a peer with whom the sending peer has 682 no direct connection. This makes it easy for a peer to ask other 683 peers to send unsolicited messages back to the requester. 685 In the following sections, we first introduce several ways for a peer 686 to get the addresses needed for further tests. Then a test for 687 learning whether a peer may be publicly reachable is proposed. 689 A.1. Getting addresses to be used as candidates for DRR 691 In order to test whether a peer may be publicly reachable, the peer 692 should first get one or more addresses which will be used by other 693 peers to send him messages directly. This address is either a local 694 address of a peer or a translated address which is assigned by a NAT 695 to the peer. 697 STUN is used to get a reflexive address on the public side of a NAT 698 with the help of STUN servers. Discovery of NAT behavior using STUN 699 is specified in [RFC5780]. Under RELOAD architecture, a few 700 infrastructure servers can be leveraged for discovering NAT behavior, 701 such as enrollment servers, diagnostic servers, bootstrap servers, 702 etc. 704 The peer can use a STUN Binding request to one of STUN servers to 705 trigger a STUN Binding response which returns the reflexive address 706 from the server's perspective. If the reflexive transport address is 707 the same as the source address of the Binding request, the peer can 708 determine that there likely is no NAT between it and the chosen 709 infrastructure server (Certainly, in some rare cases, the allocated 710 address happens to be the same as the source address. Further tests 711 will detect this case and rule it out in the end.). Usually, these 712 infrastructure severs are publicly reachable in the overlay, so the 713 peer can be considered publicly reachable. On the other hand, with 714 the techniques in [RFC5780], a peer can also decide whether it is 715 behind a NAT with endpoint-independent mapping behavior. If the peer 716 is behind a NAT with endpoint- independent mapping behavior, the 717 reflexive address should also be a candidate for further tests. 719 UPnP-IGD [IGD2] is a mechanism that a peer can use to get the 720 assigned address from its residential gateway and after obtaining 721 this address to communicate it with other peers, the peer can receive 722 unsolicited messages from outside, even though it is behind a NAT. 723 So the address obtained through the UPnP mechanism should also be 724 used for further tests. 726 Another way that a peer behind NAT can use to learn its assigned 727 address by NAT is NAT-PMP [RFC6886]. Like in UPnP-IGD, the address 728 obtained using this mechanism should also be tested further. 730 The above techniques are not exhaustive. These techniques can be 731 used to get candidate transport addresses for further tests. 733 A.2. Public reachability test 735 Using the transport addresses obtained by the above techniques, a 736 peer can start a test to learn whether the candidate transport 737 address is publicly reachable. The basic idea for the test is for a 738 peer to send a request and expect another peer in the overlay to send 739 back a response. If the response is received by the sending peer 740 successfully and also the peer giving the response has no direct 741 connection with the sending peer, the sending peer can determine that 742 the address is probably publicly reachable and hence the peer may be 743 publicly reachable at the tested transport address. 745 In a P2P overlay, a request is routed through the overlay and finally 746 a destination peer will terminate the request and give the response. 747 In a large system, there is a high probability that the destination 748 peer has no direct connection with the sending peer. Especially in 749 RELOAD architecture, every peer maintains a connection table. So it 750 is easier for a peer to check whether it has direct connection with 751 another peer. 753 If a peer wants to test whether its transport address is publicly 754 reachable, it can send a request to the overlay. The routing for the 755 test message would be different from other kinds of requests because 756 it is not for storing/fetching something to/from the overlay or 757 locating a specific peer, instead it is to get a peer who can deliver 758 the sending peer an unsolicited response and which has no direct 759 connection with him. Each intermediate peer receiving the request 760 first checks whether it has a direct connections with the sending 761 peer. If there is a direct connection, the request is routed to the 762 next peer. If there is no direct connection, the intermediate peer 763 terminates the request and sends the response back directly to the 764 sending peer with the transport address under test. 766 After performing the test, if the peer determines that it may be 767 publicly reachable, it can try DRR in subsequent transactions. 769 Authors' Addresses 771 Ning Zong (editor) 772 Huawei Technologies 774 Email: zongning@huawei.com 776 Xingfeng Jiang 777 Huawei Technologies 779 Email: jiang.x.f@huawei.com 781 Roni Even 782 Huawei Technologies 784 Email: roni.even@mail01.huawei.com 786 Yunfei Zhang 787 CoolPad 789 Email: hishigh@gmail.com