idnits 2.17.1 draft-song-ippm-inband-e2e-rtt-measurement-00.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 (November 30, 2020) is 1243 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 3 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: June 3, 2021 November 30, 2020 7 In-band Edge-to-Edge Round Trip Time Measurement 8 draft-song-ippm-inband-e2e-rtt-measurement-00 10 Abstract 12 This draft describes a lightweight in-band edge-to-edge network round 13 trip time measurement architecture and suggests implementations. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 19 "OPTIONAL" in this document are to be interpreted as described in BCP 20 14 [RFC2119][RFC8174] when, and only when, they appear in all 21 capitals, as shown here. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 3, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. In-band E2E RTT Measurement Architecture . . . . . . . . . . 3 59 3. Implementation Considerations . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 In-network service-based traffic engineering or load balancing needs 72 to monitor particular flows' edge-to-edge performance, such as round 73 trip time (RTT), in the operator's network domain. The host-based 74 ping using ICMPv6 [RFC4443] is of no use because it is usually beyond 75 the access of network operators. The router-based ping, as an active 76 measurement approach, cannot reflect the real performance of the 77 specific flows under scrutiny. This is also true for the other 78 active measurement approaches such as TWAMP [RFC5357]. 80 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] supports in-band flow- 81 based performance measurement. However, on the one hand, the IOAM 82 trace option is too heavy for the applications which do not care 83 about the per-hop performance; on the other hand, the IOAM E2E option 84 only supports the one-way measurement. 86 Alternate Marking(AM) [RFC8321], mainly designed for one-way 87 measurement, can be used to measure the two-way edge-to-edge delay if 88 both edges initiate a one-way measurement session. However, AM's 89 measurement interval needs to be large enough to avoid the 90 measurement ambiguity, and it requires both edges to conduct the 91 measurements and export results to a controller. 93 We need a lightweight in-band flow RTT measurement method. 94 "Lightweight" means the extra header overhead is low, and the extra 95 network processing overhead is also low. A network operator should 96 be able to pick a flow to monitor and get find-grained per-packet RTT 97 measurement for edge to edge. Depending on the application scenario 98 and the network domain scope, the edge can extend to the host, the 99 network interface card (NIC), or the network switch or router. To 100 this end, we propose an in-band edge-to-edge RTT measurement method 101 and suggest the implementation approaches. 103 Such measurement only reflects the network delay for a flow but 104 excludes the application layer delay incurred by server or client. 106 2. In-band E2E RTT Measurement Architecture 108 The measurement architecture is shown in Figure 1. The controller, 109 either on a remote machine or on the edge node's control plane, 110 configures the ingress edge node to measure some flow's RTT between 111 the ingress edge and the egress edge. The ingress edge node uses ACL 112 to filter the flow packets and, at given interval or probability, add 113 the timestamp and the other metadata to the selected packets. The 114 egress edge, after capturing the data, either piggyback the data on a 115 reverse flow packet, or generate a feedback packet carrying the data 116 back to the ingress edge node. Once the ingress edge node receives 117 the feedback data, it sends the data along with the current timestamp 118 to the controller. The controller can then calculate the flow RTT 119 and react with followup actions. 121 The RTT calculation is done in the slow path, the metadata incurs 122 only small and fix header overhead, and the nodes in the domain does 123 not do any processing. All these make the measurement lightweight, 124 accurate, and have little impact to the network forwarding 125 performance. 127 +------+ 128 | | 129 |Ctrl. | 130 | | 131 +-+----+ 132 | ^ 133 Config. | | Export 134 V | 135 +------+ +----+-+ Forwarding +------+ +------+ 136 | | pkt. | +-----......------>| | pkt. | | 137 |Client+----->| Edge | | Edge +----->|Server| 138 | | | |<----......-------+ | | | 139 +------+ +------+ Feedback +------+ +------+ 141 |<-- Operator Network Domain -->| 143 Figure 1: In-band E2E RTT Measurement 145 To differentiate a feedback packet from an original packet, a flag 146 needs to be raised in the feedback. Optionally, to correlate a 147 feedback with its original packet, the original packet can also 148 include an identifier (e.g., a sequence number) which the feedback 149 packet will carry back as well. The ingress edge node can use the 150 reverse flow ID plus the identifier to pair an original packet with 151 its feedback. 153 The feedback can also include some other local data at the egress 154 edge (e.g., the egress edge node ID or the egress flow statistics) 155 other than simply reflecting the original data back. 157 3. Implementation Considerations 159 One approach to implement the in-band E2E RTT measurement is to use 160 the IOAM E2E option augmented with the feedback mechanism. Current 161 IOAM E2E option only sends one-way data from one edge to the other 162 edge. The data fields can include the ingress edge timestamp which 163 is exactly what is needed. Moreover, the data fields can also 164 include a packet sequence number used for correlating the feedback 165 packet with the original packet. However, current IOAM E2E option 166 lacks a feedback mechanism. It has no flag field reserved in its 167 current option header specification, so it is not easy to indicate 168 the feedback packets. 170 To enable the two-way measurement behavior, we need to add some 171 indicator to the IOAM E2E option header to indicate the request for a 172 feedback. We also need another indicator to tell if the current 173 packet is a feedback. 175 To support this, we can either introduce another IOAM two-way E2E 176 option while keeping the current IOAM E2E option unchanged, or simply 177 modify the current IOAM E2E option header specification to extend its 178 usage. The simplest modification is to reserve a few flag bits and 179 among them, two bits are used for the two-way measurement. One 180 possible layout is shown in Figure 2. Alternatively, the flags can 181 take several bits from the Namespace-ID field. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Namespace-ID | Flags | IOAM-E2E-Type | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 | E2E Option data field determined by IOAM-E2E-Type | 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 2: Modified IOAM E2E Option Header 195 The data field can carry the timestamp, the sequence number, of a 196 unique packet identifier number. Other data types can also be 197 carried to enrich the feedback information. 199 A packet can serve as both a forward packet and a feedback packet 200 when both flags are set. In this case, there are two records for 201 each data type in the data field. The forward packet's data are 202 located in front of the feedback packet's data. 204 4. Security Considerations 206 To prevent the timestamp to be maliciously altered during the packet 207 forwarding, the ingress edge can instead keep the timestamp locally 208 and only send a packet identifier (e.g., a random data). When a 209 reverse flow packet carrying the same identifier is received, the 210 current timestamp along with the saved timestamp are forwarded to the 211 controller. 213 The ingress edge node can limit the frequency of measurement to the 214 flow packets. The egress edge node can also rate limit the feedback. 215 So the potential DoS attack can be mitigated. 217 5. IANA Considerations 219 Depending on the discussion output, either a registry for a new IOAM 220 option is required or a modification to the current IOAM E2E option 221 specification is needed. 223 6. Contributors 225 TBD. 227 7. Acknowledgments 229 TBD. 231 8. References 233 8.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 . 240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 242 May 2017, . 244 8.2. Informative References 246 [I-D.ietf-ippm-ioam-data] 247 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 248 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 249 progress), November 2020. 251 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 252 Control Message Protocol (ICMPv6) for the Internet 253 Protocol Version 6 (IPv6) Specification", STD 89, 254 RFC 4443, DOI 10.17487/RFC4443, March 2006, 255 . 257 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 258 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 259 RFC 5357, DOI 10.17487/RFC5357, October 2008, 260 . 262 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 263 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 264 "Alternate-Marking Method for Passive and Hybrid 265 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 266 January 2018, . 268 Authors' Addresses 270 Haoyu Song 271 Futurewei Technologies 272 Santa Clara 273 USA 275 Email: haoyu.song@futurewei.com 277 Linda Dunbar 278 Futurewei Technologies 279 Plano 280 USA 282 Email: linda.dunbar@futurewei.com