< draft-ietf-mboned-ieee802-mcast-problems-14.txt   draft-ietf-mboned-ieee802-mcast-problems-15.txt >
Internet Area C. Perkins Internet Area C.E. Perkins
Internet-Draft Blue Meadow Networks Internet-Draft Blue Meadow Networks
Intended status: Informational M. McBride Intended status: Informational M. McBride
Expires: December 31, 2021 Futurewei Expires: 29 January 2022 Futurewei
D. Stanley D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
June 29, 2021 28 July 2021
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-14 draft-ietf-mboned-ieee802-mcast-problems-15
Abstract Abstract
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 (wifi) and other local-area wireless multicast in 802.11 (wifi) and other local-area wireless
environments. This document describes the known limitations of environments. This document describes the known limitations of
wireless (primarily 802.11) Layer-2 multicast. Also described are wireless (primarily 802.11) Layer-2 multicast. Also described are
certain multicast enhancement features that have been specified by certain multicast enhancement features that have been specified by
the IETF, and by IEEE 802, for wireless media, as well as some the IETF, and by IEEE 802, for wireless media, as well as some
operational choices that can be taken to improve the performance of operational choices that can be taken to improve the performance of
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2021. This Internet-Draft will expire on 29 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identified multicast issues . . . . . . . . . . . . . . . . . 5 3. Identified multicast issues . . . . . . . . . . . . . . . . . 5
3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5 3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5
3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5 3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5
3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6
3.1.3. Capacity and Impact on Interference . . . . . . . . . 7 3.1.3. Capacity and Impact on Interference . . . . . . . . . 7
skipping to change at page 3, line 7 skipping to change at page 3, line 6
4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15 4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15
5. Operational optimizations . . . . . . . . . . . . . . . . . . 16 5. Operational optimizations . . . . . . . . . . . . . . . . . . 16
5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16
5.2. Mitigating Spurious Service Discovery Messages . . . . . 18 5.2. Mitigating Spurious Service Discovery Messages . . . . . 18
6. Multicast Considerations for Other Wireless Media . . . . . . 18 6. Multicast Considerations for Other Wireless Media . . . . . . 18
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19
8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19 8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Informative References . . . . . . . . . . . . . . . . . . . 21
12.1. Informative References . . . . . . . . . . . . . . . . . 21
12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 [dot11] and other local-area wireless multicast in 802.11 [dot11] and other local-area wireless
environments, as described in [mc-props], [mc-prob-stmt]. environments, as described in [mc-props], [mc-prob-stmt].
Performance issues have been observed when multicast packet Performance issues have been observed when multicast packet
transmissions of IETF protocols are used over IEEE 802 wireless transmissions of IETF protocols are used over IEEE 802 wireless
media. Even though enhancements for multicast transmissions have media. Even though enhancements for multicast transmissions have
skipping to change at page 7, line 30 skipping to change at page 7, line 33
that every station has to be configured to wake up to receive the that every station has to be configured to wake up to receive the
multicast frame, even though the received packet may ultimately be multicast frame, even though the received packet may ultimately be
discarded. This process can have a large effect on the power discarded. This process can have a large effect on the power
consumption by the multicast receiver station. For this reason there consumption by the multicast receiver station. For this reason there
are workarounds, such as Directed Multicast Service (DMS) described are workarounds, such as Directed Multicast Service (DMS) described
in Section 4, to prevent unnecessarily waking up stations. in Section 4, to prevent unnecessarily waking up stations.
Multicast (and unicast) can work poorly with the power-save Multicast (and unicast) can work poorly with the power-save
mechanisms defined in IEEE 802.11e, for the following reasons. mechanisms defined in IEEE 802.11e, for the following reasons.
o Clients may be unable to stay in sleep mode due to multicast * Clients may be unable to stay in sleep mode due to multicast
control packets frequently waking them up. control packets frequently waking them up.
o A unicast packet is delayed until an STA wakes up and requests it. * A unicast packet is delayed until an STA wakes up and requests it.
Unicast traffic may also be delayed to improve power save, Unicast traffic may also be delayed to improve power save,
efficiency and increase probability of aggregation. efficiency and increase probability of aggregation.
o Multicast traffic is delayed in a wireless network if any of the * Multicast traffic is delayed in a wireless network if any of the
STAs in that network are power savers. All STAs associated to the STAs in that network are power savers. All STAs associated to the
AP have to be awake at a known time to receive multicast traffic. AP have to be awake at a known time to receive multicast traffic.
o Packets can also be discarded due to buffer limitations in the AP * Packets can also be discarded due to buffer limitations in the AP
and non-AP STA. and non-AP STA.
3.2. Issues at Layer 3 and Above 3.2. Issues at Layer 3 and Above
This section identifies some representative IETF protocols, and 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. Common uses when using multicast transmissions for control messages. Common uses
of multicast include: of multicast include:
o Control plane signaling * Control plane signaling
o Neighbor Discovery * Neighbor Discovery
o Address Resolution * Address Resolution
o Service Discovery * Service Discovery
o Applications (video delivery, stock data, etc.) * Applications (video delivery, stock data, etc.)
o On-demand routing * On-demand routing
o Backbone construction * Backbone construction
o Other L3 protocols (non-IP) * Other L3 protocols (non-IP)
User Datagram Protocol (UDP) is the most common transport layer User Datagram Protocol (UDP) is the most common transport layer
protocol for multicast applications. By itself, UDP is not reliable protocol for multicast applications. By itself, UDP is not reliable
-- messages may be lost or delivered out of order. -- messages may be lost or delivered out of order.
3.2.1. IPv4 issues 3.2.1. IPv4 issues
The following list contains some representative discovery protocols, The following list contains some representative discovery protocols,
which utilize broadcast/multicast, that are used with IPv4. which utilize broadcast/multicast, that are used with IPv4.
o ARP [RFC5424] * ARP [RFC0826]
o DHCP [RFC2131] * DHCP [RFC2131]
o mDNS [RFC6762] * mDNS [RFC6762]
o uPnP [RFC6970] * uPnP [RFC6970]
After initial configuration, ARP (described in more detail later), After initial configuration, ARP (described in more detail later),
DHCP and uPnP occur much less commonly, but service discovery can DHCP and uPnP occur much less commonly, but service discovery can
occur at any time. Some widely-deployed service discovery protocols occur at any time. Some widely-deployed service discovery protocols
(e.g., for finding a printer) utilize mDNS (i.e., multicast) which is (e.g., for finding a printer) utilize mDNS (i.e., multicast) which is
often dropped by operators. Even if multicast snooping [RFC4541] often dropped by operators. Even if multicast snooping [RFC4541]
(which provides the benefit of conserving bandwidth on those segments (which provides the benefit of conserving bandwidth on those segments
of the network where no node has expressed interest in receiving of the network where no node has expressed interest in receiving
packets addressed to the group address) is utilized, many devices can packets addressed to the group address) is utilized, many devices can
register at once and cause serious network degradation. register at once and cause serious network degradation.
3.2.2. IPv6 issues 3.2.2. IPv6 issues
IPv6 makes extensive use of multicast, including the following: IPv6 makes extensive use of multicast, including the following:
o DHCPv6 [RFC8415] * DHCPv6 [RFC8415]
o Protocol Independent Multicast (PIM) [RFC7761] * Protocol Independent Multicast (PIM) [RFC7761]
o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] * IPv6 Neighbor Discovery Protocol (NDP) [RFC4861]
o multicast DNS (mDNS) [RFC6762] * multicast DNS (mDNS) [RFC6762]
o Router Discovery [RFC4286] * Router Discovery [RFC4286]
IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate
Address Detection (DAD) and Address Lookup make use of Link-Scope Address Detection (DAD) and Address Lookup make use of Link-Scope
multicast. In contrast to IPv4, an IPv6 node will typically use multicast. In contrast to IPv4, an IPv6 node will typically use
multiple addresses, and may change them often for privacy reasons. multiple addresses, and may change them often for privacy reasons.
This intensifies the impact of multicast messages that are associated This intensifies the impact of multicast messages that are associated
to the mobility of a node. Router advertisement (RA) messages are to the mobility of a node. Router advertisement (RA) messages are
also periodically multicasted over the Link. also periodically multicasted over the Link.
Neighbors may be considered lost if several consecutive Neighbor Neighbors may be considered lost if several consecutive Neighbor
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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 Section 3. issues discussed in Section 3.
4.1. Proxy ARP in 802.11-2012 4.1. Proxy ARP in 802.11-2012
The AP knows the MAC address and IP address for all associated STAs. The AP knows the MAC address and IP address for all associated STAs.
In this way, the AP acts as the central "manager" for all the 802.11 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 implement STAs in its basic service set (BSS). Proxy ARP is easy to implement
at the AP, and offers the following advantages: at the AP, and offers the following advantages:
o Reduced broadcast traffic (transmitted at low MCS) on the wireless * Reduced broadcast traffic (transmitted at low MCS) on the wireless
medium medium
o STA benefits from extended power save in sleep mode, as ARP * STA benefits from extended power save in sleep mode, as ARP
requests for STA's IP address are handled instead by the AP. requests for STA's IP address are handled instead by the AP.
o ARP frames are kept off the wireless medium. * ARP frames are kept off the wireless medium.
o No changes are needed to STA implementation. * No changes are needed to STA implementation.
Here is the specification language as described in clause 10.23.13 of Here is the specification language as described in clause 10.23.13 of
[dot11-proxyarp]: [dot11-proxyarp]:
When the AP supports Proxy ARP "[...] the AP shall maintain a When the AP supports Proxy ARP "[...] the AP shall maintain a
Hardware Address to Internet Address mapping for each associated Hardware Address to Internet Address mapping for each associated
station, and shall update the mapping when the Internet Address of station, and shall update the mapping when the Internet Address of
the associated station changes. When the IPv4 address being the associated station changes. When the IPv4 address being
resolved in the ARP request packet is used by a non-AP STA resolved in the ARP request packet is used by a non-AP STA
currently associated to the BSS, the proxy ARP service shall currently associated to the BSS, the proxy ARP service shall
skipping to change at page 12, line 26 skipping to change at page 12, line 26
| | 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
Figure 1: Backbone Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
LLN nodes can move freely from an LLN anchored at one IPv6 Backbone 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 Router to an LLN anchored at another Backbone Router on the same
backbone, keeping any of the IPv6 addresses they have configured. backbone, keeping any of the IPv6 addresses they have configured.
The Backbone Routers maintain a Binding Table of their Registered The Backbone Routers maintain a Binding Table of their Registered
Nodes, which serves as a distributed database of all the LLN Nodes. Nodes, which serves as a distributed database of all the LLN Nodes.
An extension to the Neighbor Discovery Protocol is introduced to 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.
skipping to change at page 13, line 41 skipping to change at page 13, line 41
"When an IPv6 address is being resolved, the Proxy Neighbor "When an IPv6 address is being resolved, the Proxy Neighbor
Discovery service shall respond with a Neighbor Advertisement Discovery service shall respond with a Neighbor Advertisement
message [...] on behalf of an associated STA to an [ICMPv6] message [...] on behalf of an associated STA to an [ICMPv6]
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." Messages on behalf of a STA."
NDP may be used to request additional information NDP may be used to request additional information
o Maximum Transmission Unit * Maximum Transmission Unit
o Router Solicitation * Router Solicitation
o Router Advertisement, etc. * Router Advertisement, etc.
NDP messages are sent as group addressed (broadcast) frames in NDP messages are sent as group addressed (broadcast) frames in
802.11. Using the proxy operation helps to keep NDP messages off the 802.11. Using the proxy operation helps to keep NDP messages off the
wireless medium. wireless medium.
4.6. Using Unicast Instead of Multicast 4.6. Using Unicast Instead of Multicast
It is often possible to transmit multicast control and data messages It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually. by using unicast transmissions to each station individually.
skipping to change at page 14, line 51 skipping to change at page 14, line 51
4.6.3. Directed Multicast Service (DMS) 4.6.3. Directed Multicast Service (DMS)
There are situations where more is needed than simply converting There are situations where more is needed than simply converting
multicast to unicast. For these purposes, DMS enables an STA to multicast to unicast. For these purposes, DMS enables an STA to
request that the AP transmit multicast group addressed frames request that the AP transmit multicast group addressed frames
destined to the requesting STAs as individually addressed frames destined to the requesting STAs as individually addressed frames
[i.e., convert multicast to unicast]. Here are some characteristics [i.e., convert multicast to unicast]. Here are some characteristics
of DMS: of DMS:
o Requires 802.11n A-MSDUs * Requires 802.11n A-MSDUs
o Individually addressed frames are acknowledged and are buffered * Individually addressed frames are acknowledged and are buffered
for power save STAs for power save STAs
o The requesting STA may specify traffic characteristics for DMS * The requesting STA may specify traffic characteristics for DMS
traffic traffic
o DMS was defined in IEEE Std 802.11v-2011 * DMS was defined in IEEE Std 802.11v-2011
o DMS requires changes to both AP and STA implementation. * DMS requires changes to both AP and STA implementation.
DMS is not currently implemented in products. See [Tramarin2017] and DMS is not currently implemented in products. See [Tramarin2017] and
[Oliva2013] for more information. [Oliva2013] for more information.
4.6.4. Automatic Multicast Tunneling (AMT) 4.6.4. Automatic Multicast Tunneling (AMT)
AMT[RFC7450] provides a method to tunnel multicast IP packets inside AMT[RFC7450] provides a method to tunnel multicast IP packets inside
unicast IP packets over network links that only support unicast. unicast IP packets over network links that only support unicast.
When an operating system or application running on an STA has an AMT When an operating system or application running on an STA has an AMT
gateway capability integrated, it's possible to use unicast to gateway capability integrated, it's possible to use unicast to
traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi
portion of the network connected to the AP. portion of the network connected to the AP.
It is recommended that multicast-enabled networks deploying AMT It is recommended that multicast-enabled networks deploying AMT
relays for this purpose make the relays locally discoverable with the relays for this purpose make the relays locally discoverable with the
following methods, as described in following methods, as described in
[I-D.ietf-mboned-driad-amt-discovery]: [I-D.ietf-mboned-driad-amt-discovery]:
o DNS-SD [RFC6763] * DNS-SD [RFC6763]
o the well-known IP addresses from Section 7 of [RFC7450] * the well-known IP addresses from Section 7 of [RFC7450]
An AMT gateway that implements multiple standard discovery methods is An AMT gateway that implements multiple standard discovery methods is
more likely to discover the local multicast-capable network, instead more likely to discover the local multicast-capable network, instead
of forming a connection to a non-local AMT relay further upstream. of forming a connection to a non-local AMT relay further upstream.
4.7. GroupCast with Retries (GCR) 4.7. GroupCast with Retries (GCR)
GCR (defined in [dot11aa]) provides greater reliability by using GCR (defined in [dot11aa]) provides greater reliability by using
either unsolicited retries or a block acknowledgement mechanism. GCR either unsolicited retries or a block acknowledgement mechanism. GCR
increases probability of broadcast frame reception success, but still increases probability of broadcast frame reception success, but still
skipping to change at page 16, line 10 skipping to change at page 16, line 13
responses. responses.
GCR is suitable for all group sizes including medium to large groups. GCR is suitable for all group sizes including medium to large groups.
As the number of devices in the group increases, GCR can send block As the number of devices in the group increases, GCR can send block
acknowledgement requests to only a small subset of the group. GCR acknowledgement requests to only a small subset of the group. GCR
does require changes to both AP and STA implementations. does require changes to both AP and STA implementations.
GCR may introduce unacceptable latency. After sending a group of 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:
o unicast a Block Ack Request (BAR) to a subset of members. * unicast a Block Ack Request (BAR) to a subset of members.
o wait for the corresponding Block Ack (BA). * wait for the corresponding Block Ack (BA).
o retransmit any missed frames. * retransmit any missed frames.
o resume other operations that may have been delayed. * resume other operations that may have been delayed.
This latency may not be acceptable for some traffic. This latency may not be acceptable for some traffic.
There are ongoing extensions in 802.11 to improve GCR performance. There are ongoing extensions in 802.11 to improve GCR performance.
o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is * BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is
already specified in 802.11-REVmc 4.3). already specified in 802.11-REVmc 4.3).
o BA is sent using uplink MU-MIMO (which is a .11ax feature). * BA is sent using uplink MU-MIMO (which is a .11ax feature).
o Additional 802.11ax extensions are under consideration; see * Additional 802.11ax extensions are under consideration; see
[mc-ack-mux] [mc-ack-mux]
o Latency may also be reduced by simultaneously receiving BA * Latency may also be reduced by simultaneously receiving BA
information from multiple STAs. information from multiple STAs.
5. Operational optimizations 5. Operational optimizations
This section lists some operational optimizations that can be 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 Section 3. some of the issues discussed in Section 3.
5.1. Mitigating Problems from Spurious Neighbor Discovery 5.1. Mitigating Problems from Spurious Neighbor Discovery
skipping to change at page 19, line 8 skipping to change at page 19, line 5
result that many such functions are relegated to operation within result that many such functions are relegated to operation within
higher layer protocols. This leads to a patchwork of non- higher layer protocols. This leads to a patchwork of non-
interoperable and vendor-specific solutions. See [uli] for some interoperable and vendor-specific solutions. See [uli] for some
additional discussion, and a proposal for a task group to resolve additional discussion, and a proposal for a task group to resolve
similar issues, in which the multicast problems might be considered similar issues, in which the multicast problems might be considered
for mitigation. for mitigation.
Similar considerations hold for most other wireless media. A brief Similar considerations hold for most other wireless media. A brief
introduction is provided in [RFC5757] for the following: introduction is provided in [RFC5757] for the following:
o 802.16 WIMAX * 802.16 WIMAX
o 3GPP/3GPP2 * 3GPP/3GPP2
o DVB-H / DVB-IPDC * DVB-H / DVB-IPDC
o TV Broadcast and Satellite Networks * TV Broadcast and Satellite Networks
7. Recommendations 7. Recommendations
This section provides some recommendations about the usage and 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
Section 4 and Section 5. Section 4 and Section 5.
Future protocol documents utilizing multicast signaling should be Future protocol documents utilizing multicast signaling should be
carefully scrutinized if the protocol is likely to be used over carefully scrutinized if the protocol is likely to be used over
wireless media. wireless media.
skipping to change at page 19, line 36 skipping to change at page 19, line 33
of any needed multicast operations. of any needed multicast operations.
Multicast signaling for wireless devices should be done in a way Multicast signaling for wireless devices should be done in a way
compatible with low duty-cycle operation. compatible with low duty-cycle operation.
8. On-going Discussion Items 8. On-going Discussion Items
This section suggests two discussion items for further resolution. This section suggests two discussion items for further resolution.
First, standards (and private) organizations should develop First, standards (and private) organizations should develop
guidelines to help clarify when multicast packets should be sent guidelines to help clarify when multicast packets would be better
wired rather than wireless. For example, 802.1ak [1] works on both served by being sent wired rather than wireless. For example,
ethernet and Wi-Fi and organizations could help decision making by 802.1ak (https://www.ieee802.org/1/pages/802.1ak.html) works on both
developing guidelines for multicast over Wi-Fi including options for ethernet and Wi-Fi and organizations could help with deployment
when traffic should be sent wired. decision making by developing guidelines for multicast over Wi-Fi
including options for when traffic should be sent wired.
Second, reliable registration to Layer-2 multicast groups, and a Second, reliable registration to Layer-2 multicast groups, and a
reliable multicast operation at Layer-2, might provide a good reliable multicast operation at Layer-2, might provide a good
multicast over wifi solution. There shouldn't be a need to support multicast over wifi solution. There shouldn't be a need to support
2^24 groups to get solicited node multicast working: it is possible 2^24 groups to get solicited node multicast working: it is possible
to simply select a number of bits that make sense for a given network to simply select a number of bits that make sense for a given network
size to limit the number of unwanted deliveries to reasonable levels. size to limit the number of unwanted deliveries to reasonable levels.
IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2 IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2
multicast issues and provide workable solutions. multicast issues and provide workable solutions.
9. Security Considerations 9. Security Considerations
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 Multicast deployed on wired or wireless networks as discussed in this
document can be made more secure in a variety of ways. [RFC7761], document can be made more secure in a variety of ways. [RFC4601],
for instance, specifies the use of IPsec to ensure authentication of for instance, specifies the use of IPsec to ensure authentication of
the link-local messages in the Protocol Independent Multicast - the link-local messages in the Protocol Independent Multicast -
Sparse Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms Sparse Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms
to authenticate the PIM-SM link-local messages using the IP security to authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the (IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). Authentication Header (AH).
When using mechanisms that convert multicast traffic to unicast When using mechanisms that convert multicast traffic to unicast
traffic for traversing radio links, the AP (or other entity) is traffic for traversing radio links, the AP (or other entity) is
forced to explicitly track which subscribers care about certain forced to explicitly track which subscribers care about certain
skipping to change at page 21, line 13 skipping to change at page 21, line 13
This document does not request any IANA actions. This document does not request any IANA actions.
11. Acknowledgements 11. Acknowledgements
This document has benefitted from discussions with the following This document has benefitted from discussions with the following
people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,
Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel
Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal
Thubert, Jeffrey (Zhaohui) Zhang Thubert, Jeffrey (Zhaohui) Zhang
12. References 12. Informative References
12.1. Informative References
[arpsponge] [arpsponge]
Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address
resolution on AMS-IX and the ARP Sponge", July 2009, resolution on AMS-IX and the ARP Sponge", July 2009,
<http://citeseerx.ist.psu.edu/viewdoc/ <http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.182.4692>. summary?doi=10.1.1.182.4692>.
[bridge-mc-2-uc] [bridge-mc-2-uc]
Fietkau, F., "bridge: multicast to unicast", Jan 2017, Fietkau, F., "bridge: multicast to unicast", January 2017,
<https://github.com/torvalds/linux/ <https://github.com/torvalds/linux/
commit/6db6f0eae6052b70885562e1733896647ec1d807>. commit/6db6f0eae6052b70885562e1733896647ec1d807>.
[CAB] Fietkau, F., "Limit multicast buffer hardware queue [CAB] Fietkau, F., "Limit multicast buffer hardware queue
depth", 2013, depth", 2013,
<https://patchwork.kernel.org/patch/2687951/>. <https://patchwork.kernel.org/patch/2687951/>.
[Deri-2010] [Deri-2010]
Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet
Filtering Using Commodity Network Adapters", RIPE 61, Filtering Using Commodity Network Adapters", RIPE 61,
skipping to change at page 21, line 48 skipping to change at page 21, line 46
[dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for [dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for
Information technology--Telecommunications and information Information technology--Telecommunications and information
exchange between systems Local and metropolitan area exchange between systems Local and metropolitan area
networks--Specific requirements - Part 11: Wireless LAN networks--Specific requirements - Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Medium Access Control (MAC) and Physical Layer (PHY)
Specification (includes 802.11v amendment)", March 2016, Specification (includes 802.11v amendment)", March 2016,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.11-2016.html>. standard/802.11-2016.html>.
[dot11-proxyarp] [dot11-proxyarp]
Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in Hiertz, G. R., Mestanov, F., and B. Hart, "Proxy ARP in
802.11ax", September 2015, 802.11ax", September 2015,
<https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax- <https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-
proxy-arp-in-802-11ax.pptx>. proxy-arp-in-802-11ax.pptx>.
[dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access [dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications Control (MAC) and Physical Layer (PHY) Specifications
Amendment 2: MAC Enhancements for Robust Audio Video Amendment 2: MAC Enhancements for Robust Audio Video
Streaming", March 2012, Streaming", March 2012,
<https://standards.ieee.org/standard/802_11aa-2012.html>. <https://standards.ieee.org/standard/802_11aa-2012.html>.
[group_key] [group_key]
Spiff, "Why do some WiFi routers block multicast packets Spiff, "Why do some WiFi routers block multicast packets
going from wired to wireless?", Jan 2017, going from wired to wireless?", January 2017,
<https://superuser.com/questions/730288/why-do-some-wifi- <https://superuser.com/questions/730288/why-do-some-wifi-
routers-block-multicast-packets-going-from-wired-to- routers-block-multicast-packets-going-from-wired-to-
wireless>. wireless>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-20 (work Backbone Router", Work in Progress, Internet-Draft, draft-
in progress), March 2020. ietf-6lo-backbone-router-20, 23 March 2020,
<https://www.ietf.org/archive/id/draft-ietf-6lo-backbone-
router-20.txt>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the Time-
of IEEE 802.15.4", draft-ietf-6tisch-architecture-30 (work Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
in progress), November 2020. Work in Progress, Internet-Draft, draft-ietf-6tisch-
architecture-30, 26 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-6tisch-
architecture-30.txt>.
[I-D.ietf-mboned-driad-amt-discovery] [I-D.ietf-mboned-driad-amt-discovery]
Holland, J., "DNS Reverse IP Automatic Multicast Tunneling Holland, J., "DNS Reverse IP Automatic Multicast Tunneling
(AMT) Discovery", draft-ietf-mboned-driad-amt-discovery-13 (AMT) Discovery", Work in Progress, Internet-Draft, draft-
(work in progress), December 2019. ietf-mboned-driad-amt-discovery-13, 20 December 2019,
<https://www.ietf.org/archive/id/draft-ietf-mboned-driad-
amt-discovery-13.txt>.
[ietf_802-11] [ietf_802-11]
Stanley, D., "IEEE 802.11 multicast capabilities", Nov Stanley, D., "IEEE 802.11 multicast capabilities",
2015, <https://mentor.ieee.org/802.11/ November 2015, <https://mentor.ieee.org/802.11/
dcn/15/11-15-1261-03-0arc-multicast-performance- dcn/15/11-15-1261-03-0arc-multicast-performance-
optimization-features-overview-for-ietf-nov-2015.ppt>. optimization-features-overview-for-ietf-nov-2015.ppt>.
[mc-ack-mux] [mc-ack-mux]
Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G., Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G.,
and S. Coffey, "Multiplexing of Acknowledgements for and S. Coffey, "Multiplexing of Acknowledgements for
Multicast Transmission", July 2015, Multicast Transmission", July 2015,
<https://mentor.ieee.org/802.11/dcn/15/11-15-0800-00-00ax- <https://mentor.ieee.org/802.11/dcn/15/11-15-0800-00-00ax-
multiplexing-of-acknowledgements-for-multicast- multiplexing-of-acknowledgements-for-multicast-
transmission.pptx>. transmission.pptx>.
[mc-prob-stmt] [mc-prob-stmt]
Abrahamsson, M. and A. Stephens, "Multicast on 802.11", Abrahamsson, M. and A. Stephens, "Multicast on 802.11",
March 2015, <https://www.iab.org/wp-content/IAB- March 2015, <https://www.iab.org/wp-content/IAB-
uploads/2013/01/multicast-problem-statement.pptx>. uploads/2013/01/multicast-problem-statement.pptx>.
[mc-props] [mc-props] Stephens, A., "IEEE 802.11 multicast properties", March
Stephens, A., "IEEE 802.11 multicast properties", March
2015, <https://mentor.ieee.org/802.11/ 2015, <https://mentor.ieee.org/802.11/
dcn/15/11-15-1161-02-0arc-802-11-multicast- dcn/15/11-15-1161-02-0arc-802-11-multicast-
properties.ppt>. properties.ppt>.
[Oliva2013] [Oliva2013]
de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs,
"Performance evaluation of the IEEE 802.11aa multicast "Performance evaluation of the IEEE 802.11aa multicast
mechanisms for video streaming", 2013 IEEE 14th mechanisms for video streaming", 2013 IEEE 14th
International Symposium on "A World of Wireless, Mobile International Symposium on "A World of Wireless, Mobile
and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013. and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013.
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, DOI 10.17487/RFC4286, December 2005, RFC 4286, DOI 10.17487/RFC4286, December 2005,
<https://www.rfc-editor.org/info/rfc4286>. <https://www.rfc-editor.org/info/rfc4286>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<https://www.rfc-editor.org/info/rfc4601>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at page 25, line 17 skipping to change at page 25, line 29
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[Tramarin2017] [Tramarin2017]
Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n
for Distributed Measurement Systems", 2017 IEEE for Distributed Measurement Systems", 2017 IEEE
International Instrumentation and Measurement Technology International Instrumentation and Measurement Technology
Conference (I2MTC) pp. 1-6, May 2017. Conference (I2MTC) pp. 1-6, May 2017.
[uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015, [uli] Kinney, P., "LLC Proposal for 802.15.4", November 2015,
<https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0- <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-
llc-proposal-for-802-15-4.pptx>. llc-proposal-for-802-15-4.pptx>.
12.2. URIs
[1] https://www.ieee802.org/1/pages/802.1ak.html
Authors' Addresses Authors' Addresses
Charles E. Perkins Charles E. Perkins
Blue Meadow Networks Blue Meadow Networks
Phone: +1-408-330-4586 Phone: +1-408-330-4586
Email: charliep@computer.org Email: charliep@computer.org
Mike McBride Mike McBride
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95055 Santa Clara, CA 95055
USA United States of America
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Dorothy Stanley Dorothy Stanley
Hewlett Packard Enterprise Hewlett Packard Enterprise
2000 North Naperville Rd. 2000 North Naperville Rd.
Naperville, IL 60566 Naperville, IL 60566
USA United States of America
Phone: +1 630 979 1572 Phone: +1 630 979 1572
Email: dstanley1389@gmail.com Email: dstanley1389@gmail.com
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: warren@kumari.net Email: warren@kumari.net
Juan Carlos Zuniga Juan Carlos Zuniga
SIGFOX SIGFOX
425 rue Jean Rostand 425 rue Jean Rostand
Labege 31670 31670 Labege
France France
Email: j.c.zuniga@ieee.org Email: j.c.zuniga@ieee.org
 End of changes. 49 change blocks. 
100 lines changed or deleted 110 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/