Generic Functionality of a Source Measurement Module

Irrespective of the particular multi-point measurement deployed by a set of modules, most of their functionality is generic, depending on whether the module operates at the source or at the

destination of an instrumented path. Relative to particular measurements is only the construction of the specific extension header and a computation on the corresponding metrics carried therein.

Upon loading a source measurement module to a system’s running kernel, that node immediately becomes the originator (source) of a unidirectional instrumented path and conducts a particular in-line measurement header insertion to outgoing packets that satisfy the appropriate selection criteria. The entry function of a source LKM registers its main processing routine with the first available pointer in the IP6_OUTPUT_PACKETS array. Consequently, every outgoing IPv6 packet that enters the ip6_output_finish()

function is passed to the module code before it is delivered to the lower layers for transmission. The source LKM’s core functionality consists of four different functions137, each performing a distinct task, as shown in Figure 4-7.

Figure 4-7: Generic Operation of a Source Measurement Module (LKM)

Each packet processed by the module is first checked against the filtering and sampling criteria that have been either specified upon module initialisation or they have been dynamically altered during the module’s operation, as will be discussed in sections 4.4.3.5 and

4.4.3.6. If these are satisfied, the next function examines whether the socket buffer assigned to manage the particular outgoing packet has enough space in its headroom area to accommodate for the size of the IPv6 extension header or option related to that measurement. If necessary, the headroom is grown138 _{by the appropriate number of bytes and the data area is expanded} (pushed) towards the head of the socket buffer accordingly (Figure 4-5).

At this stage, there are some implementation-dependent and IPv6 related aspects that need to be taken into consideration, which would probably need to be re-visited under different realisations of an in-line measurement system, and as IPv6 will operationally evolve and different extension headers and options will be standardised. For this particular prototype implementation, the in-line measurement destination options processing is treated in a semi- autonomous manner since it is not fully integrated to the implementation of the IPv6 instance (as discussed in the previous section). More specifically, outgoing packets are passed to the source module after their core IPv6-level processing has been carried out by the kernel, and hence, there is a possibility that other extension headers have already been created by an application or by the kernel itself and encoded in the packet. Therefore, it is not sufficient for the source LKM to simply create and add its measurement-specific destination options header immediately after the main IPv6 header. Rather, it needs to examine the contents of the packet structure in order to identify where in the packet and how to encode its own extension headers. In the simplest and most popular case (due to lack of standardised and widely used IPv6 options) where no extension headers have been encoded in the packet, then a destination options header that will encapsulate the measurement-specific option is created and encoded between the IPv6 and the upper-layer header.

If other extension headers already exist in the packet, then a destination options header is encoded according to the IPv6 specification recommended order [DeHi98]. Since it is desirable for the prototype to accommodate for both intermediate and end-to-end path measurements, the options produced by the source module should potentially be able to be examined by intermediate as well as the ultimate destination of the packet. Hence, the destination options header carrying the measurement options should only be preceded by a present hop-by-hop options header, and itself should precede any other extension headers (section 3.6.1). A slightly more complicated yet rarer case occurs if the packet already contains a destination options extension header carrying other application or kernel-specific options. Then, the measurement-specific option produced by the source module needs to be encoded within the same destination options header. The module code must add the option at the end of the existing header, and also ensure that it is aligned at its natural boundaries. This

138 _{Actually, a new socket buffer with sufficient headroom space is created to handle the packet. The}

latter scenario might prove to be of rare occurrence, since it is assumed that when option- bearing headers are present they usually carry only one option [DeHi98, StTh98].

After this decision-making process, the main IPv6 header and any other extension headers that might precede the measurement-specific options are moved forward in the packet structure in order to allow space for the extension header to be inserted, and the socket buffer’s network header pointer (Figure 4-4) is updated accordingly.

The source LKM has then to perform a node-local computation of the measurement indicator of interest, and to construct the relevant option and the destination options extension header that will encapsulate the measurement data. The extension header is then injected to the packet and the necessary fields of the packet’s headers are updated accordingly. The payload length field of the main IPv6 header is updated to include the recently added data and the next header field of the preceding header is updated to reflect the current state of headers within the packet. Upon completion of these operations, the module then returns control back to the kernel’s IPv6 instance which in turn passes the enhanced socket buffer for transmission to the lower layers. If at any time during the module’s execution some operating condition139 _{is not} satisfied, then the packet is returned to the kernel unmodified.