IPPM Working Group | B. M Gaonkar |
Internet-Draft | S. Jacob |
Intended status: Standards Track | Juniper |
Expires: December 26, 2017 | G. Fioccola |
Telecom Italia | |
Q. Wu | |
Huawei | |
P. Ananthasankaran | |
Nokia | |
June 24, 2017 |
Performance Measurement Models
draft-bhaprasud-ippm-pm-03
This document defines the performance measurement models for service level packets on the network which can be implemented in different kind of network scenarios. Based on the performance matrix, the analytics data can be pulled from a live network which is not possible at present.This can be used for self evolving networks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Today performance monitoring or tracking of the performance experienced by customer traffic is a key technology to strengthen service offering and verify service level agreement between customers and service providers, perform troubleshooting. The lack of adequate monitoring tools to detect an interesting subset of a packet stream, as identified by a particular packet attribute(e.g., commit rate or DSCP) and measure that packet loss drives an effort to design a new method for the performance monitoring of live traffic, possibly easy to implement and deploy. The draft aims to provide fine granularity loss, delay and delay variation measurement and define a performance measurement model on customer traffic based on a set of constraints that are associated with service level agreement such as cos attribute, color attribute. Each customer traffic is corresponding to an interesting subset of the same packet stream. The customer or a interesting packet stream can be identified by a list of source or destination prefixes, or by ingress or egress interfaces, combing with packet attributes such as DSCP or commit rate).Unlike Color and COS identification specified in MEF 23.1, this draft doesn't define new Color and CoS identification mechanism, instead, it stick to color definition in [RFC2697] and [RFC2698] and COS definition in [RFC2474].
The network would be provisioned with multiple services(e.g., real time service, interactive service) having different network performance criteria(e.g., bandwidth constraint or packet loss constraint for the end to end path) based on the customers' requirement. This models aims at performing Loss, Delay and delay variation measurement for these services (belonging to the same customer)independently for each defined network performance criteria.
The class-of-service and packet color classification defined in the network is a key factor to classify network traffic and drive traffic management mechanism to achieve corresponding network performance criteria for each service. This draft uses the class-of-service model and color based model for any given network to define the performance measurement for various services with the different network performance criteria requirements.
The proposed models is suitable mainly for passive performance measurements but can be considered for active and hybrid performance measurements as well.
This solution models loss, delay an delay variation measurement in different kinds of network scenarios. The different models explained here will help to analyse performance pattern, analyze the network congestion in a better way and model the network in a better way. For instance, Loss measurement is carried out between 2 end points. The underlying technology could be an active loss measurement or a passive loss measurement.
Any loss measurement will require 2 counters:
This draft explains the different ways to model the above data and get meaningful result for the loss, delay and delay variation measurement. The underlying technology could be an MPLS performance measurement, or an IP based performance measurement.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
A stream of packets is observed at an Observation Point of the source endpoint and destination endpoints. Two observation points can also be placed at the same endpoint for node monitoring [I-D.ietf-ippm-alt-mark], i.e.,one is at ingress interface of the endpoint and the other is at the egress interface of the endpoint. A Selection Process inspects each packet to determine whether or not it is to be selected for data analytics. The Selection Process is part of the Metering Process, which constructs a report stream on selected packets as output, using the Packet Content, and possibly other information such as the arrival timestamp. The report stream on selected packets will be stored in the persistence data store for real time data analysis or time sequence data analysis.
The following figure indicates the sequence of the three processes (Selection, Metering, and Storing).
+-----------+ +-----------+ |Persistence| |Persistence| |Data Store | |Data Store | Src Endpoint +-----^-----+ Dst Endpoint +------^----+ +------------------+ | +------------------+| | Metering Process | | | Metering Process || Observed | +-----------+ | | | +-----------+ || Packet--->| | Selection |------+ Observed | | Selection | || Stream | | Process |--------Packet--->| | Process |-----+ | +-----------+ | Stream | +-----------+ | +------------------+ +------------------+
This section defines the Selection Process and related objects.
A Metering Process selects packets from the Observed Packet Stream using a Selection Process, and produces as output a Report Stream concerning the selected packets.
This model uses the complete data traffic between the 2 end-points to compute loss measurement, delay and delay variation. This will result in computation of loss, delay and delay variation measurement for the entire traffic in the network in one direction. This is primarily used in cases of backbone traffic where traffic from different services are aggregated and send into the core network. This will count all the packet, this gives the overall measurment between one endpoint to other.
This is same as the above section of "complete data measurement" with a minor difference, only monitoring the data packet with specific color identifier.
In this model the packets are counted in the following Way: Count specific data traffic with different color identifier between 2 end points for loss, delay and delay variation measurement. One example of Color based data measurement is to count two type of color based traffic:
When both of these are combined then it becomes the model for complete traffic as mentioned in the above section.
In practice the Color of traffic can use any mechanism based on the network encapsulation.As long as the packets could be treated differently based on the underlying encapsulation this mechanism could be used.
This can be used for measuring the whole traffic of the customer who dont want cos level measurement.Ideally this can be used for provider who extend bandwidth for small providers, point to point services etc.
This model uses the data traffic in the network which is flowing in a specific CoS to measure the loss, delay and delay variation in the network. Based on the class of traffic in the network the transmitted and received packets are counted to calculate the packets transfered per service level. The time stamp will be captured along with the packet count to measure the service down time. This model measures the performance per service level. This data can be stored on the routers which can be used to plot the live analytics.
Primary use of this kind of measurement is to measure packet loss delay and delay variation for a specific service which needs to meet network performance requirements. The service could be a point-to-point layer2 service, an MPLS based service.
This model uses a combination of both Color based data measurement and CoS based data measurement. Packets are counted for a specific CoS with a specific Color.This can count both in profile packet which are green and yellow which are out profile packets. This will not count the red packet which doesn't meet network performance requirements.The packets will be counted per service level with CIR and EIR along with time stamps to find the service outage and loss. The per service level counting for COS and color will give more granular level data for poloting service graph and if some service is continously exceeding the bandwidth this data can be used for charging the end customer for extra bandwidth usage or increase the bandwidth based on usage basis.
This model reinforces the use of well known methodologies for passive performance measurements. A very simple, flexible and straightforward mechanism is presented in [I-D.ietf-ippm-alt-mark]. The basic idea is to virtually split traffic flows into consecutive batches of packets:each block represents a measurable entity unambiguously recognizable thanks to the alternate marking. This approach, called Alternate Marking method, is efficient both for passive performance monitoring and for active performance monitoring. Most of the applications requires passive packet loss measurement for a better accuracy. Instead, in same cases, it is desirable to have only active delay measurements (e.g TWAMP or OWAMP), because it is enough.
Consider a provider running point to point service between router A and B for his customer "X".Customer "X" has voice traffic which requires special treatment,then he requires attention for database traffic. The customer "X" has SLA with the provider. Now the challenge faced by the provider is how to measure the traffic of customer "X" for each class and calculate the bandwidth, moreover the provider has to see whether the "X" is sending traffic which is exceeding the level so that he can make tariff accordingly. This problem is solved by the above models which can measures the packet for each class of traffic and tabulates the data. Later point of time this data can be pulled for evaluation.
+-------+ +-------+ | | | | | +--------------+ | | | P2P service | | +-------+ +-------+ Router A Router B
Figure 1: P2P
The same considerations can be applicable in a multipoint to multipoint scenario (e.g. VPN or Data Center interconnections). In this case Customer "X" has multiple ingress endpoints and multiple egress endpoints. The proposed matrix model is composed by the number of flows of "X" in the multipoint scenario and by class-of-service and color classification. So the SLA matrix is a reference for the analysis and evaluation phase.
+--+ +--+ | | | | +--+ +--+ Router A1 Router B1 +--+ +--+ | | MP2MP service | | +--+ +--+ Router A2 Router B2 . . . . . . +--+ +--+ | | | | +--+ +--+ Router An Router Bn
Figure 2: MP2MP
We would like to thank Brian Trammell for giving us the opportunity to present our draft.We would like to thank Greg Mirsky for the comments.
This document does not introduce security issues beyond those discussed in [I-D.ietf-ippm-alt-mark].
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
[I-D.ietf-ippm-alt-mark] | Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G. and T. Mizrahi, "Alternate Marking method for passive performance monitoring", Internet-Draft draft-ietf-ippm-alt-mark-04, March 2017. |