As a technology and marketplace, voice over IP is exploding. But reining it in from overnight world domination is the lack of a standard mechanism for prioritizing voice-over-IP traffic. Most voice-over-IP vendors acknowledge the problem and would be happy to implement a solutionc any solution -- if everyone would agree to do the same thing.

So here is my stake in the ground on this issue. It's called the Dial 100 Plan. That's binary 1-0-0, by the way.

My plan assumes that Resource Reservation Protocol is a nonstarter and the state-based Multi-protocol Label Switching is not going to achieve ubiquity any time soon. But there are three other mechanisms that do hold promise: 802.1p/q, the Layer 2 frame tagging that underlies virtual LANs; the type of service (TOS) octet, universal to all Version 4 IP packets; and Differentiated Services (Diff-Serv), an Internet Engineering Task Force draft procedure that restructures the TOS octet (RFC 2474).

The rules are simple. For all three quality-of-service (QoS) mechanisms, I propose their respective priority field be encoded 1-0-0 for any packet containing voice over IP, and that the 1-0-0 value be reserved for voice over IP. In a seven-level priority scheme, 1-0-0 represents a priority level of four out of seven.

Most equipment that outputs voice-over-IP packets today can "write" this value. However, many vendors still leave the fields 0 by default. Only a few write a particular value.

With 802.1p/q, a four-octet field -- the tag -- is inserted in Ethernet frames after the media access control addresses. The first two octets (the tag protocol ID) need to carry a value "8100," which designates that the packet contains an 802.1p/q tag. The second two octets (the tag control information) start with a three-bit "user priority" field. This is where the 1-0-0 value should be written for voice-over-IP packets. The next bit needs to be 0, and then there's a 12-bit field that carries the virtual LAN (VLAN) identifier, which can be any value from 1 to 4,096. I'm not saying any particular code is required here, but if you want a VLAN for just your voice-over-IP traffic, why not start this value with 1-0-0, too? The remaining nine bits can be whatever you want.

Then there's the TOS octet, which is the second octet -- bits 8 through 15 -- at the front of the 20-byte IPv4 header. The first three bits, known as the Precedence field, is the key voice-over-IP packet marking in this case. This field should be written, you guessed it, 1-0-0 for all voice-over-IP packets.

Then there's Diff-Serv. For consistency, the first three-bit field of Diff-Serv-encoded packets should likewise be 1-0-0 for voice-over-IP traffic. This is called the Diff-Serv Code Point High. The next three-bit field, the Diff-Serv Code Point Low, should also be encoded 1-0-0 for voice-over-IP traffic. This conveys the meaning that the packet is to be handled for minimal latency, a wholly valid instruction for voice-over-IP packets. The last two-bit field of the TOS octet would normally be 0-0. In other words, a voice-over-IP packet that's Diff-Serv-encoded would contain the octet value 1-0-0 1-0-0 0-0, which is 144 in decimal.

So there you havee it: One bit-head's proposal for achieving universal QoS for voice over IP. Let me know what you think.

www.nwfusion.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine