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

re:A Minor NIT




Eric,

Good description !. Some additional comments below.

Gary ..


At 10:00 AM 6/22/00, Erik Trounce wrote:

>So, to summarize...
>
>The WIS treats the SONET/SDH data as bytes(octets).  It extracts the
>SPE from the SONET frame, which it sees as a block of 16704x9=150336
>octets.  The WIS processes and removes the POH, and removes the fixed
>stuff.  This leaves you with 16640x9=149760 octets, the payload (my
>definition).  This payload is sent to the PCS as a bit stream
>(logically).  This bit stream is a stream of concatenated 66-bit PCS
>codewords.  The PCS synchronizes to the 2-bit preamble to discover
>the codeword delineations.  Everything is good.  If there are no
>SONET pointer adjustments then the next SONET SPE is extracted in
>exactly the same way as above, and the new payload is concatenated
>with the previous payload to be sent to the PCS. 


I'm not sure what you mean by concatenated. The PCS would be reading this data out of an elastic store as a constant byte steam. The elastic store handles all the gaps due to POH, fixed stuff, pointer adjustments, etc. Basically data is written into this store in a gapped fashion from the WIS and read out as a continuous byte stream by the PCS.


>  The PCS
>codewords will cross SPE boundaries but the PCS should not see any
>indication that a new SONET frame has been parsed.  It just sees a
>constant (logically) bit stream.
>
>Now, you get a negative pointer adjustment on the SONET pointer.
>The pointer is decremented by one so there are 192 extra SPE bytes
>stored in the 192 H3 positions. 


No. Pointer adjustments, either positive or negative, do not change the number of bytes in the SPE (this is always fixed at 16704 and consists of POH + fixed stuff + payload).  During a negative pointer adjustment, 192 bytes from the SPE that would have been sent out in the 192 timeslots following the H3 bytes are instead sent out in the 192 H3 timeslots, basically advancing the SPE data by 192 bytes (but not changing the number of bytes in the SPE itself).


>  The WIS must include these as
>part of the SPE (and they may be POH or fixed stuff). 


These bytes are part of the SPE.

>  These 192
>bytes should be inserted in the SPE following the last byte of
>SPE preceding the first H1 byte, or, equivalently, preceding the
>first byte of SPE following the last H3 byte.
>   Note that the SPE
>has not changed size, it has an extra 192 bytes stored in
>the H3 overhead positions but ends 192 bytes earlier in the SONET
>frame.


Yes.


>A positive pointer adjustment is just the reverse of above.  The
>pointer is incremented by one, so 192 byte times are unused (the
>192 bytes following the last H3 byte) and 192 byte times are
>added at the end of the SPE.  Logically, the byte following the
>last unused byte time follows the SPE byte preceding the first
>H1 byte.  The next SPE begins immediately following the last extra
>byte time, 192 byte times later than in the previous SONET frame.
>
>The other case is a New Data Flag (NDF) event.  In this case, the
>pointer can arbitrarily change.  If the new pointer value is lower
>than the current value, I suspect data will be lost since the
>next SPE will overlap the current, which also means the PCS will
>have to resync.  If the new pointer value is higher than the
>current value, there will be a gap between the current and next
>SPEs.  The WIS should not send any data during this gap.  However,
>as far as the PCS is concerned, the first bit proceeding the gap
>(the 1st bit of the next SPE) follows the last bit preceeding the
>gap (the last bit of the current SPE).


An NDF means something has gone seriously wrong and is used as a means to speed up the recovery process (the alternative is to let the pointer processor state machine re-acquire synchronization by itself which could take approx 6 frames - can't remember the exact number off the top of my head). You would expect data to be lost in this case.


>Does this make any sense?
>
>Erik Trounce
>Nortel Networks
>
>