Request for Comments: 4411 Cisco Systems
Category: Standards Track February 2006
Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document proposes an IANA Registration extension to the Session
Initiation Protocol (SIP) Reason Header to be included in a BYE
Method Request as a result of a session preemption event, either at a
user agent (UA), or somewhere in the network involving a
reservation-based protocol such as the Resource ReSerVation Protocol
(RSVP) or Next Steps in Signaling (NSIS). This document does not
attempt to address routers failing in the packet path; instead, it
addresses a deliberate tear down of a flow between UAs, and informs
the terminated UA(s) with an indication of what occurred.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
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 .......................................7
3.1. Reason Header Requirements for Network Preemption Events ..10
4. Including a Hybrid Infrastructure ..............................10
4.1. Hybrid Infrastructure Requirements ........................11
5. Preemption Reason Header Cause Codes and Semantics .............11
5.1. Access Preemption Event Reason Code .......................12
5.1.1. Access Preemption Event Call Flow ..................12
5.2. Network Preemption Events Reason Code .....................14
5.2.1. Network Preemption Event Call Flow .................15
5.3. Generic Preemption Event Reason Code ......................16
5.4. Non-IP Preemption Event Reason Code .......................16
5.4.1. Non-IP Preemption Event Call Flow ..................17
6. Security Considerations ........................................17
7. IANA Considerations ............................................17
7.1. "Preemption" Namespace Registry ...........................18
7.2. Default Reason-Text IANA Registry for the SIP
Reason Header .............................................20
8. Contributions ..................................................20
9. Acknowledgements ...............................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
1. Introduction
With the introduction of the SIP 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 at 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 a SIP [2] extension
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 SIP 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,
as IP has no concept of circuits. Some domains wish to differentiate
appropriate IP reasons for preemption of sessions and to indicate
topologically where the preemption event occurred. No other means
exists today to give feedback as to why a session was torn down on
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 sharing dialog,
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 (according to 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 session(s) will
remain active when a new session/reservation is signaled for
under the parameters outlined in SIP Preconditions per [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 (according to local policy
of some domains).
This document will cover the semantics for these two cases and
request IANA registration of the new protocol value "Preemption" for
the Reason Header field, with 4 cause values for the above preemption
conditions. Additionally, this document will create a new IANA
Registry for reason-text strings that are not currently defined
through existing SIP Response codes or Q.850 cause codes. This new
Registry will be useful for future protocols used by the SIP Reason
header.
This document will emphasize an existing SIP RFC [3] as the starting
point for network preemption events. RFC 3312 set rules surrounding
SIP interaction using a reservation protocol for QoS preconditions,
using RSVP as the example protocol. That effort did not preclude
other preconditions or future protocol work from becoming a means of
preconditions. NSIS is a new reservation protocol effort that
specifies a preemption operation similar to RSVP’s ResvErr message
involving the NSIS NOTIFY message in [8] with a Transient error code
0x04000005 (Resources Pre-empted).
Note that SIP itself does not cause RSVP or NSIS reservation
signaling to start or end. That operation is part of a separate API
within each UA.
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].
2. Access Preemption Events
As mentioned previously, Access Preemption Events (APE) occur at the
user agent. It does not 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 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 of what
occurred (if this event was purposeful). 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 the UA to be informed can be
different from the rules for 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, cause the UA’s
visual display to do something, etc.).
Figure 1 illustrates the scenario. UA1 invites UA2 to a session with
the Resource Priority level of 3 (levels 1 and 2 are higher is this
domain, and the namespace element is not necessary for this
discussion).
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 of these 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.
It should be possible to configure UAs receiving a preemption
indication to indicate to the user that no particular type of
preemption occurred. There are some domains that might prefer their
users to remain unaware of the specifics of network behavior. This
should not ever prevent a known preemption indication from being sent
in a BYE from a UA.
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) ad hoc conference
and must preempt all sessions in that conference due to receipt of a
higher-priority session request (that this UA must accept), then a
BYE message must be sent to all UAs in that ad hoc 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 need to be informed of this
occurrence.
APE_REQ#3 - create a means of informing all participants in an ad
hoc 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 the one used for a Network Preemption Event
(described in the next section) in the session BYE
message.
APE_REQ#5 - create a means to generate a specific indication of a
preemption event at the user agent to inform all
relevant SIP entities, yet have the ability to
generalize this indication (based on local policy) to
the receiving UA such that this UA cannot display more
information than the domain wants the user to see.
3. Network Preemption Events
Network Preemption Events (NPE) are instances in which an
intermediate router between SIP user agents preempts one or more
sessions at one of its interfaces to place a higher-priority session
through that interface. Within RSVP, there exists a means to execute
this functionality per [7]: ResvErr messages, which travel downstream
towards appropriate receivers. The ResvErr message has the ability
to carry within it a code indicating why a reservation is being torn
down. The ResvErr does not travel upstream to the other UA. This
document proposes that a SIP message be generated to synchronize all
relevant SIP elements to this preemption event, including the
upstream UA. Creating another Reason value describing that a network
element preempted the session is necessary in certain domains.
Figures 2 and 3 illustrate a network preemption scenario with RSVP.
NSIS, not shown in examples here, can be imagined from [8] with a
NOTIFY error message indicating that a reservation has been preempted
with the Transient ERROR_SPEC 0x04000005. SIP behavior will be
identical using either reservation protocol.
UA1 invites UA2 to a session with the Resource Priority level of 3
(levels 1 and 2 are higher in this domain) and is accepted. This SIP
signaling translated the Resource Priority value to an appropriate
RSVP priority level for that flow. The link between Router 1 and
Router 2 became saturated with this session reservation 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 a Resource Priority level of 2 (a higher
priority than the current reservation between UA1 and UA2). Again,
the priority value within the Resource-Priority header of this INVITE
is translated into an appropriate RSVP priority (that is also higher
in relative priority to the UA1_UA2 session/RSVP flow). When this
second, higher-priority session is signaled, one 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 at capacity (at
Int7 in Figure 5), Router 1 will (in this example) make the decision
or will communicate with another network entity that will make the
decision to preempt lower-priority BW to ensure that this higher-
priority session reservation is completed. A ResvErr message is sent
to UA2. The result is that UA2 will know that there has been a
preemption event in a router (because the ResvErr message has a error
code within it, stating "preemption"). At this point, UA1 will not
know anything of this preemption. If there are any SIP Proxies
between UAs 1 and 2 (perhaps that inserted a Record-Route Header),
each will also need to be informed 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 complete signaling between UA3 and UA4 is
also not included.
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<-------------------------------------------------|
| ACK |
|------------------------------------------------->|
| RTP |
|<================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ****************************************** |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : ? ) |
|<-------------------------------------------------|
| 200 OK |
|------------------------------------------------->|