Author Ian MacMillan from Interphase noted that: "The AdvancedMC dot specifications were created to define AdvancedMC port usage optimized to the different AdvancedMCs' functions. However, these AdvancedMC dot specifications make conflicting use of AdvancedMC ports."
Has this problem been solved, with the larger question being, have similar problems been solved and what does that mean for the AdvancedMC market? Ian refers to "taming the flexibility beast” Is it in the process of being tamed and what will result from that? What are your suggestions for taming it if it has not been tamed?
As with any standard, it takes a gestation period to take root, to get the usage standardized, and for people to understand how to leverage it and so on. One of the things people try to do, including us, is that when we build a standard we want to try to make it general purpose to accommodate multiple usage models, and that causes the challenge. So if you have different usage models, you have to have solutions that cater to different usage models and usually a couple of standardized methodologies evolve. I’ll use an example to illustrate the point: if you look at the AdvancedTCA standard, which has been around for some time now, among the fabric interfaces there was PICMG 3.1, .2, .3, .4, .5 all the way up to StarFabric and everything, however, if you look at where the industry is today, the majority is Ethernet and even in that we see a significant consolidation around 10 Gigabit Ethernet. This is just a normal process and you have to take that into account with any standard.
Coming to the specifics of the AMC.0, it is going through its phases. Dot-Zero got adopted about a year back, and there has already been an ECN to that Dot-Zero that got ratified in December. The ECN changed several of the original definitions, including the terminology, and sizes. We used to have full-height, now we have full, mid, and half size. These are to be anticipated and it is just a common practice in standardization.
Now the AdvancedMCs are getting quite popular, and the usage models have evolved. There are still areas that are in flux and it has to do with how you take an AdvancedMC and carry traffic from the AdvancedMC to the base board and AdvancedMC to the backplane. In the AdvancedMC there are two primary functions: one is to put it into an AdvancedTCA carrier board, and the other to plug it into a backplane, and the AdvancedTCA carrier board fits within the AdvancedTCA standard. However, plugging AdvancedMC into the backplane will sort of morph this into MicroTCA. The advantage of this approach is that you use the same AdvancedMC and you get more volume, more economy of scale, more reuse. To answer your question, yes, there are new usage model and usage model variances that we see, but we do not see them as impediments per se, we see them as normal parts of evolution.
RadiSys has quite a few AdvancedMCs that we have developed and we also have carrier blades, we are also looking at MicroTCA and taking all this into account. Each application needs a little bit of work to make this work.
Author George Kontopidis from NMS noted: "AdvancedMCs will most likely replace proprietary functional modules at a high enough volume so that the economies of scale and their ubiquitous use in the telecom sector will drive costs to commodity levels."
Is this happening? Why or why not?
I will provide a little bit more context. I think the common misperception concerns the definition of “commodity level.” I think the way we internalize it is: You get more use, reuse, economies of scale appropriate to the functionality that you are putting in; that does not necessarily translate to commoditization, because typically commoditization means of low value, and that is hardly the case, because some of the AdvancedMCs and the functionalities that are being put on are fairly standard and fairly sophisticated. The advantage is that you get the modularity and common use across multiple platforms.
For example, there are several AdvancedMCs that have fairly significant processing function both inline, either security, or wire-speed packet processing, or something like that, we do not expect them to be commoditized to the point where you find them at Fry’s. It is just that the functionality is standardized and you get the sophistication with the ability to reuse.
Q: What is the best way for a system designer to capitalize on the concept that mezzanines are the main functional units, that the daughterboard is now the motherboard if that is one way of putting it?
It is best for system designers to take a more holistic point of view. If you do this top-down approach, and work your way to the modules and functions, therein lies the effort to identify, what are common modules, what are reusable modules, and how do you connect them and so on. Now having done that, you still have to prove it from bottom up, so this is one of the things that RadiSys did fairly early on in our planning and strategizing, we took a top-down and a bottom-up approach with AdvancedTCA. Using this approach, we identified common building blocks that are either AdvancedTCA level, or mezzanine level, or for that matter MicroTCA level.
If a system designer takes more of a platform or a system architecture approach, then takes the next step of partitioning the architecture to the right functionality, and finally to modularizes those functionalities, then they will be able to keep the system perspective yet still identify the right modules without messing up the data flow and the architecture. Ultimately people are building boxes that can give them a significant price/performance edge. If you do not take more of the holistic system approach, then the potential for going forward with the design and getting the system integration and then running into a performance issue and some kind of optimization issue is very high.
This is one of the things that RadiSys differentiates on. If you look at our AdvancedMCs, if you look at our platform – whether AdvancedTCA or MicroTCA – we tend to come at it from:
• Here is an application like a media gateway,
• Here are the modules and mezzanines that we built
• Here is how you use them
We can show you the data threads through the whole path without performance (degradation) and bottlenecks and other issues.
This is also how we recommend the system architect look at it. Many of my meetings with the customers are to engage on that level and get them comfortable with the way we have conceptualized the architecture, get input from them on conceptualizing our architecture.
Q: How have you addressed specific requirements through this process?
We tried to categorize applications in two broad classes: one is more server-centric and the other is more user plane or data plane-centric. The data plane-centric one tends to be the likes of media gateways, or an RNC, or something along that line. The server-centric one tends to be more call servers or application servers and so on. If you look at applications from this point of view, you can get to: “What does an RNC do?” and we went through the process of (looking at) the anatomy of an RNC or a media gateway and just like our customers do their architecture and design, we went through that exercise: what does it take to build an RNC? You need a switching plane, you need compute blades, you need packet-processing elements, you need line cards, etc. and in the process we were able to identify various requirements for many of our building blocks. For example, we needed next-generation equipment or we wanted to go with 10 Gigabit Ethernet (GbE) capable so that we can enable 10 gigabits of performance throughput and things of a similar nature.
So by going through this process and engaging with the customer, we were able to identify many of the key requirements, whether it is security processing or it is just packet processing, or time-sensitive like a TDM legacy related issue or data flow issues
We used this same process for the server-centric application, where we identified some of the unique requirements in the next generation equipment, whether for IPsec encryption, or load balancing, or packet processing, to terminate certain flows so you can distribute them to the compute clusters and get your tasks done. This relates to looking at it from the top down and building it from the bottom up.
Q: How does this differ from what a competitor might have done?
RadiSys takes more of a platform approach. If one were to try this from a building block only, it is hard to step back and look at the big picture. Fortunately, we are focused on more of the platform, so that is clearly one area where RadiSys differentiates itself from a competitor who is primarily a building block provider. Many players in the ecosystem are building block providers.
Compared to another platform provider, our value proposition tends to be more about the choices that we make – whether you use multiple 1 Gigabit Ethernet for your fabric or 10 GbE for your fabric, or which processor architecture and how you address security and line cards, redundancy, and things like that. We tend to do it at different levels, and depending on the competitor we try to differentiate.
Q: Will TDM legacy be a factor for much longer?
I would not say there is a universal answer; the networks that are in place are not going to be changed overnight, nor are they going to be completely eliminated anytime soon. Extensions and upgrades to the network will take place, and those typically come by the way of various network elements such as improved higher performance or integration and significant functionality that goes on top of existing networks.
On the other hand, new network elements are coming on the scene because of the new infrastructure and applications that are coming together, and these are oblivious to the existing legacy. So if you are a designer of a network element that needs to connect to an existing or legacy network, then there is no choice but to accommodate those kind of TDM-related questions. If one happens to be building a new network element, there may not be constrains with such issues.
If you are doing something in WiMAX, you are more likely not doing anything with TDM. If you are doing something with media gateways, most likely you have to deal with TDM.
Q: Are there a number of approaches to dealing with legacy?
With something like TDM, there are multiple approaches. For example, I-TDM. The approach depends on the overall system architecture. This is an area where the system architects would differentiate. From the RadiSys point of view, we try to take a neutral approach so we can build in either [I-TDM or RTP based transport.] So we build in ways of implementing I-TDM and ways of doing it without I-TDM. It is not easy to delineate every specific item.
Given SCOPE activities in terms of MicroTCA profile and the ensuing implications for the AdvancedMCs and the usage model, there are some recent changes that affect the whole Advanced Mezzanine ecosystem
There is a bit of a divergence in the usage model that will take some time to sort through. The divergence has implications on the business side as well as on the technical side.
Consequently it may end up being more costly, because you may build in a 10 Gigabit connector, you may build in fairly high-end packet processing or application processing and that is not going to be very cost effective. The other end of the spectrum is you are trying to build more of an access device, which has more modularity and cost effectiveness and in that situation, performance is not as high a priority, so you can build it based on one gigabit and not as much high availability and redundancy
The industry will have to come to some sort of understanding, because it is not practical to have two of everything to cater to these. For example, one AdvancedMC with one gigabit everything, another with high-end performance and so on.
When organizations like SCOPE define the profile, there are ripple effects. This is a normal process of standardization.
We will find this dichotomy on all the limitations, where you have certain usage models, and it will be reflected in the AdvancedMC design and standardization even to the degree of what an AdvanceMC it is; it may be a sophisticated Macintosh AdvancedMC or it may be just a data acquisition AdvancedMC.
Q: How do you see AdvancedMCs evolving?
The way I see AdvancedMCs evolving is there will be two classes of AdvancedMCs that are inclusive of I/O, and one will tend to the lower end of the spectrum and the other will be high-end processing. When it comes to I/O, three or four years from now, most everyone will think I/O should be primarily Ethernet and Gigabit Ethernet.
I am not saying E1/T1 and STM-1 will go away, but the dominance of Ethernet will be much more accentuated in three or four years timeframe, so now you will have variances of one gigabit or 10 gigabit or maybe even higher. I do not know of any technology that has argued with Ethernet and won.
Q: Will there be a push for 10 gig on single pair?
We do see that coming out; we have been looking at it and our prediction is that that is two to three years out. And if you look at most of the applications, 10 GbE is sufficient bandwidth for 80 percent of the usages, and two to three years from now, that will expand and will challenge the higher end. To be able to do 40 gig, you have to go to 10 gig serial and you have to be standardized on PICMG and the backplane. IEEE is already doing some work in that area, and it will eventually find its way into PICMG.
Q: Will port usage settle down?
I do see this usage model getting simplified. By now most everyone is sort of expecting AMC.0 and AMC.1 to be GbE and fat pipes. We are getting more focused in terms of what is going to be there, and as soon as the ripple effect of ECN 002 gets settled down on MicroTCA and so on, I think we will get civilized. My prediction on the time frame for that is: MicroTCA 1.0 will get an ECN, it will be this year and things will settle out.
Q: The thermal and stacking problem needs to be addressed.
The thermal problems are going to be ongoing. I remember in the early days of AdvancedTCA, people were concerned about the 200 W and how you pushed the high-end processors and so on and it some time for people to work those out, and with the AdvancedMC, we see common usage of full size and mid size. Mid size and full size are the two that we see dominating and even there, RadiSys anticipates mid size to be the predominate [size], and if you look at all our AdvancedMCs, we are pretty much mid sized across the board because that’s the common denominator we see for a multitude of AdvancedMC types, including disks and I/O – the mid size has the appropriate amount of space.
So the thermal issue of packing four AdvancedMCs in a single slot AdvancedTCA board is something that will take more study. We designed our carrier card with four slots and we have done thermal modeling and published guidelines on how to work it. I am sure others have done the same. And I do not think there is a universal answer on how it is going to be because I think it is codependent on what type of AdvancedMCs you put into them and how they affect the airflow.
Q: Do you see the predominance of AdvancdedMCs in MicroTCA, the predominance of AdvancedMCs in AdvancedTCA, or elsewhere?
AdvancedMC usage today is in AdvancedTCA already. It is here and it is going to stay. People are trying to find a way to reuse them in MicroTCA in one of two or three applications. The predominate one that is getting a lot of front-end work is military and military networking and, as you already pointed out, SCOPE is taking a active part in the telecom use in outdoor equipment, so WiMAX basestations and some of the other access boxes will probably get the AdvancedMC usage. Now to answer your predominance question, that depends on where is it deployed and the numbers associated with where it is deployed.
In sheer numbers, Access exceeds Core and Edge. And that is the way it is going to be. Now do you need 10 Gigabit in the Access? Probably not. So, I don’t know anyone who has a crystal ball on how that is.
Q: MicroTCA could take a number of paths.
There are two diverging scenarios that have to be worked out on MicroTCA. One ends up being the Central Office site where this is just as robust, just as redundant, just as performance-oriented as AdvancedTCA – it just happens to be the lower end of it.
Whereas the other scenario argues for more access, volume, outdoor and deployment, simpler systems, one Gigabit, and there’s no sophisticated clocking and that kind of stuff.
The typical applications would be Access. I don’t think we need to label them, they tend to be base stations and probably low-end media gateways that is still arguable as to what type of gateways those are.
On the Central Office type, the core element will need a lower end version of or lower capacity version of equipment.
We don’t know which is going to dominate – by two to three time frames, we will have a better idea of how this thing is taking root and what direction it is leaning.
Venkataraman “VP” Prasannan is Senior Director, AdvancedTCA PLM, RadiSys.
