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

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Mon, 5 Jun 2006 18:40:09 +0200

Hello,

<draft-lefaucheur-emergency-rsvp-01.txt> identified two open items. This
is to sollicit feed-back on resolution of the first one: Preemption
Scope.
Thanks

Francois, Ken, James

Requirement:
============
Quoting from <emergency-rsvp-01>:
"
It has been identified that some ETS emergency type sessions would need:
   - to benefit from elevated admission priority
   - to be able to preempt other ETS emergency type sessions (the ones
with lower preemption priorities) 
   - to not be able to preempt non-emergency sessions.
One approach to address this requirement is to add a new Flag in the
Preemption Priority Policy Element in order to reduce the scope of the
RSVP preemption mechanism to emergency sessions. Feedback is sought on
this requirement and potential solution. This will be addressed further
in next revisions of this document. 
"

Proposed Resolution:
====================
After more discussions, we propose to include the flag inside the
"Admission Priority" Policy Element.
The "Admission Priority" description would be changed to something like:

"
The format of Admission Priority policy element is as follows:

      +-------------+-------------+-------------+-------------+
      |     Length                | P-Type = ADMISSION_PRI    |
      +-------------+-------------+-------------+-------------+
      | Flags       | M. Strategy | Error Code  | Reserved    |
      +-------------+-------------+-------------+-------------+
      | Rvd    | Pri|            Reserved                     |
      +---------------------------+---------------------------+

...<clip>

Flags: 8 bits

       0x01 = Reduced_Preemption_Scope
		 * When the Reduced_Preemption_Scope flag is on, in case
a Preemption policy element is signaled for this reservation, the
preemption MUST be enforced ONLY against other reservations which have
an elevated admission priority (i.e. which have also been signaled with
an Admission Priority policy element). The preemption MUST NOT be
enforced against other reservations which do not have an elevated
admission priority (i.e. which have been signaled without an Admission
Priority policy element). As an example, this flag can be used to
realize a policy where some "emergency" sessions need to be able to
preempt some other "emergency" sessions but where non-emergency sessions
must not be subject to preemption.
		* When the Reduced_Preemption_Scope flag is off, in case
a Preemption policy element is signaled for this reservation, the
preemption MUST be enforced against any other reservation regardless of
its admission priority.
		* Note that when a Preemption policy element is not
signaled for this reservation, the Reduced_Preemption_Scope flag is
irrelevant and this session MUST NOT preempt any other session
regardless of its admission priority.

       Other flags: Reserved (MUST be set to zero on transmit and
ignored on receive)

...<clip>

"

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 5 Jun 2006 13:03:45 -0400

You MIGHT want to consider something based on the mechanism used in 3GPP
for eMLPP.

In eMLPP (enhanced MLPP), each set up message  has 3 indicators
-Queuing Allowed Indicator
-Preemption Capability Indicator
-Preemption Vulnerability Indicator

The Queuing Allowed Indicator simply says whether or not the request can
queue for available resources (1 if it may queue, 0 if it may not).

The Preemption Capability Indicator says whether the request can pre-empt
(1 if it may pre-empt if the conditions are met, 0 if it may never
pre-empt) existing calls  which are
-in the same service domain
-of lower priority
- have the Preemption Vulnerabililty Indicator set to 1.

The Preemption Vulnerability Indicator says whether the call can be
pre-empted (1 if it may be pre-empted if the conditions are met, 0 if it
may never be preempted) by a call request which is
-in the same service domain,
-of higher priority
-has the  Preemption Capability Indicator set to 1.

In a GETS-like system, all calls would have
-Queuing Allowed Indicator  set to 1
-Preemption Capability Indicator set to 0
-Preemption Vulnerability Indicator set to 0

In a DOD MLPP-like system, all calls would have
-Queuing Allowed Indicator set to 0
-Preemption Capability Indicator set to 1
-Preemption Vulnerability Indicator set to 1
(calls of the highest priority could have Preemption Vulnerability
Indicator set to 0, since they may never be pre-empted.  Calls of the
lowest priority could have Preemption Capability Indicator  set to 0, since
there are no lower priority calls to pre-empt.)

There are, of course, all sorts of other combinations possible.

 Setting  non-emergency calls to 0,0,0 means they would never queue, and
would never pre-empt or be pre-empted.

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

             "Francois Le                                                  
             Faucheur                                                      
             \(flefauch\)"                                              To 
             <[email-masked]         <[email-masked]>                    
             om>                                                        cc 
                                                                           
             06/05/2006 12:40                                      Subject 
             PM                        [Tsvwg]                             
                                       <draft-lefaucheur-emergency-rsvp> : 
                                       Preemption scope                    

                                                                           

Hello,

Francois, Ken, James

Requirement:
============

Proposed Resolution:
====================

"

...<clip>

Flags: 8 bits

                          * When the Reduced_Preemption_Scope flag is on,
in case
                         * When the Reduced_Preemption_Scope flag is off,
in case
                         * Note that when a Preemption policy element is
not

...<clip>

"

---

From: ken carlberg <[email-masked]>
Date: Mon, 5 Jun 2006 15:02:49 -0400

Janet,

Thanks for your feedback.  I don't think the "queuing allowed"  
indicator has an appropriate corresponding element at the level of  
RSVP.  This may be something that would be accomplished (and state  
maintained) above RSVP and Francois and I have tossed around the idea  
of an accompanying BCP or other draft that goes beyond <draft- 
lefaucheur-emergency-rsvp>.

As for the notion of a Preemption Capability & Preemption  
Vulnerability indicator, it seems to me that RFC-3181, Signaled  
Preemption Priority Policy Element, would seem to be more of a fit --  
at least in regards to eMLPP with its use of a Preemption Priority  
and Defending Priority fields.

Francois can correct me, but I think what he was stating in his  
original message was whether having a simple binary flag condition  
was satisfactory to indicate that other reservations made by the  
extension for emergency services may be preempted or not.  If they  
are, the means of how this is done and the conditions by which they  
occur would be above RSVP.

-ken

On Jun 5, 2006, at 1:03 PM, Janet P Gunn wrote:

> ---------------------------------------------------------------------- 
> ---------------------------------------------------------------------- 
> ------------------------------------
>
> ---------------------------------------------------------------------- 
> ---------------------------------------------------------------------- 
> ------------------------------------
>
>
>
>
>
>              "Francois Le
>              Faucheur
>              \(flefauch 
> \)"                                              To
>              06/05/2006 12:40                                       
> Subject

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Mon, 5 Jun 2006 14:17:44 -0500

Hello,

Preemption is NEVER allowed for ETS calls/sessions in public networks.
This needs to be corrected.

Cheers,

Martin 

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Monday, June 05, 2006 12:40 PM
To: [email-masked]
Subject: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope

Hello,

Francois, Ken, James

Requirement:
============

Proposed Resolution:
====================

"

...<clip>

Flags: 8 bits

...<clip>

"

---

From: ken carlberg <[email-masked]>
Date: Mon, 5 Jun 2006 16:33:11 -0400

I'm curious.  Let's take the example of WPS and its priority levels.   
If during call attempts all resources have been used by WPS.4 (Public  
Services/Utilities) then does the subsequent attempted call attempt  
of WPS.1 (Executive Leadership & Policy Makers) get rejected?  Or  
does WPS.1 preempt one of the WPS.4 attempted calls?  Keeping in mind  
that all of these are call attempts versus calls that have been  
established.  (Janet, could you clue me in?)

In the US, ETS-type calls that have been established definitely  
cannot be preempted (so I'll qualify your statement just a bit).  And  
in this case, Francois' statement in his original message would  
apply....

... meaning that the Preemption policy element would NOT be signaled  
in the US (at least presumably by those providers offering VoIP  
service to the US public).

Furthermore, in Section 3.1 of the draft states:

    Note that the Admission Priority Policy Element does NOT indicate
    that this RSVP reservation is to preempt any call. If a priority
    session justifies both admission priority and preemption priority,
    the corresponding RSVP reservation needs to carry both an Admission
    Priority Policy Element and a Preemption Priority Policy Element.

Keeping in mind that <draft-lefaucheur-emergency-rsvp> *only* defines  
the Admission Priority Policy Element and NOT the Preemption Priority  
Policy Element (defined in RFC-3181).

So I am unclear as to what exactly needs to be corrected.

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 5 Jun 2006 17:03:34 -0400

Ken,

WPS is based on queueing, not preemption.

If a WPS call attempt arrives, and all resources are in use, the call
attempt QUEUES, it does NOT pre-empt an established call.

A WPS.1 (high priority WPS) call attempt can NOT preempt ANY established
call (whether WPS or not).

HOWEVER, if a WPS.1 call attempt tries to queue (because all the resources
are busy) but finds the queue is FULL (finite queue size limit (typically
5) has been reached), the system will check to see if there are any lower
priority WPS call attempts in the queue.  If there are, one of the lowest
priority WPS call attempts will be "bumped" from the  queue (and rejected)
so the higher priority WPS call attempt can get into the queue.

This is NOT preemption, because no established calls are affected,  But the
higher priority call attempt DOES "displace" a lower priority call attempt
IN THE QUEUE.

Because of the FCC restrictions on preemption, we are very careful to call
it "bumping", and not "preemption" when referring to the queue discipline.

Ken, do you have a copy of the IRs?  It is spelled out in detail there.

Hope that helps,

Janet

                                                                           
             ken carlberg                                                  
             <[email-masked]                                             
             .uk>                                                       To 
                                       "Dolly, Martin C, ALABS"            
             06/05/2006 04:33          <[email-masked]>                    
             PM                                                         cc 
                                       [email-masked], [email-masked],     
                                       [email-masked]                     
                                                                   Subject 
                                       Re: [Tsvwg]                         
                                       <draft-lefaucheur-emergency-rsvp> : 
                                       Preemption scope                    

                                                                           

                         * Note that when a Preemption policy element is
not
             signaled for this reservation, the Reduced_Preemption_Scope
flag is
             irrelevant and this session MUST NOT preempt any other session
             regardless of its admission priority.

-ken

in case
in case
not

---

From: ken carlberg <[email-masked]>
Date: Mon, 5 Jun 2006 17:17:41 -0400

Janet,

Many thanks for the clarification on how WPS operates.  Where its  
needed, we'll swap the terms "preemption" with "displaced" in the  
next version of the draft.  Note that RSVP won't know the current  
state of the call (be it attempt or established), which is why I  
mentioned in a previous email the probable need for a companion  
document to the current <draft-lefaucheur-emergency-rsvp> draft.

as for the IRs, if you mean the Industry Requirements for WPS, no, I  
don't believe I have a copy, but I'll dig one up.

thanks,

-ken

On Jun 5, 2006, at 5:03 PM, Janet P Gunn wrote:

>              .uk>                                                      
>   To

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Jun 2006 15:21:07 -0600

Martin,

Dolly, Martin C, ALABS wrote:                (Mon, 05 Jun 2006 14:17:44)
> 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: "James M. Polk" <[email-masked]>
Date: Tue, 06 Jun 2006 12:24:56 -0500

>This needs to be corrected.

Saying this with my chair hat on:

This one topic has been given such attention in some discussions I've been 
around over the past few years both in the IETF, and outside our virtual 
walls, that I believe for an IETF doc to make such a claim, it will have to 
provide a reference to the law stating this function is 
illegal.  Otherwise, one reading this could take this statement as the 
authority proving this (non) capability is forbidden, thus validating 
something that doesn't really exist.

I know of no such law preventing preemption in the public networks in the 
US.  I know Canada allows preemption in the same type of Telco switches 
that are installed in the US.  I think GSM has the ability to preempt 
specified.

I pretty much understand preemption is not an active function within the US 
carrier's networks, but that's a configuration issue, not a development 
issue.  This document here will be Standards Track if it moves to RFC, 
making it a implementor's document, not a BCP or INFO that an SP would use 
as advice for creating a service.

That said, discussing the ability to preempt within a doc can always have 
an explicit caveat stating it "...is not recommended as a default 
configuration to have preemption enabled; and that this is up to local 
policy".

Having a law referencable is good too, if someone can provide that law to 
reference.

>Martin

Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Tue, 6 Jun 2006 12:56:54 -0500

James,

Preemption is NOT allowed in USA public networks. There is not a public
switching system in the USA that allows preemption. I will try to get a
reference.

Janet summarized the wireless scenarios, which is not preemption either.

As far as I know Canada does not have ETS (yet?).

Cheers,

Martin 

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 1:25 PM
To: Dolly, Martin C, ALABS; Francois Le Faucheur (flefauch);
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption
scope

This one topic has been given such attention in some discussions I've
been 
around over the past few years both in the IETF, and outside our virtual

walls, that I believe for an IETF doc to make such a claim, it will have
to 

I know of no such law preventing preemption in the public networks in
the 
US.  I know Canada allows preemption in the same type of Telco switches 
that are installed in the US.  I think GSM has the ability to preempt 
specified.

I pretty much understand preemption is not an active function within the
US 
carrier's networks, but that's a configuration issue, not a development 
issue.  This document here will be Standards Track if it moves to RFC, 
making it a implementor's document, not a BCP or INFO that an SP would
use 
as advice for creating a service.

That said, discussing the ability to preempt within a doc can always
have 
an explicit caveat stating it "...is not recommended as a default 
configuration to have preemption enabled; and that this is up to local 
policy".

Having a law referencable is good too, if someone can provide that law
to 
reference.

Cheers,
James
IETF TSVWG co-chair

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2006 12:15:28 -0600

Martin,

Dolly, Martin C, ALABS wrote:                  (Tue, 06 Jun 2006 10:33:11)
>
> ETS is not 911. ETS, as in Emergency Telecommunications Service.

Yes, and what I was saying was that such "disaster relief" calls have been
able to preempt E911 calls in Canada in some jurisdictions for some time
(almost 20 years since I put it in).

--brian

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

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Tue, 6 Jun 2006 13:18:47 -0500

TDR is the international service, where ETS is a national service (e.g.,
USA) 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 2:15 PM
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:                  (Tue, 06 Jun 2006
10:33:11)
> ETS is not 911. ETS, as in Emergency Telecommunications Service.

Yes, and what I was saying was that such "disaster relief" calls have
been
able to preempt E911 calls in Canada in some jurisdictions for some time
(almost 20 years since I put it in).

--brian

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

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Jun 2006 14:20:07 -0400

With regard to GSM-
The GSM (3gpp) specs include eMLPP, which DOES permit preemption.  However,
every US carrier we have been in contact with has interpreted the legal
situation to mean that they would NOT "turn on" the preemption features of
eMLPP in any US network.

As far as I know, it has not been turned on in any non-US PUBLIC network
either.  The one network where I know it HAS been turned on is  a PRIVATE
(railroad company) network in Europe.

Janet

                                                                           
             "James M. Polk"                                               
             <[email-masked]                                             
             >                                                          To 
                                       "Dolly, Martin C, ALABS"            
             06/06/2006 01:24          <[email-masked]>, "Francois Le      
             PM                        Faucheur \(flefauch\)"              
                                       <[email-masked]>,               
                                       <[email-masked]>                    
                                                                        cc 
                                       [email-masked], [email-masked]     
                                                                   Subject 
                                       RE: [Tsvwg]                         
                                       <draft-lefaucheur-emergency-rsvp> : 
                                       Preemption  scope                   

                                                                           

Cheers,
James
IETF TSVWG co-chair

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2006 12:21:53 -0600

Martin,

Dolly, Martin C, ALABS wrote:                    (Tue, 06 Jun 2006 13:18:47)
> TDR is the international service, where ETS is a national service (e.g.,

As a general rule Canada adopts US terminology over International
terminology in telecommunications, or make ups their own terms.

It is likely do to the proximity and friendly nature of the two
countries.

--brian

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

---

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

Communications Act of 1934,  Section 202(a)

Janet

                                                                           
             "James M. Polk"                                               
             <[email-masked]                                             
                                       "Dolly, Martin C, ALABS"            

                                                                           

Cheers,
James
IETF TSVWG co-chair

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 6 Jun 2006 14:13:29 -0400

James,

I will send you a copy of the R &O.  But here is the relevant citation.

I was wrong about the year, it is the "Communications Act of 1934".

The R&O permitting WPS (called PAS here)  says (in E)

22.   Section 202(a) of the Communications Act prohibits common carriers
from making any unjust or unreasonable discrimination in charges,
practices, classifications, facilities or services, from giving an undue or
unreasonable preference or advantage, or from subjecting any person, class
of persons or locality to any undue or unreasonable prejudice or
disadvantage.   Providing NSEP users with priority access during
emergencies might be considered a violation of these provisions and thus,
as we stated in the Second NPRM, it would be prudent to provide
specifically for limitations on liability under Section 202 of the
Communications Act.   Most commenters agreed with our tentative conclusion
that carriers offering PAS should receive some protection from liability
for violations of the Communications Act.   They further argue that without
such protection it is unlikely that carriers will offer PAS.
23.   We hold that providing priority access to authorized NSEP users in
accordance with our  PAS rules will be prima facie lawful under the
Communications Act and not unreasonable discrimination or an unreasonable
preference.   Therefore, any person filing a complaint will bear a heavy
burden of proof to show that a provider's actions that are related to its
PAS offering violate Section 202 of the Communications Act.   Initially, we
note that Section 202 of the Communications Act does not prevent carriers
from treating users differently; it bars only unjust or unreasonable
discrimination.   Carriers may differentiate among users so long as there
is a valid reason for doing so.  In the case of PAS, in emergency
situations, non-NSEP customers simply are not "similarly situated" with
NSEP personnel.  NSEP personnel are attempting to save and protect lives
and property, restore order, and restore critical services.  The ability of
NSEP personnel to communicate without delays during emergencies is
essential.  Similarly, within the NSEP community, the levels of priority
set by the PAS rules will delineate different types of customers which the
carrier may appropriately treat differently in this regard.  For example,
NCS's proposed priority levels provide for federal defense personnel to
receive priority over utility managers.  In a national emergency the
ability of federal personnel to access the wireless channels is imperative.
A CMRS provider therefore does not violate the Communications Act by
offering federal users the ability to achieve that access.
24.   Several parties ask that we also provide immunity from all types of
liability.   Parties worry, for example, that a carrier might face
potential liability for the inability of a user (particularly one
attempting to make an emergency call) to receive an open channel and
complete a call because the carrier has provided priority access to NSEP
personnel.   In the paragraph above, we conclude that providing PAS in
accordance with the PAS rules will be prima facie lawful under the
Communications Act.  We therefore limit our discussion here to carriers’
possible liability under state law.  We first note that since parties filed
their comments in this proceeding, Congress has enacted the Wireless
Communications and Public Safety Act of 1999 which provides wireless
carriers with the same protection from liability under Federal and State
law as wireline carriers, especially with regard to emergency calls.   This
Act should satisfy most of the parties’ concerns.  Second, we note that
CMRS carriers that choose to offer PAS may limit their liability by
incorporating appropriate provisions in the contracts with their users.
"

Janet

                                                                           
             "James M. Polk"                                               
             <[email-masked]                                             
                                       "Dolly, Martin C, ALABS"            

                                                                           

Cheers,
James
IETF TSVWG co-chair

---

From: ken carlberg <[email-masked]>
Date: Tue, 6 Jun 2006 19:19:29 -0400

just to note, the following RFC documents contain text on Emergency  
Telecommunications Service (ETS).

rfc-3487:  Requirements for Resource Priority Mechanisms for the
                   Session Initiation Protocol (SIP)
rfc-3689:  General Requirements for
                   Emergency Telecommunication Service (ETS)
rfc-3690:  IP Telephony Requirements for
                   Emergency Telecommunication Service (ETS)
rfc-4190:  Framework for Supporting Emergency Telecommunications
                   Service (ETS) in IP Telephony
rfc-4375:  Emergency Telecommunications Services (ETS) Requirements
                    for a Single Administrative Domain
rfc-4412:  Communications Resource Priority for
                    the Session Initiation Protocol (SIP)
rfc-4542: Implementing an Emergency Telecommunications Service (ETS) for
                  Real-Time Services in the Internet Protocol Suite

I've cc'ed the IEPREP list since nearly all of the above documents  
came from that group.  I kindly ask that if people choose to continue  
the discussion on ETS, please drop the TSVWG from the cc list and  
continue it on IEPREP.

-ken

On Jun 6, 2006, at 2:21 PM, Brian F. G. Bidulock wrote:

> 13:18:47)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2006 17:53:28 -0600

ken,

ken carlberg wrote:                              (Tue, 06 Jun 2006 19:19:29)
> the discussion on ETS, please drop the TSVWG from the cc list and  

Well, RFC 4190 section 4.3 explicitly scopes out network traffic
engineering in support of ETS.  Also, from the ieprep charter:

 "It is out of scope for this working group to do protocol or protocol
  feature development."

Whereas, as you should known as an author,
draft-lefaucheur-emergency-rsvp-01 clearly indicates:

 "This document specifies RSVP extensions necessary for supporting such
  admission priority capabilities."

I am confused by your request to drop tsvwg from the cc list: Is not
RSVP protocol and protocol feature development within the tsvwg charter?

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Jun 2006 17:58:24 -0600

Janet,

Janet P Gunn wrote:                           (Tue, 06 Jun 2006 14:13:29)
> The R&O permitting WPS (called PAS here)  says (in E)

Were you meaning to say that the quoted passage precludes preemption?
(IANAL but it sounds to me like it is saying something quite different.)

Do you have a passage that explicitly precludes preemption?

--brian

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 6 Jun 2006 20:19:51 -0400

Brian,

> RSVP protocol and protocol feature development within the tsvwg  

Yes, I quite agree with the point you make in your above question.   
On the other hand, in my view a discussion about ETS itself is  
informational in nature, and that is what I wished to move (if  
necessary) to IEPREP.

I may have been too pessimistic in feeling that any continued  
discussion on ETS will become protracted and philosophical in  
nature.  I'll respect your wishes and leave tsvwg on.  In any case,  
hopefully pointing out the previous RFCs has been helpful for you.

cheers,

-ken

---

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

Sorry, I should have given more context.

This bit:
"22.  Section 202(a) of the Communications Act prohibits common carriers
from making any unjust or unreasonable discrimination in charges,
practices, classifications, facilities or services, from giving an undue or
unreasonable preference or advantage, or from subjecting any person, class
of persons or locality to any undue or unreasonable prejudice or
disadvantage.   Providing NSEP users with priority access during
emergencies might be considered a violation of these provisions and thus,
as we stated in the Second NPRM, it would be prudent to provide
specifically for limitations on liability under Section 202 of the
Communications Act.   Most commenters agreed with our tentative conclusion
that carriers offering PAS should receive some protection from liability
for violations of the Communications Act.   They further argue that without
such protection it is unlikely that carriers will offer PAS. "
1- Summarizes the section of the 1934 Communications act that prevents
carriers from giving "unreasonable preference or advantage".
2- Agrees with the submitted comments  that, without specific protection
from the FCC, PAS (which is basically queueing for radio channels) "could
be considered a violation of these provisions." And that, without such
protection it is unlikely that carriers will offer PAS. "

 The logical next step, which I didn't explicitly state, is that, if simply
queuing for a radio channel is considered "unreasonable preference or
advantage", then preemption, which is much more disruptive to the
"non-preferred" user, would also be considered "unreasonable preference or
advantage", and be contrary to the act.

The next bit starts off:
"23.  We hold that providing priority access to authorized NSEP users in
accordance with our  PAS rules will be prima facie lawful under the
Communications Act and not unreasonable discrimination or an unreasonable
preference."

This is the statement that protects the carriers if they get sued.   The
only way that the carriers would be willing to offer a preemption based
service would be if the FCC made a similar statement saying that
"preemption is prima facie lawful".

However, since the document makes very clear (in some sections I didn't
quote in my earlier post, but will quote now) that PAS does NOT include
preemption, it is a logical deduction that the FCC does not intend to state
that  "preemption is lawful".

Here are some of the references to preemption elsewhere in the document:
"PAS will allow authorized NSEP users in emergencies to gain access to the
next available wireless channel; priority calls would not, however, preempt
calls in progress.  "
"Priority calls would not preempt calls in progress,  nor would PAS
guarantee the completion of the priority call. "
"PAS provides the means for NSEP telecommunications users to obtain
priority access to available radio channels when necessary to initiate
emergency calls.  It does not preempt calls in progress and is to be used
during situations when CMRS network congestion is blocking NSEP call
attempts.  "

It also says explicitly "Our reasoning and conclusions set forth above do
not necessarily extend to other priority schemes "

I agree it would be a whole lot cleaner if there was somewhere that
explicitly SAID "preemption is not permitted".

But it is not that hard to "read between the lines" the IMPLICIT assumption
that "preemption is not permitted".

>From a practical matter, the fact that all the carriers BELIEVE "preemption
is not permitted" is sufficient ( at least until the FCC comes out with an
explicit statement) to ensure that preemption is not going to be offered by
the US carriers.

Sorry for not being clearer the first time.

Janet

                                                                           
             "Brian F. G.                                                  
             Bidulock"                                                     
             <bidulock@openss7                                          To 
             .org>                     Janet P Gunn/FED/CSC@CSC            
                                                                        cc 
             06/06/2006 07:58          "James M. Polk" <[email-masked]>, 
             PM                        [email-masked]                      
                                                                   Subject 
                                       Re: [Tsvwg]                         
             Please respond to         <draft-lefaucheur-emergency-rsvp> : 
             bidulock@openss7.         Preemption  scope                   
                    org                                                    

Janet,

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Jun 2006 00:28:51 -0600

Janet,

Janet P Gunn wrote:                        (Tue, 06 Jun 2006 22:33:35)
> explicit statement) to ensure that preemption is not going to be offered by

Thank you for taking the time to humor me with the details!  I think
that I have some understanding of the predicament now from your
excellent explanation.

Nevertheless, does not calling preemption "unlawful" beg the question?

Also, it appears that the preemption that was excluded from PAS was
preempting "established" calls.  Do you recall there anywhere being a
definition of when a call is "established"?

Barring such a definition, one, I suppose, could assume that once
participants in the call have exchanged greetings that it is
established.  Because RSVP call admission is performed long before this
point, there is a period of time after RSVP admits the call until the
RTP channel is established and operational that RSVP could "preempt"
the admission without preempting an "established" call.

In fact, during a disaster which has stimulated a mass calling event,
this is a critical period.

> not necessarily extend to other priority schemes "

Would not that also exclude, preemption or not, any scheme not precisely
PAS?

ETS for RSVP is certainly not precisely PAS.

--brian

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

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 9 Jun 2006 09:15:43 -0400

In line

"Brian F. G. Bidulock" <[email-masked]> wrote on 06/07/2006 02:28:51

> definition of when a call is "established"?

I don't know about a "definition", but, from a practical perspective, in an
SS7 network, you could consider it when the destination returns an ISUP
Answer Message (ANM).  In an IP network, you could consider it to be when
"bearer packets" (as opposed to "signaling packets") start being
transmitted.
> ETS for RSVP is certainly not precisely PAS.

Absolutely.

There is another "waiver" for the (landline) GETS features, but since i
wasn't actively involved when it came out, it isn't sitting on my hard
drive.  There would need to be another "waiver" for any substantially new
"special treatment".  But the point is that everyone involved anticipates
getting such a new waiver, as long as the new "special treatment" does not
include  "preemption".