We currently utilize the Verizon TLS (Transparent LAN Service) for our WAN. Each of our sites employs either a 1Gbps or 100Mbps Ethernet circuit. Each site also employs an ATM connection (various speeds) for an additional circuit at each site for redundancy.
Our current TLS product is the EMS offering which utilizes "Q in Q" stacking hence giving the TLS WAN a "flat/shared" look regardless of how many Dot1Q Layer 3 interfaces (we use 2 per site) that we use on the (edge) routers that connect to the TLS. We knew that QoS may be an issue on TLS as well so all of our VoIP rides over the ATM with TLS as a failover.
Our current challenge now is enabling multicast on the TLS network. However, by virtue of the Q in Q stacking, all sites on the TLS will get a copy of any multicast stream that is currently active due to the lack of any intelligence (i.e. IGMP snooping) in the TLS cloud. Although a site might not have a subscriber for the multicast stream, the edge router must still process the frame and drop it at the door step (router int). As you can imagine, the amount of multicast "noise" on the TLS could be exponential due to the lack of layer 2 / pruning intelligence in the cloud. Tag stacking (Q in Q) actually exasperates the problem.
I would like to know if anyone has any experience with this situation and what remediation measures may have been taken. We actually could try to force the multicast on the ATM but it's an incredible effort due to the possible RPF failures. We are also going to inquire into the TLS ERS offering that I believe provides EVC's (point to point) that may also help with QoS as well.
The TLS performance (speed) is unparalleled, however, but falls short in the QoS and multicast control arena.
Keith