[Sis-ams] Re: AMS Question

[Scott Burleigh]

Darren Everley wrote:
>
> Scott,
>
>  
>
> I am working here at Scisys with Stuart Fowell on a prototype 
> implementation of AMS and have encountered something I would like to 
> run past you.
>
>  
>
> It is with regard to Node Registration and in particular the 
> /I_am_here / mpdu when sent by a Registrar.  Hopefully my attempt at 
> an explanation below is clear;
>
>  
>
> Reading through the spec. in section 4.2.5 where Node Registration is 
> detailed there are two possible implementation choices that can be 
> made; to either extract information from the mpdus which are passed 
> through the Registrar and then forward on these data in the 
> appropriate situations, or do not and allow the Nodes to take care of 
> this themselves after being introduced to one another.
>
>  
>
> We are going with the first choice and extracting information as it is 
> passed through the Registrar, hence using the /node_has_started/ mpdu 
> to notify other Nodes of a new Node starting. 
>
>  
>
> The way I read the spec. is as follows;
>
>  
>
>     * New Node sends /node_registration/ to Registrar
>
>  
>
>  
>
>     * Registrar sends /you_are_in/ to new Node
>
>  
>
>     * Registrar sends /I_am_here/ to new Node containing details of
>       all other registered Nodes (mams endpoint, delivery vectors,
>       invitations, subscriptions, etc)
>
>  
>
>     * Registrar sends /node_has_started/ on behalf of the new Node to
>       every other registered Node
>
>  
>
>  
>
>     * New Node sends /declaration/ to each Node identified within
>       /I_am_here/
>
> / /
>
> / /
>
> The problem I have is this; the /I_am_here/ mpdu contains alongside a 
> list of invitations and subscriptions the delivery vectors for each 
> Node.  The way I am reading the spec. it appears the delivery vector 
> information is never passed to the Registrar, and therefore the 
> Registrar cannot extract this from the mpdus to then pass on at a 
> later date.
>
>  
>
> The end result of this would appear to be that when a new Node 
> registers the information provided to it will always contain zero 
> length delivery vectors, and therefore no node will be able to 
> communicate with another.
>
>  
>
> If I have missed something glaringly obvious then I would appreciate a 
> pointer in the right direction.
>
Excellent catch, Darren, and it's a question that I think ought to go to 
the Working Group for discussion.

This is a vestige of the original design, in which the registering node 
sent its own /I_am_starting/ (via the registrar), its peers always 
responded directly to it with their own /I_am_here/ messages containing 
their delivery vector lists, and the registering node directly returned 
/declaration/s that contained its delivery vector list -- the Registrar 
never had any need to see any delivery vectors.  But because the 
Registrar may now be responsible for getting the delivery vectors out to 
the nodes in /I_am_here/, it now must receive them.

So I think we need to modify the spec in a couple of small ways:

1.   The /node_registration/ message must now contain not only the MAMS 
endpoint name but also the registering node's delivery vectors list.  
This assures that the registrar has this information and can pass it on 
in later /I_am_here/ messages.

2.   But since the registrar now has this information and is the source 
of all /I_am_starting///node_has_started/ messages, why make the 
registering node send its delivery vectors list again in subsequent 
declaration messages?  (And why make the new node's peers wait for 
declarations before getting that information?)   It's simpler and a 
little more efficient to add delivery vectors list to /I_am_starting/ 
and /node_has_started/, and remove it from the declaration structure.

Anybody see anything wrong with this revision?  If not, I'll post a 
tweaked Red 2 in a couple of days.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080610/148ca19e/attachment.html