<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>So if I understand correctly, the architectural
elements say that:</SPAN></FONT></DIV>
<UL dir=ltr>
<LI>
<DIV align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>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)]</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>Application interfaces to 'TCONS' are via sockets
and/or a TCONS-specific API.</SPAN></FONT></DIV></LI>
<LI>
<DIV align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>TCONS makes no claims to support QoS over paths
containing multiple OBLs</SPAN></FONT></DIV></LI></UL>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=181120420-10062005>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.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><SPAN class=181120420-10062005><FONT face=Arial color=#0000ff
size=2>
--keith</FONT></SPAN><BR></DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sois-tcons-bounces@mailman.ccsds.org
[mailto:sois-tcons-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Richard
Schnurr<BR><B>Sent:</B> Friday, June 10, 2005 11:38 AM<BR><B>To:</B>
sois-tcons@mailman.ccsds.org<BR><B>Subject:</B> [Sois-tcons] White paper
contribution.<BR></FONT><BR></DIV>
<DIV></DIV>Hi all,<BR><BR>OK, based on the last call I drafted the beginnings
of a white paper.<BR><BR>I kept it short - hopefully you can all read the
whole thing.<BR><BR>If we all agree to this structure and the descriptions I
think we can restart the books.<BR><BR>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.<BR><BR>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. <BR><BR>For these reasons I
am proposing that the OBL service interface be deleted and replaced with a
private interface to the Intra-networking service.<BR><BR>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.<BR><BR>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).<BR><BR>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.<BR><BR>I am on vacation next week.
So this and the modified diagrams are my contribution to the white
paper.<BR><BR>Rick<BR><BR>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: <FONT size=4><U>do not reply inline</U></FONT> -
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.<BR><BR>As always correct my thinking as
required.<BR><BR><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>