RE: PoS NEWPTR and NSE PSE Errors

From: Martin, Christian (cmartin@gnilink.net)
Date: Mon Aug 13 2001 - 12:34:33 EDT


NSE/PSE (Negative/Positive Stuff Events) indicate that at some point along
the path, the payload on the STS3c was shifted to adjust for a timing
differences on the lower speed (OC-3) tributary and the higher-speed
(OC12-192) path. A NSE occurs when the incoming bitrate on the tributary is
too high for the read clock (the clock that reads data from an inbound
tributary to place the bitstream on the higher speed path) to process the
previous byte before the write clock fills the write buffer with the inbound
stream. Thus, it stuffs last byte received into a reserved position in the
LOH for negative stuffs, and adjusts the pointer values to reflect the the
change in position of the beginning of the SPE. The opposite is true if the
data is coming in to slow. It inserts dummy bits into the higher stream to
account for the "missing" bits because the inbound stream was too slow. To
summarize:

1) The LOH for each STS-3c contains two bytes (H1 & H2) that define the
location of the beginning of the SPE (the payload and the path overhead).
The first 4 bits in H1 are the New Data Flag bits and are used to detect a
malformed pointer value or an invalid pointer operation. Bits 5 and 6 are
reserved and set to 0. Bits 7-15 define the pointer value, which is any
number between 0 and 782. Note that the for concatenated signals, the
pointer vlaue is multiplied by the number of STS-1s concatenated (IE STS-3c,
12c, 48c, 192c, etc). This allows for 10 bit pointer values to be able to
address thousands of byte positions in the SONET frame. Finally, 5 bits of
the 10 are defined as decrement bits, and 5 as increment bits, in an
alternating fashion as such:

IDIDIDIDID

2) Under nominal operation, the payload (SPE) is somewhere offset from the
end of the LOH. The number of bytes offset from the H3 byte is the pointer
value.

3) If the incoming rate is too slow, n dummy bytes must be stuffed into the
STS-3n. In your case, it is an STS-3c and thus, three dummy bytes are
stuffed following the last of the three H3 bytes in the LOH. Remember,
STS-3c operates just like STS1 except times everything by three. As such,
the LTE inverts the I bits from their previous value to indicate a positive
stuff shall occur in the next frame. Then, the new pointer value is sent,
incremented by one. No change in this value can occur for the next three
frame. Any such change is regarded as a pointer violation and an LOP
condition is set.

4) If the rate comes in to the multiplexing equipment too fast, 3 bytes from
the STS-3c must be stuffed into the three H3 bytes in the LOH, and the
pointer value must be decremented by one. But first, the D bits are
inverted to indicate a negative stuff event is occurring. Then, the pointer
is adjusted, the D bits inverted back (inversion meands flip from 0 to 1 and
vice versa), and the pointer vlaue is decremented. Again, no change may
occur for three consecutive frames.

5) Finally, if there is any reason for the pointer value to change other
than for positive or negative stuff, the new pointer must be sent with the
NDF bits set to 1001. Again, this value cannot change for three consecutive
frames.

What you are seeing is a timing problem. If the routers are back-to-back,
set the clock source to internal on both of them. This sounds odd, but
there is a problem in the POS chipsets on PA-POS-OC3 cards such that this is
the only stable method. If they are through and ADM, check that your
carrier has the circuit optioned properly.

Regards,
chris

> -----Original Message-----
> From: Joseph Ezerski [mailto:jezerski@broadcom.com]
> Sent: Monday, August 13, 2001 10:47 AM
> To: cisco-nsp@puck.nether.net
> Subject: PoS NEWPTR and NSE PSE Errors
>
>
> To anyone that can help shed some light:
>
> We have an OC-3 between two of our sites. Using the Cisco
> FlexWAN card and
> an OC-3 POS module, we are seeing NSE and PSE incrementing
> very rapidly,
> along with NEWPTRs. I am not sure this is dark fiber. We
> are leasing it
> from Cox Communications. I would assume the carrier would provide the
> clocking, hence this link being set to "clock source : line"
> on both sides.
> I am a complete SONET beginner, so anything helps.
>
> POS9/0/0
> SECTION
> LOF = 0 LOS = 0 BIP(B1) = 0
> LINE
> AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 0
> PATH
> AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 0
> PLM = 0 UNEQ = 0
> LOP = 0 NEWPTR = 42637 PSE = 61435 NSE = 0
>
> Active Defects: None
> Active Alarms: None
> Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA
>
> APS
> COAPS = 0 PSBF = 0
> State: PSBF_state = False
> Rx(K1/K2): FF/FF Tx(K1/K2): 00/00
> S1S0 = 00, C2 = CF
> CLOCK RECOVERY
> RDOOL = 0
> State: RDOOL_state = False
> PATH TRACE BUFFER: STABLE
> Remote hostname : abc
> Remote interface: POS9/0/0
> Remote IP addr : x.x.x.x
> Remote Rx(K1/K2): 01/16 Tx(K1/K2): 00/00
>
> BER thresholds: SF = 10e-3 SD = 10e-6
> TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6
>
> Clock source: line
>
> **********************
> Joseph Ezerski
> Network Engineer
> Broadcom Corporation
> jezerski@broadcom.com
> **********************
>



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:49 EDT