DOC PREVIEW
AUBURN COMP 7970 - Simulation-Based Analysis of MPLS-Traffic Engineering

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Model Research & DevelopmentMPLS OverviewNetwork TopologySimulation Results/AnalysisConclusionReferencesSimulation-Based Analysis ofMPLS Traffic EngineeringModel Research & DevelopmentOPNET Technologies, Inc.Bethesda, MD, 20814E-mail: [email protected] AbstractIt is a well-known behavior [FF99] that when congestion-sensitive (TCP) and congestion-insensitive (UDP) traffic sharea common path, an increase in congestion-insensitive traffic adversely affects congestion-sensitive traffic’s performance (e.g., due to TCP’s congestion control mechanism). This paperuses an example network scenario to illustrate the benefits of using MPLS traffic engineering [AMAOM99] and QoS in eliminating the undesirable effects of mixing congestion-insensitive flows with congestion-sensitive flows [BSJ00]. Weuse a UDP data flow to represent a congestion-insensitive traffic flow and TCP data flows to represent congestion-sensitive traffic flows. A comparative simulation analysis is provided for 1) non-MPLS enabled network, 2) a network withtwo LSPs, one for a pure congestion-sensitive flow, and another combined one for congestion-insensitive and congestion-sensitive flow, and 3) a network with three LSPs, one for each traffic flow, and traffic differentiation using WFQon the link carrying both congestion-insensitive and congestion-sensitive flow, based on the throughput achieved by the congestion-insensitive and congestion-sensitive flows when they share the network resources.MPLS OverviewMulti-Protocol Label Switching (MPLS) [RVC01] is the latest technology in the evolution of routing and forwarding mechanisms for the core of the Internet. The “label” in MPLS is a short, fixed-length value carried in the packet's header to identify a Forwarding Equivalence Class (FEC). A FEC is a set of packets that are forwarded over the same path through a network. FECs can created from any combination of source and destination IP addresses, transport protocol, port numbers etc. Labels are assigned to incoming packets using a FEC to label mapping procedure at the edge routers. From that point on, it is only the labels that dictate how the network will treat these packets -- i.e., what route to use, what priority to assign, and so on. MPLS defines label-switched paths (LSP), which are pre-configured to carry packets with specific labels. These LSPs can be used to forward specific packets through specific routes, thus facilitating traffic engineering.The above figure is a simple illustration of how MPLS performs label switching. The ingress label edge router (LER) receives an IP datagram (an unlabeled packet) with a destination address of 10.1.9.7. The LER then maps the packetto a FEC, and assigns a label (with a value of 8) to the packet and forwards it to the next hop in the LSP. In the core of the network, the LSRs ignore the packet's network layer header and simply forward the packet using a label-swapping algorithm. In the above example, the label changes from 8 to 4to 7.Figure 1: Life cycle of a packet through an MPLS network1Network TopologyWe used OPNET Modeler 8.0 for our simulation analysis using OPNET's MPLS models available in the OPNET Model Library. This section explains the network model used in this study. The main goal is to generate a mix of one-way (only source to destination) congestion-insensitive and congestion-sensitive traffic and study the network performance with and without MPLS traffic engineering (TE). In order to achieve this goal, we have prototyped a network with the following main components:- Traffic sources/destination: One congestion-insensitive traffic source (named “UDP Source”) generating a varying level of traffic (1.5 Mbps through 4.0 Mbps) and two congestion-sensitive traffic sources (named “TCP Source 1” and “TCP Source 2”) each generating 1.5 Mbpsof traffic to be sent from the source nodes to the respective destination nodes. All end-stations are fully TCP/IP-enabled nodes – e.g., in the event of detecting congestion, the TCP sources will reduce traffic flow input as dictated by its congestion control mechanism.Network topology: The edge network on the source and destination sides consists of an LER connected to the core. The core network consists of four LSRs connected using two parallel paths of 4.5 Mbps and 1.5 Mbps. The edge network is configured to operate at OC-3 (155 Mbps) data rate so that it does not introduce any congestion. Remember that our main goal is to study the impact of overload in the core network.All routers (LERs and LSRs) in the given baseline topology are MPLS enabled. They have been configured such that their label mapping and switching algorithms are enabled only when LSPs are defined in the network. With no LSPs defined, these routers will use the routes advertised by the dynamic routing protocol running on their interfaces (OSPF in our example). Due to the higher bandwidth of the link between LSR1 and LSR3, and LSR3 and LSR4, the default route taken to get from the “Ingress LER” to the “Egress LER” will be from LSR1 to LSR3 to LSR4.In terms of results analysis, we will focus on the throughput (in bits/sec) collected at the outgoing interfaces to the various destinations from the egress LER. Various other metrics that can also be analyzed for the above network include applicationresponse time, number of TCP retransmissions, traffic droppedin the core of the network due to congestions, etc.Figure 2: Baseline network topology2Figure 3: (Scenario 1) Baseline network with no MPLS-TESimulation Results/AnalysisThis section explains the results and the corresponding analysis performed as part of this study. We modeled several different cases:- Scenario 1: The network model does not have any LSPs (i.e., there is no MPLS-TE). In this case, our goal is to obtain baseline results to study the effect of increasing congestion-insensitive traffic over congestion-sensitive traffic. We ran multiple simulations in which we increasedthe amount of traffic generated by the “UDP Source” (1.5 Mbps, 2.0 Mbps, 2.5 Mbps, 3.0 Mbps, 3.5 Mbps, 4.0 Mbps). Both TCP (congestion-sensitive) and UDP (congestion-insensitive) traffic flow from the “Ingress LER” to the “Egress LER” via LSR1, LSR3, andLSR4. The amount of traffic being successfully received by the destination nodes for various loads is shown in Figure 4.1 through Figure 4.4. Notice that when the amount of UDP traffic sent by the “UDP Source” is increased beyond a value such that


View Full Document

AUBURN COMP 7970 - Simulation-Based Analysis of MPLS-Traffic Engineering

Download Simulation-Based Analysis of MPLS-Traffic Engineering
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Simulation-Based Analysis of MPLS-Traffic Engineering and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Simulation-Based Analysis of MPLS-Traffic Engineering 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?