idnits 2.17.1 draft-qiang-detnet-large-scale-detnet-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (May 29, 2018) is 2152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 295, but no explicit reference was found in the text Summary: 1 error (**), 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. Qiang, Ed. 3 Internet-Draft B. Liu 4 Intended status: Informational Huawei 5 Expires: November 30, 2018 L. Geng 6 China Mobile 7 May 29, 2018 9 Large-Scale Deterministic Network 10 draft-qiang-detnet-large-scale-detnet-00 12 Abstract 14 This document presents a Large-scale Deterministic Network (LDN) 15 system, which consists of Scalable Deterministic Forwarding (SDF) and 16 Scalable Resource Reservation (SRR). 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 November 30, 2018. 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 . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 2 55 2. Scalable Deterministic Forwarding . . . . . . . . . . . . . . 3 56 2.1. Three Queues . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Cycle Identifier Carrying . . . . . . . . . . . . . . . . 5 58 3. Scalable Resource Reservation . . . . . . . . . . . . . . . . 5 59 4. Performance Analysis . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Queueing Delay . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 This document presents a Large-scale Deterministic Network (LDN) 71 system, which consists of Scalable Deterministic Forwarding (SDF) and 72 Scalable Resource Reservation (SRR). The technologies of SDF and SRR 73 can be used independently. 75 As [draft-ietf-detnet-problem-statement] indicates, deterministic 76 forwarding can only apply on flows with well-defined traffic 77 characteristics. The traffic characteristics of DetNet flow has been 78 discussed in [draft-ietf-detnet-architecture], that could be achieved 79 through shaping at Ingress node or up-front commitment by 80 application. This document assumes that DetNet flows follow some 81 specific traffic patterns accordingly. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119. 89 1.2. Terminology & Abbreviations 91 This document uses the terminology defined in 92 [draft-ietf-detnet-architecture]. 94 TSN: Time Sensitive Network 96 CQF: Cyclic Queuing and Forwarding 97 LDN: Large-scale Deterministic Network 99 SDF: Scalable Deterministic Forwarding 101 SRR: Scalable Resource Reservation 103 DSCP: Differentiated Services Code Point 105 EXP: Experimental 107 T: the length of a cycle 109 H: the number of hops 111 K: the size of aggregated resource reservation window 113 2. Scalable Deterministic Forwarding 115 DetNet aims at providing deterministic service over large scale 116 network. In large scale network, it is difficulty to get precise 117 time synchronization among numerous and diverse devices. As a 118 compromise, this document assumes that just clock synchronization is 119 required among devices. That is different devices maintain the same 120 clock frequency 1/T, but may at the different time as shown in 121 Figure 1. 123 <-----T-----> <-----T-----> 124 | | | | | | 125 Node A +-----------+-----------+ Node A +-----------+-----------+ 127 | | | | | | 128 Node B +-----------+-----------+ Node B +-----------+-----------+ 130 (i) time synchronization (ii) clock synchronization 132 Figure 1: Time Synchronization & Clock Synchronization 134 IEEE 802.1 CQF is an efficient forwarding mechanism in TSN that 135 guarantees bounded end-to-end latency. CQF is designed for limited 136 scale network, the time synchronization is required, and the link 137 propagation delay is required to be smaller than a cycle length T. 138 Considering the large scale network deployment, the proposed Scalable 139 Deterministic Forwarding (SDF) permits clock synchronization and link 140 propagation delay may exceed T. Besides these two points, CQF and 141 the asynchronous forwarding are very similar. 143 Figure 2 compares them through an example. Suppose Node A is the 144 upstream node of Node B. In CQF, packets sent from Node A at cycle 145 x, will be received by Node B at the same cycle, then further be sent 146 to downstream node by Node B at cycle x+1. Due to long link 147 propagation delay and clock synchronization, Node B will receive 148 packets from Node A at different cycle denoted by y in the SDF, and 149 Node B swaps the cycles carried in packets with y+1, then sends out 150 those packets at cycle y+1. This kind of cycle mapping (e.g., x <--> 151 y+1) exists between any pair of neighbor nodes, can be studied 152 through just once forwarding. With this mapping, the receiving node 153 can easily figure out when the received packets should be send out, 154 the only requirement is to carry the cycle identifier of sending node 155 in the packets. 157 | cycle x | cycle x+1 | | cycle x | cycle x+1 | 158 Node A +-----------+-----------+ Node A +-----------+-----------+ 159 \ \ 160 \packet \packet 161 \receiving \receiving 162 \ \ 163 | V | cycle x+1 | | V | cycle y+1| 164 Node B +-----------+-----------+ Node B +-----------+-----------+ 165 cycle x \packets cycle y \packets 166 \sending \sending 167 \ \ 168 \ \ 169 V V 171 (i) CQF (ii) SDF 173 Figure 2: CQF & SDF 175 2.1. Three Queues 177 In CQF each port needs to maintain 2 (or 3) queues for each class of 178 flows, one is used to buffer newly received packets, another one is 179 used to store the packets that are going to be sent out, one more 180 queue may be needed to avoid output starvation [scheduled-queues]. 181 While in SDF, at least 3 queues are needed. 183 As Figure 3 illustrated, a node may receive packets sent at two 184 different cycles from a single upstream node due to the clock 185 synchronization. Following the timing slot mapping (i.e., x <--> 186 y+1), packets that carry cycle identifier x should be send out by 187 Node B at cycle y+1, and packets that carry cycle identifier x+1 188 should be send out by Node B at cycle y+2. Therefore, two queues are 189 needed to store the newly received packets, as well as one queue to 190 store the sending packets. In order to absorb jitter, more queues 191 also might be necessary. 193 | cycle x | cycle x+1 | 194 Node A +-----------+-----------+ 195 \ \ 196 \ \packet 197 \ \receiving 198 | V V | | 199 Node B +-----------+-----------+ 200 cycle y cycle y+1 202 Figure 3: Three Queues in SDF 204 2.2. Cycle Identifier Carrying 206 As former two sections explained, cycle identifier needs to be 207 carried in packet, so that an appropriate queue can be selected 208 accordingly. That means 2 bits is needed in the three queues model 209 of SDF, in order to identify different cycles between a pair of 210 neighbor nodes. There are several ways to carry this 2 bits cycle 211 identifier, for example: 213 o DSCP of IPv4 Header 215 o Traffic Class of IPv6 Header 217 o EXP of MPLS Header 219 o EtherType of Ethernet Header 221 o IPv6 Extension Header 223 o TLV of SRv6 225 o EXP of MPLS-SR Header 227 3. Scalable Resource Reservation 229 SDF must work with some resource reservation mechanisms, that can be 230 the proposed Scalable Resource Reservation (SRR) or other mechanisms. 231 Resource reservation guarantees the necessary network resources when 232 deterministic flows are scheduled. Network nodes have to record how 233 many network resources are reserved for a specific flow from when it 234 starts to when it ends (e.g., ). Maintaining per-flow resource reservation 236 status may be acceptable to edge nodes, but un-acceptable to core 237 nodes. [draft-ietf-detnet-architecture] pointed out that aggregation 238 must be supported for scalability. 240 [Details of SRR is TBD.] 242 4. Performance Analysis 244 4.1. Queueing Delay 246 End-to-end queueing delay's expectation is 1.5*T*H, where H is the 247 number of hops. 249 [Detailed Analysis is TBD] 251 4.2. Jitter 253 Jitter's upper bound is 2*T. 255 [Detailed Analysis is TBD] 257 5. IANA Considerations 259 This document makes no request of IANA. 261 6. Security Considerations 263 Security issues have been carefully considered in 264 [draft-ietf-detnet-security]. More discussion is TBD. 266 7. Acknowledgements 268 TBD. 270 8. Normative References 272 [draft-ietf-detnet-architecture] 273 "DetNet Architecture", . 276 [draft-ietf-detnet-dp-sol] 277 "DetNet Data Plane Encapsulation", 278 . 281 [draft-ietf-detnet-problem-statement] 282 "DetNet Problem Statement", 283 . 286 [draft-ietf-detnet-security] 287 "DetNet Security Considerations", 288 . 291 [draft-ietf-detnet-use-cases] 292 "DetNet Use Cases", . 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [scheduled-queues] 301 "Scheduled queues, UBS, CQF, and Input Gates", 302 . 305 Authors' Addresses 307 Li Qiang (editor) 308 Huawei 309 Beijing 310 China 312 Email: qiangli3@huawei.com 314 Bingyang Liu 315 Huawei 316 Beijing 317 China 319 Email: liubingyang@huawei.com 321 Liang Geng 322 China Mobile 323 Beijing 324 China 326 Email: gengliang@chinamobile.com