doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7263.txt b/doc/rfc/rfc7263.txt
new file mode 100644
index 0000000..7733049
--- /dev/null
+++ b/doc/rfc/rfc7263.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           N. Zong
+Request for Comments: 7263                                      X. Jiang
+Category: Standards Track                                        R. Even
+ISSN: 2070-1721                                      Huawei Technologies
+                                                                Y. Zhang
+                                                  CoolPad / China Mobile
+                                                               June 2014
+
+
+ An Extension to the REsource LOcation And Discovery (RELOAD) Protocol
+                   to Support Direct Response Routing
+
+Abstract
+
+   This document defines an optional extension to the REsource LOcation
+   And Discovery (RELOAD) protocol to support the direct response
+   routing mode.  RELOAD recommends symmetric recursive routing for
+   routing messages.  The new optional extension provides a shorter
+   route for responses, thereby reducing overhead on intermediate peers.
+   This document also describes potential cases where this extension can
+   be used.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7263.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 1]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 2]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+   3. Overview ........................................................5
+      3.1. SRR and DRR ................................................5
+           3.1.1. Symmetric Recursive Routing (SRR) ...................6
+           3.1.2. Direct Response Routing (DRR) .......................6
+      3.2. Scenarios Where DRR Can Be Used ............................7
+           3.2.1. Managed or Closed P2P Systems .......................7
+           3.2.2. Wireless Scenarios ..................................8
+   4. Relationship between SRR and DRR ................................8
+      4.1. How DRR Works ..............................................8
+      4.2. How SRR and DRR Work Together ..............................8
+   5. DRR Extensions to RELOAD ........................................9
+      5.1. Basic Requirements .........................................9
+      5.2. Modification to RELOAD Message Structure ...................9
+           5.2.1. State-Keeping Flag ..................................9
+           5.2.2. Extensive Routing Mode .............................10
+      5.3. Creating a Request ........................................11
+           5.3.1. Creating a Request for DRR .........................11
+      5.4. Request and Response Processing ...........................11
+           5.4.1. Destination Peer: Receiving a Request and
+                  Sending a Response .................................11
+           5.4.2. Sending Peer: Receiving a Response .................12
+   6. Overlay Configuration Extension ................................12
+   7. Security Considerations ........................................12
+   8. IANA Considerations ............................................13
+      8.1. A New RELOAD Forwarding Option ............................13
+      8.2. A New IETF XML Registry ...................................13
+   9. Acknowledgments ................................................13
+   10. References ....................................................13
+      10.1. Normative References .....................................13
+      10.2. Informative References ...................................14
+   Appendix A. Optional Methods to Investigate Peer Connectivity .....15
+     A.1. Getting Addresses to Be Used as Candidates for DRR .........15
+     A.2. Public Reachability Test ...................................16
+   Appendix B. Comparison of Cost of SRR and DRR .....................17
+     B.1. Closed or Managed Networks .................................17
+     B.2. Open Networks ..............................................19
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 3]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+1.  Introduction
+
+   The REsource LOcation And Discovery (RELOAD) protocol [RFC6940]
+   recommends symmetric recursive routing (SRR) for routing messages and
+   describes the extensions that would be required to support additional
+   routing algorithms.  In addition to SRR, two other routing options --
+   direct response routing (DRR) and relay peer routing (RPR) -- are
+   also discussed in Appendix A of [RFC6940].  As we show in Section 3,
+   DRR is advantageous over SRR in some scenarios in that DRR can reduce
+   load (CPU and link bandwidth) on intermediate peers.  For example, in
+   a closed network where every peer is in the same address realm, DRR
+   performs better than SRR.  In other scenarios, using a combination of
+   DRR and SRR together is more likely to provide benefits than if SRR
+   is used alone.
+
+   Note that in this document we focus on the DRR mode and its
+   extensions to RELOAD to produce a standalone solution.  Please refer
+   to [RFC7264] for details on the RPR mode.
+
+   We first discuss the problem statement in Section 3.  How to combine
+   DRR and SRR is presented in Section 4.  An extension to RELOAD to
+   support DRR is defined in Section 5.  Some optional methods to check
+   peer connectivity are introduced in Appendix A.  In Appendix B, we
+   give a comparison of the cost of SRR and DRR in both managed and open
+   networks.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   We use terminology and definitions from the base RELOAD specification
+   [RFC6940] extensively in this document.  We also use terms defined in
+   the NAT behavior discovery document [RFC5780].  Other terms used in
+   this document are defined inline when used and are also defined below
+   for reference.
+
+      Publicly Reachable: A peer is publicly reachable if it can receive
+      unsolicited messages from any other peer in the same overlay.
+      Note: "Publicly" does not mean that the peers must be on the
+      public Internet, because the RELOAD protocol may be used in a
+      closed network.
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 4]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+      Direct Response Routing (DRR): "DRR" refers to a routing mode in
+      which responses to Peer-to-Peer SIP (P2PSIP) requests are returned
+      to the sending peer directly from the destination peer based on
+      the sending peer's own local transport address(es).  For
+      simplicity, the abbreviation "DRR" is used in the rest of this
+      document.
+
+      Symmetric Recursive Routing (SRR): "SRR" refers to a routing mode
+      in which responses follow the reverse path of the request to get
+      to the sending peer.  For simplicity, the abbreviation "SRR" is
+      used in the rest of this document.
+
+      Relay Peer Routing (RPR): "RPR" refers to a routing mode in which
+      responses to P2PSIP requests are sent by the destination peer to
+      the transport address of a relay peer that will forward the
+      responses towards the sending peer.  For simplicity, the
+      abbreviation "RPR" is used in the rest of this document.
+
+3.  Overview
+
+   RELOAD is expected to work under a great number of application
+   scenarios.  The situations where RELOAD is to be deployed differ
+   greatly.  For instance, some deployments are global, such as a
+   Skype-like system intended to provide public service, while others
+   run in small-scale closed networks.  SRR works in any situation, but
+   DRR may work better in some specific scenarios.
+
+3.1.  SRR and DRR
+
+   RELOAD is a simple request-response protocol.  After sending a
+   request, a peer waits for a response from a destination peer.  There
+   are several ways for the destination peer to send a response back to
+   the source peer.  In this section, we will provide detailed
+   information on two routing modes: SRR and DRR.
+
+   Some assumptions are made in the illustrations that follow:
+
+   1)  Peer A sends a request destined to a peer who is the responsible
+       peer for a Resource-ID k.
+
+   2)  Peer X is the root peer responsible for Resource-ID k.
+
+   3)  The intermediate peers for the path from A to X are peers B, C,
+       and D.
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 5]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+3.1.1.  Symmetric Recursive Routing (SRR)
+
+   For SRR, when the request sent by peer A is received by an
+   intermediate peer B, C, or D, each intermediate peer will insert
+   information on the peer from whom they got the request in the
+   Via List, as described in RELOAD [RFC6940].  As a result, the
+   destination peer X will know the exact path that the request has
+   traversed.  Peer X will then send back the response in the reverse
+   path by constructing a Destination List based on the Via List in the
+   request.  Figure 1 illustrates SRR.
+
+         A            B            C             D           X
+         |  Request   |            |            |            |
+         |----------->|            |            |            |
+         |            | Request    |            |            |
+         |            |----------->|            |            |
+         |            |            | Request    |            |
+         |            |            |----------->|            |
+         |            |            |            | Request    |
+         |            |            |            |----------->|
+         |            |            |            |            |
+         |            |            |            |  Response  |
+         |            |            |            |<-----------|
+         |            |            |  Response  |            |
+         |            |            |<-----------|            |
+         |            |  Response  |            |            |
+         |            |<-----------|            |            |
+         |  Response  |            |            |            |
+         |<-----------|            |            |            |
+         |            |            |            |            |
+
+                            Figure 1: SRR Mode
+
+   SRR works in any situation, especially when there are NATs or
+   firewalls.  A downside of this solution is that the message takes
+   several hops to return to the peer, increasing the bandwidth usage
+   and CPU/battery load of multiple peers.
+
+3.1.2.  Direct Response Routing (DRR)
+
+   In DRR, peer X receives the request sent by peer A through
+   intermediate peers B, C, and D, as in SRR.  However, peer X sends the
+   response back directly to peer A based on peer A's local transport
+   address.  In this case, the response is not routed through
+   intermediate peers.  Figure 2 illustrates DRR.  Using a shorter route
+   means less overhead on intermediate peers, especially in the case of
+   wireless networks where the CPU and uplink bandwidth are limited.
+   For example, in the absence of NATs, or if the NAT implements
+
+
+
+Zong, et al.                 Standards Track                    [Page 6]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   endpoint-independent filtering, this is the optimal routing
+   technique.  Note that establishing a secure connection requires
+   multiple round trips.  Please refer to Appendix B for a cost
+   comparison between SRR and DRR.
+
+           A            B            C             D           X
+           |  Request   |            |            |            |
+           |----------->|            |            |            |
+           |            | Request    |            |            |
+           |            |----------->|            |            |
+           |            |            | Request    |            |
+           |            |            |----------->|            |
+           |            |            |            | Request    |
+           |            |            |            |----------->|
+           |            |            |            |            |
+           |            |            |            |  Response  |
+           |<-----------+------------+------------+------------|
+           |            |            |            |            |
+
+                            Figure 2: DRR Mode
+
+3.2.  Scenarios Where DRR Can Be Used
+
+   This section lists several scenarios where using DRR would work and
+   identifies when the increased efficiency would be advantageous.
+
+3.2.1.  Managed or Closed P2P Systems
+
+   The properties that make P2P technology attractive, such as the lack
+   of need for centralized servers, self-organization, etc., are
+   attractive for managed systems as well as unmanaged systems.  Many of
+   these systems are deployed on private networks where peers are in the
+   same address realm and/or can directly route to each other.  In such
+   a scenario, the network administrator can indicate preference for DRR
+   in the peer's configuration file.  Peers in such a system would
+   always try DRR first, but peers MUST also support SRR in case DRR
+   fails.  During the process of establishing a direct connection with
+   the sending peer, if the responding peer receives a request with SRR
+   as the preferred routing mode (or it fails to establish the direct
+   connection), the responding peer SHOULD NOT use DRR but instead
+   switch to SRR.  The simple policy is to try DRR and, if this fails,
+   switch to SRR for all connections.  In a finer-grained policy, a peer
+   would keep a list of unreachable peers based on trying DRR and then
+   would use only SRR for those peers.  The advantage of using DRR is
+   network stability, since it puts less overhead on the intermediate
+   peers that will not route the responses.  The intermediate peers will
+   need to route fewer messages and will save CPU resources as well as
+   link bandwidth usage.
+
+
+
+Zong, et al.                 Standards Track                    [Page 7]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+3.2.2.  Wireless Scenarios
+
+   In some mobile deployments, using DRR may help reduce radio battery
+   usage and bandwidth by the intermediate peers.  The service provider
+   may recommend using DRR based on his knowledge of the topology.
+
+4.  Relationship between SRR and DRR
+
+4.1.  How DRR Works
+
+   DRR is very simple.  The only requirement is for the source peers to
+   provide their potential (publicly reachable) transport address to the
+   destination peers, so that the destination peer knows where to send
+   the response.  Responses are sent directly to the requesting peer.
+
+4.2.  How SRR and DRR Work Together
+
+   DRR is not intended to replace SRR.  It is better to use these two
+   modes together to adapt to each peer's specific situation.  In this
+   section, we give some informative suggestions for how to transition
+   between the routing modes in RELOAD.
+
+   According to [RFC6940], SRR MUST be supported.  An overlay MAY be
+   configured to use alternative routing algorithms, and alternative
+   routing algorithms MAY be selected on a per-message basis.  That is,
+   a node in an overlay that supports SRR and some other routing
+   algorithm -- for example, DRR -- might use SRR some of the time and
+   DRR some of the time.  A node joining the overlay should get the
+   preferred routing mode from the configuration file.  If an overlay
+   runs within a private network and all peers in the system can reach
+   each other directly, peers MAY send most of the transactions with
+   DRR.  However, DRR SHOULD NOT be used in the open Internet or if the
+   administrator does not feel he has enough information about the
+   overlay network topology.  A new overlay configuration element
+   specifying the usage of DRR is defined in Section 6.
+
+   Alternatively, a peer can collect statistical data on the success of
+   the different routing modes based on previous transactions and keep a
+   list of non-reachable addresses.  Based on this data, the peer will
+   have a clearer view of the success rate of different routing modes.
+   In addition to data on the success rate, the peer can also get data
+   of finer granularity -- for example, the number of retransmissions
+   the peer needs to achieve a desirable success rate.
+
+   A typical strategy for the peer is as follows.  A peer chooses to
+   start with DRR based on the configuration.  Based on the success rate
+   as indicated by statistics on lost messages or by responses that used
+   DRR, the peer can either continue to offer DRR first or switch to
+
+
+
+Zong, et al.                 Standards Track                    [Page 8]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   SRR.  Note that a peer should use the DRR success statistics to
+   decide whether to continue using DRR or fall back to SRR.  Making
+   such a decision per specific connection is not recommended; this
+   should be an application decision.
+
+5.  DRR Extensions to RELOAD
+
+   Adding support for DRR requires extensions to the current RELOAD
+   protocol.  In this section, we define the required extensions,
+   including extensions to message structure and message processing.
+
+5.1.  Basic Requirements
+
+   All peers MUST be able to process requests for routing in SRR and MAY
+   support DRR routing requests.
+
+5.2.  Modification to RELOAD Message Structure
+
+   RELOAD provides an extensible framework to accommodate future
+   extensions.  In this section, we define a ForwardingOption structure
+   to support DRR mode.  Additionally, we present a state-keeping flag
+   to inform intermediate peers if they are allowed to not maintain
+   state for a transaction.
+
+5.2.1.  State-Keeping Flag
+
+   RELOAD allows intermediate peers to maintain state in order to
+   implement SRR -- for example, for implementing hop-by-hop
+   retransmission.  If DRR is used, the response will not follow the
+   reverse path, and the state in the intermediate peers will not be
+   cleared until such state expires.  In order to address this issue, we
+   define a new flag, state-keeping flag, in the ForwardingOption
+   structure to indicate whether the state-keeping is required in the
+   intermediate peers.
+
+   Flag: 0x08 IGNORE-STATE-KEEPING
+
+   If IGNORE-STATE-KEEPING is set, any peer receiving this message but
+   who is not the destination of the message SHOULD forward the message
+   with the full Via List and SHOULD NOT maintain any internal state.
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                    [Page 9]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+5.2.2.  Extensive Routing Mode
+
+   This document introduces a new forwarding option for an extensive
+   routing mode.  This option conforms to the description in
+   Section 6.3.2.3 of [RFC6940].
+
+   We first define a new type to define the new option,
+   extensive_routing_mode:
+
+   The option value that defines the ExtensiveRoutingModeOption
+   structure is illustrated below:
+
+   enum {(0),DRR(1),(255)} RouteMode;
+   struct {
+           RouteMode               routemode;
+           OverlayLinkType         transport;
+           IpAddressPort           ipaddressport;
+           Destination             destinations<1..2^8-1>;
+   } ExtensiveRoutingModeOption;
+
+   The above structure reuses the OverlayLinkType, Destination, and
+   IpAddressPort structures as defined in Sections 6.5.1.1, 6.3.2.2, and
+   6.3.1.1 of [RFC6940], respectively.
+
+   RouteMode: refers to which type of routing mode is indicated to the
+   destination peer.
+
+   OverlayLinkType: refers to the transport type that is used to deliver
+   responses from the destination peer to the sending peer.
+
+   IpAddressPort: refers to the transport address that the destination
+   peer will use for sending responses.  This will be a sending peer
+   address for DRR.
+
+   Destination: refers to the sending peer itself.  If the routing mode
+   is DRR, then the destination only contains the sending peer's
+   Node-ID.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 10]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+5.3.  Creating a Request
+
+5.3.1.  Creating a Request for DRR
+
+   When using DRR for a transaction, the sending peer MUST set the
+   IGNORE-STATE-KEEPING flag in the ForwardingHeader.  Additionally, the
+   peer MUST construct and include a ForwardingOption structure in the
+   ForwardingHeader.  When constructing the ForwardingOption structure,
+   the fields MUST be set as follows:
+
+   1)  The type MUST be set to extensive_routing_mode.
+
+   2)  The ExtensiveRoutingModeOption structure MUST be used for the
+       option field within the ForwardingOption structure.  The fields
+       MUST be defined as follows:
+
+       2.1)  routemode set to 0x01 (DRR).
+
+       2.2)  transport set as appropriate for the sender.
+
+       2.3)  ipaddressport set to the peer's associated transport
+             address.
+
+       2.4)  The destination structure MUST contain one value, defined
+             as type "node" and set with the sending peer's own values.
+
+5.4.  Request and Response Processing
+
+   This section gives normative text for message processing after DRR is
+   introduced.  Here, we only describe the additional procedures for
+   supporting DRR.  Please refer to [RFC6940] for RELOAD base
+   procedures.
+
+5.4.1.  Destination Peer: Receiving a Request and Sending a Response
+
+   When the destination peer receives a request, it will check the
+   options in the forwarding header.  If the destination peer cannot
+   understand the extensive_routing_mode option in the request, it MUST
+   attempt to use SRR to return an "Error_Unknown_Extension" response
+   (defined in Sections 6.3.3.1 and 14.9 of [RFC6940]) to the sending
+   peer.
+
+   If the routing mode is DRR, the destination peer MUST construct the
+   Destination List for the response with only one entry, using the
+   requesting peer's Node-ID from the Via List in the request as the
+   value.
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 11]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   In the event that the routing mode is set to DRR and there is not
+   exactly one destination, the destination peer MUST try to return an
+   "Error_Unknown_Extension" response (defined in Sections 6.3.3.1 and
+   14.9 of [RFC6940]) to the sending peer using SRR.
+
+   After the peer constructs the Destination List for the response, it
+   sends the response to the transport address, which is indicated in
+   the ipaddressport field in the option using the specific transport
+   mode in the ForwardingOption.  If the destination peer receives a
+   retransmit with SRR preference on the message it is trying to respond
+   to now, the responding peer SHOULD abort the DRR response and
+   use SRR.
+
+5.4.2.  Sending Peer: Receiving a Response
+
+   Upon receiving a response, the peer follows the rules in [RFC6940].
+   The peer SHOULD note if DRR worked, in order to decide whether to
+   offer DRR again.  If the peer does not receive a response until the
+   timeout, it SHOULD resend the request using SRR.
+
+6.  Overlay Configuration Extension
+
+   This document extends the RELOAD overlay configuration (see
+   Section 11.1 of [RFC6940]) by adding one new element, "route-mode",
+   inside each "configuration" element.
+
+   The Compact Regular Language for XML Next Generation (RELAX NG)
+   grammar for this element is:
+
+      namespace route-mode = "urn:ietf:params:xml:ns:p2p:route-mode"
+
+      parameter &= element route-mode:mode { xsd:string }?
+
+   This namespace is added into the <mandatory-extension> element in the
+   overlay configuration file.  The defined routing modes include DRR
+   and RPR.
+
+   The mode can be DRR or RPR and, if specified in the configuration,
+   should be the preferred routing mode used by the application.
+
+7.  Security Considerations
+
+   The normative security recommendations of Section 13 of [RFC6940] are
+   applicable to this document.  As a routing alternative, the security
+   part of DRR conforms to Section 13.6 of [RFC6940], which describes
+   routing security.  For example, the DRR routing option provides
+   information about the route back to the source.  According to
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 12]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   Section 13.6 of [RFC6940], the entire DRR routing message MUST be
+   digitally signed and sent over via a protected channel to protect the
+   DRR routing information.
+
+8.  IANA Considerations
+
+8.1.  A New RELOAD Forwarding Option
+
+   A new RELOAD Forwarding Option type has been added to the "RELOAD
+   Forwarding Option" registry defined in [RFC6940].
+
+   Code: 2
+   Forwarding Option: extensive_routing_mode
+
+8.2.  A New IETF XML Registry
+
+   IANA has registered the following URN in the "XML Namespaces" class
+   of the "IETF XML Registry" in accordance with [RFC3688].
+
+   URI: urn:ietf:params:xml:ns:p2p:route-mode
+
+   Registrant Contact: The IESG
+
+   XML: This specification
+
+9.  Acknowledgments
+
+   David Bryan helped extensively with this document and helped provide
+   some of the text, analysis, and ideas contained here.  The authors
+   would like to thank Ted Hardie, Narayanan Vidya, Dondeti Lakshminath,
+   Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin, and Carlos
+   Jesus Bernardos Cano for their constructive comments.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC6940]  Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
+              H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
+              Base Protocol", RFC 6940, January 2014.
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 13]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+10.2.  Informative References
+
+   [Chord]    Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
+              Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
+              Scalable Peer-to-Peer Lookup Protocol for Internet
+              Applications", IEEE/ACM Transactions on Networking
+              Volume 11, Issue 1, 17-32, February 2003.
+
+   [DTLS]     Modadugu, N. and E. Rescorla, "The Design and
+              Implementation of Datagram TLS", Proc. 11th Network and
+              Distributed System Security Symposium (NDSS),
+              February 2004.
+
+   [IGD2]     UPnP Forum, "WANIPConnection:2 Service", September 2010,
+              <http://upnp.org/specs/gw/
+              UPnP-gw-WANIPConnection-v2-Service.pdf>.
+
+   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
+              Self-Address Fixing (UNSAF) Across Network Address
+              Translation", RFC 3424, November 2002.
+
+   [RFC5780]  MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
+              Using Session Traversal Utilities for NAT (STUN)",
+              RFC 5780, May 2010.
+
+   [RFC6886]  Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
+              (NAT-PMP)", RFC 6886, April 2013.
+
+   [RFC7264]  Zong, N., Jiang, X., Even, R., and Y. Zhang, "An Extension
+              to the REsource LOcation And Discovery (RELOAD) Protocol
+              to Support Relay Peer Routing", RFC 7264, June 2014.
+
+   [wikiChord]
+              Wikipedia, "Chord (peer-to-peer)", 2013,
+              <http://en.wikipedia.org/w/
+              index.php?title=Chord_%28peer-to-peer%29&oldid=549516287>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 14]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+Appendix A.  Optional Methods to Investigate Peer Connectivity
+
+   This section is for informational purposes only and provides some
+   mechanisms that can be used when the configuration information does
+   not specify if DRR can be used.  It summarizes some methods that can
+   be used by a peer to determine its own network location compared with
+   NAT.  These methods may help a peer to decide which routing mode it
+   may wish to try.  Note that there is no foolproof way to determine
+   whether a peer is publicly reachable, other than via out-of-band
+   mechanisms.  This document addresses UNilateral Self-Address Fixing
+   (UNSAF) [RFC3424] considerations by specifying a fallback plan to SRR
+   [RFC6940].  SRR is not an UNSAF mechanism.  This document does not
+   define any new UNSAF mechanisms.
+
+   For DRR to function correctly, a peer may attempt to determine
+   whether it is publicly reachable.  If it is not, the peer should fall
+   back to SRR.  If the peer believes it is publicly reachable, DRR may
+   be attempted.  NATs and firewalls are two major contributors to
+   preventing DRR from functioning properly.  There are a number of
+   techniques by which a peer can get its reflexive address on the
+   public side of the NAT.  After obtaining the reflexive address, a
+   peer can perform further tests to learn whether the reflexive address
+   is publicly reachable.  If the address appears to be publicly
+   reachable, the peer to which the address belongs can use DRR for
+   responses.
+
+   Some conditions that are unique in P2PSIP architecture could be
+   leveraged to facilitate the tests.  In a P2P overlay network, each
+   peer has only a partial view of the whole network and knows of a few
+   peers in the overlay.  P2P routing algorithms can easily deliver a
+   request from a sending peer to a peer with whom the sending peer has
+   no direct connection.  This makes it easy for a peer to ask other
+   peers to send unsolicited messages back to the requester.
+
+   In the following sections, we first introduce several ways for a peer
+   to get the addresses needed for further tests.  Then, a test for
+   learning whether a peer may be publicly reachable is proposed.
+
+A.1.  Getting Addresses to Be Used as Candidates for DRR
+
+   In order to test whether a peer may be publicly reachable, the peer
+   should first get one or more addresses that will be used by other
+   peers to send him messages directly.  This address is either a local
+   address of a peer or a translated address that is assigned by a NAT
+   to the peer.
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 15]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   Session Traversal Utilities for NAT (STUN) is used to get a reflexive
+   address on the public side of a NAT with the help of STUN servers.
+   NAT behavior discovery using STUN is specified in [RFC5780].  Under
+   the RELOAD architecture, a few infrastructure servers can be
+   leveraged for discovering NAT behavior, such as enrollment servers,
+   diagnostic servers, bootstrap servers, etc.
+
+   The peer can use a STUN Binding request to one of the STUN servers to
+   trigger a STUN Binding response, which returns the reflexive address
+   from the server's perspective.  If the reflexive transport address is
+   the same as the source address of the Binding request, the peer can
+   determine that there is likely no NAT between it and the chosen
+   infrastructure server.  (Certainly, in some rare cases, the allocated
+   address happens to be the same as the source address.  Further tests
+   will detect this case and rule it out in the end.)  Usually, these
+   infrastructure servers are publicly reachable in the overlay, so the
+   peer can be considered publicly reachable.  On the other hand, using
+   the techniques in [RFC5780], a peer can also decide whether it is
+   behind a NAT with endpoint-independent mapping behavior.  If the peer
+   is behind a NAT with endpoint-independent mapping behavior, the
+   reflexive address should also be a candidate for further tests.
+
+   The Universal Plug and Play Internet Gateway Device (UPnP-IGD) [IGD2]
+   is a mechanism that a peer can use to get the assigned address from
+   its residential gateway, and after obtaining this address to
+   communicate it with other peers, the peer can receive unsolicited
+   messages from outside, even though it is behind a NAT.  So, the
+   address obtained through the UPnP mechanism should also be used for
+   further tests.
+
+   Another way that a peer behind NAT can learn its assigned address by
+   NAT is via the NAT Port Mapping Protocol (NAT-PMP) [RFC6886].  As
+   with UPnP-IGD, the address obtained using this mechanism should also
+   be tested further.
+
+   The above techniques are not exhaustive.  These techniques can be
+   used to get candidate transport addresses for further tests.
+
+A.2.  Public Reachability Test
+
+   Using the transport addresses obtained by the above techniques, a
+   peer can start a test to learn whether the candidate transport
+   address is publicly reachable.  The basic idea of the test is that a
+   peer sends a request and expects another peer in the overlay to send
+   back a response.  If the response is successfully received by the
+   sending peer and the peer giving the response has no direct
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 16]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   connection with the sending peer, the sending peer can determine that
+   the address is probably publicly reachable and hence the peer may be
+   publicly reachable at the tested transport address.
+
+   In a P2P overlay, a request is routed through the overlay and finally
+   a destination peer will terminate the request and give the response.
+   In a large system, there is a high probability that the destination
+   peer has no direct connection with the sending peer.  Every peer
+   maintains a connection table, particularly in the RELOAD
+   architecture, so it is easier for a peer to see whether it has direct
+   connection with another peer.
+
+   If a peer wants to test whether its transport address is publicly
+   reachable, it can send a request to the overlay.  The routing for the
+   test message would be different from other kinds of requests because
+   it is not for storing or fetching something to or from the overlay,
+   or for locating a specific peer; instead, it is to get a peer who can
+   deliver to the sending peer an unsolicited response and who has no
+   direct connection with him.  Each intermediate peer receiving the
+   request first checks to see whether it has a direct connection with
+   the sending peer.  If there is a direct connection, the request is
+   routed to the next peer.  If there is no direct connection, the
+   intermediate peer terminates the request and sends the response back
+   directly to the sending peer with the transport address under test.
+
+   After performing the test, if the peer determines that it may be
+   publicly reachable, it can try DRR in subsequent transactions.
+
+Appendix B.  Comparison of Cost of SRR and DRR
+
+   The major advantage of using DRR is that it reduces the number of
+   intermediate peers traversed by the response.  This reduces the load,
+   such as processing and communication bandwidth, on those peers'
+   resources.
+
+B.1.  Closed or Managed Networks
+
+   As described in Section 3, many P2P systems run in a closed or
+   managed environment (e.g., carrier networks), so network
+   administrators would know that they could safely use DRR.
+
+   SRR uses more routing hops than DRR.  Assuming that there are N peers
+   in the P2P system and Chord [Chord] [wikiChord] is applied for
+   routing, the number of hops for a response in SRR and in DRR are
+   listed in the following table.  Establishing a secure connection
+   between the sending peer and the responding peer with Transport Layer
+   Security (TLS) or Datagram TLS (DTLS) requires multiple messages.
+   Note that establishing (D)TLS secure connections for a P2P overlay is
+
+
+
+Zong, et al.                 Standards Track                   [Page 17]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+   not optimal in some cases, e.g., DRR where (D)TLS is heavy for
+   temporary connections.  Therefore, in the following table we show the
+   cases of 1) no (D)TLS in DRR and 2) still using DTLS in DRR as
+   sub-optimal.  As the worst-cost case, seven (7) messages are used
+   during DTLS handshaking [DTLS].  (The TLS handshake is a negotiation
+   protocol that requires two (2) round trips, while the DTLS handshake
+   is a negotiation protocol that requires three (3) round trips.)
+
+            Mode       | Success | No. of Hops | No. of Msgs
+            ------------------------------------------------
+            SRR        |  Yes    |     log(N)  |    log(N)
+            DRR        |  Yes    |     1       |    1
+            DRR (DTLS) |  Yes    |     1       |    7+1
+
+         Table 1: Comparison of SRR and DRR in Closed Networks
+
+   From the above comparison, it is clear that:
+
+   1)  In most cases when the number of peers (N) > 2 (2^1), DRR uses
+       fewer hops than SRR.  Using a shorter route means less overhead
+       and resource usage on intermediate peers, which is an important
+       consideration for adopting DRR in the cases where such resources
+       as CPU and bandwidth are limited, e.g., the case of mobile,
+       wireless networks.
+
+   2)  In the cases when N > 256 (2^8), DRR also uses fewer messages
+       than SRR.
+
+   3)  In the cases when N < 256, DRR uses more messages than SRR (but
+       still uses fewer hops than SRR), so the consideration of whether
+       to use DRR or SRR depends on other factors such as using less
+       resources (bandwidth and processing) from the intermediate peers.
+       Section 4 provides use cases where DRR has a better chance of
+       working or where the considerations of intermediary resources are
+       important.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 18]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+B.2.  Open Networks
+
+   In open networks (e.g., the Internet) where DRR is not guaranteed to
+   work, DRR can fall back to SRR if it fails after trial, as described
+   in Section 4.  Based on the same settings as those listed in
+   Appendix B.1, the number of hops, as well as the number of messages
+   for a response in SRR and DRR, are listed in the following table:
+
+    Mode       |       Success           | No. of Hops | No. of Msgs
+    ----------------------------------------------------------------
+    SRR        |         Yes             |   log(N)    |   log(N)
+    DRR        |         Yes             |   1         |   1
+               | Fail & fall back to SRR |   1+log(N)  |   1+log(N)
+    DRR (DTLS) |         Yes             |   1         |   7+1
+               | Fail & fall back to SRR |   1+log(N)  |   8+log(N)
+
+          Table 2: Comparison of SRR and DRR in Open Networks
+
+   From the above comparison, it can be observed that trying to first
+   use DRR could still provide an overall number of hops lower than
+   directly using SRR.  Suppose that P peers are publicly reachable; the
+   number of hops in DRR and SRR is P*1+(N-P)*(1+logN) and N*logN,
+   respectively.  The condition for fewer hops in DRR is
+   P*1+(N-P)*(1+logN) < N*logN, which is P/N > 1/logN.  This means that
+   when the number of peers (N) grows, the required ratio of publicly
+   reachable peers P/N for fewer hops in DRR decreases.  Therefore, the
+   chance of trying DRR with fewer hops than SRR improves as the scale
+   of the network increases.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 19]
+
+RFC 7263                       P2PSIP DRR                      June 2014
+
+
+Authors' Addresses
+
+   Ning Zong
+   Huawei Technologies
+
+   EMail: zongning@huawei.com
+
+
+   Xingfeng Jiang
+   Huawei Technologies
+
+   EMail: jiang.x.f@huawei.com
+
+
+   Roni Even
+   Huawei Technologies
+
+   EMail: roni.even@mail01.huawei.com
+
+
+   Yunfei Zhang
+   CoolPad / China Mobile
+
+   EMail: hishigh@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zong, et al.                 Standards Track                   [Page 20]
+