[c-nsp] IPTV and MPLS

[netman]

You guys are awesome with these responses. I appreciate the detail that has 
been in these posts.

SSM is one of the things I was looking at. Out STB's do not support it as 
far as I know. The static IGMP joins would mean that all the channels are 
always provided on the network.

Is your SSM static type mappings?

I was looking at it as a way to make sure another source did not show up on 
our network with the same multicast address as one of our channels and screw 
up that channel.

Thanks

Don Hickey

----- Original Message ----- 
From: "Asbjorn Hojmark - Lists" <lists at hojmark.org>
To: "'netman'" <netman at oneidatel.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Thursday, February 01, 2007 5:08 AM
Subject: RE: [c-nsp] IPTV and MPLS


>> Our pre-sales engineer told me I should not run our multicast
>> traffic in a vrf instead it should be in the global routing
>> table.
>
> If you don't have to run multicast traffic for multiple different
> customers in the same network, there isn't much point in running
> it in a MVPN. All you get is multicast encapsulated in GRE and
> sent on a (different) multicast group.
>
>
>> Are their any members here running IPTV and if so could you
>> give me a brief on how you have this type of network
>> configured?
>
> I have a customer running IPTV (5-600 Mbps) in the global table
> and that works fine (6500/7600/12000). That's a SSM setup with
> SSM mapping and static IGMP joins at the edge.
>
> It sounds like you're providing the same IPTV feed to different
> customers, and in that case I'd probably chose a simple setup as
> the above.
>
> We also have a customer running IPTV (~200 Mbps, AFAIK) in MVPN
> and that also works fine (7600/12000). That's also SSM but, as I
> said, with MVPN on top. The reason it's run in MVPN is because
> they want the option to carry IPTV from multiple content
> providers in the future.
>
> I know of at least one network here in Denmark where they run
> IPTV from different content providers in different MVPNs, also
> with hundreds of Mbps (500+), but I don't know how well it works
> for them.
>
> -A
>
>