Internet Engineering Task Force James M. Polk Internet Draft Cisco Systems Expiration: July 8th, 2004 File: draft-ietf-sipping-reason-header-for-preemption-00.txt Extending the Session Initiation Protocol Reason Header for Preemption Events January 8th, 2004 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header [1] to include in a BYE Method Request [2] as a result of a session preemption event either at a user agent (UA), or somewhere in the network using RSVP [3]. This document does not attempt to address routers failing in the packet path; but a deliberate event of tearing down a flow between UAs. Polk [Page 1] Internet Draft Reason Header for Preemption Jan 8th, 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Changes from the Individual submission Version -00 . . . . 3 2. Access Preemption Events . . . . . . . . . . . . . . . . . . 4 2.1 Effects of Preemption at the User Agent . . . . . . . . . 6 2.2 Reason Header Requirements for Access Preemption Events . . . . . . . . 6 3. Network Preemption Events . . . . . . . . . . . . . . . . . 6 3.1 Reason Header Requirements for Network Preemption Events . . . . . . . . 9 4. Preemption Reason Header Cause Codes and Semantics . . . . . 9 4.1 Access Preemption Event Reason Code . . . . . . . . . . . 10 4.1.1 Access Preemption Event Call Flow . . . . . . . . . . . 10 4.2 Network Preemption Events Reason Code . . . . . . . . . . 11 4.2.1 Network Preemption Event Call Flow . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 7. Contributions . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 10. Author Information . . . . . . . . . . . . . . . . . . . . . 14 1.0 Introduction With the introduction of the Resource-Priority (R-P) header [4], there became the possibility of sessions being torn down for (scarce) resource reasons; meaning there weren't enough resources for a particular session to continue. Certain domains will implement this mechanism where resources may become constrained either at the user agent (UA), or for congested router interfaces where more important sessions are to be completed at the expense of less important sessions. Which sessions are more or less important than others will not be discussed here. What is proposed here is extending SIP to synchronize SIP elements as to why a preemption event occurred and which type of preemption event occurred, as viewed by the element that performed the preemption of a session. The Reason Header is an application layer feedback mechanism to synchronize SIP elements of events; the particular event explained here deals with preemption of a session. Q.850 [5] provides an indication for preemption (cause=8) and for preemption "circuit reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP because IP has no concept of circuits. Some domains wish to differentiate appropriate IP reasons for preemption of sessions and topologically where the preemption event occurred. No other means exists today to give this feedback as to why a session was torn down for preemption grounds. Polk [Page 2] Internet Draft Reason Header for Preemption Jan 8th, 2004 In the event that a session is terminated for a specific reason that can (or should) be shared with SIP Servers and UAs, the Reason Header [1] was created to be included in the BYE Request. This was not the only Method for this new Header; [1] also discusses the CANCEL Method usage. This document will define two use-cases in which new preemption Reason values are necessary: Access Preemption Event - this is when a UA receives a new SIP session request message with a valid R-P value that is higher than the one associated with the currently active session at that UA. The UA must discontinue the existing session in order to accept the new one (based on local policy of some domains). Network Preemption Event - this is when a network element - such as a router - reaches capacity on a particular interface and has the ability to statefully choose which sessions will remain active when a new session/reservation is signaled for under the parameters of RSVP in [3] that would otherwise overload that interface (perhaps adversely affecting all sessions). In this case, the router must terminate one or more reservations of lower priority in order to allow this higher priority reservation access to the requested amount of bandwidth (based on local policy of some domains). This document will cover the semantics for these two cases, and request IANA registration two new Reason Header values for the above preemption conditions. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [6]. 1.2 Changes from the Individual Submission Version -00 The following is a list of changes that have been made to this document from the Individual Submission Version -00: - Changed the proposed indication from a new token (as defined by RFC 3326) to proposing a new namespace ("preemption") with cause values for each type of occurrence; Polk [Page 3] Internet Draft Reason Header for Preemption Jan 8th, 2004 - Changed the notion of the "preempted_network" value - which could mean anything not at the endpoint to "RSVP_Preemption" because this more accurately reflects the signaling behavior of the type of event explained here; - Added the contributions and acknowledgements sections for those who have provided much help with this effort - Added an IPR section to this document; 2.0 Access Preemption Events As mentioned previously, Access Preemption Events (APE) occur at the user agent. It doesn't matter which UA in a unicast or multicast session this happens to (the UAC or UAS of a session). If local policy dictates in a particular domain, rules regarding the functionality of a UA, there must be a means by which that UA (not the user) informs the other UA(s) why a session was just torn down prematurely. The appropriate mechanism is to utilize the BYE Method. The user of the other far side UA will not understand why that session "just went away" without there being a means of informing the UA what occurred (if this event was purposeful), and why it occurred. Through this type of indication to the preempted UA, it can indicate to the user of that device appropriately. The rules within a domain surrounding informing of UA can be different than the rules of informing the user. Local policy should determine if the user should be informed of the specific reason. This indication in SIP will provide a means for the UA to react in a locally determined way if appropriate (play a certain tone or tone sequence, point towards a special announcement uri, etc). Polk [Page 4] Internet Draft Reason Header for Preemption Jan 8th, 2004 The following diagram (Figure 1) illustrates the scenario here. UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher is this domain). UA1 UA2 UA3 | | | | INVITE (R-P:3) | | |----------------------->| | | 200 OK | | |<-----------------------| | | ACK | | |----------------------->| | | RTP | | |<======================>| | | | INVITE (R-P:2) | | |<------------------------| | BYE (Reason : ? ) | | |<-----------------------| | | | 200 OK | | |------------------------>| | 200 OK | | |----------------------->| | | | ACK | | |<------------------------| | | RTP | | |<=======================>| | | | Figure 1. Access Preemption with obscure Reason After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session between UA1 and UA2). Local policy within this domain dictates that UA2 MUST preempt all existing calls of lower priority in order to accept a higher priority call. What Reason value could be inserted above to mean "preemption" at a UA? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any here is questionable because the session is already established. It is further complicated if there needs to be a difference in the Reason value for an Access versus a Network Preemption Event (which is a requirement here). The limits of Q.850 [5] have been stated previously in this document. Polk [Page 5] Internet Draft Reason Header for Preemption Jan 8th, 2004 2.1 Effects of Preemption at the User Agent If 2 UAs are in a session, and one UA must preempt that session to accept another session, a BYE Method message is the appropriate mechanism to perform this task. However, taking this a step further, if a UA is the common point of a 3-way (or more) adhoc conference participants and must preempt all sessions in that conference due to a higher priority session request received (that this UA must accept), then a BYE message MUST be sent to all UAs in that adhoc conference. 2.2 Reason Header Requirements for Access Preemption Events The following is a list of requirements for adding an appropriate Reason value for an Access Preemption Event (APE) as described above and shown in Figure 1: APE_REQ#1 - create a means by which one UA can inform another UA (within the same active session) that the active session between the two devices is being purposely preempted at one UA for a higher priority session request from another UA. APE_REQ#2 - create a means by which all relevant SIP elements can be informed of this Access Preemption Event to a specific session. For example: perhaps SIP Servers that have incorporated a Record- Route header into that session set-up. APE_REQ#3 - create a means of informing all participants in a adhoc conference that the primary UA (the mixer) has preempted the conference by accepting a higher priority session request. APE_REQ#4 - create a separate indication for the access preemption event than any used for a Network Preemption Event (described in the next section) in the session BYE message. 3.0 Network Preemption Events Network Preemption Events (NPE) are those instances in which a intermediate router between SIP elements preempts one or more session(s) at one of its interfaces to place a higher priority session through that interface. Within RSVP, there exists a means to execute this functionality in [7]: ResvErr messages - which travel downstream towards appropriate receivers. The ResvErr message has the ability to carry within it a code why a reservation is being Polk [Page 6] Internet Draft Reason Header for Preemption Jan 8th, 2004 torn down. The ResvErr does not travel upstream to the other UA. This document here proposes a SIP message be generated to synchronize all relevant SIP elements to this preemption event. Creating another Reason value describing that a network element preempted the session is necessary in certain domains. The following 2 diagrams (Figure 2 and 3) illustrate the network preemption scenario: UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher is this domain) and is accepted. The link between Router 1 and Router 2 became saturated with this session between UA1 and UA2 (in this example). UA1 UA2 \ / \ / +--------+ +--------+ | | | | | RTR1 | | RTR2 | | Int7-------Int5 | | | | | +--------+ +--------+ / \ / \ UA3 UA4 Figure 2. Network Diagram Scenario A After the session between UA1 and UA2 is established, UA3 invites UA4 to a new session with an Resource Priority level of 2 (a higher priority than the current session between UA1 and UA2). When this second (higher priority session) is signaled, the Path message goes from UA3 to UA4, resulting in the Resv message going from UA4 back to UA3. Because this link between the two routers is congested (at Interface 5 in Figure 2), Router 2 will (in this example) preempt lower priority BW to ensure this higher priority session is completed. A ResvErr message is sent to UA1. The result is that UA1 will know that there has been a preemption event in a router (because the ResvErr message has a error code within it stating "preemption"), UA2 at this point will not know anything other than its reservation went away. If there are any SIP Proxies in between the 2 UAs (perhaps that inserted a Record-Route Header), each will need to be informed also as to why this reservation was torn down. Figure 3 shows the call flow with Router 2 from Figure 2 included at the RSVP layer sending the ResvErr message. A complete call flow including all UAs and Routers is not shown here for diagram complexity reasons. The signaling between UA3 and UA4 is also not included. Polk [Page 7] Internet Draft Reason Header for Preemption Jan 8th, 2004 UA1 Rtr2 UA3 | | | | INVITE (R-P:3) | |------------------------------------------------->| | 200 OK | |<-------------------------------------------------| | ACK | |------------------------------------------------->| | RTP | |<================================================>| | ******************************************** | | * -UA3 sends INV to UA4 w/ RP:2; * | | * -Reservation set-up occurs between UA3 * | | * and UA4 * | | * -Router 2 must preempt UA1-UA2 * | | * ****************************************** | | | | ResvErr | | |<-----------------------| | | | | | | | BYE (Reason : ? ) | |------------------------------------------------->| | 200 OK | |<-------------------------------------------------| | | Figure 3. Network Preemption with obscure Reason What Reason value could be inserted above to mean "preemption at a router interface"? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any here is questionable because the session is already established. It is further complicated if there needs to be a difference in the Reason value for an Access versus a Network Preemption Event. The limits of Q.850 [5] have already been stated previously showing there is nothing in that spec to indicate a problem in an IP network. To generically state that all preemptions are equal is possible, but will not provide adequate information. Therefore, another Reason Header value is necessary to differentiate the APE from the NPE. Polk [Page 8] Internet Draft Reason Header for Preemption Jan 8th, 2004 3.1 Reason Header Requirements for Network Preemption Events The following are the requirements for the appropriate SIP signaling in reaction to a Network Preemption Event: NPE_REQ#1 - create a means of informing the far end UA that a Network Preemption Event has occurred in an intermediate router. NPE_REQ#2 - create a means by which all relevant SIP elements can be informed of a Network Preemption Event to a specific session. For example: perhaps SIP Servers that have incorporated a Record- Route header into that session set-up. NPE_REQ#3 - create a means of informing all participants in a adhoc conference that the primary UA (the mixer) has been preempted by a Network Preemption Event. NPE_REQ#4 - create a separate description of the Network Preemption Event relative to an Access Preemption Event in SIP. 4.0 Preemption Reason Header Cause Codes and Semantics We propose the following new protocol value for the protocol field of the Reason header field in RFC 3326 [1]: Preemption: The cause parameter contains a preemption cause code We define the following preemption cause codes: Value Default Text Description 1 UA_Preemption The session has been preempted by a UA 2 RSVP_Preemption The session preemption has been initiated within the network via a purposeful RSVP preemption occurrence, and not a link error Example syntax is as follows: Reason: preemption ;cause=1 ;text="UA_Preemption" Reason: preemption ;cause=2 ;text="RSVP_Preemption" Sections 4.1 and 4.2 provide use cases for the above two cause codes with message flow diagrams. Polk [Page 9] Internet Draft Reason Header for Preemption Jan 8th, 2004 4.1 Access Preemption Event Reason Code The more elaborate description of the Access Preemption Event cause=1 is as follows: A user agent in a session has purposely preempted a session and is informing the far end user agent, or user agents (if part of a conference), and SIP Proxies (if stateful of the session's transactions) An example usage of this header value would be: Reason: preemption ;cause=1 ;text="UA_Preemption" 4.1.1 Access Preemption Event Call Flow The following diagram (Figure 4) replicates the call flow from Figure 1 - but with an appropriate Reason value indication that was proposed in section 4.1 above: UA1 UA2 UA3 | | | | INVITE (R-P:3) | | |---------------------------------->| | | 200 OK | | |<----------------------------------| | | ACK | | |---------------------------------->| | | RTP | | |<=================================>| | | | INVITE (R-P:2) | | |<-------------------| | BYE (Reason: Preemption ; | | | cause=1 ;text="UA_Preemption") | | |<----------------------------------| | | | 200 OK | | |------------------->| | 200 OK | | |---------------------------------->| | | | ACK | | |<-------------------| | | RTP | | |<==================>| | | | Figure 4. Access Preemption with Reason : Preemption UA1 invites UA2 to a session with the Resource Priority level of 3 Polk [Page 10] Internet Draft Reason Header for Preemption Jan 8th, 2004 (levels 1 and 2 are higher is this domain). After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session to UA1). Local policy within this domain dictates that UA2 MUST preempt all existing calls of lower priority in order to accept a higher priority call. UA2 sends a BYE Request message with a Reason header with a value: preempted_UA. This will inform the far end UA (UA1), and all relevant SIP elements (for example: SIP Proxies). The cause code is unique to what is proposed in the RSVP Preemption Event for differentiation purposes. 4.2 Network Preemption Events Reason Code The more elaborate description of the RSVP Preemption Event cause=2 is as follows: A router has preempted a reservation flow and generated a ResvErr (downstream). The (downstream) UA receiving the ResvErr message generates a BYE request towards the far side UA with a Reason Header with this value indicating that somewhere in between two or more UAs, a layer 3/4 device (router) has administratively preempted this session An example usage of this header value would be: Reason: Preemption :cause=2 ;text="RSVP_Preemption" Polk [Page 11] Internet Draft Reason Header for Preemption Jan 8th, 2004 4.2.1 Network Preemption Event Call Flow The following diagram (Figure 5) replicates the call flow from Figure 3 - but with an appropriate Reason value indication that was proposed in section 4.2 above. UA1 Rtr2 UA3 | | | | INVITE (R-P:3) | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| | ACK | |---------------------------------------------------->| | RTP | |<===================================================>| | | | *********************************************** | | * -UA3 sends INV to UA4 w/ RP:2; * | | * -Reservation set-up occurs between UA3 * | | * and UA4 * | | * -Router 2 must preempt UA1-UA2 * | | * ********************************************* | | | | ResvErr | | |<--------------------------| | | | | | | | BYE (Reason : Preemption ;cause=1 ; | | text="RSVP_Preemption") | |---------------------------------------------------->| | 200 OK | |<----------------------------------------------------| | | Figure 5. Network Preemption with "RSVP_Preemption" Above is the call flow with Router 2 from Figure 2 included at the RSVP layer sending the Resv messages. A complete call flow including all UAs and Routers is not here for diagram complexity reasons. The signaling between UA3 and UA4 is also not included. Upon receipt of the ResvErr message with the preemption error code, UA1 can now appropriately inform UA2 why this event occurred. This BYE message will also inform all relevant SIP elements, synchronizing them. The cause value is unique to that proposed in section 4.1 for Access Preemption Events for differentiation purposes. Polk [Page 12] Internet Draft Reason Header for Preemption Jan 8th, 2004 5.0 Security Considerations Eavesdropping on this header field should not prevent proper operation of the SIP protocol, although some domains utilizing this mechanism for notifying and synchronizing SIP elements will likely want the integrity to be assured. 6.0 IANA Considerations RFC [XXXX} (this document) proposes the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 2 defined cause codes: In instances where this namespace is used to indicate preemption at a UA, the following syntax shall be used: Reason: preemption ;cause=1 ;text="UA_Preemption" Section 4.1 of this document describes in detail the semantics of this cause code. In instances where this namespace is used to indicate preemption based on receipt of an RSVP ResvErr message at a SIP UA, the following syntax shall be used: Reason: preemption ;cause=2 ;text="RSVP_Preemption" Section 4.2 of this document describes in detail the semantics of this cause code. Additional definitions of the preemption namespace cause codes shall be defined in Standards Track documents. 7.0 Contributions The following individuals contributed to this effort: Subhasri Dhesikan Gonzalo Camarillo Dave Oran The author thanks these individuals greatly for their aid in this effort. 8.0 Acknowledgements To Haluk Keskiner for providing a valued sanity check. To Dean Willis, Rohan Mahy and Allison Mankin for their belief in and backing of this effort. Polk [Page 13] Internet Draft Reason Header for Preemption Jan 8th, 2004 9.0 Normative References [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326 Reason Header, December 2002 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312 Preconditions, October 2002 [4] H. Schulzrinne, J. Polk, "Communications Resource-Priority Header in SIP", Internet Draft, work in progress, July 2003 [5] ITU-T Recommendation Q.850 (1993) [6] Bradner, S., "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, March 1997. [7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 10.0 Author Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA jmpolk@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification Polk [Page 14] Internet Draft Reason Header for Preemption Jan 8th, 2004 can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement "Copyright (C) The Internet Society (February 23rd, 2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." The Expiration date for this Internet Draft is: July 8th, 2004 Polk [Page 15]