draft-ietf-sipcore-event-rate-control-00.txt   draft-ietf-sipcore-event-rate-control-01.txt 
Network Working Group A. Niemi Network Working Group A. Niemi
Internet-Draft K. Kiss Internet-Draft K. Kiss
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: November 12, 2009 S. Loreto Expires: May 1, 2010 S. Loreto
Ericsson Ericsson
May 11, 2009 October 28, 2009
Session Initiation Protocol (SIP) Event Notification Extension for Session Initiation Protocol (SIP) Event Notification Extension for
Notification Rate Control Notification Rate Control
draft-ietf-sipcore-event-rate-control-00 draft-ietf-sipcore-event-rate-control-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 12, 2009. This Internet-Draft will expire on May 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies mechanisms for adjusting the rate of Session This document specifies mechanisms for adjusting the rate of Session
Initiation Protocol (SIP) event notifications. These mechanisms can Initiation Protocol (SIP) event notifications. These mechanisms can
be applied in subscriptions to all SIP event packages. be applied in subscriptions to all SIP event packages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Document Conventions . . . . . . . . . . . . . 4 2. Definitions and Document Conventions . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Case for maximizing the rate of notifications . . . . 4 3.1. Use Case for limiting the maximum rate of notifications . 5
3.2. Use Case for minimizing the rate of notifications . . . . 5 3.2. Use Case for setting a minimum rate for notifications . . 6
3.3. Use Case for specifying the average rate of 3.3. Use Case for specifying the average rate of
notifications . . . . . . . . . . . . . . . . . . . . . . 6 notifications . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. The maximum rate mechanism for Resource List Server . . . 7 3.5. The maximum rate mechanism for Resource List Server . . . 9
3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10
4. Operation of the maximum rate mechanism . . . . . . . . . . . 10 4. Operation of the maximum rate mechanism . . . . . . . . . . . 11
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 11
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 12
4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 11 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 13
4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 12 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 14
4.4.1. Partial State Notifications . . . . . . . . . . . . . 12 4.4.1. Partial State Notifications . . . . . . . . . . . . . 14
4.4.2. Full State Notifications . . . . . . . . . . . . . . . 12 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14
4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 13 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14
5. Operation of the minimum rate mechanism . . . . . . . . . . . 13 5. Operation of the minimum rate mechanism . . . . . . . . . . . 15
5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 13 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15
5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 14 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16
6. Operation of the average rate mechanism . . . . . . . . . . . 14 6. Operation of the average rate mechanism . . . . . . . . . . . 16
6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16
6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17
6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 16 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 18
7. Usage of "min-interval", "max-interval" and 7. Usage of "min-interval", "max-interval" and
"average-interval" in a combination . . . . . . . . . . . . . 17 "average-interval" in a combination . . . . . . . . . . . . . 19
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. "min-interval", "max-interval" and "average-interval" 8.1. "min-interval", "max-interval" and "average-interval"
Header Field Parameters . . . . . . . . . . . . . . . . . 18 Header Field Parameters . . . . . . . . . . . . . . . . . 20
8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 18 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.3. Event header field usage in responses to the NOTIFY
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 request . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The SIP events framework [RFC3265] defines a generic framework for The SIP events framework [RFC3265] defines a generic framework for
subscriptions to and notifications of events related to SIP systems. subscriptions to and notifications of events related to SIP systems.
This framework defines the methods SUBSCRIBE and NOTIFY, and This framework defines the methods SUBSCRIBE and NOTIFY, and
introduces the concept of an event package, which is a concrete introduces the concept of an event package, which is a concrete
application of the SIP events framework to a particular class of application of the SIP events framework to a particular class of
events. events.
skipping to change at page 4, line 39 skipping to change at page 5, line 39
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
Indented passages such as this one are used in this document to Indented passages such as this one are used in this document to
provide additional information and clarifying text. They do not provide additional information and clarifying text. They do not
contain normative protocol behavior. contain normative protocol behavior.
3. Overview 3. Overview
3.1. Use Case for maximizing the rate of notifications 3.1. Use Case for limiting the maximum rate of notifications
A presence client in a mobile device contains a list of 100 buddies A presence client in a mobile device contains a list of 100 buddies
or presentities. In order to decrease the processing and network or presentities. In order to decrease the processing and network
load of watching 100 presentities, the presence client has employed a load of watching 100 presentities, the presence client has employed a
Resource List Server (RLS) with the list of buddies, and therefore Resource List Server (RLS) with the list of buddies, and therefore
only needs a single subscription to the RLS in order to receive only needs a single subscription to the RLS in order to receive
notification of the presence state of the resource list. notification of the presence state of the resource list.
In order to control the buffer policy of the RLS, the presence client In order to control the buffer policy of the RLS, the presence client
sets a maximum rate ("min-interval" parameter), i.e. a minimum time sets a maximum rate ("min-interval" parameter), i.e. a minimum time
skipping to change at page 5, line 35 skipping to change at page 6, line 35
the presence client can resume the stream of notifications by re- the presence client can resume the stream of notifications by re-
setting the "min-interval" parameter to the earlier used value. setting the "min-interval" parameter to the earlier used value.
Currently, a subscription refresh is needed in order to update the Currently, a subscription refresh is needed in order to update the
maximum rate. However, this is highly inefficient, since each maximum rate. However, this is highly inefficient, since each
refresh automatically generates a (full-state) notification refresh automatically generates a (full-state) notification
carrying the latest resource state. There is work carrying the latest resource state. There is work
[I-D.ietf-sipcore-subnot-etags] ongoing to solve these [I-D.ietf-sipcore-subnot-etags] ongoing to solve these
inefficiencies. inefficiencies.
3.2. Use Case for minimizing the rate of notifications 3.2. Use Case for setting a minimum rate for notifications
A location application is monitoring the movement of a target. A location application is monitoring the movement of a target.
In order to decrease the processing and network load, the location In order to decrease the processing and network load, the location
application has made a subscription with a set of location filters application has made a subscription with a set of location filters
[I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for
example, to send an update only when the target has moved at least n example, to send an update only when the target has moved at least n
meters. However, the application is also interested to receive the meters. However, the application is also interested to receive the
current state periodically even if the state of the target is current state periodically even if the state of the target has not
unchanged or has not changed enough to satisfy any of the trigger changed enough to satisfy any of the trigger criteria, i.e. has not
criteria, i.e. has not moved at least n meters within the period. moved at least n meters within the period.
In order to control the actual state, the location application sets a In order to control the actual state, the location application sets a
minimum rate ("max-interval" parameter), i.e. a maximum time interval minimum rate ("max-interval" parameter), i.e. a maximum time interval
between two notifications. The minimum rate setting triggers a between two notifications.
notification that is exactly and precisely like a notification after
a subscription refresh.
The location application can also modify the "max-interval" parameter The location application can also modify the "max-interval" parameter
during the lifetime of the subscription. during the lifetime of the subscription. When the subscription to
the movement of a target is made, the notifier does not typically
have the location information available. Thus, the first
notification might be empty, or certain values might be absent. An
important use case is placing constraints on when complete state
should be provided after creating the subscription. The "max-
interval" parameter indicates to the notifier the time when to
generate a notification containing complete state information. Once
state is acquired and the second notification is sent, the subscriber
updates or changes the "max-interval" parameter to a more sensible
value. This update can be performed in the 200 OK response to the
NOTIFY request that contains the complete state information.
3.3. Use Case for specifying the average rate of notifications 3.3. Use Case for specifying the average rate of notifications
The previous mechanisms introduce a static and instantaneous rate The previous mechanisms introduce a static and instantaneous rate
control. However there are some applications that would work better control. However there are some applications that would work better
with an adaptive rate control. This section illustrates the tracking with an adaptive rate control. This section illustrates the tracking
scenario. scenario.
A tracking application is monitoring a target. A tracking application is monitoring a target.
skipping to change at page 9, line 47 skipping to change at page 11, line 10
a specific event subscription does so by including a "max-interval" a specific event subscription does so by including a "max-interval"
Event header parameter as part of the SUBSCRIBE request. The "max- Event header parameter as part of the SUBSCRIBE request. The "max-
interval" value indicates the maximum time allowed between interval" value indicates the maximum time allowed between
transmission of two consecutive notifications in a subscription. transmission of two consecutive notifications in a subscription.
A subscriber that wants to have an average cadence for the A subscriber that wants to have an average cadence for the
notifications in a specific event subscription does so by including a notifications in a specific event subscription does so by including a
"average-interval" Event header parameter as part of the SUBSCRIBE "average-interval" Event header parameter as part of the SUBSCRIBE
request. request.
A subscriber that wants to update a previously agreed event rate
control parameter does so by including the updated "min-interval",
"max-interval" or "average-interval" Event header parameter as part
of a subsequent SUBSCRIBE request or a 200-class response to the
NOTIFY request.
A notifier that supports the different rate control mechanisms will A notifier that supports the different rate control mechanisms will
comply with the value given in "min-interval", "max-interval" and comply with the value given in "min-interval", "max-interval" and
"average-interval" parameters and adjust its rate of notification "average-interval" parameters and adjust its rate of notification
accordingly. However, if the notifier needs to lower the accordingly. However, if the notifier needs to lower the
subscription expiration value or a local policy at the notifier can subscription expiration value or a local policy or other
not satisfy the rate control request, then the notifier can adjust implementation-determined constraint at the notifier can not satisfy
opportunely the subscriber requested rate control. the rate control request, then the notifier can adjust opportunely
the subscriber requested rate control.
Rate controlled notifications will have exactly the same properties Rate controlled notifications will have exactly the same properties
as the ones without rate control, with the exception that they will as the ones without rate control, with the exception that they will
be generated within the timing constraints requested. be generated within the timing constraints requested.
4. Operation of the maximum rate mechanism 4. Operation of the maximum rate mechanism
4.1. Subscriber Behavior 4.1. Subscriber Behavior
In general, the way in which a subscriber generates SUBSCRIBE In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265 requests and processes NOTIFY requests is according to RFC 3265
[RFC3265]. [RFC3265].
A subscriber that wishes to apply a maximum rate to notifications in A subscriber that wishes to apply a maximum rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
minimum time interval between two consecutive notifications included minimum time interval between two consecutive notifications included
in the "min-interval" Event header field parameter. The value of in the "min-interval" Event header field parameter. The value of
this parameter is an integral number of seconds in decimal. this parameter is an integral number of seconds in decimal.
A subscriber that wishes to remove a the maximum rate control from Subscribers implementing the maximum rate mechanism MUST include an
notifications MUST construct a SUBSCRIBE request that does not Event header field in any 200-class responses to NOTIFY requests.
include a "min-interval" Event header field parameter.
A subscriber that wishes to update the previously agreed maximum rate
of notifications MUST include the updated "min-interval" Event header
field parameter in a subsequent SUBSCRIBE request or a 200-class
response to the NOTIFY request.
A subscriber that wishes to remove the maximum rate control from
notifications MUST indicate so by not including a "min-interval"
Event header field parameter in a subsequent SUBSCRIBE request or a
200-class response to the NOTIFY request.
There are two main consequences for the subscriber when applying the There are two main consequences for the subscriber when applying the
maximum rate mechanism: state transitions may be lost, and event maximum rate mechanism: state transitions may be lost, and event
notifications may be delayed. If either of these side effects notifications may be delayed. If either of these side effects
constitute a problem to the application that is to utilize event constitute a problem to the application that is to utilize event
notifications, developers are instructed not to use the mechanism. notifications, developers are instructed not to use the mechanism.
4.2. Notifier Behavior 4.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the maximum rate mechanism MUST extract the A notifier that supports the maximum rate mechanism MUST extract the
value of the "min-interval" Event header parameter and use it as the value of the "min-interval" Event header parameter from a SUBSCRIBE
suggested time allowed between two notifications. This value can be request or a 200-class response to the NOTIFY request and use it as
adjusted by the notifier, as defined in Section 4.3. the suggested time allowed between two notifications. This value can
be adjusted by the notifier, as defined in Section 4.3.
A compliant notifier MUST reflect back the possibly adjusted minimum A compliant notifier MUST reflect back the possibly adjusted minimum
time interval in a "min-interval" Subscription-State header field time interval in a "min-interval" Subscription-State header field
parameter of the subsequent NOTIFY requests. The indicated "min- parameter of the subsequent NOTIFY requests. The indicated "min-
interval" value is adopted by the notifier, and the notification rate interval" value is adopted by the notifier, and the notification rate
is adjusted accordingly. is adjusted accordingly.
A notifier that does not understand this extension will not reflect A notifier that does not understand this extension will not reflect
the "min-interval" Subscription-State header field parameter in the the "min-interval" Subscription-State header field parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter serves as a hint to
skipping to change at page 11, line 34 skipping to change at page 13, line 15
Retransmissions of NOTIFY requests are not affected by the maximum Retransmissions of NOTIFY requests are not affected by the maximum
rate mechanism, i.e., the maximum rate mechanism only applies to the rate mechanism, i.e., the maximum rate mechanism only applies to the
generation of new transactions. In other words, the maximum rate generation of new transactions. In other words, the maximum rate
mechanism does not in any way break or modify the normal mechanism does not in any way break or modify the normal
retransmission mechanism. retransmission mechanism.
4.3. Selecting the maximum rate 4.3. Selecting the maximum rate
Special care needs to be taken when selecting the "min-interval" Special care needs to be taken when selecting the "min-interval"
value. Using the "min-interval" syntax it is possible to insist both value. Using the "min-interval" syntax it is possible to insist both
very short and very long intervals between notifications. For very short and very long intervals between notifications.
example, the maximum rate could potentially set a minimum time value
between notifications that exceeds the subscription expiration value. For example, the maximum rate could potentially set a minimum time
Such a configuration would effectively quench the notifier, resulting value between notifications that exceeds the subscription expiration
in exactly two notifications to be generated. value. Such a configuration would effectively quench the notifier,
resulting in exactly two notifications to be generated. If the
subscriber requests a "min-interval" value greater than the
subscription expiration, the notifier MUST lower the "min-interval"
value and set it to the expiration time left. According to RFC 3265
[RFC3265] the notifier may also shorten the subscription expiry
anytime during an active subscription. For such cases, the notifier
MUST also lower the "min-interval" value and set it to the reduced
expiration time.
In some cases it makes sense to pause the notification stream on an In some cases it makes sense to pause the notification stream on an
existing subscription dialog on a temporary basis without terminating existing subscription dialog on a temporary basis without terminating
the subscription, e.g. due to inactivity on the application UI. the subscription, e.g. due to inactivity on the application UI.
Whenever a subscriber discovers the need to perform the notification Whenever a subscriber discovers the need to perform the notification
pause operation, it SHOULD set the "min-interval" value to the pause operation, it SHOULD set the "min-interval" value to the
remaining subscription expiration value. This results in receiving remaining subscription expiration value. This results in receiving
no further notifications until the subscription expires, renewed or no further notifications until the subscription expires, renewed or
notifications are resumed by the subscriber. notifications are resumed by the subscriber.
The notifier is responsible for adjusting the proposed maximum rate The notifier MAY decide to adjust the proposed maximum rate value
value based on its local policy or other properties. based on its local policy or other implementation-determined
constraints. The notifier MAY also choose a higher "min-interval"
If the subscriber requests a "min-interval" value greater than the value than the subscriber proposed one, e.g., because of static
subscription expiration, the notifier MUST lower the "min-interval" configuration given by local policy.
value and set it to the expiration time left. According to RFC 3265
[RFC3265] the notifier may also shorten the subscription expiry
anytime during an active subscription. For such cases, the notifier
MUST also lower the "min-interval" value and set it to the reduced
expiration time.
The notifier MAY also choose a higher "min-interval" value, e.g., The notifier MUST include the adjusted "min-interval" value in the
because of static configuration given by local policy. The notifier Subscription-State header field's "min-interval" parameter in each of
MUST include the adjusted "min-interval" value in the Subscription- the NOTIFY requests. In addition, different event packages MAY
State header field's "min-interval" parameter in each of the NOTIFY define additional constraints to the allowed "min-interval"
requests. In addition, different event packages MAY define intervals. Such constraints are out of the scope of this
additional constraints to the allowed "min-interval" intervals. Such specification.
constraints are out of the scope of this specification.
4.4. Buffer Policy Description 4.4. Buffer Policy Description
4.4.1. Partial State Notifications 4.4.1. Partial State Notifications
With partial notifications, the notifier will always need to keep With partial notifications, the notifier will always need to keep
both a copy of the current full state of the resource F, as well as both a copy of the current full state of the resource F, as well as
the last successfully communicated full state view F' of the resource the last successfully communicated full state view F' of the resource
in a specific subscription. The construction of a partial in a specific subscription. The construction of a partial
notification then involves creating a difference of the two states, notification then involves creating a difference of the two states,
skipping to change at page 13, line 23 skipping to change at page 15, line 6
during the same interval when using the maximum rate mechanism, during the same interval when using the maximum rate mechanism,
yielding bandwidth savings of several times the notification size. yielding bandwidth savings of several times the notification size.
With partial-state notifications, drawing estimates is further With partial-state notifications, drawing estimates is further
complicated by the fact that the states of consecutive updates may or complicated by the fact that the states of consecutive updates may or
may not overlap. However, even in the worst case scenario, where may not overlap. However, even in the worst case scenario, where
each partial update is to a different part of the full state, a rate each partial update is to a different part of the full state, a rate
controlled notification merging all of these n partial states controlled notification merging all of these n partial states
together should at a maximum be the size of a full-state update. In together should at a maximum be the size of a full-state update. In
this case, the bandwidth savings are approximately n times the size this case, the bandwidth savings are approximately n times the size
of the NOTIFY header. of the header fields of the NOTIFY request.
It is also true that there are several compression schemes available It is also true that there are several compression schemes available
that have been designed to save bandwidth in SIP, e.g., SigComp that have been designed to save bandwidth in SIP, e.g., SigComp
[RFC3320] and TLS compression [RFC3943]. However, such compression [RFC3320] and TLS compression [RFC3943]. However, such compression
schemes are complementary rather than competing mechanisms to the schemes are complementary rather than competing mechanisms to the
maximum rate mechanism. After all, they can both be applied maximum rate mechanism. After all, they can both be applied
simultaneously, and in such a way that the compound savings are as simultaneously, and in such a way that the compound savings are as
good as the sum of applying each one alone. good as the sum of applying each one alone.
5. Operation of the minimum rate mechanism 5. Operation of the minimum rate mechanism
5.1. Subscriber Behavior 5.1. Subscriber Behavior
In general, the way in which a subscriber generates SUBSCRIBE In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265 requests and processes NOTIFY requests is according to RFC 3265
[RFC3265]. [RFC3265].
A subscriber that wishes to apply a minimum rate to notifications in A subscriber that wishes to apply a minimum rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
maximum time interval between two consecutive notifications included maximum time interval between two consecutive notifications included
in the "max-interval" Event header field parameter. in the "max-interval" Event header field parameter. The value of
this parameter is an integral number of seconds in decimal.
Subscribers implementing the minimum rate mechanism MUST include an
Event header field in any 200-class responses to NOTIFY requests.
A subscriber that wishes to update the previously agreed minimum rate
of notifications MUST include the updated "max-interval" Event header
field parameter in a subsequent SUBSCRIBE request or a 200-class
response to the NOTIFY request.
A subscriber that wishes to remove the minimum rate control from A subscriber that wishes to remove the minimum rate control from
notifications MUST construct a SUBSCRIBE request that does not notifications MUST indicate so by not including a "max-interval"
include a "max-interval" Event header field parameter. The value of Event header field parameter in a subsequent SUBSCRIBE request or a
this parameter is an integral number of seconds in decimal. 200-class response to the NOTIFY request.
The main consequence for the subscriber when applying the minimum The main consequence for the subscriber when applying the minimum
rate mechanism is that it can receive a notification even if nothing rate mechanism is that it can receive a notification even if nothing
has changed in the current state of the notifier. has changed in the current state of the notifier.
There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a
reference in a notification if nothing has changed. reference in a notification if nothing has changed.
5.2. Notifier Behavior 5.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the minimum rate mechanism MUST extract the A notifier that supports the minimum rate mechanism MUST extract the
value of the "max-interval" Event header parameter and use it as the value of the "max-interval" Event header parameter from a SUBSCRIBE
suggested maximum time allowed between two notifications. This value request or a 200-class response to the NOTIFY request and use it as
can be adjusted by the notifier based on its local policy or other the suggested maximum time allowed between two notifications.
properties.
A compliant notifier MUST reflect back the possibly adjusted maximum The notifier MAY decide to adjust the proposed minimum rate value
time interval in a "max-interval" Subscription-State header field based on its local policy or other implementation-determined
parameter of the subsequent NOTIFY requests. The indicated "max- constraints. A compliant notifier MUST reflect back the possibly
interval" value is adopted by the notifier, and the notification rate adjusted maximum time interval in a "max-interval" Subscription-State
is adjusted accordingly. header field parameter of the subsequent NOTIFY requests. The
indicated "max-interval" value is adopted by the notifier, and the
notification rate is adjusted accordingly.
A notifier that does not understand this extension, will not reflect A notifier that does not understand this extension, will not reflect
the "max-interval" Subscription-State header field parameter in the the "max-interval" Subscription-State header field parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter serves as a hint to
the subscriber that no rate control is supported by the notifier. the subscriber that no rate control is supported by the notifier.
A compliant notifier MUST generate notifications whenever the time A compliant notifier MUST generate notifications whenever the time
since the most recent notification exceeds the value in the "max- since the most recent notification exceeds the value in the "max-
interval" parameter. The NOTIFY request then MUST contain the interval" parameter. Depending on the event package and subscriber
current state in its entirety, just like after a subscription preferences indicated in the SUBSCRIBE request, the NOTIFY request
refresh. MUST contain either the current full state or the partial state
showing the difference between the current state and the last
successfully communicated state.
Retransmissions of NOTIFY requests are not affected by the minimum Retransmissions of NOTIFY requests are not affected by the minimum
rate mechanism, i.e., the minimum rate mechanism only applies to the rate mechanism, i.e., the minimum rate mechanism only applies to the
generation of new transactions. In other words, the minimum rate generation of new transactions. In other words, the minimum rate
mechanism does not in any way break or modify the normal mechanism does not in any way break or modify the normal
retransmission mechanism. retransmission mechanism.
6. Operation of the average rate mechanism 6. Operation of the average rate mechanism
6.1. Subscriber Behavior 6.1. Subscriber Behavior
skipping to change at page 15, line 11 skipping to change at page 17, line 8
In general, the way in which a subscriber generates SUBSCRIBE In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265 requests and processes NOTIFY requests is according to RFC 3265
[RFC3265]. [RFC3265].
A subscriber that wishes to apply an average rate to notifications in A subscriber that wishes to apply an average rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
proposed average time interval between two consecutive notifications proposed average time interval between two consecutive notifications
included in a "average-interval" Event header field parameter. The included in a "average-interval" Event header field parameter. The
value of this parameter is an integral number of seconds in decimal. value of this parameter is an integral number of seconds in decimal.
Subscribers implementing the minimum rate mechanism MUST include an
Event header field in any 200-class responses to NOTIFY requests.
A subscriber that wishes to update the previously agreed average rate
of notifications MUST include the updated "average-interval" Event
header field parameter in a subsequent SUBSCRIBE request or a 200-
class response to the NOTIFY request.
A subscriber that wishes to remove the average rate control from A subscriber that wishes to remove the average rate control from
notifications MUST construct a SUBSCRIBE request that does not notifications MUST indicate so by not including a "average-interval"
include the "average-interval" Event header field parameter. Event header field parameter in a subsequent SUBSCRIBE request or a
200-class response to the NOTIFY request.
The main consequence for the subscriber when applying the average The main consequence for the subscriber when applying the average
rate mechanism is that it can receive a notification even if nothing rate mechanism is that it can receive a notification even if nothing
has changed in the current state of the notifier. has changed in the current state of the notifier.
There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a
reference in a notification if nothing has changed. reference in a notification if nothing has changed.
6.2. Notifier Behavior 6.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the average rate mechanism MUST extract the A notifier that supports the average rate mechanism MUST extract the
value of the "average-interval" Event header parameter, and uses it value of the "average-interval" Event header parameter from a
to calculate the maximum time allowed between two transactions as SUBSCRIBE request or a 200-class response to the NOTIFY request and
defined in Section 6.3. This value can be adjusted by the notifier use it to calculate the maximum time allowed between two transactions
based on its local policy or other properties. as defined in Section 6.3.
A compliant notifier MUST reflect back the possibly adjusted average The notifier MAY decide to adjust the proposed average time interval
time interval in an "average-interval" Subscription-State header based on its local policy or other implementation-determined
field parameter of the subsequent NOTIFY requests. The indicated constraints. A compliant notifier MUST reflect back the possibly
"average-interval" value is adopted by the notifier, and the adjusted average time interval in an "average-interval" Subscription-
notification rate is adjusted accordingly. State header field parameter of the subsequent NOTIFY requests. The
indicated "average-interval" value is adopted by the notifier, and
the notification rate is adjusted accordingly.
A notifier that does not understand this extension will not reflect A notifier that does not understand this extension will not reflect
the "average-interval" Subscription-State header parameter in the the "average-interval" Subscription-State header parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter serves as a hint to
the subscriber that no rate control is supported by the notifier. the subscriber that no rate control is supported by the notifier.
A compliant notifier MUST generate notifications whenever the time A compliant notifier MUST generate notifications whenever the time
since the most recent notification exceeds the value calculated using since the most recent notification exceeds the value calculated using
the formula defined in Section 6.3. the formula defined in Section 6.3.
skipping to change at page 18, line 10 skipping to change at page 20, line 15
A subscriber SHOULD choose a "average-interval" value higher than A subscriber SHOULD choose a "average-interval" value higher than
the "min-interval" value, otherwise the notifier MUST adjust the the "min-interval" value, otherwise the notifier MUST adjust the
subscriber provided "average-interval" value to a value equivalent subscriber provided "average-interval" value to a value equivalent
or higher than the "min-interval" value. or higher than the "min-interval" value.
max-interval and average-interval: as both the parameters are max-interval and average-interval: as both the parameters are
designed as minimum rate mechanisms, this combination makes sense designed as minimum rate mechanisms, this combination makes sense
only in some corner cases. only in some corner cases.
A subscriber SHOULD choose a "max-interval" value higher than the A subscriber SHOULD choose a "max-interval" value higher than the
"average-interval" value, otherwise the notifier MUST not consider "average-interval" value, otherwise the notifier MUST NOT consider
the "max-interval" value. the "max-interval" value.
min-interval, max-interval and average-interval: this combination min-interval, max-interval and average-interval: this combination
makes little sense to be used. makes little sense to be used.
8. Syntax 8. Syntax
This section describes the syntax extensions required for the This section describes the syntax extensions required for the
different rate control mechanisms. different rate control mechanisms.
skipping to change at page 19, line 5 skipping to change at page 21, line 17
min-interval-param = "min-interval" EQUAL delta-seconds min-interval-param = "min-interval" EQUAL delta-seconds
event-param =/ max-interval-param event-param =/ max-interval-param
subexp-params =/ max-interval-param subexp-params =/ max-interval-param
max-interval-param = "max-interval" EQUAL delta-seconds max-interval-param = "max-interval" EQUAL delta-seconds
event-param =/ average-interval-param event-param =/ average-interval-param
subexp-params =/ average-interval-param subexp-params =/ average-interval-param
average-interval-param = "average-interval" EQUAL delta-seconds average-interval-param = "average-interval" EQUAL delta-seconds
8.3. Event header field usage in responses to the NOTIFY request
Implementations using the extensions described in this document MUST
include an Event header field in any 200-class responses to NOTIFY
requests. This table expands the table described in Section 7.2 of
SIP Events [RFC3265] allowing the Event header field to appear in a
200-class response to a NOTIFY request.
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Event 2xx - - - - - - - - m
9. IANA Considerations 9. IANA Considerations
This specification registers three new SIP header field parameters, This specification registers three new SIP header field parameters,
defined by the following information which is to be added to the defined by the following information which is to be added to the
Header Field Parameters and Parameter Values sub-registry under Header Field Parameters and Parameter Values sub-registry under
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
-------------------- --------------- ---------- --------- -------------------- --------------- ---------- ---------
skipping to change at page 19, line 37 skipping to change at page 22, line 17
Naturally, the security considerations listed in SIP events Naturally, the security considerations listed in SIP events
[RFC3265], which the rate control mechanisms described in this [RFC3265], which the rate control mechanisms described in this
document extends, apply in entirety. In particular, authentication document extends, apply in entirety. In particular, authentication
and message integrity SHOULD be applied to subscriptions with this and message integrity SHOULD be applied to subscriptions with this
extension. extension.
11. Acknowledgments 11. Acknowledgments
Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander
Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham
Khartabil and Dale Worley for support and/or review of this work. Khartabil, Dale Worley, Martin Thomson and Byron Campen for support
and/or review of this work.
Thanks to Brian Rosen for the idea of the "force" and "average" Thanks to Brian Rosen for the idea of the minimum and average rate
mechanisms, and to Adam Roach for the work on the averaging mechanisms, and Adam Roach for the work on the averaging algorithm
algorithm. and other feedback.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 20, line 23 skipping to change at page 22, line 49
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
12.2. Informative References 12.2. Informative References
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R. and B. Rosen, "A Document Format for Filtering Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
and Reporting Location Notications in the Presence Location Notifications in the Session Initiation Protocol
Information Document Format Location Object (PIDF-LO)", (SIP)", draft-ietf-geopriv-loc-filters-07 (work in
draft-ietf-geopriv-loc-filters-03 (work in progress), progress), October 2009.
November 2008.
[I-D.ietf-sipcore-subnot-etags] [I-D.ietf-sipcore-subnot-etags]
Niemi, A., "An Extension to Session Initiation Protocol Niemi, A., "An Extension to Session Initiation Protocol
(SIP) Events for Conditional Event Notification", (SIP) Events for Conditional Event Notification",
draft-ietf-sipcore-subnot-etags-02 (work in progress), draft-ietf-sipcore-subnot-etags-02 (work in progress),
April 2009. April 2009.
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003. (SigComp)", RFC 3320, January 2003.
 End of changes. 35 change blocks. 
117 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/