No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

J1 Path Trace Operational Considerations

Publication Date:  2012-07-24 Views:  46 Downloads:  0
Issue Description
The configuration and processing of the J1 path trace feature, especially when Ethernet services are involved, show certain peculiarities which are worth to study and compile. This piece of work has been developed using lab scenarios with the following SW versions:
T2000V2R2C01B01H
OSN1500&OSN3500 V1R3C02B030SP04 & V1R2C02B018SP01
It gathers configuration hints, results interpretation, potential issues and workarounds from an empirical perspective. 
      
Alarm Information
HP-TIM
Handling Process
J1 Path Trace Operational Considerations
1.- J1 default operation mode = 3 � Single byte.
2.- J1/J2 path trace default configuration varies from one SW version to another. It causes path trace mismatch without further configuration. For instance: 
- V1R2C02B018SP01: J1 Tx&Rx&expectedRx = 01H
- V1R3C02B030SP04: J1 Tx&Rx&expectedRx = 00H
- Both J1 values are reported in decimal representation as a  ‘□’.
3.- J0/J1/J2 bytes reception and expected reception values must coincide in all bytes configured (1, 16 or 64 bytes). It happens that T2000 and Navigator do not display the blanks when configured in text mode. It may cause that the Jx bytes contents appear to match but the TIM alarm is present. For instance: 
- Reception = “A to B          ” and expected reception = “A to B” ? TIM alarm present while 
- Displayed reception = “A to B” and displayed expected reception = “A to B”
4.- Hexadecimal configuration is not supported on Navigator (only decimal). It implies that J1 byte configured with hexadecimal values using T2000 will not be correctly reported querying from Navigator. For instance, 00H and 01H will be reported as a ‘□’.
5.- Navigator allows the setting of the transmitting J1 byte at the line board when VC4 terminated in an EGT2 board while T2000 (V2R2C01B01H) does not. That goes against the overhead monitoring function expected from the line board in such circumstances.
6.- J1 transmission configuration at EGT2 is not considered in reception (neither EGT2 or  line board). J1 transmission configuration at line board is considered in reception (both EGT2 and line board). In this case:
- SCC SW version V1R2C02B018SP01: HP_TIM alarm clears in the line board when correctly configured but it does not in the EGT2 board.
- SCC SW version V1R3C02B030SP04: HP_TIM alarm clears in both,  the line board and the EGT2 board, when correctly configured.
7.- J1 multiframe mode ‘0’ - SDH mode (The bit7 of the first and only the first byte of the J1 byte sequence is 1) � not allowed. T2000 does not include it in the configuration menu; Navigator allows mode value but it results in error message.
8.- NE keeps memory of the J1 configuration after deleting crossconnections or trails (VC4 path deletion). Establishing a new path with any former VC4 termination point, the J1 configuration of that point will inherit the old configuration causing a J1 bytes mismatch by default. 
Root Cause
Please see attached .ppt file.
Suggestions
Compilation of Operational Consideration related to the configuration and processing of the J1 byte.

END