idnits 2.17.1 draft-song-ippm-inband-e2e-rtt-measurement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (31 May 2022) is 697 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song 3 Internet-Draft D. Linda 4 Intended status: Standards Track Futurewei Technologies 5 Expires: 2 December 2022 31 May 2022 7 In-band Edge-to-Edge Round Trip Time Measurement 8 draft-song-ippm-inband-e2e-rtt-measurement-03 10 Abstract 12 This draft describes a lightweight in-band edge-to-edge flow-based 13 network round trip time measurement architecture and proposes the 14 implementation over IOAM E2E option. By augmenting the IOAM E2E 15 option header, the process can be fully done in data plane without 16 needing to involve the control plane to maintain any states. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119][RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 2 December 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. In-band E2E RTT Measurement Architecture . . . . . . . . . . 3 61 3. Implementation over IOAM E2E Option . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 In-network service-based traffic engineering or load balancing needs 74 to monitor a particular flow's edge-to-edge performance (i.e., from 75 some ingress node of the flow forwarding path to some egress node), 76 such as round trip time (RTT), in the operator's network domain. The 77 host-based ping using ICMPv6 [RFC4443] is usually beyond the access 78 of network operators. The router-based ping, as an active 79 measurement approach, cannot reflect the real performance of the 80 specific flows under scrutiny. This is also true for the other 81 active measurement approaches such as TWAMP [RFC5357]. 83 In-situ OAM (IOAM) [RFC9197] supports in-band flow-based performance 84 measurement. However, on the one hand, the IOAM trace option can be 85 too heavy for applications which do not care about the per-hop 86 performance; on the other hand, the IOAM E2E option only supports the 87 one-way measurement. 89 Alternate Marking(AM) [RFC8321], mainly designed for one-way 90 measurement, can be used to measure the two-way edge-to-edge delay if 91 both edges initiate a one-way measurement session. However, AM's 92 measurement interval needs to be large enough to avoid the 93 measurement ambiguity, and it requires both edges to conduct the 94 measurements and export results to a controller. 96 We need a lightweight in-band flow RTT measurement method. 97 "Lightweight" means the extra header overhead is low, and the extra 98 network processing overhead is also low. A network operator should 99 be able to pick a target flow to monitor and get find-grained per- 100 packet RTT measurement for edge to edge. Moreover, the method should 101 be stateless and does not need a control plane to maintain sessions. 102 Depending on the application scenario and the network domain scope, 103 the edge can extend to the host, the network interface card (NIC), or 104 the network switch or router. To this end, we propose an in-band 105 edge-to-edge flow RTT measurement method and the implementation 106 approaches. 108 Such measurement only reflects the network delay for a flow but 109 excludes the application layer delay incurred by server or client, 110 which is useful for isolating the network's contribution to the 111 performance. 113 2. In-band E2E RTT Measurement Architecture 115 The measurement architecture is shown in Figure 1. The controller, 116 either on a remote machine or on the edge node's control plane, 117 configures the ingress edge node to measure some flow's RTT between 118 the ingress edge and the egress edge. The ingress edge node uses ACL 119 to filter the flow packets and, at given interval or probability, add 120 the timestamp and the other metadata to the selected packets. The 121 egress edge, after capturing the data, either piggyback the data on a 122 reverse flow packet, or generate a feedback packet carrying the data 123 back to the ingress edge node. Once the ingress edge node receives 124 the feedback data, it sends the data along with the current timestamp 125 to the controller. The controller can then calculate the flow RTT 126 and react with followup actions. 128 The RTT calculation can be done in the slow path (e.g., in the 129 controller), the metadata incurs only small and fix header overhead, 130 and the nodes in the domain does not do any processing. All these 131 make the measurement lightweight, accurate, and have little impact to 132 the network forwarding performance. 134 +------+ 135 | | 136 |Ctrl. | 137 | | 138 +-+----+ 139 | ^ 140 Config. | | Export 141 V | 142 +------+ +----+-+ Forwarding +------+ +------+ 143 | | pkt. | +-----......------>| | pkt. | | 144 |Client+----->| Edge | | Edge +----->|Server| 145 | | | |<----......-------+ | | | 146 +------+ +------+ Feedback +------+ +------+ 148 |<-- Operator Network Domain -->| 150 Figure 1: In-band E2E RTT Measurement 152 To differentiate a feedback packet from an original packet, a flag 153 needs to be raised in the feedback. Optionally, to correlate a 154 feedback with its original packet, the original packet can also 155 include an identifier (e.g., a sequence number) which the feedback 156 packet will carry back as well. The ingress edge node can use the 157 reverse flow ID plus the identifier to pair an original packet with 158 its feedback. 160 The feedback can also include some other local data at the egress 161 edge (e.g., the egress edge node ID or the egress flow statistics) 162 other than simply reflecting the original data back. 164 3. Implementation over IOAM E2E Option 166 One approach to implement the in-band E2E RTT measurement is to use 167 the IOAM E2E option [RFC9197] augmented with the feedback mechanism. 168 Current IOAM E2E option only sends one-way data from one edge to the 169 other edge. The data fields can include the ingress edge timestamp 170 which is exactly what is needed. Moreover, the data fields can also 171 include a packet sequence number used for correlating the feedback 172 packet with the original packet. However, current IOAM E2E option 173 lacks a feedback mechanism. It has no flag field reserved in its 174 current option header specification, so it is not easy to indicate 175 the feedback packets. 177 To enable the two-way measurement behavior, we need to add some 178 indicator to the IOAM E2E option header to indicate the request for a 179 feedback. We also need another indicator to tell if the current 180 packet is a feedback. 182 To support this, we can either introduce another IOAM two-way E2E 183 option while keeping the current IOAM E2E option unchanged, or modify 184 the current IOAM E2E option header specification to extend its usage. 185 The simplest modification is to reserve a few (e.g., 4) flag bits and 186 among them, two bits are used for the two-way measurement. One 187 possible layout is shown in Figure 2. Alternatively, the flags can 188 take several bits from the Namespace-ID field. 190 The current specification uses 16 bits for IOAM E2E data types and 191 only the first 4 bits are specified. The remaining 12 bits are 192 undefined, so it is possible to redefine their usage as proposed 193 without violating the standard. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Namespace-ID | IOAM-E2E-Type | flags | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 | E2E Option data field determined by IOAM-E2E-Type | 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: Modified IOAM E2E Option Header 207 The data field can carry the timestamp, the sequence number, of a 208 unique packet identifier number. Other data types can also be 209 carried to enrich the feedback information. 211 A packet can serve as both a forward packet and a feedback packet 212 when both flags are set. In this case, there are two records for 213 each data type in the data field. The forward packet's data are 214 located in front of the feedback packet's data. 216 4. Security Considerations 218 To prevent the timestamp to be maliciously altered during the packet 219 forwarding, the ingress edge can instead keep the timestamp locally 220 and only send a packet identifier (e.g., a random data). When a 221 reverse flow packet carrying the same identifier is received, the 222 current timestamp along with the saved timestamp are forwarded to the 223 controller. 225 The ingress edge node can limit the frequency of measurement to the 226 flow packets. The egress edge node can also rate limit the feedback. 227 So the potential DoS attack can be mitigated. 229 5. IANA Considerations 231 Depending on the discussion output, either a registry for a new IOAM 232 option is required or a modification to the current IOAM E2E option 233 specification is needed. 235 6. Contributors 237 TBD. 239 7. Acknowledgments 241 TBD. 243 8. References 245 8.1. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, 249 DOI 10.17487/RFC2119, March 1997, 250 . 252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 254 May 2017, . 256 [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, 257 Ed., "Data Fields for In Situ Operations, Administration, 258 and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, 259 May 2022, . 261 8.2. Informative References 263 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 264 Control Message Protocol (ICMPv6) for the Internet 265 Protocol Version 6 (IPv6) Specification", STD 89, 266 RFC 4443, DOI 10.17487/RFC4443, March 2006, 267 . 269 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 270 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 271 RFC 5357, DOI 10.17487/RFC5357, October 2008, 272 . 274 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 275 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 276 "Alternate-Marking Method for Passive and Hybrid 277 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 278 January 2018, . 280 Authors' Addresses 282 Haoyu Song 283 Futurewei Technologies 284 Santa Clara, 285 United States of America 286 Email: haoyu.song@futurewei.com 288 Linda Dunbar 289 Futurewei Technologies 290 Plano, 291 United States of America 292 Email: linda.dunbar@futurewei.com