ETSI GS MOI 002 V1.1.1 (2012-07)

Measurement Ontology for IP traffic (MOI); Requirements for IP traffic measurement ontologies development

DGS/MOI-0002

General Information

• Status: Published
• Publication Date: 29-Jul-2012
• Technical Committee: MOI - Measurement Ontology for IP traffic
• Current Stage: 12 - Completion
• Due Date: 02-Aug-2012
• Completion Date: 30-Jul-2012

Standards Content (Sample)

Group Specification
Measurement Ontology for IP traffic (MOI);
Requirements for IP traffic measurement ontologies
development
Disclaimer
This document has been produced and approved by the Measurement Ontology for IP traffic (MOI) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS MOI 002 V1.1.1 (2012-07)

Reference
DGS/MOI-0002
Keywords
IP, ontology, requirements, traffic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2012.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS MOI 002 V1.1.1 (2012-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Abbreviations . 8
4 Framework of the Ontology for IP Measurements . 8
5 KPI Descriptions and Mapping to MOI . 9
5.1 Parameters Related to Delay or Delay Variation . 10
5.2 Parameters Related to Errors and Losses . 11
5.3 Parameters Related to Packet Reordering, Replication and Duplication . 11
5.4 Parameters Related to Connectivity and Service Availability . 12
5.5 Throughput Related Parameters . 12
5.6 Operational Real-world KPIs . 13
6 Information Models Requirements for IP Traffic Monitoring Applications . 13
6.1 Use Case Scenarios . 13
6.1.1 IP Networks Characterisation . 14
6.1.2 QoS Measurements in IP Networks . 14
6.1.3 Traffic Monitoring for Security Applications . 15
6.1.4 Autonomic Network Monitoring and Management . 16
6.1.5 Law Enforcement . 16
6.2 Requirements Derived from the Quality of Experience Concepts . 17
6.3 Ontology Requirements to Support Business Management Applications . 18
7 Additional Input for Privacy Protection Approaches . 19
8 Main Features and Global Requirements for MOI . 24
8.1 Data Types Support Requirements . 24
8.1.1 Requirements for Application-specific Data Types . 25
8.2 Operational Requirements . 26
8.3 Requirements for Integral Privacy Protection Provisions. 27
9 Ontology Architecture and Structure Requirements . 28
9.1 Requirements of Expandability . 28
9.2 Requirements of Interoperability . 28
9.3 Requirements of Ontological Processing Performance . 29
Annex A (informative): Authors & contributors . 30
History . 31

ETSI
4 ETSI GS MOI 002 V1.1.1 (2012-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Measurement Ontology for IP
traffic (MOI).
Introduction
Defining a complete set of concepts and their relationship to support coherent developments of traffic measurement
systems needs not only an extensive mapping of key performance indicators (KPI), key quality indicators (KQI) and
currently used parameters to describe IP networks, but a serious pre-definition of the framework and extension of the
ontology to be set up. If it is true that ontologies should be complete and internally coherent, one ought to be aware of
the final purpose of establishing such an ontology, namely supporting information systems to achieve IP traffic
monitoring and quality of service (QoS) applications that can exchange information and back service level agreements
(SLA) up and fulfil the expectations of customers by assuring the quality of experience (QoE).
The present document starts setting up the limits to the ontology that needs to be defined for such purpose. Then, after
reviewing the parameters that define IP networks, some use cases are used to analyse which internal specifications
should be respected in order to give rise to a coherent ontology for IP traffic monitoring useful for practical purposes.
ETSI
5 ETSI GS MOI 002 V1.1.1 (2012-07)
1 Scope
The present document identifies the requirements that should characterise an ontology for the semantic
conceptualisation of information related to IP traffic measurements. The requirements are obtained through the analysis
of use cases spanning across a variety of related application categories and domains of interest, as well as the
consideration of additional qualitative needs, such as the protection of personal data. Additional inputs arise from user
experience, as well as the 'GS/MOI-010' Work Item study, entitled "Report on information models for IP traffic
measurement" [1]. The general difficulty of setting limits to an ontology, taking concepts from outside is also dealt
within the present document that states MOI focus on IP traffic measurement concepts and let's side ontologies dealing
with other subjects, an easy way to link. Thus a rather practical approach to define MOI ontology will be laid so that
further QoS, traffic monitoring and Internet governance issues can be built on top of it by means of semantic tools.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS MOI 010: "Measurement Ontology for IP Traffic (MOI); Report on Information Models
for IP Traffic Measurement".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] FP7 ICT project MOMENT (Monitoring and Measurement in the Next Generation Technologies).
NOTE: Available at http://fp7-moment.eu/
[i.2] FP7 ICT project PRISM (PRIvacy-aware Secure Monitoring).
NOTE: Available at http://fp7-prism.eu/
[i.3] FP7 ICT project DEMONS (DEcentralized, cooperative, and privacy-preserving MONitoring for
trustworthiness).
NOTE: Available at http://fp7-demons.eu/
[i.4] IETF RFC 2330: "Framework for IP Performance Metrics".
[i.5] ITU-T Recommendation Y.1561: "Performance and Availability Parameters for MPLS Networks".
[i.6] ITU-T Recommendation Y.1540: "Internet protocol data communication service - IP packet
transfer and availability performance parameters".
[i.7] IETF RFC 2679: "A One-way delay Metric for IPPM".
[i.8] ITU-T Recommendation Y.1544: "Multicast IP performance parameters".
ETSI
6 ETSI GS MOI 002 V1.1.1 (2012-07)
[i.9] IETF RFC 5644: "IP Performance Metrics (IPPM): Spatial and Multicast".
[i.10] IETF RFC 3393: "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)".
[i.11] ITU-T Recommendation Y.1543: "Measurements in IP networks for inter-domain performance
assessment".
[i.12] IETF RFC 2681: "A Round-trip Delay Metric for IPPM".
[i.13] IETF RFC 2680: "A One-way Packet Loss Metric for IPPM".
[i.14] IETF RFC 3357: "One-way Loss Pattern Sample Metrics".
[i.15] IETF RFC 4737: "Packet Reordering Metrics".
[i.16] IETF RFC 5560: "A One-Way Packet Duplication Metric".
[i.17] IETF RFC 3148: "A Framework for Defining Empirical Bulk Transfer Capacity Metrics".
[i.18] IETF RFC 2678: "IPPM Metrics for Measuring Connectivity".
[i.19] ITU-T Recommendation Y.1540 Amendment 1.
[i.20] IBM, "Understanding the Autonomic Manager Concept".
NOTE Available at http://www.ibm.com/developerworks/library/ac-amconcept/
[i.21] D. E. Monnat, A. L. Ethen, "A Primer on the Federal Wiretap Act and Its Fourth Amendment
Framework", Journal of the Kansas Trial Lawyers Association, Vol. 28, No. 1, pp. 12-15, 2004.
[i.22] Council of the European Union, "Council Resolution of 17 January 1995 on the lawful
interception of telecommunications", Official Journal of the European Communities, No. C 329,
pp. 1-6, November 1996.
[i.23] ETSI TS 102 233: "Lawful Interception (LI); Service specific details for E-mail services".
[i.24] ETSI TS 102 234: "Lawful Interception (LI); Service-specific details for internet access services".
[i.25] ETSI TS 102 656: "Lawful Interception (LI); Retained Data; Requirements of Law Enforcement
Agencies for handling Retained Data".
[i.26] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 1: Handover specification for IP delivery".
[i.27] A. Zugenmaier and J. Claessens, "Privacy in Electronic Communications", in Network Security:
Current Status and Future Directions, C. Douligeris & D.N. Serpanos (Eds.), pp. 419 - 440, Wiley-
Interscience & IEEE Press, 2007.
[i.28] G. V. Lioudakis, E. A. Koutsoloukas, N. Dellas, N. Tselikas, S. Kapellaki, G. N. Prezerakos, D. I.
Kaklamani, I. S. Venieris, "A Middleware Architecture for Privacy Protection", Computer
Networks, Vol. 51, No. 16, pp. 4679 - 4696, November 2007.
[i.29] L. F. Cranor, "I Didn"t Buy It for Myself", in Designing Personalized User Experiences in E-
Commerce, C.-M. Karat, J.O. Blom, & J. Karat, (Eds.), pp. 57 - 73, Kluwer Academic Publishers,
2004.
[i.30] G. D. Bissias, M. Liberatore, D. Jensen and B. N. Levine, "Privacy Vulnerabilities in Encrypted
HTTP Streams", in Proceedings of the 5th Workshop on Privacy Enhancing Technologies (PET
2005), Cavtat, Croatia, May 30 - June 1, 2005, LNCS 3856.
[i.31] M. Crotti, F. Gringoli, P. Pelosato and L. Salgarelli, "A Statistical Approach to IP-Level
Classification of Network Traffic", in Proceedings of the IEEE International Conference on
Communications (ICC) 2006, Istanbul, Turkey, June 11 - 15, 2006.
[i.32] A. Hintz, "Fingerprinting Websites Using Traffic Analysis", in Proceedings of the 2nd Workshop
on Privacy Enhancing Technologies (PET 2002), San Francisco, CA, USA, April 14 -15, 2002,
LNCS 2482.
ETSI
7 ETSI GS MOI 002 V1.1.1 (2012-07)
[i.33] Q. Sun, D. R. Simon, Y.-M. Wang, W. Russell, V. N. Padmanabhan and L. Qiu, "Statistical
Identification of Encrypted Web Browsing Traffic", in Proceedings of the 2002 IEEE Symposium
on Security and Privacy (SP" 02), Marseille, France, May 12 - 15, 2002.
[i.34] S. Bellovin, "A Technique for Counting NATted Hosts", in Proceedings of the 2nd ACM
SIGCOMM Workshop on Internet Measurement (IMW" 02), Berkeley, CA, USA, November 6-8
2002.
[i.35] European Parliament and Council, "Directive 2002/58/EC of the European Parliament and of the
Council concerning the processing of personal data and the protection of privacy in the electronic
communications sector (Directive on privacy and electronic communications)", Official Journal of
the European Communities, No. L 201, pp. 37 - 47, July 2002.
[i.36] European Parliament and Council, "Directive 2006/24/EC of the European Parliament and of the
Council of 15 March 2006 on the retention of data generated or processed in connection with the
provision of publicly available electronic communications services or of public communications
networks and amending Directive 2002/58/EC", Official Journal of the European Communities,
No. L 105, pp. 54 - 63, April 2006.
[i.37] "United States Code 18, § 2701: Unlawful access to stored communications".
[i.38] European Parliament and Council, "Directive 95/46/EC of the European Parliament and of the
Council on the protection of individuals with regard to the processing of personal data and on the
free movement of such data", Official Journal of the European Communities, No. L 281, pp. 31-
50, November 1995.
[i.39] G. V. Lioudakis, F. Gaudino, E. Boschi, G. Bianchi, D. I. Kaklamani, I. S. Venieris, "Legislation-
Aware Privacy Protection in Passive Network Monitoring", in Information Communication
Technology Law, Protection and Access Rights: Global Approaches and Issues, I. M. Portela, M.
M. Cruz-Cunha (Eds), IGI Global, 2010.
[i.40] The World Wide Web Consortium (W3C), "XML Schema Part 2: Datatypes Second Edition",
W3C Recommendation 28 October 2004.
NOTE: Available at http://www.w3.org/TR/xmlschema-2/
[i.41] Morfeo project, Measurement Units Ontology.
NOTE: Available at http://forge.morfeo-project.org/wiki_en/index.php/Units_of_measurement_ontology
[i.42] NASA, Semantic Web for Earth and Environmental Terminology (SWEET) v. 1.1, Units
Ontology.
NOTE: Available at http://sweet.jpl.nasa.gov/1.1/
[i.43] T. R. Gruber, G. R. Olsen, "An Ontology for Engineering Mathematics", in Proceedings of the 4th
International Conference on Principles of Knowledge Representation and Reasoning (KR'94),
Bonn, Germany, May 24-27, 1994.
[i.44] FP7 ICT project MOMENT, MOMENT Units Ontology.
NOTE: Available at https://svn.fp7-moment.eu/svn/moment/public/Ontology/MomentUnits.owl
[i.45] H. Stuckenschmidt, F. van Harmelen, "Information Sharing on the Semantic Web", chapter 7:
Sharing statistical information, Springer, 2005, ISBN: 978-3-540-20594-4.
[i.46] E. Shaya, "Ontology of Statistics (background for Astronomy Ontology)".
NOTE: Available at http://www.astro.umd.edu/~eshaya/astro-onto/ontologies/statistics.html
[i.47] F. Guala, "An Ontology of Economics?", Extended version of the review of "The Elgar
Companion to Economics and Philosophy" appeared in the Economic Journal, 116 (2006), pp.
318-321.
NOTE: Available at http://people.exeter.ac.uk/fguala/OntologyLong.pdf
ETSI
8 ETSI GS MOI 002 V1.1.1 (2012-07)
[i.48] OWLIM Semantic Repository.
NOTE: Available at http://www.ontotext.com/owlim/
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CC Content of Communication
CIM Common Information Model
CPU Central Processing Unit
ICMP Internet Control Management Protocol
IPTV Internet Protocol TeleVision
IRI Interception Related Information
ISP Internet Service Provider
KPI Key Performance Indicators
KQI Key Quality Indicator
LEA Law Enforcement Agency
LI Lawful Interception
MOS Mean Opinion Score
MPLS Multi Protocol Label Switching
OSI Open System Interconnection
OWL W3C Web Ontology Language
QoE Quality of Experience
QoS Quality of Service
RDF Resource Description Framework
RDFS RDF Schema
SLA Service Level Agreement
SNMP Simple Network Management Protocol
TMA Traffic Monitoring and Analysis
TCP Transmission Control Protocol
UDP User Datagram Protocol
XSD XML Schema Definition
4 Framework of the Ontology for IP Measurements
Network monitoring constitutes a key task in current communication networks, with a broad applicability domain. It is
crucial for the effective operation and management of communication networks, since it enables the acquisition of
essential information and the identification, among other, of performance bottlenecks, while the offline analysis of the
resulting traces is very useful for network planning and the accounting and billing of network services. In this context,
network monitoring can additionally serve for the validation of Service Level Agreements and generally for the
observation and fine-tuning of parameters related to Quality of Service and Quality of Experince. With respect to
security and protection of networks, it constitutes the fundamental basis for Intrusion / Anomaly Detection Systems
(IDS/ADS) which trigger alarms and set up countermeasures in reaction to events, such as network intrusions, denial-
of-service attacks and worm infections. In addition, the data traces that constitute the result of network monitoring are
very useful for the research community that investigates the fields mentioned above, as well as other network-related
research domains. Last but not least, network monitoring provides the means for the implementation of several
obligations mandated by the law; these include the retention of certain data for ensuring their availability if needed for
the investigation, detection and prosecution of serious crimes, as well as the performance of Lawful Interception.
Different monitoring tools and platforms have been developed through the years to obtain active and passive
measurements about a variety of metrics. The integration of such measurements can be valuable for network operators
to obtain network weathermaps or network tomographies. However, this integration in a single view is difficult because
each platform uses its own data structures and its own interaction interfaces.
ETSI
9 ETSI GS MOI 002 V1.1.1 (2012-07)
Ontologies can become very useful for the conceptual integration of the different measurement data models. Dealing
with the underlying information at a semantic level can enable some degree of inference and automatic reasoning over
the retrieved measurement data. At the same time, ontologies let define the information at different abstraction levels,
allowing the definition of specific classes of measurements that are derived from generic ones. The present document
focuses on this approach, applying the concepts provided by ontologies to address the integration of measurement
information from a semantic viewpoint.
The MOI ontology has to describe the set of concepts, properties, relationships and axioms in the domain of Internet
Network Measurements. In that respect, it is very important to define the limits of the ontology, and also set
connections to other already defined and globally accepted ontologies. Given that the network measurement domain is
very broad, it is important to be pragmatic, avoiding very large models that are difficult to apply in a real use case. For
this, the ontology will be focused on what can be measured in an Internet Network; Quality of Service (QoS) and
Quality of Experience (QoE) will be essential parts of this ontology, whereas special focus will be put on the critical
issue of personal data protection as an integral part of the ontology. Other concepts will be taken from other existing
ontologies, to a some extent investigated in [1]. Other general concepts are also available in already defined network
management information models such as the CIM model, SNMP MIBs or ITU M.3100.
The work presented here is supported by three European research projects. The aim of the FP7 ICT MOMENT [i.1] was
precisely to find ways to solve the integration problem. This integration was twofold: definition of a standard interface
to access the information, as well as definition of a homogeneous view of the available information. For the latter
integration, it was necessary to combine database schemas of the existing network measurement infrastructures, and
leverage existing definitions from PerfSONAR, CAIDA, IPPM IETF WG, etc. On the other hand,
FP7 ICT PRISM [i.2]focused on the issue of privacy protection in the context of passive network monitoring; a
fundamental activity has been the specification of a semantic model. Finally, this work is supported by the FP7 ICT
DEMONS [i.3]; it focuses on distributed and cooperative network monitoring for fulfilling a variety of objectives
mostly centered around security, while it continues the work of PRISM with respect to personal data protection
leveraging semantic technologies.
Next clauses investigate the requirements that should drive the development of the MOI ontology. A few representative
use cases where the MOI ontology can be used are provided, while information domains and types that should be
specified in the ontology, such as Key Performance Indicators (KPI), are outlined. Moreover, in order to cope with the
personal data protection aspects, the underlying principles are also investigated. As a result, the set of requirements of
the ontology are defined, specifying both main features and global requirements, as well as the requirements for the
ontology structure.
5 KPI Descriptions and Mapping to MOI
Operators and private network managers require tools to manage the network, prevent and detect problems, plan and
engineer sections.
The Key Performance Indicators (KPI) serve the purpose of quantifying metrics that reflect factors critical for the
correct network behaviour in the sense of operational and/or business objectives. They help in the assessment of IP
service quality levels that meet user needs or service agreements. They measure and show the performance of critical
network services.
The KPIs will differ depending on the network architecture, business objectives, critical network sections or services,
application performance requirements, system reliability, etc. Different network managers will select, configure and
monitor different sets of KPIs. The KPIs are selected from parameters monitored by commercial or ad-hoc network
performance monitoring tools and they are usually monitored in a dashboard fashion for quick access.
These parameters have been target of study for recommendations from both ITU-T and IETF organizations. Their
recommendations make an effort in creating consistent definitions but anyway the metrics differ slightly, creating
multiple alternatives for similar objectives.
Without trying to be extensive or detailed in parameter definitions, a short review of defined parameters is presented,
trying to highlight (by grouping and specific comments) relations, similarities and discrepancies between parameter
definitions from different organizations. These discrepancies and large space of parameters for similar concepts raise
the need for a common semantic.
ETSI
10 ETSI GS MOI 002 V1.1.1 (2012-07)
ITU-T specifications are rooted on Recommendation Y.1540 [i.6]which defines parameters that may be used in
specifying and assessing the performance of speed, accuracy, dependability and availability of IP packet transfer
services. IETF's work is developed on the IP Performance Metrics (IPPM) framework [i.4]. Extensions of
ITU-T parameters for technologies like MPLS follow analogous definitions [i.5].
Many of the mentioned metrics can be modified by some statistical operators like: mean, minimum, median, quantile-
based limits, interval-based limits, peak, etc. In some recommendations, the operator results in the definition of a new
parameter.
5.1 Parameters Related to Delay or Delay Variation
• IP packet transfer delay (IPTD), defined as the time between ingress and egress time of a packet to a
network section [i.6].
• Type-P-One-way-Delay, as the time between the first bit of the packet in the wire at the source to the last bit
of the packet in the wire at the destination [i.7]. This, like any following "Type-P" metric is a set of metrics
where the "type-P" section makes reference to the type of packet used in the probe (ICMP ECHO Request,
TCP SYN, UDP packet, etc).
• Type-P-One-way-Delay-Poisson-Stream, defined as a sequence of packet probes from a Poisson process and
the one-way-delay measured by each one [i.7].
• Global multicast mean one-way delay, calculated as the sum of one-way delays for all successful IP packet
transfers divided by the total successful IP packet transfers at the registered multicast destinations [i.6].
• Multicast group mean one-way delay, calculated as the sum of mean IPTD delays for all destinations
divided by the number of registered destinations [i.8].
• One-way mean delay range over multicast group, One-way delay variation range over multicast
group [i.8].
• Type-P-Spatial-One-way-Delay-Vector, consisting of a vector of one-way delay measurements from the
source node to the destination nodes including nodes in the path [i.9]. Notice that ITU-T group parameters
differ from IETF spatial parameters due to the former refer to multicast groups and the latter to nodes in a
path.
• Type-P-Segment-One-way-Delay-Stream [i.9].
• Type-P-One-to-group-Delay-Vector, the set of one-way delays between source and destinations in a
multicast group [i.9]. This parameter supports also that the destination is not a multicast group but a single
host.
• 2-point packet delay variation (PDV), defined as the difference between the IPTD of a packet to a reference
packet IPTD. Difference options for the reference definition are available [i.6].
• Type-P-One-way-ipdv-Poisson-stream, measuring the delay variation (IPDV) between pairs of packets in a
Poisson stream [i.10]. IETF delay variation specifications are based on the difference between two successive
delay measurements while ITU-T Recommendation Y.1540 [i.6] PDV is based on observations on the delay
distribution. However, IETF specification has sufficient flexibility to produce whether inter-packet delay
variation or the delay variation by using a fixed minimum delay reference [i.11].
• Type-P-One way-ipdv-jitter, measuring the IPDV between consecutive packets and taking the absolute
values [i.10].
• Type-P-Round-trip-Delay-Poisson-Stream, as a sequence of packet probes from a Poisson process and the
round-trip-delay measured by each one [i.12].
• Type-P-Spatial-One-way-ipdv-Vector, consisting of a vector of Type-P-One-way-ipdv measurements to
nodes in the path from source to destination.
• Type-P-Segment-ipdv-prev-Stream [i.9].
• Type-P-One-to-group-ipdv-Vector [i.9].
ETSI
11 ETSI GS MOI 002 V1.1.1 (2012-07)
5.2 Parameters Related to Errors and Losses
• IP packet error ratio (IPER), defined as the ratio of total errored IP packets at the measurement point to the
total successful IP packet transfers [i.6].
• IP packet loss ratio (IPLR), defined as the ratio of total lost IP packets at the measurement point to the total
transmitted IP packets [i.6].
• Spurious IP packet rate, measuring the packets that appear at the egress measurement point that do not have
a corresponding ingress packet [i.6].
• IP packet severe loss block ratio (IPSLBR) [i.6].
• Type-P-One-way-Packet-Loss-Poisson-Stream, defined as a sequence of packet probes from a Poisson
process and the result of the probe reaching or not the destination measurement point [i.13]. IETF packet loss
definition differs from ITU-T Recommendation Y.1540 [i.6] IPLR in that errored packets are designated lost
in IETF's definition but not in ITU-T's one.
• Type-P-One-Way-Loss-Distance-Stream, measuring the distance in sequence numbers between two
successive losses [i.14].
• Type-P-One-Way-Loss-Period-Stream, identifying the losses in the same burst loss [i.14].
• Type-P-One-Way-Loss-Noticeable-Rate, a statistical operator on the previous one that considers not relevant
losses that are far apart [i.14].
• Type-P-One-Way-Loss-Period-Total, measuring the total number of loss periods [i.14].
• Type-P-One-Way-Loss-Period-Lengths, measuring the length (in packets) of the loss periods [i.14].
• Type-P-One-Way-Inter-Loss-Period-Lengths, measuring the distance between successive loss
periods [i.14].
• Multicast global loss ratio, measuring the sum of all lost packets divided by the sum of packets transmitted to
each destination while a member of the specified multicast group [i.8].
• Multicast mean group loss ratio, measuring the sum of all point-to-point IPLR divided by the number of
registered destinations that were members of the specified multicast group during the defined period [i.8].
• Loss ratio range over multicast group, Comparative multicast group delivery ratio [i.8].
• Type-P-Spatial-Packet-Loss-Vector, measuring whether the packet arrived to path members from source to
destination [i.9].
• Type-P-Segment-Packet-Loss-Stream [i.9].
• Type-P-One-to-group-Packet-Loss-Vector [i.9]. Notice that IETF the basic results for losses in multicast
groups in vector form while ITU-T aggregates these results [i.8].
5.3 Parameters Related to Packet Reordering, Replication and
Duplication
• IP packet reordered ratio (IPRR), defined as the ratio of reordered egress packets to the total of successful
IP packet transfers [i.6]. Extension to multicast groups is also available [i.8].
• Type-P-Reordered-Ratio-Stream, measuring the ratio of reordered packets in a stream [i.15].
• Type-P-Packet-Reordering-Extent-Stream, measuring the maximum distance in the reordering [i.15].
• Type-P-Packet-Late-Time-Stream, measuring the time distance in the reordering extent [i.15].
• Type-P-Packet-Byte-Offset-Stream, measuring the received bytes before a reordered packet [i.15].
ETSI
12 ETSI GS MOI 002 V1.1.1 (2012-07)
• Type-P-Packet-Reordering-Gap-Stream, Type-P-Packet-Reordering-GapTime-Stream, Type-P-Packet-
Reordering-Free-Run-x-numruns-Stream, Type-P-Packet-Reordering-Free-Run-q-squruns-Stream,
Type-P-Packet-Reordering-Free-Run-p-numpkts-Stream, Type-P-Packet-Reordering-Free-Run-a-
accpkts-Stream, Type-P-Packet-n-Reordering-Stream [i.15].
• IP packet duplicate ratio (IPDR) [i.6] (extensible to multicast groups [i.8]).
• Replicated IP packet ratio (RIPR) [i.6].
• Type-P-one-way-packet-arrival-count, counting the number of packets arriving for each packet sent [i.16].
• Type-P-one-way packet-duplication, indicating the number of additional copies of an individual packet
received by the destination in the time interval [i.16].
• Type-P-one-way-Packet-Duplication-Poisson-Stream, Type-P-one-way-Packet-Duplication-Periodic-
Stream [i.16].
5.4 Parameters Related to Connectivity and Service Availability
• Percent IP service unavailability (PIU), the percentage of total scheduled IP service time that is categorized
as unavailable. Availability is declared if the IPLR is smaller than 0.75 [i.6].
• Percent IP service availability (PIA) [i.6].
• Type-P-Instantaneous-Unidirectional-Connectivity, measuring whether a packet reached its destination or
not [i.18].
• Type-P-Instantaneous-Bidirectional-Connectivity [ i.18].
• Type-P-Interval-Unidirectional-Connectivity, if there is availability somewhen in an interval [i.18].
• Type-P-Interval-Bidirectional-Connectivity, Type-P1-P2-Interval-Temporal-Connectivity [i.18].
• Multicast group IP service availability, defined as the ratio of destinations in the available state and the total
destinations [i.8].
5.5 Throughput Related Parameters
• IP-layer Bits Transferred, IP-layer Link Capacity, IP-layer Path Capacity, IP-layer Used Link
Capacity, IP-layer Link Utilization, IP-layer Available Link Capacity, IP-layer Available Path Capacity,
IP-layer Tight Link Capacity [i.19].
• Bulk Transport Capacity, measuring the expected long term average data rate of a single ideal TCP
implementation over the path in question [i.17].
• Point-to-point IP packet rate (IPPR), measuring the total number of IP packet transfers per service-
second [i.8].
• Point-to-point octet-based IP packet rate (IPOR), the number of octets in the IP packets resulting in IP
packet transfers per service-second [i.8].
• Multicast group mean packet rate, as the sum of IPPR for all destinations divided by the number of
registered destinations [i.8].
• Multicast group mean octet-based IP packet rate, One-way packet rate range over multicast group [i.8].
ETSI
13 ETSI GS MOI 002 V1.1.1 (2012-07)
5.6 Operational Real-world KPIs
As explained before, KPIs depend on what a business or network administrator considers "Key" for their particular
objectives. This situation creates KPIs in the Information Technologies world that extends from the network parameters
presented to service availability or performance, device management issues, post-processed results, etc. As an example,
some KPIs present in use in medium-large networks are:
Availability parameters:
• Availability of key network nodes and links.
• Availability of the network core measured as the percentage availability of a set of critical links.
• Availability of key servers (percentage of time): directory servers, email servers, calendar servers, web servers,
application servers, etc. Availability can be measured from the internal network, from the exterior, from key
network locations, etc.
• Availability of Internet access: measured by contacting key selected Internet servers, by checking connectivity
with adjacent ISP router, by checking reach ability to a set of destinations, etc.
Performance parameters:
• Average times: time to login, time to deliver emails between exchange servers.
• Percentage of requests to key servers that are resolved in less than a maximum time.
• Average (or maximum) utilization on key network links.
• Average (or maximum) utilization of key servers.
6 Information Models Requirements for IP Traffic
Monitoring Applications
This Work Item benefits from the activities of the previous Work Item on the analysis of ontologies for IP traffic
measurements and the associated document [1], while it leverages realistic use cases for extracting practical
requirements for the ontology of IP traffic measurements. In order to complete the conceptual model, Quality of
Service, as perceived by the users, elements and complex parameters to quantify business issues related to service level
agreements are also included so that future developments, based on objective TMA (traffic monitoring and analysis)
systems, can be used to such purpose.
6.1 Use Case Scenarios
This clause illustrates the application of KPI and IP network descriptors to manage practical situations in order to
extract conceptual relationships required to deal with them within a universal and coherent approach. Obvious
parameters requirements are skipped so that the focus is put on characteristics that might give rise to lack of
interoperability between network characterization mechanisms.
ETSI
14 ETSI GS MOI 002 V1.1.1 (2012-07)
6.1.1 IP Networks Characterisation
Aside from the general concepts of time, address, hops, neighbouring, packet size or the more specific ones related to
session parameters, routing, synchronization, etc., a MOI ontology should be open enough to characterize any IP service
through simple traffic measurements carried out either by the network elements (hosts and routers) or probes. In the
following, a series of use cases are presented to extract concepts and relations that should be taken into account just to
describe an IP network:
a) End to end routes characterization: The user asks the system which routes can be used to connect two nodes
of the network and wishes to know their characteristics. This brings elemental objects and topology parameters
like host, router, node (address), neighbour, hop counting, length, traceroute, AS (autonomous system),
Topology concepts are essential in IP networks and MOI should deal with them following classical conceptual
models: node-link-route, length, routes passing a node. Furthermore, additional concepts like port, socket, ring,
tree, source and destination should be added to construct the MOI.
b) Network topological characterization: Similar concepts may be required by different questions like:
• Maximum number of hops between two nodes of a given network (domain).
• Number of direct neighbours to a given node.
• Nodes in a tree.
• Distribution of paths per length in a given domain.
This extend the concepts of node, address (with a semantic address notation) to parent-son dependency, net, sub-net and
attributes to specific nodes like gateway, server, probe, etc. Furthermore, MOI would include rules for format exchange
as far as all these objects and attributes concern in order to increase the ontology usability; for example, IP address can
be stored in dot notation, as integer or any other format.
Some details like the required distinction between node (host, gateway, router, etc.) and IP address should be
highlighted and need the corresponding ontological differentiation. Besides, IPv6 should also be considered for the MOI
set up as far as covering and translating concepts like subnet or the simple address notation concerns.
6.1.2 QoS Measurements in IP Networks
Traffic monitoring aims at supervising network services indeed. Analysing the network topology can be used to
understand what may cause connectivity troubles and so help managing the services but their performance has to be
checked by direct measurements. Devices to accomplish such task should use the same data to support coherent
operation systems. Such interoperability relies on a common MOI compliant with use cases like the following ones:
a) Bandwidth availability monitoring: The user asks the system to check the bandwidth availability for a given
connectivity service between two hosts, either in the same domain or in different ones. This complements a
(static) vision of the network to show not only its topology but its capacity link by link and serves to
monitoring (dynamically) its behaviour. The tools to accomplish such task and the accuracy to present data
may vary but the conceptual entities are simple: One way and round trip bandwidth available end to end (e2e)
in uplink and downlink direction.

Related to this simple use case, for operational purposes, the user of an IP monitoring system could be
interested in:
• Determining the flows maintained through links of a given path.
• Knowing the percentage of the capacity e2e that is used by established flows between the two ends or by
specific applications. This capacity analysis requires measurements and data mining on objects like flow,
and protocols related to upper layers in the OSI stack (session and application, at least) to care about
connection oriented services if the MOI is going to provide QoS measuring support.
Thus such objects and their measuring should be included in the MOI namely flow, protocol and attributes to
characterize packets as part of a flow or multicast service, whether it is an ACK, ERROR message, signalling packet or
if it has been sent to duplicate a previous (failed) one.
ETSI
15 ETSI GS MOI 002 V1.
...