idnits 2.17.00 (12 Aug 2021) /tmp/idnits24814/draft-ietf-dime-overload-reqs-13.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 30, 2013) is 3148 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. McMurry 3 Internet-Draft B. Campbell 4 Intended status: Informational Tekelec 5 Expires: April 3, 2014 September 30, 2013 7 Diameter Overload Control Requirements 8 draft-ietf-dime-overload-reqs-13 10 Abstract 12 When a Diameter server or agent becomes overloaded, it needs to be 13 able to gracefully reduce its load, typically by informing clients to 14 reduce sending traffic for some period of time. Otherwise, it must 15 continue to expend resources parsing and responding to Diameter 16 messages, possibly resulting in a progressively more severe overload 17 condition. The existing Diameter mechanisms are not sufficient for 18 this purpose. This document describes the limitations of the 19 existing mechanisms. Requirements for new overload management 20 mechanisms are also provided. 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 April 3, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Documentation Conventions . . . . . . . . . . . . . . . . 3 58 1.2. Causes of Overload . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Effects of Overload . . . . . . . . . . . . . . . . . . . 5 60 1.4. Overload vs. Network Congestion . . . . . . . . . . . . . 5 61 1.5. Diameter Applications in a Broader Network . . . . . . . . 6 62 2. Overload Control Scenarios . . . . . . . . . . . . . . . . . . 6 63 2.1. Peer to Peer Scenarios . . . . . . . . . . . . . . . . . . 7 64 2.2. Agent Scenarios . . . . . . . . . . . . . . . . . . . . . 9 65 2.3. Interconnect Scenario . . . . . . . . . . . . . . . . . . 12 66 3. Diameter Overload Case Studies . . . . . . . . . . . . . . . . 13 67 3.1. Overload in Mobile Data Networks . . . . . . . . . . . . . 13 68 3.2. 3GPP Study on Core Network Overload . . . . . . . . . . . 15 69 4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 15 70 5. Issues with the Current Mechanisms . . . . . . . . . . . . . . 16 71 5.1. Problems with Implicit Mechanism . . . . . . . . . . . . . 17 72 5.2. Problems with Explicit Mechanisms . . . . . . . . . . . . 17 73 6. Extensibility and Application Independence . . . . . . . . . . 18 74 7. Solution Requirements . . . . . . . . . . . . . . . . . . . . 19 75 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 7.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 20 77 7.3. Heterogeneous Support for Solution . . . . . . . . . . . . 21 78 7.4. Granular Control . . . . . . . . . . . . . . . . . . . . . 21 79 7.5. Priority and Policy . . . . . . . . . . . . . . . . . . . 22 80 7.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 7.7. Flexibility and Extensibility . . . . . . . . . . . . . . 23 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 9.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 24 85 9.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 25 86 9.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 25 87 9.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 25 88 9.5. Compromised Hosts . . . . . . . . . . . . . . . . . . . . 26 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 92 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 93 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 A Diameter [RFC6733] node is said to be overloaded when it has 99 insufficient resources to successfully process all of the Diameter 100 requests that it receives. When a node becomes overloaded, it needs 101 to be able to gracefully reduce its load, typically by informing 102 clients to reduce sending traffic for some period of time. 103 Otherwise, it must continue to expend resources parsing and 104 responding to Diameter messages, possibly resulting in a 105 progressively more severe overload condition. The existing 106 mechanisms provided by Diameter are not sufficient for this purpose. 107 This document describes the limitations of the existing mechanisms, 108 and provides requirements for new overload management mechanisms. 110 This document draws on the work done on SIP overload control 111 ([RFC5390], [RFC6357]) as well as on experience gained via overload 112 handling in Signaling System No. 7 (SS7) networks and studies done by 113 the Third Generation Partnership Project (3GPP) (Section 3). 115 Diameter is not typically an end-user protocol; rather it is 116 generally used as one component in support of some end-user activity. 118 For example, a SIP server might use Diameter to authenticate and 119 authorize user access. Overload in the Diameter backend 120 infrastructure will likely impact the experience observed by the end 121 user in the SIP application. 123 The impact of Diameter overload on the client application (a client 124 application may use the Diameter protocol and other protocols to do 125 its job) is beyond the scope of this document. 127 This document presents non-normative descriptions of causes of 128 overload along with related scenarios and studies. Finally, it 129 offers a set of normative requirements for an improved overload 130 indication mechanism. 132 1.1. Documentation Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as defined in [RFC2119], with the 137 exception that they are not intended for interoperability of 138 implementations. Rather, they are used to describe requirements 139 towards future specifications where the interoperability requirements 140 will be defined. 142 The terms "client", "server", "agent", "node", "peer", "upstream", 143 and "downstream" are used as defined in [RFC6733]. 145 1.2. Causes of Overload 147 Overload occurs when an element, such as a Diameter server or agent, 148 has insufficient resources to successfully process all of the traffic 149 it is receiving. Resources include all of the capabilities of the 150 element used to process a request, including CPU processing, memory, 151 I/O, and disk resources. It can also include external resources such 152 as a database or DNS server, in which case the CPU, processing, 153 memory, I/O, and disk resources of those elements are effectively 154 part of the logical element processing the request. 156 External resources can include upstream Diameter nodes; for example, 157 a Diameter agent can become effectively overloaded if one or more 158 upstream nodes are overloaded. 160 A Diameter node can become overloaded due to request levels that 161 exceed its capacity, a reduction of available resources ( for 162 example, a local or upstream hardware failure) or a combination of 163 the two. 165 Overload can occur for many reasons, including: 167 Inadequate capacity: When designing Diameter networks, that is, 168 application layer multi-node Diameter deployments, it can be very 169 difficult to predict all scenarios that may cause elevated 170 traffic. It may also be more costly to implement support for some 171 scenarios than a network operator may deem worthwhile. This 172 results in the likelihood that a Diameter network will not have 173 adequate capacity to handle all situations. 175 Dependency failures: A Diameter node can become overloaded because a 176 resource on which it depends has failed or become overloaded, 177 greatly reducing the logical capacity of the node. In these 178 cases, even minimal traffic might cause the node to go into 179 overload. Examples of such dependency overloads include DNS 180 servers, databases, disks, and network interfaces. 182 Component failures: A Diameter node can become overloaded when it is 183 a member of a cluster of servers that each share the load of 184 traffic, and one or more of the other members in the cluster fail. 185 In this case, the remaining nodes take over the work of the failed 186 nodes. Normally, capacity planning takes such failures into 187 account, and servers are typically run with enough spare capacity 188 to handle failure of another node. However, unusual failure 189 conditions can cause many nodes to fail at once. This is often 190 the case with software failures, where a bad packet or bad 191 database entry hits the same bug in a set of nodes in a cluster. 193 Network Initiated Traffic Flood: Issues with the radio access 194 network in a mobile network such as radio overlays with frequent 195 handovers, and operational changes are examples of network events 196 that can precipitate a flood of Diameter signaling traffic, such 197 as an avalanche restart. Failure of a Diameter proxy may also 198 result in a large amount of signaling as connections and sessions 199 are reestablished. 201 Subscriber Initiated Traffic Flood: Large gatherings of subscribers 202 or events that result in many subscribers interacting with the 203 network in close time proximity can result in Diameter signaling 204 traffic floods. For example, the finale of a large fireworks show 205 could be immediately followed by many subscribers posting 206 messages, pictures, and videos concentrated on one portion of a 207 network. Subscriber devices, such as smartphones, may use 208 aggressive registration strategies that generate unusually high 209 Diameter traffic loads. 211 DoS attacks: An attacker, wishing to disrupt service in the network, 212 can cause a large amount of traffic to be launched at a target 213 element. This can be done from a central source of traffic or 214 through a distributed DoS attack. In all cases, the volume of 215 traffic well exceeds the capacity of the element, sending the 216 system into overload. 218 1.3. Effects of Overload 220 Modern Diameter networks, composed of application layer multi-node 221 deployments of Diameter elements, may operate at very large 222 transaction volumes. If a Diameter node becomes overloaded, or even 223 worse, fails completely, a large number of messages may be lost very 224 quickly. Even with redundant servers, many messages can be lost in 225 the time it takes for failover to complete. While a Diameter client 226 or agent should be able to retry such requests, an overloaded peer 227 may cause a sudden large increase in the number of transaction 228 transactions needing to be retried, rapidly filling local queues or 229 otherwise contributing to local overload. Therefore Diameter devices 230 need to be able to shed load before critical failures can occur. 232 1.4. Overload vs. Network Congestion 234 This document uses the term "overload" to refer to application-layer 235 overload at Diameter nodes. This is distinct from "network 236 congestion", that is, congestion that occurs at the lower networking 237 layers that may impact the delivery of Diameter messages between 238 nodes. This document recognize that element overload and network 239 congestion are interrelated, and that overload can contribute to 240 network congestion and vice versa. 242 Network congestion issues are better handled by the transport 243 protocols. Diameter uses TCP and SCTP, both of which include 244 congestion management features. Analysis of whether those features 245 are sufficient for transport level congestion between Diameter nodes, 246 and any work to further mitigate network congestion is out of scope 247 both for this document, and for the work proposed by this document. 249 1.5. Diameter Applications in a Broader Network 251 Most elements using Diameter applications do not use Diameter 252 exclusively. It is important to realize that overload of an element 253 can be caused by a number of factors that may be unrelated to the 254 processing of Diameter or Diameter applications. 256 An element that doesn't use Diameter exclusively needs to be able to 257 signal to Diameter peers that it is experiencing overload regardless 258 of the cause of the overload, since the overload will affect that 259 element's ability to process Diameter transactions. If the element 260 communicates with protocols other than Diameter, it may also need to 261 signal the overload situation on these protocols depending on its 262 function and the architecture of the network and application it is 263 providing services for. Whether that is necessary can only be 264 decided within the context of that architecture and use cases. A 265 mechanism for signaling overload with Diameter, which this 266 specification details the requirements for, provides Diameter nodes 267 the ability to signal their Diameter peers of overload, mitigating 268 that part of the issue. Diameter nodes may need to use this, as well 269 as other mechanisms, to solve their broader overload issues. 270 Indicating overload on protocols other than Diameter is out of scope 271 for this document, and for the work proposed by this document. 273 2. Overload Control Scenarios 275 Several Diameter deployment scenarios exist that may impact overload 276 management. The following scenarios help motivate the requirements 277 for an overload management mechanism. 279 These scenarios are by no means exhaustive, and are in general 280 simplified for the sake of clarity. In particular, this document 281 assumes for the sake of clarity that the client sends Diameter 282 requests to the server, and the server sends responses to client, 283 even though Diameter supports bidirectional applications. Each 284 direction in such an application can be modeled separately. 286 In a large scale deployment, many of the nodes represented in these 287 scenarios would be deployed as clusters of servers. This document 288 assumes that such a cluster is responsible for managing its own 289 internal load balancing and overload management so that it appears as 290 a single Diameter node. That is, other Diameter nodes can treat it 291 as single, monolithic node for the purposes of overload management. 293 These scenarios do not illustrate the client application. As 294 mentioned in Section 1, Diameter is not typically an end-user 295 protocol; rather it is generally used in support of some other client 296 application. These scenarios do not consider the impact of Diameter 297 overload on the client application. 299 2.1. Peer to Peer Scenarios 301 This section describes Diameter peer-to-peer scenarios. That is, 302 scenarios where a Diameter client talks directly with a Diameter 303 server, without the use of a Diameter agent. 305 Figure 1 illustrates the simplest possible Diameter relationship. 306 The client and server share a one-to-one peer-to-peer relationship. 307 If the server becomes overloaded, either because the client exceeds 308 the server's capacity, or because the server's capacity is reduced 309 due to some resource dependency, the client needs to reduce the 310 amount of Diameter traffic it sends to the server. Since the client 311 cannot forward requests to another server, it must either queue 312 requests until the server recovers, or itself become overloaded in 313 the context of the client application and other protocols it may also 314 use. 316 +------------------+ 317 | | 318 | | 319 | Server | 320 | | 321 +--------+---------+ 322 | 323 | 324 +--------+---------+ 325 | | 326 | | 327 | Client | 328 | | 329 +------------------+ 331 Figure 1: Basic Peer to Peer Scenario 333 Figure 2 shows a similar scenario, except in this case the client has 334 multiple servers that can handle work for a specific realm and 335 application. If server 1 becomes overloaded, the client can forward 336 traffic to server 2. Assuming server 2 has sufficient reserve 337 capacity to handle the forwarded traffic, the client should be able 338 to continue serving client application protocol users. If server 1 339 is approaching overload, but can still handle some number of new 340 request, it needs to be able to instruct the client to forward a 341 subset of its traffic to server 2. 343 +------------------+ +------------------+ 344 | | | | 345 | | | | 346 | Server 1 | | Server 2 | 347 | | | | 348 +--------+-`.------+ +------.'+---------+ 349 `. .' 350 `. .' 351 `. .' 352 `. .' 353 +-------`.'--------+ 354 | | 355 | | 356 | Client | 357 | | 358 +------------------+ 360 Figure 2: Multiple Server Peer to Peer Scenario 362 Figure 3 illustrates a peer-to-peer scenario with multiple Diameter 363 realm and application combinations. In this example, server 2 can 364 handle work for both applications. Each application might have 365 different resource dependencies. For example, a server might need to 366 access one database for application A, and another for application B. 367 This creates a possibility that Server 2 could become overloaded for 368 application A but not for application B, in which case the client 369 would need to divert some part of its application A requests to 370 server 1, but should not divert any application B requests. This 371 requires server 2 to be able to distinguish between applications when 372 it indicates an overload condition to the client. 374 On the other hand, it's possible that the servers host many 375 applications. If server 2 becomes overloaded for all applications, 376 it would be undesirable for it to have to notify the client 377 separately for each application. Therefore it also needs a way to 378 indicate that it is overloaded for all possible applications. 380 +---------------------------------------------+ 381 | Application A +----------------------+----------------------+ 382 |+------------------+ | +----------------+ | +------------------+| 383 || | | | | | | || 384 || | | | | | | || 385 || Server 1 | | | Server 2 | | | Server 3 || 386 || | | | | | | || 387 |+--------+---------+ | +-------+--------+ | +-+----------------+| 388 | | | | | | | 389 +---------+-----------+----------+-----------+ | | 390 | | | | | 391 | | | | Application B | 392 | +----------+----------------+-----------------+ 393 ``-.._ | | 394 `-..__ | _.-'' 395 `--._ | _.-'' 396 ``-._ | _.-'' 397 +-----`-.-''-----+ 398 | | 399 | | 400 | Client | 401 | | 402 +----------------+ 404 Figure 3: Multiple Application Peer to Peer Scenario 406 2.2. Agent Scenarios 408 This section describes scenarios that include a Diameter agent, 409 either in the form of a Diameter relay or Diameter proxy. These 410 scenarios do not consider Diameter redirect agents, since they are 411 more readily modeled as end-servers. The examples have been kept 412 simple deliberately, to illustrate basic concepts. Significantly 413 more complicated topologies are possible with Diameter, including 414 multiple intermediate agents in a path connected in a variety of 415 ways. 417 Figure 4 illustrates a simple Diameter agent scenario with a single 418 client, agent, and server. In this case, overload can occur at the 419 server, at the agent, or both. But in most cases, client behavior is 420 the same whether overload occurs at the server or at the agent. From 421 the client's perspective, server overload and agent overload is the 422 same thing. 424 +------------------+ 425 | | 426 | | 427 | Server | 428 | | 429 +--------+---------+ 430 | 431 | 432 +--------+---------+ 433 | | 434 | | 435 | Agent | 436 | | 437 +--------+---------+ 438 | 439 | 440 +--------+---------+ 441 | | 442 | | 443 | Client | 444 | | 445 +------------------+ 447 Figure 4: Basic Agent Scenario 449 Figure 5 shows an agent scenario with multiple servers. If server 1 450 becomes overloaded, but server 2 has sufficient reserve capacity, the 451 agent may be able to transparently divert some or all Diameter 452 requests originally bound for server 1 to server 2. 454 In most cases, the client does not have detailed knowledge of the 455 Diameter topology upstream of the agent. If the agent uses dynamic 456 discovery to find eligible servers, the set of eligible servers may 457 not be enumerable from the perspective of the client. Therefore, in 458 most cases the agent needs to deal with any upstream overload issues 459 in a way that is transparent to the client. If one server notifies 460 the agent that it has become overloaded, the notification should not 461 be passed back to the client in a way that the client could 462 mistakenly perceive the agent itself as being overloaded. If the set 463 of all possible destinations upstream of the agent no longer has 464 sufficient capacity for incoming load, the agent itself becomes 465 effectively overloaded. 467 On the other hand, there are cases where the client needs to be able 468 to select a particular server from behind an agent. For example, if 469 a Diameter request is part of a multiple-round-trip authentication, 470 or is otherwise part of a Diameter "session", it may have a 471 DestinationHost AVP that requires the request to be served by server 472 1. Therefore the agent may need to inform a client that a particular 473 upstream server is overloaded or otherwise unavailable. Note that 474 there can be many ways a server can be specified, which may have 475 different implications (e.g. by IP address, by host name, etc). 477 +------------------+ +------------------+ 478 | | | | 479 | | | | 480 | Server 1 | | Server 2 | 481 | | | | 482 +--------+-`.------+ +------.'+---------+ 483 `. .' 484 `. .' 485 `. .' 486 `. .' 487 +-------`.'--------+ 488 | | 489 | | 490 | Agent | 491 | | 492 +--------+---------+ 493 | 494 | 495 | 496 +--------+---------+ 497 | | 498 | | 499 | Client | 500 | | 501 +------------------+ 503 Figure 5: Multiple Server Agent Scenario 505 Figure 6 shows a scenario where an agent routes requests to a set of 506 servers for more than one Diameter realm and application. In this 507 scenario, if server 1 becomes overloaded or unavailable while server 508 2 still has available capacity, the agent may effectively operate at 509 reduced capacity for application A, but at full capacity for 510 application B. Therefore, the agent needs to be able to report that 511 it is overloaded for one application, but not for another. 513 +--------------------------------------------+ 514 | Application A +----------------------+----------------------+ 515 |+------------------+ | +----------------+ | +------------------+| 516 || | | | | | | || 517 || | | | | | | || 518 || Server 1 | | | Server 2 | | | Server 3 || 519 || | | | | | | || 520 |+---------+--------+ | +-------+--------+ | +--+---------------+| 521 | | | | | | | 522 +----------+----------+----------+-----------+ | | 523 | | | | | 524 | | | | Application B | 525 | +----------+-----------------+----------------+ 526 | | | 527 ``--.__ | _. 528 ``-.__ | __.--'' 529 `--.._ | _..--' 530 +----``-+.''-----+ 531 | | 532 | | 533 | Agent | 534 | | 535 +-------+--------+ 536 | 537 | 538 +-------+--------+ 539 | | 540 | | 541 | Client | 542 | | 543 +----------------+ 545 Figure 6: Multiple Application Agent Scenario 547 2.3. Interconnect Scenario 549 Another scenario to consider when looking at Diameter overload is 550 that of multiple network operators using Diameter components 551 connected through an interconnect service, e.g. using IPX. IPX (IP 552 eXchange) [IR.34] is an Inter-Operator IP Backbone that provides 553 roaming interconnection network between mobile operators and service 554 providers. The IPX is also used to transport Diameter signaling 555 between operators [IR.88]. Figure 7 shows two network operators with 556 an interconnect network in-between. There could be any number of 557 these networks between any two network operator's networks. 559 +-------------------------------------------+ 560 | Interconnect | 561 | | 562 | +--------------+ +--------------+ | 563 | | Server 3 |------| Server 4 | | 564 | +--------------+ +--------------+ | 565 | .' `. | 566 +------.-'--------------------------`.------+ 567 .' `. 568 .-' `. 569 ------------.'-----+ +----`.------------- 570 +----------+ | | +----------+ 571 | Server 1 | | | | Server 2 | 572 +----------+ | | +----------+ 573 | | 574 Network Operator 1 | | Network Operator 2 575 -------------------+ +------------------- 577 Figure 7: Two Network Interconnect Scenario 579 The characteristics of the information that an operator would want to 580 share over such a connection are different from the information 581 shared between components within a network operator's network. 582 Network operators may not want to convey topology or operational 583 information, which limits how much overload and loading information 584 can be sent. For the interconnect scenario shown, Server 2 may want 585 to signal overload to Server 1, to affect traffic coming from Network 586 Operator 1. 588 This case is distinct from those internal to a network operator's 589 network, where there may be many more elements in a more complicated 590 topology. Also, the elements in the interconnect network may not 591 support Diameter overload control, and the network operators may not 592 want the interconnect network to use overload or loading information. 593 They may only want the information to pass through the interconnect 594 network without further processing or action by the interconnect 595 network even if the elements in the interconnect network do support 596 Diameter overload control. 598 3. Diameter Overload Case Studies 600 3.1. Overload in Mobile Data Networks 602 As the number of Third Generation (3G) and Long Term Evolution (LTE) 603 enabled smartphone devices continue to expand in mobile networks, 604 there have been situations where high signaling traffic load led to 605 overload events at the Diameter-based Home Location Registries (HLR) 606 and/or Home Subscriber Servers (HSS) [TR23.843]. The root causes of 607 the HLR overload events were manifold but included hardware failure 608 and procedural errors. The result was high signaling traffic load on 609 the HLR and HSS. 611 The 3GPP architecture [TS23.002] makes extensive use of Diameter. It 612 is used for mobility management [TS29.272] (and others), (IP 613 Multimedia Subsystem) IMS [TS29.228] (and others), policy and 614 charging control [TS29.212] (and others) as well as other functions. 615 The details of the architecture are out of scope for this document, 616 but it is worth noting that there are quite a few Diameter 617 applications, some with quite large amounts of Diameter signaling in 618 deployed networks. 620 The 3GPP specifications do not currently address overload for 621 Diameter applications or provide an equivalent load control mechanism 622 to those provided in the more traditional SS7 elements in (Global 623 System for Mobile Communications) GSM [TS29.002]. The capabilities 624 specified in the 3GPP standards do not adequately address the 625 abnormal condition where excessively high signaling traffic load 626 situations are experienced. 628 Smartphones, an increasingly large percentage of mobile devices, 629 contribute much more heavily, relative to non-smartphones, to the 630 continuation of a registration surge due to their very aggressive 631 registration algorithms. Smartphone behavior contributes to network 632 loading and can contribute to overload conditions. The aggressive 633 smartphone logic is designed to: 635 a. always have voice and data registration, and 637 b. constantly try to be on 3G or LTE data (and thus on 3G voice or 638 VoLTE [IR.92]) for their added benefits. 640 Non-smartphones typically have logic to wait for a time period after 641 registering successfully on voice and data. 643 The smartphone aggressive registration is problematic in two ways: 645 o first by generating excessive signaling load towards the HSS that 646 is ten times that from a non-smartphone, 648 o and second by causing continual registration attempts when a 649 network failure affects registrations through the 3G data network. 651 3.2. 3GPP Study on Core Network Overload 653 A study in 3GPP SA2 on core network overload has produced the 654 technical report [TR23.843]. This enumerates several causes of 655 overload in mobile core networks including portions that are signaled 656 using Diameter. TR23.843 is a work in progress and is not complete. 657 However, it is useful for pointing out scenarios and the general need 658 for an overload control mechanism for Diameter. 660 It is common for mobile networks to employ more than one radio 661 technology and to do so in an overlay fashion with multiple 662 technologies present in the same location (such as 2nd or 3rd 663 generation mobile technologies along with LTE). This presents 664 opportunities for traffic storms when issues occur on one overlay and 665 not another as all devices that had been on the overlay with issues 666 switch. This causes a large amount of Diameter traffic as locations 667 and policies are updated. 669 Another scenario called out by this study is a flood of registration 670 and mobility management events caused by some element in the core 671 network failing. This flood of traffic from end nodes falls under 672 the network initiated traffic flood category. There is likely to 673 also be traffic resulting directly from the component failure in this 674 case. A similar flood can occur when elements or components recover 675 as well. 677 Subscriber initiated traffic floods are also indicated in this study 678 as an overload mechanism where a large number of mobile devices 679 attempting to access services at the same time, such as in response 680 to an entertainment event or a catastrophic event. 682 While this 3GPP study is concerned with the broader effects of these 683 scenarios on wireless networks and their elements, they have 684 implications specifically for Diameter signaling. One of the goals 685 of this document is to provide guidance for a core mechanism that can 686 be used to mitigate the scenarios called out by this study. 688 4. Existing Mechanisms 690 Diameter offers both implicit and explicit mechanisms for a Diameter 691 node to learn that a peer is overloaded or unreachable. The implicit 692 mechanism is simply the lack of responses to requests. If a client 693 fails to receive a response in a certain time period, it assumes the 694 upstream peer is unavailable, or overloaded to the point of effective 695 unavailability. The watchdog mechanism [RFC3539] ensures that a 696 certain rate of transaction responses occur even when there is 697 otherwise little or no other Diameter traffic. 699 The explicit mechanism can involve specific protocol error responses, 700 where an agent or server tells a downstream peer that it is either 701 too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a 702 request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER), 703 perhaps because that destination itself is overloaded to the point of 704 unavailability. 706 Another explicit mechanism, a DPR (Disconnect-Peer-Request) message, 707 can be sent with a Disconnect-Cause of BUSY. This signals the 708 sender's intent to close the transport connection, and requests the 709 client not to reconnect. 711 Once a Diameter node learns that an upstream peer has become 712 overloaded via one of these mechanisms, it can then attempt to take 713 action to reduce the load. This usually means forwarding traffic to 714 an alternate destination, if available. If no alternate destination 715 is available, the node must either reduce the number of messages it 716 originates (in the case of a client) or inform the client to reduce 717 traffic (in the case of an agent.) 719 Diameter requires the use of a congestion-managed transport layer, 720 currently TCP or SCTP, to mitigate network congestion. It is 721 expected that these transports manage network congestion and that 722 issues with transport (e.g. congestion propagation and window 723 management) are managed at that level. But even with a congestion- 724 managed transport, a Diameter node can become overloaded at the 725 Diameter protocol or application layers due to the causes described 726 in Section 1.2 and congestion managed transports do not provide 727 facilities (and are at the wrong level) to handle server overload. 728 Transport level congestion management is also not sufficient to 729 address overload in cases of multi-hop and multi-destination 730 signaling. 732 5. Issues with the Current Mechanisms 734 The currently available Diameter mechanisms for indicating an 735 overload condition are not adequate to avoid service outages due to 736 overload. This inadequacy may, in turn, contribute to broader 737 impacts resulting from overload due to unresponsive Diameter nodes 738 causing application or transport layer retransmissions. In 739 particular, they do not allow a Diameter agent or server to shed load 740 as it approaches overload. At best, a node can only indicate that it 741 needs to entirely stop receiving requests, i.e. that it has 742 effectively failed. Even that is problematic due to the inability to 743 indicate durational validity on the transient errors available in the 744 base Diameter protocol. Diameter offers no mechanism to allow a node 745 to indicate different overload states for different categories of 746 messages, for example, if it is overloaded for one Diameter 747 application but not another. 749 5.1. Problems with Implicit Mechanism 751 The implicit mechanism doesn't allow an agent or server to inform the 752 client of a problem until it is effectively too late to do anything 753 about it. The client does not know to take action until the upstream 754 node has effectively failed. A Diameter node has no opportunity to 755 shed load early to avoid collapse in the first place. 757 Additionally, the implicit mechanism cannot distinguish between 758 overload of a Diameter node and network congestion. Diameter treats 759 the failure to receive an answer as a transport failure. 761 5.2. Problems with Explicit Mechanisms 763 The Diameter specification is ambiguous on how a client should handle 764 receipt of a DIAMETER_TOO_BUSY response. The base specification 765 [RFC6733] indicates that the sending client should attempt to send 766 the request to a different peer. It makes no suggestion that the 767 receipt of a DIAMETER_TOO_BUSY response should affect future Diameter 768 messages in any way. 770 The Authentication, Authorization, and Accounting (AAA) Transport 771 Profile [RFC3539] recommends that a AAA node that receives a "Busy" 772 response failover all remaining requests to a different agent or 773 server. But while the Diameter base specification explicitly depends 774 on RFC3539 to define transport behavior, it does not refer to RFC3539 775 in the description of behavior on receipt of DIAMETER_TOO_BUSY. 776 There's a strong likelihood that at least some implementations will 777 continue to send Diameter requests to an upstream peer even after 778 receiving a DIAMETER_TOO_BUSY error. 780 BCP 41 [RFC2914] describes, among other things, how end-to-end 781 application behavior can help avoid congestion collapse. In 782 particular, an application should avoid sending messages that will 783 never be delivered or processed. The DIAMETER_TOO_BUSY behavior as 784 described in the Diameter base specification fails at this, since if 785 an upstream node becomes overloaded, a client attempts each request, 786 and does not discover the need to failover the request until the 787 initial attempt fails. 789 The situation is improved if implementations follow the [RFC3539] 790 recommendation and keep state about upstream peer overload. But even 791 then, the Diameter specification offers no guidance on how long a 792 client should wait before retrying the overloaded destination. If an 793 agent or server supports multiple realms and/or applications, 794 DIAMETER_TOO_BUSY offers no way to indicate that it is overloaded for 795 one application but not another. A DIAMETER_TOO_BUSY error can only 796 indicate overload at a "whole server" scope. 798 Agent processing of a DIAMETER_TOO_BUSY response is also problematic 799 as described in the base specification. DIAMETER_TOO_BUSY is defined 800 as a protocol error. If an agent receives a protocol error, it may 801 either handle it locally or it may forward the response back towards 802 the downstream peer. If a downstream peer receives the 803 DIAMETER_TOO_BUSY response, it may stop sending all requests to the 804 agent for some period of time, even though the agent may still be 805 able to deliver requests to other upstream peers. 807 DIAMETER_UNABLE_TO_DELIVER, or using DPR with cause code BUSY also 808 have no mechanisms for specifying the scope or cause of the failure, 809 or the durational validity. 811 The issues with error responses in [RFC6733] extend beyond the 812 particular issues for overload control and have been addressed in an 813 ad hoc fashion by various implementations. Addressing these in a 814 standard way would be a useful exercise, but it us beyond the scope 815 of this document. 817 6. Extensibility and Application Independence 819 Given the variety of scenarios Diameter elements can be deployed in, 820 and the variety of roles they can fulfill with Diameter and other 821 technologies, a single algorithm for handling overload may not be 822 sufficient. For purposes of this discussion, algorithm is inclusive 823 of behavior for control of overload, but does not encompass the 824 general mechanism or transport of control information. This effort 825 cannot anticipate all possible future scenarios and roles. 826 Extensibility, particularly of algorithms used to deal with overload, 827 will be important to cover these cases. 829 Similarly, the scopes that overload information may apply to may 830 include cases that have not yet been considered. Extensibility in 831 this area will also be important. 833 The basic mechanism is intended to be application-independent, that 834 is, a Diameter node can use it across any existing and future 835 Diameter applications and expect reasonable results. Certain 836 Diameter applications might, however, benefit from application- 837 specific behavior over and above the mechanism's defaults. For 838 example, an application specification might specify relative 839 priorities of messages or selection of a specific overload control 840 algorithm. 842 7. Solution Requirements 844 This section proposes requirements for an improved mechanism to 845 control Diameter overload, with the goals of addressing the issues 846 described in Section 5 and supporting the scenarios described in 847 Section 2. These requirements are stated primarily in terms of 848 individual node behavior to inform the design of the improved 849 mechanism; solution designers should keep in mind that the overall 850 goal is improved overall system behavior across all the nodes 851 involved, not just improved behavior from specific individual nodes. 853 7.1. General 855 REQ 1: The solution MUST provide a communication method for Diameter 856 nodes to exchange load and overload information. 858 REQ 2: The solution MUST allow Diameter nodes to support overload 859 control regardless of which Diameter applications they 860 support. Diameter clients and agents must be able to use the 861 received load and overload information to support graceful 862 behavior during an overload condition. Graceful behavior 863 under overload conditions is best described by REQ 3. 865 REQ 3: The solution MUST limit the impact of overload on the overall 866 useful throughput of a Diameter server, even when the 867 incoming load on the network is far in excess of its 868 capacity. The overall useful throughput under load is the 869 ultimate measure of the value of a solution. 871 REQ 4: Diameter allows requests to be sent from either side of a 872 connection and either side of a connection may have need to 873 provide its overload status. The solution MUST allow each 874 side of a connection to independently inform the other of its 875 overload status. 877 REQ 5: Diameter allows nodes to determine their peers via dynamic 878 discovery or manual configuration. The solution MUST work 879 consistently without regard to how peers are determined. 881 REQ 6: The solution designers SHOULD seek to minimize the amount of 882 new configuration required in order to work. For example, it 883 is better to allow peers to advertise or negotiate support 884 for the solution, rather than to require this knowledge to be 885 configured at each node. 887 7.2. Performance 889 REQ 7: The solution and any associated default algorithm(s) MUST 890 ensure that the system remains stable. At some point after 891 an overload condition has ended, the solution MUST enable 892 capacity to stabilize and become equal to what it would be 893 in the absence of an overload condition. Note that this 894 also requires that the solution MUST allow nodes to shed 895 load without introducing non converging oscillations during 896 or after an overload condition. 898 REQ 8: Supporting nodes MUST be able to distinguish current 899 overload information from stale information. 901 REQ 9: The solution MUST function across fully loaded as well as 902 quiescent transport connections. This is partially derived 903 from the requirement for stability in REQ 7. 905 REQ 10: Consumers of overload information MUST be able to determine 906 when the overload condition improves or ends. 908 REQ 11: The solution MUST be able to operate in networks of 909 different sizes. 911 REQ 12: When a single network node fails, goes into overload, or 912 suffers from reduced processing capacity, the solution MUST 913 make it possible to limit the impact of this on other nodes 914 in the network. This helps to prevent a small-scale failure 915 from becoming a widespread outage. 917 REQ 13: The solution MUST NOT introduce substantial additional work 918 for node in an overloaded state. For example, a requirement 919 for an overloaded node to send overload information every 920 time it received a new request would introduce substantial 921 work. 923 REQ 14: Some scenarios that result in overload involve a rapid 924 increase of traffic with little time between normal levels 925 and overload inducing levels. The solution SHOULD provide 926 for rapid feedback when traffic levels increase. 928 REQ 15: The solution MUST NOT interfere with the congestion control 929 mechanisms of underlying transport protocols. For example, 930 a solution that opened additional TCP connections when the 931 network is congested would reduce the effectiveness of the 932 underlying congestion control mechanisms. 934 7.3. Heterogeneous Support for Solution 936 REQ 16: The solution is likely to be deployed incrementally. The 937 solution MUST support a mixed environment where some, but 938 not all, nodes implement it. 940 REQ 17: In a mixed environment with nodes that support the solution 941 and that do not, the solution MUST NOT result in materially 942 less useful throughput during overload as would have 943 resulted if the solution were not present. It SHOULD result 944 in less severe overload in this environment. 946 REQ 18: In a mixed environment of nodes that support the solution 947 and that do not, the solution MUST NOT preclude elements 948 that support overload control from treating elements that do 949 not support overload control in a equitable fashion relative 950 to those that do. Users and operators of nodes that do not 951 support the solution MUST NOT unfairly benefit from the 952 solution. The solution specification SHOULD provide 953 guidance to implementors for dealing with elements not 954 supporting overload control. 956 REQ 19: It MUST be possible to use the solution between nodes in 957 different realms and in different administrative domains. 959 REQ 20: Any explicit overload indication MUST be clearly 960 distinguishable from other errors reported via Diameter. 962 REQ 21: In cases where a network node fails, is so overloaded that 963 it cannot process messages, or cannot communicate due to a 964 network failure, it may not be able to provide explicit 965 indications of the nature of the failure or its levels of 966 overload. The solution MUST result in at least as much 967 useful throughput as would have resulted if the solution was 968 not in place. 970 7.4. Granular Control 972 REQ 22: The solution MUST provide a way for a node to throttle the 973 amount of traffic it receives from a peer node. This 974 throttling SHOULD be graded so that it can be applied 975 gradually as offered load increases. Overload is not a 976 binary state; there may be degrees of overload. 978 REQ 23: The solution MUST provide sufficient information to enable a 979 load balancing node to divert messages that are rejected or 980 otherwise throttled by an overloaded upstream node to other 981 upstream nodes that are the most likely to have sufficient 982 capacity to process them. 984 REQ 24: The solution MUST provide a mechanism for indicating load 985 levels even when not in an overloaded condition, to assist 986 nodes making decisions to prevent overload conditions from 987 occurring. 989 7.5. Priority and Policy 991 REQ 25: The base specification for the solution SHOULD offer general 992 guidance on which message types might be desirable to send 993 or process over others during times of overload, based on 994 application-specific considerations. For example, it may be 995 more beneficial to process messages for existing sessions 996 ahead of new sessions. Some networks may have a requirement 997 to give priority to requests associated with emergency 998 sessions. Any normative or otherwise detailed definition of 999 the relative priorities of message types during an overload 1000 condition will be the responsibility of the application 1001 specification. 1003 REQ 26: The solution MUST NOT prevent a node from prioritizing 1004 requests based on any local policy, so that certain requests 1005 are given preferential treatment, given additional 1006 retransmission, not throttled, or processed ahead of others. 1008 7.6. Security 1010 REQ 27: The solution MUST NOT provide new vulnerabilities to 1011 malicious attack, or increase the severity of any existing 1012 vulnerabilities. This includes vulnerabilities to DoS and 1013 DDoS attacks as well as replay and man-in-the middle 1014 attacks. Note that the Diameter base specification 1015 [RFC6733] lacks end to end security and this must be 1016 considered (see the Security Considerations (Section 9)). 1017 Note that this requirement was expressed at a high level so 1018 as to not preclude any particular solution. Is is expected 1019 that the solution will address this in more detail. 1021 REQ 28: The solution MUST NOT depend on being deployed in 1022 environments where all Diameter nodes are completely 1023 trusted. It SHOULD operate as effectively as possible in 1024 environments where other nodes are malicious; this includes 1025 preventing malicious nodes from obtaining more than a fair 1026 share of service. Note that this does not imply any 1027 responsibility on the solution to detect, or take 1028 countermeasures against, malicious nodes. 1030 REQ 29: It MUST be possible for a supporting node to make 1031 authorization decisions about what information will be sent 1032 to peer nodes based on the identity of those nodes. This 1033 allows a domain administrator who considers the load of 1034 their nodes to be sensitive information to restrict access 1035 to that information. Of course, in such cases, there is no 1036 expectation that the solution itself will help prevent 1037 overload from that peer node. 1039 REQ 30: The solution MUST NOT interfere with any Diameter compliant 1040 method that a node may use to protect itself from overload 1041 from non-supporting nodes, or from denial of service 1042 attacks. 1044 7.7. Flexibility and Extensibility 1046 REQ 31: There are multiple situations where a Diameter node may be 1047 overloaded for some purposes but not others. For example, 1048 this can happen to an agent or server that supports multiple 1049 applications, or when a server depends on multiple external 1050 resources, some of which may become overloaded while others 1051 are fully available. The solution MUST allow Diameter nodes 1052 to indicate overload with sufficient granularity to allow 1053 clients to take action based on the overloaded resources 1054 without unreasonably forcing available capacity to go 1055 unused. The solution MUST support specification of overload 1056 information with granularities of at least "Diameter node", 1057 "realm", and "Diameter application", and MUST allow 1058 extensibility for others to be added in the future. 1060 REQ 32: The solution MUST provide a method for extending the 1061 information communicated and the algorithms used for 1062 overload control. 1064 REQ 33: The solution MUST provide a default algorithm that is 1065 mandatory to implement. 1067 REQ 34: The solution SHOULD provide a method for exchanging overload 1068 and load information between elements that are connected by 1069 intermediaries that do not support the solution. 1071 8. IANA Considerations 1073 This document makes no requests of IANA. 1075 9. Security Considerations 1077 A Diameter overload control mechanism is primarily concerned with the 1078 load and overload related behavior of nodes in a Diameter network, 1079 and the information used to affect that behavior. Load and overload 1080 information is shared between nodes and directly affects the behavior 1081 and thus is potentially vulnerable to a number of methods of attack. 1083 Load and overload information may also be sensitive from both 1084 business and network protection viewpoints. Operators of Diameter 1085 equipment want to control visibility to load and overload information 1086 to keep it from being used for competitive intelligence or for 1087 targeting attacks. It is also important that the Diameter overload 1088 control mechanism not introduce any way in which any other 1089 information carried by Diameter is sent inappropriately. 1091 Note that the Diameter base specification [RFC6733] lacks end to end 1092 security, making verifying the authenticity and ownership of load and 1093 overload information difficult for non-adjacent nodes. 1094 Authentication of load and overload information helps to alleviate 1095 several of the security issues listed in this section. 1097 This document includes requirements intended to mitigate the effects 1098 of attacks and to protect the information used by the mechanism. 1099 This section discusses potential security considerations for overload 1100 control solutions. This discussion provides the motivation for 1101 several normative requirements described in Section 7. The 1102 discussion includes specific references to the normative requirements 1103 that apply for each issue. 1105 9.1. Access Control 1107 To control the visibility of load and overload information, sending 1108 should be subject to some form of authentication and authorization of 1109 the receiver. It is also important to the receivers that they are 1110 confident the load and overload information they receive is from a 1111 legitimate source. REQ 28 requires the solution to work without 1112 assuming that all Diameter nodes in a network are trusted for the 1113 purposes of exchanging overload and load information. REQ 29 1114 requires the solution to let nodes restrict unauthorized parties from 1115 seeing overload information. Note that this implies a certain amount 1116 of configurability on the nodes supporting the Diameter overload 1117 control mechanism. 1119 9.2. Denial-of-Service Attacks 1121 An overload control mechanism provides a very attractive target for 1122 denial-of-service attacks. A small number of messages may affect a 1123 large service disruption by falsely reporting overload conditions. 1124 Alternately, attacking servers nearing, or in, overload may also be 1125 facilitated by disrupting their overload indications, potentially 1126 preventing them from mitigating their overload condition. 1128 A design goal for the Diameter overload control mechanism is to 1129 minimize or eliminate the possibility of using the mechanism for this 1130 type of attack. More strongly, REQ 27 forbids the solution from 1131 introducing new vulnerabilities to malicious attack. Additionally, 1132 REQ 30 stipulates that the solution not interfere with other 1133 mechanisms used for protection against denial of service attacks. 1135 As the intent of some denial-of-service attacks is to induce overload 1136 conditions, an effective overload control mechanism should help to 1137 mitigate the effects of an such an attack. 1139 9.3. Replay Attacks 1141 An attacker that has managed to obtain some messages from the 1142 overload control mechanism may attempt to affect the behavior of 1143 nodes supporting the mechanism by sending those messages at 1144 potentially inopportune times. In addition to time shifting, replay 1145 attacks may send messages to other nodes as well (target shifting). 1147 A design goal for the Diameter overload control solution is to 1148 minimize or eliminate the possibility of causing disruption by using 1149 a replay attack on the Diameter overload control mechanism. 1150 (Allowing a replay attack using the overload control solution would 1151 violate REQ 27.) 1153 9.4. Man-in-the-Middle Attacks 1155 By inserting themselves in between two nodes supporting the Diameter 1156 overload control mechanism, an attacker may potentially both access 1157 and alter the information sent between those nodes. This can be used 1158 for information gathering for business intelligence and attack 1159 targeting, as well as direct attacks. 1161 REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks 1162 on the overload control solution. A transport using TLS and/or IPSEC 1163 may be desirable for this purpose. 1165 9.5. Compromised Hosts 1167 A compromised host that supports the Diameter overload control 1168 mechanism could be used for information gathering as well as for 1169 sending malicious information to any Diameter node that would 1170 normally accept information from it. While it is beyond the scope of 1171 the Diameter overload control mechanism to mitigate any operational 1172 interruption to the compromised host, REQs 28 and 29 imply a need to 1173 minimize the impact that a compromised host can have on other nodes 1174 through the use of the Diameter overload control mechanism. Of 1175 course, a compromised host could be used to cause damage in a number 1176 of other ways. This is out of scope for a Diameter overload control 1177 mechanism. 1179 10. References 1181 10.1. Normative References 1183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1184 Requirement Levels", BCP 14, RFC 2119, March 1997. 1186 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1187 "Diameter Base Protocol", RFC 6733, October 2012. 1189 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1190 RFC 2914, September 2000. 1192 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 1193 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1195 10.2. Informative References 1197 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 1198 the Session Initiation Protocol", RFC 5390, December 2008. 1200 [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 1201 Considerations for Session Initiation Protocol (SIP) 1202 Overload Control", RFC 6357, August 2011. 1204 [TR23.843] 1205 3GPP, "Study on Core Network Overload Solutions (Work in 1206 Progress)", TR 23.843 0.6.0, October 2012. 1208 [IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines", 1209 IR 34 7.0, January 2012. 1211 [IR.88] GSMA, "LTE Roaming Guidelines", IR 88 7.0, January 2012. 1213 [IR.92] GSMA, "IMS Profile for Voice and SMS", IR 92 7.0, 1214 March 2013. 1216 [TS23.002] 1217 3GPP, "Network Architecture", TS 23.002 12.0.0, 1218 September 2012. 1220 [TS29.272] 1221 3GPP, "Evolved Packet System (EPS); Mobility Management 1222 Entity (MME) and Serving GPRS Support Node (SGSN) related 1223 interfaces based on Diameter protocol", TS 29.272 11.4.0, 1224 September 2012. 1226 [TS29.212] 1227 3GPP, "Policy and Charging Control (PCC) over Gx/Sd 1228 reference point", TS 29.212 11.6.0, September 2012. 1230 [TS29.228] 1231 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 1232 Signalling flows and message contents", TS 29.228 11.5.0, 1233 September 2012. 1235 [TS29.002] 1236 3GPP, "Mobile Application Part (MAP) specification", 1237 TS 29.002 11.4.0, September 2012. 1239 Appendix A. Contributors 1241 Significant contributions to this document were made by Adam Roach 1242 and Eric Noel. 1244 Appendix B. Acknowledgements 1246 Review of, and contributions to, this specification by Martin Dolly, 1247 Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert 1248 Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent 1249 Thiebaut, Andrew Booth, and Lionel Morand were most appreciated. We 1250 would like to thank them for their time and expertise. 1252 Authors' Addresses 1254 Eric McMurry 1255 Tekelec 1256 17210 Campbell Rd. 1257 Suite 250 1258 Dallas, TX 75252 1259 US 1261 Email: emcmurry@computer.org 1263 Ben Campbell 1264 Tekelec 1265 17210 Campbell Rd. 1266 Suite 250 1267 Dallas, TX 75252 1268 US 1270 Email: ben@nostrum.com