Proposed efficient TDMoIP » History » Revision 6
Revision 5 (laforge, 01/16/2022 04:45 PM) → Revision 6/17 (laforge, 01/19/2022 03:58 PM)
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 timeslots
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.
h4. 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.
h4. HDLC signaling slots (D channels)
As idle HDLC timeslots contain continuous flag characters coded as 01111110, we can also simply compare with the previous byte in the timeslot. So the same handling applies for both B-channels and D-channels.
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.
h2. Use cases
h3. pysical E1 line via Internet
In this scenario, there is E1 equipment like an ISDN PBX with PRI, a Frame Relay router, etc. in two locations, and they shall be interconnected over IP:
{{graphviz_link()
graph {
rankdir=LR;
subgraph cluster_L {
label="Site L";
PBX_L [label="PBX"];
icE1usb_L [label="icE1usb"];
GW_L [label="GW L"];
PBX_L -- icE1usb_L [label="E1"];
icE1usb_L -- GW_L [label="USB"];
}
subgraph cluster_R {
label="Site R";
PBX_R [label="PBX"];
icE1usb_R [label="icE1usb"];
GW_R [label="GW R"];
PBX_R -- icE1usb_R [label="E1"];
icE1usb_R -- GW_R [label="USB"];
}
Internet;
GW_L -- Internet [label="IP"];
GW_R -- Internet [label="IP"];
}
}}
h3. Physical E1 to virtual E1
In this scenario, we have physical E1 only on one of the two sides (where some legacy E1 equipment is located) while the other side is virtualized. This can be achieved by providing a _virtual DAHDI_ driver that shows up just like a physical DAHDI interface to the PBX software (or any other software using DAHDI).
{{graphviz_link()
graph {
rankdir=LR;
subgraph cluster_L {
label="Site L";
PBX_L [label="PBX"];
icE1usb_L [label="icE1usb"];
GW_L [label="GW L"];
PBX_L -- icE1usb_L [label="E1"];
icE1usb_L -- GW_L [label="USB"];
}
subgraph cluster_R {
label="Site R";
PBX_R [label="PBX\n(Virtual DAHDI)"];
}
Internet;
GW_L -- Internet [label="IP"];
PBX_R -- Internet [label="IP"];
}
}}
h3. Virtual E1 to Virtual E1
In this situation there would be no physical E1 line involved, but only virtual lines. This would mainly be to interconnect software developed for E1, but in a virtualized environment where no real E1 is present.
If the virtual E1 is exposed via the same DAHDI interface, the applications (e.g. softswitch) will not notice any differnce.
{{graphviz_link()
graph {
rankdir=LR;
subgraph cluster_L {
label="Site L";
PBX_L [label="PBX\n(Virtual DAHDI)"];
}
subgraph cluster_R {
label="Site R";
PBX_R [label="PBX\n(Virtual DAHDI)"];
}
Internet;
PBX_L -- Internet [label="IP"];
PBX_R -- Internet [label="IP"];
}
}}
h3. Virtual E1 timeslot mux
In this situation, we assume there is a hub terminating many E1-over-IP links, and whihc then provides services to multiplex/switch on a per-timeslot basis between those links.
We'd have different scenarios for different timeslots:
* static mapping of timeslots between E1 lines
** like leased lines, e.g. from a config file
* exposure of timeslot to userspace via DAHDI
** ISDN or SS7 signaling
** media playback
** media gateway with RTP on the other side
* dynamic mapping of timeslots between E1 lines
** under control of soft-switch for voice / data calls or the like
