Subject: [atoca] WG Direction

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Jul 2011 23:20:12 +0800

One of the topics that I want to discuss at the meeting on Friday is the future direction of the working group.  This group has been very quiet.  That's not good.

I've spoken to a number of people about a plan for getting some work completed.

A rough sketch of that plan is in the chair slides that I've uploaded to the agenda.  There are five parts to the plan:

 - Requirements
 - Architecture
 - Distribution
 - Broadcast
 - Security

I would like to see progress on the first two soon.  We can discuss times on Friday.

Discuss.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Jul 2011 12:21:09 -0400

Hi Martin, 

thank you for getting the discussion started again. 

I believe a problem with the progress is that we still don't fully understand how the envisioned communication architecture is going to look like (despite the discussion we had at the last IETF meeting in Prague). 

From the discussed scenarios I see two extreme scenarios: 

(1) the "school is closed" scenario where notifications are being sent point-to-point to a pre-defined list of devices (and users) using a pub-sub mechanism. 
Many of the security mechanisms are being dealt with at the time of subscription. 

I believe we can very easily support this scenario with the mechanisms we have available today. 

(2) The "tsunami warning" scenario where a point-to-multipoint / broadcasting mechanism is envisioned.
Here there are two communication legs that are relevant:   
   a) from the originator to some relay, and 
   b) from the relay to all the receivers. 

There are lots of solutions for (a) and I don't think that further work is needed there. For (b) we do not yet know how this is supposed to work...

We should use the meeting time to figure out how the bigger picture is supposed to work and then we can capture those aspects in the architecture work. 

Ciao
Hannes

On Jul 27, 2011, at 11:20 AM, Thomson, Martin wrote:

> _______________________________________________
> atoca mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atoca

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 28 Jul 2011 00:41:02 +0800

You have it right.

The problem is that we don't have any of the pieces that we understand written down.  The model in the requirements document doesn't include a description of these cases and how those fit together.  Brian has promised to correct that.

We need to discuss the bits where we don't have a common understanding.  Seeing some proposals should help coalesce opinions.  Without text - accurate, consensus or otherwise - as a baseline, we simply aren't making progress.

--Martin

On 2011-07-27 at 12:21:09, Hannes Tschofenig wrote:
> I believe a problem with the progress is that we still don't fully 
> understand how the envisioned communication architecture is going to 
> look like (despite the discussion we had at the last IETF meeting in 
> Prague).
> 
> (1) the "school is closed" scenario where notifications are being sent 
> point-to-point to a pre-defined list of devices (and users) using a 
> pub-sub mechanism.
> There are lots of solutions for (a) and I don't think that further 
> work is needed there. For (b) we do not yet know how this is supposed 
> to work...
> 
> We should use the meeting time to figure out how the bigger picture is 
> supposed to work and then we can capture those aspects in the 
> architecture work.
> 
> Ciao
> Hannes
> 
> 
> > One of the topics that I want to discuss at the meeting on Friday is
> the future direction of the working group.  This group has been very 
> quiet.  That's not good.
> >
> > A rough sketch of that plan is in the chair slides that I've 
> > uploaded
> to the agenda.  There are five parts to the plan:
> >
> > - Requirements
> > - Architecture
> > - Distribution
> > - Broadcast
> > - Security
> >

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 27 Jul 2011 12:54:08 -0600

There may be some useful use case and requirements information related to 
deployed, operational debris flow and tsunami warning systems. There is 
also, I suspect, considerable technical information.

Both examples are from the Asia community and are quite mature operational 
systems - and standards based!

I can provide more information if desired.

Cheers

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 27, 2011 10:21 AM
Subject: Re: [atoca] WG Direction

> understand how the envisioned communication architecture is going to look 
> like (despite the discussion we had at the last IETF meeting in Prague).
>
> There are lots of solutions for (a) and I don't think that further work is 
> needed there. For (b) we do not yet know how this is supposed to work...
>
> supposed to work and then we can capture those aspects in the architecture 
> work.
>
> Ciao
> Hannes
>
>
>> One of the topics that I want to discuss at the meeting on Friday is the 
>> future direction of the working group.  This group has been very quiet. 
>> That's not good.
>>
>> A rough sketch of that plan is in the chair slides that I've uploaded to 
>> the agenda.  There are five parts to the plan:
>>
>> - Requirements
>> - Architecture
>> - Distribution
>> - Broadcast
>> - Security
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Jul 2011 22:05:01 -0400

If the relay is close to the base station and on the same subnet as all mobiles, normal IP multicast would work ("all hosts"). For example, this could work on campus, although some campus WiFi systems have, from what I've heard, disabled multicast to deal with mDNS flooding. Yes, this does require carrier/operator cooperation, but some countries already mandate CMAS support, which also requires carrier participation.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 28 Jul 2011 21:23:09 +0800

On 2011-07-27 at 22:05:01, Henning Schulzrinne wrote:
> Yes, this does require carrier/operator cooperation, but 
> some countries already mandate CMAS support, which also requires 
> carrier participation.

An important point to keep in mind.  There is very little an authority can do without support from the local network.

---

From: "Mark" <[email-masked]>
Date: Thu, 28 Jul 2011 13:49:06 +0100

Hi Guys,
Mark Wood DRCF. 

My apologies for missing Prague, I assure you that I am deeply engaged, but
not always available for travel :-)

I think we should all consider that at some point any PUBLIC mobile system,
whether it is GSM LTE or any other form of wireless technology, will have to
have some or other point-to-multipoint geo specific bearer service, (like
Cell Broadcast in mobile systems), in order to meet national requirements
regarding public warning systems (PWS). It is likely to be mandatory in many
countries.

Private Enterprise systems are another matter, but the technological
implications are just the same imho. 

I feel that the use of multicast is the obvious way to do that, and that it
can be easily managed if we have a pre defined multicast address space for
this purpose, so that administrators can admit this traffic without any fear
of flooding their networks.

We can pick a handy range of 255 addresses in V4 and a matching set in V6,  

The existing IGMP and PIM protocols seem to be able to handle this, but we
clearly need an expert to investigate the matter further. (BTW this will be
the subject of my Masters thesis next year). 

After all, the amount of traffic sent by PWS is no more than 80 bytes per
minute or so, just a line of plain text, and then only during the disaster! 

In normal times it is almost nil (apart from hourly 80 byte heartbeat
messages) so its really trivial amounts of traffic we are talking about
here, worries about multicast causing flooding are not justified in this
application.

The traffic worry is, from people, on learning of the problem, then watching
steaming Unicast video streams from CNN, so the warning system contribution
is trivially small in comparison. However due to the above concern, we need
really bullet proof QoS priority for multicast within this specific address
range.   

Since the CAP X1303 protocol and the aggregator/gateway systems are taking
shape now, (its all being successfully tested on live systems) it should not
be hard to find an authentic source for the traffic and the authorised
polygons to be sent to the multicast RPs, so imho it does not look as if we
have an urgent need to re invent that wheel.

But we DO need to look at how to make IP multicast *passively* geo specific.

By comparison, the geo-specificity of a Cell Broadcast system is down to a
single cell, which as you know is typically about 5Km radius or so. We don't
really need geo specificity to resolutions any better than 'post code' level
by the present requirements, which should be well within the ability of any
campus administrator to handle, even manually.

Cellular base stations have an entry in a 'Cell Data Base', which 'knows'
the lat/long of the antenna for each logical cell and its azimuth. Its this
data that is cached by the cell broadcast centre, and used to find antennas
under the polygon of the cap message. Copies of the text are then sent to
each cell that was a match in the cell data base table.  There is no PIM or
IGMP in Cellular Broadcast systems, though the Cell Broadcast Centre (CBC)
serves as the Rendezvous point (RP).

We urgently need to know how to mimic this passive geo-specificity in IP
multicast systems. There are plenty of ways to do it, but we do need to
start a discussion on what they are and how we can use them.  

However as Hannes says, I don't think that this has been fully explored yet.

Warm regards, Mark Wood, on behalf of DRCF. (and CellCast). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: 28 July 2011 03:05
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [atoca] WG Direction

If the relay is close to the base station and on the same subnet as all
mobiles, normal IP multicast would work ("all hosts"). For example, this
could work on campus, although some campus WiFi systems have, from what I've
heard, disabled multicast to deal with mDNS flooding. Yes, this does require
carrier/operator cooperation, but some countries already mandate CMAS
support, which also requires carrier participation.

Henning

> (1) the "school is closed" scenario where notifications are being sent
point-to-point to a pre-defined list of devices (and users) using a pub-sub
mechanism.

---

From: [email-masked]
Date: Thu, 28 Jul 2011 13:35:37 +0000

> An important point to keep in mind.  There is very little an  
> authority can do without support from the local network.

this is in the context of expectations of additional services from the  
network.  In the end, there is always unicast back to the host.

I'd also observe that the thread has focused on variations of push  
models.  there is also the pulled poll model from the  
end-user/consumer that can be constructive to leverage -- eg, being  
that some events like hurricanes span days in advance, and initially  
polling in the order of hour(s) provides sufficient information that  
can be later complemented by subsequent pushed information.

-ken

---

From: Art Botterell <[email-masked]>
Date: Thu, 28 Jul 2011 07:48:15 -0700

> campus administrator to handle, even manually.

Not sure how those "present requirements" were determined, but I'd be cautious about confusing technical capabilities with functional requirements.  

Having run a community warning system for a number of years I can report that we very frequently used the more precise geotargeting capability of wireline systems to target messages down to areas of a square km or so, and not infrequently down to a few city blocks.  

In fact I'd go so far as to say that the utility of a warning technology is proportional to the granularity of the geotargeting... there are lots of cases where a warning might be issued except for the fear of operational and/or political fallout from including too many recipients for whom the warning is not actually relevant.  

- Art

---

From: "Mark" <[email-masked]>
Date: Thu, 28 Jul 2011 16:53:50 +0100

Friends;

Yes, Art is correct (as usual) :-)

The more geo specific a message is, the more utility is has, especially down
to very local jurisdictional levels where, which side of the street matters.
Since a CAP message has a polygon with it, there is not much problem in
using that as a very specific geo location parameter.

**
I should declare at once, that I believe that all methods of warning should
be used, the fact that I have been associated with the development of cell
broadcast for many years does not mean that I have any resistance to other
distribution methods as well, far from it; I actively work to include them
all!
**
  
My point was a different one;

*Passive* Cell Broadcast can only target one individual cell. Every enabled
device in the cell will receive the message. If you were using a larger
'cell' such as a 500kHz NAVTEX transmitter, you would have to assume that
the receiving device has some method to filer out messages based on its
location and the polygon sent in the message (as is done at sea). 

In cell broadcast we make the preliminary assumption that the mobile phone
has no GPS system and is not a 'smart phone'. In that case the
geo-specificity is implied if it gets the message or not (i.e. if it is
anywhere in the cell), and the mobile needs have no knowledge of its
position. 

But in the future, as GPS enabled smart phones become more common, we will
be able to transmit the polygon along with the content and thus have 1M
resolution without changing the technology that much, while still keeping it
back compatible with the older legacy phones. This is the sort of thing we
are working on now and rightly should be the goal.  

In IETF's interest, regarding distribution layer networks, wired, 802.11 or
802.16 cells, the same applies, if the host does not have any geo awareness,
then it will have to imply it by the fact that the router or base station
was commanded to multicast the message (or Unicast it). 

In some cases this may be a bit of a 'blunt instrument' at first, but in
time, pinpoint specificity should be the goal, and it's do-able given the
transmission of the CAP polygon to the router or base station along with the
content. 

Transmitting to any base station that has any coverage under the polygon,
then letting the hosts ignore information outside its position, means that
the whole solution is passive, which matters when you are doing very massive
scale alerting during overload events.

Of course, using 'dial down' phone or fax, the location of the end of the
line is known so the phone location can be implied by that, so the problem
does not arise.   

Thanks art, good point.

Mark

---

From: Art Botterell <[email-masked]>
Date: Thu, 28 Jul 2011 09:05:16 -0700

And as usual Mark and I are in agreement!  This does, however, point to another interesting question... the extent to which routing decisions, including but not limited to geographic ones, should be made toward the center of the functional network or toward the edge... or perhaps both/neither as in the case of content-centric networking.

At Carnegie Mellon Silicon Valley we're working with Xerox PARC on potential applications of CCN in disaster management.  While I'm sensitive to the fact that CCN remains controversial in some corners, I'm wondering whether a CCN overlay might be useful as a framework for alerting.

- Art

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 28 Jul 2011 12:38:01 -0400

A good overview of geolocation tagging needs and
mechanisms can be gleaned from the April global
CAP implementers workshop hosted by the WMO
http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2011/DocPlan.html

At the event, clever geo-tagging implementations
by both Beidou and Google were described.

The use of OIDs for some of these purposes in
the allotted alerting arc 2.49 and in conjunction with
the DNS based OID resolution system was also described
there.  Because OIDs are also embedded in digital certs
and network elements, they can be further exploited
for needed geotagging.

--tony