Network Working Group Y. Chadli
Internet-Draft X. Marjou
Intended status: Standards Track France Telecom
Expires: June 6, 2008 December 04, 2007
An overload control package for the Session Initiation Protocol (SIP).
draft-chadli-sipping-overload-sub-not-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 June 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
retrieve overload control information from an 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.
Chadli & Marjou Expires June 6, 2008 [Page 1]
Internet-Draft Overload control package December 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations for using Subscribe/Notify mechanism . . . . . . . 4
3.1. Implementation on servers 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . 8
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. Additional considerations . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative references . . . . . . . . . . . . . . . . . . . 10
9.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Chadli & Marjou Expires June 6, 2008 [Page 2]
Internet-Draft Overload control package December 2007
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] demonstrates 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]
and RFC3265 [3], and specifies the usage of the following terms:
Downstream entity: Network element that sends flows toward network
Chadli & Marjou Expires June 6, 2008 [Page 3]
Internet-Draft Overload control package December 2007
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 servers farm configuration
SIP servers farms are often implemented as a cluster of servers with
one or more front-end servers. The frond-end server interfaces to
the other network nodes and performs load balancing on the different
servers of the cluster. In such a case, the load control mechanism
can be implemented and managed only by front-end servers as only th/
ose 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
configurations 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
Record-Route for a server acting as a stateful 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
Chadli & Marjou Expires June 6, 2008 [Page 4]
Internet-Draft Overload control package December 2007
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 frond-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, susceptible to carry this information, in order to
extract it.
Chadli & Marjou Expires June 6, 2008 [Page 5]
Internet-Draft Overload control package December 2007
|---------------------------------|
| +----------+ +----------+ |
| | 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. Provided that 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 sensible and a server
may want to restrict the access to this information only to the
trusted elements. 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 status information.
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. Exchanging 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 which is connected through an outbound proxy. This allows to
Chadli & Marjou Expires June 6, 2008 [Page 6]
Internet-Draft Overload control package December 2007
throttle the traffic from the source and thus to avoid loading the
outbound proxy uselessly. In addition, this feature would allow
centralizing overload control management on nodes that have a wide
visibility on the overall network traffic. In the example given
above, the home proxy also knows the traffic following 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.
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
Chadli & Marjou Expires June 6, 2008 [Page 7]
Internet-Draft Overload control package December 2007
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
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].
Chadli & Marjou Expires June 6, 2008 [Page 8]
Internet-Draft Overload control package December 2007
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. Additional considerations
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
Chadli & Marjou Expires June 6, 2008 [Page 9]
Internet-Draft Overload control package December 2007
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 and Nick Stewart 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.
9.2. Informative references
[4] Rosenberg, Jonathan., "Requirements for Management of Overload
in the Session Initiation Protocol",
draft-ietf-sipping-overload-reqs-01 (work in progress),
November 2006.
Chadli & Marjou Expires June 6, 2008 [Page 10]
Internet-Draft Overload control package December 2007
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 June 6, 2008 [Page 11]
Internet-Draft Overload control package December 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).
Chadli & Marjou Expires June 6, 2008 [Page 12]