Subject: RE: [Ieprep] Resource priority header

From: "Gunn, Janet NE" <[email-masked]>
Date: Wed, 22 May 2002 11:08:36 -0400

Replies inserted in extract

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 21, 2002 7:58 PM
To: [email-masked]
Subject: [Ieprep] Resource priority header

4. If allowed to be something other than an ordered list, then the IANA
Considerations would need to to reworded a bit to say "Within each
namespace, the registration MUST indicate if the values represent an ordered
set and, if so, the relative precedence levels expressed as an ordered
list." Further, I would presume that, if an unordered set were created for
some namespace, that there would be no restrictions to adding values. 

[Gunn, Janet NE] ... 

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

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] ...
If the set of values can be unordered, "lowest" may not be meaningful. 

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 seemto 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 you
want the "public_network" namespace.

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. 

[Gunn, Janet NE]  
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).
 
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) .

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 13:11:41 -0400

> Replies inserted in extract

Please send email to IETF lists in text/plain format, rather than
in the text/html that you used in your note.  This IS possible
even with MS-Outlook by configuring the mail application properly.

Ran

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