Jari,
> But I do understand that the RFCs must be followed.
> However, I wonder if you Brian could say something
> about the background for the link-local and the
> Solicited Node multicast address requirements,
> were they done specifically to allow switches to operate
> or for some other reason?
Using MLD to signal interest in link-local multicast addresses
allows for two things:
1. Signal interest in a group to all link-local
listeners (hosts and routers)
2. Allowing switches to properly forward link-local
multicast addresses
In the specific case of GGSN <--> UE, there are no switches
and the GGSN has already configured the UE with the Interface
ID. So, the GGSN already knows what the corresponding Solicited
Node multicast address will be. In that case, sending an MLD
Report will not benefit either the GGSN or the UE.
>
> I also wonder about text in Section 2, which says
> that MLD should be on all interfaces from which
> an application or upper-layer protocol has requested
> reception of multicast packets. I wonder what "upper
> layer" means in this particular case...? If it
> means above IP then we could argue that we are following
> the RFC.
It means any code in the device that wishes to utilize IP
multicast. Neighbor Discovery qualifies by that definition
and it is the primary user of the Solicited Node multicast
address.
I believe that the important text is the first paragraph of
Section 2:
The purpose of Multicast Listener Discovery (MLD) is to enable
each IPv6 router to discover the presence of multicast listeners
(that is, nodes wishing to receive multicast packets) on its
directly attached links, and to discover specifically which
multicast addresses are of interest to those neighboring nodes.
Since the GGSN already knows which link-local multicast addresses
the UE is interested in, I believe the cellular host doc is
compliant with RFC 2710.
>
> I also wonder if the timers -- which are configurable
> per the RFC -- could be tuned to minimize overhead?
Sure. Section 7 of RFC 2710 defines all the timers and identifies
which ones can be modified.
One final comment. The future evolution of 3GPP standards may
lead towards more usage of IP multicast (including the subnet-local
range). If that occurs, 3GPP will have to look very closely at
how MLD (or MLDv2) fits in the architecture.
Regards,
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
