FIELD OF THE INVENTION
This application relates to multicast through Virtual Private Network and in particular, to a method of communicating muticast messages through Virtual Private Network in a Long Term Evolution network.

BACKGROUND

In LTE (Long Term Evolution) networks, Internet Protocol (IP) multicast starts right from UPEs (User Provider Edge) that are normally low capacity cell site routers. Because of the low capacity, UPE cannot handle the remote VPN (Virtual Private Network) customer routes; this drawback can be overcome by HMVPN (Hierarchy Multicast VPN) Solution by segmenting the network within the same AS (Autonomous System). Internet Engineering Task Force (IETF) standard No.rfc6513 discloses an approach for IP multicast traffic within a VPN to travel from one VPN site to another. By using a high capacity router as UPE, and using a SPE (Service Provider Edge) acts as a P router (a router in the core segment of the Service Provider's network). Thus, allowing an SPE to provide multicast VPN service, without requiring the amount of state maintained by the P routers to be proportional to the number of multicast data flows in the VPNs. The amount of state is traded off against the optimality of the multicast routing. US Patent Application No. 2010/0067528 discloses a method for enabling congruent multicast and unicast routing in a VPN, the method includes receiving a request to join a multicast group to receive multicast data traffic by a receiver behind a remote PE router, and the remote PE router may use a direct path to receive the multicast data traffic from a source. US Patent Application NO.2011/0286450 discloses a method for a particular multicast-enabled device on a LAN may determine that it is to send a Join message to an upstream multicast-enabled device that is configured to source multicast data into the LAN. The particular device may transmit a Join message to the upstream device, where the Join message may have a Hello Request indication when there are no downstream multicast neighbors for the upstream device in the LAN, or may not have the Hello Request indication if there is at least one downstream multicast neighbor for the upstream device. Specifically, the Hello Request requests that the upstream device transmit Hello r messages onto the LAN. Multicast-enabled devices in the LAN may thus transmit Hello messages in response to receiving a Join message having a Hello Request directed to that particular device, which is, transmitting the Hello messages so long as there is interest in receiving them.

Reference 1 - "Multicast in MPLS/BGP IP VPNs" , RFC 6513.

Reference 2 - "Method and Apparatus for Providing Congruent Multicast and Unicast Routing", US Patent Application No. 12/626,049.

Reference 3 - "Multicast Hello on Demand", US Patent Application No.12/783,922.

SUMMARY

A method and apparatus for communicating multicast messages through virtual private network includes using Hierarchical Multicast VPN, and supports L3VPN Traffic in the LTE Mobile Backhaul. According a first aspect, there is provided a method communicating muticast messages through Virtual Private Network, the method comprising: the VPN is between a multicast source point and a multicast destination point, and a route of the VPN passes from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device, a Service Provider Edge device (SPE) receives the multicast message from the aggregation network segment; the SPE is located between the aggregation network segment and the core network segment; the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment; the SPE decapsulates the received multicast message; the SPE encapsulats the multicast message on a second MDT tunnel which is structed in the core network segment; and the SPE sends the encapsulated multicast message through the core network segment. The advantages of the aspects exist in that two network segments are connected by a PE with MDT tunnels through the segments. Thus, existing MDT tunnel are reused to achieve Segmented Network to carry Multicast VPN traffic. In a first possible implementation form of the method according to the first aspect, after the SPE decapsulates the received multicast message, the SPE acquires a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast.
In a second implementation form of the method according to the first aspect or according to the first implementation form of the first aspect, the SPE checks a Multicast VPN FIB Table; and the SPE determines the second MDT as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast.

In a third implementation form of the method according to the first aspect, according to the first implementation form of the first aspect or according to the second implementation form of the first aspect, the Multicast VPN FIB Table includes information indicating joint point devices from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device. In a forth implementation form of the method according to the first aspect, according to the first implementation form of the first aspect, according to the second implementation form of the first aspect or according to the third implementation form of the first aspect, the SPE encapsulats the multicast message on the second MDT further comprising: configuring a multicast routing table for the core segment with an address of the SPE as a source address, and a VPN next hop address as a destination address; and configuring the second MDT as outgoing interface. In a fifth forth implementation form of the method according to the first aspect, according to the first implementation form of the first aspect, according to the second implementation form of the first aspect or according to the third implementation form of the first aspect, the multicast message received from the aggregation network segment is encapsulated on a first MDT further comprising: a multicast routing table for the aggregation segment is configured with SPE address as a destination address; and the first MDT is configured as outgoing interface. According a second aspect, there is provided a network apparatus for communicating muticast messages through Virtual Private Network, the network r apparatus is located between a aggregation network segment and a core network segment, the VPN is between a multicast source point and a multicast destination point, and a route of the VPN passes from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device, the network apparatus comprising: a receiver configured to receive the multicast message from the aggregation network segment, the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment; a processor configured to decapsulate the received multicast message and encapsulats the multicast message on a second MDT which is structed in the core network segment; and a sender configured to send the encapsulated multicast message through the core network segment.

In a first implementation form of the network apparatus according to the second aspect, the processor is configured to acquire a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast. In a second implementation form of the network apparatus according to the second aspect or according to the first implementation form of the second aspect, the processor is further configured to check the Multicast VPN FIB Table; and the processor is further configured to determine the second MDT tunnel as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast. In a third implementation form of the network apparatus according to the second aspect, according to the first implementation form of the second aspect or according to the second implementation form of the second aspect, the Multicast VPN FIB Table includes information indicating joint point devices from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device. In a forth implementation form of the network apparatus according to the second aspect, according to the first implementation form of the second aspect, according to the second implementation form of the second aspect or according to the third implementation form of the second aspect, the processor is further configured to establish a multicast routing table for the core segment with an address of the SPE as a source address, a VPN * next hop address as a destination address, and the second MDT as outgoing interface. In a fifth implementation form of the network apparatus according to the second aspect, according to the first implementation form of the second aspect, according to the second implementation form of the second aspect, according to the third implementation form of the second aspect or according to the fifth implementation form of the second aspect, the multicast message received from the aggregation network segment is encapsulated on a first MDT further comprising: a multicast routing table for the aggregation segment is configured with SPE address as a destination address; the first MDT is configured as outgoing interface.

According a third aspect, there is provided a computer-readable program, wherein when the program is executed in a network apparatus, the program enables the computer to carry out the method comprising: receiving the multicast message from the aggregation network segment; the network apparatus is located between the aggregation network segment and the core network segment; the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment; the network apparatus decapsulates the received multicast message; the network apparatus encapsulats the multicast message on a second MDT tunnel which is structed in the core network segment; and the network apparatus sends the encapsulated multicast message through the core network segment. According a fourth aspect, there is provided a storage medium in which a computer-readable program is stored, wherein the computer-readable program enables the computer to carry out the method comprising: receiving the multicast message from the aggregation network segment; the network apparatus is located between the aggregation network segment and the core network segment; the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment; the network apparatus decapsulates the received multicast message; the network apparatus encapsulats the multicast message on a second MDT tunnel which is structed in the core network • segment; and the network apparatus sends the encapsulated multicast message through the core network segment. These and further aspects and features of the present invention will be apparent with reference to the following description and attached drawings. In the description and drawings, particular embodiments of the invention have been disclosed in detail as being indicative of some of the ways in which the principles of the invention may be employed, but it is understood that the invention is not limited correspondingly in scope. Rather, the invention includes all changes, modifications and equivalents coming within the spirit and terms of the appended claims.
Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.

It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. To facilitate illustrating and describing some parts of the invention, corresponding portions of the drawings may be exaggerated in size, e.g., made larger in relation to other parts than in an exemplary device actually made according to the invention. Elements and features depicted in one drawing or embodiment of the invention may be combined with elements and features depicted in one or more additional drawings or embodiments. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views and may be used to designate like or similar parts in more than one embodiment.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

The drawings are included to provide further understanding of the present invention, which constitute a part of the specification and illustrate the preferred embodiments of the present invention, and are used for setting forth the principles of the present invention ' together with the description. The same element is represented with the same reference number throughout the drawings.

In the drawings:

Figure 1 depics a flow diagram of a detailed method, in accordance with an embodiment.

Figure 2 depicts a block diagram of a LTE back haul in accordance with an embodiment.

Figure 3 depics a flow diagram of a detailed method, in accordance with an embodiment.

Figure 4 depics a flow diagram of a detailed method, in accordance with an embodiment.

Figure 5 depics a flow diagram of a detailed method, in accordance with an embodiment.

Figure 6 depics a data structure, in accordance with an embodiment.

Figure 7 is a simplified block diagram of a machine in the example form within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.

Figure 8 depics a block diagram of an example network apparatus, in accordance with an embodiment.

DETAILED DESCRIPTION

The many features and advantages of the embodiments are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the embodiments that fall within the true spirit and scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the inventive embodiments to the exact ' construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope thereof. The preferred embodiments of the present invention are described as follows in reference to the drawings. The method for communicating multicast messages through virtual private network applies to the network senairo as shown in Fig. 2. In Fig. 2, CE-1 S refers to the customer edge device of the multicast source, and CE-1 D refers to the custermer edge device of the multicast destination. The network is divided into three segments, wherein Metro refers to Metro Area network (MAN) which provides a bridge between traditional enterprise network and core network, and Core refers to service provider's core network. In LTE Mobile back-haul, the custermer edge devices group, Metro Area network and core network of service provider each consists a Autonomous System (AS) corresponding to access, aggregation and core segments of the LTE Mobile back-haul UPE-1A and UPE-2D refer to User side Service Provider Edge devices (UPE) that are Cell site routers facing the customer nodes. SPE-1B and SPE-2C refer to Service Provider Edge devices (SPE) that are aggregate routers. SPE-1B and SPE-2C may be boder routers of the AS/Metro segments that support inter-AS connectivity for MVPN. In one embodiment, Figure 1 illustrate a simplified example procedure for communicating muticast messages through Virtual Private Network, particularly for the perspective of a SPE desiring to receive and send multicast message between a aggregation network and a core network. The procedure starts at SI 10, illustratively the SPE receives the multicast message from the aggregation network segment. The multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT) which is constructed in the aggregation network. At SI20, the SPE decapsulates the received multicast message. At SI30, the SPE encapsulates the multicast message on a second MDT which is structed in the core network segment. At SI40, the SPE sends the encapsulated multicast message through the core network segment.

By this approach, the routing policy is configured to connect two network segments by a PE with MDT tunnels through the segments. Thus, existing MDT tunnel are ' reused to achieve Segmented Network to carry Multicast VPN traffic. In one instance, Figure 3 illustrates another simplified example procedure for communicating muticast messages through Virtual Private Network. At S310, illustratively the SPE receives the multicast message from the aggregation network segment. At S320, the SPE decapsulates the received multicast message. At S330, the SPE acquires a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast. At S340, the SPE checks a Multicast VPN FIB Table and determining the second MDT as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast. At S 350, the SPE sends the encapsulated multicast message through the core network segment. UPE/SPEs are configured with VRF and MDT tunnel bindings. The private VPN PIM session is used for discovery to construct the route from CE-1S to CE-1D. As shown in Figure 2, illustratively, a multicast message comes from source CE-1 to UPE-1A. The multicast message includes at least a (source, group) tuple where the source is the IP address of the sender, and the group is the IP multicast group address of the destination. The group address of the destination is identified as "gvpn" as shown in Figure 2. "gvpn" is a private VPN's multicast group address. At UPE-1A, Routing and Forwarding (VRF) are configured with the RD (route distinguisher), RT (route target) and multicast address within the aggregation network segment. A Route Distinguisher (RD) may be an 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN IPv4 prefix. The IP prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a member of the VPN-IPv4 address family. It serves to uniquely identify the customer address, even if the customer site is using globally non-unique (unregistered private) IP addresses. The route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command associated with the VRF on the PE router. A VRF is a routing table instance, which can exist in one instance or multiple instances per each VPN on a Provider Edge (PE) router. VRF may be implemented in a ' network device by distinct routing tables known as forwarding information bases (FIBs), one per VRF. Alternatively, a network device may have the ability to configure different virtual routers, where each one has its own FIB that is not accessible to any other virtual router instance on the same device.

Based on incoming packet customer gvpn destination address, the UPE-1A lookup "Multicast VPN FIB Table". The multicast routing protocol PIM VRF binded instance is responsible for adding enteries into the multicast VPN FIB table. The UPE-1 A determines that the outgoing interface of the multicast will be the first MDT, illustratively, "L3 MDT -1" through the aggregation network segment. The UPE-1 A encapsulates the multicast message on the first MDT, for example, the (source, group) tuple of the multicast message is encapsulated with the address of UPE-1 A as a source address and gpub is a multicast public group address used to identify the public MDT. Then, the multicast message is sent through the aggregation network segment on the first MDT. A Multicast Distribution Tunnel (MDT), can be a multicast GRE Tunnel, is built across the provider network and spans a single BGP Autonomous System (AS). As shown in Figure 2, public Protocol Independent Multicast (PIM) running in the aggregation network segment will construct MDT-1, this tunnel boundary ends in the aggregation network segment. PIM is enabled on top of 'MDT Tunnel' for each VPN-interface in each segment (UPEs, SPEs).
On a PE router, each VRF has its own multicast routing and forwarding database called MVRF. Each MVRF has its own Multicast Domain. Each multicast domain is assigned a distinct group address from a pool administered by the service provider(s). The group ranges used by these multicast domains are called MDT groups. A Multicast Tunnel is established between the two end-points of two Multicast VRFs on two PEs. The Multicast VPN traffic travels over these tunnels. For example, the source addresse of MDT-1 is the address of UPE-1 A.To connect the MVPN's across autonomous systems, a MDT-default tunnel is set up between the two PE's. The PE's accomplish that by joining the configured MDT-default group. This MDT-default group is configured on the PE and unique per VPN. Both PE's know the MDT-default group address. In Source Specific Multicast (SSM) mode they also need to know the source address, which is an address configured on the PE.

Multicast-capable VRFs have a unique default-MDT associated with each VRF on a PE. Sites belonging to the same VPN have the same default-MDT. A default-MDT tunnel is setup between the PEs (one per VPN). This default-MDT Tunnel is triggered by a PIM Join to the default-MDT Group address, which is sent to all the PEs that have the default-MDT configured on any of their attached VRFs. This information is advertised by those PEs to all the other routers in the aggregation network segment, for instance via BGP. When multicast trees are built using the MDT-default MVPN traffic traverses the MDT-default tunnel. At SPE-1B, the encapsulated multicast message is first de-capsulated. Based on customer gvpn destination address, SPE-1B lookup "Multicast VPN FIB Table" . FIB indicates a table that provides information for network hardware (bridges and routers) for them to forward data packets to other networks. All the VPN routes from one segment will be available in other segment' s 'Multicast VPN FIB Table'. For example, all the VPN routes from the aggregation network segment will be available in the core network segment. This is achieved by configuring a back-to-back VPN at SPE-1B and SPE-2C. At SPEs back-to-back VRFs are configured based on VPN (similar to inter-AS option-A). RFC2547 (version 03) discloses a method for configuring VPN service between autonomous systems, namely, inter-AS option-A, the entir teaching is incorporate herewith by reference.
For destination address "gvpn" , SPE-1B determines the outgoing interface for the multicast routing is the second MDT, illustratively in Figure 2, " L3 MDT-2 ". In addition, since private PIM is enabled on MDT-1, which learned the gvpn address under that VPN. Private PIM VPN instance creates a separate PIM multicast domain over which customer private multicast routes are learned and downloaded.
The SPE-1B encapsulates the multicast message on the second MDT, for example, the (source, group) tuple of the multicast message is encapsulated with the address of SPE-1B as a source address and gpub is the public multicast group address of the L3 MDT-2 tunnel. Then, the multicast message is sent through the aggregation network segment on the second MDT. At SPE-2C, similar steps as performed by SPE-1B are repeated, and the multicast message is forwarded on MDT-3 through the second aggregation network segment. At UPE-2D, firstly, multicast message encapsulated by SPE-2C is de-capsulated by UPE-2D. Then, based on the "gvpn address", the multicast message will be forwarded to corresponding custermer edge device, illustratively, CE-ID. The advantages of the embodiment, shown in Figure 2, exist at least in that SPE only advertise default multicast route towards UPE, reducing the MVPN Routing and Forwarding table size. In another instance, Figure 4 illustrates a simplified example procedure for encapsulating the multicast message on the second MDT. At S410, the SPE configures a multicast routing table for the core segment with an address of the SPE as a source address, and a VPN next hop address as a destination address. At S420, SPE configures the second MDT tunnel as outgoing interface. In another instance, Figure 5 illustrates a simplified example procedure for encapsulating the multicast message on the first MDT. At S510, a multicast routing table for the aggregation segment is configured with SPE address as a destination address. At S520, the first MDT is configured as outgoing interface. In another instance, as shown in Figure 6, illustratively, de-capsulation at 'MTD1 Tunnel' and Encapsulation on 'MTD2 Tunnel' at SPE are presented. Firstly, SPE read the "Tunnel packet" IP Layer, where gpub is SPE' s address and sends to a Tunnel Module. "Incoming interface index to vpn mapping" is retained in the packet (MBUF) to refer the corresponding "Multicast VPN FIB". After de-capsulating, the 'private gvpn' header is looked in to corresponding "Multicast VPN FIB Table".

Since private PIM (per each VPN) was enabled on MTD2 tunnel, 'gvpn address' was learned and added "multicast FIB" for that VPN. For "gvpn destination address", the out Going interface is MTD2. IP will send the packet to Tunnel Module, which will encapsulated the MTD2 Public header. The encapsulated packet will be forwarded on MTD2 global Tunnel. Certain embodiments described herein may be implemented as logic or a number of modules, receiver, processor, or sender.' A module, receiver, processor, or sender (collectively referred to as a "module") may be a tangible unit capable of performing certain operations and configured or arranged in a certain manner. In certain example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) or firmware (note that software and firmware can generally be used interchangeably herein as is known by a skilled artisan) as a module that operates to perform certain operations described herein. In various embodiments, a module may be implemented mechanically or electronically. For example, a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor, application specific integrated circuit (ASIC), or array) to perform certain operations. A module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software or firmware to perform certain operations. It will be appreciated that a decision to implement a module mechanically, in the dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be driven by, for example, cost, time, energy-usage, and package size considerations.

Accordingly, the term module should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering embodiments in which modules or components are temporarily configured (e.g., programmed), each of the modules or components need not be configured or instantiated at any one instance in time. For example, where the modules or components comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different modules at different times. Software may accordingly configure the processor to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules can provide information to, and receive information from, other modules. Accordingly, the described modules may be regarded as being communicatively coupled. Where multiples of such modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices and can operate on a resource (e.g., a collection of information). FIG. 7 is a simplified block diagram of a machine in the example form of an apparatus 700 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines. The machine is capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example apparatus 700 includes a processor 702 (e.g., a central processing unit (CPU)), a main memory 704, and a static memory 706, which communicate with each other via bus 708. The apparatus 700 may also include a disk drive unit 810 and a network interface device 720. The disk drive unit 716 includes machine-readable medium 814 on which is stored one or more sets of instructions and data structures 722 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, within the main memory 704 and/or within the processor 702 during execution thereof by the apparatus 700, with the main memory 704 and the processor 702 also constituting machine-readable, tangible ' media. The instructions 724 may further be transmitted or received over network 726 via network interface device 720 utilizing any one of a number of well-known transfer protocols. While machine-readable medium 722 is shown in an embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches) that store the one or more sets of instructions. The term "machine-readable medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present application, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media. In one embodiment, Figure 8 illustrates a block diagram of an example network apparatus 800 for communicating muticast messages through Virtual Private Network. The network apparatus 800 is located between a aggregation network segment 840 and a core network segment 850, the VPN is between a multicast source point and a multicast destination point, and a route of the VPN passes from a first custermer edge device through at least a first aggregation network segment 840, a core network segment 850 and a second aggregation network segment to a second custermer edge device, the network apparatus 800 comprises a receiver 810, a processor 820 and a sender 830.

Receiver 810 may receive the multicast message from the aggregation network segment 840, the multicast message received from the aggregation network segment 840 is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment 840. Processor 820 may decapsulate the received multicast message and encapsulats the multicast message on a second MDT which is structed in the core network segment 850. Sender 830 may send the encapsulated multicast message through the core network segment.
By this approach, the routing policy is configured to connect two network segments by a network apparatus with MDT tunnels through the segments. Thus, existing MDT tunnel are reused to achieve Segmented Network to carry Multicast VPN traffic. In an instance, processor 820 may acquire a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast. In another instance, processor 820 may check the Multicast VPN FIB Table, and processor 820 may further determine the second MDT tunnel as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast. The Multicast VPN FIB Table includes information indicating joint point devices from a first custermer edge device through at least a first aggregation network segment 840, a core network segment 850 and a second aggregation network segment to a second custermer edge device. Processor 820 may further establish a multicast routing table for the core segment with an address of the network apparatus as a source address, a VPN next hop address as a destination address, and the second MDT as outgoing interface.

The multicast message received from the aggregation network segment 840 is encapsulated on a first MDT. The encapsulation on the first MDT includes a multicast routing table for the aggregation segment which is configured with SPE address as a destination address, and the first MDT is configured as outgoing interface. Network apparatus 800 are configured with VRF and MDT tunnel bindings. The private VPN PIM session is used for discovery to construct the route from CE-1S to CE-1D. Processor 820 may configure Routing and Forwarding (VRF) with the RD (route distinguisher), RT (route target) and multicast address within the core network segment 850. A Route Distinguisher (RD) may be an 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN IPv4 prefix. The IP prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a member of the VPN-IPv4 address family. It serves to uniquely identify the customer address, even if the customer site is using globally non-unique (unregistered private) IP addresses. The route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command associated with the VRF on the PE router. A VRF is a routing table instance, which can exist in one instance or multiple instances per each VPN on a Provider Edge (PE) router. VRF may be implemented in a network device by distinct routing tables known as forwarding information bases (FIBs), one per VRF. Alternatively, a network device may have the ability to configure different virtual routers, where each one has its own FIB that is not accessible to any other virtual router instance on the same device.

The multicase massage received by Receiver 820 processes gvpn destination addresses. Processor 820 may lookup "Multicast VPN FIB Table", after the decapsulation of the multicase message. The multicast routing protocol PIM VRF binded instance is responsible for adding enteries into the multicast VPN FIB table. Processor 820 may determines that the outgoing interface of the multicast will be the second MDT through the core network segment 850. In addition, since private PIM is enabled on MDT-1, which learned the gvpn address under that VPN. Private PIM VPN instance creates a separate PIM multicast domain over which customer private multicast routes are learned and downloaded. Processor 820 may encapsulate the multicast message on the second MDT, for example, the (source, group) tuple of the multicast message is encapsulated with the address of network apparatus 800 as a source address and gpub is a multicast public group address used to identify the public MDT. Then, Sender 830 may send the multicast message through the aggregation network segment on the second MDT.
A Multicast Distribution Tunnel (MDT), can be a multicast GRE Tunnel, is built across the core network segment 850 and spans a single BGP Autonomous System (AS). Public Protocol Independent Multicast (PIM) running in the core network segment will construct the second MDT, this tunnel boundary ends in the core network segment 850. PIM is enabled on top of 'MDT Tunnel' for each VPN-interface in each segment (840 or 850).

Each VRF may have its own multicast routing and forwarding database called MVRF. Each MVRF has its own Multicast Domain. Each multicast domain is assigned a distinct group address from a pool administered by the service provider(s). The group ranges used by these multicast domains are called MDT groups. A Multicast Tunnel is established between the two end-points of two Multicast VRFs on two PEs. The Multicast VPN traffic travels over these tunnels. For example, the source addresse of the second MDT is the address of the network apparatus 8OO.T0 connect the MVPN's across autonomous systems, a MDT-default tunnel is set up between the two PE's. The PE's accomplish that by joining the configured MDT-default group. This MDT-default group is configured on the PE in the core network segment 850 and unique per VPN. Both PE's know the MDT-default group address. Multicast-capable VRFs have a unique default-MDT associated with each VRF on a PE. Sites belonging to the same VPN have the same default-MDT. A default-MDT tunnel is setup between the PEs (one per VPN). This default-MDT Tunnel is triggered by a PIM Join to the default-MDT Group address, which is sent to all the PEs that have the default-MDT configured on any of their attached VRFs. This information is advertised by those PEs to all the other routers in the core network segment 850, for instance via BGP. When multicast trees are built using the MDT-default MVPN traffic traverses the MDT-default tunnel.A FIB indicates a table that provides information for network hardware (bridges and routers) for them to forward data packets to other networks. All the VPN routes from one segment will be available in other segment' s 'Multicast VPN FIB Table'. For example, all the VPN routes from the aggregation network segment 840 will be available in the core network segment 850. This is achieved by configuring a back-to-back VPN at network apparatus 800. A back-to-back VRFs are configured based on VPN (similar to inter-AS option-A).

The advantages of the embodiment exist at least in that SPE only advertise default multicast route towards UPE, reducing the MVPN Routing and Forwarding table size. Particular embodiments of the present invention have been disclosed herein. Those skilled in the art will readily recognize that the present invention is applicable in other environments. In practice, there exist many embodiments and implementations. The ' appended claims are by no means intended to limit the scope of the present invention to the above particular embodiments. Furthermore, any reference to "a device to..." is an explanation of device plus function for describing elements and claims, and it is not desired that any element using no reference to "a device to..." is understood as an element of device plus function, even though the wording of "device" is included in that claim. Although a particular preferred embodiment or embodiments have been shown and the present invention has been described, it is obvious that equivalent modifications and variants are conceivable to those skilled in the art in reading and understanding the description and drawings. Especially for various functions executed by the above elements (portions, assemblies, apparatus, and compositions, etc.), except otherwise specified, it is desirable that the terms (including the reference to "device") describing these elements correspond to any element executing particular functions of these elements (i.e. functional equivalents), even though the element is different from that executing the function of an exemplary embodiment or embodiments illustrated in the present invention with respect to structure. Furthermore, although the a particular feature of the present invention is described with respect to only one or more of the illustrated embodiments, such a feature may be combined with one or more other features of other embodiments as desired and in consideration of advantageous aspects of any given or particular application.

WE CLAIMS

1. A method for communicating muticast messages through Virtual Private Network
(VPN), the VPN is between a multicast source point and a multicast destination point, and a route of the VPN passes from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device, the method comprising: receiving, by a Server Provider Edge device (SPE), the multicast message from the aggregation network segment,whereinthe SPE is located between the aggregation network segment and the core network segment and the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment;
decapsulating, by the SPE, the received multicast message; encapsulating, by the SPE, the multicast message on a second MDT tunnel which is structed in the core network segment; and sending, by the SPE, the encapsulated multicast message through the core network segment.

2. The method as claimed in claim 1, wherein after the SPE decapsulates the received multicast message, the SPE acquires a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast.

3. The method as claimed in claim 2, wherein the SPE checks a Multicast VPN FIB Table; and the SPE determines the second MDT as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast.

4. The method as claimed in claim 3, wherein the Multicast VPN FIB Table includes information indicating joint point devices from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device.

5. The method as claimed in claim 1, wherein the SPE encapsulats the multicast message on the second MDT further comprising: configuring a multicast routing table for the core segment with an address of the SPE as a source address, and a VPN next hop address as a destination address; and configuring the second MDT as outgoing interface.

6. The method as claimed in claim 1, wherein the multicast message received from the aggregation network segment is encapsulated on a first MDT further comprising: a multicast routing table for the aggregation segment is configured with SPE address as a destination address; and the first MDT is configured as outgoing interface.

7. A network apparatus for communicating muticast messages through Virtual
Private Network (VPN), the network apparatus is located between a aggregation network segment and a core network segment, the VPN is between a multicast source point and a multicast destination point, and a route of the VPN passes from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device, the network apparatus comprising: a receiver configured to receive the multicast message from the aggregation network segment, the multicast message received from the aggregation network segment is encapsulated on a first Multicast Distribution Tunnel (MDT), and the first MDT is constructed in the aggregation network segment; a processor configured to decapsulate the received multicast message and encapsulats the multicast message on a second MDT which is structed in the core network segment; and a sender configured to send the encapsulated multicast message through the core network segment.

8. The network apparatus as claimed in claim 7, wherein the processor is configured to acquire a Multicast VPN Forward Information Base (FIB) Table, a source address of the multicast and a destination address of the multicast.

9. The network apparatus as claimed in claim 8, wherein the processor is further configured to check the Multicast VPN FIB Table; and the processor is further configured to determine the second MDT tunnel as an out-going interface, based on the Multicast VPN FIB Table and the destination address of the multicast.

10. The network apparatus as claimed in claim 9, wherein the Multicast VPN FIB Table includes information indicating joint point devices from a first custermer edge device through at least a first aggregation network segment, a core network segment and a second aggregation network segment to a second custermer edge device.

11. The network apparatus as claimed in claim 7, wherein the processor is further configured to establish a multicast routing table for the core segment with an address of the SPE as a source address, a VPN next hop address as a destination address, and the second MDT as outgoing interface.

12. The network apparatus as claimed in claim 7, wherein the multicast message received from the aggregation network segment is encapsulated on a first MDT further comprising: a multicast routing table for the aggregation segment is configured with SPE address as a destination address; the first MDT is configured as outgoing interface.