Technology

Routing or Bridging: Optimized for Video

Legacy DLC or NGDLC devices can provide voice and broadband data, but they are not suitable for video distribution. In order to offer video services, the carrier must either provide multicast IP video over DSL with the existing copper network or deploy a PON and then provide multicast IP video and/or RF video over it. The MALC caters to these various scenarios by simultaneously supporting RF video over PON along with high-performance multicast IP video over copper or fiber.

To provide RF video over PON, MALC OLT line cards provide support for full analog and digital video in a RF frequency range from 40 MHz up to 860 MHz for up to 32 subscribers. In conjunction with video head end equipment, the MALC PON solution can also support VoD, PPV, and advanced services including HDTV.

To provide IP video over DSL or PON, the MALC supports multicast IP forwarding. But while multicast forwarding and high bandwidth capacity are necessary for any video deployment, they are not sufficient to guarantee a quality video experience for the subscriber. The MALC therefore supports several additional critical capabilities (described below) to ensure a quality real-time experience for the subscriber.

In particular, it should be noted that the MALC uses distributed multicasting to provide multicast video services. To deliver video, the MALC backplane architecture requires the uplink cards to put each multicast stream onto the backplane just once. Each multicast video stream is then replicated on the appropriate line card when the subscriber connected to that line card requests that program. This distributed replication allows the total system performance to be scaled up easily, increasing in a linear fashion with each card added. Distribution of multicasting capabilities to every card also reduces the load on any single point in the system.

In contrast to the MALC's distributed multicasting implementation, other architectures require packet replications to occur on a single chip for all subscribers (in the worst case) or for all cards (in the best case). In both cases, the capabilities of the chips soon become exhausted as the number of video streams increases.

The MALC performs video replication, multicasting and all IGMP functions such as the IGMP Proxy and IGMP Snooping in the processor, which is located on the uplink card.

IGMP Proxy and Snooping - IP Multicast

In the simplest example of IP multicast, the MALC or Raptor operate as a bridge and performs what is referred to as IGMP snooping in which it monitors IGMP messages across a bridged interface. While an IGMP snooping bridge performs well in normal conditions, it cannot directly control or query the state of the subscriber. During peak usage and congestion periods, this approach may not produce an adequate quality of service.

Instead of operating as a simple bridge, the MALC or Raptor can be operated as a multicast-capable router and implement IGMP Proxy. As an IGMP Proxy Agent, the MALC or Raptor can actively manage and control the specific channels being delivered to each and every subscriber.

To ensure a quality video experience, the MALC also implements additional security and bandwidth controls. Channel limitations ensure the total number of concurrent channels delivered to a subscriber doesn't exceed the total number active set tops.

Active Queries within the IGMP protocol to ensure that a user-selected channel-change request is never lost within the IP network MALC controls bandwidth allocated and requested by each subscriber to ensure that the video requested is always compatible with the local loop bandwidth.

Access-Optimized Multicast Security

In an IP video network, security is important not only to protect the integrity of network equipment, but also to protect video content. Security mechanisms ensure the reliable and secure delivery of subscribed content to paying customers.

The Zhone MALC provides two unique security mechanisms for IP-based video services.

The first security mechanism is MAC-level filtering, which prevents devices from passing traffic on incorrect connections, and restricts access to defined set top boxes or other devices. The MALC observes the MAC address of devices (such as set top boxes) and filters to allow or disallow connections. Filtering on this value enables service providers to prevent rogue set top boxes, or hackers PCs from receiving IP addresses or passing traffic on connections designated for video.

The second security mechanism is Multicast Access Lists, which detail the IGMP groups a user can join to access on a video connection. Commonly, carriers will support packages of channels: basic, enhanced, premium, for example. Multicast Access Lists restrict subscribers' access to only those channels or channel packages to which they are entitled.

Access-Optimized Video Bandwidth Management

There are two distinct methods for delivery of video content to the Packet Loop Carrier - Sparse Mode and Dense Mode. The MALC and the Raptor implement both modes.

In Sparse Mode, the MALC receives only those streams that at least one subscriber is currently watching. In the typical case, there are many fewer channels being watched than theoretically possible in a system. This is because multiple subscribers may be watching the same channel or some set top boxes may be turned off. The processing requirements on the MALC are usually reduced significantly when running in Sparse Mode. However, Sparse Mode requires the MALC to proxy channel requests that are not currently being viewed. This can create a variable channel-change time when changing to a channel not currently sent to the MALC. A Packet Loop Carrier that supports only Sparse Mode will not be able to provide a quality viewing experience for the subscribers.

In Dense Mode, the Packet Loop Carrier receives all streams (channels) that could possibly be viewed by the subscriber. The Packet Loop Carrier is therefore processing all channels all of the time. A Packet Loop Carrier that reliably supports Dense Mode operation will always be able to provide a quality viewing experience for the subscribers. Additionally, Dense Mode operation ensures a predictable and usually shorter channel-change time. The only down-side to Dense Mode operation is that the network bandwidth between the core and the MALC is always used, even for channels not being requested by subscribers.

Dealing with "Mass Events" and Broadcast Storms

In order to deal with traffic storms generated by "mass events" (such as rebooting by a huge number of Set-Top Boxes after a power outage), the MALC supports intelligent broadcast filtering.

On routed interfaces, broadcasts are not propagated as per the specification. On bridged interfaces where broadcasts can be passed, the broadcast filter can be enabled. Once enabled, this filter will not pass any MAC level broadcast packet except under 2 conditions:

• The broadcast is an ARP and is intended for an IP address that the MALC has already learned. In this case, the broadcast will only be sent to the port where the IP has been seen
• The broadcast is a DHCP OFFER and is destined for a MAC address that we have learned. In this case, the broadcast will be sent only to the bridge interface where the MAC has been seen previously.

IGMP Multicast Address-based Filtering vs. IGMP Port-based Filtering

Zhone supports port-based filtering, but IGMP filtering is based on multicast addresses, not ports. Zhone recommends that filtering should be on IP multicast addresses, not on ports. Zhone can implement ports-based IGMP filtering should this be an absolute requirement.