In the circuit switched paradigm of preemption (MLPP and eMLPP),
only calls that are identified a-priori as "part of a preemption
domain (or similar term)" can be preempted. "Normal" (unmarked, as
opposed to marked "routine") calls cannot be preempted. I REALLY
don't think we should break that aspect of the paradigm without
investigating "unintended consequences" in great detail.
> - only certain namespace.priority-value combinations *can* preempt
> another call.
>
> just a thought about how to solve this...
>
> James
>
>
> >Private net (ESInet):
> >(anything they want)
> >
> >Lastly, what kind of prioritization does a government official (a
> >servant of the people) get when they themselves initiate an emergency
> >call? esnet or ets/wps? (In a private ESInet, it may be to their
> >disadvantage to keep the wrong one.)
> >
> >-roger marshall.
> >
> >
> > > -----Original Message-----
> > > From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> > > On Behalf Of Brian Rosen
> > > Sent: Thursday, November 20, 2008 9:01 AM
> > > To: 'Janet P Gunn'
> > > Cc: Ecrit at ietf.org
> > > Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > > An "Emergency Services IP Network" is a private IP network to
> > > which, we hope, all public safety agencies are connected. It
> > > handles all the traffic of a public safety agency, which
> > > would include routine and priority citizen to authority,
> > > authority to authority and authority to citizen traffic.
> > > It's not entirely clear to me yet whether we can reuse a
> > > number of the existing name spaces as well as a new one. For
> > > example, some of the agency-agency traffic will require
> > > pre-emption, but the existing MLPP namespace may be quite sufficient.
> > >
> > > It does occur to me that we could have ETS and possibly WPS
> > > traffic, in that if the normal access to public facilities
> > > traversed the ESInet towards some kind of gateway to a public
> > > network, then we would either have to have the ETS/WPS
> > > values, or remark them at the edge if a caller inside the
> > > ESInet needed to call someone outside the ESInet and needed
> > > ETS/WPS priority to do so. If we carried the priority
> > > marking across the ESInet, ETS/WPS would be lower priority
> > > than some other traffic, but higher than, for example,
> > > citizen to authority emergency calls.
> > >
> > > Brian
> > >
> > >
> > >
> > > From: Janet P Gunn [mailto:jgunn6 at csc.com]
> > > Sent: Thursday, November 20, 2008 11:37 AM
> > > To: Brian Rosen
> > > Cc: Ecrit at ietf.org; 'GOLDMAN, STUART O (STUART)'
> > > Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > >
> > > Brian,
> > >
> > > I need to understand this better.
> > >
> > > Exactly what are the constraints of the "emergency services
> > > IP network"? Is this a network in which EVERY call would
> > > have the RPH with the esnet namespace (just varying priority
> > > values),and there would be no "normal" calls? Or would their
> > > be a mixture of calls with and without RPH wit esnet?
> > >
> > > Janet
> > >
> > > "Brian Rosen" <br at brianrosen.net> wrote on 11/20/2008 11:16:39 AM:
> > >
> > > > A suggestion was made to me that we should define two namespaces.
> > > >
> > > > One would be used in public networks, and generally would
> > > be used to request
> > > > resource priority for citizen to authority and possibly
> > > authority to citizen
> > > > calls. This would have lower priority than ETS/WPS.
> > > >
> > > > The other would be for use within emergency services IP
> > > networks. It would
> > > > be unlikely that ETS/WPS would be used within those
> > > networks, but if it was,
> > > > some values within the namespace would need higher priority
> > > that ETS/WPS.
> > > > For example, a message which was an incident commanders
> > > "evacuate" message
> > > > would be higher than a ETS/WPS traffic. On the other hand,
> > > a citizen to
> > > > authority emergency call would have lower priority.
> > > >
> > > > I would be happier with one namespace and more values in
> > > that namespace for
> > > > all of this, but I was advised that two namespaces was a
> > > better choice.
> > > >
> > > > Brian
> > > >
> > > > From: ecrit-bounces at ietf.org
> > > [mailto:ecrit-bounces at ietf.org] On Behalf Of
> > > > Janet P Gunn
> > > > Sent: Thursday, November 20, 2008 11:00 AM
> > > > To: GOLDMAN, STUART O (STUART)
> > > > Cc: Ecrit at ietf.org
> > > > Subject: Re: [Ecrit] Ecrit]
> > > > draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > >
> > > >
> > > > Stu,
> > > >
> > > > I intended to say that the esnet namespace needs to be at a
> > > LOWER priority
> > > > than the ets and wps namespaces, in any network that
> > > recognizes ets and wps
> > > > as described in 10.5 and 10.6 of RFC4412.
> > > >
> > > > Janet
> > > >
> > > > "GOLDMAN, STUART O \(STUART\)"
> > > <sgoldman at alcatel-lucent.com> wrote on
> > > > 11/20/2008 10:22:49 AM:
> > > >
> > > > > Janet,
> > > > >
> > > > > With regard to you e-mail below, did you intend that
> > > esnet could be
> > > > > at the same level of priority as ETS & WPS, or that ETS
> > > & WPS need
> > > > > to be at an even higher priority than esnet?
> > > > >
> > > > >
> > > > >
> > > > > Stuart Goldman
> > > > > Alcatel-Lucent
> > > > > Stuart.Goldman at alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Janet P Gunn/FED/CSC at CSC
> > > > > Sent by: ecrit-bounces at ietf.org
> > > > > 10/27/2008 11:45 PM
> > > > >
> > > > >
> > > > >
> > > > > To
> > > > >
> > > > > "James M. Polk" <jmpolk at cisco.com>
> > > > >
> > > > > cc
> > > > >
> > > > > "'ECRIT'" <ecrit at ietf.org>, ecrit-bounces at ietf.org
> > > > >
> > > > > Subject
> > > > >
> > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I apologize for not tracking this as closely as I meant
> > > to, as these
> > > > > comments apply to earlier versions as well.
> > > > >
> > > > >
> > > > > This sentence at the end of sec 1 doesn't quite work.
> > > > > "This document IANA registers the "esnet"
> > > > > RPH namespace for use within emergency services
> > > networks, not just
> > > > > of those from citizens to PSAPs." (no clear antecedent
> > > for "those")
> > > > >
> > > > > Perhaps
> > > > > "This document IANA registers the "esnet"
> > > > > RPH namespace for use within emergency services
> > > networks, not just
> > > > > for calls or sessions
> > > > > from citizens to PSAPs."
> > > > >
> > > > > Section 2 says
> > > > > "This document updates the behaviors of the SIP Resource Priority
> > > > > header, defined in [RFC4412], during the treatment options
> > > > > surrounding this new "esnet" namespace only. The usage of the
> > > > > "esnet" namespace does not have a normal, or routine
> > > call level.
> > > > > Every use of this namespace will be in times of an
> > > emergency, where
> > > > > at least one end of the signaling is with a local emergency
> > > > > organization."
> > > > >
> > > > > I don't see this as an "update of the behavior of 4412". Neither
> > > > > the ets namespace not the wps
> > > > > namespace have a "normal" or "routine" call level. Every
> > > use of the
> > > > > wps and ets namespaces will
> > > > > have priority over calls without RPH.
> > > > >
> > > > > You say "This
> > > > > namespace, therefore, MAY be overwritten or deleted,
> > > contrary to the
> > > > > rules of RFC 4412 [RFC4412]."
> > > > >
> > > > > It is not clear to me why this is "contrary to the rules
> > > of 4412".
> > > > > It is certainly anticipated
> > > > > that other RPH will be overwritten or deleted, when the UAS
> > > > > understands the namespace.
> > > > >
> > > > > 4412 says "Existing implementations of RFC 3261 that do
> > > not participate in
> > > > the
> > > > > resource priority mechanism follow the normal rules of RFC 3261,
> > > > > Section 8.2.2: "If a UAS does not understand a header field in a
> > > > > request (that is, the header field is not defined in this
> > > > > specification or in any supported extension), the server
> > > MUST ignore
> > > > > that header field and continue processing the message". "
> > > > >
> > > > > But I do not see anywhere that is says that a UAS that DOES
> > > > > understand the namespace is
> > > > > forbidden from deleting it. For instance, sec 4.7.1 of 4412 says
> > > > > that "the UAC
> > > > > MAY attempt a subsequent request with the same or
> > > different resource
> > > > > value." This certainly implies the ability to overwrite
> > > or delete
> > > > > an RPH namespace.
> > > > >
> > > > > (See also, for instance the PTSC SAC document on the use
> > > of the ets
> > > > > and wps namespaces)
> > > > >
> > > > > Immediately following these statements, you give 3 options-
> > > > > "These proxies in the service provider
> > > > > MAY either
> > > > >
> > > > > o accept the existing RPH value with "esnet" in it, if one is
> > > > > present, and grant relative preferential treatment to
> > > the request
> > > > > when forwarding it to the ESINet.
> > > > >
> > > > > o replace any existing RPH value, if one is present,
> > > and insert an
> > > > > "esnet" namespace and give relative preferential
> > > treatment to the
> > > > > request when forwarding it to the ESINet.
> > > > >
> > > > > o insert an "esnet" namespace in a new RPH and give relative
> > > > > preferential treatment to the request when forwarding the SIP
> > > > > request towards the ESINet."
> > > > >
> > > > > Why do you exclude the possibility of adding the esnet RPH value
> > > > > without "replacing" an existing RPH value?
> > > > >
> > > > > Finally, there is another point that needs to be made clear. At
> > > > > least one person has contacted me expressing concern that this ID
> > > > > implied that the esnet namespace would have priority over other
> > > > > namespaces (in particular wps and ets). I assured him
> > > that this was
> > > > > not the case, that there was nothing prevent the expected
> > > behavior -
> > > > > that the ets and wps namespaces would be prioritized
> > > ahead of esnet
> > > > > in GETS Service Provider networks.
> > > > >
> > > > > However, since the question has already arisen, it would
> > > be a good
> > > > > idea to clarify this, perhaps in section 3, where you
> > > discuss the
> > > > > other namespaces. In particular, it needs to be made clear in
> > > > > section 3.2 that, even if "the local jurisdiction
> > > preferred to
> > > > > preempt normal calls in lieu of
> > > > > completing emergency calls. ", esnet calls will NOT
> > > preempt wps or ets
> > > > calls.
> > > > >
> > > > > By the way, I think you mean "the local jurisdiction
> > > preferred to
> > > > > preempt normal calls in order to complete emergency
> > > calls. " - not
> > > > > "in lieu of". Or perhaps "the local jurisdiction preferred to
> > > > > preempt normal calls in lieu of dropping emergency calls. "
> > > > >
> > > > > In fact, it is not clear to me that 4412 permits a call
> > > with an RPH
> > > > > (e.g., esnet) to preempt a "normal" call (with no RPH
> > > namespace).
> > > > > Section 4.7.2.1 of 4412 says
> > > > > "4.7.2.1. User Agent Servers and Preemption Algorithm
> > > > >
> > > > > A UAS compliant with this specification MUST terminate a session
> > > > > established with a valid namespace and lower-priority
> > > value in favor
> > > > > of a new session set up with a valid namespace and
> > > higher relative
> > > > > priority value, unless local policy has some form of
> > > call-waiting
> > > > > capability enabled. "
> > > > >
> > > > > It doesn't say anything about preempting a call with no RPH
> > > > >
> > > > > Thanks
> > > > >
> > > > > 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.
> > > > >
> > > > > "James M. Polk" <jmpolk at cisco.com>
> > > > > Sent by: ecrit-bounces at ietf.org
> > > > > 10/27/2008 08:32 PM
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To
> > > > >
> > > > > "'ECRIT'" <ecrit at ietf.org>
> > > > >
> > > > > cc
> > > > >
> > > > >
> > > > >
> > > > > Subject
> > > > >
> > > > > [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ECRIT WG
> > > > >
> > > > > Here is a update to a ID I think is pretty near done,
> > > given that this
> > > > > is merely an IANA registration ID of an existing mechanism.
> > > > >
> > > > > Comments are wanted
> > > > >
> > > > > >A New Internet-Draft is available from the on-line
> > > Internet-Drafts
> > > > > >directories.
> > > > > >This draft is a work item of the Emergency Context
> > > Resolution with
> > > > > >Internet Technologies Working Group of the IETF.
> > > > > >
> > > > > >
> > > > > > Title : IANA Registering a SIP
> > > Resource Priority
> > > > > > Header Namespace for Local Emergency Communications
> > > > > > Author(s) : J. Polk
> > > > > > Filename :
> > > > > > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
> > > > > > Pages : 9
> > > > > > Date : 2008-10-27
> > > > > >
> > > > > >This document creates and IANA registers the new Session
> > > Initiation
> > > > > >Protocol (SIP) Resource Priority header (RPH) namespace
> > > "esnet" for
> > > > > >local emergency usage to a public safety answering point (PSAP),
> > > > > >between PSAPs, and between a PSAP and first responders and their
> > > > > >organizations.
> > > > > >
> > > > > >A URL for this Internet-Draft is:
> > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> > > > > emergency-rph-namespace-00.txt
> > > > > >
> > > > > >
> > > > > >
> > > > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local->
> > > > emergency-rph-namespace-00.txt>
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ecrit
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > Ecrit at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > > >
> > > > > Stuart Goldman
> > > > > Alcatel-Lucent
> > > > > Stuart.Goldman at alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ecrit
> > >
> >
> >CONFIDENTIALITY NOTICE: The information contained in this message
> >may be privileged and/or confidential. If you are not the intended
> >recipient, or responsible for delivering this message to the
> >intended recipient, any review, forwarding, dissemination,
> >distribution or copying of this communication or any attachment(s)
> >is strictly prohibited. If you have received this message in error,
> >please notify the sender immediately, and delete it and all
> >attachments from your computer and network.
> >_______________________________________________
> >Ecrit mailing list
> >Ecrit at ietf.org
> >https://www.ietf.org/mailman/listinfo/ecrit
>