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 use case is concentrated on deploying SDN on the send side of a production network. In later phases (Use Cases), we 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 the multicast use case for streaming video delivery network Phase 1. SDN will be incrementally phased into the DIRECTV video distribution network, as I suspect will be the case for many large production networks. We will briefly look at the phases of deployment further down in this document., since a forklift change is simply too risky and unrealistic.
Check the following resource that describes the Multicast Forwarding Architecture
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 consumermulticast streams are consumed. 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 respectively.
Incremental Deployment
This use case, we are assuming PIM-SSM for multicast as well as a legacy unicast routing protocol.
Project Members
| Name | Organization | Role | |
|---|---|---|---|
| Michael Makhijani | DIRECTV | Project Sponsor | |
| Sunil Jethwani | DIRECTV | Project Lead | |
| Rusty Eddy | DIRECTV | Technical Lead | geddy@directv.com |
| Veerendra Muppana | DIRECTV | Technical Team | vkmuppana@directv.com |
| Jono Hart | On.Lab | Technical Team |
Incremental Deployment
This use case assumes This 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.
...
Rolling out SDN in phases means that we'll be creating sections of SDN adjacent to legacy L3 sections. routing protocols. This will create sections of the network that can not communicate directly with one another, therefore we'll need to determine a way to consistently pass traffic through the SDN / L3 borders while supporting redundancy with primary and backup paths, while avoiding loops and duplicate traffic.
Phase 1 - Send Side Deployment
The first phase covered in this USE case will be looking at solutions to replacing the sending side of the network with SDN. The initial deployment may include a hybrid deployment meaning that the OpenFlow and Legacy L3 border will exist in a single switch.
...
In our use case we will work toward solution 3 for multicast, that is create a PIM-SSM emulation mode. Unicast routing will need to be solved in some other manner that we will need to determine.
PIM Emulator
Perhaps the most robust way to solve the Ships in the Night problem will require the ONOS controller to understand and speak PIM. This does not mean that we are going to implement all of PIM-SSM as a controller app, rather we provide the controller with just enough smarts to interpret PIM messages such that it may create sufficient forwarding state on our OF switch.
PIM-SSM Hello, Join / Prune
This specific use case requires us to emulate PIM-SSM. This will require ONOS to understand PIM Join / Prune messages to determine which ports PIM-SSM expects to receive data from.
In order for PIM-SSM to send a PIM Join/Prune to an OF switch, we will also need to periodically transmit and read PIM Hello messages that will allow the PIM Router to form a neighboring adjacency.
ISIS Unicast Routing
For unicast routing we don't have quite as clear of an option. Perhaps solutions 1, 2 or 4 above. We also have an option of Introducing iBGP or running a switch in hybrid mode reducing redundancy to a single path, or perhaps to create a series of redundant static routes to still afford redundancy.
Discovering Interest In Multicast Group Data
Early development of the Multicast Use Case we will need to be able to static configure multicast forwarding state. In addition to early multicast development we may find these static configured multicast state useful for this specific use case, but generally useful for many different multicast use cases. Hence this feature should provide to be generally useful.
...
Many of these are analogous to the unicast methods mentioned above.
Static Any Source Multicast (ASM) Forwarding Configuration
During early development of this phase we will require, at minimum the static configuration of group addresses and egress ports to indicate end receivers of the given multicast address. Conceptually speaking the configuration items will be something like:
...
We'll talk about reactive forwarding in a bit.
Static Source Specific Multicast (SSM) Forwarding Configuration
Similar to Static ASM configuration above, Static SSM forwarding configuration will also assign egress ports to multicast forwarding state. Additionally Static SSM configuration will also include a source address S1 and possibly an ingress port.
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.