Network-Driven offloading with Neighbor Discovery

By utilizing an IETF protocol [76], the NAO network-driven approach can be deployed on UEs with multiple network interfaces. Several main- stream operating systems have already implemented the extensions, in- cluding Linux, BSD variants and Microsoft Windows starting from XP. The network interfaces that accept the new extensions can be specified just using host side configuration. The only consideration is to limit the number of interfaces accepting offloading commands to one interface that is both trusted and centrally managed by the operator. In our case, the 3GPP cellular connection fulfills these requirements.

Figure 3.18 shows the test setup in the industry laboratory dedicated for our experiments. Since modifying a live network GGSN/P-GW is not an option, we implement required tools in the APN termination router as shown in Figure 3.18. When the APN is terminated to an external

Figure 3.18: Test setup in industry laboratory.

router, the GGSN/P-GW essentially becomes a bridge and the APN ter- minating router becomes the first-hop router for UEs. We implement an NAO-SEND tool that enables us to send RAs with offloading options among other Neighbor Discovery messages, from the cellular network to a specific UE.

Regarding the experiments, host operating systems typically prefer WiFi over cellular access. For instance, Linux-based systems implicitly prefer WiFi access over cellular access, thus prioritizing the first-hop router(s) in WiFi access over the first-hop router in a cellular access. For consistency, we always use LOW default router priority for the cellular access. Because the default router priority on other interfaces is implicitly MEDIUM, the host IP stack will prefer any other interface for default destinations rather than cellular access. When a cellular operator wants to route certain traffic over the cellular, it only needs to send an RA with an RIO containing the IPv6 prefix(es) for those destinations. The default router and default ad- dress selection algorithm [244] in the host IP stack will take care of selecting an appropriate interface for new IPv6 connections (e.g., existing TCP con- nections will not be moved). By adopting the model of operation ‘offload everything except specific destinations’, we also avoid a large number of routing rules installed on UEs as overhead.

Figure 3.19: Using RIO to remove a default router and add a specific route.

ments in the laboratory. We used the NAO-SEND installed on the APN router to send RAs to a testing UE through the Flexi-ISN GGSN located in the op- erator network. As a proof of concept, the testing traffic consists of ICMPv6 ping packets sent from the UE to ‘www.google.com’ (2a00:1450:8007::93) and ‘www.kame.net’ (2001:200:dff:fff1:216:3eff:feb1:44d7). Regarding the testing UE, we enabled IPv6 on its WiFi and cellular interfaces. Both the first-hop routers in the WiFi and cellular networks were added to the UE’s default router list. For testing purpose, we further set the default router preference of the WiFi router as MEDIUM and the preference of the cellular router as HIGH.

Figure 3.19 and 3.20 show the Wireshark packet capture on the UE. As illustrated in Figure 3.19, all the ping packets to ‘www.google.com’ and ‘www.kame.net’ were initially sent through the cellular (3G) network. We first instructed the NAO-SEND to send an RA for offloading, which contained an RIO with a specific route for ‘www.kame.net’ (2001:200:dff:fff1::). Since we deliberately set the ‘Router Lifetime’ in this RA to 0, once the UE received the RA, it removed the cellular first-hop router from its default router list. In addition, our NAO-enabled UE was able to parse the RIO and add a specific route (2001:200:dff:fff1::) for the cellular router to its routing table. Since the cellular default router was removed and there was not specific route for ‘www.google.com’, the ping packets to ‘www.google.com’ were offloaded to the WiFi network. The ping packets to ‘www.kame.net’ were stilled sent through the cellular network according to the specific route suggested by the RIO. As shown in Figure 3.20, we sent another RA to remove the specific route of ‘www.kame.net’ by setting the ‘Router Lifetime’ of 2001:200:dff:fff1:: as 0. After UE removed this specific route of cellular network, the ping packets to ‘www.kame.net’ were also offloaded to WiFi network.

In brief, the live experiments show that we can use the proposed app- roach to support IPv6 traffic offloading. We note that 3GPP architecture relies on IPv6 Stateless Address Auto Configuration (SLAAC) for its (un)trusted 3GPP access. The GGSN/P-GW must always send Router Advertise- ments for SLAAC purposes and therefore using the 3GPP access as a com- mand channel for offloading purposes is an incremental enhancement to the GGSN/P-GW functionality. Furthermore, RAs can always be sent un- solicited. According to our experiments, the NAO solution allows for an on-demand push mode of operation from the cellular operator point of view.

3.3.3 Network-Driven offloading with IPv4 support

Based on our design principle to minimize the impact on the host sys- tem [23], we implement a system prototype for IPv4 traffic offloading with Linux kernel version 3.0. The system architecture is illustrated in Fig- ure 3.21. On the host side, we extend the existing kernel implementation of Neighbor Discovery protocol (ndisc.c) by adding an intercepting hook function (kernel offload hook ) and kernel offload module to push more- specific IPv4 routes and IPv4 default gateway information contained in RA options from the kernel to user space via the sysfs interface. In the user space, we develop an IPv4 offload daemon that handles main tasks for IPv4 traffic offloading by manipulating IPv4 routing tables.

On the network side, we implement the NAO protocol specified in Internet-Draft draft-korhonen-mif-ra-offload-03 [24] (the predecessor of [25]) and integrate it into the tool NAO-SEND. For the protocol implementation, we use the RIO Prefix field [76] to convey the specific route through an IPv4-mapped IPv6 address. We install NAO-SEND on an APN server which is connected to the Flexi-ISN GGSN located in the operator network.

As presented in Figure 3.21, the deployment of the NAO framework depends on the collaboration of network and host side. On receiving an RA with IPv4 offload options, the NAO kernel offload hook will parse the message and notify the kernel offload module. Based on the offload options, the kernel offload module will set up the sysfs interface and record the off- loading information. Once the recording is completed, the kernel offload module will notify IPv4 offload daemon with a pointer to the sysfs inter- face. The NAO IPv4 offload daemon in the user space checks the input in the sysfs interface and modifies routing tables according to the offloading policies.

To test the network-driven IPv4 traffic offloading, we set up a test environment in our laboratory at the University of Helsinki. Figure 3.22 shows the test setup. The network layout for this experiment is similar to the one shown in Figure 3.16. We installed our kernel extensions on the test machine, which is connected to cellular access through N900. The WiFi access to the Internet is provided by a laptop machine. We use the NAO-SEND tool to send RAs from the APN router to UEs through the Flexi- ISN GGSN located in the operator network.

As proof of concept, we conducted ping tests similar to the proce- dure used for RA-based IPv6 offloading. Figure 3.23 shows a captured RA message, where the RIO option carries an IPv4-mapped IPv6 address (::ffff:203.178.141.0/120) to route an IPv4 subnet to the RA originat- ing router. The RA also carries the default IPv4 gateway address of the

kernel offload hook Flexi-ISN GGSN User Space RA with v4 offload option Kernel Space kernel offload module IPv4 offload daemon sysfs interface

Mobile Host – Linux kernel 3.x

1 2 3 4 5 6

Figure 3.21: NAO Implementation to support IPv4 traffic offloading [26].

Cellular connection via N900 to Flexi-ISN GGSN with NAO-SEND WiFi connectivity

Test machine WiFi access point

to Internet

Figure 3.23: Packet capture showing an RA with RIO carrying an IPv4- mapped IPv6 address and an IPv4 default gateway address.

dual-stacked router as the last option (10.6.6.6 i.e. 0a 06 06 06). To sum up, our experiments in operational networks show that a cellular operator can take advantage of the cellular network connection as a secure command channel to push offloading policies into the UE for both IPv6 and IPv4 traffic, while still only using standard IETF protocols.