idnits 2.17.1 draft-ietf-sipcore-event-rate-control-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 966 has weird spacing: '...n-State max-...' == Line 968 has weird spacing: '...n-State min-...' == Line 970 has weird spacing: '...n-State adap...' == Line 979 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 (July 11, 2011) is 4635 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 981, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 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: January 12, 2012 Ericsson 7 July 11, 2011 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-08 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. This document 18 updates RFC 3265. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Use Case for Limiting the Maximum Rate of Notifications . 5 70 3.2. Use Case for Setting a Minimum Rate for Notifications . . 6 71 3.3. Use Case for Specifying an Adaptive Minimum Rate of 72 Notifications . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 8 76 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 9 77 5. Operation of the Maximum Rate Mechanism . . . . . . . . . . . 9 78 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 9 79 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10 80 5.3. Selecting the Maximum Rate . . . . . . . . . . . . . . . . 10 81 5.4. The Maximum Rate Mechanism for Resource List Server . . . 11 82 5.5. Buffer Policy Description . . . . . . . . . . . . . . . . 13 83 5.5.1. Partial State Notifications . . . . . . . . . . . . . 13 84 5.5.2. Full State Notifications . . . . . . . . . . . . . . . 13 85 5.6. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 86 6. Operation of the Minimum Rate Mechanism . . . . . . . . . . . 14 87 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 88 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 89 6.3. Selecting the Minimum Rate . . . . . . . . . . . . . . . . 15 90 7. Operation of the Adaptive Minimum Rate Mechanism . . . . . . . 16 91 7.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 92 7.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16 93 7.3. Selecting the Adaptive Minimum Rate . . . . . . . . . . . 18 94 7.4. Calculating the Timeout . . . . . . . . . . . . . . . . . 18 95 8. Usage of the Maximum Rate, Minimum Rate and Adaptive 96 Minimum Rate Mechanisms in a combination . . . . . . . . . . . 19 97 9. Protocol Element Definitions . . . . . . . . . . . . . . . . . 20 98 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header 99 Field Parameters . . . . . . . . . . . . . . . . . . . . . 20 100 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 9.3. Event Header Field Usage in Responses to the NOTIFY 102 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 108 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 The SIP events framework [RFC3265] defines a generic framework for 114 subscriptions to and notifications of events related to SIP systems. 115 This framework defines the methods SUBSCRIBE and NOTIFY, and 116 introduces the concept of an event package, which is a concrete 117 application of the SIP events framework to a particular class of 118 events. 120 One of the things the SIP events framework mandates is that each 121 event package specification defines an absolute maximum on the rate 122 at which notifications are allowed to be generated by a single 123 notifier. Such a limit is provided in order to reduce network load. 125 All of the existing event package specifications include a maximum 126 notification rate recommendation, ranging from once in every five 127 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 129 Per the SIP events framework, each event package specification is 130 also allowed to define additional throttle mechanisms which allow the 131 subscriber to further limit the rate of event notification. So far 132 none of the event package specifications have defined such a 133 mechanism. 135 The resource list extension [RFC4662] to the SIP events framework 136 also deals with rate limiting of event notifications. The extension 137 allows a subscriber to subscribe to a heterogeneous list of resources 138 with a single SUBSCRIBE request, rather than having to install a 139 subscription for each resource separately. The event list 140 subscription also allows rate limiting, or throttling of 141 notifications, by means of the Resource List Server (RLS) buffering 142 notifications of resource state changes, and sending them in batches. 143 However, the event list mechanism provides no means for the 144 subscriber to set the interval for the throttling. 146 Some event packages are also interested in specifying an absolute or 147 an adaptive minimum rate at which notifications need to be generated 148 by a notifier. This helps the subscriber to effectively use 149 different trigger criterias within a subscription to eliminate 150 unnecessary notifications but at the same time make sure that the 151 current event state is periodically received. 153 This document defines an extension to the SIP events framework 154 defining the following three Event header field parameters that allow 155 a subscriber to set a maximum, a minimum and an adaptive minimum rate 156 of notifications generated by the notifier: 158 max-rate: specifies a maximum number of notifications per second. 160 min-rate: specifies a minimum number of notifications per second. 162 adaptive-minimum-rate: specifies an adaptive minimum number of 163 notifications per second. 165 These mechanisms are applicable to any event subscription, both 166 single event subscription and event list subscription. A notifier 167 compliant to this specification will adjust the rate at which it 168 generates notifications. 170 2. Definitions and Document Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119] and 175 indicate requirement levels for compliant implementations. 177 Indented passages such as this one are used in this document to 178 provide additional information and clarifying text. They do not 179 contain normative protocol behavior. 181 3. Overview 183 3.1. Use Case for Limiting the Maximum Rate of Notifications 185 A presence client in a mobile device contains a list of 100 buddies 186 or presentities. In order to decrease the processing and network 187 load of watching 100 presentities, the presence client has employed a 188 Resource List Server (RLS) with the list of buddies, and therefore 189 only needs a single subscription to the RLS in order to receive 190 notifications of the presence state of the resource list. 192 In order to control the buffer policy of the RLS, the presence client 193 sets a maximum rate of notifications. The RLS will buffer 194 notifications that are generated faster than they are allowed to be 195 sent due to the maximum rate and batch all of the buffered state 196 changes together in a single notification. The maximum rate applies 197 to the overall resource list, which means that there is a hard cap 198 imposed by the maximum rate to the number of notifications per second 199 the presence client can expect to receive. 201 The presence client can also modify the maximum rate of notifications 202 during the lifetime of the subscription. For example, if the mobile 203 device detects inactivity from the user for a period of time, the 204 presence client can simply pause notifications by choosing a "max- 205 rate" parameter that allows only a single notification for the 206 remainder of the subscription lifetime. When the user becomes active 207 again, the presence client can resume the stream of notifications by 208 re-subscribing with a "max-rate" parameter set to the earlier used 209 value. Application of the mechanism defined by RFC 5839 [RFC5839] 210 can also eliminate the transmission of a (full-state) notification 211 carrying the latest resource state to the presence client after a 212 subscription refresh. 214 3.2. Use Case for Setting a Minimum Rate for Notifications 216 A location application is monitoring the movement of a target. In 217 order to decrease the processing and network load, the location 218 application has made a subscription to a Location Server with a set 219 of location filters [I-D.ietf-geopriv-loc-filters] that specify 220 trigger criteria, e.g. to send an update only when the target has 221 moved at least n meters. However, the application is also interested 222 in receiving the current state periodically even if the state of the 223 target has not changed enough to satisfy any of the trigger criteria, 224 e.g., has not moved at least n meters within the period. 226 The location application sets a minimum rate of notifications and 227 include it in the subscription sent to the Location Server. The "min- 228 rate" parameter indicates the minimum number of notifications per 229 second the notifier needs to generate. 231 The location application can also modify the minimum rate of 232 notifications during the lifetime of the subscription. For example, 233 when the subscription to the movement of a target is made, the 234 notifier may not have the location information available. Thus, the 235 first notification might be empty, or certain values might be absent. 236 An important use case is placing constraints on when complete state 237 should be provided after creating the subscription. Once state is 238 acquired and the second notification is sent, the subscriber updates 239 or changes the "min-rate" parameter to a more sensible value. This 240 update can be performed in the response to the notification that 241 contains the complete state information. 243 3.3. Use Case for Specifying an Adaptive Minimum Rate of Notifications 245 The minimum rate mechanism introduces a static and instantaneous rate 246 control without the functionality to increase or decrease the 247 notification rate adaptively. However, there are some applications 248 that would work better with an adaptive minimum rate control. 250 A location application is monitoring the movement of a target. In 251 order to decrease the processing in the application, the location 252 application wants to make a subscription that dynamically decreases 253 the minimum rate of notifications if the target has sent out several 254 notifications recently. However, if there have have been only few 255 recent notifications by the target, the location application wants 256 the minimum rate of notifications to increase. 258 The location application sets an adaptive minimum rate of 259 notifications and include it in the subscription sent to the Location 260 Server. The "adaptive-min-rate" parameter value is used by the 261 notifier to dynamically calculate the actual maximum time between two 262 notifications. In order to dynamically calculate the maximum time, 263 the notifier takes into consideration the rate at which notifications 264 have been sent recently. In the adaptive minimum rate mechanism the 265 notifier can increase or decrease the notification rate compared to 266 the minimum rate mechanism based on the recent number of 267 notifications sent out in the last period. 269 The location application can also modify the "adaptive-min-rate" 270 parameter during the lifetime of the subscription. 272 3.4. Requirements 274 REQ1: The subscriber must be able to set a maximum rate of 275 notifications in a specific subscription. 277 REQ2: The subscriber must be able to set a minimum rate of 278 notifications in a specific subscription. 280 REQ3: The subscriber must be able to set an adaptive minimum rate 281 of notifications in a specific subscription, which adjusts 282 the minimum rate of notifications based on a moving average. 284 REQ4: It must be possible to apply the maximum rate, the minimum 285 rate and the adaptive minimum rate mechanisms all together, 286 or in any combination, in a specific subscription. 288 REQ5: It must be possible to use any of the different rate control 289 mechanisms in subscriptions to any events. 291 REQ6: It must be possible to use any of the different rate control 292 mechanisms together with any other event filtering 293 mechanisms. 295 REQ7: The notifier must be allowed to use a policy in which the 296 maximum rate, minimum rate and adaptive minimum rate 297 parameters are adjusted from the value given by the 298 subscriber. 300 For example, due to congestion reasons, local policy at 301 the notifier could temporarily dictate a policy that in 302 effect further decreases the maximum rate of 303 notifications. In another example, the notifier can 304 increase the subscriber proposed maximum rate so that at 305 least one notification is generated during the remainder 306 of the subscription lifetime. 308 REQ8: The different rate control mechanisms must address corner 309 cases for setting the notification rates appropriately. At a 310 minimum, the mechanisms must address the situation when the 311 time between two notifications would exceed the subscription 312 duration and should provide procedures for avoiding this 313 situation. 315 REQ9: The different rate control mechanisms must be possible to be 316 invoked, modified, or removed in the course of an active 317 subscription. 319 REQ10: The different rate control mechanisms must allow for the 320 application of authentication and integrity protection 321 mechanisms to subscriptions invoking that mechanism. 323 4. Basic Operations 325 4.1. Subscriber Behavior 327 In general, the way in which a subscriber generates SUBSCRIBE 328 requests and processes NOTIFY requests is according to RFC 3265 329 [RFC3265]. 331 A subscriber that wants to have a maximum, minimum or adaptive 332 minimum rate of event notifications in a specific event subscription 333 does so by including a "max-rate", "min-rate" or "adaptive-min-rate" 334 Event header field parameter(s) as part of the SUBSCRIBE request. 336 A subscriber that wants to update a previously agreed event rate 337 control parameter does so by including the updated "max-rate", "min- 338 rate" or "adaptive-min-rate" Event header field parameter(s) as part 339 of a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY 340 request. If the subscriber did not include at least one of the "max- 341 rate", "min-rate" or "adaptive-min-rate" header field parameters in 342 the most recent SUBSCRIBE request in a given dialog, the subscriber 343 MUST NOT include an Event header field with any of those parameters 344 in a 2xx response to a NOTIFY request in that dialog. 346 4.2. Notifier Behavior 348 In general, the way in which a notifier processes SUBSCRIBE requests 349 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 351 A notifier that supports the different rate control mechanisms MUST 352 adjust its rate of notification according to the rate control values 353 agreed with the subscriber. If the notifier needs to lower the 354 subscription expiration value or if a local policy or other 355 implementation-determined constraint at the notifier can not satisfy 356 the rate control request, then the notifier can adjust (i.e. increase 357 or decrease) appropriately the subscriber requested rate control 358 values. The notifier MUST reflect back the possibly adjusted rate 359 control values in a "max-rate", "min-rate" or "adaptive-min-rate" 360 Subscription-State header field parameter of the subsequent NOTIFY 361 requests. 363 5. Operation of the Maximum Rate Mechanism 365 5.1. Subscriber Behavior 367 A subscriber that wishes to apply a maximum rate to notifications in 368 a subscription MUST construct a SUBSCRIBE request that includes the 369 "max-rate" Event header field parameter. This parameter specifies 370 the requested maximum number of notifications per second. The value 371 of this parameter is a positive real number given by a finite decimal 372 representation. 374 Note that the witnessed time between two consecutive received 375 notifications may not conform to the "max-rate" value for a number 376 of reasons. For example, network jitter and retransmissions may 377 result in the subscriber receiving the notifications more frequent 378 than the "max-rate" value recommends. 380 A subscriber that wishes to update the previously agreed maximum rate 381 of notifications MUST include the updated "max-rate" Event header 382 field parameter in a subsequent SUBSCRIBE request or a 2xx response 383 to the NOTIFY request. 385 A subscriber that wishes to remove the maximum rate control from 386 notifications MUST indicate so by not including a "max-rate" Event 387 header field parameter in a subsequent SUBSCRIBE request or a 2xx 388 response to the NOTIFY request. 390 There are two main consequences for the subscriber when applying the 391 maximum rate mechanism: state transitions may be lost and event 392 notifications may be delayed. If either of these side effects 393 constitute a problem to the application that utilizes the event 394 notifications, developers are instructed not to use the mechanism. 396 5.2. Notifier Behavior 398 A notifier that supports the maximum rate mechanism MUST extract the 399 value of the "max-rate" Event header parameter from a SUBSCRIBE 400 request or a 2xx response to the NOTIFY request and use it as the 401 suggested maximum number of notifications per second. This value can 402 be adjusted by the notifier, as defined in Section 5.3. 404 A compliant notifier MUST reflect back the possibly adjusted maximum 405 rate of notifications in a "max-rate" Subscription-State header field 406 parameter of the subsequent NOTIFY requests. The indicated "max- 407 rate" value is adopted by the notifier, and the notification rate is 408 adjusted accordingly. 410 A notifier that does not understand this extension will not reflect 411 the "max-rate" Subscription-State header field parameter in the 412 NOTIFY requests; the absence of this parameter indicates to the 413 subscriber that no rate control is supported by the notifier. 415 A compliant notifier MUST NOT generate notifications more frequently 416 than the maximum rate allows for, except when generating the 417 notification either upon receipt of a SUBSCRIBE request (the first 418 notification), when the subscription state is changing from "pending" 419 to "active" state or upon termination of the subscription (the last 420 notification). Such notifications reset the timer for the next 421 notification. 423 When a local policy dictates a maximum rate for notifications, a 424 notifier will not generate notifications more frequently than the 425 local policy maximum rate, even if the subscriber is not asking for 426 maximum rate control. The notifier MAY inform the subscriber about 427 such local policy maximum rate using the "max-rate" Subscription- 428 State header field parameter included in subsequent NOTIFY requests. 430 Retransmissions of NOTIFY requests are not affected by the maximum 431 rate mechanism, i.e., the maximum rate mechanism only applies to the 432 generation of new transactions. In other words, the maximum rate 433 mechanism does not in any way break or modify the normal 434 retransmission mechanism specified in RFC 3261 [RFC3261]. 436 5.3. Selecting the Maximum Rate 438 Special care needs to be taken when selecting the maximum rate. For 439 example, the maximum rate could potentially set a minimum time value 440 between notifications that exceeds the subscription expiration value. 442 Such a configuration would effectively quench the notifier, resulting 443 in exactly two notifications to be generated. If the subscriber 444 requests a maximum rate that would result in no notification before 445 the subscription expiration, the notifier MUST increase the maximum 446 rate and set it to the reciprocal value of the subscription 447 expiration time left. According to RFC 3265 [RFC3265] the notifier 448 may also shorten the subscription expiry anytime during an active 449 subscription. If the subscription expiry is shortened during an 450 active subscription, the notifier MUST also increase the "max-rate" 451 value and set it to reciprocal value of the reduced subscription 452 expiration time. 454 In some cases it makes sense to pause the notification stream on an 455 existing subscription dialog on a temporary basis without terminating 456 the subscription, e.g. due to inactivity on the application user 457 interface. Whenever a subscriber discovers the need to perform the 458 notification pause operation, it SHOULD set the maximum rate to the 459 reciprocal value of the remaining subscription expiration value. 460 This results in receiving no further notifications until the 461 subscription expires or the subscriber sends a SUBSCRIBE request 462 resuming notifications. 464 The notifier MAY decide to increase or decrease the proposed "max- 465 rate" value by the subscriber based on its local policy, static 466 configuration or other implementation-determined constraints. In 467 addition, different event packages MAY define additional constraints 468 for the allowed maximum rate ranges. Such constraints are out of the 469 scope of this specification. 471 5.4. The Maximum Rate Mechanism for Resource List Server 473 When applied to a list subscription [RFC4662], the maximum rate 474 mechanism has some additional considerations. Specifically, the 475 maximum rate applies to the aggregate notification stream resulting 476 from the list subscription, rather than explicitly controlling the 477 notification of each of the implied constituent events. Moreover, 478 the RLS can use the maximum rate mechanism on its own to control the 479 rate of the back-end subscriptions to avoid overflowing its buffer. 481 The notifier is responsible for sending out event notifications upon 482 state changes of the subscribed resource. We can model the notifier 483 as consisting of four components: the event state resource(s), the 484 Resource List Server (RLS) (or any other notifier), a notification 485 buffer, and finally the subscriber, or watcher of the event state, as 486 shown in Figure 1. 488 +--------+ 489 | Event | 490 +--------+ |Resource| +--------+ 491 | Event | +--------+ | Event | 492 |Resource| | |Resource| 493 +---.=---+ | +---=----+ 494 `-.. | _.--' 495 ``-._ | _.--' 496 +'--'--'-+ 497 |Resource| 498 | List | 499 | Server | 500 +---.----+ 501 | 502 | 503 )--+---( 504 | | .--------. 505 |Buffer|<======'max-rate| 506 | | `--------' 507 )--.---( 508 | 509 | 510 .---+---. 511 | Event | 512 |Watcher| 513 `-------' 515 Figure 1: Model for the Resource List Server (RLS) Supporting 516 Throttling 518 In short, the RLS reads event state changes from the event state 519 resource, either by creating a back end subscription, or by other 520 means; it packages them into event notifications and submits them 521 into the output buffer. The rate at which this output buffer drains 522 is controlled by the subscriber via the maximum rate mechanism. When 523 a set of notifications are batched together, the way in which 524 overlapping resource state is handled depends on the type of the 525 resource state: 527 In theory, there are many buffer policies that the notifier could 528 implement. However, we only concentrate on two practical buffer 529 policies in this specification, leaving additional ones for 530 further study and out of the scope of this specification. These 531 two buffer policies depend on the mode in which the notifier is 532 operating. 534 Full-state: Last (most recent) full state notification of each 535 resource is sent out, and all others in the buffer are discarded. 536 This policy applies to those event packages that carry full-state 537 notifications. 539 Partial-state: The state deltas of each buffered partial 540 notification per resource are merged, and the resulting 541 notification is sent out. This policy applies to those event 542 packages that carry partial-state notifications. 544 5.5. Buffer Policy Description 546 5.5.1. Partial State Notifications 548 With partial notifications, the notifier needs to maintain a separate 549 buffer for each subscriber since each subscriber may have a different 550 value for the maximum rate of notifications. The notifier will 551 always need to keep both a copy of the current full state of the 552 resource F, as well as the last successfully communicated full state 553 view F' of the resource in a specific subscription. The construction 554 of a partial notification then involves creating a difference of the 555 two states, and generating a notification that contains that 556 difference. 558 When the maximum rate mechanism is applied to the subscription, it is 559 important that F' is replaced with F only when the difference of F 560 and F' was already included in a partial state notification to the 561 subscriber allowed by the maximum rate mechanism. Additionally, the 562 notifier implementation SHOULD check to see that the size of an 563 accumulated partial state notification is smaller than the full 564 state, and if not, the notifier SHOULD send the full state 565 notification instead. 567 5.5.2. Full State Notifications 569 With full state notifications, the notifier only needs to keep the 570 full state of the resource, and when that changes, send the resulting 571 notification over to the subscriber. 573 When the maximum rate mechanism is applied to the subscription, the 574 notifier receives the state changes of the resource, and generates a 575 notification. If there is a pending notification, the notifier 576 simply replaces that notification with the new notification, 577 discarding the older state. 579 5.6. Estimated Bandwidth Savings 581 It is difficult to estimate the total bandwidth savings accrued by 582 using the maximum rate mechanism over a subscription, since such 583 estimates will vary depending on the usage scenarios. However, it is 584 easy to see that given a subscription where several full state 585 notifications would have normally been sent in any given interval set 586 by the "max-rate" parameter, only a single notification is sent 587 during the same interval when using the maximum rate mechanism 588 yielding bandwidth savings of several times the notification size. 590 With partial-state notifications, drawing estimates is further 591 complicated by the fact that the states of consecutive updates may or 592 may not overlap. However, even in the worst case scenario, where 593 each partial update is to a different part of the full state, a rate 594 controlled notification merging all of these n partial states 595 together should at a maximum be the size of a full-state update. In 596 this case, the bandwidth savings are approximately n times the size 597 of the header fields of the NOTIFY request. 599 It is also true that there are several compression schemes available 600 that have been designed to save bandwidth in SIP, e.g., SigComp 601 [RFC3320] and TLS compression [RFC3943]. However, such compression 602 schemes are complementary rather than competing mechanisms to the 603 maximum rate mechanism. After all, they can both be applied 604 simultaneously. 606 6. Operation of the Minimum Rate Mechanism 608 6.1. Subscriber Behavior 610 A subscriber that wishes to apply a minimum rate to notifications in 611 a subscription MUST construct a SUBSCRIBE request that includes the 612 "min-rate" Event header field parameter. This parameter specifies 613 the requested minimum number of notifications per second. The value 614 of this parameter is a positive real number given by a finite decimal 615 representation. 617 A subscriber that wishes to update the previously agreed minimum rate 618 of notifications MUST include the updated "min-rate" Event header 619 field parameter in a subsequent SUBSCRIBE request or a 2xx response 620 to the NOTIFY request. 622 A subscriber that wishes to remove the minimum rate control from 623 notifications MUST indicate so by not including a "min-rate" Event 624 header field parameter in a subsequent SUBSCRIBE request or a 2xx 625 response to the NOTIFY request. 627 The main consequence for the subscriber when applying the minimum 628 rate mechanism is that it can receive a notification even if nothing 629 has changed in the current state of the notifier. However, RFC 5839 630 [RFC5839] defines a mechanism that allows suppressing a NOTIFY 631 request or a NOTIFY request body if the state has not changed. 633 6.2. Notifier Behavior 635 A notifier that supports the minimum rate mechanism MUST extract the 636 value of the "min-rate" Event header field parameter from a SUBSCRIBE 637 request or a 2xx response to the NOTIFY request and use it as the 638 suggested minimum number of notifications per second. This value can 639 be adjusted by the notifier, as defined in Section 6.3. 641 A compliant notifier MUST reflect back the possibly adjusted minimum 642 rate of notifications in a "min-rate" Subscription-State header field 643 parameter of the subsequent NOTIFY requests. The indicated "min- 644 rate" value is adopted by the notifier, and the notification rate is 645 adjusted accordingly. 647 A notifier that does not understand this extension, will not reflect 648 the "min-rate" Subscription-State header field parameter in the 649 NOTIFY requests; the absence of this parameter indicates to the 650 subscriber that no rate control is supported by the notifier. 652 A compliant notifier MUST generate notifications when state changes 653 occur or when the time since the most recent notification exceeds the 654 reciprocal value of the "min-rate" parameter. Depending on the event 655 package and subscriber preferences indicated in the SUBSCRIBE 656 request, the NOTIFY request sent as a result of a minimum rate 657 mechanism MUST contain either the current full state or the partial 658 state showing the difference between the current state and the last 659 successfully communicated state. If the subscriber and the notifier 660 support the procedures in RFC 5839 [RFC5839] the complete NOTIFY 661 request or the NOTIFY request body can be suppressed if the state has 662 not changed from the previous notification. 664 Retransmissions of NOTIFY requests are not affected by the minimum 665 rate mechanism, i.e., the minimum rate mechanism only applies to the 666 generation of new transactions. In other words, the minimum rate 667 mechanism does not in any way break or modify the normal 668 retransmission mechanism. 670 6.3. Selecting the Minimum Rate 672 The minimum rate mechanism can be used to generate a lot of 673 notifications, creating additional processing load for the notifier. 674 Some of the notifications may also be unnecessary possibly repeating 675 already known state information to the subscriber. It is difficult 676 to provide generic guidelines for the acceptable minimum rate value 677 ranges, however the subscriber SHOULD request for the lowest possible 678 minimum rate. Different event packages MAY define additional 679 constraints for the allowed minimum rate values. Such constraints 680 are out of the scope of this specification. 682 The notifier MAY decide to increase or decrease the proposed "min- 683 rate" value by the subscriber based on its local policy, static 684 configuration or other implementation-determined constraints. 686 7. Operation of the Adaptive Minimum Rate Mechanism 688 7.1. Subscriber Behavior 690 A subscriber that wishes to apply an adaptive minimum rate to 691 notifications in a subscription MUST construct a SUBSCRIBE request 692 that includes the "adaptive-min-rate" Event header field parameter. 693 This parameter specifies an adaptive minimum number of notifications 694 per second. The value of this parameter is a positive real number 695 given by a finite decimal representation. 697 A subscriber that wishes to update the previously agreed adaptive 698 minimum rate of notifications MUST include the updated "adaptive-min- 699 rate" Event header field parameter in a subsequent SUBSCRIBE request 700 or a 2xx response to the NOTIFY request. 702 A subscriber that wishes to remove the adaptive minimum rate control 703 from notifications MUST indicate so by not including a "adaptive-min- 704 rate" Event header field parameter in a subsequent SUBSCRIBE request 705 or a 2xx response to the NOTIFY request. 707 The main consequence for the subscriber when applying the adaptive 708 minimum rate mechanism is that it can receive a notification even if 709 nothing has changed in the current state of the notifier. However, 710 RFC 5839 [RFC5839] defines a mechanism that allows suppressing a 711 NOTIFY request or a NOTIFY request body if the state has not changed. 713 7.2. Notifier Behavior 715 A notifier that supports the adaptive minimum rate mechanism MUST 716 extract the value of the "adaptive-min-rate" Event header parameter 717 from a SUBSCRIBE request or a 2xx response to the NOTIFY request and 718 use it to calculate the actual maximum time between two notifications 719 as defined in Section 7.4. 721 The "adaptive-min-rate" value can be adjusted by the notifier, as 722 defined in Section 7.3. 724 A compliant notifier MUST reflect back the possibly adjusted adaptive 725 minimum rate of notifications in an "adaptive-min-rate" Subscription- 726 State header field parameter of the subsequent NOTIFY requests. The 727 indicated "adaptive-min-rate" value is adopted by the notifier, and 728 the notification rate is adjusted accordingly. 730 A notifier that does not understand this extension will not reflect 731 the "adaptive-min-rate" Subscription-State header parameter in the 732 NOTIFY requests; the absence of this parameter indicates to the 733 subscriber that no rate control is supported by the notifier. 735 A compliant notifier MUST generate notifications when state changes 736 occur or when the time since the most recent notification exceeds the 737 value calculated using the formula defined in Section 7.4. Depending 738 on the event package and subscriber preferences indicated in the 739 SUBSCRIBE request, the NOTIFY request sent as a result of a minimum 740 rate mechanism MUST contain either the current full state or the 741 partial state showing the difference between the current state and 742 the last successfully communicated state. If the subscriber and the 743 notifier support the procedures in RFC 5839 [RFC5839] the complete 744 NOTIFY request or the NOTIFY request body can be suppressed if the 745 state has not changed from the previous notification. 747 The adaptive minimum rate mechanism is implemented as follows: 749 1) When a subscription is first created, the notifier creates a 750 record ("count" parameter) that keeps track of the number of 751 notifications that have been sent in the "period". The "count" 752 parameter is initialized to contain a history of having sent a 753 "period * adaptive-min-rate" number of notifications for the 754 "period". 756 2) The "timeout" value is calculated according to the equation given 757 in Section 7.4. 759 3) If the timeout period passes without a NOTIFY request being sent 760 in the subscription, then the current resource state is sent 761 (subject to any filtering associated with the subscription). 763 4) Whenever a NOTIFY request is sent (regardless of whether due to a 764 "timeout" event or a state change), the notifier updates the 765 notification history record stored in the "count" parameter, 766 recalculates the value of "timeout," and returns to step 3. 768 Retransmissions of NOTIFY requests are not affected by the timeout, 769 i.e., the timeout only applies to the generation of new transactions. 771 In other words, the timeout does not in any way break or modify the 772 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 774 7.3. Selecting the Adaptive Minimum Rate 776 The adaptive minimum rate mechanism can be used to generate a lot of 777 notifications, creating additional processing load for the notifier. 778 Some of the notifications may also be unnecessary possibly repeating 779 already known state information to the subscriber. It is difficult 780 to provide generic guidelines for the acceptable adaptive minimum 781 rate value ranges, however the subscriber SHOULD request for the 782 lowest possible adaptive minimum rate value. Different event 783 packages MAY define additional constraints for the allowed adaptive 784 minimum rate values. Such constraints are out of the scope of this 785 specification. 787 The notifier MAY decide to increase or decrease the proposed 788 "adaptive-min-rate" value based on its local policy, static 789 configuration or other implementation-determined constraints. 791 7.4. Calculating the Timeout 793 The formula used to vary the absolute pacing in a way that will meet 794 the adaptive minimum rate requested over the period is given in 795 equation (1): 797 timeout = count / ((adaptive-min-rate ^ 2) * period) (1) 799 The output of the formula, "timeout", is the time to the next 800 notification, expressed in seconds. The formula has three inputs: 802 adaptive-min-rate: The value of the "adaptive-min-rate" parameter 803 conveyed in the Subscription-State header field. 805 period: The rolling average period, in seconds. The granularity of 806 the values for the "period" parameter is set by local policy at 807 the notifier, however the notifier MUST choose a value greater 808 than the reciprocal value of the "adaptive-min-rate" parameter. 809 It is also RECOMMENDED that the notifier chooses a "period" 810 parameter several times larger than reciprocal value of the 811 "adaptive-min-rate" parameter in order to maximize the 812 effectiveness of the equation (1). It is an implementation 813 decision whether the notifier uses the same value of the "period" 814 parameter for all subscriptions or individual values for each 815 subscription. 817 count: The number of notifications that have been sent during the 818 last "period" of seconds not including any retransmissions of 819 requests. 821 In case both the maximum rate and the adaptive minimum rate 822 mechanisms are used in the same subscription the formula used to 823 dynamically calculate the timeout is given in equation (2): 825 timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2) 827 max-rate: The value of the "max-rate" parameter conveyed in the 828 Subscription-State header field. 830 The formula in (2) makes sure that for all the possible values of the 831 "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min- 832 rate" < "max-rate", the timeout never results in a lower value than 833 the reciprocal value of the "max-rate" parameter. 835 In some situation it may be beneficial for the notifier to achieve an 836 adaptive minimum rate in a different way than the algorithm detailed 837 in this document allows. However, the notifier MUST comply with any 838 "max-rate" or "min-rate" parameters that have been negotiated. 840 8. Usage of the Maximum Rate, Minimum Rate and Adaptive Minimum Rate 841 Mechanisms in a combination 843 Applications can subscribe to an event package using all the rate 844 control mechanisms individually, or in combination; in fact there is 845 no technical incompatibility among them. However there are some 846 combinations of the different rate control mechanisms that make 847 little sense to be used together. This section lists all the 848 combinations that are possible to insert in a subscription; the 849 utility to use each combination in a subscription is also analyzed. 851 maximum rate and minimum rate: This combination allows to reduce the 852 notification rate, but at the same time assures the reception of a 853 notification every time the most recent notification exceeds a 854 specified interval. 856 A subscriber SHOULD choose a "min-rate" value lower than the "max- 857 rate" value, otherwise the notifier MUST adjust the subscriber 858 provided "min-rate" value to a value equal to or lower than the 859 "max-rate" value. 861 maximum rate and adaptive minimum rate: It works in a similar way as 862 the combination above, but with the difference that the interval 863 at which notifications are assured changes dynamically. 865 A subscriber SHOULD choose a "adaptive-min-rate" value lower than 866 the "max-rate" value, otherwise the notifier MUST adjust the 867 subscriber provided "adaptive-min-rate" value to a value equal to 868 or lower than the "max-rate" value. 870 minimum rate and adaptive minimum rate: When using the adaptive 871 minimum rate mechanism, frequent state changes in a short period 872 can result in no notifications for a longer period following the 873 short period. The addition of the minimum rate mechanism ensures 874 the subscriber always receives notifications after a specified 875 interval. 877 A subscriber SHOULD choose a "min-rate" value lower than the 878 "adaptive-min-rate" value, otherwise the notifier MUST NOT 879 consider the "min-rate" value. 881 maximum rate, minimum rate and adaptive minimum rate: This 882 combination makes little sense to be used although not forbidden. 884 A subscriber SHOULD choose a "min-rate" and "adaptive-min-rate" 885 values lower than the "max-rate" value, otherwise the notifier 886 MUST adjust the subscriber provided "min-rate" and "adaptive-min- 887 rate" values to a value equal to or lower than the "max-rate" 888 value. 890 A subscriber SHOULD choose a "min-rate" value lower than the 891 "adaptive-min-rate" value, otherwise the notifier MUST NOT 892 consider the "min-rate" value. 894 9. Protocol Element Definitions 896 This section describes the protocol extensions required for the 897 different rate control mechanisms. 899 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header Field 900 Parameters 902 The "max-rate", "min-rate" and "adaptive-min-rate" parameters are 903 added to the rule definitions of the Event header field and the 904 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 905 of this parameter is described in Section 5, Section 6 and Section 7. 907 9.2. Grammar 909 This section describes the Augmented BNF [RFC5234] definitions for 910 the new header field parameters. Note that we derive here from the 911 ruleset present in RFC 3265 [RFC3265], adding additional alternatives 912 to the alternative sets of "event-param" and "subexp-params" defined 913 therein. The "delta-seconds" element is defined in RFC 3261 914 [RFC3261]. 916 event-param = max-rate-param 917 / min-rate-param 918 / amin-rate-param 919 subexp-params = max-rate-param 920 / min-rate-param 921 / amin-rate-param 922 max-rate-param = "max-rate" EQUAL 923 (1*2DIGIT ["." 1*10DIGIT]) 924 min-rate-param = "min-rate" EQUAL 925 (1*2DIGIT ["." 1*10DIGIT]) 926 amin-rate-param = "adaptive-min-rate" EQUAL 927 (1*2DIGIT ["." 1*10DIGIT]) 929 9.3. Event Header Field Usage in Responses to the NOTIFY request 931 This table expands the table described in Section 7.2 of RFC 3265 932 [RFC3265] allowing the Event header field to appear in a 2xx response 933 to a NOTIFY request. The use of the Event header field in responses 934 other than 2xx to NOTIFY requests is undefined and out of scope of 935 this specification. 937 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 938 ----------------------------------------------------------------- 939 Event 2xx - - - - - - - - o 941 A subscriber that wishes to update the previously agreed value for 942 maximum, minimum or adaptive minimum rate of notifications MUST 943 include all desired values for the "max-rate", "min-rate" and 944 "adaptive-min-rate" parameters in an Event header field of the 2xx 945 response to a NOTIFY request. Any of the other header field 946 parameters currently defined for the Event header field by other 947 specifications do not have a meaning if the Event header field is 948 included in the 2xx response to the NOTIFY request. These header 949 field parameters MUST be ignored by the notifier, if present. 951 The event type listed in the Event header field of the 2xx response 952 to the NOTIFY request MUST match the event type of the Event header 953 field in the corresponding NOTIFY request. 955 10. IANA Considerations 957 This specification registers three new SIP header field parameters, 958 defined by the following information which is to be added to the 959 Header Field Parameters and Parameter Values sub-registry under 960 http://www.iana.org/assignments/sip-parameters. 962 Predefined 963 Header Field Parameter Name Values Reference 964 -------------------- --------------- ---------- --------- 965 Event max-rate No [RFCxxxx] 966 Subscription-State max-rate No [RFCxxxx] 967 Event min-rate No [RFCxxxx] 968 Subscription-State min-rate No [RFCxxxx] 969 Event adaptive-min-rate No [RFCxxxx] 970 Subscription-State adaptive-min-rate No [RFCxxxx] 972 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 973 this specification, when assigned.) 975 This specification also updates the reference defining the Event 976 header field in the Header Fields sub-registry under 977 http://www.iana.org/assignments/sip-parameters. 979 Header Name compact Reference 980 ----------- ------- ------------------ 981 Event o [RFC3265][RFCxxxx] 983 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 984 this specification, when assigned.) 986 11. Security Considerations 988 Naturally, the security considerations listed in RFC 3265 [RFC3265], 989 which the rate control mechanisms described in this document extends, 990 apply in entirety. In particular, authentication and message 991 integrity SHOULD be applied to subscriptions with this extension. 993 RFC 3265 [RFC3265] recommends the integrity protection of the Event 994 header field of SUBSCRIBE requests. Implementations of this 995 extension SHOULD also provide integrity protection for the Event 996 header field included in the 2xx response to the NOTIFY request. 997 Without integrity protection an eavesdropper could see and modify the 998 Event header field; or it could also manipulate the transmission of a 999 200 (OK) response to the NOTIFY request in order to suppress or flood 1000 notifications without the subscriber seeing what caused the problem. 1002 When the maximum rate mechanism involves partial state notifications, 1003 the security considerations listed in RFC 5263 [RFC5263] apply in 1004 entirety. 1006 12. Acknowledgments 1008 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 1009 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 1010 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 1011 Michael Procter, Janet Gunn and Ari Keranen for support and/or review 1012 of this work. 1014 Thanks to Brian Rosen for the idea of the minimum and adaptive 1015 minimum rate mechanisms, and Adam Roach for the work on the algorithm 1016 for the adaptive minimum rate mechanism and other feedback. 1018 13. References 1020 13.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1026 A., Peterson, J., Sparks, R., Handley, M., and E. 1027 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1028 June 2002. 1030 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1031 Event Notification", RFC 3265, June 2002. 1033 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1034 Initiation Protocol (SIP) Event Notification Extension for 1035 Resource Lists", RFC 4662, August 2006. 1037 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1038 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1040 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 1041 Khartabil, "Session Initiation Protocol (SIP) Extension 1042 for Partial Notification of Presence Information", 1043 RFC 5263, September 2008. 1045 13.2. Informative References 1047 [I-D.ietf-geopriv-loc-filters] 1048 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1049 Location Notifications in the Session Initiation Protocol 1050 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1051 progress), March 2010. 1053 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1054 Liu, Z., and J. Rosenberg, "Signaling Compression 1055 (SigComp)", RFC 3320, January 2003. 1057 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1058 Package for Registrations", RFC 3680, March 2004. 1060 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1061 Indication Event Package for the Session Initiation 1062 Protocol (SIP)", RFC 3842, August 2004. 1064 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1065 Initiation Protocol (SIP)", RFC 3856, August 2004. 1067 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1068 Package for the Session Initiation Protocol (SIP)", 1069 RFC 3857, August 2004. 1071 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1072 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1073 November 2004. 1075 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1076 Initiation Protocol (SIP) Events for Conditional Event 1077 Notification", RFC 5839, May 2010. 1079 Authors' Addresses 1081 Aki Niemi 1082 Nokia 1083 P.O. Box 407 1084 NOKIA GROUP, FIN 00045 1085 Finland 1087 Phone: +358 50 389 1644 1088 Email: aki.niemi@nokia.com 1089 Krisztian Kiss 1090 Nokia 1091 200 South Mathilda Ave 1092 Sunnyvale, CA 94086 1093 US 1095 Phone: +1 650 391 5969 1096 Email: krisztian.kiss@nokia.com 1098 Salvatore Loreto 1099 Ericsson 1100 Hirsalantie 11 1101 Jorvas 02420 1102 Finland 1104 Email: salvatore.loreto@ericsson.com