Information from ILDA Technical Committee chair Dirk Apitz, February 2017

Let's start with the IDN message. Before I decided to go with a new protocol, I studied existing protocols, file formats, concepts etc. After a dozen or so - I gave up. Too complicated, too limited, too hard to synchronize, not adaptable, too expensive, in need of special hardware.

I figured out that it had to be modular and it had to be versatile since the laser business is a rather small market and implementing different protocols and formats would just raise development cost. Further, it had to be somehow packetized to allow for multiplexing, storage and transport across switched networks - and - it had to cover everything from hobbyist to professional, show to industrial applications.

Together with the Technical Committee, we ended up in what ILDA standardized as the IDN Message. In particular the IDN Channel Message that is defined in the IDN-Stream standard. With the generic IDN Message, there has been some space reserved that will be needed in other related standards. So, for now, let's focus on the IDN Channel Message.

Sometimes, people say that IDN is not finished. Well - I would say that this is a question of angle of view. Sure, network and file standards are in draft or under development - but the main part is there. It's the part that describes the codec. The description of how to put laser content into little, handy data packets that can travel across networks or be stored in files. While the rest is important too - essentially - it's 'just' about how these packets are dealt with. As long as IDN Channel Messages are handled nicely and kept in order - the (laser or media) content stays intact no matter of where these messages are stored or how they are transported.

That said, the planned formats are essentially just a standardized way of communicating - but IDN Channel Messages could live everywhere from database or proprietary file to cloud to cable. Plain or encrypted, secure or obfuscated.

The most important concept of the IDN Channel Messages is the timestamp. Every channel message has one. This timestamp has a resolution of 1 microsecond and is 32 bit wide, covering more than one hour. It is defined to be relative though, meaning that only the difference between the timestamps of consecutive channel messages is taken into account. This has the advantage of an arbitrary start point (especially useful in case of lost communication) and infinite playback (wraps get irrelevant).

With this concept of timestamps, another large problem is solved very nicely too. Synchronization across multiple distinct data streams, eventually carrying different media types like Laser, Effects, DMX512, Audio, MIDI or Video since all that has to be done is processing the messages in ascending order of their timestamps.

Other key concepts include packetizing and multiple simultaneous channels. Packetizing is useful just about everywhere since just about all scenarios use multiplexing, switched networks, frames, blocks or sectors. Essentially, in case you wanted to store or transfer a continuous waveform, it has to be packetized unless you have LP's, tape, dedicated links or such in mind. So - going for packets (or messages in IDN wording) makes the protocol very versatile. Further, the support for multiple simultaneous channels on protocol level makes IDN Channel Messages powerful and future proof.

Regarding laser projection content, the challenge was to define a data representation that covers all professional use cases but stays with moderate complexity - keeping simple implementations in mind. The outcome is a representation that is superior to all other formats as it arbitrarily scales in frequency, precision and signal count (sample size). 16, 24 or 32 Bit on your X/Y - no problem. 16 Bit on your colors - no problem. Frequency of 100 kHz or 250 kHz or 1 MHz - no problem. Stereoscopy - no problem. Further signals like BeamBrush - no problem. Sample-Synchronized output for multi head projectors - no problem.

Information from ILDA Technical Committee chair Dirk Apitz, February 2017

IDN is an open standard. There is a publicly available document describing it. It was developed in the ILDA technical committee - and voted on and adopted by the ILDA membership in Dubai 2015. Opposed to an open standard like this there are proprietary implementations. These are usually secrets of people or companies. Best you can get there is access by signing NDAs (Non-Disclosure Agreements).

This might not bother you as long as everything works fine, you're satisfied, features are sufficient and your relationship to the manufacturer is good. It turns into a headache, once something breaks though. You might find yourself in dreaming of other solutions, searching for workarounds or fooling yourself by glossing over the situation.

Even worse - how about a company closing down or being taken over or discontinuing a product? How about operating system upgrades/changes? How about changed business that leaves you in need of some special features that your setup doesn't provide? Or - how about you wanting to watch your old shows on future hardware - in - say 20 years from now?

But - stop - isn't it your time and inspiration that you put into your artwork, shows and programming? You're the owner - right? So - why is it that you can't just access it with different products to reach your goals and expectations?

Open standards allow for that. As an example - think of OpenOffice or pdf - or the Internet Protocol. There is more than one editor, viewer - or program in general being able to use these formats.

Information from ILDA Technical Committee chair Dirk Apitz, February 2017

One concern expressed about IDN is “My work is unprotected and can be stolen.”

Well - there is a slight difference between security and obfuscation... - and I'd like to quote here from Bruce Schneier's book about applied cryptography:

If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world's best safecrackers can study the locking mechanism - and you still can't open the safe and read the letter - that's security.

Coming back to the IDN Channel Message, it's a strewn myth that IDN-encoded content can't be encrypted. Support for this has been put into it on several levels - just that there is no specification of how to actually do it. Why not? - well - why should it? There hasn't been anyone showing up with skills, time or funds to put it in. It's that easy.

The most straightforward solution would be to wrap the plain messages into an encrypted stream like for example https does for http. Setting up a VPN could be another approach. In addition to that, IDN Channel Messages could live inside the obfuscated containers of current software systems. These systems and containers could provide the locking and allow for import and export of the IDN streams.

Information from ILDA Technical Committee chair Dirk Apitz, December 2016

With older analog ILDA ISP cables, everything is pretty clear. You run an ILDA cable (DB-25 parallel port style) for each projector, individually or daisy chained, connect them, and run them. Essentially, what you're doing this way is assigning an address by hand-wiring the projectors.

With digital networking, everything runs across a single cable. You very likely saved much time in wiring, but your addressing scheme is gone. Now - how to get it back?

At this point, let's make a distinction between the network hardware (OSI 1, 2) and the data that travels on the line (OSI 3++). Don't get confused with the OSI layers; I've just mentioned those for completeness. For now, the distinction between the network and the data should be sufficient.

There are many types of networks out there. Some are for historic reasons, some are because of specific properties. The one most widely used by end users is Ethernet — that little 8 way RJ45 connector that was never designed for stage use - and always breaks. Thankfully Neutrik found a solution, but this is another story.

Along with the network type there comes an addressing scheme. Think of this as an address on the letter. On Ethernet, this is the MAC address. Every network adapter has a unique one. All connected devices form a network and you could think of this network as a city or country.

Cities may want to get connected to each other and there may be different options. I mentioned different network types. It could be a wireless link, a dedicated cable or a channel on a phone line where a 'virtual cable' gets multiplexed with others.

Now, let's move on to the data. A letter shall be sent from one city to another. This means, the data packet is transported inside city A to a bridge and over to city B where it gets dispatched.

Unfortunately, since multiple types of networks may be involved, our addressing scheme is kind of in trouble. Let's therefore introduce a global addressing scheme that can translate into any local scheme. This is the IP address - or with the example above it could be the GPS coordinates.

Too complicated? Well maybe a bit — but what I like to point out here is that two levels of addressing is not generally bad. It gives a degree of abstraction and with that arbitrary flexibility. Anyway, nothing you want to worry about when setting up a show. Neither the hardware (MAC/EUI48) nor any IP address (that may even change). And — honestly — computer scientists don't like it too. That's why they assigned names. Hostnames, domain names, and so on.

Now, how does IDN deal with this?

IDN was designed to use standard components and run on minimal infrastructure as well as on dedicated networks. Requiring a name translation service in the network would have been wrong because of complexity. Instead, IDN comes with a simple network scan mechanism found in embedded devices.

Running on minimal infrastructure kind of implies little/zero configuration as well. While you might want to care about the device name or service name like "LightShark 4000 Pro" or "Left-2", you may not really be interested in the IP address (unless for special setups) or the MAC address which is just needed for delivery. Or, as with the example above, you may just want to send a letter to your friend and not care about how the postman does his job.

With IDN, your application broadcasts a scan message on the network and all devices answer with their information. Then, the application knows of who is there. It knows this by the (current) address that can be retrieved from the response data packet. Regarding IDN, the information in the reply packet contains a unique ident code and a user-given name. The ident code can be used for housekeeping and merging subsequent scans and the name can be presented to the user. This way, when the user choses a name, the application exactly knows whom and where to talk to.

Well, you got your addressing scheme back. Assign names to your projectors and label them. Set everything up, start your application, hit “Scan’ and you get a list of all projectors by name. Depending on the application, arrange them like they are on stage, assign tracks or outputs — and that's it.

Information from ILDA Technical Committee chair Dirk Apitz, April 2021

IDN-Hello is actually IDN-Hello (discovery) and IDN-RT (read time transfer). Both protocols relate in versioning, header fields, commands - but are independent! Means, a server can implement either one or the other or both (which makes most sense). There is a special case of broadcasting and multicasting where an implementation of just IDN-BRT (a subsection of IDN-RT) is needed.