257
to turn it back into a VPN multicast data packet, and passes it to the corresponding VPN
instance. If any PE has a downstream interface for an SPT, it forwards the VPN multicast
packet down the SPT. Otherwise, it discards the packet.
5.
The VPN instance on PE 2 searches the MVRF and finally delivers the VPN multicast data to
Receiver. By now, the process of transmitting a VPN multicast packet across the public network
is completed.
MDT switchover
Switching from share-MDT to switch-MDT
When a multicast data packet of a VPN is transmitted through the share-MDT on the public network,
the packet is forwarded to all PE devices that support that VPN instance, no matter whether any
active receivers exist in the attached sites. When the rate of the customer multicast traffic of that
VPN is high, multicast data might get flooded on the public network, causing bandwidth waste and
extra burden on the PE devices.
To optimize multicast transmission, the MD solution establishes a dedicated switch-MDT between
the PE devices and the VPN multicast receivers and multicast sources for any large-traffic VPN
multicast stream before it enters the public network. Then, the multicast stream is switched from the
share-MDT to the switch-MDT, to deliver the multicast data to only those receivers that need it.
The process of share-MDT to switch-MDT switchover is as follows:
1.
The source-side PE (PE 1 in this example) device periodically examines the forwarding rate of
the VPN multicast traffic. Share-MDT to switch-MDT switchover takes place only when the
following criteria are both met:
{
The VPN multicast data has passed the filtering by an ACL rule for share-MDT to
switch-MDT switchover.
{
The traffic rate of the VPN multicast stream has exceeded the switchover threshold and
stayed higher than the threshold for a certain length of time.
2.
PE 1 chooses an idle switch-group address from the switch-group-pool and sends an MDT
switchover message to all the other PE devices down the share-MDT. This message contains
the VPN multicast source address, the VPN multicast group address and the switch-group
address.
3.
Each PE device that receives this message examines whether it interfaces with a VPN that has
receivers of that VPN multicast stream.
If so, it joins the switch-MDT rooted at PE 1. Otherwise, it caches the message and will join the
switch-MDT when it has attached receivers.
4.
After sending the MDT switchover message, PE 1 waits a certain length of time and then starts
using the switch-group address to encapsulate the VPN multicast data, so that the multicast
data is forwarded down the switch-MDT.
5.
After the multicast traffic is switched from the share-MDT to the switch-MDT, PE 1 continues
sending MDT switchover messages periodically, so that subsequent PE devices with attached
receivers can join the switch-MDT. When a downstream PE device has no longer active
receivers attached to it, it leaves the switch-MDT.
For a given VPN instance, the share-MDT and the switch-MDT are both forwarding tunnels in the
same MD. A share-MDT is uniquely identified by a share-group address, and a switch-MDT is
uniquely identified by a switch-group address. Each share-group is uniquely associated with a set of
switch-group addresses, namely, a switch-group-pool.
Backward switching from switch-MDT to share-MDT
After the VPN multicast traffic is switched to the switch-MDT, the multicast traffic conditions might
change and no longer meet the aforesaid switchover criterion. In this case, PE 1, as in the preceding
example, initiates a backward MDT switchover process. When any of the following criteria is met, the
multicast traffic is switched from the switch-MDT back to the share-MDT:
