Network Working Group B. Yan, Ed. Internet-Draft Y. Zhao, Ed. Intended status: Informational W. Wang, Ed. Expires: July 7, 2018 X. Yu, Ed. J. Zhang, Ed. bupt January 3, 2018 An Equipment Parameter Control Architecture draft-epc-architecture-00 Abstract This memo specifies an equipment parameter control architecture based on Software Defined Networking (SDN). This architecture can be used to adjust equipment parameter to improve equipment performance in various types of networks, for example, optical network, wireless network and so on. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Yan, et al. Expires July 7, 2018 [Page 1] Internet-Draft An Equipment Parameter Control Architecture January 2018 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Motivation and Goals . . . . . . . . . . . . . . . . . . . . 3 4.1. Fault Location . . . . . . . . . . . . . . . . . . . . . 4 4.2. Dynamic Parameter Adjustment . . . . . . . . . . . . . . 4 4.3. Fault Prediction . . . . . . . . . . . . . . . . . . . . 4 5. Overview of Equipment Parameter Control Architecture . . . . 4 6. Architectural Considerations of Equipment Parameter Control . 6 6.1. Distributed EPC . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This memo introduce an Software Defined Networking (SDN) based architecture to monitor and analyse physical parameters on various types of network equipments, and control the adjustable parts of parameters. SDN is a programmable networks approach that supports the separation of control and forwarding plane via standardized interfaces, and make equipments foolish while centralizing control function on a logical entity named Controller. The controller can achieve rapid and accurate fault location, dynamic parameter adjustment, fault prediction via this memo. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This memo uses the following terms defined in [RFC7426]: SDN, Service, Interface, Application, Forwarding Plane. This document uses the following terms: Yan, et al. Expires July 7, 2018 [Page 2] Internet-Draft An Equipment Parameter Control Architecture January 2018 Equipment Parameter Controller (EPC): the controller supports functions about equipment parameter control. Controllable Equipment (CE): the equipment supports external physical parameter control by EPC. Physical Parameter Collection Module (PPCM): the module to collect and consolidate physical parameters from multiple equipments in CE. Preprocessing Module (PM): the module to mantain performance database, and manage the state of the CE. Physical Component Monitor (PCM): the monitor which can monitor one or more components at one equipment, and send collected data to Preprocessing module. Computational Core (CC): the logical core which can provide enough computing resource in controller. Decision Core (DC): the logical core which can make decision according to results calculated by computational core. Equipment Parameter Interface (EPI): the interface between EPC and CE. 4. Motivation and Goals The tradictional network architecture is based on overlapping hierarchical model in order to decouple complex set of network functions, and simplify network design, such as seven-layer Open System Interconnection (OSI). Overlapping hierarchical architecture makes under-layer transparent to adjacent upper-layer, so cross-layer collaboration is difficult. SDN is able to do that in network level via openflow, restconf, and other protocols. The collaboration of network level is about network resource allocation, such as traffic grooming in IP-over-WDM network. However, SDN can't handle events happened on equipment-level (foe example, transmission performance improvement), because there is no standard to describe equipment control in detail currently. Equipments are basis of network, whose running status are important to network management. Therefore, it's necessary to standardize the interfaces about running physical parameters between controller and euipments, and the mentioned euipments are not limited to router, switch, OTN, WDM, etc., but including detailed modules in equipments like Erbium Doped Fiber Amplifier (EDFA). There are three advantages mainly to provide euipment parameter control: rapid and accurate fault location, dynamic parameter adjustment, and fault prediction. Yan, et al. Expires July 7, 2018 [Page 3] Internet-Draft An Equipment Parameter Control Architecture January 2018 4.1. Fault Location Fault location is a significant challenge in network operation and maintenance. Currently, fault location is handled by operator, hence depends on experience, which is unstable and unsafe. On the other hand, it is rare for an equipment to encounter a failure. So, there is no enough examples for operators to gather experience effectively. However, if all fault information could be collected by controller, it's possible for controller to dig out relationship between warning logs and fault location. 4.2. Dynamic Parameter Adjustment There are many parameters that can reflect equipment transmission performance, such as bit error rate, packet loss rate, transmission delay, forwarding delay, etc. All these features are decided by the system consisting of power, amplifier, encoder, decoder, and so on. Otherwise, other features related to equipment, for example, temperature and humidity in machine room, also have important influence on equipment performance. It is very hard for vendor to search a formula to describe the relationship between performance and state, and different design of equipment also leed to different association. Based on these, euipment parameter adjustment is a complex problem about systems engineering, that requires huge storage resource to store performance logs and high computing power to analyse logs to seek potential incidence relation. In SDN architecture, network controller is able to use sophisticated analytical models such as machine learning, to handle these logs, and calculate proper model to adjust equipment parameters. 4.3. Fault Prediction Based on those mentioned above, Controller is able to take advantage of high computational resources to optimize those parameters automatically. 5. Overview of Equipment Parameter Control Architecture Yan, et al. Expires July 7, 2018 [Page 4] Internet-Draft An Equipment Parameter Control Architecture January 2018 o--------------------------------------------------------------o | +------------------------+ +------------------------+ | | |Computational Core (CC) |<---->| Policy Core (PC) | | | +----------Y-------------+ +-------------Y------Y---+ | | | +-------------------+ | | | | |------| Dataset Core (DC) |-------| | | | +-------------------+ | | | | | | | *----------------------------Y-----------------------Y-----* | | | Physical Parameter Collection Module (PPCM) | | | *--------------------------Y-------------------------------* | | | | | Equipment Parameter Controller (EPC) | o----------------------------|---------------------------------o | Equipment | Parameter | Interface | (EPI) o----------------------------Y---------------------------------o | | | | *------------------------Y-----------------------------* | | | Preprocessing Module | | | *--------Y------------------------------------Y--------* | | | | | | +--------Y---------+ +---------Y--------+ | | |Physical Component| |Physical Component| | | |Monitor (PCM) | ...... |Monitor (PCM) | | | +------------------+ +------------------+ | | Controllable Equipment (CE) | o--------------------------------------------------------------o Figure 1: Equipment Parameter Control Architecture Equipment Parameter Control Architecture is consisting of two parts: Controllable Equipment (CE) and Equipment Parameter Controller (EPC). CE contains multiple physical component monitor (PCM) to record equipment state fluctuation. All the history and real-time data would be gathered on Preprocessing module. Preprocessing module is a micro-core of equipment, which is responsible for data collection, data filter, data report, and equipment control according to instruction from EPC. EPC is consisting of four parts: Physical Parameter Collection Module (PPCM), Dataset Core (DC), Computational Core (CC), and Policy Core (PC). PPCM is responsible to build connection with CEs through Equipment Parameter Interface (EPI), then read performance data to , and send instructions to control CEs. Yan, et al. Expires July 7, 2018 [Page 5] Internet-Draft An Equipment Parameter Control Architecture January 2018 DC, CC, and PC form a closed cycle. DC is a high-performance storage module, which is responsible to save huge data reported from PPCM, and preprocess it. Preprocessing includes data formatting, data aggregation, data cleaning, data augmentation, and so on. CC is a compute-intensive module to provide computation power (expecially floating-point calculation) for PC. PC is the brain of EPC, which contains an algorithm library about artificial intelligence. PC also contains applications to make decisions to adjust parameters of CEs by using dataset of DC and power of CC. 6. Architectural Considerations of Equipment Parameter Control 6.1. Distributed EPC In a domain or network, the process to massive data that is collected from multiple CEs requires high storage resources for efficient access, and high computation resources for big data analysis. So, there MAY be a cluster of multiple EPCs that coordinate with each other. A CE MAY be linked to a particular EPC, or MAY be able to choose freely among several EPCs in a cluster. 7. Security Considerations 8. Acknowledgments 9. Contributors 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . Authors' Addresses Yan, et al. Expires July 7, 2018 [Page 6] Internet-Draft An Equipment Parameter Control Architecture January 2018 Boyuan Yan (editor) Beijing University of Posts and Telecommunications Xitucheng Road Beijing, Haidian Dist 100876 China Phone: +86-18810528290 Email: yanboyuan@bupt.edu.cn Yongli Zhao (editor) Beijing University of Posts and Telecommunications Xitucheng Road Beijing, Haidian Dist 100876 China Phone: +86-13811761857 Email: yonglizhao@bupt.edu.cn Wei Wang (editor) Beijing University of Posts and Telecommunications Xitucheng Road Beijing, Haidian Dist 100876 China Phone: +86-15210830183 Email: weiw@bupt.edu.cn Xiaosong Yu (editor) Beijing University of Posts and Telecommunications Xitucheng Road Beijing, Haidian Dist 100876 China Phone: +86-13811731723 Email: xiaosongyu@bupt.edu.cn Jie Zhang (editor) Beijing University of Posts and Telecommunications Xitucheng Road Beijing, Haidian Dist 100876 China Phone: +86-13911060930 Email: lgr24@bupt.edu.cn Yan, et al. Expires July 7, 2018 [Page 7]