Providing pim-sm support for mrsvp-te based multicast virtual private networks

PIM-SM support for multicast virtual private network based on mRSVP-TE

[0001] Cross reference of related applications

[0002] The present invention requires a US provisional patent application No. 61/666603 filed by Han Lin et al. on June 29, 2012, titled "Method for Providing PIM-SM Support for mVPN Solutions Based on mRSVP-TE" Priority of the earlier application of the case, the content of the earlier application is incorporated into this text by way of introduction in its entirety.

[0003] Regarding sponsored by the federal government

[0004] Statement of research or development

[0005] Not applicable.

[0006] Reference to Microfiche Attachment

[0007] Not applicable.

Background technique

[0008] Multicast Virtual Private Network (mVPN) allows service providers to configure and support multicast traffic in a Multi-Protocol Label Switching (MPLS) Virtual Private Network (VPN) environment. For example, an mVPN can support the routing and forwarding of multicast data packets of VPN routing and forwarding (VRF) instances, and provide a mechanism for transmitting VPN multicast data packets across the backbone of the service provider. mVPN may be useful for video conferencing or customer-specific broadcasts.

[0009] mVPN provides transparent interconnection within its private network that spans the network backbone of the service provider. Multicast service is a bandwidth saving solution that reduces data traffic by delivering a single data stream to multiple receivers. For example, a multicast data service can deliver source traffic to multiple receivers without adding additional burden to the source or receiver, while using the lowest network bandwidth.

[0010] There are various existing solutions that support mVPN on the service provider's network. These solutions can be used to carry Protocol Independent Multicast (PIM) signaling from customers on the service provider's network. However, these solutions can be complex to implement and lack scalability across the service provider's network. For example, at least one solution involves the use of Border Gateway Protocol (BGP). The solution may require BGP to extend 7 types of network layer reachability information (NLRI) and 4 new BGP attributes. Therefore, it may be necessary to provide a simpler and more scalable method to provide quality of service (QoS) guarantee and traffic engineering (TE) path support for mVPN applications.

Summary of the invention

[0011] In an exemplary embodiment, the multicast resource reservation protocol for traffic engineering extension (mRSVP-TE) is used to support protocol-independent multicast-sparse mode (PIM-SM).

[0012] PIM-SM is supported in the source operator edge (PE) router. In an example embodiment, the PIM state is created in the source PE router. In addition, a first unicast data message is sent to a rendezvous point (RP) PE router using the PIM state, wherein the first unicast data message is a PIM registration encapsulated as a unicast multi-protocol label switching (MPLS) packet news. The PIM join message is received from the RP PE router, wherein the PIM join message triggers the creation of a second PIM state. Finally, a second unicast data message is sent to the RP PE router via a default multicast distribution tree (MDT) using the second PIM state.

[0013] PIM-SM is supported in the RP PE router. In an exemplary embodiment, the PIM join message is sent by the RP PE router

Receiving, wherein the PIM join message triggers the creation of a PIM state. In addition, the first unicast data message is received from the source PE router using the PIM state, wherein the first unicast data message is a PIM registration message encapsulated as a unicast multiprotocol label switching (MPLS) packet. The multicast data traffic is sent to one or more receiver PE routers via a default multicast distribution tree (MDT) in response to receiving the first unicast data packet. Similarly, a second PIM join message is sent to the source PE router, where the second PIM join message triggers the creation of a second PIM state. The second unicast data message is received from the source PE router using the second PIM state, and a PIM registration stop message is sent to the source PE router in response to receiving the second unicast data message.

Description of the drawings

[0014] In order to have a more complete understanding of the present invention and its advantages, now refer to the following description in conjunction with the accompanying drawings, in which:

[0015] FIG. 1 shows a schematic diagram of an example embodiment of a network.

[0016] FIG. 2 shows an exemplary embodiment of a path message data packet.

[0017] FIG. 3 shows another exemplary embodiment of a path message data packet.

[0018] FIG. 4 shows another exemplary embodiment of a path message data packet.

[0019] FIG. 5 shows an exemplary embodiment in which a multicast distribution tree joins a data packet.

[0020] FIG. 6 shows another exemplary embodiment in which a multicast distribution tree joins a data packet.

[0021] FIGS. 7 to 10 show example embodiments of communication within mVPN.

[0022] FIG. 11 is a flowchart of an example embodiment of a multicast data communication method.

[0023] FIG. 12 is a flowchart of another exemplary embodiment of a multicast data communication method.

[0024] FIG. 13 is an example embodiment of a network device.

Detailed ways

[0025] It should be initially understood that although illustrative implementations of one or more example embodiments are provided below, any number of currently known or existing technologies may be used to implement the disclosed systems and/or methods. The present invention should never be limited to the illustrative embodiments, drawings and techniques described below, including the exemplary designs and embodiments described and described herein, but may be within the scope of the appended claims and their equivalents Modify within the full scope of the object.

[0026] mVPN can operate as part of a network infrastructure. For example, mVPN can form part of the network layer within the Open System Interconnection (OSI) model of the network architecture. The network layer can be used to provide path determination and logical addressing for data traffic (for example, one or more data packets) transmitted through the network. Therefore, the network layer can provide functions and/or procedural methods for transferring data traffic from a source host on one network to one or more target hosts on the same or different networks. For example, the network layer can be responsible for routing functions, encapsulation, data packet segmentation, data packet reassembly, error reporting, any other suitable data packet processing or operation functions that can be understood by those skilled in the art after seeing the present invention, and Its combination.

[0027] Multicast data traffic is transmitted via a multicast tree (for example, a Multicast Distribution Tree (MDT)), which may include two or more networks, for example, an MPLS network operated by a service provider and a customer office Point of Internet Protocol (IP) network. For example, multicast data traffic can be started at a customer site as IP multicast, and then can be uploaded to other customer sites on the MPLS network. In addition, in this example, the multicast data traffic can be distributed on the protocol-independent multicast (PIM) MDT of the customer site, and can be distributed via the multicast label switching path (mLSP) tunnel in the service providers MPLS network .

[0028] This document discloses an example embodiment in which mVPN utilizes PIM with MDT. In one or more exemplary embodiments disclosed in this text, mVPN is generally used to adopt the Multicast Resource Reservation Protocol for Traffic Engineering Extension (mRSVP-TE) to

Provides multicast services to deliver data traffic to multiple receivers. MRSVP-TE is an extension of the Resource Reservation Protocol (RSVP-TE) for traffic engineering extensions in the MPLS network, which can utilize features from RSVP-TE, such as QoS guarantees and TE paths. However, compared to RSVP-TE, where the multicast data tree can be established by the multicast source or head node of the multicast data tree, the multicast data tree in mRSVP-TE can be driven by one or more multicast receivers or leaf nodes. . As disclosed in this text, in an exemplary embodiment where PIM is used at the customer site and mRSVPT-TE is used on the service providers PIM-not-enabled network, mVPN can be used to support the source host and the source host using the PIM-SM protocol. Multicast data service between multiple receiver hosts.

[0029] Referring to FIG. 1, an example embodiment of a network 100 is shown. The network 100 can be used as mVPN, hereinafter referred to as mVPNIOOo mVPNIOO-generally includes multiple routers (for example, a label switching router (LSR)), such as a root router 102, one or more receiver operator edge (PE) routers 104, one or Multiple source PE routers 106, rendezvous point (RP) PE routers 107, one or more customer edge (CE) routers 108, and one or more core routers 114. In addition, these multiple routers (for example, the root router 102, the recipient PE router 104, the source PE router 106, the RP PE router 107, the CE router 108, and the core router 114, etc.) may pass through one or more links 110 (for example, Wireless link or wired link) interconnection and data communication between each other. Further, mVPNIOO is used to adopt Internet Group Management Protocol (IGMP), Intermediate System to Intermediate System (IS-IS) Protocol, Routing Information Protocol (RIP), Border Gateway Protocol (BGP), Distance Vector Multicast Routing Protocol ( DVMRP), Multicast Open Shortest Path First (MOSPF), and/or any suitable routing protocol that can be understood by those skilled in the art after seeing the present invention.

[0030] In an exemplary embodiment, mVPN100 is used to adopt the PIM Sparse Mode (PIM-SM) protocol. In this example embodiment, mVPNIOO is used to create, identify, and/or track one or more PIM states (eg, virtual connections) between the source PE router 106 and one or more recipient PE routers 104, for example, Via the PIM status table, PIM (source, group) or (S, G) channel, PIM channel, etc. In an additional or alternative exemplary embodiment, any other suitable PIM-SM standards and/or protocols that can be understood by those skilled in the art after seeing the present invention can be adopted. In this type of example, the source (S) identifies the source address, and the group (G) identifies the SM target address. The receiver PE router 104 is used to transmit the (S, G) join message (for example, a data packet) to the source address to subscribe to the (S, G) channel. In addition, the source PE router 106 is used to provide a multicast data service when the receiver PE router 104 is subscribed to the channel (S, G). Therefore, the SM protocol can provide a "channel" abstraction to host applications, where each channel has a source PE router 106 and any number of receiver PE routers 104. In an additional exemplary embodiment, mVPNIOO can be further used to adopt one or more PIM multicast protocols (for example, PIM dense mode (PIM-DM), PIM source specific multicast (PIM-SSM), two-way PIM (BIDIR-PIM), etc.).

[0031] Each of the multiple routers (for example, the root router 102, the recipient PE router 104, the source PR router 106, the RP PE router 107, the CE router 108, the core router 114, etc.) may be used to connect to the network And/or devices that forward data packets between multiple networks. For example, the core router 114 may be a router in the service provider network 112, and may be used to form a backbone or part of the core for the service provider network 112. The recipient PE router 104 and/or the source PE router 106 may be routers in the service provider network 112 and may be used to form an interface between the service provider network 112 and one or more CE routers 108. Each PE router (for example, the receiver PE router 104 and the source PE router 106) includes a reverse path lookup (RPF) interface or an operator multicast service interface (PMSI), For example, the inbound interface (IIF) in the PIM state and the outbound interface (0IF) in the PIM state are used to manage the data traffic forwarding in mVPNIOO. In an example embodiment, the IIF and/or OIF may be configured as a selective operator multicast service interface (S-PMSI) of a point-to-multipoint (P2MP) tunnel, as will be disclosed herein. Alternatively, the IIF and/or OIF can be configured as an omni-directional inclusion mode operator multicast service interface (MI-PMSI) of a multipoint-to-multipoint (MP2MP) tunnel, as will be revealed in this article. In addition, each PE router may further include an outbound interface list (OLIST) of PIM status. In an exemplary embodiment,

The MI-PMSI interface can be the interface between the IP multicast tree and the MDT. In this example embodiment, when MI-PMSI is the 0IF in the 0LIST of the multicast forwarding item (S, G), the IP multicast stream (S, G) is copied for MI-PMSI and sent to the MI-PMSI interface . In another example embodiment, when the MI-PMSI is the IIF of the multicast forwarding item (S, G), if the decapsulated data packet is an IP packet and the source and group are S and G respectively, the received data Packets (for example, MPLS packets) are forwarded by forwarding items (S, G).

[0032] The source PE router 106 can be roughly described as a PE router where a multicast source (for example, a source host) is located or behind the CE router 108. In addition, the source PE router 106 may be described as having Internet Protocol (IP) on the IIF and MDT on the OIF (for example, default MDT, data MDT, etc.). Alternatively, the receiver PE router 104 can be roughly described as a PE router behind the CE router 108 where the multicast receiver (for example, the receiver host) is located. In addition, the receiver PE router 104 may be described as having the MDT on the IIF (for example, the default MDT, the data MDT, etc.) and the IP on the OIF. The RP PE router 107 may be a PE router and may be configured as the root of the non-source specific distribution tree of the multicast group. The CE router 108 may be a router controlled or operated by a customer (for example, a router on the user side), and is used to connect to the service provider network 112 through a PE router or the like. Additionally, in an example embodiment, the CE router 108 may be configured as an RP router. Referring to the exemplary embodiment of FIG. 1, mVPN 100 includes a root router 102, a source PE router 106, and a core router 114 that perform data communication with the recipient PE router 104. In addition, each PE router (for example, the receiver PE router 104, the source PE router 106, and the RP PE router 107) communicates with CE router 108. In addition, each router can be used to control and/or direct data traffic for a given mVPN using routing tables, forwarding tables, and mVPN tables. For example, each router can generate or create a routing table to coordinate data communication with other routers in mVPNIOO. In an example embodiment, the routing table may be implemented by a flooding algorithm, a spanning tree algorithm, a reverse path broadcast algorithm, a truncated reverse path broadcast algorithm, a reverse path multicast algorithm, a core-based tree algorithm, or any other suitable A person skilled in the art can create a multicast forwarding algorithm that the present invention will understand. In addition, one or more routers (for example, the root router 102, the recipient PE router 104, the source PE router 106, the RP PR router 107, etc.) may include a settable data flow threshold (for example, the upper limit of the data flow rate) and It can be used to initiate data MDT formation in response to exceeding the data traffic flow threshold, as will be revealed in this article.

[0033] Those of ordinary skill in the art understand that the multicast label switching path (mLSP) can also be referred to as MDT, so these two terms can be used interchangeably. MDT is generally used to provide multicast services for mVPNIOO. For example, one or more MDTs can be created, each of which can pass through multiple routers (for example, root router 102, receiver PE router 104, source PE router 106, RP PE router 107, CE router 108, core router 114, etc.) Define one or more paths (for example, virtual paths) within mVPNIOO to control and/or direct the flow of data traffic through mVPNIOO, for example, between the source host and multiple receiver hosts interested in a specific multicast data stream Multicast business. MDT may include one or more sub-label switching paths (sub-LSP), which connect multiple routers (for example, LSR, core router, source PE router, receiver PE router, etc.) to form an MPLS multicast network. MDT can be configured as the default MDT to provide MP2MP packet communication, as will be revealed in this article. In this example, the root router 102 is the header of the default MDT, and each PE router is the leaf PEo of the default MDT. Alternatively, the MDT can be configured as a data MDT160 to provide P2MP packet communication, as this article will reveal Shown. In an example embodiment, the MDT may be head-driven or leaf-driven. For example, in a leaf-driven MDT, any leaf PE (for example, the source PE router 106) can initiate a data MDT 160, as will be disclosed in this article.

[0034] In this example embodiment, the default MDT may include a root router 102 that performs data communication with multiple PE routers (for example, the recipient PE router 104 and/or the source PE router 106). In addition, each PE router performs data communication with a CE router coupled to a host (for example, a source host, a receiver host, etc.). Default MDT can be used

Perform signaling, form one or more MDTs (for example, the data MDT disclosed in this article), trim the MDT (for example, remove inactive PE routers), add nodes (for example, PE routers) to the MDT, and transmit multicast data Traffic, perform any other suitable multicast service operations that those of ordinary skill in the art will understand after seeing the present invention, or a combination thereof. The default MDT is configured so that each PE router in mVPNIOO can be used as a source PE router and/or a receiver PE router, for example, each PE router can send and/or receive multicast data traffic. Further, the default MDT is used to provide two-way communication between routers (for example, PE routers). For example, the default MDT can be used to transmit PIM signaling messages and/or data packets. For example, the default MDT can support PIM signaling messages, such as join/prune messages, greeting messages, assert messages, bootstrap messages, registration stop messages, and so on.

[0035] In an exemplary embodiment, the data MDT can generally be used to offload data traffic from the default MDT to minimize or reduce wasted bandwidth, etc., for one or more routers. In an example embodiment, the data MDT includes a source host (eg, source terminal) in signal communication (eg, via the source PE 106) with multiple recipient hosts (eg, via multiple recipient PE routers 104). In this example embodiment, data MDT is used to transmit multicast data traffic only to interested receivers (eg, receiver hosts), thereby preserving the bandwidth of uninterested receivers and/or routers, as described in this article Revealed. The data MDT is configured such that the source PE router 106 and one or more recipient PE routers 104 communicate. The data MDT can be configured to be statically and/or dynamically created or established. For example, when the data MDT is configured to be statically established, the data MDT can be used to create in response to path messages transmitted from one or more recipient PE routers 104 to the source PE router 106. Alternatively, when the data MDT is configured to be dynamically established, the data MDT can be used to create in response to exceeding a predetermined threshold of multicast data traffic. In addition, the data MDT can be used to operate similarly to the data MDT of mVPN based on Multipoint Generic Routing Encapsulation (mGRE).

[0036] With reference to FIGS. 2 to 6, one or more signaling data packets can be routed to mVPNIOO routers (root router 102, receiver PE router 104, source PE router 106, RP PE router 107, CE router 108, core Router 114, etc.) to create one or more MDTs (for example, default MDT or data MDT), etc. For example, the source host may transmit one or more signaling data packets to one or more recipient hosts to form a default MDT and/or data MDT, as will be disclosed herein.

[0037] Referring to FIGS. 2 to 4, mRSVP-TE path message data packets (for example, mRSVP-TE path message data packets 200a, 200b, and 200c) are shown. In the example embodiment of FIG. 2, the mRSVP-TE path message data packet 200a includes multiple data fields, for example, VP7 identification (ID) 202a. Customer source (c-source) address field 204a and customer group (c-group) Address field 206a. Referring to FIG. 2, the mRSVP-TE path message data packet 200a of Internet Protocol version 4 (IPv4) includes a 64-bit VPN ID 202a, a 32-bit c-source address field 204a, and a 32-bit c-group address field 206a.

[0038] In the example embodiment of FIG. 3, each mRSVP-TE path message data packet 200b includes a plurality of data fields, for example, a VPN identification (ID) 202b, a c-source address field 204b, and a c-group address field 206b . 3, the IPv6 mRSVP-TE path message data packet 200b includes a 64-bit VPNID 202b, a 128-bit c-source address field 204b, and a 128-bit c-group address field 206b.

[0039] Although the exemplary embodiments of FIGS. 2 and 3 are respectively disclosed in terms of the specific bit size of each data field, it should be noted that any data field can be any suitable and those of ordinary skill in the art will see the present invention. Know the bit size. In an example embodiment, the VPN ID may be an mVPN identifier. In addition, the c-source address field may indicate the address of the traffic source (for example, the source host) in mVPNIOO. Further, the c-group address field may indicate the destination or group address of multicast traffic in mVPNIOO.

[0040] In an alternative embodiment shown in FIG. 4, the mRSVP-TE path message data packet 200c includes a plurality of data

According to fields, for example, VPN ID 202c and MDT number 208. The mRSVP-TE path message data packet 200c may have the same structure and/or format as IPv4 and IPv6. In addition, the IPv4 and IPv6 mRSVP-TE path message data packet 200c includes a 64-bit VPN ID 202c and a 32-bit MDT number 208. Although the exemplary embodiment of FIG. 4 is disclosed in terms of the specific bit size of each data field, it should be noted that any data field can be any suitable bit size that can be understood by those of ordinary skill in the art after seeing the present invention. In the example embodiment of FIG. 4, VPN ID 202c may be an mVPNIOO identifier. The MDT number 208 may be an MDT identifier. The MDT number field may be the identifier of the default MDT or the data MDTo of a specific mVPNIOO. For example, the MDT number 208 may be 0 for the default MDT, and may be a non-zero number for the data MDT. In addition, the MDT number 208 may be assigned by a PE router (eg, the source PE router 106).

[0041] Referring to FIG. 5, an MDT join TLV packet (for example, MDT join TLV packet 250a, 250b) or an MDT join message is shown. Referring to FIG. 5, an IPv4MDT join TLV packet 250a is shown. In the example embodiment of FIG. 5, the MDT join TLV packet 250a includes multiple data fields, for example, a type field 252a, a length field 254a, a reserved field 256a, a c-source address field 258a, a c-group address field 260a, and MDT number field 262a. In this example embodiment, the IPv4 MDT join TLV packet 250a includes an 8-bit type field 252a, a 16-bit length field 254a, an 8-bit reserved field 256a, a 32-bit c-source address field 258a, and a 32-bit c-group. Address field 260a and 32-bit MDT number 262a.

[0042] Referring to FIG. 6, an IPv6 MDT join TLV packet 250b is shown. In the example embodiment of FIG. 6, the MDT join TLV packet 250b includes multiple data fields, for example, a type field 252b, a length field 254b, a reserved field 256b, a c-source address field 258b, a c-group address field 260b, and MDT number field 262b. In this example embodiment, the IPv6 MDT join TLV packet 250b includes an 8-bit type field 252b, a 16-bit length field 254b, an 8-bit reserved field 256b, a 128-bit c-source address field 258b, and a 128-bit c-group. Address field 260b and 32-bit MDT number 262b.

[0043] Although the exemplary embodiments of FIGS. 5 and 6 are respectively disclosed in terms of the specific bit size of each data field, it should be noted that any data field can be any suitable and those of ordinary skill in the art will see the present invention. Know the bit size. In the example embodiments of FIGS. 5 and 6, the type field may indicate the type or type of the message represented by the data packet. The length field may indicate the length or size of the TLV data packet added by the MDT. The reserved field may be a data field reserved for future use. In an example embodiment, the c-source field and the c-group field can be configured and/or utilized similarly to the c-source addresses 204a and 204b and the c-group addresses 206a and 206b shown above. In addition, the MDT number can be configured and/or utilized similarly to the MDT number 208 shown above.

[0044] The additional details of the mRSVP-TE path message data packet and the MDT joining TLV data packet can be submitted by Lin Han et al. on June 28, 2013 under the title "Used for mRSVP-TE Multicast Multicast Distribution Trees for mRSVP-TE Based Multicast Virtual Private Networks (Multicast Distribution Trees for mRSVP-TE Based Multicast Virtual Private Networks) are described in US Patent Application No. 13/931434, which is incorporated into this text by reference in its entirety.

[0045] FIGS. 7 to 10 show communications within mVPNIOO. mVPNIOO includes a router (for example, core router 114a) in the service provider network 112, which serves as the root router 102 so that the root router 102 communicates with multiple recipient PE routers 104, source PE router 106, RP PE router 107, and core router 114. Signal communication. For example, the root router 102 is coupled to the source PE router 106, the RP PE router 107, the first receiver PE router 104a, and the second receiver PE router 104b and the third receiver PE router 104c through the second core router 114b. In addition, each PE router (for example, receiver PE routers 104a-104c, RP PE router 107, and source PE router 106)

It can be coupled to a CE router (eg, CE router 108).

[0046] In this example, the mVPN 100 may create a default MDT to provide multicast data traffic services (for example, to transmit multicast signaling and/or data packets), for example, to be among routers in the service provider network 112 Provide MP2MP communication between. In addition, each of the receiving PE router 104a-104c, the source PE router 106, the RP PE router 107, and the CE router 108 are part of the same mVPN and share a public VPN ID. For example, once mVPNIOO is created and/or enabled, the public VPN The ID can be known and/or shared among the routers of the mVPNIOO. In an exemplary embodiment, the mRSVP-TE path message data packet can be generated by each PE router and transmitted to the root router 102 within mVPN100. In addition, in response to the mRSVP-TE path message packet, the root router 102 may transmit a response message to each PE router to create a default MDT. Therefore, the RPF interface of each PE router of the default tree can be configured for MI-PMSI. Alternatively, the default MDT can be created by any other suitable method that a person of ordinary skill in the art will understand when seeing the present invention.

[0047] FIG. 11 is a method for transmitting multicast data 400 in mVPN (for example, mVPNIOO). In block 402, a PIM state is created for the source PE router. For example, referring to the exemplary embodiment of FIG. 7, in response to the source PE router 106 receiving a PIM join message 302 (for example, a PIM join/prune message) from one or more recipient PE routers 104, only the joining attribute is a sense in the method 400. Interesting, therefore the PIM signaling message may be called a PIM join message), the PIM join message 302 triggers the creation of the PIM (S, G) state 304 at the source PE router 106. In an example embodiment, the PIM join message 302 includes one or more PIM channel subscription requests (for example, (S, G) join messages). For example, one or more recipient hosts request to join group G and source S through one or more recipient PE routers 104. In an exemplary embodiment, the source PE router 106 sets its OIF to MI-PMSI (MVPN), and the receiver PE router 104 sets MI-PMSI (MVPN) to its UFo

[0048] In block 404, the source PE router sends a first unicast data message (for example, a unicast mPLS packet) to the RP PE router. For example, referring to the example embodiment of FIG. 8, the source PE router 106 (eg, from a source host) receives the data traffic 308 and encapsulates the data traffic 308 to form a first unicast data message 308 a to be sent to the RP PE router 107. For example, the first unicast data message 308a is a unicast mPLS packet and is sent from the source PE router 106 to the RP PE router 107 through the default MDT (for example, through the PIM state).

[0049] In block 406, the source PE router receives a PIM signaling message (for example, a PIM join/prune message) from the RP PE router, but only the joining attribute is of interest in the method 400, so the PIM signaling message can be Called PIM join message). For example, referring to the exemplary embodiment of FIG. 9, the RP PE router 107 sends a PIM join message 316 to the source PE router 106 to trigger the creation of the second PIM state, etc. In this example embodiment, in response to the source PE router 106 receiving the PIM join message 316, the source PE router 106 creates a second PIM state, for example, MI-PMSI (MVPN) and (S, G) with the default MDT as the OIF. status. In block 408, the source PE router sends a second unicast data message (for example, a unicast mPLS packet) to the RP PE router. For example, after the second PIM state is created, the source PE router 106 sends the multicast data traffic 318 to one or more recipient PE routers 104 through the default MDT (eg, through the second PIM state). In addition, the source PE router 106 sends a second unicast data message 318a (for example, a unicast mPLS packet) to the RP PE router 107.

[0050] In block 410, the source PE router receives a PIM registration stop from the RP PE router. For example, referring to the exemplary embodiment of FIG. 10, in response to receiving the second unicast data message, the RP PE router 107 generates and sends a PIM registration stop message 322 to the source PE router 106. In this example embodiment, the source PE router 106 receives the PIM registration stop message 322 and suspends sending the second unicast data message to the RP PE router 107. In block 412, the source PE router 106 sends the multicast data traffic 320 to one or more PE receiver routers 104 via the default MDT.

[0051] In addition, in an exemplary embodiment, the source PE router generates a data MDT. For example, the source PE router 106 may monitor and/or detect the rate of the multicast data traffic for the multicast stream (S, G) in the mVPNIOO. In such an exemplary embodiment, the source PE router 106 may generate the data MDT 324 in response to the rate of the multicast data traffic of the multicast stream (S, G) exceeding a preset threshold. For example, the source PE router 106 may send an MDT join message (for example, an MDT join TLV packet) to one or more recipient PE routers 104 in response to exceeding a preset threshold. In addition, the source PE router 106 may receive path messages (eg, mRSVP-TE path messages) from one or more recipient PE routers 104, thereby creating a data MDT324. In an alternative exemplary embodiment, the data MDT324 may pass through any other Appropriate methods or protocol creations that those of ordinary skill in the art will understand after seeing the present invention. In addition, once the data MDT324 is created, the source PE router 106 and/or one or more recipient PE routers 104 can create an S-PMSI interface and modify it at the source PE router 106 and/or one or more recipient PE routers 104 (S, G) state. For example, the source PE router 106 can add S-PMSI (MNPV, MDT) is used as OIF, and one or more receiver PE routers 104 can add S-PMSI (MVPN, MDT) as IIF. In addition, the source PE router sends multicast data traffic to one or more receiver PE routers through the data MDT. For example, once the data MDT324 is created, multicast data traffic can be transmitted between the source PE router 106 and one or more recipient PE routers 104 through the data MDT324. In addition, the multicast data traffic is switched from the default MDT to the data MDT.

[0052] FIG. 12 is an additional exemplary embodiment of a method for transmitting multicast data 500 within an mVPN (such as mVPNIOO). In block 502, the RP PE router receives a first PIM join message (for example, a PIM (*, G) join message) from one or more recipient PE routers. For example, referring to the exemplary embodiment of FIG. 7, the RP PE router 107 receives a PIM join message 302 (for example, a PIM join/prune message) from one or more recipient PE routers 104, but only the join attribute is of interest in the method 500 Therefore, the PIM signaling message may be referred to as a PIM join message. The PIM join message 302 triggers the creation of the PIM (*, G) state 304 at the RP PE router 107. In an example embodiment, the PIM join message 302 includes one or more PIM channel subscription requests (for example, (*, G) join messages). For example, one or more recipient hosts request to join group G through one or more recipient PE routers 104. In an exemplary embodiment, the RP PE router 107 sets its OIF to MI-PMSI (MVPN), and the receiver PE router 104 sets MI-PMSI (MVPN) to its IIFo

[0053] In block 504, the RP PE router (eg, through the PIM state 304) receives the first unicast data message from the source PE router to trigger the registration process. For example, referring to the exemplary embodiment of FIG. 8, the RP PE router 107 receives the first unicast data message 308a from the source PE router 106, thereby triggering the registration process. Once the first unicast data message 308a is received, the RP PE router 107 may process (for example, decapsulate) the first unicast data message 308a to generate a local multicast data packet 310 (for example, a PIM registration message) and send the local The multicast message packet 310 is sent to the RP router 108a. In block 506, the RP PE router sends multicast data traffic to one or more recipient PE routers in response to receiving the first unicast data message from the source PE router. For example, in this example embodiment, in response to creating the first PIM state, the RP router includes an OIF pointing to the RP PE router and sends the returned local multicast data packet 312 back to the RP PE router 107. Once the returned local multicast data packet 312 is received from the RP PE router 108a, The RP PE router 107 sends the returned local multicast data packet 312 to one or more receiver PE routers 104 through the default MDT. In addition, in this exemplary embodiment, only the receiver PE router 104 may process the returned local multicast data packet 312 and send the returned local multicast data packet 312 to its CE router 108.

[0054] In block 508, the RP PE router sends a second PIM join message to the source PE router. For example, referring to the exemplary embodiment of FIG. 9, the RP PE router 107 sends a second PIM join message 316 to the source PE router 106 to trigger

Send the creation of the second PIM state, etc. In this exemplary embodiment, in response to sending the PIM join message 316, the RP PE router 107 creates a second PIM state, for example, MI-PMSI (MVPN) and takes the default MDT as the (S, G) state of the OIF. In block 510, the RP PE router receives the second unicast data message from the source PE router. For example, the source PE router 106 (for example, through the PIM second state) sends a second unicast data message 318a (for example, a unicast mPLS packet) to the RP PE router 107.

[0055] In block 512, the RP PE router sends a PIM registration stop message to the source PE router. For example, referring to the exemplary embodiment of FIG. 10, in response to receiving the second unicast data message 318a, the RP PE router 107 sends a PIM registration stop message 322 to the source PE router 106 to suspend the source PE router 106 from sending the second unicast data message 318a , Thereby registering the source PE router 106.

[0056] FIG. 13 shows an embodiment of a network device or device 900, which can be any device used to transmit data frames or packets through a network. The network device 900 may include one or more ingress ports 910 coupled to the receiver 912 (Rx), which may be used to receive packets or frames, objects, options, and/or type length values (TLV) from other network components. The network device 900 may include a logical unit or processor 920 coupled to the receiver 912, which may be used to process the packet or determine which network components to send the packet to. The logic unit or processor 920 may be implemented using hardware or a combination of software and hardware. The processor 920 may be implemented as one or more central processing unit (CPU) chips, cores (for example, multi-core processors), field programmable gate arrays (FPGA), application specific integrated circuits (ASICs) and/or digital signal processors (DSP). The network device 900 may further include a memory 922.

[0057] The memory 922 may include auxiliary memory, random access memory (RAM), and/or read only memory (ROM) and/or any other type of memory. The auxiliary storage may include one or more disk drives or tape drives, which may be used for non-volatile storage of data, and if the capacity of the RAM is insufficient to store all working data, the auxiliary storage may be used as an overflow data storage device. The auxiliary memory can be used to store programs, which will be loaded into RAM when these programs are selected for execution. ROM can be used to store instructions and possibly data read during program execution. ROM is a non-volatile storage device, and its storage capacity is usually small compared to the larger storage capacity of auxiliary storage. RAM is used to store volatile data and may also be used to store instructions. Access to both ROM and RAM is generally faster than access to auxiliary memory.

[0058] The network device 900 may also include one or more egress ports 930 coupled to a transmitter 932 (Tx), which may be used to transmit packets or frames, objects, options, and/or TLVs to other network components. Note that in reality, there may be two-way traffic handled by the network node 900, so some ports can both receive and transmit packets. In this sense, the ingress port 910 and the egress port 930 can be located at the same place, or can be regarded as different functions coupled to the same port of the transceiver (Rx/Tx). The processor 920, the receiver 912, and the transmitter 932 may also be used to implement or support any of the programs and methods described herein, such as methods for transmitting multicast data 400, 500.

[0059] It is reported that by programming and/or loading executable instructions onto the network device 900, at least one of the processor 920 and the memory 922 is changed to partially transform the network device 900 into a specific machine or device (for example, source PE router, receiver PE router, etc.). Executable instructions can be stored on the memory 922 and loaded into the processor 920 for execution. The functions realized by loading executable software to the computer can be converted into hardware implementation through well-known design rules, which is very basic in the fields of power engineering and software engineering. The decision to use software or hardware to implement a concept usually depends on the design stability and the number of units to be produced, rather than any issues involved in switching from the software domain to the hardware domain. In general, designs that change frequently are more suitable for implementation in software, because rewriting hardware implementations is more expensive than rewriting software designs. Generally, a stable and mass production design is more suitable for hardware such as ASIC

Implementation, because mass production running hardware implementation is cheaper than software implementation. The design can usually be developed and tested in the form of software, and then transformed into an equivalent hardware implementation in an application specific integrated circuit through known design rules, and the integrated circuit has hard-wired software instructions. The machine controlled by the new ASIC is a specific machine or device. Similarly, a computer programmed and/or loaded with executable instructions can be regarded as a specific machine or device.

[0060] In an exemplary embodiment, as disclosed herein or a part thereof, mVPNIOO using MDT (for example, default MDT and data MDT) and/or methods using MDT may be preferably adopted to provide multicast services. In an exemplary embodiment where PIM is used at the customer site and mRSVP-TE is used on the service providers PIM-not-enabled network, mVPN (for example, mVPNIOO) can be used to provide interoperability between the customers PIM and service providers mRSVP-TE capabilities. In addition, mVPNIOO provides the ability to use the PIM-SM protocol to support mRSVP-TE multicast data services between a source host and multiple receiver hosts. Therefore, the exemplary embodiments disclosed herein improve the performance of the multicast data communication system.

[0061] The present invention discloses at least one example embodiment, and changes, combinations and/or modifications made by those of ordinary skill in the art to the example embodiment and/or the features of the example embodiment are all disclosed in the present invention In the range. Alternative exemplary embodiments obtained by combining, merging and/or omitting features of the exemplary embodiments are also within the scope of the present invention. It should be understood that the present invention has clearly clarified numerical ranges or limitations, and such explicit ranges or limitations shall include coverage in the above-mentioned ranges or limitations (for example, the range from about 1 to about 10 includes 2, 3, 4, etc.; greater than The range of 0.10 includes 0.11, 0.12, 0. 13 etc.) within a similar order of iteration range or limitation. For example, whenever a numerical range with a lower limit Ri and an upper limit is disclosed, it specifically discloses any number falling within the range. Specifically, the following numbers within the stated range are specifically disclosed: R = Ri+k*(Ru-Rj, where k is a variable that increases in 1% increments from 1% to 100%, that is, k is 1%, 2%, 3%, 4%, 5%, 50%, 51%, 52%, 95%, 96%, 97%, 98%, 99% or 100%. In addition, it is hereby disclosed that the above Any numerical range defined by the two R values defined. Unless otherwise specified, the term about is used to mean ±10% of the following digits. The use of the term "optional" with respect to a certain element of a claim indicates that element It can be "required" or "unnecessary", both of which are within the scope of the claims. The use of broader terms such as "including", "including" and "having" should be understood as Provide support for narrower terms such as "consisting of," "essentially consisting of," and "substantially consisting of." All documents described in this article are incorporated into this article by way of introduction.

[0062] Although several example embodiments have been provided in the present invention, it should be understood that the system and method disclosed in the present invention may be embodied in many other specific forms without departing from the spirit or scope of the present invention. The examples of the present invention should be regarded as illustrative rather than restrictive, and the present invention is not limited to the details given in this text. For example, various elements or components may be combined or combined in another system, or certain features may be omitted or not implemented.

[0063] In addition, without departing from the scope of the present invention, the technologies, systems, subsystems, and methods described and illustrated in various exemplary embodiments as discrete or separate can be combined with other systems, modules, technologies, or methods. Combine or merge. Other items shown or discussed as being coupled or directly coupled or communicating with each other may also be indirectly coupled or communicating through an interface, device, or intermediate component in an electrical, mechanical, or other manner. Examples of other changes, substitutions, and changes can be determined by those skilled in the art without departing from the spirit and scope of the disclosure.