idnits 2.17.1 draft-liu-ican-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2019) is 1753 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) == Unused Reference: 'RFC2119' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 333, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-03) exists of draft-dang-ippm-congestion-01 == Outdated reference: A later version (-05) exists of draft-dang-ippm-multiple-path-measurement-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track July 8, 2019 5 Expires: January 9, 2020 7 Instant Congestion Assessment Network (iCAN) for Data Plane Traffic 8 Engineering 9 draft-liu-ican-00 11 Abstract 13 iCAN (instant Congestion Assessment Network) is a set of mechanisms 14 running directly on network nodes: 16 o To adjust the flows paths based on real-time measurement of the 17 candidate paths. 19 o The measurement is to reflect the congestion situation of each 20 path, so that the ingress nodes could decide which flows need to 21 be switched from a path to another. 23 This is something that current SDN and TE technologies can hardly 24 achieve: 26 o SDN Controller is slow and far from the data plane, it is neither 27 able to assess the real-time congestion situation of each path, 28 nor able to assure the data plane always go as expected 29 (especially in SRv6 scenarios). However, iCAN can work with SDN 30 perfectly: controller planning multi-path transmission, and iCAN 31 does the flow optimization automatically. 33 o Traditional TE is not able to adjust the flow paths in real-time. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. iCAN Architecture and Key Technical Requirements . . . . . . 3 70 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 3 71 2.2. Key technical requirements . . . . . . . . . . . . . . . 5 72 2.2.1. Path quality assessment . . . . . . . . . . . . . . . 5 73 2.2.2. Recognition and statistic of flows in devices . . . . 5 74 2.2.3. Flow switching between paths . . . . . . . . . . . . 5 75 3. Use Cases of iCAN . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Network load balancing . . . . . . . . . . . . . . . . . 6 77 3.2. SLA assurance . . . . . . . . . . . . . . . . . . . . . . 6 78 3.3. Fine-Granularity reliability . . . . . . . . . . . . . . 6 79 4. Implementation Scenarios . . . . . . . . . . . . . . . . . . 6 80 4.1. iCAN with SRv6 . . . . . . . . . . . . . . . . . . . . . 6 81 4.2. iCAN with VxLAN . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. iCAN with MPLS/MPLS-TE . . . . . . . . . . . . . . . . . 7 83 5. Standardization Requirements . . . . . . . . . . . . . . . . 7 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 89 9.2. Informative References . . . . . . . . . . . . . . . . . 8 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Introduction 94 Traditional IP routing is shortest path based on static metrics, 95 which can fulfil basic requirement of connectivity. MPLS-TE brings 96 the capability of utilizing non-shortest paths, thus traffic dispatch 97 is doable; however, MPLS-TE in only a complementary mechanism because 98 of the scalability issue. Segment routing provides even more 99 flexibility that paths could be easily programmed; and along with the 100 controller, it could be scaled. 102 However, the above mentioned mechanism all run in the control plane, 103 which implies that they are not able to sense the data plane 104 situation in real-time, thus they are mostly for relative static 105 planning/controlling (minuets, hours or even day-level) of network 106 traffic and not able to adapt to the microscopic traffic change in 107 real-time (e.g. mili-second level). So, in real bearer networks 108 (metro, backbones etc.), it is always underload so that the redundant 109 resources could tolerant the traffic burst, results in a significant 110 waste of network resources. 112 This draft proposes the iCAN (Instant Congestion Assessment Network) 113 architecture to achieve autonomous adapt to traffic changes in real- 114 time in terms of switching flows between multiple forwarding paths. 115 iCAN includes following things: 117 o A mechanism between ingress and egress nodes to assess the path 118 congestion situation in RTT level speed, to recognize which paths 119 are underload and which are heavy loaded. 121 o Recognizing big flows and small flows in the device, in real time 123 o Ingress node dispatches flows to multiple paths, to make load 124 balance, or to guarantee SLA for specific flows 126 This draft also discusses use cases and implementation scenarios of 127 iCAN. 129 2. iCAN Architecture and Key Technical Requirements 131 2.1. Architecture 132 +-----------+ 133 | | 134 | Controller| 135 | | 136 +-----------+ 137 | 138 0.Multi-path | 139 Planning | 140 | 141 | 142 v 143 +-----------+ --------Path 1------------ +----------+ 144 Imcoming Flows | Ingress |3.Flow swithing between paths | Egress | 145 --------------> | Router | --------Path N------------ | Router | 146 | | | | 147 +-/------\--+ <--------------------------> +----------+ 148 / \ 1.Path Quality Assessment 149 / 2. Flow \ (simultaneusly on multiple paths) 150 / recognition 151 / \ 153 As above figure shows, there are 3 entities: 155 1. Controller 157 - Responsible for planning multiple paths for a set of flows 158 that could be aggregated to a pair of Ingress/Egress routers. 160 - After delivering the planned paths to the ingress router, the 161 controller would need nothing to do. 163 2. Ingress router: 165 - Serves as a local "controller" for the iCAN system. 167 - Responsible for triggering the path congestion assessment, 168 which is coordinated with the egress router through a 169 measurement protocol. 171 - After getting the assessment results, the ingress router would 172 calculate which flows need to be switched to a different path, 173 in order to make the paths load balanced or to assure the 174 transport quality of a certain of important flows. 176 - In order to do the path switching calculation, the ingress 177 router needs to recognize the TopN flow passing by it, since 178 switching the big flows would make the most effort. 180 3. Egress router: 182 - Only needs to coordinate with the ingress router to do the 183 path assessment. 185 2.2. Key technical requirements 187 2.2.1. Path quality assessment 189 o Req-1: the assessment MUST reflex the congestion status of the 190 paths. (Note: a candidate congestion metric is proposed as: 191 [I-D.dang-ippm-congestion].) 193 o Req-2: the assessment SHOULD be done within a RTT timeslot. Since 194 iCAN is to adapt the traffic change in real-time, the assessment 195 needs to be done very fast. 197 o Req-3: the assessment MUST be done for multiple paths between the 198 same ingress/egress routes simultaneously. (Note: a candidate 199 congestion metric is proposed as: 200 [I-D.dang-ippm-multiple-path-measurement].) 202 2.2.2. Recognition and statistic of flows in devices 204 o Req-1: the device SHOULD be able to recognize TopN big flows 205 within a timeslot. 207 o Req-2: the device MAY need to statistic all flows' amount within a 208 timeslot. 210 2.2.3. Flow switching between paths 212 o Req-1: the device SHOULD be able to recognize flow let. The flow 213 switching is done from the next flow let. 215 o Req-2: the device MAY need to actively generate gap to 216 artificially create flow let. If the flow needs to be switched 217 immediately, then the device would need to make the gap, to avoid 218 out-of-order packets arriving to the destination through multiple 219 paths. 221 o Req-3: the device SHOULD avoid oscillation of frequently switching 222 flows from one to another. 224 o Req-4: multiple ingress devices SHOULD be able to coordinate so 225 that they won't switch flows to the shared path at the same time, 226 to avoid potential congestion in the shared path. 228 3. Use Cases of iCAN 230 3.1. Network load balancing 232 Background problem: traffic is not balanced in current metro network. 234 While some links are heavily loaded, others might be still lightly 235 loaded: unbalance could lows down the service quality (e.g. SLA 236 could not be guaranteed in the heavily loaded links/paths); unbalance 237 could lows down the network utilization ratio (normally with 30%, 238 e.g. a 100G physical capacity network can only bear at most 30G 239 traffic, a huge waste of network infrastructure). 241 iCAN could be used for load balance among the multiple paths between 242 a pair of ingress/egress nodes. Once the network is balanced, the 243 real throughput of the network could be elevated significantly. 245 3.2. SLA assurance 247 Since iCAN could switch flow in real-time, it can guarantee a set of 248 important flows. Once the path which carries the important flows is 249 to be congested, the other flows could be switched to alternative 250 paths, and the important flows would stablely running in the original 251 path. 253 (More content TBD) 255 3.3. Fine-Granularity reliability 257 Traditional reliability protocols such as BFD, can only assess the 258 link on or off. With the path congestion assessment ability, iCAN 259 could also asses the quality degradation. 261 (More content TBD) 263 4. Implementation Scenarios 265 4.1. iCAN with SRv6 267 - SR Multiple Explicit Paths 269 For example, there are 3 paths between the ingress and egress 270 nodes, and the multi-path is defined as a SR-List containing 271 LSP1/2/3. 273 The probe message detects the congestion status of the three SR- 274 list paths. The edge device adjusts the load balancing between 275 the three paths according to the congestion status of the three 276 SR-lists, and switch the flows from the path with a high 277 congestion to the path with a low congestion. 279 - SR Multiple Explicit+Loose Paths 281 In loose path scenario, there needs to be an additional approach 282 to probe the specific paths of a SR tunnel. After that, 283 operations on the probed paths are the same as explicit path 284 scenario. 286 4.2. iCAN with VxLAN 288 TBD. 290 4.3. iCAN with MPLS/MPLS-TE 292 TBD. 294 5. Standardization Requirements 296 1. Multi-path Planning (North Interface between Controller and 297 devices) 299 2. Path Congestion Assesment (Horizontal Interface between devices), 300 mostly regarding to Req-1&2&3 described in Section 2.2.1 . 302 3. Flow Switching Negotiation (Horizontal Interface between 303 devices), mostly regarding to Req-3&4 described in Section 2.2.3 304 . 306 (More content TBD.) 308 6. Security Considerations 310 TBD. 312 7. IANA Considerations 314 TBD. 316 8. Acknowledgements 318 Very valuable comments were from Shunsuke Homma, Mikael Abrahamsson 319 and Bruno Decraene. 321 A commercial router hardware based prototype had been implemented to 322 prove the machinisms discussed in the document are workable. 324 9. References 326 9.1. Normative References 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 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 334 DOI 10.17487/RFC2629, June 1999, 335 . 337 9.2. Informative References 339 [I-D.dang-ippm-congestion] 340 Dang, J. and J. Wang, "A One-Path Congestion Metric for 341 IPPM", draft-dang-ippm-congestion-01 (work in progress), 342 March 2019. 344 [I-D.dang-ippm-multiple-path-measurement] 345 Dang, J. and J. Wang, "A Multi-Path Concurrent Measurement 346 Protocol for IPPM", draft-dang-ippm-multiple-path- 347 measurement-01 (work in progress), March 2019. 349 Author's Address 351 Bing Liu 352 Huawei Technologies 353 Q14, Huawei Campus 354 No.156 Beiqing Road 355 Hai-Dian District, Beijing 100095 356 P.R. China 358 Email: leo.liubing@huawei.com