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