Multimedia Networks Group  
MPLS
Multicast Fast Reroute
Multimedia Networks Group
Dept. of Computer Science
University of Virginia
   

 General
 
    Overview
    People
    Sponsors
 
 Software
 
    Overview
    MPLS Multicast Patch
    MulTreeLDP
    Testing
    Example
 
 Documents
 
    MS Thesis
 
 Contact us

[Topology | Daemon | Manual backup path | Automatic backup path | Testing]

Overview

   The topology for our full example is depicted above. You need 6 PC routers, with a different ethernet interface per link on each machine: ethernet links are used as point-to-point links. Machines 1, 5 and 6 will be LERs; they will generate and receive multicast traffic. Machines 2, 3 and 4 are pure LSRs. The multicast tree consists of links (1, 2), (2, 3), (3, 5), (2, 4) and (4, 6), with router 2 as the center of the CBT. The primary path consists of links (2, 3) and (2, 4). If any of these links breaks, the backup path constituted of the single link (3, 4) will be used to repair the tree.
   Note that the LERs (1, 5, 6) are connected to the remaining of the tree through 1 interface only. This is because at a LER, MPLS-Linux needs to know where to output a packet before pushing a label on it. Therefore, a static routing entry (with only one output link) should exist for the multicast FEC on all LERs.

   In our example, the following entries are statically configured on all routers:

  • 10.0.2.0/24
  • 10.0.3.0/24
  • 10.0.4.0/24
  • 10.0.20.0/24
  • 10.0.22.0/24
  • 10.0.22.0/24
   In addition to that, the entry 224.1.1.1/32 is statically configured on hosts 1, 5 and 6.


Daemon

   On all hosts, run the MulTreeLDP daemon:

multreeldp -s

   On one the the hosts of the primary path (2, 3, 4), you will probably want to bring up and down an interface to test the path switching mechanism. On this host, bring up the interface and run
multreeldp -l ethn

   Press ENTER to alternatively bring the interface down and up.


Manual backup path

   You are going set up a backup path that you have computed yourself. The multicast tree is defined by the "next hops" seen by packets when they arrive at a router. The first hop should be an interface address of the core of the CBT, and branches are put between braces. On this example, this file describes the multicast tree:

10.0.4.1(10.0.4.2)(10.0.3.1,10.0.2.1)(10.0.23.1,10.0.22.1)

   From any of the PC-routers, execute this command to advertise the multicast LSP:

multreeldp -b 224.1.1.1 -t tree

   The router interfaces on the primary path are 10.0.23.1, 10.0.23.2, 10.0.3.2 and 10.0.3.1, hence the routers file:

10.0.23.1,10.0.23.2,10.0.3.2,10.0.3.1

   Assuming that you do not rely on the embedded algorithm to choose a backup path, you need to provide to the routers the definition of each direction of the backup path. Here, the backup path consists of the link between PC-routers 3 and 4, so the backup path definition files are, for one direction:

10.0.20.1,10.0.20.2

and, for the other direction:

10.0.20.2,10.0.20.1

   To advertise this backup path, just type on any PC:

multreeldp -b 224.1.1.1 -r routers -k bpath1
multreeldp -b 224.1.1.1 -r routers -k bpath2


Daemon

   However, you can let an algorithm compute a backup path for you. To do so, the program needs to know the network topology, in addition to the tree topology. Our tree is still:

10.0.4.1(10.0.4.2)(10.0.3.1,10.0.2.1)(10.0.23.1,10.0.22.1)

while the network can be described by the file:

router1 10.0.4.2 router2 10.0.4.1
router2 10.0.3.2 router4 10.0.3.1
router2 10.0.23.2 router3 10.0.23.1
router4 10.0.2.2 router6 10.0.2.1
router3 10.0.22.2 router5 10.0.22.1
router4 10.0.20.1 router3 10.0.20.2


   The names router1 to router6 are arbitrary (they just need to be self-consistent within the network definition file).

   You can check without advertising any LSP what the computed backup path look like with the command

multreeldp -n network -a tree

   Finally, to advertise the multicast tree and the backup path, run this single command (on any PC-router):

multreeldp -b 224.1.1.1 -n network -t tree

   If you are already familiar with MPLS-Linux, check the files /proc/net/mpls_* to see the label bindings on each machine.

Testing

   You can try our implementation thanks to multicast traffic generation tools found on the software page.
   For instance, run
mreceive -g 224.1.1.1 -p 4444 -n
on routers 5 and 6, and
msend -g 224.1.1.1 -p 4444 -f 100 -n
on router 1 to send a multicast packet from 1 to 5 and 6 every 100 ms. Routers 5 and 6 should print a message each time a message is received. The bring down (unplug) the link from 2 to 3 or 2 to 4: the receiving program should still be printing packet reception messages (at most one packet is lost). If you run
msend -g 224.1.1.1 -p 4444 -f 10 -n
on router 1, you should notice a gap of 2 to 4 packets on one of the receiving machines (hence a 20 to 40 ms interruption of service), and possibly duplicate packets on both receiving machines.

 

D E N A L I Copyright © Multimedia Networks Group , Department of Computer Science , University of Virginia , 2002.
Maintained by Yvan Pointurier.

Last modified: Fri Oct 24, 2003 at 10:09:08 EDT