idnits 2.17.1 draft-ietf-sipcore-event-rate-control-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3265, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 922 has weird spacing: '...n-State min-...' == Line 924 has weird spacing: '...n-State max-...' == Line 926 has weird spacing: '...n-State aver...' == Line 935 has weird spacing: '...er Name compa...' (Using the creation date from RFC3265, updated by this document, for RFC5378 checks: 2001-07-05) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 937, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft K. Kiss 4 Updates: 3265 (if approved) Nokia 5 Intended status: Standards Track S. Loreto 6 Expires: April 21, 2011 Ericsson 7 October 18, 2010 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-05 13 Abstract 15 This document specifies mechanisms for adjusting the rate of Session 16 Initiation Protocol (SIP) event notifications. These mechanisms can 17 be applied in subscriptions to all SIP event packages. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Use Case for Limiting the Maximum Rate of Notifications . 5 69 3.2. Use Case for Setting a Minimum Rate for Notifications . . 6 70 3.3. Use Case for Specifying an Adaptive Minimum Rate of 71 Notifications . . . . . . . . . . . . . . . . . . . . . . 7 72 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 8 75 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 9 76 5. Operation of the Maximum Rate Mechanism . . . . . . . . . . . 9 77 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 9 78 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Selecting the Maximum Rate . . . . . . . . . . . . . . . . 11 80 5.4. The Maximum Rate Mechanism for Resource List Server . . . 11 81 5.5. Buffer Policy Description . . . . . . . . . . . . . . . . 13 82 5.5.1. Partial State Notifications . . . . . . . . . . . . . 13 83 5.5.2. Full State Notifications . . . . . . . . . . . . . . . 13 84 5.6. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 85 6. Operation of the Minimum Rate Mechanism . . . . . . . . . . . 14 86 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 87 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 88 7. Operation of the Adaptive Minimum Rate Mechanism . . . . . . . 16 89 7.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 90 7.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16 91 7.3. Calculating the Timeout . . . . . . . . . . . . . . . . . 17 92 8. Usage of the Maximum Rate, Minimum Rate and Adaptive 93 Minimum Rate Mechanisms in a combination . . . . . . . . . . . 18 94 9. Protocol Element Definitions . . . . . . . . . . . . . . . . . 19 95 9.1. "min-interval", "max-interval" and "average-interval" 96 Header Field Parameters . . . . . . . . . . . . . . . . . 19 97 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 9.3. Event Header Field Usage in Responses to the NOTIFY 99 request . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 The SIP events framework [RFC3265] defines a generic framework for 111 subscriptions to and notifications of events related to SIP systems. 112 This framework defines the methods SUBSCRIBE and NOTIFY, and 113 introduces the concept of an event package, which is a concrete 114 application of the SIP events framework to a particular class of 115 events. 117 One of the things the SIP events framework mandates is that each 118 event package specification defines an absolute maximum on the rate 119 at which notifications are allowed to be generated by a single 120 notifier. Such a limit is provided in order to reduce network load. 122 All of the existing event package specifications include a maximum 123 notification rate recommendation, ranging from once in every five 124 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 126 Per the SIP events framework, each event package specification is 127 also allowed to define additional throttle mechanisms which allow the 128 subscriber to further limit the rate of event notification. So far 129 none of the event package specifications have defined such a 130 mechanism. 132 The resource list extension [RFC4662] to the SIP events framework 133 also deals with rate limiting of event notifications. The extension 134 allows a subscriber to subscribe to a heterogeneous list of resources 135 with a single SUBSCRIBE request, rather than having to install a 136 subscription for each resource separately. The event list 137 subscription also allows rate limiting, or throttling of 138 notifications, by means of the Resource List Server (RLS) buffering 139 notifications of resource state changes, and sending them in batches. 140 However, the event list mechanism provides no means for the 141 subscriber to set the interval for the throttling; it is strictly an 142 implementation decision whether batching of notifications is 143 supported, and by what means. 145 This document defines an extension to the SIP events framework 146 defining the following three Event header field parameters that allow 147 a subscriber to set a maximum, a minimum and an adaptive minimum rate 148 of event notifications generated by the notifier: 150 min-interval: specifies a minimum notification time period (maximum 151 rate) between two notifications, in seconds. 153 max-interval: specifies a maximum notification time period (minimum 154 rate) between two notifications, in seconds. 156 average-interval: specifies an average maximum notification time 157 period (adaptive minimum rate) between two notifications, in 158 seconds. 160 The requirements and model are further discussed in Section 3. All 161 these mechanisms are simply timer values that indicate the minimum, 162 maximum and average maximum time period allowed between two 163 notifications. As a result of these mechanisms, a compliant notifier 164 will adjust the rate at which it generates notifications. 166 These mechanisms are applicable to any event subscription, both 167 single event subscription and event list subscription. 169 2. Definitions and Document Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119] and 174 indicate requirement levels for compliant implementations. 176 Indented passages such as this one are used in this document to 177 provide additional information and clarifying text. They do not 178 contain normative protocol behavior. 180 3. Overview 182 3.1. Use Case for Limiting the Maximum Rate of Notifications 184 A presence client in a mobile device contains a list of 100 buddies 185 or presentities. In order to decrease the processing and network 186 load of watching 100 presentities, the presence client has employed a 187 Resource List Server (RLS) with the list of buddies, and therefore 188 only needs a single subscription to the RLS in order to receive 189 notification of the presence state of the resource list. 191 In order to control the buffer policy of the RLS, the presence client 192 sets a maximum rate ("min-interval" parameter), i.e. a minimum time 193 interval between two notifications. The RLS will buffer 194 notifications that do not comply with the maximum rate and batch all 195 of the buffered state changes together in a single notification only 196 when allowed by the maximum rate. The maximum rate applies to the 197 overall resource list, which means that there is a hard cap imposed 198 by the maximum rate to the number of notifications the presence 199 client can expect to receive. For example, with a "min-interval" of 200 20 seconds, the presence application can expect to receive a 201 notification no more frequently than every 20 seconds. 203 The presence client can also modify the "min-interval" parameter 204 during the lifetime of the subscription. For example, if the User 205 Interface (UI) of the application shows inactivity for a period of 206 time, it can simply pause the notifications by setting the "min- 207 interval" parameter to the subscription expiration time, while still 208 keeping the subscription alive. When the user becomes active again, 209 the presence client can resume the stream of notifications by re- 210 subscribing with a "min-interval" parameter set to the earlier used 211 value. Application of the mechanism defined by RFC 5839 [RFC5839] 212 can also eliminate the transmission of a (full-state) notification 213 carrying the latest resource state to the presence client after a 214 subscription refresh. 216 3.2. Use Case for Setting a Minimum Rate for Notifications 218 A location application is monitoring the movement of a target. In 219 order to decrease the processing and network load, the location 220 application has made a subscription with a set of location filters 221 [I-D.ietf-geopriv-loc-filters] that specify trigger criteria, e.g. to 222 send an update only when the target has moved at least n meters. 223 However, the application is also interested in receiving the current 224 state periodically even if the state of the target has not changed 225 enough to satisfy any of the trigger criteria, e.g. has not moved at 226 least n meters within the period. 228 In order to control the actual state, the location application sets a 229 minimum rate ("max-interval" parameter), i.e. a maximum time interval 230 between two notifications. 232 The location application can also modify the "max-interval" parameter 233 during the lifetime of the subscription. When the subscription to 234 the movement of a target is made, the notifier may not have the 235 location information available. Thus, the first notification might 236 be empty, or certain values might be absent. An important use case 237 is placing constraints on when complete state should be provided 238 after creating the subscription. The "max-interval" parameter 239 indicates to the notifier the maximum amount of time that should be 240 allowed to elapse between NOTIFY requests containing complete state 241 information. Once state is acquired and the second notification is 242 sent, the subscriber updates or changes the "max-interval" parameter 243 to a more sensible value. This update can be performed in the 200 OK 244 response to the NOTIFY request that contains the complete state 245 information. 247 3.3. Use Case for Specifying an Adaptive Minimum Rate of Notifications 249 The minimum rate mechanism introduces a static and instantaneous rate 250 control without the functionality to increase or decrease the 251 notification frequency adaptively. However, there are some 252 applications that would work better with an adaptive minimum rate 253 control. This section illustrates the tracking scenario. 255 A tracking application is monitoring the movement of a target. In 256 order to decrease the processing in the application, the tracking 257 application wants to make a subscription that dynamically decreases 258 the minimum rate of notifications if the target has sent out several 259 notifications recently. However, if there have have been only few 260 recent notifications by the target, the tracking application wants 261 the minimum rate of notifications to increase. 263 The application sets an adaptive minimum rate ("average-interval" 264 parameter), i.e. an average maximum time interval between two 265 notifications. The "average-interval" parameter value is used by the 266 notifier to dynamically calculate the actual maximum time ("timeout" 267 parameter) between two notifications. In order to dynamically 268 calculate the maximum time, the notifier takes into consideration the 269 frequency at which notifications have been sent recently. In the 270 adaptive minimum rate mechanism the notifier can increase or decrease 271 the notification frequency compared to minimum rate mechanism based 272 on the recent number of notifications sent out in the last period. 274 The tracking application can also modify the "average-interval" 275 parameter during the lifetime of the subscription. 277 3.4. Requirements 279 REQ1: The subscriber must be able to set a maximum rate ("min- 280 interval" parameter) of notifications in a specific 281 subscription. 283 REQ2: The subscriber must be able to set a minimum rate ("max- 284 interval" parameter) of notifications in a specific 285 subscription. 287 REQ3: The subscriber must be able to set an adaptive minimum rate 288 ("average-interval" parameter), which adjusts the minimum 289 rate of notifications based on a moving average. 291 REQ4: It must be possible to apply the maximum rate, the minimum 292 rate and the adaptive minimum rate mechanisms all together, 293 or in any combination, in a specific subscription. 295 REQ5: It must be possible to use any of the different rate control 296 mechanisms in subscriptions to any events. 298 REQ6: It must be possible to use any of the different rate control 299 mechanisms together with any other event filtering 300 mechanisms. 302 REQ7: The notifier must be allowed to use a policy in which the 303 "min-interval", "max-interval" and "average-interval" 304 paremeters are adjusted from the value given by the 305 subscriber. 307 For example, due to congestion reasons, local policy at 308 the notifier could temporarily dictate a policy that in 309 effect increases the subscriber-configured minimum time 310 period between two notifications. In another example, the 311 notifier can decrease the proposed minimum time by the 312 subscriber to match it with the remaining expiry time left 313 for the subscription. 315 REQ8: The different rate control mechanisms must address corner 316 cases for setting the time periods between two notifications. 317 At a minimum, the mechanisms must address the situation when 318 the time between two notifications would exceed the 319 subscription duration and should provide mechanisms for 320 avoiding this situation. 322 REQ9: The different rate control mechanisms must be possible to be 323 invoked, modified, or removed in the course of an active 324 subscription. 326 REQ10: The different rate control mechanisms must allow for the 327 application of authentication and integrity protection 328 mechanisms to subscriptions invoking that mechanism. 330 4. Basic Operations 332 4.1. Subscriber Behavior 334 In general, the way in which a subscriber generates SUBSCRIBE 335 requests and processes NOTIFY requests is according to RFC 3265 336 [RFC3265]. 338 A subscriber that wants to have a maximum, minimum or adaptive 339 minimum rate of event notifications in a specific event subscription 340 does so by including a "min-interval", "max-interval" or "average- 341 interval" Event header field parameter(s) as part of the SUBSCRIBE 342 request. 344 A subscriber that wants to update a previously agreed event rate 345 control parameter does so by including the updated "min-interval", 346 "max-interval" or "average-interval" Event header field parameter(s) 347 as part of a subsequent SUBSCRIBE request or a 2xx response to the 348 NOTIFY request. If the subscriber did not include at least one of 349 the "min-interval, "max-interval", or "average-interval" header field 350 parameters in the most recent SUBSCRIBE request in a given dialog, it 351 MUST NOT include an Event header field with any of those parameters 352 in a 2xx response to a NOTIFY request in that dialog. 354 4.2. Notifier Behavior 356 In general, the way in which a notifier processes SUBSCRIBE requests 357 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 359 A notifier that supports the different rate control mechanisms will 360 comply with the value given in "min-interval", "max-interval" and 361 "average-interval" parameters and adjust its rate of notification 362 accordingly. However, if the notifier needs to lower the 363 subscription expiration value or if a local policy or other 364 implementation-determined constraint at the notifier can not satisfy 365 the rate control request, then the notifier can adjust (i.e. increase 366 or decrease) appropriately the subscriber requested rate control. 368 5. Operation of the Maximum Rate Mechanism 370 5.1. Subscriber Behavior 372 A subscriber that wishes to apply a maximum rate to notifications in 373 a subscription MUST construct a SUBSCRIBE request that includes a 374 minimum time interval between two consecutive notifications included 375 in the "min-interval" Event header field parameter. The value of 376 this parameter is an integral number of seconds in decimal. 378 Note that the witnessed time between two consecutive received 379 notifications may not conform to the "min-interval" value for a 380 number of reasons. For example, network jitter and 381 retransmissions may result in the subscriber receiving the 382 notifications with smaller intervals than the "min-interval" value 383 recommends. 385 A subscriber that wishes to update the previously agreed maximum rate 386 of notifications MUST include the updated "min-interval" Event header 387 field parameter in a subsequent SUBSCRIBE request or a 2xx response 388 to the NOTIFY request. 390 A subscriber that wishes to remove the maximum rate control from 391 notifications MUST indicate so by not including a "min-interval" 392 Event header field parameter in a subsequent SUBSCRIBE request or a 393 2xx response to the NOTIFY request. 395 There are two main consequences for the subscriber when applying the 396 maximum rate mechanism: state transitions may be lost, and event 397 notifications may be delayed. If either of these side effects 398 constitute a problem to the application that utilizes the event 399 notifications, developers are instructed not to use the mechanism. 401 5.2. Notifier Behavior 403 A notifier that supports the maximum rate mechanism MUST extract the 404 value of the "min-interval" Event header parameter from a SUBSCRIBE 405 request or a 2xx response to the NOTIFY request and use it as the 406 suggested minimum time allowed between two notifications. This value 407 can be adjusted by the notifier, as defined in Section 5.3. 409 A compliant notifier MUST reflect back the possibly adjusted minimum 410 time interval in a "min-interval" Subscription-State header field 411 parameter of the subsequent NOTIFY requests. The indicated "min- 412 interval" value is adopted by the notifier, and the notification rate 413 is adjusted accordingly. 415 A notifier that does not understand this extension will not reflect 416 the "min-interval" Subscription-State header field parameter in the 417 NOTIFY requests; the absence of this parameter indicates to the 418 subscriber that no rate control is supported by the notifier. 420 A compliant notifier MUST NOT generate notifications more frequently 421 than the maximum rate allows for, except when generating the 422 notification either upon receipt of a SUBSCRIBE request (the first 423 notification), when the subscription state is changing from "pending" 424 to "active" state or upon termination of the subscription (the last 425 notification). Such notifications reset the timer for the next 426 notification. 428 When a local policy dictates a maximum rate for notifications, a 429 notifier will not generate notifications more frequently than the 430 local policy maximum rate, even if the subscriber is not asking for 431 maximum rate control. The notifier MAY inform the subscriber about 432 such local policy maximum rate using the "min-interval" Subscription- 433 State header field parameter included in the subsequent NOTIFY 434 requests. 436 Retransmissions of NOTIFY requests are not affected by the maximum 437 rate mechanism, i.e., the maximum rate mechanism only applies to the 438 generation of new transactions. In other words, the maximum rate 439 mechanism does not in any way break or modify the normal 440 retransmission mechanism specified in RFC 3261 [RFC3261]. 442 5.3. Selecting the Maximum Rate 444 Special care needs to be taken when selecting the "min-interval" 445 value. For example, the maximum rate could potentially set a minimum 446 time value between notifications that exceeds the subscription 447 expiration value. Such a configuration would effectively quench the 448 notifier, resulting in exactly two notifications to be generated. If 449 the subscriber requests a "min-interval" value greater than the 450 subscription expiration, the notifier MUST lower the "min-interval" 451 value and set it to the expiration time left. According to RFC 3265 452 [RFC3265] the notifier may also shorten the subscription expiry 453 anytime during an active subscription. If the subscription expiry is 454 shortened during an active subscription, the notifier MUST also lower 455 the "min-interval" value and set it to the reduced expiration time. 457 In some cases it makes sense to pause the notification stream on an 458 existing subscription dialog on a temporary basis without terminating 459 the subscription, e.g. due to inactivity on the application user 460 interface. Whenever a subscriber discovers the need to perform the 461 notification pause operation, it SHOULD set the "min-interval" value 462 to the remaining subscription expiration value. This results in 463 receiving no further notifications until the subscription expires or 464 the subscriber sends a SUBSCRIBE request resuming notifications. 466 The notifier MAY decide to increase or decrease the proposed maximum 467 rate value by the subscriber based on its local policy, static 468 configuration or other implementation-determined constraints. The 469 notifier MUST include the adjusted "min-interval" value in the 470 Subscription-State header field's "min-interval" parameter in each of 471 the NOTIFY requests. In addition, different event packages MAY 472 define additional constraints to the allowed "min-interval" 473 intervals. Such constraints are out of the scope of this 474 specification. 476 5.4. The Maximum Rate Mechanism for Resource List Server 478 When applied to a list subscription [RFC4662], the maximum rate 479 mechanism has some additional considerations. Specifically, the 480 maximum rate applies to the aggregate notification stream resulting 481 from the list subscription, rather than explicitly controlling the 482 notification of each of the implied constituent events. Moreover, 483 the RLS can use the maximum rate mechanism on its own to control the 484 rate of the back-end subscriptions to avoid overflowing its buffer. 486 The notifier is responsible for sending out event notifications upon 487 state changes of the subscribed resource. We can model the notifier 488 as consisting of four components: the event state resource(s), the 489 Resource List Server (RLS) (or any other notifier), a notification 490 buffer, and finally the subscriber, or watcher of the event state, as 491 shown in Figure 1. 493 +--------+ 494 | Event | 495 +--------+ |Resource| +--------+ 496 | Event | +--------+ | Event | 497 |Resource| | |Resource| 498 +---.=---+ | +---=----+ 499 `-.. | _.--' 500 ``-._ | _.--' 501 +'--'--'-+ 502 |Resource| 503 | List | 504 | Server | 505 +---.----+ 506 | 507 | 508 )--+---( 509 | | .------------. 510 |Buffer|<======'min-interval| 511 | | `------------' 512 )--.---( 513 | 514 | 515 .---+---. 516 | Event | 517 |Watcher| 518 `-------' 520 Figure 1: Model for the Resource List Server (RLS) Supporting 521 Throttling 523 In short, the RLS reads event state changes from the event state 524 resource, either by creating a back end subscription, or by other 525 means; it packages them into event notifications and submits them 526 into the output buffer. The rate at which this output buffer drains 527 is controlled by the subscriber via the maximum rate mechanism. When 528 a set of notifications are batched together, the way in which 529 overlapping resource state is handled depends on the type of the 530 resource state: 532 In theory, there are many buffer policies that the notifier could 533 implement. However, we only concentrate on two practical buffer 534 policies in this specification, leaving additional ones for 535 further study and out of the scope of this specification. These 536 two buffer policies depend on the mode in which the notifier is 537 operating. 539 Full-state: Last (most recent) full state notification of each 540 resource is sent out, and all others in the buffer are discarded. 541 This policy applies to those event packages that carry full-state 542 notifications. 544 Partial-state: The state deltas of each buffered partial 545 notification per resource are merged, and the resulting 546 notification is sent out. This policy applies to those event 547 packages that carry partial-state notifications. 549 5.5. Buffer Policy Description 551 5.5.1. Partial State Notifications 553 With partial notifications, the notifier needs to maintain a separate 554 buffer for each subscriber since each subscriber may have a different 555 value for the maximum rate of notifications. The notifier will 556 always need to keep both a copy of the current full state of the 557 resource F, as well as the last successfully communicated full state 558 view F' of the resource in a specific subscription. The construction 559 of a partial notification then involves creating a difference of the 560 two states, and generating a notification that contains that 561 difference. 563 When the maximum rate mechanism is applied to the subscription, it is 564 important that F' is replaced with F only when the difference of F 565 and F' was already included in a partial state notification to the 566 subscriber allowed by the maximum rate mechanism. Additionally, the 567 notifier implementation SHOULD check to see that the size of an 568 accumulated partial state notification is smaller than the full 569 state, and if not, the notifier SHOULD send the full state 570 notification instead. 572 5.5.2. Full State Notifications 574 With full state notifications, the notifier only needs to keep the 575 full state of the resource, and when that changes, send the resulting 576 notification over to the subscriber. 578 When the maximum rate mechanism is applied to the subscription, the 579 notifier receives the state changes of the resource, and generates a 580 notification. If there is a pending notification, the notifier 581 simply replaces that notification with the new notification, 582 discarding the older state. 584 5.6. Estimated Bandwidth Savings 586 It is difficult to estimate the total bandwidth savings accrued by 587 using the maximum rate mechanism over a subscription, since such 588 estimates will vary depending on the usage scenarios. However, it is 589 easy to see that given a subscription where several full state 590 notifications would have normally been sent in any given interval set 591 by the "min-interval" parameter, only a single notification is sent 592 during the same interval when using the maximum rate mechanism 593 yielding bandwidth savings of several times the notification size. 595 With partial-state notifications, drawing estimates is further 596 complicated by the fact that the states of consecutive updates may or 597 may not overlap. However, even in the worst case scenario, where 598 each partial update is to a different part of the full state, a rate 599 controlled notification merging all of these n partial states 600 together should at a maximum be the size of a full-state update. In 601 this case, the bandwidth savings are approximately n times the size 602 of the header fields of the NOTIFY request. 604 It is also true that there are several compression schemes available 605 that have been designed to save bandwidth in SIP, e.g., SigComp 606 [RFC3320] and TLS compression [RFC3943]. However, such compression 607 schemes are complementary rather than competing mechanisms to the 608 maximum rate mechanism. After all, they can both be applied 609 simultaneously. 611 6. Operation of the Minimum Rate Mechanism 613 6.1. Subscriber Behavior 615 A subscriber that wishes to apply a minimum rate to notifications in 616 a subscription MUST construct a SUBSCRIBE request that includes a 617 maximum time interval between two consecutive notifications included 618 in the "max-interval" Event header field parameter. The value of 619 this parameter is an integral number of seconds in decimal. 621 A subscriber that wishes to update the previously agreed minimum rate 622 of notifications MUST include the updated "max-interval" Event header 623 field parameter in a subsequent SUBSCRIBE request or a 2xx response 624 to the NOTIFY request. 626 A subscriber that wishes to remove the minimum rate control from 627 notifications MUST indicate so by not including a "max-interval" 628 Event header field parameter in a subsequent SUBSCRIBE request or a 629 2xx response to the NOTIFY request. 631 The main consequence for the subscriber when applying the minimum 632 rate mechanism is that it can receive a notification even if nothing 633 has changed in the current state of the notifier. However, RFC 5839 634 [RFC5839] defines a mechanism that allows sending only an etag 635 instead of the full resource state in a notification if the state has 636 not changed. 638 6.2. Notifier Behavior 640 A notifier that supports the minimum rate mechanism MUST extract the 641 value of the "max-interval" Event header field parameter from a 642 SUBSCRIBE request or a 2xx response to the NOTIFY request and use it 643 as the suggested maximum time allowed between two notifications. 645 The notifier MAY decide to increase or decrease the proposed minimum 646 rate value based on its local policy, static configuration or other 647 implementation-determined constraints. A compliant notifier MUST 648 reflect back the possibly adjusted maximum time interval in a "max- 649 interval" Subscription-State header field parameter of the subsequent 650 NOTIFY requests. The indicated "max-interval" value is adopted by 651 the notifier, and the notification rate is adjusted accordingly. 653 A notifier that does not understand this extension, will not reflect 654 the "max-interval" Subscription-State header field parameter in the 655 NOTIFY requests; the absence of this parameter indicates to the 656 subscriber that no rate control is supported by the notifier. 658 A compliant notifier MUST generate notifications when state changes 659 occur or when the time since the most recent notification exceeds the 660 value in the "max-interval" parameter. Depending on the event 661 package and subscriber preferences indicated in the SUBSCRIBE 662 request, the NOTIFY request sent as a result of a max-interval 663 expiration MUST contain either the current full state or the partial 664 state showing the difference between the current state and the last 665 successfully communicated state. 667 Retransmissions of NOTIFY requests are not affected by the minimum 668 rate mechanism, i.e., the minimum rate mechanism only applies to the 669 generation of new transactions. In other words, the minimum rate 670 mechanism does not in any way break or modify the normal 671 retransmission mechanism. 673 7. Operation of the Adaptive Minimum Rate Mechanism 675 7.1. Subscriber Behavior 677 A subscriber that wishes to apply an adaptive minimum rate to 678 notifications in a subscription MUST construct a SUBSCRIBE request 679 that includes an average maximum time interval between two 680 consecutive notifications included in a "average-interval" Event 681 header field parameter. The value of this parameter is an integral 682 number of seconds in decimal. 684 A subscriber that wishes to update the previously agreed adaptive 685 minimum rate of notifications MUST include the updated "average- 686 interval" Event header field parameter in a subsequent SUBSCRIBE 687 request or a 2xx response to the NOTIFY request. 689 A subscriber that wishes to remove the adaptive minimum rate control 690 from notifications MUST indicate so by not including a "average- 691 interval" Event header field parameter in a subsequent SUBSCRIBE 692 request or a 2xx response to the NOTIFY request. 694 The main consequence for the subscriber when applying the adative 695 minimum rate mechanism is that it can receive a notification even if 696 nothing has changed in the current state of the notifier. However, 697 RFC 5839 [RFC5839] defines a mechanism that allows sending only an 698 etag instead of the full resource state in a notification if the 699 state has not changed. 701 7.2. Notifier Behavior 703 A notifier that supports the adaptive minimum rate mechanism MUST 704 extract the value of the "average-interval" Event header parameter 705 from a SUBSCRIBE request or a 2xx response to the NOTIFY request and 706 use it to calculate the actual maximum time between two notifications 707 as defined in Section 7.3. 709 The notifier MAY decide to increase or decrease the proposed 710 "average-interval" based on its local policy, static configuration or 711 other implementation-determined constraints. A compliant notifier 712 MUST reflect back the possibly adjusted time interval in an "average- 713 interval" Subscription-State header field parameter of the subsequent 714 NOTIFY requests. The indicated "average-interval" value is adopted 715 by the notifier, and the notification rate is adjusted accordingly. 717 A notifier that does not understand this extension will not reflect 718 the "average-interval" Subscription-State header parameter in the 719 NOTIFY requests; the absence of this parameter indicates to the 720 subscriber that no rate control is supported by the notifier. 722 A compliant notifier SHOULD generate notifications when state changes 723 occur or when the time since the most recent notification exceeds the 724 value calculated using the formula defined in Section 7.3. 726 The adaptive minimum rate mechanism is implemented as follows: 728 1) When a subscription is first created, the notifier creates a 729 record that keeps track of the number of notifications that have 730 been sent in the "period". This record is initialized to contain 731 a history of having sent one message every "average-interval" 732 seconds for the "period". 734 2) The "timeout" value is calculated according to the equation given 735 in Section 7.3. 737 3) If the timeout period passes without a NOTIFY request being sent 738 in the subscription, then the current resource state is sent 739 (subject to any filtering associated with the subscription). 741 4) Whenever a NOTIFY request is sent (regardless of whether due to a 742 timeout or a state change), the notifier updates the notification 743 history record, recalculates the value of "timeout," and returns 744 to step 3. 746 Retransmissions of NOTIFY requests are not affected by the timeout, 747 i.e., the timeout only applies to the generation of new transactions. 748 In other words, the timeout does not in any way break or modify the 749 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 751 7.3. Calculating the Timeout 753 The formula used to vary the absolute pacing in a way that will meet 754 the adaptive minimum rate requested over the period is given in 755 equation (1): 757 timeout = (average-interval ^ 2) * count / period (1) 759 The output of the formula, "timeout", is the time to the next 760 notification, expressed in seconds. The formula has three inputs: 762 average-interval: The value of the "average-interval" parameter 763 conveyed in the Subscription-State header field, in seconds. 765 period: The rolling average period, in seconds. The value of the 766 "period" parameter is chosen by the notifier, however the notifier 767 MUST choose a value greater than the value of the "average- 768 interval" parameter. The granularity of the values for the 769 "period" parameter is set by local policy at the notifier. It is 770 an implementation decision whether the notifier uses the same 771 value of the "period" parameter for all subscriptions or 772 individual values for each subscription. 774 count: The number of notifications that have been sent during the 775 last "period" of seconds not including any retransmissions of 776 requests. 778 In case both the maximum rate and the adaptive minimum rate 779 mechanisms are used in the same subscription the formula used to 780 dynamically calculate the timeout is given in equation (2): 782 timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) 784 min-interval: The value of the "min-interval" parameter conveyed in 785 the Subscription-State header field, in seconds. 787 The formula in (2) makes sure that for all the possible values of the 788 "min-interval" and "average-interval" parameters, with "average- 789 interval" > "min-interval", the timeout never results in a lower 790 value than the value of the "min-interval" parameter. 792 In some situation it may be beneficial for the notifier to achieve an 793 adaptive minimum rate in a different way than the algorithm detailed 794 in this document allows. However, the notifier MUST comply with any 795 "min-interval" or "max-interval" parameters that have been 796 negotiated. 798 8. Usage of the Maximum Rate, Minimum Rate and Adaptive Minimum Rate 799 Mechanisms in a combination 801 Applications can subscribe to an event package using all the rate 802 control mechanisms individually, or in combination; in fact there is 803 no technical incompatibility among them. However there are some 804 combinations of the different rate control mechanisms that make 805 little sense to be used together. This section lists all the 806 combinations that are possible to insert in a subscription; the 807 utility to use each combination in a subscription is also analyzed. 809 maximum rate and minimum rate: This combination allows to reduce the 810 notification frequency rate, but at the same time assures the 811 reception of a notification every time the most recent 812 notification exceeds a specified interval. 814 A subscriber SHOULD choose a "max-interval" value higher than the 815 "min-interval" value, otherwise the notifier MUST adjust the 816 subscriber provided "max-interval" value to a value equal to or 817 higher than the "min-interval" value. 819 maximum rate and adaptive minimum rate: It works in a similar way as 820 the combination above, but with the difference that the interval 821 at which notifications are assured changes dynamically. 823 A subscriber SHOULD choose a "average-interval" value higher than 824 the "min-interval" value, otherwise the notifier MUST adjust the 825 subscriber provided "average-interval" value to a value equal to 826 or higher than the "min-interval" value. 828 minimum rate and adaptive minimum rate: When using the adaptive 829 minimum rate mechanism, frequent state changes in a short period 830 can result in no notifications for a longer period following the 831 short period. The addition of the minimum rate mechanism ensures 832 the subscriber always receives notifications after a specified 833 interval. 835 A subscriber SHOULD choose a "max-interval" value higher than the 836 "average-interval" value, otherwise the notifier MUST NOT consider 837 the "max-interval" value. 839 maximum rate, minimum rate and adaptive minimum rate: This 840 combination makes little sense to be used although not forbidden. 842 A subscriber SHOULD choose a "max-interval" and "average-interval" 843 values higher than the "min-interval" value, otherwise the 844 notifier MUST adjust the subscriber provided "max-interval" and 845 "average-interval" values to a value equal to or higher than the 846 "min-interval" value. 848 A subscriber SHOULD choose a "max-interval" value higher than the 849 "average-interval" value, otherwise the notifier MUST NOT consider 850 the "max-interval" value. 852 9. Protocol Element Definitions 854 This section describes the protocol extensions required for the 855 different rate control mechanisms. 857 9.1. "min-interval", "max-interval" and "average-interval" Header Field 858 Parameters 860 The "min-interval", "max-interval" and "average-interval" parameters 861 are added to the rule definitions of the Event header field and the 862 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 863 of this parameter is described in Section 5, Section 6 and Section 7. 865 9.2. Grammar 867 This section describes the Augmented BNF [RFC5234] definitions for 868 the new header field parameters. Note that we derive here from the 869 ruleset present in RFC 3265 [RFC3265], adding additional alternatives 870 to the alternative sets of "event-param" and "subexp-params" defined 871 therein. 873 event-param =/ min-interval-param 874 subexp-params =/ min-interval-param 875 min-interval-param = "min-interval" EQUAL delta-seconds 877 event-param =/ max-interval-param 878 subexp-params =/ max-interval-param 879 max-interval-param = "max-interval" EQUAL delta-seconds 881 event-param =/ average-interval-param 882 subexp-params =/ average-interval-param 883 average-interval-param = "average-interval" EQUAL delta-seconds 885 9.3. Event Header Field Usage in Responses to the NOTIFY request 887 This table expands the table described in Section 7.2 of RFC 3265 888 [RFC3265] allowing the Event header field to appear in a 2xx response 889 to a NOTIFY request. The use of the Event header field in responses 890 other than 2xx to NOTIFY requests is undefined and out of scope of 891 this specification. 893 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 894 ----------------------------------------------------------------- 895 Event 2xx - - - - - - - - o 897 A subscriber that wishes to update the value for maximum, minimum or 898 adaptive minimum rate of notifications can do so by including all 899 desired values for the "min-interval", "max-interval" and "average- 900 interval" parameters in an Event header field of the 2xx response to 901 a NOTIFY request. Any of the other header field parameters currently 902 defined for the Event header field by other specifications do not 903 have a meaning if the Event header field is included in the 2xx 904 response to the NOTIFY request. These header field parameters MUST 905 be ignored by the notifier, if present. 907 The event type listed in the Event header field of the 2xx response 908 to the NOTIFY request MUST match the event type of the Event header 909 field in the corresponding NOTIFY request. 911 10. IANA Considerations 913 This specification registers three new SIP header field parameters, 914 defined by the following information which is to be added to the 915 Header Field Parameters and Parameter Values sub-registry under 916 http://www.iana.org/assignments/sip-parameters. 918 Predefined 919 Header Field Parameter Name Values Reference 920 -------------------- --------------- ---------- --------- 921 Event min-interval No [RFCxxxx] 922 Subscription-State min-interval No [RFCxxxx] 923 Event max-interval No [RFCxxxx] 924 Subscription-State max-interval No [RFCxxxx] 925 Event average-interval No [RFCxxxx] 926 Subscription-State average-interval No [RFCxxxx] 928 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 929 this specification, when assigned.) 931 This specification also updates the reference defining the Event 932 header field in the Header Fields sub-registry under 933 http://www.iana.org/assignments/sip-parameters. 935 Header Name compact Reference 936 ----------- ------- --------- 937 Event o [RFC3265][RFCxxxx] 939 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 940 this specification, when assigned.) 942 11. Security Considerations 944 Naturally, the security considerations listed in RFC 3265 [RFC3265], 945 which the rate control mechanisms described in this document extends, 946 apply in entirety. In particular, authentication and message 947 integrity SHOULD be applied to subscriptions with this extension. 949 RFC 3265 [RFC3265] recommends the integrity protection of the Event 950 header field of SUBSCRIBE requests. Implementations of this 951 extension SHOULD also provide integrity protection for the Event 952 header field included in the 2xx response to the NOTIFY request. 954 Without integrity protection an eavesdropper could see and modify the 955 Event header field; or it could also manipulate the transmission of a 956 200 (OK) response to the NOTIFY request in order to suppress or flood 957 notifications without the subscriber seeing what caused the problem. 959 When the maximum rate mechanism involves partial state notifications, 960 the security considerations listed in RFC 5263 [RFC5263] apply in 961 entirety. 963 12. Acknowledgments 965 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 966 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 967 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 968 Michael Procter and Janet Gunn for support and/or review of this 969 work. 971 Thanks to Brian Rosen for the idea of the minimum and adaptive 972 minimum rate mechanisms, and Adam Roach for the work on the algorithm 973 for the adaptive minimum rate mechanism and other feedback. 975 13. References 977 13.1. Normative References 979 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 980 Requirement Levels", BCP 14, RFC 2119, March 1997. 982 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 983 A., Peterson, J., Sparks, R., Handley, M., and E. 984 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 985 June 2002. 987 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 988 Event Notification", RFC 3265, June 2002. 990 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 991 Initiation Protocol (SIP) Event Notification Extension for 992 Resource Lists", RFC 4662, August 2006. 994 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 995 Specifications: ABNF", STD 68, RFC 5234, January 2008. 997 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 998 Khartabil, "Session Initiation Protocol (SIP) Extension 999 for Partial Notification of Presence Information", 1000 RFC 5263, September 2008. 1002 13.2. Informative References 1004 [I-D.ietf-geopriv-loc-filters] 1005 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1006 Location Notifications in the Session Initiation Protocol 1007 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1008 progress), March 2010. 1010 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1011 Liu, Z., and J. Rosenberg, "Signaling Compression 1012 (SigComp)", RFC 3320, January 2003. 1014 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1015 Package for Registrations", RFC 3680, March 2004. 1017 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1018 Indication Event Package for the Session Initiation 1019 Protocol (SIP)", RFC 3842, August 2004. 1021 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1022 Initiation Protocol (SIP)", RFC 3856, August 2004. 1024 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1025 Package for the Session Initiation Protocol (SIP)", 1026 RFC 3857, August 2004. 1028 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1029 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1030 November 2004. 1032 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1033 Initiation Protocol (SIP) Events for Conditional Event 1034 Notification", RFC 5839, May 2010. 1036 Authors' Addresses 1038 Aki Niemi 1039 Nokia 1040 P.O. Box 407 1041 NOKIA GROUP, FIN 00045 1042 Finland 1044 Phone: +358 50 389 1644 1045 Email: aki.niemi@nokia.com 1046 Krisztian Kiss 1047 Nokia 1048 323 Fairchild Dr 1049 Mountain View, CA 94043 1050 US 1052 Phone: +1 650 391 5969 1053 Email: krisztian.kiss@nokia.com 1055 Salvatore Loreto 1056 Ericsson 1057 Hirsalantie 11 1058 Jorvas 02420 1059 Finland 1061 Email: salvatore.loreto@ericsson.com