One document matched: draft-thubert-savi-ra-throttler-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>

<rfc category="std" docName="draft-thubert-savi-ra-throttler-01" ipr="trust200902">
  <front>
    <title abbrev="ra-throttler">Throttling RAs on constrained interfaces</title>


    <author fullname="Pascal Thubert" initials="P" role="editor"
            surname="Thubert">
      <organization abbrev="Cisco Systems">Cisco Systems</organization>

      <address>
        <postal>
          <street>Village d'Entreprises Green Side</street>

          <street>400, Avenue de Roumanille</street>

          <street>Batiment T3</street>

          <city>Biot - Sophia Antipolis</city>

          <code>06410</code>

          <country>FRANCE</country>
        </postal>

        <phone>+33 497 23 26 34</phone>

        <email>pthubert@cisco.com</email>
      </address>
    </author>
    <date />

    <area>Internet Area</area>

    <workgroup>SAVI</workgroup>

    <keyword>Draft</keyword>

    <abstract>
    <t>	In a large switched topology with either many routers or routers that transmit
	a high rate of multicast advertisements per router, as suggested to support mobile
	nodes, the cost of distributing the many resulting multicast messages to certain 
	classes of devices might be prohibitive. This is the case of a device that runs on
	batteries, or a device that is reachable over a wireless interface. For this device,
	it can be beneficial to filter a certain amount of multicast messages such as the
	Router Advertisement while preserving the functionality expected in the IPv6 Neighbor
	Discovery Protocol. 
	</t>
    </abstract>

    <note title="Requirements Language">
      <t>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in 
   <xref target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
	
	<t>
	The protection of the network is not necessarily a security function 
	such as the	defense against a specific attack. It might also have to
	do with other activities that include the control of multicast storms,
	as provided to some extent by Multicast Listener Discovery (MLD) Snooping
	<xref target="RFC4541"/>, or of the overuse of the network that might 
	degrade the service for	all users as provided for instance by Call
	Admission Control <xref target="RFC5865"/>.</t>
	<t>
	In particular, the wireless edge of a large Layer 2 topology will require some special
	protections to conserve the limited bandwidth that is available over the radio medium, 
	such protections certainly involving the reduction of multicast operations. 
	</t>
	<t>	MLD Snooping helps control the impact of multicast messages but:
	<list>
	<t>It does not apply to the all-nodes link-scoped multicast address (FF02::1) as
	defined in the IP Version 6 Addressing Architecture <xref target="RFC4291"/>.
	</t>
	<t>MLD snooping is generally not implemented for link scope multicast messages anyway.
	</t>
	<t>If MLD snooping runs in instance as opposed to the Access Point (AP) and if there
	is at least	one listener associated to the AP then the AP will still get the multicast
	and transmit it to all the devices that are associated to the AP.
	</t>
	<t>MLD snooping has the granularity of a group as opposed to a binding table that has the
	granularity of a target - a host.
	</t>
	</list>
	</t>
	<t> This document focusses on the protection against an excessive bandwidth consumption
	by multicast IPv6 <xref target="RFC4861"> Neighbor Discovery (ND) </xref> Protocol
	(NDP) Router Advertisement (RA) messages over the wireless edge of a switched network.
	</t>
	<t>
	RA messages are link-scoped messages that provide the recipient node with link information
	such as availability and characteristics of routers that are present on the link and a
	list of prefixes that are usable for IPv6 NDP Stateless Address Autoconfiguration (SLAAC)
	<xref target="RFC4862"/>. 
	</t>
	<t>RA messages coming from different routers may carry different 
	information, including information about the router itself, but also different prefix lists 
	and other information such as the period of transmission <xref target="RFC6275"/>.
	</t>
	<t> In a number of cases, the fact that a node misses an RA does not impact the node operation
	in a notable fashion, either because the information is fully redundant with information that
	the node already has (e.g. multiple RAs of a same content from a same router in rapid sequence)
	or because the information is not critical to the node (e.g. yet another router that is not
	preferable as default gateway). In other cases, the loss of an RA is eventually recovered, 
	but the node will not operate optimally in the meantime and such a loss should be avoided.
	</t>
	<t>
	This document studies situations when an Ethernet Switch, an IEEE 802.11 Access Point, or 
	a Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller (AC) 
	<xref target="RFC5415"/> can, with no notable effect, make the decision not to copy an RA 
	message onto a port or a set of ports, typically one or more ports that connect to an 
	IEEE 802.11 wireless domain, the consequences of doing so and the eventual recovery. 
	In the remainder of this document, the term throttling will refer to the decision
	not to copy a message over such ports, and the layer 2 device in charge of making that 
	decision will simply be referred to as switch, whether it is a classical Ethernet switch
	or any one of the sorts of devices listed above.</t>
		
    </section>

    <section anchor="Terminology" title="Terminology">

	<t> The draft uses the following terminology:
	  <list style="hanging">
            <t hangText="Switch:"> A layer 2 device that distributes packets over one or more ports.
			This broad definition includes but is not limited to Ethernet and IEEE802.3 switches, 
			CAPWAP Access Controllers and IEEE 802.11 Access Points. 
			</t>
            <t hangText="Throttling:"> The decision not to copy a given multicast message 
			onto a given port or a set of ports	after the determination that the RA would be 
			redundant for most hosts across the port(s).
			A multicast packet that is throttled over a given port might still be copied
			for unicast delivery to selected hosts on a that port if it is determined that they will
			benefit from receiving the RA. The packet might still be passed on to other
			ports such as trunk ports, for further switching along a VLAN for instance. 
			</t>
            <t hangText="Throttled port:"> A port on the switch where throttling is active. The port 
			might be an access port that is directly connected to a host, but it might also be a 
			multipoint port, for instance if it is connected to another switch such as an Access Point. 
			</t>
	  </list>
	  </t>
    </section>

    <section title="Problem statement">
    <section title="Routers behavior">
	<t>	Assuming that the solicitor's source address is not the unspecified address, a router
	may	choose to respond to an ND Router solicitation (RS) with a unicast RA message directly
	to the soliciting host's address. But it is common that the router aggregates multiple
	requests and sends a single multicast response to the all-nodes group. 	This RA is received
	by all the nodes on link, though a host that did not issue an RS is	probably not very
	interested in receiving the solicited RA response message. Yet, in a wireless environment,
	a host will usually issue an RS each time it reassociates, which can be quite often if the 
	host is as mobile as a smartphone.
	</t>
	<t>	
	A traditional (wireline) router will typically not rate limit its RA emissions 
	based on consistent RA messages received from other routers, though
	such a behavior is required in the <xref target="I-D.ietf-roll-rpl"> Routing Protocol for 
	Low Power and Lossy Networks (RPL) </xref> that is specifically designed for constrained 
	environments such as wireless mesh networks. As a result, the number of RAs on a switched
	topology increase roughly linearly with the number of deployed routers.
	</t>
		
	<t>	
	As it goes, the whole RA operation denotes an implicit expectation that the cost for
	a multicast operation is not substantially different from that of a unicast transmission
	and that the cost is roughly similar on all segments of the link. 
	Sadly, this is not true in the case of a composite network with a switched Ethernet
	backbone and an IEEE 802.11 Extended Service Set (ESS) wireless edge. The situation is
	even worse if the edge is a mesh network, e.g. an IEEE 802.11S or a Low Power Lossy
	Network as described in <xref target="I-D.phinney-roll-rpl-industrial-applicability"/> and
	<xref target="I-D.thubert-lowpan-backbone-router"/>. In any case, a rate of RAs that might 
	appear acceptable on the backbone can rapidly become excessive on the wireless edge.
	</t>
	
    </section>
    <section title="Wireless Mobility domain">
	
	
	<t> A number of (layer 3) Network-Based Localized Mobility Management (NetLMM) 
	techniques have been deployed that enable IP mobility transparently to the host, that 
	is without requiring the active participation of the host in any mobility-related signaling.
	This is achieved by hiding its mobility to the host and more specifically by presenting 
	the host with a consistent link appearance as it roams at layer 3, in particular through
	tailored RA messages. An example of such NetLMM solutions would be the adaption of Proxy
	Mobile IPv6 (PMIPv6) <xref target="RFC5213"/> within a proprietary mobility framework. 
	</t>
	<t>	As a result, within a same radio environment (say an IEEE 802.11 Service Set Identification
	or SSID), some of the associated nodes may be local nodes and some other nodes may be roaming 
	devices	that are virtually part of some other link or VLAN in a remote location. 
	If all the associated nodes received a local RA announcing an local IPv6 prefix, roaming devices
	would detect their movement, form new addresses and defeat the mobility functionality to the 
	point that the entire mobility domain would appear as one flat single IPv6 link. </t>
	<t>
	To avoid that problem, a dedicated RA is unicast to each of the associated devices as 
	opposed to sent	once as a layer 2 broadcast to all devices in a single shot. A very common
	method consists in rewriting the link layer multicast address in a frame that carries 
	the layer 3 multicast message onto a layer 2 unicast address. This isolates	which L3 
	multicast packet gets to which host, and more importantly which multicast packet will not
	get to a given host for whih it is not destined.
    </t>
	<t> When a multicast packet is converted into multiple unicast frames by a siwtch such as
	an Access Point or an Access Controller, a single packet that is sent to the all-nodes group
	can consume a large amount of bandwidth that is roughly a factor of the number of associated
	devices, and disrupt sensitive applications such as voice over IEEE 802.11.  
	The NDP assumption that a multicast does not cost more than	a unicast is severely broken. 
	It results that the ND Protocol is not really suited for the wireless medium, and that some
	tailoring is required in instance	to reduce the impact of the multicast messages, in particular
	RA messages.
	</t>
	
    </section>
    </section>
    <section title="Operation">
	<t>	The NDP messages Router Advertisements are scoped to a link. They are sent on a given IPv6
	link (e.g. a Virtual Local Area Network) and should be delivered only to IPv6 nodes that reside
	on that link. An RA message can be transmitted over the medium either as unicast response or as
	a multicast message that is sent to the link-scoped all-nodes multicast address (FF02::1) as
	defined in <xref target="RFC4291"/>, which all IPv6 nodes on the link listen to.
	</t>
	<t> If a Router Advertisement is sent to a unicast destination address, instance MUST forward 
	the packet to the destination device. But as opposed to other ND Protocol operations such as the
	Duplicate Address Detection (DAD) that occurs only when a node obtains or forms a new address, 
	multicast RAs are sent periodically and might be quite frequent for the duration of the network
	activity. In that case, instance MAY drop the multicast RA if it is redundant. The question
	becomes to determine whether a multicast RA is redundant.
	</t>
	<t>A switch might connect ports of different natures. Some ports may need throttling of the RA 
	messages, and some node. It is expected that some mechanism is in place to determine which ports
	require throttling, for instance a configured policy or an automatic discovery.
	</t>
    <section title="Throttling scope and period">
	<t> The scope of a throttling activity is a link (a VLAN). Within that scope, some ports on
	instance are determined to be throttled, while others are not. A throttling period is 
	associated to that scope. A policy dictates how many and under which conditions multicast 
	RAs are throttled. The policy is based on counters that count RAs per router and counters 
	that aggregate the numbers to the throttling scope (the VLAN). The counters are reset at
	each throttling period.	
	</t>	
	<t>
	NDP does not mandate that routers on a link expose the same prefixes. It is possible that a 
	router advertises a prefix that none of the other routers does for instance. Or a router
	might advertise a better preference for a given destination <xref target="RFC4291"/>. It is
	this important that the throttling mechanism does not starve any given router. instance 
	SHOULD attempt to distribute fairly the amount of RAs per source router, and to serve at least
	once any given router on the link (VLAN) within a given period of time.
	</t>
    </section>
    <section title="Pending Hosts List">
	<t>
	A multicast RA that is the response to an RS is probably redundant for all nodes that did not
	solicit the RA in the first place. But it is certainly useful to nodes that issued an RS over 
	a throttled port since the last multicast RA happened. instance needs to keep track of all those
	hosts as discovered through their RS messages, in an abstract list referred to as the Pending 
	Hosts List (PHL). There is one PHL per link (that is, typically, per VLAN).
	</t>
	<t>
	A host is anchored to a port on instance, a link layer address, and eventually one or more
	VLAN identifier(s) depending on the deployment. An IPv6 Link Local Address 
	<xref target="RFC4291"/> might be available to qualify the host.
	A PHL entry SHOULD contain all the anchor parameter and MAY indicate additional information
	such as the host Link Local Address.
	</t>
	<t>
	instance SHOULD add a host to the PHL when it receives an RS from that host over a throttled port,
	and upon a layer 2 trigger that indicates that the port has flapped, typically an association
	or a reassociation event in an Access Point or an Accesss Controller. instance MAY remove a host
	from the PHL when a RA is forwarded to the host, either as a unicast, a multicast, or a unicast copy
	of a throttled multicast, and SHOULD remove the entry after a number or RAs are forwarded, depending
	on the policy that applies to the host.</t>
    </section>
    <section title="Advertising Routers List">
	<t>
	The primary cause of RA redundancies is a router that sends multiple identical RAs in a short
	sequence, for instance as stimulated by hosts joining the link. instance identifies 
	such redundancies by keeping track of all the routers as discovered through RA messages,
	and eventually of the content of those RA messages, in an abstract list referred to as the 
	Advertising Routers List (ARL). There is one ARL per link (VLAN).
	</t>
	<t>
	A router is anchored to a port on instance, a link layer address, and eventually one or more
	VLAN identifier(s) depending on the deployment. The router Link Local Address is found as the
	source address of the RA.
	A ARL entry SHOULD contain all the anchor parameters, the router Link Local Address, and a 
	number of counters that indicate the router activity over the last period and MAY contain
	additional information from the RA such as a prefix list or the router preferences 
	<xref target="RFC4191"/>. The entry MUST also contain counters that are necessary for the
	throttling operation, typically the number of multicast RAs that where copied and the 
	number that were throttled during the current throttling period.
	</t>
	<t>
	instance SHOULD add a router to the ARL when it receives an RA from that router on any port
	that belong to that link (VLAN). instance SHOULD remove the router from the ARL when the 
	throttle period elapses. instance MAY maintain a list of routers that were part of the ARL
	for the previous period in an alternate list to keep additional history and improve runtime
	performances.</t>
    </section>
    <section anchor="AIO" title="RA with an Advertisement Interval Option">
	<t> The Mobility Support in IPv6 (MIPv6) <xref target="RFC4191"/> section 7.3 introduces 
	the	Advertisement Interval Option (AIO), used in RA messages to advertise the interval at
	which the advertising router sends unsolicited multicast Router Advertisements. When this
	option is present, a switch SHOULD NOT interfere with a routers attempt to live up to its
	claim that at least one RA message will be posted every advertisement interval.
	</t>
	<t> There is more than one way for instance to comply with this requirement, as controlled
	by a policy that applies to the throttling operation:
	<list>
	<t>instance MAY never copy RAs from a given router that carry the AIO over throttled ports.</t>
	<t>Or instance MAY copy all RAs from a given router that carry the AIO over throttled ports.</t>
	<t>Alternatively, instance MAY monitor the timing of RA emissions from a given router
	and refrain from throttling at least one RA per advertisement interval from that router. 
	It might then happen that the router arms its timer on a message that instance throttles
	later. In that case, the next RA that is not throttled can be separated by substantially
	more time than one advertisement interval though less than 2 intervals. 
	This should not impact the MIPv6 operation that does not take action until no RA is received
	within two and a half advertisement intervals.
	</t>
	</list>
	It can be noted that the advertisement interval that is used to support mobility 
	can be very short and load the radio medium quite dramatically, depending on the available
	bandwidth on that medium. The policy in place SHOULD probably make it so that RAs with 
	too short intervals are not copied on throttled	ports unless no other option is available.
	If mobile devices are expected on the wireless link, then it might be preferred to block
	all routers advertising AIO but one or two that would preferably use an acceptable interval.
	</t>
    </section>
    <section title="Final RA">
	<t>Section 6.2.5 of the <xref target="RFC4861"> Neighbor Discovery specification </xref> 
	describe the router operation when it ceases to advertise on a given interface. In 
	particular, the router needs to transmit one or more final (multicast) RA messages on the
	interface with a Router Lifetime field of zero.
	</t>
	<t>This information is critical to any host that utilizes the router either as default 
	gateway or more preferred gateway for a given destination prefix since filtering out 
	a final RA might leave such host without connectivity till the host discovers that the
	router is gone. A switch SHOULD NOT take actions that would prevent such a host from
	receiving at least one final RA that indicates that a given router ceases to be a available 
	as a IPv6 gateway on the link (VLAN) where throttling applies.
	</t>
	<t> There is more than one way for instance to comply with that requirement, as controlled
	by a policy that applies to the throttling operation:
	<list>
	<t>instance MAY never throttle an RA with a Router Lifetime field set to zero. </t>
	<t>Alternatively, instance MAY throttle further multicast final RAs arrive immediately 
	after a first final RA from a same router.
	</t>
	</list>
	It can be noted that the advertisement interval that is used to support mobility 
	can be very short and load the system quite dramatically. The policy in place 
	should probably make it so that RAs with short intervals are not copied on throttled
	ports unless no other option is available.
	</t>
    </section>
    <section title="Throttling Policy">
	<t>An implementation SHOULD allow to configure a policy whereby the RA throttling operation
	is based on the history of received RAs during the current throttling period. </t>
	<t>	Suggested policy parameters per link (VLAN) include:
	<list style="hanging">
     <t hangText="throttle-period:">
	 This is the duration of the throttling period. A suggestion is to keep this value under
	 the highest MaxRtrAdvInterval used in the network. MaxRtrAdvInterval is defined in
	 <xref target="RFC4861"/> with a default of 600 seconds. The policy that provides that
	 parameter MAY apply to the link (VLAN) or instance.
	</t> 
     <t hangText="max-through:">
	 This is a maximum number of RAs that may pass before for all routers during a 
	 throttling period. rAdvInterval is defined in
	 <xref target="RFC4861"/> with a default of 600 seconds. The policy that provides that
	 parameter MAY apply to the link (VLAN) or instance. A suggested default is 1. 
	</t> 
     <t hangText="at-least:">
	 This is the minimum guaranteed number of RAs that pass before the first RA is throttled for 
	 a given router. The policy that provides that parameter MAY apply to an individual router,
	 a port, the link (VLAN) or instance. A suggested default is 1. This parameter takes
	 precedence over the max-through parameter that is defined at the link (VLAN) level so as
	 not to starve any router.
	</t> 
     <t hangText="at-most:">
	 This is a maximum number of RAs that may pass before for a given router during a 
	 throttling period. The policy that provides that parameter MAY apply to the router,
	 the port, the link (VLAN) or instance. A suggested default is 1.
	</t> 
     <t hangText="interval-option:">
	 This parameter indicates the behaviour upon RAs with the IAO as discussed in 
	 <xref target="AIO"/>. The policy that provides that parameter MAY apply to the router,
	 the port, the link (VLAN) or instance. A suggested default is never to copy RAs with
	 IAO on a throttled port.
	</t>	
	</list>
	</t>
    </section>
    </section>
 <!--
 

•	When a router leaves a network, the router attempts to transmit one or more final multicast Router Advertisements
 on the interface with a Router Lifetime field of zero. This message informs the nodes to cease using this router as 
 a default gateway for their flows. It is a rather rare occasion and filtering out this message might leave some nodes
 without connectivity till they discover that the router is gone. SISF will not discard final RAs.
 


 
•	In a number of cases, SISF forwards the Multicast Router Advertisement message as is in order to get it distributed
 to all nodes in the VLAN. The packet must be copied to all wireless nodes in the VLAN, setting the destination address
 in the layer-2 header to the specific node’s link-layer address and while leaving the layer-3 address left to the 
 ALL-NODES-MULTICAST address. This is handled by the Access Points at the time it distributes the multicast packet 
 to the nodes attached to it.

•	When an IPv6 node sends a Router Solicitation message, when attached to an access point on foreign controller, 
the message must be intercepted and tunneled to the foreign controller, which in turn must tunnel it to the home 
controller. SISF memorizes that the request was issued. If the response is a unicast RA, the RA is forwarded to the
 requester and the state is clearer. Upon the next multicast RA, SISF copies the RA only to those the node that 
 still have an RS pending.

•	A counter effective effect of throttling the multicast RAs is that a node that is missing a RA might not get
 one by chance and will have to actively request it. A wireless device may issue a Router Solicitation upon 
 association or re-association. Or It may wait for some time to get an RA that is either stimulated by another 
 node or unsolicited. Or the RS might be lost and the node must then wait a period of time before retrying. 
 SISF will mark any node that associates or re-associates as if it had issued an RS so the node get promiscuously 
 a copy of the next multicast RA. If en RS is received from that node right after, the state will just be left to 
 the value of a RS pending.

If it is verified in a closed environment that the IPv6 nodes always send a Router Solicitation message upon 
(re)association to an access point after a handoff, then the router advertisements may be suppressed all together
 at the source, by choosing high prefix and router lifetimes and by enabling suppress-ra mode on the router. 
 The response to a Router Solicitation message can be a unicast Router Advertisement message and no interception
 or replication is required for these messages. This is a matter of configuration of the routers and transparent
 to SISF.
 

  -->
  
    <section title="Manageability">
	<t>An implementation SHOULD allow the administrator to define one or more throttling policies and 
	to apply them on the relevant targets (routers, ports, links and switch). The implementation should
	count the number of RAs that passed and RAs that are throttled per target.
	</t>
    </section>
	
    <section anchor="IANA" title="IANA Considerations">
	<t>This specification does not require IANA action.</t>
	
        </section>
		
    <section anchor="Sec" title="Security Considerations">
	<t>This specification is not found to introduce new security threat.</t>
    </section>
    <section anchor="Acknowledgements" title="Acknowledgements">
	<t>The author wishes to thank Eric Levy-Abegnoli for his kind mentorship
	all along this project.
	</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.4861"?>
		<?rfc include="reference.RFC.4862"?>
		<?rfc include="reference.RFC.4291"?>
    </references>

    <references title="Informative References">
		<?rfc include="reference.RFC.4191"?>
		<?rfc include="reference.RFC.4541"?>
		<?rfc include="reference.RFC.5865"?>
		<?rfc include="reference.RFC.5213"?>
		<?rfc include="reference.RFC.5415"?>
		<?rfc include="reference.RFC.6275"?>
        <?rfc include='reference.I-D.ietf-roll-rpl.xml'?>
		<?rfc include='reference.I-D.thubert-lowpan-backbone-router.xml'?>
		<?rfc include='reference.I-D.phinney-roll-rpl-industrial-applicability.xml'?>
    </references>


  </back>
</rfc>