experience of implementing iptv in an isp network by thong hawk yen
DESCRIPTION
TRANSCRIPT
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