SMART Multicast
 | The topic of this article may not meet Wikipedia's general notability guideline. (May 2014) |
SMART Multicast is an experimental method of secure reliable IP multicast. It allows a user to forward IP datagrams to an unlimited group of receivers. See the article on multicast for a general discussion of this subject - this article is specifically about SMART IP Multicast.
SMART Multicast uses
[edit]IP Multicast has been successfully deployed in private and controlled networking environments, for example; IP over fiber - cable TV operators, educational institutions with significant on-campus student housing and financial sector applications such as stock tickers and hoot-n-holler systems. However, IP multicast has been slow to be adopted in the interdomain routing environment. This is because the current interdomain infrastructure lacks the necessary tools to efficiently handle packet loss and the security needed to create a functional business model.
SMART IP Multicast is an experimental protocol that enables the interdomain transmission of Secure Reliable IP Multicast, thus overcoming the challenges of deploying wide area interdomain IP Multicast transmissions. SMART IP Multicast reduces the complexity of deploying wide area IP Multicast in the same way MFTP (Multicast File Transfer Protocol) accomplishes this goal for file transfer, namely allowing for security and reliability to have full interoperability.
IP Multicast file distribution has been the most successful use of IP Multicast within campus and commercial networks. For file distribution most have used some variant of the experimental protocol MFTP (Multicast File Transfer Protocol). MFTP is both secure and reliable and runs on top of IP Multicast protocol. Like MFTP, SMART Multicast is a wrapper that runs on top of IP Multicast, taking advantage of IP Multicast's efficiency. SMART Multicasts are secure, reliable and provide for bi-directional feedback.
For more info see RFC3170 - IP Multicast Applications: Challenges & Solutions
History and milestones
[edit]SMART supports an MBONE like implementation multicast between sites through the use of dynamically allocated Multicast tunnels. SMART takes advantage of SIMPLE (Self Implementing Multicast Protocol Level Escalation)
Key milestones
[edit]- Early 2000s: The initial development of multicast protocols focused on enhancing scalability and reducing redundancy in data transmission. Protocols like Protocol Independent Multicast (PIM) allowed multicast to scale better across large networks. This was particularly useful in video streaming and IPTV, where the demand for bandwidth-efficient content delivery was growing rapidly.[1]
- Mid-2000s: In the mid-2000s, research on multicast congestion control evolved significantly to address reliability issues and network congestion in various applications. A notable development was the emergence of fuzzy logic-based congestion control schemes, which introduced adaptive mechanisms to handle fluctuating network conditions. These schemes allowed multicast protocols to dynamically adjust data flow and prevent congestion in high-demand environments, such as video streaming and mobile ad hoc networks (MANETs). For instance, a survey by Matrawy and Lambadaris in 2003 highlighted the growing need for more advanced control mechanisms to support multicast video applications, focusing on the role of fuzzy logic and explicit rate adjustment techniques.[1]
- 2010s: The proliferation of IoT and cloud services further pushed the development of SMART Multicast systems. Adaptive multicast strategies were developed, allowing networks to dynamically adjust their behavior based on real-time data about congestion, bandwidth availability, and device requirements.[2]
- 2020s: SMART Multicast has become critical in emerging technologies like 5G, edge computing, and autonomous systems. Enhanced with AI and machine learning, modern SMART Multicast protocols are capable of self-configuring and optimizing the delivery of high-bandwidth data streams across complex networks.[3]
This evolution highlights how SMART Multicast continues to meet the growing demands for efficient and reliable data transmission in modern networks.
Experimental SMART protocol structure
[edit]Packet structure for SRM-P2MP
DATA PACKET Message TYP = 0x00 (binary 00)
ACCESS_SYNCH_CODE 8
PACKET_TYPE 2
CMD 2
RESERVED 4
PACKET SIZE 16
PACKET_NUMBER 16
PACKET FORMAT 2
DECRYPT_Y_N 1
QUIET 4
RESERVED 1
[...PAYLOAD]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence | FMT D QUIET R RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload [1] |
+- -+
| ........... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(6 bits 64 types)
MESSAGES Message TYP = 0x01 (binary 1)
ACCESS_SYNCH_CODE 8
PACKET_TYPE 2
CMD 6
PACKET_SIZE 16
[...PAYLOAD]
ADDR_RANGE CHANGE CMD = 01 (binary 000001)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address [1] |
+- -+
| Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
USAGE_REPORT_JOIN CMD = 0x0002 (binary 000010)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address [1] |
+- -+
| Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
USAGE_REPORT_LEAVE CMD = 0x0003 (binary 000011)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address [1] |
+- -+
| Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ERROR_REPORT CMD = 0x000B (binary 001011)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporting Address [1] |
+- -+
| Concerning Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Data [1] |
+- -+
| Message Data [2] |
+- -+
| Message Data [3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PROBLEM_REPORT CMD = 0x0010 Binary (010000)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporting Address [1] |
+- -+
| Concerning Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Data [1] |
+- -+
| Message Data [2] |
+- -+
| Message Data [3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MESSAGES Message TYP = 0x02 (binary 10) Replacement Requests
ACCESS_SYNCH_CODE 8
PACKET_TYPE 2
CMD 6
PACKET_SIZE 16
[...PAYLOAD]
REPLACEMENT CMD = 01 (binary 000001)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address [1] |
+- -+
| Sequence # | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
QUIET = 0x0002 (binary 000010)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address [1] |
+- -+
| Duration # | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MESSAGES Message TYP = 0x03 (binary 11) Tunneling Requests
ACCESS_SYNCH_CODE 8
PACKET_TYPE 2
CMD 6
PACKET_SIZE 16
[...PAYLOAD]
REQUEST_TUNNEL CMD = 01 (binary 000001)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address [1] |
+- -+
| Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LEAVE_TUNNEL = 0x0002 (binary 000010)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Synch | TYP CMD RESRV| Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address [1] |
+- -+
| Address [2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing
[edit]There are four forms of IP addressing, each with its own unique properties.
- Unicast: The most common concept of an IP address is a unicast address. It normally refers to a single sender or a single receiver.
- Broadcast: Sending data to all possible destinations. For example, to send to all addresses within a network with the prefix 192.0.2, the directed broadcast IP address is 192.0.2.255.
- Multicast: A multicast address is associated with a group of interested receivers. According to RFC 3171, addresses 224.0.0.0 to 239.255.255.255 are designated as multicast addresses. Routers take care of making copies of datagrams and sending them to all receivers that have registered their interest in receiving targeted data.
- Anycast: Like broadcast and multicast, anycast is a one-to-many routing topology. However, the data stream is not transmitted to all receivers, just the one which the router decides is the "closest" in the network. Anycast is useful for balancing data loads. It is used in DNS and UDP.
IP multicast protocols
[edit]- Internet Group Management Protocol (IGMP)
- Protocol Independent Multicast (PIM)
- Distance Vector Multicast Routing Protocol (DVMRP)
- Multicast BGP (MBGP)
- Multicast Source Discovery Protocol (MSDP)
- Multicast Listener Discovery (MLD)
- GARP Multicast Registration Protocol (GMRP)
- Multicast DNS (mDNS)
- SMART Multicast (SMART)
See also
[edit]- dense multicast
- sparse multicast
- source-specific multicast
- core-based trees
- Multicast address
- Multicast
References
[edit]- ^ Manjul, Manisha; Mishra, Rajesh; Singh, Karan; Son, Le Hoang; Abdel-Basset, Mohamed; Thong, Pham Huy (2020-07-01). "Single rate based extended logarithmic multicast congestion control". Journal of Ambient Intelligence and Humanized Computing. 11 (7): 2779–2791. doi:10.1007/s12652-019-01340-z. ISSN 1868-5145.
- ^ "Enable multicasting for individual cameras". doc.milestonesys.com. Retrieved 2024-08-18.
- ^ "Support Community". supportcommunity.milestonesys.com. Retrieved 2024-08-18.