Subject: [atoca] Broadcast Reqs

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Sep 2011 09:53:05 +0300

From the meeting minutes: 

> Slide 9: Broadcast Reqs
> -----------------------
> * Deliver msgs in common format so that a device that registers for alerts gets and understands the alerts, regardless of the transport.
> 
> KD:  I'm going to jump on this slide again.  You're assuming a model where the distributors and the recipients don't necessarily have a relationship.  You also need to take into account where the model knows about the layer-2 protocols.
> BR:  the reason that we're not going down that road is because we don't want to be limited based on the layer-2
> RBL: I think there's something like Skype, which is aware of the layer-2 details, but wants to participate.  We don't want to rely on layer-2 characteristics, but take advantage of them if we can.  If we were relying on a UDP datagram, the app can listen for that; if the network knows about this it can broadcast that UDP datagram content in an optimized manner.
> MW:  I think we've got at least two mechanisms that can utilize this.
> Scott Bradner:  While that feature is available in some, it's not available in all
> BR:  I think there's two ways to do that [the form of the alert]. Can we rely on the recipient to announce what format it wants, or do we send multiple and the recipient selects the one they want?
> RBL: Let's take location as an example.
> BR:  I think we want to handle both.  And we need to find a way to put that into the CAP message, or wrap multiple CAP messages.

I have not been able to participate at the phone conference and so I am trying to reconstruct the discussion based on the meeting minutes. 

I fail to see how a broadcast mechanism can distribute multiple CAP message in a single UDP message or how it can provide different formats to different receivers. 

I also confused by the first sentence. I hope that the idea of defining a broadcast mechanism is to define one rather than multiple.

---

From: "'Mark'" <[email-masked]>
Date: Wed, 14 Sep 2011 15:00:53 +0100

Hans question was;

-- quote  --

I fail to see how a broadcast mechanism can distribute multiple CAP message
in a single UDP message or how it can provide different formats to different
receivers. 

I also confused by the first sentence. I hope that the idea of defining a
broadcast mechanism is to define one rather than multiple. 

-- unqote  --

Chaps;

Hans makes a valid point and one that needs much more further discussion. I
don't know the answer to this yet but we need to work it out.  

I know that this forum is not a cell broadcast forum, but since CB is the
only model we have at the moment, some (not all) of the issues with it will
be the same.

With CB the available payload space is too small to transmit the whole CAP
message, and so only the 'Headline' text is transmitted, the rest of the CAP
message is stripped off by the Alert Gateway (or some other unit). The geo
specificity is implied by which cell the terminal has camped on, so the cell
broadcast centre CBC receives the polygon and the text, but only the text is
sent over the air. 

However a cell can be several km across and so this does cause some
fuzzyness as to geo resolution. 

It is possible to also transmit the 'Polygon' part of the CAP message also,
so that terminals which have some sort of location system, can determine if
they are inside the polygon or not. If not, the terminal ignores the
message. (This causes the resolution to be the same as that of the terminals
geo location system).  

But this is still very small amount of data compared to the whole of the CAP
message. The full CAP message is (in CB) used by the various gateways but
only the text (and perhaps also in the future, the polygon) will be sent to
the terminal. 

In the near future many governments will need to transmit in multiple
languages, and while how to do this is still the subject of much heated
debate, one method is to repeat the message, and either have an additional
coding scheme to indicate the language (which is ignored by terminals not
supporting that language) or by using a different Message Identifier
(Multicast address) for each language. The phone then ignores any versions
of the message not appropriate. 

The advantage of this approach is that there is no 'stateful' relationship
between the terminal and the system, which means that it is passively mass
scalable at the moment of use. The disadvantage is that only those formats
that the government have chosen to transmit are multicast. 

However devices could subscribe to another push technology in some cases,
but on a 'best effort' basis during the acute phase of overload. In fact
there is no way to prevent anyone from subscribing to 'Google Hub' if they
want to. 

Regarding IP multicast, as you know I am not an IP expert but I understand
that neither IGMP, SIP nor PIM sparse mode, seem to have a geo specific part
implemented. This seems to indicate that only quite coarse geo resolution
based on administrator settings would occur. 

Therefore in that case perhaps 'polygon' information would be sent to the
terminal so that the intelligence of location is done by the terminal. Given
that there are not such restrictions on data size in IP, perhaps in some
cases the whole of the CAP message (or a subset of it) can be multicast and
we let the terminal decide what parts of it are relevant. Naturally we
repeat the multicast periodically (eg once per minute for 20 minutes), but
there is only one copy for all stations on an access link. 

Since XML is extensible, several different version of the message can be
multicast in the same package, and we let the terminal take what it needs. 

This may be less traffic than letting 10^7 terminals try to haggle for
stateful relationships with the distribution servers.

I would be very interested in hearing observations on this.

Warm regards mark Wood  DRCF.

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Wed, 14 Sep 2011 14:16:19 +0000

message, and so only the 'Headline' text is transmitted, the rest of the CAP
message is stripped off by the Alert Gateway (or some other unit).

If you are talking about CMAS, this is not entirely correct. The CAP "headline' is not necessarily the field that is broadcast by the cell broadcast service.

so that terminals which have some sort of location system, can determine if
they are inside the polygon or not.

This is not defined in the current PWS/CMAS specifications.

(Multicast address) for each language.

ATIS is currently developing CMAS standards for Spanish.

--------
Brian K. Daly
Director, Core Network & Govn't/Regulatory Standards
AT&T Services, Inc.
+1.425.580.6873
[email-masked]

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 'Mark'
Sent: Wednesday, September 14, 2011 7:01 AM
To: [email-masked]
Subject: Re: [atoca] Broadcast Reqs

Hans question was;

-- quote  --

-- unqote  --

Chaps;

 

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

---

From: "Mark" <[email-masked]>
Date: Wed, 14 Sep 2011 15:31:57 +0100

Friends;

Thanks for your clarifications Brian,

-BD- If you are talking about CMAS, this is not entirely correct. The CAP
"headline' is not necessarily the field that is broadcast by the cell
broadcast service.

-MW- Yes correct, the AGW is programmed to use whatever part of the CAP
message is the appropriate part for that specific 'instance' of network and
requirement from the sender. 

-BD- [polygon sending] is not defined in the current PWS/CMAS
specifications.

-MW- Yes, thanks for that clarification, while polygon transmission is
'possible' it is not currently defined or implemented by any present
revision of PWS system. 

-MW- I am pleased that progress in this matter is being made.

---

From: Art Botterell <[email-masked]>
Date: Wed, 14 Sep 2011 07:48:22 -0700

Just as a reminder... there's a packed ASN.1 serialization available for CAP as well as the XML format.  Not sure how much of a payload size reduction that achieves, but it might be significant.

Also, it may be useful to distinguish explicitly between the interoperable network-level format (CAP) and various technology-specific presentation-level formats (CMAS text, CAP headline, SAME, siren activation bit, etc.)  My experience has been that those two situations sometimes get conflated in discussion, which can cause confusion.  

Usually the conversion from CAP to a presentation format is lossy and therefore essentially a one-way trip, although I suppose it's possible that some presentation schemes might actually involve adding information (e.g., visual styling) from which the full original CAP data could be retrieved later.

- Art

---

From: Art Botterell <[email-masked]>
Date: Wed, 14 Sep 2011 09:07:15 -0700

On Sep 14, 2011, at 8:00 AM, Brian Rosen wrote:

> I would like to avoid ASN.1 if possible.

Any particular reason, or just personal preference?  I hold no personal brief for the ASN.1 serialization, but it is the standardized approach to compacting CAP without losing data.

> One of the things I want to explore is how we do appropriate mapping from what is in the message to what is presented.  I'm not talking about style issues.  Some devices really would be best giving a shorter version of the alert, while others have better displays and interactivity mechanisms that allow a richer presentation.  We might want to make sure we can send/extract what a particular recipient needed.

As mentioned earlier, a "down-conversion" from CAP to something presentation-specific is almost always a one-way trip, and thus, to maximize interoperability, should be done as far downstream... as close to the receiving edge... as possible.  It may be wisest to maintain a fairly strict separation between the interoperable network and the technology-specific presentation, lest we wind up with a proliferation of semi-compatible formats floating around, which would sort of defeat the basic objective of CAP.

> I also want to be able to label things like a link for more information in a way that a renderer can do something appropriate with it.

The CAP resource block supports the sort of filtering I think you're after.

- Art

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 15 Sep 2011 10:25:20 +0200

Hi Art,

As the chair of the group that produced the X.1303 version of
CAP,  including the ASN.1 module, my recollection at the time
was that the ASN.1 representation was roughly one half the
size.  Where large numbers of emergency messages are sent in a
burst and delivery delays are critical, the value proposition is
obvious.  Although clearly ASN.1 use has diminished, translations
are readily accomplish, and the above factors make inclusion of
the ASN.1 option rather desirable.

--tony

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Sep 2011 17:19:00 +0300

Hi Tony, Hi Art, 

I am not so much concerned about the delivery bursts and delays in sending alerts but rather whether they fit into a UDP datagram without requiring fragmentation. The total size includes security related payload as well. 

Ciao
Hannes

---

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

Yes, I'm thinking that a lot of the issue here is that the ASN.1 serialization "looks hard."  The (XML-based) caplib did seem to create a comfort zone for implementers in the early days.  Is there, or would it be hard to create, a comparable reference implementation for ASN.1?  

I could probably get some Carnegie Mellon grad students to do the programming if someone had a few bucks to throw at the problem...

- Art

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 17:02:08 +0200

Dear all,

you may find some information in clause 8 of Recommendation ITU-T X.1303 
which you can download from
http://www.itu.int/rec/T-REC-X.1303-200709-I/en

I am also checking with some ASN.1 experts if they could provide you 
with some material which would help answering to your questions.
-- 
Olivier DUBUISSON, ITU-T ASN.1 & OID Project leader
France Telecom - Orange
OLNC/RD/DRS - BP 50702 - 22307 Lannion Cedex - France
tel: +33 2 96 05 38 50

> Usually the conversion from CAP to a presentation format is lossy and therefore essentially a one-way trip, although I suppose it's possible that some presentation schemes might actually involve ad…

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Sep 2011 07:15:28 +0800

On 2011-09-16 at 00:48:52, Art Botterell wrote:
> Yes, I'm thinking that a lot of the issue here is that the ASN.1 
> serialization "looks hard".

It's difficult to underestimate how powerful an effect "looks hard" actually is.  ASN.1 + DER as used in CMS isn't actually all that hard to implement when you get down to it, but in practice very few people get past the initial shock to the point of producing a real implementation.  ASN.1 + PER is hard.

Good libraries do help in this, but they aren't a perfect solution.

Out of interest, has anyone looked at CAP compression instead?  There's been a lot of work recently in the web world in optimizing compression for use there and that can be very highly effective.

--Martin

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 16:48:47 -0700

> It's difficult to underestimate how powerful an effect "looks hard" actually is.  ASN.1 + DER as used in CMS isn't actually all that hard to implement when you get down to it, but in practice very…

Of course CAP geospatial geometries looked hard at first too, at least to non-GIS folks.  But if the benefits are sufficient, it's amazing what programmers can learn how to do.

> Good libraries do help in this, but they aren't a perfect solution.

Then again, is there ever such a thing as a perfect solution? ;-)

> Out of interest, has anyone looked at CAP compression instead?  

Some web servers will already compress content by default if both ends support it, so I suppose that could be made a requirement for a specified transport layer.  Again, CAP is really a data-structure specification more than an XML or an ASN.1 thing per-se.  Still, serialization standards are necessary at the transport level to maximize interoperability, so I'd think there'd be some preference for existing standards where possible.

- Art

---

From: Paul Thorpe <[email-masked]>
Date: Fri, 16 Sep 2011 11:17:13 -0700 (PDT)

> -------- Original Message --------
> Date: Thu, 15 Sep 2011 07:48:52 -0700
> From: Art Botterell <[email-masked]>
> To: [email-masked], Eliot Christian <[email-masked]>
> CC: [email-masked]
>
> serialization "looks hard."  The (XML-based) caplib did seem to create a
> comfort zone for implementers in the early days.  Is there, or would it
> be hard to create, a comparable reference implementation for ASN.1?
>
> I could probably get some Carnegie Mellon grad students to do the
> programming if someone had a few bucks to throw at the problem...
>
> - Art
>

We do not have a specific implementation for the ASN.1 schema for CAP
available, but I would like to point out that many of the existing ASN.1
tools, both commercial and free, have the ability to generate one
automatically and directly from the ASN.1 schema.

Typically, an application developer who uses an ASN.1 tool will submit an
ASN.1 schema to the tool, and the tool will generate a set of data
structures in a particular programming language (e.g., Java classes, C++
classes, C# classes, or C structs).

In writing his application code, the developer will then deal with data
structures defined in a familiar programming language, and will not be
exposed to the details of the serialization.  The runtime library of the
ASN.1 tool provides functions that convert the content of the data
structures into a standard PER encoding and vice versa.  When using the
ASN.1 schema in the CAP 1.1 standard, the data structures generated by the
ASN.1 tool will be a representation of a CAP alert message in a formalism
familiar to the developer.

Several ASN.1 tools, both commercial and free, are listed on the
ITU-T website at http://www.itu.int/ITU-T/asn1/links/index.htm.

----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: [email-masked]                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023