idnits 2.17.1 draft-li-ippm-stamp-on-lag-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 date (February 19, 2021) is 1161 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft China Mobile 4 Intended status: Standards Track M. Chen 5 Expires: August 23, 2021 Huawei 6 G. Mirsky 7 ZTE Corp. 8 February 19, 2021 10 Simple Two-Way Active Measurement Protocol Extensions for Performance 11 Measurement on LAG 12 draft-li-ippm-stamp-on-lag-00 14 Abstract 16 This document defines extensions to Simple Two-Way Active Measurement 17 Protocol (STAMP) to implement performance measurement on every member 18 link of a Link Aggregation Group (LAG). Knowing the measured metrics 19 of each member link of a LAG enables operators to enforce a 20 performance metric-based traffic steering policy across the member 21 links. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in 28 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 29 as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 23, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Micro-Session on LAG . . . . . . . . . . . . . . . . . . . . 3 67 3. Micro-STAMP Session . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Micro-STAMP-Test . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. LAG Member Link ID TLV . . . . . . . . . . . . . . . 4 70 3.1.2. Micro-STAMP-Test Procedures . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 Link Aggregation Group (LAG), as defined in [IEEE802.1AX], provides 82 mechanisms to combine multiple physical links into a single logical 83 link. This logical link offers higher bandwidth and better 84 resiliency, because if one of the physical member links fails, the 85 aggregate logical link can continue to forward traffic over the 86 remaining operational physical member links. 88 Usually, when forwarding traffic over a LAG, a hash-based or similar 89 mechanism is used to load-balance the traffic across the LAG member 90 links. In some cases, the link delays of the member links are 91 different because they are over different transport paths. To 92 provide low delay service to time-sensitive traffic, we have to know 93 the link delay of each member link of a LAG and then steer traffic 94 accordingly. That requires a solution that could measure the 95 performance metrics of each member link of a LAG. 97 However, when using Simple Two-Way Active Measurement Protocol 98 (STAMP) [RFC8762] to measure a LAG's performance, the LAG is treated 99 as a single logical link/path. The measured metrics reflect the 100 performance of one member link or an average of some/all member links 101 of the LAG. 103 In addition, for LAG, using passive or hybrid methods (like 104 alternative marking[RFC8321] or iOAM [I-D.ietf-ippm-ioam-data]) can 105 only monitor the link crossed by traffic. It means that the measured 106 metrics reflect the performance of some member links or an average of 107 some/all member links of the LAG. Therefore, in order to measure 108 every link of a LAG, using active methods would be more appropriate. 110 This document defines extensions to STAMP [RFC8762] to implement 111 performance measurement on every member link of a LAG. 113 2. Micro-Session on LAG 115 This document intends to address the scenario (e.g., Figure 1) where 116 a LAG (e.g., the LAG includes three member links) directly connects 117 two nodes (A and B) . The goal is to measure the performance of each 118 link of the LAG. 120 +---+ +---+ 121 | |-----------------------| | 122 | A |-----------------------| B | 123 | |-----------------------| | 124 +---+ +---+ 126 Figure 1: PM for LAG 128 To measure performance metrics of every member link of a LAG, 129 multiple sessions (one session for each member link) need to be 130 established between the two hosts that are connected by the LAG. 131 These sessions are called micro-sessions for the remainder of this 132 document. 134 All micro-sessions of a LAG share the same Sender Address, Receiver 135 Address. As for the Sender Port and Receiver Port, the micro- 136 sessions may share the same Sender Port and Receiver Port pair, or 137 each micro session is configured with a different Sender Port and 138 Receiver Port pair. But from simplifying operation point of view, 139 the former is recommended. 141 In addition, with micro-sessions, there needs a way to correlate a 142 session with a member link. For example, when the Reflector receives 143 a Test packet, it needs to know from which member link the packet is 144 received, and correlate it with a micro-session. That is a new 145 functionality for STAMP as defined in [RFC8762] and [RFC8972]. 147 Upon receiving a Test packet for a micro-session, the receiver uses 148 the receiving link's identifier to correlate the packet to a 149 particular session. In addition, Test packets may need to carry the 150 member link information for validation checking. For example, when a 151 Session-Sender/Session-Reflector receives a Test packet, it may need 152 to check whether the Test packet is from the expected member link. 154 3. Micro-STAMP Session 156 3.1. Micro-STAMP-Test 158 The micro-STAMP-Test protocol is based on the STAMP-Test protocol 159 [RFC8762] and [RFC8972] with the following extensions. 161 3.1.1. LAG Member Link ID TLV 163 The LAG Member Link ID TLV is defined to carry the LAG member link 164 identifiers associated with a micro-STAMP session. The member link 165 identifiers are used for the Session-Sender and Session-Reflector to 166 check whether a Test packet is received from the expected member 167 link. The detailed procedures are defined in Section 3.1.2. 169 The format is as below: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |STAMP TLV Flags| Type | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Sender Member Link ID | Reflector Member Link ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 2: LAG Member Link ID TLV 181 Sender Member Link ID (2-octets in length): it is defined to carry 182 the LAG member link identifier of the Sender side. The value of the 183 Sender Member Link ID MUST be unique at the Session-Sender. 185 Reflector Member Link ID (2-octets in length): it is defined to carry 186 the LAG member link identifier of the Reflector side. The value of 187 the Reflector Member ID MUST be unique at the Session-Reflector. 189 3.1.2. Micro-STAMP-Test Procedures 191 The micro-STAMP-Test reuses the procedures as defined in Section 4 of 192 STAMP [RFC8762] with the following additions: 194 The micro-STAMP Session-Sender MUST send the micro-STAMP-Test packets 195 over the member link associated with the session. The micro STAMP 196 Session-Reflector MUST send the reflected Test packets over the 197 receiving member link. 199 The configuration and management of the association between a micro- 200 STAMP session and the Sender/Reflector member link identifiers are 201 outside the scope of this document. 203 When the Session-Sender sends a Test packet, the LAG Member Link ID 204 TLV MUST be carried, and the Sender member link identifier associated 205 with the micro-STAMP session MUST be put in the Sender Member Link ID 206 field. If the Session-Sender knows the Reflector member link 207 identifier, it MUST set it as the Reflector Member Link ID field's 208 value. Otherwise, the Reflector Member Link ID field MUST be set to 209 zero. 211 The Session-Sender uses the Sender Member Link ID field's value to 212 check whether the reflected Test packet is received from the member 213 link associated with the correct micro-STAMP session. Therefore, the 214 Session-Reflector MUST copy the Sender Member Link ID value to the 215 reflected Test packet. 217 The Session-Reflector uses the Reflector Member Link ID value to 218 check whether a Test packet is received from the member link 219 associated with the correct micro-STAMP session. 221 The Reflector member link identifier can be obtained from pre- 222 configuration or learned through the data plane (e.g., learned from a 223 reflected Test packet). How to obtain/learn the Reflector member 224 link identifier is outside of this document's scope. 226 When the micro-STAMP Session-Reflector receives a Test packet, it 227 MUST use the receiving member link to correlate the Test packet to a 228 micro-STAMP session. If there is no such a micro-STAMP session, the 229 Test packet MUST be discarded. Suppose the Reflector Member Link ID 230 is not zero. In that case, the micro-STAMP Session-Reflector MUST 231 use the Reflector member link identifier to check whether it is 232 associated with the micro-STAMP session. If it is not, the Test 233 packet MUST be discarded and no reflected Test packet will be sent 234 back to the Session-Sender. If all validation passed, the Session- 235 Reflector sends a reflected Test packet to the Session-Sender over 236 the receiving member link. The micro-STAMP Session-Reflector MUST 237 put the Sender and Reflector member link identifiers associated with 238 the micro-STAMP session in the Sender Member Link ID and Reflector 239 Member Link ID fields, respectively. The Sender member link 240 identifier is copied from the received Test packet. 242 When the micro-STAMP Session-Sender receives a reflected Test packet, 243 it MUST use the receiving member link to correlate the reflected Test 244 packet to a micro-STAMP session. If there is no such a session, the 245 reflected Test packet MUST be discarded. If a matched micro-STAMP 246 session exists, the Session-Sender MUST use the identifier carried in 247 the Sender Member Link ID field to check whether it associates with 248 the session. If the checking failed, the Test packet MUST be 249 discarded. 251 4. IANA Considerations 253 This document requires the IANA to allocate the following the TLV 254 type from the "STAMP TLV Types" sub-registry. 256 Value |Description | Reference 257 ---------+----------------------+---------------------- 258 TBD1 |LAG Member Link ID | This document 260 5. Security Considerations 262 This document does not introduce additional security requirements and 263 mechanisms other than the ones described in [RFC8762] apply to this 264 document. 266 6. Acknowledgements 268 The authors would like to thank Min Xiao, Fang Xin for the valuable 269 comments to this work. 271 7. References 273 7.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 285 Two-Way Active Measurement Protocol", RFC 8762, 286 DOI 10.17487/RFC8762, March 2020, 287 . 289 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 290 and E. Ruffini, "Simple Two-Way Active Measurement 291 Protocol Optional Extensions", RFC 8972, 292 DOI 10.17487/RFC8972, January 2021, 293 . 295 7.2. Informative References 297 [I-D.ietf-ippm-ioam-data] 298 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 299 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 300 progress), November 2020. 302 [IEEE802.1AX] 303 IEEE Std. 802.1AX, "IEEE Standard for Local and 304 metropolitan area networks - Link Aggregation", November 305 2008. 307 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 308 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 309 "Alternate-Marking Method for Passive and Hybrid 310 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 311 January 2018, . 313 Authors' Addresses 315 Zhenqiang Li 316 China Mobile 318 Email: li_zhenqiang@hotmail.com 320 Mach(Guoyi) Chen 321 Huawei 323 Email: mach.chen@huawei.com 325 Greg Mirsky 326 ZTE Corp. 328 Email: gregimirsky@gmail.com