UDLR topology

[Noritoshi Demizu <demizu@csl.sony.co.jp>]

I have heard that there can be at least three types of configurations
in communication via satellite.  There may be another types of
configurations for other types of uni-directional datalinks and even
for satellite links.

  (1) Single feed and multiple receivers in a `UDL' IP subnet
	- There can be multiple feeds in the world, but each feed has
	  its own set of receivers.  Each feed and its receivers
	  construct one IP subnet.  Strictly speaking, there are one
	  SOI of a feed and multiple ROIs of a subnet of receivers in
	  a `UDL' IP subnet.  So there are many UDL IP subnets in the
	  world.  Receivers can connect to multiple UDL IP subnets
	  if receivers have multiple ROIs.  If a feed has a multiple
	  SOIs, the feed can act as a feed on each `UDL' IP subnets.
	- e.g. low-cost VSAT, (IP over DVB?, IP over VBI?)

  (2) Separated multiple feeds and multiple receivers in a `UDL' IP subnet
	- Distances between feeds are typically long.  Each feed has
	  its own transmitter and, in many cases, its own receiving
	  equipment.  Typically, feeds cannot have a shared medium
	  between them, but some or many feeds can receive packets
	  sent from other feeds via receiving equipments.  So
	  mechanisms such as a mesh of tunnels are necessary only for
	  feeds that does not have receiving equipments.  (I'm not
	  sure current IP multicast works well for this purpose in
	  this configuration, because feeds would be distributed
	  nation-wide or continent-wide.)
	  Each set of feeds and receivers construct one `UDL' IP subnet.
	- If all feeds can be assumed to have receiving equipments for
	  all cases of this type of configurations, this type can be
	  ignored in UDLR.
	- e.g. high-grade VSAT with some receiving-only nodes
	       (typically, all VSAT can both send and receive.)

  (3) Multiple feeds at one place and multiple receivers in a `UDL' IP subnet
	- Distances between feeds are typically very short, and all
	  feeds use a common transmitter.  Typically, feeds and a
	  transmitter are connected via a shared medium such as
	  ethernet.  So, in many cases, feeds also may be able to
	  receive packets sent from other feeds via the shared medium.
	  There can be a bridge or an encoder between feeds and a
	  transmitter.  Such bridge may or may not have tunnels with
	  receivers on behalf of all feeds.  A subnet of SOIs of feeds
	  and a subnet of ROIs of receivrs construct a `UDL' IP subnet.
	- I think this types of configuration can be reduced to (1), by
	  replacing the bridge above with a router.  But I don't know
	  whether it will cause a problem.
	- e.g. (IP over DVB?)

Receiver side configurations are almost the same among these three
configurations.  Receivers may be a router, or may be a bridge.

So I think
  - on a tranceiver (a receiving feed)
	- In some multiple-feeds configuration, feeds can receive
	  packets sent from other feeds.  So such kind of feeds should
	  be supported in UDLR.  If the sending-capability and the
	  receiving-capability of feeds can be considered saparately,
	  the UDLR model does not need to consider so-called
	  "tranceiver".  Otherwise, I think it needs.
	  (Intuitively, I think it needs to consider of a "tranceiver".)

  - communication methods among feeds
	- Feasible communication methods between feeds depend on
	  configurations.
		- In the 1st configuration, there is no need of such
		  communcation.
		- In the 2nd configuration, UDL may support such
		  communication, or a mesh of tunnels are necessary.
		  IP multicast may work but I think in a very limited
		  situation.
		- In the 3rd configuration, feeds will be connected
		  via a shared medium in many cases.  If not, both IP
		  multicast and a mesh of tunnels works.  IP multicast
		  might be easier in some/many configurations.
		- There will be other methods for other configurations.
	- So we need to consider how to transfer packets from a feed
	  to other feeds case by case.

  - a router vs. a bridge
	- I'm not sure but theoretically a feed can be a bridge
	  instead of a router.  At this moment, everybody seem to
	  think a feed is a router.  So the possibility that a feed is
	  a bridge seems to be able to be ignored.  (I'm not sure)
	- Also a receiver can be a bridge instead of a router.
	  But this possibility seems to be able to be ignored, because
	  everybody seem to assume that a receiver is a bridge. (I'm not sure)

  - one-feed vs. multiple-feeds
	- At this moment, I'm not sure whether UDLR should support
	  multiple-feeds configuration. If all configuration can be
	  reduced to one-feed model without causing any new problem,
	  the topology that UDLR-WG assumes can be one-feed model in a
	  short-term solution.
	  But if there is a possibility that this assumption will
	  cause some problems for other datalinks or new usage of
	  satellite links, I think multiple-feeds model is better.

Regards,
Noritoshi Demizu