As an emerging genre of service, Internet Protocol television (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. 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 1 shows a basic video network topology. The example in this chapter uses this topology. This network topology can be viewed as having two parts: an access side and a metro/core side. The demarcation of these two parts is at the video services router.
Figure 1: Basic Video Network Topology
The basic video (IPTV) network model, shown in Figure 2, consists of up to five network elements.
Figure 2: Basic IPTV Network Model
These network elements are:
At the subscriber site, a set-top box 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 digital subscriber line access multiplier (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 (typically a 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 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 3, 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 3: DSLAM Without IGMP Flow Recognition
In these early networks, broadcasting of unrequested channels was not considered a problem, because multicast usage was low and the intermediate devices were typically LAN switches with lower interface and bandwidth costs. Now that IPTV requires higher bandwidth (often 4 Mbps per channel) and bandwidth costs more, it is crucial to ensure that IPTV channels are forwarded only to those subscribers currently viewing them.
To provide more intelligent control of bandwidth, DSLAMs and other intermediate devices now recognize IGMP flows. These devices examine incoming flows and build outgoing interface (OIF) tables. Figure 4 shows a simple example of an outgoing interface table for the DSLAM. The outgoing interface table enables the DSLAM to appropriately forward each multicast group (or channel) from the correct port.
Figure 4: DSLAM with IGMP Flow Recognition
The intermediate device builds the outgoing interface 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 determine whether to forward IGMP packets (IGMP proxy) but do not modify the source IP address (IGMP snooping). We recommend that you avoid these nonstandard implementations. |
Figure 5 illustrates IGMP snooping, in which an intermediate device (such as a DSLAM) transparently monitors IGMP traffic. The device adds interfaces to its outgoing interface table when it detects join request messages and removes interfaces from its outgoing interface table when 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 (for example, if an IPTV set-top box experiences a power outage).
Figure 5: 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 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 6 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 outgoing interface table 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. If no hosts respond to the query within a configured response time interval, the proxy removes the interface from the outgoing interface table.
Figure 6: 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 can save 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 receives no information regarding subscribers on the other side of the IGMP proxy.
The Dynamic Host Configuration Protocol (DHCP) provides an automated mechanism for network devices to obtain configuration information and a lease for an IP address.
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 used in 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. All the protocols create multicast trees over which video streams can travel from one (or many) sources to a 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:
Multicast Protocols to Use—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. 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 obtains routing information (such as dynamic endpoints) from other 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.
Interior Gateway Protocols to Use—PIM must use an IGP to obtain current topology information. The two protocols most often used by PIM to obtain topology information are OSPF and 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; they flood topology information throughout a network of routers 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.
Exterior Gateway Protocols to Use—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. Each 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 packet header is analyzed only once, when the packet enters the MPLS network. 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). Downstream 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 label-switched path (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 provide a high level of failure detection and redundancy, you can employ PIM Bidirectional Forwarding Detection (BFD) for multicast traffic and Virtual Router Redundancy Protocol (VRRP) for unicast traffic in your video network.
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |