Subject: RE: [Tsvwg] <rsvp-emeregncy> Appendix on "Emergency Flavors andcorresponding mechanisms"

From: "Fil Dickinson" <[email-masked]>
Date: Thu, 8 Jun 2006 12:19:18 +1000

I think it is a good idea to have this. Whether it is an appendix or a
reference document, I don't mind. 

I will ask my telephony folks where I live to provide this information.
If the concensus of opinion supports this approach, should I send it to
the list or to you directly? 

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Wednesday, 7 June 2006 8:42 PM
To: [email-masked]
Subject: [Tsvwg] <rsvp-emeregncy> Appendix on "Emergency Flavors
andcorresponding mechanisms"

Hello,

I suggested earlier that we add an Appendix to <rsvp-emergency> which
would provide examples of "flavors" of Emergency services and which
mechanisms could be used to implement those. The idea would be to
describe each flavor in very concise/simple terms (ie not a detailed
specification) and then just a bullet list of mechanisms that would be
invoked to realize those. 

Could we get feed-back on whether this is a good idea and we should try
include this in next rev?

Thanks

Francois

=========================
Below is possible set of examples of flavors that we could include in
the Appendix. It includes the "flavors" that were dicussed in recent
messages. We still need to turn this into I-D-like text, but this is the
sort of content I was thinking (ie very succinct).

If one wants to implement an emergency service purely based on Call
Queueing/Bumping, one can do that by:
	* using "Resource-Priority" in SIP
	* not using Admission-Priority in RSVP
	* not using Preemption in RSVP

If one wants to implement an emergency service based on Call
Queueing/Bumping and on "prioritised access to network resources", one
can do that by:
	* using "Resource-PrioriFrom [email-masked] Wed Jun 07 22:19:31 2006
Content-class: urn:content-classes:message
Subject: RE: [Tsvwg] <rsvp-emeregncy> Appendix on "Emergency Flavors 
	andcorresponding mechanisms"
Date: Thu, 8 Jun 2006 12:19:18 +1000
From: "Fil Dickinson" <[email-masked]>
To: "Francois Le Faucheur \(flefauch\)" <[email-masked]>, <[email-masked]>
Cc: 

I think it is a good idea to have this. Whether it is an appendix or a
reference document, I don't mind. 

I will ask my telephony folks where I live to provide this information.
If the concensus of opinion supports this approach, should I send it to
the list or to you directly? 

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Wednesday, 7 June 2006 8:42 PM
To: [email-masked]
Subject: [Tsvwg] <rsvp-emeregncy> Appendix on "Emergency Flavors
andcorresponding mechanisms"

Hello,

I suggested earlier that we add an Appendix to <rsvp-emergency> which
would provide examples of "flavors" of Emergency services and which
mechanisms could be used to implement those. The idea would be to
describe each flavor in very concise/simple terms (ie not a detailed
specification) and then just a bullet list of mechanisms that would be
invoked to realize those. 

Could we get feed-back on whether this is a good idea and we should try
include this in next rev?

Thanks

Francois

=========================
Below is possible set of examples of flavors that we could include in
the Appendix. It includes the "flavors" that were dicussed in recent
messages. We still need to turn this into I-D-like text, but this is the
sort of content I was thinking (ie very succinct).

If one wants to implement an emergency service purely based on Call
Queueing/Bumping, one can do that by:
	* using "Resource-Priority" in SIP
	* not using Admission-Priority in RSVP
	* not using Preemption in RSVP

If one wants to implement an emergency service based on Call
Queueing/Bumping and on "prioritised access to network resources", one
can do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP
	* not using Preemption in RSVP
This will not involve any preemption of session.
Different bandwidth allocation models can be used to offer different
"prioritised access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as well
as simple bypass of admission limits for emergency sessions.

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensures that (say)
"Emergency1" sessions can preempt "Emergency2" sessions but
non-emergency sessions are not affected by preemption, one can do that
by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP with
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with higher preemption priority for
Emergency1 than Emergency 2)

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensure that
"emergency" sessions can preempt regular sessions, one could do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP without
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with high preemption priority for
Emergency sessions)

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensure that
"emergency" sessions can partially preempt regular sessions (ie reduce
their reservation size), one could do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP without
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with high preemption priority for
Emergency sessions)
	* activate RFC4495 RSVP Bandwidth Reduction mechanisms

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Thu, 8 Jun 2006 09:37:42 +0200

Hi Fil,

I'd say post it on the list. 

Francois 

>> From: Fil Dickinson [mailto:[email-masked]] 
>> Sent: jeudi 8 juin 2006 04:19
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> Subject: RE: [Tsvwg] <rsvp-emeregncy> Appendix on "Emergency 
>> Flavors andcorresponding mechanisms"
>> 
>> Queueing,
>> Queueing,
>> Queueing,