Understanding the Path Trace Byte (J1) on POS Interfaces

Introduction

This document explains how Packet over SONET (POS) interfaces on Cisco routers use the J1 byte in the SONET Path OverHead (POH) column to communicate information about the remote Path Terminating Equipment (PTE). The information contained in the J1 byte is displayed as the Path Trace Buffer (PTB) in the output of the show controller pos detail command.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

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

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

What Is the J1 Byte?

The ITU-T G.707 standard defines the Synchronous Digital Hierarchy (SDH), which is widely deployed in Europe. The Bellcore/Telcordia GR-253 standard defines Synchronous Optical Networks (SONETs). Although these two standards are not the same, they do work in a similar way. SDH and SONET use a layered architecture of Path, Line, and Section Overhead (POH, LOH, and SOH). The POH column includes the J1 ( Path Trace) byte, also known as the PTB (Path Trace Buffer). The major difference between SONET an SDH is the size at which this architecture is implemented. In SONET, this takes places at the basic rate of 51.54 Mbps called an STS1. In SDH, this architecture starts a rate of 155.52 Mbps called a STM-1. This is three times the STS1, and equal to an STS3c in SONET.

The ITU-T G.707 standard and GR-253 standard describe the format of the J1 byte and suggest that the byte be used to communicate device ID information. This fixed-length string of 64-bytes transmits from the equipment the SDH or SONET signal originates from all the way through to the equipment terminating the SDH or SONET signal. It is considered to be user-programmable. This repeating ID information is used by the receiving equipment to verify its continued connection to the intended transmitter. Cisco follows the 64-byte format specified in the standards and communicates the remote hostname, interface name/number, and IP address in the J1 byte. Issue the show controller pos detail command to view these values.

gsr12-1#show controller pos 5/0
 POS5/0 
 SECTION 
   LOF = 4      25782 
 PATH 
   AIS = 0          RDI    = 0          FEBE = 3545       BIP(B3) = 380 
   LOP = 1          NEWPTR = 0          PSE  = 0          NSE     = 0 

 Active Defects: None 
 Active Alarms:  None 
 Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA 

 Framing: SONET 
 APS 

   COAPS = 51         PSBF = 1 
   State: PSBF_state = False 
   ais_shut = FALSE 
   Rx(K1/K2): 00/00  S1S0 = 00, C2 = CF 
   Remote aps status (none); Reflected local aps status (none) 
 CLOCK RECOVERY 
   RDOOL = 0 
   State: RDOOL_state = False 
PATH TRACE BUFFER : STABLE 
   Remote hostname : change 
   Remote interface: POS0/0 
   Remote IP addr  : 3.1.1.2 
   Remote Rx(K1/K2): 00/00  Tx(K1/K2): 00/00 

 BER thresholds:  SF = 10e-3  SD = 10e-6 
 TCA thresholds:  B1 = 10e-6  B2 = 10e-6  B3 = 10e-6 

Updating the Transmitted PTB Information

The PTB information is always carried in the J1 bytes of a SONET frame. Originally, Cisco POS interfaces transmitted new and updated PTB values when the interface was reset or the microcode was reloaded with the shut and no shut commands. In addition, executing the no shut command before configuring an IP address and hostname led to an advertised PTB value of all zeroes.

POS interfaces on the 7200 and 7500 series now send PTB information on a periodic interval. A similar change is implemented on the Cisco 12000 Series as of Cisco IOS Release 12.0(21)S. As a workaround, after changing the hostname or IP address of a GSR POS interface, bounce the interface to update the outgoing path trace message.

Seeing the Local Interface Information

When a router populates the PTB fields with information on the local interface, there is a problem with the POS link. Issue commands such as show cdp neighbor and show ip ospf neighbor to determine whether other protocols can see the remote information. Valid neighbor information via these commands points to a problem with the POS interface correctly updating the PTB information.

J1 Byte and SDH

The ITU-T's G.707 standard defines a second format that is used with Synchronous Digital Hierarchy (SDH). The standard defines the use of this byte as follows:

"This byte is used to transmit repetitively a Path Access Point Identifier so that a path receiving terminal can verify its continued connection to the intended transmitter. A 16-byte frame is defined for the transmission of an Access Point Identifier. This 16-byte frame is identical to the 16-byte frame defined in 9.2.2.2 for the description of the byte J0. At international boundaries, or at the boundaries between the networks of different operators, the format defined in clause 3/G.831 shall be used unless otherwise mutually agreed by the operators providing the transport. Within a national network or within the domain of a single operator, this Path Access Point Identifier may use a 64-byte frame."

POS interfaces on the Cisco 12000 Series interoperate with SDH ADMs using 64-byte J1 format and do not currently support 16-byte format. POS line cards perform path-layer termination on the POS interface itself. Since non-PTE nodes ignore and transparently relay the J1 byte, the intermediate SDH equipment can support the 64-byte J1 string of POS cards simply by "not interfering". However, if you require an SDH ADM to terminate the path and analyze the J1 string, you have no guarantee that the 64-byte format will be supported, since it is an optional format only, as per G.707.

J1 Byte Additional Functions

The ITU-T G.707 standard defines the SDH, which is widely deployed in Europe. G.707 defines the J1 byte as the first byte in the Virtual Container; its location is indicated by the associated AU-n (n = 3, 4) or TU-3 pointer.

The GR-253 standard defines Synchronous Optical Networks (SONETs). It still uses the J1 byte as the first byte of the Synchronous Payload Envelop (SPE) (this term is different from the Virtual Container (VC) but it still represents the End to End transmitted payload and POH). As this payload is transmitted from device to device, the additional LOH and SOH are added and subtracted. The location of the J1 byte must be tracked and preserved through all of this. This is done using pointer bytes H1 H2 and H3, as done in SDH with the AU-3 AU-4 or TU-3 pointers.

Related Information

• Optical Technology Support Pages
• Technical Support - Cisco Systems