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]