Re: Re the AR draft (http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt)

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Good questions, see below.

On 15/7/03 12:54 am, "borderlt" <border@hns.com> wrote:

> 
> Gorry,
> 
>   I don't know, but I missed the announced re the AR draft.  So, I had not
> read it prior to this afternoon's meeting.  But, I have read it now...
> 
>   I think the unicast problem to be solved needs to be illustrated more
> clearly in the draft.  Address resolution has different purposes for unicast
> and multicast.  For multicast, it relates to determining an address to receive
> on.  The requirements for this seem covered by the draft.  But, for unicast,
> address resolution means figuring out the address you need to send to.  With a
> DVB broadcast, I see three possibilities:
> 
>   (1) A host at the DVB broadcast receiver needs to resolve an address that
> is at the DVB broadcast sender;
>   (2) A host at the DVB broadcast receiver needs to resolve an address that
> is at another DVB broadcast receiver;
>   (3) A host at the DVB broadcast sender needs to resolve an address that is
> at a DVB broadcast receiver.
> 
> Unless you are assuming mesh (which is really not DVB broadcast, and therefore
> is a different scope), (1) and (2) are really the same in that the host at the
> DVB receiver doesn't know the difference.  In either case, the address which
> needs to be determined is the MAC address of the device at the DVB sender to
> which the IP packet should be forwarded (probably a router).  Even if it is
> not a router, some device at the DVB sender has to relay the IP packet back to
> the DVB broadcast channel and this is really the device which then needs to
> resolve the specific DVB receiver MAC address.  This is basically (3).  So, it
> seems like (3) is the problem which needs to be solved.  But, the draft
> doesn't come across that way...
> 
>   Of course, it is possible that I am thinking about the wrong problem.
> Hence my first statement re needing to more clearly define the problem being
> addressed...
> 
> 
> John
> 

I agree with what you say, but I am not sure I yet know what you want to be
added to the ID.  Let me try to reflect what you say in different words and
see if I do understood this correctly, if not, please do tell me where I go
wrong.


Can we first define "TS Multiplex" - as a single physical bearer (carrier,
another TS sent on a different carrier / channel, whatever)

Looking at the three cases:

(1) Seems to be the use of AR for an IP packet send operation, where the
resolved address is a (PID, MAC/NPA address) that resolves to this TS
Multiplex. The sender already has an AR database with an entry for the IP
address.

(2) As above, but where the address is not currently being sent. It may
resolve to a different MPEG TS Multiplex - So this could be mesh
connectivity or could be a MPEG-2 transmission system with multiple outbound
links. There's a need to co-ordinate between a number of separate address
resolution databases (for each TS Multiplex). The AR could be performed by
another system, or we could have this function centralised in one or more
(replicated) databases so a receiver can do the address mapping with AR
information from a known place.

(3) Seems to have three definite uses:

(i) At a sender (encapsulation gateway), where AR provides the (MPEG TS
Multiplex, PID, MAC/NPA address) to be used to send unicast, IPv4 subnet
broadcast and multicast packets.

(ii) At a receiver, where AR resolves an IP unicast or IPv4 broadcast
address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the
receiver to set filters to let this traffic pass to the IP layer. This is
true for unicast, and IPv4 subnet broadcast. Usually this operation is
infrequent, e.g. Following the equivalent of an "ifconfig" on the interface.

(iii) At a receiver, where AR resolves an IP multicast address to the (MPEG
TS Multiplex, PID, MAC/NPA address), and allows the receiver to set filters
to let this traffic pass to the IP layer. This operation may need to be
performed many times based on IGMP, MLD, and Multicast Routing protocol
operation.


---

John, Is this text going the right way???

Would section 3.3 of the AR ID be a good place for this sort of description?

Gorry