idnits 2.17.1 draft-epc-architecture-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 3, 2018) is 2305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Yan, Ed. 3 Internet-Draft Y. Zhao, Ed. 4 Intended status: Informational W. Wang, Ed. 5 Expires: July 7, 2018 X. Yu, Ed. 6 J. Zhang, Ed. 7 bupt 8 January 3, 2018 10 An Equipment Parameter Control Architecture 11 draft-epc-architecture-00 13 Abstract 15 This memo specifies an equipment parameter control architecture based 16 on Software Defined Networking (SDN). This architecture can be used 17 to adjust equipment parameter to improve equipment performance in 18 various types of networks, for example, optical network, wireless 19 network and so on. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 4. Motivation and Goals . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Fault Location . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Dynamic Parameter Adjustment . . . . . . . . . . . . . . 4 61 4.3. Fault Prediction . . . . . . . . . . . . . . . . . . . . 4 62 5. Overview of Equipment Parameter Control Architecture . . . . 4 63 6. Architectural Considerations of Equipment Parameter Control . 6 64 6.1. Distributed EPC . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 This memo introduce an Software Defined Networking (SDN) based 74 architecture to monitor and analyse physical parameters on various 75 types of network equipments, and control the adjustable parts of 76 parameters. SDN is a programmable networks approach that supports 77 the separation of control and forwarding plane via standardized 78 interfaces, and make equipments foolish while centralizing control 79 function on a logical entity named Controller. The controller can 80 achieve rapid and accurate fault location, dynamic parameter 81 adjustment, fault prediction via this memo. 83 2. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Terminology 91 This memo uses the following terms defined in [RFC7426]: SDN, 92 Service, Interface, Application, Forwarding Plane. 94 This document uses the following terms: 96 Equipment Parameter Controller (EPC): the controller supports 97 functions about equipment parameter control. 99 Controllable Equipment (CE): the equipment supports external physical 100 parameter control by EPC. 102 Physical Parameter Collection Module (PPCM): the module to collect 103 and consolidate physical parameters from multiple equipments in CE. 105 Preprocessing Module (PM): the module to mantain performance 106 database, and manage the state of the CE. 108 Physical Component Monitor (PCM): the monitor which can monitor one 109 or more components at one equipment, and send collected data to 110 Preprocessing module. 112 Computational Core (CC): the logical core which can provide enough 113 computing resource in controller. 115 Decision Core (DC): the logical core which can make decision 116 according to results calculated by computational core. 118 Equipment Parameter Interface (EPI): the interface between EPC and 119 CE. 121 4. Motivation and Goals 123 The tradictional network architecture is based on overlapping 124 hierarchical model in order to decouple complex set of network 125 functions, and simplify network design, such as seven-layer Open 126 System Interconnection (OSI). Overlapping hierarchical architecture 127 makes under-layer transparent to adjacent upper-layer, so cross-layer 128 collaboration is difficult. SDN is able to do that in network level 129 via openflow, restconf, and other protocols. The collaboration of 130 network level is about network resource allocation, such as traffic 131 grooming in IP-over-WDM network. However, SDN can't handle events 132 happened on equipment-level (foe example, transmission performance 133 improvement), because there is no standard to describe equipment 134 control in detail currently. Equipments are basis of network, whose 135 running status are important to network management. Therefore, it's 136 necessary to standardize the interfaces about running physical 137 parameters between controller and euipments, and the mentioned 138 euipments are not limited to router, switch, OTN, WDM, etc., but 139 including detailed modules in equipments like Erbium Doped Fiber 140 Amplifier (EDFA). There are three advantages mainly to provide 141 euipment parameter control: rapid and accurate fault location, 142 dynamic parameter adjustment, and fault prediction. 144 4.1. Fault Location 146 Fault location is a significant challenge in network operation and 147 maintenance. Currently, fault location is handled by operator, hence 148 depends on experience, which is unstable and unsafe. On the other 149 hand, it is rare for an equipment to encounter a failure. So, there 150 is no enough examples for operators to gather experience effectively. 152 However, if all fault information could be collected by controller, 153 it's possible for controller to dig out relationship between warning 154 logs and fault location. 156 4.2. Dynamic Parameter Adjustment 158 There are many parameters that can reflect equipment transmission 159 performance, such as bit error rate, packet loss rate, transmission 160 delay, forwarding delay, etc. All these features are decided by the 161 system consisting of power, amplifier, encoder, decoder, and so on. 162 Otherwise, other features related to equipment, for example, 163 temperature and humidity in machine room, also have important 164 influence on equipment performance. It is very hard for vendor to 165 search a formula to describe the relationship between performance and 166 state, and different design of equipment also leed to different 167 association. 169 Based on these, euipment parameter adjustment is a complex problem 170 about systems engineering, that requires huge storage resource to 171 store performance logs and high computing power to analyse logs to 172 seek potential incidence relation. In SDN architecture, network 173 controller is able to use sophisticated analytical models such as 174 machine learning, to handle these logs, and calculate proper model to 175 adjust equipment parameters. 177 4.3. Fault Prediction 179 Based on those mentioned above, Controller is able to take advantage 180 of high computational resources to optimize those parameters 181 automatically. 183 5. Overview of Equipment Parameter Control Architecture 184 o--------------------------------------------------------------o 185 | +------------------------+ +------------------------+ | 186 | |Computational Core (CC) |<---->| Policy Core (PC) | | 187 | +----------Y-------------+ +-------------Y------Y---+ | 188 | | +-------------------+ | | | 189 | |------| Dataset Core (DC) |-------| | | 190 | +-------------------+ | | 191 | | | | 192 | *----------------------------Y-----------------------Y-----* | 193 | | Physical Parameter Collection Module (PPCM) | | 194 | *--------------------------Y-------------------------------* | 195 | | | 196 | Equipment Parameter Controller (EPC) | 197 o----------------------------|---------------------------------o 198 | Equipment 199 | Parameter 200 | Interface 201 | (EPI) 202 o----------------------------Y---------------------------------o 203 | | | 204 | *------------------------Y-----------------------------* | 205 | | Preprocessing Module | | 206 | *--------Y------------------------------------Y--------* | 207 | | | | 208 | +--------Y---------+ +---------Y--------+ | 209 | |Physical Component| |Physical Component| | 210 | |Monitor (PCM) | ...... |Monitor (PCM) | | 211 | +------------------+ +------------------+ | 212 | Controllable Equipment (CE) | 213 o--------------------------------------------------------------o 215 Figure 1: Equipment Parameter Control Architecture 217 Equipment Parameter Control Architecture is consisting of two parts: 218 Controllable Equipment (CE) and Equipment Parameter Controller (EPC). 219 CE contains multiple physical component monitor (PCM) to record 220 equipment state fluctuation. All the history and real-time data 221 would be gathered on Preprocessing module. Preprocessing module is a 222 micro-core of equipment, which is responsible for data collection, 223 data filter, data report, and equipment control according to 224 instruction from EPC. 226 EPC is consisting of four parts: Physical Parameter Collection Module 227 (PPCM), Dataset Core (DC), Computational Core (CC), and Policy Core 228 (PC). PPCM is responsible to build connection with CEs through 229 Equipment Parameter Interface (EPI), then read performance data to , 230 and send instructions to control CEs. 232 DC, CC, and PC form a closed cycle. DC is a high-performance storage 233 module, which is responsible to save huge data reported from PPCM, 234 and preprocess it. Preprocessing includes data formatting, data 235 aggregation, data cleaning, data augmentation, and so on. CC is a 236 compute-intensive module to provide computation power (expecially 237 floating-point calculation) for PC. PC is the brain of EPC, which 238 contains an algorithm library about artificial intelligence. PC also 239 contains applications to make decisions to adjust parameters of CEs 240 by using dataset of DC and power of CC. 242 6. Architectural Considerations of Equipment Parameter Control 244 6.1. Distributed EPC 246 In a domain or network, the process to massive data that is collected 247 from multiple CEs requires high storage resources for efficient 248 access, and high computation resources for big data analysis. So, 249 there MAY be a cluster of multiple EPCs that coordinate with each 250 other. A CE MAY be linked to a particular EPC, or MAY be able to 251 choose freely among several EPCs in a cluster. 253 7. Security Considerations 255 8. Acknowledgments 257 9. Contributors 259 10. Normative References 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 267 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 268 Defined Networking (SDN): Layers and Architecture 269 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 270 2015, . 272 Authors' Addresses 273 Boyuan Yan (editor) 274 Beijing University of Posts and Telecommunications 275 Xitucheng Road 276 Beijing, Haidian Dist 100876 277 China 279 Phone: +86-18810528290 280 Email: yanboyuan@bupt.edu.cn 282 Yongli Zhao (editor) 283 Beijing University of Posts and Telecommunications 284 Xitucheng Road 285 Beijing, Haidian Dist 100876 286 China 288 Phone: +86-13811761857 289 Email: yonglizhao@bupt.edu.cn 291 Wei Wang (editor) 292 Beijing University of Posts and Telecommunications 293 Xitucheng Road 294 Beijing, Haidian Dist 100876 295 China 297 Phone: +86-15210830183 298 Email: weiw@bupt.edu.cn 300 Xiaosong Yu (editor) 301 Beijing University of Posts and Telecommunications 302 Xitucheng Road 303 Beijing, Haidian Dist 100876 304 China 306 Phone: +86-13811731723 307 Email: xiaosongyu@bupt.edu.cn 309 Jie Zhang (editor) 310 Beijing University of Posts and Telecommunications 311 Xitucheng Road 312 Beijing, Haidian Dist 100876 313 China 315 Phone: +86-13911060930 316 Email: lgr24@bupt.edu.cn