Pad 1310nm cross-connects?

Leo Bicknell bicknell at ufp.org
Sun Oct 20 20:14:59 UTC 2013


In a message written on Sat, Oct 19, 2013 at 07:33:19PM -0700, Chris Costa wrote:
> What are the opinions/views on attenuating short, 1310nm LR cross-connects.
>  Assume < 20m cable length and utilizing the same vendor optics on each
> side of the link.  Considering the LR transmit spec doesn't exceed the
> receiver's high threshold value do you pad the receiver closer to the
> median RX range to avoid potential receiver burnout over time, or just
> leave it un-padded?

With any optics, you need to go to the specifications.

I assume here you mean 10GbaseLR, although I will point out that "LR" is
ambiguous as there is also for instance OC192-LR.

I'm going to pick on Juniper specs, just because they were the easiest
to find with Google:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-10-gigabit-optical-specifications.html

And similar for 1000baseLX, the similar technology for GigE:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-1000base-optical-specifications.html

Note that for both 10GbaseLR and 1000baseLX the transmitter power range
is entirely inside the allowed receiver range.  They were designed this
way on purpose, to never need a pad.  An in-spec optic can never over
drive the receiver, even with zero loss.

Answering your question, I would never pad them.

Compare with for instance a 10Gbase-ER or 1000baseEX, 40km over
single mode optics.  In both cases an in-spec can exceed a receiver.
10Gbase-ER can transmit up to +4.0dBm, while the receiver needs
-1.0dBm or below.  When connecting them "back to back" a 5dB
attenuator is required to keep the receiver in-spec.  For any real
connections (over a fiber path more trivial than a jumper) a light
meter should be used, the value checked, and an attenuator that
places the circuit 1-2dB inside of the safe zone of the receiver
should be used.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131020/dc22a687/attachment.sig>


More information about the NANOG mailing list