IPPM Working Group L. Zhang
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: 23 August 2025 J. Ma
CAICT
19 February 2025
In Situ Operations, Administration, and Maintenance (IOAM) Active
Measurement for Multi-path
draft-zhang-ippm-ioam-active-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 promotes the
information collection and topology restoration of a multi-path
topology. It can help the operators to know the performance of
network comprehensively and efficiently.
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 23 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 23 August 2025 [Page 1]
Internet-Draft In Situ Operations, Administration, and February 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. IOAM extension . . . . . . . . . . . . . . . . . . . . . . . 4
3. Multi-path Measurement Procedures . . . . . . . . . . . . . . 4
3.1. Encapsulating Node Procedures . . . . . . . . . . . . . . 5
3.2. Transit Node Procedures . . . . . . . . . . . . . . . . . 5
3.2.1. Packet Operation . . . . . . . . . . . . . . . . . . 5
3.2.2. Packet Forwarding . . . . . . . . . . . . . . . . . . 5
3.3. Decapsulating Node Procedures . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
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] defines the Active flag to indicate that a packet is used
for active measurement and should be terminated by the decapsulating
node. It also provides two active measurement use cases where the
Active flag could be used.
Zhang, et al. Expires 23 August 2025 [Page 2]
Internet-Draft In Situ Operations, Administration, and February 2025
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 from
the source node to the destination node and ECMP, UCMP or other
multi-path routing strategy is used.), the default forwarding
behavior is to go through one path. So, it can’t collect all the
path’s information from 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 |
+------+ +------+\ /+------+ +------+
Encapsulating \ +------+ +------+ / Decapsulating
Node \| N4 |-------> | N6 |/ Node
+------+ +------+
<----------------------------IOAM-Domain------------------------------->
Figure 1: A multi-path topology
In Figure 1, node N1 is Encapsulating node, node N8 is the
Decapsulating node, N2-N7 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 IOAM probe packets or replicated data packets to measure
the paths performance, the packets are forwarded along one of the
paths (for example N1-N2-N4-N6-N7-N8), then the analyzer just can get
one of the paths information, however the traffic packets are
forwarded in all paths.
Although the IPv6 flow label and MPLS entropy label can be
constructed variously according to the paths information to make
packets go through all paths, but in some scenarios, it is hard to
get all the available paths in advance.
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 without knowing all the available paths in advance.
Zhang, et al. Expires 23 August 2025 [Page 3]
Internet-Draft In Situ Operations, Administration, and February 2025
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:
ECMP: Equal-Cost Multiple Path
UCMP: Unequal-Cost Multiple Path
IOAM: In situ Operations, Administration, and Maintenance
2. IOAM extension
The format of IOAM Pre-allocated and Incremental Trace-Option header
defined in [RFC9197] is shown as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID |NodeLen | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IOAM Pre-allocated and Incremental Trace-Option Header
This document defines a new flag X in the Flags field:
Bit X “Multipath” (M-bit): When set, the Multi-path flag indicates
that when an active measurement packet arrives at a node which has
multiple paths to the destination, the packet will be duplicated to
every interface which can reach the destination.
3. Multi-path Measurement Procedures
This section describes the procedures of Encapsulating node, transit
node, and Decapsulating node.
Zhang, et al. Expires 23 August 2025 [Page 4]
Internet-Draft In Situ Operations, Administration, and February 2025
3.1. Encapsulating Node Procedures
The Encapsulating node should generates probe packets with a Trace
Option that has its Active flag and Multipath flag set. The probe
packets could be generated independently or replicated from some of
the en-route data packets and should be terminated by the
Decapsulating node.
3.2. Transit Node Procedures
3.2.1. Packet Operation
When the transit node receives a probe packet with the IOAM trace
option, it should add its node ID, ingress interface ID, and egress
interface ID to the IOAM trace option of the probe packet. For
details about the content format, see section 4.4.2 of [RFC9197].
3.2.2. Packet Forwarding
When a transit node with multiple paths to the Destination node
receives a packet with a Trace Option that has its Active flag and
Multipath flag set, it SHOULD duplicate the packet to each egress
interface that can reach the Destination node.
When the transit node has only one path to the destination node, it
just needs to forward the packet it received to the egress interface.
If the Active flag is reset or the Multipath flag is reset, then the
transit node MUST not duplicate the packet.
3.3. Decapsulating Node Procedures
When a Decapsulating node receives a probe packet with the IOAM tarce
option, it needs to add its node ID, ingress interface ID to the IOAM
trace option of the probe packet. Then the Decapsulating node need
to export the IOAM data to the analyzer.
4. IANA Considerations
This document requests IANA to allocate a bit from the "IOAM Trace-
Flags" registry:
Zhang, et al. Expires 23 August 2025 [Page 5]
Internet-Draft In Situ Operations, Administration, and February 2025
+=======+================+===============+
| Value | Description | Reference |
+=======+================+===============+
| Bit X | Multi-path Bit | This document |
+-------+----------------+---------------+
Table 1
5. Security Considerations
The security considerations of IOAM Active flag are discussed in
[RFC9322], the solutions mitigating the attacks mentioned in
[RFC9322] are also applicable in this document.
In addition, the duplication of probe packets may lead to other
risks. When there is a loop in the topology, the probe packets may
be replicated repeatedly. Even there is no loop in the topology, an
attacker can replicate a lot of packets by setting the Multi-path
flag in en-route packets, causing bandwidth degradation.
In order to mitigate the possible attacks, the IOAM enabled nodes
should be able to:
* Limit the generation rate of IOAM probe packets with the Multi-
path flag.
* Limit the maximum number of packet replication times, this could
be realized by defining an Opaque State Snapshot filed in the
Trace Option. The value of this field should decrease by one when
a node duplicates the probe packet. The initial value of this
field is set by the Encapsulating node, when its value decreases
to zero, then the packet MUST not be duplicated anymore.
6. References
6.1. Normative 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>.
[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>.
Zhang, et al. Expires 23 August 2025 [Page 6]
Internet-Draft In Situ Operations, Administration, and February 2025
[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>.
6.2. Informative References
[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>.
Acknowledgements
The authors would like to thank Ernesto Ruffini, Thomas Graf, Greg
Mirsky for the valuable comments to this work.
Authors' Addresses
Li Zhang
Huawei
China
Email: zhangli344@huawei.com
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Junfeng Ma
CAICT
China
Email: majunfeng@caict.ac.cn
Zhang, et al. Expires 23 August 2025 [Page 7]