Re: 66-bit alignment vs 8-bit alignment
Dave,
Dave, thanks for your prompt and courteous responses. I have some additional
questions on your comments below. For the sake of brevity, I've deleted
extraneous text. If you believe that I've taken anything out of context, please
correct me.
> David Martin wrote:
>> Rich Taborek wrote:
>> 1) Why would a SONET section framer or any SONET framer, including that
>> in the UniPHY proposal, care about the contents of the payload it is
>> carrying for the specific case that the payload is 10 GbE payload? I
>> may be wrong, but I don't believe that any other SONET payload is
>> relevant or of any interest to IEEE P802.3ae;
>
> The SONET section framer does not care about the contents of the SONET path.
> It is the circuitry that recovers the payload from the SONET path that is
> simpler if that payload is byte aligned, since the byte alignment is already
> provided by the section framer.
Please excuse my ignorance of SONET nomenclature in advance. For the purposes of
this discussion thread I am going to use agreed upon terminology from the agreed
upon "WAN PHY DEFINITIONS" presentation prepared by Mr. David Law and ad hoc
contributors including yourself:
http://grouper.ieee.org/groups/802/3/ae/public/mar00/law_1_0300.pdf
The first assumption I'll make is that P802.3ae has no objectives to develop or
modify any architecture bounded by the "Line side" of SONET Line Terminating
Equipment (LTE) as illustrated in slide 8. If this is not a valid assumption
then don't bother with the rest of this note since I must be way off base and
need to be educated further about SONET.
If the above first assumption is correct, then my second assumption is that
P802.3ae need not concern itself with SONET Section or Line framing and need
only concern itself with SONET Path framing specific to the framing of Ethernet
packets to a SONET path in a "SONET compatible" manner. Once again, if this is
not a valid assumption on my part then don't bother with the rest of this note
since I must be way off base and need to be educated further about SONET.
The point of the above assumptions is to ensure that I and the IEEE P802.3ae
committee fully understand the objectives we are tying to meet with respect to
the WAN PHY. I like the way Mr. Rick Walker phrased this objective in a recent
note to this reflector:
"In any case, the Ethernet WAN phy does not need T1X1 capability. It is not
intended to be a general replacement for SONET. It is only a dedicated wrapper
for *pure* 10 GbE streams."
Getting back to the issue I raised in point (1) above and your response: You
indicated that the circuitry that recovers the payload from the SONET path is
simpler if that payload is byte aligned, since the byte alignment is already
provided by the section framer. I with this and how it fits with both the Martin
et. al. WAN PHY proposal and Frazier et. al. UniPHY proposal. In both cases
information relevant to all SONET framers are byte aligned.
In the case of the Martin et. al. WAN PHY proposal, byte alignment is maintained
through the WAN PHY Path, Line and Section.
In the case of the Frazier et. al. UniPHY proposal, byte alignment is present in
the UniPHY PCS, and is converted to 66-bit alignment by the UniPHY PCS
(64B/66B). The UniPHY SONET path framing is byte aligned with the exception of
the 10 GbE payload, which remains 66-bit aligned. UniPHY SONET path framed data
is passed to the SONET LTE and handled like any other Path multiplexed data. The
10 GbE specific payload is not byte-aligned in the case of the Frazier et. al.
UniPHY proposal. However, I don't perceive this characteristic as being relevant
or disadvantageous in any respect.
>> 2) What is your definition of payload delineation mechanism for the WAN
>> PHY? More specifically since this issue questions the SONET
>> interpretation of word size alignment, if the WAN PHY is UniPHY,
>> the PCS is 64B/66B + SONET framing + SONET scrambling. Therefore,
>> for the UniPHY, the payload delineation mechanism is the 64B/66B
>> decoder. Is there some other requirement for the SONET transport
>> to perform payload delineation?;
>
> Examples of payload delineation mechanisms, which occur after SONET section
> framing and after SONET pointer processing to locate the SONET path: (a)
> 64B/66B case - hunting for the 2 bit 01 or 10 pattern every 66 bits; (b)
> <lngth><type><HEC> case - hunting for an 8 byte string which has a CRC-16
> which matches the 2 byte value following the 8 byte string. Case (a)
> requires searching by bit. Case (b) requires searching by byte.
I agree with your definitions which point out the differences between the
a) Frazier et. al. UniPHY proposal
b) Martin et. al. WAN PHY proposal
The next question in line is whether you agree that both proposals meet P802.3ae
objectives for the WAN PHY?
I assume that the specific objectives in questions are:
"Define two families of PHYs
– A LAN PHY, operating at a data rate of 10.000 Gb/s
– A WAN PHY, operating at a data rate compatible with the
payload rate of OC-192c/SDH VC-4-64c"
and that the second bullet objective (WAN PHY) can be met by either (a) the
Frazier et. al. UniPHY proposal or (b) the Martin et. al. WAN PHY proposal.
>> 4) Your last comment about bit-slipping vs. byte-slipping involving more
>> circuitry is incorrect with respect to 64B/66B code vs. SONET framing.
>> First of all, this "slipping" operation is part of the link
>> synchronization function and need not be performed (at least for
>> 64B/66B) once the link is in sync. For 64B/66B link synchronization
>> is performed by syncing on either a b'01' or b'10' pattern with 66-bit
>> periodicity. I don't know SONET that well, but my understanding is
>> that you're looking for a many byte pattern which occurs every
>> 155,000 or so bytes. I believe it's safe to say that 64B/66B
>> bit-slipping involves significantly LESS circuitry than SONET
>> byte-slipping. Please tell me if I mis-interpreted your "slipping"
>> comment in any way.
>
> The slipping operation is performed on link synchronization. Of course that
> circuitry is still there after link sync is achieved, it's just burning
> power. Your reference to the byte pattern search is the SONET section
> framer operation, which is common for either 64B/66B or <length><type><HEC>
> mappings into a SONET path.
Thanks for the clarification on when the slipping operation is performed. We are
in agreement that slipping is only performed during link synchronization.
I didn't get a response from you regarding my assertion that 64B/66B
bit-slipping involves significantly LESS circuitry than SONET byte-slipping.
Could you please respond to this point? I believe the Frazier et. al. UniPHY
proposal has a huge advantage over the Martin et. al. WAN PHY proposal on this
point.
With respect to your assertion that slipping circuitry is always there and burns
power after synchronization, this may be required in the case of SONET but is
clearly not required for the case of block codes such as 64B/66B and 8B/10B. In
fact, CMOS implementations derive significant power benefits by not switching
states. Since it is very simple to check that a 64B/66B stream is still in sync
after acquiring sync, there is no need to enable sync logic, thereby saving the
power of this logic. However, I must point out that this is an implementation
issue, not a P802.3ae standards issue.
> ...Dave
>
> David W. Martin
> Nortel Networks
> +1 613 765-2901
> +1 613 763-2388 (fax)
> dwmartin@xxxxxxxxxxxxxxxxxx
--
Best Regards,
Rich
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com