Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Here it is:
Table 38-2—Operating range for 1000BASE-SX over each optical fiber type
Modal bandwidth @ 850 nm
Fiber type
(min. overfilled launch) Minimum range
(MHz · km)
(meters)
62.5 mm MMF
160
2 to 220
62.5 mm MMF
200
2 to 275
50 mm MMF
400
2 to 500
50 mm MMF
500
2 to 550
10 mm SMF
N/A
Not supported
--
Paul Bottorff wrote:
Rick:--I don't see the table image. Can you send the data just in text?
Paul
At 06:45 PM 6/25/99 -0700, you wrote:
>I concurr with Ed Cornejo's reasoning of including the distance, and media
type
>in the objective. The application, I believe, is
>unnecessary. I also strongly agree with Ed's objection to a distance
support of
>300 meters on MMF... if the intention is to support the
>installed base of fiber. This unnecessarily precludes several signaling
>proposals, is much greater than the distance support
>requirements at 1/10th the speed (Gigabit Ethernet) and does not consider
major
>improvements in MMF cable technology which
>may lead to significantly lower cost 10 GbE products. These three reasons
are in
>addition to the three that Ed offers in objection in
>his note.
>
>My suggestion for HSSG distance objectives for fiber support is to partition
>support requirements into "cells" per 1000BASE-X
>clause 38 methodology. Why deviate from this procedue? For example, Table
38.2
>is as follows:
>
>[Image]
>
>(Hopefully, most of you can see the above table. This is the first time I
have
>cut and pasted an Adobe Acrobat graphic into an email.
>What a neat feature! Sorry if this is old news.)
>
>The center column table cells indicate the fiber performance in terms of a
>bandwidth*distance product and is applicable to all PHY signaling schemes.
The
>minimum range is either not necessary, or must be specified as a cell for
each
>PHY signaling variant. My choice would be to eliminate it as redundant and
>confusing information. The only modification I can think of is the
blending of
>results from the work of the TIA FO2.2 regarding laser lunch conditions which
>will likely affect the fiber performance parameter.
>
>This methodology eliminates the need to interpret ill-defined terms such as:
>- the installed cable plant
>- the equipment room
>- a building/horizontal run
>- multiple floors in a building/vertical/riser
>- a campus
>- etc.
>
>Please consider the following wording for a distance motion:
>
>That distance be specified in the form of a table with each row containing a
>fiber type and its associated fiber performance.
>
>Best Regards,
>Rich
>
>--
>
>"Cornejo, Edward (Edward)" wrote:
>
>> Brian, et al,
>>
>> Thanks for your diligence in pressing this issue. Sorry, but I was not part
>> of this reflector until very recently. So here is some feedback on your
>> comments, and some additional comments.
>>
>> I don't see the value of having a general objective that states support for
>> traditional LAN, MAN, and WAN because it doesn't say anything if you don't
>> include distance and media type. Therefore, I favor including the
>> application, distance, and media type in the objective.
>>
>> I have a problem with at least 300m on MMF, and supporting the installed
>> base being added in the objective. Here is why:
>>
>> * I believe mentioning the installed base in the objective could be
>> too restrictive and possibly delay the release of the 10G standard. For
>> example, the serial proposal over new MMF using VCSEL technology could be
>> availble first, but would not satisfy the objective.
>> * We've had surprises with GbE regarding the installed base and it
>> would not be prudent to include it in the objective. Possible surprises for
>> 10G can come from the use of coherent sources like DFBs over MMF.
>> * Lastly, having a minimum distance of 300m may exclude lower cost
>> technologies for shorter distance applications.
>>
>> My suggestion, which would not exclude the installed base, is as follows:
>>
>> For Enterprise Applications
>> * At least 100m over multimode fiber for equipment room applications
>> * At least 200m over multimode fiber for riser applications
>> * We could always increase this number to 300m if everyone
>> feels confident their solution could support this. This just allows some
>> breathing room as proposals are fine tuned.
>> * At least 2km over single mode for the campus application
>> * The reason I want to throttle this back is because you
could
>> be excluding lower cost serial solutions for this application. Also, based
>> on Chris Dominico's installed based study, he presented data that 2km's
>> satisfied a majority of the campus link distance requirements.
>> * Also, 2km is a distance that is defined for short reach in
>> other applications
>> * The reasons for this are clear; it is all about
>> allowing lower cost solutions to the customer
>>
>> For MAN Applications
>> * At least 15km over single mode fiber for the intermediate
>> applications
>> * At least 40km over single mode fiber for the long reach
applications
>> * At least 80km over single mode fiber for the extended reach
>> applications
>>
>> Since I have not been part of your earlier discussions, could someone
>> forward the details for the call this coming Monday.
>>
>> Thanks,
>> Ed C.-Lucent
>>
>> > ----------
>> > From:
>> >
BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx[SMTP:BRIAN_LEMOFF@HP-PaloAlto-om16
>> > .om.hp.com]
>> > Sent: Friday, June 25, 1999 12:31 PM
>> > Cc: stds-802-3-hssg-distance@xxxxxxxx
>> > Subject: Distance Objectives !!!!!
>> >
>> >
>> > Three days ago, I suggested a distance objective on the HSSG
distance
>> >
>> > reflector (the first suggestion, I believe, since Idaho). The
purpose
>> >
>> > of this reflector is to provide a forum for the ad hoc distance
>> > committee (all of us receiving this e-mail) to reach a consensus
>> > prior
>> > to the Montreal meeting. There is a conference call Monday to reach
>> > "final" agreement. So far, there has been no response to my
>> > suggested
>> > objectives. Does this imply that we are all in agreement with them?
>> > If not, then perhaps someone who differs with me could offer a
>> > suggested alternative. Otherwise, we will simply pick up in
Montreal
>> >
>> > where we left off in Idaho.
>> >
>> > -Brian Lemoff
>> > HP Labs
>> >
>> >
>> > ______________________________ Reply Separator
>> > _________________________________
>> > Subject: Re: Discussion on the HSSG Distance reflector
>> > Author: BRIAN-LEMOFF-at-om (BRIAN_LEMOFF@xxxxxxxxxxxxxxxxxxxxxxxxxx) at
>> > HP-PaloAlto,mimegw2
>> > Date: 6/22/99 11:47 AM
>> >
>> >
>> >
>> > As I understood Jonathan's kick-off message, he was proposing
that we
>> >
>> > have two separate objectives, the first being phrased in general
>> > terms
>> > such as the one he proposed, i.e. support for traditional LAN,
>> > support
>> > for traditional MAN, and support for WAN access. The second, and
>> > more
>> > controversial objective will name the distance and fiber-type
>> > objectives. This is probably the more important of the two, and it
>> > has not yet been discussed on this reflector!!
>> >
>> > We might already have a consensus on the first objective (although
>> > there is still debate over support for the WAN), but we are nowhere
>> > near consensus on the second objective. I would support something
>> > like the following:
>> >
>> > To define physical solutions to support distances of:
>> >
>> > At least 300 m on multimode fiber, including the installed base
>> >
>> > At least 6 km on single mode fiber
>> >
>> > At least 50km on single mode fiber
>> >
>> >
>> > I am not wedded to these numbers, but I do think that some mention
>> > of
>> > support for the installed base should be included in this
objective.
>> >
>> >
>> > -Brian Lemoff
>> > HP Labs
>> >
>> >
>> > ______________________________ Reply Separator
>> > _________________________________
>> > Subject: Discussion on the HSSG Distance reflector
>> > Author: del-hanson-at-exch (del_hanson@xxxxxxxxxxxxxx) at
>> > HP-PaloAlto,exchgw2
>> > Date: 6/22/99 11:07 AM
>> >
>> >
>> > HSSG Distance Ad Hoc Colleagues,
>> >
>> > I am on vacation this week but am following my email. I have noticed that
>> > the dialog on the Distance reflector has died up. If this is because
there
>> > is agreement of the restated objectives, that is great. However, by
>> > sending
>> > out an announcement of a conference call for Monday 6/28/99 at 8 AM PST
>> > and
>> > an updated summary of objectives, it was not my intent to close down
>> > discussions. If there are issues that need to be discussed prior to the
>> > call, we need to use this reflector to make them visible. Also, after the
>> > call we need to use the reflector to refine issues so we can go into the
>> > Plenary with consensus, if possible.
>> >
>> > Regards,
>> > Del Hanson
>> >
>
>-------------------------------------------------------------
>Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
>Principal Architect Fax: 650 940 1898 or 408 374 3645
>Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
>1029 Corporation Way http://www.transcendata.com
>Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx
>
>
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx
Best Regards,
Rich
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408
370 9233
Principal Architect
Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc.
Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way
http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx