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

Re: Issues in mapping Ethernet signal to SONET


Your list below seems to agree with our proposal. However, I am
having some problem understanding your terminology for J0 and
H1-3. Here is what we propose for J0 and H1-3 (using our

Transmitter side:
J0 - Provisioned value.

Receiver side:
J0 - Allows receiver to verify its continued connection to
the intended transmitter.
H1/H2 - single pointer processor required.
H3 - Use defined by the pointer processor. Carries 192 extra
octets in the event of a negative pointer adjustment.

As you indicate below, dark fiber applications would not change
the H1/H2 pointer.


Norival Figueira, Ph.D.
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
Tel: 408-495-3674

At 01:59 PM 4/17/00 +0900, Osamu ISHIDA wrote:
>Thanks for your clarification on the H3 bytes in your proposal.
>Here are my understanding of the proposed overhead byte usage in 
>the WAN-PHY with SONET-framing.  Note that here I have neglected 
>the fixed values.  Please let me know if I have misunderstood you.
>  Transmitter side:
>    B1: Section: Sending 8-bit Parity-data for BER monitor
>    J0: Section: Sending Section Identifier (static value)
>    B3: Path:    Sending 8-bit Parity-data for BER monitor
>    G1: Path:    Sending Local Fault info & bit-error count
>  Receiver side:
>    B1: Section: Performing BER monitor of 6 x 10^-6 or lower
>    J0: Section: Recieving Section Identifier (static value)
>    B3: Path:    Performing BER monitor of 6 x 10^-6 or lower
>    G1: Path:    Recieving Remote Fault info, Remote bit-error count
>   *H1-2: Pointer:  Processing byte-slip for single pointer
>   *H3:   Pointer:  Processing bute-stuff/destuff for single pointer
>* H1-H3 byte processing is required for receiving from ELTE.
>  Receiving from WAN-PHY (dark fiber) does not need this processing.
>Thanks in advance,
>At 4:00 PM -0700 00.4.14, Norival Figueira wrote:
>> Please refer to the presentation indicated below (in your email).
>> It further explains our proposal for H3 usage and single pointer
>> processor at the receive path of the WAN PHY.
>> At 12:19 PM 4/14/00 +0900, Osamu ISHIDA wrote:
>>>Thanks for your clarification, but I feel I have some confusion 
>>>about pointer manipulation in your WAN-PHY with SONET-framing, 
>>>especially how to treat the pointer H3 bytes.
>>>My question is whether your WAN-PHY and/or ELTE requires or does 
>>>not require the CLK-frequency justification mechanism by the H3 
>>>bytes.  And are there any difference between transmiter/receiver 
>>>At 3:46 PM -0700 00.4.13, Norival Figueira wrote:
>>>> A presentation of the PCS2 function (i.e.,SONET
>>>> compatibility function): 
>>>> Another function that is required at the receiver side is a 
>>>> pointer processor, i.e., only one pointer processor. This is not
>>>> a complicated function. The PCS2 frame has a pointer on
>>>> the H1/H2 octets that can be incremented, decremented, or set to
>>>> a new value.  The receiver PHY uses the pointer value to locate
>>>> the first octet of the SPE (this is SONET terminology for
>>>> Synchronous Payload Envelope). At the transmitter side, the PCS2
>>>> always transmits PCS2 frames with a same fixed pointer value.
>>>> Note that a pointer processor is required because the pointer
>>>> value may be changed by a SONET transport network. The pointer
>>>> may change when the receiver side of an LTE has a slightly different
>>>> clock from the one on the transmitter side. This is exactly the
>>>> mechanism an ELTE will use between the +-100ppm clock of the
>>>> 10GE WAN PHY and the SONET network clock.