Downloads |
 Feedback
|
Table Of Contents
Rate Based Satellite Control Protocol
Restrictions for Rate Based Satellite Control Protocol
Information About Rate Based Satellite Control Protocol
Performance Enhancing Proxy over Satellite Links
How to Configure Rate Based Satellite Control Protocol
Verifying that the RBSCP Tunnel Is Active
Configuration Examples for Rate Based Satellite Control Protocol
Configuring the RBSCP Tunnel: Example
Configuring Routing for the RBSCP Tunnel: Example
Feature Information for Rate Based Satellite Control Protocol
Rate Based Satellite Control Protocol
Rate Based Satellite Control Protocol (RBSCP) was designed for wireless or long-distance delay links with high error rates, such as satellite links. Using tunnels, RBSCP can improve the performance of certain IP protocols, such as TCP and IP Security (IPSec), over satellite links without breaking the end-to-end model.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for AToM NSF" section on page 10.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Restrictions for Rate Based Satellite Control Protocol
•
•
•
•
Restrictions for Rate Based Satellite Control Protocol
•
•
•
Information About Rate Based Satellite Control Protocol
•
IP over Satellite Links
Satellite links have several characteristics that affect the performance of IP protocols over the link. Figure 1 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).
Performance Enhancing Proxy over Satellite Links
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 Figure 2 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 over Satellite Links
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 Figure 3. 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.
Time Delay
One of the RBSCP routers can be configured to hold frames due for transmission through the RBSCP tunnel. The delay time increases the RTT at the end host and allows RBSCP time to retransmit lost TCP frames or other protocol frames. If the retransmission is successful, it prevents lost frame events from reaching the end host where congestion procedures would be enabled. In some cases the retransmission can be completed by RBSCP without inserting the delay.
ACK Splitting
Performance improvements can be made for clear-text TCP traffic using acknowledgement (ACK) splitting in which a number of additional TCP ACKs are generated for each TCP ACK received. TCP will open a congestion window by one maximum transmission unit (MTU) for each TCP ACK received. Opening the congestion window results in increased bandwidth becoming available. Configure this feature only when the satellite link is not using all the available bandwidth. Encrypted traffic cannot use ACK splitting.
Window Stuffing
Clear-text TCP and SCTP traffic can benefit from the RBSCP window stuffing feature. RBSCP can buffer traffic so that the advertised window can be incremented up to the available satellite link bandwidth or the available memory in the router. The end host that sends the packets is fooled into thinking that a larger window exists at the receiving end host and sends more traffic. Use this feature with caution because the end host may send too much traffic for the satellite link to handle and the resulting loss and retransmission of packets may cause link congestion.
SCTP Drop Reporting
SCTP uses an appropriate byte counting method instead of ACK counting to determine the size of the transmission window, so ACK splitting does not work with SCTP. The RBSCP tunnel can generate an SCTP packet-dropped report for packets dropped across the satellite but not as a result of congestion loss. This SCTP drop reporting is on by default and provides a chance to retransmit the packet without affecting the congestion window size. Actual congestion losses are still reported, and normal recovery mechanisms are activated.
How to Configure Rate Based Satellite Control Protocol
•
•
•
Configuring the RBSCP Tunnel
Perform this task to configure the RBSCP tunnel. Remember to configure the router at each end of the tunnel.
Prerequisites
Ensure that the physical interface to be used as the tunnel source in this task is already configured.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
DETAILED STEPS
What to Do Next
This task must be repeated on the router on the other side of the satellite link. Substitute the sample IP addresses, host names, and other parameters for the appropriate values on the second router.
Verifying that the RBSCP Tunnel Is Active
Perform this task to verify that the RBSCP tunnel configured in the "Configuring the RBSCP Tunnel" task is active.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying the RBSCP Traffic
Perform this task to verify that the traffic is being transmitted through the RBSCP tunnel and across the satellite link.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuration Examples for Rate Based Satellite Control Protocol
•
•
Configuring the RBSCP Tunnel: Example
In the following example, Router 1 and Router 2 are configured to send traffic through an RBSCP tunnel over a satellite link.
Router 1
interface Tunnel 0ip unnumbered ethernet1tunnel source ethernet1tunnel destination 172.17.2.1tunnel bandwidth transmit 1000tunnel mode rbscptunnel rbscp ack_split 6tunnel rbscp report!interface ethernet1description Satellite Linkip address 172.20.1.2 255.255.255.0Router 2
interface Tunnel 0ip unnumbered ethernet1tunnel source ethernet1tunnel destination 172.20.1.2tunnel bandwidth transmit 1000tunnel mode rbscptunnel rbscp ack_split 6tunnel rbscp report!interface ethernet1description Satellite Linkip address 172.17.2.1 255.255.255.0Configuring Routing for the RBSCP Tunnel: Example
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
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.
Router 1 (Local Side)
interface Tunnel1ip unnumbered FastEthernet1/1tunnel source FastEthernet1/1tunnel destination 10.12.0.20tunnel mode rbscptunnel ttl 5tunnel bandwidth transmit 30000tunnel rbscp window_stuff 1tunnel rbscp ack_split 4!interface FastEthernet0/0ip address 10.13.0.1 255.255.255.0ip policy route-map rbscp-pbrduplex autospeed auto!interface FastEthernet1/1description Satellite Linkip address 10.12.0.1 255.255.255.0duplex autospeed auto!ip route 10.15.0.0 255.255.255.0 FastEthernet1/1!ip access-list extended rbscp-aclpermit tcp any 10.15.0.0 0.0.0.255permit 132 any 10.15.0.0 0.0.0.255permit esp any 10.15.0.0 0.0.0.255permit ahp any 10.15.0.0 0.0.0.255deny ip any any!!route-map rbscp-pbr permit 10match ip address rbscp-aclset interface Tunnel1Router 2 (Remote Side)
ip dhcp pool CLIENTimport allnetwork 10.15.0.0 255.255.255.0default-router 10.15.0.1domain-name engineer.chicago.il.usdns-server 10.10.0.252!interface Tunnel1ip unnumbered FastEthernet0/1tunnel source FastEthernet0/1tunnel destination 10.12.0.1tunnel mode rbscptunnel ttl 5tunnel bandwidth transmit 30000tunnel rbscp window_stuff 1tunnel rbscp ack_split 4!interface FastEthernet0/0description Local LANip address 10.15.0.1 255.255.255.0ip policy route-map rbscp-pbrduplex autospeed auto!interface FastEthernet0/1description Satellite Linkip address 10.12.0.20 255.255.255.0duplex autospeed auto!ip route 0.0.0.0 0.0.0.0 FastEthernet0/1!ip access-list extended rbscp-aclpermit tcp any anypermit 132 any anypermit esp any anypermit ahp any anydeny ip any any!route-map rbscp-pbr permit 10match ip address rbscp-aclset interface Tunnel1Additional References
Related Documents
Tunnel interface commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Cisco IOS Interface and Hardware Component Command Reference
Tunnel configuration
Cisco IOS Interface and Hardware Component Configuration Guide
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
RFC 1323
TCP Extensions for High Performance
RFC 2018
TCP Selective Acknowledgment Options
Technical Assistance
Feature Information for Rate Based Satellite Control Protocol
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
