Deploying MPLS on the Czech academic backbone

Ladislav Lhotka <>
University of South Bohemia, Branisovska 31, CZ-37005 Ceske Budejovice, Czech Republic


The Czech academic backbone (TEN-34 CZ, later TEN-155 CZ) was designed in 1996 as an ATM network and at the same time it was decided to use LAN emulation (LANEv1) for carrying IP traffic over ATM. Even though this technology is not intended for backbone networks, we have not encountered any major problem in its operation or performance. Current topology of the TEN-155 CZ network is given in Fig. 1 - the scale in the horizontal direction is about 500 km.

TEN-155 CZ sites and connections Figure 1. TEN-155 CZ sites and connections

Nine cities with connections of at least 34 Mbit/s form the ATM core. The hardware base is very homogeneous, consisting of ATM switches Cisco LS1010 with PFQ feature cards and Cisco 7500 routers. Recently, a new OC-48 circuit between Praha and Brno was established with a Cisco GSR 12000 on each end. This link, when used for production traffic, will split our emulated LANs on the backbone into two islands. Besides of that, several other drawbacks of LANEv1 (lack of QoS support, inefficient handling of multicasts etc.) led us to the conclusion that a new backbone technology is needed. Multi-protocol label switching (MPLS) appeared to be the most natural candidate due to the following features:

MPLS network architecture

MPLS was extensively tested by the joint task forces of DANTE and TERENA (TF-TEN and TF-TANT, see [3] and [4] ). Their results proved to be a very valuable source of practical information which made our start much easier.

One of their important suggestions was a special routing architecture combining OSPF in the MPLS core with IBGP sessions between the edge routers. The aim of this approach is to limit the number of routes in the OSPF database (which is used for label assignments) to the bare minimum and by doing so to eliminate the adverse effects of route flapping which leads to expensive virtual circuit reconfigurations at the ATM layer. The IETF draft specification [2] provides a direct solution to the same problem called "egress-targeted label assignment" but it is not available yet in the Cisco MPLS implementation. Moreover, BGP with multi-protocol extensions is required for using VPNs over MPLS. Therefore, we decided to implement the OSPF/IBGP routing architecture.


For the transition period we used the option of running MPLS along with standard ATM signalling (UNI and PNNI). This allowed us to continue the operation of the backbone ELANs while setting up and testing the MPLS logical network.

MPLS backbone topoplogy

Figure 2. MPLS backbone topology

The MPLS backbone is built upon the ATM network topology shown in Fig. 2. Its configuration is based on the following principles:

  1. All switches in the ATM core are configured as label switching routers (LSR) together with all the edge routers shown in Fig. 2 which connect campus or metropolitan networks;
  2. Each LSR runs an OSPF process which deals only with the internal (host) routes within the MPLS cloud;
  3. The edge routers exchange with each other the prefixes of attached metropolitan networks through IBGP;
In the two main ATM switches in Praha and near Brno we use the VC-merge feature for reducing the number of allocated label-switched VCs.

One has to be aware that IBGP is used here in a rather nonstandard way because (i) IBGP is usually complemented by an IGP advertising the same prefixes and (ii) BGP was not designed for rapid reactions to the changes in network topology. Issue (i) results in various problems and limitations in the interaction of the backbone IBGP with the OSPF processes that are typically used in the campus or metropolitan networks. In order to speed up the BGP convergence, one has to reduce several timers used in the BGP implementation - e.g., interval between BGP route validations and frequency of route exchanges between BGP and VPN routing/forwarding instances

Practical results

After a period of testing and tuning up the configuration of the MPLS logical network we repeatedly tried to migrate all the backbone unicast traffic to it. Along the way we encountered a number of problems. They have nothing in common with the very concept of MPLS but rather they are plain software bugs. We can classify them into four main categories: Currently (end of March 2000) the backbone is operating in the MPLS mode and the only persisting serious problem is the non-functional WCCP redirection. We are cooperating with Cisco TAC on this issue.


Although the technology has been around for several years and various tests or installations on a smaller scale confirmed its utility, our practical experience shows that the deployment of MPLS in more complex and moderately loaded networks is still rather troublesome. On the other hand, none of the problems we found can be considered as a flaw of the MPLS technology itself and so we believe MPLS is a viable alternative for the Czech academic backbone and other networks as well.

Our plans for the future are twofold:

An up-to-date information about the status of the Czech MPLS backbone is available at


  1. Bates, T., Chandra, R., Katz, D. and Rekhter, Y., 1998. Multiprotocol Extensions for BGP-4.. RFC 2283.
  2. Rosen, E.C., Viswanathan, A. and Callon, R., 1999. Multiprotocol Label Switching Architecture. Work in progress.
  3. Uz, J.-M. and Ferrari, T., 1998. Label-based switching: Architecture and Performance in an ATM wide area network. In: Behringer, M. (editor), TEN-34: Results of Phase 2 Test Programme. DANTE, UK.
  4. Uz, J.-M., 1999. Multi-Protocol Label Switching (MPLS). Work in progress.