Network Working Group Tao. Ma Internet-Draft Lichun. Li Intended status: Informational Chunhong. Zhang Expires: Nov 18, 2009 Yang. Ji Xiaofeng. Qiu MINE lab,Beijing University of Posts and Telecommunication May 25, 2009 A SIP server event package for SIP server farm draft-ma-sipping-server-event-package-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 November 18, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Ma, et al. Expires Nov 18, 2009 [Page 1] Internet-Draft SIP server event package May, 2009 Abstract This document defines the Session Initiation Protocol (SIP) server even package for SIP server farm using the SIP event framework. The SIP server event package allows clients to subscribe to the servers for server information in the server farm, and serves to communicate information with each other. Based on this, an overall view of the SIP server farm is built and delivered to the entity (including SIP phone proxy or other SIP servers) which subscribes and receives the event packages. The view would help failover and load balancing in the server farm. The event notification mechanism of SIP event framework guarantees its adaption to the dynamic changes of server state. We instantiate the usage of SIP server event package in three scenarios: client based failover, DNS based failover, load balancer based load balancing. To be added, we introduce some specific usage in Peer-to-Peer SIP(P2PSIP) and service discovery to expand and explore the potential usage space. Compared with the failover and load balancing mechanisms in traditional SIP, the new SIP event package would apply its explicit and dynamic notification mechanism to improve the efficiency and service availability of SIP server farm. This mechanism using server event package can also be a complementary way for the DNS functionality defined in RFC 3263[RFC 3263] to locate SIP servers. Ma, et al. Expires Nov 18, 2009 [Page 2] Internet-Draft SIP server event package May, 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Convention and Terminology . . . . . . . . . . . . . 5 3. SIP Server Event Package . . . . . . . . . . . . . . . . . . . 5 3.1. Event package name . . . . . . . . . . . . . . . . . . . . 6 3.2. Filtering/Default subscription policy. . . . . . . . . . . 7 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.4. Subscription duration. . . . . . . . . . . . . . . . . . . 6 3.5. NOTIFY Bodies. . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Notifier processing of SUBSCRIBE requests. . . . . . . . . 7 3.7. Notifier generation of NOTIFY requests . . . . . . . . . . 7 3.8. Subscriber processing of NOTIFY requests . . . . . . . . . 7 3.9. Handling of forked requests. . . . . . . . . . . . . . . . 7 3.10. Rate of notifications. . . . . . . . . . . . . . . . . . . 8 3.11. State of Agents . . . . . . . . . . . . . . . . . . . . . 8 4. SIP server information document. . . . . . . . . . . . . . . . 8 5. Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 General Usage. . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1 Failover with SIP server event package. . . . . . . . . 9 5.1.2 Load balancing with SIP server event package . . . . . .11 5.1.3 DNS and SIP server event package . . . . . . . . . . . 12 5.2 Specific Usage . . . . . . . . . . . . . . . . . . . . . . 13 6. Security and privacy . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Ma, et al. Expires Nov 18, 2009 [Page 3] Internet-Draft SIP server event package May, 2009 1. Introduction Server farm technique is proposed to implement services with high availability and reliability. For SIP servers, they could collectively form a server farm which acts as a single and high- performance SIP server for SIP clients. However, when some of the servers in the server farm failed or became overloaded, some mechanisms should be used to provide suitable handover or failover to other SIP servers for SIP clients or to transfer load among SIP servers. For these mechanisms, the prior procedure is to obtain the information or state of SIP servers including load, address and so on. Here,we define SIP server event package to communicate information of SIP servers in the SIP server farm. Following the event notification and subscription mechanism defined in SIP event framework [RFC 3265], the server information or state is subscribed and notified among SIP servers and SIP clients in the SIP server farm. Based on this, failover and load balancing can be implemented dynamically. Besides, DNS procedure to locate SIP servers in RFC 3263[RFC 3263] can be substituted partially. The information provided by this package is comprised of the attributes or characteristics of SIP servers such as IP address, transport protocol, SIP port, load, priority, etc. Some attributes are essential but some are optional and extensible. For each server in the SIP server farm, an entry of attributes can be generated and added into this event package. More entries there are in a SIP server event package, more comprehensively and detailed it reflects the overall state of the server farm. Ma, et al. Expires Nov 18, 2009 [Page 4] Internet-Draft SIP server event package May, 2009 2. Document Convention and Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC 2119] and indicate requirement levels for compliant implementations. This documents use the terminology defined in Session Initiation Protocol(SIP)[RFC3261] and SIP event framework [RFC 3265][RFC3903]. Besides, it introduces some new concepts: SIP server farm: also called as SIP server cluster. It consists of SIP servers which collectively serve one domain or more. SIP servers form the server farm by configuration or some distributed techniques, e.g. Distributed Hash Table(DHT). There MAY be a centralized controller in the server farm, e.g. a load balancer to distribute the load to SIP servers. Otherwise, the SIP servers MAY play the same role and form a Peer-to-Peer structure. SIP server event package: a SIP event package in the SIP event framework[RFC3265]. It allows clients to subscribe to the servers for the server information in the server farm, and servers to communicate information with each other. Server attributes: The server attributes represent the status of SIP servers in the server farm, which would be ncluded in the SIP server event package. It includes the basic information such as IP address, port, transport protocol of SIP server. It should be extensible and customizable. The subscriber could request some other server attributes. The formats would be defined in Section 4. 3. SIP server event package The SIP server event package allows SIP entities to subscribe to the information relating to the SIP server farm. This section provides the details for defining a SIP-specific event notification package, as specified by RFC 3265 [RFC 3265]. 3.1. Event package name The name of this event package is "SIPserver". This package name is carried in the Event and Allow-Events header, as defined in RFC 3265 [RFC 3265]. Ma, et al. Expires Nov 18, 2009 [Page 5] Internet-Draft SIP server event package May, 2009 3.2. Filtering/Default subscription policy A SUBSCRIBE for a SIP server package, being sent without a body, implies the default subscription policy. The default policy is as follows: Notifications are generated every time there is any change in the state of the SIP server. Notifications do not normally contain full state; rather, they only indicate the state that has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the full state of the information requested by the subscriber. 3.3. SUBSCRIBE Bodies According to RFC 3265[RFC 3265], the SUBSCRIBE requests will define the types of events being requested. In this event package, a new type defined as "Application/ serverinfo" is added into the Content- type header field to represent the specific usage of event package. 3.4. Subscription duration The default expiration time for a subscription to a SIP server is 30 minutes. The "Expire" value is regarded as 30 if none is specified. 3.5. NOTIFY Bodies According to RFC 3265 [RFC 3265], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE request, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE request. In this event package, the body of the notification contains a SIP server information document. All subscribers and notifiers MUST support the "application/serverinfo+xml" data format. By default, i.e., if no Accept header is specified to a SUBSCRIBE request, the NOTIFY will contain a body in the "application/serverinfo+xml" data format. If the Accept header field is present, it MUST include "application/serverinfo+xml" and MAY include any other types. Ma, et al. Expires Nov 18, 2009 [Page 6] Internet-Draft SIP server event package May, 2009 3.6. Notifier processing of SUBSCRIBE requests The information of SIP servers in the server farm might be sensitive. Therefore, all subscription SHOULD be authenticated and then authorized before approval. The authorization policy is at the discretion of administrator, as always. However, it is RECOMMENDED that all the SIP servers in the server farm and authorized users are allowed to access the information. 3.7. Notifier generation of NOTIFY requests Notifications SHOULD be generated for the server state when the state changes. Changes in other server state information MAY be reported by the SIP server to the SIP server event package subscribers. 3.8. Subscriber processing of NOTIFY requests The SIP events framework expects packages to specify how a subscriber processes NOTIFY requests in any package-specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the NOTIFY for the conference package will only contain information about those servers whose state in the server farm has changed. To construct a coherent view of the total state of all servers, a subscriber to the SIP server evnet package will need to combine NOTIFYs received over time. Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. 3.9. Handling of forked requests There are many SIP servers in the server farm. As a result, a subscriber can subscribe to several servers. However, the forked SUBSCRIBE requests are not allowed. The multiple subscriptions are made by multiple SUBSCRIBE requests and corresponding SUBSCRIBE dialogs. The subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To","From", "From" header, "tag" parameter, "Call-ID", "CSeq", "Event",and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Ma, et al. Expires Nov 18, 2009 [Page 7] Internet-Draft SIP server event package May, 2009 3.10. Rate of notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server does not generate notifications for a single subscriber at a rate faster than once every 1 minute. 3.11. State of Agents Server information is ideally maintained by the server itself. Therefore, a SIP server is the best-suited element to handle subscriptions to it. However, there MAY exist some centralized controllers in the server farm which can collect and aggregate the server information of the whole server farm. In that case, this controller can receive the SUBSCRIBE requests and generate NOTIFY messages. The authorization and authentication policy SHOULD be formulated by the administrators. 4. SIP server information document SIP server information document is RECOMMENDED as an XML document that SHOULD be well-formed and valid. It MUST be based on Extensible Markup Language (XML) 1.0 and MUST be encoded using UTF-8 [RFC 3629]. The data in the document should include some important attributes of SIP servers, i.e. IP address, transport protocol, SIP port, load, priority, etc. Some attributes are essential but some are optional and extensible. Separated documents SHOULD specify the detailed formats of SIP server information document. The attributes of network address of servers MUST be included. 5. Usage SIP server event packages are utilized to transfer server information in the SIP server farm. We design a new type of event package in the SIP event framework to support the failover and load balancing mechanisms for high service reliability and availability in the SIP server farm. Based on the SIP event notification framework, general usage and specific usage are described. Ma, et al. Expires Nov 18, 2009 [Page 8] Internet-Draft SIP server event package May, 2009 5.1 General usage Usage of SIP server event package exists basically in the case that one or more SIP servers failed or became overloaded in the SIP server farm. This type of event package provides an explicit interface for the authorized SIP entities to have the knowledge of the server farm. The related server information constructs the database for the failover and load balancing mechanisms. Besides, the DNS way to locate SIP servers defined in RFC 3263[RFC3263] can be substituted partly by the event notification mechanism defined here. Then, some examples of application based on SIPserver event packages are to be introduced briefly. 5.1.1 Failover with SIP server event package If a SIP server crashes, the SIP entities connected to this server SHOULD transfer the connections to other servers in the server farm. If they have received the SIP server event package, they would know the information of SIP servers including the IP address and transport protocol. Based on this, they can establish new connections with the available SIP servers, resulting in high service reliability. We instantiate the usage in two scenarios in SIP telephony: The first is client-based failover, which hosts the failover logic on client side. As showed in Figure 1, SIP client B registers with the two proxy servers P1 and P2. SIP client A knows the addresses of P1 and P2. It first tries P1, if that fails it switches to P2. The key is how to make SIP client A know the addresses of two servers. Configuring the phones with the two server addresses works well, as Cisco IP phones did. But static configuration doesn't adapt to the dynamic change. If the backup server P2 changes or fails too, SIP client A is unable to contact with client B any more. SIP server event package would be a good method to set up and maintain the relationship between client and server farm. As showed in Figure 1, client A would subscribe to P1 and P2 for the SIP server event package. Through the periodical notification mechanism, client A is informed with the server information about P1 and P2. Client A aggregates the server information from different notifier servers including P1 and P2. Or If the centralized controller exists as 3.11 mentioned, client A MAY subscribe to the controller directly. When P1 fails, client A chooses a backup server from the server information and establishes new contacts with that. Here the chosen backup server is P2. If some SIP servers change, the client would be informed by the update server information respectively once the subscription relationship with them exists. Ma, et al. Expires Nov 18, 2009 [Page 9] Internet-Draft SIP server event package May, 2009 +---------------+ INVITE,FAIL |Proxy P1 | REGISTER ---------------| |................. | | | | | | | | | +---------------+ | +--'-----+ +-----'--+ |SIP | |SIP | |client A| |client B| +-.-.----+ +------.-+ | | | +---------------+ | | |Proxy P2 | | | | | | |INVITE | | REGISTER | |_____________| |-----------------' +---------------+ Figure 1 client based failover The second is DNS based failover. DNS SRV-based failover is a clean way to failover. In this method, client A can retrieve the DNS SRV [14 rfc 2782] record for _sip._udp.home.com to get the two server addresses. In the example, P1 will be preferred over P2 by assigning a lower numeric priority value to P1. Alternatively, dynamic DNS can be used to update the A-record for home.com from the IP address of P1 to P2, when P1 fails. P2 can periodically monitor P1 and update the record when P1 is dead. However, the record bindings are relatively static, accompanied with DNS caching, which would make the failover latency high. The SIP server event package has more flexible information than DNS records and the notification mechanism which would adapt to the dynamic change when fail happens. Here, DNS records can be replaced by server information, the DNS queries can be replaced by the event package subscription. Ma, et al. Expires Nov 18, 2009 [Page 10] Internet-Draft SIP server event package May, 2009 +---------------+ INVITE,FAIL |Proxy P1 | REGISTER ---------------| |................. | | | | | | | | | +---------------+ | +--------+ +--------+ |SIP | |SIP | |client A| |client B| +-.-.----+ +------.-+ | | | | | +---------------+ | | | |Proxy P2 | | | | | | | | |INVITE | | REGISTER | | |_____________| ------------------' | +---------------+ +--|-----------+ | | example.com | _sip._udp SRV 0 0 P1.example.com | DNS | SRV 1 0 P2.example.com | | +--------------+ Figure 2 DNS based failover 5.1.2 Load balancing with SIP server event package If a server becomes overloaded, the SIP server event packages guarantee the redundant choices for the subscribers. Similar with the failover based on SIP server event package, the overloaded server are substituted by other servers triggered by the subscribers. Besides, the load balancing can be implemented in a centralized way. As showed in Figure 3, there MAY be a load balancer in the SIP server farm which distributes all the requests to SIP servers to balance the load. The SIP server event packages become the basic tool to collect the load information for the load balancer. The load balancer (L1) MAY subscribe to all the SIP servers (P1, P2, P3,...) with a high rate of notification or all SIP servers publish their information to load balancer. And the information can be refreshed dynamically to reflect the status of server farm. As a result, the load balancer can grasp the load of all the SIP servers instantaneously and distribute the SIP requests fairly. Ma, et al. Expires Nov 18, 2009 [Page 11] Internet-Draft SIP server event package May, 2009 +--------------------------------+ | SIP Server Farm | | | | +---------------+ | | | Server P1 | | ---------+-----| | | | | | | | | | | | | | | +---------------+ | +---------+ +--'-----+ | +---------------+ | | SIP |___________|load |__|_____| Server P2 | | | client | |balancer" | | | | +---------+ +-.-.----+ | | | | | | | | | | | +---------------+ | | | +---------------+ | | | | Server P3 | | | | | | | |_______|_____| | | | | | | | +---------------+ | | | +--------------------------------+ Figure 3 load balancer based load balancing 5.1.3 DNS and SIP server event package Besides the DNS based failover in 5.1.1, RFC 3263 defines a way to locate SIP servers using DNS queries. The SIP event packages include the server information such as IP address and transport protocol. If a SIP entity has received SIP event packages, the server information would be enough to locate suitable SIP servers. Compared with DNS way, this way shows good flexibility and dynamic characteristics. In RFC3263, DNS records are configured in a static state and the information of DNS records are limited(address, weight, priority). However, the server information can be refreshed dynamically by the notification mechanisms and the information included is extensible and customizable. For the subscriber, the content and format of server information can be decided by SUBSCRIBE bodies. Ma, et al. Expires Nov 18, 2009 [Page 12] Internet-Draft SIP server event package May, 2009 Nevertheless, the SIP server event packages are not adequate for all the scenarios in RFC 3263. On one hand, for a SIP caller which calls frequently to many different domains, the overhead to maintain the dynamic server information in different domains is overwhelming. SIP server event packages are not suitable here. On the other hand, when the SIP entity subscribe to the SIP server information at the first time, it needs to locate the notifier server or proxy. This initial locating process MAY be implemented by the DNS way defined in RFC3263. In all, the mechanisms using SIP server event packages can be a complementary way of DNS to locate SIP servers and substitute it in some scenarios but not in all. 5.2. Specific usage Beside the general usage of SIP server event packages, some specific usage MAY be developed in specific scenarios. This section describes some examples and tries to show the wide area of SIP server event packages. For example, P2PSIP is a new technology which combines Peer-to Peer and SIP. The distributed algorithms such as Distributed Hash Tables(DHT) are applied to form a scalable and reliable infrastructure for SIP application. However, DHT algorithms bring more latency than traditional SIP because the distributed routing and storage mechanisms need additional search to locate where the data is stored. SIP server event packages can be utilized to reduce the latency only if data storage information is added as an item of server attributes. According to this explicit information, DHT search is omitted and the data can be accurately located immediately. SIP server event packages improve the performance of P2PSIP. Service discovery can be an appropriate usage of SIP server event package in SIP network. Adding service item as a server attribute, the event package describes some services the SIP server farm can provide, e.g. STUN/TURN, relay. It SHOULD be noted that only SIP related services are allowed to use SIP sever event packages to discover. Some services such as FTP have no reasons to incorporate SIP event framework. 6. Security and privacy Subscriptions to server information can reveal very sensitive information. For this reason, it is RECOMMENDED that a strong means for authentication and server information protection is applied when using the event notification mechanism defined in this document. The detailed discussion is not included in this version of draft. Ma, et al. Expires Nov 18, 2009 [Page 13] Internet-Draft SIP server event package May, 2009 7. IANA consideration This document proposes a new event packages, which needs IANA considerations such as Package Name, Package or Template-Package, etc. However, because this document only provides a initial description of the event package, the detailed IANA considerations will be defined infurther version. 8. Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): Locating SIP servers", RFC 3263, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3269] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. Ma, et al. Expires Nov 18, 2009 [Page 14] Internet-Draft SIP server event package May, 2009 Authors' Addresses Tao Ma Mobile lIfe and New mEdia Lab, BUPT. P.O. Box 92, No.10, Xitucheng Road Beijing, Haidian District 100876 China Email: abcdmatao@gmail.com 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 Xiaofeng Qiu Mobile lIfe and New mEdia Lab, Xituchen Road Beijing, Haidian District 100876 China Email: qiuxiaofeng@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 Ma, et al. Expires Nov 18, 2009 [Page 15]