BICC: A "Temporary" Solution to a Real Problem?
Posted by Jiri Kuthan on Thu, Dec 31, 2009 @ 07:56 AM
Recently BICC became the protocol of choice for several wireless operators deploying VoIP trunking backbones. For many it is perceived as a temporary workaround solution.
What I'm asking myself is whether such a temporary solution might possibly stay for longer?
In the IP world we have quite a few examples of "temporary solutions" that have featured momentary advantage, real or perceived, and which have stayed with us. I consider NATs (Network Address Translators) the most important example. NATs translate IP addresses in packets from/to the public Internet to a private address range. This allows for the sharing of a scarce public IP address among multiple devices (real problem) and hiding these devices better. The latter is considered a perceived security feature as the same functionality can be implemented in firewalls without the side effect of changing IP packets. The changes to IP packets can cause dysfunctional applications, errors in security protocols and limitations to redundancy schemes. (See RFC3027 for more).
In the IETF standardization body NATs have therefore been considered as architecturally unsound, or even evil architecture. It shall be added that guarding an "architectural spirit" has allowed Internet technology to develop, stay manageable and prevail. In this spirit the "right answer" to the problem of scarce IP addresses has been proposed: IPv6. NATs have been labeled as a "temporary solution". However, many years later it is as hard to find a user without NATs as it is a user with IPv6. NATs are to stay and the fate of IPv6 is all but clear.
I think a similar scenario is occurring with Session Border Controllers (SBCs). They solve real problems such as NAT difficulties that have bubbled up to the application layer. They solve temporary problems such as interoperability of immature implementations. They also solve perceived problems -- we know yet too little about what security problems are out there but SBCs offer an answer already. However, the coincidence of solving real problems and claims they are of a temporary nature seems to me remarkably similar to NATs. I think this may lead to a similar ending, with SBCs staying and solving the problems that are compelling and permanent. Certainly, re-connecting disjoint IP addressing spaces would be one of those.
What is the next controversial architecture to stay? NATs are definitely staying, SBCs keep "temporarily" reconnecting disjoint address spaces. The capability to solve compelling problems has prevailed over desires for a consistent and presumably easier-to-maintain architecture. Recently, several BICC deployments have emerged -- is BICC going to be the next protocol that is "architecturally unsound", yet here to stay?
The BICC architecture is very special-purposed and therefore of limited applicability. Basically, it inherits encoding from ISUP, and transports it over IP or even ATM. Development beyond the purpose of trunking began stalling at "CS3" (Capability Set 3). By any measure it is a real hybrid vehicle.
Still, as unappealing as it sounds, deployments are reported and continue to solve the MSC trunking scenario. We can soon witness again an architecture solving a real problem and prevailing over "grand architectures" in specific use cases.
It appears that the notion of hybrid vehicles is not exclusively owned by the automotive industry.
Happy New Years!