Re: Issues in mapping Ethernet signal to SONET
Osamu,
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
terminology).
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.
Regards,
Norival
==========================
Norival Figueira, Ph.D.
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
Tel: 408-495-3674
norival@nortelnetworks.com
==========================
At 01:59 PM 4/17/00 +0900, Osamu ISHIDA wrote:
>Norival,
>
>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,
>Osamu
>
>
>At 4:00 PM -0700 00.4.14, Norival Figueira wrote:
>http://grouper.ieee.org/groups/802/3/10G_study/email/msg02325.html
>> 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:
>> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02310.html
>>>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
>>>sides?
>
>>>At 3:46 PM -0700 00.4.13, Norival Figueira wrote:
>>>http://grouper.ieee.org/groups/802/3/10G_study/email/msg02306.html
>>>> A presentation of the PCS2 function (i.e.,SONET
>>>> compatibility function):
>>>> http://grouper.ieee.org/groups/802/3/ae/public/mar00/figueira_1_0300.pdf
>>>
>>>> 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.
>