draft-ietf-p2psip-rpr-05.txt   draft-ietf-p2psip-rpr-06.txt 
P2PSIP N. Zong P2PSIP N. Zong
Internet-Draft X. Jiang Internet-Draft X. Jiang
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: October 10, 2013 Huawei Technologies Expires: November 08, 2013 Huawei Technologies
Y. Zhang Y. Zhang
April 08, 2013 May 07, 2013
An extension to RELOAD to support Relay Peer Routing An extension to RELOAD to support Relay Peer Routing
draft-ietf-p2psip-rpr-05 draft-ietf-p2psip-rpr-06
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 37 skipping to change at page 1, line 37
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 October 10, 2013. This Internet-Draft will expire on November 08, 2013.
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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Backgrounds . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 6 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 . . . . . . . . . . . . . . 7 4.2. How SRR and RPR work together . . . . . . . . . . . . . . 6
5. Comparison on cost of SRR and RPR . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . 9 6.2. Modification to RELOAD message structure . . . . . . . . 8
6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 9 6.2.1. State-keeping flag . . . . . . . . . . . . . . . . . 8
6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9 6.2.2. Extensive routing mode . . . . . . . . . . . . . . . 9
6.3. Creating a request . . . . . . . . . . . . . . . . . . . 10 6.3. Creating a request . . . . . . . . . . . . . . . . . . . 9
6.3.1. Creating a request for RPR . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 12 7. Discovery of relay peers . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12 9.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Optional methods to investigate peer connectivity . 13 Appendix A. Optional methods to investigate peer connectivity . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
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 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
and SRR together is more likely to bring benefits than if SRR is used and SRR together is more likely to bring benefits than if SRR is used
alone. alone.
Note that in this document, we focus on RPR routing mode and its Note that in this document, we focus on RPR routing mode and its
extensions to RELOAD to produce a standalone solution. Please refer extensions to RELOAD to produce a standalone solution. Please refer
to DRR draft [I-D.ietf-p2psip-drr] for DRR routing mode. to DRR document [I-D.ietf-p2psip-drr] for DRR routing mode.
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 are introduced in Some optional methods to check peer connectivity are introduced in
Appendix A. Appendix A.
2. Terminology 2. Terminology
skipping to change at page 4, line 29 skipping to change at page 4, line 27
responses to P2PSIP requests are sent by the destination peer to a responses to P2PSIP requests are sent by the destination peer to a
relay peer transport address who will forward the responses relay peer transport address who will forward the responses
towards the sending peer. For simplicity, the abbreviation RPR is towards the sending peer. For simplicity, the abbreviation RPR is
used instead in the rest of the document. used instead in the rest of the document.
Symmetric Recursive Routing (SRR): refers to a routing mode in Symmetric Recursive Routing (SRR): refers to a routing mode in
which responses follow the reverse path of the request to get to which responses follow the reverse path of the request to get to
the sending peer. For simplicity, the abbreviation SRR is used the sending peer. For simplicity, the abbreviation SRR is used
instead in the rest of the document. instead in the rest of the document.
3. Introduction 3. Overview
RELOAD is expected to work under a great number of application RELOAD is expected to work under a great number of application
scenarios. The situations where RELOAD is to be deployed differ scenarios. The situations where RELOAD is to be deployed differ
greatly. For instance, some deployments are global, such as a Skype- greatly. For instance, some deployments are global, such as a Skype-
like system intended to provide public service, while others run in like system intended to provide public service, while others run in
closed networks of small scale. SRR works in any situation, but RPR closed networks of small scale. SRR works in any situation, but RPR
may work better in some specific scenarios. may work better in some specific scenarios.
3.1. Overview 3.1. RPR
RELOAD is a simple request-response protocol. After sending a RELOAD is a simple request-response protocol. After sending a
request, a peer waits for a response from a destination peer. There 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 are several ways for the destination peer to send a response back to
the source peer. In this section, we will provide detailed the source peer. In this section, we will provide detailed
information on RPR. information on RPR.
Note that the same illustrative settings can be found in DRR draft Note that the same illustrative settings can be found in DRR document
[I-D.ietf-p2psip-drr]. [I-D.ietf-p2psip-drr].
3.1.1. Relay Peer Routing (RPR) 3.1.1. Relay Peer Routing (RPR)
If peer A knows it is behind a NAT or NATs, and knows one or more If peer A knows it is behind a NAT or NATs, and knows one or more
relay peers with whom they have a prior connections, peer A can try relay peers with whom they have a prior connections, peer A can try
RPR. Assume A is associated with relay peer R. When sending the RPR. Assume A is associated with relay peer R. When sending the
request, peer A includes information describing peer R transport request, peer A includes information describing peer R transport
address in the request. When peer X receives the request, peer X address in the request. When peer X receives the request, peer X
sends the response to peer R, which forwards it directly to Peer A on sends the response to peer R, which forwards it directly to Peer A on
the existing connection. Figure 1 illustrates RPR. Note that RPR the existing connection. Figure 1 illustrates RPR. Note that RPR
also allows a shorter route for responses compared to SRR, which also allows a shorter route for responses compared to SRR, which
means less overhead on intermediate peers. Establishing a connection means less overhead on intermediate peers. Establishing a connection
to the relay with TLS requires multiple round trips. Please refer to to the relay with TLS requires multiple round trips. Please refer to
skipping to change at page 5, line 31 skipping to change at page 5, line 27
| | | Request | | | | | | Request | | |
| | |----------->| | | | | |----------->| | |
| | | | Request | | | | | | Request | |
| | | |----------->| | | | | |----------->| |
| | | | | Response | | | | | | Response |
| | | | |---------->| | | | | |---------->|
| | | | Response | | | | | | Response | |
|<-----------+------------+------------+------------+-----------| |<-----------+------------+------------+------------+-----------|
| | | | | | | | | | | |
Figure 1, RPR Figure 1. RPR routing mode
This technique relies on the relative population of peers such as A This technique relies on the relative population of peers such as A
that require relay peers, and peers such as R that are capable of that require relay peers, and peers such as R that are capable of
serving as a relay peers. It also requires a mechanism to enable serving as a relay peers. It also requires a mechanism to enable
peers to know which peers can be used as their relays. This peers to know which peers can be used as their relays. This
mechanism may be based on configuration, for example as part of the mechanism may be based on configuration, for example as part of the
overlay configuration an initial list of relay peers can be supplied. overlay configuration an initial list of relay peers can be supplied.
Another option is in a response message, the responding peer can Another option is in a response message, the responding peer can
announce that it can serve as a relay peer. announce that it can serve as a relay peer.
skipping to change at page 6, line 20 skipping to change at page 6, line 16
Another usage is to install relay peers on the managed network Another usage is to install relay peers on the managed network
boundary allowing external peers to send responses to peers inside boundary allowing external peers to send responses to peers inside
the managed network. the managed network.
3.2.2. Using bootstrap nodes as relay peers 3.2.2. Using bootstrap nodes as relay peers
Bootstrap nodes are typically publicly reachable in a RELOAD Bootstrap nodes are typically publicly reachable in a RELOAD
architecture. As a result, one possible architecture would be to use architecture. As a result, one possible architecture would be to use
the bootstrap nodes as relay peers for use with RPR. A relay peer the bootstrap nodes as relay peers for use with RPR. A relay peer
SHOULD be publicly accessible and maintaining a direct connection SHOULD be publicly accessible and maintain a direct connection with
with its client. As such, bootstrap nodes are well suited to play its client. As such, bootstrap nodes are well suited to play the
the role of relay peers. role of relay peers.
3.2.3. Wireless scenarios 3.2.3. Wireless scenarios
In some mobile deployments, using RPR may help reducing radio battery In some mobile deployments, using RPR may help reducing radio battery
usage and bandwidth by the intermediate peers. The service provider usage and bandwidth by the intermediate peers. The service provider
may recommend using RPR based on his knowledge of the topology. may recommend using RPR based on his knowledge of the topology.
4. Relationship between SRR and RPR 4. Relationship between SRR and RPR
4.1. How RPR works 4.1. How RPR works
skipping to change at page 7, line 5 skipping to change at page 6, line 48
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.
Note that being a relay peer does not require that the relay peer has Note that being a relay peer does not require that the relay peer has
more functionality than an ordinary peer. As discussed later, relay more functionality than an ordinary peer. As discussed later, relay
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 (e.g. compute success rate of RPR, fall back to SRR, etc) are the
same with that of DRR. Please refer to DRR draft [I-D.ietf-p2psip- same with that of DRR. Please refer to DRR document [I-D.ietf-
drr] for more details. Similarly, the peer can decide whether to try p2psip-drr] for more details. Similarly, the peer can decide whether
RPR based on other information such as configuration file to try RPR based on other information such as configuration file
information. If a relay peer is provided by the service provider, information. If a relay peer is provided by the service provider,
peers MAY prefer RPR over SRR. peers MAY prefer RPR over SRR.
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.
The number of hops for a response in SRR and RPR are listed in the The number of hops for a response in SRR and RPR are listed in the
following table. Note that the same illustrative settings can be following table. Note that the same illustrative settings can be
found in DRR draft [I-D.ietf-p2psip-drr]. found in DRR document [I-D.ietf-p2psip-drr].
Mode | Success | No. of Hops | No. of Msgs Mode | Success | No. of Hops | No. of Msgs
---------------------------------------------------- ----------------------------------------------------
SRR | Yes | log(N) | log(N) SRR | Yes | log(N) | log(N)
RPR | Yes | 2 | 2 RPR | Yes | 2 | 2
RPR(DTLS) | Yes | 2 | 7+2 RPR(DTLS) | Yes | 2 | 7+2
Table 1, comparison of SRR and RPR in closed networks Table 1. Comparison of SRR and RPR in closed networks
From the above comparison, it is clear that: From the above comparison, it is clear that:
1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR. 1) In most cases when N > 4 (2^2), RPR uses fewer hops than SRR.
Using a shorter route means less overhead and resource usage on Using a shorter route means less overhead and resource usage on
intermediate peers, which is an important consideration for adopting intermediate peers, which is an important consideration for adopting
RPR in the cases where the resources such as CPU and bandwidth are RPR in the cases where the resources such as CPU and bandwidth are
limited, e.g. the case of mobile, wireless networks. limited, e.g. the case of mobile, wireless networks.
2) In the cases when N > 512 (2^9), RPR also uses fewer messages than 2) In the cases when N > 512 (2^9), RPR also uses fewer messages than
skipping to change at page 8, line 16 skipping to change at page 8, line 12
still uses fewer hops than SRR). So the consideration on whether still uses fewer hops than SRR). So the consideration on whether
using RPR or SRR depends on other factors like using less resources using RPR or SRR depends on other factors like using less resources
(bandwidth and processing) from the intermediate peers. Section 4 (bandwidth and processing) from the intermediate peers. Section 4
provides use cases where RPR has better chance to work or where the provides use cases where RPR has better chance to work or where the
intermediary resources considerations are important. intermediary resources considerations are important.
5.2. Open networks 5.2. Open networks
In open networks where RPR is not guaranteed to work, RPR can fall In open networks where RPR is not guaranteed to work, RPR can fall
back to SRR if it fails after trial, as described in Section 4. back to SRR if it fails after trial, as described in Section 4.
Based on the same settings in Section 5.1, the number of hops, number Based on the same settings of Section 5.1, the number of hops, number
of messages for a response in SRR and RPR are listed in the following of messages for a response in SRR and RPR are listed in the following
table. table.
Mode | Success | No. of Hops | No. of Msgs Mode | Success | No. of Hops | No. of Msgs
----------------------------------------------------------- -----------------------------------------------------------
SRR | Yes | logN | logN SRR | Yes | log(N) | log(N)
RPR | Yes | 2 | 2 RPR | Yes | 2 | 2
| Fail&Fall back to SRR | 2+logN | 2+logN | Fail&Fall back to SRR | 2+log(N)| 2+log(N)
RPR(DTLS) | Yes | 2 | 7+2 RPR(DTLS) | Yes | 2 | 7+2
| Fail&Fall back to SRR | 2+logN | 9+logN | Fail&Fall back to SRR | 2+log(N)| 9+log(N)
Table 2, comparison of SRR and RPR in open networks Table 2. Comparison of SRR and RPR in open networks
From the above comparison, it can be observed that trying to first From the above comparison, it can be observed that trying to first
use RPR could still provide an overall number of hops lower than use RPR could still provide an overall number of hops lower than
directly using SRR. The detailed analysis is same as DRR case and directly using SRR. The detailed analysis is same as DRR case and
can be found in DRR draft [I-D.ietf-p2psip-drr]. can be found in DRR document [I-D.ietf-p2psip-drr].
6. RPR extensions to RELOAD 6. RPR 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, we define the extensions required to the protocol. In this section, we define the extensions required to the
protocol, including extensions to message structure and to message protocol, including extensions to message structure and to message
processing. processing.
6.1. Basic requirements 6.1. Basic requirements
skipping to change at page 9, line 36 skipping to change at page 9, line 27
ExtensiveRoutingModeOption structure: ExtensiveRoutingModeOption structure:
enum {(0),DRR(1),RPR(2),(255)} RouteMode; enum {(0),DRR(1),RPR(2),(255)} RouteMode;
struct { struct {
RouteMode routemode; RouteMode routemode;
OverlayLinkType transport; OverlayLinkType transport;
IpAddressPort ipaddressport; IpAddressPort ipaddressport;
Destination destinations<1..2^8-1>; Destination destinations<1..2^8-1>;
} ExtensiveRoutingModeOption; } ExtensiveRoutingModeOption;
Note that DRR value in RouteMode is defined in DRR draft [I-D.ietf- Note that DRR value in RouteMode is defined in DRR document [I-D
p2psip-drr]. .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. destination peer.
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.
skipping to change at page 14, line 36 skipping to change at page 14, line 36
leveraged to facilitate the tests. In P2P overlay network, each peer leveraged to facilitate the tests. In P2P overlay network, each peer
only has partial a view of the whole network, and knows of a few only has partial a view of the whole network, and knows of a few
peers in the overlay. P2P routing algorithms can easily deliver a 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 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
draft [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
Huawei Technologies Huawei Technologies
Email: zongning@huawei.com Email: zongning@huawei.com
Xingfeng Jiang Xingfeng Jiang
Huawei Technologies Huawei Technologies
 End of changes. 30 change blocks. 
37 lines changed or deleted 35 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/