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