Service Quality Management for multidomain network services Pavle Vuletić, AMRES edupert videoconference, 20 July 2015
What is Service Quality Management? Resource Performance Management (RPM) provides insight into the network and network element performance and behavior (e.g. status of the interface, the amount of traffic passing through the interface, CPU load or similar) Service Quality Management (SQM) Correlates network measurement data with the service information and gives it a specific meaning. processes related to SLA verification and assurance Used to check and verify key SLA parameters and customers experience. Increasingly important with the development of virtualized environments where multiple service instances share the same physical infrastructure 2
SQM supporting tool main goals Support multi-domain, multi-instance (and multi-point) network services. MDVPN is a primary target, but also multi domain circuits or other multidomain services should be able to use this system. Aim: Monitor service end-to-end, capture user s experience of the service and verify contractual obligations (SLA) - Service Quality Management - SQM. Tool users: service operators to continuously monitor KPI of the service and knowledgeable service users to have an insight into the SLA verification. Allow dynamic service paths - do not depend on the service path and network element access rights along the path Scalability. Monitoring end-to-end m instances of a service, with n end points each in multiple domains requires in a straightforward solution mn measurement agents. Reduce this number! Simple for use (simple configuration) Accuracy and reliability Always prefer reusing/integrating existing tools if possible than developing new components 3
MDVPN, an example of multi-domain, multi-instance, multi-point service 4
What is specified by the SLA? Service is offered to the end-user SLA should capture user s demands and expected service experience ITU-T Y.1540 and Y.1541 specify in detail the definition of specific performance metrics and KPIs SLA parameters are: packet latency, latency variation (jitter) and packet loss rate (PLR) For different services and applications, there are specific performance metrics that must be guaranteed in order to satisfy service perception. Real-time applications demand guarantees of all three metrics, whereas applications like file transfer and web browsing only need guarantees for PLR. Bandwidth measurements (capacity, available bandwidth, TCP throughput and similar) are not a part of the SLA. Bandwidth measurements are typically used before the service is put into production. 5
SLA models for multi-point services SLA model depends on the type of the service Point to point Hub and spoke (point to multiple points) Multipoint (mesh SLA) MDVPN offers a very general set of services for end users all SLA models are applicable for MDVPN services Problem of multipoint services SLA scalability MEF 10.2 and Y.1563 propose the use of aggregated SLA metrics for multipoint services (e.g. an average value of the delay or jitter of all combinations of paths between service instance end-points). However, even for the aggregated metrics to be properly measured in the multipoint case the number of measurement agents will be equal to the number of end points and the number of measurements on the order of O(n 2 ) 6
SLA verification in multi-domain environments - strategies End-to-end measurements: assume the use of passive and active methods to measure delay, jitter and packet loss between service end points Problem: If service has m service instances where service instance x has n x end points, the total number of measurement agents is N ma = x=1 m n x Metric composition: described in several standard documents RFC 5644, RFC 5835, RFC 6049, ITU-T Y.1541 Key measurement parameters are measured in each domain and then end-to-end metrics are estimated from the per-domain measurements Total number of measurement agents in this case can be N ma = x=1 d b x, where b x is the number of cross-border connections of the domain x, and d is the number of domains. 7
Metric composition - issues this methodology is more scalable, but inherently less accurate especially for jitter measurements [Douardo et. al] because of the several issues like: the measurement of the border link, double measurements on MA links, time synchronization of the measurements, etc. Also there are issues with the exposure of the per-domain data towards the central measurement gathering and calculation device in-instance measurements and changes in service instance topology due to the routing table changes Who measures this link? What if this is measured 1 min after Domain A? Delay, jitter, loss Delay, jitter, loss MA MA MA MA Domain A This link can be measured twice if MA is not on the network element Domain B 8
Measurement methodologies Active and passive monitoring Delay, jitter have to be measured actively, while packet loss can be inferred from the passive measurements, although using complex methodology and large resources What can be active probes for SLA verification? Separate measurement points (perfsonar MP, Atlas probes,...) Network element features (Cisco SLA, Juniper RPM) not compatible MPLS VPNs do not have standardized method for the performance measurement (features like MPLS BFD not compatible between different vendors incomplete implementations) Recently concluded IETF l3vpn WG aimed to propose standards for MPLS and MPLS VPN performance monitoring, the extension of RFC 6374: draft-zheng-l3vpn-pm-analysis-03 (expired), July 2014. draft-dong-l3vpn-pm-framework-02 (expired), January 2014. draft-ni-l3vpn-pm-bgp-ext-01 (expired), February 13, 2014 9
MPLS and MPLS VPN monitoring challenges Problem is LSP aggregation, especially when PHP is used Drafts propose the new concept of the "VRF-to-VRF Tunnel" (VT). In this concept, each PE router needs to allocate MPLS labels to identify the VRF-to- VRF tunnel between the local VRF and the remote VRFs (labels are called VT labels). It is likely that the functionality that is being developed is going to be a feature for the PE routers, but it does not exist now. 10
SQM - High level design decisions - 1 Uses standard active measurement architecture, like perfsonar or IETF LMAP (measurement agent + measurement collector + measurement controller) Measure and monitor only the SLA parameters: delay, jitter, loss No heavyweight, intrusive and unreliable capacity/available bandwidth estimations Relies on reliable and standardized active measurements (owamp): No dependence on the service path and network element access rights along the service instance path Accuracy: Use end-to-end measurements instead of metric composition strategies External devices are needed as there are no interoperable solutions on network elements 11
High level design decisions - 2 Scalability and simplicity: Small/zero footprint measurement agents (SBCs), Measurement results are not collected on agents One-click configuration of measurement agents Multi-homing measurement agents (one measurement agent can serve multiple service instances with overlapping address spaces) 12
SQM architecture and the prototype Based on IETF LMAP architecture Main new components: User Interface Service quality reports Trouble ticket system Alarm management system Service/SLA inventory SQM processing tool Service/SLA Inventory Service Quality Management OWAMP based measurement agents (not zero footprint at the moment) Reporting, alarming not a part of the short-term goals controller collector MA MA MA MA MA Resource Performance Management 13
Service/SLA inventory Stores the relevant data about service instances (both transport service and MDVPN services) Stores SLA parameters and thresholds Data model used TMF SID as inspiration Based on MDVPN data model for service requests First implementation was the extension of perfsonar SLS, current version is built from scratch 14
SQM component Gathers SLA data from inventory Gathers measurement data Makes distinction between measurement data belonging to different service instances Displays SLA data Displays temporal graphs of main SLA parameters 15
SQM prototype
Prototype setup 17
Service inventory / configuration
SLA/Service inventory front page 19
Creating new service instances 20
List of NRENs subscribed to the service 21
Adding new Measurement Agent 22
Adding new PE Router 23
Configuring SLA, config files for service instances 24
25
Adding NREN contacts 26
SQM monitoring
SQM monitoring front page 28
L2VPN 29
L3VPN 30
loss 31
delay 32
jitter 33
Conclusions SQM system is capable to monitor any network service from within the service instance. The system is not dependent on the underlying network technology and network topology It is more scalable than the existing platforms for monitoring netswork service instances The architecture of the system is similar (or the same) as perfsonar, RIPE ATLAS or LMAP not much sense to have two or more so similar systems in parallel Potential solution: Add SQM capabilities to perfsonar. Changes to the Esmond archive should not be so big, but larger changes are required on the measurement agent/controller side. 34
Thank you! www.geant.net www.twitter.com/geantnews www.facebook.com/geantnetwork www.youtube.com/geanttv 35