Sie sind auf Seite 1von 18

Subject:

Greenfield MPLS Network Design Using SPGuru

Date: From:

2013-4-10 Ahmet Akyamac Benjamin Tang Ramesh Nagarajan Advanced Technologies Bell Laboratories Holmdel, NJ07744 (732) 949-5413 (732) 949-6477 (732) 949-2761 akyamac@lucent.com btang@lucent.com rameshn@lucent.com

1. Introduction & Scope


SPGuru is a network design, capacity planning and traffic engineering tool offered by Opnet. It incorporates 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 and MPLS. This document focuses on the Greenfield topological design of MPLS networks using Opnets 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 to Lucent Technologies contains a custom design feature called Min_Cost_MPLS_Net_Design. This feature represents a custom workflow that performs a near-optimal topological design for a Greenfield network given a set of input nodes, link cost tariffs and MPLS LSP demands. Please note that, as of version 11.0, the Min_Cost_MPLS_Net_Design feature does not different forwarding classes 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 the Min_Cost_MPLS_Net_Design custom design feature in SPGuru:

Input Node and Link Data

Input LSP Requirements

Greenfield Design

Output Visualization

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

In the following, we discuss the components of the above process using an example network and example screen captures from SPGuru, thereby outlining the typical steps required to use SPGuru for Greenfield 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 the SPGuru 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 a new scenario. The new window will show the new project, new scenario and the default world map background. SPGuru allows for projects to consist of multiple scenarios. In general, it is recommended to split the different phases of a network design project into multiple scenarios, each representing the completion of a certain action (for example, topology input, then design, then failure analysis, etc.). A scenario management interface is also provided. The new project and scenario can now be saved under a custom file, as shown in Figure 2. The zoom feature allows the

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

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

Object Palette icon

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 manually using the SPGuru GUI. In the following, we use examples from the China Unicom design study to illustrate 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 toolbox of the object palette, as shown in Figure 3. Once the T640 is selected, the user can click on any

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

location(s) in the map to place T640 devices (for this example, we chose the densely populated T640 of the two options shown while placing the device, the model name was JN_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 selecting Edit Attributes. For now, we will only change the names, as shown in Figure 4.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

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. Note that 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, we show a network imported using Juniper configlet files, and a section of the configlet file for the Beijing node. For this network, we have removed the links (since we will be performing Greenfield design), and we have set all node models to JN_T640_s3_a16_ge48_sl64. This network also contains 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

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

For Greenfield design using the Min_Cost_MPLS_Net_Design feature, the link data input consists of a set of candidate links and link pricing information. Normally, a price can be associated with each link type in SPGuru. However, as of Release 11.0, the Min_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 created by opening the object palette, selecting Configure Palette and saving an existing palette under a custom name (as a starting point for the custom palette). For this design example, we initially select the pre-defined links palette as the starting point, and save it under the name MPLS_MandP_Example_Custom_Link_Palette. Once a custom palette is created, the next step is to add/delete link types in this palette. These changes are made using the Configure Palette GUI and must be saved (overwritten) to MPLS_MandP_Example_Custom_Link_Palette. For this example, we configured the custom palette as shown in Figure 6 to include DS3, OC-12 and OC-48 links. Note that in SPGuru, the capacity of a link is defined by its data rate, not its transmission rate. For example, an OC-3 link has a capacity of 148.61 Mbps.

Figure 6: Custom link palette

Since the Min_Cost_MPLS_Net_Design feature tariff model overrides the link price settings from the 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 from Cisco and Juniper routers, or manually using the SPGuru GUI. Continuing with our China Unicom example, we will enter dynamic E-LSPs. To manually enter LSPs, select the MPLS_E-LSP_DYNAMIC model from the MPLS palette. Once the 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

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

LSR (right click and cancel add action when done). Note that this creates a single LSP from source to 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 the Min_Cost_MPLS_Net_Design feature is meant for Greenfield design, we need to only assign the traffic engineering (TE) minimum bandwidth for the LSPs. This can be done one by one while entering LSPs, or a bandwidth can be macro-edited on a group of selected LSPs. Figure 7 shows the MPLS palette and manual entry of an E-LSP and the LSP attributes where the TE bandwidth can be set. This particular example is for an E-LSP from Xian 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, for Cisco and Juniper routers. To import topologies using configlet files, apply the same process as before, select Topology->Import Topology->From Device Configurations, and specify the directories that contain the Cisco and Juniper configlet files (this process will import all topology information, including node locations, link topology-but not interface rates- and LSPs).

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

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, and the 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 45 Mbps for each of them.

After LSP Import

After LSP Update

Figure 8: LSP entry by configlet import

1.4 Greenfield Design


The Greenfield design is performed using the Min_Cost_MPLS_Net_Design feature. This feature is accessed 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 shows the numerous options that can be configured for this design. Of particular interest are the link cost options, the link price sub-action, and the number of iterations and random cases, which we discuss below. Once the options are set, the design action should be saved under a custom name, so that all options can be saved for future use, our design is called MPLS_MandP_Example_Design. Note that the candidate link palette is set to our custom link palette, MPLS_MandP_Example_Custom_Link_Palette.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

1.4.1 Link Cost Options The design will be influenced by the link costing method. As mentioned earlier, the Min_Cost_MPLS_Net_Design feature overrides the link cost models associated with the link objects in the object palette. There are two components to specifying link cost. The first is through the Link Metric Information option in the design attributes. This generates a customized link metric cost formula, which requires a financial cost function. The second is a customized link financial cost (or tariff) interface, which is accessed through the Link_Pricer sub-action of the Min_Cost_MPLS_Net_Design feature. This sub-action allows the user to specify financial cost as a combination of fixed cost, cost per data rate, cost per distance and, optionally, different tariff rates between given geographic locations (which requires the latitude and longitude information for the node 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

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

Figure 10: Link Metric Information parameters

Figure 10 shows our chosen parameters for the Link Metric Information fields. These include the distance factor, cost (financial) factor, traffic factor and existing link discount factor. During the Greenfield design process, these factors determine the cost metric of candidate links. The link metric is a function of the distance, financial cost and traffic. Additionally, the metric of existing links 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 are calculated during the design:

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

10

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.
d_raw = the raw distance value for a candidate link d_norm = 1.0 if d_raw > d_95 = d_raw/d_95 otherwise Used to normalize a raw distance value.

c_95 = the 95% cost value over all candidate links considered.
c_raw = the raw cost value for a candidate link c_norm = 1.0 if c_raw > c_95 = c_raw/c_95 otherwise

Used to normalize a raw cost value.

Traffic is inversely weighted.


node pairs with high traffic.

More traffic results in a lower link cost metric in order to favor direct links between

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 node
pair. 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.

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 is calculated as in Figure 12, and includes a fixed cost parameter, distance based cost parameter, data rate based cost parameter and a custom database based cost parameter, which is obtained from a custom 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 cost per Kbps of $10. We did not include a custom tariff database for this design. The specified link pricing sub-action can be saved for future access. As can be seen in Figure 13, we saved our action as MandP_Example_link_pricer.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

11

Figure 13: Link Pricer sub-action parameters

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

12

1.4.2 Number of Iterations and Random Cases The Min_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 outputs will be a seed chosen for the subsequent run. The number of random cases refers to the number of different solutions, the lowest cost of which is chosen as the final solution. In each run, the number of iterations specifies multiple solution iterations (discussed below). These iterations attempt to improve the existing solution. By default, there are five runs (or random cases), with three iterations each. Both of these are options, as shown in Figure 9. The run-time is linear with respect to both the number of random cases and the number of iterations. For each run, LSPs are first randomly ordered (using the seed) when there are no links in the network. From the generated order, the LSPs are sequentially routed using a minimum cost routing algorithm, where link metrics are updated prior 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 repeated until the number of iterations is exhausted. The end result of a run (which could include one or more iterations) is a set of links and LSP routes, network link cost and random seed to be used for a potential subsequent run. The overall solution is the lowest cost solution of all the runs. This algorithm used in the Min_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 for each 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

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

13

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 of ports available on an LSR can be exceeded. If enabled, links cannot be placed on routers with exhausted capacity. If disabled, routers can be overloaded, resulting in a warning message being generated. The capacity conflict would then need to be manually remedied before further design operations on the network.

1.5 Output Visualization


The Min_Cost_MPLS_Net_Design feature generates two sets of reports. The first set consists of logs, 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 network in a new scenario. To open the logs, select Design->Results->Open Log. The reports contained in this section include supervisory messages, warnings and errors, design action taken, etc. The summary 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 minimum cost design. The Details log (not shown) contains the automatically generated next seed, which can be used as a starting point for further design runs.

Figure 15: The design summary log

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

14

To open the output tables, select Design->Results->Open->View Output Tables. The relevant outputs will be contained under MPLS_MandP_Example_Design. Choose Link Summary to access the 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 the contained LSPs. Clicking the Show button at the bottom right corner will spawn a self-contained Links 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

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

15

Similarly, LSP Summary provides access to the LSP report, which shows detailed information about the LSP source, destination, TE bandwidth, explicit route name and number of hops. Clicking the show 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. To view 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 will highlight it in the network view.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

16

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 the LSP 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 LSPs originating at that node. Selecting the LSP will show the LSP demand in the network view and reveal an explicit routes field. Selecting the explicit routes field will show the LSP route in the network view. Figure 19 shows the explicit route for an LSP from Chengdu to Guangzhou, going through Beijing and Xian.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

17

Figure 19: Connections Browser view of final network topology

References
1. Chalermpol Charnsripinyo and David Tipper, Topological Design of Survivable Wireless Access Networks, in Design of Reliable Communication Networks (DRCN) 2003, Banff, Alberta, Canada, Oct. 2003.

Lucent Technologies Inc. - Proprietary


Use pursuant to Company instructions.

18

Das könnte Ihnen auch gefallen