<html>
Hi Keith,<br>
<br>
In some ways I am the scribe but I will try to answer anyway.<br><br>
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.<br><br>
The IP/NP layer does perform the routing between OBL.<br><br>
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.<br><br>
Remember some of the Bus/Lan are networks onto themselves (for example)
JWST is using a SpaceWire network to move data without IP.<br><br>
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.<br><br>
On the other hand the SOIS API is non-normative since hardware devices
would not implement.<br><br>
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.<br><br>
Steve, put the copyright notice on the document during the shutdown
period. He will have to comment on why.<br><br>
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
:).<br><br>
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.<br><br>
If my clarifications lead to needed changes let me know.<br><br>
Cheers,<br>
Rick<br><br>
At 04:22 PM 6/10/2005, Scott,Keith L. wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">So
if I understand correctly, the architectural elements say that:</font>
<ul><font face="arial" size=2 color="#0000FF">
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)]</font><font face="arial" size=2 color="#0000FF">
Application interfaces to 'TCONS' are via sockets and/or a TCONS-specific
API.</font><font face="arial" size=2 color="#0000FF">
TCONS makes no claims to support QoS over paths containing multiple
OBLs</font>
</ul><font face="arial" size=2 color="#0000FF">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.</font><br>
<br>
<font face="arial" size=2 color="#0000FF">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.</font><br>
<br>
<font face="arial" size=2 color="#0000FF">
--keith</font>
<dl><hr>
<font face="tahoma" size=2>
<dd>From:</b> sois-tcons-bounces@mailman.ccsds.org
[<a href="mailto:sois-tcons-bounces@mailman.ccsds.org" eudora="autourl">mailto:sois-tcons-bounces@mailman.ccsds.org</a>]
On Behalf Of </b>Richard Schnurr
<dd>Sent:</b> Friday, June 10, 2005 11:38 AM
<dd>To:</b> sois-tcons@mailman.ccsds.org
<dd>Subject:</b> [Sois-tcons] White paper contribution.</font>
<dd>Hi all,<br><br>
<dd>OK, based on the last call I drafted the beginnings of a white
paper.<br><br>
<dd>I kept it short - hopefully you can all read the whole
thing.<br><br>
<dd>If we all agree to this structure and the descriptions I think we can
restart the books.<br><br>
<dd>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>
<dd>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>
<dd>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>
<dd>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>
<dd>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>
<dd>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>
<dd>I am on vacation next week. So this and the modified diagrams
are my contribution to the white paper.<br><br>
<dd>Rick<br><br>
<dd>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</u> - 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.
<dd>As always correct my thinking as required.<br><br>
<br><br>
<br><br>
<br><br>
</blockquote>
<x-sigsep><p></x-sigsep>
</dl>Richard G Schnurr Jr<br>
Chief Architect<br>
Electrical Systems Center<br>
Applied Engineering and Technology Directorate<br>
NASA GSFC Code 560.0<br>
Greenbelt MD 20771<br><br>
(301)-286-1852</html>