idnits 2.17.1 draft-ietf-sipping-reason-header-for-preemption-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 819. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 787), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 754, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force James M. Polk 2 Internet Draft Cisco Systems 3 Expiration: February 27th, 2005 4 File: draft-ietf-sipping-reason-header-for-preemption-02.txt 6 Extending the Session Initiation Protocol 7 Reason Header for Preemption Events 9 August 27th, 2004 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document proposes an IANA Registration extension to the Session 41 Initiation Protocol (SIP) Reason Header to include in a BYE Method 42 Request as a result of a session preemption event, either at a user 43 agent (UA), or somewhere in the network using RSVP. This document 44 does not attempt to address routers failing in the packet path; but 45 a deliberate event of tearing down a flow between UAs, and informing 46 the terminated UA(s) with an indication of what occurred. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Access Preemption Events . . . . . . . . . . . . . . . . . . 3 53 2.1 Effects of Preemption at the User Agent . . . . . . . . 5 54 2.2 Reason Header Requirements for 55 Access Preemption Events . . . . . . . . . . . . . . . 5 56 3. Network Preemption Events . . . . . . . . . . . . . . . . . 6 57 3.1 Reason Header Requirements for 58 Network Preemption Events . . . . . . . . . . . . . . . 8 59 4. Including a Hybrid Infrastructure . . . . . . . . . . . . . 9 60 4.1 Hybrid Infrastructure Requirements . . . . . . . . . . 9 61 5. Preemption Reason Header Cause Codes and Semantics . . . . . 10 62 5.1 Access Preemption Event Reason Code . . . . . . . . . . 10 63 5.1.1 Access Preemption Event Call Flow . . . . . . . . . . 11 64 5.2 Network Preemption Events Reason Code . . . . . . . . . 12 65 5.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12 66 5.3 Generic Preemption Event Reason Code . . . . . . . . . . 13 67 5.4 Non-IP Preemption Event Reason Code . . . . . . . . . . 14 68 5.4.1 Non-IP Preemption Event Call Flow . . . . . . . . . . 14 69 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 71 8. Contributions . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 74 11. Author Information . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 With the introduction of the Resource-Priority (R-P) header [4], 79 there became the possibility of sessions being torn down for 80 (scarce) resource reasons; meaning there weren't enough resources 81 for a particular session to continue. Certain domains will 82 implement this mechanism where resources may become constrained 83 either at the user agent (UA), or for congested router interfaces 84 where more important sessions are to be completed at the expense of 85 less important sessions. Which sessions are more or less important 86 than others will not be discussed here. What is proposed here is 87 extending SIP to synchronize SIP elements as to why a preemption 88 event occurred and which type of preemption event occurred, as 89 viewed by the element that performed the preemption of a session. 91 The Reason Header is an application layer feedback mechanism to 92 synchronize SIP elements of events; the particular event explained 93 here deals with preemption of a session. Q.850 [5] provides an 94 indication for preemption (cause=8) and for preemption "circuit 95 reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP 96 because IP has no concept of circuits. Some domains wish to 97 differentiate appropriate IP reasons for preemption of sessions and 98 topologically where the preemption event occurred. No other means 99 exists today to give this feedback as to why a session was torn down 100 for preemption grounds. 102 In the event that a session is terminated for a specific reason that 103 can (or should) be shared with SIP Servers and UAs sharing dialog, 104 the Reason Header [1] was created to be included in the BYE Request 105 This was not the only Method for this new Header; [1] also discusses 106 the CANCEL Method usage. 108 This document will define two use-cases in which new preemption 109 Reason values are necessary: 111 Access Preemption Event - this is when a UA receives a new SIP 112 session request message with a valid R-P value that is 113 higher than the one associated with the currently active 114 session at that UA. The UA must discontinue the existing 115 session in order to accept the new one (based on local 116 policy of some domains). 118 Network Preemption Event - this is when a network element - such 119 as a router - reaches capacity on a particular interface 120 and has the ability to statefully choose which session(s) 121 will remain active when a new session/reservation is 122 signaled for under the parameters of RSVP in [3] that 123 would otherwise overload that interface (perhaps adversely 124 affecting all sessions). In this case, the router must 125 terminate one or more reservations of lower priority in 126 order to allow this higher priority reservation access to 127 the requested amount of bandwidth (based on local policy 128 of some domains). 130 This document will cover the semantics for these two cases, and 131 request IANA registration of the new protocol value "Preemption" for 132 the Reason Header field with 4 cause values for the above preemption 133 conditions. 135 1.1 Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 138 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described 140 in [6]. 142 2. Access Preemption Events 144 As mentioned previously, Access Preemption Events (APE) occur at 145 the user agent. It does not matter which UA in a unicast or 146 multicast session this happens to (the UAC or UAS of a session). If 147 local policy dictates in a particular domain, rules regarding the 148 functionality of a UA, there must be a means by which that UA (not 149 the user) informs the other UA(s) why a session was just torn down 150 prematurely. The appropriate mechanism is to utilize the BYE 151 Method. The user of the other far side UA will not understand why 152 that session "just went away" without there being a means of 153 informing the UA what occurred (if this event was purposeful). 154 Through this type of indication to the preempted UA, it can indicate 155 to the user of that device appropriately. 157 The rules within a domain surrounding informing of UA can be 158 different than the rules of informing the user. Local policy should 159 determine if the user should be informed of the specific reason. 160 This indication in SIP will provide a means for the UA to react in a 161 locally determined way if appropriate (play a certain tone or tone 162 sequence, point towards a special announcement uri, causes the UA's 163 visual display to do something, etc). 165 The following diagram (Figure 1) illustrates the scenario here. UA1 166 invites UA2 to a session with the Resource Priority level of 3 167 (levels 1 and 2 are higher is this domain, and the namespace element 168 is not necessary for this discussion). 170 UA1 UA2 UA3 171 | | | 172 | INVITE (R-P:3) | | 173 |----------------------->| | 174 | 200 OK | | 175 |<-----------------------| | 176 | ACK | | 177 |----------------------->| | 178 | RTP | | 179 |<======================>| | 180 | | INVITE (R-P:2) | 181 | |<------------------------| 182 | BYE (Reason : ? ) | | 183 |<-----------------------| | 184 | | 200 OK | 185 | |------------------------>| 186 | 200 OK | | 187 |----------------------->| | 188 | | ACK | 189 | |<------------------------| 190 | | RTP | 191 | |<=======================>| 192 | | | 194 Figure 1. Access Preemption with obscure Reason 196 After the session between UA1 and UA2 is established, UA3 invites 197 UA2 to a new session with an R-P of 2 (a higher priority than the 198 current session between UA1 and UA2). Local policy within this 199 domain dictates that UA2 must preempt all existing calls of lower 200 priority in order to accept a higher priority call. 202 What Reason value could be inserted above to mean "preemption" at a 203 UA? There are several choices: 410 "Gone", 480 "Temporarily 204 Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The 205 use of any here is questionable because the session is already 206 established. It is further complicated if there needs to be a 207 difference in the Reason value for an Access versus a Network 208 Preemption Event (which is a requirement here). The limits of Q.850 209 [5] have been stated previously in this document. 211 It should be possible to configure UAs receiving a preemption 212 indication to indicate to the user no particular type of preemption 213 occurred. There are some domains that might prefer their users to 214 remain unaware of the specifics of network behavior. This should 215 not ever prevent a known preemption indication from being sent in a 216 BYE from a UA. 218 2.1 Effects of Preemption at the User Agent 220 If 2 UAs are in a session, and one UA must preempt that session to 221 accept another session, a BYE Method message is the appropriate 222 mechanism to perform this task. However, taking this a step 223 further, if a UA is the common point of a 3-way (or more) adhoc 224 conference participants and must preempt all sessions in that 225 conference due to a higher priority session request received (that 226 this UA must accept), then a BYE message must be sent to all UAs in 227 that adhoc conference. 229 2.2 Reason Header Requirements for Access Preemption Events 231 The following is a list of requirements for adding an appropriate 232 Reason value for an Access Preemption Event (APE) as described above 233 and shown in Figure 1: 235 APE_REQ#1 - create a means by which one UA can inform another UA 236 (within the same active session) that the active 237 session between the two devices is being purposely 238 preempted at one UA for a higher priority session 239 request from another UA. 241 APE_REQ#2 - create a means by which all relevant SIP elements can 242 be informed of this Access Preemption Event to a 243 specific session. 245 For example: perhaps SIP Servers that have incorporated a Record- 246 Route header into that session set-up need to be informed of this 247 occurrence. 249 APE_REQ#3 - create a means of informing all participants in a 250 adhoc conference that the primary UA (the mixer) has 251 preempted the conference by accepting a higher 252 priority session request. 254 APE_REQ#4 - create a separate indication for the access 255 preemption event than one used for a Network 256 Preemption Event (described in the next section) in 257 the session BYE message. 259 APE_REQ#5 - create a means to generate a specific indication of a 260 preemption event at the user agent to inform all 261 relevant SIP entities, yet have the ability to 262 generalize this indication (based on local policy) to 263 the receiving UA such that this UA cannot display 264 more information than the domain wants the user to 265 see. 267 3. Network Preemption Events 269 Network Preemption Events (NPE) are those instances in which a 270 intermediate router between SIP elements preempts one or more 271 sessions at one of its interfaces to place a higher priority 272 session through that interface. Within RSVP, there exists a means to 273 execute this functionality in [7]: ResvErr messages - which travel 274 downstream towards appropriate receivers. The ResvErr message has 275 the ability to carry within it a code why a reservation is being 276 torn down. The ResvErr does not travel upstream to the other UA. 277 This document here proposes a SIP message be generated to 278 synchronize all relevant SIP elements to this preemption event. 279 Creating another Reason value describing that a network element 280 preempted the session is necessary in certain domains. 282 The following 2 diagrams (Figures 2 and 3) illustrate the network 283 preemption scenario: 285 UA1 invites UA2 to a session with the Resource Priority level of 3 286 (levels 1 and 2 are higher is this domain) and is accepted. This 287 SIP signaling translated the Resource Priority value to an 288 appropriate RSVP priority level for that flow. The link between 289 Router 1 and Router 2 became saturated with this session reservation 290 between UA1 and UA2 (in this example). 292 UA1 UA2 293 \ / 294 \ / 295 +--------+ +--------+ 296 | | | | 297 | RTR1 | | RTR2 | 298 | Int7-------Int5 | 299 | | | | 300 +--------+ +--------+ 301 / \ 302 / \ 303 UA3 UA4 305 Figure 2. Network Diagram Scenario A 307 After the session between UA1 and UA2 is established, UA3 invites 308 UA4 to a new session with an Resource Priority level of 2 (a higher 309 priority than the current reservation between UA1 and UA2). Again, 310 the priority value within the Resource-Priority header of this 311 INVITE is translated into an appropriate RSVP priority (that is also 312 higher in relative priority to the UA1_UA2 session/RSVP flow). When 313 this second (higher priority session) is signaled, one Path message 314 goes from UA3 to UA4, resulting in the Resv message going from UA4 315 back to UA3. Because this link between the two routers is at 316 capacity (at Int7 in Figure 5), Router 1 will (in this example) make 317 the decision to preempt lower priority BW to ensure this higher 318 priority session reservation is completed. A ResvErr message is 319 sent to UA2. The result is that UA2 will know that there has been a 320 preemption event in a router (because the ResvErr message has a 321 error code within it stating "preemption"), UA1 at this point will 322 not know anything of this preemption. If there are any SIP Proxies 323 in between UAs 1 & 2(perhaps that inserted a Record-Route Header), 324 each will need to be informed also as to why this reservation was 325 torn down. 327 Figure 3 shows the call flow with Router 2 from Figure 2 included at 328 the RSVP layer sending the ResvErr message. A complete call flow 329 including all UAs and Routers is not shown here for diagram 330 complexity reasons. The signaling between UA3 and UA4 is also not 331 included. 333 UA1 Rtr2 UA2 334 | | | 335 | INVITE (R-P:3) | 336 |------------------------------------------------->| 337 | 200 OK | 338 |<-------------------------------------------------| 339 | ACK | 340 |------------------------------------------------->| 341 | RTP | 342 |<================================================>| 343 | ******************************************** | 344 | * -UA3 sends INV to UA4 w/ RP:2; * | 345 | * -Reservation set-up occurs between UA3 * | 346 | * and UA4 * | 347 | * -Router 2 must preempt UA1-UA2 * | 348 | * ****************************************** | 349 | | 350 | | ResvErr | 351 | |------------------------>| 352 | | | 353 | | 354 | BYE (Reason : ? ) | 355 |<-------------------------------------------------| 356 | 200 OK | 357 |------------------------------------------------->| 358 | | 360 Figure 3. Network Preemption with obscure Reason 362 What Reason value could be inserted above to mean "preemption at a 363 router interface"? There are several choices: 410 "Gone", 480 364 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service 365 Unavailable". The use of any here is questionable because the 366 session is already established. It is further complicated if there 367 needs to be a difference in the Reason value for an Access versus a 368 Network Preemption Event. The limits of Q.850 [5] have already been 369 stated previously showing there is nothing in that spec to indicate 370 a problem in an IP network. 372 To generically state that all preemptions are equal is possible, but 373 will not provide adequate information. Therefore, another Reason 374 Header value is necessary to differentiate the APE from the NPE. 376 3.1 Reason Header Requirements for Network Preemption Events 378 The following are the requirements for the appropriate SIP signaling 379 in reaction to a Network Preemption Event: 381 NPE_REQ#1 - create a means of informing the far end UA that a 382 Network Preemption Event has occurred in an 383 intermediate router. 385 NPE_REQ#2 - create a means by which all relevant SIP elements can 386 be informed of a Network Preemption Event to a 387 specific session. 389 For example: perhaps SIP Servers that have incorporated a Record- 390 Route header into that session set-up. 392 NPE_REQ#3 - create a means of informing all participants in a 393 adhoc conference that the primary UA (the mixer) has 394 been preempted by a Network Preemption Event. 396 NPE_REQ#4 - create a separate description of the Network 397 Preemption Event relative to an Access Preemption 398 Event in SIP. 400 4. Including a Hybrid Infrastructure 402 If it is the case that User 1 is in a non-IP portion of 403 infrastructure (using a TDM phone) in a session with a UA through a 404 SIP gateway, and the TDM portion had the ability to preempt the 405 session and indicate to the SIP gateway when it did such a 406 preemption, the SIP GW would need to be able to convey this 407 preemption event into the SIP portion of this session just as if 408 user 1 were a UA in the session. Below is a diagram of this: 410 ************************** 411 * TDM network * 412 * +---------+ 413 * User 1 | | 414 * O ==========>| SIP GW1 |================> UA2 415 * /|\ ^ | | | 416 * / \ | +---------+ | 417 * | * | 418 **********|*************** | | 419 | | Preemption | 420 Preemption ---------> |--------------------->| 421 Event Indication 423 Figure 4. TDM/IP Preemption Event 425 4.1 Hybrid Infrastructure Requirements 427 The following are the requirements unique to the topology involving 428 both IP infrastructure and TDM (or non-IP) infrastructure. 430 HYB_REQ#1 - create a means of informing the far end UA in a 431 dialog through a SIP gateway with a Non-IP phone 432 that the TDM portion of the session indicated to 433 the SIP gateway that a preemption event terminated 434 the session. 436 HYB_REQ#2 - create a means of identifying this preemption 437 event uniquely with respect to an access 438 preemption and network preemption event. 440 5. Preemption Reason Header Cause Codes and Semantics 442 This document defines the following new protocol value for the 443 protocol field of the Reason header field in RFC 3326 [1]: 445 Preemption: The cause parameter contains a preemption cause code 447 We define the following preemption cause codes: 449 Value Default Text Description 450 1 UA Preemption The session has been preempted by a UA 452 2 RSVP Preemption The session preemption has been 453 initiated within the network via a 454 purposeful RSVP preemption occurrence, 455 and not a link error 457 3 Generic Preemption This is a limited use preemption 458 indication to be used on the final leg 459 to the preempted UA to generalize the 460 event 462 4 Non-IP Preemption The session preemption has occurred in 463 a non-IP portion of the infrastructure 464 and this is the Reason cause code given 465 by the SIP Gateway 467 Example syntax is as follows: 469 Reason: preemption ;cause=1 ;text="UA Preemption" 470 Reason: preemption ;cause=2 ;text="RSVP Preemption" 471 Reason: preemption ;cause=3 ;text="Generic Preemption" 472 Reason: preemption ;cause=4 ;text="Non-IP Preemption" 474 Sections 5.1, 5.2, 5.3 and 5.4 provide uses cases and extended 475 definitions for the above four cause codes with message flow 476 diagrams. 478 5.1 Access Preemption Event Reason Code 480 The more elaborate description of the Access Preemption Event 481 cause=1 is as follows: 483 A user agent in a session has purposely preempted a session and 484 is informing the far end user agent, or user agents (if part of a 485 conference), and SIP Proxies (if stateful of the session's 486 transactions) 488 An example usage of this header value would be: 490 Reason: preemption ;cause=1 ;text="UA Preemption" 492 5.1.1 Access Preemption Event Call Flow 494 The following diagram (Figure 5) replicates the call flow from 495 Figure 1 - but with an appropriate Reason value indication that was 496 proposed in section 4.1 above: 498 UA1 UA2 UA3 499 | | | 500 | INVITE (R-P:3) | | 501 |---------------------------------->| | 502 | 200 OK | | 503 |<----------------------------------| | 504 | ACK | | 505 |---------------------------------->| | 506 | RTP | | 507 |<=================================>| | 508 | | INVITE (R-P:2) | 509 | |<-------------------| 510 | BYE (Reason: Preemption ; | | 511 | cause=1 ;text="UA Preemption") | | 512 |<----------------------------------| | 513 | | 200 OK | 514 | |------------------->| 515 | 200 OK | | 516 |---------------------------------->| | 517 | | ACK | 518 | |<-------------------| 519 | | RTP | 520 | |<==================>| 521 | | | 523 Figure 5. Access Preemption with Reason: UA Preemption 525 UA1 invites UA2 to a session with the Resource Priority level of 3 526 (levels 1 and 2 are higher is this domain). After the session 527 between UA1 and UA2 is established, UA3 invites UA2 to a new session 528 with an R-P of 2 (a higher priority than the current session to 529 UA1). Local policy within this domain dictates that UA2 must 530 preempt all existing calls of lower priority in order to accept a 531 higher priority call. 533 UA2 sends a BYE Request message with a Reason header with a value: 534 UA Preemption. This will inform the far end UA (UA1), and all 535 relevant SIP elements (for example: SIP Proxies). The cause code is 536 unique to what is proposed in the RSVP Preemption Event for 537 differentiation purposes. 539 5.2 Network Preemption Events Reason Code 541 The more elaborate description of the RSVP Preemption Event 542 cause=2 is as follows: 544 A router has preempted a reservation flow and generated a ResvErr 545 (downstream). The (downstream) UA receiving the ResvErr message 546 generates a BYE request towards the far side UA with a Reason 547 Header with this value indicating that somewhere in between two 548 or more UAs, a router has administratively preempted this session 550 An example usage of this header value would be: 552 Reason: Preemption :cause=2 ;text="RSVP Preemption" 554 5.2.1 Network Preemption Event Call Flow 556 The following diagram (Figure 6) replicates the call flow from 557 Figure 5 - but with an appropriate Reason value indication that was 558 proposed in section 4.2 above. 560 UA1 Rtr2 UA2 561 | | | 562 | INVITE (R-P:3) | 563 |---------------------------------------------------->| 564 | 200 OK | 565 |<----------------------------------------------------| 566 | ACK | 567 |---------------------------------------------------->| 568 | RTP | 569 |<===================================================>| 570 | | 571 | *********************************************** | 572 | * -UA3 sends INV to UA4 w/ RP:2; * | 573 | * -Reservation set-up occurs between UA3 * | 574 | * and UA4 * | 575 | * -Router 2 must preempt UA1-UA2 * | 576 | * ********************************************* | 577 | | 578 | | ResvErr | 579 | |------------------------>| 580 | | | 581 | | 582 | BYE (Reason : Preemption ;cause=1 ; | 583 | text="RSVP Preemption") | 584 |<----------------------------------------------------| 585 | 200 OK | 586 |---------------------------------------------------->| 587 | | 589 Figure 6. Network Preemption with "RSVP Preemption" 591 Above is the call flow with Router 2 from Figure 2 included at the 592 RSVP layer sending the Resv messages. A complete call flow 593 including all UAs and Routers is not here for diagram complexity 594 reasons. The signaling between UA3 and UA4 is also not included. 596 Upon receipt of the ResvErr message with the preemption error code, 597 UA2 can now appropriately inform UA1 why this event occurred. This 598 BYE message will also inform all relevant SIP elements, 599 synchronizing them. The cause value is unique to that proposed in 600 section 4.1 for Access Preemption Events for differentiation 601 purposes. 603 5.3 Generic Preemption Event Reason Code 605 The more elaborate description of the Generic Preemption Event 606 cause=3 is as follows: 608 This cause code is for infrastructures that do not wish to 609 provide the preempted UA a more precise reason that just 610 "preemption". It is possible that UAs will have code that will 611 indicate the type of preemption event that is contained in the 612 Reason header, and certain domains have expressed this as not 613 being optimal, and wanted to generalize the indication. This 614 MUST NOT be the initial indication within these domains, as 615 valuable traffic analysis and other NM applications will be 616 generalized as well. If this cause value is to be implemented, 617 it SHOULD only be done at the final SIP Proxy in such a way that 618 the cause value indicating which type of preemption event 619 actually occurred is changed to this generalized preemption 620 indication to be received by the preempted UA. 622 An example usage of this header value would be: 624 Reason: preemption ;cause=3 ;text="Generic Preemption" 626 5.4 Non-IP Preemption Event Reason Code 628 The more elaborate description of the Non-IP Preemption Event 629 cause=4 is as follows: 631 A session exists in a hybrid IP/Non-IP infrastructure and the 632 preemption event occurs in the Non-IP portion, and was indicated 633 by that portion that this call termination was due to preemption. 634 This is the indication that would be generated by a SIP Gateway 635 towards the SIP UA that is being preempted, traversing whichever 636 SIP Proxies are involved in session signaling (a question of 637 server state). 639 An example usage of this header value would be: 641 Reason: preemption ;cause=4 ;text=" Non-IP Preemption" 643 5.4.1 Non-IP Preemption Event Call Flow 645 The following is a simple call flow diagram of the Non-IP 646 preemption event. 648 ............ 649 UA1 SIP GW1 . User3 . 650 | | . . 651 | INVITE (R-P:1) | . . 652 |-------------------------------------->| . Non-IP . 653 | 200 OK | . . 654 |<--------------------------------------| . Network . 655 | ACK | . . 656 |-------------------------------------->| . . 657 | RTP | . . 658 |<=====================================>| . . 659 | | . . 660 | BYE (Reason: Preemption ; |<==Preemption Indication 661 | cause=4 ;text="Non-IP Preemption") | . . 662 |<--------------------------------------| . . 663 | | ............ 665 Figure 7. Non-IP Preemption Flow 667 In this case, UA1 signals User3 to a session. Once established, 668 there is a preemption event in the Non-IP portion of the 669 session/call, and the TDM portion has the ability to inform the SIP 670 GW of this type of event. This Non-IP signal can be translated into 671 SIP signaling (into the BYE session termination message). Within 672 this BYE there should be a Reason header indicating such an event 673 to synchronize all SIP elements. 675 6. Security Considerations 677 Eavesdropping on this header field should not prevent proper 678 operation of the SIP protocol, although some domains utilizing this 679 mechanism for notifying and synchronizing SIP elements will likely 680 want the integrity to be assured. It is therefore RECOMMENDED to 681 apply integrity protection when using this header to prevent 682 unwanted changes to the field and snooping of the messages. The 683 accepted choices to provide integrity protection in SIP are TLS and 684 S/MIME. 686 7. IANA Considerations 688 RFC [XXXX} (this document) proposes the new SIP "Reason Header" [1] 689 protocol namespace: "Preemption", with 4 defined cause codes: 691 In instances where this namespace is used to indicate preemption 692 at a UA, the following syntax shall be used: 694 Reason: preemption ;cause=1 ;text="UA Preemption" 696 Section 5.1 of this document describes in detail the semantics 697 of this cause code. 699 In instances where this namespace is used to indicate preemption 700 based on receipt of an RSVP ResvErr message at a SIP UA, the 701 following syntax shall be used: 703 Reason: preemption ;cause=2 ;text="RSVP Preemption" 705 Section 5.2 of this document describes in detail the semantics 706 of this cause code. 708 In instances where this namespace is used to indicate a 709 generalized preemption event to the destination UA from a Proxy 710 that modifies the Reason value only during this last SIP hop 711 shall use the following syntax: 713 Reason: preemption ;cause=3 ;text="Generic Preemption" 715 Section 5.3 of this document describes in detail the semantics 716 of this cause code. 718 In instances where this namespace is used to indicate preemption 719 from a Non-IP portion of a call leg, a SIP Gateway shall use the 720 following syntax to inform the SIP infrastructure of this event 721 with: 723 Reason: preemption ;cause=4 ;text=" Non-IP Preemption" 724 Section 5.4 of this document describes in detail the semantics 725 of this cause code. 727 Additional definitions of the preemption namespace and its cause 728 codes MUST be defined in Standards Track documents. 730 8. Contributions 732 The following individuals contributed to this effort: 734 Subhasri Dhesikan 735 Gonzalo Camarillo 736 Dave Oran 738 The author thanks these individuals greatly for their aid in this 739 effort. 741 9. Acknowledgements 743 To Haluk Keskiner for providing a valued sanity check. To Dean 744 Willis, Rohan Mahy and Allison Mankin for their belief in and 745 backing of this effort. To Adam Roach and Arun Kumar for helpful 746 comments to this document. 748 10. Normative References 750 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 751 for the Session Initiation Protocol (SIP)", RFC 3326 Reason 752 Header, December 2002 754 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 755 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 756 Session Initiation Protocol", RFC 3261, June 2002. 758 [3] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg, "Integration of 759 Resource Management and Session Initiation Protocol (SIP)", RFC 760 3312 Preconditions, October 2002 762 [4] H. Schulzrinne, J. Polk, "Communications Resource-Priority Header 763 in SIP", Internet Draft, work in progress, Mar 2004 765 [5] ITU-T Recommendation Q.850 (1993) 767 [6] Bradner, S., "Key words for use in RFCs to indicate requirement 768 levels," BCP 14, RFC 2119, March 1997. 770 [7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 771 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 772 Specification", RFC 2205, September 1997 774 11. Author Information 776 James M. Polk 777 Cisco Systems 778 2200 East President George Bush Turnpike 779 Richardson, Texas 75082 USA 781 jmpolk@cisco.com 783 Full Copyright Statement 785 Copyright (C) The Internet Society (2004). This document is subject 786 to the rights, licenses and restrictions contained in BCP 78, and 787 except as set forth therein, the authors retain all their rights. 789 This document and the information contained herein are provided on 790 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 791 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 792 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 793 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 794 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 795 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 797 Intellectual Property 799 The IETF takes no position regarding the validity or scope of any 800 Intellectual Property Rights or other rights that might be claimed 801 to pertain to the implementation or use of the technology described 802 in this document or the extent to which any license under such 803 rights might or might not be available; nor does it represent that 804 it has made any independent effort to identify any such rights. 805 Information on the procedures with respect to rights in RFC 806 documents can be found in BCP 78 and BCP 79. 808 Copies of IPR disclosures made to the IETF Secretariat and any 809 assurances of licenses to be made available, or the result of an 810 attempt made to obtain a general license or permission for the use 811 of such proprietary rights by implementers or users of this 812 specification can be obtained from the IETF on-line IPR repository 813 at http://www.ietf.org/ipr. 815 The IETF invites any interested party to bring to its attention any 816 copyrights, patents or patent applications, or other proprietary 817 rights that may cover technology that may be required to implement 818 this standard. Please address the information to the IETF at ietf- 819 ipr@ietf.org. 821 Acknowledgement 823 Funding for the RFC Editor function is currently provided by the 824 Internet Society. 826 The Expiration date for this Internet Draft is: 828 February 28th, 2005