Multicast topology

Monday April 5th, 2004.
 

By the same authors

In the same section

In the same section

Transporting IPv6 multicast

As IPv6 multicast is almost not available in production networks for the moment, the M6Bone is a tunnel network with edge equipments supporting IPv6 multicast. The tunnels can be:

-  IPv6 multicast over IPv6 unicast
-  IPv6 multicast over IPv4 unicast
-  IPv6 multicast over GRE

It is possible also to carry IPv6 multicast in dedicated ATM PVCs.

Multicast protocol

Interdomain protocols

There is no MSDP for IPv6 at that time. There is no wish to implement this protocol as it does not scale with a large deployment. Therefore the M6Bone today is a unique PIM domain.

Intradomain protocols

The protocol used in M6Bone today is PIM Sparse Mode. There are different RPs configured on the network:

-  RENATER global RP - 2001:660:3007:300:1:: This RP can be used by the whole M6Bone community. It is RP for the addresses matching the following prefixes:

Moreover, sites or connected organisations can have their own private RPs and restrict access to it.

Of course, the solution to have a unique global RP does not scale as the M6Bone grows dramaticaly. A solution to avoid the need of a bottleneck protocol like MSDP is embedded-rp-address. Described in RFC 3956 (see bibliography section), the idea is to embed the address of the RP in the IPv6 multicast address. This is currently deployed in some parts of the M6Bone but this is more and more supported.

The initial M6Bone

The M6Bone dilemna

Very few routers implemented IPv6 multicast when the project started in July 2001 (only implemented in Kame stack)
-  A different topology for IPv6 unicast and IPv6 multicast was needed (tunnel topology)

No IPv6 multicast routing table implemented at that time (PIM used the unicast routing table for RPF check)
-  This implied that the unicast and multicast topologies had to be fully congruent.

The solution to this problem was to dedicate equipments for IPv6 multicast . At the beginning, the M6Bone was a network of IPv6 multicast routers only connected together with IPv6 in IPv6 or IPv6 in IPv4 tunnels. The equipments were PC with FreeBSD and Kame stack. The PIM SM daemon was pim6sd.

Routing protocol

As there were no IPv6 multicast routing tables implemented, PIM SM used only the unicast routing table for RPF checks. Therefore the routes for the sites had to be seen in the tunnels. The routing protocol used in M6Bone to populate the routing table is RIPng. Each site has to annouce its prefix through the M6Bone tunnels and the announce is then propagated in the whole M6Bone network. The other options we had were:

The following scheme shows the initial M6Bone architecture:

The routing policy of the M6Bone is to announce only the prefixes corresponding to IPv6 enable subnets. Each site has to decide and tell which prefixe(s) it uses in the M6Bone (from /64 to /48) so that other sites can update there filters. The filters are very important to controle that sites announce only subnets IPv6 multicast enable and not the entire IPv6 routing table.

IPv6 tunnels and routing

A problem occurs when you set up an IPv6 in IPv6 tunnel: in order to set up the tunnel, you need to reach the destination of the tunnel via the unicast network. You need to be sure that the address of the tunnel end point is NOT included in a prefix advertised on the M6Bone. If this is the case (topology choice) you need to specify a static route to the tunnel end-point through the unicast network.

PIM registers in initial M6Bone

The PIM registers messages are unicast from the DR to the RP. The RP address must be seen via the multicast tunnels in the initial M6Bone, otherwise, the RPF check fails when a router receives an (S,G) join from the RP. As there is a unique routing table on every router of the initial M6Bone, the PIM registers are also sent through the multicast tunnels.

BSR

In the initial M6Bone, routers can use BSR to learn the existing RPs. They don’t need to manually configure the RP addresses.

MBGP deployment

IPv6 multicast routing table

An IPv6 multicast routing table makes it possible on an equipment to have different topologies for IPv6 unicast and IPv6 multicast. The router uses the multicast routing table for RPF checks and the multicast tree construction; it uses the unicast routing table for IPv6 unicast forwarding.

To populate the multicast routing table, it is possible to use static multicast routes or IPv6 multicast address family of MBGP. The address family IPv6 multicast became available during the first semester of 2003 on CISCO and JUNIPER routers.

MBGP peerings and routing policy

The IPv6 multicast MBGP peerings are established between IPv6 multicast routers. With a tunnel topology, the peerings are established between the addresses of the logical links.

As with IPv6 unicast, MBGP makes it possible to aggregate the prefixes. Therefore sites have to announce their entire /48 and ISPs have to announce their /32. ISPs have to use public AS numbers. Sites can use private AS numbers when peering with their providers. Otherwise, they must use public AS numbers.

PIM registers and MBGP network

PIM registers are sent via the unicast network instead of the multicast tunnels. The multicast routing table is used for doing RPF checks and the unicast routing table is used for sending all the unicast traffic. BSR

In the MBGP network, there is no BSR messages passing between ASes as the BSR protocol does not scale. Every network can provide BSR service to its customer and advertise local or global RPs.

Global topology

The initial M6Bone was connected to the MBGP network so that people can connect to the new network keeping the connectivity they had. The interconnection is done in RENATER network. RIPng routes are redistributed into MBGP.

Sites in initial M6Bone don’t have all the MBGP routes (it is no coherent to redistribute BGP in an IGP). Initial M6Bone sites have a route to the RP and will stay along the (*,G) tree for flows coming from sources in the MBGP network.


Reply to this article

Forum