Implementation And Testing Report On Ipv6

Transcript

Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability Grant agreement for: Collaborative project Grant agreement no.: 288445 Start date of project: 1 October 2011 (36 months duration) Deliverable D2.4 Implementation and testing report on IPv6-based IoT6 features for the Service Layer Contract Due Date 30/11/2013 Submission Date 31/01/2014 Version v1.0 Responsible Partner University College London (UCL) Author List Socrates Varakliotis, Peter Kirstein, Rafael Marin-Perez, David Fernandez, Pablo Lopez, Antonio Skarmeta Dissemination level PU Keywords Internet of Things, 6LoWPAN, GLoWBAL, IPv6, API, Digital Object Architectures, Handle System, persistent identifiers, QoS, security, ubiquitous access, scalable and efficient routing, IoT gateways, service networks Project Coordinator: Mandat International (MI) Sébastien Ziegler [email protected] D2.4 Implementation and testing of IPv6-based features Table of Contents 1 Executive Summary ......................................................................................................... 5 2 Introduction ...................................................................................................................... 7 2.1 The Scope of T2.4 ...................................................................................................... 7 2.2 Structure of the Document ......................................................................................... 8 3 6LoWPAN ....................................................................................................................... 10 3.1 Addressing ................................................................................................................ 10 3.2 Input/Output Packet .................................................................................................. 10 3.3 Fragmentation........................................................................................................... 10 3.4 Header Compression ................................................................................................ 11 3.4.1 Compression-related functions ............................................................................. 11 3.5 UDP transport layer .................................................................................................. 12 3.6 API interface for IEEE 802.15.4 technology ........................................................... 12 3.7 Testing of 6LoWPAN. ............................................................................................. 15 4 GLoWBAL-IPv6............................................................................................................. 16 4.1 API interface for IEEE 802.15.4 technology ........................................................... 18 4.2 Implementation of GLoWBAL-IPv6 applications. .................................................. 20 4.3 Evaluation of GLoWBAL-IPv6 ............................................................................... 21 5 IPv6 Addressing Proxy .................................................................................................. 23 5.1 API interfaces for X10, CAN and KNX technologies ............................................. 25 5.1.1 API functions for X10 technology ....................................................................... 25 5.1.2 API functions for CAN technology...................................................................... 26 5.1.3 API functions for KNX technology ..................................................................... 27 5.2 Evaluation of IPv6 Addressing Proxy ...................................................................... 28 5.2.1 Scalability evaluation ........................................................................................... 28 6 Overview of Provision of IoT Services using the Handle System .............................. 30 6.1 Introduction .............................................................................................................. 30 6.2 The Current IoT6 Repositories and Gateways ......................................................... 31 6.3 The Digital Object Identifiers and the Handle System............................................. 31 7 Some Features of the Handle System ........................................................................... 34 7.1 Handles as Persistent Identifiers .............................................................................. 34 7.2 Handle Syntax .......................................................................................................... 34 7.2.1 Handle syntax for IoT applications ...................................................................... 35 7.3 Handle Resolution and relevance to IoT applications .............................................. 36 7.4 Administering Handles – Security Provisions and Implications .............................. 37 7.4.1 Handle security provisions and the IoT................................................................ 39 7.5 Handle System Scalability ....................................................................................... 39 7.5.1 Storage scalability ................................................................................................ 40 7.5.2 Performance scalability ........................................................................................ 41 7.6 Security aspects ........................................................................................................ 42 7.6.1 Authentication ...................................................................................................... 42 7.6.2 Server Certification .............................................................................................. 43 7.6.3 Security Services in Handle ................................................................................. 43 7.7 Handle Value Types ................................................................................................. 43 7.8 Template Handles ..................................................................................................... 46 7.8.1 The Template Delimiter ....................................................................................... 46 8 Digital Objects for the IoT............................................................................................. 48 v1.0 IoT6 D2.4 Page 2 D2.4 Implementation and testing of IPv6-based features 8.1 Use of the Handle System in the IoT ....................................................................... 48 8.2 Gateways and Functional Separation ....................................................................... 49 8.3 DO Registration........................................................................................................ 50 8.3.1 Auto-configuration of IoT services and resources using Handle ......................... 51 9 The Operations in Automated Building Management................................................ 52 9.1 Introduction .............................................................................................................. 52 9.2 SAaaS Operations .................................................................................................... 52 9.3 DO Registration........................................................................................................ 53 9.4 Compound Operations.............................................................................................. 53 9.5 Re-Use of past IoT6 work ........................................................................................ 54 9.5.1 The GLoWBAL-IPv6 protocol and object identifiers.......................................... 54 9.5.2 The Digcovery system and operations with object identifiers ............................. 56 9.5.3 Comparison of Handle System to the DNS system for IoT purposes .................. 56 9.6 Advantages of using Handle in a IoT integration approach ..................................... 58 9.6.1 Global secure service ........................................................................................... 58 9.6.2 Novel business process description ...................................................................... 58 10 Programmability ............................................................................................................ 60 10.1 Clients and the client library .................................................................................... 60 10.2 Batch Processing ...................................................................................................... 60 10.3 HTTP Proxy (REST API) ........................................................................................ 60 10.4 IPv6, REST and Secure access ................................................................................. 61 10.5 Links with the Digcovery System ............................................................................ 62 10.6 Interfacing legacy ABM Systems............................................................................. 62 11 Conclusions ..................................................................................................................... 63 12 References ....................................................................................................................... 64 v1.0 IoT6 D2.4 Page 3 D2.4 Implementation and testing of IPv6-based features Table of Figures Figure 1: JN5139 mote from the Jennic company ................................................................... 15 Figure 2: Sequence diagram of AAID sending module ........................................................... 17 Figure 3: Sequence diagram of AAID receiving module ......................................................... 17 Figure 4: AAID Gateway defined in the multi-protocol card (left) and also based on the IEEE 802.15.4 USB Ethbridge (right). .............................................................................................. 21 Figure 5: Performance evaluation for the AAID mapping in AAID Gateway and AAID node. .................................................................................................................................................. 22 Figure 6: Summary of the mapping performance for 500 sessions.......................................... 22 Figure 7: Multi-protocol card used for the evaluation of IPv6 addressing proxy .................... 23 Figure 8: Evaluation framework of IPv6 addressing proxy ..................................................... 23 Figure 9: Average of times in the IPv6 mapping processing with application or routing modes .................................................................................................................................................. 29 Figure 10: The Handle resolution process................................................................................ 36 Figure 11: Secure end-to-end Handle administration from DeviceNets to the Internet. .......... 39 Figure 12: Logical separation of Handle Service to Servers and Sites .................................... 40 Figure 13: Functional separation of gateways to processes ..................................................... 49 Figure 14: Direct linkage of DOA systems with the IoT ......................................................... 61 List of Tables Table 1: Pre-defined Administrative Types ............................................................................. 44 Table 2: Non-administrative Types .......................................................................................... 45 Table 3: Prefix Handle Values ................................................................................................. 45 v1.0 IoT6 D2.4 Page 4 D2.4 Implementation and testing of IPv6-based features 1 Executive Summary This Deliverable is presented in two parts: The first part evaluates many features of the IPv6 stack, which were implemented in the earlier tasks. In the earlier Deliverables, the developments themselves were described, but their evaluation was minimal. In particular, three developments were examined in the context of their use by the other Work-Packages. The three aspects were: the 6LoWPAN implementation, the GLoWBAL system and the addressing proxy. 6LoWPAN is the network protocol for sending IPv6 packets over IEEE 802.15.4 wireless systems. The implementation used was one that comes with the Contiki release, and we describe the addressing, fragmentation, header compression and API. A particular choice of compression algorithm is recommended resulting in the whole implementation being revised. The GLoWBAL implementation describes how individual session information is maintained between a source node outside the gateway and a 6LoWPAN device. Since resources in the gateway are limited, the tables formed include a time-to-live of each entry. An evaluation of the scalability of the system is given. On a specific platform, the process took about 7ms for each of the three technologies investigated – X10, BACnet and KNX. The IPv6 addressing proxy defines the mechanisms for mapping automatically an IPv6 address as used in IoT6 and the three different legacy technologies used. Here one also evaluated the difference between using a different daemon for each technology, and sharing one for all the technologies. In the evaluation, it was shown that with a common daemon, the time taken to do the mapping in a specific Linux gateway varied between 25 milliseconds and 30 milliseconds for the different technologies. By using separate daemons, this could be cut by 50% - 60%. The second part of this Deliverable is additional to what was promised in the DoW. Since the basic activities contracted had been accomplished (except perhaps a full implementation of secure operation), we decided to step back and consider whether a complete complementary approach might have advantages. In most of the previous IoT6 work, the individual sensors and actuators have been associated with an IPv6 address. It was realised that a key requirement was to associate the device with its resources in a repository, and that a globally distributed name resolution system was needed. Much of the infrastructure for this was provided by the Digcovery system, with the accompanying use of specific repositories and heavy reliance on the DNS – since it was designed to store addresses in a globally distributed and scalable form. Many have considered that one should differentiate between the name and the location of a node. While this differentiation is difficult with the limited address space of IPv4, it becomes more achievable with IPv6. We postulated further that all entities, whether IP addressable or otherwise, should be associated with a name – which for brevity we might call a Handle. By means of a suitable hierarchic structure of the name, one could route to it in the Name Space just as the DNS can be used to devise routes in the address space. This idea was not original; it was initially applied to digital documents by Bob Kahn at CNRI, who has developed a whole Digital Object Architecture (DOA) to deal with such digital objects (DOs). Based on these concepts, CNRI has developed a whole system with several basic components: a Naming Syntax, a Name Resolver, a Registry and links to various repositories. Moreover, a globally distributed implementation of the concept has been deployed with freely available server and client modules. It operates as a global service, and some of its concepts have just been adopted by the ITU in a recent recommendation. Considerable emphasis has been placed on scalability and performance – by replication, caching and clustering. Unlike the DNS, it has employed a strong security infrastructure at all stages of its design and implementation. v1.0 IoT6 D2.4 Page 5 D2.4 Implementation and testing of IPv6-based features Moreover, partially as a result of our on-going discussions with CNRI, the current release has become IPv6-compliant, and the next one will include REST interfaces. The system has been applied mainly to the media and document industry; a study of the system indicates that it is a superb match for the real needs of IoT and, in this respect, we have had strong cooperation from CNRI. Because the concepts are so different from what has been done before in IoT6 WP2, it was necessary to provide an in-depth description of the salient features of the Handle System. We have then shown how its features provide such a good match for the needs of IoT generically. IoT6 has concentrated on Automated Building Management (ABM), so the operations needed in IoT6 and the DOs that can represent ABM devices that can be implemented using the Handle syntax are shown. We then show how functions like the IoT6 addressing proxy and the legacy-dependent sensing and actuation processes can be re-located outside the current gateways – but with in-built security. As a result, these processes should also be locatable in computing clouds; it would then become an optimisation issue of which process must run on local clouds and which can be remote. The detailed validation of this activity will be done in the third year under WP7. The extension of this work to Digital Objects in no way detracts from the essentially IPv6 nature of this project. We do conclude that dealing with identifiers, groups of objects and security are better dealt with in the hierarchic Identifier Name Space than the IPv6 Address Space. Nevertheless, the DOs will always contain IPv6 addresses in their attributes, all communications routing takes full advantage of the benefits that IPv6 gives. This matter is fully explained in the text. v1.0 IoT6 D2.4 Page 6 D2.4 Implementation and testing of IPv6-based features 2 Introduction 2.1 The Scope of T2.4 The DoW is a contractual document, and hence the work described in the DoW is the least that must be covered. At the same time, there are no further Deliverables in this WorkPackage. For this reason, if there are important additional areas of work that come into the general ambit of WP2 and WP3, this is the logical place to report them. This is particularly important if there is work done during the first two years that will be validated in WP7 in the third year. The DoW for Task 2.4 is quite explicit: T2.4: Test and implementation of IPv6 connectivity M13-M26 (Task leader: UCL) This task will work in close cooperation with the WP3 on Open Service Layer. It will integrate and evaluate the mechanisms identified and developed in the previous tasks, which are relevant for the Internet of Things and which could be used by the service layer like: discovery, self-configuration, very large address space, mobility, ubiquitous access, QoS, multicast functionalities, security and authentication. It should provide a coherent and complete stack for the connectivity layer and test it. This description gives the authors problems for several reasons. It was conceived over two years before this task was due to start, and therefore could not envisage the developments which would take place in the first year of the project. Second, much of the integration work was already done in Task T2.3. Finally, while there was an initial interpretation of the DoW, both the needs of the subject and the progress of the project have modified the scope of this Task. Already in the earlier tasks WP2 has worked in close cooperation with the WP3 Open Service Layer. WP2 integrated and evaluated the mechanisms identified and developed in the previous tasks, which are relevant for the Internet of Things and which could be used by the service layer like: discovery, self-configuration, very large address space, mobility, ubiquitous access and multicast functionalities. In Task T2.4 these functions should have been integrated and tested in a stack suitable for WP3. We have gone way beyond that. All except mobility and multicast have been integrated with the services of WP3 and distributed to the partners. They have integrated them with the work of WPs 4-6, and the results were demonstrated already at the second project review. Mobility, multicast and QoS are a little different. In the second review, mobility in the sense of working in a mobile way with mobile telephones was demonstrated. This requires, of course, no features of the IPv6 stack directly. In the DoW, was meant IPv6 Mobile IP (MIP6). In the IPv6 stack, this does not require additional features - except that the mobile node must update its binding with the Care-of Server, which requires IPSec in the standard. It also requires a Server with the Care-of Address feature incorporated. As stated in D2.3, these features are supported in some of the Linux and Contiki stacks used in the project. Multicast does not require anything special in the stack. It is a feature used in many of the basic IPv6 services, and must therefore be supported in the basic stacks. Its features are thus already integrated and tested – though its use in applications has not been explored. QoS is in a different category. In the Year 1 project review, QoS was interpreted as use of the Flow Label, and the work of demonstrating this feature was transferred to Task T3.2 – and was demonstrated in the second project review. v1.0 IoT6 D2.4 Page 7 D2.4 Implementation and testing of IPv6-based features Security is in yet another category. Task T2.2 analysed many of the features required for secure operations, and demonstrated that the low-level algorithms often used could be implemented with TinyOS, the operating system UL was using (not the Contiki used by the other partners in small devices). However, there was no attempt in Tasks T2.2 or T2.3 to implement secure operations in the total system – though there can be a requirement for authentication in the service stack set up for the partners – which we call the IoT6 stack. What was not attempted, and is vital not only for WP2 but for the whole project, is an evaluation of what functions can be enabled by IPv6 that might bring extra value to IoT. Nor has there been earlier in the project a consideration of how the important authentication and authorisation functionality should be provided. It should be emphasised, that these activities are not part of the “IPv6 stack”. The provision of authorisation and security are not particularly impacted by IPv6 – though some functions are facilitated by it. Another requirement highlighted in the Reviewers’ comments at the latest project review was the importance of scalability. One part of this is addressed automatically by the sheer address size of IPv6; however, another is the need for scalability in the salient components. It is the specification of how such security services could be provided in a manner compatible with the rest of the project that is one of the main outcomes of Task T2.4. A discussion of where IPv6 features could facilitate IoT is a secondary outcome. Neither of these impacts the implementation of most of the activities of the other Work-Packages; they require just the stack that they have received from Task T2.3. The provision of services that can be shown to scale is a very important aspect; we show how the solution proposed here achieves also this aim. The activities that we describe here are fitting final activities for WP2. Their validation in the context of specific Use Cases is a subject of the WP7 validation activity. 2.2 Structure of the Document While many aspects of the IPv6 stack were implemented in the earlier Tasks, and in particular Task T2.3, the evaluation of these developments was minimal. In Sections 3-5, we undertake such an evaluation of many of the features that were presented in Task T2.3. This is in strict accordance with the DoW description of Task T2.4. In Section 3 there is an evaluation of the 6LoWPAN implementation, and in Section 4 of the GLoWBAL system. Another aspect was the addressing proxy, and here the evaluation is carried out in Section 5. The remainder of this Deliverable is additional, and is more in the nature of a specification of a Systems Architecture. We postulate in Section 6, that IoT would be particularly well served by considering each end device as a Digital Object (DO). There is already a system called Handle that has defined a Digital Object Architecture (DOA) that has been developed for manipulating DOs securely. In Section 7 we outline the principal characteristics of Handle – including its reliance on a hierarchic structure and its use of a Name Resolver Service (NRS), which is intrinsically involved with Digital Objects and their secure manipulation. There are many other features associated with the Handle System (HS). These include fine-grained security provisions – including secure authorisation to access the resources – and other techniques to secure the administration features of the system. There are other features like templates for constructing Handles of similar pattern. Moreover, the requirements for scalability were envisaged from the outset, and implementation has been designed with the need for clustering the servers from the beginning. Thus, this solution is very capable of being scaled up into very large numbers of components. In Section 8 we then consider how the Handle System can be applied to IoT, and its components. One such component is the sort of complex DO represented by the gateways described in the earlier WP2/WP3 work. We consider in this section how its functionality could be decomposed into separate processes. The Handle System could take over some of the functionality of such components, and could v1.0 IoT6 D2.4 Page 8 D2.4 Implementation and testing of IPv6-based features route any operations to processes that embrace more of the functionality. We consider here also aids to the automatic registration of objects facilitated by the Handle System. The main Use Case pursued in the IoT6 project is Automated Building Management (ABM). Thus it is important to show how Handle would help in the implementation of an ABM management system. In Section 10 we then consider the provisions in the system for programmability, and how this work links in to the previous thread of the IoT6 activity. Here we consider also some of the aspects of Sensing and Actuation as a Service (SAaaS). The Handle Service has been compared to the DNS. There are similarities, but we discuss also the differences. An important aspect is the capability of programmable features of Handle interfaces. In Section 10 these aspects are considered in some detail, and we discuss how activity based on Handle relate on the one hand to HTTP and REST interfaces, on the other the links to previous IoT6 work on Digcovery and legacy ABM systems. Finally, some conclusions are drawn in Section 11. v1.0 IoT6 D2.4 Page 9 D2.4 Implementation and testing of IPv6-based features 3 6LoWPAN 6LoWPAN [1] is a Working Group in IETF which defines the use of IPv6 on IEEE 802.15.4 links. 6LoWPAN has been implemented in several Operating Systems such as Contiki [2]. In particular, Contiki implements addressing, fragmentation, and header compression of 6LoWPAN protocol. The Contiki implementation is based on RFC4944 [3] (Transmission of IPv6 Packets over IEEE 802.15.4 Networks), the Internet draft “Interoperability Test for 6LoWPAN” [4] and the Internet draft “Compression format for IPv6 datagrams in 6LoWPAN Networks” [5]. In the following we describe the 6LoWPAN implementation of addressing, fragmentation, and header compression. 3.1 Addressing In Contiki, 6LoWPAN currently only supports 802.15.4 64-bit addresses based on RFC4944. RFC4944 defines address configuration mechanisms based on 802.15.4 16-bit and 64-bit addresses, fragmentation of IPv6 packets below IP layer, IPv6 and UDP header compression, a mesh header to enable link-layer forwarding in a mesh-under topology, and a broadcast header to enable broadcast in a mesh-under topology. The format of an 802.15.4 address is defined in uip.h with the structure uip_802154_longaddr. The IPv6 local-link addresses of the nodes are determined automatically using Stateless Address Auto-configuration [6]. Each node appends its link-layer 6 bytes address to the locallink network prefix (fe80::0/64). When the function tcpip_process is started, the address configuration is done, followed by some IPv6 ND [7] messages which are exchanged (such as Duplicate Address Detection and Router Solicitation). If a router is present, it may give some extra addresses to the node such as the prefix of global address (aaaa::0/64). In Contiki, the 6LoWPAN implementation can operate with both addressing schemes. 3.2 Input/Output Packet 6LoWPAN is called by the MAC layer when a 6LoWPAN packet is received and by the transport layer when an IPv6 packet needs to be sent. It is initialised from the MAC layer, which calls the function sicslowpan_init (giving as argument a pointer to the mac_driver structure). The main 6LoWPAN functions are implemented in the sicslowpan.h and sicslowpan.c files. They are used to format packets between the 802.15.4 and the IPv6 layers. 6LoWPAN also creates a few IPv6 and link-layer dependencies. At initialisation, the input function in sicslowpan.c is set as the function to be called by the MAC upon packet reception. At packet reception, the link-layer copies the 802.15.4 payload in a memory buffer, and sets its length. It also stores the source and destination link-layer addresses as two networking addresses for sender and receiver. It then calls the sicslowpan_input function. Similarly, when the IPv6 layer has a packet to send over the radio, it puts the packet in the buffer (uip_buf), sets the length(uip_len) and calls the sicslowpan_output function. The output function is set as the tcpip_output function. 3.3 Fragmentation Fragmentation is enabled by setting the SICSLOWPAN_CONF_FRAG compilation option. To support fragmentation, Contiki provides two functions described below: • v1.0 Output function: When an IP packet, after header compression, is too big to fit in an 802.15.4 frame, it is fragmented in several packets which are sent successively IoT6 D2.4 Page 10 D2.4 Implementation and testing of IPv6-based features • over the radio. The packets are formatted as defined in RFC 4944. Only the first fragment contains the IP/UDP compressed or uncompressed header fields. Input function: This function takes care of fragment reassembly. We do not assume that the fragments are received in order. When reassembly of a packet is on-going, we discard any non-fragmented packet or fragment from another packet. Reassembly times out after SICSLOWPAN_REASS_MAXAGE = 20s. As we do not support a complex buffer allocation mechanism, we define for now a new 1280 bytes buffer (sicslowpan_buf) to reassemble packets. At reception, once all the fragments have been received, we copy the packet to the buffer(uip_buf), set the length(uip_len), and call the function tcpip_input. In addition, MAC_MAX_PAYLOAD defines the maximum payload length in an 802.15.4 frame. Currently, it is constant and equal to 102 bytes (the 802.15.4 frame can be maximum 127 bytes long, and the header 25 bytes long). 3.4 Header Compression The implementation supports the header compression scenarios defined in [4]. This defines an interoperability scenario which was used between wireless sensor devices. In [5], it defines a stateful header compression mechanism which should soon deprecate the stateless header compression mechanism defined in RFC4944. It is much more powerful and flexible, in particular it allows compression of some multicast addresses and of all global unicast addresses. The SICSLOWPAN_CONF_COMPRESSION compilation option defines the compression scheme supported. We support HC1, HC01, and IPv6 compression. HC1 and IPv6 compression are defined in RFC4944, HC01 in [5]. What we call IPv6 compression means sending packets with no compression, and adding the IPv6 dispatch before the IPv6 header. If at compile time IPv6 “compression” is chosen, packets sent will never be compressed, and compressed packets will not be processed at reception. If at compile time either HC1 or HC01 are chosen, we will try to compress all fields at sending, and will accept packets compressed with the chosen scheme, as well as uncompressed packets. Note that HC1 and HC01 supports are mutually exclusive. 3.4.1 Compression-related functions When a packet is received, the input function is called. Fragmentation issues are handled, then we check the dispatch byte: if it is IPv6, we treat the packet inline. If it is HC1 or HC01, the corresponding decompression function (uncompress_hdr_hc1 or uncompress_hdr_hc01) is called. When a packet needs to be sent, we try to compress it. If only the IPv6 compression support is enabled, we just add the IPv6 dispatch before the 802.15.4 payload. If HC1 or HC01 support is enabled, we call the corresponding compression function (compress_hdr_hc1 or compress_hdr_hc01) to compress the packet as much as possible. In HC1, if the IPv6 Flow Label is not compressed, we would need to copy the fields after the Flow Label starting in the middle of a byte (the Flow Label is 20 bits long). To avoid this, we compress the packets only if all fields can be compressed. If we cannot, we use the IPv6 dispatch and send all headers fields inline. This behaviour is the one defined in [4]. In the same way, if the packet is an UDP packet, we compress the UDP header only if all fields can be compressed. Note that HC1 can only compress unicast link local addresses. For this reason, we recommend using HC01. v1.0 IoT6 D2.4 Page 11 D2.4 Implementation and testing of IPv6-based features HC01 uses address contexts to enable compression of global unicast addresses. All nodes must share context (namely the global prefixes in use) to compress and uncompress such addresses successfully. The context number is defined by 2 bits. Context 00 is reserved for the link local context. Other contexts have to be distributed within the LoWPAN dynamically, by means of ND extensions yet to be defined. Note that if you want to test global address compression (i.e. 0xaaa::0), you need to configure the global contexts manually. 3.5 UDP transport layer The procedure to send and receive UDP datagrams is very easy. The UDP connection must be filled with the other node's IP address and the destination port used, and the local port number may be specified. Then the functions called are: • • • struct uip_udp_conn * udp_new (const uip_ipaddr_t *ripaddr, u16_t port, void *appstate) o This function creates a new UDP connection. If the connection is used to send data to a specific host, the arguments ripaddr (remote IP address) and port must be filled adequately, otherwise ripaddr may be set to NULL and port to 0 in order to accept any incoming datagram. appstate is a pointer to some data that will be passed to the process when UDP events will occur. The function returns a pointer to the connection that will be used by all the other functions afterward. The function chooses a local port number arbitrarily. udp_bind(conn, port) o This macro binds an open UDP connection to a local port number. The specified port will be the source port used to send datagrams as well as the listening port for incoming datagrams. uip_newdata() o This macro indicates if there is data available on the connection. If so it can be accessed from the pointer uip_appdata and the length obtained by uip_datalen(). 3.6 API interface for IEEE 802.15.4 technology For 6LoWPAN, an API interface is implemented in the api_6lowpan.h and api_6lowpan.c files in the core/net directory. These files provide the API interface for application layer to communicate via 6LoWPAN protocol. The main functions implemented for 6LoWPAN are described below. v1.0 • void api_6lowpan_bindTCPPort (unsigned short port) o This function binds a TCP connection to a local port. This function sets up a new TCP connection. The function will automatically allocate an unused local port for the new connection. The local port number is changed to network byte order.  Parameters: • port The local port number.  Returns: • None. • void api_6lowpan_bindUDPPort( struct uip_udp_conn* conn, short port) IoT6 D2.4 unsigned Page 12 D2.4 Implementation and testing of IPv6-based features o This function binds a UDP connection to a local port. This function sets up a new UDP connection. The function will automatically allocate an unused local port for the new connection. The local port number is changed to network byte order.  Parameters: • conn A pointer to the uip_udp_conn structure for the connection. • port The local port number.  Returns: • None. v1.0 • void api_6lowpan_closeSocketTCP(void) o This function closes a previous IPv6/TCP connection.  Parameters: • None.  Returns: • None. • void api_6lowpan_closeSocketUDP(struct uip_udp_conn * conn) o This function closes a previous IPv6/UDP connection.  Parameters: • conn The UDP connection in a pointer to a structure uip_udp_conn.  Returns: • None. • uip_ipaddr_t * api_6lowpan_getIPv6Address(void) o This function gets the IPv6 address of the node.  Parameters: • None  Returns: • IPv6-address of the node in a structure uip_ipaddr_t. • MAC_ExtAddr_s * api_6lowpan_getLocalAddress(void) o This function gets the local address of the node.  Parameters: • None  Returns: • MAC-address of the node in a structure MAC_ExtAddr_s. • struct uip_conn* api_6lowpan_openSocketTCP(unsigned short address_dst[8], unsigned short port_dst) o This function opens a new socket IPv6/TCP to a destination node. This function is used to start a new connection to the specified port on the specified host. It allocates a new connection identifier, sets the connection to the SYN_SENT state and sets the retransmission timer to 0. This will cause a TCP SYN segment to be sent out the next time this connection is periodically processed, which usually is done within 0.5 seconds after the call to uip_connect().  Parameters: IoT6 D2.4 Page 13 D2.4 Implementation and testing of IPv6-based features •  v1.0 address_dst The IPv6 address of the destination node in an array of unsigned short. • port_dst The port of the destination node. Returns: • The TCP connection in a pointer to a structure uip_conn. • struct uip_udp_conn* api_6lowpan_openSocketUDP(uint16_t * address_dst, uint16_t port_dst) o This function opens a new socket IPv6/UDP to a destination node. This function sets up a new UDP connection. The function will automatically allocate an unused local port for the new connection.  Parameters: • address_dst The IPv6 address of the destination node in an array of unsigned short. • port_dst The port of the destination node.  Returns: • The UDP connection in a pointer to a structure uip_udp_conn. • void api_6lowpan_print_local_ipv6_address(void) o This function prints local IPv6 address.  Parameters: • None.  Returns: • None. • void api_6lowpan_sendTCP(uint8_t * data, uint16_t len) o This function sends data through the current TCP connection.  Parameters: • data A pointer to the array of data. • len The length of data.  Returns: • None. • void api_6lowpan_sendUDP (struct uip_udp_conn * conn, uint8_t * data, uint16_t len) o This function sends data through an UDP connection.  Parameters: • conn A pointer to the uip_udp_conn structure for the connection. • data A pointer to the array of data. • len The length of data.  Returns: • None. • void api_6lowpan_receiveUDP(uint8_t* data, uint16_t uip_udp_conn* conn) o This function receives data through an UDP connection.  Parameters: IoT6 D2.4 len, struct Page 14 D2.4 Implementation and testing of IPv6-based features •  • conn A pointer to the uip_udp_conn structure for the connection. • data A pointer to the array of data. • len The length of data. Returns: • None. void api_6lowpan_setIPv6Address(uint16_t * address) o This function sets the IPv6 address of the node.  Parameters: • The IPv6 address in an array of unsigned short.  Returns: • None. 3.7 Testing of 6LoWPAN. To test 6LoWPAN, two applications are provided in the client-api-6lowpan-testing.c and server-api-6lowpan-testing.c files in the apps/app-api-6lowpan directory. The client application sends periodic messages to the server device using the IPv6/UDP connection. The server application receives and processes packets from the client device using the IPv6/UDP connection. The evaluation of the 6LoWPAN protocol is performed by two JN5139 devices [8] from the Jennic company with 802.15.4 radio as shown in the next figure. The server application starts in the process definition. First a UDP connection is created, specifying remote IP address and port as 0, indicating it's a listening connection. Then the local UDP port is bound to 50000, which means the connection listens on that port. Finally, an infinite loop is entered waiting for TCP/IP events, and calling a handler function when these occur. Figure 1: JN5139 mote from the Jennic company When the server receives data from the client, the handler function checks if new data is available from the buffer uip_buf. If so, it prints the received data for debug as well as the sender IP address and port, then prepares a response datagram. The connection information must be updated in order to send the response to the emitter of the message. Therefore, the ripaddr and rport fields of the UDP connection structure are filled with the sender information extracted from the received IP packet. Then the function for sending the packet is invoked. Finally the UDP connection structure is updated back to its original state (with remote IP address and port set to 0) in order to be able to receive datagrams from any host. v1.0 IoT6 D2.4 Page 15 D2.4 Implementation and testing of IPv6-based features 4 GLoWBAL-IPv6 The GLoWBAL-IPv6 protocol has been proposed to provide for an Access Address/Identifier (AAID) which simplifies every parameter from IPv6 communications (source and destination address/port, 36 bytes) in a single 4-byte communication identifier. Thus, the 41 bytes from the IPv6/UDP headers based on 6LoWPAN with global IP addressing can be significantly reduced. This achieves an effective frame format for global communications, and also a mechanism to support global communications in networks that do not have native support for IPv6. The details of the protocol have been fully described in [9]. This section describes the implementation of GLoWBAL-IPv6 using the Jennic JN5139 platform with 802.15.4 radio. In addition, a Jennic USB ethbridge acts as AAID gateway to collect all the received packets for AAID nodes through its 802.15.4 radio and manages the traffic from Internet network via a USB port that emulates an Ethernet interface. In GLoWBAL-IPv6, each Jennic device implements a table L2G that allows saving a maximum of MAX_AAID_ENTRIES. When the table L2G is full then the new AAID entry is discarded. For avoiding this failure situation, each AAID entry has a maximum time to be stored in the table before it is removed. Moreover, the tableL2G prevents AAID duplicates because the hash function generates the same AAID identifier for different connections of IPsource, IP-destination, Port-source and Port-destination. Here, we introduce the most common fields of each entry in the L2G table: IP6_SRC: IPv6 address of the source node. IP6_DST: IPv6 address of the destination node. PORT_SRC: 16-bits port of the source node. PORT_DST: 16-bits port of the destination node. AAID: 32-bits identifier of the access address. TIMEOUT: maximum time after removing the AAID entry. In additional, Jennic devices employ three types of packets to guarantee a reliable wireless communication between an AAID node and an AAID gateway over 802.15.4 wireless technology. DATA: packets for sending the data payload of an application. This contains AAID dispatch, AAID identifier and payload. ACK: packets for confirming the reception of SETTING and DATA packets. This contains an error code if there is some failure in the communication between the AAID node and AAID Gateway. SETTING: packets for establishing a new AAID entry for a session between a source node of 802.15.4 network and a destination node of Core network. This contains AAID dispatch, AAID identifier and inline fields of IP-source, IP-destination, Port-source and Portdestination. Below we describe the functionalities of each AAID node. Its operation is divided in the following modules two modules: Sending Module: This module sends the data payload required by an application layer via the 802.15.4 radio interface. First, it checks that the AAID identifier is previously used and available in its L2G. Otherwise, a setting packet is transmitted to include the AAID identifier in the L2G mapping table of the AAID Gateway. v1.0 IoT6 D2.4 Page 16 D2.4 Implementation and testing of IPv6-based features Figure 2: Sequence diagram of AAID sending module Receiving Module: This module manages the packets received by each Jennic device using 802.15.4 radio interface. It indicates the three types of packets according to the AAID entries stored in its table L2G. This checks the possible error in the AAID communication such as duplicated AAID, no-stored AAID and full table L2G. Figure 3: Sequence diagram of AAID receiving module Here we describe the functionalities of the AAID Gateway. Its operation is divided in the following modules two modules: Native-network Module: This corresponds with the module allocated in the Jennic-USB ethbridge to manage the traffic generated from the native devices with the AAID technology v1.0 IoT6 D2.4 Page 17 D2.4 Implementation and testing of IPv6-based features support to the Core Network. This identifies and knows deeply the connection and session information for each device, since this manages the L2G table. This module hears the radio transmission, in this case IEEE 802.15.4 technology. This checks that the AAID is previously used and available in the L2G, or it is a set message and requires including in the L2G mapping table. Core-Network Module: This is also allocated in the Jennic-USB ethbridge to manage the incoming traffic from the Core Network to the specific technologies and specifications. This module is an application, which is listening in promiscuous mode the messages received from the global network via the USB port. Once a message is received, this receiver maps the IPv6 destination address to the correspondent AAID and follows the mapping specifications in order to detect if this is from a previous session, or it is required to set up a new AAID. Then, the ethbridge manages the AAID communication with the AAID node specified with the IPv6 destination address. 4.1 API interface for IEEE 802.15.4 technology For GLoWBAL-IPv6, an API interface is implemented in the api_glowbalip.h and api_glowbalip.c files in the core/net directory. These files provide the API interface for application layer to communicate via GLoWBAL-IPv6 protocol. The main functions implemented for GLoWBAL-IPv6 are described below. v1.0 • uint32_t api_glowbalip_calculateAAID (uip_ip6addr_t * ip6addr_src, uip_ip6addr_t* ip6addr_dst, uint16_t port_src, uint16_t port_dst) o This function receives data through an AAID connection.  Parameters: • aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.  Returns: • None. • bool api_glowbalip_closeSocketAAID(uint32_t aaid) o This function closes a previous IPv6/AAID connection. This receives as parameter the AAID identifier of the opened connection.  Parameters: • aaid The AAID identifier of the connection.  Returns: • bool. TRUE indicates all right. FALSE indicates a wrong AAID identifier. • uip_ip6addr_t * api_glowbalip_getDestinationAddress(uint32_t aaid) o This function gets the source IPv6-Address of the specific AAID connection.  Parameters: • aaid The AAID identifier of the connection.  Returns: • The IPv6 Address of my Jennic mote. • uint16_t api_glowbalip_getDestinationPort(uint32_t aaid) o This function gets the destination Port of the specific AAID connection. IoT6 D2.4 Page 18 D2.4 Implementation and testing of IPv6-based features   • uip_ip6addr_t * api_glowbalip_getIPv6Address(void) o This function gets the IPv6 address of the node. It has not any input parameter and returns the IPv6 address of the device.  Parameters: • None  Returns: • IPv6-address of the node in a structure uip_ip6addr_t. • MAC_ExtAddr_s * api_glowbalip_getLocalAddress(void) o This function gets the local address of the node. This has not any input parameter and returns the MAC-layer address of the device (i.e. EUI-64 identifier).  Parameters: • None  Returns: • MAC-address of the node in a structure MAC_ExtAddr_s. uip_ip6addr_t * api_glowbalip_getSourceAddress(uint32_t aaid) o This function gets the source IPv6-Address of the specific AAID connection.  Parameters: • aaid The AAID identifier of the connection.  Returns: • The IPv6 Address of the Jennic mote. • v1.0 Parameters: • aaid The AAID identifier of the connection. Returns: • The Port of my Jennic mote. • uint16_t api_glowbalip_getSourcePort(uint32_t aaid) o This function gets the source Port of the specific AAID connection.  Parameters: • aaid The AAID identifier of the connection.  Returns: • The Port of my Jennic mote. • void api_glowbalip_init(void) o This function initialises all modules of GLoWBAL-IP communications.  Parameters: • None.  Returns: • None. • uint32_t api_glowbalip_openSocketAAID (uip_ip6addr_t* ip6addr_src, uip_ip6addr_t* ip6addr_dst, uint16_t port_src, uint16_t port_dst) o This function opens a new socket IPv6/AAID to a destination node. This function sets up a new AAID connection. The function will automatically allocate an unused local port for the new connection.  Parameters: IoT6 D2.4 Page 19 D2.4 Implementation and testing of IPv6-based features •  address_dst The IPv6 address of the destination node in an array of unsigned short. • port_dst The port of the destination node. Returns: • The AAID identifier of the connection. • bool api_glowbalip_sendAAID(rimeaddr_t * rimeaddr_dst, uint32_t aaid, uint8_t * data, uint16_t len) o This function sends data through an AAID connection. This has three input parameters for indicating the AAID identifier of the opened connection, the payload and the length to transmit. rimeaddr_dst must be the MACAddress of the ethbridge-mote if the destination node is outside the local area network. rimeaddr_dst must be the MAC-Address of the Destinationmote if the destination node is inside the local area network.  Parameters: • rimeaddr_dst The MAC-Address of the next-hop mote. • aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.  Returns: • bool. TRUE indicates all right. FALSE indicates a wrong AAID identifier. • void api_glowbalip_receiveAAID(uint32_t aaid, uint8_t *data, uint16_t len) o This function receives data through an AAID connection.  Parameters: • aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.  Returns: • None. • void api_glowbalip_setIPv6Address(unsigned short address[8]) o This function sets the IPv6 address of the node. It has one input parameter with the MAC-layer address of the device (i.e. EUI-64 identifier).  Parameters: • The IPv6 address in an array of unsigned short.  Returns: • None. 4.2 Implementation of GLoWBAL-IPv6 applications. For GLoWBAL-IPv6, two applications were implemented in the client-api-glowbaliptesting.c and server-api-glowbalip-testing.c files in the apps/app-api-glowbalip directory. The client application sends periodic packets to the server device. The server application receives and processes data frames from the client device. In addition, a GLoWBAL-IPv6 ethbridge is implemented to make the integration of sensor networks easy. The ethbridge builds a bridge between a IEEE 802.15.4 wireless sensor v1.0 IoT6 D2.4 Page 20 D2.4 Implementation and testing of IPv6-based features network and Ethernet-based LAN infrastructures. It offers a USB CDC Ethernet interface, and an IEEE 802.15.4 compliant radio interface. Plugged into the USB port, it emulates a serial communication port for communication with the radio interface on the device. The ethbridge is freely programmable using the Contiki Operation System including the GLoWBALIP/IPv6 dual-network stack: the GLoWBAL-IP stack for communicating with devices in the wireless sensor network and the IPv6 stack for communicating through the Ethernet to any IPv6 machine. The ethbridge receives messages from Jennic nodes using the GLoWBAL-IPv6 protocol and resend via USB-Ethernet in IPv6 protocol. The ethbridge receives messages from the PC daemon using the IPv6 protocol and resend via IEEE 802.15.4 in the GLoWBAL-IPv6 protocol. The ethbridge also processes Neighbour Solicitation messages from PC daemon using Neighbour Discovery protocol and resend Neighbour Advertisement. The GLoWBALIPv6 ethbridge is implemented in the ethbridge-glowbalip.c file in the apps/app-ethbridgeglowbalip directory. 4.3 Evaluation of GLoWBAL-IPv6 To evaluate GLoWBAL-IPv6, an AAID Gateway was deployed in a multi-protocol based on an ARM CPU and an embedded Linux OS, and also in an IEEE 802.15.4 USB ethbridge based on the Jennic JN5139 chip. Figure 4: AAID Gateway defined in the multi-protocol card (left) and also based on the IEEE 802.15.4 USB Ethbridge (right). The platform for the AAID Gateway is presented in the left of the figure. It is based on the 32 bit processor ARM9@400Mhz, with 256MB LPDDR RAM memory, and 256MB NAND memory, which supports Linux OS. This offers an Ethernet 10/100Mbps (A), 2 USB 2.0 ports (B), 4 Serial RS232 ports (C), Bluetooth 2.1 with HDP profile compliant with BlueGiga (D), GPRS from WaveCom (E), IEEE802.15.4 ZigBee from Jennic (F), 24 inputs/outputs among digital/analogue/relays (G), a compact flash support for data logging (H), and a touch screen LCD (I). Finally, other interesting capabilities include continuous sensing such as real-time watch, 5 high precision timers, 2 analogue/digital converters for analogue signal processing, a random number generator for security seeds, and IPv6 stack support. In addition, the USB ethbridge node is shown in the right of the figure. It is based on the Jennic JN5139 module. This also has a 32-bit processor OpenRISC. This supports the IEEE802.15.4 stack, and ZigBee Pro. It is also possible to set it up with 6LoWPAN, but for this evaluation it has been defined with the basic IEEE 802.15.4 stack. This is connected to the PC through the USB port. Thereby, it is easily programmable and allows debugging the results through the emulated serial port. In the following, we present the evaluation carried over this platform, where the AAID approach has been implemented. v1.0 IoT6 D2.4 Page 21 D2.4 Implementation and testing of IPv6-based features The GLoWBAL-IPv6 protocol was evaluated by measuring the performance and scalability of this system and the interactivity and mapping process between the AAID node and the AAID Gateway over the IPv6 network of the University of Murcia. The AAID mapping performance has been evaluated in the above-mentioned multi-protocol card. This multiprotocol board is in charge of mapping between the multiple technologies and its corresponding IPv6 addresses and vice-versa. In the AAID node, the incoming packets are pre-analysed to determine the session from the coming packet, and post-processed in order to include the AAID information to the payload. The mapping process has been evaluated with a flow of packets between a server host and an AAID node with 500 consecutive requests (each one with different port). Over this evaluation, it has been calculated the total time for processing the mapping and the reply. Therefore, it is calculated the transmission time as the difference between the total time, and the time calculated locally in the AAID Gateway and AAID node for the processing. The result is divided by 2, in order to consider only the time for transmission in one way, not for the full round-trip. The results are presented in the next figure; As mentioned the data presentation distinguishes between the processing in the AAID Gateway, the processing in the AAID node and the oneway transmission time (half of the round-trip transmission time). Figure 5: Performance evaluation for the AAID mapping in AAID Gateway and AAID node. In addition, a summary of the results are shown in the following table, in which the minimum, maximum, and average for each one of the times considered is calculated. The mapping processing does not introduce a high delay. Figure 6: Summary of the mapping performance for 500 sessions. Specifically, the mapping processing in the AAID gateway is practically instantaneous, and it is only a little bit higher in the AAID node. This also presents an average time of 22 milliseconds. Therefore, it is totally suitable to carry out this mapping processing. Note that the transmission times are low, since it was evaluated with a server located at the same network. v1.0 IoT6 D2.4 Page 22 D2.4 Implementation and testing of IPv6-based features 5 IPv6 Addressing Proxy The IPv6 addressing Proxy [11] has been implemented in a multi-protocol card which is presented below. Figure 7: Multi-protocol card used for the evaluation of IPv6 addressing proxy This multi-protocol card is based on the Atmel ARM9 processor running at 400MHz (32-bit) with 256MB LPDDR RAM and 256MB NAND memory, which supports Linux OS. This board supports, through its extension interfaces (serial RS232 and SPI ports), the technologies for industrial and building automation. More specifically, the extension interfaces support Control Area Networks (CANs), X10 and European Industrial Bus (EIB)/Konnex (KNX). This multi-protocol board is in charge of mapping between the multiple technologies and their corresponding IPv6 addresses and vice-versa (see the next deployment scenario). Figure 8: Evaluation framework of IPv6 addressing proxy The implemented scenario is composed of the following software modules and clients: Transceiver Driver: Software in the multi-protocol card manages the traffic generated from the legacy technologies to the Core Network. This software identifies and has detailed knowledge about the node’s technology. This is needed to build the IPv6 address following the mapping techniques presented in D2.1. The software listens to the native interfaces in v1.0 IoT6 D2.4 Page 23 D2.4 Implementation and testing of IPv6-based features accordance with the technology used for each device (e.g. X10, EIB/KNX, CAN), i.e. Serial Ports. Receiver Module (Daemon): Software in the multi-protocol card manages the incoming traffic from the Core Network to the specific sensor system. This software listens for messages sent by the Clients. Once a message is received, this receiver decodes the IPv6 destination address and technology. It follows the mapping specifications in order to make a message in the format of the requisite technology. Remote Client Application: A client in this infrastructure is some device which is received information about a sensor located e.g. a remote server. This client has two options. On the one hand, it can be aware of the mapping and try to understand the native features of the device from a transformation of the IPv6 address information related to the technology being used. On the other hand, a recommended option is to abstract data from the technology and to define homogeneous Web Services based on RESTful/CoAP. Now, we will focus on an explanation of the mapping processing in the Receiver module (daemon). First, this defines the function checking technology. Its operation will depend on where the technology id is allocated. Second, the Receiver knows with which technology should be used in the mapping processing. In the mapping process, it is necessary to take care of some typical situations in the IPv6 parsing: A field is set to 8 bits, corresponding to a complete byte. This case is the easiest, and we only have to check the value of this byte. A field is set to a number of bits smaller than 8 within a byte. In order to extract it, a division is needed and we will obtain the value if it is at the beginning or a module operation will be necessary if it is at the end of the byte. A field is set in different bytes. In this case, we will need to obtain the value of each one and to do a multiplication for the corresponding power of 2 in each byte. A field is set in two different bytes, so we need to extract the corresponding part of each byte and reset the value of each part in their proper proportion. The most complex case is the mapping specification. In order to decrease the delay and increase the scalability of the mapping processing, multiple daemon can be defined with each listening to a different interface, rather than having only one daemon listening to every request on one network interface. For that reason, the possibility of discriminating the technology at the network layer instead of the application layer was considered. The best case for this routing-based discrimination would be if the ISP provides us with an IPv6 network with 48 bits of netmask. In this case, we would be able to set up different networks and a virtual interface for each network could be set up. In this scenario, the kernel is in charge of managing the routing of the message to the correct interface. To take full advantage of this scheme, in our case we had to set up 3 daemons, one for each technology. This is because a daemon can listen only to one sub-network. Indeed, we might even need to define multiple daemons to one technology, carrying out a division per line, in order to increase the scalability. Here we note that in the future it will be possible to process the daemons in a parallel architecture (multiple CPUs). In the case of only one daemon for all the technologies, it will need to check which technology is being used in the mapping. This is because potentially there can be requests from different technologies. Below, a performance evaluation comparing the two approaches is presented. v1.0 IoT6 D2.4 Page 24 D2.4 Implementation and testing of IPv6-based features For that reason, this evaluation is focused on: the evaluation of the overload and processing time required for the IPv6 addressing proxy through the mean time for the translation from each independent receiver module for each technology, and on an evaluation about the scalability through the performance with a flow of requests in order to evaluate, which of the approaches is more relevant, a common daemon or a daemon for each sub-network/interface. 5.1 API interfaces for X10, CAN and KNX technologies For IPv6 Addressing Proxy, an API interface is implemented for each technology. These implementations provide the interface for the application layer to establish IPv6 communication via the addressing proxy protocol. In the next subsection, the main functions implemented for each technology are described. 5.1.1 API functions for X10 technology • uint8_t* api_proxy_getAddress_x10(void): o This function gets the X10 address of the device.   Parameters: • None Returns: • The identifier of the X10 device. • int api_proxy_send_x10(struct x10_mapping* x10_addr, uint8_t * frame, uint16_t len): o This function sends a data frame to a local X10 device.   Parameters: • X10_addr The X10 address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit. Returns: • The result of the function. • void api_proxy_receive_x10(struct x10_mapping* x10_addr, uint8_t * frame, uint16_t len): o This function receives a data frame from a local X10 device.   Parameters: • X10_addr The X10 address of the source device. • frame The pointer of the data frame. • len the length of the frame received. Returns: • None • int api_proxy_parse_ipv6_to_x10(struct in6_addr* ip, struct x10_mapping * x10_addr): o This function converts the global IPv6 address of a node to its local X10 address.  v1.0 Parameters: • X10_addr The identifier of the X10 device • ip The IPv6 address of the X10 device IoT6 D2.4 Page 25 D2.4 Implementation and testing of IPv6-based features  Returns: • The result of the function • int api_proxy_parse_x10_to_ipv6(struct in6_addr* ip): x10_mapping * x10_addr, struct o This function converts the local X10 address of a node to its global IPv6 address. This combines the local X10 address with a pre-established prefix for the X10 technology.   Parameters: • X10_addr The identifier of the X10 device • ip The IPv6 address of the X10 device Returns: • The result of the function. 5.1.2 API functions for CAN technology • uint8_t* api_proxy_getAddress_can(void): o This function gets the CAN address of the device.   Parameters: • None Returns: • The identifier of the CAN device. • int api_proxy_send_can(struct can_mapping* can_addr, uint8_t * frame, uint16_t len): o This function sends a data frame to a local CAN device.   Parameters: • can_addr The CAN address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit. Returns: • The result of the function. • void api_proxy_receive_can(struct can_mapping* can_addr, uint8_t * frame, uint16_t len): o This function receives a data frame from a local CAN device.   Parameters: • can_addr The CAN address of the source device. • frame The pointer of the data frame. • len the length of the frame received. Returns: • None • int api_proxy_parse_ipv6_to_can(struct in6_addr* ip, struct can_mapping * can_addr): o This function converts the global IPv6 address of a node to its local CAN address. v1.0 IoT6 D2.4 Page 26 D2.4 Implementation and testing of IPv6-based features   Parameters: • can_addr The identifier of the CAN device • ip The IPv6 address of the CAN device Returns: • The result of the function. • int api_proxy_parse_can_to_ipv6(struct in6_addr* ip): can_mapping * can_addr, struct o This function converts the local CAN address of a node to its global IPv6 address. This combines the local CAN address with a pre-established IPv6prefix for the CAN technology.   Parameters: • CAN_addr The identifier of the CAN device • ip The IPv6 address of the CAN device Returns: • The result of the function. 5.1.3 API functions for KNX technology • uint8_t* api_proxy_getAddress_knx(void): o This function gets the KNX address of the device.   Parameters: • None Returns: • The identifier of the KNX device. • int api_proxy_send_knx(struct knx_mapping* knx_addr, uint8_t * frame, uint16_t len): o This function sends a data frame to a local KNX device.   Parameters: • knx_addr The KNX address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit. Returns: • The result of the function. • void api_proxy_receive_knx(struct knx_mapping* knx_addr, uint8_t * frame, uint16_t len): o This function receives a data frame from a local KNX device.   Parameters: • knx_addr The KNX address of the source device. • frame The pointer of the data frame. • len the length of the frame received. Returns: • v1.0 None IoT6 D2.4 Page 27 D2.4 Implementation and testing of IPv6-based features • int api_proxy_parse_ipv6_to_knx(struct in6_addr* ip, struct knx_mapping * knx_addr): o This function converts the global IPv6 address of a node to its local KNX address.   Parameters: • knx_addr The identifier of the KNX device • ip The IPv6 address of the KNX device Returns: • The result of the function. • int api_proxy_parse_knx_to_ipv6(struct in6_addr* ip): knx_mapping * knx_addr, struct o This function converts the local KNX address of a node to its global IPv6 address. This combines the local KNX address with a pre-established IPv6prefix for the KNX technology.   Parameters: • knx_addr The identifier of the KNX device • ip The IPv6 address of the KNX device Returns: • The result of the function. 5.2 Evaluation of IPv6 Addressing Proxy For determining the processing time for the mapping process itself the mean time for the mapping process was determined. The time difference introduced by the addressing proxy in the mapping process presents a mean time of 7.89 milliseconds for X10, 7.74 milliseconds for CAN and 7.05 milliseconds for EIB/KNX. The little differences are mainly due to the involved mathematical operations which introduce some complexity into the mapping operation. 5.2.1 Scalability evaluation For the scalability evaluation of the IPv6 Addressing Proxy, multiple requests from a remote client were generated. Specifically, 900 consecutive requests were arranged (300 for each technology). The times are averages from the 900 requests in a window time of one minute in order to evaluate the scalability of the buffers. v1.0 IoT6 D2.4 Page 28 D2.4 Implementation and testing of IPv6-based features Figure 9: Average of times in the IPv6 mapping processing with application or routing modes This figure presents a comparison between the solution based on application (1 daemon) and routing mode (3 daemons). This shows a considerable reduction of the time. Clearly the routing mode from the Linux Kernel offers a more scalable solution than management at the user level, because it allows the multiple processing of packets with independent interrupts. In addition, this reduces the requirements for local buffers for queues. In the future, there could be further reduction by using platforms with multiple-cores for parallel processing. v1.0 IoT6 D2.4 Page 29 D2.4 Implementation and testing of IPv6-based features 6 Overview of Provision of IoT Services using the Handle System 6.1 Introduction In the IoT6 project, interesting and relevant work has been done on gateways, repositories and IPv6. While the context has been Automated Building Management (ABM), many of the considerations are more general. In the next few sections, we describe a further development which has important deviations from the previous work. Particularly in ABM, but also in many other applications, there are major legacy sensor and actuation systems. Conventionally these had only local control interfaces, but more recently they have added Internet interfaces (currently only IPv4). These normally just export the local operations to ones that can be done over a network. While we would like to replace such systems by ones completely suited to the Internet, this will not happen rapidly. These systems we call DeviceNets, and their communications often does not use Internet technology. There has been a trend to try to put gateways in front of such controllers to translate between technology-independent operations, and the ones required by the specific technology. In the IoT6 project, we have put interfaces not only to such legacy systems, but also to IPv6 sensor/actuator systems running IPv6 and 6LoWPAN in the end-systems. It has become clear that the number of end-systems that will need to be accessed over the Internet is very large – too large to be accommodated by the IPv4 address space. Moreover, the environments of the sensor/actuator systems may well be multiple-purpose, making wholesale use of NATs and IPv4 addressing impractical. For this and other reasons, we have postulated, for many IoT environments a network scene with three levels: the General Internet, the ServiceNet and the DeviceNet. The first is self-explanatory; we think it will eventually become IPv6, but that may take time. The third is the set of networks we have been describing before – which may not even be using IP internally. The second one is where the domain-specific IoT adaptation is carried out. For many environments, the ServiceNet is specific to a particular application and can be assumed IPv6 – but while this would be an advantage, it is not essential. We have known in the past that IoT has other differences from the Internet. The importance of binding Names to IP addresses has been realised for the last 30 years, when the Domain Name System (DNS) was introduced. However, while the importance of a global DNS was realised, its functionality is rather limited by its original design objectives suited to the early Internet, where the main resources (data types) to be resolved were IPv4 addresses and names. In the IoT, we need much fuller descriptions of resources, so that digital entities (digital objects) and resource repositories become a vital ingredient. The repositories must be easy to access, and to search. For many purposes the eventual output is then the address that must be used for an operation (either in numerical IP-like form for a host/interface, or as a URI or equivalent notation for a service). A third difference in IoT is the fine-grained nature of the authorisation required. The importance of security in the Internet has long been realised, but in the conventional Internet the authorisation required is often much more coarse-grained, and the devices themselves are more powerful and able to implement the precautions required. In this second part of the deliverable, an overview is provided of a different approach to the IoT problem, which also serves as an evaluation, validation of IoT6 concept and significant v1.0 IoT6 D2.4 Page 30 D2.4 Implementation and testing of IPv6-based features extension to the previous output of WP2. An overview of the approach is provided in this section; more details on specific aspects are provided in the later sections. We will describe briefly in Section 6.2 what has been done in IoT6 to address some of these issues. In Section 6.3 a more radical approach is introduced – a Digital Object Architecture as exemplified by the Handle System that has been developed by CNRI. Most of the contents of this section are expanded in the subsequent sections. In Section 7 we delve deeper into some design features of the Handle System. In Section 8, we will then show how the concepts of DOA and their Handle System instantiations are important for IoT. In particular, in Section 8.2 we consider how gateways should be designed, and in Section 8.3 object registration is presented. Section 9 re-approaches the main Use Case scenario of IoT6 (Automated Buildings Management) in light of the developments discussed in Sections 6-8. In Section 9.5 we validate previous output of IoT6 and examine more generic approaches to GLoWBAL and the IPv6 addressing proxy for the IoT. Finally, Section 10 details programmatic access to Handle and its fit for IoT applications. 6.2 The Current IoT6 Repositories and Gateways In the 2nd year, a considerable effort has been made to make optimum use of IPv6. Thus every device in the DeviceNet is associated with an IPv6 address. This allows extensive use of a particular Service Resolution System called Digcovery to access specific local repositories, and then use the DNS to resolve commands towards specific IPv6 locations by a mapping of legacy systems identifiers with such addresses called GLoWBAL-IPv6 [9]. The translation between these IPv6 addresses and the native addresses needed for specific technologies is carried out in gateways. A special protocol mDNS [10] has been developed to ensure that the translation can be done unambiguously for each technology. This permits DNS to be used consistently throughout address resolution, and the related protocol DNS-SD to be employed for Service Discovery. The IPv6 address proxying mechanism has been described earlier in this deliverable as well as in [11]. The capabilities of the end-hosts and resources they support and operations allowed on them are described by entries in the Digcovery System. Security is provided by limiting access to the Digcovery System by passwords. A more detailed description of the Digcovery system is given in deliverable D3.3, including its limited security provisions (most of them inherent by design of the DNS subsystem that underlies it). Because of the limited syntax capabilities of DNS, and the monolithic concept of the gateways, it is difficult to provide very fine-grained security in systems of this type. There are good facilities in the DNSSEC extension of the DNS for ensuring that DNS entries are trustworthy; these were recognised many years ago and have been well designed and implemented. Authorisation is required for creating, deleting or replicating entries. The integrity of the responses is guaranteed by the protocol. However, there is no need for authorisation in accessing the DNS and searching it for entries. Nor do DNS mechanisms protect any of the processes pointed to from its entries being used in an unauthorised manner. These are not accidental deficiencies of the DNS system; they were deliberately introduced to ensure the universality and speed of access of the total system. 6.3 The Digital Object Identifiers and the Handle System Rather than base identifiers on IPv6 addresses, it is more general to define Digital Objects. A digital object has a machine and platform independent structure that allows it to be identified, accessed and protected, as appropriate. Digital Objects have Identifiers, called Digital Object Identifiers. Bob Kahn, under whose aegis the DNS was developed while he was Director of v1.0 IoT6 D2.4 Page 31 D2.4 Implementation and testing of IPv6-based features the relevant DARPA office, has developed the Digital Object Architecture (DOA), which provides a means of managing digital information in a network environment. The DOA enables interoperability across heterogeneous information systems. With the considerations described in Section 6.1 regarding the network environments that the IoT6 project is trying to address in its DoW, we deduce a number of desirable properties for the network infrastructure to support the IoT: 1. A complete separation of Name and Network Address. The routing by Name may be through a complete application-domain-specific structure which has nothing to with any network topology. 2. Multiple Names for the same end-system. Thus one can choose to locate different network addresses with each name and use conventional routing techniques to access it. 3. Both the Name and the Address syntax hierarchic. The former to allow various application-domain forms of logical routing; the second to allow physically efficient forms of access. 4. The capability of authorisation (with fine-grained access permissions) based on strong-authentication techniques on the Name resolution of any node of the Name hierarchy. The Name Resolver should also be capable of high performance, and minimal or no limit on extensibility and capacity. The Name Resolution service should also be globally distributable. 5. The capability of having multiple names for a DO. This will automatically allow, in view of (4), different authorisations based on the logical path. It will also allow different attributes to be associated with each Name of the DO. (An example would be that an ABM component like a HVAC might have one Name for the occupant of the room; another for the buildings manager, and yet a third for the service engineer who may need to probe into the interior of the HVAC). 6. An extendable syntax of attributes associated with a Name. 7. A recursive capability, so that one of the attributes associated with a Name could be another Name. 8. Use of caching in clients to avoid unnecessary duplication of effort for Name Resolution and Access. In view of the requirement for security, the lifetime of caches must be limitable. 9. One or more repositories associated with a Name. There may be several, for instance one may represent static information, requiring only comparatively slow access and secure, even slower, update capability; another may hold transitory status information that requires less security and much faster update capability. There are almost certainly many other properties required, and many implementations satisfying these may exist. The DNS system meets many of them – but not (1), (3) and (4). The CNRI [15] group, led by Kahn, developed the Handle System (HS) [12] as one component of the DOA just to handle such DOs and DOIs because the DNS syntax was too limited. The other two components (with associated protocols) also implemented by CNRI were the DO Repository and the DO Registry. The Handle System (HS) includes an open set of protocols, a namespace, and a reference implementation of the protocols. The protocols enable a distributed computer system to store identifiers, known as Handles, of arbitrary resources and resolve those Handles into the information necessary to locate, access, contact, authenticate, or otherwise make use of the resources. This information can be changed as needed to reflect the current state of the identified resource without changing its identifier, thus allowing the name of the item to persist over changes of location and other related state information. v1.0 IoT6 D2.4 Page 32 D2.4 Implementation and testing of IPv6-based features A Handle consists of a prefix and a local identifier. The syntax of the DO is a set of pairs (type, value). As with the Domain Name System (DNS) with its DNS Resource Directory (DNS-RD), the Handle Resolver (i.e. Handle server) will provide a set of such pairs, some of which include well-known data types, like URIs, INET_HOST addresses, etc. The pairs can be hierarchic, so that a DO contains descriptions and identifiers of other DOs in its parameters. Clearly some of the parameters may contain IPv6 addresses (as INET_HOST entries, see later description of data types) – but there may be several such addresses depending on different views of the parameters. The HS incorporates an operational security system based on both private/public key pairs and passwords. The HS was developed initially with digital documents in mind, but it has evolved into a generic implementation of the DOA, supporting multiple object types, not just ‘digital documents’ (see further analysis in the following sections). It is an operational system with global distribution, many features to aid performance, resilience and scalability. It is being standardised for the ITU under ITU-T Recommendation X.1255 [15]. v1.0 IoT6 D2.4 Page 33 D2.4 Implementation and testing of IPv6-based features 7 Some Features of the Handle System The following description of HS features is not an exhaustive list. We discuss features that we believe are pertinent to IoT applications and where the HS architecture can provide the necessary infrastructure and network operations to make these applications a reality with the least effort. In addition, the infrastructure satisfies many of the requirements of the IoT architectures and in particular, many of its desired functions. 7.1 Handles as Persistent Identifiers Handles are persistent identifiers for Internet resources. A Handle does not have to be derived in any way from the entity that it names – the connection is maintained within the Handle System. This allows the name to persist over changes of location, ownership, and other ‘current state’ conditions. When a named resource moves from one location to another, e.g., from an old server to a new server, the Handle is kept current by updating its value in the Handle System to reflect the new location. The Handle System is designed to meet the following requirements for persistence. Handles are: • • • • • not based on any changeable attributes of the entity they identify (location, ownership, or any other attribute that may change over time); opaque, preferably ‘dumb numbers’ from which no potentially confusing meaning can be drawn, and from which no assumptions about ownership or use can be made; unique within the Handle System, avoiding collisions and referential uncertainty; easy to make user friendly, human-readable, cut-and-paste-able, and can be embedded, if needed; easily fit into common systems, e.g., URI specification. Handle resolution is: • • • • • • reliable, using redundancy, with no single points of failure and resolution time fast enough never to appear broken; scalable, so that higher loads are easily managed with more computers; flexible and easily adapted to changing computing environments and new applications; trusted, with both resolution and administration built on proven trust methods; built on an open architecture that encourages the community of users to build applications on top of the infrastructure; transparent to users who don't need to know the infrastructure details. The above requirements for persistence fit most, if not all, the requirements of IoT architectures, including IoT6. In particular, where IETF-compliant standards have been defined for IoT operations, such as the CoRE group’s specifications of link formats and CoAP operations based on URIs, the above features cover all these aspects. 7.2 Handle Syntax Within the Handle namespace, every identifier consists of two parts: its Handle prefix, and a suffix or unique “local name” under the prefix. The prefix and suffix are separated by the ASCII character “/”. An identifier may thus be defined as v1.0 IoT6 D2.4 Page 34 D2.4 Implementation and testing of IPv6-based features ::= “/” For example, “10.1045/january2010-reilly” is an identifier (also known as a Digital Object Identifier (DOI) name, an implementation of the Handle System) for an article published in D-Lib Magazine. It is defined under the prefix “10.1045”, and its suffix is “january2010reilly”. Identifiers may consist of any printable characters from the Universal Character Set, two-octet form (UCS-2) of ISO/IEC 10646, which is the exact character set defined by Unicode v2.0. The UCS-2 character set encompasses most characters used in every major language written today. To allow compatibility with most of the existing systems and prevent ambiguity among different encodings, Handle protocol mandates UTF-8 to be the only encoding used for Handles. The UTF-8 encoding preserves any ASCII encoded names, which allows maximum compatibility to existing systems without causing naming conflict. The use of Universal Character Sets is a novelty in its own right, in IoT systems. A Buildings Operator or Administrator can even refer to language-localised versions of BMS s/w. By default, Handles are case sensitive. However, any Handle service, including the global service, may define its namespace such that all ASCII characters within any Handle are case insensitive. The latter is the preferred approach in IoT environments. The Handle namespace can be considered as a superset of many local namespaces, with each local namespace having its own unique prefix. The prefix identifies the administrative unit of creation, although not necessarily continuing administration, of the associated Handles. Each prefix is guaranteed to be globally unique within the Handle System. Any existing local namespace can join the global Handle namespace by obtaining a unique prefix, with the resulting identifiers being a combination of prefix and local name as shown above. Each prefix may have derived prefixes. For example, once the prefix 12345 has been created, 12345.1 can be created. Derived prefix 12345.1 is therefore defined under prefix 12345. The syntax can be represented as “string.derivedstring”. In terms of Handle System technology, a derived prefix is a prefix in its own right and can be used any way that any other prefix can be used, but typically it is used as one of a set of connected prefixes. Derived prefixes are sometimes used by organisations that assign identifiers to different categories of content or objects that they wish to keep separate. They are also used for test purposes. The prefix and the suffix, or local name, are separated by the octet used for ASCII character “/” (0x2F). The collection of local names under a prefix is the local namespace for that prefix. Any local name must be unique under its local namespace. The uniqueness of a prefix and a local name under that prefix ensures that any identifier is globally unique within the context of the Handle System. 7.2.1 Handle syntax for IoT applications The syntax described above is the basis of the syntax we are using in IoT6. For example, UCL obtained the globally unique prefix 11175 from the international Handle registrar (currently at CNRI [15], but subject to change). Under this international prefix we can now allocate Handles at will. For example, in the buildings management Use Case of interest to IoT6, one can envisage the creation of a logical ‘next-step’ Handle for a smart building as ‘11175/EngBldg’. Then, further sub-Handles (which are Handles in their own right) are possible following the logical structure of the semantics of each application. Examples in our case, are ‘11175/EngBldg/Floor2’, ‘11175/EngBldg/Floor6/LightA’, ‘11175/EngBldg/AllSirens’, etc. v1.0 IoT6 D2.4 Page 35 D2.4 Implementation and testing of IPv6-based features The beauty of Handles as arbitrary length opaque identifiers is that they can be neatly mapped onto URIs, which most RESTful implementations favour. The advantages become even more powerful for IoT when combined with programmatic access to a Handle server. Further details on this aspect can be found in Section 10. 7.3 Handle Resolution and relevance to IoT applications The Handle System allows identifiers (Handles) to be resolved in a distributed fashion, using dedicated clients, common clients such as web browsers using special extensions or plug-ins, or un-extended clients going through various proxies. In all cases, communication with the Handle System is carried out using Handle System protocols, and in all cases, those protocols have both a formal specification and some specific implementations. Figure 10: The Handle resolution process Figure 10 shows a client sending a request to the Handle System for the data associated with identifier 11175/UCLEstate. The following describes aspects of this communication structure. • A client such as a web browser encounters a Handle, e.g., 11175/UCLEstate, on the Internet or an individual intranet, typically as a hyperlink or other kind of reference. The client sends the Handle to the Handle System for resolution. This can be done directly by a client who understands the Handle resolution protocol natively, or through a proxy server by a client which does not. In the case of IoT clients, such as IP sensors, the proxy method is recommended. However, the queries are relatively simple and could be submitted by the end-nodes themselves, if required. There is no need to have the full Handle protocol specification v1.0 IoT6 D2.4 Page 36 D2.4 Implementation and testing of IPv6-based features implemented on a node with reduced processing capabilities. Only the pertinent sections of the protocol that would allow the node to complete a successful requestresponse would suffice. It is expected that end-nodes of an IoT application would have a very clearly constrained set of capabilities specified. • The Handle System consists of a collection of local Handle services. Each service consists of at least one primary site and any number of secondary sites, with each site containing any number of Handle servers. For resolution, each site replicates all of the identifiers in that Handle service. This structure is independent of the application domain or end-node capabilities. It can provide the necessary infrastructure for any IoT application. • The Global Handle Registry is responsible for knowing the locations and namespace responsibilities of the entire set of local Handle services. Each of these local services knows how to access the Global Handle Registry. This allows a resolution query to enter the Handle System at any point, and be routed to the server that knows the answer in any site within the responsible service. There is a similarity here to the global DNS structure with root servers. However, in the most recent design development, the GHR function will be delegated to an international foundation. • Each identifier can be associated with one or more pieces of typed data. In this example, the Handle 11175/UCLEstate is associated with, and so resolves to two URLs (it would also be possible to associate multiple instances of the same data type), and also XML and binary data. The client can request that the Handle server return to the client all of the data associated with that identifier, or all of the data of a specific type, or with a specific index value. The Handle System is a pure resolution system and carries no assumptions on what the client will or will not do with the resolution information, thus maximizing the flexibility of applications which use the Handle System as an infrastructure for naming. The above observations are significant for IoT environments. The basic data types defined by the Handle protocol specification are sufficient enough to describe a large set of communications transactions required by the IoT. However, in various IoT application domains, one may need to define new single or composite types that fully describe the IoT resource or service as a ‘digital entity’ and further apply relational hierarchies, if the IoT digital entities so require. The system provides the technology to store the newly defined types inside structures of the Handle server. This mechanism is crucial in giving IoT applications the ability to abstract their logical components and insert them into a Handle digital object structure. 7.4 Administering Handles – Security Provisions and Implications Conducting Handle administration (i.e., creating, modifying, and deleting individual Handles) requires that you authenticate yourself to the Handle System by proving that you are who you claim to be. To authenticate yourself, you need to have an ID that uniquely identifies you, and since the Handle System is global in nature, your ID must also be globally unique. Since globally unique identifiers are the Handle System’s specialty, it is natural that administrators should be identified by Handles. An administrator Handle contains either a public key or a secret key (password) that authenticates the individual identified by that Handle. If an administrator Handle is specified with permission to perform some operation in the Handle System, then that administrator can v1.0 IoT6 D2.4 Page 37 D2.4 Implementation and testing of IPv6-based features perform that operation as long as he can authenticate himself against the public or secret key in the administrator Handle. When you request your own prefix, a prefix will be created that will also serve as the administrator Handle for that prefix, so prefixes (such as 0.NA/11175) serve double-duty as administrator Handles and as prefixes. In this discussion, we will be focusing on the administrator functions of the naming authority Handle. An administrator Handle can be queried and the values viewed using a Handle client, or by using a proxy. Your public or secret key will be associated with the administrator Handle. When you query the Handle, you will notice that there are several values associated with it. In addition, each Handle value has a unique (within the Handle) numeric index, as well as a type identifier. Some of the Handle values have special meaning within the Handle System: • • • • Admin Value. Every Handle must have an admin value associated with it. An admin value is of type HS_ADMIN, and specifies the permissions and Handle of the administrator who is allowed to make changes to or delete that Handle. Admin values are values of type HS_ADMIN, and for consistency are being given an index of 100 (The Handle System does not require these particular index values. The index values just need to be unique within the Handle). If there are multiple admin values, then the additional indexes are being given 101, 102, 103, and so on. Admin values specify who can perform administration, by the Handle and value index of either the administrator's authentication, or of an admin group value. Public Key Value. If you have a public key associated with the Handle, it will be in a Handle value with type HS_PUBKEY. Public key values for consistency are being given an index of 300 (or 301, 302, 303, etc., if you have multiple keys). It is important to remember the index because you will need to specify it along with your Handle when you authenticate yourself. Secret Key Value. If you have a secret key associated with your Handle, it will be in a Handle value with type HS_SECKEY. For consistency, secret key values are being given an index of 300 (or 301, 302, 303, etc. if you have multiple keys). It is important to remember this index because you will need to specify it along with your Handle when asked to authenticate yourself. This Handle value should obviously not be publicly readable, which is why secret key values do not appear in non-authenticated queries for your administrative Handle. Group Value. A group value contains a list of Handle values that identify public keys, secret keys, or other groups and is type HS_VLIST. If an admin value specifies a group value as an administrator, then every value in the group is considered an administrator for the Handle. Handle administration requires an administrator to authenticate himself by providing the following information: • • Your admin Handle. (Your prefix) and the index of your public or secret key value within that Handle. Your private or secret key. The private and secret keys do not get sent over the Internet by the Handle System. You only need to provide this to the Handle System client software so that it can prove to any Handle server that you have this information. In order to create an identifier under a given prefix, the owner of the prefix (the part of the Handle before the slash) must give you permission to create identifiers under that prefix. He can give you permission to create identifiers by adding your admin Handle and the index for your key value to a list of administrators who have permission to create identifiers under that v1.0 IoT6 D2.4 Page 38 D2.4 Implementation and testing of IPv6-based features prefix. When you send the ‘create-handle’ request to the Handle System, you must provide your authentication information. If the server can verify that you are the individual identified by the admin handle (your private key matches your public key, or you enter the correct secret key) then the requested identifier will be created. 7.4.1 Handle security provisions and the IoT The above descriptions clearly define the access control mechanisms embedded into the Handle Systems, which can be suitable to the IoT. The mechanisms provide a strong framework for authentication and authorisation that can be extended to operate in a M2M environment, involving gateways or end-nodes of an IoT subsystem and the Handle infrastructure (see details in Figure 11). Where the nodes of an IoT subsystem are involved, further DTLS-based provisions can be applied to create secure end-to-end transactions (noted as green curved arrows). In particular, the CoAP DeviceNet-side access to the Handle infrastructure is not mandated to be secure, therefore, we foresee use of DTLS when CoAP-enabled Handle proxies are used for interaction towards a Handle Service (i.e., from DeviceNets to the ServiceNet and from DeviceNets to the Internet). Figure 11: Secure end-to-end Handle administration from DeviceNets to the Internet. 7.5 Handle System Scalability Scalability has been a fundamental requirement and design criterion for Handle. It reflects on storage and performance issues. We examine each separately below. The basic questions to address are whether some limits exist in the number of identifiers that can be added and whether performance decreases with the number of Handles served. Scalability can be a relatively subjective issue. It may be addressed differently at design stage or at implementation phase. A design that is fundamentally scalable, may exhibit problems with a specific implementation instance. v1.0 IoT6 D2.4 Page 39 D2.4 Implementation and testing of IPv6-based features Furthermore, the use of intermediary services, such as http proxies, may introduce other scalability issues, which the basic Handle System design does not and cannot address. 7.5.1 Storage scalability The Handle System has been designed at a very basic level as a distributed system; that is, it will run across as many computers and domains as are required to provide the desired functionality. There are three architectural concepts that have been implemented in Handle to satisfy storage scalability: Handle Servers, Handle Sites and Handle Services. Figure 12: Logical separation of Handle Service to Servers and Sites As shown in Figure 12 Handles are held in, and resolved by, Handle servers and the servers are grouped into one or more Handle sites within each Handle service. There are no design limits on the total number of Handle services which constitute the Handle System, there are no design limits on the number of sites which make up each service, and there are no limits on the number of servers which make up each site. Replication by site, within a Handle service, does not require that each site contain the same number of servers; that is, while each site will have the same replicated set of Handles, each site may allocate that set of Handles across a different number of servers. Thus, increased numbers of Handles within a site can be accommodated by adding additional servers, either on the same or additional computers, additional sites can be added to a Handle service at any time, and additional Handle services can be created. Every service must be registered with the Global Handle Registry, but that Handle service can also have as many sites with as many servers as needed. The result is that the number of identifiers that can be accommodated in the current Handle System is limited only by the number of computers available. v1.0 IoT6 D2.4 Page 40 D2.4 Implementation and testing of IPv6-based features 7.5.1.1 Dimensioning storage for IoT applications The highly scalable implementation of the DOA architecture by the Handle System is of great interest to IoT applications. There are significant benefits we could highlight in IoT6 Use Cases, like the BMS systems. For example, a particular dimensioning of a Buildings Estate to an IT infrastructure that manages it, does not have to be statically dependent on the design decisions made. Say, for example, that the UCL Estate comprised 4 buildings for 4 Faculties. Say that the College grows two-fold within 3 years of operation to 8 buildings for 8 Departments/Faculties. Any BMS system deployed to manage the 4 original facilities would require significant changes to the underlying storage and performance systems to accommodate the growth. In the Handle case, the administrator of 11175/UCLEstate namespace has a number of design tools in his hands to accommodate the new Estate while maintaining performance. In terms of Handle management, the new Estate would follow the logical structure of the application domain and would only require the creation of new Handles. It also allows the administrator to tune performance by allocating specific sub-Handles to specific services under his control or by delegating control to the appropriate department within the Estate management division. 7.5.1.2 Default database: Berkeley DB By default the Handle server uses a Berkeley DB Java Edition database to store Handles and Handle values as well as prefixes that are homed to the server. In addition to the above database, a Handle server uses cache.jdb as a temporary Handle cache. 7.5.1.3 Custom storage (SQL, PostgreSQL, Oracle) Using a SQL database as storage for a Handle server allows greater control over data deposits as well as permitting complex data query. 7.5.2 Performance scalability Performance of Handle across increasing numbers of identifiers is addressed by hashing, replication, and caching. 7.5.2.1 Hashing Hashing is used in the Handle System to allocate evenly any number of identifiers across any number of servers within a site, and allows a single computation to determine on which server within a set of servers a given Handle is located, regardless of the number of Handles or the number of servers. Each server within a site is responsible for a subset of Handles managed by that site. Given a specific identifier and knowledge of the Handle service responsible for that identifier, a Handle client selects a site within that Handle service and performs a single computation on the Handle to determine which server within the site contains the Handle. The result of the computation becomes a pointer into a hash table, which is unique to each Handle site and can be thought of as a map of the given site, mapping which Handles belong to which servers. The computation is independent of the number of servers and Handles, and it will not take a client any longer to locate and query the correct server for a Handle within a Handle service that contains billions of Handles and hundreds of servers, than for a Handle service that contains only millions of Handles and only a few servers. v1.0 IoT6 D2.4 Page 41 D2.4 Implementation and testing of IPv6-based features The connection between a given Handle and the responsible Handle service is determined by prefix. Prefix records are maintained by the GHR as Handles, and these Handles are hashed across the GHR sites in the same way that all other Handles are hashed across their respective Handle services. The only hierarchy in Handle System services is the two level distinction between the single GHR and all locals, which means that the worst case resolution would be that a client with no built in or cached knowledge would have to consult the GHR and one local. 7.5.2.2 Replication (mirror server) Another aspect of Handle System scalability is replication. The individual Handle services within the Handle System each consist of one or more Handle service sites, where each site replicates the complete individual Handle service, at least for the purposes of Handle resolution. Thus, increased demand on a given Handle service can be met with additional sites, and increased demand on a given site can be met with additional servers. This also opens up the option, so far not implemented by any existing client, of optimizing resolution performance by selecting the "best" server from a group of replicated servers. 7.5.2.3 Caching Caching may also be used to improve performance and reduce the possibility of bottleneck situations in the Handle System, as is the case in many distributed systems. The Handle System data model and protocol design includes a space for cache time-outs and Handle caching servers have been developed and are in use. (See RFC 3651 [13]). 7.5.2.4 Splitting a Handle server A feature exists where the administrator of a Handle service can split a single Handle server into multiple Handle servers. (This is different from splitting sites consisting of multiple servers, which is a much more complicated process.) The goal of this procedure is to minimise the down time for the primary site. The database splitting process can be performed on a checkpoint/backup of the source database, and then completed using the transaction log of the source database. 7.6 Security aspects In the previous section, we discussed how the architecture ensures how the administration, storage and access of Handles can be secured (Section 7.4). To implement the secure functions, the Handle server uses cryptographic libraries that come with Java v.5 distribution (called Sun Java™ Cryptography Extension and Provider). We revisit and analyse below the key security aspects of the system implementation. 7.6.1 Authentication The Handle System provides two forms of authentication: public key and secret key. The system can authenticate all administrators of the Handles stored in its database, main and delegated administrators in the hierarchical chain of prefixes and identifiers, allowing for finegrained control of each structure. v1.0 IoT6 D2.4 Page 42 D2.4 Implementation and testing of IPv6-based features 7.6.1.1 Public Key authentication Public key authentication is performed using the DSA algorithm (key length varies from 512 to 1024 bits, strength can be chosen by the user when generating keys. The default is 1024). To authenticate a client, the Handle System relies on a public key that is stored in a Handle to make it available to the public. The private key is securely stored on the computer with the Handle client that will be authenticated. To prevent unauthorised use of a private key, it can be encrypted using a symmetric algorithm (currently 56 bit DES in Handle Systems). 7.6.1.2 Secret Key authentication Secret key authentication relies on a secure hashing algorithm, chosen by the client being authenticated (currently either MD5 or SHA1). A secret key consists of a single byte string of size ranging from 0 to 2147483648. This byte string is stored as plain text in a Handle. It is highly advisable to restrict read permissions on the Handle to ensure the secrecy of the secret key. The server functionality allows this with fine-grained permission control over Handles. 7.6.2 Server Certification Handle clients can request that a Handle server cryptographically certify its messages with its public key. This certification can be used to verify the authenticity of Handle server transmissions. The current implementation of the Handle System uses DSA for this purpose. The DSA public key for a Handle server is stored in its site information record. 7.6.3 Security Services in Handle There are two important differences, and one similarity, between the security services provided in Handle from those in the DNS (with its DNSSEC extension). Both have the same constraints on entry creation, deletion and replication. Both require strong authorisation with specific administration credentials. Both provide proof of source and integrity. However, Handle has two additional features: session services and access control. Handle allows a client to establish secure sessions with a server for encrypted communication. This functionality is permitted for example when operating in batch execution mode. This is equivalent to using SSL or TLS (as used by HTTPS), as it affords protection from eavesdropping and man-in-the middle attacks (currently encrypting sessions using 56 bit DES). Handle also can require credentials to permit access to the contents of the Handle. This feature is very important for IoT, for two reasons. First, the attributes of the Handle may reveal properties of the DO that should be protected information. Second, by requiring finegrained authorisation to access of the Handle contents, one can greatly simplify the authorisation needs in the IoT processes. No further authorisation is required provided the relevant access is vouched for by the Handle-provided credentials, 7.7 Handle Value Types A Handle has a set of values assigned to it and may be thought of as a record that consists of a group of fields. Each Handle value must have a data type specified in its field that v1.0 IoT6 D2.4 Page 43 D2.4 Implementation and testing of IPv6-based features defines the syntax and semantics of its data, and a unique value that distinguishes it from the other values of the set. Types are identified by Handles and can be any UTF8-string. Handle System users must take care of potential conflicts introduced by custom Handle clients if users assign types that are not registered and recognised across the global Handle infrastructure. In IoT applications, one would probably specify a set of data types that are common in the application domain or technology registered in the Handle System serving the IoT domain. For example, a particular building management infrastructure may employ a standardised legacy DeviceNet, such as a KNX or LonWorks set of A/C units. These may come prearranged in a networked configuration with proprietary communications (signalling) protocols. Use of such technologies with Handle may be facilitated by defining basic and compound data types that are fundamental to the operation of the legacy DeviceNet, such as LegacyXAddress, LegacyXProtocol, etc. For interoperability purposes, how types should be defined and how they should be registered and used at global scale should be clearly defined a priori. Table 1 shows the pre-defined types that exist for Handle which have been specified for administrative purposes. Table 1: Pre-defined Administrative Types 0.TYPE/HS_ADMIN Values of type HS_ADMIN are encoded representations of the admin record for a Handle. This admin record defines the administrator as well as the permissions that the administrator has over the Handle. 0.TYPE/HS_PUBKEY Values of type HS_PUBKEY contain encoded information describing a public key that can be used to authenticate entities in the Handle System. 0.TYPE/HS_SECKEY Values of type HS_SECKEY are used to store UTF8-encoded text that is used as a password to access some service. Values of type HS_SECKEY should usually not be publicly readable. 0.TYPE/HS_VLIST Values of type HS_VLIST contain a list of Handle value references. Each Handle value reference consists of a Handle and an index of the value being referenced. 0.TYPE/HS_SERV Values of type HS_SERV contain UTF8-encoded Handles that identify a Handle service (i.e., a set of HS_SITE values). When HS_SERV values are contained in a prefix Handle, resolvers retrieve the service information from the Handle referenced in the HS_SERV value. 0.TYPE/HS_ALIAS Values of type HS_ALIAS contain a UTF8-encoded Handle. The Handle identified by the HS_ALIAS value should be resolved, and its data should be used in place of the data in the Handle containing the HS_ALIAS value. This redirection should be handled at the application level. v1.0 IoT6 D2.4 Page 44 D2.4 Implementation and testing of IPv6-based features Table 2 shows other common types of Handles that are non-administrative. Combinations of such types are fairly sufficient to define a good subset of IoT resources and services in RESTful environments. Table 2: Non-administrative Types 0.TYPE/URL Values of type URL are UTF8-encoded URIs that specify the location of the object identified by a Handle. 0.TYPE/EMAIL Values of type EMAIL are UTF8-encoded email addresses. 0.TYPE/DESC Values of type DESC are UTF8-encoded text descriptions of the object identified by the Handle. 0.TYPE/INET_HOST Used to identify a Handle value which has an IP address or host name. 0.TYPE/URN Used to store a value identified as a URN (type not defined or registered) 10320/loc Values of type 10320/loc specify an XML-formatted list of locations Among the Handle values stored in every prefix are some that directly impact the behaviour of clients, servers, and the proxies. They are described in Table 3. Table 3: Prefix Handle Values 1 HS_SITE and HS_SERV values These values determine which LHS a client will use to resolve Handles under a prefix. 2 HS_ADMIN value An LHS server will use this value to determine which administrators are authorised to create Handles under the prefix. 3 HS_VLIST, HS_PUBKEY, HS_SECKEY values These values are referenced by HS_ADMIN values and so are used by servers (and clients) for authentication and authorisation. It has become customary to use the prefix Handle itself as the Handle an LHS administrator uses to authenticate. 4 An HS_NAMESPACE value with several subcomponents: 4a Delegation information Used by clients to determine when derived prefixes should be resolved via delegation. 4b Template Handle information Used by servers to determine how to configure themselves to respond to Handle resolution requests via template. 4c Status information Used by the proxy when it is unable to resolve a Handle under the prefix. v1.0 IoT6 D2.4 Page 45 D2.4 Implementation and testing of IPv6-based features 4d Multiple redirection information Used by the proxy when it is unable to resolve a Handle under the prefix. 7.8 Template Handles A single template Handle can be created as a base that will allow any number of extensions to that base to be resolved as full Handles, according to a pattern, without each such Handle being individually registered. This would allow, for example, the use of Handles to reference an unlimited number of resources or service endpoints in a building (lights, switches, sockets, etc., as exhibited by sensor measurements, actuation and other operations) without each potential resource or service having to be registered with a separate Handle. If the pattern needs to be changed, e.g., a light bulb moves location or a different kind of server is used to deliver the building’s resources, only the single base Handle needs to be changed to allow an unlimited number of previously constructed extensions to continue to resolve properly. When a server receives a resolution request for a Handle which is not in its database, it tries to determine if there is template for constructing the Handle values. This is an extremely powerful feature of the Handle System for constructing logical processing hierarchies of IoT subsystems. In the IoT6 Buildings Management scenario, this means that the logical structure of the building’s managed components can be described algorithmically (and therefore programmatically) by use of XML within a template Handle. This feature empowers the user (building operator/administrator) with minimal system support apart from the basic ancillary functions of Handle management (secure upload of the XML description to the template Handle record, if authentication permits). It also lays a strong foundation in support of Software Defined Buildings. 7.8.1 The Template Delimiter The way templates work is as follows. First, the server looks for a template delimiter, which is a string dividing the original Handle into a base and an extension. The delimiter is generally defined in an HS_NAMESPACE value of the prefix Handle 0.NA/. An example: