[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                     A. Yourtchenko
Internet-Draft                                                     cisco
Intended status: Informational                                L. Colitti
Expires: August 18, 2014                                          Google
                                                       February 14, 2014


             Reducing Multicast in IPv6 Neighbor Discovery
            draft-yourtchenko-colitti-nd-reduce-multicast-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 18, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Yourtchenko & Colitti    Expires August 18, 2014                [Page 1]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Impact of Multicast Packets in 802.11 Networks  . . . . . . .   3
   3.  Quantifying the use of Multicast in Neighbor Discovery  . . .   4
   4.  Multicast-limiting measures with no changes in specifications   4
     4.1.  On-device robust multicast filtering  . . . . . . . . . .   5
     4.2.  Unicast Solicited Router Advertisements . . . . . . . . .   5
     4.3.  Infrastructure-based multicast filtering  . . . . . . . .   5
     4.4.  Proxy the Neighbor Discovery protocol on the access point   6
     4.5.  Maximized Interval for Periodic RAs . . . . . . . . . . .   6
     4.6.  Increasing the advertised Reachable value . . . . . . . .   7
     4.7.  Clearing the on-link bit in the advertized prefixes . . .   7
     4.8.  Explicit creation of state with DHCPv6 address assignment   8
     4.9.  Client link shutdown within the router lifetime expiry  .   8
   5.  Multicast-limiting measures with small changes in
       specifications  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Remove the send-side limit on AdvDefaultLifetime of 9000
           Seconds . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Explicitly Client-Driven Router Advertisements  . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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.

   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.

   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.

   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.




Yourtchenko & Colitti    Expires August 18, 2014                [Page 2]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   This document presents two groups of measures which reduce the
   shortcoming:

   o  The measures which are possible without any changes to the
      existing standards.

   o  The measures which require minimal changes to the standards.

   Add some text here.  You will need to use these references somewhere
   within the text: [RFC4862] [RFC4861] [RFC6620] [RFC3315]

2.  Impact of Multicast Packets in 802.11 Networks

   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.

   1.  Multicast can impact power consumption on hosts if hosts receive
       multicast packets that are not addressed to them.

   2.  Excessive use of multicast can reduce the performance of wireless
       networks.

   3.  The extra packets are more expensive when they occur with the
       host not otherwise engaged in using the network.

   4.  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.

   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.

   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).

   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)



Yourtchenko & Colitti    Expires August 18, 2014                [Page 3]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   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.

   Increasing these values increases the latency for the multicast
   packets, therefore changing the DTIM interval beyond the defaults is
   usually not recommended.

3.  Quantifying the use of Multicast in Neighbor Discovery

   Normal operation of Neighbor Discovery uses the following multicast
   packets.

   1.  Duplicate Address Detection.
       Expected impact: One packet per IPv6 address (a host may be
       configured to do 2 or more) every time a host joins the network

   2.  Router Solicitations.
       Expected impact: One packet every time a host joins the network.

   3.  Router Advertisements.
       Expected impact:

       *  One multicast RAs every [RA interval] seconds

       *  One solicited RA per host joining the network (if solicited
          RAs are sent using multicast)

   4.  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..

   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.

4.  Multicast-limiting measures with no changes in specifications








Yourtchenko & Colitti    Expires August 18, 2014                [Page 4]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


4.1.  On-device robust multicast filtering

   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.

   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.

4.2.  Unicast Solicited Router Advertisements

   [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.

   To help address this, all router implementations SHOULD have a way to
   send solicited RAs unicast in the environments which wish to do so.

4.3.  Infrastructure-based multicast filtering

   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..

   The latter can be done in two ways:

   o  on the 802.11 level alone, preserving the destination within the
      inner Ethernet frame as multicast

   o  on the 802.11 and 802.3 levels, as clarified by the [RFC6085]

   Some networks track individual device IP addresses for security and
   tracking reasons, typically by snooping DAD packets or device traffic
   as described in [RFC6620]

   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.





Yourtchenko & Colitti    Expires August 18, 2014                [Page 5]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   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.

4.4.  Proxy the Neighbor Discovery protocol on the access point

   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).

   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).

   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.

4.5.  Maximized Interval for Periodic RAs

   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.

   The bounding factor is AdvDefaultLifetime, which is limited by the
   [RFC4861], section 6.1 on the sending side to 9000 seconds.

   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.

   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.





Yourtchenko & Colitti    Expires August 18, 2014                [Page 6]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


4.6.  Increasing the advertised Reachable value

   The NUD with the default settings and active traffic will enter the
   PROBE state as frequently as every ~30 seconds.  [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."

   Short-term connectivity issues at link layer may cause a trigger for
   the symptoms described in the [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.

   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.

   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.

4.7.  Clearing the on-link bit in the advertized prefixes

   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.

   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.

   The remaining impact of the link-local addresses still present in the
   cache can then be mitigated by blocking the direct communications



Yourtchenko & Colitti    Expires August 18, 2014                [Page 7]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   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.

4.8.  Explicit creation of state with DHCPv6 address assignment

   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.

   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.

   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.

4.9.  Client link shutdown within the router lifetime expiry

   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.

5.  Multicast-limiting measures with small changes in specifications

5.1.  Remove the send-side limit on AdvDefaultLifetime of 9000 Seconds

   [RFC4861], section 6.1 limits the AdvDefaultLifetime on the sending
   side to 9000 seconds, while explicitly requiring the receiving side




Yourtchenko & Colitti    Expires August 18, 2014                [Page 8]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   to process all the values up to 65535 (maximum allowed by 16-bit
   unsigned integer that the AdvDefaultLifetime is).

   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).

   This artificial restriction prevents from using very long router
   advertisement intervals that would otherwise be possible - with the
   difference being more than 7x!

   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.

5.2.  Explicitly Client-Driven Router Advertisements

   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.

   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.

6.  Acknowledgements

   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.







Yourtchenko & Colitti    Expires August 18, 2014                [Page 9]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


7.  IANA Considerations

   None.

8.  Security Considerations

   Not discussed in -00.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC6085]  Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
              "Address Mapping of IPv6 Multicast Packets on Ethernet",
              RFC 6085, January 2011.

   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses", RFC
              6620, May 2012.

   [RFC7048]  Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
              Detection Is Too Impatient", RFC 7048, January 2014.

Authors' Addresses

   Andrew Yourtchenko
   cisco
   7a de Kleetlaan
   Diegem, 1831
   Belgium

   Phone: +32 2 704 5494
   Email: ayourtch@cisco.com





Yourtchenko & Colitti    Expires August 18, 2014               [Page 10]


Internet-Draft        Reducing Multicast in IPv6 ND        February 2014


   Lorenzo Colitti
   Google

   Email: lorenzo@google.com















































Yourtchenko & Colitti    Expires August 18, 2014               [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/