idnits 2.17.1
draft-geng-detnet-requirements-bounded-latency-02.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 (June 3, 2019) is 1760 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. Geng
3 Internet-Draft China Mobile
4 Intended status: Informational P. Willis
5 Expires: December 5, 2019 BT
6 S. Homma
7 NTT
8 L. Qiang
9 Huawei
10 June 3, 2019
12 Requirements of Layer 3 Deterministic Latency Service
13 draft-geng-detnet-requirements-bounded-latency-02
15 Abstract
17 This document specifies some technical, operational and management
18 requirements of deploying deterministic latency service on layer 3
19 networks from the perspective of the service provider.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at https://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on December 5, 2019.
38 Copyright Notice
40 Copyright (c) 2019 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
57 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3
58 2. Technical Requirements . . . . . . . . . . . . . . . . . . . 3
59 2.1. Requirement 1: Must support the dynamic creation,
60 modification and deletion of deterministic services . . . 3
61 2.2. Requirement 2: Should tolerate a certain degree of time
62 variance . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2.2.1. Sub-requirement 2.1: Should support asynchronous
64 clocks across domains . . . . . . . . . . . . . . . . 4
65 2.2.2. Sub-requirement 2.2: Should tolerate clock jitter &
66 wander within a clock synchronous domain . . . . . . 4
67 2.3. Requirement 3: Must support Inter-Continental propagation
68 delay . . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 3. Operational and Management Requirements . . . . . . . . . . . 6
70 3.1. Requirement 4: Should have self-monitoring capability . . 6
71 3.2. Requirement 5: Should be robust against denial of service
72 attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6
73 3.3. Requirement 6: Must tolerate failures of links or nodes
74 and topology changes . . . . . . . . . . . . . . . . . . 7
75 3.4. Requirement 7: Must be scalable . . . . . . . . . . . . . 7
76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
79 7. Normative References . . . . . . . . . . . . . . . . . . . . 8
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
82 1. Introduction
84 DetNet is chartered to provide bounds on latency, jitter (delay
85 variation) and packet loss [draft-ietf-detnet-problem-statement].
86 Where latency and jitter are two closely related performance
87 characteristics, this document refers to bounded latency and bounded
88 jitter collectively as deterministic latency.
90 This document does not intend to define any specific mechanism, but
91 specifies some technical, operational and management requirements
92 that must be considered when deploying deterministic latency service
93 at layer 3.
95 1.1. Requirements Language
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
99 "OPTIONAL" in this document are to be interpreted as described in BCP
100 14 [RFC2119][RFC8174] when, and only when, they appear in all
101 capitals, as shown here.
103 1.2. Terminology & Abbreviations
105 This document uses the terminology defined in
106 [draft-ietf-detnet-architecture].
108 TSN: Time Sensitive Network
110 2. Technical Requirements
112 2.1. Requirement 1: Must support the dynamic creation, modification and
113 deletion of deterministic services
115 There are at least two modes to provide deterministic service over an
116 operator's network: 1) deterministic VPN; 2) point-to-point
117 deterministic tunnel. No matter in which mode, the layer 3
118 deterministic latency mechanisms must be able to support the dynamic
119 creation, modification and deletion of deterministic services without
120 affecting any deterministic services that are already running in the
121 network.
123 In a local area network such as a factory, the information about when
124 a deterministic service will start, how long the service will last,
125 can be known in advance, or can even be planned. Based on this
126 information, the local area network can adopt a global programming
127 mechanism to calculate the accurate processing behaviors for each
128 device, and achieve a global optimal performance. However, such
129 global programming mechanisms are unsuitable for service providers'
130 networks. Many deterministic applications are expected to running on
131 a service provider's network simultaneously. Different deterministic
132 applications may have different lifecycles and SLA requirements,
133 hence the network state changes dynamically. If a mechanism relies
134 on a stable network state for global computing, any change in network
135 state (e.g., new application starts, or an application finishes, or
136 SLA requirement changes) will lead to re-computing, even worse if all
137 devices need to stop work and install the recomputed results, then
138 this mechanism is hard to be deployed on service provider's network.
140 2.2. Requirement 2: Should tolerate a certain degree of time variance
142 2.2.1. Sub-requirement 2.1: Should support asynchronous clocks across
143 domains
145 One of DetNet's objectives is to stitch TSN islands together. All
146 devices inside a TSN domain are time-synchronized, and most of TSN
147 technologies rely on precise time synchronization. However,
148 different TSN islands may have different clocks which are not
149 synchronized as shown in Figure 1, where the time difference of two
150 TSN domain is D. DetNet needs to connect these two TSN domains
151 together and provide end-to-end deterministic latency service. The
152 mechanism adopted by DetNet should be able to support the interaction
153 across time domains by using a fine controlled buffer (the time
154 difference 'D' may be us-level) to absorb the time difference, or
155 relying on the mechanism itself to implement cross domain time
156 mapping.
158 +--------------+ +--------------+
159 | | DetNet Connection | |
160 | TSN Domain I +-----------------------------+ TSN Domain II|
161 | | | |
162 +--------------+ +--------------+
164 | | | | |
165 Clock of TSN +--------+--------+--------+--------+
166 Domain I =
167 =
168 = | | | | |
169 Clock of TSN = +--------+--------+--------+--------+
170 Domain II = =
171 =<==D==>=
172 = =
174 Figure 1: TSN islands interconnecting
176 2.2.2. Sub-requirement 2.2: Should tolerate clock jitter & wander
177 within a clock synchronous domain
179 DetNet domain itself can be time synchronous or asynchronous,
180 depending on the technology selection of different operators. Even
181 within a time synchronous domain, the synchronized clocks may also
182 experience jitter & wander, the mechanisms adopted by DetNet should
183 be able to tolerate a certain degree of clock jitter & wander.
185 2.3. Requirement 3: Must support Inter-Continental propagation delay
187 In contrast to Layer 2 TSN that is deployed on a LAN [IEEE-TSN],
188 DetNet is expected to be deployed in a larger scale carrier networks
189 that have long link propagation delay which means that DetNet must
190 work on network links that have inter-continental propagation delays.
191 Long link propagation delay can cause some troubles to cyclic
192 forwarding type mechanisms. In order to guarantee deterministic
193 latency, cyclic forwarding type mechanisms usually require a packet
194 be sent out (or received) at a particular cycle, rather than be sent
195 out (or received) randomly. There is a mapping between the sending
196 cycle of upstream node and the receiving cycle of downstream node.
197 In a local area network that with short link propagation delay, the
198 cycle mapping relationship could be very simple.
200 As an example shown in Figure 2, where the length of a cycle is 10
201 us, and the sending cycle of upstream node X and the receiving cycle
202 of downstream node Y correspond to the same period of time (e.g.,
203 0~10 us). Packets sent from X at sending cycle will arrive at
204 downstream node Y at receiving cycle, and the link propagation delay
205 between X and Y is smaller than the length of a cycle (i.e., 10 us).
207 Suppose a large scale network wants to keep using this simple cycle
208 mapping relationship, however the link distance between two nodes is
209 longer. Moreover, a downstream node may have many upstream nodes
210 each with different link propagation delays (e.g., 9 us, 10 us, 11
211 us, 15 us, 20 us). In order to absorb the longest link propagation
212 delay, then the length of cycle must be set to at least 20 us.
213 However since packet's arrival time varies within the receiving
214 cycle, larger cycle length means larger delay variance.
216 Upstream Node X |sending cycle | |
217 +--"------------+------------+
218 = "\ = =
219 = " \ = =
220 = " \ = =
221 = " \ = =
222 = " V = =
223 Downstream Node Y |receiving cycle| |
224 +--"----"-------+----\-------+
225 = " " = \ =
226 = " " = V resent out
227 = " " = =
228 Time Line -=--"----"-------=------------=----->
229 (in us) 0 Link 10 20
230 Propagation
231 Delay
233 Figure 2: An example of limited link
235 3. Operational and Management Requirements
237 [Authors note: more explanations for each requirement need to be
238 added in later versions.]
240 3.1. Requirement 4: Should have self-monitoring capability
242 Both network operators and end-users need to be able to measure if
243 the deterministic latency service is working correctly and meeting
244 its SLA. Once the monitored results exceed the expected bounds,
245 network operators and end-users should be notified, and some service
246 protection mechanisms should also be triggered accordingly. In
247 addition, network operators can input the collected results into a
248 reporting system and produce the latency (and jitter) distribution
249 over a period of time, which would be helpful for operators in
250 understanding their networks performance.
252 However, such fine-granularity monitoring is costly. Hence although
253 the self-monitoring is an important capability to both operators and
254 customers, it is not recommended as a mandatory requirement until the
255 use cases are clear.
257 3.2. Requirement 5: Should be robust against denial of service attacks
259 To protect the services requiring deterministic latency, the
260 mechanisms implemented by DetNet should be robust to denial of
261 service attacks. This includes robustness against attacks on the
262 mechanisms to generate clock synchronization.
263 [draft-ietf-detnet-architecture] has discussed using the traffic
264 admission control at the ingress or through the fault mitigation
265 methods, to prevent (or mitigate) the excess traffic caused by
266 malicious or malfunction devices. DetNet also considers using
267 authentication and authorization to mitigate man-in-the middle
268 attacks
270 3.3. Requirement 6: Must tolerate failures of links or nodes and
271 topology changes
273 A step change in latency due to a single network topology change is
274 inevitable. However if the topology keeps changing many times, then
275 DetNet may not deliver on its SLA. The topology changes alone may
276 not be sufficient on a traditional IP network to raise any alarms,
277 but the mechanism's self-monitoring should detect this, and keep
278 working in flapping network topologies.
280 3.4. Requirement 7: Must be scalable
282 Further to the requirement to work on inter-continental links, the
283 deterministic latency forwarding mechanisms must scale to networks of
284 significant size. The number of DetNet devices and flows in a
285 network will be very dependent on the use case. A simple use case to
286 understand is ultra-low-latency (public) 5G transport networks, which
287 would require DetNet extend to every 5G base station. For some
288 network operators, their network may need to connect to ~100 K base
289 stations (serving multiple MNOs'), and this number will only increase
290 with 5G. If each ultra-low-latency slice or MNO is treated as a
291 separate deterministic latency traffic flow (or tunnel), then even if
292 each base station has a limited number of ultra-low latency slices or
293 MNOs (e.g. ~10), there will still be a lot of, ~1M, deterministic
294 latency traffic flows on one network simultaneously.
296 [Authors note: Req. 1 and Req. 3 also have some discussions relevant
297 to scalability. Need more comments and suggestions to help
298 reorganize the contents.]
300 4. IANA Considerations
302 This document makes no request of IANA.
304 5. Security Considerations
306 This document will not introduce new security problems.
308 6. Acknowledgements
310 The Authors would like to thank David Black, Stewart Bryant for their
311 review, suggestion and comments to this document.
313 7. Normative References
315 [draft-ietf-detnet-architecture]
316 "DetNet Architecture", .
319 [draft-ietf-detnet-problem-statement]
320 "DetNet Problem Statement",
321 .
324 [IEEE-TSN]
325 "IEEE TSN Task Group",
326 .
328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
329 Requirement Levels", BCP 14, RFC 2119,
330 DOI 10.17487/RFC2119, March 1997,
331 .
333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
335 May 2017, .
337 Authors' Addresses
339 Liang Geng
340 China Mobile
341 Beijing
342 China
344 Email: gengliang@chinamobile.com
346 Peter Willis
347 BT
348 BT Adastral Park
349 Ipswich IP5 3RE
350 UK
352 Email: peter.j.willis@bt.com
353 Shunsuke Homma
354 NTT
355 Tokyo
356 Japan
358 Email: shunsuke.homma.fp@hco.ntt.co.jp
360 Li Qiang
361 Huawei
362 Huawei Campus, No. 156 Beiqing Rd.
363 Beijing 100095
364 China
366 Email: qiangli3@huawei.com