Cisco Cisco Aironet 350 Mini-PCI Wireless LAN Client Adapter Guia Do Desenho

Página de 368
6-3
Enterprise Mobility 4.1 Design Guide
OL-14435-01
Chapter 6      Cisco Unified Wireless Multicast Design
  Overview of Multicast Forwarding in Cisco Unified Wireless Networks
  •
The multicast-enabled network delivers the LWAPP multicast packet to each of the access points 
that have joined the LWAPP multicast group, using the normal multicast mechanisms in the routers 
to replicate the packet along the way as needed so that the multicast packet reaches all APs 
(
). This relieves the controller from replicating the multicast packets.
  •
Access points may receive other multicast packets but will only process the multicast packets that 
are sourced from the controller they are currently joined to; any other copies are discarded. If more 
than one WLAN is associated to the VLAN interface where the original multicast packet was 
sourced, the AP transmits the multicast packet over each WLAN (following the WLAN bitmap in 
the LWAPP header). Additionally, if that WLAN is on both radios (802.11g and 802.11a), both 
radios transmit the multicast packet on the WLAN if there are clients associated, even if those clients 
did not request the multicast traffic.
When the source of the multicast group is a wireless client:
  •
The multicast packet is unicast (LWAPP encapsulated) from the AP to the controller similar to 
standard wireless client traffic.
  •
The controller makes two copies of the multicast packet. One copy is sent out the VLAN associated 
with the WLAN it came on, enabling receivers on the wired LAN to receive the multicast stream and 
the router to learn about the new multicast group. The second copy of the packet is 
LWAPP-encapsulated and is sent to the LWAPP multicast group so that wireless clients may receive 
the multicast stream.
Wireless Multicast Roaming
A major challenge for a multicast client in a wireless environment is maintaining its multicast group 
membership when moving about the WLAN. Drops in the wireless connection moving from AP-to-AP 
can cause a disruption in a client’s multicast application. Internet Group Management Protocol (IGMP) 
plays an important role in the maintenance of dynamic group membership information. 
A basic comprehension of IGMP is important for understanding what happens to a client’s multicast 
session when it roams about the network. In a Layer 2 roaming case, sessions are maintained simply 
because the foreign AP, if configured properly, already belongs to the multicast group and traffic is not 
tunneled to a different anchor point on the network. Layer 3 roaming environments are a little more 
complex in this manner and depending on what tunneling mode you have configured on your controllers, 
the IGMP messages sent from a wireless client will be affected. The default mobility tunneling mode on 
a controller is asymmetrical. As discussed in the 
 this means that return traffic to the client is sent to the anchor WLC then forwarded to the 
foreign WLC where the associated client connection resides. Outbound packets are forwarded out the 
foreign WLC interface. In symmetrical mobility tunneling mode, both inbound and outbound traffic are 
tunneled to the anchor controller. For more information on mobility tunneling, see 
Asymmetric Multicast Tunneling
In asymmetric multicast tunneling, when a client roams to a new AP associated to a different WLC and 
on a different subnet, it is queried for its multicast group memberships by the foreign WLC and send out 
an IGMP group membership report. This is forwarded out the foreign WLC dynamic interface assigned 
to the VLAN and the client rejoins the multicast stream through the foreign subnet. 
 illustrates 
the traffic flow for normal data and multicast data.