WO2013053334A1 - 一种为组播数据建立优化路径的方法及系统 - Google Patents

一种为组播数据建立优化路径的方法及系统 Download PDF

Info

Publication number
WO2013053334A1
WO2013053334A1 PCT/CN2012/082880 CN2012082880W WO2013053334A1 WO 2013053334 A1 WO2013053334 A1 WO 2013053334A1 CN 2012082880 W CN2012082880 W CN 2012082880W WO 2013053334 A1 WO2013053334 A1 WO 2013053334A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
mag
belongs
tunnel
routing entry
Prior art date
Application number
PCT/CN2012/082880
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 中兴通讯股份有限公司
Publication of WO2013053334A1 publication Critical patent/WO2013053334A1/zh

Links

Classifications

    • 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
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/24—Interfaces between hierarchically similar devices between backbone network devices

Definitions

  • the present invention relates to the field of mobile communications, and in particular, to a method and system for establishing an optimized path for multicast data.
  • the emergence of multicast is to solve the efficiency problem that traditional unicast routing occurs when dealing with group communication.
  • Mobile multicast is developed from traditional fixed multicast, providing mobile users with mobile video conferencing, mobile online games, etc. Application can effectively improve data transmission efficiency.
  • Mobile multicast needs to solve two basic problems: one is group membership management, and the other is group member location management.
  • the current group membership management generally uses protocols such as the Internet Group Management Protocol (IGMP) (referred to as the Internet Group Management Protocol) or the Multicast Listener Discovery Protocol (MLD), and the group member location management is Use mobility management protocols such as mobile IP.
  • IGMP Internet Group Management Protocol
  • MLD Multicast Listener Discovery Protocol
  • IP multicast service models There are two types of IP multicast service models: Any Source Multicast ASM (full name Any-Source Multicast) and a specific source multicast SSM (full name Source-Specific Multicast).
  • ASM uses a multicast group address G to identify a multicast group. Each multicast group can have any number of multicast sources and receivers.
  • the aggregation point (RP, called Rendezvous Point) is used for the shared tree.
  • each channel can only have one specified source and any number of receivers. There is no need to select the aggregation point RP and the maintenance shared tree (RPT) in the SSM model.
  • the multicast source is registered, so that the SPT with the multicast source S as the root and the receiver as the leaf is directly constructed in the network, thereby eliminating the process of establishing the shared tree and then switching from the shared tree to the shortest path tree in the ASM model.
  • SSM is a simple and effective multicast model, which can overcome the shortcomings of ASM in access control, address allocation, source discovery, and vulnerability to DoS attacks. Therefore, SSM model is more scalable and can be used. Improve network performance in the future The Internet has a wider application prospect.
  • RPF reverse path forwarding
  • the RPF check process is as follows: The router that receives the multicast packet searches for the unicast routing table with the IP address of the multicast source as the destination address. The outbound interface in the corresponding entry is the RPF interface. The router considers that the RPF is configured by the RPF. The path that the multicast packet received by the interface is the shortest path from the multicast source to the local device. The RPF interface is compared with the interface where the multicast packet actually arrives.
  • the unicast routing information used as the basis for path judgment can be derived from any unicast routing protocol, multicast static route, or MBGP routing protocol.
  • IETF For mobile multicast, IETF is working on the PMIPv6-based mobile multicast mechanism in the MULTIMOB working group.
  • the multicast receiver MN The multicast source MN-S (MN-Source) is located in the same PMIPv6 domain, the multicast receiver MN is connected to the mobile access gateway MAG1, and the MN-S is connected to the mobile access gateway MAG2, the MN and the MN-S.
  • Topological anchors can be the same LMA or different LMAs.
  • the MN reports to the MAG1 that it needs to receive multicast data from the multicast source MN-S and sent to the multicast group G through the MLDv2 report message.
  • the MAG1 After receiving the MLDv2 Report 4 message, the MAG1 sends the channel subscription hop-by-hop to the multicast source MN-S.
  • the subscription message sent by the MAG1 to the LMA needs to be encapsulated in the tunnel.
  • the subscription message sent by the LMA to the MAG2 is also advertised. Tunnel encapsulation is required. All routers along the way create (HoA, G) multicast routing entries. HoA represents the address of the multicast source MN-S, and G represents the multicast address. Therefore, the multicast source MN-S is used as the root.
  • the path from the MAG2 to the LMA to which the multicast source MN-S belongs is a PMIPv6 tunnel, and the path from the LMA to the MAG1 to which the multicast receiver belongs is a ⁇ tunnel, followed by multicast.
  • the multicast data sent by the source MN-S arrives along the established SPT, and the multicast forwarding path is as shown in FIG.
  • the multicast packet sent by the MN-S to the ⁇ must first be sent through the ⁇ 6 tunnel between the MN-S mobile access gateway MAG2 and the local mobility anchor (LMA), and the multicast arrives. After the MN's mobility anchor LMA, it must pass the mobile access gateway of LMA and MN.
  • the PMIPv6 tunnel between the MAGIs is transmitted, so the SPT path 100 shown in FIG. 1 is not the shortest multicast forwarding path. Therefore, the current mobile multicast solution proposed based on PMIPv6 inevitably results in a non-shortest SPT path, which reduces routing efficiency and performance of mobile multicast. Summary of the invention
  • the embodiments of the present invention provide a method and system for establishing an optimized path for a multicast message, which solves the problem of low routing efficiency caused by a non-shortest SPT path that must be transmitted via a local mobility anchor in the related solution.
  • the present invention provides a method for establishing an optimized path for a multicast packet, including:
  • a multicast tunnel is established between the mobile access gateway (MAG) to which the multicast receiver (MN) belongs and the MAG to which the multicast source (MN-S) belongs, and the MAG to which the MN-S belongs receives the MN- After the multicast message sent by the S, the multicast message is sent to the MAG to which the MN belongs by using the multicast tunnel.
  • MAG mobile access gateway
  • MN-S multicast source
  • the method further includes: after the establishment of the multicast tunnel, the MAG to which the MN belongs determines whether the local channel group corresponding to the channel information exists according to the channel information indicated by the multicast listening discovery report message reported by the MN. If the routing entry does not exist, create a new multicast routing entry for the channel, and set the inbound interface in the created multicast routing entry to the MAG to which the MN belongs to the MAG to which the MN-S belongs. Adding, by the interface, an interface that receives the multicast message of the MN to the multicast routing discovery message to the outbound interface list of the multicast routing entry; if the multicast routing entry of the channel exists locally, the multicast is updated.
  • the MAG to which the MN belongs sends a protocol-independent multicast join message to the MAG to which the MN-S belongs by using the multicast tunnel to declare the joining of the channel.
  • the method further includes: after the MAG to which the MN-S belongs receives the protocol-independent multicast join message sent by the MAG to which the MN belongs, through the multicast tunnel, determining whether the local channel exists. If the multicast routing entry does not exist, create a new multicast routing entry for the channel, and add the tunnel interface that receives the protocol-independent multicast join message to the outbound interface list of the created multicast routing entry. If the multicast routing entry of the multicast routing entry exists locally, the outbound interface list of the multicast routing entry is updated, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface list of the multicast routing entry.
  • the steps of establishing a multicast tunnel between the MAG to which the MN belongs and the MAG to which the MN-S belongs include:
  • the MAG to which the MN belongs sends a multicast tunnel setup message to the MAG to which the MN-S belongs, and the MAG to which the MN-S belongs sends a multicast tunnel setup response message to the MAG to which the MN belongs, and establishes the The multicast tunnel end node of the MAG to which the MN belongs, the MAG to which the MN belongs is established to the multicast tunnel end node of the MAG to which the MN-S belongs, and the multicast tunnel is established.
  • the multicast tunnel setup message and the multicast tunnel setup response message are corresponding mobile header messages; or a corresponding proxy binding update message and a proxy binding response message carrying a mobility option indicating a multicast tunnel establishment flag.
  • the step of sending the multicast packet to the MAG to which the MN belongs by using the multicast tunnel includes:
  • the MAG to which the MN-S belongs After receiving the multicast file sent by the MN-S, the MAG to which the MN-S belongs, finds a multicast routing entry, and sends the multicast packet to all tunnel interfaces in the outbound interface list of the multicast routing entry. Text.
  • the method further includes: after receiving the channel subscription message of the unicast exit channel sent by the MN, determining, by the MN, whether the MN is the last one of the MAG to receive the multicast data from the designated MN-S.
  • the multicast receiver if yes, deletes the multicast tunnel to the MAG to which the specified MN-S belongs, and if not, the multicast tunnel to the MAG to which the designated MN-S belongs.
  • the method for deleting a multicast tunnel includes: the MAG to which the MN belongs to the multicast tunnel
  • the MAG to which the MN-S belongs sends a protocol-independent multicast (PIM) prune message, and deletes the multicast routing entry corresponding to the MN-S.
  • PIM protocol-independent multicast
  • the tunnel interface to the MAG to which the MN belongs is deleted from the outbound interface list of the multicast routing entry.
  • the embodiment of the present invention further provides a system for establishing an optimized path for a multicast packet, including a mobile access gateway (MAG) to which the multicast receiving end (MN) belongs and a MAG to which the multicast source (MN-S) belongs, where ,
  • the MAG to which the MN belongs is set to establish a multicast tunnel with the MAG to which the MN-S belongs; the MAG to which the MN-S belongs is set to: establish the multicast tunnel with the MAG to which the MN belongs; After the multicast message sent by the MN-S, the multicast message is sent to the MAG to which the MN belongs by using the multicast tunnel.
  • the MAG to which the MN belongs is further configured to: after the establishment of the multicast tunnel, determine, according to channel information indicated by the multicast snooping discovery report message reported by the MN, whether a local channel group corresponding to the channel information exists. If the routing entry does not exist, create a new multicast routing entry for the channel, and set the inbound interface in the created multicast routing entry to the MAG to which the MN belongs to the MAG to which the MN-S belongs.
  • the interface adds an interface that receives the message that the MN reports the multicast snooping discovery report to the outbound interface list of the multicast routing entry; if the multicast routing entry of the channel exists locally, the multicast routing entry is updated, and The inbound interface of the multicast routing entry is set to the tunnel interface of the MAG to which the MN belongs to the MAG to which the MN-S belongs, and the interface that receives the multicast multicast snooping discovery report message of the MN is added to the group. In the outbound interface list of the broadcast route entry.
  • the MAG to which the MN belongs is also configured to send a protocol-independent multicast join message to the MAG to which the MN-S belongs by using the multicast tunnel to create a new multicast routing entry. Said channel.
  • the MAG to which the MN-S belongs is further configured to: after receiving the protocol-independent multicast join message sent by the MAG to which the MN belongs, through the multicast tunnel, determine whether the local multicast route entry exists in the channel, if not A new multicast routing entry is created for the channel, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface list of the created multicast routing entry. If the routing entry is broadcast, the outbound interface list of the multicast routing entry is updated, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface list of the multicast routing entry.
  • the MAG to which the MN belongs is set to establish a multicast tunnel with the MAG to which the MN-S belongs: in the process of establishing the multicast tunnel, sending a multicast tunnel to the MAG to which the MN-S belongs a message, and after receiving the multicast tunnel setup response message returned by the MAG to which the MN-S belongs, establishing a multicast tunnel end node to the MAG to which the MN-S belongs;
  • the MAG to which the MN-S belongs is set to establish the multicast tunnel with the MAG to which the MN belongs: After receiving the multicast tunnel setup message, send a multicast tunnel to the MAG to which the MN belongs. Establishing a response message, and establishing a multicast tunnel end node to the MAG to which the MN belongs.
  • the multicast tunnel setup message and the multicast tunnel setup response message are corresponding mobile header messages; or a corresponding proxy binding update message and a proxy binding response message carrying a mobility option indicating a multicast tunnel establishment flag.
  • the MAG to which the MN belongs is further configured to determine, after receiving the channel subscription message of the announced exit channel sent by the MN, whether the MN is the last group on the MAG to receive multicast data from the designated MN-S.
  • the broadcast receiver deletes the multicast tunnel to the MAG to which the designated MN-S belongs, and if not, the multicast tunnel to the MAG to which the designated MN-S belongs.
  • the embodiment of the present invention further provides a mobile access gateway, including a multicast processing module, where the multicast processing module is configured to:
  • the multicast tunnel is established with the MAG to which the MN belongs. After receiving the multicast packet sent by the MN-S, the multicast packet is passed through the multicast packet. The established multicast tunnel is sent to the MAG to which the MN belongs.
  • the multicast processing module is further configured to: according to the channel information indicated by the multicast snooping discovery report message reported by the MN, after the MAG is configured as the MAG to which the MN belongs, after the multicast tunnel is established. Determine whether there is a multicast routing entry for the channel corresponding to the channel information. If not, create a new multicast routing entry for the channel, and set the inbound interface of the created multicast routing entry to be located.
  • the interface that receives the message that the MN reports the multicast snooping discovery report is added to the outbound interface list of the multicast routing entry; If the routing entry is broadcast, the multicast routing entry is updated, and the inbound interface in the multicast routing entry is set to the tunnel interface of the MAG to which the MN-S belongs, and the MN is reported to be multicast. The interface that listens for the discovery report message is added to the outbound interface list of this multicast routing entry.
  • the multicast processing module is further configured to: when the MAG is located as the MAG to which the MN belongs, create a new multicast routing entry for the channel, and use the multicast tunnel to the MN-S
  • the associated MAG sends a protocol-independent multicast join message to declare joining the channel.
  • the multicast processing module is further configured to: when the MAG to which the MN-S belongs is the MAG to which the MN belongs, after receiving the protocol-independent multicast join message sent by the MAG to which the MN belongs, the local MAG determines the local Whether a multicast routing entry of the channel exists, if not, a new multicast routing entry is created for the channel, and a tunnel interface that receives the protocol-independent multicast join message is added to the created multicast routing entry.
  • the outbound interface list if the multicast routing entry of the channel exists locally, the outbound interface list of the multicast routing entry is updated, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface of the multicast routing entry. List.
  • the method for establishing an optimized SPT path provided by the solution can improve routing efficiency and performance of mobile multicast.
  • FIG. 1 is a schematic diagram of a manner in which multicast data is transmitted by a multicast receiver and a multicast source in the same PMIPv6 domain in the related art;
  • FIG. 2 is a flow chart of a method for establishing an optimized SPT path in an embodiment
  • FIG. 3 is a flow chart of a method for pruning an SPT tree in an embodiment. Preferred embodiment of the invention
  • the method for establishing an optimized path for a multicast packet includes: establishing between a mobile access gateway (MAG) to which the multicast receiving end (MN) belongs and a mobile access gateway (MAG) to which the multicast source (MN-S) belongs The multicast tunnel, after the MAG to which the MN-S belongs receives the multicast message sent by the MN-S, sends the multicast message to the MAG to which the MN belongs.
  • MAG mobile access gateway
  • MN-S mobile access gateway
  • the scheme optimizes the multicast forwarding path 100 as shown in FIG. 1.
  • the optimized SPT path is as shown in FIG. 101, and the multicast message sent by the multicast source MN-S directly passes through the multicast source MN-S.
  • Multicast tunnel between mobile access gateway MAG2 and mobile access gateway MAG1 of multicast receiver MN Perform package forwarding.
  • the MAG to which the MN belongs and the MAG to which the MN-S belongs may be located in the same PMIPv6 domain.
  • the MAG to which the MN belongs determines whether there is a multicast routing entry of the channel according to the channel information indicated by the multicast detection report message of the MN.
  • a new multicast routing entry is created for the channel, and the inbound interface in the multicast routing entry is set to the tunnel interface of the MAG to which the MN belongs to the MAG to which the MN-S belongs, and the MN is reported to be multicast.
  • the interface that listens to the discovery report message is added to the outbound interface list of the multicast routing entry. If yes, the multicast routing entry is updated, and the inbound interface in the multicast routing entry is set to the MAG to which the MN belongs.
  • the tunnel interface of the MAG to which the MN-S belongs is added to the outbound interface list of the multicast routing entry by the interface that receives the message that the MN reports the multicast snooping discovery report.
  • the MAG to which the MN belongs sends a protocol-independent multicast join message to the MAG to which the MN-S belongs through the multicast tunnel to declare joining the channel.
  • the MAG to which the MN-S belongs receives the protocol-independent multicast join message sent by the MAG of the MN through the multicast tunnel, it determines whether there is a multicast routing entry of the channel, and if it does not exist, it creates a channel for the channel.
  • a new multicast routing entry is added to the outbound interface list of the multicast routing entry, and the outbound interface list of the multicast routing entry is updated, and the receiving protocol is received.
  • a tunnel interface that is independent of multicast join messages is added to the outbound interface list.
  • the method of establishing a multicast tunnel between the MAG to which the MN belongs and the MAG to which the MN-S belongs includes: sending, by the MAG to which the MN belongs, a multicast tunnel establishment message to the MAG to which the MN-S belongs, where the MN-S belongs.
  • the MAG sends a multicast tunnel setup response message to the MAG to which the MN belongs, and establishes a multicast tunnel end node to the MAG to which the MN belongs, and the MAG to which the MN belongs is established to the MAG to which the MN-S belongs.
  • the multicast tunnel end node is established.
  • the multicast tunnel is used to carry the multicast control message and the multicast data.
  • the PIM join message sent by the MAG to which the MN belongs to the MAG of the MN-S is sent through the multicast tunnel.
  • the MAG to which the MN-S belongs is sent.
  • the multicast data of the MAG to which the MN belongs is also transmitted through the multicast tunnel.
  • the multicast tunnel setup message and the multicast tunnel setup response message are corresponding mobile header messages; that is, a pair of new mobile header messages, Proxy Multicast Tunnel, and proxy multicast tunnel response, may be defined in this solution.
  • Message PMTR Proxy Multicast Tunnel Reply
  • the multicast tunnel setup message PMT and the multicast tunnel setup response message PMTR Is a corresponding proxy binding update message PBU and a proxy binding response message PBA carrying a mobility option indicating a multicast tunnel establishment flag, that is, an extended PBU/PBA message as a message for establishing a multicast tunnel, for example, defining a new mobility option.
  • the manner in which the MAG to which the MN belongs is the address of the MAG to which the MN-S belongs is: after the MN belongs to the channel subscription, the local mobile anchor LMA to which the MAG belongs is queried for the address of the MAG to which the MN-S belongs, and the LMA is tied according to the The cache entry is queried to the address of the multicast source and notified to the MAG to which the MN belongs.
  • the MAG to which the MN-S belongs receives the multicast message sent by the MN-S, searches for a multicast routing entry, and sends a multicast packet to all the tunnel interfaces in the outbound interface list.
  • the MAG that the MN belongs to determines that the MN is the last multicast receiver on the MAG that receives the multicast data from the specified multicast source MN-S.
  • the MAG to which the MN belongs is deleted to the MAG multicast tunnel to which the MN-S belongs, otherwise the multicast tunnel is reserved.
  • the method for removing the multicast tunnel includes: the MAG to which the MN belongs sends a PIM prune message to the MAG to which the MN-S belongs through the multicast tunnel, and deletes the multicast routing entry corresponding to the MN-S.
  • the MAG to which the MN-S belongs deletes the MAG to which the MN-S belongs to the interface of the MAG to which the MN belongs, from the outbound interface list of the multicast routing entry.
  • This scheme can create a multicast tunnel for each multicast source MN-S. All channels sent from the multicast source share the multicast tunnel. You can also create your own multicast tunnel for each channel. The multicast packets sent from the multicast source to different channels are forwarded through their respective multicast tunnels.
  • the shared multicast tunnel is taken as an example for detailed description.
  • a system for establishing a shortest path for a multicast file corresponding to the above method including a MN
  • the MAG to which the MN belongs, and the MAG to which the MN belongs is set to establish a multicast tunnel with the MAG to which the MN-S belongs; the MAG to which the MN-S belongs is set to: The MAG establishes the multicast tunnel; and, after receiving the multicast message sent by the MN-S, sends the multicast packet to the MAG to which the MN belongs by using the multicast tunnel.
  • the MAG of the MN to which the MN belongs and the MAG to which the MN-S belongs are executed in the same manner as in the above method.
  • the MAG to which the MN belongs is further configured to: determine, according to the channel information indicated by the multicast snooping discovery report message reported by the MN, that the local multicast routing entry exists in the channel after the completion of the establishment of the multicast tunnel, and does not exist.
  • a new multicast routing entry is created for the channel, and the inbound interface in the multicast routing entry is set to the tunnel interface of the MAG to which the MN belongs to the MAG to which the MN-S belongs, and the MN is received.
  • the interface of the multicast snooping discovery report is added to the outbound interface list of the multicast routing entry. If yes, the multicast routing entry is updated, and the inbound interface in the multicast routing entry is set to the MAG to which the MN belongs.
  • the interface of the MAG that the MN-S belongs to is added to the outbound interface list of the multicast routing entry.
  • the MAG to which the MN belongs is further configured to: send a protocol-independent multicast join message to the MAG to which the MN-S belongs by using the multicast tunnel to declare the join of the channel.
  • the MAG to which the MN-S belongs is further configured to: after receiving the protocol-independent multicast join message sent by the MAG to which the MN belongs, through the multicast tunnel, determine whether the multicast routing entry of the channel exists. A new multicast routing entry is created for the channel, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface list of the multicast routing entry. When present, the outbound interface of the multicast routing entry is updated. List, add the tunnel interface that receives the protocol-independent multicast join message to the outbound interface list.
  • the MAG to which the MN belongs is set to establish a multicast tunnel with the MAG to which the MN-S belongs: in the process of establishing the multicast tunnel, sending a multicast tunnel to the MAG to which the MN-S belongs a message, and after receiving the multicast tunnel setup response message returned by the MAG to which the MN-S belongs, establishing a multicast tunnel end node to the MAG to which the MN-S belongs;
  • the MAG to which the MN-S belongs is set to establish a multicast tunnel with the MAG to which the MN belongs: After receiving the multicast tunnel setup message, the MAG sends a multicast tunnel setup response to the MAG to which the MN belongs. The message is established to the multicast tunnel end node of the MAG to which the MN belongs.
  • the MAG to which the MN belongs is also set to receive the frequency of the announcement of the exit channel sent by the MN.
  • the MN is the last multicast receiver that receives the multicast data from the specified multicast source MN-S on the MAG, the MAG to which the MN belongs is deleted from the MN-S. MAG multicast tunnel, otherwise the multicast tunnel is reserved.
  • the mobile access gateway provided by the solution includes a multicast processing module, which is configured to process multicast messages, and the execution manner thereof is the same as that in the foregoing method.
  • the multicast processing module is configured to: establish a multicast with the MAG to which the multicast source (MN-S) belongs when the mobile access gateway (MAG) is configured as the MAG to which the multicast receiver (MN) belongs. And the tunnel is established with the MAG to which the MN belongs, and after receiving the multicast message sent by the MN-S, when the MAG is the MAG to which the multicast source MN-S belongs, The multicast message is sent to the MAG to which the MN belongs by using the multicast tunnel.
  • the multicast processing module is further configured to: according to the channel information indicated by the multicast snooping discovery report message reported by the MN, after the MAG is configured as the MAG to which the MN belongs, after the multicast tunnel is established. If the multicast routing entry of the channel exists in the local device, the new multicast routing entry is created for the channel, and the inbound interface of the multicast routing entry is set to the MAG of the MN to the MN. The tunnel interface of the MAG to which the S belongs is added to the outbound interface list of the multicast routing entry, and the multicast routing entry is updated.
  • the inbound interface in the multicast routing entry is set to the tunnel interface of the MAG to which the MN belongs to the MAG to which the MN-S belongs, and the interface that receives the multicast message of the multicast monitoring and discovery message is added to the group.
  • the outbound interface list of the broadcast route entry In the outbound interface list of the broadcast route entry.
  • the multicast processing module is further configured to: when the MAG is located as the MAG to which the MN belongs, create a multicast routing entry, and use the multicast tunnel to send a protocol to the MAG to which the MN-S belongs.
  • the multicast join message is declared to join the channel.
  • the multicast processing module is further configured to: after the MAG to which the MN-S belongs is the MAG to which the MN belongs, after receiving the protocol-independent multicast join message sent by the MAG of the MN through the multicast tunnel, determine the local If a multicast routing entry exists for the channel, the new multicast routing entry is created for the channel, and the tunnel interface that receives the protocol-independent multicast join message is added to the outbound interface list of the multicast routing entry. In the presence, when updating the outbound interface list of this multicast routing entry, it will receive The tunnel interface of the protocol-independent multicast join message is added to the outbound interface list.
  • Step 200 The MN needs to receive IPv6 multicast data from the multicast source MN-S and sent to the multicast group G, and the MN sends the MA6 to the MAG1.
  • MLD Report MLD Report message
  • Step 201 After receiving the MLD ⁇ message, the MAG1 queries the LMA for the address of the MAG2, and the query message carries the address of the MN-S, ⁇ .
  • Step 202 After receiving the query message PBQ, the LMA searches for the local binding cache entry BCE according to the address HoA of the MN-S, finds the address of the MAG2, and notifies the MAG1.
  • the multicast receiver MN and the multicast source MN-S have been bound and registered on the LMA.
  • the LMA has created a corresponding binding cache entry BCE for the MN and the MN-S.
  • Step 203 The MAG1 sends a proxy multicast tunnel establishment message PMT (Proxy Multicast Tunnel) to the MAG2.
  • PMT Proxy Multicast Tunnel
  • the source address of the message is the address of the MAGI
  • the destination address is the address of the MAG2.
  • Step 204 After receiving the PMT message, the MAG2 sends a Proxy Multicast Tunnel Reply (PMTR) message to the MAG1, and the MAG2 establishes an end node of the bidirectional tunnel to the mobile access gateway MAG1.
  • PMTR Proxy Multicast Tunnel Reply
  • Step 205 After receiving the PMTR message, the MAG1 establishes an end node of the bidirectional tunnel to the mobile access gateway MAG2.
  • a bidirectional multicast tunnel is established between MAG1 and MAG2, and the bidirectional tunnel is used to carry multicast control packets and multicast data packets.
  • Step 206 MAG1 creates or updates an MLD state table (G, a filtering mode, a multicast source address list, and an interface for receiving an MLD report message, that is, an interface that receives a channel subscription message of the MN).
  • the timer is used to determine whether there is a multicast routing entry corresponding to the channel according to the channel information in the MLD report message. If the multicast routing entry does not exist, create a new multicast routing entry (HoA, G) and enter the multicast routing entry.
  • the interface (that is, the RPF interface) is configured as the tunnel interface of the MAG1 to the MAG2, and adds the interface that receives the MLD report message to the outbound interface list of the multicast routing entry.
  • the multicast routing entry (HoA, G) is updated.
  • the inbound interface (that is, the RPF interface) of the multicast routing entry is configured as the tunnel interface of the MAG1 to the MAG2, and the interface that receives the MLD report message is added to the outbound interface list of the multicast routing entry.
  • the multicast routing entry includes a multicast source address HoA, a multicast group address G, an inbound interface, an outbound interface list, a timer, and a flag.
  • Step 207 The MAG1 sends a PIM join message to the MAG2 through the multicast tunnel, and the PIM join message carries the channel information of the channel to which the MN and the MN-S belong.
  • Steps 207 and 206 do not perform the sequence.
  • Step 208 The MAG2 creates a multicast routing entry (HoA, G) according to the channel information in the received PIM join message, and adds the tunnel interface that receives the PIM Join message to the outbound interface list of the multicast routing entry. If the multicast routing entry of the channel already exists on MAG2, the outbound interface list is updated, and the tunnel interface that receives the PIM Join message is added to the outbound interface list.
  • HoA multicast routing entry
  • Step 209 The MN-S sends the multicast packet M-data (Multicast data) to the multicast group G. After receiving the multicast packet, the MAG2 forwards the multicast packet to all the outbound interfaces in the outbound interface list.
  • M-data Multicast data
  • Step 210 The MAG2 tunnels the multicast packet to the MAG1.
  • Step 211 After receiving the multicast packet from the tunnel, the MAG1 queries the multicast routing entry. If the interface that the packet actually arrives is the same as the inbound interface of the multicast routing entry, the MAG1 forwards the outbound interface to the outbound interface. The multicast packet. If the interface that the packet actually arrives does not match the inbound interface saved in the multicast routing entry, perform RPF check on the packet. If the RPF interface is the same as the inbound interface, the multicast routing entry saved in MAG2 (HoA) If the RPF interface does not match the inbound interface, the multicast routing entry (HoA, G) saved in MAG2 has expired, and the incoming interface is expired. Updated to RPF interface.
  • HoA the multicast routing entry saved in MAG2
  • the optimized SPT path is established by the foregoing steps.
  • the multicast receiver MN When receiving the multicast data of the multicast source, the multicast receiver MN does not need to go through the respective anchor point LMA, optimizes the multicast forwarding path, and improves the multicast routing efficiency.
  • the scheme optimizes the SPT path based on the SSM model. For the ASM model, when the mobile access gateway MAG1 on the multicast receiver side detects that the multicast data rate sent from the RP to the multicast group G exceeds a certain threshold. The switch from RPT to SPT will be initiated by MAG1, and an optimized SPT path can also be established by using the method of this embodiment when the handover occurs.
  • a flowchart of a method for pruning an SPT tree includes the following steps:
  • Steps 300 to 302 The multicast source MN-S sends a multicast packet to the MN through a tunnel between MAG2 and MAG1.
  • Step 303 The MN requests to reject the IPv6 multicast data sent from the multicast source MN-S to the multicast group G, and the MN sends an MLD report message to the MAG1 to declare the leaving channel (HoA, G).
  • the MN can actively send an MLD report message to the MAG1, or wait for the MLD query message sent by the MAG1, and then send the MLD ⁇ report.
  • Step 304 After receiving the MLD 4 report of the MN, the MAG1 deletes the MLD status table of the interface that receives the MLD report and updates the multicast routing entry (HoA, G).
  • the MN is not the last multicast receiver under MAG1, that is, there are other mobile nodes that need to receive multicast data from the MN-S under MAG1, you do not need to remove the MAG1 and MAG2. If the MN is the last multicast receiver under MAG1, then steps 305 to 309 are performed.
  • Step 305 The MAG1 sends a PIM prune message to the MAG2 through the multicast tunnel.
  • Step 306 Delete the multicast routing entry (HoA, G) corresponding to the multicast source MN-S on MAG1.
  • Step 307 Remove the tunnel established with MAG2.
  • Step 308 After receiving the prune message from the MAG1, the MAG2 updates the multicast routing entry (HoA, G), and the tunnel interface (that is, the tunnel interface of the MAG2 to the MAG1) is elected from the outbound interface list of the multicast routing entry. Deleted.
  • Step 309 the tunnel established with MAG1 is removed.
  • the SPT tree is prune, and the prune is sent through the tunnel to optimize the prune process and improve the efficiency of multicast routing.
  • the multicast sent by the MN-S to any multicast group is transmitted through the tunnel between MAG2 and MAG1, that is, for the designated source MN-S, all channels
  • the same tunnel can be shared.
  • the tunnel can be a tunnel such as IP-in-IP or GRE.
  • the technical solution provided by this solution can also create a private tunnel for each channel, which can be implemented by establishing a GRE tunnel and using GRE Key. To distinguish tunnels of different channels, those skilled in the art can conveniently derive the process of establishing and updating an optimized SPT tree through a proprietary tunnel by using the techniques disclosed in the present scheme.
  • the above embodiment is directed to the scenario of ⁇ , and uses MLDv2 for IPv6 multicast member management.
  • the technical solution in the present solution is also applicable to the scenario of proxying mobile IPv4, and can be implemented by a person skilled in the art according to the technical solution in the embodiment of the present solution and in combination with the prior art solutions in the prior art.
  • the mobile node in the proxy mobile IPv6 joins the multicast group using MLDv2, and the mobile node in the proxy mobile IPv4 joins the multicast group using IGMPv3.
  • the method for establishing an optimized SPT path provided by the embodiments of the present invention can improve routing efficiency and performance of mobile multicast.

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)

Abstract

一种为组播数据建立优化路径的方法及系统，此方法包括：在组播接收端（MN）所属的移动接入网关（MAG）与组播源（MN-S）所属的移动接入网关（MAG）之间建立组播隧道，所述MN-S所属的MAG收到所述MN-S 发出的组播报文后，将所述组播报文通过所述组播隧道发送至所述MN所属的MAG。本方案提供的建立优化SPT路径的方法可以提高路由效率和移动组播的性能。

Description

一种为组播数据建立优化路径的方法及系统
技术领域
本发明涉及移动通信领域， 尤其涉及一种为组播数据建立优化路径的方 法及系统。
背景技术
组播的出现是为了解决传统单播路由在处理组通信时出现的效率问题。 随着无线和移动技术的发展， 在移动过程中获取组播服务成为了一个研究热 点,移动组播由传统固定组播发展而来， 为移动用户提供诸如移动视频会议、 移动在线游戏等多种应用， 可有效提高数据传输效率。 移动组播需要解决两 个基本问题:一是组成员关系管理， 二是组成员位置管理。 当前组成员关系管 理一般釆用 Internet组管理协议 IGMP (全称为 Internet Group Management Protocol,简称）/组播侦听者发现协议 MLD(全称为 Multicast Listener Discovery Protocol )等协议， 而组成员位置管理则釆用移动 IP等移动性管理协议。
IP 组播业务模型分为两种： 任意源组播 ASM (全称为 Any-Source Multicast )和特定源组播 SSM (全称为 Source-Specific Multicast ) 。 ASM模 型使用一个组播组地址 G来标识一个组播组， 每个组播组可以有任意多个组 播源和接收者， 需要利用汇集点（RP, 全称为 Rendezvous Point )进行共享树 ( RPT , 全称为 Rendezvous Point Tree )的建立， 并且通过组播源注册机制建 立最短路径树 SPT (全称为 Shortest Path Tree ) ； SSM和 MLDv2/IGMPv3相 结合， 使用组播组地址 G和组播源地址 S来标识一个组播会话， 也称为一个 频道， 每个频道只能有一个指定源和任意多个接收者， 在 SSM模型中不需要 选择汇集点 RP和维护共享树（RPT ) , 不需要进行组播源注册， 从而在网络 内直接构建以组播源 S为根、以接收者为叶子的 SPT,省去了 ASM模型中先 建立共享树再从共享树向最短路径树切换的过程， 从而能够从一开始就沿最 短路径树转发数据。 和 ASM比较， SSM是一种简单有效的组播模型， 它可 以克服 ASM在访问控制、 地址分配、 源发现、 易于遭受 DoS攻击等方面的 缺陷， 因此 SSM模型具有更强的可扩展性， 可以提高网络性能， 在未来的 Internet中具备更加广泛的应用前景。
为了处理同一路由器在不同接口上收到来自不同对端的相同组播信息， 需要对组播报文的入接口进行逆向路径转发 RPF (全称为 Reverse Path Forwarding )检查， 以决定转发还是丟弃该报文。 在 SSM模型中， RPF检查 的过程是： 接收组播报文的路由器以组播源的 IP地址为目的地址查找单播路 由表， 对应表项中的出接口为 RPF接口， 路由器认为由该 RPF接口接收到 的组播报文所经历的路径是从组播源到本地的最短路径， 将 RPF接口与组 播报文实际到达的接口相比较， 如果两接口相一致， 那么就认为这个组播包 是从正确路径而来， RPF检查成功； 如果两接口不一致， 将该组播报文丟弃。 作为路径判断依据的单播路由信息可以来源于任何一种单播路由协议、 组播 静态路由或者 MBGP路由协议。
对于移动组播， IETF在 MULTIMOB工作组致力于研究基于 PMIPv6的 移动组播机制， 目前提出了一种基本解决方案， 下面结合附图介绍该方案的 实现过程， 如图 1 , 组播接收者 MN和组播源 MN-S(MN-Source)位于同一个 PMIPv6域， 组播接收者 MN连接在移动接入网关 MAG1上， MN-S连接在 移动接入网关 MAG2上， MN和 MN-S的拓朴锚点可以是同一个 LMA也可 以是不同的 LMA。 在 SSM模型下， MN通过 MLDv2报告报文向 MAG1报 告自己需要接收来自组播源 MN-S、 发往组播组 G的组播数据。 MAG1收到 MLDv2 Report 4艮文后， 向组播源 MN-S逐跳发送频道订阅 4艮文 (由 MAG1 发往 LMA的订阅报文需要进行隧道封装，由 LMA发往 MAG2的订阅报文也 需要进行隧道封装）， 沿途所有路由器都创建（HoA, G )组播路由项， HoA 代表组播源 MN-S的地址， G代表组播地址， 从而构建以组播源 MN-S为根， 以组播接收者 MN为叶子的 SPT路径，从组播源 MN-S所属的 MAG2到 LMA 的路径是 PMIPv6隧道， 从 LMA到组播接收者 MN所属的 MAG1的路径是 ΡΜΙΡνό隧道，随后组播源 MN-S发出的组播数据沿着已建好的 SPT到达 ΜΝ , 组播转发路径如图 1的 100所示。
以上解决方案， 由 MN-S发往 ΜΝ的组播报文必须先通过 MN-S的移动 接入网关 MAG2和本地移动锚点（ LMA )之间的 ΡΜΙΡν6隧道进行发送， 组 播才艮文到达 MN的移动锚点 LMA后，必须通过 LMA和 MN的移动接入网关 MAGI之间的 PMIPv6隧道进行发送， 所以图 1所示 SPT路径 100不是最短 的组播转发路径。 因此， 目前基于 PMIPv6所提出的移动组播解决方法不可 避免的造成了非最短 SPT路径， 降低了路由效率和移动组播的性能。 发明内容
本发明实施方式提供一种为组播报文建立优化路径的方法及系统， 解决 相关方案中必需经由本地移动锚点的非最短 SPT路径造成的路由效率低的问 题。
为了解决上述技术问题， 本发明提供了一种为组播报文建立优化路径的 方法， 包括：
在组播接收端 （MN )所属的移动接入网关 （MAG )与组播源 （MN-S ) 所属的 MAG之间建立组播隧道，所述 MN-S所属的 MAG收到所述 MN-S发 出的组播 文后， 将所述组播 文通过所述组播隧道发送至所述 MN所属的 MAG„
该方法还包括： 所述组播隧道建立完成后， 所述 MN所属的 MAG根据 所述 MN上报的组播侦听发现报告消息指示的频道信息判断本地是否存在该 频道信息所对应的频道的组播路由项， 若不存在， 为此频道创建新的组播路 由项， 并将所创建的组播路由项中的入接口设置为所述 MN所属 MAG到所 述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播侦听发现 4艮告 消息的接口添加到此组播路由项的出接口列表中； 若本地存在所述频道的组 播路由项， 则更新此组播路由项， 并将此组播路由项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口，将接收所述 MN上才艮 组播侦听发现报告消息的接口添加到此组播路由项的出接口列表中。
为所述频道创建新的组播路由项的步骤中， 所述 MN所属的 MAG通过 所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消息以声明 加入所述频道。
该方法还包括： 所述 MN-S所属的 MAG收到所述 MN所属的 MAG通 过组播隧道发送的协议无关组播加入消息后， 判断本地是否存在所述频道的 组播路由项， 若不存在， 为此频道创建新的组播路由项， 并将接收所述协议 无关组播加入消息的隧道接口添加到所创建的组播路由项的出接口列表中， 若本地存在所述频道的组播路由项， 则更新此组播路由项的出接口列表， 将 接收协议无关组播加入消息的隧道接口添加到该组播路由项的出接口列表 中。
在 MN所属的 MAG与 MN-S所属的 MAG之间建立组播隧道的步骤包 括：
所述 MN所属的 MAG向所述 MN-S所属的 MAG发送组播隧道建立消 息， 所述 MN-S所属的 MAG向所述 MN所属的 MAG发送组播隧道建立应 答消息， 并建立到所述 MN所属的 MAG的组播隧道端节点， 所述 MN所属 的 MAG建立到所述 MN-S所属的 MAG的组播隧道端节点，组播隧道建立完 成。
所述组播隧道建立消息和组播隧道建立应答消息是对应的移动头消息； 或者是携带了指示组播隧道建立标志的移动选项的对应的代理绑定更新消息 和代理绑定应答消息。
将所述组播报文通过所述组播隧道发送至所述 MN所属的 MAG的步骤 包括：
所述 MN-S所属的 MAG收到所述 MN-S发送的组播 文后， 查找组播 路由项， 并向该组播路由项的出接口列表中的所有隧道接口发送所述组播报 文。
该方法还包括： 所述 MN所属的 MAG收到所述 MN发送的声明退出频 道的频道订阅报文后， 判断所述 MN是否是本 MAG上最后一个接收来自指 定 MN-S的组播数据的组播接收者， 若是， 则删除到所述指定 MN-S所属的 MAG的组播隧道，若不是则保留到所述指定 MN-S所属的 MAG的组播隧道。
删除组播隧道的方式包括： 所述 MN所属的 MAG通过组播隧道向所述
MN-S所属的 MAG发送协议无关组播（ PIM )剪枝消息， 并删除所述 MN-S 对应的组播路由项， 所述 MN-S所属的 MAG收到所述 PIM剪枝消息后， 将 到所述 MN所属的 MAG的隧道接口从组播路由项的出接口列表中删除。 本发明实施方式还提供一种为组播报文建立优化路径的系统， 包括组播 接收端（ MN )所属的移动接入网关（ MAG )和组播源（ MN-S )所属的 MAG, 其中，
所述 MN所属的 MAG设置为与所述 MN-S所属的 MAG建立组播隧道； 所述 MN-S所属的 MAG设置为： 与所述 MN所属的 MAG建立所述组播 隧道； 以及在收到所述 MN-S发出的组播 文后， 将所述组播 文通过所述 组播隧道发送至所述 MN所属的 MAG。
所述 MN所属的 MAG还设置为： 在所述组播隧道建立完成后， 根据所 述 MN上报的组播侦听发现报告消息指示的频道信息判断本地是否存在该频 道信息所对应的频道的组播路由项， 若不存在， 为此频道创建新的组播路由 项， 并将所创建的组播路由项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口 ,将接收所述 MN上报组播侦听发现报告消息 的接口添加到此组播路由项的出接口列表中； 若本地存在该频道的组播路由 项， 则更新此组播路由项， 并将此组播路由项中的入接口设置为所述 MN所 属 MAG到所述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播 侦听发现报告消息的接口添加到此组播路由项的出接口列表中。
所述 MN所属的 MAG还设置为在为所述频道创建新的组播路由项的同 时， 通过所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消 息以声明加入所述频道。
所述 MN-S所属的 MAG还设置为：在收到所述 MN所属的 MAG通过组 播隧道发送的协议无关组播加入消息后， 判断本地是否存在所述频道的组播 路由项， 若不存在， 为此频道创建新的组播路由项， 并将接收所述协议无关 组播加入消息的隧道接口添加到所创建的组播路由项的出接口列表中， 若本 地存在所述频道的组播路由项， 则更新此组播路由项的出接口列表， 将接收 协议无关组播加入消息的隧道接口添加到该组播路由项的出接口列表中。
所述 MN所属的 MAG是设置为通过如下方式与所述 MN-S所属的 MAG 建立组播隧道： 在所述组播隧道建立过程中， 向所述 MN-S所属的 MAG发 送组播隧道建立消息， 并在收到所述 MN-S所属的 MAG返回的组播隧道建 立应答消息后， 建立到所述 MN-S所属的 MAG的组播隧道端节点； 所述 MN-S所属的 MAG是设置为通过如下方式与所述 MN所属的 MAG 建立所述组播隧道： 收到所述组播隧道建立消息后，向所述 MN所属的 MAG 发送组播隧道建立应答消息， 并建立到所述 MN所属的 MAG的组播隧道端 节点。
所述组播隧道建立消息和组播隧道建立应答消息是对应的移动头消息； 或者是携带了指示组播隧道建立标志的移动选项的对应的代理绑定更新消息 和代理绑定应答消息。
所述 MN所属的 MAG还设置为在收到所述 MN发送的声明退出频道的 频道订阅报文后， 判断所述 MN是否是本 MAG上最后一个接收来自指定 MN-S的组播数据的组播接收者， 若是， 则删除到所述指定 MN-S所属 MAG 的组播隧道， 若不是则保留到所述指定 MN-S所属 MAG的组播隧道。
本发明实施方式还提供一种移动接入网关， 包括组播处理模块； 所述组 播处理模块设置为：
在所处的移动接入网关（ MAG )作为组播接收端（ MN )所属的 MAG时， 与组播源 （MN-S )所属的 MAG建立组播隧道； 以及
在所处的 MAG作为 MN-S所属的 MAG时， 与 MN所属的 MAG建立组 播隧道； 并在收到所述 MN-S发出的组播报文后， 将所述组播报文通过所建 立的组播隧道发送至所述 MN所属的 MAG。
所述组播处理模块还设置为：在所处的 MAG作为所述 MN所属的 MAG 时， 在所述组播隧道建立完成后根据所述 MN上报的组播侦听发现报告消息 指示的频道信息判断本地是否存在该频道信息对应的频道的组播路由项， 若 不存在， 则为此频道创建新的组播路由项， 并将所创建的组播路由项中的入 接口设置为所处的 MAG到所述 MN-S所属的 MAG的隧道接口，将接收所述 MN 上报组播侦听发现报告消息的接口添加到此组播路由项的出接口列表 中； 若本地存在所述频道的组播路由项， 则更新此组播路由项， 并将此组播 路由项中的入接口设置为所处的 MAG到所述 MN-S所属的 MAG的隧道接 口， 将接收所述 MN上报组播侦听发现报告消息的接口添加到此组播路由项 的出接口列表中。 所述组播处理模块还设置为在所处的 MAG作为所述 MN所属的 MAG 时， 在为所述频道创建新的组播路由项的同时， 通过所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消息以声明加入所述频道。
所述组播处理模块还设置为： 在所处的 MAG作为所述 MN-S 所属的 MAG时，收到所述 MN所属的 MAG通过组播隧道发送的协议无关组播加入 消息后， 判断本地是否存在所述频道的组播路由项， 若不存在， 为此频道创 建新的组播路由项， 并将接收所述协议无关组播加入消息的隧道接口添加到 所创建的组播路由项的出接口列表中， 若本地存在所述频道的组播路由项， 则更新此组播路由项的出接口列表， 将接收协议无关组播加入消息的隧道接 口添加到该组播路由项的出接口列表中。
本方案提供的建立优化 SPT路径的方法可以提高路由效率和移动组播的 性能。 附图概述
图 1是相关技术中以及实施例中组播接收者和组播源位于同一个 PMIPv6 域内组播数据发送的方式示意图；
图 2是实施例中建立优化 SPT路径的方法流程图；
图 3是实施例中对 SPT树进行剪枝的方法流程图。 本发明的较佳实施方式
为组播报文建立优化路径的方法包括： 在组播接收端（MN )所属的移动 接入网关 （MAG )与组播源 （MN-S )所属的移动接入网关 （MAG )之间建 立组播隧道， 所述 MN-S所属的 MAG收到所述 MN-S发出的组播 文后， 将所述组播 文通过所述组播隧道发送至所述 MN所属的 MAG。
本方案对如图 1的组播转发路径 100进行优化， 优化后的 SPT路径如图 1的 101所示，由组播源 MN-S发出的组播 4艮文直接通过组播源 MN-S的移动 接入网关 MAG2和组播接收者 MN的移动接入网关 MAG1之间的组播隧道 进行封装转发。
MN所属 MAG与 MN-S所属 MAG可以位于同一 PMIPv6域内。
所述组播隧道建立完成后， 所述 MN所属的 MAG根据所述 MN上 4艮的 组播侦听发现报告消息指示的频道信息判断本地是否存在该频道的组播路由 项， 不存在时， 为此频道创建新的组播路由项， 并将此组播路由项中的入接 口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口， 将接 收所述 MN上报组播侦听发现报告消息的接口添加到此组播路由项的出接口 列表中； 存在时， 更新此组播路由项， 并将此组播路由项中的入接口设置为 所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口，将接收所述 MN 上报组播侦听发现报告消息的接口添加到此组播路由项的出接口列表中。
创建组播路由项的同时， 所述 MN所属的 MAG通过所述组播隧道向所 述 MN-S所属的 MAG发送协议无关组播加入消息以声明加入所述频道。 所 述 MN-S所属的 MAG收到所述 MN所属的 MAG通过组播隧道发送的协议 无关组播加入消息后， 判断是否存在所述频道的组播路由项， 不存在时， 为 此频道创建新的组播路由项， 并将接收所述协议无关组播加入消息的隧道接 口添加到组播路由项的出接口列表中， 存在时， 更新此组播路由项的出接口 列表， 将接收协议无关组播加入消息的隧道接口添加到出接口列表中。
在 MN所属的 MAG与 MN-S所属的 MAG之间建立组播隧道的方法包 括： 所述 MN所属的 MAG向所述 MN-S所属的 MAG发送组播隧道建立消 息， 所述 MN-S所属的 MAG向所述 MN所属的 MAG发送组播隧道建立应 答消息， 并建立到所述 MN所属的 MAG的组播隧道端节点， 所述 MN所属 的 MAG建立到所述 MN-S所属的 MAG的组播隧道端节点，组播隧道建立完 成。此组播隧道用于承载组播控制 艮文和组播数据艮文， 比如 MN所属 MAG 发往 MN-S所属 MAG的 PIM加入消息是通过该组播隧道发送的， MN-S所 属 MAG发往 MN所属 MAG的组播数据也是通过该组播隧道发送的。
组播隧道建立消息和组播隧道建立应答消息是对应的移动头消息； 即本 方案中可以定义一对新的移动头消息即代理组播隧道消息 PMT ( Proxy Multicast Tunnel )和代理组播隧道响应消息 PMTR ( Proxy Multicast Tunnel Reply ) ,或者，所述组播隧道建立消息 PMT和组播隧道建立应答消息 PMTR 是携带了指示组播隧道建立标志的移动选项的对应的代理绑定更新消息 PBU 和代理绑定应答消息 PBA, 即扩展 PBU/PBA消息作为建立组播隧道的消息， 例如定义新的移动选项来携带组播隧道建立标志，或者扩展 PBU/PBA消息携 带所述新的移动选项。
MN所属 MAG获知 MN-S所属 MAG的地址的方式是： 所述 MN所属 频道订阅 文后，向此 MAG所属的本地移动锚点 LMA查询所述 MN-S所属 MAG的地址， 所述 LMA根据绑定緩存表项查询到所述组播源的地址并通知 至所述 MN所属 MAG。
所述 MN-S所属的 MAG收到所述 MN-S发送的组播 文， 查找组播路 由项， 并向出接口列表中的所有隧道接口发送组播报文。
所述 MN所属的 MAG收到所述 MN发送的声明退出频道的频道订阅报 文后， 判断所述 MN是 MAG上最后一个接收来自指定组播源 MN-S的组播 数据的组播接收者时，则删除所述 MN所属的 MAG到所述 MN-S所属的 MAG 组播隧道， 否则保留所述组播隧道。拆除所述组播隧道的方式包括： 所述 MN 所属的 MAG通过组播隧道向所述 MN-S所属的 MAG发送 PIM剪枝消息， 并删除所述 MN-S对应的组播路由项， 所述 MN-S所属的 MAG收到所述剪 枝消息后， 将所述 MN-S所属的 MAG到所述 MN所属的 MAG的隧道接口 从组播路由项的出接口列表中删除。
本方案可以为每个组播源 MN-S创建一个组播隧道， 从该组播源发出的 所有频道"¾文共享该组播隧道；也可以为每个频道分别创建自己的组播隧道， 从组播源发往不同频道的组播报文通过各自的组播隧道转发。 本方案中以共 享组播隧道为例进行了详细说明。
与上述方法对应的为组播 文建立最短路径的系统， 包括 MN所属的
MAG和 MN-S所属的 MAG,其中，所述 MN所属的 MAG设置为与所述 MN-S 所属的 MAG建立组播隧道； 所述 MN-S所属的 MAG设置为： 与所述 MN 所属的 MAG建立所述组播隧道； 以及， 在收到所述 MN-S发出的组播 4艮文 后， 将所述组播报文通过所述组播隧道发送至所述 MN所属的 MAG。 本系统中 MN所属 MAG和 MN-S所属 MAG的执行方式与上述方法中 相应相同。
所述 MN所属的 MAG还设置为： 在所述组播隧道建立完成后根据所述 MN上报的组播侦听发现报告消息指示的频道信息判断本地是否存在该频道 的组播路由项， 不存在时， 为此频道创建新的组播路由项， 并将此组播路由 项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道 接口， 将接收所述 MN上报组播侦听发现报告消息的接口添加到此组播路由 项的出接口列表中； 存在时， 更新此组播路由项， 并将此组播路由项中的入 接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口， 将 接收所述 MN上报组播侦听发现报告消息的接口添加到此组播路由项的出接 口列表中。
所述 MN所属的 MAG还设置为： 在创建组播路由项的同时， 通过所述 组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消息以声明加入 所述频道。
所述 MN-S所属的 MAG还设置为： 在收到所述 MN所属的 MAG通过 组播隧道发送的协议无关组播加入消息后， 判断是否存在所述频道的组播路 由项， 不存在时， 为此频道创建新的组播路由项， 并将接收所述协议无关组 播加入消息的隧道接口添加到组播路由项的出接口列表中， 存在时， 更新此 组播路由项的出接口列表， 将接收协议无关组播加入消息的隧道接口添加到 出接口列表中。
所述 MN所属的 MAG是设置为通过如下方式与所述 MN-S所属的 MAG 建立组播隧道： 在所述组播隧道建立过程中， 向所述 MN-S所属的 MAG发 送组播隧道建立消息， 并在收到所述 MN-S所属的 MAG返回的组播隧道建 立应答消息后， 建立到所述 MN-S所属的 MAG的组播隧道端节点；
所述 MN-S所属的 MAG是设置为通过如下方式与所述 MN所属的 MAG 建立组播隧道： 收到所述组播隧道建立消息后， 向所述 MN所属的 MAG发 送组播隧道建立应答消息， 并建立到所述 MN所属的 MAG的组播隧道端节 点。
所述 MN所属的 MAG还设置为收到所述 MN发送的声明退出频道的频 道订阅报文后，判断所述 MN是 MAG上最后一个接收来自指定组播源 MN-S 的组播数据的组播接收者时， 则删除所述 MN所属的 MAG到所述 MN-S所 属的 MAG组播隧道， 否则保留所述组播隧道。
本方案提供的移动接入网关， 包括组播处理模块， 其设置为处理组播报 文， 其执行方式与上述方法中相应相同。 例如， 所述组播处理模块设置为： 在所处的移动接入网关 （MAG )作为组播接收端 （MN )所属的 MAG时， 与组播源 （MN-S )所属的 MAG建立组播隧道； 以及， 在所述 MAG作为组 播源 MN-S所属的 MAG时， 与所述 MN所属的 MAG建立所述组播隧道， 并在收到所述 MN-S发出的组播 文后， 将所述组播 文通过所述组播隧道 发送至所述 MN所属的 MAG。
所述组播处理模块还设置为：在所处的 MAG作为所述 MN所属的 MAG 时， 在所述组播隧道建立完成后根据所述 MN上报的组播侦听发现报告消息 指示的频道信息判断本地是否存在该频道的组播路由项， 不存在时， 为此频 道创建新的组播路由项， 并将此组播路由项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口，将接收所述 MN上艮组播侦听 发现报告消息的接口添加到此组播路由项的出接口列表中； 存在时， 更新此 组播路由项， 并将此组播路由项中的入接口设置为所述 MN所属 MAG到所 述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播侦听发现 4艮告 消息的接口添加到此组播路由项的出接口列表中。
所述组播处理模块还设置为在所处的 MAG作为所述 MN所属的 MAG 时，在创建组播路由项的同时， 通过所述组播隧道向所述 MN-S所属的 MAG 发送协议无关组播加入消息以声明加入所述频道。
所述组播处理模块还设置为：在所处的 MAG作为所述 MN-S所属的 MAG 时， 收到所述 MN所属的 MAG通过组播隧道发送的协议无关组播加入消息 后， 判断本地是否存在所述频道的组播路由项， 不存在时， 为此频道创建新 的组播路由项， 并将接收所述协议无关组播加入消息的隧道接口添加到组播 路由项的出接口列表中， 存在时， 更新此组播路由项的出接口列表， 将接收 协议无关组播加入消息的隧道接口添加到出接口列表中。
上述系统的组播处理模块的其它执行方式与上述方法中相同， 此处不再 赘述。
下面结合附图详细对本方案进行详细。
如图 2所示，具体实施例中建立优化 SPT路径 101的方法包括以下步骤： 步骤 200, MN需要接收来自组播源 MN-S、 发往组播组 G的 IPv6组播 数据， MN向 MAG1发送 MLD报告报文（ MLD Report ) 以声明加入频道 ( HoA, G ) , HoA代表组播源 MN-S的地址， G代表组播地址。
其中， ΜΝ可以主动向 MAG1发送 MLD报告报文， 也可以等待 MAG1 发来的 MLD查询 文， 然后发送 MLD ^艮告 ^艮文。
步骤 201 , MAG1收到 ΜΝ的 MLD ^艮告^艮文消息后，向 LMA查询 MAG2 的地址， 查询消息中携带 MN-S的地址 ΗοΑ。
步骤 202 , LMA收到查询消息 PBQ后， 根据 MN-S的地址 HoA查询本 地绑定緩存表项 BCE, 查找到 MAG2的地址， 并通知 MAG1。
在进行 SPT路径优化前组播接收者 MN和组播源 MN-S已经在 LMA上 进行了绑定注册， LMA已经为 MN和 MN-S创建了对应的绑定緩存表项 BCE。
步骤 203 , MAG1 向 MAG2发送代理组播隧道建立消息 PMT ( Proxy Multicast Tunnel ) , 消息源地址为 MAGI的地址， 目的地址为 MAG2的地址。
步骤 204, MAG2收到 PMT消息后，向 MAG1发送代理组播隧道建立应 答消息 PMTR ( Proxy Multicast Tunnel Reply ) ， 同时 MAG2建立到移动接入 网关 MAG1的双向隧道的端节点。
步骤 205 , MAG1收到 PMTR消息后， 建立到移动接入网关 MAG2的双 向隧道的端节点。 MAG1和 MAG2之间的双向组播隧道建立完成， 该双向隧 道用于承载组播控制报文和组播数据报文。
步骤 206, MAG1为接收 MLD报告消息的接口 （即接收 MN的频道订 阅报文的接口）创建或者更新 MLD状态表（G, 过滤模式， 组播源地址列表， 定时器），并根据 MLD报告消息中的频道信息判断是否存在该频道对应的组 播路由项， 不存在时， 创建新的组播路由项（HoA, G ) , 将组播路由项中的 入接口（即 RPF接口）设置为 MAG1到 MAG2的隧道接口，将所述接收 MLD 报告消息的接口添加到组播路由项的出接口列表中； 存在时， 更新此组播路 由项 （HoA, G ) , 将组播路由项中的入接口 （即 RPF接口）设置为 MAG1 到 MAG2的隧道接口， 将所述接收 MLD报告消息的接口添加到组播路由项 的出接口列表中。 所述组播路由项包括组播源地址 HoA、 组播组地址 G、 入 接口、 出接口列表、 定时器和标志等。
步骤 207 , MAG1通过组播隧道向 MAG2发送 PIM加入消息，并在此 PIM 加入消息中携带 MN和 MN-S所属频道的频道信息。
步骤 207和步骤 206没有执行先后顺序。
步骤 208, MAG2根据接收到的 PIM加入消息中的频道信息创建组播 路由项 (HoA, G) , 并将接收 PIM Join消息的隧道接口添加到组播路由项的出 接口列表中。 如果 MAG2上已经存在该频道的组播路由项， 则更新出接口列 表， 将接收 PIM Join消息的隧道接口添加到出接口列表中。
步骤 209, MN-S向组播组 G发送组播报文 M-data ( Multicast data ) , MAG2收到组播报文后， 向出接口列表中的所有出接口转发该组播报文。
步骤 210, MAG2对组播艮文进行隧道封装后发送给 MAG1。
步骤 211 , MAG1 收到来自隧道的组播报文后， 查询组播路由项， 如果 报文实际到达的接口与组播路由项中的入接口一致， 则向出接口列表中的所 有出接口转发该组播报文。 如果报文实际到达的接口与组播路由项中保存的 入接口不匹配， 则对此报文执行 RPF检查： 若其 RPF接口与入接口一致， 则 说明 MAG2中保存的组播路由项 （HoA, G )正确， 认为此报文来自错误路 径， 丟弃此报文； 若其 RPF接口与入接口不符， 则说明 MAG2中保存的组播 路由项 （ HoA, G ) 已过期， 于是把入接口更新为 RPF接口。
本实施例通过以上步骤建立了优化 SPT路径， 组播接收者 MN接收组播 源的组播数据时不需要经过各自的锚点 LMA, 优化了组播转发路径， 提高了 组播路由效率。 本方案以 SSM模型为前提对 SPT路径进行优化， 对于 ASM模型， 当组 播接收者侧的移动接入网关 MAG1检测到从 RP发往组播组 G的组播数据速 率超过一定的阔值时， 将由 MAG1发起从 RPT向 SPT的切换， 当该切换发 生时运用本实施例的方法也可以建立优化的 SPT路径。
如图 3所示， 对 SPT树进行剪枝的方法流程图包括以下步骤：
步骤 300〜步骤 302, 组播源 MN-S通过 MAG2和 MAG1之间的隧道向 MN发送组播报文。
步骤 303 , MN要求拒绝来自组播源 MN-S、 发往组播组 G的 IPv6组播 数据， MN向 MAG1发送 MLD报告报文以声明离开频道（ HoA, G ) 。
其中， MN可以主动向 MAG1发送 MLD报告报文， 也可以等待 MAG1 发来的 MLD查询 文， 然后发送 MLD ^艮告 ^艮文。
步骤 304, MAG1收到 MN的 MLD 4艮告 文后， 删除接收 MLD报告 才艮文的接口的 MLD状态表， 更新组播路由项 （HoA, G ) 。
对于指定的组播源 MN-S,如果 MN不是 MAG1下最后一个组播接收者， 即 MAG1下还存在其他的移动节点需要接收 MN-S的组播数据， 则不需要拆 除 MAG1和 MAG2之间的隧道；如果 MN是 MAG1下最后一个组播接收者， 则执行步骤 305到步骤 309。
步骤 305 , MAG1通过组播隧道向 MAG2发送 PIM剪枝消息。
步骤 306 , 删除 MAG1上组播源 MN-S对应的组播路由项 （ HoA, G ) 。 步骤 307, 拆除与 MAG2建立的隧道。
步骤 308, MAG2收到来自 MAG1的剪枝 4艮文后， 对组播路由项（HoA, G )进行更新， 将隧道接口 （即 MAG2到 MAG1的隧道接口 )从组播路由项 的出接口列表中删除。
步骤 309, 拆除与 MAG1建立的隧道。
通过以上步骤对 SPT树进行剪枝， 通过隧道发送剪枝 文， 优化了剪枝 流程， 提高了组播路由效率。 需要指出的是， 在以上实施例中， MN-S发往任意组播组的组播"¾文都 通过 MAG2和 MAG1之间的隧道进行发送， 即对于指定源 MN-S而言， 所有 频道共享同一条隧道， 此隧道可以是 IP-in-IP、 GRE等隧道。 利用本方案提供 的技术方案也可以为每个频道创建一条专有隧道，可以通过建立 GRE隧道来 实现， 并使用 GRE Key来区分不同频道的隧道， 本领域的技术人员运用本方 案所公开的技术可以方便的得出通过专有隧道建立和更新优化的 SPT树的流 程。
以上实施例针对 ΡΜΙΡνό的场景， 并且运用 MLDv2进行 IPv6组播组成 员管理。 本方案中的技术方案同样适用于代理移动 IPv4的场景， 本领域的技 术人员可以根据本方案实施例中的技术方案， 并结合本领域的现有技术方案 即可实现。 在代理移动 IPv6中的移动节点使用 MLDv2加入组播组， 而在代 理移动 IPv4中的移动节点使用 IGMPv3加入组播组。
需要说明的是， 在不冲突的情况下， 本申请中的实施例及实施例中的特 征可以相互任意组合。
当然， 本发明还可有其他多种实施例， 在不背离本发明精神及其实质的 但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成， 所述程序可以存储于计算机可读存储介质中， 如只读 存储器、 磁盘或光盘等。 可选地， 上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。 相应地， 上述实施例中的各模块 /单元可以釆用 硬件的形式实现， 也可以釆用软件功能模块的形式实现。 本发明不限制于任 何特定形式的硬件和软件的结合。
工业实用性
本发明实施方式提供的建立优化 SPT路径的方法可以提高路由效率和移 动组播的性能。

Claims

1、 一种为组播报文建立优化路径的方法， 包括：
在组播接收端 （MN )所属的移动接入网关 （MAG )与组播源 （MN-S ) 所属的 MAG之间建立组播隧道，所述 MN-S所属的 MAG收到所述 MN-S发 出的组播 文后， 将所述组播 文通过所述组播隧道发送至所述 MN所属的 MAG„
2、 如权利要求 1所述的方法， 还包括：
所述组播隧道建立完成后， 所述 MN所属的 MAG根据所述 MN上 4艮的 组播侦听发现报告消息指示的频道信息判断本地是否存在该频道信息所对应 的频道的组播路由项， 若不存在， 为此频道创建新的组播路由项， 并将所创 建的组播路由项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口，将接收所述 MN上报组播侦听发现报告消息的接口添加到 此组播路由项的出接口列表中； 若本地存在所述频道的组播路由项， 则更新 此组播路由项， 并将此组播路由项中的入接口设置为所述 MN所属 MAG到 所述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播侦听发现才艮 告消息的接口添加到此组播路由项的出接口列表中。
3、 如权利要求 2所述的方法， 其中，
为所述频道创建新的组播路由项的步骤中， 所述 MN所属的 MAG通过 所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消息以声明 加入所述频道。
4、 如权利要求 3所述的方法， 还包括：
所述 MN-S所属的 MAG收到所述 MN所属的 MAG通过组播隧道发送 的协议无关组播加入消息后， 判断本地是否存在所述频道的组播路由项， 若 不存在， 为此频道创建新的组播路由项， 并将接收所述协议无关组播加入消 息的隧道接口添加到所创建的组播路由项的出接口列表中， 若本地存在所述 频道的组播路由项， 则更新此组播路由项的出接口列表， 将接收协议无关组 播加入消息的隧道接口添加到该组播路由项的出接口列表中。
5、 如权利要求 1、 2、 3或 4所述的方法， 其中， 在 MN所属的 MAG 与 MN-S所属的 MAG之间建立组播隧道的步骤包括：
所述 MN所属的 MAG向所述 MN-S所属的 MAG发送组播隧道建立消 息， 所述 MN-S所属的 MAG向所述 MN所属的 MAG发送组播隧道建立应 答消息， 并建立到所述 MN所属的 MAG的组播隧道端节点， 所述 MN所属 的 MAG建立到所述 MN-S所属的 MAG的组播隧道端节点 ,组播隧道建立完 成。
6、 如权利要求 5所述的方法， 其中，
所述组播隧道建立消息和组播隧道建立应答消息是对应的移动头消息； 或者是携带了指示组播隧道建立标志的移动选项的对应的代理绑定更新消息 和代理绑定应答消息。
7、 如权利要求 1所述的方法， 其中， 将所述组播报文通过所述组播隧道 发送至所述 MN所属的 MAG的步骤包括：
所述 MN-S所属的 MAG收到所述 MN-S发送的组播 文后， 查找组播 路由项， 并向该组播路由项的出接口列表中的所有隧道接口发送所述组播报 文。
8、 如权利要求 1、 2、 3或 4所述的方法， 还包括：
所述 MN所属的 MAG收到所述 MN发送的声明退出频道的频道订阅报 文后， 判断所述 MN是否是本 MAG上最后一个接收来自指定 MN-S的组播 数据的组播接收者， 若是， 则删除到所述指定 MN-S所属的 MAG的组播隧 道， 若不是则保留到所述指定 MN-S所属的 MAG的组播隧道。
9、 如权利要求 8所述的方法， 其中，
删除组播隧道的方式包括： 所述 MN所属的 MAG通过组播隧道向所述 MN-S所属的 MAG发送协议无关组播（ PIM )剪枝消息， 并删除所述 MN-S 对应的组播路由项， 所述 MN-S所属的 MAG收到所述 PIM剪枝消息后， 将 到所述 MN所属的 MAG的隧道接口从组播路由项的出接口列表中删除。
10、 一种为组播 ^艮文建立优化路径的系统， 包括组播接收端（ MN )所属 的移动接入网关 （MAG )和组播源 （MN-S )所属的 MAG, 其中，
所述 MN所属的 MAG设置为与所述 MN-S所属的 MAG建立组播隧道； 所述 MN-S所属的 MAG设置为： 与所述 MN所属的 MAG建立所述组播 隧道； 以及在收到所述 MN-S发出的组播 文后， 将所述组播 文通过所述 组播隧道发送至所述 MN所属的 MAG。
11、 如权利要求 10所述的系统， 其中，
所述 MN所属的 MAG还设置为： 在所述组播隧道建立完成后， 根据所 述 MN上报的组播侦听发现报告消息指示的频道信息判断本地是否存在该频 道信息所对应的频道的组播路由项， 若不存在， 为此频道创建新的组播路由 项， 并将所创建的组播路由项中的入接口设置为所述 MN所属 MAG到所述 MN-S所属的 MAG的隧道接口 ,将接收所述 MN上报组播侦听发现报告消息 的接口添加到此组播路由项的出接口列表中； 若本地存在该频道的组播路由 项， 则更新此组播路由项， 并将此组播路由项中的入接口设置为所述 MN所 属 MAG到所述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播 侦听发现报告消息的接口添加到此组播路由项的出接口列表中。
12、 如权利要求 11所述的系统， 其中，
所述 MN所属的 MAG还设置为在为所述频道创建新的组播路由项的同 时， 通过所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消 息以声明加入所述频道。
13、 如权利要求 12所述的系统， 其中，
所述 MN-S所属的 MAG还设置为：在收到所述 MN所属的 MAG通过组 播隧道发送的协议无关组播加入消息后， 判断本地是否存在所述频道的组播 路由项， 若不存在， 为此频道创建新的组播路由项， 并将接收所述协议无关 组播加入消息的隧道接口添加到所创建的组播路由项的出接口列表中， 若本 地存在所述频道的组播路由项， 则更新此组播路由项的出接口列表， 将接收 协议无关组播加入消息的隧道接口添加到该组播路由项的出接口列表中。
14、 如权利要求 10、 11、 12或 13所述的系统， 其中，
所述 MN所属的 MAG是设置为通过如下方式与所述 MN-S所属的 MAG 建立组播隧道： 在所述组播隧道建立过程中， 向所述 MN-S所属的 MAG发 送组播隧道建立消息， 并在收到所述 MN-S所属的 MAG返回的组播隧道建 立应答消息后， 建立到所述 MN-S所属的 MAG的组播隧道端节点； 所述 MN-S所属的 MAG是设置为通过如下方式与所述 MN所属的 MAG 建立所述组播隧道： 收到所述组播隧道建立消息后，向所述 MN所属的 MAG 发送组播隧道建立应答消息， 并建立到所述 MN所属的 MAG的组播隧道端 节点。
15、 如权利要求 14所述的系统， 其中，
所述组播隧道建立消息和组播隧道建立应答消息是对应的移动头消息； 或者是携带了指示组播隧道建立标志的移动选项的对应的代理绑定更新消息 和代理绑定应答消息。
16、 如权利要求 10、 11、 12或 13所述的系统， 其中，
所述 MN所属的 MAG还设置为在收到所述 MN发送的声明退出频道的 频道订阅报文后， 判断所述 MN是否是本 MAG上最后一个接收来自指定 MN-S的组播数据的组播接收者， 若是， 则删除到所述指定 MN-S所属 MAG 的组播隧道， 若不是则保留到所述指定 MN-S所属 MAG的组播隧道。
17、 一种移动接入网关， 包括组播处理模块； 所述组播处理模块设置为： 在所处的移动接入网关（ MAG )作为组播接收端（ MN )所属的 MAG时， 与组播源 （MN-S )所属的 MAG建立组播隧道； 以及
在所处的 MAG作为 MN-S所属的 MAG时， 与 MN所属的 MAG建立组 播隧道； 并在收到所述 MN-S发出的组播报文后， 将所述组播报文通过所建 立的组播隧道发送至所述 MN所属的 MAG。
18、 如权利要求 17所述的移动接入网关， 其中， 所述组播处理模块还设 置为：
在所处的 MAG作为所述 MN所属的 MAG时， 在所述组播隧道建立完 成后根据所述 MN上报的组播侦听发现报告消息指示的频道信息判断本地是 否存在该频道信息对应的频道的组播路由项， 若不存在， 则为此频道创建新 的组播路由项， 并将所创建的组播路由项中的入接口设置为所处的 MAG到 所述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上艮组播侦听发现才艮 告消息的接口添加到此组播路由项的出接口列表中； 若本地存在所述频道的 组播路由项， 则更新此组播路由项， 并将此组播路由项中的入接口设置为所 处的 MAG到所述 MN-S所属的 MAG的隧道接口， 将接收所述 MN上 4艮组 播侦听发现报告消息的接口添加到此组播路由项的出接口列表中。
19、 如权利要求 18所述的移动接入网关， 其中，
所述组播处理模块还设置为在所处的 MAG作为所述 MN所属的 MAG 时， 在为所述频道创建新的组播路由项的同时， 通过所述组播隧道向所述 MN-S所属的 MAG发送协议无关组播加入消息以声明加入所述频道。
20、 如权利要求 19所述的移动接入网关， 其中，
所述组播处理模块还设置为： 在所处的 MAG作为所述 MN-S 所属的 MAG时，收到所述 MN所属的 MAG通过组播隧道发送的协议无关组播加入 消息后， 判断本地是否存在所述频道的组播路由项， 若不存在， 为此频道创 建新的组播路由项， 并将接收所述协议无关组播加入消息的隧道接口添加到 所创建的组播路由项的出接口列表中， 若本地存在所述频道的组播路由项， 则更新此组播路由项的出接口列表， 将接收协议无关组播加入消息的隧道接 口添加到该组播路由项的出接口列表中。
PCT/CN2012/082880 2011-10-13 2012-10-12 一种为组播数据建立优化路径的方法及系统 WO2013053334A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110309827.7A CN103051545B (zh) 2011-10-13 2011-10-13 一种为组播数据建立优化路径的方法及系统
CN201110309827.7 2011-10-13

Publications (1)

Publication Number Publication Date
WO2013053334A1 true WO2013053334A1 (zh) 2013-04-18

Family

ID=48064050

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/082880 WO2013053334A1 (zh) 2011-10-13 2012-10-12 一种为组播数据建立优化路径的方法及系统

Country Status (2)

Country Link
CN (1) CN103051545B (zh)
WO (1) WO2013053334A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103259736A (zh) * 2013-05-24 2013-08-21 杭州华三通信技术有限公司 一种隧道建立方法和网络设备
CN109842918B (zh) * 2017-11-24 2020-09-08 华为技术有限公司 一种无线通信的方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010118698A1 (en) * 2009-04-17 2010-10-21 Huawei Technologies Co., Ltd. Apparatus and method for basic multicast support for proxy mobile internet protocol version six (ipv6)
CN101909276A (zh) * 2009-06-04 2010-12-08 中国移动通信集团公司 一种移动组播切换方法、系统及相关设备
US20110122815A1 (en) * 2008-03-03 2011-05-26 Panasonic Corporation Information exchange between gateways for route optimization with network-based mobility management

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110122815A1 (en) * 2008-03-03 2011-05-26 Panasonic Corporation Information exchange between gateways for route optimization with network-based mobility management
WO2010118698A1 (en) * 2009-04-17 2010-10-21 Huawei Technologies Co., Ltd. Apparatus and method for basic multicast support for proxy mobile internet protocol version six (ipv6)
CN101909276A (zh) * 2009-06-04 2010-12-08 中国移动通信集团公司 一种移动组播切换方法、系统及相关设备

Also Published As

Publication number Publication date
CN103051545A (zh) 2013-04-17
CN103051545B (zh) 2017-07-18

Similar Documents

Publication Publication Date Title
US8102792B2 (en) Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address
KR101216757B1 (ko) 하이브리드 멀티캐스팅 가능하고 비-멀티캐스팅 가능한 ｒａｎｓ를 통한 멀티캐스트 트래픽 흐름을 가능하게 하기 위한 방법
US9871718B2 (en) Method and device for registering multicast source and establishing multicast path
US8953595B2 (en) Route-optimised mulitcast traffic for a mobile network node
JP2014520428A (ja) マルチパスオーバーレイネットワーク及びそれのマルチパス管理プロトコル
WO2012083844A1 (zh) 传输组播数据的方法、组播树的更新方法以及系统和装置
WO2013056669A1 (zh) 在组播接收端切换场景下建立优化路径的方法及系统
Schmidt et al. Multicast mobility in mobile IP version 6 (MIPv6): problem statement and brief survey
KR20110114662A (ko) 모바일 멀티캐스트 서비스를 위한 고정 네트워크에서 멀티캐스트 백홀 채널들의 셋 업을 보조하기 위한 방법 및 장치
WO2009046622A1 (fr) Procédé et appareil de commande de paquets ip multidiffusion dans un réseau d'accès
Schmidt et al. Mobile multicast sender support in proxy mobile IPv6 (PMIPv6) domains
CN110999230B (zh) 传输组播报文的方法、网络设备和系统
WO2008154796A1 (fr) Procédé et équipement permettant de commander la transmission de paquets de données de multidiffusion dans la station de base et la passerelle du système wimax
WO2013053334A1 (zh) 一种为组播数据建立优化路径的方法及系统
Bettstetter et al. Interoperation of Mobile IPv6 and protocol independent multicast dense mode
KR20120011803A (ko) 이동 통신 시스템에서 이동 노드에 대한 멀티캐스트 서비스 제공 방법 및 장치
WO2012089032A1 (zh) 一种采用多种接入方式中的数据传输方法和接入设备
KR101407669B1 (ko) 망 기반 이동성 관리 시스템 및 모바일 멀티캐스트 서비스 핸드오버 방법
WO2013056633A1 (zh) 在组播源切换场景下建立优化路径的方法及系统
Ponnusamy A survey on wired and mobile multicast group membership management protocol
Gao et al. RFC 7287: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
Waehlisch Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains draft-ietf-multimob-pmipv6-source-08
Takahashi et al. Multicast source handover scheme based on proxy router discovery
Mohd et al. Mathematical Evaluation of a Context Transfer-based Approach to Improve Handover in Mobile Multicast Environment
Schmidt et al. RFC 5757: Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12840631

Country of ref document: EP

Kind code of ref document: A1