This section is devoted to the support of multihoming in proposals acting at the ap- plication layer and in operating systems. For instance, Name Based Sockets (NBS) [Ubillos et al., 2010] represents a change of paradigm on how applications see the information of layers bellow. Moreover, as presented in subsection 2.3.2, server appli- cations incorporate mechanisms to support multiple interfaces or multiple paths.
2.3.1 Protocols at Application layer
This subsection discusses two application-layer protocols, namely Session Initiation Protocol (SIP) and NBS.
2.3.1.1 Session Initiation Protocol
SIP [Rosenberg et al., 2002] is a session protocol that enables mobility at the application layer. SIP employs a Universal Resource Identifier (URI) to represent the user identity connected to a SIP domain. Sessions, therefore, are bound to the URI and not to an IP address. On mobility events, the user sends a binding update message that renews the mapping in the SIP server (URI to IP address). In this case, communication proceeds, as the URI is used to identify the user during the entire session. One drawback of SIP is that it is intended for User Datagram Protocol (UDP) applications. Thus, TCP applications cannot have the support of SIP in mobility events [Jain et al., 2012], as the change of IP address leads to the termination of connections. Some proposals mitigate this issue by combining SIP with Mobile IP [Seta et al., 2007].
Another drawback of SIP relates to the privacy of user IDs. PrivaSIP [Karopoulos et al., 2010] enables the protection of caller and caller’s IDs by the use of cryptogra-
2.3 Operating Systems and Applications
phy. Further, the media multihoming proposal [Verma, 2012] combines SIP with SCTP, enhancing multihoming support, to improve resilience. Nonetheless, in this last pro- posal the information provided is not sufficient to enable its implementation.
2.3.1.2 Name Based Sockets (NBS)
The NBS proposal [Ubillos et al., 2010] introduces a novelty that in a sense facilitates multihoming. Applications only use domain names, while IP addresses (e.g. selec- tion, discovery) are managed by the operating system. Such functionality is proposed as an extension to the socket API. Nodes communicating with each other, initially exchange names, in a piggyback scheme. The first packets convey the name on an IP-Option/IPv6 extension header. A receiver node, upon detecting such option, adds its name in the reply packets. The name can be based on a Fully Qualified Domain Name (FQDN), on ip6.arpa (host interface address) or nonces (session identifiers). The ports rely on service keywords attributed by the Internet Assigned Numbers Au- thority (IANA) (e.g. http for port 80).
The Name Based Sockets proposal can be combined with other protocols, such as SHIM6 to enable mobility [Xu et al., 2010]. Nevertheless, it requires node modifica- tions and removes the possibility of applications to use multiple addresses according to their own requirements. This proposal did not attain enough support in Internet Engineering Task Force (IETF) standardization. Nonetheless, it has the advantage of not requiring new infrastructure to be deployed [Ming et al., 2012].
Table 2.1: Multihoming support in application-layer protocols.
MH-Multihoming, OS-Operating System.
Protocol MH Goals Strengths Flaws Implementation
R U L F Simulators OS SIP X √ X X Widely available. Resilience can be supported. No flow distribution capabilities. Yes Yes NBS X √ X X Resilience can be supported. Not standardized. – Linuxa a[Ming et al., 2012]
enjoys widespread implementation, efficient mobility support, and can be extended to also support resilience. Such extension relies on the combination of SIP and SCTP. The same logic applies to NBS, that can support resilience if combined with SHIM6. But, in contrast to SIP, NBS represents a new concept and introduces modifications that may hinder its widespread implementation.
2.3.2 Operating Systems and Server Applications
Although most mobile devices have very rudimentary mechanisms for heterogeneous network access selection and management, modern operating systems have connec- tion managers to select the best path for applications based on preference sets (e.g. cost, bandwidth) [Wasserman and Seite, 2011]. Others explore techniques similar to IP aliasing to support multiple IP addresses due to the different (physical/virtual) net- work connections [IBM, 2001]. IP network multi-pathing (IPMIP) [SUN, 2009] extends the functionality of IP aliasing techniques by providing interface failure detection and by offering load sharing in systems with multiple interfaces.
Linux supports multipath routing by allowing the specification of multiple next hops for a given destination. The motivation for multipath routing can include toler- ance to failures (using a backup route) or load sharing to increase throughput [Ben- venutti, 2005]. While simple reliability can be based on the specification of several routes with different weights, load balancing requires more advanced mechanisms that can be based on identical weights such as the implemented Equal Cost Multipath (ECMP) algorithm [Hopps, 2000]. The distribution of traffic, under multipath config- uration, is based on routing cache entries to distribute traffic according to different algorithms, such as Weighted Round Robin. In FreeBSD 8.0, the routing infrastructure was modified to split layer2 (L2) and L3 information [Li and Macy, 2009]. This split introduces benefits that facilitate the utilization of parallel computing and introduce support for ECMP.
Server applications such as DHCP and File Transfer Protocol (FTP) can be config- ured according to the sets of each subnet a host can connect to. For instance, vsftpd, an FTP daemon, can be configured for multiple FTP domains [RedHat, 2013b]. Both approaches have drawbacks, since this kind of configuration requires IP addresses for each FTP domain and a multihomed DHCP server can perform differently for each network [RedHat, 2013a]. Apache, a web server, provides support for multihoming via virtual hosts [Foundation, 2013] that give the possibility of hosting several domains on a single physical machine. Domains can be identified on a name or IP configuration basis. In the last approach, a virtual host is configured based on a server IP address.