Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] Trowbridge_01_0907.pdf comment about

I think I already mentioned that this possibility occurred to me in a
previous reply I wrote to Pat. Of course one would need to take care of
how the sequence of 64B/66B blocks get mapped to FEC codewords. If we
sequentially number the 64B/66B blocks 1, 2, 3, 4, 5 ..., then block 1
is the 1st block in the FEC codeword for lane 1, block 2 is the 1st
block in the FEC codeword for lane 2, block 3 is the 1st block in the
FEC codeword for lane 3, block 4 is the 1st block in the FEC codeword
for lane 4, block 5 is the 2nd block in the FEC codeword for lane 1, and
so on for the 128 64B/66B blocks that fit into the four corresponding
FEC codewords sent on each lane.

-----Original Message-----
From: Andre Szczepanek [mailto:a-szczepanek@TI.COM] 
Sent: Thursday, September 27, 2007 1:53 AM
Subject: Re: [HSSG] Trowbridge_01_0907.pdf comment about


Your statement : "No such (alignment) marker appears in any 10G serial
PHY" is not strictly true.

The 10GBASE-R PCS FEC layer standardized by Backplane Ethernet imposes a
2112 bit FEC block structure onto the serial bit stream. FEC block
boundaries can be used as alignment markers to allow ~ +/- 1000bd of
interlane deskewcapability.

The downside of FEC is of course the additional error correction latency
(2112+ bd), however if FEC framing was supported without correction then
this could be avoided (Currently the standard requires that if you
support FEC you must error correct).

Andre Szczepanek (TI)

Trowbridge, Stephen J (Steve) wrote:
> Hi David,
> Understood that the state machine is the (most) normative part of the 
> specification, but I don't think you want to rely on things that are 
> buried deep in the state machine to provide the appropriate safeguards

> about where one needs to be careful in future evolution of the 802.3 
> standard so as not to break a mapping into OTN. No doubt that the 
> state machine must be designed so that it interworks properly with the

> mapping into OTN that will be standardized concurrently in ITU-T. But 
> making sure that it works with the initial version of the standard and

> making sure that nobody breaks it later both need to be covered.
> Regarding the 40G PHY, we haven't (and aren't allowed to yet, 
> according to the rules) chosen a solution. I think that it is widely 
> assumed that the 40G PHY will be a 4-lane interface with each lane 
> bearing a lot of resemblance to a 10G serial PHY, but it WILL be 
> different. For one thing, the lane of the 40G PHY needs to have lane 
> alignment markers for deskew when combined with the other three lanes.

> No such marker appears in any 10G serial PHY (and the markers for 10G 
> parallel PHYs are based on replacing four 10B consecutive codewords 
> from an IPG - since I think it is widely assumed that we won't be 
> using 8B/10B for the lanes of 40G (which wouldn't correspond to any 
> serial PHY for 10G anyway), so the 10G Base-X lane marking strategy is

> unlikely to be used for 40 GbE). Whether the lane alignment markers 
> are inserted into a lane by doing a rate adaptation on the MAC 
> (stealing enough IPG to make room) and just making the marker look 
> like a control block, or whether the lane rate is increased slightly 
> to make room for the marker is still TBD. So I agree that it is most 
> likely that lanes of the 40 GbE PHY will be quite similar to a 10 GbE 
> serial PHY, I do not see any way that the lanes of a 40 GbE PHY could
actually BE a 10 GbE serial PHY.
> Regards,
> Steve
> -----Original Message-----
> From: David Martin [mailto:dwmartin@NORTEL.COM]
> Sent: Wednesday, September 26, 2007 1:26 PM
> Subject: Re: [HSSG] Trowbridge_01_0907.pdf comment about
> Steve,
> A couple of comments on this...
> Just so you're aware, it's 802.3 practice that a state machine is the 
> definitive description of a function and takes precedence over any 
> related textual descriptions. Textual descriptions are intentionally 
> minimized.
> Re your last paragraph, I'm not sure I follow the latter part. I would

> expect 40GigE to use multiple serial 10G PHYs rather than multiple 
> multi-lane 10G PHYs.
> For example, the 10GBASE-KR and 10GBASE-SR serial PHYs both include 
> the
> c49 64b/66b PCS, not 8b/10b. And if APL above the PCS was used, then 
> those PHYs could be leveraged in their entirety.
> ...Dave
> David W. Martin
> Nortel Networks
> +1 613 763 3874 (esn 393)
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> -----Original Message-----
> From: Trowbridge, Stephen J (Steve)
> [mailto:sjtrowbridge@ALCATEL-LUCENT.COM]
> Sent: Tuesday, September 25, 2007 6:00 PM
> Subject: Re: [HSSG] Trowbridge_01_0907.pdf comment about
> Hi Pat,
> Yes, I saw this, but I still think some stronger language is warrented

> assuming that we end up relying on a fixed, controlled codeword set as

> a solid "handoff point" between Ethernet and OTN for 40 GbE and ODU3. 
> If the mapping from one to the other across standards groups is going 
> to depend on it, I don't think you want to trust that everybody goes 
> through an extra level of indirection to find every constraint on the 
> handoff. It is fairly simple to state the constraints that apply to 
> that handoff point clearly in one place, and add the note about the 
> relationship to G.709 (assuming that the two standards progress along 
> the lines of the transcoding solution to carry one over the other). 
> Then you minimize both the chance that someone breaks the transcoding 
> with something proprietary, and the chance that the transcoding gets 
> broken with the evolution of 802.3 by something inadvertently adding 
> something that they didn't know would be a problem because they 
> weren't aware of the relationship.
> I think the text for 40G PCS will be different from 10G PCS anyway 
> because 10G has no multi-lane 64B/66B encoded interface (all of the 
> 10G multi-lane solutions are 8B/10B encoded). So there is the 
> opportunity to make the constraints more explicit for 40G without 
> having to tinker with text that applies to previous rates.
> Regards,
> Steve
> -----Original Message-----
> From: Pat Thaler [mailto:pthaler@BROADCOM.COM]
> Sent: Tuesday, September 25, 2007 2:42 PM
> Subject: [HSSG] Trowbridge_01_0907.pdf comment about
> I want to respond to the comment made on page 7 of the
> trowbridge_01_0907 presentation that says the text about unused type 
> field values is too weak.
> Steve felt that the language in was too weak to ensure that 
> unused values of the type field aren't used - that subclause doesn't 
> have a shall statement about transmission and receipt of reserved 
> values. The reason a statement doesn't appear there is that the 
> behavior is controlled by the state machines and we didn't want to 
> double specify it.
> Look at the R_BLOCK_TYPE and T_BLOCK_TYPE functions defined in 
> Any block type that doesn't meet the defined types gets 
> the value E which causes the transmit and receive state machine to 
> turn it into the error block.
> Use of reserved type field values is fully covered - It is just done 
> in a different location in the Clause.
> Pat