Subject: Text for MLD - cellular host draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 3 Jun 2002 18:12:55 +0200

Hi all, 

After some discussion on the list, I'd like to
propose the following text for MLD in the cellular
host draft:

	2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6

	MLD may be supported by cellular hosts. 

	2.9.1 MLD in 3GPP networks

	Within 3GPP networks, hosts are connected to their 
	default routers (GGSN) via point-to-point links. 
	Consequently, hosts cannot communicate directly with 
      each other using link-local addresses. Hence, joining 
      multicast groups for link-local multicast addresses is 
      not required. However, MLD is required when hosts run 
      applications that need to join multicast groups whose 
      scopes are larger than the link scope. 

Is this acceptable?

Hesham
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Tue, 04 Jun 2002 09:07:19 -0400

Hesham,
     The text looks fine to me.

Regards,
Brian

---

From: [email-masked]
Date: Tue, 04 Jun 2002 22:22:10 +0900

>      scopes are larger than the link scope. 

	i still don't understand why you are trying to impose additional
	restriction for link-local multicast groups (maybe i'm dumb).
	without MLD joins for link-local multicast groups, default routers
	won't be able to know which multicast group the 3GPP node is
	interested in.  there's no special text available in RFC2710 for
	p2p links.

itojun

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Jun 2002 18:07:26 +0300

Hi Itojun,

> interested in. there's no special text available in RFC2710 for

First some motivation in the practical situation. The
GGSN has no applications, and hence there wouldn't
be a link-local video distribution from it, as an
example. Furthermore, I believe IPv6 ND packets
are sent to the link regardless of the state of the MLD
situation on e.g. a Solicited Node address -- or perhaps
I have missed some text somewhere? Hence there'd be no use
of the MLD for the IPv6 routing functioanality either.
Obviously, there are no switches around in these interfaces.
Finally, MLD packets do consume bandwidth, particularly if
they need to be sent even when there is no traffic and we
are just listening e.g. on our solicited node mcast address.
(I'm not exactly sure how much this bandwidth is -- perhaps
someone could enlighten me? At least some initial packets
have to be sent, but is there a periodic refresh as well?)

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?

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.

I also wonder if the timers -- which are configurable
per the RFC -- could be tuned to minimize overhead?

Finally, I have a compromise proposal. I do appreciate
Itojun's point some time ago that MLD even on a p2p
link would allow the router to reduce traffic to the
link. This is because it would know whether there are
listeners or not. Perhaps in the future there will be some
new parts of IPv6, or some new applications for which this
would be useful, even in a 3GPP environment. However,
I do wonder about the Solicited Node multicast address
case. Assuming the rules about this are in the RFC
for the support of switches, could we use MLD for
all link-local and global addresses, except for all
nodes and solicited node multicast addresses? Given
that I can't find a place where ND would depend on
MLD, I think this would work well. And the case
is important, as all hosts would have these addresses
and would have to announce them over the network
otherwise. So, the proposal is to have the following text:

   MLD should be supported by cellular hosts.

   Within 3GPP networks, hosts are connected to their
   default routers (GGSN) via point-to-point links.
   This arrangement also precludes any network
   switches. Consequently, hosts cannot communicate
   directly with each other using link-local addresses.
   Furthermore, none of the entities along the link
   will be doing any address-based switching, and
   all messages sent to the point-to-point link
   normally arrive to the other end. As
   Neighbor Discovery operates without relying on
   MLD, joining on solicited node and all nodes
   multicast addresses is not required. 

   However, MLD is required for all other multicast
   addresses in all scopes.

Jari

---

From: Brian Haberman <[email-masked]>
Date: Tue, 04 Jun 2002 11:27:12 -0400

Jari,

> 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.

> means above IP then we could argue that we are following

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.

> 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

---

From: Markku Savela <[email-masked]>
Date: Tue, 4 Jun 2002 18:42:57 +0300

> From: [email-masked]

Once again, I must have missed something. Why is there ever any reason
to do MLD on any link-local group?

- any host on link will automaticly receive all multicast traffic that
  is sent to link-local group, at least if it itself is listening that
  group.

- what use would default router have for the info? There is nothing
  coming into link-local group from outside the link.

Perhaps, the RFC just should say "MAY use MLD" for link-local groups,
if someone really wants to do it for some reason.

---

From: Markku Savela <[email-masked]>
Date: Tue, 4 Jun 2002 20:12:02 +0300

> From: Markku Savela <[email-masked]>
> 

Well, from other posts here, I guess it's to help those switches and
such.

However, it does somewhat bother me, that we have an exact
specification, and before the standard is even ready, we are already
adding things that are on the verge of "layer breaking".

 [ as far as IPv6 is concerned, anything you send to a link, is
 supposed to be seen by anyone on the link without any additional
 work]

---

From: Bill Fenner <[email-masked]>
Date: Tue, 4 Jun 2002 16:12:58 -0700

>   As

I read "join" to mean the action performed on the IP stack to indicate
group membership (e.g. adding the group to the list of groups listened
to and notifying the link), but I don't think that's what's intended
here.  Perhaps more specific wording, like "sending MLD reports for
link-local multicast addresses is not required"?

  Bill

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jun 2002 08:28:17 +0300

> link-local multicast addresses is not required"?

Yes. Thanks.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Jun 2002 11:41:09 +0200 (CEST)

>    multicast addresses is not required. 

The term "joining" could mean e.g. "record the group membership
in the IP stack". Saying "sending MLD reports" would be much more exact
for what you are trying to say.

   Erik