Re: [HSSG] Trowbridge_01_0907.pdf comment about 49.2.4.3
Steve,
Thanks for the elaboration, it now ties in with your September
presentation.
...Dave
David W. Martin
Nortel Networks
dwmartin@nortel.com
+1 613 763 3874 (esn 393)
~~~~~~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: Trowbridge, Stephen J (Steve)
[mailto:sjtrowbridge@alcatel-lucent.com]
Sent: Wednesday, September 26, 2007 4:09 PM
To: Martin, David (CAR:Q840); STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: RE: [HSSG] Trowbridge_01_0907.pdf comment about 49.2.4.3
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
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: Re: [HSSG] Trowbridge_01_0907.pdf comment about 49.2.4.3
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
dwmartin@nortel.com
+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
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: Re: [HSSG] Trowbridge_01_0907.pdf comment about 49.2.4.3
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
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: [HSSG] Trowbridge_01_0907.pdf comment about 49.2.4.3
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 49.2.4.3 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
49.2.13.2.3. 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