Subject: mboned: Solicit feedback on draft-pashby-mboned-mc-scoped-addr-00

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Tue, 20 Sep 2005 13:58:52 -0500

I would like to solicit feedback on my draft-pashby-mboned-mc-scoped-addr-00. It was scheduled to be presented in the mboned WG, but was not due to the combining of mboned WG and imad BOF.

The major issue is making sure that large multicast flows never collide with groups that a host is required to join, i.e. Solicited Node Address (SNA). Take for an example that an application selects a multicast group for a large multicast flow, following the current method defined in RFC3307. It calculates a 32 bit random number, sets the high bit and uses this for the lower 32 bits of the address. Independently, a host joins the multicast group for its SNA. If the lower 32 bits of these addresses match then the host will be sent the multicast flow and the host will have to discard the flow at the IP layer. If that host was performing a real-time task, the overhead of discarding the traffic could cause it to fail its real-time task. One might argue that the probably is very low, 1 in 2 billion. However the more hosts on the network, the more addresses per host, the more multicast flows and the more often the multicast flows are created, significantly increases the probability. A low probability is acceptable only if a zero probability is not achievable in real-time mission critical networks, where a collision may have catastrophic consequences.

The solution is simple: define the range for dynamically assigned addresses not to overlap with the ranges that all hosts are required to join. The draft recommends rather than just setting the high bit that the next bit is reset. This will make sure that it does not overlap with the SNA range, while making the address selection simple. 

The draft further breaks down the 0xC000000 - 0xFFFFFFFF into 2 ranges a reserved range and a "Dynamically Assigned Link-Local Address" of 0xF0000000 - 
0xFFFFFFFF, which includes the SNA range, but allows for other future purposes as well. (There is a typo in the draft for end of this range. It reads 0xF0FFFFFF instead of 0xFFFFFFFF.)

Thanks,
Ron

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Sep 2005 12:12:22 +0300 (EEST)

On Tue, 20 Sep 2005, Pashby, Ronald W CTR NSWCDD-B35 wrote:
> The solution is simple: define the range for dynamically assigned 
> addresses not to overlap with the ranges that all hosts are required 
> to join.

This does not fix the problem -- it may even make it worse.

That is, now you'd have *smaller* ID space where these high-bw 
applications would pick their "non-conflicting" group-ID's from -- 
thus a higher chance that two apps would pick the same group-ID, 
right?

But even if not, aren't there two workarounds:
  - for such high-bw feeds which must never collide, get a permanent 
group ID (these don't conflict), or
  - when allocating the dynamic addresses, just pick them from 
0x80000000-0xEEFFFFFF instead of 0x80000000-0xFFFFFFFF; there is 
nothing which mandates that you to pick them from the whole pool (even 
those parts of the pool which are known to result in solicited-node 
address or other conflicts).

As there is no "DAD" for the use of a multicast address [or multicast 
group-id], I think you will just have to live with the fact that in 
some cases, there may be a collision even if the probability is 
minimalistic..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/