RE: Path Status (G1) latching
I think that the intended behavior is to simply copy the last received
G1 octet. This behavior can be stated like this:
"The G1 byte (path status) is a copy of the last G1 octet received from
the far end transmitter. The G1 octet conveys the path terminating
status and performance back to the WIS transmitter."
This would replace the current text:
"The G1 byte (path status) is a copy of the G1 octet received from the
far end transmitter. The G1 octet conveys the path terminating status and
performance back to the WIS transmitter. The G1 byte shall be implemented
with a latching function, such that the reception of any non zero G1 octet
will cause the G1 byte to become set to the value of the received octet and
remain set until it is read via the management interface."
Regards,
Norival
==========================
Norival Figueira, Ph.D.
Nortel Networks
4301 Great America Parkway
Santa Clara, CA 95054
Tel: 408-495-3674
Fax: 408-988-7512
norival@xxxxxxxxxxxxxxxxxx
==========================
At 05:18 PM 10/5/00 +0530, Prosun Chatterjee wrote:
>Dr. Nelson,
>
>Thanks for the prompt reply. I understand
>what you have written, and have no problem
>with that.
>
>My problem is that the register in question
>HAS BEEN DEFINED AS AN LNZ REGISTER (pg 78),
>which contradicts 125us UPDATES.
>
>This is what makes me feel that it becomes
>useless in light of the fact that it will
>most probably LATCH (and not change when
>an error occurs), and KEEP latched, a
>normal operation value of 02h.
>
>Prosun
>
>-----Original Message-----
>From: Dr. Gary Nelson [<mailto:gnelson@xxxxxxxxxx>mailto:gnelson@xxxxxxxxxx]
>Sent: Thursday, October 05, 2000 1:42 PM
>To: Prosun Chatterjee
>Cc: HSSG
>Subject: Re: Path Status (G1) latching
>
>The G1 Path Status is sent every 125usec by the receiver (far end) of a
>SONET signal to tell the sender (near end) of that signal how it
>looks when it is received at the far end, ie it is a real time
>(upstream) feedback signal. Thus, that Rx register at the near end is
>reloaded every 125usec when the G1 byte is received from the far end.
>The near end Rx chip that contains this register interfaces to a
>processor that must read the register. The software has to be designed
>to
>hae a real time loop that runs to completion every 125usec.
>The REI-P field contains an estimate of the number of bit errors
>contained in the Synchronous Payload Envelope to
>which it refers. The sender/near-end accumulates the byte-size XOR of
>all the bytes of the SPE, puts that result-byte in B3 of the next
>SPE/frame and ships it (downstream). Receiving/far end calculates the
>XOR across the SPE and XORs it with B3, counts up the number of 1s in
>the result and that is the REI-P--it is a reasonable estimator of the
>number of bit errors in that frame. The far-end returns the G1 byte in
>which the RDI and ERDI field identifies all other monitored Path layer
>error conditions. REI-P refers only to bit errors (or Coding Violations
>as they are called in the lingo of SONET).
>
>Thus, the register to which you refer is changing all the time in
>response to the real-time conditions of the outbound/downstream link
>
>Naturally, this process is ongoing at both ends such that signal
>integrity in both directions is monitored and fed back to the senders.
>And reported to the NMS of course.
>
>In SONET lingo, downstream refers to the direction of signal flow,
>upstream to the reverse direction.
>
>Prosun Chatterjee wrote:
>
>>
>>
>> Hi all,
>>
>> This regards the G1 path status maintained
>> in register 2.12.7:0 (section 33.3.2.9 of
>> the draft).
>>
>> This states ".... become set to the value
>> of the received octet and remain set until
>> it is read via the management interface."
>>
>> A typical SONET equippment will set this
>> to 02h (= "0000" REI & "001" RDI (no error
>> ERDI indication) & '0').
>>
>> Since a non-zero value, once latched, will
>> not be removed till read, the non-zero
>> normal operation condition is what will
>> get latched practically all the time.
>>
>> All error conditions will be lost to this
>> status byte practically for all time.
>>
>> Given this, can someone tell what purpose
>> this status byte hopes to achieve?
>>
>> regards,
>> Prosun
>
>--
>
>Dr. Gary A. Nelson
>Zynrgy Group Inc
>20708 Deerpath Road
>Barrington, IL 60010-3787
>USA
>+1.847.304.0000
>+1.847.304.1929 fax
>gnelson@xxxxxxxxxx