[Sis-ams] RE: AMS Question

[Darren Everley]

Scott,

 

I believe this same issue also affects the reconnect MPDU.  Currently
reconnection messages only contain MAMS and node number data; no
delivery vector data is available for a registrar to extract.

 

Darren

 

________________________________

From: Scott Burleigh [mailto:Scott.Burleigh at jpl.nasa.gov] 
Sent: 10 June 2008 17:32
To: Darren Everley
Cc: sis-ams at mailman.ccsds.org
Subject: Re: AMS Question

 

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
declarations 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/20080613/f4fa9626/attachment.html