Internet-Draft Framework for IBBM October 2022
Ding Expires 15 April 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ding-ibbm-framework-01
Published:
Intended Status:
Informational
Expires:
Author:
W. Ding
Southeast University

Framework For Internet Basic Behavior Measurement Metrics System

Abstract

This document provides a definition of Internet Basic Behavior Measurement(IBBM) based on the Internet architecture and describes in detail the specifications to be followed for the measurement metrics and measurement activities under IBBM, which are given in the form of elements. The main purpose of this document is to standardize the accurate meaning and expression of metrics obtained based on Internet behavioral measurement activities, to improve the use efficiency and worth of the measurement results.

Requirements Language

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 RFC 2119.

Status of This Memo

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 https://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 15 April 2023.

▲

Table of Contents

1. Introduction

This document constructs an extensible framework to regulate the metrics and measurement activities in the field of Internet Basic Behavior Measurement, to support comprehensive, effective, and standardized management and monitoring of the Internet. More specific intentions are reflected in the following aspects:

1)
Utilizing unified metrics to support characterization of various network activities and standardized description of the running states of the Internet from the perspective of basic behavior. The characterizations of network activities help managers to control the operation of the network and supports locating existing or possible anomalies and threat activities in the networks. The standardized description of the running state of the Internet can support the preservation of the running tracks and prediction of the overall or partial running states of the Internet.
2)
Supporting the sharing and analysis for various intents of measurement results through the standardized description of measurement metrics and measurement activities, thereby improving the use efficiency of measurement results and expanding its use scope.
3)
This document is more inclined to support engineering, practice, and application in the field of Internet Basic Behavior measurement, and provide analytical data for scientific research in this field.
4)
This document is more inclined to support accurate description and normative expression of the measurement results of Internet Basic Behavior and does not involve the discussion of measurement methods, measurement accuracy, application intention, etc.

2. Terminology

The following list gives definitions that need to be clarified in the development of this framework.

Internet Basic Behavior Measurement
A process of quantifying the characteristics and laws of the subjects in Internet architecture when networks are running. In principle, measurements taken in simulated network environments are not Internet Basic Behavior Measurements.
Internet Basic Behavior Measurement Metric

The meaning and manifestation of results of Internet Basic Behavior measurements (hereinafter referred to as "Metric").

Describing the elements of basic Internet Behavior Measurement Metrics is the main purpose of this document, and the relevant content will be given in Sections 4-7.

Internet Basic Behavior Measurement Activity

A series of operations performed to measure specific Internet Basic Behavior Measurement Metrics (hereinafter referred to as "Measurement Activity"). The Internet Basic Behavior Measurement Activity consists of two phases:

(i) Acquisition of Internet Basic Behavior Measurement Source Data. It refers to obtaining traffic and operating data from the Internet, including original or time-stamped packet (header) sequences, flow records, flow tables, routing tables and MIBs, etc., hereinafter referred to as "Measurement Source Data";

(ii)Modeling analysis. Modeling analysis is the mapping from Measurement Source Data objects to Metric instances. The scheme used to do this mapping is called the "Analysis Model".

Because a Metric instance could be obtained from different types of Measurement Source Data and by different Analysis Models, the details of methods of obtaining Measurement Source Data and modeling analysis will not be discussed in this document. Other elements of Measurement Activities will be detailedly described in Section 8. The description and requirements of measurement activities can ensure the operability of Metrics and the storability of measurement results.

3. Criteria For Internet Basic Behavior Metrics

Metrics MUST be useful for the safe operation and management of the Internet.

This document does not provide any Metric but provides a framework for defining and describing what a Metric SHOULD be like. Metrics MAY be developed individually or in groups by the proposers as specifications conforming to this framework (hereinafter referred to as "Metric Specification"). In each Metric Specification, the following items SHOULD be explained:

4. Metric Subjects

As the measurement is oriented to Internet Basic Behavior, Metrics SHOULD have clear behavior Subjects. Subjects SHOULD have clear meanings in Internet architecture and can work continuously and stably in the long term. Based on the existing Internet architecture, this document divides all Subjects into two categories: the basic protocols and the network components that support the operation of the Internet. The details are given below.

4.1. Basic Protocols

The basic protocols that MAY be used as the Metric subjects include:

It SHOULD be further noted that all link-layer protocols and all application-layer protocols that do not belong to the above protocols SHOULD NOT be regarded as the subjects of Internet Basic Behavior Measurement Metrics because they could be easily changed and replaced.

4.2. Network Components

The network components that MAY be used as Metric subjects include the following categories:

4.3. Representation of Subjects

To formally represent subjects, this section provides each subject a unique name for identification and description.

4.3.1. Basic Protocols

Basic protocols are abbreviated by the protocols' names, such as TCP, UDP, IP, ICMP, BGP, DNS, etc.

4.3.2. Network Components

The network components are represented by the subjects' names or abbreviations:

  • Device:"NetDevice" or "EndDevice"
  • Link:"Link"
  • Network:"Network"
  • Service:"Service"
  • AS:"AS"

5. Metric Topics

To facilitate management and use, Metrics could be separated into several topics by semantics, including Routing Measurements, Performance Measurements, Domain Name Resolution Measurements, Traffic Measurements, and Other Measurements. With the exception of Other Measurement topics, each topic with a specific meaning should be presented with a separate framework document describing the specific requirements and specifications for that topic to be followed by measurements within the scope of the topic. The scope of metrics' topics MAY be expanded as needed, such as IPv6 measurements. The meanings and scope of the existing four topics are described as follows:

5.1. Routing Measurement

Metrics oriented to routing information, routing protocols, and routers' attributes that are running on the Internet fall within this topic.

5.2. Performance Measurements

This topic includes three typical directions:

5.2.1. IP Performance Measurements

Metrics that measure the performance of IP networks in the actual operation of the Internet during data transmission are IP Performance Metrics.

5.2.2. Network Device Performance Measurements

Metrics that measure the individual performance of devices on the Internet in operation and data transmission are network device performance Metrics.

5.2.3. Service Performance Measurements

Metrics of the time required by the server software running on the Internet to complete specific service tasks are service performance Metrics.

5.3. Domain Name Resolution Measurements

Metrics that locate active DNS servers on the Internet and describe their service properties and capabilities fall within this topic.

5.4. Traffic Measurements

Traffic refers to the sequence of IP packets obtained from the running network without active injection of test traffic. Metrics based on traffic acquisition fall within this topic, but the specification of the process of acquiring, compressing, and storing traffic is outside the scope of this document. In principle, all Metrics under this topic SHOULD only be obtained based on passive measurement methods, however, some metrics, such as DNS response time for resolving IP addresses, end-to-end packet loss, etc., may also be obtained based on traffic, but they are outside the topic of traffic measurement.

6. Metric Entity

Metric entities are elements of the Internet architecture that can carry the results of measurements. Measurement Activities MAY be carried out for different entity objects under the fixed entity types. Standardizing the description of metric entities facilitates the storage, use, and fusion of measurement results.

6.1. Classes of Metric Entities

Any metric entity that carries the Internet Basic Behavior Measurement is a stable and uniquely identifiable existence on the Internet. Metric Entities include but are not limited to the following seven categories:

6.2. Description of Metric Entity Classes

This section provides a JSON-based description of the seven entity types defined in the previous section.

6.2.1. Data Types

The data types used in the description include:

  • string - indicates a string of finite length;
  • string63 - indicates string with no more than 63 characters;
  • unsigneddInt - indicates integer ranging from 0 to 2^32-1;
  • unsignedShort - indicates integer ranging from 0 to 2^16-1;
  • float - indicates floating number;
  • bool - indicates boolean value;
  • inetAddress - indicates Ipv4 or ipv6 address. An ipv4 address is represented as a string in dotted-decimal notation. An ipv6 address is represented as a string in standard notation (hexadecimal numbers connected with ":").
  • prefixLength - indicates the prefix length of an ipv4 or ipv6 address. For the ipv4 address prefix, it is an integer ranging from 0 to 32. For the ipv6 address prefix, it is an integer ranging from 0 to 128.

6.2.2. Formal Description

In the following JSON-based description, "(data type | entity type)" denotes the value of this data type or entity type, "[data type | entity type]" denotes an array of this data type or entity type. Refer to 6.2.1 for data type description and 6.1 for entity type description.

  • End System

      "EndSystemClass": {
    "IP": (inetAddress)
  }

  • IP Prefix

      "IPPrefixClass":{
    "Prefix":(inetAddress),
    "Prefix Length": (prefixLength)
  }

  • Connection Point

      "ConnPointClass":{
    "IP": (inetAddress),
    "Port": (unsignedShort)
  }

  • Network Device

      "NetDeviceClass":{
    "Vendor ID": (unsignedInt),
    "#Vender ID":"0 indicates unknown",
    "Vender Type": (string),
    "#Vender Type":""" indicates unknown",
    "ASN": (unsignedInt),
    "#ASN":"0 indicates unknown"
    "Type":
      "Router"|"Switch"|"AccessPoint"|"Others",
    "Longitude": (float),
    "#Longitude":"0.0 indicates unknown",
    "Latitude": (float),
    "#Latitude":"0.0 indicates unknown",
    "MAC": (string),
    "#MAC":""" indicates unknown"
    "Spare Information": (unsignedInt),
    "#Spare Information":"0 indicates unknown"
  }

  • Autonomous System

      "ASClass":{
    "ASN":(unsignedInt)
  }

  • Link

      "LinkClass":{
    "IPa": (inetAddress),"
    "IPb" :(inetAddress),
    "Direction": (bool),
    "#Direction":
      " "ture/false" indicates that IPa to
      IPb is bidirectional/unidirectional"
  }

  • Path

      "PathClass": {
    "Links": [inetAddress],
    "#Links":"A series of IP Address, such as [ip1,ip2,ip3,...]",
    "Direction":(bool),
    "#Direction":"0 indicates unidirectional(ip1->ip2->ip3->...),
                  1 indicates bidirectional"
  }

When a new entity type of Internet Basic Behavior metrics is added, its name, description, and formal description SHOULD be given in the above form at the same time.

7. Elements of A Metric

Metric Specifications under the framework MUST clarify the following elements:

(i)

Name

"Name" is the identifier of a Metric that MUST be unique in the context of all relevant Internet Basic Behavior Measurement fields. It is suggested to use English words connected with "_" that reflect the core semantics of the metric. If the topic to which the Metric belongs has special naming requirements for the Metrics under the subject's independent framework, the naming of this Metric SHOULD comply with its requirements.

(ii)

Representation

"Representation" describes the data structure of the quantitative results of a metric. It includes the types of number, string, network address, set and undirected graph, etc. It is RECOMMEDED that the proposer of the metric SHOULD describe them in JSON.

(iii)

Topic

"Topic" SHOULD be specified as one of "Routing Measurement", "Topology Measurement", "DNS Measurement", "Traffic Measurement" or "Performance Measurement" (See Section 5 for details).

(iv)

Subject

"Subject" is a non-empty set of metric subjects(See section 4 for details).

(v)

Entity

"Entity" is a structure of entity types that hosts this metric (See Section 6 for details). JSON is the RECOMMENDED format for this structure's description. The entity types in a structure can be the same or different.

(vi)

Semantics

"Semantics" is the meaning of the metric containing the description of each element in the data structure given by the "Representation" element. It MAY be a descriptive definition or a model representation based on mathematical symbols. The description of metric semantics MUST be basic, normative, and unambiguous no matter what method is adopted. For items whose value range includes numerical values, the metric unit to be used MUST also be given, which MUST be in international metric units.

(vii)

Attribute

"Attribute" consists of two sub-elements: a) Basic attribute. According to the semantics and characteristics of the metric, the value SHOULD be one of structural| characteristic|sample|other. A Metric composed of one or more entity objects of different entity types (see Section 6 for entity types) and contains a relatively stable specific structural relationship among entity objects is called a structural metric, such as networks' topologies; a metric that describes the inherent characteristics of an entity object is called a characteristic metric, such as the capacity of a link. A characteristic metric is relatively stable so could also be called a static metric; the metric based on a specific Measurement Source Data and analyzed by the Analysis Model is called a sample Metric; Metrics that can not be described by the above attributes are uniformly called other metrics. The proposer of such metrics SHOULD try to give appropriate explanations and descriptions of other metrics. b) Fusible attribute. Fusible attribute refers to whether the measurement result of this metric could perform the fusion activities. For the definition and related content of the fusion activity, see Section 9.

(viii)

Parameter

"Parameter" is a set of parameters (name & type) that MUST be used during the measurement, which MAY be empty. For example, the agreement on unit time， the bandwidth usage threshold when congestion occurs, etc. The semantics of these parameters SHOULD be reflected in the metric's "Semantics" element. The parameter set is RECOMMEDED to be given in JSON.

(ix)

Others

The metric's description information that is not included in the above elements but MUST be explained. This element would be empty if there is no need.

8. Internet Basic Behavior Measurement Activity

Measurement Activities MUST only be carried out for Metrics that have completed Metric Specifications. A Measurement Activity SHOULD be described as an 8-tuple [Measurement Activity's Name, Metric's Name, Metric's Parameter, measurement method, measurement point, entity object, Measurement Source Data, measurement results]. The front 7 items are the attributes of the Measurement Activity, that is, each Measurement Activity instance MUST have a unique identification, and only be oriented to one Metric at the same measurement point, using the same measurement method and under the conditions with the same parameters; the measurement result is a collection of triples like [measurement time, entity object, measurement value].

8.1. Attributes of Measurement Activity

(i)

Measurement Activity Name

It refers to the identifier of the Measurement Activity, which uniquely identifies the Measurement Activity. A measure activity name is ADVISED to be expanded based on the name or number that can uniquely identify the organizations or individuals that perform the measurement. The organizations or individuals who perform the Measurement Activity SHALL be responsible for the measurement results and have the obligation to further explain the measurement results when necessary.

(ii)

Metric

It refers to the name of the Metric targeted by this Measurement Activity(see Section 7 for details).

(iii)

Metric Parameter

It refers to the specific value of each parameter described in the "Parameter" element of the Metric Specification in this Measurement Activity. The "Parameter" element is referred to Article 8 in Section 7.

(iv)

Measurement Method

It refers to the description of the Analysis Model used in this Measurement Activity, that is, the algorithm or model used in the process of mapping a Measurement Source Data object into a Metric value, which is described in natural language or pseudocode. The Analysis Model is defined in section 2.

(v)

Measurement Point

It refers to the network location where the Measurement Source Data is obtained.

(vi)

Entity Object

It refers to a sequence of network entity objects that carry the Metric. The type of all entity objects in the sequence MUST be consistent with the description of the Metric element "Entity" in the corresponding Metric Specification. If the measurement is performed for different entity objects, the value of this attribute is null and will be marked in "Measurement Results".

(vii)

Measurement Source Data

It refers to a description of the Measurement Source Data used in this Measurement Activity and acquired at the measurement point, which follows the definition in section 2, along with the parameters associated with these Measurement Source Data (e.g., the sampling rate for passively collecting traffic).

8.2. Measurement Result

When the "entity object" attribute of the Measurement Activity is non-null, the measurement result of the Measurement Activity is a sequence of 2-tuples [measurement time, measurement value], otherwise, the measurement result is a sequence of triples [measurement time, measurement value, entity object]. A more specific explanation is as follows:

9. Metric Fusion

The procedure of processing the measurement results or fusion results through combination, statistics, etc. is called metric fusion, such as the combination of topology graphs, the mean or median of the sample metrics, etc. Metric fusion is carried out by metric fusion activities towards completed Measurement Activities or fusion activities. Metric fusion activities are described as a 6-tuple: [fusion activity name, Metric, description, fusion object, fusion model, fusion result]. The detailed description is as follows:

(i)

Fusion Activity Name

It refers to an identifier of the fusion activity. It is used to uniquely identify the fusion activity. It is ADVISED to be expanded based on the name or number that uniquely identifies the organizations or individuals performing this fusion activity and distinguished from the Measurement Activity name through a standard suffix. The organizations or individuals that carry out this fusion activity are responsible for the result of this fusion and have the obligation to further explain the results of the fusion as needed.

(ii)

Metric

It refers to the Metric for which the fusion activity is oriented, as described in Article 1) in Section 7. In particular, sub-element b) of the "Attribute" elements of the Metric in the fusion activity SHOULD be marked as " Fusible".

(iii)

Description

It refers to a general description of the intention of this fusion activity and other matters that need to be explained.

(iv)

Fusion Object

The measurement results and fusion results of the collection of completed measurement activities and fusion activities are the fusion objects of this fusion activity. It SHOULD be noted that all the results of measurement activities and fusion activities that are fusion objects MUST have the same metric. In general, the measurement results have the same structure.

(v)

Fusion Model

It refers to the description of the Analysis Model (or algorithm) used in this fusion activity.

(vi)

Fusion Result

It is as same as measurement result.

10. Security Considerations

TBD

11. IANA Considerations

This document has no actions for IANA.

12. Informative References

[RFC2330]
Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, , <https://www.rfc-editor.org/info/rfc2330>.
[RFC2544]
Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, , <https://www.rfc-editor.org/info/rfc2544>.
[RFC2678]
Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, DOI 10.17487/RFC2678, , <https://www.rfc-editor.org/info/rfc2678>.
[RFC3148]
Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, , <https://www.rfc-editor.org/info/rfc3148>.
[RFC3393]
Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, , <https://www.rfc-editor.org/info/rfc3393>.
[RFC5136]
Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, , <https://www.rfc-editor.org/info/rfc5136>.
[RFC5481]
Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, , <https://www.rfc-editor.org/info/rfc5481>.
[RFC5560]
Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, DOI 10.17487/RFC5560, , <https://www.rfc-editor.org/info/rfc5560>.
[RFC5853]
Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, DOI 10.17487/RFC5853, , <https://www.rfc-editor.org/info/rfc5853>.
[RFC6390]
Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, , <https://www.rfc-editor.org/info/rfc6390>.
[RFC7679]
Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, , <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680]
Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, , <https://www.rfc-editor.org/info/rfc7680>.

Author's Address

Wei Ding
Southeast University
Nanjing
211189
China