Subject: RE: [Ieprep] Resource priority header

From: "Gunn, Janet NE" <[email-masked]>
Date: Wed, 22 May 2002 14:07:15 -0400

Ran,

The IEPREP charter says:
"The RFC may include identification of gaps in existing protocols and
requirements for use in new protocol or protocol feature design."

Janet
-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 1:08 PM
To: James M. Polk
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] Resource priority header

This WG explicitly SHOULD NOT be used to drive requirements onto
other WGs.  

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: [email-masked]
Date: Wed, 22 May 2002 14:32:21 EDT

In a message dated 5/22/02 1:08:43 PM Eastern Daylight Time, 
[email-masked] writes:

> other WGs.  That would violate IETF practices.  Individuals who have
> such proposals to change SIP should be making those proposals in
> the proper WG -- which is NOT here.
> 

Then where should we talk about requirements that might require a change to 
SIP? We couldn't deal with this issue in SIPPING?

Mike

---

From: [email-masked]
Date: Wed, 22 May 2002 14:36:32 EDT

In a message dated 5/22/02 11:09:42 AM Eastern Daylight Time, 
[email-masked] writes:

More replies inserted.

> Replies inserted in extract
> 
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, May 21, 2002 7:58 PM
>> To: [email-masked]
>> Subject: [Ieprep] Resource priority header
>> 
>> 
>> 
>> 
>> 
>> Don't forget to add "critic-ecp" to the text in the first paragraph of 
>> Annex A. With the addition of a new namespace for IPREP, it seems that the 
>> reference to using "critic-ecp" for GETS is incorrect. I'm sure that a 
>> GETS call can't take precedence over a "Flash-Override call in the dsn. I 
>> suggest replacing the final paragraph of Annex A with something like the 
>> following: 
>> [Gunn, Janet NE] 
>> ...
>>  
>> It depends what  you mean by "precedence."  If we assume that dsn priority 
>> works by pre-emption, and GETS works by queuing (I know I am 
>> oversimplifying), I can think of situations in which a queued call will 
>> get through, while a pre-emption capable call won't (as well as vice 
>> versa).
> 

[Mike Pierce]
If a dsn switch could apply queuing to a GETS call that it was trying to 
handle, it would certainly apply the same queuing to a FlashOverride call 
rather than blocking it. I'm sure the FlashOverride would always get 
"precedence" over any GETS call. I don't see any GETS call using the 
"critic-ecp" value, but maybe I'm wrong on its current use.
What I see happening is the GETS call (in a network supporting the "public" 
namespace) might interwork to the dsn with the interworking function 
providing a locally defined mapping of the "public" namespace" priority 
values to the values in the dsn. Maybe GETS "gets" mapped to Immediate. Or if 
there are multiple levels for GETS as in my proposal, they get mapped to 
multiple dsn levels.

> >> 
>> For the namespace q735, the defaults are another issue. The intention was 
>> to supported interworking with PSTN in which a SIP portion provides the 
>> link between 2 PSTN parts. This header then just provides the place to put 
>> the equivalent information from the ISUP messages. In this case, there 
>> would not be a default. It simply carries what it gets. At the end, when 
>> mapping back to ISUP, undefined values can not be mapped so may be 
>> defaulted to the lowest, but I don't see that this needs to be specified 
>> here. Perhaps a paragraph added to say something like: 
>> [Gunn, Janet NE] ...
>> 
> 

[Mike Pierce]
In the case of q735, the values are actually ordered but they may be carried 
through SIP as if they are not. It's the specific mapping function at the end 
that knows their meaning. One could say "defaults to 4" rather than "to the 
lowest".

> >> 
>> Since the intention of this namespace is to provide interworking between 
>> Q.735.3 entities without interpretation by the SIP proxies, no default in 
>> the case of no header or a header with an unknown priority value is 
>> required. Each MUST carry the header (or lack thereof) exactly as 
>> received. The mapping back to Q.735.3 requires that the namespace be 
>> correct and that unknown priority values be discarded or changed to the 
>> lowest defined. 
>> 
>> (Remember to change the definition so that "0" is the highest and "4" is 
>> the lowest.) 
>> 
>> For IEPREP, the job is to add the definition of the namespace. I believe 
>> that, while the namespace would be added to support the specific 
>> requirements of IEPREP, it is something that exists in a broader context - 
>> the public network. Within that network, the new value(s) for IEPREP are 
>> in addition to the case of "normal" calls, even if the normal calls never 
>> use the Resource-priority header. It seems necessary to actually define a 
>> "Normal" priority value, simply to be able to say that something defaults 
>> to it. 
>>  
>> [Gunn, Janet NE] Here you seem to be referring to "Normal" as a 
>> value/priority within the IEPREP namespace, but below you seem to be 
>> referring to "Normal" as a value within the "public_network" namespace.  I 
>> think I understand  why you want it in the former, but I am not sure why 
>> 
> 

[Mike Pierce}
Not sure of your point. I'm not proposing a separate IPEPREP namespace and 
"public" namespace. The "public" namespace needs to include priority levels 
for everything that is in that "space" : normal calls, 911 calls, and GETS 
calls.

> 
> >> 
>> Also, the idea has been raised before about the desire to have several 
>> values of priority for authorized emergency. (I mean ascending levels of 
>> priority, not labels that have no specific meaning.) 
>> 
>> Also, while 911 emergency type calls may be indicated by another means 
>> ("SOS"), it seems that there still is a need to include a priority level 
>> in this set for it. Otherwise, it is not straightforward to specify 
>> relative priority handling. 
>> 
>> Therefore, I would propose to add an Annex C as follows (where the actual 
>> name of the namespace is open for discussion): 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------------------------------------------------------------- 
>> C Namespace public_network 
>> 
>> The namespace "public_network" is registered here to be used by those 
>> public networks which support the emergency services defined in 
>> [IEPS/SOS/911/etc]. The namespace contains the following five priority 
>> values in ascending order: 
>> 
>> Normal (Although all normal calls are expected to not contain this header, 
>> the value is defined for completeness and to allow the specification of 
>> the default.) 
>> Emergency_public (Although public emergency calls may be indicated by 
>> other means, e.g., "SOS", this value is defined for completeness and to 
>> allow sufficient definition of its relationship to the higher priority 
>> levels.) 
>> Emergency_auth_1 (The assignment and use of this priority level is the 
>> responsibility of the network operator/telecommunications agency in the 
>> country, etc. 
>> Emergency_auth_2 " 
>> Emergency_auth_3 " 
>> 
>> Within a network which is expected to support only this one namespace, 
>> when the Resource-priority header is missing or is present but contains an 
>> unknown priority value, any procedures applied SHOULD be the same as if 
>> the lowest value (Normal) had been specified. When the Resource-priority 
>> header contains an unknown namespace, the receiver SHOULD reject the 
>> request in which the Resource-priority header was included. 
>> [Gunn, Janet NE] It seems to me that what to do with an unknown namespace 
>> is a policy issue which should be determined by the network "owner" in 
>> negotiation with its customers. 
> 

[Mike Pierce]
Yes, it certainly is policy. I would be happy not saying anything here about 
defaults or error treatments. Or take the other route and say "MAY do this or 
MAY do that."

> >> 
>> There was some discussion of interworking with GSM which, according to 
>> various descriptions has 7 or 15 priority levels. I understand from recent 
>> e-mails, that it has 7, as I included in my presentation. The 15 levels 
>> also referred to are not priority levels as Janet Gunn explained., but 
>> rather access classes which can be turned on or off by the service 
>> provider to allow certain groups of handsets to get service. As such, they 
>> are not "priority levels" and they do not need to be passed anywhere for 
>> interworking. The Resource-priority header would only need to deal with 
>> the actual 7 priority levels. Do we know what they are called and what 
>> interworking might be required?
>> [Gunn, Janet NE] The seven eMLPP priority levels are A,B, 0,1,2,3,4.  A 
>> and B are reserved for network internal use and are only used locally 
>> (within the domain of one MSC (mobile switching center)). 0,1,2,3,4 are  
>> offered for subscription, and can be applied globally (ie.e, outside the 
>> domain of the originating network).  The expected policy is that level 4 
>> is "normal", with no preferential treatment (I am not sure if this is 
>> specified in the standard, or just normal operating procedure).
> 

[Mike Pierce]
So I guess the levels 0 to 4 are just like MLPP and A and B are like the 
"critic-ecp". It seems that only the 0-4 would have to be considered in any 
interworking (which I suspect is also the case for "critic-ecp").

> 
> >> Within a given switch, the TREATMENT applied may depend on other 
>> characteristics besides eMLPP level.  For instance, it is considered good 
>> engineering to give preference, in assigning radio channels, to the 
>> handover of an existing call over the establishment of a new call.  
>> Therefore all the switches in a network MIGHT (and this is an internal 
>> policy issue) give a (eMLPP) level 3 "handoff" peferential treatment to a 
>> (eMLPP) level 1 "call initiation".  Within the switch, this is  reflected 
>> in what is referred to as an "08.08 priority level".  But since this 
>> information is not passed between switches, let alone between networks, it 
>> should not have any impact on IEPREP. "08.08" has 14 levels.
>>  
>> The 15 levels of access overload control apply to access to the control 
>> channels (signalling), not access to the traffic channels (bearer, 
>> content, voice) . 
>> 
> 
[Mike Pierce]
So we need to be sure everyone understands that these "08.08" 14 "levels" and 
the 15 "levels" for access control have nothing to do with the task at hand 
in IEPREP.

Thanks for the comments.

Mike