draft-ietf-p2psip-rpr-07.txt   draft-ietf-p2psip-rpr-08.txt 
P2PSIP N. Zong P2PSIP N. Zong, Ed.
Internet-Draft X. Jiang Internet-Draft X. Jiang
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: December 11, 2013 Huawei Technologies Expires: January 16, 2014 Huawei Technologies
Y. Zhang Y. Zhang
CoolPad
June 09, 2013 July 15, 2013
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-07 draft-ietf-p2psip-rpr-08
Abstract Abstract
This document proposes an optional extension to RELOAD to support This document proposes an optional extension to RELOAD to support
relay peer routing mode. RELOAD recommends symmetric recursive relay peer routing mode. RELOAD recommends symmetric recursive
routing for routing messages. The new optional extension provides a routing for routing messages. The new optional extension provides a
shorter route for responses reducing the overhead on intermediate shorter route for responses reducing the overhead on intermediate
peers and describes the potential use cases where this extension can peers and describes the potential use cases where this extension can
be used. be used.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. RPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4 3.1.1. Relay Peer Routing (RPR) . . . . . . . . . . . . . . 4
3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5 3.2. Scenarios where RPR can be beneficial . . . . . . . . . . 5
3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5 3.2.1. Managed or closed P2P systems . . . . . . . . . . . . 5
3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 5 3.2.2. Using bootstrap nodes as relay peers . . . . . . . . 6
3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6 3.2.3. Wireless scenarios . . . . . . . . . . . . . . . . . 6
4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6 4. Relationship between SRR and RPR . . . . . . . . . . . . . . 6
4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6 4.1. How RPR works . . . . . . . . . . . . . . . . . . . . . . 6
4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6 4.2. How SRR and RPR work together . . . . . . . . . . . . . . 7
5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 6 5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7
5.1. Closed or managed networks . . . . . . . . . . . . . . . 7 5.1. Closed or managed networks . . . . . . . . . . . . . . . 7
5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Open networks . . . . . . . . . . . . . . . . . . . . . . 8
6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8 6. RPR extensions to RELOAD . . . . . . . . . . . . . . . . . . 8
6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8 6.1. Basic requirements . . . . . . . . . . . . . . . . . . . 8
6.2. Modification to RELOAD message structure . . . . . . . . 8 6.2. Modification to RELOAD message structure . . . . . . . . 8
6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 9
6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9
6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 10
6.3.1. Creating a request for RPR . . . . . . . . . . . . . 9 6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10
6.4. Request and response processing . . . . . . . . . . . . . 10 6.4. Request and response processing . . . . . . . . . . . . . 10
6.4.1. Destination peer: receiving a request and sending a 6.4.1. Destination peer: receiving a request and sending a
response . . . . . . . . . . . . . . . . . . . . . . 10 response . . . . . . . . . . . . . . . . . . . . . . 10
6.4.2. Sending peer: receiving a response . . . . . . . . . 11 6.4.2. Sending peer: receiving a response . . . . . . . . . 11
6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11 6.4.3. Relay peer processing . . . . . . . . . . . . . . . . 11
7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11 7. Overlay configuration extension . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Discovery of relay peers . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Optional methods to investigate peer connectivity . 13 Appendix A. Optional methods to investigate peer connectivity . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing RELOAD [I-D.ietf-p2psip-base] recommends symmetric recursive routing
(SRR) for routing messages and describes the extensions that would be (SRR) for routing messages and describes the extensions that would be
required to support additional routing algorithms. Other than SRR, required to support additional routing algorithms. Other than SRR,
two other routing options: direct response routing (DRR) and relay two other routing options: direct response routing (DRR) and relay
peer routing (RPR) are also discussed in Appendix A of [I-D.ietf- peer routing (RPR) are also discussed in Appendix A of [I-D.ietf-
p2psip-base]. As we show in section 3, RPR is advantageous over SRR p2psip-base]. As we show in section 3, RPR is advantageous over SRR
in some scenarios reducing load (CPU and link bandwidth) on in some scenarios reducing load (CPU and link bandwidth) on
intermediate peers. RPR works better in a network where relay peers intermediate peers. RPR works better in a network where relay peers
are provisioned in advance so that relay peers are publicly reachable are provisioned in advance so that relay peers are publicly reachable
in the P2P system. In other scenarios, using a combination of RPR in the P2P system. In other scenarios, using a combination of RPR
skipping to change at page 3, line 35 skipping to change at page 3, line 38
Section 6. Discovery of relay peers is introduced in Section 7. Section 6. Discovery of relay peers is introduced in Section 7.
Some optional methods to check peer connectivity are introduced in Some optional methods to check peer connectivity are introduced in
Appendix A. Appendix A.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
We use the terminology and definitions from the Concepts and We use the terminology and definitions from the RELOAD base draft
Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft [I-D.ietf-p2psip-base] extensively in this document. We also use
extensively in this document. We also use terms defined in NAT terms defined in NAT behavior discovery [RFC5780]. Other terms used
behavior discovery [RFC5780]. Other terms used in this document are in this document are defined inline when used and are also defined
defined inline when used and are also defined below for reference. below for reference.
Publicly Reachable: A peer is publicly reachable if it can receive Publicly Reachable: A peer is publicly reachable if it can receive
unsolicited messages from any other peer in the same overlay. unsolicited messages from any other peer in the same overlay.
Note: "publicly" does not mean that the peers must be on the Note: "publicly" does not mean that the peers must be on the
public Internet, because the RELOAD protocol may be used in a public Internet, because the RELOAD protocol may be used in a
closed system. closed system.
Relay Peer: A type of publicly reachable peer that can receive Relay Peer: A type of publicly reachable peer that can receive
unsolicited messages from all other peers in the overlay and unsolicited messages from all other peers in the overlay and
forward the responses from destination peers towards the sender of forward the responses from destination peers towards the sender of
skipping to change at page 6, line 42 skipping to change at page 7, line 10
peers comply with the same procedure as an ordinary peer to forward peers comply with the same procedure as an ordinary peer to forward
messages. The only difference is that there may be a larger traffic messages. The only difference is that there may be a larger traffic
burden on relay peers. Relay peers can decide whether to accept a burden on relay peers. Relay peers can decide whether to accept a
new connection based on their current burden. new connection based on their current burden.
4.2. How SRR and RPR work together 4.2. How SRR and RPR work together
RPR is not intended to replace SRR. It is better to use these two RPR is not intended to replace SRR. It is better to use these two
modes together to adapt to each peer's specific situation. Note that modes together to adapt to each peer's specific situation. Note that
the informative suggestions on how to transition between SRR and RPR the informative suggestions on how to transition between SRR and RPR
(e.g. compute success rate of RPR, fall back to SRR, etc) are the are the same with that of DRR. Please refer to DRR document [I-D
same with that of DRR. Please refer to DRR document [I-D.ietf- .ietf-p2psip-drr] for more details. If a relay peer is provided by
p2psip-drr] for more details. Similarly, the peer can decide whether the service provider, peers MAY prefer RPR over SRR. Otherwise,
to try RPR based on other information such as configuration file using RPR SHOULD be discouraged in the open Internet or if the
information. If a relay peer is provided by the service provider, administrator does not feel he have enough information about the
peers MAY prefer RPR over SRR. overlay. A new overlay configuration element specifying the usage of
DRR is defined in Section 7.
5. Comparison on cost of SRR and RPR 5. Comparison on cost of SRR and RPR
The major advantage of the use of RPR is that it reduces the number The major advantage of the use of RPR is that it reduces the number
of intermediate peers traversed by the response. By doing that, it of intermediate peers traversed by the response. By doing that, it
reduces the load on those peers' resources like processing and reduces the load on those peers' resources like processing and
communication bandwidth. communication bandwidth.
5.1. Closed or managed networks 5.1. Closed or managed networks
As described in Section 3, many P2P systems run in a closed or As described in Section 3, many P2P systems run in a closed or
managed environment (e.g. carrier networks) so that network managed environment (e.g. carrier networks) so that network
administrators would know that they could safely use RPR. administrators would know that they could safely use RPR.
skipping to change at page 11, line 31 skipping to change at page 12, line 5
that the destination_list is not the reverse of the via_list. that the destination_list is not the reverse of the via_list.
Instead, it is constructed from the forwarding option as described Instead, it is constructed from the forwarding option as described
below. below.
When a relay peer receives a response, it MUST follow the rules in When a relay peer receives a response, it MUST follow the rules in
[I-D.ietf-p2psip-base]. It receives the response, validates the [I-D.ietf-p2psip-base]. It receives the response, validates the
message, re-adjust the destination_list and forward the response to message, re-adjust the destination_list and forward the response to
the next hop in the destination_list based on the connection table. the next hop in the destination_list based on the connection table.
There is no added requirement for relay peer. There is no added requirement for relay peer.
7. Discovery of relay peers 7. Overlay configuration extension
This document uses the new RELOAD overlay configuration element,
"route-mode", inside each "configuration" element, as defined in DRR
document [I-D.ietf-p2psip-drr].
8. Discovery of relay peers
There are several ways to distribute the information about relay There are several ways to distribute the information about relay
peers throughout the overlay. P2P network providers can deploy some peers throughout the overlay. P2P network providers can deploy some
relay peers and advertise them in the configuration file. With the relay peers and advertise them in the configuration file. With the
configuration file at hand, peers can get relay peers to try RPR. configuration file at hand, peers can get relay peers to try RPR.
Another way is to consider relay peer as a service and then some Another way is to consider relay peer as a service and then some
service advertisement and discovery mechanism can also be used for service advertisement and discovery mechanism can also be used for
discovering relay peers, for example, using the same mechanism as discovering relay peers, for example, using the same mechanism as
used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base]. used in TURN server discovery in base RELOAD [I-D.ietf-p2psip-base].
Another option is to let a peer advertise his capability to be a Another option is to let a peer advertise his capability to be a
relay in the response to ATTACH or JOIN. relay in the response to ATTACH or JOIN.
8. Security Considerations 9. Security Considerations
As a routing alternative, the security part of RPR conforms to As a routing alternative, the security part of RPR conforms to
section 13.6 of the base draft [I-D.ietf-p2psip-base] which describes section 13.6 of the base draft [I-D.ietf-p2psip-base] which describes
routing security. RPR behave like a DRR requesting node towards the routing security. RPR behave like a DRR requesting node towards the
destination node. The RPR relay node is not an arbitrary node but destination node. The RPR relay node is not an arbitrary node but
SHOULD be a trusted one (managed network, bootstrap nodes or SHOULD be a trusted one (managed network, bootstrap nodes or
configured relay) which will make it less of a risk as outlined in configured relay) which will make it less of a risk as outlined in
section13 of the based draft. section13 of the based draft.
9. IANA Considerations 10. IANA Considerations
9.1. A new RELOAD Forwarding Option 10.1. A new RELOAD Forwarding Option
A new RELOAD Forwarding Option type is added to the Forwarding Option A new RELOAD Forwarding Option type is added to the Forwarding Option
Registry defined in [I-D.ietf-p2psip-base]. Registry defined in [I-D.ietf-p2psip-base].
Type: 0x02 - extensive_routing_mode Type: 0x02 - extensive_routing_mode
10. Acknowledgements 11. Acknowledgements
David Bryan has helped extensively with this document, and helped David Bryan has helped extensively with this document, and helped
provide some of the text, analysis, and ideas contained here. The provide some of the text, analysis, and ideas contained here. The
authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti authors would like to thank Ted Hardie, Narayanan Vidya, Dondeti
Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and Lakshminath, Bruce Lowekamp, Stephane Bryant, Marc Petit-Huguenin and
Carlos Jesus Bernardos Cano for their constructive comments. Carlos Jesus Bernardos Cano for their constructive comments.
11. References 12. References
12.1. Normative References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
[I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E.,
Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in (RELOAD) Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013. progress), February 2013.
11.2. Informative References 12.2. Informative References
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", RFC5780, May 2010. Using STUN", RFC5780, May 2010.
[I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y., [I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
"An extension to RELOAD to support Direct Response Routing", draft- "An extension to RELOAD to support Direct Response Routing", draft-
ietf-p2psip-drr-07, June 2013. ietf-p2psip-drr-07, June 2013.
[I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis, [I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis,
D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October 2011. draft-ietf-p2psip-concepts-04 (work in progress), October 2011.
12. References 13. References
Appendix A. Optional methods to investigate peer connectivity Appendix A. Optional methods to investigate peer connectivity
This section is for informational purposes only for providing some This section is for informational purposes only for providing some
mechanisms that can be used when the configuration information does mechanisms that can be used when the configuration information does
not specify if RPR can be used. It summarizes some methods which can not specify if RPR can be used. It summarizes some methods which can
be used for a peer to determine its own network location compared be used for a peer to determine its own network location compared
with NAT. These methods may help a peer to decide which routing mode 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 it may wish to try. Note that there is no foolproof way to determine
if a peer is publically reachable, other than via out-of-band if a peer is publically reachable, other than via out-of-band
skipping to change at page 14, line 4 skipping to change at page 14, line 22
request from a sending peer to a peer with whom the sending peer has 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 no direct connection. This makes it easy for a peer to ask other
peers to send unsolicited messages back to the requester. peers to send unsolicited messages back to the requester.
The approaches for a peer to get the addresses needed for the further The approaches for a peer to get the addresses needed for the further
tests, as well as the test for learning whether a peer may be tests, as well as the test for learning whether a peer may be
publicly reachable is same as the DRR case. Please refer to DRR publicly reachable is same as the DRR case. Please refer to DRR
document [I-D.ietf-p2psip-drr] for more details. document [I-D.ietf-p2psip-drr] for more details.
Authors' Addresses Authors' Addresses
Ning Zong
Ning Zong (editor)
Huawei Technologies Huawei Technologies
Email: zongning@huawei.com Email: zongning@huawei.com
Xingfeng Jiang Xingfeng Jiang
Huawei Technologies Huawei Technologies
Email: jiang.x.f@huawei.com Email: jiang.x.f@huawei.com
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Yunfei Zhang Yunfei Zhang
CoolPad
Email: hishigh@gmail.com Email: hishigh@gmail.com
 End of changes. 28 change blocks. 
47 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/