[Sis-ams] AMS deliberations

[Scott Burleigh]

Hi.  The holiday hiatus behind us, it's probably time for the AMS BOF to start making some progress toward its goals: we're supposed to report to Bob on our deliberations by the end of February.

The first step is to identify a set of Requirements for asynchronous message exchange among spacecraft and between spacecraft and ground data systems.  One way to begin would be to look at the (informal) requirements that the design of the NASA Constellation Command, Control, Communications, and Information (C3I) architecture's "framework" element was responding to.  Another way, though, would be to look at the MOIMS requirements for asynchronous messaging.

Roger, I remember there was at least one technical point that you brought up in Toulouse, that the initial AMS concept paper didn't address; naturally I failed to write it down, but I'm hoping you can recall what it was.  Would you have a few minutes to summarize the MOIMS messaging requirements for this mailing list and point out areas where AMS as currently proposed would fall short?

Also, are there MTS requirements that we need to keep in mind when considering the AMS concept?  Stuart and Ashton, would you want to summarize for this discussion?

A couple of things I know of that have come up since November:

1.	Abhijit confirms a point I thought of, which comes out of the C3I framework design: while the AMS concept as currently written enables QOS to be specified on a node-by-node basis (in node specifications at registration time), we really need QOS to be specified at finer granularity.  I think this means adding optional overriding "port specifications" (or maybe a better term would be "delivery point specifications") to subscriptions, so that QOS is controlled at subscription -- message type, subject -- granularity.

2.	Another C3I requirement comes out of vehicle docking: we need to be able to merge distinct AMS continua when the physical platforms on which they are sited come into such close proximity that there is no longer any purpose served by keeping the continua separate.  (And, conversely, we need to be able to carve a single continuum into two continua when physical platforms become separated by distances that impose inconvenient latencies on meta-AMS traffic.)  I've got a mechanism for this in mind, but the details are probably a topic to work out in the AMS Working Group when and if it gets approved; for now I think it's sufficient just to identify the requirement.

Any other thoughts?

Scott