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