octoi talk slides for osmodevcall
This commit is contained in:
parent
848d961616
commit
96f070b84e
Binary file not shown.
|
After Width: | Height: | Size: 1.0 MiB |
|
|
@ -0,0 +1,386 @@
|
|||
OCTOI - Osmocom Community TDM over IP
|
||||
=====================================
|
||||
:author: Harald Welte <laforge@gnumonks.org>
|
||||
:copyright: 2022 by Harald Welte (License: CC-BY-SA)
|
||||
:backend: slidy
|
||||
:max-width: 45em
|
||||
|
||||
|
||||
== Overview
|
||||
|
||||
* WTF? Why?
|
||||
* History: TDM networks
|
||||
* existing TDMoIP technology
|
||||
* OCTOI Protocol
|
||||
* OCTOI Software
|
||||
* Current OCTOI Network
|
||||
* WIP / Future Plans
|
||||
|
||||
== WTF is this all about?
|
||||
|
||||
* enable people to run legacy WAN equipment
|
||||
** Modems, Phones (analog, ISDN), PBXs
|
||||
** ISDN-Adapters
|
||||
** Frame Relay / HDLC / X.25 / routers
|
||||
* in a distributed fashion, over the internet
|
||||
* allow to run retronetworking tech from mid-1980s to about 2010 at a time where the related transport
|
||||
services are no longer available from public telephone operators / carriers
|
||||
|
||||
// ***********************************************************************
|
||||
// History: TDM networks
|
||||
// ***********************************************************************
|
||||
|
||||
== History: analog telephone networks
|
||||
|
||||
public switched telephone network (PSTN)
|
||||
|
||||
* traditionally used only analog lines
|
||||
** base band on twisted pair on last mile
|
||||
** base band on twisted pair between exchanges nearby
|
||||
** analog modulated carrier wave on coaxial cables or microwave links for long distance
|
||||
|
||||
== History: TDM networks + ISDN
|
||||
|
||||
* at some point (1970s?), digital PCM technology was introduced between exchanges
|
||||
** initially PDH, later SDH (which can transport PDH)
|
||||
** see https://media.ccc.de/v/osmodevcall-20211112-laforge-tdm[OsmoDevCall on TDM/PDH/SDH]
|
||||
* external interfaces, particularly to subscriber, still analog until mid-1980s
|
||||
* ISDN changed that: Introduced digital subscriber lines
|
||||
** Basic Rate ISDN (BRI): 2x B, 1x D-Channel
|
||||
** Primary Rate ISDN (PRI): 30x B, 1x D-Channel
|
||||
|
||||
== Present: TDM networks mostly dead
|
||||
|
||||
* Telcos have meanwhile mostly migrated to All-IP telephony
|
||||
* PDH/SDH networks mostly shut down, occasionally still in operation for legacy customers or some internal
|
||||
legacy services. Not actively sold anymore.
|
||||
* You cannot get a real PRI line anymore to connect your ISDN PBX or your Cisco router
|
||||
* Idea: Create community network of people who want to play with ISDN / TDM stuff
|
||||
* Naive approach: Use existing, off-the-shelf TDMoIP devices
|
||||
|
||||
|
||||
== Wanted: TDMoIP network
|
||||
|
||||
[graphviz]
|
||||
----
|
||||
graph G {
|
||||
hub [shape=box, label="TDMoIP hub\ncross-connect\nin public internet"];
|
||||
subgraph cluster_1 {
|
||||
label="Hobbyist A";
|
||||
ad1 [label="Access Device\n"];
|
||||
pbx1 [label="PBX"];
|
||||
phone1a [label="Phone"];
|
||||
modem1b [label="Modem"];
|
||||
ta1c [label="ISDN TA"];
|
||||
pbx1 -- ad1 [label="E1"];
|
||||
phone1a -- pbx1 [label="POTS"];
|
||||
modem1b -- pbx1 [label="POTS"];
|
||||
ta1c -- pbx1 [label="ISDN-BRI"];
|
||||
}
|
||||
subgraph cluster_2 {
|
||||
label="Hobbyist B";
|
||||
ad2 [label="Access Device\n"];
|
||||
pbx2 [label="PBX"];
|
||||
phone2a [label="Phone"];
|
||||
modem2b [label="Modem"];
|
||||
ta2c [label="ISDN TA"];
|
||||
pbx2 -- ad2 [label="E1"];
|
||||
phone2a -- pbx2 [label="POTS"];
|
||||
modem2b -- pbx2 [label="POTS"];
|
||||
ta2c -- pbx2 [label="ISDN-BRI"];
|
||||
}
|
||||
subgraph cluster_3 {
|
||||
label="Hobbyist C";
|
||||
ad3 [label="Access Device\n"];
|
||||
pbx3 [label="PBX"];
|
||||
phone3a [label="Phone"];
|
||||
modem3b [label="Modem"];
|
||||
ta3c [label="ISDN TA"];
|
||||
pbx3 -- ad3 [label="E1"];
|
||||
phone3a -- pbx3 [label="POTS"];
|
||||
modem3b -- pbx3 [label="POTS"];
|
||||
ta3c -- pbx3 [label="ISDN-BRI"];
|
||||
}
|
||||
ad1 -- hub [label="TDMoIP\nInternet"];
|
||||
ad2 -- hub [label="TDMoIP\nInternet"];
|
||||
ad3 -- hub [label="TDMoIP\nInternet"];
|
||||
}
|
||||
----
|
||||
|
||||
// ***********************************************************************
|
||||
// Existing TDMoIP technology
|
||||
// ***********************************************************************
|
||||
|
||||
== Existing TDMoIP: SAToP / CESoPSN
|
||||
|
||||
So we just get some of these and all is good?
|
||||
|
||||
image::RAD_IPmux-1_front.jpg[width=1200,align="center"]
|
||||
|
||||
== Existing TDMoIP: SAToP / CESoPSN
|
||||
|
||||
Examples for _transparent_ TDMoIP technologies
|
||||
|
||||
* SAToP (Structure Agnostic TDM over IP)
|
||||
** RFC 4553
|
||||
* CESoPSN (Circuit Emulation Service over Packet Switched Network)
|
||||
** RFC 5086
|
||||
* transport of raw E1 frames over MPLS or UDP
|
||||
* designed for use in LAN or carrier backbone networks
|
||||
* waste a lot of bandwidth, even if TDM circuits are completely idle
|
||||
** > 2Mbps plus header/packet overhead, bi-directional
|
||||
* typically no support for dynamic IP addresses
|
||||
|
||||
== Existing TDMoIP: SIGTRAN IUA, EL2TPD
|
||||
|
||||
Examples for _non-transparent_ TDMoIP technologies
|
||||
|
||||
* SIGTRAN IUA (ISDN User Adaptation)
|
||||
** RFC 3057
|
||||
** works only for ISDN BRI/PRI with Q.921 as Layer 2 on signaling channel
|
||||
** uses SCTP as transport (might not pass all middleboxes in public internet)
|
||||
** no specification how the B-channels are handled, pure signaling solution
|
||||
* Ericsson L2TP / PacketAbis over IP
|
||||
** proprietary, but FOSS implementation in @osmo-el2tpd@
|
||||
** makes specific assumption of use of E1 as Ericsson Abis (GSM BTS back-haul)
|
||||
|
||||
// ***********************************************************************
|
||||
// OCTOI TDMoIP protocol
|
||||
// ***********************************************************************
|
||||
|
||||
== The case for a new TDMoIP protocol
|
||||
|
||||
There's room for a new protocol based on the following goals:
|
||||
|
||||
* *transparent*. Should work for ISDN and other use cases (Frame Relay, Abis, SS7, ATM, ...)
|
||||
* *efficient*. Should not waste a lot of bandwidth on an otherwise idle/unused link
|
||||
* *dynamic IP*. End-user internet access normally has dynamic IP addresses
|
||||
* *nat friendly*. Should work through any number of NATs and CG-NAT without special ALG/helper
|
||||
* *IPv6 support*. Should support IPv6 just like IPv4
|
||||
* *authentication*. Should have built-in mutual authentication
|
||||
|
||||
== OCTOI Protocol: Bandwidth
|
||||
|
||||
* Timeslot Suppression
|
||||
** Transmitter has history of 1 TDM frame
|
||||
** Before Tx, to-be-transmitted frame is compared with last frame
|
||||
** only those timeslots with value != that of last frame are transmitted
|
||||
* Batching
|
||||
** Batch 32 (up to 40) E1 frames per UDP packet
|
||||
*** 8000 frames/s / 32 => 250 packets/s
|
||||
|
||||
Result: About 70 kbit/s (including UDP + IPv4 overhead) on idle E1 link
|
||||
|
||||
== OCTOI Protocol: dynamic IP / NAT-friendly
|
||||
|
||||
* Classic client/server approach
|
||||
* Server currently requires fixed IP (no STUN/ICE/...)
|
||||
* Clients can have dynamic IPs
|
||||
* All messages (control plane + TDM user plan) in one UDP flow
|
||||
|
||||
// ***********************************************************************
|
||||
// OCTOI Software
|
||||
// ***********************************************************************
|
||||
|
||||
== E1oIP: osmo-e1d + icE1usb
|
||||
|
||||
* osmo-e1d was the first (libusb, userspace) driver for the icE1usb hardware
|
||||
* traditionally, it sits between icE1usb hardware and applications using E1 like osmo-bsc
|
||||
* instead of a local application, it can now interface icE1usb to OCTOI
|
||||
** `octoi-server` mode
|
||||
** `octoi-client` mode
|
||||
|
||||
First 4 OCTOI users were connected to the hub that way
|
||||
|
||||
[graphviz]
|
||||
----
|
||||
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"];
|
||||
}
|
||||
----
|
||||
|
||||
== E1oIP: osmo-e1d + dahdi-trunkdev
|
||||
|
||||
* having one icE1usb per peer/user doesn't scale at the hub
|
||||
* this triggered the development of `dahdi-trunkdev`
|
||||
** virtual E1 _span_ for DAHDI without any real hardware
|
||||
** simply provides stream of E1 frames on a character-device
|
||||
** can be used to implement any virtual TDM interface/protocol
|
||||
* osmo-e1d was extended to open dahdi-trunkdev instead of icE1usb
|
||||
|
||||
Next 4 OCTOI users were connected to the hub that way; will become standard for all users
|
||||
|
||||
[graphviz]
|
||||
----
|
||||
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"];
|
||||
}
|
||||
----
|
||||
|
||||
// ***********************************************************************
|
||||
// Current OCTOI Network
|
||||
// ***********************************************************************
|
||||
|
||||
== Current OCTOI network hub
|
||||
|
||||
* Debian 11 with `dahdi-trunkdev`, `osmo-e1d` and `yate`
|
||||
* since physical machine died recently: migrated into qemu-kvm
|
||||
** SRV-IO for NIC, USB Host Controller and DADHI card (TE820)
|
||||
* TE820 8-port E1 card, attaches to
|
||||
** LaF0rge's local PBX (Auerswald COMmander 2 basic)
|
||||
** Livingston PortMaster 3 RAS
|
||||
** 4x icE1usb
|
||||
** Cisco AS5400
|
||||
|
||||
== Current OCTOI participants
|
||||
|
||||
The hub currently has the following clients / participants:
|
||||
|
||||
* using icE1usb at hub side
|
||||
** manawyrm
|
||||
** gruetzkopf
|
||||
** roox
|
||||
** cquirin
|
||||
* using `dahdi-trunkdev` at hub side
|
||||
** drdeke
|
||||
** tmwawpl
|
||||
** tom/sirtux
|
||||
** tnt
|
||||
|
||||
== Current OCTOI services
|
||||
|
||||
* E1 / TDM as "transport" layer
|
||||
* ISDN network as "routing" layer
|
||||
** hub simulates the network / central office / switch side
|
||||
** client devices implement the "user" side, just like when attaching to ISDN/PSTN
|
||||
* Services on top of ISDN
|
||||
** Audio Telephony
|
||||
** Video Telephony (T-View 100 / H.320)
|
||||
** ISDN Data Calls
|
||||
** Analog Modem Calls
|
||||
|
||||
== OCTOI ISDN / Modem calls
|
||||
|
||||
* hub currently has a https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3[Livingston Portmaster 3] RAS
|
||||
** up to 30 ISDN data or analog modem calls (up to V.90)
|
||||
* services can be created in RADIUS, identified by Called Party Number
|
||||
** PPP dial-up locally terminated
|
||||
** PPP dial-up with forwarding of data via L2TP to remote LAC
|
||||
** telnet or TCP clear forwarding to remote BBSs
|
||||
* Cisco AS5400 with much higher capacity is waiting to be provisioned
|
||||
|
||||
== Challenges: Clocking
|
||||
|
||||
* TDM networks need a stable bitclock at all parts of the network
|
||||
* everyone must transmit and receive at the same rate of bits / frames
|
||||
* we use GPS disciplined oscillators (GPS-DO) to ensure same clock everywhere
|
||||
** this avoids overruns / underruns resulting in cycle slips that would create phase discontinuity for
|
||||
any modem signals carried over the network
|
||||
|
||||
== Challenges: Packet Re-ordering
|
||||
|
||||
* It seems like particularly on DOCSIS there is quite a bit of UDP packet re-ordering
|
||||
* Initially, osmo-e1d used a FIFO and dropped all out-of-order packets
|
||||
* later, we introduced a RIFO (Random In, First Out) to support re-ordering without loss
|
||||
|
||||
== Challenges: Packet Loss
|
||||
|
||||
* There is quite a bit of packet loss on the public internet
|
||||
* People probably don't generally notice much, as most services use TCP or retransmit UDP
|
||||
* Surprisingly, I couldn't find any comprehensive studies / research papers on packet loss behaviour of
|
||||
consumer internet that are less than 10 years old?
|
||||
* Right now we just accept it exists
|
||||
* Some early thoughts and experiments on FEC (Forward Error Correction)
|
||||
|
||||
== Challenges: Latency
|
||||
|
||||
* intercontinental public IP can easily reach >= 200ms RTT
|
||||
* ISDN timers in Q.921 and Q.931 are luckily working just fine over that kind of RTT
|
||||
* some suspicion that the high latency might have negative impact on Fax (T.30 timers) and modems (buffer
|
||||
sizes). I'm personally not yet convinced it is really an issue.
|
||||
|
||||
|
||||
// ***********************************************************************
|
||||
// Future Plans
|
||||
// ***********************************************************************
|
||||
|
||||
== Future Plans
|
||||
|
||||
* migrate OCTOI hub to co-location / data centre
|
||||
** higher capacity, better reliability, less packet loss
|
||||
* ISDN BRI (S/T) access to OCTOI network
|
||||
** more end-user friendly; many people have S0 equipment and no E1/S2M PBX at home
|
||||
* Frame Relay switch / hub
|
||||
** second, additional service, completely independent of the current ISDN service
|
||||
** initial testing has confirmed HDLC / FR over OCTOI works without problems
|
||||
* exhibits at hacker and vintage computing events
|
||||
|
||||
== ISDN BRI (S/T) access to OCTOI
|
||||
|
||||
* BRI (ISDN basic rate aka "S/T" aka "S0") support in OCTOI protocol
|
||||
* BRI hardware with 2x S/T interface and GPS-DO
|
||||
** unlike icE1usb: Ethernet/IP support, not USB
|
||||
** complete _appliance_ for OCTOI client mode: no need for computer
|
||||
** Status: design of first break-out / evaluation board for ISDN BRI side complete
|
||||
** Software not even started yet. Idea is to use Nuttx on Atmel SAMV71
|
||||
|
||||
== Longer-Term Future Plans
|
||||
|
||||
* improve FOSS soft-modem situation (linmodem, spandsp)
|
||||
* investigate somewhat limited V.90 performance so far
|
||||
* investigate somewhat limited throughput of PM3 in tcp-clear/telnet-forwarding
|
||||
* support for other Q.931 dialects than DSS1 (like 1TR6 or even NI1)
|
||||
* X.25 / X.31 support
|
||||
|
||||
== Thanks
|
||||
|
||||
Thanks to
|
||||
|
||||
* Sylvain "tnt" Munaut for icE1usb and all his help
|
||||
* All of the early OCTOI network participants manawyrm, gruetzkopf, roox, DrDeke, tmwawpl, cquirin
|
||||
|
||||
== Further Reading
|
||||
|
||||
* https://osmocom.org/projects/octoi/wiki[OCTOI Project Homepage/Wiki]
|
||||
* https://osmocom.org/projects/octoi/wiki/Proposed_efficient_TDMoIP[OCTOI Protocol Description]
|
||||
* https://osmocom.org/projects/retronetworking/wiki[Retronetworking Wiki]
|
||||
* https://osmocom.org/projects/osmo-e1d/wiki/Wiki[osmo-e1d software]
|
||||
* https://osmocom.org/projects/octoi/wiki/Proposed_efficient_TDMoIP[icE1usb hardware]
|
||||
|
||||
== EOF
|
||||
|
||||
End of File
|
||||
Loading…
Reference in New Issue