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, . [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, DOI 10.17487/RFC2678, September 1999, . [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, . 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, . [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, . [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, . [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, DOI 10.17487/RFC5560, May 2009, . [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, . [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, . [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, . [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, . Author's Address Wei Ding Southeast University Nanjing 211189 China Email: wding@njnet.edu.cn Ding Expires 15 April 2023 [Page 18]