[Sois-tcons] White paper contribution.

Mon Jun 13 12:03:35 EDT 2005

All,

I uploaded the 2 documents to
http://public.ccsds.org/sites/cwe/sois-tcons/Documents.aspx

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.
Thanks!

At 05:38 PM 6/10/2005 -0400, Richard Schnurr wrote:
>Hi Keith,
>
>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 
>perspective.
>
>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.
>
>Cheers,
>Rick
>
>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 
>>sense.
>>
>>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.
>>
>>         --keith
>>----------
>>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.
>>Hi all,
>>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.
>>
>>Rick
>>
>>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
>Chief Architect
>Electrical Systems Center
>Applied Engineering and Technology Directorate
>NASA GSFC Code 560.0
>Greenbelt MD 20771
>
>(301)-286-1852
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons

Jane 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050613/4184cabb/attachment.html