[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                           James M. Polk
Internet Draft                                            Cisco Systems
Expiration: April 8th, 2004
File: draft-polk-sipping-reason-header-for-preemption-00.txt





               Extending the Session Initiation Protocol
             Reason Header to account for Preemption Events

                          October 8th, 2003



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 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         Preemption in Reason Header        Oct 8th, 2003


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
        1.1 Conventions  . . . . . . . . . . . . . . . . . . . . . .  3
   2.   Access Preemption Events . . . . . . . . . . . . . . . . . .  3
        2.1  Effects of Preemption at the User Agent . . . . . . . .  5
        2.2  Reason Header Requirements for
                           Access Preemption Events  . . . . . . . .  5
   3.   Network Preemption Events  . . . . . . . . . . . . . . . . .  5
        3.1  Reason Header Requirements for
                           Network Preemption Events . . . . . . . .  8
   4.   Proposed Reason Header Values and Descriptions . . . . . . .  8
        4.1 Access Preemption Event Reason Value . . . . . . . . . .  9
        4.1.1 Access Preemption Event Call Flow  . . . . . . . . . . 10
        4.2 Network Preemption Events Reason Value . . . . . . . . . 11
        4.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12
   5.   Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 13
   7.   Acknowledgements   . . . . . . . . . . . . . . . . . . . . . 13
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.   Author Information . . . . . . . . . . . . . . . . . . . . . 14
   10.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 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 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 will be proposed here is extending
   SIP to synchronize SIP elements as to why a preemption event
   occurred and which type of 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.  No other means exists today to give
   this feedback as to why a session was torn down for preemption
   grounds.

   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 reason for this new Header; [1] also discusses the
   CANCEL Method Request.



Polk                                                           [Page 2]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003


   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 value for
   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 [5].


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.


Polk                                                           [Page 3]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003


   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"?
   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).







Polk                                                           [Page 4]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

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 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 [6]: ResvErr messages - which travel
   downstream towards appropriate receivers.  The ResvErr message has



Polk                                                           [Page 5]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

   the ability to carry within it a code why a reservation is being
   torn down.  The ResvErr does not travel upstream to the other UA.
   This document here proposes that 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.


   The following 2 diagrams (Figure 2 and 3) illustrate the network
   preemption scenario:

          UA1                                  UA2
             \                                /
              \                              /
               +--------+          +--------+
               |        |          |        |
               | RTR1   |          |  RTR2  |
               |       Int7-------Int5      |
               |        |          |        |
               +--------+          +--------+
              /                              \
             /                                \
          UA3                                  UA4

             Figure 2. Network Diagram Scenario A


   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).  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, Router 2
   will (in this example) preempt lower priority BW to ensure this
   higher priority session is completed.  The congestion point is in
   Router 2, interface 5 (in figure 2).  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 will not know
   anything other than its reservation went away.  If there is 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.

   In Figure 3 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


Polk                                                           [Page 6]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003


   reasons.  The signaling between UA3 and UA4 is also not included.



   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"?
   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.

   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 7]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

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 Proposed Reason Header Values and Descriptions

   RFC 3326 [1] defines the format of the header as follows:

   Reason           = "Reason" HCOLON reason-value *(COMMA reason-value)
   reason-value     = protocol *(SEMI reason-params)
   protocol         = "SIP" / "Q.850" / token
   reason-params    = protocol-cause / reason-text
                       / reason-extension
   protocol-cause   = "cause" EQUAL cause
   cause            = 1*DIGIT
   reason-text      = "text" EQUAL quoted-string
   reason-extension = generic-param

   The following are currently the only defined values in the protocol
   field in [1]:

      SIP: The cause parameter contains a SIP status code.

      Q.850: The cause parameter contains an ITU-T Q.850 cause value
           in decimal representation.







Polk                                                           [Page 8]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

4.1 Access Preemption Event Reason Value

   The following Reason Header value is proposed for cases of Access
   Preemption Events:

   Reason           = "Reason" HCOLON reason-value *(COMMA reason-value)
   reason-value     = protocol *(SEMI reason-params)
   protocol         = "SIP" / "Q.850" / token
   token            = preempted_UA

   with the following "token" value being proposed in this document for
   addition to the IANA Registry under possible Reason Values:

      preempted_UA : a user agent in a session has 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)

   This token was chosen because there is no SIP (or other Standards
   Body recognized) cause code that replicates the meaning of a
   existing session intentionally preempted at the user agent.

   An example usage of this header value would be:


      Reason: preempted_UA ;text="user agent preemption"


   This effort is open to the idea of registering a 400 or 500 level
   error code just for this, but it seems excessive at this time.
   A 37X level warning code can also be created - but it is not
   apparent that this is necessary.  Comments regarding this document
   will determine if creating new a new code number is a better course
   of action than the above token name.



















Polk                                                           [Page 9]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

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 : preempted_UA)|                         |
    |<--------------------------|                         |
    |                           |         200 OK          |
    |                           |------------------------>|
    |         200 OK            |                         |
    |-------------------------->|                         |
    |                           |          ACK            |
    |                           |<------------------------|
    |                           |          RTP            |
    |                           |<=======================>|
    |                           |                         |

     Figure 4. Access Preemption with Reason : Preempted_UA

   UA1 invites UA2 to a session with the Resource Priority level of 3
   (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 token name
   "preempted_UA" is unique to what is proposed in the Network
   Preemption Event.







Polk                                                          [Page 10]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

4.2 Network Preemption Events Reason Value

   The following Reason Header value is proposed for cases of Network
   Preemption Events:

   Reason           = "Reason" HCOLON reason-value *(COMMA reason-value)
   reason-value     = protocol *(SEMI reason-params)
   protocol         = "SIP" / "Q.850" / token
   token            = preempted_network

   with the following "token" value being proposed in this documents
   for addition to the IANA Registry under possible Reason Values:

      preempted_network : 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 the network a layer
                3/4 device (router) has preempted this session

   This token was chosen because there is no SIP (or other Standards
   Body recognized) cause code that replicates the meaning of a
   existing session as a RSVP flow intentionally preempted by an
   intermediate router within the network between UAs.

   An example usage of this header value would be:


     Reason: preempted_network ;text="session preempted within network"


   This effort is open to the idea of registering a 400 or 500 level
   error code just for this, but it seems excessive at this time.
   A 37X level warning code can also be created - but it is not
   apparent that this is necessary.  Comments regarding this document
   will determine if creating new a new code number is a better course
   of action than the above token name.
















Polk                                                          [Page 11]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

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 : preempted_Network)           |
    |------------------------------------------------->|
    |                              200 OK              |
    |<-------------------------------------------------|
    |                                                  |

       Figure 5. Network Preemption with obscure Reason

   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 token name is unique to that proposed in
   section 4.1 for Access Preemption Events.






Polk                                                          [Page 12]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

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

   This document defines a new SIP header field values for the "Reason
   Header" from RFC 3326 [1].  Two new token values are to be IANA
   registered based on this document.


    Token value            Defined in section of this document:
    -----------            -----------------------------------

    preempted_UA                section 4.1

    preempted_network           section 4.2


   There is no protocol name or cause value associated with these token
   Values.


7.0 Acknowledgements

   Your name here


8.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





Polk                                                          [Page 13]


Internet Draft         Preemption in Reason Header        Oct 8th, 2003

 [5] Bradner, S., "Key words for use in RFCs to indicate requirement
     levels," BCP 14, RFC 2119, March 1997.

 [6] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
     Specification", RFC 2205, September 1997


9.0 Author Information

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, Texas 75082 USA
   jmpolk@cisco.com


10.  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:


April 8th, 2004

Polk                                                          [Page 14]