idnits 2.17.1 draft-ietf-soc-load-control-event-package-07.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 (February 1, 2013) is 4101 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) == 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: 2 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: August 5, 2013 A. Koike 6 NTT 7 February 1, 2013 9 A Session Initiation Protocol (SIP) Load Control Event Package 10 draft-ietf-soc-load-control-event-package-07.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 August 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 . . . . . . . . . . . . . . . 15 75 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 15 76 6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Load Control Document . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 36 99 12.1. Load Control Event Package Registration . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 104 14.1. Normative References . . . . . . . . . . . . . . . . . . . 38 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 the subscriber enforces load filtering policies, it needs to 608 prioritize requests and select those requests that need to be 609 rejected or redirected. This selection is largely a matter of local 610 policy. It is expected that the subscriber will follow local policy 611 as long as the result in reduction of traffic is consistent with the 612 overload algorithm in effect at that node. Accordingly, the 613 normative behavior in the next three paragraphs should be interpreted 614 with the understanding that the subscriber will aim to preserve local 615 policy to the fullest extent possible. 617 o The subscriber SHOULD honor the local policy for prioritizing SIP 618 requests such as policies based on message type, e.g., INVITEs 619 versus requests associated with existing sessions. 620 o The subscriber SHOULD honor the local policy for prioritizing SIP 621 requests based on the content of the Resource-Priority header 622 (RPH, [RFC4412]). Specific (namespace.value) RPH contents may 623 indicate high priority requests that should be preserved as much 624 as possible during overload. The RPH contents can also indicate a 625 low-priority request that is eligible to be dropped during times 626 of overload. 627 o The subscriber SHOULD honor the local policy for prioritizing SIP 628 requests relating to emergency calls as identified by the SOS URN 629 [RFC5031] indicating an emergency request. 631 A local policy can be expected to combine both the SIP request type 632 and the prioritization markings, and SHOULD be honored when overload 633 conditions prevail. 635 6.9. Handling of Forked Requests 637 Forking is not applicable when this load control event package 638 mechanism is used within a single-hop distance between neighboring 639 SIP entities. If communication scope of the load control event 640 package mechanism is among multiple hops, forking is not expected to 641 happen either because the subscription request is addressed to a 642 clearly defined SIP entity. However, in the unlikely case when 643 forking does happen, the load control event package only allows the 644 first potential dialog-establishing message to create a dialog, as 645 specified in Section 5.9 of [RFC6665]. 647 6.10. Rate of Notifications 649 Rate of notifications is likely not a concern for this local control 650 event package mechanism when it is used in a non-real-time mode for 651 relatively static load filtering policies. Nevertheless, if 652 situation does arise that a rather frequent load filtering policy 653 update is needed, it is RECOMMENDED that the notifier do not generate 654 notifications at a rate higher than once per-second in all cases, in 655 order to avoid the NOTIFY request itself overloading the system. 657 6.11. State Delta 659 It is likely that updates to specific load filtering policies are 660 made by changing only part of the policy parameters only (e.g. 661 acceptable request rate or percentage, but not matching identities). 662 This will typically be because the utilization of a resource subject 663 to overload depends upon dynamic unknowns such as holding time and 664 the relative distribution of offered loads over subscribing SIP 665 entities. The updates could originate manually or be determined 666 automatically by an algorithm that dynamically computes the load 667 filtering policies (Section 5.2). Another factor that is usually not 668 known precisely or needs to be computed automatically is the duration 669 of the event requiring load filtering. Therefore it would also be 670 common for the validity to change frequently. 672 This event package allows the use of state delta as in [RFC6665] to 673 accommodate frequent updates of partial policy parameters. For each 674 NOTIFY transaction in a subscription, a version number that increases 675 by exactly one MUST be included in the NOTIFY request body when the 676 body is present. When the subscriber receives a state delta, it 677 associates the partial updates to the particular policy by matching 678 the appropriate rule id (Section 7.5). If the subscriber receives a 679 NOTIFY request with a version number that is increased by more than 680 one, it knows that it has missed a state delta and needs to ask for a 681 full state snapshot. Therefore, the subscriber ignores that NOTIFY 682 request containing the state delta, and re-sends a SUBSCRIBE request 683 to force a NOTIFY request containing a complete state snapshot. 685 7. Load Control Document 687 7.1. Format 689 A load control document is an XML document that describes the load 690 filtering policies. It inherits and enhances the common policy 691 document defined in [RFC4745]. A common policy document contains a 692 set of rules. Each rule consists of three parts: conditions, actions 693 and transformations. The conditions part is a set of expressions 694 containing attributes such as identity, domain, and validity time 695 information. Each expression evaluates to TRUE or FALSE. Conditions 696 are matched on "equality" or "greater than" style comparison. There 697 is no regular expression matching. Conditions are evaluated on 698 receipt of an initial SIP request for a dialog or standalone 699 transaction. If a request matches all conditions in a rule set, the 700 action part and the transformation part are consulted to determine 701 the "permission" on how to handle the request. Each action or 702 transformation specifies a positive grant to the policy server to 703 perform the resulting actions. Well-defined mechanism are available 704 for combining actions and transformations obtained from more than one 705 sources. 707 7.2. Namespace 709 The namespace URI for elements defined by this specification is a 710 Uniform Resource Namespace (URN) ([RFC2141]), using the namespace 711 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 712 The URN is as follows: 714 urn:ietf:params:xml:ns:load-control 716 7.3. Conditions 718 [RFC4745] defines three condition elements: , and 719 . In this specification, we re-define an element for 720 identity, define a new element for method and reuse the 721 element. The element is not used. 723 7.3.1. Call Identity 725 Since the problem space of this specification is different from that 726 of [RFC4745], the [RFC4745] element is not sufficient for 727 use with load filtering. First, load filtering may be applied to 728 different identities contained in a request, including identities of 729 both the receiving entity and the sending entity. Second, the 730 importance of authentication varies when different identities of a 731 request are concerned. This specification defines new identity 732 conditions that can accommodate the granularity of specific SIP 733 identity header fields. The requirement for authentication depends 734 on which field is to be matched. 736 The identity condition for load filtering is specified by the element and its sub-element . The element 738 itself contains sub-elements representing SIP sending and receiving 739 identity header fields: , , and , each is of the same type as the element in 741 [RFC4745]. Therefore, they also inherit the sub-elements of the 742 element, including , , and . 744 The [RFC4745] and elements may contain an "id" 745 attribute, which is the URI of a single entity to be included or 746 excluded in the condition. When used in the , , and elements, this "id" value is the URI 748 contained in the corresponding SIP header field, i.e., From, To, 749 Request-URI, and P-Asserted-Identity. 751 When the element contains multiple sub- 752 elements, the result is combined using logical OR. When the , 753 , and elements contain 754 multiple or sub-elements, the result is also combined 755 using logical OR. When the sub-element further contains one 756 or more sub-elements, the result of each sub- 757 element is combined using a logical OR, similar to that of the 758 element in [RFC4745]. However, when the element 759 contains multiple of the , , and sub-elements, the result is combined using logical AND. 761 This allows the call identity to be specified by multiple fields of a 762 SIP request simultaneously, e.g., both the From and the To header 763 fields. 765 The following shows an example of the element, which 766 matches call requests whose To header field contains the SIP URI 767 "sip:alice@hotline.example.com", or the 'tel' URI 768 "tel:+1-212-555-1234". 770 771 772 773 774 775 776 777 779 Before evaluating call-identity conditions, the subscriber shall 780 convert URIs received in SIP header fields in canonical form as per 781 [RFC3261], except that the phone-context parameter shall not be 782 removed, if present. 784 The [RFC4745] and elements may take a "domain" 785 attribute. The "domain" attribute specifies a domain name to be 786 matched by the domain part of the candidate identity. Thus, it 787 allows matching a large and possibly unknown number of entities 788 within a domain. The "domain" attribute works well for SIP URIs. 790 A URI identifying a SIP user, however, can also be a 'tel' URI. We 791 therefore need a similar way to match a group of 'tel' URIs. 792 According to [RFC3966], there are two forms of 'tel' URIs for global 793 numbers and local numbers, respectively. All phone numbers must be 794 expressed in global form when possible. The global number 'tel' URIs 795 start with a "+". The rest of the numbers are expressed as local 796 numbers, which must be qualified by a "phone-context" parameter. The 797 "phone-context" parameter may be labelled as a global number or any 798 number of its leading digits, or a domain name. Both forms of the 799 'tel' URI make the resulting URI globally unique. 801 'Tel' URIs of global numbers can be grouped by prefixes consisting of 802 any number of common leading digits. For example, a prefix formed by 803 a country code or both the country and area code identifies telephone 804 numbers within a country or an area. Since the length of the country 805 and area code for different regions are different, the length of the 806 number prefix also varies. This allows further flexibility such as 807 grouping the numbers into sub-areas within the same area code. 'Tel' 808 URIs of local numbers can be grouped by the value of the "phone- 809 context" parameter. 811 To include the two forms of 'tel' URI grouping in the and 812 elements, one approach is to add a new attribute similar to 813 the "domain" attribute. In this specification, we decide on a 814 simpler approach. There are basically two types of grouping 815 attribute values for both SIP URIs and 'tel' URIs: domain name and 816 number prefix starting with "+". Both of them can be expressed as 817 strings. Therefore, we re-interpret the existing "domain" attribute 818 of the and elements to allow it to contain both types 819 of grouping attribute values. In particular, when the "domain" 820 attribute value starts with "+", it denotes a number prefix, 821 otherwise, the value denotes a domain name. Note that the tradeoff 822 of this simpler approach is the overlap in matching different types 823 of URIs. Specifically, a domain name in the "domain" attribute could 824 be matched by both a SIP URI with that domain name and a local number 825 'tel' URI containing the same domain name in the "phone-context". On 826 the other hand, a number prefix in the "domain" attribute could be 827 matched by both global number 'tel' URIs starting with those leading 828 digits, and local number 'tel' URIs having the same prefix in the 829 "phone-context" parameter. However, when the "phone-context" 830 coincides with the SIP domain name or the global number prefix, in 831 many cases the related phone numbers indeed belong to the same domain 832 or the same area, which means the overlap is not inappropriate. It 833 should be noted that the method of grouping local numbers as defined 834 in this specification does not support all cases. For example, if 835 the phone-context for short service numbers in a country is the 836 country code, this solution does not permit the definition of a load 837 filtering policy that excludes all E.164 numbers in that country but 838 retains all short service numbers. A complete solution for local 839 number grouping requires a separate method outside the scope of this 840 document. 842 The following example shows the use of the re-interpreted "domain" 843 attribute. It matches those requests calling to the number "+1-202- 844 999-1234" but are not calling from a "+1-212" prefix or a SIP From 845 URI domain of "manhattan.example.com". 847 848 849 850 851 852 853 854 855 856 857 858 859 861 7.3.2. Method 863 The load created on a SIP server depends on the type of initial SIP 864 requests for dialogs or standalone transactions. The 865 element specifies the SIP method to which the load filtering action 866 applies. When this element is not included, the load filtering 867 actions are applicable to all applicable initial requests. These 868 requests include INVITE, MESSAGE, REGISTER, SUBSCRIBE, OPTIONS, and 869 PUBLISH. Non-initial requests, such as ACK, BYE and CANCEL are not 870 subjected to load filtering. In addition, SUBSCRIBE requests are not 871 filtered if the event-type header field indicates the event package 872 defined in this specification. 874 The following example shows the use of the element in the 875 case the filtering actions should be applied to INVITE requests. 877 INVITE 879 7.3.3. Target SIP Entity 881 A SIP server that performs load filtering may have multiple paths to 882 route call requests matching the same set of call identity elements. 883 In those situations, the SIP load filtering server may desire to take 884 advantage of alternative paths and only apply load filtering actions 885 to matching requests for the next hop SIP entity that originated the 886 corresponding load filtering policy. To achieve that, the SIP load 887 filtering server needs to associate every load filtering policy with 888 its originating SIP entity. The element is 889 defined for that purpose and it contains the URI of the entity that 890 initiated the load filtering policy, which is generally the 891 corresponding notifier. A notifier MAY include this element as part 892 of the condition of its filtering policy being sent to the 893 subscriber, as below. 895 sip:biloxi.example.com 897 When a SIP load filtering server receives a policy with a element, it SHOULD record it and take it into 899 consideration when making load filtering decisions. If the load 900 filtering server receives a load filtering policy that does not 901 contain a element, it MAY still record the URI of 902 the load filtering policy's originator as the 903 information and consider it when making load filtering decisions. 905 The following are two examples of using the 906 element. Usecase I: the network has user A connected to SIP Proxy 907 1 (SP1), user B connected to SIP Proxy 3 (SP3), SP1 and SP3 908 connected via SIP Proxy 2 (SP2), and SP2 connected to an 909 Application Server (AS). Under normal load conditions, a call 910 from A to B is routed along the following path: 911 A-SP1-SP2-AS-SP3-B. The AS provides a non-essential service and 912 can be bypassed in case of overload. Now let's assume that AS is 913 overloaded and sends to SP2 a load filtering policy requesting 914 that 50% of all INVITE requests be dropped. SP2 can maintain AS 915 as the for that policy so that it knows the 916 50% drop action is only applicable to call requests that must go 917 through AS, without affecting those calls directly routed through 918 SP3 to B. Usecase II: An 800 translation service is installed on 919 two Application Servers, AS1 and AS2. User A is connected to SP1 920 and calls 800-1234-4529, which is translated by AS1 and AS2 into a 921 regular E.164 number depending on, e.g., the caller's location. 922 SP1 forwards INVITE requests with Request-URI = "800 number" to 923 AS1 or AS2 based on a load balancing strategy. As calls to 800- 924 1234-4529 creates a pre-overload condition in AS1, AS1 sends to 925 SP1 a load filtering policy requesting that 50% of calls towards 926 800-1234-4529 be rejected. In this case, SP1 can maintain AS1 as 927 the for the rule, and only apply the load 928 filtering policy on incoming requests that are intended to be sent 929 to AS1. Those requests that are sent to AS2, although matching 930 the of the filter, will not be affected. 932 7.3.4. Validity 934 A filtering policy is usually associated with a validity period 935 condition. This specification reuses the element of 936 [RFC4745], which specifies a period of validity time by pairs of 937 and sub-elements. When multiple time periods are 938 defined, the validity condition is evaluated to TRUE if the current 939 time falls into any of the specified time periods. i.e., it 940 represents a logical OR operation across all validity time periods. 942 The following example shows a element specifying a valid 943 period from 12:00 to 15:00 US Eastern Standard Time on 2008-05-31. 945 946 2008-05-31T12:00:00-05:00 947 2008-05-31T15:00:00-05:00 948 950 7.4. Actions 952 The actions a load filtering server takes on loads matching the load 953 filtering conditions are defined by the element in the load 954 filtering policy, which includes any one of the three sub-elements 955 , , and . The element denotes an absolute 956 value of the maximum acceptable request rate in requests per second; 957 the element specifies the relative percentage of incoming 958 requests that should be accepted; the element describes the 959 acceptable window size supplied by the receiver, which is applicable 960 in window-based load filtering. In static load filtering policy 961 configuration scenarios, using the sub-element is RECOMMENDED 962 because it is hard to enforce the percentage rate or window-based 963 load filtering when incoming load from upstream or reactions from 964 downstream are uncertain. (See [I-D.ietf-soc-overload-control] 965 [RFC6357] for more details on rate-based, loss-based and window-based 966 load control.) 968 In addition, the element takes an optional "alt-action" 969 attribute which can be used to explicitly specify the desired action 970 in case a request cannot be processed. The default "alt-action" 971 value is "reject" where the load filtering server will reject the 972 request with a 503 (Service Unavailable) response message. Other 973 possible "alt-action" values include "drop" for simple drop, and 974 "redirect" for redirecting the request to another target. It should 975 be noted that when running SIP over an unreliable transport such as 976 UDP, using the "drop" action will create message retransmissions that 977 further worsen the possible overload situation. Therefore, any 978 "drop" action applied to an unreliable transport MUST be treated as 979 if it were "reject". When the "alt-action" value is "redirect", an 980 "alt-target" attribute MUST be defined. The "alt-target" specifies 981 one URI or a list of URIs where the request should be redirected. 982 The server sends out the redirect URIs in a 300-class response 983 message. 985 In the following element example, the server accepts 986 maximum of 100 call requests per second. The remaining calls are 987 redirected to an answering machine. 989 990 992 100 993 994 996 7.5. Complete Examples 998 7.5.1. Load Control Document Examples 1000 This section presents two complete examples of load control documents 1001 valid with respect to the XML schema defined in Section 8. 1003 The first example assumes that a set of hotlines are set up at 1004 "sip:alice@hotline.example.com" and "tel:+1-212-555-1234". The 1005 hotlines are activated from 12:00 to 15:00 US Eastern Standard Time 1006 on 2008-05-31. The goal is to limit the incoming calls to the 1007 hotlines to 100 requests per second. Calls that exceed the rate 1008 limit are explicitly rejected. 1010 1011 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 INVITE 1026 1027 2008-05-31T12:00:00-05:00 1028 2008-05-31T15:00:00-05:00 1029 1030 1031 1032 1033 100 1034 1035 1037 1038 1040 The second example considers optimizing server resource usage of a 1041 three-day period during the aftermath of a hurricane. Incoming calls 1042 to the hurricane domain "newyork.example.com" will be limited to a 1043 rate of 100 requests per second, except for those calls originating 1044 from a particular rescue team domain "rescue.example.com". Outgoing 1045 calls from the hurricane domain or calls within the local domain are 1046 never limited. All calls that are throttled due to the rate limit 1047 will be forwarded to an answering machine with updated hurricane 1048 rescue information. 1050 1051 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 INVITE 1071 1072 2012-10-25T09:00:00+01:00 1073 2012-10-28T09:00:00+01:00 1074 1075 1076 1077 1079 100 1080 1081 1083 1084 1086 7.5.2. Message Flow Examples 1088 This section presents an example message flow of using the load 1089 control event package mechanism defined in this specification. 1091 atlanta biloxi 1092 | F1 SUBSCRIBE | 1093 |------------------>| 1094 | F2 200 OK | 1095 |<------------------| 1096 | F3 NOTIFY | 1097 |<------------------| 1098 | F4 200 OK | 1099 |------------------>| 1101 F1 SUBSCRIBE atlanta.example.com -> biloxi.example.com 1103 SUBSCRIBE sip:biloxi.example.com SIP/2.0 1104 Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy7cjbu3 1105 From: sip:atlanta.example.com;tag=162ab5 1106 To: sip:biloxi.example.com 1107 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1108 CSeq: 2012 SUBSCRIBE 1109 Contact: sip:atlanta.example.com 1110 Event: load-control 1111 Max-Forwards: 70 1112 Accept: application/load-control+xml 1113 Expires: 3600 1114 Content-Length: 0 1116 F2 200 OK biloxi.example.com -> atlanta.example.com 1118 SIP/2.0 200 OK 1119 Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy7cjbu3 1120 ;received=192.0.2.1 1121 To: ;tag=331dc8 1122 From: ;tag=162ab5 1123 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1124 CSeq: 2012 SUBSCRIBE 1125 Expires: 3600 1126 Contact: sip:biloxi.example.com 1127 Content-Length: 0 1129 F3 NOTIFY biloxi.example.com -> atlanta.example.com 1131 NOTIFY sip:atlanta.example.com SIP/2.0 1132 Via: SIP/2.0/TCP biloxi.example.com;branch=z9hG4bKy71g2ks 1133 From: ;tag=331dc8 1134 To: ;tag=162ab5 1135 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1136 Event: load-control 1137 Subscription-State: active;expires=3599 1138 Max-Forwards: 70 1139 CSeq: 1775 NOTIFY 1140 Contact: sip:biloxi.example.com 1141 Content-Type: application/load-control+xml 1142 Content-Length: ... 1144 [Load Control Document] 1146 F4 200 OK atlanta.example.com -> biloxi.example.com 1148 SIP/2.0 200 OK 1149 Via: SIP/2.0/TCP atlanta.example.com;branch=z9hG4bKy71g2ks 1150 ;received=192.0.2.2 1151 From: ;tag=331dc8 1152 To: ;tag=162ab5 1153 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com 1154 CSeq: 1775 NOTIFY 1155 Content-Length: 0 1157 8. XML Schema Definition for Load Control 1159 This section defines the XML schema for the load control document. 1160 It extends the Common Policy schema in [RFC4745] in two ways. 1161 Firstly, it defines two mandatory attributes for the 1162 element: version and state. The version attribute allows the 1163 recipient of the notification to properly order them. Versions start 1164 at 0, and increase by one for each new document sent to a subscriber 1165 within the same subscription. Versions MUST be representable using a 1166 non-negative 32 bit integer. The state attribute indicates whether 1167 the document contains a full load filtering policy update, or whether 1168 it contains only state delta as partial update. Secondly, it defines 1169 new members of the and elements. 1171 1172 1179 1181 1183 1184 1185 1186 1187 1188 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1205 1207 1208 1210 1211 1212 1213 1214 1216 1217 1218 1220 1221 1222 1223 1224 1225 1226 1228 1230 1231 1232 1234 1235 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1249 1250 1252 1253 1254 1255 1256 1257 1258 1260 1261 1262 1264 1265 1267 1268 1269 1270 1272 1274 9. Related Work 1276 9.1. Relationship with Load Filtering in PSTN 1278 It is known that existing PSTN network also uses a load filtering 1279 mechanism to prevent overload and the filtering policy configuration 1280 is done manually except in specific cases when the Intelligent 1281 Network architecture is used [Q.1248.2][E.412]. This specification 1282 defines a load filtering mechanism based on the SIP event 1283 notification framework that allows automated filtering policy 1284 distribution in suitable environments. 1286 There are control messages associated with PSTN overload control 1287 which would specify an outgoing control list, call gap duration and 1288 control duration [Q.1248.2][E.412]. These items could be roughly 1289 correlated to the identity, action and time fields of the SIP load 1290 filtering policy defined in this specification. However, the load 1291 filtering policy defined in this specification is much more generic 1292 and flexible as opposed to its PSTN counterpart. 1294 Firstly, PSTN load filtering only applies to telephone numbers. The 1295 identity element of SIP load filtering policy allows both SIP URI and 1296 telephone numbers (through Tel URI) to be specified. These 1297 identities can be arbitrarily grouped by SIP domains or any number of 1298 leading prefix of the telephone numbers. 1300 Secondly, the PSTN load filtering action is usually limited to call 1301 gapping. The action field in SIP load filtering policy allows more 1302 flexible possibilities such as rate throttle and others. 1304 Thirdly, the duration field in PSTN load filtering specifies a value 1305 in seconds for the load filtering duration only, and the allowed 1306 values are mapped into a value set. The time field in SIP load 1307 filtering policy may specify not only a duration, but also a future 1308 activation time which could be especially useful for automating load 1309 filtering for predictable overloads. 1311 PSTN load filtering can be performed in both edge switches and 1312 transit switches; SIP load filtering can also be applied in both edge 1313 proxy servers and core proxy servers, and even in capable user 1314 agents. 1316 PSTN load filtering also has special accommodation for High 1317 Probability of Completion (HPC) calls, which would be similar to 1318 calls designated by the SIP Resource Priority Headers [RFC4412]. SIP 1319 load filtering mechanism also allows prioritizing the treatment of 1320 these calls by specifying favorable actions for them. 1322 PSTN load filtering also provides administrative option for routing 1323 failed call attempts to either a reorder tone [E.300SerSup3] 1324 indicating overload conditions, or a special recorded announcement. 1325 Similar capability can be provided in SIP load filtering mechanism by 1326 specifying appropriate "alt-action" attribute in the SIP load 1327 filtering action field. 1329 9.2. Relationship with Other IETF SIP Overload Control Efforts 1331 The load filtering policies in this specification consist of 1332 identity, action and time. The identity can range from a single 1333 specific user to an arbitrary user aggregate, domains or areas. The 1334 user can be identified by either the source or the destination. When 1335 the user is identified by the source and a favorable action is 1336 specified, the result is to some extent similar to identifying a 1337 priority user based on authorized Resource Priority Headers [RFC4412] 1338 in the requests. Specifying a source user identity with an 1339 unfavorable action would cause an effect to some extent similar to an 1340 inverse SIP resource priority mechanism. 1342 The load filtering policy defined in this specification is generic 1343 and expected to be applicable not only to the load filtering 1344 mechanism but also to the feedback overload control mechanism in 1345 [I-D.ietf-soc-overload-control]. In particular, both mechanisms 1346 could use specific or wildcard identities for load control and could 1347 share well-known load control actions. The time duration field in 1348 the load filtering policy could also be used in both mechanisms. As 1349 mentioned in Section 1, the load filtering policy distribution 1350 mechanism and the feedback overload control mechanism address 1351 complementary areas in the overload control problem space. Load 1352 filtering is more proactive and focuses on distributing filtering 1353 policies towards the source of the traffic; the hop-by-hop feedback- 1354 based approach is reactive and targets more at traffic already 1355 accepted in the network. Therefore, they could also make different 1356 use of the generic load filtering policy components. For example, 1357 the load filtering mechanism may use the time field in the filtering 1358 policy to specify not only a control duration but also a future 1359 activation time to accommodate a predicable overload such as the one 1360 caused by Mother's Day greetings or a viewer-voting program; the 1361 feedback-based control might not need to use the time field or might 1362 use the time field to specify an immediate load control duration. 1364 10. Discussion of this specification meeting the requirements of 1365 RFC5390 1367 This section evaluates whether the load control event package 1368 mechanism defined in this specification satisfies various SIP 1369 overload control requirements set forth by RFC5390 [RFC5390]. Not 1370 all RFC5390 requirements are found applicable due to the scope of 1371 this specification. Therefore, we categorize the assessment results 1372 into Yes (meet the requirement), P/A (Partially Applicable), No (must 1373 be used in conjunction with another mechanism to meet the 1374 requirement), and N/A (Not Applicable). 1376 REQ 1: The overload mechanism shall strive to maintain the overall 1377 useful throughput (taking into consideration the quality-of- 1378 service needs of the using applications) of a SIP server at 1379 reasonable levels, even when the incoming load on the network is 1380 far in excess of its capacity. The overall throughput under load 1381 is the ultimate measure of the value of an overload control 1382 mechanism. 1384 P/A. The goal of the load filtering is to prevent overload or 1385 maintain overall goodput during the time of overload, but it is 1386 dependent on the advance predictions of the load. If the predictions 1387 are incorrect, in either direction, the effectiveness of the 1388 mechanism will be affected. 1390 REQ 2: When a single network element fails, goes into overload, or 1391 suffers from reduced processing capacity, the mechanism should 1392 strive to limit the impact of this on other elements in the 1393 network. This helps to prevent a small-scale failure from 1394 becoming a widespread outage. 1396 N/A if load filtering policies are installed in advance and do not 1397 change during the potential overload period. P/A if load filtering 1398 policies are dynamically adjusted. The algorithm to dynamically 1399 compute load filtering policies is outside the scope of this 1400 specification, while the distribution of the updated filtering 1401 policies uses the event package mechanism of this specification. 1403 REQ 3: The mechanism should seek to minimize the amount of 1404 configuration required in order to work. For example, it is 1405 better to avoid needing to configure a server with its SIP message 1406 throughput, as these kinds of quantities are hard to determine. 1408 No. This mechanism is entirely dependent on advance configuration, 1409 based on advance knowledge. In order to satisfy Req 3, it should be 1410 used in conjunction with other mechanisms which are not based on 1411 advance configuration. 1413 REQ 4: The mechanism must be capable of dealing with elements that 1414 do not support it, so that a network can consist of a mix of 1415 elements that do and don't support it. In other words, the 1416 mechanism should not work only in environments where all elements 1417 support it. It is reasonable to assume that it works better in 1418 such environments, of course. Ideally, there should be 1419 incremental improvements in overall network throughput as 1420 increasing numbers of elements in the network support the 1421 mechanism. 1423 No. This mechanism is entirely dependent on the participation of all 1424 possible neighbors. In order to satisfy Req 4, it should be used in 1425 conjunction with other mechanisms, some of which are described in 1426 Section 5.4. 1428 REQ 5: The mechanism should not assume that it will only be 1429 deployed in environments with completely trusted elements. It 1430 should seek to operate as effectively as possible in environments 1431 where other elements are malicious; this includes preventing 1432 malicious elements from obtaining more than a fair share of 1433 service. 1435 No. This mechanism is entirely dependent on the non-malicious 1436 participation of all possible neighbors. In order to satisfy Req 5, 1437 it should be used in conjunction with other mechanisms, some of which 1438 are described in Section 5.4. 1440 REQ 6: When overload is signaled by means of a specific message, 1441 the message must clearly indicate that it is being sent because of 1442 overload, as opposed to other, non overload-based failure 1443 conditions. This requirement is meant to avoid some of the 1444 problems that have arisen from the reuse of the 503 response code 1445 for multiple purposes. Of course, overload is also signaled by 1446 lack of response to requests. This requirement applies only to 1447 explicit overload signals. 1449 N/A. This mechanism signals anticipated overload, not actual 1450 overload. However the signals in this mechanism are not used for any 1451 other purpose. 1453 REQ 7: The mechanism shall provide a way for an element to 1454 throttle the amount of traffic it receives from an upstream 1455 element. This throttling shall be graded so that it is not all- 1456 or-nothing as with the current 503 mechanism. This recognizes the 1457 fact that "overload" is not a binary state and that there are 1458 degrees of overload. 1460 Yes. This event package allows rate/loss/window-based overload 1461 control options as discussed in Section 7.4. 1463 REQ 8: The mechanism shall ensure that, when a request was not 1464 processed successfully due to overload (or failure) of a 1465 downstream element, the request will not be retried on another 1466 element that is also overloaded or whose status is unknown. This 1467 requirement derives from REQ 1. 1469 N/A to the load control event package mechanism itself. 1471 REQ 9: That a request has been rejected from an overloaded element 1472 shall not unduly restrict the ability of that request to be 1473 submitted to and processed by an element that is not overloaded. 1474 This requirement derives from REQ 1. 1476 Yes. For example, load filtering policy [Section 5.1] allows the 1477 inclusion of alternative forwarding destinations for rejected 1478 requests. 1480 REQ 10: The mechanism should support servers that receive requests 1481 from a large number of different upstream elements, where the set 1482 of upstream elements is not enumerable. 1484 No. Because this mechanism requires advance configuration of 1485 specifically identified neighbors, it does not support environments 1486 where the number and identity of the upstream neighbors are not known 1487 in advance. In order to satisfy Req 10, it should be used in 1488 conjunction with other mechanisms. 1490 REQ 11: The mechanism should support servers that receive requests 1491 from a finite set of upstream elements, where the set of upstream 1492 elements is enumerable. 1494 Yes. See also answer to REQ 10. 1496 REQ 12: The mechanism should work between servers in different 1497 domains. 1499 Yes. The load control event package mechanism is not limited by 1500 domain boundaries. However, it is likely more applicable in intra- 1501 domain scenarios than in inter-domain scenarios due to security and 1502 other concerns (See also Section 5.4). 1504 REQ 13: The mechanism must not dictate a specific algorithm for 1505 prioritizing the processing of work within a proxy during times of 1506 overload. It must permit a proxy to prioritize requests based on 1507 any local policy, so that certain ones (such as a call for 1508 emergency services or a call with a specific value of the 1509 Resource-Priority header field [RFC4412]) are given preferential 1510 treatment, such as not being dropped, being given additional 1511 retransmission, or being processed ahead of others. 1513 P/A. This mechanism does not specifically address the prioritizing of 1514 work during times of overload. But it does not preclude any 1515 particular local policy. 1517 REQ 14: The mechanism should provide unambiguous directions to 1518 clients on when they should retry a request and when they should 1519 not. This especially applies to TCP connection establishment and 1520 SIP registrations, in order to mitigate against avalanche restart. 1522 N/A to the load control event package mechanism itself. 1524 REQ 15: In cases where a network element fails, is so overloaded 1525 that it cannot process messages, or cannot communicate due to a 1526 network failure or network partition, it will not be able to 1527 provide explicit indications of the nature of the failure or its 1528 levels of congestion. The mechanism must properly function in 1529 these cases. 1531 P/A. Because the load filtering policies are provisioned in advance, 1532 they are not affected by the overload or failure of other network 1533 elements. But, on the other hand, they may not, in those cases, be 1534 able to protect the overloaded network elements (see Req 1). 1536 REQ 16: The mechanism should attempt to minimize the overhead of 1537 the overload control messaging. 1539 Yes. The standardized SIP event package mechanism [RFC6665] is used. 1541 REQ 17: The overload mechanism must not provide an avenue for 1542 malicious attack, including DoS and DDoS attacks. 1544 P/A. This mechanism does provide a potential avenue for malicious 1545 attacks. Therefore the security mechanisms for SIP event packages in 1546 general [RFC6665] and of section 10 of this specification should be 1547 used. 1549 REQ 18: The overload mechanism should be unambiguous about whether 1550 a load indication applies to a specific IP address, host, or URI, 1551 so that an upstream element can determine the load of the entity 1552 to which a request is to be sent. 1554 Yes. The identity of load indication is covered in the load filtering 1555 policy format definition in Section 5.1. 1557 REQ 19: The specification for the overload mechanism should give 1558 guidance on which message types might be desirable to process over 1559 others during times of overload, based on SIP-specific 1560 considerations. For example, it may be more beneficial to process 1561 a SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh 1562 with a non-zero expiration (since the former reduces the overall 1563 amount of load on the element), or to process re-INVITEs over new 1564 INVITEs. 1566 N/A to the load control event package mechanism itself. 1568 REQ 20: In a mixed environment of elements that do and do not 1569 implement the overload mechanism, no disproportionate benefit 1570 shall accrue to the users or operators of the elements that do not 1571 implement the mechanism. 1573 No. This mechanism is entirely dependent on the participation of all 1574 possible neighbors. In order to satisfy Req 20, it should be used in 1575 conjunction with other mechanisms, some of which are described in 1576 Section 5.4. 1578 REQ 21: The overload mechanism should ensure that the system 1579 remains stable. When the offered load drops from above the 1580 overall capacity of the network to below the overall capacity, the 1581 throughput should stabilize and become equal to the offered load. 1583 N/A to the load control event package mechanism itself. 1585 REQ 22: It must be possible to disable the reporting of load 1586 information towards upstream targets based on the identity of 1587 those targets. This allows a domain administrator who considers 1588 the load of their elements to be sensitive information, to 1589 restrict access to that information. Of course, in such cases, 1590 there is no expectation that the overload mechanism itself will 1591 help prevent overload from that upstream target. 1593 N/A to the load control event package mechanism itself. 1595 REQ 23: It must be possible for the overload mechanism to work in 1596 cases where there is a load balancer in front of a farm of 1597 proxies. 1599 Yes. The load control event package mechanism does not preclude its 1600 use in a scenario with server farms. 1602 11. Security Considerations 1604 Two aspects of security considerations arise from this specification. 1605 One is the SIP event notification framework-based load filtering 1606 policy distribution mechanism, the other is the load filtering policy 1607 enforcement mechanism. 1609 Security considerations for SIP event package mechanisms are covered 1610 in Section 6 of [RFC6665]. A particularly relevant security concern 1611 for this event package is that if the notifiers can be spoofed, 1612 attackers can send fake notifications asking subscribers to throttle 1613 all traffic, leading to Denial-of-Service attacks. Therefore, all 1614 load filtering policy notifications MUST be authenticated and 1615 authorized before being accepted. Standard authentication and 1616 authorization mechanisms recommended in [RFC3261] such as TLS 1617 [RFC5246] and IPSec [RFC4301] may serve this purpose. On the other 1618 hand, if a legitimate notifier is itself compromised, additional 1619 mechanisms will be needed to detect the attack. 1621 Security considerations for load filtering policy enforcement depends 1622 very much on the contents of the policy. This specification defines 1623 possible match of the following SIP header fields in a load filtering 1624 policy: , , and . The 1625 exact requirement to authenticate and authorize these fields is up to 1626 the service provider. In general, if the identity field represents 1627 the source of the request, it SHOULD be authenticated and authorized; 1628 if the identity field represents the destination of the request, the 1629 authentication and authorization is optional. 1631 12. IANA Considerations 1633 This specification registers a SIP event package, a new MIME type, a 1634 new XML namespace, and a new XML schema. 1636 12.1. Load Control Event Package Registration 1638 This section registers an event package based on the registration 1639 procedures defined in [RFC6665]. 1641 Package name: load-control 1643 Type: package 1645 Published specification: This specification 1647 Person to contact: Charles Shen, charles@cs.columbia.edu 1649 12.2. application/load-control+xml MIME Registration 1651 This section registers a new MIME type based on the procedures 1652 defined in [RFC6838] and guidelines in [RFC3023]. 1654 MIME media type name: application 1656 MIME subtype name: load-control+xml 1658 Mandatory parameters: none 1660 Optional parameters: Same as charset parameter application/xml in 1661 [RFC3023] 1663 Encoding considerations: Same as encoding considerations of 1664 application/xml in [RFC3023] 1666 Security considerations: See Section 10 of [RFC3023] and Section 11 1667 of this specification 1669 Interoperability considerations: None 1671 Published Specification: This specification 1673 Applications which use this media type: load control of SIP entities 1674 Additional information: 1676 Magic number: None 1678 File extension: .xml 1680 Macintosh file type code: 'TEXT' 1682 Personal and email address for further information: 1684 Charles Shen, charles@cs.columbia.edu 1686 Intended usage: COMMON 1688 Author/Change Controller: IETF SOC Working Group 1689 , as designated by the IESG 1691 12.3. Load Control Schema Registration 1693 URI: urn:ietf:params:xml:schema:load-control 1695 Registrant Contact: IETF SOC working group, Charles Shen 1696 (charles@cs.columbia.edu). 1698 XML: the XML schema to be registered is contained in Section 8. 1700 Its first line is 1702 1704 and its last line is 1706 1708 13. Acknowledgements 1710 The authors would like to thank Bruno Chatras, Martin Dolly, Keith 1711 Drage, Ashutosh Dutta, Janet Gunn, Vijay Gurbani, Volker Hilt, Geoff 1712 Hunt, Carolyn Johnson, Hadriel Kaplan, Paul Kyzivat, Salvatore 1713 Loreto, Timothy Moran, Eric Noel, Parthasarathi R, Adam Roach, Shida 1714 Schubert, Robert Sparks, Phil Williams and other members of the SOC 1715 and SIPPING working group for many helpful comments. In particular, 1716 Bruno Chatras proposed the and condition 1717 elements along with many other text improvements. Janet Gunn 1718 provided detailed text suggestions including Section 10. Eric Noel 1719 suggested clarification on load filtering policy distribution 1720 initialization process. Shida Schubert made many suggestions about 1721 terminology usage. Phil Williams suggested adding support for delta 1722 updates. Ashutosh Dutta gave pointers to PSTN references. Adam 1723 Roach suggested RFC6665-related and other helpful clarifications. 1725 14. References 1727 14.1. Normative References 1729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1730 Requirement Levels", BCP 14, RFC 2119, March 1997. 1732 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1734 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1735 Types", RFC 3023, January 2001. 1737 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1738 A., Peterson, J., Sparks, R., Handley, M., and E. 1739 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1740 June 2002. 1742 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1743 January 2004. 1745 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1746 RFC 3966, December 2004. 1748 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1749 Polk, J., and J. Rosenberg, "Common Policy: A Document 1750 Format for Expressing Privacy Preferences", RFC 4745, 1751 February 2007. 1753 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1754 July 2012. 1756 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1757 Specifications and Registration Procedures", BCP 13, 1758 RFC 6838, January 2013. 1760 14.2. Informative References 1762 [E.300SerSup3] 1763 ITU-T, "North American Precise Audible Tone Plan", E.300 1764 Series Supplement 3 , November 1988. 1766 [E.412] ITU-T, "Network Management Controls", E.412-2003 , 1767 January 2003. 1769 [I-D.ietf-soc-overload-control] 1770 Gurbani, V., Hilt, V., and H. Schulzrinne, "Session 1771 Initiation Protocol (SIP) Overload Control", 1772 draft-ietf-soc-overload-control-11 (work in progress), 1773 November 2012. 1775 [Q.1248.2] 1776 ITU-T, "Interface Recommendation for Intelligent Network 1777 Capability Set4:SCF-SSF interface", Q.1248.2 , July 2001. 1779 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1780 August 1999. 1782 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1783 Internet Protocol", RFC 4301, December 2005. 1785 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1786 Priority for the Session Initiation Protocol (SIP)", 1787 RFC 4412, February 2006. 1789 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1790 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1792 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1793 Emergency and Other Well-Known Services", RFC 5031, 1794 January 2008. 1796 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1797 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1799 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 1800 the Session Initiation Protocol", RFC 5390, December 2008. 1802 [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 1803 Considerations for Session Initiation Protocol (SIP) 1804 Overload Control", RFC 6357, August 2011. 1806 Authors' Addresses 1808 Charles Shen 1809 Columbia University 1810 Department of Computer Science 1811 1214 Amsterdam Avenue, MC 0401 1812 New York, NY 10027 1813 USA 1815 Phone: +1 212 854 3109 1816 Email: charles@cs.columbia.edu 1818 Henning Schulzrinne 1819 Columbia University 1820 Department of Computer Science 1821 1214 Amsterdam Avenue, MC 0401 1822 New York, NY 10027 1823 USA 1825 Phone: +1 212 939 7004 1826 Email: schulzrinne@cs.columbia.edu 1828 Arata Koike 1829 NTT Service Integration Labs 1830 3-9-11 Midori-cho Musashino-shi 1831 Tokyo, 184-0013 1832 Japan 1834 Phone: +81 422 59 6099 1835 Email: koike.arata@lab.ntt.co.jp