idnits 2.17.1 draft-li-opsawg-network-ai-arch-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 has text resembling RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Informational Y. Zheng 5 Expires: September 14, 2017 China Unicom 6 J. Zhang 7 S. Xu 8 Huawei Technologies 9 March 13, 2017 11 An Architecture of Network Artificial Intelligence(NAI) 12 draft-li-opsawg-network-ai-arch-00 14 Abstract 16 Artificial intelligence is an important technical trend in the 17 industry. With the development of network, it is necessary to 18 introduce artificial intelligence technology to achieve self- 19 adjustment, self- optimization, self-recovery of the network through 20 collection of huge data of network state and machine learning. This 21 draft defines the architecture of Network Artificial Intelligence 22 (NAI), including the key components and the key protocol extension 23 requirements. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described inRFC 2119 [RFC2119] 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Classification . . . . . . . . . . . . . . . . . . . . . . . 5 70 6. Requirement of Protocol Extensions . . . . . . . . . . . . . 5 71 6.1. Requirement of Southbound Protocols . . . . . . . . . . . 5 72 6.2. Requirement of Data Collection . . . . . . . . . . . . . 6 73 6.3. Requirement of Devices . . . . . . . . . . . . . . . . . 6 74 6.4. Requirement of Northbound Interface . . . . . . . . . . . 6 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Artificial Intelligence is an important technical trend in the 83 industry. The two key aspects of Artificial Intelligence are 84 perception and cognition. Artificial Intelligence has evolved from 85 an early non-learning expert system to a learning-capable machine 86 learning era. In recent years, the rapid development of the deep 87 learning branch based on the neural network and the maturity of the 88 big data technology and software distributed architecture make the 89 Artificial Intelligence in many fields (such as transportation, 90 medical treatment, education, etc.) have been applied. With the 91 development of network, it is necessary to introduce artificial 92 intelligence technology to achieve self-adjustment, self- 93 optimization, self-recovery of the network through collection of huge 94 data of network state and machine learning. The areas of machine 95 learning which are easier to be used in the network field may 96 include: root cause analysis of network failures, network traffic 97 prediction, traffic adjustment and optimization, security defense, 98 security auditing, etc., to implement network perception and 99 cognition. 101 This draft defines the architecture of Network Artificial 102 Intelligence (NAI), including the key components and the key protocol 103 extension requirements. 105 2. Terminology 107 AI: Artificial Intelligence 109 NAI: Network Artificial Intelligence 111 3. Architecture 113 ^ ^ 114 (4)| |(4) 115 +---------------|--------------+ +---------------|--------------+ 116 | Domain 1 | | | | Domain 2 | 117 | +------------+ | | +------------+ | 118 | | Central | | | | Central | | 119 | (1)| Controller |----------------------| Controller |(1) | 120 | | with | | | | with | | 121 | | NTA | | | | NTA | | 122 | +------------+ | | +------------+ | 123 | / \ | | / \ | 124 | (3)/ \ | | / \(3) | 125 | / \ | | / \ | 126 | +--------+ +--------+ | | +--------+ +--------+ | 127 | | | | | | | | | | | | 128 | |Network | ...... |Network | | | |Network | ...... |Network | | 129 | | Device | (2) | Device | | | | Device | (2) | Device | | 130 | | 1 | | N | | | | 1 | | N | | 131 | +--------+ +--------+ | | +--------+ +--------+ | 132 | | | | 133 +------------------------------+ +------------------------------+ 135 Figure 1: An Architecture of Network Artificial Intelligence(NAI) 137 The architecture of Network artificial intelligence includes 138 following key components: 140 (1) Central Controller: Centralized controller is the core part of 141 Network Artificial Intelligence which can be called as 'Network 142 Brain'. The Network Telemetry and Analytics (NTA) engines can be 143 introduced acompanying with the central controller. The Network 144 Telemetry and Analytics (NTA) engine inclues data collector, 145 analytics framework, data persistence, and NAI applications. 147 (2) Network Device: IP network operation and maintenance are always a 148 big challenge since the network can only provide limited state 149 information. The network states includes but are not limited to 150 topology, traffic engineering, operation and maintenance information, 151 network failure information and related information to locate the 152 network failure. In order to provide these information, the network 153 must be able to support more OAM mechanisms to acquire more state 154 information and report to the controller. Then the controller can 155 get the complete state information of the network which is the base 156 of Network Artificial Intelligence(NAI). 158 (3) Southbound Protocol and Models of Controller: As network devices 159 provide huge network state information, it proposes a number of new 160 requirements for protocols and models between controllers and network 161 devices. The traditional southbound protocol such as Netconf and 162 SNMP can not meet the performance requirements. It is necessary to 163 introduce some new high-performance protocols to collect network 164 state data. At the same time, the models of network data should be 165 completed. Moreover with the introduction of new OAM mechanisms of 166 network devices, new models of network data should be introduced. 168 (4) Northbound Model of Controller: The goal of the Network 169 Artificial Intelligence is to reduce the technical requirements on 170 the network administrators and release them from the heavy network 171 management, control, maintenance work. The abstract northbound model 172 of the controller for different network services should be simple and 173 easy to be understood. 175 4. Process 177 NAI consists of following processes: 179 -- Data Collection 181 From the time aspect, data collection can be divided into real-time 182 data collection and non-real-time collection. 184 From the content aspect, data collection can be divided into network 185 information collection (including topology, tunnels, routing, 186 equipment configuration, etc.) and traffic collection (the collection 187 network traffic, network load, device KPI, etc.). 189 -- Data Storage 190 Store data collected from network. Many existing big data storage 191 technologies can be used here. 193 -- Data Processing 195 This is preliminary data processing too select effective data and 196 simply analyse data relationship. 198 -- Analyse 200 Analyse engine will provide the data analysis results using machine 201 learning algorithm. 203 -- Closed Loop Control 205 According to the results of intelligent analysis and policy set by 206 user, the centrol controller will implement closed-loop control of 207 the network. 209 5. Classification 211 NAI can be divided into off-line process and on-line process in 212 accordance to the time aspect of the data collection and analysis. 214 Off-line process refers to process of the existing data, or non-real- 215 time collection data. Although the analysis process will also focus 216 on the relationship between data and time, but it does not require 217 real-time analysis. Off-line process is mainly used for two 218 purposes: (1) training or verification of real-time process design; 219 (2) trouble shooting or reason analysis for events that have already 220 occurred. 222 On-line process is efficient real-time collection, processing and 223 analysis of the data, to operate network monitoring and event 224 forecasting. The main purpose of the on-line process are: (1) 225 network capacity monitoring and precise optimizing; (2) network event 226 prediction and fast trouble shooting; (3) real-time network 227 optimization according to the policy. 229 6. Requirement of Protocol Extensions 231 6.1. Requirement of Southbound Protocols 233 REQ 01: The southbound protocol of the controller should be 234 introduced to meet the performance requirements of collecting huge 235 data of network states. 237 The soundbound protocol can be based on the extensions of the 238 existing traditional protocols such link state colloction protocols, 239 PCEP[RFC5440], BMP[RFC7854], etc. Or the new protocol like 240 Telemetry[I-D.kumar-rtgwg-grpc-protocol] can be introduced as the 241 soundbound protocols. The protocol choice will be based on the 242 application scenarios of NAI. 244 6.2. Requirement of Data Collection 246 REQ 02: The data collected from the network devices includes but not 247 limites to following information: 249 -- network topology information 251 -- routing protocol status 253 -- IP routes and MAC routes 255 -- LSP information 257 -- network traffic inforamtion 259 -- network configuration 261 -- network device KPIs 263 -- log of network elements 265 -- trap of network elements 267 -- OAM information 269 6.3. Requirement of Devices 271 REQ 03: New OAM mechanisms should be introduced for the network 272 devices in order to acquire more types of network state data. 274 6.4. Requirement of Northbound Interface 276 REQ 04: The abstract network-based service models should be provided 277 by the controller as the northbound models to satisfy the 278 requirements of different services. 280 7. IANA Considerations 282 This document makes no request of IANA. 284 8. Security Considerations 286 TBD. 288 9. Normative References 290 [I-D.kumar-rtgwg-grpc-protocol] 291 Kumar, A., Kolhe, J., Ghemawat, S., and L. Ryan, "gRPC 292 Protocol", draft-kumar-rtgwg-grpc-protocol-00 (work in 293 progress), July 2016. 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 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 301 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 302 DOI 10.17487/RFC5440, March 2009, 303 . 305 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 306 Monitoring Protocol (BMP)", RFC 7854, 307 DOI 10.17487/RFC7854, June 2016, 308 . 310 Authors' Addresses 312 Zhenbin Li 313 Huawei Technologies 314 Huawei Bld., No.156 Beiqing Rd. 315 Beijing 100095 316 China 318 Email: lizhenbin@huawei.com 320 Yi Zheng 321 China Unicom 322 No.9, Shouti Nanlu, Haidian District 323 Beijing 100048 324 China 326 Email: zhengyi39@chinaunicom.cn 327 Jinhui Zhang 328 Huawei Technologies 329 Huawei Bld., No.156 Beiqing Rd. 330 Beijing 100095 331 China 333 Email: jason.zhangjinhui@huawei.com 335 Xu Shiping 336 Huawei Technologies 337 Huawei Bld., No.156 Beiqing Rd. 338 Beijing 100095 339 P.R. China 341 Email: xushiping7@huawei.com