idnits 2.17.1 draft-du-detnet-layer3-low-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 9, 2020) is 1506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Standards Track L. Geng 5 Expires: September 10, 2020 China Mobile 6 March 9, 2020 8 Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic 9 draft-du-detnet-layer3-low-latency-00 11 Abstract 13 This document introduces a method to decrease the micro-bursts in 14 Layer3 network for low-latency traffic. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Mechanism to Decrease Micro-bursts . . . . . . . . . . . . . 3 58 2.1. Process of Edge Node . . . . . . . . . . . . . . . . . . 3 59 2.2. Process of Forwarding Node . . . . . . . . . . . . . . . 4 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Problem Statement 70 Currently, the DetNet architecture in RFC 8655 [RFC8655] is supposed 71 to work in campus-wide networks and private WANs, and hasn't covered 72 the large-scale ISP network scenario. However, the low-latency 73 requirement exists in both L2 and L3 networks, and in both small and 74 large networks. 76 As talked in [I-D.qiang-detnet-large-scale-detnet], deploying 77 deterministic services in a large-scale network brings a lot of new 78 challenges. A novel method called LDN is introduced in 79 [I-D.qiang-detnet-large-scale-detnet], which explores the 80 deterministic forwarding over a large-scale network. 82 According to RFC 8655 [RFC8655], DetNet operates at the IP layer and 83 delivers service over lower-layer technologies such as MPLS and IEEE 84 802.1 Time-Sensitive Networking (TSN). However, the TSN mechanisms 85 are designed for L2 network originally, and cannot be directly used 86 in the large-scale layer 3 network because of various reasons. For 87 example, some TSN mechanisms need synchronization of the network 88 equipments, which is easier in a small network, but hard in a large 89 network; some mechanisms need a per-flow state in the forwarding 90 plane, which is un-scalable; and some TSN mechanisms need a constant 91 and forecastable traffic characteristics, which is more complicated 92 in a large network where much more flows exist and the traffic 93 characteristics is more dynamic. 95 The current forwarding mechanism in an IP router is based on 96 statistical multiplexing, and cannot provide the deterministic 97 service because of various reasons. Even be given a high priority, a 98 deterministic packet can experience a long congestion delay or be 99 lost in a relatively light-loaded network, which is called micro- 100 burst in the network. 102 Figure 1 show the problem of the current scheduling mechanism of an 103 IP network. Before the scheduling in an IP network, the critical 104 packets are well paced, but after the scheduling, the packets will be 105 gathered even the total traffic rate is unchanged. When an IP 106 outgoing interface receives multiple critical flows from several 107 incoming interfaces, the situation becomes more serious. However, an 108 IP router will try to send them as soon as possible, so occasionally, 109 in some later hops, micro-bursts will emerge. 111 _ _ _ _ _ _ _ _ _ _ _ 112 | | | | | | | | | | | | | | | | | | | | | | 113 --------------------------------------------------------------------- 114 Before scheduling in an IP network 116 _ _ _ _ _ _ _ _ _ _ _ 117 | || || || || || | | || || || || | 118 --------------------------------------------------------------------- 119 After scheduling in an IP network 121 Figure 1: Change of the traffic characteristics in an IP network 123 This document proposes a method to support the low latency traffic 124 bearing in an IP network by avoiding micro-bursts in the network as 125 much as possible. 127 2. Mechanism to Decrease Micro-bursts 129 The mechanism needs the cooperation of the edge node and the 130 forwarding node in an IP network. 132 2.1. Process of Edge Node 134 The edge node of the IP network can recognize each critical flows 135 just as in the TSN network, and then give them individually a good 136 shaping. In fact, in TSN mechanisms, no micro-busrt will emerge for 137 critical traffic, and each TSN mechanism is proved to be effective 138 under some conditions. 140 This document suggests the edge node to shape the critical traffic by 141 using the CBS method in IEEE 802.1Qav, or the shaping methods in IEEE 142 802.1Qcr. They can generate a paced traffic for each critical flow. 144 The parameters of the shaper, such as the sending rate, can be 145 configured for each flow by some means. 147 2.2. Process of Forwarding Node 149 For the forwarding node, it is uneasy to recognize each critical flow 150 because of the high pressure of forwarding. It is suggested that no 151 per-flow state is maintained in the forwarding node. Hence, the 152 forwarding node needs to aggregate the critical flows and handle them 153 together. 155 This document suggests that the forwarding node can deploy a specific 156 queue at each outgoing interface. The queue will buffer all critical 157 traffic that need to go out through that interface, and will pace 158 them by using methods mentioned in Section 2.1. 160 The shaping method in TSN is used here instead of the original 161 forwarding method in an IP router, which can make the critical 162 traffic be forwarded orderly instead of as soon as possible. 163 Therefore, micro-bursts can be decreased in the network. 165 If all the forwarding nodes can do their jobs properly, i.e., they 166 can well pace the critical traffic, no or rare micro-bursts for the 167 critical traffic will emerge. In this way, the critical traffic will 168 have a relatively low average latency in the IP network. 170 As no per-flow state is maintained in the forwarding node, the 171 sending rate of the shaper is hard to decide. In this document, the 172 sending rate is suggested to be generated referring to the incoming 173 rate of the queue. The purpose is to maintain a proper buffer depth 174 for the queue. 176 3. IANA Considerations 178 TBD. 180 4. Security Considerations 182 TBD. 184 5. Acknowledgements 186 TBD. 188 6. References 190 6.1. Normative References 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 6.2. Informative References 199 [I-D.qiang-detnet-large-scale-detnet] 200 Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G. 201 Li, "Large-Scale Deterministic IP Network", draft-qiang- 202 detnet-large-scale-detnet-05 (work in progress), September 203 2019. 205 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 206 "Deterministic Networking Architecture", RFC 8655, 207 DOI 10.17487/RFC8655, October 2019, 208 . 210 Authors' Addresses 212 Zongpeng Du 213 China Mobile 214 No.32 XuanWuMen West Street 215 Beijing 100053 216 China 218 Email: duzongpeng@foxmail.com 220 Peng Liu 221 China Mobile 222 No.32 XuanWuMen West Street 223 Beijing 100053 224 China 226 Email: liupengyjy@chinamobile.com 227 Liang Geng 228 China Mobile 229 No.32 XuanWuMen West Street 230 Beijing 100053 231 China 233 Email: gengliang@chinamobile.com