Optimized Neighbor Discovery for 6LoWPANs: Implementation and Performance Evaluation

Transcription

1 Optimized Neighbor Discovery for 6LoWPANs: Implementation and Performance Evaluation Mohamed A. M. Seliem The Web of Objects Project Cairo University Giza, Egypt Khaled M. F. Elsayed, Ahmed Khattab Dept. of Electronics and Communications Engineering Cairo University Giza, Egypt {khaled, Abstract In this paper, we provide an implementation and thorough performance evaluation of the RFC 6775 optimized Neighbor Discovery (ND) protocol. RFC 6775 was developed by the Internet Engineering Task Force (IETF) to standardize IPv6 neighbor discovery over Low power Wireless Personal Area Networks (6LoWPAN). First, we investigate and analyze the basic RFC 4861 ND, developed for general networks running IPv6. We explain why such a basic ND protocol is inefficient and sometimes impractical for 6LoWPANs due to its heavy use of multicast transmission, and being not originally designed for non-transitive wireless links (e.g. IEEE links). Second, we overview and explain the optimized RFC 6775 ND. Third, we implement such an optimized ND on the widely used Contiki OS. Finally, we evaluate the performance of our implementation of the optimized ND protocol and compare it with the RFC 4861 based ND protocol. Our results show that the optimized ND protocol reduces the number of the exchanged radio messages in the network by 70% compared to RFC 4861-based ND. Besides, nodes multicast around 30% to70% less ND control messages. Such optimization alleviates network congestion, enhances the delivery ratio of ND packets to almost 100% and saves more power. Even in the case of variable node reachability, the optimized ND protocol shows a better performance compared to the RFC 4861 basic ND. Index Terms neighbor discovery; Contiki OS; performance evaluation; RFC 6775; 6LoWPAN. I. INTRODUCTION The Internet of Things (IoT) is a network of embedded physical objects that communicate and sense or interact with their environment. It is expected that billions of physical objects will be connected to the Internet by 2020 [1]. The Internet Protocol version 6 (IPv6) stands out as a natural choice due to the huge address space it offers since the * This work is part of the ITEA2 Web of Objects Project funded in Egypt by the Egyptian Ministry of Communication and Information Technology.

2 length of an IPv6 address is 128 bits. Neighbor Discovery (ND) is one of the main protocols used with IPv6 to perform functions analogous to the Address Resolution Protocol (ARP), router discovery, and router redirect protocols developed for IPv4. However, ND provides many improvements over its IPv4 counterparts such as enabling address auto-configuration, removing the need for extra packets exchange to resolve a router's link-local address and the need for a separate mechanism to configure the net mask, advertising the MTU for hosts to assure the same usage of a well-defined MTU value, and improving the packet delivery by introducing the neighbor unreachability detection mechanism. The ND protocol provides solutions for a wide set of problems related to the interaction between the nodes attached to the same link. ND defines mechanisms for achieving the following purposes: router discovery, prefix discovery, parameter discovery, addresses auto-configuration, address resolution, neighbor unreachability detection, and duplicate address detection. ND functions are designed to allow hosts to ascertain the ownership of an address or the mapping between link-layer and IP-layer addresses. Nodes use ND to determine the link-layer addresses for neighbors residing on the attached links to: (1) maintain the reachability status of all node s neighbors, (2) select a default router to inform these nodes with network parameters and route packets on their behalf, (3) check for address duplication when software configuration is used to define the node s MAC address, and (4) actively find a new default router, upon discovering changes on the link local address of the old default router. Neighbor discovery messages (embedded in ICMPv6 messages) are needed to implement the aforementioned functions. However, IPv6 neighbor discovery in its basic form specified in RFC 4861 [2] was not designed for nontransitive wireless links. This is because it relies on the traditional IPv6 link, which assumes symmetric reachability and multicast support capabilities. The basic ND specified in RFC 4861 heavily uses multicasting which makes it inefficient, and sometimes impractical in Low-power Wireless Personal Area Networks (LoWPAN) and their IPv6 based counterparts known as 6LowPAN [3]. A 6LoWPAN link [4] is characterized as lossy, low-power, low-bitrate, short-range; with many nodes attempting to save energy with long sleep periods. It is thus of crucial importance to optimize the ND protocol to minimize its overheads and ensure efficiency, especially when considering the nature of these devices that need to perform self-management, self-healing and self-configuration. An IoT device needs to learn about its immediate environment to be capable of performing these tasks. These needs thus justify a dedicated work towards optimizing neighbor discovery protocol in this special class of networked devices. Thus motivated, an optimized neighbor discovery protocol was specified in RFC 6775 [5] that introduces the following optimizations to the basic IPv6 neighbor discovery RFC 4861 [2]. The RFC 6775 specifically target lowpower and lossy networks such as 6LoWPANs through the following optimized components: (1) Host-initiated interactions to allow for sleeping hosts, (2) Elimination of multicast-based address resolution for hosts to minimize overhead when considering the limited capabilities of 6LoWPANs nodes, (3) A host address registration feature using a new option in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to optimize the interface between hosts and their default router, (4) A new neighbor discovery option to distribute 6LoWPAN

3 header compression context to hosts as needed by 6LoWPAN header compression [4], (5) Multi-hop distribution of prefix and 6LoWPAN header compression context to spread context information and prefix information from the border to all routers in a 6LoWPAN, and (6) Multi-hop Duplicate Address Detection (DAD), which uses two new ICMPv6 message types, to make it suitable for route-over topology. In this paper, we explain, implement and evaluate the performance of the new ND optimization introduced in RFC We present a detailed study of the original IPv6 ND protocol RFC 4861 and its implementation in the Contiki OS network stack [7]. Then we analyze the new optimizations and divide them into distinct well-defined components. However, the main contribution of this work is the implementation and subsequent evaluation of the optimized RFC 6775 ND protocol in Contiki OS. Our implementation focuses on the most important and beneficial optimizations which are the host initiated interactions, the elimination of the effect of multicast, and the enhanced host address registration mechanism. Finally, we perform an extensive set of experiments to evaluate the reduction in the number of ND exchanged messages (NS, NA, RS, and RA) and their performance implications. Our evaluation shows that for low number of hosts, the optimized ND sends around 70% less messages than the basic IPv6 ND protocol. As the number of hosts increase, this percentage is approximately 25%. Not only a reduction in the transmitted messages is realized, but also the optimized ND reduces the overhead of the multicast mechanisms in sending those messages. Nodes multicast around 69% less packets. This percentage becomes 30% when the number of hosts increases. Optimized ND shows a remarkable (almost 100%) delivery ratio for ND control packet even in the case of sleeping nodes. Even in the lack of 100% reachability, our results showed that the optimized ND has a significantly better performance compared to the basic ND by using fewer protocol messages while supporting the same functions along with added optimized features. The organization of this paper is as follows. We overview the basic neighbor discovery protocol in section II. In section III, we present the optimized features defined for ND RFC 6775 to handle 6LoWPAN. Then, we review the main components and implementation details of the optimized ND protocol in section IV. The performance evaluation results of our optimized ND implementation of are presented in section V. Finally, section VI concludes this paper. II. RFC BASIC NEIGHBOR DISCOVERY PROTCOL ND is a protocol in the Internet protocol suite that is used with IPv6. ND operates in the link layer of the Internet protocol suite and is responsible for address auto-configuration of nodes, address prefix discovery, discovery of other nodes on the link, determining the link layer addresses of other nodes, duplicate address detection, finding available routers and domain name system (DNS) servers, and maintaining the reachability information of the paths to other active neighbor nodes. In this section, we overview the basic IPv6 ND protocol

4 A. Basic RFC 4861 ND Messages and Headers The basic IPv6 neighbor discovery protocol defines five different ICMPv6 packet types to perform its functions. Basically a pair of router solicitation/advertisement (RS/RA) messages is used in router-to-host messaging and dynamic address allocation, while a pair of neighbor solicitation/advertisement (NS/NA) messages is used in nodeto-node messaging. Finally, the redirect message is used in next hop determination. 1) Neighbor Solicitation (NS) (Fig. 1a): Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Neighbor solicitations are also used for duplicate address detection (DAD). 2) Neighbor Advertisement (NA) (Fig. 1b): This is the response to the NS message. A node may also send unsolicited neighbor advertisements to announce link-layer address changes. 3) Router Solicitation (RS) (Fig. 2a): When an interface becomes enabled, hosts may send out router solicitations that request routers to generate router advertisements immediately rather than at their next scheduled time. Fig. 1: ICMPv6 headers for NS/NA messages 4) Router Advertisement (RA) (Fig. 2b): Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router solicitation message. Router advertisements contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a hop limit value, etc. 5) Redirect: A message that is used by the routers to inform hosts of a better first hop for a destination.

5 Neighbor discovery messages, shown in Fig. 1 and Fig. 2, include zero or more options from a set of options shown in Fig. 3. Some of these options may appear multiple times in the same message: Source Link-Layer Address Option (SLLAO): contains the link-layer address of the sender of the packet. It is used in the NS, RS, and RA messages. Target Link-Layer Address Option (TLLAO): contains the link-layer address of the target. It is used in NA and Redirect messages. Prefix Information Option (PIO): provide hosts with on-link prefixes and prefixes for address autoconfiguration. The PIO appears in Router Advertisement messages. Redirected Header: is used in Redirect messages and contains all or part of the packet that is being redirected. The MTU Option: is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known. Fig. 2: ICMPv6 headers for RA/RS messages

6 Fig. 3: Optional headers used in neighbor discovery messages. These messages and options contain important fields (flags, timers etc.) to be distributed over the whole network: Managed address configuration (M flag): If the M flag is set, it indicates that addresses are available via Dynamic Host Configuration. Else, then the address can be configured by any other means (software configured). On-link flag (L flag): When set, it indicates that this prefix can be used for on-link determination. Other configuration (O flag): If the O flag is set, it indicates that other configuration information is available via DHCPv6. Examples of such information is DNS-related information or information on other servers within the network. Router Lifetime: The lifetime associated with the default router in units of seconds. A Lifetime of 0 indicates that the router is not a default router and should be removed from the default router list. Reachable Time: The time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. Used by the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router). Retransmission Timer: The time, in milliseconds, between retransmitted neighbor solicitation messages. Retransmission timer is used by address resolution and the neighbor unreachability detection algorithm, a value of zero means unspecified (by this router). Router flag(r flag): When set, it indicates that the sender is a router. It is used by neighbor unreachability detection to detect a router that changes to a host. Solicited flag (S flag): When set, it indicates that the advertisement was sent in response to a neighbor solicitation from the Destination address. It is used as a reachability confirmation for neighbor unreachability

7 detection. Override flag (O flag): If the O flag is set, it indicates that the advertisement should override an existing cache entry and update the cached link-layer address. else, then it is not set the advertisement will not update a cached link-layer address though it will update an existing neighbor cache entry for which no linklayer address is known. Autonomous address configuration flag (A flag): when set, it indicates that this prefix can be used for stateless address configuration. B. Basic RFC 4861 ND Functions Here, we describe the neighbor discovery functions (dynamic address allocation, address resolution, NUD...etc.). IPv6 Dynamic Address Allocation: IPv6 dynamic address allocation is slightly different from its IPv4 counterpart. In IPv4, a host that is configured to obtain its address automatically requests it directly from a DHCPv4 server to get the IPv4 addressing information. Then, the DHCPv4 server responds with all the required information (IPv4 address, subnet mask, default gateway, and DNS servers). However, in IPv6 a host sends a multicast router solicitation message to locate routers that are capable of telling it the network address information. A router responds to this RS message with a multicast router advertisement message. This RA message directs the host how to obtain or create its IPv6 address. For example, routers can specify whether hosts should use DHCPv6 and/or autonomous stateless address configuration. When the host receives RA messages from different routers, it starts building a list of default routers. These RA messages contain the information about the network parameters such as the hop limits, the link parameters such as the link MTU, and the prefix-related information. The host uses these prefixes to build a list that is used later to determine the neighbors residing on-link with this host. IPv6 Address Resolution: Address resolution in IPv6 is similar to ARP in IPv4. However, in IPv6 nodes use neighbor discovery NS/NA messages to obtain the link local address of their neighbors. First, nodes multicast NS messages that contain their link local address to ask the target node to return its link local address (LLA). Then, the target node responds with a unicast NA messages with its LLA. Nodes use the LLAs of neighbors to build or maintain a neighbor cache list of the neighbors to which traffic has been sent recently. IPv6 Duplicate Address Detection: NS/NA messages are also used for Duplicate Address Detection (DAD) if more than one node has been assigned the same unicast address. DAD differs from address resolution as the source address of the NS message will be unspecified by setting it to zero. In the case of duplication, the node that has the address responds with a multicast NA message. As the NS sender does not use the desired IP address, it cannot receive unicast messages. DAD is specified in RFC 4862 [8]. IPv6 Neighbor Unreachability Detection: Neighbor Unreachability Detection (NUD) is one of the main functions in IPv6 neighbor discovery. It is used to actively keep track of neighbors changes. Then, it updates the status of

8 these neighbors stored in neighbor cache. A node sends unicast NS messages that solicit NA as reachability confirmation. The NUD process is used with neighbors to whom the node is actively sending packets. In addition to the above network functions, ND also handles the following situations: 1) When a router finds a better first-hop node to reach a particular destination, it uses a redirect messages to inform a host of this next hop. 2) When a node changes its link-layer address, it sends multicast unsolicited NA messages to inform its neighbors with the changes. Neighbors quickly update their neighbor cache entries that have become invalid. Then, the NUD process is used to ensure that all nodes will reliably discover the new address. 3) When nodes with replicated interfaces want to load-balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses. C. Basic RFC 4861 ND Conceptual Data Strcuture of a Host We next describe a model of data structure organization that hosts will maintain while interacting with neighboring nodes. This organization is provided by RFC 2461 [9] and adopted by RFC 4861 to facilitate the explanation of how the neighbor discovery protocol should behave. This model is only concerned with the aspects of the host behavior directly related to neighbor discovery. Hosts will need to maintain the following data structures for each interface: 1) Neighbor Cache: It is a set of entries about individual neighbors to which traffic has been sent recently. Entries are keyed on the neighbor s on-link unicast IP address and contain such information as its link-layer address, a flag indicating whether the neighbor is a router or a host, a pointer to any queued packets waiting for address resolution to complete. A Neighbor Cache entry also contains the information used by the neighbor unreachability detection algorithm, including the reachability state, the number of unanswered probes, and the time the next NUD event is scheduled to take place. 2) Default Router List: It is a list of routers to which packets may be sent. The algorithm for selecting a default router favors routers known to be reachable over those whose reachability is suspicious. Each entry also has an associated invalidation timer value (extracted from RA messages) used to delete the entries that are no longer advertised.

9 3) Prefix List: It is a list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from the information received in RA messages. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. The neighbor cache contains the information maintained by the NUD algorithm. A key piece of information is the neighbor s reachability state, which is one of five possible states: No state (S 0 ): An idle state used for implementation purpose. No entry is created for this node. INCOMPLETE (S 1 ): Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. REACHABLE (S 2 ): The neighbor is known to have been reachable recently (within tens of seconds ago). STALE (S 3 ): The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability. DELAY (S 4 ): The neighbor is no longer known to be reachable, and traffic has recently been sent to the neighbor. Rather than probe the neighbor immediately, however, delay sending probes for a short while in order to give upper-layer protocols a chance to provide reachability confirmation. PROBE (S 5 ): The neighbor is no longer known to be reachable, and unicast NS probes are being sent to verify reachability. Fig. 4 shows the finite state machine (FSM) state transitions when performing address resolution and neighbor unreachability detection using the above states and by applying the mentioned model of the data structure. Fig. 4: FSM of NUD and address resolution functions

10 Table 1 summarizes the events that happen to change the state of the Neighbor Cache Entry (NCE), and the transitions taken in case of each event. Name Event Action T1 New packet to send Create entry. Send multicast NS. Start retransmit timer. T2 Retransmit timeout, less than max no. of retransmissions. Retransmit NS Start retransmit timer. T3 T4 T5 T6 T7 T8 T9 Retransmit timeout, max no. of retransmissions. Received NA, Solicited flag =1, Override flag= any. Received NA, Solicited flag =1, Override flag= any. Received NA, Solicited=any, Override=any No link-layer. Received NA, Solicited=1, Override=0 Same link-layer address as cached. NA, Solicited=1, Override=0 Different link-layer address than cached. NA, Solicited=1, Override=0 Different link-layer address than cached. Discard entry, Send ICMP error Record link-layer. Send queued packets. Record link-layer. Send queued packets. Update content of Is_Router flag. Move to Reachable state If Reachable Move to Stale state Any state Other than Reachable (stale, probe, or delay) No change T10 More than Reachable time seconds since reachability confirm. Move to Stale state T11 Sending packet Start delay timer. T12 T13 T14 T15 Delay timeout Retransmit timeout, less than no. of retransmissions. Retransmit timeout More no. of retransmissions. Received NA, Solicited=0, Override=1 address. Different link-layer address than cached. Send unicast NS, Start retransmit timer Retransmit NS. Discard entry Table 1: Events and Transitions of the neighbor discovery protocol FSM Record link-layer STALE III. RFC OPTIMIZED NEIGHBOR DISCOVERY PROTOCOL In this section, we describe the new features added by the optimized ND protocol according to RFC Finally, the finite state machine of the new optimized ND protocol and its functions along with clarifying the new protocol functions (e.g. registration) are provided.

11 A. Optimized Neighbor Discovery A 6LoWPAN [3]is characterized as lossy, low-power, low-bit-rate, short-range; with many nodes saving energy with long sleep periods. In RFC 4861 based neighbor discovery, the routers find the hosts by assuming that a subnet prefix maps to one broadcast domain. Then the routers multicast NS messages to find the host and its link-layer address, even if the on-link flag (L flag) in the RA prefix information option was set to zero. Furthermore, the DAD use of multicast assumes that all hosts that auto-configure IPv6 addresses from the same prefix can be reached using link-local multicast messages. Also, routers use multicast NS messages to find the hosts. Thus, RFC 4861 based ND multicast is not desirable in wireless low-power and lossy networks. Considering the above characteristic of 6LoWPAN and basic ND protocol, several optimizations and extensions to neighbor discovery were needed for the wide deployment of IPv6 in such low-power and lossy networks. The importance of these optimizations comes from the interactions between hosts and routers, which are not affected by the configuration of 6LoWPAN. As all ND messages are initiated by the hosts, this would allow hosts to sleep and avoid using multicast ND messages except when necessary. The optimization of ND protocol adds new optional headers to be used in the ND messages. These new headers will be helpful in implementing the new features of ND protocol over 6LoWPAN Networks. Address Registration Optional (ARO) Header (Fig. 5a): is used to represent the main structure for the address registration optional header. ARO is introduced since routers need to know the set of host IP addresses that are directly reachable and their corresponding link-layer addresses. This needs to be maintained as the radio reachability changes. ARO can be included in unicast NS messages sent by hosts. The ARO is required to provision better reliability and power saving. The lifetime timer provides the flexibility to the host to register an address that should be usable during sleep periods. 6LoWPAN Context Optional (6CO) Header (Fig. 5b): is used to represent the main structure for the 6LoWPAN Context Optional header. The 6LoWPAN Context Option (6CO) carries prefix information for 6LoWPAN header compression and is similar to the prefix information option (PIO). However, the prefixes can be remote as well as local to the 6LoWPAN, since header compression potentially applies to all IPv6 addresses. This option allows for the dissemination of multiple contexts identified by a 4-bit Context Identifier (CID). Authoritative Border Router Optional (ABRO) Header (Fig. 5c): is needed when RA messages are used to disseminate prefixes and context information across a route-over topology. In this case, Routers receive PIOs from other routers. The ABRO must to be included in all RA messages in the case when RAs are used to propagate information between routers. The optimized ND protocol is designed such that the host to router interaction is not affected by the configuration of the 6LoWPAN. The new optimized protocol functions are: host initializes the interaction with the router, neighbor

12 unreachability detection, address registration process, and the use of solicited unicast RA messages. Also there are parts of the ND optimization that can be substituted with a routing protocol such as: Multi-hop distribution of prefix and 6LoWPAN header compression context; Multi-hop duplicate address detection. A routing protocol can provide a good alternative for such mechanisms. Thus, if substitution is intended then multi-hop prefix distribution (the ABRO) and the 6LoWPAN Context Option (6CO) for distributing header compression must be substituted (RFC 6775 [5] section 1.4). Applying optimized ND protocol over 6LoWPAN will minimize signaling, reduce the use of multicast messages, and support sleeping hosts. Also, the optimized neighbor discovery is designed to operate successfully in both mesh-under, which places routing function at the link layer to maintain the deterministic link characteristics, and route-over, which places all routing functions at IP layer with every physical hop appears as an IP hop. [12][13][13]. Fig. 5: The new optional headers of the optimized ND protocol B. Optimized ND Functions The optimized ND protocol inherits all the functions defined is RFC 4861 based ND protocol such as: router discovery, prefix discovery, duplicate address detection, address resolution, and neighbor unreachability detection. However, some of these functions are entirely changed and others are just slightly modified to make ND efficient and suitable for 6LoWPAN networks. Moreover, the optimized ND protocol proposes some new functions such as: the address registration process and the distribution of context information over the network. In what follows, we will discuss these new and modified functions.

13 Address Registration Process: This is the process during which a host node sends NS message with an address registration option to a router creating a Neighbor Cache Entry for the host with a specific timeout. This will allow hosts to sleep and reduce the usage of multicast signaling. In the registration process response, a router sends NA message with address registration option containing a status field. A host processes the ARO to determine the result of the registration process, which will be one of the following: Status = 0 indicates the success of the registration process; Status = 1, indicates a duplicate address detected; while status = 2 indicates the router cache is full. Moreover, the registration process is combined with NUD process to reduce the usage of ND messages. Address Re-registration Process: This process is considered as a sub-function of the registration process, which happens when host needs to re-register with a router before registration lifetime expiry. Re-registration is important even if the host does not have data to send, as other nodes might try to send packets to the host. In all cases, when a host knows it will no longer use a router it is registered to, it shall unregister with the router by sending an NS message with an ARO containing a lifetime of 0. Prefix and Context Information Distribution: Hosts send RS messages to solicit information about the network from neighbors routers. RS message must include the SLLAO of the host to enable unicast RA messages in response. Hosts process the RA message to extract the data it receives from the router, and then hosts maintain the data about the context information in the context table, and maintain the prefixes information in the prefix list. Hosts use the information in the 6LoWPAN context table for decompression process when receiving packets. A 6CO header received in RA message is used to add or update the information in the context table. If the context identifier field matches one of the entries in the existing context table, then that entry is updated with the information in the 6CO. In addition to these new functions, some ND functions have a modified behavior such as: Network Parameter Discovery: No need for periodic multicast RA message. Only unicast RA messages, in response to RS messages sent by the host, are used for distribution of network information. This will reduce the periodic multicast signaling in the network. Note that multicast is still used at the beginning of interface initialization. Address Resolution: Address resolution is not needed, as the address registration process and the SLLAO within the exchanged messages provide sufficient information to resolve an IPv6 address. This will prevent transmitting multicast NS to resolve IPv6 address Duplicate Address Detection: Nodes do not need to perform the DAD function separately. In the optimized ND protocol, DAD is part of the address registration process. This will reduce the number of exchanged NS/ NA messages.

14 Neighbor Unreachability Detection: The NUD algorithm used in optimized ND is similar to the NUD algorithm used in RFC 4861 based ND protocol. However, the NS/NA messages pair, responsible for checking reachability, also carries the ARO to do the registration or unregistration process. The combined NUD and registration process enables new orthogonal registration states with a new FSM. The new states for the registration process (registered, tentative etc.) are independent of the reachability state (reachable, stale etc.). For example, a host can be unreachable at a certain moment but still be in registered state at its router as its registration life time has not expired, or a host can be reachable but needs to unregister with the default router. C. Optimized ND Finite State Machine. The features added to the optimized ND protocol will lead to a new finite state machine. This new FSM must take into consideration the following changes: First, optimized neighbor discovery prevents hosts from sending multicast NS messages. Hosts in a 6LoWPAN use the ARO in the NS messages they send as a way to maintain the neighbor cache in the routers, thereby removing the need for multicast NSs to do address resolution. Unlike RFC 4861, the hosts initiate updating the information they receive in RA messages by sending RS messages before the information expires. However, when NUD indicates that one or all of the default routers have become unreachable, the host uses RS messages to find a new set of default routers. Therefore, hosts do not need to join the solicited-node multicast address, since nobody multicasts NSs in this type of network. Second, the hosts need to intelligently retransmit RS messages whenever the default router list is empty, one of its default routers becomes unreachable, or the lifetime of the prefixes and contexts in the previous RA is about to expire. This is because hosts do not depend on multicast RA messages to discover routers. Third, address auto-configuration depends on the managed address configuration (M) flag, if the M flag is set; it indicates that addresses are available via Dynamic Host Configuration Protocol (DHCPv6), and if the M flag is not set, that means the address is not configured by DHCPv6, so duplicate address detection need to be performed. However, unlike in RFC 4861, DAD will be performed as part of the registration process. Finally, the Neighbor Cache Entries (NCEs) will be managed slightly different from the way followed by RFC 4861 based ND. This will results in three different types of NCEs which also specify how those entries can be removed: Idle State (OS0): No entry created, as still no interaction happens. Registered (OS1): Entries that have an explicit registered lifetime and are kept until this lifetime expires or they are explicitly unregistered.

15 Garbage Collectable (OS2): Entries that are subject to the normal rules of cache management related to ND and address resolution functions in RFC 4861, that allow for garbage collection when low on memory. Tentative (OS3): Entries those are temporary with a short lifetime, which typically get converted to Registered entries. To Be Unregistered (OS4): Auxiliary registration entry state. Fig. 6: Registration process FSM of the optimized ND protocol These types of the NCE are orthogonal to the states, used for NUD process, specified in RFC Fig. 6 shows the relation between the types of NCEs, referred to as OS0, OS1, OS2, OS3, OS4, respectively. The transition between the four states can be explained as follows: When a router receives RS message from a host, it creates a tentative NCE for this host. Once a router has successfully had a node register with it, the result is a registered NCE. When a router changes its status from a router that sends RAs to a host that receives RA messages or receive multicast NS messages, the result is garbage collectable NCEs. There can only be one kind of NCE for an IP address at a time (router s NCEs or host s NCEs). Table 2 specifies the events and the action that explains the above FSM. It is noted that the FSM related to reachability as defined in RFC 4861 are maintained orthogonally to the reachability FSM. Name Event Action U1 Registration timer Expired, Registration in progress, Max no. of retransmissions. Delete the default router; we must delete also all registrations with that router. U2 Registration timer Expired, Registration in progress, Less than max no. of retransmissions. Reset Registration timer, Retransmit NS message. U3 Received NA, Status= success. Registration process succeeded, update NCE.

16 U4 U5 Host does not need router(e.g. Router life time about to expired) Received RA. First interaction with the router. Transmit NS message with an ARO containing a lifetime of 0. Tentative NCE for the Router. Start the registration process by transmitting NS message. U6 Received RA. Router already registered. Garbage Collectable NCEs, as there can only be one kind of NCE for an IP address at a time. Table 2: Events and actions of the registration process FSM IV. OPTIMIZED NEIGHBOR DISCOVERY IMPLEMENTATION In this section, we present the main contribution of this work which is design, implementation and deployment of the optimized ND protocol features over Contiki OS. Then, we discuss the protocol consideration in implementing the behavior of hosts and routers. A. RFC 4861 ND Implementation in Contiki OS The Contiki OS, developed for 6LowPAN systems, implementation of RFC 4861 is based on the following modules: Uip_nd6 module that implements the different actions needed to handle the various ND messages listed above, and contains the variable definitions, function declarations and protocol constants of the ND protocol. Uip_ds6 module that contains the variables definitions, function declarations and network interface and stateless auto-configuration [8] that is used to handle the IPv6 data. It also comprises parts of the neighbor discovery and auto configuration state machines. We thoroughly analyzed the basic ND protocol RFC 4861 as implemented in Contiki 2.7. We identified two main issues in this implementation that affects the performance of the ND message exchange and operation. 1) RPL and Neighbor Discovery Duplication of Work The Routing Protocol for Lossy networks (RPL) [11] is adopted as the default routing mechanism in Contiki. RPL exchanges ICMPv6 messages (e.g. DAG Information Solicitation (DIS), DAG Information Object (DIO), and DAG Advertisement Object (DAO)) between nodes to construct the routing table for each router node and construct a Data Acyclic Graph (DAG) for the entire network from a network layer point of view. Meanwhile, the ND protocol control messages are used between hosts and routers at the link layer. We found that RPL messages duplicate ND protocol messages in some of their functions. In order to clearly demonstrate the ND protocol behavior, and focus on the link layer only, we deactivate RPL and all its related functions in our experiments in order to closely monitor the ND function performance and show all types of messages exchange between client and server.

17 2) Prefix List Access Prefix discovery is the process through which hosts learn the ranges of IP addresses that reside on-link and can be reached directly without going through a router. In Contiki implementation, routers prefix entries are implemented in the RPL files. However, host prefix entries are implemented in ND files. Given that, we deactivate the RPL protocol implanted function, we need to implement the router prefix entries in the ND files. B. ND Optimized Message Transmission Here, we discuss our effort to transmit and process the optimized ND protocol messages. In our implementation, we need to reduce the number of exchanged messages and at the same time assure the same functionality of the ND protocol, in order to optimize the ND messages transmissions. We modified the interval between successive RA messages transmissions, MAX_RA_DELAY_TIME, and the interval between successive RS messages transmission to limit the RS/RA transmissions. Also, some protocol constants are added by (RFC section 9) such as: TENTATIVE_NCE_LIFETIME is added with 20 seconds value. An RS might be received from a host that has not yet registered its address with the router. Thus, the router must not modify an existing NCE based on the SLLAO from the RS. However, a router MAY create a tentative NCE based on the SLLAO. Such a tentative NCE timed out in TENTATIVE_NCE_LIFETIME seconds, in order to allow for another host to attempt to register the IPv6 address, unless a registration converts it into a Registered NCE. MAX_RTR_SOLICITATION_INTERVAL is set to 60 seconds, to truncate the increase in the retransmission timer of an RS message. The optimized ND protocol has two main components. The first component handles the RS/RA message pair as shown in Fig. 7. It targets minimizing the overhead by avoiding the use of multicast flooding, and reducing the use of link-scope multicast messages. Routers will not transmit any RA messages until they receive a router solicitation message sent by a host. This removes the need for periodic or unsolicited RA messages from routers to hosts. Fig. 7: Basic Router Solicitation/Router Advertisement Exchange between hosts and router.

18 The second component handles the NS/NA messages as shown in Fig. 8. It optimizes the interfaces between hosts and their default routers and provides support for sleeping hosts. This removes the need for routers to use multicast NS to find hosts and supports sleeping hosts. An implementation that adheres to RFC 6775 must implement these behaviors. Fig. 8: Neighbor Discovery Address Registration C. Host Behavior in the Optimized ND Protocol We demonstrate the behavior of host node that uses the optimized ND protocol. Code 1 illustrates and summarizes the sequence of the prominent processes performed by the host. First, a host obtains a link-layer to assign a link-local IPv6 address to itself. A link-local IPv6 address is configured based on the host s EUI-64 linklayer address. OBTAIN EUI-64 Link-Layer Address ASSIGN Link-Local IPv6 Address USES the Following Constants: MAX_RTR_SOLICITATIONS := Maximum number of successive RS transmissions. RTR_SOLICITATION_INTERVAL := the interval between 2 successive RS transmissions MAX_NS_Transmissions:= Maximum number of successive NS transmissions. RETRANSMISSION_TIMER_INTERVAL:= the interval between 2 successive NS retransmissions SET Periodic Timer SET RS Count to 0 SET NS Count to 0 REPEAT IF RS Count < MAX_RTR_SOLICITATIONS IF Host cache Contains Router Address CALL Send_RS with Router Address ELSE CALL Send_RS with All-routers multicast address END WAIT RTR_SOLICITATION_INTERVAL INCREMENT RS Count ELSE CALL Retrans_RS //Retrans_RS decides whether RS retransmissions are needed or

19 not. RESET RS Count END Until Router Advertisement Received Obtain Network Parameters (e.g. prefix, Continue) Obtain Default Router Lifetime value Obtain Valid Lifetime value REPEAT IF NS Count < MAX_NS_Transmissions SET Registeraion Lifetime CALL Send_NS_Registered with Router Address WAIT RETRANSMISSION_TIMER_INTERVAL INCREMENT NS Count ELSE CALL Retrans_NS RESET NS Count END Until Neighbor Advertisement Received OBTAIN Neighbor State. OBTAIN status value. CASE status OF 0 : USE this Address (successful registration) 1 : REMOVE this Address (duplicate address) IF this address registered with any other router SET Registeraion Lifetime to 0 CALL Send_NS_Registered with Router Address 2 : Register with any other router. ENDCASE Code 1: Pseudo-code for host behavior in optimized ND protocol The host determines one or more default routers in the network by sending an RS to the all-routers multicast address with the SLLAO set to its link-local address. If the host is able to obtain the link-layer address of a router through its link-layer operations, then the host may form a link-local destination IPv6 address for the router and send it a unicast RS. A host should inspect the various lifetimes to determine when it should next initiate sending an RS to ask for any updates to the information. The lifetimes that matter are the Default Router Lifetime, and the Valid Lifetime in the PIO, the host sends one or more unicast RS message to the router well before the shortest of those lifetimes expires and then switches to multicast RS messages if there is no response to the unicasts. Since hosts do not depend on multicast RAs to discover routers, the hosts need to retransmit RS. The retransmission rate is to initially set to send up to 3 (MAX_RTR_SOLICITATIONS) RS messages separated by at least 10 seconds (RTR_SOLICITATION_INTERVAL) as specified in RFC 4861, and then is switched to slower retransmission rate. After the initial retransmissions, the host should do truncated binary exponential back-off of the retransmission timer for each subsequent retransmission, truncating the increase of the retransmission timer at 60 seconds (MAX_RTR_SOLICITATION_INTERVAL). In all cases, the RS retransmissions are terminated when router responds with a unicast RA to the IP source address using the SLLAO from the RS after creating a tentative NCE.

20 The processing of RA messages is as in RFC 4861 in addition to handling the new features and triggering address registration when a new address has been configured. Furthermore, the SLLAO must be included in the RA. Unlike RFC 4861 section 6 that limits the timer value to 9000 seconds, the optimized ND allows the maximum value of Router Lifetime field to be up to 0xFFFF seconds, which is the largest value of the 16- bit router life time size. Next, the host registers its address with one or more of its default routers by sending a unicast NS message with an ARO containing its tentative global IPv6 address to register, the Registration Lifetime, and its EUI-64. An SLLAO is also included with the link-layer address corresponding to the address being registered. If a successful (Status 0) NA message is received, the address can then be used, and the host assumes that it has been successfully checked for duplicates. The address registration procedure may fail for two reasons: when no response to NS messages is received (NUD failure), or an ARO with a failure Status (Status > 0) is received. In the case of NUD failure, the entry for that router will be removed. Thus, address registration is no longer of importance. If a duplicate address (Status 1) NA message is received, the host removes the temporary IPv6 address. Moreover, if the host has valid registrations with other routers, these must be removed by registering with each of these routers using a zero ARO lifetime. If a neighbour cache full (Status 2) message is received, the host attempts to register with another default router. The host needs to perform maintenance by sending a new NS address registration before the lifetime expires. A host handles NA messages as specified in RFC 4861, with added logic described in this section for handling the ARO. In addition to the normal validation of an NA and its options, the ARO is verified as follows. If the length field is not equal to two, the option is silently ignored. If the EUI-64 field does not match the EUI-64 of the interface, the option is silently ignored. D. Router Behavior in the Optimized ND Protocol The router s behavior is slightly different than its counterpart in RFC 4861 ND protocol. In optimized ND, the router does not send periodic RA messages. Instead, it only responds with an RA message upon receiving an RS message. A router processes the RS messages as specified in RFC A router must check the source of the solicitation message, as it might be from a host that has not yet registered its address. In this case, the router may create a tentative NCE based on the SLLAO included in the RS message, then the router waits for the host to register its address for TENTATIVE_NCE_LIFETIME seconds, if this timer times out, then the NCEs will become garbage collectable. Routers must not set the L flag in the PIOs attached to transmitted RAs, to prevent hosts from transmitting multicast NS messages. When a router receives an NS message, it will be processed as specified in RFC However, it must also process the new attached ARO header. First, routers validate the received NS message and its options. Then, routers

21 check the validation of the ARO header as follow: if the source address of the NS is unspecified address, or if no SLLAO is included in the NS message, then any included ARO is invalid and must be ignored. Consequently, the NS is processed as if it did not contain an ARO. In the case of the NS message has a valid ARO, The router checks its neighbor cache for duplication. If the ARO did not result in a duplicate address, then if the registration lifetime is non-zero the router creates or updates an NCE for the IPv6 source address of the NS. However, if ARO contains a zero Registration Lifetime, then any existing NCE for the IPv6 source address of the NS must be deleted and an NA is sent. Also, if the Registration Lifetime in an NCE expires, then the router must delete the cache entry. Any changes in registered NCEs would result in notifying the routing protocol. Routers should not send redirect messages, because a router cannot tell whether the host can reach the redirected to- target or not. Exceptionally, redirect messages are sent. E. Proposed Optimized ND Implementation using Contiki In order to implement the Contiki OS UIP source code to include the RFC 6675 optimization, we modify the Uip_nd6 and Uip_ds6 modules. Our source code is available at [14]. The changes in this module include implementing the address registration optional ARO header, its fields, and several modifications in the module functions to handle the transmission and reception process of this new optional header. ARO can be included in unicast NS messages sent by hosts. The lifetime timer (UIP_ND6_REGISTRATION_LIFETIME s) provides the flexibility to the host to register an address that should be usable during its sleep schedule. All the functions, related to NS/ NA message processing, are modified to handle the new optional header as follows: uip_nd6_ns_input: this function is modified to process the ARO header attached to an incoming NS messages and to update neighbor cache by the source address of this NS message. In all cases, the host/router will respond with an NA message. uip_nd6_ns_output: this function is modified to be used in registration process. Upon receiving RA message from a router, hosts send unicast NS messages to register their IPv6 addresses, and also to do NUD to verify that their default routers are still reachable. The registration is performed by the host including an ARO in the NS it sends. ARO must include the registration lifetime of this address. uip_nd6_na_input: this function is modified to respond in case of receiving NA message as a part of registration process. In addition, it also triggers transmission of RS messages in case of one default router is removed from the default router list.

22 uip_nd6_ra_output: this function is modified to handle the RA message transmission to support transmission of unicast messages. Note that there is no problem to obtain the destination unicast address since we added the source link local address optional header (SLLAO) in the to-be-received RS message. Additionally, a few new functions are implemented create_aro: this function is used to construct the ARO header that is added to NS or NA messages in registration process. uip_ds6_send_ns_registered: this function is implemented to trigger sending the NS message to register node address upon receiving RA message from any router. The UIP_ds6_ Module Our Modifications in this module targets the following functions: uip_ds6_periodic: This function periodically checks the node s data structure (e.g. neighbor cache, prefix list, default router list, etc.), and triggers the transmission of periodic RA message. We disabled the trigger of periodic RA transmissions, and we include the periodic processing on registration address list. Registration process actions and outputs are mainly implemented in this function. uip_ds6_init: This function initializes node s interface. According to RFC 6775, a node does not need to join the solicited node multicast address to avoid multicasting. Also, we modified this function to initialize the data structure and to set the interface parameters that are related to the address registration list. send_ra_solicited: This function is implemented to schedule the transmission of solicited RA messages according to the definitions of the new optimization protocol. send_rs: This function is implemented to transmit RS messages on interface initialization and retransmissions. A host performs a truncated binary exponential back-off of the retransmission timer per subsequent retransmission. tcpip_event_handler: This process handles the RA delay timer expiration by calling uip_nd6_ra_output function to transmit a solicited RA message. Also, we implemented a new data structure related to the address registration process (registered address list) and we created all the functions that handle the changes in this registered address list: uip_ds6_reg: A structure to handle optimized ND protocol registrations. uip_ds6_reg_add: Adds a registration to the registrations list. It also increases the value of the number of registrations of the corresponding default router.

23 uip_ds6_reg_rm: Removes a registration from the registrations list. It also decreases the value of the number of registrations of the corresponding default router. uip_ds6_reg_lookup: Looks for a registration address in the registrations list. uip_ds6_get_registrations: to return the number of addresses that are registered (or pending to be registered) with a router. uip_ds6_reg_cleanup_addr: Removes all registrations of specific address from the registration list. If the registration is in REGISTERED state, we cannot just delete it, but we must first send a NS with ARO lifetime = 0. As there may be more than one, we mark it as TO_BE_UNREGISTERED so uip_ds6_periodic can process them properly. uip_ds6_reg_cleanup_defrt: removes all registrations with default router from the registration list. V. EVALUATION OF THE OPTIMIZED ND PROTOCOL In this section, we present an exhaustive set of experiments that does not only evaluate the performance of the optimized ND protocol but also demonstrates that existing implementation of ND protocol can benefit from the gains of implementing this optimization for various network types. A. Simulation Setup For the performance evaluation of our implementation of the optimized RFC 6775 ND protocol, we use Contiki OS v2.7 and Cooja [15] simulator tools to get the evaluation results. We consider a network that contains a variable number of hosts and one router centered between these hosts. Nodes use simple UDP packets for communication and data exchange. We use the same configuration, and the same type of nodes that are used to evaluate the basic IPv6 ND protocol. These configurations are made to assure the reachability of nodes. The nodes distribution shown in Fig. 9 will allow nodes to discover more than one neighbor. This will test the criteria of neighbor selection. In basic ND, hosts can maintain NCEs for other on-link hosts. However, in optimized ND protocol, hosts do not maintain NCEs for other hosts, only routers maintain the hosts addresses in its registration cache.

24 Fig. 9: Network topology used to test ND protocol Our scope is the data link layer where the ND processes takes place. Hence, the routing layer is out of our scope to prevent duplication of RPL and ND protocols functions as explained in section IV A.1. In router nodes, we disable the functionalities of RPL, and enable the transmission of RAs to allow dynamic address allocation and other functionalities discussed in section B. In host nodes, we disable the router configuration to allow transmission of Router Solicitation messages. Other configuration like Cooja s power trace will be set to investigate the power behavior of network nodes. B. Reduction Exchanged ND Messages The first experiment aims to show the number of exchanged ND messages for the optimized ND protocol versus the original implementation of the ND protocol as the number of hosts vary. We compare the numbers for each type of messages (RS, RA, NS, and NA), and then we will combine the overall messages in order to show the overall reduction in the number of exchanged messages. In Fig. 10, the optimized ND protocol reduces the transmission of neighbor advertisement messages by around 30% relative to the basic ND protocol. This reduction is mainly due to two reasons: the retransmission timer period increased; the NA is sent in response to NS message, and then in the optimized ND duplicate address detection is eliminated; and there is no need for address resolution in the Registration process (Section A). However, this will lead to the slight increase in transmitting NS messages as shown in Fig. 11.

25 N um ber of N A M essages Number of Hosts NA 677 NA 486 Number of NS Messages NS NS Number of Hosts Fig. 10: The number of NA messages of both RFC 4861 and RFC 6775 implementations for different number of host nodes. Fig. 11: The number of NS messages of both RFC 4861 and RFC 6775 implementations for different number of host nodes For the RS/RA pair, our implementation of the optimized ND protocol reduces the transmission of RA messages by 90% as shown in Fig. 12. This is achieved by disabling the periodic RA messages and the fast termination of the solicitation process after receiving RA message. Fig. 12 also indicates that the number of RA messages in both implementations do not depend on the number of hosts since we assume only one router. We next evaluate the change in the number of RS messages with the number of host nodes. Fig. 13 shows the number of RS messages for both ND protocol implementations. The number of RS messages increase with increasing number of host nodes. However, the optimized ND protocol shows a better behavior in transmitting and receiving RS/RA messages. The terminating process of RS messages transmissions is tightly controlled in the new optimizations as explained in Section IV C. Next, we count all the ND messages in order to assess the overall behavior of optimized ND protocol. Fig. 14 shows a reduction of (25% to 70%) in the total number of transmitted ND messages. This is a significant indication on: optimizing the ND control packet transmissions and minimize signaling through the network, besides multicast schemes is reduced in this optimized version of ND protocol.

26 Number of RA Messages Number of Hosts RA 6775 RA 4861 Number of RS Messages RS RS Number of Hosts Fig. 12: The number of RA messages of both RFC 4861 and RFC 6775 implementations for different number of client nodes. Fig. 13: The number of RS messages of both RFC 4861 and RFC 6775 implementations for different number of client nodes Total Number of Combined ND Messages Total 6775 Total Number of Hosts Fig. 14: The number of total ND messages of both ND (RFC 4861) and Optimized ND (RFC 6775) implementations for different number of host nodes Number of Transmitted Messages Number of Hosts 6775 Multicast Msgs 6775 unicast Msgs 4861 Multicast Msgs 4861 unicast Msgs Fig. 15: Multicast and unicast Messages sent by nodes for both optimized ND and basic version of ND protocol.

27 C. Reduction in Using Multicast Messages The second experiment aims to inspect the number of multicast messages for the optimized ND protocol versus the original ND protocol implementation. One of the main goals of the optimization is to reduce the multicast IPv6 packets transmitted between network nodes. As we mentioned earlier the original ND is based on sending multicast messages. Multicast message is not favorable in 6LoWPANs due to its lossy nature as explained in Section III. Optimized ND reduces the effect of multicasting as mentioned in section III A. Fig. 15 shows the reduction in the number of transmitted multicast messages around (30% to 69%). D. Network Life Time and Power Consumption Optimized ND allows hosts to sleep for power saving purposes. However, a host has to wake-up before its registration life time expires to update its status at the default router, or else the host will be removed from router s NCEs. In this case, the host will start the registration process from the beginning. This effect might add overhead due to the multiple use of NS/NA transmission in the re-registration process. The third experiment aims to test the worst case when hosts fail to update its registration life time. Consequently optimized ND algorithm is reapplied from the beginning. This experiment is divided into two steps: First, we assess the life time of the network. We build a battery model mainly based on using and processing the optimized ND messages to show the effect of nodes communications (transmissions, receiving etc.) on the network life time. By changing the nodes reachability to trigger failure in updating the registration lifetime, we will test the optimized ND protocol and how it affects the network lifetime. Fig. 16 shows the effect of NUD reachability process on the battery of the nodes and network life time. The network life time is the time needed until the last host in the network drains its battery. 100 % reachability is considered the reference point in the results presented in Fig. 16. In the full reachability scenario, hosts will successfully be able to update their registration lifetimes. However, when we decrease the reachability percentage, we find that the probability of failure in updating the registration lifetime increases. Consequently, extra transmission of NS/NA messages will take place for reachability confirmation and node registrations. This behavior will drain the nodes batteries faster. Consequently it will degrade the network lifetime. We conclude that both optimized ND protocol and RFC 4861 based ND affect the network lifetime when the reachability decreases due to the retransmissions of ND messages. In optimized ND, we find that the network lifetime decreases only 6% when network suffers low level of reachability (50%). On the other hand, the RFC 4861 based ND suffers from 27% drop in the network lifetime. In the second part of this experiment, we assume that each node has 5000 units of power. This amount of power is related to transmission of IPv6 packets. We measure the average power of the nodes in the network every

28 120% 6000 Network Life Time % 100% 80% 60% 40% 20% 0% 100% 99% 98% 95% 94% 94% 94% 90% 86% 83% 74% 73% 100% 90% 80% 70% 60% 50% Reachability % RFC 6775 RFC 4861 Network Average Power (unit) Time (unit) RFC 6775 RFC 4861 Fig. 16: Network life time for various percentages of nodes' Fig. 17: Average power consumption for group of nodes versus reachability. time. 5 seconds. Fig. 17 shows the drop in the network average power level in both basic and optimized ND protocols. However, the optimized ND protocol gives a better performance as nodes register their addresses and then sleep which saves nodes power and increase network life time. In Fig. 17, we can see that basic ND consumes power faster than optimized ND. We found that after time unit the network with basic ND already dead, while the network with optimized ND still has 20% of its average power. E. Comparison of Delivery Ratio This experiment aims to assess the delivery ratio between hosts and router when the nodes sleep for periods less than their registration lifetimes. This experiment is to insure that the sleeping process does not affect the delivery ratio of ND control packets. We vary number of hosts in the network for this experiment. Fig. 18 shows that the delivery ratio of ND packets increases by increasing number of nodes in the optimized ND protocol. In contrast, the basic ND protocol delivery ratio decreases when the number of nodes increases. This happens due to the heavy use of multicast messages between network nodes, and the short periods between two successive transmissions of ND messages in the case of the basic RFC 4861 implementation. We conclude from this experiment that the optimized ND protocol consumes energy wisely and optimize the ND packets exchange between hosts and routers in 6LoWPAN networks. F. Impact of Nodes Unreachability Some of the previous results are obtained when the all nodes in the network are assumed to be reachable for all the simulation time. In the case of one of default routers is unreachable as discussed in section IV. C D, the RS message will be retransmitted. NS/NA messages as a part of NUD process are used to update the node neighbor cache. We next study the impact of reachability of the nodes in the network and how it affects the number of ND messages. Fig. 19 shows the total number of ND messages for a range of (100% to 90%) reachability of the nodes.

29 During an hour-long simulation, the host nodes cannot reach its default router for 60*(100-X)/100 minutes, where X is the reachability percentage. Fig. 19 shows the slight increase in the number of ND messages with the decrease in the reachability percentage. The default router unreachability is the main reason for this increase as nodes need to transmit the RS messages in such a case as we mentioned in section C. In addition NS messages will be transmitted as hosts need to update their neighbor cache entries. VI. CONCLUSIONS The basic IPv6 neighbor discovery protocol was designed for traditional IPv6 links. Considering the limited capabilities of devices used in 6LoWPAN, optimized ND protocol is essential to be used in 6LoWPAN networks in order to minimize the IPv6 overhead, save energy, and ensure resource efficiency. In this paper, we have presented a detailed analysis of both the basic and the optimized ND protocols. We have explained the baseline functions of ND, and then we elaborated on the added optimizations such as new registration mechanism, disturbing the context and prefixes over the network. The main contribution of the paper is the first-of-its kind implementation of the optimized ND over Contiki OS 2.7. Simulation results have shown that our implementation enhances the behavior of ND by reducing the number of exchanged ND control messages, reducing the use of multicast messages. Our optimized ND has shown better performance even in case of low reachability (90%). Our implementation has also resulted in enhanced delivery ratio of ND control packets. This enhanced behavior of the optimized ND protocol leads to a better network lifetime, and more energy savings, as the optimized ND protocol allows nodes to sleep without the need to go all over again of ND processes.

30 ND Packets Deleviery Ratio % 100% 98% 96% 94% 92% 90% 88% 86% 84% 82% 80% 78% 76% 74% 72% 70% 100% 100% 100% 100% 96.70% 97.30% 97.63%97.84% 98.2% 98.65% 94.80% 94.36% 94.25% 94.06% 94.01% 93.76% 91.9% 89.50% 88% 78.70% Number of Nodes RFC 6775 RFC 4861 Fig. 18: Delivery ratio of ND protocol packets through Network with different number of host nodes. Total Number of ND messages RFC 6775 RFC 4861 Reachability Percentage Fig. 19: The variable reachability percentage effect on number of transmitted ND messages with 8 host nodes. VII. REFERENCES [1] Gartner Report, Forecast: The Internet of Things, Worldwide, [2] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, Neighbor Discovery for IP version 6 (IPv6), RFC 4861, IETF Network Working Group, Sep [3] Zach Shelby, Carsten Bormann, 6LoWPAN: The Wireless Embedded Internet, November [4] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 Packets over IEEE Networks, IETF Network Working Group,September 2007 [5] Z. Shelby, Ed, S. Chakrabarti, E. Nordmark,and C. Bormann, Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs), RFC6775, Internet Engineering Task Force, Nov [6] J. Hui, P. Thubert, Compression Format for IPv6 Datagrams over IEEE Based Networks,RFC6282S, IETF Network Working Group,September [7] A. Dunkels, B. Grönvall, and V. Thiemo, Contiki a lightweight and flexible operating system for tiny networked sensors, in Proc. of IEEE Workshop on Embedded Networked Sensors, Tampa, FL, Nov [8] S.Thomson,, T.Narten, and T. Jinmei, IPv6 Stateless Address Autoconfiguration, RFC 4862, IETF Network Working Group, Sep [9] T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, IETF Network Working Group, December [10] M. Selim, K. Elsayed, and A. Khattab, Optimized Neighbor Discovery for 6LoWPANs Envrionments, Cairo University Technical Report, Available from: [11] T. Winter and P. Thubert, RPL: IPv6 Routing Protocol for Low power and Lossy Networks, RFC 6550, IETF ROLL, Mar