idnits 2.17.1 draft-ietf-sipcore-event-rate-control-09.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 962 has weird spacing: '...n-State max-...' == Line 964 has weird spacing: '...n-State min-...' == Line 966 has weird spacing: '...n-State adap...' == Line 975 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 (August 31, 2011) is 4622 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 977, 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: March 3, 2012 Ericsson 7 August 31, 2011 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-09 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 March 3, 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 notification rate may not conform to the 375 "max-rate" value for a number of reasons. For example, network 376 jitter and retransmissions may result in the subscriber receiving 377 the notifications more frequent than the "max-rate" value 378 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 a notification if the interval 416 since the most recent notification is less than the reciprocal value 417 of the "max-rate" parameter, except when generating the notification 418 either upon receipt of a SUBSCRIBE request, when the subscription 419 state is changing from "pending" to "active" state or upon 420 termination of the subscription (the last notification). 422 When a local policy dictates a maximum rate for notifications, a 423 notifier will not generate notifications more frequently than the 424 local policy maximum rate, even if the subscriber is not asking for 425 maximum rate control. The notifier MAY inform the subscriber about 426 such local policy maximum rate using the "max-rate" Subscription- 427 State header field parameter included in subsequent NOTIFY requests. 429 Retransmissions of NOTIFY requests are not affected by the maximum 430 rate mechanism, i.e., the maximum rate mechanism only applies to the 431 generation of new transactions. In other words, the maximum rate 432 mechanism does not in any way break or modify the normal 433 retransmission mechanism specified in RFC 3261 [RFC3261]. 435 5.3. Selecting the Maximum Rate 437 Special care needs to be taken when selecting the maximum rate. For 438 example, the maximum rate could potentially set a minimum time value 439 between notifications that exceeds the subscription expiration value. 440 Such a configuration would effectively quench the notifier, resulting 441 in exactly two notifications to be generated. If the subscriber 442 requests a maximum rate that would result in no notification before 443 the subscription expiration, the notifier MUST increase the maximum 444 rate and set it to the reciprocal value of the subscription 445 expiration time left. According to RFC 3265 [RFC3265] the notifier 446 may also shorten the subscription expiry anytime during an active 447 subscription. If the subscription expiry is shortened during an 448 active subscription, the notifier MUST also increase the "max-rate" 449 value and set it to reciprocal value of the reduced subscription 450 expiration time. 452 In some cases it makes sense to pause the notification stream on an 453 existing subscription dialog on a temporary basis without terminating 454 the subscription, e.g. due to inactivity on the application user 455 interface. Whenever a subscriber discovers the need to perform the 456 notification pause operation, it SHOULD set the maximum rate to the 457 reciprocal value of the remaining subscription expiration value. 458 This results in receiving no further notifications until the 459 subscription expires or the subscriber sends a SUBSCRIBE request 460 resuming notifications. 462 The notifier MAY decide to increase or decrease the proposed "max- 463 rate" value by the subscriber based on its local policy, static 464 configuration or other implementation-determined constraints. In 465 addition, different event packages MAY define additional constraints 466 for the allowed maximum rate ranges. Such constraints are out of the 467 scope of this specification. 469 5.4. The Maximum Rate Mechanism for Resource List Server 471 When applied to a list subscription [RFC4662], the maximum rate 472 mechanism has some additional considerations. Specifically, the 473 maximum rate applies to the aggregate notification stream resulting 474 from the list subscription, rather than explicitly controlling the 475 notification of each of the implied constituent events. Moreover, 476 the RLS can use the maximum rate mechanism on its own to control the 477 rate of the back-end subscriptions to avoid overflowing its buffer. 479 The notifier is responsible for sending out event notifications upon 480 state changes of the subscribed resource. We can model the notifier 481 as consisting of four components: the event state resource(s), the 482 Resource List Server (RLS) (or any other notifier), a notification 483 buffer, and finally the subscriber, or watcher of the event state, as 484 shown in Figure 1. 486 +--------+ 487 | Event | 488 +--------+ |Resource| +--------+ 489 | Event | +--------+ | Event | 490 |Resource| | |Resource| 491 +---.=---+ | +---=----+ 492 `-.. | _.--' 493 ``-._ | _.--' 494 +'--'--'-+ 495 |Resource| 496 | List | 497 | Server | 498 +---.----+ 499 | 500 | 501 )--+---( 502 | | .--------. 503 |Buffer|<======'max-rate| 504 | | `--------' 505 )--.---( 506 | 507 | 508 .---+---. 509 | Event | 510 |Watcher| 511 `-------' 513 Figure 1: Model for the Resource List Server (RLS) Supporting 514 Throttling 516 In short, the RLS reads event state changes from the event state 517 resource, either by creating a back end subscription, or by other 518 means; it packages them into event notifications and submits them 519 into the output buffer. The rate at which this output buffer drains 520 is controlled by the subscriber via the maximum rate mechanism. When 521 a set of notifications are batched together, the way in which 522 overlapping resource state is handled depends on the type of the 523 resource state: 525 In theory, there are many buffer policies that the notifier could 526 implement. However, we only concentrate on two practical buffer 527 policies in this specification, leaving additional ones for 528 further study and out of the scope of this specification. These 529 two buffer policies depend on the mode in which the notifier is 530 operating. 532 Full-state: Last (most recent) full state notification of each 533 resource is sent out, and all others in the buffer are discarded. 534 This policy applies to those event packages that carry full-state 535 notifications. 537 Partial-state: The state deltas of each buffered partial 538 notification per resource are merged, and the resulting 539 notification is sent out. This policy applies to those event 540 packages that carry partial-state notifications. 542 5.5. Buffer Policy Description 544 5.5.1. Partial State Notifications 546 With partial notifications, the notifier needs to maintain a separate 547 buffer for each subscriber since each subscriber may have a different 548 value for the maximum rate of notifications. The notifier will 549 always need to keep both a copy of the current full state of the 550 resource F, as well as the last successfully communicated full state 551 view F' of the resource in a specific subscription. The construction 552 of a partial notification then involves creating a difference of the 553 two states, and generating a notification that contains that 554 difference. 556 When the maximum rate mechanism is applied to the subscription, it is 557 important that F' is replaced with F only when the difference of F 558 and F' was already included in a partial state notification to the 559 subscriber allowed by the maximum rate mechanism. Additionally, the 560 notifier implementation SHOULD check to see that the size of an 561 accumulated partial state notification is smaller than the full 562 state, and if not, the notifier SHOULD send the full state 563 notification instead. 565 5.5.2. Full State Notifications 567 With full state notifications, the notifier only needs to keep the 568 full state of the resource, and when that changes, send the resulting 569 notification over to the subscriber. 571 When the maximum rate mechanism is applied to the subscription, the 572 notifier receives the state changes of the resource, and generates a 573 notification. If there is a pending notification, the notifier 574 simply replaces that notification with the new notification, 575 discarding the older state. 577 5.6. Estimated Bandwidth Savings 579 It is difficult to estimate the total bandwidth savings accrued by 580 using the maximum rate mechanism over a subscription, since such 581 estimates will vary depending on the usage scenarios. However, it is 582 easy to see that given a subscription where several full state 583 notifications would have normally been sent in any given interval set 584 by the "max-rate" parameter, only a single notification is sent 585 during the same interval when using the maximum rate mechanism 586 yielding bandwidth savings of several times the notification size. 588 With partial-state notifications, drawing estimates is further 589 complicated by the fact that the states of consecutive updates may or 590 may not overlap. However, even in the worst case scenario, where 591 each partial update is to a different part of the full state, a rate 592 controlled notification merging all of these n partial states 593 together should at a maximum be the size of a full-state update. In 594 this case, the bandwidth savings are approximately n times the size 595 of the header fields of the NOTIFY request. 597 It is also true that there are several compression schemes available 598 that have been designed to save bandwidth in SIP, e.g., SigComp 599 [RFC3320] and TLS compression [RFC3943]. However, such compression 600 schemes are complementary rather than competing mechanisms to the 601 maximum rate mechanism. After all, they can both be applied 602 simultaneously. 604 6. Operation of the Minimum Rate Mechanism 606 6.1. Subscriber Behavior 608 A subscriber that wishes to apply a minimum rate to notifications in 609 a subscription MUST construct a SUBSCRIBE request that includes the 610 "min-rate" Event header field parameter. This parameter specifies 611 the requested minimum number of notifications per second. The value 612 of this parameter is a positive real number given by a finite decimal 613 representation. 615 A subscriber that wishes to update the previously agreed minimum rate 616 of notifications MUST include the updated "min-rate" Event header 617 field parameter in a subsequent SUBSCRIBE request or a 2xx response 618 to the NOTIFY request. 620 A subscriber that wishes to remove the minimum rate control from 621 notifications MUST indicate so by not including a "min-rate" Event 622 header field parameter in a subsequent SUBSCRIBE request or a 2xx 623 response to the NOTIFY request. 625 The main consequence for the subscriber when applying the minimum 626 rate mechanism is that it can receive a notification even if nothing 627 has changed in the current state of the notifier. However, RFC 5839 628 [RFC5839] defines a mechanism that allows suppressing a NOTIFY 629 request or a NOTIFY request body if the state has not changed. 631 6.2. Notifier Behavior 633 A notifier that supports the minimum rate mechanism MUST extract the 634 value of the "min-rate" Event header field parameter from a SUBSCRIBE 635 request or a 2xx response to the NOTIFY request and use it as the 636 suggested minimum number of notifications per second. This value can 637 be adjusted by the notifier, as defined in Section 6.3. 639 A compliant notifier MUST reflect back the possibly adjusted minimum 640 rate of notifications in a "min-rate" Subscription-State header field 641 parameter of the subsequent NOTIFY requests. The indicated "min- 642 rate" value is adopted by the notifier, and the notification rate is 643 adjusted accordingly. 645 A notifier that does not understand this extension, will not reflect 646 the "min-rate" Subscription-State header field parameter in the 647 NOTIFY requests; the absence of this parameter indicates to the 648 subscriber that no rate control is supported by the notifier. 650 A compliant notifier MUST generate notifications when state changes 651 occur or when the time since the most recent notification exceeds the 652 reciprocal value of the "min-rate" parameter. Depending on the event 653 package and subscriber preferences indicated in the SUBSCRIBE 654 request, the NOTIFY request sent as a result of a minimum rate 655 mechanism MUST contain either the current full state or the partial 656 state showing the difference between the current state and the last 657 successfully communicated state. If the subscriber and the notifier 658 support the procedures in RFC 5839 [RFC5839] the complete NOTIFY 659 request or the NOTIFY request body can be suppressed if the state has 660 not changed from the previous notification. 662 Retransmissions of NOTIFY requests are not affected by the minimum 663 rate mechanism, i.e., the minimum rate mechanism only applies to the 664 generation of new transactions. In other words, the minimum rate 665 mechanism does not in any way break or modify the normal 666 retransmission mechanism. 668 6.3. Selecting the Minimum Rate 670 The minimum rate mechanism can be used to generate a lot of 671 notifications, creating additional processing load for the notifier. 672 Some of the notifications may also be unnecessary possibly repeating 673 already known state information to the subscriber. It is difficult 674 to provide generic guidelines for the acceptable minimum rate value 675 ranges, however the subscriber SHOULD request for the lowest possible 676 minimum rate. Different event packages MAY define additional 677 constraints for the allowed minimum rate values. Such constraints 678 are out of the scope of this specification. 680 The notifier MAY decide to increase or decrease the proposed "min- 681 rate" value by the subscriber based on its local policy, static 682 configuration or other implementation-determined constraints. 684 7. Operation of the Adaptive Minimum Rate Mechanism 686 7.1. Subscriber Behavior 688 A subscriber that wishes to apply an adaptive minimum rate to 689 notifications in a subscription MUST construct a SUBSCRIBE request 690 that includes the "adaptive-min-rate" Event header field parameter. 691 This parameter specifies an adaptive minimum number of notifications 692 per second. The value of this parameter is a positive real number 693 given by a finite decimal representation. 695 A subscriber that wishes to update the previously agreed adaptive 696 minimum rate of notifications MUST include the updated "adaptive-min- 697 rate" Event header field parameter in a subsequent SUBSCRIBE request 698 or a 2xx response to the NOTIFY request. 700 A subscriber that wishes to remove the adaptive minimum rate control 701 from notifications MUST indicate so by not including a "adaptive-min- 702 rate" Event header field parameter in a subsequent SUBSCRIBE request 703 or a 2xx response to the NOTIFY request. 705 The main consequence for the subscriber when applying the adaptive 706 minimum rate mechanism is that it can receive a notification even if 707 nothing has changed in the current state of the notifier. However, 708 RFC 5839 [RFC5839] defines a mechanism that allows suppressing a 709 NOTIFY request or a NOTIFY request body if the state has not changed. 711 7.2. Notifier Behavior 713 A notifier that supports the adaptive minimum rate mechanism MUST 714 extract the value of the "adaptive-min-rate" Event header parameter 715 from a SUBSCRIBE request or a 2xx response to the NOTIFY request and 716 use it to calculate the actual maximum time between two notifications 717 as defined in Section 7.4. 719 The "adaptive-min-rate" value can be adjusted by the notifier, as 720 defined in Section 7.3. 722 A compliant notifier MUST reflect back the possibly adjusted adaptive 723 minimum rate of notifications in an "adaptive-min-rate" Subscription- 724 State header field parameter of the subsequent NOTIFY requests. The 725 indicated "adaptive-min-rate" value is adopted by the notifier, and 726 the notification rate is adjusted accordingly. 728 A notifier that does not understand this extension will not reflect 729 the "adaptive-min-rate" Subscription-State header parameter in the 730 NOTIFY requests; the absence of this parameter indicates to the 731 subscriber that no rate control is supported by the notifier. 733 A compliant notifier MUST generate notifications when state changes 734 occur or when the time since the most recent notification exceeds the 735 value calculated using the formula defined in Section 7.4. Depending 736 on the event package and subscriber preferences indicated in the 737 SUBSCRIBE request, the NOTIFY request sent as a result of a minimum 738 rate mechanism MUST contain either the current full state or the 739 partial state showing the difference between the current state and 740 the last successfully communicated state. If the subscriber and the 741 notifier support the procedures in RFC 5839 [RFC5839] the complete 742 NOTIFY request or the NOTIFY request body can be suppressed if the 743 state has not changed from the previous notification. 745 The adaptive minimum rate mechanism is implemented as follows: 747 1) When a subscription is first created, the notifier creates a 748 record ("count" parameter) that keeps track of the number of 749 notifications that have been sent in the "period". The "count" 750 parameter is initialized to contain a history of having sent a 751 "period * adaptive-min-rate" number of notifications for the 752 "period". 754 2) The "timeout" value is calculated according to the equation given 755 in Section 7.4. 757 3) If the timeout period passes without a NOTIFY request being sent 758 in the subscription, then the current resource state is sent 759 (subject to any filtering associated with the subscription). 761 4) Whenever a NOTIFY request is sent (regardless of whether due to a 762 "timeout" event or a state change), the notifier updates the 763 notification history record stored in the "count" parameter, 764 recalculates the value of "timeout," and returns to step 3. 766 Retransmissions of NOTIFY requests are not affected by the timeout, 767 i.e., the timeout only applies to the generation of new transactions. 769 In other words, the timeout does not in any way break or modify the 770 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 772 7.3. Selecting the Adaptive Minimum Rate 774 The adaptive minimum rate mechanism can be used to generate a lot of 775 notifications, creating additional processing load for the notifier. 776 Some of the notifications may also be unnecessary possibly repeating 777 already known state information to the subscriber. It is difficult 778 to provide generic guidelines for the acceptable adaptive minimum 779 rate value ranges, however the subscriber SHOULD request for the 780 lowest possible adaptive minimum rate value. Different event 781 packages MAY define additional constraints for the allowed adaptive 782 minimum rate values. Such constraints are out of the scope of this 783 specification. 785 The notifier MAY decide to increase or decrease the proposed 786 "adaptive-min-rate" value based on its local policy, static 787 configuration or other implementation-determined constraints. 789 7.4. Calculating the Timeout 791 The formula used to vary the absolute pacing in a way that will meet 792 the adaptive minimum rate requested over the period is given in 793 equation (1): 795 timeout = count / ((adaptive-min-rate ^ 2) * period) (1) 797 The output of the formula, "timeout", is the time to the next 798 notification, expressed in seconds. The formula has three inputs: 800 adaptive-min-rate: The value of the "adaptive-min-rate" parameter 801 conveyed in the Subscription-State header field. 803 period: The rolling average period, in seconds. The granularity of 804 the values for the "period" parameter is set by local policy at 805 the notifier, however the notifier MUST choose a value greater 806 than the reciprocal value of the "adaptive-min-rate" parameter. 807 It is also RECOMMENDED that the notifier chooses a "period" 808 parameter several times larger than reciprocal value of the 809 "adaptive-min-rate" parameter in order to maximize the 810 effectiveness of the equation (1). It is an implementation 811 decision whether the notifier uses the same value of the "period" 812 parameter for all subscriptions or individual values for each 813 subscription. 815 count: The number of notifications that have been sent during the 816 last "period" of seconds not including any retransmissions of 817 requests. 819 In case both the maximum rate and the adaptive minimum rate 820 mechanisms are used in the same subscription the formula used to 821 dynamically calculate the timeout is given in equation (2): 823 timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2) 825 max-rate: The value of the "max-rate" parameter conveyed in the 826 Subscription-State header field. 828 The formula in (2) makes sure that for all the possible values of the 829 "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min- 830 rate" < "max-rate", the timeout never results in a lower value than 831 the reciprocal value of the "max-rate" parameter. 833 In some situation it may be beneficial for the notifier to achieve an 834 adaptive minimum rate in a different way than the algorithm detailed 835 in this document allows. However, the notifier MUST comply with any 836 "max-rate" or "min-rate" parameters that have been negotiated. 838 8. Usage of the Maximum Rate, Minimum Rate and Adaptive Minimum Rate 839 Mechanisms in a combination 841 Applications can subscribe to an event package using all the rate 842 control mechanisms individually, or in combination; in fact there is 843 no technical incompatibility among them. However there are some 844 combinations of the different rate control mechanisms that make 845 little sense to be used together. This section lists all the 846 combinations that are possible to insert in a subscription; the 847 utility to use each combination in a subscription is also analyzed. 849 maximum rate and minimum rate: This combination allows to reduce the 850 notification rate, but at the same time assures the reception of 851 periodic notifications. 853 A subscriber SHOULD choose a "min-rate" value lower than the "max- 854 rate" value, otherwise the notifier MUST adjust the subscriber 855 provided "min-rate" value to a value equal to or lower than the 856 "max-rate" value. 858 maximum rate and adaptive minimum rate: It works in a similar way as 859 the combination above, but with the difference that the interval 860 at which notifications are assured changes dynamically. 862 A subscriber SHOULD choose a "adaptive-min-rate" value lower than 863 the "max-rate" value, otherwise the notifier MUST adjust the 864 subscriber provided "adaptive-min-rate" value to a value equal to 865 or lower than the "max-rate" value. 867 minimum rate and adaptive minimum rate: When using the adaptive 868 minimum rate mechanism, frequent state changes in a short period 869 can result in no notifications for a longer period following the 870 short period. The addition of the minimum rate mechanism ensures 871 the subscriber always receives notifications after a specified 872 interval. 874 A subscriber SHOULD choose a "min-rate" value lower than the 875 "adaptive-min-rate" value, otherwise the notifier MUST NOT 876 consider the "min-rate" value. 878 maximum rate, minimum rate and adaptive minimum rate: This 879 combination makes little sense to be used although not forbidden. 881 A subscriber SHOULD choose a "min-rate" and "adaptive-min-rate" 882 values lower than the "max-rate" value, otherwise the notifier 883 MUST adjust the subscriber provided "min-rate" and "adaptive-min- 884 rate" values to a value equal to or lower than the "max-rate" 885 value. 887 A subscriber SHOULD choose a "min-rate" value lower than the 888 "adaptive-min-rate" value, otherwise the notifier MUST NOT 889 consider the "min-rate" value. 891 9. Protocol Element Definitions 893 This section describes the protocol extensions required for the 894 different rate control mechanisms. 896 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header Field 897 Parameters 899 The "max-rate", "min-rate" and "adaptive-min-rate" parameters are 900 added to the rule definitions of the Event header field and the 901 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 902 of this parameter is described in Section 5, Section 6 and Section 7. 904 9.2. Grammar 906 This section describes the Augmented BNF [RFC5234] definitions for 907 the new header field parameters. Note that we derive here from the 908 ruleset present in RFC 3265 [RFC3265], adding additional alternatives 909 to the alternative sets of "event-param" and "subexp-params" defined 910 therein. 912 event-param = max-rate-param 913 / min-rate-param 914 / amin-rate-param 915 subexp-params = max-rate-param 916 / min-rate-param 917 / amin-rate-param 918 max-rate-param = "max-rate" EQUAL 919 (1*2DIGIT ["." 1*10DIGIT]) 920 min-rate-param = "min-rate" EQUAL 921 (1*2DIGIT ["." 1*10DIGIT]) 922 amin-rate-param = "adaptive-min-rate" EQUAL 923 (1*2DIGIT ["." 1*10DIGIT]) 925 9.3. Event Header Field Usage in Responses to the NOTIFY request 927 This table expands the table described in Section 7.2 of RFC 3265 928 [RFC3265] allowing the Event header field to appear in a 2xx response 929 to a NOTIFY request. The use of the Event header field in responses 930 other than 2xx to NOTIFY requests is undefined and out of scope of 931 this specification. 933 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 934 ----------------------------------------------------------------- 935 Event 2xx - - - - - - - - o 937 A subscriber that wishes to update the previously agreed value for 938 maximum, minimum or adaptive minimum rate of notifications MUST 939 include all desired values for the "max-rate", "min-rate" and 940 "adaptive-min-rate" parameters in an Event header field of the 2xx 941 response to a NOTIFY request. Any of the other header field 942 parameters currently defined for the Event header field by other 943 specifications do not have a meaning if the Event header field is 944 included in the 2xx response to the NOTIFY request. These header 945 field parameters MUST be ignored by the notifier, if present. 947 The event type listed in the Event header field of the 2xx response 948 to the NOTIFY request MUST match the event type of the Event header 949 field in the corresponding NOTIFY request. 951 10. IANA Considerations 953 This specification registers three new SIP header field parameters, 954 defined by the following information which is to be added to the 955 Header Field Parameters and Parameter Values sub-registry under 956 http://www.iana.org/assignments/sip-parameters. 958 Predefined 959 Header Field Parameter Name Values Reference 960 -------------------- --------------- ---------- --------- 961 Event max-rate No [RFCxxxx] 962 Subscription-State max-rate No [RFCxxxx] 963 Event min-rate No [RFCxxxx] 964 Subscription-State min-rate No [RFCxxxx] 965 Event adaptive-min-rate No [RFCxxxx] 966 Subscription-State adaptive-min-rate No [RFCxxxx] 968 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 969 this specification, when assigned.) 971 This specification also updates the reference defining the Event 972 header field in the Header Fields sub-registry under 973 http://www.iana.org/assignments/sip-parameters. 975 Header Name compact Reference 976 ----------- ------- ------------------ 977 Event o [RFC3265][RFCxxxx] 979 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 980 this specification, when assigned.) 982 11. Security Considerations 984 Naturally, the security considerations listed in RFC 3265 [RFC3265], 985 which the rate control mechanisms described in this document extends, 986 apply in entirety. In particular, authentication and message 987 integrity SHOULD be applied to subscriptions with this extension. 989 RFC 3265 [RFC3265] recommends the integrity protection of the Event 990 header field of SUBSCRIBE requests. Implementations of this 991 extension SHOULD also provide integrity protection for the Event 992 header field included in the 2xx response to the NOTIFY request. 993 Without integrity protection an eavesdropper could see and modify the 994 Event header field; or it could also manipulate the transmission of a 995 200 (OK) response to the NOTIFY request in order to suppress or flood 996 notifications without the subscriber seeing what caused the problem. 998 When the maximum rate mechanism involves partial state notifications, 999 the security considerations listed in RFC 5263 [RFC5263] apply in 1000 entirety. 1002 12. Acknowledgments 1004 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 1005 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 1006 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 1007 Michael Procter, Janet Gunn and Ari Keranen for support and/or review 1008 of this work. 1010 Thanks to Brian Rosen for the idea of the minimum and adaptive 1011 minimum rate mechanisms, and Adam Roach for the work on the algorithm 1012 for the adaptive minimum rate mechanism and other feedback. 1014 13. References 1016 13.1. Normative References 1018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Levels", BCP 14, RFC 2119, March 1997. 1021 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1022 A., Peterson, J., Sparks, R., Handley, M., and E. 1023 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1024 June 2002. 1026 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1027 Event Notification", RFC 3265, June 2002. 1029 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1030 Initiation Protocol (SIP) Event Notification Extension for 1031 Resource Lists", RFC 4662, August 2006. 1033 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1034 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1036 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 1037 Khartabil, "Session Initiation Protocol (SIP) Extension 1038 for Partial Notification of Presence Information", 1039 RFC 5263, September 2008. 1041 13.2. Informative References 1043 [I-D.ietf-geopriv-loc-filters] 1044 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1045 Location Notifications in the Session Initiation Protocol 1046 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1047 progress), March 2010. 1049 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1050 Liu, Z., and J. Rosenberg, "Signaling Compression 1051 (SigComp)", RFC 3320, January 2003. 1053 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1054 Package for Registrations", RFC 3680, March 2004. 1056 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1057 Indication Event Package for the Session Initiation 1058 Protocol (SIP)", RFC 3842, August 2004. 1060 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1061 Initiation Protocol (SIP)", RFC 3856, August 2004. 1063 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1064 Package for the Session Initiation Protocol (SIP)", 1065 RFC 3857, August 2004. 1067 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1068 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1069 November 2004. 1071 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1072 Initiation Protocol (SIP) Events for Conditional Event 1073 Notification", RFC 5839, May 2010. 1075 Authors' Addresses 1077 Aki Niemi 1078 Nokia 1079 P.O. Box 407 1080 NOKIA GROUP, FIN 00045 1081 Finland 1083 Phone: +358 50 389 1644 1084 Email: aki.niemi@nokia.com 1085 Krisztian Kiss 1086 Nokia 1087 200 South Mathilda Ave 1088 Sunnyvale, CA 94086 1089 US 1091 Phone: +1 650 391 5969 1092 Email: krisztian.kiss@nokia.com 1094 Salvatore Loreto 1095 Ericsson 1096 Hirsalantie 11 1097 Jorvas 02420 1098 Finland 1100 Email: salvatore.loreto@ericsson.com