<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Sis-csi] Basic network
diagrams</title></head><body>
<div>When I think of how to explain some of this stuff to people who
haven't the foggiest idea what TCP/IP means, I have to back up to a
more abstract or functional level..</div>
<div><br></div>
<div>When trying to explain all this stuff to a mere mortal who just
wants data to get from point A to point B somehow, we have 3 concepts
that are important: 1. Links, 2. management of links when more than
one is needed to get from A to B, and 3. management of data flows by
content (and eventually priority) once the final destination is
reached.</div>
<div><br></div>
<div>1. Everyone basically understands links. What they don't
understand is why all the fuss about protocols. So you need them for
automation of both end-to-end data paths and for the
sorting/prioritization of data flows.</div>
<div><br></div>
<div>2. You can handle the management of links and switching between
multiple possible paths using Routing protocols. Couple of ways to do
that, IP being the means Keith shows of course. For dissimilar
networks (no common address space), we have DTN BP. For non-IP-based
systems, we have CFDP EP or SFO.</div>
<div><br></div>
<div>3. Addressing of data by TCP/UDP port or by CCSDS virtual channel
is how you automate the management of data flowing to the right place
on the other end of a link or series of links. Again, for some
systems, TCP/UDP is fine, for others, CCSDS VCs work (and work with a
very large currently installed base).</div>
<div><br></div>
<div>The main message is that single channel, manually-managed links
are tantamount to having the old party line and operator switchboard
telephone system. We need new means of automation, but we have to be
careful to pay due regard for both legacy systems and for systems that
consist of disconnected or disjoint networks that do not share common
address space. Light time considerations are also a factor in choosing
what protocol to use of course - have to fold that into the story as
well..</div>
<div><br></div>
<div>Leigh</div>
<div><br></div>
<div><br></div>
<div>At 3:38 AM -0700 10/19/05, Adrian J. Hooke wrote:</div>
<blockquote type="cite" cite>Keith: thanks for the clarifications. I
guess that the exercise points out that if we are going to put in some
basic tutorial information, it helps to keep it really simple so that
people don't read specific design choices into it. That's why I prefer
something like Forrest Warthman's diagrams.<br>
<blockquote type="cite" cite><font color="#0000FF">I'm not sure
exactly how this diagram will be used. For now it was<br>
just an attempt to stick all sorts of acronyms in their relative<br>
positions on the page. It includes lots of other protocols
and<br>
technologies to help other folks understand where they fit and to<br>
give us a map to scribble in potential options for further
study.</font><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
That may be appropriate for a document that is attempting to justify a
large technology development program, but - as standardizers - aren't
we trying to narrow the options here? It seems like our primary
current customers (ESMD and Aurora) are mainly looking for a robust,
well-proven, consensus architecture that will do the job, not a
shopping list of new technologies in which to "invest". So
shouldn't the Cislunar work focus on just adding the necessary and
sufficient set of new capabilities onto the current installed base in
an evolutionary way, rather than starting over?<br>
<br>
///adrian<br>
</blockquote>
<blockquote type="cite" cite><br>
_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<br>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>--------------------------------------------------------------------<br
>
J. Leigh
Torgerson <span
></span
> <span
></span> ltorgerson@jpl.nasa.gov<br>
Jet Propulsion Laboratory - Communications Systems Research Sec.
331<br>
NASA Space Communications Protocol Standards (SCPS) Project CTM<br>
(818)
393-0695 <span
></span
> <span
></span
> <span
></span> (818) 393-4643 fax<br>
--------------------------------------------------------------------</div
>
</body>
</html>