Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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