IP Routing Over HF

Experience with Icon-PEP

Isode’s Icon-PEP product implements STANAG 5066 Annex U IP Client and HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9) to provide efficient TCP and Web Browsing over HF.

IP Client operates at the IP routing level, and so Icon-PEP works effectively as an IP Router.   Icon-PEP uses Generic Routing Encapsulation (GRE) specified in RFC 2784 to communicate with a general purpose router.   Icon-PEP provides two models of IP routing:

1. Fixed routing, with IP networks configured to be associated with specific STANAG 5066 addresses.
2. NAT model, which enables a Mobile Unit (MU) to initiate a connection to a shore system. The shore system will map IP addresses so that MU-initiated communication will work from an MU with any IP network.

This model supports a wide range of communication scenarios.

Additional Requirements for IP Routing

There are a number of scenarios which these capabilities do not meet all requirements.  In particular:

1. Where MUs move between HF networks, there is no mechanism for sending IP traffic from shore to the MU.
2. Where there is a complex and changing topology of nodes communicating over HF and with faster links, there is no mechanism for IP routing to adapt to topology changes.

Both of these need a more generic IP routing mechanism.

IP Routing Models

There is extensive literature on IP routing, but two basic models are useful to note here.

1. Distance Vector protocols provide a straightforward mechanism, by sharing a list of routes and noting the “distance” to each. Routing Information Protocol (RIP) is a widely known distance vector protocol, as the original Internet routing protocol.
2. Link State Protocols, such as the popular Open Shortest Path First (OSPF) protocol share information on links that enable topology to be determined. In complex scenarios, this approach enables better choices to be made than distance vector.

For HF, it is proposed to use the HF-RIP distance vector protocol for two reasons:

1. Routing over HF is going to be quite simple and systems outside HF will be faster and will choose to use an HF link as last resort.
2. It is important for the routing protocol used over HF to be efficient, as HF is a poor channel.

Note that it is straightforward to mix routing protocols and a typical router will be able to do this.  State is represented by the routing tables used in a router, which can be externally presented

HF-RIP

HF Routing Information Protocol (HF-RIP) is published as S5066-APP12 (***URL**).   It is modelled on RIP and optimized for HF.    It supports both IPv4 and IPv6 networks.   HF-RIP defines  three types of HF Node:

1. “Shore”.  An HF node with connection to strategic networks that other HF nodes can use as a default route all IP networks.   A shore node does not share routing information.
2. “MU” (Mobile Unit).  An HF node without further connections.   An MU node will have a  very stable set of IP Networks, which means that other nodes can cache the routing information for an extended period of time.
3. “Relay”.  An HF node that has dynamic IP connectivity and may support local and remote IP networks that will vary more rapidly.

All nodes will share their existence with other nodes at appropriate intervals.   MU and Relay nodes will also share a list of IP Networks to which the node can route traffic.   This provides dynamic IP routing update across the HF network.

STANAG 5066 Annex S – List Peer Nodes

To keep local routing up to date an HF node needs to know the link status of each peer.   This can be determined by the routing process in the node sending traffic to a peer.  However, this is information that the local STANAG 5066 server will usually know, either due to use of Annex L WTRP at the MAC layer, which actively shares node status or by monitoring traffic. To optimize performance, the HF Node can use a SIS protocol extension to list peer nodes.  This information can be used to update peer IP routers with status and also to determine if the local HF node is lacking current IP routing information.

This extension has been specified by Isode and is incorporated in a proposed update for the SIS protocol in STANAG 5066 Annex S in Edition 5.

Operation with TCP and HF-PEP

Isode’s Icon-PEP product implements HF-PEP (S5066-APP9) to improve TCP performance.   This utilizes the IP routing capability of Icon-PEP.    When dynamic IP routing is used,  TCP connections will break if routing changes.   In general they will re-establish.   Use of TCP is going to be viable provided that:

1. Routing is relatively stable. It will not work if there is rapid routing changes or load sharing.
2. Most TCP applications will not lose/duplicate significant amounts of data if the connection resets.

It is expected that these conditions will normally be the case.

Implementation Approach

This section finished with a summary of how these protocols will be used in a future implementation that extends Icon-PEP.

Icon-PEP will communicate IP routing information with IP Client peers using HF-RIP.  Icon-PEP will obtain peer status information using List Peer Nodes over SIS.

Locally, Icon-PEP will communicate with an associated local IP router using GRE.  It will exchange IP routing information using RIP-2 (IPv4) or RIP-NG (IPv6).   This enables the HF network to obtain and share routing information with other routers.

The local IP router will onwards share routing information.   This is anticipated to use other routing protocols such as OSPF.

Conclusions

This paper has shown how dynamic IP routing can be efficiently achieved over an HF network using HF-RIP and a SIS extension, in a manner that can be shared with external routers.