[Sis-csi] Green book thoughts

[Keith Hogie]

All,

   Sorry for the late input but here are a few thoughts
and inputs for this afternoon's telecon.  I couldn't see
shipping the whole 6 MB around to convey
this little bit of info.

   These are based on Draft_15.doc

2.2.2  Telepresence/Telescience

...  At Cislunar (and Cismartian) distances there will be
significant degradation of such capabilities (telepresence) ...

   This is true at the outer limits of these environments, but Cislunar
also includes everything from low-earth orbit out to beyond the moon.
I think we often focus on Cislunar being only lunar missions and
forget about all of the other missions like all of the current
"Cislunar satellites" already in orbit around the Earth.

   Section 2.1 just got done mentioning that Cislunar covers
everything from LEO to L2.  Somehow we need to be careful about
making broad statements about Cislunar.  Do we need to break
down Cislunar into short, medium, and long or something like that.


2.2.6 Services unique to the ground environment

   Not sure about this section.  Some of these might apply to space 
links too.

3.3

   reference to "traffic types described in section 3" should be 2

4.0

Routed (definition)

In a packet-switched network, data packets are delivered across
multiple hops (links) with possibly multiple paths between a source
and destination.  Intermediate network nodes will receive a packet
from one link and then make a routing decision on which link
to forward the packet to the next node.  Packet routing based
on individual packet addresses allows a data source
to address packets to many different destinations and the packets
will be routed to the various destinations as they traverse the
network and its associated links.

4.2.1 IP Network Packet

   With respect to IPv4 vs IPv6 can we come to any conclusion on
one or the other.  My concern is that there is no installed
base of IPv4 or IPv6 in space right now.  If we keep offering both
then we need to implement and support both forever.  If we can
justify only IPv6, that could greatly simplify implementation
and future support issues.  It also requires support for
security which is something we need to start supporting anyway.

  Also, is it worth even mentioning SCPS-NP since IP header
compression can do about as good and there is lots of
real support for IP compression and no real support for SCPS-NP.
Again, the issue of if you offer options, each option will
eventually be used by someone, and the network ends up having
to support them all forever.

4.4 Automated Data Forwarding

   Not sure if the SLE reference really fits here.  That is a
reference to the old circuit switch concept and not routing
based on addresses in packets.  SLE doesn't do IP packet
forwarding and doesn't apply in an end-to-end IP architecture
does it

   Should this mention things like standard automated routing
protocols like RIP, OSPF, Mobile IP, MANET stuff, etc. along
with static routing.

4.4.1 Forwarding, Routing

   This mentions that "This will allow mission operations
personnel to maintain absolute control over the forwarding
process..."  They don't really have that control today and
won't have it in the future.  Today they may indicate that
they want their commands sent to a particular antenna but
they don't control the exact path from their control center,
across all links, to the antenna.

   I don't think we want to give them the impression that
they can control all routers in NASA's operational networks.

4.4.3 Quality of Service

   There are simple QOS options like priority queuing based
on UDP, TCP, port numbers, etc. that can also be implemented
very easily without the additional complexity of things like
diffserv, rsvp, etc.  We need to check and see what is
currently implemented in IONET.  I think they may currently
just prioritize UDP over TCP.


4.4.4 Security

   With IPv6 security is no longer an option.  It is part of
the spec.

4.4.5 Additional services

   Multicast has been used for the last 10 years in NASA's
ground networks to support efficient delivery of satellite
data to multiple destinations. The common application is
simultaneous delivery of realtime data to multiple control
center processing systems and level-zero processing
facilities.

4.6 Transport layer

   --- insert after first paragraph ---

   UDP provides a data delivery very similar to standard
TDM and CCSDS packet delivery systems that are currently
used for space communication.  It's unreliable delivery
attribute means that it does not utilize any process,
such as acknowledgments, for determining if the data
gets to its destination.  Reliable delivery can be
implemented over UDP in the application layer if desired
with applications such as CFDP.

   One advantage of UDP is that since it does not require
any acknowledgments, its operation is not affected by
propagation delay and it can also function over one-way
links.  UDP provides an alternative to TCP in scenarios
where TCP performance suffers due to delays and errors.
Since UDP doesn't require acknowledgments, it allows
end-system application implementors to design their
own retransmission schemes to meet their particular
environment.

   UDP is also commonly used for data delivery
scenarios where timeliness of delivery is more important
than completeness.  Common uses include streaming data
such as voice and video.  It is also used for multicast
delivery where the same data is sent to multiple
destinations and it is not desirable to have
multiple acknowledgments returning from all the
destinations.


4.8 Store-and Forward for Disrupted Environments

Seems to jump to DTN rather quickly.  We have survived
for many years doing store-and-forward based on files
or big chunks of data and that will still work fine for
many future missions.  We don't need to tell them that
they need to completely change what they are used to
just because we are putting in IP.

How about something like

A critical component of the cislunar architecture for dealing with cases 
where there is not an end-to-end path between source and destination is 
the use of store-and forward mechanisms.   The store-and-forward 
function can occur at either the packet level or file level. 
Traditional store-and-forward space communication occur at the file or 
mass-storage partition level with files being stored at each hop and 
forwarded later.  Another option is to do store-and-forward at the 
packet level with approaches such as Delay/Disruption Tolerant 
Networking (DTN).


5.0  Operations concepts

   These are basically Lunar scenarios.  Do we need to include basic LEO 
scenarios to let people know that Cislunar is not just lunar but 
everything from LEO to beyond the moon. Just a thought that there will 
still be lots of non-lunar missions coming up and I think we want this 
document to relate to them too.


   See you on the telecon at 3:30

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