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/