idnits 2.17.1
draft-geng-detnet-requirements-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 (July 2, 2018) is 2125 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 234, but no explicit
reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 3 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 L. Wang
4 Intended status: Informational China Mobile
5 Expires: January 3, 2019 L. Qiang
6 Huawei Technologies
7 July 2, 2018
9 Technical Requirements of Bounded Latency in Large-scale DetNet
10 Deployment
11 draft-geng-detnet-requirements-bounded-latency-00
13 Abstract
15 This document summarizes the technical requirements of bounded
16 latency of DetNet system in large-scale deployment.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at https://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on January 3, 2019.
35 Copyright Notice
37 Copyright (c) 2018 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
54 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3
55 2. End-to-end bounded latency requirements . . . . . . . . . . . 3
56 3. Tolerance of time deviation . . . . . . . . . . . . . . . . . 4
57 4. Massive number of deterministic flows . . . . . . . . . . . . 4
58 5. Stable jitter with long transmission delay . . . . . . . . . 4
59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
62 9. Normative References . . . . . . . . . . . . . . . . . . . . 5
63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
65 1. Introduction
67 Deterministic Networking (DetNet) enables the transmission of
68 specific data flows in large scale networks with extremely low data
69 loss rates and bounded latency. [draft-ietf-detnet-problem-statement]
70 outlines the problems that need to be resolved in DetNet, and
71 [draft-ietf-detnet-use-cases] presents the use cases in which DetNet
72 deployment is found beneficial and useful.
74 In DetNet WG, many of the technical requirements and solution have
75 been discussed In order to achieve deterministic networking
76 performance in large-scale network. This mainly include the
77 following aspect.
79 o DetNet Definition and architecture are discussed in
80 [draft-ietf-detnet-architecture]
82 o Encapsulation methods are discussed in[draft-ietf-detnet-dp-sol]
83 with specific mechanisms for identification of DetNet services and
84 approaches for reliable transmission (i.e. Replication of
85 packets).
87 o Security requirements are specially discussed in
88 [draft-ietf-detnet-security].
90 To some extend, TSN is assumed to be used for Layer 2 underlay for
91 DetNet services to guarantee the bounded latency performance.
92 However, TSN is originally designed for LAN scenario which suffers
93 from scalability problems (i.e. end-to-end time synchronization,
94 sensitive jitter performance subject to transmission latency).
95 Meanwhile, it is also considered challenging to using MPLS/IP
96 encapsulation for DetNet service in which the forwarding plane is
97 purely based on Layer 2 TSN technology. There is yet a document
98 which specifically discusses the requirements of bounded latency with
99 an assumption that DetNet runs as an standalone underlay technology
100 rather than an overlay of TSN.
102 1.1. Requirements Language
104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
106 document are to be interpreted as described in RFC 2119.
108 1.2. Terminology & Abbreviations
110 This document uses the terminology defined in
111 [draft-ietf-detnet-architecture].
113 TSN: Time Sensitive Network
115 2. End-to-end bounded latency requirements
117 As [draft-ietf-detnet-dp-sol] declares, there are two types of
118 scenarios considered in DetNet as shown in Figure 1: (i) inter-
119 connect TSN domains scenario, and (ii) native connectivity between
120 DetNet-aware end systems.
122 +--------------+ +--------------+
123 | | | |
124 | TSN Domain I +-----------------------------+ TSN Domain II|
125 | | | |
126 +--------------+ +--------------+
128 (i) Inter-connect TSN Domains
130 +--------------+ +--------------+
131 |DetNet Device +---------------------------+DetNet Device |
132 +--------------+ +--------------+
134 (ii) Native Connectivity between DetNet-aware End Systems
136 Figure 1: Two Types of DetNet Scenarios
138 Req 1: Stitching TSN domains with bounded latency.
140 In scenario (i) TSN islands are bridged through DetNet connections,
141 and time synchronization is required inside each TSN domain. Note
142 that different TSN domains may be misaligned in time and it may not
143 be feasible to achieve end-to-end time synchronization in large
144 scale. It is the DetNet domain who has to maintain the bounded
145 latency performance between the separated TSN domains.
147 Req 2: Flexible and fast convergence mechanism as new DetNet flow is
148 created.
150 Considering the features of TSN applications we can speculate that
151 the applications in scenario (i) are usually in a simple manner,
152 which means the number of deterministic flows will not dramatically
153 change with time. At the same time, the traffic patterns are
154 relative regular. While in scenario (ii) there are more bandwidth-
155 greddy applications such as VR communication. They may require
156 establishment or tear-down of the DetNet connections frequently.
157 Mechanisms like IEEE 802.1 Qch, and IEEE 802.1 Qbv which need re-
158 computation whenever new flow are added may be not suitable for this
159 case. In order to deploy DetNet services in scenario (ii).
161 3. Tolerance of time deviation
163 Req 3: Tolerance of a certain level of end-to-end time deviation.
165 Different from the TSN services which are deployed in small-scale
166 local area network, DetNet service targets at large scale
167 implementation. There are a great amount of heterogeneous devices in
168 large scale network. It will be difficult and costly to keep precise
169 synchronization among all devices. It is worthy of have a DetNet
170 system which can keep the bounded latency performance even under an
171 unsynchronized situation..
173 4. Massive number of deterministic flows
175 Req 4: Fine-grained and scalable resource reservation method.
177 Resource reservation for individual DetNet flows are required in
178 order to maintain per-flow state in the devices along the path.
179 Given a large number of DetNet flows, aggregation of such resource
180 reservation may be necessary at least at the core routers. However,
181 aggregating massive DetNet flows into a tunnel will sacrifice some
182 network resources or accuracy, just like change from DiffServ to
183 IntServ. Certain trade-off needs to be studied carefully to achieve
184 optimal performance.
186 5. Stable jitter with long transmission delay
188 Req 5: Tolerance of transmission latency
190 Large transmission latency is expected in large scale network which
191 may further lead to larger jitter in some mechanisms such as IEEE
192 802.1 Qch. It would be preferred to have a mechanism where the jitter
193 performance does not scale up with the transmission latency. Thus
194 end user can have same bounded latency performance in a P2MP
195 deployment.
197 6. IANA Considerations
199 This document makes no request of IANA.
201 7. Security Considerations
203 This document will not introduce new security problems.
205 8. Acknowledgements
207 TBD.
209 9. Normative References
211 [draft-ietf-detnet-architecture]
212 "DetNet Architecture", .
215 [draft-ietf-detnet-dp-sol]
216 "DetNet Data Plane Encapsulation",
217 .
220 [draft-ietf-detnet-problem-statement]
221 "DetNet Problem Statement",
222 .
225 [draft-ietf-detnet-security]
226 "DetNet Security Considerations",
227 .
230 [draft-ietf-detnet-use-cases]
231 "DetNet Use Cases", .
234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
235 Requirement Levels", BCP 14, RFC 2119,
236 DOI 10.17487/RFC2119, March 1997,
237 .
239 Authors' Addresses
241 Liang Geng
242 China Mobile
243 Beijing
244 China
246 Email: gengliang@chinamobile.com
248 Lei Wang
249 China Mobile
250 Beijing
251 China
253 Email: wangleiyjy@chinamobile.com
255 Li Qiang
256 Huawei Technologies
257 Huawei Campus, No. 156 Beiqing Rd.
258 Beijing 100095
259 China
261 Email: qiangli3@huawei.com