Re: Issues in mapping Ethernet signal to SONET
David, Paul,
I stand corrected.
Ben
> 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
> -----------------------------------------
--
-----------------------------------------
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
-----------------------------------------