RE: [RPRWG] Further Comments on using <64Byte Frames with 802.3 PHYs
Bob,
I believe this issue just applies to the Ethernet PHYs since
they restrict the minimum/maximum frame sizes. I do not
believe the SONET PHYs carry any restrictions.
robert
-----Original Message-----
From: Robert D. Love
To: Thompson, Geoff O; Grow, Bob; 802.17
Sent: 1/24/2003 12:45 PM
Subject: [RPRWG] Further Comments on using <64Byte Frames with 802.3 PHYs
Bob Grow has expanded on his initial answer to my question so that it
provides his perspective of the areas where 802.17 must do further
analysis and evaluation. Bob, thank you for taking the time to do so.
His response is to the following question I posed to both Geoff Thompson
and Bob Grow:
Do either of you see any problem with 802.17 using a "standard 802.3
PHY" and supporting frame sizes less than 64 Bytes", especially if the
data rates of interest are 1 and 10 Gbits/s? Would you expect anyone in
802.3 to be upset with 802.17 requiring the PHY to support the small
frame sizes? (I realize that you can't know for sure how everyone will
respond to this question. I am just looking for your gut reaction here.
Thanks.)
As I look ahead at the Sponsor level ballot, I want to steer around
stumbling blocks and want to get an early peek at whether there is any
reasonable standards conformance based reason to want to avoid requiring
802.17 PHYs from supporting these small frame sizes. I expect that we
will have a fair number of 802.3 voters in our sponsor ballot pool.
Bob Grow's Reply to me:
Bob:
The answer to your rephrased question is YES! While minimum frame size
should be evaluated, other differences with the Ethernet MAC provide
more likely areas for problems. I know too little about the 802.17 M
AC right now to judge if these are definite problems. That is the job
of participants in 802.17. The list below includes areas for analysis
that occur to me with little thought, in no way should it be considered
a comprehensive list.
I don't know which PHYs 802.17 is considering using, and I haven't even
thought about: 10GBASE-W PHYs, any PMD specific concerns (e.g.,
10GBASE-LX4) or ongoing 10 GbE work within IEEE 802.3 (i.e., the fairly
well understood 10GBASE-CX4, and less well understood 10GBASE-T proposed
projects).
Nothing comes to mind in our 1GbE and 10 GbE PHY specifications that
would limit the minimum frame size to 64 bytes, but there are issues
that 802.17 must consider (as 802.5 eventually had to for GTR). Our PHYs
have been specified assuming characteristics of the Ethernet MAC. The
most important characteristics that permeate implementations are an IPG
between frames of 96 bits (12 bytes) minimum, and the preamble/SFD
starting pattern (8 bytes). Here is a start on areas to study:
10GbE:
1. A mandatory link fault signaling protocol that assumes a full duplex
link and existence of the Ethernet Reconciliation Sublayer. That
protocol includes functions in the PHY that will overwrite frames with
fault signals, uses both transmit and receive paths and assumes the
transmit and receive paths connect to one DTE.
2. 32-bit and 64-bit functions that were specified and reviewed with
Ethernet data streams in mind. These functions align the DA on a 32 bit
boundary. In doing this, it is assumed that the encoding for a start
packet delimiter (not the Ethernet start of frame delimiter) is the
first byte of preamble and that the SPD + preamble + SFD will be exactly
8 bytes.
3. PHY functions that allow minimum IPG to shrink to 5 bytes. The
64b/66b PHY requires a minimum of 5 bytes IPG to maintain frame
delimiters. The IPG functions work on the Ethernet MAC requirement that
frames be an integer number of octets.
4. Common implementations use the XAUI interface. XAUI contributes to
IPG shrinkage and relies on the 32-bit alignment of data from the XGMII.
The new copper interfaces proposed will likely be specified to the XGMII
and support the XAUI interface.
GbE:
1. As you will recall from Gigabit Token Ring, the 10GBASE-X PCS uses a
16-bit idle "ordered set" and aligns by shrinking the preamble. The
sponsor ballot GTR draft had this function deleting the first byte of
the 802.5 frame (AC field). Some PHY implementations shrink IPG instead
of preamble, but the standard specifies preamble shrinkage for
alignment.
2. If it is a desire to use existing PHY parts/libraries, then it is
important to consider if there are any functions in RGMII and SGMII that
break. These are industry MSAs, and not part of the 802.3 standard.
Does it matter if the PHY has to be modified to support smaller frames
if it already has to be modified because of the mandatory link fault
signaling protocol not working in a ring topology? When 802.3 borrows
technology from another standard, we address very early on what is
different. I don't get the warm fuzzy feeling that this has happened
with RPR, it sounds more like the WG is assuming they will be able to
use 802.3 specified PHYs rather than having studied the relevant 802.3
specifications.
So, my "gut reaction" is that the 802.3 folk on your SB probably won't
get upset about these things, they will simply heap scorn on the work of
your committee if it has failed to do its homework. Many people in 802.3
will be reluctant to do any analysis for 802.17; and there might even be
some that would chuckle with glee if 802.17 published a broken
specification.
Bob Grow
The above opinions are mine alone and do not necessarily represent the
opinion of IEEE 802.3 Working Group nor my employer!
=================
I would like to emphasize Bob's statement: "When 802.3 borrows
technology from another standard, we address very early on what is
different. I don't get the warm fuzzy feeling that this has happened
with RPR, it sounds more like the WG is assuming they will be able to
use 802.3 specified PHYs rather than having studied the relevant 802.3
specifications."
This lack of analysis, as seen by Bob Grow, coupled with a willingness
to change parameters is rightly viewed as opening us up for technical
problems. I don't want to minimize work that has already been done by
the PHY experts in the 802.17 WG. However, if we have carried out such
analysis, we certainly have not presented it. I believe we should set
up an AdHoc group to specifically study the 802.3 specifications,
possibly generating the documentation that shows we have already done
our homework, and only change parameters if there is sufficient
demonstrated analysis that the changes will not affect PHY operation.
Both Bob and Geoff have clearly indicated that 802.3 members will not
consider a "hand waving" argument that the changes won't affect
anything, as being sufficient. In addition, although Bob's comments
relate to the 802.3 PHY, it is reasonable to assume that a similar
argument could be brought forward with respect to SONET PHYs.
Therefore, the AdHoc group, or a separate AdHoc group should also be
closely examining the SONET PHYs we are using to see if we are modifying
any of the assumptions made in the development of those PHYs.
Let's not find we have a problem at Sponsor Ballot time.
I would appreciate hearing from our PHY experts with respect to these
issues.
Best regards,
Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx <mailto:rdlove@xxxxxxxx> Fax: 208
978-1187