--- 1/draft-ietf-mboned-ieee802-mcast-problems-10.txt 2019-12-11 17:13:10.912518700 -0800 +++ 2/draft-ietf-mboned-ieee802-mcast-problems-11.txt 2019-12-11 17:13:10.968520126 -0800 @@ -1,54 +1,56 @@ Internet Area C. Perkins -Internet-Draft +Internet-Draft Blue Meadow Networks Intended status: Informational M. McBride -Expires: May 7, 2020 Futurewei +Expires: June 13, 2020 Futurewei D. Stanley HPE W. Kumari Google JC. Zuniga SIGFOX - November 4, 2019 + December 11, 2019 Multicast Considerations over IEEE 802 Wireless Media - draft-ietf-mboned-ieee802-mcast-problems-10 + draft-ietf-mboned-ieee802-mcast-problems-11 Abstract Well-known issues with multicast have prevented the deployment of - multicast in 802.11 and other local-area wireless environments. This - document offers guidance on known limitations and problems with + multicast in 802.11 (wifi) and other local-area wireless + environments. + + This document describes the problems of known limitations with wireless (primarily 802.11) Layer-2 multicast. Also described are 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 the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -335,34 +337,35 @@ o On-demand routing o Backbone construction o Other L3 protocols (non-IP) User Datagram Protocol (UDP) is the most common transport layer protocol for multicast applications. By itself, UDP is not reliable -- messages may be lost or delivered out of order. 3.2.1. IPv4 issues - The following list contains some representative discovery protocols - that are used with IPv4. + The following list contains some representative discovery protocols, + which utlize broadcast/multicast, that are used with IPv4. o ARP o DHCP o mDNS [RFC6762] o uPnP [RFC6970] - After initial configuration, ARP and DHCP occur much less commonly, - but service discovery can occur at any time. Some widely-deployed - service discovery protocols (e.g., for finding a printer) utilize - mDNS (i.e., multicast). It's often the first service that operators - drop. Even if multicast snooping is utilized, many devices can - register at once and cause serious network degradation. + After initial configuration, ARP (described in more detail later) and + DHCP occur much less commonly, but service discovery can occur at any + time. Some widely-deployed service discovery protocols (e.g., for + finding a printer) utilize mDNS (i.e., multicast). It's often the + first service that operators drop. Even if multicast snooping is + utilized, many devices can register at once and cause serious network + degradation. 3.2.2. IPv6 issues IPv6 makes extensive use of multicast, including the following: o DHCPv6 o Protocol Independent Multicast (PIM) o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] o multicast DNS (mDNS) o Route Discovery @@ -392,28 +395,28 @@ addresses that do not have forwarding state installed (perhaps due to hardware memory limitations on the switch) cause frames to be flooded 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. 3.2.4. Spurious Neighbor Discovery On the Internet there is a "background radiation" of scanning traffic (people scanning for vulnerable machines) and backscatter (responses from spoofed traffic, etc). This means that routers very often - receive packets destined for IP addresses regardless of whether those - IP addresses are in use. In the cases where the IP is assigned to a - host, the router broadcasts an ARP request, gets back an ARP reply, - and caches it; then traffic can be delivered to the host. When the - IP address is not in use, the router broadcasts one (or more) ARP - requests, and never gets a reply. This means that it does not - populate the ARP cache, and the next time there is traffic for that - IP address the router will rebroadcast the ARP requests. + receive packets destined for IPv4 addresses regardless of whether + those IP addresses are in use. In the cases where the IP is assigned + to a host, the router broadcasts an ARP request, gets back an ARP + reply, and caches it; then traffic can be delivered to the host. + When the IP address is not in use, the router broadcasts one (or + more) ARP requests, and never gets a reply. This means that it does + not populate the ARP cache, and the next time there is traffic for + that IP address the router will rebroadcast the ARP requests. The rate of these ARP requests is proportional to the size of the subnets, the rate of scanning and backscatter, and how long the router keeps state on non-responding ARPs. As it turns out, this rate is inversely proportional to how occupied the subnet is (valid ARPs end up in a cache, stopping the broadcasting; unused IPs never respond, and so cause more broadcasts). Depending on the address space in use, the time of day, how occupied the subnet is, and other unknown factors, thousands of broadcasts per second have been observed. Around 2,000 broadcasts per second have been observed at @@ -631,25 +634,26 @@ least one widely available implementation exists in the Linux bridging code [bridge-mc-2-uc]. Other proprietary implementations are available from various vendors. In general, these implementations perform a straightforward mapping for groups or channels, discovered by IGMP or MLD snooping, to the corresponding unicast MAC addresses. 4.6.3. Directed Multicast Service (DMS) There are situations where more is needed than simply converting - multicast to unicast. For these purposes, DMS enables an STA to - request that the AP transmit multicast group addressed frames - destined to the requesting STAs as individually addressed frames - [i.e., convert multicast to unicast]. Here are some characteristics - of DMS: + multicast to unicast. + + For these purposes, DMS enables an STA to request that the AP + transmit multicast group addressed frames destined to the requesting + STAs as individually addressed frames [i.e., convert multicast to + unicast]. Here are some characteristics of DMS: o Requires 802.11n A-MSDUs o Individually addressed frames are acknowledged and are buffered for power save STAs o The requesting STA may specify traffic characteristics for DMS traffic o DMS was defined in IEEE Std 802.11v-2011 o DMS requires changes to both AP and STA implementation. DMS is not currently implemented in products. See [Tramarin2017] and @@ -1155,25 +1159,26 @@ o Used terminology "Wi-Fi" throughout. o Many editorial improvements and grammatical corrections. o Modified text to be more generic instead of referring specifically to IETF conference situations. o Cited [RFC5757] for introduction to other wireless media. o Updated bibliographic citations. Authors' Addresses Charles E. Perkins + Blue Meadow Networks Phone: +1-408-330-4586 Email: charliep@computer.org Mike McBride - Futurewei Inc. + Futurewei Technologies Inc. 2330 Central Expressway Santa Clara, CA 95055 USA Email: michael.mcbride@futurewei.com Dorothy Stanley Hewlett Packard Enterprise 2000 North Naperville Rd. Naperville, IL 60566