One document matched: draft-jiang-p2psip-relay-00.txt
P2PSIP XingFeng. Jiang
Internet-Draft Huawei Tech.
Intended status: Standards Track R. Even
Expires: April 18, 2009 Gesher Erove
October 25, 2008
An extension to RELOAD to support Direct Response and Relay Peer routing
draft-jiang-p2psip-relay-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 18, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document proposes an extension to RELOAD to support direct
response and relay peer routing modes. The document starts with the
problem statement and address concerns about these two routing modes
mentioned in RELOAD. Then methods about how to discover NAT behavior
of the client in P2PSIP situations are discussed. The last part
proposes extensions to RELOAD for supporting these additional routing
modes.
Jiang & Even Expires April 18, 2009 [Page 1]
Internet-Draft P2PSIP RELAY October 2008
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. How To Identify The Role Of A Peer . . . . . . . . . . . . . . 7
5.1. Discovery Of NAT Mapping Behavior . . . . . . . . . . . . 7
5.2. Discovery Of NAT Filtering Behavior . . . . . . . . . . . 8
6. Discovery Of Relay Peer . . . . . . . . . . . . . . . . . . . 9
7. Relationship Between SRR And DRR/RPR . . . . . . . . . . . . . 10
8. Extensions To RELOAD . . . . . . . . . . . . . . . . . . . . . 10
8.1. Steps For Running DRR/RPR . . . . . . . . . . . . . . . . 10
8.2. Needed Modifications To RELOAD . . . . . . . . . . . . . . 11
8.3. New Message RM_TEST . . . . . . . . . . . . . . . . . . . 11
8.3.1. Detecting NAT Filtering Behavior . . . . . . . . . . . 12
8.3.2. RPR Procedure . . . . . . . . . . . . . . . . . . . . 12
8.4. Modification To RELOAD Message Structure . . . . . . . . . 13
8.5. Request And Response Processing . . . . . . . . . . . . . 14
8.5.1. Sending Reqeust And Receiving Response . . . . . . . . 14
8.5.2. Receiving Request And Sending Response . . . . . . . . 14
9. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. New REALOAD message code . . . . . . . . . . . . . . . . . 16
11.2. A new RELOAD Forwarding Option . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Jiang & Even Expires April 18, 2009 [Page 2]
Internet-Draft P2PSIP RELAY October 2008
1. Introduction
RELOAD 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 section 3.3.1.3 and 3.3.1.4
respectively in [I-D.ietf-p2psip-reload].Symmetric recursive routing
will not work well in some cases. For example, overlay churn will
make the reverse path of the request unstable, therefore fail 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[I-D.ietf-p2psip-reload] about these
two routing options. Then, some methods are presented to show that
it is feasible to discover NAT behavior in 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 current 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.
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 peer's own
local transport addresses. For simplicity, the abbreviation DRR
is used instead in the following text.
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 first who will further forward responses towards the
sending peer. For simplicity, the abbreviation RPR is used
instead in the following text.
Jiang & Even Expires April 18, 2009 [Page 3]
Internet-Draft P2PSIP RELAY October 2008
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 peer. 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. For example, if peer A is behind a p2p-unfriendly NAT, he
can use relay peers to traverse the NAT and get the response from
the destination peer.
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 will run in an overlay
composed of only ten to hundred stable nodes. On the other hand,
overlays may experience heavy churn or comprise of nodes over 1
million. 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 section 3.3.1.5 in RELAOD [I-D.ietf-p2psip-reload],
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 the requests reach the destination peer. In this case,
DRR and RPR won't bring any benefit for 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 is also 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 may be a large number of paths between a sending peer
and a destination peer. Therefore, the request success rate will be
improved greatly. This still leave open the issue of the response
failure due to churn.
Jiang & Even Expires April 18, 2009 [Page 4]
Internet-Draft P2PSIP RELAY October 2008
Through the above analysis, we can see that churn in request path
could be solved to great extent by using existing mechanisms. The
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 response, 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 will be only 1 hop; if RPR is used, the response path
will be 2 hops. According to the suggestions in this draft, before
the peer start to use the DRR or RPR, a test that decides whether the
DRR or RPR could work should be performed. In this way, it could
mitigate the concerns about influence from the failure of the 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 April 18, 2009 [Page 5]
Internet-Draft P2PSIP RELAY October 2008
4. Concerns From RELOAD
For the DRR and RPR routing modes, the RELOAD authors expressed
several concerns in section 3.3.1.3 and section 3.3.1.4 in
[I-D.ietf-p2psip-reload] respectively. 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 the DRR works together with SRR.
In this draft we suggest tests based on the NAT behavior
discovery [I-D.ietf-behave-nat-behavior-discovery] that will
have good probability to find a publicly reachable address or a
relay peer. We can also offer flexibility in which routing
mode will be the main one and which will be the fallback (SRR
first or DRR/RPR first) .
o Concern2: Due to NAT filtering behavior, the NAT would drop the
response if it is not a p2p-friendly NAT.
* Answer: This draft will introduce tests based on
[I-D.ietf-behave-nat-behavior-discovery] that the peer needs to
do before the DRR is offered in order to discover NAT filtering
behavior, so that the DRR will succeed with high probability.
o Concern3: The response happens to be received by another peer who
is not the sending peer and hence it adds to the transaction
latency.
* Answer: We think this is a rare case since this draft
recommends a method to identify the NAT behavior
[I-D.ietf-behave-nat-behavior-discovery]. Even if it would
happen, the method proposed in this draft allows the sending
peer to decide which routing mode will be used first. On the
other hand, as we mentioned before in section 3.3, the main
benefit from DRR is improving the transactions success rate in
some cases, not only the transaction latency.
4.2. Concerns About RPR
o Concern1: RPR requires the help from relay peers for the sending
peer. It is not easy to identify which category a peer is in.
* Answer: RPR does not intend to replace the SRR. This draft
propose RPR and DRR as an enhancement to the SRR. As for the
difficulty in identifying a peer's role, the draft suggests
tests for NAT behavior discovery techniques based on
[I-D.ietf-behave-nat-behavior-discovery] under RELOAD
architecture to achieve the goal. So it is possible for a node
in the overlay to detect its location relative to NAT. Using
Jiang & Even Expires April 18, 2009 [Page 6]
Internet-Draft P2PSIP RELAY October 2008
peer as relays is also common in p2p network where peers can
declare themselves as supernodes if they have a publicly
reachable address.
5. How To Identify The Role Of A Peer
For DRR and RPR to function correctly, a peer should be able to
determine whether it is publicly reachable or not. If it is not, RPR
may be used 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.
Draft [I-D.ietf-behave-nat-behavior-discovery] proposed a STUN usage
to discover NAT behavior. The STUN usage needs a dedicated STUN
server with multiple IP address or it must duplicate the behavior of
such a dedicated STUN server with two nodes that share the role of
providing the address-changing operations required by this usage.
For DRR and RPR in P2P system, NAT address and port mapping and NAT
filtering behaviors are the most important characteristics to be
discovered. So, in order to make DRR and RPR work, the peer needs to
determine if the NAT with respect to the peer has a endpoint-
independent mapping property and a endpoint-independent filtering
property.
At the same time, some conditions are unique in P2PSIP architecture
which could be exploited to make the discovery easier. For example,
there are some public servers, such as enrollment servers, bootstrap
servers, who could be used as an anchor to perform NAT behavior
discovery tests when the node joins the overlay. P2PSIP overlay has
enough nodes which could provide help with the test when there is a
need for receiving an unsolicited message from another address and
port.
The following text, details suggestions on how to discover NAT
behavior in P2PSIP architecture.
5.1. Discovery Of NAT Mapping Behavior
In RELOAD architecture there are a couple of servers that may have a
publicly reachable address that can be used for discovering the NAT
mapping behavior. The peer should look for endpoint independent
mapping as a prerequisite to allow DDR or to be a relay peer.
To do that we can use the enrollment server used to get the required
information, such as node-id, overlay specific configuration, etc.
Usually, the enrollment server is publicly reachable and could be
contacted directly by any nodes in the system. So it can act as an
Jiang & Even Expires April 18, 2009 [Page 7]
Internet-Draft P2PSIP RELAY October 2008
anchor to help nodes to learn whether it is on the same network as
the enrollment server. Besides enrollment server, there are other
infrastructure servers in the system, depending on the real
deployment. For example, bootstrap servers or diagnostic servers may
exist in some P2P system for management purpose.
The methods a node uses to determine its location are various and
depend on specific deployments. One way is a node can use a variant
of STUN during exchanges with one of the servers. For example, when
the node contacts with the enrollment server, the enrollment server
could reflect the source transport address of the messages from the
node, and convey it to the node in the response. The node compares
its local transport address with the reflexive address in the
response, and then makes the final determination. Another way is to
use the STUN protocol as described in the NAT behavior discovery
[I-D.ietf-behave-nat-behavior-discovery]. All nodes and server in
the P2P system need to support STUN. In either way, the peer could
learn through the above procedure whether the NAT has a endpoint-
independent mapping behavior or not. Another method to get a
reachable address can be based on NAT assisted methods like UPnP as
suggested in [I-D.lowekamp-mmusic-ice-tcp-framework]
5.2. Discovery Of NAT Filtering Behavior
After discovering NAT mapping behavior is endpoint-independent, a
node needs to continue with discovery of the NAT filtering behavior.
The proposed test in [I-D.ietf-behave-nat-behavior-discovery]requires
the STUN server has multiple addresses or if a few STUN servers with
single address are involved, require coordination among them to
complete the test. The test described in
[I-D.ietf-behave-nat-behavior-discovery] is applicable to UDP while
for RELAOD we need to use TCP address. In P2PSIP system, we can take
advantage of the fact that a peer has a built-in mechanism to talk
with other nodes with whom he has not contacted before, the routing
function in the P2P algorithm can route the request to any peer in
the overlay who is responsible for a key in a request. We can use
this functionality to define a test for the NAT filtering behavior.
If a node could receive messages from other nodes with whom it does
not have a connection, then the remote node could help the testing if
the NAT has an endpoint-independent filtering behavior. In current
P2PSIP architecture, a node can easily know whether it has existing
connections with the unsolicited message sender, for any node
maintains a connection table. The peer that wants to learn its NAT
filtering behavior can send a request for a key in order to learn
from the responder the filtering behavior of the NAT.
In the above description, we assume the destination peer has no
Jiang & Even Expires April 18, 2009 [Page 8]
Internet-Draft P2PSIP RELAY October 2008
direct connections with the node in question before sending the
response. But there are a few rare cases where the assumption does
not hold. One case is the request only traverses one hop so that the
destination peer is the direct neighbor with the node; another case
is the destination peer happens to be the neighbor of the node even
if the request traverses several hops. It often depends on the key
set in the request. Two methods can address the above problem.
The first one is to have the sending node make the judgment because
every node has a connection table. For example, when the sending
node receives the response from a peer, it should check whether the
response came over an existing connection or not. If yes, then the
sending peer should try another key and perform another test.
The second one is to make a little modification to the way the test
message is routed. In conventional P2P algorithms, the next hop is
often determined by looking up the key in the routing table and the
closest node will be chosen accordingly. But for the test purpose,
the request is not really for STORE or FETCH values to/from the
overlay. Its real purpose is to find a peer in the overlay with whom
the peer has no connection. In a sense, intermediate peers need not
route the message according to the conventional routing algorithm.
Instead, they could do the random routing which is irrelevant to the
key in a request. So the peer who has no direct connection with the
sending peer would be considered as the destination peer and then
sends the response directly to the sending peer. In the second
method, the test message is resilient to overlay churn, for the
routing is based on the random choice. Moreover it also means that
we need to define a new message to perform the test and that all
intermediate peers should know how to process the request.
6. Discovery Of Relay Peer
In order to support RPR, a node who is 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 using the methods proposed in
section 5, a peer could determine whether it is publicly reachable,
i,e, with an endpoint-independent mapping and filtering behavior.
Generally, P2PSIP overlay needs a service discovery mechanism by
means of which the node in the overlay could find which peers can
provide which kind of service. The capability of the relay peers
could be defined as a service and discovering relay peers means that
peers use the general service mechanism to find which peer can
provide relay peer capability.
Jiang & Even Expires April 18, 2009 [Page 9]
Internet-Draft P2PSIP RELAY October 2008
7. Relationship Between SRR And DRR/RPR
DRR/RPR and SRR have their advantages and disadvantages. A major
issue should be addressed before we design ways to combine these two
kinds of routing modes. It is in which order the DRR/RPR or SRR is
attempted. In order to make full use of advantages of every routing
mode, the peer should decide which one is tried first. There are
several strategies. If a peer wants to get quick response, it can
try DRR/RPR first; if failed, then fallback to SRR. In this draft,
DRR/RPR test SHOULD be passed before DRR/RPR is used for message
routing so that DRR/RPR would work with high success rate. On the
other hand, a peer can also try SRR first and then DRR/RPR would be
used as a fallback. This draft does not mandate which order will be
used. It depends on specific scenarios. This draft just provides
available tools to give the peers different choices to deal with
different situations. The decision if to use DRR/RPR first can also
be based on past success percentage of this mode. .
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 may fail in the presence of NAT. So in order to improve
the success rate of DRR and RPR, we need to do some necessary tests
before a node can use it. Below are the required steps to make DRR
and RPR work.
1. When a peer X joins the overlay, it uses proposed mechanism in
section 5.1 to determine its NAT mapping behavior.
2. After X becomes a full-functional peer in the overlay, If the
previous test shows that his NAT has a endpoint-independent
mapping behavior, he will continue with the proposed mechanism in
section 5.2 to determine its NAT filtering behavior.
3. Based on the above two tests, if peer X learns that it is behind
a p2p-friendly NAT or non-NATed, i,e, endpoint-independent
mapping and filtering behavior, the peer could try DRR in the
future message. Moreover, he is also a candidate to be a relay
peer. In order to adapt to the change of NAT mapping and
filtering, peer X SHOULD periodically perform the tests.
Jiang & Even Expires April 18, 2009 [Page 10]
Internet-Draft P2PSIP RELAY October 2008
4. If peer X is behind a p2p-unfirendly NAT, peer X tries to get
relay peers with service discovery mechanism. Peer X should try
to attach to one of the relay peers to verify that it can use it
as a relay.
5. Peer X can offer DRR or RPR respectively depending on peer X
location with regard to NAT. This offer is done by adding
extensive_routing_mode structure in the forawdingHeader to each
request and using the preference flag in the
extensive_routing_mode structure to specify if SRR or DRR/RPR are
to be used first. If the preference flag equals to 0 then DRR/
RPR should be tried first otherwise SRR should be used first.
8.2. Needed Modifications To RELOAD
In order to support the DRR/RPR, we need to make the following
modifications to RELOAD.
1. Define a forwarding option in the forward header to indicate
which routing mode can be used. Depending on different routing
mode, the information in the option value field is different.
For example, if DRR is used, the information about sending nodes
MUST be included; If RPR is used, the information about the send
node's relay peers MUST be included.
2. Define a new message to perform tests that will be used to detect
NAT filtering behavior and to test whether DRR or RPR works. In
this draft, the new message is named RM_TEST( Routing Mode Test
).
3. Add a new flag bit (hop-by-hop flag: 0x04) in the flags field in
the forward header. This flag is used to indicate to the
intermediate peers that they need to know the semantics of the
message and take some actions accordingly. As mentioned in
section 5.2, in order to make sure the destination peer has no
direct connection with the sending peer, every intermediate peer
determines whether it has existing connections with the sending
peer. So it requires the intermediate peers involvement to
achieve the test. Of course, it could use other methods from
section 5.2 to avoid define a new flag. At this stage, we think
the flag is useful, but it is subject to change depending on
working group's consensus.
8.3. New Message RM_TEST
RM_TEST serves two purposes: detecting NAT filtering behavior and
checking whether DRR or RPR works. The following is the normative
procedure for processing the RM_TEST.
Jiang & Even Expires April 18, 2009 [Page 11]
Internet-Draft P2PSIP RELAY October 2008
8.3.1. Detecting NAT Filtering Behavior
In order to detect NAT filtering behavior, the sending peer MUST
determine whether his NAT has a endpoint-independent mapping behavior
first as specified in [I-D.ietf-behave-nat-behavior-discovery]. Then
sending peer sets the routing mode as DRR in the forwarding header,
in which one of the sending peer's reflexive transport address is
also carried. It is REQUIRED that in each test message, only one
reflexive transport address is included. At the same time, set the
hop-by-hop flag 0x04 in the forwarding header. The key in the
destination list SHOULD be a random one.
[ Open issue: because the RM_TEST message is not for real data or
management operations, just for a test, do we need a specialized ID
which indicates to the intermediate peers that the destination peer
for the message depends on the semantics of the message type? ]
When an intermediate peer receives the message, it checks the hop-by-
hop flags first. If the flag is set, then get the message type. If
the message type is RM_TEST, get the routing mode and its associated
information, i,e, transport address information. If the intermediate
peer has no existing connections with the sending peer after checking
its connection table based on the node-id, then he can act as the
destination peer for the RM_TEST message, constructs a response and
sends directly to the sending peer. If the intermediate peer has
existing connections, it forwards the request further.
The sending peer waits for the RM_TEST response by setting a
retransmission timer. If the response succeeds in returning to the
sending peer, the sending peer can determine that his NAT has
endpoint-independent filtering behavior. To avoid the unreliability
of the underlying network, the sending peer will try the RM_TEST
several times before he gives up the test.
8.3.2. RPR Procedure
If a peer is behind a p2p-unfriendly NAT after doing the NAT behavior
tests, and would like to offer RPR it MUST get relay peers first. A
peer that declared itself as a relay peer have already done the NAT
behavior tests and have at least a publicly reachable address.
Furthermore a peer may learn about more than one available relay
peers.
After getting the information of relay peers, the peer uses Attach
method to establish direct connections with one of the possible relay
peers. A relay peer may reject the Attach request if it is currently
loaded, in this case the peer may try another relay peer. When a
peer attached to a relay peer it can now offer RPR.
Jiang & Even Expires April 18, 2009 [Page 12]
Internet-Draft P2PSIP RELAY October 2008
8.4. Modification To RELOAD Message Structure
Some necessary modifications to RELOAD message structure are
explained in the following text.
This draft defines a new forwarding option in the ForwardingHeader
structure. The new forwarding option must conform to the structure
defined in section 6.2.2.3 in [I-D.ietf-p2psip-reload].
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;
uint8 preference;
Transport transport;
Destination destination<1..2>;
IpAddreessPort ipaddressport;
} Extensive_Routing_Mode;
The above structure reuses: Transport, Destination and IpAddressPort
structure defined in section 6.2.1.1 and 6.2.2.1 in
[I-D.ietf-p2psip-reload] respectively. The node-id in Destination
structure is useful to match the existing connections.
routemode: refers to which kind of routing mode is preferred to be
used among extensive routing modes. Currently, only DRR and RPR are
defined.
preference: refers to which kind of routing mode the destination peer
will try first. 0x1 means SRR first, 0x0 means the extensive routing
mode will be tried first;
Transport: refers to the transport type which will be used to deliver
the response from the destination peer to the sending peer or the
relay peer;
Destination: refers to the relay peer or the sending peer itself. If
Jiang & Even Expires April 18, 2009 [Page 13]
Internet-Draft P2PSIP RELAY October 2008
routing type is DRR, then the destination will contains the sending
peer's node-id; If routing type is RPR, then the destination will
contains two destinations, which are the relay peer's node-id and the
sending peer's node-id;
IpAddressPort: refers to the transport address the destination has to
use to send the response to.
8.5. 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-reload] for RELOAD base procedures.
8.5.1. Sending Reqeust And Receiving Response
If a peer can offer DRR, it MUST fill the extensive_routing_mode
option first defined in section 8.4 before sending the request out.
The routing mode MUST be set to 0x1(DRR); the preference MUST be 0 or
1 which depends on the choice of the sending peer. If the peer wants
to try DRR first, then the field MUST be set to 0; otherwise 1. The
destination carries the sending peer node-id and the ipaddressport
MUST carry only one transport address which has been tested.
If a peer can offer RPR, it MUST fill extensive_routing_mode option
too. Routing mode MUST be set to 0x2(RPR). The preference MUST be
set to 0 or 1 depending on the choice of the sending peer. The
destination MUST hold one relay peer's node-id and the sending peer's
node-id in a sequential order. The ipaddressport MUST carry one of
the relay peer's transport address which has been tested.
For receving response, the peer follows the rule in
[I-D.ietf-p2psip-reload].
8.5.2. 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
understand extensive_routing_mode option, it will check the
preference first, if the preference shows SRR first, then the peer
will use the SRR to return the response.
If the preference shows DRR/RPR first, then the peer check the
routing mode. if the routing mode is DRR, then the peer constructs
the Destination lists with only one entry, i,e, the sending peer
node-id in the option; if the routing mode is RPR, then the peer
construct Destination list with two entries, one is the relay peer
Jiang & Even Expires April 18, 2009 [Page 14]
Internet-Draft P2PSIP RELAY October 2008
node-id got from the option, the other one is the sending peer
node-id which is also carried in the option in RPR case.
After the peer construct the destination list, if the peer will use
DRR or RPR, then they will send the response to the transport address
which is indicated in the ipaddressport field in the option using the
specific transport mode in the option.
9. An Example
In this section, we will illustrate how a peer uses the 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; The letter H in the figure refers to hop-by-hop flag in the
forwarding header.
1. Detect the NAT filtering behavior
SP IP DP
| RM_TEST(DRR | H) | |
|--------------------->| |
| | RM_TEST(DRR | H) |
| |--------------------->|
| | |
| | |
| RM_TEST Resp | |
|<--------------------------------------------|
| | |
SP sends a RM_TEST request and set the DRR routing mode and hop-by-
hop flag in the request. IP will forward the request until the
intermediate peer checks that it has no existing connections with SP,
then it changes its role to DP. Finally, DP sends a RM_TEST response
back to the SP.
2. Sending other messages than RM_TEST with DRR or RPR
Jiang & Even Expires April 18, 2009 [Page 15]
Internet-Draft P2PSIP RELAY October 2008
SP IP DP
| StoreReq(DRR) | |
|--------------------->| |
| | StoreReq(DRR) |
| |--------------------->|
| | |
| | |
| StoreAns | |
|<--------------------------------------------|
| | |
| | |
SP RP IP DP
| | | |
| StoreReq| (RPR) | |
|----------------------------->| |
| | |StoreReq(RPR) |
| | |------------->|
| | | |
| | | |
| | StoreAns | |
| StoreAns |<------------------------------|
|<------------| | |
| | | |
The above figures show how DRR and RPR are used to route normal
message. The major difference from RM_TEST is that hop-by-hop flag
is not required. It may depend on the message in use.
10. Security Considerations
TBD
11. IANA Considerations
11.1. New REALOAD message code
A new RELOAD message code RM_TEST and RM_TEST_ANS are added in this
contribution. The new REALOAD message codes should be assigned by
IANA.
RM_TEST: 23
RM_TEST_ANS: 24
Jiang & Even Expires April 18, 2009 [Page 16]
Internet-Draft P2PSIP RELAY October 2008
11.2. A new RELOAD Forwarding Option
A new RELOAD Forwarding Option type is add to the Registry.
Type: 0x1 - extensive_routing_mode
12. Acknowledgements
Authors would like to thank Ted Hardie, Narayanan Vidya and Dondeti
Lakshminath for their comments.
13. References
13.1. Normative 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-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.
[I-D.ietf-p2psip-reload]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD)", draft-ietf-p2psip-reload-00 (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
[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),
Jiang & Even Expires April 18, 2009 [Page 17]
Internet-Draft P2PSIP RELAY October 2008
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",
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 April 18, 2009 [Page 18]
Internet-Draft P2PSIP RELAY October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jiang & Even Expires April 18, 2009 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-22 23:21:33 |