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

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.

-----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

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.