[Sis-csi] Basic network diagrams

[Keith Hogie]

Adrian,

   Thanks for the comments.  These were just attempts at some
graphics.  I'm looking for feedback to see if people think this
can help explain the packet routed network concept to other folks.

   See additional thoughts below.

Adrian J. Hooke wrote:

> I agree that some very simple "networking 101" pictures may be useful. 
> Forrest Warthman contributed a very nice tutorial at 
> http://www.ipnsig.org/reports/DTN_Tutorial11.pdf which maybe we should 
> consider adding to the Green Book as an Annex?
> 
> In terms of the slides proposed by Keith Hogie:
> 
> Slides 1, 3:
> 
> a) That bottom blue-white-pink loop that comes out of the intermediate 
> node is not clear; since it doesn't seem to help, maybe it should be 
> removed?

   After drawing the basic horizontal path it seemed a bit plain.  With
each intermediate node only having 2 interfaces, the routing aspect
doesn't come through as strong.  I put 3 interfaces on each intermediate
node to allow more alternate paths and added the bottom one.

   I agree that it's not obvious why it's there in the current diagram.
It really needs a sequence of slides to show how traffic could reroute
if the middle link goes out.  By adding more end nodes it could also
show how a source could address packets to multiple destinations.
However, adding all those more complex routing options starts making
the picture more messy.

   Not sure what level of complexity we want to pursue.

> 
> b) What's the key difference between slide 1 and slide 3? They both seem 
> to say much the same thing.

   Slides 2 and 3 are exact copies of slide 1.  Slide 2 just has the
link/physical layer removed and 3 has the application/transport layer
removed.  Slide 2 is there to show the software developers view and
how IP hides the physical layer details from the upper layers.  Slide
3 shows the other aspect that the physical layer folks don't need to
know anything about what applications are up above the IP layer.  If
you flip between 2 and 3 quickly it sort of shows that IP is the
common denominator between them.  However, the bottom node does sort
of mess up the effect since its IP part is not reflected in
slide 2.  Not sure whether we should drop the
bottom node or add its IP part and alternate paths into slide 2.

> 
> Slide 2:
> 
> a) This slide (as-titled) seems misleading since the applications 
> interface with (not shown) Application services, not directly with IP. 
> One of the principal original reasons for adopting/adapting Internet 
> protocols in space was to preserve user interfaces with native, 
> unmodified Application services. Yet in our quest for "IP purity" we now 
> seem to have inverted that logic by advocating the running of custom 
> Applications over native networking services. As such, this doesn't seem 
> to represent a very "User/Software" friendly view. See 4b below.

   I collapsed lots of layers into only 3 to make these diagrams as
simple as possible.  My main goal was to show people a view with a
packet routed network layer and then stuff above it and below it.

   As far as unmodified applications versus custom applications, we
have always used applications that were selected to deal with our
intermittent spacecraft links.  That normally reduces to some sort
of acknowledged commanding mechanism and a way to catch dumps of
bulk data from space.  There are TCP and UDP applications
available that can handle lots of space communication scenarios.
In the future I expect to see lots of standard applications used
as well as new ones written for the space environment.

> 
> Slide 4:
> 
> a) DTN is not a peer to applications such as e-mail and file transfer; 
> it should sit slightly below them and slightly above the TCP/UDP 
> Transport layer
> 

   I didn't like the way that lots of things in this diagram came
out.  For starters I was just trying to stick lots of acronyms
on the page and get them somewhat organized by layers.  I didn't
add connecting lines because that got way to messy since there are
many ways in which these can be connected.

   I think there may also be configuration where file transfer
actually fits under DTN and email or they can be all by themselves.
Of course they can also operate over TCP or UDP in various
configurations.  This was an initial attempt at drawing this and
I agree it needs work.

> b) TCP should be fully allowable over RF and optical environments - it 
> can be made to work quite well. Why is this slide implicitly advocating 
> everything over UDP? Max Repaci and the guys at UMD should have 
> something to say here.

   There was no intention to say that TCP can only be used over the links
on the left and UDP over the links on the right.  I just put some TCP
and UDP blobs to show where they fit in the overall picture.  I didn't
add lines to show the lower layers for each.  I think there are
probably cases where TCP can be used over any of the lower layers just
like UDP can.

  My main goal was to show where TCP and UDP fit and that since
they are above IP they don't care what the lower layers are.

> 
> c) Informative or not, this is a CCSDS document and as such - to avoid 
> confusion - it should only illustrate Link and Physical layer protocols 
> that are in the current CCSDS protocol suite and which have either been 
> adopted by the CCSDS agencies or are under active consideration. For the 
> "RF" domain those should be AOS, TM, TC and Prox-1. Assuming that the 
> "Cable" (wired?) domain also embraces LANS on a spacecraft or on a 
> planetary surface, the current SOIS candidates such as Spacewire should 
> be added . For the "Optical" domain, they should be simply left as "??".

   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.
My current thought is that this may not even belong in the Cislunar
Green book but be used more as a corkboard to stick technologies on.
I think we need something like that to help organize possible
solutions as we move forward.  I'm not sure what's going to happen
as we try to start listing more details like routing protocols,
QoS mechanisms, and security options.

> 
> ///adrian
> 
>
----------------------------------------------------------------------
   Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
   Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
   7700 Hubble Dr.
   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
----------------------------------------------------------------------