Internet DRAFT - draft-chadli-sipping-overload-sub-not
draft-chadli-sipping-overload-sub-not
Network Working Group Y. Chadli
Internet-Draft X. Marjou
Intended status: Standards Track France Telecom
Expires: August 29, 2009 February 25, 2009
An overload control package for the Session Initiation Protocol (SIP).
draft-chadli-sipping-overload-sub-not-02
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 August 29, 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.
Abstract
This document specifies an event package for the notification of
overload control using the Session Initiation Protocol (SIP) events
framework. The overload control package allows an upstream server to
Chadli & Marjou Expires August 29, 2009 [Page 1]
Internet-Draft Overload control package February 2009
retrieve overload control information from a downstream server and to
be notified when this information changes. This information is used
by the upstream server to adapt its flow toward the downstream server
and thus to avoid overloading it.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations for using SUBSCRIBE/NOTIFY mechanism . . . . . . . 4
3.1. Implementation on server farm configuration . . . . . . . 4
3.2. Prioritization of overload control information . . . . . . 6
3.3. Securing overload control information . . . . . . . . . . 6
3.4. Exchanging Overload Information between Non-Neighbours
Elements . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Implementation on non-SIP servers . . . . . . . . . . . . 7
4. Event Package Definition . . . . . . . . . . . . . . . . . . . 7
4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7
4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7
4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7
4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7
4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 8
4.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8
4.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
4.10. Handling of Forked Requests . . . . . . . . . . . . . . . 9
4.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
4.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
4.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 9
5. Application examples . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative references . . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Chadli & Marjou Expires August 29, 2009 [Page 2]
Internet-Draft Overload control package February 2009
1. Introduction
This document specifies an event package for the management of
overload control between nodes of a given network using the Session
Initiation Protocol (SIP) events framework. The overload control
package allows an upstream server to retrieve the load status of a
downstream server and to be notified when this status changes. This
information is used by the upstream server to adapt its flow toward
the receiving server to avoid overloading it.
[4] discusses the overload problem within SIP and provides
requirements for a solution. [5] discusses models and design
considerations for a SIP overload control mechanism. Both [4] and
[5] demonstrate the necessity to exchange explicit overload control
information between SIP entities in order to avoid network
congestion.
This document neither specifies the procedures and syntax for
reporting overload status information nor the rules for processing
this information. In fact, the nature of the overload control
information to be exchanged and the processing of this information by
both the upstream and the downstream entities may depend on the
nature of the network and on the provided services. There are two
approaches. In one approach, the upstream entity signals its current
load to the downstream entity and this latter uses this information
to adapt its traffic. In the other approach, the upstream entity
dictates explicit rules to be applied by the sending entity. In this
latter solution, different types of rules exist in the literature.
Even when only the load status is reported, different syntax may be
used.
Under overload conditions, in order to limit the amount of signalling
traffic and processing capacity used by the notification mechanism, a
downstream entity may decide to notify only a subset of the upstream
entities having subscribed to the overload events. How this subset
is determined is outside the scope of this document. A typical
criteria would be to send notifications to the upstream entities that
have been active during a pre-defined period before the overload
conditions are met.
2. 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 [1].
This document also reuses the SIP terminology defined in RFC3261 [2]
Chadli & Marjou Expires August 29, 2009 [Page 3]
Internet-Draft Overload control package February 2009
and RFC3265 [3], and specifies the usage of the following terms:
Downstream entity: Network element that sends flows toward network
element, upstream entity. The nature of the sent flows depends on
the related network.
Upstream entity: Network element that receives flows coming from
another element entity, downstream entity. The nature of the
received flows depends on the related network..
3. Motivations for using SUBSCRIBE/NOTIFY mechanism
This section discusses the advantages of using a new SIP event
package to carry overload control information. The use of a
dedicated SIP subscription allows separating transport of this
information from the normal applicative traffic. This separation is
necessary to allow:
o The overload mechanism to be supported on SIP servers implemented
as a cluster of servers.
o Prioritizing overload control messages over normal signalling
traffic.
o Applying different security policies to overload control messages
and normal signalling traffic.
o Exchanging overload information between non-neighbours Elements
o The possibility to use the same mechanism by entities that do not
use SIP for their applications.
3.1. Implementation on server farm configuration
SIP server farms are often implemented as a cluster of servers with
one or more front-end servers. The front-end server interfaces to
the other network nodes and performs load balancing on the different
servers of the cluster. Support of such configuration is required in
[4]/ REQ 23. In such a case, the load control mechanism can be
implemented and managed only by front-end servers as only those
servers can know the overall load of the cluster. In case more than
one front-end server is used, we assume that each of them knows the
overall load of the cluster. The way each front-end server knows
this information is out of the scope of this document. When SIP
servers are implemented as a cluster of servers, two kinds of
configuration are possible, regarding the handling of SIP messages:
o The front-end server only dispatches out-of-dialog SIP requests to
the server farms and the subsequent SIP messages related to the
same SIP transaction or SIP dialogs do not go through the front-
end server (see Figure 1). In that case, the server of the farm
chosen to handle the initial SIP request modifies routing
information before forwarding the SIP request (e.g. Via and
Chadli & Marjou Expires August 29, 2009 [Page 4]
Internet-Draft Overload control package February 2009
Record-Route headers for a server acting as a SIP proxy) so that
the subsequent SIP messages of the related SIP transaction or
dialogs are directly routed to it. Supporting such configuration
requires to carry overload control information separately and
independently from normal signalling traffic.
|---------------------------------|
| +----------+ +----------+ |
| | Server 1 | | Server n |............................
| +----------+ +----------+ | .
| | | | |------.------|
| |..+----------+ | | | Adjacent SIP|
| |--| Front-End|----| | | server |
| | Server |=============================| |
| +----------+ | |-------------|
|---------------------------------|
==== Initial SIP requests of "normal" SIP traffic and Subsribe/
Notify(overload-control event)
.... SIP responses and in-dialog requests of "normal" SIP traffic
Figure 1: SIP Server implemented as cluster of servers: only initial
SIP requests go through the Front-End.
o All the SIP messages go through the front-end server. In such
configuration, the use of SUBSCRIBE/NOTIFY to carry overload
control information has the following advantages:
* Overload control information is sent asynchronously from the
normal SIP traffic. Thus, compared to transporting the
overload control information embedded into the normal traffic,
this information may be sent even when there is no normal
traffic to be sent to the downstream entity. Moreover, the
front-end server does not need to parse outgoing traffic in
order to insert this information.
* Identification of received messages carrying overload
information is easy. Compared to transporting the overload
control information embedded into the normal traffic, the
front-end server does not need to parse all the received
messages, able to carry this information, in order to extract
it.
Chadli & Marjou Expires August 29, 2009 [Page 5]
Internet-Draft Overload control package February 2009
|---------------------------------|
| +----------+ +----------+ |
| | Server 1 | | Server n | |
| +----------+ +----------+ |
| | | |
| | | | |-------------|
| | +----------+ | | | Adjacent SIP|
| |--| Front-End|----| | | server |
| | Server |=============================| |
| +----------+ | |-------------|
|---------------------------------|
====== All "Normal" SIP traffic & Sub/Not (overload-control event)
Figure 2: SIP Server implemented as cluster of servers: all SIP
messages go through the Front-End.
3.2. Prioritization of overload control information
In situation where the server is overloaded it's necessary that a
downstream entity is able to treat SIP messages carrying status
information with a high priority. Since the overload information is
carried within a dedicated SIP subscription, prioritization of such
messages is possible.
3.3. Securing overload control information
The overload status information of a server is sensitive and a server
may want to restrict the access to this information only to the
trusted elements. [4], in REQ 22, states that the mechanism must
allow disabling the reporting of load information towards upstream
targets based on the identity of those targets. In addition, REQ 5
of [4] states that the mechanism should not assume that it will only
be deployed in environments with completely trusted elements.
Moreover, overload information flow may represent a denial of service
attack vector. For example, false load information or bogus
restriction rules may be introduced into the signalling stream by a
third party in order to disrupt the application work flow.
The use of subscription mechanism allows a server to authenticate the
network element asking for this information. Moreover, in order to
avoid interception of this information by intermediary elements, it
is possible to apply a suitable and dedicated security mechanism to
the SIP messages transporting overload information.
Chadli & Marjou Expires August 29, 2009 [Page 6]
Internet-Draft Overload control package February 2009
3.4. Exchanging Overload Information between Non-Neighbours Elements
The use of SUBSCRIBE/NOTIFY mechanism within a SIP-based network
allows exchanging overload control information between network
elements that do not exchange directly normal signalling traffic.
Compared to encapsulating the overload control information into the
normal traffic, identification of the sending and receiving of
overload control information is naturally carried within Subscribe/
Notify messages. Exchange of overload control information between
non-adjacent elements may be useful in some configurations. For
instance, a home proxy may need to throttle the traffic coming from a
PBX that is connected through an outbound proxy. Throttling the
traffic directly from the PBX allows to avoid loading the outbound
proxy uselessly. In addition, this feature would allow centralizing
overload control management on nodes that have a wide visibility of
the overall network traffic. In the example given above, the home
proxy also knows the traffic flowing through the other outbound
proxies.
3.5. Implementation on non-SIP servers
Separating the transport of overload control information form normal
traffic makes the implementation of the mechanism possible on network
elements that are not in the path of normal SIP traffic, provided
that they implement a SIP user agent.
4. Event Package Definition
4.1. Event Package Name
The name of this package is "overload-control". As defined in [3],
this value appears in the Event header field present in SUBSCRIBE and
NOTIFY requests for this package.
4.2. Event Package Parameters
No parameters are defined for this event package.
4.3. SUBSCRIBE Bodies
This package defines no use of the SUBSCRIBE request body. If
present, it MUST be ignored.
4.4. Subscription Duration
The duration of a subscription is specific to SIP deployments and no
specific recommendation is made by this Event Package.
Chadli & Marjou Expires August 29, 2009 [Page 7]
Internet-Draft Overload control package February 2009
It is to be noted that a one-time fetch of an overload control
information, especially in case this information is the load status
of the server, can be accomplished by setting the 'Expires' parameter
to a value of zero, as specified in [3].
4.5. NOTIFY Bodies
The NOTIFY body MUST contain overload control information. This
document does not does not define any specific contents and syntax
for overload control information and delegates specification of
utilised MIME types for representing overload control information to
other documents. The overload control information to be carried
depends on the overload control mechanism in use.
The NOTIFY body MUST include a content corresponding to a MIME type
specified in the 'Accept' header of the SUBSCRIBE.
4.6. Subscriber Generation of SUBSCRIBE Requests
The subscribe message MUST contain the Event header set to overload
control and the Accept header indicating the supported MIME types.
4.7. Notifier Processing of SUBSCRIBE Requests
A successful SUBSCRIBE request results in a NOTIFY.
The SUBSCRIBE request for the overload control event SHOULD be either
authenticated or transmitted over an integrity protected SIP
communication channels.
If the identity of the entity sending the SUBSCRIBE message is not
allowed to receive overload control information, the notifier MUST
return a 403 "Forbidden" response.
If none of MIME types specified in the Accept header of the SUBSCRIBE
is supported, the Notifier SHOULD return 406 "Not Acceptable"
response.
4.8. Notifier Generation of NOTIFY Requests
As specified in [3], the Notifier MUST always send a NOTIFY request
upon accepting a subscription. Depending on the used overload
control mechanism, this MAY contain a body. For instance, if the
overload mechanism is based on reporting the load status, the first
NOTIFY SHOULD contain a body reporting the current load status.
If the SUBSCRIBE was received over an integrity protected SIP
communications channel, the Notifier SHOULD send the NOTIFY over the
Chadli & Marjou Expires August 29, 2009 [Page 8]
Internet-Draft Overload control package February 2009
same channel.
If an Accept header was received in the SUBSCRIBE message, the body
type of the NOTIFY request MUST correspond to one of the ones that
were indicated in this header.
4.9. Subscriber Processing of NOTIFY Requests
A Subscriber to this event package MUST adhere to the NOTIFY request
processing behaviour specified in[3].
If the NOTIFY contains several bodies, only the supported ones MUST
be considered. If no supported body type is present, the subscriber
SHOULD unsubscribe. The subscriber MUST also be prepared to receive
a NOTIFY request with no body. The subscriber MUST NOT reject the
NOTIFY request with no body. The subscription dialog MUST NOT be
terminated by a NOTIFY with no body.
Processing of supported bodies is outside the scope of this document.
4.10. Handling of Forked Requests
This Event package allows the creation of only one dialog as a result
of an initial SUBSCRIBE request as described in section 4.4.9 of [3].
It does not support the creation of multiple subscriptions using
forked SUBSCRIBE requests.
4.11. Rate of Notifications
The rate of notifications for overload control information will
depend on the overload mechanism in use. Hence, the event package
specification does not specify a throttling or minimum period between
NOTIFY requests.
4.12. State Agents
State agents are not applicable to this Event Package.
4.13. Behavior of a Proxy Server
There are no additional requirements on a SIP Proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY methods as required in
SIP. However, Proxies SHOULD allow non-SIP URLs.
5. Application examples
The SUBSCRIBE/NOTIFY mechanism described in this document may be used
Chadli & Marjou Expires August 29, 2009 [Page 9]
Internet-Draft Overload control package February 2009
to implement any overload control mechanism that requires explicit
exchange of overload information. [5] discusses two implemention
models of an explicit overload control mechanism: hop-by-hop and end-
to-end.
Moreover, different types of information may be exchanged between
network elements depending on the used overload mechanism. [5]
discusses five types of overload control mechanism based on the type
of information conveyed between network elements:
o Rate-based Overload Control
o Loss-based Overload Control
o Window-based Overload Control
o Signal-based Overload Control
o On-/Off Overload Control
The SUBSCRIBE/NOTIFY based mechanism described in this document may
be used to implement all of the overload control mechanisms listed .
Although signal-based and On/Off overload mechanisms may be easily
implemented using 503 "Server Unavailable", the use of SUBSCRIBE/
NOTIFY may be justified in case these mechanisms are used in
conjunction with other mechanisms that require exchange of more
complex overload information or when there is a need to send the
overload information to a particular network element in the
signalling path
Hereafter, an example of XML schema for a Rate-Based Overload Control
mechanism:
Chadli & Marjou Expires August 29, 2009 [Page 10]
Internet-Draft Overload control package February 2009
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf::id:draft-chadli-sipping-overload-sub-not-02:params:xml:ns:overloadcontrol"
xmlns:ss="urn:ietf::id:draft-chadli-sipping-overload-sub-not-02:params:xml:ns:overloadcontrol"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="rulesList" type="ss:RulesList" />
<xs:complexType name="RulesList">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="element" type="ss:Rule" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="Rule">
<xs:sequence>
<xs:element name="ruleID" type="xs:integer" />
<xs:element name="applicationCriteria" type="ss:ApplicationCriteria" />
<xs:element name="duration" type="ss:Duration" />
<xs:element name="rate" type="xs:double" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="ApplicationCriteria">
<xs:sequence>
<xs:element name="applicationAddress" type="ss:ApplicationAddress" />
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ApplicationAddress">
<xs:annotation>
<xs:documentation>
Application layer address, e.g. SIP URI, phone number.
Some addresses may be wildcarded using a delimited regular expression.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
</xs:schema>
Chadli & Marjou Expires August 29, 2009 [Page 11]
Internet-Draft Overload control package February 2009
6. IANA Considerations
This specification registers a new event package as defined in [3].
The following information required for this registration:
Package Name: overload-control
Type: package
Published specification: This document
Persons to Contact: Youssef CHADLI, Youssef.chadli@orange-ftgroup.com
7. Security Considerations
Overload information is particularly sensitive and access to this
information by malicious elements may increase the risk of security
attacks. At a minimum, subscriptions to this event package SHOULD be
authenticated and properly authorized. Furthermore, notifications
SHOULD be encrypted and integrity protected using either end-to-end
mechanisms, or the hop-by-hop protection afforded messages sent to
SIPS URIs.
8. Acknowledgements
The authors would like to thank Bruno Chatras (Orange) and Nick
Stewart (BT) for their contributions to this document.
9. References
9.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] 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.
[3] Roach, Alan., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Chadli & Marjou Expires August 29, 2009 [Page 12]
Internet-Draft Overload control package February 2009
9.2. Informative references
[4] Rosenberg, Jonathan., "Requirements for Management of Overload
in the Session Initiation Protocol", RFC 5390, May 2008.
[5] Rosenberg, Jonathan., "Design Considerations for Session
Initiation Protocol (SIP) Overload Control",
draft-ietf-sipping-overload-design-00 (work in progress),
May 2008.
Authors' Addresses
Youssef Chadli
France Telecom
38, avenue General Leclerc
Issy les Moulineaux 92130
France
Email: youssef.chadli@orange-ftgroup.com
Xavier Marjou
France Telecom
2, rue Pierre Marzin
Lannion 22307
France
Email: xavier.marjou@orange-ftgroup.com
Chadli & Marjou Expires August 29, 2009 [Page 13]
