Marc Weiss, PhD: Precision timing is becoming increasingly important in a wide range of markets. Tell us a bit about what's driving that.
Norm Finn: A broad range of markets depend on accurate timing and their timing needs are changing. Power grid users have a need for precision time for switching large amounts of electrical power. They need to ensure that they don't blow up transformers. There are also video production studios, which have important new uses for timing. Industrial process control is another area, such as in chemical processes, or even in applications you wouldn't normally consider, such as assembling toys. There are mobile applications in airplanes and automobiles. In general, there is a thrust in areas that have been controlled digitally since the 80's, and as their applications grow, timing gets faster and more important. Industries want to switch to using Ethernet instead of proprietary digital buses, for example, using Ethernet in video instead of HDMI.
Weiss: Would you say Ethernet is going to become the major transport for mixing data with timing in most of these industries?
Finn: It will certainly become at least one of the major transports. In the automobile industry there are already a number of cars using Ethernet to carry both bumper camera and entertainment data within the car. The wiring in cars is one of the heaviest components in the automobile. Ethernet may well replace it. Often with the right equipment, you may be able to carry enough power over the Ethernet to do a lot of things.
Weiss: Power as well?
Finn: Yes, Ethernet carries 10's of watts of power, which is enough for a lot of things.
Weiss: Could you map out other industries and the levels of accuracy they need?
Finn: The audio world needs accuracies of around 10 microseconds to get phases right. You need to be able to get timing down into the microsecond range to get the phase right among speakers. You can play some fascinating tricks with sound, in terms of timing, on the order of a microsecond.
Weiss: In general we know that time has become important in a lot of industries. However, people are struggling to make standards that support time, because industries are not converging, and this is causing problems.
Finn: Very rightly so. There are industries that have immediate needs. They want to move into using Ethernet. They want precision time as part of what they're doing — and they want to move right now.
However, here is a basic problem: Say you have a network that is dedicated to a particular function. You have specific timing needs. IEEE1588 offers a profile that meets your needs. It provides a great way to make progress when the industry is relatively young.
However, it becomes a problem when you want a time service to be robust and secure against accidental or malicious tampering, and you're worried about how many time sources you need. An enterprise network manager, for example, may find their factory floor and their audio-video conference rooms all have timing needs. As the number of applications multiplies, they need more out of their network than perhaps it can handle.
An industry vertical will define the relationship of PTP with the bridges or routers that it is using. However, if it assumes that this vertical is the only application that needs time on this network, soon there are multiple potentially conflicting needs.
Weiss: But is it on the same network as the best effort traffic?
Finn: Exactly. That's the goal of deterministic networking in the IETF and time-sensitive networking and IEEE 802, which is specifically the ability to get the real-time data where it has to go. It also still passes the data that we've been carrying in the way people are accustomed to carrying it. It does this in such a way that neither of them interferes excessively with the other. Exactly the same physical infrastructure. That's very important. I call it a "feature on top of a network." The customers can't afford to have a separate network for the real-time stuff.
Weiss: That's part of the advantage right? You have one network and it solves all problems?
Finn: Exactly. That gets into a form of time as a service. The service providers have their vision of time as a service, but time as a service is also an important concept for enterprise networks. For example, you have all of these applications that want time. The network needs to provide it. For example, when I look at SMPTE, PC37, or 802.AS, which is used for industrial control and for audio distribution, I look at all of these different profiles. These different technologies are great. Now, however, people want secure or robust time or to be able to deal with levels of synchronizing to UTC.
Weiss: How do you mix all of that?
Finn: That's the question. There are all of these kinds of features — especially the robustness and the security — and all the encryption in the world will not protect time. This is because time often is about when you deliver the packet, not necessarily what's in it. The techniques for securing time involve getting time from multiple sources. This is exactly the robustness problem. The technique to solve those problems is using multiple sources — getting the time to you via multiple paths.
Weiss: To guarantee redundancy with multiple source reliability?
Finn: Exactly. By having multiple sources, and multiple paths and distribution trees for time, entities that are spread out through the network make a decision on what time it is based on these multiple sources. Here is where we get into timing as a service in the enterprise sense as opposed to the service provider sense. I want one of my sources to be a service provider, or two, and one of them may offer me multiple sources of time. However, when I look at all these proliferations of profiles, it is not easy to reconcile multiple sources of time. It would be absurd to burden a 75 cent microphone in the ceiling with reconciling multiple time sources.
Say I want time as a service throughout my enterprise — to the manufacturing floor, to the finance people, to the conference rooms. I want time as a service in my company. I would build a network inside my organization where I have robust, reliable and secure time by means of the multiplicity of time. I would have nodes by the edge of my network, which do play this game and do get time from multiple sources. Then each node has his set of local clients.
Weiss: So your nodes would make decisions choosing who to trust. These smart and complex nodes control cheap, inexpensive apps who run as clients getting the right time from the nodes.
Finn: Right. Moving forward, I'm hoping that it is fine that SMPTE or the power grid people or all these different industries have their profiles, but I'm going to build this microphone or valve actuator around some unique profile. I'm not going to get my time distributed to me in the existing 1588 profile style that assumes it is going to go via transparent clock through these bridges. The local master's doing the integration and all the security. It will speak to all of these users in whatever style that local user needs. With time as a service, you have robust time, so all your failure modes are local.
Weiss: So we have listed a number of needs for timing now, such as power grid, video, industrial, transportation systems. Some of the standard bodies are addressing this in terms of the challenges each industry faces and their resolutions. We've addressed the challenge that traditional networking and computing involves virtualization and abstraction from the physical layer. We've addressed how they are resolving this issue with timing that needs immediacy, that needs connection to the physical layer, and mixing that with the needs for security in enterprise networks.
Finn: Yes, and to close the connection, time as a service in the enterprise or the data center is the key to all that. In the data center, you have a virtual network that quite often has nothing to do with the physical network. You manage time as a service as a physical thing. At the very edges, it gets delivered to the physical box. That is how you make the connections and resolve this. You make time physical, underneath all the virtualization. Then you can reconnect the virtual world to the physical world at the edge. The network needs to say, "Okay I can deliver you time. Here's how we're going to do it." Networks need to think about time as a service — without an arms race of robustness, security, features, and extra services — and just concentrate on time as a service that's feature rich and meeting local needs.
Weiss: In conclusion, we've listed some industries that need time, discussed some of the standards work, and introduced the question of time as a service in enterprise networks. There will be a lot more information on this topic at the ATIS Workshop on Synchronization and Timing Systems, WSTS. Join us April 3-6 in San Jose, California.