<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Keith,<br>
<br>
See comments below. I think some of these comments resulted from the
way I led into the section and didn't clearly separate the overall
network from a discussion focused on just the network layer. I'll be
working more on the section in the next few days.<br>
<br>
Keith Hogie<br>
<br>
<br>
Scott,Keith L. wrote:
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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. </pre>
</blockquote>
The network part was meant to be about just the network layer. That
could use some clarification. The thought was that at the network
layer you just want packet forwarding. There is not reliable ACK/NACK
operation at the network layer. It just receives packets, looks at the
destination address, and forwards the packet. Any "reliable" delivery
options come in at the transport layer. <br>
<br>
I started with the network layer to try to move away from circuit
concepts and get into network packet forwarding concepts.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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. </pre>
</blockquote>
Yes, missions will not necessarily use simplex as the norm but at the
network layer I was thinking more about basic packet forwarding and
then building on that with the upper layers.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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, ...) </pre>
</blockquote>
When using IP over a point-to-point serial link you don't need ARP.
ARP is needed in shared media LANs where you need to associate a MAC
address with an IP address. When running IP over serial links you just
have a routing table that tells you what serial interface to use to
forward the packet. The route needs to be set up somehow and on a
simplex link that might require manual route setup. But during a
spacecraft emergency, you need to do whatever needed to try to send a
packet over a simplex link.<br>
<br>
I was trying to emphasize that IP (network layer) doesn't require
two-way links to function. It is really just about packet forwarding.
Another point is that IP is not sensitive to propagation delay.
Routing entries need to be in place, but once they are, IP packets
simply forward and don't care how long it takes to get to their
destination because IP does not have any sort of handshake required. <br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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. </pre>
</blockquote>
Missions have been running without any QoS for years. IONET has been
running all NASA operational traffic over UDP/IP for years and control
centers and LZP facilities routinely receive passes with hundreds of
thousands of blocks without any loss. There are also TCP transfers
running on the same ground network. There are simple approaches like
prioritizing UDP traffic over TCP to take care of mixed traffic
problems. These are much easier to implement than requiring all
network nodes to participate in more complex QoS mechanisms.<br>
<br>
As far as an astronaut surfing the web and congesting a link,
wouldn't the astronaut's RF link and the mission RF link be two
separate links so there would not be any common low-rate RF link shared
by them. If their traffic merged somewhere, it would be on a larger
link and the UDP traffic can be prioritized to avoid problems. <br>
<br>
I guess I'm not sure the network layer has to provide QoS for
everyone and we need to make sure that it doesn't add any additional
delay for users who want low latency packet delivery.<br>
<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
The requirement is that the option must be available for one-way blind
commanding which is<br>
a requirement for all spacecraft. Normal commanding may use a two-way,
reliable <br>
protocol but the "network" must support a simplex mode for spacecraft
emergencies. We need to make sure there is always an option to run in
simplex mode at the network layer. <br>
<br>
Also some missions are planning on using things like TDRSS demand
access with only a one-way data flow. They would run lots of data over
one-way links and then might have a few two-way contacts every day for
any retransmissions needed.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
I have mixed feeling about messing around with too much QoS complexity
at the network layer. See comments below on diffserv.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">Security (note: may be 'TLS-like where only application data is
</pre>
</blockquote>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">authenticated / encrypted) -- not really a requirement for us; could be
pushed to the application but may be good to provide as an
infrastructure mechanism)
</pre>
</blockquote>
I left all the security stuff in the next section that is still getting
filled in. I wanted to focus on basic network concepts first and then
we can confuse people with all the security stuff in the next section.
That will mention things like IPSec at the network layer.<br>
<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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'? </pre>
</blockquote>
I'm not quite sure what that one means. It was just a thought that any
link protocol has to be prepared for intermittent links. Also that
data should not stop flowing in one direction on the link just because
there was and interruption on the link on one direction or the other.
Not sure how we want to state that.<br>
<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
Yes, exactly. R/S, or Turbo, or LPDC, often require fixed size
codeblocks. We need to make sure those sizes don't restrict the
network packet size.<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap="">
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)).
</pre>
</blockquote>
I'm not sure what to say about diffserv. I did a bit of web searching
to see what's up with diffserv and didn't find much current work. Most
of it was from 1998-2002. I'm not sure how popular it is yet and how
feasible it is to implement in our environment. Does anyone have any
updates on how and where diffserv is being used/deployed?<br>
<br>
<blockquote
cite="midEAD5C58F27640B429D87C4663AFE3535343221@IMCSRV1.MITRE.ORG"
type="cite">
<pre wrap=""> --keith
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:sis-csi-bounces@mailman.ccsds.org">sis-csi-bounces@mailman.ccsds.org</a>
[<a class="moz-txt-link-freetext" href="mailto:sis-csi-bounces@mailman.ccsds.org">mailto:sis-csi-bounces@mailman.ccsds.org</a>] On Behalf Of Keith Hogie
Sent: Thursday, August 18, 2005 3:25 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:sis-csi@mailman.ccsds.org">sis-csi@mailman.ccsds.org</a>
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
</pre>
</blockquote>
<pre wrap=""><!---->section.
</pre>
<blockquote type="cite">
<pre wrap="">See what you think of the general structure and contents and we can
discuss it at this week's telecon.
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
----------------------------------------------------------------------
Keith Hogie e-mail: <a class="moz-txt-link-abbreviated" href="mailto:Keith.Hogie@gsfc.nasa.gov">Keith.Hogie@gsfc.nasa.gov</a>
Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480
7700 Hubble Dr.
Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard
---------------------------------------------------------------------- </pre>
</body>
</html>