4. 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
5. 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.
6. 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.
7. Challenges #3 – Traditional Multicast Did Not Fit
August 27, 2014 ConfidentialTemplate Presentation 6
MVPN
NG-
MVPN
mLDP MBPG
Draft
Rosen
8. Challenges #1 – Traditional Multicast Did Not Fit
August 27, 2014 ConfidentialTemplate Presentation 7
MVPN
NG-
MVPN
mLDP MBPG
Draft
Rosen
9. Challenges #1 – Traditional Multicast Did Not Fit
August 27, 2014 ConfidentialTemplate Presentation 8
MVPN
NG-
MVPN
mLDP MBPG
Draft
Rosen
???
10. Quick Glance at Draft Rosen
August 27, 2014 ConfidentialTemplate Presentation 9
IP Network
Forwarding Plane
GRE Tunnels
Signaling Plane
PIM
L3VPN
(multicast)
11. Quick Glance at NG-MVPN
August 27, 2014 ConfidentialTemplate Presentation 10
IP/MPLS Network
Forwarding Plane
MPLS LSP
Signaling Plane
MBGP / mLDP
L3VPN
(multicast)
Multicast was made
possible with the
implementation of P2MP
LSP
Multicast was made
possible with the
implementation of P2MP
LSP
12. Challenge #5 : IPTV Network Components
August 27, 2014 ConfidentialTemplate Presentation 11
er-01-glsfb
MX480
JUNOS 10.4R4.5
Primary Sender PE
(Upstream)
cum RP
Secondary Sender
PE ( Upstream )
cum RP
Receiver PE
(Downstream )
Receiver PE
(Downstream )
P2MP LSP
P2MP LSP
P2MP LSP
P2MP LSP
Secondary
Source
Primary
Source
IP/MPLS Core
PIM and eBGP BGP Signaled MVPN
GPON Access Network
STB
TV
L2 GPON
iBGP iBGP
iBGP
iBGP
RR
13. 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
14. 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
15. 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
16. Probing and Monitoring Is Required.
August 27, 2014 ConfidentialTemplate Presentation 15
17. How the Probe Works ?
• IGMP for all the channels.
• OOB for Probe Management.
August 27, 2014 ConfidentialTemplate Presentation 16
18. How the Probe Works ?
August 27, 2014 ConfidentialTemplate Presentation 17
Probe
sends IGMP
join msgs
Router
sends “PIM”
RP
RP 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
19. A Quick Glance at the Probe Output
August 27, 2014 ConfidentialTemplate Presentation 18
20. Probe Output Zoomed In
August 27, 2014 ConfidentialTemplate Presentation 19
IAT = Inter-Arrival
Time
MLR = Media
Loss Rate
Threshold
21. Today Agenda
• Challenges in Implementing IPTV in an ISP network √
• Dimensioning Concern
• Experience Sharing.
• Misconceptions
August 27, 2014 ConfidentialTemplate Presentation 20
22. Dimensioning Concerns
August 27, 2014 ConfidentialTemplate Presentation 21
Upstream link
SD channel is 2-3.5Mbps
HD 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
23. 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
24. Today Agenda
• Challenges in Implementing IPTV in an ISP network √
• Dimensioning Concern √
• Experience Sharing.
• Misconceptions
August 27, 2014 ConfidentialTemplate Presentation 23
25. 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
26. Today Agenda
• Challenges in Implementing IPTV in an ISP network √
• Dimensioning Concern √
• Experience Sharing. √
• Misconceptions
August 27, 2014 ConfidentialTemplate Presentation 25
27. 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
28. The probes is asking all the channels all the time.
August 27, 2014 ConfidentialTemplate Presentation 27
Probe
sends IGMP
join msgs
Router
sends “PIM”
RP
RP 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
29. Other reference
1. draft-ietf-l3vpn-2547bis-mcast-07.txt
2. ietf-l3vpn-2547bis-mcast-bgp-05.txt
3. 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
30. Appreciations go to individuals who have
contributed to the design and the build of
NG-MVPN architecture.
