RE: Loss of Code Word Delineation alarm
Prosun,
It seems a reasonable approach, but at present we do not define any status
messages
that pass between the PCS which is the sublayer that has knowledge of 64/66
sync
and the WIS which is the layer that could insert the byte into the Sonet
frame. If we
decide to do this, we will have to modify the service interface to add a
status message.
If we adopt a Remote Fault signalling proposal which signals Remote Fault in
band
to the code, then signalling loss of 64/66 sync in the block would be
redundant.
Also, a PCS might have 64/66 sync but there might be a problem in the XAUI
so
that the receive link is not operational.
Is there a value to duplicating the loss of sync information in the Sonet
Frame and
the transmit stream?
If so, should it be just the 64/66 sync status that appears in the Sonet
Frame or
should it be a clone of remote fault?
Regards,
Pat
-----Original Message-----
From: Prosun Chatterjee [mailto:prosun@xxxxxxxxxxxxxxx]
Sent: Tuesday, October 31, 2000 10:33 PM
To: Dr. Gary Nelson; David Martin; IEEE 802.3ae HSSG
Subject: RE: Loss of Code Word Delineation alarm
Hi all,
--------------------------------------------------------------
A. No replies on the 'LCD-P for 64/66 sync'. Is this option
acceptable to all?
From Gary's mail(31st Oct):
"..........pattern, we should assert
Loss_of_Codeword_Delineation by borrowing the ATM Loss of Cell
Delineation codepoint in the G1 byte ........"
The last I objection on this I recall is
from Norival's reply mail (20th July):
"..................
>2. will LCD-P be used for anything (e.g. indicate loss of PCS codeword
>delineation)?
The current proposal keeps WIS and PCS issues as separate as
possible. The WIS manages only its "WAN connection."
.................."
--------------------------------------------------------------
B. Clarification on ELTE:
1. ELTE Functions (please correct where required):
i) Xmission side : B2/M1 additions
ii) Reception side : B2/M1 extraction
iii) Xmission side : addition of remaining 63 '522'
pointers to H1's & H2's
iv) Reception side : BUFFERING of the 64 paths TO
BRING TO ANY COMMON pointer value. And subsequently
regenerate the first H1 & H2 to the common pointer,
and replace all others with the concatenation
indication. This 192c (concatenated) stream is fed
to the WAN PHY, which extracts the payload
2. question:
As I have understood it (and described in iv), BOTH the
ELTE and WAN PHY support received pointer processing. The
ELTE has the further capability to align these to one
pointer value, to enable processing by the WAN PHY. Is
this understanding correct? If so, isn't the WAN PHY's
pointer processing logic redundant. Or is it that this
particular ELTE function is present ONLY for vendors who
require to do the translation?
ref. from Dave's mail (1st Nov):
"...............At the WAN edge, for example an
'ELTE', the translation to 64x STM-1s virtually concatenated
would be done. At that point the 64 pointers etc are generated.
At the egress ELTE the 10GE WAN PHY (VC-4-64c) would be
reconstructed."
Prosun