[c-nsp] SPA-1XCHSTM1/OC3 SDH Software Implementation

[Rob Shakir]

Hi,

I'm currently involved in deploying a new platform for terminating a reasonable
number of E1s, which are delivered on N channelised STM-1 from Ericsson OMS1684
MUXes. We're terminating these STM-1s on 7609-S with SIP-200 and
SPA-1XCHSTM1/OC3, and seem to have come across a, somewhat surprising,
limitation of the software on these SPAs. I'd be interested to hear, on or
off-list, whether this limitation is affecting any other providers trying to use
these SPAs.

The limitation is that the SPA cannot parse VC-12 path overheads (the V5 byte of
the SDH path overheads) fully -- as far as I can tell, the only value that it is
able to parse is the VC-AIS signal (the signal label (bits 5, 6 and 7) in the V5
byte being set to 111). This means, that when a VC-12 is unequipped (signal
label = 000), the VC-12 is marked as up on the box.

For example, on this channel this VC-12 isn't equipped by the telco:

rtr# sh controller sonet 2/1/0.1/3/2/3 brief 

SONET 2/1/0 is up.
 Path mode C12

 AU-4 1, TUG-3 3, TUG-2 2, E1 3 (C-12 1/3/2/3) is up
  No alarms detected.
  Framing is unframed, Clock Source is Internal

This means that the mapped Serial interface looks like:

rtr#sh int ser2/1/0.1/3/2/3:0    
Serial2/1/0.1/3/2/3:0 is up, line protocol is down 
  Hardware is SPA-1XCHSTM1/OC3
  Description: :f=qt:
...

Being in an up/down state, and showing the VC-12 as up when there are alarms set
in the VC-12 POH seems to me to being completely invalid behaviour. We have
checked the state of the VC-12 POHs with an SDH analyser -- and verified that
the MUX is setting these correctly. This behaviour is causing us a number of
problems with both provisioning and administration of these circuits.

This problem is even more frustrating due to the fact that the PA-MC-STM-1SM
that we're using in a FlexWAN on another box is able to show LP-UNEQ alarms
correctly, and marks the VC-12 as down.

I've got SR 610067345, and CSCsw25088 tracking this problem --  but would be
very interested to hear whether this problem is affecting any other service
providers using this SPA.

Many thanks for any comments.

Cheers,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html