VES A Modeled Approach to Monitoring VNF Event

VES: A Modeled Approach to Monitoring VNF Event Streams Bryan Sullivan and Alok Gupta, AT&T

OPNFV VES (VNF Event Stream) Project Objective Enable significant reduction in effort to integrate VNF telemetry into automated VNF management systems, by promoting convergence to a common event stream format and collection system. https: //wiki. opnfv. org/display/VES 30 Sept 2016 Open. Stack Days Seattle 2

Why this is needed § Telemetry data formats and semantics / expected actions by management systems vary widely § For Fault Events, vendors use SNMP, 3 GPP Corba, MTOSI, OSSJ etc, and semantics can differ (e. g. Critical Severity as “ 1” or “ 5”) § For Measurement events (KPI/KCI), vendors deliver CSV or XML based files, with varying internal data formats § This variance results in substantial development and maintenance costs for VNF integration into management systems § 3 -6 months development is typically needed 30 Sept 2016 Open. Stack Days Seattle 3

Project Scope and Deliverables § VNF Event Stream Common Event Data Model § To be developed in collaboration with SDOs and other open source projects § Integration into the OPNFV platform as a monitoring framework § A VES Agent that can collect the VNF Event Stream data from the VNF and deliver it to the VES Collector § A VES Collector that can consume the VNF Event Stream data, and store the data in a database backend § VES plugins for integration with Open. Stack infrastructure services such as Monasca, Vitrage, Congress § A plan for upstreaming the project code 30 Sept 2016 Open. Stack Days Seattle 4

Why this is relevant to Open. Stack • NFV Service Providers need to monitor and manage all aspects of the environment • Applications (VNFs and other VFs) • Physical and virtual infrastructure (compute, storage, network devices) • Virtual infrastructure managers (Cloud controllers, SDN controllers) • Open. Stack’s internal telemetry is not a holistic solution for all those needs • It supports only a subset, primarily focused on the virtual infrastructure it manages • Challenges applying the telemetry system outside Open. Stack, and at scale • VIMs can benefit from relevant events they would otherwise not be aware of, e. g. • Application state, fault, and performance events 30 Sept 2016 Open. Stack Days Seattle 5

VES interfaces Other Management Functions Application Controller In scope: • Green/solid interfaces • Agent/Collector interface support library and reference implementation • Open. Stack component plugins Agent code is embedded in VNFCs, Virtualization Hosts, and Bare Metal Hosts Agents / VNFCs can also deliver directly to Open. Stack Plugins 30 Sept 2016 Monasca Vitrage Congress etc Plugins Collector can integrate with other Open. Stack Collectors VES Collector Open. Stack SDNC Message Bus VES Agent VNFC VES Agent Direct (REST) Virtualization Host(s) Bare Metal Host Open. Stack Days Seattle 6

VES – Common Event Data Model § Common Header and Domain Specific Event § Extensible for additional fields or domains § Collector connection and data profile established at VM creation § Connection/authentication/profile parameters injected into VM § 30 Sept 2016 Data profile is fully controllable, to optimize telemetry overhead Open. Stack Days Seattle 7

Initial VES Data Model • UML diagram based upon a YANG representation of the VES JSON schema 30 Sept 2016 Open. Stack Days Seattle 8

Initial VES Data Model • This illustrates the basic fault domain event data • VES data model will be published in JSON, and easily adaptable to – Other representations (e. g. YANG) – Control protocols e. g. HTTP/REST (current agent code), Netconf, AVRO, g. RPC. Domains with data/volume size may determine the protocol used. 30 Sept 2016 Open. Stack Days Seattle 9

Use cases with example closed-loop monitoring plugins Events VNF Collector Event Processor PM (Threshold Crossing Alert) Correlation Policy Enforcement/ Automation Scenario 1: False Alarm Data Bus Scenario 2: VM Failure Scenario 3: Scaling Alert Tickets Generated, Updated and Closed Ticketing System 30 Sept 2016 Open. Stack Days Seattle Scenario 1: Failure Event, Notification Scenario 2: Payload Processor Failure Publish an event to Restart VM Scenario 3: High CPU Utilization Published an event for service orchestrator to create a New VF 10

Takeaways and next steps • Common telemetry data models can improve ROI in VNF onboarding • OPNFV will work with SDOs (TM Forum, OASIS, ETSI) to standardize the VES event data model • OPNFV will prototype Open. Stack services integration as VES providers/consumers, with blueprints to follow • Collaborators in the OPNFV VES project are welcome! 30 Sept 2016 Open. Stack Days Seattle 11

THANK YOU! • For more info, stop by https: //wiki. opnfv. org/display/VES • And while you’re there check out other OPNFV projects – https: //wiki. opnfv. org/display/copper (Configuration Policy): Deployment and use of Open. Stack Congress on OPNFV – https: //wiki. opnfv. org/display/models/ (Model-Driven NFV): Deployment and use of VNF Managers e. g. Open. Stack Tacker, Cloudify, Open. Baton, as tools to drive support/convergence of standard VNF packages and blueprints 30 Sept 2016 Open. Stack Days Seattle 12