Subject: Re: question

From: Bryan Mclaughlin <[email-masked]>
Date: Wed, 05 Sep 2001 09:28:49 +0100

Hitesh,

"the mac addr is hard-coded on to the card " this is the address used  as a 
source or as a destination in unicast communication.

Remeber the destination in IPmulticast is not a physical device but a 
virtual group.

The destination MAc address of an IP Multicast frame is set as follows:

Organisational Unit Identifier; 00.00.5E  as you say the least significant 
bit of the most significant byte is set to 1 to indicate 
Broadcast/Multicast so the OUI becomes 01.00.5E:

To have a 1-1 mapping would have required 16 OUI's only 1 was made 
available to Steve Deering. In fact he was only given 1/2 of the above 
OUI.  So a possible 24 bits to map from IP add to MAC address became only 
23 bits.
You will notice there are now 32 possible address that map to the each MAC 
address.

01.00.5E.01.01.01

224.1.1.1
224.129.1.1
.
.
239.129.1.1

Hope this helps

At 20:44 04/09/2001 -0500, hitesh rupare; wrote:
>hi,
>
>the mac addr is hard-coded on to the card ... how then can one map the 28 
>bits of the ip addr onto 23 bits of the mac addr ?
>
>also bit 0 in octet 7 has to be set to 1 for broadcast/multicast ... how 
>is this bit set ?
>
>rgds
>hitesh
>
>
>
>>From: Beau Williamson <[email-masked]>
>>To: John Zwiebel <[email-masked]>,        Bryan Mclaughlin 
>><[email-masked]>, [email-masked],        MAGMA Mailing List 
>><[email-masked]>, [email-masked]
>>Subject: Re: draft-ietf-pim-dm-new-v2-04.txt
>>Date: Wed, 01 Aug 2001 16:37:59 -0500
>>
>>John,
>>
>>Once again I think you and I are on the same wavelength.  I'd like to see 
>>MSNIP evolve into something more like the RTS/CTS mechanism that you 
>>describe with sufficient specifications as to how the first hop device 
>>(maybe a router or maybe a layer-3 aware switch) should handle this.
>>
>>In addition, I'd like to see "receiver" admission control added if at all 
>>possible.  I'm not convinced that this would require a extension to IGMP 
>>or a new protocol and may actual fall into vendor specific features.
>>
>>In any case, the worries over DoS Attacks due to random sourcing and 
>>random joining (especially if SSM takes off) are real and are quickly 
>>becoming a barrier to multicast deployment.
>>
>>Maybe this can be discussed at the MAGMA WG in London.  Unfortunately, I 
>>won't be there so I'm hoping you or someone else will carry the 
>>flag.  (At least initially.)
>>
>>Beau
>>At 01:26 PM 7/31/2001, John Zwiebel wrote:
>> >Bryan Mclaughlin wrote:
>> >>
>> >> This issue is addressed by Multicast Source Notification of Interest
>> >> Protocol (MSNIP)  for SM protocols,  isn't it ? What would need to be 
>> added
>> >> to make it work for DM?
>> >>
>> >
>> >MSNIP does not do admission control.  It "kind of" does it, but
>> >there's nothing that prevents a source from dumping mpackets on to the
>> >LAN.
>> >And MSNIP does not specifically address what a router should do if
>> >it sees packets from a source that hasn't registered via MSNIP.
>> >(one could make the leap that in such a case the router could just
>> >bit bucket the data stream)
>> >
>> >The host (source) is still "in charge" and the network has to muddle
>> >through the best it can.  If a host is sending and there is no MSNIP
>> >available, there's nothing to stop it.
>> >
>> >The RTS/CTS process I'd like to see would make the network more
>> >"superior" to the host and is quite a bit more complicated than what
>> >MSNIP is trying to provide.
>> >
>> >I guess this sentence from the MSNIP draft makes my point:
>> >
>> >     Hosts that wish to be managed by MSNIP periodically transmit an
>> >     Interest Solicitation message. This message is multicast with a
>> >group
>> >     destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is
>> >     transmitted every [Interest Solicitation Interval] seconds.
>> >
>> >  -- MSNIP is IGMPv3 only
>> >  -- Hosts can arbitrarily decide to not be managed by MSNIP
>> >  -- MSNIP does not describe how to signal the "network" that the
>> >        source is about to send.
>> >
>> >This shouldn't be taken as a condemnation of MSNIP.  Its quite
>> >possible my imagination just isn't strong enough to grasp the
>> >capabilities.  And what I think is needed may be way too complicated
>> >and contrary to the "spirit of the internet".
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Bryan Mclaughlin
Technical Marketing Engineer	            Telephone :+44 (0)20 8756 8811
IOS Technology Division 		Email        :[email-masked]
Cisco Systems			Mobile       :+44 (0)7710 164487

---

From: "hitesh rupare;" <[email-masked]>
Date: Tue, 04 Sep 2001 20:44:19 -0500

hi,

also bit 0 in octet 7 has to be set to 1 for broadcast/multicast ... how is 
this bit set ?

rgds
hitesh

>possible.  I'm not convinced that this would require a extension to IGMP or 
>a new protocol and may actual fall into vendor specific features.
>
>In any case, the worries over DoS Attacks due to random sourcing and random 
>joining (especially if SSM takes off) are real and are quickly becoming a 
>barrier to multicast deployment.
>
>won't be there so I'm hoping you or someone else will carry the flag.  (At 
>least initially.)
>
>Beau

---

From: "Stepping, Michael" <[email-masked]>
Date: Wed, 5 Sep 2001 10:44:18 +0200

Hi Hitesh,

I am jumping in this thread and therefor I assume, you are talking about
IGMP,
which is the location where a mapping of IP-Adresses (IPv4 32 Bit) to
Mac-Adresses
(Ethernet MAC 48 Bits) happens.

First of all: Ethernet Cards have a register which proposes a
world-wide unique MAC Address, which consists of first three bytes are
manufacturer,
last three bytes are serial number. (This explains the cry of using this
number
in the Microsoft Word Documents.)
This MAC Address (48bit) can be reconfigured with standard mechanisms like
NDIS or ODI interface programming (on Windows and Novell machines).
DecNet reconfigured always this adress.

Second:
IP-Class D adresses are IP-Multicast adresses and therefore the last 28 bit
(out
of 32 bit) are significant.
Ethernet adresses have a tag for Ethernet-Multicast MAC Address (currently
not in my mind) and therefore the last 23 bits are significant.

Third: Mapping:
Take the last 23 bits of the IPv4-Multicast adress and fill these to the
Ethernet MAC Adress. That is all.

Question: But there are multiple IP-Multicast adresses mappable on
one Ethernet-MAC-Multicast Adress?

That is true, but a) that happens not that often in real and
b) the upper IP-Multicast layer can decide if this IPv4-Multicast traffic
is required.

Keep in mind: There are other topologies than Ethernet underlying IP layer.
(Token Ring, Fiber, etc.)

Michael

> also bit 0 in octet 7 has to be set to 1 for broadcast/multicast

For Ethernet there are only 6 octets. Did I mis the point?

Michael