Transponder(less) Architecture

Hello friends, today I will touch upon how some innovations in silicon photonics and miniaturization of the transponder functions catalyzing the evolution of new transport network architecture. 

You can also read Transponder(less) architectures as architectures with "less/limited" transponder/s.

Every device, connection, and software code could be a potential point of failure in a network and keeping the # of components minimal to realize services is always a good idea. The new architecture with reduced components enables this design philosophy. 

Now let's see what do we mean by transponder "less" architecture. 

**I am using Transponder and muxponder interchangeably, read Transponder as (Trans/Mux)ponders.

In general, Transponders provided gray-to-color translation(for long-distance transmission), and muxponder aggregate many smaller services into a bigger colored pipe to transport over the optical transport network.

Transponder less architecture is the act of collapsing the features provided by the transponder/muxponder to another point/layer in the network. 

How is this possible now?

The main reason this is possible now is the miniaturization of transponder features into small form factors like CFP2-DCO and ZR/+. 

These optics have consumed the DSP and other optical analog functions provided by transponders thus eliminating the need for a transponder( generally fulfilled by specific hardware). 

IPoDWDM was something similar done in past but the solution required having a Transponder(like) hardware on routing boxes consuming slots on routing box and also interlocking the refresh cycles of routers and transport hardware( both having considerably different refresh cycles)

How would it benefit 

With commercial versions of CFP2 and ZR available many CSPs can take the advantage of these innovations to reduce the network cost and more importantly minimize the # of components required to realize the same service. 

In many metro and DCI where distance is limited (~30-80kms) many network connections can now be made with these new optics and some passive(or active) mux/demux blades without a need of deploying an entire transport line system. 

Apart from reducing the CAPEX this should significantly reduce the OPEX( limited power requirement, employee training, hardware spare), and the most important benefit in my view is a simplified network. 

Happy reading! Stay safe!

References:

CFP2 DCO optics 

400G ZR Optics

Customer is WRONG !

Hello friends, an apology for deploying a provocative title to catch your attention😉

All organizations aspire to "delight" the customers, quality is implicit and any slack in user experience can turn into an existential crisis for the product and organization. 

No one can escape accountability when customers are not able to consume the product/service for the problem the product/service was intended to solve but, 

what happens when customers discover a new workflow or configure/use the product in a way it was never designed or built 😟

Customer fault  -  A BIG NO 

Now how can you find these "unusual", "out of the order" workflows before they are reported by customers? 

Validation teams within an organization have the accountability to ensure these problems are found and fixed before the feature/product/service is available to the customer. 

For products having limited complexity and combinations, validating these negative scenarios can work( especially with the automated test suite) but for a multilayer,multi-component complex product/service this approach(find & fix) will not scale. 

Secondly, does it even make sense to spend time and resources in validating something which is not a revenue (💲💲)generating activity? 

What is a better approach? - "Mistake proofing"

One such mistake-proofing technique is "Poka-Yoke".  Poka ➡ "mistake", Yoke ➡"prevent"

Poka-Yoke is a process introduced by Japanese engineer Shigeo Shingo. The purpose of Poka-Yoke is to develop processes to reduce defects by avoiding or correcting mistakes in the early design and development phases.

Building a product that takes care of this unusual workflow in design and development is the best phase to avoid a humungous effort later( with the find & fix approach). 

All the cross-functional team's product owners, software architects, development, validation, operations & support team should come together during the design phase and plug all the possible entry points preventing any inadvertent misuse of the product/service by the end-user. 

"Remember Proactive is better than Reactive"