One document matched: draft-jiang-p2psip-sep-01.txt
Differences from draft-jiang-p2psip-sep-00.txt
P2PSIP XingFeng. Jiang
Internet-Draft HeWen. Zheng
Intended status: Standards Track Huawei Tech.
Expires: August 4, 2008 C. Macian
V. Pascual
Pompeu Fabra University
February 1, 2008
Service Extensible P2P Peer Protocol
draft-jiang-p2psip-sep-01
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 August 4, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes the Service Extensible Protocol (SEP), which
is the peer protocol spoken between P2PSIP Overlay peers to share
information and organize the P2PSIP Overlay Network. SEP uses a
flexible forwarding mechanism to avoid congestion in the Overlay. It
also proposes a general service discovery method and a built-in NAT
Jiang, et al. Expires August 4, 2008 [Page 1]
Internet-Draft P2PSIP SEP February 2008
traversal mechanism. By using these methods, SEP tries to improve
the success rate and reduce the latency of the transaction.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Routing States . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Operations . . . . . . . . . . . . . . . . . . . . . 7
3.3. Data Transfer During the Overlay Churn . . . . . . . . . . 7
4. Design Choice . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 8
4.2. Relaying Peer . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Cases in which Relaying Peers Help . . . . . . . . . . 10
4.2.2. Locating Relaying Peer . . . . . . . . . . . . . . . 10
4.2.3. How to Use Relaying Peer . . . . . . . . . . . . . . . 11
4.3. Routing Mode . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Flexible Routing Mechanism . . . . . . . . . . . . . . . . 12
4.5. End-to-end Reliability . . . . . . . . . . . . . . . . . . 12
5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Message Attribute . . . . . . . . . . . . . . . . . . . . 15
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Peer Address Info . . . . . . . . . . . . . . . . . . 15
5.2.3. Peer service capability . . . . . . . . . . . . . . . 16
5.2.4. Peer-ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.5. Source Peer Info . . . . . . . . . . . . . . . . . . . 17
5.2.6. Destination Peer Info . . . . . . . . . . . . . . . . 18
5.2.7. Resource Info . . . . . . . . . . . . . . . . . . . . 18
5.2.8. Negotiation Info . . . . . . . . . . . . . . . . . . . 20
5.2.9. Response Attribute . . . . . . . . . . . . . . . . . . 20
5.2.10. Service Peer Info . . . . . . . . . . . . . . . . . . 20
5.2.11. Relaying Peer Info . . . . . . . . . . . . . . . . . . 22
5.2.12. Source Reflexive Address attribute . . . . . . . . . . 22
5.2.13. Routing table . . . . . . . . . . . . . . . . . . . . 23
5.2.14. Status Info . . . . . . . . . . . . . . . . . . . . . 23
5.2.15. Event Info . . . . . . . . . . . . . . . . . . . . . . 23
5.2.16. Update Type . . . . . . . . . . . . . . . . . . . . . 24
5.2.17. Overlay Configuration Info . . . . . . . . . . . . . . 24
6. Peer Protocol Message . . . . . . . . . . . . . . . . . . . . 25
6.1. Overlay Maintenance . . . . . . . . . . . . . . . . . . . 25
6.1.1. JOIN . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. LEAVE . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.3. KEEPALIVE . . . . . . . . . . . . . . . . . . . . . . 28
6.1.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.5. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . 29
Jiang, et al. Expires August 4, 2008 [Page 2]
Internet-Draft P2PSIP SEP February 2008
6.1.6. SearchPeer . . . . . . . . . . . . . . . . . . . . . . 30
6.1.7. TRANSFER . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Data Operations . . . . . . . . . . . . . . . . . . . . . 31
6.2.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.3. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3. Additional messages . . . . . . . . . . . . . . . . . . . 33
6.3.1. LookUpServicePeer . . . . . . . . . . . . . . . . . . 33
7. Routing Operations . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Request Routing . . . . . . . . . . . . . . . . . . . . . 35
7.2. Response Routing . . . . . . . . . . . . . . . . . . . . . 36
7.2.1. Response Routing on the Destination Peer . . . . . . . 36
7.2.2. Response Routing on the Intermediate Peer . . . . . . 36
8. General Peer Behavior . . . . . . . . . . . . . . . . . . . . 37
8.1. Source Peer Behavior . . . . . . . . . . . . . . . . . . . 37
8.1.1. Generating the Request and Sending the Request . . . . 37
8.1.2. Processing the Response . . . . . . . . . . . . . . . 38
8.2. Intermediate Peer Behavior . . . . . . . . . . . . . . . . 39
8.2.1. Request Processing . . . . . . . . . . . . . . . . . . 39
8.2.2. Response Processing . . . . . . . . . . . . . . . . . 39
8.3. Destination Peer Behavior . . . . . . . . . . . . . . . . 40
8.3.1. Request Processing . . . . . . . . . . . . . . . . . . 40
8.3.2. Response Generation and Sending the Response . . . . . 40
9. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Gather ICE candidates . . . . . . . . . . . . . . . . . . 41
9.2. Response from the Destination Peer to the Source Peer . . 42
9.2.1. How to Make JOIN Response Return to Source Peer . . . 42
9.3. Exchange Candidates for the Direct Communication . . . . . 43
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46
Jiang, et al. Expires August 4, 2008 [Page 3]
Internet-Draft P2PSIP SEP February 2008
1. Introduction
This document proposes a Service Extensible Protocol (SEP), which is
spoken between P2PSIP peers. The SEP conforms to the definition of
P2PSIP Peer protocol in [concept]. Like the definition, SEP not only
maintains the P2PSIP overlay topology, but also provides distributed
database service.
1. SEP uses a flexible packet forwarding mechanism so that peers
could choose the best peer to route the packet further. For
example, if a peer selects a downstream peer which has no enough
resource at that time, then the requests may be discarded by the
downstream peer. So the upstream peer could choose another
downstream peer which is in good condition.
2. In P2PSIP, peers offer storage and transport services to allow
the distributed database function and distributed transport
function to be implemented. It is expected that individual peers
may also offer other services. SEP provides a common method for
service discovery, i.e. to discover which peers could provide a
specific service. Some of these additional services (for
example, a STUN server [STUN]) may be required to allow the
overlay to form and operate, while others (for example, a
voicemail service) may be enhancements to the basic P2PSIP
functionality [concept].
3. The routing modes taken by the SEP attempts to make the
transaction with lower latency and higher success rate even if
the intermediate peers fail or NATs are between the source and
the destination peers.
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 [1].
Some of the terminologies are borrowed from the [concept].
O Routing states: it is a general description of the information used
to route packets through the overlay. Several kinds of routing
states exist. Routing table and neighbor table are two examples.
O Service peer: peers who provide one or more services in addition to
routing and storage service.
O Public peer: peers who are on the public Internet. In case P2PSIP
system uses a private addressing scheme, the address realm is also
considered public if the peers in the realm could be reached by any
Jiang, et al. Expires August 4, 2008 [Page 4]
Internet-Draft P2PSIP SEP February 2008
other peer.
O Upstream peer/downstream peer: they are paired with each other.
Downstream peers often appear in the routing states of a upstream
peer and receives packets from upstream peer directly.
O Transaction: a transaction is initiated by the source peer and
comprises a request and several responses. Transaction is an end-to-
end concept and is uniquely identified by the tuple, including a
source peer-ID, a destination ID, a message type, transaction ID
(chosen by the source peer).
O Relaying peer: peers are willing to relay response destined to the
source peer of the request. One example of relaying peers is a peer
which is located on the public Internet and could be directly reached
by any peer without any prior negotiations between them so long as
other peers have the relay peer's transport address.
O Dialog: is a peer-to-peer long-term relationship between two peers
and is uniquely identified by a dialog identifier. It represents a
context that facilitates the sequencing of messages (i.e. maintain
states) between the peers and proper routing of requests between both
of them. Not all peer protocol requests create dialogs. The
requests that create the dialogs need well-defined mechanisms of
establishing and tearing down the dialog. An example of a dialog may
be the long-term relationship between a peer X and its replica Y.
Peer X is a responsible peer which has several replicas (Peers which
are responsible for maintaining and storing the same information)
within the overlay. Peer X may establish a long-term relationship
(i.e. one dialog) with each replica and may need to maintain their
information and state. When a replica Y decides to stop serving as
such or Peer X decides to leave the overlay, the dialog should be
torn down. Other example may be when a peer joins or (gracefully)
leaves the P2P overlay network, data transfer operations will be
triggered. The joining peer will be responsible for some <key,
value> pairs and the leaving node SHOULD transfer its stored <key,
value> pairs to its neighbors. When several transfer transactions
take place between two nodes a dialog may be established to keep
control over the status of the relationship.
3. Overview
Each peer in the overlay keeps its own routing states, including a
routing table, a neighbor table or other states which are maintained
by the DHT algorithms. According to the DHT algorithms, the peer
must learn other peers' information and communicate with them. So
the routing states not only keep the network reachability information
Jiang, et al. Expires August 4, 2008 [Page 5]
Internet-Draft P2PSIP SEP February 2008
of its downstream peers, but can also be extended to store other
information of its downstream peers, for example, service capability,
processing status, etc.
Peers with heterogeneous capability make up of the P2PSIP overlay.
SEP attempts to benefit from the heterogeneity among the peers and
mitigates the bad effect resulting from it at the same time. Some
peers could provide other service in addition to the routing and
storage service which are the required services for peers. These
additional services include STUN, STUN Relay, etc, which are needed
by other peers, for example, which are behind the NAT. In terms of
processing resource, such as bandwidth, CPU cycles, they are also
heterogeneous. This kind of heterogeneity may make the less powerful
peer congested by the messages from the more powerful peers and fail
the transactions processed by the congested peers. In this case, a
simple flow control mechanism between immediate peers combined with a
flexible forwarding mechanism would make the situation better.
The communication between peers may not work in the presence of the
NAT. The IETF has developed the STUN/TURN/ICE protocols to address
this problem. SEP works with these proposals and also provides a
relay peers to facilitate the NAT traversal.
3.1. Routing States
Each peer should maintain routing states and route packets by
choosing the next hop peer from the routing states. The routing
states should be updated as the overlay topology changes. Here, we
give an example data organization of routing states, and explain each
item in the entry. Although this is an implementation issue,
comprehension on the routing states will make reader understand SEP
easier.
In current DHT algorithms, there are often two kinds of routing
states: routing table and neighbor table. Routing table is often
asymmetric and neighbor table is symmetric. Peers in the routing
states are also called P2PSIP neighbors defined in the [concept]. It
means the peer could reach these peers directly without further
lookup.
The routing states are often comprised of several entries. Each
entry keeps the information about the P2PSIP neighbors. The
information about the P2PSIP neighbors might be organized as follows.
O Peer-ID: which uniquely identifies a peer in the overlay.
O Workable candidate pairs: this item records several candidate pairs
which are found by using ICE procedure. By using them, peers could
Jiang, et al. Expires August 4, 2008 [Page 6]
Internet-Draft P2PSIP SEP February 2008
communicate with its neighbors directly. Two or more workable
candidate pairs could improve the stability of the P2PSIP peer
control connection.
O Current processing status: this item reflects the processing status
of the peer's neighbors. The possible status may be simply
classified into normal or busy. They also may be measured by some
quantitative parameters, such as CPU idle percentage, available
bandwidth, etc.
O Service capability: it gives information about additional services
supported by the peer. Having this kind of information in mind, the
peer learns which neighbors could provide a specific service.
Note: here, we just list some basic items of the information about
the P2PSIP neighbors. This information is not exhaustive and will be
extended to support new functions if needed.
3.2. Data Operations
A peer may put multiple resource objects in the overlay under the
same resource ID, and some peers may put various resource objects
with the same resource ID. Therefore, there may be multiple resource
objects under the same resource ID. SEP uses the owner identity and
hash code accompanied with resource ID to locate the unique resource
object.
A resource object in the P2P overlay network can be any type of data,
such as a contact address, a file, etc. The size varies from one
resource object to another. Resource objects with small size can
directly be put to or got from the overlay by carrying them in the
PUT or GET message. If the size is over some limit, it's more
efficient to exchange the resource object using a direct connection.
SEP supports both kinds of operation. Negotiation information is put
into the PUT or GET message to negotiate a direct data transport for
the latter.
The resource objects should be transferred from one peer to another
when the overlay churns. But the sending peer may not be aware of
the state of the receiving peer, and whether the receiving peer is
really responsible for the <key, value> pairs to be transferred. SEP
provides a TRANSFER operation with negotiation capability to solve
these problems.
3.3. Data Transfer During the Overlay Churn
In P2P overlay, peers can join and leave the overlay at any time.
Therefore two operations of data moving and routing states update
Jiang, et al. Expires August 4, 2008 [Page 7]
Internet-Draft P2PSIP SEP February 2008
should be performed accordingly. During the churn, some data may be
placed on the wrong peer because the two operations can't keep pace
with each other. In the meantime, a lookup operation for a key may
fail in that the data associated with the key is not on the correct
root peer.
SEP attempts to reduce the failure possibility of the transaction
during the overlay churn. The idea is to make the joining peer or
leaving peer work together with its neighbors to serve the coming
lookup operations. For example, when a peer is about to leave the
network, it could transfer <key, value> pairs to its neighbors and
notify other peers its departure simultaneously. Before the transfer
completes, both the leaving peer and its neighbors may be the target
of the lookup operation due to routing states update in other peers.
So they could serve the lookup operation together by leading the
requests to which if they have no answer to the others.
4. Design Choice
In this section, some considerations about the SEP's design are
presented. The principle behind the design is to make the
transaction with shorter latency and higher success rate even in the
environment where peers churn frequently and some peers may be
overloaded by traffic. So we choose the semi-recursive routing mode
combined with overlay native routing mode and propose a flexible
forwarding mechanism to avoid the congestion in the overlay. Other
design choices such as end-to-end reliability and service discovery
are also discussed in this section.
4.1. Service Discovery
The nature of peer-to-peer computing is that each peer offers
services to other peers to allow the overlay to collectively provide
larger functions [concept]. For example, routing and storage service
provided by each peer enable the distributed database function of the
overlay, where any peer may store any data under a key and any other
peer may fetch it using the same key. Since there exists
heterogeneity in peers' capabilities, as pointed out by the
descriptions in section 2.1 of [concept], some additional services
other than routing and storage will be needed. Thus, two kind of
services may exist: those well-known and common in most overlays and
required to allow the overlay to form and operate (for example, a
STUN server [rfc3489bis]), and others which are enhancements to the
basic P2PSIP functionality (for example, a voicemail service) and are
specific for a given overlay. In both cases, service discovery
procedures are required in order to discover services and their
operation. SEP proposes three methods to do the service discovery,
Jiang, et al. Expires August 4, 2008 [Page 8]
Internet-Draft P2PSIP SEP February 2008
i.e. service search based on well-known service names, random walk
through the overlay and neighbors' service publication.
The first method consists on performing a regular overlay search
based on the well-known Resource ID of a given service. To that end,
the responsible node must have previously published (i.e., PUT) the
Resource ID in the overlay.The second one, random walk through the
overlay, tries to get the Peer ID of the responsible service peers by
walking hop-by-hop through the ovelay and getting information
provided by intermediate peers until one peer gives a response. In
the last method, each peer's routing state intends to store its
neighbors' service capabilities, i.e. which kinds of service its
neighbors could provide. Then, the service capability information is
advertised through the overlay maintenance mechanism as is described
in section 3.1.
SEP provides a message LookUpServicePeer for the peer to attempt to
collect the service peers providing a non-well-known service by
walking through the overlay. The peer in need of a specific service
will send a LookUpServicePeer message in which the service taxonomy
type is indicated and the destination ID could be chosen at random.
Then the intermediate peers receiving the message will check whether
there are peers in its routing states providing the desired service.
If there is at least one peer, the intermediate peer would insert the
information in the request and route the request further. In the
end, the destination peer will return the information to the source
peer in the response. So, the service discovery is made by randomly
routing the packet through the overlay. The source peer could try
different destination IDs and make sure to get more service peers'
information. If LookUpServicePeer messages are sent several times,
we could choose different destination IDs to make the message go
through different paths, so that the source peer will have a chance
to ask more peers.
What information SEP intends to get is to learn the reachability
information of these service peers. It does not care about whether
the service peers are capable of serving the peers in need of this
service at the moment. With several service peers in mind, the peer
in need of the service could try all service peers until it gets
served. As for how to choose the best service peer, it is hard to
achieve. But in SEP, if every peer which provides a specific service
could update its service status and keep it in the routing states as
described in section 2.1, the peers who look for service peers may
choose based on their associated service status. Service delivery is
done by setting up a session to a service provider peer or any other
way of interaction with the specified peer. This procedure is out of
the scope of this draft. However, in this process the current status
of the service COULD be communicated, so that the requesting node can
Jiang, et al. Expires August 4, 2008 [Page 9]
Internet-Draft P2PSIP SEP February 2008
make an updated decision as to which serving node to contact.
4.2. Relaying Peer
Some peers may be visited directly by other peers. This kind of
peers will help communications between peers who need to exchange
information, but have no direct connection yet. These peers could
relay messages between peers mentioned above. Here, we call these
peers realying peer.
4.2.1. Cases in which Relaying Peers Help
The use of relaying peer could help message traverse NAT and reach
its recipient. Further, it could also improve transactions'
reliability due to fewer hops. Here, we list cases where relaying
peers are suited to be applied.
1. In semi-recursive routing mode, if the source peer sending a
request is behind NAT, the response is hard to be returned to the
source peer directly. With the use of a relaying peer, the
relaying peer receives the response from a peer and relays it to
the source peer.
2. In recursive routing mode, peers often use the reverse
connections to its upstream peers to route the response.
However, the reverse connections may break down when the peer
receives a response. The reasons for the breakdown are various,
for example, when the upstream peer has left the overlay, or TURN
server between two peers has failed, or NATs between two peers
reboot, etc. In this case, the peer could attempt to send the
response to the source peer with the hlep from a relaying peer.
4.2.2. Locating Relaying Peer
Before asking for help from relaying peers, a peer should locate
where the relaying peers are. There are two requirements on the
peers who are eligible for a relaying peer.
1. The peer SHOULD have a unrestricted connectivity. It may be on
the Internet or behind the p2p-friendly NAT. All in all, other
peer could reach it so long as they have relaying peers'
transport address.
2. The relaying peer SHOULD know how to send a response to the
source peer when the source peer is behind NAT. It could be
achieved at least by two means. One is to choose its own
neighbor peer as its relaying peer because they have already
established direct connections. The other is to send the request
directly to the its chosen relaying peer and the relaying peer
keeps state of the source peer's transport address based on the
Jiang, et al. Expires August 4, 2008 [Page 10]
Internet-Draft P2PSIP SEP February 2008
incoming request or carry the address in the request and get from
the response again the source peer's transport address which will
be used to relay response to the source peer.
We could think of the relaying peer as a service, so service
discovery method in section 4.1 could be used to locate relaying
peer. On the other side, the peer could also check whether there are
peers which could be relaying peers in its neighbor peer set.
4.2.3. How to Use Relaying Peer
A few general steps will be followed if the peer want to get the help
from the relaying peer.
1. Locating relaying peers first;
2. The peer stores the information about its chosen relaying peer in
the request and convey them to other peer which may send it
response back directly;
3. Based on whether direct connection between the peer and the
relaying peer exists or not, the peer may either send the request
directly to the relaying peer or not;
4. The destination peer will send the response to the relaying peer
which has been communicated to the destination peer in the
request.
4.3. Routing Mode
Several routing modes are often used to realize the P2PSIP
transaction. P2PSIP requests have to be routed through the overlay
by using the overlay routing states, but the responses have several
choices to return to the source peer, either directly or in the
reverse path or in a sepearte path based on the source peer ID.
In the following figure, we compare four routing modes from three
perspectives: difficulty of NAT traversal, resilient from the failure
of intermediate peers and the latency of the transaction.
+----------------+--------------+---------------------+-------------+
| Routing Mode | Difficulty | Resilient from the | Latency of |
| | of NAT | failure of | the |
| | traversal | intermediate peers | transaction |
+----------------+--------------+---------------------+-------------+
| iterative | high | high | high |
| recursive | low | high | medium |
| semi-recursive | medium | high | low |
| overlay native | low | high | high |
+----------------+--------------+---------------------+-------------+
Figure 1 the comparison of the four routing modes
Jiang, et al. Expires August 4, 2008 [Page 11]
Internet-Draft P2PSIP SEP February 2008
For iterative mode, NAT traversal is a big problem and the
transaction latency is higher. Recursive mode has little trouble in
traversing NAT, but transaction will be prolonged due to the
breakdown of any reverse connection in the reverse path. As for
overlay native mode, the response is still routed to the source peer
through the overlay and hence the transaction's latency is also high.
Semi-recursive mode has good balance between the three perspectives.
The response is returned to the source peer directly. The only
problem in the semi-recursive mode is that the response may not reach
the source peer due to the existence of NAT.
SEP takes the two routing modes from them, semi-recursive mode and
overlay native routing mode. In most cases, semi-recursive mode
works. Overlay native mode may be used once semi-recursive mode has
failed. As for NAT traversal in semi-recursive mode, SEP's solution
is for the source peer to convey some relaying peers to the
destination peer so that the destination peer could send the response
to these peers who relays the response to the source peer. Of
course, if the source peer is on the public Internet, the destination
peer could reach the source peer directly.
4.4. Flexible Routing Mechanism
Because of the heterogeneity in peers' bandwidth, processing power
and traffic load, some less powerful peers may be overloaded by
excess messages. Under this condition, the connection between the
peer with its overloaded downstream peers seems in a good state, but
its processing capability has decreased greatly. If the upstream
peer still route message to the overloaded downstream peer, the
message may be discarded or experience longer delay.
On the other hand, there are often a great number of paths between
two peers in the overlay. The peer will have several downstream
peers at hand as its candidate next hop peers when routing a specific
message. So it could choose the next hop peer based on the
downstream current status.
SEP supports status notification from the downstream peers and also
do flexible routing based on the advertised status.
4.5. End-to-end Reliability
Reliability is very important for the transaction in the peer
protocol. The transaction comprises of requests and responses.
Because peer protocol messages will be delivered to the destination
hop-by-hop, it is hard to achieve end-to-end reliability for the
transaction. The reason for this is that source peer does not know
where the destination peer is before the request really reaches the
Jiang, et al. Expires August 4, 2008 [Page 12]
Internet-Draft P2PSIP SEP February 2008
destination. So it could not rely on TCP to ensure end-to-end
reliability. Although every hop in the path could be TCP
connections, it only guarantees the reliability between the immediate
peers. The behavior of the intermediate peers may break the end-to-
end reliability, for example, dropping packets.
It seems that application retransmission mechanism is the only answer
to the end-to-end reliability. If the source peer could not receive
the response within the expected time, it could retransmit the
request. It works for the simple request-response communication.
Open issue 1: how does the source peer set the retransmission timeout
timer? Does the value used in the conventional SIP work well in P2P
case?
5. Message Syntax
SEP protocol messages comprises of two parts: message header and some
attributes expressed in a TLV style.
O Message header: it contains some information for forwarding
operations, for example, destination ID, message type and some
options; and other information used to for the source peer to match
the response with the request, including source peer ID, destination
ID, transaction ID.
O Attributes: in order to make SEP extensible, TLV-style attributes
is used to express attributes. In order to support new operations,
we are not only able to add new messages, but able to add new
attributes. Every attribute may be composed of other attributes with
the TLV-style.
Jiang, et al. Expires August 4, 2008 [Page 13]
Internet-Draft P2PSIP SEP February 2008
5.1. Message Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|R|H|D|F|J| Reserved | Message Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Peer ID = 128bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID = 128bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (4 bit): Indicates the version of the SEP protocol. The
current version is 0x01;
R (1 bit): If it is set, used to indicate that this message is a
response.
H (1 bit): If it is set, used to indicate to the intermediate peers
that this message should be processed in terms of the message type in
addition to forwarding operation.
D (1 bit): If it is set, it indicates to the destination peer that
the source peer thinks that a direct connection SHOULD be negotiated
and established after this transaction.
F (1 bit): If it is set, it means the response should be processed in
the relay mode.
J (1 bit): If it is set, it means that it has been processed only by
the source peer.
Message type (8 bit): type of the message.
TTL (8 bit): time-to-live. It indicates the number of hops which a
message is allowed to traverse before it is discarded.
Message Length (16 bit): indicates the length of the message,
including the message header and the following variable attributes.
Transaction-ID (32 bit): It is randomly assigned by the source peer
and in order to match the response with the request.
Source Peer-ID (128 bit): indicates the Peer-ID of the source peer
Jiang, et al. Expires August 4, 2008 [Page 14]
Internet-Draft P2PSIP SEP February 2008
who initiates the request.
Destination ID (128 bit): either a destination Peer-ID or a
destination key. Its function is for the P2P overlay to get the
packet delivered to the destination peer.
5.2. Message Attribute
In this draft, we define several message attributes that are
expressed in a TLV-style.
5.2.1. TLV Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Value - variable length +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M (1 bit): It indicates that the attribute MUST be understood by the
peers who intend to process them. If the attribute could not be
understood by the processing peers, the message MUST be discarded or
return a error response.
Type (8 bit): It indicates the type of the attribute.
Length (16 bit): the byte length of the attribute.
5.2.2. Peer Address Info
Attribute type: 0x00 ( to be assigned by IANA)
Jiang, et al. Expires August 4, 2008 [Page 15]
Internet-Draft P2PSIP SEP February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trans | Type | Reserved | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trans (4 bit): it indicates the type of the transport protocol. In
this draft, we define two types: 0x00(TCP), 0x01(UDP).
Type (4 bit): host (0x0), server reflexive (0x01), peer reflexive
(0x02), relayed address (0x03). The classification is the same as
that in [ICE].
Port (16bit): the port on which this peer listens for requests.
Priority (32bit): It is used by ICE procedure to sort the candidate
pair. It is computed as suggested in [ICE].
IPv4 Address: the IPv4 address of the peer.
5.2.3. Peer service capability
Attribute type: 0x01 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|S|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is to express which services the peer could provide to
the other peers. Every bit in the value is used to indicate a
specific service. In this draft, we recommend the length of this
attribute is 16 bit long and three services are defined.
N (1 bit): if N flag is set, it means the peer is behind NAT.
Otherwise the peer is on the public Internet.
S (1 bit): STUN service. If it is set, it means the peer supports
STUN service.
Jiang, et al. Expires August 4, 2008 [Page 16]
Internet-Draft P2PSIP SEP February 2008
T (1 bit): STUN relay service. When it is set, it means the peer
supports STUN relay service.
5.2.4. Peer-ID
Attribute type: 0x02 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID = 128bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-ID conveys the Peer-ID of the specific peer. The length of this
field is 128bit. Although not all DHT algorithms use 128 bit as the
length of the Peer-ID, we think that 128 bit works for all DHT
algorithms.
5.2.5. Source Peer Info
Source Peer Info is a composite attributes. It is comprised of
Peer-ID attribute, peer service capability attribute and several peer
address info attributes. This attribute carries a few source peer
related information to other peers.
Attribute type: 0x03 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer service capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jiang, et al. Expires August 4, 2008 [Page 17]
Internet-Draft P2PSIP SEP February 2008
5.2.6. Destination Peer Info
Destination Peer Info is also a composite attribute. Like the source
peer info attribute, it is also comprised of Peer-ID attribute, peer
service capability attribute and several peer address info
attributes. This attribute carries a few destination peer related
information to the source peer.
Attribute type: 0x04 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer service capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info - N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.7. Resource Info
Attribute type: 0x05 ( to be assigned by IANA)
Jiang, et al. Expires August 4, 2008 [Page 18]
Internet-Draft P2PSIP SEP February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|O|H|C| Value Type | Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Resource ID(16Bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Time(4Bytes,Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Identity(16Bytes,Optional) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Hash Code(16Bytes,Optional) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Value Content(variable length,Optional) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E (1 bit): If this bit is set, Expiration Time field MUST be
included; otherwise not.
O (1 bit): If this bit is set, Owner Identity field MUST be included;
otherwise not.
H (1 bit): If this bit is set, Hash Code field MUST be included;
otherwise not.
C (1 bit): If this bit is set, Value Content field MUST be included;
otherwise not.
Value Type: A 12-bit value, the type of application in which the
value is used. How to assign this value depends on the content to be
stored in the overlay. It will be developed in the later version.
Value length: The number of Bytes in the value.
Resource ID: A 16-byte value, the hash function result of the
resource unique property.
Expiration Time: Optional in the Resource Info, A 4-byte value
Jiang, et al. Expires August 4, 2008 [Page 19]
Internet-Draft P2PSIP SEP February 2008
indicate the expiration time of the resource object.
Owner Identity: it specifies the owner of the Resource object.
Hash Code: It is computed by hashing the resource objects. It is
used for integrity check. A resource object must be put into the
overlay with its owner identity and the hash code of the resource
object. The owner uses the owner identity and the hash code to
refresh and modify the unique resource object, because a user may put
several resource objects under the same resource ID.
Value Content: when presented, its length is specified by the "Value
Length" parameter.
5.2.8. Negotiation Info
Attribute type: 0x06 ( to be assigned by IANA)
This attribute is used to negotiate the transport parameters for PUT
or GET or TRANSFER operations. Its format is to be determined.
5.2.9. Response Attribute
Attribute type: 0x07 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following response codes are defined in this version.
200: Successful request;
401: Bad parameters;
402: Could not find the corresponding data;
403: The request is rejected for some reason;
5.2.10. Service Peer Info
Attribute type: 0x08 ( to be assigned by IANA)
Jiang, et al. Expires August 4, 2008 [Page 20]
Internet-Draft P2PSIP SEP February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Peers | Service Type | Max. Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-ID attribute 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Address Info attribute 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............. //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............. //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer-ID attribute N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Address Info attribute N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is also a composite attribute. It intends to collect the
reachability information of peers which could support the service
specified in the attribute.
O Num of Peers (8 bit): this field records how many peers in this
attribute. It is set to zero while the source peer creates this
attribute. The number will be modified by the intermediate peers and
destination peers when new peers are added. This attribute should be
returned to the source peer in the response from the destination
peer.
O Service type (8 bit): this field indicates which type of service
the source peer wants to know. In this draft, three service types
are recommended. They are STUN (0x00), TRUN relay (0x01) and
Relaying Peer (0x02).
O Max. Num (8 bit): this field indicates the maximum number of the
service peers what the source peer wants.
O Peer-ID attribute: this field has a type of Peer-ID attribute and
records the Peer-ID information of the peers who provides the
specified type of service.
O Peer address info attribute: this field has a type of Peer Address
Info attribute and records the transport address of the peers who
could provide the specified type of service.
Jiang, et al. Expires August 4, 2008 [Page 21]
Internet-Draft P2PSIP SEP February 2008
5.2.11. Relaying Peer Info
Attribute type: 0x09 ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Peers | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info attribute 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address Info attribute N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attributes intends to convey relaying peer information to the
peer which would return response to the source peer directly.
O Num of Peers: this field records the number of relaying peers
supplied by the source peer. It won't be changeed in transit.
O Peer Address Info attribute: this filed has a type of the Peer
Address Info attribute and records the reachability information of
the relaying peers.
5.2.12. Source Reflexive Address attribute
Attribute type: 0x0A ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Transport pro.| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is often used in the case where bootstrap peer
processes the JOIN request and record the source transport address of
the JOIN request including IP address and the port observed by
bootstrap peer. This attribute will be delivered in the request and
Jiang, et al. Expires August 4, 2008 [Page 22]
Internet-Draft P2PSIP SEP February 2008
later in response unmodified. When the Join response returns to the
bootstrap peer, it will check this attribute and make it as the
destination transport address of the JOIN response relayed by the
bootstrap peer. In this way, bootstrap peer won't keep state for the
joining peer and make the response return to the Joining peer even
though the Joining peer is behind NAT.
O Port (16 bit): the port number observed by the bootstrap peer.
O Transport Pro. : The type of transport protocol. In this draft,
two types are defined. TCP (0x00) and UDP (0x01).
O IPv4 address: the IP address observed by the bootstrap peer.
5.2.13. Routing table
Attribute type: 0x0B ( to be assigned by IANA)
The attribute format depends on detailed DHT algorithm, so its format
is TBD.
5.2.14. Status Info
Attribute type: 0x0C ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion State: indicates the current state of a peer. 0x00, a peer
which states the peer is in good condition; 0x01, which means the
peer is busy;.
5.2.15. Event Info
Attribute type: 0x0D ( to be assigned by IANA)
Jiang, et al. Expires August 4, 2008 [Page 23]
Internet-Draft P2PSIP SEP February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Type | Event Description (Variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O Event Type: Indicates that what kind of event has happened. 0x00
means the sending peer is about to leave the overlay. Others TBD.
O Event Description: give the detailed description of this event. It
is informational.
5.2.16. Update Type
Attribute type: 0x0E ( to be assigned by IANA)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Type |
+-+-+-+-+-+-+-+-+
Update Type: indicate what kind of Update operation the sending peer
want the destination peer do. 0x00 means the receiving peer should
check whether it should update its routing state; 0x01 means the
sending peer requests routing table of the receving peer.
5.2.17. Overlay Configuration Info
Attribute type: 0x0F ( to be assigned by IANA)
Jiang, et al. Expires August 4, 2008 [Page 24]
Internet-Draft P2PSIP SEP February 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of DHT Algorithms | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHT Algorithm Attribute 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHT Algorithm attribute N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other configuration parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Authentication credentials, etc.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Num of Algorithms: The length of the DHT Algorithm Attribute list (N)
The DHT Algorithm attribute is tbd, and could be dependent upon the
characteristics of each DHT and its associated hash functions.
The element MAY also contain additional configuration parameters,
such as the authentication credentials of the joining node, an
overlay ID specifying the Overlay to join (supposing that the
bootstrap server is the admitting node for several overlays), etc.
6. Peer Protocol Message
6.1. Overlay Maintenance
6.1.1. JOIN
A peer MUST learn some necessary information before it wants to join
the overlay, such as DHT algorithm, bootstrap peer list, its Peer ID,
hash algorithm used to get the key and the like. It could get that
information by enrollment procedure or some other means which is not
within the scope of this draft. In SEP, the bootstrap peer MUST be
on the public Internet.
The joining procedure follows the general rules for setting up a
session using SIP, combined with the authentication procedure: A
first message is sent, specifying the desire to join and a summary of
the joining node's capabilities; a challenge is sent back to the
sender, and a new request containing the necessary credentials is
Jiang, et al. Expires August 4, 2008 [Page 25]
Internet-Draft P2PSIP SEP February 2008
resent to the entry point to the network. Finally, a response with
the chosen communication parameters is sent to the joining node,
serving as acknowledgment.
The joining peer send an initial JOIN request to the bootstrap peer.
This initial JOIN includes the Overlay Configuration Info attribute,
containing the full list of supported DHT algorithms, in priority
order, as well as supported hash functions. Other Overlay-relevant
configuration elements MAY also be included (tbd; e.g. the
authentication credentials of the joining node). The joining node
MUST leave the Source Peer ID and Destination ID empty, since it
initially does not know its own Peer ID.
The bootstrap server, upon receiving the JOIN message, checks the
Overlay Configuration Info element and compares it with the actual
Overlay configuration parameters. If this is the first joining node,
then the initial joining node MAY define the working parameters for
the Overlay, if the bootstrap node so allows. Otherwise, the
bootstrap node defines the working parameters. How the bootstrap
node gets this configuration information is out of the scope of this
draft. Nevertheless, manual configuration, taking into account
factors such as the application scenario, number of potential peers,
expected geographical distribution, etc. MAY be taken into account.
The bootstrap server then sends a JOIN Response to the joining node,
including the Overlay Configuration Info attribute. This attribute
MUST contain the selected set of Overlay working parameters,
including the chosen DHT algorithm and the hash function to calculate
the Peer ID.
Upon receiving the response, the joining node MUST calculate its own
Peer ID according to the hash function and the DHT algorithm. It
MUST send a second JOIN message to the bootstrap peer, filling the
Source Peer ID and the Destination ID with its own Peer ID. If the
joining peer is behind a NAT, it SHOULD set D flag in the message
header to indicate to the destination peer that they should start an
ICE negotiation with each other to find a direct connection for later
communication. Source Peer Info MUST be carried in the JOIN request.
Jiang, et al. Expires August 4, 2008 [Page 26]
Internet-Draft P2PSIP SEP February 2008
Join request =
Message Header
Overlay Configuration Info
Source Peer Info
[Relaying Peer Info]
[Source Reflexive Address]
When a peer receives JOIN request, it checks the Destination ID to
determine whether it is the destination of the join request. if it is
not, the peer forwards the message to next peer which is closer to
the destination. If the peer is the destination of the JOIN request,
the peer processes the message and sends JOIN response to the joining
peer.The destination peer often sends its routing table to the
joining peer in the response. If the destination peer learns that
source peer is behind NAT by check the Source Peer Info, it MUST set
the D flag in the response.
Join response =
Message Header
Overlay Configuration Info
Response Attribute
Destination Peer Info
[Source Reflexive Address]
[Routing Table]
In the end, the joining peer receives the response. If it is a 200
OK response, the joining peer MAY use the routing table in the
response to construct its own routing table. If the D flag is set in
the response, the joining peer SHOULD start ICE procedure to find out
a direct path between them.
JOIN operation will trigger data transfer from other peers to the
joining peer. These peers who will transfer data to the joining
peers are often the neighbors of the joining peer. After the
transfer finishes, these neighbors will update their routing table to
reflect the existence of the joining peer.
6.1.2. LEAVE
Before it leaves the overlay, a peer should transfer all the data to
other peers, and other peers should update their routing table. So
the leave process MAY include the following steps:
1. The leaving peer sends LEAVE request to its neighbor peer(s);
2. the neighbor peer(s) expands the key region and updates the
routing table;
Jiang, et al. Expires August 4, 2008 [Page 27]
Internet-Draft P2PSIP SEP February 2008
3. the leaving peer notifies its upstream peers its departure;
4. the leaving peer starts data transfer process;
5. the leaving peer and the neighbor peer work together to serve the
new requests;
6. After data transfer finishes, the leaving peer leaves the
overlay;
A leaving peer sends leave message to it's neighbor peers which
depend on the DHT algorithms in use.
Leave request =
Message Header
Source Peer Info
The peer receiving the LEAVE message SHOULD consider whether it's
responsible space in the overlay has changed due to the source peer's
leave and then expand the responsible space accordingly. If the
neighbor peer receives message, the peer MAY either reply this
request on its own if the associated data has been transferred from
the leaving peer, or lead this request to the leaving peer.
Leave response =
Message Header
Response Attribute
Destination Peer Info
When the leaving peer receives the response, it could start data
transfer operation to its neighbors and at the same time, it could
notify any of its upstream peers its departure to accelerate the
convergence of the overlay. Before the transfer finishes, the
leaving peer and its neighbors could work together to serve the
requests in the overlay. (TO DO: how they work together with various
messages is to be developed further.)
Open issue: How do the leaving peer and the neighbor peer work
together to serve the new request?
6.1.3. KEEPALIVE
KEEPALIVE message is used by a peer to make sure whether the neighbor
peers are still alive. If a peer has not received KEEPALIVE response
from the destination peer for several times, it could conclude that
the destination peer is not alive and then should start to update its
routing or neighbor table. After receiving KEEPALVIE request, the
destination peer MUST convey its status information in the KEEPALVIE
response. If a peer has received a KEEPALIVE message with a peer's
current status which shows this peer is in the busy state, the peer
SHOULD not forward packets to that congested peer until that peer
Jiang, et al. Expires August 4, 2008 [Page 28]
Internet-Draft P2PSIP SEP February 2008
reaches the normal state again.
KEEPALIVE Request =
Message Header
Source Peer Info
(preamble)
KEEPALIVE Response =
Message Header
Response Attriubute
Destination Peer Info
Status info
(postamble)
6.1.4. NOTIFY
The continuity and quality of service contributed by a peer is
concerned by the other peers in the overlay. After receiving an
indication that a specified peer is interested in the status of the
contributed service, the peer who contributed the service starts to
monitor its service status for the specified peer, and then it
informs the specified peer about the interesting service status
information through a NOTIFY message when it finds that the service
status changes (e.g. service quality degraded or service
interrupted). Those information includes: a)an event means that the
peer will leave; b)an event means that the peer is coming into
congestion state, etc.
NOTIFY message =
Message Header
Source Peer Info
[EVENT] [STATUS INFO]
When receiving notify message, peer MAY choose to update
corresponding status according to the information in the request.
Open Issue: As proposed in the section 4.4, current status
advertisement from downstream peers will be useful to ease the
congestion of the downstream peers. How do these downstream peers
measure its status? When is the right time for them to advertise the
status change?
6.1.5. UPDATE
UPDATE message is used to notify its existence in the overlay to its
neighbors or request routing table from its neighbors. The target
peers of the UPDATE request depends on the DHT algorithms. For
example, neighbor may just mean the successor or predecessor in
Jiang, et al. Expires August 4, 2008 [Page 29]
Internet-Draft P2PSIP SEP February 2008
Chord, but it means all peers in its leaf set in Pastry.
UPDATE provides two options for peers to update its own or its
neighbors routing states. One option is for the peer to notify its
existence to its neighbors. For example, after the joining peer
finished JOIN transaction in Pastry, it should notify other neighbors
to let them update its leaf set. The other option is for the peer to
request routing table from its neighbors. In Pastry, peers may want
to update its routing states after it checks some peers have been
dead. They often request routing table from its neighbors to achieve
this. Of course, SEP could support the two options in the single
UPDATE transaction.
Before UPDATE request is sent, the source peer should set the UPDATE
Type attribute to determine option type.
When the destination peer receives the UPDATE request, it first
checks the UPDATE Type. If the UPDATE is for a routing table, the
destination peer should convey the routing table according to the
request in the response.
UPDATE Request =
Message Header
Source Peer Info
Update Type
UPDATE Response =
Message Header
Response Attribute
Destination Peer Info
Update Type
[Routing-table]
6.1.6. SearchPeer
One Peer sends a SearchPeer request to find the responsible peer for
a destination ID. The destination peer information MAY be used to
maintain the overlay routing table. The source peer MAY establish a
direct connection with the destination peer. If it is the case, the
D flag MUST be set to indicate to the responsible peer they SHOULD
exchange ICE candidate for the NAT traversal. In Chord, one peer
uses SearchPeer request to lookup the responsible peer for its finger
table. The responsible peer MUST make a response to the request with
its own peer information. Current status of the responsible peer MAY
also be included in the response.
Jiang, et al. Expires August 4, 2008 [Page 30]
Internet-Draft P2PSIP SEP February 2008
SearchPeer Request =
Message Header
Source Peer Info
[Relaying Peer Info]
SearchPeer Response =
Message Header
Response Attribute
Destination Peer Info
[Status Info]
6.1.7. TRANSFER
When a peer joins or leaves the P2P overlay network, data transfer
operation will be triggered. The joining peer will be responsible
for some <key, value> pairs and the leaving node SHOULD transfer its
stored<key, value> pairs to its neighbors. When the transfer
operation takes place, the source peer does not know whether the peer
receiving the <key, value> pair is leaving the overlay or it is busy.
So SEP provides a mechanism to make both peers could negotiate some
transfer parameters and the time when will the tranfer start.
The source peer sends a TRANSFER request with the negotiation of the
range of the resource ID to be transferred and the destination peer
responds with the negotiation result by taking its current state into
account. If the the destination peer is about to leave the overlay,
it MAY reject the request and sugguest the source peer tries another
peer some time later. The destination MAY accept, redirect or deny
the transfer operation. After that, the source peer transfers
resource objects to the destination peer if the request was accepted.
Peers MAY also negotiate transport parameters, such as transport
protocol, to transfer resource objects.
TRANSFER Request =
Message Header
Source Peer Info
[Negotiation Info]
[Resource Info]
TRANSFER Response =
Message Header
Destination Peer Info
[Negotiation Info]
6.2. Data Operations
Jiang, et al. Expires August 4, 2008 [Page 31]
Internet-Draft P2PSIP SEP February 2008
6.2.1. PUT
A peer sends a PUT request to publish its resource object in the P2P
overlay. A peer may also send a PUT request to refresh or modify the
resource object. A hash code must be used with the owner identity to
identify the unique resource object under the same resource ID.
Every resource object has an owner identity to verify the owner of
the resource object and a hash code to check the integrity of the
resource object. Every resource object also has an expiration time.
One peer can refresh the resource object by modifying the expiration
time, otherwise the destination peer SHOULD remove the resource
object when it expires.
A PUT request may take the resource object within the request. A PUT
request may also include negotiation information to negotiate the
transport parameter to set up a direct connection between the source
peer and the destination peer, and then the resource object
transports through a direct connection. When the resource object
transport completes, the source peer may notify the destination peer
of the completion. When the put request is used to refresh the
resource object, there is no resource object in the request but the
resource ID, expiration time, owner identity and hash code are
needed.
PUT Request =
Message Header
Source Peer Info
[Relaying Peer Info]
Resource Info
[Negotiation Info]
PUT Response =
Message Header
Response Attribute
Destination Peer Info
[Negotiation Info]
6.2.2. GET
The source peer sends a GET message with the resource ID and content
type to retrieve the resource object. The resource objects can be
sent back with the Get response. If the size of the resource objects
is large(over some limit), the transport parameters can be negotiated
using the GET request and response to figure out the transport type
of the resource objects in a following direct connection. When the
resource objects transport completes, the source peer must notify the
destination peer of the completion.
Jiang, et al. Expires August 4, 2008 [Page 32]
Internet-Draft P2PSIP SEP February 2008
GET Request =
Message Header
Source Peer Info
[Relaying Peer Info]
Resource Info
[Negotiation Info]
GET Response =
Message Header
Response Attribute
Destination Peer Info
[Resource Info] [Negotiation Info]
6.2.3. REMOVE
A peer sends a REMOVE request to delete the resource object in the
P2P overlay network. A resource ID is used to locate in which peer
the resource object is stored. The owner identity and the hash code
is used to distinguish the resource object from others under the same
resource ID. One responsible peer should delete all information
about the resource object including replicas immediately when it
receives the remove request.
REMOVE Request =
Message Header
Source Peer Info
[Relaying Peer Info]
Resource Info
REMOVE Response =
Message Header
Response Attribute
Destination Peer Info
6.3. Additional messages
6.3.1. LookUpServicePeer
Some messages could be used to discover service peers who could
provide a specific service, for example, STUN or TURN Relay service.
Source peer MUST carry Service Peer Info in the request. In SEP, we
choose the LookUpServicePeer to collect the service peer's
information. This message will be forwarded through the overlay in a
hop-by-hop way, so intermediate peers and the destination peer could
collect the service peers based on its local knowledge of the
overlay. Every peer other than the source peer SHOULD put the
searched results in the Service Peer Info attributes which will be
returned back to the source peer.
Jiang, et al. Expires August 4, 2008 [Page 33]
Internet-Draft P2PSIP SEP February 2008
The source peer MUST insert a Service Peer Info attribute in the
request to collect service peers whose types may be STUN, STUN relay,
etc, and send it to the destination peer by choosing a given
destination ID. The source peer should specify the maximum number of
service peers in the request. If the number of peers reaches the
maximum number, the successive intermediate peer or destination peer
won't need to find satisfied peers. In the resulting Service Peer
Info attribute, none of the peer has the same Peer-ID attribute. If
the successive intermediate peer or the destination peer finds the
service peer has already been in the Service Peer Info attribute,
they MUST not be put into the Service Peer info attribute.
When the peers process LookUpServicePeer request or response, some
message-specific actions should be done in addition to basic actions
proposed in section 9.
The source peer SHOULD choose a destination ID which will determine
the path the request will traverse. The source peer SHOULD set the H
flags in the message header and put in the request a Service Peer
Info attribute which SHOULD set the maximum number of the expected
service peers. When source peer receives the response, it should
check whether Service Peer Info attribute exists. If it is, the
source peer gets service peers from it for later use.
While intermediate peers and the destination peer receive the
LookUpServicePeer request, it first checks if the number in the
Service Peer attribute reaches the maximum value. If it is not the
case, the intermediate peer should get the service type what the
source peer wants and try to search the satisfied peers in the
locally stored states. If the intermediate peer gets some service
peers, it should put it in the Service Peer info attribute. If the
number of the discovered peers equals the maximum number, they will
not be put in the attribute. At the same time, every intermediate
peer or the destination peer should guarantee that every service peer
is unique in this set.
When the destination peer generates the response, it should carry the
Service Peer attribute which is copied from the request unmodified.
In the end, the discovered service peers are learned by the source
peer by carrying them in the Service Peer Info attribute.
Jiang, et al. Expires August 4, 2008 [Page 34]
Internet-Draft P2PSIP SEP February 2008
LookUpServicePeer Request =
Message Header
Source Peer Info
Service Peer Info
[Relaying Peer Info]
LookUpServicePeer Response =
Message Header
Source Peer Info
[Service Peer Info]
7. Routing Operations
Routing operation is the basic and the important function of the peer
in the overlay. Peers choose the next hop peer for the packet
regardless of where packets are from. The packets as the input to
the routing operation may come from the upper applications in the
same peer, or from the network. But the general forwarding operation
applies to all of them.
SEP protocol takes the semi-recursive and overlay native routing
modes by considering the difficulty of NAT traversal and simultaneous
failures of the intermediate peers.
7.1. Request Routing
If the packet is a request, it should be routed through the overlay
by looking up the downstream peer based on the destination-ID in the
packet. The destination ID may be a Resource-ID or a Peer-ID which
depends on the message type.
In order to improve the reliability of the packets, SEP makes a
flexible routing decision, not only complying with the DHT
algorithms, but also based on the status of the downstream peers.
The flexible routing operations may introduce latency for the packet,
but it does improve the reliability. Certainly, the tradeoff between
the reliability and the additional latency from the additional hops
should be evaluated independently by the routing peer.
Note: if there are several candidate downstream peers at the same
level in the overlay, for example, peers in the successor list in
chord, the flexible routing operation would not introduce additional
significant latency.
The routing rules for the request are listed as follows:
Jiang, et al. Expires August 4, 2008 [Page 35]
Internet-Draft P2PSIP SEP February 2008
1. Get the destination ID from the request;
2. Check whether the peer itself is responsible for the destination
ID. If it is, then deliver the packet up to the message specific
function;
3. If it is not, get a few downstream peers closer to the
destination ID in the routing states and get their associated
processing status;
4. It is up to the implementation to decide which peer the request
will be sent to by evaluating the trade-off between the
reliability and the latency;
7.2. Response Routing
If the packet is a response, the first choice is to send the response
back to the source peer directly, because the destination peer could
get IP address of the source peer from the Peer Address Info
attribute. Due to the existence of the NAT, response MAY be returned
to source peer by using some special mechnisms. The routing behavior
on intermediate peers or destination peer is different which are
described below respectively.
7.2.1. Response Routing on the Destination Peer
1. Before the destination peer sends the response back to the source
peer, it should check the N flag of Service Capability Info to
learn whether the source peer is on the public Internet;
2. If the source peer is on the public Internet, the transport
address in the Peer address Info could be used to send the
response back directly.
3. If the source peer is behind the NAT, the destination peer checks
whether the Relaying Peer Info attribute is carried in the
request. If the destination peer has not found them, the
response should be sent back by routing through the overlay and F
flag in the message header MUST be cleared.
4. If the Relaying Peer Info is carried in the request, then
destination peer could send the response to the transport address
of these relaying peers which will relay the response to the
source peer and the F flag MUST be set. Note: destination peer
could send the response to these relaying peers parallelly or
sequentially. The response could also be returned by using
overlay native routing. It is up to the destination peer to
choose the right ways to send the response back.
7.2.2. Response Routing on the Intermediate Peer
1. The intermediate peers check the F flag in the message header
first. If it is cleared, the response SHOULD be treated via
overlay routing according to the forwarding rule described in the
Jiang, et al. Expires August 4, 2008 [Page 36]
Internet-Draft P2PSIP SEP February 2008
section 8.1.
2. If the F flag is set, it means that the response want to be
relayed by the intermediate peer to the source peer. So the
intermediate peer gets the source peer-ID and checks whether the
peer has the direct connection with the source peer.
3. If the direct connection exists, the intermediate peer sends the
response to the source peer through the established connection
with it.
4. If there is no direct connection between them, then it will check
whether Source Reflexive attribute is carried in the response.
If the Source Reflexive attribute exists, the intermediate peer
will send the response directly to the transport address recorded
in the Source Reflexive attribute;
5. If it does not exist, the intermediate peer MAY discard the
response silently. The intermediate peer also route the packet
further based on the source peer ID.
8. General Peer Behavior
A few kinds of peers are involved in the transaction, including
source peer, destination peer, intermediate peers. The request is
generated by the source peer and then forwarded through the overlay
by traversing several intermediate peers and reaches the destination
peer in the end. The response from the destination peer may either
be sent via IP routing, or forwarded by the intermediate peers
through the overlay. In this section, we give the general behavior
of the peers who plays different roles in the transaction.
8.1. Source Peer Behavior
8.1.1. Generating the Request and Sending the Request
The fields in the message header and some required attributes of the
new message MUST be determined before the message would be sent.
O Version: the current version number is 1;
O F flag: this bit MUST be cleared in the request;
O D flag: If the source peer realizes that it is behind NAT and needs
a direct connection with destination peer after this transaction
completes, the D flag MUST be set.
O H flag: If the source peer wants the intermediate peers to process
this message hop-by-hop, the H flag MUST be set.
O R flag: this bit MUST be cleared in the request.
Jiang, et al. Expires August 4, 2008 [Page 37]
Internet-Draft P2PSIP SEP February 2008
O J flag: if this is the JOIN request, it should be set.
O TTL: Every overlay MAY specify a default TTL in terms of the size
of the overlay peers. This default values MAY be obtained through
the enrollment procedure. It is up to the source peer to decide the
value of the TTL.
O Transaction ID: a 32 bit random number which is used to match the
response with the request. The method to get the transaction ID is
implementation dependent.
After the requests are generated, the routing operation described in
section 8 MUST be followed to find out who is the next peer to the
destination ID, and then send the requests directly to the next peer
by using the established control connection between them.
Source peer should keep the state for the request and wait for the
response. In order to make sure the reliability, the source peer MAY
set a retransmit timer. If the timer fires, the source peer should
send the request again until maximum retransmit times reached.
8.1.2. Processing the Response
When the peer receives a response from the network, the routing
operation will decide how to process it. If the Source Peer ID in
the response equals to the Peer ID of the routing peer, the routing
peer knows it is the destination of the response and it will deliver
the response to the upper layer and perform the message-specific
processing.
Before the message-specific processing, the peer MUST check the
message in the following rules:
1. Check the value in the TTL field whether it is zero. If it is,
dicard the response.
2. Make sure Destination Peer Info attribute and the Response
Attribute are carried in the response. If any of them
disappears, the peer MUST discard the response.
3. Extract Source Peer ID, destination ID, transaction ID and the
message type from the message header, and match them with the
pending requests. If there is no matched one, it means that the
response MAY either arrive at a wrong destination or be a delayed
response, therefore the response MUST be discarded. If there is
a matched one, the response should be processed according to the
message-specific procedure;
Jiang, et al. Expires August 4, 2008 [Page 38]
Internet-Draft P2PSIP SEP February 2008
8.2. Intermediate Peer Behavior
When the peer receives a message from the network, it first checks if
it is the destination of the message. If it is not, it plays the
intermediate peer role. For the intermediate peer, the main task is
to forward the message through the overlay or relay the messages to
their destination.
SEP introduces the hop-by-hop option which means that the
intermediate peers should perform some message-specific actions in
addition to routing operations. These message-specific actions would
provide some information which will be carried in the message and
learned by the source peer in the end. For example, source peer MAY
want to get a route log of a request, so every intermediate peer
should put itself into the request and later the route log will be
returned to source peer.
SEP also sets a J flag in the JOIN request which means that the JOIN
request has not been processed by any peer in this overlay. So when
a peer receives a JOIN request, it would take the role of the
bootstrap peer if J flag is set. What the bootstrap peer could do to
the JOIN request is to clear the J flag and get the source transport
address of the JOIN request, and then record it into the Source
Reflexive Address attribute in the request.
Intermediate peer could decide whether the message is a request or
response by only looking at the R flag in the message header.
8.2.1. Request Processing
When the intermediate peer receives a request, it first checks
whether the hop-by-hop flag is set. If it is set, it should perform
some message-specific actions according to the message type. Whether
the H flag is set or not, the basic routing operations MUST be
performed.
The intermediate peer should also check the J flag if the message is
JOIN request. If the J flag is set, the intermediate peer should do
some message-specific action. If it is not set, only basic routing
operations is performed.
The TTL should be decreased by 1 and if the result is 0, the
intermediate peer MUST discard the request.
8.2.2. Response Processing
When the intermediate peer receives a response, it should check the F
flag and determined what kinds of routing mode will be preferred by
Jiang, et al. Expires August 4, 2008 [Page 39]
Internet-Draft P2PSIP SEP February 2008
the destination peer. If F flag is set, it means the response should
be relayed by the intermediate peer; if it is not, the response
should be routed on the overlay level like what the requests are
treated.
8.3. Destination Peer Behavior
8.3.1. Request Processing
When the peer receives a request, it should consult their routing
states to decide whether it is the destination peer for the request.
If it is the destination peer, some routine checks MUST be performed
before the message-specific actions are to be performed.
1. Check whether TTL is zero. If it is, MUST discard the message;
2. Check whether the Source Peer Info attribute is in the request.
If it is absent, MUST discard the message;
8.3.2. Response Generation and Sending the Response
After processing the request, the destination SHOULD send a response
to the source peer. The rules below should be followed:
1. The Source Peer, Destination ID, message type and the transaction
ID MUST not be changed in the response. These fields should be
kept the same as the request.
2. Response Attribute MUST be included in the response;
3. Destination Peer Info MUST be included in the response.
How to send the response depends on the routing modes chosen by the
destination peer. Please refer to the section 7.2.1 for more detail.
9. NAT Traversal
The existence of NAT makes the communication between peers becomes
harder. IETF has developed a suite of tools, STUN/TURN/ICE to
address the issue. SEP intends to reuse these tools and work with
them in a harmonious way. For example, SEP provides a method to
exchange the candidate for the ICE protocol and SEP has the
capability for the peer to discover the STUN or TURN server.
An overlay is made up of the peers and the connections between peers.
Peers could reach its neighbors directly. For some operations like
GET or PUT, source peers may only request the service provided by the
destination peer and would not communicate with the destination peer
any more. In that case, the requests are delivered over the
established connections and later reach the destination peer. There
Jiang, et al. Expires August 4, 2008 [Page 40]
Internet-Draft P2PSIP SEP February 2008
is nothing needed to do to address the NAT traversal of the request.
But for the response, if it is forwarded on the overlay layer, it
also would not be interfered by the existence of the NAT for the same
reason as the request; But if it is forwarded on the IP layer, NAT
MAY fail the response. SEP introduces relaying peers to make
response go back to the source peer by traversing NAT.
For some other operations like JOIN, SearchPeer, source peers not
only request the service provided by the destination peer, but also
expect the direct connection between them. If a new peer wants to
join the overlay, it sends JOIN request to the destination peer. The
destination peer for the request must be the new peer's neighbor;
therefore they would communicate directly later. SEP provides a
method to exchange the candidates for the source peers and
destination peers and ICE could make use of them to attempt to find
out one or more candidate pairs by which they could reach each other
directly even in the presence of NAT between them.
Before a peer joins the overlay, it should initiate an enrollment
procedure. The joining peer MUST learn some bootstrap peers with
public address. These public bootstrap peers could provide STUN
service for other peers, therefore the joining peer could learn
whether it is behind NAT or not with the help from these public
bootstrap peer or some other STUN servers.
The peer MAY uses STUN protocol to detect whether it is behind the
NAT. If it is, it may need a TURN server if it is behind a p2p-
unfriendly NAT. Service peer discovery method proposed in SEP could
be used to find service peers which could provide TURN service.
Alternatively, it also could get a TURN server in other ways, for
example, from the enrollment server.
9.1. Gather ICE candidates
A peer could learn whether it is behind NAT by means of STUN. If it
is, it should gather ICE candidates and put them into the Source Peer
Info or Destination Peer Info respectively. By using these two
attributes, the source peer and the destination peer could exchange
the ICE candidates with each other and the ICE process would be
started as suggested by [ICE].
The method to gather ICE candidates is similar to that described in
[ICE]. ICE candidates are often carried by using SDP, but the Peer
Address Info is used in the SEP.
Jiang, et al. Expires August 4, 2008 [Page 41]
Internet-Draft P2PSIP SEP February 2008
9.2. Response from the Destination Peer to the Source Peer
If the source peer is on the public Internet, the response could be
sent back directly from the destination peer to the source peer. If
the source peer is behind the NAT, it should either relies on the
relaying peer to relay response or use the overlay native routing.
It should follow the routing operations described in section 7.
9.2.1. How to Make JOIN Response Return to Source Peer
JOIN message has a little difference from other message, because the
joining peer has not joined the overlay and has no neighbors at that
time. What the joining peer knows are only one or more bootstrap
peers which are required to be on the public Internet.
In order to make the JOIN response return to the source peer in the
presence of NAT, the joining peer SHOULD set the J flag in the
message header to show that the JOIN request has not been processed
by any peer in the overlay. In the meantime, the joining peer SHOULD
get the transport address of the bootstrap peer which will be the
next hop of the JOIN request and fill it into the Relaying Peer Info.
After finishing above tasks, the joining peer sends the JOIN request
to the bootstrap peer.
The bootstrap peer SHOULD check the J flag and decide whether it is
the bootstrap peer of the JOIN request. If it is the bootstrap peer,
it should record the source transport address of the JOIN request and
fill it into the Source Reflexive Address attribute. The J flag MUST
be cleared by the bootstrap peer.
When the destination peer receives the JOIN request, if the source
peer is behind NAT, sending the response by routing through the
overlay won't make sense in that the joining peer has not been known
by any peer in the overlay. So the only choice in SEP is for
destination peer to relay the response to the source peer with the
help of the relaying peer. In that case, the destination peer will
send the response directly to the relaying peer and SHOULD put the
Source Reflexive Address attribute unmodified into the response.
After the bootstrap peer (now, it plays relaying peer role) receives
JOIN response, it checks whether Source Reflexive Address attribute
is carried in the response. If it is, JOIN response will be
forwarded to the transport address which could be got from the Source
Reflexive Address. Then the JOIN response returns to the source
peer.
Jiang, et al. Expires August 4, 2008 [Page 42]
Internet-Draft P2PSIP SEP February 2008
9.3. Exchange Candidates for the Direct Communication
Some operations may require a direct connection after the associated
transaction finishes. But due to the existence of NAT, both peers
should exchange their own candidates with each other and then use ICE
to find out one or more workable candidate pairs. The transaction
before the direct connection could be used as a signaling channel to
exchange candidates. In order to achieve this, the source peer
SHOULD set the D flag in the message header if it requires a later
direct connection with the destination peer.
After exchange candidates, ICE process will be started. (TO DO: how
is SEP seamlessly integrated with the ICE process will explored in
the next version.)
10. Security Considerations
Security considerations will be dicussed in the next version.
11. IANA Considerations
+-------------------+--------------+
| Message | Message Type |
+-------------------+--------------+
| JOIN | 0 |
| LEAVE | 1 |
| KEEPALIVE | 2 |
| NOTIFY | 3 |
| UPDATE | 4 |
| SearchPeer | 5 |
| TRANSFER | 6 |
| PUT | 7 |
| GET | 8 |
| REMOVE | 9 |
| LookUpServicePeer | 10 |
+-------------------+--------------+
12. Acknowledgements
A team of guys contribute to this documents. Thanks for the effort
from Alex, Watw, Justin and Rake.
Jiang, et al. Expires August 4, 2008 [Page 43]
Internet-Draft P2PSIP SEP February 2008
13. References
13.1. Normative References
RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Offer/
Answer Protocols", Internet Draft draft-ietf-mmusic-ice (Work in
Progress).
[Concept] Bryan, D., Matthews, P., Shim, E., Willis, D., " Concepts
and Terminology for Peer to Peer SIP " Internet Draft
draft-ietf-p2psip-concepts-00 (Work in progress)
[STUN] Rosenberg, J., Huitema, C., Mahy, R., Willis, D., "Session
Traversal Utilities for (NAT) (STUN)" Internet Draft
draft-ietf-behave-rfc3489bis (Work in Progress)
[TURN] Rosenberg, J., Mahy, R., Huitema, C., "Obtaining Relay
Addresses from Simple Traversal Underneath NAT (STUN)" Internet Draft
draft-ietf-behave-turn(Work in Progress)
13.2. Informative References
[STUN Discovery] XingFeng Jiang, "A mechanism to discover STUN/TURN
nodes in P2PSIP" Internet Draft draft-jiang-p2psip-STUN-discovery
(Work in Progress)
Authors' Addresses
XingFeng Jiang
Huawei Tech.
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 210001
P.R.China
Phone: +86(25)84565468
Email: jiang.x.f@huawei.com
Jiang, et al. Expires August 4, 2008 [Page 44]
Internet-Draft P2PSIP SEP February 2008
HeWen Zheng
Huawei Tech.
Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu P.R.China
Phone: +86(25)84565467
Email: hwzheng@huawei.com
Carlos Macian Ruiz
Pompeu Fabra University
Barcelona, Passeig de la Circumval.lacio 8 08003
Spain
Phone: +34-93-5421498
Fax: +34-93-5422517
Email: carlos.macian@upf.edu
Victor Pascual Avila
Pompeu Fabra University
Barcelona, Passeig de la Circumval.lacio 8 08003
Spain
Phone: +34-93-5421561
Fax: +34-93-5422517
Email: victor.pascuala@upf.edu
Jiang, et al. Expires August 4, 2008 [Page 45]
Internet-Draft P2PSIP SEP February 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, et al. Expires August 4, 2008 [Page 46]
| PAFTECH AB 2003-2026 | 2026-04-23 04:11:32 |