he build-out of broadband services is well under way; today many businesses and homes are enjoying affordable, fast Internet access. The most common services are xDSL and cable. In addition, wireless services are growing rapidly and the price of traditional T1 services has dropped significantly.

Although accessing Web pages and downloading files over a broadband link is a significant improvement over our dial-up history, much more is attainable from these high-speed services. The next most logical step is delivering voice over broadband. After all, businesses and consumers want economical access to more phone lines and additional telephony services. So deploying multiline voice services over the existing cable plant represents considerable savings to telecommunications companies as well as the opportunity to sell value-added bundles of voice and data.

New compression standards now make video over broadband practical. Video applications include delivering movies on demand, video conferencing and video multicast. Service providers are also eager to meet businesses’ requests for service-level agreements (SLAs). Initially, SLAs were based on line speed and availability, but the next generation will be application specific, ensuring that applications like Web-based enterprise requirements planning receives priority.

Value-added applications, like voice and video, require QoS to ensure that they function properly. Users want more voice services, but not at the cost of distortion or delay. Delivering QoS is therefore critical to exploiting the full potential of digital broadband services.

Delivering applications within QoS requirements necessitates a network-wide approach using techniques like prioritizing traffic and reserving bandwidth. Until these standards are widely adopted throughout the Internet infrastructure, managed networks or hybrid packet-circuit models will be needed to assure QoS. Even within these implementations, there are a number of challenges to delivering QoS over the last mile.

The real-time transactional nature of voice traffic creates a number of challenges. Human beings are very sensitive to delay or latency in voice communications. They are also sensitive to any variation in delay, which is also known as jitter. The ITU recommends in G.114 that voice networks do not exceed a maximum delay of 50 ms in national networks and 150 ms in international ones.

The very process of creating packetized voice communication over digital networks induces delay. The amount of delay is a function of the type of voice encoding, the number of voice channels being serviced, the size of packets, available bandwidth and other network factors. The following are examples of the types of delays that can occur.

• Encoding a 44-byte packet using the G.711 recommendation induces 5.5 ms of delay. Delay with the same packet size goes up to 44 ms with a low-bit-rate encoder such as that recommended in G.729.
• Data queuing delay results if a data packet is in the process of being transmitted at the moment a voice packet arrives. The delay is a function of packet size and line rate. For example, at 384 kbits/second a 1,504-byte packet induces 31 ms of delay.
• Voice queuing delay occurs when multiple voice packets need to be serviced at the same time. The delay is the cumulative time for each voice channel to be serviced. Consequently, the extent of this delay is much greater with a 16-port integrated access device (IAD) than with a four-port model.

A jitter buffer is used to compensate for variability in delay. The resulting jitter build-out adds further delay.

Many network architects are challenged by the fact that the existing cumulative amount of delay is already pushing up against the acceptable budget for delay in the network. With the advent of voice-over-Internet Protocol and requirements for more channels to be serviced, it is imperative that customer premise equipment does not add additional delay or jitter. At the same time, data applications are demanding more processing power. For example, networks are moving beyond simple packet forwarding and network address translation functions to deep packet processing and security applications.

Some industry watchers see the solution for delivering voice and video to the end of the last mile as simple as bringing fiber to every business and home. However, bandwidth is not the solution.

First, less than 10 percent of U.S. homes even have cable or DSL services–many with less than 1 Mbit of bandwidth. Given the level of penetration with the existing cable plant (copper and coax), it is hard to see a new higher bandwidth solution being widely available soon.

Second, bandwidth alone is insufficient to address latency requirements of all applications, most notably voice. Fig. 1 shows these relative requirements.

The next generation of routers, gateways and IADs will require an underlying technology that balances the need for performance and QoS at an affordable cost.

Combining multiple cores on a single chip is only a partial step toward meeting the requirements for next-generation customer premise equipment. It only addresses cost and leaves the QoS issues to software executing on the processor core. Brecis concluded that a new network processor architecture was needed to effectively deliver multi-service applications. The Brecis Multi-Service Processor architecture is used in a family of processors that first sampled this summer. The architecture involved a number of innovative design approaches that will be described below.

The MSP5000 is the first of the Brecis family of multi-service processors (MSPs). The chip has 28.8 million transistors and includes multiple cores on a single chip:

• 180-Mhz MIPS processor for management and communications applications;
• Dual 160-Mhz LSI DSP cores, each functioning as a separate programmable engine–one for voice processing and one for packet processing;
• Dedicated security engine to provide hardware acceleration for encryption;
  
• Dual Ethernet MACs;
• Broad range of interfaces to external peripherals, memory, WAN and telephony interfaces.

Within the Brecis MSP architecture, the Multi-Service Bus plays a critical role in delivering a combination of performance and QoS (Fig. 2). The Multi-Service Bus is a packetized bus with a theoretical bandwidth of 3.2 Gbits/s. This bandwidth is designed to service traffic from 10/100 LAN interfaces and broadband WAN connections while minimizing contention for the bus. The Multi-Service Bus supports multimaster mode and allows any peripheral device to communicate on a peer-to-peer basis.

Every engine and peripheral is connected to the Multi-Service Bus through an interface unit, depicted in Fig. 2, which is integral to the bus architecture and fulfills a number of key functions. These units classify traffic into prioritized queues. Queues for voice, control commands and data receive access to the bus on a prioritized basis to ensure time sensitive traffic; like voice payloads are delivered without delay. Prioritization is not deferred until a packet reaches memory; rather, it occurs dynamically at multiple points.

The interface units also contain their own intelligent and context-aware direct memory access (DMA) engines. This allows the frame descriptor to contain both control and data information that off-loads the processor from setting up DMA bursts as well as considerably reducing time costly interrupts. The result is to significantly stretch the system performance without impacting cost or power consumption.

The Multi-Service Bus is also segmented through a four-way data switch to allow multiple simultaneous transactions. For example, the MIPS processor core can communicate directly with system memory while the bus communicates with other engines. This approach helps avoid waiting for slow peripheral devices to complete transactions across the bus.

The bus architecture enables a powerful feature to ensure that voice latency and jitter are kept to very low tolerances. The traditional path for a voice payload is from the wide area interface over the central bus to main memory for processing and then back over the bus to a voice-processing engine and out the telephony interface. By comparison, the MSP classifies the voice payload at the packet engine and directly sends it to the voice engine without processor and memory intervention.

The fast path between the voice and packet engines avoids delay that can occur when a data packet is serviced before a voice packet, thereby causing many milliseconds of delay and commensurate jitter.

QoS protocols are changing as new standards are being adopted. Many Internet Protocol-based and ATM protocols are used to provide end-to-end QoS and the Brecis packet engine supports several of them. Making the packet engine a flexible, programmable core was a key design goal to allow new protocols to be added as they become broadly implemented.