General Considerations

Architectures are presented in evolutionary order starting from basic ones and ending with more sophisticated. Each subsequent architecture usually addresses some weaknesses of a previous one. If some parts of previous architecture are repeated then corresponding pros and cons apply and are repeated.

In architectures described below that use some implementation of unreliable multicast transport, it is assumed that the transport will deliver most of the packets. Implementations of reliable multicast transports (on top of provided unreliable multicast transport) over lossy networks are generally very inefficient.

"Star"

Each host on each spacecraft is running NS which is connected to every other spacecraft's host's NS. This is a typical peer-to-peer architecture with all the pros and cons associated with such architectures.

Pros:

• Robust - failure of any participant does not affect the others.
• NS can be used as is.

Cons:

• Additional mechanisms for peer discovery.
• Potentially redundant network traffic.

Implementation:

• Discovery and interconnection mechanism (outside NS) has to be designed and implemented. Prototype could work as follows:
  1. each NS is registered in a NamingService
  2. when new host is brought up it discovers (via NamingService directory scanning) all other hosts and connects to them, registers itself in NamingService, and notifies all other hosts that they should rescan the NamingService directory.

"NS-per-Spacecraft"

Each spacecraft has its "hub" NS. Each host's NS is connected to such a hub. All hubs across all spacecrafts are interconnected in a "star" manner.

Pros:

• Bringing up new host is easy.
• Intra-spacecraft traffic does not leave the spacecraft.
• Inter-spacecraft bandwidth conservation (especially if intelligent filtering criteria propagation is implemented in NS).

Cons:

• Additional mechanisms for inter-spacecraft peer discovery.
• Spacecraft-wide single point of failure.

Implementation:

• Discovery and interconnection mechanism (outside NS) has to be designed and implemented for inter-spacecraft peer discovery.
• Intelligent filtering criteria propagation. This is a special support for federation in NS.

"Master Hub"

Like "NS-per-Spacecraft" except instead of interconnecting all spacecraft's hubs in a "star" manner, a "master" hub is set to which all spacecraft's hubs are connected.

Pros:

• Bringing up new host or spacecraft is easy.
• Intra-spacecraft traffic does not leave the spacecraft.
• Inter-spacecraft bandwidth conservation (especially if intelligent filtering criteria propagation is implemented in NS).

Cons:

• Single point of failure.
• Master hub could become a bottleneck.
• Not clear where to put master hub (special tiny spacecraft?).

Implementation:

• Intelligent filtering criteria propagation. This is a special support for federation in NS.

"Total Multicast"

Each host's NS is connected to a global multicast group.

Pros:

• Zero setup cost (no need for NamingServices, etc).
• Bringing up new host or spacecraft is easy.
• More bandwidth-efficient than "Star".

Cons:

• Potentials for bandwidth waste (e.g. spacecraft-local messages are delivered to all spacecrafts).

Implementation:

• Implementation of reliable multicast transport (can use TMCast for prototype, modification for production, depending on ordering requirements).
• Integration of reliable multicast transport into NS as an alternative message delivery medium.

"Intra-Spacecraft Multicast"

Inside a spacecraft each host is connected to a spacecraft-local multicast group. Outside a spacecraft NSs are interconnected in a "star" manner or via a "master hub".

Pros:

• Zero setup cost (no need for NamingServices, etc) inside a spacecraft.
• Bringing up new host inside a spacecraft is easy.
• Bandwidth-efficient inside spacecraft.

Cons:

• Discovery and interconnection mechanism outside spacecrafts.

Implementation:

• Implementation of reliable multicast transport (can use TMCast for prototype, modification for production, depending on ordering requirements).
• Integration of reliable multicast transport into NS as an alternative message delivery medium.
• Discovery and interconnection mechanism (outside NS) has to be designed and implemented for inter-spacecraft peer discovery.

"Inter-Spacecraft Multicast"

Inside a spacecraft hosts are interconnected using "star" or "hub". Outside, spacecrafts are connected to a multicast group.

Pros:

• Zero setup cost (no need for NamingServices, etc) outside spacecrafts.
• Bringing up new spacecraft is easy.

Cons:

• Potentially redundant network traffic inside spacecraft.

Implementation:

• Implementation of reliable multicast transport (can use TMCast for prototype, modification for production, depending on ordering requirements).
• Integration of reliable multicast transport into NS as an alternative message delivery medium.

"Two-layer Total Multicast"

This architecture is a combination of "Inter-spacecraft" and "Intra-spacecraft" multicast with a per-spacecraft "gateway" NS between spacecraft-local multicast group and global multicast group.

Pros:

• Zero setup cost both inside and outside spacecrafts.
• Bringing up new spacecraft or host is easy.
• Bandwidth-efficient both inside and outside spacecrafts (Provided intelligent filtering criteria propagation is implemented).

Cons:

Implementation:

• Implementation of reliable multicast transport (can use TMCast for prototype, modification for production, depending on ordering requirements).
• Integration of reliable multicast transport into NS as an alternative message delivery medium.
• Implementation of intelligent filtering criteria propagation for multicast-interconnected NSs.