Position: home/contact >
connection oriented routing project
cor - connection oriented routing
Cor is a layer 3+4 protocol mostly for wifi mesh networks. It is not based on TCP/IP. Instead it replaces it or runs in parallel. The main differences are:
- Connection oriented: Connections are established between neighboring routers and not end-to-end. Each router on the path reassembles the received packets and splits them if needed before sending them to the next router. Retransmissions of lost packets are handled between neighboring routers as well. (The checksum and keepalive is handled end-to-end.)
- Source routed: The entire route is calculated on the source host. The routers do not decide where data should be forwarded to. Each router has a small command interpreter for commands like "list neighbors", "connect to neighor x" and "connect to port y". The routing process on the client side will use these commands to discover the network step by step and establish connections on request.
- Ports are 32 bit long. The routing table contains a list open ports for each host. If the application with an open ports wants it to show up in this list, it needs to do one setsockopt() call. (Open ports are not added to this list by default.)
- Flow control: Cor does not need to wait for packet loss in order to know when to slow down. The sender will know basd on the window size. (If there is packet loss on a link, cor will slow down if it is configurated to do so. This is done so it can run parallel to TCP/IP).
- There is 1 address per host and not per interface. There are no subnets. The address is optional for hosts which only need to establish outgoing connections and do not need to handle incoming connections or forfard data for others.
Why?
- Less overhead: The headers for each packet are much smaller and Cor can make use of large MTUs even if not all links on the path support this. It also sends less acknewledgements and other small packets. This means there is more bandwidth for applications. The effect is largest on Wifi links and with rts/cts enabled.
- Flexible routes: The routing process on the client can establish the route it wants. There is no risk of routing loops if others disagree on what the best route is. (On the other side, routing loops can be intentionally created by the client.)
- Graceful under load: Background traffic can set its priority to low so it does not slow down time foreground traffic. Connections which are mostly idle get a priority boost.
- The configuration is more simple.
- The source address is not propagated through the network. Each host sees only the previous router.
The disadvantage in that there is more cpu load and memory usage on each router.
Development state
Cor is currently in alpha state. You can run it, but I currently recommend its use only for testing purposes.
- The wire protocol is not frozen yet.
- The are some open tasks related to performance.
- There code has not been reviewed by the linux kernel developers yet. I suspect some interfaces with the rest of the kernel contain issues, including security ones.
Getting started
The user space tools contains cor_perfs (benchmarking server) and cor_perfs (benchmarking client). You can also use the "--fwd-to-" options of cor_routed if you want to use applications which are not cor-enabled.