<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Sis-csi] RE: networking
details</title></head><body>
<div>Dave,&nbsp;&nbsp; You are correct and this stuff that is flying
around is just religious ferver.&nbsp;&nbsp; I have been trying to get
a picture of the in space networking needs for Constellation for a
long time and have yet to see anything that is operationally blessed.&nbsp;
We can talk about routing desires for ever but what are the real
requirements.&nbsp; Are things going to take random walks in space or
are missions and hardware movements going to scheduled and
exhaustively tested before anything moves.&nbsp; Is automated address
management needed, or is it over kill for the first 30 years of the
program?&nbsp;&nbsp;&nbsp; And If the environment in the later years
of the program is centered around the Moon or Mars, how will the
delays effect the operational use of UDP.&nbsp; Deep space missions
have been forced to use store and forward operations for years, and
the protocols supporting those missions are focus for that
environment.&nbsp; So can anyone supply an operational scenario that
requires the advanced networking features that IPv6 brings to the
table. </div>
<div><br></div>
<div>At 2:40 PM -0500 2/9/07, Dave Israel wrote:</div>
<blockquote type="cite" cite>Before another whole thread starts about
link layer issues again, can somebody explain why the link layer
matters are so critical at this time that we keep spending time and
energy debating them, instead of working on the many networking issues
that need to be resolved?&nbsp; I'd rather see that discussed, than
any arguments about any link protocols.<br>
<br>
It seems to me that the real need is to get missions to start evolving
to networking based communications first.&nbsp; Once that starts,
optimization may follow.&nbsp; How much time have we lost in
&quot;IP<i> versus</i> CCSDS&quot; debates, when in reality there
really isn't mutually exclusive decision required?<br>
<br>
Dave<br>
<br>
At 02:20 PM 2/9/2007, Keith Hogie wrote:<br>
<blockquote type="cite" cite>Adrian,<br>
<br>
&nbsp; A major concern is what you mentioned below about Virtual
Channels.<br>
Those are a CCSDS data format that was developed 20 years ago and
was<br>
a fine solution for the time.&nbsp; It sounds like you are proposing
that<br>
that VC data structure be maintained as the underlying format for
civil<br>
space programs for the next 20 years.&nbsp; Does it make sense to<br>
plan on extending the life of a 20 year old protocol format for<br>
20 more years or is it time for an upgrade or replacement of<br>
the VC format.<br>
<br>
&nbsp; During the last 20 years lots of protocols have come and gone
and<br>
been replaced by new ones that better suit users current needs.&nbsp;
The<br>
commercial world primarily uses Frame Relay and DVB over thousands of
satellite links supporting tens of thousands of users.&nbsp; They
have<br>
created a very large commercial market of internationally<br>
interoperable products with much better layering and function<br>
support than the basic CCSDS VCDU.<br>
<br>
&nbsp; So it seems that a major question is whether the current VC<br>
structure is the best structure to use for the future or is it<br>
time to upgrade to more current solutions at that level?<br>
<br>
&nbsp; As far as future IP missions interoperating with future
missions<br>
that see no need for IP, that's fine but then they don't have any<br>
plans to communicate with future IP missions anyway.&nbsp; Ground
stations<br>
can still support both IP and non-IP formats as many do already.<br>
The facilities, antennas, transmitters, and receivers still need<br>
to do their jobs just the same.&nbsp; The real question is whether
the<br>
bits coming off the space link go into a CCSDS specific box that<br>
processes VCs or if the bits go into a commercial router.&nbsp;
This<br>
is not a major change to the infrastructure.&nbsp; Yes, it is a
change,<br>
but the communication world has changed drastically over the last<br>
20 years and we need to decide if it is time for the civil space<br>
community to catch up or if it wants to keep doing its own thing.<br>
<br>
Keith<br>
<br>
<br>
Adrian J. Hooke wrote:<br>
<blockquote type="cite" cite>Maybe this is a good time to take stock
of where we are. I think that it is fair to say that there is broad
international agreement that:<br>
1. We can see future requirements for the emergence of a more
networked approach to space communications.</blockquote>
<blockquote type="cite" cite>2. Accordingly, we need to develop a
migration strategy that leads us towards more capable networking
protocols.<br>
3. IP has a role in that migration strategy.<br>
Beyond those elements of consensus, it's not clear that there is much
agreement on how or when to initiate change.<br>
At 06:09 AM 2/8/2007, Keith Hogie wrote:<br>
<blockquote type="cite" cite>&nbsp; Moving to spacecraft using
Internet protocols a change to the whole space communication
concept.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
snip<br>
<blockquote type="cite" cite>
<blockquote type="cite" cite>If we start launching some of our future
systems with no routed IP, is there a clean path for them to
&quot;migrate&quot; and be full participants in the future
network.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>Turn that around. If we start launching
*some* of our future systems exclusively with routed IP, is there a
clean path for them to be full participants in the future
international community of missions that see no need for it?<br>
Nobody's arguing that there won't be an increasing need for portions
of the international space mission support infrastructure to adopt
more powerful routing technologies. When you need IP and IP works, you
should use IP. But does that mean that *everything* has to become
IP-based, all at once? And yes, there's a migration path: it's called
international space standardization in general and in particular it's
called a Virtual Channel. It means that you can run part of your
system using existing infrastructure, in parallel with part of your
system using IP-based approaches. Change the mix of traffic on the VCs
and you can migrate with hardly any impact.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
----------------------------------------------------------------------<br
>
&nbsp; Keith
Hogie&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e-mail:
Keith.Hogie@gsfc.nasa.gov<br>
&nbsp; Computer Sciences Corp.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
office: 301-794-2999&nbsp; fax: 301-794-9480<br>
&nbsp; 7700 Hubble Dr.<br>
&nbsp; Lanham-Seabrook, MD 20706&nbsp;
USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 301-286-3203 @
NASA/Goddard<br>
----------------------------------------------------------------------<br
>
<br>
_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<br>
&nbsp;http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi<br>
</blockquote>
</blockquote>
<blockquote type="cite"
cite>______________________________________________________________<br
>
Dave Israel<br>
Leader, Advanced Technology Development Group<br>
Microwave &amp; Communication Systems Branch<br>
NASA Goddard Space Flight Center&nbsp; Code 567.3<br>
Greenbelt, MD 20771<br>
Phone: (301) 286-5294&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax:&nbsp;&nbsp;
(301) 286-1769<br>
E-mail: dave.israel@nasa.gov<br>
<br>
&quot;Without deviation from the norm, progress is not
possible.&quot;&nbsp; -Frank Zappa</blockquote>
<blockquote type="cite" cite><br>
_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<br>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</blockquote>
<div><br></div>
</body>
</html>