In-situ OAM (ioam)

WG Name In-situ OAM
Acronym ioam
Area Routing Area (rtg)
State Abandonded
Charter charter-ietf-ioam-00-02 Not currently under review
Dependencies Document dependency graph (SVG)
Personnel Chair Tal Mizrahi
Area Director Alvaro Retana
Mailing list Address ioam@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/ioam
Archive https://mailarchive.ietf.org/arch/browse/ioam/
Jabber chat Room address xmpp:ioam@jabber.ietf.org?join
Logs https://jabber.ietf.org/logs/ioam/

Charter for Working Group

In-situ OAM provides real-time telemetry of individual data packets and flows. It is based on telemetry information which is embedded within live user traffic. In this context ‘live user traffic’ refers to packets originated and terminated at the application layer. The IOAM WG intends to define data formats and associated procedures for in-situ OAM, including mechanisms for capturing path and path-traversal related information as well as procedures to employ, configure, trigger, and export the embedded telemetry information.

The IOAM WG will define the following in-situ OAM components:

* Data-records for in-situ OAM will include attributes such as path-tracing and path verification information (node-ids, ingress/egress interfaces), timestamps, transit-delay, transit jitter, sequence numbers, application-defined metadata. In-situ OAM data-records are defined using an in-situ OAM namespace. It should be possible to control the information that gets recorded in data-records.
* Procedures to add, update, remove, retrieve and export data-records for in-situ OAM to live user traffic, including a classifier to select a subset of live user traffic for addition, update, removal and retrieval of in-situ OAM data-records.
* Scope of in-situ OAM operation. In-Situ OAM operations are defined for a specific operational domain. In-situ OAM data-records are added and removed at domain boundaries and updated by nodes within the in-situ OAM domain.
* Procedure to deal with various challenges and constraints in packet forwarding and error handling such as ECMP processing, path MTU and ICMP message handling when in-situ OAM is enabled in an in-situ OAM domain.
* Security aspects of in-situ OAM, including the potential vulnerabilities of integrating hop-by- hop information to live user traffic, and measures that should be taken to mitigate them.
* Data-records for in-situ OAM are to be defined in a way that makes them independent from the underlying encapsulation protocol. Data-records for in-situ OAM will need to be embedded into encapsulation protocols such as NSH, SRv6, IPv6, IPv4, etc. While considering all those encapsulation protocols, the WG is expected to initially focus on NSH, SRv6 and IPv6.
* Procedures and data-records optimized for software dataplane and hardware dataplane implementations of in-situ OAM.
* In-situ OAM to support layering. If several encapsulation protocols (e.g. in case of tunneling) are stacked on top of each other, in-situ OAM data-records could be present at every layer.
* Management and control of role of nodes for in-situ OAM operation, dynamic control of in-situ OAM data collected in the data records, data export optimization.

The IOAM working group intends to work on and publish:
* Definition of the data-type formats used in in-situ OAM and namespaces for in-situ OAM.
* Definition of procedures that in-situ OAM enabled nodes will perform on data traffic that carries in-situ OAM information (e.g., introducing, removing, processing, modifying, and exporting the telemetry information from the associated data packets).
* Configuration and operational data models for controlling in-situ OAM data and operations.

In-situ OAM data records could be embedded into a variety of encapsulations. These encapsulations are expected to be defined in the respective working group(s) such as SFC, SPRING, and 6man, in consultation with the IOAM working group documents.

The IOAM WG exclusively focuses on mechanisms which piggyback OAM-related metadata onto live user traffic for OAM purposes. Other ongoing OAM-related efforts in working groups(s) such as MPLS and IPPM that do not piggyback OAM metadata onto live user traffic are out of scope of the IOAM WG. The IOAM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches, as well as definition and interpretation of in-situ OAM data.

Milestones

April 2018 - submit data format and associated procedures document to IESG.
March 2018 - WGLC for data format and associated procedures document.
April 2017 - working group adoption of data format and associated procedures document

Milestones

Date Milestone