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