Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Brad, Yes, we had some discussion on these points during the call.
I’ll post notes soon (over the weekend?). Overall, we had a healthy discussion on the merits &
demerits similar to the dialogue that has been present on the reflector.
However, after that debate, my plan is to submit a comment based upon “traverso_1_0711”
as it is posted. One possible compromise (only discussed at a hazy outline level)
was to have interested parties pursue a non-IEEE standard route with the
detailed specifications required to achieve >400 m reach over OM4. I’ll try to capture the details in my notes. cheers --matt From: Brad Booth
[mailto:bjbooth@xxxxxxxxx] I was surprised to see no response to this. Not sure if it
got addressed on today's conference call. I do want to address the aspect of willingness. In my humble
opinion, there would be greater willingness to support the proposal if the full
set of 10GBASE-SR compliant parts could be used rather than a
"subset". Without a distinct nomenclature to distinguish an optics
device that complies with the subset versus one that complies with the 10GBASE-SR
specification, there is no way to know how to achieve the greater reach than
400 m on OM4. If you wish to create a new port type, then a new class of
PMD is being created. To put it in terms of cabling, OM4 is a subset of
OM3. But why is it called OM4 and why does it have its own specification
if it is just a better performing OM3? (rhetorical question) If the cabling
standards bodies have to create a new specification for this improved subset of
OM3 (aka OM4), then IEEE 802.3 should be required to create a new specification
for this new PMD. The other option is to create a proprietary version as you
mentioned. MSA's, consortia, etc. do this all the time and that is their
choice. What impedes my willingness to support this modification to
the standard is that in my opinion it is creating a new PMD. It creates a
new SKU in manufacturing, in creating parts, in building ports, etc. And to
create a new PMD, even if it is a subset, should be done as its own project and
not through the revision of the standard. Just as Marek did a CFI to modify the
EPON capabilities, so should this effort be handled in a similar manner. Only
then can the working group decide if this should be studied and if so, later
decide if it warrants a project. Thanks,
On Tue, Aug 16, 2011 at 2:13 PM, Kolesar, Paul <PKOLESAR@xxxxxxxxxxxxx> wrote: Rick
Pimpinella of Panduit is working to subscribe to this reflector. In the
mean time he asked me to share his spectral width data from their assortment of
transceiver samples. With about twice the number of samples, and
representation of eight manufacturers, it validates the Corning
distribution. All this
data is simply addressing the potential availability of devices that could meet
the proposed engineered link spectral width. With ~40% of the samples
passing the 0.30nm proposal, it seems clear that the subset of 10GBASE-SR
compliant parts is rather abundant. So the industry is quite capable of
supporting this proposal. Putting
that aspect of the question aside as resolved, the context of the discussion
shifts from capability to willingness. While I
must agree that it would be helpful (as well as the right thing to do) to give
a reduced spectral width transceiver a name to distinguish it from its
minimally-compliant 10G-SR brethren, it is not absolutely necessary to do so
within the standard for this is not a new PMD. Rather, is a completely
compliant subset of the existing PMD. There is no design change, nor a
different parts list, technology, transmission technique, or wavelength.
The manufacturer simply sorts the parts from existing production
yield. It interoperates with its counterparts to the full capability of
the less-capable part. This interoperability aspect would be clarified by
granting a new name, but let’s look at the converse first. There are
plenty of examples of PMDs in the market that do not appear in the
standard. -SR-lite, -USR, and –ZR are among the suffixes that come
to mind. None of these need be compliant to anything because they are
proprietary. Every proprietary offer has no assurance of
interoperability, which is a cornerstone of why we develop standards. Yet
the market copes with all that, and the problems it brings will not stop future
proprietary offers. Now
contrast those cases with that of the engineered link proposal where the part
remains completely compliant and non-proprietary. The compliance aspect
is powerful reason to give it a nod in the standard. So what it
is called can be defined in the standard or left to the whims of proprietary
offers. I propose that rather than let this blossom into a whole range of
new proprietary suffixes, to take charge of it within the standard. If
the remaining rub is really just what to call it, let me propose some names: 10GBASE-SRX 10GBASE-SRE Here X
stands for eXtended and E stands for Enhanced. Both of these should ring
well for those who like to think of the definition of these suffixes in ways
that relate to the customer rather than technology. Placement in the last
position is well suited, as that location is often used for embellishments such
as in –SR4, -SR10, -LX4. Now some
of you will likely come back at me with the argument that we don’t have a
project to develop a new PMD or we can’t do a new PMD under a maintenance
activity. To both arguments I say again that this is not a new PMD, it is
a subset of an existing PMD. We are operating under a project called
802.3bh with a scope encompassing the entirety of the standard. No one
has disputed the proposal based on technical merit. The numbers are
good. The changes are minimal. And the benefit is harmony rather
than possible confusion. Regards, Paul
Kolesar From: Brad Booth [mailto:bjbooth@xxxxxxxxx] Steve, The
scenario you listed is not an apples-to-apples comparison, but rather an
apples-to-oranges comparison. I'm
sure I don't need to remind you that the compliance point in an Ethernet
network is at the medium dependent interface (MDI). A
customer that purchases a switch or server that has a port type 10GBASE-SR
or 10GBASE-ER assumes that the device is compliant with the specifications
at the MDI. In the case of the ER channel, if the channel is compliant with the
specification - whether it is 30 km or an engineered 40 km link - then the
system will be interoperable. As
for your concern, if the 500 m OM4 link was compliant to the channel
specifications at the MDI, then there would be no issue. From what has been
presented, the specification at the MDI looking into the PHY and into the
channel needs to be changed to permit a 500 m OM4 link. This is radically
different than what 10GBASE-ER requires, hence the inability to do an
apples-to-apples comparison. To
try to require a tighter specification at the MDI while still calling the port
type 10GBASE-SR is misleading. As an industry, we would be unable to guarantee
interoperability to an end user that has purchase 10GBASE-SR optics for their
devices and expect them to operate over 500 m of OM4, because the only
requirement for 10GBASE-SR is to be "minimally" compliant with the
specification at the MDI. Therefore, a new port type is required for your
proposal. To
create an apple-to-apple comparison, don't touch the spectral width of the
10GBASE-S PMD. If you can "engineer" the 500 m OM4 channel to have
the same performance specifications as a 400 m OM4 channel, then you would be
creating a system similar to what 10GBASE-ER does. This
is just my take on it. Cheers, Brad On
Tue, Aug 16, 2011 at 8:49 AM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx>
wrote: Dan, Thanks for
the comment; I think this subject will be discussed further in a future call
but I would like to understand the concern here. If someone
releases a product tomorrow that is 100%
compliant, but minimally meets the laser specs for SR, then
he can support a minimum of 400m per the standard. If someone
releases a product tomorrow that is 100%
compliant, but exceeds the minimum laser specs, fiber specs
and connector specs for SR by a defined amount, then he can support a
minimum of 500m per the standard (by definition, an engineered link). Contrast
this with: If someone
releases a product tomorrow that is 100%
compliant, but minimally meets the single-mode fiber specs
for ER, then he can support a minimum of 30km per the standard. If someone
releases a product tomorrow that is 100%
compliant, but exceeds the minimum single-mode fiber specs
for ER by a defined amount, then he can support a minimum of 40km per the
standard (by definition, an engineered link). But it is
still 10GBASE-ER, right? Steve Steven
E. Swanson t
828-901-5328 From: Dove, Daniel
[mailto:dan.dove@xxxxxx] Hi Steve, I tend to agree with Brad. We cannot
specify the reach based upon empirical laser data. We must consider the
specifications and assume that somebody is going to release a product tomorrow
that is 100% compliant, but minimally meets the laser specs for SR. The goal of this maintenance effort
should stick to confirmation that existing SR optics (per spec) will support
the reaches defined and I think we have done that. We can debate about how much
margin should be necessary as this might allow a slight increase in reach, but
400m is a nice round number and retaining some margin will increase confidence
in passing the spec readily.
From: Brad
Booth [mailto:bjbooth@xxxxxxxxx]
Thanks
Steve. BTW,
you make reference to last week's presentation. I remember reviewing it on the
conference call but was it ever uploaded? I'd like to be able to reference back
to it. As
mentioned on the call, the concern is lack of 100% coverage with available
10GBASE-S PMDs. If only a subset of PMDs would satisfy the spectral
width requirements for achieving 500m reach, then that subset would require
a new PMD name to distinguish them as exceeding the 10GBASE-S requirements. I
believe some felt that we don't add a new PMD specification to 802.3 without a
PAR that permits use to do so. A new PMD is probably considered by many to be
outside the scope of the revision PAR. Cheers, Brad On
Mon, Aug 15, 2011 at 12:56 PM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx>
wrote: Brad, I didn't do it for spectral width because I
attached a plot of all of the VCSEL spectral widths but here is the raw data:
So in the proposal we made last week, ~40%
of the lasers would support 500m with 1.1 dB margin; with a little less margin,
I think .35nm will work suggesting that ~78% of the lasers would support the
proposal. Steven E. Swanson t
828-901-5328 From: Brad
Booth [mailto:bjbooth@xxxxxxxxx]
Steve, In
bullet points #2 and 3, you list the worst case wavelength and OMA power. Can
you also do the same for bullet point #1 for spectral width? Thanks, On
Mon, Aug 15, 2011 at 10:23 AM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx>
wrote: Matt, I had an error in my calculation: 1. The average spectral width is 0.317 2. The average wavelength is
850.6; worst case 845.7 3. The average OMA power is -1.41;
worst case -2.42 Using these numbers in the IEEE
model yields 4.9 dB of margin at 400m. Using these numbers in the IEEE
model yields 2.6 dB of margin at 550m. Steven E. Swanson t
828-901-5328 From:
Swanson, Steven E [mailto:SwansonSE@xxxxxxxxxxx]
Matt etal, I had our guys look at the VCSELs we have
purchased on the open market used in our test facilities; there are 70
transceivers from 6 different manufacturers. 78% of the spectral widths are
less than 0.35. The triple trade-off numbers are as follows: 1. The average spectral width is 0.286 2. The average wavelength is
849.4; worst case 845.7 3. The average OMA power is -1.24;
worst case -2.42 Using these numbers in the IEEE
model yields 5.2 dB of margin at 400m. Using these numbers in the IEEE
model yields 3.3 dB of margin at 550m. The more I look at this, I think
we are being REALLY, REALLY conservative in IEEE, maybe too much so;
here is the distribution of spectral width: Steven E. Swanson t
828-901-5328 From: Matt
Traverso (mattrave) [mailto:mattrave@xxxxxxxxx]
Hello
to the now very active IEEE Maintenance reflector! As
I mentioned during my presentation at the IEEE plenary in July I would like to
schedule a few calls to follow up on the questions/comments raised during the
meeting. (see http://www.ieee802.org/3/maint/public/traverso_1_0711.pdf) My
goal for these calls per the discussion on the floor is to try to build more
confidence in the proposed reach value. I believe that there was broad
consensus at the meeting that (a) goal of specifying value is worthwhile,(b)
theoretical analysis was sound. I hope to confirm my perception at the
first call & discuss further justification for 400m reach. My
intention is to submit a comment by the comment deadline of Aug 26th. Call
timing: Wednesday
Aug 10th, 10 – 11:30 am PT Wednesday
Aug 17th , 10 – 11:30 am PT Meeting
login details below best
regards --matt
traverso -+-----+-----+-----+-----+-----+-----+-----+-----+- Meeting
Number: 203 920 382 Meeting
Password: OM4 ------------------------------------------------------- To
start this meeting ------------------------------------------------------- 1.
Go to https://cisco.webex.com/cisco/j.php?J=203920382&PW=NNjg0OTljYThj 2.
Log in to your account. 3.
Click "Start Now". 4.
Follow the instructions that appear on your screen. ---------------------------------------------------------------- ALERT:Toll-Free
Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The
affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP
area. Please
dial the local access number for your area from the list below: -
San Jose/Milpitas (408) area: 525-6800 -
RTP (919) area: 392-3330 -------------------------------------------------------
To
join the teleconference only -------------------------------------------------------
1.
Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html
2.
Follow the prompts to enter the Meeting Number (listed above) or Access Code
followed by the # sign. San
Jose, CA: +1.408.525.6800
RTP: +1.919.392.3330 US/Canada:
+1.866.432.9903
United Kingdom: +44.20.8824.0117
India:
+91.80.4350.1111
Germany: +49.619.6773.9002
Japan:
+81.3.5763.9394
China: +86.10.8515.5666 CCM:+14085256800x203920382# |