RE: 9.584640 (framing issue)
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 is byte stream bases. There is no "Idle symbol"
nor "Carrier signal". We need some technique to make
IF Frame A and Frame B are send 9.58464Gbps, receiver side
and receiver can't distinguish two frames.
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
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.
Toshio Ooka @Sumitomo Electric U.S.A., Inc.
3235 Kifer Rd, #150, Santa Clara, CA 95051-0185