Icon-PEP

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.

Deployment Model

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 U “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 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 and IPv6 complying to STANAG 5066 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 all of the TCP protocol with its overheads and functionality such as, ACKs (acknowledgements) and window-handling. The PEP approach 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].

Icon-PEP acts as an IP router and supports two models of IP routing:

Fixed routing. Icon-PEP configures IP networks associated with each peer STANAG 5066 node and routes IP traffic according to this. This can include a default route, which enables a mobile unit to route all traffic to a shore node by default.
NAT model, which is intended for a shore node to support traffic from any mobile unit without the shore node being aware of the IP networks used by the mobile unit. It does this by performing Network Address Translation (NAT). This mode only supports IP traffic initiated by a mobile unit. IP traffic then originates from Icon-PEP and does not use GRE.

Icon-PEP supports rules for IP and TCP traffic that allows control of traffic. Rules can match on:

Protocol (port for TCP; protocol/port for IP).
Source and Destination IP address matching against a list of IP subnetworks.

Rules can control:

Blocking traffic that matches the rule.
Setting non-default parameters for matching traffic

STANAG 5066 Priority
ARP/Non-ARQ choice (for IP traffic)

Supported Applications

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.

Configuration

Icon-PEP has full web management, supporting configuration, control and monitoring. Operator and administrator authentication is provided using OAuth.

The configuration UI enables full configuration of Icon-PEP including:

Router connection with GRE.
Connections to STANAG 5066 Server
IP routing and NAT mode configuration
Traffic rules for IP and TCP traffic

Control

Icon-PEP provides a control function, which allows an operator to enable or disable Icon-PEP. This may be useful in poor HF conditions, where it is desired to give priority to non-IP applications.

Monitoring

Icon-PEP provides five monitoring options in the web monitoring interface. Three of these are primarily to support initial setup and debug.

Monitoring of all IP traffic over GRE with the router.
Monitoring of IP traffic (excluding TCP) exchanged with the STANAG 5066 server.
Monitoring of all Icon-PEP logging metrics.

There is a special monitoring interface for DNS (Domain Name Service) shown above. IP services make extensive use of DNS and it is useful to monitor this independently, so that queries and answers can be observed.