Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
This is the multicast use case is concentrated on deploying SDN on the send side of a production network. Later phases (Use Cases) will concern ourselves with SDN on the receiving edge and later SDN in the core (i.e. a complete SDN network).
I suspect incremental deployment to phase in multicast across the larger network. I suspect will be the case for many large production networks we will work on deploying multicast on the sending edge of this network, since a forklift change is simply too risky and unrealistic.
The Network
The network topology can be viewed as a core network with two types of edges, the sending edge where video IP multicast streams are encoded into IP packets and injected into the network, the recieving receiving edge is where the video streams are decoded to be eventually delivered to the consumerconsumed. The core connects the sending and receiving edges. (This is somewhat over simplified an oversimplified view of a production network but should suffice for this use case).
The
network currently runs Legacy L3 multicast and unicast routing protocols PIM-SSM and IS-IS respectivelyThis use case, we are assuming PIM-SSM for multicast as well as a legacy unicast routing protocol.
Incremental Deployment
This use case assumes a high volume production network so it is only prudent that sections controlled by SDN are rolled out gradually in the early phases until we have sufficient confidence with the solution in our production environment.
...
Unlike Static ASM, Static SSM flows can be added proactively, as well as reactively. Since SSM tells us the source of the traffic, and possibly the group, it is possible to proactively add multicast flows to a switch before any data starts to flow.
Reactive Forwarding
SDN has enabled the concept of Reactive Forwarding in unicast networks, where the controller establishes the path between two hosts (or any device for that matter) after data has been sent from one device to another. Traditional unicast networks (built with legacy routing protocols such as OSPF or BGP) don't work that way, forwarding state to all reachable destinations is established proactively.
Multicast, on the other hand, has traditionally been "data driven", meaning that for the most part, not established in the router until after data arrives (it also will typically time out). This is largely because ASM was the main problem initially solved by the original protocols (mrouted, pim-sm & pim-dm).
Reactive Forwarding is Required for ASM
For Any Source Multicast (ASM) theoretically any source could start and stop sending at any given time. That being the case, it is not possible to proactively install the respective intents until after the sender starts sending. ASM, however is not part of this use case to this will is not a requirement we need to worry about at the moment. Another use case, this may be important.
Reactive Forwarding Means Less State
By reactively populating multicast state, you have the positive side effect that the forwarding tables in a switch only contain state for active (or recently actively) flows. In other words, the switch does not have to store 100% of all possible state if only 10% of that state is active at a given time.
Zero Configuration
I think it is worth considering a "zero configuration" setup. In a case that a network has a large number of multicast groups being generated from various "sending" edges. Reactive forwarding could potentially simplify configuration management.