Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Optical Connectors




Speaking as a customer, I wouldn't and haven't (choose MTRJ over LC).

Can we have some data please and less discussion about vendor plots. There
seems to be a lot of discussion about people or organizations plotting on
this mail list.

Mick
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Roy Bynum
Sent: Monday, July 24, 2000 9:15 AM
To: Rohit Sharma; HSSG_reflector (E-mail)
Subject: RE: Optical Connectors



Rohit.

A minor correction.  It is not fiber trays that make the adaptation between 
the carrier transmission equipment using SC connectors and other types of 
connectors.  It is expensive adaptor cables that make the conversion 
between SC and other types of optical connectors.  If you listen to the 
marketing hype of one vendor, you will be led to believe that a lot of 
people are deploying optical connectors other than SC.  It is simply not 
true.  Only one major vendor is using something other than SC.  That vendor 
is attempting to expand their market beyond the single major carrier that 
they were spun off of.  They are making some progress in that area, but it 
is slow going.  In spite of the hype, SC still is the primary SM fiber 
connector and will remain so for some time.

In the data room for multi-mode fiber, I have not seen any SFF connectors 
other than MT-RJ in actual use.  At higher bandwidths, the marketing hype 
that says that MT-RJ has problems the number of insertions is also 
misleading.  The larger, higher bandwidth systems are not constantly being 
physically re-configured.  The number of time that a connector is inserted 
in very low over the life of the interface, many times as little as only 
once.  The lower cost and ease of use of MT-RJ makes it preferable to the 
customers.  Because it is a single connector, fiber length alignment on 
duplex cables is very easy with field termination of MT-RJ 
connectors.  When I was doing duplex SC  for FDDI getting both fibers to be 
the exact same length was a practiced skill.   Speaking as a customer, I 
think that if customers are given the choice between MT-RJ connectors on 
cabling and other SFF connectors, they will chose MT-RJ.

Thank you,
Roy Bynum


At 10:43 PM 7/23/00 -0700, Rohit Sharma wrote:

>For a telecom service provider, the use of LC connectors recommended for
>10GbE transceivers will not affect whether they recommend SC connectors for
>their networks since the service providers typically connect to the
>equipment via Fiber trays which adapt whichever connector (SC, ST, APC,...)
>may be present on the equipment faceplate.  This year, several equipment
>vendors have shown deployed equipment with MU, LC, and other -- even
>proprietary connector types on certain ultra-long haul equipment in
multiple
>networks in Metro, Long haul, submarine applications.  Most service
>providers continue to specify SC for connection to their fiber plant which
>is accomplished via fiber trays.
>
>I do not believe that adoption of LC connector by IEEE precludes the
>(continued) use of SC connector by any network/service provider and moves
us
>in the right direction for SFFs @ 10G.
>
>-rohit
>Rohit Sharma
>
>
> >
> > Chris,
> >
> > I am not sure of your comment about LC having a proven track
> > record for
> > single mode implementations.  At present, WorldCom has not
> > deployed any
> > LC.  All of the connectors currently specified for SM
> > installations is
> > SC.  A particular vendor is attempting to get WorldCom to
> > make use of their
> > connectors.  ( I will not say how successful or not they are.
> > )  Several
> > system vendors are attempting to make use of LC, but at
> > present, none have
> > been certified.  Given the form factor that would use XAUI,
> > SFF connectors
> > would not be a requirement.
> >
> > Thank you,
> > Roy Bynum
> >
> >
> > At 04:28 PM 7/21/00 -0600, Chris Simoneaux wrote:
> >
> > >Our opinion is that LC is a better connector than MTRJ.  The
> > LC does not
> > >seem to suffer the possible damage that MTRJ can see with
> > high mate/demate
> > >cycles...due to the guide pin action.  Also, the LC has a
> > proven track
> > >record for singlemode whereas the MTRJ does not.
> > >
> > >PS: My feeling is the standards body's charter should be to specify a
> > >connector. However, there's too much rhetoric in the
> > procedure. Therefore
> > >it's difficult to choose the best solution.  Inevitably the
> > real winner/s
> > >will come forward. Conclusion: Choose a connector at the
> > standards level as
> > >it can expose good points of each solution.
> > >
> > >Chris Simoneaux
> > >Picolight
> > >
> > >-----Original Message-----
> > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > >Sent: Tuesday, July 18, 2000 12:09 PM
> > >To: Jonathan Thatcher; HSSG_reflector (E-mail)
> > >Subject: Re: Optical Connectors
> > >
> > >
> > >
> > >Jonathan,
> > >
> > >In spite of what Lucent wants, the LC connector does not
> > have the market
> > >support that MTRJ does.  MTRJ also has a smaller form factor
> > than does
> > >LC.  I don't like and am specifying the non-use of LC on
> > transmission gear
> > >because of the fragile "lock" tab that is on the connector.
> > >
> > >Thank you,
> > >Roy Bynum
> > >
> > >
> > >At 08:48 AM 7/18/00 -0700, Jonathan Thatcher wrote:
> > > >I have opened this thread to continue the discussion on optical
> > > >connectors. So far (what has come into my reader), we have
> > the following
> > > >comments:
> > > >
> > > >-----------------------
> > > >"Bill Wiedemann: Regarding 850CWDM we are planning to make first
> > > >implementations with duplex SC moving to LC with small
> > form factors. Our
> > > >expectation is that small form factor with LC could be
> > available a year
> > > >from today. "
> > > >-----------------------
> > > >"Jim Tatum: I would assume that 802.3ae would do the same
> > as 802.3z, and
> > > >NOT specify conectors. "
> > > >-----------------------
> > > >"Ed Chang: There are so many different form factors, and
> > connectors, which
> > > >even the GbE and Fibre Channel market can not get consensus."
> > > >-----------------------
> > > >
> > > >If we review the 802.3 Ethernet specification, we see that we have
> > > >identified connectors for each variant (I don't remember
> > an exception).
> > > >For example:
> > > >7.6.2 AUI Configuration cable
> > > >9.9.5.2 Optical for repeaters
> > > >...
> > > >38.11.3 MDI = Duplex SC for GigE Optics
> > > >39.5.1 MDI = Style 1 (DB9) and Style 2 for GigE Cu
> > > >
> > > >While I remember no rules that require us to do so, it
> > seems obvious that
> > > >there exists a precedent which should guide our decision.
> > > >
> > > >In 802.3z, we specifically took a vote to avoid connector
> > discussions
> > > >("connector wars")**. We could do the same in 802.3ae. If
> > we did, I would
> > > >argue that we would, effectively, be retaining the duplex
> > SC optical
> > > >connector specified in clause 38.
> > > >
> > > >My PERSONAL preference would be to specify the LC
> > connector. Rationale:
> > > >1. There seems to be an overall inclination to move in
> > that direction.
> > > >2. It sets the stage for some kind of "Small Form Factor" 10 Gig
> > >transceiver.
> > > >3. I don't think that it would negatively impact the cost of the
> > > >transceiver in the 2002 (standard completion time frame).
> > > >
> > > >As CHAIR, I don't want to use up any cycles on this. If there isn't
> > > >sufficient consensus to agree on an alternative to the SC,
> > we should just
> > > >adopt the SC and move on.
> > > >
> > > >jonathan
> > > >
> > > >** In reality, this was bumped up to 802.3 because neither
> > I (sub-chair
> > > >for PMD) nor Howard (802.3z chair) wanted to use precious
> > committee time
> > > >for the discussion.
> > > >
> > > >Jonathan Thatcher,
> > > >Chair, IEEE 802.3ae (10 Gigabit Ethernet)
> > > >Principal Engineer, World Wide Packets
> > > >PO BOX 141719, Suite B; 12720 E. Nora, Spokane, WA 99214
> > > >509-242-9000 X228; Fax 509-242-9001; jonathan@xxxxxxxxxxxxxxxxxxxx
> > > >
> >