The problem of RCA (root-cause-analysis) is a real challenge: in my opinion, the only way to correlate applications/services to the underlining infrastructure is to have an "entity" providing information about "which service is running on which VM".
Probably the only "entity" with such knowledge is the Service Orchestrator but...what is "a service" ? Thinking to a Virtual EPC, it can be composed by many VM each implementing a component (MME, P/Gw, HSS, PCRF...) that should be mapped on the respective piece of hardware.
A "VoLTE service" requires many other components to run (I am referring to the logical components, like vEPC and vIMS), increasing the complexity of determining if a fault in the lower hardware is affecting (and how) the overall service, or the RCA of a possible quality degradation. Example is the following: I can easily detect a decreased MOS related to the voice quality but find the RCA an be extremely challenging...
BR
------------------------------
Angelo Baccarani
Product Manager - NFV Service Assurance
Empirix - Italy
------------------------------
Original Message:
Sent: 09-24-2017 20:44
From: David Redwine
Subject: multi-vendor service chain
In Enterprise and sole provider carrier networks, a contiguous network topology allows for automated topology discovery, and root cause fault correlation across the network transport model, as well root cause fault detection across the full stack Application/compute/storage/access/network model.
In an NFV/SDN multi-vendor service chain, how does TM Forum plan to maintain the ability to perform root cause fault correlation from end to end? I.E. when intermediate services fail in the service chain, how do you pinpoint the transport service failure/owner/component when multiple entities/companies only provide one or more pieces of the service chain?
------------------------------
David Redwine
Ai4Cloud
------------------------------