IP Multicast VPN Routing and Forwarding and Multicast Domains


IP Multicast VPN Routing and Forwarding and Multicast Domains


Multicast VPN introduces multicast routing information to the VPN routing and forwarding table. When a PE router receives multicast data or control packets from a customer-edge (CE) router, forwarding is performed according to the information in the Multicast VRF (MVRF).


A set of Multicast VPN Routing and Forwarding instances that can send multicast traffic to each other constitutes a multicast domain. For example, the multicast domain for a customer that wanted to send certain types of multicast traffic to all global employees would consist of all CE routers associated with that enterprise.

Multicast Distribution Trees


Multicast VPN establishes a static default MDT for each multicast domain. The default MDT defines the path used by PE routers to send multicast data and control messages to every other PE router in the multicast domain.


Multicast VPN also supports the dynamic creation of MDTs for high-bandwidth transmission. Data MDTs are a feature unique to Cisco IOS software. Data MDTs are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal traffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can be configured on a per-router or a per-VRF basis. When the multicast transmission exceeds the defined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol (UDP) message that contains information about the data MDT to all routers in the default MDT. The statistics to determine whether a multicast stream has exceeded the data MDT threshold are examined once every 10 seconds. If multicast distributed switching is configured, the time period can be up to twice as long.


Data MDTs are created only for (S, G) multicast route entries within the VRF multicast routing table. They are not created for (*, G) entries regardless of the value of the individual source data rate.


In the following example, a service provider has a multicast customer with offices in San Jose, New York, and Dallas. A one-way multicast presentation is occurring in San Jose. The service provider network supports all three sites associated with this customer, in addition to the Houston site of a different enterprise customer.


The default MDT for the enterprise customer consists of provider routers P1, P2, and P3 and their associated PE routers. PE4 is not part of the default MDT, because it is associated with a different customer. Figure 1 shows that no data flows along the default MDT, because no one outside of San Jose has joined the multicast.


Figure 1 Default Multicast Distribution Tree Overview




An employee in New York joins the multicast session. The PE router associated with the New York site sends a join request that flows across the default MDT for the multicast domain of the customer whether it is configured to use Sparse Mode, Bidir or SSM within a VRF which contains both the Dallas and the San Jose sites. PE1, the PE router associated with the multicast session source, receives the request. Figure 2 depicts that the PE router forwards the request to the CE router associated with the multicast source (CE1a).


Figure 2 Initializing the Data MDT



The CE router (CE1a) begins to send the multicast data to the associated PE router (PE1), which sends the multicast data along the default MDT. Immediately after sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold at which a data MDT should be created. Therefore, PE1 creates a data MDT, sends a message to all routers using the default MDT that contains information about the data MDT, and, three seconds later, begins sending the multicast data for that particular stream using the data MDT. Only PE2 has interested receivers for this source, so only PE2 will join the data MDT and receive traffic on it.


PE routers maintain a PIM relationship with other PE routers over the default MDT, and a PIM relationship with its directly attached PE routers.


Figure 3 depicts the final flow of multicast data sourced from the multicast sender in San Jose to the multicast client in New York. Multicast data sent from the multicast sender in San Jose is delivered in its original format to its associated PE router (PE1) using either sparse mode, bidir or SSM. PE1 then encapsulates the multicast data and sends it across the data MDT using the configured MDT data groups. The mode used to deliver the multicast data across the data MDT is determined by the service provider and has no direct correlation with the mode used by the customer. The PE router in New York (PE2) receives the data along the data MDT. The PE2 router deencapsulates the packet and forwards it in its original format toward the multicast client using the mode configured by the customer.


Figure 3 Multicast Distribution Tree with VRFs

Comments

Popular posts from this blog

L2TPv3 Enables Layer 2 Services for IP Networks

TCP/IP 明確擁塞通知 (ECN)

Q-in-Q(Dot1Q Tunnel) Sample Configuration