WO2012083844A1 - 传输组播数据的方法、组播树的更新方法以及系统和装置 - Google Patents

传输组播数据的方法、组播树的更新方法以及系统和装置 Download PDF

Info

Publication number
WO2012083844A1
WO2012083844A1 PCT/CN2011/084296 CN2011084296W WO2012083844A1 WO 2012083844 A1 WO2012083844 A1 WO 2012083844A1 CN 2011084296 W CN2011084296 W CN 2011084296W WO 2012083844 A1 WO2012083844 A1 WO 2012083844A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
mag
mode
source
handover
Prior art date
Application number
PCT/CN2011/084296
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 JP2013545027A priority Critical patent/JP2014502116A/ja
Priority to US13/995,851 priority patent/US9265029B2/en
Priority to EP11850637.7A priority patent/EP2658296B1/en
Publication of WO2012083844A1 publication Critical patent/WO2012083844A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H04W36/026—Multicasting of data during hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover

Definitions

  • the present invention relates to the field of mobile communications technologies, and in particular, to a method for transmitting multicast data, a method for updating a multicast tree, and a system and apparatus.
  • Background Art In recent years, the maturity of wireless technologies has led more and more people to connect to networks through wireless devices, and hopes to be able to access the network anytime and anywhere. Supporting mobile communication has become an inevitable requirement for network development. A large amount of research has focused on how the network provides support for mobile. Among them, IETF (Internet Engineering Task Force, Internet Engineering Task Force) PMIPv6 (Proxy Mobile IPv6) acts as a kind of The local mobility management technology transfers the mobility management function from the terminal side to the network side. The network is responsible for managing IP mobility on behalf of the host.
  • the mobile entity in the network is responsible for tracking the movement of the host and initializing the required mobile signal transmission.
  • PMIPv6 realizes the IP (Internet Protocol) mobility of the host without requiring the host to participate in any mobility-related signal transmission, thereby greatly reducing the burden on the terminal and facilitating centralized control.
  • Multicast is a point-to-multipoint information transmission method that requires data to be simultaneously transmitted from one source node to multiple destination nodes.
  • the destination node constitutes a specific set of nodes, called groups or groups.
  • multicast technology has the advantages of high network utilization, reduced network congestion, resource saving, and scalability, it has played a big role in new network applications such as video conferencing, file distribution, real-time information distribution, and IP TV. effect.
  • a typical mobile IPTV (Interactive Personality TV) application a large number of users can obtain audio/video stream data distributed by the network through multicast technology.
  • the traditional multicast protocol is based on a fixed network and wired communication methods, which cannot meet the mobility requirements.
  • the mobile multicast architecture not only handles dynamic changes in the location of mobile hosts, but also handles dynamically changing group memberships in multicast groups.
  • the multicast architecture in the mobile environment needs to meet the following requirements: Ensure seamless continuity of multicast conversations when switching nodes; Ensure optimal routing of data packets; Support flow switching in multicast communication (different flows have Different characteristics and identification); Avoid multicast solution specialization (only support multicast, not support unicast); Can handle packet loss, duplicate copy; Multicast data stream dynamically adapts to current network Condition (adjust the transmission rate, etc.); easy to deploy; speed up the convergence speed of routing protocols, etc.
  • the IETF working group is still in the initial stage of research on supporting multicast source mobility, and proposes a scheme to support multicast source mobility in PMIPv6.
  • This scheme proposes a method of RPT (Rendezvous Point Tree, Support Shared Tree) and SPT (Shortest Path Tree) in PMIPv6.
  • the scheme proposes to use the LM A (Local Mobility Anchor) as the RP (Rendezvous Point) to reply to the join message sent by the multicast receiving node when the multicast data is transmitted in the RPT mode.
  • the multicast data is sent by the multicast source to the LMA, and then forwarded by the LMA to the multicast receiving node through the multicast tree.
  • the shortest path tree between the LMA and the multicast receiving node does not need to be re-established, and the multicast tree is stable.
  • this mode introduces a large delay and network burden.
  • Step 101 Establish a link between the mobile access gateway MAG1 and the multicast source MN.
  • Step 102 After determining that the multicast source MN is connected, the MAG1 sends the extended PBU message to the LMA to establish a bidirectional tunnel between the MAG1 and the LM A.
  • step 102 after receiving the PBU message, the LMA parses the extended information included in the PUB message and returns the multicast join message.
  • Step 103 The multicast data is sent by the multicast source MN to the LMA according to the basic manner defined in PMIPv6.
  • an SPT is established between the LMA and the multicast receiving node, and the multicast data is transmitted between the LMA and the multicast receiving node according to the multicast routing protocol.
  • Step 104 The multicast source MN moves to the MAG2, and the multicast source MN sends the multicast related information to the MAG2 through the RS message.
  • Step 105 Update the bidirectional tunnel between the LMA and the MAG2.
  • the process of updating the bidirectional tunnel between the LMA and the MAG2 does not affect the SPT between the LMA and the multicast receiver.
  • the multicast source MN switches, the multicast data continues to be transmitted.
  • the movement of the multicast source has no effect on the multicast receiver.
  • the solution proposes that when the multicast data is transmitted by using the SPT mode, the multicast source replies to the join message sent by the multicast receiving node, and directly establishes the shortest path multicast tree from the multicast source to the multicast receiving node, and the multicast data is multicast.
  • the source is sent directly to the multicast receiving node through the established multicast tree.
  • the network delay is relatively small, but it causes the router to overburden the storage and the multicast tree is unstable.
  • multicast The tree needs to be updated frequently.
  • Step 201 Establish a link between the MAG1 and the multicast source MN.
  • Step 202 After determining that the multicast source MN is connected, the MAG1 sends the extended PBU message to the LMA to establish a bidirectional tunnel between the MAG1 and the LM A.
  • the LMA parses the extended information included in the PBU message, but does not reply to the multicast join message.
  • Step 203 The multicast data is sent by the multicast source MN to the LMA according to the basic manner defined in the PMIPv6.
  • step 203 when the LMA redirects the multicast join message to the multicast source MN, the SPT between the multicast source and the multicast receiving node starts to be established, and the next multicast data is grouped according to the optimized path. Transmission between the broadcast source and the multicast receiving node.
  • Step 204 After the multicast source MN moves to the MAG2, the multicast source MN sends the multicast related information to the MAG2 through the RS message.
  • Step 205 Update a bidirectional tunnel between the LMA and the MAG2.
  • step 205 when updating the bidirectional tunnel between the LMA and the MAG2, the SPT between the multicast source and the multicast receiving node needs to be updated because the root node of the multicast tree moves to a different location.
  • the SPT is used to establish a shortest path multicast tree between the multicast source and the multicast receiving node.
  • the RPT is used as the aggregation node, and the shortest path multicast tree is established between the LMA and the multicast receiving node.
  • a disadvantage of the prior art is that the fast switching of the multicast source cannot be supported.
  • the multicast source has a large delay when switching between two MAGs in the PMIPv6 domain.
  • the existing solution stipulates that when the multicast source moves from the old MAG (that is, the MAGI) to the new MAG (that is, the MAG2), a series of processes such as binding update and authentication between the multicast source and the MAG2 are required.
  • the multicast tree reconstruction process also needs to be performed. After these processes are completed, the multicast data can be distributed, which will cause the multicast service to be interrupted for a long time. Due to the one-to-many nature of multicast services, the switching delay of the multicast source will affect all users in the group.
  • an embodiment of the present invention provides a method for transmitting multicast data, a method for updating a multicast tree, and a system.
  • the system and the device reduce the delay of the multicast service interruption caused by the switching between the multicast source and the mobile access gateway, and ensure the real-time performance of the multicast service in the PMIPv6 system.
  • a method for transmitting multicast data including:
  • the first mobile access gateway MAG receives a handover advance message sent by the multicast source before the first MAG is switched to the second MAG; the handover notice message carries the identifier information of the second MAG;
  • the first MAG establishes a bidirectional tunnel with the second MAG according to the identifier of the second MAG carried in the handover notice message;
  • a method for updating a multicast tree including:
  • the Join message is generated for generating the multicast tree, and the address information of the second MAG carried in the data packet is carried in the Join message.
  • the second multicast node that receives the Join message updates the multicast route according to the address information of the second MAG carried in the Join message, and continues to forward the Join message until the group has been updated according to the address information of the second MAG.
  • the multicast node after the broadcast is received by the multicast node.
  • a system for transmitting multicast data including:
  • a multicast source a first mobile access gateway MAG, and a second MAG;
  • the multicast source is used to send a handover notice message to the first MAG before being switched from the currently accessed first MAG to the second MAG; the handover notice message carries the identifier information of the second MAG ;
  • the first MAG is configured to establish a bidirectional tunnel with the second MAG according to the identifier of the second MAG that is carried in the handover advance message sent by the multicast source, and according to the determined switch group
  • the broadcast mode and the established two-way tunnel, the multicast data from the multicast source is multicast, wherein the post-switching multicast mode is a group that is used after the multicast source is switched to the second MAG. Broadcast mode.
  • an apparatus for transmitting multicast data including:
  • the handover notice message receiving unit is configured to receive a handover notice message sent before the multicast source switches from the currently accessed first mobile access gateway MAG to the second MAG, where the handover notice message carries the identifier information of the second MAG ;
  • a tunnel establishing unit configured to establish a bidirectional tunnel with the second MAG according to the identifier of the second MAG carried in the handover notice message received by the handover notice message receiving unit;
  • a multicast data transmission unit configured to multicast multicast data from the multicast source according to the determined post-switching multicast mode and the bidirectional tunnel established by the tunnel establishing unit, where the handover multicast Mode is the multicast source Switching to the multicast mode used after the second MAG.
  • a multicast tree update system including:
  • a first multicast node configured to receive a data packet sent by the first mobile access gateway MAG, and after determining that the data packet carries a multicast source switching indication, construct a join message for generating a multicast tree, and The address information of the second MAG carried in the data packet is carried in the Join message;
  • the second multicast node is configured to receive the Join message forwarded by the first multicast node, update the multicast route according to the address information of the second MAG carried in the Join message, and continue to forward the Join message until The multicast node that updates the multicast route according to the address information of the second MAG receives the Join message.
  • the first MAG receives the handover advance notice message that is sent by the multicast source and includes the second MAG identifier, and establishes the second MAG identifier according to the second MAG identifier included in the handover notice message.
  • the handover advertisement message is sent before the multicast source is switched from the currently accessed first MAG to the second MAG, and the binding update is performed between the multicast source and the second MAG by establishing a bidirectional tunnel in advance.
  • the first MAG can transmit multicast data through the established bidirectional tunnel, thereby reducing the multicast service interruption delay caused by the switching of the multicast source between the MAGs, and ensuring the multicast in the PMIPv6 system. Real-time and continuity of business.
  • FIG. 1 is a flowchart of switching a multicast source into a ⁇ domain in an RPT mode provided by the prior art
  • FIG. 2 is a flow chart of switching a multicast source into a ⁇ domain in an SPT mode provided by the prior art
  • FIG. 3 is a flowchart of a method for transmitting multicast data according to Embodiment 1 of the present invention.
  • FIG. 4 is a flowchart of establishing a bidirectional tunnel between MAG1 and MAG2 according to Embodiment 1 of the present invention
  • FIG. 5 is a schematic diagram of a basic message format of an HI message defined in the prior art
  • FIG. 6 is a schematic diagram of a basic message format of an extended HI message according to Embodiment 1 of the present invention.
  • FIG. 7 is a schematic diagram of a format of a multicast source switching option according to Embodiment 1 of the present invention.
  • FIG. 8 is a schematic diagram of a basic message format of a HAck message defined in the prior art
  • FIG. 9 is a schematic diagram of a message format of an extended HAck message according to Embodiment 1 of the present invention
  • FIG. 10 is a flowchart of transmitting multicast data in an RPT mode according to Embodiment 1 of the present invention
  • FIG. 11 is a flowchart of an SPT according to Embodiment 1 of the present invention and does not update multicast data in a multicast tree mode
  • FIG. 12 is a schematic diagram of transmitting STP in a SPT and a multicast tree pre-update mode according to Embodiment 1 of the present invention
  • FIG. 13 is a schematic diagram of a multicast tree when a multicast source is moved from an access point 1 to an access point 2 according to Embodiment 1 of the present invention
  • FIG. 14 is a multicast tree update according to Embodiment 1 of the present invention.
  • FIG. 15 is a flowchart of updating a multicast route according to Embodiment 1 of the present invention.
  • FIG. 16 is a schematic diagram of a format of an IPv6 hop-by-hop option header according to Embodiment 1 of the present invention.
  • FIG. 17 is a schematic diagram of a format of a multicast source switching option according to Embodiment 1 of the present invention.
  • FIG. 18 is a flowchart of further updating a multicast router according to Embodiment 1 of the present invention.
  • FIG. 19 is a first schematic diagram of an apparatus for transmitting multicast data according to Embodiment 2 of the present invention.
  • FIG. 20 is a second schematic diagram of an apparatus for transmitting multicast data according to Embodiment 2 of the present invention.
  • FIG. 21 is a third schematic diagram of an apparatus for transmitting multicast data according to Embodiment 2 of the present invention.
  • FIG. 22 is a schematic diagram of a system for transmitting multicast data according to Embodiment 3 of the present invention.
  • FIG. 23 is a schematic diagram of a multicast tree update system according to Embodiment 4 of the present invention.
  • the present invention provides a method for transmitting multicast data, a method for updating a multicast tree, a system, and a device, in order to provide an implementation solution for ensuring real-time and continuity of multicast services in a PMIPv6 system.
  • the preferred embodiments of the present invention are described with reference to the accompanying drawings, and the preferred embodiments described herein are intended to illustrate and explain the invention. And in the case of no conflict, the features of the embodiments and the embodiments in the present application can be combined with each other.
  • the first embodiment of the present invention first provides a method for transmitting multicast data, which can solve the problem that the multicast interrupt is too long when the mobile multicast source switches between two MAGs in the PMIPv6 system, so as to achieve For the purpose of restoring the multicast service in a small time delay, the first embodiment of the present invention further provides a method for updating a multicast tree, which solves the problem of pre-updating the SPT when the multicast source moves in the PMIPv6. Under the premise that the broadcast receiver is transparent, the purpose of pre-updating the SPT before the completion of the multicast source switching is achieved.
  • the present invention can be applied to the scenario in which the multicast source MN is switched in the same PMIPv6 system. For example, the multicast source MN is moved from the currently accessed MAG1 to the MAG2 in the same PMIPv6 domain.
  • the post-switching multicast mode in the embodiment of the present invention.
  • the multicast mode after the handover is the multicast source MN.
  • the embodiments of the present invention provide three types of post-switching multicast modes, and the three types of post-switching multicast modes are:
  • the multicast source MN uses the RPT mode to transmit multicast data when accessing MAG1. That is, the LMA is used as the RP.
  • the multicast data is first sent to the LMA and then transmitted by the LMA to each multicast receiver.
  • the RPT mode is still required. That is, the multicast mode used after the multicast source MN accesses MAG2 is RPT mode. In this mode, MAG1 needs to pass the RP address to MAG2. MAG2 needs to construct a path to the RP.
  • the multicast data can be forwarded through the bidirectional tunnel established between the MAG1 and the MAG2, that is, the multicast data is sent to the multicast receiver.
  • the path that the multicast receives when receiving the node is:
  • Source ⁇ MAG2 ⁇ LMA (RP) ⁇ Multicast tree is transmitted to the multicast receiving node.
  • the multicast source MN accesses MAG1, it uses SPT mode to transmit multicast data. If the multicast source MN moves faster (for example, greater than the set threshold), the multicast source MN switches to MAG2. After that, the SPT mode needs to continue to transmit multicast data, but the multicast tree does not need to be updated.
  • the post-switching multicast mode is called SPT and does not update the multicast tree mode.
  • the bidirectional tunnel between the MAG1 and the MAG2 can be forwarded, that is, the multicast data is before and after the multicast source establishes a connection with the MAG2 and completes the binding update process.
  • the path that is sent to the multicast receiving node corresponding to the multicast receiver is:
  • the tunnel between the MAG1 and the MAG2 is not revoked as the multicast source establishes a connection with the MAG2 and the binding update is completed.
  • the data sent by the multicast source to the outside world is always passed.
  • the bidirectional tunnel is transmitted to the multicast receiving node. ⁇ This mode can reduce the frequent demolition and construction of the multicast tree caused by the switching between the MAGs and the MNs, so as to avoid waste of network resources and improve multicast forwarding efficiency.
  • the multicast source MN uses the SPT mode to transmit multicast data when accessing the MAG1. If the multicast source moves at a slower speed (for example, not greater than the set threshold), the multicast source MN switches to the MAG2. After that, the SPT mode needs to continue to transmit multicast data. In this case, the multicast tree needs to be pre-updated.
  • the post-switching multicast mode is called SPT and the multicast tree pre-update mode. Style.
  • the pre-updating process of the multicast tree mainly includes: MAG1 carries a multicast source switching option in the multicast data packet, and the option includes the multicast source switching indication and the address of the MAG2.
  • the multicast source option notifies the router in the multicast tree of the upcoming multicast source switchover and the translated MAG2 address, thereby triggering the multicast tree.
  • the old multicast tree refers to a multicast path established by the multicast source MN to transmit multicast data when it accesses MAG1.
  • the multicast data is sent to the multicast receiving node through the new multicast tree.
  • the new multicast tree refers to a multicast path established by the multicast source MN to transmit multicast data when it accesses MAG2.
  • the multicast data can be forwarded through the bidirectional tunnel established between MAG1 and MAG2, that is, the multicast data is sent to
  • the path that the multicast receiver receives when receiving the multicast receiver is:
  • Source ⁇ MAG2 ⁇ MAGl ⁇ Multicast Tree (old multicast tree).
  • the path that the multicast data is sent to the multicast receiver corresponding to the multicast receiver is:
  • Source ⁇ MAG2 ⁇ Multicast Tree new multicast tree.
  • the method for transmitting multicast data provided in Embodiment 1 of the present invention is as shown in FIG. 3, which mainly includes the following steps, based on the post-switching multicast mode and the corresponding data transmission path.
  • Step 301 The MAG1 receives the handover advertisement message sent by the MN from the currently accessed MAG1 to the MAG2, and the handover notice message carries the identifier information of the MAG2.
  • Step 302 The MAG1 establishes a bidirectional relationship with the MAG2 according to the identifier of the MAG2 carried in the handover notice message! 3 ⁇ 4 way.
  • Step 303 Multicast multicast data from the multicast source according to the determined post-switching multicast mode and the established bidirectional tunnel.
  • the specific mode of transmitting the multicast data in the step 303 is different according to the determined mode of the multicast mode after the handover. The process will be described in detail in the following embodiments, and will not be described here.
  • the above-mentioned process is mainly applied to the scenario in which the multicast source MN transmits multicast data when the MAG needs to be switched due to the mobile requirement. Specifically, when the multicast source MN needs to be switched from the MAG1 to the MAG2, a bidirectional tunnel needs to be established between the MAG1 and the MAG2.
  • the process of establishing the bidirectional tunnel is as shown in FIG. 4, which mainly includes the following steps:
  • Step 401 Before the handover occurs, the multicast source MN is connected to the MAG1, and the multicast data is transmitted according to the used multicast mode.
  • the multicast data is transmitted in the RPT mode, the multicast data is sent by the multicast source MN to the MAG1, and then transmitted to the LMA (the LMA is used as an RP convergence point) and forwarded by the LMA to the multicast receiver;
  • the multicast data is transmitted in the SPT mode, and the multicast data is directly forwarded by the multicast source to the multicast receiver according to the established SPT.
  • Step 402 The multicast source MN determines that the handover is to be performed, and reports the ID of the multicast source MN to the MAG1 and the step 402 of the MAG2.
  • the multicast source MN determines that the handover is about to occur, that is, determines that the MAG1 that is currently accessed is to be switched to the MAG2. That is, the multicast source MN moves from the coverage area of the network where MAG1 is located to the coverage area of the network where MAG2 is located.
  • Step 403 The MAG1 sends an extended HI message (Handover Initiate Message) to the MAG2.
  • the HI message sent by the MAG1 includes the indication information of the multicast source switching, the multicast source identifier, the indication information of the multicast mode after the handover, the multicast group address, and the multicast source home address. Further, when the multicast mode indicated by the HI message is in the RPT mode, the HI message further includes an RP address.
  • Step 404 After receiving the HI message, the MAG2 sends a HAck message (Handover Acknowledge Message) to the MAG1.
  • a HAck message (Handover Acknowledge Message)
  • the HAck message includes an indication of whether the MAG2 accepts the multicast source handover.
  • MAG2 may reject multicast source switching due to local policies, non-multicast source switching, and heavy load. If MAG2 agrees to the multicast source switchover, a bidirectional tunnel between MAG1 and MAG2 is established.
  • the MAG2 may update the HI message included in the HI message according to the RP address sent by the HI message.
  • the pre-update of the multicast path between the MAG2 and the LMA further shortens the multicast delay caused by the multicast source switching MAG.
  • the HI message and the HAck message involved in the foregoing process are extended messages, and the following describes the extension manner of the HI message and the HAck message.
  • the extended HI message of the present invention adds an indication bit for indicating that the current handover is a multicast handover and is a multicast source handover.
  • the extended HI message also contains the identity of the multicast source MN and an extended Mobility options.
  • the mobility options include: a post-switching multicast mode selection bit (corresponding to RPT mode, SPT and not updating the multicast tree mode and SPT and one of the multicast tree pre-update modes), multicast group address (optional), RP address ( Optional), multicast source home address (optional).
  • RFC 5568 defines the FMIPv6 protocol for fast handover of unicast nodes.
  • the protocol defines HI/HAck messages for establishing tunnels and transmission contexts between old access routers and new access routers, such as multicast. Source MN ID, Ipv4 home address, etc.
  • the IETF Mipshop working group studied the fast switching scheme in PMIPv6.
  • the FMIPv6 protocol is extended to redefine the HI/HAck message.
  • the embodiment of the present invention further expands the HI/HAck message to implement the bidirectional tunnel between MAG1 and MAG2 in the embodiment of the present invention. purpose.
  • the extension of the HI message and the HAck message is as follows:
  • the HI message is sent by MAG1 to MAG2, which is used to initiate the handover process of the multicast source MN.
  • the basic message format of the extended HI message is as shown in FIG. 6.
  • the extended HI message adds a new flag bit, R, in the original HI message, and is in the Mobility Options.
  • R a new flag bit
  • M bit Indicates a mobile multicast switch request.
  • R bit Indicates whether the switch is a multicast receiver or a multicast source.
  • the Mobility options need to include the newly defined multicast source switching option, as shown in Figure 7, where , mainly includes the following fields:
  • Option-Code used to indicate the multicast mode after handover. For example, it can be defined as: “0" means that the multicast mode after handover is RPT mode, " ⁇ , indicating that the multicast mode after handover is SPT and not Update the multicast tree mode, "2" indicates that the multicast mode after switching is SPT and the multicast tree pre-update mode; Multicast Address (multicast group address);
  • Multicast Source Home Address which is the address used by the multicast source to send multicast packets.
  • the HAck message is sent by MAG2 to MAG1 to reply to the HI message sent by MAG1.
  • the basic message format of the extended HAck message is as shown in FIG. 9.
  • the extended HAck message adds a new flag bit and R to the original HAck message, and is used to indicate the HI message.
  • Reply The definitions of the M and R bits are the same as the definitions of M and R in the extended HI message, and are not described here.
  • step 303 of the process of FIG. 3 according to the determined post-switching multicast mode and the established bidirectional tunnel, when multicast data from the multicast source is multicast, according to the determined post-switching multicast mode, the specific processing procedure
  • the process is described in detail below for the three different multicast modes mentioned above.
  • MAG1 In RPT mode, MAG1 needs to pass the RP address to MAG2, and MAG2 constructs the path to the RP.
  • MAG2 In RPT mode, MAG1 needs to pass the RP address to MAG2, and MAG2 constructs the path to the RP.
  • the multicast data is transmitted to the multicast receiving node through the path: Source (general source) ⁇ MAG2 ⁇ LMA (RP) ⁇ multicast tree.
  • the multicast data transmission in the RPT mode mainly includes the following steps (the flow can be connected to the bidirectional tunnel establishment process described in Figure 4 above):
  • Step 1001 The multicast source MN disconnects from the MAG1, and starts the handover process (that is, accesses to the MAG2).
  • Step 1002 The multicast source MN is connected to the MAG2, and the multicast data is sent by the multicast source MN to the MAG2, and then transmitted to the old multicast tree through the bidirectional tunnel between the MAG2 and the MAG1, and sent through the old multicast tree. To the multicast receiver.
  • the old multicast tree refers to the multicast path used to transmit multicast data when the multicast source MN accesses MAG1.
  • Step 1003 The MAG2 sends an extended binding update message (PUB message) to the LMA according to an existing process, and updates.
  • PUB message extended binding update message
  • the tunnel between the MAG2 and the LMA is the RP that requests the LMA as the multicast source.
  • Step 1004 The path update between the multicast source MN and the RP (LMA) is completed, and the multicast data starts to be forwarded along the path of the source (ie, multicast source MN) ⁇ MAG2 ⁇ LMA (RP) ⁇ multicast tree.
  • Step 1005 The tunnel between the MAG2 and the MAGI is sent, and the MAG1 sends a PBU message to the LMA that is bound to the multicast source MN.
  • the MAG1 passes the established bidirectional tunnel.
  • the multicast data of the multicast source MN forwarded by the MAG2 is received, and the multicast data is transmitted according to the multicast path established when the multicast source accesses.
  • the multicast data is transmitted between the MAG2 and the RP (LMA), and the bidirectional tunnel established between MAG1 and MAG2 is revoked. .
  • the SPT does not update the multicast data in the multicast tree mode, and mainly includes the following steps (the flow can be connected to the bidirectional tunnel establishment process described in FIG. 4):
  • Step 1101 The multicast source MN disconnects from the MAG1, and starts the handover process.
  • Step 1102 The multicast source MN is connected to the MAG2, and the multicast data is sent by the multicast source MN to the MAG2, and then transmitted to the old multicast tree through the bidirectional tunnel between the MAG2 and the MAG1, and sent through the old multicast tree. To the multicast receiver.
  • Step 1103 The MAG2 sends a PMIPv6 normal binding update message to the LMA to update the tunnel between the MAG2 and the LMA.
  • the tunnel between MAG1 and MAG2 is not revoked, and the data sent from the multicast source to the outside world is always transmitted from the source (multicast source MN) ⁇ 02 ⁇ 01 ⁇ multicast tree path to the multicast receiving node.
  • MAG1 is selected as the root node of the multicast tree and remains between the MAG of the latest access source MN. Establish a tunnel.
  • the multicast source MN sends the switch again, that is, the MAG2 is switched to the MAG3, the multicast source MN notifies the MAG1 of the address of the MAG3, and the MAG1 re-establishes the bidirectional tunnel with the MAG3, and repeats the above process to transmit the multicast source MN forwarded by the MAG3.
  • Multicast data After MAG1 establishes a bidirectional tunnel with MAG3, the bidirectional tunnel with MAG2 needs to be revoked.
  • the SPT and the multicast tree pre-update mode transmit multicast data, which mainly includes the following steps (the flow can be connected to the bidirectional tunnel establishment process described in FIG. 4):
  • Step 1201 The MAG1 initiates a process of pre-updating the multicast tree.
  • the multicast tree pre-update process is described in detail in the following embodiments, and is not described here.
  • Step 1202 The multicast source MN disconnects from the MAGI, and starts the handover process.
  • Step 1203 The multicast source MN is connected to the MAG2, and the multicast data is sent by the multicast source MN to the MAG2, and then transmitted to the old multicast tree through the bidirectional tunnel between the MAG2 and the MAG1, and the old multicast tree is adopted. Send to the multicast receiver.
  • Step 1204 The MAG2 sends a PMIPv6 normal binding update message to the LMA.
  • Step 1205 The binding update of the multicast source MN and the update of the multicast tree are completed, and the multicast data starts to be forwarded along the new multicast tree.
  • Step 1206 The tunnel between the MAG2 and the MAG1 is sent, and the MAG1 sends a PBU message to the LMA to be unbound to the multicast source MN.
  • the MAG1 receives the data of the multicast source forwarded by the MAG2 through the established bidirectional tunnel, and establishes the data according to the multicast source.
  • the multicast path multicasts the data.
  • the pre-updating process of the multicast tree is performed.
  • the new multicast path that is, the updated multicast tree
  • the multicast tree pre-updating process is initiated by the MAG1 after receiving the HAck message sent by the MAG2.
  • the MAG1 triggers the establishment of the multicast source to access the MAG2 and then uses the multicast source and the MAG2 address.
  • the multicast path of the broadcast data triggers the multicast tree update process.
  • the MAG1 carries the multicast source switching indication and the address information of the MAG2 in the data packet received by the bidirectional tunnel or the data packet directly sent by the multicast source, and according to the multicast path established when the multicast source accesses (ie, The old multicast tree) sends a packet carrying the multicast source switching indication and the address information of the MAG2.
  • the multicast source switching indication and the address information of the MAG2 may be carried in the Ipv6 hop-by-hop option header of the data packet.
  • an embodiment of the present invention provides a method for updating an SPT tree in a PMIPv6 environment.
  • the multicast source is a multicast tree (ie, a multicast path) corresponding to when the access point 1 moves to the access point 2, where the path is: DR ⁇ Routerl corresponding to the access point 1.
  • (Route 1) ⁇ Router2 ⁇ Router3 ⁇ DR which represents the multicast tree before the multicast source is switched, that is, the multicast path when the multicast source accesses the access point 1;
  • Router2 ⁇ Router3 ⁇ DR which represents the pre-updated multicast tree, that is, the multicast source access point 2 After the multicast path.
  • the routers associated with the multicast tree can be classified into the following four categories: 1. In the old multicast tree, but not in the new multicast tree, such as Router 1.
  • the MAG1 after the MAG1 obtains the MAG2 consent message (HAck message) for supporting the multicast source handover, the MAG1 immediately starts the pre-update process of the multicast tree, and does not need to wait for the multicast source to establish a connection with the MAG2.
  • the purpose of this is to be able to gain time to update the multicast tree as soon as possible and to reduce the time that the multicast source waits for the multicast tree to be updated.
  • the update of the multicast tree is bound to affect the use of the old multicast tree.
  • the new multicast tree will cause the old multicast tree to be discarded. This is not desirable for multicast fast handover, because in the process of pre-updating the multicast tree, we still want to use the old multicast tree to send multicast data, so as to reduce the pause delay of multicast service. .
  • the present invention extends the state of the (S, G) route stored on the multicast router, so that the multicast route corresponding to each multicast source has two interfaces for receiving multicast data:
  • Pre-switch interface pre-handover interface.
  • the active interface is the interface that receives the multicast data before the switchover, that is, the RPF interface of the old access point MAG1 of the router to the multicast source.
  • the old access point refers to the MAG1 that the multicast source MN accesses before the handover.
  • the router always receives multicast data from the old multicast tree through this interface.
  • the Pre-handover interface is the RPF interface of the new access point MAG2 from the router to the multicast source.
  • the new access point refers to the MAG2 that the multicast source MN accesses after the handover.
  • the pre-handover interface is set to null before the switch occurs. In the pre-update process, it is set to the RPF interface of the router to MAG2. When multicast data arrives through this interface, the new multicast tree is working. This interface is upgraded to Active interface.
  • the leaf router that is, the multicast node in the multicast tree
  • the IP address of the multicast source is unchanged, and the Join message is sent in the normal manner.
  • the router needs to encapsulate the Join (S, G) message in the IP packet with the destination address of MAG2, and the option header of the IP packet also needs to carry the group.
  • the hop-by-hop option header for the source switching option.
  • the specific process of multicast tree update mainly includes the following steps:
  • Step 1401 Before the handover starts, the Active interface of the (S, G) state in the multicast tree router is set to the path. From the RPF interface of the old access point MAG1 to the multicast source, the pre-handover interface is set to null.
  • Step 1402 The MAG1 initiates a multicast tree pre-updating process, and adds the extended multicast source switching option of the present invention to the Ipv6 hop-by-hop option header of the multicast data, where the option includes a multicast source switching indication and a multicast source to be accessed. The address of MAG2.
  • step 1402 the extended multicast source switching option will be described in detail later, and will not be described here.
  • Step 1403 When the data packet with the multicast source switching option reaches the first multicast node, the first multicast node constructs a Join message for generating the multicast tree, and the address information of the MAG2 carried in the data packet. Carrying is forwarded in the Join message.
  • Step 1404 The second multicast node that receives the Join message updates the multicast route according to the address information of the MAG2 carried in the Join message, and continues to forward the Join message until the new multicast tree is successfully added, that is, according to the address of the MAG2.
  • the multicast node after the information update multicast route receives the Join message.
  • the MAG2 processes the Join message instead of the multicast source MN, and the specific processing complies with the PIM-SM protocol (ie, RFC4601). Content), will not be described in detail here.
  • a multicast tree rooted at the new multicast source access point MAG2 is pre-established in the network.
  • all routers (S, G) are in the state.
  • the pre-handover interface is set to the RPF interface of the new access point MAG2 of the router to the multicast source.
  • the first multicast node carries the address information of the MAG2 in the Join message, and the process is as follows:
  • the first multicast node encapsulates the Join message in a data packet with the address of the MAG2 as the destination address, and carries the multicast source switching indication in the data packet;
  • the data packet carrying the multicast source switching indication is forwarded according to the set upstream neighbor router address.
  • the second multicast node that receives the Join message updates the multicast route according to the address information of the MAG2 carried in the Join message, that is, according to the address information of the MAG2 carried in the Join message.
  • the Pre-handover Interface in the broadcast routing state is set to the RPF interface of MAG2.
  • the process of updating the multicast route is as shown in FIG. 15, and includes the following steps:
  • Step 1501 The second multicast node parses the multicast source switching option in the option header of the Ipv6 packet, and obtains the address of the MAG2 carried in the packet.
  • Step 1502 The second multicast node determines whether there is a multicast routing state corresponding to the multicast service. If yes, go to step 1503. If no, go to step 1504.
  • Step 1503 Set the Pre-handover Interface in the multicast routing state corresponding to the multicast service to the RPF interface of the MAG2, and keep the state of the Active Interface unchanged.
  • Step 1504 Create a multicast routing state corresponding to the multicast service, and set the state of the Pre-handover Interface to the RPF interface of the MAG2, and set the state of the Active Interface to null.
  • the second multicast node continues to forward the Join packet to the upstream direction of the MAG2. Specifically, when forwarding the Join packet, it is forwarded according to the set upstream neighbor router address.
  • the extended multicast source switching option involved in the process of Figure 14 is carried in the option header of the IP data packet.
  • the IPv6 hop-by-hop option header is defined by RFC 2460, and its format is as shown in Figure 16, in the options (options).
  • the present invention defines the following new options:
  • the multicast source switching option indicates that the multicast source is about to be switched, and includes the address of the new access point MAG2 of the multicast source.
  • the multicast source switching option defined in the embodiment of the present invention is as shown in FIG. 17, where:
  • H indicates a multicast source switching indication
  • New access point's Address indicates the address of the new access point MAG2 of the multicast source.
  • the multicast data is maintained through the old multicast tree to the multicast receiving node.
  • the multicast source completes the binding update operation on MAG2
  • the multicast data starts to be forwarded along the new multicast tree, that is, it starts to reach each router from the pre-handover interface interface of the (S, G) state.
  • Step 1801 Determine whether the Active Interface state in the multicast routing state is empty. If yes, go to step 1804. If no, go to step 1802.
  • the determination result is yes, it corresponds to the above-mentioned Type of Router4, that is, the route that is not in the old multicast tree but in the new multicast tree.
  • Step 1802 Determine whether the Active Interface and the Pre-handover Interface in the multicast routing state are the same. If yes, go to step 1804. If no, go to step 1803.
  • the router type corresponding to the foregoing that is, the route in the old multicast tree and in the new multicast tree
  • the corresponding Router2 Type that is, the route in the old multicast tree and also in the new multicast tree.
  • Step 1803 Send a prune message to the Active Interface, and cut the router from the multicast tree.
  • Step 1804 Set the state of the Active Interface according to the state of the Pre-handover Interface, and set the state of the Pre-handover Interface to null. At this point, the alternate work of the old and new multicast trees is completed, and the multicast data is forwarded along the new multicast tree.
  • the second multicast node After the second multicast node updates the multicast route according to the address information of the MAG2 carried in the Join message, the second multicast node determines the Active Interface state or Active Interface after receiving the data through the Pre-handover Interface for the first time.
  • the Pre-handover Interface is the same, the Pre-handover Interface is upgraded to Active Interface (that is, the state of the Active Interface is set according to the state of the Pre-handover Interface), and the state of the Pre-handover Interface is set to null.
  • the MAG1 (the MAG accessed before the multicast source switching), the MAG2 (the MAG accessed after the multicast source switching), and the multicast router in the pre-update process of the multicast tree are required to be performed.
  • the corresponding improvements, specifically, the operations on MAG1, MAG2, and the multicast router are as follows:
  • the operation on MAG1 mainly includes the following aspects:
  • the MAG1 After receiving the handover notice message sent by the multicast source MN, the MAG1 extracts the ID of the multicast source MN and the ID of the MAG2. Determine the multicast mode after the multicast source is switched, and prepare the multicast group address, RP address (when RPT mode is selected), and multicast source home address for transmission.
  • the MAG1 sends the extended HI message to the MAG2.
  • the extended HI message also contains the ID of the multicast source MN and an extended mobility option.
  • the extended mobility options include: multicast mode selection bits after switching, multicast group address, RP address (when RPT mode is selected), and multicast source home address.
  • the MAG1 receives the notification from the MAG2, and revokes the bidirectional tunnel from the MAG1 to the MAG2, and sends a PBU message to the LMA.
  • SPT does not update the multicast tree mode:
  • the tunnel between MAG1 and MAG2 is not revoked, and the data sent from the multicast source to the outside world is maintained at 30 ⁇ 02 ⁇ 01 ⁇ the path of the multicast tree is transmitted to the multicast receiving node. .
  • MAG1 is the root node of the multicast tree and maintains a tunnel with the latest access point MAG2 of the multicast source MN.
  • the multicast source MN moves for the second time and the third time, it notifies the MAGI of the address of the next access point through the existing tunnel, and the MAG1 cyclically establishes its new connection to the multicast source MN.
  • the tunnel between the inbound MAGs the multicast data is transmitted to the MAG1 through the new tunnel, and then transmitted to the multicast tree.
  • the tunnel between MAG1 and the access point of the multicast source MN is revoked.
  • MAG1 initiates the process of pre-updating the multicast tree. It broadcasts data to
  • the Ipv6 hop-by-hop option header adds the extended multicast source switching option of the present invention, including multicast source switching indication and multicast.
  • MAG1 receives the notification from MAG2, revokes the bidirectional tunnel from MAG1 to MAG2, and sends a PBU message to the LMA that is bound to the multicast source MN.
  • the operation on MAG2 mainly includes the following aspects:
  • the MAG2 receives the HI message sent by the MAG1, determines the current handover to the multicast source by parsing the HI message, and extracts the post-switching multicast mode information, the multicast group address, and the RP address (selecting the RPT mode). Time), multicast source home address and other information. According to the local policy, whether to support the multicast source switching, whether the load is too heavy, etc. decide whether to accept the handover.
  • MAG2 After the multicast source MN is connected to MAG2, MAG2 receives the multicast data sent by the multicast source, and then transmits it to MAG1 through the bidirectional tunnel between MAG2 and MAG1.
  • the MAG2 In the RPT mode, the MAG2 sends an extended binding update message to the LMA, requesting the LMA to act as the RP of the multicast source. After the binding update process is completed, MAG2 notifies MAG1 to stop the forwarding of multicast data and revoke the bidirectional tunnel from MAG1 to MAG2.
  • MAG2 sends a PMIPv6 normal binding update message to the LMA.
  • the multicast source is fast, the tunnel between MAG1 and MAG2 is not revoked, and the data sent from the multicast source to the outside world is always transmitted to the multicast receiving node in the source->MAG2->MAGl->multicast tree. .
  • the MAG2 notifies the MAG1 of the address of the new access point MAG that the multicast source MN moves again through the tunnel between the MAG1 and the MAG2. After the tunnel of the MAG1 and the new access point MAG is established, The tunnel between MAG1 and MAG2 is currently revoked.
  • MAG2 sends PMIPv6 normal binding update message to LMAJ. During the multicast tree update process, it receives a special Join message. If the multicast source MN is not connected to MAG2 at this time, MAG2 replaces the multicast source MN to process the Join message. After the multicast tree is updated, the multicast data is forwarded along the new multicast tree. MAG2 notifies MAG1 to stop forwarding multicast data and revoke the bidirectional tunnel from MAG1 to MAG2.
  • the multicast router pre-update process in the multicast router mainly includes the following aspects
  • the active interface of the (S, G) state in the multicast tree router is set to the RPF interface of the access point MAG1 from the router to the multicast source, and the pre-handover interface is set to null.
  • the leaf node router When the leaf node router (corresponding to the multicast node) receives the multicast data with the multicast source switching option sent by the MAG1, it needs to parse the multicast source switching option, extract the address of the MAG2, and construct the Join ( S, G) message, the Join (S, G) message is encapsulated in the IP data packet with the MAG2 as the destination address, and the IPv6 hop-by-hop option header of the IP data packet carries the multicast source switching option. Finally, it sends the Join message encapsulated in the IP packet to the direction of MAG2. (3) After receiving the Join message encapsulated in the IP packet, the router updates the multicast route.
  • a multicast tree rooted at the new multicast source access point MAG2 is pre-established in the network.
  • all routers S The pre-handover interface of the state of G, is set to the RPF interface of the new access point MAG2 of the router to the multicast source.
  • the multicast data After MAG2 completes the binding update and other operations, the multicast data starts to be forwarded along the new multicast tree, that is, it starts to reach each router from the pre-handover interface interface of the (S, G) state.
  • the router needs to forward the multicast data according to the new path.
  • the second embodiment of the present invention provides a device for transmitting multicast data.
  • the device includes: a handover notice message receiving unit 1901, a tunnel establishing unit 1902, and a multicast data transmission unit 1903;
  • the handover notice message receiving unit 1901 is configured to receive a handover notice message sent before the multicast source is switched from the currently accessed first mobile access gateway MAG to the second MAG; the handover notice message carries the identifier information of the second MAG;
  • the tunnel establishing unit 1902 is configured to establish a bidirectional tunnel with the second MAG according to the identifier of the second MAG carried in the handover notice message received by the handover notice message receiving unit 1901.
  • the multicast data transmission unit 1903 is configured to: multicast the multicast data from the multicast source according to the determined bidirectional tunnel mode and the bidirectional tunnel established by the tunnel establishing unit 1902, where the post-switching multicast mode is the group.
  • the multicast mode used after the broadcast source switches to the second MAG.
  • the device shown in FIG. 19 includes a tunnel establishing unit 1902, specifically configured to:
  • the device shown in FIG. 19 includes a tunnel establishing unit 1902, specifically configured to:
  • an HI message including indication information of the multicast source handover, a multicast source identifier, and indication information of the post-switching multicast mode.
  • the device shown in FIG. 19 includes a tunnel establishing unit 1902, specifically configured to:
  • the device shown in FIG. 19 includes a multicast data transmission unit 1903, which is specifically configured to:
  • the multicast mode after the handover is the RPT mode
  • the multicast mode used by the multicast source to access the first MAG is SPT mode and determining that the moving speed of the multicast source is greater than a set threshold, determining that the multicast mode after the switch is SPT and does not update the multicast Tree mode
  • the multicast mode used by the multicast source to access the first MAG is SPT mode and determining that the moving speed of the multicast source is not greater than a set threshold, determining that the multicast mode after the handover is SPT and the multicast tree Pre-update mode.
  • the apparatus shown in FIG. 19 includes a multicast data transmission unit 1903, which is specifically configured to:
  • the first MAG is used before the multicast path is established after the multicast source accesses the second MAG. Receiving, by the established bidirectional tunnel, data of the multicast source that is forwarded by the second MAG, and multicasting data according to the multicast path established when the multicast source is accessed;
  • the first MAG receives the data of the multicast source forwarded by the second MAG through the established bidirectional tunnel, and accesses according to the multicast source, after the determined switch mode is the SPT and the multicast tree mode is not updated.
  • the multicast path established at this time multicasts the data.
  • the apparatus shown in FIG. 19 may further include:
  • the multicast tree update control unit 1904 is configured to: after receiving the HAck message sent by the second MAG, after the determined handover mode, the multicast mode is SPT and the multicast tree pre-update mode, The multicast path and the address of the second MAG trigger the establishment of a multicast path for the multicast data after the multicast source accesses the second MAG.
  • the apparatus shown in FIG. 20 includes a multicast tree update control unit 1904, specifically configured to:
  • the data packet sent by the multicast source carries the multicast source switching indication and the address information of the second MAG, and is sent to the multicast node on the multicast path according to the multicast path established when the multicast source is accessed.
  • a multicast source switching indication and a data packet of the address information of the second MAG are included in the multicast source.
  • the apparatus shown in FIG. 20 includes a multicast tree update control unit 1904, specifically configured to:
  • the multicast source switching indication and the address information of the second MAG are carried in the Ipv6 hop-by-hop option header of the data packet sent by the multicast source.
  • the apparatus shown in FIG. 19 may further include:
  • the tunnel revocation unit 1905 is configured to complete the multicast path establishment of the multicast data after the multicast source accesses the second MAG, when the determined multicast mode is the RPT mode or the SPT and the multicast tree pre-update mode. Afterwards, the bidirectional tunnel revocation indication sent by the second MAG is received, and the bidirectional tunnel with the second MAG is revoked according to the revocation indication.
  • the above-mentioned means for transmitting multicast data includes only the logical division according to the functions implemented by the apparatus. In practical applications, the superposition or splitting of the above units may be performed.
  • the function implemented by the device provided in this embodiment is in one-to-one correspondence with the method for transmitting multicast data provided in the first embodiment. The more detailed processing flow implemented by the device is already in the first embodiment of the foregoing method. A detailed description will not be described in detail here.
  • a third embodiment of the present invention provides a system for transmitting multicast data.
  • the system mainly includes: a multicast source 2201, a first mobile access gateway MAG 2202, and a second MAG 2203;
  • the multicast source 2201 is configured to send to the first MAG before switching from the currently accessed first MAG to the second MAG.
  • the handover advance notice message carries the identifier information of the second MAG 2203;
  • a first MAG 2202 configured to establish a bidirectional tunnel with the second MAG 2203 according to the identifier of the second MAG 2203 carried in the handover advance message sent by the multicast source 2201; and establish a post-switching multicast mode and establish The two-way tunnel, multicasting multicast data from the multicast source, where the multicast mode after switching is the multicast source switching to the second MAG
  • the multicast mode used after 2203.
  • the function implemented by the first MAG included in the system for transmitting multicast data corresponds to the apparatus for transmitting multicast data provided in Embodiment 2, and a more detailed processing flow implemented by the first MAG is It has been described in detail in the above second embodiment, and will not be described in detail herein.
  • a fourth embodiment of the present invention provides a system for updating a multicast tree.
  • the system mainly includes: a first multicast node 2301 and a second multicast node 2302;
  • the first multicast node 2301 is configured to receive a data packet sent by the first mobile access gateway MAG, and after determining that the data packet carries the multicast source switching indication, construct a join message for generating a multicast tree, and The address information of the second MAG carried in the data packet is carried in the Join message.
  • the second multicast node 2302 is configured to receive the Join message forwarded by the first multicast node 2301, update the multicast route according to the address information of the second MAG carried in the Join message, and continue to forward the Join message until the second MAG is After the multicast information is updated, the multicast node receives the Join message.
  • the system shown in FIG. 23 includes a first multicast node 2301, specifically configured to: Encapsulating the Join message in the data packet with the address of the second MAG as the destination address, and carrying the multicast source switching indication in the data packet, and forwarding the data packet carrying the multicast source switching indication according to the set upstream neighbor router address .
  • the second multicast node included in the system shown in FIG. 4 In a preferred embodiment provided by Embodiment 4 of the present invention, the second multicast node included in the system shown in FIG.
  • the pre-handover interface in the multicast routing state corresponding to the multicast service is set to the reverse path forwarding RPF interface of the second MAG according to the address information of the second MAG carried in the Join message.
  • the system shown in FIG. 23 includes a second multicast node 2302, specifically configured to:
  • Interface is set to the RPF interface of the second MAG
  • the multicast routing state is created, and the state of the Pre-handover Interface in the multicast routing state is set to the RPF interface of the second MAG, and the multicast is The status of the data receiving interface Active Interface in the routing state is set to null.
  • the second multicast node included in the system shown in FIG. 4 In a preferred embodiment provided by Embodiment 4 of the present invention, the second multicast node included in the system shown in FIG.
  • the Active Interface state in the multicast routing state is determined to be empty or Active Interface and Pre-handover.
  • the status of the Active Interface is set according to the state of the Pre-handover Interface, and the status of the Pre-handover Interface is set to null.
  • the MAG1 is initiated by the extended handover.
  • HI the handover acknowledgement
  • HAck the handover acknowledgement
  • the multicast data is transmitted to the original multicast tree through the multicast source ⁇ MAG2 ⁇ MAG1 path, and then forwarded to the multicast receiving node. In this way, the pause time of the multicast service is minimized.
  • the multicast source establishes a connection with MAG2, the multicast service can be restored.
  • the delay of the multicast source switching is: The time when the multicast source moves and connects to the MAG2.
  • the handover delay of the multicast source is only: The time when the multicast source MN moves and connects to MAG2. It can be seen that the solution effectively reduces the handover delay of the multicast source, and achieves the purpose of restoring the multicast service in the smallest possible delay.
  • the SPT and multicast tree update mode since the pre-upgrade of the multicast tree is started at the beginning of the handover, this also effectively reduces the time when the multicast source waits for the multicast tree reconstruction. Between.
  • the present invention supplements the prior art post-switching multicast mode.
  • the present invention defines three post-switching multicast modes: RPT mode, SPT and does not update the multicast tree mode and SPT and the multicast tree pre-update mode.
  • RPT mode RPT mode
  • SPT SPT
  • SPT SPT
  • SPT SPT
  • SPT SPT
  • SPT SPT
  • SPT SPT
  • SPT SPT
  • multicast tree pre-update mode Each mode captures different switching modes for different real-world situations, which makes it more realistic and more usable, avoiding waste of network resources and excessive delay of multicast services.
  • the present invention also defines a method for pre-updating the SPT, starting the pre-updating work of the multicast tree before the handover of the mobile node, pre-establishing the multicast tree, and reducing the time required for updating the multicast tree. Delay. Moreover, the process of pre-updating the multicast tree does not affect the old multicast tree, and the old multicast tree is used to forward data.
  • the invention overcomes the problem that the RPF detection fails in the case that the multicast source address is unchanged during the movement of the multicast source, and ensures that the multicast source mobile is transparent to the multicast receiver. The time that the multicast source MN waits for the multicast tree update after switching to the MAG2 is reduced, and the multicast data is lost during the multicast tree update process.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the present invention can be embodied in the form of a computer program product embodied on one or more computer-usable storage interfaces (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.
  • computer-usable storage interfaces including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

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

Description

传输组播数据的方法、 组播树的更新方法以及系统和装置 本申请要求在 2010年 12月 21日提交中国专利局、申请号为 201010597699.6、发明名称为"一 种传输组播数据的方法、 组播树的更新方法以及系统和装置"的中国专利申请的优先权， 其 全部内容通过 I用结合在本申请中。
技术领域 本发明涉及移动通信技术领域， 尤其涉及一种传输组播数据的方法、 组播树的更新方 法以及系统和装置。 背景技术 近年来， 无线技术的成熟使得越来越多的人通过无线设备连接到网络中， 并希望能够 随时随地的对网络进行访问。 支持移动通信成为网络发展的必然要求， 已有大量研究关注 于网络如何为移动提供支持 , 其中 IETF ( Internet Engineering Task Force , Internet工程任务 组） 的 PMIPv6 ( Proxy Mobile IPv6, 代理移动 IPv6 )作为一种局部移动性管理技术， 将移 动性管理功能从终端侧转移到网络侧， 网络代表主机来负责管理 IP移动性， 网络中的移动 实体负责跟踪主机的移动并且初始化所要求的移动信号传输。 PMIPv6在不需要主机参与任 何移动性相关信号传输的前提下实现了主机的 IP ( Internet Protocol, 互联网协议）移动性， 从而大大减轻了终端的负担， 同时方便了集中控制。
另一方面， 组播技术被越来越广泛地应用到各个领域。 组播是一种点到多点的信息传 输方式， 要求数据能从一个源节点同时传输到多个目的节点， 目的节点构成一个特定的节 点集合， 称为组或者群组。 由于组播技术具有网络利用率高、 减少骨千网络拥塞、 节省资 源、 可扩展性强等优点， 在视频会议、 文件分发、 实时信息发布、 IP 电视等新型网络应用 中发挥了 4艮大的作用。 在一个典型的移动 IPTV ( Interactive Personality TV, 交互式网络电 视）应用中， 大量用户可以通过组播技术获得网络分发的音频 /视频流数据。
随着移动通信技术的发展， 移动与组播的结合成为一项迫切的需求。 在移动环境中， 无线链路的链路带宽有限且有着较高的错误率， 同时， 移动节点的能量供应、 处理器能力 等都是非常有限的，这对传统组播技术提出了新的挑战。传统的组播协议基于固定的网络， 有线的通信方式， 不能满足移动性的要求。 移动组播架构不仅要处理移动主机位置的动态 改变， 而且要处理组播组中动态变化的组成员关系。 总体来说， 移动环境中的组播架构需 要满足以下要求： 节点切换时保证组播对话的无缝连续性； 保证数据包的最佳路由； 支持 组播通信中的流切换（不同的流有不同的特性和标识） ； 避免组播解决方案特殊化 (只能 支持组播， 不支持单播） ； 能够处理丢包、 重复副本； 组播数据流动态适应当前网络的状 况（调整发送速率等） ； 易于部署； 加快路由协议的收敛速度等。
目前， IETF工作组对于支持组播源移动的研究工作仍处于初始阶段，提出了在 PMIPv6 中支持组播源移动性的方案。 这个方案提出了在 PMIPv6中 RPT ( Rendezvous Point Tree, 支持共享树）和 SPT ( Shortest Path Tree, 最短路径树） 的方法。
方案提出， 当使用 RPT模式传输组播数据时， 使用 LM A ( Local Mobility Anchor, 本地 移动锚点）作为 RP ( Rendezvous Point, 组播汇聚点）， 由它来回复组播接收节点发送的加 入消息， 建立 LMA到组播接收节点的最短路径组播树。 组播数据由组播源发送到 LMA, 再 由 LMA通过组播树转发到组播接收节点。 这种模式下， 当组播源位置移动时， 不需要重新 建立 LMA到组播接收节点之间的最短路径树， 组播树比较稳定。但是， 由于通过 LMA转发 的路径并不是组播源到组播接收节点之间的最优路由， 所以这种模式会引入很大的延时和 网络负担。
RPT模式下， 当组播源 MN进入 PMIPv6域后， 执行的流程如图 1所示， 主要包括如下步 骤：
步骤 101、建立移动接入网关 MAG1与组播源 MN之间的链路， 组播源 MN在 RS ( Router Solicitation, 路由请求） 消息中包含 "S" =1和 "J" =1 , 标识自己是组播源并且选择 RPT 模式。
步骤 102、 MAG1确定组播源 MN接入后， 发送扩展的 PBU消息到 LMA, 建立 MAG1和 LM A之间的双向隧道。
该步骤 102中， LMA接收到 PBU消息后， 解析该 PUB消息中包含的扩展信息， 并且回 复组播加入消息。
步骤 103、 组播数据按照 PMIPv6中定义的基本方式由组播源 MN发送到 LMA。
该步骤中， 在 LMA和组播接收节点之间建立 SPT, 组播数据按照组播路由协议在 LMA 和组播接收节点之间传输。
步骤 104、 组播源 MN移动到 MAG2 , 组播源 MN通过 RS消息把组播相关信息发送到 MAG2。
步骤 105、 更新 LMA和 MAG2之间的双向隧道。
该步骤 105中， 更新 LMA和 MAG2之间的双向隧道的过程对 LMA和组播接收者之间的 SPT不造成影响。
在组播源 MN切换后， 组播数据继续传输。 组播源的移动对组播接收者不产生影响。 方案提出， 当使用 SPT模式传输组播数据时， 由组播源回复组播接收节点发送的加入 消息， 直接建立组播源到组播接收节点的最短路径组播树 , 组播数据由组播源直接通过建 立的组播树发送到组播接收节点。 这种模式下， 由于路由的最优化， 网络延迟比较小， 但 是它会引起路由器存储负担过重、 组播树不稳定的问题。 当组播源在网络中移动时， 组播 树需要频繁地进行更新。
SPT模式下， 当组播源 MN进入 PMIPv6域后， 执行的流程如图 2所示， 主要包括如下步 骤：
步骤 201、 建立 MAG1与组播源 MN之间的链路， 组播源 MN在 RS消息中包含 " S" =1 和 "J" =0 , 标识自己是组播源并且选择 SPT模式。
步骤 202、 MAG1确定组播源 MN接入后， 发送扩展的 PBU消息到 LMA, 建立 MAG1和 LM A之间的双向隧道。
该步骤 202中， LMA接收到 PBU消息后， 解析该 PBU消息中包含的扩展信息， 但并不 回复组播加入消息。
步骤 203、 组播数据按照 PMIPv6中定义的基本方式由组播源 MN发送到 LMA。
该步骤 203中， 当 LMA把组播加入消息重定向给组播源 MN时， 组播源和组播接收节点 之间的 SPT开始建立， 接下来的组播数据将按照优化后的路径在组播源和组播接收节点之 间传输。
步骤 204、 组播源 MN移动到 MAG2后， 组播源 MN通过 RS消息把组播相关信息发送到 MAG2。
步骤 205、 更新 LMA和 MAG2之间的双向隧道。
该步骤 205中， 更新 LMA和 MAG2之间的双向隧道时， 也需要更新组播源和组播接收 节点之间的 SPT , 因为组播树的根节点移动到了一个不同的位置。
方案中规定， 组播源根据移动速度来进行模式的选择。 当组播源在网络中以较小的速 率移动时， 釆用 SPT的方式， 在组播源和组播接收节点之间建立最短路径组播树； 当组播 源在网络中的移动速度较快时， 釆用 RPT的方式， 由 LMA充当汇聚节点， 在 LMA和组播接 收节点之间建立最短路径组播树。
现有技术的缺点在于不能支持组播源的快速切换， 组播源在 PMIPv6域中两个 MAG之 间进行切换时存在较大的延迟。 现有方案中规定， 当组播源从旧的 MAG (即 MAGI )移动 到新的 MAG (即 MAG2 ) 时， 需要进行组播源与 MAG2之间的绑定更新、 认证等一系列过 程， 尤其在 SPT模式下， 还需要执行组播树重建过程。 在这些过程完成后， 才能继续进行 组播数据的分发， 这会使组播服务产生很长时间的中断。 由于组播服务一对多的特性， 组 播源的切换延迟将会影响到组内的所有用户， 这显然不能满足组播会话的无缝连续性， 对 具有实时性要求的应用的影响尤为严重。 发明内容 有鉴于此， 本发明实施例提供了一种传输组播数据的方法、 组播树的更新方法以及系 统和装置， 釆用该技术方案， 减少了由于组播源在移动接入网关之间切换而导致的组播服 务中断时延， 保证了 PMIPv6系统中组播业务的实时性。
本发明实施例通过如下技术方案实现：
根据本发明实施例的一个方面， 提供了一种传输组播数据的方法， 包括：
第一移动接入网关 MAG接收组播源从当前接入的第一 MAG切换到第二 MAG之前 发送的切换预告消息； 所述切换预告消息携带所述第二 MAG的标识信息；
第一 MAG根据所述切换预告消息中携带的所述第二 MAG的标识， 建立与所述第二 MAG之间的双向隧道； 并
根据确定的切换后组播模式以及建立的所述双向隧道， 组播来自所述组播源的组播数 据， 其中， 所述切换后组播模式为所述组播源切换到所述第二 MAG后釆用的组播模式。
根据本发明实施例的一个方面， 提供了一种组播树的更新方法， 包括：
第一组播节点接收第一移动接入网关 MAG发送的数据包；
在确定所述数据包中携带组播源切换指示后， 构建用于生成组播树的加入 Join消息， 并将所述数据包中携带的第二 MAG的地址信息携带在所述 Join消息中转发；
接收到所述 Join消息的第二组播节点根据所述 Join消息携带的第二 MAG的地址信息 更新组播路由， 并继续转发所述 Join消息直至已根据所述第二 MAG的地址信息更新组播 路由后的组播节点接收到所述 Join消息。
根据本发明实施例的一个方面， 提供了一种传输组播数据的系统， 包括：
组播源、 第一移动接入网关 MAG以及第二 MAG;
所述组播源，用于在从当前接入的第一 MAG切换到第二 MAG之前，向所述第一 MAG 发送的切换预告消息； 所述切换预告消息携带所述第二 MAG的标识信息；
所述第一 MAG,用于根据所述组播源发送的切换预告消息中携带的所述第二 MAG的 标识， 建立与所述第二 MAG之间的双向隧道； 并根据确定的切换后组播模式以及建立的 所述双向隧道， 组播来自所述组播源的组播数据， 其中， 所述切换后组播模式为所述组播 源切换到所述第二 MAG后釆用的组播模式。
根据本发明实施例的一个方面， 提供了一种传输组播数据的装置， 包括：
切换预告消息接收单元， 用于接收组播源从当前接入的第一移动接入网关 MAG切换 到第二 MAG之前发送的切换预告消息； 所述切换预告消息携带所述第二 MAG的标识信 息；
隧道建立单元， 用于根据所述切换预告消息接收单元接收的切换预告消息中携带的所 述第二 MAG的标识， 建立与所述第二 MAG之间的双向隧道；
组播数据传输单元， 用于根据确定的切换后组播模式以及所述隧道建立单元建立的所 述双向隧道， 组播来自所述组播源的组播数据， 其中， 所述切换后组播模式为所述组播源 切换到所述第二 MAG后釆用的组播模式。
根据本发明实施例的一个方面， 提供了一种组播树的更新系统， 包括：
第一组播节点， 用于接收第一移动接入网关 MAG发送的数据包， 在确定所述数据包 中携带组播源切换指示后， 构建用于生成组播树的加入 Join消息， 并将所述数据包中携带 的第二 MAG的地址信息携带在所述 Join消息中转发；
第二组播节点，用于接收所述第一组播节点转发的所述 Join消息，根据所述 Join消息 携带的第二 MAG的地址信息更新组播路由， 并继续转发所述 Join消息直至已根据所述第 二 MAG的地址信息更新组播路由后的组播节点接收到所述 Join消息。
通过本发明实施例提供的上述至少一个技术方案， 第一 MAG接收组播源发送的包括 第二 MAG标识的切换预告消息， 根据该切换预告消息中包括的第二 MAG标识， 建立与 该第二 MAG标识对应的第二 MAG之间的双向隧道； 并根据确定的切换后组播模式以及 建立的双向隧道， 组播来自组播源的组播数据， 其中， 切换后组播模式为组播源切换到第 二 MAG后釆用的组播模式。 釆用该技术方案， 由于切换预告消息在组播源从当前接入的 第一 MAG切换到第二 MAG之前发送， 通过预先建立双向隧道， 在组播源与第二 MAG 之间进行绑定更新、认证等过程时， 第一 MAG可以通过建立的该双向隧道传输组播数据， 从而减少了由于组播源在 MAG之间切换而导致的组播服务中断时延， 保证了 PMIPv6系 统中组播业务的实时性以及连续性。
本发明的其它特征和优点将在随后的说明书中阐述， 并且， 部分地从说明书中变得显 而易见， 或者通过实施本发明而了解。 本发明的目的和其他优点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实现和获得。 附图说明 附图用来提供对本发明的进一步理解， 并且构成说明书的一部分， 与本发明实施例一 起用于解释本发明， 并不构成对本发明的限制。 在附图中：
图 1为现有技术提供的 RPT模式下组播源进入 ΡΜΙΡνό域的切换流程图；
图 2为现有技术提供的 SPT模式下组播源进入 ΡΜΙΡνό域的切换流程图；
图 3为本发明实施例一提供的传输组播数据的方法流程图；
图 4为本发明实施例一提供的 MAG1与 MAG2之间建立双向隧道的流程图； 图 5为现有技术中定义的 HI消息的基本消息格式示意图；
图 6为本发明实施例一提供的扩展后的 HI消息的基本消息格式示意图；
图 7为本发明实施例一提供的组播源切换选项的格式示意图；
图 8为现有技术中定义的 HAck消息的基本消息格式示意图； 图 9为本发明实施例一提供的扩展后的 HAck消息的消息格式示意图； 图 10为本发明实施例一提供的 RPT模式下传输组播数据的流程图；
图 11为本发明实施例一提供的 SPT且不更新组播树模式下传输组播数据的流程图； 图 12为本发明实施例一提供的 SPT且组播树预更新模式下传输组播数据的流程图； 图 13为本发明实施例一提供的组播源由接入点 1移动到接入点 2时的组播树示意图； 图 14为本发明实施例一提供的组播树更新的流程图；
图 15为本发明实施例一提供的更新组播路由的流程图；
图 16为本发明实施例一提供的 IPv6逐跳选项头的格式示意图；
图 17为本发明实施例一提供的组播源切换选项的格式示意图；
图 18为本发明实施例一提供的进一步更新组播路由器的流程图；
图 19为本发明实施例二提供的传输组播数据的装置示意图一；
图 20为本发明实施例二提供的传输组播数据的装置示意图二；
图 21为本发明实施例二提供的传输组播数据的装置示意图三；
图 22为本发明实施例三提供的传输组播数据的系统示意图；
图 23为本发明实施例四提供的组播树更新系统示意图。 具体实施方式 为了给出保证 PMIPv6系统中组播业务的实时性以及连续性的实现方案， 本发明实施 例提供了一种传输组播数据的方法、 组播树的更新方法以及系统和装置， 以下结合说明书 附图对本发明的优选实施例进行说明， 应当理解， 此处所描述的优选实施例仅用于说明和 解释本发明， 并不用于限定本发明。 并且在不冲突的情况下， 本申请中的实施例及实施例 中的特征可以相互组合。
实施例一
本发明实施例一首先提供了一种传输组播数据的方法， 通过该方法能够解决移动组播 源在 PMIPv6系统中两个 MAG之间切换时组播中断过长的问题， 以达到在尽可能小的时延 内恢复组播服务的目的； 本发明实施例一还提供了一种组播树的更新方法， 通过该方法解 决了 PMIPv6中组播源移动时 SPT的预更新问题， 在对组播接收者透明的前提下实现了组播 源切换完成之前预先更新 SPT的目的。
本发明可以应用于同一个 PMIPv6系统内组播源 MN切换的场景， 例如， 组播源 MN由 当前接入的 MAG1移动到同一个 PMIPv6域中的 MAG2。 在对本发明实施例一提供的传输组 播数据的方法进行详细描述之前， 首先对本发明实施例中提出的切换后组播模式进行详细 说明， 此处， 切换后组播模式即组播源 MN在接入 MAG2以后釆用的组播模式。 本发明实施例提供了三种切换后组播模式， 该三种切换后组播模式分布为：
RPT模式；
SPT且不更新组播树模式；
SPT且组播树预更新模式。
以下对该三种切换后组播模式进行详细说明：
( 1 ) RPT模式
组播源 MN在接入 MAG1时釆用 RPT模式传输组播数据， 即使用 LMA作为 RP, 组播数 据首先发送到 LMA, 再由 LMA传输给各组播接收者。 在该情况下， 当该组播源 MN切换到 MAG2后， 仍然需要使用 RPT模式， 即组播源 MN接入 MAG2以后釆用的组播模式为 RPT模 式。 这种模式下 MAG1需要把 RP地址传递给 MAG2, MAG2需要构建到 RP的路径。
根据该 RPT模式， 在组播源与 MAG2建立连接且完成绑定更新等过程之前， 组播数据 可以通过 MAG1以及 MAG2之间建立的双向隧道转发 , 即组播数据发送到组播接收者对应 的组播接收节点时通过的路径为：
Source (即组播源）→MAG2→MAG1→LMA ( RP )→组播树传输到组播接收节点。 当组播源与 MAG2建立连接且完成绑定更新等过程之后， 组播数据发送到组播接收者 对应的组播接收节点时通过的路径为：
Source→MAG2→LMA ( RP )→组播树传输到组播接收节点。
( 2 ) SPT且不更新组播树模式
组播源 MN在接入 MAG1时釆用 SPT模式传输组播数据， 若此时组播源 MN的移动速度 较快（例如， 大于设定阀值）时， 当该组播源 MN切换到 MAG2后， 需要继续使用 SPT模式 传输组播数据 , 但不需要更新组播树 , 该切换后组播模式称为 SPT且不更新组播树模式。
根据该 SPT且不更新组播树模式， 可以通过 MAG1以及 MAG2之间建立的双向隧道转 发， 即组播数据在组播源与 MAG2建立连接且完成绑定更新等过程之前以及之后 , 组播数 据发送到组播接收者对应的组播接收节点时通过的路径均为：
80^^→ 02→ 01→组播树。
釆用该 SPT且不更新组播树模式， MAG1和 MAG2之间的隧道不随着组播源与 MAG2建 立连接且完成绑定更新等过程的结束而撤销 , 组播源发往外界的数据一直通过该双向隧道 传输到组播接收节点。 釆用该模式可以减少组播源 MN移动速度过快在 MAG之间切换而导 致的频繁拆、 建组播树， 从而避免网络资源浪费， 提高组播转发效率。
( 3 ) SPT且组播树预更新模式
组播源 MN在接入 MAG1时釆用 SPT模式传输组播数据 ,若此时组播源的移动速度比较 慢（例如， 不大于设定阀值）时， 当该组播源 MN切换到 MAG2后， 需要继续使用 SPT模式 传输组播数据， 此时， 需要预更新组播树， 该切换后组播模式称为 SPT且组播树预更新模 式。
这种模式下， MAGI在接收到 MAG2反馈的建立双向隧道的回复消息后、 需要发起组 播树的预更新过程。 该组播树的预更新过程主要包括： MAG1在组播数据包中携带组播源 切换选项， 该选项中包括组播源切换指示、 MAG2的地址等信息。 随着组播数据包在旧的 组播树上的传递， 组播源选项向组播树中的路由器通告即将发生的组播源切换、 以及切换 后的 MAG2的地址， 从而触发组播树的预更新。 此处， 旧的组播树指组播源 MN接入 MAG1 时建立的用于传输组播数据的组播路径。 当新的组播树更新完毕、 且组播源 MN在 MAG2 完成绑定更新等过程之后， 组播数据通过新的组播树发送到组播接收节点。 此处， 新的组 播树指组播源 MN接入 MAG2时建立的用于传输组播数据的组播路径。
根据该 SPT且组播树预更新模式， 在组播源与 MAG2建立连接且完成绑定更新等过程 之前， 组播数据可以通过 MAG1以及 MAG2之间建立的双向隧道转发， 即组播数据发送到 组播接收者对应的组播接收节点时通过的路径为：
Source→MAG2→MAGl→组播树（旧的组播树） 。
在组播源与 MAG2建立连接且完成绑定更新等过程之后 , 组播数据发送到组播接收者 对应的组播接收节点时通过的路径为：
Source→MAG2→组播树（新的组播树） 。
基于以上定义的切换后组播模式以及相应的数据传输路径， 本发明实施例一提供的传 输组播数据的方法如图 3所示， 主要包括如下步骤：
步骤 301、 MAG1接收组播源 MN从当前接入的 MAG1切换到 MAG2之前发送的切换预 告消息， 该切换预告消息携带 MAG2的标识信息。
步骤 302、 MAG1根据该切换预告消息中携带的 MAG2的标识， 建立与 MAG2之间的双 向！ ¾道。
步骤 303、 根据确定的切换后组播模式以及建立的双向隧道， 组播来自组播源的组播 数据。
该步骤 303中， 根据确定的切换后组播模式不同， 该步骤 303釆用的传输组播数据的具 体方式不同， 该过程将在后续实施例中详细描述， 此处暂不描述。
至此，在组播源由于移动而需要改变接入的 MAG改变时对应的传输组播数据的流程结 束。
上述流程在具体实现时， 主要应用于组播源 MN由于移动需求需要切换 MAG时传输组 播数据的场景。 具体地， 组播源 MN需要从 MAG1切换到 MAG2时， MAG1与 MAG2之间需 要建立双向隧道， 该建立双向隧道的流程如图 4所示， 主要包括如下步骤：
步骤 401、 未发生切换之前， 组播源 MN连接在 MAG1上， 按照釆用的组播模式传输组 播数据。 该步骤 401中， 若釆用 RPT模式传输组播数据， 组播数据由组播源 MN发送到 MAG1 , 然后传输到 LMA ( LMA作为 RP汇聚点）、 由 LMA转发到组播接收者； 若釆用 SPT模式传输 组播数据， 组播数据直接根据建立的 SPT由组播源转发到组播接收者。
步骤 402、 组播源 MN确定即将发生切换， 向 MAG1报告组播源 MN的 ID以及 MAG2的 该步骤 402中， 组播源 MN确定即将发生切换， 即确定即将从当前接入的 MAG1切换到 MAG2 , 也就是说组播源 MN从 MAG1所在网络的覆盖区域移动到 MAG2所在网络的覆盖区 域。
步骤 403、 MAG1发送扩展后的 HI消息 （ Handover Initiate Message, 切换初始化消息 ) 给 MAG2。
该步骤 403中， MAG1发送的 HI消息中包括组播源切换的指示信息、 组播源标识、 切换后组播模式的指示信息、 组播组地址以及组播源家乡地址。 进一步地， 在该 HI 消息 指示的组播模式为 RPT模式时， 该 HI消息还进一步包括 RP地址。
步骤 404、 MAG2接收到 HI消息后， 发送 HAck消息 （ Handover Acknowledge Message, 切换回复消息）给 MAG1。
该步骤 404中， HAck消息中包含 MAG2是否接受组播源切换的指示。 实际应用中， MAG2可能由于本地策略、不支持组播源切换、 负载过重等原因拒绝组播源切换。若 MAG2 同意组播源切换， 则建立 MAG1与 MAG2之间的双向隧道。
至此， MAG1与 MAG2之间建立双向隧道的流程结束。
进一步地， 本发明优选实施例中， 若确定切换后的组播模式为 RPT模式， 则 MAG2在 接收到 MAG1发送的 HI消息后， 可以预先根据该 HI消息中包括的 RP地址， 更新其与该 RP 对应的 LMA之间的组播路径。 通过 MAG2与 LMA之间的组播路径的预更新 , 进一步缩短了 组播源切换 MAG后引起的组播时延。
本发明实施例中，上述流程中涉及的 HI消息以及 HAck消息为扩展后的消息， 以下针对 HI消息以及 HAck消息的扩展方式进行详细说明。
本发明扩展后的 HI消息中增加了用于表示本次切换为组播切换且为组播源切换的指 示位。 此外， 扩展后的 HI消息还包含组播源 MN的标识和一个扩展的移动选项 （Mobility options ) 。 该移动选项包括： 切换后组播模式选择位 （对应 RPT模式、 SPT且不更新组播 树模式以及 SPT且组播树预更新模式之一） ， 组播组地址（可选） ， RP地址（可选） 、 组 播源家乡地址（可选） 。
RFC5568定义了 FMIPv6协议用于单播节点的快速切换的方案， 协议中定义了 HI/HAck 消息，用于在旧的接入路由器和新的接入路由器之间建立隧道、传输上下文，如组播源 MN 的标识、 Ipv4家乡地址等。 IETF Mipshop工作组对 PMIPv6中的快速切换方案进行了研究， 对 FMIPv6协议进行了扩展， 重新定义了 HI/HAck消息， 本发明实施例在此基础上进一步对 HI/HAck消息进行了扩展，用于实现本发明实施例中建立 MAG1以及 MAG2之间双向隧道的 目的。
具体地， 对 HI消息以及 HAck消息的扩展说明如下：
( 1 ) HI消息的扩展说明
HI消息由 MAG1发送给 MAG2, 用于发起组播源 MN的切换过程。
现有技术中定义的 HI消息的基本消息格式如图 5所示， 对应其中的字段说明如下：
Figure imgf000012_0001
根据本发明实施例提供的技术方案扩展后的 HI消息的基本消息格式如图 6所示， 该扩 展后的 HI消息在原有 HI消息中增加新的标志位 、 R, 并且在 Mobility Options (移动选项） 中增加新定义的组播源切换选项来实现。 其中：
M位： 表示移动组播切换请求。
R位： 表示是组播接收者的切换还是组播源的切换。
M=0, R=0: 单播节点的快速切换；
M=l , R=l : 组播接收者节点的快速切换；
M=l , R=0: 组播源的快速切换。
M=0, R=l : 不合法。
根据上述定义， 当 HI消息中的 M=l , R=0时，即表示组播源切换，此时， Mobility options 中需要包括新定义的组播源切换选项， 具体如图 7所示， 其中， 主要包括如下字段：
Option-Code (组播选项） ， 用于表示切换后组播模式， 例如， 可以定义为： "0" 表 示切换后组播模式为 RPT模式， "Γ，表示切换后组播模式为 SPT且不更新组播树模式， "2" 表示切换后组播模式为 SPT且组播树预更新模式； Multicast Address (组播组地址 ) ；
Multicast Source Home Address (组播源家乡地址） ， 即组播源发送组播数据包时使用 的地址。
RP Address ( RP的地址） ， 该字段在 Option-Code=0 时， 即选择 RPT模式时存在。
( 2 ) HAck消息的扩展说明
HAck消息由 MAG2发送给 MAG1 , 用于对 MAG1发送的 HI消息进行回复。
现有技术中定义的 HAck消息的基本消息格式如图 8所示， 对应其中的字段说明如下：
Figure imgf000013_0001
根据本发明实施例提供的技术方案扩展后的 HAck消息的基本消息格式如图 9所示， 该 扩展后的 HAck消息在原有 HAck消息中增加新的标志位 、 R, 用于表示对 HI消息的回复。 其中 M、 R位的定义与扩展的 HI消息中 M、 R的定义相同， 此处不再赘述。
图 3所述流程的步骤 303中， 根据确定的切换后组播模式以及建立的双向隧道， 组播来 自组播源的组播数据时， 根据确定的切换后组播模式的不同， 具体处理过程也有所不同， 以下针对上述三个不同的组播模式， 对该过程进行详细说明。
一、 切换后组播模式为 RPT模式时传输组播数据的流程
RPT模式下， MAG1需要把 RP地址传递给 MAG2, MAG2构建到 RP的路径。 当组播源
MN与 MAG2建立连接且完成绑定更新等过程之后，组播数据通过路径： Source (即组播源） →MAG2→LMA ( RP )→组播树传输到组播接收节点。
如图 10所示， RPT模式下传输组播数据， 主要包括如下步骤（该流程可接上述图 4所述 的双向隧道建立的流程） ：
步骤 1001、 组播源 MN断开与 MAG1的连接， 开始切换过程（即接入到 MAG2 )。
步骤 1002、 组播源 MN连接到 MAG2 , 组播数据由组播源 MN发送到 MAG2 , 再通过 MAG2与 MAG1之间的双向隧道传输到旧的组播树上， 通过该旧的组播树发送给组播接收 者。
此处， 旧的组播树即指该组播源 MN接入 MAG1时用于传输组播数据的组播路径。 步骤 1003、 MAG2根据现有流程向 LMA发送扩展的绑定更新消息 （PUB消息）， 更新
MAG2和 LMA之间的隧道， 请求 LMA作为组播源的 RP。
步骤 1004、 组播源 MN与 RP ( LMA )之间的路径更新完成， 组播数据开始沿着 source (即组播源 MN )→MAG2→LMA(RP)→组播树的路径进行转发。 步骤 1005、 MAG2与 MAGI之间的隧道措 i销 , MAG1向 LMA发送解除与组播源 MN绑定 的 PBU消息。
至此， RPT模式下传输组播数据的流程结束。
根据上述流程，在组播源 MN接入 MAG2后用于组播数据的组播路径建立完成之前， 即 组播源 MN与 RP ( LMA )之间的路径更新完成之前， MAG1通过建立的双向隧道接收 MAG2 转发的组播源 MN的组播数据， 并根据组播源接入时建立的组播路径传输该组播数据。 在 组播源接入 MAG2后用于组播数据的组播路径建立完成之后， 则釆用 MAG2与 RP ( LMA ) 之间的路径传输组播数据 , 并且撤销 MAG1与 MAG2之间建立的双向隧道。
二、 切换后组播模式为 SPT且不更新组播树模式时传输组播数据的流程
如图 1 1所示， SPT且不更新组播树模式下传输组播数据， 主要包括如下步骤（该流程 可接上述图 4所述的双向隧道建立的流程） ：
步骤 1101、 组播源 MN断开与 MAG1的连接， 开始切换过程。
步骤 1102、 组播源 MN连接到 MAG2 , 组播数据由组播源 MN发送到 MAG2 , 再通过 MAG2与 MAG1之间的双向隧道传输到旧的组播树上， 通过该旧的组播树发送给组播接收 者。
步骤 1103、 MAG2向 LMA发送 PMIPv6正常的绑定更新消息， 更新 MAG2和 LMA之间的 隧道。
此时， MAG1和 MAG2之间的隧道不撤销 , 组播源发往外界的数据一直保持由 source (组播源 MN ) → 02→ 01→组播树的路径传输到组播接收节点。
在该 SPT且不更新组播树模式下， 由于组播源 MN的移动速度很快， 因此， 选择 MAG1 一直作为组播树的根节点， 保持与组播源 MN的最新接入的 MAG之间建立隧道。 当组播源 MN再次发送切换时， 即从 MAG2切换到 MAG3 , 组播源 MN将 MAG3的地址通知 MAG1 , MAG1重新建立与 MAG3之间的双向隧道， 重复上述流程传输 MAG3转发的组播源 MN的组 播数据。 在 MAG1建立与 MAG3之间的双向隧道后， 需要撤销与 MAG2之间的双向隧道。
在该 SPT且不更新组播树模式下， 在组播源与 MAG2建立连接且完成绑定更新等过程 之前以及之后 , 组播数据发送到组播接收者对应的组播接收节点时通过的路径均为：
Source (组播源）→MAG2→MAG1→旧的组播树。
根据该方式， 无需重建组播树 , 减少了组播树建立的操作。
三、 切换后组播模式为 SPT且组播树预更新模式时传输组播数据的流程
如图 12所示， SPT且组播树预更新模式下传输组播数据， 主要包括如下步骤（该流程 可接上述图 4所述的双向隧道建立的流程） ：
步骤 1201、 MAG1发起组播树预先更新的过程， 该组播树预更新过程将在后续实施例 中详细描述， 此处暂不描述。 步骤 1202、 组播源 MN断开与 MAGI的连接， 开始切换过程。
步骤 1203、 组播源 MN连接到 MAG2, 组播数据开始由组播源 MN发送到 MAG2, 再通 过 MAG2与 MAG1之间的双向隧道传输到旧的组播树上， 通过该旧的组播树发送给组播接 收者。
步骤 1204、 MAG2向 LMA发送 PMIPv6正常的绑定更新消息。
步骤 1205、 组播源 MN的绑定更新以及组播树的更新均已完成， 组播数据开始沿着新 的组播树进行转发。
步骤 1206、 MAG2与 MAG1之间的隧道措 i销 , MAG1向 LMA发送解除与组播源 MN绑定 的 PBU消息。
至此， SPT且组播树预更新模式下传输组播数据的流程结束。
根据上述流程，在组播源接入 MAG2后用于组播数据的组播路径建立完成之前， MAG1 通过建立的双向隧道接收 MAG2转发的组播源的数据， 并根据组播源接入时建立的组播路 径组播该数据。 同时， 进行组播树的预更新流程， 在组播源接入 MAG2后用于组播数据的 组播路径建立完成之后， 则釆用新的组播路径（即更新后的组播树）传输组播数据。
以下对本发明实施例所涉及的组播树预更新流程进行详细说明：
组播树预更新过程由 MAG1接收到 MAG2发送的 HAck消息后发起， 即 MAG1根据组播 源接入时建立的组播路径以及 MAG2的地址， 触发建立该组播源接入 MAG2后用于组播数 据的组播路径， 即触发组播树更新过程。 具体地， MAG1在通过双向隧道接收的数据包中 或组播源直接发送的数据包中携带组播源切换指示以及 MAG2的地址信息， 并根据组播源 接入时建立的组播路径（即旧的组播树） ， 发送携带组播源切换指示以及 MAG2的地址信 息的数据包。 具体可以在数据包的 Ipv6逐跳选项头中携带组播源切换指示以及 MAG2的地 址信息。
在传统的 PMIPv6中， 节点在 PMIPv6域内移动时 IP地址是不发生变化的， 那么， 当组 播源移动到新的 MAG之后， 它仍然使用相同的 IP地址发送组播数据。 若系统中釆用需求驱 动、 显式加入的方法重建组播树， 则由于组播接收节点不知道移动节点发生了切换， 那么 也就不会重新发送加入消息， 这样就没有办法进行组播树重建。 而若釆用数据驱动、 扩散 剪枝的方式重建组播树， 则通过新的 MAG发送出去的组播数据包不能通过 RPF检查， 这样 也没有办法进行组播树重建。针对这个问题， 本发明实施例提出了一种 PMIPv6环境中更新 SPT树的方法。
如图 13所示， 组播源 （source ) 由接入点 1移动到接入点 2时分别对应的组播树（即组 播路径） ， 其中， 路径： 接入点 1对应的 DR→Routerl (路由 1 )→Router2→Router3→DR, 代表组播源切换之前的组播树， 即组播源接入接入点 1时的组播路径； 路径： 接入点 2对应 的 DR→Router4→Router2→Router3→DR, 代表预更新后的组播树， 即组播源接入接入点 2 后的组播路径。 由图 13可以看出， 与组播树相关的路由器可以分为以下四类： 1、 在旧的组播树中， 但不在新的组播树中， 例如 Router 1。
2、 在旧的组播树中， 也在新的组播树中， 但是接收组播数据的接口发生了改变， 例 如 Router 2。
3、 在旧的组播树中， 也在新的组播树中， 并且接收组播数据的接口没有发生改变， 例如 Router 3。
4、 不在旧的组播树中， 但在新的组播树中， 例如 Router 4。
根据本发明实施例， 当 MAG1获得 MAG2关于支持组播源切换的同意消息（ HAck消息） 之后， MAG1立即开始启动组播树的预更新过程， 不需要等待组播源与 MAG2建立连接。 这样做的目的是为了能够争取时间尽快地更新组播树， 减少组播源等待组播树更新的时 间。 在现有方法中， 组播树的更新势必会影响到旧组播树的使用， 新的组播树会导致旧组 播树的废弃。 而这是组播快速切换所不希望的， 因为在预更新组播树的过程中， 我们仍希 望使用旧的组播树来发送组播数据， 以达到减小组播服务停顿时延的目的。
为了克服以上的困难， 本发明实施例提供的技术方案中， 在进行组播树预更新时， 仍 然能从旧的组播树上接收数据。 为了实现此目的， 本发明对组播路由器上保存的 （S, G ) 路由状态进行了扩展， 使每个组播源对应的组播路由拥有两个接收组播数据的接口：
数据接收接口 Active interface ； 以及
预切换接口 pre-handover interface。
其巾：
Active interface是切换之前使用的接收组播数据的接口， 即路由器到组播源的旧接入 点 MAG1的 RPF接口。 此处， 旧接入点指组播源 MN在切换前接入的 MAG1。 在组播树预更 新的过程中， 路由器一直通过这个接口从旧的组播树中接收组播数据；
Pre-handover interface是路由器到组播源的新接入点 MAG2的 RPF接口。 此处， 新接入 点指组播源 MN在切换后接入的 MAG2。 在切换发生之前， pre-handover interface设置为空。 在预更新的过程中， 它被设置为路由器到 MAG2的 RPF接口。 当有组播数据通过此接口到 达时， 说明新的组播树已经开始工作， 此接口升级为 Active interface。
另外， 本发明实施例中， 当叶子路由器 （即组播树中的组播节点）发起到 MAG2的组 播加入请求时， 由于组播源的 IP地址不变， 如果按照普通方式发送加入 Join消息就会出现 问题。 为了能够通知沿途路由器向着 MAG2的方向转发此 Join消息， 路由器需要把 Join ( S, G )消息封装在以 MAG2为目的地址的 IP数据包中， 此 IP数据包的选项头中也需要携带含有 组播源切换选项的逐跳选项头。
如图 14所示， 组播树更新的具体过程， 主要包括如下步骤：
步骤 1401、 切换开始之前， 组播树路由器中 （S, G )状态的 Active interface设置为路 由器到组播源的旧接入点 MAG1的 RPF接口， pre-handover interface设置为空。 步骤 1402、 MAG1发起组播树预更新过程， 向组播数据的 Ipv6逐跳选项头中添加本发 明扩展的组播源切换选项，选项中包括组播源切换指示及组播源即将接入的 MAG2的地址。
该步骤 1402中， 扩展的组播源切换选项将在后续进行详细说明， 此处暂不描述。
步骤 1403、 当带有组播源切换选项的数据包到达第一组播节点时， 第一组播节点构建 用于生成组播树的 Join消息， 并将该数据包中携带的 MAG2的地址信息携带在 Join消息中转 发。
步骤 1404、接收到该 Join消息的第二组播节点根据该 Join消息携带的 MAG2的地址信息 更新组播路由， 并继续转发该 Join消息直至成功加入新的组播树， 即已根据 MAG2的地址 信息更新组播路由后的组播节点接收到该 Join消息。
该步骤 1404中， 当 Join消息到达 MAG2后， 如果此时组播源 MN还没有连接到 MAG2, 则 MAG2代替组播源 MN对该 Join消息进行处理， 具体处理过程遵照 PIM-SM协议 (即 RFC4601的内容） ， 此处不再详细描述。
完成上述步骤的处理之后， 网络中预先建立起了一个以组播源新接入点 MAG2为根的 组播树， 在这棵预更新的组播树中， 所有路由器（S, G )状态的 pre-handover interface均被 设置为路由器到组播源的新接入点 MAG2的 RPF接口。
至此， 组播树更新流程结束。
图 14所述流程包括的步骤 1403中， 第一组播节点将 MAG2的地址信息携带在 Join消息 中转发， 具体通过如下过程：
第一组播节点将该 Join消息封装在以 MAG2的地址为目的地址的数据包中， 并在该 数据包中携带组播源切换指示；
根据设定的上游邻居路由器地址转发携带组播源切换指示的数据包。
图 14所述流程包括的步骤 1404中，接收到该 Join消息的第二组播节点根据该 Join消 息携带的 MAG2的地址信息更新组播路由， 即根据 Join消息携带的 MAG2的地址信息， 将组播路由状态中的 Pre-handover Interface设置为到 MAG2的 RPF接口。 具体地， 更新组 播路由的过程如图 15所示， 包括如下步骤：
步骤 1501、 第二组播节点解析 Ipv6报文选项头中的组播源切换选项， 获取其中携带 的 MAG2的地址。
步骤 1502、第二组播节点判断自身是否存在与此组播服务对应的组播路由状态，若是， 执行步骤 1503; 若否， 执行步骤 1504。
该步骤 1502中， 若判断结果为是， 则对应以上所述的 Router2、 3类型， 即在旧的组 播树中、 也在新的组播树中的路由； 若判断结果为否， 则对应以上所述的 Rounter4类型， 即不在旧的组播树中、 但在新的组播树中， 其中， Rounter 1不会收到该 Join消息。 步骤 1503、 将此组播服务对应的组播路由状态中的 Pre-handover Interface设置为到 MAG2的 RPF接口， 并保持 Active Interface的状态不变。
步骤 1504、 创建与此组播服务对应的组播路由状态， 并将 Pre-handover Interface的状 态设置为到 MAG2的 RPF接口， 将 Active Interface的状态设置为空。
至此， 更新组播路由的流程结束。
完成上述流程后， 第二组播节点继续向着 MAG2的上游方向转发该 Join数据包。 具 体地， 在转发该 Join数据包时， 根据设定的上游邻居路由器地址转发。
图 14所述流程中涉及的扩展的组播源切换选项携带在 IP数据包的选项头中，具体地， IPv6逐跳选项头由 RFC 2460定义， 其格式如图 16所示， 在 options (选项）字段中， 本发 明定义了如下新的选项：
组播源切换选项。
组播源切换选项表示组播源即将发生切换， 其中包括组播源的新接入点 MAG2 的地 址， 具体地， 本发明实施例定义的组播源切换选项如图 17所示， 其中：
H表示组播源切换指示；
New access point's Address表示组播源的新接入点 MAG2的地址。
其余字段与现有字段含义相同， 此处不再赘述。
在图 14所述流程的执行过程中， 组播数据一直保持通过旧的组播树到达组播接收节 点。 当组播源在 MAG2完成绑定更新等操作之后， 组播数据开始沿着新的组播树转发， 即 开始从（S,G )状态的 pre-handover interface接口到达每个路由器。
当新组播树上的路由器首次从 pre-handover interface接口接收到组播数据时， 证明新的 组播树开始投入使用， 组播路由器需要进一步更新， 具体如图 18所示， 包括如下步骤： 步骤 1801、判断组播路由状态中的 Active Interface状态是否为空，若是，执行步骤 1804, 若否， 执行步骤 1802。
该步骤 1801中， 若判断结果为是， 则对应上述的 Router4类型， 即不在旧的组播树中、 但在新的组播树中的路由。
步骤 1802、 判断组播路由状态中的 Active Interface与 Pre-handover Interface是否相同， 若是， 执行步骤 1804, 若否， 执行步骤 1803。
该步骤 1802中， 当判断结果为是时， 则对应上述的 Router3类型， 即在旧的组播树中、 也在新的组播树中的路由； 若判断结果为否， 则对应上述的 Router2类型， 即在旧的组播树 中、 也在新的组播树中的路由。
步骤 1803、 向 Active Interface的方向发送剪枝消息， 将该路由器从组播树中剪掉。 步骤 1804、 根据 Pre-handover Interface的状态设置 Active Interface的状态， 并将 Pre-handover Interface的状态设置为空。 至此， 新旧组播树的交替工作完成， 组播数据沿着新的组播树转发。
通过图 18所述的流程， 第二组播节点根据 Join消息携带的 MAG2的地址信息更新组 播路由之后， 若首次通过 Pre-handover Interface接收到数据， 则在确定 Active Interface状 态为 或 Active Interface与 Pre-handover Interface相同时,将 Pre-handover Interface升级为 Active Interface (即才艮据 Pre-handover Interface的状态设置 Active Interface的状态） ， 并将 Pre-handover Interface的 态设置为空。
根据本发明实施例提供的上述技术方案，需要对 MAG1 (组播源切换前接入的 MAG )、 MAG2 (组播源切换后接入的 MAG ) 以及组播树预更新过程中组播路由器做相应的改进， 具体地， MAG1、 MAG2以及组播路由器上的操作分别如下：
一、 MAG1上的操作主要包括如下几个方面：
( 1 ) MAG1接收到组播源 MN发送的切换预告消息后， 提取出该组播源 MN的 ID以及 MAG2的 ID。 确定组播源切换后组播模式， 并准备好组播组地址， RP地址（选择 RPT模式 时） 、 组播源家乡地址等信息以待传输。
( 2 ) MAG1发送扩展的 HI消息给 MAG2, 该扩展的 HI消息中指示位 M=l , R=0, 表示 本切换为组播切换且为组播源切换。 另外， 扩展后的 HI消息还包含组播源 MN的 ID和一个 扩展的移动选项。 该扩展的移动选项中包括： 切换后组播模式选择位， 组播组地址， RP地 址（选择 RPT模式时） 、 组播源家乡地址等信息。
( 3 )接收从 MAG2返回的 HAck消息， 与 MAG2之间建立用于传输组播数据的双向隧 道。
( 4 )接收由 MAG2通过双向隧道转发过来的组播数据 ,按照切换之前的组播模式转发 组播数据。
( 5 )根据切换后组播模式的不同， 进行不同的操作：
RPT模式下： 当组播源在新位置的组播树更新完成之后， MAG1接到 MAG2的通知， 撤销 MAG1到 MAG2的双向隧道， 向 LMA发送解除与组播源 MN绑定的 PBU消息。
SPT且不更新组播树模式下： MAG1和 MAG2之间的隧道不撤销，组播源发往外界的数 据一直保持着 30^^→ 02→ 01→组播树的路径传输到组播接收节点。由于组播源移 动速度很快， MAG1—直作为组播树的根节点， 一直保持与组播源 MN的最新接入点 MAG2 之间建立隧道。 当组播源 MN发生第二次、 第三次 ... ...移动时， 它通过现有隧道把下一个 接入点的地址通知 MAGI , MAG1循环建立其到组播源 MN的新接入点 MAG之间的隧道， 组播数据通过新的隧道传输到 MAG1 , 继而传输到组播树上。 而 MAG1与组播源 MN上个接 入点的隧道随之撤销。
SPT且组播树预更新模式下： MAG1发起组播树预先更新的过程。 它向组 播数据的
Ipv6逐跳选项头中添加本发明扩展的组播源切换选项， 选项中包括组播源切换指示及组播 源即将接入的 MAG2的地址。 当组播源在新位置的组播树更新完成之后 , MAG1接到 MAG2 的通知， 撤销 MAG1到 MAG2的双向隧道， 向 LMA发送解除与组播源 MN绑定的 PBU消息。
二、 MAG2上的操作主要包括如下几个方面：
( 1 ) MAG2接收 MAG1发送过来的 HI消息， 通过解析该 HI消息确定本次切换为组播源 切换， 提取出其中携带的切换后组播模式信息、 组播组地址、 RP地址（选择 RPT模式时）、 组播源家乡地址等信息。 根据本地策略确定是否支持组播源切换、 负载是否过重等情况决 定是否接受切换。
( 2 )发送 HAck消息给 MAG1 , 包含 MAG2是否接受组播源切换的信息， 若 MAG2同意 切换， 则与 MAG1之间建立双向隧道。
( 3 )组播源 MN连接到 MAG2后， MAG2接收组播源发送的组播数据， 再通过 MAG2 与 MAG1之间的双向隧道传输给 MAG1。
( 4 ) MAG2根据切换后组播模式的不同， 执行不同的操作：
RPT模式下： MAG2向 LMA发送扩展的绑定更新消息， 请求 LMA作为组播源的 RP。 当 绑定更新等过程完成之后， MAG2向 MAG1通知停止组播数据的转发，撤销 MAG1到 MAG2 的双向隧道。
SPT且不更新组播树模式下： MAG2向 LMA发送 PMIPv6正常的绑定更新消息。 由于 组播源移动速度很快， MAG1和 MAG2之间的隧道不撤销 , 组播源发往外界的数据一直保 持着 source->MAG2->MAGl->组播树的路径传输到组播接收节点。 当组播源 MN再次发生 移动时， MAG2通过 MAG1和 MAG2之间的隧道把组播源 MN再次移动的新接入点 MAG的地 址通知 MAG1 , 当 MAG1与新接入点 MAG的隧道建立之后， 当前 MAG1与 MAG2之间的隧 道撤销。
SPT且组播树预更新模式下： MAG2向 LMAJ 送 PMIPv6正常的绑定更新消息。 组播树 更新的过程中，它接收特殊的 Join消息，如果此时组播源 MN还没有连接到 MAG2,则 MAG2 代替组播源 MN对 Join消息进行处理。 当组播树更新完成之后， 组播数据开始沿着新的组播 树进行转发， MAG2向 MAG1通知停止组播数据的转发， 撤销 MAG1到 MAG2的双向隧道。
三、 组播树预更新过程中组播路由器上的操作主要包括如下几个方面
( 1 )在切换开始之前， 组播树路由器中 （S, G )状态的 Active interface设置为路由器 到组播源旧就接入点 MAG1的 RPF接口， pre-handover interface设置为空。
( 2 )当叶子节点路由器（对应组播节点）接收到 MAG1发送的带有组播源切换选项的 组播数据后， 它需要解析组播源切换选项， 从中提取出 MAG2的地址， 构造 Join ( S, G ) 消息， 把 Join ( S, G )消息封装在以 MAG2为目的地址的 IP数据包中， IP数据包的 IPv6逐跳 选项头中携带组播源切换选项。最后， 它把这个用 IP报文封装的 Join消息向着 MAG2的方向 发送出去。 ( 3 ) 沿途路由器接收到用 IP报文封装的 Join消息后， 更新组播路由。 并接收从 MAG2 返回的对于 Join消息的回复， 网络中预先建立起了一个以组播源新接入点 MAG2为根的组 播树， 在这棵预更新的组播树中， 所有路由器（S, G )状态的 pre-handover interface均被设 置为路由器到组播源的新接入点 MAG2的 RPF接口。
( 4 )在组播树预更新的过程中， 从 Active interface接收并转发组播数据。 当组播源在
MAG2完成绑定更新等操作之后， 组播数据开始沿着新的组播树转发， 即开始从（S, G ) 状态的 pre-handover interface接口到达每个路由器。
( 5 ) 当新组播树上的路由器首次从 pre-handover interface接口接收到组播数据时， 证 明新的组播树开始投入使用， 进一步更新组播路由。
( 6 ) 新旧组播树的交替工作完成后， 路由器需要按照新的路径转发组播数据。
实施例二
本发明实施例二提供了一种传输组播数据的装置， 如图 19所示， 该装置包括： 切换预告消息接收单元 1901、 隧道建立单元 1902以及组播数据传输单元 1903;
其巾：
切换预告消息接收单元 1901 , 用于接收组播源从当前接入的第一移动接入网关 MAG 切换到第二 MAG之前发送的切换预告消息； 该切换预告消息携带该第二 MAG的标识信 息；
隧道建立单元 1902, 用于根据切换预告消息接收单元 1901接收的切换预告消息中携 带的第二 MAG的标识， 建立与该第二 MAG之间的双向隧道；
组播数据传输单元 1903 , 用于根据确定的切换后组播模式以及隧道建立单元 1902建 立的双向隧道， 组播来自该组播源的组播数据， 其中， 该切换后组播模式为该组播源切换 到第二 MAG后釆用的组播模式。
本发明实施例二提供的一个优选实施方式中， 图 19 所示装置包括的隧道建立单元 1902, 具体用于：
向第二 MAG发送切换初始化 HI消息，并在接收到该第二 MAG发送的切换回复 HAck 消息后， 建立与该第二 MAG之间的双向隧道。
本发明实施例二提供的一个优选实施方式中， 图 19 所示装置包括的隧道建立单元 1902, 具体用于：
向该第二 MAG发送包括组播源切换的指示信息、 组播源标识以及切换后组播模式的 指示信息的 HI消息。
本发明实施例二提供的一个优选实施方式中， 图 19 所示装置包括的隧道建立单元 1902, 具体用于：
向该第二 MAG发送还包括组播组地址以及组播源家乡地址的 HI消息， 并且在该 HI 消息指示的组播模式为共享树 RPT模式时， 该 HI消息还包括组播汇聚点 RP地址。 本发明实施例二提供的一个优选实施方式中， 图 19 所示装置包括的组播数据传输单 元 1903 , 具体用于：
确定该组播源接入到第一 MAG时釆用的组播模式；
在确定该组播源接入到第一 MAG时釆用的组播模式为 RPT模式时，确定切换后组播 模式为 RPT模式；
在确定该组播源接入到第一 MAG时釆用的组播模式为 SPT模式且确定该组播源的移 动速度大于设定阈值时， 确定切换后组播模式为 SPT且不更新组播树模式；
在确定该组播源接入到第一 MAG时釆用的组播模式为 SPT模式且确定该组播源的移 动速度不大于设定阈值时， 确定切换后组播模式为 SPT且组播树预更新模式。
本发明实施例二提供的一个优选实施方式中， 图 19 所示装置包括的组播数据传输单 元 1903 , 具体用于：
在确定的切换后组播模式为 RPT模式或 SPT且组播树预更新模式时， 在该组播源接 入该第二 MAG后用于组播数据的组播路径建立完成之前， 第一 MAG通过建立的该双向 隧道接收该第二 MAG转发的该组播源的数据 , 并根据该组播源接入时建立的组播路径组 播数据；
在确定的切换后组播模式为 SPT且不更新组播树模式时， 第一 MAG通过建立的该双 向隧道接收该第二 MAG转发的该组播源的数据， 并根据该组播源接入时建立的组播路径 组播该数据。
如图 20所示， 本发明实施例二提供的一个优选实施方式中， 图 19所示装置还可以进 一步包括：
组播树更新控制单元 1904,用于在确定的切换后组播模式为 SPT且组播树预更新模式 时， 在接收到第二 MAG发送的 HAck消息后， 根据该组播源接入时建立的组播路径以及 第二 MAG的地址， 触发建立该组播源接入第二 MAG后用于组播数据的组播路径。
本发明实施例二提供的一个优选实施方式中， 图 20 所示装置包括的组播树更新控制 单元 1904, 具体用于：
在组播源发送的数据包中携带组播源切换指示以及第二 MAG的地址信息， 并根据该 组播源接入时建立的组播路径， 向该组播路径上的组播节点发送携带组播源切换指示以及 该第二 MAG的地址信息的数据包。
本发明实施例二提供的一个优选实施方式中， 图 20 所示装置包括的组播树更新控制 单元 1904, 具体用于：
在组播源发送的数据包的 Ipv6逐跳选项头中携带组播源切换指示以及该第二 MAG的 地址信息。 如图 21所示， 本发明实施例二提供的一个优选实施方式中， 图 19所示装置还可以进 一步包括：
隧道撤销单元 1905 , 用于在确定的切换后组播模式为 RPT模式或 SPT且组播树预更新 模式时， 在组播源接入第二 MAG后用于组播数据的组播路径建立完成之后， 接收该第二 MAG发送的双向隧道撤销指示， 并根据该撤销指示撤销与第二 MAG之间的双向隧道。
应当理解， 以上传输组播数据的装置包括的单元仅为根据该装置实现的功能进行的逻 辑划分， 实际应用中， 可以进行上述单元的叠加或拆分。 并且该实施例提供的装置所实现 的功能与上述实施例一提供的传输组播数据的方法流程一一对应， 对于该装置所实现的更 为详细的处理流程， 在上述方法实施例一中已做详细描述， 此处不再详细描述。
实施例三
本发明实施例三提供了一种传输组播数据的系统， 如图 22所示， 该系统主要包括： 组播源 2201、 第一移动接入网关 MAG 2202以及第二 MAG 2203；
组播源 2201 , 用于在从当前接入的第一 MAG切换到第二 MAG之前， 向第一 MAG
2202发送的切换预告消息； 该切换预告消息携带第二 MAG 2203的标识信息；
第一 MAG 2202 , 用于根据组播源 2201发送的切换预告消息中携带的第二 MAG 2203的 标识， 建立与第二 MAG 2203之间的双向隧道； 并根据确定的切换后组播模式以及建立的 双向隧道， 组播来自组播源的组播数据， 其中， 切换后组播模式为组播源切换到第二 MAG
2203后釆用的组播模式。
应当理解，以上传输组播数据的系统包括的第一 MAG所实现的功能与上述实施例二提 供的传输组播数据的装置对应，对于该第一 MAG所实现的更为详细的处理流程，在上述实 施例二中已做详细描述， 此处不再详细描述。
实施例四
本发明实施例四提供了一种组播树的更新系统， 如图 23所示， 该系统主要包括： 第一组播节点 2301以及第二组播节点 2302;
其中：
第一组播节点 2301 , 用于接收第一移动接入网关 MAG发送的数据包， 在确定该数据 包中携带组播源切换指示后， 构建用于生成组播树的加入 Join消息， 并将数据包中携带的 第二 MAG的地址信息携带在 Join消息中转发；
第二组播节点 2302 , 用于接收第一组播节点 2301转发的 Join消息， 根据该 Join消息 携带的第二 MAG的地址信息更新组播路由，并继续转发该 Join消息直至已根据第二 MAG 的地址信息更新组播路由后的组播节点接收到 Join消息。
本发明实施例四提供的一个优选实施方式中， 图 23 所示系统包括的第一组播节点 2301 , 具体用于： 将 Join消息封装在以第二 MAG的地址为目的地址的数据包中， 并在数据包中携带组 播源切换指示， 并根据设定的上游邻居路由器地址转发携带组播源切换指示的数据包。
本发明实施例四提供的一个优选实施方式中， 图 23 所示系统包括的第二组播节点
2302 , 具体用于：
根据 Join消息携带的第二 MAG的地址信息， 将此组播服务对应的组播路由状态中的 预切换接口 Pre-handover Interface设置为到第二 MAG的反向路径转发 RPF接口。
本发明实施例四提供的一个优选实施方式中， 图 23 所示系统包括的第二组播节点 2302 , 具体用于：
确定自身是否存在与此组播服务对应的组播路由状态；
在确定存在与此组播服务对应的组播路由状态时， 将组播路由状态中的 Pre-handover
Interface设置为到第二 MAG的 RPF接口；
在确定不存在与此组播服务对应的组播路由状态时， 创建组播路由状态， 并将组播路 由状态中的 Pre-handover Interface的状态设置为到第二 MAG的 RPF接口， 将组播路由状 态中的数据接收接口 Active Interface的状态设置为空。
本发明实施例四提供的一个优选实施方式中， 图 23 所示系统包括的第二组播节点
2302 , 还用于：
在根据 Join消息携带的第二 MAG的地址信息更新组播路由之后， 若在首次通过 Pre-handover Interface接收到数据， 在确定组播路由状态中的 Active Interface状态为空或 Active Interface与 Pre-handover Interface相同时, 才艮据 Pre-handover Interface的状态设置 Active Interface的状态， 并将 Pre-handover Interface的状态设置为空。
本发明实施例提供的上述技术方案， 在组播源切换之前， MAG1通过扩展的切换发起
( HI )和切换应答（HAck )信令消息， 提前把组播源的组播组地址、 RP地址、 组播模式 选择方式等信息发送到 MAG2 , 并预先在 MAG1和 MAG2之间建立一条双向隧道。 在组播 源完成绑定更新、 认证、 组播树重建等过程之前， 组播数据通过组播源→MAG2→MAG1 的路径传输到原来的组播树上， 从而转发到组播接收节点。 这样， 最小化了组播服务的停 顿时间， 一旦组播源与 MAG2建立连接， 组播服务即可恢复。 当使用 SPT且组播树更新模 式时， 根据本发明实施例提供的技术方案， 可以进行以下分析：
在现有技术情形下， 组播源切换的延迟为： 组播源 MN移动并连接到 MAG2的时间
+MAG2向 LMA绑定更新的时间 （包括 PBU、 PB A消息的发送、 传输、 LMA认证的时间） + 组播树重构的时间 （SPT模式） 。 而在使用本方案情形下， 组播源的切换延迟仅为： 组播 源 MN移动并连接到 MAG2的时间。 可见， 本方案有效地减少了组播源的切换延迟， 达到了 在尽可能小的时延内恢复组播服务的目的。 此外， 当使用 SPT且组播树更新模式时， 由于 在切换之初就开始了组播树的预更新工作， 这也有效减小了组播源等待组播树重构的时 间。
进一步地， 本发明补充完善了现有技术的切换后组播模式。 针对现实中切换的不同情 况， 本发明定义了三种切换后组播模式： RPT模式、 SPT且不更新组播树模式以及 SPT且组 播树预更新模式。 每种模式针对于不同的现实情况釆取不同的切换方式， 这样能够更加贴 合实际， 可用性更高， 避免了网络资源浪费、 组播服务延迟过长等情况。
进一步地， 本发明还定义了一种预先更新 SPT的方法， 在移动节点发生切换之前就启 动组播树的预更新工作， 预先进行组播树的重建， 减小了更新组播树需要的时延。 而且实 现了组播树预更新的过程中不影响旧的组播树， 利用旧的组播树来转发数据。 本发明克服 了组播源移动过程中组播源地址不变的情况下 RPF检测失效的问题， 保证了组播源移动对 组播接收者透明。减小了组播源 MN切换到 MAG2后等待组播树更新的时间，避免了组播树 更新过程中组播数据的丢失。
本领域内的技术人员应明白， 本发明的实施例可提供为方法、 系统、 或计算机程序产 品。 因此， 本发明可釆用完全硬件实施例、 完全软件实施例、 或结合软件和硬件方面的实 施例的形式。 而且， 本发明可釆用在一个或多个其中包含有计算机可用程序代码的计算机 可用存储介盾 （包括但不限于磁盘存储器、 CD-ROM、 光学存储器等）上实施的计算机程 序产品的形式。
本发明是参照根据本发明实施例的方法、 设备（系统）、 和计算机程序产品的流程图 和 /或方框图来描述的。 应理解可由计算机程序指令实现流程图和 /或方框图中的每一流 程和 /或方框、 及流程图和 /或方框图中的流程和 /或方框的结合。 可提供这些计算机程 序指令到通用计算机、 专用计算机、 嵌入式处理机或其他可编程数据处理设备的处理器以 产生一个机器， 使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于 实现在流程图一个或多个流程和 /或方框图一个或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方 式工作的计算机可读存储器中， 使得存储在该计算机可读存储器中的指令产生包括指令装 置的制造品， 该指令装置实现在流程图一个流程或多个流程和 /或方框图一个方框或多个 方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上， 使得在计算机 或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理， 从而在计算机或其他 可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 /或方框图一个 方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例， 但本领域内的技术人员一旦得知了基本创造性概 念， 则可对这些实施例作出另外的变更和修改。 所以， 所附权利要求意欲解释为包括优选 实施例以及落入本发明范围的所有变更和修改。

Claims

权 利 要 求
1、 一种传输组播数据的方法， 其特征在于， 包括：
第一移动接入网关 MAG接收组播源从当前接入的第一 MAG切换到第二 MAG之前 发送的切换预告消息， 所述切换预告消息携带所述第二 MAG的标识信息；
第一 MAG # ^据所述切换预告消息中携带的所述第二 MAG的标识， 建立与所述第二
MAG之间的双向隧道； 并
根据确定的切换后组播模式以及建立的所述双向隧道， 组播来自所述组播源的组播数 据， 其中， 所述切换后组播模式为所述组播源切换到所述第二 MAG后釆用的组播模式。
2、 如权利要求 1所述的方法， 其特征在于， 第一 MAG建立与所述第二 MAG之间的 双向隧道， 包括：
第一 MAG向所述第二 MAG发送切换初始化 HI消息， 并在接收到所述第二 MAG发 送的切换回复 HAck消息后， 建立与所述第二 MAG之间的双向隧道。
3、 如权利要求 2 所述的方法， 其特征在于， 在确定的切换后组播模式为最短路径树 SPT且组播树预更新模式时， 还包括：
第一 MAG在接收到所述第二 MAG发送的 HAck消息后， 根据所述组播源接入时建 立的组播路径以及所述第二 MAG的地址， 触发建立所述组播源接入所述第二 MAG后用 于组播数据的组播路径。
4、 如权利要求 3所述的方法， 其特征在于， 第一 MAG根据所述组播源接入时建立的 组播路径以及所述第二 MAG的地址， 触发建立所述组播源接入所述第二 MAG后用于组 播数据的组播路径， 包括：
第一 MAG在组播源发送的数据包中携带组播源切换指示以及所述第二 MAG的地址 信息；
根据所述组播源接入时建立的组播路径 , 向所述组播路径上的组播节点发送携带所述 组播源切换指示以及所述第二 MAG的地址信息的数据包。
5、 如权利要求 4所述的方法， 其特征在于， 第一 MAG在所述数据包的 Ipv6逐跳选 项头中携带组播源切换指示以及所述第二 MAG的地址信息。
6、 如权利要求 2所述的方法， 其特征在于， 所述 HI消息， 包括：
组播源切换的指示信息、 组播源标识以及切换后组播模式的指示信息。
7、 如权利要求 6所述的方法， 其特征在于， 所述 HI消息还包括： 组播组地址以及组 播源家乡地址；
所述 HI消息指示的组播模式为共享树 RPT模式时，所述 HI消息还包括：组播汇聚点 RP地址。
8、 如权利要求 7所述的方法， 其特征在于， 所述第二 MAG在接收到指示的组播模式 为 RPT模式并且还包括 RP地址的 HI消息时， 所述第二 MAG根据所述 HI消息中包括的 RP地址， 更新与所述 RP地址对应的本地移动锚点 LMA之间的组播路径。
9、 如权利要求 1所述的方法， 其特征在于， 确定切换后组播模式的方式， 包括： 确定所述组播源接入到所述第一 MAG时釆用的组播模式；
在确定所述组播源接入到所述第一 MAG时釆用的组播模式为 RPT模式时，确定切换 后组播模式为 RPT模式；
在确定所述组播源接入到所述第一 MAG时釆用的组播模式为 SPT模式且确定所述组 播源的移动速度大于设定阈值时， 确定切换后组播模式为 SPT且不更新组播树模式； 在确定所述组播源接入到所述第一 MAG时釆用的组播模式为 SPT模式且确定所述组 播源的移动速度不大于所述设定阈值时，确定切换后组播模式为 SPT且组播树预更新模式。
10、 如权利要求 9所述的方法， 其特征在于， 根据确定的切换后组播模式以及建立的 所述双向隧道， 组播来自所述组播源的组播数据， 包括：
在确定的切换后组播模式为 RPT模式或 SPT且组播树预更新模式时， 在所述组播源 接入所述第二 MAG后用于组播数据的组播路径建立完成之前， 第一 MAG通过建立的所 述双向隧道接收所述第二 MAG转发的所述组播源的数据， 并根据所述组播源接入时建立 的组播路径组播所述数据；
在确定的切换后组播模式为 SPT且不更新组播树模式时， 第一 MAG通过建立的所述 双向隧道接收所述第二 MAG转发的所述组播源的数据， 并根据所述组播源接入时建立的 组播路径组播所述数据。
11、 如权利要求 10所述的方法， 其特征在于， 若确定的切换后组播模式为 RPT模式 或 SPT且组播树预更新模式， 则在所述组播源接入所述第二 MAG后用于组播数据的组播 路径建立完成之后， 还包括：
接收所述第二 MAG发送的双向隧道撤销指示， 并根据所述撤销指示撤销与所述第二 MAG之间的双向隧道。
12、 一种组播树的更新方法， 其特征在于， 包括：
第一组播节点接收第一移动接入网关 MAG发送的数据包；
在确定所述数据包中携带组播源切换指示后， 构建用于生成组播树的加入 Join消息， 并将所述数据包中携带的第二 MAG的地址信息携带在所述 Join消息中转发；
接收到所述 Join消息的第二组播节点根据所述 Join消息携带的第二 MAG的地址信息 更新组播路由； 并
继续转发所述 Join消息直至已根据所述第二 MAG的地址信息更新组播路由后的组播 节点接收到所述 Join消息。
13、如权利要求 12所述的方法，其特征在于，所述组播源切换指示以及所述第二 MAG 的地址信息携带在所述数据包的 Ipv6逐跳选项头中。
14、 如权利要求 12 所述的方法， 其特征在于， 第一组播节点将所述数据包中携带的 第二 MAG的地址信息携带在所述 Join消息中转发， 包括：
第一组播节点将所述 Join 消息封装在以所述第二 MAG 的地址为目的地址的数据包 中， 并在所述数据包中携带组播源切换指示；
根据设定的上游邻居路由器地址转发携带组播源切换指示的数据包。
15、 如权利要求 12所述的方法， 其特征在于， 接收到所述 Join消息的第二组播节点 根据所述 Join消息携带的第二 MAG的地址信息更新组播路由， 包括：
第二组播节点根据所述 Join消息携带的第二 MAG的地址信息， 将此组播服务对应的 组播路由状态中的预切换接口 Pre-handover Interface设置为到所述第二 MAG的反向路径 转发 RPF接口。
16、 如权利要求 15所述的方法， 其特征在于， 第二组播节点根据所述 Join消息携带 的第二 MAG的地址信息， 将此组播服务对应的组播路由状态中的 Pre-handover Interface 设置为到所述第二 MAG的 RPF接口， 包括：
第二组播节点确定自身是否存在与此组播服务对应的组播路由状态；
在确定存在与此组播服务对应的组播路由状态时， 将所述组播路由状态中的 Pre-handover Interface设置为到所述第二 MAG的 RPF接口；
在确定不存在与此组播服务对应的组播路由状态时， 创建组播路由状态， 并将所述组 播路由状态中的 Pre-handover Interface的状态设置为到所述第二 MAG的 RPF接口， 将所 述组播路由状态中的数据接收接口 Active Interface的状态设置为空。
17、 如权利要求 16所述的方法， 其特征在于， 第二组播节点根据所述 Join消息携带 的第二 MAG的地址信息更新组播路由之后， 还包括：
第二组播节点首次通过所述 Pre-handover Interface接收到数据；
在确定组播路由状态中的 Active Interface 状态为空或所述 Active Interface 与
Pre-handover Interface相同时， 才艮据所述 Pre-handover Interface 的状态设置所述 Active Interface的状态， 并将所述 Pre-handover Interface的状态设置为空。
18、 一种传输组播数据的系统， 其特征在于， 包括：
组播源、 第一移动接入网关 MAG以及第二 MAG;
所述组播源，用于在从当前接入的第一 MAG切换到第二 MAG之前，向所述第一 MAG 发送的切换预告消息， 所述切换预告消息携带所述第二 MAG的标识信息；
所述第一 MAG,用于根据所述组播源发送的切换预告消息中携带的所述第二 MAG的 标识， 建立与所述第二 MAG之间的双向隧道； 并根据确定的切换后组播模式以及建立的 所述双向隧道， 组播来自所述组播源的组播数据， 其中， 所述切换后组播模式为所述组播 源切换到所述第二 MAG后釆用的组播模式。
19、 一种传输组播数据的装置， 其特征在于， 包括：
切换预告消息接收单元， 用于接收组播源从当前接入的第一移动接入网关 MAG切换 到第二 MAG之前发送的切换预告消息， 所述切换预告消息携带所述第二 MAG的标识信 息；
隧道建立单元， 用于根据所述切换预告消息接收单元接收的切换预告消息中携带的所 述第二 MAG的标识， 建立与所述第二 MAG之间的双向隧道；
组播数据传输单元， 用于根据确定的切换后组播模式以及所述隧道建立单元建立的所 述双向隧道， 组播来自所述组播源的组播数据， 其中， 所述切换后组播模式为所述组播源 切换到所述第二 MAG后釆用的组播模式。
20、 如权利要求 19所述的装置， 其特征在于， 所述隧道建立单元， 具体用于： 向所述第二 MAG发送切换初始化 HI消息，并在接收到所述第二 MAG发送的切换回 复 HAck消息后， 建立与所述第二 MAG之间的双向隧道。
21、 如权利要求 20所述的装置， 其特征在于， 所述隧道建立单元， 具体用于： 向所述第二 MAG发送包括组播源切换的指示信息、 组播源标识以及切换后组播模式 的指示信息的 HI消息。
22、 如权利要求 21所述的装置， 其特征在于， 所述隧道建立单元， 具体用于： 向所述第二 MAG发送还包括组播组地址以及组播源家乡地址的 HI消息，并且在所述 HI消息指示的组播模式为共享树 RPT模式时， 所述 HI消息还包括组播汇聚点 RP地址。
23、 如权利要求 20所述的装置， 其特征在于， 还包括：
组播树更新控制单元，用于在确定的切换后组播模式为最短路径树 SPT且组播树预更 新模式时， 在接收到所述第二 MAG发送的 HAck消息后， 根据所述组播源接入时建立的 组播路径以及所述第二 MAG的地址， 触发建立所述组播源接入所述第二 MAG后用于组 播数据的组播路径。
24、 如权利要求 23所述的装置， 其特征在于， 所述组播树更新控制单元， 具体用于： 在组播源发送的数据包中携带组播源切换指示以及所述第二 MAG的地址信息， 并根 据所述组播源接入时建立的组播路径 , 向所述组播路径上的组播节点发送携带所述组播源 切换指示以及所述第二 MAG的地址信息的数据包。
25、 如权利要求 24所述的装置， 其特征在于， 所述组播树更新控制单元， 具体用于： 在组播源发送的数据包的 Ipv6逐跳选项头中携带组播源切换指示以及所述第二 MAG 的地址信息。
26、 如权利要求 19所述的装置， 其特征在于， 所述组播数据传输单元， 具体用于： 确定所述组播源接入到第一 MAG时釆用的组播模式；
在确定所述组播源接入到第一 MAG时釆用的组播模式为 RPT模式时，确定切换后组 播模式为 RPT模式；
在确定所述组播源接入到第一 MAG时釆用的组播模式为 SPT模式且确定所述组播源 的移动速度大于设定阈值时， 确定切换后组播模式为 SPT且不更新组播树模式；
在确定所述组播源接入到第一 MAG时釆用的组播模式为 SPT模式且确定所述组播源 的移动速度不大于所述设定阈值时， 确定切换后组播模式为 SPT且组播树预更新模式。
27、 如权利要求 26所述的装置， 其特征在于， 所述组播数据传输单元， 具体用于： 在确定的切换后组播模式为 RPT模式或 SPT且组播树预更新模式时， 在所述组播源 接入所述第二 MAG后用于组播数据的组播路径建立完成之前， 第一 MAG通过建立的所 述双向隧道接收所述第二 MAG转发的所述组播源的数据， 并根据所述组播源接入时建立 的组播路径组播所述数据；
在确定的切换后组播模式为 SPT且不更新组播树模式时， 第一 MAG通过建立的所述 双向隧道接收所述第二 MAG转发的所述组播源的数据， 并根据所述组播源接入时建立的 组播路径组播所述数据。
28、 如权利要求 27所述的装置， 其特征在于， 还包括：
隧道撤销单元， 用于在确定的切换后组播模式为 RPT模式或 SPT且组播树预更新模 式时， 在所述组播源接入所述第二 MAG后用于组播数据的组播路径建立完成之后， 接收 所述第二 MAG发送的双向隧道撤销指示， 并根据所述撤销指示撤销与所述第二 MAG之 间的双向隧道。
29、 一种组播树的更新系统， 其特征在于， 包括：
第一组播节点， 用于接收第一移动接入网关 MAG发送的数据包， 在确定所述数据包 中携带组播源切换指示后， 构建用于生成组播树的加入 Join消息， 并将所述数据包中携带 的第二 MAG的地址信息携带在所述 Join消息中转发；
第二组播节点， 用于接收所述第一组播节点转发的所述 Join消息，根据所述 Join消息 携带的第二 MAG的地址信息更新组播路由， 并继续转发所述 Join消息直至已根据所述第 二 MAG的地址信息更新组播路由后的组播节点接收到所述 Join消息。
30、 如权利要求 29所述的系统， 其特征在于， 所述第一组播节点， 具体用于： 将所述 Join消息封装在以所述第二 MAG的地址为目的地址的数据包中， 并在所述数 据包中携带组播源切换指示， 并根据设定的上游邻居路由器地址转发携带组播源切换指示 的数据包。
31、 如权利要求 29所述的系统， 其特征在于， 所述第二组播节点， 具体用于： 根据所述 Join消息携带的第二 MAG的地址信息， 将此组播服务对应的组播路由状态 中的预切换接口 Pre-handover Interface设置为到所述第二 MAG的反向路径转发 RPF接口。
32、 如权利要求 31所述的系统， 其特征在于， 所述第二组播节点， 具体用于： 确定自身是否存在与此组播服务对应的组播路由状态；
在确定存在与此组播服务对应的组播路由状态时， 将所述组播路由状态中的 Pre-handover Interface设置为到所述第二 MAG的 RPF接口；
在确定不存在与此组播服务对应的组播路由状态时， 创建组播路由状态， 并将所述组 播路由状态中的 Pre-handover Interface的状态设置为到所述第二 MAG的 RPF接口， 将所 述组播路由状态中的数据接收接口 Active Interface的状态设置为空。
33、 如权利要求 32所述的系统， 其特征在于， 所述第二组播节点， 还用于： 在根据所述 Join消息携带的第二 MAG的地址信息更新组播路由之后， 若在首次通过 所述 Pre-handover Interface接收到数据， 在确定组播路由状态中的 Active Interface状态为 或所述 Active Interface与 Pre-handover Interface相同时, 才艮据所述 Pre-handover Interface 的状态设置所述 Active Interface的状态， 并将所述 Pre-handover Interface的状态设置为空。
PCT/CN2011/084296 2010-12-20 2011-12-20 传输组播数据的方法、组播树的更新方法以及系统和装置 WO2012083844A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2013545027A JP2014502116A (ja) 2010-12-20 2011-12-20 マルチキャストデータを伝送する方法、マルチキャストツリーの更新方法及びシステム並びに装置
US13/995,851 US9265029B2 (en) 2010-12-20 2011-12-20 Method of transferring multicast data, updating method of multicast tree, system and device thereof
EP11850637.7A EP2658296B1 (en) 2010-12-20 2011-12-20 Method of transferring multicast data, updating method of multicast tree, system and device thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010597699.6 2010-12-20
CN201010597699.6A CN102547582B (zh) 2010-12-20 2010-12-20 传输组播数据的方法、组播树的更新方法以及系统和装置

Publications (1)

Publication Number Publication Date
WO2012083844A1 true WO2012083844A1 (zh) 2012-06-28

Family

ID=46313171

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/084296 WO2012083844A1 (zh) 2010-12-20 2011-12-20 传输组播数据的方法、组播树的更新方法以及系统和装置

Country Status (5)

Country Link
US (1) US9265029B2 (zh)
EP (1) EP2658296B1 (zh)
JP (2) JP2014502116A (zh)
CN (1) CN102547582B (zh)
WO (1) WO2012083844A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103118098B (zh) * 2013-01-25 2016-05-25 清华大学 基于预测的多连接移动节点接口切换方法
US9407583B2 (en) 2013-03-15 2016-08-02 Red Hat, Inc. Handling unavailable destinations in a messaging network
US9112824B2 (en) * 2013-03-15 2015-08-18 Red Hat, Inc. Forwarding multicast messages in a messaging network
US9503272B2 (en) * 2014-03-13 2016-11-22 Cisco Technology, Inc. Fast convergence with multicast source mobility
US9848317B2 (en) 2015-11-25 2017-12-19 Viasat, Inc. Multicast handover for mobile communications
CN106992935B (zh) * 2016-01-20 2019-09-24 上海诺基亚贝尔股份有限公司 在dam系统中建立运营商组播树的方法和设备
CN113973076B (zh) * 2020-07-24 2023-01-06 华为技术有限公司 一种多播切换方法及装置
CN114466318B (zh) * 2022-01-30 2023-04-07 西安电子科技大学 组播服务有效认证和密钥分配协议实现方法、系统及设备
CN115134287A (zh) * 2022-06-30 2022-09-30 中国电信股份有限公司 组播状态和数据管理方法和系统、控制器和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159751A (zh) * 2007-11-14 2008-04-09 中兴通讯股份有限公司 一种通过ip交换网传送时分复用业务的方法和装置
CN101873658A (zh) * 2009-04-21 2010-10-27 华为技术有限公司 移动组播切换的方法和设备
CN101909276A (zh) * 2009-06-04 2010-12-08 中国移动通信集团公司 一种移动组播切换方法、系统及相关设备

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054646B2 (en) * 2002-10-17 2006-05-30 Nokia Corporation Transmission method in a communication system
US7644177B2 (en) * 2003-02-28 2010-01-05 Cisco Technology, Inc. Multicast-routing-protocol-independent realization of IP multicast forwarding
GB0308980D0 (en) * 2003-04-17 2003-05-28 Orange Personal Comm Serv Ltd Telecommunications
EP1667381A4 (en) * 2003-07-07 2011-07-27 Ntt Docomo Inc COMMUNICATION SYSTEM, MULTICAST OPERABLE ROUTER, TRANSMITTER TERMINAL, RECEIVER TERMINAL, AND COMMUNICATION METHOD
GB2406462A (en) * 2003-09-25 2005-03-30 Nokia Corp Multicasting apparatus
JP2006074379A (ja) * 2004-09-01 2006-03-16 Ntt Docomo Inc サーバ装置、送信端末、移動通信システム及び移動通信方法
KR100663451B1 (ko) * 2004-11-09 2007-01-02 삼성전자주식회사 이동 인터넷 프로토콜 통신 시스템에서 소스 노드의핸드오프에 따른 멀티캐스트 서비스 제공 방법
WO2006103719A1 (ja) * 2005-03-25 2006-10-05 Fujitsu Limited マルチキャスト通信システム
WO2007123227A1 (ja) * 2006-04-21 2007-11-01 Panasonic Corporation マルチキャストパケット転送装置及びマルチキャストパケット管理装置並びにマルチキャストパケット受信装置
US8279829B2 (en) * 2006-10-10 2012-10-02 Futurewei Technologies, Inc. Multicast fast handover
KR100862722B1 (ko) * 2006-12-08 2008-10-10 한국전자통신연구원 네트워크기반의 지역 이동성 관리기법에 의한 빠른핸드오버 방법 및 시스템
CN101212773B (zh) * 2006-12-31 2011-01-05 华为技术有限公司 一种支持移动网络移动的方法和系统
CN101647230B (zh) * 2007-04-04 2013-02-20 汤姆森许可贸易公司 多跳中继网络中的组播通信的方法和设备
EP2161883A1 (en) * 2007-05-28 2010-03-10 Sharp Kabushiki Kaisha Communication system using network base ip mobility protocol, control device, router, and communication method thereof
US20090036152A1 (en) * 2007-07-31 2009-02-05 Motorola, Inc. Method for enabling multicast traffic flows over hybrid multicast capable and non-multicast capable radio access networks (rans)
US9160547B2 (en) * 2008-10-15 2015-10-13 Orange Method and devices for managing a data flow transfer
JP5350481B2 (ja) * 2008-10-23 2013-11-27 テレフオンアクチーボラゲット エル エム エリクソン（パブル） マルチキャストサービス用のモビリティ処理
EP2207379A1 (en) * 2009-01-09 2010-07-14 Alcatel, Lucent Method for handover of a mobile node in a communications network
JP5191936B2 (ja) * 2009-03-24 2013-05-08 Ｋｄｄｉ株式会社 ハンドオーバ制御システム、ｍａｇおよびハンドオーバ制御方法
IN2012DN03097A (zh) * 2009-10-06 2015-09-18 Nortel Networks Ltd
CN102387584B (zh) * 2010-08-31 2014-10-22 株式会社日立制作所 移动接入网关及其快速切换方法、代理移动IPv6系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101159751A (zh) * 2007-11-14 2008-04-09 中兴通讯股份有限公司 一种通过ip交换网传送时分复用业务的方法和装置
CN101873658A (zh) * 2009-04-21 2010-10-27 华为技术有限公司 移动组播切换的方法和设备
CN101909276A (zh) * 2009-06-04 2010-12-08 中国移动通信集团公司 一种移动组播切换方法、系统及相关设备

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
JP6381565B2 (ja) 2018-08-29
EP2658296A1 (en) 2013-10-30
JP2016106501A (ja) 2016-06-16
EP2658296B1 (en) 2019-03-06
US20130279397A1 (en) 2013-10-24
JP2014502116A (ja) 2014-01-23
EP2658296A4 (en) 2016-12-14
CN102547582A (zh) 2012-07-04
CN102547582B (zh) 2014-12-10
US9265029B2 (en) 2016-02-16

Similar Documents

Publication Publication Date Title
WO2012083844A1 (zh) 传输组播数据的方法、组播树的更新方法以及系统和装置
US8102792B2 (en) Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address
KR101216757B1 (ko) 하이브리드 멀티캐스팅 가능하고 비-멀티캐스팅 가능한 ｒａｎｓ를 통한 멀티캐스트 트래픽 흐름을 가능하게 하기 위한 방법
JP4066867B2 (ja) 移動ノード、パケット中継装置、パケット転送方法
KR100663451B1 (ko) 이동 인터넷 프로토콜 통신 시스템에서 소스 노드의핸드오프에 따른 멀티캐스트 서비스 제공 방법
WO2014106314A1 (zh) 组播源的注册、组播路径的建立方法及装置
JP4543097B2 (ja) セッションアウェア接続制御方法および装置
JP2007531356A (ja) モバイルネットワークノードにおける経路最適化マルチキャストトラフィック
WO2009006825A1 (fr) Procédé de transfert, procédé pour rejoindre un groupe de multidiffusion et routeur d'accès dans le protocole proxy mobile ip
WO2013056669A1 (zh) 在组播接收端切换场景下建立优化路径的方法及系统
WO2006076862A1 (fr) Systeme pour creer un service de multidiffusion au moyen d'un hote mobile et procede associe
JP4468424B2 (ja) シームレスなハンドオーバのための方法及び装置
US9160547B2 (en) Method and devices for managing a data flow transfer
KR20120011803A (ko) 이동 통신 시스템에서 이동 노드에 대한 멀티캐스트 서비스 제공 방법 및 장치
JP3668130B2 (ja) マルチキャスト通信装置及びマルチキャスト通信方法
JP2009017545A (ja) 移動エンティティ通信におけるシームレスなハンドオーバ方法および装置
CN103888910B (zh) 组播树的更新方法以及系统
WO2013053334A1 (zh) 一种为组播数据建立优化路径的方法及系统
KR101407669B1 (ko) 망 기반 이동성 관리 시스템 및 모바일 멀티캐스트 서비스 핸드오버 방법
Yoo et al. Fast handover mechanism for seamless multicasting services in mobile IPv6 wireless networks
Singh et al. Core based tree multicast (M-CBT) approach in supporting mobility
KR20090050396A (ko) 통신 시스템에서 멀티캐스트 핸드오버 방법
KR20130037349A (ko) 모바일 라우터, 액세스 라우터 및 이를 이용한 멀티캐스트 데이터 전송 방법
Xia MULTIMOB Group H. Asaeda Internet-Draft Keio University Intended status: Standards Track P. Seite Expires: May 3, 2012 France Telecom
Takahashi et al. Multicast source handover scheme based on proxy router discovery

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: 11850637

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013545027

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13995851

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2011850637

Country of ref document: EP