draft-ietf-lwig-nbr-mgmt-policy.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC6345 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6345.xml">
<!ENTITY RFC6775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC5191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?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="4"?>
<!-- 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 list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-lwig-nbr-mgmt-policy-latest" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="Neighbor Management Policy for 6LoWPAN">Neighbor Management Policy for 6LoWPAN</title>

    <author fullname="Rahul Arvind Jadhav" initials="R.A." role="editor" surname="Jadhav">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Kundalahalli Village, Whitefield,</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560037</code>
          <country>India</country>
        </postal>
        <phone>+91-080-49160700</phone>
        <email>rahul.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Rabi Narayan Sahoo" initials="R.N." surname="Sahoo">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Kundalahalli Village, Whitefield, </street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560037</code>
          <country>India</country>
        </postal>
        <phone>+91-080-49160700</phone>
        <email>rabinarayans@huawei.com</email>
      </address>
    </author>
    <author initials="S" surname="Duquennoy" fullname="Simon Duquennoy">
      <organization>Inria</organization>
      <address>
        <postal>
          <street>40 Avenue Halley</street>
          <street>Building A</street>
          <city>Villeneuve d'Ascq</city>
          <country>France</country>
        </postal>
        <phone>+33 768227731</phone>
        <email>simon.duquennoy@inria.fr</email>
      </address>
    </author>
    <author fullname="Joakim Eriksson" initials="J.E." surname="Eriksson">
      <organization>Yanzi Networks</organization>
      <address>
      <!--
        <postal>
          <street></street>
          <city>TODO</city>
          <region></region>
          <code></code>
          <country>TODO</country>
        </postal>
      -->
        <phone></phone>
        <email>joakime@sics.se</email>
      </address>
    </author>

    <date year="2018" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>LWIG</workgroup>

    <keyword>LWIG, 6lo, RPL, PANA, PRE, PAC, PAA, NCE, neighbor cache management</keyword>

    <abstract>
      <t>
        <!--
          This document describes the problems associated with neighbor cache
          management in constrained multihop networks and a sample neighbor
          management policy to deal with it.
          -->
          This document describes the problems associated with neighbor cache
          management in multihop networks involving resource-constrained
          devices.  Thereafter, it also presents a sample neighbor management
          policy that allows efficient cache management in multihop LLNs
          (low-power and lossy networks such as LoWPAN) with
          resource-constrained devices.
      </t>
    </abstract>
  </front>

<middle>
	<section title="Introduction">
		<t>
            In a wireless multihop LLN, the node densities (maximum nodes
            reachable on the same hop) may vary significantly depending upon
            deployments and scenarios. Examples of such networks is LoWPAN
            [REF] networks. While there is some policy control possible with
            regards to the network size in terms of maximum number of devices
            connected, it is especially difficult to set a figure on what will
            be the maximum node density given a deployment.  For e.g. A network
            can put an upper limit on max 1000 devices but it is impossible to
            state what the node density will be in this 1000 node network.
        </t>

        <t>
            A neighbor cache is used for populating neighboring one-hop
            connected nodes information such as MAC address, link local IP
            address and other reachability state information. Node density has
            direct implications on the neighbor cache and in constrained
            network scenario the size of the neighbor cache will be limited.
            Thus there are chances that a node may not be able to fit all the
            neighboring nodes in its cache in which case it has to prioritize
            entries and thus needs a neighbor management policy.
        </t>

        <t>
            This draft presents problems related to neighbor management
            policies by considering a security-enabled multi-hop 6lo network.
            This document considers RPL <xref target="RFC6550"/> as a routing
            protocol and PANA (EAP-PANA) <xref target="RFC5191"/> as a network
            access protocol. For RPL, both the storing and non-storing mode of
            operations are considered. We also provide a sample neighbor
            management policy which can be used in such networks and its
            limitations. The aim of such a policy is to retain set of neighbor
            cache entries with high quality links such that routing adjacencies
            are stablized.
        </t>

		<t>
            The problem statement and the proposed solution described is also
            relevant to other multihop constrained scenarios such as 6TiSCH
            <xref target="I-D.ietf-6tisch-architecture"/>. <xref
            target="I-D.ietf-6tisch-minimal-security"/> talks about a pledge
            (new joinee) node authenticating via a Join Proxy. The
            considerations mentioned in this document are applicable for such
            networks as well.
        </t>

		<t> <figure align="center" anchor="sample_top" title="Sample Topology">
		<artwork align="center"><![CDATA[
                    +--------+
                    | PAA/   |
             +------| Auth   |
             |      | Server |
             |      +--------+
+------------|-------------+
|            |             |
|          (BR)            |
|          / \             |
|         /   \            |
|        /     \           |
|      (N1)   (N2)         |
|      / :     / \         |
|     /   :   /   \        |
|    /     : /     \       |
|  (N8)    (N3)   (N4)     |
|    :     / \     :       |
|     :   /   \   :        |
|      : /     \ :         |
|      (N5)   (New)        |
|      / \                 |
|     /   \                |
|    /     \               |
|  (N6)   (N7)             |
|                          |
|        6Lo Network       |
+--------------------------+
            ]]></artwork> </figure> </t>

        <section title="Requirements Language and Terminology">
			<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">RFC 2119</xref>.</t>

            <t> NDP: Neighbor Discovery protocol [REF] </t>

            <t> NS: Neighbor Solicitation </t>

            <t> NA: Neighbor Advertisement </t>

            <t> LLN: Low Power and Lossy Networks </t>

            <t> RPL: Routing Protocol for LLNs [REF] </t>

            <t> DAO: DODAG Advertisement Object </t>

            <t> DIO: DODAG Information Object </t>

            <t> ARO: Address Registration Option defined as part of IPv6 NDP</t>

			<t>
                PaC (PANA Client): New joining node which is yet to be
                authenticated.
            </t>

			<t>
                PRE (PANA Relay Element): An already authenticated and network
                joined node which is willing to act as a relay element for PaCs
                to complete their authentication procedure on multi-hop
                networks. <xref target="RFC6345"/> describes the details of
                PRE.
            </t>

			<t>
                PAA (PANA Auth Agent): Auth server which hosts the credentials
                database. PaC will handshake with PAA to complete
                authentication procedure.
            </t>

            <t> PCI: PANA Client Initiation is the first message sent by the
                PaC which initiates the authentication procedure </t>

			<t>
                Routing Child: A downstream node who is part of the routing
                table of the parent. For e.g. in the sample topology above N5
                is the directly connected routing child for N3.  N6 and N7 are
                also part of N3 routing table, they are routing child nodes but
                not directly connected. For N6 and N7 the document might
                alternatively use a term grand-child.
            </t>

            <t>Routing Parent: In <xref target="sample_top"/>, N1 and N2 are
            possible routing parents for N3.</t>

			<t>Neighbor Cache Entry (NCE): A neighbor entry managed on behalf
			of directly connected peer.</t>

			<t>This document also uses terminology described in <xref
			target="RFC6550"/> and <xref target="RFC6775"/>.</t>
        </section>

    </section>

    <section anchor="nbr_mgmt" title="Neighbor Management">
        <section title="Significance of Neighbor management policy">
			<t>
                Multihop mesh networks present unique challenges to neighbor
                management especially with resource constrained nodes. In cases
                where the node density is higher that the neighbor cache size,
                the entries have to be prioritized. <xref target="Woo_et_al"/>
                and <xref target="Dawans_et_al"/> talk about prioritization of
                neighbor entries by using link quality estimation techniques.
                But prioritization alone may not necessarily be optimal in all
                cases.  The reason or function why neighbor entry was added
                also needs to be taken in consideration. For example, evicting
                a routing direct child might have a ripple effect in turn
                impacting all the sub-childs as well.
            </t>

			<t>
                In case of key management protocols deployed above MAC layer in
                multihop network, the neighbor management kicks in early even
                before the routing adjacencies are established. Since a new
                joining node needs to discover/attach to a relay element for
                completing its authentication procedure, the neighbor cache
                entries have to be appropriately populated both on a PaC and on
                the PRE. If a neighbor entry whose authentication is in
                progress is evicted, it will negatively impact the
                authentication procedure.
            </t>

			<t>Another important consideration is that with increased node
            density, the prioritization based on link estimation parameters
            might not help since there might be more well connected
            peers. In dense deployments the number of directly attached
            neighbors with good quality links might still be higher than the
            max entries in neighbor cache size.</t>
		</section>
		<section title="Trivial neighbor management policies">
			<t>This section investigates policies which are used by most of the
			current operating systems for constrained nodes. While such
			policies are trivial to implement they may not be able to deal with
            the constrained network scenario. Note that such policies can still
            be used if it is known apriori that the neighbor cache can hold
            entries for maximum node density.</t>

			<t><list style="letters">
			<t>First Come First Serve (FCFS) policy</t>
			<t>Least Recently Used (LRU) policy</t> </list>
			The primary distinction between these policies is how it treats a
			new entry when the neighbor cache is full. In case of FCFS policy,
            the new entry is simply rejected while with LRU, the new entry
            replaces the least recently used entry.</t>

			<t>RPL works by initiating a downstream multicast DIO to establish
			upstream network path. Subsequently DAO messages might be sent by
			the nodes to establish downstream paths to the nodes. Thus the
			network is flooded with multicast DIO messages initially and
			similarly there are chances that the same node is ended up been
			selected as a preferred parent by most of the child nodes and thus
			receives a DAO message from all these child nodes. Note that once a
			node establishes a parent entry or a routing entry on behalf of a
			directly connected node then it has to also provision a neighbor
			cache entry for it for subsequent unicast traffic.  </t>

			<t> In case of FCFS policy, a node might end up hosting all the
			neighbor entries based on DIO or DAO messages.  Once the cache is
			full all the subsequent attempts to add an NCE will fail.</t>

			<t> In case of LRU policy, a node might end up churning lot of
			neighbor entries because once the cache gets full and there is
			a request for new entry, it would result in evicting the least
			recently used (but active) entry.  If at later point of time,
			there is a traffic for the evicted entry then the old entry has
			to be reinstated using IPv6 NDP procedure. This would mean
			reinstating the entry by evicting another least recently used
			entry. If the node density is very high, then this churn would
			be substantially high to extent that it would disrupt any
			routing adjacencies to be established in the network in a
			stable way. </t>
		</section>

		<section title="Lifecycle of a NCE">
			<section title="NCE Insertion">
				<t>
				IPv6 NDP <xref target="RFC6775"/> defines signaling involved in
				resolving the IPv6 addresses to its corresponding MAC addresses
                which gets populated in the neighbor cache. In case of
                constrained network, it is desired that such control traffic is
                minimized and thus the neighbor cache entries are populated as
                part of existing messaging. One example would be when the node
                receives a DAO message from its immediate child node, it not
                only makes an addition to the routing table but also creates a
                neighbor cache entry for the node. Thus it eliminates need for
                additional IPv6 NDP NS/NA messaging involved to resolve MAC
                address. Similar hueristic is used to add neighbor entries
                in other cases as well. Section 10.3.2 of <xref
                target="RFC6775"/> describes update and addition of such
                NCEs based on roting information packets.</t>

				<t>Following are the possible signaling scenarios in which case
				a neighbor entry may get added.</t>

				<t>Node Joining procedure: A new joinee node discovers a relay
				element to initiate its auth procedure. At the end of the
				discovery phase the new joinee node would have known the link
				local IP address of the relay element. The joinee node will
				send an unsecured-NS to the relay element to solicit its NA.
				The PRE may send a NA with the suitable status code as
				defined in section 6.5.3 of <xref target="RFC6775" />.</t>

				<t> <figure align="center" anchor="auth_callflow" title="NCE
				creation between PaC and PRE during relay discovery process">
                <artwork align="center"><![CDATA[
                                 RPL
       PaC           PRE         Parent        PAA
        |             |            |            |
        |  PRE Disc   |            |            |
        |<----------->|            |            |
        |             |            |            |
        |   UNSEC-NS  |            |            |
        |------------>|            |            |
        |             |            |            |
        |   addNCE(new,reason=PANA)|            |
        |             |            |            |
        | UNSEC-NA(status)         |            |
        |<------------|            |            |
        |             |            |            |
addNCE(PRE,reason=PANA)            |            |
        |             |            |            |
        |    PCI      |            |            |
        |------------>|            |            |
        |             |            |            |
        |             |  AUTHPROC  |            |
        |<===========>|<=======================>|
        |             |            |            |
                ]]></artwork> </figure> </t>

				<t> Relay element does not hold any state information on behalf
				of the new joinee node except for its neighbor cache entry.
				Thus in the <xref target="sample_top"/> the new joinee node may
				select node N3 as its PRE, in which case N3 has to add a
				neighbor entry on behalf of the new joinee node.  </t>

				<t> Post authentication the node enters into network discovery
				phase. The node selects one or more of its neighboring peer as
				its preferred parent based on the DIO received from these
				peers. Note that the node's selected relay element and its
				preferred parent may not be same. The preferred parent serves
				as a default router node to which all its upstream traffic is
				directed. Thus an NCE on behalf of preferred parent needs to be
				added. In <xref target="sample_top" /> node N5 selects N3 as
				its preferred parent. N5 needs to add neighbor entry on behalf
				of N3 which is its directly connected RPL preferred parent.
				</t>

				<t>In case of RPL storing MOP (mode of operation), the node may
				send a DAO message containing its reachability information to
				its preferred parent. The parent node in turn may pass this
				information upstream to its parent by generating a DAO
				retaining the child node's reachability information,
				establishing a downstream routing path towards the node who
				originated the DAO.
				The preferred parent has to maintain a neighbor entry on behalf
				of the directly connected child node. For example, in the <xref
				target="sample_top"/>, node N3 needs to maintain a neighbor
				entry on behalf of N5 which is its directly connected child
				node. Nodes N6 and N7 are grand-child nodes for node N3 for
				whom no neighbor entry is required.</t>

				<t> As mentioned in Section 10.3.2 of <xref target="RFC6775"/>,
				the NCEs on parent and child can be added directly as a result
				of RPL DIO/DAO signalling without any explicit NS/NA
				messaging.</t>

				<t> <figure align="center" anchor="s_callflow" title="NCE
				creation call Flow for RPL storing MOP"> <artwork
				align="center"><![CDATA[
                                 RPL
       PaC           PRE         Parent        PAA
        |             |            |            |
        |             |  AuthProc  |            |
        |<----------->|<----------------------->|
        |             |            |            |
        |             |  RPL-DIO   |            |
        |<-------------------------|            |
        |             |            |            |
addNCE(parent,reason=PARENT)       |            |
        |             |            |            |
        |             |  RPL-DAO   |            |
        |------------------------->|            |
        |             |            |            |
        |             |   addNCE(new,reason=CHILD)
        |             |            |            |
                ]]></artwork> </figure></t>

				<t> In case of non-storing MOP, the parent node needs to know
				the global IPv6 address of the immediate child nodes.  This is
				needed since the source routing header carries the global
				addresses and thus the NCE of the child node should contain the
				global address.
				Secondly, the RPL DAO is addressed directly to the root node in
				case of non-storing mode. Thus RPL messaging cannot be used for
				creating NCE entries on parent and child, unlike storing MOP.
				The child node may send a secure unicast NS with ARO option
				containing its global address to be registered on the parent
				node. The child node can still use RPL DIO to create an NCE on
				behalf of the parent node.</t>

				<t><figure align="center" anchor="ns_callflow" title="NCE
				creation call Flow for non-storing MOP"> <artwork
				align="center"><![CDATA[
                                 RPL
       PaC           PRE         Parent        Root
        |             |            |            |
        |             |  AuthProc  |            |
        |<----------->|<----------------------->|
        |             |            |            |
        |             |  RPL-DIO   |            |
        |<-------------------------|            |
        |             |            |            |
addNCE(parent,reason=PARENT)       |            |
        |             |            |            |
        | sec-NS(ARO=GlobalIPv6)   |            |
        |------------------------->|            |
        |             |            |            |
        |             |       addNCE(new,reason=CHILD)
        |         sec-NA(status)   |            |
        |<-------------------------|            |
        |             |            |            |
        |             |  RPL-DAO   |            |
        |-------------------------------------->|
        |             |            |            |
                ]]></artwork> </figure> </t>

				<t> This document expects the neighbor management policy to
				remember the reason why the neighbor entry is inserted.
				Secondly, the router may remember whether the NS received was
				secured or unsecured and accordingly use it to prioritize
				eviction entries. As described in the next sections, this
				reason will help the policy to prioritize the entries in case
				an eviction is required.  </t>
            </section>

            <section anchor="nce_deletion" title="NCE Deletion">
				<t>It is imperative that an unwanted neighbor entry be removed
				as soon as possible. This section talks about different cases
				in which neighbor entry can be deleted.  </t>

				<t> Route Invalidation: In case of storing MOP, when the child
				node decides to switch its preferred parent, the RPL
				specifications allows the node to send a no-path DAO message to
				invalidate the route along the previous path(s). A directly
				connected parent node can use this message to clear the NCE.

				While the entry can be immediately cleared, usually the
				implementations choose to wait a small amount of time before
				clearing the entry.  This is to avoid any impact on the
				in-transit traffic. Thus this also establishes the importance
				of route invalidation to achieve optimized neighbor cache
				utilization. </t>

                <t>In case of non-storing mode, the no-path DAO cannot be not
                employed since the previous parent does not having any routing
                information to be invalidated. But the previous parent may
                still contain the NCE on behalf of the child node. This
                document recommends use of <xref target="RFC6775"/> section
                6.5.3. which allows sending a zero lifetime ARO option in NS
                for deregistering the corresponding neighbor entry.</t>

				<t> <xref target="RFC6775"/>, ND optimizations for 6LoWPANs,
				section 5.5.3. talks about deleting the entries in case the NUD
				(neighbor unreachability detection) fails either due to no
				response to NS messages or due to failure response. NCEs in
				such cases should be deleted. An example where NUD NS would
				fail because of no response is the case where the child node
				switches its parent due to link unavailability. The parent in
				such a case would not receive the no-path DAO message or any
				other traffic from the child node. Thus on NCE lifetime expiry,
				the parent node would send NS which would fail with no
				response, thus triggering entry deletion.  </t>
            </section>

            <section anchor="nce_eviction" title="NCE Eviction">
				<t> The eviction rules have a major impact on the neighbor
				management policy. Eviction rules are used when the policy has
				to forcibly remove an active neighbor entry from the cache to
				make space for the new (hopefully higher priority) entry. The
				eviction policy may take into account several considerations
				such as the reason why the entry was made, is the entry in
				active use currently, how good (for e.g., based on link
				estimation) the entry currently is.  </t>

				<section anchor="dc_eviction" title="Eviction for directly connected routing entries">
					<t> This section talks about implications of an eviction in
					which a parent node decides of evicting a directly
					connected routing child NCE. In the sample topology <xref
					target="sample_top"/>, lets assume N3 needs to evict N5
					from its neighbor cache. In case of RPL's storing MOP,
					eviction of directly connected routing child NCE also has
					impact on all the sub-children. Thus not only will it result
					in impacting N5 but also nodes N6 and N7. It is important
					to note that such an eviction has less impact on RPL's
					non-storing MOP i.e. in case of non-storing mode N5 might
					end up selecting alternate parent N8 and does not result in
					any additional control overhead for node N6 and N7.  </t>

					<t> Thus RPL's non-storing MOP provides additional eviction
					flexibility for a neighbor management policy in terms
					evicting directly connected child entries.  </t>
				</section>
			</section>

            <section title="NCE Reinforcement">
				<t> It is expected that the latest reachability state and
				metric information be maintained in context to the NCE.  With
				wireless networks, the neighbor cache entries prioritization
				may change over a period of time especially the link quality
				estimation parameters or the routing metrics.  Reinforcement
				refers to updating the parameters in context to the NCEs which
				helps in prioritizing the entries when it comes to handling
				eviction. In wireless networks, on reception of incoming
				packet, the receiver node's physical and MAC layer may derive
				certain signal reception parameters (such as RSSI, LQI) which
				can be considered for reinforcement purpose if the
				corresponding transmitter/source entry in neighbor cache is
				found. It should be noted that the signal quality parameters
				may have high variance in 6lo networks and thus statistical
				techniques (such as weighted averaging) are usually employed
				for deciding about a link quality over a period of time.
				Reinforcement can be achieved using one or more of the
				following techniques:
                <list style="hanging">
					<t hangText="Passive Monitoring:">Reinforcing the quality
					parameters using packets received from the source. Trickled
					DIO, periodic beacons, application traffic etc can be used
					for such monitoring.</t>

					<t hangText="Active Probing:">A node may select subset of
					entries for active probing wherein it sends a message to
					the neighbor entry's target and can expect a response
					message back. An example of such probing is <xref
					target="CONTIKI"/> where unicast DIS is sent to solicit a
					unicast DIO without impacting the trickle timers. Though it
					adds a control overhead on the link, periodic probing can
					help to ascertain connectivity in the absence of any other
					traffic from the neighboring node.</t>
                </list>
                </t>
                <!-- SD: To what extent do we want to define probing? Do we only recommend, with one practical example? Or do we want to mandate? -->
				<!-- RJ: Mandating i guess is not an option because there are so many probing options. We ll leave it at this and see if we recv any specific comment on this part -->
            </section>
        </section>

        <section title="Requirements of a good neighbor management policy">
            <t>
                <list style="hanging">
                    <t hangText="Route Stability:">
                        Stable NCEs will result in stable routing adjacencies.
                        Thus it is important to avoid unnecessary NCE churn for
                        routing path stability.
                    </t>

                    <t hangText="Control overhead:">
                        A neighbor management policy may have to use signalling
                        messages for policy handling (such as rejection of
                        NCE). It is required that such overhead be kept as low
                        as possible.
                    </t>

                    <t hangText="Scalability:">
                        Scalability with respect to large and uneven node
                        densities in the network.
                    </t>
                </list>
            </t>
        </section>

        <section title="Approaches to neighbor management policy">
        <!-- SD: I like the idea to address both proactive and reactive. For proactive, do we plan to advertise the space left in NCE as a DIO metric or similar? -->
        <!-- RJ: Turns out that without advertising there may be a problem i.e. policy wont work. Hope to discuss on skype. -->
			<t> Neighbor management policy depends upon the neighbor cache
			space availability and the same can be advertised proactively or
			can be handled reactively.  </t>
            <section title="Reactive Approach">
				<t> In this approach, the nodes select their RPL parent or the
				relay element purely based on link metrics and subsequently
				when they try to allocate their NCE in the target node, it may
				fail due to unavailability of the cache space. The failure can
				be communicated depending upon the signaling involved: </t>

                <t> <list style="hanging">
					<t hangText="NS failure:"> Section 6.5.3 of <xref
					target="RFC6775"/> defines a procedure for NS failure
					handling in case the router's neighbor cache is full. It
					results in a unicast NA with ARO status field set to two.
					</t>

					<t hangText="DAO NACK:"> Section 9.3 of RPL <xref
					target="RFC6550"/> specifies on how can the parent node
					react to DAOs from child. In case the parent could not make
					a NCE on behalf of the child node, a negative ACK with
					status (between 127-255) should be sent to the child node.
					The natural reaction of the child node would be to switch
					to an alternate parent.  </t>

					<t hangText="PANA Failure:"> PaC's auth session starts with
					a PaC discovering a PRE. The discovery procedure is not
					standardized and can be based upon various factors
					including signal strength of discovery messages from PRE.
					Post discovery, the PaC needs to send an unsecured unicast
					NS message with an ARO containings its link-local IPv6
					address. NS helps to determine whether the PRE can allocate
					an NCE for the PaC. PRE accordingly sends a NA response
					with appropriate status field.</t>
                </list> </t>
            </section>

            <section anchor="proactive" title="Proactive Approach">
				<t> Neighbor cache availability could be proactively advertised
				by the parent nodes in the DIO messages and in the PRE
				discovery messages. A child RPL node may additionally use this
				information from DIO as part of parent selection process. In
				case of new joinee node, the node may use PRE discovery
				messages with space availability information to select an
				appropriate PRE.  Proactive signaling of neighbor cache space
				availability will help the nodes to select the parent node or
				relay node such that the failure signaling due to cache full
				event can be reduced.  </t>

				<t> Currently there is no standard way of signaling such
				neighbor cache space availability information. RPL's DIO
				messages carry metric information and can be augmented with
				neighbor cache space as an additional metric. In case of PRE
				discovery however there is no standard way of defining this
				information since the PRE discovery procedure itself is not
				standardized.  </t>

				<t> In a wireless or shared bus network, a multicast DIO metric
				advertisement may reach several child nodes eventually everyone
				responding by selecting the same parent node causing neighbor
				cache to be exhausted. Thus the failure handling approaches
				defined in the Reactive Approach section applies here as well.
				But importantly the failure signaling will be significantly
				reduced because of proactive advertisement.  </t>
            </section>
        </section>
    </section>

    <section title="Reservation based Neighbor Management Policy">
        <!-- SD: we need to define here how we know our children in RPL non-storing.
        If needed, we could enforce a way to use 6lowpan-nd in non-storing context.
        E.g. force NS before switch, so we provision our entry at the future parent before switching.
        Also, with 6lowpan-nd, my understanding is that not only children and parent end up in the table.
        How shall we handle other nodes present in the cache, how to we identify children? -->
        <!-- RJ: Have added a section above which introduces use of 6lo-ND for
             establishing NCE in case of non-storing MOP. Looks like this has
             to be mandated during parent selection/switching. -->
		<t> This section defines a sample neighbor management policy, with the
		primary objective to reduce NCE churn and to ensure stability of
		routing adjacencies. The scheme uses a reservation based policy to
		reserve NCEs for: </t>

        <texttable anchor="tab_nce" title="Neighbor Cache Entry reservation">
            <ttcol align='center'>NCE Entry for</ttcol>
            <ttcol align='center'>MAX count</ttcol>
            <ttcol align='center'>Reason</ttcol>
            <c>Routing Parent</c>
            <c>MAX_ROUTING_PARENT_NCE_NUM</c>
            <c>PARENT</c>
			<c></c><c></c><c></c>
            <c>Routing child</c>
            <c>MAX_ROUTING_CHILD_NCE_NUM</c>
            <c>CHILD</c>
			<c></c><c></c><c></c>
            <c>Others such as pre-auth sessions</c>
            <c>MAX_OTHER_NCE_NUM</c>
            <c>OTHER</c>
            <!-- <postamble>Data from http://www.ietf.org/meetings/past.meetings.html</postamble> -->
        </texttable>

        <t>
            <xref target="tab_nce"/> denotes that the NCEs are reserved
            dependending upon the reason for its addition.
            MAX_ROUTING_PARENT_NCE_NUM specifies maximum number of parent
            entries a node should allow.  MAX_ROUTING_CHILD_NCE_NUM specifies
            maximum number of child entries that are allowed after which the
            node SHOULD decline the DAO signalling. MAX_OTHER_NCE_NUM specifies
            any other entries that might be created. Pre-auth session entries
            are usually short-lived and should be considered part of this
            category.
        </t>

		<t> Note that reservation policy depends upon identification of the
		reason behind making an NCE . In case of pre-auth sessions, the
		corresponding NCE is created based on unsecured NS/NA.  In case of
		storing MOP, CHILD NCEs are created either based on DAO (as shown
		in <xref target="s_callflow"/>) or based on secured NS/NA messaging (as
		shown in <xref target="ns_callflow"/>).  In case of non-storing MOP, a
		secured NS/NA messaging as shown in <xref target="ns_callflow"/> needs
		to be used.  </t>

		<t><figure align="center" anchor="reserv_table" title="Reservation of
		NCEs in neighbor table"> <artwork align="center"><![CDATA[
<- - - - - - - - - - - Routing Parents - - - - - - - - - - - - ->
+---------------------------------------------------------------+
|                                 |                   |         |
+-----------------------------------------------------+---------+
  Routing Child                    Routing Parents     Other
            ]]></artwork>
<!-- SD: artwork about: "parents" and "parent": confusing. How about "Routing neighbors" for the one at the top?
Children are technically not necessarily in the candidate parent set anyway. (I know the Contiki naming is confusing
but that is a different story :p)	-->
<!-- RJ: The primary message i wanted to convey thru this artwork was that Routing parents can possibly occupy all entries if the corresponding space is not occupied by child/others -->
        </figure></t>

        <t> As shown in the <xref target="reserv_table" />, the neighbor
        cache is partitioned into different entry types. The routing parents
        can possibly occupy any entry type if found vacant since in case an
        eviction is sought the non-preferred routing parent could be evicted
        without much impact on the functioning or on the control traffic. The
        eviction could be done based on reasons specified in <xref
        target="nce_eviction"/>.</t>

		<t> Routing Child entries are made in context to directly connected
		peers and these entries are not deleted unless they are unreacable or
		there is any reason for the parent node to believe that it is no longer
		the preferred parent for the child node. Deletion may happen based on
		reasons mentioned in <xref target="nce_deletion"/>.</t>

		<t> Other entries (OTHER) may be made in response to temporary
		requirement of making an NCE. One such case is the pre authentication
		phase where in the relay node makes an entry of the PaC temporarily
		till the time the authentication phase is completed. The NCE made thus
		is garbage collected at the end of the lifetime. Also an implementation
		may choose to keep a lower lifetime for such NCEs depending upon the
		time taken to complete the authentication process.  </t>

        <section title="Limitations of such a policy">
			<t> The reservation based policy mentioned in this section may
			result in sub-optimal path selection due to lack of NCE resource on
			the parent nodes. Also the restriction of maximum pre-auth sessions
			in the form of MAX_OTHER_NCE_NUM limits the maximum relay sessions
			that can be supported on the relay node.  </t>

			<t> The reservation policy allows the parent node to reject the
			child node's DAO or NS. But the child node cannot remember this
			rejection and may reattempt the same parent after some time
			depending upon triggers such as reception of DIO from the same
			parent who rejected it previously. One of the only way to stop the
			child node from reattempting such parent selection would be to also
			include a proactive approach wherein the parent node signals its
			resource availability in the DIO message as mentioned in <xref
			target="proactive"/>. Such a scheme of signalling parent node's
			resource availability is currently not standardized.</t>

			<t> RPL's storing MOP imposes additional restrictions.  One such
			case is where a child node may have a given parent node as its only
			parent and that parent node's NCE are all used up. In such a case,
			the child node would keep on retrying and failing to send a DAO
			through the parent node. Ideally the parent node could have evicted
			a least used child node or a child node who has an alternate parent
			available. Evicting such a child node is a complex process and may
			increase the control overhead as described in <xref
			target="dc_eviction"/>.  Thus the reservation based policy requires
			that the minimum node density is sufficiently high so that every
			child finds a parent node in its vicinity with enough resources.
			</t>
        </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
        <t>
            Thanks to Malisa Vucinic for pointing towards security aspects of
            un-authenticated nodes neighbor cache management.
        </t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
        <t>
            The Join Relay or the PANA Relay Element allows the
            un-authenticated nodes to join the network. Since the NS/NA
            signaling is unencrypted, it is possible that a malicious node may
            try to spoof and occupy all the entries. This draft explains the use
            of reservation based policy for managing such entries. Following
            points try to reduce the impact of such attacks:
            <list style="letters">
                <t>
                    Only a subset of entries are reserved for
                    un-authenticated nodes doing plain-text NS/NA.
                </t>
                <t>
                    It is recommended that NCE timeout be configured a lower
                    value to evict such entries as soon as possible. New
                    joining nodes are supposed to use these entries and thus
                    are only needed during the time the authentication is in
                    progress. Thus a short-duration NCE timeout will help
                    reduce the impact of DoS attacks.
                </t>
            </list>
        </t>
    </section>
  </middle>

  <back>
    <!-- References split into informative and normative -->
    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
        &RFC2119;
		&RFC6775;
		&RFC6550;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      &RFC5191;
      &RFC6345;

        <reference anchor="Woo_et_al">
            <front>
                <title>Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks</title>
                <author initials="A" surname="Woo">
                    <organization>University of California</organization>
                </author>
                <author initials="T" surname="Tong">
                    <organization>University of California</organization>
                </author>
                <author initials="D" surname="Culler">
                    <organization>Intel Corp</organization>
                </author>
                <date year="2003" />
            </front>
        </reference>
        <reference anchor="Dawans_et_al">
            <front>
                <title>On Link Estimation in Dense RPL Deployments</title>
                <author initials="S" surname="Dawans">
                    <organization>CETIC</organization>
                </author>
                <author initials="S" surname="Duquennoy">
                    <organization>SICS</organization>
                </author>
                <author initials="O" surname="Bonaventure">
                    <organization>Universite Catholique de Louvain</organization>
                </author>
                <date year="2012" />
            </front>
        </reference>
        <reference anchor="CONTIKI" target="http://www.contiki-os.org">
            <front>
                <title>Contiki: The Open Source OS for IoT</title>
                <author>
                    <organization>Thingsquare</organization>
                </author>
                <date year="2012"/>
            </front>
        </reference>
		<?rfc include="reference.I-D.ietf-6tisch-architecture.xml"?>
		<?rfc include="reference.I-D.ietf-6tisch-minimal-security.xml"?>
    </references>

    <!--
    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
    -->
</back>
</rfc>