Skip Headers
Oracle® Communications Network Intelligence Concepts
Release 7.2.2

E17891-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Understanding Services, Policies, and Rules

This chapter describes services, policies, and rules in Oracle Communications Network Intelligence.

About Services, Policies, and Rules

A service is a product offering delivered to a customer location through trails. Services are created using service definitions which are blueprints for creating services. Services can be grouped. Service topologies are used to model a collection of trails that comprise a multitrail (point) service. A service can also reference a policy.

A policy is a set of routing constraints, or rules, that are applied when looking for a path between two points in the network. For example, policies specify class of service, or quality of service constraints when looking for suitable network resources to satisfy service demand requirements on a service level agreement (SLA). A policy is set by a reference in the service definition for a particular service. In addition to containing rules, a policy can also contain other policies.

The relationship between services, service definitions, policies, and rules is outlined in the following diagram:

Figure 6-1 Relationships between Services, Service Definitions, Policies, and Rules

Description of Figure 6-1 follows
Description of "Figure 6-1 Relationships between Services, Service Definitions, Policies, and Rules"

About Services

The services tree browser displays all services and service definitions currently modeled in Network Intelligence.

Services are separated into predefined folders or groups for ease of navigation. Double-click the folder to expand the selection.

Creating Services and Service Definitions

Each service requires a service definition, so before creating a service, you must first create a service definition to associate with it. A service definition requires a name and connectivity type (for example, point to point, multipoint to multipoint, or rooted multipoint). You can optionally add a description of the service definition, and associate a policy with it.

A service is defined by name, status (for example, planned or testing) associated service definition, and assigned service group (for example, transport, 3G, 4G, or Ethernet). You can optionally add a description of the service.

Creating a Policy

If a service requires a trail that must be routed over carrying trails, you must assign a policy to the service definition to define routing constraint rules.

A policy holds rules that define the pathfinding criteria used to discover end to end trail connections when fulfilling a service.

A policy is defined by name and associated policy type:

  • Service: Used to create a policy for a service.

  • Network: Used to create a policy to be used by a specific network.

  • Service Demand: Used if a policy is created by a plan.

  • Exploratory: Used if a policy is intended for study purposes.

You can optionally add a description of the policy.

Assigning a Policy to a Service

You assign a policy to a service by editing the service definition, and selecting the required policy.

Adding a Rule to a Policy

A policy holds rules, or other policies. You can add rules to a policy by selecting one of the views associated with the policy and using the Rule Configuration wizard to select the rule type associated with the rule.

Complete the rule details by specifying a rule name and at least one service trail definition, and add enabling trail definitions, or routing trails for aggregation purposes as required.

Enabling trail definitions are trail definitions available for routing this service. All trails that match the trail definitions in the enabling trail definitions list are candidates for pathfinding unless they are ruled out by other policy rules. Aggregation is used to set concatenation rules for aggregated service demands. You can opt to display the rule in the policy and rule list view.

Note:

The order in which rules and policies appear in the table in the policy and rule list view defines the precedence of the rules (the order in which they are implemented.)

About the Service Trail Definitions Rule

The Service Trail Definition rule is an important rule when carrying out routing. The service trail definitions rule:

  • Specifies what signal structure (child channels, or trail holders) are built out if the trail is structured.

  • Specifies the capacity of the trails of the service.

  • Specifies the list of enabling trail definitions; these are the parent trail definitions that can carry a service of this type.

  • Enables you to find path solutions using Trail Routing Manager and Forecast Manager. You must explicitly add the Service Trail Definition rule to use these managers in Network Intelligence.

If the service you are creating does not require routing, you do not must add this rule in the policy. Service routing may not be required if:

  • You are routing entirely over a cloud network and you do not need to know the path.

  • You are creating a top level link trail and are not concerned about the parents.

  • You do not know, or do not have the network loaded to do the path routing at the time of service creation.

Adding a Policy to a Policy

You can add a policy to another policy to group common rules for routing use. For example, for a Metro Ethernet implementation, you might need a quality of service policy, QoS Policy, which is in turn responsible for the jitter and latency policies, Jitter Policy and Latency Policy, governing those constraints on the network.

Designing and Assigning a Service Demand

A service demand is a request from a customer for a particular service over a particular route (for example, Customer A requires a business data service between Site A4 and Site A5).

To design a service demand, you perform the following tasks:

Creating Trails to Define the Network Connectivity of a Service

A service requires trails to define its network connectivity. As with services and service definitions, each trail also requires a trail definition to define the type of trail to be built, principally whether the trail is structured or unstructured. If it is structured, a signal structure hierarchy can be defined.

To create trails, use the Trail Configuration wizard. See the Network Intelligence Help.

Using Trail Routing Manager to Determine Path Routing

When using the Trail Configuration wizard, use the trail routing step to find a path routing for the service between the specified sites.

This invokes Trail Routing Manager. See "Routing Trails" for information on trail routing.

Applying Policies and Rules to a Service

When using Trail Routing Manager, note the following options used to apply policies and rules to the service:

  • Click View Policy to view, or edit the policy created for the service.

  • Click Analyze to search for routed path solutions. Trail Routing Manager takes the service demand and applies its policy to look for available solution paths between Site A4 and Site A5.

Trail Routing Manager displays valid solutions for inspection.

Selecting a Solution Displayed by Trail Routing Manager

From the list of valid solutions displayed by Trail Routing Manager, you can choose one of the valid path routing options for the service trail.

See "Choosing the Routing Method" for information on selecting a routing solution.

Creating and Saving the New Service Trail

To create and save the new service trail, complete the trail details in the final step of the Trail Configuration wizard.

Select Parent Hierarchy View to check that the trail was created with the correct parent trails. The parent trails have trail definitions that match the policy rule that was set.

Using Routing Rules

A routing rule is a conditional constraint applied to Trail Routing Manager when looking for route solutions for a service demand. A policy is made up of routing rules.

Rules may be used; for example:

  • To limit the scope of a search to specific network elements, such as a particular network equipment provider, or particular topology;

  • To define requirements such as the maximum number of hops a solution completes, or the use of physical strapping to build out the network;

  • To generate costs associated with routing solutions.

Table 6-1 describes each rule and how it is used.

Table 6-1 Routing Rule Definitions and Default Values

Rule Type Rule Description

Service Trail Definitions rule

Used to define the trail definitions used for a service and the capacity required.

Specifies the enabling trail definitions for the service trail definitions.

Enables aggregation configurations.

See "About the Service Trail Definitions Rule".

Start Termination rule

Used to specify what type of start equipment, or card, or port, to use when looking for a path solution.

See "About the Termination Rules".

End Termination rule

Used to specify what type of end equipment, or card, or port, to use when looking for a path solution.

See "About the Termination Rules".

Limit rule

Used to limit the entities used in the routing solution.

See "About the Limit Rule".

Exclude rule

Used to exclude entities from routing solutions.

See "About the Exclude Rule".

Hub rule

Defines a list of entities, at least one of which must be a transiting part of the routing solution.

See "About the Hub Rule".

Use Internal Hub Hops rule

Used to allow the path solution to have at least one internal hop at any hub site.

See "About the Internal Hub Hops Rule".

Path Routing rule

Used to look for path routing.

See "About the Path Routing Rule".

Path Protection rule

Used to look for a set of protected paths. If set, all valid paths can be displayed.

See "About the Path Protection Rule".

Diversity Type rule

Used to find a unique set of diverse paths between the start and end sites in a routing solution.

The diversity may be for a trail (no two paths can share the same trail), or path (no two paths can contain the same set of trails end to end).

The Diversity Type rule is always set when path protection is required.

See "About the Diversity Type Rules".

Comparison Operator rules

Used to specify a constraint on a equipment or trail attribute.

See "About the Comparison Operator Rule".

Statistical rule

Used to specify a constraint rule on an trail or equipment attribute.

Statistical rules may be sum or average.

See "About the Statistical Rule".

Service Overbooking rule

Used to specify the allowed rate of overbooking for a given service allowed when using network resources.

This is used to model contention ratios and bandwidth reservation.

See "About the Service Overbooking Rule".

Physical Strapping rule

Used to specify whether physical strapping is permitted in the route solution, and optionally, specifies the maximum numbers of straps.

See "About the Physical Strapping Rule".

Topology Based Routing rule

Used to find path solutions using topologies rather than trails.

See "About the Topology Based Routing Rule".

Display Failure Solutions Last rule

Used to display failure solutions (if any) last on the list of solutions.

A failure solution is a solution that has one or more parent trails that do not have enough bandwidth for the service demand.

See "About the Display Failure Solutions Last Rule".

Consider Optimal Feasible Solution Only rule

Used to return the optimal solution that satisfies the service demand.

See "About the Consider Optimal Feasible Solution Only Rule".

Calculate Costs rule

Used to calculate costs to be included in solutions.

If Enable is not set, costs are not included, and default to zero.

This setting affects any comparison rules, statistical rules, and weightings that contain costs.

See "About the Calculate Costs Rule".

Maximum number of Solutions rule

Used to specify the maximum number of solutions to return.

See "About the Maximum Number of Solutions Rule".

Maximum Number of Possible Solutions During Processing rule

Used to set the number of potential path solutions before processing and sorting.

See "About the Maximum Number of Possible Solutions During Processing Rule".

Solution Search Timeout rule

Used to specify the time in milliseconds that the path analysis process looks for path solutions for the parent policy (service).

See "About the Solution Search Timeout Rule".

Maximum number of Equipment hops rule

Used to limit the number of equipment node hops used in the path solution process.

See "About the Maximum Number of Equipment Hops Rule".

Maximum number of Site hops rule

Used to limit the number of site hops used in the path solution process (a hop is a trail between two sites).

See "About the Maximum Number of Site Hops Rule".

Maximum number of internal hops end Site rule

Used to set the maximum number of hops allowed within the end site in a path solution.

This allows all of the different terminating equipment options (that result from having internal trails in the end site) to be considered by Trail Routing Manager.

See "About the Maximum Number of Internal Hops End Site Rule".

Maximum number of internal hops start Site rule

Used to set the maximum number of hops allowed within the start site.

This allows all different terminating equipment options (that result from having internal trails in the start site) to be considered by Trail Routing Manager.

See "About the Maximum Number of Internal Hops Start Site Rule".

Use Network Policies

Used to apply separate policies to individual networks.

See "About the Use Network Policies Rule".

Require Cross Connect Routing rule

Used when trail routing solutions on the network are required to take account of cross connects. You can eliminate service routing solutions that cannot be implemented in the network due to equipment constraints, thereby improving plan implementation success rates.

See "About the Require Cross Connect Routing Rule".


About the Service Trail Definitions Rule

The Service Trail Definitions rule is used to specify the parent trail definitions that are in scope for path routing. As it is mandatory for path routing, it must be created in order for routing to be carried out. If it is not set, the path analysis process cannot use any trails to determine an A to Z path solution.

You can select multiple trail definitions if the trail definitions selected have the same structure type (all of the trail definitions are either structured, or unstructured.) So, for example, you could use this rule to search only for solutions across 10Gb Ethernet links.

By selecting multiple trail definitions, you can create a single policy that covers all the different combinations of signal structure for a particular trail type (for example, a single VC-4 policy for all VC-4 trail definitions).

Defining Service Trail Definitions

The service trail definition specifies the type of trail created using the Trail Configuration wizard. For structured trails, this determines the signal structure (child trail holders).

All other fields on the rule creation window remain disabled until the service trail definitions have been selected.

The capacity is the capacity of the trail created, and normally defaults to the service trail definition capacity.

Defining the Capacity

You can also specify the capacity required for the service trails.

Defining Enabling Trail Definitions

The enabling trail definition section specifies the trail definitions that can carry this trail (the set of trails used as the search space in finding an A to Z path.) By default, a search returns the immediate parents of the service trail definitions.

All trails that match the definitions set here (and that are not excluded by any other rules) are used to look for paths.

You can edit the enabling trail definitions to add any ancestor of the service trail definitions, not just the immediate parents.

Note:

If you set an enabling trail definition, you cannot set an aggregation rule. If you set an aggregation rule, you cannot set an enabling trail definition.

Adding an Aggregation

Aggregation is used to model concatenation demands for paths that require virtual concatenation.

You can use add an aggregation to specify the trail definition to use for routing plus a quantity. You can select any trail definition for this trail definition, for example, routing a GigE circuit over SDH using VCAT would entail the following, as shown in Table 6-2.

Table 6-2 Using Aggregation In the Service Trail Definitions Rule

Trail Definition for Routing Quantity Enabling Trail Definitions

VC4 Path

7

Gigabit Ethernet (Gig E) Circuit


You can also specify the enabling trail definitions for the trail definition, and this list is pre-populated with the trail definition's immediate parent trail definitions.

You can add multiple aggregation configurations.

Note:

If you set an enabling trail definition, you cannot set an aggregation rule. If you set an aggregation rule, you cannot set an enabling trail definition.

About the Termination Rules

Termination rules are used to specify the equipment nodes or termination ports required for a service demand. For service demands that do not require end point terminations, this rule should not be set.

When you are looking for a path solution, the Start Termination Rule is used to specify what type of equipment, card, card technology, or port to use on the starting termination point of a solution. So, for example, you could use this rule to specify that the path solution must (start) terminate on the Cisco 10020 router type.

The End Termination Rule is used to specify what type of equipment, card, card technology, or port to use on the end termination point of a solution. So, for example, you can use this rule to specify that the path solution must (end) terminate on a 10Mb Ethernet port. You can specify the quantity of ports per port definition required to terminate a trail on (for example, five 2 MB ports for a 10 MB trail).

When you create a termination rule, the Rule Configuration wizard is displayed. On the Complete Rule Details window, set port exclusivity by selecting the Port Exclusivity check box. By turning port exclusivity on, only one trail may terminate on a port (a port is fully consumed if a trail terminates on the port.) Port exclusivity is turned on by default.

On the Complete Rule Details window, configure the rules listed in Table 6-3.

Table 6-3 Rules Used for Start and End Termination Rules

Rule Description

Port Definition

Specify the port definition type and number of ports.

If the Port Definition rule is set, only path solutions that start (or end) on equipment nodes that contain ports specified by this definition are presented.

Card

Specify individual cards for path termination. Search for cards (for example, by type, technology, or in service date).

When the search is complete, select the cards required. The search window remains open when the cards are displayed in the Complete Rule Details window.

If the Card rule is set, only solutions that start (or end) on the specified cards are presented.

Card Technology

Specify card technologies that start (or end) the path. All card technologies configured in Network Intelligence are displayed.

Use the Card Technology rule to restrict path solutions to start (or end) on equipment nodes that uses ports of a particular technology type (for example, a consumer broadband service uses a policy with an end termination rule that specifies DSLAM ports).

Equipment

Specify equipment nodes to terminate the path. Search for equipment nodes (for example, by site, name, type, or in service date). Use the search to select equipment nodes singly.

Define the percentage split for circuits terminating on this equipment (for example, specify 3 equipment nodes to start terminate a path, and assign the percentage split in the ratio 40:30:30).

Use the Equipment rule to restrict path solutions to a single vendor, or to a particular equipment type (for example, a service demand between a customer edge (CE) router and a core provider edge (PE) router). In this case, a start termination rule is used to specify the CE router allowed, and an end termination rule is used to specify the PE router allowed.


Note:

If termination rules are not set as part of the routing solution, no port data is displayed in the graphical solution view (the Consider Optimal Feasible Solutions Only rule must be set also).

See "About the Consider Optimal Feasible Solution Only Rule".

About the Limit Rule

When defining path routing, the Limit rule is used to refine the set of trails used in the path solution. So, for example, you could use this rule to specify that the solution must route over Node X, Node Y, and Node Z.

This is an exclusive list: routing solutions may only contain entities in the list and no other.

Table 6-4 lists Network Intelligence entities that can have limit rules assigned, and outlines how the limit rule is applied to each entity.

Table 6-4 Limit Rule Supported Entities

Entity Explanation

Trail

Select trails. The path solution must use the selected trails as the set of parent trails for path solution computation.

Equipment

Select equipment nodes and use only trails that reference these equipment nodes as their start equipment or end equipment.

Equipment Definition

Allow only path solutions that use equipment nodes that match the equipment definitions set in this limit rule.

External Source

Allow only trails that match this external source as the set of parent trails for path solution computation.

Site

Allow only path solutions that use parent trails that have a start and /or end site that match the sites set in this limit rule.

Topology

Allow only path solutions that contain parent trails that are part of the topologies specified in this limit rule.

Only topologies that have a behavior type of routable can be selected in this rule.

Network

Allow only path solutions that contain parent trails that reference equipment nodes that are part of networks specified in this limit rule.

Telecom Domain

Allow only trails that match the telecom domains set in this limit rule as the set of parent trails for path solution computation.


About the Exclude Rule

The Exclude rule defines a list of entities, whether equipment, networks, and so on, that are specifically excluded from routing solutions. So, for example, a network planner could exclude the equipment definition, Alcatel-Lucent 7750, because it is legacy equipment, and is being removed from the network.

If Migration Manager has been used to migrate a site, Remote Office from the network, it is displayed in the list of excluded entities in the Consolidated Rules and Weightings view for all applicable service demands. See "Managing Network Migrations".

Table 6-5 lists Network Intelligence entities that can have exclude rules assigned, and outlines how the exclude rule is applied to each entity.

Table 6-5 Exclude Rule Supported Entities

Entity Explanation

Trail

Select trails. The path solution must exclude the selected trails from path solution computation.

Equipment

Select equipment nodes and exclude trails that reference these equipment nodes as their start or end equipment nodes from the set of parent trails for path solution computation.

Equipment Definition

Exclude path solutions that use equipment nodes that match the equipment definitions set in this exclude rule.

External Source

Exclude trails that match this external source from the set of parent trails for path solution computation.

Site

Exclude path solutions that use parent trails that have a start and /or end site that match the sites set in this exclude rule.

Topology

Exclude path solutions that contain parent trails that are part of the topologies specified in this exclude rule.

Only topologies that have a behavior type of routable can be selected in this rule.

Network

Exclude path solutions that contain parent trails that reference equipment nodes that are part of networks specified in this exclude rule.

Telecom Domain

Exclude trails that match the telecom domains set in this limit rule from the set of parent trails for path solution computation. Telecom domains may be associated with a trail definition.


About the Hub Rule

The Hub rule is a filter rule that defines a list of entities, one of which at least must be a transiting part of a routing solution. So, for example, a hub rule is used to force a path solution to route through a particular entity such as the Chicago Central Office site.

Table 6-6 lists Network Intelligence entities that can have hub rules assigned, and outlines how the hub rule is applied to each entity.

Table 6-6 Hub Rule Supported Entities

Entity Explanation

Trail

Select trails. The path solution must use the selected trails as part of any routing solution.

Equipment

Select equipment nodes. The path solutions must contain the selected equipment as the hub equipment node in any solution.

Equipment Definition

Select equipment definitions. The path solutions must contain equipment nodes of the selected equipment definition as hub equipment nodes in any solution.

External Source

Select external sources. The equipment hub nodes must be tagged as coming from that external source.

Site

Select sites. The path solution must contain the selected site as a hub node.

Topology

Select one of more topologies. The path solutions must contain only hub equipment nodes belonging to the selected topologies.

Only topologies that have a behavior type of routable can be selected in this rule.

Network

Select one of more networks. The path solutions must contain only hub equipment nodes belonging to the selected networks.

Telecom Domain

Select one of more telecom domains. The path solutions must contain only hub equipment nodes belonging to the selected telecom domains.


About the Internal Hub Hops Rule

When looking for a viable end to end path, a connection may be required between two equipment at a hub site. The Use Internal Hub Hops rule enables routing paths to have at least one internal hop at any hub site (for example, a one hop connection between edge and core collocated equipment in the same central office).

The use of the Use Internal Hub Hops rule should be moderated; in general, it is not considered good practice to allow more than two internal hub hops at a hub site because it is wasteful of hub resources.

Start and end sites are not considered hub sites. Use the Maximum Number of Internal Hops Start/End Site rules to create multiple internal hops for these sites. See:

About the Path Routing Rule

The Path Routing rule is used to enable path routing to be carried out. By default, this rule is enabled in every policy unless it is specifically added to a policy and the Enable check box set to false. If it is set to false, no path routing is required, and solutions are returned without paths.Use the Path Routing rule, for example, to verify port availability between two node points where routing is cloud based, or not known.

About the Path Protection Rule

The Path Protection rule is used to look for a set of protected paths. It forces the path analysis process to look for two paths for each service demand quantity. If this rule is set, all valid paths can be displayed.

This rule must be used with the Diversity Type rule so that the path analysis process uses the required diversity criteria to use when selecting path pairs.

See "About the Diversity Type Rules".

About the Diversity Type Rules

Diversity type rules are used to find a unique set of diverse paths between the start and end sites of a routing solution; diverse means not sharing the same resources. For example, trail diversity means that no two paths can share the same trail; path diversity means that no two paths can contain the same set of trails end to end. The diversity type rule is always set when path protection is required.

Diversity rules are used as follows:

  • All: This is full diversity: a pair of circuits are routed so that no path shares the same hub site, node, or trail with another other path solution.

  • Not Required: No diversity is set. This is typically used to deactivate a diversity rule in a subpolicy. This is the default.

  • Path: This is path diversity: a pair of circuits are routed so that no path shares a link with the same terminating equipment. No solution can share the same path (exact combination of trail hops) with any other solution.

  • Trail: This is trail diversity: a pair of circuits are routed so that no path shares the same trail with another path. No solution can share the same trail in any equipment to equipment node hops with any other solution.

The Diversity Type rule is generally used to find protection paths that are resource diverse; you can plan or analyze load balance scenarios where there is a requirement to split customer services over two or more service platform nodes.

Note:

Diversity as it is applied in Network Intelligence does not check hierarchical parent path resources to find a common fibre or cable, for example.

About the Comparison Operator Rule

The Comparison Operator rule is used to set a comparison rule on a trail or equipment node attribute. A comparator and a value are applied to all trails and equipment that have the attribute (for example, the number of free ports on an equipment node is set to 2). The rule is used on trail or equipment attributes to enforce constraints for path computation. Select the Mandatory check box to force all resources to use the constraint, or else be excluded from path computation. The Comparison Operator rule is typically used when creating a policy rule to make all link attributes the same (for example, all links must have latency of less than 10).

You must select whether the attribute is mandatory (only entities that have this attribute, and satisfy the rule, may be used in a solution.) If the attribute is not mandatory, then this rule passes for entities that do not have the attribute.

Table 6-7 shows the trail or equipment node attributes used with the Comparison Operator rule.

Table 6-7 Trail or Equipment Node Attributes Used with the Comparison Operator Rule

Attribute Type Parent Entity Type Explanation

Exhaustion Date

Date

Trail

Date when the entity is predicted to have exhausted its capacity.

External Status

External Status

Trail

Status of the trail as set in external data source.

In Service Date

Date

Equipment, Trail

The date on which the entity went into service.

Km Length

Double

Trail

The A-Z distance of the trail (in miles or kilometers).

Number of Free Ports

Double

Equipment

The number of ports with no service association.

Number of In Service Ports

Double

Equipment

The number of ports with status set to In Service.

Number of Planned Ports

Double

Equipment

The number of ports with status set to Planned.

Out Service Date

Date

Equipment, Trail

The date on which the entity goes out of service.

Reserved

Boolean

Trail

The reserved flag set on the trail.

Status

Status

Equipment, Trail

The status of the entity (In Service, Planned)

Total Ports

Double

Equipment

The total number of ports associated with the equipment.

Trail Protection

Short Text

Trail

The trail protection status. Valid values are Protected, Protection, Unprotected.


About the Operators

The following operators are supported for numeric attributes:

  • =

  • !=

  • >

  • <

  • =>

  • <=

If the attribute is non-numeric, the following operators are supported:

  • =

  • !=

About the Statistical Rule

The Statistical rule is used to specify a constraint rule on a trail or equipment attribute. The attribute may be a system attribute (for example, Trail. Capacity) or a custom attribute created by a user (for example, Trail.MyAttribute).

This rule applies only to numeric attributes; select a numeric attribute from a list containing all of the numeric extensible attributes.

You select an attribute, an operator and a type, to be applied to the attribute across the entire solution.

Table 6-8 shows the Statistical rule components.

Table 6-8 Statistical Rule Components

Component Description

Attribute

The attribute that the rule operates against.

Operator

The following operators are supported:

  • =

  • !=

  • >

  • <

  • =>

  • <=

Type

The type can be either Sum or Average:

  • Sum: sums all attribute values for each trail or equipment in the path solution.

  • Average: takes the average value of all attribute values for each trail or equipment in the path solution.


Select whether the attribute is mandatory (only entities that have this attribute, and satisfy the rule, may be used in a solution.) If the attribute is not mandatory, specify a default for the attribute to be used in the calculation.

About the Service Overbooking Rule

The Service Overbooking rule is used to model contention ratios for a service.

In traditional circuit switched services (for example, transport links) dedicated private line resources are normally dedicated for exclusive use by the service. For packet based networks, it is normal to share single resources between multiple services and overbook the resource to a degree. Overbooking occurs because not all customers require the service at the same time, and accept a reduced service if it complies with the minimum agreed service specified in the service contract.

The Service Overbooking rule enables an overbooking ratio to be set for a given service. This overbooking ratio is then applied to all port and link bandwidth resources in path computation. For example, a trail holds 10 services of type Silver Home Data. By setting the Over Booking Rate value in the Service Overbooking rule in the Silver Home Data policy to 2, the trail can now carry 20 (2 times 10) of these services.

This rule is enabled only when the trail definition required is not structured. You specify a float value such that underbooking may also be supported. You cannot enter zero, or a negative number.

About the Physical Strapping Rule

This rule is used if you consider path solutions that could be enabled using hub site equipment to equipment node tie cable or strap connections. These are physical solutions suggested by Network Intelligence that may provide an easier of cheaper solution. Physical strapping can be useful in determining paths at the higher layers of the network which must often be manually configured by connecting nodes (for example, when looking for a path transiting through a busy central office).

To use this rule, select the Enable check box, and enter a strap count value in the Value field. If a path solution is found using physical strapping, the connection between nodes is denoted using a strap icon.

Path solutions with strapping require a truck roll to a hub site to provide a card insertion, card upgrade, or physical tie cable connection to be created.

Note:

Physical strapping is sometimes referred to as ”air-gap routing”.

About the Display Failure Solutions Last Rule

This rule is used to display path routing solutions that currently fail, but that would pass if the bandwidth provided on parent trails was upgraded to follow the service demand set. If this rule is applied, failure solutions (regardless of hop size) are presented after valid solutions. A failure solution is displayed in red (the graphical link rectangle which is normally gray is displayed in red.)

Note:

If the Consider Optimal Feasible Solutions Only rule is applied and enabled, no failure solutions are ever presented. Therefore, under these conditions, the Display Failure Solutions Last Rule does not work.

About the Topology Based Routing Rule

In a very large network, it is not very efficient to use trails as the main basis for route computation. Topology based routing may be a better option as it should produce solutions more quickly. Using topology based routing, paths are computed within a topology, and then connection paths are sought to another topology to complete the next hop of the solution. Topology based routing works only if topologies with valid nodes and links are modeled. It is useful for enforcing service provider policies for routing governance, such as stipulating that a path cannot route across more than 3 topologies, or that path solutions must avoid solutions that do not link through a topology.

This rule enables Trail Routing Manager to use topologies to constrain the search. Each topology is entered once in a routing search (there is no backtracking.)In addition, common neighbors are also not allowed to be traversed.

Note:

On some occasions, solutions may not be found, but it is unlikely that these are the solutions required.

You can allow the common neighbor search to be turned off. The default is to exclude common neighbors.You can allow the route solution paths to follow topology paths. The default is Off.

About the Consider Optimal Feasible Solution Only Rule

When this rule is set to On, Trail Routing Manager considers resource availability when looking for a solution, and returns the optimal solution that satisfies the service demand. If this rule is not included in the policy, it is still considered to be set and enabled.

When this rule is set to Off, Trail Routing Manager returns all possible solutions, irrespective of resource availability, up to the number specified in the Maximum number of Solutions rule (see "About the Maximum Number of Solutions Rule").

This rule is always set to On when using Plan Routing Manager.

About the Calculate Costs Rule

The Calculate Costs rule is used to display financial costing for each parent link presented in a path solution. Two types of cost can be applied:

  • Instance costs against trails (defined in the TRAIL_COST table in the database). For example, the monthly recurring cost for a leased link.

  • Task costs associated with definitions or metadata (for example, a unit cost per unit of bandwidth consumed on a parent trail type).

You can load costs from a data source, or create them using the Network Intelligence user interface (for example, create a cost based on link bandwidth consumption for a trail holder). Every time a path solution with X parents is found, the child service consumes X trail holders, and the cost is incurred per unit.

Creating Costs

You can create costs by selecting Administration from the top level menu, and then selecting Costing.

The following cost options are provided:

  • Select from:

    • Maintain Connection Build Tasks

    • Maintain Port Build Tasks

    • Maintain Timeslot Build Tasks

    • Maintain Card Build Tasks

    • Maintain Equipment Build Tasks

    • Maintain Trail Build Tasks

    • Maintain Site Build Tasks

    • Maintain Topology Build Tasks

    • Maintain Trail Costs

    • Maintain Labour Costs

    • Maintain Equipment Costs

  • Select the required build tasks from the table. Using the example above, select Maintain Timeslot Build Tasks. Build tasks are defined by name and cost, and other attributes such as capacity, service, supplier, and so on.

  • Complete the cost creation.

See the Network Intelligence Help for further information on creating costs.

About the Maximum Number of Solutions Rule

The Maximum number of Solutions rule specifies the number of solutions to postprocess and display in the Trail Routing Manager user interface; it is configured during the implementation if required, and defaults to 2000 solutions.

Tip:

The Maximum number of Solutions rule is an advanced rule. It should only be set by expert users.

About the Maximum Number of Possible Solutions During Processing Rule

The Maximum Number of Possible Solutions During Processing rule defines the maximum number of possible path solutions to store before stopping the search for path solutions; it is configured during the implementation if required, and defaults to 20000 solutions.

Tip:

The Maximum Number of Possible Solutions During Processing rule is an advanced rule. It should only be set by expert users.

About the Solution Search Timeout Rule

The Solution Search Timeout rule specifies the time in milliseconds that the path analysis process looks for path solutions for the parent policy (service); it is used for forecast planning to ensure that no single service demand takes too long, delaying the overall service demand set. Enter the timeout value in the Value field. If it is not set, it defaults to 2000 ms.

Tip:

The Solution Search Timeout rule is an advanced rule. It should only be set by expert users.

About the Maximum Number of Equipment Hops Rule

The Maximum Number of Equipment Hops rule is used to limit the number of equipment node hops (trail connections between two equipment nodes) that the path solution set uses. For example, when specifying a service for optical transport, set this value to 5 equipment node hops to maintain reliability and maximize resource optimization.

The hop rule is used to limit path solutions from having too many hops as each hop in a solution is another potential point of failure; order by shortest path (OSPF) is the preferred methodology for path computation as a path the least hops consumes fewer link and node resources.

The Maximum number of Equipment Hops rule has a default value of 5 if no rule is set; the rule is always applied regardless of whether it is set in the policy. To set path solutions with more than 5 equipment hops, add the rules to the policy and set the values to be greater than 5.

Use the Maximum Number of Equipment Hops rule with the The Maximum Number of Site Hops rule to be effective. See "About the Maximum Number of Site Hops Rule".

About the Maximum Number of Site Hops Rule

The Maximum number of Site Hops rule is used to set a limit on the number of site hops (trail connections between two sites) that the path solution set uses.

The number of site hops can never be greater than the number of equipment hops; they are equal in number if every equipment node resides in a separate site. The number of site hops is fewer than the number of equipment hops if equipment nodes reside in the same site.

The Maximum number of Site Hops rule has a default value of 5 if no rule is set; the rule is always applied regardless of whether it is set in the policy. To set path solutions with more than 5 site hops, add the rules to the policy and set the values to be greater than 5.

Use the Maximum Number of Site Hops rule with the The Maximum Number of Equipment Hops rule to be effective. See "About the Maximum Number of Equipment Hops Rule".

About the Maximum Number of Internal Hops End Site Rule

This rule is set if you require internal equipment node to equipment node hops at the end site of the service demand (for example, if the path solution requires connection from an aggregation node to a service platform node within the same central office).

About the Maximum Number of Internal Hops Start Site Rule

This rule is set if you require internal equipment node to equipment node hops at the start site of the service demand (for example, if the path solution requires connection from an aggregation node to a service platform node within the same central office).

About the Use Network Policies Rule

The Use Network Policies rule is set for each network if you require a different policy to be applied in each network for end to end path computation. During path routing analysis, if a path enters a network associated with a policy, the network policy overrides the policy set by the service demand. Use this rule if the path routing for the service demand requires separate rule constraints within a network. A policy must be created for network entities that are in scope and the Use Network Policies rule must also be set in the policy.

For example, consider an SDH path that requires protection in the access network, but none within the core network. You can configure the Use Network Policies rule to set a different policy for each network, and that policy is applied for the route segments that traverse each network.

About the Require Cross Connect Routing Rule

The Require Cross Connect Routing rule is set for a network in which cross connects within the constituent equipment exist. A network equipment may have internal connectivity, specifically cross connects, from the ingress port through internal cards (if present), to the egress port. A cross connect is a connection between two logical or physical ports within an equipment. To say that one port is cross connected to another port means that these ports are somehow ”wired” together (either physically, or by using software).

By setting this rule, you can explicitly eliminate service routing solutions that cannot be implemented in the network due to equipment constraints, thereby improving plan implementation success rates.

The Require Cross Connect for Traversal option specified on an equipment definition for an equipment is only used by Trail Routing Manager when the Require Cross Connects Routing rule is enabled for the service being routed. In other words, only equipment that have this option enabled use this rule during trail routing. See the Network Intelligence Help for more information on creating an equipment definition.

Assigning Precedence to Rules

If multiple rules of a particular type are assigned to a policy, the rule precedence is that the rule nearest the top of the list is executed first. You can change the order in which the rules are executed by using the up and down arrows at the bottom of the Policy and Rule List window.

About Weightings

Weightings are used in Network Intelligence to assign relative importance to the particular attributes of a constraint. Among the supported attributes are: fill, kilometer length, sequence number, total fixed costs, total number of equipment hops, total number of internal hops, total number of site hops, total number of straps, total recurring costs, jitter, maximum delay, and any extensible attributes that have been created in Network Intelligence.

Creating a Weighting

To create a weighting, you define the attribute. Among the supported attributes are: fill, kilometer length, sequence number, total fixed costs, total number of equipment hops, total number of internal hops, total number of site hops, total number of straps, total recurring costs, jitter, maximum delay, and any extensible attributes that have been created in Network Intelligence.

The weighting is added to the Weightings table. Double-click the weighting to edit it.

Extensible attributes exist only if they have been created as custom attributes as part of a telecom domain, or during implementation (for example, when creating an equipment).

Select the attribute type: double or integer. Associate an entity with the attribute (for example, EQUIPMENT, EQUIPMENT and TRAIL, ROUTE_SOLUTION, or TRAIL). Assign best and worst values to the constraint. Specify how the weighting is calculated (summed or averaged) and use the slider to set the relative weight.

See Network Intelligence Developer's Guide for further information on creating and configuring extensible attributes.

About Associations

From the policy, you can view and select the following entities defined by name and association type:

  • Associated Service Definitions

  • Associated Service Demands

  • Associated Networks

See the Network Intelligence Help for more information on viewing, editing, or deleting associations.