Genie's Tech Blog

Where knowledge has no dimensions

Rate-Based Satellite Control Protocol

Hi All,

Today we will be discussing about Rate Based Satellite Control Protocol (RBSCP). RBSCP is a tunneling method designed by Cisco for wireless or long-distance delay links, such as satellite links, which are having high latency or error rates. Satellite links are generally used by companies to connect some of their remote offices to the HQ site data center. Below are the characteristics of the Satellite Links:

- Large round trip time (RTT) delays (550ms typical)
- Relatively high error / high packet loss rates (1-6% loss)
- Depending on transmission technology, weather causes increased RTT or packet loss rate.

In order to overcome the challenges of the Satellite Links, Disruptive TCP performance enhancing proxy (PEP) to the network was introduced. Below are the benefits of TCP PEP:

- PEP generates a local TCP ACK (TCP Spoofing) for all data which greatly reduced TCP slow start (congestion window)
- It buffers all data from the end hosts.
- Since TCP flows do not exist across the satellite, dropped packets are not interpreted as congestion and the dropped packets can be retransmitted from buffered data.
- Helps increase available bandwidth.

 

 

The above topology depicts show the RSCP tunnel will be setup to get the communication over the Satellite links. Lets now have a look at the configuration:

Config on R1:
==========
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel100
 ip unnumbered GigabitEthernet0/1
 tunnel source GigabitEthernet0/1
 tunnel mode rbscp
 tunnel destination 12.12.12.2
 tunnel bandwidth transmit 1000
 tunnel rbscp delay
 tunnel rbscp window-stuff 1
 tunnel rbscp ack-split 4
!
interface GigabitEthernet0/1
 ip address 12.12.12.1 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
ip route 2.2.2.2 255.255.255.255 Tunnel100 name LAN2
!

Config on R2:
=========
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel100
 ip unnumbered GigabitEthernet0/1
 tunnel source GigabitEthernet0/1
 tunnel mode rbscp
 tunnel destination 12.12.12.1
 tunnel bandwidth transmit 1000
 tunnel rbscp delay
 tunnel rbscp window-stuff 1
 tunnel rbscp ack-split 4
!
interface GigabitEthernet0/1
 ip address 12.12.12.2 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
ip route 1.1.1.1 255.255.255.255 Tunnel100 name LAN1

From the above config, you can notice that the tunnel mode of tunnel 100 is configured as "rbscp". The "tunnel rbscp delay" is an optional config to enable RBSCP tunnel delay. Its recommended to use this command if link RTT > 700ms. You can also specify the bandwidth of the tunnel using the "tunnel rbscp bandwidth" option. Rest all the additional rbscp config automatically comes in which you can configure according to the type of the link and the latency or tcp window size on it. Lets now verify the route and also the tunnel state.

Output on R1:
==========
R1#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Tunnel100
      Route metric is 0, traffic share count is 1

R1#sh ip cef 2.2.2.2 det
2.2.2.2/32, epoch 0, flags [attached]
  attached to Tunnel100


R1#show rbscp state
Tunnel100 is up, line protocol is up
RBSCP operational state:  OPEN
RBSCP operating mode: (26Eh) delay dual_delay ack_split window_stuffing inorder SCTP_report
  window step: 1
  drop scale : 0
  ACK split size: 4
  input drop scale: 2
  initial TSN: 1h
  fuzz factor: 0
  max burst: tunnel 16, network 16
  next TSN: 18h
  next sequence: 84h
  current outstanding: 0
  out with no ack: 0
  max out per RTT: 1500
  packets since SACK: 0
  cumulative ack: 12h
  TSN at SACK: 12h
  last cumulative ack: 17h
  last delivered TSN: 12h
  next FWDTSN corr: 1h
  RTO: 166 ms
  RTT: 12 ms      srtt_sa: 46     srtt_sv: 13
  sentQ: num packets: 0, num bytes: 0
  tmitQ: num packets: 0, num bytes: 0

R1#

R1#show rbscp statistics 
Tunnel100 is up, line protocol is up
RBSCP protocol statistics:
  Init FWD-TSNs sent 0, received 0
  TUNNEL-UPs sent 0, received 1
  CLOSEDs sent 0, received 0
  TSNs sent 23, resent 0, lost by sender: gap 0, timeout 0
  TSNs received 18 (duplicates 0)
  FWD-TSNs sent 222 (heartbeats 136)
  FWD-TSNs received 0 (ignored 136)
  FWD-TSNs caused 0 packet drops, 0 whole window drops
  SACKs sent 155, received 159 (ignored 0)
  Recovered with RTX 0
  Received with delay 0
  Packets released into: tunnel 400, network 18
  Failed sends into the: tunnel 0, network 0
  Most released at once: tunnel 1, network 1
  Dropped due to: excess delay 0, tmit queue full 0
  Dropped detunneled packets 0
  Max on any queue: num packets: 1, num bytes: 148
  Max outstanding: 148

R1# 

R1# ping 2.2.2.2 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/9/13 ms
R1#

In the above output, we can see that the prefix 2.2.2.2 is reachable via Tunnel 100. Also from the show rbscp state | statistics command, we can see that the tunnel state is up/up and its operational. These commands also help in troubleshooting the issue if there are any packet drops noticed on the link which may be due to excess delay or some other issue.

Hope this post was helpful.

Please feel free to reach out to me in case you have any question.

Cheers...!!!

Comments are closed