Transmitting Internet Protocol Packets Efficiently on Underwater Networks using Entropy-Encoder Header Translation

Transcription

1 Transmitting Internet Protocol Packets Efficiently on Underwater Networks using Entropy-Encoder Header Translation 5.6 Toby Schneider GobySoft, LLC Woods Hole, MA Abstract The Internet Protocol (IP) is ubiquitous in terrestrial and electromagnetic-carrier wireless networking. However, for very low-throughput underwater links (such as those using acoustic modems) the IP header introduces an unacceptable amount of data overhead for the small maximum transmission units available on underwater acoustic links. Nonetheless, it is becoming increasingly valuable to connect undersea deployments to the internet to provide data to researchers on shore, and facilitate remote command of deployed vehicles and sensors. This paper details a technique to reversibly translate the IPv4 header to allow IP packets to traverse acoustic links but with a header that is an order of magnitude smaller than a regular IPv4 header. In addition, this technique provides support for translating the User Datagram Protocol (UDP) header to provide scalable multiplexing. This technique works by dynamically partitioning the address space into the required subnet size based on the number of communicating nodes, and applying a Huffman entropy encoder to the address values based on the probabilistic data flow amongst the nodes. I. INTRODUCTION Oceanographic sensors and autonomous underwater vehicles (AUVs) are increasingly deployed with the expectation that their collected data (and in the other direction, commands) will be available in near real-time via a combination of satellite, cabled, and terrestrial networks which typically use the Internet Protocol (IP). However, the last links to many of these marine systems are often low-throughput, such as over acoustic modems. Fielded networks thus far with acoustic links has generally been to abandon the IP completely and use a custom protocol stack; examples are [1], [2], and [3]. These self-contained solutions lead to acceptable performance, but create a significant impedance mismatch when trying to integrate them into systems using the Internet Protocol. It would appear beneficial to have an option to support a subset of the IP while maintaining the low data overhead required by marine links. This paper outlines a technique for performing header translation on the IP (and the User Datagram Protocol (UDP) transport layer) which greatly reduces the size of the IP header by 1) removing features that are not widely used or do not make sense on underwater links. 2) reducing the addressing space to that required by the maximum number of communicating nodes in the sub-network (subnet). 3) collapsing the source and destination addressing into a single symbol which allows elimination of unused pairs. 4) encoding the addressing symbol and UDP ports using an Huffman entropy encoder that takes advantage of a non-uniform probability distribution of addressing to reduce the encoded packet size. A. Implementation This work was implemented in GNU/Linux using the open-source Dynamic Compact Control Language version 3 (DCCL3) [4] and Goby [2] projects. The goby_ip_gateway application 1 provides a tun interface (a virtual IP-layer networking device that can be used in much the same way as a physical Ethernet interface) on one side, and implements the interface to the Goby ModemDriver on the other. This allows this work to be used immediately with any of the existing or future Goby ModemDriver implementations, for example, over the WHOI Micro-Modem or Iridium satellite links. II. IP HEADER TRANSLATION The aim of this header translation is to combine the IP and UDP headers into a single combined Underwater 1 Source code is available at /16/$ IEEE 241

2 Internet Protocol v4 User Datagram Protocol Underwater NetHeader Version IP Header Differentiated Length services ECN Identification Frag. flags Total Length Total Length Fragment Offset Time To Live Protocol Header Checksum Protocol Source port Length variable length 32-bit word Source IP Address Destination IP Address Options Source/Destination Address Symbol 32-bit word Source Port Dest Port Dest port Checksum Fig. 1. Standard IPv4 and UDP Headers, with new Underwater NetHeader translated representation. Colored fields are preserved (though reduced in size) and gray fields are removed from the NetHeader. Total length is an optional field depending on whether the desired physical links to be used provide packet size information. NetHeader which takes significantly less data, allowing for a reasonable payload size on links that typically have small (order of 10s and 100s of bytes) maximum transmission units (MTUs). The standard IPv4 [5] and UDP [6] headers are given in Fig. 1 along with the NetHeader. Mapping the IP version 6 is a similar process; for the ease of exposition, only IPv4 would be considered. A. Removed and reduced fields Several parts of the IP header (see gray fields in Fig. 1) are removed from the remapped NetHeader because their use is unnecessary or redundant on underwater links. These fields include: Version: The assumption is that the same version (either 4 or 6) of IP is used throughout the last mile underwater links. IP Header Length: The length of the Underwater NetHeader is defined exactly by the size of each field in it, so there is no need for a separate length field. Identification, fragmentation flags, and fragment offset: underwater acoustic networks can have very high packet loss and high inter-packet periods which suggests that it is best to structure the packet payload to be atomically useful rather than rely on transport level fragmentation and reassembly. For example, scalar data files can be represented as a series of samples (with one or more samples per packet) and imagery can be sent using a progressive technique (see, for example, citemurphy2010wavelet). Header Checksum: most physical links provide a checksum for data integrity, making this checksum redundant. In the event that the checksum is not provided by the physical link, it is straightforward to implement it at the link layer interface (e.g. Goby ModemDriver). The removal of these fields reduces the IP header by nine bytes (excluding the possible Options field). In addition, several fields are reduced in size: Protocol: only a handful of protocols that run on IP are in use; thus, this field can be reduced to handle the ones that are sensible. Given the high latencies involved, Transmission Control Protocol (TCP) is unlikely to function acceptably on marine links. UDP, parts of the Internet Control Message Protocol (ICMP), and perhaps the Stream Control Transmission Protocol (SCTP) seem likely to be the protocols that would make sense to use over such low throughput links. Given this, the protocol field can be reduced to two bits (for an enumeration of up to four protocols). Total length: This field is redundant if the physical layer provides variable packet length support already (for example the WHOI Micro-Modem [7] packets or the Iridium Short-Burst Data protocol). In the case where the entire subnet uses such a physical link, this field should be omitted. Otherwise, it can be included to allow delineation of packets in a stream-based physical link (such as Hayes command set based modems). B. Collapsed address space After removing the fields as described in Section II-A, the main remaining space is used by the source and destination IP addresses (eight bytes total). The first way to greatly reduce the size of these fields is to limit the available addresses to the actual number of fielded nodes in the underwater subnet. This brings the space required for these addresses (in bits, b sd ) to b sd = log 2 N 2 a (1) where N a is the number of addresses in the network. In the case of a typical sized subnet of up to eight addresses, b sd = 6 bits /16/$ IEEE 242

3 TABLE I IP ADDRESS TO UNDERWATER NETHEADER SYMBOL MAPPING FOR 8-ADDRESS SUBNET (6 PHYSICAL NODES) a) b) a gate a gate Destination IP Address Source IP Address (within subnet) 0, , Note: source and destination addresses shown are the logical AND of the IP address and the complement of the subnet mask. For example, in the subnet /29, address is given as 3 above. Fig. 2. Examples of possible networks with varying values of autonomy () and collaboration (γ c). Part a) shows a highly autonomous network of sensors with no collaboration ( = 1, γ c = 0), and b) shows a group of tightly coupled vehicles ( > γ c > 0.5). This value can be reduced further by pairing the source and destination into a single value, the source/destination address symbol S[s, d] where { d(n a 2) + s s < d, s a broadcast S[s, d] = d(n a 2) + (s 1) s > d, s a broadcast (2) given that s is the source address and d is the destination address within the subnet. By doing so, the diagonals of Table I can be removed (since a packet destined to the same address from which it is originated never needs to be communicated over a physical link). In addition, the convention of IPv4 is to use the largest address in a subnet for broadcast packets, and to reserve the smallest address for subnet notation. By collapsing these into a single broadcast address (a broadcast ), and assuming that the source address of a valid packet will never be broadcast, this eliminates more symbols. Making these modifications, the bits required for the addresses (b sd ) is b sd = log 2 ( N 2 a 4(N s d 1) ) (3) Now, in the case of the eight-address subnet, b sd = 5.17 bits. While the partial bit saved is not useful here, one could now increase the subnet size to a ten-address subnet while still staying within 6 bits. C. Entropy encoding addresses The encoded space used by the source/destination address symbol could be further reduced by considering that certain pairs of addresses are more or less likely to occur in a given deployment of oceanographic sensors or autonomous vehicles. Let us designate an address (a gate, for example, for the eight-address subnet /29) for the gateway or topside node. This node can be the local destination for much of the traffic, and the source (as far as this subnet is concerned) of commands to any autonomous vehicles. Now, consider two non-dimensional factors with values that range [0, 1] that can parameterize the data flow: autonomy ( ), which weights the probability that a packet has the gateway source address and collaboration (γ c ), which weights the probability of packets amongst all the other source addresses, except those destined to the gateway. The difference -γ c is used to weight outbound traffic (i.e. with a destination of a gateway ) and to allow normalization of the probability mass function. A completely autonomous network ( = 1) needs no commands so it would have no data sent from the gateway node. A completely collaborative network (γ c = ) would have equal data flow between all the non-gateway nodes, and no outbound data (which may occur if no data is offloaded until the mission is complete). For example, a suite of pre-programmed independently collecting sea-floor sensors would likely have a large autonomy value, and a small or zero collaboration value. On the other hand, a fleet of small AUVs flying formation based on shared navigation data would have a large collaboration value (and an autonomy value that depends on how much operator direction is required). Fig. 2 illustrates two possible network scenarios. The probability P [S] of a given symbol is given by p 0 (1 ) s = a gate P [S[s, d]] = p 1 ( γ c ) d = a gate (4) p 2 (γ c ) s a gate, d a gate /16/$ IEEE 243

4 a) Client Server b) Source IP Address Destination IP Address c) dyn : 2 dyn : 2 s: d: 5001 s: 2 d: 0 s: d: 5001 UDP : 2 NetHeader : 2 UDP s: 5001 d: s: 0 d: 2 s: 5001 d: d) e) 001 Fig. 3. Illustration of the process of mapping and encoding the IP addresses (a) onto a final encoded value (e) in the Underwater NetHeader. The addresses are collapsed into a single symbol (b); an example is given in Table I. Then, the probability of each symbol (c) is computed based in the and γ c values as given in Eq. 4. The probability mass function is used to compute a Huffman dictionary (d), which is used to encode the source/destination symbol into a binary value (e). where normalizing constants p 0 = (N a 2) 1 (5) p 1 = (N a 3) 1 (6) p 2 = (N 2 a 6N a + 9) 1 (7) This formulation requires >= γ c to ensure that no symbols have negative probability, which makes sense intuitively since autonomous behavior is a precondition to collaborative behavior. Given this probability distribution, a Huffman [8] dictionary can be created to encode the single source/destination address symbol with close to optimality. Fig. 3 details the process from start to finish of encoding the source/destination value as explained in this section and Section II-B. D. UDP port reduction To support UDP port-based multiplexing, the Underwater NetHeader supports variable sized source and destination port fields. These ports can be designated as static, where there is a fixed mapping from UDP port to NetHeader port. Some ports can also be designated dynamic, so that the goby_ip_gateway application can temporarily map a given UDP source port to a dynamic NetHeader port so that replies to the same port are properly translated back into the correct UDP port. Fig. 4. Example of UDP port mapping to Underwater NetHeader ports. Here four ports are allocated (taking two bits each for source and destination port fields). When the sending side of goby_ip_gateway encounters an unknown port (e.g ), it maps it to the first unused dynamic port. Similarly, on receive, a new dynamic UDP port is requested (e.g ) from the system, allowing this mapping to be maintained for messages sent in the reverse direction (server to client) γ c Fig. 5. Expected value of source/destination symbol Huffman encoded size over the range of possible values of and γ c. Fig. 4 gives an example of this port mapping. This allows clients using dynamic ports to send messages to a server and receive a reply. The number of dynamic ports must be at least as many as the simultaneous sessions required. When the dynamic ports are exhausted, they are recycled starting with the first allocated port. III. RESULTS The expected value of the encoded size of the source/destination address symbol over the entire possible space of the autonomy and collaboration factors ( and γ c ) is shown in Fig. 5. The most compression is obtained when the network is asymmetric, such as when the autonomy is high and the collaboration is low. This corresponds to a network where most traffic is encoded size (bits) /16/$ IEEE 244

5 Expected value of Underwater NetHeader size (bits) uniform distribution = 1, γ c = 0 = 0.9, γ c = subnet size Fig. 6. Expected value of the entire Underwater NetHeader assuming a 2-bit protocol field, 3-bit destination and source port fields, and source/address fields based on Huffman encoding using the probability distribution P [S] for different values of, γ c, and subnet size N a. For comparison, the standard IPv4/UDP headers are at least 224 bits. directed towards the gateway node. In highly collaborative networks, the addressing is much more uniformly distributed amongst all possible source/destination pairs, so there is little or no gain from using the Huffman encoder. Fig. 6 shows the expected value of the size of the Underwater NetHeader as a function of subnet size for a uniform probability distribution, and two pairs of the autonomy and collaboration factors representative of the qualitative networks shown in Fig. 2. This technique shows significant promise for reducing the IP header into a size (2-3 bytes on average) that is acceptable for use with underwater links that may have maximum transmission units of only tens of bytes. IV. CONCLUSION This paper presents a technique for mapping a subset of the IP header (and higher level protocols such as UDP) onto a single Underwater NetHeader with substantially reduced size that would be acceptable for use on the low throughput links that are common in the marine operating environment (5-10% of the IP header, depending on the subnet size and data flow of the network). It would be of significant value to the underwater communications user community (AUV operators and ocean sensor deployers) to create a standard for this type of mapping. Since each underwater subnet must share the exact same parameters for encoding all the fields (especially the source/destination address symbol), some flexibility must be given for the designer of given subnet to choose his or her own parameters based on the nature of the deployed assets. A possibility would be to agree on a handful of pairs of autonomy and collaboration factors that represent realistic networks and are thus given as standard options. Combined with requiring that subnets must be powers of two in size, this would provide flexibility to the subnet designer without so much freedom as to remove the value of having a standard at all. ACKNOWLEDGMENT I would like to thank Jim Partan at the WHOI Micro- Modem group for the initial spark of this idea, and all those who have contributed to the diversity of open source software used in this work: GNU/Linux, IP, DCCL, and Goby. REFERENCES [1] M. Grund, L. Freitag, J. Preisig, and K. Ball, The PLUSNet underwater communications system: acoustic telemetry for undersea surveillance, in OCEANS IEEE, 2006, pp [2] T. Schneider and H. Schmidt, Goby-acomms version 2: extensible marshalling, queuing, and link layer interfacing for acoustic telemetry, in 9th IFAC Conference on Manoeuvring and Control of Marine Craft, Arenzano, Italy, [3] Z. Peng, Z. Zhou, J. H. Cui, and Z. J. Shi, Aqua-net: An underwater sensor network architecture: Design, implementation, and initial testing, in OCEANS 2009, MTS/IEEE Biloxi - Marine Technology for Our Future: Global and Local Challenges, Oct 2009, pp [4] T. Schneider, S. Petillo, H. Schmidt, and C. Murphy, The dynamic compact control language version 3, in OCEANS Genova, May 2015, pp [5] J. Postel, Internet protocol RFC 791, ARPANET Working Group Requests for Comments, no. 791, [6], Internet protocol RFC 768, ARPANET Working Group Requests for Comments, no. 768, [7] E. Gallimore, J. Partan, I. Vaughn, S. Singh, J. Shusta, and L. Freitag, The whoi micromodem-2: A scalable system for acoustic communications and networking, in OCEANS IEEE, 2010, pp [8] D. A. Huffman, A method for the construction of minimumredundancy codes, Proceedings of the IRE, vol. 40, no. 9, pp , Sept /16/$ IEEE 245