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

[borderlt <border@hns.com>]

(ii) is where I see an issue.  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.  So, the comparison to existing mechanisms needs
to be described carefully...


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