Comments
clrmoney
4/9/2016 1:15:27 PM
User Rank Platinum
NFV
I think that this need to get this resolved relating to data management and virtualization tools for our computers and processors etc.
jbtombes
4/11/2016 3:45:29 PM
User Rank Platinum
several minutes delay?
Absent Doctor, notification of failure to the app manager takes several minutes? Wow. It's good that someone - or some group of someones - got around to addresssing that delay. So now notification can occur within a second. How long before the repair takes effect?
JohnBarnes
4/13/2016 7:53:17 AM
User Rank Platinum
Cool video from a business standpoint ...
... for those of us on the tech/biz interface, it would be great, though, to see some kind of packet simulation: error happens here, how does it become local message? How does local message transfer/convert upchain, and how does fix propagate downward?
I realize that our engineering writer here was probably already driven half-mad by all the cool things they didn't give him space to explain, but the right animation/simulation would help a great deal for those of us trying to follow (in a naive, semi-technical way).
JohnBarnes
4/13/2016 7:56:34 AM
User Rank Platinum
If I'm understanding this correctly the basic structure is hub and spoke ...
... with hubs defined at an arbitrary network/junction distance from the rim of applications. I'm just wondering if it would be possible to devolve more and more of the analysis/repair functions down into local processors and have them report back that they found a problem and fixed it rather than requiring the whole problem-identification-attempt-solution-evaluation cycle to pass through the upper reaches of the pyramid?
Or have I misunderstood the architecture?
1 whole second
Is that good enough?
What's the current detection and failover time for VoLTE or even older spec voice ?
While the article doesn't explicitly state it, I expect that Doctor can handle n+1. Is that correct, or does it only do Active/Standy, ie 1+1.
Thanks for bringing this effort to light. If you hadn't pointed it out, we'd still be thinking that NFV had sub-second response times like people expect from transport networks.
Re: several minutes delay?
Yes, before notifications could take up to several minutes and it was not deterministic because of two stats pooling times in between.
The time for repairing can vary a lot depending on a number of factors that may be external to the virtual infrastructure management (VIM) platform, e.g. OpenStack. For instance, a recovery action could be, as presented in this article, switching to a standby VNF triggered by the upper layers (e.g. VNF, VNF Manager, NFV Orchestrator) and that takes milliseconds. We measured 103 milliseconds from active-standby switching action to recovery in an OpenStack testbed (Use Case #2 https://wiki.opnfv.org/download/attachments/5046291/20150730_doctor_demo_v6.pdf).
Another recovery action could involve actions to the VIM such as evacuation of the VNF/VM to another compute node – in this case, it could take up to seconds (we measured 58-second evacuation time in an OpenStack testbed; Use Case #1). However, for telco operation, switching to the standby VNF would be necessary before such evacuation actions.
Re: Cool video from a business standpoint ...
Re: If I'm understanding this correctly the basic structure is hub and spoke ...
John, you made a very good point!
Not everything needs to be reported to upper layer management entities. What could be locally repaired (e.g. a fan or RAID disk failure) can be locally repaired. The objective is to reduce the service downtime to zero. In the Doctor architecture, we have the Inspector module where an Operator can flexibly define what kind of fault it wants the VIM (e.g. OpenStack) to report to upper layer managements. It should be flexible and programmable to be able to reflect Operators policy.
We also need to consider the fact that in certain redundancy configurations, e.g. 1+1 ACT-SBY, local repairing may violate the ACT-SBY interdependency. Migration, re-instantiation, etc. type of recovery should not be performed without notifying the upper layer management. That's what Doctor tries to achieve. Based on the policy defined in the Inspector module, Doctor notifies the upper layer management about a fault so that the upper layer management can take necessary action, e.g., switch to the standby instance.
Re: 1 whole second
Theoretically and technically, n+1 is also possible. However, the fast notification feature in Doctor provides the upper layer management a mean to switch to a standby VNF as soon as it receives such fault notification. Now, a sub-second switchover is possible if the standby is a hot-standby. The upper layer management can then just switch to the hot-standby, and provided that Doctor sends a fast enough fault notification, the switchover can be completed in sub-second order. Assuming the standby in an n+1 redundancy scheme is a common standby node and not in hot-standby, fast notification from Doctor will not guarantee a sub-second level recovery. Well, that won't be Doctor's fault though :)
JohnBarnes
4/19/2016 7:24:47 AM
User Rank Platinum
Re: If I'm understanding this correctly the basic structure is hub and spoke ...
Carlos, that's a great solution made much better by the ability of individual organizations to decide the exact structure of reporting and control they want at each level, rather than trying to write a "correct" version for them ahead of time (the bane of any software buyer: the supplier who decided what would be "right" and imposed it). I assume it is also possible for users to change their minds more or less on the fly, so that if it becomes clear that higher levels don't need some information, or that they do, they can begin or stop recording data in those categories without having to redo the whole database?
|
|
Italy's 5G auction could exceed a government target of raising €2.5 billion ($2.9 billion) after attracting interest from companies outside the mobile market.
The emerging-markets operator is focusing on the humdrum business of connectivity and keeping quiet about some of its ill-fated 'digitalization' efforts.
Three UK has picked Huawei over existing radio access network suppliers Nokia and Samsung to build its 5G network.
Vendor says that it's its biggest 5G deal to date.
Verizon skates where the puck is going by waiting for standards-based 5G devices to launch its mobile service in 2019.
Orange has been one of the leading proponents of SDN and NFV. In this Telco Transformation radio show, Orange's John Isch provides some perspective on his company's NFV/SDN journey.
10/16/2017
Huawei Network Transformation Seminar
The adoption of virtualization technology and cloud architectures by telecom network operators is now well underway but there is still a long way to go before the transition to an era of Network Functions Cloudification (NFC) is complete.
The Small Cell Forum's CEO Sue Monahan says that small cells will be crucial for indoor 5G coverage, but challenges around business models, siting ...
People, strategy, a strong technology roadmap and new business processes are the key underpinnings of Telstra's digital transformation, COO Robyn ...
Eric Bozich, vice president of products and marketing at CenturyLink, talks about the challenges and opportunities of integrating Level 3 into ...
Epsilon's Mark Daley, director of digital strategy and business development, talks about digital transformation from a wholesale service provider ...
Bill Walker, CenturyLink's director of network architecture, shares his insights on why training isn't enough for IT employees and traditional ...
All Videos
|
On-the-Air Thursdays Digital Audio
Special Huawei Video
Tweet This