Subject: RE: BOF Agenda - Multicast Last-Mile Solutions

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 7 Jul 2003 15:40:47 -0400

Lloyd Wood wrote:

> Manfredi, Albert E wrote:
> 
> > Sorry, but I had exactly the opposite reaction.
> >
> > Over a broadcast channel, such as satellite, it seems to me, any
> > sort of encapsulation is just fine. At the receiving end*s*, the
> > receivers can easily reformat the packet to be unicast or multicast,
> > to enable the appropriate routing where routing matters.
> 
> what do you mean by 'reformat the packet'?

Reincapsulate the frame that was broadcast over the broadcast medium. That frame can be used by multiple systems, presumably, only one of which would need to worry about IP routing, multicast or otherwise.

> > The broadcast channel's individual streams can be differentiated in
> > any number of ways, including the use of Class D addresses
> > certainly. But that makes a weak argument for IP Multicast, I think.
> > For instance, what's wrong with using PIDs in MPEG-2 Transport
> > Stream? Or what about differentiating based only on a LLC/SNAP
> > header ID?
> 
> You'd have to indicate that the multicast packet was a multicast
> packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down
> the layers.

My fundamental disagreement with bringing up a broadcast channel is that the broadcast channel per se couldn't care less. There are no difficult routing decisions to be made in the satellite or other broadcast link. The broadcast channel is the equivalent of a single Ethernet link along the way, in a wired internet.

Bert

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 7 Jul 2003 20:52:43 +0100 (BST)

On Mon, 7 Jul 2003, Manfredi, Albert E wrote:

> Reincapsulate the frame that was broadcast over the broadcast
> medium. That frame can be used by multiple systems, presumably, only
> one of which would need to worry about IP routing, multicast or
> otherwise.

interesting way of looking at things. Not sure it's workable. I don't
see where IP routing comes in.

> My fundamental disagreement with bringing up a broadcast channel is
> that the broadcast channel per se couldn't care less.

the terminals receiving from that channel, however, do care when
discriminating. Channels are fundamentally physical, they don't care.
A shared link medium is, however, a different beast.

> There are no difficult routing decisions to be made in the satellite
> or other broadcast link. The broadcast channel is the equivalent of
> a single Ethernet link along the way, in a wired internet.

Collision management is rather different.

As it happens, Ethernet indicates multicast packets in its frame
structure via its own multicast address. There's a mapping.

(And if you have multiple spotbeams on the satellite, each
broadcasting to multiple terminals you have complex packet/frame
replication/identification issues.)

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 7 Jul 2003 20:52:43 +0100 (BST)

L.