Control network IP scheme change and automation

[Scott Norwood]

Coming into this a bit late, from an IT/network background: any RFC1918 address space is fine to use. I think that I would be inclined to shy away from using 192.168/16 space for two reasons, but not because of security (as noted above, it makes no difference). The first would be that many new devices come with default addresses in the 192.168/16 space. If someone decides to plug a random new whizzy-bangy device into the cinema network, there is a chance for creating an IP conflict. The second would be similar: if there is ever a chance that people might connect to the cinema network over a VPN, there is a risk of conflict, as most home networks use the 192.168/16 space. At the very least, I wouldn't intentionally use 192.168.0/24 or .1/24. Steve's idea of starting at 192.168.101 is a good one.

I've not set up a cinema network from scratch, but most of the ones that I have seen use the Dolby numbering scheme. DHCP is generally a bad idea in a fixed network, although the DHCP server can be configured to repeatedly give the same IP address to a particular device. The problem comes when (not if) the DHCP server fails or runs out of leases. It is possible to set up multiple redundant DHCP servers and work around the other issues, but this is unlikely to happen in a cinema environment. Given the lack of on-site IT people in the typical cinema, simpler is better, and the system should be designed so that failure of one screen's projection system does not take out other projection equipment, cash registers, etc.

[Mark Gulbrandsen]

Scott, I talked to my friend last night who is down in Huntsville, and what you said is exactly why he told me that. He said use anything BUT what equipment comes defaulted to.

[Steve Guttag]

Exactly! That is why I moved Dolby's IP scheme to 100+ theatre number though, if I had to do over again, I'd also move the Theatre network too just to avoid there ever being two theatre 1s.

Where I use Class-C networks (QLAN), you'll note it isn't any of the typical defaults for any piece of gear. Since Q-LANs are inherently on their own and often without a gateway...if you aren't physically connected to their network, you aren't on them anyway...so again, "safe." If you are in the booth and physically connected, there is going to be little I can do to stop you anyway (the hacker could unplug a core and plug his computer directly to the core and skip whatever IT block you may have had...there is the password that one can put into a CORE but...I've taken the approach that other techs have to do their jobs too (particularly for screenings) so again, if you are physically in the booth, you can pretty much have at it. I even leave notes in the QSYS design to help the outside tech. Something I'll probably work into my screening room designs, and possibly the rest are "my B-chain" and a guest-tech B-chain. It would be relatively easy to do so going back to the house-tuning would be instant.

[Bruce Cloutier]

Do you guys simply list the IP address assignments for a site? I don't suppose you've been successful trying to graphically represent a topology? Just curious.

Our's is really dynamic as populations of JNIORs ebb and flow at the facility.

I had thought to combine JNIOR core logic with a 4/8/12 port switch/hub. Then those devices can play more of a role maybe by just identifying physical ports in routes to a device? Maybe in trapping IP conflicts or malicious access attempts? I don't know. It just seems it would be interesting if you could add monitoring/control custom software to an otherwise invisible hub. It could provide a smart version of POE or switch power to devices with the relays? The JNIOR already performs network packet capture.

I know that there are more expensive managed switches that you probably prefer to use that do QoS and all of that. The concept just comes up now and then.

Just thinking.

[Steve Guttag]

I can't speak for others but I presume they are similar with their schemes. I have a set of Excel spreadsheets that have the scheme on them. Put in the base IPs for Management and Media and it fills in the rest. All one has to do is look at the theatre number and the device and the IP is there.

As for topology. It really is just two concentric rings. one is management and the other is media and never do the two touch (except maybe at a TMS rack where a separate VLAN is set up so one can configure or monitor the Media switch. Each screen will have its collection of devices that are all on the management network and, as such will have its own network switch sized to work with that screen. You wouldn't put everything on a single large switch in the TMS rack since if that failed, your whole complex stops. This way, if the TMS rack goes down or the management switch fails, each theatre becomes its own island until the TMS system is restored but the shows continue to run.

The media switch is typically just one large one for the complex as the TMS is what causes content to move about anyway and more hops just slows down the process. Furthermore, it is typical to have 10G or better feeding that switch and 1G or better to each theatre so multiple pieces of content can move about.

As of QoS. For cinema, that hasn't come up yet except for things like Q-SYS where audio is traveling over IT and it is essential for there to be a priority given to it. If people start moving video/audio over IT then it will come in there too. For now, I will only do Q-SYS if it is on its own network and does not share a switch with any other IT. The cost of switches are cheap compared to dropping audio in a show.

[Greg Routenburg]

My approach to ethernet switching in my recent designs have relied heavily on VLANs to differentiate between networks with 10G trunks between them. I've just put in enough switchports at each location to handle what is required for that section of the building. The exception to that is for the projection auditorium switches. Each auditorium has a 24 port switch dedicated to it to so that if a single switch fails, it doesn't affect the automation for multiple screens. This approach allows for maximum flexibility within the complex to locate equipment as necessary. For example, where we have a boothless installation, the TMS may be in the manager's office so we need both Media and Management VLANs accessible to that room. Rather than running dedicated runs back to a core management or media projection switch, they just connect to the closest switch to the office and trunk back to where they need to go. If a run goes bad or a switchport fails, you can patch into any spare port in the room and reconfigure the switch as necessary to re-establish connectivity. I think when I eventually install a QSYS system, I will do as Steve suggests and have dedicated infrastructure and switches for that purpose. There's really no drawbacks to that approach and it's robust as hell.

[Steve Guttag]

Greg, please note people do, particularly in A/V, run Q-SYS on the same IT as the rest and rely on VLANs, QoS and IGMP to ensure safe/speedy passage of the audio. I won't do that on my designs. Partly due to my weakness on IT but also because, as I said, switches are cheap, interrupted audio, particularly on multiple screens isn't. It is a cost/risk thing. As Video over IT becomes more of a thing I think there is another potential network. It can be very bandwidth demanding (depending on resolution, frame rate, color depth...etc). The people at MIT have done such a system with Q-SYS, Visionary Solutions Video over IT) plus the usual DCinema requirements.

-Steve

[Sean McKinnon]

I have done a system where I have three screens running on two core 510c's with DCIO's in each house and a centralizedAudio and DM video matrix utilizing Q-Sys Cameras, Shure ULX-D Wireless over Dante, The Q-Sys streaming appliance, ioflex8's, Spy Mic's in each house, Q-Sys Amps, plus 35mm film in one house, 16mm in another (using an AVIO flex to transport the 16mm audio) and various other analog and digital I/O for audio and video. You can route any audio or any non D-Cinema video to any house (or display each screen has two preview displays and the "central" rack has a triple rack mount display.

I prefer to use Luminex Switches Connected by Fiber and the following VLAN's in these type of installs;

VLAN A- Q-LAN A
VLAN B- QLAN B
VLAN C- DANTE PRI
VLAN D- DANTE SEC
VLAN E- Mangement (Control)
VLAN F- Content

The luminex switches make setting up VLAN's very easy and they transport all Vlan's on one fiber pair (I like to use single mode cresfiber for both data and video) with the second a "hot spare" that will give instant failover. I also subnet each VLAN which i guess is kind of redundant but allows me to connect one PC with different NIC's and be able to see multiple VLAN's at once.

I have also done other single screen installs using the same typical network layout for large performing arts type venues.

[Steve Guttag]

Very impressive Sean! I take it, at your central audio area, the switch is essentially just fiber ports going to each theatre (though with just three screens, probably you have a switch with at least 4 fiber ports on it).

In Q-SYS 8.3.x, I believe we are to see our first software Dante so that might change things for you if the bulk of your Dante is just microphones. And, with QSC dropping the "n" series of amplifiers, I see an abundance of Inputs becoming available for "included." Too bad they don't make those amplifier inputs into "flex."

[Greg Routenburg]

Greg, please note people do, particularly in A/V, run Q-SYS on the same IT as the rest and rely on VLANs, QoS and IGMP to ensure safe/speedy passage of the audio. I won't do that on my designs. Partly due to my weakness on IT but also because, as I said, switches are cheap, interrupted audio, particularly on multiple screens isn't. It is a cost/risk thing.

Steve, I didn't say it wasn't do-able. I'm just a bit of a control freak about my network infrastructure and I don't fancy needing to grant a sound tech access to the rest of the complex should they need to make any modifications to the sound system. By having all of the switching completely separate for audio, any Q-Sys tech could come and do what they need to do without needing to involve IT. I also agree with you about the cost/risk assessment. What's an extra couple/few switches in the grand scheme of things.

[Scott Norwood]

Using separate switches for sound systems makes sense to me. In principle, separate VLANs should be sufficient to isolate different types of traffic, but that won't prevent some random person from, say, rebooting an entire switch because he thinks that doing so will fix an unrelated computer problem (which it probably won't) and taking all of the cinema sound with it. Same for Greg's point about not wanting to give a sound technician access to the theatre's other IT infrastructure.

All of this actually makes a typical multi-screen cinema an interesting networking excercise. I can imagine needing separate VLANs or physical networks for cash registers/box office, digital cinema, TMS, manager's office/Internet access, screen advertising, credit card machine (if not part of the cash register), networked audio, possibly some VoIP circuits, and maybe a VPN to the home office and/or NOC. The good part is that most of this stuff doesn't change regularly, so it can be set up once and left alone.

[Sean McKinnon]

Steve, Each screen has a primary (Qlan A/Dante Pri/Mgmt) and back-up (Qlan B/Dante Sec/Mgmt/Sec) 26 port Luminex Switch with redundant fiber to each switch and two spares so we ran six fibers to each sound rack. The central rack is the same with two switches. The central rack has the DM16X16, Mac Mini, USB I/O, I/O Frame with Dante Card, Wireless Mic Receiver. The wireless mic antenna is daisy chained with amplifiers so any of 4 mic's can be used in any or all theatres.

QSC touts the ability for Q-Sys to live on a regular corporate network.

[Steve Guttag]

Sean, they tout a lot of things!

Scott, it should be noted that if one is using a networked audio like Q-SYS, only a fool would not have redundant networks (as is provided by Q-SYS) to ensure the mere rebooting of a single switch could not take down the audio network...the redundant network would take over with a zero transfer time (it is always active). Heck, even the COREs themselves can (and should) be configured in redundant mode so that losing one CORE won't take down the complex. Many people also still use separate COREs per theatre, like a conventional sound processor but the networks are connected to provide audio transfers.

The only networks I have running around the booth are the management/control, Media (movie content) and Q-SYS (both QLAN-A and QLAN-B). Nobody from the booth has any access to any other part of the theatre. Likewise the rest of the theatre doesn't have any access to the booth...EXCEPT via our firewall router. One port on that is for the manager to have access to necessary parts of the booth equipment but that is only opened up to what ports are needed and what sorts of traffic and what IPs. So you can give them VNC to their servers, or POS schedule transfers to the TMS, remote clients to the TMS...etc. They get to do their work seamlessly but the firewall acts as the go between and keeps everyone where they should be. So, at present, I can have up to four runs of copper around the booth tagging each theatre to a central area for the sound and TMS. At the TMS, there will be another copper for WAN (internet) access and another run of copper to the manager's computer network to allow POS and their control/monitoring of the booth. What is allowed on that run is by us and, quite frankly, their IT person since restrictions and be placed at both ends.

[Scott Norwood]

In that case, with a redundant network, it's probably fine to not do separate switches for Q-sys, but I'm not knowledgeable about its special requirements.

So, how does cinema networking happen in practice now? Does the typical building get completely different networks installed by the projection/sound vendor, box office system vendor, office computer vendor, etc., each supplying its own preferred make and model of switches and routers? That seems like needless duplication, but maybe the support issues and lack of finger-pointing among vendors makes it worthwhile. I suppose that the box office computer company doesn't want to get calls about why there is no sound in cinema #4 and such.

Interesting times, i guess.

[Steve Guttag]

I cannot speak for everyone, naturally, but from my experience...the booth network(s) are as I describe them as completely separate from the rest of the complex. If you think about it, Scott, the chief idea of the booth networks is zero glitches or downtime. Nothing from outside of the booth is so important that it should imped upon that. Likewise, given the size of the media transfers (if it takes say 20-40 minutes to move a movie and you have a 10 plex with all sorts of ads and new features moving about, why would you want that to take any slow down by having to share a wire with something else?...copper is cheap (relatively speaking), time and glitches are not. I could definitely see things changing as fiber becomes more prevalent and 10G networks/trunks go into use. Then again, most of the communication within a booth is not in any particular rush (e.g. a command to send the sound to 6.5, in terms of network speeds, if it happens milliseconds late is imperceptible. Dropping packets of sound or missing a timing restriction, would be instantly noticed.

Now, some companies, like GDC, are working on and have implemented a "streaming" system whereby their TMS/LMS system is a large storage and streams the media to each screen. So content transfers (ahead of the show) are non-existent really. You could run a movie in theatre 1 on the first set and theatre 5 on the second set and the content is essentially there instantly. Naturally, you'd want that network unencumbered. Least you think they've thrown all caution to the wind, each of their servers has (at present and it keeps getting larger) 1TB of "cache" storage so if a piece of content has already streamed, particularly features, that server will have it in cache until it has to make room for newer content (FIFO) so the server need not consume network/switch bandwidth for content it already has. It also means that if the TMS fails, the individual theatres can still run with whatever content they already have until the network/TMS/LMS can be fixed.

As for the rest of the theatre...I would never want the booth system to have ANY connection to a credit card or like system as that has its own security issues. As I said before, the single link between the booth an the rest of the theatre can be individually set up to prevent either side from getting into trouble and yet be transparent to the manager/user.