Re: 9.584640 (framing issue)
Toshio,
I have assumed that the proponents of the 9.584640 Gbps MAC/PLS payload rate
have selected that rate specifically to allow a SONET links to accept Ethernet
payload at full rate as indicated in my #5a (below). No other rate will work
without flow control whether it be positive (pause/defer) or negative
(padding).
I am further assuming that all control characters including idles/IPG,
start-of-packet and end-of-packet are accounted for in the 9.584640 Gbps
MAC/PLS payload rate. In 1000BASE-X, the start-of-packet code replaces the
first octet of preamble and the end-of-packet codes are considered to be part
of the IPG. I am not a proponent of 9.584640 Gbps Ethernet. Perhaps proponents
of this rate can better help you with more specific solutions to this framing
issue.
If my first assumption above is not correct, then the HSSG speed objective is a
non-issue since flow control will always be required between SONET OC-192 and
10 GbE. It also follows that a MAC/PLS rate of 10.0 Gbps is the obvious choice
for the HSSG speed objective.
Best Regards,
Rich
--
Toshio Ooka wrote:
> Rich,
>
> I have same questions same as Mr. Hon Wah Chin asked.
>
> > 5) Consider a Ethernet to OC-192 line card (feeding a fiber or
> > wavelength) in operation. Assume that receive and transmit paths are
> separate on
> > the SONET side and related (i.e. full duplex) on the Ethernet side:
> > a) Ethernet -> SONET @ 9.584640 Gbps: The Ethernet side can
> > continuously feed the SONET link with no flow control required.
> > --
>
> If Ethernet takes 9.58464Gbps, no flow control required.
> I agree at this point.
>
> But receiver side should distinguish one frame and next frame.
> This is "framing synchronization" issue.
>
> As Hon wrote,
> 10M Ethernet world:
> There is no signal between two frames. If next frame comes,
> preamble signal makes 1.05V (Carrier) on the Ethernet cable,
> receiver knows this is the start of next frame.
>
> 1000M Ethernet world:
> There is "Idle symbol (10B Code)" between two frames.
> If valid symbol ( =NOT Idle symbol) comes, recover knows
> this is the start of next frame.
>
> SONET
> SONET is byte stream bases. There is no "Idle symbol"
> nor "Carrier signal". We need some technique to make
> "frame synchronization".
> Example.
> Frame A:
> 112233445566
> Frame B
> 88990011223344
> IF Frame A and Frame B are send 9.58464Gbps, receiver side
> will get
> 11223344556688990011223344
> and receiver can't distinguish two frames.
>
> POS solution
> POS is one sample of this solution.
> "RFC 1662 PPP in HDLC_like Framing"
> 0x7E and 0x7D is reserved for framing purpose.
> If we chose FRC1662 way. Frame A and Frame B
> will be send
> 1122334455667E88990011223344
> and receiver detect special code "7E" and
> it can separate Frame A and Frame B.
> # 7E code will be send 7D 5E
> # 7D code will be send 7D 5D
> # detail RFC1662
>
> I think there is some overhead is necessary to
> distinguish two frames.
> Please let me know how to solve this framing issue.
>
> > Hon Wah Chin wrote:
> ------
> > > Given a raw continuous bit stream at the PMD, some scheme for
> > > framing packets would be needed. 10M used a carrier, 100M used coding,
> > > 1000M used coding.
>
> Regards,
>
> ----
> Toshio Ooka @Sumitomo Electric U.S.A., Inc.
> 3235 Kifer Rd, #150, Santa Clara, CA 95051-0185
> Phone:(408)737-8517x232 Fax(408)737-0134
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx