49.1. Overview

AIPT2 is the second version of the Abilis IP tunnel protocol. This new type of resource offers the possibility to create a tunnel with up to 6 paths, and use them for load balancing and/or for redundancy (former AIPT double path now AIPT2 multipath), as well as for backup purposes by means of dependency setting. It simplifies configurations and improves performances.

[Important]Important

AIPT2 works only with Abilis devices with software version > 8.6.

AIPT2 serves to achieve these goals:

One side of the AIPT2 tunnel must be configured as a ‘server’, the other as a ‘client’. The server side requires a valid address on the Internet (type 82.33.143.22 or FQDN), the client side is independent of the addresses. It is the client's responsibility to establish the connection to the desired server. If the server has multiple addresses, the list can be indicated.

The authentication of the client by the server takes place through protected/encrypted modes, making use of the client's Abilis-ID or a pair of "keys" (LOCKEY, REMKEY).

AIPT2 uses 256 bit AES encryption. The encrypted packets are sent on the available lines (paths) according to the chosen operating mode (PATHSMODE: BALANCE or REDUNDANT or MIXED). In the BALANCE operating mode the packets are distributed on the available paths, thus allowing a more rapid transmission of information. In the REDUNDANT operating mode, a copy of each packet is transmitted by means of each path designated for this service. How each path must work is indicated by the MPx parameter (MP1 for path 1, MP2 for path 2, ...).

The correct functionality of each path is controlled by AIPT2 by means of the periodic exchange of probe packets (LC link-check). When a path fails to give the requested service it is automatically taken out of service (and readmitted, when the operating conditions are good again).

The correct functionality of each path depends on how much the lines are loaded. In case of overload, there is a high loss of packets and this causes the deterioration of the performance of the AIPT2 connection, especially when the paths are used in BALANCE mode. To prevent this from happening at least in "normal" network conditions, the AIPT2 paths are speed-regulated, so as not to exceed the normal line capacity (OUTSPx parameters).

The configuration of the AIPT2 tunnels is complex, but fortunately in most cases only a few parameters have to be entered, the others remaining at default values.

In VPN networks with many similar peripheral points it is appropriate to use the PROVISIONING system, described here.

The main characteristics of AIPT2 are:

[Important]Important

The tunnel packets, i.e. control and encapsulated payload, that AIPT2 sends out obey IPACL for all parameters except for IPCOS which is enforced by means of C-IPCOS and D-IPCOS parameters. On the contrary the clean payload, i.e. decapsulated packets, fully obey IPACL.

In the example below:

Server:

[21:56:35] ABILIS_CPX:d p ip-11

RES:Ip-11 - Abilis IP tunnel v.2 (AIPT2) --------------------------------------
Run    DESCR:
       LOCATION:
       OPSTATE:UP                   STATE-DETECT:NORMAL        CAT:AUTO (VPN)
       LOG:NO                       ALERT:NO
       IPADD:172.020.011.205   MASK:255.255.255.000   NEIGH:000.000.000.000
       NEIGH-USER:                                    NEIGH-PROT:PLAIN
       NEIGH-PWD:                                     NEIGH-PORT:AUTO
       REDIS:YES     HIDE:NO         RP:NONE            IPSEC:NO       VRRP:NO
       NAT:VPN                       DIFFSERV:NO        DDNS:NO
       OUTBUF:250    OUTQUEUE:FAIR   MTU:1500           
       OUTSPL:NO     
       INBUF:0                       mru:1500           SRCV:NO
       - TRFA section ---------------------------------------------------------
       TRFA:NO      
       - IP Tunnel ------------------------------------------------------------
       ROLE:SERVER   CR:YES    COMP:NO       FRAGSIZE:1480  TRY:5     TOUT:5000
       LOCKEY:ip11             LOCPORT:4011  C-TOS:0-D      DLY-UP:10 THR-DN:30
       REMKEY:ip11                           C-IPCOS:HIGH   DLY-TOUT:3
       REMABILIS-ID:           RS-BUF:250    D-TOS:0-N      BURST:1
       REDMODE:AUTO            REORDER:AUTO  D-IPCOS:COPY   BURST-DLY:100
       REDCOPY:AUTO            FEC:NO        BOD:YES
       NUMPATHS:6
       - IP Tunnel Paths --------------------------------------------------------
       x    MPx: OUTSPx: OUTx:     LOCIPx:         REMIPx:
       OSx:                        GWx:            SPL-OVHx:
       ----+----+-------+---------+---------------+------------------------------
       1   |     AUTO    AUTO      *               *
       2   |     AUTO    AUTO      *               *
       3   |     AUTO    AUTO      *               *
       4   |A    AUTO    AUTO      *               *
       5   |A    AUTO    AUTO      *               *
       6   |     AUTO    AUTO      *               *

Client:

[21:53:49] ABILIS_CPX:d p ip-11

RES:Ip-11 - Abilis IP tunnel v.2 (AIPT2) --------------------------------------
Run    DESCR:
       LOCATION:
       OPSTATE:UP                   STATE-DETECT:NORMAL        CAT:AUTO (VPN)
       LOG:NO                       ALERT:NO
       IPADD:172.020.011.206   MASK:255.255.255.000   NEIGH:000.000.000.000
       NEIGH-USER:                                    NEIGH-PROT:PLAIN
       NEIGH-PWD:                                     NEIGH-PORT:AUTO
       REDIS:YES     HIDE:NO         RP:NONE            IPSEC:NO       VRRP:NO
       NAT:VPN                       DIFFSERV:NO        DDNS:NO
       OUTBUF:250    OUTQUEUE:FAIR   MTU:1500           
       OUTSPL:NO     
       INBUF:0                       mru:1500           SRCV:NO
       - TRFA section ---------------------------------------------------------
       TRFA:NO      
       - IP Tunnel ------------------------------------------------------------
       ROLE:CLIENT                           FRAGSIZE:1480  TRY:5     TOUT:5000
       LOCKEY:ip11             LOCPORT:4011  C-TOS:0-D      DLY-UP:10 THR-DN:30
       REMKEY:ip11             REMPORT:4011  C-IPCOS:HIGH   DLY-TOUT:3
       REMABILIS-ID:           RS-BUF:250    D-TOS:0-N      BURST:1
       REDMODE:AUTO            REORDER:AUTO  D-IPCOS:COPY   BURST-DLY:100
       REDCOPY:AUTO            FEC:NO        BOD:YES
       NUMPATHS:6
       - IP Tunnel Paths --------------------------------------------------------
       x    MPx: OUTSPx: OUTx:     LOCIPx:         REMIPx:
       OSx: DEPx:        BCK-CHKx: GWx:            SPL-OVHx:
       ----+----+-------+---------+---------------+------------------------------
       1   |     AUTO    AUTO      OUT-IP          #
       2   |     AUTO    AUTO      OUT-IP          172.020.002.205
       3   |     AUTO    AUTO      OUT-IP          172.020.002.205
       4   |A    AUTO    AUTO      OUT-IP          172.020.002.205
       5   |A    AUTO    AUTO      OUT-IP          172.020.002.205
       6   |     AUTO    AUTO      OUT-IP          172.020.002.205
            2|3          #         #               AUTO
       - Controller preferences -----------------------------------------------
       CONTROL:NONE

49.1.1. Treatment of data

When a packet needs to be sent through a tunnel composed of one or more bundled paths, it follows a default rule that evenly redistributes throughput among the available paths, aiming to ensure similar utilization percentages (determined by the ratio of generated throughput to maximum bandwidth, known as THR%). In this case, THR% is the sole criterion for choosing the path for each outgoing packet. The same rule is also applied to any backup packets (which could be simple copies or parity packets generated by FEC).

With the introduction of preferences (parameter CONTROL:), we distinguish preferential traffic from overall traffic. This preferential traffic follows more detailed and targeted rules based on defined types: VoIP, VPN, STREAMING, SURFING. Preferential traffic is identified using filter parameters that allow identification of the socket(s) of outgoing packets (SA: DA: PROT: PO: SPO: DPO:). By default, the filter is set to ANY.

In addition to the THR% parameter, preferences introduce:

  • MISS% (percentage of packets lost relative to packets sent)

  • JITTER (variation in the delay of received packets)

  • RTT (roundtrip time, the time for packets to complete a round trip)

Depending on the set preference, these four parameters are assigned different weights (some may have a weight of zero) in identifying the best paths. The sum of these weights gives the path score, which is used as a rating for packet transmission.

Preference settings (CONTROL:):

  • NONE (default): No preferential traffic filters are used; packet redistribution is only based on THR%.

  • VoIP (voice over IP): Original traffic is distributed on the most suitable path, redundant traffic (copies of the original packet) on the second most suitable path (both paths understood as having the best total score). The path score is evaluated using the following weights: MISS (40%), JITTER (33%), and RTT (27%). In practice, the path evaluation score is composed using these weighted percentages. Packet loss has the greatest impact, followed by JITTER and RTT. THR% is not considered for VoIP traffic.

  • VPN (interactive traffic - Interactive Video - Videogames): Original traffic is distributed on the most suitable path, redundant traffic on the path with the least packet loss (MISS%). The path score is evaluated using the following weights: RTT (33%), THR (28%), JITTER (22%), and MISS (17%). All four parameters influence the total path score.

  • STREAMING (Video streaming): Original traffic is distributed on the most suitable path, redundant traffic on the path with the least packet loss (MISS%). The path score is evaluated using the following weights: THR (67%) and MISS (23%). JITTER and RTT are not considered for streaming traffic. Throughput contributes approximately 2/3 to the overall score, while packet loss contributes the remaining 1/3.

  • SURFING (Browsing): Surfing is similar to streaming: original traffic is distributed on the most suitable path, redundant traffic on the path with the least packet loss (MISS%). The path score is evaluated using the following weights: MISS (63%) and THR (37%). JITTER and RTT are not considered for SURFING traffic. Packet loss contributes approximately 2/3 to the overall score, while throughput contributes the remaining 1/3.

PREFERENCESNONEVoIPVPNSTREAMINGSURFING
The weight of parameters for the quality of the Path/RouteThroughput 100%Missing 32%RTT 33%Throughput 67%Missing 62%
Throughput 26%Throughput 28%
Jitter 26%Jitter 22%Missing 33%Throughput 33%
RTT 16%Missing 17%
Redundancy By default, redundant packets are sent on the path with the second best score