Demand Groupings
Demand Groupings define a group of demands. They provide a convenient way of specifying aggregated traffic in a plan, which can be used as a basis for traffic reports and growth plans. For example, you can use demand groupings to represent the following.
-
Total traffic sourced from one specific site
-
Total VPN traffic, or any defined service class, sourced from one specific site to another
-
Total traffic destined for a particular AS
To generate a report on demand groupings, including costs associated with them, choose Tools > Reports > Demand Groupings. For detailed information, see Demand Groupings Reports. For a description of the cost modeling columns in the report output, see Cost Modeling.
Demand Groupings and Their Filters
The term demand grouping refers to a set of filters (rules) that determine a group of demands. For example, you could create a demand grouping that filters all demands sourced from Paris, and name it ParisSrc. When you apply the filter, if 52 of the existing demands contain Paris as a source, those 52 demands combined comprise a single demand grouping called ParisSrc.
Each row in the Demand Groupings table identifies a uniquely named demand grouping and the associated filters that define which demands are in it.
-
Each column other than Name is a criterion that a demand must meet to be in that demand grouping.
-
A demand must meet all criteria defined in these columns in order for it to be a member of the demand grouping.
-
If the field is empty, it is not used as a criterion.
-
The column headings with “Matches” in the name use regular expressions and the filters are applied accordingly.
Example: If Destination Node Matches is .*\.atl$, a demand can be a member of this demand grouping only if it has destination nodes ending in .atl and if it meets all other criteria (listed in the other columns).
-
The column heading that use “Equals” in the name must be exact matches.
Example: If Source Site Equals is chi, a demand can be a member of this demand grouping if its source site is named exactly chi and if it meets all other criteria.
-
If the Tags Include column has an entry, a demand must contain this tag to be included in this demand grouping. (Demands can have multiple tags.)
Example: If Tags Include is atlantic, and if a demand has three tags named europe, atlantic, and apac, then the demand would be included in this demand grouping provided it meets all other criteria.
There are other object-based Tags Include columns for source and destination sites, nodes, and ASes. If one of these columns has an entry, the source or destination object must contain this tag to be included in this demand grouping.
Example: If Source Site Tags Include is Europe and if the Dest Site Tags Include is Asia, the demand would be included in this demand grouping if its source site is tagged with Europe, if its destination site is tagged with Asia, and if it meets all other criteria.
-
Demand Grouping columns can contain information that does not exist in the current plan. This flexibility allows a demand grouping to be applied to any network.
To see a list of demands that comprise a demand grouping, in the Demands Grouping table, right-click the row containing the unique demand grouping name and select Filter to Associated Demands.
-
In Demand Groupings Contain Demands, if you were to filter to associated demands on the first row (chi to bos), the resulting Demands table would show four demands because they are the only ones with both chi as the source and bos as the destination.
-
If you were to filter to associated demands on the second row (chi to All), the resulting Demands table would show all demands with chi as the source, no matter the destination.
To see all demand groupings in which a demand exists, in the Demands table, right-click the row containing the demand of interest and select Filter to Demand Groupings.
-
In Demands Contained in Demand Groupings, if you were to filter to associated demand groupings on the second row (cr1.chi_cr1.mia), the resulting Demand Groupings table would show the two demand groupings that contain this demand (chi to All, and All to mia).
-
If you were to filter to associated demand groupings on the first row (cr1.bos_cr1.mia), the resulting Demand Groupings table would show the only demand grouping that contains it (All to mia).
Creating a Single Demand Grouping
This method lets you create a single demand grouping. All fields other than the Name field combine to create a set of rules, or filters, for the demand grouping. A demand must meet all of the specified criteria for it to be included in the demand grouping. If you specify one or more growth values, the demand grouping can be used in creating growth plans.
Note that you can also import demand groupings. For information, see the Cisco WAE Design Integration and Development Guide .
Procedure
Step 1 |
Choose Insert > Demands > Demand Grouping, or right-click in the empty plot area and choose New > Demands > Demand Grouping. |
Step 2 |
Enter a unique name for the demand grouping. If you do not add a name, WAE Design renames the grouping to make it unique. |
Step 3 |
Enter information as needed in the Demands, Source, and Destination fields to create the set of rules that define the demand grouping. Each of these is a demand filter.
|
Step 4 |
If you want to use this demand grouping when creating growth plans, enter one or more values in the Growth area. See Single-Period Demand Grouping Traffic for information on these values. |
Step 5 |
Click OK. |
Creating a Demand Grouping Mesh
A mesh of demand groupings is a set of demand groupings created between a specified set of sources and destinations. It is often more convenient to create an entire mesh at once than to create the demand groupings individually.
There are two methods for quickly creating a demand grouping mesh:
-
Choose Insert > Demands > Demand Grouping Mesh or New > Demands > Demand Grouping as described the following steps.
-
Importing existing demand groupings from another plan file or table file. For information on importing demand groupings, see the Cisco WAE Design Integration and Development Guide .
Because you are creating a set of filters, not all steps are required. By default, the Insert Demand Grouping Mesh uses selected sites (or all sites if none are selected) as the source and does not group by destination. To change the default and further restrict the demand grouping, you can choose from any combination of source, destination, service class, and demand name, as well as use object tags.
If you select multiple sites before opening the dialog box and use those sites for either the source, destination, or both, a unique demand grouping is created for each selection.
Examples: If you select both chi and mia sites for the source and nothing for destination, two demand groupings are generated: one named chi to All and one named mia to All . If you select both bos and nyc as both source and destination, four demand groupings are created: bos to bos , bos to nyc , nyc to nyc , and nyc to bos .
Procedure
Step 1 |
Select sites, nodes, or ASes if you want to create the demand grouping for a specific set of selected objects, whether as source, destination, or both. |
Step 2 |
Choose Insert > Demands > Demand Grouping Mesh, or right-click in an empty area and choose New > Demands > Demand Grouping Mesh. |
Step 3 |
For both source and destination, you have these options:
|
Step 4 |
In addition to or instead of selecting sources or destinations, you can create the grouping by restricting it to specific demands.
|
Step 5 |
The demand grouping names are created based on the name or variables used in the Name of Grouping field.
If a demand grouping is selected using source and destination tags, then $1 is the name of the source tag, and $2 is the name of the destination tag.
Example: You could select and use chi as the source, leave the destination empty, and add an extension of voice, thus creating a demand grouping named chi to All voice . |
Step 6 |
Click OK. |
Demand Groupings Reports
You can generate Demand Groupings reports on plan files that contain demand groupings. Each report has two sections:
-
Demand Groupings—For each demand grouping in the plan file, this section lists the name, traffic level to which it applies, and the number of demands. All other columns are based on the total (aggregate) of all demands in the demand grouping, traffic, capacity bound, capacity violation, QoS bound, QoS violation, cost by capacity, and cost by utilization. These costs are the sum of the demands in the demand grouping.
-
Capacity Bound—The maximum amount that the sum of the demands in the demand grouping can be without causing over 100% utilization on any interface in the network. The calculation is based on the assumption that all demand traffic increases proportionally.
-
Capacity Violation—Total traffic minus the capacity permitted for the demand grouping (Capacity Bound). A violation occurs if the Capacity Bound is exceeded. If the number appearing in the Capacity Violation column is positive, then the Capacity Bound has been surpassed. If the number is negative, the Capacity Bound has not been reached.
-
For information on QoS bound and QoS violation, see Quality of Service Simulation.
-
For information on how these costs are calculated, see Cost Modeling.
-
-
Demands—For each demand in the plan file, regardless of whether it is in a demand grouping or not, this section lists the name, source and destination, service class, and number of demand groupings to which it belongs.
To generate a Demand Groupings report, choose Tools > Reports > Demand Groupings, and then click OK.
Example of Capacity Bound and Capacity Violation
Each interface imposes a limit on the traffic that can be carried by all demands in the demand grouping.
The goal of this example is to determine which interface is limiting the demand grouping’s ability to deliver traffic. To do this, WAE Design looks at the interfaces over which each demand is routed. WAE Design then calculates the maximum traffic that can be used for the demand without exceeding 100% utilization for any routed interface.
In this example, the demands and interfaces are as follows.
-
All interfaces have 1000 Mbps of traffic.
-
The demand grouping is Acme_Region.
-
sjc_wdc_demand has 300 Mbps of traffic, and it traverses A_interface and B_interface.
-
sjc_hst_demand has 200 Mbps of traffic, and it traverses A_interface and C_interface.
-
-
There are other demands outside this demand grouping.
A_interface has 600 Mbps of traffic. Of this, 500 Mbps of it is from the Acme Region demand grouping, and the remaining 100 Mbps is from demands outside this Acme_Region demand grouping.
B_interface has 500 Mbps of traffic, of which 300 Mbps is from the sjc_wdc_demand. The remaining 200 Mbps of traffic is from demands outside this demand grouping.
C_interface has 400 Mbps of traffic, of which 200 Mbps is from the sjc_hst_demand. The remaining 200 Mbps of traffic is from demands outside this demand grouping.
The calculation is as follows:
-
A_interface
-
A_interface can hold 900 Mbps of demand grouping traffic.
A_interface capacity – non-demand grouping traffic
1000 – 100 = 900
-
The amount of sjc_wdc_demand traffic that A_interface can hold is 540 Mbps.
Total available capacity for the demand grouping * (sjc_wdc_demand/total demand grouping traffic)
900* (300/500) = 540
-
The amount of sjc_hst_demand traffic that A_interface can hold is 360 Mbps.
Total available capacity for the demand grouping * (sjc_hst_demand/total demand grouping traffic)
900* (200/500) = 360
-
-
B_interface can hold 800 Mbps of sjc_wdc_demand traffic.
B_interface capacity – non-demand grouping traffic
1000 – 200 = 800
-
C_interface can hold 800 Mbps of sjc_hst_demand traffic.
C_interface capacity – non-demand grouping traffic
1000 – 200 = 800
-
The limiting interface is A_interface because it imposes the strictest limits in the demand grouping’s ability to deliver traffic. It supports only 360 Mbps of sjc_hst_demand traffic, whereas B_interface supports 800 Mbps of sjc_hst_demand traffic. Also, A_interface can support only 540 Mbps of sjc_wdc_demand traffic, whereas C_interface supports 800 Mbps of sjc_wdc_demand traffic.
-
The Capacity Bound is 900 Mbps. If the sum of the demands in the demand grouping becomes 900 Mbps, the utilization of A_interface (the limiting interface) will be 100%. This 900 Mbps is the total available capacity for the demand grouping based on the limiting interface.
A_interface capacity – non-demand grouping traffic
1000 – 100 = 900
-
The Capacity Violation is –400.
Total A_interface traffic permitted for the demand grouping – Capacity Bound
500 – 900 = –400