Subject: [atoca] Architecture Writeup

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 17 Sep 2011 21:19:25 +0300

Hi all, 

based on the discussions from the last IETF meeting I have written a short section for the current requirements/framework/terminology document. I would like to know whether it captures the discussions appropriately or where additional text is needed. 

------

3.  Alert Delivery Architecture

   Section 1 describes the basic two steps that are involved with the
   alert message handling, namely subscription and alert delivery.  From
   an architectural point of view there are, however, a few variations
   possible depending on the characteristics of the subscription process
   and the style of message delivery.  This section offers more details
   on the communication architecture and highlights the necessary
   standardization actions.

   We start our description with the so-called "school closed" example
   where school authorities send alerts to all parents to notify theim
   about the fact that their children cannot attend school.  Parents
   subscribe to these events when their children start attending the
   school and unsubscribe when they are finished with a particular
   school.  The subscription procedures establishes a closed
   communication group and authorization is also taken off as part of
   this process.  Typically, alert messages stay within the closed group
   and are not shared with others and alert message delivery is point-
   to-point with whatever communication protocol is most suitable.  This
   also means that there the alerts reach those who have subscribed
   rather than those who are in the vicinity of the school.  The number
   of alert message Recipients is typically rather small, in the order
   of hundreds to several thousands.

   A variation of the "school closed" example is an explicit
   subscription model where no closed group pattern exists.  Consider a
   traveler who would like to receive weather alerts about a specific
   geographical region.  He may have to manually search for how to
   subscribe to alerts for the desired region, potentially looking a
   different subscription points for different types of alerts.  As an
   automated version of this procedure some form of discovery may help
   to find these subscription servers.  The approach described in
   [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery
   such alert subscription servers.  The number of alert message
   Recipients is larger than in the previous example but will typically
   stay below the millions.

   With the next category we move to a scenario where large number of
   Recipients shall be notified but the subscription itself is implicit,
   as it is the case when persons are within a specific region that can
   easily be reached by making use of broadcast link layer technologies.
   The placement of the actors from Figure 1 is thereby important.  When
   a Sender distributes the alert it distributes it already to Relays
   within the geographically affected area.  Those Relays are located
   within Internet Service Providers so that multicast and broadcast
   communication protocols can be utilized for efficient distribution to
   a large number of Recipients.  When the alert message delivery is
   accomplished at the networking layer then various requirements, such
   as the ability to deal with NAT and firewall traversal, have to be
   met by such a protocol.  The number of alert message Recipients is
   very large, potentially in the millions.

   Next, we move to a model where the alert distribution uses a
   broadcast network layer distribution mechanism but subscription to
   the alerts is explicit.  Figure 2 shows the architecture.  The LoST
   Forest Guide ensures that there is a way for Reivers to discovery
   local alert subscription servers.  The individual LoST servers
   thereby know about these authoritative servers and redirect discovery
   requests to the appropriate LoST server in case the answer cannot be
   provided for a request, similar to how LoST is used in the ECRIT
   emergency services architecture [RFC5582].

   Once a Receiver had discovered a local subscription server it
   subscribes to it (with additional information about the type of alert
   it is interested in).  As a response, it will receive information
   about the security credential the relay is going to use for
   subsequent alert delivery.

   When an Author creates an alert for distribution the affected region
   will be indicated and so the alert will be sent to a relay within the
   realm of the local alert distribution server and a notification will
   be sent to all the subscribed Receivers.  The local Relay and the
   local alert subscription server will therefore cooperate in the
   handling of the alerts.

                           ,-----.
                          / Lost  \
                 +-------(  Server )---------+
   Forest     ,-----.     \   A   /       ,-----.
   Guide     / LoST  \     `-----'       / LoST  \
            (  Server )                 (  Server )
             \   D   /     ,-----.       \  B    /
              `-----'     / LoST  \       `-----'
                 +-------(  Server )---------+
                          \   B   /
                           `-----'
  ,''''''''''''''''''''''''\  :
  | Local         ,------. |  :
  | Alert         | Local| |  :                      ...................
  | Subscription  | Relay|.|..:       Alert          | +------+ Author |
  | Server        `......'-+-------------------------+-|Sender|    O   |
  |                  |     |         Notification    | |      |   /|\  |
  '`'''''''''''''''''+''''''                         | +------+   / \  |
     |        Alert  |                               `-----------------'
  Subscr.  +---------+
     |     |  Notification
     |     |
     |     |
  .....................
  | +------+ Recipient|
  | |Recvr |    O     |
  | |      |   /|\    |
  | +------+   / \    |
  `-------------------'

      Figure 2: Architectural Model for the Broadcast Alert Delivery
                   Mechanism with Explicit Subscription

------

The not-yet-submitted version of the document, which contains the above writeup, can be found here: 
https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-framework/draft-ietf-atoca-requirements-02.txt

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Sep 2011 10:21:27 +0300

Here is some feedback from Richard on my writeup sent off list earlier. With his permission I share it with you:

-----

The document only barely touches on the separation of distribution from broadcast. The only spot I see it is in the separation of "Receiver" from "recipient", which seems confusing. The document seems inordinately focused on the "Message Handling System" ("distribution", in the terminology I've been using), and doesn't really say anything about the ultimate delivery ("broadcast").  ISTM that the situation should be reversed.  Given the abundant prior art in the distribution space -- and the fact that it's overall an easier problem technically -- means we don't have to say a whole lot here.  Whereas the problems raised by the broadcast protocol are numerous and subtle.

Starting with the "school closed" case is less than convincing.  The more I think about it, the less I think we need to do anything about that case.  There are lots of existing technologies that meet the needs of that case (SIP, Jabber, email); or at least, I don't recall having heard an argument that they don't.

Notwithstanding the above, the requirements are actually pretty OK.  I would assign them to slightly different parts of the architecture (mainly as aspects of the broadcast protocol), and I think there need to also be some security requirements, but it seems like they should basically all be carried forward.

-----

Ciao
Hannes

---

From: "Peter Sanders" <[email-masked]>
Date: Mon, 19 Sep 2011 10:36:33 +0200

Hi Hannes,

I would support Richard's idea that the "school closed" example is not very
convincing. One reason is that the alert is not location specific. It
doesn't really matter where the school children or their parents are when
the alert is transmitted. A second reason is that it is not clear that there
is a sense of urgency here. Possibly the message is sent on the previous
evening of the day when the school is closed.

Regards,
Peter 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: maandag 19 september 2011 9:21
To: Hannes Tschofenig; [email-masked]
Subject: Re: [atoca] Architecture Writeup

Here is some feedback from Richard on my writeup sent off list earlier. With
his permission I share it with you:

-----

The document only barely touches on the separation of distribution from
broadcast. The only spot I see it is in the separation of "Receiver" from
"recipient", which seems confusing. The document seems inordinately focused
on the "Message Handling System" ("distribution", in the terminology I've
been using), and doesn't really say anything about the ultimate delivery
("broadcast").  ISTM that the situation should be reversed.  Given the
abundant prior art in the distribution space -- and the fact that it's
overall an easier problem technically -- means we don't have to say a whole
lot here.  Whereas the problems raised by the broadcast protocol are
numerous and subtle.

Starting with the "school closed" case is less than convincing.  The more I
think about it, the less I think we need to do anything about that case.
There are lots of existing technologies that meet the needs of that case
(SIP, Jabber, email); or at least, I don't recall having heard an argument
that they don't.

Notwithstanding the above, the requirements are actually pretty OK.  I would
assign them to slightly different parts of the architecture (mainly as
aspects of the broadcast protocol), and I think there need to also be some
security requirements, but it seems like they should basically all be
carried forward.

-----

Ciao
Hannes

On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote:

> Hi all, 
> 
> based on the discussions from the last IETF meeting I have written a short
section for the current requirements/framework/terminology document. I would
like to know whether it captures the discussions appropriately or where
additional text is needed. 
>                  +-------(  Server )---------+
https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-framewo
rk/draft-ietf-atoca-requirements-02.txt
> Hannes

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

---

From: "Mark" <[email-masked]>
Date: Mon, 19 Sep 2011 11:17:49 +0100

Thanks Peter;

-PS- A second reason is that it is not clear that there
is a sense of urgency here. Possibly the message is sent on the previous
evening of the day when the school is closed.

Regards,
Peter 

-MW- Sadly, it's usually the case that the mass scale 10^7 distribution
needs to be delivered "in a timely manner" at the moment that the network is
in acute overload situations. 

By contrast, such things as 'civic information' or school closures, even if
on a large scale, may not also simultaneously occur during acute overload
instances. 

Therefore for many situations the normal push/pull bearers that we have now
may well be perfectly fine.

Broadcast and multicast bearers are also a good fit for smaller scale civic
messaging, because they are much more efficient and are natively and
passively geo specific, but using them in combination with push or pull is
also possible provided we are not in an acute phase.  

I will be having a chat with my CAP expert later today to get some
clarification about how CAP is authenticated. I think there is an EXL -DE
wrapper around it which contains specified origination point codes. I note
that ITU-T SG11 has become involved in this part of the solution because one
of the other things they do is to manage the object identifier space (or one
of the three of them). 

I will chat to some people who know about that today and ask for
clarification.

Mark

ca

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Sep 2011 14:04:17 +0300

Hi Peter, 

I agree with you that location may not play the same role as in the mass alert distribution case. 
In this case the alerts may refer to a specific location (such as "give me all weather alerts from the Helsinki area") but in the school specific example the location plays a less important role. 

The urgency is clearly also not the same as in the tsuami warning case. For that reason the point-to-point delivery is a suitable choice here. 

I have specifically added this example because many of the Internet alert distribution examples make use of this type of alert distribution and they happen to use CAP and GeoRSS for that purpose. For example, have a look at: 
http://alerts.weather.gov/

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Sep 2011 14:09:15 +0300

Hi Mark, 

On Sep 19, 2011, at 1:17 PM, Mark wrote:

> clarification about how CAP is authenticated.

We know how CAP messages are authenticated; at least we know what the specification says (namely XML DSIG).
It would be interesting to hear what is being used in the real world 

> I think there is an EXL -DE

Nobody so far suggested to use EDXL-DE in this discussion. 
EDXL-DE, if I correctly understood it, adds another wrapper on top of CAP. 

This will obviously not make the size problems to go away. Instead, they will become more problematic as we add more wrappers. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Sep 2011 09:21:50 -0400

I think it's helpful to enumerate the scenarios, including the school alerts, even if we then declare some to be "already solved" or "beyond the scope".

The problem with non-standard school alerts is fairly obvious: Right now, if each school has its own mechanism, aggregators (e.g., TV stations, public transit authorities or large employers) have to manually extract the information and keep track of a dozen different ways to get the information. Typically, such systems are also display-oriented, making processing of the information very difficult. Such processing includes appropriate rendering for people with disabilities.

Also, I think it would be helpful to distinguish more clearly between delivery of structured and display of formatted information.Somewhere along the way, the translation happens. We have often implicitly assumed that this is in the end system, but that's clearly not always the case. For example, CAP could be translated to a voice call "in the network", or an SMS message or some other display format. This includes language translation by third-party services. (Government issues the alert, but, say, a local NGO decides to convert the alert to the language of an immigrant community.)

Henning

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 19 Sep 2011 09:32:41 -0400

+1

Igor