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