Rate Based Satellite Control Protocol

Satellite links have several characteristics that affect the performance of IP protocols over the link. The figure below shows that satellite links can have a one-way delay of 275 milliseconds. A round-trip time (RTT) of 550 milliseconds is a very long delay for TCP. Another issue is the high error rates (packet loss rates) that are typical of satellite links as compared to wired links in LANs. Even the weather affects satellite links, causing a decrease in available bandwidth, and an increase in RTT and packet loss.

Figure 1

Typical Satellite Link

Long RTT keeps TCP in a slow start mode, which increases the time before the satellite link bandwidth is fully used. TCP and Stream Control Transmission Protocol (SCTP) interpret packet loss events as congestion in the network and start to perform congestion recovery procedures, which reduce the traffic being sent over the link.

Although available satellite link bandwidths are increasing, the long RTT and high error rates experienced by IP protocols over satellite links are producing a high bandwidth-delay product (BDP).

To address the problem of TCP being kept in a slow start mode when a satellite link is used, a disruptive performance enhancing proxy (PEP) solution is introduced into the network. In the figure below you can see that the transport connection is broken up into three sections with hosts on the remote side connecting to the Internet through their default router. The router sends all Internet-bound traffic to the TCP PEP, which terminates the TCP connection to the Internet. The PEP generates a local TCP ACK (TCP spoofing) for all data. Traffic is buffered and retransmitted through a single PEP protocol connection over the satellite link. The second PEP receives the data from the satellite link and retransmits the data over separate TCP connections to the Internet. TCP transmission is disrupted, so dropped packets are not interpreted as TCP congestion and can be retransmitted from buffered data. Minimal TCP ACKs and reduced TCP slow starts allow more bandwidth to be used.

Figure 2

Disruptive TCP PEP Solution

One of the disadvantages to using disruptive TCP PEP is the breaking of the end-to-end model. Some applications cannot work when the flow of traffic is broken, and the PEP has no provision for handling encrypted traffic (IPSec). New transport protocols such as SCTP require special handling or additional code to function with disruptive TCP PEP. An additional managed network component is also required at every satellite router.

RBSCP has been designed to preserve the end-to-end model and provide performance improvements over the satellite link without using a PEP solution. IPSec encryption of clear-text traffic (for example a VPN service configuration) across the satellite link is supported. RBSCP allows two routers to control and monitor the sending rates of the satellite link, thereby increasing the bandwidth utilization. Lost packets are retransmitted over the satellite link by RBSCP preventing the end host TCP senders from going into slow start mode.

RBSCP is implemented using a tunnel interface as shown in the figure below. The tunnel can be configured over any network interface supported by Cisco IOS software that can be used by a satellite modem or internal satellite modem network module. IP traffic is sent across the satellite link with appropriate modifications and enhancements that are determined by the router configuration. Standard routing or policy-based routing can be used to determine the traffic to be sent through the RBSCP tunnel.

Figure 3

Nondisruptive RBSCP Solution

RBSCP tunnels can be configured for any of the following features.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip unnumbered interface-type interface-number

5.    tunnel source {ip-address | interface-type interface-number}

6.    tunnel destination {hostname | ip-address}

7.    tunnel bandwidth {receive | transmit} bandwidth

8.    tunnel mode {aurp | cayman| dvmrp| eon| gre| gre multipoint| ipip[decapsulate-any]| iptalk| mpls| nos| rbscp}

9.    tunnel rbscp ack_split split-size

10.    tunnel rbscp delay

11.    tunnel rbscp report

12.    tunnel rbscp window_stuff step-size

13.    exit

• What to Do Next
  

1.    enable

2.    show rbscp [all| state| statistics] [tunnel tunnel-number]

3.    exit

1.    enable

2.    show interfaces tunnel number [accounting

3.    exit

In the following example, Router 1 and Router 2 are configured to send traffic through an RBSCP tunnel over a satellite link.

interface Tunnel 0
 ip unnumbered ethernet1
 tunnel source ethernet1
 tunnel destination 172.17.2.1
 tunnel bandwidth transmit 1000
 tunnel mode rbscp
 tunnel rbscp ack_split 6
 tunnel rbscp report
!
interface ethernet1
 description Satellite Link
 ip address 172.20.1.2 255.255.255.0

interface Tunnel 0
 ip unnumbered ethernet1
 tunnel source ethernet1
 tunnel destination 172.20.1.2
 tunnel bandwidth transmit 1000
 tunnel mode rbscp
 tunnel rbscp ack_split 6
 tunnel rbscp report
!
interface ethernet1
 description Satellite Link
 ip address 172.17.2.1 255.255.255.0

To control the type of traffic that uses the RBSCP tunnel, you must configure the appropriate routing. If you want to direct all traffic through the tunnel, you can configure a static route.

Note	Remember to configure the tunnel interface as passive if dynamic routing protocols are used to prevent routing flaps.

The following example shows how to use policy based routing to route some specific protocol types through the tunnel. In this example, an extended access list allows TCP, Stream Control Transmission Protocol (SCTP), Encapsulating Security Payload (ESP) protocol, and Authentication Header (AH) traffic to travel through the tunnel. All IP traffic is denied.

interface Tunnel1
 ip unnumbered FastEthernet1/1
 tunnel source FastEthernet1/1
 tunnel destination 10.12.0.20
 tunnel mode rbscp
 tunnel ttl 5
 tunnel bandwidth transmit 30000
 tunnel rbscp window_stuff 1
 tunnel rbscp ack_split 4
!
interface FastEthernet0/0
 ip address 10.13.0.1 255.255.255.0
 ip policy route-map rbscp-pbr
 duplex auto
 speed auto
!
interface FastEthernet1/1
 description Satellite Link
 ip address 10.12.0.1 255.255.255.0
 duplex auto
 speed auto
!
ip route 10.15.0.0 255.255.255.0 FastEthernet1/1
!
ip access-list extended rbscp-acl
 permit tcp any 10.15.0.0 0.0.0.255
 permit 132 any 10.15.0.0 0.0.0.255
 permit esp any 10.15.0.0 0.0.0.255
 permit ahp any 10.15.0.0 0.0.0.255
 deny ip any any
!
!
route-map rbscp-pbr permit 10
 match ip address rbscp-acl
 set interface Tunnel1

ip dhcp pool CLIENT
 import all
 network 10.15.0.0 255.255.255.0
 default-router 10.15.0.1
 domain-name engineer.chicago.il.us
 dns-server 10.10.0.252
!
interface Tunnel1
 ip unnumbered FastEthernet0/1
 tunnel source FastEthernet0/1
 tunnel destination 10.12.0.1
 tunnel mode rbscp
 tunnel ttl 5
 tunnel bandwidth transmit 30000
 tunnel rbscp window_stuff 1
 tunnel rbscp ack_split 4
!
interface FastEthernet0/0
 description Local LAN
 ip address 10.15.0.1 255.255.255.0
 ip policy route-map rbscp-pbr
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description Satellite Link
 ip address 10.12.0.20 255.255.255.0
 duplex auto
 speed auto
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
!
ip access-list extended rbscp-acl
 permit tcp any any
 permit 132 any any
 permit esp any any
 permit ahp any any
 deny ip any any
!
route-map rbscp-pbr permit 10
 match ip address rbscp-acl
 set interface Tunnel1