projects / mirror_frr.git / blame
| Commit | Line | Data |
|---|---|---|
| 12e41d03 DL |
1 | WHY SSM |
| 2 | ||
| 3 | Benefis of PIM SSM over PIM SM | |
| 4 | ------------------------------ | |
| 5 | ||
| 6 | - SSM consumes minimum link bandwidth | |
| 7 | - SSM simplifies multicast address management (specially important for | |
| 8 | inter-domain multicast) | |
| 9 | - SSM (S,G) channels easily provide unique per-application addressing | |
| 10 | - SSM does not require MSDP between PIM domains | |
| 11 | - SSM does not suffer instabilities from traffic-driven SPT switchover | |
| 12 | - SSM is not suscetible to DoS attack from unwanted sources | |
| 13 | - SSM does not use RP. Some RP issues: | |
| 14 | - RP is possible point of failure | |
| 15 | - RP demands redundancy management | |
| 16 | - RP may require PIM dense mode support for RP election | |
| 17 | - RP is possible performance bottleneck | |
| 18 | - RP may demand lots of extra management | |
| 19 | - SSM can be deployed in an existing PIM SM network (only the last hop | |
| 20 | routers need to support IGMPv3) | |
| 21 | - SSM is easier to deploy and maintain | |
| 22 | ||
| 23 | PIM-SSM drawbacks | |
| 24 | ----------------- | |
| 25 | ||
| 26 | - SSM requires IGMPv3 support on both receivers and last-hop routers | |
| 27 | - SSM may be memory intensive when managing (S,G) states for | |
| 28 | many-to-many multicast distribution | |
| 29 | - SSM will keep (S,G) state as long as there are subscriptions from | |
| 30 | receivers, even if the source is not actually sending traffic | |
| 31 | ||
| 32 | --EOF-- |