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