[Sis-ams] Revised White Book

[Scott Burleigh]

Hi, AMS fans.  We've got a implementation of Remote AMS working pretty 
well now, and in the course of working out the problems in RAMS I 
identified a number of opportunities to improve the AMS White Book.  
This morning I posted a new revision to the AMS-WG CWE on ccsds.org, and 
here are some notes on the changes I'm proposing.

1.   The subscription assertion and cancellation "supplementary data 
values" in MAMS had to be expanded somewhat to include the number of the 
continuum to which each subscription pertains.  Since invitation 
assertions and cancellations don't need continuum number (they only 
pertain to the local continuum), I needed to split the subscription 
stuff out into two new items.

2.   A simplification, for once: it turned out to be much better for the 
RAMS gateway simply to pay attention to all subscription activity 
(including the subscriptions in registration and resynchronization 
traffic) than to receive its own special-purpose MAMS messages, so I've 
removed petition assertions and cancellations from the AMS and RAMS 
procedures.

3.   In order to handle messages received from remote continua properly, 
it turns out to be important that the zone names and numbers defined in 
the local continuum be identical to those defined in the remote 
continua.  What finally dawned on me is that "zones" are really units of 
organization that cut across multiple continua, sort of the same way 
that a big company's Sales division may include sales offices in a dozen 
different cities.  In this light, the word "zone" starts to seem less 
and less useful as the name for this concept.  So I have in effect split 
the notion of "zone" in two and given each part a new name.  A "unit" of 
an application instance is one of these cross-cutting units of 
hierarchical organization, and a "cell" is the subset of a given unit 
that is within a given continuum -- in the same way that a "message 
space" is the subset of a given application instance that is within a 
given continuum.  The cells (formerly "zones") in a message space nest 
within one another in exactly the same way that the units of the 
application instance nest within one another.  I've added a diagram to 
the spec to try to make this a little clearer, but I suspect explaining 
these relationships clearly will ultimately be one of the major tasks 
for whoever ends up writing the AMS Green Book.

4.   Another terminology change: serious implementation and use of RAMS 
makes the concept of the "application instance" so important that I 
would like to use a less cumbersome name for that concept.  I've started 
replacing "application instance" with "venture" in most places in the spec.

5.   In discussions with some people from the DTN world it occurred to 
me that RAMS is very close to providing all the functionality that 
people have historically hoped to get from "multicast"; the one feature 
that is missing is the scalability that a tree-shaped forwarding 
structure can provide.  I think this is a small enough change to RAMS to 
be worth inserting, considering the potential benefit, so I have 
proposed that the "RAMS grid" be generalized to a "RAMS network" that 
can take the form of either a grid or a tree depending on the 
requirements of the users.  This affects a couple of the RAMS 
procedures, but I suspect that it won't make implementations a lot larger.

6.   Finally, as I was looking at the impact of enabling the RAMS 
network to be tree-shaped I noticed an error in the procedure for 
propagating an "announcement" through RAMS.  That error is now corrected.

I'm sure we'll be talking about some of this stuff in Rome, but if 
you've got comments before then please feel free to post them to this list.

Scott