IP Convergence: Beyond VoIP, Beyond Cost Savings

In a comment on this post from one of our readers, Christopher Wacker writes:

To me, it sounds like you A/V issues lie with your networking.  I work for a MPLS consulting firm (if you don't know what MPLS is, you can take a look at http://mpls-experts.com/default.asp?page=pages/whatismpls.asp&v=nontech for a brief overview of what MPLS is) and have noticed this problem quiet often with companies.  Are you currently using ATM/Frame Relay?

I am somewhat familiar with MPLS.  :-)

I was an IP Engineer at Frontier Globalcenter when we were doing our rollout of MPLS back in Q1 1999, which coincidentally was the first deployment of MPLS in any production IP network anywhere.  We deployed the mesh nationally in Q2 of 1999, and according to our primary core vendor at the time (Cisco), we were the first carrier with a nationwide deployment of MPLS. With the acquisition of Frontier by Global Crossing, we began building new POPs internationally in Europe and Latin America over the first half of 2000, and our US domestic MPLS core became an international one..

It was a tough time for us to deploy MPLS.  The standard was so new it wasn't even a standard yet, it was still in draft.  There were lots of bugs in our vendors' routing code.  Deploying Juniper created additional complexities because each vendor interpreted the RFC's and Internet Drafts (pre-RFC's) differently, which occasionally led to some very interesting network behavior.

But I digress.

Towards your question around the use of ATM/FR, I am not directly connected to our corporate network with ATM/FR or MPLS, which is the root of my problem and a common plague of the telecommuter.  I use a local ISP who buys transit from someone other than Global Crossing, and the performance is often less than desirable. 

For the sake of argument, let's say that I was connected directly to the corporate MPLS network, would my QoS problems be solved?  Would I be able to set different ToS bits on the video packets coming from communicator compared with the voice?  As near as I can tell, there are no such settings in MS Communicator 07, and if that is true, then all packets originating from my computer will look like any other data packets and will not get any special treatment on the network. 

QoS on MPLS works great, but if you can't differentiate packets in some way (IP address range, port range, or ToS bits) you won't be able to take advantage of it.  Usually, differentiating packets within the same application (say OCS) is impossible to anywhere other than the application itself.  I say usually because it is possible that if the application uses different ports on seperate rtp streams, and you can tell which one will always be video and which will always be voice, you can probably work something out on the CPE router to classify the packet, but it would certainly be easier to just set the parameters in the application.


Perhaps one of our readers knows if it is possible to set the ToS packets within OCS?