[Sois-tcons] White paper contribution.

Mon Jun 13 12:38:16 EDT 2005

Jane,

Did you put those in the public or private area?  All I can see in the
public document library is a folder with 'Meetings [sic] Info"

        --keith

________________________________

	From: sois-tcons-bounces at mailman.ccsds.org
[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of Jane K.
Marquart
	Sent: Monday, June 13, 2005 12:04 PM
	To: Richard Schnurr; Scott,Keith L.;
sois-tcons at mailman.ccsds.org
	Subject: RE: [Sois-tcons] White paper contribution.

	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/edb04391/attachment-0001.html