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]