Service Provider Transformation
Juniper Employee , Juniper Employee Juniper Employee
Service Provider Transformation
LLDP Extension for Optimal End-to-End Optical Network Performance
Oct 21, 2017

In a linear optical network that contains multiple optical nodes, it is an operational goal to optimize the end-to-end optical network performance, measured by the receiving node’s optical BER (Bit Error Rate). And as time goes on, the receiving node’s BER can drift, due to factors such as the sending node’s transmitting optical power drifting, ambient temperature variation, equipment aging, etc. While some factors are difficult to control, such as ambient temperature variation and equipment aging, the sending node’s transmitting optical power is easily controllable and can be adjusted to compensate for the BER drifting due to other factors. So if we can continuously monitor the receiving node’s real-time BER, provide feedback to the sending node, and adjust the sending node’s transmitting optical power as needed, we can obtain the optimal end-to-end optical network performance.


The following diagram shows the relationship between the receiving node’s optical BER and the sending node’s transmitting optical power. There is a sweet spot at which the minimum BER is achieved.



This next diagram illustrates an optical network. Nodes 1 and 5 are integrated photonic line cards on two PTX chassis. Nodes 2, 3, and 4 represent inline optical amplifiers. They don’t terminate the optical signal. Their purpose is to amplify the optical signal so that the optical signal can travel longer distance between node 1 and node 5. Nodes 1 through to 5 are connected through bi-directional optical fibers. They terminate the OSC (Optical Supervisory Channel) between every node.

If node 1 knows node 5’s BER in a real-time fashion, it can continuously adjust its transmitting optical signal power to get the minimum BER on node 5; similarly, in the reverse direction, if node 5 knows node 1’s BER, it can adjust its transmitting optical signal power and get the minimum BER on node 1.


How can this be done? Puneet Jain, Domenico Di Mola, and I came up with an innovation that achieves this goal in an elegant way:


  • All nodes in the network run the LLDP (Link Layer Discovery Protocol). The LLDP application on each node periodically sends LLDP packets to its immediate neighbors through the OSC OC3 data path, which is terminated between each node. Each node’s application will extract the LLDP packets from the OSC OC3 data path and read/process the LLDP payloads.
  • On top of the basic/standard LLDP TLVs (Type-Length-Value), an extension is made to the LLDP by adding organizationally specific TLVs to LLDP payloads. The newly added organizationally-specific TLVs contain BER.
  • If a node doesn’t have a cross-connect (such as node 1 and node 5), it will insert its own BER in its outgoing LLDP TLVs. If a node has a cross-connect (such as nodes 2, 3, and 4), it will take its cross-connect’s BER in the incoming LLDP TLVs and send them to the downstream node in its outgoing LLDP TLVs. In the above case, node 1 (no cross-connect) will send its BER to node 2, node 2 (with cross-connect) will send node 1’s BER to node 3, and so on, and eventually, node 5 will receive node 1’s BER. Same happens in the reverse direction: node 1 will receive node 5’s BER.
  • After node 1 gets node 5’s BER, node 1 can use the BER as feedback to adjust its transmitting optical power and achieve the best network performance; similarly, node 5 can use node 1’s BER as feedback to adjust its transmitting optical power and achieve optimal performance.
  • LLDP sends LLDP packets periodically. So the end nodes steadily and continuously receive the other ends’ BER. This end-to-end optical network performance optimization is an ongoing process.
  • Besides BER, other optical control information, such as received optical power readings, can also be added to the LLDP’s organizationally specific TLVs for other control purposes.

This invention is a beautiful way to achieve the optimal end-to-end optical network performance, as LLDP is a simple and light-weighted protocol, and is already supported in Junos. It blends packet network (LLDP with extension) with optical network (OSC OC3 data path) very nicely. Moreover, it has been granted as a US patent:


U.S. Patent No. 9,755,956

Filing Date: November 16, 2015

Issue Date: September 05, 2017


Inventor(s): Dai Song (, Domenico Di Mola (, Puneet Jain (

Sep 25, 2017
RIchard A Steenbergen

Why LLDP? I can see a reasonable argument being made for communicating information between directly adjacent nodes (e.g. nodes 1-2), but for nodes 1 and 5 to know about each other, you'll have to flood optical information for the entire network to every node. LLDP seems like a terrible way to do this, since it's designed for adjacent node communication, and has no inherent mechanisms for such global flooding or for controlling the scope of such flooding.


It seems to me like an extension to OSPF/ISIS (similar to the TE extensions) would be an infinitely cleaner and more scalable way to handle this. For what you're trying to accomplish here, global flooding of BER information within a specific administrative domain, this seems like a much better fit. That said, I can think of a lot of other intereting applications for LLDP-based optical extensions. Imagine for example if you could easily see (via LLDP) the received optical power on the far side of the port. This would be a huge win for operational troubleshooting, especially when the far side is outside of your administrative control. I'd love to see you guys pursuing something like that as a standard, but I'm incredibly skeptical of the mechanism described above for BER flooding.


Sep 25, 2017
Jeff Tantsura

I agree with Richard’s comment, LLDP is not the right protocol to distribute state/meta-data in a network.

I’d rather look at IGP/BGP-LS extensions, IGP would provide flooding facility, while BGP-LS a NBI.


You could take a look at *MSD* IGP/BGP-LS drafts and take a similar approach.





Sep 25, 2017
I agree with Richard and Jeff, why LLDP?
Could you explain?
Sep 26, 2017
Juniper Employee

Thank you all for your comments. The optical amplifiers (nodes 2, 3, and 4) don’t run routing protocols. They behave as switches. So LLDP is the choice in this application.

Sep 26, 2017
Distinguished Expert

LLDP makes perfect sense IMO - the BER data is only relevant for the point-to-point link the information is propagated on.


I can't think of a good reason (which isn't to say there isn't one) you would need to know the BER data of a node that you don't have a direct adjacency with (adjusting your local TX power isn't going to affect it), so IGP/BGP-LS seems like overkill - we already have knobs in Junos to switch away LSPs when signal is degraded.


That said I think Richard's request for Far-end RSSI being sent back over LLDP would be a killer feature!

Sep 27, 2017
RIchard A Steenbergen

LLDP is designed to transmit basic information between two directly adjacent devices. They're talking about using LLDP to propagate information between non-adjacent nodes as well, such that 1 and 5 are talking to each other by having 2 copy 1's data when forwarding to 3, and having 3 copy 1 and 2's data when forwarding to 4, etc. That's not only a hideous misapplication of LLDP from an architectural standpoint, but it introduces all kinds of questions about scalability.


Actual routing protocols are specifically designed to manage the control the flooding of information between non-directly adjacent nodes, so every device can know about the properties of every other device without every device. Even a fairly low-intelligence amplifier should be perfectly capable of speaking a simple routing protocol like OSPF or ISIS over the OSC control channel, the only way it gets dumber than that is if it's not capable of speaking over an OSC at all. That's how other vendors like Ciena handle this, the optical devices are all speaking OSPF to each other through the OSC, which gives you a nice simple scalable way to communicate optical management information between any devices.


The only reason this is even remotely less than "avert your eyes children!" hideous is that it seems very limited in scope, constrained to one specific path between a pair of transponders, rather than network-wide flooding. But what happens when amplifiers 2->3->4 are carrying say 80 different DWDM channels, from many different transponder pairs? Coordinating the level of amplification between 2, 3, and 4 makes total sense, you're only operating on the aggregate power level. But how do you handle this when there are more than a single pair of transponders communicating over your amplifiers? What do those LLDP packets look like then?


I'm also a little confused how you're getting this information into the OSC in the first place. There's definitely no way you could be doing any LLDP snooping on the actual transponder signal at an amplifier level, so are you having each PTX transponder also speaking into the amplifier via an OSC channel? That sounds absurdly wasteful and difficult, plus I'm sure you don't want to have a 128-port switch on every amplifier. Wouldn't this be the point at which you'd want to have a real routing protocol, so you could have every actual node (regardless of individual channels) knowing about every other node, using standard and well-proven IGP principals and controls?

Oct 3, 2017
Distinguished Expert

Okay Richard, so now that I've re-read the above I see where you're coming from - it appears I completely missed the part about nodes 2,3 and 4 actually participating in LLDP and all via an OSC (so basically most of the key points of the article ; )


In my mind (and how I originally thought this was being designed) was that the transponders in 1 and 5 were LLDP neighbours (over their lambda, NOT via an OSC), so that the their BER information was link-local and relevant and any intermediate amps would completely ignore to the information since, as you say, they only deal with aggregate power across all channels anyway.


PS: I quite enjoyed the Podcast you did on Software Gone Wild - well done!

Oct 20, 2017
Ben Liv

Apart of the fact that amps at 2,3,4 could amplify other channels, the real problem is (gently speaking) not always about the opt power of 1.


You decrease the power only when dealing with non-linearity. And this is relevant only on coherent channels.

If you lower the power you could face the next ROADM too low to get equalized with other channels.

You cannot just increase the power as if the problem is fiber degradation on 2-3 span, you increase and make the amp 2 saturated.

And so on...


Optical network is a whole world of its own. Most probably a single node' processing power could not calculate all the relations of the components of this optical path and all the related pathes using these components as well. Unless you invest 15b$ on heavy processing power of your routers and it's idle because of SR, external PCE and SDN, and you need to justify the investment and the high price per port.

This is why you don't need this information to be shared on any node nor need to send it via this mechanism.


You rather need to separate the L2+ domains from L0-1, set up a separate SDN controller, get it via any standard or proprietary protocol, and calculate L0-1 offline. And let the controller to calculate all the ~8 parameters of any optical component apart of optical power.

Oct 21, 2017
RIchard A Steenbergen

Right, with a DWDM system the only useful thing you could do at the transponder level is tune the TX power levels such that it stays in balance with the other channels at the first line system element (which is probably easier and cheaper than putting a VOA or WSS in front of every channel). In a modern world of disaggregated open line systems and alien wavelengths, having automatic power balance at the transponder level would be extremely interesting. You could technically do that with my previously mentioned concept of LLDP-based optical power information exchange, but it'd sure be better if you didn't have a hard-coded Ethernet requirement in the process. Smiley Happy

Top Kudoed Authors