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.

Y(J)S

Wednesday, July 28, 2010

Trains, planes, MPLS, and IP

I am in Maastricht at the 78th IETF meeting.

In the weeks before the meeting many IETF'ers complained about the fact that there were no direct flights to the venue. The closest airports are Amsterdam and Brussels, but from there three trains had to be taken.

At first I had thought that the problem was related to carrying luggage between trains, but discovered that the concerns were more about the differences between connection-oriented and connectionless networking.

Plane flights are similar to MPLS or ATM.
You set up the entire end-to-end route before taking it.
You pay for the desired quality of service (business class / economy) and the appropriate resources are reserved for you.
Your connections should be seamless (e.g., they transfer your luggage for you) but, if a connection fails you have to invoke the management system and wait a long time for a reroute (with gold passengers suffering less delay than non-prioritorized ones).

Train rides are like IP.
You pay a flat rate to get to Maastricht.
There are many valid ways to get there (via Utrecht, via Amsterdam Centraal, or via Rotterdam), and which you take is nondeterministic, depending on when you start the journey and whether some lines are not running (due to weekends, work on the lines, etc).
The processing required at each hop may seem complex (arrive at platform 13, take elevator up, and then down to platform 5a), but your best strategy is just to take the first train in the right direction that comes along (after all Dijkstra was Dutch).
You can pay for a first-class DiffServ priority, but the difference is not very big and they don't reserve an assigned seat for you.
Even if you accidentally get on the wrong cabin and end up in Heerlan, you just take the next train back.

It seems surprising to me that so many IETF78 participants were worried that the IP way of doing things would not work.

Y(J)S

Monday, July 26, 2010

Succulents and (tele)protection mechanisms

My wife and I cultivate succulents, plants that store water. Cacti are succulents, but we don’t collect them – only the cuddly and outwardly types. What I find so interesting about succulents is that the various types are relatively unrelated – there was never a proto-succulent that evolved into many subspecies. Instead many different kinds of plants developed similar mechanisms to cope with the same problem – that of conserving water. For example, the American Agave (from which Tequila is made) family looks so similar to the African Aloe (from which Aloe Vera is derived) family, that it is hard to tell them apart.

The same thing happens in different families of technologies. For example, in-building wiring in the UK uses ring circuits, where wiring goes from the fuse box to each of the receptacles, and back to the fuse box. In this way one can get away with smaller-diameter conductors than needed with a "radial circuit", since there are two parallel paths from the fuse box to each receptacle. Furthermore, if a wire is disconnected along one direction from the fuse box, there is still electricity at all of the receptacles. This is similar to what we call in communications engineering a 1+1 protection mechanism. In 1+1 protection the information is sent around a ring in both directions, and a copy that makes it (first or best) to the destination is extracted.

On the other hand, high-voltage electric distribution systems use a mechanism called "teleprotection" in order to bypass faults. When a fault is detected large relays switch in order to bypass the fault. This is similar to what we call fast reroute (FRR), in which detection of a communications network failure triggers rerouting of information around the failed link or element.

So, two of the protection mechanisms used in communications were independently discovered and implemented in electric wiring as well. I find that as interesting as succulents.

Y(J)S

Wednesday, July 21, 2010

Shaping / policing in 3G networks

This is my first blog entry on the world of traffic shaping. We have all been hearing about the need for shaping in 3G mobile networks. The subject’s popularity exploded with the publicity of network overload problems that some operators were experiencing with the introduction of the iPhone. Most of that turned out to be due to signaling overload. However, almost everyone is convinced that if flat-rate plans remain then true data congestion will become acute at some point, and some sort of bandwidth shaping and policing will then be needed.

The question is where to apply the shaping. Most of the many solutions that I have seen are positioned relatively high up in the network, at the Gn (between SGSN and GGSN) or Gi (between GGSN and Internet) interfaces. And it’s easy to see why. Lower down (at the Iu or Iub RAN interfaces) there are scalability concerns and the protocols are much more complex.

The problem is that the same data overload concerns are forcing mobile operators to cache and/or offload traffic as close to the end-user as possible. This traffic doesn’t traverse shaping / policing functions positioned higher up, and thus leads them to believe that all is well. Hence the RAN becomes even more overloaded.

Two fixes come to mind. The more complex one is to signal the true situation upwards. This one may be preferred by operators, as it could potentially allow non-flat-rate billing even for traffic that doesn’t traverse their core. The cleaner solution is to perform the shaping lower down (e.g., at the Iub), before the caching/offloading. This solution entails classifying user traffic that is usually encrypted and even if in the clear is hidden by a plethora of complex protocols. The actual shaping is also complicated because of multiplexing.

I would appreciate hearing as to preference or other alternatives.

Y(J)S