Troubleshooting PSE and NSE Events on POS Interfaces

Introduction

This document explains why the output of the show controller pos command on a Packet Over SONET (POS) interface can display a non-zero value for the Positive Stuff Event (PSE) and Negative Stuff Event (NSE) counters. The value continuously increases. These events increase when the POS link experiences clocking problems. Therefore, this document also covers clocking.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Here is a sample output of the show controller pos command, captured on a Cisco 12000 Series Internet Router:

   POS7/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 = 967        BIP(B3) = 26860037    
     LOP = 0         NEWPTR = 205113     PSE  = 295569        NSE     = 18 

Note: The NEWPTR error counter also can increase when NSE and PSE events increase.

Clocking Fundamentals

A simple view of a physical network link is that it defines a one-way transmission path from a sending device or transmitter to a receiving device or receiver. In other words:

• A source device communicates pulses of voltage or light waves to transmit a binary 1 or 0.

• A destination device receives a binary 1 or 0. For this, the receiving device measures the signal level on the physical wire at a specific rate (frequency) and at a specific time (phase).

Both devices use a clock in order to determine when to perform the task. Ideally, bits must arrive at the receiver in a very precise and concise manner. The receiver must know the exact time that a binary 1 or 0 manifests itself at the receiver interface. A transmitter and a receiver are perfectly synchronized when they are in phase and in frequency.

Accurate clocking becomes more important with high-speed interfaces like SONET because there is an inverse relationship between the number of bits on a physical link in a second and the length of time that a bit manifests itself at the receiver. For example, a SONET OC-3 interface can transmit 155,000,000 bits per second. Use this formula in order to calculate the time on the wire of each bit:

1 / 155000000 = .000000006 seconds

Compare this value with the time on the wire of a bit on a T1 link:

1 / 1544000 = .000000648 seconds or 648 microseconds

Therefore, if the receiver experiences even a slight inaccuracy in the timing of its sampling clock, it cannot detect a bit or even several bits in succession. This problem leads to clock slips, which are the loss of timing, and the resultant loss of the detection of bits. Clock slips can also result in an incorrect interpretation of the binary 1s and 0s, and therefore lead to parity and Cyclic Redundancy Check (CRC) errors.

Timing is not carried explicitly. Instead, a receiving interface derives the frequency and phase of the transmitting interface. For this, the receiving interface tracks the incoming signals and the transitions from 0 to 1 and 1 to 0.

H1 and H2

You first need to understand how SONET uses H1 and H2 bytes in the line overhead.

Each Synchronous Transport Signal (STS-1) consists of 810 bytes, which includes 27 bytes for the transport overhead and 783 bytes for the Synchronous Payload Envelope (SPE). The format of an STS-1 frame and the nine rows by 90 columns are illustrated in .

Figure 1 – The Format of an STS-1 Frame

The transport overhead section breaks down into section overhead and line overhead. The line overhead includes the H1 and H2 bytes. The SONET protocol uses these bytes to identify the position of the payload in the SPE portion of the frame. This table illustrates the location of the H1 and H2 bytes:

				Path Overhead
Section Overhead	A1 Framing	A2 Framing	A3 Framing	J1 Trace
	B1 BIP-8	E1 Orderwire	E1 User	B3 BIP-8
	D1 Data Com	D2 Data Com	D3 Data Com	C2 Signal Label
Line Overhead	H1 Pointer	H2 Pointer	H3 Pointer Action	G1 Path Status
	B2 BIP-8	K1	K2	F2 User Channel
	D4 Data Com	D5 Data Com	D5 Data Com	H4 Indicator
	D7 Data Com	D8 Data Com	D9 Data Com	Z3 Growth
	D10 Data Com	D11 Data Com	D12 Data Com	Z4 Growth
	S1/Z1 Sync Status/Growth	M0 or M1/Z2 REI-L Growth	E2 Orderwire	Z5 Tandem Connection

How SONET Deals With Timing Problems

While SONET networks exhibit very accurate timing, some variations are inevitable. Although the variation is very small, the small time on the wire of each bit necessitates strict timing accuracy.

Synchronous networks can use several methods in order to resolve timing problems. SONET networks use byte stuffing and pointer adjustments. Before you study these concepts, you first need to understand underflows and overflows.

Fundamentally, a network device accepts traffic on an input line, and writes it into a buffer based on the frequency of the incoming signal. A locally generated clock determines the read frequency of the bits from the buffer. The read rate determines when the contents of the frame (the binary 1s and 0s) are placed onto an output line.

Clock slips, and the resultant overflows and underflows, lead to PSE and NSE events within the network because a byte in the transmission stream is deleted or repeated. Fundamentally, clock slips indicate that the clock rate on the incoming interface is not synchronized somehow with the clock rate on the outgoing interface.

Problem	Condition	SONET Response
Write into buffer is performed faster than read from buffer.	Overflow	NSE—Move frame backward by one byte location.
Write into buffer is performed slower than read from buffer.	Underflow	PSE—Move frame forward by one byte location, add an artificial byte to compensate for failure of the writes.

H3 Pointer Action Byte

A need for bit-stuffing occurs when the buffer is empty at a time when a bit must be read. Stuff bits make up for a shortfall in the number of bits in a frame.

A PSE occurs on an Add/Drop Multiplexer (ADM) when the incoming signal runs slightly behind with respect to the clock of the outgoing interface where that data is cross connected. A PSE also occurs when the payload data rate is slow with respect to the STS frame rate. In these conditions, the byte position after the H3 byte is stuffed (skipped), and the pointer value in the H1 or H2 bytes is increased.

An NSE is precisely the opposite. When the input signal arrives too quickly with respect to the frequency of outgoing interfaces, the data is not buffered. Instead, the pointer value decreases by one, and the payload starts one byte position earlier. Specifically, one payload byte is placed in the H3 byte, also known as the Pointer Action Byte. Normally, this byte is empty.

Causes of Stuff Events

NSE and PSE events typically increase due to synchronization problems on a link or incorrect clock settings. These events also increase in these conditions:

• The received signal is very degraded, and the SONET framer on the router reports what appears to be NSE and PSE events because of the highly degraded signal.

• A back-to-back configuration uses internal - line, and there are sufficient differences in the accuracy of the oscillator at each end.

• The physical fiber is not sufficiently clean.

• The transmitter overdrives the remote receiver, and there is insufficient attenuation on the link.

• The link experiences an alarm or badly-errored condition. While the router clears this state, the router detects some valid NEWPTRs, and counts these incorrectly as NSEs or PSEs.

It is important to note that Cisco POS interfaces do not generate PSE or NSE counters because they send a fixed value in the H1 or H2 bytes. Cisco POS interfaces only report what they see from the cloud.

Are Some NSE/PSE Events Acceptable?

This table lists the maximum allowable NSE and PSE rates for different Stratum clock accuracy levels:

Clock	Maximum NSE and PSE Rate
Stratum 1	11.2 stuffs per day
Stratum 2	12.44 stuffs per minute
Stratum 3	59.6 stuffs per second
20 ppm	259 stuffs per second

These numbers assume absolute worst case, end-of-life specifications for the various clocks. They also assume that the two clocks are at opposite ends of their ranges (that is, one is at the maximum while the other is at the minimum), which is very unlikely in a production environment. Therefore, typical numbers in a real network must be one or two orders of magnitude less than these numbers.

Here are the PSE and NSE rates, if you assume the presence of two Telcos with independent Stratum clocks:

Stratum 1 accuracy =  +/- 1x10-11

Therefore, the worst-case offset between two Stratum 1 clocks is 2x10-11.

STS-1 rate = 51.84x10+6 bits/second

Worst-case offset between two STS-1s that run off independent Stratum 1 clocks is:

             (51.84x10+6) x (2x10-11) 
          =  103.68 x10-5  bits/second 
          =  (103.68/8) x 10-5  bytes/second 
          =  12.96 x 10-5  bytes/ second 

Each STS-1 pointer adjustment (or stuff) accommodates one byte of data. Therefore, the number is also the NSE or PSE rate. Thus, the maximum NSE or PSE rate when you assume the existence of Stratum 1 clocks is:

          = 12.96 x 10-5  stuffs per second 
          = (12.96x10-5) x (60x60x24) stuffs per day 
          = 11.2   stuffs per day 

Remember these points when you troubleshoot NSE and PSE events:

• The rate of PSE and NSE events must not increase with load.

• Cisco POS line cards generate a fixed pointer value of 522. Therefore, you must not see any PSE or NSE events when you connect two POS line cards back to back.

• Some NEWPTR events can be reported when an interface clears an alarm or during a badly-errored condition.

Contact Cisco TAC

When you open a case with the Cisco Technical Support for help to resolve the increase in the number of PSE and NSE events, please be prepared to provide this information:

• Whether the topology is back to back or across a SONET network of ADMs.

• Hardware platform and line card you use.

• Brief description of the history of the problem and any steps that you took to troubleshoot the problem.

• Output of the show tech command from the router that reports the events.

Related Information

• Technical Support & Documentation - Cisco Systems