Retronetworking » OCTOI - Osmocom Community TDM over IP

h1. Proposed efficient TDMoIP

{{>toc}}

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 [[retro-bbs:Community_TDMSS7_Network]]).

h2. Major design goals

h3. 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

h3. 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)

h2. Current WIP thoughts on implementation

h3. suppress transmission of idle timeslost

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

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.

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.

h3. 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.

h3. 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

h3. 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.

h3. 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.

h3. 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.