idnits 2.17.1 draft-ietf-soc-load-control-event-package-06.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 -- The document date (January 1, 2013) is 4133 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) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-15) exists of draft-ietf-soc-overload-control-11 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF SOC Working Group C. Shen 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: July 5, 2013 A. Koike 6 NTT 7 January 1, 2013 9 A Session Initiation Protocol (SIP) Load Control Event Package 10 draft-ietf-soc-load-control-event-package-06.txt 12 Abstract 14 We define a load control event package for the Session Initiation 15 Protocol (SIP). It allows SIP entities to distribute load filtering 16 policies to other SIP entities in the network. The load filtering 17 policies contain rules to throttle calls based on their source or 18 destination domain, telephone number prefix or for a specific user. 19 The mechanism helps to prevent signaling overload and complements 20 feedback-based SIP overload control efforts. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 5, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 60 5. SIP Load Filtering Overview . . . . . . . . . . . . . . . . . 7 61 5.1. Load Filtering Policy Format . . . . . . . . . . . . . . . 7 62 5.2. Load Filtering Policy Computation . . . . . . . . . . . . 7 63 5.3. Load Filtering Policy Distribution . . . . . . . . . . . . 8 64 5.4. Applicability in Different Network Environments . . . . . 11 65 6. Load Control Event Package . . . . . . . . . . . . . . . . . . 12 66 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 12 67 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 12 68 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 12 69 6.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . . 12 70 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12 71 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 13 72 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 13 73 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 74 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 14 75 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 15 76 6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Load Control Document . . . . . . . . . . . . . . . . . . . . 15 78 7.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 16 80 7.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 16 81 7.3.1. Call Identity . . . . . . . . . . . . . . . . . . . . 16 82 7.3.2. Method . . . . . . . . . . . . . . . . . . . . . . . . 19 83 7.3.3. Target SIP Entity . . . . . . . . . . . . . . . . . . 20 84 7.3.4. Validity . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 7.5. Complete Examples . . . . . . . . . . . . . . . . . . . . 22 87 7.5.1. Load Control Document Examples . . . . . . . . . . . . 22 88 7.5.2. Message Flow Examples . . . . . . . . . . . . . . . . 24 89 8. XML Schema Definition for Load Control . . . . . . . . . . . . 25 90 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 9.1. Relationship with Load Filtering in PSTN . . . . . . . . . 28 92 9.2. Relationship with Other IETF SIP Overload Control 93 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 10. Discussion of this specification meeting the requirements 95 of RFC5390 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 98 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 99 12.1. Load Control Event Package Registration . . . . . . . . . 35 100 12.2. application/load-control+xml MIME Registration . . . . . . 36 101 12.3. Load Control Schema Registration . . . . . . . . . . . . . 37 102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 104 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 105 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 108 1. Introduction 110 Proper functioning of Session Initiation Protocol (SIP) [RFC3261] 111 signaling servers is critical in SIP-based communications networks. 112 The performance of SIP servers can be severely degraded when the 113 server is overloaded with excessive number of signaling requests. 114 Both legitimate and malicious traffic can overload SIP servers, 115 despite appropriate capacity planning. 117 There are three common examples of legitimate short-term increases in 118 call volumes. Viewer-voting TV shows or ticket giveaways may 119 generate millions of calls within a few minutes. Call volume may 120 also spike during special holidays such as New Year's Day and 121 Mother's Day. Finally, callers may want to reach friends and family 122 in natural disaster areas such as those affected by hurricanes. When 123 possible, only calls traversing overloaded servers should be 124 throttled under those conditions. 126 SIP load control mechanisms are needed to prevent congestion collapse 127 in these cases [RFC5390]. There are two types of load control 128 approaches. In the first approach, feedback control, SIP servers 129 provide load limits to upstream servers, to reduce the incoming rate 130 of all SIP requests [I-D.ietf-soc-overload-control]. These upstream 131 servers then drop or delay incoming SIP requests. Feedback control 132 is reactive and affects signaling messages that have already been 133 issued by user agent clients. They work well when SIP proxy servers 134 in the core networks (core proxy servers) or destination-specific SIP 135 proxy servers in the edge networks (edge proxy servers) are 136 overloaded. By their nature, they need to distribute rate, drop or 137 window information to all upstream SIP proxy servers and normally 138 affect all calls equally, regardless of destination. However, 139 feedback control is usually ineffective for overload of more general 140 purpose SIP edge proxy servers. For example, in the ticket giveaway 141 case, almost all calls to the hotline will fail at the core proxy 142 servers; if the edge proxy servers leading to the core proxy servers 143 are also overloaded, calls to other destinations will also be 144 rejected or dropped. 146 Here, we propose an additional, complementary load control mechanism, 147 called load filtering. Network operators create load filtering 148 policies that indicate calls to specific destinations or from 149 specific sources should be rate-limited or randomly dropped. These 150 load filtering policies are then distributed to SIP servers and 151 possibly SIP user agents that are likely to generate calls to the 152 affected destinations or from the affected sources. Load filtering 153 works best if it prevents calls as close to the originating user 154 agent clients as possible. 156 The load filtering approach is most applicable for situations where a 157 traffic surge and its source/destination distribution can be 158 predicted in advance. For instance, it is appropriate for a mass- 159 phone-voting event, Mother's Day, New Year's Day, and even a 160 hurricane. However, it is less likely to be effective for the 161 initial phase of unpredicted/unpredictable mass calling events, such 162 as earthquakes or terrorist attacks. In these latter cases, the 163 local traffic load may peak by more than an order of magnitude in 164 minutes, if not seconds. This does not allow time to either 165 effectively identify the load filtering policies needed, nor 166 distribute them to the appropriate servers soon enough to prevent 167 server congestion. Once other, more immediate, techniques (such as 168 the loss-based or rate-based load feedback control methods) have 169 prevented the initial congestion collapse, the load filtering 170 approach can be used to effectively control the continuing overload. 172 Performing SIP load filtering involves the following components of 173 load filtering policies: format definition, computation, distribution 174 and enforcement. This specification defines the load filtering 175 policy, distribution and enforcement in the SIP load control event 176 package built upon existing SIP event notification framework. 177 However, load filtering policy computation is out of scope of this 178 specification, because it depends heavily on the actual network 179 topology and other service provider policies. 181 It should be noted that although the SIP load filtering mechanism is 182 motivated by the SIP overload control problem, which is why this 183 specification refers extensively to parallel SIP overload control 184 related efforts, the applicability of SIP load filtering extends 185 beyond the overload control purpose. For example, it can also be 186 used to implement quality of service or other service level agreement 187 commitments. Therefore, we use the term "load control event 188 package", instead of a narrower term "overload control event 189 package". 191 The rest of this specification is structured as follows: we begin by 192 listing the design requirements for this work in Section 4. We then 193 give an overview of load filtering operation in Section 5. The load 194 control event package for load filtering policy distribution is 195 detailed in Section 6. The load filtering policy format is defined 196 in the two sections that follow, with Section 7 introducing the XML 197 document for load filtering policies and Section 8 listing the 198 associated schema. Section 9 relates this work to corresponding 199 mechanisms in PSTN and other IETF efforts addressing SIP overload 200 control. Section 10 evaluates whether this specification meets the 201 SIP overload control requirements set forth by RFC5390 [RFC5390]. 202 Finally, Section 11 presents security considerations and Section 12 203 provides IANA considerations. 205 2. Conventions 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119]. 211 3. Definitions 213 This specification reuses the definitions for "Event Package", 214 "Notification", "Notifier", "Subscriber", "Subscription" as in 215 [RFC6665]. The following additional definitions are also used. 217 Load Filtering: A load control mechanism which applies specific 218 actions to selected loads (e.g., SIP requests) matching specific 219 conditions. 220 Load Filtering Policy: A set of zero or more load filtering rules, 221 also known as load filtering rule set. 222 Load Filtering Rule: Conditions and actions to be applied for load 223 filtering. 224 Load Filtering Condition: Elements that describe how to select loads 225 to apply load filtering actions. This specification defines the 226 "call identity", "method", "target SIP identity", and "validity" 227 condition elements (Section 7.3). 228 Load Filtering Action: An operation to be taken by a load filtering 229 server on loads that match the load filtering conditions. This 230 specification allows actions such as accept, reject and redirect 231 of loads (Section 7.4). 232 Load Filtering Server: A server which performs load filtering. In 233 the context of this specification, the load filtering server is 234 the subscriber, which receives load filtering policies from the 235 notifier and enforces those policies during load filtering. 236 Load Control Document: An XML document that describes the load 237 filtering policies (Section 7). It inherits and enhances the 238 common policy document defined in [RFC4745]. 240 4. Design Requirements 242 The SIP load filtering mechanism needs to satisfy the following 243 requirements: 245 o To simplify the solution, we focus on a method for controlling SIP 246 load, rather than a generic application-layer mechanism. 247 o The load filtering policy needs to be distributed efficiently to 248 possibly a large subset of all SIP elements. 249 o The solution should re-use existing SIP protocol mechanisms to 250 reduce implementation and deployment complexity. 252 o For predictable overload situations, such as holidays and mass 253 calling events, the load filtering policy should specify during 254 what time it is to be applied, so that the information can be 255 distributed ahead of time. 256 o For destination-specific overload situations, the load filtering 257 policy should be able to describe the destination domain or the 258 callee. 259 o To address accidental and intentional high-volume call generators, 260 the load filtering policy should be able to specify the caller. 261 o Caller and callee need to be specified as both SIP URIs and 'Tel' 262 URIs [RFC3966] in load filtering policies. 263 o It should be possible to specify particular information in the SIP 264 headers (e.g., prefixes in telephone numbers) which allow load 265 filtering over limited regionally-focused overloads. 266 o The solution should draw upon experiences from related PSTN 267 mechanisms where applicable. 268 o The solution should be extensible to meet future needs. 270 5. SIP Load Filtering Overview 272 5.1. Load Filtering Policy Format 274 Load filtering policies are specified by sets of rules. Each rule 275 contains both load filtering conditions and actions. The load 276 filtering conditions define identities of the targets to be 277 filtered(Section 7.3.1). For example, there are two typical resource 278 limits in a possible overload situation, i.e., human destination 279 limits (N number of call takers) and node capacity limits. The load 280 filtering targets in these two cases can be the specific callee 281 numbers or the destination domain corresponding to the overload. 282 Load filtering conditions also indicate the specific message type to 283 be matched (Section 7.3.2), with which target SIP entity the 284 filtering policy is associated (Section 7.3.3) and the period of time 285 when the filtering policy should be activated and deactivated 286 (Section 7.3.4). Load filtering actions describe the desired control 287 functions such as limiting the request rate below a certain level 288 (Section 7.4). 290 5.2. Load Filtering Policy Computation 292 Computing the load filtering policies needs to take into 293 consideration information such as overload time, scope and network 294 topology, as well as service policies. It is also important to make 295 sure that there is no resource allocation loop, and that server 296 capacity is allocated in a way which both prevents overload and 297 maximizes effective throughput (aka goodput). In some cases, in 298 order to better utilize system resources, it may be preferable to 299 employ an algorithm which dynamically computes the load filtering 300 policies based on currently observed server load status, rather than 301 using a purely static filtering policy assignment. The computation 302 algorithm for load filtering policies is out of scope of this 303 specification. 305 5.3. Load Filtering Policy Distribution 307 For load filtering policy distribution, this specification defines 308 the SIP event package for load control, which is an "instantiation" 309 of the generic SIP event notification framework [RFC6665]. The SIP 310 event notification framework provides an existing method for SIP 311 entities to subscribe to and receive notifications when certain 312 events occur. Such a framework forms a scalable event distribution 313 architecture that suits our needs. This specification also defines 314 XML schema of a load control document (Section 7), which is used to 315 encode load filtering policies. 317 In order for load filtering policies to be properly distributed, each 318 capable SIP entity in the network SHOULD subscribe to the SIP load 319 control event package from all its outgoing signaling neighbors, 320 known as notifiers (Section 6.6). Subscription is initiated and 321 maintained during normal server operation. Signaling neighbors are 322 discovered by sending signaling messages. For instance, if A sends 323 signaling requests to B, B is an outgoing signaling neighbor of A. A 324 needs to subscribe to the load control event package of B in case B 325 wants to curb requests from A. On the other hand, if B also sends 326 signaling requests to A, then B also needs to subscribe to A. The 327 subscription of neighboring SIP entities needs to be persistent so 328 that it is in place independently of any specific events requiring 329 load filtering. Key to this is the fact that following initial 330 subscription, the notifier sends a notification without a body if no 331 load filtering policy is defined (Section 6.7), and that the 332 subscription needs to be refreshed periodically to make it 333 persistent, as described in Section 4.1 and Section 4.2 of [RFC6665]. 334 The notifier will send a notification to its subscribers each time a 335 new subscription or a subscription refresh is accepted (Section 6.7). 336 The notification request includes in its body the current load 337 filtering policies (Section 7.1) from the notifier. If no such load 338 filtering policy exists, the notification request is sent without a 339 body. The subscribers MAY terminate the subscription if it no longer 340 considers the notifiers as its signaling neighbor, e.g., after an 341 extended period of absence of signaling message exchange. However, 342 if after un-subscribing, the subscriber determines that signaling 343 with the notifier becomes active again, it MUST immediately subscribe 344 to that notifier again. 346 We use the example architecture shown in Figure 1 to illustrate load 347 filtering policy distribution based on the SIP load control event 348 package mechanism. This scenario consists of two networks belonging 349 to Service Provider A and Service Provider B, respectively. Each 350 provider's network is made up of two SIP core proxy servers and four 351 SIP edge proxy servers. The core proxy servers and edge proxy 352 servers of Service Provider A are denoted as CPa1 to CPa2 and EPa1 to 353 EPa4; the core proxy servers and edge proxy servers of Service 354 Provider B are denoted as CPb1 to CPb2 and EPb1 to EPb4. 356 +-----------+ +-----------+ +-----------+ +-----------+ 357 | | | | | | | | 358 | EPa1 | | EPa2 | | EPa3 | | EPa4 | 359 | | | | | | | | 360 +-----------+ +-----------+ +-----------+ +-----------+ 361 \ / \ / 362 \ / \ / 363 \ / \ / 364 +-----------+ +-----------+ 365 | | | | 366 | CPa1 |------------------| CPa2 | 367 | | | | 368 +-----------+ +-----------+ 369 | | 370 Service | | 371 Provider A | | 372 | | 373 ================================================================= 374 | | 375 Service | | 376 Provider B | | 377 | | 378 +-----------+ +-----------+ 379 | | | | 380 | CPb1 |------------------| CPb2 | 381 | | | | 382 +-----------+ +-----------+ 383 / \ / \ 384 / \ / \ 385 / \ / \ 386 +-----------+ +-----------+ +-----------+ +-----------+ 387 | | | | | | | | 388 | EPb1 | | EPb2 | | EPb3 | | EPb4 | 389 | | | | | | | | 390 +-----------+ +-----------+ +-----------+ +-----------+ 391 Figure 1: Example Network Scenario Using SIP Load Control Event 392 Package Mechanism 394 At initialization stage, the proxy servers first identify all their 395 outgoing signaling neighbors and subscribe to them. The neighbor 396 identification process can be performed by service providers through 397 direct provisioning, or by the proxy servers themselves via 398 progressive learning from the signaling messages sent and received. 399 Assuming all signaling relationships in Figure 1 are bi-directional, 400 after this initialization stage, each proxy server will be subscribed 401 to all its neighbors. That is, EPa1 subscribes to CPa1; CPa1 402 subscribes to EPa1, EPa2, CPa2 and CPb1, so on and so forth. The 403 following cases then show two examples of how load filtering policy 404 distribution in this network works. 406 Case I: EPa1 serves a TV program hotline and decides to limit the 407 total number of incoming calls to the hotline to prevent an overload. 408 To do so, EPa1 sends a notification to CPa1 with the specific hotline 409 number, time of activation and total acceptable call rate. Depending 410 on the load filtering policy computation algorithm, CPa1 may allocate 411 the received total acceptable call rate among its neighbors, namely, 412 EPa2, CPa2, and CPb1, and notify them about the resulting allocation 413 along with the hotline number and the activation time. CPa2 and CPb1 414 may perform further allocation among their own neighbors and notify 415 the corresponding proxy servers. This process continues until all 416 edge proxy servers in the network have been informed about the event 417 and have proper load filtering policy configured. 419 In the above case, the network entity where load filtering policy is 420 first introduced is the SIP server providing access to the resource 421 that creates the overload situation. In other cases, the network 422 entry point of introducing load filtering policy could also be an 423 entity that hosts this resource. For example, an operator may host 424 an application server that performs 800 number translation services. 425 The application server may itself be a SIP proxy server or a SIP 426 Back-to-Back User Agent (B2BUA). If one of the 800 numbers hosted at 427 the application server creates the overload condition, the load 428 filtering policies can be introduced from the application server and 429 then propagated to other SIP proxy servers in the network. 431 Case II: a hurricane affects the region covered by CPb2, EPb3 and 432 EPb4. All these three SIP proxy servers are overloaded. The rescue 433 team determines that outbound calls are more valuable than inbound 434 calls in this specific situation. Therefore, EPb3 and EPb4 are 435 configured with load filtering policies to accept more outbound calls 436 than inbound calls. CPb2 may be configured the same way or receive 437 dynamically computed load filtering policies from EPb3 and EPb4. 438 Depending on the load filtering policy computation algorithm, CPb2 439 may also send out notifications to its outside neighbors, namely CPb1 440 and CPa2, specifying a limit on the acceptable rate of inbound calls 441 to CPb2's responsible domain. CPb1 and CPa2 may subsequently notify 442 their neighbors about limiting the calls to CPb2's area. The same 443 process could continue until all edge proxy servers are notified and 444 have load filtering policies configured. 446 Note that this specification does not define the provisioning 447 interface between the party who determines the load filtering policy 448 and the network entry point where the policy is introduced. One of 449 the options for the provisioning interface is the Extensible Markup 450 Language (XML) Configuration Access Protocol (XCAP) [RFC4825]. 452 5.4. Applicability in Different Network Environments 454 SIP load filtering is more effective when the filtering policies can 455 be pushed to the proximity of signaling sources. But even if only 456 part of the signaling path towards the signaling source could be 457 covered, use of this mechanism can still be beneficial. In fact, due 458 to possibly sophisticated call routing and security concerns, trying 459 to apply automated load filtering policy distribution in the entire 460 inter-domain network path could get extremely complicated and be 461 unrealistic. 463 The scenarios where this mechanism could be most useful are 464 environments consisting of servers with secure and trust relationship 465 and with relatively straightforward routing configuration known to 466 the load filtering policy computation algorithm. These scenarios may 467 include intra-domain environments such as those inside a service 468 provider or enterprise domain; inter-domain environments such as 469 enterprise connecting to a few service providers or between service 470 providers with manageable routing configurations. 472 Another important aspect that affects the applicability of SIP load 473 filtering is that all neighbors that are possible signaling sources 474 need to participate and enforce the designated load filtering 475 policies. Otherwise, a single non-conforming neighbor could make the 476 whole filtering efforts useless by pumping in excessive traffic to 477 overload the server. Therefore, the SIP server that distributes load 478 filtering policies needs to take counter-measures towards any non- 479 conforming neighbors. A simple method is to reject excessive 480 requests with 503 (Service Unavailable) response messages as if they 481 were obeying the rate. Considering the rejection costs, a more 482 complicated but fairer method would be to allocate at the overloaded 483 server the same amount of processing to the combination of both 484 normal processing and rejection as the overloaded server would devote 485 to processing requests for a conforming upstream SIP server. These 486 approaches work as long as the total rejection cost does not 487 overwhelm the entire server resources. In addition, SIP servers need 488 to handle message prioritization properly while performing load 489 filtering, which is described in Section 6.8. 491 6. Load Control Event Package 493 The SIP load filtering mechanism defines a load control event package 494 for SIP based on [RFC6665]. 496 6.1. Event Package Name 498 The name of this event package is "load-control". This name is 499 carried in the Event and Allow-Events header, as specified in 500 [RFC6665]. 502 6.2. Event Package Parameters 504 No package specific event header field parameters are defined for 505 this event package. 507 6.3. SUBSCRIBE Bodies 509 The effectiveness of SIP load filtering relies on the scope of 510 distribution and installation of the filtering policies in the 511 network. Since wide distribution of load filtering policies is 512 desirable, subscribers SHOULD try to subscribe to all those notifiers 513 with which they have regular signaling exchanges, although not all 514 such notifiers may permit such subscription. 516 A SUBSCRIBE request sent without a body implies the default 517 subscription behavior as specified in Section 6.7. 519 6.4. SUBSCRIBE Duration 521 The default expiration time for a subscription to load filtering 522 policy is one hour. Since the desired expiration time may vary 523 significantly for subscriptions among SIP entities with different 524 signaling relationships, the subscribers and notifiers are 525 RECOMMENDED to explicitly negotiate appropriate subscription duration 526 when knowledge about the mutual signaling relationship is available. 528 6.5. NOTIFY Bodies 530 The body of a NOTIFY request in this event package contains load 531 filtering policies. The format of the NOTIFY request body MUST be in 532 one of the formats defined in the Accept header field of the 533 SUBSCRIBE request or be the default format, as specified in 535 [RFC6665]. The default data format for the NOTIFY request body of 536 this event package is "application/load-control+xml" (defined in 537 Section 7). This means that when NOTIFY request body exists but no 538 Accept header field is specified in a SUBSCRIBE request, the NOTIFY 539 request body will contain "application/load-control+xml" format. If 540 NOTIFY request body exists and the Accept header field is present in 541 a SUBSCRIBE request, the NOTIFY request body MUST include 542 "application/load-control+xml" format and MAY include any other 543 formats. 545 6.6. Notifier Processing of SUBSCRIBE Requests 547 The notifier accepts a new subscription or updates an existing 548 subscription upon receiving a valid SUBSCRIBE request. 550 If the identity of the subscriber sending the SUBSCRIBE request is 551 not allowed to receive load filtering policy, the notifier MUST 552 return a 403 "Forbidden" response. 554 If none of MIME types specified in the Accept header of the SUBSCRIBE 555 request is supported, the notifier SHOULD return 406 "Not Acceptable" 556 response. 558 6.7. Notifier Generation of NOTIFY Requests 560 A notifier MUST send a NOTIFY request with its current load filtering 561 policy to the subscriber upon successfully accepting or refreshing a 562 subscription. If no load filtering policy needs to be distributed 563 when the subscription is received, the notifier SHOULD sent a NOTIFY 564 request without body to the subscriber. The content-type header 565 field of this NOTIFY request MUST indicate the correct body format as 566 if the body were present (e.g., "application/load-control+xml"). 567 Sending this NOTIFY request without body is often the case when a 568 subscription is initiated for the first time, e.g., when a SIP entity 569 is just introduced, because there may be no planned events that 570 require load filtering at that time. A notifier SHOULD generate 571 NOTIFY requests each time the load filtering policy changes, with the 572 maximum notification rate not exceeding values defined in 573 Section 6.10. 575 6.8. Subscriber Processing of NOTIFY Requests 577 The subscriber is the load filtering server which enforces load 578 filtering policies received from the notifier. The way subscribers 579 process NOTIFY requests depends on the load filtering policies 580 conveyed in the notifications. Typically, load filtering policies 581 consist of rules specifying actions to be applied to requests 582 matching certain conditions. A subscriber receiving a notification 583 first installs these rules and then enforce corresponding actions on 584 requests matching those conditions, for example, limiting the sending 585 rate of call requests destined for a specific callee. 587 In the case when load filtering policies specify a future validity, 588 it is possible that when the validity time comes, the subscription to 589 the specific notifier that conveyed the rules has expired. In this 590 case, it is RECOMMENDED that the subscriber re-activate its 591 subscription with the corresponding notifier. Regardless of whether 592 this re-activation of subscription is successful or not, when the 593 validity time is reached, the subscriber SHOULD enforce the 594 corresponding rules. 596 Upon receipt of a NOTIFY request with a Subscription-State header 597 field containing the value "terminated", the subscription status with 598 the particular notifier will be terminated. Meanwhile, subscribers 599 MUST also terminate previously received load filtering policies from 600 that notifier. 602 The subscriber SHOULD discard unknown bodies. If the NOTIFY request 603 contains several bodies, none of them being supported, it SHOULD 604 unsubscribe. A NOTIFY request without a body indicates that no load 605 filtering policies need to be updated. 607 When enforcing load filtering policies, a subscriber needs to handle 608 message prioritization according to the following principles. 610 o It SHOULD honor any local policy for prioritizing SIP requests 611 such as policies based on message type, e.g., INVITEs vs. requests 612 associated with existing sessions. 613 o It SHOULD honor any local policy for prioritizing SIP requests 614 based on the content of the Resource-Priority header (RPH, 615 [RFC4412]). Specific (namespace.value) RPH contents may indicate 616 high priority requests that should be preserved as much as 617 possible during overload. The RPH contents can also indicate a 618 low-priority request that is eligible to be dropped during times 619 of overload. 620 o It SHOULD honor any local policy for prioritizing SIP requests 621 relating to emergency calls, as identified by the SOS URN 622 [RFC5031] indicating an emergency request. 624 6.9. Handling of Forked Requests 626 Forking is not applicable when this load control event package 627 mechanism is used within a single-hop distance between neighboring 628 SIP entities. If communication scope of the load control event 629 package mechanism is among multiple hops, forking is not expected to 630 happen either because the subscription request is addressed to a 631 clearly defined SIP entity. However, in the unlikely case when 632 forking does happen, the load control event package only allows the 633 first potential dialog-establishing message to create a dialog, as 634 specified in Section 5.9 of [RFC6665]. 636 6.10. Rate of Notifications 638 Rate of notifications is likely not a concern for this local control 639 event package mechanism when it is used in a non-real-time mode for 640 relatively static load filtering policies. Nevertheless, if 641 situation does arise that a rather frequent load filtering policy 642 update is needed, it is RECOMMENDED that the notifier do not generate 643 notifications at a rate higher than once per-second in all cases, in 644 order to avoid the NOTIFY request itself overloading the system. 646 6.11. State Delta 648 It is likely that updates to specific load filtering policies are 649 made by changing only part of the policy parameters only (e.g. 650 acceptable request rate or percentage, but not matching identities). 651 This will typically be because the utilization of a resource subject 652 to overload depends upon dynamic unknowns such as holding time and 653 the relative distribution of offered loads over subscribing SIP 654 entities. The updates could originate manually or be determined 655 automatically by an algorithm that dynamically computes the load 656 filtering policies (Section 5.2). Another factor that is usually not 657 known precisely or needs to be computed automatically is the duration 658 of the event requiring load filtering. Therefore it would also be 659 common for the validity to change frequently. 661 This event package allows the use of state delta as in [RFC6665] to 662 accommodate frequent updates of partial policy parameters. For each 663 NOTIFY transaction in a subscription, a version number that increases 664 by exactly one MUST be included in the NOTIFY request body when the 665 body is present. When the subscriber receives a state delta, it 666 associates the partial updates to the particular policy by matching 667 the appropriate rule id (Section 7.5). If the subscriber receives a 668 NOTIFY request with a version number that is increased by more than 669 one, it knows that it has missed a state delta and needs to ask for a 670 full state snapshot. Therefore, the subscriber ignores that NOTIFY 671 request containing the state delta, and re-sends a SUBSCRIBE request 672 to force a NOTIFY request containing a complete state snapshot. 674 7. Load Control Document 676 7.1. Format 677 A load control document is an XML document that describes the load 678 filtering policies. It inherits and enhances the common policy 679 document defined in [RFC4745]. A common policy document contains a 680 set of rules. Each rule consists of three parts: conditions, actions 681 and transformations. The conditions part is a set of expressions 682 containing attributes such as identity, domain, and validity time 683 information. Each expression evaluates to TRUE or FALSE. Conditions 684 are matched on "equality" or "greater than" style comparison. There 685 is no regular expression matching. Conditions are evaluated on 686 receipt of an initial SIP request for a dialog or standalone 687 transaction. If a request matches all conditions in a rule set, the 688 action part and the transformation part are consulted to determine 689 the "permission" on how to handle the request. Each action or 690 transformation specifies a positive grant to the policy server to 691 perform the resulting actions. Well-defined mechanism are available 692 for combining actions and transformations obtained from more than one 693 sources. 695 7.2. Namespace 697 The namespace URI for elements defined by this specification is a 698 Uniform Resource Namespace (URN) ([RFC2141]), using the namespace 699 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 700 The URN is as follows: 702 urn:ietf:params:xml:ns:load-control 704 7.3. Conditions 706 [RFC4745] defines three condition elements: , and 707 . In this specification, we re-define an element for 708 identity, define a new element for method and reuse the 709 element. The element is not used. 711 7.3.1. Call Identity 713 Since the problem space of this specification is different from that 714 of [RFC4745], the [RFC4745] element is not sufficient for 715 use with load filtering. First, load filtering may be applied to 716 different identities contained in a request, including identities of 717 both the receiving entity and the sending entity. Second, the 718 importance of authentication varies when different identities of a 719 request are concerned. This specification defines new identity 720 conditions that can accommodate the granularity of specific SIP 721 identity header fields. The requirement for authentication depends 722 on which field is to be matched. 724 The identity condition for load filtering is specified by the element and its sub-element . The element 726 itself contains sub-elements representing SIP sending and receiving 727 identity header fields: , , and , each is of the same type as the element in 729 [RFC4745]. Therefore, they also inherit the sub-elements of the 730 element, including , , and . 732 The [RFC4745] and elements may contain an "id" 733 attribute, which is the URI of a single entity to be included or 734 excluded in the condition. When used in the , , and elements, this "id" value is the URI 736 contained in the corresponding SIP header field, i.e., From, To, 737 Request-URI, and P-Asserted-Identity. 739 When the element contains multiple sub- 740 elements, the result is combined using logical OR. When the , 741 , and elements contain 742 multiple or sub-elements, the result is also combined 743 using logical OR. When the sub-element further contains one 744 or more sub-elements, the result of each sub- 745 element is combined using a logical OR, similar to that of the 746 element in [RFC4745]. However, when the element 747 contains multiple of the , , and sub-elements, the result is combined using logical AND. 749 This allows the call identity to be specified by multiple fields of a 750 SIP request simultaneously, e.g., both the From and the To header 751 fields. 753 The following shows an example of the element, which 754 matches call requests whose To header field contains the SIP URI 755 "sip:alice@hotline.example.com", or the 'tel' URI 756 "tel:+1-212-555-1234". 758 759 760 761 762 763 764 765 767 Before evaluating call-identity conditions, the subscriber shall 768 convert URIs received in SIP header fields in canonical form as per 769 [RFC3261], except that the phone-context parameter shall not be 770 removed, if present. 772 The [RFC4745] and elements may take a "domain" 773 attribute. The "domain" attribute specifies a domain name to be 774 matched by the domain part of the candidate identity. Thus, it 775 allows matching a large and possibly unknown number of entities 776 within a domain. The "domain" attribute works well for SIP URIs. 778 A URI identifying a SIP user, however, can also be a 'tel' URI. We 779 therefore need a similar way to match a group of 'tel' URIs. 780 According to [RFC3966], there are two forms of 'tel' URIs for global 781 numbers and local numbers, respectively. All phone numbers must be 782 expressed in global form when possible. The global number 'tel' URIs 783 start with a "+". The rest of the numbers are expressed as local 784 numbers, which must be qualified by a "phone-context" parameter. The 785 "phone-context" parameter may be labelled as a global number or any 786 number of its leading digits, or a domain name. Both forms of the 787 'tel' URI make the resulting URI globally unique. 789 'Tel' URIs of global numbers can be grouped by prefixes consisting of 790 any number of common leading digits. For example, a prefix formed by 791 a country code or both the country and area code identifies telephone 792 numbers within a country or an area. Since the length of the country 793 and area code for different regions are different, the length of the 794 number prefix also varies. This allows further flexibility such as 795 grouping the numbers into sub-areas within the same area code. 'Tel' 796 URIs of local numbers can be grouped by the value of the "phone- 797 context" parameter. 799 To include the two forms of 'tel' URI grouping in the and 800 elements, one approach is to add a new attribute similar to 801 the "domain" attribute. In this specification, we decide on a 802 simpler approach. There are basically two types of grouping 803 attribute values for both SIP URIs and 'tel' URIs: domain name and 804 number prefix starting with "+". Both of them can be expressed as 805 strings. Therefore, we re-interpret the existing "domain" attribute 806 of the and elements to allow it to contain both types 807 of grouping attribute values. In particular, when the "domain" 808 attribute value starts with "+", it denotes a number prefix, 809 otherwise, the value denotes a domain name. Note that the tradeoff 810 of this simpler approach is the overlap in matching different types 811 of URIs. Specifically, a domain name in the "domain" attribute could 812 be matched by both a SIP URI with that domain name and a local number 813 'tel' URI containing the same domain name in the "phone-context". On 814 the other hand, a number prefix in the "domain" attribute could be 815 matched by both global number 'tel' URIs starting with those leading 816 digits, and local number 'tel' URIs having the same prefix in the 817 "phone-context" parameter. However, when the "phone-context" 818 coincides with the SIP domain name or the global number prefix, in 819 many cases the related phone numbers indeed belong to the same domain 820 or the same area, which means the overlap is not inappropriate. It 821 should be noted that the method of grouping local numbers as defined 822 in this specification does not support all cases. For example, if 823 the phone-context for short service numbers in a country is the 824 country code, this solution does not permit the definition of a load 825 filtering policy that excludes all E.164 numbers in that country but 826 retains all short service numbers. A complete solution for local 827 number grouping requires a separate method outside the scope of this 828 document. 830 The following example shows the use of the re-interpreted "domain" 831 attribute. It matches those requests calling to the number "+1-202- 832 999-1234" but are not calling from a "+1-212" prefix or a SIP From 833 URI domain of "manhattan.example.com". 835 836 837 838 839 840 841 842 843 844 845 846 847 849 7.3.2. Method 851 The load created on a SIP server depends on the type of initial SIP 852 requests for dialogs or standalone transactions. The 853 element specifies the SIP method to which the load filtering action 854 applies. When this element is not included, the load filtering 855 actions are applicable to all applicable initial requests. These 856 requests include INVITE, MESSAGE, REGISTER, SUBSCRIBE, OPTIONS, and 857 PUBLISH. Non-initial requests, such as ACK, BYE and CANCEL are not 858 subjected to load filtering. In addition, SUBSCRIBE requests are not 859 filtered if the event-type header field indicates the event package 860 defined in this specification. 862 The following example shows the use of the element in the 863 case the filtering actions should be applied to INVITE requests. 865 INVITE 867 7.3.3. Target SIP Entity 868 A SIP server that performs load filtering may have multiple paths to 869 route call requests matching the same set of call identity elements. 870 In those situations, the SIP load filtering server may desire to take 871 advantage of alternative paths and only apply load filtering actions 872 to matching requests for the next hop SIP entity that originated the 873 corresponding load filtering policy. To achieve that, the SIP load 874 filtering server needs to associate every load filtering policy with 875 its originating SIP entity. The element is 876 defined for that purpose and it contains the URI of the entity that 877 initiated the load filtering policy, which is generally the 878 corresponding notifier. A notifier MAY include this element as part 879 of the condition of its filtering policy being sent to the 880 subscriber, as below. 882 sip:biloxi.example.com 884 When a SIP load filtering server receives a policy with a element, it SHOULD record it and take it into 886 consideration when making load filtering decisions. If the load 887 filtering server receives a load filtering policy that does not 888 contain a element, it MAY still record the URI of 889 the load filtering policy's originator as the 890 information and consider it when making load filtering decisions. 892 The following are two examples of using the 893 element. Usecase I: the network has user A connected to SIP Proxy 894 1 (SP1), user B connected to SIP Proxy 3 (SP3), SP1 and SP3 895 connected via SIP Proxy 2 (SP2), and SP2 connected to an 896 Application Server (AS). Under normal load conditions, a call 897 from A to B is routed along the following path: 898 A-SP1-SP2-AS-SP3-B. The AS provides a non-essential service and 899 can be bypassed in case of overload. Now let's assume that AS is 900 overloaded and sends to SP2 a load filtering policy requesting 901 that 50% of all INVITE requests be dropped. SP2 can maintain AS 902 as the for that policy so that it knows the 903 50% drop action is only applicable to call requests that must go 904 through AS, without affecting those calls directly routed through 905 SP3 to B. Usecase II: An 800 translation service is installed on 906 two Application Servers, AS1 and AS2. User A is connected to SP1 907 and calls 800-1234-4529, which is translated by AS1 and AS2 into a 908 regular E.164 number depending on, e.g., the caller's location. 909 SP1 forwards INVITE requests with Request-URI = "800 number" to 910 AS1 or AS2 based on a load balancing strategy. As calls to 800- 911 1234-4529 creates a pre-overload condition in AS1, AS1 sends to 912 SP1 a load filtering policy requesting that 50% of calls towards 913 800-1234-4529 be rejected. In this case, SP1 can maintain AS1 as 914 the for the rule, and only apply the load 915 filtering policy on incoming requests that are intended to be sent 916 to AS1. Those requests that are sent to AS2, although matching 917 the of the filter, will not be affected. 919 7.3.4. Validity 921 A filtering policy is usually associated with a validity period 922 condition. This specification reuses the element of 923 [RFC4745], which specifies a period of validity time by pairs of 924 and sub-elements. When multiple time periods are 925 defined, the validity condition is evaluated to TRUE if the current 926 time falls into any of the specified time periods. i.e., it 927 represents a logical OR operation across all validity time periods. 929 The following example shows a element specifying a valid 930 period from 12:00 to 15:00 US Eastern Standard Time on 2008-05-31. 932 933 2008-05-31T12:00:00-05:00 934 2008-05-31T15:00:00-05:00 935 937 7.4. Actions 939 The actions a load filtering server takes on loads matching the load 940 filtering conditions are defined by the element in the load 941 filtering policy, which includes any one of the three sub-elements 942 , , and . The element denotes an absolute 943 value of the maximum acceptable request rate in requests per second; 944 the element specifies the relative percentage of incoming 945 requests that should be accepted; the element describes the 946 acceptable window size supplied by the receiver, which is applicable 947 in window-based load filtering. In static load filtering policy 948 configuration scenarios, using the sub-element is RECOMMENDED 949 because it is hard to enforce the percentage rate or window-based 950 load filtering when incoming load from upstream or reactions from 951 downstream are uncertain. (See [I-D.ietf-soc-overload-control] 952 [RFC6357] for more details on rate-based, loss-based and window-based 953 load control.) 955 In addition, the element takes an optional "alt-action" 956 attribute which can be used to explicitly specify the desired action 957 in case a request cannot be processed. The default "alt-action" 958 value is "reject" where the load filtering server will reject the 959 request with a 503 (Service Unavailable) response message. Other 960 possible "alt-action" values include "drop" for simple drop, and 961 "redirect" for redirecting the request to another target. It should 962 be noted that when running SIP over an unreliable transport such as 963 UDP, using the "drop" action will create message retransmissions that 964 further worsen the possible overload situation. Therefore, any 965 "drop" action applied to an unreliable transport MUST be treated as 966 if it were "reject". When the "alt-action" value is "redirect", an 967 "alt-target" attribute MUST be defined. The "alt-target" specifies 968 one URI or a list of URIs where the request should be redirected. 969 The server sends out the redirect URIs in a 300-class response 970 message. 972 In the following element example, the server accepts 973 maximum of 100 call requests per second. The remaining calls are 974 redirected to an answering machine. 976 977 979 100 980 981 983 7.5. Complete Examples 985 7.5.1. Load Control Document Examples 987 This section presents two complete examples of load control documents 988 valid with respect to the XML schema defined in Section 8. 990 The first example assumes that a set of hotlines are set up at 991 "sip:alice@hotline.example.com" and "tel:+1-212-555-1234". The 992 hotlines are activated from 12:00 to 15:00 US Eastern Standard Time 993 on 2008-05-31. The goal is to limit the incoming calls to the 994 hotlines to 100 requests per second. Calls that exceed the rate 995 limit are explicitly rejected. 997 998 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 INVITE 1013 1014 2008-05-31T12:00:00-05:00 1015 2008-05-31T15:00:00-05:00 1016 1017 1018 1019 1020 100 1021 1022 1024 1025 1027 The second example considers optimizing server resource usage of a 1028 three-day period during the aftermath of a hurricane. Incoming calls 1029 to the hurricane domain "newyork.example.com" will be limited to a 1030 rate of 100 requests per second, except for those calls originating 1031 from a particular rescue team domain "rescue.example.com". Outgoing 1032 calls from the hurricane domain or calls within the local domain are 1033 never limited. All calls that are throttled due to the rate limit 1034 will be forwarded to an answering machine with updated hurricane 1035 rescue information. 1037 1038 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 INVITE 1058 1059 2012-10-25T09:00:00+01:00 1060 2012-10-28T09:00:00+01:00 1061 1062 1063 1064 1066 100 1067 1068 1070 1071 1073 7.5.2. Message Flow Examples 1075 This section presents an example message flow of using the load 1076 control event package mechanism defined in this specification. 1078 atlanta biloxi 1079 | F1 SUBSCRIBE | 1080 |------------------>| 1081 | F2 200 OK | 1082 |<------------------| 1083 | F3 NOTIFY | 1084 |<------------------| 1085 | F4 200 OK | 1086 |------------------>| 1088 F1 SUBSCRIBE atlanta.example.com -> biloxi.example.com 1090 SUBSCRIBE sip:biloxi.example.com SIP/2.0 1091 Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy7cjbu3 1092 From: sip:atlanta.example.com;tag=162ab5 1093 To: sip:biloxi.example.com 1094 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1095 CSeq: 2012 SUBSCRIBE 1096 Contact: sip:atlanta.example.com 1097 Event: load-control 1098 Max-Forwards: 70 1099 Accept: application/load-control+xml 1100 Expires: 3600 1101 Content-Length: 0 1103 F2 200 OK biloxi.example.com -> atlanta.example.com 1104 SIP/2.0 200 OK 1105 Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy7cjbu3 1106 ;received=192.0.2.1 1107 To: ;tag=331dc8 1108 From: ;tag=162ab5 1109 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1110 CSeq: 2012 SUBSCRIBE 1111 Expires: 3600 1112 Contact: sip:biloxi.example.com 1113 Content-Length: 0 1115 F3 NOTIFY biloxi.example.com -> atlanta.example.com 1117 NOTIFY sip:atlanta.example.com SIP/2.0 1118 Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy71g2ks 1119 From: ;tag=331dc8 1120 To: ;tag=162ab5 1121 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1122 Event: load-control 1123 Subscription-State: active;expires=3599 1124 Max-Forwards: 70 1125 CSeq: 1775 NOTIFY 1126 Contact: sip:biloxi.example.com 1127 Content-Type: application/load-control+xml 1128 Content-Length: ... 1130 [Load Control Document] 1132 F4 200 OK atlanta.example.com -> biloxi.example.com 1134 SIP/2.0 200 OK 1135 Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy71g2ks 1136 ;received=192.0.2.2 1137 From: ;tag=331dc8 1138 To: ;tag=162ab5 1139 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1140 CSeq: 1775 NOTIFY 1141 Content-Length: 0 1143 8. XML Schema Definition for Load Control 1145 This section defines the XML schema for the load control document. 1146 It extends the Common Policy schema in [RFC4745] in two ways. 1147 Firstly, it defines two mandatory attributes for the 1148 element: version and state. The version attribute allows the 1149 recipient of the notification to properly order them. Versions start 1150 at 0, and increase by one for each new document sent to a subscriber 1151 within the same subscription. Versions MUST be representable using a 1152 non-negative 32 bit integer. The state attribute indicates whether 1153 the document contains a full load filtering policy update, or whether 1154 it contains only state delta as partial update. Secondly, it defines 1155 new members of the and elements. 1157 1158 1165 1167 1169 1170 1171 1172 1173 1174 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1191 1193 1194 1195 1196 1197 1198 1199 1201 1202 1203 1205 1206 1207 1208 1209 1210 1211 1213 1215 1216 1217 1219 1220 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1234 1235 1237 1238 1239 1240 1241 1242 1243 1245 1246 1247 1249 1250 1252 1253 1254 1255 1257 1259 9. Related Work 1261 9.1. Relationship with Load Filtering in PSTN 1263 It is known that existing PSTN network also uses a load filtering 1264 mechanism to prevent overload and the filtering policy configuration 1265 is done manually except in specific cases when the Intelligent 1266 Network architecture is used [Q.1248.2][E.412]. This specification 1267 defines a load filtering mechanism based on the SIP event 1268 notification framework that allows automated filtering policy 1269 distribution in suitable environments. 1271 There are control messages associated with PSTN overload control 1272 which would specify an outgoing control list, call gap duration and 1273 control duration [Q.1248.2][E.412]. These items could be roughly 1274 correlated to the identity, action and time fields of the SIP load 1275 filtering policy defined in this specification. However, the load 1276 filtering policy defined in this specification is much more generic 1277 and flexible as opposed to its PSTN counterpart. 1279 Firstly, PSTN load filtering only applies to telephone numbers. The 1280 identity element of SIP load filtering policy allows both SIP URI and 1281 telephone numbers (through Tel URI) to be specified. These 1282 identities can be arbitrarily grouped by SIP domains or any number of 1283 leading prefix of the telephone numbers. 1285 Secondly, the PSTN load filtering action is usually limited to call 1286 gapping. The action field in SIP load filtering policy allows more 1287 flexible possibilities such as rate throttle and others. 1289 Thirdly, the duration field in PSTN load filtering specifies a value 1290 in seconds for the load filtering duration only, and the allowed 1291 values are mapped into a value set. The time field in SIP load 1292 filtering policy may specify not only a duration, but also a future 1293 activation time which could be especially useful for automating load 1294 filtering for predictable overloads. 1296 PSTN load filtering can be performed in both edge switches and 1297 transit switches; SIP load filtering can also be applied in both edge 1298 proxy servers and core proxy servers, and even in capable user 1299 agents. 1301 PSTN load filtering also has special accommodation for High 1302 Probability of Completion (HPC) calls, which would be similar to 1303 calls designated by the SIP Resource Priority Headers [RFC4412]. SIP 1304 load filtering mechanism also allows prioritizing the treatment of 1305 these calls by specifying favorable actions for them. 1307 PSTN load filtering also provides administrative option for routing 1308 failed call attempts to either a reorder tone [E.300SerSup3] 1309 indicating overload conditions, or a special recorded announcement. 1310 Similar capability can be provided in SIP load filtering mechanism by 1311 specifying appropriate "alt-action" attribute in the SIP load 1312 filtering action field. 1314 9.2. Relationship with Other IETF SIP Overload Control Efforts 1316 The load filtering policies in this specification consist of 1317 identity, action and time. The identity can range from a single 1318 specific user to an arbitrary user aggregate, domains or areas. The 1319 user can be identified by either the source or the destination. When 1320 the user is identified by the source and a favorable action is 1321 specified, the result is to some extent similar to identifying a 1322 priority user based on authorized Resource Priority Headers [RFC4412] 1323 in the requests. Specifying a source user identity with an 1324 unfavorable action would cause an effect to some extent similar to an 1325 inverse SIP resource priority mechanism. 1327 The load filtering policy defined in this specification is generic 1328 and expected to be applicable not only to the load filtering 1329 mechanism but also to the feedback overload control mechanism in 1330 [I-D.ietf-soc-overload-control]. In particular, both mechanisms 1331 could use specific or wildcard identities for load control and could 1332 share well-known load control actions. The time duration field in 1333 the load filtering policy could also be used in both mechanisms. As 1334 mentioned in Section 1, the load filtering policy distribution 1335 mechanism and the feedback overload control mechanism address 1336 complementary areas in the overload control problem space. Load 1337 filtering is more proactive and focuses on distributing filtering 1338 policies towards the source of the traffic; the hop-by-hop feedback- 1339 based approach is reactive and targets more at traffic already 1340 accepted in the network. Therefore, they could also make different 1341 use of the generic load filtering policy components. For example, 1342 the load filtering mechanism may use the time field in the filtering 1343 policy to specify not only a control duration but also a future 1344 activation time to accommodate a predicable overload such as the one 1345 caused by Mother's Day greetings or a viewer-voting program; the 1346 feedback-based control might not need to use the time field or might 1347 use the time field to specify an immediate load control duration. 1349 10. Discussion of this specification meeting the requirements of 1350 RFC5390 1352 This section evaluates whether the load control event package 1353 mechanism defined in this specification satisfies various SIP 1354 overload control requirements set forth by RFC5390 [RFC5390]. Not 1355 all RFC5390 requirements are found applicable due to the scope of 1356 this specification. Therefore, we categorize the assessment results 1357 into Yes (meet the requirement), P/A (Partially Applicable), No (must 1358 be used in conjunction with another mechanism to meet the 1359 requirement), and N/A (Not Applicable). 1361 REQ 1: The overload mechanism shall strive to maintain the overall 1362 useful throughput (taking into consideration the quality-of- 1363 service needs of the using applications) of a SIP server at 1364 reasonable levels, even when the incoming load on the network is 1365 far in excess of its capacity. The overall throughput under load 1366 is the ultimate measure of the value of an overload control 1367 mechanism. 1369 P/A. The goal of the load filtering is to prevent overload or 1370 maintain overall goodput during the time of overload, but it is 1371 dependent on the advance predictions of the load. If the predictions 1372 are incorrect, in either direction, the effectiveness of the 1373 mechanism will be affected. 1375 REQ 2: When a single network element fails, goes into overload, or 1376 suffers from reduced processing capacity, the mechanism should 1377 strive to limit the impact of this on other elements in the 1378 network. This helps to prevent a small-scale failure from 1379 becoming a widespread outage. 1381 N/A if load filtering policies are installed in advance and do not 1382 change during the potential overload period. P/A if load filtering 1383 policies are dynamically adjusted. The algorithm to dynamically 1384 compute load filtering policies is outside the scope of this 1385 specification, while the distribution of the updated filtering 1386 policies uses the event package mechanism of this specification. 1388 REQ 3: The mechanism should seek to minimize the amount of 1389 configuration required in order to work. For example, it is 1390 better to avoid needing to configure a server with its SIP message 1391 throughput, as these kinds of quantities are hard to determine. 1393 No. This mechanism is entirely dependent on advance configuration, 1394 based on advance knowledge. In order to satisfy Req 3, it should be 1395 used in conjunction with other mechanisms which are not based on 1396 advance configuration. 1398 REQ 4: The mechanism must be capable of dealing with elements that 1399 do not support it, so that a network can consist of a mix of 1400 elements that do and don't support it. In other words, the 1401 mechanism should not work only in environments where all elements 1402 support it. It is reasonable to assume that it works better in 1403 such environments, of course. Ideally, there should be 1404 incremental improvements in overall network throughput as 1405 increasing numbers of elements in the network support the 1406 mechanism. 1408 No. This mechanism is entirely dependent on the participation of all 1409 possible neighbors. In order to satisfy Req 4, it should be used in 1410 conjunction with other mechanisms, some of which are described in 1411 Section 5.4. 1413 REQ 5: The mechanism should not assume that it will only be 1414 deployed in environments with completely trusted elements. It 1415 should seek to operate as effectively as possible in environments 1416 where other elements are malicious; this includes preventing 1417 malicious elements from obtaining more than a fair share of 1418 service. 1420 No. This mechanism is entirely dependent on the non-malicious 1421 participation of all possible neighbors. In order to satisfy Req 5, 1422 it should be used in conjunction with other mechanisms, some of which 1423 are described in Section 5.4. 1425 REQ 6: When overload is signaled by means of a specific message, 1426 the message must clearly indicate that it is being sent because of 1427 overload, as opposed to other, non overload-based failure 1428 conditions. This requirement is meant to avoid some of the 1429 problems that have arisen from the reuse of the 503 response code 1430 for multiple purposes. Of course, overload is also signaled by 1431 lack of response to requests. This requirement applies only to 1432 explicit overload signals. 1434 N/A. This mechanism signals anticipated overload, not actual 1435 overload. However the signals in this mechanism are not used for any 1436 other purpose. 1438 REQ 7: The mechanism shall provide a way for an element to 1439 throttle the amount of traffic it receives from an upstream 1440 element. This throttling shall be graded so that it is not all- 1441 or-nothing as with the current 503 mechanism. This recognizes the 1442 fact that "overload" is not a binary state and that there are 1443 degrees of overload. 1445 Yes. This event package allows rate/loss/window-based overload 1446 control options as discussed in Section 7.4. 1448 REQ 8: The mechanism shall ensure that, when a request was not 1449 processed successfully due to overload (or failure) of a 1450 downstream element, the request will not be retried on another 1451 element that is also overloaded or whose status is unknown. This 1452 requirement derives from REQ 1. 1454 N/A to the load control event package mechanism itself. 1456 REQ 9: That a request has been rejected from an overloaded element 1457 shall not unduly restrict the ability of that request to be 1458 submitted to and processed by an element that is not overloaded. 1459 This requirement derives from REQ 1. 1461 Yes. For example, load filtering policy [Section 5.1] allows the 1462 inclusion of alternative forwarding destinations for rejected 1463 requests. 1465 REQ 10: The mechanism should support servers that receive requests 1466 from a large number of different upstream elements, where the set 1467 of upstream elements is not enumerable. 1469 No. Because this mechanism requires advance configuration of 1470 specifically identified neighbors, it does not support environments 1471 where the number and identity of the upstream neighbors are not known 1472 in advance. In order to satisfy Req 10, it should be used in 1473 conjunction with other mechanisms. 1475 REQ 11: The mechanism should support servers that receive requests 1476 from a finite set of upstream elements, where the set of upstream 1477 elements is enumerable. 1479 Yes. See also answer to REQ 10. 1481 REQ 12: The mechanism should work between servers in different 1482 domains. 1484 Yes. The load control event package mechanism is not limited by 1485 domain boundaries. However, it is likely more applicable in intra- 1486 domain scenarios than in inter-domain scenarios due to security and 1487 other concerns (See also Section 5.4). 1489 REQ 13: The mechanism must not dictate a specific algorithm for 1490 prioritizing the processing of work within a proxy during times of 1491 overload. It must permit a proxy to prioritize requests based on 1492 any local policy, so that certain ones (such as a call for 1493 emergency services or a call with a specific value of the 1494 Resource-Priority header field [RFC4412]) are given preferential 1495 treatment, such as not being dropped, being given additional 1496 retransmission, or being processed ahead of others. 1498 P/A. This mechanism does not specifically address the prioritizing of 1499 work during times of overload. But it does not preclude any 1500 particular local policy. 1502 REQ 14: The mechanism should provide unambiguous directions to 1503 clients on when they should retry a request and when they should 1504 not. This especially applies to TCP connection establishment and 1505 SIP registrations, in order to mitigate against avalanche restart. 1507 N/A to the load control event package mechanism itself. 1509 REQ 15: In cases where a network element fails, is so overloaded 1510 that it cannot process messages, or cannot communicate due to a 1511 network failure or network partition, it will not be able to 1512 provide explicit indications of the nature of the failure or its 1513 levels of congestion. The mechanism must properly function in 1514 these cases. 1516 P/A. Because the load filtering policies are provisioned in advance, 1517 they are not affected by the overload or failure of other network 1518 elements. But, on the other hand, they may not, in those cases, be 1519 able to protect the overloaded network elements (see Req 1). 1521 REQ 16: The mechanism should attempt to minimize the overhead of 1522 the overload control messaging. 1524 Yes. The standardized SIP event package mechanism [RFC6665] is used. 1526 REQ 17: The overload mechanism must not provide an avenue for 1527 malicious attack, including DoS and DDoS attacks. 1529 P/A. This mechanism does provide a potential avenue for malicious 1530 attacks. Therefore the security mechanisms for SIP event packages in 1531 general [RFC6665] and of section 10 of this specification should be 1532 used. 1534 REQ 18: The overload mechanism should be unambiguous about whether 1535 a load indication applies to a specific IP address, host, or URI, 1536 so that an upstream element can determine the load of the entity 1537 to which a request is to be sent. 1539 Yes. The identity of load indication is covered in the load filtering 1540 policy format definition in Section 5.1. 1542 REQ 19: The specification for the overload mechanism should give 1543 guidance on which message types might be desirable to process over 1544 others during times of overload, based on SIP-specific 1545 considerations. For example, it may be more beneficial to process 1546 a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh 1547 with a non-zero expiration (since the former reduces the overall 1548 amount of load on the element), or to process re-INVITEs over new 1549 INVITEs. 1551 N/A to the load control event package mechanism itself. 1553 REQ 20: In a mixed environment of elements that do and do not 1554 implement the overload mechanism, no disproportionate benefit 1555 shall accrue to the users or operators of the elements that do not 1556 implement the mechanism. 1558 No. This mechanism is entirely dependent on the participation of all 1559 possible neighbors. In order to satisfy Req 20, it should be used in 1560 conjunction with other mechanisms, some of which are described in 1561 Section 5.4. 1563 REQ 21: The overload mechanism should ensure that the system 1564 remains stable. When the offered load drops from above the 1565 overall capacity of the network to below the overall capacity, the 1566 throughput should stabilize and become equal to the offered load. 1568 N/A to the load control event package mechanism itself. 1570 REQ 22: It must be possible to disable the reporting of load 1571 information towards upstream targets based on the identity of 1572 those targets. This allows a domain administrator who considers 1573 the load of their elements to be sensitive information, to 1574 restrict access to that information. Of course, in such cases, 1575 there is no expectation that the overload mechanism itself will 1576 help prevent overload from that upstream target. 1578 N/A to the load control event package mechanism itself. 1580 REQ 23: It must be possible for the overload mechanism to work in 1581 cases where there is a load balancer in front of a farm of 1582 proxies. 1584 Yes. The load control event package mechanism does not preclude its 1585 use in a scenario with server farms. 1587 11. Security Considerations 1589 Two aspects of security considerations arise from this specification. 1590 One is the SIP event notification framework-based load filtering 1591 policy distribution mechanism, the other is the load filtering policy 1592 enforcement mechanism. 1594 Security considerations for SIP event package mechanisms are covered 1595 in Section 6 of [RFC6665]. A particularly relevant security concern 1596 for this event package is that if the notifiers can be spoofed, 1597 attackers can send fake notifications asking subscribers to throttle 1598 all traffic, leading to Denial-of-Service attacks. Therefore, all 1599 load filtering policy notifications MUST be authenticated and 1600 authorized before being accepted. Standard authentication and 1601 authorization mechanisms recommended in [RFC3261] such as TLS 1602 [RFC5246] and IPSec [RFC4301] may serve this purpose. On the other 1603 hand, if a legitimate notifier is itself compromised, additional 1604 mechanisms will be needed to detect the attack. 1606 Security considerations for load filtering policy enforcement depends 1607 very much on the contents of the policy. This specification defines 1608 possible match of the following SIP header fields in a load filtering 1609 policy: , , and . The 1610 exact requirement to authenticate and authorize these fields is up to 1611 the service provider. In general, if the identity field represents 1612 the source of the request, it SHOULD be authenticated and authorized; 1613 if the identity field represents the destination of the request, the 1614 authentication and authorization is optional. 1616 12. IANA Considerations 1618 This specification registers a SIP event package, a new MIME type, a 1619 new XML namespace, and a new XML schema. 1621 12.1. Load Control Event Package Registration 1623 This section registers an event package based on the registration 1624 procedures defined in [RFC6665]. 1626 Package name: load-control 1628 Type: package 1630 Published specification: This specification 1632 Person to contact: Charles Shen, charles@cs.columbia.edu 1634 12.2. application/load-control+xml MIME Registration 1636 This section registers a new MIME type based on the procedures 1637 defined in [RFC4288] and guidelines in [RFC3023]. 1639 MIME media type name: application 1641 MIME subtype name: load-control+xml 1643 Mandatory parameters: none 1645 Optional parameters: Same as charset parameter application/xml in 1646 [RFC3023] 1648 Encoding considerations: Same as encoding considerations of 1649 application/xml in [RFC3023] 1651 Security considerations: See Section 10 of [RFC3023] and Section 11 1652 of this specification 1654 Interoperability considerations: None 1656 Published Specification: This specification 1658 Applications which use this media type: load control of SIP entities 1660 Additional information: 1662 Magic number: None 1664 File extension: .xml 1666 Macintosh file type code: 'TEXT' 1668 Personal and email address for further information: 1670 Charles Shen, charles@cs.columbia.edu 1671 Intended usage: COMMON 1673 Author/Change Controller: IETF SOC Working Group 1674 , as designated by the IESG 1676 12.3. Load Control Schema Registration 1678 URI: urn:ietf:params:xml:schema:load-control 1680 Registrant Contact: IETF SOC working group, Charles Shen 1681 (charles@cs.columbia.edu). 1683 XML: the XML schema to be registered is contained in Section 8. 1685 Its first line is 1687 1689 and its last line is 1691 1693 13. Acknowledgements 1695 The authors would like to thank Bruno Chatras, Martin Dolly, Keith 1696 Drage, Ashutosh Dutta, Janet Gunn, Vijay Gurbani, Volker Hilt, Geoff 1697 Hunt, Carolyn Johnson, Hadriel Kaplan, Paul Kyzivat, Salvatore 1698 Loreto, Timothy Moran, Eric Noel, Parthasarathi R, Adam Roach, Shida 1699 Schubert, Robert Sparks, Phil Williams and other members of the SOC 1700 and SIPPING working group for many helpful comments. In particular, 1701 Bruno Chatras proposed the and condition 1702 elements along with many other text improvements. Janet Gunn 1703 provided detailed text suggestions including Section 10. Eric Noel 1704 suggested clarification on load filtering policy distribution 1705 initialization process. Shida Schubert made many suggestions about 1706 terminology usage. Phil Williams suggested adding support for delta 1707 updates. Ashutosh Dutta gave pointers to PSTN references. Adam 1708 Roach suggested RFC6665-related and other helpful clarifications. 1710 14. References 1712 14.1. Normative References 1714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1715 Requirement Levels", BCP 14, RFC 2119, March 1997. 1717 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1719 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1720 Types", RFC 3023, January 2001. 1722 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1723 A., Peterson, J., Sparks, R., Handley, M., and E. 1724 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1725 June 2002. 1727 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1728 January 2004. 1730 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1731 RFC 3966, December 2004. 1733 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1734 Registration Procedures", BCP 13, RFC 4288, December 2005. 1736 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1737 Polk, J., and J. Rosenberg, "Common Policy: A Document 1738 Format for Expressing Privacy Preferences", RFC 4745, 1739 February 2007. 1741 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1742 July 2012. 1744 14.2. Informative References 1746 [E.300SerSup3] 1747 ITU-T, "North American Precise Audible Tone Plan", E.300 1748 Series Supplement 3 , November 1988. 1750 [E.412] ITU-T, "Network Management Controls", E.412-2003 , 1751 January 2003. 1753 [I-D.ietf-soc-overload-control] 1754 Gurbani, V., Hilt, V., and H. Schulzrinne, "Session 1755 Initiation Protocol (SIP) Overload Control", 1756 draft-ietf-soc-overload-control-11 (work in progress), 1757 November 2012. 1759 [Q.1248.2] 1760 ITU-T, "Interface Recommendation for Intelligent Network 1761 Capability Set4:SCF-SSF interface", Q.1248.2 , July 2001. 1763 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1764 August 1999. 1766 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1767 Internet Protocol", RFC 4301, December 2005. 1769 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1770 Priority for the Session Initiation Protocol (SIP)", 1771 RFC 4412, February 2006. 1773 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1774 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1776 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1777 Emergency and Other Well-Known Services", RFC 5031, 1778 January 2008. 1780 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1781 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1783 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 1784 the Session Initiation Protocol", RFC 5390, December 2008. 1786 [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 1787 Considerations for Session Initiation Protocol (SIP) 1788 Overload Control", RFC 6357, August 2011. 1790 Authors' Addresses 1792 Charles Shen 1793 Columbia University 1794 Department of Computer Science 1795 1214 Amsterdam Avenue, MC 0401 1796 New York, NY 10027 1797 USA 1799 Phone: +1 212 854 3109 1800 Email: charles@cs.columbia.edu 1802 Henning Schulzrinne 1803 Columbia University 1804 Department of Computer Science 1805 1214 Amsterdam Avenue, MC 0401 1806 New York, NY 10027 1807 USA 1809 Phone: +1 212 939 7004 1810 Email: schulzrinne@cs.columbia.edu 1811 Arata Koike 1812 NTT Service Integration Labs 1813 3-9-11 Midori-cho Musashino-shi 1814 Tokyo, 184-0013 1815 Japan 1817 Phone: +81 422 59 6099 1818 Email: koike.arata@lab.ntt.co.jp