One document matched: draft-zheng-p2psip-client-protocol-00.txt
Network Working Group Hewen. Zheng
Internet-Draft Xingfeng. Jiang
Intended status: Standards Track Huawei Technologies
Expires: June 13, 2008 December 11, 2007
P2PSIP Client Protocol
draft-zheng-p2psip-client-protocol-00
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 June 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 peer.
Zheng & Jiang Expires June 13, 2008 [Page 1]
Internet-Draft P2PSIP Client Protocol December 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Functions . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Protocol . . . . . . . . . . . . . . . . . . . . . 6
4.1. High-level Descriptions . . . . . . . . . . . . . . . . . 6
4.2. P2PSIP Client Protocol and SIP . . . . . . . . . . . . . . 7
4.3. Messages Routing . . . . . . . . . . . . . . . . . . . . . 8
4.4. Messages Transporting . . . . . . . . . . . . . . . . . . 9
4.5. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9
4.7. Node Capability . . . . . . . . . . . . . . . . . . . . . 10
4.8. Node Status . . . . . . . . . . . . . . . . . . . . . . . 10
5. Packets Formats . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Message Attributes . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Response Attribute . . . . . . . . . . . . . . . . . . 12
5.2.2. Status Attribute . . . . . . . . . . . . . . . . . . . 13
5.2.3. Uptime Attribute . . . . . . . . . . . . . . . . . . . 14
5.2.4. Overlay Info Attribute . . . . . . . . . . . . . . . . 14
5.2.5. Client 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. Put . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.7. Remove . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.8. Get . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Contribute Storage Capacity . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Zheng & Jiang Expires June 13, 2008 [Page 2]
Internet-Draft P2PSIP Client Protocol December 2007
1. Introduction
Conventional centralized function is provided by 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 peers 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 offer storage and transport services to allow the
distributed database function and distributed transport function to
be implemented; these nodes are called as P2PSIP Peers. P2PSIP
overlay can provision P2PSIP functions to those nodes without
participating in structuring P2PSIP 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 are unable or
unwilling to participate in structuring P2PSIP overlay, they do not
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, does not store
resource records for the overlay, 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.
A client can provide centralized function such as Storage to its
associated peer if it has this ability and willing. In this
document, we only consider that a client may contribute its storage
capacity to its associated peer, this means that a client can store
Zheng & Jiang Expires June 13, 2008 [Page 3]
Internet-Draft P2PSIP Client Protocol December 2007
resource records for its associated peer. A peer which needs to
store a resource record may elect one or more of its associated
clients to store the resource record, which boosts its available
storage capacity. Note that a client can not contribute its storage
capability for other peers except its associated peers because any
client is a non-overlay-routing node and unreachable for other peers
using ID-based routing.
Peers provides distributed storage service and distributed transport
service of the overlay to clients, clients may provide centralized
storage service to associated peers, one communication protocol is
desired between clients and peers. This communication protocol is
used to create, implement and maintain the services between a client
and its associated peer, this protocol is called as "P2PSIP client
protocol".
One communication protocol known as "P2PSIP Peer protocol" between
peers is used to create and maintain an overlay of participant nodes,
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 from P2PSIP overlay through
Peer Q.
Zheng & Jiang Expires June 13, 2008 [Page 4]
Internet-Draft P2PSIP Client Protocol December 2007
--->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 is used to create, implement and maintain the
services between a client and its associated peer, it provides a
mechanism for clients to query capability of candidate associated
peers, it provides mechanisms for clients to create, maintain and
terminate service relation with the selected associated peer, it
provides a mechanism for clients to publish its resource record to
P2PSIP overlay through its associated peer, it provides a mechanism
for clients to retrieve interesting resource records from P2PSIP
overlay through its associated peer. If possible and required, it
provides mechanisms for peers to store and retrieve resource records
to and from associated clients.
Zheng & Jiang Expires June 13, 2008 [Page 5]
Internet-Draft P2PSIP Client Protocol December 2007
P2PSIP client protocol is a request-response protocol. For every
received request message from clients, the associated peer checks
whether it can accomplish this request, if it can do, then it returns
a response message directly to the client, otherwise it tries to get
a result for this request from P2PSIP overlay using P2PSIP Peer
protocol and then returns a response message containing the result
directly to the client. Certainly, a client may specify that the
response message with the required resource record must come directly
from the peer who may be not its associated peer. For every received
request message from the associated peers, a client disposes it and
returns a response message directly to the host peer.
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.
P2PSIP Overlay Services Those distributed functions that provided
collectively by all peers in the P2PSIP overlay, such as distributed
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 relation maintenance, this protocol should provide
mechanisms to maintain service relation between a client and its host
peer;
(2).Resource publication and obtainment, this protocol should provide
Zheng & Jiang Expires June 13, 2008 [Page 6]
Internet-Draft P2PSIP Client Protocol December 2007
a mechanism for clients to publish its resource record to P2PSIP
overlay through its host peer, a mechanism for clients to retrieve
its interesting resource records from P2PSIP overlay through its host
peer, a mechanism for peers to storage 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 interact with P2PSIP overlay through one peer
but clients can also communicate with multiple peers at the same
time. One peer can serve more than one client simultaneously, one
client can communicate with more than one peer simultaneously to
enhance redundancy.
P2PSIP client protocol is a request-response protocol. Request
messages from clients are responded with necessary response info by
its host peer or other peer in the P2PSIP overlay network. Request
messages from peers are acknowledge with required response info by
client directly. Message routing is described in Section 4.3.
How to discover candidate host peers for clients is outside the scope
of this specification. Some technologies to discover candidate host
peers are described in Section 4.5.
P2PSIP client protocol allows a node to provide capability info such
as network bandwidth, contributable storage capacity. This protocol
requires a peer to provide status info (e.g., congestion status info
based on CPU utilization) to its clients so that clients execute
appropriate actions basing on some policies to guarantee
uninterrupted P2PSIP overlay service.
4.2. P2PSIP Client Protocol and SIP
P2PSIP Peer protocol can not adopt SIP as the signal underlying
protocol, as one logical subset of P2PSIP peer protocol, P2PSIP
client protocol also can not adopt SIP as the signal underlying
protocol, i.e., it is impossible to extend SIP to implement P2PSIP
client protocol. In detail, considering those reasons as below, SIP
is not eligible to be chosen as the signal underlying protocol of
P2PSIP client protocol:
(1). SIP does not exist between a client and its associated peer at
some scenarios.
Zheng & Jiang Expires June 13, 2008 [Page 7]
Internet-Draft P2PSIP Client Protocol December 2007
According to P2PSIP Overlay Reference Model depicted in Figure 1,
P2PSIP client protocol runs between a peer without any SIP entity and
a client with a SIP entity, the peer does not recognize SIP protocol,
SIP is not eligible to act as the signal underlying protocol of
P2PSIP client protocol.
(2). SIP is not a general Remote Procedure Call (RPC).
A P2PSIP client protocol on top of SIP acts as a remote procedure
call (RPC) mechanism. The SIP guidelines document [RFC4485]
prohibits the use of SIP as a RPC mechanism.
(3). SIP is not a general purpose transfer protocol.
One of P2PSIP client protocol main tasks is to transfer resource
object and its content, those contents is irrelevant to SIP. SIP's
operation and the SIP guideline document [RFC4485] prohibit sending
large amounts of data unrelated to SIP's operation.
(4). SIP is not a lookup protocol.
SIP is not a lookup protocol; it relies on DNS to locate an
appropriate SIP server. Insert and lookup functionality is essential
for any P2PSIP client protocol. Using SIP as a peer-to-peer protocol
requires integrating lookup functionality into SIP which goes against
its design philosophy.
4.3. Messages Routing
A client issues request messages using IP routing directly to its
host peer, the host peer returns response messages using IP routing
directly to the client. The host peer tries to locally accomplish
the requests if possible; it tries to get the results for the
requests from the P2PSIP overlay when failing to accomplish the
requests.
A client may require that the response message must come from the
peer accomplish its request which may be not its host peer, the
client can do so in its request messages carrying info indicating
itself contact such as IP address and port.
A peer sends out a request message using IP routing directly to one
client, the client dispose the request and then returns response
message using IP routing directly to the host peer.
Request and response Messages are limited to between a client and its
host peer and use IP routing.
Zheng & Jiang Expires June 13, 2008 [Page 8]
Internet-Draft P2PSIP Client Protocol December 2007
4.4. Messages Transporting
P2PSIP client protocol proposed in this document follows the messages
transporting specification defined in the P2PSIP peer protocol [I-D.
jiang-p2psip-sep], e.g. they adopt the same transport layer listening
port.
4.5. Enrollment
When a client wishes to use existing overlay's service, it must first
locate some peers that are already participating in the overlay, and
then it gets overlay services through one peer. A client can
communicate with multiple peers at the same time. The procedure to
find a host peer for a client is called as "client enrollment".
The client enrollment procedure MUST address two issues. One is to
find some candidate host peers, and the other is to determine which
one in the candidates is to be the host peer.
Clients may use any method they choose to locate the initial host
peer candidates - the decision is outside the scope of this
specification. The following are a few of the many methods that may
be used:
(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.
When a client finds some peers as host peer candidates, it will
decide which one is to be the host peer.
4.6. NAT Traversal
In P2PSIP, it is possible that some clients are behind NAT and some
peers are behind NAT.
Zheng & Jiang Expires June 13, 2008 [Page 9]
Internet-Draft P2PSIP Client Protocol December 2007
If some clients are behind NAT and its host peer is reachable, NAT is
not a problem.
If some peers are behind NAT, the problem is how to discover and
visit directly those peers, 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 and peers behind NAT are the last
choice.
4.7. 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 as 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.8. 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 real-time feeling the service degrading event or the service
interruption event, 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
Zheng & Jiang Expires June 13, 2008 [Page 10]
Internet-Draft P2PSIP Client Protocol December 2007
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 except omitting the "Source Peer ID" field and
the "Destination ID" field, at the same time it introduces two
control flags - 'C' flag and 'E' flag. The message header format is
depicted 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
This document introduces one new type of message as below:
Message Type Name
12 Inquire
5.2. Message Attributes
As P2PSIP peer protocol, P2PSIP client protocol message contains
zero, one or multiple Attributes which describe the specified
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.
Zheng & Jiang Expires June 13, 2008 [Page 11]
Internet-Draft P2PSIP Client Protocol December 2007
This document introduces two new types of attributes as below:
Attribute Type Name
17 Uptime
18 Overlay Info
19 Client
20 Security
In addition to the newly introduced Client attribute, Security
attribute, Uptime attribute and Overlay Info attribute, this document
extends the Response attribute and Status attribute defined in P2PSIP
peer protocol specification.
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;
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:
Zheng & Jiang Expires June 13, 2008 [Page 12]
Internet-Draft P2PSIP Client Protocol December 2007
Response Code Meaning
404 Authentication Requested
405 Authentication Failed
406 Contributed Space Requested
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
means that the peer is busy.
This document introduces a new type of status codes as below:
Zheng & Jiang Expires June 13, 2008 [Page 13]
Internet-Draft P2PSIP Client Protocol December 2007
Status Code Meanings
2 Overlay Service Interrupt
5.2.3. 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime(seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 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.4. 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 6:
Zheng & Jiang Expires June 13, 2008 [Page 14]
Internet-Draft P2PSIP Client Protocol December 2007
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 6 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. A client uses original resource- name or resource-ID by
hashing the original resource-name to operate the responding resource
record. 0x00 for raw resource-name, 0x01 for SHA-1;
Overlay ID (24 bits): information that uniquely identifies each
P2PSIP overlay network within a given administrate domain. 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.5. Client Attribute
This document introduces a new type of attribute to describe the
information of a client, this attribute is called as "Client
attribute", and its format is shown as Figure 7:
Zheng & Jiang Expires June 13, 2008 [Page 15]
Internet-Draft P2PSIP Client Protocol December 2007
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|C| Ver | Resv| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contributable Storage Space (in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client IP Address (IPv4 or IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Client Attribute Format
M-flag: the value is 1;
C-flag: if set (C=1), this attribute contains "Contributable Storage
Space" field;
Ver (3 bits): the version of IP address depicted in "Client IP
address" field, 0x0 for IPv4 and 0x01 for IPv6;
Reserved (3 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;
Contributable Storage Space (32 bits): the contributable storage
space in bytes, this field is optional;
Client IP Address: the client's IP address.
A Client attribute may emerge as one composite attribute (e.g.
further combining an Overlay Info attribute describing the info of
the overlay network which the client is interested in).
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:
Zheng & Jiang Expires June 13, 2008 [Page 16]
Internet-Draft P2PSIP Client Protocol December 2007
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 20 (0x14);
Length (16 bits): the length in bytes of this attribute.
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
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
Zheng & Jiang Expires June 13, 2008 [Page 17]
Internet-Draft P2PSIP Client Protocol December 2007
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;
Password: the human-friendly password of the user.
Challenge Sub-Attribute Format is shown as Figure 12:
Zheng & Jiang Expires June 13, 2008 [Page 18]
Internet-Draft P2PSIP Client Protocol December 2007
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. 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 structure and issue one Inquire message to obtain
capabilities info, status info and P2PSIP overlay info of the peer
before establishing service relation between the client and the peer.
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 Client attribute and a Security attribute.
Zheng & Jiang Expires June 13, 2008 [Page 19]
Internet-Draft P2PSIP Client Protocol December 2007
Inquire request = Message Header
[Client 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 relation
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 relation.
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
Requested" 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 Requested" to
require contributable storage capacity from the client.
Upon the receipt of a Join message, the peer may return a Join
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.
Zheng & Jiang Expires June 13, 2008 [Page 20]
Internet-Draft P2PSIP Client Protocol December 2007
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 Client
attribute; it may contain a Security attribute and an Overlay Info
Attribute.
Join request = Message Header
Client 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. If the initiator is a client, the Keep-
alive message may contain a Client attribute; if the initiator is a
peer, it may contain a Destination Peer Info attribute.
Keep-alive request = Message Header
[Status Attribute]
[Client Attribute]
[Destination Peer Info Attribute]
A Keep-alive response message must contain a message header; it may
contain a Status attribute. If the initiator is a client, the Keep-
alive response message may contain a Client attribute; if the
initiator is a peer, it may contain a Destination Peer Info
attribute.
Zheng & Jiang Expires June 13, 2008 [Page 21]
Internet-Draft P2PSIP Client Protocol December 2007
Keep-alive response = Message Header
[Status Attribute]
[Client 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 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 its host peer using a
Join message, the 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 message may indicate that the response message is
suppressed.
A Notify message must contain a message header and a Status
attribute.
Notify request = Message Header
Status Attribute
A Notify response message must a message header and a Response
attribute.
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 relation between the client
and the peer.
Zheng & Jiang Expires June 13, 2008 [Page 22]
Internet-Draft P2PSIP Client Protocol December 2007
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 Client attribute.
Leave request = Message Header
[Client 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
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 Client attribute if the initiator
Zheng & Jiang Expires June 13, 2008 [Page 23]
Internet-Draft P2PSIP Client Protocol December 2007
is a client, and it may contain a Destination Peer Info attribute if
the initiator is a peer.
Put request = Message Header
Resource Info Attribute
[Client 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 Client attribute if the initiator
is a client, and it may contain a Destination Peer Info attribute if
the initiator is a peer.
Remove request = Message Header
Resource Info Attribute
[Client Attribute]
[Destination Info Attribute]
A Remove response message must contain a message header and a
Response attribute.
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
Zheng & Jiang Expires June 13, 2008 [Page 24]
Internet-Draft P2PSIP Client Protocol December 2007
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 Client attribute if the initiator
is a client. It may contain a Destination Peer Info attribute if the
initiator is a peer.
Get request = Message Header
Resource Info Attribute
[Client Attribute]
[Destination 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
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. Security Considerations
We think that the security threats mainly come from clients since
P2PSIP overlay service is provided by peers.
Currently those threats from clients mainly include:
Zheng & Jiang Expires June 13, 2008 [Page 25]
Internet-Draft P2PSIP Client Protocol December 2007
(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.
(2).Cheat Attack
Cheat attack appears on the hose peer when malicious clients
counterfeit authenticated clients. One method to resolve this
problem is to use encryption to keep communication privacy.
9. 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 Client
20 Security
Response Code: this document introduces some new response definitions
as below:
Zheng & Jiang Expires June 13, 2008 [Page 26]
Internet-Draft P2PSIP Client Protocol December 2007
Response Code Name
404 Authentication Requested
405 Authentication Failed
406 Contributed Space Requested
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
10. Appendix
Here is a sample of P2PSIP client protocol, depicted as Figure 13.
Client-1 Peer-1 Peer-2 Peer-3
| | | |
| (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 |
| | |<--------------------|
Zheng & Jiang Expires June 13, 2008 [Page 27]
Internet-Draft P2PSIP Client Protocol December 2007
| | (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 | |
|<-------------------|---------------------| |
| | | |
| | (Congest) |
| | (21).Notify | |
|<-------------------|---------------------| |
| | (20).Response w/200 | |
|--------------------|-------------------->| |
| (21).Join | | |
|------------------->| | |
|(22).Response w/404 | | |
|<-------------------| | |
| (23).Join | | |
|------------------->| | |
|(24).Response w/200 | | |
|<-------------------| | |
| | | |
Figure 13 P2PSIP Client Protocol Sample
11. References
11.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:
Zheng & Jiang Expires June 13, 2008 [Page 28]
Internet-Draft P2PSIP Client Protocol December 2007
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),
June 2007.
[I-D.jiang-p2psip-sep] X. Jiang, "Service Extensible P2P Peer
Protocol", draft-jiang-p2psip-sep-00 (work in progress), November
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
11.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
Zheng & Jiang Expires June 13, 2008 [Page 29]
Internet-Draft P2PSIP Client Protocol December 2007
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
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
Zheng Hewen
Huawei Technologies
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
PRC
Phone: +86-25-84565467
Fax: +86-25-84565354
Email: hwzheng@huawei.com
Jiang Xingfeng
Huawei Technologies
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
PRC
Phone: +86-25-84565468
Fax: +86-25-84565848
Email: jiang.x.f@huawei.com
Zheng & Jiang Expires June 13, 2008 [Page 30]
Internet-Draft P2PSIP Client Protocol December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Zheng & Jiang Expires June 13, 2008 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-23 20:38:32 |