WO2012003743A1 - 组播流量的转发方法及装置 - Google Patents

组播流量的转发方法及装置 Download PDF

Info

Publication number
WO2012003743A1
WO2012003743A1 PCT/CN2011/073941 CN2011073941W WO2012003743A1 WO 2012003743 A1 WO2012003743 A1 WO 2012003743A1 CN 2011073941 W CN2011073941 W CN 2011073941W WO 2012003743 A1 WO2012003743 A1 WO 2012003743A1
Authority
WO
WIPO (PCT)
Prior art keywords
path
multicast
primary
join message
multicast traffic
Prior art date
Application number
PCT/CN2011/073941
Other languages
English (en)
French (fr)
Inventor
白涛
于云福
陈刚
范树学
刘晖
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to ES11803097T priority Critical patent/ES2570747T3/es
Priority to EP11803097.2A priority patent/EP2592793B1/en
Publication of WO2012003743A1 publication Critical patent/WO2012003743A1/zh
Priority to US13/735,477 priority patent/US9019952B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • 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
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • 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
    • H04L45/06—Deflection routing, e.g. hot-potato 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/28—Routing or path finding of packets in data switching networks using route fault recovery

Definitions

  • BACKGROUND Fast Re-Route is a network fault-tolerant strategy, which can protect a link or a node, and can quickly switch when a link or a node fails, thereby minimizing packet loss.
  • the unicast IP FRR generates a preferred route (primary route) and a corresponding backup route for the IP routing protocol, so that when the primary path fails, the IP traffic can be switched to the alternate path for forwarding.
  • Multicast Protocol Independent Multicast (PIM) FRR is a unicast IP FRR or statically configured alternate path. When the primary path and the alternate path forward multicast traffic at the same time, the primary path fails. The broadcast traffic can be switched to the alternate path for forwarding.
  • the embodiment of the invention provides a method and a device for forwarding multicast traffic, which are used to solve the problem of waste of network bandwidth caused by the simultaneous forwarding of multicast traffic between the primary path and the alternate path in the prior art, and save network bandwidth.
  • the embodiment of the invention provides a method for forwarding multicast traffic, including:
  • the embodiment of the invention further provides a device for forwarding multicast traffic, including:
  • a receiving module configured to receive a third multicast join message
  • a first response module configured to send a first multicast join message to the first upstream routing device, and establish an active path, in response to the third multicast join message
  • a second response module configured to send a second multicast join message to the second upstream routing device, and establish an alternate path, in response to the third multicast join message
  • a sending module configured to send the multicast traffic to the multicast receiver by using the primary path, where the standby path does not forward the module, and is used to describe the multicast traffic.
  • the embodiment of the present invention pre-establishes an alternate path that does not forward multicast traffic, so that when the primary path fails, the multicast path can be forwarded by using the pre-established alternate path, because the alternate path is in the primary path.
  • multicast traffic is forwarded normally, multicast traffic is not forwarded, so it does not occupy double the network bandwidth, thus saving network bandwidth.
  • FIG. 1 is a schematic flowchart of a method for forwarding multicast traffic according to an embodiment of the present disclosure
  • FIG. 2A is a simplified schematic diagram of a network topology structure according to another embodiment of the present invention.
  • 2B is a schematic flowchart of a method for forwarding multicast traffic according to another embodiment of the present invention.
  • FIG. 3 is a schematic diagram of a network topology structure according to another embodiment of the present invention, which is a simplified schematic diagram of a typical ring network topology structure;
  • FIG. 4A is a simplified schematic diagram of a network topology structure according to still another embodiment of the present invention.
  • FIG. 4B is a schematic flowchart of a method for forwarding multicast traffic according to still another embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a multicast forwarding device according to an embodiment of the present disclosure.
  • FIG. 6 is a schematic structural diagram of a device for forwarding multicast traffic according to another embodiment of the present invention.
  • the technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention.
  • Embodiment It is a partial embodiment of the invention, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.
  • FIG. 1 is a schematic flowchart of a method for forwarding multicast traffic according to an embodiment of the present invention. As shown in FIG. 1, the method for forwarding multicast traffic in this embodiment may include:
  • the first multicast join message is sent to the first upstream routing device, and the primary path is established, in response to the third multicast join message.
  • the above method may further include:
  • the third multicast join message is received by the active node and the originating node of the alternate path.
  • the second upstream routing device is an intermediate node of the standby path, and the second upstream routing device continues to send the second group to the upstream routing device.
  • the broadcast join message ' for example, the second multicast join message' differs from the second multicast join message in that the address of the upstream neighbor routing device is different from the source address.
  • the difference between the second multicast join message and the second multicast join message further includes the primary path carried by the second multicast join message.
  • the information includes not only the primary path information carried in the second multicast join message but also the primary path information carried by other backup join messages.
  • the second upstream routing device updates the entry information, and carries the primary path information in all the backup multicast join messages to the second upstream routing device.
  • the upstream routing device sends a second multicast join message '.
  • the intermediate routing node needs to add the backup multicast to the message until it is sent to the root node of the multicast tree, such as a source-designated router (DR) or a rendezvous (RP), or until it is sent to the primary device.
  • DR source-designated router
  • RP rendezvous
  • the foregoing third multicast join message may be an Internet Group Management Protocol (IGMP) member report, and a multicast listener discovery (Multicast Listener). Discovery, MLD) Member reports, PIM join messages, and more.
  • IGMP Internet Group Management Protocol
  • MLD multicast listener discovery
  • PIM join messages and more.
  • the first multicast join message and the second multicast join message may be PIM join messages.
  • the foregoing second multicast join message may be a normal PIM join message; or may include the primary path information.
  • the primary path information is used to identify the primary inbound interface information of the primary path protected by the standby path, and may be an identifier of the primary ingress interface of the alternate path initiating node (for example, an IP address); or the primary ingress of the alternate path initiating node.
  • the primary path information identifies a primary ingress interface or a primary inbound interface list on the primary path protected by the alternate path.
  • the routing device on the alternate path After receiving the second multicast join message carrying the primary path information, the routing device on the alternate path records the primary path information, for example, on the outbound interface of the routing device on the alternate path.
  • the multicast traffic may be forwarded through the foregoing alternate path to implement path protection. For example, in some cases, if the number of primary inbound interfaces protected by the backup path is large, the primary path information carried in the backup join message will be too much, which will increase the burden on the routing device.
  • the update can be sent according to the incremental change of the primary path information in the PIM join message and the join message, instead of periodically sending, reducing the interaction of the message.
  • the first multicast join message may be a normal PIM join message.
  • the first multicast join message may carry the primary path information.
  • the standby path that does not forward the multicast traffic is established in advance, so that when the primary path fails, the multicast path can be forwarded by using the pre-established alternate path, because the alternate path does not forward the multicast traffic normally in the active path. Forwarding multicast traffic, so it does not occupy double the network bandwidth, thus saving network bandwidth.
  • the routing device RTD is an alternate path initiation point and is also an active path initiation point.
  • the routing device RTE is the upstream routing device of the RTD on the alternate path and is the intermediate node.
  • Routing Device The RTA is the upstream routing device of the RTE on the alternate path and is the terminating node of the alternate path.
  • Routing Device The RTC is the upstream routing device of the RTD on the primary path.
  • Routing Device RTB is the upstream routing device of the RTC on the primary path.
  • the routing device that terminates the node as the alternate path RTA is also on the primary path, and the RTA is the aggregation node of the primary path and the alternate path.
  • FIG. 2B is a schematic flowchart of a method for forwarding multicast traffic according to another embodiment of the present invention, where the method is based on the network topology shown in FIG. 2A.
  • the method for forwarding multicast traffic in this embodiment may include:
  • the RTD receives the third multicast join message, and sends the first multicast join message and the first multicast join message 'until the RTA;
  • the first multicast join message may be a normal PIM join message, and the primary path may be established according to the process in the prior art, and the multicast traffic is forwarded by using the primary path, and details are not described herein again.
  • the first multicast join message may carry a newly added attribute, such as the primary path information.
  • the difference between the first multicast join message and the first multicast join message includes that the upstream neighbor has different addresses of the device and the source address is different.
  • the RTD sends a second multicast join message to the RTE, where the second multicast join message includes the primary path information.
  • the primary path information includes an identifier of the primary inbound interface of the RTD, the RTC, and the RTB.
  • the second multicast join message which includes the primary path information, may be implemented in the PIM join message defined in the RFC 5384.
  • the join attribute may be included in the source address in the PIM join message.
  • the format of the above added attributes can be as follows:
  • Attr_Type identifies this attribute as a backup.
  • the flag is the content of this attribute. For example, you can use only one bit, and 1 means PIM backup join; Path Count identifies the number of Path ID; Path ID identifies the primary path.
  • the information which is the identifier of the primary inbound interface (for example, an IP address) of the multicast entry of the routing device corresponding to the primary path protected by the alternate path.
  • the routing device needs to negotiate with the neighbor to process the PIM backup join attribute before sending the PIM join message containing the backup join attribute.
  • the negotiation uses the periodic PIM Hellot message of the routing device. If the Hel lo message sent by the neighboring routing device does not include the Hel lo option of the PIM extended attribute, the PIM join message containing the added attribute is not sent.
  • the format of the Hel lo option of the above PIM extended attribute can be as follows:
  • the option type identifies this Hello option to add the attribute Hello option to the newly defined PIM backup;
  • the option length identifies the length of this Hello option.
  • the unit is byte.
  • the length of this hello option is currently fixed at 8 bytes.
  • the option value (OptionValue) is the reserved length of 8 bytes. It is currently unused and is set to 0 when sent.
  • the RTE determines that the multicast entry created by the second multicast join message is not received, and continues to send the second multicast join message containing the primary path information to the RTA, if the RTA determines that the second multicast is received.
  • a multicast entry created by adding a message does not continue to send multicast join messages to the upstream routing device.
  • the RTC can detect the upstream link fault through the fault detection technology, and learn the fault information of the active path.
  • the RTB can also detect the downstream link failure through the fault detection technology, and learn the fault information of the active path.
  • BFD Bidirectional Forwarding Detection
  • the RTC sends the fault information of the primary path according to the identifier of the primary ingress interface (for example, an IP address) corresponding to the faulty link, where the fault information includes the identifier of the primary inbound interface corresponding to the faulty link, that is, the foregoing alternate path.
  • the routing device RTD, RTE and RTA send the fault information of the above-mentioned main path;
  • the RTB sends the fault information of the primary path to the RTA on the standby path according to the identifier of the primary ingress interface (for example, an IP address) corresponding to the faulty link, and the fault information includes the downstream route corresponding to the faulty link.
  • ID of the primary inbound interface of the device that is, the identifier of the primary inbound interface of the remote routing device RTC.
  • the RTC or RTB sends the fault information of the above-mentioned main path to the routing devices RTD, RTE and RTA on the above alternate path.
  • the fault information of the primary path may be sent to the routing devices RTD, RTE, and RTA on the standby path by using any of the following A-C modes:
  • the RTC or the RTB floods the fault information of the primary path to the routing device in the entire network.
  • the fault information of the primary path can be flooded in the entire network through the interface configured with fault detection and transmission.
  • the routing device on the standby path has obtained the second multicast join message (backup join message).
  • the primary path information is used. Therefore, the backup outbound interface corresponding to the primary inbound interface is determined according to the identifier of the primary inbound interface corresponding to the faulty link included in the fault information, and the multicast outbound interface is forwarded through the backup outbound interface, thereby ensuring the fault chain.
  • the multicast traffic of the road can be forwarded from the alternate path.
  • the RTC sends the fault information of the primary path to the routing devices RTD, RTE, and RTA on the alternate path through all the primary outbound interfaces or the backup inbound interfaces in other network topologies according to the preset fault delivery policy.
  • the routing device to the fault information determines the corresponding backup outbound interface according to the primary inbound interface corresponding to the faulty link, and forwards the multicast traffic through the backup outbound interface.
  • routing rules for routing device RTC, RTD, RTE, and RTA to pass the above-mentioned primary path fault information can be as follows:
  • the fault is received from the primary inbound interface and the backup device has a backup inbound interface and the backup inbound interface fails to receive the fault, the fault is transmitted to the backup inbound interface. Otherwise, the fault is transmitted to all outbound interfaces.
  • the fault information is transmitted through the primary inbound interface and the outbound interface forwards the multicast traffic.
  • the fault information is received from the backup inbound interface, if the primary inbound interface does not receive the fault information, the fault information is transmitted. Otherwise, the fault information is transmitted through all the outbound interfaces.
  • the RTC sends fault information to the RTD through the primary outbound interface.
  • the fault information is transmitted to the RTE through the backup inbound interface.
  • the RTE receives the fault information from the backup outbound interface, opens the backup outbound interface that receives the fault information, forwards the traffic, and continues to pass the fault information to the RTA through the primary inbound interface on the alternate path.
  • the RTA opens the backup outbound interface that receives the fault information and forwards the traffic, and then continues to pass the primary inbound interface until it is delivered to the routing device directly connected to the source or to the primary outbound interface. Passing aborted.
  • the RTB sends the fault information of the primary path to the upstream through the primary inbound interface according to the preset fault transmission policy, so that the routing device RTA opens the backup outbound interface to forward the multicast traffic. .
  • the RTB sends the fault information to the RTA through the primary inbound interface according to the identifier of the faulty interface.
  • the RTA determines the corresponding backup outbound interface according to the identifier of the primary inbound interface carried in the fault information, and sends the multicast traffic through the backup outbound interface.
  • the routing device or the primary outgoing interface directly connected to the source For example, in the case that there are multiple routing devices directly connected to the source, when the fault information is transmitted to a routing device directly connected to the source, the fault information needs to be continuously transmitted to other routing devices directly connected to the source, and then opened. Back up the outbound interface.
  • the c mode is applicable to the scenario where the end node of the alternate path is also on the corresponding active path, or the end node applicable to the alternate path is also on the routing device directly connected to the source.
  • the backup path does not forward traffic if the backup outbound interface of the routing device of the alternate path termination point is not forwarded.
  • the transmission of the fault information can be implemented by extending the fault detection protocol.
  • the source address and the faulty interface that is, the identification information of the primary inbound interface can be added.
  • the BFD protocol is used as an example. :
  • Type is the type definition; Length is the length of the extension; Fault Indication is the cause of the fault, and is not currently used; Path ID is the identifier of the primary ingress interface of the downstream router of the faulty link; The RFC5880 standard is defined.
  • the RTD, the RTE, and the RTA forward the multicast stream by using the alternate path according to the learned fault information of the active path.
  • the rules for opening the backup outbound interface of the RTD, RTE, and RTA are as follows:
  • the fault information contains the identifier of the primary inbound interface corresponding to the faulty link, and finds all the multicast entries to determine the identity of the primary inbound interface.
  • the backup outbound interface forwards multicast traffic through the backup outbound interface. If the fault information does not contain any primary inbound interface identifier, all multicast backup outbound interfaces of all multicast entries are forwarded to forward multicast traffic.
  • the RTA forwards the multicast traffic through the backup outbound interface according to the learned fault information of the active path.
  • the RTE forwards the multicast traffic through the backup outbound interface according to the learned fault information of the active path.
  • the RTD receives the multicast traffic through the backup inbound interface according to the fault information of the learned primary path.
  • the RTD receives the multicast traffic through the primary ingress interface of the primary path. If the RTD does not receive the multicast traffic through the primary ingress interface of the primary path, the traffic received by the backup inbound interface is further forwarded. For example, if the link between the RTB and the RTC does not fail, but the fault information of other links in the network and the link identifier carrying the RTC master inbound interface is passed to the topology shown in Figure 2A, The multicast traffic is forwarded along the alternate path RTA-RTE-RTD. At this time, the RTD detects the multicast traffic of the backup inbound interface. However, if there is multicast traffic on the primary inbound interface, the switch does not perform the handover and routes to the alternate path. The device RTD, RTE, and RTA send prune messages and remove the alternate path to terminate the incorrectly forwarded backup traffic. After the delay, the backup path is re-established according to the method of the above embodiment.
  • the routing device sends a prune message, and the prune message sent carries the reduced primary path information to update the primary ingress interface information corresponding to the backup outbound interface. For example, if an alternate path is no longer needed, the sent prune message may not carry any primary path information.
  • the upstream routing device receives the prune message and removes the corresponding backup path.
  • FIG. 3 is a schematic diagram of a network topology structure according to still another embodiment of the present invention, which is a simplified schematic diagram of a typical ring network topology structure.
  • each routing device on the ring can receive the multicast join message.
  • the primary path (solid line identifier) can be used to forward multicast traffic.
  • the backup join message containing the added attribute is reversely transmitted to establish an alternate path. (dotted line).
  • the backup inbound interface of the alternate path origination point can be statically specified, or the backup inbound interface of the alternate path origination point can be generated according to the unicast IP FRR algorithm.
  • the backup path is from the initiating node of the backup path to the multicast root node or the main A sink node that uses a path and an alternate path.
  • the RTA learns that the primary outgoing interface is faulty and sends fault information to the upstream routing device.
  • the network topology in the example shown in Figure 3 is not connected to other routing devices because the RTA is not connected. description.
  • the RTB knows the fault information of the primary inbound interface, and sends a fault message to the primary path. For example, the fault information can be flooded to the entire network.
  • the fault information is transmitted along the RTC-RTD-RTE-RTF.
  • the fault information contains the primary inbound interface identifier of the RTB.
  • the RTB is set to forward traffic through the backup inbound interface to the RTC. After receiving the above fault information, the RTC senses that the RTB primary path is faulty.
  • the RTD receives the fault information, opens the backup outbound interface corresponding to the fault information, and forwards the traffic through the backup outbound interface.
  • the RTE receives the fault information. Since the backup that contains the RTB and RTC active path information is not added, the path switch is not performed.
  • the final multicast traffic is forwarded by the RTD to the RTC and then forwarded to the RTB.
  • FIG. 4A is a simplified schematic diagram of a network topology according to still another embodiment of the present invention.
  • the RTD and the RTE are alternate path initiation points.
  • the RTC is the upstream routing device of the RTD and RTE on the alternate path, which is the intermediate node of the alternate path.
  • the RTA is the routing device upstream of the RTC on the alternate path, which is the terminating node of the alternate path.
  • the RTB is the upstream routing device of the RTD and RTE on the primary path and is the intermediate node of the primary path.
  • the RTA is the upstream routing device of the RTB on the primary path, which is the root node of the primary path and the alternate path.
  • FIG. 4B is a schematic flowchart of a method for forwarding a multicast traffic according to another embodiment of the present invention. As shown in FIG. 4B, the method for forwarding multicast traffic in this embodiment may include:
  • the RTD receives the third multicast join message, and sends the first multicast join message and the first multicast join message ' to the IJ RTA;
  • the active path can be established according to the process in the prior art. For example, after receiving the multicast join message, the RTD and the RTE add the primary path information, such as the tree ID, to form a first multicast join message, and send the first multicast join to the upstream routing device. Message, establish the main path. Use the primary path to forward multicast traffic. The path establishment process will not be described here.
  • the main path established here is the main tree.
  • the RTD and the RTE send a second multicast join message to the RTC.
  • the second multicast join message may carry primary path information, such as an identifier (ID) of the tree.
  • ID an identifier
  • the foregoing second multicast join message including the primary path information may be implemented by using the RFC5384 specification to newly define a join attribute in the PIM join message.
  • the join attribute may be included in the source address in the PIM join message, and the FLAG identifies the message. Whether to join or not to join.
  • the format of the above added attributes can be as follows:
  • Attr_Type identifies this attribute as the PIM with the tree ID.
  • the flag is the content of this attribute. Currently, only one bit is used. 1 means PIM backup join, 0 means PIM master join message; Tree Count identifies Tree ID. Quantity; Tree ID identifies the primary tree information.
  • the routing device needs to negotiate with the neighbor to support the PIM join with the tree ID attribute before sending the PIM join message containing the join attribute.
  • the negotiation is performed by the periodic PIM Hello message of the routing device. If the Hello message sent by the neighboring routing device does not contain the Hello option of the PIM extended attribute, the PIM with the tree ID attribute will not be sent.
  • the format of the Hello option for the above PIM extension properties can be as follows:
  • option type identifies this Hello option to add the attribute Hello option to the newly defined PIM backup
  • Option length identifies the length of this Hello option, the unit For bytes, the length of this hello option is currently fixed at 8 bytes
  • the option value OptionValue is a reserved length of 8 bytes, which is currently unused and set to 0 when sent.
  • the tree ID attribute is the same as the backup added attribute structure mentioned in the previous method, and can be defined as an attribute.
  • the RTC determines that the multicast entry created by the second multicast join message is not received, and then continues to forward the second multicast join message to the RTA.
  • the RTA is the root node of the primary standby tree, and then does not continue upstream.
  • the routing device sends a multicast join message, and the outbound interface that receives the second multicast join message does not forward the multicast traffic.
  • the RTB can detect the fault of the downstream link by using the fault detection technology, and obtain the fault information of the active path.
  • the RTE can also detect the upstream link failure through the fault detection technology, and learn the fault information of the active path.
  • the RTB advertises the fault information of the active tree that includes the tree ID according to all the tree IDs carried in the join message received by the primary egress interface, that is, sends the fault of the active tree to the root node RTA of the active/standby tree. Information for the RTA to open the corresponding backup tree to forward multicast traffic;
  • the RTE advertises the fault information of the active tree that includes the tree ID according to all the tree IDs carried in the join message sent by the primary inbound interface, that is, sends the primary tree to the root node RTA of the active/standby tree. Fault information, for the RTA to open the corresponding backup tree to forward multicast traffic;
  • the fault information of the foregoing primary path may be sent to the root node RTA of the active/standby tree in multiple manners as follows:
  • A, RTE or RTB floods the above fault information to the routing device in the entire network
  • the fault information of the active path can be flooded in the entire network through the interface configured with fault detection and delivery until it is forwarded to the root node, that is, the routing device RTA.
  • the RTB transmits the fault along the root node of the active tree according to a preset fault delivery policy.
  • C. The RTE transmits the fault along the leaf direction of the active tree according to the preset fault delivery policy. After the fault reaches the leaf, the fault is transmitted to the root node along the backup tree.
  • the fault information transmission can be implemented by extending the fault detection protocol.
  • the source address and the path information can be added.
  • the BFD protocol is used as an example.
  • the protocol needs to be extended as follows:
  • Type is the type definition; Length is the extension part. Length; Fault Indicate is the cause of the fault and is not currently used; Tree ID identifies the primary tree information; other parts of the content encoding format are defined according to the RFC5880 standard.
  • the RTA forwards the multicast traffic by using the alternate path according to the learned fault information of the active path.
  • the standby path is a backup tree.
  • the RTA determines the corresponding backup outbound interface according to the tree ID carried in the fault information, and forwards the multicast traffic through the backup outbound interface.
  • the primary outbound interface stops forwarding multicast traffic.
  • the RTE and RTD are learned according to the knowledge.
  • the fault information of the active tree receives the multicast traffic through the backup inbound interface and forwards it downward.
  • the traffic received by the backup inbound interface continues to be forwarded downward.
  • FIG. 5 is a schematic structural diagram of a device for forwarding multicast traffic according to an embodiment of the present invention.
  • the device for forwarding multicast traffic in this embodiment may include a receiving module 51, a first response module 52, and a second response. Module 53 and transmitting module 54.
  • the receiving module 51 receives the third multicast join message
  • the first response module 52 sends a first multicast join message to the first upstream routing device in response to the third multicast join message, and establishes a primary path
  • the response module 53 sends a second multicast join message to the second upstream routing device in response to the third multicast join message, and establishes an alternate path
  • the sending module 54 sends the multicast traffic to the multicast through the primary path.
  • the receiver, the alternate path does not forward the module, and is used to describe the multicast traffic.
  • the foregoing method in the first embodiment of the present invention can be implemented by the multicast forwarding device provided by the embodiment of the present invention.
  • an alternate path that does not forward multicast traffic is established in advance through the second response module, because the alternate path is When the primary path forwards multicast traffic normally, it does not forward multicast traffic, so it does not occupy double the network bandwidth, thus saving network bandwidth.
  • FIG. 6 is a schematic structural diagram of a device for forwarding a multicast traffic according to another embodiment of the present invention. As shown in FIG. 6, the device for forwarding multicast traffic according to this embodiment may further include forwarding.
  • the module 61 is configured to forward the multicast traffic by using the standby path when the primary path fails.
  • the second response module pre-establishes an alternate path that does not forward the multicast traffic, so that when the primary path established by the first response module fails, the forwarding module can forward the multicast traffic by using the pre-established alternate path, due to the backup.
  • the path does not forward multicast traffic when the primary path forwards multicast traffic normally, so it does not occupy double the network bandwidth, thus saving network bandwidth.
  • the various specific solutions described in the foregoing method embodiments are applicable to the device embodiments, and are not described herein again.
  • a person skilled in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by using hardware related to program instructions, and the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the steps of the foregoing method embodiments are included; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例提供一种组播流量的转发方法及装置，方法包括：接收第三组播加入消息；响应所述第三组播加入消息，向第一上游路由设备发送第一组播加入消息，并建立主用路径；响应所述第三组播加入消息，向第二上游路由设备发送第二组播加入消息，并建立备用路径；通过所述主用路径发送组播流量到所述组播接收者，所述备用路径不转发所述组播流量。上述实施例通过预先建立不转发组播流量的备用路径，使得在主用路径发生故障时，能够利用预先建立的备用路径转发组播流量，由于备用路径在主用路径正常转发组播流量时不转发组播流量，所以不会占用双倍的网络带宽，从而可以节省网络带宽。

Description

组播流量的转发方法及装置 本申请要求于 2010年 7月 5日提交中国专利局、 申请号为 201010225833. X、 发明 名称为 "组播流量的转发方法及装置"的中国专利申请的优先权， 其全部内容通过引用 结合在本申请中。 技术领域 本发明实施例涉及通信技术， 尤其涉及一种组播流量的转发方法及装置。 背景技术 快速重路由 （Fast Re-Route， 简称 FRR)是一种网络容错策略， 它可以对链路或节 点进行保护， 当链路或节点发生故障时可迅速切换， 最大限度地减少报文丢失。 单播的 IP FRR为 IP路由协议生成优选路由 （主路由） 和相应的备份路由， 以便主用路径发生 故障时， IP 流量则可以切换到备用路径进行转发。 组播的协议无关组播 （Protocol Independent Multicast, 简称 PIM) FRR为利用单播的 IP FRR或者静态配置备用路径， 主用路径与备用路径同时转发组播流量， 以便主用路径发生故障时， 组播流量则可以切 换到备用路径进行转发。
在实现本发明过程中， 发明人发现现有技术中至少存在如下问题： 由于主用路径与 备用路径同时转发组播流量， 从而浪费了网络带宽。 发明内容
本发明实施例提供一种组播流量的转发方法及装置，用以解决现有技术中由于主用 路径与备用路径同时转发组播流量导致的网络带宽的浪费的问题， 节省网络带宽。
本发明实施例提供了一种组播流量的转发方法， 包括：
接收第三组播加入消息；
响应所述第三组播加入消息， 向第一上游路由设备发送第一组播加入消息， 并建立 主用路径；
响应所述第三组播加入消息， 向第二上游路由设备发送第二组播加入消息， 并建立 备用路径；
通过所述主用路径发送组播流量到所述组播接收者，所述备用路径不转发所述组播 流量。 本发明实施例还提供了一种组播流量的转发装置， 包括：
接收模块， 用于接收第三组播加入消息；
第一响应模块， 用于响应所述第三组播加入消息， 向第一上游路由设备发送第一组 播加入消息， 并建立主用路径；
第二响应模块， 用于响应所述第三组播加入消息， 向第二上游路由设备发送第二组 播加入消息， 并建立备用路径；
发送模块， 用于通过所述主用路径发送组播流量到所述组播接收者， 所述备用路径 不转发所模块， 用于述组播流量。
由上述技术方案可知， 本发明实施例通过预先建立不转发组播流量的备用路径， 使 得在主用路径发生故障时， 能够利用预先建立的备用路径转发组播流量， 由于备用路径 在主用路径正常转发组播流量时不转发组播流量， 所以不会占用双倍的网络带宽， 从而 节省了网络带宽。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有 技术描述中所需要使用的附图作一简单地介绍， 显而易见地， 下面描述中的附图是本发 明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动的前提下， 还可 以根据这些附图获得其他的附图。
图 1为本发明实施例提供的组播流量的转发方法的流程示意图；
图 2A为本发明另一实施例提供的网络拓扑结构简化示意图；
图 2B为本发明另一实施例提供的组播流量的转发方法的流程示意图；
图 3为本发明又一实施例网络拓扑结构示意图，为典型的环网拓扑结构简化示意图； 图 4A为本发明再一实施例提供的网络拓扑结构简化示意图；
图 4B为本发明再一实施例提供的组播流量的转发方法的流程示意图；
图 5为本发明实施例提供的组播流量的转发装置的结构示意图；
图 6为本发明另一实施例提供的组播流量的转发装置的结构示意图。 具体实施方式 为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发明实施例中 的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例 是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技 术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范 围。
图 1为本发明实施例提供的组播流量的转发方法的流程示意图， 如图 1所示， 本实 施例的组播流量的转发方法可以包括：
101、 接收第三组播加入消息；
102、 响应上述第三组播加入消息， 向第一上游路由设备发送第一组播加入消息， 并建立主用路径；
103、 响应上述第三组播加入消息， 向第二上游路由设备发送第二组播加入消息， 并建立备用路径；
104、 通过上述主用路径发送组播流量到上述组播接收者， 上述备用路径不转发上 述组播流量。
上述方法还可以包括：
105、 当上述主用路径发生故障时， 通过上述备用路径转发上述组播流量。
举例来说， 上述方法中接收第三组播加入消息的是主用路径和备用路径的发起节 点。
举例来说， 若第二上游路由设备不存在对应的组播表项， 则第二上游路由设备是备 用路径的中间节点，上述第二上游路由设备则继续向其上游的路由设备发送第二组播加 入消息' ， 举例来说， 第二组播加入消息' 与第二组播加入消息的区别包括上游邻居路 由设备的地址不同和源地址不同。 再举例来说， 当第二上游路由设备还是其他备用路径 的中间节点时，第二组播加入消息' 与第二组播加入消息的区别还包括第二组播加入消 息' 携带的主用路径信息不仅包括第二组播加入消息携带的主用路径信息，还包括其他 备份加入报文携带的主用路径信息。若第二上游路由设备存在因为收到其他备份组播加 入消息而建立的表项， 则上述第二上游路由设备更新表项信息， 携带所有备份组播加入 消息中的主用路径信息， 向其上游的路由设备发送第二组播加入消息' 。 举例来说， 中 间路由节点需要将备份组播加入消息直至发送到组播树的根节点，例如源指定路由设备 (Designated Router, DR) 或集合点 ( Rendezvous , RP)， 或者直至发送到主用路径和 备用路径的汇聚节点。
举例来说， 上述第三组播加入消息可以为互联网组管理协议 （Internet Group Management Protocol , IGMP ) 成员报告、 组播监听者发现 ( Multicast Listener Discovery, MLD) 成员报告、 PIM加入报文等。 举例来说， 上述第一组播加入消息和第 二组播加入消息可以是 PIM加入报文。
举例来说， 上述第二组播加入消息可以是普通的 PIM加入报文； 也可以包含主用路 径信息。 主用路径信息用于标识上述备用路径所保护的主用路径的主入接口信息， 可以 是备用路径发起节点的主入接口的标识 （例如： IP地址）； 或者是备用路径发起节点的 主入接口的标识与其上游的一个或多个路由设备的主入接口的标识组成的标识列表。其 中， 上述标识列表可以静态配置， 还可以通过其他途径获取。 上述主用路径信息标识备 用路径所保护的主用路径上的主入接口或主入接口列表。备用路径上的路由设备接收到 携带主用路径信息的第二组播加入消息后， 记录该主用路径信息， 举例来说， 可以记录 在备用路径上路由设备的出接口上。当第二组播加入消息中包含的任意一个主入接口的 标识对应的主入接口故障， 则可以通过上述备用路径转发组播流量从而实现路径保护。 举例来说， 在某些情况下， 若备用路径保护的主入接口数量很大， 会导致备份加入报文 中携带的主用路径信息太多， 从而加重路由设备的负担， 对于这种问题， 可以根据 PIM 加入报文以及加入报文中的主用路径信息变化增量发送更新， 而不是周期性发送， 减少 报文的交互。
举例来说， 上述第一组播加入消息可以是普通的 PIM加入报文。 又例如， 第一组播 加入消息可以携带上述主用路径信息。
上述实施例通过预先建立不转发组播流量的备用路径， 使得在主用路径发生故障 时， 能够利用预先建立的备用路径转发组播流量， 由于备用路径在主用路径正常转发组 播流量时不转发组播流量， 所以不会占用双倍的网络带宽， 从而可以节省网络带宽。
图 2A为本发明另一实施例提供的网络拓扑结构简化示意图， 路由设备 RTD是备用 路径发起点， 也是主用路径发起点。 路由设备 RTE是备用路径上 RTD的上游路由设备， 是中间节点。路由设备 RTA是备用路径上 RTE的上游路由设备，是备用路径的终止节点。 路由设备 RTC是主用路径上 RTD的上游的路由设备。路由设备 RTB是主用路径上 RTC的 上游路由设备。 作为备用路径终止节点的路由设备 RTA也在主用路径上， RTA是主用路 径和备用路径的汇聚节点。 图 2B为本发明另一实施例提供的组播流量的转发方法的流 程示意图， 该方法基于图 2A所示的网络拓扑。 如图 2B所示， 本实施例的组播流量的转 发方法可以包括：
201〜206、 RTD接收第三组播加入消息， 发送第一组播加入消息和第一组播加入消 息' 直到 RTA; 举例来说， 第一组播加入消息可以是普通的 PIM加入报文， 可以按照现有技术中的 流程， 建立主用路径， 利用主用路径转发组播流量， 此处不再赘述。 再举例来说， 第一 组播加入消息可以携带新增加入属性， 例如主用路径信息。 举例来说， 第一组播加入消 息' 和第一组播加入消息的区别包括上游邻居有设备的地址不同和源地址不同。
209、 RTD向 RTE发送第二组播加入消息， 第二组播加入消息包含主用路径信息， 举 例来说， 主用路径信息包含 RTD、 RTC、 RTB的主入接口的标识；
上述包含主用路径信息的第二组播加入消息可以在 RFC5384定义的 PIM加入报文中 新定义一个加入属性实现， 上述加入属性可以包含于 PIM加入报文中的源地址中。 上述 加入属性的格式可以如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F I E Attr— Type | Length | Flags | Path Count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 其中， 标志位 F、 标志位 E、 属性类型 （Attr— Type)、 长度 （Length ) 都使用协议 标准定义， 此处不再赘述。 Attr— Type标识此属性为备份加入； 标志位 Flags为此属性 的内容， 举例来说， 可以只使用一位， 由 1代表 PIM备份加入； Path Count标识 Path ID 的数量； Path ID标识主用路径信息， 一般为备用路径所保护的主用路径对应的路由设 备的组播表项主入接口的标识 （例如： IP地址）。
举例来说， 根据 RFC5384规范定义， 路由设备在发送包含备份加入属性的 PIM加入 报文之前， 需要先与邻居协商是否支持处理 PIM备份加入属性。 此协商采用路由设备周 期性的 PIM Hel lo报文， 若邻居路由设备发送的 Hel lo报文中不包含此 PIM扩展属性的 Hel lo选项， 则不继续发送包含加入属性的 PIM加入报文。 上述 PIM扩展属性的 Hel lo 选项的格式可以如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Opt ionType | Opt ionLength +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionValue
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 举例来说， 选项类型 （OptionType)标识此 Hello选项为新定义的 PIM备份加入属 性 Hello选项； 选项长度 （OptionLength)标识此 Hello选项的长度， 单位为字节， 目 前此 hello选项的长度固定为 8个字节； 选项数值 （OptionValue) 为 8个字节的预留 长度， 目前暂未使用， 发送时设置为 0。
211、 RTE判断不存在收到第二组播加入消息创建的组播表项，则继续向 RTA发送包 含主用路径信息的第二组播加入消息' ，如果 RTA判断存在收到第二组播加入消息而创 建的组播表项， 则不再继续向上游的路由设备发送组播加入消息。
至此， 上述备用路径建立完毕。 主用路径正常 （未出现故障） 的情况下， 上述备用 路径上的路由设备均不通过备份接口转发组播流量。
213、当 RTB与 RTC之间的链路发生故障， RTC可以通过故障检测技术检测到上游链 路故障， 获知主用路径的故障信息；
可替换地， 当 RTB与 RTC之间的链路发生故障， RTB也可以通过故障检测技术检测 到下游链路故障， 获知主用路径的故障信息。 举例来说， 可以采用双向转发检测 (Bidirectional Forwarding Detection, 简称 BFD) 技术检测链路故障。
215、 RTC根据故障链路对应的主入接口的标识（例如： IP地址）， 发送主用路径的 故障信息， 故障信息中包含故障链路对应的主入接口的标识， 即向上述备用路径上的路 由设备 RTD、 RTE和 RTA发送上述主用路径的故障信息；
可替换地， RTB根据故障链路对应的主入接口的标识 （例如： IP地址）， 向上述备 用路径上的 RTA发送上述主用路径的故障信息，故障信息中包含故障链路对应的下游路 由设备的主入接口的标识， 即对端路由设备 RTC的主入接口的标识。
RTC或 RTB向上述备用路径上的路由设备 RTD、RTE和 RTA发送上述主用路径的故障 信息。
本步骤中，可以通过如下 A-C方式中的任意一种方式向上述备用路径上的路由设备 RTD、 RTE和 RTA发送上述主用路径的故障信息：
A、 RTC或 RTB向整个网络中的路由设备泛洪上述主用路径的故障信息； 举例来说，主用路径的故障信息可以在通过配置了故障检测与传递的接口在整网中 泛洪， 由于备用路径上的路由设备之前获取到了第二组播加入消息 （备份加入报文） 中 的主用路径信息， 因此可以根据故障信息中包含的故障链路对应的主入接口的标识， 确 定该主入接口对应的备份出接口， 通过该备份出接口转发组播流量， 这样保证故障链路 的组播流量能够从备用路径转发。
B、 RTC根据预先设置的故障传递策略， 通过所有主出接口， 或者在其他网络拓扑中 是备份入接口，发送上述主用路径的故障信息到备用路径上的路由设备 RTD、RTE和 RTA, 接收到故障信息的路由设备根据故障链路对应的主入接口确定对应的备份出接口，通过 该备份出接口转发组播流量。
举例来说， 考虑到各种不同的网络拓扑结构， 路由设备 RTC、 RTD、 RTE和 RTA传递 上述主用路径的故障信息的传递规则可以如下所示：
若从主入接口接收到故障信息，且路由设备存在备份入接口且备份入接口没有收到 过故障， 则将故障向备份入接口传递， 否则故障向所有出接口传递；
若从备份出接口接收到故障信息， 则通过主入接口传递故障信息， 同时备份出接口 转发组播流量。
若从主出接口收到故障信息， 不处理， 故障信息的传递中止。
若从备份入接口收到故障信息， 若主入接口没有收到故障信息， 故障信息的传递中 止， 否则通过所有出接口传递故障信息。
举例来说， RTC通过主出接口向 RTD传递故障信息； RTD从主入接口收到故障信息， 且存在备份入接口， 则通过备份入接口向 RTE传递故障信息。 RTE从备份出接口收到故 障信息， 打开收到故障信息的备份出接口并转发流量， 继续通过备用路径上的主入接口 向 RTA传递故障信息。 RTA从备份出接口收到故障信息以后， 打开收到故障信息的备份 出接口并转发流量， 继续通过主入接口向上传递， 直到传递到与源直连的路由设备或传 递到主出接口， 故障传递中止。
C、 RTB根据预先设置的故障传递策略，通过主入接口向上游发送上述主用路径的故 障信息， 以供备用路径与主用路径的汇聚点， 即路由设备 RTA打开备份出接口转发组播 流量。
举例来说， RTB根据故障接口的标识， 通过主入接口向 RTA发送故障信息， RTA根 据故障信息中携带的主入接口的标识确定对应的备份出接口，通过该备份出接口发送组 播流量。 可选地， 然后继续朝入接口方向传递直到与源直连的路由设备或者主出接口。 举例来说， 对于存在多个与源直连的路由设备的情况， 当故障信息传递到一个与源直连 的路由设备，需要将此故障信息继续传递到其他与源直连的路由设备，打开备份出接口。 c方式适用于备用路径的终节点也在对应的主用路径上的场景， 或者适用于备用路 径的终节点也在与源直连的路由设备上的场景。这种场景下，在主用路径未发生故障时， 可选地， 如果只使得备用路径终止点的路由设备的备份出接口不转发流量， 也可以实现 备用路径不转发流量。
举例来说，上述各种例子中，发送故障信息传递可以通过扩展故障检测协议来实现， 可以增加源地址以及故障接口即主入接口的标识信息， 以 BFD协议为例， 协议需要扩展 如下所示：
+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
I Vers I Diag | Sta | P | F | C | A | D | M | Detect Mult | Length |
+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
My Discriminator |
+_+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
Your Discriminator |
+_+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
Desired Min TX Interval |
+_+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
Required Min RX Interval |
+_+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
Required Min Echo RX Interval |
+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
I Type I Length | Fault Indication |
+_+_+_+_+_+_+- -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+
Path ID I
+_+_+_+_+_+_+_+— -+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+ 其中， 通过定义 BFD报文的新的版本号 （在 Vers字段） 或 M比特来标识这是一个 扩展 BFD 报文。 在消息体中， Type 为类型定义； Length 为扩展部分的长度； Fault Indication为故障原因， 目前暂未使用； Path ID表示故障链路的下游路由器的主入接 口的标识； 其他部分内容编码格式根据 RFC5880标准定义。
217、 RTD、 RTE和 RTA根据获知的主用路径的故障信息， 利用备用路径转发组播流 举例来说， RTD、 RTE和 RTA的备份出接口打开的规则是： 由于故障信息中包含故障 链路对应的主入接口的标识，查找所有的组播表项确定对应该主入接口的标识的备份出 接口， 通过该备份出接口转发组播流量； 若故障信息中没有包含任何主入接口的标识， 则打开所有组播表项的所有组播备份出接口转发组播流量。
举例来说， RTA根据获知的主用路径的故障信息， 通过备份出接口转发组播流量。
RTE根据获知的主用路径的故障信息， 通过备份出接口转发上述组播流量。 RTD根据获 知的主用路径的故障信息， 通过备份入接口接收上述组播流量。
可选地， 判断 RTD是否通过主用路径的主入接口接收组播流量， 若 RTD未通过主用 路径的主入接口接收组播流量，则继续将备份入接口接收到的流量向下转发。举例来说， 若 RTB与 RTC之间的链路没有发生故障，而是网络中其他链路的故障信息并且携带了 RTC 主入接口的链路标识传递到图 2A 所示的拓扑中， 也会导致组播流量沿备用路径 RTA-RTE-RTD转发， 此时 RTD检测到备份入接口的组播流量， 但是主入接口还存在组播 流量， 则可以不进行切换， 并向备用路径上的路由设备 RTD、 RTE和 RTA发送剪枝报文， 拆除备用路径， 可以及时终止错误转发的备份流量。 延时之后， 根据上述实施例的方法 重新建立备份路径。
举例来说， 若是保护的主入接口减少， 则路由设备发送剪枝报文， 发送的剪枝报文 中携带减少的主用路径信息， 以更新备份出接口对应的主入接口信息。 又例如， 若是不 再需要某一备用路径， 则发送的剪枝报文可以不携带任何主用路径信息。 上游路由设备 收到上述剪枝报文， 拆除对应的备份路径。
图 3为本发明又一实施例网络拓扑结构示意图，为典型的环网拓扑结构简化示意图。 正常情况下， 环上的每个路由设备都可以收到组播加入消息， 可以利用主用路径（实线 标识）转发组播流量； 并逆向传递包含加入属性的备份加入报文， 建立备用路径 （虚线 标识）。 举例来说， 可以静态指定备用路径发起点的备份入接口， 也可以根据单播的 IP FRR算法生成备用路径发起点的备份入接口， 备份路径从备份路径的发起节点到组播根 节点或主用路径与备用路径的汇聚节点。 当环上 RTA与 RTB之间的链路发生故障， RTA 获知主出接口故障，向上游路由设备发送故障信息，图 3所示示例的网络拓扑中由于 RTA 没有与其他路由设备相连， 后面不再描述。 RTB获知主入接口的故障信息， 发送通知主 用路径的故障信息， 举例来说， 可以向整个网络泛洪故障信息。 故障信息沿 RTC-RTD-RTE-RTF传递， 故障信息中包含了 RTB的主入接口标识。 RTB设置为可以通过 朝 RTC的备份入接口转发流量。 RTC接收到上述故障信息后， 感知 RTB主用路径故障， 打开朝 RTB的备份出接口， 同时发现故障信息中的主入接口标识为自己到组播源的路径 上的一个主入接口， 设置为可以通过朝 RTD的备份入接口转发流量。 RTD接收到故障信 息， 打开故障信息对应的备份出接口， 通过该备份出接口转发流量。 RTE接收到故障信 息， 由于没有收到包含 RTB、 RTC主用路径信息的备份加入， 所以不进行路径倒换。 最 终组播流量由 RTD转发给 RTC, 然后转发给 RTB。
图 4A为本发明再一实施例提供的网络拓扑结构简化示意图， RTD、 RTE是备用路径 发起点。 RTC即备用路径上 RTD、 RTE的上游路由设备， 是备用路径的中间节点。 RTA即 备用路径上 RTC上游的路由设备， 是备用路径的终止节点。 RTB即主用路径上 RTD、 RTE 的上游路由设备， 是主用路径的中间节点。 RTA即主用路径上 RTB的上游的路由设备， 是主用路径和备用路径的根节点。 举例来说， 根节点可以是主备树的聚合点， 或者与源 直连的路由设备， 再或者由用户指定。 图 4B为本发明再一实施例提供的组播流量的转 发方法的流程示意图， 如图 4B所示， 本实施例的组播流量的转发方法可以包括：
40广 403、 RTD、 RTE接收第三组播加入消息， 发送第一组播加入消息和第一组播加 入消息' 至 IJ RTA;
举例来说， RTD、 RTE接收到第三组播加入消息之后， 可以按照现有技术中的流程， 建立主用路径。 再举例来说， RTD、 RTE接收组播加入消息后， 新增主用路径信息， 例如 树的标识 （Tree ID), 形成第一组播加入消息， 并向上游路由设备发送第一组播加入消 息， 建立主用路径。 利用主用路径转发组播流量。 路径建立过程此处不再赘述。 这里建 立的主用路径是主用树。
404、 RTD、 RTE向 RTC发送第二组播加入消息。
举例来说， 第二组播加入消息可以携带主用路径信息， 例如树的标识 （ID)。
上述包含主用路径信息的第二组播加入消息可以利用 RFC5384规范在 PIM加入报文 中新定义一个加入属性实现， 上述加入属性可以包含于 PIM加入报文中的源地址中， 由 FLAG标识此加入是否为主备加入。 上述加入属性的格式可以如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F I E Attr Type | Length | Flags | Tree Count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tree ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tree ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 举例来说， 标志位 F、 标志位 E、 属性类型 （Attr— Type)、 长度 （Length) 都使用 协议标准定义， 此处不再赘述。 Attr— Type标识此属性为包含树 ID的 PIM加入； 标志位 Flags为此属性的内容， 目前只使用一位， 由 1代表 PIM备份加入， 0代表 PIM主加入 报文； Tree Count标识 Tree ID的数量； Tree ID标识主用树信息。
举例来说， 根据 RFC5384规范定义， 路由设备在发送包含加入属性的 PIM加入报文 之前， 需要先与邻居协商是否支持处理包含树 ID属性的 PIM加入。 此协商是通过路由 设备周期性的 PIM Hello报文来识别的， 若邻居路由设备发送的 Hello报文中不包含此 PIM扩展属性的 Hello选项，则不继续发送包含树 ID属性的 PIM加入。上述 PIM扩展属 性的 Hello选项的格式可以如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionType | OptionLength
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OptionValue
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 其中，选项类型（OptionType)标识此 Hello选项为新定义的 PIM备份加入属性 Hello 选项； 选项长度（OptionLength)标识此 Hello选项的长度， 单位为字节， 目前此 hello 选项的长度固定为 8个字节； 选项数值 （OptionValue) 为 8个字节的预留长度， 目前 暂未使用， 发送时设置为 0。
举例来说： 树 ID属性与前面方法提到的备份加入属性结构是一致的， 可以统一定 义成一个属性。
405、 RTC判断不存在收到第二组播加入消息创建的组播表项，则继续向 RTA转发第 二组播加入消息' ， RTA为主备树的根节点， 则不再继续向上游的路由设备发送组播加 入消息， 并且收到第二组播加入消息' 的出接口不转发组播流量；
至此， 上述备用路径建立完毕。 主用路径正常 （未出现故障） 的情况下， 上述备用 路径上的路由设备均不通过备份接口转发组播流量。
406、当 RTB与 RTE之间的链路发生故障， RTB可以通过故障检测技术检测到下游链 路故障， 获知主用路径的故障信息； 可替换地， 当 RTB与 RTE之间的链路发生故障， RTE也可以通过故障检测技术检测 到上游链路故障， 获知主用路径的故障信息。
407、 RTB根据主出接口收到的加入报文中携带的所有树 ID， 发布包含此树 ID的主 用树的故障信息， 即向上述主备树的根节点 RTA发送上述主用树的故障信息， 以供 RTA 打开对应的备份树转发组播流量；
可替换地， RTE根据主入接口发送的加入报文中携带的所有树 ID,发布包含此树 ID 的主用树的故障信息， 即向上述主备树的根节点 RTA发送上述主用树的故障信息， 以供 RTA打开对应的备份树转发组播流量；
举例来说，可以通过如下多种方式向上述主备树的根节点 RTA发送上述主用路径的 故障信息：
A、 RTE或 RTB向整个网络中的路由设备泛洪上述故障信息；
这种方案中，主用路径的故障信息可以在通过配置了故障检测与传递的接口在整网 中泛洪， 直到转发给根节点， 即路由设备 RTA。
B、 RTB根据预先设置的故障传递策略， 将故障沿着主用树的根节点方向传递。 C, RTE根据预先设置的故障传递策略， 将故障沿主用树的叶子方向传递， 故障到达 叶子以后， 故障再沿着备份树传递给根节点。
举例来说， 上述故障信息传递可以通过扩展故障检测协议来实现， 可以增加源地址 以及路径信息， 以 BFD协议为例， 协议需要扩展如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers | Diag Sta | P | F | C | A | D | M Detect Mult | Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
My Discriminator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Your Discriminator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Desired Min TX Interval
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Required Min RX Interval
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Required Min Echo RX Interval +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type I Length | Fault Indicat ion
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tree ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 其中， 版本号 （Vers ion ) 标识版本， 由于扩展了 BFD报文， 因此需要新定义版本 号； Type为类型定义； Length为扩展部分的长度； Fault Indicat ion为故障原因， 目 前暂未使用； Tree ID标识主用树信息； 其他部分内容编码格式根据 RFC5880标准定义。
408、 RTA根据获知的主用路径的故障信息， 利用备用路径转发组播流量， 这里， 备 用路径是备用树。
举例来说， RTA接收到故障信息后，根据故障信息中携带的树 ID确定对应的备份出 接口， 通过备份出接口转发组播流量， 主出接口停止转发组播流量， RTE、 RTD根据获知 的主用树的故障信息， 通过备份入接口接收上述组播流量且向下转发。可选地， 若 RTE、 RTD未通过主入接口接收组播流量时， 继续将备份入接口接收到的流量向下转发。
需要说明的是： 对于前述的各方法实施例， 为了简单描述， 故将其都表述为一系列 的动作组合， 但是本领域技术人员应该知悉， 本发明并不受所描述的动作顺序的限制， 因为依据本发明， 某些步骤可以采用其他顺序或者同时进行。 其次， 本领域技术人员也 应该知悉， 说明书中所描述的实施例均属于优选实施例， 所涉及的动作和模块并不一定 是本发明所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分， 可以参见其他实施例的相关描述。
图 5为本发明实施例提供的组播流量的转发装置的结构示意图， 如图 5所示， 本实 施例的组播流量的转发装置可以包括接收模块 51、 第一响应模块 52、 第二响应模块 53 和发送模块 54。其中， 接收模块 51接收第三组播加入消息， 第一响应模块 52响应所述 第三组播加入消息， 向第一上游路由设备发送第一组播加入消息， 并建立主用路径， 第 二响应模块 53响应所述第三组播加入消息， 向第二上游路由设备发送第二组播加入消 息， 并建立备用路径， 发送模块 54通过所述主用路径发送组播流量到所述组播接收者， 所述备用路径不转发所模块， 用于述组播流量。
上述本发明实施例一中方法可以由本发明实施例提供的组播流量的转发装置实现。 本实施例通过第二响应模块预先建立不转发组播流量的备用路径， 由于备用路径在 主用路径正常转发组播流量时不转发组播流量， 所以不会占用双倍的网络带宽， 从而节 省了网络带宽。
图 6为本发明另一实施例提供的组播流量的转发装置的结构示意图， 如图 6所示， 与上一实施例相比，本实施例的组播流量的转发装置还可以进一步包括转发模块 61，用 于当所述主用路径发生故障时， 通过所述备用路径转发所述组播流量。
本实施例通过第二响应模块预先建立不转发组播流量的备用路径，使得在第一响应 模块建立的主用路径发生故障时， 转发模块能够利用预先建立的备用路径转发组播流 量， 由于备用路径在主用路径正常转发组播流量时不转发组播流量， 所以不会占用双倍 的网络带宽， 从而节省网络带宽。
上述方法实施例中描述的各种具体方案均适用于装置实施例， 此处不再赘述。 本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤可以通过程 序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读取存储介质中， 该程序 在执行时， 执行包括上述方法实施例的步骤； 而前述的存储介质包括： R0M、 RAM, 磁碟 或者光盘等各种可以存储程序代码的介质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其限制； 尽管 参照前述实施例对本发明进行了详细的说明， 本领域的普通技术人员应当理解： 其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换； 而这些修改或者替换， 并不使相应技术方案的本质脱离本发明各实施例技术方案的 精神和范围。

Claims

权利要求
1、 一种组播流量的转发方法， 其特征在于， 包括：
接收第三组播加入消息；
响应所述第三组播加入消息， 向第一上游路由设备发送第一组播加入消息， 并建立 主用路径；
响应所述第三组播加入消息， 向第二上游路由设备发送第二组播加入消息， 并建立 备用路径；
通过所述主用路径发送组播流量到组播接收者， 所述备用路径不转发所述组播流
2、 根据权利要求 1所述的方法， 其特征在于， 还包括： 当所述主用路径发生故障 时， 通过所述备用路径转发所述组播流量。
3、 根据权利要求 2所述的方法， 其特征在于， 所述第二组播加入消息包含用于标 识所述备用路径所保护的主用路径的主入接口信息的主用路径信息，所述当所述主用路 径发生故障时，通过所述备用路径转发所述组播流量包括：当所述主用路径发生故障时， 备用路径上的路由设备根据获取到的主用路径的故障信息中携带的主入接口的标识，确 定对应的备份出接口， 通过所述备份出接口转发所述组播流量。
4、 根据权利要求 2所述的方法， 其特征在于， 所述第二组播加入消息包含用于标 识所述备用路径所保护的主用路径的树的标识的主用路径信息，所述当所述主用路径发 生故障时， 通过所述备用路径转发所述组播流量包括： 当所述主用路径发生故障时， 备 用路径上的根节点路由设备根据获取到的主用路径的故障信息中携带的树的标识，确定 对应的备份出接口， 通过所述备份出接口转发所述组播流量。
5、 一种组播流量的转发装置， 其特征在于， 包括：
接收模块， 用于接收第三组播加入消息；
第一响应模块， 用于响应所述第三组播加入消息， 向第一上游路由设备发送第一组 播加入消息， 并建立主用路径；
第二响应模块， 用于响应所述第三组播加入消息， 向第二上游路由设备发送第二组 播加入消息， 并建立备用路径；
发送模块， 用于通过所述主用路径发送组播流量到组播接收者， 所述备用路径不转 发所述组播流量。
6、 根据权利要求 5所述的装置， 其特征在于， 还包括转发模块， 用于当所述主用 路径发生故障时， 通过所述备用路径转发所述组播流量。
7、 根据权利要求 6所述的方法， 其特征在于， 所述第二组播加入消息包含用于标 识所述备用路径所保护的主用路径的主入接口信息的主用路径信息，所述当所述主用路 径发生故障时，通过所述备用路径转发所述组播流量包括：当所述主用路径发生故障时， 备用路径上的路由设备根据获取到的主用路径的故障信息中携带的主入接口的标识，确 定对应的备份出接口， 通过所述备份出接口转发所述组播流量。
8、 根据权利要求 6所述的方法， 其特征在于， 所述第二组播加入消息包含用于标 识所述备用路径所保护的主用路径的树的标识的主用路径信息，所述当所述主用路径发 生故障时， 通过所述备用路径转发所述组播流量包括： 当所述主用路径发生故障时， 备 用路径上的根节点路由设备根据获取到的主用路径的故障信息中携带的树的标识，确定 对应的备份出接口， 通过所述备份出接口转发所述组播流量。
PCT/CN2011/073941 2010-07-05 2011-05-11 组播流量的转发方法及装置 WO2012003743A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES11803097T ES2570747T3 (es) 2010-07-05 2011-05-11 Método y equipo para reenviar tráfico de multidifusión
EP11803097.2A EP2592793B1 (en) 2010-07-05 2011-05-11 Method and apparatus for forwarding multicast traffic
US13/735,477 US9019952B2 (en) 2010-07-05 2013-01-07 Method and apparatus for forwarding multicast traffic

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010225833.XA CN102316016B (zh) 2010-07-05 2010-07-05 组播流量的转发方法及装置
CN201010225833.X 2010-07-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/735,477 Continuation US9019952B2 (en) 2010-07-05 2013-01-07 Method and apparatus for forwarding multicast traffic

Publications (1)

Publication Number Publication Date
WO2012003743A1 true WO2012003743A1 (zh) 2012-01-12

Family

ID=45428849

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/073941 WO2012003743A1 (zh) 2010-07-05 2011-05-11 组播流量的转发方法及装置

Country Status (5)

Country Link
US (1) US9019952B2 (zh)
EP (1) EP2592793B1 (zh)
CN (1) CN102316016B (zh)
ES (1) ES2570747T3 (zh)
WO (1) WO2012003743A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013179164A1 (en) * 2012-06-01 2013-12-05 Telefonaktiebolaget L M Ericsson (Publ) Enhancements to pim fast re-route with upstream activation packets
US8824276B2 (en) 2012-06-01 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) Increasing failure coverage of MOFRR with dataplane notifications
US9628285B2 (en) 2012-06-01 2017-04-18 Telefonaktiebolaget L M Ericsson (Publ) Increasing failure coverage of MoFRR with dataplane notifications
WO2022017432A1 (zh) * 2020-07-22 2022-01-27 华为技术有限公司 组播报文的发送方法、装置和***

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8867552B2 (en) 2010-05-03 2014-10-21 Brocade Communications Systems, Inc. Virtual cluster switching
US9769016B2 (en) 2010-06-07 2017-09-19 Brocade Communications Systems, Inc. Advanced link tracking for virtual cluster switching
US9807031B2 (en) 2010-07-16 2017-10-31 Brocade Communications Systems, Inc. System and method for network configuration
CN102136965B (zh) * 2010-12-24 2013-12-04 华为技术有限公司 一种隧道故障检测方法和流量工程节点
US9071546B2 (en) * 2011-05-20 2015-06-30 Cisco Technology, Inc. Protocol independent multicast designated router redundancy
CN102315951B (zh) 2011-09-19 2015-05-27 华为技术有限公司 一种组播报文的传输方法、相关设备及***
CN102932248A (zh) * 2012-10-29 2013-02-13 中兴通讯股份有限公司 多源组播路径备份方法及装置、汇聚点
US9882713B1 (en) 2013-01-30 2018-01-30 vIPtela Inc. Method and system for key generation, distribution and management
US9565099B2 (en) 2013-03-01 2017-02-07 Brocade Communications Systems, Inc. Spanning tree in fabric switches
JP6052044B2 (ja) * 2013-04-30 2016-12-27 富士通株式会社 パケットトランスポートネットワークシステム
US10142254B1 (en) * 2013-09-16 2018-11-27 Cisco Technology, Inc. Service chaining based on labels in control and forwarding
US9467478B1 (en) 2013-12-18 2016-10-11 vIPtela Inc. Overlay management protocol for secure routing based on an overlay network
US9548873B2 (en) 2014-02-10 2017-01-17 Brocade Communications Systems, Inc. Virtual extensible LAN tunnel keepalives
US10581758B2 (en) 2014-03-19 2020-03-03 Avago Technologies International Sales Pte. Limited Distributed hot standby links for vLAG
US10476698B2 (en) 2014-03-20 2019-11-12 Avago Technologies International Sales Pte. Limited Redundent virtual link aggregation group
US9800471B2 (en) 2014-05-13 2017-10-24 Brocade Communications Systems, Inc. Network extension groups of global VLANs in a fabric switch
US10616108B2 (en) 2014-07-29 2020-04-07 Avago Technologies International Sales Pte. Limited Scalable MAC address virtualization
US9807007B2 (en) 2014-08-11 2017-10-31 Brocade Communications Systems, Inc. Progressive MAC address learning
CN105610708B (zh) * 2014-10-31 2019-11-12 新华三技术有限公司 一种trill网络中组播frr的实现方法和rb设备
US9651984B2 (en) * 2014-12-15 2017-05-16 Cisco Technology, Inc. Feed-forward time transfer mechanism for time synchronization
US10579406B2 (en) 2015-04-08 2020-03-03 Avago Technologies International Sales Pte. Limited Dynamic orchestration of overlay tunnels
CN104901893B (zh) * 2015-06-11 2018-05-11 新华三技术有限公司 组播流量保护方法及装置
US10439929B2 (en) * 2015-07-31 2019-10-08 Avago Technologies International Sales Pte. Limited Graceful recovery of a multicast-enabled switch
US10171303B2 (en) 2015-09-16 2019-01-01 Avago Technologies International Sales Pte. Limited IP-based interconnection of switches with a logical chassis
US9980303B2 (en) 2015-12-18 2018-05-22 Cisco Technology, Inc. Establishing a private network using multi-uplink capable network devices
US10237090B2 (en) 2016-10-28 2019-03-19 Avago Technologies International Sales Pte. Limited Rule-based network identifier mapping
CN109428814B (zh) * 2017-09-04 2022-12-02 中兴通讯股份有限公司 一种组播流量传输方法、相关设备和计算机可读存储介质
CN109474520B (zh) * 2017-09-07 2022-07-08 中兴通讯股份有限公司 组播vpn网络的流量转发方法、pe及组播vpn网络
CN110661628B (zh) * 2018-06-30 2021-12-14 华为技术有限公司 一种实现数据组播的方法、装置和***
US11050658B2 (en) * 2018-09-14 2021-06-29 Cisco Technology, Inc. IOAM-based quality of experience propagation to endpoints and seamless switchover to alternate call path
US11296899B2 (en) 2019-02-28 2022-04-05 Cisco Technology, Inc. Redundant multicast trees without duplication and with fast recovery
CN112134776B (zh) * 2019-06-25 2022-08-26 华为技术有限公司 生成组播转发表项的方法和接入网关
CN110351148A (zh) * 2019-07-21 2019-10-18 汪勤思 一种网络三层转发路径诊断方法和***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101094175A (zh) * 2007-06-14 2007-12-26 华为技术有限公司 一种组播流量保护方法、装置及***
CN101163103A (zh) * 2007-11-07 2008-04-16 孙先花 一种实现快速重路由的方法
CN101656679A (zh) * 2009-09-25 2010-02-24 华为技术有限公司 一种组播快速收敛方法、路由器和通信***
CN101669105A (zh) * 2007-04-26 2010-03-10 思科技术公司 多播快速重新路由

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60234665D1 (de) * 2001-06-21 2010-01-21 Sk Telecom Co Ltd Verfahren zur Bestimmung des Weges in einem Netzwerk mit Mehrfachprotokoll Etikettvermittlung
JP4728209B2 (ja) * 2006-12-05 2011-07-20 アラクサラネットワークス株式会社 マルチキャストネットワーク冗長化システム
US7719959B2 (en) * 2007-04-20 2010-05-18 Cisco Technology, Inc. Achieving super-fast convergence of downstream multicast traffic when forwarding connectivity changes between access and distribution switches
CN101335695B (zh) * 2007-06-27 2012-11-07 华为技术有限公司 点到多点标签交换路径的头节点保护方法、装置和设备
US7684316B2 (en) 2008-02-12 2010-03-23 Cisco Technology, Inc. Multicast fast reroute for network topologies
US8526300B2 (en) 2008-03-31 2013-09-03 Ericsson Ab Method and apparatus for providing resiliency in multicast networks
US8462621B2 (en) * 2009-07-27 2013-06-11 At&T Intellectual Property I, L.P. Systems and methods of multicast reconfiguration using cross-layer information

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101669105A (zh) * 2007-04-26 2010-03-10 思科技术公司 多播快速重新路由
CN101094175A (zh) * 2007-06-14 2007-12-26 华为技术有限公司 一种组播流量保护方法、装置及***
CN101163103A (zh) * 2007-11-07 2008-04-16 孙先花 一种实现快速重路由的方法
CN101656679A (zh) * 2009-09-25 2010-02-24 华为技术有限公司 一种组播快速收敛方法、路由器和通信***

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2592793A4 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013179164A1 (en) * 2012-06-01 2013-12-05 Telefonaktiebolaget L M Ericsson (Publ) Enhancements to pim fast re-route with upstream activation packets
US8824276B2 (en) 2012-06-01 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) Increasing failure coverage of MOFRR with dataplane notifications
US8913482B2 (en) 2012-06-01 2014-12-16 Telefonaktiebolaget L M Ericsson (Publ) Enhancements to PIM fast re-route with upstream activation packets
US9197547B2 (en) 2012-06-01 2015-11-24 Telefonaktiebolaget L M Ericsson (Publ) Increasing failure coverage of MoFRR with dataplane notifications
US9628285B2 (en) 2012-06-01 2017-04-18 Telefonaktiebolaget L M Ericsson (Publ) Increasing failure coverage of MoFRR with dataplane notifications
US9736061B2 (en) 2012-06-01 2017-08-15 Telefonaktiebolaget L M Ericsson (Publ) Enhancements to PIM fast re-route with upstream activation packets
WO2022017432A1 (zh) * 2020-07-22 2022-01-27 华为技术有限公司 组播报文的发送方法、装置和***

Also Published As

Publication number Publication date
EP2592793A4 (en) 2013-08-07
CN102316016B (zh) 2014-12-31
CN102316016A (zh) 2012-01-11
ES2570747T3 (es) 2016-05-20
EP2592793B1 (en) 2016-02-24
US20130121142A1 (en) 2013-05-16
EP2592793A1 (en) 2013-05-15
US9019952B2 (en) 2015-04-28

Similar Documents

Publication Publication Date Title
WO2012003743A1 (zh) 组播流量的转发方法及装置
US8218429B2 (en) Method and device for multicast traffic redundancy protection
US8638787B2 (en) Multicast hello on demand
US7778204B2 (en) Automatic maintenance of a distributed source tree (DST) network
EP3035592B1 (en) Enhanced protocol independent multicast source registration over a reliable transport
EP2996287A1 (en) Method for notifying information of pe device and pe device
CN109150580B (zh) 协议无关多播加入熵
EP2498454A1 (en) Method, device and system for processing service traffic based on pseudo wires
EP2601766B1 (en) System and method for virtual private local area network service to use the flow aware pseudowire
WO2009056034A1 (fr) Procédé, système et équipement pour établir une détection bfd pour un tunnel lsp
WO2011035699A1 (zh) 一种组播快速收敛方法、路由器和通信***
WO2006099784A1 (fr) Procédé de détection d’un défaut de liaison entre des noeuds d’une extrémité à l’autre dans un réseau hybride
CN102638389A (zh) 一种trill网络的冗余备份方法及***
WO2012075831A1 (zh) 一种实现组播保护的方法及***
WO2009146622A1 (zh) 实现组播的方法、路由器及***
WO2011160498A1 (zh) 运营管理和维护的配置方法和节点
WO2020001389A1 (zh) 一种避免环路的通信方法、设备和***
WO2022021818A1 (zh) 数据报文的处理方法及装置、存储介质、电子装置
WO2010006524A1 (zh) 可靠组播的方法、运营商边缘上层设备及***
WO2014169856A1 (zh) 一种组播通信方法和汇聚交换机
EP2394390B1 (en) Method for using a computer network
WO2008125675A1 (en) Method for operating a network element and according device as well as communication system comprising such device
US9948474B2 (en) Network system, packet transmission apparatus, packet transmission method, and recording medium recording information processing program
WO2020168982A1 (zh) 一种发送和获取断言报文的方法和网络节点
WO2016082516A1 (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: 11803097

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011803097

Country of ref document: EP