idnits 2.17.1 draft-li-rtgwg-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 (October 31, 2016) is 2731 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 J. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: May 4, 2017 October 31, 2016 7 An Architecture of Network Artificial Intelligence(NAI) 8 draft-li-rtgwg-network-ai-arch-00 10 Abstract 12 Artificial intelligence is an important technical trend in the 13 industry. With the development of network, it is necessary to 14 introduce artificial intelligence technology to achieve self- 15 adjustment, self- optimization, self-recovery of the network through 16 collection of huge data of network state and machine learning. This 17 draft defines the architecture of Network Artificial Intelligence 18 (NAI), including the key components and the key protocol extension 19 requirements. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described inRFC 2119 [RFC2119] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 4, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Requirement of Protocol Extensions . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 Artificial Intelligence is an important technical trend in the 74 industry. The two key aspects of Artificial Intelligence are 75 perception and cognition. Artificial Intelligence has evolved from 76 an early non-learning expert system to a learning-capable machine 77 learning era. In recent years, the rapid development of the deep 78 learning branch based on the neural network and the maturity of the 79 big data technology and software distributed architecture make the 80 Artificial Intelligence in many fields (such as transportation, 81 medical treatment, education, etc.) have been applied. With the 82 development of network, it is necessary to introduce artificial 83 intelligence technology to achieve self-adjustment, self- 84 optimization, self-recovery of the network through collection of huge 85 data of network state and machine learning. The areas of machine 86 learning which are easier to be used in the network field may 87 include: troubleshooting of network problems, network traffic 88 prediction, traffic optimization adjustment, security defense, 89 security auditing, etc., to implement network perception and 90 cognition. 92 This draft defines the architecture of Network Artificial 93 Intelligence (NAI), including the key components and the key protocol 94 extension requirements. 96 2. Terminology 98 AI: Artificial Intelligence 100 NAI: Network Artificial Intelligence 102 3. Architecture 104 3.1. Reference Model 106 +------------------------------+ +------------------------------+ 107 | Domain 1 | | Domain 2 | 108 | +------------+ | | +------------+ | 109 | | Central | | | | Central | | 110 | | Controller |----------------------| Controller | | 111 | | | | | | | | 112 | | | | | | | | 113 | +------------+ | | +------------+ | 114 | / \ | | / \ | 115 | / \ | | / \ | 116 | / \ | | / \ | 117 | +--------+ +--------+ | | +--------+ +--------+ | 118 | | | | | | | | | | | | 119 | |Network | ...... |Network | | | |Network | ...... |Network | | 120 | | Device | | Device | | | | Device | | Device | | 121 | | 1 | | N | | | | 1 | | N | | 122 | +--------+ +--------+ | | +--------+ +--------+ | 123 | | | | 124 +------------------------------+ +------------------------------+ 126 Figure 1: An Architecture of Network Artificial Intelligence(NAI) 128 The architecture of Network artificial intelligence includes 129 following key component: 131 1. Central Controller: Centralized controller is the core component 132 of Network Artificial Intelligence which can be called as 'Network 133 Brain'. It man collect huge data of network states, store the data 134 based on the big data platform, and carry on the machine learning, to 135 achieve network perception and cognition, including network self- 136 optimization, self- adjustment, self-recovery, intelligent fault 137 location and a series of network artificial intelligence goals. 139 2. Network Device: IP network operation and maintenance are always a 140 big challenge since the network can only provide limited state 141 information. The network states includes but are not limited to 142 topology, traffic engineering, operation and maintenance information, 143 network failure information and related information to locate the 144 network failure.. In order to provide these information, the network 145 must be able to support more OAM mechanisms to acquire more state 146 information and report to the controller. Then the controller can 147 get the complete state information of the network which is the base 148 of Network Artificial Intelligence(NAI). 150 3. Southbound Protocol and Models of Controller: As network devices 151 provide huge network state information, it proposes a number of new 152 requirements for protocols and models between controllers and network 153 devices. The traditional southbound protocol such as Netconf and 154 SNMP can not meet the performance requirements. It is necessary to 155 introduce some new high-performance protocols to collect network 156 state data. At the same time, the models of network data should be 157 completed. Moreover with the introduction of new OAM mechanisms of 158 network devices, new models of network data should be introduced. 160 4. Northbound Model of Controller: The goal of the Network 161 Artificial Intelligence is to reduce the technical requirements on 162 the network administrators and release them from the heavy network 163 management, control, maintenance work. The abstract northbound model 164 of the controller for different network services should be simple and 165 easy to be understood. 167 3.2. Requirement of Protocol Extensions 169 REQ 01: The new southbound protocol of the controller should be 170 introduced to meet the performance requirements of collecting huge 171 data of network states. 173 REQ 02: The models of network elements should be completed to collect 174 the network states based on the new southbound protocol of the 175 controller. 177 REQ 03: New OAM mechanisms should be introduced for the network 178 devices in order to acquire more types of network state data. 180 REQ 04: New models of network elements should be introduced as the 181 new OAM mechanisms are introduced. 183 REQ 05: The operation models of network elements should be completed 184 based on the new southbound protocol to carry on the corresponding 185 network operation as the result of Network Artificial Intelligence. 187 REQ 06: The abstract network-based service models should be provided 188 by the controller as the northbound models to satisfy the 189 requirements of different services. 191 4. IANA Considerations 193 This document makes no request of IANA. 195 5. Security Considerations 197 TBD. 199 6. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 Authors' Addresses 208 Zhenbin Li 209 Huawei Technologies 210 Huawei Bld., No.156 Beiqing Rd. 211 Beijing 100095 212 China 214 Email: lizhenbin@huawei.com 216 Jinhui Zhang 217 Huawei Technologies 218 Huawei Bld., No.156 Beiqing Rd. 219 Beijing 100095 220 China 222 Email: jason.zhangjinhui@huawei.com