MXPA06007339A - Route-optimised multicast traffic for a mobile network node - Google Patents

Abstract

A method of communicating traffic from a source to a group (G) of nodes including a Network Node (MNN) in a network using one or more multicast protocols. The network also comprises a Router (MR) for forwarding traffic between the network and the Internet and a Multicast Signalling Gateway (MSG) co-located with the Router (MR) and translating on an interface signalling messages of a multicast routing protocol (MRP) into messages of a group membership protocol (GMP). In the case of mobile networks, the interface is preferably an egress interface of the Mobile Router (MR). The Multicast Signalling Gateway (MSG) preferably translates multicast packets together with unicast source addresses and multicast destination addresses of multicast packets between IPv4 and IPv6 protocols.

Description

TRAFFIC OPTIMIZED ROUTE MÜLTIEMISION FOR MOBILE NETWORK NODE FIELD OF THE INVENTION This invention relates to optimized route multiemission traffic for a mobile network node.

BACKGROUND OF THE INVENTION Traditional mobility support has as its main purpose to provide continuous connectivity to the Internet to mobile hosts; thus offering support to the mobility of the host. In contrast, mobility support to the network is related to situations where a whole network changes its connection point to the topology of the Internet and thus its ability to reach the topology. That network in motion can be called a mobile network. There are a large number of scenarios where these mobile networks exist. Two of many examples are: • A Personal Area Network (PAN, that is, a network of several personal devices linked to an individual) that change their point of attachment to the topology of the Internet while the user is walking in a shopping center. • A network included in a vehicle, such as a bus, a train or an airplane that provides access to the Internet on board passengers. A passenger can use a single device (such as a laptop) or have a mobile network (such as a PAN), which then illustrates a case of a mobile network visiting a mobile network (ie, nested mobility). Therefore a mobile network can be defined as a set of nodes (called Mobile Network Nodes or MNN) forming one or more IP subnets attached to a mobile router (MR), the mobile network (the MR and all its MNNs being linked) ) being mobile as a unit with respect to the rest of the Internet. Internet-Draft draft-ernst-monet-terrrtinology-00.txt [Thierry Ernst, Hong-Yon Lach, "Network Mobility Support Terminology", draft-ernst-monet-terminology-00.txt, February 2002, work in progress] define the terminology for mobile networks that will be used in the following. Especially the following terms are defined: • Local Fixed Node (LFN): A node permanently located within the mobile network and that does not change its connection point. An LFN can be an LFH (local fixed host) or a LFR (Local Fixed Router). • Local Mobile Node (LMN): A mobile node that belongs to the mobile network and that changes its connection point from one link within the mobile network to another link inside or outside the mobile network (the local link in the LMN is a link within the mobile network). An LMN can be a LMH (Local Mobile Host) or an LMR (Local Mobile Router). • Mobile Visitor Node (VMN): A mobile node that does not belong to the mobile network and that changes its connection point from a link outside the mobile network to a link within the mobile network (the local link of the VMN is not a link within the Mobile Network). A VMN that connects to a link within the mobile network obtains an address on that link. A VMN can be a VMH (Visiting Mobile Host) or a VMR (Visiting Mobile Router). • Mobile Network Prefix: An ordered sequence of bits consisting of some number of initial bits in an IP address that defines a mobile network within the topology of the Internet. The nodes belonging to the mobile network (ie at least the MR, LFN and LMN) share the same "network identifier" IPv6. For a single mobile IP subnet, the mobile network prefix is the "network identifier" of this subnet. • Exit interface of an MR: The interface linked or connected to the local link if the mobile network is at home, or connected to a foreign link if the mobile network is a foreign network. • Access interface of an MR: the interface linked or connected to a link within the mobile network.

While the draft of the mobile IPvd specification [D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPVD", draft-ietf-mobileip-ipv6-20.txt, January 2003, work in progress] defines two means for a Mobile Node to receive multi-broadcast traffic while it is in motion, namely bidirectional tunneling and remote subscription, only the bidirectional tunneling method is currently contemplated in the case of a mobile network. In fact, the most advanced proposals depend on the bidirectional tunneling between the mobile router and its local agent through which the unification or multiemission traffic of the nodes of the mobile network in both directions must be sent. Especially in the case of multi-broadcast traffic. • Multicast packets for MNN (that is, multicast packets addressed to a multicast group G to which the MNN has subscribed - the MNN is a multicast receiver) are routed along the multicast tree in the structure through the local link of the mobile router; intercepted by the local agent HA of the MR that tunnels them through a tunnel of uniemission to the MR, destunelizados by the MR and sent along the tree of multiemisión within the mobile network, and finally received by the MNN as shown in Figure 1 of the accompanying drawings. • The output packets (ie the multicast packets sent by the MNN to a multicast group G- the MNN is a multicast generator) are routed to the mobile router, tunneled back by the MR to its Local Agent HA, and thence routed to the multicast distribution tree as shown in Figure 2. This mechanism does not provide optimization of the route to the MNNs since the multiemission packets between the multiemission distribution tree (in the structure) and the MNN must pass through the bidirectional tunnel between the MR and the HA, which potentially produces a much longer trajectory (take as an illustrative example an MR used in an airplane that flies over the United States while its HA is located in France). Thus, there is a need for means to allow MNNs to receive multicast traffic along an optimized path, i.e. having packets distributed through the multiemission tree to or from the current location of the mobile router without the need to transit. through the local agent HA of the MR. US Patent Specification 20020150094 proposes a new IP multicast routing protocol, called "Hierarchical Level IP Multiemission" (HLIM) which is said to support not only the host's mobility (IP host movement) but also the network mobility (movement of IP routers with or without connected hosts). Especially, it is said that the HLIM preserves the distribution over the shortest path of multiemmission traffic from a source or generator to a receiver located within a mobile network when the network changes its connection point in the topology. However, the HL1M, which has been designed for tactical networks, which can operate in very specific network topologies (hierarchical networks), which is not the case of the Internet, thus limiting its applicability to commercial applications. In addition, the HLIM requires all routers in the topology to execute this new protocol, which is not realistic on the Internet, whose multicast model is based on many multiemission domains (owned by different parties) and possibly running different multicast protocols (such as DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, for example). In this way HLIM does not provide means to support the distribution by the optimized route of the multiemmission traffic to a roaming mobile network on the Internet, regardless of the multiemmission routing protocols used inside and outside the mobile network. It is not desirable for a mobile walker to resend forwarding multicast routing signaling messages (used to manage the multicast tree) between the nodes in the mobile network and the visited network (rather than through its local network and its local agent) HA) to reconstruct a branch of the multicast tree to the current location of the mobile router activated by the multicast. This method is applicable if and only if the same multicast routing protocol is executed within the mobile network and the visited network. As explained above, due to the very large number of existing multicast protocols, this requirement will rarely be satisfied in practice. As a result, this method does not allow delivery over the optimized route of multiemmission traffic regardless of the location of the mobile network on the Internet. In addition, in practice, the security policies of the visited network will generally prohibit an injection of routing signaling (unicam and multiemission) from unauthorized nodes such as a visiting mobile router (the mobile router may be owned by a different organization). It has been proposed that the mobile network deploy in all routers within the mobile network a mechanism called "multicast sending based on IGMP / MLD" [B. Fenner, H. He, Nortel Networks, B. Haberman, H. Sandick, "IGMP / MLD-based Multicast Forwarding (" IGMP / NLD Proxying "), draft-ietf-magma-igmp-proxy-02.txt, March 2003, work in process] instead of executing an internal multicast routing protocol, this method is intended to allow the mobile router to collect all the information of the members of the multi-broadcast group from within its mobile network, and to subscribe on its own to all those multiemmission groups that use the IGMP / MLD protocol with the access router activated by the multiemission in the visited domain The information of the group members will be forwarded hop by hop, in the mobile network, from the intended multiemission receiver up to the mobile router, by means of all the intermediate fixed routers approaching incoming IGMP / MLD reporting messages to their originating enclosure (this is known as the IGMP approach or MLD approach). On the other hand, the mobile router manages the multi-broadcast subscription in the visited domain in favor of all the nodes in the mobile network. After the movement, it will activate the reconstruction of a new branch of multiemission in its new location sending reports of MLD to its new point of connection. However, this method requires a heavy manual configuration, in particular to define the upstream and downstream interfaces, in each router in the mobile network to make its internal topology similar to a tree routed in the mobile router. This makes this method applicable only for relatively small mobile networks with stable internal topology. In addition, it imposes the deployment of a new sending mechanism (IGMP / MLD proxies) on each internal router, and does not support the distribution by the optimized route of the multicast traffic for any other form of multiemmission routing deployed in the mobile network. This is a limitation, especially for large mobile networks where it is expected that regular multicast routing protocols will be deployed to facilitate multi-broadcast support within the mobile network. In this way there is a need for a mechanism that allows the distribution by an optimized route of multiemmission traffic to and from a mobile network: • regardless of the location of the mobile network on the Internet, • regardless of the type of routing protocols multi-broadcast used inside and outside the mobile network; and • through the extension of the mobile router involved only that is to say without change in any node in the mobile network or to the Internet.

SUMMARY OF THE INVENTION The present invention provides a method for communicating traffic from a generator to a group of nodes that includes a mobile network node (MNN) in a mobile network using one or more protocols and multi-broadcast apparatus for use in such method as it is described in the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic diagram of the routing of input multicast packets according to a known method, Figure 1 is a schematic diagram of the routing of output multicast packets according to the method of the Figure 1, Figure 3 is a schematic diagram of the routing of input multicast packets according to an embodiment of the invention, given by way of example; Figure 4 is a flow diagram of the steps in the method shown in Figure 3, and Figure 5 is an example of a group list maintained in the method shown in Figure 3.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES The embodiments of the present invention shown in Figures 3 to 5 of the accompanying drawings provide a greater degree of optimization of the route for multiemission traffic that offers certain key advantages: • Minimum delay since the packages They are sent on the shortest path. This is important since in many multi-broadcast applications they have rigorous requirements in terms of delay (eg audio / video stream, audio / video conferencing). • Reduced probability of packet loss due to congestion, since packets are sent along a shorter path. Again for real time multiemission applications, this will improve the quality of the flow on the receiver side. • Scalability and improved robustness. By avoiding the local HA agent of the mobile router, which can be easily overloaded due to the concentration of multiemisón traffic at this point, the optimization of the route reduces the probability of faults. • Reduced bandwidth overload since the packets are not tunneled. This helps to optimize the resources of the network. • PMTU (Trajectory Transmission Unit) Maximum on the MNN-CN trajectory, which ensures a minimum fragmentation of the payload. The embodiment of the present invention shown in Figure 3 comprises a multi-signal signaling gateway (MSG) colocalized with the mobile router and having a network interface activated by MSG to achieve the distribution by the optimized route of multiemmission traffic to the mobile network regardless of the location of the mobile network on the Internet, and regardless of the multicast routing protocol used inside and outside the mobile network. A key principle of the MSG is to translate the messages of a multiemmission routing protocol (MRP) into messages of a protocol of members of a group (GMP). It will be appreciated that this functionality of the MSG is completely different from the known ways in which the MRP and GMP protocols interoperate, including the translation of GMP messages into MRP messages. One possible way in which the MSG generates the GMP messages, as detailed below, is to forward over the so-called "service interface" provided by those GMP protocols. The "service interface" can be used for upper layer protocols or application programs to request the IP layer to enable and disable the reception of packets sent to specific IP multicast addresses (optionally any of a given set of sources or generators). This interface service can be understood as a function call, which typically becomes available at the API connection level. This is available for both IPv4 (IGMP) and IPv6 (MLD). The Multiemission Routing Protocols (MRP) are protocols responsible for the construction of a distribution tree, for example DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, etc. Basically, two families of multicast routing protocols can be distinguished. • Protocols that use explicit signaling to build the multicast tree: Those protocols define specific messages to be used by a multicast router of the receiver to activate the establishment of a multicast distribution branch to itself. The PIM-SM is an example of these protocols. These messages can be divided into two main categories: • "Input group": messages used by a multiemmission router to enter the multi-broadcast distribution tree. An example of that message is the PIM-SM entry. • "Output group": Messages used by a multicast router to leave the multicast distribution tree. An example of that message is the cutting of PIM-SM. • Protocol that uses overflow: These protocols do not necessarily define specific messages to be used by a multiemmission router of the receiver to enter a multiemission distribution tree. On the contrary, the packets sent by a multi-broadcast generator are overflowed over the entire network and listened to by any interested nodes. Most of the existing protocols in this category, however, include explicit signaling that allows you to "cut" a branch to stop the distribution of multiemmission traffic over a region of the network where there are no interested receivers. They also include support for "grafting" a branch when a new receiver appears. The PIM-DM is an example of these protocols. Group member protocols (GMPs) are protocols that allow a multiemmission receiver to announce their interest in receiving multicast packets sent to a multicast group G. Those are the Internet group management protocol (IGMP) for the group. IPv4, and the multiemmission listener discovery protocol (MLD) for IPv6. Note that recent versions of these protocols, IGMPv3 [B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC3376, May 2002] and MLDv2 [R. Vida, L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6". Draft-vida-mld-v2-06.txt, November 2002, work in progress], when compared to the previous versions add support to "filter the source". This refers to the ability of a receiver to report the interest of listening to packets only from specific source addresses or from all but specific source addresses, sent to a multiemmission address. "Network interface activated by MSG" means a network interface of a node that executes a multicast routing protocol on which the operations of the multiemmission signaling gateway are activated. A node can have varying network interfaces activated by MSG at the same time. In the case of the mobile router, all its return interfaces must be activated by MSG in order to achieve interconnection in the multiemission routing protocols inside and outside the mobile network thanks to the protocol of members of a group. Figure 3 illustrates the use of the MSG, in the case of a mobile router (MR) equipped with a single egress interface, by way of example. The MRP # 1 multiemission routing protocol is executed within the mobile network. The MR is linked to a visited network that executes a different multiemmission routing protocol MRP # 2. It is assumed that both of MRP # 1 and MRP # 2 are part of the "explicit signaling" family. It is also assumed that IPv6 in both the mobile network and the visited network. Due to the IPv6 context, the group member protocol (GMP) is MLD. The MSG is activated on the exit interface of the MR. When a MNN node within the mobile network subscribes to a multicast group G, sends an MLD_Report (G) message from the group member protocol to its local multicast router LFRl. Since the LFRl is not yet linked to the group G multicast tree (assuming that the MNN is the first receiver for the group G below LFRl), the LFRl sends an explicit MRP # l_entry (G) message from the routing protocol of issue # 1 within the mobile network to activate the establishment of a distribution branch to the LFRl. This branch establishment request propagates within the mobile network, eventually to the mobile router whose local case of the MRP # 1 protocol would decide to send an MRP # l_Entry (G) to the egress interface. Since this interface is activated by MSG, the MR instead issues an MLD_ Report (G) message from the group member protocol to the access router (AR) in the visited network, which results in the MRP messages # 2_Entry (G) of the multicast routing protocol # 2 propagates within the visited network to the multi-group distribution tree of group G. These operations have allowed the creation of two multiemission distribution branches (one in each domain of multiemisón) interconnected by the Mobile Router. As a result, the multicast packets (for example, an S source) sent to the G group without MRP # 2-native multiemissions routed to the MR in the visited network, and there from the MRP # l-native multicast routed to the MNN. The mobile router activated by MSG manages the multi-broadcast subscription in the visited domain in favor of all nodes in the mobile network. The MSG automatically discovers the subscription information (ie the group and the view of sources of interest) of the MRP messages arriving from within the mobile network. When the MR changes its connection point to the visited network (or Internet), the MR will activate the reconstruction of one or more new multi-broadcast branches in its new location by sending MLD reports to its new connection point for the multi-broadcast groups to those who have subscribed This is known as a remote subscription. Figure 4 is a flow diagram of the operations performed by the multicast signaling gateway (MSG) in an embodiment of the present invention, when a message of the multicast routing protocol (MRP message) is next to be sent to through a network interface ifc_i of the node hosting the MSG. If the interface ifc_i is not activated by MSG, then the MSG only ignores the message. If the ifc_i interface is activated by MSG, then the MRP message is analyzed to determine: • The MRP message class: The class takes one of the following three values. { ENTRY, DEPARTURE, NONE} as a function of the MRP message type (or the impact it has on the multiemission distribution tree). To any message, an MRP can be assigned one of those three values. That information can be stored within a table that is known as a class table to be used by the MSG for the purpose of classifying messages of a given multicast routing protocol. • The objective of the MRP message: The objective consists of the multicast of the G group to which the message refers, possibly together with an address of a source S. If an address of origin is not present, this means that the package refers to to any potential people. In this case, the wildcard symbol "*" is used to represent all sources: S = *. The objective can be expressed as a pair (S, G), or (*, G) in the case that specific information is not transported. If the MRP message class is NONE, it does not refer to specific MSG action for this package. This typically means that the packet does not have semantics that must be translated into a GMP protocol message for the purpose of performing the interconnection between multi-broadcast protocols on both sides of the MSG. If the MRP message class is ENTERED, source S (of the target) must be added to the existing list of sources of group G (of the target) maintained by the MSG for the interface ifc__i: MSG_srclis (ifc_i, G). This is the list of sources of group G for which the MSG must maintain the reception of traffic, through the interface ifc_i. For this purpose the MSG maintains a list that is referred to as a group list, as illustrated in Figure 5, which includes, for each interface activated by MSG, the list of the groups that are of interest along with their source lists. respective. Once it has been updated (or created in the case of a new entry) MSG_srclist (ifc_i, G) with the source S of the objective, it should be verified if this addition of S has modified MSG__srclist (ifc_i, G). If it has not been modified MSG-srclist (ifc-i, G) then no action is required. On the other hand, if MSG_srclist (ifc-i, G) has changed then the MSG must renew the GMP subscription for this new set of group G resources in the ifc_i interface. The MSG can use the GMP "service interface" (or API) for this purpose as any other multi-broadcast application would. If the MRP message class is OUT, the source is (of the target) must be removed from the existing list of sources of group G (of the target) maintained by the MSG for the interface ifc_i: MSG_srclist (ifc_i, G). Once MSG_srclist has been updated (ifc_i, G) it should be verified if this removal of S has modified MSG_srclist (ifc_i, G). If MSG_srclist (ifc_i, G) has not been modified then no action is required. On the other hand, if MSG_srclist (ifc_i, G) has changed and is now empty, the MSG must terminate the subscription other than group G of the ifc_i interface. In addition, the MSG can remove the entry for group G in this group list for ifcvL. If the updated MSG_srclist (ifc_i, G) is not empty, the MSG must renew the GMP subscription for this new set of resources from group G of the ifc_i interface. Then the MSG can use the GMP "service interface" (or API) for this purpose as any other multi-broadcast application does. The following arithmetic can be used when adding (+) or removing (-) a font (S or *) to / from a source list MSG_srclist (ifc_i, G): • A font can appear only once in the list : S + S = S, S - S = 0 • Adding all sources (*) to a list causes the list to include all sources: srclist + * = * (of course * + * = *) Remove all sources (*) from a list leaves the list empty (0): srclist - * = 0 (especially, * - * = 0) • The removal of a defined source S from a list that includes all sources (*) does not change the list: * - S = *.

Figure 5 shows an example list of the group maintained by an MSG. The following table shows the class table that can be used by an MSG for the PIM_SM multiemission routing protocol. Similar class tables can be established for any multicast routing protocol (which has explicit signaling) to be used by the MSG.

The sending of multiemison packets in a node activated by MSG is visible, and really transparent to the MSG. The sending of multicast packets is done according to the multicast sending table of the MRP protocol executed by the node activated by MSG. This is true regardless of whether the input interface is activated by MSG or not. Especially, in the case of the mobile network, multiemmission packets from an external source to the mobile network (ie, that have been subscribed through the interface activated by MSG) will be routed by multicasting to the egress interface of the MR (activated by MSG) and from there routed by multiemission within the mobile networks according to the Table of sending by local multiemisión of the MR. When the MSG-activated interface of the mobile router (MR) changes its connection point to the visited network (or the Internet), the MSG will activate the reconstruction of the necessary multi-broadcast branches in its new location by sending GMP reporting messages to subscribe to the multi-broadcast groups (and the respective sources) listed in the group list for the interface activated by MSG. A mobile router (MR) for which a given egress interface is at home can decide whether to configure this interface as activated by MSG or not. Regardless of the selected option, the multiemmission traffic will be routed to the MNNs in the same way (according to the local multicast submission table of the MR). However, configuring the interface as activated by MSG even when you are at home will allow ongoing multismision communications to be maintained when the interface connects to another topological location. This is because the MSG will have to understand the list of G streams in progress (and associated sources) and then they can be re-enrolled in the new location. In the event that the MSG-enabled interface of the mobile router (MR) returns home and the mobile router (MR) decides to deactivate the MSG on this interface, the multicast routing protocol will then normally operate through this interface to the local network. In that case, the MSG can remove any status in its group list for that given interface. Several methods can be performed for the implementation of the multi-signaling gateway (MSG). In particular, for example, this may be increased 1) as a separate program and programming system module or 2) as an extension (patch) of a multicast routing protocol (MRP) implementation. In both cases, in this embodiment of the present invention, the MSG interface to the group member protocol (MSG-GMP interface) can be implemented by retransmitting over the existing GMP "service interface": ListenMultiemission (connection, interface, address of multiemission, filter mode, list of sources). In this method the MSG requests the IP layer (GMP) to activate and deactivate the reception of packets sent to a specific IP multicast address in the same way that any multi-broadcast application program does (for example through a API connection activated by GMP). The implementation based on the previous service interface can be carried out in two different ways: a) MSG programming programs and systems manage the aggregation of sources for a given multi-broadcast group (MSG_srclist (ifc_i, G)) and use a single connection identifier (sid) to pass the whole list: ListenMultiemission (sid, ifc_i, G, INCLUDE, MSG_srclist (ifc_i, G)), or ListenMultiemisió (sid, ifc_i, G, EXCLUDE, {.}.), iff MSG_srclist (ifc_i, G) == * b) The programs and programming systems of the MSG use several connection ids (one for (S, G) objective) to pass the respective objective (S, G) and the associated class derived from the MRP message to the MLD module that is then in charge of adding the sources for a given multiemmission group. For a given goal (S, G): If the class is ENTRY: • ListenMultiemission (goal_sid, ifc_i, G, INCLUDE, S), or • ListenMultiemission (goal_sid, ifc_i, G, EXCLUDE, . { } ), if S == * 0 If the class is OUTPUT: • ListenMultiemission (target_sid, ifc_i, G, INCLUDE, S), or • ListenMultiemission (target_sid, ifc_i, G, EXCLUDE, . { } ), if S == * The second method requires the programs and programming systems of the MSG to generate a single target_object per target and store it in the list of MSG groups. The implementation of the MSG-MRP interface towards the multicast routing protocol (MRP) will depend on whether method 1) or 2) is chosen. The purpose of this interface is for the MSG to detect the "MRP message ready to be sent over the isc_i interface" (See the MSG status machine in Figure 4) to activate MSG operations. • Method 1): The MSG, as a module of programs and independent programming systems, can detect MRP messages by checking the packets sent over the interface ifc_i. • Method 2): MSG operations can be activated directly by the implementation of the MRP protocol. For example, the MRP implementation patched by the MSG would invoke MSG procedures with the correct class and target information instead of sending MRP messages through an ifc_i interface activated by MSG. In method 1) the programs and programming systems of the MSG are completely independent of MRP and as a result can be used by any MRP as long as the corresponding class table is known. This facilitates the reuse of programs and programming systems or programs and programming or software systems. In method 2) the MSG program is incorporated into the MRP implementation of the node activated by MSG. This can provide a more efficient implementation, for example to detect when the MSG operation should be activated.

When the Multiemmission Signaling Gateway (MSG) activates the distribution by the optimized route of multiemmission packets to a mobile network, this is also a very valuable method to solve other types of problems. The following are two examples of other possible applications of the MSG: • MSG for interconnection of fast multi-domain domains: The MSG can be deployed as a point of temporary interconnection between the fixed-line multi-emission domains, for example in the case of the failure of the interconnecting multi-emission structure. Therefore, MSG offers a temporary failure recovery solution since it is quick and easy to deploy for network administrators. • MSG for the IPv4 / IPv6 transition: The MSG offers a very convenient method for interconnecting IPv4 and IPvd multicast clouds so that IPv6 receivers can receive multicast traffic from IPv4 sources and vice versa. This is a very important use case considering that the IPv4 and IPvβ protocols were contemplated to coexist for a relatively long time, until the transition phase of totally IPv4 totally IPv6 is completed. For this purpose, the MSG must translate the multicast packets (together with the addresses of the uniemission source and multi-destination packet multicast destination addresses) from IPv4 to IPv6 and vice versa. Most of the previously known mechanisms for the IPv4 / IPv6 transition apply only to unicast traffic. A mechanism for multi-broadcast traffic [K. Tsuchiya et al, "An IPv4 / IPv6 Multicast Translator based on IGMP / MLD Proxying (mtp)", draft-tsichiya-mtp-01.txt, February 2003, work in progress] that presents an IPv4-IPv6 protocol translator and a Address tracer to send multicast packets between IPv4 and IPv6 domains (and vice versa). However, this proposal requires the translator to be manually preconfigured (by the network administrator) to send traffic for a given set of IPv4 multicast addresses (IPv6 respectively). During this installation process, the translator joins ALL those preconfigured groups so that they are able to receive related traffic. This mechanism is clearly not efficient since it requires human intervention every time a new multi-broadcast group has to be translated. The MSG (extended with an IPv4-IPv6 header translator and address plotter) solves this problem by dynamically activating the reception of IPv4 multicast traffic (IPv6 respectively) in the MSG only when necessary by the IPvd domain (IPv4 respectively). Note that the use of a mobile router activated by MSG allows an IPv6 Mobile Network (IPv4 respectively) to travel to a visited IPv4 network (TPv6 respectively) and receive multiemmission traffic from this visited network. It will be appreciated that the embodiments of the invention described above offer a number of advantageous features. For example: • means to activate the distribution of MNN multicast traffic along an optimal path regardless of the location of the mobile network on the Internet. • Route optimization for multiemission traffic transparently to MNNs: No change in MNNs required, so that non-mobile LFNs, even basic ones, can benefit from route optimization (for example, basic electronic devices in a car ). The optimization of the route is achieved by the only MR. • distribution of multiemmission traffic by the optimized route for nested mobile networks (that is, mobile networks visiting another mobile network), regardless of the aggregate level number of nested mobile networks. • mechanisms for the imperceptible mobility of mobile multi-broadcast s based on the remote subscription method applicable to the case of mobile networks. The above features are applicable without, however, the existing multicast routing protocols when they are placed on the mobile router to allow the distribution by an optimized route of the multicast packets. Additionally, the MSG is: • applicable to other scenarios such as IPv4 / IPv6 transistors. • very simple to implement. • does not require any changes to existing protocols or extensions on any other nodes in the network.

Claims (22)

1. NOVELTY OF THE INVENTION The invention written in the invention as above, is claimed as content property in the following: CLAIMS 1. The method for communicating traffic from a source to a group (G) of nodes including a Network Node (MNN) In a network using one or more multi-broadcast protocols, the network also comprises a router (MR) for sending traffic between the network and the Internet, characterized by a multi-signaling gateway (MSG) colocalized with the router (MR) and translates signaling messages of a multicast routing protocol (MRP) into messages of a group member protocol (GMP) on an interface.
2. 2. The method for communicating traffic from a source to a group (G) of nodes including Mobile Network Nodes (MNN) in a Mobile Network using one or more multi-broadcast protocols, the Mobile Network also comprises a Mobile Router (MR) for send traffic between the Mobile Network and the Internet, characterized by a gateway of Multicast Signaling (MSG) colocalized with the Mobile Router (MR) that translates signaling messages of a multicast routing protocol (MRP) into messages on an interface a protocol with members of a group (GMP).
3. 3. The method according to claim 2, characterized in that the interface is an egress interface of the Mobile Router (MR).
4. The method according to any one of the preceding claims, characterized in that the Multicam Signaling Gateway (MSG) operating the interface determines whether the signaling messages are related to the group entry class (. {INPUT.}. .) or the group output class (. {OUTPUT.}.) and translates the class into the members in a group (GMP) protocol.
5. 5. The method according to claim 4, characterized in that the determination of the class is made using a class table which provides the class as a function of the type of signaling message. H.H.
6. The method according to any of the preceding claims, characterized in that the Multiemmission Signaling Gate (MSG) operating at the interface determines whether the signaling messages contain identification of a target multispection Group (G) and translates the identification of the group of objective identification in the group member protocol (GMP).
7. The method according to claim 6, characterized in that the Multicast Signaling Gate (MSG) operating the interface determines whether the signaling messages contain an address of a source of the objective multi-transmit group (S) and translates the address of the target source in the group member protocol (GMP).
8. The method according to claim 7, characterized in that the Multistream Signaling Gateway (MSG) maintains a list of sources that includes, for each interface activated by MSG, the identification of the groups (G) associated with its addresses of source of the respective multicast group identified by the signaling messages.
9. The method according to claim 8, characterized in that the Multicast Signaling Gate (MSG) renews the subscription to the GMP by the group (G) in response to a change in the respective source list.
10. The method according to any of the preceding claims, characterized in that the Multicast Signaling Gate (MSG) renews the GMP subscription for the groups and lists of associated sources maintained by the interface in response to a change of connection source. topological interface.
11. 11. The method according to any of the preceding claims, characterized in that the multicast packets from an external source to the network to which the network is subscribed through the interface activated by MSG are routed by multicasting the interface activated with MSG within the network according to a local multicast sending table the router (MR).
12. 12. The method according to any of the preceding claims, characterized in that the Multiemmission Signaling Gateway (MSG) uses "service interface" as provided by the GMP protocols to generate the GMP messages and in this way activate and deactivate the reception of packets sent to specific IP multicast addresses. by specific sources.
13. The method according to claim 12, characterized in that the Multicast Signaling Gateway (MSG) adds sources for a given multicast group (G) and uses a single connection identifier (sid) to pass all the aggregation.
14. The method according to claim 12 or 13, characterized in that the Multicast Signaling Gate (MSG) uses different connection identifiers (sid__objective) for respective sources (S source, G multi-transmission group) derived from the signaling messages .
15. 15. The method according to any of the preceding claims, characterized in that the Multiemmission Signaling Gate (MSG) occupies messages of the Multicast Routing Protocol (MRP) verifying the packets sent on the interface activated by MSG.
16. The method according to any of the preceding claims, characterized in that the Multicast Signaling Gate (MSG) is included within an extension of an implementation of the Multicast Routing Protocol (MRP).
17. The method according to any one of the preceding claims, characterized in that the Multicast Signaling Gateway (MSG) translates the multicast packets together with the addresses of the uniemission sources and the multi-destination packet multicast destination addresses between the IPv4 and IPvß protocols.
18. 18. The method according to any of the preceding claims, characterized in that the Multicam Signaling Gateway (MSG) translates IPv4 MRP messages into IPv4 GMP messages (ie IGMP messages).
19. The method according to any of the preceding claims, characterized in that the Multicast Signaling Gateway (MSG) translates the IPv6 MRP messages into IPv6 GMP messages (ie MLD messages).
20. The method according to any one of the preceding claims, characterized in that the Multicast Signaling Gateway (MSG) translates the IPv4 MRP messages into IPvd messages and activates the IPv4 nodes to receive multicast packets from groups and multi-broadcast sources.
21. IPv6 The method according to any one of the preceding claims, characterized in that the Multicast Signaling Gate (MSG) translates MRP IPv6 messages into IPv4 GMP messages and activates IPvd nodes to receive multicast packets from IPv4 groups and multiemission sources.
22. 22. An apparatus for being used to perform a method according to any of the preceding claims and characterized in that the Multiemmission Signaling Gateway (MSG) colocalized with the router (MR) and that translates signaling messages from a multicast routing protocol. (MRP) in messages of a group member protocol (GMP).