| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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
-----------------------------------------