In my last blog regarding “The Internet is getting too full”  I illustrated a bit on how connection-oriented Ethernet may resolve some of the problems caused by the connectionless nature of nearly all networks connected to the Internet. In a prior life I taught advanced ATM (Asynchronous Transfer Mode) to primarily Ethernet engineers at Cabletron Systems. Because of this technology, I learned to appreciate many of the features implemented in traditional telephony. In this blog I will draw some comparisons between telephony and data communications.

HALT, who goes there?
One of the problems we are seeing with Ethernet networking today is that many businesses do not want people simply walking into a company and getting access to the network. Although Ethernet originally evolved to make it very simple for people to ‘data’ communicate, it seems that most companies today have implemented LDAP, Active Directory, radius, mandated password changes, secure wireless networks, SSL, 802.1x etc. to keep out unapproved hosts.

In some connection-oriented communications (COC) such as ATM, the host can’t simply broadcast out onto the network heralding “Can I have an IP address” for everyone to hear “Excuse me everyone, can someone help me?”.  Unlike DHCP, in COC, all hosts are preprogrammed with who they need to contact first for all communications. Think of this as going to the operator or opening up your phonebook so that you can type in the exact address of who you want to communicate with.

Let me see your papers
When initiating communication to a destination, a connection-oriented switch will look up who is the host and confirm that it has permission to talk to the destination. It could also determine the source host’s committed information rate (CIR), burst rate, QoS, etc., all done prior to allowing any communication. NOTE: This is all done prior to passing data.

All switches and routers in the path would precommunicate and have to set aside bandwidth for the connection. They have to agree on the QoS prior to allowing transfer to take place. If an agreement can’t be made, the source host receives an “all circuits are busy now, please try your connection again later” message.  That doesn’t sound so novel an idea does it?

COC adds connection setup overhead however, let’s list the potential benefits:

  • Feature: A host can’t send more than the allowed CIR but it is guaranteed.
  • Benefit: No one fights for bandwidth at the CIR level.
  • Feature: A quality of service (QoS) is set aside for the host.
  • Benefit: Time sensitive data is given proper priority.
  • Feature: A maximum burst rate is allowed but not guaranteed like the CIR.
  • Benefit: Contention among connections only occurs for the burst rate.
  • Feature: Security is checked at call setup.
  • Benefit: The source may not even be able to approach the destination without ingress authorization.
  • Feature: 100% accountability and control.
  • Benefit: Less communication chaos and hackers have less chance to wreak havoc.

Perhaps if data communications followed some of the steps used in the telephony world for call setup, we could avoid some of the lingering congestion problems the Internet may be facing.

Mike Patterson author pic


Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.


Leave a Reply