Project

General

Profile

Proposed efficient TDMoIP » History » Version 8

laforge, 01/19/2022 04:02 PM

1 1 laforge
h1. Proposed efficient TDMoIP
2
3
{{>toc}}
4
5
This wiki page exists to collect some ideas about a proposed, new type of TDMoIP protocol.
6
7 2 laforge
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]]).
8 1 laforge
9
h2. Major design goals
10
11
h3. mandatory features
12
13
* *structure-agnostic*
14
** suitable for any kind of traffic, whether ISDN/Q921, GSM-Abis, SS7, ATM, Frame Relay, ...
15
** support for framed E1
16
** support for channelized and non-channelized E1
17
** support for E1 with and without CRC4
18
* *bandwidth-efficient*
19
** the average hobbyist doesn't want to waste 2Mbps full-duplex bandwidth even if no traffic at all is communicated
20
* *suitable for use with dynamic IP and NAT*
21
** at least on the client side, it should work with dynamic IP and through NAT
22
** server side is required to have static IP
23
* *support for IPv4 and IPv6*
24
** there are more and more users in the public internet without real IPv4 connectivity
25
* *support for cryptographic authentication*
26
** users should authenticate themselves against the server via some challenge-resposne mechanism safe against eavesdroppers
27
28
h3. optional features
29
30
* support for unframed E1
31
* support for T1 (in the protocol; not in the proposed primary [[Ice1usb]] based hardware implementation)
32
* support for confidentiality (encryption)
33
34
h2. Current WIP thoughts on implementation
35
36 4 laforge
h3. suppress transmission of idle timeslots
37 1 laforge
38 3 laforge
This is the most critical part of reducing the background traffic for an [relatively] idle link.
39 1 laforge
40
41 3 laforge
We'd need to know (ideally auto-detect) which timeslots are in use, and then only tramsmit those with actual traffic in them.
42
43 1 laforge
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.
44 3 laforge
45
h4. traffic slots (B channels)
46
47
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.
48
49
h4. HDLC signaling slots (D channels)
50
51 5 laforge
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.
52 1 laforge
53
h3. batching / aggregation of frames
54
55
Batching several frames in a single packet serves the following purposes
56
* reduce the amount of packets per second
57
* reduce the proportional overhead for IP/UDP/protocol headers
58
59
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)
60
61
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.
62
63
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.
64
65
h3. optional HDLC processing on both sides
66
67
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.
68
69
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
70
71
h3. clocking / timing / jitter
72
73
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.
74
75
Some pre-buffering and a [minimal] jitter buffer is required to compensate for jitter in the IP transport medium.
76
77
78
h3. Initial / Preferred Hardware implementation
79
80
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.
81
82
h3. Direct DAHDI driver
83
84
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:
85
86
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.
87 6 laforge
88
h2. Use cases
89
90
h3. pysical E1 line via Internet
91
92
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:
93
94
{{graphviz_link()
95
graph {
96
  rankdir=LR;
97
  subgraph cluster_L {
98
     label="Site L";
99
     PBX_L [label="PBX"];
100
     icE1usb_L [label="icE1usb"];
101
     GW_L [label="GW L"];
102
     PBX_L -- icE1usb_L [label="E1"];
103
     icE1usb_L -- GW_L [label="USB"];
104
  }
105
  subgraph cluster_R {
106
     label="Site R";
107
     PBX_R [label="PBX"];
108
     icE1usb_R [label="icE1usb"];
109
     GW_R [label="GW R"];
110
     PBX_R -- icE1usb_R [label="E1"];
111
     icE1usb_R -- GW_R [label="USB"];
112
  }
113
  Internet;
114
  GW_L -- Internet [label="IP"];
115
  GW_R -- Internet [label="IP"];
116
}
117
}}
118
119 7 laforge
h4. clocking
120
121
In this setup, it is possible to use the GPS-DO of the icE1usb on both sides as a clock reference.  As long as they are both locked, there shouldn't be any drift, just a very small amount of jitter, which si compensated by a small jitter buffer.
122
123 6 laforge
h3. Physical E1 to virtual E1
124
125
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).
126
127
{{graphviz_link()
128
graph {
129
  rankdir=LR;
130
  subgraph cluster_L {
131
     label="Site L";
132
     PBX_L [label="PBX"];
133
     icE1usb_L [label="icE1usb"];
134
     GW_L [label="GW L"];
135
     PBX_L -- icE1usb_L [label="E1"];
136
     icE1usb_L -- GW_L [label="USB"];
137
  }
138
  subgraph cluster_R {
139
     label="Site R";
140
     PBX_R [label="PBX\n(Virtual DAHDI)"];
141
  }
142
  Internet;
143
  GW_L -- Internet [label="IP"];
144
  PBX_R -- Internet [label="IP"];
145
}
146 1 laforge
}}
147 8 laforge
148
h4. clocking
149
150
In this situation, the _virtual_ side doesn't have any quality clock source.  clock would have to be recovered from timing of arriving packets from the physical side of the link, where hardware timing is present.  As long as there is only one link (or rather one clock source), this should work.
151
152
If there are multiple "physical" sides connected to the virtual side, then the  "physical" sides would all have to use GPS-DO clocking in order to ensure there is one single clock across the network.
153 6 laforge
154
h3. Virtual E1 to Virtual E1
155
156
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.
157
158
If the virtual E1 is exposed via the same DAHDI interface, the applications (e.g. softswitch) will not notice any differnce.
159
160
{{graphviz_link()
161
graph {
162
  rankdir=LR;
163
  subgraph cluster_L {
164
     label="Site L";
165
     PBX_L [label="PBX\n(Virtual DAHDI)"];
166
  }
167
  subgraph cluster_R {
168
     label="Site R";
169
     PBX_R [label="PBX\n(Virtual DAHDI)"];
170
  }
171
  Internet;
172
  PBX_L -- Internet [label="IP"];
173
  PBX_R -- Internet [label="IP"];
174
}
175
}}
176
177
h3. Virtual E1 timeslot mux
178
179
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.
180
181
We'd have different scenarios for different timeslots:
182
* static mapping of timeslots between E1 lines
183
** like leased lines, e.g. from a config file
184
* exposure of timeslot to userspace via DAHDI
185
** ISDN or SS7 signaling
186
** media playback
187
** media gateway with RTP on the other side
188
* dynamic mapping of timeslots between E1 lines
189
** under control of soft-switch for voice / data calls or the like
Add picture from clipboard (Maximum size: 48.8 MB)