[j-nsp] UNEQ-P and LOP-P in same signal - mismatched concatenation info?

From: Martin, Christian (cmartin@gnilink.net)
Date: Thu Feb 01 2001 - 16:34:58 EST


Hello,

I have an OC-3c connection between two routers through a carrier. One end
is looped back toward the other end. On the receiving end facing the loop I
am receiving UNEQ-P and LOP-P. After perusing GR-253, I came across an
anecdote that indicates this scenario should not be possible. Roughly
paraphrased, GR-253 states that, during a LOP-P condition, the C2 byte is
inaccessible and thus, UNEQ-P and PLM cannot be monitored. My
interpretation of this is that because there is no valid pointer, the
beginning of the POH cannot be determined, and thus, the C2 byte cannot be
read. However, what if the first POH were accessible and the rest were not?
I.e., what if there was a misoptioning on the local ADM between concatenated
and non-concatenated mode?

Recall that we have this LOP-P condition. If I am to understand this
correctly, (it is loosely defined in GR-253, and not defined at all in ANSI
T1.105) a possible cause could be that there are too many successive NDFs or
that the PTE is expecting a concatenation indicator in the H1/H2 bytes for
STS-1 2 and 3; however, it is getting a real pointer value in the N bits (ie
0110.) In other words, would a PTE expecting concatenation indicators and
not getting the requisite N bits in the H1 byte generate a LOP-P condition?
If so, wouldn't it then still be able to read the C2 byte in the STS-c POH,
since there is only one POH column in the STS-3c SPE?

TIA,

chris



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT