[Sois-tcons] White paper contribution.
Jane K. Marquart
Jane.K.Marquart at nasa.gov
Mon Jun 13 12:03:35 EDT 2005
I uploaded the 2 documents to
I couldn't create a new folder. Kept getting errors. I also put this
e-mail on the discussion board so as not to lose it. Let's try to keep all
correspondence there from now on.
At 05:38 PM 6/10/2005 -0400, Richard Schnurr wrote:
>In some ways I am the scribe but I will try to answer anyway.
>IP/NP is the current networking layer of choice for SOIS. In some ways
>IP/NP could be given to SIS since all the QOS stuff other than the QOS
>tagging is below. This would simplify SOIS's life since we would simply
>hand this function over to SIS.
>The IP/NP layer does perform the routing between OBL.
>The span of an OBL is defined by the user. IE if multiple networks of the
>same type are available the bridging of those networks would be
>implementation specific. This is necessary from a fault tollerance
>Remember some of the Bus/Lan are networks onto themselves (for example)
>JWST is using a SpaceWire network to move data without IP.
>The TCONS-API is better than sockets from my perspective since it captures
>the close interaction between network messages and software actions in its
>call back interface however Jane is the one to discuss this and Scott's
>white paper on the messaging service must be interpreted and implemented.
>On the other hand the SOIS API is non-normative since hardware devices
>would not implement.
>Yes, TCONS currently makes no claims to support QOS over multiple OBL's
>(heterogenious or not - IE two separately scheduled SpaceWire networks
>would not support end to end QOS). Although doing so would not be hard if
>both OBL's were in the same schedule domain.
>Steve, put the copyright notice on the document during the shutdown
>period. He will have to comment on why.
>As far as I am concerned the document is copyright of the CCSDS since all
>of this is a group derived work. Otherwise it would be ITAR :).
>The US government has the same write to copyright as anyone else. The
>current court rulings indicate that US copyright occurs when pen is placed
>to paper with or without registration. I am less familiar with the laws
>of Greece. Lets not get into this legal stuff.
>If my clarifications lead to needed changes let me know.
>At 04:22 PM 6/10/2005, Scott,Keith L. wrote:
>>So if I understand correctly, the architectural elements say that:
>>TCONS (in conjunction with/via OBL) provides QoS over individual subnets,
>>and that for traffic that spans heterogeneous subnets, IP is the
>>networking layer? [Architectural Elements (2,3)] Application interfaces
>>to 'TCONS' are via sockets and/or a TCONS-specific API. TCONS makes no
>>claims to support QoS over paths containing multiple OBLs
>>The inclusion of TCP/IP in the green SOIS box on slide 1 is sort of odd
>>(since IP/TCP would normally be a SIS thing). But taking as given that
>>TCONS is a world unto itself in order to provide time-critical services,
>>and needs a network layer to span heterogeneous subnets, it sort of makes
>>BTW: I believe that works by the U.S. Gov't are not eligible for
>>copyright protection, and I'm not sure what legal standing 'The TCONS
>>Working Group' has wrt copyright. I'd be sort of interested if you know
>>more about this.
>>From: sois-tcons-bounces at mailman.ccsds.org
>>[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of Richard Schnurr
>>Sent: Friday, June 10, 2005 11:38 AM
>>To: sois-tcons at mailman.ccsds.org
>>Subject: [Sois-tcons] White paper contribution.
>>OK, based on the last call I drafted the beginnings of a white paper.
>>I kept it short - hopefully you can all read the whole thing.
>>If we all agree to this structure and the descriptions I think we can
>>restart the books.
>>BTW, it would not hurt my feelings if we deleted the OBL service
>>interface and simply defined a Intra-network service interface (This is
>>what I did in this white paper). Not clear that the OBL interface is
>>usable since on board a spacecraft we are time critical and OBL is a on
>>demand type of service not coordinated with anything else.
>>Also, the OBL service interface seems to get in the way more than it
>>helps. For example some OBL's support protocol multiplexing. For those
>>that do the Intra-Net should map directly. We already have IP
>>addresses. It would seem that mapping directly from IP addresses to OBL
>>addresses is what is usually done and makes sense.
>>For these reasons I am proposing that the OBL service interface be
>>deleted and replaced with a private interface to the Intra-networking service.
>>Please read my section on address mapping. It makes sense to me I think
>>it can be implemented and it is in line with existing IP implementations.
>>Steve, I modified the picture to remove the OBL service interface and to
>>move address resolution inside and between the Intra-networking service
>>and OBL. (In case you cannot open the figure again).
>>If we stick to what is written here I think I can actually see a way to
>>implement this consistently across various bus. This is the first time I
>>have had such clarity and I am going on vacation before any of you spoil it.
>>I am on vacation next week. So this and the modified diagrams are my
>>contribution to the white paper.
>>PS I did not use the message board because I do not have my
>>password. Someone can post this if they like. If you reply to this
>>message Please: do not reply inline - add your response to the
>>top. After one pass of the in line comments I cannot follow and on a
>>mailing list like this the likely hood that I will get many reply's is
>>almost surely one.
>>As always correct my thinking as required.
>Richard G Schnurr Jr
>Electrical Systems Center
>Applied Engineering and Technology Directorate
>NASA GSFC Code 560.0
>Greenbelt MD 20771
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sois-tcons