rfc9119xml2.original.xml   rfc9119.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!-- declare nbsp and friends -->
<!ENTITY nbsp "&#xa0;">
<!ENTITY nbhy "&#x2011;">
<!ENTITY wj "&#x2060;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- ?rfc subcompact="no" ? -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
<!-- TODO!!
== We could write text for more Recommendations.
== We could more fully describe the IPv6 uses of multicast.
== We could describe more potential multicast applications that might be
enabled with better multicast solutions (if in fact better solutions exist).
<rfc category="info" docName="draft-ietf-mboned-ieee802-mcast-problems-15"
ipr="trust200902">
<front>
<title abbrev="Multicast Over IEEE 802 Wireless">Multicast Considerations
over IEEE 802 Wireless Media</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Blue Meadow Networks">Blue Meadow Networks</organiza
tion>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country></country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<author fullname="Mike McBride" initials="M." surname="McBride">
<organization abbrev="Futurewei">Futurewei Technologies Inc.</organization
>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95055</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>michael.mcbride@futurewei.com</email>
</address>
</author>
<author fullname="Dorothy Stanley" initials="D" surname="Stanley">
<organization abbrev="HPE">Hewlett Packard Enterprise</organization>
<address>
<postal>
<street>2000 North Naperville Rd.</street>
<city>Naperville</city>
<code>60566</code>
<region>IL</region>
<country>USA</country>
</postal>
<phone>+1 630 979 1572</phone>
<email>dstanley1389@gmail.com</email>
</address>
</author>
<author fullname="Warren Kumari" initials="W" surname="Kumari">
<organization abbrev="Google">Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<code>94043</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>warren@kumari.net</email>
</address>
</author>
<author fullname="Juan Carlos Zuniga" initials="JC" surname="Zuniga">
<organization abbrev="SIGFOX">SIGFOX</organization>
<address>
<postal>
<street>425 rue Jean Rostand</street>
<city>Labege</city>
<code>31670</code>
<region/>
<country>France</country>
</postal>
<email>j.c.zuniga@ieee.org</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>Internet Area</workgroup>
<keyword>Multicast</keyword>
<keyword>IEEE 802 Wireless Multicast</keyword>
<abstract>
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 (wifi) and other local-area wireless environments.
<!-- deleted re: Jake Holland, Aug. 10.
IETF multicast experts have been meeting
together to discuss these issues and provide IEEE updates. The
mboned working group is chartered to receive regular reports on the
current state of the deployment of multicast technology, create
"practice and experience" documents that capture the experience of
those who have deployed and are deploying various multicast
technologies, and provide feedback to other relevant working groups.
-->
This document describes the known limitations
of wireless (primarily 802.11) Layer-2 multicast. Also described are cer
tain multicast
enhancement 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 to improve the performance of the network. Finally,
some recommendations are provided about the usage and combination of
these features and operational choices.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 <xref target="dot11"/> and other local-area
wireless environments, as described in <xref target="mc-props"/>,
<xref target="mc-prob-stmt"/>. Performance issues have been observed
when multicast
packet transmissions of IETF protocols are used over IEEE 802 wireless
media. Even though enhancements for multicast transmissions have been
designed at both IETF and IEEE 802, incompatibilities still exist
between specifications, implementations and configuration choices.
</t>
<t> Many IETF protocols depend on multicast/broadcast for delivery of
control messages to multiple receivers. Multicast allows sending data to
multiple interested recipients without the source needing to send duplica
te
data to each recipient. With broadcast traffic, data is sent to every dev
ice
regardless of their expressed interest in the data. Multicast is used for
various
purposes such as neighbor discovery, network flooding, address
resolution, as well minimizing media occupancy for the
transmission of data that is intended for multiple receivers.
In addition to protocol use of broadcast/multicast for
control messages, more applications, such as push to talk in
hospitals, or video in enterprises, universities, and homes, are
sending multicast IP to end user devices, which are increasingly
using Wi-Fi for their connectivity. </t>
<t> IETF protocols typically rely on network protocol layering in order
to reduce or eliminate any dependence of higher level protocols on
the specific nature of the MAC layer protocols or the physical media.
In the case of multicast transmissions, higher level protocols have
traditionally been designed as if transmitting a packet to an IP
address had the same cost in interference and network media access,
regardless of whether the destination IP address is a unicast address
or a multicast or broadcast address. This model was reasonable for
networks where the physical medium was wired, like Ethernet.
Unfortunately, for many wireless media, the costs to access the
medium can be quite different. Multicast over Wi-Fi has often been
plagued by such poor performance that it is disallowed.
Some enhancements have been designed
in IETF protocols that are assumed to work primarily over wireless
media. However, these enhancements are usually implemented in limited
deployments and not widespread on most wireless networks.</t>
<t> IEEE 802 wireless protocols have been designed with certain features
to support multicast traffic. For instance, lower modulations are
used to transmit multicast frames, so that these can be received by
all stations in the cell, regardless of the distance or path
attenuation from the base station or access point. However, these
lower modulation transmissions occupy the medium longer;
they hamper efficient transmission of traffic using
higher order modulations to nearby stations.
For these and other reasons, IEEE 802 working groups such as 802.11
have designed features to improve the performance of multicast
transmissions at Layer 2 <xref target="ietf_802-11" />.
In addition to protocol design features, certain operational and
configuration enhancements can ameliorate the network
performance issues created by multicast traffic,
as described in <xref target="optim3" />.</t>
<t> There seems to be general agreement that these problems will not <!DOCTYPE rfc [
be fixed anytime soon, primarily because it's expensive to do so <!ENTITY nbsp "&#160;">
and due to multicast being unreliable. Compared to unicast over Wi-Fi, <!ENTITY zwsp "&#8203;">
multicast is often treated as somewhat of a second class citizen, even <!ENTITY nbhy "&#8209;">
though there are many protocols using multicast. Something needs to <!ENTITY wj "&#8288;">
be provided in order to make them more reliable. IPv6 ]>
neighbor discovery saturating the Wi-Fi link is only part of the <!-- updated by MS 08/02/21 -->
problem. Wi-Fi traffic classes may help. This document is intended
to help make the determination about
what problems should be solved by the IETF and what problems
should be solved by the IEEE (see <xref target="discussion" />).
<!--
A "multicast over wifi" IETF mailing list has been formed
(mcast-wifi@ietf.org) for further discussion. This draft will
be updated according to the current state of discussion.
-->
</t>
<t> This document details various problems caused by multicast transmission <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-
over wireless networks, including high packet error rates, no ietf-mboned-ieee802-mcast-problems-15" ipr="trust200902" obsoletes="" updates=""
acknowledgements, and low data rate. It also explains some submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="tru
enhancements that have been designed at the IETF and IEEE 802.11 to ameli e" sortRefs="true" version="3" consensus="true" number="9119">
orate <!-- xml2rfc v2v3 conversion 3.9.1 -->
the effects of the radio medium on multicast traffic. Recommendations ar <front>
e also provided <title abbrev="Multicast Over IEEE 802 Wireless">Multicast Considerations
to implementors about how to use and combine these enhancements. over IEEE 802 Wireless Media</title>
Some advice about the operational choices that can be taken is also <seriesInfo name="RFC" value="9119"/>
included. It is likely that this document will also be considered <author fullname="Charles E. Perkins" initials="C." surname="Perkins">
relevant to designers of future IEEE wireless specifications. </t> <organization>Lupin Lodge</organization>
</section> <!-- end section "Introduction" --> <address>
<phone>+1 408 255 9223</phone>
<email>charliep@lupinlodge.com</email>
</address>
</author>
<author fullname="Mike McBride" initials="M." surname="McBride">
<organization abbrev="Futurewei">Futurewei Technologies Inc.</organizatio
n>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95055</code>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>michael.mcbride@futurewei.com</email>
</address>
</author>
<author fullname="Dorothy Stanley" initials="D" surname="Stanley">
<organization abbrev="HPE">Hewlett Packard Enterprise</organization>
<address>
<postal>
<street>6280 America Center Dr.</street>
<city>San Jose</city>
<code>95002</code>
<region>CA</region>
<country>United States of America</country>
</postal>
<phone>+1 630 363 1389</phone>
<email>dorothy.stanley@hpe.com</email>
</address>
</author>
<author fullname="Warren Kumari" initials="W" surname="Kumari">
<organization abbrev="Google">Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<code>94043</code>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>warren@kumari.net</email>
</address>
</author>
<author fullname="Juan Carlos Zuniga" initials="JC" surname="Zuniga">
<organization abbrev="SIGFOX">SIGFOX</organization>
<address>
<postal>
<street/>
<city>Montreal</city>
<code/>
<country>Canada</country>
</postal>
<email>j.c.zuniga@ieee.org</email>
</address>
</author>
<date year="2021" month="September"/>
<area>Internet</area>
<workgroup>Internet Area</workgroup>
<keyword>Multicast</keyword>
<keyword>Broadcast</keyword>
<keyword>BUM</keyword>
<keyword>wifi</keyword>
<keyword>wireless</keyword>
<keyword>IEEE 802 Wireless Multicast</keyword>
<abstract>
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 (Wi-Fi) and other local-area wireless environments.
This document describes the known limitations
of wireless (primarily 802.11) Layer 2 multicast. Also described are ce
rtain multicast
enhancement features that have been specified by the IETF
and by IEEE 802 for wireless media, as well as some operational choices
that can be made to improve the performance of the network. Finally,
some recommendations are provided about the usage and combination of
these features and operational choices.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
Well-known issues with multicast have prevented the deployment of
multicast in 802.11 <xref target="dot11" format="default"/> and other lo
cal-area
wireless environments, as described in <xref target="mc-props" format="d
efault"/> and <xref target="mc-prob-stmt" format="default"/>. Performance issue
s have been observed
when multicast
packet transmissions of IETF protocols are used over IEEE 802 wireless
media. Even though enhancements for multicast transmissions have been
designed at both IETF and IEEE 802, incompatibilities still exist
between specifications, implementations, and configuration choices.
</t>
<t> Many IETF protocols depend on multicast/broadcast for delivery of
control messages to multiple receivers. Multicast allows data to be sent
to
multiple interested recipients without the source needing to send duplic
ate
data to each recipient. With broadcast traffic, data is sent to every de
vice
regardless of their expressed interest in the data. Multicast is used fo
r various
purposes such as Neighbor Discovery, network flooding, and address
resolution, as well as minimizing media occupancy for the
transmission of data that is intended for multiple receivers.
In addition to protocol use of broadcast/multicast for
control messages, more applications, such as Push To Talk in
hospitals or video in enterprises, universities, and homes, are
sending multicast IP to end-user devices, which are increasingly
using Wi-Fi for their connectivity. </t>
<t> IETF protocols typically rely on network protocol layering in order
to reduce or eliminate any dependence of higher-level protocols on
the specific nature of the MAC-layer protocols or the physical media.
In the case of multicast transmissions, higher-level protocols have
traditionally been designed as if transmitting a packet to an IP
address had the same cost in interference and network media access,
regardless of whether the destination IP address is a unicast address
or a multicast or broadcast address. This model was reasonable for
networks where the physical medium was wired, like Ethernet.
Unfortunately, for many wireless media, the costs to access the
medium can be quite different. Multicast over Wi-Fi has often been
plagued by such poor performance that it is disallowed.
Some enhancements have been designed
in IETF protocols that are assumed to work primarily over wireless
media. However, these enhancements are usually implemented in limited
deployments and are not widespread on most wireless networks.</t>
<t> IEEE 802 wireless protocols have been designed with certain features
to support multicast traffic. For instance, lower modulations are
used to transmit multicast frames so that these can be received by
all stations in the cell, regardless of the distance or path
attenuation from the base station or Access Point (AP).
<section anchor="def" title="Terminology"> However, these
<!-- lower modulation transmissions occupy the medium longer;
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL they hamper efficient transmission of traffic using
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", higher-order modulations to nearby stations.
"MAY", and "OPTIONAL" in this document are to be interpreted as For these and other reasons, IEEE 802 Working Groups such as 802.11
described in <xref target="RFC2119" />.</t> have designed features to improve the performance of multicast
<t>This document also uses some terminology from <xref transmissions at Layer 2 <xref target="ietf_802-11" format="default"/>.
target="RFC5444" />.</t> In addition to protocol design features, certain operational and
--> configuration enhancements can ameliorate the network
performance issues created by multicast traffic,
as described in <xref target="optim3" format="default"/>.</t>
<t> There seems to be general agreement that these problems will not
be fixed anytime soon, primarily because it's expensive to do so
and because of the unreliability of multicast. Compared to unicast over
Wi-Fi,
multicast is often treated as somewhat of a second-class citizen even
though there are many protocols using multicast. Something needs to
be provided in order to make them more reliable. IPv6
Neighbor Discovery saturating the Wi-Fi link is only part of the
problem. Wi-Fi traffic classes may help. This document is intended
to help make the determination about
what problems should be solved by the IETF and what problems
should be solved by the IEEE (see <xref target="discussion" format="defa
ult"/>).
</t>
<t> This document details various problems caused by multicast transmissi
on
over wireless networks, including high packet error rates, no
acknowledgements, and low data rate. It also explains some
enhancements that have been designed at the IETF and IEEE 802.11 to amel
iorate
the effects of the radio medium on multicast traffic. Recommendations a
re also provided
to implementors about how to use and combine these enhancements.
Some advice about the operational choices that can be made is also
included. It is likely that this document will also be considered
relevant to designers of future IEEE wireless specifications. </t>
</section>
<section anchor="def" numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the following definitions: <t>This document uses the following definitions:
<list style="hanging"> </t>
<t hangText="ACK"><vspace/> The 802.11 layer 2 acknowledgement</t> <dl newline="true">
<t><vspace/></t> <dt>ACK</dt>
<t hangText="AP"><vspace/> IEEE 802.11 Access Point</t> <dd> The 802.11 Layer 2 acknowledgement.</dd>
<t><vspace/></t> <dt>AES-CCMP</dt><dd>AES-Counter Mode CBC-MAC Protocol</dd>
<t hangText="basic rate"><vspace/> The slowest rate of all the <dt>AP</dt>
connected devices, at which multicast and broadcast traffic is <dd> IEEE 802.11 Access Point.</dd>
generally transmitted</t> <dt>Basic rate</dt>
<t><vspace/></t> <dd> The slowest rate of all the
<t hangText="DTIM"><vspace/> Delivery Traffic Indication Map (DTIM): An connected devices at which multicast and broadcast traffic is
information element that advertises whether or not any associated generally transmitted.</dd>
stations have buffered multicast or broadcast frames</t> <dt>DVB-H</dt><dd>Digital Video Broadcasting - Handheld</dd>
<t><vspace/></t> <dt>DVB-IPDC</dt><dd>Digital Video Broadcasting - Internet Protocol Datacasting<
<t hangText="MCS"><vspace/> Modulation and Coding Scheme</t> /dd>
<t><vspace/></t> <dt>DTIM</dt>
<t hangText="NOC"><vspace/> Network Operations Center</t> <dd>Delivery Traffic Indication Map; an information element that adverti
<t><vspace/></t> ses whether or not any associated
<t hangText="PER"><vspace/> Packet Error Rate</t> stations have buffered multicast or broadcast frames.</dd>
<t><vspace/></t> <dt>MCS</dt>
<t hangText="STA"><vspace/> 802.11 station (e.g. handheld device)</t> <dd> Modulation and Coding Scheme.</dd>
<t><vspace/></t> <dt>NOC</dt>
<t hangText="TIM"><vspace/> Traffic Indication Map (TIM): An <dd> Network Operations Center.</dd>
<dt>PER</dt>
<dd> Packet Error Rate.</dd>
<dt>STA</dt>
<dd> 802.11 station (e.g., handheld device).</dd>
<dt>TIM</dt>
<dd>Traffic Indication Map; an
information element that advertises whether or not any associated information element that advertises whether or not any associated
stations have buffered unicast frames</t> stations have buffered unicast frames.</dd>
<t><vspace/></t> <dt>TKIP</dt><dd>Temporal Key Integrity Protocol</dd>
</list></t> <dt>WiMAX</dt><dd>Worldwide Interoperability for Microwave Access</dd>
<!-- <t><vspace blankLines="19" /></t> --> <dt>WPA</dt><dd>Wi-Fi Protected Access</dd>
</section> <!-- end section "Terminology" --> </dl>
<section anchor="multicast_issues" title="Identified multicast issues"> </section>
<section anchor="l2_issues" title="Issues at Layer 2 and Below">
<t> In this section some of the issues related to the use of multicast
transmissions over IEEE 802 wireless technologies are described.</t>
<section anchor="reliability" title="Multicast reliability"> <section anchor="multicast_issues" numbered="true" toc="default">
<t> Multicast traffic is typically much less reliable than unicast <name>Identified Multicast Issues</name>
<section anchor="l2_issues" numbered="true" toc="default">
<name>Issues at Layer 2 and Below</name>
<t> In this section, some of the issues related to the use of multicast
transmissions over IEEE 802 wireless technologies are described.</t>
<section anchor="reliability" numbered="true" toc="default">
<name>Multicast Reliability</name>
<t> Multicast traffic is typically much less reliable than unicast
traffic. Since multicast makes point-to-multipoint communications, traffic. Since multicast makes point-to-multipoint communications,
multiple acknowledgements would be needed to guarantee reception multiple acknowledgements would be needed to guarantee reception
at all recipients. And since there are no ACKs for multicast at all recipients. However, since there are no ACKs for multicast
packets, it is not possible for the Access Point (AP) to packets, it is not possible for the AP to
know whether or not a retransmission is needed. Even in the wired know whether or not a retransmission is needed. Even in the wired
Internet, this characteristic often causes undesirably high error Internet, this characteristic often causes undesirably high error
rates. This has contributed to the relatively slow uptake of rates. This has contributed to the relatively slow uptake of
multicast applications even though the protocols have long been multicast applications even though the protocols have long been
available. The situation for wireless links is much worse, and is available. The situation for wireless links is much worse and is
quite sensitive to the presence of background traffic. quite sensitive to the presence of background traffic.
Consequently, there can be a high packet error rate (PER) Consequently, there can be a high packet error rate (PER)
due to lack of retransmission, and because the sender never backs due to lack of retransmission and because the sender never backs
off. PER is the ratio, in percent, of the number of packets not succ essfully off. PER is the ratio, in percent, of the number of packets not succ essfully
received by the device. It is not uncommon for there to be a packet l oss rate of 5% received by the device. It is not uncommon for there to be a packet l oss rate of 5%
or more, which is particularly troublesome for video and other or more, which is particularly troublesome for video and other
environments where high data rates and high reliability are environments where high data rates and high reliability are
required. </t> required. </t>
</section> <!-- end section "Multicast reliability" --> </section>
<section anchor="lower_rate" title="Lower and Variable Data Rate">
<t> Multicast over wired differs from multicast over wireless because <section anchor="lower_rate" numbered="true" toc="default">
<name>Lower and Variable Data Rate</name>
<t> Multicast over wired differs from multicast over wireless because
transmission over wired links often occurs at transmission over wired links often occurs at
a fixed rate. Wi-Fi, on the other hand, has a transmission rate a fixed rate. Wi-Fi, on the other hand, has a transmission rate
that varies depending upon the STA's proximity to the AP. that varies depending upon the STA's proximity to the AP.
The throughput of video flows, and the capacity of the broader The throughput of video flows and the capacity of the broader
Wi-Fi network, will change with device movement. This impacts the abi Wi-Fi network will change with device movement. This impacts the abil
lity for QoS ity for QoS
solutions to effectively reserve bandwidth and provide admission solutions to effectively reserve bandwidth and provide admission
control. </t> control. </t>
<t> For wireless stations authenticated and linked with an AP, the pow
<t> For wireless stations authenticated and linked with an Access Point, er
the power
necessary for good reception can vary from station to station. For necessary for good reception can vary from station to station. For
unicast, the goal is to minimize power requirements while maximizing unicast, the goal is to minimize power requirements while maximizing
the data rate to the destination. For multicast, the goal is simply the data rate to the destination. For multicast, the goal is simply
to maximize the number of receivers that will correctly receive the to maximize the number of receivers that will correctly receive the
multicast packet; generally the Access Point has multicast packet; generally, the AP has
to use a much lower data rate at a power level high enough for even to use a much lower data rate at a power level high enough for even
the farthest station to receive the packet, for example as briefly the farthest station to receive the packet, for example, as briefly
mentioned in section 2 of <xref target="RFC5757"/>. Consequently, th
e data mentioned in <xref target="RFC5757" sectionFormat="of" section="4"/>.
Consequently, the data
rate of a video stream, for instance, would be constrained by the rate of a video stream, for instance, would be constrained by the
environmental considerations of the least reliable receiver environmental considerations of the least-reliable receiver
associated with the Access Point. </t> associated with the AP. </t>
<t> Because more robust modulation and coding schemes (MCSs) <t> Because more robust modulation and coding schemes (MCSs)
have longer range but also lower data rate, multicast / broadcast have a longer range but also a lower data rate, multicast/broadcast
traffic is generally transmitted at the slowest rate of all the traffic is generally transmitted at the slowest rate of all the
connected devices. This is also known as the basic rate. connected devices. This is also known as the basic rate.
The amount of additional interference depends on the The amount of additional interference depends on the
specific wireless technology. In fact, backward compatibility and specific wireless technology. In fact, backward compatibility and
multi-stream implementations mean that the maximum unicast rates multi-stream implementations mean that the maximum unicast rates
are currently up to a few Gbps, so there can be more than are currently up to a few Gbps, so there can be more than
3 orders of magnitude difference in the transmission rate between 3 orders of magnitude difference in the transmission rate between
multicast / broadcast versus optimal unicast forwarding. Some multicast/broadcast versus optimal unicast forwarding. Some
techniques employed to increase spectral efficiency, such as spatial techniques employed to increase spectral efficiency, such as spatial
multiplexing in MIMO systems, are not available with more than multiplexing in Multiple Input Multiple Output (MIMO) systems, are no t available with more than
one intended receiver; it is not the case that backwards one intended receiver; it is not the case that backwards
compatibility is the only factor responsible for lower multicast compatibility is the only factor responsible for lower multicast
transmission rates. </t> transmission rates. </t>
<t> Wired multicast also affects wireless LANs when the AP extends
<t> Wired multicast also affects wireless LANs when the AP extends the wired segment; in that case, multicast/broadcast frames
the wired segment; in that case, multicast / broadcast frames
on the wired LAN side are copied to the Wireless Local Area Network ( WLAN). Since broadcast on the wired LAN side are copied to the Wireless Local Area Network ( WLAN). Since broadcast
messages are transmitted at the most robust MCS, messages are transmitted at the most robust MCS,
many large frames are sent at a slow rate over the air. </t> many large frames are sent at a slow rate over the air. </t>
</section> <!-- end section "Lower Data Rate" --> </section>
<section anchor="interference" title="Capacity and Impact on Interference"> <section anchor="interference" numbered="true" toc="default">
<t> Transmissions at a lower <name>Capacity and Impact on Interference</name>
<t> Transmissions at a lower
rate require longer occupancy of the wireless medium and thus rate require longer occupancy of the wireless medium and thus
take away from the airtime of other communications and take away from the airtime of other communications and
degrade the overall capacity. Furthermore, transmission at higher degrade the overall capacity. Furthermore, transmission at higher
power, as is required to reach all multicast STAs associated power, as is required to reach all multicast STAs associated
to the AP, proportionately increases the area of interference with ot her with the AP, proportionately increases the area of interference with other
consumers of the radio spectrum. </t> consumers of the radio spectrum. </t>
</section> <!-- end section "Capacity and Impact on Interference" --> </section>
<section anchor="power_save" title="Power-save Effects on Multicast"> <section anchor="power_save" numbered="true" toc="default">
<t> One of the characteristics of multicast transmission over wifi is tha <name>Power-Save Effects on Multicast</name>
t every <t> One of the characteristics of multicast transmission over Wi-Fi is
that every
station has to be configured to wake up to receive the multicast fram e, station has to be configured to wake up to receive the multicast fram e,
even though the received packet may ultimately be discarded. This even though the received packet may ultimately be discarded. This
process can have a large effect on the power consumption by process can have a large effect on the power consumption by
the multicast receiver station. For this reason there are workarounds the multicast receiver station. For this reason, there are workaround
, s,
such as Directed Multicast Service (DMS) described in Section 4, to such as Directed Multicast Service (DMS) described in <xref target="o
ptim2"/>, to
prevent unnecessarily waking up stations.</t> prevent unnecessarily waking up stations.</t>
<t> Multicast (and unicast) can work poorly with the power-save mechan
isms defined in
IEEE 802.11e for the following reasons.
</t>
<ul>
<li> Clients may be unable to stay in sleep mode due to
multicast control packets frequently waking them up.</li>
<t> Multicast (and unicast) can work poorly with the power-save mechanism <li> A unicast packet is delayed until an STA wakes up and requests
s defined in
IEEE 802.11e, for the following reasons.
<list style="symbols">
<t> Clients may be unable to stay in sleep mode due to
multicast control packets frequently waking them up.</t>
<t> A unicast packet is delayed until an STA wakes up and requests
it. Unicast traffic may also be delayed to improve power it. Unicast traffic may also be delayed to improve power
save, efficiency and increase probability of aggregation.</t> save and efficiency and to increase the probability of aggregatio
n.</li>
<t> Multicast traffic is delayed in a wireless network if any of <li> Multicast traffic is delayed in a wireless network if any of
the STAs in that network are power savers. the STAs in that network are power savers.
All STAs associated to the AP have to be All STAs associated with the AP have to be
awake at a known time to receive multicast traffic.</t> awake at a known time to receive multicast traffic.</li>
<li> Packets can also be discarded due to buffer limitations in
<t> Packets can also be discarded due to buffer limitations in the AP and non-AP STA.</li>
the AP and non-AP STA.</t> </ul>
</list></t> </section>
</section> <!-- end section "Power-save Effects on Multicast" --> </section>
</section> <!-- end section "Issues at Layer 2 and Below" -->
<section anchor="l3_issues" title="Issues at Layer 3 and Above"> <section anchor="l3_issues" numbered="true" toc="default">
<t> This section identifies some representative IETF protocols, and <name>Issues at Layer 3 and Above</name>
<t> This section identifies some representative IETF protocols and
describes possible negative effects due to performance degradation describes possible negative effects due to performance degradation
when using multicast transmissions for control messages. when using multicast transmissions for control messages.
Common uses of multicast include: Common uses of multicast include:
<list style="symbols"> </t>
<t> Control plane signaling </t> <ul>
<t> Neighbor Discovery </t> <li> Control plane signaling </li>
<t> Address Resolution </t> <li> Neighbor Discovery </li>
<t> Service Discovery </t> <li> Address resolution </li>
<t> Applications (video delivery, stock data, etc.) </t> <li> Service Discovery </li>
<t> On-demand routing </t> <li> Applications (video delivery, stock data, etc.) </li>
<t> Backbone construction </t> <li> On-demand routing </li>
<t> Other L3 protocols (non-IP) </t> <li> Backbone construction </li>
<!-- CEP: citations needed here, especially for non-IP protocols. --> <li> Other Layer 3 protocols (non-IP) </li>
</list> </ul>
</t> <t>
<t> User Datagram Protocol (UDP) is the most common transport-layer
User Datagram Protocol (UDP) is the most common transport layer
protocol for multicast applications. protocol for multicast applications.
By itself, UDP is not reliable -- messages may be lost or By itself, UDP is not reliable -- messages may be lost or
delivered out of order. delivered out of order.
</t> </t>
<section anchor="IPv4" numbered="true" toc="default">
<section anchor="IPv4" title="IPv4 issues"> <name>IPv4 Issues</name>
<t> The following list contains some representative <t> The following list contains some representative
discovery protocols, which utilize broadcast/multicast, that are used discovery protocols that utilize broadcast/multicast and are used wit
with IPv4. h IPv4.
<list style="symbols"> </t>
<t>ARP <xref target="RFC0826"/></t> <ul>
<t>DHCP <xref target="RFC2131"/></t> <li>ARP <xref target="RFC0826" format="default"/></li>
<t>mDNS <xref target="RFC6762"/></t> <li>DHCP <xref target="RFC2131" format="default"/></li>
<t>uPnP <xref target="RFC6970"/></t> <li>Multicast DNS (mDNS) <xref target="RFC6762" format="default"/></
</list></t> li>
<li>Universal Plug and Play (uPnP) <xref target="RFC6970" format="de
<t> After initial configuration, ARP (described in more detail later), D fault"/></li>
HCP and uPnP occur much less </ul>
<t> After initial configuration, ARP (described in more detail later),
DHCP, and uPnP occur much less
commonly, but service discovery can occur at any time. Some commonly, but service discovery can occur at any time. Some
widely-deployed service discovery protocols (e.g., for finding a widely deployed service discovery protocols (e.g., for finding a
printer) utilize mDNS (i.e., multicast) which is often dropped by ope printer) utilize mDNS (i.e., multicast), which is often dropped by op
rators. Even if multicast erators. Even if multicast
snooping <xref target="RFC4541"/> (which provides the benefit of cons snooping <xref target="RFC4541" format="default"/> (which provides th
erving e benefit of conserving
bandwidth on those segments of the network where no node has expresse d interest in receiving bandwidth on those segments of the network where no node has expresse d interest in receiving
packets addressed to the group address) is utilized, many devices can register at once and cause serious packets addressed to the group address) is utilized, many devices can register at once and cause serious
network degradation.</t> network degradation.</t>
</section> <!-- end section 'IPv4 uses' --> </section>
<section anchor="IPv6" title="IPv6 issues"> <section anchor="IPv6" numbered="true" toc="default">
<t> IPv6 makes extensive use of multicast, including the following: <name>IPv6 Issues</name>
<list style="symbols"> <t> IPv6 makes extensive use of multicast, including the following:
<t> DHCPv6 <xref target="RFC8415"/></t> </t>
<t> Protocol Independent Multicast (PIM) <xref target="RFC7761"/></t> <ul>
<t> IPv6 Neighbor Discovery Protocol (NDP) <xref target="RFC4861"/></ <li> DHCPv6 <xref target="RFC8415" format="default"/></li>
t> <li> Protocol Independent Multicast (PIM) <xref target="RFC7761" for
<t> multicast DNS (mDNS) <xref target="RFC6762"/></t> mat="default"/></li>
<t> Router Discovery <xref target="RFC4286"/></t> <li> IPv6 Neighbor Discovery Protocol (NDP) <xref target="RFC4861" f
</list></t> ormat="default"/></li>
<t> IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate Addres <li> Multicast DNS (mDNS) <xref target="RFC6762" format="default"/><
s /li>
Detection (DAD) and Address Lookup make use of Link-Scope multicast. <li> Router Discovery <xref target="RFC4286" format="default"/></li>
In </ul>
<t> IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate Add
ress
Detection (DAD) and address lookup make use of link-scope multicast.
In
contrast to IPv4, an IPv6 node will typically use multiple contrast to IPv4, an IPv6 node will typically use multiple
addresses, and may change them often for privacy reasons. This addresses and may change them often for privacy reasons. This
intensifies the impact of multicast messages that are associated intensifies the impact of multicast messages that are associated
to the mobility of a node. Router advertisement (RA) messages with the mobility of a node. Router advertisement (RA) messages
are also periodically multicasted over the Link. are also periodically multicast over the link.
</t> </t>
<t> Neighbors may be considered lost if several consecutive <t> Neighbors may be considered lost if several consecutive
Neighbor Discovery packets fail. Neighbor Discovery packets fail.
</t> </t>
</section> <!-- end section 'IPv6 uses' --> </section>
<section anchor="mld" title="MLD issues"> <section anchor="mld" numbered="true" toc="default">
<t> Multicast Listener Discovery (MLD) <xref target="RFC4541"/> is <name>MLD Issues</name>
<t> Multicast Listener Discovery (MLD) <xref target="RFC4541" format="
default"/> is
used to identify members of a multicast group that are connected to used to identify members of a multicast group that are connected to
the ports of a switch. Forwarding multicast frames into a the ports of a switch. Forwarding multicast frames into a
Wi-Fi-enabled area can use switch support for hardware Wi-Fi-enabled area can use switch support for hardware
forwarding state information. However, since IPv6 makes heavy use forwarding state information. However, since IPv6 makes heavy use
of multicast, each STA with an IPv6 address will require state on of multicast, each STA with an IPv6 address will require state on
the switch for several and possibly many multicast solicited-node the switch for several and possibly many solicited-node multicast
addresses. A solicited-node multicast address is an IPv6 multicast addresses. A solicited-node multicast address is an IPv6 multicast
address used by NDP to verify whether an IPv6 address is already address used by NDP to verify whether an IPv6 address is already
used by the local-link. Multicast addresses that do not have forwardi ng state used by the local link. Multicast addresses that do not have forwardi ng state
installed (perhaps due to hardware memory limitations on the installed (perhaps due to hardware memory limitations on the
switch) cause frames to be flooded on all ports of the switch. Some 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 switch vendors do not support MLD for link-scope multicast due to
the increase it can cause in state. </t> the increase it can cause in state. </t>
</section> <!-- end section "MLD issues" --> </section>
<section anchor="spurious" title="Spurious Neighbor Discovery"> <section anchor="spurious" numbered="true" toc="default">
<t> On the Internet there is a "background radiation" of scanning <name>Spurious Neighbor Discovery</name>
<t> On the Internet, there is a "background radiation" of scanning
traffic (people scanning for vulnerable machines) and backscatter traffic (people scanning for vulnerable machines) and backscatter
(responses from spoofed traffic, etc). This means that routers (responses from spoofed traffic, etc.). This means that routers
very often receive packets destined for IPv4 addresses regardless of very often receive packets destined for IPv4 addresses regardless of
whether those IP addresses are in use. In the cases where the IP 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 bac is assigned to a host, the router broadcasts an ARP request, receives
k an ARP an ARP
reply, and caches it; then traffic can be delivered to the host. 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 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 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 not populate the ARP cache, and the next time there is traffic for
that IP address the router will rebroadcast the ARP requests. that IP address, the router will rebroadcast the ARP requests.
</t> </t>
<t> The rate of these ARP requests is proportional to the size of the
<t> 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 rate is inversely proportional to how occupied the subnet is
(valid ARPs end up in a cache, stopping the broadcasting; unused (valid ARPs end up in a cache, stopping the broadcasting; unused
IPs never respond, and so cause more broadcasts). Depending on IPs never respond, and so cause more broadcasts). Depending on
the address space in use, the time of day, how occupied the the address space in use, the time of day, how occupied the
subnet is, and other unknown factors, thousands of broadcasts per sec ond subnet is, and other unknown factors, thousands of broadcasts per sec ond
have been observed. Around 2,000 broadcasts per second have been obse rved at have been observed. Around 2,000 broadcasts per second have been obse rved at
the IETF NOC during face-to-face meetings. </t> the IETF NOC during face-to-face meetings. </t>
<t> With Neighbor Discovery for IPv6 <xref target="RFC4861" format="de
<t> With Neighbor Discovery for IPv6 <xref target="RFC4861"/>, nodes fault"/>, nodes
accomplish address resolution by multicasting a Neighbor Solicitation accomplish address resolution by multicasting a Neighbor Solicitation
that asks the target node to return its link-layer address. Neighbor that asks the target node to return its link-layer address. Neighbor
Solicitation messages are multicast to the solicited-node multicast Solicitation messages are multicast to the solicited-node multicast
address of the target address. The target returns its link-layer address address of the target address. The target returns its link-layer address
in a unicast Neighbor Advertisement message. A single request-response in a unicast Neighbor Advertisement message. A single request-response
pair of packets is sufficient for both the initiator and the target to res olve pair of packets is sufficient for both the initiator and the target to res olve
each other's link-layer addresses; the initiator includes its link-layer each other's link-layer addresses; the initiator includes its link-layer
address in the Neighbor Solicitation.</t> address in the Neighbor Solicitation.</t>
<t> On a wired network, there is not a huge difference between unicast
<t> On a wired network, there is not a huge difference between unicast, ,
multicast and broadcast traffic. Due to hardware filtering multicast, and broadcast traffic. Due to hardware filtering
(see, e.g., <xref target="Deri-2010" />), inadvertently flooded (see, e.g., <xref target="Deri-2010" format="default"/>), inadvertent
traffic (or excessive ethernet multicast) on wired networks ly flooded
can be quite a bit less costly, compared to wireless cases where slee traffic (or excessive Ethernet multicast) on wired networks
ping can be quite a bit less costly compared to wireless cases where sleep
ing
devices have to wake up to process packets. Wired Ethernets tend to be switched devices have to wake up to process packets. Wired Ethernets tend to be switched
networks, further reducing interference from multicast. There is networks, further reducing interference from multicast. There is
effectively no collision / scheduling problem except at extremely effectively no collision / scheduling problem except at extremely
high port utilizations. </t> high port utilizations. </t>
<t> This is not true in the wireless realm; wireless equipment is
<t> This is not true in the wireless realm; wireless equipment is
often unable to send high volumes of broadcast and multicast often unable to send high volumes of broadcast and multicast
traffic, causing numerous broadcast and multicast packets to be traffic, causing numerous broadcast and multicast packets to be
dropped. Consequently, when a host connects it is often not dropped. Consequently, when a host connects, it is often not
able to complete DHCP, and IPv6 RAs get dropped, leading to able to complete DHCP, and IPv6 RAs get dropped, leading to
users being unable to use the network.</t> users being unable to use the network.</t>
</section> <!-- end section "Spurious Neighbor Discovery" --> </section>
</section> <!-- end section "Issues at Layer 3 and Above" --> </section>
</section> </section>
<section anchor="optim2" numbered="true" toc="default">
<section anchor="optim2" title="Multicast protocol optimizations"> <name>Multicast Protocol Optimizations</name>
<t> This section lists some optimizations that have been specified in <t> This section lists some optimizations that have been specified in
IEEE 802 and IETF that are aimed at reducing or eliminating the IEEE 802 and IETF that are aimed at reducing or eliminating the
issues discussed in <xref target="multicast_issues"/>.</t> issues discussed in <xref target="multicast_issues" format="default"/>.</
t>
<section anchor="proxy-arp" title="Proxy ARP in 802.11-2012"> <section anchor="proxy-arp" numbered="true" toc="default">
<t> The AP knows the MAC address and IP address for all associated <name>Proxy ARP in 802.11-2012</name>
<t> The AP knows the Medium Access Control (MAC) address and IP address
for all associated
STAs. In this way, the AP acts as the central "manager" for all STAs. In this way, the AP acts as the central "manager" for all
the 802.11 STAs in its basic service set (BSS). Proxy ARP is easy to the 802.11 STAs in its Basic Service Set (BSS). Proxy ARP is easy to
implement at the implement at the
AP, and offers the following advantages: AP and offers the following advantages:
<list style="symbols"> </t>
<t> Reduced broadcast traffic (transmitted at low MCS) on the <ul>
wireless medium</t> <li> Reduced broadcast traffic (transmitted at low MCS) on the
<t> STA benefits from extended power save in sleep mode, as ARP wireless medium.</li>
requests for STA's IP address are handled instead by the AP.</t> <li> STA benefits from extended power save in sleep mode, as ARP
<t> ARP frames are kept off the wireless medium.</t> requests for STA's IP address are handled instead by the AP.</li>
<t> No changes are needed to STA implementation.</t> <li> ARP frames are kept off the wireless medium.</li>
</list></t> <li> No changes are needed to STA implementation.</li>
</ul>
<t> Here is the specification language as <t> Here is the specification language as
described in clause 10.23.13 of <xref target="dot11-proxyarp"/>: described in clause 10.23.13 of <xref target="dot11-proxyarp" format=
<list style="empty"> "default"/>:
<t> When the AP supports Proxy ARP "[...] the AP shall maintain a </t>
<blockquote><t>When the AP supports Proxy ARP "[...] the AP shall main
tain a
Hardware Address to Internet Address mapping for each Hardware Address to Internet Address mapping for each
associated station, and shall update the mapping when the associated station, and shall update the mapping when the
Internet Address of the associated station changes. When the Internet Address of the associated station changes. When the
IPv4 address being resolved in the ARP request packet is used IPv4 address being resolved in the ARP request packet is used
by a non-AP STA currently associated to the BSS, the proxy ARP by a non-AP STA currently associated to the BSS, the proxy ARP
service shall respond on behalf of the non-AP STA".</t> service shall respond on behalf of the STA to an ARP request or a
</list></t> n ARP Probe.
</section> <!-- end section "Proxy ARP in 802.11-2012" --> </t></blockquote>
</section>
<section anchor="proxy-ND"
title="IPv6 Address Registration and Proxy Neighbor Discovery">
<t> <section anchor="proxy-ND" numbered="true" toc="default">
<name>IPv6 Address Registration and Proxy Neighbor Discovery</name>
<t>
As used in this section, As used in this section,
a Low-Power Wireless Personal Area Network (6LoWPAN) denotes a low a Low-Power Wireless Personal Area Network (6LoWPAN) denotes a Low-Power
power lossy network (LLN) that supports and Lossy Network (LLN) that supports
<xref target="RFC6282"> 6LoWPAN Header Compression (HC)</xref>. <xref target="RFC6282" format="default"> 6LoWPAN Header Compression (HC)<
A <xref target="I-D.ietf-6tisch-architecture">6TiSCH network</xref> /xref>.
is an example of a 6LowPAN. A <xref target="RFC9030" format="default">6TiSCH network</xref>
is an example of a 6LoWPAN.
In order to control the use of IPv6 multicast over 6LoWPANs, the In order to control the use of IPv6 multicast over 6LoWPANs, the
<xref target="RFC6775">6LoWPAN Neighbor Discovery (6LoWPAN ND)</xref> <xref target="RFC6775" format="default">6LoWPAN Neighbor Discovery (6LoWP AN ND)</xref>
standard defines an address registration mechanism that relies on a standard defines an address registration mechanism that relies on a
central registry to assess address uniqueness, as a substitute to the central registry to assess address uniqueness as a substitute to the
inefficient DAD mechanism found in the mainstream IPv6 Neighbor Discovery Protocol (NDP) inefficient DAD mechanism found in the mainstream IPv6 Neighbor Discovery Protocol (NDP)
<xref target="RFC4861"/><xref target="RFC4862"/>. <xref target="RFC4861" format="default"/> <xref target="RFC4862" format="
</t> default"/>.
</t>
<t> <t>
The 6lo Working Group has specified an The 6lo Working Group has specified an
<xref target="RFC8505">update</xref> to RFC6775. <xref target="RFC8505" format="none">update</xref> to <xref target="RFC67 75"/>.
Wireless devices can register their address to a Wireless devices can register their address to a
<xref target="I-D.ietf-6lo-backbone-router">Backbone Router</xref>, <xref target="RFC8929" format="default">Backbone Router</xref>,
which proxies for the registered addresses with the IPv6 which proxies for the registered addresses with the IPv6
NDP running on a high speed aggregating backbone. The update also NDP running on a high-speed aggregating backbone. The update also
enables a proxy registration mechanism on behalf of the registered enables a proxy registration mechanism on behalf of the Registered
node, e.g. by a 6LoWPAN router to which the mobile node is attached. Node, e.g., by a 6LoWPAN router to which the mobile node is attached.
</t> </t>
<t>
<t> The general idea behind the Backbone Router concept is that broadcast
The general idea behind the backbone router concept is that broadcast
and multicast messaging should be tightly controlled in a variety and multicast messaging should be tightly controlled in a variety
of WLANs and Wireless Personal Area of WLANs and Wireless Personal Area
Networks (WPANs). Networks (WPANs).
Connectivity to a particular link that provides the subnet should Connectivity to a particular link that provides the subnet should
be left to Layer-3. The model for the Backbone Router operation is be left to Layer 3. The model for the Backbone Router operation is
represented in <xref target='figBackbone'/>. represented in <xref target="figBackbone" format="default"/>.
</t> </t>
<figure anchor="figBackbone">
<figure anchor='figBackbone' title="Backbone Link and Backbone Routers"> <name>Backbone Link and Backbone Routers</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| |
+-----+ +-----+
| | Gateway (default) router | | Gateway (default) router
| | | |
+-----+ +-----+
| |
| Backbone Link | Backbone Link
+--------------------+------------------+ +--------------------+------------------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
skipping to change at line 665 skipping to change at line 562
| | router 1 | | router 2 | | router 3 | | router 1 | | router 2 | | router 3
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o
LLN 1 LLN 2 LLN 3 LLN 1 LLN 2 LLN 3
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
LLN nodes can move freely from an LLN anchored at one IPv6 Backbone Router LLN nodes can move freely from an LLN anchored at one IPv6 Backbone Router
to an LLN anchored at another Backbone Router on the same backbone, to an LLN anchored at another Backbone Router on the same backbone,
keeping any of the IPv6 addresses they have configured. keeping any of the IPv6 addresses they have configured.
The Backbone Routers maintain a Binding Table of their The Backbone Routers maintain a Binding Table of their
Registered Nodes, which serves as a distributed database of all the LLN Registered Nodes, which serves as a distributed database of all the LLN
Nodes. An extension to the Neighbor Discovery Protocol is introduced to nodes. An extension to the Neighbor Discovery Protocol is introduced to
exchange Binding Table information across the Backbone Link as needed exchange Binding Table information across the Backbone Link as needed
for the operation of IPv6 Neighbor Discovery. for the operation of IPv6 Neighbor Discovery.
</t> </t>
<t> <t>
RFC6775 and follow-on work <xref target="RFC8505"/> <xref target="RFC6775"/> and follow-on work <xref target="RFC8505" format
="default"/>
address the needs of LLNs, and similar techniques are likely to be address the needs of LLNs, and similar techniques are likely to be
valuable on any type of valuable on any type of
link where sleeping devices are attached, or where the use of link where sleeping devices are attached or where the use of
broadcast and multicast operations should be limited. </t> broadcast and multicast operations should be limited. </t>
</section> </section>
<section anchor="buffer" numbered="true" toc="default">
<section anchor="buffer" title="Buffering to Improve Battery Life"> <name>Buffering to Improve Battery Life</name>
<t> Methods have been developed to help save battery life; for example, <t> Methods have been developed to help save battery life; for example,
a device might not wake up when the AP receives a multicast packet. a device might not wake up when the AP receives a multicast packet.
The AP acts on behalf of STAs in various ways. To enable use of The AP acts on behalf of STAs in various ways. To enable use of
the power-saving feature for STAs in its BSS, the AP buffers frames the power-saving feature for STAs in its BSS, the AP buffers frames
for delivery to the STA at the time when the STA is scheduled for for delivery to the STA at the time when the STA is scheduled for
reception. If an AP, for instance, expresses a DTIM (Delivery Traffic reception. If an AP, for instance, expresses a Delivery Traffic
Indication Message) of 3 then Indication Message (DTIM) of 3, then
the AP will send a multicast packet every 3 packets. In fact, the AP will send a multicast packet every 3 packets. In fact,
when any single wireless STA associated with an access point has when any single wireless STA associated with an AP has
802.11 power-save mode enabled, the access point buffers all multicast 802.11 power-save mode enabled, the AP buffers all multicast
frames and sends them only after the next DTIM beacon. </t> frames and sends them only after the next DTIM beacon. </t>
<t> In practice, most APs will send a multicast every 30 packets.
<t> In practice, most AP's will send a multicast every 30 packets. For unicast, the AP could send a Traffic Indication Message (TIM),
For unicast the AP could send a TIM (Traffic Indication Message), but, for multicast, the AP sends a broadcast to everyone. DTIM does
but for multicast the AP sends a broadcast to everyone. DTIM does power management, but STAs can choose whether to wake up
power management but STAs can choose whether or not to wake up and whether to drop the packet. Unfortunately, without proper administra
and whether or not to drop the packet. Unfortunately, without proper adm tive
inistrative
control, such STAs may be unable to determine why their control, such STAs may be unable to determine why their
multicast operations do not work. </t> multicast operations do not work. </t>
</section> <!-- end of section 'Buffering to improve Power-Save' --> </section>
<section title="Limiting multicast buffer hardware queue depth"> <section numbered="true" toc="default">
<t>The CAB (Content after Beacon) queue is used for beacon-triggered <name>Limiting Multicast Buffer Hardware Queue Depth</name>
<t>The Content after Beacon (CAB) queue is used for beacon-triggered
transmission of buffered multicast frames. If lots of multicast frames were transmission of buffered multicast frames. If lots of multicast frames were
buffered, and this queue fills up, it drowns out all regular traffic. To lim it the buffered and this queue fills up, it drowns out all regular traffic. To limi t the
damage that buffered traffic can do, some drivers limit the amount of 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 queued multicast data to a fraction of the beacon_interval. An example of
this is <xref target="CAB" />. </t> this is <xref target="CAB" format="default"/>. </t>
</section> </section>
<section anchor="ipv6" numbered="true" toc="default">
<section anchor="ipv6" title="IPv6 support in 802.11-2012"> <name>IPv6 Support in 802.11-2012</name>
<t> IPv6 uses NDP instead of ARP. Every IPv6 node subscribes to a special <t> IPv6 uses NDP instead of ARP. Every IPv6 node subscribes to a specia
l
multicast address for this purpose. multicast address for this purpose.
</t> </t>
<t> Here is the specification language from clause 10.23.13
<t> Here is the specification language from clause 10.23.13 of <xref target="dot11-proxyarp" format="default"/>:
of <xref target="dot11-proxyarp"/>: </t>
<list style="empty"> <blockquote>
<t>"When an IPv6 address is being resolved, the Proxy Neighbor <t>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]
Neighbor Solicitation message [...]. When MAC address mappings Neighbor Solicitation message [...]. When MAC address mappings
change, the AP may send unsolicited Neighbor Advertisement change, the AP may send unsolicited Neighbor Advertisement
Messages on behalf of a STA."</t> Messages on behalf of a STA.</t>
</list></t> </blockquote>
<t>NDP may be used to request additional information using the following
<t>NDP may be used to request additional information methods, among others:
<list style="symbols"> </t>
<t>Maximum Transmission Unit</t> <ul>
<t>Router Solicitation</t> <li>Maximum Transmission Unit</li>
<t>Router Advertisement, etc.</t> <li>Router Solicitation</li>
</list> <li>Router Advertisement</li>
NDP messages are sent as group addressed (broadcast) frames </ul>
<t>
NDP messages are sent as group-addressed (broadcast) frames
in 802.11. Using the proxy operation helps to keep NDP messages off in 802.11. Using the proxy operation helps to keep NDP messages off
the wireless medium.</t> the wireless medium.</t>
</section> <!-- end of section 'IPv6 support in 802.11-2012' --> </section>
<section anchor="convert" title="Using Unicast Instead of Multicast"> <section anchor="convert" numbered="true" toc="default">
<t> It is often possible to transmit multicast control and data messages <name>Using Unicast Instead of Multicast</name>
<t> It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually.</t> by using unicast transmissions to each station individually.</t>
<section anchor="convert-over" numbered="true" toc="default">
<section anchor="convert-over" title="Overview"> <name>Overview</name>
<t> <t>
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 multicast over the Wi-Fi link. This avoids most of the
problems specific to multicast over Wi-Fi, since the individual problems specific to multicast over Wi-Fi, since the individual
frames are then acknowledged and buffered for power save clients, frames are then acknowledged and buffered for power-save clients
in the way that unicast traffic normally operates. in the way that unicast traffic normally operates.
</t> </t>
<t> <t>
This approach comes with the tradeoff of sometimes sending This approach comes with the trade-off of sometimes sending
the same packet multiple times over the Wi-Fi link. However, the same packet multiple times over the Wi-Fi link. However,
in many cases, such as video into a residential home network, in many cases, such as video into a residential home network,
this can be a good tradeoff, since the Wi-Fi link may have enough this can be a good trade-off since the Wi-Fi link may have enough
capacity for the unicast traffic to be transmitted to each capacity for the unicast traffic to be transmitted to each
subscribed STA, even though multicast addressing may have been subscribed STA, even though multicast addressing may have been
necessary for the upstream access network. necessary for the upstream access network.
</t> </t>
<t> <t>
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.
</t> </t>
</section> <!-- end of section 'Overview' --> </section>
<section anchor="convert-l2" <section anchor="convert-l2" numbered="true" toc="default">
title="Layer 2 Conversion to Unicast"> <name>Layer 2 Conversion to Unicast</name>
<t> <t>
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.
</t> </t>
<t> <t>
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 <xref target="bridge-mc-2-uc"/>. Other proprietary bridging code <xref target="bridge-mc-2-uc" format="default"/>. Othe r proprietary
implementations are available from various vendors. implementations are available from various vendors.
In general, these implementations perform a straightforward In general, these implementations perform a straightforward
mapping for groups or channels, discovered by IGMP or MLD mapping for groups or channels, discovered by IGMP or MLD
snooping, to the corresponding unicast MAC addresses. snooping, to the corresponding unicast MAC addresses.
</t> </t>
</section> <!-- end of section 'Layer 2 Conversion to Unicast' --> </section>
<section anchor="convert-DMS" title="Directed Multicast Service (DMS)"> <section anchor="convert-DMS" numbered="true" toc="default">
<t> <name>Directed Multicast Service (DMS)</name>
There are situations where more is needed than simply converting <t>
multicast to unicast. <!-- Editor's note: citation needed --> DMS enables an STA to request that the AP
For these purposes, DMS enables an STA to request that the AP transmit multicast group-addressed frames destined to the
transmit multicast group addressed frames destined to the requesting STAs as individually addressed frames (i.e., convert
requesting STAs as individually addressed frames [i.e., convert multicast to unicast). Here are some characteristics of DMS:
multicast to unicast]. Here are some characteristics of DMS: </t>
<list style="symbols"> <ul>
<t> Requires 802.11n A-MSDUs</t> <li> Requires 802.11n Aggregate MAC Service Data Units (A-MSDU
<t> Individually addressed frames are acknowledged and are s).</li>
buffered for power save STAs</t> <li> Individually addressed frames are acknowledged and are
<t> The requesting STA may specify traffic characteristics for buffered for power-save STAs.</li>
DMS traffic</t> <li> The requesting STA may specify traffic characteristics fo
<t> DMS was defined in IEEE Std 802.11v-2011</t> r
<t> DMS requires changes to both AP and STA implementation.</t> DMS traffic.</li>
</list>
<li> DMS was defined in IEEE Std 802.11v-2011 <xref target="v2
011"/>.</li>
<li> DMS requires changes to both AP and STA implementation.</li>
</ul>
<t>
DMS is not currently implemented in products. DMS is not currently implemented in products.
See <xref target="Tramarin2017"/> and <xref target="Oliva2013"/> See <xref target="Tramarin2017" format="default"/> and <xref target=" Oliva2013" format="default"/>
for more information. </t> for more information. </t>
</section> <!-- end of section 'Directed Multicast Service (DMS)' --> </section>
<section anchor="convert-amt" <section anchor="convert-amt" numbered="true" toc="default">
title="Automatic Multicast Tunneling (AMT)"> <name>Automatic Multicast Tunneling (AMT)</name>
<t> <t>
AMT<xref target="RFC7450"/> provides a method to tunnel multicast AMT <xref target="RFC7450" format="default"/> provides a method to tu
nnel multicast
IP packets inside unicast IP packets over network links that only IP packets inside unicast IP packets over network links that only
support unicast. When an operating system or application running support unicast. When an operating system or application running
on an STA has an AMT gateway capability integrated, it's possible on an STA has an AMT gateway capability integrated, it's possible
to use unicast to traverse the Wi-Fi link by deploying an AMT to use unicast to traverse the Wi-Fi link by deploying an AMT
relay in the non-Wi-Fi portion of the network connected to the AP. relay in the non-Wi-Fi portion of the network connected to the AP.
</t> </t>
<t> <t>
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 relays for this purpose make the relays locally discoverable with
the following methods, as described in the following methods, as described in
<xref target="I-D.ietf-mboned-driad-amt-discovery"/>: <xref target="RFC8777" format="default"/>:
<list style="symbols"> </t>
<t> DNS-SD <xref target="RFC6763"/></t> <ul>
<t> the well-known IP addresses from Section 7 of <li>DNS-based Service Discovery (DNS-SD) <xref target="RFC6763" form
<xref target="RFC7450"/></t> at="default"/></li>
</list> <li>The well-known IP addresses from <xref target="RFC7450" sectionF
</t> ormat="of" section="7"/></li>
<t> </ul>
<t>
An AMT gateway that implements multiple standard discovery methods An AMT gateway that implements multiple standard discovery methods
is more likely to discover the local multicast-capable network, is more likely to discover the local multicast-capable network
instead of forming a connection to a non-local AMT relay further upstr instead of forming a connection to a nonlocal AMT relay further upstre
eam. am.
</t> </t>
</section> <!-- end of section 'Automatic Multicast Tunneling (AMT)'--> </section>
</section> <!-- end of section 'Using Unicast Instead of Multicast' --> </section>
<section anchor="GCR" title="GroupCast with Retries (GCR)"> <section anchor="GCR" numbered="true" toc="default">
<t> GCR (defined in <xref target="dot11aa"/>) provides greater <name>GroupCast with Retries (GCR)</name>
<t> GCR (defined in <xref target="dot11aa" format="default"/>) provides
greater
reliability by using either unsolicited retries or a block reliability by using either unsolicited retries or a block
acknowledgement mechanism. GCR increases probability of broadcast acknowledgement mechanism. GCR increases the probability of broadcast
frame reception success, but still does not guarantee success.</t> frame reception success but still does not guarantee success.</t>
<t> For the block acknowledgement mechanism, the AP transmits each
<t> For the block acknowledgement mechanism, the AP transmits each group-addressed frame as a conventional group-addressed transmission.
group 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
status from receivers; retransmissions are based upon these status from receivers; retransmissions are based upon these
responses.</t> responses.</t>
<t> GCR is suitable for all group sizes including medium to large
<t> GCR is suitable for all group sizes including medium to large
groups. As the number of devices in the group increases, GCR can send groups. As the number of devices in the group increases, GCR can send
block acknowledgement requests to only a small subset of the group. block acknowledgement requests to only a small subset of the group.
GCR does require changes to both AP and STA implementations.</t> GCR does require changes to both AP and STA implementations.</t>
<t> GCR may introduce unacceptable latency. After sending a group of
<t> GCR may introduce unacceptable latency. After sending a group of
data frames to the group, the AP has to do the following: data frames to the group, the AP has to do the following:
<list style="symbols"> </t>
<t>unicast a Block Ack Request (BAR) to a subset of members.</t> <ul>
<li>Unicast a Block Ack Request (BAR) to a subset of members.</li>
<t>wait for the corresponding Block Ack (BA).</t> <li>Wait for the corresponding Block Ack (BA).</li>
<li>Retransmit any missed frames.</li>
<t>retransmit any missed frames.</t> <li>Resume other operations that may have been delayed.</li>
</ul>
<t>resume other operations that may have been delayed.</t> <t> This latency may not be acceptable for some traffic.</t>
</list> This latency may not be acceptable for some traffic.</t> <t> There are ongoing extensions in 802.11 to improve GCR performance.
</t>
<t> There are ongoing extensions in 802.11 to improve GCR performance. <ul>
<list style="symbols"> <li> BAR is sent using downlink Multi-User MIMO.</li>
<t> BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO <li> BA is sent using uplink MU-MIMO (uplink MU-MIMO is an IEEE 801.11
is already specified in 802.11-REVmc 4.3).</t> ax-2021 feature).</li>
<li> Latency may also be reduced by simultaneously receiving BA
<t> BA is sent using uplink MU-MIMO (which is a .11ax feature).</t> information from multiple STAs.</li>
</ul>
<t> Additional 802.11ax extensions are under consideration; see </section>
<xref target="mc-ack-mux"/></t>
<t> Latency may also be reduced by simultaneously receiving BA
information from multiple STAs.</t>
</list></t>
</section> </section>
</section> <section anchor="optim3" numbered="true" toc="default">
<name>Operational Optimizations</name>
<section anchor="optim3" title="Operational optimizations"> <t> This section lists some operational optimizations that can be
<t> This section lists some operational optimizations that can be
implemented when deploying wireless IEEE 802 networks to mitigate implemented when deploying wireless IEEE 802 networks to mitigate
some of the issues discussed in <xref target="multicast_issues"/>.</t> some of the issues discussed in <xref target="multicast_issues" format="d
<!-- Jake Holland: efault"/>.</t>
Is it worth adding here use cases that are considered probably useful, but
not currently done with multicast over Wi-Fi, in part because of these
concerns? (e.g. apps providing instant replays in a stadium IIUC currently
use unicast, but could theoretically share a lot of bandwidth)
-->
<section anchor="mitigate-spurious" <section anchor="mitigate-spurious" numbered="true" toc="default">
title="Mitigating Problems from Spurious Neighbor Discovery"> <name>Mitigating Problems from Spurious Neighbor Discovery</name>
<t> <list hangIndent="6" style="hanging"> <dl newline="true" indent="6">
<t hangText="ARP Sponges"><vspace blankLines="1"/> An ARP Sponge <dt>ARP Sponges</dt>
<dd>
<t> An ARP Sponge
sits on a network and learns which IP addresses are actually in sits on a network and learns which IP addresses are actually in
use. It also listens for ARP requests, and, if it sees an ARP for use. It also listens for ARP requests, and, if it sees an ARP for
an IP address that it believes is not used, it will reply with an IP address that it believes is not used, it will reply with
its own MAC address. This means that the router now has an IP to its own MAC address. This means that the router now has an IP-to-MAC
MAC mapping, which it caches. If that IP is later assigned to a mapping, which it caches. If that IP is later assigned to a
machine (e.g using DHCP), the ARP sponge will see this, and will machine (e.g., using DHCP), the ARP Sponge will see this and will
stop replying for that address. Gratuitous ARPs (or the machine stop replying for that address. Gratuitous ARPs (or the machine
ARPing for its gateway) will replace the sponged address in the ARPing for its gateway) will replace the sponged address in the
router ARP table. This technique is quite effective; but, router ARP table. This technique is quite effective; unfortunately, t
unfortunately, the ARP sponge daemons were not really designed for he ARP Sponge daemons were not really designed for
this use (one of the most widely deployed arp sponges this use (one of the most widely deployed ARP Sponges
<xref target="arpsponge"/>, was <xref target="arpsponge" format="default"/> was
designed to deal with the disappearance of participants from an designed to deal with the disappearance of participants from an
IXP) and so are not optimized for this purpose. One daemon is Internet Exchange Point (IXP)) and so are not optimized for this purp
needed per subnet, the tuning is tricky (the scanning rate versus ose.
the population rate versus retires, etc.) and sometimes daemons just
stop,
requiring a restart of the daemon which causes disruption. <vspace bl
ankLines="1"/></t>
<t hangText="Router mitigations"><vspace blankLines="1"/> Some One daemon is
needed per subnet; the tuning is tricky (the scanning rate versus
the population rate versus retries, etc.), and sometimes daemons just
stop,
requiring a restart of the daemon that causes disruption. </t>
</dd>
<dt>Router mitigations</dt>
<dd>
<t> Some
routers (often those based on Linux) implement a "negative ARP routers (often those based on Linux) implement a "negative ARP
cache" daemon. If the router does not see a reply to cache" daemon. If the router does not see a reply to
an ARP it can be configured to cache this information for some an ARP, it can be configured to cache this information for some
interval. Unfortunately, the core routers in use often do interval. Unfortunately, the core routers in use often do
not support this. Instead, when a host connects to a network and gets an IP not support this. Instead, when a host connects to a network and gets an IP
address, it will ARP for its default gateway (the router). The address, it will ARP for its default gateway (the router). The
router will update its cache with the IP to host MAC mapping router will update its cache with the IP to host MAC mapping
learned from the request (passive ARP learning). <vspace learned from the request (passive ARP learning). </t>
blankLines="1"/></t>
<t hangText="Firewall unused space"><vspace blankLines="1"/> The </dd>
<dt>Firewall unused space</dt>
<dd>
<t> The
distribution of users on wireless networks / subnets may change in va rious distribution of users on wireless networks / subnets may change in va rious
use cases, such as conference venues (e.g SSIDs are renamed, some SSI use cases, such as conference venues (e.g., Service Set Identifiers (
Ds SSIDs) are renamed, some SSIDs
lose favor, etc). This makes utilization for particular SSIDs lose favor, etc.). This makes utilization for particular SSIDs
difficult to predict ahead of time, but usage can be monitored difficult to predict ahead of time, but usage can be monitored
as attendees use the different networks. Configuring multiple as attendees use the different networks. Configuring multiple
DHCP pools per subnet, and enabling them sequentially, can create DHCP pools per subnet and enabling them sequentially can create
a large subnet, from which only addresses in the lower portions a large subnet from which only addresses in the lower portions
are assigned. Therefore input IP access lists can be applied, are assigned. Therefore, input IP access lists can be applied,
which deny traffic to the upper, unused portions. Then the which deny traffic to the upper, unused portions. Then the
router does not attempt to forward packets to the unused portions router does not attempt to forward packets to the unused portions
of the subnets, and so does not ARP for it. This method has proven of the subnets and so does not ARP for it. This method has proven
to be very effective, but is somewhat of a blunt axe, is fairly to be very effective but is somewhat of a blunt axe, is fairly
labor intensive, and requires coordination. <vspace labor intensive, and requires coordination. </t>
blankLines="1"/></t>
<t hangText="Disabling/filtering ARP requests"><vspace </dd>
blankLines="1"/> In general, the router does not need to ARP for <dt>Disabling/Filtering ARP requests</dt>
hosts; when a host connects, the router can learn the IP to MAC <dd>
mapping from the ARP request sent by that host. Consequently it <t> In general, the router does not need to ARP for
should be possible to disable and / or filter ARP requests from the hosts; when a host connects, the router can learn the IP-to-MAC
router. Unfortunately, ARP is a very low level / fundamental part mapping from the ARP request sent by that host. Consequently, it
of the IP stack, and is often offloaded from the normal control should be possible to disable and/or filter ARP requests from the
plane. While many routers can filter layer-2 traffic, this is router. Unfortunately, ARP is a very low-level/fundamental part
usually implemented as an input filter and / or has limited of the IP stack and is often offloaded from the normal control
ability to filter output broadcast traffic. This means that the plane. While many routers can filter Layer 2 traffic, this is
simple "just disable ARP or filter it outbound" seems like a usually implemented as an input filter and/or has limited
really simple (and obvious) solution, but implementations / ability to filter output broadcast traffic.
architectural issues make this difficult or awkward in practice.
<vspace blankLines="1"/></t>
<t hangText="NAT"><vspace blankLines="1"/> Broadcasts can often be This means that the seemingly simple and obvious solution to "just disable ARP o
caused by outside wifi scanning / backscatter traffic. In order to re r filter it outbound" is made difficult or awkward in practice by implementation
duce the impact of s and/or architectural issues.
</t>
</dd>
<dt>NAT</dt>
<dd>
<t> Broadcasts can often be
caused by outside Wi-Fi scanning / backscatter traffic. In order to r
educe the impact of
broadcasts, NAT can be used on the entire (or a large portion) of a n etwork. This would broadcasts, NAT can be used on the entire (or a large portion) of a n etwork. This would
eliminate NAT translation entries for unused addresses, and the route r would never ARP eliminate NAT translation entries for unused addresses, and the route r would never ARP
for them. There are, however, many reasons to avoid using NAT in such a blanket fashion. for them. There are, however, many reasons to avoid using NAT in such a blanket fashion.
<vspace blankLines="1"/></t> </t>
<t hangText="Stateful firewalls"><vspace blankLines="1"/> Another </dd>
<dt>Stateful firewalls</dt>
<dd> Another
obvious solution would be to put a stateful firewall between the obvious solution would be to put a stateful firewall between the
wireless network and the Internet. This firewall would block wireless network and the Internet. This firewall would block
incoming traffic not associated with an outbound request. incoming traffic not associated with an outbound request.
But this conflicts with the need and desire of some But this conflicts with the need and desire of some
organizations to have the network as open as possible and to organizations to have the network as open as possible and to
honor the end-to-end principle. An attendee on a meeting network honor the end-to-end principle. An attendee on a meeting network
should be an Internet host, and should be able to receive should be an Internet host and should be able to receive
unsolicited requests. Unfortunately, keeping the network working unsolicited requests. Unfortunately, keeping the network working
and stable is the first priority and a stateful firewall may be and stable is the first priority, and a stateful firewall may be
required in order to achieve this.</t> required in order to achieve this.</dd>
</list></t> </dl>
</section><!--'Mitigating Problems from Spurious Neighbor Discovery'--> </section>
<section anchor="mitigate-spurious-sd" <section anchor="mitigate-spurious-sd" numbered="true" toc="default">
title="Mitigating Spurious Service Discovery Messages"> <name>Mitigating Spurious Service Discovery Messages</name>
<t> <t>
In networks that must support hundreds of STAs, operators have In networks that must support hundreds of STAs, operators have
observed network degradation due to many devices simultaneously observed network degradation due to many devices simultaneously
registering with mDNS. In a network with many clients, it is registering with mDNS. In a network with many clients, it is
recommended to ensure that mDNS packets designed to discover recommended to ensure that mDNS packets designed to discover
services in smaller home networks be constrained to avoid services in smaller home networks be constrained to avoid
disrupting other traffic. disrupting other traffic.
</t> </t>
</section>
</section> <!-- 'Mitigating Spurious Service Discovery Messages' -->
</section> <!-- end section 'Layer 3 optimizations' -->
<section anchor="other-media" </section>
title="Multicast Considerations for Other Wireless Media">
<t> Many of the causes of performance degradation described in earlier <section anchor="other-media" numbered="true" toc="default">
<name>Multicast Considerations for Other Wireless Media</name>
<t> Many of the causes of performance degradation described in earlier
sections are also observable for wireless media other than 802.11.</t> sections are also observable for wireless media other than 802.11.</t>
<t> For instance, problems with power save, excess media occupancy, and
<t> For instance, problems with power save, excess media occupancy, and
poor reliability will also affect 802.15.3 and 802.15.4. Unfortunately, poor reliability will also affect 802.15.3 and 802.15.4. Unfortunately,
802.15 media specifications do not yet include mechanisms similar to 802.15 media specifications do not yet include mechanisms similar to
those developed for 802.11. In fact, the design philosophy for 802.15 those developed for 802.11. In fact, the design philosophy for 802.15
is oriented towards minimality, with the result that many such is oriented towards minimality, with the result that many such
functions are relegated to operation within higher layer protocols. functions are relegated to operation within higher-layer protocols.
This leads to a patchwork of non-interoperable and vendor-specific This leads to a patchwork of non-interoperable and vendor-specific
solutions. See <xref target="uli"/> for some additional discussion, solutions. See <xref target="uli" format="default"/> for additional disc ussion
and a proposal for a task group to resolve similar issues, in which and a proposal for a task group to resolve similar issues, in which
the multicast problems might be considered for mitigation. </t> the multicast problems might be considered for mitigation. </t>
<t> Similar considerations hold for most other wireless media. A brief
<t> Similar considerations hold for most other wireless media. A brief introduction is provided in <xref target="RFC5757" format="default"/> for
introduction is provided in <xref target="RFC5757"/> for the following: the following:
<list style="symbols"> </t>
<t> 802.16 WIMAX </t> <ul>
<t> 3GPP/3GPP2 </t> <li> 802.16 WiMAX </li>
<t> DVB-H / DVB-IPDC </t> <li> 3GPP/3GPP2 </li>
<t> TV Broadcast and Satellite Networks </t> <li> DVB-H/DVB-IPDC </li>
</list></t> <li> TV Broadcast and Satellite Networks </li>
</section> <!-- 'Multicast Considerations for Other Wireless Media' --> </ul>
</section>
<!-- CEP: More recommendations are needed. --> <section anchor="recommendations" numbered="true" toc="default">
<section anchor="recommendations" title="Recommendations"> <name>Recommendations</name>
<t> This section provides some recommendations about the usage and <t> This section provides some recommendations about the usage and
combinations of some of the multicast enhancements described in combinations of some of the multicast enhancements described in Sections
<xref target="optim2"/> and <xref target="optim3"/>.</t> <xref target="optim2" format="counter"/> and <xref target="optim3" format
<t> Future protocol documents utilizing multicast signaling should ="counter"/>.</t>
<t> Future protocol documents utilizing multicast signaling should
be carefully scrutinized if the protocol is likely to be used over be carefully scrutinized if the protocol is likely to be used over
wireless media. </t> wireless media. </t>
<t> The use of proxy methods should be encouraged to conserve network bandwi <t> The use of proxy methods should be encouraged to conserve network band
dth width
and power utilization by low-power devices. The device can use and power utilization by low-power devices.
a unicast message to its proxy, and then the proxy can take care
The device can send a unicast message to its proxy, and then the proxy can take
care
of any needed multicast operations. </t> of any needed multicast operations. </t>
<t> Multicast signaling for wireless devices should be done in a way <t> Multicast signaling for wireless devices should be done in a way that is
compatible with low duty-cycle operation. </t> compatible with low duty-cycle operation. </t>
</section> </section>
<section anchor="discussion" numbered="true" toc="default">
<name>Ongoing Discussion Items</name>
<t> This section suggests two discussion items for further resolution
. </t>
<t> First, standards (and private) organizations should develop guidelines
to help clarify when
multicast packets would be better served by being sent wired rather than
wireless.
For example, 802.1ak <xref target="IEEE802.1ak"/> works on
both Ethernet and Wi-Fi, and organizations could help with deployment dec
ision making
by developing guidelines for multicast over Wi-Fi, including options for
when traffic should be sent wired.
</t>
<section anchor="discussion" title="On-going Discussion Items"> <t>
<t> This section suggests two discussion items for further resolution Second, reliable registration to Layer 2 multicast groups and a reliable
. </t> multicast operation at Layer 2 might provide a good multicast over Wi-Fi
<t> First, standards (and private) organizations should develop guidelines t solution.
o help clarify when There shouldn't be a need to support 2<sup>24</sup> groups to get solicit
multicast packets would be better served by being sent wired rather than ed node
wireless. For example,
<eref target="https://www.ieee802.org/1/pages/802.1ak.html">802.1ak</eref
> works on
both ethernet and Wi-Fi and organizations could help with deployment deci
sion making
by developing guidelines for multicast over Wi-Fi including options for w
hen traffic should be sent wired.
</t>
<t>
Second, reliable registration to Layer-2 multicast groups, and a reliable
multicast operation at Layer-2, might provide a good multicast over wifi
solution.
There shouldn't be a need to support 2^24 groups to get solicited node
multicast working: it is possible to simply select a number of multicast working: it is possible to simply select a number of
bits that make sense for a given network size to limit the bits that make sense for a given network size to limit the
number of unwanted deliveries to reasonable levels. IEEE 802.1, number of unwanted deliveries to reasonable levels.
802.11, and 802.15 should be encouraged to revisit L2 multicast issues an The IEEE 802.1,
d provide 802.11, and 802.15 Working Groups should be encouraged to revisit Layer 2
multicast issues and provide
workable solutions. workable solutions.
</t> </t>
</section> </section>
<section anchor="sec" numbered="true" toc="default">
<section anchor="sec" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This document does not introduce or modify any security mechanisms. This document does not introduce or modify any security mechanisms.
Multicast deployed on wired or wireless networks as discussed in this doc ument can be Multicast deployed on wired or wireless networks as discussed in this doc ument can be
made more secure in a variety of ways. <xref target="RFC4601"/>, for inst made more secure in a variety of ways.
ance, <xref target="RFC4601" format="default"/>, for instance,
specifies the use of IPsec to ensure authentication of the link-local messages specifies the use of IPsec to ensure authentication of the link-local messages
in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol.
<xref target="RFC5796"/>specifies mechanisms to authenticate the PIM-SM link-l ocal messages <xref target="RFC5796" format="default"/> specifies mechanisms to authenticate the PIM-SM link-local messages
using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optiona lly) the using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optiona lly) the
Authentication Header (AH). Authentication Header (AH).
</t> </t>
<t>When using mechanisms that convert multicast traffic to unicast traffic f <t>When using mechanisms that convert multicast traffic to unicast traffic
or traversing radio links, for traversing radio links,
the AP (or other entity) is forced to explicitly track which subscribers car e about certain multicast traffic. the AP (or other entity) is forced to explicitly track which subscribers car e about certain multicast traffic.
This is generally a reasonable tradeoff, but does result in another entity t hat is tracking what entities This is generally a reasonable trade-off but does result in another entity t hat is tracking what entities
subscribe to which multicast traffic. While such information is already (by necessity) tracked elsewhere, subscribe to which multicast traffic. While such information is already (by necessity) tracked elsewhere,
this does present an expansion of the attack surface for that potentially pr ivacy-sensitive information.</t> this does present an expansion of the attack surface for that potentially pr ivacy-sensitive information.</t>
<t> <t>
As noted in <xref target="group_key"/>, the unreliable nature of As noted in <xref target="group_key" format="default"/>, the unreliable n
ature of
multicast transmission over wireless media can cause subtle problems multicast transmission over wireless media can cause subtle problems
with multicast group key management and updates. When WPA (TKIP) or WPA2 with multicast group key management and updates.
(AES-CCMP)
encryption is in use, AP to client (From DS) multicasts have to be encryp <xref target="group_key"/> states that when TKIP (WPA, now deprecated) or AES-CC
ted with a separate encryption key that MP (WPA2/WPA3) encryption is in use, AP-to-client (FromDS) multicasts have to be
encrypted with a separate encryption key that
is known to all of the clients (this is called the Group Key). Quoting fu rther from that is known to all of the clients (this is called the Group Key). Quoting fu rther from that
website, "... most clients are able to get connected and surf the web, website, "... most clients are able to get connected and surf the web,
check email, etc. even when From DS multicasts are broken. So a lot of check email, etc. even when FromDS multicasts are broken. So a lot of
people don't realize they have multicast problems on their network..." people don't realize they have multicast problems on their network..."
</t> </t>
<t>This document encourages the use of proxy methods to conserve network b
<t>This document encourages the use of proxy methods to conserve network ban andwidth and
dwidth and
power utilization by low-power devices. Such proxy methods in general ha ve security considerations that power utilization by low-power devices. Such proxy methods in general ha ve security considerations that
require the proxy to be trusted to not misbehave. One such proxy method require the proxy to be trusted to not misbehave. One such proxy method
listed is an Arp Sponge which listed is an ARP Sponge that listens for ARP requests, and, if it sees an ARP fo
listens for ARP requests, and, if it sees an ARP for an IP address that r an IP address that it believes is not used, it will reply
it believes is not used, it will reply with its own MAC address. ARP poisoning and false advertising could pote
with its own MAC address. ARP poisoning and false advertising could pote ntially undermine (e.g., DoS)
ntially undermine (e.g. DoS) this and other proxy approaches.</t>
this, and other, proxy approaches.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> This document does not request any IANA actions.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t> <t> This document has no IANA actions.</t>
This document has benefitted from discussions with the following
people, in alphabetical order:
Mikael Abrahamsson,
Bill Atwood,
Stuart Cheshire,
Donald Eastlake,
Toerless Eckert,
Jake Holland,
Joel Jaeggli,
Jan Komissar,
David Lamparter,
Morten Pedersen,
Pascal Thubert,
Jeffrey (Zhaohui) Zhang
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Informative References"> <references>
<!-- <?rfc include='reference.RFC.2119.xml'?> --> <name>Informative References</name>
<?rfc include='reference.I-D.ietf-6tisch-architecture.xml'?>
<?rfc include='reference.I-D.ietf-6lo-backbone-router.xml'?>
<?rfc include='reference.I-D.ietf-mboned-driad-amt-discovery.xml'?>
<?rfc include='reference.RFC.0826.xml'?>
<?rfc include='reference.RFC.5424.xml'?>
<?rfc include='reference.RFC.2131.xml'?>
<?rfc include='reference.RFC.4861.xml'?>
<?rfc include='reference.RFC.4286.xml'?>
<?rfc include='reference.RFC.4541.xml'?>
<?rfc include='reference.RFC.4601.xml'?>
<?rfc include='reference.RFC.7761.xml'?>
<?rfc include='reference.RFC.4862.xml'?>
<?rfc include='reference.RFC.5757.xml'?>
<?rfc include='reference.RFC.5796.xml'?>
<?rfc include='reference.RFC.6282.xml'?>
<?rfc include='reference.RFC.6762.xml'?>
<?rfc include='reference.RFC.6763.xml'?>
<?rfc include='reference.RFC.6775.xml'?>
<?rfc include='reference.RFC.6970.xml'?>
<?rfc include='reference.RFC.7450.xml'?>
<?rfc include='reference.RFC.8505.xml'?>
<?rfc include='reference.RFC.8415.xml'?>
<reference anchor="uli" target='https://mentor.ieee.org/802.15/dcn/15/15-1
5-0521-01-wng0-llc-proposal-for-802-15-4.pptx'>
<front>
<title>LLC Proposal for 802.15.4</title>
<author fullname="Pat Kinney">
<organization>"IEEE 802 Wireless"</organization>
<address>
</address>
</author>
<date month="Nov" year="2015"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</front> .0826.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2131.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4286.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4541.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4601.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4862.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5757.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5796.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6970.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7450.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8505.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8415.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8929.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.9030.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8777.xml"/>
<reference anchor="ietf_802-11" target='https://mentor.ieee.org/802.11/dcn <reference anchor="v2011" target="https://ieeexplore.ieee.org/document/571
/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for- 6530">
ietf-nov-2015.ppt'> <front>
<front> <title>Information technology -- Local and metropolitan area networks
<title>IEEE 802.11 multicast capabilities</title> -- Specific requirements -- Part 11: Wireless LAN Medium Access Control (MAC) an
d Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network
Management</title>
<author>
<organization>IEEE</organization>
</author>
<date month="February" year="2011"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5716530"/>
<seriesInfo name="IEEE Std" value="802.11v-2011"/>
</reference>
<!-- author fullname="Dorothy Stanley" initials="D" surname="Stanley" --> <reference anchor="IEEE802.1ak" target="https://www.ieee802.org/1/pages/80
<author fullname="Dorothy&nbsp;Stanley"> 2.1ak.html">
<organization>"IEEE 802 Wireless"</organization> <front>
<address> <title>Local and Metropolitan Area Networks Virtual Bridged Local Area
</address> Networks - Amendment 07: Multiple Registration Protocol</title>
</author> <author>
<organization>IEEE</organization>
</author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2007.380667"/>
<seriesInfo name="IEEE Std" value="802.1ak-2007 "/>
</reference>
<date month="Nov" year="2015"/> <reference anchor="uli" target="https://mentor.ieee.org/802.15/dcn/15/15-1
</front> 5-0521-01-wng0-llc-proposal-for-802-15-4.pptx">
<front>
<title>LLC Proposal for 802.15.4</title>
<author fullname="Pat Kinney" initials="P." surname="Kinney">
</author>
<date month="September" year="2015"/>
</front>
</reference> </reference>
<reference anchor="mc-ack-mux" target='https://mentor.ieee.org/802.11/dcn/ <reference anchor="ietf_802-11" target="https://mentor.ieee.org/802.11/dcn
15/11-15-0800-00-00ax-multiplexing-of-acknowledgements-for-multicast-transmissio /15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-
n.pptx'> ietf-nov-2015.ppt">
<front> <front>
<title>Multiplexing of Acknowledgements for Multicast <title>IEEE 802.11 multicast capabilities</title>
Transmission</title> <author fullname="Dorothy Stanley" initials="D." surname="Stanley"/>
<date month="November" year="2015"/>
<author fullname="Yusuke Tanaka"> </front>
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Eisuke Sakai">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Yuichi Morioka">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Masahito Mori">
<organization>"IEEE 802 Wireless, Sony Corp."</organization>
<address>
</address>
</author>
<author fullname="Guido Hiertz">
<organization>"IEEE 802 Wireless, Ericsson"</organization>
<address>
</address>
</author>
<author fullname="Sean Coffey">
<organization>"IEEE 802 Wireless, Realtek"</organization>
<address>
</address>
</author>
<date month="July" year="2015"/>
</front>
</reference> </reference>
<reference anchor="dot11" target="https://standards.ieee.org/standard/802_
<reference anchor="dot11" 11-2020.html">
target='http://standards.ieee.org/findstds/standard/802.11-2016.html'> <front>
<front> <title>Information Technology--Telecommunications and Information Exch
<title>802.11-2016 - IEEE Standard for Information technology--Telecomm ange between Systems - Local and Metropolitan Area Networks--Specific Requiremen
unications and information exchange between systems Local and metropolitan area ts - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (M Specifications (includes 802.11v amendment)</title>
AC) and Physical Layer (PHY) Specification (includes 802.11v amendment)</title> <author>
<organization>IEEE</organization>
<author surname="P802.11"> </author>
<organization>"IEEE 802 Wireless"</organization> <date month="December" year="2020"/>
</front>
<address> <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
</address> <seriesInfo name="IEEE Std" value="802.11-2020"/>
</author>
<date month="March" year="2016"/>
</front>
</reference> </reference>
<reference anchor="mc-props" target="https://mentor.ieee.org/802.11/dcn/15
<reference anchor="mc-props" target='https://mentor.ieee.org/802.11/dcn/15 /11-15-1161-02-0arc-802-11-multicast-properties.ppt">
/11-15-1161-02-0arc-802-11-multicast-properties.ppt'> <front>
<front> <title>IEEE 802.11 multicast properties</title>
<title>IEEE 802.11 multicast properties</title> <author fullname="Adrian Stephens">
<organization>Intel Corporation</organization>
<author fullname="Adrian Stephens"> </author>
<organization>"IEEE 802 Wireless"</organization> <date month="September" year="2015"/>
</front>
<address>
</address>
</author>
<date month="March" year="2015"/>
</front>
</reference> </reference>
<reference anchor="bridge-mc-2-uc" target="https://github.com/torvalds/lin
<reference anchor="bridge-mc-2-uc" target='https://github.com/torvalds/lin ux/commit/6db6f0e">
ux/commit/6db6f0eae6052b70885562e1733896647ec1d807'> <front>
<front> <title>bridge: multicast to unicast</title>
<title>bridge: multicast to unicast</title> <author/>
<date month="January" year="2017"/>
<author fullname="Felix Fietkau"> </front>
<organization>"Linux"</organization> <refcontent>commit 6db6f0e</refcontent>
<address>
</address>
</author>
<date month="Jan" year="2017"/>
</front>
</reference> </reference>
<reference anchor="arpsponge" target="http://citeseerx.ist.psu.edu/viewdoc
<reference anchor="arpsponge" /summary?doi=10.1.1.182.4692">
target='http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692'> <front>
<front> <title>Effects of IPv4 and IPv6 address resolution on AMS-IX and
<title>Effects of IPv4 and IPv6 address resolution on AMS-IX and
the ARP Sponge</title> the ARP Sponge</title>
<author fullname="Marco Wessel">
<author fullname="Marco Wessel"> <organization>"Universiteit van Amsterdam"</organization>
<organization>"Universiteit van Amsterdam"</organization> </author>
<author fullname="Niels Sijm">
<address> <organization>"Universiteit van Amsterdam"</organization>
</address> </author>
</author> <date month="July" year="2009"/>
</front>
<author fullname="Niels Sijm">
<organization>"Universiteit van Amsterdam"</organization>
<address>
</address>
</author>
<date month="July" year="2009"/>
</front>
</reference> </reference>
<reference anchor="dot11-proxyarp" target="https://mentor.ieee.org/802.11/
<reference anchor="dot11-proxyarp" target='https://mentor.ieee.org/802.11/ dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx">
dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx'> <front>
<front> <title>Proxy ARP in 802.11ax</title>
<title>Proxy ARP in 802.11ax</title> <author fullname="Guido R. Hiertz" initials="G." surname="Hiertz"/>
<author fullname="Filip Mestanov" initials="F." surname="Mestanov"/>
<author fullname="Guido R. Hiertz" initials="G. R." surname="Hiertz"> <author fullname="Brian Hart" initials="B." surname="Hart"/>
<organization>"IEEE 802 Wireless P802.11"</organization> <date month="September" year="2015"/>
</front>
<address>
</address>
</author>
<author fullname="Filip Mestanov" initials="F." surname="Mestanov">
<organization>"IEEE 802 Wireless P802.11"</organization>
<address>
</address>
</author>
<author fullname="Brian Hart" initials="B." surname="Hart">
<organization>"IEEE 802 Wireless P802.11"</organization>
<address>
</address>
</author>
<date month="September" year="2015"/>
</front>
</reference> </reference>
<reference anchor="dot11aa" target="https://standards.ieee.org/standard/80
<reference anchor="dot11aa" 2_11aa-2012.html">
target='https://standards.ieee.org/standard/802_11aa-2012.html'> <front>
<front> <title>Information technology--Telecommunications and information exch
<title>Part 11: Wireless LAN Medium Access Control (MAC) and ange between systems Local and metropolitan area networks--Specific requirements
Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Spec
for Robust Audio Video Streaming</title> ifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming</title
>
<author surname="P802.11"> <author>
<organization>"IEEE 802 Wireless"</organization> <organization>IEEE</organization></author>
<date month="March" year="2012"/>
<address> </front>
</address> <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6204193"/>
</author> <seriesInfo name="IEEE Std" value="802.11aa-2012"/>
<date month="March" year="2012"/>
</front>
</reference> </reference>
<reference anchor="mc-prob-stmt" target="https://www.iab.org/wp-content/IA
<reference anchor="mc-prob-stmt" target='https://www.iab.org/wp-content/IA B-uploads/2013/01/multicast-problem-statement.pptx">
B-uploads/2013/01/multicast-problem-statement.pptx'> <front>
<front> <title>Multicast on 802.11</title>
<title>Multicast on 802.11</title> <author fullname="Mikael Abrahamsson">
<organization>Deutsche Telekom</organization>
<author fullname="Mikael Abrahamsson"> </author>
<organization>"IAB, IEEE 802 Wireless"</organization> <author fullname="Adrian Stephens">
<organization>Intel Corporation</organization>
<address> </author>
</address> <date year="2013"/>
</author> </front>
<author fullname="Adrian Stephens">
<organization>"IAB, IEEE 802 Wireless"</organization>
<address>
</address>
</author>
<date month="March" year="2015"/>
</front>
</reference> </reference>
<reference anchor="Deri-2010" target="http://ripe61.ripe.net/presentations
<reference anchor="Deri-2010" /138-Deri_RIPE_61.pdf">
target="http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf"> <front>
<front> <title abbrev="Deri-2010">10 Gbit Hardware Packet Filtering Using
<title abbrev="Deri-2010">10 Gbit Hardware Packet Filtering Using
Commodity Network Adapters</title> Commodity Network Adapters</title>
<author fullname="Luca Deri" initials="L." surname="Deri">
<author fullname="Luca Deri" initials="L." surname="Deri"> <organization>NTOP</organization>
<organization>NTOP</organization> </author>
</author> <author fullname="Joseph Gasparakis" initials="J." surname="Gasparakis
">
<author fullname="Joseph Gasparakis" initials="J." <organization>Intel</organization>
surname="Gasparakis"> </author>
<organization>Intel</organization> <date month="November" year="2010"/>
</author> </front>
<refcontent>RIPE 61</refcontent>
<date year="2010" />
</front>
<seriesInfo name="RIPE" value="61" />
<format
target="http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf"
type="HTML" />
</reference> </reference>
<reference anchor="CAB" target="https://patchwork.kernel.org/patch/2687951
<reference anchor="CAB" /">
target="https://patchwork.kernel.org/patch/2687951/"> <front>
<front> <title>limit multicast buffer hardware queue depth</title>
<title abbrev="CAB">Limit multicast buffer hardware queue depth</title> <author/>
<author fullname="Felix Fietkau"> <date year="2013" month="June"/>
<organization>"openwrt.org"</organization> </front>
<refcontent>commit 2687951</refcontent>
<address> </reference>
</address> <reference anchor="group_key" target="https://superuser.com/questions/7302
</author> 88/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless
<date year="2013" /> ">
</front> <front>
</reference> <title>Subject: Why do some WiFi routers block multicast packets going
from wired to wireless?</title>
<reference anchor="group_key" target='https://superuser.com/questions/7302 <author />
88/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless <date month="January" year="2017"/>
'> </front>
<front> <refcontent>message to the Super User Q &amp; A community</refcontent>
<title>Why do some WiFi routers block multicast packets going from wire
d to wireless?</title>
<author fullname="Spiff">
<organization>"superuser.com"</organization>
<address>
</address>
</author>
<date month="Jan" year="2017"/>
</front>
</reference> </reference>
<reference anchor="Tramarin2017"> <reference anchor="Tramarin2017">
<front> <front>
<title> IEEE 802.11n for Distributed Measurement Systems</title> <title> IEEE 802.11n for Distributed Measurement Systems</title>
<author fullname="Federico Tramarin" initials="F." surname="Tramarin"> <author fullname="Federico Tramarin" initials="F." surname="Tramarin">
<organization> <organization>
National Research Council of Italy, CNR-IEIIT National Research Council of Italy, CNR-IEIIT
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Via Gradenigo 6/B, 35131 Padova, Italy Via Gradenigo 6/B, 35131 Padova, Italy
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<author fullname="Stefano Vitturi" initials="S." surname="Vitturi">
<author fullname="Stefano Vitturi" <organization>
initials="S." surname="Vitturi">
<organization>
National Research Council of Italy, CNR-IEIIT National Research Council of Italy, CNR-IEIIT
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Via Gradenigo 6/B, 35131 Padova, Italy Via Gradenigo 6/B, 35131 Padova, Italy
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<author fullname="Michele Luvisotto" initials="M." surname="Luvisotto"
<author fullname="Michele Luvisotto" >
initials="M." surname="Luvisotto"> <organization>
<organization>
Dept. of Information Engineering, University of Padova Dept. of Information Engineering, University of Padova
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Via Gradenigo 6/B, 35131 Padova, Italy Via Gradenigo 6/B, 35131 Padova, Italy
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<date month="May" year="2017"/> <date month="May" year="2017"/>
</front> </front>
<seriesInfo name="2017 IEEE International Instrumentation and <refcontent>2017 IEEE International Instrumentation and Measurement Tech
Measurement Technology Conference (I2MTC)" nology Conference (I2MTC), pp. 1-6</refcontent>
value="pp. 1-6"/> </reference>
</reference>
<!--
Antonio de la Oliva
Universidad Carlos III de Madrid,
Avda. Universidad, 30, 28911 Leganes, Spain
Pablo Serrano
Universidad Carlos III de Madrid,
Avda. Universidad, 30, 28911 Leganes, Spain
Pablo Salvador
Institute IMDEA Networks,
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
Albert Banchs
Institute IMDEA Networks,
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
Email:
{ aoliva,pablo } @it.uc3m.es
Email:
{ josepablo.salvador,albert.banchs } @imdea.org
@INPROCEEDINGS{6583394,
author={A. de la Oliva and P. Serrano and P. Salvador and A. Banchs},
booktitle={2013 IEEE 14th International Symposium on "A World of Wireless, Mobil
e and Multimedia Networks" (WoWMoM)},
title={Performance evaluation of the IEEE 802.11aa multicast mechanisms for vide
o streaming},
year={2013},
volume={},
number={},
pages={1-9},
keywords={multicast communication;performance evaluation;radio transmitters;
telecommunication traffic;video communication;video streaming;
wireless LAN;IEEE 802.11aa Task Group;IEEE 802.11aa multicast mechanism;
Internet traffic;group addressed frame handling;home environment;
multicast flow transmission;multimedia traffic;performance evaluation;
resource complexity;resource consumption;video streaming;video traffic;
video transmission;wireless LAN;wireless equipment;
IEEE 802.11 Standards;Multimedia communication;Receivers;Reliability;
Streaming media;Wireless LAN;802.11aa;Groupcast;WLAN},
doi={10.1109/WoWMoM.2013.6583394},
ISSN={},
month={June},}
-->
<reference anchor="Oliva2013"> <reference anchor="Oliva2013">
<front> <front>
<title> Performance evaluation of the IEEE 802.11aa multicast <title> Performance evaluation of the IEEE 802.11aa multicast
mechanisms for video streaming </title> mechanisms for video streaming </title>
<author fullname="Antonio de la Oliva" <author fullname="Antonio de la Oliva" initials="A." surname="de la Ol
initials="A." surname="de la Oliva"> iva">
<organization> <organization>
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Avda. Universidad, 30, 28911 Leganes, Spain Avda. Universidad, 30, 28911 Leganes, Spain
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<author fullname="Pablo Serrano" initials="P." surname="Serrano">
<author fullname="Pablo Serrano" initials="P." surname="Serrano"> <organization>
<organization>
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Avda. Universidad, 30, 28911 Leganes, Spain Avda. Universidad, 30, 28911 Leganes, Spain
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<author fullname="Pablo Salvador" initials="P." surname="Salvador">
<author fullname="Pablo Salvador" initials="P." surname="Salvador"> <organization>
<organization>
Institute IMDEA Networks, Institute IMDEA Networks,
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<author fullname="Albert Banchs" initials="A." surname="Banchs">
<author fullname="Albert Banchs" initials="A." surname="Banchs"> <organization>
<organization>
Institute IMDEA Networks, Institute IMDEA Networks,
</organization> </organization>
<address> <address>
<postal> <postal>
<street> <street>
Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain Avda. del Mar Mediterraneo, 22, 28911 Leganes, Spain
</street> </street>
</postal> </postal>
</address> </address>
</author> </author>
<date month="June" year="2013"/>
<date month="June" year="2013"/> </front>
</front> <seriesInfo name="DOI" value="10.1109/WoWMoM.2013.6583394"/>
<seriesInfo name='2013 IEEE 14th International Symposium on <refcontent>2013 IEEE 14th International Symposium on "A World of Wirele
"A World of Wireless, Mobile and Multimedia Networks" (WoWMoM)' ss, Mobile and Multimedia Networks" (WoWMoM), pp. 1-9 </refcontent>
value="pp. 1-9"/> </reference>
</reference>
<!--
<reference anchor="dot15mc">
<front>
<title>IEEE 802.15.4 and ZigBee as Enabling Technologies</title>
<author surname='Stefano Tennina et al.'>
<organization>
</organization>
<address>
<uri>https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem
-statement.pptx</uri>
</address>
</author>
<date month="March" year="2015"/>
</front>
</reference>
<author surname='Stefano Tennina, Anis Koubaa, Roberta Daidone,
Mario Alves, et al.'>
Koubaa had first 'a' with caret
Mario had 'a' with accent
-->
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
</back> <name>Acknowledgements</name>
<t>
This document has benefitted from discussions with the following
people, in alphabetical order:
<contact fullname="Mikael Abrahamsson"/>,
<contact fullname="Bill Atwood"/>,
<contact fullname="Stuart Cheshire"/>,
<contact fullname="Donald Eastlake 3rd"/>,
<contact fullname="Toerless Eckert"/>,
<contact fullname="Jake Holland"/>,
<contact fullname="Joel Jaeggli"/>,
<contact fullname="Jan Komissar"/>,
<contact fullname="David Lamparter"/>,
<contact fullname="Morten Pedersen"/>,
<contact fullname="Pascal Thubert"/>, and
<contact fullname="Jeffrey (Zhaohui) Zhang"/>.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 190 change blocks. 
1307 lines changed or deleted 1079 lines changed or added

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