The Internet Protocol (IP) | IPv4

Ethernet defines how devices can be physically connected. But users do not know the Ethernet addresses of the devices providing the services they wish to use. More intelligence is needed to separate out the physical addressing, replacing it with logical addressing that an administrator can decide on, and allow multiple physical networks to be connected. The Internet Protocol (IP) defines how this addressing and packet formatting is to occur.

IP was originally specified in RFC 791 and expanded upon later, and comes in two versions: version 4 (IPv4) and version 6 (IPv6). The two main concepts for IP are the IP addressand IP frame.

IPv4

IPv4 is the version used most often on the Internet today, by a wide margin. IPv4 uses a four-byte address written out as dotted decimal numbers, such as 192.168.0.1. These addresses are given out by an international agency in blocks for large organizations to use. Generally, individual IP addresses are provided to organizations by their Internet service providers. Ranges of addresses tend to be specified using the slash notation. For example, 192.168.0.0/16 means that the upper 16 bits are what was written, and the rest are within the range defined by allowing the remaining lower bits to be set to any value.

Of the 32-bit address space, some of the addresses have special meanings. The 127.0.0.0/8 address range is for loopback networking, and, when used as a destination, are kept internally to the machine that is doing the sending. This allows an IP device to send packets to itself. The 169.254.0.0/16 range is for link-local addresses, meaning that their use cannot extend past the Ethernet switching network they are used on. In addition, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are all private addresses. These are the addresses most commonly used in voice mobility networks within the enterprise. They are not valid on the public Internet itself, but are designed for private networks based on IP. The 224.0.0.0/4 network is used for multicast traffic: each address is a different multicast group. Finally, the 255.255.255.255 address is the link-local broadcast address, meant to go out to all devices on the Ethernet switching network (and using the FF:FF:FF:FF:FF:FF Ethernet broadcast address for the underlying packet).

IPv4 runs on Ethernet by setting the Ethernet type to 0×0800. The IP packet has a header and payload, as shown in Table 1.

Table 1: IPv4 Packet Format

Table 2: The Version/Header Length Field

	Version	Header Length
Bit	0-3	4-7

The Version/Header Length field is specified in Table 2. For IPv4, the version is always 4. The header length measures how long the header is (up to the data field), in four-byte increments. The Type of Service/Diffserv Code Point (TOS/DSCP) field is used to specify the quality-of-service properties of the packet. The Total Length measures the entire length of the packet, and will come into play with fragmentation. The Identification field is used to track which fragments belong to the same overall packet; between separate packets, most devices tend to increment this by one, although this is not required. The Fragment field specifies what the offset is for this fragment in the entire packet. The TTL (Time To Live) field is used for forwarding, and specifies how many times this packet can be forwarded before it is dropped. The Protocol field specifies what higher-layer protocol is used on top of IP for this packet. The Header Checksum is a literal one's complement 16-bit sum of the header of the packet, and is used to detect if the underlying network flips a bit by mistake. (The Ethernet CRC is adequate for that purpose, so this field, although always set and always checked, is not terribly useful.) Finally, to the interesting information. The Source and Destination fields hold the IP addresses of the originator and final destination of this packet. The header ends here, and is followed by the next protocol's headers or data. This entire set of bytes is the payload of the underling Ethernet frame.

IP is designed to be relayed, or forwarded, between computers, across different network segments, and across the world if needed. This is the major distinction for IP, as it hasallowed the Internet to be constructed from an assembly of smaller networks. The idea is that any IP-connected device that has multiple links can forward messages if configured to do so. Each link has its own IP address, as required. When an packet comes in for an IP address that is not that of the machine (how that happens will be mentioned in a moment), the device will look up a routing table to find out where the next machine is that this packet needs to go to. IP forwarding works on the concept of longest-prefix matching. Because there are too many IP addresses for a machine to know about, and because the IP address space tends to be organized in ranges, the forwarding device (arouter in this context) looks up a series of routing rules that it has configured. Each routing rule is set up as a network prefix (as specifiable by slash notation), and the IP address of a machine that is on one of the links the router has. This address is the next hop. Because a destination address might match more than one rule, the one rule that matches the most leading bits-the longest prefix-will win, and that next hop will be used.

This concept of next hops explains why a router or machine may get a packet for a different destination IP address than it uses for itself. If another machine is set up to forward packets to it—and any machine can be set up to forward to any other, without restriction, so long as both are on the same switching network—then the first machine will get packets for other devices. The concept of prefix routing makes sense when you think of most enterprise routers. Enterprises, all but the largest, usually have a limited number of address ranges that are used locally. All of the rest, every other one, is out on the Internet. Connecting the enterprise to the Internet is one Internet router. The enterprise routers thus need only to have forwarding rules for the address ranges that they have in the enterprise, plus one route, called a default route, that tells the IP address of the Internet router. This default route uses a 0.0.0.0/0 prefix, meaning that every address matches, because the prefix is trivially short. Therefore, longest-prefix matching ensures that the default route matches last. Nonrouters will normally only have this default route, because they will not forward other devices' traffic. In this way, locally generated traffic is forwarded, even when other traffic will not be. The final bit of information to know is that not all traffic is forwarded on to next hops. Each link into the system has not only an IP address but asubnet mask, or a prefix that specifies what other IP addresses are directly on that link. For example, using the same slash notation, 192.168.10.20/24 states that the IP address of the link is 192.168.10.20, and all IP addresses starting with 192.168.10 are directly on the link, and do not need to be routed to the next hop. Those direct-link addresses belong to the same subnet. Every time the frame is forwarded, the TTL is reduced by one. Once it hits zero, the packet is dropped, rather than forwarded. Nothing else is modified while the packet is forwarded—the source and destination addresses are always those of the originator and the final destination of the packet.

Because IP runs on top of Ethernet, there must be a way to map IP addresses to Ethernet addresses. Every IP address has an Ethernet address—that of the Ethernet device the IP address was assigned to. When a sender needs to send out an IP packet, and it has used its forwarding logic to figure out which link the next hop or final destination is on, the sender needs to use a resolution protocol to ask the devices on the network for which one has the IP address it needs. The protocol is called the Address Resolution Protocol(ARP). ARP runs on a different Ethernet protocol type 0×0806. The idea is that each sender maintains an ARP cache. This cache stores the Ethernet address that is known for a given IP address. The cache is updated whenever another device sends a packet to the first one, as the Ethernet source address is assumed to be bound to the IP source address, so long as that IP address is on the same subnet. However, if the cache does not have an address mapping that is needed, the sender will send an ARP request to the network. These ARP requests are broadcasted using Ethernet, and any device that receives the ARP request and has that IP address is required to respond, unicast to the ARP sender, acknowledging the binding with another ARP message. The format of an ARP message is shown in Table 3.

Table 3: ARP Message Format

For Ethernet networks, the Hardware Type is always 1, and the Protocol Type is always 0×800. The Hardware size is the length of the Ethernet address, 6. The Protocol Size is the length of the IP address, 4. There are two opcodes: 1 is for a request, and 2 is for a reply. Finally, the addresses state the mapping that is requested or being answered for. When a machine requests to find out which other device has an IP address, it will send its Ethernet and IP addresses as Sender, and the IP address it is looking for as Target, with the Target Ethernet set to 0. The respondent will fill in its Ethernet and IP address as sender, the original requester's Ethernet and IP as target, and then send the response back.

With ARP, the binding of IP addresses to Ethernet addresses can be dynamic and changing.

Earlier, the concept of fragmentation was alluded to. IP provides a service that lets a packet be split across a number of smaller packets. The reason for this is that IP is meant to be carried over a wide variety of link-layer technologies, not just Ethernet, and those technologies may have a different maximum payload size. To make sure that a packet that is of a valid length that is sent in one network can arrive safely at the other, the concept of fragmentation was introduced. The router, or sender who has a packet which is too large, and which does not already have the "Do Not Fragment" bit in its Fragment field set, will divide the packet into two or more smaller ones, each with a copy of the original IP header.

The data fields will be the individual segments, with the offset of the first byte of the data field from the start of the original (or reassembled) packet being given in the Fragment field. The fragments are sent over the network, and the receiver is required to reassemble all of the fragments before sending it up to the higher layers. The receiver knows that it has reached the end of the fragment chain by looking at the "More Fragment" bit in the Fragment field. The last fragment will not have that bit set. All fragments of an original packet share that packet's original Identification field. The maximum size of an IP packet, including all headers, is 65,535 bytes.

IP, like most other packet networking technologies, makes no guarantees as to whether a packet will arrive at its destination. Packets may arrive with arbitrary delays, and may even come out of order (although this is to be discouraged). This best-effort delivery guarantee-the network will try, but will not commit resources up front-is key to IP's success. It, unfortunately, also runs counter to the goals of voice.

Clearly, IPv4 is the bread-and-butter protocol for voice mobility. What was presented here was a brief, high-level survey, and readers are encouraged to fill any major gaps in understanding before undertaking major roles in voice mobility networks.

Ethernet | Wireline Networking Technologies and Packetization

Nearly all wireline voice mobility networks in the enterprise start with Ethernet. Ethernet is a family of related networking technologies that establish how two machines that are physically connected can talk to each other. Ethernet was designed to be as simple to deploy as possible, so that it can be set up as an unmanaged network, where physically connecting two endpoints together, somehow, through the network is enough to allow them to find each other and communicate. (Note that this doesn't mean that higher-level protocols will work on this network without effort-just Ethernet itself.)

All of the Ethernet protocols belong to the IEEE 802.3 series and are based on the idea of encoding frames. A frame is a well-defined packet message, with a source, a destination, a length, and a type. The logical format of the Ethernet frame is shown in Table 1.

Table 1: Ethernet Frame Format 

Destination	Source	Ethertype	Frame Body	FCS
6 bytes	6 bytes	2 bytes	n bytes	4 bytes

In Ethernet, links are anonymous. Endpoints, however—the line cards that the Ethernet cables plug into—are given addresses. These addresses are assigned at the time the device is built, and are permanently associated with the device. The Ethernet address is a 48-bit (6-byte) address, as shown in Table 2. The first three bytes, or 24 bits, is called the Organizationally Unique Identifier (OUI). Each manufacturer of Ethernet equipment is assigned one or more of these OUIs by the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority. The manufacturer chooses the second 24 bits from a unique pool, often in order starting from 00:00:01. Together, the scheme guarantees that this address will never be accidentally taken by another device.

Table 2: The Ethernet Address Format

	OUI	Manufacturer-Defined
Bit:	0-23	24-47

	L	G
Bit	6	7

Ethernet also defines two special flags in the address. The L bit specifies a local address, which is dynamic and invented by a device for temporary usage. This has an application in Wi-Fi, but is otherwise not common. The G bit is for group-addressed frames-either broadcast or multicast. A group-addressed frame is meant to go out to multiple devices at once, for all of them to receive. Multicast transmissions use this mechanism. The special group address FF:FF:FF:FF:FF:FF (all 1s) is the broadcast address, and specifically requests to go to every device, whether they are in a multicast group or not.

This is one way by which Ethernet guarantees that it does not require management to add or remove devices from the network. When a device wants to transmit over a wire to another device, it has no way of knowing if that second device is there. Ethernet was intentionally designed to be as simple as possible, so senders have to transmit and hope that the other device is there. When the sender creates a frame, it places the destination Ethernet address first in the frame, followed by its own address. Then comes the type of the frame, used to figure out what network protocol is running on top of Ethernet. An arbitrary frame body follows, subject to size restrictions: the body of the frame cannot be greater than 1500 bytes, usually, and cannot be less than 64 bytes. (Shorter frames must be padded.) Finally, Ethernet provides a way to determine whether noise on the Ethernet line causes any bit errors, by using a. frame check sequence (FCS), a mathematical checksum of the bits in the frame that will generally not match the contents of a frame if there are any errors. Ethernet uses a CRC-32 checksum.

Ethernet itself is a serial protocol, much like serial lines used to connect modems together, but operating with much more sophistication and at a faster rate. Most Ethernet types today fall into two categories: copper and fiber. The commercially available copper Ethernet technologies all use a modified version of a telephone cable, made out of copper wires. Each cable carries eight small, insulated copper wires, twisted into pairs as is done for analog telephone lines. The plastic connectors at each end also look like telephone connectors, but have eight pins, rather than the usual six. These connectors, often referred to as RJ45, a specification in which the connectors figure prominently, snap into thecorresponding sockets on all Ethernet devices. Differing numbers of the pairs within the four-pair cable may be used for different Ethernet technologies.

The first RJ45-based Ethernet is called 10BASE-T, or simply original Ethernet. Devices that support 10BASE-T run at 10Mbps, across just two of the pairs within the cable, one for reception, and one for transmission. (The other pairs are not used for data.) These Ethernet lines run a serial protocol, where the voltage on the line is flipped to signal a one or a zero in the bits used to encode the frame. However, these serial lines do not constantly transmit. Instead, the line is usually idle. But when a device wants to transmit on the line, it simply starts transmitting. The transmission itself is the frame, just described. Before the frame itself is sent, a few bits are prepended to it. These bits, known as thepreamble, are used to alert the device at the other end that the transmission is going to begin. The preamble is a 64-bit sequence of alternating ones and zeros, except for the last two bits, which are both ones. The receiving device detects that a transmission comes in, by looking for the sharp swings in voltage in the line from idle, representing the preamble's bits. By the time the preamble is done, the receiver will have figured out the timing of the bit patterns, in case the receiver's clock is slightly off from the sender's. The full bits of the frame proper come in, including the checksum. At the end of the transmission, the sender and receiver have to wait for a few microseconds, and then the line becomes idle and ready to be transmitted on again.

Given that 10BASE-T is a point-to-point physical system, as there can only be one transmitter on one twisted pair, and the other transmitter on the second, there needed to be some way to interconnect multiple lines and thus multiple devices together. The solution to that is the Ethernet hub. The hub works by connecting the twisted pair that is used by a device to transmit, to every link's twisted pair used to receive. This connection allows the transmission by one device to reach all of the others on the same segment, or other devices attached to the same hub. Hubs are purely electrical, and do not participate in the network itself. When a device transmits on an Ethernet hub, every device on that hub hears the signal. A receiver knows that the frame is for it by looking at the destination Ethernet address. If the address matches, then the frame is kept; otherwise, it is discarded unless the operating system on that device requests to receive all frames on the line. The use of hubs, and the definitions for 10BASE-T, require that the transmissions are all half-duplex, meaning that a reception and transmission cannot occur independently.

Adding multiple devices together on an Ethernet link introduces a problem. Two or more devices are capable of transmitting at the same time. If two devices do transmit at the same time, their signals will mix on the wire, and all of the receivers will receive the garbage created by the interference. Thankfully, there is a solution to avoid this. The overall concept is known by the unwieldy phrase Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Let's break that phrase apart, starting from the end. The collision detection portion of Ethernet works rather simply. When the device starts transmitting, it watches the receive twisted pair for its own transmission to return to it. If it sees a signal that differs from its transmission, more than just by a delay, it knows that another device is also transmitting. To prevent wasting time by having both signals clobber each other, the transmitter stops transmitting the frame and sends out a jamming signal for a short burst to ensure that the line is dead. The senders then retry their frame, up to a certain number of times. If the signal does not get clobbered by the time the frame reaches the end, the sender knows that the frame must have made it down the wire safely. If that were all to it, however, two devices with data to send would never be able to avoid colliding. That is because they would both detect the collision at nearly the same time, stopping their transmissions and waiting the mandatory time for the line to come back to quiet, and then they would transmit their next frames immediately. The segment would be in constant collision. To avoid that, the CSMA portion of Ethernet is used. Carrier sense is the act of detecting that a transmission is already on the line. First, the devices check the receive line, to make sure that a signal is not coming in already, corresponding to a transmission already in progress. If there is a transmission in progress, the transmitter waits until it ends. Then it transmits. If a collision occurs, CSMA uses the notion of a random backoff. Instead of each device transmitting exactly after a fixed time from the previous frame after the collision, each device picks a random integer greater than or equal to zero and less than the maximum backoff for this transmission. They then wait that many of slots, each one measured in microseconds, before transmitting again. This step reduces the probability that the devices will collide a second time. If the collision occurs again, the maximum backoff doubles, starting from the first backoff of two slots. This process stops when the frame is successfully transmitted, or abandoned. The next frame will then go out with no backoff.

The problem with backoffs is that they lead to unstable behavior when the network is loaded. This congestion occurs because of excess collisions, and more and more of the time on the network becomes dedicated to retransmissions and less time to new data. The solution to the problem was with the introduction of the Ethernet switch. The Ethernet switch is similar in concept to the telephone switch. A telephone switch isolates the paths between two connections, allowing two devices to speak at a time as if they were directly connected, independent of the other traffic. An Ethernet switch doesn't directly connect circuits, being packet-based, but it does eliminate one device's dependance on the transmissions of the other devices.

The Ethernet switch works by terminating each Ethernet link. Whereas a hub ties the multiple links together into one interconnected collision domain, the switch acts as a separate receiver for each connected device. Two or more devices can transmit at once, on their individual ports, and the switch will independently receive and gather the frames. The frames are then analyzed, interpreted for their destination addresses, and the frame is then sent out on the link that has that address. Because the switch has to read and understand the Ethernet frames, its job becomes one of a traffic director. The concept of simultaneous reception resolves collisions between two endpoint devices, but the switch goes further, by performing the above-mentioned detection of which device is on each link. This function is a crucial part of bridging traffic, and works by the switch maintaining a learning table, built up dynamically, of the Ethernet addresses that have been seen as sources on each link. This table is essentially soft state, meaning that the entries are not permanently recorded, and are built up or refreshed as needed. The last remaining problem is for when the switch gets a frame whose destination address has not yet been learned. In this case, the switch just forwards the frame on every port on the switch, except for the one the frame came in on.

With a switch, the transmit side of each Ethernet link can become a bottleneck. Multiple frames can come in destined to one link, especially if this link holds a common server of some sort. When this happens, the switch is forced to build a backlog of pending transmissions, known as a queue. This queue is a list of packets, usually ordered first-come, first-serve, or first-in, first-out (FIFO). One of the switch's major benefits is that it has translated the resource contention that occurred with hubs into an orderly, predictable wait for packets to get to a popular resource.

The other benefit of a switch is that the collision concept can now be removed entirely. Because, on a switch, there are only ever two possible transmitters on a link, and because there are separate transmit and receive pairs, there is no reason for the receiver to echo back the transmitter's signal. Instead, each device can operate the transmit and receive lines independently. This is known as full duplex operation.

Full duplex operation was introduced with 100BASE-TX, or Fast Ethernet. Fast Ethernet runs at 100Mbps for each direction, greatly increasing the possible data rate on the line. Fast Ethernet uses the same cables and connectors as the original 10BASE-T Ethernet (though lesser-quality cables of the type cannot be used), and the standard defines Fast Ethernet to be backward-compatible with the original. The mechanics of the Fast Ethernet encoding are more advanced than that of the original Ethernet. I will not concern you with the details here, as Ethernet signals are rarely noisy and insight into the encoding is not necessary. The key is that the frame format remains the same, but the data rate is ten times that of Ethernet. Additionally, because Fast Ethernet can use a switch, the backoff procedure is no longer required when transmitting to a Fast Ethernet peer. However, Ethernet hubs are still allowed. Furthermore, 10BASE-T devices may still be connected to a Fast Ethernet port. To determine whether the device can use the 100BASE-TX standard, a protocol known as autonegotiation occurs. Autonegotiation starts as soon as two ports are plugged together. 100BASE-TX devices send out special signals on the line, establishing that it is using 100BASE-TX and communicating its duplex setting. If the other side is also 100BASE-TX, the link will use Fast Ethernet. On the other hand, if the other device does not respond with the other signal (and instead sends the usual 10BASE-T link detection pulses), the 100BASE-TX device will downgrade until the link is unplugged.

Gigabit Ethernet over copper is specified in the 1000BASE-T standard. Gigabit Ethernet, again, is backward-compatible, and uses similar cables, though with tighter quality requirements than either of the previous standards. One major difference for Gigabit Ethernet is that it uses all four twisted pairs in the cable. Combined with using a more advanced bit coding, this produces the extra speed-100 times faster than the original Ethernet.

The IP-Based Voice Network

Voice started out on analog phone lines. Each pair of copper wires was dedicated to one specific phone, and to nothing else. This notion of a dedicated circuit has its advantages. It provides complete isolation of whatever might be going on with that line from the circumstances and problems of other phones in the network. No amount of calls being placed on a neighbor's line can make the original line itself become busy. This isolation and invariance is necessary for voice networks to function when unexpected circumstances occur, and ensures that the voice network is reliable in the face of massive fluctuations in the system. Provisioning is simple, as well, with one line per phone at the edge.

The problem with the concept of the dedicated line is that it is extremely wasteful. When the phone is not in use, the line stays empty. No other calls can be placed on that line. Even when a call is in place, the copper wire is fully occupied with carrying the voice traffic, a small bandwidth application, and a tremendous amount of excess signal capacity exists. Dedicated wires might make sense for short distances between the phone and some next-level aggregation equipment, but these dedicated lines were used as trunks between the aggregators, causing tremendous waste from both idleness and lost bandwidth. But probably the property that caused the most complications with wireline networking was that the dedicated line is not robust. If network problems occur-the bundle of cables is cut, or some intermediate equipment fails and can't do its job-all lines that are attached along that path are brought down with it. Digital telephone networks started to eliminate some of the problems inherent to the oneline dedication of early circuit switching. By having digital processes encode and carry the voice, more voice calls could be multiplexed onto each line, better using the bandwidth available on the copper wire. Furthermore, by allowing for hop-by-hop switching with smarter switches between trunks, failures along one trunk could be accommodated. However, the network was still circuit-switched. A voice line could be used only for voice. Even where voice circuits were set aside for data links, the link is either fully in use or not at all. The granularity of the 64kbps audio line, the DS0, became a burden. Running applications that are not always on and have massive peak throughput but equally meek average throughput requirements meant that provisioning was always an expensive proposition: either dedicate enough lines to cover the peak requirement case, and pay for all of the unused capacity, or cap the capacity offered to the application. Furthermore, these circuits needed to be considered, managed, and monitored rather separately. The hard divisions between two circuits became a hard division between applications. Voice networks were famous for their reliability, strict clockwork operation—and complexity. They were not for easy-to-set-up, easy-to-move operations. The wires are drawn once and carefully, and the switches and intermediate equipment is set up by a team of dedicated and expensive experts who do nothing but voice all day. If you were serious about voice, you operated your own little phone company, complete with dedicated operators. If not, your only option was to have the phone company run your phone network for you.

Along came packet-switched networks. Sending small, self-contained messages between arbitrary endpoints on a network inherently made sense for computers. The idea of sending a message quickly, without tying up lines or going through cumbersome setup and teardown operations removed the restrictions on wasted lines. Although it was still true that lines could remain idle when not being used, the notion of allowing these packets of information into the line as the fundamental concept, rather than requiring continuous occupation and streaming, meant that lines that carried aggregated traffic from multiple users and multiple messages could be used more efficiently. If the messages were short enough, one line might do. No concerns about running out of lines and having the needed, or only, path to the receiver blocked. Instead, these messages could just be queued until space was available.

Along with this whole new way of thinking about occupying the resources came a different way of thinking about addressing and connecting the resources. In the early days, a phone number used to encode the exact topological location of the extension. Each exchange, or switch with switchboard operator, had a name and number, and calls were routed from exchange to exchange based on that number first. Changes to the structure or layout of the telephone system would require changes to the numbers. Packet-switching technologies changed that. Lines themselves lost their names and numbers. Instead, those names and numbers were moved to the equipment that glued the lines together. Every device itself now had the address. The binding of the addresses to the topology of the network remained, at some level. Devices could not be given any arbitrary address. Rather, they needed to have addresses that were similar to their neighbors. The notion of exchange-to-exchange routing was retained.

This notion, though, proved to be a burden. Changes to the network were quite possible, as either more devices needed addresses, or more new "exchanges" were added to the network. Either way, the problem of figuring out how to route messages through the network remained. The original design had each router know which lines needed to be used to send the messages along their way. The router might not know how the message should get to the final destination, but it always knew the next step, and could direct traffic along the right roads to the next intersection, where the next router took over. As the number of intersections increased, and the number of devices expanded, the complexity of maintaining these routing tables exploded. A way was needed for neighboring routers to find out about each other, and more importantly, to find out about what end devices they knew routes to. Thus, the routing protocol was born. These protocols spoke from router to router, exchanging information on a regular basis, ensuring that routers always had recent information on what destinations were valid and how to get there from here. But another thing happened. This idea of exchanging the routes had another benefit, in that it allowed the network itself to be restructured, or to fail in spots, and yet still be able to send traffic. Routers did not need to know the entire path to the destination, only the next hop. If a router knew two, different next hops for the same message, and one of the routes went down, the router could try the second one. If the router lost all of its paths to a particular set of destinations, the router before it could learn about that, and avoid using that path to get the messages through. If there was a way to get the message there, the network would find it, through the process of convergence, or agreement over time on the consistency of whether and how messages could be sent. The network became resilient, and point failures would not stop traffic from flowing.

This is the story of the Internet, and of all the protocols that make it work. Clearly, the story is simplified (and perhaps romanticized to highlight the point at hand), but the fundamentals are there. Circuit switching is difficult to manage, because it is incredibly wasteful and inflexible. Packet switching is much simpler to manage, and can recover from failures.

The Internet grew up on top of the lines offered by the circuit-switched technologies, but used a better way to dedicate the resources. It wasn't long before someone realized that voice itself could be put over these packet-switched lines. At first, that might sound wasteful, as using a digital line to carry a packet containing voice can never be more efficient than using that line to carry the same bits of voice directly because of the packet overhead. But packet networking technologies matured, and the throughputs offered on simple point-to-point links grew much faster than did the corresponding uses of the same copper line for digital voice-at least, in the enterprise. And the advantages of using amultipurpose technology allowed these voice over IP pioneers to use the network's flexibility and lack of dedication to one purpose to add to the voice over IP offerings quickly, without requiring retooling of physical wires. The ways in which provisioning was thought about changed, and the idea that voice and data networks can perhaps use the same resources became a compelling reason to try to save deployment and management costs.

There are a tremendous number of resources available for understanding the intricacies of how IP networks operate, including details on how to manage routing protocols and large trunk lines. Here, we will explore how voice fits into the packet-based IP network.

How to Measure Voice Quality Yourself

The Expensive, Accurate Approach: End-to-End Voice Quality Testers

As mentioned in the discussion of PESQ, existing tools can measure the quality of the voice network by directly pumping in prerecording voice samples andcomparing the output. These tools are either expensive or home-grown, and are used to test large networks as a part of a planning or predeployment phase.

This sort of testing is more of a tuning exercise, and-much like how piano tuning is a rare and complicated enough exercise that it is not performed frequently-direct end-to-end testing is not diagnostic. Telephone equipment testing companies do make the sort of equipment to perform this end-to-end inspection, and these tools can be rented. Unfortunately, it is very difficult to know where to invest in this sort of heavily proactive effort.

More likely, the voice quality is measured by having administrators walk around the network with some number of phones in question, ensuring themselves that whatever problems they may face will likely be manageable. The problem with both forms of proactive testing is that they normally occur on only lightly loaded networks, and thus are not able to measure the effect of network load on voice quality. Network load is generally the largest impact on voice quality, in fact, partly because voice mobility network managers do a good job of testing their networks before they launch them for basic problems, which they quickly correct, and partly because voice mobility networks are more likely to be robust enough out of the box for basic voice connectivity.

Network Specific: Packet Capture Tests

Most of the major packet capture tools, for wireline and for wireless, make modules that are able to indirectly infer the MOS values using E-model calculations. Sometimes, these work by tracing the voice setup protocols, such as SIP, and determining what RTP flows map to phone calls and the properties of the phone calls. Other times, these tools will just look directly at the RTP streams, and not try to find out what phone numbers the streams map to In both cases, the tools then use the sequence number and timestamp fields in the RTP stream to determine values such as loss, delay, and jitter. Using assumed values for the jitter buffer, with the option of having the user overwrite them, the tools then model the expected effect and produce a score.

The major issue with these tools is that they show quality only up to the point where they are inserted. An easy example of the problem is to look at wireless networks. On a Wi-Fi network, a packet capture tool may be able to directly determine what packets it sees and come up with a score. By looking at the Wi-Fi protocol, the tool may do a good job of inferring whether the mobile phone received the packet from the access point, and at what time, and may produce a reasonably close call quality number. On the other hand, the upstream flow is likely to look quite good from the point of view of the test tool, because there is only one network in between the client and the tool. The entirety of the network upstream from the client goes missing, and the upstream MOS value can be entirely misleading.

Some network infrastructure devices are able to do these inferences within themselves, as they pass the data through. This may be a reasonable thing to do, again depending on the point of insertion and how well they are able to capture information as late into the network as possible. It is important, when using all of these tools, for you to consult with the vendor or maker of the tools to find out where the tools are measuring. For a wireless controller with voice metric capabilities, for example, make sure that the downstream metrics are measured on the access point, based on what happened over the air, and not just passing through the controller. For wireless overlay monitoring, make sure that there is an option to do a similar capture using a wired mirror port on one of the switches, for cases in which voice quality might begin to suffer and the network needs direct attention. Overall, do not rely on just one tool, and believe what the users say-no matter what the tool tells you.

The Device Itself

The most accurate and reasonable way to measure voice quality is from the endpoints themselves. Both some handsets and PBXs offer the ability for the device to produce the one-way MOS value or R-value for the receive side at the device itself. These numbers are based entirely on E-model calculations, assuming best-case or known-default scenarios for the rest of the system, but are likely to be the most accurate. Of course, it is difficult to ask a user to determine what the voice quality is of a call while on it, especially given that voice quality is not something a user wants to measure. However, for diagnosing locations that are having troubles, this tool is valuable for the administrator herself, who is able to avoid having to guess as to whether the call sounds reasonable, and may be able to detect variations in the MOS value or R-value.

In the end, keep in mind that the absolute values produced by any of the methods deserve being taken with a grain of salt. As time goes on, the administrator of a voice mobility network should be able to learn what the real quality means for any given value the tool suggests, even when the tool is placing results a half a MOS point too high or too low. However, the variation of the scores, especially when the network has changed, can be a valuable tool for point the way towards the solution.

Jitter | What Makes Voice over IP Quality Suffer

Jitter is the variation in delays that the receiver experiences. Jitter is a nuisance that the user does not hear directly, because the phones employ a jitter buffer to correct for any delays. Jitter can be defined in a number of ways. One way is to use the standard deviation or maximum deviation around the mean delay per packet. Another way is to use the known arrival intervals (such as 20ms), and subtract consecutive delays of packets that were not lost from the known arrival time, then take the standard deviation or the maximum deviation. Either way, the jitter, measured in times or percentages against the mean, tells how variable the network is.

Jitter is introduced by variable queuing delays within network equipment. Phones and PBXs are well known for having very regular transmission intervals. However, the intervening network may have variable traffic. As the queue depths change and the network loads fluctuate, and as contention-based media such as Wi-Fi links clog with density, packets are forced to wait. Wireless networks are the biggest culprit for introducing delay into an enterprise private network. This is because wireless packets can be lost and retransmitted, and the time it takes to retransmit a packet can usually be measured in units of a millisecond.

A jitter buffer's job is to sit on the receiver and prevent the jitter from causing an underrun of the voice decoder. An underrun is an awkward period of silence that happens when the phone has finished playing the previous packet and needs another packet to play, but one has not yet arrived. These underruns count as a form of error or loss, even if every packet does make it to the receiver, and loss concealment will work to disguise them. The problem with jitter becomes that an underrun must be followed by an increase in delay of the same amount, assuming no packets are lost. This can be seen by realizing that the delayed packet will hold up the line for packets behind it.

Here, the value of the jitter buffer can be seen. The jitter buffer lets the receiver build up a slight delay in the output. If this delay is greater than the amount of actual jitter on the network, the jitter buffer will be able to smooth things out without underruning.

In this sense, the jitter buffer converts jitter directly into delay. If the jitter becomes too large, the jitter buffer may have limited room, and start dropping earlier samples in the buffer to let the call catch up to be closer to real time. In this way, the jitter buffer can convert the jitter directly into loss.

Because jitter is always converted into delay first, then loss, it does not have a direct impact on the E-model by itself, but instead can be folded in to the other measures. However, the complication arises because the user or administrator does not usually know the exact parameters of the jitter buffer. How many samples, how much delay, will the jitter buffer take before it starts to drop audio? Does the jitter buffer start off with a fixed delay? Does it build up the delay as jitter forces it to? Or does it try to proactively build in some delay, which can grow or shrink as the underruns occur? These all have an impact on the E-model call quality.

As a result, a rule of thumb here is to match the jitter tolerance to the delay tolerance. The network, at least, should not introduce more than 50ms of jitter.

Handoff Breaks | What Makes Voice over IP Quality Suffer

Handoffs cause consecutive packet losses. As mentioned in our previous discussion on packet loss, the impact of a handoff glitch can become large. The E-model does not make the best measurement of handoff break consternation, because it takes into account only the average burst length. Handoffs can cause burst loss far longer than the average, and these losses can delete entire words or parts of sentences.

Later chapters explore the details of where handoff breaks can occur. The two general categories are for intratechnology handoffs, such as Wi-Fi access-point to access-point, and intertechnology handoffs, such as from Wi-Fi to cellular. Both handoffs can cause losses ranging for up to a second, and the intertechnology handoff losses can be potentially far higher, if the line is busy or the network is congested when the handoff takes place.

The exact tolerance for handoff breaks depends on the mobility of the user, the density or cell sizes of the wireless technology currently in use, and the frequency of handoffs. Mobility tends to cut both ways: the more mobile the user is at the time of handoff, the more forgiving the user might be, so long as the handoff glitches stop when the user does. The density of the network base stations and the sizes of the cells determine how often a station hands off and how many choices a station has when doing so. These both add to the frequency of the glitches and the average delays the glitches see. Finally, the number of glitches a user sees during a call influences how they feel about the call and the technology.

There are no rules for how often the glitches should occur, except for the obvious one that the glitches should not be so many or for so long that they represent a packet loss rate beginning to approach a half of a percentage point. That represents one packet loss in a four second window, for 20ms packets. Therefore, a glitch of 100ms takes five packets, and so the glitch should certainly not occur more than once every 20 seconds. Glitches longer than that also run the risk of increasing the burst loss factor, and even more so run the risk of causing too many noticeable flaws in the voice call, even if they do not happen every few seconds. If, every two minutes, the caller is forced to repeat something because a choice word or two has been lost, then he would be right to consider that there is something wrong with the call or the technology, even though these cases do not fit well in the E-model.

Furthermore, handoff glitches may not always result in a pure loss, but rather in a loss followed by a delay, as the packets may have been held during the handoff. This delay causes the jitter buffer (jitter is explained in Section 3.2.4) to grow, and forces the loss to happen at another time, possibly with more delay accumulated.

A good rule of thumb is to look for technologies that keep handoff glitches less than 50ms. This keeps the delaying effect and the loss effect to reasonable limits. The only exception to this would be for handoffs between technologies, such as a fixed-mobile convergence handoff between Wi-Fi and cellular. As long as those events are kept not only rare but predictable, such as that they happen only on entering or exiting the building, the user is likely to forgive the glitch because it represents the convenience of keeping the phone call alive, knowing that it would otherwise have died. In this case, it is reasonable to not want the handoff break to exceed two seconds, and to have it average around a half of a second.

PESQ: How to Predict MOS Using Mathematics

Therefore, we turn to how the predictions of voice quality can actually be made electronically. ITU P. 862 introduces Perceptual Evaluation of Speech Quality, the PESQ metric. PESQ is designed to take into account all aspects of voice quality, from the distortion of the codecs themselves to the effects of filtering, delay variation, and dropouts or strange distortions. PESQ was verified with a number of real MOS experiments to make sure that the numbers are reasonable within the range of normal telephone voices.

PESQ is measured on a 1 to 4.5 scale, aligning exactly with the 1 to 5 MOS scale, in the sense that a 1 is a 1, a 2 is a 2, and so on. (The area from 4.5 to 5 in PESQ is not addressed.) PESQ is designed to take into account many different factors that alter the perception of the quality of voice.

The basic concept of PESQ is to have a piece of software or test measurement equipment compare two versions of a recording: the original one and the one distorted by the telephone equipment being measured. PESQ then returns with the expected mean opinion score a group of real listeners are likely to have thought.

PESQ uses a perceptual model of voice, much the same way as perceptual voice codecs do. The two audio samples are mapped and remapped, until they take into account known perceptual qualities, such as the human change in sensitivity to loudness over frequency (sounds get quieter at the same pressure levels as they get higher in pitch). The samples are then matched up in time, eliminating any absolute delay, which affects the quality of a phone call but not a recording. The speech is then broken up into chunks, called utterances, which correspond to the same sound in both the original and distorted recording. The delays and distortions are then analyzed, counted, and correlated, and a number measuring how far removed the distorted signal is from the original signal is presented. This is the PESQ score.

PESQ is our first entry into the area of mathematical, or algorithmic, determination of call quality. It is good for measuring how well a new codec works, or how much noise is being injected into the sample. However, because it requires comparing what the talker said and what the listener heard, it is not practical for real-time call quality measurements.