Page Comparison

SDC

• Define import CSAR format
• Define export CSAR format

• Define E2E service CSAR format

• Define WAN underlay network using Underlay Network Service template
• Define WAN overlay network using Overlay Network Service template

• Using SDC GUI to design VoLTE E2E service with vEPC, vIMS and WAN overlay and underlay networks

SDC

• SDC support of service instantiation sequencing by using Dependency construct

SDC can support Dependency construct already

• Support new node types used by VoLTE VNFD

• Time is very tight for SDC team because the design is finalized very recently

• Obtain vendor's VNFD
• Verify vendors' VNFD can be onboarded by ONAP

• Design network for vEPC
• Define different design options
• Work with VNF vendors to figure out the network design for vEPC

Need to discuss with integration team and come up with different design options

• Design network for vIMS
• Define different design options
• Work with VNF vendors to figure out the network design vIMS

• Support ESR registration for VIM, SDN DC controller, SDN WAN controller, vendors' SVNFM and EMS

• Add new Network Service vertex in A&AI

• Design a new SO NB interfaces for VoLTE E2E service LCM
• Design and implement workflow for VoLTE E2E service
• SO can use Dependency construct to implement service instantiation sequencing

As we discussed with deployment team in CMCC, parallel deployment of VNFs will hit VIM performance bottleneck.

Have sent Yan Yang an email asking about the need to support VNF instantiation sequencing

[Yan] VF-C didn't  receive the requirements from the VNF vendor that one vnf depends on the others.  So in the R1, VoLTE case don't need to define the VNF sequence.  In the futrue, we can cooperate with SDC team to do it if needed.VNF instantiation parallel is a streth goal in VF-C.

• DG for WAN underlay network
• DG for WAN overlay network
• Integration with SO

An example given by Guangron, it contains 2 rules. CLAMP can only support 1 rule in R1.

In email attachment sent by Guangrong on 9/7, file holmes-rule-mgmt-componentspec.json defines:

"parameters": [
{
"name": "holmes.default.rule.volte.scenario1",
"value": "package dcae.ves.test\nimport org.onap.some.related.packages;\nrule\"SameVNF_Relation_Rule\"\nsalience 120\nno-loop true\nwhen\n$root : VesAlarm(\n$sourceId: sourceId, sourceId != null && !sourceId.equals(\"\"),\nspecificProblem in ( \"LSS_cpiPCSCFFailReg(121297)\", \"LSS_cpiSIPRetransmitInvite(120267)\" ),\n$eventId: eventId)\n$child : VesAlarm( eventId != $eventId,\nCorrelationUtil.getInstance().isTopologicallyRelated(sourceId, $sourceId),\nspecificProblem in (\"LSS_externalLinkDown(4271)\",\"LSS_failedAttachReqsRateExceeded(4272)\"),\nthis after [-60s, 60s] $root)\nthen\nDmaapService.publishResult(...);\nend",
"description": "The default rule for the VoLTE usecase."
},
{
"name": "holmes.default.rule.volte.scenario2",
"value": "package dcae.ves.test\nimport org.onap.some.related.packages;\nrule\"SameVNF_Relation_Rule_1\"\nsalience 120\nno-loop true\nwhen\n$root : VesAlarm(\n$sourceId: sourceId, sourceId != null && !sourceId.equals(\"\"),\nspecificProblem in ( \"LSS_cpiPCSCFFailReg(121297)\", \"LSS_cpiSIPRetransmitInvite(120267)\" ),\n$eventId: eventId)\n$child : VesAlarm( eventId != $eventId,\nCorrelationUtil.getInstance().isTopologicallyRelated(sourceId, $sourceId),\nspecificProblem in (\"LSS_externalLinkDown(4271)\",\"LSS_failedAttachReqsRateExceeded(4272)\"),\nthis after [-60s, 60s] $root)\nthen\nDmaapService.publishResult(...);\nend",
"description": "The default rule for the VoLTE usecase."
}
],

As Pam explained, in R1 Holmes rules will be bundled with Holmes artifact. DCAE will convert the rules into Blueprint format when onboarding Holmes. CLAMP will configure the rules and store them into Policy. When service is instantaiated, Policy will distribute the rules to DCAE and DCAE will pass it to Holmes when bringing up Holmes analytics.

• Define correlation policy for VoLTE closed loop event. Different vendors will have different alarm code

Blutprint

and Operation Policy

• Support configuration of all closed loop policy related parameters
• Distribute policy artifacts to DCAE, Holmes, and Policy

Policy R1 Amsterdam Functional Test Cases

VoLTE Provisional Operational Policy Example:

controlLoop:
  version: 2.0.0
  controlLoopName: ControlLoop-VOLTE-2179b738-fd36-4843-a71a-a8c24c70c55b
  trigger_policy: unique-policy-id-1-restart
  timeout: 3600
 
policies:
  - id: unique-policy-id-1-restart
    name: Restart the VM
    description:
    actor: VFC
    recipe: Restart
    target:
      type: VM
    retry: 3
    timeout: 1200
    success: final_success
    failure: final_failure
    failure_timeout: final_failure_timeout
    failure_retries: final_failure_retries
    failure_exception: final_failure_exception
    failure_guard: final_failure_guard

• Support auto healing policy for VoLTE
• Define auto healing policy in GUI

• Support all parameter input defined in VoLTE service template
• Support VoLTE E2E service instantiation by clicking one button
• Support alarm monitoring for ONAP and VoLTE service

Development is delayed, and some repo is still empty.

• Support Network Service instantiation
• Support auto-healing