[Sis-ams] AMS White Book

[Scott Burleigh]

Hi.  I have now posted to the CWE a fairly heavily revised version of 
the AMS Concept Paper, which has been transmuted into the first edition 
of the AMS White Book ("Proposed Standard") that we're chartered to try 
to publish in December.  Please look it over when you've got time, and 
let's start discussing things that we think need some discussion.

The White Book PDF I've posted is a "clean" document, intended to serve 
as the basis for future evolution of the recommendation.  The bulk of 
the alterations made to the Concept Paper to produce that initial White 
Book are shown in the document named "AMS Concept Paper Markup 2", which 
has got "track changes" turned on; that's the document to look at if you 
want to see the evolution from the Concept Paper that is currently 
implemented, which we demonstrated in Atlanta.  Here's a summary:

1.   As a number of people have suggested, the "Remote AMS" (RAMS) 
procedures are now fully integrated into the protocol rather than 
managed as an add-on capability.  (This actually doesn't increase the 
complexity of the core AMS protocol noticeably, as all of the more 
complicated RAMS stuff happens in the RAMS gateway nodes, above AMS.)  
Also a lot of the RAMS processing has been revisited and in some cases 
clarified; there are now some RAMS-specific protocol data units, for 
example.

2.   The notion of the application "roles" performed by AMS nodes is 
better developed and integrated into the architecture.

3.   Roger pointed out that there's need for a way to (in effect) 
support subscriptions to messages at various levels of subject 
aggregation, e.g., "fuel level" vs "fuel level in main propellant tanks 
of MRO" vs "fuel level in anything on MRO" vs "fuel level in all main 
propellant tanks anywhere".  To address this, the "zone" notion is 
developed a little further in some simple ways.  Zones have always been 
purely administrative groupings of application nodes; the change is that 
zones may now be nested inside one another, e.g., you can have a zone of 
"Mars orbiters" that includes an "MRO" zone in which all the MRO nodes 
are registered.  Further, you can now qualify a message subscription or 
invitation: when you subscribe to messages on a given subject, you can 
additionally say that you only want messages published by nodes that 
perform a specified role ("main propellant tank" vs "all roles") and are 
registered within a specific zone or any zone that is contained within 
that zone ("MRO" vs "anywhere in the system").  I've also defined 
another message transmission option named "announce", in addition to 
publish/send/query/reply, that you can use to send a message to all 
nodes that perform a specified role and are in a specified zone.  
"Announce" is kind of like "publish" in that you don't need to know 
exactly who you're sending to, but the recipients don't have to 
subscribe to get these messages.  Note that these changes impose 
additional complexity, particularly in the RAMS processing.  But the 
power of this approach seems to justify the extra work, and the 
additional RAMS complexity is almost entirely within the RAMS gateway; 
most nodes won't pay a lot for it.

4.   Stuart asked for better AMS support for service-based 
(client/server) applications: specifically, he noted that for 
service-based applications it's the client rather than the server that 
is likely to have the best understanding of the priority (for example) 
of a message sent to the server, so a purely receiver-driven QOS model 
isn't a good fit.  So it's still the case that receivers specify the QOS 
on which they want to receive messages on various subjects, but the 
receiver-specified QOS is now treated as a default that can be 
overridden by the sender when a message is transmitted.

5.   There have been a number of other changes to QOS, mostly inspired 
by the TCONS white paper on QOS.  Delivery order (Transmission order vs 
Arrival order) has been added as a QOS parameter; delivery order and 
"diligence" (Assured vs Best Effort) are now the two parameters that are 
used to select the underlying protocol to use when sending a given 
message.  Priority is no longer one of those protocol-selecting 
parameters, but is instead a value that is carried in the messages 
mainly to enable event ordering at the receiving node; the number of 
priority levels has been increased to 15.  "Flow label", a number from 0 
to 255, has been added as a further QOS parameter; it's opaque to AMS 
but management may map flow labels to QOS settings in underlying 
protocols, e.g., diffserv code points or TCONS channels.  And, as I 
proposed in an email to this list a little while ago, delivery deadline 
has been removed from the AMS QOS concept.  In conversations and email 
exchanges with Ashton and Mike Stagnaro I've become convinced that 
requirements for this kind of feature are going to vary so widely in 
different application regimes that it makes more sense for the layer 
above AMS -- MTS, the C3I framework layer, whatever -- to implement this 
function in whatever way makes sense locally.  This simplifies the spec 
considerably, as it means things like the Handling.indication go away.

6.   My implementation experience has led me to change the node 
registration procedures a good deal, streamlining and simplifying them.  
Also the PDU structures have changed quite a lot as I got a better 
handle on what was likely to work well.

7.   I've also rethought node resynchronization and have rewritten a lot 
of that section of the spec.  Still have to implement it, though.

And there is a little additional news.  I think we're now at the point 
where JPL will let us freely ship the AMS (and supporting libraries) 
source code to other U.S. sites, and we may (or may not; it's not quite 
clear yet) also have authorization to distribute to ESA.  I'd like to 
hold off on sending it out until I bring the implementation up to 
conformance to the revised protocol spec, but if you'd like to start 
working with it in [I hope] late December or early January, let me 
know.  Also, in addition to the Linux and vxWorks ports of AMS, Abhijit 
tells me we are getting close to having a port that would run on Windows 
via Interix (a.k.a. Windows Services for Unix, from Microsoft).

Scott