[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    [ntp:bugs] [Bug 2057] Add "multicast" as synonym for "broadcast" in
From:       bugzilla-daemon () ntp ! org
Date:       2011-11-14 21:44:52
Message-ID: bug-2057-35-n5wb0DSdfx () http ! bugs ! ntp ! org/
[Download RAW message or body]

http://bugs.ntp.org/show_bug.cgi?id=2057

--- Comment #4 from David L. Mills <mills@udel.edu> 2011-11-14 21:44:52 UTC ---
Danny,

There may be a disconnect here from the original semantics developed in 
Steve Deering's dissertation and adopted by the Internet Architecture 
Task Force, (INARC). I was the chairperson for that group during the 
1980s. As specified by the documents on gateway requirements, first by 
me, then another by Bob Braden, broadcasts are directed only to the 
local subnet and do not transit gateways. On the other hand, multicasts 
are directed to a subscribed group that may have presence on any network 
or subnet and do transit gateways. Sending or receiving to a broadcast 
address does not require subscription, but sending to   on a multicast 
group address requires subscription, which expires after timeout when 
the spanning tree is pruned. Broadcast requires no specific routing 
algorithm, but multicast requires a routing algorithm, either DVMRP or 
PIM or equivalent, which constructs spanning trees rooted on each sender 
with leaves on each receiver.

 From this description, broadcast IPv4 servers are assigned class A, B, 
and C broadcast addresses, while multicast servers are assigned class D 
addresses. Clearly, the notion of broadcast and multicast apply to IPv6, 
where broadcast applies to a defined subset of the IPv6 address space, 
such as site local, an multicast has no such boundaries. Again, it is 
possible to disambiguate these cases by inspecting the address prefix.

The mapping from IP semantics to on-wire semantics is network technology 
specific. For instance, the traditional mapping of IP broadcast to 
Ethernet address is to the all-ones address, but there is no magic in 
that. For instance, in order to support two or more distinct IP subnets 
or address families on the same wire, the all-ones address can be 
changed to some other Ethernet logical address, where the 24-bit 
manufacturer prefix is preserved, but the 24-bit interface postfix is 
other than all-ones. This is how I separated the 128.175 and 128.4 
networks on the same wire when I arrive a UDel in 1986. The mapping from 
IP4/6 IP address to ethernet address, as well as the local DVMRP gateway 
is handled by the IGMP protocol, which for IPv4 multicast kernels is a 
kernel component.

With the above in mind, it is clearly possible to configure a number of 
local hosts on the same wire to subscribe to a group address where the 
scope does not include past the gateways. In theory, IGMP is not 
required. It is also possible to configure a multicast group where the 
span of the routing algorithm extends past the gateways, but this 
requires something like DVMRP and IGMP.

For IPv4, the distinction between broadcast and multicast depends only 
on the class of address, while for IPv6 the distinction may not be 
obvious. This would suggest the IPv4 configuration commands 
broadcast/client might be different than fro multicast/client, but 
accomplish the same things. On the other hand, the semantics of 
broadcast and multicast/client for IPv6 might be different in subtle 
ways. The important thing is to salute the original model: broadcast 
referes to a defined subset of IP addresses, such as a subnet, while 
multicast refers to a set of individually subscribed IP addresses that 
may be scattered over the IP address space.

I really don't like this kind of discussion on the bugs list; it should 
be discussed on the hackers list.

Dave

bugzilla-daemon@ntp.org wrote:

[---=| Quote block shrunk by t-prot: 13 lines snipped |=---]
>>so now you add complexity to the code to figure out whether you want broadcast
>>or multicast packets. Is it worth the effort involved?
>>
>>Danny
>>    
>>
>
>Sorry, I managed to refer to the wrong side. Yes, referring to broadcast server
>for a multicast server is a bit strange. It's the idea of merging
>broacastclient with multicastclient that I will have a hard time with since
>they are different animals.
>
>  
>

-- 
Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bugs mailing list
bugs@lists.ntp.org
http://lists.ntp.org/listinfo/bugs
[prev in list] [next in list] [prev in thread] [next in thread]