[Sis-ams] Issues for discussion

[Ray, Timothy J. (GSFC-5830)]

Hello all,

 

This email provides a list of AMS issues for discussion (most are
related to Remote AMS).  The first two issues are important; the rest
are minor.

 

1)       Is our working group comfortable with constraining a Remote-AMS
network to be either a 'mesh' or a 'tree' - keep in mind that if one
agency creates a 'mesh' network, and another agency creates a 'tree'
network, the two Remote-AMS networks will not interoperate (more
specifically, Remote-AMS cannot be used to join the two networks) .
This may not be a big deal, but let's make sure that everyone is aware
of this limitation and able to live with it.

2)       The part of the Remote AMS specification that handles the
propagation of subscription assertions/cancellations is not intuitive
for me, but I think it can be expressed in a way that is intuitive.  In
particular, rules that are currently spread across sections 4.4.3,
4.4.5.2, 4.4.6.2, 4.4.6.4, 4.4.7.2, and 4.4.7.5 can be put in a single
section.  The Green Book material that I posted to our web site a few
weeks ago summarizes an approach that is intuitive (and could be
contained in a single section)  (see the section titled "Calculating a
Petition's Source Continuum Set" and compare it to the above-mentioned
sections).     Link:   http://cwe.ccsds.org/sis/docs/sis-ams/draft
documents/green book/rams green book text v38.doc
<http://cwe.ccsds.org/sis/docs/sis-ams/draft%20documents/green%20book/ra
ms%20green%20book%20text%20v38.doc>        accompanying pictures are
here:   http://cwe.ccsds.org/sis/docs/sis-ams/draft documents/green
book/rams green book figures v1.ppt
<http://cwe.ccsds.org/sis/docs/sis-ams/draft%20documents/green%20book/ra
ms%20green%20book%20figures%20v1.ppt>       If there is a consensus that
the change is worth making, I will volunteer to edit the Red Book.  

3)       Each time a gateway starts (4.4.2.1.2) it subscribes locally to
the pseudo-subject.  But when it terminates (4.4.2.2.3) it doesn't
unsubscribe locally.  Seems like it should.

4)       4.4.8 - is there a hole?  Suppose the RPDU header indicates
'send on reception' to 'all continua'?  Presumably, that is not allowed,
but the current specs would propagate the message to all continua.

5)       Clearly, a RAMS gateway needs to keep track of each invitation
from any of its local nodes, but I don't see any explicit requirement to
do so (nor a specification of the mechanism that provides that
information to the local gateway) - suggest adding a section on
responding to Assert_Invitation.indication and
Cancel_Invitation.indication.

6)       Editorial change in section 3.2 - "AMS" includes AAMS and
Meta-AMS but not Remote AMS.

7)       Add explanatory note in section 4.4.9.1 ("memory copy of the
incoming APDU").

8)       Add explanatory note in section 4.3.3.1.1 ("enclosure is
essentially equivalent to an APDU").

9)       4.4.9  Editorial change:  On receiving a message.indication on
a subject that is greater than zero...     (also applies to 4.4.8,
except it's a message.indication, query.indication, or reply.indication
whose subject is a pseudo-subject)

10)   4.4.9.1 "construct an AAMS message having the same parameters" or
something similar instead of "exactly re-creating".  Recall that
version_number and checksum are not in the message.indication, but are
needed to exactly recreate the AAMS message.

11)   4.4.2.2.3  Careful: perhaps "neighbors" should be "declared
neighbors".

12)   4.4.2.2.2  Why would the set of neighbors change on-the-fly?  

13)   4.4.2.1.3  Editorial change.  The current text ends with "and
whose domain is all nodes in all continua".  Given that a domain
includes continuum, unit, and role - there would be less chance of this
clause being misinterpreted if the text said "and with the following
domain: all units from all continua with any role" (or words to that
effect).  (or if a note was added)   

14)   Remote AMS - forwarding an 'Announcement'.  The destination
gateway needs to know the source node's role, but does not appear to
have that info - i.e. the source node's role is not propagated through
the RAMS network.  (Note: 'source role number' is carried in the RPDU
header, but section 4.3.3.1.2 says that "the destination continuum
number, unit number, and node number or role number of the envelope
shall be those identifying the *destination* of the enclosure").
Anyway, I have not finished implementing this capability, so this may
turn out to be a misunderstanding on my part.

 

Best regards,

Tim

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20090306/433f800e/attachment.htm