When I did multicast testing on my wireless network last couple of days I noticed few things may worth to note here.

First thing is the group addresses used by different services which we may not aware of.  During my “VideoStream” testing I have used 239.255.255.200 group address for my video stream. But when I monitor multicast on my controller I have noticed lot of other multicast group addresses listed there(see below).

When I search these group addresses on web, I found that certain private multicast (239.x.x.x) group addresses used for specific applications. (Ref:http://www.multicast.org.uk/address-tools/scope-relative.html). Since I have used SAP for my multicast stream session announcement, these group addresses shown in my wireless network. Usually these are top end of addresses in a given class B & better to avoid it using for your application group addresses.

Local Scope Relative
239.255.255.255 – SAP (Session Announcement Protocol)
239.255.255.254 – MADCAP Protocol
239.255.255.253 – SLPv2 Discovery
239.255.255.252 – MZAP
239.255.255.251 – Multicast Discovery of DNS Services
239.255.255.250 – SSDP
239.255.255.249 – DHCPv4
239.255.255.248 – AAP
239.255.255.247 – MBUS

Organization Scope Relative
239.195.255.255 – SAP (Session Announcement Protocol)
239.195.255.254 – MADCAP Protocol
239.195.255.253 – SLPv2 Discovery
239.195.255.252 – MZAP
239.195.255.251 – Multicast Discovery of DNS Services
239.195.255.250 – SSDP
239.195.255.249 – DHCPv4
239.195.255.248 – AAP
239.195.255.247 – MBUS

Multicast Address range 224.0.0.0/24 is allocated for “Local Network Control” 224.0.1.0/24 ” is for “Internetwork Control” by IANA. (Ref http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-1) These local network multicast packet go with TTL=1 & therefore cannot go beyond local subnet. I think Apple is using certain of these group address discover certain services within local subnet. In my environment I had iPad3 with AppleTV. They use mDNS (224.0.0.251) group address for that. 224.2.127.254 is using for SAPv1 announcement.

The second thing need to note is how multicast destination MAC address derived from a multicast IP address.IP multicast addresses have been assigned to  Class “D” address space by the Internet Assigned Number Authority (IANA). Addresses in this space are denoted with a binary “1110” prefix in the first four bits of the first octet, as shown in below figure. This results in IP multicast addresses spanning a range from 224.0.0.0 through 239.255.255.255.

The IEEE 802.2 specification makes provisions for the transmission of broadcast and multicast packets. As shown in below figure, Bit 0 of Octet 0 in an IEEE MAC address indicates whether the destination address is a broadcast/multicast address or a unicast address. If this bit is set, the MAC frame is destined either for an arbitrary group of hosts or all hosts on the network (if the MAC destination address is the broadcast address 0xFFFF.FFFF.FFFF). IP multicasting at Layer 2 uses this capability to transmit IP multicast packets to a group of hosts on a LAN segment.

All IP multicast frames all MAC layer addresses beginning with the 24-bit prefix of 0x0100.5Exx.xxxx. With only half of these MAC addresses available for use by IP Multicast, 23 bits of MAC address space is available for mapping Layer 3 IP multicast addresses into Layer 2 MAC addresses. All Layer 3 IP multicast addresses have the first four of the 32 bits set to 0x1110, leaving 28 bits of meaningful IP multicast address information. These 28 bits must map into only 23 bits of the available MAC address. This mapping is shown graphically in below figure.

Because all 28 bits of the Layer 3 IP multicast address information cannot be mapped into the available 23 bits of MAC address space, five bits of address information are lost in the mapping process. This results in a 32:1 address ambiguity when a Layer 3 IP multicast address is mapped to a Layer 2 IEEE MAC address. This means that each IEEE IP multicast MAC address can represent 32 IP multicast addresses as shown in below figure.

This 32:1 address ambiguity has the potential to cause problems. For example, a host that wishes to receive multicast group 224.1.1.1 will program the hardware registers in the network interface card to interrupt the CPU when a frame with a destination multicast MAC address of 0x0100.5E00.0101 is received. Unfortunately, this same multicast MAC address is also used for 31 other IP multicast groups. If any of these 31 other groups are also active on the local LAN, the host CPU will receive interrupts when a frame is received for any of these other groups. The CPU must examine the IP portion of each of these received frames to determine if it is the desired group; for instance, 224.1.1.1. This can affect the host’s available CPU power if the amount of “spurious” group traffic is high enough.(Ref:http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml)

Due to this reason if you want to use private multicast for your application avoid using 239.y.x.x & 239.(y+128).x.x  together for your applications as these will map into same Multicast MAC address. Specially 239.0.0.X & 239.128.0.x range as it overlap with link local addresses & flood out to all switch ports even with IGMP snooping turned on.

In my wireless packet capture  shown below (taken for a previous post) shows 239.255.255.200 mapping to layer 2 MAC 01:00:5e:7f:ff:c8. To understand how this came, you  can convert last 23 bits of this layer 3 addresss (11101111-11111111-11111111-11001000) into hex  (7f:ff:c8). Therefore multicast MAC address should be 01:00:5e:7f:ff:c8. You can verify if from the capture itself.

Sometimes it is important to understand these sorts of things when you allocate multicast group addresses for your applications to prevent unexpected behavior.

Related Posts

1. Test Yourself- Basic Multicast
2. Configuring Multicast on WLC
3. Wireless Multicast is not working – Why ?
4. Understanding “VideoStream” feature
5. IGMP Basics