Discrete services are increasing in

ASON network due to software bug

Publication Date:  2012-07-25 Views:  0 Downloads:  0 References:  0

Issue Description

In one of the customer, ASON services are going in to

discrete.Services were going in to discrete while performing trail

search operation after fiber restoration, when fiber cut are large in

network, accordingly discrete services are more and when fiber cut

are less in network, then discrete services are less. It is in relation

with the new provisioning of services.

Alarm Information

Services are going in to discrete, after fiber cut happened in

network.

Handling Process

Software is having defect which leads the problem. The same problem reported where 6 services were down

in which we found that upload was not successful and trail search operation performed .

Due to the ASON rerouting events, services were gone in to discrete.

 More discrete services are displayed in the discrete service

management window. This problem can be resolved by a trail search

and has no impact on services and this is the workaround solution.

 Need to check the problem, if problem description is clear then

check the version, and if it the same version, then need to upgrdae

the software.

Root Cause

During ASON trail creation, ASON cross-connections are created for

the client trail and common cross-connections are created for the

server trail.

On the live network, rerouting occurred on an ASON NE. Due to the

rerouting, new ASON cross-connections were generated for the

client trail and new common cross-connections were generated for

the server trail. After the new common cross-connections were

reported to the U2000, the U2000 added them these cross-

connections to NE, forming discrete cross-connections.

We checked from the NE logs, it shows that a large number of

rerouting events occurred, The rerouting events led to ASON trail re-

creation.

Services were divided into multiple layers when trails were being

created.
 The upper ODU1 trail (client trail) was generated on the local and

peer 52TOM boards.

The lower ODU2 trail (server trail) was generated on the local and

peer 52NQ2 boards.

The U2000 processed common cross-connections (ODU2) as new

cross-connections and displayed them as discrete cross-connections.

These cross-connections could form a trail and therefore would

disappear after a trail search.

Suggestions

Need to check the problem, if problem description is clear then

check the version, and if it the same version, then need to upgrdae

the software.

Old NMS version is : V100R002C01SPC100

Need to upgrdae to :V100R002C01SPC503

When rerouting of ASON trail is happened in the network,

accordingly trail management trail module system informs that a

switchover is completed. Then the module automatically

synchronizes trails and refreshes discrete cross-connections that are

generated during trail rerouting to complete trails in case that the

ASON trails become stable. Generally, it takes 6 to 15 minutes for

ASON trails to become stable and the default period is 10 minutes. If

new rerouting occurs  at the time when ASON trails are not stable,

the period required for ASON trails to become stable will be

increased. The trail management module automatically synchronizes

trails when no rerouting occurs again.

The period for ASON trails to become stable refers to a period in

which rerouting occurs for 2 to 3 times and information about ASON

trails is synchronized to gateways. After an ASON trail switchover is

performed, cross-connections are refreshed on all nodes of a trail,

new routes are used, and the U2000 begins to monitor alarms on

the routes. If no alarm is reported, the trail becomes stable.

However, sometimes rerouting alarms are generated when new

routes are used, which causes rerouting again. Currently, rerouting is

allowed for a maximum of three times. If rerouting occurs for more

than three times, network re-planning or capacity expansion is

required.

Switchover period: 1s (Generally a switchover is completed within 0.5

seconds.)
Reporting events to the U2000: If a large number of switchover

success events are reported to the U2000, the U2000 processes the

events with a delay of 0 to 2 minutes.

Reserved period for the U2000: 1 minute

Period for ASON trails to become stable = 2 x (120s + 60s) = 360s =

6 minutes

The U2000 V100R002C01SPC503 patch can resolve this issue.