Some classics can’t get a sequel. The Blues Brothers cannot get another mission from God after the mess they created pulling the band back together. Others are telling just one side of the story and leave you with a taste for more – or are even created as a part 1 out of a series.
We just recently submitted version 2 of the distributed disaggregated chassis (DDC) specification and had it approved by the OCP incubation committee.
The Original Distributed Disaggregated Chassis (DDC)
The original DDC spec was not a classic. Rather, it was well-defined to suit the particular needs and desires of its creator, AT&T. Some topics were deliberately omitted from the original spec to avoid further delay, and simply because AT&T decided that these issues should be handled in the future and not from day one. With so much innovation, both technological and operational, already covered in the spec, it wasn’t surprising that some items were consciously left outside.
The recent release of the v2 of the DDC spec included inputs coming from AT&T itself. Contributions also were made by ODM companies that manufacture the hardware and by DriveNets that implements the software running on the DDC.
Flexibility and versatility of the Distributed Disaggregated Chassis
From a hardware perspective, as DDC expands its penetration into more use cases and as ASIC technology evolves, the basic building blocks known as NCP1 and NCP2 are not enough to answer the varying demand. This is what triggered NCP3, which brings higher capacity, and NCP-Light, which brings a higher port count and better backwards compatibility to legacy equipment.
The software side of things is in fact closing a gap that was created by the disaggregated distributed model, granting capabilities that do not exist in a monolithic design.
Automatic Firmware Updater in a DDC Cluster
Dubbed automatic firmware updater, the mechanism inserted by DriveNets into the DDCv2 spec establishes a protocol between the network operating system (NOS) and the hardware white boxes. This protocol enables the firmware to update itself within the DDC cluster without mandating a change in the software version as well.
This is the basic principle of disaggregation but when applied over a cluster of devices, as opposed to alternative disaggregated solutions, this mechanism must be handled from an orchestration standpoint. It also must be done on a whole lot of boxes that are interleaved with one another and not on every box as a stand-alone.
The interface between the HW and the SW is an open standard definition implemented by the ODM providing the white boxes and read by the NOS provided by the SW vendor. This file being open also means that any newcomer joining the DDC ecosystem will also support this capability.
Track and Control the Upgrade of Various Components in a DDC Cluster
Well, so far we can say that DDC created a problem and eventually fixed it – so where is the exciting part? If you are indeed asking this question, give yourself two points for paying attention! And now for the answer…
Because we have an algorithm to track and control the upgrade of various components within a DDC cluster, it means we can upgrade the cluster in parts. And not only that – we can tap into every component being upgraded and provide a status of its individual upgrade process.
Let’s compare that to the well-known chassis model. This would be like upgrading a line card within a chassis to run on different software and firmware from the rest of the chassis while still working with the other components of the system! And the upgrade process of that single line card would be something you can track into its internal stages.
Why is this upgrade process important?
DDC is built to run multiple network functions on the same infrastructure. The first implementation of a core router is indeed a “first” because it was followed by the implementation of other router functions and non-routing network functions. If running several functions onto the same DDC cluster also meant that an upgrade would have to be applied to all these functions at once, it would deprive precious sleep from network admins around the globe.
Telco operators, and specifically their network admins, are looking for better control over their networks. Using black boxes means that they are kept in the dark in terms of understanding what’s going, monitoring the network, and troubleshooting problems. Visibility and granularity are key attributes in a network that these network admins are very happy to find and utilize.
Distributed Disaggregated Chassis is Enhanced With Router Functionality Definitions
Now here is a twist – DDCv2 is not really the second version. Somewhere between v1 and v2, we also saw definitions coming from the Telecom Infra Project (TIP) under the name Distributed Disaggregated Backbone Router (DDBR). This definition took the hardware architecture defined as DDC and enhanced it with router functionality definitions. Considering that v1 was a creation of AT&T, it didn’t include such definitions as these were not public info. What TIP has done is collect inputs from a group of operators so that anonymity of each operator is kept despite the inclusion of its requirements in a public list.
You could say that somewhere between “Despicable Me” and its sequel, we had a spin-off with unique contributors that created a storyline of their own. Go Minions!
Additional Resources for Distributed Disaggregated Chassis
Video
White Paper
Blog
DriveNets White Paper
Which Network Architecture Is Right for You