Method for efficient routing of multicast traffic

Abstract

A method of routing Internet Protocol Version 6, IPV6, multicast traffic in a utility metering system. The method includes creating a tunnel between each of a plurality of devices of a utility metering system on a first network and at least one device of the utility metering system on a second network to allow bidirectional communication therebetween, wherein each of the plurality of devices on the first network facilitates communication with at least one multicast group; generating and assigning a unique network prefix to each of the plurality of devices on the first network; prepending a multicast prefix to each unique network prefix to generate a unique device multicast prefix for each of the plurality of devices on the first network, the unique device multicast prefix including only the unique network prefix and the multicast prefix and not including a group ID identifying the at least one multicast group; populating a multicast routing table using the unique device multicast prefix of each of the plurality of devices on the first network to allow communication routing between each of the plurality of devices on the first network and the at least one device on the second network to be established; and using the multicast routing table to route multicast traffic from the at least one device on the second network to the relevant devices of the plurality of devices on the first network.

Description

Technical Field

[0001] This invention relates to a method for routing Internet Protocol version 6 (IPv6) multicast traffic in a utility metering system. Background Technology

[0002] IPv6 (Internet Protocol version 6) is the successor to IPv4 (Internet Protocol version 4) and provides unique digital IP addresses for devices communicating over the Internet. IPv4, as the original IP address standard, provides devices with unique 32-bit IP addresses, thus providing a unique IP address for each device. 32 It supports 4.29 billion IP addresses (approximately 4.29 billion in total). However, due to the widespread use of the Internet, the number of addresses available for allocation under the 32-bit address system is rapidly decreasing. IPv6 differs from IPv4 in that it uses a unique 128-bit IP address, thus providing 2... 128 One IP address. This should allow 128-bit IP addresses to be assigned to internet devices for a long time to come.

[0003] A 128-bit IPv6 address is represented using hexadecimal notation. The 128 bits are divided into eight 16-bit segments, each segment being converted into a 4-bit hexadecimal number separated by colons. For example:

[0004] 2001:0db8:0001:0000:0000:0000:0000:0001

[0005] IPv6 can use multicast to facilitate one-to-many communication. Multicast allows a single device to send the same communication to all devices within a multicast group using an IPv6 multicast address. Therefore, multicast is a useful communication tool that can be used in a range of systems, such as utility metering systems, to allow efficient communication with hundreds or even thousands of devices within the system (e.g., with metering devices within the metering system).

[0006] However, routing multicast traffic can be expensive and increases system memory and processing requirements because each multicast address needs to be tracked by the operating system, and large systems may include thousands or more multicast addresses. For example, using the multicast address format defined in RFC-3306 (IPv6 multicast addresses based on unicast prefixes) provides the ability to use up to 4,294,967,295 possible multicast addresses.

[0007] A more efficient method for routing multicast traffic is needed. Summary of the Invention

[0008] According to a first aspect of the invention, a method is provided for routing Internet Protocol version 6, IPv6, multicast traffic in a utility metering system, the method comprising: creating a tunnel between each of a plurality of devices in the utility metering system on a first network and at least one device in the utility metering system on a second network to allow bidirectional communication between them, wherein each of the plurality of devices on the first network facilitates communication with at least one multicast group; generating a unique network prefix and assigning it to each of the plurality of devices on the first network; prepending the multicast prefix to each unique network prefix to generate a unique device multicast prefix for each of the plurality of devices on the first network, the unique device multicast prefix including only the unique network prefix and the multicast prefix, excluding a group ID identifying the at least one multicast group; populating a multicast routing table with the unique device multicast prefix of each of the plurality of devices on the first network to allow establishing communication routes between each of the plurality of devices on the first network and the at least one device on the second network; and using the multicast routing table to route multicast traffic from the at least one device on the second network to the associated device among the plurality of devices on the first network.

[0009] Optionally, the only device multicast prefix in the multicast routing table is the / 96 prefix.

[0010] Optionally, each unique network prefix includes a / 64 prefix.

[0011] Optionally, each multicast prefix includes a / 32 prefix.

[0012] Optionally, each unique network prefix may consist of 64 bits or less in length.

[0013] Optionally, the second network is a subnet of the first network.

[0014] Alternatively, the multicast routing table may include only a single entry for each of the multiple devices on the first network, regardless of how many multicast groups the corresponding device on the first network facilitates communication with.

[0015] Optionally, each of the plurality of devices on the first network includes a border router configured to communicate with a plurality of utility metering devices, and at least one device on the second network includes a tunnel management server configured to facilitate the creation of tunnels.

[0016] Optionally, the utility metering system also includes a headend system configured to communicate with the multiple border routers via a tunnel management server using a unique device multicast prefix for each of the multiple border routers.

[0017] Optionally, the method further includes assigning a network prefix to the tunnel management server, wherein the unique network prefix of each border router is a / 64 prefix, and the / 64 prefix is ​​a subnet of the network prefix of the tunnel management server. Attached Figure Description

[0018] Figure 1 An exemplary utility metering system is shown;

[0019] Figure 2 A schematic diagram of the format of an IPv6 multicast address is shown;

[0020] Figure 3 A schematic diagram of the format of an IPv6 multicast address is shown;

[0021] Figure 4 An exemplary utility metering system is shown;

[0022] Figure 5 A flowchart illustrating an exemplary method for routing multicast traffic in an IPv6 system; and

[0023] Figure 6 An exemplary utility metering system is shown. Detailed Implementation

[0024] This document generally discloses a method for efficiently routing multicast traffic in a utility metering system. Multicast includes a method in which data is sent from a source device to multiple devices within a specified multicast group. A multicast group can be defined as including multiple devices identified by a single multicast address. Therefore, when data is sent from the source device to a single multicast address, it is delivered to all devices that are members of the multicast group.

[0025] like Figure 1 As schematically illustrated, utility metering system 100 typically includes a headend system 102, which acts as a central processing system and communicates with multiple metering devices 108a-n, 110a-n, and 112a-n via border routers 106a-c (also referred to as collectors or root nodes). The multiple utility metering devices may include electricity, gas, or water utility meters configured to measure consumption for their respective utilities. The multiple utility metering devices are connected via a wireless mesh network. Border routers 106a-c can facilitate communication of data from the wireless mesh network to the headend system 102 via one or more networks (or via cellular or powerline communication).

[0026] like Figure 1 As shown, a typical utility metering system 100 includes multiple border routers 106a-c, each border router 106a-c communicating with a headend system 102 and each border router 106a-c communicating with multiple metering devices. Figure 1 In the illustrated arrangement, border router 106a communicates with metering devices 108a-n, border router 106b communicates with metering devices 110a-n, and border router 106c communicates with metering devices 112a-n. Border routers 106a-c may include a Personal Area Network (PAN) coordinator, a gateway, or any other device capable of routing communication from headend system 102 to multiple metering devices 108a-n, 110a-n, and 112a-n (or vice versa).

[0027] In the context of a utility metering system, multicast can be used to allow effective communication, for example, between headend system 102 and a plurality of associated metering devices 108a-n, 110a-n and / or 112a-n.

[0028] For example, in utility metering system 100, each utility metering device connected to a given border router 106a, 106b, or 106c can be a member of one or more multicast groups. For instance, a first multicast group can be defined that includes a first group of utility metering devices (e.g., electricity metering devices) connected to border router 106a, and a second multicast group can be defined that includes a second group of utility metering devices (e.g., gas metering devices) connected to border router 106a, and so on. In this way, communication from the headend system can be routed to the relevant utility metering device using the relevant multicast address defining the relevant multicast group.

[0029] However, as the number of multicast groups increases, the number of multicast addresses that need to be tracked also increases. This increases the cost and complexity of the system.

[0030] The invention disclosed herein reduces the number of multicast addresses that need to be tracked while still allowing multicast communication, and thus provides the associated advantages.

[0031] To aid in understanding this invention, first refer to Figure 2 This describes the format of Internet Protocol version 6 (IPv6) multicast addresses, specifically IPv6 multicast addresses based on unicast prefixes. The format of IPv6 multicast addresses based on unicast prefixes is defined in RFC-3306. IPv6 multicast addresses based on unicast prefixes are a specific type of multicast address where the unicast prefix (typically a 64-bit network prefix) is embedded within the multicast address itself. This allows the creation of multicast groups bound to a specific set of network addresses / prefixes assigned to devices within a system.

[0032] The first 8 bits of an IPv6 multicast address are always "11111111", represented as "FF" in hexadecimal, and... Figure 2 It is shown as field 202.

[0033] The next 4 bits are flags, in Figure 2 This is schematically shown as field 204. The next 4 bits after the flag represent the scope. Figure 2 This is schematically shown as field 206. The scope field identifies the application scope of the multicast group, as follows.

[0034]

[0035] The next 8 bits are reserved and have a default value of "0", such as Figure 2 The "Reserved" field 208 is specified in the document.

[0036] The next 8 bits represent the plen or prefix length field, such as Figure 2 As shown in field 210. This field 210 indicates the effective length of the embedded unicast prefix or network prefix.

[0037] The next 64 bits represent the embedded unicast prefix or network prefix, such as Figure 2 As shown in field 212.

[0038] The last 32 bits represent the group ID and are used to distinguish different multicast groups sharing the same network prefix. This is in Figure 2 It is specified as field 214.

[0039] Therefore, a 128-bit IPv6 multicast address can be defined. Figure 3 An example 128-bit IPv6 multicast address is shown, with hexadecimal numbers mapped to the fields 202-214 above to aid understanding.

[0040] Now for reference Figures 1 to 5 This describes a method for routing IPv6 multicast traffic in a utility metering system.

[0041] 502: such as Figure 1 As shown, each border router 106a-c communicates with the tunnel manager or tunnel management server 104. Figure 1 In the exemplary arrangement shown, each border router 106a-c communicates with the same tunnel manager 104. However, those skilled in the art will understand that in an alternative arrangement, one or more of the border routers 106a-c may communicate with different tunnel managers, as will be described in more detail below.

[0042] For the purposes of this example, the method is described in relation to a single border router 106a, as follows: Figure 4 As shown. However, those skilled in the art will understand that, where applicable, similar approaches can facilitate the routing of multicast traffic to different border routers, such as... Figure 1 106b and 106c are shown in the diagram.

[0043] When the border router 106a starts up, it initiates a tunnel creation sequence to establish a tunnel between the tunnel manager 104 and the border router 106a to allow bidirectional communication between them.

[0044] The tunnel created between the border router 106a and the tunnel manager 104 can be configured to support multicast traffic, for example, by enabling the relevant multicast routing protocol. The methods used to configure the tunnel to support multicast traffic are familiar to those skilled in the art.

[0045] 504: Generate a unique network prefix and assign it to border router 106a. The unique network prefix generated and assigned to border router 106a may include a 64-bit prefix, represented as / 64. Those skilled in the art will understand that in alternative arrangements, different numbers of bits can be used for the network prefix; for example, a network prefix of 64 bits or fewer bits may be used. However, according to RFC-3306, the network prefix assigned to border router 106a will typically not exceed 64 bits.

[0046] A unique / 64 prefix can be generated as a subnet for the network prefix assigned to tunnel manager 104. For example, as Figure 4 As shown, tunnel manager 104 is assigned the / 48 prefix 2001:DB8:1:: / 48. The / 48 prefix means that the first 48 bits of the 128-bit IPv6 address are designated for the network prefix, in this case, the network prefix of tunnel manager 104. The remaining bits of the 128-bit IPv6 address can be used for subnets and host addresses. Typically, subnets are allocated a / 64 size, and therefore a very large number of / 64 subnets can be created within its allocated / 48 prefix. Those skilled in the art will understand that in alternative arrangements, tunnel manager 104 can include network prefixes of varying lengths. In other words, the length of the tunnel manager network prefix does not need to be 48 bits, and in other examples it can be less than or greater than 48 bits, and this can be configured by the user according to system requirements.

[0047] exist Figure 4 In the example shown, border router 106a is assigned the / 64 network prefix:

[0048] 2001:DB8:1: 1:: / 64.

[0049] It will be apparent to those skilled in the art that the portion of the / 64 network prefix of the border router 106a, indicated in bold and underline, corresponds to the / 48 prefix of the tunnel manager 104, identifying the border router 106a as a subnet of the tunnel manager 104, while the remaining 16 bits of the 64-bit network prefix of the border router 106a uniquely identify the border router 106a.

[0050] Technicians will also understand that, Figure 4 In the example shown, the / 48 network prefix of tunnel manager 104 is a subnet of the network prefix of headend system 102.

[0051] 506: Use the / 64 network prefix assigned to the border router 106a to create the border router multicast prefix. The border router multicast prefix is ​​different from the multicast address outlined in RFC 3306 (i.e., IPv6 multicast address based on unicast prefix).

[0052] Creating a border router multicast prefix involves prepending the / 64 network prefix of the border router 106a to form a / 96 border router multicast prefix. As used herein, the term "multicast prefix" refers to the first 32 bits of the multicast address immediately preceding the / 64 network prefix. References Figure 2 The multicast prefix includes fields 202-210, which include FF specification 202, flag 204, scope 206, reserved field 208, and plen field 210. For example, the multicast prefix could be FF38:40::, which creates a border router multicast prefix when prepended to the / 64 network prefix of border router 106a.

[0053] FF38:40:2001:DB8:1:1:: / 96.

[0054] As used herein, the term “device multicast prefix” or “border router multicast prefix” refers to the / 96 prefix assigned to a device, which includes the network prefix and the multicast prefix prepended to it.

[0055] As mentioned above, the multicast prefix for border routers differs from the multicast address defined in RFC-3306. It uses the multicast address outlined in RFC-3306 (and... Figure 2 and Figure 3 The multicast address format (shown in the diagram) identifies the group ID of the multicast group served by the border router 106a, which will be appended to the multicast prefix and network prefix of the border router 106a, such as... Figure 2 As shown in field 214, this is used to form a 128-bit multicast address. For example, in the case where border router 106a serves three multicast groups, three multicast addresses can be created, such as:

[0056] FF38:40:2001:DB8:1:1::1;

[0057] FF38:40:2001:DB8:1:1::2;

[0058] FF38:40:2001:DB8:1:1::3.

[0059] Conversely, the border router multicast prefix omits the group ID field. Therefore, a single border router multicast prefix for border router 106a can be used to route traffic from headend system 102 to border router 106a, regardless of how many multicast groups border router 106a facilitates communication with.

[0060] 508: The multicast routing table is then populated with the / 96 border router multicast prefix. Border router 106a uses the multicast routing table to manage and route received data (e.g., data received from tunnel manager 104). The multicast routing table includes data entries that can be used by devices such as tunnel manager 104 and border router 106a to determine the best path for forwarding multicast data from the source to the multicast group and across the IPv6 network.

[0061] Typically, in known multicast systems, each data entry in the multicast routing table includes a source address (indicating where the multicast data originates) and a destination group address in the form of a multicast address, such as... Figure 2 and Figure 3 As shown, this includes the multicast prefix, network prefix, and group ID, which is a 128-bit multicast address. This means that in the presence of three multicast groups served by border router 106a, there are three entries in the multicast routing table. Those skilled in the art will understand that exemplary data entries in the multicast routing table may include other information, such as a list of interfaces, etc.

[0062] Utility metering systems can include hundreds or thousands of border routers, each serving multiple multicast groups. This means that multicast routing tables are needed to manage a large number of multicast addresses; that is, if there are one thousand border routers and each border router serves three multicast groups, then multicast routing tables are needed to manage three thousand multicast addresses. This increases memory and processing requirements and can lead to scalability challenges, as the amount of information to maintain in the multicast routing tables can grow rapidly as more border routers are implemented and / or as more multicast groups are defined.

[0063] The inventors have recognized that these problems can be improved by routing data from headend system 102 to a given border router (e.g., border router 106a) via tunnel manager 104 using a / 96 border router multicast prefix within the multicast routing table instead of the 128-bit multicast address corresponding to each multicast group. In other words, the 32-bit group ID field is omitted, and the multicast routing table includes a / 96 device multicast prefix for each border router (in this example, a border router multicast prefix). As mentioned above, the border router multicast prefix includes both a multicast prefix and a network prefix, but does not include the 32-bit group ID field.

[0064] Continuing the example above, where border router 106a serves three multicast groups with addresses FF38:40:2001:DB8:1:1::1, FF38:40:2001:DB8:1:1::2, and FF38:40:2001:DB8:1:1::3, instead of having three entries in border router 106a's multicast routing table, there is only a single / 96 border router prefix, which in this case would be FF38:40:2001:DB8:1:1:: / 96. The / 96 border router multicast prefix covers all group IDs served by the corresponding border router because the first 96 bits of the multicast address for each group served by the border router are identical. Therefore, if there are one thousand border routers in a utility metering system, the multicast routing table only needs to manage one entry for each border router, regardless of how many multicast groups each border router serves.

[0065] 510: Multicast data is routed from headend system 102 to the associated border router via tunnel manager 104, which facilitates communication with utility metering devices within a given multicast group. Data is routed using a multicast routing table that includes a / 96 border router multicast prefix. Using the / 96 multicast prefix in the multicast routing table represents a departure from standards known in the art, which specify filling multicast routing tables with 128 bits of multicast group address.

[0066] For example, any data destined for a multicast group served by border router 106a is routed from headend system 102 to tunnel manager 104, and then to border router 106a by means of the / 96 border router multicast prefix (because all multicast addresses of the multicast group served by border router 106a will start with the same 96 bits as defined in the first / 96 border router multicast prefix).

[0067] Then, the border router can use a different communication standard to forward the traffic to the relevant multicast group.

[0068] As described above, an exemplary utility metering system may include multiple tunnel managers, each communicating with one or more border routers. The following describes a method for routing multicast traffic in a system including multiple tunnel managers; however, those skilled in the art will understand that following the principles outlined above will be beneficial. Figure 5 The methods outlined in the text are similar to those described above.

[0069] Figure 6 An exemplary utility metering system is shown, comprising two tunnel managers 104a, 104b communicating with a headend system 102; however, those skilled in the art will understand that alternative systems may include a different number of tunnel managers, sometimes thousands.

[0070] Tunnel manager 104a has a / 48 prefix of 2001:DB8:1:: / 48, and tunnel manager 104b has a / 48 prefix of 2001:DB8:2:: / 48. These prefixes are examples for illustrative purposes only and, as mentioned above, can be of a different length than 48 bits ( / 48) in alternative arrangements. As part of the tunnel creation sequence, a / 64 network prefix is ​​created for border routers 106a, 106b, and 106c. Similarly, those skilled in the art will understand that each tunnel manager 104a, 104b can communicate with a large number of border routers, and Figure 6 The arrangement shown is merely an example.

[0071] Corresponding tunnels are created between border router 106a and tunnel manager 104a, between border router 106b and tunnel manager 104a, and between border router 106c and tunnel manager 104b. Thus, the / 64 network prefix assigned to border routers 106a and 106b is a subnet of the / 48 prefix of tunnel manager 104a, and the / 64 network prefix assigned to border router 106c is a subnet of the / 48 prefix of tunnel manager 104b. Those skilled in the art will also understand that... Figure 6 In the example shown, the / 48 network prefix of tunnel manager 104a is the first subnet of the network prefix of headend system 102, and the / 48 network prefix of tunnel manager 104b is the second subnet of the network prefix of headend system 102.

[0072] Then, a / 96 border router multicast prefix can be created for each border router in the utility metering system, similar to the above. Figure 5The following describes the process: In this scenario, a first / 96 border router multicast prefix is ​​created for border router 106a, a second / 96 border router multicast prefix is ​​created for border router 106b, and a third / 96 border router multicast prefix is ​​created for border router 106c. As described above, the / 96 border router multicast prefix is ​​created by prepending the multicast prefix to each / 64 network prefix of border routers 106a-c.

[0073] For example:

[0074] First / 96 border router multicast prefix: FF38:40:2001:DB8:1:1:: / 96

[0075] Second / 96 border router multicast prefix: FF38:40:2001:DB8:1:2:: / 96

[0076] Third / 96 border router multicast prefix: FF38:40:2001:DB8:2:1:: / 96

[0077] Thus, any data destined for the multicast group served by border router 106a is routed from headend system 102 to tunnel manager 104a, and then to border router 106a via the first / 96 border router multicast prefix (because all multicast addresses of the multicast group served by border router 106a will begin with the same 96 bits defined in the first / 96 border router multicast prefix). Similarly, any data destined for the multicast group served by border router 106b is routed from headend system 102 to tunnel manager 104a, and then to border router 106b via the second / 96 border router multicast prefix (because all multicast addresses of the multicast group served by border router 106b will begin with the same 96 bits defined in the second / 96 border router multicast prefix). Any data destined for the multicast group served by border router 106c is routed from headend system 102 to tunnel manager 104b, and then to border router 106c by means of the third / 96 border router multicast prefix (because all multicast addresses of the multicast group served by border router 106c will start with the same 96 bits as defined in the third / 96 border router multicast prefix).

[0078] Multicast traffic from headend system 102 can be directed to the relevant border routers 106a-c to be distributed to multicast groups using a multicast routing table containing one entry for each border router, with each entry including a / 96 border router multicast prefix.

[0079] Those skilled in the art will understand that the above method allows IPv6 multicast traffic to be routed efficiently while reducing the need for memory and processing compared to known methods, even when additional multicast groups are defined or when additional border routers are added to the system.

[0080] Those skilled in the art will understand that various modifications can be made to the above embodiments without departing from the scope of the invention. The word "exemplary" is used herein to mean "example." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0081] A computer program can be configured to provide any of the methods described above. The computer program can be provided on a computer-readable medium. The computer program can be a computer program product. This product may include a non-transitory computer-usable storage medium. The computer program product may have computer-readable program code embodied in the medium and configured to perform the method. The computer program product can be configured to cause at least one processor to perform some or all of the method.

[0082] This document describes various methods and apparatuses with reference to block diagrams or flowcharts illustrating computer-implemented methods, apparatuses (systems and / or devices) and / or computer program products. It should be understood that the blocks of block diagrams and / or flowcharts, and combinations of blocks in block diagrams and / or flowcharts, can be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions can be provided to processor circuits of general-purpose computer circuits, special-purpose computer circuits, and / or other programmable data processing circuits to produce a machine, such that instructions executed by the processor of a computer and / or other programmable data processing apparatus transform and control transistors, values ​​stored in memory locations, and other hardware components within such circuits to implement the functions / actions specified in the block diagrams and / or flowcharts, thereby creating components (functions) and / or structures for implementing the functions / actions specified in the block diagrams and / or flowcharts.

[0083] Computer program instructions may also be stored in a computer-readable medium that can instruct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of writing including instructions that implement the functions / actions specified in the block diagrams and / or flowcharts.

[0084] Tangible, non-transitory computer-readable media can include electronic, magnetic, optical, electromagnetic, or semiconductor data storage systems, apparatuses, or devices. More specific examples of computer-readable media will include the following: portable computer disks, random access memory (RAM) circuitry, read-only memory (ROM) circuitry, erasable programmable read-only memory (EPROM or flash memory) circuitry, portable optical disc read-only memory (CD-ROM), and portable digital video disc read-only memory (DVD / Blu-ray).

[0085] Computer program instructions may also be loaded onto a computer and / or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and / or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions / actions specified in the block diagram and / or flowchart boxes.

[0086] Therefore, the present invention can be embodied in hardware and / or software running on a processor (including firmware, resident software, microcode, etc.), which can be collectively referred to as "circuit", "module" or variations thereof.

[0087] It should also be noted that in some alternative implementations, the functions / actions marked in the boxes may not occur in the order indicated in the flowchart. For example, depending on the functions / actions involved, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order. Furthermore, the function of a given block in a flowchart and / or block diagram may be divided into multiple blocks, and / or the functions of two or more boxes in a flowchart and / or block diagram may be at least partially integrated. Finally, additional boxes may be added / inserted between the boxes shown.

Claims

1. A method for routing Internet Protocol version 6, IPv6, multicast traffic in a utility metering system, the method comprising: A tunnel is created between each of the plurality of devices in the utility metering system on the first network and at least one device in the utility metering system on the second network to allow bidirectional communication between them, wherein each of the plurality of devices on the first network facilitates communication with at least one multicast group. Generate a unique network prefix and assign it to each of the plurality of devices on the first network; A multicast prefix is ​​placed before each unique network prefix to generate a unique device multicast prefix for each of the plurality of devices on the first network, the unique device multicast prefix including only the unique network prefix and the multicast prefix, but excluding the group ID that identifies the at least one multicast group; The multicast routing table is populated with the unique device multicast prefix of each of the plurality of devices on the first network to allow the establishment of communication routes between each of the plurality of devices on the first network and the at least one device on the second network. as well as The multicast routing table is used to route multicast traffic from at least one device on the second network to the relevant device among the plurality of devices on the first network.

2. The method according to claim 1, wherein, The only device multicast prefix in the multicast routing table is the / 96 prefix.

3. The method according to claim 1 or claim 2, wherein, Each unique network prefix includes the / 64 prefix.

4. The method according to claim 3, wherein, Each multicast prefix includes the / 32 prefix.

5. The method according to claim 1 or claim 2, wherein, Each unique network prefix consists of 64 bits or less in length.

6. The method according to any of the preceding claims, wherein, The second network is a subnet of the first network.

7. The method according to any of the preceding claims, wherein, The multicast routing table includes only a single entry for each of the plurality of devices on the first network, regardless of how many multicast groups the corresponding device on the first network facilitates communication with.

8. The method according to any of the preceding claims, wherein, Each of the plurality of devices on the first network includes a border router configured to communicate with a plurality of utility metering devices, and wherein at least one device on the second network includes a tunnel management server configured to facilitate the creation of the tunnel.

9. The method according to claim 8, wherein, The utility metering system also includes a headend system configured to communicate with the multiple border routers via the tunnel management server using a unique device multicast prefix for each of the multiple border routers.

10. The method of claim 8 or claim 9, comprising assigning a network prefix to the tunnel management server, wherein the unique network prefix of each of the border routers is a / 64 prefix, the / 64 prefix being a subnet of the network prefix of the tunnel management server.

Images