Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Tue, 6 Jun 2006 11:10:36 +0200

Hello,

Thanks for the great info. Here is what I am hearing and where I think
we stand:

	* different "emergency" services have different requirements (in
different parts of the world, across different agencies, in the face of
different crisis situations,..)

	* these different requirements can be met by combining:
		* (i) different selected subset of functionality at the
"session" layer,
		* (ii) different selected subset of functionality at the
"network layer"

	* one does NOT have to systematically make use of all the
functionality available at the session layer and at the network layer.
One just has to pick the right subset of functionality at each layer to
implement the required "emergency" service.

	* One example of required functionality at the "session" layer
is the ability to "queue" calls (in some cases with the notion of
"bumping" from the queue). Another example is that "the request can be
given elevated priority for access to PSTN gateway resources, such as
trunk circuits."

	* The necessary extensions for implementing the required
"session layer functionality" (in the case where the session control
protocol is SIP) are already fully covered in RFC 4412. It defines the
SIP "Resource-Priority" header field which may be used by SIP user
agents to influence their treatment of SIP requests, including the
priority afforded to PSTN calls. For example, this can be used to
implement call "queueing" and associated "bumping".

	* the following functionality have been identified as required
from the network layer:
		* (N1) ability to provide "preferential" access to
network resources to elevate probablity of session establishment
		* (N2) (in some arguably less common cases) ability to
allow some form of preemption by emergency calls 
		* (N3) (in those arguably less common cases) ability to
ensure preemption does not "spill" on normal calls

	* <draft-lefaucheur-emergency-rsvp> aims at defining the nessary
extensions for implementing the required "network layer functionality"
(in the case where the network layer reservation protocol is RSVP). It
defines policy elements for implementing (N1). It turns out that RSVP
already has a Preemption policy element to support (N2). The objective
of the "Reduced_Preemption_Scope" flag is to support (N3).

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

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensures that (say)
"disaster relief" can preempt "emergency" calls, one can do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP with
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP

If one ever wanted to implement an emergency service based on Call
Queueing, on "prioritised access to network resources", and ensure that
"emergency" calls can preempt regular calls, one could do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP without
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP

Does the above summary capture the situation correctly?

Can anyone identify some "emergency" service which could not be
implemented with the proposed extensions?
What other functional capabilities would be required from the network
layer?
Can anyone recommend better ways to support/encode the proposed
extensions?

Thanks

Francois

>> -----Original Message-----
>> From: Brian F. G. Bidulock [mailto:[email-masked]] 
>> Sent: lundi 5 juin 2006 23:21
>> To: Dolly, Martin C, ALABS
>> Cc: Francois Le Faucheur (flefauch); [email-masked]; 
>> [email-masked]; [email-masked]
>> Subject: Re: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : 
>> Preemption scope
>> 
>> Martin,
>> 
>> Dolly, Martin C, ALABS wrote:                (Mon, 05 Jun 
>> 2006 14:17:44)
>> > 
>> > Preemption is NEVER allowed for ETS calls/sessions in 
>> public networks.
>> > This needs to be corrected.
>> 
>> This is not true for all public networks.
>> 
>> In Canada disaster relief organizations are sometimes permitted to
>> preempt emergency calls.  In Edmonton during a very rare 
>> tornado about
>> 20 years ago, a mass calling event to 911 impaired the ability of
>> municipal disaster relief to make calls.  (It didn't help that the
>> tornado ripped a central office switch out of the ground.)
>> 
>> Municipal disaster relief in Edmonton was since configured to preempt
>> the 911 calls that they were attempting to serve (using preemption
>> classes in DMS-100 switching equipment).  Although legality of such
>> things has always been sticky, it was mandated by the 
>> government and the
>> telco has no choice but to comply.  I don't know if this is still the
>> case, but at one time it was.
>> 
>> Perhaps the statement should be:
>> 
>>   Preemption is NEVER allowed for ETS calls/sessions in _US_ 
>> public networks.
>> 
>> --brian
>> 
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2006 04:36:35 -0600

Francois,

Francois Le Faucheur (flefauch) wrote:             (Tue, 06 Jun 2006 11:10:36)
> What other functional capabilities would be required from the network

In the telephone network E911 trunks are directly connected from the
local exchange to the E911 center (they are not routed between
switches).  Switch resources in the form of switching matrix junctors
are "dedicated" to E911 in SPC (Stored Program Control).  If there are
10 trunk members in the E911 trunk group, 10 calls can be established to
the E911 center from subscribers attached to the switch at any time.
That is 10 paths through the switch matrix (from any idle sub) are
permanently reserved for 911 calls.  Put another way: if the switch is
completely occuppied with normal calls, and additional normal calls are
being turned away (all trunks busy, delayed dial tone), still 10 911
calls can still be made to the 10 trunks.

I don't believe that priority queueing nor preemption adequately
describe that.  It is a dedicated resource.  Instead of queueing
with priority, it is more like reserving 10 (or whatever number of)
queue positions only to be used by 911 calls.  It is not preemption,
because only the reserved positions will be used.

Can RSVP protect and enforce a dedicated reserved network resource,
only to be used in the event of a 911 call?

Well, I suppose RSVP could, because it is just a protocol: perhaps a
better question would be: Is network equipment capable of performing
dedicated reservation of resources?

This reminds me of a discussion some time ago about performing best
effort over a reserved minimum (the best effort being normal calls and
the reserved minimum being 911 calls).  See the tsvwg thread
"[NSIS] interoperability problems between end-to-end ECN and edge-to-edge ECN"
from around 17 November 2005.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Jun 2006 09:54:34 -0400

I would just clarify this paragraph.

In circuit switching, "queuing" is a subset of "given elevated priority for
access to PSTN gateway resources, such as trunk circuits"  It isn't
"another example". (The other things, beyond queueing, that may be included
in "elevated priority" are exemption from certain network management
controls, and  alternate routing.  But queuing is the main thing.)

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Jun 2006 11:05:35 -0400

Francois,

You asked:
"Can anyone identify some "emergency" service which could not be
implemented with the proposed extensions?
What other functional capabilities would be required from the network
layer?"

One of the ideas that has been tossed around (without any firm resolution
pro or con, as far as I can tell) is a more discrete form of the "Priority
Bypass Model"

Under this  concept, if an ETS call needed to be set up, but all the
bandwidth has been allocated,  "the system" would reduce the bandwidth
allocation on a finite set of existing "calls", and reallocate that
bandwidth to the ETS call.  For instance, "the system" could  take 5% of
the bandwidth away from each of 20 existing "calls", and use that bandwidth
for the ETS calls.

There have been discussions (with no real resolution) as to whether this
would, or would not, be permitted by the FCC on  US "public" network- in
other words, whether it should be considered "preemption" or not.

 If I remember correctly, one of Joseph  Babiarz IDs hinted at this
behavior, with a variant on RSVP as the mechanism.

Anyway, it certainly isn't a current model for emergency calls, nor is
there a known requirement for it, but it IS an interesting idea that has
been considered.

Janet

                                                                           
             "Francois Le                                                  
             Faucheur                                                      
             \(flefauch\)"                                              To 
             <[email-masked]         <[email-masked]>, "Dolly,     
             om>                       Martin C, ALABS" <[email-masked]>   
                                                                        cc 
             06/06/2006 05:10          [email-masked], [email-masked],     
             AM                        [email-masked]                     
                                                                   Subject 
                                       RE: [Tsvwg]                         
                                       <draft-lefaucheur-emergency-rsvp> : 
                                       Preemption scope                    

                                                                           

Hello,

             * different "emergency" services have different requirements
(in
different parts of the world, across different agencies, in the face of
different crisis situations,..)

             * these different requirements can be met by combining:
                         * (i) different selected subset of functionality
at the
"session" layer,
                         * (ii) different selected subset of functionality
at the
"network layer"

             * the following functionality have been identified as required
from the network layer:
                         * (N1) ability to provide "preferential" access to
network resources to elevate probablity of session establishment
                         * (N2) (in some arguably less common cases)
ability to
allow some form of preemption by emergency calls
                         * (N3) (in those arguably less common cases)
ability to
ensure preemption does not "spill" on normal calls

             * <draft-lefaucheur-emergency-rsvp> aims at defining the
nessary

Thanks

Francois

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Jun 2006 11:42:17 -0400

I said

I take it back.
I was thinking of draft-ietf-tsvwg-rsvp-bw-reduction-00.txt,
A Resource Reservation Extension for the Reduction of
                  Bandwidth of a Reservation Flow

                        February 10th, 2005

 James Polk
 Subha Dhesikan
  Cisco Systems

 but it doesn't seem to have survived on line.

Janet