[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00

At 11:24 AM 11/20/2008, Roger Marshall wrote:

It seems like we're diverging here.  In the ESInet, it seems to me, that
the owner/manager of that ESInet will set the priority treatment as they
deem fit.  Only in the public network arena will real prioritization
have a chance to be "standardized".  So far what do people say is the
ordering?
Just to be clear, this discussion is NOT something my namespace ID should ever address. I have no issues with having this discussion - but I want to make clear that draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make priority decisions or even recommendations in the text of the doc.
This ID only creates the namespace *and* the probably scenario in which it is intended. 



Public net:
P1. ets/wps? (PSAPs may not be so eager to agree)
P2. esnet
P3. <other/null>


it's not as simple as that.
each <namsepace.priority-value> gets its own slot in any relative priority order (per section 8 of RFC4412). 

With this in mind, it is *possible* to have a relative priority order like this

P1. ets.4
P2. esnet.4
P3. ets.3  wps.4
P4. esnet.3  esnet.2
P5. wps.3  ets.2
P6. wps.2  ets.1
P7. esnet.1
P8. esnet.0
P9. ets.0  wps.0
notice that within each <namespace>, the numbering order is consistent, but that the order relative to the different namespaces is whatever the local operator wants to make them. I do show here that at each priority level (e.g., P3, P4, P5, P6 and P9) that there are more than one namespace.priority-value combination. This means, within this priority - it's a FIFO situation in which each of the namespace.priority-value combinations at this priority level compete (i.e., they are equivalent in priority). This is all a local decision.
I think a way to address Brian's comment about preemption is also a local decision (because the local jurisdiction needs to live with the consequences). Here's how that can be addressed: 

- all these namespace.priority-value combinations *can* be preempted
- 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


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit