[Sois-tcons] White paper contribution.

[Scott,Keith L.]

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.
	
	
	
	
	
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050610/230bf427/attachment.htm