idnits 2.17.1 draft-ietf-sipping-reason-header-for-preemption-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 933. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 20 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 876, 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: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group James M. Polk 3 Internet Draft Cisco Systems 4 Expires: March 12th, 2006 6 Extending the Session Initiation Protocol 7 Reason Header for Preemption Events 8 draft-ietf-sipping-reason-header-for-preemption-04.txt 10 Sept 12th, 2005 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 Months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 12th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document proposes an IANA Registration extension to the Session 44 Initiation Protocol (SIP) Reason Header to include in a BYE Method 45 Request as a result of a session preemption event, either at a user 46 agent (UA), or somewhere in the network involving a reservation- 47 based protocol such as RSVP or NSIS. This document does not attempt 48 to address routers failing in the packet path; but a deliberate 49 event of tearing down a flow between UAs, and informing the 50 terminated UA(s) with an indication of what occurred. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Access Preemption Events . . . . . . . . . . . . . . . . . . 4 57 2.1 Effects of Preemption at the User Agent . . . . . . . . 5 58 2.2 Reason Header Requirements for 59 Access Preemption Events . . . . . . . . . . . . . . . 6 60 3. Network Preemption Events . . . . . . . . . . . . . . . . . 6 61 3.1 Reason Header Requirements for 62 Network Preemption Events . . . . . . . . . . . . . . . 9 63 4. Including a Hybrid Infrastructure . . . . . . . . . . . . . 9 64 4.1 Hybrid Infrastructure Requirements . . . . . . . . . . 10 65 5. Preemption Reason Header Cause Codes and Semantics . . . . . 10 66 5.1 Access Preemption Event Reason Code . . . . . . . . . . 11 67 5.1.1 Access Preemption Event Call Flow . . . . . . . . . . 11 68 5.2 Network Preemption Event Reason Code . . . . . . . . . 12 69 5.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12 70 5.3 Generic Preemption Event Reason Code . . . . . . . . . 13 71 5.4 Non-IP Preemption Event Reason Code . . . . . . . . . . 14 72 5.4.1 Non-IP Preemption Event Call Flow . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 75 8. Contributions . . . . . . . . . . . . . . . . . . . . . . . 17 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Author Information . . . . . . . . . . . . . . . . . . . . . 19 79 Intellectual Property and Copyright Statements . . . . . . . 19 81 1. Introduction 83 With the introduction of the SIP Resource-Priority (R-P) header [4], 84 there became the possibility of sessions being torn down for 85 (scarce) resource reasons; meaning there weren't enough resources 86 for a particular session to continue. Certain domains will 87 implement this mechanism where resources may become constrained 88 either at the user agent (UA), or at congested router interfaces 89 where more important sessions are to be completed at the expense of 90 less important sessions. Which sessions are more or less important 91 than others will not be discussed here. What is proposed here is 92 extending SIP to synchronize SIP elements as to why a preemption 93 event occurred and which type of preemption event occurred, as 94 viewed by the element that performed the preemption of a session. 96 The SIP Reason Header is an application layer feedback mechanism to 97 synchronize SIP elements of events; the particular event explained 98 here deals with preemption of a session. Q.850 [5] provides an 99 indication for preemption (cause=8) and for preemption "circuit 100 reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP 101 because IP has no concept of circuits. Some domains wish to 102 differentiate appropriate IP reasons for preemption of sessions and 103 topologically where the preemption event occurred. No other means 104 exists today to give this feedback as to why a session was torn down 105 for preemption grounds. 107 In the event that a session is terminated for a specific reason that 108 can (or should) be shared with SIP Servers and UAs sharing dialog, 109 the Reason Header [1] was created to be included in the BYE Request 110 This was not the only Method for this new Header; [1] also discusses 111 the CANCEL Method usage. 113 This document will define two use-cases in which new preemption 114 Reason values are necessary: 116 Access Preemption Event - this is when a UA receives a new SIP 117 session request message with a valid R-P value that is 118 higher than the one associated with the currently active 119 session at that UA. The UA must discontinue the existing 120 session in order to accept the new one (based on local 121 policy of some domains). 123 Network Preemption Event - this is when a network element - such 124 as a router - reaches capacity on a particular interface 125 and has the ability to statefully choose which session(s) 126 will remain active when a new session/reservation is 127 signaled for under the parameters outlined in SIP 128 Preconditions in [3] that would otherwise overload that 129 interface (perhaps adversely affecting all sessions). In 130 this case, the router must terminate one or more 131 reservations of lower priority in order to allow this 132 higher priority reservation access to the requested amount 133 of bandwidth (based on local policy of some domains). 135 This document will cover the semantics for these two cases, and 136 request IANA registration of the new protocol value "Preemption" for 137 the Reason Header field with 4 cause values for the above preemption 138 conditions. Additionally, this document will create a new IANA 139 Registry for reason-text strings that are not currently defined 140 through existing SIP Response codes or Q.850 cause codes. This new 141 Registry will be useful for future protocols used by the SIP Reason 142 header. 144 This document will emphasize an existing SIP RFC [3] as the starting 145 point for network preemption events. RFC 3312 set rules surrounding 146 SIP interaction using a reservation protocol for QoS preconditions, 147 using RSVP as the example protocol. That effort did not preclude 148 other preconditions or future protocol work from becoming a means of 149 preconditions. NSIS is a new reservation protocol effort that 150 specifies a preemption operation similar to RSVP's ResvErr message 151 involving the NSIS NOTIFY message in [8] with a Transient error code 152 0x04000005 (Resources Pre-empted). 154 To be clear, it should be noted that SIP itself does not cause RSVP 155 or NSIS reservation signaling to start or end. That operation is 156 part of a separate API within each UA. 158 1.1 Conventions used in this document 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 161 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described 163 in [6]. 165 2. Access Preemption Events 167 As mentioned previously, Access Preemption Events (APE) occur at 168 the user agent. It does not matter which UA in a unicast or 169 multicast session this happens to (the UAC or UAS of a session). If 170 local policy dictates in a particular domain, rules regarding the 171 functionality of a UA, there must be a means by which that UA (not 172 the user) informs the other UA(s) why a session was just torn down 173 prematurely. The appropriate mechanism is to utilize the BYE 174 Method. The user of the other far side UA will not understand why 175 that session "just went away" without there being a means of 176 informing the UA what occurred (if this event was purposeful). 177 Through this type of indication to the preempted UA, it can indicate 178 to the user of that device appropriately. 180 The rules within a domain surrounding informing of UA can be 181 different than the rules of informing the user. Local policy should 182 determine if the user should be informed of the specific reason. 183 This indication in SIP will provide a means for the UA to react in a 184 locally determined way if appropriate (play a certain tone or tone 185 sequence, point towards a special announcement uri, causes the UA's 186 visual display to do something, etc). 188 The following diagram (Figure 1) illustrates the scenario here. UA1 189 invites UA2 to a session with the Resource Priority level of 3 190 (levels 1 and 2 are higher is this domain, and the namespace element 191 is not necessary for this discussion). 193 UA1 UA2 UA3 194 | | | 195 | INVITE (R-P:3) | | 196 |----------------------->| | 197 | 200 OK | | 198 |<-----------------------| | 199 | ACK | | 200 |----------------------->| | 201 | RTP | | 202 |<======================>| | 203 | | INVITE (R-P:2) | 204 | |<------------------------| 205 | BYE (Reason : ? ) | | 206 |<-----------------------| | 207 | | 200 OK | 208 | |------------------------>| 209 | 200 OK | | 210 |----------------------->| | 211 | | ACK | 212 | |<------------------------| 213 | | RTP | 214 | |<=======================>| 215 | | | 217 Figure 1. Access Preemption with obscure Reason 219 After the session between UA1 and UA2 is established, UA3 invites 220 UA2 to a new session with an R-P of 2 (a higher priority than the 221 current session between UA1 and UA2). Local policy within this 222 domain dictates that UA2 must preempt all existing calls of lower 223 priority in order to accept a higher priority call. 225 What Reason value could be inserted above to mean "preemption" at a 226 UA? There are several choices: 410 "Gone", 480 "Temporarily 227 Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The 228 use of any here is questionable because the session is already 229 established. It is further complicated if there needs to be a 230 difference in the Reason value for an Access versus a Network 231 Preemption Event (which is a requirement here). The limits of Q.850 232 [5] have been stated previously in this document. 234 It should be possible to configure UAs receiving a preemption 235 indication to indicate to the user no particular type of preemption 236 occurred. There are some domains that might prefer their users to 237 remain unaware of the specifics of network behavior. This should 238 not ever prevent a known preemption indication from being sent in a 239 BYE from a UA. 241 2.1 Effects of Preemption at the User Agent 243 If 2 UAs are in a session, and one UA must preempt that session to 244 accept another session, a BYE Method message is the appropriate 245 mechanism to perform this task. However, taking this a step 246 further, if a UA is the common point of a 3-way (or more) adhoc 247 conference participants and must preempt all sessions in that 248 conference due to a higher priority session request received (that 249 this UA must accept), then a BYE message must be sent to all UAs in 250 that adhoc conference. 252 2.2 Reason Header Requirements for Access Preemption Events 254 The following is a list of requirements for adding an appropriate 255 Reason value for an Access Preemption Event (APE) as described above 256 and shown in Figure 1: 258 APE_REQ#1 - create a means by which one UA can inform another UA 259 (within the same active session) that the active 260 session between the two devices is being purposely 261 preempted at one UA for a higher priority session 262 request from another UA. 264 APE_REQ#2 - create a means by which all relevant SIP elements can 265 be informed of this Access Preemption Event to a 266 specific session. 268 For example: perhaps SIP Servers that have incorporated a Record- 269 Route header into that session set-up need to be informed of this 270 occurrence. 272 APE_REQ#3 - create a means of informing all participants in a 273 adhoc conference that the primary UA (the mixer) has 274 preempted the conference by accepting a higher 275 priority session request. 277 APE_REQ#4 - create a separate indication for the access 278 preemption event than one used for a Network 279 Preemption Event (described in the next section) in 280 the session BYE message. 282 APE_REQ#5 - create a means to generate a specific indication of a 283 preemption event at the user agent to inform all 284 relevant SIP entities, yet have the ability to 285 generalize this indication (based on local policy) to 286 the receiving UA such that this UA cannot display 287 more information than the domain wants the user to 288 see. 290 3. Network Preemption Events 292 Network Preemption Events (NPE) are those instances in which a 293 intermediate router between SIP user agents preempts one or more 294 sessions at one of its interfaces to place a higher priority 295 session through that interface. Within RSVP, there exists a means to 296 execute this functionality in [7]: ResvErr messages - which travel 297 downstream towards appropriate receivers. The ResvErr message has 298 the ability to carry within it a code why a reservation is being 299 torn down. The ResvErr does not travel upstream to the other UA. 300 This document here proposes a SIP message be generated to 301 synchronize all relevant SIP elements to this preemption event, 302 including the upstream UA. Creating another Reason value describing 303 that a network element preempted the session is necessary in certain 304 domains. 306 Two diagrams (Figures 2 and 3) illustrate a network preemption 307 scenario with RSVP. NSIS, not shown in examples here, can be 308 imagined here from [8] with a NOTIFY error message indicating a 309 reservation has been preempted with the Transient ERROR_SPEC 310 0x04000005. SIP behavior will be identical using either reservation 311 protocol. 313 UA1 invites UA2 to a session with the Resource Priority level of 3 314 (levels 1 and 2 are higher is this domain) and is accepted. This 315 SIP signaling translated the Resource Priority value to an 316 appropriate RSVP priority level for that flow. The link between 317 Router 1 and Router 2 became saturated with this session reservation 318 between UA1 and UA2 (in this example). 320 UA1 UA2 321 \ / 322 \ / 323 +--------+ +--------+ 324 | | | | 325 | RTR1 | | RTR2 | 326 | Int7-------Int5 | 327 | | | | 328 +--------+ +--------+ 329 / \ 330 / \ 331 UA3 UA4 333 Figure 2. Network Diagram Scenario A 335 After the session between UA1 and UA2 is established, UA3 invites 336 UA4 to a new session with an Resource Priority level of 2 (a higher 337 priority than the current reservation between UA1 and UA2). Again, 338 the priority value within the Resource-Priority header of this 339 INVITE is translated into an appropriate RSVP priority (that is also 340 higher in relative priority to the UA1_UA2 session/RSVP flow). When 341 this second (higher priority session) is signaled, one Path message 342 goes from UA3 to UA4, resulting in the RESV message going from UA4 343 back to UA3. Because this link between the two routers is at 344 capacity (at Int7 in Figure 5), Router 1 will (in this example) make 345 the decision, or will communicate with another network entity that 346 will make the decision to preempt lower priority BW to ensure this 347 higher priority session reservation is completed. A ResvErr message 348 is sent to UA2. The result is that UA2 will know that there has 349 been a preemption event in a router (because the ResvErr message has 350 a error code within it stating "preemption"), UA1 at this point will 351 not know anything of this preemption. If there are any SIP Proxies 352 in between UAs 1 & 2 (perhaps that inserted a Record-Route Header), 353 each will need to be informed also as to why this reservation was 354 torn down. 356 Figure 3 shows the call flow with Router 2 from Figure 2 included at 357 the RSVP layer sending the ResvErr message. A complete call flow 358 including all UAs and Routers is not shown here for diagram 359 complexity reasons. The complete signaling between UA3 and UA4 is 360 also not included. 362 UA1 Rtr2 UA2 363 | | | 364 | INVITE with QoS Preconditions (R-P:3) | 365 |------------------------------------------------->| 366 | ******************************************** | 367 | * - QoS Preconditions established UA1-UA2 * | 368 | * - SIP signaling continues... * | 369 | ******************************************** | 370 | 200 OK | 371 |<-------------------------------------------------| 372 | ACK | 373 |------------------------------------------------->| 374 | RTP | 375 |<================================================>| 376 | ******************************************** | 377 | * -UA3 sends INV with QoS Preconditions * | 378 | * to UA4 w/ RP:2; * | 379 | * -Reservation set-up occurs between UA3 * | 380 | * and UA4 * | 381 | * -Router 2 in Figure 2 must preempt * | 382 | * reservation between UA1 & UA2 * | 383 | * ****************************************** | 384 | | 385 | | ResvErr | 386 | |------------------------>| 387 | | | 388 | | 389 | BYE (Reason : ? ) | 390 |<-------------------------------------------------| 391 | 200 OK | 392 |------------------------------------------------->| 393 | | 395 Figure 3. Network Preemption with obscure Reason 397 What Reason value could be inserted above to mean "preemption at a 398 router interface"? There are several choices: 410 "Gone", 480 399 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service 400 Unavailable". The use of any here is questionable because the 401 session is already established. It is further complicated if there 402 needs to be a difference in the Reason value for an Access versus a 403 Network Preemption Event. The limits of Q.850 [5] have already been 404 stated previously showing there is nothing in that spec to indicate 405 a problem in an IP network. 407 To generically state that all preemptions are equal is possible, but 408 will not provide adequate information. Therefore, another Reason 409 Header value is necessary to differentiate the APE from the NPE. 411 3.1 Reason Header Requirements for Network Preemption Events 413 The following are the requirements for the appropriate SIP signaling 414 in reaction to a Network Preemption Event (NPE): 416 NPE_REQ#1 - create a means of informing the far end UA that a 417 Network Preemption Event has occurred in an 418 intermediate router. 420 NPE_REQ#2 - create a means by which all relevant SIP elements can 421 be informed of a Network Preemption Event to a 422 specific session. 424 For example: perhaps SIP Servers that have incorporated a Record- 425 Route header into that session set-up. 427 NPE_REQ#3 - create a means of informing all participants in a 428 adhoc conference that the primary UA (the mixer) has 429 been preempted by a Network Preemption Event. 431 NPE_REQ#4 - create a separate description of the Network 432 Preemption Event relative to an Access Preemption 433 Event in SIP. 435 4. Including a Hybrid Infrastructure 437 If it is the case that User 1 is in a non-IP portion of 438 infrastructure (using a TDM phone) in a session with a UA through a 439 SIP gateway, and the TDM portion had the ability to preempt the 440 session and indicate to the SIP gateway when it did such a 441 preemption, the SIP GW would need to be able to convey this 442 preemption event into the SIP portion of this session just as if 443 user 1 were a UA in the session. Below is a diagram of this: 445 ************************** 446 * TDM network * 447 * +---------+ 448 * User 1 | | 449 * O ==========>| SIP GW1 |================> UA2 450 * /|\ ^ | | | 451 * / \ | +---------+ | 452 * | * | 453 **********|*************** | | 454 | | Preemption | 455 Preemption ---------> |--------------------->| 456 Event Indication 458 Figure 4. TDM/IP Preemption Event 460 4.1 Hybrid Infrastructure Requirements 462 The following are the requirements unique to the topology involving 463 both IP infrastructure and TDM (or non-IP) infrastructure. 465 HYB_REQ#1 - create a means of informing the far end UA in a 466 dialog through a SIP gateway with a Non-IP phone 467 that the TDM portion of the session indicated to 468 the SIP gateway that a preemption event terminated 469 the session. 471 HYB_REQ#2 - create a means of identifying this preemption 472 event uniquely with respect to an access 473 preemption and network preemption event. 475 5. Preemption Reason Header Cause Codes and Semantics 477 This document defines the following new protocol value for the 478 protocol field of the Reason header field in RFC 3326 [1]: 480 Preemption: The cause parameter contains a preemption cause code 482 We define the following preemption cause codes: 484 Value Default Text Description 485 1 UA Preemption The session has been preempted by a UA 487 2 Reserved Resources The session preemption has been 488 Preempted initiated within the network via a 489 purposeful RSVP preemption occurrence, 490 and not a link error 492 3 Generic Preemption This is a limited use preemption 493 indication to be used on the final leg 494 to the preempted UA to generalize the 495 event 497 4 Non-IP Preemption The session preemption has occurred in 498 a non-IP portion of the infrastructure 499 and this is the Reason cause code given 500 by the SIP Gateway 502 Example syntax is as follows for each of the above preemption types: 504 Reason: preemption ;cause=1 ;text="UA Preemption" 505 Reason: preemption ;cause=2 ;text="Reserved Resources Preempted" 506 Reason: preemption ;cause=3 ;text="Generic Preemption" 507 Reason: preemption ;cause=4 ;text="Non-IP Preemption" 509 Sections 5.1, 5.2, 5.3 and 5.4 provide uses cases and extended 510 definitions for the above four cause codes with message flow 511 diagrams. 513 5.1 Access Preemption Event Reason Code 515 The more elaborate description of the Access Preemption Event 516 cause=1 is as follows: 518 A user agent in a session has purposely preempted a session and 519 is informing the far end user agent, or user agents (if part of a 520 conference), and SIP Proxies (if stateful of the session's 521 transactions) 523 An example usage of this header value would be: 525 Reason: preemption ;cause=1 ;text="UA Preemption" 527 5.1.1 Access Preemption Event Call Flow 529 The following diagram (Figure 5) replicates the call flow from 530 Figure 1 - but with an appropriate Reason value indication that was 531 proposed in section 4.1 above: 533 UA1 UA2 UA3 534 | | | 535 | INVITE (R-P:3) | | 536 |---------------------------------->| | 537 | 200 OK | | 538 |<----------------------------------| | 539 | ACK | | 540 |---------------------------------->| | 541 | RTP | | 542 |<=================================>| | 543 | | INVITE (R-P:2) | 544 | |<-------------------| 545 | BYE (Reason: Preemption ; | | 546 | cause=1 ;text="UA Preemption") | | 547 |<----------------------------------| | 548 | | 200 OK | 549 | |------------------->| 550 | 200 OK | | 551 |---------------------------------->| | 552 | | ACK | 553 | |<-------------------| 554 | | RTP | 555 | |<==================>| 556 | | | 558 Figure 5. Access Preemption with Reason: UA Preemption 560 UA1 invites UA2 to a session with the Resource Priority level of 3 561 (levels 1 and 2 are higher is this domain). After the session 562 between UA1 and UA2 is established, UA3 invites UA2 to a new session 563 with an R-P of 2 (a higher priority than the current session to 564 UA1). Local policy within this domain dictates that UA2 must 565 preempt all existing calls of lower priority in order to accept a 566 higher priority call. 568 UA2 sends a BYE Request message with a Reason header with a value: 569 UA Preemption. This will inform the far end UA (UA1), and all 570 relevant SIP elements (for example: SIP Proxies). The cause code is 571 unique to what is proposed in the RSVP Preemption Event for 572 differentiation purposes. 574 5.2 Network Preemption Events Reason Code 576 The more elaborate description of the Reserved Resources Preempted 577 Event cause=2 is as follows: 579 A router has preempted a reservation flow and generated a 580 reservation error message, a ResvErr traveling downstream in 581 RSVP, a NOTIFY in NSIS. The UA receiving the preemption error 582 message generates a BYE request towards the far side UA with a 583 Reason Header with this value indicating that somewhere in 584 between two or more UAs, a router has administratively preempted 585 this session. 587 An example usage of this header value would be: 589 Reason: Preemption :cause=2 ;text="Reserved Resources Preempted" 591 5.2.1 Network Preemption Event Call Flow 593 The following diagram (Figure 6) replicates the call flow from 594 Figure 5 - but with an appropriate Reason value indication that was 595 proposed in section 4.2 above. 597 UA1 Rtr2 UA2 598 | | | 599 | INVITE with QoS Preconditions (R-P:3) | 600 |---------------------------------------------------->| 601 | ******************************************** | 602 | * - QoS Preconditions established UA1-UA2 * | 603 | * - SIP signaling continues... * | 604 | ******************************************** | 605 | 200 OK | 606 |<----------------------------------------------------| 607 | ACK | 608 |---------------------------------------------------->| 609 | RTP | 610 |<===================================================>| 611 | ******************************************** | 612 | * -UA3 sends INV with QoS Preconditions * | 613 | * to UA4 w/ RP:2; * | 614 | * -Reservation set-up occurs between UA3 * | 615 | * and UA4 * | 616 | * -Router 2 in Figure 2 must preempt * | 617 | * reservation between UA1 & UA2 * | 618 | * ********************************************* | 619 | | 620 | | ResvErr | 621 | |------------------------>| 622 | | | 623 | | 624 | BYE (Reason : Preemption ;cause=2 ; | 625 | text="Reserved Resources Preempted") | 626 |<----------------------------------------------------| 627 | 200 OK | 628 |---------------------------------------------------->| 629 | | 631 Figure 6. Network Preemption with "Reserved Resources Preempted" 633 Above is the call flow with Router 2 from Figure 2 included at the 634 RSVP layer sending the Resv messages. A complete call flow 635 including all UAs and Routers is not here for diagram complexity 636 reasons. The signaling between UA3 and UA4 is also not included. 638 Upon receipt of the ResvErr message with the preemption error code, 639 UA2 can now appropriately inform UA1 why this event occurred. This 640 BYE message will also inform all relevant SIP elements, 641 synchronizing them. The cause value is unique to that proposed in 642 section 4.1 for Access Preemption Events for differentiation 643 purposes. 645 5.3 Generic Preemption Event Reason Code 647 The more elaborate description of the Generic Preemption Event 648 cause=3 is as follows: 650 This cause code is for infrastructures that do not wish to 651 provide the preempted UA a more precise reason that just 652 "preemption". It is possible that UAs will have code that will 653 indicate the type of preemption event that is contained in the 654 Reason header, and certain domains have expressed this as not 655 being optimal, and wanted to generalize the indication. This 656 MUST NOT be the initial indication within these domains, as 657 valuable traffic analysis and other NM applications will be 658 generalized as well. If this cause value is to be implemented, 659 it SHOULD only be done at the final SIP Proxy in such a way that 660 the cause value indicating which type of preemption event 661 actually occurred is changed to this generalized preemption 662 indication to be received by the preempted UA. 664 An example usage of this header value would be: 666 Reason: preemption ;cause=3 ;text="Generic Preemption" 668 5.4 Non-IP Preemption Event Reason Code 670 The more elaborate description of the Non-IP Preemption Event 671 cause=4 is as follows: 673 A session exists in a hybrid IP/Non-IP infrastructure and the 674 preemption event occurs in the Non-IP portion, and was indicated 675 by that portion that this call termination was due to preemption. 676 This is the indication that would be generated by a SIP Gateway 677 towards the SIP UA that is being preempted, traversing whichever 678 SIP Proxies are involved in session signaling (a question of 679 server state). 681 An example usage of this header value would be: 683 Reason: preemption ;cause=4 ;text="Non-IP Preemption" 685 5.4.1 Non-IP Preemption Event Call Flow 687 The following is a simple call flow diagram of the Non-IP 688 preemption event. 690 ............ 691 UA1 SIP GW1 . User3 . 692 | | . . 693 | INVITE (R-P:1) | . . 694 |-------------------------------------->| . Non-IP . 695 | 200 OK | . . 696 |<--------------------------------------| . Network . 697 | ACK | . . 698 |-------------------------------------->| . . 699 | RTP | . . 700 |<=====================================>| . . 702 | | . . 703 | BYE (Reason: Preemption ; |<==Preemption Indication 704 | cause=4 ;text="Non-IP Preemption") | . . 705 |<--------------------------------------| . . 706 | | ............ 708 Figure 7. Non-IP Preemption Flow 710 In this case, UA1 signals User3 to a session. Once established, 711 there is a preemption event in the Non-IP portion of the 712 session/call, and the TDM portion has the ability to inform the SIP 713 GW of this type of event. This Non-IP signal can be translated into 714 SIP signaling (into the BYE session termination message). Within 715 this BYE there should be a Reason header indicating such an event 716 to synchronize all SIP elements. 718 6. Security Considerations 720 Eavesdropping on this header field should not prevent proper 721 operation of the SIP protocol, although some domains utilizing this 722 mechanism for notifying and synchronizing SIP elements will likely 723 want the integrity to be assured. It is therefore RECOMMENDED to 724 apply integrity protection when using this header to prevent 725 unwanted changes to the field and snooping of the messages. The 726 accepted choices to provide integrity protection in SIP are TLS and 727 S/MIME. 729 7. IANA Considerations 731 This document adds to one existing IANA Registry and creates one new 732 Registry. The existing IANA Registry for the SIP Reason Header is 733 as follows: 735 Protocol Value Protocol Cause Reference 736 -------------- -------------- --------- 737 SIP Status code RFC 3261 738 Q.850 Cause value in decimal ITU-T Q.850 740 This document adds to that Registry with the following entry 741 (including the '*' comment): 743 Protocol Value Protocol Cause Reference 744 -------------- -------------- --------- 745 Preemption Cause value in decimal* RFC XXXX [this document] 747 * see the separate "Preemption" Registry for default reason-text 748 strings 750 The cause values created by the Preemption Protocol namespace in 751 this document are defined in section 7.1 below. Each cause value 752 has a Reason-text string as a general description of what the cause 753 value is for. This is shown for the existing Reason header in 754 section 2 of RFC 3326. Before this document, the Reason-text was 755 taken from the SIP Response code string from all SIP Response codes, 756 or the default description from Q.850 cause codes. There currently 757 is no place to register new reason-text strings other than from 758 those two sources. Because this document defines a new Reason 759 header protocol namespace, a new IANA Registry is created in section 760 7.2 below just for this and future Reason header protocol namespaces 761 (other than SIP Response codes or Q.850 cause values) to register 762 their respective general descriptive text string. These text 763 strings are non-binding, and merely the default for human 764 understanding, but deemed important enough to have their own 765 Registry. 767 7.1 "Preemption" Namespace Registry 769 RFC [XXXX} (this document) creates the new SIP "Reason Header" [1] 770 protocol namespace: "Preemption", with 4 defined cause codes: 772 In instances where this namespace is used to indicate preemption 773 at a UA, the following syntax shall be used (the reason-text is a 774 default string, it is not mandatory, and may be different): 776 Reason: preemption ;cause=1 ;text="UA Preemption" 778 Section 5.1 of this document describes in detail the semantics 779 of this cause code. 781 The default text above is part of a new IANA Registry for 782 default text strings for any new protocol namespace cause 783 code. See section 7.2 below for the details. 785 In instances where this namespace is used to indicate preemption 786 based on receipt of an RSVP ResvErr message at a SIP UA, the 787 following syntax shall be used (the reason-text is a default 788 string, it is not mandatory, and may be different): 790 Reason: preemption ;cause=2 ;text="Reserved Resources Preempted" 792 Section 5.2 of this document describes in detail the semantics 793 of this cause code. 795 The default text above is part of a new IANA Registry for 796 default text strings for any new protocol namespace cause 797 code. See section 7.2 below for the details. 799 In instances where this namespace is used to indicate a 800 generalized preemption event to the destination UA from a Proxy 801 that modifies the Reason value only during this last SIP hop 802 shall use the following syntax (the reason-text is a default 803 string, it is not mandatory, and may be different): 805 Reason: preemption ;cause=3 ;text="Generic Preemption" 807 Section 5.3 of this document describes in detail the semantics 808 of this cause code. 810 The default text above is part of a new IANA Registry for 811 default text strings for any new protocol namespace cause 812 code. See section 7.2 below for the details. 814 In instances where this namespace is used to indicate preemption 815 from a Non-IP portion of a call leg, a SIP Gateway shall use the 816 following syntax to inform the SIP infrastructure of this event 817 with (the reason-text is a default string, it is not mandatory, 818 and may be different): 820 Reason: preemption ;cause=4 ;text=" Non-IP Preemption" 822 Section 5.4 of this document describes in detail the semantics 823 of this cause code. 825 The default text above is part of a new IANA Registry for 826 default text strings for any new protocol namespace cause 827 code. See section 7.2 below for the details. 829 Additional definitions of the preemption namespace and its cause 830 codes MUST be defined in Standards Track documents. 832 7.2 Default Reason-Text IANA Registry for the SIP Reason Header 834 Below is the creation of a new IANA Registry for SIP Reason Header 835 reason-text strings, associated with their respective protocol type 836 and Reason-param cause values. Per RFC 3326, the Reason-text string 837 is a quoted default string with only human understandability meant. 838 These strings can be changed by local policy. 840 Reason- 841 Protocol param Reason-Text Reference 842 -------- ------- ------------ --------- 843 Preemption Cause=1 UA Preemption RFC XXXX [this document] 844 Preemption Cause=2 Reserved Resources RFC XXXX [this document] 845 Preempted 846 Preemption Cause=3 Generic Preemption RFC XXXX [this document] 847 Preemption Cause=4 Non-IP Preemption RFC XXXX [this document] 849 8. Contributions 851 The following individuals contributed to this effort: 853 Subhasri Dhesikan 854 Gonzalo Camarillo 855 Dave Oran 857 The author thanks these individuals greatly for their aid in this 858 effort. 860 9. Acknowledgements 862 To Haluk Keskiner for providing a valued sanity check. To Dean 863 Willis, Rohan Mahy and Allison Mankin for their belief in and 864 backing of this effort. To Adam Roach and Arun Kumar for helpful 865 comments to this document. 867 Thanks to Mike Pierce for helpful comments and catching a flaw in 868 this spec late in the process (before it was too late). 870 10. Normative References 872 [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field 873 for the Session Initiation Protocol (SIP)", RFC 3326 Reason 874 Header, December 2002 876 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 877 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 878 Session Initiation Protocol", RFC 3261, June 2002. 880 [3] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg, "Integration of 881 Resource Management and Session Initiation Protocol (SIP)", RFC 882 3312 Preconditions, October 2002 884 [4] H. Schulzrinne, J. Polk, "Communications Resource-Priority Header 885 in SIP", Internet Draft, work in progress, May 2005 887 [5] ITU-T Recommendation Q.850 (1993) 889 [6] Bradner, S., "Key words for use in RFCs to indicate requirement 890 levels," BCP 14, RFC 2119, March 1997. 892 [7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 893 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 894 Specification", RFC 2205, September 1997 896 10.1 Informative Reference 898 [8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, " NSLP 899 for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp, Sept 900 2005, "work in progress" 902 Author Information 904 James M. Polk 905 Cisco Systems 906 2200 East President George Bush Turnpike 907 Richardson, Texas 75082 USA 909 jmpolk@cisco.com 911 Intellectual Property Statement 913 The IETF takes no position regarding the validity or scope of any 914 Intellectual Property Rights or other rights that might be claimed 915 to pertain to the implementation or use of the technology described 916 in this document or the extent to which any license under such 917 rights might or might not be available; nor does it represent that 918 it has made any independent effort to identify any such rights. 919 Information on the procedures with respect to rights in RFC 920 documents can be found in BCP 78 and BCP 79. 922 Copies of IPR disclosures made to the IETF Secretariat and any 923 assurances of licenses to be made available, or the result of an 924 attempt made to obtain a general license or permission for the use 925 of such proprietary rights by implementers or users of this 926 specification can be obtained from the IETF on-line IPR repository 927 at http://www.ietf.org/ipr. 929 The IETF invites any interested party to bring to its attention any 930 copyrights, patents or patent applications, or other proprietary 931 rights that may cover technology that may be required to implement 932 this standard. Please address the information to the IETF at 933 ietf-ipr@ietf.org. 935 Disclaimer of Validity 937 This document and the information contained herein are provided on 938 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 939 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 940 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 941 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 942 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 943 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Copyright Statement 947 Copyright (C) The Internet Society (2005). This document is subject 948 to the rights, licenses and restrictions contained in BCP 78, and 949 except as set forth therein, the authors retain all their rights. 951 Acknowledgment 953 Funding for the RFC Editor function is currently provided by the 954 Internet Society.