Internet DRAFT - draft-epc-architecture
draft-epc-architecture
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc7426>.
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]
