Greenfield MPLS Network Design Using SPGuru.doc

7/28/2019 Greenfield MPLS Network Design Using SPGuru.doc

1/18

Subject: Greenfield MPLS Network Design Using SPGuru Date: 2013-4-10

From: Ahmet AkyamacBenjamin Tang

Ramesh Nagarajan

Advanced Technologies

Bell Laboratories

Holmdel, NJ07744

(732) 949-5413

(732) 949-6477

(732) 949-2761

[email protected]

[email protected]

[email protected]

1. Introduction & Scope

SPGuru is a network design, capacity planning and traffic engineering tool offered by Opnet. Itincorporates features that are of interest to LWS, such as network configuration, capacity planning,QoS analysis and simulation, etc. for a number of networking technologies such as ATM, IP andMPLS. This document focuses on the Greenfield topological design of MPLS networks usingOpnets SPGuru.

1.1 Greenfield MPLS Network Design Overview

The latest version of SPGuru as of the writing of this document is 11.0. SPGuru 11.0 supplied toLucent Technologies contains a custom design feature calledMin_Cost_MPLS_Net_Design. Thisfeature represents a custom workflow that performs a near-optimaltopological design for aGreenfield network given a set of input nodes, link cost tariffs and MPLS LSP demands. Please notethat, as of version 11.0, theMin_Cost_MPLS_Net_Design feature does not different forwardingclasses or classes of service (CoS). This document will be updated as this feature becomes available.

The following figure represents the process of Greenfield MPLS network design using theMin_Cost_MPLS_Net_Design custom design feature in SPGuru:

Lucent Technologies Inc. - ProprietaryUse pursuant to Company instructions.

1

Input Node

and Link Data

Input LSP

Requirements

Greenfield

Design

Output

Visualization
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/18

In the following, we discuss the components of the above process using an example network andexample screen captures from SPGuru, thereby outlining the typical steps required to use SPGuru forGreenfield MPLS network design.

1.2 Node and Link Data Input

The first step is to create a new project. This is accomplished by selecting File->New from theSPGuru splash screen, as shown in Figure 1.

Figure 1: SPGuru splash screen

Since we are interested in Greenfield design, it is not necessary to use the startup wizard to create anew scenario. The new window will show the new project, new scenario and the default world mapbackground. SPGuru allows for projects to consist of multiple scenarios. In general, it isrecommended to split the different phases of a network design project into multiple scenarios, eachrepresenting the completion of a certain action (for example, topology input, then design, thenfailure analysis, etc.). A scenario management interface is also provided. The new project andscenario can now be saved under a custom file, as shown in Figure 2. The zoom feature allows the


2


3/18

user to select different areas on the map. Multiple zoom-in actions will eventually display the namesof major cities.

Figure 2: Default view for a new project and scenario

1.2.1 Node Data Input

Node data can be input either using configuration files from Cisco and Juniper routers, or manuallyusing the SPGuru GUI. In the following, we use examples from the China Unicom design study toillustrate node data input procedures.

For manual node entry, the user has to select MPLS capable routers (LSRs) from the object palette.The first icon on the left of the icon bar can be used to access the object palette, as seen in Figure 2.

For our example, China Unicom uses Juniper T640 routers. These are found in the Juniper toolboxof the object palette, as shown in Figure 3. Once the T640 is selected, the user can click on any


3

Object Palette icon


4/18

location(s) in the map to place T640 devices (for this example, we chose the densely populated T640of the two options shown while placing the device, the model name wasJN_T640_s3_a16_ge48_sl64). Multiple nodes can be entered into the map and right clicking will

exit the entry mode.

Figure 3: The Juniper toolbox of the object palette

The attributes of the node can be edited by right clicking on the node icon on the map and selectingEdit Attributes. For now, we will only change the names, as shown in Figure 4.


4


5/18

Figure 4: Editing node attributes

Node data can also be entered using configuration files, or configlets, for Cisco and Juniper routers.To import topologies using configlet files, select Topology->Import Topology->From Device

Configurations, and specify the directories that contain the Cisco and Juniper configlet files. Notethat the configlet files do not contain information about the specific device model or interface speeds(hence, link speeds). The link speeds and node models need to be manually entered. In Figure 5, weshow a network imported using Juniper configlet files, and a section of the configlet file for theBeijing node. For this network, we have removed the links (since we will be performing Greenfielddesign), and we have set all node models toJN_T640_s3_a16_ge48_sl64. This network alsocontains a set of dynamic E-LSPs, which are not shown in this figure.

Figure 5: Network view after configlet import

1.2.2 Link Data Input


5


6/18

For Greenfield design using theMin_Cost_MPLS_Net_Design feature, the link data input consists ofa set of candidate links and link pricing information. Normally, a price can be associated with eachlink type in SPGuru. However, as of Release 11.0, theMin_Cost_MPLS_Net_Design feature

incorporates a link cost model that overrides the individual price models for the candidate links.The set of candidate links need to be placed in a custom object palette. A custom palette is createdby opening the object palette, selecting Configure Palette and saving an existing palette under acustom name (as a starting point for the custom palette). For this design example, we initially selectthe pre-defined links palette as the starting point, and save it under the nameMPLS_MandP_Example_Custom_Link_Palette. Once a custom palette is created, the next step is toadd/delete link types in this palette. These changes are made using the Configure Palette GUI andmust be saved (overwritten) toMPLS_MandP_Example_Custom_Link_Palette. For this example, weconfigured the custom palette as shown in Figure 6 to include DS3, OC-12 and OC-48 links. Notethat in SPGuru, the capacity of a link is defined by its data rate, not its transmission rate. Forexample, an OC-3 link has a capacity of 148.61 Mbps.

Figure 6: Custom link palette

Since theMin_Cost_MPLS_Net_Design feature tariff model overrides the link price settings fromthe palette, we will discuss link pricing in Section 1.4.

1.3 LSP Data Input

As in the case of the node data input, LSP data can be input either using configuration files fromCisco and Juniper routers, or manually using the SPGuru GUI. Continuing with our China Unicomexample, we will enter dynamic E-LSPs.

To manually enter LSPs, select theMPLS_E-LSP_DYNAMICmodel from the MPLS palette. Oncethe LSP model is selected, create LSPs one by one by selecting a source LSR, intermediate LSRs(if necessary, by right clicking on each intermediate LSR to add it to the path), and a destination


6


7/18

LSR (right click and cancel add action when done). Note that this creates a single LSP from sourceto destination. To create a pair of LSPs, a second LSP must be created in the opposite direction.Once all LSPs are entered, it is necessary to commit LSP information by selecting Protocols-

>MPLS->Update LSP Details. Since theMin_Cost_MPLS_Net_Design feature is meant forGreenfield design, we need to only assign the traffic engineering (TE) minimum bandwidth for theLSPs. This can be done one by one while entering LSPs, or a bandwidth can be macro-edited on agroup of selected LSPs. Figure 7 shows the MPLS palette and manual entry of an E-LSP and theLSP attributes where the TE bandwidth can be set. This particular example is for an E-LSP fromXian to Shenyang with an intermediate hop at Guangzhou. The TE bandwidth is set to 10 Mbps.

Figure 7: Manual LSP entry

As in the case of node data, LSP data can also be entered using configuration files, or configlets, forCisco and Juniper routers. To import topologies using configlet files, apply the same process asbefore, select Topology->Import Topology->From Device Configurations, and specify thedirectories that contain the Cisco and Juniper configlet files (this process will import all topologyinformation, including node locations, link topology-but not interface rates- and LSPs).


7


8/18

After an import is complete, the LSP information needs to be updated using Protocols->MPLS->Update LSP Details. In Figure 8, we show the result of an import process containing LSP pairs, andthe resulting point-to-point LSP requests that are generated after the LSP information is updated. In

our design example, we use the imported LSP requests and set the minimum TE bandwidth to 45Mbps for each of them.

After LSP Import After LSP UpdateAfter LSP Import After LSP Update

Figure 8: LSP entry by configlet import

1.4 Greenfield Design

The Greenfield design is performed using theMin_Cost_MPLS_Net_Design feature. This feature isaccessed through Design->Configure/Run Design Action menu, under the Topology Design section(the Design->Run Design Action menu allows for fast access to the currently configured design

actions but does not allow extensive editing and saving of the design parameters). Figure 9 showsthe numerous options that can be configured for this design. Of particular interest are the link costoptions, the link price sub-action, and the number of iterations and random cases, which we discussbelow. Once the options are set, the design action should be saved under a custom name, so that alloptions can be saved for future use, our design is calledMPLS_MandP_Example_Design. Note thatthe candidate link palette is set to our custom link palette,MPLS_MandP_Example_Custom_Link_Palette.


8


9/18

1.4.1 Link Cost Options

The design will be influenced by the link costing method. As mentioned earlier, theMin_Cost_MPLS_Net_Design feature overrides the link cost models associated with the link objectsin the object palette. There are two components to specifying link cost. The first is through the LinkMetric Information option in the design attributes. This generates a customized link metric costformula, which requires a financial cost function. The second is a customized link financial cost (ortariff) interface, which is accessed through theLink_Pricersub-action of theMin_Cost_MPLS_Net_Design feature. This sub-action allows the user to specify financial cost as acombination of fixed cost, cost per data rate, cost per distance and, optionally, different tariff ratesbetween given geographic locations (which requires the latitude and longitude information for thenode locations). These cost calculations apply to all candidate links in the network and override the

individual financial cost components defined in the object palette for the link objects.

Figure 9: Min_Cost_MPLS_Net_Design feature options


9


10/18

Figure 10: Link Metric Information parameters

Figure 10 shows our chosen parameters for the Link Metric Information fields. These include thedistance factor, cost (financial) factor, traffic factor and existing link discount factor. During theGreenfield design process, these factors determine the cost metric of candidate links. The linkmetric is a function of the distance, financial cost and traffic. Additionally, the metric of existinglinks can be discounted so that an existing link will be viewed cheaper (or free) during the design.Taken from the interactive help option in SPGuru, Figure 11 details how the link metrics arecalculated during the design:


10


11/18

Figure 11: Link metric calculations using the Link Metric Information fields

The parameters for the Link Price sub-action are shown in Figure 13. The financial cost of the link iscalculated as in Figure 12, and includes a fixed cost parameter, distance based cost parameter, datarate based cost parameter and a custom database based cost parameter, which is obtained from acustom tariff database file.

c_raw = custom_db_cost + fixed_cost + cost_per_kb * data_rate_in_kb + cost_per_km * distance_in_km

Figure 12: Financial cost calculations

For our design example, we assumed a fixed cost of $1000 per link, plus $100 every km., and a costper Kbps of $10. We did not include a custom tariff database for this design. The specified linkpricing sub-action can be saved for future access. As can be seen in Figure 13, we saved our actionasMandP_Example_link_pricer.


11

link_metric = distance_factor * d_norm + cost_factor * c_norm + traffic_factor * t_norm

d_95 = the 95% distance value over all candidate links considered. Used to normalize a raw distance value.

d_raw = the raw distance value for a candidate link

d_norm = 1.0 if d_raw > d_95

= d_raw/d_95 otherwise

c_95 = the 95% cost value over all candidate links considered. Used to normalize a raw cost value.

c_raw = the raw cost value for a candidate link

c_norm = 1.0 if c_raw > c_95

= c_raw/c_95 otherwise

Traffic is inversely weighted. More traffic results in a lower link cost metric in order to favor direct links betweennode pairs with high traffic.

t_95 = the 95% traffic value over all candidate links considered. Used to normalize a raw traffic value.

t_raw = the raw maximum traffic value between a node pair in bps. This includes direct traffic and traffic homed to

the node pair.

t_norm = 0.0 if t_raw > t_95

= 1 - t_raw/t_95

The link metric is further discounted by the Existing Link Discount if there already exists a link between the nodepair. If the link exists, but it is less than the required bandwidth, the discount is proportional to the amount of

bandwidth that is already provided.


12/18

Figure 13: Link Pricer sub-action parameters


12


13/18

1.4.2 Number of Iterations and Random Cases

TheMin_Cost_MPLS_Net_Design feature employs a heuristic based algorithm to arrive at a near

optimum topological design. Each run, or random case, of this algorithm starts with a random seed.The initial seed is specified as one of the options shown in Figure 9. For each run, one of the outputswill be a seed chosen for the subsequent run. The number of random cases refers to the number ofdifferent solutions, the lowest cost of which is chosen as the final solution. In each run, the numberof iterations specifies multiple solution iterations (discussed below). These iterations attempt toimprove the existing solution. By default, there are five runs (or random cases), with three iterationseach. Both of these are options, as shown in Figure 9. The run-time is linear with respect to both thenumber of random cases and the number of iterations. For each run, LSPs are first randomlyordered (using the seed) when there are no links in the network. From the generated order, the LSPsare sequentially routed using a minimum cost routing algorithm, where link metrics are updatedprior to the routing of each LSP. This is called the first iteration. In subsequent iterations, each LSP

is un-routed and rerouted one-by-one with all of the other LSPs still routed. This process is repeateduntil the number of iterations is exhausted. The end result of a run (which could include one or moreiterations) is a set of links and LSP routes, network link cost and random seed to be used for apotential subsequent run. The overall solution is the lowest cost solution of all the runs. Thisalgorithm used in theMin_Cost_MPLS_Net_Design feature in SPGuru version 11.0 is based on [1].

Based on [1], Figure 14 shows a possible high level description of the heuristic algorithm used foreach run-random case (to be verified when source code is available):

Begin

L = set of LSPs

E = set of all potential links

Randomly order LSPs based on seed

iteration = 1

Sequentially route all LSPs

while (iteration < Max_Number_of_Iterations) {

for each LSP k {

un-route LSP k and release its bandwidth

update network state

reroute LSP k using min cost routing with new network state

}

iteration++

}

End

Figure 14: Heuristic routing algorithm for each random case


13


14/18

1.4.3 Other Design Parameters

The Max Link Subscription refers to the maximum TE bandwidth assignable to a link as a

percentage of its capacity. The Port Constraint specifies whether or not the maximum number ofports available on an LSR can be exceeded. If enabled, links cannot be placed on routers withexhausted capacity. If disabled, routers can be overloaded, resulting in a warning message beinggenerated. The capacity conflict would then need to be manually remedied before further designoperations on the network.

1.5 Output Visualization

TheMin_Cost_MPLS_Net_Design feature generates two sets of reports. The first set consists oflogs, messages and overall design information. The second contains detailed information about the

added links and LSP routes. Also note that SPGuru automatically saves the newly designed networkin a new scenario. To open the logs, select Design->Results->Open Log. The reports contained inthis section include supervisory messages, warnings and errors, design action taken, etc. Thesummary log for our design is shown in Figure 15 and includes overall link and cost information.Most of the fields are self-explanatory. The Best Random Seed refers to the seed for the minimumcost design. The Details log (not shown) contains the automatically generated next seed, which canbe used as a starting point for further design runs.

Figure 15: The design summary log


14


15/18

To open the output tables, select Design->Results->Open->View Output Tables. The relevantoutputs will be contained underMPLS_MandP_Example_Design. Choose Link Summary to accessthe link report, which shows detailed information about the added links. This information includes

source, destination, link type, TE bandwidth, cost and a Details tab that shows information about thecontained LSPs. Clicking the Show button at the bottom right corner will spawn a self-containedLinks window that contains hyperlinks (shown in red) to link and node objects in the SPGuru GUI,as shown in Figure 16. All links generated are OC-3 links (other candidates were DS3 and OC-12).

Figure 16: Design Link Summary


15


16/18

Similarly, LSP Summary provides access to the LSP report, which shows detailed information aboutthe LSP source, destination, TE bandwidth, explicit route name and number of hops. Clicking theshow button will spawn a self-contained LSP window that also contains hyperlinks (shown in red) to

the SPGuru GUI, as shown in Figure 17.

Figure 17: Design LSP Summary

All design reports can also be saved as a web report by clicking the Generate Web Report button. Toview the generated links in the SPGuru GUI, hide the LSPs using Protocols->MPLS->Hide All

LSPs. Figure 18 shows the resulting network topology as viewed through the network browser(View->Show Network Browser). In the network browser, the left pane contains the list of nodes.Selecting a node will drop down the list of links incident to that node, and selecting a link willhighlight it in the network view.


16


17/18

Figure 18: Network Browser View of final network topology

The LSP explicit routes are stored in the source LSR. From the GUI, one method for viewing theLSP explicit routes is to open the connections browser from Topology->Open Connections Browser.In the connections browser, selecting a node on the left pane will drop down the list of LSPsoriginating at that node. Selecting the LSP will show the LSP demand in the network view andreveal an explicit routes field. Selecting the explicit routes field will show the LSP route in thenetwork view. Figure 19 shows the explicit route for an LSP from Chengdu to Guangzhou, goingthrough Beijing and Xian.


17


18/18

Figure 19: Connections Browser view of final network topology

References

1. Chalermpol Charnsripinyo and David Tipper, Topological Design of Survivable WirelessAccess Networks, inDesign of Reliable Communication Networks (DRCN) 2003, Banff,Alberta, Canada, Oct. 2003.

Lucent Technologies Inc. - Proprietary

Documents

Greenfield MPLS Network Design Using SPGuru.doc