History
You want a history lesson? I love giving history lessons, and I am
sure that the wise sages, who have seen Ethernet through many more
generations than I, will provide additional insights or corrections.
In the good old days, Ethernet had one PHY. It performed Manchester
encoding at 10 Mb/s. We had different Medium Attachment Units (MAUs)
underneath the PHY to support different physical medium. The
Manchester PHY had a long and useful life, because most media had
plenty of bandwidth, and you didn't have to optimize the coding scheme
for each different medium.
As we started going faster, we found various benefits in allowing greater
flexibility at the physical layer.
We've had two different PHYs within the same project before. Fast
Ethernet was an example. In a single project, 802.3u, we specified the
100BASE-T4 PHY, and the 100BASE-X PHY, which had two media variants,
100BASE-TX and 100BASE-FX.
The rationale was that the repeater, MAC and MII were common to both,
but that the two PHYs could be optimized for their respective
underlying medium. T4 was designed to work on 4 pairs of category 3,
4, or 5 cable. X was designed to work on either two pairs of category 5
cable (TX) or two multi-mode optical fibers (FX).
The two PHYs were developed in parallel, more or less in lock step.
When we reviewed, balloted, and approved 802.3u, we reviewed, balloted,
and approved both 100BASE-T4 and 100BASE-X.
Later, we did a project called 802.3y, that defined the 100BASE-T2 PHY,
for operation on two pairs of category 3, 4, or 5 cable, with the
ability to run in full duplex (something T4 lacked). T2 could have
been done in 802.3u, and there were proposals to do something like it
(CAP-32 was proposed to 802.3u), but the membership of 802.3 wisely
decided that it the technology was not as mature as the technology
required for T4 or X, and that the inclusion of a T2-like PHY would
have delayed 802.3u.
That was also the rationale for splitting 802.3ab (1000BASE-T) out from
802.3z. The Working Group decided that the 1000BASE-X PHY and its
associated PMDs were moving at a faster pace than the work on
1000BASE-T, so we split 1000BASE-T out so that it could run on
it's own schedule. This necessitated the generation and approval of a
new PAR and 5 Criteria, for the 802.3ab project on 1000BASe-T.
So here we come to the crux of the matter. You can define the scope of
a project to include as much or as little as you want. In 802, we have
some notions about what the charter of each Working Group is, so we try
to stay within a Working Group's charter when we define a project.
When you get a Project Authorization Request (PAR) approved by the IEEE
Standards Board, you are getting permission to hold meetings, develop a
draft standard, and conduct ballots on it. Basically, you get the
permission to conduct one sponsor ballot, and the subject of a sponsor
ballot is a single document. Once you exercise your privilege to run a
ballot, you have used up your PAR.
So the rule is, you need a PAR for each document you plan to ballot.
If we feel that we can develop both the LAN PHY and the WAN PHY within
a single project in 802.3, and that the documentation for the PHYs can
be written, reviewed, and balloted at the same time, then we can ask
for just one PAR. If we find out later that one of the PHYs is taking
longer to specify, we can spin that PHY off into a separate project.
Taking things down to a finer level of detail, the two PHYs will be
described in separate clauses (chapters). Any new management attributes
will be described in clause 30, where the existing management
attributes live. The 10Gig MII (what I like to call the XMII) will be
described in another new clause. In all likelyhood, we will have
several different sub-taskforces within 802.3ae, one for the LAN PHY,
one for the WAN PHY, one for the XMII, one for management, etc. The
groups would meet in parallel most of the time. That's the
organizational structure we used in 802.3u and 802.3z, and it worked
reasonably well.
But all of that is still to be decided, and it is up to 802.3, and the
802.3ae Task Force to make those decisions. I am sure that there will
be some suggestions and discussion about how to proceed in York. In
the meantime, it might be a good idea to start tossing around some
ideas for the PAR and 5 Critters. If anyone is interested in boning up
on them, you might want to take a look at the 802.3z PAR and 5 Criteria,
which you can find at the URL:
http://grouper.ieee.org/groups/802/3/z/public/misc/
Some of this material can be reused for 802.3ae. In fact, we can
probably add an extra zero here and there, and use the 802.3z stuff as
a starting point.
Howard Frazier
Cisco Systems, Inc.