[Sis-csi] Basic network diagrams

[Leigh Torgerson]

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..

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.

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.

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.

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).

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..

Leigh


At 3:38 AM -0700 10/19/05, Adrian J. Hooke wrote:
>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.
>
>>I'm not sure exactly how this diagram will be used.  For now it was
>>just an attempt to stick all sorts of acronyms in their relative
>>positions on the page.   It includes lots of other protocols and
>>technologies to help other folks understand where they fit and to
>>give us a map to scribble in potential options for further study.
>>
>
>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?
>
>///adrian
>
>
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi


-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           ltorgerson at jpl.nasa.gov
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20051019/2ac8e017/attachment.html