QoS and Multicast Design for IPTV, VoIP, and Business VPN
A cable MSO delivers IPTV, VoIP, and business VPN over a 100G core and 10G access nodes. Each access node serves 4,000 subscribers; 300 SD/HD channels are available, and a subscriber watches up to four channels. HD is 8 Mbps and SD is 3 Mbps. The network currently treats all traffic as best effort, and during peak hours IPTV shows macroblocking while VoIP jitter exceeds 30 ms. Business VPN customers have a 10 ms latency and 1% loss SLA. Access nodes have 10G uplinks and 2G of dedicated IPTV headend capacity. The MSO wants a QoS and multicast design that protects both IPTV and business traffic without overbuilding the access uplinks. IGMP snooping is enabled, but PIM is not.
1. Calculate the multicast bandwidth needed per access node and decide whether to use PIM-SM or PIM-SSM. Show your reasoning.
Read the worked answer
Without multicast, 4,000 subscribers times four channels is 16,000 streams. At an average of 8 Mbps, that is 128 Gbps per access node, far beyond the 10G uplink. Multicast changes the calculation: the access node only needs the distinct channels that its subscribers have joined. The theoretical worst case is all 300 channels at 8 Mbps, or 2.4 Gbps, which already exceeds the 2G headend allocation. A realistic HD/SD mix will be lower, but the design must cap HD joins or add headend capacity.
Use PIM-SSM for IPTV. SSM uses explicit (S,G) joins with IGMPv3, removes the need for an RP, reduces join latency, and prevents unwanted sources from injecting into a channel. PIM-SM would require an RP, shared-tree switching, and more state and control traffic. With SSM, the access node replicates only the requested channels toward the subscriber segments, and IGMP snooping limits each segment to its actual viewers. Reserve headroom for channel-change bursts and measure the actual HD mix before finalizing the 2G headend limit.
2. Define the classification, marking, and MPLS EXP mapping and the queueing/scheduling model at the access node and core.
Read the worked answer
Classify at the access node, where the service is known. Mark VoIP as EF (DSCP 46), IPTV as AF41 (34), business VPN as AF31 (26) for transactional traffic and AF21 (18) for bulk, and best-effort Internet as 0. Police per subscriber so one user cannot exceed their purchased rate. Map to MPLS EXP at the access node: EF to EXP 5, AF41 to EXP 4, AF31 to EXP 3, AF21 to EXP 2, and best effort to EXP 0. Preserve the DSCP-to-EXP mapping across the core so the core can queue on EXP.
Use hierarchical QoS. The parent shaper enforces the access-node or subscriber aggregate rate. Child queues provide strict priority for VoIP with a policer, a bandwidth queue with WRED for IPTV, a bandwidth queue for business AF classes, and a default queue. Do not put video in strict priority; it can starve business traffic. On the core, use EXP-based queues and WRED. Reserve bandwidth for VoIP and business, and verify that IPTV bursts do not exceed the video queue. Monitor per-queue drops and latency, not just interface utilization.
3. How would you protect business VPN SLA during IPTV congestion? Address admission control and multicast replication.
Read the worked answer
Separate business VPN into its own queue or hierarchy with reserved bandwidth, and use admission control for both VoIP and IPTV. For VoIP, limit the number of admitted calls per access node based on the strict-priority budget; for IPTV, limit HD channel joins per access segment so the video queue and headend capacity remain within design limits. Business traffic should not share the IPTV queue, even if both are marked as AF.
Keep multicast replication at the access node and as close to viewers as possible. Use IGMP snooping and PIM-SSM so only requested channels traverse each segment. Do not flood IPTV into the business VPN VRF. If business VPN uses pseudowires, map the business class to the correct EXP and reserve bandwidth in the core. During congestion, the parent shaper should drop best-effort traffic before business or video. Test failover scenarios where an access uplink loses capacity; the design should shed IPTV or best effort first, not business traffic.