idnits 2.17.1 draft-dang-detnet-deployment-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([RFC8655]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 12, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC8934' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC9023' is defined on line 507, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Dang, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational Z. Du 5 Expires: January 13, 2022 China Mobile 6 July 12, 2021 8 Services Deployment Guideline in DetNet Network 9 draft-dang-detnet-deployment-00 11 Abstract 13 Deterministic Networking (DetNet) defined in [RFC8655] provides a 14 capability for the delivery of data flows with extremely low packet 15 loss rates and bounded end-to-end delivery latency. DetNet network 16 administrators worldwide can deploy DetNet services into their 17 networks. This document aims to provide a guideline for DetNet 18 network administrators. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 13, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 3 57 4. Preparation of DetNet networks . . . . . . . . . . . . . . . 3 58 5. How to Introduce Deterministic Flow into DetNet network . . . 4 59 5.1. Parameter Specification . . . . . . . . . . . . . . . . . 4 60 5.1.1. Definition of Deterministic Flow . . . . . . . . . . 5 61 5.1.2. Establishing Explicit Path . . . . . . . . . . . . . 6 62 5.2. DetNet Network Element Configuration and Functions . . . 9 63 6. How to Maintain Deterministic Flow in DetNet network . . . . 9 64 7. How to Withdraw Deterministic Flow in DetNet network . . . . 10 65 8. Deployment Trial Experience . . . . . . . . . . . . . . . . . 10 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Deterministic Networking (DetNet) defined in [RFC8655] provides a 74 capability for the delivery of data flows with extremely low packet 75 loss rates and bounded end-to-end delivery latency. The diverse 76 industries in [RFC8578] have in common a need for "deterministic 77 flows". How to introduce deterministic flows to the DetNet network 78 is required. 80 While the DetNet technologies are becoming mature, the DetNet 81 deployment is about to enter the live network experiment and even to 82 large-scale commercial deployment. The DetNet network is actively 83 managed by a network operations entity (the "administrator", whether 84 a single person or a department of administrators). A network 85 administrator is responsible for the deployment of DetNet services, 86 who can must master the skills of how to introduce deterministic 87 flows into DetNet networks and the related maintenance. 89 This document is intended as guidance for DetNet network 90 administrators. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119. 98 3. Terminology & Abbreviations 100 DetNet UPE 102 A DetNet edge node, which connects DetNet flows into DetNet network. 104 DetNet P 106 A DetNet relay node or DetNet transit node. 108 DetNet PE 110 A DetNet edge node, where DetNet flows leave DetNet network. 112 DetNet source 114 An end system is capable of originating a DetNet flow. 116 DetNet Destination 118 An end system is capable of terminating a DetNet flow. 120 4. Preparation of DetNet networks 122 The premise of this section is that the network has not yet enabled 123 DetNet capability. First of all, a network administrator must enable 124 the DetNet capability of the network on demand. 126 The DetNet network administrator must plan the scope of DetNet 127 network, DetNet network topology and DetNet network element roles. 128 As usual, the network controller has collected the topology of the 129 entire network. So the DetNet network administrators only need to 130 specify the scope of DetNet networks, DetNet network topology and 131 DetNet network element roles on the controller interface. When the 132 scope of the DetNet network is determined, the DetNet network 133 administrators can naturally get the DetNet network topology. At 134 that time, the DetNet network administrators must figure out whether 135 the DetNet network is in a single domain or in multiple domains. 137 o If in a single domain, it contains DetNet Ingress UPE nodes, 138 DetNet P nodes, DetNet PE nodes. In fact, a P node may be 139 connected to multiple different UPE devices or PE nodes or P node. 141 o If in multiple domains, it also contains ASBR nodes in addition to 142 Ingress UPE nodes, DetNet P nodes and DetNet PE nodes, for the 143 purpose of cross-domain interconnection. 145 The example is shown in Figure 1, which contain DetNet Ingress UPE 146 node, DetNet P nodes, DetNet PE node. In fact, a P node may be 147 connected to multiple different UPE devices or PE nodes or P node. 149 DetNet DetNet 150 Source Destination 151 DetNet-UNI (U) 152 +--+--+ | +--+--+ 153 | | | | | 154 +--+--+ v +--+--+ 155 | | 156 | +----+ +---+ +---+ +---+ | 157 +----U PE +---+ P +---+...+---+ PE+----+ 158 +----+ +---+ +---+ +---+ 159 | | 160 | End-to-End Service | 161 |------------------------------------->| 162 | Explicit Routes (DetNet Network) | 163 | |--------------------------->| | 165 Figure-1: DetNet Network 167 5. How to Introduce Deterministic Flow into DetNet network 169 For the next work, the DetNet network administrator must specify the 170 following information on the controller. 172 1. Definition of Deterministic Flow 174 2. Establishing Explicit Path for Deterministic Flow 176 * Definition of Deterministic Flow 178 * Specifying Encapsulation Type of Networking Technology 180 * Specifying Type of Queuing Mechanism 182 * Definition of Service Protection 184 * Network Resource Evaluation and Reservation 186 The section 5.1 focus on how to use these parameters. 188 5.1. Parameter Specification 189 5.1.1. Definition of Deterministic Flow 191 A DetNet network administrator must figure out 193 o how to identify a deterministic flow, 195 o the related DetNet SLA requirements, 197 o which node the DetNet flow is accessed from and which node the 198 DetNet flow leaves from. 200 This above information must be given the DetNet network administrator 201 by DetNet service providers who initiate or terminate DetNet flows. 203 The flow identification in [RFC9016] let the DetNet UPE node identify 204 the flow. Flow identification for MPLS and IP Data Planes are 205 described in [RFC8939] , [RFC8964], and Ethernet information (such as 206 MAC address, VLAN) respectively. 208 o IP Data plane: five tuple 210 o Ethernet data plane: MAC address or VLAN 212 o MPLS or SR data plane: label 214 The SLA information of DetNet flow in section 5.9 of [RFC9016] are 215 listed as follows. 217 o MinBandwidth 219 o MaxLatency 221 o MaxLoss 223 o MaxConsecutiveLossTolerance 225 o MaxMisordering 227 If the deterministic flow has requirement for Jitter, a new parameter 228 named jitter needs to be added. 230 In the follow-up work, the DetNet network administrator creates 231 explicit route defined in section 3.2.3 of [RFC8655] according to the 232 information which node the DetNet flow is accessed from and which 233 node the DetNet flow leaves from. 235 5.1.2. Establishing Explicit Path 237 The DetNet network administrator must pay attention to the 238 encapsulation type of the explicit route, which is added to the 239 DetNet flows when DetNet flow enters the UPE node. The DetNet 240 network administrator may freely choose encapsulation type of the 241 networking technology according to his/her preferences. The way of 242 IP over SR or [IP-Over-MPLS] or IP over SR) is recommended. 244 5.1.2.1. Encapsulation Type of Networking Technology 246 The DetNet network administrator must pay attention to the 247 encapsulation type of the explicit route, which is added to the 248 DetNet flows when DetNet flow enters the UPE node. The DetNet 249 network administrator may freely choose encapsulation type of the 250 networking technology according to his/her preferences. The way of 251 IP over SR or [IP-Over-MPLS] or IP over SR) is recommended. 253 5.1.2.2. Type of Queuing Mechanism 255 The DetNet network administrator obtains or sets the queuing type 256 used by the network. If the cyclic queuing mechanism is used in the 257 network, the parameters of the queuing need to be set as follows. 258 This mechanism must allow multiple deterministic flows to share a 259 periodic buffer. 261 o CyclicBufferSize: the length of the cyclic buffer 263 o CyclicInterval: duration of periodic scheduling 265 o BufferNumber: the number of the cyclic buffer 267 o MinBurstSize: the minimum burst size that can be tolerated by 268 cyclic queue mechanism, which is specified in octets per second 269 and excludes additional DetNet header (if any).Bandwidth used 270 above the Committed Information rate is called Burst traffic. It 271 is used when the bandwidth available is more than CIR. 272 MinBurstSize is the minimum burst size that has to be guaranteed 273 for the DetNet traffic. The queuing mechanism needs to pay 274 attention to how to shape burst size traffic into buffers. 276 5.1.2.3. Definition of Service Protection 278 The DetNet network administrator can consider how to do with service 279 protection to meet MaxLoss, MaxConsecutiveLossTolerance and 280 MaxMisordering of a deterministic flow. The premise of service 281 protection is that there are multiple available explicit paths for a 282 DetNet flow. These types of packet loss can be greatly reduced by 283 spreading the data over multiple disjointed forwarding paths. The 284 PREOF embeded in the PE node ensures that packets are not out of 285 order. 287 5.1.2.4. Network Resource Evaluation and Reservation 289 The DetNet network administrator can enable network resource 290 evaluation and reservation of the controller. In fact, the network 291 may support a distributed protocol similar to RSVP defined in 292 [draft-trossen-detnet-rsvp-tsn], so this function can rely on the 293 distributed protocol. 295 The DetNet SLA requirements to the DetNet flow generally have 296 deterministic bandwidth, bounded latency and bounded jitter. But in 297 fact these three parameters are interrelated. For example, the 298 insufficient bandwidth reservation might introduce the additional 299 delay or the additional jitter. Therefore, the bandwidth reservation 300 should consider the latency and jitter requirements. 302 There are three methods here to do with, one is to get it through 303 centralized calculation provided by controller or other centralized 304 systems, the other is to get it through negotiation between DetNet 305 Nodes along the explicit routes, and the third is to rely on the 306 human brain. When the scale of the network becomes larger or the 307 types of services become more, the third method is difficult to 308 handle. Therefore, the first and the second methods are recommended. 309 These centralized and distributed solutions can cooperate with each 310 other, for example, if the centralized system is offline, the 311 distributed system functions will be enabled. Or in order to support 312 rapid network decision-making, the priority is given to using 313 distributed systems for deployment, and the centralized systems are 314 responsible for global optimization. 316 The algorithm on the network resource reservation is not discussed 317 now in this document. 319 5.1.2.4.1. DetNet Bandwidth Evaluation and Reservation 321 The DetNet network administrator must know the bandwidth resource 322 evaluation and reservation can be divided into service access 323 interface part on the DetNet UPE node and explicit route part. 325 o Service access interface part on the DetNet UPE node: The 326 bandwidth of service access interface part on the DetNet UPE is 327 reserved according to the MinBandwidth of the DetNet flow. 329 o Explicit route part: This mechanism ensures that the available 330 bandwidth along the explicit path can meet MinBandwidth of DetNet 331 flow. 333 The P node should take into account that there are multiple explicit 334 routes passing in the same direction. For example, if one interface 335 of P node accesses 3 explicit paths, the reserved bandwidth of the 336 interface is the total required bandwidth of the 3 explicit paths. 338 It is emphasized that the remaining bandwidth of the interface on the 339 DetNet nodes can also be used for non-DetNet flows. 341 5.1.2.4.2. DetNet Latency Evaluation 343 The DetNet network administrator can let the controller collect the 344 network-wide delay information for calculation and evaluation, and 345 obtain the queuing type. 347 Given that DetNet nodes have a finite amount of buffer space, the 348 resource allocation necessarily results in a maximum end-to-end 349 latency. The overall latency of the explicit route can be calculated 350 based on the queue scheduling mechanism on the data plane of the 351 DetNet nodes. The queue scheduling mechanisms have various types, 352 such as DiffServ,Qch[IEEE802.1QCH] and so on. 353 [DetNet-Bounded-Latency] provides end-to-end delay bound and backlog 354 bound computations for such mechanisms that can be used by the 355 control plane to provide DetNet QoS. If the CQF is used, 356 CyclicBufferSize, CyclicInterval and BufferNumber of queuing 357 mechanism can be included in the calculation factors that affect the 358 E2E delay. 360 The controller evaluates the path delay based on the resources of the 361 entire network, and judges whether it meets the MaxLatency of the 362 deterministic flow. 364 5.1.2.4.3. DetNet Jitter Evaluation 366 The DetNet network administrator can figure out that there are two 367 aspects to reduce network jitter. The first is through resource 368 reservation in section 4.4.1 to 4.4.2 , and the second is through 369 effective queuing control methods. The former is not easy to 370 evaluate jitter, but the latter is very convenient. The DetNet 371 network administrator also can know the queuing type, because not all 372 queuing mechanisms have a jitter control mechanism. The CQF is 373 recommend to effectively solve the uncertainty of jitter. Under this 374 mechanism, the end to end jitter can be controlled within 2 * 375 CyclicInterval. 377 5.2. DetNet Network Element Configuration and Functions 379 After the information is input by the DetNet network administrator, 380 the controller will convert the information into the network 381 configuration and send it to the DetNet network element node, using a 382 protocol such as NETCONF [RFC6241]/YANG[RFC6020]. Deterministic 383 Networking (DetNet) YANG Model defined in [DetNet-YANG] contains the 384 specification for the Deterministic Networking YANG Model for 385 configuration and operational data for DetNet Flows. 387 After DetNet network equipment receives the configuration, it starts 388 to execute. As Figure 2 is shown, the functions of each DetNet 389 network element is clearly visible. 391 SDN +----+ 1.Entrance to the above information 392 Controller | | 2.Network Resource Evaluation and Reservation(Optional) 393 +----+ 3.Converting the information into the network configuration 394 | 395 +--------+-------+------+ 396 | | | | 397 +----+ +---+ +---+ +---+ 398 U PE +---+ P +---+...+---+ PE+ 399 +----+ +---+ +---+ +---+ 400 | | | 401 | | +-->+-----------------------------+ 402 | | |1. Enabling queuing mechanism| 403 | | |2. End Explicit Path | 404 | | +-----------------------------+ 405 | +-->+--------------------------+ 406 | |Enabling queuing mechanism| 407 | +--------------------------+ 408 +--> +-------------------------------------------------------+ 409 |1.Identifying a deterministic flow | 410 |2.Establishing explicit path for the deterministic flow| 411 |3.Enabling queuing mechanism | 412 +-------------------------------------------------------+ 414 Figure-2: DetNet Network Functions 416 6. How to Maintain Deterministic Flow in DetNet network 418 TBD 420 If a new DetNet flow needs to be added into the existing DetNet 421 network, the network administrators will operate according to section 422 4.1~4.5. 424 7. How to Withdraw Deterministic Flow in DetNet network 426 TBD 428 If a DetNet flow deployed needs to be canceled, the network 429 administrator will execute the corresponding undo operation through 430 the controller, and the network will release the corresponding 431 resources. 433 8. Deployment Trial Experience 435 TBD 437 9. Security Considerations 439 TBD 441 10. Acknowledgements 443 TBD 445 11. Normative References 447 [DetNet-Bounded-Latency] 448 "DetNet Bounded Latency", . 451 [DetNet-YANG] 452 "Deterministic Networking (DetNet) YANG Model", 453 . 456 [draft-trossen-detnet-rsvp-tsn] 457 "RSVP for TSN Networks", . 460 [IEEE802.1QCH] 461 "IEEE Standard for Local and metropolitan area networks-- 462 Bridges and Bridged Networks--Amendment 29: Cyclic Queuing 463 and Forwarding", 464 . 466 [IP-Over-MPLS] 467 "DetNet Data Plane: IP over MPLS", . 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels", 476 . 478 [RFC6020] "YANG - A Data Modeling Language for the Network 479 Configuration Protocol (NETCONF)", 480 . 482 [RFC6241] "Network Configuration Protocol (NETCONF)", 483 . 485 [RFC8402] "Segment Routing Architecture", 486 . 488 [RFC8578] "Deterministic Networking Use Cases", 489 . 491 [RFC8655] "Deterministic Networking Architecture", 492 . 494 [RFC8934] "Deterministic Networking (DetNet) Data Plane: MPLS", 495 . 497 [RFC8939] "Deterministic Networking (DetNet) Data Plane: IP", 498 . 500 [RFC8964] "Deterministic Networking (DetNet) Data Plane: MPLS", 501 . 503 [RFC9016] "Flow and Service Information Model for Deterministic 504 Networking (DetNet)", 505 . 507 [RFC9023] "Deterministic Networking (DetNet) Data Plane: IP over 508 IEEE 802.1 Time-Sensitive Networking (TSN)", 509 . 511 Authors' Addresses 512 Joanna Dang (editor) 513 Huawei 514 No.156 Beiqing Road 515 Beijing, P.R. China 100095 516 China 518 Email: dangjuanna@huawei.com 520 Zongpeng Du 521 China Mobile 522 32 Xuanwumen West St 523 Beijing, P.R. China 100053 524 China 526 Email: duzongpeng@chinamobile.com