idnits 2.17.1 draft-shen-sipping-load-control-event-package-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1199. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5647 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) ** Downref: Normative reference to an Informational RFC: RFC 2648 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-08) exists of draft-hilt-sipping-overload-05 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF SIPPING Working Group C. Shen 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: May 7, 2009 A. Koike 6 NTT 7 November 3, 2008 9 A Session Initiation Protocol (SIP) Load Control Event Package 10 draft-shen-sipping-load-control-event-package-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document defines a load control event package for the Session 40 Initiation Protocol (SIP). It allows SIP servers to distribute user 41 load control information to SIP servers. The load control 42 information can throttle outbound calls based on their destination 43 domain, telephone number prefix or for a specific user. The 44 mechanism helps to prevent signaling overload and complements 45 feedback-based SIP overload control efforts. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 51 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 4 52 4. Load Filtering Control Distribution . . . . . . . . . . . . . 5 53 4.1. Operation Overview and Examples . . . . . . . . . . . . . 5 54 4.2. Filter Contents . . . . . . . . . . . . . . . . . . . . . 7 55 4.3. Filter Computation . . . . . . . . . . . . . . . . . . . . 8 56 4.4. Applicability in Different Network Environments . . . . . 8 57 5. Load Control Event Package . . . . . . . . . . . . . . . . . . 8 58 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 9 59 5.2. Event Package Parameters . . . . . . . . . . . . . . . . . 9 60 5.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 9 61 5.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . . 9 62 5.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 9 63 5.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 9 64 5.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 10 65 5.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 10 66 5.9. Handling of Forked Requests . . . . . . . . . . . . . . . 11 67 5.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 11 68 5.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Load Control Document . . . . . . . . . . . . . . . . . . . . 11 70 6.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.3.1. Call Identity . . . . . . . . . . . . . . . . . . . . 12 74 6.3.2. Validity . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.5. Complete Examples . . . . . . . . . . . . . . . . . . . . 15 77 7. XML Schema Definition for Load Control . . . . . . . . . . . . 17 78 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8.1. Relationship with Load Filtering in PSTN . . . . . . . . . 19 80 8.2. Relationship with Other IETF SIP Load Control Efforts . . 20 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 10.1. Load Control Event Package Registration . . . . . . . . . 21 84 10.2. application/load-control+xml MIME Registration . . . . . . 22 85 10.3. Load Control Schema Registration . . . . . . . . . . . . . 23 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 90 Intellectual Property and Copyright Statements . . . . . . . . . . 26 92 1. Introduction 94 Proper functioning of Session Initiation Protocol (SIP) [RFC3265] 95 signaling servers is critical in SIP-based communications networks. 96 The performance of SIP severs can be severely degraded when the sever 97 is overloaded with excessive number of signaling requests. Both 98 legitimate and malicious traffic can overload SIP servers, despite 99 appropriate capacity planning. 101 There are three common examples of legitimate short-term increases in 102 call volumes. Viewer-voting TV shows or ticket giveaways may 103 generate millions of calls within a few minutes. Call volume may 104 also spike during special holidays such as New Year's Day and 105 Mother's Day. Finally, callers may want to reach friends and family 106 in natural disaster areas such as those affected by earthquakes. 107 When possible, only calls traversing overloaded servers should be 108 throttled under those conditions. 110 SIP load control mechanisms are needed to prevent congestion collapse 111 in these cases [I-D.ietf-sipping-overload-reqs]. There are two types 112 of load control approaches. In the first approach, feedback control, 113 SIP servers provide load limits to upstream servers, to reduce the 114 incoming rate of all SIP requests [I-D.hilt-sipping-overload]. These 115 upstream servers then drop or delay incoming SIP requests. Feedback 116 control is reactive and affects signaling messages that have already 117 been issued by user agent clients. They work well if core or 118 destination-specific SIP proxies are overloaded. By their nature, 119 they need to distribute rate, drop or window information to all 120 upstream SIP proxies and generally affect all calls equally, 121 regardless of destination. However, feedback control is ineffective 122 for edge-server overload. For example, for the ticket giveaway case, 123 almost all such calls will fail in the core SIP server. If the edge 124 server is also overloaded, calls to other destinations will also be 125 rejected or dropped. 127 Here, we propose an additional, complementary mechanism, called load 128 filtering. Network operators create filters that indicate that calls 129 to specific destinations or from specific sources should be rate- 130 limited or randomly dropped. These filters are then distributed to 131 SIP servers and possibly user agents likely to generate calls to the 132 affected destinations or from the affected sources. Load filters 133 work best if they prevent calls as close to the user agent client as 134 possible. 136 Performing SIP load filtering control requires three components: the 137 filter distribution mechanism, the filter content format definition, 138 and the filter content computation methods. This document addresses 139 the first two components. The filter distribution mechanism is built 140 upon the existing SIP event framework and the filter content format 141 definition is defined by the contents of a SIP load control event 142 package. The third component, filter content computation, depends 143 heavily on the actual network topology and service provider policies. 144 Therefore it is out of scope of this document. 146 The rest of this document is structured as follows: we begin by 147 listing the design requirements for this work in Section 3. We then 148 describe the SIP event framework based load filtering distribution 149 operation in Section 4. The load control event package is detailed 150 in Section 5. The load filter content definition is discussed in the 151 two sections that follow, with Section 6 defining the load control 152 XML document and Section 7 defining the corresponding XML schema. 153 Section 8 relates this work to corresponding mechanisms in PSTN and 154 other IETF efforts addressing SIP load control. Finally, Section 9 155 presents security considerations and Section 10 provides IANA 156 considerations. 158 2. Requirements Notation 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 3. Design Requirements 166 The SIP load filtering control mechanism needs to satisfy the 167 following requirements: 169 o To simplify the solution, we focus on SIP load control, rather 170 than a generic application-layer mechanism. 171 o The load filter information needs to be distributed efficiently to 172 possibly a large subset of all SIP elements. 173 o It is desirable to re-use existing SIP protocol mechanisms to 174 reduce implementation and deployment complexity. 175 o For predictable overload situations, such as holidays and call-in 176 events, the mechanism should specify during what time period it is 177 to be applied, so that the information can be distributed ahead of 178 time. 179 o For destination-specific overload situations, the load filter 180 needs to be able to describe the callee. 181 o To address accidental and intentional high-volume call generators, 182 the filter should allow to specify the caller. 183 o Caller and callee need to be specified as both Tel and SIP URIs. 184 o For telephone numbers, specifying prefixes allows control over 185 limited regionally-focused overloads. 187 o Solutions should draw upon experiences from related PSTN 188 mechanisms where applicable. 189 o Solutions need to be extensible to meet future needs. 191 4. Load Filtering Control Distribution 193 4.1. Operation Overview and Examples 195 Although it may be possible to manually configure load filters in the 196 corresponding entities, an automated distribution mechanism can have 197 many benefits such as efficiency, scalability and human error 198 avoidance, provided that the concerned entities satisfy the required 199 security and trust relationship of sending and accepting load control 200 information. 202 To meet the requirements enumerated in the previous section, this 203 document defines the SIP event package for load control, which is an 204 "instantiation" of the generic SIP events framework [RFC3265]. The 205 SIP events framework provides an existing method for SIP entities to 206 subscribe to and receive notifications when certain events have 207 occurred. Such a framework forms a scalable event distribution 208 architecture that suits our needs. This document also defines the 209 XML schema used to encode the load control document. The choice of 210 XML allows us to reuse existing SIP-specific policy related XML 211 schemas when applicable, and also fits our goal of flexibility and 212 extensibility. 214 The load filter distribution operation based on the SIP load control 215 event package is illustrated with the example architecture shown in 216 Figure 1. This scenario consists of two networks belonging to 217 Service Provider A and Service Provider B, respectively. Each 218 provider's network is made up of two SIP Core Proxies (CPs) and four 219 SIP Edge Proxies (EPs). The CPs and EPs of Service Provider A are 220 denoted as CPa1 to CPa2 and EPa1 to EPa4; the CPs and EPs of Service 221 Provider B are denoted as CPb1 to CPb2 and EPb1 to EPb4. 223 With the load filtering control mechanism, each SIP proxy in the 224 network is required to subscribe to the load control event package 225 from all its outgoing signaling neighbors. Signaling neighbors are 226 defined by sending signaling messages. For instance, if A sends 227 signaling requests to B, B is an outgoing signaling neighbor of A. A 228 needs to subscribe to the load control event package of B in case B 229 wants to curb requests from A. On the other hand, if B also sends 230 signaling requests to A, then B also subscribes to A. In the example 231 topology of Figure 1, assuming all signaling relationship is bi- 232 directional, each proxy will need to subscribe to all its neighbors. 233 That is, EPa1 subscribes to CPa1; CPa1 subscribes to EPa1, EPa2, CPa2 234 and CPb1, so on and so forth. Notifications are always sent to all 235 subscribing entities. 237 +-----------+ +-----------+ +-----------+ +-----------+ 238 | | | | | | | | 239 | EPa1 | | EPa2 | | EPa3 | | EPa4 | 240 | | | | | | | | 241 +-----------+ +-----------+ +-----------+ +-----------+ 242 \ / \ / 243 \ / \ / 244 \ / \ / 245 +-----------+ +-----------+ 246 | | | | 247 | CPa1 |------------------| CPa2 | 248 | | | | 249 +-----------+ +-----------+ 250 | | 251 Service | | 252 Provider A | | 253 | | 254 ================================================================= 255 | | 256 Service | | 257 Provider B | | 258 | | 259 +-----------+ +-----------+ 260 | | | | 261 | CPb1 |------------------| CPb2 | 262 | | | | 263 +-----------+ +-----------+ 264 / \ / \ 265 / \ / \ 266 / \ / \ 267 +-----------+ +-----------+ +-----------+ +-----------+ 268 | | | | | | | | 269 | EPb1 | | EPb2 | | EPb3 | | EPb4 | 270 | | | | | | | | 271 +-----------+ +-----------+ +-----------+ +-----------+ 273 Figure 1: Example Network Scenario with SIP Load Control Event 274 Notification 276 To begin load filter distribution on a network when the appropriate 277 subscriptions among the entities are ready, the initial filter 278 contents determined through a mechanism out of scope of this document 279 is introduced to a SIP server which acts as the network entry point 280 for load filtering control. The filter is then propagated to the 281 rest of the entities throughout the network. We show two examples 282 below. 284 Case I: EPa1 serves a TV program hotline and decides to limit the 285 total number of incoming calls to the hotline to prevent an overload. 286 To do so, EPa1 sends a notification to CPa1 with the specific hotline 287 number, time of activation and total acceptable call rate. CPa1 then 288 allocates the received total acceptable rate among its neighbors, 289 namely, EPa2, CPa2, and CPb1 and notifies them about the resulting 290 allocation along with the hotline number and the activation time. 291 CPa2 and CPb1 then perform further allocation among their own 292 neighbors and notify the corresponding servers. This process 293 continues until all edge proxies in the network has been informed 294 about the event and have proper load filter configured. 296 Case II: an earthquake affected the region covered by CPb2, EPb3 and 297 EPb4. All the three servers are overloaded. The rescue services 298 determine that outbound calls are more valuable than inbound calls in 299 this specific situation. Therefore, CPb2, EPb3 and EPb4 configure 300 themselves to accept more outbound calls than inbound calls. CPb2 301 also sends out notifications to its outside neighbors, namely CPb1 302 and CPa2, specifying a limit on the acceptable rate of inbound calls 303 to the CPb2's responsible region. CPb1 and CPa2 subsequently notify 304 their neighbors about limiting the calls to CPb2's area. The same 305 process continues until all edge proxy servers are notified and have 306 filters configured. 308 Note that this version of the document does not define the 309 provisioning interface between the load control policy maker and the 310 policy entry point in the network. One of the potential solutions 311 for the provisioning interface is the Extensible Markup Language 312 (XML) Configuration Access Protocol (XCAP) [RFC4825]. 314 4.2. Filter Contents 316 The above two examples covered the two typical resource limits in a 317 possible overload condition: human destination limits (N call takers) 318 and proxy capacity limits. The overloaded identities in the two 319 cases can be represented by a callee number specific filter and a 320 wildcard domain based filter, respectively. In addition, source 321 identity based filter can also be helpful in curbing the load. 323 Besides the identity of the load source and destination, the filter 324 content in the above examples also specifies the actions to be taken 325 and during which time period the control should be active. All these 326 aspects are detailed in the filter specification in Section 6. 328 4.3. Filter Computation 330 The filter content computation methods are very important in ensuring 331 a correct operation of the load filtering control mechanism. 332 Whatever computation algorithm is used, it needs to take into 333 consideration the network topology and related policies; it needs to 334 ensure there is no load filter allocation loop and loads are 335 allocated in a way that both prevents overload and minimizes the 336 possibility of an under-utilization of the network. 338 4.4. Applicability in Different Network Environments 340 The load filtering control is more effective when the filter can be 341 pushed to the proximity of the signaling sources. But even if only 342 part of the signaling path towards the signaling source could be 343 covered, use of this mechanism can still be beneficial. In fact, due 344 to possibly sophisticated call routing and security concerns, trying 345 to apply automated load filter distribution in the entire inter- 346 domain network path could get extremely complicated and be 347 unrealistic. 349 The scenarios where this mechanism could be most useful are 350 environments consisting of servers with secure and trust relationship 351 and with relatively straightforward routing configuration known to 352 the filter computation decision maker. These scenarios may include 353 intra-domain environments such as inside a service provider or 354 enterprise domain; inter-domain environments such as enterprise 355 connecting to a few service providers or between service providers 356 with manageable routing configurations. 358 Another important aspect that affects the applicability of the load 359 filtering control is that all possible signaling source neighbors 360 must participate and enforce the designated filter. Otherwise, a 361 single non-conforming neighbor could easily make the whole control 362 efforts useless by pumping in excessive traffic. Therefore, the 363 entity that initiates the filter needs to take counter-measures 364 towards any non-conforming neighbors. A simple model is to just drop 365 excessive requests with a 500 response as if they were obeying the 366 rate. This works as long as the dropping cost is sufficiently low 367 that the entity doing the dropping is not overloaded. Note that this 368 issue is a generic problem that applies to any overload control 369 mechanisms. 371 5. Load Control Event Package 373 This section defines the details of the SIP event package for load 374 control according to [RFC3265]. 376 5.1. Event Package Name 378 The name of this event package is "load-control". This name is 379 carried in the Event and Allow-Events header, as specified in 380 [RFC3265]. 382 5.2. Event Package Parameters 384 No package specific event header field parameters are defined for 385 this event package. 387 5.3. SUBSCRIBE Bodies 389 A SUBSCRIBE request for load control policy MAY contain a body to 390 filter the requested load control notification. For example, a 391 subscriber may be interested in some specific types of load control 392 information only. The details of the subscription filter 393 specification are not yet defined. 395 A SUBSCRIBE request sent without a body implies the default 396 subscription behavior as specified in Section 5.7. 398 5.4. SUBSCRIBE Duration 400 The default expiration time for a subscription to load control policy 401 is one hour. Since the desired expiration time may vary 402 significantly for subscriptions among SIP entities with different 403 signaling relationships, the subscribers and notifiers are 404 RECOMMENDED to explicitly negotiate appropriate subscription 405 durations when knowledge about the mutual signaling relationship is 406 available. 408 5.5. NOTIFY Bodies 410 The body of a NOTIFY message in this event package contains policy 411 information regarding load control. As specified in [RFC3265], the 412 format of the NOTIFY body MUST be in one of the formats defined in 413 the Accept header field of the SUBSCRIBE request or be the default 414 format. The default data format for the NOTIFY body of this event 415 package is "application/load-control+xml" (defined in Section 6). 416 This means that if no Accept header field is specified to a SUBSCRIBE 417 request, the NOTIFY will contain a body in the "application/ 418 load-control+xml" format. If the Accept header field is present, it 419 MUST include "application/load-control+xml" and MAY include any other 420 types. 422 5.6. Notifier Processing of SUBSCRIBE Requests 423 The effectiveness of load filtering control relies on the 424 distribution and installation of the control policies as widely as 425 possible in the network. Therefore, a SIP entity notifier MUST 426 accept subscriptions from all neighboring SIP entities with whom they 427 have a direct signaling relationship. 429 5.7. Notifier Generation of NOTIFY Requests 431 Following the [RFC3265] specification, a notifier MUST send a NOTIFY 432 with its current load control policy to the subscriber upon 433 successfully accepting or refreshing a subscription. A notifier 434 SHOULD generate NOTIFY requests each time the load control policy 435 changes, with the maximum notification rate not exceeding values 436 defined in Section 5.10. 438 A SIP entity subscriber which itself is also a notifier may need to 439 forward a NOTIFY message to its own subscribers after receiving a 440 load control update from its own notifier. In such cases, the 441 forwarding SIP entity MUST make proper modifications to the contents 442 of the NOTIFY message as needed before sending it out. For example, 443 if a SIP entity receives a rate limit of 100 requests per second for 444 a particular downstream SIP entity and it needs to forward the policy 445 to its three upstream neighbors which all subscribe to it, then the 446 total rate limit for the specific downstream SIP entity in the three 447 NOTIFY messages sent to those three upstream neighbors must not 448 exceed 100 requests per second. 450 This event package does not support notifications that contain deltas 451 to previous information or partial information. 453 5.8. Subscriber Processing of NOTIFY Requests 455 The way subscribers process NOTIFY requests depends on the contents 456 of the notifications. Typically, a load control notification 457 consists of rules that should be applied to requests matching certain 458 identities. A SIP entity subscriber receiving the notification first 459 installs these rules and then filter incoming call requests to 460 enforce actions on appropriate requests, for example, limiting the 461 sending rate of call requests destined for a specific SIP entity. 463 In the case when load control rules specify a future validity time, 464 it is possible that when the validity time comes, the subscription to 465 the specific notifier that conveyed the rules has expired. In this 466 case, it is RECOMMENDED that the subscriber re-activate its 467 subscription with the corresponding notifier. Regardless of whether 468 this re-activation of subscription is successful or not, when the 469 validity time is reached, the subscriber SHOULD enforce the 470 corresponding rules. 472 5.9. Handling of Forked Requests 474 Forking is not applicable when the load control event package is used 475 within a single-hop distance between neighboring SIP entities. If 476 the communication scope of the load-control event package is among 477 multiple hops, forking is not expected to happen either because the 478 subscription request is addressed to a clearly defined SIP entity. 479 However, in the unlikely case when forking does happen, the load- 480 control event package only allows the first potential dialog- 481 establishing message to create a dialog, as specified in Section 482 4.4.9 of [RFC3265]. 484 5.10. Rate of Notifications 486 Rate of notifications is likely not a concern for this event package 487 because it is expected to be used in a non-real-time mode for 488 relatively static load control policies. Nevertheless, if situation 489 does arise that a rather frequent load control policy update is 490 needed, it is RECOMMENDED that the notifier does not generate 491 notifications at a rate higher than once per-second in all cases, in 492 order to avoid the NOTIFY message itself overloading the system. 494 5.11. State Agents 496 The load control policy information can be directly generated by 497 concerned SIP entities distributed in the network. Alternatively, 498 qualified state agents external to the SIP entities MAY be defined to 499 take charge of load control policy making. 501 6. Load Control Document 503 6.1. Format 505 A load control document is an XML document that inherits and enhances 506 the common policy document defined in [RFC4745]. A common policy 507 document contains a set of rules. Each rule consists of three parts: 508 conditions, actions and transformations. The conditions part is a 509 set of expressions containing attributes such as identity, domain, 510 and validity time information. Each expression evaluates to TRUE or 511 FALSE. Conditions are matched on "equality" or "greater than" style 512 comparison. There is no regular expression matching. If a request 513 matches all conditions in a rule set, the action part and the 514 transformation part are consulted to determine the "permission" on 515 how to handle the request. Each action or transformation specifies a 516 positive grant to the policy server to perform the resulting actions. 517 Well-defined mechanism are available for combining actions and 518 transformations obtained from more than one sources. 520 6.2. Namespace 522 The namespace URI for elements defined by this specification is a 523 Uniform Resource Namespace (URN) ([RFC2141]), using the namespace 524 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 525 The URN is as follows: 527 urn:ietf:params:xml:ns:load-control 529 6.3. Conditions 531 [RFC4745] defined three condition elements: , and 532 . In this document, we re-define an element for identity 533 and reuse the element. The element is not used. 535 6.3.1. Call Identity 537 Since the problem space of this document is different from that of 538 [RFC4745], the [RFC4745] element is not sufficient for use 539 with load control. First, load control may be applied to different 540 identity information contained in a request, including identities of 541 both the receiving entity and the sending entity. Second, the 542 importance of authentication varies when different identities of a 543 request are concerned. This document defines new identity conditions 544 that can accommodate the granularity of specific SIP identity header 545 fields. Requirement for authentication depends on which field is to 546 be matched. 548 The identity condition for load control is specified by the element and its sub-element . The element 550 itself contains sub-elements representing SIP sending and receiving 551 identity header fields: , , and , each is of the same type as the element in 553 [RFC4745]. Therefore, they also inherit the sub-elements of the 554 element, including , , and . When the 555 element or its sub-elements contain multiple sub- 556 elements, the result is combined using logical OR. 558 The [RFC4745] and elements may contain an "id" 559 attribute, which is the URI of a single entity to be included or 560 excluded in the condition. When used in the , , and elements, this "id" value is the URI 562 contained in the corresponding SIP header field, i.e., From, To, 563 Request-URI, and P-Asserted-Identity. 565 The following shows an example of the element: 567 568 569 570 571 572 573 574 576 This example matches call requests whose To header field contains the 577 SIP URI "sip:alice@hotline.example.com", or 'tel' URI 578 "tel:+1-212-555-1234". 580 The [RFC4745] and elements may take a "domain" 581 attribute. The "domain" attribute specifies a domain name to be 582 matched by the domain part of the candidate identity. Thus, it 583 allows matching a large and possibly unknown number of entities 584 within a domain. The "domain" attribute works well for SIP URIs. 586 A URI identifying a SIP user, however, can also be a 'tel' URI 587 [RFC3966]. We therefore need a similar way to match a group of 'tel' 588 URIs. There are two formats of 'tel' URIs: global format and local 589 format. All phone numbers must be expressed in the global format 590 when possible. The global format 'tel' URIs start with a "+". The 591 rest of the phone numbers are expressed in a local format, which must 592 be qualified by a "phone-context" parameter. The "phone-context" 593 parameter may be labelled as a global number or any number of its 594 leading digits, or a domain name. Both formats of the 'tel' URI make 595 the resulting URI globally unique. 597 'Tel' URIs of global format can be grouped by prefixes consisting of 598 any number of common leading digits. For example, a prefix formed by 599 a country code or both the country and area code identifies telephone 600 numbers within a country or an area. Since the length of the country 601 and area code for different regions are different, the length of the 602 number prefix is also variable. This allows further flexibility such 603 as grouping the numbers into sub-areas within the same area code. 604 'Tel' URIs of local-number format can be grouped by the value of the 605 "phone-context" parameter. 607 To include the two formats of 'tel' URI grouping in the and 608 elements, one approach is to add a new attribute similar to 609 the "domain" attribute. In this document, we decided on a simpler 610 approach. There are basically two forms of grouping attribute values 611 for both SIP URIs and 'tel' URIs: domain name or number prefix 612 starting with "+". Both of them can be expressed as strings. 613 Therefore, we re-interpret the existing "domain" attribute of the 614 and elements to allow it to contain both forms of 615 grouping attribute values. In particular, when the "domain" 616 attribute value starts with "+", it denotes a number prefix, 617 otherwise, the value denotes a domain name. Note that the tradeoff 618 of this simpler approach is the overlapping in matching different 619 types of URIs. Specifically, a domain name in the "domain" attribute 620 could be matched by both a SIP URI with that domain name and a local 621 format 'tel' URI containing the same domain name in the "phone- 622 context". On the other hand, a number prefix in the "domain" 623 attribute could be matched by both global 'tel' URIs starting with 624 those leading digits, and local 'tel' URIs having the same prefix in 625 the "phone-context" parameter. These overlapping situations would 626 not be a big problem because of two reasons. First, when the "phone- 627 context" coincides with the SIP domain name or the global number 628 prefix, it is usually the case that the related phone numbers indeed 629 belong to the same domain or the same area, which means the 630 overlapping is not inappropriate. Second, the use of the local 631 format 'tel' URI in practice is expected to be rare. As a result, 632 the chance of such overlapping happening is very small. 634 The following example shows the use of the re-interpreted "domain" 635 attribute. 637 638 639 640 641 642 643 644 645 646 648 This example matches those call requests whose domain field in the 649 From SIP URI is different from "manhattan.example.com", or those call 650 requests whose 'Tel' URI indicates a caller number starting from a 651 prefix other than "+1-212". 653 6.3.2. Validity 655 A rule is usually associated with a validity period condition. This 656 document reuses the element of [RFC4745], which specifies 657 a period of validity time by pairs of and sub- 658 elements. When multiple time periods are defined, the validity 659 condition is evaluated to TRUE if the current time falls into any of 660 the specified time periods. i.e., it represents a logical OR 661 operation across all validity time periods. 663 The following example shows a element specifying a valid 664 period from 12:00 to 15:00 US Eastern Standard Time on 2008-05-31. 666 667 2008-05-31T12:00:00-05:00 668 2008-05-31T15:00:00-05:00 669 671 6.4. Actions 673 As [RFC4745] specified, conditions form the 'if'-part of rules, while 674 actions and transformations form the 'then'-part. Transformations 675 are not used in the load control document. The actions for load 676 control are defined by the element, which takes any one of 677 the three sub-elements , , and . The 678 element denotes an absolute value of the maximum acceptable request 679 rate in requests per second; the element specifies the 680 relative percentage of incoming requests that should be accepted; the 681 element describes the acceptable window size supplied by the 682 receiver, which is applicable in window-based load control (See 683 [I-D.hilt-sipping-overload] for more details on rate-based and 684 window-based load control). 686 In addition, the element takes an optional "alt-action" 687 attribute which can be used to explicitly specify the desired action 688 in case a request is not accepted. The possible "alt-action" values 689 are "Drop" for simple drop, "Reject" for explicit rejection (e.g., 690 sending a "503 Service Unavailable" response message to an INVITE 691 request), and "Forward". The default value is "Drop". If the "alt- 692 action" value is "Forward", an "alt-target" attribute MUST be 693 defined. The "alt-target" specifies a URI where the request should 694 be forwarded (e.g., an answering machine with explanation of why the 695 request cannot be accepted). 697 In the following element example, the server accepts 698 maximum of 100 call requests per second. The remaining calls are 699 forwarded to an answering machine. 701 702 704 100 705 706 708 6.5. Complete Examples 710 This section presents two complete examples of rule sets. 712 The example below assumes a hotline reachable through 713 "sip:alice@hotline.example.com" or "tel:+1-212-555-1234". The 714 hotline is activated from 12:00 to 15:00 US Eastern Standard Time on 715 2008-05-31. The goal is to limit the incoming calls to 100 requests 716 per second. Calls that exceed the rate limit are explicitly 717 rejected. 719 720 723 724 725 726 727 728 729 730 731 732 733 734 2008-05-31T12:00:00-05:00 735 2008-05-31T15:00:00-05:00 736 737 738 739 740 100 741 742 744 745 747 The following example assumes a three-day period during the aftermath 748 of an earthquake. To optimize resource usage, 50 percent of the 749 inbound calls to the region will be throttled but no throttle is 750 placed on outbound calls. In addition, calls originating from the 751 local domain and the rescue team domain are never throttled. All 752 throttled inbound calls will be forwarded to an answering machine 753 with updated earthquake information. 755 756 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 79-08-24T09:00:00+01:00 779 79-08-27T09:00:00+01:00 780 781 782 783 785 50 786 787 789 790 792 7. XML Schema Definition for Load Control 794 This section defines the XML schema for the load-control document. 795 It extends the Common Policy schema in [RFC4745] by defining new 796 members of the and elements. 798 799 806 808 810 811 813 814 815 816 817 819 820 821 823 824 825 826 827 828 829 831 833 834 835 837 839 840 841 842 843 844 846 847 848 849 850 851 853 8. Related Work 855 8.1. Relationship with Load Filtering in PSTN 857 It is known that the existing PSTN network also uses a load filtering 858 mechanism to prevent overload and the filter configuration is done 859 manually. This document defines the SIP event framework based 860 distribution mechanism which allows automated filter distribution in 861 suitable environments. 863 There are control messages associated with PSTN overload control 864 which would specify an outgoing control list, call gap duration and 865 control duration [AINGR]. These items could be roughly correlated to 866 the identity, action and the time fields in the SIP load filter 867 content definition in this document. However, the filter defined in 868 this document is much more generic and flexible as opposed to its 869 PSTN counterpart. 871 Firstly, PSTN filtering only applies to telephone numbers, and the 872 number of prefix to be matched for a group of telephone numbers is 873 usually a fixed set. The SIP filter identity allows both SIP URI and 874 telephone numbers (through Tel URI) to be specified. The identities 875 can be arbitrary grouped by SIP domains or any number of leading 876 prefix of the telephone number. 878 Secondly, the PSTN filtering action is usually limited to call 879 gapping, and there is also a fixed set of allowed gapping intervals. 880 The action field in the SIP load filter allows more possibilities 881 such as rate throttle, window-based throttle and others. 883 Thirdly, the duration field in PSTN filtering specifies a value in 884 seconds for the control duration only and the allowed values are 885 mapped into a value sets. The time field in the SIP load filter can 886 not only specify a duration, but also a future activation time which 887 could be especially useful for automating overload control for 888 predictable overloads. 890 PSTN filtering can be performed in both edge switches and transit 891 switches; SIP filtering can also be applied in both edge proxies and 892 core proxies, and even in capable user agents. 894 PSTN overload control also has special accommodation for High 895 Probability of Completion (HPC) calls, which would be similar to the 896 calls designated by the SIP Resource Priority Headers [RFC4412]. SIP 897 filtering mechanism can also prioritize the treatment of these calls 898 by specifying favorable actions for these calls. 900 PSTN filtering also provides administrative option for routing failed 901 call attempts to either Reorder Tone or a special announcement. 902 Similar capability can be provided in the SIP filtering mechanism by 903 specifying the appropriate "alt-action" attribute in the SIP 904 filtering action field. 906 8.2. Relationship with Other IETF SIP Load Control Efforts 908 The filter content definition in this document is based on identity, 909 action and time. The identity can range from a single specific user 910 to an arbitrary user aggregate, domains or areas. The user can be 911 identified by either the source or the destination. When the user is 912 identified by the source and a favorable action is specified, the 913 result may be comparable to identifying a priority user based on 914 authorized Resource Priority Headers [RFC4412] in the requests. 915 Specifying a source user identity with an unfavorable action would 916 cause an effect comparable to an inverse SIP resource priority 917 mechanism. 919 The filter content defined in this document is generic and is 920 expected to be applicable not only to the load filtering control 921 mechanism but also to the feedback overload control mechanism in 922 [I-D.hilt-sipping-overload]. In particular, both of them could use 923 specific or wildcard filter identities for load control and could 924 share well-known load control actions. The time duration field in 925 the filter content could also be used in both mechanisms. As 926 mentioned in Section 1, the load filter distribution mechanism and 927 the feedback overload control mechanism address complementary areas 928 in the load control problem space. Load filtering is more proactive 929 and focuses on distributing the filter towards the source of the 930 traffic; the hop-by-hop feedback based approach is reactive and 931 targets more at traffic already accepted in the network. Therefore, 932 they could also make different use of the generic filter components. 933 For example, the load filtering mechanism may use the time field in 934 the filter to specify not only a control duration but also a future 935 activation time to accommodate a predicable overload such as caused 936 by Mother's Day or a viewer-voting program; the feedback-based 937 control might not need to use the time field or might use the time 938 field to specify an immediate control duration. 940 9. Security Considerations 942 Two aspects of security considerations arise from this document: one 943 is the SIP event framework based filter distribution mechanism, the 944 other is the filter enforcement mechanism. 946 Security considerations for the SIP event framework based mechanism 947 is covered in Section 5 of [RFC3265]. In addition, we would like to 948 emphasize the following two points specific to this document. 950 o Subscription control: the effectiveness of load filtering requires 951 that all incoming signaling neighbors be under control. 952 Therefore, the notifier MUST open the load control subscription to 953 all its legitimate neighbors from which it is expected to accept 954 signaling requests from. It is important to note that, accepting 955 load control subscription from a neighbor does not mean the 956 specific neighbor will correctly enforce the contents of load 957 control notification as expected. When there are neighbors that 958 are non-conforming, additional measures need to be taken as 959 discussed in Section 4.4. 961 o Notification control: in order to prevent the load control 962 notification being used to launch denial of service attacks, all 963 load control notification MUST be authenticated and authorized 964 before being accepted. Standard authentication and authorization 965 mechanisms recommended in [RFC3261] such as HTTP authentication 966 [RFC2617], TLS [RFC2246] and IPSec [RFC2401] can serve this 967 purpose. 969 Security considerations for filter enforcements vary depending on the 970 filter contents. This document defines possible filter match of the 971 following SIP header fields: , , and 972 . The exact requirement to authenticate and 973 authorize these fields is up to the service provider. In general, if 974 the identity field represents the source of the request, it SHOULD be 975 authenticated and authorized; if the identity field represents the 976 destination of the request the authentication and authorization is 977 optional. 979 10. IANA Considerations 981 This specification registers a SIP event package, a new MIME type, a 982 new XML namespace, and a new XML schema. 984 10.1. Load Control Event Package Registration 986 This section registers an event package based on the registration 987 procedures defined in [RFC3265]. 989 Package name: load-control 990 Type: package 992 Published specification: This document 994 Person to contact: Charles Shen, charles@cs.columbia.edu 996 10.2. application/load-control+xml MIME Registration 998 This section registers a new MIME type based on the procedures 999 defined in [RFC4288] and guidelines in [RFC3023]. 1001 MIME media type name: application 1003 MIME subtype name: load-control+xml 1005 Mandatory parameters: none 1007 Optional parameters: Same as charset parameter application/xml in 1008 [RFC3023] 1010 Encoding considerations: Same as encoding considerations of 1011 application/xml in [RFC3023] 1013 Security considerations: See Section 10 of [RFC3023] and Section 9 of 1014 this specification 1016 Interpretability considerations: None 1018 Published Specification: This document 1020 Applications which use this media type: load control of SIP entities 1022 Additional information: 1024 Magic number: None 1026 File extension: .xml 1028 Macintosh file type code: 'TEXT' 1030 Personal and email address for further information: 1032 Charles Shen, charles@cs.columbia.edu 1034 Intended usage: COMMON 1036 Author/Change Controller: IETF SIPPING Working Group 1037 , as designated by the IESG 1039 10.3. Load Control Schema Registration 1041 URI: urn:ietf:params:xml:schema:load-control 1043 Registrant Contact: IETF SIPPING working group, Charles Shen 1044 (charles@cs.columbia.edu). 1046 XML: the XML schema to be registered is contained in Section 7. 1048 Its first line is 1050 1052 and its last line is 1054 1056 11. References 1058 11.1. Normative References 1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1061 Requirement Levels", BCP 14, RFC 2119, March 1997. 1063 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1065 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1066 August 1999. 1068 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1069 Types", RFC 3023, January 2001. 1071 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1072 A., Peterson, J., Sparks, R., Handley, M., and E. 1073 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1074 June 2002. 1076 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1077 Event Notification", RFC 3265, June 2002. 1079 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1080 January 2004. 1082 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1083 RFC 3966, December 2004. 1085 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1086 Registration Procedures", BCP 13, RFC 4288, December 2005. 1088 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1089 Polk, J., and J. Rosenberg, "Common Policy: A Document 1090 Format for Expressing Privacy Preferences", RFC 4745, 1091 February 2007. 1093 11.2. Informative References 1095 [AINGR] Bell Communications Research, "AINGR: Service Control 1096 Point (SCP) Network Traffic Management", GR-2938-CORE , 1097 December 1996. 1099 [I-D.hilt-sipping-overload] 1100 Hilt, V., Widjaja, I., and H. Schulzrinne, "Session 1101 Initiation Protocol (SIP) Overload Control", 1102 draft-hilt-sipping-overload-05 (work in progress), 1103 July 2008. 1105 [I-D.ietf-sipping-overload-reqs] 1106 Rosenberg, J., "Requirements for Management of Overload in 1107 the Session Initiation Protocol", 1108 draft-ietf-sipping-overload-reqs-05 (work in progress), 1109 July 2008. 1111 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1112 RFC 2246, January 1999. 1114 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1115 Internet Protocol", RFC 2401, November 1998. 1117 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1118 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1119 Authentication: Basic and Digest Access Authentication", 1120 RFC 2617, June 1999. 1122 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1123 Priority for the Session Initiation Protocol (SIP)", 1124 RFC 4412, February 2006. 1126 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1127 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1129 Authors' Addresses 1131 Charles Shen 1132 Columbia University 1133 Department of Computer Science 1134 1214 Amsterdam Avenue, MC 0401 1135 New York, NY 10027 1136 USA 1138 Phone: +1 212 854 3109 1139 Email: charles@cs.columbia.edu 1141 Henning Schulzrinne 1142 Columbia University 1143 Department of Computer Science 1144 1214 Amsterdam Avenue, MC 0401 1145 New York, NY 10027 1146 USA 1148 Phone: +1 212 939 7004 1149 Email: schulzrinne@cs.columbia.edu 1151 Arata Koike 1152 NTT Service Integration Labs & 1153 NTT Washington DC Representative Office 1154 1100 13th St., NW, Suite 900 1155 Washington DC, 20005 1156 USA 1158 Phone: +1 202 312 1451 1159 Email: koike.arata@lab.ntt.co.jp 1161 Full Copyright Statement 1163 Copyright (C) The IETF Trust (2008). 1165 This document is subject to the rights, licenses and restrictions 1166 contained in BCP 78, and except as set forth therein, the authors 1167 retain all their rights. 1169 This document and the information contained herein are provided on an 1170 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1171 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1172 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1173 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1174 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1175 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1177 Intellectual Property 1179 The IETF takes no position regarding the validity or scope of any 1180 Intellectual Property Rights or other rights that might be claimed to 1181 pertain to the implementation or use of the technology described in 1182 this document or the extent to which any license under such rights 1183 might or might not be available; nor does it represent that it has 1184 made any independent effort to identify any such rights. Information 1185 on the procedures with respect to rights in RFC documents can be 1186 found in BCP 78 and BCP 79. 1188 Copies of IPR disclosures made to the IETF Secretariat and any 1189 assurances of licenses to be made available, or the result of an 1190 attempt made to obtain a general license or permission for the use of 1191 such proprietary rights by implementers or users of this 1192 specification can be obtained from the IETF on-line IPR repository at 1193 http://www.ietf.org/ipr. 1195 The IETF invites any interested party to bring to its attention any 1196 copyrights, patents or patent applications, or other proprietary 1197 rights that may cover technology that may be required to implement 1198 this standard. Please address the information to the IETF at 1199 ietf-ipr@ietf.org.