Anyone using ASM (versus SSM) for IPTV? If so why?
thanks,
mike
Dear Mike;
Anyone using ASM (versus SSM) for IPTV? If so why?
From what I understand, the answer is likely to be "yes" and the
reason is likely to be "deployed equipment only
supports IGMP v2."
Regards
Marshall
Marshall,
Dear Mike;
Anyone using ASM (versus SSM) for IPTV? If so why?
From what I understand, the answer is likely to be "yes" and the
reason is likely to be "deployed equipment only
supports IGMP v2."
Agreed. I'm seeking confirmation, from IPTV implementers, that non
igmpv3 support is the reason for using ASM with IPTV. Versus other
reasons such as reducing state. Or is this a non issue and everyone is
using SSM with IPTV?
thanks,
mike
Mike,
To my knowledge in most today's networks even if legacy equipment don't support IGMPv3 most likely 1st hop router does static translation and SSM upstream.
The reason not to migrate to SSM is usually - ASM is already there and works just fine 
Cost to support RP infrastructure is usually the main non-technical factor to not to use ASM.
Would be interested to hear from the SPs on the list.
Regards,
Jeff
SSM is also used since we *know* the IP addresses of the content
servers that are the sources - You dont need ASM. I dont think
maintaining RP infrastructure is trivial. Who wants to deal with
register packets, etc. Small routers punt all registers to CPU and
them forward them in SW.
In fact there was a draft which proposed using MPLS encapsulation in
networks that support MPLS to replace the existing RP mechanism.
From the draft:
Encapsulation and Decapsulation are expensive operations for routers
and the latter, especially, as it entails a double lookup that many
routers cannot do in hardware. It is for this reason that several
off the shelf chips do not support decapsulating the PIM Register
packets. Any router that cannot decapsulate the PIM Register packet
in hardware must send all this traffic to CPU, where its
decapsulated, and forwarded based on the multicast forwarding table.
This increases the load on the CPU and also makes the router
susceptible for DoS attacks. Also, since Register packets are
unicast, then can be easily spoofed and an attacker can use this to
attack the router and thus the network.
This document attempts to solve the above problems by doing away with
the PIM Register packets. It instead proposes using an MPLS tunnel
to send all multicast data traffic till an SPT is formed. This
eliminates the complexity of decapsulating PIM register packets on
the RP as it now only needs to pop off the MPLS labels before
forwarding the native packet down the RPT.
Looks like the draft died some time back ..
Glen
Isn't source discovery and efficiency a big concern for ASM? If individual
streams are tied to a specific source then it's possible to live without
some of the overhead involved in ASM. Joins go straight to the source,
traffic is disseminated via direct paths instead of being replicated by the
RP, etc etc..
Disclaimer: Other than being a lab rat I haven't done much with multicast
in the wild.
That and numerous clients which don't know anything about SSM.
Antonio Querubin
e-mail: tony@lavanauts.org
xmpp: antonioquerubin@gmail.com
This is true for us - the broadcaster whose IPTv traffic we
carry supports only IGMPv2. This makes SSM a no-no, but we
aren't really complaining about having to use PIM-SM either.
Mark.
We are running NG-MVPN (BGP replaces PIM, MPLS replaces
IP/GRE).
We run PIM-SM, not only because our customer's STB's only
support IGMPv2 (we only transport IPTv content, not generate
it), but also because, well, it just works and there hasn't
been any compelling need to push for PIM-SSM.
It's scaling well due to the nature of the NG-MVPN
infrastructure itself.
Mark.
To my knowledge in most today's networks even if legacy
equipment don't support IGMPv3 most likely 1st hop
router does static translation and SSM upstream.
Yes, SSM Mapping allows for PIM-SSM to be used in a network
where the receivers don't support IGMPv3. But it tends to be
static in nature, although both Juniper and Cisco suggest
that dynamically-configured options are possible.
I couldn't quite decode the Juniper dynamic method, but the
Cisco one appears to be based on DNS. That should be
interesting (and a colossal screw-up if things are poorly
maintained):
The
reason not to migrate to SSM is usually - ASM is already
there and works just fine
This is our case.
Cost to support RP
infrastructure is usually the main non-technical factor
to not to use ASM. Would be interested to hear from the
SPs on the list.
For us, the cost of the RP isn't an issue. The Sender PE
routers (in NG-MVPN speak, the ISP's routers that are
connected toward the Source) are also the RP's.
But due to the use of NG-MVPN, and how we designed our
Multicast backbone, there really isn't any need for the
Receiver PE routers to contact the RP whenever a customer is
joining a group.
BGP has been extended to handle PIM messages in NG-MVPN.
When a Source is discovered by the Sender PE router, it
generates a Type 5 SA-AD (Source Active, Auto-discovery)
BGP update route which is sent to all Receiver PE routers
participating in the MVPN. This Type 5 route is generated
from the PIM Register state that is created by PIM running
between the Sender PE and CE routers.
If the Receiver PE router is configured to operate the MVPN
in the SPT-only mode, it generates a Type 7 (C-S,C-G) route
for every Type 5 route it received, effectively creating the
necessary state in the local Receiver PE router. Once
customers send (*,G) IGMP reports requesting to join
Multicast groups, that state is already present on the
Receiver PE router, and traffic starts flowing immediately
downstream.
If the Receiver PE router is configured to operate the MVPN
in RPT-SPT mode, it will follow regular PIM mecahnisms when
users are trying to join groups, i.e., Join messages are
forwarded toward the RP along the RPT, and then Multicast
traffic forwarded along the SPT once the correct (C-S,C-G)
state is created locally.
The above explanation is somewhat simplified, but represents
the general architecture of how things work in NG-MVPN's.
For us, SPT-only mode makes sense because we have IPTv
probes attached to all Receiver PE routers; and since
they're collecting telemetry for all IPTv channels, no point
running the RPT-SPT mode.
Please note that this whole setup doesn't require MSDP,
which is nice!
Cheers,
Mark.
SSM is also used since we *know* the IP addresses of the
content servers that are the sources - You dont need
ASM. I dont think maintaining RP infrastructure is
trivial. Who wants to deal with register packets, etc.
Small routers punt all registers to CPU and them forward
them in SW.
Our Sender PE routers double as our RP's. These are Juniper
M320's and T320's today.
Yes, a Tunnel PIC is required on the Juniper's (although you
might find it interesting that if you're running PIM-SM for
IPv6 on Sender PE routers, you don't need a Tunnel PIC;
however, if you have an IPv6-based RP, you need a Tunnel
PIC).
Juniper MX routers don't require a Tunnel PIC, as those are
integrated into their DPC and MPC line cards.
Our customer is using Cisco ASR1000 routers as Sender CE
routers, and PIM Registers are encapsulated/decapsulated in
hardware on those platforms.
But I do agree that it does add overhead.
In fact there was a draft which proposed using MPLS
encapsulation in networks that support MPLS to replace
the existing RP mechanism.http://tools.ietf.org/html/draft-bhatia-pim-mpls-register
-packets-00
This quite interesting, I hadn't heard of this one before,
although I'd always wondered why something like this wasn't
already implemented.
My main issue with this proposal is that if the Sender CE
router is not part of your network, i.e., your customer, a
partner network, e.t.c., it requires that your MPLS domain
be extended toward them. It's not impossible, but not
typically common.
Also, it would be good to support both LDP and RSVP, and not
RSVP only.
Maybe I should contact the author to see if the project can
be revived.
Cheers,
Mark.
In our case, Source discovery happens once, and BGP updates
containing that information is sent to all Receiver PE
routers in the MVPN.
They then generate Type 7 routes locally (due to running
SPT-only mode), which are essentially (S,G) routes.
Once a customer sends a Join message to subscribe to a
group, the Receiver PE router just serves it locally. No
need to send any requests back to the RP.
This breaks regular PIM mechanisms, but is a welcome
deviation that makes a lot of sense.
One does have the option of running RPT-SPT modes which are
akin to regular IP Multicast.
Mark.
With SSM Mapping, they don't need to.
Mark.
For example Apple products don't support IGMPv3.
For example Apple products don't support IGMPv3.
Implemented at last in 2011 (!) under OSX Lion, 10 years after Windows XP...
$ sysctl net.inet.igmp.default_version
net.inet.igmp.default_version: 3