RE: 66-bit alignment vs 8-bit alignment

["David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>]

Title: RE: 66-bit alignment vs 8-bit alignment

Rich,

I've removed old text to try and make this easier to follow. My comments are
interlaced.

-----Original Message-----
From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
Sent:   Friday, April 14, 2000 3:08 PM
To:     HSSG
Subject:        Re: 66-bit alignment vs 8-bit alignment




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.

We have an objective to do a WAN PHY at OC-192c payload rate. I don't believe
there is any ruling that precludes also using some form of SONET section/line framing.
Doesn't the Frazier et. al. UniPHY proposal include it?

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. 

When the path payload is non-byte aligned, it is only an issue for the far end path
terminating equipment, not any intermediary SONET LTEs.

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. 

 
Agreed. The concern I have with the UniPHY solution is the loss of 3% thruput
due to the 64/66 encode.

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.

The reason I didn't respond to that question is that I don't believe it is the relevant
comparison to make. The SONET section framer is common to both proposals. It is
the 64/66 delineation vs the <length><type><HEC> delineation that is appropriate
to compare. As offered earlier to Osamu, we're preparing gate count estimates to
quantify our proposal.

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.

I meant that the circuitry wasn't doing anything productive. I wasn't sniping.

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx

========================