Experience of Implementing IPTV in an ISP Network by Thong Hawk Yen

Experience Implementing IPTV in an ISP Network

Thong Hawk YenMyNOG – 4 August 2014

Time dotCom Bhd Confidential

Today Agenda

• Challenges in Implementing IPTV in an ISP network• Dimensioning Concerns• Experience Sharing• Misconception

August 27, 2014 ConfidentialTemplate Presentation 1

The Requirement

August 27, 2014 ConfidentialTemplate Presentation 2

Simple Requirement – Multiple Challenges

1. No references within Malaysia, no experience. 2. Plenty of choices and variances in terms of technology. ( in fact too many )3. Multivendor challenges. 4. Traditional multicast ( PIM over IP ) did not fit.5. Platform Requirement.6. Service testing – New network was not up, early adopters were in the field.7. 3rd party content. 8. Much more stringent latency/ jitter requirement than other IP/MPLS

applications.

August 27, 2014 ConfidentialTemplate Presentation 3

Challenge # 1/2 : No real life reference. No experience. To many variances.

• YES, there were references. BUT they were our competitors. • Other sources white papers and RFCs. • Vendors implementation documents. • Conference papers from SANOG and NANOG.• Most resources and reference were not multi-vendors. • Research, research and research.

August 27, 2014 ConfidentialTemplate Presentation 4

And a lot of tests.

Challenge #3 :Why Multivendor ? (Why make your life difficult ?)

Pros

• Wider choice of hardware selection • Allow for feature comparison across

different platforms.• Keeping price down.

Cons

• Issue involving 2 or more vendors may result gray areas.

• Inter-op test takes longer time. • More complex engineering skill

required.

August 27, 2014 ConfidentialTemplate Presentation 5

• It is our tradition ( it is our way of life ). • Old network were also multivendor • We believe the Pros outweight the Cons.• Just a matter of preference.

Our Direction.

Challenges #3 – Traditional Multicast Did Not Fit

August 27, 2014 ConfidentialTemplate Presentation 6

MVPN

NG-MVPN

mLDP MBPG

Draft Rosen

Challenges #1 – Traditional Multicast Did Not Fit

August 27, 2014 ConfidentialTemplate Presentation 7

MVPN

NG-MVPN

mLDP MBPG

Draft Rosen

Challenges #1 – Traditional Multicast Did Not Fit

August 27, 2014 ConfidentialTemplate Presentation 8

MVPN

NG-MVPN

mLDP MBPG

Draft Rosen

???

Quick Glance at Draft Rosen

August 27, 2014 ConfidentialTemplate Presentation 9

IP Network

Forwarding PlaneGRE Tunnels

Signaling PlanePIM

L3VPN(multicast)

Quick Glance at NG-MVPN

August 27, 2014 ConfidentialTemplate Presentation 10

IP/MPLS Network

Forwarding PlaneMPLS LSP

Signaling PlaneMBGP / mLDP

L3VPN(multicast)

Multicast was made possible with the

implementation of P2MP LSP

Multicast was made possible with the

implementation of P2MP LSP

Challenge #5 : IPTV Network Components

August 27, 2014 ConfidentialTemplate Presentation 11

er-01-glsfbMX480JUNOS 10.4R4.5

Primary Sender PE(Upstream) cum RP

Secondary SenderPE ( Upstream )cum RP

Receiver PE (Downstream )

Receiver PE (Downstream )

P2MP LSP

P2MP LSP

P2MP LSP

P2MP LSP

SecondarySource

PrimarySource

IP/MPLS Core

PIM and eBGP BGP Signaled MVPN

GPON Access NetworkSTB

TV

L2 GPON

iBGP iBGP

iBGP

iBGP

RR

Challenge #5 : Platform Requirements

Some important criteria but can be easily missed are as follow :

• PE router : Junos with 8.5 or later that can support P2MP LSP• RR : Any model that support L3VPN signaling ( VPNv4 in Cisco term )

with BGP multicast VPN signaling. • Core : Juniper M320 or Cisco CRS that is P2MP LSP aware.

August 27, 2014 ConfidentialTemplate Presentation 12

Challenge #6 : Service Test

• Lab test was not good enough.• POC with real traffic and customer raise confidence level. • Real test with a couple of hundred customer in the field on voluntary basis. • Carefully carve out test customers with VLAN separation.• Months of gathering customer feedback and fine tuning. • Customer is good but it is not scientific that led us to our next challenge.

August 27, 2014 ConfidentialTemplate Presentation 13

Challenge # 7/8 : 3rd Party Content and Stringent Performance Requirement

• Eye-ball quality assurance were note enough for commercial delivery of the IPTV service.

• Probing at various point in the network were required.• Probing at ingress to the IP/MPLS network.• Probing at egress of the IP/MPLS network. • Probing at the customer ( only when problem was reported by that

customer )

August 27, 2014 ConfidentialTemplate Presentation 14

Probing and Monitoring Is Required.

August 27, 2014 ConfidentialTemplate Presentation 15

How the Probe Works ?

• IGMP for all the channels. • OOB for Probe Management.

August 27, 2014 ConfidentialTemplate Presentation 16

How the Probe Works ?

August 27, 2014 ConfidentialTemplate Presentation 17

Probe sends IGMP join msgs

Router sends “PIM”

RPRP sends PIM join source

Source sends IPTV

traffic

Ingress router tag MPLS

label sends in P2MP LSP

Egress router removes MPLS label and sends to probe

Probe digests multicast data and send unicast

report to NMS

A Quick Glance at the Probe Output

August 27, 2014 ConfidentialTemplate Presentation 18

Probe Output Zoomed In

August 27, 2014 ConfidentialTemplate Presentation 19

IAT = Inter-Arrival Time

MLR = Media Loss Rate

Threshold

Today Agenda

• Challenges in Implementing IPTV in an ISP network √• Dimensioning Concern• Experience Sharing. • Misconceptions

August 27, 2014 ConfidentialTemplate Presentation 20

Dimensioning Concerns

August 27, 2014 ConfidentialTemplate Presentation 21

Upstream link SD channel is 2-3.5MbpsHD channel is 9Mbps

Subnet size depends on how many

customer can each access node handle

Increases as the number of channels

increases.

Licensing for the probes

Special Hardware for tunnels

L3VPN license

Dimensioning Concerns - continued

August 27, 2014 ConfidentialTemplate Presentation 22

QoS bandwidth allocation for EF

Subcriber license scale DHCP relay.

Routing table size.

Fiber splitting ratio

Today Agenda

• Challenges in Implementing IPTV in an ISP network √

• Dimensioning Concern √

• Experience Sharing. • Misconceptions

August 27, 2014 ConfidentialTemplate Presentation 23

Experience Sharing

• Minimum requirement for NG-MVPN at the PE is Junos 8.5 but there is still improvement in 11.4 for NG-MVPN in some specific area.

• Some IPTV quality issue was resolved by making sure fiber readings at each links ( cable and SFPs ) were clean to make sure it is not point to consider when troubleshooting IPTV quality issue.

• Selection of probing solution was critical. Need to be on the same page with the content provider.

• SLA standards – DVB’s ETSI TS 102 034 • SLA setting – Provide opportunity to benchmark and increase level by at

least 2 phases.

August 27, 2014 ConfidentialTemplate Presentation 24

Today Agenda

• Challenges in Implementing IPTV in an ISP network √

• Dimensioning Concern √

• Experience Sharing. √• Misconceptions

August 27, 2014 ConfidentialTemplate Presentation 25

Misconception

• Multicast network is very bandwidth efficient protocol. Bandwidth is required only when there is a downstream IPTV client requesting for that channel. YES BUT NOT QUITE.

August 27, 2014 ConfidentialTemplate Presentation 26

The probes is asking all the channels all the time.

August 27, 2014 ConfidentialTemplate Presentation 27

Probe sends IGMP join msgs

Router sends “PIM”

RPRP sends PIM join source

Source sends IPTV

traffic

Ingress router tag MPLS

label sends in P2MP LSP

Egress router removes MPLS label and sends to probe

Probe digests multicast data and send unicast

report to NMS

Other reference

1. draft-ietf-l3vpn-2547bis-mcast-07.txt2. ietf-l3vpn-2547bis-mcast-bgp-05.txt3. http://www.juniper.net/us/en/training/jnbooks/day-one/junos-learning-sphere/vday-one-intro-bgp-multicast-vpns/4. http://www.sanog.org/resources/sanog14/sanog14-amitdash-multicast-vpn.pdf

Time dotCom Bhd Confidential

Appreciations go to individuals who have contributed to the design and the build of

NG-MVPN architecture.

Thank you&

Question