idnits 2.17.1 draft-bormann-loops-geneve-binding-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.welzl-loops-gen-info], [I-D.ietf-nvo3-geneve]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (12 June 2020) is 1414 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) == Missing Reference: 'RFCthis' is mentioned on line 300, but not defined == Outdated reference: A later version (-04) exists of draft-welzl-loops-gen-info-03 == Outdated reference: A later version (-06) exists of draft-li-tsvwg-loops-problem-opportunities-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 loops C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track 12 June 2020 5 Expires: 14 December 2020 7 Embedding LOOPS in Geneve 8 draft-bormann-loops-geneve-binding-01 10 Abstract 12 LOOPS (Local Optimizations on Path Segments) aims to provide local 13 in-network loss recovery. It can be used with tunneling protocols to 14 efficiently recover lost packets on a single segment of an end-to-end 15 path instead of leaving recovery to the end-to-end protocol, 16 traversing the entire path. 18 [I-D.welzl-loops-gen-info] defines the information to be carried 19 between LOOPS ingress and egress nodes in a generic way, giving a 20 guideline on defining the common elements to embed LOOPS functions in 21 various tunnel protocols. The present document specifies how to 22 embed LOOPS in the overlay tunnel protocol chosen for the initial 23 LOOPS specification, Geneve [I-D.ietf-nvo3-geneve]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 14 December 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Geneve LOOPS Frame Format . . . . . . . . . . . . . . . . . . 3 61 3.1. Flags and Flag Based Data . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Geneve Option Class . . . . . . . . . . . . . . . . . . . 6 65 5.2. LOOPS Geneve Type Numbers . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 LOOPS (Local Optimizations on Path Segments) aims to provide local 75 in-network loss recovery. The LOOPS problems and opportunities draft 76 [I-D.li-tsvwg-loops-problem-opportunities] illustrates some typical 77 scenarios where LOOPS are applicable. One way to use LOOPS is to map 78 it onto a tunnel protocol. The path segment on which LOOPS is 79 applied then is a tunnel, which can be an existing one or created on 80 purpose. 82 LOOPS allows the packet loss recovery to be performed over specific 83 segments instead of end-to-end, enabling faster and more reliable 84 data delivery. [I-D.welzl-loops-gen-info] defines the information to 85 be carried between LOOPS ingress and egress nodes in a generic way, 86 giving a guideline on defining the common elements to embed LOOPS 87 functions in various tunnel protocols. 89 Geneve [I-D.ietf-nvo3-geneve] is an encapsulation protocol that can 90 be used to create overlay tunnels. It defines an extensible TLV 91 structure to carry so-called "tunnel options". The present document 92 employs this flexibility, specifying how to embed LOOPS in Geneve. 93 This specification covers the format and Geneve-specific procedures 94 only: the actual LOOPS function and procedures are defined in 95 [I-D.welzl-loops-gen-info]. 97 LOOPS has two modes of loss recovery, retransmission and forward 98 error correction (FEC). The current version of the present document 99 covers retransmission only. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This document makes use of the terminology defined in 110 [I-D.welzl-loops-gen-info]. 112 3. Geneve LOOPS Frame Format 114 Figure 1 shows the format of the Geneve Header and a single Geneve 115 Option, as defined in [I-D.ietf-nvo3-geneve]. Geneve LOOPS defines a 116 new Option class called LOOPS to carry LOOPS forward and backward 117 information. 119 Geneve Header and Option: 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |Ver| Opt Len |O|C| Rsvd. | Protocol Type | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Virtual Network Identifier (VNI) | Reserved | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Variable Length Options | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Option Class | Type |R|R|R| Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Variable Option Data | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: Geneve Header and Option Format 138 In the Geneve Option structure, a Geneve LOOPS option uses the 139 following values: 141 * Option Class: TBD1 for LOOPS (see Section 5). 143 * Type: Based on the substructure already defined in Geneve, which 144 uses bit 0 (the most significant bit) to indicate a critical 145 option (see see Figure 2), LOOPS defines two type numbers: 0 for 146 LOOPS retransmission mode, and 64 for FEC mode. The present 147 document only addresses messages with LType=0. 149 TBD: Additional type numbers could be defined, possibly obviating the 150 need for some of the flags in the current option structure. 152 0 1 2 3 4 5 6 7 153 +-+-+-+-+-+-+-+-+ 154 |C| LType | 155 +-+-+-+-+-+-+-+-+ 157 Figure 2: Type Field Format in Geneve LOOPS Option 159 * C: Critical bit as defined in [I-D.ietf-nvo3-geneve]. 161 * LType: LOOPS Mode. 163 - 0: Retransmission mode. In this mode, the LOOPS option format 164 and operations follow this document. 166 - 64: FEC mode 168 - Further mode values can be assigned in an IANA registry (see 169 Section 5.2). 171 * Length: Length of Variable Option Data field, expressed in four 172 byte multiples excluding the option header, ranging from 0 to 31. 173 As the option header is another four bytes, the total length of 174 the option in bytes is therefore 4 * (1 + Length), yielding a 175 maximum total length of 128 bytes. 177 * Variable option data: consists of two parts, Flags and Flag Based 178 Data, as shown in Figure 3. 180 - Flags: 16 bits, as described in next subsection. Some of the 181 flags indicate the presence of additional data in the field of 182 Flag Based Data. 184 - Flag Based Data: This field consists of one or multiple 185 optional data blocks whose presence is indicated by the 186 corresponding flag bits. Any remaining bytes needed to reach a 187 multiple of four bytes are filled with zeroes. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Flags | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 194 | | 195 ~ Flag Based Data ~ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 3: Variable Option Data Format in Geneve LOOPS Option 201 3.1. Flags and Flag Based Data 203 Flags for LOOPS Tunnel Options are defined in Figure 4. Some flags 204 cause additional data blocks to occur in the Flags Based Data field. 205 Those additional data blocks are placed in the order of the flags 206 causing them. 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |I|R|D|S|T|E|A|R| |B| 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 4: Flags in Variable Option Data in Geneve LOOPS Option 214 A number of the flag bits are used on their own and do not cause 215 carrying additional data: 217 * I: Initial Packet Sequence Number (PSN) flag; may be set by the 218 LOOPS ingress to notify the egress about using a new initial PSN. 220 * R: Initial PSN Received flag; echo of I flag provided by the LOOPS 221 egress. 223 * D: ACK Desired flag; set by the LOOPS ingress if it wants the 224 egress to generate an acknowledgement immediately upon receiving a 225 particular packet. 227 These flag bits cause the addition of a single 32-bit number each: 229 * S: PSN flag; indicates a PSN data block is carried in the Flag 230 Based Data field. It must be set when a packet payload is 231 present. It must not be set if the packet is a pure LOOPS ACK 232 packet, i.e. when no payload is included in the packet. 234 * T: Timestamp flag. When set, it indicates a Timestamp data block 235 is carried in the Flag Based Data field. 236 // TBD: Might want to have "timestamp" and "echo" fields of less 237 or 238 // more than 4 bytes. 240 * E: Echoed Timestamp flag. When set, it indicates an Echoed 241 Timestamp data block is carried in the Flag Based Data field. 243 * A: ACK number flag. When set, it indicates the presence of a 244 Block 1 ACK information block. 246 * R: Reception time flag: May only be set if A is set. Indicates 247 that an absolute reception time is given (Format TBD). 249 Finally, a single flag bit is defined that causes the addition of a 250 variable-length block (therefore this flag is put as the least 251 significant bit of Flags): 253 * B: Block 2 flag. When set, it indicates the presence a Block 2 254 ACK information block, with the following format: TBD 255 // copy over the structure we have in gen-info. 257 Acknowledgement information can be sent as a pure ACK packet without 258 payload or piggybacked in a data packet. 260 4. Security Considerations 262 The security considerations of [I-D.welzl-loops-gen-info] and 263 [I-D.ietf-nvo3-geneve] apply. 265 5. IANA Considerations 267 5.1. Geneve Option Class 269 IANA is requested to assign a new option class for LOOPS from the 270 "Geneve Option Class" registry. 272 +--------------+-----------------------------+ 273 | Option Class | Description | 274 +==============+=============================+ 275 | TBD1 | LOOPS (Local Optimizations | 276 | | on Path Segments) [RFCthis] | 277 +--------------+-----------------------------+ 279 Table 1 281 5.2. LOOPS Geneve Type Numbers 283 IANA is requested to create a registry for type numbers ("LType") as 284 used in the TBD1 option class for LOOPS from the "Geneve Option 285 Class" registry, with the following three columns: 287 Type Number: Integer between 0 and 127 289 Description: Short Description 291 Reference: Reference to Specification 293 The initial contents of the registry is: 295 +-------------+---------------------+-----------+ 296 | Type Number | Description | Reference | 297 +=============+=====================+===========+ 298 | 0 | Retransmission mode | [RFCthis] | 299 +-------------+---------------------+-----------+ 300 | 64 | FEC mode | [RFCthis] | 301 +-------------+---------------------+-----------+ 303 Table 2 305 (Registry policy TBD, probably Specification Required.) 307 6. References 309 6.1. Normative References 311 [I-D.welzl-loops-gen-info] 312 Welzl, M. and C. Bormann, "LOOPS Generic Information Set", 313 Work in Progress, Internet-Draft, draft-welzl-loops-gen- 314 info-03, 9 March 2020, . 317 [I-D.ietf-nvo3-geneve] 318 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 319 Network Virtualization Encapsulation", Work in Progress, 320 Internet-Draft, draft-ietf-nvo3-geneve-16, 7 March 2020, 321 . 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 330 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 331 May 2017, . 333 6.2. Informative References 335 [I-D.li-tsvwg-loops-problem-opportunities] 336 Yizhou, L., Zhou, X., Boucadair, M., and J. Wang, "LOOPS 337 (Localized Optimizations on Path Segments) Problem 338 Statement and Opportunities for Network-Assisted 339 Performance Enhancement", Work in Progress, Internet- 340 Draft, draft-li-tsvwg-loops-problem-opportunities-04, 6 341 January 2020, . 344 Acknowledgements 346 Sami Boutros provided some advice on the use of Geneve in this 347 protocol binding. 349 Author's Address 351 Carsten Bormann 352 Universitaet Bremen TZI 353 Postfach 330440 354 Bremen D-28359 355 Germany 357 Phone: +49-421-218-63921 358 Email: cabo@tzi.org