WO2020244372A1 - 一种实现组播的方法和装置 - Google Patents
一种实现组播的方法和装置 Download PDFInfo
- Publication number
- WO2020244372A1 WO2020244372A1 PCT/CN2020/090725 CN2020090725W WO2020244372A1 WO 2020244372 A1 WO2020244372 A1 WO 2020244372A1 CN 2020090725 W CN2020090725 W CN 2020090725W WO 2020244372 A1 WO2020244372 A1 WO 2020244372A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- route
- network device
- multicast
- transmission path
- source
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/033—Topology update or discovery by updating distance vector protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/30—Routing of multiclass traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/34—Source routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
Definitions
- This application relates to the field of communication technology, and in particular to a method and device for implementing multicast.
- traffic When traffic is forwarded in the network, it may pass through multiple different data centers (English: data center, DC for short). Among them, traffic is usually transmitted from the edge device of one DC to the edge device of another DC, so as to realize cross-DC forwarding. In many networks, the same network device will be used by two adjacent DCs as edge devices. That is, the edge devices of two adjacent DCs are combined into one network device. This network device can be called a combined Set up equipment. However, if the transmission path between the multicast source and the multicast user needs to be forwarded from one DC to another DC through a joint device, the multicast source cannot provide multicast services for the multicast user.
- DC data center
- the embodiments of the present application provide a method and device for implementing multicast, so that when a multicast source and a multicast user located in different DCs communicate via a joint device, the multicast source can serve the multicast Users provide multicast services.
- the embodiments of this application provide a method for implementing multicast in a next-generation multicast virtual private network (English: Next Generation Multicast Virtual Private Network, abbreviated as: NG MVPN), and the method is applied to include the first network In a network of devices, second network devices, and third network devices, in the network, the first network device is an edge device that communicates with the first DC and the second DC, and the second network device is the second DC and the third DC Edge device, the third network device belongs to the first DC.
- the method may specifically include: a first route sent by the second network device to the first network device, the first route carrying a second device identifier and a second AS number, wherein the second device identifier indicates that the second network device and the second network device 2.
- VPN Virtual Private Network
- the third network in the network can trace back to the first network device according to the received second route. Similarly, the first network device can also trace back to the second network device according to the received first route. In this way, the multicast can be determined
- the multicast path from the source to the multicast user makes it possible for the traffic of the multicast source to perform accurate cross-DC multicast in the NG MVPN, that is, the multicast source and the multicast user located in different DCs are conducted through a co-located device
- the multicast source can provide multicast services for the multicast user.
- the first route includes a second virtual route forwarding route import VRF route import extended community attribute and a second source autonomous system Source AS extended community attribute, the second VRF route import The extended community attribute includes the second device identifier, and the second Source AS extended community attribute includes the second AS number.
- the second route includes the first VRF route impot extended community attribute and the first Source AS extended community attribute, the first VRF route impot extended community attribute includes the first device identifier, and the first Source AS extended community attribute
- the community attribute includes the first AS number.
- the cross-DC co-located device replaces the device ID and AS number in the two extended community attributes with The device ID and AS number corresponding to itself will carry the updated two extended community attributes in the route and continue to be published on the network, which provides a basis for the multicast source to provide multicast services on the network.
- the first route is a virtual private network VPN route of the edge gateway protocol BGP, specifically a VPNv4 route of the BGP protocol;
- the second route is a BGP Ethernet virtual private network EVPN route, specifically a BGP EVPN Protocol IP prefix routing (also called Type5 routing) or MAC/IP advertising routing (also called Type2 routing).
- BGP Ethernet virtual private network EVPN route specifically a BGP EVPN Protocol IP prefix routing (also called Type5 routing) or MAC/IP advertising routing (also called Type2 routing).
- BGP Ethernet virtual private network EVPN route specifically a BGP EVPN Protocol IP prefix routing (also called Type5 routing) or MAC/IP advertising routing (also called Type2 routing).
- BGP EVPN Protocol IP prefix routing also called Type5 routing
- MAC/IP advertising routing also called Type2 routing
- the second DC and the third DC belong to the same domain.
- the process of establishing the first transmission path from the second network device to the first network device, and the process of establishing the second transmission path from the first network device to the third network device may specifically include: the first network device receives the first path information sent by the second network device and determines the first transmission path according to the first path information; The third network device sends second path information, where the second path information is used to instruct the third network device to determine the second transmission path. Wherein, after the transmission path is established, it has a corresponding path identifier, which can be subsequently used when establishing a multicast entry on the network node.
- both the first transmission path and the second transmission path are tunnels that include the operator's multicast service interface I-PMSI.
- the DC also includes a fourth network device. Then, the first transmission path is to take the second network device as the root node, respectively to The path of the first network device and the fourth network device.
- the embodiment of the present application may further include: 3. The third route sent by the network device to the first network device; the first device identifier and the first AS number are carried in the third route; both the first route and the third route are used to indicate The first multicast source; the second step, the first network device determines the first transmission path for receiving the first multicast according to the second network device identifier and the second AS number carried by the first route Source traffic and determine the second transmission path for sending traffic of the first multicast source according to the second transmission path for receiving the third route; wherein, the first transmission path is from the A transmission path from a second network device to the first network device, where the second transmission path is a transmission path from the first network device to the third network device; in the third step, the first network device generates a A multicast entry; wherein the first multicast entry is used to instruct the first network device to receive the traffic of the first
- the path may be switched That is, to establish a third transmission path from the second network device to the first network device, the operator's multicast service S-PMSI tunnel is selected, and the corresponding multicast entry is re-established on the relevant network device.
- the embodiment of the present application further includes: the first network device receives third path information sent by the second network device and determines the third transmission path according to the third path information.
- a second multicast entry is generated on the first network device, where all The second multicast entry is used to instruct the first network device to receive the traffic of the multicast source from a third transmission path and send the traffic of the multicast source through the second transmission path, and the third transmission path It is an S-PMSI tunnel from the second network device to the first network device.
- the third transmission path is an S-PMSI tunnel.
- the DC also includes a fourth network device, then the third transmission path is from the second network The path from the device to the first network device. After the third transmission path is established, it has a path identifier different from that of the first transmission path. Therefore, the multicast table entry needs to be updated to prepare for the subsequent provision of multicast services.
- the method for implementing multicast may include: the first network device receives a fifth route sent by the third network device, wherein the first network device 5.
- the route carries a third device identifier and the AS number of the first autonomous system, wherein the third device identifier indicates a third VPN instance corresponding to the third network device and the third network device;
- a network device determines a sixth route according to the fifth route, and the sixth route is that the first network device updates the third device identifier in the fifth route to a fourth device identifier and changes all
- the first AS number in the fifth route is updated to be determined by the second AS number, wherein the fourth device identifier indicates the first network device and the fourth network device corresponding to the first network device.
- VPN instance the first network device sends the sixth route to the second network device.
- the fifth route includes the fifth virtual route forwarding route entry VRF route import extended community attribute and the fifth source autonomous system Source AS extended community attribute, and the fifth VRF route import extended community attribute includes the third device identifier ,
- the fifth Source AS extended community attribute includes the first AS number.
- the sixth route includes the sixth VRF route impot extended community attribute and the sixth Source AS extended community attribute, the sixth VRF route impot extended community attribute includes the fourth device identifier, and the sixth Source AS extended community attribute Including the second AS number.
- the sixth route is a BGP EVPN route
- the fifth route is a VPN route of BGP.
- an embodiment of the present application further includes: the first network device receives fourth path information sent by the third network device, and determines the A fourth transmission path; the first network device sends fifth path information to the second network device, where the fifth path information is used to instruct the second network device to determine the fifth transmission path.
- the fourth transmission path and the fifth transmission path are both an I-PMSI tunnel containing an operator's multicast service interface.
- an embodiment of the present application further includes: the first network device receives the seventh route sent by the second network device; and the fourth route is carried in the seventh route.
- Device identification and the second AS number; the fifth route and the seventh route are used to indicate the second multicast source; the first network device according to the third device identification carried by the fifth route And the first AS number to determine that the fourth transmission path is used to receive the traffic of the second multicast source, and the fifth transmission path is determined to be used for transmitting the traffic according to the fifth transmission path used to receive the seventh route.
- the traffic of the second multicast source wherein the fourth transmission path is a transmission path from the third network device to the first network device, and the fifth transmission path is a transmission path from the first network device
- the transmission path to the second network device the first network device generates a third multicast entry; wherein, the third multicast entry is used to instruct the first network device to transmit from the fourth
- the path receives the traffic of the second multicast source and sends the traffic of the second multicast source through the fifth transmission path;
- the first network device updates the fourth device identifier in the seventh route
- For the third device identifier carried by the fifth route and the second AS number in the seventh route is updated to the first AS number carried by the first route, and an eighth route is determined;
- the first network device sends the eighth route to the third network device.
- the seventh route and the eighth route are both edge gateway protocol BGP C-multicast routes.
- this embodiment of the present application further includes: if the multicast traffic of the second multicast source indicated by the fifth route on the first network device exceeds a traffic threshold, The first network device modifies the third multicast entry into a fourth multicast entry, and the fourth multicast entry is used to instruct the first network device to receive from the fourth transmission path
- the received traffic is sent through a sixth transmission path, where the sixth transmission path is a selected carrier multicast service S-PMSI tunnel from the first network device to the second network device.
- the sixth path information sent by the first network device to the second network device determines the sixth transmission path according to the sixth path information.
- the embodiments of the present application also provide a device for implementing multicast.
- the device is applied to the first network device in the next-generation multicast virtual private network NG MVPN, and includes: a receiving unit, a processing unit, and a sending unit .
- the receiving unit is configured to receive the first route sent by the second network device, where the first data center DC includes the first network device, and the second DC includes the first network device and the second network device ,
- the third DC includes the second network device, the first network device is an edge device that the first DC and the second DC communicate with each other, and the first route carries a second device identifier and a second An autonomous system AS number, wherein the second device identifier indicates the second network device and the first virtual private network VPN instance corresponding to the second network device, and the second AS number indicates the second DC;
- a processing unit configured to determine a second route according to the first route, where the second route is obtained by the first network device by updating the second device identifier in the first route to a first device identifier and The second AS number in the first route is updated to the first AS number determined, wherein the first device identifier indicates the first network device and the second network device corresponding to the first network device For a virtual private network VPN instance, the first AS number indicates the first DC;
- the first route includes a second virtual route forwarding route import VRF route import extended community attribute and a second source autonomous system Source AS extended community attribute
- the second VRF route import extended community attribute includes the second device identifier
- the second Source AS extended community attribute includes the second AS number.
- the second route includes the first VRF route impot extended community attribute and the first Source AS extended community attribute
- the first VRF route impot extended community attribute includes the first device identifier
- the first Source AS extended community attribute Including the first AS number.
- the first route is a virtual private network VPN route of the edge gateway protocol BGP
- the second route is an Ethernet virtual private network EVPN route of BGP.
- the second DC and the third DC belong to the same domain.
- the receiving unit in the device is further configured to receive first path information sent by the second network device and determine the first path information according to the first path information.
- Transmission path; the sending unit is further configured to send second path information to the third network device, where the second path information is used to instruct the third network device to determine the second transmission path.
- the first transmission path and the second transmission path are both an I-PMSI tunnel containing an operator's multicast service interface.
- the receiving unit in the device is further configured to receive a third route sent by the third network device; the first device is carried in the third route Identification and the first AS number; both the first route and the third route are used to indicate a first multicast source; the processing unit is further used to indicate the second route carried by the first route
- the network device identifier and the second AS number determine that the first transmission path is used to receive traffic from the first multicast source, and the second transmission path is used to determine the second transmission path according to the second transmission path used to receive the third route.
- the first transmission path is from the second A transmission path from a network device to the first network device, and the second transmission path is a transmission path from the first network device to the third network device;
- the first multicast entry is used to indicate all
- the first network device receives the traffic of the first multicast source from the first transmission path and sends the traffic of the first multicast source through the second transmission path;
- the sending unit is further configured to send the traffic to the second multicast source The network device sends the fourth route.
- the third route and the fourth route are both edge gateway protocol client multicast BGP C-multicast routes.
- the processing unit in the device is further configured to: if the first multicast source indicated by the first route is on the second network device When the traffic exceeds the traffic threshold, a second multicast entry is generated, where the second multicast entry is used to instruct the first network device to receive the traffic of the multicast source from the third transmission path and pass the second multicast entry.
- the second transmission path sends the traffic of the multicast source
- the third transmission path is a selected operator multicast service S-PMSI tunnel from the second network device to the first network device.
- the receiving unit in the apparatus is further configured to receive third path information sent by the second network device and determine the first path information according to the third path information. Three transmission paths.
- the receiving unit in the device is further configured to receive a fifth route sent by the third network device, where the fifth route carries a third device Identification and the AS number of the first autonomous system, wherein the third device identification indicates a third VPN instance corresponding to the third network device and the third network device;
- the processing unit is further configured to The fifth route determines the sixth route, and the sixth route is that the first network device updates the third device identifier in the fifth route to the fourth device identifier and changes the fifth route
- the first AS number is updated to the second AS number determined, wherein the fourth device identifier indicates the first network device and the fourth VPN instance corresponding to the first network device;
- the sending unit is further configured to send the sixth route to the second network device.
- the fifth route includes the fifth virtual route forwarding route entry VRF route import extended community attribute and the fifth source autonomous system Source AS extended community attribute, and the fifth VRF route import extended community attribute includes the third device identifier ,
- the fifth Source AS extended community attribute includes the first AS number.
- the sixth route includes the sixth VRF route impot extended community attribute and the sixth Source AS extended community attribute, the sixth VRF route impot extended community attribute includes the fourth device identifier, and the sixth Source AS extended community attribute Including the second AS number.
- the sixth route is a BGP EVPN route
- the fifth route is a VPN route of BGP.
- the receiving unit in the apparatus is further configured to receive fourth path information sent by the third network device and determine the first path information according to the fourth path information.
- the sending unit is further configured to send fifth path information to the second network device, where the fifth path information is used to instruct the second network device to determine the fifth transmission path.
- the fourth transmission path and the fifth transmission path are both an I-PMSI tunnel containing an operator's multicast service interface.
- the receiving unit in the device is further configured to receive a seventh route sent by the second network device; and the fourth device is carried in the seventh route
- the identifier and the second AS number; the fifth route and the seventh route are used to indicate a second multicast source; the processing unit is also used to indicate the third device carried by the fifth route
- the identifier and the first AS number determine that the fourth transmission path is used for receiving the traffic of the second multicast source, and the fifth transmission path is used for sending according to the fifth transmission path used for receiving the seventh route.
- the traffic of the second multicast source generate a third multicast entry; by updating the fourth device identifier in the seventh route to the third device identifier carried in the fifth route and adding The second AS number in the seventh route is updated to the first AS number carried by the first route, and the eighth route is determined; wherein, the fourth transmission path is from the third network device A transmission path to the first network device, the fifth transmission path is a transmission path from the first network device to the second network device; the third multicast entry is used to indicate the first network device A network device receives the traffic of the second multicast source from the fourth transmission path and sends the traffic of the second multicast source through the fifth transmission path; the sending unit is further configured to send the traffic to the third multicast source The network device sends the eighth route.
- the seventh route and the eighth route are both edge gateway protocol BGP C-multicast routes.
- the processing unit in the device is further configured to perform multicast if the second multicast source indicated by the fifth route is on the first network device
- the third multicast entry is modified to a fourth multicast entry
- the fourth multicast entry is used to instruct the first network device to receive the data from the fourth transmission path
- the traffic of is sent through a sixth transmission path, where the sixth transmission path is a selected carrier multicast service S-PMSI tunnel from the first network device to the second network device.
- the sending unit in the device is further configured to send sixth path information to the second network device and determine the first path information according to the sixth path information. Six transmission paths.
- the device provided in the second aspect corresponds to the method provided in the first aspect, so the implementation manners of the second aspect and the technical effects achieved can refer to the related descriptions of the implementation manners in the first aspect.
- an embodiment of the present application also provides a network device, which includes a processor and a memory, and the memory stores instructions.
- the processor executes the instructions
- the network device executes any of the foregoing first aspect.
- One way to implement the method One way to implement the method.
- the embodiments of the present application also provide a computer program product, which when running on a computer, causes the computer to execute the method described in any one of the implementation manners of the first aspect.
- the embodiments of the present application also provide a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer or processor, causes the computer or processor to execute the aforementioned first
- a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer or processor, causes the computer or processor to execute the aforementioned first
- any one of the methods described in the implementation manner any one of the methods described in the implementation manner.
- FIG. 1 is a schematic diagram of the framework of a network involved in a scenario in an embodiment of the application
- Figure 2 is a signaling flowchart of a method for implementing multicast in an embodiment of the application
- Figure 3 is a signaling flowchart of another method for implementing multicast in an embodiment of the application.
- FIG. 4 is a schematic flowchart of a method for creating a tunnel in an embodiment of this application.
- FIG. 5 is a schematic flowchart of a method for implementing multicast in an embodiment of the application
- FIG. 6 is a schematic flowchart of another method for implementing multicast in an embodiment of the application.
- FIG. 7 is a schematic flowchart of another method for implementing multicast in an embodiment of the application.
- FIG. 8 is a schematic flowchart of another method for implementing multicast in an embodiment of this application.
- FIG. 9 is a schematic structural diagram of a device for implementing multicast in an embodiment of the application.
- Fig. 10 is a schematic structural diagram of a network device in an embodiment of this application.
- Traffic may pass through multiple different DCs when it is forwarded in the network.
- traffic in one data center (English: data center, abbreviation: DC) can be sent to another DC through the backbone network of the operator.
- DC data center
- traffic inside a DC is sent by the gateway device of the DC to an operator edge (English: Provider Edge, referred to as PE) device on the operator's backbone network, and then the PE device is sent to another device on the operator's backbone network.
- PE Provider Edge
- One PE device sends it, and then the other PE device sends it to the gateway device of another DC, thereby being forwarded to the inside of another DC.
- the same network device will be used as edge devices by two adjacent DCs. That is, the edge devices of two adjacent DCs are combined into one network device.
- This network device can be called It is a joint equipment.
- a PE device on the carrier's backbone network can be combined with a DC's gateway device, that is, the DC's gateway device is used as both the gateway device of the DC and a PE on the carrier's backbone network. equipment.
- Figure 1 shows a schematic diagram of a network structure.
- the network includes three domains: DC1, operator backbone network, and DC2.
- the autonomous system (English: autonomous system, abbreviated: AS) number corresponding to the operator backbone network is 100
- the AS number corresponding to DC1 is 200
- DC2 The corresponding AS number is 300.
- DC1 and the operator's backbone network have a joint device DC-GW1
- DC2 and the operator's backbone network have a joint device DC-GW2.
- the DC-GW1 is a joint device formed by combining a PE device on the operator's backbone network with the gateway device of DC1, and at the same time as an edge device shared by the operator's backbone network and DC1; similarly,
- the DC-GW2 is a joint device formed by combining a PE device on the operator's backbone network with the gateway device of DC2, and at the same time serves as an edge device shared by the operator's backbone network and DC2.
- DC1 may include: DC-GW1, leaf node leaf1, leaf node leaf2, and backbone node spine1, where the identifier of DC-GW1 1.1.1.1, leaf1’s identity is 2.2.2.2, leaf2’s identity is 3.3.3.3, leaf1 is connected to user host-1, leaf2 is connected to server Server-2; the carrier backbone network includes: DC-GW1, DC-GW2 , Intermediate node P3 and operator edge equipment PE1, where the identifier of DC-GW2 is 4.4.4.4, and PE1 is connected to Server-1; if DC2 is also a VXLAN network, DC2 can include: DC-GW2, leaf node leaf3 , Leaf node leaf4 and backbone node spine3, where leaf3 is identified as 5.5.5.5, leaf4 is identified as 6.6.6.6, leaf4 is connected to user host-2, and leaf3 is connected to server Server-3. It
- the route publishing process includes: leaf3 in DC2 generates routing information carrying the extended community attributes corresponding to leaf3; leaf3 sends the BGP route to DC-GW2; DC-GW2 forwards the routing information directly to DC-GW1 without processing; DC-GW1 also forwards the routing information directly to leaf1 without processing.
- leaf3 in DC2 when a multicast user downstream of leaf1 wants to join the multicast source Server-3, because leaf1 belongs to DC1 and the edge devices in DC1 can only identify other edge devices in the DC, it is based on the received routing information
- the leaf3 carried in the file corresponds to the extended community attribute.
- the leaf1 cannot be traced back to DC-GW2 or leaf3 in DC2. In this way, the multicast path from the multicast source to the multicast user cannot be determined, and the multicast cannot be provided for the multicast user. service.
- the route update is performed in the co-located device across the DC.
- the leaf3 carried in the route received from the edge device leaf3 of DC2 corresponds to Replace the device ID and AS number with the device ID and AS number corresponding to the DC-GW2 respectively, and then send the updated route to the edge device DC-GW1 of the operator’s backbone network to which the DC-GW1 belongs;
- the device ID and AS number corresponding to DC-GW2 carried in the route received from the edge device DC-GW2 of the operator backbone network are replaced with the device ID and AS number corresponding to the DC-GW1.
- leaf1 in the network can trace back to leaf3 based on the received routing information, that is, the network device can determine the multicast based on the received route The multicast path from the source to the multicast user, so that the multicast source can forward the multicast traffic to the corresponding multicast user and provide multicast services for the multicast user.
- FIG. 1 is only an example of a scenario where the embodiment of the present application is applicable, and the embodiment of the present application is not limited to this scenario.
- the multicast source needs to advertise private network routes, that is, send its address to all network devices in the network, and inform each network device of the multicast source The specific location in the network, so that each network device in the network can accurately locate the multicast source; on the other hand, after the multicast source has completed the private network routing announcement, if a multicast user requests to access the multicast source, Therefore, it is necessary to establish corresponding multicast entries on the network equipment through which the transmission path of the multicast traffic passes, so that subsequent multicast source traffic can be accurately sent to the corresponding multicast users, so that the multicast source can be accurately connected.
- the incoming multicast user provides the function of multicast service.
- Step 201 Server-3 sends the address of Server-3 to leaf3.
- Step 202 Leaf3 receives and saves the Server-3 address sent by Server-3.
- Step 203 Leaf3 generates route 1 based on the address of Server-3.
- the route 1 carries the virtual route forwarding route import VRF route import extended community attribute and the autonomous system Source AS extended community attribute.
- the Internet Engineering Task Force English: Internet Engineering Task Force.
- Task Force abbreviation: IETF
- request comments English: Request For Comments, abbreviation: RFC 6513 and RFC6514, which are incorporated into this application by reference in their entirety.
- the VRF route import extended community attribute ie, the device identifier in the subsequent embodiment
- the Source AS extended community attribute that is, the AS number in the subsequent embodiment
- the above two extended community attributes can be carried in the network layer reachability information (English: network layer reachability information, abbreviated as: NLRI) field in the route.
- the VRF route import extended community attribute of route 1 includes device identifier 1, which is used to indicate the identity of leaf 3 and the VPN instance corresponding to leaf 3; the source AS extended community attribute of route 1 includes the AS number.
- the device ID 1 can be 5.5.5.5:123, where 5.5.5.5 is the ID of the leaf3, 123 is the ID of the VPN instance configured for the Server-3, and the AS number can be 300, 300 are the AS numbers corresponding to the AS domain to which leaf3 belongs.
- Step 204 leaf3 sends the route 1 to DC-GW2 through DC2.
- Step 205 DC-GW2 receives and saves the route 1 sent by leaf3.
- Step 206 DC-GW2 determines route 2 according to route 1.
- DC-GW2 can specifically update the VRF route import extended community attribute and Source AS extended community attribute in route 1 to obtain route 2.
- the update process includes: replacing device ID 1 with device ID 2, instead It is the AS number. Specifically, on the one hand, replace the leaf3 identifier 5.5.5.5 in the device identifier 1 with the DC-GW2 identifier 4.4.4.4 in the device identifier 2, and replace the VPN instance 123 corresponding to leaf3 in the device identifier 1 with the device identifier 2.
- DC-GW2 is the VPN instance identifier 234 configured for the Server-3; on the other hand, the AS number 300 is replaced with the AS number 100 corresponding to another AS domain to which the DC-GW2 belongs.
- Step 207 DC-GW2 sends the route 2 to DC-GW1 through the operator backbone network.
- Step 208 DC-GW1 receives and saves the route 2 sent by DC-GW2.
- Step 209 DC-GW2 determines route 3 according to route 2.
- the DC-GW1 can specifically update the VRF route import extended community attribute and Source AS extended community attribute in the route 2 to obtain route 3.
- the update process includes: replacing the device identifier 2 with the device identifier 3. Replaced with AS number. Specifically, on the one hand, replace the identifier 4.4.4.4 of DC-GW2 in device identifier 2 with the identifier 1.1.1.1 of DC-GW1 in device identifier 3, and replace the VPN instance 234 corresponding to DC-GW2 in device identifier 2 with In the device identifier 2, DC-GW1 is the VPN instance identifier 567 configured for the Server-3; on the other hand, the AS number 100 is replaced with the AS number 200 corresponding to another AS domain to which the DC-GW1 belongs.
- Step 210 DC-GW1 sends the route 3 to leaf1 through DC1.
- Step 211 Leaf1 receives and saves the route 3 sent by DC-GW1.
- route 1 is the route saved by the multicast source Server-3 on DC-GW2
- route 2 is the route saved by the multicast source Server-3 on DC-GW1
- route 3 is the multicast source Server-3 on leaf1 Saved routes.
- Route 1 to route 3 can all indicate the multicast source Server-3.
- routes 1 to 3 can be routes of various VPN protocols applicable to BGP of the corresponding domain, and the three routes can be the same or different.
- Route 1 and Route 3 can be BGP EVPN routes, specifically BGP EVPN protocol IP prefix routes (also known as Type5 routes) or MAC/IP advertised routes (also known as Type2 routes), and route 2 can be BGP
- the VPN protocol is specifically the VPNv4 route of the BGP protocol; another example: Route 1 to Route 3 may all be the VPN protocol of BGP; Another example: Route 1 to Route 3 may also be the EVPN protocol of BGP.
- the detailed description of the IP prefix routing (also called Type 5 routing) or MAC/IP advertisement routing of the BGP EVPN protocol can be found in the description of RFC7432, which is incorporated into this application by reference in its entirety.
- the multicast source upstream of leaf3 completes route advertisement, that is, after routing updates are performed on the co-located devices DC-GW1 and DC-GW2, the updated routes are advertised downstream.
- each network device in the network can trace the received route to the upstream network device, that is, the multicast source to the multicast user can be determined
- the multicast path makes it possible for the traffic of the multicast source to perform accurate cross-DC multicast in this NG MVPN.
- the following uses the network shown in FIG. 1 as a scenario, in conjunction with the drawings, to describe the process of a multicast user requesting access to a multicast source and each network device establishing a multicast entry.
- the item process can refer to the flowchart shown in Figure 3.
- the process may specifically include the following steps 301 to 313:
- Step 301 host-1 sends a join request message to leaf1.
- join request message carries the address of the multicast source, for example, the address of Server-3, which is used to indicate the multicast source Server-3.
- Step 302 According to the address of the multicast source, leaf1 finds the route 3 corresponding to the multicast source stored on the leaf1.
- step 303 leaf1 determines according to the route 3 that it should request the DC-GW1 to join the multicast member host-1, and establishes the multicast entry 1.
- the leaf1 can determine to receive multicast traffic through the tunnel from DC-GW1 to leaf1 according to route 3, and it can also determine to send multicast traffic through the path between leaf1 and host-1; thus, the leaf1 according to the route 3 Multicast entry 1 can be established.
- the multicast entry includes at least: the multicast source Server-3 address, the multicast user host-1 address, the upstream interface and the downstream interface.
- the upstream interface identifiers in the multicast entry 1 are specifically: DC-GW1 to leaf1
- the identifier of the tunnel, the downstream interface identifier is specifically: the identifier of the interface connecting host-1 on leaf1.
- Step 304 Leaf1 sends BGP C-multicast route 1 to DC-GW1.
- BGP C-multicast route 1 can carry the address of the multicast source and the address of the multicast member, for example, the address of Server-3 and the address of host-1, which are used to request to join the multicast member host- 1 to Server-3, and trigger DC-GW1 to establish a corresponding multicast entry 2.
- the BGP C-multicast route 1 carries the device identifier 3 and the AS number, where the device identifier 3 includes the identifier of DC-GW1, DC-GW1 is the VPN instance identifier configured by Server-3, and the AS number is 200.
- the description of BGP C-multicast routing please refer to the description of RFC6513, which is incorporated into this application by reference in its entirety.
- the BGP C-multicast route 1 may specifically be sent by a network device to neighboring devices of the network device in the form of broadcast, where the BGP C-multicast route 1 at least carries the address of the multicast source, Device ID 3 and AS number, then, after receiving the BGP C-multicast route 1, each neighboring device checks whether the device ID 3 carried in the BGP C-multicast route 1 matches its own. If so, the neighboring device BGP C-multicast route 1 is processed; if it does not match, the BGP C-multicast route 1 is discarded without processing.
- leaf1 sends BGP C-multicast route 1 to DC-GW1, which may specifically include: the leaf1 broadcasts BGP C-multicast route 1 to neighboring devices such as DC-GW1 and leaf2.
- the BGP C-multicast route 1 carries DC- GW1 identification, then, among the network devices that receive the BGP C-multicast route 1, only DC-GW1 processes the BGP C-multicast route 1, that is, DC-GW1 establishes multicast entry 2 and sends it to DC -GW2 sends BGP C-multicast route 2.
- Step 305 According to the received address of the multicast source in the BGP C-multicast route 1, the DC-GW1 finds the route 2 corresponding to the multicast source stored on the DC-GW1.
- step 306 the DC-GW1 determines according to the route 2 that it should request the DC-GW2 to join the multicast member host-1, and establishes the multicast entry 2.
- the DC-GW1 can determine to receive multicast traffic through the tunnel from DC-GW2 to DC-GW1 according to route 2, and it can also determine to send multicast traffic through the tunnel from DC-GW1 to leaf1; thus, the DC -GW1 can establish multicast entry 2 according to route 2.
- the identifier of the upstream interface in the multicast entry 2 is specifically: the identifier of the tunnel from DC-GW2 to DC-GW1, and the identifier of the downstream interface is specifically: the identifier of the tunnel from DC-GW1 to leaf1.
- Step 307 The BGP C-multicast route 2 sent by DC-GW1 to DC-GW2.
- step 308 the DC-GW2 finds the route 1 corresponding to the multicast source stored on the DC-GW2 according to the address of the multicast source in the received BGP C-multicast route 2.
- step 309 the DC-GW2 determines according to the route 1 that it should request the leaf3 to join the multicast member host-1, and establishes the multicast entry 3.
- the BGP C-multicast route 2 at least carries the address of the multicast source, the device ID 2 and the AS number.
- the DC-GW1 sends BGP C-multicast route 2 to DC-GW2, which may specifically include: the DC-GW1 broadcasts BGP C-multicast route 2 to neighboring devices such as DC-GW2, PE1, etc., the BGP C-multicast route 2 Carries the identifier of DC-GW2, then, among the network devices that receive the BGP C-multicast route 2, only DC-GW2 processes the BGP C-multicast route 2, that is, DC-GW2 establishes multicast entry 3 , And send BGP C-multicast route 3 to leaf3.
- the DC-GW2 can determine to receive multicast traffic through the tunnel from leaf3 to DC-GW2 according to route 1, and can also determine to send multicast traffic through the tunnel from DC-GW2 to DC-GW1; thus, the DC -GW2 can establish multicast entry 3 according to route 1.
- the identifier of the upstream interface in the multicast entry 3 is specifically: the identifier of the tunnel from leaf3 to DC-GW2, and the identifier of the downstream interface is specifically: the identifier of the tunnel from DC-GW2 to DC-GW1.
- Step 310 DC-GW2 sends BGP C-multicast route 3 to leaf3.
- leaf3 finds the multicast source address corresponding to the multicast source stored on leaf3 according to the address of the multicast source in the received BGP C-multicast route 3.
- leaf3 determines according to the multicast source address that it should request Server-3 to join the multicast member host-1, and establishes multicast entry 4.
- the BGP C-multicast route 3 at least carries the address of the multicast source, the device identifier 1, and the AS number.
- the DC-GW2 sends BGP C-multicast route 3 to leaf3, which may specifically include: the DC-GW2 broadcasts BGP C-multicast route 3 to neighboring devices such as leaf3 and leaf4.
- the BGP C-multicast route 3 carries leaf3 ID, then, among the network devices that received the BGP C-multicast route 3, only leaf 3 processes the BGP C-multicast route 3. That is, leaf 3 creates multicast entry 4 and sends a join request message to Server-3 .
- the leaf3 can determine to receive multicast traffic through the path between Server-3 and leaf3, and it can also determine to send multicast traffic through the tunnel from leaf3 to DC-GW1; thus, the leaf3 can also establish multicast Table item 4.
- the identifier of the upstream interface in multicast entry 4 is specifically: the identifier of the interface connected to Server-3 on leaf3, and the identifier of the downstream interface in multicast entry 1 is specifically: the identifier of the tunnel from leaf3 to DC-GW2 .
- step 313 leaf3 sends a join request message to Server-3.
- join request message carries the address of the multicast user requesting to join, for example, the address of host-1, which is used to indicate that the multicast user host-1 requests to join the multicast source Server-3.
- the multicast user host-1 joins Server-3 and becomes the object of the multicast service provided by Server-3. Moreover, at each edge of the multicast path from the multicast source Server-3 to the multicast user host-1 A corresponding multicast entry is established on the device to ensure that the multicast traffic provided by the multicast source Server-3 can be accurately received by the multicast user host-1.
- the above method provided by the embodiment of the present application updates routing information when advertising routes, and establishes multicast entries based on the updated routing information to ensure that multicast traffic sent from a multicast source can be accurately forwarded to those who have joined The multicast users of the multicast source, thereby ensuring that multicast services can be provided for the multicast users.
- the network shown in Figure 1 from DC-GW2 to DC-GW1 may include the operator multicast service interface (English: Inclusive-Provider Multicast Service Interface, abbreviated as: The I-PMSI) tunnel establishment process is described as an example.
- the I-PMSI Inclusive-Provider Multicast Service Interface
- Step 401 DC-GW2 sends to DC-GW1 and PE1 respectively to automatically discover intra-as i-pmsi a-d routes in the AS domain including the operator's multicast service interface.
- step 401 is specifically: DC-GW2 sends DC-GW2 to the other two edge devices DC-GW1 and DC-GW1 in the domain.
- PE1 sends intra-as i-pmsi ad routing.
- the intra-as i-pmsi a-d route includes path information of the tunnel to be established, and the path information of the tunnel to be established includes the identifier of the DC-GW2 and the identifier of the tunnel to be established.
- the domain to which the tunnel to be established belongs can be identified.
- the intra-as i-pmsi ad route carries different The path information, in this way, can establish corresponding tunnels applicable to the domain in different domains.
- the intra-as i-pmsiad route carries the path information of the tunnel in the operator’s backbone network. If the route from leaf3 to DC-GW2 is established, the intra-as i-pmsi ad route carries the path information of the tunnel in DC2, so that different types of tunnels can be established in different domains.
- Step 402 DC-GW1 and PE1 respectively send intra-as i-pmsi a-d routes to DC-GW2.
- the intra-as i-pmsi a-d route does not include the identifier of the tunnel to be established.
- the label distribution protocol (English: Label Distribution Protocol, referred to as: LDP) is used to establish the tunnel, then after step 402, the establishment of the tunnel can be completed through the following step 403a; if the traffic engineering (English: traffic engineering, referred to as : TE) to establish a tunnel, then, after step 402, the establishment of the tunnel can also be completed through the following steps 403b to 404b:
- Step 403a DC-GW1 and PE1 respectively send Mapping messages to DC-GW2 along the transmission path, and establish a tunnel with DC-GW2 as the root node.
- the DC-GW2 since the Mapping message is used to assign labels to each node of the tunnel, and records the labels in turn, as the Mapping message jumps to DC-GW2, the DC-GW2 has DC-GW2.
- the label stacks of the tunnels from GW2 to DC-GW1 and from DC-GW2 to PE1 are used for forwarding multicast traffic in the two tunnels.
- Step 403b DC-GW2 sends Path messages to DC-GW1 and PE1 respectively.
- DC-GW1 and PE1 respectively send Resv messages to DC-GW2.
- Path message and the Resv message are used to establish tunnels for DC-GW2 to DC-GW1 and DC-GW2 to PE1.
- the tunnel identifier of the tunnel from DC-GW2 to DC-GW1 and the identifier of the tunnel from DC-GW2 to PE1 are the same, and the tunnel identifier can be used as the upstream interface of the multicast entry 2 in the corresponding embodiment in FIG. 3 ID or the ID of the downstream interface of multicast entry 3.
- the type of tunnel to be established can be determined according to needs and specific network supported protocols.
- the tunnel from leaf3 to DC-GW2 and the tunnel from DC-GW1 to leaf1 can all be virtual extended local area networks (English: Virtual eXtensible LAN (abbreviation: VXLAN) protocol protocol independent multicast-sparse mode (English: Protocol Independent Multicast-Sparse Mode, abbreviation: PIM-SM) tunnel
- the tunnel from DC-GW2 to DC-GW1 can be LDP multipoint extension ( English: multipoint extensions for LDP abbreviation: mLDP) point-to-multipoint (English: Point 2 Multiple Point, abbreviation: P2MP) tunnel.
- VXLAN Virtual eXtensible LAN
- PIM-SM Protocol Independent Multicast-Sparse Mode
- FIG. 4 may be executed before the embodiment shown in FIG. 2, or may be executed simultaneously with the embodiment shown in FIG. 2, which is not specifically limited here.
- the tunnel established in the manner shown in FIG. 4 is an I-PMSI tunnel, that is, a tunnel is established with one edge device as the root node to all other edge devices in the domain. Then, the multicast traffic is multicast in the I-PMSI tunnel.
- the edge device When passing through an edge device, the edge device will use the edge device as the tunnel identifier indicated by the downstream interface in the multicast entry established on it.
- the root node is sent to all edge devices (also denoted as leaf nodes) in the domain except the root node. Among all edge devices except the root node, some edge devices do not have access to multicast users downstream, and will directly discard the received multicast traffic. Only the edge devices that can reach the multicast users will receive the multicast traffic.
- the multicast traffic continues to be forwarded. For example: when the multicast traffic from the multicast source Server-3 reaches DC-GW2, DC-GW2 will send the multicast traffic to DC-GW1 and PE1, and DC-GW1 will forward the multicast traffic to the multicast user host- 1. PE1 directly discards the multicast traffic. In this way, it may cause a waste of network resources in the network.
- the embodiments of the present application further include: for the edge device (especially the edge device between the DC and the operator's backbone network, for example: DC-GW2), the establishment type is selected operator multicast service interface (English: Selective-Provider Multicast Service Interface (abbreviation: S-PMSI) tunnel, and generate the multicast entry corresponding to the S-PMSI tunnel on the relevant edge device.
- S-PMSI tunnel refers to a tunnel from the root node to the leaf node that only the other edge devices in the domain except the root node, and the downstream edge devices that have joined the multicast user as the leaf nodes.
- the tunnel used in the operator’s backbone network is an I-PMSI tunnel, that is, when the multicast traffic sent by Server-3 passes through DC-GW2, according to DC- For multicast entry 3 generated on GW2, the multicast traffic is forwarded to DC-GW1 and PE1 at the same time.
- the embodiment of this application also provides a method for switching tunnels, which can be specifically: The I-PMSI tunnel is switched to the S-PMSI tunnel.
- the process of switching tunnels may specifically include: the first step is to establish an S-PMSI tunnel; and the second step is to update the multicast entry on the corresponding edge device.
- the DC-GW2 establishes an S-PMSI tunnel to DC-GW1.
- the specific process may include: S11, DC-GW2 sends an intra-as s-pmsi ad route to DC-GW1.
- the intra-as-pmsi ad route includes: path information of the tunnel to be established, and the path information includes the identifier of the tunnel to be established; S12, DC- GW1 sends an intra-as s-pmsi ad route to DC-GW2, and the intra-as s-pmsi ad route does not include the identifier of the tunnel to be established; S13a, DC-GW1 sends a Mapping message to DC-GW2 along the transmission path to establish With a tunnel from DC-GW2 to DC-GW1; or, in S13b, DC-GW2 sends a Path message to DC-GW1, and S14b, DC-GW1 sends a Resv message to DC-GW2.
- S12, DC- GW1 sends an intra-as s-pmsi ad route to DC-GW2, and the intra-as s-pmsi ad route does not include the identifier of the tunnel to be established; S13a, DC-GW1
- the identifier of the above-mentioned DC-GW2 to DC-GW1 tunnel is the same as Figure 4 corresponds to the embodiment in which the tunnel identifiers of the I-PMSI tunnel from DC-GW2 to DC-GW1 are inconsistent, so network resources are saved during the multicast process.
- the embodiment of this application can also change the I- in the related multicast table.
- the tunnel identifier of the PMSL tunnel is replaced with the tunnel identifier of the corresponding S-PMSI tunnel. That is, for the second step, take the network corresponding to FIG.
- the identifier of the upstream interface of multicast entry 2 and the identifier of the downstream interface of multicast entry 3 can be DC-
- the tunnel identifier of the I-PMSI tunnel from GW2 to DC-GW1 is updated and replaced with the tunnel identifier of the S-PMSI tunnel from DC-GW2 to DC-GW1.
- the multicast traffic of the multicast source Server-3 reaches DC-GW2
- DC-GW2 only sends the multicast traffic to DC-GW1
- DC-GW1 forwards the multicast traffic to the multicast user host-1, and does not send the multicast traffic to the multicast user hoat which is impossible to reach -1 PE1.
- network resources can be saved.
- Fig. 5 is a schematic flowchart of a method for implementing multicast in an embodiment of the application. Referring to FIG. 5, the method may specifically include the following steps 501 to 503:
- Step 501 The first network device receives the first route sent by the second network device, where the first DC includes the first network device, the second DC includes the first network device and the second network device, and the third DC includes the second network device.
- a network device, the first network device is an edge device that the first DC and the second DC communicate with each other, the first route carries the second device identifier and the second autonomous system AS number, where the second device identifier indicates the second network
- the first VPN instance corresponding to the device and the second network device, and the second AS number indicates the second DC.
- the first route may include the second virtual route forwarding route import VRF route import extended community attribute and the second source autonomous system Source AS extended community attribute.
- the second VRF route import extended community attribute includes the second device identifier
- the second Source AS extended community attribute includes the second AS number.
- the second DC and the third DC may belong to the same domain.
- the first network device may correspond to DC-GW2, then the second network device is leaf3, and the third network device may be PE1 or DC -GW1.
- the first DC corresponds to the carrier’s backbone network and can belong to the AS domain corresponding to AS number 100; the second DC corresponds to DC2 and can belong to the AS domain with AS number 300; the third DC can belong to the same AS domain as the second DC
- the AS domain with the AS number of 300 may alternatively correspond to an AS domain different from the second DC.
- the second device identifier is carried in the second VRF route import extended community attribute, specifically 5.5.5.5:123, and the second AS number is carried in the second Source AS extended community attribute, which can be 300, of which the value in 5.5.5.5:123 5.5.5.5 is the identifier of the second network device leaf3, used to indicate the leaf3; 123 is an example of the first VPN corresponding to the second network device leaf3.
- the first network device can correspond to DC-GW1, then the second network device is DC-GW2 or PE1, and the third network device It can be leaf1 or leaf2.
- the first DC corresponds to DC1 and can belong to the AS domain corresponding to the AS number of 200;
- the second DC corresponds to the operator backbone network and can belong to the AS domain with the AS number of 100;
- the third DC can belong to the same AS domain as the second DC
- the AS domain with the AS number of 100, or the third DC can also correspond to DC2, belonging to the AS domain with the AS number of 300.
- the second device identifier is carried in the second VRF route import extended community attribute, which can be specifically 4.4.4.4:234, and the second AS number is carried in the second Source AS extended community attribute. It can be 100, where 4.4.4.4 in 4.4.4.4:234 is the identifier of the second network device DC-GW2, used to indicate the DC-GW2; 234 is the first VPN example corresponding to the second network device DC-GW2.
- step 501 may refer to the related description of step 205 or step 208 in the embodiment corresponding to FIG. 2.
- Step 502 The first network device determines a second route according to the first route.
- the second route is the first network device by updating the second device identifier in the first route to the first device identifier and adding The second AS number of is updated to the first AS number determined, the first device identifier indicates the first network device and the second VPN instance corresponding to the first network device, and the first AS number indicates the first DC.
- the second route includes the first VRF route impot extended community attribute and the first Source AS extended community attribute
- the first VRF route impot extended community attribute includes the first device identifier
- the first Source AS extended community attribute Including the first AS number
- the first route may be a BGP VPN route
- the second route may be a BGP EVPN route.
- the second route may be an IP prefix route of the BGP EVPN protocol or a MAC/IP advertisement route
- the first route may be a VPNv4 route of the BGP protocol.
- the first network device corresponds to DC-GW2, then the second network device is leaf3, and the third network device may be PE1 or DC-GW1.
- the first DC corresponds to the operator's backbone network, and can belong to the AS domain corresponding to the AS number of 100.
- the first device identifier is carried in the first VRF route import extended community attribute, which can be 4.4.4.4:234.
- the AS number is carried in the first Source AS extended community attribute, which can be 100, where 4.4.4.4 in 4.4.4.4:234 is the identifier of the first network device DC-GW2, used to indicate the DC-GW2; 234 is the second An example of the second VPN corresponding to the network device DC-GW2.
- the first network device corresponds to DC-GW1
- the second network device is DC-GW2 or PE1
- the third network device may be leaf1 or leaf2.
- the first DC corresponds to DC1 and can belong to the AS domain corresponding to the AS number of 200.
- the first device identifier can be 1.1.1.1:567
- the first AS number can be 200, where the value in 1.1.1.1:567 1.1.1.1 is the identifier of the first network device DC-GW1, used to indicate the DC-GW1; 567 is an example of the second VPN corresponding to the first network device DC-GW1.
- step 502 can refer to the related description of step 206 or step 209 in the embodiment corresponding to FIG. 2.
- Step 503 The first network device sends a second route to a third network device, and the third network device belongs to the first DC.
- the first network device corresponds to DC-GW2
- the second network device is leaf3, and the third network device can be PE1 or DC-GW1.
- the DC corresponds to the operator's backbone network and can belong to the AS domain corresponding to the AS number 100.
- DC-GW2 sends to PE1 or DC-GW1 a second route including: the first device identifier 4.4.4.4:234 and the first AS number 100.
- the first network device corresponds to DC-GW1
- the second network device is DC-GW2 or PE1
- the third network device can be leaf1 or leaf2
- the first DC corresponds to DC1 and may belong to the AS domain corresponding to the AS number 200.
- DC-GW1 sends to leaf1 or leaf2 the second route including the first device identifier 1.1.1.1:567 and the first AS number 200.
- step 503 can refer to the related description of step 207 or step 210 in the corresponding embodiment of FIG. 2.
- the process of establishing tunnels in each domain may also be included: S21, the first network The device receives the first path information sent by the second network device and determines the first transmission path according to the first path information; S22, the first network device sends second path information to the third network device, and the second path information is used to indicate The third network device determines the second transmission path.
- the first transmission path is the tunnel from the second network device to the first network device established according to the first path information; the second transmission path is the first network device to the third network device established according to the second path information Tunnel.
- the two tunnels may be I-PMSI tunnels.
- the first transmission path may refer to the tunnel from leaf3 to DC-GW2, and the second transmission path may refer to DC -Tunnel from GW2 to DC-GW1.
- the first transmission path may be a PIM-SM tunnel of the VXLAN protocol
- the second transmission path may be a P2MP tunnel of mLDP.
- the first transmission path may refer to the tunnel from DC-GW2 to DC-GW1, and the second transmission path may be Refers to the tunnel from DC-GW1 to leaf1.
- the first transmission path may be a P2MP tunnel of mLDP, and the second transmission path may be a PIM-SM tunnel of the VXLAN protocol.
- the multicast source upstream of the second network device completes routing announcement. If a multicast user downstream of the third network device joins the multicast source, the third network in the network The device can trace back to the first network device according to the received second route. Similarly, the first network device can also trace back to the second network device according to the received first route.
- the multicast path from the source to the multicast user makes it possible for the traffic of the multicast source to perform accurate cross-DC multicast in the NG MVPN, that is, the multicast user and the multicast source are not in the same DC and the multicast process is realized Provide multicast services for multicast users in the case of a joint device of two DCs.
- FIG. 6 is a schematic flowchart of another method for implementing multicast according to an embodiment of the application.
- the method not only includes the process of publishing the private network route corresponding to FIG. 5, but also includes the process of requesting a multicast user to access the multicast source and each network device establishing a multicast entry.
- the method further includes the following steps 601 to 605:
- Step 601 The first network device receives the third route sent by the third network device; the third route carries the first device identifier and the first AS number; both the first route and the third route are used to indicate the first multicast source.
- the third route may be a BGP C-multicast route.
- the third network device may be DC-GW1.
- the third route may include: the first device identifier 4.4.4.4:234 and the first AS number 100.
- the third network device may be leaf1.
- the third route may include: the first device identifier 1.1.1.1:567 and the first AS number 200.
- step 601 refers to the related description of step 304 or step 307 in the corresponding embodiment of FIG. 2 above.
- Step 602 The first network device determines, according to the second network device identifier and the second AS number carried by the first route, that the first transmission path is used to receive traffic from the first multicast source; and according to the first transmission path used to receive the third route Second transmission path, determining that the second transmission path is used to send traffic of the first multicast source; wherein, the first transmission path is a transmission path from the second network device to the first network device, and the second transmission path is from the first network device A transmission path from a network device to a third network device.
- Step 603 The first network device generates a first multicast entry; wherein, the first multicast entry is used to instruct the first network device to receive the traffic of the first multicast source from the first transmission path and pass the second The transmission path sends the traffic of the first multicast source.
- both the first transmission path and the second transmission path may be I-PMSI tunnels.
- the first network device corresponds to DC-GW2
- the second network device is leaf3, and the third network device can be DC-GW1, and Server-3 corresponds to The first multicast source.
- the DC-GW2 can determine that the first transmission path is a tunnel from leaf3 to DC-GW2 according to the second device identifier 5.5.5.5:123 and the second AS number 300 carried by the first route, and the tunnel is used for Receive the multicast traffic sent by Server-3; moreover, the DC-GW2 can also determine the second transmission path as the DC-GW2 to DC-GW1 based on the tunnel from DC-GW2 to DC-GW1 used by the third route Tunnel, which is used to send multicast traffic sent by Server-3.
- DC-GW2 may also establish a first multicast entry, including the identifier of the upstream interface: the identifier of the tunnel from leaf3 to DC-GW2, and the identifier of the downstream interface: the identifier of the tunnel from DC-GW2 to DC-GW1.
- the first network device corresponds to DC-GW1
- the second network device is DC-GW2 or PE1
- the third network device can be leaf1
- Server- 3 corresponds to the first multicast source.
- the DC-GW1 can determine that the first transmission path is the tunnel from DC-GW2 to DC-GW1 according to the second device identifier 4.4.4.4:234 and the second AS number 100 carried by the first route.
- the DC-GW1 may also determine the second transmission path as the tunnel from DC-GW1 to leaf1 according to the tunnel from DC-GW1 to leaf1 used to receive the third route, This tunnel is used to send multicast traffic sent by Server-3.
- DC-GW1 may also establish a first multicast entry, including the identifier of the upstream interface: the identifier of the tunnel from DC-GW2 to DC-GW1, and the identifier of the downstream interface: the tunnel from DC-GW1 to leaf1.
- step 602 to step 603 refer to the related description of step 305 to step 306 or step 308 to step 309 in the embodiment corresponding to FIG. 2 above.
- Step 604 The first network device updates the first device identifier in the third route to the second device identifier carried in the first route and updates the first AS number in the third route to the second AS carried in the first route. No., determine the fourth route.
- Step 605 The first network device sends the fourth route to the second network device.
- the fourth route may be a BGP C-multicast route.
- the first network device can update the first device identifier and the first AS number carried in the third route to obtain the fourth route, specifically update the first device identifier to the second device identifier, and change the first device identifier to the second device identifier.
- the AS number is updated to the second AS number, that is, the fourth route includes the second device identifier, the second AS number, and other information other than the two parts in the third route.
- the first network device corresponds to DC-GW2
- the second network device is leaf3
- the third network device may be DC-GW1.
- the fourth route may include: the second device identifier 5.5.5.5:123 and the second AS number 300, and DC-GW2 sends the fourth route to leaf3 to inform leaf3 that a multicast user requests to join the group Broadcast the source and trigger leaf3 to establish the corresponding multicast entry.
- the fourth route may include: the second device identifier 4.4.4.4:234 and the second AS number 100, and DC-GW1 sends the fourth route to DC-GW2 to inform DC-GW2 that there is multicast
- the user requests to join the multicast source and triggers DC-GW2 to establish a corresponding multicast entry.
- step 604 to step 605 refer to the related description of step 307 or step 310 in the embodiment corresponding to FIG. 2 above.
- the first transmission path and the second transmission path are usually I-PMSI tunnels, that is, in a domain.
- a tunnel with a joint device as the root node and all other edge devices in the domain as leaf nodes is established.
- the tunnel corresponds to a tunnel identifier.
- the co-located device is used as the ingress node of the tunnel and forwarded from each edge device. Only the egress node of the tunnel that accesses the multicast user downstream receives it. The multicast traffic is forwarded, and the multicast traffic received by other edge devices is discarded, resulting in a waste of network resources.
- the embodiment of the present application may also establish an S- from the second network device to the first network device. PMSI tunnel, and generate a second multicast entry on the first network device based on the newly established S-PMSI tunnel.
- the establishment of an S-PMSI tunnel from the second network device to the first network device may specifically include: S31.
- the first network device receives the third path information sent by the second network device, and according to the third path information Determine the third transmission path.
- the third transmission path is a tunnel from the second network device to the first network device established according to the third path information, and the tunnel is an S-PMSI tunnel.
- the third transmission path may refer to the tunnel from leaf3 to DC-GW2, and the second transmission path may refer to DC -Tunnel from GW2 to DC-GW1.
- the third transmission path may be a PIM-SM tunnel of the VXLAN protocol
- the second transmission path may be a P2MP tunnel of mLDP.
- the third transmission path may refer to the tunnel from DC-GW2 to DC-GW1, and the second transmission path may be Refers to the tunnel from DC-GW1 to leaf1.
- the third transmission path may be a P2MP tunnel of mLDP, and the second transmission path may be a PIM-SM tunnel of the VXLAN protocol.
- S31 can refer to the above-mentioned S11, S12, and S13a, or the related description of S11, S12, S13b, and S14b, or refer to the related description of the corresponding embodiment in FIG. 4.
- the establishment of the S-PMSI tunnel from the second network device to the first network device will only establish the tunnel from the second network device to the first network device, not including the second network device to other network devices. Tunnels of each edge device.
- generating a second multicast entry on the first network device based on the newly established S-PMSI tunnel may specifically include: the first network device generates a second multicast entry, where the second multicast entry The entry is used to instruct the first network device to receive the multicast source traffic from the third transmission path and send the multicast source traffic through the second transmission path.
- the third transmission path is from the second network device to the first network device S-PMSI tunnel.
- the third transmission path and the first transmission path are two different tunnels, the third transmission path and the first transmission path correspond to the identifiers of different tunnels. Then, when the multicast traffic of the first multicast source on the second network device indicated by the first route exceeds the traffic threshold, and the third transmission path is established, the first network device may be based on the distance from the second network device to the second network device. A change in the transmission path of a network device generates a second multicast entry.
- the above method updates routing information when advertising routes, and establishes multicast entries based on the updated routing information to ensure that multicast traffic sent from a multicast source can be accurately forwarded to those who have joined The multicast users of the multicast source, thereby ensuring that multicast services can be provided for the multicast users.
- it provides an implementation method for tunnel switching in the multicast process, switching the I-PMSI tunnel in the domain to the S-PMSI tunnel, saving network resources.
- the foregoing embodiments all specifically introduce the method for implementing multicast provided by the embodiments of the present application based on the network of the multicast source ⁇ the second network device ⁇ the first network device ⁇ the third network device ⁇ the multicast user.
- the third network device side ie, the first DC
- the second network device side ie, the third DC
- the second network device ⁇ the first network device ⁇ the third network device ⁇ the multicast source.
- the method may specifically include:
- Step 701 The first network device receives the fifth route sent by the third network device, where the fifth route carries the third device identifier and the first AS number, wherein the third device identifier indicates that the third network device and the Third, the third VPN instance corresponding to the network device.
- the fifth route includes the fifth VRF route import extended community attribute and the fifth Source AS extended community attribute.
- the fifth VRF route import extended community attribute includes the third device identifier
- the fifth Source AS extended community attribute includes the first AS number. .
- step 701 may be that the first network device DC-GW2 receives the third network
- the fifth route sent by the device leaf3 the fifth route includes: the third device identifier 5.5.5.5:123 and the first AS number 300; or, in step 701, the first network device DC-GW1 may also receive the third network device
- step 701 may be that the first network device DC-GW1 receives the fifth route sent by the third network device leaf2; or In this step 701, the first network device DC-GW2 may also receive the fifth route sent by the third network device DC-GW1.
- step 701 refers to the related description of step 205 or step 208 in the corresponding embodiment of FIG. 2 above.
- Step 702 The first network device determines a sixth route according to the fifth route.
- the sixth route is the first network device by updating the third device identifier in the fifth route to the fourth device identifier and changing the fifth route in the fifth route.
- the first AS number is updated to be determined by the second AS number, where the fourth device identifier indicates the first network device and the fourth VPN instance corresponding to the first network device.
- the sixth route includes the sixth VRF route impot extended community attribute and the sixth Source AS extended community attribute.
- the sixth VRF route impot extended community attribute includes the fourth device identifier
- the sixth Source AS extended community attribute includes the second AS number. .
- the fifth route may be a BGP VPN route
- the sixth route may be a BGP EVPN route.
- the sixth route may be an IP prefix route or a MAC/IP advertisement route of the BGP EVPN protocol
- the fifth route may be a VPNv4 route of the BGP protocol.
- step 702 may be that the first network device DC-GW2 sends the fifth The third device identifier 5.5.5.5:123 in the route is updated to the fourth device identifier 4.4.4.4:234, and the first AS number 300 is updated to the second AS number 100 to obtain the sixth route; or, step 702 can also be It is the first network device DC-GW1 that updates the third device identification 4.4.4.4:234 in the fifth route to the fourth device identification 1.1.1.1:567, and updates the first AS number 100 to the second AS number 200, Get the sixth route.
- step 702 may be that the first network device DC-GW1 determines the sixth route according to the fifth route; or, this step 702 may also be that the first network device DC-GW2 determines the sixth route according to the fifth route.
- step 702 refers to the related description of step 206 or step 209 in the embodiment corresponding to FIG. 2 above.
- Step 703 The first network device sends the sixth route to the second network device.
- step 703 may be that the first network device DC-GW2 will include the fourth The device identifier 4.4.4.4: 234 and the sixth route of the second AS number 100 are sent to the second network device DC-GW1; or, in this step 703, the first network device DC-GW1 may include the fourth device identifier 1.1. 1.1: 567 and the sixth route of the second AS number 200 are sent to the second network device leaf1.
- step 703 may be that the first network device DC-GW1 sends the sixth route to the second network device DC-GW2 Or, in step 703, the first network device DC-GW2 may send the sixth route to the second network device leaf4.
- step 703 can refer to the related description of step 207 or step 210 in the embodiment corresponding to FIG. 2.
- the process of establishing tunnels in each domain may also be included during or before performing the above steps 701 to 703: S41, the first network The device receives the fourth path information sent by the third network device and determines the fourth transmission path according to the fourth path information; S42, the first network device sends fifth path information to the second network device, and the fifth path information is used to indicate the first The second network device determines the fifth transmission path.
- the fourth transmission path is the tunnel from the third network device to the first network device established according to the fourth path information; the fifth transmission path is the first network device to the second network device established according to the fifth path information Tunnel.
- the two tunnels may be I-PMSI tunnels.
- the fourth transmission path can be from leaf3 to
- the tunnel of DC-GW2 and the fifth transmission path may refer to the tunnel from DC-GW2 to DC-GW1; or, in the case of the first network device DC-GW1, the fourth transmission path may refer to the tunnel from DC-GW2 to DC-GW1 1.
- the fifth transmission path may refer to the tunnel from DC-GW1 to leaf1.
- the fourth transmission path can refer to the tunnel from leaf2 to DC-GW1, and the fifth transmission The path may refer to the tunnel from DC-GW1 to DC-GW2; or, when the first network device is DC-GW2, the fourth transmission path may refer to the tunnel from DC-GW1 to DC-GW2, and the fifth transmission path may refer to The tunnel from DC-GW2 to leaf4.
- S41 to S42 can be referred to S21 to S22, or the related description and implementation of S41 or S42 can be referred to the related description in the corresponding embodiment in Figure 4 above, and the LDP or TE method is used to establish the first Five transmission path and sixth transmission path.
- step 703 the method further includes the following steps 801 to 805:
- Step 801 The first network device receives the seventh route sent by the second network device; the seventh route carries the fourth device identifier and the second AS number; the fifth route and the seventh route are used to indicate the second multicast source.
- Step 802 The first network device determines according to the third device identifier and the first AS number carried in the fifth route that the fourth transmission path is used to receive the traffic of the second multicast source, and according to the first network device used to receive the seventh route.
- Five transmission paths determine that the fifth transmission path is used to send the traffic of the second multicast source, where the fourth transmission path is the transmission path from the third network device to the first network device, and the fifth transmission path is the transmission path from the first network device. The transmission path from the network device to the second network device.
- Step 803 The first network device generates a third multicast entry; where the third multicast entry is used to instruct the first network device to receive the traffic of the second multicast source from the fourth transmission path and pass the fifth transmission path Send the traffic of the second multicast source.
- Step 804 the first network device updates the fourth device identifier in the seventh route to the third device identifier carried in the fifth route and updates the second AS number in the seventh route to the first AS carried in the first route. No., determine the eighth route.
- Step 805 The first network device sends the eighth route to the third network device.
- the seventh route and the eighth route may both be BGP C-multicast routes.
- the fourth transmission path and the fifth transmission path are both I-PMSI tunnels.
- the multicast source is still Server-3 and the multicast user is host-1.
- the first network device in step 601 to step 605 corresponds to The second network device corresponding to the first network device in step 801 to step 805; the third network device corresponding to the first network device in step 601 to step 605 as the third network device in step 801 to step 805 A second network device corresponding to a network device.
- the multicast source is Server-2 and the multicast user is host-2.
- the first network device is DC-GW1
- the third network device can be leaf2
- the second network device can be DC-GW1.
- steps 801 to 805 please refer to the relevant descriptions of steps 601 to 605 in the embodiment corresponding to FIG. 6 above.
- the embodiment of the present application may further include: S51, the first network device sends the traffic to the second network device The sixth path information is sent and the sixth transmission path is determined according to the sixth path information.
- the sixth transmission path may be an S-PMSI tunnel.
- the first network device modifies the third multicast entry into a fourth multicast entry, and the fourth multicast entry is used to indicate the first network device
- the traffic received from the fourth transmission path is sent through a sixth transmission path, where the sixth transmission path is an S-PMSI tunnel from the first network device to the second network device.
- the multicast source upstream of the third network device completes routing announcement, and when a multicast user downstream of the second network device joins the multicast source, the second network device in the network
- the received sixth route can be traced back to the first network device.
- the first network device can also trace back to the third network device based on the received fifth route.
- the multicast path to the multicast user makes it possible for the traffic of the multicast source to perform accurate cross-DC multicast in the NG MVPN, that is, the multicast user and the multicast source are not in the same DC and the multicast process passes In the case of a joint device of two DCs, it provides multicast services for multicast users.
- FIG. 9 is a schematic structural diagram of a device 900 for implementing multicast according to an embodiment of the application.
- the device 900 is applied to the first network device in the next-generation multicast virtual private network NG MVPN, and includes: a receiving unit 901, processing Unit 902 and sending unit 903.
- the receiving unit 901 is configured to receive a first route sent by a second network device, where the first data center DC includes the first network device, and the second DC includes the first network device and the second network Device, the third DC includes the second network device, the first network device is an edge device that the first DC and the second DC communicate with each other, and the first route carries a second device identifier and a Second autonomous system AS number, wherein the second device identifier indicates the second network device and the first virtual private network VPN instance corresponding to the second network device, and the second AS number indicates the second DC
- the processing unit 902 is configured to determine a second route according to the first route, and the second route is the first network device by updating the second device identifier in the first route to the first device Identification and update the second AS number in the first route to the first AS number determined, wherein the first device identification indicates that the first network device corresponds to the first network device
- the second virtual private network VPN instance, the first AS number indicates the first DC
- the sending unit 903 is configured to send the second route to
- the receiving unit 901 can specifically perform step 501, step 601, step 701, and step 801;
- the processing unit 902 can specifically perform Step 502, step 602 to step 604, step 702, and step 802 to buzhou 804;
- the sending unit 903 can specifically execute step 503, step 605, step 703, and step 805.
- the first route includes a second virtual route forwarding route import VRF route import extended community attribute and a second source autonomous system Source AS extended community attribute
- the second VRF route import extended community attribute includes the second device identifier
- the second Source AS extended community attribute includes the second AS number.
- the second route includes the first VRF route impot extended community attribute and the first Source AS extended community attribute
- the first VRF route impot extended community attribute includes the first device identifier
- the first Source AS extended community attribute Including the first AS number.
- the first route is a virtual private network VPN route of the edge gateway protocol BGP
- the second route is an Ethernet virtual private network EVPN route of BGP.
- the second DC and the third DC belong to the same domain.
- the receiving unit 901 in the apparatus 900 is further configured to receive first path information sent by the second network device and determine the first transmission path according to the first path information Path; the sending unit 903 is further configured to send second path information to the third network device, where the second path information is used to instruct the third network device to determine the second transmission path.
- the first transmission path and the second transmission path are both an I-PMSI tunnel containing an operator's multicast service interface.
- the receiving unit 901 in the apparatus 900 is further configured to receive a third route sent by the third network device; the third route carries the first device identifier And the first AS number; both the first route and the third route are used to indicate the first multicast source; the processing unit 902 is further used to indicate the second route carried by the first route
- the network device identifier and the second AS number determine that the first transmission path is used to receive traffic from the first multicast source, and the second transmission path is used to determine the second transmission path according to the second transmission path used to receive the third route.
- the first transmission path is from the second A transmission path from a network device to the first network device, and the second transmission path is a transmission path from the first network device to the third network device;
- the first multicast entry is used to indicate all
- the first network device receives the traffic of the first multicast source from the first transmission path and sends the traffic of the first multicast source through the second transmission path;
- the sending unit 903 is further configured to send the traffic to the first multicast source
- the second network device sends the fourth route.
- the third route and the fourth route are both edge gateway protocol client multicast BGP C-multicast routes.
- the processing unit 902 in the device 900 is further configured to: if the first multicast source indicated by the first route is in the second network device, the multicast traffic If the traffic threshold is exceeded, a second multicast entry is generated, where the second multicast entry is used to instruct the first network device to receive the traffic of the multicast source from the third transmission path and pass the second The transmission path sends the traffic of the multicast source, and the third transmission path is the selected operator multicast service S-PMSI tunnel from the second network device to the first network device.
- the receiving unit 901 in the apparatus 900 is further configured to receive third path information sent by the second network device and determine the third path information according to the third path information. Transmission path.
- the receiving unit 901 in the apparatus 900 is further configured to receive a fifth route sent by the third network device, where the fifth route carries a third device identifier And the first autonomous system AS number, wherein the third device identifier indicates the third network device and the third VPN instance corresponding to the third network device;
- the processing unit 902 is further configured to The fifth route determines the sixth route, and the sixth route is that the first network device updates the third device identifier in the fifth route to the fourth device identifier and changes the fifth route
- the first AS number is updated to the second AS number determined, wherein the fourth device identifier indicates the first network device and the fourth VPN instance corresponding to the first network device;
- the sending unit 903 is further configured to send the sixth route to the second network device.
- the fifth route includes the fifth virtual route forwarding route entry VRF route import extended community attribute and the fifth source autonomous system Source AS extended community attribute, and the fifth VRF route import extended community attribute includes the third device identifier ,
- the fifth Source AS extended community attribute includes the first AS number.
- the sixth route includes the sixth VRF route impot extended community attribute and the sixth Source AS extended community attribute, the sixth VRF route impot extended community attribute includes the fourth device identifier, and the sixth Source AS extended community attribute Including the second AS number.
- the sixth route is a BGP EVPN route
- the fifth route is a VPN route of BGP.
- the receiving unit 901 in the apparatus 900 is further configured to receive fourth path information sent by the third network device and determine the fourth path information according to the fourth path information.
- Transmission path; the sending unit 903 is further configured to send fifth path information to the second network device, where the fifth path information is used to instruct the second network device to determine the fifth transmission path.
- the fourth transmission path and the fifth transmission path are both an I-PMSI tunnel containing an operator's multicast service interface.
- the receiving unit 901 in the apparatus 900 is further configured to receive the seventh route sent by the second network device; the fourth device identifier is carried in the seventh route And the second AS number; the fifth route and the seventh route are used to indicate the second multicast source; the processing unit 902 is further used to perform the third device carried by the fifth route The identifier and the first AS number determine that the fourth transmission path is used for receiving the traffic of the second multicast source, and the fifth transmission path is used for sending according to the fifth transmission path used for receiving the seventh route.
- the traffic of the second multicast source generate a third multicast entry; by updating the fourth device identifier in the seventh route to the third device identifier carried in the fifth route and adding The second AS number in the seventh route is updated to the first AS number carried by the first route, and the eighth route is determined; wherein, the fourth transmission path is from the third network device A transmission path to the first network device, the fifth transmission path is a transmission path from the first network device to the second network device; the third multicast entry is used to indicate the first network device A network device receives the traffic of the second multicast source from the fourth transmission path and sends the traffic of the second multicast source through the fifth transmission path; the sending unit 903 is further configured to send traffic to the second multicast source 3. The network device sends the eighth route. Wherein, the seventh route and the eighth route are both edge gateway protocol BGP C-multicast routes.
- the processing unit 902 in the apparatus 900 is further configured to: if the second multicast source indicated by the fifth route is in the multicast traffic on the first network device If the traffic threshold is exceeded, the third multicast entry is modified to a fourth multicast entry, and the fourth multicast entry is used to instruct the first network device to receive the data from the fourth transmission path
- the traffic is sent through a sixth transmission path, where the sixth transmission path is a selected carrier multicast service S-PMSI tunnel from the first network device to the second network device.
- the sending unit 903 in the apparatus 900 is further configured to send sixth path information to the second network device and determine the sixth path information according to the sixth path information. Transmission path.
- the device 900 corresponds to the method provided in the method embodiment corresponding to FIG. 5, so the various implementation manners of the device 900 and the technical effects achieved can refer to the related description of each implementation manner in the embodiment shown in FIG.
- FIG. 10 shows a network device 1000 provided by an embodiment of the present application.
- the network device 1000 includes a processor 1001 and a memory 1002.
- the memory 1002 stores instructions.
- the processor 1001 executes the instructions
- the The network device 1000 executes any one of the foregoing methods for implementing multicast.
- embodiments of the present application also provide a computer program product, which when running on a computer, causes the computer to execute any one of the foregoing methods for implementing multicast.
- embodiments of the present application also provide a computer-readable storage medium that stores instructions in the computer-readable storage medium, and when it runs on a computer or a processor, the computer or the processor executes the foregoing implementation of multicast Any one of the methods.
- the computer software product can be stored in a storage medium, such as read-only memory (English: read-only memory, ROM)/RAM, magnetic disk, An optical disc, etc., includes a number of instructions to enable a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the method described in each embodiment of the application or some parts of the embodiment.
- a computer device which may be a personal computer, a server, or a network communication device such as a router
- the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments.
- the description is relatively simple, and for related parts, please refer to the partial description of the method embodiment.
- the device embodiments described above are merely illustrative.
- the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place. , Or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请公开了一种实现组播的方法和装置,组播源进行路由发布时,在跨DC的合设设备处进行路由更新,将接收到的设备标识和自治系统AS号替换为该合设设备的设备标识和自治系统AS号,这样,当有组播用户加入该组播源时,该网络中的各网络设备均可以根据所接收到的路由,追溯到组播源,且确定出组播源到组播用户的组播路径,如此,使得组播源的流量在下一代组播虚拟专用网NG MVPN中进行准确的跨数据中心DC组播成为了可能,即,位于不同DC的组播源和组播用户经由合设设备进行通信时,该组播源能够为该组播用户提供组播服务。
Description
本申请要求于2019年06月06日提交国家知识产权局、申请号为201910492933.X、发明名称为“一种实现组播的方法和装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及通信技术领域,特别是涉及一种实现组播的方法和装置。
流量在网络中转发时可能会经过多个不同的数据中心(英文:data center,简称:DC)。其中,流量通常会从一个DC的边缘设备传输到另一个DC的边缘设备,从而实现跨DC转发。在许多网络中,同一个网络设备会被相邻的两个DC都当做边缘设备来使用,即相邻两个DC的边缘设备被合设成了一个网络设备,该网络设备可以被称为合设设备。但是,若组播源与组播用户之间的传输路径需要通过合设设备实现从一个DC转发到另一个DC,则该组播源无法为该组播用户提供组播服务。
发明内容
基于此,本申请实施例提供了一种实现组播的方法和装置,以使得,位于不同DC的组播源和组播用户经由合设设备进行通信时,该组播源能够为该组播用户提供组播服务。
第一方面,本申请实施例提供了一种在下一代组播虚拟专用网(英文:Next Generation Multicast Virtual Private Network,简称:NG MVPN)中实现组播的方法,该方法应用于包括第一网络设备、第二网络设备和第三网络设备的网络中,该网络中,第一网络设备是第一DC与第二DC相互通信的边缘设备,第二网络设备是第二DC和第三DC的边缘设备,第三网络设备属于第一DC。该方法具体可以包括:第二网络设备向第一网络设备发送的第一路由,该第一路由携带有第二设备标识和第二AS号,其中,第二设备标识指示第二网络设备和第二网络设备对应的第一虚拟专用网(英文:Virtual Private Network,简称:VPN)实例,第二AS号指示第二DC;该第一网络设备根据第一路由确定第二路由,该第二路由是第一网络设备通过将第一路由中的第二设备标识更新为第一设备标识和将第一路由中的第二AS号更新为第一AS号确定得到的,其中,第一设备标识指示第一网络设备和第一网络设备对应的第二VPN实例,第一AS号指示第一DC;接着,第一网络设备向第三网络设备发送第二路由。可见,通过本申请实施例提供的上述方法,第二网络设备上游的组播源完成路由发布,若第三网络设备的下游有组播用户加入该组播源时,该网络中的第三网络设备可以根据所接收的第二路由,追溯到第一网络设备,同理,第一网络设备也可以根据所接收到的第一路由,追溯到第二网络设备,如此,即可确定出组播源到组播用户的组播路径,使得组播源的流量在该NG MVPN中进行准确的跨DC组播成为了可能,即,位于不同DC的组播源和组播用户经由合设设备进行通信时,该组播源能够为该组播用户提供组播服务。
结合第一方面的一种可能的实现方式,所述第一路由包括第二虚拟路由转发路由入口VRF route import扩展团体属性和第二源自治系统Source AS扩展团体属性,所述第二VRF route import扩展团体属性包括所述第二设备标识,第二Source AS扩展团体属性包括所述第二AS号。而且,所述第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。可见,通过在组播源路由发布时,将设备标识和AS 号携带在上述两个扩展团体属性,在跨DC的合设设备处通过将两个扩展团体属性中的设备标识和AS号替换为自身对应的设备标识和AS号,将更新后的两个扩展团体属性携带在路由中继续在网络中发布,为组播源可以在该网络中提供组播服务提供了基础。
可以理解的是,所述第一路由为边缘网关协议BGP的虚拟专用网络VPN路由,具体为BGP协议的VPNv4路由;所述第二路由为BGP的以太网虚拟专用网络EVPN路由,具体为BGP EVPN协议的IP前缀路由(也称为Type5路由)或MAC/IP通告路由(也称为Type2路由)。需要说明的是,第一路由和第二路由也可以相同,均为BGP的VPN协议或BGP的EVPN协议。
其中,所述第二DC和所述第三DC属于同一个域。
结合第一方面的另一种可能的实现方式,从第二网络设备到第一网络设备的建立第一传输路径的过程,以及从第一网络设备到第三网络设备的建立第二传输路径的过程,具体可以包括:所述第一网络设备接收所述第二网络设备发送的第一路径信息并根据所述第一路径信息确定所述第一传输路径;所述第一网络设备向所述第三网络设备发送第二路径信息,所述第二路径信息用于指示所述第三网络设备确定所述第二传输路径。其中,传输路径建立之后,具有对应的路径标识,可以后续在网络节点上建立组播表项时使用。
可以理解的是,所述第一传输路径和所述第二传输路径均为包含运营商组播业务接口I-PMSI隧道。这样,以第一传输路径为例,假设在DC除了第一网络设备和第二网络设备外,还包括第四网络设备,那么,第一传输路径为以第二网络设备为根节点,分别到第一网络设备和第四网络设备的路径。
结合第一方面的再一种可能的实现方式,若第三网络设备的下游有组播用户请求加入第二网络设备上游的组播源时,本申请实施例还可以包括:第一步,第三网络设备向第一网络设备发送的第三路由;在所述第三路由携带所述第一设备标识和所述第一AS号;所述第一路由和所述第三路由均用于指示第一组播源;第二步,第一网络设备根据所述第一路由携带的所述第二网络设备标识和所述第二AS号确定第一传输路径用于接收所述第一组播源的流量并根据用于接收所述第三路由的第二传输路径确定所述第二传输路径用于发送所述第一组播源的流量;其中,所述第一传输路径是从所述第二网络设备到所述第一网络设备的传输路径,所述第二传输路径是从所述第一网络设备到所述第三网络设备的传输路径;第三步,第一网络设备生成第一组播表项;其中,所述第一组播表项用于指示所述第一网络设备从第一传输路径接收所述第一组播源的流量并通过第二传输路径发送所述第一组播源的流量;第四步,第一网络设备通过将所述第三路由中的所述第一设备标识更新为所述第一路由携带的所述第二设备标识和将所述第三路由中的所述第一AS号更新为所述第一路由携带的所述第二AS号,确定第四路由;第五步,第一网络设备向所述第二网络设备发送所述第四路由。可以理解的是,所述第三路由和所述第四路由均为边缘网关协议客户组播BGP C-multicast路由。
结合第一方面的又一种可能的实现方式,为了节约网络资源,在第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈值时,可以切换路径,即,建立从第二网络设备到第一网络设备的第三传输路径,该选择运营商组播业务S-PMSI隧道,并重新在相关网络设备上建立对应的组播表项。其中,本申请实施例还包括:第一网络设备接收所述第二网络设备发送的第三路径信息并根据所述第三路径信息确定所述第三传输路径。其中,若第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈 值,则,在所述第一网络设备生成第二组播表项,其中,所述第二组播表项用于指示所述第一网络设备从第三传输路径接收所述组播源的流量并通过所述第二传输路径发送所述组播源的流量,第三传输路径为从所述第二网络设备到第一网络设备的S-PMSI隧道。
可以理解的是,所述第三传输路径为S-PMSI隧道,假设在DC除了第一网络设备和第二网络设备外,还包括第四网络设备,那么,第三传输路径为从第二网络设备到第一网络设备的路径。在所述第三传输路径建立之后,具有和第一传输路径不同的路径标识,故,需要更新组播表项为后续提供组播服务作准备。
下述实现方式为结合第一方面提供在第三网络设备的上游连接组播源,第二网络设备的下游连接组播用户时,几种可能的实现方式,与上述第一方面的可能的实现方式中提供的在第三网络设备的下游连接组播用户,第二网络设备的上游连接组播源的情况类似,相关效果和细节描述可以参见上述说明。
结合第一方面的一种可能的实现方式,本申请实施例提供的实现组播的方法可以包括:所述第一网络设备接收所述第三网络设备发送的第五路由,其中,所述第五路由携带有第三设备标识和所述第一自治系统AS号,其中,所述第三设备标识指示所述第三网络设备和所述第三网络设备对应的第三VPN实例;所述第一网络设备根据所述第五路由确定第六路由,所述第六路由是所述第一网络设备通过将所述第五路由中的所述第三设备标识更新为第四设备标识和将所述第五路由中的所述第一AS号更新为所述第二AS号确定得到的,其中,所述第四设备标识指示所述第一网络设备和所述第一网络设备对应的第四VPN实例;所述第一网络设备向所述第二网络设备发送所述第六路由。
其中,所述第五路由包括第五虚拟路由转发路由入口VRF route import扩展团体属性和第五源自治系统Source AS扩展团体属性,所述第五VRF route import扩展团体属性包括所述第三设备标识,第五Source AS扩展团体属性包括所述第一AS号。所述第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,所述第六VRF route impot扩展团体属性包括所述第四设备标识,所述第六Source AS扩展团体属性包括所述第二AS号。
可以理解的是,所述第六路由为BGP EVPN路由,所述第五路由为BGP的VPN路由。
结合第一方面的另一种可能的实现方式,本申请实施例还包括:所述第一网络设备接收所述第三网络设备发送的第四路径信息并根据所述第四路径信息确定所述第四传输路径;所述第一网络设备向所述第二网络设备发送第五路径信息,所述第五路径信息用于指示所述第二网络设备确定所述第五传输路径。其中,所述第四传输路径和所述第五传输路径均为包含运营商组播业务接口I-PMSI隧道。
结合第一方面的再一种可能的实现方式,本申请实施例还包括:所述第一网络设备接收所述第二网络设备发送的第七路由;在所述第七路由携带所述第四设备标识和所述第二AS号;所述第五路由和所述第七路由用于指示第二组播源;所述第一网络设备根据所述第五路由携带的所述第三设备标识和所述第一AS号确定第四传输路径用于接收所述第二组播源的流量并根据用于接收所述第七路由的第五传输路径确定所述第五传输路径用于发送所述第二组播源的流量,其中,所述第四传输路径为从所述第三网络设备到所述第一网络设备的传输路径,所述第五传输路径为从所述第一网络设备到所述第二网络设备的传输路径;所述第一网络设备生成第三组播表项;其中,所述第三组播表项用于指示所述第一网络设备从所述第四传输路径接收所述第二组播源的流量并通过第五传输路径发送所述第二组播源的流量;所述第一网络设备通过将所述第七路由中的所述第四设备标识更新为 所述第五路由携带的所述第三设备标识和将所述第七路由中的所述第二AS号更新为所述第一路由携带的所述第一AS号,确定第八路由;所述第一网络设备向所述第三网络设备发送所述第八路由。其中,所述第七路由和所述第八路由均为边缘网关协议BGP C-multicast路由。
结合第一方面的又一种可能的实现方式,本申请实施例还包括:若所述第五路由所指示的第二组播源在所述第一网络设备上的组播流量超过流量阈值,所述第一网络设备将所述第三组播表项修改成第四组播表项,所述第四组播表项用于指示所述第一网络设备将从所述第四传输路径接收到的流量通过第六传输路径发送,其中,所述第六传输路径为从所述第一网络设备到所述第二网络设备的选择运营商组播业务S-PMSI隧道。其中,所述第一网络设备向所述第二网络设备发送的第六路径信息并根据所述第六路径信息确定所述第六传输路径。
第二方面,本申请实施例还提供了一种实现组播的装置,所述装置应用于下一代组播虚拟专用网NG MVPN中的第一网络设备,包括:接收单元,处理单元和发送单元。
其中,接收单元,用于接收第二网络设备发送的第一路由,其中,第一数据中心DC包括所述第一网络设备,第二DC包括所述第一网络设备和所述第二网络设备,第三DC包括所述第二网络设备,所述第一网络设备是所述第一DC与所述第二DC相互通信的边缘设备,所述第一路由携带有第二设备标识和第二自治系统AS号,其中,所述第二设备标识指示所述第二网络设备和所述第二网络设备对应的第一虚拟专用网VPN实例,所述第二AS号指示所述第二DC;处理单元,用于根据所述第一路由确定第二路由,所述第二路由是所述第一网络设备通过将所述第一路由中的所述第二设备标识更新为第一设备标识和将所述第一路由中的所述第二AS号更新为第一AS号确定得到的,其中,所述第一设备标识指示所述第一网络设备和所述第一网络设备对应的第二虚拟专用网VPN实例,所述第一AS号指示所述第一DC;发送单元,用于向第三网络设备发送所述第二路由,所述第三网络设备属于所述第一DC。
其中,所述第一路由包括第二虚拟路由转发路由入口VRF route import扩展团体属性和第二源自治系统Source AS扩展团体属性,所述第二VRF route import扩展团体属性包括所述第二设备标识,第二Source AS扩展团体属性包括所述第二AS号。所述第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。
可以理解的是,所述第一路由为边缘网关协议BGP的虚拟专用网络VPN路由,所述第二路由为BGP的以太网虚拟专用网络EVPN路由。
作为一个示例,所述第二DC和所述第三DC属于同一个域。
结合第二方面的一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第二网络设备发送的第一路径信息并根据所述第一路径信息确定所述第一传输路径;所述发送单元,还用于向所述第三网络设备发送第二路径信息,所述第二路径信息用于指示所述第三网络设备确定所述第二传输路径。其中,所述第一传输路径和所述第二传输路径均为包含运营商组播业务接口I-PMSI隧道。
结合第二方面的另一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第三网络设备发送的第三路由;在所述第三路由携带所述第一设备标识和所述第一AS号;所述第一路由和所述第三路由均用于指示第一组播源;所述处理单元,还用于根据所述第 一路由携带的所述第二网络设备标识和所述第二AS号确定第一传输路径用于接收所述第一组播源的流量并根据用于接收所述第三路由的第二传输路径确定所述第二传输路径用于发送所述第一组播源的流量;生成第一组播表项;通过将所述第三路由中的所述第一设备标识更新为所述第一路由携带的所述第二设备标识和将所述第三路由中的所述第一AS号更新为所述第一路由携带的所述第二AS号,确定第四路由;其中,所述第一传输路径是从所述第二网络设备到所述第一网络设备的传输路径,所述第二传输路径是从所述第一网络设备到所述第三网络设备的传输路径;所述第一组播表项用于指示所述第一网络设备从第一传输路径接收所述第一组播源的流量并通过第二传输路径发送所述第一组播源的流量;所述发送单元,还用于向所述第二网络设备发送所述第四路由。其中,所述第三路由和所述第四路由均为边缘网关协议客户组播BGP C-multicast路由。
结合第二方面的再一种可能的实现方式,该装置中的所述处理单元,还用于若所述第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈值,生成第二组播表项,其中,所述第二组播表项用于指示所述第一网络设备从第三传输路径接收所述组播源的流量并通过所述第二传输路径发送所述组播源的流量,第三传输路径为从所述第二网络设备到第一网络设备的选择运营商组播业务S-PMSI隧道。
结合第二方面的又一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第二网络设备发送的第三路径信息并根据所述第三路径信息确定所述第三传输路径。
结合第二方面的再一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第三网络设备发送的第五路由,其中,所述第五路由携带有第三设备标识和所述第一自治系统AS号,其中,所述第三设备标识指示所述第三网络设备和所述第三网络设备对应的第三VPN实例;所述处理单元,还用于根据所述第五路由确定第六路由,所述第六路由是所述第一网络设备通过将所述第五路由中的所述第三设备标识更新为第四设备标识和将所述第五路由中的所述第一AS号更新为所述第二AS号确定得到的,其中,所述第四设备标识指示所述第一网络设备和所述第一网络设备对应的第四VPN实例;所述发送单元,还用于向所述第二网络设备发送所述第六路由。
其中,所述第五路由包括第五虚拟路由转发路由入口VRF route import扩展团体属性和第五源自治系统Source AS扩展团体属性,所述第五VRF route import扩展团体属性包括所述第三设备标识,第五Source AS扩展团体属性包括所述第一AS号。所述第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,所述第六VRF route impot扩展团体属性包括所述第四设备标识,所述第六Source AS扩展团体属性包括所述第二AS号。
可以理解的是,所述第六路由为BGP EVPN路由,所述第五路由为BGP的VPN路由。
结合第二方面的又一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第三网络设备发送的第四路径信息并根据所述第四路径信息确定所述第四传输路径;所述发送单元,还用于向所述第二网络设备发送第五路径信息,所述第五路径信息用于指示所述第二网络设备确定所述第五传输路径。其中,所述第四传输路径和所述第五传输路径均为包含运营商组播业务接口I-PMSI隧道。
结合第二方面的另一种可能的实现方式,该装置中的所述接收单元,还用于接收所述第二网络设备发送的第七路由;在所述第七路由携带所述第四设备标识和所述第二AS号;所述第五路由和所述第七路由用于指示第二组播源;所述处理单元,还用于根据所述第五路由携带的所述第三设备标识和所述第一AS号确定第四传输路径用于接收所述第二组播 源的流量并根据用于接收所述第七路由的第五传输路径确定所述第五传输路径用于发送所述第二组播源的流量;生成第三组播表项;通过将所述第七路由中的所述第四设备标识更新为所述第五路由携带的所述第三设备标识和将所述第七路由中的所述第二AS号更新为所述第一路由携带的所述第一AS号,确定第八路由;其中,所述第四传输路径为从所述第三网络设备到所述第一网络设备的传输路径,所述第五传输路径为从所述第一网络设备到所述第二网络设备的传输路径;所述第三组播表项用于指示所述第一网络设备从所述第四传输路径接收所述第二组播源的流量并通过第五传输路径发送所述第二组播源的流量;所述发送单元,还用于向所述第三网络设备发送所述第八路由。其中,所述第七路由和所述第八路由均为边缘网关协议BGP C-multicast路由。
结合第二方面的再一种可能的实现方式,该装置中的所述处理单元,还用于若所述第五路由所指示的第二组播源在所述第一网络设备上的组播流量超过流量阈值,将所述第三组播表项修改成第四组播表项,所述第四组播表项用于指示所述第一网络设备将从所述第四传输路径接收到的流量通过第六传输路径发送,其中,所述第六传输路径为从所述第一网络设备到所述第二网络设备的选择运营商组播业务S-PMSI隧道。
结合第二方面的又一种可能的实现方式,该装置中的所述发送单元,还用于向所述第二网络设备发送的第六路径信息并根据所述第六路径信息确定所述第六传输路径。
可以理解的是,第二方面提供的装置对应于第一方面提供的方法,故第二方面各实现方式以及达到的技术效果可参见第一方面各实现方式的相关描述。
第三方面,本申请实施例还提供了一种网络设备,该网络设备包括处理器和存储器,所述存储器存储有指令,当处理器执行该指令时,使得该网络设备执行前述第一方面任意一种实现方式所述的方法。
第四方面,本申请实施例还提供了一种计算机程序产品,当其在计算机上运行时,使得计算机执行前述第一方面任意一种实现方式所述的方法。
第五方面,本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机或处理器上运行时,使得该计算机或处理器执行前述第一方面任意一种实现方式所述的方法。
图1为本申请实施例中一场景所涉及的网络的框架示意图;
图2为本申请实施例中一种实现组播的方法的信令流程图;
图3为本申请实施例中另一种实现组播的方法的信令流程图;
图4为本申请实施例中一种创建隧道的方法的流程示意图;
图5为本申请实施例中一种实现组播的方法的流程示意图;
图6为本申请实施例中另一种实现组播的方法的流程示意图;
图7为本申请实施例中再一种实现组播的方法的流程示意图;
图8为本申请实施例中又一种实现组播的方法的流程示意图;
图9为本申请实施例中一种实现组播的装置的结构示意图;
图10为本申请实施例中一种网络设备的结构示意图。
流量在网络中转发时可能会经过多个不同的DC。例如,在数据中心互联(英文:data center interconnection,简称:DCI)的场景中,一个数据中心(英文:data center,简称:DC)内部的流量可以通过运营商骨干网发送到另一个DC内部。通常,流量在跨DC转发时是从一个DC上的网关设备传输到另一个DC上的网关设备。例如,一个DC内部的流量由该DC的网关设备向运营商骨干网上的一个运营商边缘(英文:Provider Edge,简称:PE)设备发送,然后由该PE设备在该运营商骨干网中向另一个PE设备发送,再由该另一个PE设备向另一个DC的网关设备发送,从而被转发到另一个DC内部。
而在许多网络中,同一个网络设备会被相邻的两个DC都当作边缘设备来使用,即相邻两个DC的边缘设备被合设成了一个网络设备,这个网络设备可以被称为合设设备。例如,运营商骨干网上的一个PE设备可以被合设到一个DC的网关设备上,即该DC的网关设备既被用作该DC的网关设备,又被用作该运营商骨干网上的一个PE设备。
图1示出了一种网络的结构示意图。该网络中包括三个域:DC1、运营商骨干网和DC2,其中,运营商骨干网对应的自治系统(英文:autonomous system,简称:AS)号为100,DC1对应的AS号为200,DC2对应的AS号为300。而且,DC1和运营商骨干网具有合设设备DC-GW1,DC2和运营商骨干网具有合设设备DC-GW2。需要说明的是,该DC-GW1为运营商骨干网上的一个PE设备被合设到DC1的网关设备上形成的一个合设设备,同时作为运营商骨干网和DC1共用的边缘设备;同理,该DC-GW2为运营商骨干网上的一个PE设备被合设到DC2的网关设备上形成的一个合设设备,同时作为运营商骨干网和DC2共用的边缘设备。
其中,若DC1为虚拟扩展局域网(英文:Virtual Extensible LAN,简称:VXLAN)网络,则DC1中可以包括:DC-GW1、叶子节点leaf1、叶子节点leaf2和骨干节点spine1,其中,DC-GW1的标识为1.1.1.1,leaf1的标识为2.2.2.2,leaf2的标识为3.3.3.3,且leaf1连接用户host-1,leaf2连接服务器Server-2;运营商骨干网中包括:DC-GW1、DC-GW2、中间节点P3和运营商边缘设备PE1,其中,DC-GW2的标识为4.4.4.4,PE1连接服务器Server-1;若DC2也为VXLAN网络,则DC2中可以包括:DC-GW2、叶子节点leaf3、叶子节点leaf4和骨干节点spine3,其中,leaf3的标识为5.5.5.5,leaf4的标识为6.6.6.6,且leaf4连接用户host-2,leaf3连接服务器Server-3。需要说明的是,各个边缘设备均可以连接用户或者服务器,图1示出的仅是一个场景。
通常,以图1所示的网络为例,若服务器Server-3为组播源,其路由发布过程包括:DC2中的leaf3生成携带leaf3对应扩展团体属性的路由信息;leaf3将该BGP路由发送给DC-GW2;DC-GW2对该路由信息不加处理直接转发到DC-GW1;DC-GW1也对该路由信息不加处理直接转发至leaf1。但是,当leaf1的下游有组播用户想要加入组播源Server-3时,由于leaf1属于DC1且DC1中的边缘设备只能识别到本DC内的其他边缘设备,故,根据接收到路由信息中携带的leaf3对应扩展团体属性,该leaf1根本无法追溯到DC2中的 DC-GW2或leaf3,这样,无法确定出组播源到组播用户的组播路径,从而无法为组播用户提供组播服务。
基于此,在本申请实施例中,在跨DC的合设设备中处进行路由更新,例如,在合设设备DC-GW2上,将从DC2的边缘设备leaf3接收到的路由中携带的leaf3对应的设备标识和AS号,分别替换为该DC-GW2对应的设备标识和AS号,再将更新后的路由发送给该DC-GW1的所属的运营商骨干网的边缘设备DC-GW1;在合设设备DC-GW1上,将从运营商骨干网的边缘设备DC-GW2接收到的路由中携带的DC-GW2对应的设备标识和AS号,分别替换为该DC-GW1对应的设备标识和AS号,再将更新后的路由发送给该DC-GW1的所属的DC1的边缘设备leaf1。这样,若leaf1的下游有组播用户加入该组播源时,该网络中的leaf1可以根据所接收的路由信息,追溯到leaf3,也就是说,网络设备可以根据接收到的路由确定出组播源到组播用户的组播路径,从而组播源即可将组播流量转发至对应的组播用户,为组播用户提供组播服务。
需要说明的是,上述图1所示的网络架构仅是适用本申请实施例的一个场景示例,本申请实施例并不限于此场景。
可以理解的是,组播源在进行组播之前,一方面,组播源需要发布私网路由,即,将自己的地址发送给该网络中的所有网络设备,告知各网络设备该组播源在网络中的具体位置,以便网络中各网络设备可以精确的定位该组播源;另一方面,组播源在完成私网路由发布之后,若有组播用户请求接入该组播源,则,需要在组播流量的传输路径所经过的网络设备上建立对应的组播表项,以便后续组播源的流量可以准确的发送到对应的组播用户,实现组播源准确的为接入的组播用户提供组播服务的功能。
下面结合附图,对本申请实施例提供的实现组播的方法进行说明。
以图1所示的网络为场景,结合附图2,对组播源发布私网路由的过程进行说明。
假设组播源为Server-3,以其向DC1域内的leaf1发布路由的过程为例,其发布私网路由的过程可以参见图2所示的流程示意图。该过程具体可以包括下述步骤201~步骤211:
步骤201,Server-3向leaf3发送的该Server-3的地址。
步骤202,leaf3接收并保存Server-3发送的该Server-3的地址。
步骤203,leaf3基于该Server-3的地址生成路由1。
可以理解的是,该路由1中携带虚拟路由转发路由入口VRF route import扩展团体属性和自治系统Source AS扩展团体属性,这两个扩展团体属性的具体说明可以参考因特网工程任务组(英文:Internet Engineering Task Force,简称:IETF)请求注解(英文:Request For Comments,简称:RFC)6513和RFC6514的说明,所述RFC6513和RFC6514以全文引用的方式并入本申请中。其中,该VRF route import扩展团体属性(即,后续实施例中的设备标识),用于表示生成和发送该路由的网络设备,让接收到该路由的下一跳设备确定出该路由的来源;Source AS扩展团体属性(即,后续实施例中的AS号),用于标识该网络设备所述的AS域。例如:上述两个扩展团体属性可以被携带在 路由中的网络层可达信息(英文:network layer reachability information,简称:NLRI)字段中。
路由1的VRF route import扩展团体属性包括设备标识1,用于指示leaf3的标识和该leaf3对应的VPN实例;路由1中的Source AS扩展团体属性包括AS号。在图1所示的网络中,设备标识1可以是5.5.5.5:123,其中,5.5.5.5为该leaf3的标识,123为该leaf3为该Server-3配置的VPN实例标识,AS号可以是300,300为该leaf3所属的AS域对应的AS号。
步骤204,leaf3通过DC2向DC-GW2发送该路由1。
步骤205,DC-GW2接收并保存leaf3发送的该路由1。
步骤206,DC-GW2根据路由1确定路由2。
具体实现时,DC-GW2具体可以将该路由1中的VRF route import扩展团体属性和Source AS扩展团体属性进行更新,得到路由2,更新的过程包括:将设备标识1替换为设备标识2,替为AS号。具体而言,一方面,将设备标识1中leaf3的标识5.5.5.5替换为设备标识2中DC-GW2的标识4.4.4.4,将设备标识1中leaf3对应的VPN实例123替换为设备标识2中DC-GW2为该Server-3配置的VPN实例标识234;另一方面,将AS号300替换为该DC-GW2所属的另一AS域对应的AS号100。
步骤207,DC-GW2通过运营商骨干网向DC-GW1发送该路由2。
步骤208,DC-GW1接收并保存DC-GW2发送的该路由2。
步骤209,DC-GW2根据路由2确定路由3。
具体实现时,该DC-GW1具体可以将该路由2中的VRF route import扩展团体属性和Source AS扩展团体属性进行更新,得到路由3,更新的过程包括:将设备标识2替换为设备标识3,替为AS号。具体而言,一方面,将设备标识2中DC-GW2的标识4.4.4.4替换为设备标识3中DC-GW1的标识1.1.1.1,将设备标识2中DC-GW2对应的VPN实例234替换为设备标识2中DC-GW1为该Server-3配置的VPN实例标识567;另一方面,将AS号100替换为该DC-GW1所属的另一AS域对应的AS号200。
步骤210,DC-GW1通过DC1向leaf1发送该路由3。
步骤211,leaf1接收并保存DC-GW1发送的该路由3。
其中,路由1为组播源Server-3在DC-GW2上保存的路由,路由2为组播源Server-3在DC-GW1上保存的路由,路由3为组播源Server-3在leaf1上保存的路由。路由1~路由3均可以指示组播源Server-3。
需要说明的是,路由1~路由3可以是适用于对应域的BGP的各类VPN协议的路由,三个路由可以相同,也可以不同。例如:路由1和路由3可以是BGP的EVPN路由,具体为BGP EVPN协议的IP前缀路由(也称为Type5路由)或MAC/IP通告路由(也称为Type2路由),路由2可以是BGP的VPN协议,具体为BGP协议的VPNv4路由;又例如:路由1~路由3可以均为BGP的VPN协议;再例如:路由1~路由3也可以均为BGP的EVPN协议。其中,BGP EVPN协议的IP前缀路由(也称为Type5路由)或MAC/IP通告路由的详细说明可以参见RFC7432的说明,所述RFC7432以全文引用的方式并入本申请中。
需要说明的是,上述仅是以组播源Server-3向leaf1发布私网路由的相关说明,Srrver-3向其他网络设备发布私网路由的过程、以及其他组播源向网络中的网络设备发布私网路由的过程,均可以参照上述图2对应的实施例提供的方法的相关描述,在此不再赘述。
可见,通过本申请实施例提供的上述方法,leaf3上游的组播源完成路由发布,即,在合设设备DC-GW1和DC-GW2上分别进行路由更新后,将更新的路由向下游发布,这样,若leaf1的下游有组播用户加入该组播源时,该网络中的各网络设备可以根据所接收的路由,追溯到上游的网络设备,即,可以确定出组播源到组播用户的组播路径,使得组播源的流量在该NG MVPN中进行准确的跨DC组播成为了可能。
下面以图1所示的网络为场景,结合附图,对组播用户请求接入组播源以及各网络设备建立组播表项的过程进行说明。
以图1所示的网络中组播用户host-1请求加入组播源Server-3的过程为例,在图2对应的实施例之后,该host-1请求加入Server-3并建立组播表项的过程可以参见图3所示的流程示意图。该过程具体可以包括下述步骤301~步骤313:
步骤301,host-1向leaf1发送加入请求消息。
可以理解的是,该加入请求消息中携带组播源的地址,例如:Server-3的地址,用于指示组播源Server-3。
步骤302,leaf1根据组播源的地址,查找到该leaf1上保存的与该组播源对应的路由3。
步骤303,leaf1根据该路由3确定应该向DC-GW1请求加入组播成员host-1,并建立组播表项1。
具体实现时,该leaf1根据路由3可以确定通过DC-GW1到leaf1的隧道接收组播流量,而且,还可以确定通过leaf1到host-1之间的路径发送组播流量;从而,该leaf1根据路由3可以建立组播表项1。
其中,组播表项至少包括:组播源Server-3地址、组播用户host-1地址、上游接口和下游接口,组播表项1中的上游接口的标识具体为:DC-GW1到leaf1的隧道的标识,下游接口的标识具体为:leaf1上连接host-1的接口的标识。
需要说明的是,本申请实施例中提及的隧道以及隧道的标识的相关描述,可以参见下述图4对应的实施例的相关描述,在此不再赘述。
步骤304,leaf1向DC-GW1发送BGP C-multicast路由1。
可以理解的是,BGP C-multicast路由1中,可以携带组播源的地址和组播成员的地址,例如:Server-3的地址和host-1的地址,用于请求加入组播成员host-1到Server-3,并触发DC-GW1建立对应的组播表项2。而且,BGP C-multicast路由1中携带设备标识3和AS号,其中,设备标识3包括DC-GW1的标识、DC-GW1为Server-3配置的VPN实例标识,AS号为200。BGP C-multicast路由的具体说明可以参考RFC6513的说明,所述RFC6513以全文引用的方式并入本申请中。
需要说明的是,BGP C-multicast路由1具体可以是由一个网络设备通过广播的形式 向该网络设备的邻居设备发送的,其中,该BGP C-multicast路由1中至少携带组播源的地址、设备标识3和AS号,那么,接收到该BGP C-multicast路由1后,各邻居设备查看该BGP C-multicast路由1中携带的设备标识3是否与自己匹配,如果是,该邻居设备对该BGP C-multicast路由1进行处理;如果不匹配,则丢弃该BGP C-multicast路由1,不作处理。例如:该leaf1向DC-GW1发送BGP C-multicast路由1,具体可以包括:该leaf1向DC-GW1、leaf2等邻居设备广播BGP C-multicast路由1,该BGP C-multicast路由1中携带DC-GW1的标识,那么,收到该BGP C-multicast路由1的网络设备中,只有DC-GW1对该BGP C-multicast路由1进行处理,即,DC-GW1建立组播表项2,并向DC-GW2发送BGP C-multicast路由2。
步骤305,DC-GW1根据所接收到的BGP C-multicast路由1中的组播源的地址,查找到该DC-GW1上保存的与该组播源对应的路由2。
步骤306,DC-GW1根据该路由2确定应该向DC-GW2请求加入组播成员host-1,并建立组播表项2。
具体实现时,该DC-GW1根据路由2可以确定通过DC-GW2到DC-GW1的隧道接收组播流量,而且,还可以确定通过DC-GW1到leaf1的隧道发送组播流量;从而,该DC-GW1根据路由2可以建立组播表项2。
其中,组播表项2中的上游接口的标识具体为:DC-GW2到DC-GW1的隧道的标识,下游接口的标识具体为:DC-GW1到leaf1的隧道的标识。
步骤307,DC-GW1向DC-GW2发送的BGP C-multicast路由2。
步骤308,DC-GW2根据所接收到的BGP C-multicast路由2中的组播源的地址,查找到该DC-GW2上保存的与该组播源对应的路由1。
步骤309,DC-GW2根据该路由1确定应该向leaf3请求加入组播成员host-1,并建立组播表项3。
可以理解的是,该BGP C-multicast路由2中至少携带组播源的地址、设备标识2和AS号。例如:该DC-GW1向DC-GW2发送BGP C-multicast路由2,具体可以包括:该DC-GW1向DC-GW2、PE1等邻居设备广播BGP C-multicast路由2,该BGP C-multicast路由2中携带DC-GW2的标识,那么,收到该BGP C-multicast路由2的网络设备中,只有DC-GW2对该BGP C-multicast路由2进行处理,即,DC-GW2建立组播表项3,并向leaf3发送BGP C-multicast路由3。
具体实现时,该DC-GW2根据路由1可以确定通过leaf3到DC-GW2的隧道接收组播流量,而且,还可以确定通过DC-GW2到DC-GW1的隧道发送组播流量;从而,该DC-GW2根据路由1可以建立组播表项3。
其中,组播表项3中的上游接口的标识具体为:leaf3到DC-GW2的隧道的标识,下游接口的标识具体为:DC-GW2到DC-GW1的隧道的标识。
步骤310,DC-GW2向leaf3发送BGP C-multicast路由3。
步骤311,leaf3根据所接收到的BGP C-multicast路由3中的组播源的地址,查找到 该leaf3上保存的与该组播源对应的组播源地址。
步骤312,leaf3根据该组播源地址确定应该向Server-3请求加入组播成员host-1,并建立组播表项4。
可以理解的是,该BGP C-multicast路由3中至少携带组播源的地址、设备标识1和AS号。例如:该DC-GW2向leaf3发送BGP C-multicast路由3,具体可以包括:该DC-GW2向leaf3、leaf4等邻居设备广播BGP C-multicast路由3,该BGP C-multicast路由3中携带leaf3的标识,那么,收到该BGP C-multicast路由3的网络设备中,只有leaf3对该BGP C-multicast路由3进行处理,即,leaf3建立组播表项4,并向Server-3发送加入请求消息。
具体实现时,该leaf3可以确定通过Server-3到leaf3之间的路径接收组播流量,而且,还可以确定通过leaf3到DC-GW1的隧道发送组播流量;从而,该leaf3还可以建立组播表项4。
其中,组播表项4中的上游接口的标识具体为:leaf3上连接Server-3的接口的标识,组播表项1中的下游接口的标识具体为:leaf3到DC-GW2的隧道的标识。
步骤313,leaf3向Server-3发送加入请求消息。
可以理解的是,该加入请求消息中携带请求加入的组播用户的地址,例如:host-1的地址,用于指示是组播用户host-1请求加入组播源Server-3。
如此,组播用户host-1加入了Server-3,成为了Server-3提供组播服务的对象,而且,在组播源Server-3到组播用户host-1的组播路径上的各边缘设备上建立了对应的组播表项,确保组播源Server-3提供的组播流量可以准确的被组播用户host-1接收到。
需要说明的是,其他任意的组播用户加入组播源的请求以及在组播流量的传输路径可能经过的网络设备上建立对应的组播表项的过程,均可以参照上述图3对应的实施例提供的方法,在此不再赘述。
可见,本申请实施例提供的上述方法,通过在发布路由时更新路由信息,并且基于更新后的路由信息建立组播表项,确保从组播源发出的组播流量可以准确的转发至已经加入该组播源的组播用户,从而确保可以为组播用户提供组播服务。
对于本申请实施例中提及的隧道的建立过程,可以以图1所示的网络中DC-GW2到DC-GW1的包含运营商组播业务接口(英文:Inclusive-Provider Multicast Service Interface,简称:I-PMSI)隧道的建立过程为例进行说明。
具体实现时,若DC-GW2要建立到DC-GW1的I-PMSI隧道,具体建立过程可以参见图4所示的流程示意图,可以包括:
步骤401,DC-GW2分别向DC-GW1和PE1发送AS域内包含运营商组播业务接口自动发现intra-as i-pmsi a-d路由。
可以理解的是,DC-GW1和DC-GW2共同属于的运营商骨干网域内包括3个边缘设备,那么,步骤401具体为:DC-GW2分别向该域内其他的两个边缘设备DC-GW1和PE1 发送intra-as i-pmsi a-d路由。该intra-as i-pmsi a-d路由中包括:待建立隧道的路径信息,该待建立隧道的路径信息包括该DC-GW2的标识和待建立隧道的标识。
需要说明的是,对于合设设备DC-GW1和DC-GW2,在建立隧道前,可以识别待建立隧道所属的域,根据所属域的不同,在intra-as i-pmsi a-d路由中携带不同的路径信息,如此,可以在不同的域建立该域适用的对应隧道。例如:对于DC-GW2,若建立DC-GW2到DC-GW1的隧道,则,在intra-as i-pmsi a-d路由中携带运营商骨干网中隧道的路径信息,若建立leaf3到DC-GW2的隧道,则在intra-as i-pmsi a-d路由中携带DC2中隧道的路径信息,如此,在不同的域即可建立不同类型的隧道。
步骤402,DC-GW1和PE1分别向DC-GW2发送intra-as i-pmsi a-d路由。
可以理解的是,该intra-as i-pmsi a-d路由中不包括待建立隧道的标识。
若采用标签分发协议(英文:Label Distribution Protocol,简称:LDP)的方式建立隧道,那么,在步骤402之后,可以通过下述步骤403a完成隧道的建立;若采用流量工程(英文:traffic engineering,简称:TE)的方式建立隧道,那么,在步骤402之后,还可以通过下述步骤403b~404b完成隧道的建立:
步骤403a,DC-GW1和PE1分别沿传输路径向DC-GW2发送Mapping消息,建立以DC-GW2为根节点的隧道。
可以理解的是,由于该Mapping消息用于为隧道的各条节点分配标签,并将标签依次记录下来,随着Mapping消息逐跳转发至DC-GW2,故,该DC-GW2上具有DC-GW2到DC-GW1以及DC-GW2到PE1的隧道的标签栈,用于组播流量在该两条隧道中的转发。
步骤403b,DC-GW2分别向DC-GW1和PE1发送Path消息。
步骤404b,DC-GW1和PE1分别向DC-GW2发送Resv消息。
可以理解的是,Path消息和Resv消息用于为DC-GW2到DC-GW1以及DC-GW2到PE1建立隧道。
可见,通过上述步骤401、步骤402和步骤403a,或者,通过上述步骤402、步骤402、步骤403b和步骤404b,均可以建立DC-GW2到DC-GW1以及DC-GW2到PE1的隧道。
需要说明的是,上述DC-GW2到DC-GW1隧道的标识以及DC-GW2到PE1隧道的标识一致,而且该隧道的标识可以作为上述图3对应实施例中组播表项2的上游接口的标识或者组播表项3的下游接口的标识。
需要说明的是,图1示出的网络中,leaf3到DC-GW2的隧道、DC-GW1到leaf1的隧道,或者,其他场景下网络中的隧道,均可以参见上述图4对应的实施例进行建立,在此不再赘述。
需要说明的是,建立隧道的类型可以根据需要以及具体的网络支持的协议确定,例如:leaf3到DC-GW2的隧道、DC-GW1到leaf1的隧道,均可以是虚拟扩展局域网(英文:Virtual eXtensible LAN,简称:VXLAN)协议的协议无关组播-稀疏模式(英文:Protocol Independent Multicast-Sparse Mode,简称:PIM-SM)隧道,DC-GW2到DC-GW1的隧道,可以是LDP多点扩展(英文:multipoint extensions for LDP简称:mLDP)的 点到多点(英文:Point 2 Multiple Point,简称:P2MP)隧道。
需要说明的是,图4所示的实施例,可以是在图2所示的实施例之前执行的,也可以是与图2所示的实施例同时执行的,在此不做具体限定。
可以理解的是,以图4示出的方式建立的隧道为I-PMSI隧道,即,建立以一个边缘设备为根节点,到该域中其他所有边缘设备的隧道。那么,组播流量在I-PMSI隧道中实现组播,经过某边缘设备时,该边缘设备按照其上建立的组播表项中下游接口指示的隧道标识,组播流量会以该边缘设备为根节点,被发送到该域中除了该根节点之外的其他所有边缘设备(也记作叶子节点)中。而除了根节点之外的其他所有边缘设备中,有些边缘设备的下游并没有接入组播用户,会直接将接收到的组播流量丢弃,只有可以到达组播用户的边缘设备会将接收到的组播流量继续转发。例如:组播源Server-3的组播流量到达DC-GW2时,DC-GW2会将该组播流量发送至DC-GW1和PE1,DC-GW1将该组播流量转发至组播用户host-1,而PE1直接将该组播流量丢弃。这样,可能导致该网络中网络资源的浪费。
为了节约网络资源,本申请实施例还包括:针对边缘设备(尤其是DC和运营商骨干网之间的边缘设备,例如:DC-GW2)上建立类型为选择运营商组播业务接口(英文:Selective-Provider Multicast Service Interface,简称:S-PMSI)的隧道,以及在相关的边缘设备上生成该S-PMSI隧道对应的组播表项。可以理解的是,S-PMSI隧道,是指只将域内除根节点之外的其他边缘设备中,下游有已加入组播用户的边缘设备作为叶子节点,建立的根节点到叶子节点的隧道。
以图1所示的网络为场景,在组播过程中,假设运营商骨干网中使用的隧道为I-PMSI隧道,即,Server-3发出的组播流量经过DC-GW2时,根据DC-GW2上生成的组播表项3,该组播流量被同时转发至DC-GW1和PE1。但是,当组播源Server-3在DC-GW2上的组播流量超过了流量阈值,此时,本申请实施例还提供了切换隧道的方法,具体可以是:将运营商骨干网中使用的I-PMSI隧道切换为S-PMSI隧道。切换隧道的过程具体可以包括:第一步,建立S-PMSI隧道;第二步,更新对应边缘设备上的组播表项。
假设组播源Server-3在DC-GW2上的组播流量超过了流量阈值,则,对于第一步,该DC-GW2建立到DC-GW1的S-PMSI隧道,具体过程可以包括:S11,DC-GW2向DC-GW1发送intra-as s-pmsi a-d路由,该intra-as s-pmsi a-d路由中包括:待建立隧道的路径信息,该路径信息包括待建立隧道的标识;S12,DC-GW1向DC-GW2发送intra-as s-pmsi a-d路由,该intra-as s-pmsi a-d路由中不包括待建立隧道的标识;S13a,DC-GW1沿传输路径向DC-GW2发送Mapping消息,建立以DC-GW2到DC-GW1的隧道;或者,S13b,DC-GW2向DC-GW1发送Path消息,S14b,DC-GW1向DC-GW2发送Resv消息。其中,上述建立隧道的过程具体可以参见图4中建立DC-GW2到DC-GW1的隧道的相关描述。
可以理解的是,当通过S11、S12和S13a,或者通过S11、S12、S13b和S14b建立了DC-GW2到DC-GW1的S-PMSI隧道后,上述DC-GW2到DC-GW1隧道的标识与图4对应实施例建立的DC-GW2到DC-GW1的I-PMSI隧道的隧道标识不一致,那么,在组播过 程中节约网络资源,本申请实施例还可以将相关组播表中的I-PMSL隧道的隧道标识替换为对应的S-PMSI隧道的隧道标识。即,对于第二步,以图1对应的网络为例:可以将上述图3对应实施例中,组播表项2的上游接口的标识以及组播表项3的下游接口的标识中DC-GW2到DC-GW1的I-PMSI隧道的隧道标识进行更新,替换为DC-GW2到DC-GW1的S-PMSI隧道的隧道标识,这样,组播源Server-3的组播流量到达DC-GW2时,DC-GW2只将该组播流量发送至DC-GW1,DC-GW1将该组播流量转发至组播用户host-1,而不会将组播流量发送给不可能到达组播用户hoat-1的PE1。这样,以本实施例更新的组播表项进行组播时,可以节约网络资源。
图5为本申请实施例中一种实现组播的方法的流程示意图。参见图5,该方法具体可以包括下述步骤501~步骤503:
步骤501,第一网络设备接收第二网络设备发送的第一路由,其中,第一DC包括该第一网络设备,第二DC包括第一网络设备和第二网络设备,第三DC包括第二网络设备,该第一网络设备是第一DC与第二DC相互通信的边缘设备,第一路由携带有第二设备标识和第二自治系统AS号,其中,该第二设备标识指示第二网络设备和该第二网络设备对应的第一VPN实例,第二AS号指示第二DC。
其中,第一路由可以包括第二虚拟路由转发路由入口VRF route import扩展团体属性和第二源自治系统Source AS扩展团体属性。其中,第二VRF route import扩展团体属性包括第二设备标识,第二Source AS扩展团体属性包括第二AS号。
其中,第二DC和第三DC可以属于同一个域。
与上述以图1中网络为场景的实施例进行对应,一种情况下,第一网络设备可以对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为PE1或者DC-GW1。该情况下,第一DC对应运营商骨干网,可以属于AS号为100对应的AS域;第二DC对应DC2,可以属于AS号为300的AS域;第三DC可以和第二DC同属于AS号为300的AS域,或者,也可以对应与第二DC不同的AS域。第二设备标识携带于第二VRF route import扩展团体属性,具体可以是5.5.5.5:123,第二AS号携带于第二Source AS扩展团体属性,可以是300,其中5.5.5.5:123中的5.5.5.5为第二网络设备leaf3的标识,用于指示该leaf3;123为第二网络设备leaf3对应的第一VPN示例。
与上述以图1中网络为场景的实施例进行对应,另一种情况下,第一网络设备可以对应于DC-GW1,那么,第二网络设备即为DC-GW2或PE1,第三网络设备可以为leaf1或者leaf2。该情况下,第一DC对应DC1,可以属于AS号为200对应的AS域;第二DC对应运营商骨干网,可以属于AS号为100的AS域;第三DC可以和第二DC同属于AS号为100的AS域,或者,第三DC也可以对应DC2,属于AS号为300的AS域。若第二网络设备为DC-GW2,则,第二设备标识携带于第二VRF route import扩展团体属性,具体可以是4.4.4.4:234,第二AS号携带于第二Source AS扩展团体属性,可以是100,其中4.4.4.4:234中的4.4.4.4为第二网络设备DC-GW2的标识,用于指示该DC-GW2;234为第二网络设备DC-GW2对应的第一VPN示例。
需要说明的是,步骤501的相关描述及实现方式可以参见上述图2对应实施例中步骤205或步骤208的相关描述。
步骤502,第一网络设备根据所述第一路由确定第二路由,该第二路由是第一网络设备通过将第一路由中的第二设备标识更新为第一设备标识和将第一路由中的第二AS号更 新为第一AS号确定得到的,第一设备标识指示第一网络设备和该第一网络设备对应的第二VPN实例,第一AS号指示第一DC。
其中,第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。
其中,第一路由可以是BGP VPN路由,第二路由可以是BGP EVPN路由。具体而言,第二路由可以为BGP EVPN协议的IP前缀路由或MAC/IP通告路由,第一路由可以为BGP协议的VPNv4路由。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为PE1或者DC-GW1。该情况下,第一DC对应运营商骨干网,可以属于AS号为100对应的AS域,第一设备标识携带于第一VRF route import扩展团体属性,具体可以是4.4.4.4:234,第一AS号携带于第一Source AS扩展团体属性,可以是100,其中4.4.4.4:234中的4.4.4.4为第一网络设备DC-GW2的标识,用于指示该DC-GW2;234为第二网络设备DC-GW2对应的第二VPN示例。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW1,那么,第二网络设备即为DC-GW2或PE1,第三网络设备可以为leaf1或者leaf2。该情况下,第一DC对应DC1,可以属于AS号为200对应的AS域,第一设备标识具体可以是1.1.1.1:567,第一AS号可以是200,其中1.1.1.1:567中的1.1.1.1为第一网络设备DC-GW1的标识,用于指示该DC-GW1;567为第一网络设备DC-GW1对应的第二VPN示例。
需要说明的是,步骤502的相关描述及实现方式可以参见上述图2对应实施例中步骤206或步骤209的相关描述。
步骤503,第一网络设备向第三网络设备发送第二路由,该第三网络设备属于第一DC。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为PE1或者DC-GW1,第一DC对应运营商骨干网,可以属于AS号为100对应的AS域。该情况下,DC-GW2向PE1或者DC-GW1发送包括:第一设备标识4.4.4.4:234和第一AS号100的第二路由。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW1,那么,第二网络设备即为DC-GW2或PE1,第三网络设备可以为leaf1或者leaf2,第一DC对应DC1,可以属于AS号为200对应的AS域。该情况下,DC-GW1向leaf1或者leaf2发送包括:第一设备标识1.1.1.1:567和第一AS号200的第二路由。
需要说明的是,步骤503的相关描述及实现方式可以参见上述图2对应实施例中步骤207或步骤210的相关描述。
在一些实现方式中,本申请实施例中提供的实现组播的方法中,在执行上述步骤501~步骤503的过程中或者之前,还可以包括在各个域建立隧道的过程:S21,第一网络设备接收第二网络设备发送的第一路径信息并根据该第一路径信息确定第一传输路径;S22,第一网络设备向第三网络设备发送第二路径信息,该第二路径信息用于指示所述第三网络设备确定所述第二传输路径。
其中,第一传输路径即为根据第一路径信息,建立的第二网络设备到第一网络设备的隧道;第二传输路径为根据第二路径信息,建立的第一网络设备到第三网络设备的隧道。 该两个隧道可以为I-PMSI隧道。
与上述以图1中网络为场景的实施例进行对应,在第一网络设备对应于DC-GW2时,第一传输路径可以是指leaf3到DC-GW2的隧道、第二传输路径可以是指DC-GW2到DC-GW1的隧道。该情况下,第一传输路径可以是VXLAN协议的PIM-SM隧道,第二传输路径可以是mLDP的P2MP隧道。
与上述以图1中网络为场景的实施例进行对应,在第一网络设备对应于DC-GW1时,第一传输路径可以是指DC-GW2到DC-GW1的隧道、第二传输路径可以是指DC-GW1到leaf1的隧道。该情况下,第一传输路径可以是mLDP的P2MP隧道,第二传输路径可以是VXLAN协议的PIM-SM隧道。
需要说明的是,S21或S22的相关描述及实现方式,可以参见上述图4对应实施例中的相关描述,采用LDP或TE的方式建立第一传输路径和第二传输路径。
可见,通过本申请实施例提供的上述方法,第二网络设备上游的组播源完成路由发布,若第三网络设备的下游有组播用户加入该组播源时,该网络中的第三网络设备可以根据所接收的第二路由,追溯到第一网络设备,同理,第一网络设备也可以根据所接收到的第一路由,追溯到第二网络设备,如此,即可确定出组播源到组播用户的组播路径,使得组播源的流量在该NG MVPN中进行准确的跨DC组播成为了可能,即,实现了组播用户与组播源不在同一DC且组播过程通过两个DC的合设设备的情况下,为组播用户提供组播服务。
图6为本申请实施例提供的另一种实现组播的方法的流程示意图。该方法不仅包括图5对应的私网路由的发布过程,而且,还包括对组播用户请求接入组播源以及各网络设备建立组播表项的过程。参见图6,该方法在步骤503之后,还包括下述步骤601~步骤605:
步骤601,第一网络设备接收第三网络设备发送的第三路由;在该第三路由携带第一设备标识和第一AS号;第一路由和该第三路由均用于指示第一组播源。
可以理解的是,该第三路由可以是BGP C-multicast路由。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为DC-GW1。该情况下,第三路由可以包括:第一设备标识4.4.4.4:234和第一AS号100。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW1,那么,第二网络设备即为DC-GW2或PE1,第三网络设备可以为leaf1。该情况下,第三路由可以包括:第一设备标识1.1.1.1:567和第一AS号200。
需要说明的是,步骤601的相关描述及实现方式,可以参见上述图2对应实施例中步骤304或步骤307的相关描述。
步骤602,第一网络设备根据第一路由携带的第二网络设备标识和第二AS号,确定第一传输路径用于接收第一组播源的流量;并根据用于接收第三路由的第二传输路径,确定第二传输路径用于发送第一组播源的流量;其中,第一传输路径是从第二网络设备到第一网络设备的传输路径,所述第二传输路径是从第一网络设备到第三网络设备的传输路径。
步骤603,第一网络设备生成第一组播表项;其中,所第一组播表项用于指示所述第 一网络设备从第一传输路径接收第一组播源的流量并通过第二传输路径发送第一组播源的流量。
可以理解的是,第一传输路径和第二传输路径均可以是I-PMSI隧道。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为DC-GW1,Server-3对应第一组播源。该情况下,该DC-GW2可以根据第一路由携带的第二设备标识5.5.5.5:123和第二AS号300,确定第一传输路径为从leaf3到DC-GW2的隧道,该隧道用于接收Server-3发送的组播流量;而且,该DC-GW2也可以根据接收第三路由采用的DC-GW2到DC-GW1的隧道,确定第二传输路径为该DC-GW2到DC-GW1的隧道,该隧道用于发送Server-3发出的组播流量。该情况下,DC-GW2还可以建立第一组播表项,包括上游接口的标识:leaf3到DC-GW2的隧道的标识,下游接口的标识:DC-GW2到DC-GW1的隧道的标识。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW1,那么,第二网络设备即为DC-GW2或PE1,第三网络设备可以为leaf1,Server-3对应第一组播源。该情况下,该DC-GW1可以根据第一路由携带的第二设备标识4.4.4.4:234和第二AS号100,确定第一传输路径为从DC-GW2到DC-GW1的隧道,该隧道用于接收Server-3发送的组播流量;而且,该DC-GW1也可以根据接收第三路由采用的DC-GW1到leaf1的隧道,确定第二传输路径为该DC-GW1到leaf1的隧道,该隧道用于发送Server-3发出的组播流量。该情况下,DC-GW1还可以建立第一组播表项,包括上游接口的标识:DC-GW2到DC-GW1的隧道的标识,下游接口的标识:DC-GW1到leaf1的隧道。
需要说明的是,步骤602~步骤603的相关描述及实现方式,可以参见上述图2对应实施例中步骤305~步骤306或步骤308~步骤309的相关描述。
步骤604,第一网络设备通过将第三路由中的第一设备标识更新为第一路由携带的第二设备标识和将第三路由中的第一AS号更新为第一路由携带的第二AS号,确定第四路由。
步骤605,第一网络设备向第二网络设备发送第四路由。
可以理解的是,该第四路由可以是BGP C-multicast路由。
可以理解的是,第一网络设备可以将第三路由中携带的第一设备标识和第一AS号进行更新,得到第四路由,具体将第一设备标识更新为第二设备标识、将第一AS号更新为第二AS号,即,第四路由中包括第二设备标识和第二AS号以及其第三路由中除这两部分外的其他信息。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW2,那么,第二网络设备即为leaf3,第三网络设备可以为DC-GW1。该情况下,第四路由可以包括:第二设备标识5.5.5.5:123和第二AS号300,而且,DC-GW2将该第四路由发送给leaf3,以告知leaf3有组播用户请求加入组播源并触发leaf3建立对应的组播表项。
与上述以图1中网络为场景的实施例进行对应,若第一网络设备对应于DC-GW1,那么,第二网络设备可以为DC-GW2,第三网络设备可以为leaf1。该情况下,第四路由可以包括:第二设备标识4.4.4.4:234和第二AS号100,而且,DC-GW1将该第四路由发送给 DC-GW2,以告知DC-GW2有组播用户请求加入组播源并触发DC-GW2建立对应的组播表项。
需要说明的是,步骤604~步骤605的相关描述及实现方式,可以参见上述图2对应实施例中步骤307或步骤310的相关描述。
在一些实现方式中,由于第一传输路径和第二传输路径通常为I-PMSI隧道,即,在一个域内,建立了一个合设设备为根节点,域内其他所有边缘设备为叶子节点的隧道,该隧道对应一个隧道标识,当组播流量经过该合设设备时,会以该合设设备为隧道入节点,从各个边缘设备转发出来,而只有下游接入组播用户的隧道出节点接收到的组播流量被转发,其他各边缘设备接收的组播流量均被丢弃,造成网络资源浪费。基于此,在第一路由所指示的第一组播源在第二网络设备上的组播流量超过流量阈值时,本申请实施例还可以建立从第二网络设备到第一网络设备的S-PMSI隧道,并基于该新建立的S-PMSI隧道在第一网络设备上生成第二组播表项。
具体实现时,建立从第二网络设备到第一网络设备的S-PMSI隧道,具体可以包括:S31,第一网络设备接收第二网络设备发送的第三路径信息,并根据该第三路径信息确定第三传输路径。
其中,第三传输路径即为根据第三路径信息,建立的第二网络设备到第一网络设备的隧道,该隧道为S-PMSI隧道。
与上述以图1中网络为场景的实施例进行对应,在第一网络设备对应于DC-GW2时,第三传输路径可以是指leaf3到DC-GW2的隧道、第二传输路径可以是指DC-GW2到DC-GW1的隧道。该情况下,第三传输路径可以是VXLAN协议的PIM-SM隧道,第二传输路径可以是mLDP的P2MP隧道。
与上述以图1中网络为场景的实施例进行对应,在第一网络设备对应于DC-GW1时,第三传输路径可以是指DC-GW2到DC-GW1的隧道、第二传输路径可以是指DC-GW1到leaf1的隧道。该情况下,第三传输路径可以是mLDP的P2MP隧道,第二传输路径可以是VXLAN协议的PIM-SM隧道。
需要说明的是,S31的相关描述及实现方式,可以参见上述S11、S12和S13a,或者S11、S12、S13b和S14b的相关描述,或者,也可以参见图4对应实施例的相关说明。
如此,在一个域内,建立从第二网络设备到第一网络设备的S-PMSI隧道,将只建立从第二网络设备到第一网络设备的隧道,而不包括从该第二网络设备到其他各个边缘设备的隧道。
具体实现时,基于该新建立的S-PMSI隧道在第一网络设备上生成第二组播表项,具体可以包括:第一网络设备生成第二组播表项,其中,该第二组播表项用于指示第一网络设备从第三传输路径接收组播源的流量并通过第二传输路径发送所述组播源的流量,第三传输路径为从第二网络设备到第一网络设备的S-PMSI隧道。
可以理解的是,由于第三传输路径和第一传输路径是两条不同的隧道,故,第三传输路径和第一传输路径对应不同的隧道的标识。那么,在第一路由所指示的第一组播源在第二网络设备上的组播流量超过流量阈值,且建立好第三传输路径时,第一网络设备可以基 于从第二网络设备到第一网络设备的传输路径的变动,生成第二组播表项。
需要说明的是,生成第二组播表项的相关描述及实现方式,可以参见上述图2对应实施例中步骤306或步骤309的相关描述。
这样,当组播流量经过该第二网络设备时,只会按照第三传输路径,从第一网络设备转发出来,而不会从其他边缘设备转出又被丢弃,从而提高了网络资源的利用率。
可见,本申请实施例提供的上述方法,通过在发布路由时更新路由信息,并且基于更新后的路由信息建立组播表项,确保从组播源发出的组播流量可以准确的转发至已经加入该组播源的组播用户,从而确保可以为组播用户提供组播服务。而且,提供了组播过程中隧道切换的实现方式,将域内的I-PMSI隧道切换为S-PMSI隧道,节约了网络资源。
上述实施例均是以组播源→第二网络设备→第一网络设备→第三网络设备→组播用户的网络为基础对本申请实施例提供的实现组播的方法的具体介绍。在具体的场景中,第三网络设备侧(即,第一DC)也可以接组播源,而第二网络设备侧(即,第三DC)可以接组播用户,即为组播用户→第二网络设备→第一网络设备→第三网络设备→组播源。下面结合附图7和附图8,对第三网络设备侧接组播源,第二网络设备侧接组播用户情况下,本申请实施例提供的实现组播的方法进行说明。
第一部分,参见图7所示的本申请实施例提供的实现组播的方法的流程示意图,该方法具体可以包括:
步骤701,第一网络设备接收第三网络设备发送的第五路由,其中,第五路由携带有第三设备标识和第一AS号,其中,所述第三设备标识指示第三网络设备和第三网络设备对应的第三VPN实例。
其中,第五路由包括第五VRF route import扩展团体属性和第五Source AS扩展团体属性,该第五VRF route import扩展团体属性包括第三设备标识,第五Source AS扩展团体属性包括第一AS号。
在图1所示的网络中,一种情况下,若组播源仍为Server-3,组播用户为host-1,那么,该步骤701可以是第一网络设备DC-GW2接收第三网络设备leaf3发送的第五路由,该第五路由包括:第三设备标识5.5.5.5:123和第一AS号300;或者,该步骤701也可以是第一网络设备DC-GW1接收第三网络设备DC-GW2发送的第五路由,该第五路由包括:第三设备标识4.4.4.4:234和第一AS号100。另一种情况下,若组播源为Server-2,组播用户为host-2,那么,该步骤701可以是第一网络设备DC-GW1接收第三网络设备leaf2发送的第五路由;或者,该步骤701也可以是第一网络设备DC-GW2接收第三网络设备DC-GW1发送的第五路由。
需要说明的是,步骤701的相关描述及实现方式,可以参见上述图2对应实施例中步骤205或步骤208的相关描述。
步骤702,第一网络设备根据第五路由确定第六路由,该第六路由是第一网络设备通 过将第五路由中的第三设备标识更新为第四设备标识和将第五路由中的第一AS号更新为第二AS号确定得到的,其中,第四设备标识指示第一网络设备和第一网络设备对应的第四VPN实例。
其中,第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,该第六VRF route impot扩展团体属性包括第四设备标识,第六Source AS扩展团体属性包括第二AS号。
其中,第五路由可以是BGP VPN路由,第六路由可以是BGP EVPN路由。具体而言,第六路由可以为BGP EVPN协议的IP前缀路由或MAC/IP通告路由,第五路由可以为BGP协议的VPNv4路由。
在图1所示的网络中,一种情况下,若组播源仍为Server-3,组播用户为host-1,那么,该步骤702可以是第一网络设备DC-GW2将该第五路由中的第三设备标识5.5.5.5:123更新为第四设备标识4.4.4.4:234,将第一AS号300更新为第二AS号100,得到第六路由;或者,该步骤702也可以是第一网络设备DC-GW1将该第五路由中的第三设备标识4.4.4.4:234更新为第四设备标识1.1.1.1:567,将第一AS号100更新为第二AS号200,得到第六路由。另一种情况下,若组播源为Server-2,组播用户为host-2,那么,该步骤702可以是第一网络设备DC-GW1根据第五路由确定第六路由;或者,该步骤702也可以是第一网络设备DC-GW2根据第五路由确定第六路由。
需要说明的是,步骤702的相关描述及实现方式,可以参见上述图2对应实施例中步骤206或步骤209的相关描述。
步骤703,第一网络设备向第二网络设备发送第六路由。
在图1所示的网络中,一种情况下,若组播源仍为Server-3,组播用户为host-1,那么,该步骤703可以是第一网络设备DC-GW2将包括第四设备标识4.4.4.4:234和第二AS号100的第六路由发送给第二网络设备DC-GW1;或者,该步骤703也可以是第一网络设备DC-GW1将包括第四设备标识1.1.1.1:567和第二AS号200的第六路由发送给第二网络设备leaf1。另一种情况下,若组播源为Server-2,组播用户为host-2,那么,该步骤703可以是第一网络设备DC-GW1将第六路由发送给第二网络设备DC-GW2;或者,该步骤703也可以是第一网络设备DC-GW2将第六路由发送给第二网络设备leaf4。
需要说明的是,步骤703的相关描述及实现方式可以参见上述图2对应实施例中步骤207或步骤210的相关描述。
在一些实现方式中,本申请实施例中提供的实现组播的方法中,在执行上述步骤701~步骤703的过程中或者之前,还可以包括在各个域建立隧道的过程:S41,第一网络设备接收第三网络设备发送的第四路径信息并根据第四路径信息确定第四传输路径;S42,第一网络设备向第二网络设备发送第五路径信息,该第五路径信息用于指示第二网络设备确定第五传输路径。
其中,第四传输路径即为根据第四路径信息,建立的第三网络设备到第一网络设备的隧道;第五传输路径为根据第五路径信息,建立的第一网络设备到第二网络设备的隧道。该两个隧道可以为I-PMSI隧道。
在图1所示的网络中,一种情况下,若组播源仍为Server-3,组播用户为host-1,第一网络设备DC-GW2时,第四传输路径可以是指leaf3到DC-GW2的隧道、第五传输路径可以是指DC-GW2到DC-GW1的隧道;或者,第一网络设备DC-GW1时,第四传输路径可以是指DC-GW2到DC-GW1的隧道、第五传输路径可以是指DC-GW1到leaf1的隧道。另一种情况下,若组播源为Server-2,组播用户为host-2,第一网络设备DC-GW1时,第四传输路径可以是指leaf2到DC-GW1的隧道、第五传输路径可以是指DC-GW1到DC-GW2的隧道;或者,第一网络设备为DC-GW2时,第四传输路径可以是指DC-GW1到DC-GW2的隧道、第五传输路径可以是指DC-GW2到leaf4的隧道。
需要说明的是,S41~S42的相关描述可以参见S21~S22,或者,S41或S42的相关描述及实现方式,可以参见上述图4对应实施例中的相关描述,采用LDP或TE的方式建立第五传输路径和第六传输路径。
第二部分,参见图8所示的本申请实施例提供的实现组播的方法的流程示意图,该方法在步骤703之后,还包括下述步骤801~步骤805:
步骤801,第一网络设备接收第二网络设备发送的第七路由;在第七路由携带第四设备标识和第二AS号;第五路由和第七路由用于指示第二组播源。
步骤802,第一网络设备根据第五路由携带的第三设备标识和第一AS号确定第四传输路径用于接收所述第二组播源的流量,并根据用于接收第七路由的第五传输路径确定第五传输路径用于发送所述第二组播源的流量,其中,第四传输路径为从第三网络设备到第一网络设备的传输路径,第五传输路径为从第一网络设备到第二网络设备的传输路径。
步骤803,第一网络设备生成第三组播表项;其中,该第三组播表项用于指示第一网络设备从第四传输路径接收第二组播源的流量并通过第五传输路径发送第二组播源的流量。
步骤804,第一网络设备通过将第七路由中的第四设备标识更新为第五路由携带的第三设备标识和将第七路由中的第二AS号更新为第一路由携带的第一AS号,确定第八路由。
步骤805,第一网络设备向第三网络设备发送第八路由。
其中,第七路由和第八路由可以均为BGP C-multicast路由。
其中,第四传输路径和第五传输路径均为I-PMSI隧道。
可以理解的是,在图1所示的网络中,一种情况下,组播源仍为Server-3,组播用户为host-1,那么,将步骤601~步骤605中第一网络设备对应的第二网络设备作为步骤801~步骤805中该第一网络设备对应的第三网络设备;将步骤601~步骤605中第一网络设备对应的第三网络设备作为步骤801~步骤805中该第一网络设备对应的第二网络设备。另一种情况下,组播源为Server-2,组播用户为host-2,那么,第一网络设备为DC-GW1时,第三网络设备可以为leaf2,第二网络设备可以为DC-GW2,或者,第一网络设备为DC-GW2时,第三网络设备可以为DC-GW1,第二网络设备可以为leaf4。
需要说明的是,上述步骤801~步骤805的相关描述及实现方式,可以参见上述图6对应实施例中步骤601~步骤605的相关描述。
作为一个示例,当第五路由所指示的第二组播源在第一网络设备上的组播流量超过流量阈值时,本申请实施例还可以包括:S51,第一网络设备向第二网络设备发送的第六路径信息并根据该第六路径信息确定第六传输路径。该第六传输路径可以为S-PMSI隧道。此时,本申请实施例实现组播之前,还可以包括:第一网络设备将第三组播表项修改成第四组播表项,该第四组播表项用于指示第一网络设备将从第四传输路径接收到的流量通过第六传输路径发送,其中,该第六传输路径为从第一网络设备到第二网络设备的S-PMSI隧道。
需要说明的是,S51的相关描述及实现方式,可以参见上述S31的相关描述,或者,参见上述S11、S12和S13a,或者S11、S12、S13b和S14b的相关描述。
需要说明的是,生成第四组播表项的相关描述及实现方式,可以参见上述生成第二组播表项的相关描述,或者,参见图2对应实施例中步骤306或步骤309的相关描述。
这样,当组播流量经过该第二网络设备时,只会按照第六传输路径,从第一网络设备转发出来,而不会从其他边缘设备转出由被丢弃,从而提高了网络资源的利用率。
可见,通过本申请实施例提供的上述方法,第三网络设备上游的组播源完成路由发布,第二网络设备的下游有组播用户加入该组播源时,该网络中的第二网络设备可以根据所接收的第六路由,追溯到第一网络设备,同理,第一网络设备也可以根据所接收到的第五路由,追溯到第三网络设备,如此,即可确定出组播源到组播用户的组播路径,使得组播源的流量在该NG MVPN中进行准确的跨DC组播成为了可能,即,实现了组播用户与组播源不在同一DC且组播过程通过两个DC的合设设备的情况下,为组播用户提供组播服务。
图9为本申请实施例提供的一种实现组播的装置900的结构示意图,所述装置900应用于下一代组播虚拟专用网NG MVPN中的第一网络设备,包括:接收单元901,处理单元902和发送单元903。
其中,接收单元901,用于接收第二网络设备发送的第一路由,其中,第一数据中心DC包括所述第一网络设备,第二DC包括所述第一网络设备和所述第二网络设备,第三DC包括所述第二网络设备,所述第一网络设备是所述第一DC与所述第二DC相互通信的边缘设备,所述第一路由携带有第二设备标识和第二自治系统AS号,其中,所述第二设备标识指示所述第二网络设备和所述第二网络设备对应的第一虚拟专用网VPN实例,所述第二AS号指示所述第二DC;处理单元902,用于根据所述第一路由确定第二路由,所述第二路由是所述第一网络设备通过将所述第一路由中的所述第二设备标识更新为第一设备标识和将所述第一路由中的所述第二AS号更新为第一AS号确定得到的,其中,所述第一设备标识指示所述第一网络设备和所述第一网络设备对应的第二虚拟专用网VPN实例,所述第一AS号指示所述第一DC;发送单元903,用于向第三网络设备发送所述第二路由,所述第三网络设备属于所述第一DC。
需要说明的是,上述实现组播的装置900用于执行图5对应的实施例中的各个步骤,接收单元901具体可以执行步骤501、步骤601、步骤701和步骤801;处理单元902具体可以执行步骤502、步骤602~步骤604、步骤702和步骤802~buzhou 804;发送单元903具体可以执行步骤503、步骤605、步骤703和步骤805。
其中,所述第一路由包括第二虚拟路由转发路由入口VRF route import扩展团体属性和 第二源自治系统Source AS扩展团体属性,所述第二VRF route import扩展团体属性包括所述第二设备标识,第二Source AS扩展团体属性包括所述第二AS号。所述第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。
可以理解的是,所述第一路由为边缘网关协议BGP的虚拟专用网络VPN路由,所述第二路由为BGP的以太网虚拟专用网络EVPN路由。
作为一个示例,所述第二DC和所述第三DC属于同一个域。
在一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第二网络设备发送的第一路径信息并根据所述第一路径信息确定所述第一传输路径;所述发送单元903,还用于向所述第三网络设备发送第二路径信息,所述第二路径信息用于指示所述第三网络设备确定所述第二传输路径。其中,所述第一传输路径和所述第二传输路径均为包含运营商组播业务接口I-PMSI隧道。
在另一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第三网络设备发送的第三路由;在所述第三路由携带所述第一设备标识和所述第一AS号;所述第一路由和所述第三路由均用于指示第一组播源;所述处理单元902,还用于根据所述第一路由携带的所述第二网络设备标识和所述第二AS号确定第一传输路径用于接收所述第一组播源的流量并根据用于接收所述第三路由的第二传输路径确定所述第二传输路径用于发送所述第一组播源的流量;生成第一组播表项;通过将所述第三路由中的所述第一设备标识更新为所述第一路由携带的所述第二设备标识和将所述第三路由中的所述第一AS号更新为所述第一路由携带的所述第二AS号,确定第四路由;其中,所述第一传输路径是从所述第二网络设备到所述第一网络设备的传输路径,所述第二传输路径是从所述第一网络设备到所述第三网络设备的传输路径;所述第一组播表项用于指示所述第一网络设备从第一传输路径接收所述第一组播源的流量并通过第二传输路径发送所述第一组播源的流量;所述发送单元903,还用于向所述第二网络设备发送所述第四路由。其中,所述第三路由和所述第四路由均为边缘网关协议客户组播BGP C-multicast路由。
在再一种可能的实现方式中,该装置900中的所述处理单元902,还用于若所述第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈值,生成第二组播表项,其中,所述第二组播表项用于指示所述第一网络设备从第三传输路径接收所述组播源的流量并通过所述第二传输路径发送所述组播源的流量,第三传输路径为从所述第二网络设备到第一网络设备的选择运营商组播业务S-PMSI隧道。
在又一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第二网络设备发送的第三路径信息并根据所述第三路径信息确定所述第三传输路径。
在再一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第三网络设备发送的第五路由,其中,所述第五路由携带有第三设备标识和所述第一自治系统AS号,其中,所述第三设备标识指示所述第三网络设备和所述第三网络设备对应的第三VPN实例;所述处理单元902,还用于根据所述第五路由确定第六路由,所述第六路由是所述第一网络设备通过将所述第五路由中的所述第三设备标识更新为第四设备标识和将所述第五路由中的所述第一AS号更新为所述第二AS号确定得到的,其中,所述第四设备标识指示所述第一网络设备和所述第一网络设备对应的第四VPN实例;所述发送单元903,还用于向所述第二网络设备发送所述第六路由。
其中,所述第五路由包括第五虚拟路由转发路由入口VRF route import扩展团体属性和第五源自治系统Source AS扩展团体属性,所述第五VRF route import扩展团体属性包括所述第三设备标识,第五Source AS扩展团体属性包括所述第一AS号。所述第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,所述第六VRF route impot扩展团体属性包括所述第四设备标识,所述第六Source AS扩展团体属性包括所述第二AS号。
可以理解的是,所述第六路由为BGP EVPN路由,所述第五路由为BGP的VPN路由。
在又一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第三网络设备发送的第四路径信息并根据所述第四路径信息确定所述第四传输路径;所述发送单元903,还用于向所述第二网络设备发送第五路径信息,所述第五路径信息用于指示所述第二网络设备确定所述第五传输路径。其中,所述第四传输路径和所述第五传输路径均为包含运营商组播业务接口I-PMSI隧道。
在另一种可能的实现方式中,该装置900中的所述接收单元901,还用于接收所述第二网络设备发送的第七路由;在所述第七路由携带所述第四设备标识和所述第二AS号;所述第五路由和所述第七路由用于指示第二组播源;所述处理单元902,还用于根据所述第五路由携带的所述第三设备标识和所述第一AS号确定第四传输路径用于接收所述第二组播源的流量并根据用于接收所述第七路由的第五传输路径确定所述第五传输路径用于发送所述第二组播源的流量;生成第三组播表项;通过将所述第七路由中的所述第四设备标识更新为所述第五路由携带的所述第三设备标识和将所述第七路由中的所述第二AS号更新为所述第一路由携带的所述第一AS号,确定第八路由;其中,所述第四传输路径为从所述第三网络设备到所述第一网络设备的传输路径,所述第五传输路径为从所述第一网络设备到所述第二网络设备的传输路径;所述第三组播表项用于指示所述第一网络设备从所述第四传输路径接收所述第二组播源的流量并通过第五传输路径发送所述第二组播源的流量;所述发送单元903,还用于向所述第三网络设备发送所述第八路由。其中,所述第七路由和所述第八路由均为边缘网关协议BGP C-multicast路由。
在再一种可能的实现方式中,该装置900中的所述处理单元902,还用于若所述第五路由所指示的第二组播源在所述第一网络设备上的组播流量超过流量阈值,将所述第三组播表项修改成第四组播表项,所述第四组播表项用于指示所述第一网络设备将从所述第四传输路径接收到的流量通过第六传输路径发送,其中,所述第六传输路径为从所述第一网络设备到所述第二网络设备的选择运营商组播业务S-PMSI隧道。
在又一种可能的实现方式中,该装置900中的所述发送单元903,还用于向所述第二网络设备发送的第六路径信息并根据所述第六路径信息确定所述第六传输路径。
可以理解的是,该装置900对应于图5对应的方法实施例提供的方法,故该装置900的各实现方式以及达到的技术效果可参见图5所示实施例中各实现方式的相关描述。
此外,图10示出了本申请实施例提供的一种网络设备1000,该网络设备1000包括处理器1001和存储器1002,所述存储器1002存储有指令,当处理器1001执行该指令时,使得该网络设备1000执行前述实现组播的方法中的任意一种实现方式。
此外,本申请实施例还提供了一种计算机程序产品,当其在计算机上运行时,使得计算机执行前述实现组播的方法中的任意一种实现方式。
此外,本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存 储有指令,当其在计算机或处理器上运行时,使得该计算机或处理器执行前述实现组播的方法中的任意一种实现方式。
本申请实施例中提到的“第一网络设备”、“第一路由”等名称中的“第一”只是用来做名字标识,并不代表顺序上的第一。该规则同样适用于“第二”等。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如只读存储器(英文:read-only memory,ROM)/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请示例性的实施方式,并非用于限定本申请的保护范围。
Claims (42)
- 一种实现组播的方法,其特征在于,所述方法应用于下一代组播虚拟专用网NG MVPN中,包括:第一网络设备接收第二网络设备发送的第一路由,其中,第一数据中心DC包括所述第一网络设备,第二DC包括所述第一网络设备和所述第二网络设备,第三DC包括所述第二网络设备,所述第一网络设备是所述第一DC与所述第二DC相互通信的边缘设备,所述第一路由携带有第二设备标识和第二自治系统AS号,其中,所述第二设备标识指示所述第二网络设备和所述第二网络设备对应的第一虚拟专用网VPN实例,所述第二AS号指示所述第二DC;所述第一网络设备根据所述第一路由确定第二路由,所述第二路由是所述第一网络设备通过将所述第一路由中的所述第二设备标识更新为第一设备标识和将所述第一路由中的所述第二AS号更新为第一AS号确定得到的,其中,所述第一设备标识指示所述第一网络设备和所述第一网络设备对应的第二虚拟专用网VPN实例,所述第一AS号指示所述第一DC;所述第一网络设备向第三网络设备发送所述第二路由,所述第三网络设备属于所述第一DC。
- 根据权利要求1所述的方法,其特征在于,所述第一路由包括第二虚拟路由转发路由入口VRF route import扩展团体属性和第二源自治系统Source AS扩展团体属性,所述第二VRF route import扩展团体属性包括所述第二设备标识,第二Source AS扩展团体属性包括所述第二AS号。
- 根据权利要求1或2所述的方法,其特征在于,所述第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。
- 根据权利要求1至3任意一项所述的方法,其特征在于,所述第一路由为边缘网关协议BGP的虚拟专用网络VPN路由,所述第二路由为BGP的以太网虚拟专用网络EVPN路由。
- 根据权利要求1至4任意一项所述的方法,其特征在于,所述第二DC和所述第三DC属于同一个域。
- 根据权利要求1至5任意一项所述的方法,其特征在于,还包括:所述第一网络设备接收所述第二网络设备发送的第一路径信息并根据所述第一路径信息确定所述第一传输路径;所述第一网络设备向所述第三网络设备发送第二路径信息,所述第二路径信息用于指示所述第三网络设备确定所述第二传输路径。
- 根据权利要求6所述的方法,其特征在于,还包括:所述第一网络设备接收所述第三网络设备发送的第三路由;在所述第三路由携带所述第一设备标识和所述第一AS号;所述第一路由和所述第三路由均用于指示第一组播源;所述第一网络设备根据所述第一路由携带的所述第二网络设备标识和所述第二AS号确定第一传输路径用于接收所述第一组播源的流量并根据用于接收所述第三路由的第二传输路径确定所述第二传输路径用于发送所述第一组播源的流量;其中,所述第一传输路径是从所述第二网络设备到所述第一网络设备的传输路径,所述第二传输路径是从所述第一网络设备到所述第三网络设备的传输路径;所述第一网络设备生成第一组播表项;其中,所述第一组播表项用于指示所述第一网络设备从第一传输路径接收所述第一组播源的流量并通过第二传输路径发送所述第一组播源的流量;所述第一网络设备通过将所述第三路由中的所述第一设备标识更新为所述第一路由携带的所述第二设备标识和将所述第三路由中的所述第一AS号更新为所述第一路由携带的所述第二AS号,确定第四路由;所述第一网络设备向所述第二网络设备发送所述第四路由。
- 根据权利要求7所述的方法,其特征在于,所述第三路由和所述第四路由均为边缘网关协议客户组播BGP C-multicast路由。
- 根据权利要求6至8任意一项所述的方法,其特征在于,所述第一传输路径和所述第二传输路径均为包含运营商组播业务接口I-PMSI隧道。
- 根据权利要9所述的方法,其特征在于,还包括:若所述第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈值,所述第一网络设备生成第二组播表项,其中,所述第二组播表项用于指示所述第一网络设备从第三传输路径接收所述组播源的流量并通过所述第二传输路径发送所述组播源的流量,第三传输路径为从所述第二网络设备到第一网络设备的选择运营商组播业务S-PMSI隧道。
- 根据权利要求10所述的方法,其特征在于,还包括:所述第一网络设备接收所述第二网络设备发送的第三路径信息并根据所述第三路径信息确定所述第三传输路径。
- 根据权利要求1至11任意一项所述的方法,其特征在于,还包括:所述第一网络设备接收所述第三网络设备发送的第五路由,其中,所述第五路由携带有第三设备标识和所述第一自治系统AS号,其中,所述第三设备标识指示所述第三网络设备和所述第三网络设备对应的第三VPN实例;所述第一网络设备根据所述第五路由确定第六路由,所述第六路由是所述第一网络设备通过将所述第五路由中的所述第三设备标识更新为第四设备标识和将所述第五路由中的所述第一AS号更新为所述第二AS号确定得到的,其中,所述第四设备标识指示所述第一网络设备和所述第一网络设备对应的第四VPN实例;所述第一网络设备向所述第二网络设备发送所述第六路由。
- 根据权利要求12所述的方法,其特征在于,所述第五路由包括第五虚拟路由转 发路由入口VRF route import扩展团体属性和第五源自治系统Source AS扩展团体属性,所述第五VRF route import扩展团体属性包括所述第三设备标识,第五Source AS扩展团体属性包括所述第一AS号。
- 根据权利要求12或13所述的方法,其特征在于,所述第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,所述第六VRF route impot扩展团体属性包括所述第四设备标识,所述第六Source AS扩展团体属性包括所述第二AS号。
- 根据权利要求12至14任意一项所述的方法,其特征在于,所述第六路由为BGP EVPN路由,所述第五路由为BGP的VPN路由。
- 根据权利要求12至15任意一项所述的方法,其特征在于,还包括:所述第一网络设备接收所述第三网络设备发送的第四路径信息并根据所述第四路径信息确定所述第四传输路径;所述第一网络设备向所述第二网络设备发送第五路径信息,所述第五路径信息用于指示所述第二网络设备确定所述第五传输路径。
- 根据权利要求16所述的方法,其特征在于,还包括:所述第一网络设备接收所述第二网络设备发送的第七路由;在所述第七路由携带所述第四设备标识和所述第二AS号;所述第五路由和所述第七路由用于指示第二组播源;所述第一网络设备根据所述第五路由携带的所述第三设备标识和所述第一AS号确定第四传输路径用于接收所述第二组播源的流量并根据用于接收所述第七路由的第五传输路径确定所述第五传输路径用于发送所述第二组播源的流量,其中,所述第四传输路径为从所述第三网络设备到所述第一网络设备的传输路径,所述第五传输路径为从所述第一网络设备到所述第二网络设备的传输路径;所述第一网络设备生成第三组播表项;其中,所述第三组播表项用于指示所述第一网络设备从所述第四传输路径接收所述第二组播源的流量并通过第五传输路径发送所述第二组播源的流量;所述第一网络设备通过将所述第七路由中的所述第四设备标识更新为所述第五路由携带的所述第三设备标识和将所述第七路由中的所述第二AS号更新为所述第一路由携带的所述第一AS号,确定第八路由;所述第一网络设备向所述第三网络设备发送所述第八路由。
- 根据权利要求17所述的方法,其特征在于,所述第七路由和所述第八路由均为边缘网关协议BGP C-multicast路由。
- 根据权利要求16至18任意一项所述的方法,其特征在于,所述第四传输路径和所述第五传输路径均为包含运营商组播业务接口I-PMSI隧道。
- 根据权利要19所述的方法,其特征在于,还包括:若所述第五路由所指示的第二组播源在所述第一网络设备上的组播流量超过流量阈值,所述第一网络设备将所述第三组播表项修改成第四组播表项,所述第四组播表项用于 指示所述第一网络设备将从所述第四传输路径接收到的流量通过第六传输路径发送,其中,所述第六传输路径为从所述第一网络设备到所述第二网络设备的选择运营商组播业务S-PMSI隧道。
- 根据权利要求20所述的方法,其特征在于,还包括:所述第一网络设备向所述第二网络设备发送的第六路径信息并根据所述第六路径信息确定所述第六传输路径。
- 一种实现组播的装置,其特征在于,所述装置应用于下一代组播虚拟专用网NG MVPN中的第一网络设备,包括:接收单元,用于接收第二网络设备发送的第一路由,其中,第一数据中心DC包括所述第一网络设备,第二DC包括所述第一网络设备和所述第二网络设备,第三DC包括所述第二网络设备,所述第一网络设备是所述第一DC与所述第二DC相互通信的边缘设备,所述第一路由携带有第二设备标识和第二自治系统AS号,其中,所述第二设备标识指示所述第二网络设备和所述第二网络设备对应的第一虚拟专用网VPN实例,所述第二AS号指示所述第二DC;处理单元,用于根据所述第一路由确定第二路由,所述第二路由是所述第一网络设备通过将所述第一路由中的所述第二设备标识更新为第一设备标识和将所述第一路由中的所述第二AS号更新为第一AS号确定得到的,其中,所述第一设备标识指示所述第一网络设备和所述第一网络设备对应的第二虚拟专用网VPN实例,所述第一AS号指示所述第一DC;发送单元,用于向第三网络设备发送所述第二路由,所述第三网络设备属于所述第一DC。
- 根据权利要求22所述的装置,其特征在于,所述第一路由包括第二虚拟路由转发路由入口VRF route import扩展团体属性和第二源自治系统Source AS扩展团体属性,所述第二VRF route import扩展团体属性包括所述第二设备标识,第二Source AS扩展团体属性包括所述第二AS号。
- 根据权利要求22或23所述的装置,其特征在于,所述第二路由包括第一VRF route impot扩展团体属性和第一Source AS扩展团体属性,所述第一VRF route impot扩展团体属性包括所述第一设备标识,所述第一Source AS扩展团体属性包括所述第一AS号。
- 根据权利要求22至24任意一项所述的装置,其特征在于,所述第一路由为边缘网关协议BGP的虚拟专用网络VPN路由,所述第二路由为BGP的以太网虚拟专用网络EVPN路由。
- 根据权利要求22至25任意一项所述的装置,其特征在于,所述第二DC和所述第三DC属于同一个域。
- 根据权利要求22至26任意一项所述的装置,其特征在于,所述接收单元,还用于接收所述第二网络设备发送的第一路径信息并根据所述第一路径信息确定所述第一传输路径;所述发送单元,还用于向所述第三网络设备发送第二路径信息,所述第二路径信息用于指示所述第三网络设备确定所述第二传输路径。
- 根据权利要求27所述的装置,其特征在于,所述接收单元,还用于接收所述第三网络设备发送的第三路由;在所述第三路由携带所述第一设备标识和所述第一AS号;所述第一路由和所述第三路由均用于指示第一组播源;所述处理单元,还用于根据所述第一路由携带的所述第二网络设备标识和所述第二AS号确定第一传输路径用于接收所述第一组播源的流量并根据用于接收所述第三路由的第二传输路径确定所述第二传输路径用于发送所述第一组播源的流量;生成第一组播表项;通过将所述第三路由中的所述第一设备标识更新为所述第一路由携带的所述第二设备标识和将所述第三路由中的所述第一AS号更新为所述第一路由携带的所述第二AS号,确定第四路由;其中,所述第一传输路径是从所述第二网络设备到所述第一网络设备的传输路径,所述第二传输路径是从所述第一网络设备到所述第三网络设备的传输路径;所述第一组播表项用于指示所述第一网络设备从第一传输路径接收所述第一组播源的流量并通过第二传输路径发送所述第一组播源的流量;所述发送单元,还用于向所述第二网络设备发送所述第四路由。
- 根据权利要求28所述的装置,其特征在于,所述第三路由和所述第四路由均为边缘网关协议客户组播BGP C-multicast路由。
- 根据权利要求27至29任意一项所述的装置,其特征在于,所述第一传输路径和所述第二传输路径均为包含运营商组播业务接口I-PMSI隧道。
- 根据权利要30所述的装置,其特征在于,所述处理单元,还用于若所述第一路由所指示的第一组播源在所述第二网络设备上的组播流量超过流量阈值,生成第二组播表项,其中,所述第二组播表项用于指示所述第一网络设备从第三传输路径接收所述组播源的流量并通过所述第二传输路径发送所述组播源的流量,第三传输路径为从所述第二网络设备到第一网络设备的选择运营商组播业务S-PMSI隧道。
- 根据权利要求31所述的装置,其特征在于,所述接收单元,还用于接收所述第二网络设备发送的第三路径信息并根据所述第三路径信息确定所述第三传输路径。
- 根据权利要求22至32任意一项所述的装置,其特征在于,所述接收单元,还用于接收所述第三网络设备发送的第五路由,其中,所述第五路由携带有第三设备标识和所述第一自治系统AS号,其中,所述第三设备标识指示所述第三网络设备和所述第三网络设备对应的第三VPN实例;所述处理单元,还用于根据所述第五路由确定第六路由,所述第六路由是所述第一网络设备通过将所述第五路由中的所述第三设备标识更新为第四设备标识和将所述第五路由中的所述第一AS号更新为所述第二AS号确定得到的,其中,所述第四设备标识指示 所述第一网络设备和所述第一网络设备对应的第四VPN实例;所述发送单元,还用于向所述第二网络设备发送所述第六路由。
- 根据权利要求33所述的装置,其特征在于,所述第五路由包括第五虚拟路由转发路由入口VRF route import扩展团体属性和第五源自治系统Source AS扩展团体属性,所述第五VRF route import扩展团体属性包括所述第三设备标识,第五Source AS扩展团体属性包括所述第一AS号。
- 根据权利要求33或34所述的装置,其特征在于,所述第六路由包括第六VRF route impot扩展团体属性和第六Source AS扩展团体属性,所述第六VRF route impot扩展团体属性包括所述第四设备标识,所述第六Source AS扩展团体属性包括所述第二AS号。
- 根据权利要求33至35任意一项所述的装置,其特征在于,所述第六路由为BGP EVPN路由,所述第五路由为BGP的VPN路由。
- 根据权利要求33至36任意一项所述的装置,其特征在于,所述接收单元,还用于接收所述第三网络设备发送的第四路径信息并根据所述第四路径信息确定所述第四传输路径;所述发送单元,还用于向所述第二网络设备发送第五路径信息,所述第五路径信息用于指示所述第二网络设备确定所述第五传输路径。
- 根据权利要求37所述的装置,其特征在于,所述接收单元,还用于接收所述第二网络设备发送的第七路由;在所述第七路由携带所述第四设备标识和所述第二AS号;所述第五路由和所述第七路由用于指示第二组播源;所述处理单元,还用于根据所述第五路由携带的所述第三设备标识和所述第一AS号确定第四传输路径用于接收所述第二组播源的流量并根据用于接收所述第七路由的第五传输路径确定所述第五传输路径用于发送所述第二组播源的流量;生成第三组播表项;通过将所述第七路由中的所述第四设备标识更新为所述第五路由携带的所述第三设备标识和将所述第七路由中的所述第二AS号更新为所述第一路由携带的所述第一AS号,确定第八路由;其中,所述第四传输路径为从所述第三网络设备到所述第一网络设备的传输路径,所述第五传输路径为从所述第一网络设备到所述第二网络设备的传输路径;所述第三组播表项用于指示所述第一网络设备从所述第四传输路径接收所述第二组播源的流量并通过第五传输路径发送所述第二组播源的流量;所述发送单元,还用于向所述第三网络设备发送所述第八路由。
- 根据权利要求38所述的装置,其特征在于,所述第七路由和所述第八路由均为边缘网关协议BGP C-multicast路由。
- 根据权利要求37至39任意一项所述的装置,其特征在于,所述第四传输路径和所述第五传输路径均为包含运营商组播业务接口I-PMSI隧道。
- 根据权利要40所述的装置,其特征在于,所述处理单元,还用于若所述第五路由所指示的第二组播源在所述第一网络设备上的 组播流量超过流量阈值,将所述第三组播表项修改成第四组播表项,所述第四组播表项用于指示所述第一网络设备将从所述第四传输路径接收到的流量通过第六传输路径发送,其中,所述第六传输路径为从所述第一网络设备到所述第二网络设备的选择运营商组播业务S-PMSI隧道。
- 根据权利要求41所述的装置,其特征在于,所述发送单元,还用于向所述第二网络设备发送的第六路径信息并根据所述第六路径信息确定所述第六传输路径。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP20818390.5A EP3968584B1 (en) | 2020-05-17 | Method and apparatus for implementing multicasting | |
US17/541,465 US12063153B2 (en) | 2019-06-06 | 2021-12-03 | Method and apparatus for implementing multicast |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910492933.X | 2019-06-06 | ||
CN201910492933.XA CN112054962B (zh) | 2019-06-06 | 2019-06-06 | 一种实现组播的方法和装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/541,465 Continuation US12063153B2 (en) | 2019-06-06 | 2021-12-03 | Method and apparatus for implementing multicast |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020244372A1 true WO2020244372A1 (zh) | 2020-12-10 |
Family
ID=73609106
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/090725 WO2020244372A1 (zh) | 2019-06-06 | 2020-05-17 | 一种实现组播的方法和装置 |
Country Status (3)
Country | Link |
---|---|
US (1) | US12063153B2 (zh) |
CN (1) | CN112054962B (zh) |
WO (1) | WO2020244372A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115102806B (zh) * | 2022-06-20 | 2023-10-17 | 咪咕视讯科技有限公司 | 组播数据传输方法、装置、系统及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105337865A (zh) * | 2014-06-03 | 2016-02-17 | 华为技术有限公司 | 一种建立转发表项的方法、装置和系统 |
US20160134535A1 (en) * | 2014-11-06 | 2016-05-12 | Juniper Networks, Inc. | Deterministic and optimized bit index explicit replication (bier) forwarding |
CN105991302A (zh) * | 2015-03-20 | 2016-10-05 | 瞻博网络公司 | 可靠传输上使用注册的多播流覆盖 |
CN106161258A (zh) * | 2015-03-25 | 2016-11-23 | 华为技术有限公司 | 用于传输组播协议报文的方法、设备及系统 |
US9832031B2 (en) * | 2014-10-24 | 2017-11-28 | Futurewei Technologies, Inc. | Bit index explicit replication forwarding using replication cache |
CN109218178A (zh) * | 2017-07-05 | 2019-01-15 | 华为技术有限公司 | 一种报文处理方法及网络设备 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8619774B2 (en) * | 2004-10-26 | 2013-12-31 | Cisco Technology, Inc. | Method and apparatus for providing multicast messages within a virtual private network across a data communication network |
US9166903B2 (en) * | 2012-12-18 | 2015-10-20 | Alcatel Lucent | System, method and apparatus to resolve RPF-vector attribute conflicts |
US9148290B2 (en) | 2013-06-28 | 2015-09-29 | Cisco Technology, Inc. | Flow-based load-balancing of layer 2 multicast over multi-protocol label switching label switched multicast |
US9948472B2 (en) * | 2014-10-22 | 2018-04-17 | Juniper Networks, Inc. | Protocol independent multicast sparse mode (PIM-SM) support for data center interconnect |
CN104702480B (zh) * | 2015-03-24 | 2018-10-02 | 华为技术有限公司 | 下一代组播虚拟专用网中建立隧道保护组的方法和装置 |
US9935816B1 (en) | 2015-06-16 | 2018-04-03 | Amazon Technologies, Inc. | Border gateway protocol routing configuration |
US10104139B2 (en) * | 2016-03-31 | 2018-10-16 | Juniper Networks, Inc. | Selectively signaling selective tunnels in multicast VPNs |
CN105743797B (zh) * | 2016-04-05 | 2019-03-29 | 深圳市风云实业有限公司 | 基于接口绑定的组播vpn隧道建立方法 |
US10181999B2 (en) | 2016-12-16 | 2019-01-15 | Juniper Networks, Inc. | Optimizing information related to a route and/or a next hop for multicast traffic |
US10193812B2 (en) | 2017-03-31 | 2019-01-29 | Juniper Networks, Inc. | Multicast load balancing in multihoming EVPN networks |
BR112019026003A2 (pt) | 2017-06-13 | 2020-06-23 | Equinix, Inc. | Central de emparelhamento de serviços |
WO2019134067A1 (en) * | 2018-01-02 | 2019-07-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling device and method implemented thereon for ethernet virtual private network |
-
2019
- 2019-06-06 CN CN201910492933.XA patent/CN112054962B/zh active Active
-
2020
- 2020-05-17 WO PCT/CN2020/090725 patent/WO2020244372A1/zh unknown
-
2021
- 2021-12-03 US US17/541,465 patent/US12063153B2/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105337865A (zh) * | 2014-06-03 | 2016-02-17 | 华为技术有限公司 | 一种建立转发表项的方法、装置和系统 |
US9832031B2 (en) * | 2014-10-24 | 2017-11-28 | Futurewei Technologies, Inc. | Bit index explicit replication forwarding using replication cache |
US20160134535A1 (en) * | 2014-11-06 | 2016-05-12 | Juniper Networks, Inc. | Deterministic and optimized bit index explicit replication (bier) forwarding |
CN105991302A (zh) * | 2015-03-20 | 2016-10-05 | 瞻博网络公司 | 可靠传输上使用注册的多播流覆盖 |
CN106161258A (zh) * | 2015-03-25 | 2016-11-23 | 华为技术有限公司 | 用于传输组播协议报文的方法、设备及系统 |
CN109218178A (zh) * | 2017-07-05 | 2019-01-15 | 华为技术有限公司 | 一种报文处理方法及网络设备 |
Non-Patent Citations (3)
Title |
---|
HEYDARI, VAHID ET AL.: "Secure VPN using Mobile IPv6 based Moving Target Defense", 2016 IEEE GLOBAL COMMUNICATIONS CONFERENCE (GLOBECOM),, 8 December 2016 (2016-12-08), XP033058977, DOI: 20200803154653A * |
ROSEN, E. ET AL.: "Multicast in MPLS/BGP IP VPNs", IETF RFC:6513,, 29 February 2012 (2012-02-29), XP055765448, DOI: 20200803153410A * |
See also references of EP3968584A4 |
Also Published As
Publication number | Publication date |
---|---|
US12063153B2 (en) | 2024-08-13 |
EP3968584A4 (en) | 2022-06-29 |
CN112054962A (zh) | 2020-12-08 |
CN112054962B (zh) | 2021-12-14 |
EP3968584A1 (en) | 2022-03-16 |
US20220094626A1 (en) | 2022-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11381500B2 (en) | Efficient multicast traffic forwarding in EVPN-based multi-homed networks | |
Aggarwal et al. | BGP encodings and procedures for multicast in MPLS/BGP IP VPNs | |
US9860163B2 (en) | MPLS traffic engineering for point-to-multipoint label switched paths | |
US8339973B1 (en) | Multicast traceroute over MPLS/BGP IP multicast VPN | |
US9509609B2 (en) | Forwarding packets and PE devices in VPLS | |
US8111633B1 (en) | Multicast trees for virtual private local area network (LAN) service multicast | |
US8064440B2 (en) | Technique for avoiding IP lookup with multipoint-to-multipoint label switched paths | |
US8638788B2 (en) | Replication management for remote multicast replication network | |
EP3965368B1 (en) | Replication mode selection for multicast in evpn | |
WO2018077304A1 (zh) | 业务信息处理方法、装置及系统 | |
CN115118545B (zh) | 以太网虚拟专用网多播网络中的组管理协议主机移动性 | |
EP3883182A1 (en) | Evpn multicast ingress forwarder election using source-active route | |
CN106357541B (zh) | 一种信息传递方法和装置 | |
US12063153B2 (en) | Method and apparatus for implementing multicast | |
EP3968584B1 (en) | Method and apparatus for implementing multicasting | |
CN113630320A (zh) | 计算机网络内创建隧道的方法、入口网络装置及存储介质 | |
CN108512762B (zh) | 一种组播实现方法及装置 | |
US20240214292A1 (en) | Multicast tracing in hybrid networks | |
US20240195648A1 (en) | Optimal multicast forwarding for sources behind evpn fabric | |
Verrydt et al. | Study of IPv6 Multicast Deployment in MPLS Netw | |
Riaz | Multicast in MPLS Based Networks and VPNs | |
CN115051890A (zh) | 一种报文处理方法、系统、装置、电子设备及存储介质 | |
CN114726783A (zh) | 通告路由的方法、装置及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20818390 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2020818390 Country of ref document: EP Effective date: 20211207 |