[Sis-ams] spec changes

[Scott Burleigh]

Hi.  I haven't had time to post to this list a detailed recap of the 
discussions in Atlanta early this month, and I can't go into a whole lot 
of detail right now either -- that will show up mainly in the next 
edition of the Concept Paper, which I'm working on now, and in 
discussion on this list after I get that draft posted.  But I want to 
talk a little about the two main types of changes to AMS that came out 
of the meetings, because there are broader implications to one of them.

First, in talking with Roger Thompson about AMS features that MOIMS/SMC 
will need, I came to the realization that we can easily make the AMS 
"zone" and "role" notions powerful enough to minimize the need for 
elaborate subclassing or filtering of message subjects.  Specifically, I 
think Roger wanted the ability to subscribe either to (here I'm making 
up a dubious and fictitious example) "instrument state" messages 
published by the UV spectrometer on Deep Space 5, or the "instrument 
state" messages published by all of the instruments on Deep Space 5, or 
all of the "instrument state" messages published by the UV spectrometers 
on all flying spacecraft, or all of the "instrument state" messages 
published by all instruments on all flying spacecraft.  You could do 
this with message subject naming, e.g., "DS5.UVS.instrumentState", but 
that makes subscribing to all "instrumentState" messages tedious.  
Alternatively, though, you could have a hierarchy of zones (e.g., the 
"all flying spacecraft" zone could contain zones named "DS5", "DS6", 
etc.), and when subscribing to messages you could specify not only 
message subject "instrumentState" but also the zone ("DS5") and 
functional role ("UVS") of the AMS nodes whose published messages you 
want to receive.  You could similarly constrain message invitations, 
with the effect that you would accept messages only from nodes 
performing specified application roles and registered within specified 
zones.  And, for that matter, we could add a new "announce"  message 
transmission model in addition to "publish" and "send": when you 
announce a message you are telling AMS to send it to all nodes 
performing specified application roles and registered within specified 
zones, rather than to a specific node or to all subscribers to a 
specific subject.  I think this turns out to be a surprisingly small 
extension to the protocol and the implementation that offers a lot of 
expressive power.

The other major change came from sitting in on the SOIS/TCONS meeting 
where we discussed the TCONS QOS model.  It occurred to me that AMS 
could utilize both the TCONS resource reservation "channel" notion, and 
also other underlying transport service QOS mechanisms like diffserv, by 
adding a "flow label" to subscriptions and invitations and letting 
transport service adapters map flow labels to channels (etc.) according 
to preconfigured, managed rules.  This seems like a really easy and 
general mechanism for meeting some of the AMS QOS requirements.

Along those lines, though: given this additional QOS dimension, do we 
still need delivery deadlines as part of the AMS QOS design?  The reason 
I'm having second thoughts is that MTS really hasn't been absorbed into 
AMS: it is turning into a separate, alternative API to AMS 
functionality, complementing the native AMS API, in much the same way 
that RPCs are an alternative to sockets as an API for accessing TCP/IP 
functionality.  MTS is already doing things like managing connections, 
which are not an AMS concept; maybe the delivery deadlines and related 
features identified in the MTS spec similarly ought to be implemented in 
MTS rather than in AMS.  This would have the advantage of somewhat 
simplifying and streamlining AMS, making additional implementations and 
testing somewhat easier.  I haven't heard a lot of demand for these 
features from the C3I or SMC communities; maybe they are sufficiently 
SOIS-specific to make them more appropriate for MTS than for the 
underlying AMS.  Anyone have any opinions on this?

One last note: for those who are interested, I have posted to the AMS 
CWE site the AMS status slides I was talking from at the Atlanta 
meetings.  Let me know if you've got questions on 'em.

Scott