Thursday, July 29, 2010

TICTOC update

This entry is an update for people who have been following the IETF TICTOC working group that I chair.

We had a very lively meeting yesterday, and the topic that evoked the most interest was that of how to transfer timing flows (especially 1588, but NTP as well) over MPLS networks.

The first question is why anything special treatment is needed here at all - after all, anything that can be carried over IP or Ethernet can be carried over MPLS! The reason for special treatment is that network elements along the path may need to be able to identify timing packets. For example, for high accuracy timing it will be necessary to prioritorize timing packets, for example by placing them in a usually empty queue in order to limit transit delay and delay variation. Furthermore, it may be desirable to identify timing packets and read specific field in them in order to implement on-path support (e.g., 1588 transparent clock or boundary clock functionality).

So what can be done? The simplest answer is nothing; well almost nothing. We could just send the timing packets as IP packets over MPLS and expect DPI to identify them. This would be expensive, potentially error-prone, and would introduce additional delay and perhaps delay variation.

The next simplest answer is to place timing packets in an LSP of their own, and to signal or configure the LSRs to recognize these timing packets. A draft describing such a mechanism has recently been written.

Another idea would be to use a special MPLS label could be defined that would be universally recognized. Unfortunately, there are only 16 reserved labels, and 6 have already been allocated - it will be hard to convince the MPLS experts to give us a label for this purpose. Alternatively, a specific combination of TC bits (ex-EXP bits) could be used to indicate timing packets.

For MPLS-TP environments the relatively new generic associated channel (GACh) could be used. These are packets that usually carry OAM, and for timing delivered by the service provider, this would seem a natural way to go.

Finally, one could define a new pseudowire type, or a new MPLS client (right now MPLS can carry MPLS, IP, or pseudowire clients).

In the discussions that ensued, the method of using a special LSP (carrying either IP or Ethernet timing packets), the use of the TC field, and the GACH method, all had proponents.

It is too early to say which method will prevail.