draft-ietf-p2psip-rpr-00.txt   draft-ietf-p2psip-rpr-01.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: April 10, 2012 Huawei Technologies Expires: June 2, 2012 Huawei Technologies
Y. Zhang Y. Zhang
China Mobile China Mobile
October 08, 2011 November 30, 2011
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-00 draft-ietf-p2psip-rpr-01
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 intermediary shorter route for responses reducing the overhead on intermediary
peers and describes the potential cases where this extension can be peers and describes the potential cases where this extension can be
used. 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 April 10, 2012. This Internet-Draft will expire on June 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 7, line 46 skipping to change at page 7, line 46
This can be done in the same way as establishing a neighbor This can be done in the same way as establishing a neighbor
connection between peers by using the Attach method. connection between peers by using the Attach method.
A requirement for RPR is for the source peer to convey their relay A requirement for RPR is for the source peer to convey their relay
peer (or peers) transport address in the request, so the destination peer (or peers) transport address in the request, so the destination
peer knows where the relay peer are and send the response to a relay peer knows where the relay peer are and send the response to a relay
peer first. The request should include also the requesting peer peer first. The request should include also the requesting peer
information enabling the relay peer to route the response back to the information enabling the relay peer to route the response back to the
right peer. right peer.
(Editor's Note: Being a relay peer does not require that the relay Note that being a relay peer does not require that the relay peer
peer have more functionality than an ordinary peer. As discussed have more functionality than an ordinary peer. As discussed later,
later, relay peers comply with the same procedure as an ordinary peer relay peers comply with the same procedure as an ordinary peer to
to forward messages. The only difference is that there may be a forward messages. The only difference is that there may be a larger
larger traffic burden on relay peers. Relay peers can decide whether traffic burden on relay peers. Relay peers can decide whether to
to accept a new connection based on their current burden.) accept a 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. As seen from Section 3, RPR has RPR is not intended to replace SRR. As seen from Section 3, RPR has
better performance in some scenarios, but have limitations as well, better performance in some scenarios, but have limitations as well,
see for example section 4.3 in Non-Transitive Connectivity and DHTs see for example section 4.3 in Non-Transitive Connectivity and DHTs
[http://srhea.net/papers/ntr-worlds05.pdf]. As a result, it is [http://srhea.net/papers/ntr-worlds05.pdf]. As a result, it is
better to use these two modes together to adapt to each peer's better to use these two modes together to adapt to each peer's
specific situation. Note that the informative suggestions on how to specific situation. Note that the informative suggestions on how to
transition between SRR and RPR (e.g. compute success rate of RPR, transition between SRR and RPR (e.g. compute success rate of RPR,
skipping to change at page 10, line 22 skipping to change at page 10, line 22
The state-keeping flag to support RPR is same as DRR case. Please The state-keeping flag to support RPR is same as DRR case. Please
refer to DRR draft [I-D.ietf-p2psip-drr]. refer to DRR draft [I-D.ietf-p2psip-drr].
6.2.2. Extensive Routing Mode 6.2.2. Extensive Routing Mode
The ForwardingOption structure to support RPR is same as DRR case. The ForwardingOption structure to support RPR is same as DRR case.
Please refer to DRR draft [I-D.ietf-p2psip-drr]. The definition of Please refer to DRR draft [I-D.ietf-p2psip-drr]. The definition of
the fields is as follow: the fields is as follow:
Route mode: refers to which type of routing mode is indicated to the RouteMode: refers to which type of routing mode is indicated to the
destination peer. Currently, only DRR (specified in DRR draft destination peer. Currently, only DRR (specified in DRR draft
[I-D.ietf-p2psip-drr]) and RPR are defined. [I-D.ietf-p2psip-drr]) and RPR are defined.
Transport: refers to the transport type which is used to deliver OverlayLinkType: refers to the transport type which is used to
responses from the destination peer to the relay peer. deliver responses from the destination peer to the relay peer.
IpAddressPort: refers to the transport address that the destination IpAddressPort: refers to the transport address that the destination
peer should use to send the response to. This will be a relay peer peer should use to send the response to. This will be a relay peer
address for RPR. address for RPR.
Destination: refers to the relay peer itself. If the routing mode is Destination: refers to the relay peer itself. If the routing mode is
RPR, then the destination contains two destinations, which are the RPR, then the destination contains two destinations, which are the
relay peer's node-id and the sending node's node-id. relay peer's node-id and the sending node's node-id.
6.3. Creating a Request 6.3. Creating a Request
6.3.1. Creating a request for RPR 6.3.1. Creating a request for RPR
When using RPR for a transaction, the sending peer MUST set the When using RPR for a transaction, the sending peer MUST set the
IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the IGNORE-STATE-KEEPING flag in the ForwardingHeader. Additionally, the
peer MUST construct and include a ForwardingOptions structure in the peer MUST construct and include a ForwardingOptions structure in the
ForwardingHeader. When constructing the ForwardingOption structure, ForwardingHeader. When constructing the ForwardingOption structure,
the fields MUST be set as follows: the fields MUST be set as follows:
1) The type MUST be set to EXTENSIVE_ROUTING_MODE_TYPE. 1) The type MUST be set to extensive_routing_mode.
2) The ExtensiveRoutingModeOption structure MUST be used for the 2) The ExtensiveRoutingModeOption structure MUST be used for the
option field within the ForwardingOptions structure. The fields MUST option field within the ForwardingOptions structure. The fields MUST
be defined as follows: be defined as follows:
2.1) RouteMode set to 0x02 (RPR). 2.1) routemode set to 0x02 (RPR).
2.2) Transport set as appropriate for the relay peer. 2.2) transport set as appropriate for the relay peer.
2.3) IPAddressPort set to the transport address of the relay peer 2.3) ipaddressport set to the transport address of the relay peer
that the sender wishes the message to be relayed through. that the sender wishes the message to be relayed through.
2.4) Destination structure MUST contain two values. The first MUST 2.4) destination structure MUST contain two values. The first MUST
be defined as type peer and set with the values for the relay peer. be defined as type peer and set with the values for the relay peer.
The second MUST be defined as type peer and set with the sending The second MUST be defined as type peer and set with the sending
peer's own values. peer's own values.
6.4. Request And Response Processing 6.4. Request And Response Processing
This section gives normative text for message processing after RPR is This section gives normative text for message processing after RPR is
introduced. Here, we only describe the additional procedures for introduced. Here, we only describe the additional procedures for
supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD supporting RPR. Please refer to [I-D.ietf-p2psip-base] for RELOAD
base procedures. base procedures.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
request. request.
In the event that the routing mode is set to RPR and there are not In the event that the routing mode is set to RPR and there are not
exactly two destinations the destination peer MUST try to send an exactly two destinations the destination peer MUST try to send an
"Error_Unknown_Extension" response (defined in Section 5.3.3.1 and "Error_Unknown_Extension" response (defined in Section 5.3.3.1 and
Section 13.9 in [I-D.ietf-p2psip-base]) to the sending peer using Section 13.9 in [I-D.ietf-p2psip-base]) to the sending peer using
SRR. SRR.
After the peer constructs the destination list for the response, it After the peer constructs the destination list for the response, it
sends the response to the transport address which is indicated in the sends the response to the transport address which is indicated in the
IpAddressPort field in the option using the specific transport mode ipaddressport field in the option using the specific transport mode
in the Forwardingoption. If the destination peer receives a in the Forwardingoption. If the destination peer receives a
retransmit with SRR preference on the message it is trying to retransmit with SRR preference on the message it is trying to
response to now, the responding peer should abort the RPR response response to now, the responding peer should abort the RPR response
and use SRR. and use SRR.
6.4.2. Sending Peer: Receiving a Response 6.4.2. Sending Peer: Receiving a Response
Upon receiving a response, the peer follows the rules in [I-D.ietf- Upon receiving a response, the peer follows the rules in [I-D.ietf-
p2psip-base]. If the sender used RPR and does not get a response p2psip-base]. If the sender used RPR and does not get a response
until the timeout, it MAY either resend the message using RPR but until the timeout, it MAY either resend the message using RPR but
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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.
Editor note: This section will be extended if we adopt RPR, but like
other configuration information, there may be many ways to obtain
this.
8. Optional Methods to Investigate Node Connectivity 8. Optional Methods to Investigate Node 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 node to determine its own network location compared be used for a node to determine its own network location compared
with NAT. These methods may help a node to decide which routing mode with NAT. These methods may help a node 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 node is publically reachable, other than via out- of-band if a node is publically reachable, other than via out- of-band
mechanisms. As such, peers using these mechanisms may be able to mechanisms. As such, peers using these mechanisms may be able to
skipping to change at page 13, line 39 skipping to change at page 13, line 35
no direct connection. This makes it easy for a node to ask other no direct connection. This makes it easy for a node to ask other
nodes to send unsolicited messages back to the requester. nodes to send unsolicited messages back to the requester.
The approaches for a node to get the addresses needed for the further The approaches for a node 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 reacheable is same as the DRR case. Please refer to DRR publicly reacheable is same as the DRR case. Please refer to DRR
draft [I-D.ietf-p2psip-drr] for more details. draft [I-D.ietf-p2psip-drr] for more details.
9. Security Considerations 9. Security Considerations
TBD As a routing alternative, the security part of RPR conforms to
section 12.6 in based draft[I-D.ietf-p2psip-base] which describes
routing security.
10. IANA Considerations 10. IANA Considerations
No IANA action is needed. No IANA action is needed.
11. 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 and Stephane Bryant for their Lakshminath, Bruce Lowekamp, Stephane Bryant and Marc Petit-Huguenin
constructive comments. for their constructive comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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-18 (work in (RELOAD) Base Protocol", draft-ietf-p2psip-base-19 (work in
progress), August 2011. progress), October 2011.
[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-03 (work in progress), October 2010. draft-ietf-p2psip-concepts-03 (work in progress), October 2010.
[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, RFC 2119, March 1997.
[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", "An extension to RELOAD to support Direct Response Routing",
draft-ietf-p2psip-drr-00, October 2011. draft-ietf-p2psip-drr-01, November 2011.
12.2. Informative References 12.2. Informative References
[ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the [ChurnDHT] Rhea, S., "Handling Churn in a DHT", Proceedings of the
USENIX Annual Technical Conference. Handling Churn in a DHT, June USENIX Annual Technical Conference. Handling Churn in a DHT, June
2004. 2004.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of
Datagram TLS", 11th Network and Distributed System Security Symposium Datagram TLS", 11th Network and Distributed System Security Symposium
(NDSS), 2004. (NDSS), 2004.
skipping to change at page 15, line 12 skipping to change at page 15, line 11
Transport Control Protocol (ICE-TCP) as an Extensible Framework", Transport Control Protocol (ICE-TCP) as an Extensible Framework",
draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress), draft-lowekamp-mmusic-ice-tcp-framework-00 (work in progress),
October 2008. October 2008.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
January 2007. January 2007.
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
 End of changes. 20 change blocks. 
31 lines changed or deleted 29 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/