< draft-ietf-sipping-reason-header-for-preemption-03.txt		draft-ietf-sipping-reason-header-for-preemption-04.txt >
	SIPPING Working Group James M. Polk		SIPPING Working Group James M. Polk
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	Expires: January 17th, 2006		Expires: March 12th, 2006
	Extending the Session Initiation Protocol		Extending the Session Initiation Protocol
	Reason Header for Preemption Events		Reason Header for Preemption Events
	draft-ietf-sipping-reason-header-for-preemption-03.txt		draft-ietf-sipping-reason-header-for-preemption-04.txt
	July 17th, 2005		Sept 12th, 2005
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Months and may be updated, replaced, or obsoleted by other documents		Months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 17th, 2006.		This Internet-Draft will expire on March 12th, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document proposes an IANA Registration extension to the Session		This document proposes an IANA Registration extension to the Session
	Initiation Protocol (SIP) Reason Header to include in a BYE Method		Initiation Protocol (SIP) Reason Header to include in a BYE Method
	Request as a result of a session preemption event, either at a user		Request as a result of a session preemption event, either at a user
	agent (UA), or somewhere in the network using RSVP. This document		agent (UA), or somewhere in the network involving a reservation-
	does not attempt to address routers failing in the packet path; but		based protocol such as RSVP or NSIS. This document does not attempt
	a deliberate event of tearing down a flow between UAs, and informing		to address routers failing in the packet path; but a deliberate
	the terminated UA(s) with an indication of what occurred.		event of tearing down a flow between UAs, and informing the
			terminated UA(s) with an indication of what occurred.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . 4
	2. Access Preemption Events . . . . . . . . . . . . . . . . . . 4		2. Access Preemption Events . . . . . . . . . . . . . . . . . . 4
	2.1 Effects of Preemption at the User Agent . . . . . . . . 5		2.1 Effects of Preemption at the User Agent . . . . . . . . 5
	2.2 Reason Header Requirements for		2.2 Reason Header Requirements for
	Access Preemption Events . . . . . . . . . . . . . . . 5		Access Preemption Events . . . . . . . . . . . . . . . 6
	3. Network Preemption Events . . . . . . . . . . . . . . . . . 6		3. Network Preemption Events . . . . . . . . . . . . . . . . . 6
	3.1 Reason Header Requirements for		3.1 Reason Header Requirements for
	Network Preemption Events . . . . . . . . . . . . . . . 8		Network Preemption Events . . . . . . . . . . . . . . . 9
	4. Including a Hybrid Infrastructure . . . . . . . . . . . . . 9		4. Including a Hybrid Infrastructure . . . . . . . . . . . . . 9
	4.1 Hybrid Infrastructure Requirements . . . . . . . . . . 9		4.1 Hybrid Infrastructure Requirements . . . . . . . . . . 10
	5. Preemption Reason Header Cause Codes and Semantics . . . . . 10		5. Preemption Reason Header Cause Codes and Semantics . . . . . 10
	5.1 Access Preemption Event Reason Code . . . . . . . . . . 10		5.1 Access Preemption Event Reason Code . . . . . . . . . . 11
	5.1.1 Access Preemption Event Call Flow . . . . . . . . . . 11		5.1.1 Access Preemption Event Call Flow . . . . . . . . . . 11
	5.2 Network Preemption Events Reason Code . . . . . . . . . 12		5.2 Network Preemption Event Reason Code . . . . . . . . . 12
	5.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12		5.2.1 Network Preemption Event Call Flow . . . . . . . . . . 12
	5.3 Generic Preemption Event Reason Code . . . . . . . . . 13		5.3 Generic Preemption Event Reason Code . . . . . . . . . 13
	5.4 Non-IP Preemption Event Reason Code . . . . . . . . . . 13		5.4 Non-IP Preemption Event Reason Code . . . . . . . . . . 14
	5.4.1 Non-IP Preemption Event Call Flow . . . . . . . . . . 14		5.4.1 Non-IP Preemption Event Call Flow . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
	8. Contributions . . . . . . . . . . . . . . . . . . . . . . . 17		8. Contributions . . . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18
	10. Normative References . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Author Information . . . . . . . . . . . . . . . . . . . . . 18		Author Information . . . . . . . . . . . . . . . . . . . . . 19
	Intellectual Property and Copyright Statements . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . 19
	1. Introduction		1. Introduction
	With the introduction of the SIP Resource-Priority (R-P) header [4],		With the introduction of the SIP Resource-Priority (R-P) header [4],
	there became the possibility of sessions being torn down for		there became the possibility of sessions being torn down for
	(scarce) resource reasons; meaning there weren't enough resources		(scarce) resource reasons; meaning there weren't enough resources
	for a particular session to continue. Certain domains will		for a particular session to continue. Certain domains will
	implement this mechanism where resources may become constrained		implement this mechanism where resources may become constrained
	either at the user agent (UA), or at congested router interfaces		either at the user agent (UA), or at congested router interfaces
	where more important sessions are to be completed at the expense of		where more important sessions are to be completed at the expense of
	less important sessions. Which sessions are more or less important		less important sessions. Which sessions are more or less important
	than others will not be discussed here. What is proposed here is		than others will not be discussed here. What is proposed here is
	extending SIP to synchronize SIP elements as to why a preemption		extending SIP to synchronize SIP elements as to why a preemption
	event occurred and which type of preemption event occurred, as		event occurred and which type of preemption event occurred, as
	viewed by the element that performed the preemption of a session.		viewed by the element that performed the preemption of a session.
	The Reason Header is an application layer feedback mechanism to		The SIP Reason Header is an application layer feedback mechanism to
	synchronize SIP elements of events; the particular event explained		synchronize SIP elements of events; the particular event explained
	here deals with preemption of a session. Q.850 [5] provides an		here deals with preemption of a session. Q.850 [5] provides an
	indication for preemption (cause=8) and for preemption "circuit		indication for preemption (cause=8) and for preemption "circuit
	reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP		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		because IP has no concept of circuits. Some domains wish to
	differentiate appropriate IP reasons for preemption of sessions and		differentiate appropriate IP reasons for preemption of sessions and
	topologically where the preemption event occurred. No other means		topologically where the preemption event occurred. No other means
	exists today to give this feedback as to why a session was torn down		exists today to give this feedback as to why a session was torn down
	for preemption grounds.		for preemption grounds.
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	session request message with a valid R-P value that is		session request message with a valid R-P value that is
	higher than the one associated with the currently active		higher than the one associated with the currently active
	session at that UA. The UA must discontinue the existing		session at that UA. The UA must discontinue the existing
	session in order to accept the new one (based on local		session in order to accept the new one (based on local
	policy of some domains).		policy of some domains).
	Network Preemption Event - this is when a network element - such		Network Preemption Event - this is when a network element - such
	as a router - reaches capacity on a particular interface		as a router - reaches capacity on a particular interface
	and has the ability to statefully choose which session(s)		and has the ability to statefully choose which session(s)
	will remain active when a new session/reservation is		will remain active when a new session/reservation is
	signaled for under the parameters of RSVP in [3] that		signaled for under the parameters outlined in SIP
	would otherwise overload that interface (perhaps adversely		Preconditions in [3] that would otherwise overload that
	affecting all sessions). In this case, the router must		interface (perhaps adversely affecting all sessions). In
	terminate one or more reservations of lower priority in		this case, the router must terminate one or more
	order to allow this higher priority reservation access to		reservations of lower priority in order to allow this
	the requested amount of bandwidth (based on local policy		higher priority reservation access to the requested amount
	of some domains).		of bandwidth (based on local policy of some domains).
	This document will cover the semantics for these two cases, and		This document will cover the semantics for these two cases, and
	request IANA registration of the new protocol value "Preemption" for		request IANA registration of the new protocol value "Preemption" for
	the Reason Header field with 4 cause values for the above preemption		the Reason Header field with 4 cause values for the above preemption
	conditions. Additionally, this document will create a new IANA		conditions. Additionally, this document will create a new IANA
	Registry for reason-text strings that are not currently defined		Registry for reason-text strings that are not currently defined
	through existing SIP Response codes or Q.850 cause codes. This new		through existing SIP Response codes or Q.850 cause codes. This new
	Registry will be useful for future protocols used by the SIP Reason		Registry will be useful for future protocols used by the SIP Reason
	header.		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).
			To be clear, it should be noted 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		1.1 Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described		"OPTIONAL" in this document are to be interpreted as described
	in [6].		in [6].
	2. Access Preemption Events		2. Access Preemption Events
	As mentioned previously, Access Preemption Events (APE) occur at		As mentioned previously, Access Preemption Events (APE) occur at
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 46 ¶
	preemption event at the user agent to inform all		preemption event at the user agent to inform all
	relevant SIP entities, yet have the ability to		relevant SIP entities, yet have the ability to
	generalize this indication (based on local policy) to		generalize this indication (based on local policy) to
	the receiving UA such that this UA cannot display		the receiving UA such that this UA cannot display
	more information than the domain wants the user to		more information than the domain wants the user to
	see.		see.
	3. Network Preemption Events		3. Network Preemption Events
	Network Preemption Events (NPE) are those instances in which a		Network Preemption Events (NPE) are those instances in which a
	intermediate router between SIP elements preempts one or more		intermediate router between SIP user agents preempts one or more
	sessions at one of its interfaces to place a higher priority		sessions at one of its interfaces to place a higher priority
	session through that interface. Within RSVP, there exists a means to		session through that interface. Within RSVP, there exists a means to
	execute this functionality in [7]: ResvErr messages - which travel		execute this functionality in [7]: ResvErr messages - which travel
	downstream towards appropriate receivers. The ResvErr message has		downstream towards appropriate receivers. The ResvErr message has
	the ability to carry within it a code why a reservation is being		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.		torn down. The ResvErr does not travel upstream to the other UA.
	This document here proposes a SIP message be generated to		This document here proposes a SIP message be generated to
	synchronize all relevant SIP elements to this preemption event.		synchronize all relevant SIP elements to this preemption event,
	Creating another Reason value describing that a network element		including the upstream UA. Creating another Reason value describing
	preempted the session is necessary in certain domains.		that a network element preempted the session is necessary in certain
			domains.
	The following 2 diagrams (Figures 2 and 3) illustrate the network		Two diagrams (Figures 2 and 3) illustrate a network preemption
	preemption scenario:		scenario with RSVP. NSIS, not shown in examples here, can be
			imagined here from [8] with a NOTIFY error message indicating 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		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. This		(levels 1 and 2 are higher is this domain) and is accepted. This
	SIP signaling translated the Resource Priority value to an		SIP signaling translated the Resource Priority value to an
	appropriate RSVP priority level for that flow. The link between		appropriate RSVP priority level for that flow. The link between
	Router 1 and Router 2 became saturated with this session reservation		Router 1 and Router 2 became saturated with this session reservation
	between UA1 and UA2 (in this example).		between UA1 and UA2 (in this example).
	UA1 UA2		UA1 UA2
	\ /		\ /
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 43 ¶
	Figure 2. Network Diagram Scenario A		Figure 2. Network Diagram Scenario A
	After the session between UA1 and UA2 is established, UA3 invites		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		UA4 to a new session with an Resource Priority level of 2 (a higher
	priority than the current reservation between UA1 and UA2). Again,		priority than the current reservation between UA1 and UA2). Again,
	the priority value within the Resource-Priority header of this		the priority value within the Resource-Priority header of this
	INVITE is translated into an appropriate RSVP priority (that is also		INVITE is translated into an appropriate RSVP priority (that is also
	higher in relative priority to the UA1_UA2 session/RSVP flow). When		higher in relative priority to the UA1_UA2 session/RSVP flow). When
	this second (higher priority session) is signaled, one Path message		this second (higher priority session) is signaled, one Path message
	goes from UA3 to UA4, resulting in the Resv message going from UA4		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		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		capacity (at Int7 in Figure 5), Router 1 will (in this example) make
	the decision to preempt lower priority BW to ensure this higher		the decision, or will communicate with another network entity that
	priority session reservation is completed. A ResvErr message is		will make the decision to preempt lower priority BW to ensure this
	sent to UA2. The result is that UA2 will know that there has been a		higher priority session reservation is completed. A ResvErr message
	preemption event in a router (because the ResvErr message has a		is sent to UA2. The result is that UA2 will know that there has
	error code within it stating "preemption"), UA1 at this point will		been a preemption event in a router (because the ResvErr message has
			a error code within it stating "preemption"), UA1 at this point will
	not know anything of this preemption. If there are any SIP Proxies		not know anything of this preemption. If there are any SIP Proxies
	in between UAs 1 & 2(perhaps that inserted a Record-Route Header),		in between UAs 1 & 2 (perhaps that inserted a Record-Route Header),
	each will need to be informed also as to why this reservation was		each will need to be informed also as to why this reservation was
	torn down.		torn down.
	Figure 3 shows the call flow with Router 2 from Figure 2 included at		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		the RSVP layer sending the ResvErr message. A complete call flow
	including all UAs and Routers is not shown here for diagram		including all UAs and Routers is not shown here for diagram
	complexity reasons. The signaling between UA3 and UA4 is also not		complexity reasons. The complete signaling between UA3 and UA4 is
	included.		also not included.
	UA1 Rtr2 UA2		UA1 Rtr2 UA2
	| | |		| | |
	| INVITE (R-P:3) |		| INVITE with QoS Preconditions (R-P:3) |
	|------------------------------------------------->|		|------------------------------------------------->|
			| ******************************************** |
			| * - QoS Preconditions established UA1-UA2 * |
			| * - SIP signaling continues... * |
			| ******************************************** |
	| 200 OK |		| 200 OK |
	|<-------------------------------------------------|		|<-------------------------------------------------|
	| ACK |		| ACK |
	|------------------------------------------------->|		|------------------------------------------------->|
	| RTP |		| RTP |
	|<================================================>|		|<================================================>|
	| ******************************************** |		| ******************************************** |
	| * -UA3 sends INV to UA4 w/ RP:2; * |		| * -UA3 sends INV with QoS Preconditions * |
			| * to UA4 w/ RP:2; * |
	| * -Reservation set-up occurs between UA3 * |		| * -Reservation set-up occurs between UA3 * |
	| * and UA4 * |		| * and UA4 * |
	| * -Router 2 must preempt UA1-UA2 * |		| * -Router 2 in Figure 2 must preempt * |
			| * reservation between UA1 & UA2 * |
	| * ****************************************** |		| * ****************************************** |
	| |		| |
	| | ResvErr |		| | ResvErr |
	| |------------------------>|		| |------------------------>|
	| | |		| | |
	| |		| |
	| BYE (Reason : ? ) |		| BYE (Reason : ? ) |
	|<-------------------------------------------------|		|<-------------------------------------------------|
	| 200 OK |		| 200 OK |
	|------------------------------------------------->|		|------------------------------------------------->|
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 35 ¶
	This document defines the following new protocol value for the		This document defines the following new protocol value for the
	protocol field of the Reason header field in RFC 3326 [1]:		protocol field of the Reason header field in RFC 3326 [1]:
	Preemption: The cause parameter contains a preemption cause code		Preemption: The cause parameter contains a preemption cause code
	We define the following preemption cause codes:		We define the following preemption cause codes:
	Value Default Text Description		Value Default Text Description
	1 UA Preemption The session has been preempted by a UA		1 UA Preemption The session has been preempted by a UA
	2 RSVP Preemption The session preemption has been		2 Reserved Resources The session preemption has been
	initiated within the network via a		Preempted initiated within the network via a
	purposeful RSVP preemption occurrence,		purposeful RSVP preemption occurrence,
	and not a link error		and not a link error
	3 Generic Preemption This is a limited use preemption		3 Generic Preemption This is a limited use preemption
	indication to be used on the final leg		indication to be used on the final leg
	to the preempted UA to generalize the		to the preempted UA to generalize the
	event		event
	4 Non-IP Preemption The session preemption has occurred in		4 Non-IP Preemption The session preemption has occurred in
	a non-IP portion of the infrastructure		a non-IP portion of the infrastructure
	and this is the Reason cause code given		and this is the Reason cause code given
	by the SIP Gateway		by the SIP Gateway
	Example syntax is as follows for each of the above preemption types:		Example syntax is as follows for each of the above preemption types:
	Reason: preemption ;cause=1 ;text="UA Preemption"		Reason: preemption ;cause=1 ;text="UA Preemption"
	Reason: preemption ;cause=2 ;text="RSVP Preemption"		Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
	Reason: preemption ;cause=3 ;text="Generic Preemption"		Reason: preemption ;cause=3 ;text="Generic Preemption"
	Reason: preemption ;cause=4 ;text="Non-IP Preemption"		Reason: preemption ;cause=4 ;text="Non-IP Preemption"
	Sections 5.1, 5.2, 5.3 and 5.4 provide uses cases and extended		Sections 5.1, 5.2, 5.3 and 5.4 provide uses cases and extended
	definitions for the above four cause codes with message flow		definitions for the above four cause codes with message flow
	diagrams.		diagrams.
	5.1 Access Preemption Event Reason Code		5.1 Access Preemption Event Reason Code
	The more elaborate description of the Access Preemption Event		The more elaborate description of the Access Preemption Event
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, line 26 ¶
	higher priority call.		higher priority call.
	UA2 sends a BYE Request message with a Reason header with a value:		UA2 sends a BYE Request message with a Reason header with a value:
	UA Preemption. This will inform the far end UA (UA1), and all		UA Preemption. This will inform the far end UA (UA1), and all
	relevant SIP elements (for example: SIP Proxies). The cause code is		relevant SIP elements (for example: SIP Proxies). The cause code is
	unique to what is proposed in the RSVP Preemption Event for		unique to what is proposed in the RSVP Preemption Event for
	differentiation purposes.		differentiation purposes.
	5.2 Network Preemption Events Reason Code		5.2 Network Preemption Events Reason Code
	The more elaborate description of the RSVP Preemption Event		The more elaborate description of the Reserved Resources Preempted
	cause=2 is as follows:		Event cause=2 is as follows:
	A router has preempted a reservation flow and generated a ResvErr		A router has preempted a reservation flow and generated a
	(downstream). The (downstream) UA receiving the ResvErr message		reservation error message, a ResvErr traveling downstream in
	generates a BYE request towards the far side UA with a Reason		RSVP, a NOTIFY in NSIS. The UA receiving the preemption error
	Header with this value indicating that somewhere in between two		message generates a BYE request towards the far side UA with a
	or more UAs, a router has administratively preempted this session		Reason Header with this value indicating that somewhere in
			between two or more UAs, a router has administratively preempted
			this session.
	An example usage of this header value would be:		An example usage of this header value would be:
	Reason: Preemption :cause=2 ;text="RSVP Preemption"		Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"
	5.2.1 Network Preemption Event Call Flow		5.2.1 Network Preemption Event Call Flow
	The following diagram (Figure 6) replicates the call flow from		The following diagram (Figure 6) replicates the call flow from
	Figure 5 - but with an appropriate Reason value indication that was		Figure 5 - but with an appropriate Reason value indication that was
	proposed in section 4.2 above.		proposed in section 4.2 above.
	UA1 Rtr2 UA2		UA1 Rtr2 UA2
	| | |		| | |
	| INVITE (R-P:3) |		| INVITE with QoS Preconditions (R-P:3) |
	|---------------------------------------------------->|		|---------------------------------------------------->|
			| ******************************************** |
			| * - QoS Preconditions established UA1-UA2 * |
			| * - SIP signaling continues... * |
			| ******************************************** |
	| 200 OK |		| 200 OK |
	|<----------------------------------------------------|		|<----------------------------------------------------|
	| ACK |		| ACK |
	|---------------------------------------------------->|		|---------------------------------------------------->|
	| RTP |		| RTP |
	|<===================================================>|		|<===================================================>|
	| |		| ******************************************** |
	| *********************************************** |		| * -UA3 sends INV with QoS Preconditions * |
	| * -UA3 sends INV to UA4 w/ RP:2; * |		| * to UA4 w/ RP:2; * |
	| * -Reservation set-up occurs between UA3 * |		| * -Reservation set-up occurs between UA3 * |
	| * and UA4 * |		| * and UA4 * |
	| * -Router 2 must preempt UA1-UA2 * |		| * -Router 2 in Figure 2 must preempt * |
			| * reservation between UA1 & UA2 * |
	| * ********************************************* |		| * ********************************************* |
	| |		| |
	| | ResvErr |		| | ResvErr |
	| |------------------------>|		| |------------------------>|
	| | |		| | |
	| |		| |
	| BYE (Reason : Preemption ;cause=2 ; |		| BYE (Reason : Preemption ;cause=2 ; |
	| text="RSVP Preemption") |		| text="Reserved Resources Preempted") |
	|<----------------------------------------------------|		|<----------------------------------------------------|
	| 200 OK |		| 200 OK |
	|---------------------------------------------------->|		|---------------------------------------------------->|
	| |		| |
	Figure 6. Network Preemption with "RSVP Preemption"		Figure 6. Network Preemption with "Reserved Resources Preempted"
	Above is the call flow with Router 2 from Figure 2 included at the		Above is the call flow with Router 2 from Figure 2 included at the
	RSVP layer sending the Resv messages. A complete call flow		RSVP layer sending the Resv messages. A complete call flow
	including all UAs and Routers is not here for diagram complexity		including all UAs and Routers is not here for diagram complexity
	reasons. The signaling between UA3 and UA4 is also not included.		reasons. The signaling between UA3 and UA4 is also not included.
	Upon receipt of the ResvErr message with the preemption error code,		Upon receipt of the ResvErr message with the preemption error code,
	UA2 can now appropriately inform UA1 why this event occurred. This		UA2 can now appropriately inform UA1 why this event occurred. This
	BYE message will also inform all relevant SIP elements,		BYE message will also inform all relevant SIP elements,
	synchronizing them. The cause value is unique to that proposed in		synchronizing them. The cause value is unique to that proposed in
	skipping to change at page 15, line 51 ¶		skipping to change at page 16, line 26 ¶
	understanding, but deemed important enough to have their own		understanding, but deemed important enough to have their own
	Registry.		Registry.
	7.1 "Preemption" Namespace Registry		7.1 "Preemption" Namespace Registry
	RFC [XXXX} (this document) creates the new SIP "Reason Header" [1]		RFC [XXXX} (this document) creates the new SIP "Reason Header" [1]
	protocol namespace: "Preemption", with 4 defined cause codes:		protocol namespace: "Preemption", with 4 defined cause codes:
	In instances where this namespace is used to indicate preemption		In instances where this namespace is used to indicate preemption
	at a UA, the following syntax shall be used (the reason-text is a		at a UA, the following syntax shall be used (the reason-text is a
	default string, and is not mandatory):		default string, it is not mandatory, and may be different):
	Reason: preemption ;cause=1 ;text="UA Preemption"		Reason: preemption ;cause=1 ;text="UA Preemption"
	Section 5.1 of this document describes in detail the semantics		Section 5.1 of this document describes in detail the semantics
	of this cause code.		of this cause code.
	The default text above is part of a new IANA Registry for		The default text above is part of a new IANA Registry for
	default text strings for any new protocol namespace cause		default text strings for any new protocol namespace cause
	code. See section 7.2 below for the details.		code. See section 7.2 below for the details.
	In instances where this namespace is used to indicate preemption		In instances where this namespace is used to indicate preemption
	based on receipt of an RSVP ResvErr message at a SIP UA, the		based on receipt of an RSVP ResvErr message at a SIP UA, the
	following syntax shall be used (the reason-text is a default		following syntax shall be used (the reason-text is a default
	string, and is not mandatory):		string, it is not mandatory, and may be different):
	Reason: preemption ;cause=2 ;text="RSVP Preemption"		Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
	Section 5.2 of this document describes in detail the semantics		Section 5.2 of this document describes in detail the semantics
	of this cause code.		of this cause code.
	The default text above is part of a new IANA Registry for		The default text above is part of a new IANA Registry for
	default text strings for any new protocol namespace cause		default text strings for any new protocol namespace cause
	code. See section 7.2 below for the details.		code. See section 7.2 below for the details.
	In instances where this namespace is used to indicate a		In instances where this namespace is used to indicate a
	generalized preemption event to the destination UA from a Proxy		generalized preemption event to the destination UA from a Proxy
	that modifies the Reason value only during this last SIP hop		that modifies the Reason value only during this last SIP hop
	shall use the following syntax (the reason-text is a default		shall use the following syntax (the reason-text is a default
	string, and is not mandatory):		string, it is not mandatory, and may be different):
	Reason: preemption ;cause=3 ;text="Generic Preemption"		Reason: preemption ;cause=3 ;text="Generic Preemption"
	Section 5.3 of this document describes in detail the semantics		Section 5.3 of this document describes in detail the semantics
	of this cause code.		of this cause code.
	The default text above is part of a new IANA Registry for		The default text above is part of a new IANA Registry for
	default text strings for any new protocol namespace cause		default text strings for any new protocol namespace cause
	code. See section 7.2 below for the details.		code. See section 7.2 below for the details.
	In instances where this namespace is used to indicate preemption		In instances where this namespace is used to indicate preemption
	from a Non-IP portion of a call leg, a SIP Gateway shall use the		from a Non-IP portion of a call leg, a SIP Gateway shall use the
	following syntax to inform the SIP infrastructure of this event		following syntax to inform the SIP infrastructure of this event
	with (the reason-text is a default string, and is not mandatory):		with (the reason-text is a default string, it is not mandatory,
			and may be different):
	Reason: preemption ;cause=4 ;text=" Non-IP Preemption"		Reason: preemption ;cause=4 ;text=" Non-IP Preemption"
	Section 5.4 of this document describes in detail the semantics		Section 5.4 of this document describes in detail the semantics
	of this cause code.		of this cause code.
	The default text above is part of a new IANA Registry for		The default text above is part of a new IANA Registry for
	default text strings for any new protocol namespace cause		default text strings for any new protocol namespace cause
	code. See section 7.2 below for the details.		code. See section 7.2 below for the details.
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 45 ¶
	Below is the creation of a new IANA Registry for SIP Reason Header		Below is the creation of a new IANA Registry for SIP Reason Header
	reason-text strings, associated with their respective protocol type		reason-text strings, associated with their respective protocol type
	and Reason-param cause values. Per RFC 3326, the Reason-text string		and Reason-param cause values. Per RFC 3326, the Reason-text string
	is a quoted default string with only human understandability meant.		is a quoted default string with only human understandability meant.
	These strings can be changed by local policy.		These strings can be changed by local policy.
	Reason-		Reason-
	Protocol param Reason-Text Reference		Protocol param Reason-Text Reference
	-------- ------- ------------ ---------		-------- ------- ------------ ---------
	Preemption Cause=1 UA Preemption RFC XXXX [this document]		Preemption Cause=1 UA Preemption RFC XXXX [this document]
	Preemption Cause=2 RSVP Preemption RFC XXXX [this document]		Preemption Cause=2 Reserved Resources RFC XXXX [this document]
			Preempted
	Preemption Cause=3 Generic Preemption RFC XXXX [this document]		Preemption Cause=3 Generic Preemption RFC XXXX [this document]
	Preemption Cause=4 Non-IP Preemption RFC XXXX [this document]		Preemption Cause=4 Non-IP Preemption RFC XXXX [this document]
	8. Contributions		8. Contributions
	The following individuals contributed to this effort:		The following individuals contributed to this effort:
	Subhasri Dhesikan		Subhasri Dhesikan
	Gonzalo Camarillo		Gonzalo Camarillo
	Dave Oran		Dave Oran
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 48 ¶
	[5] ITU-T Recommendation Q.850 (1993)		[5] ITU-T Recommendation Q.850 (1993)
	[6] Bradner, S., "Key words for use in RFCs to indicate requirement		[6] Bradner, S., "Key words for use in RFCs to indicate requirement
	levels," BCP 14, RFC 2119, March 1997.		levels," BCP 14, RFC 2119, March 1997.
	[7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,		[7] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
	"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional		"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
	Specification", RFC 2205, September 1997		Specification", RFC 2205, September 1997
			10.1 Informative Reference
			[8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, " NSLP
			for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp, Sept
			2005, "work in progress"
	Author Information		Author Information
	James M. Polk		James M. Polk
	Cisco Systems		Cisco Systems
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082 USA		Richardson, Texas 75082 USA
	jmpolk@cisco.com		jmpolk@cisco.com
	Intellectual Property Statement		Intellectual Property Statement
End of changes. 46 change blocks.
	72 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/