Internet DRAFT - draft-ding-ibbm-framework
draft-ding-ibbm-framework
Network Working Group W. Ding
Internet-Draft Southeast University
Intended status: Informational 12 October 2022
Expires: 15 April 2023
Framework For Internet Basic Behavior Measurement Metrics System
draft-ding-ibbm-framework-01
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.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ding Expires 15 April 2023 [Page 1]
Internet-Draft Framework for IBBM October 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Criteria For Internet Basic Behavior Metrics . . . . . . . . 4
4. Metric Subjects . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Basic Protocols . . . . . . . . . . . . . . . . . . . . . 5
4.2. Network Components . . . . . . . . . . . . . . . . . . . 6
4.3. Representation of Subjects . . . . . . . . . . . . . . . 6
4.3.1. Basic Protocols . . . . . . . . . . . . . . . . . . . 6
4.3.2. Network Components . . . . . . . . . . . . . . . . . 6
5. Metric Topics . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Routing Measurement . . . . . . . . . . . . . . . . . . . 7
5.2. Performance Measurements . . . . . . . . . . . . . . . . 7
5.2.1. IP Performance Measurements . . . . . . . . . . . . . 7
5.2.2. Network Device Performance Measurements . . . . . . . 7
5.2.3. Service Performance Measurements . . . . . . . . . . 7
5.3. Domain Name Resolution Measurements . . . . . . . . . . . 8
5.4. Traffic Measurements . . . . . . . . . . . . . . . . . . 8
6. Metric Entity . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Classes of Metric Entities . . . . . . . . . . . . . . . 8
6.2. Description of Metric Entity Classes . . . . . . . . . . 9
6.2.1. Data Types . . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Formal Description . . . . . . . . . . . . . . . . . 10
7. Elements of A Metric . . . . . . . . . . . . . . . . . . . . 12
8. Internet Basic Behavior Measurement Activity . . . . . . . . 14
8.1. Attributes of Measurement Activity . . . . . . . . . . . 14
8.2. Measurement Result . . . . . . . . . . . . . . . . . . . 15
9. Metric Fusion . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Ding Expires 15 April 2023 [Page 2]
Internet-Draft Framework for IBBM October 2022
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
Ding Expires 15 April 2023 [Page 3]
Internet-Draft Framework for IBBM October 2022
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:
* The purpose and significance of setting up this metric. The
purpose and value of the Metric in Internet management, security
control, and other aspects SHOULD be described.
Ding Expires 15 April 2023 [Page 4]
Internet-Draft Framework for IBBM October 2022
* The specific content of Metric's elements listed in Section 7.
* A Measurement Activity case including Measurement Source Data
objects and Analysis Model adopted, conforming to the format
specified in Section 8. Because all Metrics MUST be measurable,
that is, the proposer of the metric SHOULD ensure that at least
one Measurement Source Data and Analysis Model can support the
measurement of the Metric.
* Other supplementary contents which are not included in the above
three items MUST 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:
* Routing protocols
All interdomain routing protocols and intradomain routing
protocols with RFC standards that are used on the Internet,
including BGP, etc.
* Network-layer protocols
IP and ICMP.
* Transport-layer protocols
TCP, UDP, and other RFC-specified transport-layer protocols that
can be carried by IP packets.
* DNS protocol
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.
Ding Expires 15 April 2023 [Page 5]
Internet-Draft Framework for IBBM October 2022
4.2. Network Components
The network components that MAY be used as Metric subjects include
the following categories:
* Device
Including Network Device and End System Device;
* Link
Channels that connect devices;
* Network
Collections of devices and links that can communicate with each
other using private IP addresses;
* Service
Application-oriented software system that runs over the Internet;
* AS
Groups of routers, links, and networks with the same AS number
under the control of one administrator.
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"
Ding Expires 15 April 2023 [Page 6]
Internet-Draft Framework for IBBM October 2022
* 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.
Ding Expires 15 April 2023 [Page 7]
Internet-Draft Framework for IBBM October 2022
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:
* End System (EndSystemClass)
Devices that have reachable routing IP addresses on the Internet
and are connected to the network as end hosts, such as servers,
clients, IoT devices, etc. When used as entity objects that carry
Metrics, they SHALL be classified into this metric entity class
and are directly identified by IP addresses.
* IP Prefix (IPPrefixClass)
The network parts of the IP addresses when using CIDR, which are
identified in the form of "IP address/prefix-length".
* Connection Point (ConnPointClass)
Ding Expires 15 April 2023 [Page 8]
Internet-Draft Framework for IBBM October 2022
The endpoints of transport layer connections on the Internet,
which are identified in the form of "IP address: port". The value
of port is an integer falling in 0..65535, which indicates the
"port" field in TCP and UDP header.
* Network Device (NetDeviceClass)
Devices used to forward IP packets on the Internet, including
routers, switches, and access devices. We use a structure with 8
fields to identify a network device - vendor identification,
vendor type, AS number, equipment type, longitude, latitude, MAC,
and spare information. We suggest using the vendor number (OID)
in the MIB to represent the producer identification, and the
equipment type SHOULD be one of Router | Switch | AccessPoint |
Others. For routers and switches, MAC and spare information are
optional. If the first six fields cannot distinguish two devices,
the optional fields could be used to support this distinction.
For AP devices, longitude, latitude, and spare information are
optional.
* Autonomous System (ASClass)
As described in Section 4.2, we suggest identifying autonomous
systems by the corresponding AS numbers.
* Link (LinkClass)
A link refers to a single link-layer connection between two
network devices or between an end system and a network device. A
link is identified by an IP address pair.
* Path (PathClass)
A path is a sequence of links that connect end to end. It is
identified by the sequence of IP addresses.
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;
Ding Expires 15 April 2023 [Page 9]
Internet-Draft Framework for IBBM October 2022
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
Ding Expires 15 April 2023 [Page 10]
Internet-Draft Framework for IBBM October 2022
"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"
}
Ding Expires 15 April 2023 [Page 11]
Internet-Draft Framework for IBBM October 2022
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
Ding Expires 15 April 2023 [Page 12]
Internet-Draft Framework for IBBM October 2022
"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
Ding Expires 15 April 2023 [Page 13]
Internet-Draft Framework for IBBM October 2022
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
Ding Expires 15 April 2023 [Page 14]
Internet-Draft Framework for IBBM October 2022
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:
* The value type of the measurement value MUST be consistent with
the "Representation" element in the Metric Specification for which
the measurement is performed. See Section 7 for the
"Representation" element.
Ding Expires 15 April 2023 [Page 15]
Internet-Draft Framework for IBBM October 2022
* The measurement time is the time to obtain the " measurement
value", expressed in a 2-tuple [start time, duration]. If the
duration is zero, the measurement time is instantaneous;
Otherwise, it's a period. The RECOMMENDED default time unit is
second. Otherwise, it SHOULD be specified. In general, the
measurement time is obtained based on the Measurement Source Data.
* Entity objects: as described in Article 6 in Section 8.1.
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
Ding Expires 15 April 2023 [Page 16]
Internet-Draft Framework for IBBM October 2022
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, May 1998,
<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, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <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, July 2001,
<https://www.rfc-editor.org/info/rfc3148>.
Ding Expires 15 April 2023 [Page 17]
Internet-Draft Framework for IBBM October 2022
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/info/rfc5136>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric",
RFC 5560, DOI 10.17487/RFC5560, May 2009,
<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, April 2010,
<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, October 2011,
<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, January
2016, <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, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
Author's Address
Wei Ding
Southeast University
Nanjing
211189
China
Email: wding@njnet.edu.cn
Ding Expires 15 April 2023 [Page 18]
