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

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

On 16/7/03 2:02 pm, "borderlt" <border@hns.com> wrote:

> 
> (ii) is where I see an issue.

Agreed in that this is the thing we need to drive a MPEG-2 receiver (i.e.
"tune/filter").

> I think it is needed.  But it is not ARP.  It
> is closer to reverse-ARP because, if I understand what you are saying, the
> question is what MPEG TS Multiplex, PID, MAC/NPA address should I use to
> listen for stuff sent to me.

Yes, I agree this function matches (ii).

It not "rarp" as I understand it, reverse-arp is about:

"given a L2 address (MAC, etc) what IPv4 address does this have?"

rarp is, e.g.,  typically used for auto-configuration of an interface.


So... IMHO, (ii) could be called "address resolution", let's look at the
function: are you trying to relate a IP address to a L2 address? - *BUT* as
you say, the use you make of this information at the Receiver is somehwhat
different. So we do have to be careful we identify this, ...

Are there other similar networks that use the information in the same way,
so we can learn from them?


> So, the comparison to existing mechanisms needs
> to be described carefully...
> 
YES, I'd like more precision of the function.

Gorry
> 
> John
> 
> 
> Gorry Fairhurst wrote:
>> 
>> 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
> 
> 
>