One document matched: draft-yourtchenko-colitti-nd-reduce-multicast-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6620 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC6085 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6085.xml">
<!ENTITY RFC7048 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7048.xml">
<!--
This does not compile...
<!ENTITY I-D.vyncke-6man-mcast-not-efficient-01 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vyncke-6man-mcast-not-efficient-01.xml">
-->
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="2"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?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 compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-yourtchenko-colitti-nd-reduce-multicast-00" ipr="trust200902">
<front>
<title abbrev="Reducing Multicast in IPv6 ND">Reducing Multicast in IPv6 Neighbor Discovery</title>
<author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
<organization>cisco</organization>
<address>
<postal>
<street>7a de Kleetlaan</street>
<city>Diegem</city>
<region>1831</region>
<!-- <code/> -->
<country>Belgium</country>
</postal>
<phone>+32 2 704 5494</phone>
<!-- <facsimile/> -->
<email>ayourtch@cisco.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Lorenzo Colitti" initials="L" surname="Colitti">
<organization>Google</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>lorenzo@google.com</email>
<!-- <uri/> -->
</address>
</author>
<date year="2014" />
<!-- <area/> -->
<!-- <workgroup/> -->
<keyword>nd, ipv6</keyword>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>
IPv6 Neighbor Discovery protocol makes wide use of multicast traffic, which makes it not energy efficient for the mobile WiFi hosts. This document describes two classes of possible ways to reduce the multicast traffic within IPv6 ND. First, within the boundaries of existing protocols. Second - with what the authors deem to be "minor changes" to the existing protocols. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<!--
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
<xref target="RFC2119"/>.
</t>
-->
<t>
Wireless networks based on the IEEE 802.11 standard (WiFi) are ubiquitous
in today's life. The multicast/broadcast behavior in these networks has
significantly lower performance than unicast in the majority of the cases.
</t>
<t>
Also, in the current standard and implementations of the 802.11 protocols
from the link-layer media standpoint the multicast is the same as broadcast.
</t>
<t>
The Neighbor Discovery protocol makes substantial use of multicast packets
on the assumption that they provide the same or better efficiency compared
to unicast packets.
</t>
<t>
This misalignment results that the nodes on IPv6 networks with the default
configuration perform significantly poorer both from the battery life standpoint
and the bandwidth efficiency standpoint.
</t>
<t>
This document presents two groups of measures which reduce the shortcoming:
<list style="symbols">
<t>
The measures which are possible without any changes to the existing standards.
</t>
<t>
The measures which require minimal changes to the standards.
</t>
</list>
</t>
<t>
Add some text here. You will need to use these references somewhere within the text:
<xref target="RFC4862"/>
<xref target="RFC4861"/>
<xref target="RFC6620"/>
<xref target="RFC3315"/>
<!-- <xref target="I-D.vyncke-6man-mcast-not-efficient-01"/> -->
</t>
</section>
<section title="Impact of Multicast Packets in 802.11 Networks">
<t>
NOTE: much if not all of the subsequent text in this section might need to be transferred to vyncke-6man-mcast-not-efficient-01, which discusses
why multicast is not an efficient media in the WiFi environments.
</t>
<t>
<list style="numbers">
<t>
Multicast can impact power consumption on hosts if hosts receive multicast packets that are not addressed to them.
</t>
<t>
Excessive use of multicast can reduce the performance of wireless networks.
</t>
<t>
The extra packets are more expensive when they occur with the host not otherwise engaged in using the network.
</t>
<t>
Mobile nodes often have more than one processor and multiple power management states both for the central processing unit and for the WiFi portion (e.g. using only one antenna out of multiple). Often, the battery impact of rejecting a packet in the radio firmware is substantially lower than the impact of passing the packet to the main processor and rejecting it there.
</t>
</list>
</t>
<t>
In 802.11 networks, multicast frames towards clients have a greater
battery impact than the unicast frames because they are transmitted to all hosts at once, with
the AP setting the DTIM bit on the beacon packet to signal
to the dozing hosts that the transmission is about to begin.
</t>
<t>
Thus, if the host were not to wake up right there and then,
it would miss the multicast frame. Unicast packets are buffered
on the AP and may have a more lenient delivery schedule,
which would allow the devices to not have to wake up
at every beacon interval (100ms).
</t>
<t>
The tradeoff between the energy savings and the latency of
the multicast delivery may be manipulated by changing the parameter
called DTIM interval, which determines how often (every Nth beacon)
the AP can send the indication about the multicast
traffic to the clients - with the default values
being fairly low, usually in the range of one to three.
</t>
<t>
Increasing these values increases the latency
for the multicast packets, therefore changing the DTIM
interval beyond the defaults is usually not recommended.
</t>
</section>
<section title="Quantifying the use of Multicast in Neighbor Discovery">
<t>
Normal operation of Neighbor Discovery uses the following multicast packets.
<list style="numbers">
<t>
Duplicate Address Detection.
<vspace/>
Expected impact: One packet per IPv6 address (a host may be configured to do 2 or more) every time a host joins the network
</t>
<t>
Router Solicitations.
<vspace/>
Expected impact: One packet every time a host joins the network.
</t>
<t>
Router Advertisements.
<vspace/>
Expected impact:
<list style="symbols">
<t>
One multicast RAs every [RA interval] seconds
</t>
<t>
One solicited RA per host joining the network (if solicited RAs are sent using multicast)
</t>
</list>
</t>
<t>
Neighbor solicitations.
Expected impact: One every time a host talks to a new on-link destination talked to. The response is cached and typically does not expire unless the ND cache is under pressure and subject to garbage collection. Cache entries are refreshed (and possibly deleted) using unicast NUD packets, so cache refreshes do not cause multicast packets to be sent..
</t>
</list>
With the exception of periodic RAs (and possibly solicited RAs), none of these packets are addressed to all nodes. RS packets are addressed to all routers, and NS packets are addressed to solicited-node multicast groups. Because solicited-node multicast groups contain the last 24 bits of the IPv6 address, in most networks, each solicited-node group will have at most one member.
</t>
</section>
<section title="Multicast-limiting measures with no changes in specifications">
<section title="On-device robust multicast filtering">
<t>
The hosts may implement on-device multicast filtering,
such that if devices receive multicast packets that are
not addressed to them, they will not send the packets to
the main CPU but instead remain in a lower sleep state.
</t>
<t>
It is worth noting that this may require a less deep sleep state than
the one required to monitor the TIM in the beacon frames. Also,
filtering the packets on the device does not address the inefficiency in
spectrum utilisation caused by excessive multicast frames.
</t>
</section>
<section title="Unicast Solicited Router Advertisements">
<t>
<xref target="RFC4861"/> in section 6.2.6 already allows to do so via a MAY verb (if the
solicitation's source address is not the unspecified address).
This is further weakened by the subsequent qualifier being
"but the usual case is to multicast the response to the all-nodes group."
As a result of this, a lot of implementations do multicast the solicited RAs,
significantly impacting the devices.
</t>
<t>
To help address this, all router implementations SHOULD have a way to send solicited RAs unicast in
the environments which wish to do so.
</t>
</section>
<section title="Infrastructure-based multicast filtering">
<t>
Ensure that solicited-node multicasts only go to the specific nodes.
This can be implemented either using multicast snooping or by converting
multicast packets to unicast packets that are addressed to a subset of the hosts..
</t>
<t>
The latter can be done in two ways:
<list style="symbols">
<t>
on the 802.11 level alone, preserving the destination within the inner Ethernet frame as multicast
</t>
<t>
on the 802.11 and 802.3 levels, as clarified by the <xref target="RFC6085"/>
</t>
</list>
</t>
<t>
Some networks track individual device IP addresses for security and tracking reasons,
typically by snooping DAD packets or device traffic as described in <xref target="RFC6620"/>
</t>
<t>
In these networks, the infrastructure is already aware of which IP addresses are mapped
to which MAC addresses, and can use this information to selectively unicast neighbor
solicitations to the nodes that will be interested in them.
</t>
<t>
Most wireless networks are infrastructure-based. The 802.11 standard defines that
all communications in such networks will happen via the access points.
Therefore, the infrastructure has a chance to intelligently
filter any multicast packets that are coming from both local (served by the same access point)
and remote (located behind the wired infrastructure) hosts or routers,
before forwarding them onto the air to their ultimate destination.
</t>
</section>
<section title="Proxy the Neighbor Discovery protocol on the access point">
<t>
802.11 standard defines also that all of packets sent from the client to the Access Point
(either for the local over-the-air delivery or for forwarding on to the wired side)
are acknowledged (even the multicast ones).
</t>
<t>
With this in mind, in the scenarios like DAD, a proxy ND implementation
has inherently a much better chance of working than the "regular" forwarding
of the multicast DAD NS (and the return forwarding of the multicast DAD NA
in case of DAD collision that was detected).
</t>
<t>
Therefore, the environments which want to increase the robustness of the DAD,
may wish to proxy the ND on behalf of the clients, therefore reducing
the overall client-directed multicast traffic (which is unacknowledged)
and increasing the robustness against the poor radio conditions.
</t>
</section>
<section title="Maximized Interval for Periodic RAs">
<t>
Assuming the solicited RAs are sent unicast, increasing the interval
of the periodic RAs is a natural way of further reducing the amount of multicast packets in the air.
</t>
<t>
The bounding factor is AdvDefaultLifetime, which is limited by the <xref target="RFC4861"/>, section 6.1 on the sending side to 9000 seconds.
</t>
<t>
Thus, to find the "right" value one will have to balance the robustness in the face of higher packet loss on the segment with the energy
consumption by the endpoints. Some real-world mid-scale networks (on the order of 10000 hosts within a single /64)
successfully used a value of one RA in 1800 seconds.
</t>
<t>
However, it is impossible to specify the "best" value - everything will depend on
the quality of the local WiFi installation and the radio conditions, with the constraint
of 9000 seconds currently specified by the standard.
</t>
</section>
<section title="Increasing the advertised Reachable value">
<t>
The NUD with the default settings and active traffic will enter the PROBE state as frequently as every ~30 seconds.
<xref target="RFC4861"/> section 7.3.3 defines: "If no response is
received after waiting RetransTimer milliseconds after sending the
MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the
entry SHOULD be deleted. Subsequent traffic to that neighbor will
recreate the entry and perform address resolution again."
</t>
<t>
Short-term connectivity issues at link layer may cause a trigger for the symptoms described in the <xref target="RFC7048"/>,
therefore triggering the nodes to send multicast neighbor solicitations. However, most of the hosts do not implement
at this time the changes suggested there. With the default short timeouts and a wireless
environment which forwards multicasts without the filtering, these retransmissions may contribute to further possible failures of NUD in other hosts.
In the extreme high density and mobility environments (conferences, stadiums) this may result in avalanche effect and
significantly increase the portion of multicast traffic.
</t>
<t>
Furthermore, an 802.11 segment usually has a single gateway (possibly in a FHRP redundant configuration), therefore making NUD
not very useful at all: if that gateway does not function, there is no alternative.
</t>
<t>
For these kinds of environments it may be useful to significantly increase the REACHABLE_TIME from 30000 milliseconds to 600000
seconds and higher. One possible concern here, however, may be the overflow of the ND table on the gateway, so, again, there is
no "best" value suitable for all the networks.
</t>
</section>
<section title="Clearing the on-link bit in the advertized prefixes">
<t>
The mobile nodes have generally fairly limited memory, so in the environments where there are thousands of nodes on a single /64,
it might be burdensome for them to manage a large neghbor table. Having a lot of hosts with large neighbor tables may mean also
a lot of NUD maintenance activity, with the potential for the catastrophic failure of the NUD therefore increasing
in the high-density environments.
</t>
<t>
Clearing the on-link bit in the advertised prefixes causes the hosts to send all the
traffic to each other via the default gateway - thus dramatically reducing the size
of the neighbor table and the burden of its maintenance on the hosts.
</t>
<t>
The remaining impact of the link-local addresses still present in the cache can
then be mitigated by blocking the direct communications between the hosts at L2,
which is a standard feature in the wireless LAN equipment. This operation effectively
turns a wireless LAN segment into a collection of point-to-point links between the hosts
and the access point, not dissimilar to the operation of private VLANs in the wired LAN case -
making the subnet effectively NBMA.
</t>
</section>
<section title="Explicit creation of state with DHCPv6 address assignment">
<t>
Turning the WLAN subnet into an NBMA has a consequence that the DAD may no longer work - which may create a problem with the global addresses.
Therefore, it may be necessary to transfer the control over the address assignment to a centralized entity.
</t>
<t>
Also, the 802.11 protocols operate in the unlicensed bands, which means that the radio conditions may vary greatly.
The 802.11 LLC protocol itself does have a fairly robust L2 retransmission mechanism for the acknowledged packets (up to 64 retransmissions).
However, there still may be times when the radio conditions are so poor that this robustness is not enough.
If the network were to use the snooping to maintain the strict policies (e.g. restrict the source addresses of the traffic),
merely snooping the ND may not work, and the data-driven recovery mechanisms might be unacceptable.
</t>
<t>
In these cases one may consider using DHCPv6 as an address assignment mechanism, which would provide
the explicit management of state by the client, and the retransmissions required to create the necessary
state on the network side without requiring the node to send the data.
</t>
</section>
<section title="Client link shutdown within the router lifetime expiry">
<t>
Some nodes after a longer period of time may decide to completely shut down the radio. This will of course result
in the best battery usage, but will incur a tradeoff that waking up the client from the network side will be impossible.
However, this mode of operation is the only one not using DHCPv6 which may allow complete avoidance of multicast RA packets:
if the client never stays awake for longer than the router lifetime, it will not require the multicast RA processing.
This optimization is here for completeness of the discussion - since it changes the connectivity of the client.
</t>
</section>
</section>
<section title="Multicast-limiting measures with small changes in specifications">
<section title="Remove the send-side limit on AdvDefaultLifetime of 9000 Seconds">
<t>
<xref target="RFC4861"/>, section 6.1 limits the AdvDefaultLifetime on the sending side to 9000 seconds, while explicitly
requiring the receiving side to process all the values up to 65535 (maximum allowed by 16-bit unsigned integer
that the AdvDefaultLifetime is).
</t>
<t>
This artificial limit means a hard limit on the maximum router lifetime that can be specified in the configuration.
(The authors tried two router implementations: Cisco IOS and radvd. More information welcome).
</t>
<t>
This artificial restriction prevents from using very long router advertisement
intervals that would otherwise be possible - with the difference being more than 7x!
</t>
<t>
Additionally, allowing the router lifetime of 65535 seconds, coupled with sufficiently long lifetimes for the
prefix, would cover the vast majority of the lifetimes of the devices on the WiFi networks. 65535 seconds is 18.2 hours,
and the typical mobile devices might not even stay on the same network for such a long period of time. This would allow
to increase the robustness of the network in the face of bad radio conditions causing the high loss of the multicast RAs.
</t>
</section>
<section title="Explicitly Client-Driven Router Advertisements">
<t>
We can logically extend the "client link shutdown" in the direction of smaller connectivity loss,
and imagine that the client, instead of completely shutting the radio down, would flap its radio
link somewhere close to router lifetime expiry, therefore, while acting fully within the standards it will be
able to maintain the connectivity during all but very short period of time, without any use of periodic RAs.
</t>
<t>
It may be interesting to explore a modification of the client behavior such that the "flap time" converges to zero,
and eventually allowing the client to initiate a unicast Router Solicitation some time shortly before the router lifetime
expires. This will have the result of the client being able to maintain the connectivity without the need of processing
any periodic RAs. The advantage of doing so is that the RS-RA exchange will happen at the time convenient for the client
sleep schedule - thus allowing to maximize the battery life.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Thanks to the following people for the very useful discussions. In no particular order:
Erik Nordmark, Pascal Thubert, Eric Levy-Abegnoli, Ole Troan, Eric Vyncke,
Federico Lovison, Jerome Henry.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
None.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Not discussed in -00.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4862;
&RFC4861;
&RFC6620;
&RFC3315;
&RFC6085;
&RFC7048;
</references>
<!--
<references title="Informative References">
&I-D.vyncke-6man-mcast-not-efficient-01;
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:41:55 |