All the Best Wishes for 2011
The Xelerated Xpress blog will now make a short holiday break. Looking forward to a very interesting 2011.
| Comment
The Xelerated Xpress blog will now make a short holiday break. Looking forward to a very interesting 2011.
| Comment
Light Reading reports from London that packet-based mobile backhaul is no longer limited to Asia, but is also being deployed in large volumes in Europe. Still many mobile operators keep E1 services to synchronize their base stations. Are they out of sync? Or are vendors still pulling the technology together?
| Comment
Defining OAM, Part 3 of 3. Please check out my earlier posts on defining OAM and OAM on NPUs – not only about CPU off-load.
As service providers take on new technologies, they spend a significant amount of time and resources adapting the new infrastructure to their method of operation. This means fine-tuning service provisioning, monitoring network status and having tools for consistent fault protection and mitigation. As with most things, standards is one thing, but what purchased products really can do is yet another. Designing the OAM functions therefore is as delicate as engineering the user plane for the right performance, features and availability. You need to analyze what functions you have, what you want to maintain, and what new capabilities you’d like to see across the complete network. Purchasing equipment that doesn’t meet requirements is as bad for OAM as it is for user data services. You end up compromising functions against performance and designing against the least significant denominator.
System vendors know this. Some have learned it the hard way when their products can’t support the required model of operations by some of they’re potential service provider customers. Others by owing the luxury of incumbency; once an operating system is ‘in-designed’ it becomes ‘approved’ by the service provider. This puts vendors with running contracts in a strategic position where they may advise new features that are planned for in their future releases of the OS, and are well supported by the underlying hardware. Competitors not in this position struggle to catch up and get their functions approved.
Here is why programmability matters for OAM. If the hardware is not flexible enough to develop a strong and agile OAM and service provisioning roadmap, the product will fail to concur with new market territory. Even aggressive pricing can’t compensate for a rigid hardware. Addressing the service provider requirements with a re-spin of the hardware is not very attractive either. An unproven vendor with an unproven line card is just too much uphill to win the deal.
It is rather common that network elements such as switches and transport systems are designed to perfectly meet a large incumbent carrier’s set of requirements. This customer may very well be significant enough to justify the design. But in a global market with global standards all systems have a larger market to address. But it can only be addressed with flexible OAM functions.
For a successful global expansion, Carrier Ethernet products need programmable OAM.
PS. Interested in how Xelerated technology can be used for OAM? You can find more information on the technology section on the Xelerated website.
| Comment