Showing posts sorted by relevance for query MPLS Tutorial. Sort by date Show all posts
Showing posts sorted by relevance for query MPLS Tutorial. Sort by date Show all posts

Monday, December 9, 2013

NTT Develops 10G SDN Software Switch for Carriers

NTT outlined details of a prototype, 10 Gbps high-performance SDN software switch that it developed as part of the "Research and Development of Network Virtualization Technology" program commissioned by Japan's Ministry of Internal Affairs and Communications.

NTT, which is already using SDN in its data centers for cloud services, said it developed this prototype SDN software switch to handle the large scale flow entries that will be required in wide area networks, such as those of telecommunications carriers and Internet providers.

The prototype switch still transfers large packets at a 10 Gbps wire rate even when 100K entries are in its flow tables and each packet header must be rewritten.  This makes it one of the highest performance SDN software switches to date, according to NTT.

The work was carried out by NTT Network Innovation Laboratories (Yokosuka, Kanagawa) as part of reseach for SDN software nodes in the "O3 Project".

The switch features a "Flexible parallel Flow processing Framework."

Earlier this year, leading Japanese companies, including Fujitsu, Hitachi, NEC, NTT Communications and NTT, launched the "Open Innovation over Network Platforms" research and development (R&D) project, also known as the "O3 Project".

The project, which is supported by Japan's Ministry of Internal Affairs and Communications, aims to develop network virtualization technology that enables multiple telecommunications carriers and service providers who share network resources to design and construct networks and manage their operations freely to suit their needs.

Specifically, a common SDN layer will be developed to integrate a multilayer infrastructure consisting of optical, wireless and packet communications platforms. Compared to existing SDN architectures, the O3 Project targets a common, multi-carrier framework that would enable any Service Providers to share resources.

In September 2013, NTT Com's Nationwide SDN for Uncompressed HDTV received the Innovation Award in Content Delivery at IBC 2013.  The service provides stable transmission of uncompressed high-definition video images between the 128 members of the Japan Commercial Broadcasters Association via a large-capacity and highly reliable network.

NTT Com said the value of SDN in this application is that it enables simplified functionality for broadcasters, such as adjusting the bandwidth requirements of each station according to their program schedule. By centrally managing the network, the technology flexibly and efficiently manages traffic to ensure the flawless and timely transmission of vast amounts of data between stations.

In June 2013, NTT showcased its Versatile Openflow vaLidaTor (VOLT) resource control system for software defined networking (SDN) at Interop Tokyo 2013.

NTT said VOLT, which was developed in partnership with Fujitsu, is able to duplicate the entire route information and configuration of OpenFlow.  This can be used to test a new network under the same conditions as the real environment.

The system consists of an MPLS edge router and controller.

Blueprint Tutorial: SDN and NFV for Optimizing Carrier Networks

This article provides some examples of how SDN and NFV can be applied to various segments of a carrier network, and how the functions of a traditional carrier network can be offloaded to a virtualized datacenter to improve end-to-end performance.

Sunday, August 5, 2012

Demystifying SDN for Carrier Ethernet Networks

by Sandy Orlando,  

Software Defined Networking (SDN) is the hottest new technology in networking. Google is running its backbone network traffic on an SDN network built using OpenFlow. Nicira was acquired by VMware for $1.26 billion to accelerate the adoption of network virtualization in the data center. Yet with all the buzz about SDN, it is not clear how it will be deployed in service provider networks and what it means to the expansion of Carrier Ethernet. 

Tsunami of data driving change

SDN and Carrier Ethernet are not mutually exclusive technologies. What’s more, both technologies help address the growing tsunami of data driven by the growth in mobile phones and tablets, the emergence of BIG DATA, and the rise in machine-to-machine communications.
Not only is the amount of data exploding, but the characteristics of that traffic are changing with over 70 percent of network traffic on mobile networks streaming media. As service providers roll-out new network services, they struggle with how to keep pace with growing consumer and business demand and how to grow their Average Revenue per User (ARPU) faster than costs. The growing appetite for new services as well as the pace of rolling out new services every three to six months is straining service provider networks.

In comes Carrier Ethernet and SDN

There is no secret why Carrier Ethernet is a $25 billion dollar business, expected to grow to over $47 billion by 2015. Carrier Ethernet offers significant cost advantages for service providers providing WAN transport for a wide-range of services, including mobile backhaul. With Carrier Ethernet, service providers can provide high-value-per-bit at a lower-cost-per-bit while maintaining the reliability and predictable performance required by even the most latency-sensitive applications.

The next stage of Carrier Ethernet growth will come from cloud services and Carrier Ethernet interconnects, combined with virtualized network services. The cost advantages of Ethernet alone cannot keep pace with the uncontrollable demand for bandwidth combined with the emergence of on-demand network services. The next generation of Carrier Ethernet solutions will need a new approach to network equipment design and architecture provided by SDN.

SDN fundamentals

Software Defined Networking is a new approach to architecting networking equipment that fundamentally changes the way we design and build networks in a data center and over a wide-area network (WAN). SDN moves from the monolithic network equipment design based on custom silicon, a custom control plane, and tightly integrated network applications (services) to a modular, programmable, and distributed design (figure 1).

Figure 1: Network architecture transformation.
The key to SDN is the decoupling of network control from traffic forwarding. This migration to a separate software-based controller offers a number of key advantages:
  • Programmability
  • Network application (service) abstraction
  • Global network view
Whether these controllers are based on the emerging OpenFlow standard or a hybrid of legacy switching/routing alongside OpenFlow, the network intelligence is centralized and appears to applications and policy engines as a single logical switch, which simplifies network design and operations.

Distributed traffic forwarders can be added as demand dictates, reducing costly oversubscription of network bandwidth. Moreover, the separation of the network services enables service providers to more quickly add new services without having to forklift networking devices.

The role of OpenFlow

OpenFlow is a communications interface between the control and forwarding layers in an SDN architecture. It allows direct access to and manipulation of the forwarding plane of physical and virtual network devices. The OpenFlow standard is developed by the Open Networking Foundation which was launched in 2011 by Duetsche Telecom, Facebook, Google, Microsoft, Verizon, and Yahoo.

The current version of OpenFlow (version 1.3) provides an instruction set for networks analogous to the x86 instruction set for PCs. The Open Flow (figure 2) protocol includes flow tables (generic primitives) that sit on top of (virtual) switch Ternary Content Addressable Memory (TCAM) and can perform the following actions:
  • Switching and routing
  • Firewalling
  • Switching non-OpenFlow logic locally
  • Sending to controller for processing

Figure 2: OpenFlow, courtesy of Open Networking Foundation, 2012

Other SDN standards and research

In addition to OpenFlow, there are several other standards and research activities for SDN, including:
  • Open Networking Foundation: Hybrid programmable forwarding planes
  • ITEF:
    • MPLS-TP Pseudowire configuration using OpenFlow 1.3 (draft-medved-pwe3-of-config-00)
    • SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS) across Multiple Domains (draft-yin-sdn-sdni-00.txt)
    • Use Cases for ALTO with Software Defined Networks (draft-xie-alto-sdn-use-cases-01.txt)
  • MEF: is working on cloud-computing and SDN standards
See the ONF and IETF websites for full list of SDN standards.

SDN is important for the future of Carrier Ethernet

Software Defined Networking is important for the evolution of Carrier Ethernet. It provides a new mechanism for architecting networking equipment and network designs. Moreover, implementing SDN does not necessarily require a rip and replace strategy. Service providers and network equipment vendors can begin identifying the high-value use cases to take advantage of the flexibility and programmability of SDN. These can include:

  • Dynamically partitioning access points and cell radios on demand based on a number of different parameters, including carrier, usage, identity, device type at the mobile edge, enabling optimal use of spectrum, Wi-Fi, and Carrier Ethernet mobile backhaul links.
  • Pooled compute and storage across geographically distributed data centers, connected with Carrier Ethernet transport using SDN, which will carve out bandwidth and allocate optimal use of bandwidth.
  • Traffic steering for content management and distribution, providing granular routing of traffic based on a wide-range of parameters such as subscriber policy, application type, and cache asset.

Waves of adoption

SDN is in its infancy and we have seen the first waves of adoption washing over the data center. For service providers and Carrier Ethernet equipment manufacturers, now is the time to begin researching SDN and identifying use cases that will drive future business.

While the ITEF and the MEF are beginning to explore SDN, the best place to learn about the technology is the Open Networking Foundation: The ONF is the standards body for SDN and OpenFlow, and has tutorials and the OpenFlow specifications. In addition, the proceedings from the Open Networking Summit from April 2012 are online at There are a number sessions from service providers and vendors on SDN for carrier networks.

As the tsunami of data grows, the emergence of SDN in carrier networks is inevitable. Only a fundamental change in how we architect networks can prepare us for the dynamic growth in communications in the coming decades. Carrier Ethernet will continue to grow. As network equipment providers adopt SDN architectures, service providers will see more opportunities to accelerate new and profitable network services.

About the Author

Sandy Orlando is a high-tech marketing executive with extensive experience in developing winning business strategies for networking and virtualization companies. She transformed the marketing strategy for IP Infusion, moving it from a point protocol provider to the leader in SDN embedded networking platforms. She has written about trends in carrier and enterprise networking and has spoken at data center and Ethernet conferences regarding the network transition to SDN.

See Our Videos:

Monday, February 6, 2012

Broadband Forum Adds Support for MPLS in Mobile Backhaul Networks

At the MPLS & Ethernet World Congress in Paris, the Broadband Forum released its latest suite of technical specifications and featuring new mobile backhaul capabilities. Specifically, BroadbandSuite 6.0 addresses network migration requirements with practical resources, specifications, test plans, and best practice documentation, including:

Technical specifications:

TR-221: "MPLS in Mobile Backhaul Networks"

IP/MPLS Forum 20.0.0: "MPLS in Mobile Backhaul Networks Framework and Requirements"

Certification Test Plan:

TR-248: "Abstract Test Suite for TDM Services over MPLS" (basis of the BBF.248 TDMoMPLS certification)

Resources: White Papers

MR-238: "Use of MPLS in LTE"

MR-258: "Enabling Next Generation Transport and Services using Unified MPLS"


MR-234: "MPLS in Mobile Backhaul Networks"

MR-245: "MPLS-TP in Multi-Service Packet Network Deployments"

MR-275: "Data Center Interconnection"

Robin Mersh, CEO of the Broadband Forum said: "The remarkable growth of mobile traffic, driven by demand for data, video and emerging business services, means that the industry must act quickly. The Broadband Forum continues to develop timely specifications that empower the industry to engineer smart converged mobile backhaul implementations."

Wednesday, December 15, 2010

Broadband Forum Charts Progress in 2010 -- Resurgence in Activity as Industry Looks to Hybrid Fiber/Copper

At its quarterly meeting last week in San Francisco, The Broadband Forum approved a record eleven new technical reports, released a new white paper on Unified MPLS, and appointed a new Technical Chairman. The meeting also drew the highest attendance of members and guests in recent years. The Forum noted an unprecedented level of contributions for technical reports, white papers and tutorials -- all indications of a resurgence in activity as the industry looks to next gen broadband access solutions.

The newly approved specifications ranged from IPv6 to TR-069 Software Module Management to DSL Quality Management.

New work items for the Forum include hybrid fiber-copper solutions for 4th Generation Broadband (4GBB).

The Forum has appointed Christophe Alter of France Telecom Orange to serve as its Technical Chairman, replacing Gavin Young of C&W, who has held the position since 1998. Christophe is responsible for France Telecom Orange Group' strategy regarding broadband networks standards. Since he first joined the Broadband Forum in December 2004, Christophe Alter has been a main contributor in the End to End Architecture Working Group and in the Fiber Access Network Working Group and has served as a member of the Board of Directors since 2008.

Among its accomplishments for 2010, the Broadband Forum noted its collaboration with the Full Service Access Network (FSAN) to expedite GPON deployments, enhance multi-vendor interoperability and enable better broadband network fiber integration globally. A joint initiative with the HomeGrid Forum was also announced, with the aim of delivering a global compliance and interoperability testing program for products using technology -- ITU-T's unified wired home networking standard. And another strategic relationship forged was with 3GPP focused on broadband convergence specifications and multi-service architecture developments.

"I am delighted to be taking over as Technical Chair at such a busy and positive time for the Broadband Forum," said Christophe Alter. "As a member I have watched the Forum grow in stature and authority but also increase enormously the number of technical reports, the range of topics in our scope and the intensity of our relationships with other organizations. It will be part of my role to manage this growth and to co-ordinate the groups so that they are able to deliver a comprehensive body of standards from over 1500 contributions we receive from members each year."

Thursday, January 24, 2002

Tutorial: MPLS Traffic Engineering

Rick Gallaher, CISSP, is owner of Dragonfly Associates LLC and author of  Rick Gallaher's MPLS Training Guide

January 24, 2002

In previous articles, we discussed data flow, signaling, and rapid recovery. This article addresses the subject of traffic engineering.

  • Silence Suppression:  Not using bandwidth when there is no data to send.
  • CR-LDP: Constraint Route Label Distribution Protocol.
  • Over-provisioning:  Having more bandwidth than allocated traffic.
  • Over-subscribing: Having more allocated traffic than available bandwidth. (Telco)
  • RSVP-TE: Resource Reservation Setup Protocol with Traffic Engineering
  • Under-subscribing: Having more bandwidth than allocated traffic. (Telco)
  • Under-provisioning: Having more allocated traffic than available bandwidth.

There is a road in Seattle, Washington that I drove years ago called Interstate 5.  From the suburb of Lynnwood, I could get on the highway and drive into the city, getting off at any exit.  If I wanted to go from Lynnwood into the heart of Seattle, I could get onto the express lanes.  This express lane is like an MPLS tunnel.  If my driving characteristics matched the requirements of the express lane, then I could use it.

Figure 5.1: Express Lane

Taking this illustration further, let’s say that I enter the freeway and want to drive into the heart of Seattle. I might ask myself, “Which is faster: the express lane or the regular highway? Is there an accident on the express lane?  Is the standard freeway faster?”

It would be nice to have traffic report, but traffic reports are not given in real time – by the time that I would find out about a slowdown, I would be stuck in it.  I could make the mistake of entering the express lane just as an accident happens 5 miles ahead and be trapped for hours.

It would be great if I had a police escort.  The police would drive in front of me; if there were an accident or a slowdown, then they would take me on a detour of similar quality to ensure that I arrive at my destination on time.

On the Internet, we have thousands of data roads just like Interstate 5. With MPLS, we have a road dedicated to traffic with certain characteristics – much like the express lane. To ensure that the express lane is available and free of congestion, we can use protocols like CR-LDP and RSVP-TE.  These protocols are discussed in greater detail in the article Advanced MPLS Signaling.  Currently, the most popular of these two protocols appears to be RSVP-TE, because it acts like a police escort to ensure that, if there is congestion, it can be re-routed around the problem area.

When looking at traffic patterns around the country, often freeways experience congestion and delays, while other roads are open and allow traffic to flow freely. The traffic is just in the wrong area. Wouldn’t it be nice if the highway engineers and the city planners could find ways to route heavy traffic to roads that could handle the traffic load and to adjust the road capacity as needed to accommodate traffic volume?

Traffic Engineering

In data and voice networks, traffic engineering is used to direct traffic to the available resources.  If achieving a smooth-flowing network by moving traffic around were simple, then our networks would never experience slowdowns or rush hours.

On the Internet (as with highways), there are four steps that must be undertaken to achieve traffic engineering: measuring, characterizing, modeling, and moving traffic to its desired location.

Figure 5.2: Four Aspects of Traffic Engineering

Measuring traffic is a process of collecting network metrics, such as the number of packets, the size of packets, packets traveling during the peak busy hour, traffic trends, applications most used, and performance data (i.e., downloading and processing speeds).

Characterizing traffic is a process that takes raw data and breaks it into different categories so that it can be statistically modeled. Here, the data that is gathered in the measurement stage is sorted and categorized.

Modeling traffic is a process of using all the traffic characteristics and the statistically analyzed traffic to derive repeatable formulas and algorithms from the data. When traffic has been mathematically modeled, different scenarios can be run against the traffic patterns.  For instance, “What happens if voice/streaming traffic grows by two percent a month for four months?”  Once traffic is correctly modeled, then simulation software can be used to look at traffic under differing conditions.

Putting traffic where you want it: To measure, characterize, and model traffic for the entire Internet is an immense task that would require resources far in excess of those at our disposal. Before MPLS was implemented, we had to understand the characteristics and the traffic models of the entire Internet in order to perform traffic engineering.

When addressing MPLS traffic engineering, articles and white papers tend to focus on only one aspect of traffic engineering.  For example, you may read an article about traffic engineering that addresses only signaling protocols or one that just talks about modeling; however, in order to perform true traffic engineering, all four aspects must be thoroughly considered.

With the advent of MPLS, we no longer have to worry about the traffic on all of the highways in the world. We don’t even have to worry about the traffic on Interstate 5. We just need to be concerned about the traffic in our express lane – our MPLS tunnel. If we create several tunnels, then we need to engineer the traffic for each tunnel.

Provisioning and Subscribing

Before looking at the simplified math processes for engineering traffic in an MPLS tunnel, a brief discussion of bandwidth provisioning and subscribing is needed. 

First, let’s look at the definitions. Over-provisioningis the engineering process in which there are greater bandwidth resources than there is network demand.  Under-provisioning is the engineering process in which there is greater demand than there are available resources.  “Provisioning” is a term typically used in datacom language.

In telecom language, the term “subscribe” is used instead of “provision.” Over-subscribing is the process of having more demand than bandwidth, while under-subscribing is a process of having more bandwidth than demand.  It is important to note that provisioning terms and subscription terms refer to opposite circumstances.

A pipe/path/circuit that has a defined bandwidth (e.g., a “Cat-5” cable) can in theory process 100 Mb/s, while an OC-12 can process 622 Mb/s. These are bits crossing the pipe and comprise all overhead and payload bits.

In order to determine the data throughput at any given stage, you can measure the data traveling through a pipe with relative accuracy by using networking-measurement tools.  Using an alternate measurement method, you can calculate necessary bandwidth by calculating the total payload bits per second and adding the overhead bits per second; this second method is more difficult to calculate and less accurate than actually measuring the pipe.

If the OC-12, which is designed to handle 622 Mb/s, is fully provisioned and the traffic placed on the circuit is less than 622 Mb/s, it is said to be over-provisioned. By over-provisioning a circuit, true Quality of Service (QoS) has a better chance of becoming a reality; however, the cost per performance is significantly higher.

If the traffic that is placed on the OC-12 is greater than 622 Mb/s, then it is said to be under-provisioned.  For example, commercial airlines under-provision as a matter of course, because they calculate that 10-15% of their customers will not show up for a flight. By under-provisioning, the airlines are assured of full flights; but they run into problems when all the booked passengers show up for a flight.  The same is true for network engineering – if a path is under-provisioned, then there is a probability that there will be a problem of too much traffic.  The advantage of under-provisioning is a significant cost savings; the disadvantages are loss of QoS and reliability.

Figure 5-3:  Over-Provisioning v. Under-Provisioning

In figure 5-3, you can see that you can over- or under-provision a circuit in percentages related to the designed bandwidth.

Figure 5-4: Comparison of Over Provisioning and Under Provisioning

Calculating How Much Bandwidth You Need

For the sake of discussion in these examples, let’s assume that you know the characteristics of your network. This is a process of gathering data that is unique to your situation and has been measured by your team.

Example One:  Two tunnels with load balanced OC-12 designed for peak busy hour.
Let’s say that we want to engineer traffic for an OC-12 pipe, which is 622 Mbps.
You want to have rapid recovery, so you use two pipes and load balance each pipe for 45% of capacity.  In this case, if one OC-12 pipe fails, then your rapid recovery protocol can move traffic from your under-provisioned pipe to the other, and the total utilization is still under-provisioned.

Figure 5-5: Sample Network Diagram Example One

Figure 5-6: Sample Network Failure

Figure 5-7 Traffic Trends
We can work these numbers just like we would in a checkbook. After we do the math, if we still have money (bits) remaining, then we are okay.  If our checkbook comes out in the red, then we must go back and budget our spending.

The following table helps to simplify the bandwidth budgeting process, as well as demonstrate some of the calculations involved in traffic engineering.Our traffic trends for peak busy hour show that we have:

Traffic DemandsTotals and subtotals
Number of voice calls100
      Total voice
      streams in b/s
Number of video calls3
      Total video
      streams in b/s
Committed information rate250,000,000250,000,000
Other traffic00
Total traffic demand271,500,000271,500,000BW required
Bandwidth  Available
  Circuit bandwidth
  for  OC-12
  Percentage used45%Over-
  Total BW for
279,900,000279,900,000BW on-hand
271,500,000BW required
Remaining Bandwidth8,400,000BW remaining
       BW = Bandwidth
       b/s = bits per second
       b/s/call = bits per second for each call

Figure 5-8:  Traffic Engineering Calculations for Example One

Now that we understand the basic concept, let’s play with the figures a bit to achieve the outcomes that we need.

Example 2:  Example with Silence Suppression

First, let’s say that we are going to use “silence suppression” on the voice calls. Silence suppression means that we will not use bandwidth if we are not transmitting.  The effects of silence suppression can be seen in Figure 5-9 below, which is a simple 10 count over 10 seconds.

The lows in the graph indicate the periods in which no data is being sent.  Silence suppression can be used if the calls have the characteristics of phone calls (Figure 5-9). However, if the calls are streaming voice like a radio show, or piped-in music (Figure 5-10), notice that the baseline is higher, and that more overall bandwidth is used.

Figure 5-9: Voice with Silence Suppression

Figure 5-10:  Music Jazz (The Andrews Sisters singing “Boogie-Woogie Bugle Boy”)

We can reduce the number of bits required for voice calls down to100K by using silence suppression. Notice in the following table that we have more remaining bandwidth with which to work.

Traffic DemandsTotals and subtotals
Number of voice calls100
      Total voice
      streams in b/s
Number of video calls3
      Total video
      streams in b/s
Committed information rate250,000,000250,000,000
Other traffic00
Total traffic demand261,500,000261,500,000BW required
Bandwidth  Available
  Circuit bandwidth
  Percentage used45%Over-
  Total BW for
279,900,000279,900,000BW on-hand
261,500,000BW required
Remaining Bandwidth18,400,000BW remaining
       BW = Bandwidth
       b/s = bits per second
       b/s/call = bits per second for each call

Figure 5-11: Traffic Engineering Calculations for Example Two

Example 3: Over Provisioned by 110%

Many carriers will choose over-provisioning because they cannot afford the cost of designing a highway system for rush hour traffic. Instead, they design a network for “normal traffic.”  Over-provisioning a network is similar to the airlines overbooking flights. There is a statistical point at which possible loss of customers is less than the cost of running planes at half capacity.

Let’s use the same example as above, with no switchable path and an OC-12 pipe that is able to tolerate some congestion during rush hour. We choose not to design the tunnel for peak busy-hour traffic; instead we design it for 10% over-provisioning, or 110% of the available bandwidth.

On paper this looks great, as we can still handle several hundred more calls, and it is an accountant’s dream. However, trouble lies in wait. What happens if all of the traffic arrives at the same time?  In addition, how can we handle a switchover to another link? If this link is provisioned at 110%, and the spare link is provisioned at 110%, one link will have a 220% workload during a single link failure, and will more than likely fail itself.

Traffic DemandsTotals and subtotals
Number of voice calls100
      Total voice
      streams in b/s
Number of video calls3
      Total video
      streams in b/s
Committed information rate250,000,000250,000,000
Other traffic00
Total traffic demand261,500,000261,500,000BW required
Bandwidth  Available
  Circuit bandwidth
  for  OC-12
  Percentage used110%Over-
  Total BW for
684,200,000684,200,000BW on-hand
261,500,000BW required
Remaining Bandwidth422,700,000BW remaining
       BW = Bandwidth
       b/s = bits per second
       b/s/call = bits per second for each call

Figure 5-12:  Traffic Engineering Calculations for Example Three


Traffic engineering for MPLS consists of four elements: measurement, characterization, modeling, and putting traffic where you want it to be.  MPLS can use either traffic engineering protocols (CR-LDP or RSVP-TE) discussed in advanced signaling to put traffic where it is desired.  Of the two protocols, RSVP-TE appears to be more dominant, but it costs more in bandwidth – it is like paying for a police escort when you travel.
The rest of traffic engineering is far from simple. You must measure, characterize, and model the traffic that you want. Once you have the information that you need, you can then perform mathematical calculations to determine how much traffic can be placed on your tunnel.
The mathematical process is like balancing a checkbook; you should never allow the balance to go into the red or negative area.

The tradeoff decisions are difficult to make.  Can you over-provision (over-book) your tunnel and just hope that rush hour traffic never comes your way?  In the event of a failure, where is the traffic going to go?

Suggested URLs:

Traffic Modeling 
Draft Math RFC
Bell Labs
Traffic Engineering Work Group  
Inside the Internet Statistics 
Excellent Measurement Site
Modeling and Simulation Software

Special Thanks

I would like to thank Ben Gallaher, Susan Gallaher, and Amy Quinn for their assistance in reviewing, and editing this article.

A special thank you to all those who assisted me with information and research on the MPLSRC-OP mail list, especially: Senthil Ayyasamy, Irwin Lazar, and Ashwin C. Prabhu.

Rick Gallaher, CISSP, is owner of Dragonfly Associates LLC

Rick is also the author of Rick Gallaher's MPLS Training Guide - Building Multi Protocol Label Switching Networks