draft-ietf-p2psip-rpr-03.txt   draft-ietf-p2psip-rpr-04.txt 
P2PSIP N. Zong, Ed. 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 25, 2013 Huawei Technologies Expires: August 21, 2013 Huawei Technologies
Y. Zhang Y. Zhang
China Mobile China Mobile
October 22, 2012 February 17, 2013
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-03 draft-ietf-p2psip-rpr-04
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 25, 2013. This Internet-Draft will expire on August 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
6. Extensions to RELOAD . . . . . . . . . . . . . . . . . . . . . 9 6. Extensions to RELOAD . . . . . . . . . . . . . . . . . . . . . 9
6.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 9 6.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 9
6.2. Modification To RELOAD Message Structure . . . . . . . . . 9 6.2. Modification To RELOAD Message Structure . . . . . . . . . 9
6.2.1. State-keeping Flag . . . . . . . . . . . . . . . . . . 10 6.2.1. State-keeping Flag . . . . . . . . . . . . . . . . . . 10
6.2.2. Extensive Routing Mode . . . . . . . . . . . . . . . . 10 6.2.2. Extensive Routing Mode . . . . . . . . . . . . . . . . 10
6.3. Creating a Request . . . . . . . . . . . . . . . . . . . . 10 6.3. Creating a Request . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Creating a request for RPR . . . . . . . . . . . . . . 10 6.3.1. Creating a request for RPR . . . . . . . . . . . . . . 10
6.4. Request And Response Processing . . . . . . . . . . . . . 11 6.4. Request And Response Processing . . . . . . . . . . . . . 11
6.4.1. Destination Peer: Receiving a Request And Sending 6.4.1. Destination Peer: Receiving a Request And Sending
a Response . . . . . . . . . . . . . . . . . . . . . . 11 a Response . . . . . . . . . . . . . . . . . . . . . . 11
6.4.2. Sending Peer: Receiving a Response . . . . . . . . . . 11 6.4.2. Sending Peer: Receiving a Response . . . . . . . . . . 12
6.4.3. Relay Peer Processing . . . . . . . . . . . . . . . . 12 6.4.3. Relay Peer Processing . . . . . . . . . . . . . . . . 12
7. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 12 7. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 12
8. Optional Methods to Investigate Peer Connectivity . . . . . . 12 8. Optional Methods to Investigate Peer Connectivity . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. Backgrounds 1.1. Backgrounds
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 D in [I-D.ietf- peer routing (RPR) are also discussed in Appendix D in [I-D.ietf-
p2psip-base]. DRR is specified in [I-D.ietf-p2psip-drr]. As we show p2psip-base]. As we show in section 3, RPR is advantageous over SRR
in section 3, RPR is advantageous over SRR in some scenarios reducing in some scenarios reducing load (CPU and link BW) on intermediary
load (CPU and link BW) on intermediary peers. RPR works better in a peers. RPR works better in a network where relay peers are
network where relay peers are provisioned in advance so that relay provisioned in advance so that relay peers are publicly reachable in
peers are publicly reachable in the P2P system. In other scenarios, the P2P system. In other scenarios, using a combination of RPR and
using a combination of RPR and SRR together is more likely to bring SRR together is more likely to bring benefits than if SRR is used
benefits than if SRR is used alone. Some discussion on connectivity alone. Some discussion on connectivity is in Non-Transitive
is in Non-Transitive Connectivity and DHTs Connectivity and DHTs [http://srhea.net/papers/ntr-worlds05.pdf].
[http://srhea.net/papers/ntr-worlds05.pdf].
Note that in this draft, we focus on RPR routing mode and its Note that in this draft, we focus on RPR routing mode and its
extensions to RELOAD. Some text such as modification to RELOAD extensions to RELOAD to produce a standalone solution. Please refer
message structure, optional methods to investigate peer connectivity to DRR draft [I-D.ietf-p2psip-drr] for DRR routing mode.
described in DRR draft [I-D.ietf-p2psip-drr] are also relevent to
RPR.
We first discuss the problem statement in Section 3, then how to We first discuss the problem statement in Section 3, then how to
combine RPR and SRR is presented in Section 4. In Section 5, we give combine RPR and SRR is presented in Section 4. In Section 5, we give
comparison on the cost of SRR and RPR in both managed and open comparison on the cost of SRR and RPR in both managed and open
networks. An extension to RELOAD to support RPR is proposed in networks. An extension to RELOAD to support RPR is proposed in
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 is introduced in Some optional methods to check peer connectivity is introduced in
Section 8. Section 8.
2. Terminology 2. Terminology
skipping to change at page 9, line 34 skipping to change at page 9, line 34
draft [I-D.ietf-p2psip-drr]. draft [I-D.ietf-p2psip-drr].
2) In the cases of large network and the success rate of RPR is good, 2) In the cases of large network and the success rate of RPR is good,
it is still possible that RPR has fewer messages than SRR. it is still possible that RPR has fewer messages than SRR.
Otherwise, the consideration to use RPR or SRR depends on other Otherwise, the consideration to use RPR or SRR depends on other
factors like using less resources from the intermediaries peers. factors like using less resources from the intermediaries peers.
6. Extensions to RELOAD 6. Extensions to RELOAD
Adding support for RPR requires extensions to the current RELOAD Adding support for RPR requires extensions to the current RELOAD
protocol. In this section and in DRR[I-D.ietf-p2psip-drr], we define protocol. In this section, we define the changes required to the
the changes required to the protocol, including changes to message protocol, including changes to message structure and to message
structure and to message processing. processing.
6.1. Basic Requirements 6.1. Basic Requirements
The basic requirements to peers for supporting RPR are same as DRR All peers implementing RPR MUST support SRR.
case. Please refer to DRR draft [I-D.ietf-p2psip-drr].
All peers MUST be able to process requests for routing in SRR, and
MAY support RPR routing requests.
6.2. Modification To RELOAD Message Structure 6.2. Modification To RELOAD Message Structure
RELOAD provides an extensible framework to accommodate future RELOAD provides an extensible framework to accommodate future
extensions. In this section and in DRR[I-D.ietf-p2psip-drr], we extensions. In this section, we define a ForwardingOption structure
define a ForwardingOption structure to support RPR mode. and present a state-keeping flag to support RPR mode.
6.2.1. State-keeping Flag 6.2.1. State-keeping Flag
The state-keeping flag to support RPR is same as DRR case. Please flag : 0x08 IGNORE-STATE-KEEPING
refer to DRR draft [I-D.ietf-p2psip-drr].
If IGNORE-STATE-KEEPING is set, any peer receiving this message and
which is not the destination of the message SHOULD forward the
message with the full via_list and SHOULD not maintain any internal
state.
6.2.2. Extensive Routing Mode 6.2.2. Extensive Routing Mode
The ForwardingOption structure to support RPR is same as DRR case. We first define a new type to define the new option,
Please refer to DRR draft [I-D.ietf-p2psip-drr]. The definition of extensive_routing_mode:
the fields is as follow:
The option value will be illustrated in the following figure,
defining the ExtensiveRoutingModeOption structure:
enum {(0),DRR(1),RPR(2),(255)} RouteMode;
struct {
RouteMode routemode;
OverlayLinkType transport;
IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption;
Note that DRR value in RouteMode is defined in DRR draft [I-D.ietf-
p2psip-drr].
RouteMode: 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.
[I-D.ietf-p2psip-drr]) and RPR are defined.
OverlayLinkType: refers to the transport type which is used to OverlayLinkType: refers to the transport type which is used to
deliver 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
skipping to change at page 13, line 28 skipping to change at page 13, line 48
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 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
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 in based draft[I-D.ietf-p2psip-base] which describes section 13.6 in based draft [I-D.ietf-p2psip-base] which describes
routing security. routing security.
10. IANA Considerations 10. IANA Considerations
No IANA action is needed. 10.1. A new RELOAD Forwarding Option
A new RELOAD Forwarding Option type is added to the Forwarding Option
Registry defined in [I-D.ietf-p2psip-base].
Type: 0x02 - extensive_routing_mode
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, Stephane Bryant and Marc Petit-Huguenin Lakshminath, Bruce Lowekamp, Stephane Bryant and Marc Petit-Huguenin
for their constructive comments. for their constructive comments.
12. References 12. References
skipping to change at page 14, line 4 skipping to change at page 14, line 23
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, Stephane Bryant and Marc Petit-Huguenin Lakshminath, Bruce Lowekamp, Stephane Bryant and Marc Petit-Huguenin
for their constructive comments. for their constructive comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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-22 (work in (RELOAD) Base Protocol", draft-ietf-p2psip-base-22 (work in
progress), July 2012. progress), July 2012.
[I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis,
D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
"An extension to RELOAD to support Direct Response Routing",
draft-ietf-p2psip-drr-03, October 2012.
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 5 skipping to change at page 15, line 15
[I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, "A [I-D.lowekamp-mmusic-ice-tcp-framework] Lowekamp, B. and A. Roach, "A
Proposal to Define Interactive Connectivity Establishment for the Proposal to Define Interactive Connectivity Establishment for the
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.
[I-D.ietf-p2psip-drr] Zong, N., Jiang, X., Even, R. and Zhang, Y.,
"An extension to RELOAD to support Direct Response Routing",
draft-ietf-p2psip-drr-04, February 2013.
[I-D.ietf-p2psip-concepts] Bryan, D., Matthews, P., Shim, E., Willis,
D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-04 (work in progress), October 2011.
Authors' Addresses Authors' Addresses
Ning Zong (editor) Ning Zong (editor)
Huawei Technologies Huawei Technologies
Email: zongning@huawei.com Email: zongning@huawei.com
Xingfeng Jiang Xingfeng Jiang
Huawei Technologies Huawei Technologies
 End of changes. 23 change blocks. 
51 lines changed or deleted 73 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/