technical white paper for multicast vpn.pdf

Technical White Paper for Multicast VPN

Huawei Technologies Co., Ltd.


Copyright ©2007 Huawei Technologies Co., Ltd. All rights reserved ihttp://datacomm.huawei.com

Table of Contents

1 Foreword ........................................................................................................................................ 1

2 Technology Introduction .............................................................................................................. 2

3 Key Technologies.......................................................................................................................... 3 3.1 Forwarding Private Network Traffic through Share-MDT ..................................................... 3 3.2 Forwarding Private Network Traffic through Switch-MDT .................................................... 4 3.3 Switch-Delay and Switch-Holddown..................................................................................... 4 3.4 Policies over MTI .................................................................................................................. 5 3.5 Inter-AS VPN Multicast ......................................................................................................... 6

3.5.1 Inter-AS VPN Multicast over a VRF-to-VRF Connection ........................................... 6 3.5.2 Inter-AS VPN Multicast over a Multi-Hop EBGP Connection .................................... 7

3.6 VPN Multicast over a GRE Tunnel ....................................................................................... 7

4 Typical Application........................................................................................................................ 9 4.1 Single-AS MD VPN Multicast................................................................................................ 9 4.2 Inter-AS MD VPN Multicast ................................................................................................ 12

5 Conclusion ................................................................................................................................... 15

Appendix A References ................................................................................................................. 16

Appendix B Abbreviations ............................................................................................................ 16


Copyright ©2007 Huawei Technologies Co., Ltd. All rights reserved http://datacomm.huawei.com

1

1

1)

2)

3)


Abstract: Multicast VPN is a technology to deploy the multicast service in an existing MPLS/BGP VPN. It transmits multicast data between private networks by encapsulating the original multicast packets. This document describes the fundamental concepts, implementation schemes, basic configurations and typical networking applications of multicast VPN.

Key word: multicast, VPN, MD, MTI, RPF

Foreword

With the increasingly wide application of Multi-Protocol Label Switching / Border Gateway Protocol Virtual Private Network (MPLS/BGP VPN), the VPN users require the multicast service. There are the following aspects worth serious considerations in implementing the multicast service in a MPLS VPN:

The provider (P) routers in the public network cannot obtain the private routing table of each VPN and cannot directly forward the multicast data on the private network.

In the MPLS/BGP VPN, the provider edge (PE) routers calculate the private network routing table of each VPN and attach two labels to each private network IP packet within the VPN. The P routers in the core network can correctly forward the private network packet based on the labels without needing to know the route of the private network. However, unlike a unicast packet, a multicast packet cannot be forwarded according to only the destination address. It is subject to Reverse Path Forwarding (RPF) check based on the multicast source address and the incoming interface (IIF). Only a multicast packet from the RPF interface can be forwarded. The P routers in the public network do not know the private network route, and therefore cannot directly forward the multicast data on the private network.

VPN users can apply overlapping source and group addresses for the private multicast data.

One of the advantages of MPLS/BGP VPN is that it allows VPNs to have overlapping private address spaces. Different VPN users can have overlapping multicast source addresses and group addresses. The PE routers can correctly forward a private multicast packet to a user within the same VPN without causing interleaving.

The public network needs to support the multicast function for bandwidth conservation.



2

4)

2

Multicast's major advantage over unicast is that only one copy of multicast data is forwarded on each link in the network. The multicast data is duplicated at each router according to the number of outgoing interfaces (OIFs). Thus, the data consumes the same bandwidth whether it is delivered to one or more receivers. If the public network in the MPLS/BGP VPN can support multicast and on-demand duplication and duplicate multicast data at only Rendezvous Points (RPs), the data load of the public network will undoubtedly decrease greatly, saving bandwidth resources.

The private multicast data flow needs to be sent on demand.

A VPN consists of multiple sites that are connected to different PEs. Not every site requires multicast data. The workload of the PE routers will decrease greatly if the data flow goes to only the PE routers connected with the receiver sites.

Technology Introduction

The multicast VPN solution is based on the Multicast Domain (MD) scheme presented in draft-rosen-vpn-mcast, including the following concepts:

MD: Broadly speaking, an MD is a set of devices that can send / receive multicast messages to / from each other. In a multicast VPN, an MD is a set of VPN instances that can send / receive multicast packets to / from each other on different PEs.

P-PIM: A provider Protocol Independent Multicast (P-PIM) instance is a PIM instance in the public VPN Routing & Forwarding (VRF) table on a PE.

C-PIM: A customer PIM (C-PIM) instance is a PIM instance in a private VRF on a PE.

Share-Group: According to the principle of MD, all VPN instances on the PEs in the same MD shall join in a public group, which is known as a Share-Group.

Share-MDT: The P-PIM instance on a PE is added to the Share-Multicast Distribution Tree (Share-MDT) created by a Share-Group to distribute the PIM packets and low-speed data packets in the VPN to the other PEs in the same VPN.

MTI: From the perspective of the C-PIM instance(s) on a PE, a multicast tunnel is a virtual physical Multicast Tunnel Interface (MTI). The C-PIM instances on each PE have one MTI. After a Share-Group is configured for the VPN instances, the MTI is actually an interactive tunnel between the C-PIM instances and the P-PIM instance and an interface for the C-PIM instances to establish a PIM neighbor. The MTIs on the PEs are connected through the Share-Multicast Tunnel (Share-MT) as if they were in a shared network segment. The VPN instances on the PEs, belonging to the MD, establish a PIM neighborship, conduct Designated Router (DR) election and generate assert messages on the MTIs.



Switch-MDT: To prevent the data flow from going to an unnecessary PE router, all private recipient PEs need to join in an on-demand sending Switch-MDT created by a Switch-Group to distribute the high-speed data packets to the other PEs in the same VPN after a share-MDT is set up.

Switch-Group: A Switch-Group is a group in which all private recipient PEs join to form a Switch-MDT after a Share-MT is set up.

3

3

3.1

Key Technologies

Forwarding Private Network Traffic through Share-MDT

Figure 1 illustrates the procedure for creating a Share-MDT to forward private network traffic.

Figure 1

1)

Share-MDT Creating Share-MDT

The C-PIM instance on PE1 sends a C-PIM packet or multicast data packet to the MTI. The P-PIM instance encapsulates the packet into a public network multicast packet using the MTI source address and the Share-Group address and then forwards it to the public network.



4

2)

3)

4)

5)

6)

3.2

1)

2)

3)

3.3

The C-PIM instance on PE2 in the same MD notifies the P-PIM instance that it requires some data from the Share-Group. The encapsulated multicast data is forwarded over the public network according to the multicast route generated by the multicast routing protocol on the public network. The P-PIM instance on PE2 joins in the MDT created by the Share-Group on the public network. The P-PIM instance receives the multicast data with the Share-Group address as the destination address, decapsulates the multicast data and forwards it to the C-PIM instance on PE2. The MDT created by the Share-Group on the public network is the right Share-MDT for the C-PIM instances. The C-PIM instance parts on the both PEs send and receive a Hello packet, create a PIM neighborship and conduct DR election through the MTIs. They work through the MTIs in the same way as through LAN interfaces.

Forwarding Private Network Traffic through Switch-MDT

As shown in Figure 1, there is no receiver connected with CE3. However, the private multicast data at 192.1.1.1 and 225.1.1.1 can still arrive at PE3. As is a shortcoming of the MD solution, all the PEs belonging to the same MD can receive multicast data packets no matter whether they have a downstream receiver. This wastes bandwidth resources and burdens the unnecessary PE. To overcome the shortcoming and optimize the solution, Switch-MDT, an on-demand sending method, can be used in the multicast VPNs.

The following describes the procedure for creating a Switch-MDT. This description assumes that the Share-MDT has been successfully created through the above procedure.

On PE1, set a Switch-Group address range from 238.1.1.0 through 238.1.1.255 and a forwarding threshold over which PE1 switches to the Switch-MDT. When the source connected with CE1 sends data at a rate over the forwarding threshold, PE1 selects a group address, 238.1.1.0, from the Switch-Group address range. PE1 also periodically sends a signaling message representing a switchover to the Switch-MDT to the other PEs through the Share-MDT. The Switch-MDT creation procedure starts. PE2 that has a downstream receiver joins in the group at 238.1.1.0 in the same way as it joined in the Share-MDT after it receives the signaling message. PE3 has no downstream receiver, and therefore does not join in the Switch-MDT when receiving the switching signaling message. From now on, only PE2 can receive the private network data packets from 192.1.1.1 and 225.1.1.1. In this case, the PIM control packets are still distributed through the Share-MDT.

Switch-Delay and Switch-Holddown

PE1 can make some preparations before it forwards data through the Switch-MDT. These preparations include sending a signaling message representing a switchover to the



5

3.4

1)

2)

3)

4)

Switch-MDT, waiting for a period of Switch-Delay and encapsulating the data in the Switch-Group. The Switch-Delay can reserve some time for the downstream PE to join in the Switch-MDT, minimizing the data loss. The Switch-Delay is configurable according to the actual network conditions.

The data will be re-forwarded through the Share-MDT when its rate falls below the threshold. The data may frequently switch back and forth between the Switch-MDT and the Share-MDT when its rate is around the threshold. A Switch-Holddown can help prevent that problem. In other words, the data can wait for a period of Switch-Holddown rather than immediately switch to the Share-MDT when its rate goes below the threshold. The data will switch to the Share-MDT if the data rate keeps lower than the threshold even after the period. The data will remain in the Switch-MDT if the data rate jumps higher than the threshold within the period. This can prevent the encapsulated data from frequently switching back and forth between the Share-MDT and the Switch-MDT due to unstable traffic.

Policies over MTI

An MTI is actually an interactive channel between the C-PIM instance(s) and the P-PIM instance on a PE. The multicast VPN technology provides a variety of policies on the MTI. You can configure the policies according to your actual requirements.

An MTI can provide the following policies:

PIM neighbor filtering

The PIM neighbor filtering ACL on the MTI can control the PE to reject or accept a C-PIM neighbor on a remote PE, providing a security control mechanism.

BSR border

The Boot Strap Router (BSR) border on the MTI can filter the BSR packets sent / received on the MTI.

JP packet control

The JP packet control policy on the MTI is specific to the (S, G) pairs. A specific (S, G) pair can accept the JP packets from only a specific neighbor. Combining the JP packet filtering policies with the neighbor filtering policies can generate abundant multicast route control policies.

MTU

The MTI carries the private multicast packets between the C-PIM instance(s) and the public network. All the packets traversing the MTI need to undergo Generic Routing Encapsulation (GRE) and decapsulation. A multicast packet that is originally in length equal to or close to the Maximum Transmission Unit (MTU) for the public OIF before the GRE will become longer than the MTU after the GRE. Therefore, it needs to be segmented to travel over the public OIF after the GRE. The destination P-PIM instance needs to reassemble the segments into a multicast packet to decapsulate it and forward it to the destination C-PIM instance(s).



The MTU for the MTI can help optimize the multicast VPN to avoid the above problem. That is, the source C-PIM instance segments a multicast packet longer than the MTU, encapsulates the segments and then forward the segments over the public network. The MTU length for the MTI is equal to the minimum MTU length for the public OIF minus the GRE length. This policy can omit the segmentation after the encapsulation and accordingly the reassembly before the decapsulation, accelerating the forwarding efficiency of the PEs.

6

3.5

3.5.1

Inter-AS VPN Multicast

There are two multi-Autonomous System (Inter-AS) MPLS/BGP VPN multicast solutions that are respectively based on VRF-to-VRF connections and multi-hop external BGP (EBGP) connections.

Inter-AS VPN Multicast over a VRF-to-VRF Connection

The VPN nodes in different ASes can establish VRF-to-VRF connections to each other, forming a Inter-AS VPN. As shown in Figure 2, the two AS Border Routers (ASBRs) (PE2 and PE3) that connect the two ASes treat each other as CEs in the VPN. PE1 / PE4 uses PE2 / PE3, the ASBR in the same AS, as the next hop of the unicast route to CE2 / CE1 in the other AS. In other words, the VPN is stitched across the ASes using the ASBRs.

In this case, two MDs need to be created respectively in the two ASes. The multicast data traverses between the MDs through the ASBRs.

Figure 2 Inter-AS multicast VPN over a VRF-to-VRF connection



The two MDs created respectively in the two ASes can use either the same or different Share-Groups.

7

3.5.2 Inter-AS VPN Multicast over a Multi-Hop EBGP Connection

The VPN nodes in different ASes can establish multi-hop EBGP connections to each other, forming a Inter-AS VPN. The PEs in two ASes exchange VPN routes through a multi-hop EBGP peer relationship. As shown in Figure 3, PE1 / PE4 uses PE4 / PE1 that connects to CE2 / CE1 in the other AS as the next hop of the unicast route to CE2 / CE1.

Figure 3

1)

2)

3) 4)

3.6

Inter-AS multicast VPN over a multi-hop EBGP connection

The procedure is as follows:

The PEs in the two ASes exchange VPN routes through a multi-hop EBGP peer relationship. PE1 / PE4 uses PE4 / PE1 in the other AS as the next hop of the unicast route to CE2 / CE1 in that AS. That is, PE1 and PE4 establish a neighborship with each other. Only one MD can be created for the two ASes. The two AS’s exchange P-packets through Inter-AS multicast.

VPN Multicast over a GRE Tunnel

Another multicast VPN solution is to set up a GRE tunnel between PEs / CEs so that the private multicast data can traverse the public network in unicast mode.



Figure 4 MPLS/BGP multicast over a GRE Tunnel

Details are as follows:

The PIM protocol is enabled for the VPN instances on the PEs. A GRE tunnel is set up between two PEs in one VPN, which serves as an interface within the VPN. The source and destination addresses of the tunnel are private addresses in the VPN. The PIM protocol is enabled at both ends of the tunnel. The multicast data goes through the GRE tunnel to traverse the MPLS network. The multicast routing protocols for different VPNs are isolated without any influence on each other.

A GRE tunnel between PEs burdens the PEs and the public network as the PEs need to be fully and the traffic needs to traverse the MPSL core network in unicast mode. However, this solution has two distinct advantages that it is easy to implement and that the MPLS core network does not need to support multicast routing protocols and multicast data forwarding.

8



9

4

4.1

Typical Application

Single-AS MD VPN Multicast

Figure 5 illustrates a typical single-AS VPN multicast example.

Figure 5 Typical single-AS MD VPN multicast

As shown in Figure 5, there are two VPNs in a single MPLS VPN AS, VPN RED and VPN BLUE. They have different multicast sources. This example shows how to implement the multicast service in the VPNs. Let's assume the following networking requirements:

Item Requirement

Multicast source / multicast receiver

In the VPN RED instance, the multicast source is Source1 and the receivers include PC1, PC5 and PC6.

In the VPN BLUE instance, the multicast source is Source2 and the receiver is PC7.

In the VPN RED instance, there is a Share-Group with an IP address of 239.1.1.1 and a Switch-Group with an IP address pool from 225.2.2.1 through 225.2.2.16.

In the VPN BLUE instance, there is a Share-Group with an IP address of 239.2.2.2 and a Switch-Group with an IP address pool from 225.4.4.1 through 225.4.4.16.



10

Item Requirement

VPN instance for PEs' interfaces

On PE-A, E1 and E6 belong to the VPN RED instance; and E4 and Loopback1, the P-PIM instance.

On PE-B, E1 belongs to the VPN BLUE instance; E2, the VPN RED instance; and E4 and Loopback1, the P-PIM instance.

On PE-C, E4 belongs to the VPN RED instance; E5 and Loopback2, the VPN BLUE instance; and E2, Loopback1 and Loopback3, the P-PIM instance.

Routing protocol and MPLS

The public network uses the OSPF unicast routing protocol. The PEs and CEs communicate using the Routing Information Protocol (RIP).

A BGP peer connection links the Loopback1 interfaces of PE-A, PE-B and PE-C and carries all the private routes between the interfaces.

The public network uses the MPLS for forwarding.

Multicast function

The P-PIM instance parts on PE-A, PE-B and PE-C have the multicast function.

The VPN RED instance parts on PE-A, PE-B and PE-C have the multicast function.

The VPN BLUE instance parts on PE-B and PE-C have the multicast function.

CE-Ra, CE-Rc, CE-Bb and CE-Bc have the multicast function.

IGMP function

E6 on PE-A uses the Internet Group Management Protocol (IGMP).

The E1 interfaces of CE-Rb, CE-Rc and CE-Bc use the IGMP.

PIM function

All the private interfaces in the VPN RED instance use the PIM-Sparse Mode (PIM-SM).

All the private interfaces in the VPN BLUE instance use the PIM-SM.

All the interfaces on P and the public interfaces on the PEs use the PIM-SM.

Loopback1 of P acts as a Common BSR (C-BSR) and a Common RP (C-RP) to serve all groups on the public network.

Loopback1 of CE-Rb acts as a C-BSR and a C-RP of the VPN RED instance to serve all groups in the instance.

Loopback2 of PE-C acts as a C-BSR and a C-RP of the VPN BLUE instance to serve all groups in the instance.

The procedure for deploying a single-AS multicast VPN is as follows:

Configuring PE-A

# Configure PE-A router ID, start IP multicast routing on the public network, set MPLS Label Switching Router (LSR) ID, and enable Label Distribution Protocol (LDP).

# Create the VPN RED instance. In the instance view, configure the prefix for VPN IPv4 and create the egress / ingress routes for the instance. Start IP multicast routing, configure a Share-Group, and specify the MTI and Switch-MDT address pool to be bound with the instance.

# Bind Ethernet1/0/0 to the VPN RED instance and enable PIM-SM on the interface.

# Enable LDP and PIM-SM on Ethernet4/0/0, the public interface.

# Bind Ethernet6/0/0 to the VPN RED instance and enable IGMP and PIM-SM on the interface.

# Configure the IP address for Loopback1.



11

# Configure the IP address for MTI0, which shall be consistent with that for Loopback1. Bind MTI0 to the VPN RED instance and enable PIM-SM on the interface.

# Configure BGP, OSPF and RIP unicast routing information.

Configuring PE-B (the same is the PE-C configuration)

# Configure PE-B router ID, start IP multicast routing on the public network, set MPLS LSR ID, and enable LDP.

# Create the VPN BLUE instance. In the instance view, configure the prefix for VPN IPv4 and create the egress / ingress routes for the instance. Start IP multicast routing, configure a Share-Group, and specify the MTI and Switch-MDT address pool to be bound with the instance.

# Create the VPN RED instance. In the instance view, configure the prefix for VPN IPv4 and create the egress / ingress routes for the instance. Start IP multicast routing, configure a Share-Group, and specify the MTI interface to be bound with the instance.

# Bind Ethernet1/0/0 to the VPN BLUE instance and Ethernet2/0/0 to the VPN RED instance and enable PIM-SM on the interfaces (in the same way).



# Configure the IP address for MTI0, which shall be consistent with that for Loopback1. The system automatically binds MTI0 with the VPN RED instance without any manual intervention. Enable PIM-SM on the interface (the same is the MTI1 configuration).

# Configure BGP, OSPF and RIP unicast routing information.

Configuring P

# Start IP multicast routing on the public network, configure MPLS LSR ID, and enable LDP.

# Enable LDP and PIM-SM on Ethernet1/0/0 / Ethernet2/0/0 / Ethernet3/0/0, the public interfaces. The three interfaces have the same configurations except for their IP addresses.

# Configure the IP address for Loopback1 and enable PIM-SM on the interface.

# Configure Loopback1 as a BSR and an RP.

# Configure OSPF unicast routing information.

Configuring CE-Ra (the same is the CE-Bb configuration)

# Start IP multicast routing.

# Enable PIM-SM on Ethernet2/0/0, a private interface.

# Configure RIP unicast routing information.



Configuring CE-Rb (the same are the CE-Rc and CE-Bc configurations)


# Enable PIM-SM on Ethernet2/0/0 / Ethernet3/0/0, the private interfaces. The two interfaces have the same configurations except for their IP addresses.

# Enable IGMP on Ethernet1/0/0, a private interface.

# Configure the IP address for Loopback1 and enable PIM-SM on the interface.

# Configure Loopback1 as a BSR and an RP.

# Configure RIP unicast routing information.

12

4.2 Inter-AS MD VPN Multicast

Figure 6 illustrates a typical Inter-AS VPN multicast example.

Figure 6 Typical Inter-AS MD VPN multicast

As shown in Figure 6, there are two ASes in the network, AS100 and AS200. There are two VPNs across the two MPLS VPN ASes, VPN RED and VPN BLUE. The two VPNs have different multicast sources. This example shows how to implement the multicast service in the VPNs. Let's assume the following networking requirements:



13

Item Requirement

Multicast source / multicast receiver

In the VPN RED instance, the multicast source is Source2 and the receiver is PC4.

In the VPN BLUE instance, the multicast source is Source1 and the receiver is PC2.

In the VPN RED instance, there is a Share-Group with an IP address of 239.4.4.4 and a Switch-Group with an IP address pool from 225.4.4.1 through 225.4.4.16.

In the VPN BLUE instance, there is a Share-Group with an IP address of 239.1.1.1 and a Switch-Group with an IP address pool from 225.1.1.1 through 225.1.1.16.

VPN instance for PEs' interfaces

On PE-A, E1 belongs to the VPN BLUE instance; E3, the VPN RED instance; and E2 and Loopback1, the P-PIM instance.

On ASBR1, E1, E2, Loopback1 and Loopback2 belong to the P-PIM instance.

On ASBR2, E1, E2, Loopback1 and Loopback2 belong to the P-PIM instance.

On PE-B, E2 belongs to the VPN BLUE instance; E3, the VPN RED instance; and E1 and Loopback1, the P-PIM instance.

Routing protocol and MPLS

AS100 and AS200 use the OSPF unicast routing protocol. The PEs and CEs communicate using OSPF.

A BGP peer connection links the Loopbak1 interfaces of PE-A, ASBR1, ASBR2 and PE-B and it transmits all the private routes between the interfaces.

AS100 and AS200 use the MPLS for forwarding.

Multicast function

The P-PIM instance parts on PE-A, ASBR1, ASBR2 and PE-B have the multicast function.

The VPN RED and VPN BLUE instance parts on PE-A and PE-B have the multicast function.

CE-A, CE-B, CE-C and CE-D have the multicast function.

IGMP function

E1 on CE-B uses the IGMP.

E2 on CE-D uses the IGMP.

PIM function

The public interfaces on PE-A, ASBR1, ASBR2 and PE-B use the PIM-SM.

All the private interfaces in the VPN RED and VPN BLUE instances on PE-A and PE-B use the PIM-SM.

The Loopback2 interfaces of ASBR1 and ASBR2 act as a C-BSR and a C-RP in their ASes respectively to serve all groups.

Loopback0 of CE-A acts as a C-BSR and a C-RP of the VPN BLUE instance to serve all groups in the instance.

Loopback0 of CE-C acts as a C-BSR and a C-RP of the VPN RED instance to serve all groups in the instance.

MSDP function An MSDP peer connection links the Loopback2 instances of ASBR1 and ASBR2.

The procedure for deploying a Inter-AS multicast VPN is as follows:

Configuring PE-A (the same is the PE-B configuration)

# Configure PE-A router ID, start IP multicast routing on the public network, set MPLS LSR ID, and enable LDP.



14

# Create the VPN BLUE instance. In the instance view, configure the prefix for VPN IPv4 and create the egress / ingress routes for the instance. Start IP multicast routing, configure a Share-Group, and specify the MTI and Switch-MDT address pool to be bound with the instance.

# Create the VPN RED instance. In the instance view, configure the prefix for VPN IPv4 and create the egress / ingress routes for the instance. Start IP multicast routing, configure a Share-Group, and specify the MTI and Switch-MDT address pool to be bound with the instance.

# Bind Ethernet1/0/0 to the VPN BLUE instance and enable PIM-SM on the instance.

# Bind Ethernet2/0/0 to the VPN RED instance and enable PIM-SM on the instance.



# Configure the IP addresses for MTI0 and MTI1, which shall be consistent with that for Loopback1. Bind MTI0 to the VPN BLUE instance and MTI1 to the VPN RED instance and enable PIM-SM on the interface.

# Configure BGP and OSPF unicast routing information.

Configuring ASBR1 (the same is the ASBR2 configuration)

# Configure ASBR1 router ID, start IP multicast routing on the public network, set MPLS LSR ID, and enable LDP.

# Enable LDP and PIM-SM on Ethernet1/0/0, a public interface. Enable PIM-SM on Ethernet2/0/0, the other public interface.

# Configure the IP addresses for Loopback1 and Loopback2.

# Configure static, BGP and OSPF unicast routing information.

# Configure routing policies.

# Configure C-BSR, C-RP and MSDP peer.

Configuring CE-A (the same are the CE-B, CE-C and CE-D configurations)


# Enable PIM-SM on Ethernet1/0/0, a private interface.

# Enable PIM-SM on Ethernet2/0/0, the other private interface.


# Configure OSPF unicast routing information.



15

5 Conclusion

With the development of IP telecom networks, the broadband IP networks support not only smooth communication over the broad highways but rich visual multimedia information. The multicast technology provides a powerful technical means for developing the multimedia service like IPTV.

With the increasingly maturing of the MPLS VPN technology, VPNs have been widely applied and the deployment of the multicast service in the VPNs has been put on the agenda. The MD VPN multicast solution provides a solid technical guarantee for deploying the service.


Copyright ©2007 Huawei Technologies Co., Ltd. All rights reserved 16http://datacomm.huawei.com

Appendix A References

References:

Internet Draft, ”draft-rosen-vpn-mcast-07”

Appendix B Abbreviations

Acronym/Abbreviation English

BSR Boot Strap Router

C-BSR Candidate-BSR

C-RP Candidate-RP

DM Dense mode

IGMP Internet Group Management Protocol

IIF Incoming Interface

MBR Multicast Border Router

MD Multicast Domain

MDT Multicast Distribution Tree

MSDP Multicast Source Discovery Protocol

MTI Multicast Tunnel Interface

OIF Outgoing Interface

OIF_List Outgoing Interface List

PIM Protocol Independent Multicast

RM Routing Management

RP Rendezvous Point

RPF Reverse Path Forwarding

RPT RP Tree

SM Sparse Mode

SPT Shortest Path Tree

SSM Source Specific Multicast

VPN Virtual Private Network

technical white paper for multicast vpn.pdf

Documents

md vpn multicast

multicast vpn copyright

multicast vpn abstract

multicast service

multicast data

vpn users

existing mplsbgp vpn

original multicast packets