NETS header NETS Homepage UCAR Homepage NCAR Homepage SCD Homepage NETS Homepage About NETS Work requests & support
  Browse NETS topics: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

How to configure rate-limited FRGP ATM PVCs

General

ATM PVC connections at the FRGP originate on the M20 router frgp-gw-1, but pass thru the ATM switch frgp-as-1 to be distributed to SONET connections to other ATM switches (4-campus, for example), CRS connections (DU and FLC, for example), or leased lines (UW, for example). PVCs in the Juniper router must be configured with ATM shaping to not overrun the switch or the downstream network, and PVCs in the Cisco LS1010 switch must have "cttr" options configured to match the Juniper. A complicating factor here is the different ways the two vendors refer to ATM bit rates. Cisco counts a cell as 53 bytes, whereas Juniper only counts the 48 byte payload. Juniper ATM bit rates are configured to be 48/53 that of Cisco or Qwest CRS rates.

Traffic class: UBR, VBR, or CBR?

UBR, or Unspecified Bit Rate, has no User Parameter Control (UPC) limits, and is the best and easiest way to most effectively maximize the use of leased circuits or switch-to-switch connections. It's also the cheapest and most flexible Cell Relay Service option. UBR PVCs accept packet bursts that dramatically reduce latency as compared to CBR PVCs that accept cells only into isochronous transmission slots. CBR cannot accept packet bursts. However, most managers want bandwidth guarantees to assure they're getting what they paid for, so most CRS circuits are purchased as CBR (Constant Bit Rate) services. CBR is the most difficult service to fully utilize without extensive and laborious tuning. Cells issued too rapidly into a CBR CRS circuit will be dropped by the UPC policer at the ingress to the CRS network. The only way to assure cells won't be dropped by a CBR is to configure rates below the CBR CRS rate.

PVC VPI/VCI assignment

By ancient and venerable tradition, each FRGP member is assigned a separate VPI. At one time, VCIs of 100 identified Abilene connections and were switched directly to the Abilene router. VCIs of 200 and 300 identified the first and second commodity connections. Its nice to keep this system, but Qwest names PVCs incrementally from 1/33 and its nicer to keep a PVC's VPI/VCI numbers unchanged as it transits the FRGP, so there are a few assigned this way.

Juniper Configuration

The OC-12 ATM interface on frgp-gw-1 is at-0/2/0. PVCs are created on a subinterface which is generally assigned by adding or, alternatively, concatenating the VPI and VCI numbers. Usually we use atm-snap encapsulation to allow easy IPv6 implementation, but the atm-vc-mux encapsulation is more efficient and desirable for low-speed links (TCP ACK in one cell rather than two!)(And SNAP shouldn't be necessary for IPv6 anyway - its still IP - but that's what JUNOS does). A limited number of VCs are allowed on the interface, so each VPI must be set with the maximum number of VCs that will be supported. Shaping with a limited queue-length must be configured to prevent cell-buffer starvation; UBR can be faked by shaping with VBR PVC with very liberal UPC (User Parameter Control). Calculate JUNOS bit rates by multiplying Cisco or Qwest CRS rates by 48/53. For PVCs that stay on leased lines, be sure to configure a maximum rate no larger than the physical circuit.

Example: DU's connection

interfaces {
    at-0/2/0 {
        vpi 1 {
            maximum-vcs 401;
        }
        unit 133 {
            description "------------------------------------------------- DU PVC 1/33";
            encapsulation atm-snap;
            vci 1.33;
            shaping {
                cbr 48m;
                queue-length 300;
            }
            family inet {
                mtu 4470;
	(extraneous stuff deleted)
            }
            family inet6 {
                mtu 4470;
	(more extraneous stuff deleted)
            }
        }

Cisco LS1010 Configuration

PVCs are technically one-way only, but Cisco and most other manufacturers install PVCs in both directions with one command. LS1010 IOS always displays the PVC configuration on the highest number interface (or, equivalently, the lowest line in the config), even when the configuration was applied to a low interface number towards the top of the config file. It can be disconcerting to have a newly configured PVC vanish, so be sure to look for it on the highest numbered interface.

No User Parameter Control (UPC) is required for UBR CRS PVCs or PVCs that travel on leased circuits or dedicated connections. CRS CBR PVCs, however, need to be rate-shaped to avoid cell drops by the CRS ingress policer. A "Connection Traffic Table Row" must be configured with the appropriate UPC values, and that "CTTR" must be applied to the PVC. Here're a few example Connection Traffic Table Rows:

atm connection-traffic-table-row index 11 cbr pcr 12352 
atm connection-traffic-table-row index 20 vbr-nrt pcr 35000 scr0 30000 
atm connection-traffic-table-row index 21 ubr pcr 150000  mcr 25000

Note that the rates are in kbps even tho the "cr" stands for "Cell Rate." Note also that UBR PVCs can be configured with a Peak Cell Rate and a Minimum Cell Rate. The Minimum Cell Rate guarantees that the UBR PVC will transmit at least the minimum rate. No burst sizes are specified for UBR, which is a little bothersome and could be a problem for CRS but never seems to be.

The "CTTR" is applied to the PVC in each direction and could conceivably be different in each direction.

Make sure to include the "pd on" option to invoke packet discard. Packet discard causes the switch to drop all subsequent cells of a single packet after UPC forces the drop of any cell. Cell drops relieve congestion much more effectively with packet discard turned on. Here're a few example PVC configuration lines:

interface ATM4/0/0
 atm pvc 1 32 pd on rx-cttr 15 tx-cttr 15  interface  ATM3/1/0 1 32 
 atm pvc 1 33 pd on rx-cttr 12 tx-cttr 12  interface  ATM3/1/0 1 33 
 atm pvc 1 34 pd on  interface  ATM3/1/0 1 34 

Address comments or questions about this Web page to the Network Engineering & Telecommunications Section (NETS) at nets-www@ncar.ucar.edu. The NETS is part of the Computational & Information Systems Laboratory (CISL) of the National Center for Atmospheric Research (NCAR), which is sponsored by the National Science Foundation (NSF) and managed by the University Corporation for Atmospheric Research (UCAR). This website follows the UCAR General Privacy Policy and the NCAR/UCAR/UCP Terms of Use.