Synchronous Optical NETwork (SONET)

Document ID: 18932

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Background Information
Clocking Fundamentals
H1 and H2
How SONET Deals With Timing Problems
H3 Pointer Action Byte
Causes of Stuff Events
Are Some NSE/PSE Events Acceptable?
Contact Cisco TAC
Cisco Support Community - Featured Conversations
Related Information

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 .

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.

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:

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.

Cisco Support Community - Featured Conversations

Related Information

• Technical Support & Documentation - Cisco Systems