TOP TEN:
MPLS Software Considerations
By Robert
Pulley
It’s no secret that network service providers are struggling to address the exponential growth of their Internet and IP networks. Providers also want to add quality of service (QoS) capabilities to their networks to enable reliable voice, video, data, multimedia, and virtual private network (VPN) services over the same IP network. Adding QoS will allow service providers to differentiate their services from the raw bandwidth services that they offer today.
Multiprotocol label
switching (MPLS) is thought by most industry analysts, network service providers, and equipment manufacturers to be the only way to solve their networking issues. For this reason, most major equipment manufacturers and start-ups are scrambling to add MPLS capabilities to their products to ensure that they hit the market window serving this multi-billion dollar market.
When designing MPLS software into an existing or new product, many factors must be taken into consideration.
1. MPLS
application.
The starting point must be a clear definition of the MPLS software objectives. Whether the MPLS software will reside in a label-edge router (LER), a label-switch router (LSR), or an access product (such as a cable modem) determines these objectives. In all cases, the MPLS software should be able to support VPN applications.
When designing an LER to support bandwidth wholesale applications, a virtual machine capability should be included in the architecture of the product. To do
this, each instance of the MPLS and associated software must allow virtual machine capabilities. With these capabilities, the LER can have one physical interface dedicated to one carrier and another physical interface dedicated to a second carrier.
The application also dictates which types of routing protocols will be required. For access applications (like cable modems) a static routing capability is the most economical and feasible choice. For edge-of-the-network point of presence (POP) products,
routing protocols such as open shortest path first (OSPF) V2.0, intermediate station to intermediate station (IS-IS), and routing information protocol (RIP) V2.0 will most likely be required. In LSRs, a border gateway routing protocol such as BGP 4 may be required.
2. Traffic engineering.
A key component in MPLS is traffic engineering. Traffic engineering provides QoS for the IP traffic and can be done using either the constraint-based routing label distribution protocol (CR-LDP) or the
Resource Reservation protocol (RSVP) with extensions for traffic engineering. Different equipment manufacturers and service providers will support the use of CR-LDP and RSVP with extensions. It’s too soon to tell which method of traffic engineering will ultimately prevail, so products should be developed with the flexibility to support both types of traffic engineering, ensuring interoperability with other products on the market.
3. Architecture.
When developing an MPLS product, the
software architecture is a critical component. It must have the flexibility to support the MPLS system (which may include the LDP, CR-LDP, and RSVP) with extensions for traffic engineering. It must also support the Layer 2 transport protocols (like ATM and/or Frame Relay) that MPLS will use. It must be modular so the other protocols may be easily added as the product migrates. Various standards organizations and forums are working to determine an architecture for the next generation of multiservice
switching products that will include additional protocols and capabilities. In the architecture, it is important to have well-defined application program interfaces (APIs) to a routing database, Layer 2 protocols, TCP, user datagram protocol (UDP), the IP forwarding hardware, the application interface, and a label manager.
In LERs, the label manager’s function is to map forward equivalency classes onto label switch paths (LSPs) that may have different QoS attributes. In LSRs, the label manager is
important in performing the label binding between the incoming and outgoing physical interfaces. In both cases, the label manager helps determine the availability of resources for QoS. In this sense, the label manager may be thought of as a call-control switch application that validates, accepts, and rejects QoS requests through the network.
4. Porting environment.
Whether using an off-the-shelf or proprietary RTOS, it is important to ensure that the OS can be easily ported into the hardware
system and can be easily upgraded. As new IP-forwarding chipsets and more powerful low-cost processors become available, it is likely that upgrades will occur. If a porting environment is well designed, these upgrades will become easier.
5. Fault isolation and troubleshooting.
It is important to ensure that well-defined and easy to use APIs are designed initially. Also, software traces, probes, and test applications that can dramatically minimize the amount of time it takes to
troubleshoot and test the software should be included. Today, there are no LDPs, CR-LDPs, and RSVPs with traffic engineering test equipment that can be purchased off the shelf, so it’s important that all of these capabilities be included in the design to help troubleshoot, provide fault isolation, and perform quality assurance testing.
6. Performance.
Performance is a key issue in designing LERs and LSRs. The MPLS software should be able to support tens of thousands of IP flows. This
includes IP classification from forward equivalency classes to LSPs and flows for IP switching. Although aggregation of labels and flows may occur, it’s possible that this number of flows is a good practical guideline. Performance in access products such as cable modems is not as critical an issue.
7. Distributed operation.
To achieve high-performance, multiple processors working in a distributed processing model may be required. Control-plane software components should be designed from
the ground up to support distributed processor operation. This includes the MPLS software, the label manager, the ATM software, and the call control application. A fast, reliable communications channel is necessary for the information distribution between entities running on different processors.
8. Redundant operation.
When selling products to network service providers, high-availability and 99.999% uptime is required. The software architecture must use software control-plane redundancy
to provide carrier class operation. This requires the use of a software redundancy management system to coordinate between the primary and back-up instances of software running on different processors. This software redundancy concept should be applied to the MPLS software, to other control-plane protocols (such as ATM), signaling, and to the call control application to ensure that switched virtual circuits and label-switch paths are not torn down if a processor failure occurs.
9. Interworking.
Interworking is a key issue to consider during the software design. In MPLS, the ATM VPI/VCI and in Frame Relay, the DLCI value can be used as the IP label. In this context, MPLS must interwork with ATM and/or Frame Relay is used to support those types of capabilities. The interworking must also support the mapping of ATM QoS parameters to MPLS traffic engineering parameters for seamless QoS operation between ATM and MPLS. The ATM switch call control application must also interwork with the label
manager for resource availability and switch fabric control. Interworking between MPLS and Diff-serv may be required if Diff-serv is supported.
10. Interoperability.
Vendors should support CR-LDP and RSVP with traffic extensions to allow for a wide range of interoperability until it is determined which design method will prevail. It’s important to ensure that the architecture and software design can migrate and be easily upgraded as new versions of the MPLS specification are generated by
the IETF.
Robert Pulley is the director of software development at Harris & Jeffries in Dedham, MA. He holds a BSCS from Brown University, and has been involved in the development of data and WAN communications software for over ten years. He can be reached at
rpulley@hjinc.com
.
Return to the
Table of Contents
Puzzled by a network processing design issue?
