The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
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.
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.
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:
|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|
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.
|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.|
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.
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.
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.
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.