International Engineering Consortium
Web ProForums
A Comparison of Multiprotocol Label Switching (MPLS) Traffic-Engineering Initiatives

1. Introduction

The momentum toward voice and data convergence is driving the Internet to cope with new realities. Historically, the Internet infrastructure and protocols were intended and optimized solely for data. Traditional routing paradigms incorporating Internet Gateway Protocols (IGPs), such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), and Exterior Gateway Protocols (EGPs), such as Border Gateway Protocol 4 (BGP4), no longer represent the optimal solution.

On top of traditional data traffic, the addition of Hypertext Transfer Protocol (HTTP); voice, store, and forward messaging; multimedia traffic; and real-time electronic-commerce applications to the infrastructure are pushing toward ever-higher bandwidth requirements, as well as the ability to guarantee that bandwidth. This new reality is promulgating the development of new models to ensure guaranteed delivery of services such as voice, on par with the public switched telephone network (PSTN), regardless of unexpected interruptions in the network infrastructure. To the network, voice is just considered additional data, with very specific QoS and CoS requirements.

That Was Then, This Is Now

Thirty years ago, the early designers of Internet Protocol (IP) had to address different, but no less difficult, challenges than the designers of MPLS. Back then, the state of the art of computing logic itself dictated how computers could communicate. By today’s standards, central processing units (CPUs) were primitive and limited in their capabilities. Dynamic memory was slow and expensive. The facilities used to develop operating systems and communication protocols had yet to completely mature and be fully tested. Hence, the primary focus of early protocol development was to ensure the survivability of a truly decentralized network. Designers concentrated on functionality that supported segmentation, retransmission, and dynamic routing. Successful delivery of the data was the primary concern. Therefore, at each stop along its journey through the network, the IP datagram was decomposed, verified, analyzed, and reconstructed before it was finally sent on its way. Amazingly, the fundamental infrastructure of the transmission control protocol (TCP)/IP has managed to survive and evolve into the global phenomenon that is the Internet. This is a testament to the tenets of a standardized approach to protocol development.

The Initial Step, RSVP Arrives

In the mid 1990s, traffic levels in large networks and the Internet increased to levels far beyond what conventional routers were able to handle. The network had to support mission-critical applications in which expedited delivery of data over the network was mandatory. RSVP had been designed to offer higher-quality delivery over the existing local-area network (LAN)–based networks. RSVP had been based on the original fundamental requirement of the Internet (i.e., process each IP flow in a hop-by-hop fashion) but now provides limited scheduling and traffic shaping of each forwarded IP datagram at the egress port.

Acceptance of RSVP was not universal for several reasons. To realize actual guaranteed performance, RSVP required each router along the routed path to support RSVP signaling and some level of priority queuing or traffic shaping. It also required devices at the edge of the network to initiate and respond to RSVP requests. The demand for RSVP capabilities was not great enough to require a wholesale upgrade of network hardware.

Registered Users
Enjoy exclusive access to free On-Line Education and receive the biweekly IEC newsletter.

IEC Newsletter
Get the latest industry information including critical insights from key industry leaders, technology briefings, and an Analyst Corner.
Current
Subscribe

Newsroom

IEC Corporate Member

Advertising Kit