An In Situ Operations, Administration, and Maintenance (IOAM) Multi-path Flag
draft-zhang-ippm-ioam-mp-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Li Zhang , Tianran Zhou | ||
| Last updated | 2024-02-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-ippm-ioam-mp-00
IPPM Working Group L. Zhang
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: 31 August 2024 28 February 2024
An In Situ Operations, Administration, and Maintenance (IOAM) Multi-path
Flag
draft-zhang-ippm-ioam-mp-00
Abstract
Active measurements are typically used to collect the information of
a specific path. However, when using active measurement mechanisms
in a multi-path topology, the default forwarding behavior is to go
through one path. So, it cannot collect the information of all the
paths at one time.
This document extends IOAM Trace Option with a multi-path flag to
simplify multi-path IOAM active measurement, which can promote the
information collection and topology restoration of a multi-path
topology.
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 31 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Zhang & Zhou Expires 31 August 2024 [Page 1]
Internet-Draft An In Situ Operations, Administration, a February 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. IOAM extension . . . . . . . . . . . . . . . . . . . . . . . 4
3. Multi-path Active Measurement with IOAM . . . . . . . . . . . 4
3.1. Example of Multi-path Active Measurement with IOAM . . . 4
3.2. Example of Reflection Multi-path IOAM Data Fields with
STAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In situ Operations, Administration, and Maintenance (IOAM) collects
OAM information within the packet while the packet traverses a
particular network domain. IOAM is used to complement mechanisms,
such as Ping or Traceroute.
[RFC9322] provides three kinds of active measurements using IOAM, and
defines a Active flag to indicate that a packet is used for active
measurement.
[I-D.gandhi-ippm-stamp-ext-hdr] extends STAMP[RFC8762] to reflect any
IPv6 options and MPLS Network Action Sub-Stacks for hop-by-hop and
edge-to-edge active measurements. In section 4 of
[I-D.gandhi-ippm-stamp-ext-hdr], it provides an example of reflecting
IOAM data fields, in which the IPv6 options with IOAM option-types is
carried in the STAMP Session-Sender and Session-Reflector test
packets.
However, active measurements are typically used to collect the
information of a specific path, when using active measurement
mechanisms in a multi-path topology (there are multiple paths form
the source node to the destination node and ECMP, UCMP or other
multi-path routing strategy is used.), the default forwarding
Zhang & Zhou Expires 31 August 2024 [Page 2]
Internet-Draft An In Situ Operations, Administration, a February 2024
behavior is to go through one path. So, it can’t collect all the
path’s information form source node to destination node . An example
of active measurement in a multi-path topology is shown as follow:
+------+ +------+
/| N3 |---------| N5 |\
/ +------+ +------+ \
+------+ +------+/ \+------+ +------+
| N1 |--->| N2 | | N7 |---->| N8 |
+------+ +------+\ /+------+ +------+
SRC \ +------+ +------+ / DST
\| N4 |-------> | N6 |/
+------+ +------+
Figure 1: A multi-path topology
In Figure 1, node N1 is the source node, node N8 is the destination
node, N2-7 are transit node. Equal-Cost Multiple Path (ECMP) is
applied in this topology. So, there are two paths form N1 to N8, one
is N1-N2-N3-N5-N7-N8, and the other is N1-N2-N4-N6-N7-N8. When N1
use active measurement to measure the path performance, the probe
packet is forwarded along one of the paths (for example
N1-N2-N4-N6-N7-N8), then the source node or controller just can get
one path’s information, however the data packets are forwarded in all
paths.
This document extends IOAM Trace Option with a multi-path flag to
simplify multi-path IOAM active measurement, which can promote the
information collection and topology restoration of a multi-path
topology.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
The abbreviations used in this document are:
OAM: Operation, Administration, and Maintenance
ECMP: Equal-Cost Multiple Path
UCMP: Unequal-Cost Multiple Path
Zhang & Zhou Expires 31 August 2024 [Page 3]
Internet-Draft An In Situ Operations, Administration, a February 2024
STAMP: Simple Two-Way Active Measurement Protocol
2. IOAM extension
This document defines a new flag in the Pre-allocated and Incremental
Trace options:
Bit X “Multipath” (M-bit): When set, the Multi-path flag indicates
that when an active measurement packet arrives a node which has
multiple paths to the destination, the packet will be copied to every
path.
3. Multi-path Active Measurement with IOAM
Active measurement methods [RFC7799] make use of synthetically
generated packets to facilitate measurement. This section presents
use cases of multi-path active measurement using the IOAM Multi-path
flag.
The Multi-path flag indicates that an active measurement packet is
used for multi-path active measurement. An IOAM Transit node that
receives a packet with the Multi-path flag set in one of its Trace
options must copy the packet to every path that can reach the
destination node. The Multi-path flag is intended to record every
path’s information by one active measurement packet in multi-path
topology.
3.1. Example of Multi-path Active Measurement with IOAM
An example of an IOAM deployment scenario is illustrated in Figure 2.
The figure depicts two endpoints: An Encapsulating node and a
Decapsulating node. The data traffic from the Encapsulating node to
the Decapsulating node is forwarded through four transit nodes.
There are two routing paths from Encapsulating node to the
Decapsulating node.
+--------+
/| N3 |\
/ +--------+ \
+--------+ +--------+/ Transit \+--------+ +--------+
| N1 |-----| N2 | Node | N5 |-----| N6 |
+--------+ +--------+\ /+--------+ +--------+
Encapsulating Transit \ +--------+ / Transit Decapsulating
Node Node \| N4 |/ Node Node
+--------+
Transit
Node
<---------------------- IOAM-Domain ------------------------>
Zhang & Zhou Expires 31 August 2024 [Page 4]
Internet-Draft An In Situ Operations, Administration, a February 2024
Figure 2: IOAM in multi-path topology
In Figure 2, Probe packets are generated and transmitted by the IOAM
Encapsulating node and are expected to be terminated by the
Decapsulating node. The Encapsulating node generates Probe packets
include a Trace Option that has its Multi-path flag set, indicating
that these are multi-path probe packets.
When a multi-path probe packet arrives at N2, N2 find that there are
two paths to the Decapsulating node, then it will copy the packet to
each outgoing interface of the two paths and add its information to
the IOAM Trace Option. It should be noted that Node Identification
and outgoing interface Identification of N2 are mandatory for path
recovering, other node data defined in section 4.1.1 of [RFC9197] are
optional.
The following transit nodes just add its node data to the IOAM Trace
Option as described in section 4 of [RFC9197].
When a probe packet arrives at Decapsulating node, the Decapsulating
node will extract the encapsulated node data along the path from the
probe packet and exports the associated data to the controller.
The controller will restore all path information based on the
exported data form Decapsulating node.
3.2. Example of Reflection Multi-path IOAM Data Fields with STAMP
A “STAMP Topology” is shown in Figure 3. Node S1 is a session
sender, node R1 is a session reflector, node M1, M2, M3 and M4 are
midpoint node.
+----+
// | M2 | \\
// +----+ \\
+----+Test Packet+----+ +----+ +----+
| | - - - - ->| | | |- - - - - >| |
| S1 |===========| M1 | | M4 |===========| R1 |
| |<- - - - - | | | |<- - - - - | |
+----+ +----+ +----+ Reply Test+----+
\\ +----+ // Packet
\\ | M3 | //
+----+
STAMP Session-Sender STAMP Session-Reflector
Figure 3: Stamp Topology
Zhang & Zhou Expires 31 August 2024 [Page 5]
Internet-Draft An In Situ Operations, Administration, a February 2024
The STAMP Session Sender S1 initiates a Session-Sender test packet
with an IPv6 IOAM option and has its Multi-path flag set.
When the Session-Sender test packet arrives at M1, M1 find that there
are two paths to R1, then it will copy the packet to each outgoing
interface of the two paths and add its information to the IOAM Trace
Option.
The following transit nodes just add its node data to the IOAM Trace
Option as described in the section 4 of [RFC9197].
When the probe packet arrives at R1, it MUST copy the entire IPv6
option including the header into the STAMP "Reflected IPv6 Option
Data" TLV in Session-Reflector payload. The Session-Reflector also
MUST add the matching IPv6 option in the IPv6 header of the Session-
Reflector test packet and reset the Multi-path flag of IOAM option.
Based on the above procedures, the multi-path information collected
by IOAM data fields is reflected to the Sender where the Sender can
use that information to support the hop-by-hop and edge-to-edge
measurement use-cases.
4. IANA Considerations
This document defines a new bit in the registry "IOAM Trace-Flags"
registry as follows:
+=======+================+===========+
| Value | Description | Reference |
+=======+================+===========+
| Bit X | Multipath Flag | This |
+-------+----------------+-----------+
Table 1
5. Security Considerations
The security considerations described in [RFC9197] apply to the
extensions defined in this document as well. This document does not
raise new security issues.
6. References
6.1. Normative References
Zhang & Zhou Expires 31 August 2024 [Page 6]
Internet-Draft An In Situ Operations, Administration, a February 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.
6.2. Informative References
[RFC9322] Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and
M. Spiegel, "In Situ Operations, Administration, and
Maintenance (IOAM) Loopback and Active Flags", RFC 9322,
DOI 10.17487/RFC9322, November 2022,
<https://www.rfc-editor.org/rfc/rfc9322>.
[I-D.gandhi-ippm-stamp-ext-hdr]
Gandhi, R. and T. Zhou, "Simple Two-Way Active Measurement
Protocol (STAMP) Extensions for Reflecting STAMP Packet
Headers", Work in Progress, Internet-Draft, draft-gandhi-
ippm-stamp-ext-hdr-00, 6 February 2024,
<https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-
stamp-ext-hdr-00>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/rfc/rfc8762>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.
Acknowledgements
Authors' Addresses
Li Zhang
Huawei
China
Email: zhangli344@huawei.com
Zhang & Zhou Expires 31 August 2024 [Page 7]
Internet-Draft An In Situ Operations, Administration, a February 2024
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Zhang & Zhou Expires 31 August 2024 [Page 8]