At a system level, the in-line measurement functionality and operation have several common characteristics with the Netfilter framework. In principle, the direct (in-line) measurement through the addition of indicators within selected outgoing IPv6 packets and the observation, recording, and possibly amendment of existing measurement data within incoming packets can be seen as special functions within the general packet filtering and mangling concept provided by Netfilter under Linux. Indeed, the Netfilter framework could have been used as the basis for implementing the in-line measurement modules by registering additional special- purpose functions to the IPv6 Netfilter hooks of interest, and assigning them a priority relative to filtering, mangling, connection tracking, and the rest of the Netfilter operations.
Additionally, the Netfilter framework could have been used to queue incoming and outgoing IPv6 packets at certain hooks and pass them onto user-space for asynchronous131 packet handling. Using this facility, the in-line measurement modules could have adopted a more straight-forward, system and language-independent implementation as user-space processes, decoupled from the kernel operation. However, as it has been raised in section 4.4, such user- space implementation is not ideal, neither for high-speed processing nor for demonstrating the measurement modules’ operation on network nodes where a ‘user-space’ might simply not be present.
For similar reasons of minimisation of the inter-operational assumptions regarding the system operating environment of the in-line measurements modules, it was preferred for the prototype to keep its reliance on existing frameworks as well as its dependencies on add-on components at a bare minimum.
Finally, the in-line measurement instrumentation could have been hard-coded within the kernel’s IPv6 instance, directly embedding the additional functionality at appropriate points in the protocol stack to provide for the necessary processing of the measurement options within the IPv6 Destination Options headers. However, such approach would have been more appropriate for already standardised options that would start being widely supported in IPv6
131 The kernel does not wait while the packet is handled in user-space. At some later time, the packet
implementations, and potentially used by applications. Instead, the in-line measurement prototype has been designed and implemented as an independent set of self-contained modules of code, whose actual interference with the core kernel code only occurs at two certain places, in the form of call-back hooks. As it can be seen from Figure 4-6, two hooks have been put in place to pass control to the measurement modules as soon as packets enter an instrumented node and just before they are passed to the lower layer transmit functions, respectively. IP6_INPUT_PACKETS resides within ip6_rcv() and is called as soon as an incoming packet is delivered to the IPv6 instance and has passed the initial versioning and length error checks. IP6_OUTPUT_PACKETS resides in ip6_output_finish() and is called just before an outgoing packet is passed to the lower layer for transmission over a network device. These two hooks that operate on incoming and outgoing packets respectively are arrays of certain length that consist of pointers to functions, each one taking as an argument the socket buffer that represents and manages the packet in question. When no measurement modules are loaded, the arrays contain null pointers and consequently the kernel only has to perform one extra comparison over the elements of each array. When a measurement module is loaded in the kernel, it replaces the first available pointer in the respective input or output array132 with its call-back function which then becomes part of the kernel’s IPv6 instance. Similarly, when the module is unloaded, the corresponding pointer is set back to null. In this manner, incoming and outgoing IPv6 packets are passed to all loaded modules that have registered their call-back function.
As will become evident in the following section, minimal measurement modules have been implemented to either insert, or observe and record a particular measurement indicator. Hence, the arrays of pointers (instead of a single function pointer) allow for more than one module to operate simultaneously either on incoming or outgoing packets, by registering their processing routines with an entry of the corresponding array. Of course this comes at the cost of the kernel performing more comparisons over the entries of each array to identify how many modules have currently registered their functions with the kernel, and therefore, the number of entries in each array needs to be carefully chosen. For the purposes of this prototype implementation each array has two entries, essentially only marginally burdening the kernel with an additional (second) comparison133.
132 Depending on the operation of the loaded module, it will register itself either with the IP6_INPUT_PACKETS or the IP6_OUTPUT_PACKETS hook (array), as described in section 4.4.3.
133 One extra comparison in the kernel code is the minimum additional operation required to install a
hook in this manner [Herr00]. Also, this is the minimum permanent overhead introduced to the kernel while no modules are installed.