Overview


Cisco MetroPlanner 2.5.1 provides a means to construct and test wavelength division multiplexing (WDM) optical networks in a modelled graphical environment. Well-designed optical networks can take advantage of the availability of dark fiber to build a common infrastructure that supports data, storage area network (SAN), and time-division multiplexing (TDM) traffic.

The primary purpose of MetroPlanner is to assist sales engineers (SEs) in the design and validation of optical networking deployment using Cisco Optical Networking System (ONS) 15454 Multi-Service Transport Platforms (MSTP). MetroPlanner generates a shelf view of all the sites deployed in the optical network and provides a complete bill of materials (BOM) for the network.

This chapter describes how you use MetroPlanner to design, analyze, and optimize new or existing Cisco optical networks.

This chapter contains the following sections:

MetroPlanner Features

Network Design Process

Internal Architecture

MetroPlanner Procedural Flow

Planning Traffic in MetroPlanner 2.5.1

Viewing Traffic in MetroPlanner 2.5.1

1.1  MetroPlanner Features

MetroPlanner 2.5.1 provides a simple tool set for designing optical networks with Cisco ONS 15454 MSTP products. By entering specific configurations, or only the barest essentials of site distances, you can make the correct choices for the type of network you wish to build. Several solutions can correspond to one type of equipment or platform. The MetroPlanner 2.5.1 graphical user interface (GUI) models general specifications and produces detailed BOMs to provision optimized networks.

Designing optical networks requires the verification of multiple constraints such as optical budget limitations and platform architectural constraints. Both simple and complex optical network designs are automatically modelled and tested by MetroPlanner 2.5.1.

1.2  Network Design Process

The MetroPlanner 2.5.1 GUI allows SEs to design and document network designs and validate optical networking implementations on the Cisco ONS 15454 MSTP platform. Using MetroPlanner 2.5.1, you can perform the following tasks:

Create network topologies

Define network requirements (service demands, protection)

Validate the network constraints (optical budget, receiver overload)

Create corresponding BOMs and build reports

Using the MetroPlanner-generated BOM, you can place the order directly on Cisco.com.

The MetroPlanner 2.5.1 GUI allows the SE to do the following:

Create a node at a site

Interconnect sites with fiber spans

Specify the requested service demands between nodes

Define the type of protection scheme

1.2.1  Network Design Optimization

The total network cost is the cost of the equipment for all of the sites in the designed network. MetroPlanner 2.5.1 searches for the best solution to a designed network using an optimization algorithm.

1.2.2  Network Design Constraints

A network design must meet the optical budget and receiver overload criteria to operate efficiently. The analysis of optical budget and receiver overload evaluates the strength of the signal traversing the ring. If a design solution satisfies the constraints, it is a valid design. The MetroPlanner 2.5.1 optimization algorithms generate multiple solutions and verify the constraints against those solutions. If the constraints are satisfied, the solution with the lowest cost-to-utilization ratio is selected as the optimal solution.

If the network design solution fails to satisfy all the constraints, MetroPlanner 2.5.1 makes adjustments to parameters such as signal attenuation and amplification. Amplification is achieved either by using an erbium-doped fiber amplifier (EDFA). Attenuation is achieved by using variable optical attenuator (VOA) modules integrated into the platform. MetroPlanner 2.5.1 corrects the optical budget using an algorithm that includes automatic placement of EDFAs and VOA regulation.

For each internodal demand, MetroPlanner 2.5.1 performs an optical budget and receiver overload analysis and the displays the results in form of various reports in the GUI. If the network design algorithms are not able to provide a solution, then the user can modify the input data (for example, by relaxing some user constraints) and run the analysis again.

1.3  Internal Architecture

To generate a network design, the SE enters the following parameters:

The number of network sites

The type of equipment used at each site

The distance separating the sites

The type of fiber connecting the sites

Service demands, including the service type, the protection type, and the number of channels between nodes

Once the network parameters have been entered, the MetroPlanner finds the best routing, defines the required add/drop filters, and places optical amplifiers and dispersion compensation units (DCUs) to fit the user traffic demands at the minimum cost. Optimization is performed to meet the boundary conditions. The optimization includes attenuation and amplification.

Finally, MetroPlanner 2.5.1 generates the BOM, which includes the product code, the quantity, and pricing information. In addition, it creates other reports, such as a shelf-level view of the configuration, which can be printed. This helps the SE understand how the shelf is built and helps to avoid confusion and errors during the actual deployment. Within the BOM is the total network cost, which allows a quick comparison of various design options.

1.3.1  Platform Support

MetroPlanner Release 2.5.1 supports the Cisco ONS 15454 DWDM optical platform.

1.3.2  Topology Support

MetroPlanner 2.5.1 supports the following network topologies:

Bus (single span, point-to-point, and linear)

Open (or hubbed) ring

Closed (or meshed) ring

Any to Any ring

1.3.3  Protection Scheme Support

MetroPlanner 2.5.1 designs support the following protection schemes:

Client-based 1+1 protection

Fiber switched protection

Y-cable protection

Unprotected

1.3.4  Service Support

MetroPlanner 2.5.1 can support any subset of the following services:

2R Any Rate

Gigabit Ethernet

10GE—10 Gigabit Ethernet

ESCON—Enterprise System Connection

Fibre Channel

Fibre Channel 2G

Fibre Channel 10G

STM-1

STM-4

STM-16

STM-64

OC-3

OC-12

OC-48

OC-192

Sysplex CLO—Control Link Oscillator

Sysplex ETR—External Throughput Rate

D1 Video

SDI—Serial Data Input

FICON—Fiber Connection

FICON 2G

ISC-Peer (ISC-1 Peer Mode)

ISC-Compat (ISC-3 Compatibility Mode)

15530 2.5.1Gbps Aggregated

15530 10Gbps Aggregated

15530 MR Transport

15530 Data MXP

HDTV

D1 Video

DV-6000


Note The Sysplex CLO and Sysplex ETR services are only supported on the following topologies:

Single span—Two terminal sites with 32MUX-O and 32DMX-O, or 32WSS and32DMX or 32-DMX-O cards installed and no intermediate sites in between.

Point-to-Point—Two terminal sites with 32MUX-O and 32DMX-O or 32WSS and32DMX or 32-DMX-O cards installed. Line amplifiers can be installed between the terminal sites, but intermediate (traffic terminating) sites cannot be installed.

Two hubs—Two hub nodes in a ring with 32MUX-O and 32DMX-O 32WSS and32DMX or 32-DMX-O cards installed. Line amplifiers can be installed between the hubs.

Refer to the Cisco ONS 15454 DWDM Installation and Operations Guide for more infomation about the supported topologies for the ETR and CLO services.


1.4  MetroPlanner Procedural Flow

The flowchart in Figure 1-1 shows the following stages used to create a complete network design:

1. Place sites in the network. A site represents a potential location for placing equipment. This can be accomplished by adding one site at a time or by using the Add Network tool to add multiple sites at once.

2. Place fiber spans between the sites. A span represents a pair of fibers.

3. Specify service demands between sites as required. For Fixed adn P-Ring demands, only one line will be drawn to represent all services between a particular service source and service destination site.

4. Analyze the network design.

5. In the event that the user would like to force automatic tool choices, there are options to adjust the design and repeat the analysis until the desired configuration is achieved.

1.5  Planning Traffic in MetroPlanner 2.5.1

Traffic in MetroPlanner 2.5.1 is defined as an optical path for each pair of nodes requiring a service demand. An optical path (connectivity) is defined as the sum of a wavelength between the two nodes. This task is performed by creating a network design that minimizes the overall cost.

MetroPlanner 2.5.1 allows you to design flexible networks. A flexible network is a network that, leveraging on the Reconfigurable OADM (ROADM) nodes, allows traffic modification/reconfiguration as traffic requirements change. The main feature of flexible networks is the traffic reconfiguration/modification among all the networked nodes or among a subset of them.

1.5.1  Basic Traffic Items

The following list gives definitions for some basic traffic items:

Circuit—A single wavelength between a pair of source and destination nodes. In addition to the source and destination nodes and all the attributes that are common to the demand containing the circuit, it defines the following list of attributes:

Present/Forecast indication

Routing direction for unprotected service

ITU channel

Optical bypass indication

Connectivity—An undefined number of channels than can vary from 0 to 32 between a pair of nodes. The connectivity takes the meaningful parameter values of the circuit demand to which the connectivity belongs.

Demand—A set of services of the same type. It defines the set of parameters common to all the circuits or connectivity that are part of this demand. The list of relevant attributes are:

Service Demand Label

Number of circuit in present

Number of circuit in forecast

Client Service Type

Protection Type

Optical bypass number of channels

Optical bypass site

Wave division multiplexing (WDM) Interface Type (TXT or ITU-LC choice)

WDM Card Type

Src Client Interface (SR, IR, or LR)

Dst Client Interface (SR, IR, or LR)

Traffic Group: Groups all the demands between same set of nodes. The following traffic groups are supported:

ROADM—All nodes in the subset can be connected. The way each node can be connected with the others depends on the way you define the Traffic Type parameter. The number of channels can vary from 0 to 32.

Meshed—Each node defined in the set is connected to each other. This is the most common traffic type.

Hub—The user-defined hub node is connected to each of the other nodes defined in the subset.

P-Ring—Contains all the demands to support traffic topologies similar to bidirectional line switch ring (BLSR) or multiplex section-shared protection ring (MS-SPRing). Each demand that is part of the P-Ring is defined between a pair of nodes in the list of the added/dropped nodes where BLSR-like (or MS-SPRing-like) traffic must be opened. The number of circuits is the same for each demand, and must be user-specified (from 1 to 32).

Fixed—Restricts the set of nodes at 2 sites. The number of circuits of each demand must be user-specified (from 1 to 32).

1.5.2  Any-to-Any Traffic Demands

An any-to-any traffic demand is defined among a subset of nodes (minimum of two, maximum of every node in the network). An any-to-any traffic demand allows each node belonging to the subset to establish one or more circuits (an optical path carrying a service) with the other nodes. These circutis have the same protection types and services to be carried. The actual connection capacity between each pair of nodes belonging to the subset is dependant on the specific traffic pattern present in the overall network, not just within the selected subset.

1.6  Viewing Traffic in MetroPlanner 2.5.1

MetroPlanner 2.5.1 represents all the user-defined traffic services as an explorer tree view within the Traffic Tree window. Fixed, P-Ring, and ROADM traffic groups are shown on the tree view (Figure 1-1).

Figure 1-1 Tree View

Right-click an item to view a menu that allows you to view the optical results or the traffic matrix. Right-clicking on the site name also allows you to edit the services. Refer to Chapter 2, "Designing Networks with MetroPlanner" for more information about optical results, the traffic matrix, and editing services.


Note The tree view appears gray until you analyze the network. Refer to the "2.4  Analyzing the Network" section on page 2-32. You cannot access the right-click menu until the network is analyzed.


The colors of tree view change according to the error/warning condition of the network design. The icons will display as red if there are errors in the network design; orange if there are warnings but no errors; and green of there are no warnings or errors. At the network level, the icon displays the color of the most severe condition. MetroPlanner 2.5 designs all display as gray.

1.6.1  Fixed Traffic Groups

Each fixed traffic group is represented by a folder labeled with a concatenation of the source and destination site names. All the fixed services between these nodes are represented in this traffic group (Figure 1-2).

Figure 1-2 Fixed Traffic Group

Each fixed demand defined between these nodes is represented by an item in this traffic group. The fixed demand is labeled using the following information:

Client Service Type

Protection Type

The number of present and forecast channels

The tree view shows a list of defined service circuits under each fixed demand. All the service circuits are grouped in the Connectivities folder.

Each service circuit is labeled with a string containing the service circuit label and the Present/Forecast (P&F) indication. The P represents circuits present since day 1, and the F represents circuits defined in the forecast.


Note For ROADM network topologies, fixed traffic can also include traffic demand with optical-bypass sites. No additional patch cords are required for express or optical bypass channels in ROADM sites.


1.6.2  P-Ring Traffic Groups

Protected ring (P-ring) traffics groups are represented in the tree by a folder. This folder is labeled by using a concatenation of the P-Ring substring and a progressive number automatically assigned by MetroPlanner 2.5.1. Figure 1-3 shows an example of a P-ring traffic group.

Figure 1-3 P-Ring Traffic Group Example

The list of add/drop sites (as defined in the P-Ring request) is shown in the P-Ring Traffic Group folder. All the demands between each node pair are represented under this traffic group. Each demand (generated by the P-Ring wizard) is labeled concatenating the following information:

SiteA-SiteB (source and destination node labels for this demand)

Client Service Type

The number of present and forecast channels

Each service circuit is labeled as described in the "Fixed Traffic Groups" section.


Note For ROADM network topologies, P-ring traffic can also include traffic demand with optical-bypass sites. No additional patch cords are required for express or optical bypass channels in ROADM sites.


1.6.3  ROADM Traffic Groups

Each ROADM traffic group is represented in the tree view by a folder labeled under the root traffic network. All the sites and demands between each node pairs defined in the list (of added/dropped nodes) are represented under this traffic group.

The ROADM traffic group folder contains the following information:

One item for each site that is part of this ROADM group. You can only define one set of nodes for each ROADM group.

One folder for each defined ROADM demand. You can define more demands for the same ROADM group for the same set of nodes.

Figure 1-4 shows an example of an ROADM traffic group.

Figure 1-4 ROADM Traffic Group Example

Each ROADM demand is defined by the ROADM demand name. The following set of parameters are represented as an item of the ROADM demand in the tree view:

Traffic Type—Defines the supported traffic pattern type. The following options are supported:

Meshed (Default)—A traffic pattern where a connectivity is defined for each node pair in the traffic group

Hub (Hub Node)—Defines connectivity between the defined hub node and every other node in the traffic group. You must specify the selected hub node among the list in the group.

Routing Strategy—defines the maximum number of allowed connectivities, and the way the connectivities are routed by MetroPlanner 2.5.1. The following options are supported:

Protected (Default)—Each node pair in the traffic group is connected using two connectivities.

Unprotected Optimum Optical Path—Each node pair is connected using one connectivity. The Unprotected Optimum Optical Path minimizes the number of required optical amplifiers, but also restricts the number of channels that can be deployed among the nodes of the traffic group (maximum of 32 channels between each node pair) in the installed network.

Unprotected Minimum Hop Count—Each node pair in the traffic group is connected by one connectivity. The unprotected minimum hop count maximizes the number of channels (for unprotected traffic types only) that can be deployed among the nodes of the traffic group, but can requires a higher number of optical amplifiers on the unprotected optimum optical path (maximum of 32 channels between each node pair) in the installed network.

Unprotected Subnet—Each node pair in the traffic group is connected using one connectivity. You can manually force connectivities on only one branch of the ring. For unprotected subnets, you must manually select one starting node of the branch and the direction the ring must be traversed to define the subnet, starting from the initial site. Branch direction is specified defining the outgoing side referred to the starting node.This routing strategy option allows you to exclude some critical paths and (with ROADM traffic groups containing 2 sites) to force each ROADM connectivity clockwise or counterclockwise.

List of selected Client Service Types—The list of client service types to be supported for this demand is represent by a set of item under the related ROADM Demand folder. You can simultaneously request more then one Client Service Type for each demand (Any Client).

List of selected DWDM Card Interfaces—Represents the list of DWDM card interfaces you selected to support the list of selected Client Service Types. You can simultaneously request more than one DWDM card interface for each demand and for each client service type. Each DWDM card interface is characterized by a set of optical performances. Each DWDM card interface is labeled by concatenating the selected DWDM card type and the protection type information. A tooltip on each DWDM card interface item shows which client service types are supported by this interface.

To avoid duplication in the tree view while using the Protected routing strategy:

DWDM card interfaces with client 1+1 and Y-cable protection types are represented by only one DWDM card interface item. The selected protection types are listed in brackets, separated by commas.

DWDM card interfaces with fiber-switched protection types are represented by a separate DWDM card interface item.