[Sis-ams] RE: Issues for discussion
Burleigh, Scott C
scott.c.burleigh at jpl.nasa.gov
Fri Mar 6 14:24:05 EST 2009
Tim, thanks once again for all the work you've been putting into this. Remote AMS is getting much more - and more constructive - scrutiny than I had ever hoped for.
Some comments on your issues:
1. Do you have something in mind as an alternative to constraining a RAMS network to be either a mesh or a tree? The definitions are mutually exclusive (for any network of more than 2 gateways), so there's no way that any RAMS network could be both. Are you suggesting that we discard one or the other? Or are you proposing to replace one or the other (or both) with a new structure altogether?
2. I agree that the description of the propagation of subscription assertions and cancellations in RAMS is not intuitive. However, I believe it is precise, comprehensive, and unambiguous. I think those are the qualities that are most important in a formal specification. I agree that the approach you posted a few weeks ago will seem more intuitive to many readers, but I don't think it is a better spec. I think adding it to the Green Book as an alternate perspective on the problem and as a guide to developers is very important. But I think that losing the current language in the Red Book and replacing it with your alternative text would be a major mistake. This may just be one of those rare topics on which we simply will not agree.
3. Whenever any AMS node (including a RAMS gateway) terminates, all of its subscriptions automatically terminate (4.2.6.4[4]), so I think we're already getting the correct behavior. How much value would an additional, explicit unsubscribe add?
4. Good catch. 4.4.8.3.1 should be modified to say something like "If the continuum number in the envelope header is zero then (a) if the control code in the envelope indicates "send on reception" then the message shall be discarded, otherwise (b) the RAMS gateway shall forward the envelope data structure - an RPDU - to all declared neighbors."
5. I think this is an implementation matter, Tim. We probably should mention it in the guidance to developers in the Green Book, but it isn't part of the protocol and it isn't part of the service interface. If we start down the path of telling the developer everything she needs to do in order to make AMS work, I think we'll end up with an unnecessarily thick specification.
6. Actually "AMS" has evolved into a blanket term that refers to the system as a whole, that is, everything covered in this spec. I think a better approach here would be to insert an additional Note before Note 1 saying something like "Note that this Transport service definition applies to the Transport Services utilized by the MAMS and AMS protocols as described in 2.3.1. The services used to implement Remote AMS communication channels as described in 4.4.1 are not subject to this definition."
7. Here and in 4.4.8 I think the right thing to do is to change the language: the gateway is a RAMS application node, so (as you pointed out to me) it never actually sees these messages - it only receives service indication primitives. If we say that then we can't talk about copying the incoming APDU, but we can instead say "An enclosure data structure shall be constructed from the parameters of the primitive in the same way that an AAMS message would be constructed from those parameters if the message's destination were a node in the local continuum." That's consistent with the language in 4.3.3.1.1 and it removes the false requirement to make an exact copy of the received message.
8. Do we really need that note? It actually seems pretty clear to me already. But if everybody agrees it would be helpful, okay.
9. Right, as in (7) above.
10. Yes, again as in (7).
11. No, I think this should be all neighbors. The absence of a declaration from a neighbor doesn't mean the neighbor isn't running or doesn't care about your own declaration - it could be that the neighbor is 40 light minutes away and its declaration just hasn't reached you yet. If the retraction goes into the bit bucket, no harm done.
12. You might have a RAMS network that operates continuously for 20 years. During that time, you might want to add some new continua/gateways and/or remove some continua/gateways.
13. But isn't the current language already clear? I don't see how "All nodes in all continua" could be interpreted to mean that nodes in some roles wouldn't be included.
14. Excellent catch! 4.3.3.1.2 is wrong - it didn't get updated when we added the source ID and destination ID fields to the envelope structure. It should say "The continuum number, unit number, and destination ID number of the envelope shall be those identifying the destination of the enclosure; the source ID number of the envelope shall identify source node's own role, and the subject number of the envelope shall identify the subject specified in the original service primitive."
Scott
From: sis-ams-bounces at mailman.ccsds.org [mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J. (GSFC-5830)
Sent: Friday, March 06, 2009 8:46 AM
To: sis-ams at mailman.ccsds.org
Subject: [Sis-ams] Issues for discussion
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/rams%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/rams%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/ab1b2398/attachment.html
More information about the Sis-ams
mailing list