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