A P P L I C A T I O N N O T E
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
AbstractImplementing broadcast TV (BTV) service using a unique application of hierarchical
virtual private LAN service (H-VPLS) minimizes operational and capital costs to
service providers while guaranteeing improved delivery of services to customers.
Alcatel’s solution gives service providers the scalability, traffic engineering, security,
resiliency and cost-effectiveness required to deliver content applications in metro
aggregation networks.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Network Architectures for Broadcast TV . . . . . . . . . . . . . . . . . . . . . . . 1
Broadcast TV Service Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
A Network Architecture for the Delivery of Broadcast TV . . . . . . . . . . . . . . . . . . 1
Conventional End-to-End IP Network Architecture . . . . . . . . . . . . . . . . . . . . . . . 4
Broadcast Services with VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Conventional Versus Innovative Infrastructures: The Pros and Cons . . . . . . . . . . . 8
Network Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Per-Demand Multicast Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Operation of a Per-Demand Multicast Service . . . . . . . . . . . . . . . . . . . . . . . . 11
Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Service Provider Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Table of Contents
ALCATEL 1 >
IntroductionMetro Ethernet networks are rapidly becoming the networks
of choice for aggregation of user traffic toward the core as
service providers attempt to reduce operational and capital
expenditures on one hand and increase revenues derived
from their network infrastructures on the other. Typically,
reductions in capital expenditures are realized because an
Ethernet interface is significantly cheaper than a SONET/SHD
interface of the same bandwidth. Operational expenditures
are reduced because Ethernet-based service interfaces offer
a number of benefits, unavailable from traditional interfaces
such as leased lines or frame relay/asynchronous transfer mode
(ATM). For example, service providers can realize operational
cost savings in an Ethernet network by increasing the amount
of bandwidth provided to a customer through a configuration
change rather than the truck roll/interface change typically
required with leased lines and frame relay/ATM.
New revenue opportunities are available today to service
providers who have a network infrastructure capable of
delivering a wide variety of high-value services, such as
Layer 2 and 3 virtual private networks (VPNs) and triple-play
services, such as voice, video and high-speed Internet access.
These new services are associated with service-level
guarantees that are difficult to achieve in traditional,
best-effort networks.
Service providers have been deploying multiprotocol label
switching (MPLS) in the core of their networks for some time
but metro aggregation networks have lagged behind in the
transition to MPLS. Typically, aggregation networks are based
on traditional, bridged, Ethernet networks. These networks
depend on various forms of the spanning tree protocol for
resiliency but recovery times are slow. Also, the scalability of
these networks is limited, due to the relatively small virtual
local area network (VLAN) tag-numbering space and to media
access control (MAC) addressing issues. Finally, traffic
management is challenging and large amounts of bandwidth
are usually needed to resolve issues.
Alcatel’s broadband services aggregation architecture, which
defines a framework for the deployment of triple play and
business services over a single network, addresses these
limitations. This architecture is based on a new generation
of service-oriented platforms that use multiprotocol label
switching (MPLS) as the underlying technology to deliver
services. Metro aggregation networks built using next-
generation MPLS-enabled Ethernet nodes have the scalability,
traffic engineering and resiliency required to deliver the
variety of high-end services that customers are requesting
from their service providers.
When the resiliency and traffic engineering capabilities inherent
in MPLS are combined with service-oriented platforms, such
as the Alcatel 7750 Service Router (SR) and the Alcatel 7450
Ethernet Service Switch (ESS), a range of advanced, revenue-
generating services can be delivered over a single network.
Broadcast TV (BTV) is just one of the new, high-value
services that providers can offer their customers over a next
generation network infrastructure such as Alcatel’s broadband
services aggregation architecture. This paper describes the
implementation of a BTV service using a unique application
of hierarchical virtual private LAN service (H-VPLS) and a
per-demand multicast service to enable the delivery of content
services over a single network infrastructure.
Network Architectures for Broadcast TVBroadcast TV Service RequirementsTo compete effectively with traditional approaches to deliver-
ing a TV service, there are three key requirements for an
IP-based BTV service:
> Channel-changing (channel-zapping) response times must
be comparable to those of traditional cable-based service.
> Service availability levels must be in the order of 99.999
percent (five 9s).
> The network must be able to provide stringent quality of
service (QoS) guarantees in order to maintain very strict
bounds on the delay and jitter the associated traffic
experiences.
A Network Architecture for the Delivery of Broadcast TVFigure 1 shows a typical backbone/metro network architecture
that can deliver BTV services to subscribers. The backbone of
the network is an IP/MPLS core. Each aggregation network is
dually connected to the core by a pair of routers for resiliency
(R1 and R2). The BTV/video data stream enters the network
from a router that is connected to the BTV head-end. The
aggregation network consists of a ring of switches/routers.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
> 2 ALCATEL
Each switch/router acts as a provider edge (PE) device for
one or more access devices, in this case a digital subscriber
line access multiplexer (DSLAM). The end customer’s set-top
box (STB) connects to the DSLAM over a DSL modem.
The access device could be a multi-tenant unit (MTU)
device located in the basement of an apartment building and
connected to subscribers’ STBs by a set of downlinks. The
operation is identical for both the DSLAM and MTU devices.
All functions attributed to the DSLAM are also found on the
MTU device.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
MTU
DSLAM
IP/MPLS Backbone
Aggregation Network
MTU
BTV Headend
Head-EndRouter
R1R2
PE2 PE4
PE5
PE3
PE1
STB/TV
Figure 1 - Network Architecture for the Delivery of BTV
ALCATEL 3 >
A basic understanding of IP addressing and the Internet group management protocol(IGMP) is required to understand the opera-tion of the BTV solution in this paper. Refer tothe Internet Engineering Task Force (IETF)Requests for Comments (RFCs) for a completedescription of the operation of both IGMPand IP multicast.
There are three fundamentally differentaddress types that are used to move IPpackets or Ethernet frames from one hostcomputer to another: unicast, broadcast and multicast. Unicast addressing is used for traffic between two hosts that wish tocommunicate. One copy of the packettraverses the network that connects the two hosts. Broadcast addressing is usedwhen one host on the network wants tocommunicate simultaneously with all of thehosts on the network. The host that sends the message uses a well-known destinationaddress that tells the network the packetshould be duplicated and delivered to everyhost on the network. Multicast addressing is a special case of broadcast addressing. It isused when the sender wants to communicatewith a specific subset of the hosts connectedto the network. In a pure Layer 2 network, the behavior is very similar to broadcastaddressing — the packet is duplicated anddelivered to each host connected to thenetwork. The host uses the destination MACaddress to determine if it is interested in thepacket. In the absence of an IP multicastrouting protocol, such as protocol-independentmulticase (PIM)-SM and IGMP, IP-multicastaddressed packets behave in the same way.
IP multicast protocols, such as PIM-SM, limit the spread of copies of the packet in the network to the areas where there arehosts that have expressed an interest in these packets. IP multicast addresses specifya community of interest or group for theparticular type of communication. The rela-tionship between the multicast address andthe multicast group is defined by the network.An example of a common multicast applica-tion is the delivery of stock quotes to a set of hosts within a network. The community ofinterest is the set of hosts that want to havethe stock quote information delivered to them.An IP multicast address is assigned at thenetwork level to identify the multicast group.The multicast routing protocol ensures that thepackets containing stock quote informationare only delivered to the parts of the networkwhere there are interested hosts.
IGMP is a protocol used to allow hosts tocommunicate their desire to join or leave amulticast group. There are two different typesof messages that are important to this paper:IGMP group membership reports and leavemessages. The former allow a host to join aspecific group and the latter allow a host toleave a group. When a host wants to join amulticast group, it sends a membership reportto its nearest multicast-enabled router, whichresponds by starting to deliver the desiredtraffic to the part of the network where thehost is located. Conversely, when the host is no longer interested, it sends an IGMPleave message to its nearest multicast-enabledrouter and it responds by stopping the deliveryof the traffic to the portion of the networkwhere the host resides.
Another aspect of IGMP that is used in thesolution proposed in this paper is the IGMPquerier function. If a network segment hastwo or more multicast-enabled routers attachedto it, only one of these devices can react toIGMP messages, as described above. Inorder to decide which of the routers will beactive, a querier is elected. The winner of the election is the device that sends out theglobal query messages with the lowestsource-IP address. The other routers go intonon-querier mode where they simply listen to the global query messages. If they losecontact with the querier — if they do notreceive any messages for a period of time —then the election is performed again todetermine which router should take over as querier. This function plays an importantrole in the resiliency of a network thatdelivers a BTV service.
IGMP snooping is another technique used in the network architecture to deliver BTVservice to subscribers. IGMP snooping is used by Layer 2 devices such as a DSLAM or MTU access devices to listen to an IGMPconversation between host (in this case theSTB) and the multicast-enabled routers locatedat the interface between the core and aggre-gation networks. The IGMP traffic is snoopedby the access device to determine if themessage is a membership report or a leavemessage and, if so, to extract informationregarding the multicast group involved. ■
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
IGMP/MULT ICAST PR IMER
> 4 ALCATEL
Conventional End-to-End IP Network ArchitectureThe simplest way to implement delivery of a BTV service to
a set of customers connected at the access network is to
deploy an interior gateway protocol (IGP), such as intermediate
system — to intermediate system (IS-IS) or open shortest path
first (OSPF), and an IP-multicast protocol, such as PIM-SM, in
both the core and aggregation networks. Using this approach,
PIM is responsible for setting up individual multicast trees,
one for each BTV channel, to deliver the traffic to the access
devices in the aggregation network. Each television channel
belongs to a different multicast group; therefore, each has a
different multicast IP address assigned to the packets carrying
data for the channel. IGMP is used by the STB to tell the PE
device which channel the user is requesting.
When the STB/television is turned on, the STB sends an IGMP
membership request to the PE device, requesting the initial
channel. The membership request is received by the mutlicast-
enabled PE device and mapped to a PIM join message, which
is sent to the head-end of the network. An appropriate multi-
cast tree is created and used by the routers in the network to
deliver the multicast traffic to the PE device. The PE device
sends the traffic to the access device (DSLAM or MTU) for
delivery to the appropriate subscriber.
When the customer switches or zaps from one channel to
another, the STB sends an IGMP leave request, followed by
a membership request, to the PE router. The leave request
may result in the multicast tree being partially or completely
removed from the network, depending on whether other
TV viewers in the network are currently viewing the same
channel and where they are attached to the network. The
new membership request is handled as described above,
and a new multicast tree is set up to deliver the traffic
associated with the channel to the user.
The DSLAM or MTU access device must be capable of snoop-
ing the IGMP requests the STB generates, in order to know
which multicast group (TV channel) to deliver to which
subscriber. When the access device detects an IGMP leave
message, it must determine which subscriber’s STB it originated
from (port number or VLAN ID) and which multicast group
the leave message is related to (derived from the IGMP
message content). The DSLAM or MTU can then shut off the
flow of traffic associated with the group to the subscriber’s
STB. Conversely, when a membership request is received,
the same process occurs and the traffic for the requested
channel is sent to the STB. After the access device snoops
the IGMP message, it is sent upstream to the PE device,
where it is mapped by PIM to a join message.
There are several problems associated with this approach
and some of these cause unacceptable delays in delivering
the TV signal to the end user. The creation and teardown of
the necessary multicast trees by PIM can take a significant
amount of time, depending on the user’s location in the
network relative to other users watching the same channel.
In the worst case (i.e., if no other subscriber is watching the
requested channel) the tree must be constructed all the way
back to the router connecting the BTV server to the backbone.
This results in channel-zapping times on the order of seconds,
far longer than the response times associated with conventional
cable TV. The response times will be roughly proportional
to the size of the network and the amount of ongoing IGMP
activity in the network.
Using PIM multicast trees as the delivery mechanism for this
traffic from the head-end to the subscriber also has a significant
negative impact on network resiliency. Any failure in the net-
work will result in substantial recovery delays related to the
reconvergence of the underlying IGP network, followed by the
rebuilding of the affected multicast trees. The recovery times
will be in the order of tens of seconds and will result in the
loss of service that could potentially affect a large percentage
of the network’s customer base.
Running PIM throughout the network significantly increases
the network’s capital and operational expenses. It adds to the
complexity of the network, making it more difficult to deploy
and maintain. Debugging problems in a multicast network are
not trivial — they increase operational costs and can lead to
significant periods of service downtime.
Poor channel-zapping response times and service downtimes,
related to poor network resiliency or difficulty in resolving
customer problems, lead to customer dissatisfaction and
churn in the service provider’s customer base.
Running PIM throughout the network also significantly reduces
network scalability and results in increased capital expenses
per customer. Because PIM and IGP are run in the aggregation
network, the platforms used to construct this part of the net-
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
ALCATEL 5 >
work must dedicate system resources to operate the routing
functionality. Because of this consumption of resources, fewer
subscribers can be serviced by each PE device and the
network’s capacity to offer other types of services concurrently
is severely limited. Consequently, more platforms are needed
to provide services.
These factors increase the capital expenses and operating
expenses for each subscriber as well as reducing the
competitiveness of the service offering and the network’s
return-on-investment (ROI) potential.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
VPLS is a new class of VPN technology thatprovides a simple, cost-effective alternative to frame relay or ATM for the interconnectionof multiple customer sites by a single, bridgeddomain, operating on a provider-managedIP/MPLS-based WAN. From the customer’sperspective, all sites appear to be connectedto each other by a single LAN segment regard-less of their location. VPLS is described inInternet Draft — draft-ietf-l2vpn-vpls-ldp-04.txt— produced by the IETF PPVPN WorkingGroup. The following is an overview of VPLS operation.
The customer premises equipment (CPE)devices are connected to the PE equipmentvia Ethernet. The PE devices in the networkare connected by a full mesh of MPLS labelswitched paths (LSPs) or transport tunnels.Multiple VPLS services can be provided overthe same set of transport tunnels. In order tokeep the traffic of multiple customers separatein the transport tunnel, targeted label distri-
bution protocol (LDP) signaling is used tonegotiate a set of ingress and egress virtualconnection (VC) or pseudowire labels foreach VPLS instance. The VC labels areappended to customer packets before they are sent into the network and used todemultiplex traffic arriving at the PE device.
When a packet arrives on an access interfaceor pseudowire, the PE device examines thesource MAC address of the packet. The MACaddresses, along with the access-port identifieror VC label of the pseudowire where thepacket was received, are stored internally in a forwarding information base (FIB). Aseparate FIB is maintained for each VPLSservice. The destination MAC address of thepacket is compared to the appropriate FIB todetermine which access port or pseudowirethe packet should be transmitted to. If theMAC address is not found in the FIB, thepacket is flooded on each pseudowire or port associated with the service (except
for the port/pseudowire that received thepacket). If the destination address is a multi-cast or broadcast address, the FIB lookup is foregone and the packet is flooded.
H-VPLS is an enhancement of VPLS thatimproves the scalability of VPLS services by introducing hierarchy. The introduction of a second tier of pseudowires removes theneed for a full mesh among all the PE devicesparticipating in a VPLS service. A new type of pseudowire, known as a spoke pseudowire,allows connection of a PE device to the mesh,and therefore to all other PEs participating in the service instance, using a single-spokepseudowire. Hierarchy in the VPLS servicereduces the signaling overhead and distributesthe packet-duplication overhead related to theforwarding of unknown and non-unicast trafficamong all of the involved PE devices. Spokepseudowires play an important role in theBTV solution. ■
VPLS INTRODUCT ION
> 6 ALCATEL
Broadcast Services with VPLSUsing VPLS technology in the aggregation network provides a
more powerful solution for the delivery of BTV services. VPLS
limits the scope of deploying PIM to the IP/MPLS backbone to
take advantage of the inherent multicast capabilities of VPLS
to deliver the BTV traffic to the customer.
In Figure 2, VPLS is used in the aggregation network to create
a Layer 2 VPN, which interconnects all PE devices transpar-
ently. The underlying tunneling technology is MPLS. A full
mesh of LSPs is established between the PE devices carrying
the pseudowires that interconnect the VPLS service instances
located on the PEs.
When the PE device connected to the backbone receives
multicast traffic, it is flooded to all PE devices participating
in the VPLS VPN over the set of pre-established pseudowires.
Each PE device in the aggregation ring receives all the traffic
associated with each BTV channel without having to deploy
PIM in the aggregation network.
Using VPLS in the aggregation network resolves several
problems inherent in the PIM-based solution. Because VPLS
is based on MPLS, the sub-50 ms recovery times inherent in
MPLS can be leveraged to dramatically improve recovery times
after a node or link failure occurs in this part of the network.
Removing PIM from the aggregation part of the network
dramatically reduces the operational complexity of deploying,
maintaining and debugging problems. Network scalability is
increased because the number of users served by each PE
device is increased, and the reduction in resource consump-
tion makes it possible to offer different types of services
concurrently.
Replacing PIM with VPLS in the aggregation network
improves network resiliency and decreases operating
and capital costs.
Hierarchical-VPLS: optimizing bandwidth use in the networkMany metro aggregation networks use a ring-based topology,
so a number of LSPs that compose the full mesh of pseudowires
required for a VPLS-based VPN will be assigned to the same
physical link. Because all of the packets associated with a
BTV transmission use Layer 2 multicast MAC addresses,
they will be flooded over every pseudowire in the mesh. The
same packet is sent over the link, once for each pseudowire
assigned to the link, resulting in significant wasted bandwidth.
The packet forwarding engine associated with the physical
interface will have to make multiple copies of the same
packet, consuming significant packet-processing resources.
Finally, if the mesh is large, the initial deployment of the VPLS
service or the subsequent addition of a new PE device to the
ring will require the configuration of many pseudowires.
An innovative VPLS application, called daisy-chained hierar-
chical VPLS, resolves these concerns. Figure 3 shows adjacent
PE devices in the aggregation ring that are connected together
with a spoke pseudowire to form a single point-to-point VPLS
instance, and are adapted to the underlying physical-ring
topology. The endpoints of the ring (PE1 and PE5) are not
connected; this avoids a Layer 2 loop.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
DSLAM
R1 R2
PE2 PE4
PE5
PE3
PE1
STB/TV
IGMPMessages
IP/MPLSBackbone
BTVChannel
Data
Physical LinkPseudo WireVPLS VPN
Figure 2 - VPLS-Enabled Network Architecture
for the Delivery of BTV
ALCATEL 7 >
Each packet that arrives at a PE device (PE1 in Figure 3)
is duplicated, once per attached access device, and then
forwarded to these devices. The original copy of the packet
is forwarded to the next PE device in the ring. The final PE
device (PE5) that terminates the ring forwards the duplicates
of the packet to its attached access devices but does not
forward it further.
The daisy-chained H-VPLS approach reduces the number of
packets flowing over the ring to the minimum required to
implement the BTV service. The ring is optimized because
only one copy of each packet traverses the ring, reducing
bandwidth consumption. The packet-processing load on each
individual PE device is minimized by distributing the packet-
duplication load over the set of PE devices making up the
ring. Comparing Figures 2 and 3 shows that the number of
pseudowire connections is also minimized, easing the initial
deployment of a BTV service and making it simpler to add a
new PE device to the network.
Table 1 summarizes the functions of each of the devices in the
network.
Table 1 - Functions of Network Devices
in a VPLS-Based Architecture
Function Core PE DSLAM/ Set-Top Router Device MTU Box
Participates in PIM Xprotocol running in the IP/MPLS backbone
Configured with static XIGMP entries (one per BTV channel); generates multicast-tree join requests to the head-end of the network
IGMP querier function Xand switchover to backup querier in failure scenarios
Implements QoS — X X Xensures that video traffic is treated appropriately to minimize delay and jitter in the video streams
Implements daisy- Xchained H-VPLS in the aggregation ring
Ring failure recovery X(sub 50 ms) using MPLS fast reroute
IGMP snooping — opens X* Xand closes channels to the STB based on receipt of IGMP membership and leave requests
Generates IGMP membership Xrequest and leave messages in response to subscriber channel zapping
* Only required if the DSLAM/MTU devices are incapable of this function.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
DSLAM
R1 R2
PE2 PE4
PE5
PE3
PE1
STB/TV
IGMPMessages
IP/MPLSBackbone
BTVChannel
Data
Physical LinkPseudo WireH-VPLS VPN
Figure 3 - H-VPLS-Enabled Network Architecture
for the Delivery of BTV
> 8 ALCATEL
Detailed BTV service operation with a VPLS-based architectureThe PIM multicast protocol can be deployed and limited to the
IP/MPLS backbone by using VPLS in the aggregation network.
One static IGMP entry is configured for each TV channel on
the routers (R1 and R2 in Figure 3). The IP multicast group
address is used to identify all traffic associated with a TV
channel. When the routers initialize, they perform the process
needed to decide which of the two routers will be the querier
for the aggregation network. After the election process is
complete, the router acting as querier (R1) generates PIM join
requests (one for each of the multicast groups represented by
the statically configured IGMP entries), and sends them to the
head-end router. This results in the construction of static
multicast trees from the head-end device to router R1. Once
the multicast trees are created, R1 receives all data associated
with each TV channel, and forwards it to the first PE device
in the aggregation ring.
When the PE device receives the TV channel data from the
router elected as querier, it duplicates the traffic and sends
it to the access devices connected to it. It then forwards the
original packet to the next H-VPLS instance in the daisy-chain.
This process is repeated at each PE device in the ring.
Delivering the data stream that makes up the various TV
channels out to the access devices plays an important role
in ensuring that the response times for channel zapping are
consistently less than 50 ms. It may appear that constant
delivery of the data stream associated with many different
TV channels to the access devices results in a significant
waste of bandwidth. However, there will be several hundred
TV viewers attached to each of the aggregation networks. At
any given time, it is likely that at least one of these subscribers
will be viewing each channel and will require the distribution
of that channel’s traffic to the aggregation network.
The data associated with each TV channel is now delivered
to the DSLAM or MTU access devices in the network. When
a subscriber zaps from one channel to the next, the STB
generates two IGMP messages: a leave request followed
immediately by a membership report. The access device
performs IGMP snooping on both messages and responds
as described earlier. The new channel to the STB/TV can be
delivered instantly because the traffic associated with all
channels is being delivered to the DSLAM or MTU, ensuring
that zapping delay times are short and consistent.
In contrast, the channel-zapping delay in a conventional PIM-
based approach depends on the time it takes to set up a new
multicast tree from the head-end of the network to the access
device, in response to the membership request message. The
time required to do this depends on the network size and the
number of IGMP requests being processed by the network. This
makes channel-zapping times much longer and inconsistent.
Conventional Versus Innovative Infrastructures: The Pros and ConsUsing VPLS removes the need to deploy a multicast routing
protocol such as PIM-SM or PIM-SSM in the aggregation
network. The application of daisy-chained H-VPLS improves
the bandwidth efficiency, optimizes multicast-packet duplica-
tion, eases initial deployment and simplifies the addition of
a new site (PE and access devices) to the network. The
implications of this are summarized in Table 2.
Table 2 - Comparison of PIM and VPLS-Based Broadcast TV
Delivery Solutions
PIM-Based VPLS-Based Solution Solution
Initial deployment effort High Moderate
Operational cost High Low
Capital cost High Moderate
Channel-zapping delay Long and Short and inconsistent consistent
Network scalability Limited Enhanced
Network failure recovery time High Low
A network architecture based on daisy-chained H-VPLS
guarantees that consistent response time requirements for
channel zapping can be met. The PIM-based approach cannot
provide these guarantees because of the latency involved in
setting up multicast trees from the head-end to the access
devices in the network. Channel-zapping times will often
be inconsistent and longer than required. This variation in
response times leaves the TV viewer with the impression
that the service is not only slow but inconsistent.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
ALCATEL 9 >
Substituting H-VPLS for PIM in the aggregation portion of the
network significantly reduces operational complexity. H-VPLS
is a much simpler protocol to deploy and debug than multicast
protocols such as PIM. Alcatel has developed a comprehensive
service assurance toolkit that exceeds the traditional ping and
trace-route debugging capabilities of a typical router/switch.
These tools allow the network operator to quickly test each
H-VPLS segment and isolate a problem. A second tier of MAC-
level tools can then be used to resolve the problem in the
H-VPLS segment quickly and efficiently. Because the network
is less complex, fewer network problems will arise and,
when problems do arise, the resolution times will be shorter
for an Alcatel H-VPLS based solution, thereby improving
customer satisfaction.
Replacing PIM in the aggregation network with H-VPLS signifi-
cantly reduces the capital costs associated with deploying or
upgrading a network to deliver BTV service. This is because
PE devices consume fewer resources with H-VPLS than with
PIM. The consequences of this are twofold. The scalability of
the network is increased: more customers can be served by
each PE, reducing the number of PE devices that need to be
deployed. Second, because there is less overall load on the
network, the service provider can use the same infrastructure
to deliver a wide range of other services to its customer base.
Using daisy-chained H-VPLS to deliver a BTV service also
improves network resiliency. The next section examines a
variety of network-failure scenarios and highlights the improve-
ments in network resiliency that result from the deployment
of H-VPLS technology in the aggregation network.
Network ResilienceThe VPLS protocol is underpinned by MPLS. MPLS has a built-
in mechanism called fast reroute, which provides sub-50 ms
recovery times in the event of node or link failures. Using fast
reroute to defend against node or link failures in the aggregation
ring, in combination with the use of the querier election
process built into IGMP, provides protection from many
failure scenarios that can occur in the aggregation portion
of the network.
If a physical link connecting any two adjacent PE devices fails,
the MPLS fast reroute function will reroute traffic around the
failure. For example, in Figure 4, if R1 is the querier for the
aggregation ring, the TV channel data will flow in a counter-
clockwise direction. Assume the link connecting PE2 and PE3
fails. The daisy-chained, H-VPLS ring will be interrupted. PE2
will invoke fast reroute protection. Traffic arriving at PE2 will
be duplicated and sent to the access devices attached to it,
as before. Traffic will then be redirected from PE2 back to
PE1, PE5, PE4 and PE3 over a backup LSP, in sub-50 ms time
intervals. The subscribers attached to the PE devices down-
stream of the failed link will not experience any loss of service.
Other possible network failures include the loss of the link
connecting the router to the first PE device (e.g., the link
between R1 and PE1 fails), the failure of one of the routers
(e.g., R1 fails and it is the querier for the ring), or the failure
of one of the PE devices connecting directly to R1 or R2.
Because R1 is the querier, it sends global query messages
out to the ring periodically. When the network is operating
normally, the non-querier device (R2) receives these messages
after they traverse the ring. In this failure scenario, the querier
is disconnected from the ring, and R2 no longer receives global
query messages from R1. R2 will assume the role of querier
for the aggregation ring after a timeout period has expired.
PIM, running on R2, will send one join message for each
statically configured IGMP entry toward the head-end of the
network. This allows the necessary multicast trees to be
rebuilt. The multicast traffic for each of the TV channels will
then be delivered to R2 and forwarded on to the aggregation
ring, using PE5 for delivery to the attached PE devices. This
restoration process will take approximately one to two
seconds to complete.
In the event of a failure of a PE device in the ring (other that
PE1 and PE5; assume PE3), R2 will stop seeing global query
messages from R1 and take over as querier for the ring, setting
up the needed multicast trees as described above. R1 will
continue to deliver BTV traffic to the PE devices on its half of
the severed ring. R2 will deliver BTV traffic to the other half of
the ring, once it has established itself as a querier. See Figure 4.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
> 10 ALCATEL
Figure 4 - Network Failure Scenarios
Quality of ServiceThe devices in the network must provide a comprehensive set
of QoS and traffic engineering capabilities in order to meet the
stringent delay and jitter requirements of a BTV service. This
is especially important if the network is being used to deliver
a multitude of service types, with different characteristics,
to thousands of customers.
Traffic management is further complicated by the trend to
provide these services on Ethernet-based metro aggregation
networks. Ethernet by itself does not have the necessary
attributes to meet the demands of this environment. It has
no intrinsic traffic management capability and depends on
an IEEE 802.1p mechanism to differentiate traffic classes.
Traditionally, these networks have been built using routers
or switches that work well in an enterprise network setting.
However, these devices do not have the capabilities necessary
to provide the service levels required by service providers.
Typically, they provide class of service on a per-port basis
only, with a limited number of queues, limited traffic classifi-
cation capabilities and small amounts of packet buffer memory.
They cannot distinguish between traffic belonging to different
customers. This makes it possible for one customer to impact
the services of other customers served by the same device.
Increasing bandwidth to resolve the problem has not produced
the desired result, and it increases capital expenses and
operating expenses.
Because the VPLS protocol runs over MPLS, the aggregation
network inherits the traffic- management capabilities inherent
in MPLS. The traffic management characteristics of MPLS,
when combined with service-oriented QoS capabilities, allow
the service provider to build networks that deliver high-quality
BTV services concurrently with many other SLA-based service
types. The key attribute of service-oriented QoS is that it
provides each individual service with a set of dedicated
resources. This ensures that the traffic associated with each
service (such as a BTV service) receives the appropriate
priority and bandwidth guarantees dictated by the traffic type
and the service level agreement (SLA). The Alcatel 7750 SR
and the Alcatel 7450 ESS possess the QoS resources to meet
these requirements. The underlying attributes of a QoS
system capable of providing this level of service include:
> Rich, wire-rate, packet classification at Layers 2, 3 and
above
> Fine-grained range of packet priorities, each with an
associated service queue, in order to ensure that user traffic
is handled in accordance with the required precedence
> Packet buffering dedicated for the use of traffic in each
service (customer) queue
> Ingress and egress traffic shaping so that the traffic associated
with each service can be managed such that traffic flows do
not have a cross-impact between services
> Hierarchical scheduling, which allows maximal bandwidth
delivery to the customer while simplifying the management
task for the service provider
SecurityThe service provider must be able to limit the set of TV channels
that paying subscribers can access. Unscrupulous individuals
could gain access to BTV services they have not subscribed
to unless measures are taken to prevent unauthorized access.
Also, the service provider may sell different “channel bundles”
to the various subscribers on the network.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
DSLAM
R1 R2
PE2 PE4
PE5
PE3
PE1
STB/TV
IGMPMessages
IP/MPLSBackbone
BTVChannel
Data
Physical LinkPseudo WireH-VPLS VPN
ALCATEL 11 >
To limit the set of channels a subscriber can access, IGMP
filtering can be used on the DSLAM or MTU access device
to limit the set of multicast addresses allowed for each
subscriber and the channels each subscriber can access.
Disabling IGMP snooping on an access device interface
prevents non-subscribers from accessing any of the BTV
channels destined for other, legitimate subscribers who
receive service from that access device.
Another security concern relates to the fact that IGMP
messages are multicast and could be used to initiate a denial
of service (DoS) attack on the network. This is mitigated by
restricting the processing of IGMP messages to the access
device in order to determine the TV channel that is requested.
The messages do not have to be forwarded beyond the access
device; therefore, they cannot impact the network as a whole.
The access device drops all other traffic the user sends into
the network.
Per-Demand Multicast ServiceA per-demand multicast service can be provided using the
same network infrastructure and protocols described above
for BTV service. The content delivered over this type of
service has a smaller community of interest. Some examples
are the delivery of distance education and business video-
conferencing. These types of applications have the same
requirements for service availability as a BTV service. Many
QoS requirements will be the same, but real-time response
requirements will be different.
Real-time requirements for applications using a per-demand,
multicast service are more relaxed than for BTV, so constant
delivery of the traffic associated with the application, through
the aggregation portion of the network out to the access
device, is not required. Some changes to network configuration
and operation will be required.
Operation of a Per-Demand Multicast ServiceThe physical network architecture used for per-demand multi-
cast service is identical to that used for the delivery of BTV.
PIM deployment is restricted to the routers that form the
backbone of the network. Daisy-chained H-VPLS is deployed
in the aggregation network. The benefits of this deployment
model are identical to those described above.
There are two key differences between these service delivery
approaches. Static IGMP entries are not configured in the
backbone routers (see R1 and R2 in Figure 3). This implies
that the application data is not being constantly delivered into
the aggregation network. Multicast traffic flow to a subscriber
is initiated in response to the receipt of an IGMP membership
report by the PIM-enabled router in the backbone. Second,
IGMP snooping is enabled on all PE nodes in the aggregation
network and to the access device.
When a distance education subscriber has a lecture scheduled,
an IGMP membership request from the subscriber’s PC makes
a request to begin delivery of the video stream. The DSLAM
or MTU access device snoops the IGMP request and opens
the path between the device and the subscriber. The IGMP
message is then passed to the PE device (PE4 in Figure 3).
PE4 also snoops the message, opens the path between itself
and the access device, and sends the message over the H-VPLS
instances to its neighbors. This process is repeated until R1
and R2 receive the IGMP membership request and a dynamic
path is created from both the querier (R1) and the non-querier
(R2), to the access device connecting the user to the network.
The extra path from R2 to the access device provides network
resiliency. The backbone router, which is the querier for the
aggregation network (R1), translates the IGMP message into a
PIM join message that is sent to the head-end of the network.
A multicast tree is set up and is then used to deliver the traffic
to the aggregation network and on to the subscriber through
the access device.
Snooping the IGMP message at each PE node sets up a path
between the backbone router that delivers the data stream to
the aggregation network (R1) and the PE device (PE4) that
indirectly connects the subscriber to the network. As a result,
the data stream does not travel further than it needs to around
the aggregation ring, thereby optimizing bandwidth consumption
on the ring. Second, the PE devices that perform the IGMP
snooping suppress membership and leave messages at the
point in the network where the branches of the path join
between the access device and the main path back to the
querier router for the aggregation ring. This reduces the
IGMP processing-load for the remaining PE devices and
routers in the network.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
> 12 ALCATEL
ResiliencyIf there is a link failure in the aggregation ring, the MPLS
fast reroute function repairs the break in the same way BTV
handles resiliency.
Other types of possible failures (e.g., R1as querier, PE1, R1-
PE1 link or PE device) are handled in a similar way as they
are for the BTV solution. The router that was in a non-querier
state for the aggregation network maintains a list of active,
multicast groups, based on the IGMP membership requests
it has received. When a failure occurs that causes the non-
querier (R2 before the failure) to lose contact with the querier
router (R1), R2 becomes the querier. R2 sends PIM join
messages to the multicast source of the network, based on the
list of active groups. This causes multicast trees to be built to
deliver the required multicast traffic. Because the PE devices
establish paths to both querier and non-querier routers when
the host sends the initial membership report, the path from the
new querier (R2) to the access devices is already established.
This ensures that the multicast traffic is delivered to the
correct access devices connected to the aggregation network.
ConclusionThe Alcatel 7750 Service Router and the Alcatel 7450 Ethernet
Service Switch platforms are ideally suited to deliver the
applications described in this paper, as well as a multitude
of other types of Layer 2 and Layer 3 services that are in
high demand today. The set of services supported by these
platforms include:
> Broadband Internet access for residential and business
users
> Broadcast TV
> Multicast-enabled application content
> Layer 2 VPNs (point-to-point and point-to-multipoint)
> Layer 3 VPNs (IP VPN, Alcatel 7750 SR only)
> Video on demand
> Voice over IP
> Business data applications
While enterprise-oriented platforms may be able to deliver
some of these services on a limited scale, they do not have
the service-oriented architecture that is inherent in the
Alcatel 7750 SR and the Alcatel 7450 ESS.
A service-oriented architecture is required to achieve the
scalability and wire-rate performance needed to deliver all
of the service types to thousands of customers on a single
platform. Both Alcatel platforms provide QoS capabilities for
each service that, when combined with the traffic engineering
characteristics of MPLS, allow the service provider to meet
the requirements of an SLA. The service assurance tools
available in these platforms allow the network operator to
quickly test new service instances during the turn-up phase
and rapidly resolve network issues that can occur during net-
work operation. Finally, the platforms’ accounting capabilities
generate accurate billing records for each service, ensuring
that service providers are able to maximize revenues from
network operations.
Networks based on the Alcatel 7750 SR and the Alcatel
7450 ESS provide numerous benefits to service providers
and customers.
Service Provider Benefits> High degree of network resiliency from sub-50 ms
SONET/SDH-like protection against node and link failure,
provided by MPLS fast reroute
> Reduction in operational complexity of the network by
replacing PIM with H-VPLS in the aggregation network
> Rapid resolution of network problems derived from a
comprehensive set of service-assurance capabilities
provided by the Alcatel 7750 SR and Alcatel 7450 ESS
> Improved network scalability, allowing the service provider
to deploy more customers on each PE device
> End-to-end, ATM-like QoS, allowing service providers to
meet the requirements of a multitude of service types,
including BTV
> Capacity to deliver a multitude of service types on
the same network, to thousands of customers
Customer BenefitsEnd customers enjoy channel-zapping response times that
are comparable to what they are used to with a conventional,
cable-based TV service. The intrinsic resiliency of the network
design ensures that TV viewers never have to worry about loss
of service while watching their favorite movie or TV program.
The Alcatel 7750 SR and 7450 ESS are ideally suited to deliver
BTV service. In order to realize all the benefits, the platforms
used to create the network must be fully service-oriented.
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
ALCATEL 13 >
AcronymsATM asynchronous transfer mode
BTV broadcast television
CPE customer premises equipment
DSLAM digital subscriber line access multiplexer
FIB forwarding information base
H-VPLS hierarchical virtual private LAN service
IGP interior gateway protocol
IGMP Internet group management protocol
IS-IS intermediate system-to-intermediate system
LAN local area network
LDP label distribution protocol
LSP label switched path
MAC media access control
MPLS multiprotocol label switching
MTU multi-tenant unit
OSPF open shortest path first
PE provider edge
PIM-SM protocol-independent multicast switching module
QoS quality of service
RFC request for comment
ROI return on investment
STB set-top box
VC virtual connection
VLAN virtual local area network
Delivery of Broadcast TV over a VPLS-Based Multicast Solution
Alcatel and the Alcatel logo are registered trademarks of Alcatel. All other trademarks are the property of their respective owners. Alcatel assumes no responsibility for the accuracy of the information presented, which is subject to change without notice. © 12 2004 Alcatel. All rights reserved. 3CL 00469 0726 TQZZA Ed.02 18847