Re: [RPRWG] Further Comments on using <64Byte Frames with 802.3 PHYs
Bob, I wasn't thinking about the minimum frame size with respect to SONET,
but rather a careful review to determine what the assumptions were for SONET
and to see if we are breaking any of those assumptions. If reading Bob
Grow's note I saw that his primary emphasis was on the process of how we
evaluate a PHY before applying it. His basic message was that we must be
extremely careful in picking up any PHY and first understand the basis and
assumptions that went into developing it, in order to determine if we can
use it. On the whole I believe that most of us in 802.17, and I include
myself in that group, have been too cavalier in assuming that we can easily
pick up a developed PHY without close scrutiny to see what "gotchas" are in
it. Bob and Geoff give some good advice in requesting that we first
carefully review. I would add: and then we should document what we have
found, showing why we can use what we do. In addition, if we change any of
the assumptions, then more exhaustive analysis is required to verify that
our use of the PHY, now modified in how it will operate, is still
technically sound.
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 Fax: 208 978-1187
----- Original Message -----
From: "Castellano, Robert" <RCastellano@xxxxxxxxx>
To: "'Robert D. Love '" <rdlove@xxxxxxxxx>; "'Thompson, Geoff O '"
<thompson@xxxxxxxx>; "'Grow, Bob '" <bob.grow@xxxxxxxxx>; "'802.17 '"
<stds-802-17@xxxxxxxx>
Sent: Friday, January 24, 2003 2:23 PM
Subject: 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