September 16, 2014

How SDN Can Multiply VoIP Channel Capacity


Flanagan.JPG
Pull out a fresh napkin or turn over that envelope: we're going to compare the bandwidth requirements for voice connections on public networks. First is the legacy PSTN based on time division multiplexing (TDM). The other is what may be its replacement, the all-IP infrastructure where voice, video, data, and texting converge--VoIP for short.

We'll assume the calculation for TDM is well known: a constant 64 kbit/s in both directions.

For VoIP, start with today's routing procedures, add IPv6, and encapsulate in Ethernet for access to the WAN. We'll ignore PPoE (Point to Point Protocol over Ethernet) headers; while still used for some Internet access, it likely will disappear. Then we'll compare bandwidth use in a traditional routed network to the potential bandwidth per channel on an SDN.

VoIP may not be as inevitable as death, but it is surely in the 'taxes' range. People who designed, built, and operated TDM switches and multiplexers are almost all retired (present company excluded). You can't get parts to continue building the old designs and nobody will invest in R&D for a new TDM switch. So get used to VoIP.

Fans of IP often celebrate that IP is more efficient than TDM transmission, granting bandwidth on demand and only when needed.  The question for today's exercise, however, is how many voice connections will a pipe of a given size (and cost) carry.  For examples, what is the capacity of a dedicated access link from a SIP trunking provider, or a long distance connection between countries.

The Table below summarizes some rules of thumb and engineering practices.  The numbers reflect voice channels on a T-1 access link, but extrapolate to larger pipes.  Note that a voice TDM link behaves the same up to 100% utilization.  For packet transmission good practice keeps throughput to something less than the link capacity, 80% here.  To give each party on a call equal opportunity to speak, and to avoid the possible confusion of doubling the bandwidth of a connection, we'll specify full duplex Ethernet.

vl91-table.jpg

VoIP today carries several headers on each packet. Looking long-term, we use IPv6 in the calculations.

Real Time Protocol (12 bytes) + UDP (8) + IPv6 (40) + Ethernet (28) = 88 bytes per packet

Many VoIP systems create one packet every 10 ms: 

                       100 packet/s x 88 bytes/packet x 8 bits/byte = 70.4 kbit/s for the headers.

Encoded voice most often is 64 kbit/s PCM. Look ahead to High Definition voice at 32 kbit/s and the total remains more than 100 kbit/s per voice channel. Compressing voice information to 8 kbit/s (in use by some carriers) drops the minimum requirement to 79 kbit/s. Each byte of voice payload needs multiple bytes of headers.

Most of those headers are used by routing protocols and switches in a discovery protocol to find hosts. There could be more headers for additional features: virtual LANs, LAN emulation services, authentication, IP security, etc. At least one vendor has used the longer TCP header in place of UDP. Some networks could add an aggregation header to define busy routes shared by many connections.

Enter Software Defined Network (SDN) technology that calculates routes in a central server, not in each packet handler (router or switch). If the SDN controller instructs each device how to handle packets, the way a Label Distribution Protocol sets up forwarding tables based on labels, then all the IP, UDP, RTP, and other addresses contribute nothing to how the packet finds its way through the network. Only the label matters.

To save bandwidth, start at the entry point of the network.  There replace all the IP-related headers on a packet with a token, very much like the MPLS label. The addresses associated with the token are added back to packets at the exit point from the network.

The Frame Relay Forum worked out most of the packet formats for voice and signaling 15 years ago in the implementation agreement (FRF-11)) for voice over FR, but routing remained proprietary to each vendor. The IA needs a few tweaks but it boasts some interesting features.

As the GPS says, "Recalculating" the bandwidth for a 6-byte label:

6 bytes x 100 frames/s x 8 bits/byte = 4.8 kbit/s

For HD voice compare 37 kbit/s vs. 103 kbit/s.  FRF-11 defined a format to put payloads from multiple channels in one packet.  That saves a little in the headers but seriously cuts the packets per second burden on switches.

With centralized SDN call setup, the packet handlers don't need any information beyond how to handle a packet with a given token. The exit device restores headers to the packet as it leaves the network.

If you want to get a jump start on saving bandwidth--the SDN way--I can point you to sources for well proven VoFR protocol stacks.  They have some bonus features that makes packet handlers much more productive.

This approach looks in some ways like header compression, MPLS, and Frame Relay.  But we'll think up a new name for it as historically we have for every change in network technology.

NOTE: a patent application filed in the US covers portions of the technology described.



1 Comment

Will SDN really solve all of the legacy problems?

A boon and bane to TDM is the ability to "route" around path outages. The boon: sub-second reaction (as low as 50 ms). The bane: typically requires single provider solution, good entrance facility, high cost of "end-end" facility and under-subscription (1 path is effectively idle) and the TDM path change occurs only when there is a recognized complete path outage.

In some ways IP routed networks get around many of the disadvantages of TDM, but not without it's own problems; slower reaction time, indeterminant performance in face of network issues (packet loss, excessive delay and jitter), no intrinsic ability to intelligently aggregate multiple paths. There are mature proprietary solutions that get around many of these IP disadvantages, but they are costly and complex.

Can SDN in a VOIP scenario (for this discussion implies WAN) solve the legacy problems? Can it perform fast to respond to real life path events without using expensive single provider proprietary solutions?

Leave a comment

Search Webtorials

Get E-News and Notices via Email


  

 



  

I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites






















Archives

Notices

Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.