Proposed efficient TDMoIP¶

• Table of contents
• Proposed efficient TDMoIP
  • Major design goals
    • mandatory features
    • optional features
  • Current WIP thoughts on implementation
    • suppress transmission of idle timeslost
      • traffic slots (B channels)
      • HDLC signaling slots (D channels)
    • batching / aggregation of frames
    • optional HDLC processing on both sides
    • clocking / timing / jitter
    • Initial / Preferred Hardware implementation
    • Direct DAHDI driver

This wiki page exists to collect some ideas about a proposed, new type of TDMoIP protocol.

The high-level goal of the protocol is to be able to carry E1 circuits over IP networks, specifially the public internet. The idea is for this to be used in order to interconnect various community/hobbyist folks who experiment with TDM technology at their home, but who have no chance to interconnect with others due to the decommissioning of the pubic PDH/ISDN networks. (more on that proposed network at Community_TDMSS7_Network).

Major design goals¶

mandatory features¶

• structure-agnostic
  • suitable for any kind of traffic, whether ISDN/Q921, GSM-Abis, SS7, ATM, Frame Relay, ...
  • support for framed E1
  • support for channelized and non-channelized E1
  • support for E1 with and without CRC4
• bandwidth-efficient
  • the average hobbyist doesn't want to waste 2Mbps full-duplex bandwidth even if no traffic at all is communicated
• suitable for use with dynamic IP and NAT
  • at least on the client side, it should work with dynamic IP and through NAT
  • server side is required to have static IP
• support for IPv4 and IPv6
  • there are more and more users in the public internet without real IPv4 connectivity
• support for cryptographic authentication
  • users should authenticate themselves against the server via some challenge-resposne mechanism safe against eavesdroppers

optional features¶

• support for unframed E1
• support for T1 (in the protocol; not in the proposed primary Ice1usb based hardware implementation)
• support for confidentiality (encryption)

Current WIP thoughts on implementation¶

suppress transmission of idle timeslost¶

This is the most critical part of reducing the background traffic for an [relatively] idle link.

We'd need to know (ideally auto-detect) which timeslots are in use, and then only tramsmit those with actual traffic in them.

The actual packets then need to contain some kind of information which timeslots are present in the current packet, for example by including a 32bit bit-mask.

traffic slots (B channels)¶

If a timeslot keeps carrying the same pattern (bytes) in consecutive frames, suppress transmission of that timeslot. The receiver can reconstruct the bitstream by repeating the bytes from a previous (cached) frame.

HDLC signaling slots (D channels)¶

As idle HDLC timeslots contain continuous 7-bit flag characters, we cannot simply just compare with the previous byte in the channel, as it would change all the time. Only ever 8 flag octets (7 bytes) the pattern repeats if no actual payload is transmitted.

So we could introduce more higher-level processing at this point, and decapsulate/encapsulate the HDLC payload at both sides and simply transport the payload over IP only. This would typically be a LAPD frame.

The critical question is how do we know which slot[s] are used for HDLC.

• out-of-band configuration by the user is always ugly
• auto-detection (long sequences of flag octets) are prone to false positives and use quite a bit of CPU

Since at least in many deployments one of the two sides (the "central office") is going to be a virtual span in DAHDI, we could of course simply use the channel mode (CLEAR vs. HDLCFCS/HDLCRAW/HDLCNET) and communicate this to the peer.

batching / aggregation of frames¶

Batching several frames in a single packet serves the following purposes

• reduce the amount of packets per second
• reduce the proportional overhead for IP/UDP/protocol headers

Batching too many frames introduces unwanted additional latency. Furthermore, we want to avoid exceeding the MTU of the IP connection (which would add IP level fragmentation, which is generally to be avoided)

We can fit at least 40 frames (32 bytes each) inside a single TCP/UDP packet without hitting the usual MTUs around the internet. 40 frames means 200 Hz packet rate, introducing 5ms of buffering.

Some quick estimate: Sending 36 bytes (IPv4 + UDP header + estimated 8 byte TDMoIP header) at 200 Hz means 57.6 kbits-per-second of background traffic, plus then whatever active slots. That's much better than 2Mbps flat.

optional HDLC processing on both sides¶

Many types of E1 traffic have one 64k slot for signalling (ISDN, Abis, SS7). If this 64k bitstream is transmitted transparently at all times, we would end up with something like 120 kbit/s background traffic.

This could optionally be optimized further by telling the converters on both sides that a certain slot is in HDLC mode. In this mode, the repeated sequences of flag octets are suppressed, and only the HDLC payload (with or without FCS) is passed over IP. This would make an idle signalling channel free of bandwidth utilization

clocking / timing / jitter¶

The curent idea is to use icE1usb as the physical E1 interface. It has a built-in GPS-DO and hence would allow to avoid any significant clock drift between the participants of the network. Larger clock drift would lead to buffer underruns/overruns with rather ugly effects to the payload.

Some pre-buffering and a [minimal] jitter buffer is required to compensate for jitter in the IP transport medium.

Initial / Preferred Hardware implementation¶

The idea would be to use something small and compact, with limited power consumption like an icE1usb plus an embedded Linux system like a Raspberry Pi, Banaa Pi, Odroid XU4, PC-Engines APU or the like.

Direct DAHDI driver¶

The primary use case for this system is to attach legacy E1/PDH equipment. However, there are of course use cases where one might want to connect software like Asterisk, yate, Freeswitch, osmo-bsc, ... The naive approach of course would be to use a physical E1 line card and then go via the icE1usb. But in this case a fully virtualized approach can of course be used:

This entails an implementation of this protocol directly inside a DAHDI driver (like the Astribank drivers). This way, the software (e.g. Asterisk) sees a DAHDI span, but that span has no actual hardware associated with it, just the TDMoIP.