O'Reilly    
 Published on O'Reilly (http://oreilly.com/)
 See this if you're having trouble printing code examples


Subspace Networks: Hiding Circuit Switched Networks in a Packet Switched Network

by Brian McConnell
11/14/2006

Quality of service (QoS) has long been the bane of voice and video over the Internet, both of which require a stable constant bit rate connection to function well. Over the years, many plans have been floated to improve QoS, such as RSVP and DiffServ, but have not been widely implemented outside of corporate networks.

In this article, I describe a straightforward trick that can be used to embed circuit switched networking within packet switched LAN hardware, and do so in such a way that applications can be unaware that this is going on behind the scenes. I am calling this technique/hack subspace networking.

Over the past 10 years or so, there have been a number of attempts to create Internet protocols that allow TCP/IP networks to deliver the same reliability as circuit switched networks. One approach, which is simpler and more compatible with best effort routing, is differentiated services, where some packets are given higher routing priority than others. This is done at the IP level with the DiffServ protocol, and in Ethernet with 802.1p. While this is easy to implement since the devices at each routing point do not need to know anything about what's happening upstream or downstream, the chain is only as strong as its weakest link.

Another approach, which is more technically sophisticated, is to negotiate a route between endpoints that has guaranteed performance characteristics. In theory, this allows applications to reserve a block of bandwidth to create a quasi circuit switched connection with a guaranteed bitrate. The problem is that every device and ISP along the way must support this protocol, otherwise the chain is, again, only as strong as its weakest link.

TCP/IP networks were never designed to operate as circuit switched networks, which is the main reason why it has been difficult to implement QoS. But one interesting feature of the Internet is that it is largely an overlay to the circuit switched public telephone network infrastructure.

One way to do QoS is to design a device (e.g., a DSL modem/router) that looks to the devices connected to it like a standard best effort router, but is capable of establishing direct bearer channel connections to other devices. This essentially bypasses TCP/IP when it needs to nail up a constant bitrate connection with another device, for a voice/video call for example. I am coining the phrase "subspace networking" to describe this, because the router will drop down to establish a lower level connection to an end point, or intermediate router, and in effect bypass standard Internet routing for most or all of the route.

Here's a more concrete example. I used to do a lot of work with videoconferencing terminals. Until just a couple of years ago, most of these systems were dual-mode devices that could talk to each other via either a TCP/IP connection or an ISDN connection. ISDN, although more expensive, often worked a lot better because it was a circuit switched service that delivered 64kbits per bearer channel. With four ISDN lines, or eight 64kbps bearer channels, you could get near broadcast quality video without a glitch.

We can do something similar with last-mile devices (e.g., DSL routers) by enabling them to negotiate bypass connections with each other. There are a number of ways to do this, one of which is to use the DiffServ protocol as a way of indicating what type of bypass connection is required (e.g., one DiffServ level might mean 128kbps, while another means 1.5mbps), and to use a STUN-like protocol, perhaps combined with ENUM, to resolve physical layer addresses of the devices along the route between network endpoints.

The application using this feature, such as a videoconferencing program, does not need to know anything except how to use DiffServ. So if it needs a 512kbps connection, it can just start sending packets with the appropriate DiffServ code. The router/modem will then try to find a physical address for a counterpart near the endpoint IP address, and if possible, negotiate a direct bypass connection (e.g. PPP via ISDN, ATM, etc). This is invisible to the applications on both sides, which think they are talking to each other via a normal best effort connection. If it's not possible to negotiate a "subspace" connection, then the router falls back to best effort.

What is needed to implement this is a protocol for negotiating these direct connections between routers, typically endpoint devices at the customer premise, such as a DSL modem. This protocol does not have to be very complicated, and would work as follows:

  1. The device that is requesting a subspace connection opens a TCP connection to the destination IP (probably a NAT'ed address) on a port reserved for this protocol.
  2. If answered, the two devices handshake and announce their current physical addresses if the feature is enabled (e.g. an ISDN phone number, ATM address, etc).
  3. The devices agree on the number of bearer channels or virtual circuits required and/or available.
  4. The calling device initiates direct connection, if connection succeeds, devices send packets in serial order via subspace connection until data flow stops and/or device on either end explicitly ends the session.
  5. (Optional) To further increase efficiency the routers could extract data from each packet, and since the connection is a static route, strip out UDP or TCP headers, since all packets are going to the same endpoint. Properly formed UDP and TCP packets are reconstructed on the receiving end. This will effectively increase connection speed by about 20 percent.

This approach will also enable applications to combine best effort and subspace connections. For example, in a telepresence application, you want the voice/video data to be streamed reliably, so you'd route those packets via a 512kbps subspace connection. The other stuff, whiteboarding, remote desktop, etc., can tolerate variable throughput, so you send those packets via best effort. The subspace connection, which is invisible to the applications, will be hogging up 512kbits of your connection, whether it is all in use or not, so if there is contention, the packets sent to the best effort routing address will be dropped or delayed.

This technique can be used to negotiate end-to-end circuits, where one router establishes a direct PSTN connection to another, but can also be used to setup CPE to CO circuits on each end of the connection. In the first case, both customer premise devices are connected to the same type of network, e.g., a LEC DSL line and can establish direct multibearer channel connections with each other. Because of the variety of physical layer connections in use today, this will generally only be possible when the devices are connected to the same regional network (e.g., one DSL user wants to connect to another DSL user on the same net).

However, because the real issue with reliable voice and video calls is the so-called last mile, a direct end-to-end connection is not needed in most cases. Instead, we can create two subspace connections, one on each side of the connection, between the end users and their ISPs backbone. In this scenario, the router on each end of the connection negotiates a subspace connection with the CO, and assumes that best effort routing will work fine from that point onward. This two-hop approach will allow users on different types of networks to establish quasi circuit switched connections over TCP/IP networks.

This idea is admittedly not a cure all, and is not a pure solution as it breaks the layered network model. However, the Internet by and large rides on top of the public telephone network with its circuit switched architecture, and I believe it's worthwhile to examine ways to use that where it makes sense.

Pure, abstract systems are elegant, but they often do not perform as well as those built on lower-level interfaces. Java is a case in point. It's a great language for many applications, but if you need to do something computationally intensive, such as graphics processing, you have to use something like C or a DSP card that is specially designed for graphics operations.

I think we're at a similar point with voice and video over the network. TCP/IP was never designed with constant bitrate applications in mind. So rather than try to make it do something it was not designed to do, why not use TCP/IP as a way for voice/video devices to find each other, and then if possible, setup dedicated connections via a lower level interface? We can use technical chicanery to make this messy hack look like a normal best effort connection to the applications using it, albeit one that just happens to be a lot more stable.

Brian McConnell is an inventor, author, and serial telecom entrepreneur. He has founded three telecom startups since moving to California. The most recent, Open Communication Systems, designs cutting-edge telecom applications based on open standards telephony technology.


Return to O'Reilly Emerging Telephony.

Copyright © 2009 O'Reilly Media, Inc.