Ippm Workgroup RFCs

Browse Ippm Workgroup RFCs by Number

RFC2330 - Framework for IP Performance Metrics: The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC2679 - A One-way Delay Metric for IPPM: This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]
RFC2680 - A One-way Packet Loss Metric for IPPM: This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]
RFC2681 - A Round-trip Delay Metric for IPPM: This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]
RFC3148 - A Framework for Defining Empirical Bulk Transfer Capacity Metrics: This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.
RFC3357 - One-way Loss Pattern Sample Metrics
RFC3393 - IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)
RFC3432 - Network performance measurement with periodic streams: This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]
RFC3763 - One-way Active Measurement Protocol (OWAMP) Requirements: With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.
RFC4148 - IP Performance Metrics (IPPM) Metrics Registry: This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.; This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.; IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC4656 - A One-way Active Measurement Protocol (OWAMP): The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]
RFC4737 - Packet Reordering Metrics: This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]
RFC5136 - Defining Network Capacity: Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community.
RFC5357 - A Two-Way Active Measurement Protocol (TWAMP): The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]
RFC5388 - Information Model and XML Data Model for Traceroute Measurements: This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]
RFC5481 - Packet Delay Variation Applicability Statement: Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.; Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.
RFC5560 - A One-Way Packet Duplication Metric: When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.; In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]
RFC5618 - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP): This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]
RFC5644 - IP Performance Metrics (IPPM): Spatial and Multicast: The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]
RFC5835 - Framework for Metric Composition: This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5938 - Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP): The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]
RFC6038 - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features: This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]
RFC6049 - Spatial Composition of Metrics: This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]
RFC6248 - RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete: This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6349 - Framework for TCP Throughput Testing: This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCP Throughput. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6534 - Loss Episode Metrics for IP Performance Metrics (IPPM): The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]
RFC6576 - IP Performance Metrics (IPPM) Standard Advancement Testing: This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.
RFC6673 - Round-Trip Packet Loss Metrics: Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.; This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]
RFC6703 - Reporting IP Network Performance Metrics: Different Points of View: Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6802 - Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets: This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC6808 - Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track: This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC7290 - Test Plan and Results for Advancing RFC 2680 on the Standards Track: This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680.
RFC7312 - Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM): To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.
RFC7398 - A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance: This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.
RFC7497 - Rate Measurement Test Protocol Problem Statement and Requirements: This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.
RFC7679 - A One-Way Delay Metric for IP Performance Metrics (IPPM): This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete.
RFC7680 - A One-Way Loss Metric for IP Performance Metrics (IPPM): This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.
RFC7717 - IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP): The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.
RFC7718 - Registries for the One-Way Active Measurement Protocol (OWAMP): This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.
RFC7750 - Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP): This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.
RFC7799 - Active and Passive Metrics and Methods (with Hybrid Types In-Between): This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.
RFC7820 - UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP): The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.
RFC8186 - Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP): This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.
RFC8250 - IPv6 Performance and Diagnostic Metrics (PDM) Destination Option: To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.
RFC8321 - Alternate-Marking Method for Passive and Hybrid Performance Monitoring: This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.
RFC8337 - Model-Based Metrics for Bulk Transport Capacity: This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.; Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.; For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.
RFC8468 - IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework: This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.
RFC8545 - Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP): This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.; This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.
RFC8762 - Simple Two-Way Active Measurement Protocol: This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.
RFC8889 - Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring: The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking".
RFC8911 - Registry for Performance Metrics: This document defines the format for the IANA Registry of Performance; Metrics. This document also gives a set of guidelines for Registered; Performance Metric requesters and reviewers.
RFC8912 - Initial Performance Metrics Registry Entries: This memo defines the set of initial entries for the IANA Registry of; Performance Metrics. The set includes UDP Round-Trip Latency and; Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP; Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,; ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss.
RFC8913 - Two-Way Active Measurement Protocol (TWAMP) YANG Data Model: This document specifies a data model for client and server; implementations of the Two-Way Active Measurement Protocol (TWAMP).; This document defines the TWAMP data model through Unified Modeling; Language (UML) class diagrams and formally specifies it using the; YANG data modeling language (RFC 7950). The data model is compliant; with the Network Management Datastore Architecture (NMDA).
RFC8972 - Simple Two-Way Active Measurement Protocol Optional Extensions: This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762.
RFC9097 - Metrics and Methods for One-Way IP Capacity: This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical Maximum IP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement.
RFC9197 - Data Fields for In Situ Operations, Administration, and Maintenance (IOAM): In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.
RFC9198 - Advanced Unidirectional Route Assessment (AURA): This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology based on the IP Performance Metrics (IPPM) framework (RFC 2330). This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.
RFC9322 - In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags: In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags.
RFC9326 - In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting: In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document.
RFC9341 - Alternate-Marking Method: This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.
RFC9342 - Clustered Alternate-Marking Method: This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC 8889.
RFC9359 - Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities: This document describes a generic format for use in echo request/reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER).
RFC9378 - In Situ Operations, Administration, and Maintenance (IOAM) Deployment: In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance.
RFC9486 - IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM): In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6.
RFC9503 - Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks: Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies Simple Two-Way Active Measurement Protocol (STAMP) extensions (as described in RFC 8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972.
RFC9506 - Explicit Host-to-Network Flow Measurements Techniques: This document describes protocol-independent methods called Explicit Host-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied.
RFC9533 - One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group: This document defines extensions to the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links.
RFC9534 - Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group: This document extends Simple Two-way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links.
RFC9544 - Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs): This document defines a set of metrics for networking services with; performance requirements expressed as Service Level Objectives; (SLOs). These metrics, referred to as "Precision Availability Metrics; (PAMs)", are useful for defining and monitoring SLOs. For example,; PAMs can be used by providers and/or customers of an RFC 9543 Network; Slice Service to assess whether the service is provided in compliance; with its defined SLOs.