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

RE: Loss of Code Word Delineation alarm



Title: RE: Loss of Code Word Delineation alarm
Prosun,
 
A. I have a presentation on 'WIS Fault Isolation' for next week's meeting
    which proposes using the G1 Status byte RDI-P field for relaying 64/66
    loss of delineation (LCD-P) back to the source.
 
B. Your last sentence is correct - 'Or is it that this particular ELTE function
    is present ONLY for vendors who require to do the translation? '. The
    conversion from contiguously concatenated to virtually concatenated
    would generally only occur on ingress/egress to a European operator's
    transport network.
 
...Dave
-----Original Message-----
From: Prosun Chatterjee [mailto:prosun@xxxxxxxxxxxxxxx]
Sent: Wednesday, November 01, 2000 1:33 AM
To: Dr. Gary Nelson; Martin, David [SKY:1I63-M:EXCH]; 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