Network Working Group Yongchao. Song
Internet-Draft Xingfeng. Jiang
Intended status: Standards Track Hewen. Zheng
Expires: August 25, 2008 Huawei
Hui. Deng
China Mobile
February 22, 2008
P2PSIP Client Protocol
draft-zheng-p2psip-client-protocol-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 25, 2008.
Abstract
This document defines P2PSIP client protocol, one protocol for
client-peer communication, which is used to create, implement and
maintain the services between a client and its associated peers.
Song, et al. Expires August 25, 2008 [Page 1]
Internet-Draft P2PSIP Client Protocol February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Functions . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . . 7
4.1. High-level Descriptions . . . . . . . . . . . . . . . . . 7
4.2. Messages Routing . . . . . . . . . . . . . . . . . . . . . 8
4.3. Messages Transporting . . . . . . . . . . . . . . . . . . 8
4.4. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . 8
4.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Node Capability . . . . . . . . . . . . . . . . . . . . . 10
4.7. Node Status . . . . . . . . . . . . . . . . . . . . . . . 10
5. Packets Formats . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Message Attributes . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Response Attribute . . . . . . . . . . . . . . . . . . 12
5.2.2. Status Attribute . . . . . . . . . . . . . . . . . . . 13
5.2.3. Service Capability . . . . . . . . . . . . . . . . . . 14
5.2.4. Uptime Attribute . . . . . . . . . . . . . . . . . . . 15
5.2.5. Overlay Info Attribute . . . . . . . . . . . . . . . . 15
5.2.6. Security Attribute . . . . . . . . . . . . . . . . . . 16
6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Inquire . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Join . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Notify . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.5. Leave . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.6. Put . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.8. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.9. LookUpServicePeer . . . . . . . . . . . . . . . . . . . . 25
7. Contribute Storage Capacity . . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Song, et al. Expires August 25, 2008 [Page 2]
Internet-Draft P2PSIP Client Protocol February 2008
1. Introduction
Conventional centralized function is provided by a single node using
Client/Server mode, e.g. STUN and FTP. Distributed function is
provided by many nodes using peer-to-peer mode, in this mode, each
node contributes its services to other nodes to allow the overlay
consisting of all individual nodes to collectively provide function,
e.g. P2PSIP. A node can solely provide centralized function, but it
must cooperate with other nodes to collectively provide distributed
function.
In P2PSIP, nodes participating in a P2PSIP Overlay that provides
storage and transport services to other nodes in that P2PSIP Overlay
are called P2PSIP peers. P2PSIP overlay can provision services to
nodes that participate in the overlay but don't provide distributed
transport service in the overlay, those nodes are called P2PSIP
Clients, and at the same time those P2PSIP Peers which are associated
with P2PSIP Clients and provide P2PSIP functions to P2PSIP Clients
are called Host Peers or Associated Peers. Host Peers or Associated
Peers must be P2PSIP neighbors of P2PSIP Clients. In this document,
we call P2PSIP Peer as Peer and P2PSIP Client as Client unless
special explanation.
Essentially Peers are P2PSIP overlay routing nodes, and Clients are
non-overlay-routing nodes [P2PSIP-Concepts-Terminology]. Any Peer
owns a unique identifier known as Peer-ID in P2PSIP overlay, and
P2PSIP overlay is transparent to Clients.
Peers participate in structuring P2PSIP overlay, they collectively
provide P2PSIP overlay functions - distributed storage function and
distributed transport function, the peers in the overlay collectively
run a distributed database algorithm. Clients participate in the
P2PSIP overlay, but they are unable or unwilling to provide
distributed storage function or distributed transport function.
A client interacts with the P2PSIP overlay through an associated peer
(or perhaps several peers) using the client protocol. The client
does not run the distributed database algorithm, and is not involved
in routing messages to other peers or clients. Through interactions
with its associated peer, a client can insert, modify, examine, and
remove resource records.
What services a client can contribute to the overlay can be found in
the client draft[I-D.pascual-p2psip-clients]. We support the
function that a client can contribute its storage space to its
associated peer in our p2psip client protocol. It can be easily
realized by sending a PUT or Get message from a peer to its
associated client after receiving knowleadge of the contributable
Song, et al. Expires August 25, 2008 [Page 3]
Internet-Draft P2PSIP Client Protocol February 2008
storage space from its associated client.
P2PSIP client protocol is used to create, implement and maintain the
services between a client and its associated peer.
One communication protocol known as "P2PSIP Peer protocol" is used to
create and maintain all participant peers topology and distributed
function in the overlay, i.e., to share information and organize
P2PSIP overlay network. It has been agreed that the client protocol
is a functional subset of the P2P Peer Protocol, but may differ in
syntax and protocol implementation (i.e., may not be syntactically
related).
This document defines the P2PSIP client protocol basing on one P2PSIP
peer protocol "Service Extensible P2P Peer Protocol" [I-D. jiang-
p2psip-sep], i.e. the defined P2PSIP client protocol reuses the
P2PSIP peer protocol if possible, and certainly they may be different
in syntax.
2. Overview of Functions
P2PSIP client protocol is used to communicate between a client and
its associated peer depicted as Figure 1, the peer Q is not coupled
with SIP entity such as SIP UA, SIP proxy or SIP redirector, but the
client C is coupled with SIP UA, and the client C uses P2PSIP client
protocol to retrieve the callee's contact info from P2PSIP overlay
through Peer Q.
Song, et al. Expires August 25, 2008 [Page 4]
Internet-Draft P2PSIP Client Protocol February 2008
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # P2PSIP
| E | A | F | +---------+ # Client
| | T | | # Protocol
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |=====/ UA \
+------+ A P2PSIP Overlay | Peer | /Client\
| | T | Q | |___C__|
| UA | N | |
| Peer | A +-------+
| D | T #
| | N #
+------+ A # P2PSIP
# T # Peer
# N +-------+ +-------+ # Protocol
# A | | | | #
#########T####| Proxy |########| Redir |#######
N | Peer | | Peer |
A | P | | R |
T +-------+ +-------+
| /
| SIP /
\__/ / /
/\ / ______________/ SIP
/ \/ /
/ UA \/
/______\
SIP UA A
Figure1 P2PSIP Overlay Reference Model
P2PSIP client protocol:
O Provides a bootstrap mechanism for clients to join the overlay. A
centralized bootstrap server mechanism is proposed in this draft.
O Provides mechanisms for clients to create, maintain and terminate
service relationship with the selected associated peer.
O Provides a mechanism for clients to publish/retrieve resource
records to/from the overlay through its associated peer.
Song, et al. Expires August 25, 2008 [Page 5]
Internet-Draft P2PSIP Client Protocol February 2008
O Provides a mechanism for clients to get candidate associated peers
through its now associated peer. Any peer that is willing to be a
candidate associated peer advertise its service in the
overlay(SEP[I-D. jiang-p2psip-sep] provides a general service
advertisement and lookup mechanism). A client sends a
LookUpServicePeer request to find its candidate associated peers.
O Provides a notification mechanism for a client to choose one best
service peer from its multiple associated peers. When a peer or a
client changes its status due to some reasons, it must generate a
Notify message to its associated client/peer. (Open Issue: Is there
a Primary associated Peer among a client's multiple associated peers,
a client should get service through this primary peer until it fails?
Or it is just the client's local policy to choose which peer to serve
him? ). The notification can also be used for other purposes.
O If possible and required, provides a mechanism for a peer to store/
retrieve resource records to/from its associated clients.
O If possible and required, e.g. there are many clients associated
with a same peer and communication among these clients are regular.
The peer can store the resource objects that its associated clients
published on both itself and the overlay. Then it can resolve many
requests from its associated clients locally, and if it can't, it
tries to get a result from the overlay.
3. 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 [RFC2119].
This section defines some key concepts using in this document.
Host Peer: A peer that provides P2PSIP overlay function to clients,
it is also called as "associated peer". A client can have more than
one host peer.
Host Peer Candidate: A peer that has the ability of providing P2PSIP
overlay function to clients. A client can learn multiple Host Peer
Candidates through a bootstrap server, or through its Host Peer. A
client can choose one or more Host Peer Candidate(s) to be its Host
Peer(s). It also has the name "candidate host peer", or "candidate
associated peer".
P2PSIP Overlay Services: Those distributed functions that provided
collectively by all peers in the P2PSIP overlay, such as distributed
Song, et al. Expires August 25, 2008 [Page 6]
Internet-Draft P2PSIP Client Protocol February 2008
storage function, distributed transport function.
Resource Name: A human-friendly name that unique resource, such as
URI.
The other concepts used in this document are compatible with P2PSIP
Work Group Draft "Concepts and Terminology for Peer to Peer SIP"
[I-D.ietf-p2psip-concepts].
4. Overview of Protocol
4.1. High-level Descriptions
From the viewpoint of service provision, P2PSIP client protocol
mainly meets three basic requirements:
(1).Client-peer relationship maintenance, this protocol should
provide mechanisms to maintain service relationship between a client
and its host peer;
(2).Resource publication and retrieve, this protocol should provide a
mechanism for a client to publish/retrieve resource records to/from
the overlay through its host peer, a mechanism for a peer to store
and retrieve resource records to and from its associated clients;
(3).Heterogeneous network support, this protocol should provide a
mechanism for a client to learn candidate host peers' capability and
status to select one or more appropriate peers as its host peers, a
mechanism for a peer to learn its clients' capability (i.e.,
contributable storage capacity) to enlarge its storage capability.
Multiple clients can have the same host peer and one client can also
have multiple host peers. One peer can serve more than one client
simultaneously, one client can communicate with more than one peer
simultaneously to enhance redundancy for service continuity.
P2PSIP client protocol is a request-response protocol. Requests from
clients are responded with necessary response info by its host peer
or any responsible peer in the overlay network. Requests sent
directly from a peer to its associated client are responded with
required response info by its associated client. Message routing is
described in Section 4.3.
Host peer candidates for a client are learned from its bootstrap
server or through its host peers.
A client can provide capability info such as network bandwidth,
Song, et al. Expires August 25, 2008 [Page 7]
Internet-Draft P2PSIP Client Protocol February 2008
contributable storage capacity to its host peer. A peer must provide
status info (e.g., congestion status info based on CPU utilization)
to its clients so that clients can do appropriate actions based upon
some policies to guarantee uninterrupted overlay service.
4.2. Messages Routing
A client sends requests using IP routing directly to its host peer,
the host peer returns responses using IP routing directly to the
client. The host peer tries to locally resolve the requests if
possible; it tries to get the results from the P2PSIP overlay when
failed to resolve the requests itself.
A client may require that the response from the responsible peer must
come back to it via IP routing directly, it can include its contact
address such as IP address and port in the request for this purpose.
A peer sends out a request using IP routing directly to one client,
the client dispose the request and then returns the response using IP
routing directly to the host peer.
Requests and responses are limited to between a client and its host
peer and use IP routing.
4.3. Messages Transporting
P2PSIP client protocol proposed in this document follows the messages
transporting specification defined in the SEP protocol [I-D. jiang-
p2psip-sep], e.g. they adopt the same transport layer listening port.
4.4. Enrollment and Bootstrap
When a client wishes to use the service of the overlay, it must get a
client ID from the Enrollment server. And then it must contact the
bootstrap server to get some host peer candidates information. It
inquire these host peer candidates to choose its host peers and it
get the service of the overlay from its host peers. A client can
have multiple host peers. Enrollment server and bootstrap server may
be collocated in one entity. We just propose this kind of mechanism
using centralized server for simplicity. We agree that there are
none centralized mechanisms(e.g. mDNS) for the enrollment and
bootstrap and they are very useful in the specific application
scenarios.
The enrollment and bootstrap procedure MUST address two issues. One
is to issue a client ID which does not conflict with the existing
client ID to the joining client, as for the security considerations,
some additional mechanism may be added(e.g. with a signed
Song, et al. Expires August 25, 2008 [Page 8]
Internet-Draft P2PSIP Client Protocol February 2008
certificate). The other is to learn candidate host peers information
and choose one or more to be the host peer(s).
There are some proposed methods are not based on the Bootstrap Server
Mechanism. Some of them are listed in the following:
(1).Static Locations: Some number of peers in the overlay may be
persistent and have well known addresses. These addresses could be
configured into the client application or obtained using an out-of-
band mechanism such as a web page;
(2).Cached Peers: While this mechanism cannot be used when a client
runs the first time, on subsequent attempts to join the overlay a
client might attempt to use a previously contacted host peer as a
host peer candidates;
(3).Broadcast/multicast mechanisms: Clients can use a broadcast or
another local discovery mechanism to locate the initial peers;
(4).DNS: An overlay can list well-known and capable peers in
appropriate DNS entries so that current host peers can be located by
any client when it wishes to use the overlay's service. DNS-SD
bootstrapping mechanism[I-D.garcia-p2psip-dns-sd-bootstrapping] is an
example.
When a client finds some peers as host peer candidates, it MUST
decide which of them to be the host peer(s) through the inquiry
result with each host peer candidates.
4.5. NAT Traversal
In P2PSIP, it is possible that some clients are behind NAT and some
peers are behind NAT.
If some clients are behind NAT and its host peer is reachable, NAT is
not a problem because the client can send requests to the host peer
and the response can be sent back through the host peer.
If some peers are behind NAT, the problem is how to set up a
connection between the client and the NATed host peer. STUN
[I-D.ietf-behave-rfc3489bis], TURN [I-D.ietf-behave-turn] and ICE
[I-D.ietf-mmusic-ice] can be used to solve this problem.
NAT traversal is relevant to network deployment; the implementer may
use an Enrollment Server to publish reachable contact info of peers
behind NAT. We suggest that peers with global addresses should be
preferred as candidate host peers, but peers behind NAT should also
be taken into account to ensure enough service peers.
Song, et al. Expires August 25, 2008 [Page 9]
Internet-Draft P2PSIP Client Protocol February 2008
4.6. Node Capability
The capabilities of host peer obviously impact the QoS of P2PSIP
overlay service for its clients. Clients need to learn the
capabilities of candidate host peers such as link bandwidth so that
the clients choose one or more peers with better capabilities to be
its host peers.
The capability of a client (i.e., contributable storage capacity)
directly impacts its associated peers' decision whether and how to
use clients to expand their storage capacity.
4.7. Node Status
In fact, the most important factor impacting QoS of P2PSIP overlay
service for clients is peers' status, such as congestion info, peer-
to-overlay connectivity etc.
Upon perceiving the service degrading event or the service
interruption event of host peer timely, clients can choose other
peers as host peers to keep continuous QoS of providing P2PSIP
overlay service.
5. Packets Formats
On packets formats, P2PSIP client protocol follows P2PSIP peer
protocol specification, the introduced messages adopt the same
message format with existing P2PSIP peer protocol messages, and those
message uses the common message header. Different types of messages
convey different contents according to the protocol design, and then
those different contents are described by different TLV (Type-Length-
Value) style objects combinations. Those objects are called as
"Attributes".
P2PSIP client protocol reuses messages (including format and
semantic) defined the P2PSIP peer protocol if possible, extend them
and introduce new types of messages if necessary.
5.1. Message Header
P2PSIP client protocol messages also use a common message header,
after which some TLV style attributes follow, as in the P2PSIP peer
protocol.
P2PSIP client protocol reuses the message header defined in the
P2PSIP peer protocol. At the same time it introduces two control
flags - 'C' flag and 'E' flag. The message header format is depicted
Song, et al. Expires August 25, 2008 [Page 10]
Internet-Draft P2PSIP Client Protocol February 2008
as Figure 2. Please refer to P2PSIP peer protocol [I-D.jiang-p2psip-
sep] for the detailed format of 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|C|E|Reserved | Message Type | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID = 128bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID = 128bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Message Header Format
C-flag (1 bit): If it is set, it means that this message is P2PSIP
client protocol message;
E-flag (1 bit): If it is set, it means that suppressing response
message is desirable, for example, a Notify request message from a
peer to its client can require the client to suppress response
message through setting E flag.
Source ID: If the message is generated by a peer, the source ID is
filled with the source peer ID, if the message is generated by a
client, the source ID is filled with the client ID.
This document introduces one new type of message as below:
Message Type Name
12 Inquire
If the message's final destination is the associated peer or client,
e.g. it's a Notify message, then the destination ID is filled with
the associated peer's ID or associated client's ID. If the message's
destination is a peer that responsible for the searched resource
object, e.g. it's a Get message generated by a client, then the
destination ID is filled with the resource ID of the searched
resource object.
5.2. Message Attributes
As P2PSIP peer protocol, P2PSIP client protocol message contains
zero, one or multiple Attributes which describe the specified
Song, et al. Expires August 25, 2008 [Page 11]
Internet-Draft P2PSIP Client Protocol February 2008
contents. All attributes follow P2PSIP peer protocol specification
and adopt TLV style. Please refer to P2PSIP peer protocol
[I-D.jiang-p2psip-sep] for the detailed format of Message Attributes.
This document introduces three new types of attributes as below:
Attribute Type Name
17 Uptime
18 Overlay Info
19 Security
In addition to the newly introduced Client attribute, Security
attribute, Uptime attribute and Overlay Info attribute, this document
extends the Response attribute, Status attribute, and Service
Capability attribute defined in P2PSIP peer protocol specification.
Every attribute in SEP peer protocol can also be used in P2PSIP
client protocol without change except that its meaning is not limited
only to the peer, but adapted to both peer and client.
5.2.1. Response Attribute
This document extends the Response attribute defined in the P2PSIP
peer protocol to describe the result of disposing the P2PSIP client
protocol request message.
Response attribute format is shown as Figure 3:
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 |Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response code | Response sub-code |
+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+
Figure 3 Response Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 7 (0x07);
Length (16 bits): the length in bytes of this attribute;
Response Code (16 bits): response code determined by the initiator,
this field is necessary for any response attribute;
Song, et al. Expires August 25, 2008 [Page 12]
Internet-Draft P2PSIP Client Protocol February 2008
Response Sub-Code (16 bits): response sub-code determined by the
initiator, this field is optional for one response attribute.
This document introduces new response codes as below:
Response Code Meaning
404 Authentication Required
405 Authentication Failed
406 Contributed Space Required
407 Not Found
408 Request Failed
409 Request Rejected
410 Join Request Deferred
431 Leave Request Deferred
432 Overlay Service Interrupt
433 Message Too Large
434 Unrecognized message type
435 Unrecognized object type
436 Request Timeout
5.2.2. Status Attribute
This document extends the Response attribute defined in the P2PSIP
peer protocol to describe the status of a peer (e.g., congestion, or
overlay service interrupt).
Status attribute format is shown as Figure 4:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Status Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 12 (0x0C);
Length (16 bits): the length in bytes of this attribute;
Status Code (16 bits): indicates the current state of a peer. The
value 0x00 means that the peer is in good condition; the value 0x01
Song, et al. Expires August 25, 2008 [Page 13]
Internet-Draft P2PSIP Client Protocol February 2008
means that the peer is busy.
This document introduces a new type of status codes as below:
Status Code Meanings
2 Overlay Service Interrupt
5.2.3. Service Capability
This document extends the Peer Service Capability attribute defined
in the P2PSIP peer protocol to describe the service capability of a
peer or a client (e.g., provide the service of a TURN server, or a
client can contribute certain space of storage to the associated peer
).
Service capability attribute format is shown as Figure 5:
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|H|C| Reserved | Contributable Storage Space |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contributable Storage Space |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Service Capability attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 0x01;
Length (16 bits): the length in bytes of this attribute;
N (1 bit): if N flag is set, it means the node is behind NAT.
Otherwise the node is on the public Internet.
S (1 bit): STUN service. If it is set, it means the peer supports
STUN service.
T (1 bit): STUN relay service. When it is set, it means the peer
supports STUN relay service.
H(1 bit): Host peer service. If this bit is set, it means that the
Song, et al. Expires August 25, 2008 [Page 14]
Internet-Draft P2PSIP Client Protocol February 2008
peer supports host peer service, it can be chosen as a host peer
candidate.
C(1 bit): Contributable storage. If it is set, the size of storage
space(32bits integer in bytes) that the client can provide to its
associated peer is following the reserved field.
5.2.4. Uptime Attribute
This document introduces a new type of attribute to describe the
uptime of a node, this attribute is called as "Uptime attribute", and
its format is shown as Figure 6:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime(seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Uptime Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 17 (0x11);
Length (16 bits): the length in bytes of this attribute;
Uptime (16 bits): the uptime of the node in seconds.
5.2.5. Overlay Info Attribute
This document introduces a new type of attribute to describe the
information of the overlay network which a peer participates in or a
client wants to access, this attribute is called as "Overlay Info
attribute", and its format is shown as Figure 7:
Song, et al. Expires August 25, 2008 [Page 15]
Internet-Draft P2PSIP Client Protocol 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Hash algorithm | Overlay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Overlay Name (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Overlay Info Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 18 (0x12);
Length (16 bits): the length in bytes of this attribute;
Hash algorithm (8 bits): the hash algorithm used by the P2PSIP
overlay. The destination ID field of the message is the hashing
result of the resource name when the message is used to retrieve a
resource object in the overlay. 0x00 is reserved, 0x01 for SHA-1;
Overlay ID (24 bits): an identifier that uniquely identifies each
P2PSIP overlay network. This value is not human-friendly;
Overlay Name: A human-friendly name that identifies a specific P2PSIP
Overlay. This is in the format of (a portion of) a URI, but may or
may not have a related record in the DNS. This field is optional in
an Overlay Info attribute.
5.2.6. Security Attribute
This document introduces a new type of attribute to describe the
security information for a node, this attribute is called as
"Security attribute", and its header format is shown as Figure 8:
Song, et al. Expires August 25, 2008 [Page 16]
Internet-Draft P2PSIP Client Protocol 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Security Attribute Header Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Attribute Type (8 bits): the value is 19(0x13);
Length (16 bits): the length in bytes of this attribute including its
sub attributes.
A Security attribute is a composite attribute; it owns some private
sub-attribute especially for itself. This document defines several
sub-attributes for Security attribute: authentication & crypto type,
username, password, challenge.
Authentication & Crypto Type Sub-Attribute Format is shown as Figure
9:
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Crypto Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Authentication & Crypto Type Sub-Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Sub-attribute Type (8 bits): the value is 1 (0x01);
Length (16 bits): the length in bytes of this sub-attribute;
Auth Type (8 bits): authentication type. This document defines two
types of authentication: 1 for PAP; 2 for CHAP. The value Zero means
that no any authentication is required;
Crypto Type (8 bits): crypto algorithm. This document defines 2
Song, et al. Expires August 25, 2008 [Page 17]
Internet-Draft P2PSIP Client Protocol February 2008
types of crypto algorithms: 1 for DES, 2 for RC4. The value Zero
means that no any crypto algorithm is required and specified. The
crypto algorithm is used to encrypt/decrypt the P2PSIP client
protocol message over the transport layer.
Username Sub-Attribute Format is shown as Figure 10:
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Username (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 Username Sub-Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Sub-attribute Type (8 bits): the value is 2 (0x02);
Length (16 bits): the length in bytes of this sub-attribute;
Username: the human-friendly string which uniquely identifies the
P2PSIP client.
Password Sub-Attribute is shown as Figure 11:
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Password (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 Password Sub-Attribute Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Sub-attribute Type (8 bits): the value is 3 (0x03);
Length (16 bits): the length in bytes of this sub-attribute;
Song, et al. Expires August 25, 2008 [Page 18]
Internet-Draft P2PSIP Client Protocol February 2008
Password: the human-friendly password of the user.
Challenge Sub-Attribute Format is shown as Figure 12:
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 | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Challenge Sub-Object Format
M-flag: the value is 1;
Reserved (7 bits): those bits are reserved and ignored;
Sub-attribute Type (8 bits): the value is 4 (0x04);
Length (16 bits): the length in bytes of this sub-attribute;
Challenge: a non-human-friendly challenge in binary.
6. Messages
P2PSIP client protocol reuses Join, Leave, Keep-alive and Notify
messages to maintain topology, it reuses Put, Get and Remove messages
to operate resource records. It reuses LookUpServicePeer message to
look up peers or clients that can provide certain services in the
overlay(e.g. STUN server, TURN server, host peer candidates).
Besides those messages, it introduces one new type of message -
Inquire and some attributes.
Each type of message contains the request form and its response form.
The request messages are used to require the specified receiver to
dispose the specified event or provide the specified info, and the
response messages are used to return the initiator the disposal
result.
6.1. Inquire
The introduced Inquire messages are used to request capabilities
info, status info and P2PSIP overlay info of candidate host peers.
A client must generate one Inquire message to obtain service
capabilities info, status info and P2PSIP overlay info of the peer
Song, et al. Expires August 25, 2008 [Page 19]
Internet-Draft P2PSIP Client Protocol February 2008
before establishing service relationship between the client and its
host peer candidate.
Upon the receipt of an Inquire message, the peer returns directly a
response message with possible info to the client.
An Inquire request message must contain a message header; it may
contain a source peer Info attribute and a Security attribute. If
the initiator is a client, the "Peer ID" field in the Source Peer
Info is actually a Client ID, and other fields are suchlike.
Inquire request = Message Header
[Source Peer Info Attribute]
[Security Attribute]
An Inquire response message must contain a message header and a
Response attribute; it may contain a Destination Peer Info attribute
and a Status attribute.
Inquire response = Message Header
Response Attribute
[Destination Peer Info Attribute]
[Status Attribute]
6.2. Join
In this document, Join messages are reused to create service
relationship with the selected host peer.
After obtaining interesting info of candidate host peers by Inquire
messages, a client choose one or more peers as host peers according
to local policy such as capabilities of candidate host peers,
response delay of candidate host peers, then it structures and sends
out a Join message to the selected peer to setup service
relationship.
Upon the receipt of a Join message without any required
authentication info from a client, the peer may return a Join
response message with the response code "405 Authentication Required"
to require authentication info from the client, the response message
uses a Security attribute to indicate specified authentication type.
Upon the receipt of a Join message without the required contributable
storage info from a client, the peer may return a Join response
message with the response code "406 Contributed Space Required" to
require contributable storage capacity from the client.
Upon the receipt of a Join message, the peer may return a Join
Song, et al. Expires August 25, 2008 [Page 20]
Internet-Draft P2PSIP Client Protocol February 2008
response message with the response code "410 Join Request Deferred"
when the peer finds itself busy or considers other causes.
A client must provide the required authentication info in the
following Join message according to the received Security attribute
in the response message with the response code 405.
A client must provide contributable storage capacity info in the
following Join message according to the received response message
with the response code 406.
A client may resend another Join message after the specified interval
according to the received response message with the response code
410.
After receiving a Join message from a client, the peer returns a Join
response message with the response code "200 OK" when the peer is
ready to serve the client.
A Join request message must contain a message header and a Source
Peer Info attribute; it may contain a Security attribute and an
Overlay Info Attribute.
Join request = Message Header
Source Peer Info Attribute
[Security Attribute]
[Overlay Info Attribute]
A Join response message must contain a message header and a Response
attribute; it may contain a Destination Peer Info attribute.
Join response = Message Header
Response Attribute
[Destination Peer Info Attribute]
6.3. Keep-alive
In this document, Keep-alive messages are sent out periodically to
check the availability for a client and its host peers, especially
when one or more nodes are behind NAT. Certainly any other P2PSIP
client messages can be used to check the availability, the keep-alive
timer between two immediate nodes (i.e., a client and its host peer)
can be heuristics.
A Keep-alive request message must contain a message header; it may
contain a Status attribute and a Source Peer Info attribute.
Song, et al. Expires August 25, 2008 [Page 21]
Internet-Draft P2PSIP Client Protocol February 2008
Keep-alive request = Message Header
[Status Attribute]
[Source Peer Info Attribute]
A Keep-alive response message must contain a message header; it may
contain a Status attribute a Destination Peer Info attribute.
Keep-alive response = Message Header
[Status Attribute]
[Destination Peer Info Attribute]
6.4. Notify
In this document, Notify messages are reused to announce the host
peer's event such as the congestion event or the overlay connection
unexpected disruption event.
A client concerns about the continuity and quality of P2PSIP overlay
service provided by its host peer. A client may access multiple
peers to enhance redundancy of P2PSIP overlay service, and at the
same time a client expresses implicitly its interest in monitoring
the status of P2PSIP overlay service provided by its host peer
through a Join message. After a client joins the overlay, the
associated peer monitors its service status for this client. When
the peer finds that the service status changes (e.g. congested or its
overlay connection disrupted by itself or others), the peer sends out
a Notify message to tell its client the service status change (e.g.
service degradation due to the congestion or the service interruption
due to the disconnection from the overlay network), the client then
choose other appropriate peers as host peers to avoid impacting
negatively the continuity and quality of P2PSIP overlay service.
A Notify request may indicate that the response is suppressed.
A Notify request must contain a message header and a Status
attribute.
Notify request = Message Header
Status Attribute
A Notify response message must contain a message header and a
Response attribute.
Song, et al. Expires August 25, 2008 [Page 22]
Internet-Draft P2PSIP Client Protocol February 2008
Notify response = Message Header
Response Attribute
6.5. Leave
In this document, Leave message are reused to tell the host peer that
the client wants to terminate the service relationship between the
client and the peer.
Before sending out a Leave message, a client may use Remove messages
to remove the published resource records by itself through the host
peer.
The host peer returns a Leave response message with the response code
"200 OK" if it is ready for the client's leave. If the client
contributes its storage space to the host peer, the host peer need
retrieve those resource records stored in the contributed storage
space of the client before the client leave.
Upon the receipt of a Leave response message with the response code
"409 Leave Request Deferred", the client may resend out another Leave
message after some time.
A Leave request message must contain a message header; it may contain
a Source Peer Info attribute.
Leave request = Message Header
[Source Peer Info Attribute]
A Leave response message must contain a message header and a Response
attribute.
Leave response = Message Header
Response Attribute
6.6. Put
In this document, Put messages are used to insert and modify resource
records between a client and its host peer.
A client uses Put messages to insert and modify the resource records
through its host peer. A peer uses Put messages to transfer resource
records to the client, update the transferred resource records on the
client.
The resource records should be deleted when it expires.
A host peer may locally cache the resource records published by its
Song, et al. Expires August 25, 2008 [Page 23]
Internet-Draft P2PSIP Client Protocol February 2008
clients, and then the host peer prefers locating the resource records
first locally on itself than in the overlay when receiving the
consequent requests for the resource records from its other clients,
at last the host peer returns the requested resource records within
the response messages, it is more effective especially for local
communication between clients served by the same host peer.
A Put request message must contain a message header and a Resource
Info attribute. It may contain a Source Peer Info attribute.
Put request = Message Header
Resource Info Attribute
[Source Peer Info Attribute]
[Destination Info Attribute]
A Put response message must contain a message header and a Response
attribute.
Put response = Message Header
Response Attribute
6.7. Remove
In this document, Remove messages are used to remove resource records
between a client and its host peer.
A client uses Remove messages to remove the resource records through
its host peer. A peer uses Remove messages to remove resource
records to the client.
A Remove message should remove cached resource records published by
clients on a peer.
A Remove request message must contain a message header and a Resource
Info attribute. It may contain a Source Peer Info attribute.
Remove request = Message Header
Resource Info Attribute
[Source Peer Info Attribute]
A Remove response message must contain a message header and a
Response attribute.
Song, et al. Expires August 25, 2008 [Page 24]
Internet-Draft P2PSIP Client Protocol February 2008
Remove response = Message Header
Response Attribute
6.8. Get
In this document, Get messages are reused to retrieve the specified
resource records.
A client uses Get messages to obtain the specified resource record
from the P2PSIP overlay through the host peer. A peer uses Get
messages to obtain the specified resource record from its clients.
A Get request message must contain a message header and a Resource
Info attribute. It may contain a Source Peer Info attribute.
Get request = Message Header
Resource Info Attribute
[Source Peer Info Attribute]
A Get response message must contain a message header, a Response
attribute and a Resource Info attribute.
Get response = Message Header
Response Attribute
Resource Info Attribute
6.9. LookUpServicePeer
As the SEP peer protocol, a client sends a LookUpServicePeer request
to its associated peer to lookup peers that have the certain service
capability in the overlay, e.g. STUN server, TURN server and so on.
A client can also get its host peer candidates with this request.
A LookUpServicePeer request must contain a message header and a
Service Peer Info attribute.
LookUpServicePeer Request = Message Header
Service Peer Info
Source Peer Info
A LookUpServicePeer response must contain a message header and a
Source Peer Info. If service peers are found in the overlay, the
result is returned to the source peer with a Service Peer Info
attribute.
Song, et al. Expires August 25, 2008 [Page 25]
Internet-Draft P2PSIP Client Protocol February 2008
LookUpServicePeer Response = Message Header
Source Peer Info
[Service Peer Info]
7. Contribute Storage Capacity
Some strong P2PSIP clients may be able and willing to share storage
pressure for its host peer, but those clients do not run distributed
database algorithm, they only simply contribute their storage
capacity for host peers.
When a client joins its host peer, the client tells the peer its
contributable storage capacity in the Join message. If a Join
message does not carry this info, the peer can return a Join response
message with the response code "406 Contributed Space Requested" to
require this info in the following Join message.
A peer uses Put message to store resource records into its clients;
the clients return results with Put response messages.
A peer uses Resource-ID through Get messages to retrieve resource
records from its clients; the clients return results with Get
response messages.
8. Acknowledgments
Some of the consideration in the draft came from the discussion in
the P2PSIP mailing list. Thanks to Spencer Dawkins, Victor Pascual.
9. Security Considerations
We can't complete all security considerations section in this
revision, but in at least some application scenarios, client
vulnerability to peers would be of concern to a network operator, and
the current version focuses on peer vulnerabilities to clients.
Currently those threats from clients mainly include:
(1).DoS Attack
DoS attack appears on the host peer when malicious clients send out
Inquire or Join messages to the host peer simultaneously. It may be
weakened using some enrollment control, but there is no any efficient
method to resolve it.
Song, et al. Expires August 25, 2008 [Page 26]
Internet-Draft P2PSIP Client Protocol February 2008
(2).Cheat Attack
Cheat attack appears on the host peer when malicious clients
counterfeit authenticated clients. One method to resolve this
problem is to use encryption to keep communication privacy.
10. IANA Considerations
Message Type: this document introduces a new type of message as
below:
Message Type Name
12 Inquire
Attribute Type: this document introduces two new types of attributes
as below:
Attribute Type Name
17 Uptime
18 Overlay Info
19 Security
Response Code: this document introduces some new response definitions
as below:
Response Code Name
404 Authentication Required
405 Authentication Failed
406 Contributed Space Required
407 Not Found
408 Request Failed
409 Request Rejected
410 Join Request Deferred
431 Leave Request Deferred
432 Overlay Service Interrupt
433 Message Too Large
434 Unrecognized message type
435 Unrecognized object type
436 Request Timeout
11. Appendix
Here is a sample of P2PSIP client protocol, depicted as Figure 13.
Client-1 Peer-1 Peer-2 Peer-3
| | | |
Song, et al. Expires August 25, 2008 [Page 27]
Internet-Draft P2PSIP Client Protocol February 2008
| (1).Inquire | | |
|------------------->| | |
| | (2).Inquire | |
|--------------------|-------------------->| |
| | | |
| (3).Response w/200 | | |
|<-------------------| | |
| | (4).Response w/200 | |
|<-------------------|---------------------| |
| | | |
| | (5).Join | |
|--------------------|-------------------->| |
| | (6).Response w/404 | |
|<-------------------|---------------------| |
| | | |
| | (7).Join | |
|--------------------|-------------------->| |
| | (8).Response w/200 | |
|<-------------------|---------------------| |
| | | |
| | (9).Put | |
|--------------------|-------------------->| |
| | | (10).Put |
| | |-------------------->|
| | | (11).Response w/200 |
| | |<--------------------|
| | (12).Response w/200 | |
|<-------------------|---------------------| |
| | | |
| | (13).Get | |
|--------------------|-------------------->| |
| | (14).Get | |
| |<--------------------| |
| | (15).Response w/200 | |
| |-------------------->| |
| | (16).Response w/200 | |
|<-------------------|---------------------| |
| | | |
| | (17).Keep-alive | |
|--------------------|-------------------->| |
| | (18).Response w/200 | |
|<-------------------|---------------------| |
| | | |
| | (19).Keep-alive | |
|--------------------|-------------------->| |
| | (20).Response w/200 | |
|<-------------------|---------------------| |
| | | |
Song, et al. Expires August 25, 2008 [Page 28]
Internet-Draft P2PSIP Client Protocol February 2008
| | (Congest) |
| | (21).Notify | |
|<-------------------|---------------------| |
| | (22).Response w/200 | |
|--------------------|-------------------->| |
| (23).Join | | |
|------------------->| | |
|(24).Response w/404 | | |
|<-------------------| | |
| (25).Join | | |
|------------------->| | |
|(26).Response w/200 | | |
|<-------------------| | |
| | | |
Figure 13 P2PSIP Client Protocol Sample
12. References
12.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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
2005.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", RFC 4485,
May 2006.
[I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R.,
and D. Wing, "Simple Traversal Underneath Network Address Translators
(NAT) (STUN)", draft-ietf-behave- rfc3489bis-08 (work in progress),
July 2007.
[I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for
Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress),
Song, et al. Expires August 25, 2008 [Page 29]
Internet-Draft P2PSIP Client Protocol February 2008
June 2007.
[I-D.pascual-p2psip-clients] Pascual, V., "P2PSIP Clients",
draft-pascual-p2psip-clients-01 (work in progress), February 2008.
[I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer
Protocol", draft-jiang-p2psip-sep-00 (work in progress), November
2007.
[I-D.garcia-p2psip-dns-sd-bootstrapping], "P2PSIP bootstrapping using
DNS-SD", draft-garcia-p2psip-dns-sd-bootstrapping-00(work in
progress), October 2007.
[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and C. Huitema,
"Obtaining Relay Addresses from Simple Traversal Underneath NAT
(STUN)", draft-ietf-behave-turn-04 (work in progress), July 2007.
[I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Methodology for Network Address Translator
(NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-17
(work in progress), July 2007
[I-D.bryan-p2psip-requirement] D. Bryan, "P2PSIP Protocol Framework
and Requirements", draft-bryan-p2psip-requirements-00 (work in
progress), July 2007
[P2PSIP-Concepts-Terminology] Dean Willis, "P2PSIP Concepts and
Terminology",
http://www3.ietf.org/proceedings/07jul/slides/p2psip-13.pdf, July
2007
12.2. Informative References
[I-D.bryan-p2psip-dsip] Bryan, D., "dSIP: A P2P Approach to SIP
Registration and Resource Location", draft-bryan-p2psip-dsip-00 (work
in progress), February 2007.
[I-D.bryan-p2psip-reload] Bryan, D., "REsource LOcation And Discovery
(RELOAD)", draft-bryan-p2psip-reload-00 (work in progress), June
2007.
[I-D.baset-p2psip-p2pp] S. Baset, "Peer-to-Peer Protocol (P2PP)",
draft-baset-p2psip-p2pp-00 (work in progress), July 2007.
[I-D.Jennings-p2psip-asp] C. Jennings, "Address Settlement by Peer to
Peer", draft-jennings-p2psip-asp-00 (work in progress), July 2007.
[I-D.marocco-p2psip-xpp-pcan] Marocco, E. and E. Ivov, "XPP
Song, et al. Expires August 25, 2008 [Page 30]
Internet-Draft P2PSIP Client Protocol February 2008
Extensions for Implementing a Passive P2PSIP Overlay Network based on
the CAN Distributed Hash Table", draft-marocco-p2psip-xpp-pcan-00
(work in progress), June 2007.
[I-D.matthews-p2psip-hip-hop] Cooper, E., "A Distributed Transport
Function in P2PSIP using HIP for Multi-Hop Overlay Routing",
draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007.
Authors' Addresses
Song Yongchao
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565081
Fax: +86-25-84565070
Email: melodysong@huawei.com
Jiang Xingfeng
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565079
Fax: +86-25-84565070
Email: jiang.x.f@huawei.com
Zheng Hewen
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565467
Fax: +86-25-84565354
Email: hwzheng@huawei.com
Song, et al. Expires August 25, 2008 [Page 31]
Internet-Draft P2PSIP Client Protocol February 2008
Hui Deng
China Mobile
53A, Xibianmennei Ave. Xuanwu District
Beijing 100053
P.R.China
Email: denghui@chinamobile.com
Song, et al. Expires August 25, 2008 [Page 32]
Internet-Draft P2PSIP Client Protocol 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.
Song, et al. Expires August 25, 2008 [Page 33]