NG MVPN Public Network Tunnel Principle
NG MVPN devices exchange routing information through BGP and establishes an MVPN tunnel based on MPLS P2MP to carry multicast traffic.
- Intra-AS non-segmented NG MVPN: The public network contains only one AS, and only one MPLS protocol is deployed.
- Intra-AS segmented NG MVPN: The public network contains only one AS but contains multiple areas. Different MPLS protocols are deployed in adjacent areas.
- Inter-AS non-segmented NG MVPN: The public network contains multiple ASs, and only one MPLS protocol is deployed in the ASs.
For details about the NG MVPN deployment scenarios, see NG MVPN Typical Deployment Scenarios on the Public Network.
-
MVPN membership autodiscovery is a process that automatically discovers MVPN peers and establishes MVPN peer relationships. A sender PE and a receiver PE on the same MVPN can exchange control messages that carry MVPN NLRI to establish a PMSI tunnel only after they establish an MVPN peer relationship. In NE20E, PEs use BGP as the signaling protocol to exchange control messages.
-
PMSI tunnels are logical tunnels used by a public network to transmit VPN multicast traffic.
Switching between I-PMSI and S-PMSI tunnels
After switching between I-PMSI and S-PMSI tunnels is configured, if the multicast data forwarding rate exceeds the switching threshold, multicast data is switched from the I-PMSI tunnel to an S-PMSI tunnel. Unlike the I-PMSI tunnel that sends multicast data to all PEs on an NG MVPN, an S-PMSI tunnel sends multicast data only to PEs interested in the data, reducing bandwidth consumption and PEs' burdens.
Transmitting multicast traffic on an NG MVPN
After a public network PMSI tunnel is created, multicast users can join the multicast group and apply for multicast services from the multicast source. The multicast source can send multicast traffic to multicast users through the PMSI tunnel.
PMSI Tunnel
Public tunnels (P-tunnels) are transport mechanisms used to forward VPN multicast traffic across service provider networks. In NE20E, PMSI tunnels can be carried over RSVP-TE P2MP or mLDP P2MP tunnels. Table 8-15 lists the differences between RSVP-TE P2MP tunnels and mLDP P2MP tunnels.
Tunnel Type |
Tunnel Establishment Method |
Characteristic |
|---|---|---|
RSVP-TE P2MP tunnel |
Established from the root node. |
RSVP-TE P2MP tunnels support bandwidth reservation and can ensure service quality during network congestion. Use RSVP-TE P2MP tunnels to carry PMSI tunnels if high service quality is required. |
mLDP P2MP tunnel |
Established from a leaf node. |
mLDP P2MP tunnels do not support bandwidth reservation and cannot ensure service quality during network congestion. Configuring an mLDP P2MP tunnel, however, is easier than configuring an RSVP-TE P2MP tunnel. Use mLDP P2MP tunnels to carry PMSI tunnels if high service quality is not required. |
Theoretically, a P-tunnel can carry the traffic of one or multiple MVPNs. However, in NE20E, a P-tunnel can carry the traffic of only one MVPN.
PMSI Tunnel Type |
Description |
Characteristic |
|---|---|---|
I-PMSI tunnel |
An I-PMSI tunnel connects to all PEs on an MVPN. |
Multicast data sent over an I-PMSI tunnel can be received by all PEs on the MVPN. In a VPN instance, one PE corresponds to only one I-PMSI tunnel. |
S-PMSI tunnel |
An S-PMSI tunnel connects to the sender and receiver PEs of specific sources and multicast groups. |
Multicast data sent over an S-PMSI tunnel is received by only PEs interested in the data. In a VPN instance, one PE can correspond to multiple S-PMSI tunnels. |
- For a non-segment tunnel, the public network between the sender PE and receiver PE uses the same MPLS protocol. Therefore, an MPLS P2MP tunnel can be used to set up a PSMI logical tunnel to carry multicast traffic.
- For a segmented tunnel, different areas on the public network between the sender PE and receiver PE use different MPLS protocols. Therefore, PMSI tunnels need to be established in each area based on the MPLS protocol type and MPLS P2MP tunnel type. In addition, tunnel stitching must be configured on area connection nodes to stitch PMSI tunnels in different areas into one tunnel to carry the data traffic of the MVPN. Currently, the NE20E supports intra-AS segmented tunnels, not inter-AS segmented tunnels.
MVPN Targets
- Export MVPN target: A PE adds the export MVPN target to an MVPN instance before advertising this route.
- Import MVPN target: After receiving an MVPN A-D route from another PE, a PE matches the export MVPN target of the route against the import MVPN targets of its VPN instances. If the export MVPN target matches the import MVPN target of a VPN instance, the PE accepts the MVPN A-D route and records the sender PE as an MVPN member. If the export MVPN target does not match the import MVPN target of any VPN instance, the PE drops the MVPN A-D route.
By default, if you do not configure MVPN targets for an MVPN, MVPN A-D routes carry the VPN target communities that are attached to unicast VPN-IPv4 routes. If the unicast and multicast network topologies are congruent, you do not need to configure MVPN targets for MVPN A-D routes. If they are not congruent, configure MVPN targets for MVPN A-D routes.
MVPN Membership Autodiscovery
To exchange control messages and establish PMSI tunnels, a PE on an MVPN must be capable of discovering other PEs on the MVPN. The discovery process is called MVPN membership autodiscovery. An NG MVPN uses BGP to implement this process. To support MVPN membership autodiscovery, BGP defines a new address family, the BGP-MVPN address family.
On the network shown in Figure 8-24, BGP and MVPN are configured on PE1, PE2, and PE3 in a way that PE1 can negotiate with PE2 and PE3 to establish BGP MVPN peer relationships. A PE newly added to the service provider's backbone network can join the MVPN so long as this PE can establish BGP MVPN peer relationships with existing PEs on the MVPN.
To transmit multicast traffic from multicast sources to multicast receivers, sender PEs must establish BGP MVPN peer relationships with receiver PEs. On the network shown in Figure 8-24, PE1 serves as a sender PE, and PE2 and PE3 serve as receiver PEs. Therefore, PE1 establishes BGP MVPN peer relationships with PE2 and PE3.
PEs on an NG MVPN use BGP Update messages to exchange MVPN information. MVPN information is carried in the network layer reachability information (NLRI) field of a BGP Update message. The NLRI containing MVPN information is also called the MVPN NLRI. For more information about the MVPN NLRI, see MVPN NLRI.
I-PMSI Tunnel Establishment
- RSVP-TE P2MP tunnels: A sender PE sends an intra-AS PMSI A-D route to each receiver PE. Upon receipt, each receiver PE sends a reply message. Then, the sender PE collects P2MP tunnel leaf information from received reply messages and establishes an RSVP-TE P2MP tunnel for each MVPN based on the leaf information of the MVPN. For more information about RSVP-TE P2MP tunnel establishment, see "P2MP TE" in NE20E Feature Description - MPLS.
- mLDP P2MP tunnels: Receiver PEs directly send Label Mapping messages based on the root node address (sender PE address) and opaque value information carried in the Intra-AS PMSI A-D route sent by the sender PE to establish an mLDP P2MP tunnel. For more information about mLDP P2MP tunnel establishment, see "mLDP" in NE20E Feature Description - MPLS.
For comparison between RSVP-TE and mLDP P2MP tunnels, see Table 8-15 in NG MVPN Public Network Tunnel Principle.
The following example uses the network shown in Figure 8-25 to describe how to establish PMSI tunnels. Because RSVP-TE P2MP tunnels and mLDP P2MP tunnels are established differently, the following uses two scenarios, RSVP-TE P2MP Tunnel and mLDP P2MP Tunnel, to describe how to establish PMSI tunnels.
This example presumes that:
- PE1 has established BGP MVPN peer relationships with PE2 and PE3, but no BGP MVPN peer relationship is established between PE2 and PE3.
- The network administrator has configured MVPN on PE1, PE2, and PE3 in turn.
RSVP-TE P2MP Tunnel
Figure 8-26 shows the time sequence for establishing an I-PMSI tunnel with the P-tunnel type as RSVP-TE P2MP LSP.
Table 8-17 briefs the procedure for establishing an I-PMSI tunnel with the P-tunnel type as RSVP-TE P2MP LSP.
Step |
Device |
Prerequisites |
Key Action |
|---|---|---|---|
 |
PE1 |
BGP and MVPN have been configured on PE1. PE1 has been configured as a sender PE. The P-tunnel type for I-PMSI tunnel establishment has been specified as RSVP-TE P2MP LSP. |
As a sender PE, PE1 initiates the I-PMSI tunnel establishment process. The MPLS module on PE1 reserves resources for the corresponding RSVP-TE P2MP tunnel. Because PE1 does not know RSVP-TE P2MP tunnel leaf information, the RSVP-TE P2MP tunnel is not established in a real sense. |
 |
PE1 |
BGP and MVPN have been configured on PE2. PE1 has established a BGP MVPN peer relationship with PE2. |
PE1 sends a Type 1 BGP A-D route to PE2. This route carries
the following information:
|
 |
PE2 |
- |
|
 |
PE1 |
- |
After PE1 receives the BGP A-D route from PE2, PE1 matches the export MVPN target of the route against its local import MVPN target. If the two targets match, PE1 accepts this route, records PE2 as an MVPN member, and instructs the MPLS module to send an MPLS message to PE2 and add PE2 as a leaf node of the RSVP-TE P2MP tunnel to be established. |
 |
PE1 |
- |
After PE1 receives a reply from PE2, the MPLS module on PE1 completes the process of establishing an RSVP-TE P2MP tunnel with PE1 as the root node and PE2 as a leaf node. For more information about RSVP-TE P2MP tunnel establishment, see "P2MP TE" in NE20E Feature Description - MPLS. |
 |
PE2 |
- |
After PE2 receives the MPLS message from PE1, PE2 joins the established RSVP-TE P2MP tunnel. |
PE3 joins the RSVP-TE P2MP tunnel rooted at PE1 in a similar way as PE2. After PE2 and PE3 both join the RSVP-TE P2MP tunnel rooted at PE1, the I-PMSI tunnel is established and the MVPN service becomes available.
mLDP P2MP Tunnel
Figure 8-27 shows the time sequence for establishing an I-PMSI tunnel with the P-tunnel type as mLDP LSP.
Table 8-18 briefs the procedure for establishing an I-PMSI tunnel with the P-tunnel type as mLDP P2MP LSP.
Step |
Device |
Prerequisites |
Key Action |
|---|---|---|---|
|
PE1 |
BGP and MVPN have been configured on PE1. PE1 has been configured as a sender PE. The P-tunnel type for I-PMSI tunnel establishment has been specified as mLDP P2MP LSP. |
As a sender PE, PE1 initiates the I-PMSI tunnel establishment process. The MPLS module on PE1 reserves resources (FEC information such as the opaque value and root node address) for the corresponding mLDP P2MP tunnel. Because PE1 does not know leaf information of the mLDP P2MP tunnel, the mLDP P2MP tunnel is not established in a real sense. |
|
PE1 |
BGP and MVPN have been configured on PE2. PE1 has established a BGP MVPN peer relationship with PE2. |
PE1 sends a Type 1 BGP A-D route to PE2. This route carries
the following information:
|
|
PE2 |
- |
After PE2 receives the BGP A-D route from PE1, the MPLS module on PE2 sends a Label Mapping message to PE1. This is because the PMSI Tunnel attribute carried in the received route specifies the P-tunnel type as mLDP, meaning that the P2MP tunnel must be established from leaves. After PE2 receives the MPLS message replied by PE1, PE2 becomes aware that the P2MP tunnel has been established. For more information about mLDP P2MP tunnel establishment, see "mLDP" in NE20E Feature Description - MPLS. |
|
PE2 |
- |
PE2 creates an mLDP P2MP tunnel rooted at PE1. |
|
PE2 |
- |
PE2 sends a BGP A-D route that carries the export MVPN target to PE1. Because PE2 is not a sender PE configured with PMSI tunnel information, the BGP A-D route sent by PE2 does not carry the PMSI Tunnel attribute. After PE1 receives the BGP A-D route from PE2, PE1 matches the export MVPN target of the route against its local import MVPN target. If the two targets match, PE1 accepts this route and records PE2 as an MVPN member. |
PE3 joins the mLDP P2MP tunnel and MVPN in a similar way as PE2. After PE2 and PE3 both join the mLDP P2MP tunnel rooted at PE1, the I-PMSI tunnel is established and the MVPN service becomes available.
Switching Between I-PMSI and S-PMSI Tunnels
Background
An NG MVPN uses the I-PMSI tunnel to send multicast data to receivers. The I-PMSI tunnel connects to all PEs on the MVPN and sends multicast data to these PEs regardless of whether these PEs have receivers. If some PEs do not have receivers, this implementation will cause redundant traffic, wasting bandwidth resources and increasing PEs' burdens.
To solve this problem, S-PMSI tunnels are introduced. An S-PMSI tunnel connects to the sender and receiver PEs of specific multicast sources and groups on an NG MVPN. Compared with the I-PMSI tunnel, an S-PMSI tunnel sends multicast data only to PEs interested in the data, reducing bandwidth consumption and PEs' burdens.
For comparison between I-PMSI and S-PMSI tunnels, see NG MVPN Public Network Tunnel Principle in Table 8-16.
Implementation
The following example uses the network shown in Figure 8-28 to describe switching between I-PMSI and S-PMSI tunnels on an NG MVPN.
Item |
Occurring Condition |
Description |
|---|---|---|
| Switching from the I-PMSI tunnel to an S-PMSI tunnel | The multicast data forwarding rate is consistently above the specified switching threshold. |
S-PMSI tunnels are classified as RSVP-TE S-PMSI tunnels
or mLDP S-PMSI tunnels, depending on the bearer tunnel type. For details
about switching from the I-PMSI tunnel to an S-PMSI tunnel, see:
|
| Switching from an S-PMSI tunnel to the I-PMSI tunnel | The multicast data forwarding rate is consistently below the specified switching threshold. |
- |
- After multicast data is switched from the I-PMSI tunnel to an S-PMSI tunnel, if the S-PMSI tunnel fails but the I-PMSI tunnel is still available, multicast data will be switched back to the I-PMSI tunnel.
- After multicast data is switched from the I-PMSI tunnel to an S-PMSI tunnel, if the multicast data forwarding rate is consistently below the specified switching threshold but the I-PMSI tunnel is unavailable, multicast data still travels along the S-PMSI tunnel.
Switching from the I-PMSI Tunnel to an S-PMSI Tunnel
Switching from the I-PMSI Tunnel to an RSVP-TE S-PMSI Tunnel
Figure 8-29 shows the time sequence for switching from the I-PMSI tunnel to an RSVP-TE S-PMSI tunnel. Table 8-20 describes the specific switching procedure.
Table 8-20 Procedure for switching from the I-PMSI tunnel to an RSVP-TE S-PMSI tunnelStep
Device
Key Action
PE1
After PE1 detects that the multicast data forwarding rate exceeds the specified switching threshold, PE1 initiates switching from the I-PMSI tunnel to an S-PMSI tunnel by sending a BGP S-PMSI A-D route to its BGP peers. In the BGP S-PMSI A-D route, the Leaf Information Require flag is set to 1, indicating that a PE that receives this route needs to send a BGP Leaf A-D route in response if the PE wants to join the S-PMSI tunnel to be established.
PE2
Upon receipt of the BGP S-PMSI A-D route, PE2, which has downstream receivers, sends a BGP Leaf A-D route to PE1.
PE3
Upon receipt of the BGP S-PMSI A-D route, PE3, which does not have downstream receivers, does not send a BGP Leaf A-D route to PE1 but records the BGP S-PMSI A-D route information.
PE1
Upon receipt of the BGP Leaf A-D route from PE2, PE1 establishes an S-PMSI tunnel with itself as the root node and PE2 as a leaf node.
PE2
After PE2 detects that the RSVP-TE S-PMSI tunnel has been established, PE2 joins this tunnel.
After PE3 has downstream receivers, PE3 will send a BGP Leaf A-D route to PE1. Upon receipt of the route, PE1 adds PE3 as a leaf node of the RSVE-TE S-PMSI tunnel. After PE3 joins the tunnel, PE3's downstream receivers will also be able to receive multicast data.
Switching from the I-PMSI Tunnel to an mLDP S-PMSI Tunnel
Figure 8-30 shows the time sequence for switching from the I-PMSI tunnel to an mLDP S-PMSI tunnel. Table 8-21 describes the specific switching procedure.
Table 8-21 Procedure for switching from the I-PMSI tunnel to an mLDP S-PMSI tunnelStep
Device
Key Action
PE1
After PE1 detects that the multicast data forwarding rate exceeds the specified switching threshold, PE1 initiates switching from the I-PMSI tunnel to an S-PMSI tunnel by sending a BGP S-PMSI A-D route to its BGP peers. In the BGP S-PMSI A-D route, the Leaf Information Require flag is set to 0.
PE2
Upon receipt of the BGP S-PMSI A-D route, PE2, which has downstream receivers, directly joins the mLDP S-PMSI tunnel specified in the BGP S-PMSI A-D route.
PE3
Upon receipt of the BGP S-PMSI A-D route, PE3, which does not have downstream receivers, does not join the mLDP S-PMSI tunnel specified in the BGP S-PMSI A-D route, but records the BGP S-PMSI A-D route information.
After PE3 has downstream receivers, PE3 will also directly join the mLDP S-PMSI tunnel. Then, PE3's downstream receivers will also be able to receive multicast data.
PE1 starts a switch-delay timer upon the completion of S-PMSI tunnel establishment and determines whether to switch multicast data to the S-PMSI tunnel as follows: If the S-PMSI tunnel fails to be established, PE1 still uses the I-PMSI tunnel to send multicast data. If the multicast data forwarding rate is consistently below the specified switching threshold throughout the timer lifecycle, PE1 still uses the I-PMSI tunnel to transmit multicast data. If the multicast data forwarding rate is consistently above the specified switching threshold throughout the timer lifecycle, PE1 switches data to the S-PMSI tunnel for transmission.
Switching from an S-PMSI Tunnel to the I-PMSI Tunnel
Figure 8-31 shows the time sequence for switching from an S-PMSI tunnel to the I-PMSI tunnel. Table 8-22 describes the specific switching procedure.
Step |
Device |
Key Action |
|---|---|---|
|
PE1 |
After PE1 detects that the multicast data forwarding rate
is consistently below the specified switching threshold, PE1 starts
a switchback hold timer:
|
|
PE2 |
Upon receipt of the BGP Withdraw S-PMSI A-D route, PE2 withdraws the bindings between its multicast entries and the S-PMSI tunnel. If PE2 has sent a BGP Leaf A-D route to PE1, PE2 will send a BGP Withdraw Leaf A-D route to PE1 in this step. |
|
PE2 |
After PE2 detects that none of its multicast entries is bound to the S-PMSI tunnel, PE2 leaves the S-PMSI tunnel. |
|
PE1 |
PE1 deletes the S-PMSI tunnel after waiting for a specified period of time. |
- Before the timer expires, leaf PEs delete tunnel protection groups to skip the status check of the primary I-PMSI or S-PMSI tunnel. The leaf PEs select the multicast data received from the primary tunnel and discard the multicast data received from the backup tunnel.
- After the timer expires, leaf PEs start to check the primary I-PMSI or S-PMSI tunnel status again. Leaf PEs select the multicast data received from the primary tunnel only if the primary tunnel is Up. If the primary tunnel is Down, Leaf PEs select the multicast data received from the backup tunnel.
Multicast Traffic Transmission Using NG MVPN
After a public-network PMSI tunnel is established and multicast users join a multicast group, carriers can provide MVPN services over BGP/MPLS IP VPN.
On a leaf PE, a P2MP tunnel can be mapped to only one VPN instance. Therefore, the import VPN target of each VPN instance must be unique on a leaf PE. If multiple VPN instances with the same import VPN target exist on a leaf PE, only the downstream node of one VPN instance can receive multicast traffic.
Table 8-23 describes how an IP multicast packet is transmitted using NG MVPN.
Step |
Device |
Action |
Multicast Forwarding Table |
|---|---|---|---|
1 |
CE1 |
After receiving an IP multicast packet from the multicast source, CE1 searches its multicast forwarding table and forwards the packet to PE1. |
|
2 |
PE1 |
After receiving the IP multicast packet, PE1 searches its VPN instance multicast forwarding table for the corresponding (C-S, C-G) entry, adds an MPLS label to the packet, and sends the packet over a P2MP tunnel to the P. |
|
3 |
P |
After receiving the MPLS packet, the P removes the MPLS label from the packet and replicates the packet. Then, the P adds a new MPLS label to one copy and sends the copy to PE2, and adds another MPLS label to another copy and sends the copy to PE3. |
- |
4 |
PE2/PE3 |
After receiving the MPLS packet, PE2/PE3 removes the MPLS label, searches its VPN instance multicast forwarding table for the corresponding (C-S, C-G) entry, and forwards the IP multicast packet to CE2/CE3. |
|
5 |
CE2/CE3 |
After receiving the packet, CE2/CE3 searches its multicast forwarding table and forwards the packet to all receivers in the multicast group. |
NG MVPN Typical Deployment Scenarios on the Public Network
- Intra-AS non-segmented NG MVPN: The public network contains only one AS, and only one MPLS protocol is deployed.
- Inter-AS non-segmented NG MVPN: The public network contains multiple ASs, and only one MPLS protocol is deployed in the ASs.
- Intra-AS segmented NG MVPN: The public network contains only one AS but multiple areas, and different MPLS protocols are deployed in adjacent areas.
Intra-AS Non-segmented NG MVPN
- Establish an I-BGP peer relationship between PEs.
- Deploy MVPN on the PEs, so that the PEs in the same MVPN can automatically discover each other and use BGP to transmit BGP C-multicast routes.
- Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other, so that PE1 and PE2 can establish a PMSI tunnel based on the P2MP tunnel to transmit multicast traffic.
Inter-AS Non-segmented NG MVPN
This scenario supports three VPN modes: Option A, Option B, and Option C. In Option A mode, ASBRs use each other as CEs. The establishment process is similar to that in the intra-AS non-segment scenario.
- Establish an IBGP peer relationship between a PE and an ASBR in the same AS. Establish an EBGP peer relationship between ASBRs in different ASs.
- Deploy MVPN on the PEs, so that the PEs in the same MVPN can automatically discover each other and use BGP to transmit BGP C-multicast routes through ASBRs.
- Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other through ASBRs, so that PE1 and PE2 can establish a PMSI tunnel based on the P2MP tunnel to transmit multicast traffic.
- Establish an IBGP peer relationship between a PE and an ASBR in the same AS. Establish an EBGP peer relationship between ASBRs in different ASs. Establish an MP-EBGP peer relationship between PE1 and PE2.
- Deploy MVPN on the PEs, so that the PEs in the same MVPN can automatically discover each other and use BGP to directly transmit BGP C-multicast routes over ASBRs.
- Configure a P2MP tunnel and use BGP to directly transmit BGP A-D routes to each other over ASBRs, so that PE1 and PE2 can establish a PMSI tunnel based on the P2MP tunnel to transmit multicast traffic.
Intra-AS Segmented NG MVPN
- Establish an I-BGP peer relationship between the PE and ABR.
- Deploy MVPN on the PEs, so that the PEs in the same MVPN can automatically discover each other and use BGP to transmit BGP C-multicast routes.
- Configure a P2MP tunnel and use BGP to transmit BGP A-D routes to each other so that PE1 and the ABR can establish a PMSI tunnel based on the P2MP tunnel. The ABR and PE2 establish a PMSI tunnel based on the P2MP tunnel. The two tunnels are stitched on the ABR to carry the multicast traffic transmitted from PE1 to PE2.
