Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing

Introduction Multicast is an efficient data transmission method for distributing data to multiple receivers simultaneously. The Internet Protocol (IP) multicast service model is defined in RFC 1112 . RFC 5110 describes an overview of multicast routing architectures. However, these traditional multicast frameworks suffer from several challenges, particularly with global address management and excessive traffic due to group membership updates. In large-scale networks, this can lead to inefficiencies in routing and bandwidth consumption. In real-time spatial sensing and control applications, efficient data transmission and processing are crucial for achieving low latency and high accuracy. This document introduces a new approach where multicast groups are content-based, and defined locally by routers. It eliminates the need for global multicast address management. Additionally, the concept of a "topic" is introduced to manage data delivery based on the content, offering further flexibility and scalability for multicast applications.

Terminology Global Multicast Group: A set of hosts interested in receiving data from the same source. Content-based Multicast Group: A multicast group of directly connected hosts that is content-based and defined and managed by a local router. Topic: A label representing the content of the data being multicast. A topic may correspond to specific data types. Membership Request: A message sent by a host to its nearest router to either join or leave a multicast group. RP: Rendezvous point

Multicast Framework

Conventional method This section describes the conventional method. When a host wants to receive a transmission through multicast group with a certain group address, it indicates its interest to its first-hop router. The router next initiates hop-by-hop forwarding state. The entire distribution for each group is managed by a RP and the transmissions may be optimized later.

Content-based Multicast The introduction of the "topic" concept allows routers to manage multicast streams based on the content or purpose of the data, rather than by the group of hosts interested in receiving the data. Each topic is associated with a content-based multicast group, and multiple hosts can subscribe to the same topic. A router forwards multicast data based on the active topics, and each router in the delivery chain is aware of which topics are active within its local network. Hosts can subscribe to multiple topics, and routers dynamically manage group membership per topic.

Content-based Multicast Grouping In the framework, each router is responsible for managing multicast groups for hosts directly connected to it. Unlike traditional multicast, where routers must track global group memberships, routers in this framework only maintain the status of their next-hop hosts. Group addresses can be reused across different local networks, reducing the complexity of address management. When a host wishes to join a multicast group (associated with a topic), it sends a membership request to its next-hop router. The router finds the requested content-based multicast group. If the group exists, that is, if it is already receiving the desired the topic data, it adds the host to the content-based multicast group and begins forwarding the data to the host via multicast. Otherwise, the router creates its own new content-based multicast group for the topic, sequentially sends a membership request to its upstream router, and then begins forwarding the data to the new host. Similarly, when a host wishes to leave a multicast group, it sends a leave request to its next-hop router. The router removes the host from the content-based multicast group. If no other hosts connected directly to the router are subscribed to the same topic, the router removes the group, stops forwarding the data stream, and sends a leave request to its upstream router. The upstream router then checks its own content-based multicast group for the topic. If there are no more local subscribers, it will cease forwarding the data stream for that topic as well. This process ensures that multicast traffic is only delivered when there are active subscribers, preventing unnecessary bandwidth consumption.

Example Use Case This section describes an example use case based on the network topology shown in .

The network consists of three routers (R1, R2, and R3), two visual sensors (VS1 and VS2), an edge computer (EC1), and two users (U1 and U2). Visual sensors, such as light detection and ranging (LiDAR) or cameras, provide real-space data for generating a digital twin on EC1. The users utilize the digital twin in real time for various applications, autonomous driving for example. The devices are connected across several subnets: VS1, VS2, and R1 are linked via the 192.168.0.0/24 subnet; R1, R2, and R3 are linked via the 192.168.1.0/24 subnet; EC1 and R2 are linked via the 192.168.2.0/24 subnet; and R3, U1, and U2 are linked via the 192.168.3.0/24 subnet. EC1 is assumed to receive information from visual sensors to create the digital twin. VS1 sends its acquired data to a multicast group with the address 224.0.0.1 in the 192.168.0.0/24 subnet, to which R1 belongs. R1 forwards the data to a multicast group with the address 224.0.0.2 in the 192.168.1.0/24 subnet, to which R2 belongs. Subsequently, R2 forwards the data to a multicast group with the address 224.0.0.3 in the 192.168.2.0/24 subnet, allowing EC1 to receive the data. It is also assumed that EC1 distributes the digital twin data to U1. EC1 sends the digital-twin data to a multicast group with the address 224.0.0.4 in the 192.168.2.0/24 subnet, to which R2 belongs. R2 forwards the data to a multicast group with the address 224.0.0.5 in the 192.168.1.0/24 subnet, to which R3 belongs. Finally, R3 forwards the data to the multicast group with the address 224.0.0.6 in the 192.168.3.0/24 subnet, allowing U1 to receive them. If U2 wishes to access the digital twin data, it notifies its first-hop router, R3. U2 joins to the multicast group with the address 224.0.0.6 and R3 can receive the data. If U2 wishes to access visual-sensor data from VS1, it notifies its first-hop router, R3. As R3 does not have the data to forward, it propagates this notification to downstream routers. Then R3 joins to the multicast group with the address 224.0.0.2 and R3 can receive the data. R3 establishes a new multicast group with the address 224.0.0.7 in the 192.168.3.0/24 subnet. Finally, U2 joins to the group and can receive the data.

IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.

Security Considerations Security in the multicast framework must be addressed to prevent unauthorized access to multicast streams. Routers should implement access control mechanisms to verify whether a host is authorized to join a specific topic. Encryption of multicast traffic should also be considered to prevent eavesdropping on sensitive data.

Conclusion The content-based multicast framework provides a flexible and efficient solution for multicast communication in large-scale networks. By managing multicast group membership locally and introducing the topic-based data delivery model, the framework reduces bandwidth consumption, simplifies routing, and enhances the scalability of multicast services.

Acknowledgements This work is supported in part by the National Institute of Information and Communications Technology, Japan (JPJ012368C06401).