Skip to content

IPv6 support for the Wiselib

Jump to bottom Edit New page
Dániel Géhberger edited this page May 10, 2013 · 5 revisions

]# Documentation for the 6LoWPAN implementation

This is a short documentation and tutorial for the IPv6 protocol stack which was implemented to The Wiselib under the Google Summer of Code 2012 project.

Further documentation (BSc thesis)

The protocol stack has an exact layer structure as you can see in the figure. The main file of the implementation contains the IPv6Stack, this is the only file which has to be included to an application which uses the IPv6 communication, and the layers can be accessed through this class.

IPV6 stack

On the top of the stack the UDP and the ICMPv6 protocols were implemented as transport layers. The user can communicate with the public functions of these protocols. Under the transport layer, the IPv6 layer could be found which works with standard IPv6 packages. Because of this, it is much easier to implement and use different lower layers, the headers could be compressed (6LoWPAN) or the whole packet could be sent without modification (Uart). In the Wiselib multiple interfaces must be supported. At the moment there are two of them: radio and uart, but the implementation is prepared for easy integration of new ones. Between the IPv6 and the concrete interfaces, there is a manager called InterfaceManager which is responsible for the connectivity of these. The most important interface is the radio. For better and more efficient IPv6 communication the 6LoWPAN adaptation layer stands between the HW Radio and the IPv6. This layer compresses the header of the IPv6 and UDP layers, deals with fragmentation because of the short message support of the 802.15.4 and in mesh-under routing mode the routing is also in this layer. With the uart interface a sensor mote can send and receive information from the 'non-sensor world'. In the stack an UartRadio cares the handling of the HW uart. It receives the information, reserves an IPv6 packet for it and forwards it to the IPv6 layer. For neighbor discovery it provides a special function for border router configuration.

Serial Line IP PC side tool

SLIP documentation (Report)

The implementation has some other files (classes) for data structures and subsidiary functions.

The IPv6Address class represents an IPv6 address. It has setter and getter functions with special constructor calls and the three special addresses can be used (multicast to all nodes, multicast to the routers, unspecified address). This class has a debug function called get_address which constructs a printable string from the IP address and the length of the prefix.

The IPv6Packet class represents a packet in the system. Every IPv6 header section has a setter and a getter. These use the bitwise serialization to write and read the bits into the right positions. The IPv6 checksum generator function is also placed into this class because this way it could be easily accessed from every other class.

The IPv6PacketPoolManager class manages the actual packets in the system. Because dynamic memory allocation is forbidden, a predefined number of packets are available, and a packet must be freed up after the usage. This class can provide a free packet with the number of it in the pool or with a pointer.

The nd_storage.h file contains 6 classes which are related to the Neighbor Discovery function. An interface can be implemented with or without this function, and it must be indicated with a ND_enabled flag in the class. The NeighborCacheEntryType, DefaultRouterEntryType, LoWPANContextType are just types for arrays. The NeighborCache_DefaultRouters class represents the Neighbor Cache and the Default Routers list. The two arrays with predefined sizes, updater functions and getters with different parameters are in this class. The NDStorage class stores some values for the ND messages, and the neighbor cache could be also accessed through this class. The LoWPANContextManager is used only in the 6LoWPAN layer. It stores the contexts for the compression and decompression.

The PrefixType class is used to store the prefixes in the InterfaceManager.

The LoWPANReassemblingManager deals with the reassembling of the 6LoWPAN fragments; it is only used in that layer. It contains a start function, a new fragment handler function, some helper values and a timer. Because fragments could be lost along the communication after a specified time the whole packet must be dropped. The manager can work only with one packet in the same time.

The routing was not part of the project. Because of this, only a SimpleQueryableRouting is provided. This is more a `routing manager' because it can be called by the IPv6 or the 6LoWPAN layer and if the route exists, this class returns the next hop. Otherwise the find function is called asynchronously, and this function represents the actual routing, but for a real implementation maybe other parts will have to be modified.

Tutorial

This is a sort section for the easier usage of the IPv6 stack in the Wiselib.

Debug messages

The debug messages can be enabled for the different layers in the: wiselib.testing/config_testing.h

Initialization

The ipv6_stack.h file contains the instances of the layers. This file must be included into the application:

#include "algorithms/6lowpan/ipv6_stack.h"

The template parameters are the following:

typedef wiselib::IPv6Stack<Os, Radio, Os::Debug, Os::Timer, Uart> IPv6_stack_t;

An IPv6 address type is also needed which could be used as:

typedef wiselib::IPv6Address<Radio, Os::Debug> IPv6Address_t;

The UDP socket type:

typedef wiselib::UDPSocket<IPv6Address_t> UDPSocket_t;

The stack must be initialized in the init function of the application:

ipv6_stack_.init(*radio_, *debug_, *timer_, *uart_);

Sending messages

The destination's IPv6 address must be specified. A new IPv6 address instance is needed for this. The prefix could be the link-local one, which could be set with the make_it_link_local call on the instance. For a global address, the prefix must be specified in a byte array, and it could be placed into the address with the set_prefix call on the instance. The host ID could be short or long. At the moment only the long addresses are used in the system. These are formed from the MAC address provided by the radio. The host ID could be set with the set_long_iid call. The parameter is a MAC address and a flag which indicates that this is a global or link-local address. For a broadcast message, the constant from the ipv6 layer could be used: ipv6_stack_.ipv6.BROADCAST_ADDRESS.

Echo request (ping)

An echo request could be sent with the public ping function of the ICMPv6 layer towards a specified destination. ipv6_stack_.icmpv6.ping( destinationaddr );

UDP message

The application can open a UDP port with the following command:

ipv6_stack_.udp.listen( 61617, callback_id );

The application must create a socket and use this for outgoing UDP datagrams: UDPSocket_t my_socket = UDPSocket_t( 61616, 61617, destinationaddr ); ipv6_stack_.udp.send(my_socket,sizeof(mypayload),mypayload);

Other messages

The sensor motes can send several other types of messages. These are ICMPv6 ones at the moment. These are the echo reply, and the Neighbor Discovery messages. These are sent automatically, no action from the user is required.

Callback functions

Different callback functions could be used for UDP and the ICMPv6 layers:

ICMPv6 layer

From the ICMPv6 layer only the echo reply is passed up for the application. The array contains only one byte, which is the ICMPv6 message code of the echo reply. The IPv6 address of the sender is also provided. callback_id_icmpv6= ipv6_stack_.icmpv6.reg_recv_callback<lowpanApp,&lowpanApp::receive_echo_reply>( this ); void receive_echo_reply( IPv6Address_t from, size_t len, Os::Radio::block_data_t *buf ) { ... }

UDP layer

From the UDP layer, the content of the actual message is passed up for the application. For the size of the array the uint16_t type is used because the size_t which is provided by the radios is not as large as an IPv6 packet could be. callback_id_udp= ipv6_stack_.udp.reg_recv_callback<lowpanApp,&lowpanApp::receive_radio_message>( this ); void receive_radio_message( IPv6Address_t from, uint16_t len, Os::Radio::block_data_t *buf ) { ... }

The following documents were used during the implementation:

Dániel Géhberger - September 2012

Add a custom footer
Add a custom sidebar
Clone this wiki locally