Internet Emergency Preparedness (ieprep)

Ken Carlberg | 12 Jun 2002 15:12

(no subject)

Henning,

>  Below are some requirements for such a mechanism:
>
>        Not specific to one domain: The mechanism should not be specific
>             to one country or particular priority mechanism. For
>             example, there are currently at least four priority schemes
>             in widespread use: Q.735, with five levels, the U.S.
>             defense network and NATO with five levels, the United
>             States GETS (Government Emergency Telecommunications
>             Systems) scheme with implied higher priority and the
>             British GTPS system ???.

the above may need a bit of clarification. I think one could argue that 
a specific NameSpace represents a "particular priority mechanism".

I can gather that what you are saying is that the NameSpace should not
reflect a specific organization or implementation.  And you also want to
avoid a one-to-one correlation between a namespace and geographic/geo-
political boundaries.  thats fine.

one the other hand, I assume that NameSpace(s) that correlate to a
standard like MLPP (from ITU) would be fine.  valid interpretation?

also, would it be fine to state that private or experimental NameSpace(s) 
could be defined, but they simply would not be registered with IANA.  We
kind of have that with the current diff-serv allocation of code points.
The one difference with the diff-serv analogy is that I do NOT think there
will be a need to additional parameter stating whether the NameSpace is
public or private.  if the NameSpace is not one listed by IANA, then by

(Continue reading)

headers

Henning Schulzrinne | 1 Oct 2002 22:23

Re: (no subject)


> the above may need a bit of clarification. I think one could argue that 
> a specific NameSpace represents a "particular priority mechanism".

I will formulate a bit more positively.

> 
> I can gather that what you are saying is that the NameSpace should not
> reflect a specific organization or implementation.  And you also want to
> avoid a one-to-one correlation between a namespace and geographic/geo-
> political boundaries.  thats fine.

Indeed.

> 
> one the other hand, I assume that NameSpace(s) that correlate to a
> standard like MLPP (from ITU) would be fine.  valid interpretation?
> 
> also, would it be fine to state that private or experimental NameSpace(s) 
> could be defined, but they simply would not be registered with IANA.  We
> kind of have that with the current diff-serv allocation of code points.
> The one difference with the diff-serv analogy is that I do NOT think there
> will be a need to additional parameter stating whether the NameSpace is
> public or private.  if the NameSpace is not one listed by IANA, then by
> default its private.

Yes; noted.

headers

Scott Bradner | 29 Jun 2002 03:52

Re: (no subject)


from Ran's note I guess I was not clear

what I tried to say was that we do not have an understanding of what
an EPS  phone call *is* in an Internet context

I suppose that one could say that such a call must have a data path that
acts basically like a dedicated private wire but that is not what the
Internet is all about and it would be far from the most efficient way
to provide for this service, and what does one say, if anything, about 
the signaling path?

this list has been talking about prioritizing trafic (and making 
a requrement to tell SIP proxies, PSTN gateways, SIP nodes and who
knows what else what priority to use and I do not know that 
strict priority is even the right concept (Fred has been talking
about more complex concepts such as diffserv AF) 

so when we say "high level requirements" I am not sure we
know what basic concepts the requirements need to fit into in the IP
network

in the gateway to the PSTN is seems clear that we need to have a way to 
tell that gateway what PSTN eps functions (for example MLPP) are
being requested - but what do we want to tell (high level concept,
not N-levels of priority, which is an implementaion concept) a SIP
Proxy to do, or a router in the signaling path, or a router in the data path

Scott

(Continue reading)

headers

Scott Bradner | 29 Jun 2002 03:02

(no subject)

Fred sed:
> It seems to me that the requirements draft should be talking about the 
> problem to be solved ("we need the phones and certain sites to be 
> accessible be emergency workers when things are falling apart"), and if it 
> mentioned solutions at all ("overprovisioning" or "QoS"), it should mention 
> them as examples of a solution which can fix the problem being addressed, 
> discussion of which can help identify requirements remaining to be addressed.

I think this is correct, but ieprep might also need to say what it
means to have phones be "accessible [to] emergency workers"

	there is an a authentication part to this
	there is a privacy part to this
	there is a functionality part to this (e.g., what finctions are needed
		to say that a phone is "accessible")
	there is a quality part to this ( e.g., what are the 
		characteristics of the required network-level functons, 
		e.g., what qos variables, latency, bandwidth, loss, etc, 
		apply, and how shoudl they be thought about

	there are other parts I'm sure

Scott

headers

RJ Atkinson | 29 Jun 2002 03:31

Re: (no subject)


On Friday, June 28, 2002, at 09:02 , Scott Bradner wrote:
> Fred sed:
>> It seems to me that the requirements draft should be talking about the
>> problem to be solved ("we need the phones and certain sites to be
>> accessible be emergency workers when things are falling apart"), and 
>> if it
>> mentioned solutions at all ("overprovisioning" or "QoS"), it should 
>> mention
>> them as examples of a solution which can fix the problem being 
>> addressed,
>> discussion of which can help identify requirements remaining to be 
>> addressed.
>
> I think this is correct, but ieprep might also need to say what it
> means to have phones be "accessible [to] emergency workers"
>
> 	there is an a authentication part to this
> 	there is a privacy part to this
> 	there is a functionality part to this (e.g., what finctions are needed
> 		to say that a phone is "accessible")
> 	there is a quality part to this ( e.g., what are the
> 		characteristics of the required network-level functons,
> 		e.g., what qos variables, latency, bandwidth, loss, etc,
> 		apply, and how shoudl they be thought about
>
> 	there are other parts I'm sure

Scott,

(Continue reading)

headers

Mpierce1 | 12 Jun 2002 20:44

Re: (no subject)

In a message dated 6/12/02 12:17:07 PM Eastern Daylight Time, Janet.Gunn <at> DynCorp.com writes:

Do you know where Q.735 is, or is planned to be, implemented? Is it on the
PSTN, or on a "private" telecom network? Who (if anyone) would be the
"owner" of the q735 namespace?

I don't know of anyplace where Q.735 is used in a "public" network. But I'm sure it is implemented in switches that also provide public network service. It's intended use was clearly within a "private" telecom network, such as the Defense Switched Network. But remember that part of a "private" network may share physical resources with a "public" network.

Your question on the proposed q735 namespace is one that I need to address to justify the creation of such a namespace. I know that I haven't done a complete job of this.

First, no one needs to "own" the namespace. The intention is a very limited one - providing the interworking between two ISUP-based networks through a SIP-based part. Anyone could use it for this purpose. The intention was to allow the gateways to perfom a straightforward mapping, without any interpretation, of the values in the IAM to a similar one in the INVITE. (For example, the dsn namespace requires that the gateway understand the meaining of the character "FLASH" and convert it to a binary value 2.)

Of course, as other discussions on ISUP-SIP mapping and encapsulation are showing, there may already be other ways to support this interworking scenario. The q735 namespace was essentially an extension to the ISUP to SIP mapping, with the idea that the mapping needed to include everything that might need interworking between ISUP and SIP. Perhaps it can be handled with pure encapsulation, if its relation with mapping can be better defined.

Mike Pierce

headers

Gunn, Janet NE | 12 Jun 2002 18:16

RE: (no subject)

Do you know where Q.735 is, or is planned to be, implemented?  Is it on the
PSTN, or on a "private" telecom network?  Who (if anyone) would be the
"owner" of the q735 namespace?

-----Origi nal Message-----
From: Mpierce1 <at> aol.com [mailto:Mpierce1 <at> aol.com]
Sent: Wednesday, June 12, 2002 12:11 PM
To: K.Carlberg <at> cs.ucl.ac.uk; schulzrinne <at> cs.columbia.edu
Cc: ieprep <at> ietf.org
Subject: Re: [Ieprep] (no subject)

In a message dated 6/12/02 9:14:10 AM Eastern Daylight Time,
K.Carlberg <at> cs.ucl.ac.uk writes: 

>        Not specific to one domain: The mechanism should not be specific 
>             to one country or particular priority mechanism. For 
>             example, there are currently at least four priority schemes 
>             in widespread use: Q.735, with five levels, the U.S. 
>             defense network and NATO with five levels, the United 
>             States GETS (Government Emergency Telecommunications 
>             Systems) scheme with implied higher priority and the 
>             British GTPS system ???. 

Just to clarifiy, the priority scheme in Q.735 is exactly the same as the US
defense network. 

Mike Pierce

headers

Mpierce1 | 12 Jun 2002 18:11

Re: (no subject)

In a message dated 6/12/02 9:14:10 AM Eastern Daylight Time, K.Carlberg <at> cs.ucl.ac.uk writes:

>        Not specific to one domain: The mechanism should not be specific
>             to one country or particular priority mechanism. For
>             example, there are currently at least four priority schemes
>             in widespread use: Q.735, with five levels, the U.S.
>             defense network and NATO with five levels, the United
>             States GETS (Government Emergency Telecommunications
>             Systems) scheme with implied higher priority and the
>             British GTPS system ???.

Just to clarifiy, the priority scheme in Q.735 is exactly the same as the US defense network.

Mike Pierce

headers

Ken Carlberg | 12 Jun 2002 15:18

draft-schulzrinne-ieprep-resource-req-00.txt


sorry.  my previous message was for Henning's Requirements for Resource
Priority Mechanisms draft  <draft-schulzrinne-ieprep-resource-req-00.txt>

i forgot to add the draft name to the subject line

-ken