A VPLS-Based Multicast Solution for the Delivery of ...mauigateway.com/~surfer/library/Delivery-of-Broadcast-TV-over-a-VP… · switching (MPLS) in the core of their networks for

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.


> 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.


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. ■


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-


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.


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.


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.


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.


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.


> 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.


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.


> 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.


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


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

Documents

A VPLS-Based Multicast Solution for the Delivery of ...mauigateway.com/~surfer/library/Delivery-of-Broadcast-TV-over-a-VP… · switching (MPLS) in the core of their networks for