TCP accelerator for DVB-RCS SATCOM dynamic bandwidth environment with HAIPE

摘要

A high assurance IP encryption (HAIPE) compliant protocol accelerator is proposed for military networks consisting of red (or classified) networks and black (or unclassified) networks. The boundary between red and black sides is assumed to be protected via a HAIPE device. However, the IP layer encryption introduces challenges for bandwidth on demand satellite communication. The problems experienced by transmission control protocol (TCP) over satellites are well understood: While standard modems (on the black side) employ TCP performance enhancing proxy (PEP) which has been shown to work well, the HAIPE encryption of TCP headers renders the onboard modem's PEP ineffective. This is attributed to the fact that under the bandwidth-on-demand environment, PEP must use traditional TCP mechanisms such as slow start to probe for the available bandwidth of the link (which eliminates the usefulness of the PEP). Most implementations recommend disabling the PEP when a HAIPE device is used. In this paper, we propose a novel solution, namely broadband HAIPE-embeddable satellite communications terminal (BH-eST), which utilizes dynamic network performance enhancement algorithms for high latency bandwidth-on-demand satellite links protected by HAIPE. By moving the PEP into the red network and exploiting the explicit congestion notification bypass mechanism allowed by the latest HAIPE standard, we have been able to regain PEP's desired network enhancement that was lost due to HAIPE encryption (even though the idea of deploying PEP at the modem side is not new). Our BHeST solution employs direct video broadcast-return channel service (DVB-RCS), an open standard as a means of providing bandwidth-on-demand satellite links. Another issue we address is the estimation of current satellite bandwidth allocated to a remote terminal which is not available in DVB-RCS. Simulation results show that the improvement of our solution over FIX PEP is significant and could reach up to 100%. The improv-n-nement over the original TCP is even more (up to 500% for certain configurations).