Figure 67: Basic Video Network Topology
As an emerging genre of service, IPTV networks compete with more traditional video service offerings. IPTV networks provide new revenue streams to higher-premium multiplay services, which encompass bundled voice, video, Internet, gaming, and other services.
IPTV offers true integration of information, communications, and entertainment into personalized and interactive applications centered on familiar television-like services, including:
These new opportunities also present challenges to cost-effectively manage the delivery of performance-sensitive services over a service provider’s IP infrastructure. Ensuring quality of service (QoS) for IPTV is essential, especially when the network is also carrying a wide array of other traffic. Providers cannot simply throw more and more costly bandwidth into the mix. Furthermore, IPTV and similar latency-sensitive and jitter-sensitive services cannot be delivered at an acceptable quality of service simply through additional bandwidth. IPTV services must provide more efficient resource utilization while offering the best level of experience possible for subscribers.
Figure 67 shows a basic video network topology. The example in this chapter uses this topology.
Figure 67: Basic Video Network Topology
In the basic video (IPTV) network model, shown in Figure 68, you can have up to five network elements involved. These elements include the set-top box, routing gateway, digital subscriber line access multiplexer (DSLAM), Ethernet switch, and edge router.
Figure 68: Basic IPTV Network Model
At the subscriber site, you have a set-top box that links the television to the external network. This device initiates channel change requests and responds to status inquiries.
The routing gateway, often close to the subscriber site or a part of the set-top box, aggregates traffic from multiple subscribers and may act upon requests from the set-top box.
The DSLAM, like the routing gateway, aggregates traffic from multiple subscribers and may act on requests from the set-top box. The DSLAM often resides at a separate, centrally located office.
Some networks can include an Ethernet switch or some other broadband services aggregator (BSA) to provide an additional layer of aggregation.
The edge router, broadband services router (BSR), or video services router (VSR) is the gateway into the backbone network. This device most often controls the multicast traffic to and channel requests from the set-top box.
In a video (IPTV) network, broadcast television, pay-per-view (PPV), and video-on-demand (VOD) channels are all delivered by means of IP multicasting. Internet Group Management Protocol (IGMP) is the mechanism that controls the delivery of multicast traffic to subscribers on the network. This traffic is received and controlled by the subscriber’s set-top box through multicast streams (referred to as channels). IGMP communicates with the upstream routing equipment to either begin sending (join) or stop sending (leave) a channel.
Depending on the architecture that you choose for your network, the process of controlling channels occurs on a DSLAM, an aggregation switch, or an edge router.
Basic IGMP operation involves the following two devices:
The IGMP protocol provides the following three basic functions for IP multicast networks:
In early IGMP networks, devices located between the IGMP client and the IGMP router did not detect IGMP flows. In Figure 69, the top set-top box issues a request to view Channel 4, and the DSLAM forwards the request to the edge router. In response, the edge router begins forwarding the multicast group associated with Channel 4. However, if it does not detect IGMP flows, the intermediate device (in this case, the DSLAM) cannot appropriately forward the multicast traffic. By default, most switches broadcast incoming multicast traffic to all ports. In this case, the broadcast results in the bottom client receiving an unrequested channel.
Figure 69: DSLAM Without IGMP Flow Recognition
In these early networks, broadcasting of channels was not considered problematic, because multicast usage was low and the intermediate devices were typically LAN switches with smaller, less-expensive interface and bandwidth costs. Now that IPTV requires higher bandwidth (often 4 Mbps per channel) and bandwidth costs are at more of a premium, ensuring that IPTV channels are forwarded only to those subscribers currently viewing them is becoming more and more crucial.
To address the need for more intelligent control of bandwidth, DSLAMs and other intermediate devices now recognize IGMP flows. These devices examine incoming flows and build outbound interface (OIF) tables. Figure 70 shows a simple example of an OIF table for the DSLAM. The OIF table enables the DSLAM to appropriately forward each multicast group (or channel) from the correct port.
Figure 70: DSLAM with IGMP Flow Recognition
The intermediate device builds the OIF table in one of two ways—IGMP snooping or IGMP proxy.
 |
Caution: Some intermediate devices implement IGMP subsystems that use characteristics of both IGMP snooping and IGMP proxy. Most commonly, these devices might decide whether or not to forward IGMP packets (IGMP proxy) but not to modify the source IP address (IGMP snooping). We recommend that you avoid these nonstandard implementations. |
Figure 71 illustrates IGMP snooping, in which an intermediate device (like a DSLAM) transparently monitors IGMP traffic. The device adds interfaces to its OIF table whenever it detects join request messages and removes interfaces from its OIF table whenever it detects leave request messages. The snooping device also maintains state information for general “ membership query maximum response time” timers if the IGMP client does not issue a leave message (in the case of a power outage of some type for an IPTV set-top box).
Figure 71: IGMP Snooping
Because IGMP snooping is transparent, the snooping device typically does not participate in IGMP host messaging. The device only monitors transactions between clients and routers, forwarding IGMP packets upstream to the multicast router and determining when join or leave processing is required for a downstream host. One exception to this transparency occurs when the snooping device intercepts membership reports based on local filters to prevent the host from joining specific groups (that is, specific broadcast channels allocated to multicast groups that are blocked from being received by the end set-top box).
The snooping device can receive multicast data in several ways within a broadband access network. The router might be configured to flood all multicast groups downstream to the snooping device. The upstream router might forward only groups based on IGMP membership reports that it receives from the IGMP hosts. The snooping agent might invoke an IGMP client process to source its own membership reports that it sends to the multicast router, and so on. However, these various options are beyond the scope of this document.
Figure 72 illustrates an IGMP proxy. An IGMP proxy performs functions of both an IGMP router and an IGMP client. When an IGMP host issues a join message, the IGMP proxy receives the message and adds the interface to its OIF list for a specific multicast group. The proxy uses a general membership query timer and state to send general queries downstream to all multicast-enabled interfaces. When the IGMP proxy receives a leave message, the proxy issues a group-specific query and removes the interface from the OIF list if no hosts respond to the query within a configured response time interval.
Figure 72: IGMP Proxy
A device that functions as an IGMP proxy participates in every IGMP flow. This level of participation requires much more processing power and memory allocation from the DSLAM, but it potentially saves some upstream bandwidth.
Because a multicast router treats any IGMP proxy that it interacts with as an IGMP client, the multicast router tracks one device (the DSLAM) joining and leaving multicast groups. As a result, the multicast router does not receive any information regarding subscribers on the other side of the IGMP proxy.
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism through which devices using Transmission Control Protocol/IP (TCP/IP) can obtain protocol configuration parameters automatically from a DHCP server on the network.
The most important configuration parameter carried by DHCP is the IP address. A computer must initially be assigned a specific IP address that is appropriate to the network to which the computer is attached and that is not assigned to any other computer on that network. If you move a computer to a new network, it must be assigned a new IP address for that new network. You can use DHCP to manage these assignments automatically.
DHCP carries other important configuration parameters, such as the subnet mask, default router, and DNS server.
The video services router must run DHCP relay to enable devices to obtain parameters from the DHCP server on the network. The DHCP relay feature relays a request from a remote client to a DHCP server for an IP address. When the router receives a DHCP request from an IP client, it forwards the request to the DHCP server and passes the response back to the IP client.
For more information about configuring DHCP relay, see the JUNOS Policy Framework Configuration Guide.
Video networks can incorporate various protocols within the metro and core network. How you configure a metro or core network to transmit video streams depends on the type of network you have and the complexity of your application. The common factor among these various protocols is that they create multicast trees over which video streams can travel from one (or many) sources to some number of hosts.
When running video networks in an IP metro and core network, you must configure several protocols to function together. These protocols typically include the following protocol types:
Video networks often use Protocol Independent Multicast-Sparse Mode (PIM-SM) when communicating beyond the access side of the network (that is, in the metro or core networks).
PIM is a family of multicast routing protocols that enable one-to-many and many-to-many distribution of data over the core. The term protocol-independent means that PIM is not dependent on any particular unicast routing protocol for topology discovery. However, because it does not have its own method of topology discovery, PIM uses routing information (like dynamic endpoints) that it obtains from other traditional routing protocols, such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
Instead of flooding packets throughout the network and then removing (or pruning) paths where no receivers exist, PIM-SM uses the information it receives from the other routing protocols to construct a tree from each sender to the receivers in a multicast group.
PIM must use an IGP to obtain current topology information. The two protocols most often used by PIM to obtain topology information are OSPF or IS-IS. As IGPs, OSPF and IS-IS function within a single autonomous system (OSPF) or area (IS-IS).
Both OSPF and IS-IS are link-state routing protocols, meaning that they flood topology information throughout a network of routers (that is, within the autonomous system or area). After obtaining this information, each router independently builds a picture of the network topology. The routers can then forward packets or datagrams based on the best topological path through the network to the destination.
Depending on the complexity and size of your network, you might need to configure an exterior gateway protocol (EGP). EGPs such as Border Gateway Protocol (BGP) exchange routing information between networks.
Instead of using PIM-SM to create multicast trees, you can use MPLS to control the paths that traffic takes to various destinations.
In the traditional Layer 3 forwarding paradigm, as a packet travels from one router to the next, an independent forwarding decision is made at each hop—the device analyzes the IP network layer header and then chooses the next hop based on the analysis and the information in the routing table.
In an MPLS environment, however, the device analyzes the packet header only once when the packet enters the MPLS cloud. After analyzing the packet header, the router assigns the packet to a stream that is identified by a label (a short, fixed-length value at the front of the packet). Routers use these labels as lookup indexes for the label-forwarding table. The label-forwarding table stores forwarding information for each label.
A point-to-multipoint MPLS LSP is an RSVP-signaled LSP with a single source and multiple destinations. By taking advantage of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary packet replication at the ingress router. Packet replication takes place only when packets are forwarded to two or more different destinations requiring different network paths.
Point-to-multipoint LSPs enable you to do the following:
For additional information about how to configure MPLS point-to-multipoint LSPs, see the JUNOS MPLS Applications Configuration Guide.
Video networks require rapid failure detection and router redundancy to ensure minimal interruption of service. To accomplish this level of failure detection and redundancy, you can employ PIM Bidirectional Forwarding Detection (for multicast traffic) and Virtual Router Redundancy Protocol (for unicast traffic) in your video network.