[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rmt] IETF74 FCAST Action Item
Poll response: I think there is indeed merit. Worthwhile WG item.
At the risk of overkill, here are some of my reasons and rationale:
My comments have to do with the utility of FCAST (and NORM) in military
and emergency services environments. If I get this right, it will be a
translation from operational needs into protocol requirements.
Traffic observation. A much higher percentage of traffic in the
military/EMS world is multicast than in the civilian world. We have
acronyms like BFT (blue force track, asset tracking), COP (common
operational picture), chat, APB (all points bulletin, from the TV
shows), and CAP -- common alerting protocol -- which should give you an
idea of how ubiquitous multicast data is.
Conversely, all of this entails extension of the internet to mobile
platforms so we suffer a 10*4 decrease in bandwidth at the radio-WAN.
The only offset to that bandwidth constriction is the fact that the
media is a shared one -- the ether.
That much rationale should convince that multicast is a good idea -- the
demand side and supply side arguments intersect. Further, we have to
cover multicast at all layers of the ISO reference model (application
layer included) in order to get the benefit. Multicast at layers 1-4
provides no relief if the applications don't use it.
One of the banes of military 'data links' is that they do not include
meta data in the data stream. Compounded by the fact that the data
dictionary (format) is usually in the same spec as the communications
specification. This, coupled with the fact that the data dictionaries
between any two information systems don't coincide yields all kinds of
interoperability difficulties. This leads to phenomena where a single
physical object (a ship) is reported by several different sensor/comms
lashups to a common operational plot where it shows up as several
objects (one appearance per sensor/comms instantiation). Is it any
wonder that the users don't trust it? Modularizing communications and
data away from each other is a core interoperability problem. Including
the meta data in the data stream is one very good means of accomplishing
that end.
Therefore, the basic ideas in FCAST are good and necessary.
But there's more. Look at the problem from the data point of view
rather than the comms (internet) one for a moment. There is
considerable work in object-orienting data. I know of three initiatives
out there worth mentioning:
XMPP. Chat implementations have flowered like the proverbial Czech
springtime. Many were not interoperable with each other and none
carried object security (vital). DISA has latched onto XMPP as the
common denominator. We shouldn't have too much trouble figuring out
that a multicast-based chat implementation has many benefits over the
current server-centric model, both in terms of robustness and bandwidth
conservation.
Cursor on Target. Object oriented data format that uses XML as the
tagging means (small step from the MIME typing mentioned in FCAST).
There are several things wrong with Cursor on Target, lack of
authenticity being one of them. But for this discussion, the most
egregious one is that there's no 'envelope' specified for Cursor o
meritn Target messages (e.g.e-mail). I can't read the Cursor on Target
specification and point to any layer 6/7 protocols.
Common Alerting Protocol. Over the years, several means of warning the
public, and alerting emergency services, have evolved. Many are
stovepipes (remember the TV warnings about nuclear attack?). CAP is
designed to get past the stovepipes by specifying an XML-based schema
that modularizes both the message and the meta-data away from the
communications means of delivery. Many of the FCAST I-D para 4.1 items
also appear (object time validity, for example) in the CAP schema. CAP
also eschews specifying a 'wrapper' or 'envelope' -- considered outside
scope.
Somewhere between a layer 6/7 protocol and MIME/XML-based data formats
we will need a careful modularization boundary ... don't have a complete
interoperability solution without it.
Magnus Westerlund wrote:
Hi,
If the interest for this item is this low, I am very hesitant to approve
taking it on as WG item.
Cheers
Magnus
Brian Adamson skrev:
Hello,
During discussions at the IETF74 RMT meeting, we concluded that we
should poll the mailing list to determine if there is sufficient
interest in adding the new FCAST document and pursuing it as an RMT
working group item. There was some interest expressed during the
working group meeting and a number of folks raised their hands
indicating they would review the document (i.e. we need broader
participation than just the document authors!)
This message requests interested parties to respond on the mailing list
to indicate their opinion on this:
1) Do you think there is merit in the FCAST specification as an RMT WG
item (or not)?
2) Will you review the document so that we can rapidly finish it if it
is accepted as a working group item?
Thank you in advance for your responses to this query.
best regards,
Brian Adamson
adamson at itd.nrl.navy.mil
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www.ietf.org/mailman/listinfo/rmt
--
Rex Buddenberg
Senior Lecturer
Naval Postgraduate School
Monterey, Ca 93943
831/656-3576