P2PSIP X. Jiang
Internet-Draft Huawei Tech.
Intended status: Standards Track R. Even
Expires: June 30, 2009 Gesher Erove
December 27, 2008
An extension to RELOAD to support Direct Response and Relay Peer routing
draft-jiang-p2psip-relay-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 30, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document proposes an extension to RELOAD to support direct
Jiang & Even Expires June 30, 2009 [Page 1]
Internet-Draft P2PSIP RELAY December 2008
response and relay peer routing modes. The document starts with the
problem statement and addresses concerns about these two routing
modes mentioned in RELOAD. Then methods about how to detect whether
a node is publicly reachable in P2PSIP situations are discussed. The
last part proposes extensions to RELOAD for supporting these
additional routing modes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Symmetric Route Stability . . . . . . . . . . . . . . . . 4
3.2. Application Scenarios . . . . . . . . . . . . . . . . . . 5
3.3. Advantages from DRR and RPR . . . . . . . . . . . . . . . 5
4. Concerns From RELOAD . . . . . . . . . . . . . . . . . . . . . 6
4.1. Concerns About DRR . . . . . . . . . . . . . . . . . . . . 6
4.2. Concerns About RPR . . . . . . . . . . . . . . . . . . . . 6
5. Detrming If Node Is Publicly Reachable? . . . . . . . . . . . 7
5.1. Getting Addresses To Be Used As Candidates for DRR . . . . 7
5.2. Test On Being Publicly Reachable Or Not . . . . . . . . . 8
6. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 9
7. Relationship Between SRR And DRR/RPR . . . . . . . . . . . . . 9
8. Extensions To RELOAD . . . . . . . . . . . . . . . . . . . . . 10
8.1. Steps For Running DRR/RPR . . . . . . . . . . . . . . . . 10
8.1.1. Procedure For Running DRR . . . . . . . . . . . . . . 10
8.1.2. Procedure For Running RPR . . . . . . . . . . . . . . 11
8.2. Modification To RELOAD Message Structure . . . . . . . . . 11
8.3. Request And Response Processing . . . . . . . . . . . . . 13
8.3.1. Sending Peer: Sending Reqeust And Receiving
Response . . . . . . . . . . . . . . . . . . . . . . . 13
8.3.2. Destination Peer: Receiving Request And Sending
Response . . . . . . . . . . . . . . . . . . . . . . . 13
8.3.3. What Relay Peer Does? . . . . . . . . . . . . . . . . 14
9. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11.1. A new RELOAD Forwarding Option . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Jiang & Even Expires June 30, 2009 [Page 2]
Internet-Draft P2PSIP RELAY December 2008
1. Introduction
RELOAD [I-D.ietf-p2psip-base]recommends symmetric recursive routing
for routing messages and describes the extensions that would be
required to support additional routing algorithms. This document
proposes an extension to RELOAD to support two additional routing
options: direct response and relay peer which are also discussed in
Appendix B in [I-D.ietf-p2psip-base]. However, symmetric recursive
routing will not work well in some cases. For example, overlay churn
makes the reverse path of the request unstable, therefore fails the
transaction. In these cases, direct response or relay peer would be
helpful to improve the reliability and efficiency of the P2PSIP
transaction. So it is useful to make these three modes work together
to provide better service to the upper layer applications on top of
the P2PSIP overlay. We analyze the problem statement first and try
to address the concerns in RELOAD about these two routing options.
Then, some methods are presented to show that it is feasible for a
peer to learn whether it is publicly reachable under RELOAD
architecture. In section 7 the document discusses the methods to
make direct response and relay peer routing mode work together with
symmetric routing mode. In the end, an extension to base RELOAD is
proposed to make them work.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
We use the terminology and definitions from the Concepts and
Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] draft
extensively in this document. We also use terms defined in NAT
behavior discovery [I-D.ietf-behave-nat-behavior-discovery]. Other
terms used in this document are defined inline when used and are also
defined below for reference.
There are two types of roles in RELOAD architecture, peer and client.
Node is used when describing both peer and client. In specific
descriptions to peer or client, peer or client is used instead.
o Direct Response Routing (DRR): refers to a routing mode in which
responses to P2PSIP requests are returned to the sending peer
directly from the destination peer based on the sending node's own
local transport addresses. For simplicity, the abbreviation DRR
is used instead in the following text.
Jiang & Even Expires June 30, 2009 [Page 3]
Internet-Draft P2PSIP RELAY December 2008
o Relay Peer Routing (RPR): refers to a routing mode in which
responses to P2PSIP requests are sent by the destination peer to a
relay peer who will forward the responses towards the sending
node. For simplicity, the abbreviation RPR is used instead in the
following text.
o Symmetric Recursive Routing(SRR): refers to a routing mode in
which responses follow the same request path in the reverse order
to get back to the sending node. For simplicity, the SRR is used
instead in the following text.
o publicly reachable: A node is publicly reachable if it can receive
unsolicited messages from any other node in the same overlay.
Note: "publicly" does not mean that the nodes MUST be on the
public Internet, because RELOAD protocol may be used in a closed
system.
o relay peer: a type of publicly reachable peers that can receive
unsolicited messages from all other nodes in the overlay and
forward the responses from destination peers towards the request
sender.
3. Problem Statement
P2PSIP WG intends to make RELOAD work under a number of application
scenarios. In reality, the situations where RELOAD is to be deployed
differ greatly. For instance, some systems run in an overlay
composed of only ten to hundred stable and powerful nodes. On the
other hand, overlays may experience heavy churn or comprise of over 1
million nodes. It is obvious that SRR currently adopted in RELOAD
works well in the former case. But for the latter case, SRR may not
work well.
3.1. Symmetric Route Stability
As discussed in Appendix B.5 in RELAOD [I-D.ietf-p2psip-base], one
concern for the motivation to add DRR and RPR is, if there is a heavy
churn in overlay, requests fail first. That is, transactions failed
before requests reach the destination peer. In this case, DRR and
RPR won't bring any benefit since the transactions in that these two
routing modes are used to avoid the churn influence on the response
path. RELOAD mentions that retries of the failed requests will
reduce the influence of churn. By using optional DRR and RPR the
probability of failure due to churn can also be reduced.
In some literatures, for example [ChurnDHT], one way to handle churn
in DHT is to get a more accurate timeout value between neighbors.
When the timeout fires, the preferred way for the upstream peer to
handle the failure is to try the request through another downstream
peer, for there are a number of paths between a sending node and a
Jiang & Even Expires June 30, 2009 [Page 4]
Internet-Draft P2PSIP RELAY December 2008
destination peer. Therefore, the probability for a request to reach
the destination peer successfully under churn will improve greatly.
This still leave open the issue of the response failure due to churn.
Through the above analysis, we can see that churn in request path
could be solved to great extent by using existing mechanisms. DRR
and RPR routing mode are still helpful for the responses to be
resilient to the churn.
3.2. Application Scenarios
Overlay churn causes nodes or connections between neighbor nodes to
be unstable. If SRR is used for routing responses, any failure of
nodes or connections in the reverse path will fail the whole P2PSIP
transaction. So a transaction with longer response latency will be
vulnerable to churn. Below are two examples of overlays which
produce slow response.
o P2P technology has been applied successfully in some global public
VoIP services, such as Skype. The number of the simultaneous
online users for this type of system is often over 1 million. For
a typical overlay network, the lookup operation in P2P systems
will end up with the hop counts within [0, log(N)]. Here, N is
the number of nodes in the system. For a system where N is over 1
million, the maximum hop counts would be about 20. For such a
long path, the churn of the overlay will break the reverse path
with high probability, for the failure of any node in the path
would mean the failure of the reverse path, hence the failure of
the transaction.
o If links of the overlay network are wireless link or some low
speed links, the latency between links would be significantly
long. So messages will take longer to traverse the path back and
forth and the nodes in the path are more easily subject to failure
during the message transportation duration because of churn.
3.3. Advantages from DRR and RPR
DRR and RPR try to shorten the response path to a fixed number of
hops and thus reducing the response time. If DRR is used, the
response path is only 1 hop; In the case of RPR, the response path is
2 hops. According to the suggestions in this draft, before the peer
starts to use the DRR or RPR, a test that decides whether DRR or RPR
could work should be performed. In this way, it could mitigate the
concerns about influence from the failure of DRR and RPR. The main
benefit from adding the option to use DRR and RPR with SRR fall-back
is that it will improve the success rate and reliability of the
P2PSIP transaction, especially for the scenarios described in section
3.2.
Jiang & Even Expires June 30, 2009 [Page 5]
Internet-Draft P2PSIP RELAY December 2008
Another advantage of DRR/RPR is that the via-list grows as requests
are forwarded around the overlay, so it is highly possible that the
size of the requests is larger than MTU and fragmentation will be
unavoidable, either IP level fragmentation or RELOAD level
fragmentation. DRR and RPR can work without the support of via-list,
making the size of messages more predictable and making it easy to
handle the fragmentation.
4. Concerns From RELOAD
For DRR and RPR routing modes, RELOAD authors has expressed several
concerns in Appendix B.3 and Appendix B.4 in [I-D.ietf-p2psip-base].
This section attempts to address these concerns.
4.1. Concerns About DRR
o Concern1: Due to NAT existence, DRR is subject to failure. So it
requires the destination peer to detect the failure and then
fallback to SRR.
* Answer: The concern is on how DRR works together with SRR. In
this draft we suggest tests in which a node can learn whether
it is publicly reachable. With this information in mind, the
success rate of DRR will improve greatly. On the other hand, a
node can decide which routing mode it will try first based on
past success rate. After several attempts, the node can
transition to other routing mode as a fallback.
o Concern2: Due to NAT filtering behavior, the NAT would drop the
response if it is not a p2p-friendly NAT.
* Answer: This draft introduces tests that a node should perform
before DRR is offered in order to learn whether a node is
publicly reachable, so that DRR will succeed with high
probability.
o Concern3: The response happens to be received by another peer who
is not the sending node and hence it adds to the transaction
latency.
* Answer: We think this is a rare case since this draft
recommends a method to test whether a node is publicly
reachable.
4.2. Concerns About RPR
o Concern1: RPR requires the help from relay peers of the sending
node. It is not easy to identify which category a node is in.
* Answer: RPR does not intend to replace SRR. This draft
proposes RPR and DRR as an enhancement to SRR. As for the
difficulty in identifying a node's role, the draft suggests
tests for learning whether a node is publicly reachable. Using
Jiang & Even Expires June 30, 2009 [Page 6]
Internet-Draft P2PSIP RELAY December 2008
eligible peers as relays is also common in p2p network where
peers can declare themselves as supernodes if they have a
publicly reachable address.
5. Detrming If Node Is Publicly Reachable?
For DRR and RPR to function correctly, a node should be able to
determine whether it is publicly reachable. If it is not, RPR should
be chosen to route the response with the help from relay peers;
otherwise, DRR may be offered. NATs and firewalls are two major
contributors preventing DRR and RPR from functioning properly.
There are a number of techniques with which a node can get its
reflexive address which is on the public side of the NAT. After
getting the reflexive address, a peer can perform further tests to
learn whether the reflexive address is publicly reachable. If the
address proves publicly reachable, the nodes to which the address
belongs can use DRR for responses and also can be a candidate for
relay peer. Nodes being publicly unreachable use RPR to shorten
response path with the help from relay peers
On the other hand, some conditions are unique in P2PSIP architecture
which could be leveraged to facilitate the tests. In P2P overlay
network, every node only has partial view of the whole network and
then knows a few nodes in the overlay. P2P routing algorithm can
easily deliver the request from a sending node to a peer with whom
the sending node has no direct connection. So it is easy for a node
to get other nodes to send unsolicited message to him.
In this section, we first introduce several ways for a node to get
the addresses for the further test. Then a test for learning whether
a peer is publicly reachable is proposed.
5.1. Getting Addresses To Be Used As Candidates for DRR
In order to test whether a peer is publicly reachable, the node
should first get one or more addresses which will be used by other
nodes to send messages directly. This address is either a local
address of a node or a translated address which is assigned by NAT to
the node.
STUN is used to get a reflexive address on the public side of NAT
with the help of STUN servers. There is also a STUN usage
[I-D.ietf-behave-nat-behavior-discovery] to discover NAT behavior.
Under RELOAD architecture, a few infrastructure servers can be
leveraged for this usage, such as enrollment servers, diagnostic
servers, bootstrap servers, etc.
Jiang & Even Expires June 30, 2009 [Page 7]
Internet-Draft P2PSIP RELAY December 2008
The node can use STUN Binding request to one of STUN servers to
trigger a STUN Binding response which returns the reflexive address
from the server's perspective. If the reflexive transport address is
the same as the source address of Binding request, the node can
determine that there is no NAT between him and the chosen
infrastructure server. (Certainly, in some rare cases, the allocated
address happens to be the same as the source address. Further tests
will detect this case and rule it out in the end.). Usually, these
infrastructure severs are publicly reachable in the overlay, so the
node can be considered as being publicly reachable. On the other
hand, with the techniques in
[I-D.ietf-behave-nat-behavior-discovery], a node can also decide
whether it is behind NAT with endpoint-independent mapping behavior.
If the node is behind NAT with endpoint-independent mapping behavior,
the reflexive address should also be a candidate for further tests.
UPnP-IGD is a mechanism that a node can use to get the assigned
address by its residential gateway and after getting this address and
communicating it with other nodes, the node can receive unsolicited
messages from outside, even though it is behind a NAT. So the
address obtained through the UPnP mechanism should also be used for
further tests.
Another way that a node behind NAT can use to learn its assigned
address by NAT is NAT-PMP. Like in UPnP-IGD, the learned address
should also be tested further.
The above techniques are not exhaustive. For example, MIDCOM SIMCO
can also serve the same purpose as UPnP-IGD. These techniques can be
used to get candidate transport addresses for further tests.
5.2. Test On Being Publicly Reachable Or Not
Using the transport addresses obtained by means of the above
techniques, a node can start a test to learn whether the transport
address in question is publicly reachable. The basic idea for the
test is for a node to send a request and expect another node in the
overlay to send back a response. If the response is received by the
sending node successfully and also the node giving the response has
no direct connection with the sending node, the sending node can
determine that the address is probably publicly reachable and hence
the node may be publicly reachable at the tested transport address.
In P2P overlay, a request is routed through the overlay and finally a
destination peer will terminate the request and give the response.
It is high probability that the destination peer has no direct
connection with the sending node. Especially in RELOAD architecture,
every node maintains a connection table. So it is easier for a node
Jiang & Even Expires June 30, 2009 [Page 8]
Internet-Draft P2PSIP RELAY December 2008
to check whether it has direct connection with another node.
Note: Currently, no existing message in base RELOAD can achieve the
test. In our opinion, this kind of test is within diagnostic scope,
so authors hope WG can define a new diagnostic message to do that.
We don't plan to define the message in this document, for the
objective of this draft is to propose an extension to support DRR and
RPR. The following texts is informative.
If a node wants to test whether its transport address is publicly
reachable, it can send a request to the overlay. The routing for the
test message will be a little different from other kinds of requests
because it is not for storing/fetching something to/from the overlay
or locating a specific node, instead it is to get a peer who can
deliver the sending node an unsolicited response and must have no
direct connection with him. So each intermediate peer receiving the
request first checks whether it has direct connections with the
sending peer. If there is any, keep routing the request. Otherwise,
the intermediate peer terminates the request and sends the response
back directly to the sending node with the transport address under
test.
After performing the test, if the peer determines that it is publicly
reachable, it can try DRR in the later transaction. And it should
advertise that it is a candidate for relay peers.
6. Discovery Of Relay Peer
In order to support RPR, a node behind p2p-unfriendly NAT must have
one or more relay peers to help him receive response from destination
peers. The major requirement for relay peers is that they should be
publicly reachable. By performing the test proposed in section 5, a
peer could determine whether it is publicly reachable.
There are several means to get the information about relay peers.
For example, as proposed in base RELOAD [I-D.ietf-p2psip-base],
service discovery for TURN server can also be used to discover relay
peers. In some other cases, the service provider may provide a set
of relay peers to improve the efficiency of the overlay.
7. Relationship Between SRR And DRR/RPR
The major contribution in this draft is to provide available tools to
use DRR/RPR in different situations. In order to make DRR/RPR work
well with SRR, we give some suggestions on how to transition between
them in a P2PSIP transaction.
Jiang & Even Expires June 30, 2009 [Page 9]
Internet-Draft P2PSIP RELAY December 2008
Editor's Note: it is not required that the implementation should use
the same strategy. The specific implementation can use its own
strategy to achieve better performance.
Basically, a peer can collect statistics data on different routing
modes based on previous transactions or develop a dedicated component
to initiate transactions and collect the related statistics data.
For example, a node may have a diagnostic component which sends PING
message with different routing mode, either DRR/RPR or SRR. After
collecting enough data, the peer will have a clearer view about the
success rate of different routing modes. Other than the success
rate, the peer can also get data of fine granularity, for example,
the number of retransmission the peer needs to get a desirable
success rate.
So a typical strategy for the transition is as follows. A node
chooses the routing mode with higher success rate first, for example,
SRR. And he will try for several times based on the statistics data,
i,e, the number of retransmission for the routing mode. After the
suggested number of retransmissions, the node can transition to DRR
or RPR based on the peer is publicly reachable or not.
If the overlay is run within a private network, and all nodes in the
system can reach each other directly, nodes try most of the
transactions with DRR. On the other hand, if the relay peer is
provided by the service provider, nodes prefer RPR over SRR.
8. Extensions To RELOAD
Adding the support of DRR and RPR requires extensions to the current
RELOAD. In this section, first we show the steps taken by a node in
order to use DRR and RPR. Then based on the results, we could point
out the difference from the current RELOAD and define the required
extensions.
8.1. Steps For Running DRR/RPR
DRR and RPR have the similar effect on P2PSIP transaction, i.e.
reduce the response path and improve the success rate. There are
still minor differences between them. In this section, we will give
procedure for running DRR and RPR respectively.
8.1.1. Procedure For Running DRR
After running the tests suggested in section 5, a node can determine
whether it is publicly reachable, either reachable at its own local
public address or a reflexive address assigned by NAT. If a node is
Jiang & Even Expires June 30, 2009 [Page 10]
Internet-Draft P2PSIP RELAY December 2008
publicly reachable, it can use DRR for future transaction.
If a node decides to use DRR for a transaction, it MUST include in
the request its node-id and associated transport address which has
been tested as being publicly reachable. So the destination peer can
use the publicly reachable transport address to send back the
response to the sending node.
8.1.2. Procedure For Running RPR
If a node has no publicly reachable transport address, it chooses RPR
instead of DRR. In order to use RPR, the node MUST get some relay
peers first and then establish direct connection with at least one of
the relay peers before initiating transaction.
As discussed in section 6, overlay has existing mechanisms to
discover relay peers. In RELOAD, it is also easy for a node to use
Attach to create a direct connection with relay peer. Relay peer may
reject requests based on its current load. (Note: Do we need to add
a new error code to describe this kind of error: the node can not
accommodate new connections?) So the node will try other relay peers
till getting a direct connection with relay peer successfully.
When the node decides to use RPR for a transaction, it MUST include
in the request the relay peer's node-id and its associated publicly
reachable transport address. The sending node's node-id also MUST be
included in the request. Upon receiving a request demanding RPR, the
destination peer will send the response directly to the relay peer
with the relay peer's publicly reachable transport address. Then the
relay peer will forward the response to the sending peer through the
existing connection between the relay peer and sending peer.
8.2. Modification To RELOAD Message Structure
RELOAD provides an extensible framework to accommodate future
extensions. This proposal defines a new forwarding option in the
ForwardingHeader structure to allow DRR and RPR. In this section, we
introduce this new forwarding option. The normative procedures which
the peers have to follow for the new option are proposed in the
following section.
RELOAD supports state-keeping style to realize SRR. If DRR or RPR is
to be used, the response will not follow the reverse path so that the
state in the intermediate peers won't be cleared until states expire.
In order to address this issue, the proposal intends to define a new
flag, state-keeping flag, in the message header to indicate whether
the state will be allowed to maintain in the intermediate peers.
Jiang & Even Expires June 30, 2009 [Page 11]
Internet-Draft P2PSIP RELAY December 2008
Editor's note: this flag will be useful for other cases so the
authors suggest adding it in the base draft.
The new forwarding option is named Extensive_Routing_Mode and
conforms to the structure defined in section 5.2.2.3 in
[I-D.ietf-p2psip-base]".
type : 0x1 extensive_routing_mode
flag: 0x02 DESTINATION_CRITICAL
The option value will be illustrated in the following figure.
enum { 0x0, 0x01 (DRR), 0x02(RPR), 255} RouteMode;
struct {
RouteMode routemode;
Transport transport;
Destination destination<1..2>;
IpAddreessPort ipaddressport;
} Extensive_Routing_Mode;
The above structure reuses: Transport, Destination and IpAddressPort
structure defined in section 5.2.1.1 and 5.2.2.1 in
[I-D.ietf-p2psip-base].
Route mode: refers to which kind of routing mode is indicated to the
destination peer. Currently, only DRR and RPR are defined.
Transport: refers to the transport type which is used to deliver
responses from the destination peer to the sending peer or the relay
peer;
Destination: refers to the relay peer or the sending node itself. if
the routing mode is DRR, then the destination only contains the
sending node's node-id; If the routing mode is RPR, then the
destination contains two destinations, which are the relay peer's
node-id and the sending node's node-id;
IpAddressPort: refers to the transport address the destination peer
is using to send the response to.
Jiang & Even Expires June 30, 2009 [Page 12]
Internet-Draft P2PSIP RELAY December 2008
8.3. Request And Response Processing
This section gives normative text on the normal message processing
after DRR and RPR are introduced. Here, we only describe the
additional procedures for supporting DRR and RPR and please refer to
[I-D.ietf-p2psip-base] for RELOAD base procedures.
8.3.1. Sending Peer: Sending Reqeust And Receiving Response
If a peer can offer DRR, it MUST fill the extensive_routing_mode
option first defined in section 8.2 before sending a request out.
The routing mode MUST be set to 0x1(DRR); The destination carries the
sending node node-id and the ipaddressport field MUST carry only one
transport address of the sending node which has been tested.
If a peer can offer RPR, it MUST fill extensive_routing_mode option .
Routing mode MUST be set to 0x2(RPR). The destination MUST hold one
relay peer's node-id and the sending node's node-id in a sequential
order so that the destination peer can tell who is who from the order
of the destinations. The ipaddressport MUST carry one of the
transport addresses of the relay peer.
Upon receiving response, the peer follows the rule in
[I-D.ietf-p2psip-base].
8.3.2. Destination Peer: Receiving Request And Sending Response
When the destination peer receives a request, it will check the
options in the forwarding header. if the destination peer can not
understand extensive_routing_mode option in the request, it tries to
use SRR to return a error response to the sending peer.
If the routing mode is DRR, then the peer constructs the Destination
lists for the response with only one entry, i,e, the sending peer
node-id got from the option in the request; if the routing mode is
RPR, the destination peer constructs Destination list for the
response with two entries, the relay peer node-id and the sending
node node-id which is carried in the option of the request. For RPR,
if there is only one Destination in the option, the destination peer
tries to send a error response to the sending peer using SRR.
After the peer constructs the destination list for the response, it
sends the response to the transport address which is indicated in the
ipaddressport field in the option using the specific transport mode
in the option.
Jiang & Even Expires June 30, 2009 [Page 13]
Internet-Draft P2PSIP RELAY December 2008
8.3.3. What Relay Peer Does?
Relay peers are designed to forward responses to nodes who are not
publicly reachable. For the routing of the response, this draft
still uses the destination list. The only difference from SRR is
that the destination list is not the reverse of the via-list, instead
it is constructed from the forwarding option.
As the ordinary peer, it receives the response, validate the message,
re-adjust the destination-list and forward the response to the next
hop in the destination list based on the connection table. There is
no added requirement for relay peer.
9. An Example
In this section, we give illustration to show the use of DRR or RPR
to route messages. In the following illustration, we use SP for
sending peer, IP for intermediate peer, DP for destination peer, RP
for relay peer.
Jiang & Even Expires June 30, 2009 [Page 14]
Internet-Draft P2PSIP RELAY December 2008
SP IP DP
| StoreReq(DRR) | |
|--------------------->| |
| | StoreReq(DRR) |
| |--------------------->|
| | |
| | |
| StoreAns | |
|<--------------------------------------------|
| | |
| | |
SP RP IP DP
| | | |
| StoreReq| (RPR) | |
|----------------------------->| |
| | |StoreReq(RPR) |
| | |------------->|
| | | |
| | | |
| | StoreAns | |
| StoreAns |<------------------------------|
|<------------| | |
| | | |
The above figures show flow diagrams in the cases where RPR or DRR is
used to routing message, From the above figures, the response does
not follow the reverse path of the request. Responses either go back
directly to the sending peer or go through the relay peer, then
return to the sending peer.
10. Security Considerations
TBD
11. IANA Considerations
11.1. A new RELOAD Forwarding Option
A new RELOAD Forwarding Option type is add to the Registry.
Type: 0x1 - extensive_routing_mode
Jiang & Even Expires June 30, 2009 [Page 15]
Internet-Draft P2PSIP RELAY December 2008
12. Acknowledgements
Authors would like to thank Ted Hardie, Narayanan Vidya and Dondeti
Lakshminath for their comments. Special thanks go to Bruce Lowekamp
for his constructive comments.
13. References
13.1. Normative References
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-01 (work in
progress), December 2008.
[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-02 (work in progress),
July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[ChurnDHT]
Rhea, S., "Handling Churn in a DHT", Proceedings of the
USENIX Annual Technical Conference. Handling Churn in a
DHT, June 2004.
[I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-04
(work in progress), July 2008.
[I-D.ietf-behave-tcp]
Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-08 (work in progress),
September 2008.
[I-D.lowekamp-mmusic-ice-tcp-framework]
Lowekamp, B. and A. Roach, "A Proposal to Define
Interactive Connectivity Establishment for the Transport
Control Protocol (ICE-TCP) as an Extensible Framework",
Jiang & Even Expires June 30, 2009 [Page 16]
Internet-Draft P2PSIP RELAY December 2008
draft-lowekamp-mmusic-ice-tcp-framework-00 (work in
progress), October 2008.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Authors' Addresses
XingFeng Jiang
Huawei Tech.
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 210001
P.R.China
Phone: +86(25)84565867
Email: jiang.x.f@huawei.com
Roni Even
Gesher Erove
14 David Hamelech
Tel Aviv 64953
Israel
Email: ron.even.tlv@gmail.com
Jiang & Even Expires June 30, 2009 [Page 17]