The evolution of voice-over-Internet Protocol technology, streaming audio and video, remote and wireless links, and myriad other high-bandwidth, low-latency, multimedia-rich Internet applications is driving network service providers to offer Differentiated Services. Also known as DiffServ, these features will enable new sources of premium billable services.
To gain the full network intelligence required, the implementation of quality-of-service (QoS) guarantees must evolve from the current generation of the "one size fits all" Internet and IP network infrastructures. Industry heavyweights such as Cisco, Alcatel, Nortel and Lucent are offering Multi-Protocol Label Switching (MPLS) as a basis for end-to-end QoS implementation.
Driven by the needs of network service providers, MPLS is the basis to deliver premium billable services to their customers. Traffic between a subscriber and network service is routed across a label-switched path (LSP) that has controllable bandwidth and priority. Mission-critical applications can (if the subscriber pays for them) be provisioned with guaranteed performance levels independent of network conditions.
See related chart
MPLS networks use two types of MPLS routers. At the edge of the core, label edge routers (LERs) map various subscribers' traffic into multiple LSPs based on the type of traffic, the service level the subscriber is paying for and network conditions. Label-switched routers (LSRs) then use the label as an indicator to determine the QoS required as data traffic is transported across the core.
As data flows through an MPLS network, the LER maps external data to an LSP by inserting or "pushing" a label between the transport layer header and the network layer. Multiple labels can be applied to the same packet, creating a label stack. In real networks with many subscribers and services, LERs and LSRs perform additional operations on labels. These include replacing the MPLS label on the top of the label stack, thereby merging multiple LSPs and grouping them into a single LSP by pushing another label onto the current label stack. The label for the group can be removed, or "popped," by other LERs or LSRs and the packet routed based on the next label in the stack.
MPLS labels include a time-to-live (TTL) field that's used to prevent infinite loops in LSPs, where the field must be decremented by each router on an LSP. Packets with a "zero" TTL should be discarded. MPLS labels also contain a bottom-of-stack bit so that an LER or LSR can tell if a packet needs to be routed by a more conventional method.
The challenge facing network service providers is to supply a consistent QoS strategy from the edge of the network through the core. This implies that QoS must be supported at wire-speed data rates ranging from 10/100 Ethernet to OC-192. However, current MPLS implementations only support data rates through OC-48.
The primary difficulty stalling the ubiquitous deployment of MPLS is the support of the MPLS protocol in the core at OC-192 in the LSR application. To achieve the full benefits of an MPLS-based application and infrastructure, the OC-192 data path or data plane must be able to process, manipulate and classify the ingress or egress data streams at wire speed.
The MPLS application in an OC-192 LSR requires at a minimum that a 32-bit field be inserted between the encapsulation layer and the network layer. The 32-bit word is made up of a 20-bit label, an 8-bit TTL field, a 1-bit bottom-of-stack indicator and a 3-bit experimental-bits field (EXP). An LSR has nine basic operational requirements, essential if the connection is to be completed.
The MPLS processing and classification block is the primary challenge for network system providers trying to deploy equipment in 2001. Other functions exist today or are becoming available by the end of this year. For example:
- OC-192 clock recovery and serializer/deserializer solutions are shipping today in gallium arsenide, silicon germanium and CMOS technologies.
- CMOS OC-192 framers are sampling now from AMCC and Vitesse.
- Traffic management, shaping and queuing solutions are coming to the market (for example, from Acorn Networks, PMC-Sierra via its acquisition of Extreme Packet Devices, and Vitesse via Orologic).
- Switching capacity is in place now with lots of options to scale into the terabit range.
Current solutions for the MPLS processing and classification are not as clear as these framer, traffic management and switch operations. The current generation of network processors is challenged to meet the performance goals of gigabit and OC-48 systems. At OC-192 there are not enough processor clock cycles available to do the deep packet inspection, statistics gathering and processing, modifications and data tagging for proper queuing in the traffic management subsystem. Today's network processors also lack the physical interface to support a flow-through OC-192 data path, such as the SPI-4 Phases 1 and 2 defined by the Optical Internetworking Forum.
Historically, custom approaches are generally the solution chosen to resolve the performance issues since generic alternatives have not been available. Custom approaches, however, are generally very specific to the current requirements and do not scale. Below are some considerations facing a custom or ASIC program:
- There are challenges and overhead associated with rule table management.
- Location priority dependencies, table management and related functions are also a factor.
- Another issue is how to account for all the statistic gathering and processing, and to determine how much will be required in the future.
- What if additional fields need to be evaluated-for example, new encapsulations, or perhaps the need to look further into the packet for QoS dependencies?
In the constant search for cost-effective, scalable solutions, equipment manufacturers looking to add OC-192 MPLS processing to their product portfolios are investigating fresh approaches to provide a way to get product into customers' networks in 2001. Furthermore, they require a solution that's able to scale in two ways; one is to offer more capability at OC-192 and the other is to be ready for the OC-768 challenge.
A network coprocessor architecture called the PolicyEdge is an attempt to provide key features in support of MPLS at OC-192 performance rates. Set for availability early next year in silicon form, it employs a data-driven architecture to provide for scalable and flexible wire-speed data-plane processing. The intent of the device is to perform sophisticated packet-inspection functions based on user-defined "policies" or rule sets that can be dynamically altered. The device is available with various I/O options so that it can be used in line with the packet data flow.
Offered with an Optical Internetworking Forum OC-192 physical interface (SPI-4 Phase 1), the PolicyEdge is able to inspect packets flowing out of the device by tagging them with user-defined data that identifies the packet to the subsequent functional blocks in the data path. While inspecting packets, the device can be configured to gather statistical information about the data traffic and can also provide alternative user-defined tags based on the gathered statistical information.
Used in an OC-192 LSR application, the device can easily handle functions such as header encapsulation, pushing and popping label fields, and decrementing the TTL field while maintaining the OC-192 wire rate. When used in conjunction with a queuing and scheduling device, it provides a complete solution for an OC-192 LSR data path.
See related chart