idnits 2.17.1 draft-qiang-tsvwg-udp-options-bounded-latency-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 (March 8, 2019) is 1876 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Qiang, Ed. 3 Internet-Draft T. Eckert 4 Intended status: Informational Huawei 5 Expires: September 9, 2019 March 8, 2019 7 UDP Options for Bounded Latency 8 draft-qiang-tsvwg-udp-options-bounded-latency-00 10 Abstract 12 This document explores the use of UDP options for packet forwarding 13 with bounded latency. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 9, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 52 2. Overview of Bounded Latency Forwarding Schemes . . . . . . . 3 53 2.1. Time Aware Shaping . . . . . . . . . . . . . . . . . . . 3 54 2.2. Cyclic Queuing and Forwarding . . . . . . . . . . . . . . 4 55 2.3. Scalable Deterministic Forwarding (SDF) . . . . . . . . . 5 56 2.4. SR based Bounded Latency . . . . . . . . . . . . . . . . 6 57 2.5. Other Bounded Latency Forwarding Schemes . . . . . . . . 6 58 3. UDP Option Extension for Bounded Latency Forwarding . . . . . 6 59 3.1. Sending Cycle Option . . . . . . . . . . . . . . . . . . 7 60 3.2. UDP Option for Other Purposes . . . . . . . . . . . . . . 7 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 More and more applications require for deterministic forwarding as 70 summarized in [draft-ietf-detnet-use-cases]. Deterministic 71 forwarding refers to the packet forwarding with bounded latency, as 72 well as low packet loss. In current DetNet's discussion, low packet 73 loss is mainly achieved through PREOF (Packet Replication, 74 Elimination, and Ordering Functions) 75 [draft-ietf-detnet-architecture]. Supporting PREOF through UDP 76 options is out of this document's scope. This document only explores 77 the use of UDP options for bounded latency forwarding purposes. 79 A lot of bounded latency forwarding schemes have been proposed such 80 as Time Aware Shaping [IEEE802.1Qbv], Cyclic Queuing and Forwarding 81 [IEEE802.1Qch], Scalable Deterministic Forwarding 82 [draft-qiang-detnet-large-scale-detnet], and SR based bounded latency 83 [draft-chen-detnet-sr-based-bounded-latency]. These schemes require 84 more or less specific information, whether configured through control 85 plane or carried in data plane. In MPLS data plane, there is enough 86 space in MPLS Label to carry information for bounded latency 87 forwarding. However in an IP data plane, there is no enough space in 88 the IP common header. To that aim, UDP options 89 [draft-ietf-tsvwg-udp-options] are an interesting channel to 90 investigate. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119][RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 1.2. Terminology & Abbreviations 102 2. Overview of Bounded Latency Forwarding Schemes 104 In order to figure out what information needs to be carried in an UDP 105 option, this section briefly analyzes existing bounded latency 106 forwarding schemes. More details about forwarding schemes themselves 107 can be found in referenced documents. Generally speaking, in order 108 to ensure end-to-end bounded latency, each hop along the way should 109 be latency-bounded. Different forwarding schemes are actually 110 different packet scheduling methods. 112 2.1. Time Aware Shaping 114 In Time Aware Shaping [IEEE802.1Qbv], each port has several 115 deterministic forwarding queues. Each queue is controlled by a gate. 116 When a gate opens, packets in the associated queue will be 117 transmitted. Otherwise, packets should wait in the queue. A 118 controller calculates the global optimal gate control list for every 119 port as depicted in Figure 1. 121 Queue 0 Queue 1 Queue 7 123 +------+ +------+ +------+ ^^^^^^^^^^^^^^^^^^^^^ 124 |------| |------| |------| ^ Gate Control List ^ 125 |------| |------| |------| ^ ^ 126 |------| |------| |------| ^ 1000 0000 ^ 127 |------| |------| .... |------| ^ ^ 128 |------| |------| |------| ^ 0001 0000 ^ 129 |------| |------| |------| ^ ^ 130 |------| |------| |------| ^ 0000 0001 ^ 131 |------| |------| |------| ^ ^ 132 +--+---+ +--+---+ +--+---+ ^ . ^ 133 | | | ^ . ^ 134 | | | ^ . ^ 135 +--+---+ +--+---+ +--+---+ ^ ^ 136 |Gate=1| |Gate=0| .... |Gate=0| ^ ^ 137 +--+---+ +--+---+ +--+---+ ^ 1: Gate Open ^ 138 | | | ^ ^ 139 | | | ^ 0: Gate Close ^ 140 +--+-----------+----------------+---+ ^ ^ 141 | Transmission | ^^^^^^^^^^^^^^^^^^^^^ 142 +-----------------------------------+ 144 Figure 1: Time Aware Shaping 146 In Time Aware Shaping, the scheme specific information is "Gate 147 Control List". Normally, the gate control list is configured through 148 control plane. There is no need for an extension for Time Aware 149 Shaping scheme. 151 2.2. Cyclic Queuing and Forwarding 153 In Cyclic Queuing and Forwarding (CQF)[IEEE802.1Qch], all nodes are 154 time-synchronized (i.e., time is divided into the same length cycle, 155 and all nodes' cycles start at the same timing). Figure 2 explains 156 the CQF scheme, packets sent out at a cycle will arrive at downstream 157 node at the same cycle, and resent out at the next cycle. As a 158 result, once source node sends out packets at a cycle, then the 159 receiving cycle of these packets at destination node can be 160 determined -- that also means the end-to-end latency is bounded. 162 Upstream Node | cycle x | cycle x+1 | 163 +-----------+-----------+ 164 \ 165 \packet 166 \receiving 167 \ 168 Downstream Node | V | cycle x+1 | 169 +-----------+-----------+ 170 cycle x \packet 171 \sending 172 \ 173 \ 174 V 176 Figure 2: Cyclic Queuing and Forwarding 178 In CQF, the scheme specific information is "sending cycle" at each 179 hop. This specific information is actually indicated by the 180 receiving cycle--each hop can determine the sending cycle of a packet 181 based on the time this packet be received. Hence no need for an 182 extension to explicitly carry any scheme specific information in data 183 plane. 185 2.3. Scalable Deterministic Forwarding (SDF) 187 Considering a large scale network deployment, the scalable 188 deterministic forwarding [draft-qiang-detnet-large-scale-detnet] 189 scheme makes extensions based on CQF. In scalable deterministic 190 forwarding (SDF) scheme, all nodes are frequency-synchronized (i.e., 191 time is divided into the same length cycle, but different nodes' 192 cycles may start at different timing). As shown in Figure 3, at a 193 single cycle y, downstream node may receive packets that were sent 194 out by upstream node in two different cycles (i.e., cycle x and cycle 195 x+1). There are two different queues inside the downstream node to 196 buffer received packets: one is for packets sent out at cycle x, 197 another one is for packets sent out at cycle x+1. The downstream 198 node needs to decide which queue a packet should enter based on its 199 sending cycle at upstream node. 201 Upstream Node | cycle x | cycle x+1 | 202 +-----------+-----------+ 203 \ \ 204 \ \packet 205 \ \receiving 206 Downstream Node | V V | | 207 +-----------+-----------+ 208 cycle y cycle y+1 \ packet 209 \ sending 210 \ 211 V 213 Figure 3: Scalable Deterministic Forwarding 215 In SDF, the scheme specific information is also "sending cycle". 216 Since a node may receive packets with different sending cycles within 217 a single cycle, the sending cycle information should be explicitly 218 carried with packet. Hence there is a need for an extension to carry 219 the sending cycle information in IP data plane. The use of UDP 220 options is a good candidate given the target applications rely upon 221 an UDP transport. 223 2.4. SR based Bounded Latency 225 SR [RFC8402] based bounded latency has similar idea as SDF 226 (Section 2.3), the main difference is that the "sending cycle" 227 information is pre-calculated at controller and carried with packet 228 in MPLS labels. Hence no need for UDP option extension in IP data 229 plane. 231 2.5. Other Bounded Latency Forwarding Schemes 233 TBD 235 3. UDP Option Extension for Bounded Latency Forwarding 237 After analyzing the existing bounded latency forwarding schemes, we 238 found that there are some scheme specific information need to be 239 carried in data plane. IP common header has very limited space, it 240 is difficult to find enough bits in IP common header to carry these 241 scheme specific information. UDP options defined below is a possible 242 solution for this situation. 244 Kind Length Meaning 245 ------------------------------------------- 246 127 1 Sending Cycle (SC) 248 Figure 4: UDP Option Extension 250 3.1. Sending Cycle Option 252 The Sending Cycle (SC) option includes 1-byte cycle identifier filed 253 that indicates the cycle a packet be sent out from upstream node as 254 shown in Figure 5. Normally, the first cyclic forwarding aware node 255 (e.g., edge gateway) is responsible for creating the SC option, and 256 setting the Cycle_Identifier filed to be the corresponding cycle that 257 the packet be sent out. The sending cycle information can help 258 downstream node to determine when the packet should be resent out. 260 After receiving packet from upstream node, the downstream node should 261 interpret the SC option and take an appropriate measures, like 262 entering a certain queue, or re-sending out immediately, or others. 263 If there is only one SC option carried in a packet, the 264 Cycle_Identifier filed may need to be rewritten before re-sending 265 out. 267 One way to relieve in-transit rewriting is to pre-compute the sending 268 cycles along the way, then carry them with multiple SC options. 270 +----------+---------+-------------------+ 271 | Kind=127 | Len=1 | Cycle_Identifier | 272 +----------+---------+-------------------+ 274 Figure 5: Sending Cycle Option 276 3.2. UDP Option for Other Purposes 278 TBD 280 [Note: As more bounded latency forwarding schemes are developed, more 281 UDP option extensions may be required.] 283 4. IANA Considerations 285 This document makes no request of IANA. 287 5. Security Considerations 289 TBD 291 6. Acknowledgements 293 The Authors would like to thank Mohamed Boucadair, Christian 294 Jacquenet and David Black for their review, suggestion and comments 295 to this document. 297 7. Normative References 299 [draft-chen-detnet-sr-based-bounded-latency] 300 "SR based Bounded Latency", 301 . 304 [draft-ietf-detnet-architecture] 305 Sca, "DetNet Architecture", 306 . 309 [draft-ietf-detnet-use-cases] 310 Sca, "DetNet Use Cases", 311 . 314 [draft-ietf-tsvwg-udp-options] 315 "Transport Options for UDPE", 316 . 319 [draft-qiang-detnet-large-scale-detnet] 320 "Large-Scale Deterministic Network", 321 . 324 [IEEE802.1Qbv] 325 "Enhancements for Scheduled Traffic", 2016. 327 [IEEE802.1Qch] 328 "Cyclic Queuing and Forwarding", 2016. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 337 May 2017, . 339 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 340 Decraene, B., Litkowski, S., and R. Shakir, "Segment 341 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 342 July 2018, . 344 Authors' Addresses 346 Li Qiang (editor) 347 Huawei 348 Beijing 349 China 351 Email: qiangli3@huawei.com 353 Toerless Eckert 354 Huawei USA - Futurewei Technologies Inc. 355 2330 Central Expy 356 Santa Clara 95050 357 USA 359 Email: tte+ietf@cs.fau.de