Re: Issues in mapping Ethernet signal to SONET
All,
From recent reflector emails, there still appears to be
some misunderstanding regarding our WAN PHY proposal.
The following list summarizes the technical presentations
we've made. They together completely specify our WAN PHY
proposal.
A complete specification:
http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/figueira_2_1199.pdf
A presentation of the PCS1 function (i.e., length-type-CRC
coding scheme):
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/figueira_1_0100.pdf
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
Supporting documents/presentations
Why WAN PHY:
http://grouper.ieee.org/groups/802/3/ae/public/mar00/bottorff_2_0300.pdf
10GE WAN PHY Delineation Performance:
http://grouper.ieee.org/groups/802/3/10G_study/public/email_attach/delineation_perf_v3.doc
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/martin_2_0100.pdf
About our revised terminology
Our revised terminology defines PCS1 and PCS2 as the two main
functions within the PCS. There is still only one PCS. The PCS1
contains the MAC packet delineation function, while the PCS2
contains the SONET compatibility function with minimum overhead
support. (In our older terminology, PCS = PCS1 and PMA = PCS2.)
The PCS2
The PCS2 does not support a full SONET framer. Because of this,
in this email I am calling it a "PCS2 framer" and not a SONET framer.
The PCS2 frame does not have 192 pointers, 192 B2s, or 192 STS1s
to worry about. One cannot directly compare a full SONET framer
with the proposed PCS2 framer.
The PCS2 frame synchronization algorithm is similar to the
one used in 64/66 to sync to 0/1 bits. The main difference is
that the one in the PCS2 looks for A1/A2 octets instead of
0/1 bits. A1/A2 transitions are used as frame markers in SONET.
All the operations after frame alignment are octet-oriented.
At the transmitter side, the PCS2 calculates a few overhead
bytes (B1, B3, and G1) and transmits others with fixed or static
values. The generation of the PCS2 frame only requires counters to
determine overhead positions (e.g., the B1 octet is always the
17281th octet of a frame) and to determine the location of
the payload area. Besides this, the PCS2 frame is scrambled
with x^7+x^6+1.
At the receiver side, the PCS2 frame is descrambled, and the
overheads are retrieved by looking at their fixed positions
inside the frame.
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.
Note: I am using SONET terminology to simplify exposition.
The WAN PHY proposal is also compatible with SDH.
The PCS1
The PCS1 encodes MAC packets and sends them to the PCS2.
In theory, the PCS1 can use length-type-CRC, SLP, or
64/66. In practice, coding schemes with zero overhead and that
keep octet alignment make more sense for the WAN PHY.
Our proposed length-type-CRC coding scheme has zero overhead,
provides a very robust delineation scheme (see reference above),
is a proven technology (e.g., see ATM HEC system), and is octet
oriented. The issue of determining the length of packets can be
very easily resolved by counting the bytes at the PCS. This takes
only about 1.2 microseconds of delay for maximum length packets.
The length-type-CRC scheme replaces idles with 10-octet Idle
Packets. Idle Packets are only generated when required. One
nice property of the length-type-CRC scheme is that packet
headers and Idle Packets are protected by a CRC-16 (which can
detect burst errors of up to 16 bits and can correct single-bit
errors). Idle Packets and packet headers have a similar
format: Length (2 octets), Reserved (5 octets reserved
for future use), Type (1 octet), and HEC (2 octets for CRC-16).
The length-type-CRC scheme maintains synchronization by using
the validated Length value of a packet header or Idle Packet
to locate the next header (i.e., either a packet header or
an Idle Packet), which it validates against the HEC (i.e.,
CRC-16 of the header), and so on.
Please refer to our presentations and posted documents for
more details.
I hope this helps clarify a few points.
Best regards,
Norival
==========================
Norival Figueira, Ph.D.
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
Tel: 408-495-3674
norival@xxxxxxxxxxxxxxxxxx
==========================
At 05:39 PM 4/12/00 -0700, Rich Taborek wrote:
>
>Ben, Dave,
>
>Reading this note, it seems that there is some conflict between what WAN PHY
>proposal IS on the table and what ISN'T on the table. Can you please clarify the
>situation and list the ACTIVE WAN PHY proposals?
>
>One WAN PHY proposal that I know is on the active list is Mr. Howard Frazier's
>UniPHY proposal:
>http://grouper.ieee.org/groups/802/3/ae/public/mar00/frazier_1_0300.pdf
>
>Dave,
>
>This is he first time I've heard the PCS1/PCS2 terminology. We previously had
>the same problem with the 8B/10B code proposed for Hari and solved it by
>proposing the optional XAUI/XGXS interface and associated sublayers. I don't
>believe that there's any proposal for the LAN, WAN or UniPHY that requires two
>PCS sublayers. All PCS functions can be described in a single PCS sublayer.
>
>What is the specific reason for introducing this new terminology and how does it
>appear in the layer model? If you draw a picture of it, please use the model
>from Mr. Brad Booth's "IEEE P802.3ae Document Structure" presentation:
>http://grouper.ieee.org/groups/802/3/ae/public/mar00/booth_1_0300.pdf
>
>Best Regards,
>Rich
>
>--
>
>> David Martin wrote:
>>
>> Ben,
>>
>> A correction to your delineation explanation below. It should state that after
>> the Ethernet data stream is extracted from the SONET payload by the PMA (PCS2
>> in the new terminology), the receive PCS (PCS1 in the new terminology) gains
>> synchronization by searching for any header (data or idle frame) with a valid
>> HEC. It maintains synchronization by using the validated length value to point
>> to the next frame, which again it confirms OK by verifying that header has
>> a valid HEC, and so on.
>>
>> I see that Paul Bottorff has clarified in a later e-mail that the
>> <length><type><HEC> proposal continues to be our position for the WAN PHY.
>>
>> ...Dave
>>
>> David W. Martin
>> Nortel Networks
>> +1 613 765-2901
>> +1 613 763-2388 (fax)
>> dwmartin@xxxxxxxxxxxxxxxxxx
>>
>> ========================
>>
>> -----Original Message-----
>> From: Brown, Ben [NHBED:DS48:EXCH]
>> Sent: Tuesday, April 11, 2000 6:02 PM
>> To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
>> Subject: Re: Issues in mapping Ethernet signal to SONET
>>
>> Tripathi,
>>
>> I'll let someone else respond to your clock tolerance
>> questions. As to why is the Length field inserted into the
>> preamble, this is for packet delineation. The proposal
>> put forth by Paul Bottorff, et al:
>>
>> http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/figueira_1_0100.pdf
>>
>> used a DATA header, consisting of Length, Type and HEC
>> fields in place of the preamble, to delineate the packets.
>> It also replaced IDLEs with similar IDLE headers, using a
>> Length value of 0. After the ethernet data stream is extracted
>> from the SONET payload by the PMA, the receive PCS gains
>> synchronization by searching for IDLE headers with a valid
>> HEC then maintains synchronization by using the Length field
>> to look for the start of the next header (IDLE or DATA).
>>
>> I don't believe this particular PCS proposal is still on the
>> table. Though Nortel still feels strongly about using a WIS
>> of sorts to put the ethernet data stream into a SONET payload,
>> I believe Nortel has succumbed to the pressures of requesting
>> a length value from the MAC (or including the buffering and
>> latency within the PCS to count bytes) and is now in support
>> of Lucent's SLP proposal.
>>
>> Hope this helps,
>> Ben
>>
>> Devendra Tripathi wrote:
>> >
>> > Hi,
>> > Could some one illustrate (or give pointer to existing document) on
>> various
>> > issues
>> > in mapping an Ethernet signal
>> > @9.584640 (+-100ppm) to OC-192 stream. As Paul has already pointed out,
>>
>> > the muxer, should be able to absorb 320 ppm tolerance. Basically I
>> would like
>> > to understand the reasoning for Length insertion in preamble (which
>> makes the
>> > scheme somewhat unpleasant). The basic
>> > OAM&P function like remote fault and break link are already being
>> talked
>> > about as part of the control code (as part of Ethernet stream).
>> > Thanks in advance,
>> >
>> > Best Regards,
>> >
>> > Devendra Tripathi
>> > Vitesse Semiconductor Corporation
>> > 3100 De La Cruz Boulevard
>> > Santa Clara, CA 95054
>> > Phone: (408) 986-4380 Ext 103
>> > Fax: (408) 986-6050
>> > ********************************************************************
>> >
>> > Web: http://www.vitesse.com
>>
>> --
>> -----------------------------------------
>> Benjamin Brown
>> Router Products Division
>> Nortel Networks
>> 1 Bedford Farms,
>> Kilton Road
>> Bedford, NH 03110
>> 603-629-3027 - Work
>> 603-624-4382 - Fax
>> 603-798-4115 - Home
>> bebrown@xxxxxxxxxxxxxxxxxx
>> -----------------------------------------
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com
>