[Sis-csi] Cislunar section 4

Scott,Keith L. KSCOTT at mitre.org
Wed Aug 31 00:09:50 EDT 2005


Keith:
I like a lot of your section 4 but some issues with your network layer
requirements for cislunar comms.  The requirements seem entirely
centered around the need to handle simplex paths.  While I think we
have to be able to handle simplex paths, I don't think we want to count
on them as the norm.  There are lots of things in IP that won't work
right over pure simplex paths (you'd have to pre-load your ARP table,
you're not going to get ICMP messages, ...)  Things like network layer
QoS are, I believe, essential to getting missions to buy into the rest
of the cislunar stack.  We need to convince missions that during a
critical maneuver, their important data isn't going to get lost because
some astronaut is surfing the web.  Also, is it really a requirement to
NOT provide guaranteed delivery, or just that guaranteed delivery can
be met universally given the need to function over simplex paths?

I'd propose the following list of networking requirements (heavily
borrowing from yours):

End-to-end networking layer that can function over a set of
heterogeneous environment-specific link layers.
Support for gateways to connect legacy and future networks
Quality of Service mechanisms to protect important data from congestion
loss
Security (note: may be 'TLS-like where only application data is
authenticated / encrypted) -- not really a requirement for us; could be
pushed to the application but may be good to provide as an
infrastructure mechanism)
Ability to transmit over simplex paths for emergencies
Ability to support short command sequences for emergency commanding.
Ability to function over a range of end-to-end delays, starting with
~2.5s (lunar) and growing to minutes or tens of minutes over the next
20 years.
Capable of efficiently supporting voice, video, and data traffic

I think I agree with the data link requirements, but don't understand
'Resume/continue operation after link errors'?  The requirement to
support variable length frames at the data link layer (as a universal
requirement) is also problematic, I think.  If one uses Reed-Solomon
error correction, it's possible to support variable length data link
PDUs, it's just that the physical (underneath coding) frames have
discrete step sizes, right?

In your requirements for transport layers, you include QoS, which I
agree with (though I'd put at least a piece of it in network (e.g.
diffserv)).

		--keith

> -----Original Message-----
> From: sis-csi-bounces at mailman.ccsds.org
> [mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
> Sent: Thursday, August 18, 2005 3:25 AM
> To: sis-csi at mailman.ccsds.org
> Subject: [Sis-csi] Cislunar section 4
>
> All,
>
>    Here is the current version of section 4 of the Cislunar Green
> Book.  I chopped out all of the other sections to keep the file
> smaller.  It is not complete but is has some thoughts in each
section.
> See what you think of the general structure and contents and we can
> discuss it at this week's telecon.
>
>
----------------------------------------------------------------------
>    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
>
----------------------------------------------------------------------
> 




More information about the Sis-CSI mailing list