Icon-PEPEnabling IP Applications over HF Networks
Icon-PEP enables deployment of IP Applications over an HF network using STANAG 5066 link layer as the interface to that network.
Icon-PEP provides two core services:
- Generic switching of IP packets over an HF network, causing it to act as an IP subnet. This enables support of any IP applications.
- Optimized support for TCP over IP using a Performance Enhancing Proxy (PEP) to optimize TCP performance over HF.
This enables a wide range of applications, such as Web browsing, to operate over HF. While in principle any application can be run, the choice of application in practice is constrained by the limited bandwidth and high latency of HF communication.
The basic deployment model is shown below, a pair of IP applications (e.g., a Web client and a Web server) are separated by HF. At a very high level, Icon-PEP is enabling this communication. The diagram omits components between IP Application/Icon-PEP and between Icon-PEP/HF Network.
The communication between a pair of IP applications proceeds over a sequence of IP subnets, each one connected by a router, as shown below. Icon-PEP enables an IP subnet to be created over HF, which forms one step in the complete IP communications setup.
The diagram below shows how Icon-PEP provides an IP subnetwork.
Icon-PEP operates over the STANAG 5066 HF Link layer, and connects to a STANAG 5066 server such as Isode’s Icon-5066 product using the STANAG 5066 SIS protocol. This cleanly decouples Icon-PEP from the STANAG 5066 link layer.
It is important to note that Icon-PEP connects to an IP router, and not directly to a host (end system) or to an application. This gives flexibility to support many applications and hosts with a single Icon-PEP server.
Icon-PEP communicates with one or more IP Routers using Generic Routing Encapsulation (GRE), specified in RFC 2784. GRE provides a simple mechanism to exchange packets between routers over IP, often described as a “GRE Tunnel”. Icon-PEP terminates the GRE tunnel from a connected IP router. This means that there is no requirement for a peer system to use GRE.
GRE is widely supported by Edge routers, and it is anticipated that Icon-PEP will generally connect to the deployed router. For subnets or single hosts that do not deploy a router, or where the deployed router does not support GRE, it is possible to use a software router, such as the one provided on many Linux systems or a product such as pfSense running in a virtual machine.
IP Switching and PEP
Icon-PEP provides two services. The first is simply to switch IP packets. This follows STANAG 5066 Annex F.12 “IP Client” services for operating an IP subnet over HF. It simply transfers the IP packet. Icon-PEP provides controls based in the IP protocol used and ports within the protocol (e.g., ICMP, UDP). Packets can be handled differently based on protocol, including blocking, and choosing between ARQ and non-ARQ transfer.
Operation using IP Client is described in detail in the Isode whitepaper [Measuring and Analysing STANAG 5066 F.12 IP Client]. This shows that IP Client works well for some services, such as ICMP Ping, but not for others including TCP. Icon-PEP supports IPv4 (complying to STANAG 5066 Ed3 and Ed4) and supports IPv6 complying to STANAG 5066 Ed4 Annex U.
The second service uses a performance enhancing proxy (PEP) architecture to give optimized performance for TCP applications. In this TCP Proxy architecture, an application is communicating over TCP, running over IP in the normal manner. The TCP connection from each application is terminated at the point it interacts with Icon-PEP, rather than continuing on to the other application. Icon-PEP then communicates over HF using the HF-PEP protocol specified in [HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9)]. This approach means that only the data stream is passed over HF, rather than the entirety of a TCP connections ACKs (acknowledgements) or window-handling, which avoids the issues with running TCP over IP Client, leading to significant performance and reliability improvements.
HF-PEP operates over SLEP (SIS Layer Extension Protocol), specified in S5066-APP3. SLEP provides the Stream Services used by HF-PEP, including data compression. SLEP communicates over STANAG 5066, using the local STANAG 5066 SIS (Subnet Interface Service) to connect. Icon-PEP is carefully tuned for HTTP usage, so that typical small transfers can be handled with a single HF round trip. Further details on HF-PEP and performance measurements using Icon-PEP are provided in the Isode whitepaper [Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF].
Because IP Client switches any IP packet, it is possible to run any IP application over HF using Icon-PEP. In practice the constrained bandwidth and high latency of an HF link is going to limit the choice of applications that can usefully be used.
IP Client is appropriate for low volume applications such as DNS lookup. It will generally perform poorly for applications performing bulk transfer. Where applications such as messaging and XMPP have optimized mappings onto STANAG 5066, it is preferable to use these optimized mappings rather than Icon-PEP. Many IP applications use TCP and many of those are based on HTTP (the Web protocol) running over TCP. Icon-PEP is intended to support Web, noting that performance can be improved by tuning the Web Server and Web Site for access using HF.
Icon-PEP will ensure that TCP efficiently uses the HF network. This will often lead to delays. Applications with high volumes of data, lots of handshaking and short application timeouts will not work well over HF, even with Icon-PEP. However, there is a large class of TCP applications that it is anticipated can be usefully deployed using Icon-PEP.