[Sis-csi] Finishing off the architecture book

[Scott, Keith L.]

All,

I'd like to skip the telecon today, but we need to get the architecture
book finished off.  I think the last thing we need is to introduce the
'phasing' notion as we discussed in Rome, and I had the action to write
some text to that effect.  Let's discuss over email.  I will also be
out next week, but back the week after.


How about the following as a short section on phasing in capability:
 
6	PHASED INTRODUCTION OF CAPABILITIES

Moving from traditional operations to a completely IP-based system in
one step would be jarring at best.  While the concepts of automated
data forwarding, routing, and network quality of service are mature and
have operational experience terrestrially, their applicability to a
'MANET of networks' composed of orbiting satellites, orbiting relays,
lunar outposts, and lunar transit vehicles leaves several questions.
One of the largest open questions is how to structure a dynamic routing
protocol to handle the changing connectivity among various spacecraft.
We thus propose developing the protocols to populate the architecture
presented here in three phases:

1.	Simple spacecraft without in-space routing
2.	Simplified in-space routing among cooperating spacecraft
3.	Advanced in-space routing among multiple spacecraft

In the first phase, spacecraft will not be required to use other
spacecraft as IP routers in order to reach the ground.  This admits the
use of layer-2 relays such as TDRSS, but greatly simplifies
network-layer routing.  Because the spacecraft may use different ground
stations and hence change their points of attachment to the Internet,
routing from ground-based systems to space-based systems is an issue
(routing toward the ground-based systems, which do not move within the
Internet topology, is trivial).  Techniques such as MobileIP would work
here, as would a more managed approach where GRE tunnels from the
spacecraft's 'home' location to the correct ground station are
configured and maintained from a mission operations center.

In the second phase, we will consider simple routing among spacecraft
that are designed to know of each other's existence and where the
in-space routing does not require a full dynamic routing protocol to
manage connectivity.  An example of such a situation would be an
orbiter-lander mission, where the lander could route data via the
orbiter to reach Earth.  This situation is not much more complex than
the first phase, since the only thing changing from the point of view
of the terrestrial routing is the orbiter's point of attachment to the
ground.

In the third phase we will consider the general case of
spacecraft-to-spacecraft routing where two spacecraft, A and B, can use
each other as relays to communicate with the ground, or may communicate
with the ground directly.  This is more complicated because spacecraft
A's could be directly attached to the ground (via a DTE/DFE link), in
which case packets from other locations on the ground to spacecraft A
should be routed to spacecraft A's home (assuming some form of
tunneling is used).  Spacecraft A's point of attachment could also be
via spacecraft B, in which case packets to spacecraft A would need to
be routed toward spacecraft B's home (again, assuming some form of
tunneling from spacecraft B's home location to the current ground
station serving spacecraft B).

========

		--keith