draft-ietf-mboned-ieee802-mcast-problems-07.txt   draft-ietf-mboned-ieee802-mcast-problems-08.txt 
Internet Area C. Perkins Internet Area C. Perkins
Internet-Draft M. McBride Internet-Draft
Intended status: Informational Futurewei Intended status: Informational M. McBride
Expires: January 27, 2020 D. Stanley Expires: February 14, 2020 Futurewei
D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
July 26, 2019 August 13, 2019
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-07 draft-ietf-mboned-ieee802-mcast-problems-08
Abstract Abstract
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 and other local-area wireless environments. This multicast in 802.11 and other local-area wireless environments. This
document offers guidance on known limitations and problems with document offers guidance on known limitations and problems with
wireless multicast. Also described are certain multicast enhancement wireless multicast. Also described are certain multicast enhancement
features that have been specified by the IETF and by IEEE 802 for features that have been specified by the IETF and by IEEE 802 for
wireless media, as well as some operational choices that can be taken wireless media, as well as some operational choices that can be taken
to improve the performace of the network. Finally, some to improve the performace of the network. Finally, some
skipping to change at page 1, line 44 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2020. This Internet-Draft will expire on February 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7 3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7
3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7 3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7
3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9 3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9
4. Multicast protocol optimizations . . . . . . . . . . . . . . 10 4. Multicast protocol optimizations . . . . . . . . . . . . . . 10
4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10 4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10
4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10 4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10
4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12 4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12
4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 4.4. Limiting multicast buffer hardware queue depth . . . . . 12
4.5. Using Unicast Instead of Multicast . . . . . . . . . . . 13 4.5. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12
4.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Using Unicast Instead of Multicast . . . . . . . . . . . 13
4.5.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13 4.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 14 4.6.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13
4.5.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14 4.6.3. Directed Multicast Service (DMS) . . . . . . . . . . 14
4.6. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 14 4.6.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14
4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15
5. Operational optimizations . . . . . . . . . . . . . . . . . . 15 5. Operational optimizations . . . . . . . . . . . . . . . . . . 15
5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16
5.2. Mitigating Spurious Service Discovery Messages . . . . . 17 5.2. Mitigating Spurious Service Discovery Messages . . . . . 17
6. Multicast Considerations for Other Wireless Media . . . . . . 17 6. Multicast Considerations for Other Wireless Media . . . . . . 18
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18
8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes in this draft between revisions 06 versus 07 23 Appendix A. Changes in this draft between revisions 06 versus 07 23
Appendix B. Changes in this draft between revisions 05 versus 06 23 Appendix B. Changes in this draft between revisions 05 versus 06 23
Appendix C. Changes in this draft between revisions 04 versus 05 23 Appendix C. Changes in this draft between revisions 04 versus 05 24
Appendix D. Changes in this draft between revisions 03 versus 04 24 Appendix D. Changes in this draft between revisions 03 versus 04 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 [dot11] and other local-area wireless multicast in 802.11 [dot11] and other local-area wireless
environments, as described in [mc-props], [mc-prob-stmt]. environments, as described in [mc-props], [mc-prob-stmt].
Performance issues have been observed when multicast packet Performance issues have been observed when multicast packet
transmissions of IETF protocols are used over IEEE 802 wireless transmissions of IETF protocols are used over IEEE 802 wireless
skipping to change at page 12, line 34 skipping to change at page 12, line 34
after the next DTIM beacon. after the next DTIM beacon.
In practice, most AP's will send a multicast every 30 packets. For In practice, most AP's will send a multicast every 30 packets. For
unicast the AP could send a TIM (Traffic Indication Message), but for unicast the AP could send a TIM (Traffic Indication Message), but for
multicast the AP sends a broadcast to everyone. DTIM does power multicast the AP sends a broadcast to everyone. DTIM does power
management but STAs can choose whether or not to wake up or not and management but STAs can choose whether or not to wake up or not and
whether or not to drop the packet. Unfortunately, without proper whether or not to drop the packet. Unfortunately, without proper
administrative control, such STAs may be unable to determine why administrative control, such STAs may be unable to determine why
their multicast operations do not work. their multicast operations do not work.
4.4. IPv6 support in 802.11-2012 4.4. Limiting multicast buffer hardware queue depth
The CAB (Content after Beacon) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast
frames were buffered, and this queue fills up, it drowns out all
regular traffic. To limit the damage that buffered traffic can do,
some drivers limit the amount of queued multicast data to a fraction
of the beacon_interval. An example of this is [CAB].
4.5. IPv6 support in 802.11-2012
IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP. Every IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP. Every
IPv6 node subscribes to a special multicast address for this purpose. IPv6 node subscribes to a special multicast address for this purpose.
Here is the specification language from clause 10.23.13 of Here is the specification language from clause 10.23.13 of
[dot11-proxyarp]: [dot11-proxyarp]:
"When an IPv6 address is being resolved, the Proxy Neighbor "When an IPv6 address is being resolved, the Proxy Neighbor
Discovery service shall respond with a Neighbor Advertisement Discovery service shall respond with a Neighbor Advertisement
message [...] on behalf of an associated STA to an [ICMPv6] message [...] on behalf of an associated STA to an [ICMPv6]
skipping to change at page 13, line 11 skipping to change at page 13, line 22
NDP may be used to request additional information NDP may be used to request additional information
o Maximum Transmission Unit o Maximum Transmission Unit
o Router Solicitation o Router Solicitation
o Router Advertisement, etc. o Router Advertisement, etc.
NDP messages are sent as group addressed (broadcast) frames in NDP messages are sent as group addressed (broadcast) frames in
802.11. Using the proxy operation helps to keep NDP messages off the 802.11. Using the proxy operation helps to keep NDP messages off the
wireless medium. wireless medium.
4.5. Using Unicast Instead of Multicast 4.6. Using Unicast Instead of Multicast
It is often possible to transmit multicast control and data messages It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually. by using unicast transmissions to each station individually.
4.5.1. Overview 4.6.1. Overview
In many situations, it's a good choice to use unicast instead of In many situations, it's a good choice to use unicast instead of
multicast over the Wi-Fi link. This avoids most of the problems multicast over the Wi-Fi link. This avoids most of the problems
specific to multicast over Wi-Fi, since the individual frames are specific to multicast over Wi-Fi, since the individual frames are
then acknowledged and buffered for power save clients, in the way then acknowledged and buffered for power save clients, in the way
that unicast traffic normally operates. that unicast traffic normally operates.
This approach comes with the tradeoff of sometimes sending the same This approach comes with the tradeoff of sometimes sending the same
packet multiple times over the Wi-Fi link. However, in many cases, packet multiple times over the Wi-Fi link. However, in many cases,
such as video into a residential home network, this can be a good such as video into a residential home network, this can be a good
tradeoff, since the Wi-Fi link may have enough capacity for the tradeoff, since the Wi-Fi link may have enough capacity for the
unicast traffic to be transmitted to each subscribed STA, even though unicast traffic to be transmitted to each subscribed STA, even though
multicast addressing may have been necessary for the upstream access multicast addressing may have been necessary for the upstream access
network. network.
Several technologies exist that can be used to arrange unicast Several technologies exist that can be used to arrange unicast
transport over the Wi-Fi link, outlined in the subsections below. transport over the Wi-Fi link, outlined in the subsections below.
4.5.2. Layer 2 Conversion to Unicast 4.6.2. Layer 2 Conversion to Unicast
It is often possible to transmit multicast control and data messages It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually. by using unicast transmissions to each station individually.
Although there is not yet a standardized method of conversion, at Although there is not yet a standardized method of conversion, at
least one widely available implementation exists in the Linux least one widely available implementation exists in the Linux
bridging code [bridge-mc-2-uc]. Other proprietary implementations bridging code [bridge-mc-2-uc]. Other proprietary implementations
are available from various vendors. In general, these are available from various vendors. In general, these
implementations perform a straightforward mapping for groups or implementations perform a straightforward mapping for groups or
channels, discovered by IGMP or MLD snooping, to the corresponding channels, discovered by IGMP or MLD snooping, to the corresponding
unicast MAC addresses. unicast MAC addresses.
4.5.3. Directed Multicast Service (DMS) 4.6.3. Directed Multicast Service (DMS)
There are situations where more is needed than simply converting There are situations where more is needed than simply converting
multicast to unicast. For these purposes, DMS enables an STA to multicast to unicast. For these purposes, DMS enables an STA to
request that the AP transmit multicast group addressed frames request that the AP transmit multicast group addressed frames
destined to the requesting STAs as individually addressed frames destined to the requesting STAs as individually addressed frames
[i.e., convert multicast to unicast]. Here are some characteristics [i.e., convert multicast to unicast]. Here are some characteristics
of DMS: of DMS:
o Requires 802.11n A-MSDUs o Requires 802.11n A-MSDUs
o Individually addressed frames are acknowledged and are buffered o Individually addressed frames are acknowledged and are buffered
for power save STAs for power save STAs
o The requesting STA may specify traffic characteristics for DMS o The requesting STA may specify traffic characteristics for DMS
traffic traffic
o DMS was defined in IEEE Std 802.11v-2011 o DMS was defined in IEEE Std 802.11v-2011
o DMS requires changes to both AP and STA implementation. o DMS requires changes to both AP and STA implementation.
DMS is not currently implemented in products. See [Tramarin2017] and DMS is not currently implemented in products. See [Tramarin2017] and
[Oliva2013] for more information. [Oliva2013] for more information.
4.5.4. Automatic Multicast Tunneling (AMT) 4.6.4. Automatic Multicast Tunneling (AMT)
AMT[RFC7450] provides a method to tunnel multicast IP packets inside AMT[RFC7450] provides a method to tunnel multicast IP packets inside
unicast IP packets over network links that only support unicast. unicast IP packets over network links that only support unicast.
When an operating system or application running on an STA has an AMT When an operating system or application running on an STA has an AMT
gateway capability integrated, it's possible to use unicast to gateway capability integrated, it's possible to use unicast to
traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi
portion of the network connected to the AP. portion of the network connected to the AP.
It is RECOMMENDED that multicast-enabled networks deploying AMT It is RECOMMENDED that multicast-enabled networks deploying AMT
relays for this purpose make the relays locally discoverable with the relays for this purpose make the relays locally discoverable with the
following methods, as described in following methods, as described in
[I-D.ietf-mboned-driad-amt-discovery]: [I-D.ietf-mboned-driad-amt-discovery]:
o DNS-SD [RFC6763] o DNS-SD [RFC6763]
o the well-known IP addresses from Section 7 of [RFC7450] o the well-known IP addresses from Section 7 of [RFC7450]
An AMT gateway that implements multiple standard discovery methods is An AMT gateway that implements multiple standard discovery methods is
more likely to discover the local multicast-capable network, instead more likely to discover the local multicast-capable network, instead
of forming a connection to an AMT relay further upstream. of forming a connection to an AMT relay further upstream.
4.6. GroupCast with Retries (GCR) 4.7. GroupCast with Retries (GCR)
GCR (defined in [dot11aa]) provides greater reliability by using GCR (defined in [dot11aa]) provides greater reliability by using
either unsolicited retries or a block acknowledgement mechanism. GCR either unsolicited retries or a block acknowledgement mechanism. GCR
increases probability of broadcast frame reception success, but still increases probability of broadcast frame reception success, but still
does not guarantee success. does not guarantee success.
For the block acknowledgement mechanism, the AP transmits each group For the block acknowledgement mechanism, the AP transmits each group
addressed frame as conventional group addressed transmission. addressed frame as conventional group addressed transmission.
Retransmissions are group addressed, but hidden from non-11aa STAs. Retransmissions are group addressed, but hidden from non-11aa STAs.
A directed block acknowledgement scheme is used to harvest reception A directed block acknowledgement scheme is used to harvest reception
skipping to change at page 19, line 39 skipping to change at page 19, line 51
10. IANA Considerations 10. IANA Considerations
This document does not request any IANA actions. This document does not request any IANA actions.
11. Acknowledgements 11. Acknowledgements
This document has benefitted from discussions with the following This document has benefitted from discussions with the following
people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,
Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel
Jaeggli, Jan Komissar, David Lamparter, Pascal Thubert, Jeffrey Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal
(Zhaohui) Zhang Thubert, Jeffrey (Zhaohui) Zhang
12. Informative References 12. Informative References
[arpsponge] [arpsponge]
Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address
resolution on AMS-IX and the ARP Sponge", July 2009, resolution on AMS-IX and the ARP Sponge", July 2009,
<http://citeseerx.ist.psu.edu/viewdoc/ <http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.182.4692>. summary?doi=10.1.1.182.4692>.
[bridge-mc-2-uc] [bridge-mc-2-uc]
Fietkau, F., "bridge: multicast to unicast", Jan 2017, Fietkau, F., "bridge: multicast to unicast", Jan 2017,
<https://github.com/torvalds/linux/ <https://github.com/torvalds/linux/
commit/6db6f0eae6052b70885562e1733896647ec1d807>. commit/6db6f0eae6052b70885562e1733896647ec1d807>.
[CAB] Fietkau, F., "Limit multicast buffer hardware queue
depth", 2013,
<https://patchwork.kernel.org/patch/2687951/>.
[Deri-2010] [Deri-2010]
Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet
Filtering Using Commodity Network Adapters", RIPE 61, Filtering Using Commodity Network Adapters", RIPE 61,
2010, <http://ripe61.ripe.net/ 2010, <http://ripe61.ripe.net/
presentations/138-Deri_RIPE_61.pdf>. presentations/138-Deri_RIPE_61.pdf>.
[dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for [dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for
Information technology--Telecommunications and information Information technology--Telecommunications and information
exchange between systems Local and metropolitan area exchange between systems Local and metropolitan area
networks--Specific requirements - Part 11: Wireless LAN networks--Specific requirements - Part 11: Wireless LAN
skipping to change at page 24, line 33 skipping to change at page 24, line 43
o Used terminology "Wi-Fi" throughout. o Used terminology "Wi-Fi" throughout.
o Many editorial improvements and grammatical corrections. o Many editorial improvements and grammatical corrections.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to IETF conference situations. to IETF conference situations.
o Cited [RFC5757] for introduction to other wireless media. o Cited [RFC5757] for introduction to other wireless media.
o Updated bibliographic citations. o Updated bibliographic citations.
Authors' Addresses Authors' Addresses
Charles E. Perkins Charles E. Perkins
Futurewei Inc.
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-4586 Phone: +1-408-330-4586
Email: charliep@computer.org Email: charliep@computer.org
Mike McBride Mike McBride
Futurewei Inc. Futurewei Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95055 Santa Clara, CA 95055
USA USA
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Dorothy Stanley Dorothy Stanley
Hewlett Packard Enterprise Hewlett Packard Enterprise
2000 North Naperville Rd. 2000 North Naperville Rd.
Naperville, IL 60566 Naperville, IL 60566
USA USA
Phone: +1 630 979 1572 Phone: +1 630 979 1572
Email: dstanley@arubanetworks.com Email: dstanley@arubanetworks.com
Warren Kumari Warren Kumari
 End of changes. 22 change blocks. 
32 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/