idnits 2.17.1 draft-ietf-tsvwg-mlpp-that-works-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1847. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1510: '... request for qos MUST be successful or...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 27, 2006) is 6631 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC1633' is mentioned on line 1087, but not defined == Missing Reference: 'RFC4412' is mentioned on line 1242, but not defined == Missing Reference: 'RFC4411' is mentioned on line 1242, but not defined == Missing Reference: 'RFC3261' is mentioned on line 1744, but not defined == Missing Reference: 'RFC2475' is mentioned on line 1155, but not defined == Missing Reference: 'RFC2474' is mentioned on line 1150, but not defined == Missing Reference: 'RFC2998' is mentioned on line 1124, but not defined == Missing Reference: 'RFC3246' is mentioned on line 1162, but not defined == Missing Reference: 'RFC3247' is mentioned on line 1167, but not defined == Missing Reference: 'RFC2205' is mentioned on line 1244, but not defined == Missing Reference: 'RFC2209' is mentioned on line 1104, but not defined == Missing Reference: 'RFC3312' is mentioned on line 1367, but not defined == Missing Reference: 'RFC2208' is mentioned on line 1098, but not defined == Missing Reference: 'RFC2207' is mentioned on line 1095, but not defined == Missing Reference: 'RFC2746' is mentioned on line 1108, but not defined == Missing Reference: 'RFC2983' is mentioned on line 1159, but not defined == Missing Reference: 'RFC3175' is mentioned on line 1133, but not defined == Missing Reference: 'RFC2996' is mentioned on line 1121, but not defined == Missing Reference: 'RFC2753' is mentioned on line 1117, but not defined == Missing Reference: 'RFC2750' is mentioned on line 1114, but not defined == Missing Reference: 'RFC3181' is mentioned on line 1733, but not defined == Missing Reference: 'RFC3182' is mentioned on line 1140, but not defined == Missing Reference: 'RFC2747' is mentioned on line 1111, but not defined == Missing Reference: 'RFC3097' is mentioned on line 1129, but not defined == Missing Reference: 'RFC2327' is mentioned on line 1477, but not defined ** Obsolete undefined reference: RFC 2327 (Obsoleted by RFC 4566) == Missing Reference: 'M1' is mentioned on line 1412, but not defined == Missing Reference: 'M3' is mentioned on line 1589, but not defined == Missing Reference: 'M4' is mentioned on line 1592, but not defined == Missing Reference: 'M5' is mentioned on line 1596, but not defined == Missing Reference: 'M6' is mentioned on line 1623, but not defined == Missing Reference: 'M7' is mentioned on line 1649, but not defined == Missing Reference: 'M10' is mentioned on line 1652, but not defined Summary: 5 errors (**), 0 flaws (~~), 35 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group F. Baker 3 Internet-Draft J. Polk 4 Intended status: Experimental Cisco Systems 5 Expires: August 31, 2006 February 27, 2006 7 Implementing an Emergency Telecommunications Service for Real Time 8 Services in the Internet Protocol Suite 9 draft-ietf-tsvwg-mlpp-that-works-04 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 31, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 RFCs 3689 and 3690 detail requirements for an Emergency 43 Telecommunications Service (ETS), of which an Internet Emergency 44 Preparedness Service (IEPS) would be a part. Some of these types of 45 services require call preemption; others call for call queuing or 46 other mechanisms. IEPS requires a Call Admission Control (CAC) 47 procedure and a Per Hop Behavior for the data which meet the needs of 48 this architecture. Such a CAC procedure and PHB is appropriate to 49 any service that might use H.323 or SIP to set up real time sessions. 50 The key requirement is to guarantee an elevated probability of call 51 completion to an authorized user in time of crisis. 53 This document primarily discusses supporting ETS in the context of 54 the US Government and NATO, because it focuses on the MLPP and GETS 55 standards. The architectures described here are applicable beyond 56 these organizations. 58 Table of Contents 60 1. Overview of the Internet Emergency Preference Service 61 problem and proposed solutions . . . . . . . . . . . . . . . . 4 62 1.1. Emergency Telecommunications Services . . . . . . . . . . 4 63 1.1.1. Multi-Level Preemption and Precedence . . . . . . . . 5 64 1.1.2. Government Emergency Telecommunications Service . . . 7 65 1.2. Definition of Call Admission . . . . . . . . . . . . . . . 7 66 1.3. Assumptions about the Network . . . . . . . . . . . . . . 8 67 1.4. Assumptions about application behavior . . . . . . . . . . 8 68 1.5. Desired Characteristics in an Internet Environment . . . . 10 69 1.6. The use of bandwidth as a solution for QoS . . . . . . . . 11 71 2. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 12 72 2.1. Call admission/preemption procedure . . . . . . . . . . . 13 73 2.2. Voice handling characteristics . . . . . . . . . . . . . . 16 74 2.3. Bandwidth admission procedure . . . . . . . . . . . . . . 17 75 2.3.1. RSVP procedure: explicit call admission - RSVP 76 Admission using Policy for both unicast and 77 multicast sessions . . . . . . . . . . . . . . . . . . 18 78 2.3.2. RSVP Scaling Issues . . . . . . . . . . . . . . . . . 20 79 2.3.3. RSVP Operation in backbones and VPNs . . . . . . . . . 20 80 2.3.4. Interaction with the Differentiated Services 81 Architecture . . . . . . . . . . . . . . . . . . . . . 21 82 2.3.5. Admission policy . . . . . . . . . . . . . . . . . . . 21 83 2.4. Authentication and authorization of calls placed . . . . . 24 84 2.5. Defined User Interface . . . . . . . . . . . . . . . . . . 24 86 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 6.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 6.2. Integrated Services Architecture References . . . . . . . 28 95 6.3. Differentiated Services Architecture References . . . . . 29 96 6.4. Session Initiation Protocol and related References . . . . 30 97 6.5. Informative References . . . . . . . . . . . . . . . . . . 30 99 Appendix A. 2-Call Preemption Example using RSVP . . . . . . . . 32 101 1. Overview of the Internet Emergency Preference Service problem and 102 proposed solutions 104 [RFC3689] and [RFC3690] detail requirements for an Emergency 105 Telecommunications Service (ETS), of which an Internet Emergency 106 Preference Service (IEPS) would be a part. Some of these types of 107 services require call preemption; others call for call queuing or 108 other mechanisms. The key requirement is to guarantee an elevated 109 probability of call completion to an authorized user in time of 110 crisis. 112 IEPS requires a Call Admission Control procedure and a Per Hop 113 Behavior for the data which meet the needs of this architecture. 114 Such a CAC procedure and PHB is appropriate to any service that might 115 use H.323 or SIP to set up real time sessions. These obviously 116 include but are not limited to Voice and Video applications, although 117 at this writing the community is mostly thinking about Voice on IP 118 and many of the examples in the document are taken from that 119 environment. 121 In a network where a call permitted initially is not denied or 122 rejected at a later time, capacity admission procedures performed 123 only at the time of call setup may be sufficient. However in a 124 network where sessions status can be reviewed by the network and 125 preempted or denied due to changes in routing (when the new routes 126 lack capacity to carry calls switched to them) or changes in offered 127 load (where higher precedence calls supersede existing calls), 128 maintaining a continuing model of the status of the various calls is 129 required. 131 1.1. Emergency Telecommunications Services 133 Before doing so, however, let us discuss the problem that ETS (and 134 therefore IEPS) is intended to solve and the architecture of the 135 system. The Emergency Telecommunications Service [ITU.ETS.E106] is a 136 successor to and generalization of two services used in the United 137 States: Multilevel Preemption and Precedence (MLPP), and the 138 Government Emergency Telecommunication Service (GETS). Services 139 based on these models are also used in a variety of countries 140 throughout the world, both PSTN and GSM-based. Both of these 141 services are designed to enable an authorized user to obtain service 142 from the telephone network in times of crisis. They differ primarily 143 in the mechanisms used and number of levels of precedence 144 acknowledged. 146 1.1.1. Multi-Level Preemption and Precedence 148 The Assured Service is designed as an IP implementation of an 149 existing ITU-T/NATO/DoD telephone system architecture known as Multi- 150 Level Preemption and Precedence [ITU.MLPP.1990] [ANSI.MLPP.Spec] 151 [ANSI.MLPP.Supplement], or MLPP. MLPP is an architecture for a 152 prioritized call handling service such that in times of emergency in 153 the relevant NATO and DoD commands, the relative importance of 154 various kinds of communications is strictly defined, allowing higher 155 precedence communication at the expense of lower precedence 156 communications. This document describes NATO and U.S. Department of 157 Defense uses of MLPP, but the architecture and standard are 158 applicable outside of these organizations. 160 These precedences, in descending order, are: 162 Flash Override Override: used by the Commander in Chief, Secretary 163 of Defense, and Joint Chiefs of Staff, Commanders of combatant 164 commands when declaring the existence of a state of war. 165 Commanders of combatant commands when declaring Defense Condition 166 One or Defense Emergency or Air Defense Emergency and other 167 national authorities that the President may authorize in 168 conjunction with Worldwide Secure Voice Conferencing System 169 conferences. Flash Override Override cannot be preempted. This 170 precedence level is not enabled on all DoD networks. 172 Flash Override: used by the Commander in Chief, Secretary of 173 Defense, and Joint Chiefs of Staff, Commanders of combatant 174 commands when declaring the existence of a state of war. 175 Commanders of combatant commands when declaring Defense Condition 176 One or Defense Emergency and other national authorities the 177 President may authorize. Flash Override cannot be preempted in 178 the DSN. 180 Flash: reserved generally for telephone calls pertaining to command 181 and control of military forces essential to defense and 182 retaliation, critical intelligence essential to national survival, 183 conduct of diplomatic negotiations critical to the arresting or 184 limiting of hostilities, dissemination of critical civil alert 185 information essential to national survival, continuity of federal 186 government functions essential to national survival, fulfillment 187 of critical internal security functions essential to national 188 survival, or catastrophic events of national or international 189 significance. 191 Immediate: reserved generally for telephone calls pertaining to 192 situations that gravely affect the security of national and allied 193 forces, reconstitution of forces in a post-attack period, 194 intelligence essential to national security, conduct of diplomatic 195 negotiations to reduce or limit the threat of war, implementation 196 of federal government actions essential to national survival, 197 situations that gravely affect the internal security of the 198 nation, Civil Defense actions, disasters or events of extensive 199 seriousness having an immediate and detrimental effect on the 200 welfare of the population, or vital information having an 201 immediate effect on aircraft, spacecraft, or missile operations. 203 Priority: reserved generally for telephone calls requiring 204 expeditious action by called parties and/or furnishing essential 205 information for the conduct of government operations. 207 Routine: designation applied to those official government 208 communications that require rapid transmission by telephonic means 209 but do not require preferential handling. 211 MLPP is intended to deliver a higher probability of call completion 212 to the more important calls. The rule, in MLPP, is that more 213 important calls override less important calls when congestion occurs 214 within a network. Station based preemption is used when a more 215 important call needs to be placed to either party in an existing 216 call. Trunk based preemption is used when trunk bandwidth needs to 217 be reallocated to facilitate a higher precedence call over a given 218 path in the network. In both station and trunk based preemption 219 scenarios, preempted parties are positively notified, via preemption 220 tone, that their call can no longer be supported. The same 221 preemption tone is used, regardless of whether calls are terminated 222 for the purposes of station of trunk based preemption. The remainder 223 of this discussion focuses on trunk based preemption issues. 225 MLPP is built as a proactive system in which callers must assign one 226 of the precedence levels listed above at call initiation; this 227 precedence level cannot be changed throughout that call. If an 228 elevated status is not assigned by a user at call initiation time, 229 the call is assumed to be "routine". If there is end to end capacity 230 to place a call, any call may be placed at any time. However, when 231 any trunk group (in the circuit world) or interface (in an IP world) 232 reaches a utilization threshold, a choice must be made as to which 233 calls to accept or allow to continue. The system will seize the 234 trunk(s) or bandwidth necessary to place the more important calls in 235 preference to less important calls by preempting an existing call (or 236 calls) of lower precedence to permit a higher precedence call to be 237 placed. 239 More than one call might properly be preempted if more trunks or 240 bandwidth is necessary for this higher precedence call. A video call 241 (perhaps of 384 KBPS, or 6 trunks) competing with several lower 242 precedence voice calls is a good example of this situation. 244 1.1.2. Government Emergency Telecommunications Service 246 A US service similar to MLPP and using MLPP signaling technology, but 247 built for use in civilian networks, is the Government Emergency 248 Telecommunications Service (GETS). This differs from MLPP in two 249 ways: it does not use preemption, but rather reserves bandwidth or 250 queues calls to obtain a high probability of call completion, and it 251 has only two levels of service: "Routine" and "Priority". 253 GETS is described here as another example. Similar architectures are 254 applied by other governments and organizations. 256 1.2. Definition of Call Admission 258 Traditionally, in the PSTN, Call Admission Control (CAC) has had the 259 responsibility of implementing bandwidth available thresholds (e.g. 260 to limit resources consumed by some traffic) and determining whether 261 a caller has permission (e.g., is an identified subscriber, with 262 identify attested to by appropriate credentials) to use an available 263 circuit. IEPS, or any emergency telephone service, has additional 264 options that it may employ to improve the probability of call 265 completion: 267 o The call may be authorized to use other networks that it would not 268 normally use 270 o The network may preempt other calls to free bandwidth, 272 o The network may hold the call and place it when other calls 273 complete, or 275 o The network may use different bandwidth availability thresholds 276 than are used for other calls. 278 At the completion of CAC, however, the caller either has a circuit 279 that he or she is authorized to use, or has no circuit. Since the 280 act of preemption or consideration of alternative bandwidth sources 281 is part and parcel of the problem of providing bandwidth, the 282 authorization step in bandwidth provision also affects the choice of 283 networks that may be authorized to be considered. The three cannot 284 be separated. The CAC procedure finds available bandwidth that the 285 caller is authorized to use and preemption may in some networks be 286 part of making that happen. 288 1.3. Assumptions about the Network 290 IP networks generally fall into two categories: those with 291 constrained bandwidth, and those that are massively over-provisioned. 292 In a network wherein over any interval that can be measured 293 (including sub-second intervals) capacity exceeds offered load by at 294 least 2:1, the jitter and loss incurred in transit are nominal. This 295 is generally a characteristic of properly engineered Ethernet LANs 296 and of optical networks (networks that measure their link speeds in 297 multiples of 51 MBPS); in the latter, circuit-switched networking 298 solutions such as ATM, MPLS, and GMPLS can be used to explicitly 299 place routes, and so improve the odds a bit. 301 Between those networks, in places commonly called "inter-campus 302 links", "access links" or "access networks", for various reasons 303 including technology (e.g. satellite links) and cost, it is common to 304 find links whose offered load can approximate or exceed the available 305 capacity. Such events may be momentary, or may occur for extended 306 periods of time. 308 In addition, primarily in tactical deployments, it is common to find 309 bandwidth constraints in the local infrastructure of networks. For 310 example, the US Navy's network afloat connects approximately 300 311 ships, via satellite, to five network operation centers, and those 312 NOCs are in turn interconnected via the DISA backbone. A typical 313 ship may have between two and six radio systems aboard, often at 314 speeds of 64 KBPS or less. In US Army networks, current radio 315 technology likewise limits tactical communications to links below 100 316 KBPS. 318 Over this infrastructure, military communications expect to deploy 319 voice communication systems (30-80 KBPS per session), video 320 conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 321 KBPS), in addition to traditional mail, file transfer, and 322 transaction traffic. 324 1.4. Assumptions about application behavior 326 Parekh and Gallagher published a series of papers [Parekh1] [Parekh2] 327 analyzing what is necessary to ensure a specified service level for a 328 stream of traffic. In a nutshell, they showed that to predict the 329 behavior of a stream of traffic in a network, one must know two 330 things: 332 o the rate and arrival distribution with which traffic in a class is 333 introduced to the network, and 335 o what network elements will do, in terms of the departure 336 distribution, injected delay jitter and loss characteristics, with 337 the traffic they see. 339 For example, TCP tunes its effective window (the amount of data it 340 sends per round trip interval) so that the ratio of the window and 341 the round trip interval approximate the available capacity in the 342 network. As long as the round trip delay remains roughly stable and 343 loss is nominal (which are primarily behaviors of the network), TCP 344 is able to maintain a predictable level of throughput. In an 345 environment where loss is random or in which delays wildly vary, TCP 346 behaves in a far less predictable manner. 348 Voice and video systems, in the main, are designed to deliver a fixed 349 level of quality as perceived by the user. (Exceptions are systems 350 that select rate options over a broad range to adapt to ambient loss 351 characteristics. These deliver broadly fluctuating perceived quality 352 and have not found significant commercial applicability.) Rather, 353 they send traffic at a rate specified by the codec depending on what 354 it perceives is required. In an MPEG-4 system, for example, if the 355 camera is pointed at a wall, the codec determines that an 80 KBPS 356 data stream will describe that wall, and issues that amount of 357 traffic. If a person walks in front of the wall or the camera is 358 pointed an a moving object, the codec may easily send 800 KBPS in its 359 effort to accurately describe what it sees. In commercial broadcast 360 sports, which may line up periods in which advertisements are 361 displayed, the effect is that traffic rates suddenly jump across all 362 channels at certain times because the eye- catching ads require much 363 more bandwidth than the camera pointing at the green football field. 365 As described in [RFC1633], when dealing with a real-time application, 366 there are basically two things one must do to ensure Parekh's first 367 requirement. To ensure that one knows how much offered load the 368 application is presenting, one must police (measure load offered and 369 discard excess) traffic entering the network. If that policing 370 behavior has a debilitating effect on the application, as non- 371 negligible loss has on voice or video, one must admit sessions 372 judiciously according to some policy. A key characteristic of that 373 policy must be that the offered load does not exceed the capacity 374 dedicated to the application. 376 In the network, the other thing one must do is ensure that the 377 application's needs are met in terms of loss, variation in delay, and 378 end to end delay. One way to do this is to supply sufficient 379 bandwidth that loss and jitter are nominal. Where that cannot be 380 accomplished, one must use queuing technology to deterministically 381 apply bandwidth to accomplish the goal. 383 1.5. Desired Characteristics in an Internet Environment 385 The key elements of the Internet Emergency Preference Service include 386 the following: 388 Precedence Level Marking each call: Call initiators choose the 389 appropriate precedence level for each call based on user perceived 390 importance of the call. This level is not to be changed for the 391 duration of the call. The call before, and the call after are 392 independent with regard to this level choice. 394 Call Admission/Preemption Policy: There is likewise a clear policy 395 regarding calls that may be in progress at the called instrument. 396 During call admission (SIP/H.323), if they are of lower 397 precedence, they must make way according to a prescribed 398 procedure. All callers on the preempted call must be informed 399 that the call has been preempted, and the call must make way for 400 the higher precedence call. 402 Bandwidth Admission Policy: There is a clear bandwidth admission 403 policy: sessions may be placed which assert any of several levels 404 of precedence, and in the event that there is demand and 405 authorization is granted, other sessions will be preempted to make 406 way for a call of higher precedence. 408 Authentication and Authorization of calls placed: Unauthorized 409 attempts to place a call at an elevated status are not permitted. 410 In the telephone system, this is managed by controlling the policy 411 applied to an instrument by its switch plus a code produced by the 412 caller identifying himself or herself to the switch. In the 413 Internet, such characteristics must be explicitly signaled. 415 Voice handling characteristics: A call made, in the telephone 416 system, gets a circuit, and provides the means for the callers to 417 conduct their business without significant impact as long as their 418 call is not preempted. In a VoIP system, one would hope for 419 essentially the same service. 421 Defined User Interface: If a call is preempted, the caller and the 422 callee are notified via a defined signal, so that they know that 423 their call has been preempted and that at this instant there is no 424 alternative circuit available to them at that precedence level. 426 A VoIP implementation of the Internet Emergency Preference Service 427 must, by definition, provide those characteristics. 429 1.6. The use of bandwidth as a solution for QoS 431 There is a discussion in Internet circles concerning the relationship 432 of bandwidth to QoS procedures, which needs to be put to bed before 433 this procedure can be adequately analyzed. The issue is that it is 434 possible and common in certain parts of the Internet to solve the 435 problem with bandwidth. In LAN environments, for example, if there 436 is significant loss between any two switches or between a switch and 437 a server, the simplest and cheapest solution is to buy the next 438 faster interface - substitute 100 MBPS for 10 MBPS Ethernet, 1 439 Gigabit for 100 MBPS, or for that matter upgrade to a ten gigabit 440 Ethernet. Similarly, in optical networking environments, the 441 simplest and cheapest solution is often to increase the data rate of 442 the optical path either by selecting a faster optical carrier or 443 deploying an additional lambda. In places where the bandwidth can be 444 over-provisioned to a point where loss or queuing delay are 445 negligible, 10:1 over-provisioning is often the cheapest and surest 446 solution, and by the way offers a growth path for future 447 requirements. However, there are many places in communication 448 networks where the provision of effectively infinite bandwidth is not 449 feasible, including many access networks, satellite communications, 450 fixed wireless, airborn and marine communications, island 451 connections, and connections to regions in which fiber optic 452 connections are not cost-effective. It is in these places where the 453 question of resource management is relevant. Specifically, we do not 454 recommend the deployment of significant QoS procedures on links in 455 excess of 100 MBPS apart from the provision of aggregated services 456 that provide specific protection to the stability of the network or 457 the continuity of real-time traffic as a class, as the mathematics of 458 such circuits do not support this as a requirement. 460 In short, the fact that we are discussing this class of policy 461 control says that such constrictions in the network exist and must be 462 dealt with. However much we might like to, in those places we are 463 not solving the problem with bandwidth. 465 2. Solution Proposal 467 A typical voice or video network, including a backbone domain, is 468 shown in Figure 1. 470 ............... ...................... 471 . . . . 472 . H H H H . . H H H H . 473 . /----------/ . . /----------/ . 474 . R SIP . . R R . 475 . \ . . / \ . 476 . R H H H . ....... / \ . 477 . /----------/ .. ../ R SIP . 478 . R .. /. /----------/ . 479 ..... ..\. R-----R . H H H H . 480 ...... .\ / \ . . 481 . \ / \ . . 482 . R-----------R .................... 483 . \ / . 484 . \ / . 485 . R-----R . 486 . . 487 ............ 488 SIP = SIP Proxy 489 H = SIP-enabled Host (Telephone, call gateway or PC) 490 R = Router 491 /---/ = Ethernet or Ethernet Switch 493 Figure 1: Typical VoIP or Video/IP Network 495 Reviewing that figure, it becomes obvious that Voice/IP and Video/IP 496 call flows are very different than call flows in the PSTN. In the 497 PSTN, call control traverses a switch, which in turn controls data 498 handling services like ATM or TDM switches or multiplexers. While 499 they may not be physically co-located, the control plane software and 500 the data plane services are closely connected; the switch routes a 501 call using bandwidth that it knows is available. In a voice/ 502 video-on-IP network, call control is completely divorced from the 503 data plane: It is possible for a telephone instrument in the United 504 States to have a Swedish telephone number if that is where its SIP 505 proxy happens to be, but on any given call to use only data paths in 506 the Asia/Pacific region, data paths provided by a different company, 507 and often data paths provided by multiple companies/providers. 509 Call management therefore addresses a variety of questions, all of 510 which must be answered: 512 o May I make this call from an administrative policy perspective? 514 o What IP address correlates with this telephone number or SIP URI? 516 o Is the other instrument "on hook"? If it is busy, under what 517 circumstances may I interrupt? 519 o Is there bandwidth available to support the call? 521 o Does the call actually work, or do other impairments (loss, delay) 522 make the call unusable? 524 2.1. Call admission/preemption procedure 526 Administrative Call Admission is the objective of SIP and H.323. It 527 asks fundamental questions like "what IP address is the callee at?" 528 and "Did you pay your bill?". 530 For specialized policy like call preemption, two capabilities are 531 necessary from an administrative perspective: [RFC4412] provides a 532 way to communicate policy-related information regarding the 533 precedence of the call; and [RFC4411] provides a reason code when a 534 call fails or is refused, indicating the cause of the event. If it 535 is a failure, it may make sense to redial the call. If it is a 536 policy-driven preemption, even if the call is redialed it may not be 537 possible to place the call. Requirements for this service are 538 further discussed in [RFC3689]. 540 The Communications Resource Priority Header (or RP Header) serves the 541 call set-up process with the precedence level chosen by the initiator 542 of the call. The syntax is in the form: 544 Resource Priority : namespace.priority level 546 The "namespace" part of the syntax ensures the domain of significance 547 to the originator of the call, and this travels end-to-end to the 548 destination (called) device (telephone). If the receiving phone does 549 not support the namespace, it can easily ignore the set-up request. 550 This ability to denote the domain of origin allows SLAs to be in 551 place to limit the ability of an unknown requester to gain 552 preferential treatment into an IEPS domain. 554 For the DSN infrastructure, this header would look like this: 556 Resource Priority : dsn.routine 558 for a routine precedence level call. The precedence level chosen in 559 this header would be compared to the requester's authorization 560 profile to use that precedence level. This would typically occur in 561 the SIP first hop Proxy, which can challenge many aspects of the call 562 set-up request including the requester choice of precedence levels 563 (verifying they are not using a level they are not authorized to 564 use.) 566 The DSN has 5 precedence levels of IEPS in descending order: 568 dsn.flash-override 570 dsn.flash 572 dsn.immediate 574 dsn.priority 576 dsn.routine 578 The US Defense Red Switched Network (DRSN), as another example that 579 is to be IANA registered in [RFC4412], has 6 levels of precedence. 580 The DRSN simply adds one higher precedence level than flash-override: 582 drsn.flash-override-override 584 to be used by the President and a select few others. Note that the 585 namespace changed for this level. The lower 5 levels within the DRSN 586 would also have this as their namespace for all DRSN originated call 587 set-up requests. 589 The Resource-Priority Header (RPH) informs both the use of DSCPs by 590 the callee (who needs to use the same DSCP as the caller to obtain 591 the same data path service) and to facilitate policy-based preemption 592 of calls in progress when appropriate. 594 Once a call is established in an IEPS domain, the Reason Header for 595 Preemption, described in [RFC4411], ensures that all SIP nodes are 596 synchronized to a preemption event occurring either at the endpoint 597 or in a router that experiences congestion. In SIP, the normal 598 indication for the end of a session is for one end system to send a 599 BYE Method request as specified in [RFC3261]. This, too, is the 600 proper means for signaling a termination of a call due to a 601 preemption event, as it essentially performs a normal termination 602 with additional information informing the peer of the reason for the 603 abrupt end - it indicates that a preemption occurred. This will be 604 used to inform all relevant SIP entities, and whether this was a 605 endpoint generated preemption event, or that the preemption event 606 occurred within a router along the communications path (described in 607 Section 2.3.1 ). 609 Figure 2 is a simple example of a SIP call set-up that includes the 610 layer 7 precedence of a call between Alice and Bob. After Alice 611 successfully sets up a call to Bob at the "Routine" precedence level, 612 Carol calls Bob at a higher precedence level (Immediate). At the SIP 613 layer (this has nothing to do with RSVP yet, that example involving 614 SIP and RSVP signaling will be in the appendix), once Bob's user 615 agent (phone) receives the INVITE message from Carol, his UA needs to 616 make a choice between retaining the call to Alice and sending Carol a 617 "busy" indication, or preempting the call to Alice in favor of 618 accepting the call from Carol. That choice in IEPS networks is a 619 comparison of Resource Priority headers. Alice, who controlled the 620 precedence level of the call to Bob, sent the precedence level of her 621 call to him at "Routine" (the lowest level within the network). 622 Carol, who controls the priority of the call signal to Bob, sent her 623 priority level to "Immediate" (higher than "Routine"). Bob's UA 624 needs to (under IEPS policy) preempt the call from Alice (and provide 625 her with a preemption indication in the call termination message). 626 Bob needs to successfully answer the call set-up from Carol. 628 UA Alice UA Bob UA Carol 629 | INVITE (RP: Routine) | | 630 |--------------------------->| | 631 | 200 OK | | 632 |<---------------------------| | 633 | ACK | | 634 |--------------------------->| | 635 | RTP | | 636 |<==========================>| | 637 | | | 638 | | INVITE (RP: Immediate) | 639 | |<----------------------------| 640 | ************************************************ | 641 | *Resource Priority value comparison by Bob's UA* | 642 | ************************************************ | 643 | | | 644 | BYE (Reason: UA preemption) | 645 |<---------------------------| | 646 | | 200 OK | 647 | |---------------------------->| 648 | 200 OK (BYE) | | 649 |--------------------------->| | 650 | | ACK | 651 | |<----------------------------| 652 | | RTP | 653 | |<===========================>| 654 | | | 656 Figure 2: Priority Call Establishment and Termination at SIP Layer 658 Nothing in this example involved mechanisms other than SIP. It is 659 also assumed each user agent recognized the Resource-Priority header 660 namespace value in each message. Therefore, it is assumed that the 661 domain allowed Alice, Bob and Carol to communicate. Authentication 662 and Authorization are discussed later in this document. 664 2.2. Voice handling characteristics 666 The Quality of Service architecture used in the data path is that of 667 [RFC2475]. Differentiated Services uses a flag in the IP header 668 called the DSCP [RFC2474] to identify a data stream, and then applies 669 a procedure called a Per Hop Behavior, or PHB, to it. This is 670 largely as described in the [RFC2998]. 672 In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] 673 describes the fundamental needs of voice and video traffic. This PHB 674 entails ensuring that sufficient bandwidth is dedicated to real-time 675 traffic to ensure minimal variation in delay and a minimal loss rate, 676 as codecs are hampered by excessive loss [G711.1][G711.2][G711.3]. 677 In parts of the network where bandwidth is heavily over-provisioned, 678 there may be no remaining concern. In places in the network where 679 bandwidth is more constrained, this may require the use of a priority 680 queue. If a priority queue is used, the potential for abuse exists, 681 meaning that it is also necessary to police traffic placed into the 682 queue to detect and manage abuse. A fundamental question is "where 683 does this policing need to take place?". The obvious places would be 684 the first hop routers and any place where converging data streams 685 might congest a link. 687 Some proposals mark traffic with various code points appropriate to 688 the service precedence of the call. In normal service, if the 689 traffic is all in the same queue and EF service requirements are met 690 (applied capacity exceeds offered load, variation in delay is 691 minimal, and loss is negligible), details of traffic marking should 692 be irrelevant, as long as packets get into the right service class. 693 The major issues, then are primarily appropriate policing of traffic, 694 especially around route changes, and ensuring that the path has 695 sufficient capacity. 697 The real time voice/video application should be generating traffic at 698 a rate appropriate to its content and codec, which is either a 699 constant bit rate stream or a stream whose rate is variable within a 700 specified range. The first hop router should be policing traffic 701 originated by the application, as is performed in traditional virtual 702 circuit networks like Frame Relay and ATM. Between these two checks 703 (at what some networks call the DTE and DCE), the application traffic 704 should be guaranteed to be within acceptable limits. As such, given 705 bandwidth-aware call admission control, there should be minimal 706 actual loss. The cases where loss would occur include cases where 707 routing has recently changed and CAC has not caught up, or cases 708 where statistical thresholds are in use in CAC and the data streams 709 happen to coincide at their peak rates. 711 If it is demonstrated that routing transients and variable rate beat 712 frequencies present a sufficient problem, it is possible to provide a 713 policing mechanism that isolates intentional loss among an ordered 714 set of classes. While the ability to do so, by various algorithms, 715 has been demonstrated, the technical requirement has not. If 716 dropping random packets from all calls is not appropriate, 717 concentrating random loss in a subset of the calls makes the problem 718 for those calls worse; a superior approach would reject or preempt an 719 entire call. 721 Parekh's second condition has been met: we must know what the network 722 will do with the traffic. If the offered load exceeds the available 723 bandwidth, the network will remark and drop the excess traffic. The 724 key questions become "How does one limit offered load to a rate less 725 than or equal to available bandwidth?" and "how much traffic does one 726 admit with each appropriate marking?" 728 2.3. Bandwidth admission procedure 730 Since the available voice and video codecs require a nominal loss 731 rate to deliver acceptable performance, Parekh's first requirement is 732 that offered load be within the available capacity. There are 733 several possible approaches. 735 An approach that is commonly used in H.323 networks is to limit the 736 number of calls simultaneously accepted by the gatekeeper. SIP 737 networks do something similar when they place a stateful SIP proxy 738 near a single ingress/egress to the network. This is able to impose 739 an upper bound on the total number of calls in the network or the 740 total number of calls crossing the significant link. However, the 741 gatekeeper has no knowledge of routing, so the engineering must be 742 very conservative, and usually presumes a single ingress/egress or 743 the failure of one of its data paths. While this may serve as a 744 short term work-around, it is not a general solution that is readily 745 deployed. This limits the options in network design. 747 [RFC1633] provides for signaled admission for the use of capacity. 748 The recommended approach is explicit capacity admission, supporting 749 the concepts of preemption. An example of such a procedure uses the 750 Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of 751 Capacity Admission using RSVP with SIP is described in [RFC3312]. 752 While call counting is specified in H.323, network capacity admission 753 is not integrated with H.323 at this time. 755 2.3.1. RSVP procedure: explicit call admission - RSVP Admission using 756 Policy for both unicast and multicast sessions 758 RSVP is a resource reservation setup protocol providing the one-way 759 (at a time) setup of resource reservations for multicast and unicast 760 flows. Each reservation is set up in one direction (meaning one 761 reservation from each end system; in a multicast environment, N 762 senders set up N reservations). These reservations complete a 763 communication path with a deterministic bandwidth allocation through 764 each router along that path between end systems. These reservations 765 setup a known quality of service for end-to-end communications and 766 maintain a "soft-state" within a node. The meaning of the term "soft 767 state" is that in the event of a network outage or change of routing, 768 these reservations are cleared without manual intervention, but must 769 be periodically refreshed. In RSVP, the refresh period is by default 770 30 seconds, but may be as long as appropriate. 772 RSVP is a locally-oriented process, not a globally- or domain- 773 oriented one like a routing protocol or like H.323 Call Counting. 774 Although it uses the local routing databases to determine the routing 775 path, it is only concerned with the quality of service for a 776 particular or aggregate flow through a device. RSVP is not aware of 777 anything other than the local goal of QoS and its RSVP-enabled 778 adjacencies, operating below the network layer. The process by 779 itself neither requires nor has any end-to-end network knowledge or 780 state. Thus, RSVP can be effective when it is enabled at some nodes 781 in a network without the need to have every node participate. 783 HOST ROUTER 784 _____________________________ ____________________________ 785 | _______ | | | 786 | | | _______ | | _______ | 787 | |Appli- | | | |RSVP | | | | 788 | | cation| | RSVP <---------------------------> RSVP <----------> 789 | | <--> | | | _______ | | | 790 | | | |process| _____ | ||Routing| |process| _____ | 791 | |_._____| | -->Policy| || <--> -->Policy|| 792 | | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl|| 793 | |data | | |_____|| ||__.____| | | |_____|| 794 |===|===========|==|==========| |===|==========|==|==========| 795 | | --------| | _____ | | | --------| | _____ | 796 | | | | ---->Admis|| | | | | ---->Admis|| 797 | _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl|| 798 | | | | | |_____|| | | | | ||_____|| 799 | |Class-| | Packet | | | |Class-| | Packet | | 800 | | ifier|==>Schedulr|================> ifier|==>Schedulr|=========> 801 | |______| |________| |data | |______| |________| data 802 | | | | 803 |_____________________________| |____________________________| 805 Figure 3: RSVP in Hosts and Routers 807 Figure 3 shows the internal process of RSVP in both hosts (end 808 systems) and routers, as shown in [RFC2209]. 810 RSVP uses the phrase "traffic control" to describe the mechanisms of 811 how a data flow receives quality of service. There are 3 different 812 mechanisms to traffic control (shown in Figure 2 in both hosts and 813 routers). They are: 815 A packet classifier mechanism: which resolves the QoS class for each 816 packet; this can determine the route as well. 818 An admission control mechanism: this consists of two decision 819 modules: the admission control module and the policy control 820 module. Determining whether there is satisfactory resources for 821 the requested QoS is the function of admission control. 822 Determining if the user has the authorization to request such 823 resources is the function of policy control. If the parameters 824 carried within this flow fail either of these two modules, RSVP 825 errors the request. 827 A packet scheduler mechanism: at each outbound interface, the 828 scheduler attains the guaranteed QoS for that flow 830 2.3.2. RSVP Scaling Issues 832 As originally written, there was concern that RSVP had scaling 833 limitations due to its data plane behavior[RFC2208]. This has either 834 not proven to be the case or has in time largely been corrected. 835 Telephony services generally require peak call admission rates on the 836 order of thousands of calls per minute and peak call levels 837 comparable to the capacities of the lines in question, which is 838 generally on the order of thousands to tens of thousands of calls. 839 Current RSVP implementations admit calls at the rate of hundreds of 840 calls per second and maintain as many calls in progress as memory 841 configurations allow. 843 In edge networks, RSVP is used to signal for individual microflows, 844 admitting the bandwidth. However, Differentiated Services is used 845 for the data plane behavior. Admission and policing may be performed 846 anywhere, but need only be performed in the first hop router (which, 847 if the end system sending the traffic is a DTE, constitutes a DCE for 848 the remaining network) and in routers that have interfaces threatened 849 by congestion. In Figure 1, these would normally be the links that 850 cross network boundaries. 852 2.3.3. RSVP Operation in backbones and VPNs 854 In backbone networks, networks that are normally awash in bandwidth, 855 RSVP and its affected data flows may be carried in a variety of ways. 856 If the backbone is a maze of tunnels between its edges - true of MPLS 857 networks and of networks that carry traffic from an encryptor to a 858 decryptor, and also of VPNs - applicable technologies include 859 [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is simplistically 860 a IP packet enveloped inside another IP packet as a payload. When 861 IPv6 is transported over an IPv4 network, encapsulating the entire v6 862 packet inside a v4 packet is an effective means to accomplish this 863 task. In this type of tunnel, the IPv6 packet is not read by any of 864 the routers while inside the IPv4 envelope. If the inner packet is 865 RSVP enabled, there must be a active configuration to ensure that all 866 relevant backbone nodes read the RSVP fields; [RFC2746] describes 867 this. 869 This is similar to how IPsec tunnels work. Encapsulating an RSVP 870 packet inside an encrypted packet for security purposes without 871 copying or conveying the RSVP indicators in the outside IP packet 872 header would make RSVP inoperable while in this form of a tunnel. 873 [RFC2207] describes how to modify an IPsec packet header to allow for 874 RSVP awareness by nodes that need to provide QoS for the flow or 875 flows inside a tunnel. 877 Other networks may simply choose to aggregate the reservations across 878 themselves as described in [RFC3175]. The problem with an individual 879 reservation architecture is that each flow requires a non-trivial 880 amount of message exchange, computation, and memory resources in each 881 router between each endpoint. Aggregation of flows reduces the 882 number of completely individual reservations into groups of 883 individual flows that can act as one for part or all of the journey 884 between end systems. Aggregates are not intended to be from the 885 first router to the last router within a flow, but to cover common 886 paths of a large number of individual flows. 888 Examples of aggregated data flows include streams of IP data that 889 traverse common ingress and egress points in a network, and also 890 include tunnels of various kinds. MPLS LSPs, IPSEC Security 891 Associations between VPN edge routers, IP/IP tunnels, and GRE tunnels 892 all fall into this general category. The distinguishing factor is 893 that the system injecting an aggregate into the aggregated network 894 sums the PATH and RESV statistical information on the un- aggregated 895 side and produces a reservation for the tunnel on the aggregated 896 side. If the bandwidth for the tunnel cannot be expanded, RSVP 897 leaves the existing reservation in place and returns an error to the 898 aggregator, which can then apply a policy such as IEPS to determine 899 which session to refuse. In the data plane, the DSCP for the traffic 900 must be copied from the inner to the outer header, to preserve the 901 PHB's effect. 903 One concern with this approach is that this leaks information into 904 the aggregated zone concerning the number of active calls or the 905 bandwidth they consume. In fact, it does not, as the data itself is 906 identifiable by aggregator address, deaggregator address, and DSCP. 907 As such, even if it is not advertised, such information is 908 measurable. 910 2.3.4. Interaction with the Differentiated Services Architecture 912 In the PATH message, the DCLASS object described in [RFC2996] is used 913 to carry the determined DSCP for the precedence level of that call in 914 the stream. This is reflected back in the RESV message. The DSCP 915 will be determined from the authorized SIP message exchange between 916 end systems by using the R-P header. The DCLASS object permits both 917 bandwidth admission within a class and the building up of the various 918 rates or token buckets. 920 2.3.5. Admission policy 922 RSVP's basic admission policy, as defined, is to grant any user 923 bandwidth if there is bandwidth available within the current 924 configuration. In other words, if a new request arrives and the 925 difference between the configured upper bound and the currently 926 reserved bandwidth is sufficiently large, RSVP grants use of that 927 bandwidth. This basic policy may be augmented in various ways, such 928 as using a local or remote policy engine to apply AAA procedures and 929 further qualify the reservation. 931 2.3.5.1. Admission for variable rate codecs 933 For certain applications, such as broadcast video using MPEG-1 or 934 voice without activity detection and using a constant bit rate codec 935 such as G.711, this basic policy is adequate apart from AAA. For 936 variable rate codecs, such as MPEG-4 or a voice codec with Voice 937 Activity Detection, however, this may be deemed too conservative. In 938 such cases, two basic types of statistical policy have been studied 939 and reported on in the literature: simple over-provisioning, and 940 approximation to ambient load. 942 Simple over-provisioning sets the bandwidth admission limit higher 943 than the desired load, on the assumption that a session that admits a 944 certain bandwidth will in fact use a fraction of the bandwidth. For 945 example, if MPEG-4 data streams are known to use data rates between 946 80 and 800 KBPS and there is no obvious reason that sessions would 947 synchronize (such as having commercial breaks on 15 minute 948 boundaries), one could imagine estimating that the average session 949 consumes 400 KBPS and treating an admission of 800 KBPS as actually 950 consuming half the amount. 952 One can also approximate to average load, which is perhaps a more 953 reliable procedure. In this case, one maintains a variable which 954 measures actual traffic through the admitted data's queue, 955 approximating it using an exponentially weighted moving average. 956 When a new reservation request arrives, if the requested rate is less 957 than the difference between the configured upper bound and the 958 current value of the moving average, the reservation is accepted and 959 the moving average is immediately increased by the amount of the 960 reservation to ensure that the bandwidth is not promised out to 961 several users simultaneously. In time, the moving average will decay 962 from this guard position to an estimate of true load, which may offer 963 a chance to another session to be reserved that would otherwise have 964 been refused. 966 Statistical reservation schemes such as these are overwhelmingly 967 dependent on the correctness of their configuration and its 968 appropriateness for the codecs in use. But they offer the 969 opportunity to take advantage of statistical multiplexing gains that 970 might otherwise be missed. 972 2.3.5.2. Interaction with complex admission policies, AAA, and 973 preemption of bandwidth 975 Policy is carried and applied as described in [RFC2753]. Figure 4 976 below is the basic conceptual model for policy decisions and 977 enforcement in an Integrated Services model. This model was created 978 to provide ability to monitor and control reservation flows based on 979 user identify, specific traffic and security requirements and 980 conditions which might change for various reasons, including as a 981 reaction to a disaster or emergency event involving the network or 982 its users. 984 Network Node Policy server 985 ______________ 986 | ______ | 987 | | | | _____ 988 | | PEP | | | |-------------> 989 | |______|<---|------>| PDP |May use LDAP,SNMP,COPS... for accessing 990 | ^ | | | policy database, authentication, etc. 991 | | | |_____|-------------> 992 | __v___ | 993 | | | | PDP = Policy Decision Point 994 | | LPDP | | PEP = Policy Enforcement Point 995 | |______| | LPDP = Local Policy Decision Point 996 |______________| 998 Figure 4: Conceptual Model for Policy Control of Routers 1000 The Network Node represents a router in the network. The Policy 1001 Server represents the point of admission and policy control by the 1002 network operator. Policy Enforcement Point (PEP)(the router) is 1003 where the policy action is carried out. Policy decisions can be 1004 either locally present in the form of a Local Policy Decision Point 1005 (LPDP), or in a separate server on the network called the Policy 1006 Decision Point. The easier the instruction set of rules, the more 1007 likely this set can reside in the LDPD for speed of access reasons. 1008 The more complex the rule set, the more likely this is active on a 1009 remote server. The PDP will use other protocols (LDAP, SNMP, etc) to 1010 request information (e.g. user authentication and authorization for 1011 precedence level usage) to be used in creating the rule sets of 1012 network components. This remote PDP should also be considered where 1013 non-reactive policies are distributed out to the LPDPs. 1015 Taking the above model as a framework, [RFC2750] extends RSVP's 1016 concept of a simple reservation to include policy controls, including 1017 the concepts of Preemption [RFC3181] and Identity [RFC3182], 1018 specifically speaking to the usage of policies which preempt calls 1019 under the control of either a local or remote policy manager. The 1020 policy manager assigns a precedence level to the admitted data flow. 1021 If it admits a data flow that exceeds the available capacity of a 1022 system, the expectation is that the RSVP affected RSVP process will 1023 tear down a session among the lowest precedence sessions it has 1024 admitted. The RESV Error resulting from that will go to the receiver 1025 of the data flow, and be reported to the application (SIP or H.323). 1026 That application is responsible to disconnect its call, with a reason 1027 code of "bandwidth preemption". 1029 2.4. Authentication and authorization of calls placed 1031 It will be necessary, of course, to ensure that any policy is applied 1032 to an authenticated user; it is the capabilities assigned to an 1033 authenticated user that may be considered to have been authorized for 1034 use in the network. For bandwidth admission, this will require the 1035 utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures 1036 will also be needed. 1038 2.5. Defined User Interface 1040 The user interface - the chimes and tones heard by the user - should 1041 ideally remain the same as in the PSTN for those indications that are 1042 still applicable to an IP network. There should be some new effort 1043 generated to update the list of announcements sent to the user which 1044 don't necessarily apply. All indications to the user, of course, 1045 depend on positive signals, not unreliable measures based on changing 1046 measurements. 1048 3. IANA Considerations 1050 This document makes no request of IANA. 1052 Note to RFC Editor: this section may be removed on publication as an 1053 RFC. 1055 4. Security Considerations 1057 This document outlines a networking capability composed entirely of 1058 existing specifications. It has significant security issues, in the 1059 sense that a failure of the various authentication or authorization 1060 procedures can cause a fundamental breakdown in communications. 1061 However, the issues are internal to the various component protocols, 1062 and are covered by their various security procedures. 1064 5. Acknowledgements 1066 This document was developed with the knowledge and input of many 1067 people, far too numerous to be mentioned by name. Key contributors 1068 of thoughts include, however, Francois Le Faucheur, Haluk Keskiner, 1069 Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan, and Tony 1070 De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce provided 1071 useful reviews. 1073 6. References 1075 6.1. Normative References 1077 [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for 1078 Emergency Telecommunication Service (ETS)", RFC 3689, 1079 February 2004. 1081 [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 1082 for Emergency Telecommunication Service (ETS)", RFC 3690, 1083 February 2004. 1085 6.2. Integrated Services Architecture References 1087 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1088 Services in the Internet Architecture: an Overview", 1089 RFC 1633, June 1994. 1091 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1092 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1093 Functional Specification", RFC 2205, September 1997. 1095 [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC 1096 Data Flows", RFC 2207, September 1997. 1098 [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, 1099 M., Romanow, A., Weinrib, A., and L. Zhang, "Resource 1100 ReSerVation Protocol (RSVP) Version 1 Applicability 1101 Statement Some Guidelines on Deployment", RFC 2208, 1102 September 1997. 1104 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1105 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1106 September 1997. 1108 [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 1109 "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 1111 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1112 Authentication", RFC 2747, January 2000. 1114 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 1115 RFC 2750, January 2000. 1117 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 1118 for Policy-based Admission Control", RFC 2753, 1119 January 2000. 1121 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 1122 November 2000. 1124 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 1125 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 1126 Felstaine, "A Framework for Integrated Services Operation 1127 over Diffserv Networks", RFC 2998, November 2000. 1129 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1130 Authentication -- Updated Message Type Value", RFC 3097, 1131 April 2001. 1133 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1134 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1135 RFC 3175, September 2001. 1137 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 1138 RFC 3181, October 2001. 1140 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 1141 Herzog, S., and R. Hess, "Identity Representation for 1142 RSVP", RFC 3182, October 2001. 1144 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1145 "Integration of Resource Management and Session Initiation 1146 Protocol (SIP)", RFC 3312, October 2002. 1148 6.3. Differentiated Services Architecture References 1150 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1151 "Definition of the Differentiated Services Field (DS 1152 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1153 December 1998. 1155 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1156 and W. Weiss, "An Architecture for Differentiated 1157 Services", RFC 2475, December 1998. 1159 [RFC2983] Black, D., "Differentiated Services and Tunnels", 1160 RFC 2983, October 2000. 1162 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1163 J., Courtney, W., Davari, S., Firoiu, V., and D. 1164 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1165 Behavior)", RFC 3246, March 2002. 1167 [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., 1168 Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. 1170 Ramakrishnan, "Supplemental Information for the New 1171 Definition of the EF PHB (Expedited Forwarding Per-Hop 1172 Behavior)", RFC 3247, March 2002. 1174 6.4. Session Initiation Protocol and related References 1176 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1177 Protocol", RFC 2327, April 1998. 1179 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1180 A., Peterson, J., Sparks, R., Handley, M., and E. 1181 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1182 June 2002. 1184 [RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) 1185 Reason Header for Preemption Events", RFC 4411, 1186 February 2006. 1188 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1189 Priority for the Session Initiation Protocol (SIP)", 1190 RFC 4412, February 2006. 1192 6.5. Informative References 1194 [ANSI.MLPP.Spec] American National Standards Institute, 1195 "Telecommunications - Integrated Services 1196 Digital Network (ISDN) - Multi-Level 1197 Precedence and Preemption (MLPP) Service 1198 Capability", ANSI T1.619-1992 (R1999), 1992. 1200 [ANSI.MLPP.Supplement] American National Standards Institute, "MLPP 1201 Service Domain Cause Value Changes", 1202 ANSI ANSI T1.619a-1994 (R1999), 1990. 1204 [G711.1] Viola Networks, "Netally VoIP Evaluator", 1205 January 2003, . 1209 [G711.2] IEPSI Tiphon, "IEPSI Tiphon Temporary 1210 Document 64", July 1999, . 1214 [G711.3] Nortel Networks, "Packet Loss and Packet Loss 1215 Concealment", 2000, . 1219 [ITU.ETS.E106] International Telecommunications Union, 1220 "International Emergency Preference Scheme 1221 for disaster relief operations (IEPS)", ITU- 1222 T Recommendation E.106, October 2003. 1224 [ITU.MLPP.1990] International Telecommunications Union, 1225 "Multilevel Precedence and Preemption Service 1226 (MLPP)", ITU-T Recommendation I.255.3, 1990. 1228 [Parekh1] Parekh, A. and R. Gallager, "A Generalized 1229 Processor Sharing Approach to Flow Control in 1230 Integrated Services Networks: The Multiple 1231 Node Case", INFOCOM 1993: 521-530, 1993. 1233 [Parekh2] Parekh, A. and R. Gallager, "A Generalized 1234 Processor Sharing Approach to Flow Control in 1235 Integrated Services Networks: The Single Node 1236 Case", INFOCOM 1992: 915-924, 1992. 1238 Appendix A. 2-Call Preemption Example using RSVP 1240 This appendix will present a more complete view of the interaction 1241 between SIP, SDP and RSVP. The bulk of the material is referenced 1242 from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be 1243 some discussion on basic RSVP operations regarding reservation paths, 1244 this will be mostly from [RFC2205]. 1246 SIP signaling occurs at the Application Layer, riding on a UDP/IP or 1247 TCP/IP (including TLS/TCP/IP) transport that is bound by routing 1248 protocols such as BGP and OSPF to determine the route the packets 1249 traverse through a network between source and destination devices. 1250 RSVP is riding on top of IP as well, which means RSVP is at the mercy 1251 of the IP routing protocols to determine a path through the network 1252 between endpoints. RSVP is not a routing protocol. In this appendix 1253 there will be a escalation of building blocks getting to how the many 1254 layers are involved in SIP with QoS Preconditions requiring 1255 successful RSVP signaling between endpoints prior to SIP successfully 1256 acknowledging the set-up of the session (for voice or video or both). 1257 Then we will present what occurs when a network overload occurs 1258 (congestion), causing a SIP session to be preempted. 1260 There are three diagrams in this appendix to show multiple views of 1261 the same example of connectivity for discussion throughout this 1262 appendix. The first diagram (Figure 5) is of many routers between 1263 many endpoints (SIP user agents, or UAs). There are 4 UAs of 1264 interest, those are for users Alice, Bob, Carol and Dave. When a 1265 user (the human) of a UA gets involved and must do something to a UA 1266 to progress a SIP process, this will be explicitly mentioned to avoid 1267 confusion; otherwise, when Alice is referred to - this means Alice's 1268 UA (her phone) in the text here. 1270 RSVP reserves bandwidth in one direction only (the direction of the 1271 RESV message), as has been discussed, IP forwarding of packets are 1272 dictated by the routing protocol for that portion of the 1273 infrastructure from the point of view of where the packet is to go 1274 next. 1276 The RESV message traverses the routers in the reverse path taken by 1277 the PATH message. The PATH message establishes a record of the route 1278 taken through a network portion to the destination endpoint, but it 1279 does not reserve resources (bandwidth). The RESV message back to the 1280 original requester of the RSVP flow requests for the bandwidth 1281 resources. This means the endpoint that initiates the RESV message 1282 controls the parameters of the reservation. This document specifies 1283 in the body text that the SIP initiator (the UAC) establishes the 1284 parameters of the session in an INVITE message, and that the INVITE 1285 recipient (the UAS) must follow the parameters established in that 1286 INVITE message. One exception to this is which codec to use if the 1287 UAC offered more than one to the UAS. This exception will be shown 1288 when the INVITE message is discussed in detail later in the appendix. 1289 If there was only one codec in the SDP of the INVITE message, the 1290 parameters of the reservation will follow what the UAC requested 1291 (specifically to include the Resource-Priority header namespace and 1292 priority value). 1294 Here is the first figure with the 4 UAs and a meshed routed 1295 infrastructure between each. For simplicity of this explanation, 1296 this appendix will only discuss the reservations from Alice to Bob 1297 (one direction) and from Carol to Dave (one direction). An 1298 interactive voice service will require two one-way reservations that 1299 end in each UA. This gives the appearance of a two-way reservation, 1300 when indeed it is not. 1302 Alice -----R1----R2----R3----R4------ Bob 1303 | \ / \ / \ / | 1304 | \/ \/ \/ | 1305 | /\ /\ /\ | 1306 | / \ / \ / \ | 1307 Carol -----R5----R6----R7----R8------ Dave 1309 Figure 5: Complex Routing and Reservation Topology 1311 The PATH message from Alice to Bob (establishing the route for the 1312 RESV message) will be through routers: 1314 Alice -> R1 -> R2 -> R3 -> R4 -> Bob 1316 The RESV message (and therefore the reservation of resources) from 1317 Bob to Alice will be through routers: 1319 Bob -> R4 -> R3 -> R2 -> R1 -> Alice 1321 The PATH message from Carol to Dave (establishing the route for the 1322 RESV message) will be through routers: 1324 Carol -> R5 -> R2 -> R3 -> R8 -> Dave 1326 The RESV message (and therefore the reservation of resources) from 1327 Dave to Carol will be through routers: 1329 Dave -> R8 -> R3 -> R2 -> R5 -> Carol 1331 The reservations from Alice to Bob traverse a common router link: 1332 between R3 and R2 and thus a common interface at R2. Here is where 1333 there will be congestion in this example, on the link between R2 and 1334 R3. Since the flow of data (in this case voice media packets) 1335 travels the direction of the PATH message, and RSVP establishes 1336 reservation of resources at the egress interface of a router, the 1337 interface in Figure 6 shows Int7 to be what will first know about a 1338 congestion condition. 1340 Alice Bob 1341 \ / 1342 \ / 1343 +--------+ +--------+ 1344 | | | | 1345 | R2 | | R3 | 1346 | Int7-------Int5 | 1347 | | | | 1348 +--------+ +--------+ 1349 / \ 1350 / \ 1351 Carol Dave 1353 Figure 6: Reduced Reservation Topology 1355 From Figure 6, the messaging between the UAs and the RSVP messages 1356 between the relevant routers can be shown to understand the binding 1357 that was established in [RFC3312] "SIP Preconditions for QoS". 1359 We will assume all devices have powered up, and received whatever 1360 registration or remote policy downloads were necessary for proper 1361 operation. The routing protocol of choice has performed its routing 1362 table update throughout this part of the network. Now we are left to 1363 focus only on end-to-end communications and how that affects the 1364 infrastructure between endpoints. 1366 The next diagram (Figure 7 ) (nearly identical to Figure 1 from 1367 [RFC3312])shows the minimum SIP messaging (at layer 7) between Alice 1368 and Bob for a good quality voice call. The SIP messages are numbered 1369 to identify special qualities are each. During the SIP signaling, 1370 RSVP will be initiated. That messaging will also be discussed below. 1372 UA Alice UA Bob 1373 | | 1374 | | 1375 |-------------(1) INVITE SDP1--------------->| 1376 | | Note 1 1377 |<------(2) 183 Session Progress SDP2--------| | 1378 ***|********************************************|***<-+ 1379 * |----------------(3) PRACK------------------>| * 1380 * | | * Where 1381 * |<-----------(4) 200 OK (PRACK)--------------| * RSVP 1382 * | | * is 1383 * | | * signaled 1384 ***|********************************************|*** 1385 |-------------(5) UPDATE SDP3--------------->| 1386 | | 1387 |<--------(6) 200 OK (UPDATE) SDP4-----------| 1388 | | 1389 |<-------------(7) 180 Ringing---------------| 1390 | | 1391 |-----------------(8) PRACK----------------->| 1392 | | 1393 |<------------(9) 200 OK (PRACK)-------------| 1394 | | 1395 | | 1396 |<-----------(10) 200 OK (INVITE)------------| 1397 | | 1398 |------------------(11) ACK----------------->| 1399 | | 1400 | RTP (within the reservation) | 1401 |<==========================================>| 1402 | | 1404 Figure 7: SIP Reservation Establishment Using Preconditions 1406 The session initiation starts with Alice wanting to communicate with 1407 Bob. Alice decides on an IEPS precedence level for their call (the 1408 default is the "routine" level, which is for normal everyday calls, 1409 but a priority level has to be chosen for each call). Alice puts 1410 into her UA Bob's address and precedence level and (effectively) hits 1411 the send button. This is reflected in SIP with an INVITE Method 1412 Request message [M1]. Below is what SIP folks call a well-formed SIP 1413 message (meaning it has all the headers that are mandatory to 1414 function properly). We will pick on the USMC for the addressing of 1415 this message exchange. 1417 [M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory] 1418 INVITE sip:bob@usmc.example.mil SIP/2.0 1419 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 1420 ;branch=z9hG4bK74bf9 1421 Max-Forwards: 70 1422 From: Alice ;tag=9fxced76sl 1423 To: Bob 1424 Call-ID: 3848276298220188511@pc33.usmc.example.mil 1425 CSeq: 31862 INVITE 1426 Requires: 100rel, preconditions, resource-priority 1427 Resource-Priority: dsn.routine 1428 Contact: 1429 Content-Type: application/sdp 1430 Content-Length: 191 1431 v=0 1432 o=alice 2890844526 2890844526 IN IP4 usmc.example.mil 1433 c=IN IP4 10.1.3.33 1434 t=0 0 1435 m=audio 49172 RTP/AVP 0 4 8 1436 a=rtpmap:0 PCMU/8000 1437 a=curr:qos e2e none 1438 a=des:qos mandatory e2e sendrecv 1440 From the INVITE above, Alice is inviting Bob to a session. The upper 1441 half of the lines (above the line 'v=0') are SIP headers and header 1442 values, the lower half of the lines above are Session Description 1443 Protocol (SDP) lines. SIP headers (after the first line, called the 1444 Status line) are not mandated in any particular order, with one 1445 exception: the Via header. It is a SIP hop (through a SIP Proxy) 1446 route path that has a new Via header line added by each SIP element 1447 this message traverses towards the destination UA. This is similar 1448 in function to an RSVP PATH message (building a reverse path back to 1449 the originator of the message). At any point in the message's path, 1450 a SIP element knows the path to the originator of the message. There 1451 will be no SIP Proxies in this example, because for Preconditions, 1452 Proxies only make more messages that look identical (with the 1453 exception of the Via and Max-Forwards headers), and that is not worth 1454 the space here to replicate what has been done in SIP RFCs already. 1456 SIP headers that are used for Preconditions are the: 1458 Requires header - which mandates a reliable provisional response 1459 message to the conditions requesting in this INVITE (knowing they 1460 are special), mandates that preconditions are attempted, and 1461 mandates support for the Resource-Priority header. Each of these 1462 option-tags can be explicitly identified in a message failure 1463 indication from the called UA to tell the calling UA what was not 1464 supported. 1466 Provided this INVITE message is received as acceptable, this will 1467 result in the 183 "Session Progress" message from Bob's UA as a 1468 reliable confirmation that preconditions are required for this call. 1470 - Resource-Priority header - which denotes the domain namespace 1471 and precedence level of the call on an end-to-end basis. 1473 This completes SIPs functions in session initiation. Preconditions 1474 are requested, required and signaled for in the SDP portion of the 1475 message. SDP is carried in what's called a SIP message body (much 1476 like the text in an email message is carried). SDP has special 1477 properties [see [RFC2327] for more on SDP, or the MMUSIC WG for 1478 ongoing efforts regarding SDP]. SDP lines are in a specific order 1479 for parsing reasons by end systems. Dialog (Call) generating SDP 1480 message bodies all must have an "m" line (or media description line). 1481 Following the "m" line is zero or more "a" lines (or Attribute 1482 lines). The m-line in Alice's INVITE calls for a voice session (this 1483 is where video is identified also) using one of 3 different codecs 1484 that Alice supports (0 = G.711, 4 = G.723 and 18 = G.729) that Bob 1485 gets to choose from for this session. Bob can choose any of the 3. 1486 The first a=rtpmap line is specific to the type of codec these 3 are 1487 (PCMU). The next two a-lines are the only identifiers that RSVP is 1488 to be used for this call. The second a-line: 1490 a=curr:qos e2e none 1492 identifies the "current" status of qos at Alice's UA. Note: 1493 everything in SDP is with respect to the sender of the SDP message 1494 body (Alice will never tell Bob how his SDP is, she will only tell 1495 Bob about her SDP). 1497 "e2e" means that capacity assurance is required from Alice's UA to 1498 Bob's UA; meaning a lack of available capacity assurance in either 1499 direction will fail the call attempt. 1501 "none" means there is no reservation at Alice's UA (to Bob) at 1502 this time. 1504 The final a-line (a=des): 1506 a=des:qos mandatory e2e sendrecv 1508 identifies the "desired" level of qos 1510 "mandatory" means this request for qos MUST be successful or the 1511 call fails. 1513 "e2e" means RSVP is required from Alice's UA to Bob's UA 1515 "sendrecv" means the reservation is in both directions. 1517 As discussed, RSVP does not reserve bandwidth in both directions, and 1518 that it is up to the endpoints to have 2 one-way reservations if that 1519 particular application (here voice) requires it. Voice between Alice 1520 and Bob requires 2 one-way reservations. The UAs will be the focal 1521 points for both reservations in both directions. 1523 Message 2 is the 183 "Session Progress" message sent by Bob to Alice 1524 that indicates to Alice that Bob understands that preconditions are 1525 required for this call. 1527 [M2 - 183 "Session Progress"] 1528 SIP/2.0 183 Session Progress 1529 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 1530 ;branch=z9hG4bK74bf9 ;received=10.1.3.33 1531 From: Alice ;tag=9fxced76sl 1532 To: Bob ;tag=8321234356 1533 Call-ID: 3848276298220188511@pc33.usmc.example.mil 1534 CSeq: 31862 INVITE 1535 RSeq: 813520 1536 Resource-Priority: dsn.routine 1537 Contact: 1538 Content-Type: application/sdp 1539 Content-Length: 210 1540 v=0 1541 o=bob 2890844527 2890844527 IN IP4 usmc.example.mil 1542 c=IN IP4 10.100.50.51 1543 t=0 0 1544 m=audio 3456 RTP/AVP 0 1545 a=rtpmap:0 PCMU/8000 1546 a=curr:qos e2e none 1547 a=des:qos mandatory e2e sendrecv 1548 a=conf:qos e2e recv 1550 Figure 9 1552 The only interesting header in the SIP portion of this message is the 1553 RSeq header, which is the "Reliable Sequence" header. The value is 1554 incremented for every Reliable message that's sent in this call 1555 set-up (to make sure none are lost, or to ignore duplicates). 1557 Bob's SDP indicates several a-line statuses and picks a codec for the 1558 call. The codec picked is in the m=audio line (the "0" at the end of 1559 this line means G.711 will be the codec). 1561 The a=curr line gives Alice Bob's status with regard to RSVP 1562 (currently "none"). 1564 The a=des line also states the desire for mandatory qos e2e in both 1565 directions. 1567 The a=conf line is new. This line means Bob wants confirmation that 1568 Alice has 2 one-way reservations before Bob's UA proceeds with the 1569 SIP session set-up. 1571 This is where "Note-1" applies in Figure 7. At the point that Bob's 1572 UA transmits this 183 message, Bob's UA (the one that picked the 1573 codec, so it knows the amount of bandwidth to reserve) transmits an 1574 RSVP PATH message to Alice's UA. This PATH message will take the 1575 route previously discussed in Figure 5: 1577 Bob -> R4 -> R3 -> R2 -> R1 -> Alice 1579 This is the path of the PATH message, and the reverse will be the 1580 path of the reservation set up RESV message, or: 1582 Alice -> R1 -> R2 -> R3 -> R4 -> Bob 1584 Immediately after Alice transmits the RESV message towards Bob, Alice 1585 sends her own PATH message to initiate the other one-way reservation. 1586 Bob, receiving that PATH message, will reply with a RESV. 1588 All this is independent of SIP. But during this time of reservation 1589 establishment, a Provisional Acknowledgment (PRACK) [M3] is sent from 1590 Alice to Bob to confirm the request for confirmation of 2 one-way 1591 reservations at Alice's UA. This message is acknowledged with a 1592 normal 200 OK message [M4]. This is shown in Figure 7. 1594 As soon as the RSVP is successfully completed at Alice's UA (knowing 1595 it was the last in the two way cycle or reservation establishment), 1596 at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform 1597 his UA that current status of RSVP (or qos) is "e2e" and "sendrecv". 1599 [M5 - UPDATE to Bob that Alice has qos e2e and sendrecv] 1600 UPDATE sip:bob@usmc.example.mil SIP/2.0 1601 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 1602 ;branch=z9hG4bK74bfa 1603 From: Alice ;tag=9fxced76sl 1604 To: Bob 1605 Resource-Priority: dsn.routine 1606 Contact: 1607 CSeq: 10197 UPDATE 1608 Content-Type: application/sdp 1609 Content-Length: 191 1610 v=0 1611 o=alice 2890844528 2890844528 IN IP4 usmc.example.mil 1612 c=IN IP4 10.1.3.33 1613 t=0 0 1614 m=audio 49172 RTP/AVP 0 1615 a=rtpmap:0 PCMU/8000 1616 a=curr:qos e2e send 1617 a=des:qos mandatory e2e sendrecv 1619 Figure 10 1621 This is shown by the matching table that can be build from the a=curr 1622 line and a=des line. If the two lines match, then no further 1623 signaling need take place with regard to "qos". [M6] is the 200 OK 1624 acknowledgment of this synchronization between the two UAs. 1626 [M6 - 200 OK to the UPDATE from Bob indicating synchronization] 1627 SIP/2.0 200 OK sip:bob@usmc.example.mil 1628 Via: SIP/2.0/TCP pc33.usmc.example.mil:5060 1629 ;branch=z9hG4bK74bfa 1630 From: Alice ;tag=9fxced76sl 1631 To: Bob 1632 Resource-Priority: dsn.routine 1633 Contact: < sip:alice@usmc.example.mil > 1634 CSeq: 10197 UPDATE 1635 Content-Type: application/sdp 1636 Content-Length: 195 1637 v=0 1638 o=alice 2890844529 2890844529 IN IP4 usmc.example.mil 1639 c=IN IP4 10.1.3.33 1640 t=0 0 1641 m=audio 49172 RTP/AVP 0 1642 a=rtpmap:0 PCMU/8000 1643 a=curr:qos e2e sendrecv 1644 a=des:qos mandatory e2e sendrecv 1646 Figure 11 1648 At this point, the reservation is operational and both UA's know it, 1649 and Bob's UA now rings ([M7] is the SIP indication to Alice this is 1650 taking place) telling Bob the user that Alice is calling her. 1651 Nothing up until now has involved Bob the user. Bob picks up the 1652 phone (generating [M10], from which Alice's UA responds with the 1653 final ACK) and RTP is now operating within the reservations between 1654 the two UAs. 1656 Now we get to Carol calling Dave. Figure 6 shows a common router 1657 interface for the reservation between Alice to Bob, and one that will 1658 also be the route for one of the reservations between Carol to Dave. 1659 This interface will experience congestion in our example here. 1661 Carol is now calling Dave at a Resource-Priority level of "Immediate" 1662 - which is higher in priority than Alice to Bob's "routine". In this 1663 continuing example, Router 2's Interface-7 is congested and cannot 1664 accept any more RSVP traffic. Perhaps the offered load is at 1665 interface capacity. Perhaps Interface-7 is configured with a fixed 1666 amount of bandwidth it can allocate for RSVP traffic and has reached 1667 its maximum without one of the reservations going away through normal 1668 termination or forced termination (preemption). 1670 Interface-7 is not so full of offered load that it cannot transmit 1671 signaling packets, such as Carol's SIP messaging to set up a call to 1672 Dave. This should be by design - that not all RSVP traffic can 1673 starve an interface from signaling packets. Carol sends her own 1674 INVITE with the following characteristics important here: 1676 [M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory] 1678 This packet does *not* affect the reservations between Alice and Bob 1679 (SIP and RSVP are at different layers, and all routers are passing 1680 signaling packets without problems). Dave sends his M2: 1682 [M2 - 183 "Session Progress"] 1684 with the SDP chart of: 1686 a=curr:qos e2e none 1688 a=des:qos mandatory e2e sendrecv 1690 a=conf:qos e2e recv 1692 indicating he understands RSVP reservations are required e2e for this 1693 call to be considered successful. Dave sends his PATH message. The 1694 PATH message does *not* affect Alice's reservation, it merely 1695 establishes a path for the RESV reservation set-up message to take. 1697 To keep this example simple, the PATH message from Dave to Carol took 1698 this route (which we make different from the route in the reverse 1699 direction): 1701 Dave -> R8 -> R7 -> R6 -> R5 -> Carol 1703 causing the reservation to be this route: 1705 Carol -> R5 -> R6 -> R7 -> R8 -> Dave 1707 The reservation above in this direction (Dave to will not traverse 1708 any of the same routers as the Alice to Bob reservations. When Carol 1709 transmits her RESV message towards Dave, she immediately transmits 1710 her PATH message to set up the complementary reservation. 1712 The PATH message from Carol to Dave be through routers: 1714 Carol -> R5 -> R2 -> R3 -> R8 -> Dave 1716 Thus, the RESV message will be through routers: 1718 Dave -> R8 -> R3 -> R2 -> R5 -> Carol 1720 This RESV message will traverse the same routers R3 and R2 as the 1721 Alice to Bob reservation. This RESV message, when received at Int-7 1722 of R2, will create a congestion situation such that R2 will need to 1723 make a decision on whether: 1725 o to keep the Alice to Bob reservation and error the new RESV from 1726 Dave, or 1728 o to error the reservation from Alice to Bob in order to make room 1729 for the Carol to Dave reservation 1731 Alice's reservation was set up in SIP at the "routine" precedence 1732 level. This will equate to a comparable RSVP priority number (RSVP 1733 has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV 1734 equates to a precedence value of "immediate", which is a higher 1735 priority. Thus, R2 will preempt the reservation from Alice to Bob, 1736 and allow the reservation request from Dave to Carol. The proper 1737 RSVP error is the ResvErr that indicates preemption. This message 1738 travels downstream towards the originator of the RESV message (Bob). 1739 This clears the reservation in all routers downstream of R2 (meaning 1740 R3 and R4). Once Bob receives the ResvErr message indicating 1741 preemption has occurred on this reservation, Bob's UA transmits a SIP 1742 preemption indication back towards Alice's UA. This accomplishes two 1743 things: first it informs all SIP Servers that were in the session 1744 set-up path that wanted to remain "dialog stateful" per [RFC3261], 1745 and informs Alice's UA that this was a purposeful termination, and to 1746 play a preemption tone. The proper indication in SIP of this 1747 termination due to preemption is a BYE Method message that includes a 1748 Reason Header indicating why this occurred (in this case, "Reserved 1749 Resources Preempted". Here is that message from Bob to Alice that 1750 terminates the call in SIP. 1752 BYE sip:alice@usmc.example.mil SIP/2.0 1753 Via: SIP/2.0/TCP swp34.usmc.example.mil 1754 ;branch=z9hG4bK776asegma 1755 To: Alice 1756 From: Bob ;tag=192820774 1757 Reason: preemption ;cause=2 ;text=reserved resourced preempted 1758 Call-ID: a84b4c76e66710@swp34.usmc.example.mil 1759 CSeq: 6187 BYE 1760 Contact: 1762 When Alice's UA receives this message, her UA terminates the call, 1763 sends a 200 OK to Bob to confirm reception of the BYE message, and 1764 plays a preemption tone to Alice the user. 1766 The RESV message from Dave successfully traverses R2 and Carol's UA 1767 receives it. Just as with the Alice to Bob call set-up, Carol sends 1768 an UPDATE message to Dave confirming she has QoS "e2e" in "sendrecv" 1769 directions. Bob acknowledges this with a 200 OK that gives his 1770 current status (QoS "e2e" and "sendrecv"), and the call set-up in SIP 1771 continues to completion. 1773 In summary, Alice set up a call to Bob with RSVP at a priority level 1774 of Routine. When Carol called Dave at a high priority, their call 1775 will preempt any lower priority calls where these is a contention for 1776 resources. In this case, it occurred and affected the call between 1777 Alice and Bob. A router at this congestion point preempted Alice's 1778 call to Bob in order to place the higher priority call between Carol 1779 and Dave. Alice and Bob were both informed of the preemption event. 1780 Both Alice and Bob's UAs played preemption indications. What was not 1781 mentioned in this appendix was that this document RECOMMENDS router 1782 R2 (in this example) generating a syslog message to the domain 1783 administrator to properly manage and track such events within this 1784 domain. This will ensure the domain administrators have recorded 1785 knowledge of where such events occur, and what the conditions were 1786 that caused them. 1788 Authors' Addresses 1790 Fred Baker 1791 Cisco Systems 1792 1121 Via Del Rey 1793 Santa Barbara, California 93117 1794 USA 1796 Phone: +1-408-526-4257 1797 Fax: +1-413-473-2403 1798 EMail: fred@cisco.com 1800 James Polk 1801 Cisco Systems 1802 2200 East President George Bush Turnpike 1803 Richardson, Texas 75082 1804 USA 1806 Phone: +1-817-271-3552 1807 EMail: jmpolk@cisco.com 1809 Full Copyright Statement 1811 Copyright (C) The Internet Society (2006). 1813 This document is subject to the rights, licenses and restrictions 1814 contained in BCP 78, and except as set forth therein, the authors 1815 retain all their rights. 1817 This document and the information contained herein are provided on an 1818 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1819 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1820 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1821 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1822 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1823 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1825 Intellectual Property 1827 The IETF takes no position regarding the validity or scope of any 1828 Intellectual Property Rights or other rights that might be claimed to 1829 pertain to the implementation or use of the technology described in 1830 this document or the extent to which any license under such rights 1831 might or might not be available; nor does it represent that it has 1832 made any independent effort to identify any such rights. Information 1833 on the procedures with respect to rights in RFC documents can be 1834 found in BCP 78 and BCP 79. 1836 Copies of IPR disclosures made to the IETF Secretariat and any 1837 assurances of licenses to be made available, or the result of an 1838 attempt made to obtain a general license or permission for the use of 1839 such proprietary rights by implementers or users of this 1840 specification can be obtained from the IETF on-line IPR repository at 1841 http://www.ietf.org/ipr. 1843 The IETF invites any interested party to bring to its attention any 1844 copyrights, patents or patent applications, or other proprietary 1845 rights that may cover technology that may be required to implement 1846 this standard. Please address the information to the IETF at 1847 ietf-ipr@ietf.org. 1849 Acknowledgements 1851 Funding for the RFC Editor function is provided by the IETF 1852 Administrative Support Activity (IASA). This document was produced 1853 using xml2rfc v1.31pre5 (of http://xml.resource.org/) from a source 1854 in RFC-2629 XML format.