Subject: Two strawpeople for last mile multicast

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 11 Jul 2003 15:12:23 -0400

From the discussion so far, I gather that a couple of the problems that have to be solved are (a) how to count group membership and (b) how to allow multicast routers to unicast multicast packets through edge routers, to the group members.

Taking each one independently at first, how about:

1. Counting membership.

All that's required here is to have an optional IGMP mode whereby each group member is made to respond to IGMP queries by using the (unicast) source address of the querier. That way, no other member will hear the join report, and every member will be forced to send these join reports. The multicast router can keep track. Now that each multicast router has info on every host's membership, that info can be passed back to whomever needs it, in an unspecified manner. For example, if PIM-SM is used, it shouldn't be difficult to send the membership info back to the RP? In any event, this part of the problem affects only the multicast routers and whoever needs to keep track of overall membership.

2. Unicast the multicast packet.

The problem here is to preserve the IP group address information somehow, while creating a unicast packet which is originated by the closest multicast router to each host. Many people expressed a dislike for some sort of tunnel. I agree. How difficult would it be to create a new IP header option, which would incorporate (S, G)? This ought to work for IPv4 or IPv6. When this new option is invoked, the end user knows to read the incoming packet as a multicast packet. The IP Souce Address of the packet would be the multicast router's source address, but the actual multicast source address is preserved, along with the group address, in the new option overhead words (making this compatible with SSM). 

3. IGMP in the unicast-only edge router environment.

IGMP relies on multicast addressing entirely. What if IGMP frames were sent by the multicast router to each member of the group using the scheme described in #2 above? A well-known UDP Port ID could be used to differentiate this IGMP "unicast multicast" packet from the normal data "unicast multicast" packets. The source address incorporated in (S,G) in the new IP header option words, for this unicast IGMP query, would match the IP Source Address of the packet, both source addressing being the address of the closest multicast router.

4. To which hosts are IGMP all hosts queries sent?

With normal IGMP, all hosts queries are sent to the "all hosts" multicast address. Also, with normal IGMP, hosts can send join reports immediately, without waiting for an IGMP query. Neither of these mechanisms can work here. Can we postulate a separate "cold start" mechanism here? Such as a web site, which permits hosts to indicate they want to join a particular multicast group, which in turn causes the appropriate multicast router for that host to start sending the unicast IGMP queries to that host? At which point, of course, the joiner will know the unicast address of the multicast router? Etc. etc.?

Bert

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 11 Jul 2003 12:29:55 -0700 (PDT)

On Fri, 11 Jul 2003, Manfredi, Albert E wrote:

-) >From the discussion so far, I gather that a couple of the problems
-) that have to be solved are (a) how to count group membership and (b)

I don't think counting group members is a goal of this effort.  Counting
viewers is a task that can be easily handled by the applications
themselves.  Indeed, some apps already do this today.

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 11 Jul 2003 12:29:55 -0700 (PDT)

---

From: Liming Wei <[email-masked]>
Date: Fri, 11 Jul 2003 12:53:32 -0700 (PDT)

> From: "Manfredi, Albert E" <[email-masked]>
> 
> >From the discussion so far, I gather that a couple of the problems
> >that have to be solved are (a) how to count group membership and
> >(b) how to allow multicast routers to unicast multicast packets
> >through edge routers, to the group members.

> All that's required here is to have an optional IGMP mode whereby
> each group member is made to respond to IGMP queries by using the
> (unicast) source address of the querier. That way, no other member
> will hear the join report, and every member will be forced to send
> these join reports. The multicast router can keep track. Now that
> each multicast router has info on every host's membership, that info
> can be passed back to whomever needs it, in an unspecified manner.
> For example, if PIM-SM is used, it shouldn't be difficult to send
> the membership info back to the RP? In any event, this part of the
> problem affects only the multicast routers and whoever needs to keep
> track of overall membership.

This is clever, but the problem is it fails the IGMP snooping switches
in between the hosts and the last "router". There are almost always
some layer 2 IGMP snooping devices in between them.

Also, there are already well established and widely-available
solutions to collect accounting data from broadband subscribers. As
long as the last hop "router" has the membership information, it will
be sufficient for all magics to happen. There is no need to propogate
such information via a routing protocol to the PIM RP.

> The problem here is to preserve the IP group address information
> somehow, while creating a unicast packet which is originated by the
> closest multicast router to each host. Many people expressed a
> dislike for some sort of tunnel. I agree. How difficult would it be
> to create a new IP header option, which would incorporate (S, G)?
> This ought to work for IPv4 or IPv6. When this new option is
> invoked, the end user knows to read the incoming packet as a
> multicast packet. The IP Souce Address of the packet would be the
> multicast router's source address, but the actual multicast source
> address is preserved, along with the group address, in the new
> option overhead words (making this compatible with SSM).

The cost of turning on multicast on the last hop router can not
be avoided or postponed. Period.

I know there are some interests in trying this out. But it won't
really have the effect folks imagined. Neither the subscriber nor the
last mile service provider or even the content provider will see a big
difference. They will conclude that multicast does not really matter.

> IGMP relies on multicast addressing entirely. What if IGMP frames
> were sent by the multicast router to each member of the group using
> the scheme described in #2 above? A well-known UDP Port ID could be
> used to differentiate this IGMP "unicast multicast" packet from the
> normal data "unicast multicast" packets. The source address
> incorporated in (S,G) in the new IP header option words, for this
> unicast IGMP query, would match the IP Source Address of the packet,
> both source addressing being the address of the closest multicast
> router.

See comment above.

-Liming

> With normal IGMP, all hosts queries are sent to the "all hosts"
> multicast address. Also, with normal IGMP, hosts can send join
> reports immediately, without waiting for an IGMP query. Neither of
> these mechanisms can work here. Can we postulate a separate "cold
> start" mechanism here? Such as a web site, which permits hosts to
> indicate they want to join a particular multicast group, which in
> turn causes the appropriate multicast router for that host to start
> sending the unicast IGMP queries to that host? At which point, of
> course, the joiner will know the unicast address of the multicast
> router? Etc. etc.?

---

From: Liming Wei <[email-masked]>
Date: Fri, 11 Jul 2003 12:53:32 -0700 (PDT)

See comment above.

-Liming