draft-ietf-mboned-ieee802-mcast-problems-10.txt   draft-ietf-mboned-ieee802-mcast-problems-11.txt 
Internet Area C. Perkins Internet Area C. Perkins
Internet-Draft Internet-Draft Blue Meadow Networks
Intended status: Informational M. McBride Intended status: Informational M. McBride
Expires: May 7, 2020 Futurewei Expires: June 13, 2020 Futurewei
D. Stanley D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
November 4, 2019 December 11, 2019
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-10 draft-ietf-mboned-ieee802-mcast-problems-11
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 (wifi) and other local-area wireless
document offers guidance on known limitations and problems with environments.
This document describes the problems of known limitations with
wireless (primarily 802.11) Layer-2 multicast. Also described are wireless (primarily 802.11) Layer-2 multicast. Also described are
certain multicast enhancement features that have been specified by certain multicast enhancement features that have been specified by
the IETF and by IEEE 802 for wireless media, as well as some the IETF, and by IEEE 802, for wireless media, as well as some
operational choices that can be taken to improve the performance of operational choices that can be taken to improve the performance of
the network. Finally, some recommendations are provided about the the network. Finally, some recommendations are provided about the
usage and combination of these features and operational choices. usage and combination of these features and operational choices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 7, 2020. This Internet-Draft will expire on June 13, 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 8, line 14 skipping to change at page 8, line 14
o On-demand routing o On-demand routing
o Backbone construction o Backbone construction
o Other L3 protocols (non-IP) o Other L3 protocols (non-IP)
User Datagram Protocol (UDP) is the most common transport layer User Datagram Protocol (UDP) is the most common transport layer
protocol for multicast applications. By itself, UDP is not reliable protocol for multicast applications. By itself, UDP is not reliable
-- messages may be lost or delivered out of order. -- messages may be lost or delivered out of order.
3.2.1. IPv4 issues 3.2.1. IPv4 issues
The following list contains some representative discovery protocols The following list contains some representative discovery protocols,
that are used with IPv4. which utlize broadcast/multicast, that are used with IPv4.
o ARP o ARP
o DHCP o DHCP
o mDNS [RFC6762] o mDNS [RFC6762]
o uPnP [RFC6970] o uPnP [RFC6970]
After initial configuration, ARP and DHCP occur much less commonly, After initial configuration, ARP (described in more detail later) and
but service discovery can occur at any time. Some widely-deployed DHCP occur much less commonly, but service discovery can occur at any
service discovery protocols (e.g., for finding a printer) utilize time. Some widely-deployed service discovery protocols (e.g., for
mDNS (i.e., multicast). It's often the first service that operators finding a printer) utilize mDNS (i.e., multicast). It's often the
drop. Even if multicast snooping is utilized, many devices can first service that operators drop. Even if multicast snooping is
register at once and cause serious network degradation. utilized, many devices can register at once and cause serious network
degradation.
3.2.2. IPv6 issues 3.2.2. IPv6 issues
IPv6 makes extensive use of multicast, including the following: IPv6 makes extensive use of multicast, including the following:
o DHCPv6 o DHCPv6
o Protocol Independent Multicast (PIM) o Protocol Independent Multicast (PIM)
o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
o multicast DNS (mDNS) o multicast DNS (mDNS)
o Route Discovery o Route Discovery
skipping to change at page 9, line 24 skipping to change at page 9, line 24
addresses that do not have forwarding state installed (perhaps due to addresses that do not have forwarding state installed (perhaps due to
hardware memory limitations on the switch) cause frames to be flooded hardware memory limitations on the switch) cause frames to be flooded
on all ports of the switch. Some switch vendors do not support MLD, on all ports of the switch. Some switch vendors do not support MLD,
for link-scope multicast, due to the increase it can cause in state. for link-scope multicast, due to the increase it can cause in state.
3.2.4. Spurious Neighbor Discovery 3.2.4. Spurious Neighbor Discovery
On the Internet there is a "background radiation" of scanning traffic On the Internet there is a "background radiation" of scanning traffic
(people scanning for vulnerable machines) and backscatter (responses (people scanning for vulnerable machines) and backscatter (responses
from spoofed traffic, etc). This means that routers very often from spoofed traffic, etc). This means that routers very often
receive packets destined for IP addresses regardless of whether those receive packets destined for IPv4 addresses regardless of whether
IP addresses are in use. In the cases where the IP is assigned to a those IP addresses are in use. In the cases where the IP is assigned
host, the router broadcasts an ARP request, gets back an ARP reply, to a host, the router broadcasts an ARP request, gets back an ARP
and caches it; then traffic can be delivered to the host. When the reply, and caches it; then traffic can be delivered to the host.
IP address is not in use, the router broadcasts one (or more) ARP When the IP address is not in use, the router broadcasts one (or
requests, and never gets a reply. This means that it does not more) ARP requests, and never gets a reply. This means that it does
populate the ARP cache, and the next time there is traffic for that not populate the ARP cache, and the next time there is traffic for
IP address the router will rebroadcast the ARP requests. that IP address the router will rebroadcast the ARP requests.
The rate of these ARP requests is proportional to the size of the The rate of these ARP requests is proportional to the size of the
subnets, the rate of scanning and backscatter, and how long the subnets, the rate of scanning and backscatter, and how long the
router keeps state on non-responding ARPs. As it turns out, this router keeps state on non-responding ARPs. As it turns out, this
rate is inversely proportional to how occupied the subnet is (valid rate is inversely proportional to how occupied the subnet is (valid
ARPs end up in a cache, stopping the broadcasting; unused IPs never ARPs end up in a cache, stopping the broadcasting; unused IPs never
respond, and so cause more broadcasts). Depending on the address respond, and so cause more broadcasts). Depending on the address
space in use, the time of day, how occupied the subnet is, and other space in use, the time of day, how occupied the subnet is, and other
unknown factors, thousands of broadcasts per second have been unknown factors, thousands of broadcasts per second have been
observed. Around 2,000 broadcasts per second have been observed at observed. Around 2,000 broadcasts per second have been observed at
skipping to change at page 14, line 45 skipping to change at page 14, line 45
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.6.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.
request that the AP transmit multicast group addressed frames
destined to the requesting STAs as individually addressed frames For these purposes, DMS enables an STA to request that the AP
[i.e., convert multicast to unicast]. Here are some characteristics transmit multicast group addressed frames destined to the requesting
of DMS: STAs as individually addressed frames [i.e., convert multicast to
unicast]. Here are some characteristics 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
skipping to change at page 25, line 43 skipping to change at page 25, 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
Blue Meadow Networks
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 Technologies 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
 End of changes. 13 change blocks. 
30 lines changed or deleted 35 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/