P2PSIP Working Group L. Li Internet-Draft Ch. Zhang Intended status: Standards Track Y. Wang Expires: May 15, 2008 Y. Ji MINE/BUPT November 12, 2007 A SIP-based P2PSIP Client Protocol draft-li-p2psip-client-protocol-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document presents the motivation, design guidelines and high level descriptions of peer-to-peer session initiation protocol (P2PSIP) client protocol, which is spoken between P2PSIP peers and P2PSIP clients. In this document, the necessity of P2PSIP Client is identified firstly. Then, two fundamental guidelines for our design are explained in details. Following these guidelines, the design of Li, et al. Expires May 15, 2008 [Page 1] Internet-Draft SIP-based Client Protocol November 2007 proposed protocol and new extensions to existing SIP (session initiation protocol) are described. Such a SIP-based protocol not only makes itself backward-compatible with the vast existing SIP devices, but also provides extra functions to satisfy some particular requirements raised by P2PSIP. Li, et al. Expires May 15, 2008 [Page 2] Internet-Draft SIP-based Client Protocol November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Concepts and Terminologies . . . . . . . . . . . . . . . . . . 5 3. The necessity of P2PSIP Client . . . . . . . . . . . . . . . . 6 4. Our Design Guidelines . . . . . . . . . . . . . . . . . . . . 7 4.1. Why SIP-based? . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Why new SIP extensions are needed? . . . . . . . . . . . . 8 5. Client Protocol Design . . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Protocols for Accessing Services . . . . . . . . . . . . . 9 5.2.1. Accessing Services Offered by Peers . . . . . . . . . 9 5.2.2. Accessing Services Offered by Clients . . . . . . . . 9 5.3. Event Package Extension . . . . . . . . . . . . . . . . . 9 5.3.1. Event packages for clients locating services . . . . . 10 5.3.2. Event package for clients announcing services . . . . 10 6. Network Architecture . . . . . . . . . . . . . . . . . . . . . 11 7. Overview of Operations . . . . . . . . . . . . . . . . . . . . 12 8. Event Packages for P2PSIP Clients Locating Services . . . . . 13 8.1. Service Type Event Package . . . . . . . . . . . . . . . . 14 8.2. Server Peer List Event Package . . . . . . . . . . . . . . 14 8.2.1. Server Peer List . . . . . . . . . . . . . . . . . . . 15 8.3. Persistent Subscription and Immediate Fetch . . . . . . . 16 8.4. Roles in Subscription . . . . . . . . . . . . . . . . . . 16 9. Operations for P2PSIP Clients Locating Services . . . . . . . 16 9.1. Discover Service Types . . . . . . . . . . . . . . . . . . 16 9.2. Locate Server Peer . . . . . . . . . . . . . . . . . . . . 17 9.2.1. Query Server Peer List . . . . . . . . . . . . . . . . 17 9.2.2. Peers Notify the Changes of Server Peers . . . . . . . 17 9.2.3. Peers Notify Clients Before Leave . . . . . . . . . . 18 9.3. Serving Peer Selection . . . . . . . . . . . . . . . . . . 18 9.3.1. Collecting Serving Peer Candidates . . . . . . . . . . 19 9.3.2. Selecting Criteria . . . . . . . . . . . . . . . . . . 19 9.3.3. Peer instructs client to select peer . . . . . . . . . 19 10. P2PSIP Clients Publish Services . . . . . . . . . . . . . . . 20 10.1. Service Entry Event Package . . . . . . . . . . . . . . . 21 10.2. Publish Service Entries . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Li, et al. Expires May 15, 2008 [Page 3] Internet-Draft SIP-based Client Protocol November 2007 1. Introduction There are two kinds of nodes in P2PSIP, which are P2PSIP Peer and P2PSIP Client [I-D.ietf-p2psip-concepts]. However, for a long period of time, the concept of P2PSIP Client and its role have been a controversial source in the discussion of IETF P2PSIP WG. According to [I-D.ietf-p2psip-concepts], P2PSIP client is defined as a node participating in a P2PSIP Overlay that is less capable than a P2PSIP Peer in some way. Additionally, P2PSIP Client Protocol is defined as the protocol spoken between P2PSIP Clients and P2PSIP Peers. Besides the definitions, there are quite a lot pros and cons on whether the P2PSIP Client and P2PSIP Client Protocol are necessary. However, despite all these disputes, it has been agreed that P2PSIP Clients do have the ability to add, modify, inspect, and delete information in the overlay if they exist. In this document, based on the analysis of the heterogeneity among all the nodes which want to use P2PSIP services, we argue that the role of P2PSIP Client is indispensable. P2PSIP clients are suitable role for several categories of nodes, such as the nodes whose P2P module is incompatible with the existing P2PSIP overlay, the nodes which want to provide service but not willing to join in the P2P overlay, the nodes with limited computational resource, the existing SIP devices and SIP-based soft phones, etc. Section 3 explains these different cases. To make these clients capable of accessing services in P2PSIP overlay, a P2PSIP Client Protocol is needed. We come up with two basic guidelines for our design. Firstly, the proposed client protocol should be SIP-based. Secondly, new SIP extensions are needed to address the new challenges raised by P2PSIP. The reasons for such decisions are presented in Section 4. Following these guidelines, a client protocol is proposed. This client protocol is mainly based on SIP but with new SIP Event Package Extensions. The high level description on the basic operation of the proposed client protocol, the contents and operations of newly- defined SIP Event Package are also presented. Such an approach not only makes the proposed client protocol compatible with existing SIP devices but also satisfies new challenges raised by P2PSIP. The detailed design and implementation of this client protocol are still in progress. This version of draft aims at demonstrating the necessity of P2PSIP Client, exploring some new challenges for client protocol raised by P2PSIP, defining basic concepts and mechanisms used in client protocol. In the future visions, more detailed work will be presented. Li, et al. Expires May 15, 2008 [Page 4] Internet-Draft SIP-based Client Protocol November 2007 1.1. Requirements Language 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 [RFC2119]. 2. Concepts and Terminologies This section describes several key concepts used in this document. Generally speaking, the concepts and terminologies used in this document follow the definitions in [I-D.ietf-p2psip-concepts]. However, some definitions are modified and some new concepts are added. Both modified and newly-added concepts are listed as follow. o P2PSIP Client: a kind of nodes which want to use the services provided by P2PSIP overlay and MAY provide services to other nodes but can not join in P2PSIP overlay due to some reasons. Such nodes MAY be the node which supports P2PSIP but its P2P module is incompatible with the existing P2PSIP overlay, the node that is not qualified to join P2P overlay due to its limited resource, etc. The P2PSIP Client defined in this document is designed to be complied with the general agreement in [I-D.ietf-p2psip-concepts], that is to say, it do have the ability to add, modify, inspect, and delete information in the overlay. o P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients and P2PSIP Peers. It is used to provide a mechanism for exchanging information between clients and peers. Clients can use this protocol to ask their serving peers to add, modify, inspect, and delete information in the overlay on behalf of client itself. Peers can use this protocol to tell clients the information on itself, other peers, as well as the services which have been registered into P2PSIP overlay. o Server Peer: a P2PSIP Peer which is capable of providing one or more services to clients. o SIP Server Peer: Server Peer that behaves as registrar and SIP proxy. SIP server peer provides SIP service to clients. o SIP Service: Service provided by SIP server Peer. This service allows clients to create, modify, terminate sessions with other nodes. o STUN Server Peer: Server Peer that behaves as STUN server. STUN server peer provides STUN service to clients. Li, et al. Expires May 15, 2008 [Page 5] Internet-Draft SIP-based Client Protocol November 2007 o Serving Peer: a P2PSIP Peer which is offering certain types of services to client. For example, when a P2PSIP client is using a P2PSIP peer as its SIP outbound proxy, the peer is a SIP serving peer. o Associated Peer & Associated Client: The server peer(s) on which a P2PSIP client makes persistent subscription(s) of server peer list(s) are referred to as "associated peer(s)" of the client; the P2PSIP client is referred to as "associated client" of the associated peer(s). 3. The necessity of P2PSIP Client The necessity of P2PSIP Client originates from the heterogeneity among all the nodes which want or need to use P2PSIP services. Generally speaking, these nodes can be divided in to several categories which are discussed in details as follow. Firstly, the heterogeneity of P2P overlays makes P2PSIP Client necessary. For example, a P2PSIP node which only supports Chord algorithm, needs to access services of P2PSIP overlay which uses Bamboo as P2P algorithm. Due to the incompatible P2P algorithms, the Chord-based node can not join in the Bamboo-based DHT overlay. Thus the Chord-based node has to work as P2PSIP Client. The second kind of Client candidates comes from the nodes which want to provide services. For example, a conferences server wants to provide conference services to nodes in a P2PSIP system. Because the decoding, mixture and encoding of multiple media streams can be quite a heavy load for its computational resources, this conference server may choose not to join in the P2PSIP overlay. Thus, some extra resources, which would be used for the maintenance of P2P overlay if the server joined overlay, can be utilized for providing better conference services. Thirdly, the heterogeneity among P2PSIP nodes also makes P2PSIP Client necessary. In order to make P2PSIP overlay convergent and efficient, some kinds of nodes, such as fast-moving nodes, are not suitable to join the overlay. These unqualified nodes can only act as client, using services provided by P2PSIP overlay rather than joining in the overlay. The fourth kind of P2PSIP Clients come from the vast existing SIP clients, including hardware-based SIP devices and soft phones which support SIP. Obviously, these non-P2P aware SIP clients can neither join in P2PSIP overlay nor offer services. However, for smooth evolution of P2PSIP, these SIP clients must be taken into Li, et al. Expires May 15, 2008 [Page 6] Internet-Draft SIP-based Client Protocol November 2007 consideration at the beginning of P2PSIP's commercially deployment. Therefore, the backward-compatibility with traditional SIP [RFC3261] is indispensable. P2PSIP Client may be the only suitable role for these non-P2P aware SIP clients. The cases listed in this section are neither comprehensive nor exclusive; in other words, client may be needed in other scenarios. However, the comprehensive scenarios where P2PSIP Clients are necessary are out of the scope of this document. 4. Our Design Guidelines In this section, two fundamental guidelines that we follow during the design process of our proposed client protocol are presented. One states that the proposed protocol should be SIP-based; the other one is that new SIP extensions are needed. Each principle addresses one different perspective of challenges which client protocol has to face. 4.1. Why SIP-based? The first one of our guideline states that SIP is the base of newly- proposed client protocol. There are mainly two reasons for such decision. Firstly, SIP is needed because the client protocol has to meet the basic session control requirement. The client protocol must support peers registering clients' information into P2PSIP overlay and the establishment, modification and termination of sessions between client and another node within P2PSIP system. In order to satisfy such requirements, SIP is ideal due to its simplicity, flexibility, etc. In addition, SIP has been not only standardized but also widely used; therefore, using the existing well-developed SIP technologies will reduce the complexity for developers implementing the client protocol. Secondly, in order to make the proposed client protocol compatible with existing SIP devices, SIP is also indispensable. Vast SIP devices and SIP-based soft phones have already been used widely. Thus, to enlarge the user quantity quickly when P2PSIP is deployed at its initial stage, the backward-compatibility which ensures non-P2P aware SIP devices can access services provided by P2PSIP overlay is important. Li, et al. Expires May 15, 2008 [Page 7] Internet-Draft SIP-based Client Protocol November 2007 4.2. Why new SIP extensions are needed? Although the basic session control functions can be implemented by existing SIP, there are still lots of other challenges raised by new scenarios of P2PSIP. The challenges which have been identified are explained as follow. o The service reliability requirement. In RFC 3261 [RFC3261], the outbound proxy is typically manually configured on SIP UA. However, P2PSIP peers are typically unstable and ephemeral compared with SIP proxies in traditional SIP; they may leave the overlay or crash from time to time. Therefore, to ensure that clients can access services reliably even though the peers offering this service are unreliable, new SIP extensions are needed. For example, client can use SIP Event Notification Mechanism [RFC3265] to get all available server peers. If the one currently used crashed suddenly, client can switch to another available one. o The service availability requirement. As mentioned in [I-D.ietf-p2psip-concepts], some individual peers may provide extra services, for example STUN [I-D.ietf-behave-rfc3489bis] services, to the overlay or members in the overlay. To make these services accessible for clients, the client protocol MUST enable peers to tell clients what services are available and the detailed parameters for some services of client's interest. o The service efficiency requirement. Both client and peer need to operate effectively. Taking the load of peers for example, client protocol MUST enable peers indicating clients to choose other peers based on some criteria when the peer becomes overloaded. Similarly, in order to ensure the client's efficiency, the client protocol MUST allow client to choose the most suitable peer as its serving peer. The term "most suitable" can be interpreted as low RTT, high bandwidth, etc. However,the exact meaning of the term "most suitable" SHOULD be determined by the local policy of client which is out of the scope of this document o The service announcing requirements. The client protocol MAY be able to be used for announcing the services that clients offer to the P2PSIP overlay or members of the overlay. It is still an open issue that whether P2PSIP clients should provide services or not, and this issue needs further study. However, if P2PSIP clients provide services, service announcing mechanism needs to be defined in client protocol to support these services. What service P2PSIP clients may offer is still an open issue. Storage is a possible service proposed in [I-D.ietf-p2psip-concepts]. Clients may also help in bootstrap procedure of other peers and/or clients. Li, et al. Expires May 15, 2008 [Page 8] Internet-Draft SIP-based Client Protocol November 2007 All these above requirements cannot be satisfied by existing SIP and its extensions, thus new SIP extensions are needed, which become our second guideline in designing a client protocol. 5. Client Protocol Design 5.1. Overview The client protocol proposed in this document is extended from SIP protocol. Currently we define three new SIP event packages. Additional extensions may need to be added in client protocol in the future. 5.2. Protocols for Accessing Services 5.2.1. Accessing Services Offered by Peers P2PSIP overlay provides services for P2PSIP clients. P2PSIP clients access the services through P2PSIP server peers, and P2PSIP server peers behave as servers, such as SIP servers and STUN servers. Conventional SIP and related protocols allow P2PSIP clients to use the basic services provided by overlay. For example, SIP enables clients to create, modify and terminate sessions with other nodes in overlay. ICE [I-D.ietf-mmusic-ice] and STUN enable sessions to traverse NATs. P2PSIP overlay MAY provide some additional services to P2PSIP clients. To allow P2PSIP clients accessing these services, other protocols might be used between peers and clients or some extensions might be added to client protocol. 5.2.2. Accessing Services Offered by Clients P2PSIP clients MAY provide services. To allow other nodes accessing these services, other protocols might be used between peers and clients or some extensions might be added to client protocol. 5.3. Event Package Extension We define three SIP event packages to meet the requirements in P2PSIP described in 4.2. P2PSIP clients can utilize these event packages to locate services and announce services. These SIP event packages are extendable, that is to say, these extensions don't require any modification of SIP protocol implementations. Thus, they are easy to implement. Li, et al. Expires May 15, 2008 [Page 9] Internet-Draft SIP-based Client Protocol November 2007 5.3.1. Event packages for clients locating services Two event packages are defined in section 8 for clients to locate service. Operations based on these two event packages are described in section 9.These operations meet the service availability, availability and efficiency requirements described in 4.2. These operations are listed below: o Operations required by service availability. P2PSIP clients discover what services the overlay provides. P2PSIP clients locate server peers that can provide specific service. o Operations required by service reliability. P2PSIP peers notify clients the changes of server peers. P2PSIP peers notify clients before leaving. o Operations required by service efficiency. P2PSIP clients select serving peers. P2PSIP clients search desirable server peers. P2PSIP peers instruct clients to select serving peers. 5.3.2. Event package for clients announcing services An event package is defined in section 10 to meet the services announcement requirement described in 4.2. Clients can announce services based on this event packages. The details are described in section 10. Li, et al. Expires May 15, 2008 [Page 10] Internet-Draft SIP-based Client Protocol November 2007 6. Network Architecture --->PSTN +------+ +------+ +---------+ / | UA | | UA | | Gateway |-/ |------|########|------|#####|---------|######## | Peer | | Peer | | Peer G | # P2PSIP | E | | F | +---------+ # Client +------+ +------+ # Protocol # # | # # | N # # | A # # | T \__/ # +-------------+ v N / \Extended # | STUN SERVER |====A==/ \SIP UA +------+ P2PSIP Overlay |-------------| T /Client\ | UA | | Peer S | N |___B__| |------| +-------------+ A | Peer | # T | D | # +------+ # # # P2PSIP # # Peer # +-------+ +-------+ # Protocol # | Proxy | | Proxy | # ############|-------|########|-------|####### | | | | \_ / | Peer P| | Peer Q|===============/\ +-------+ +-------+ P2PSIP / \ Extended | Client / \ SIP UA | SIP Protocol +------+ \__/ / |Client| unmodified/ \ / | C | SIP UA / \ +------+ /Client\ |___A__| P2PSIP Network Reference Model Figure 1 Fig 1 illustrates the architecture of P2PSIP networks. This figure is mainly based on the "Figure: P2PSIP Overlay Reference Model" in [I-D.ietf-p2psip-concepts]. In addition, some modifications are made in order to highlight different types of P2PSIP clients and the Li, et al. Expires May 15, 2008 [Page 11] Internet-Draft SIP-based Client Protocol November 2007 P2PSIP Client Protocol. In Fig 1, each node is separated into two parts. The upper part describes the functionality of this node; while the lower part tells the node's role, client or peer. Several peers construct a P2PSIP overlay defined in [I-D.ietf-p2psip-concepts] using peer protocol. Some of these peers are coupled with SIP proxy, thus they can be used as SIP outbound proxies by clients. Some other peer may provide extra services, such as STUN/TURN services. Client does not join the P2PSIP overlay but use the services provided by P2PSIP overlay. Three types of clients are illustrated in Fig 1, which are unmodified SIP UA, extended SIP UA and extended SIP UA located behind NAT devices. Unmodified SIP UA refers to the SIP UA which do not support P2PSIP Client Protocol defined in this document. For such client, denoted as "Client A" in Fig 1, it treats "peer P", which is a peer coupled with SIP Proxy, as a SIP outbound proxy and communicate with other nodes using SIP. Extended SIP UA refers to SIP UA with extensions defined in this document to support P2PSIP client protocol. For such clients, denoted as "Client C" in Fig 1, they can get information about available alternate peers and other available services in addition to the services unmodified SIP UA can get from "peer Q". The "peer Q" is a peer support both peer protocol and client protocol. Extended SIP UA may be located behind NAT devices, for example "Client B" in Fig 1. In this case, the client itself has to be STUN/ TURN-enabled. When it starts, the client could obtain the address of "peer S", which provides STUN/TURN services. Afterwards, the client can use ICE for establishing sessions based on STUN/TURN services. 7. Overview of Operations This section represents the basic operations of the proposed client protocol. Generally speaking, these operations can be divided into two categories. The first category contains operations for accessing services, which contains the operations defined in [RFC3261]. The other category contains operations related to locating services. The first kind of operations includes, Li, et al. Expires May 15, 2008 [Page 12] Internet-Draft SIP-based Client Protocol November 2007 o SIP service operations. The client acts as SIP UA, and its serving peer acts as registrar and SIP proxy. These operations include client registering itself to peer, peer proxying client's requests, etc. These operations are defined in SIP [RFC3261] and some existing extensions. o Operations for accessing other services offered by peers. These operations need further study. o Operations for accessing the services offered by clients. These operations need further study. The second kind of operations includes but not limited to, o Client discovers available service types provided by P2PSIP overlay o Client queries the list of available server peers o Peers inform clients the changes of server peers o Peers inform clients before leaving P2PSIP overlay o Clients select serving peers o Peers instruct clients to select serving peers o Clients announce services This kind of operations needs new SIP extensions. In this document, we propose extending SIP Event Package RFC 3265 [RFC3265] to achieve this goal. The high level definition of new event packages and their operations are described in section 8,9,10. 8. Event Packages for P2PSIP Clients Locating Services As discussed above, existing protocols can not meet all the requirements of client protocol. To meet the services availability, reliability and efficiency requirements described in 4.2, two event packages are defined in this section. Operations based on these event packages are described in next section. Every server peer MUST support these extensions. But supporting these SIP extensions doesn't mean that a server peer MUST work as registrar and proxy. In this document, event packages are utilized to transfer service information and server peer information from P2PSIP peers to P2PSIP clients. A new event package called STEP (Service Type Event Li, et al. Expires May 15, 2008 [Page 13] Internet-Draft SIP-based Client Protocol November 2007 Package) is defined for transferring information about services types from P2PSIP peers to P2PSIP clients. A new event packages called SPLEP (Server Peer List Event Package) is defined for transferring information of server peers from P2PSIP peers to P2PSIP clients. This document only gives high level descriptions on the information contained in STEP and SPLEP. Separated documents SHOULD specify the formats of STEP and SPLEP in details. 8.1. Service Type Event Package A new event package called STEP (Service Type Event Package) is defined for transferring service type information from P2PSIP peers to P2PSIP clients. A STEP lists all service types that a P2PSIP overlay can provide to P2PSIP clients. A STEP also contains the overlay's overlay name. We give an example to show the information contained in a STEP as bellow: Overlay Name: example.chord Service Type List: SIP, STUN To generate STEP, peers SHOULD know all service types the overlay provides to P2PSIP clients. P2PSIP peer protocol SHOULD provide a mechanism to make peers aware of these services. This issue is out of the scope of this document. 8.2. Server Peer List Event Package A new event packages called SPLEP (Server Peer List Event Package) is defined for transferring information of server peers from P2PSIP peers to P2PSIP clients. SPLEP contains overlay name and one or more server peer list. For example: Overlay Name: example.chord Service Peer List(s): SIP server peer list, STUN server peer list Different server peer list in a SPLEP contains information of different type of server peers. Server peer list can be cataloged by the type of server peer. For example, SIP server peer list contains information of SIP server peers, and STUN server peer list contains information of STUN server peers. As a server peer MAY provide more than one type of service, a server peer's MAY be included in different types of server peer lists. By setting parameters in SUBSCRIBE message's body, a P2PSIP client can specify the type(s) of server peer list(s) that should be contained in SPLEP. Li, et al. Expires May 15, 2008 [Page 14] Internet-Draft SIP-based Client Protocol November 2007 8.2.1. Server Peer List In server peer list, the information of a server peer at least includes server peer type, service locating point, service entry (or service entries). The information of a server peer MAY include two optional attributes, weight and priority, and some service-specific information. An example of SIP server peer list is given below: +-------+----------------+----------------+------------+------------+ | Server| Service | service | Priority | Weight | | Peer | Locating Point | entries | (optional) | (optional) | | Type | | | | | | | | | | | +-------+----------------+----------------+------------+------------+ | SIP | 30.3.3.3:5060, | 30.3.3.3:5060, | 1 | 1001 | | | UDP; | UDP; | | | | | 30.3.3.3:5060, | 30.3.3.3:5060, | | | | | TCP | TCP | | | | SIP | 20.2.2.2:9060, | 20.2.2.2:9060, | 1 | 1000 | | | UDP; | UDP; | | | | | 20.2.2.2:9060, | 20.2.2.2:9060, | | | | | TCP | TCP | | | +-------+----------------+----------------+------------+------------+ Table 1: SIP sever peer list example Explanations of server peer's attributes: o Server peer type: Server peer type here is corresponded with the type of server peer list containing the server peer. For example, in a SIP server peer list, every server peer's server peer type is set to SIP. o Service entry: A service entry includes IP address, port, transfer protocol. A server peer MAY have several service entries that provide the same type of service. For example, a SIP server peer MAY provide SIP service via TCP and UDP at the same time. o Service locating point: Service locating point includes IP address, port, transfer protocol. Service locating point is the entry for P2PSIP clients subscribing STEP and SPLEP. Service locating point MAY or MAY not be the same as SIP service entry. o Weight and Priority: Weight and Priority attributes indicate a server peer's capacity and priority separately. The meanings of these attributes are similar with those in DNS SRV records RFC 2782 [RFC2782]. Both the Priority attribute and Weight attribute are numbers. The Priority attribute indicates the priority that a Li, et al. Expires May 15, 2008 [Page 15] Internet-Draft SIP-based Client Protocol November 2007 peer SHOULD be selected. Lower numeric Priority value means higher priority to be selected. The Weight attribute indicates a peer's capacity to accommodate clients. The peer with higher Weight can accommodate more clients. Peers MAY instruct clients to select serving peers by utilizing these two attributes. Priority and Weight attributes MAY be variables, and server selection MAY be dynamic. 8.3. Persistent Subscription and Immediate Fetch With SIP SUBSCRIBE/NOTIFY methods [RFC3265] or PUBLISH method [RFC3903], event packages can be transferred between SIP entities. In this document, SUBSCRIBE/NOTIFY methods are used to transfer STEP and SPLEP. SIP SUBSCRIBE/NOTIFY mechanism provides two types of subscriptions: persistent subscription and immediate fetch. An immediate fetch is a subscription expires immediately. Immediate fetch can be used to fetch current status of the event. An immediate fetch is effected by sending a SUBSCRIBE with an "Expires" header of 0. Persistent subscription lasts for some time. If subscribers make persistent subscription, notifiers will notify subscribers every time when the status of the event changes. Both persistent subscription and immediate fetch are used in this client protocol. 8.4. Roles in Subscription Every P2PSIP server peer MUST have at least one service locating point, on which P2PSIP clients can subscribe STEP and SPLEP. If a P2PSIP client subscribes STEP, SPLEP or both, it behaves as subscriber. A P2PSIP server peer MUST behave as a notifier, if any P2PSIP client subscribes STEP or SPLEP from it. 9. Operations for P2PSIP Clients Locating Services 9.1. Discover Service Types P2PSIP client can discover available service types by subscribing STEP (Service Types Event Pacakge) from P2PSIP peers. By parsing STEP, a P2PSIP client can find out all service types the overlay can provide. If the P2PSIP client wants to use any type of service among these services, it can use the way described in 8.2 to locate server peers. Li, et al. Expires May 15, 2008 [Page 16] Internet-Draft SIP-based Client Protocol November 2007 9.2. Locate Server Peer SPLEP contains information of one or more types of server peers. In SPLEP, the information of a server peer at least includes its overlay name, server peer type, service locating point, service entry (or service entries), weight and priority. By setting parameters in SUBSCRIBE message's body, a P2PSIP client can specify the type(s) of server peer list(s) that should be contained in SPLEP. By subscribing SPLEP and parsing it, P2PSIP clients can find server peers of given types and the service entries on these server peers. A P2PSIP client MAY subscribe SPLEP from several peers. A P2PSIP client MAY subscribe several types of server peer lists. A P2PSIP client MAY subscribe the same type of server peer lists from different peers. For redundancy, any server peer list in a SPLEP SHOULD contain several server peers if possible. To generate SPLEP, P2PSIP peers MUST collect information about available server peers from other peers. But a P2PSIP peer doesn't need to find all available server peers in the overlay, and it's impossible usually. These issues are out of the scope of this document. Some needed mechanisms SHOULD be defined in P2PSIP peer protocol. Immediate fetch or persistent subscription MAY be used to locate server peer. Immediate fetch and persistent subscription are used to support different operations as described in 9.2.1, 9.2.2 and 9.2.3. 9.2.1. Query Server Peer List Immediate fetch SHOULD be used for querying server peer list. P2PSIP clients MAY query server peer list occasionally. For example, a P2PSIP client seldom uses some type of service. To reduce overhead, the P2PSIP client may query this type of server peer list every time before it wants to use this type of service. 9.2.2. Peers Notify the Changes of Server Peers P2PSIP server peers are unstable, transient. They may leave or fail any time. New server peers may join the overlay anytime. If P2PSIP clients want to be notified the changes of server peers, they SHOULD make persistent subscriptions. Suppose a client make a persistent subscription on a peer. To generate SPLEP for persistent subscription, the peer MUST generate and maintain the server peer list(s) required in SPLEP. The peer MUST has the ability to detect if any server peer in the server peer list(s) leaves or any server peer (exclude itself) in the server peer list(s) fails. The leaving peer or failed peer MUST be removed from Li, et al. Expires May 15, 2008 [Page 17] Internet-Draft SIP-based Client Protocol November 2007 the server peer list(s). The peer MAY add one or more server peers in the server peer list(s) it maintains. When the server peer list(s) changes, the peer SHOULD notify its associated clients. 9.2.3. Peers Notify Clients Before Leave Persistent subscriptions are required for peer notifying clients before leave. Suppose a P2PSIP client makes persistent subscription of SPLEP from a peer. The client subscribes one or more server peer lists in the persistent subscription. Then the client can receive notification if any server peer in the server peer list(s) is about to leave. We discuss the notification in two cases: Suppose the leaving peer is not the associated peer. If the associated peer detects a peer in the server peer list(s) is about to leave, the associated peer notify the client a SPLEP from which the leaving peer is removed. Notification in this case requires the associated peer has the ability to detect if any peer in the server peer list(s) is about to leave. The detect means MAY be the leaving peer notifying the associated peer. The detect means is out of the scope of this document. Suppose the leaving peer is the associated peer. To leave gracefully, the leaving peer SHOULD inform the associated client about its leaving and terminate the subscription. This can be done by sending the associated client a SPLEP with NOTIFY method. The leaving peer is removed from the server peer list(s) in the SPLEP. To terminate subscriptions, the NOTIFY message contains a "Subscription-State" header with a value of "terminated" as described in RFC 3265 [RFC3265]. 9.3. Serving Peer Selection For some reason, such as getting better services, load balance, a P2PSIP client MAY select one or more server peers from all the reachable server peers it knows as serving peer. And other reachable server peers the P2PSIP client knows are backups of serving peers. P2PSIP clients MAY select serving peers periodically. P2PSIP clients MAY select serving peers every time before requesting services. A P2PSIP client MAY select one or more types of serving peers, such as SIP serving peer, STUN serving peer. Specific type of serving peer selection is among the same type of server peers. For example, SIP serving peer selection is among SIP server peers. In the rest of this section, if no specification, serving peer selection refers to a specific type of serving peer selection. Li, et al. Expires May 15, 2008 [Page 18] Internet-Draft SIP-based Client Protocol November 2007 9.3.1. Collecting Serving Peer Candidates For selecting serving peers, a client needs to subscribe SPLEP from one or more peers. If the client subscribes SPLEP from more peers, it MAY find more serving peer candidates. Then, it can find more backup peers and MAY find serving peers which are more desirable. If a P2PSIP client subscribes SPLEP from a peer for collecting serving peer candidates exclusively, immediate fetch SHOULD be used to reduce overhead. 9.3.2. Selecting Criteria Selecting serving peers can be based on any criteria, such as latency, SIP session success rate, instruction from server peer. The selecting criterion MAY be dynamic and MAY vary in different P2PSIP overlays. Establishing such a criterion is out of the scope of this document. 9.3.3. Peer instructs client to select peer Peers MAY or MAY not give instructions to P2PSIP clients for selecting peers. This document provides the mechanism that peers instruct clients to select peers. This mechanism can be used to distribute the requests initiated by clients among server peers. This mechanism MAY help to avoid the situation that some peers are overload, to achieve load balancing. It also MAY help clients to get better services. As avoiding overload and load balance involve many factors, other mechanisms are also needed. Except for serving clients, P2PSIP peers have other tasks such as maintaining overlay and storing data. The capacities of P2PSIP peers are also heterogeneous. Some mechanisms MAY be deployed in peer protocol for avoiding overload and load balancing. These issues are out of the scope of this document. Peers can instruct P2PSIP clients to select serving peers by utilizing Priority and Weight attributes. There are two types of instruction: strict instruction and loose instruction. o Strict instruction In strict instruction case, the criterion of selecting peers is decided by peers. P2PSIP clients receive instruction from peers and select peers strictly obeying instructions if possible. The rules of strict instruction are the same as the rules in selecting servers defined in RFC 2782 [RFC2782]. Among all the reachable peers, P2PSIP clients MUST select serving peer from the peer(s) with lowest Priority attribute (i.e. highest priority). If there are more than Li, et al. Expires May 15, 2008 [Page 19] Internet-Draft SIP-based Client Protocol November 2007 one peers with highest priority, P2PSIP clients SHOULD select according to these peers' weight attributes. Larger weights SHOULD be given a proportionately higher probability of being selected. An example is given as follow. All reachable SIP server peers a P2PSIP client knows is listed as below: +-------------------+----------+--------+ | Service Peer | Priority | Weight | +-------------------+----------+--------+ | SIP server peer A | 1 | 30 | | SIP server peer B | 1 | 20 | | SIP server peer C | 2 | 100 | +-------------------+----------+--------+ Table 2: strict instruction example As server peer A and server peer B have highest priority (lowest Priority attribute value), the serving peer must be selected from them. According to their Weight attributes, the probability of server peer A being selected should be 30/(30+20), and the probability of server peer B being selected should be 20/(30+20). From the view of peers, P2PSIP peers MAY set priority and weight attributes with the consideration of load distribution. As P2PSIP clients select peers only according to Priority and Weight attributes, P2PSIP peers MAY set Priority and Weight attributes with other considerations so that P2PSIP clients can get better services. For example, proximity-aware technologies MAY be deployed and P2PSIP clients can be instructed to select close peers. o Loose instruction In loose instruction, P2PSIP clients select peers with the considerations of other factors besides priority and weight attributes. The selection criterion is out of the scope of this document. But peers with higher priority and peers with higher capacity SHOULD have more chances to be selected. 10. P2PSIP Clients Publish Services P2PSIP clients MAY or MAY not provide some services, such as storage. This document is not intent to discuss what services P2PSIP clients SHOULD provide and how to implement these services. These services may be accessed through existing protocols or client protocol. These issues are out of the scope of this document. We only describe how to publish the services provided by P2PSIP clients, if these services exist. In this section, a new SIP event package called SEEP (Service Li, et al. Expires May 15, 2008 [Page 20] Internet-Draft SIP-based Client Protocol November 2007 Entry Event Package) is defined for transferring services information. 10.1. Service Entry Event Package A SEEP contains information of all entries of services provided by a P2PSIP client. SEEP also contains some related information, such as overlay name. In SEEP, information of a service at least includes service type, service entry (or service entries). Service-specific information and service capacity information MAY be contained in SEEP. Suppose a P2PSIP client provides storage service via FTP, the SEEP MAY look like: +------------+-----------------+------------------------------------+ | Service | Service Entry | Service-specific Information | | Type | | | +------------+-----------------+------------------------------------+ | FTP | 10.0.0.2:21,TCP | username: alice; password: | | | | PasswordOfAlice | +------------+-----------------+------------------------------------+ Table 3: SEEP example 10.2. Publish Service Entries P2PSIP clients MAY send SEEP to P2PSIP peers with SIP PUBLISH method. P2PSIP peers MAY or MAY not publish the service information of P2PSIP clients in overlay. P2PSIP clients MAY access the services provided by other clients just like access the services provided by peers. 11. IANA Considerations This document proposes several event packages, each of them need IANA considerations such as Package Name, Package or Template-Package, etc. However, because this document only provide a high level description of these event packages, the detailed description of each event package and its own IANA considerations will be defined in respective documents. Thus, no IANA consideration is listed in this document. 12. Security Considerations Although some attack and threat models and security mechanisms for SIP are proposed in RFC 3261 [RFC3261], there are still lots of security challenges which the proposed P2PSIP Client Protocol has to face. What is more, compared with Client/Server mode, the nature of Li, et al. Expires May 15, 2008 [Page 21] Internet-Draft SIP-based Client Protocol November 2007 peer-to-peer system makes it even more complicated to design a secure client protocol. Currently, we are at the initial stage of designing security mechanism for the proposed client protocol. Thus, in this version of draft the security issues are not covered. In the future version, the security considerations will be presented in a detailed way. 13. Acknowledgements The authors wish to thank Tao Ma and Zhenyu Wu for their valuable comments. In addition, the authors also quite appreciate the discussions on the topic of P2PSIP Client in the IETF P2PSIP maillist. 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. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. 14.2. Informative References [I-D.ietf-behave-rfc3489bis] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-11 (work in progress), October 2007. [I-D.ietf-mmusic-ice] Li, et al. Expires May 15, 2008 [Page 22] Internet-Draft SIP-based Client Protocol November 2007 Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress), July 2007. Authors' Addresses LiChun Li Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 China Email: lilichun@gmail.com Chunhong Zhang Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 China Email: zhangch@bupt.edu.cn Yao Wang Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 China Email: yaowang.bupt@gmail.com Yang Ji Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road BeiJing, Haidian District 100876 China Email: jiyang@bupt.edu.cn Li, et al. Expires May 15, 2008 [Page 23] Internet-Draft SIP-based Client Protocol November 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). Li, et al. Expires May 15, 2008 [Page 24]