Transcript Dr. Ranganai Chaparadza - EU

The need for Research Projects to adopt emerging
Standards and contribute to Standards for
Autonomic Future Internet
ECIAO Workshop (Co-located with EWSDN 2014, Budapest) : AUTONOMIC FUTURE INTERNET STANDARDIZATION
AND SDN, NFV & IPv6 IMPACTS WORKSHOP
Unified Standards for Autonomic Management & Control (AMC) of Networks and Services, SDN, and NFV, as
complementary emerging paradigms,
and Bridging Research and Standardization Activities
ETSI/NTECH/AFI (Autonomic Future Internet) GANA Autonomic Management & Control
(AMC) Reference Model and its integration with SDN and NFV Reference Models
Dr. Ranganai Chaparadza: IPv6 Forum representantive in ETSI AFI; Chair of the Industry
Harmonization for Unified Standards Initiative and IEEE Globecom Industry Forum Sessions Chair,
Dr. Tayeb Ben Meriem (Orange): ETSI NTECH/AFI Rapporteur & acting Chair
Time
Research Projects conduct basic
research on specific new technologies
e.g. AMC, SDN, NFV, Future Internet
Further research activities on: the new
technologies and large-scale
experimentation.
Pre-Standardization on Architectural
Frameworks (inc. Reference Models),
Concepts, Models, etc.
Standardized Architectural
Frameworks, Concepts and Models,
but on individual Networking
Paradigms in Silos, e.g. for AMC
(Autonomics), SDN, NFV, etc
Standardized Unified/Harmonized
Frameworks, Concepts and Models
that combine multiple Networking
Paradigms
1.
-
2. The type of research at this stage then does not need to
create new architectures but can focus on innovation and
algorithms research based on the adopted standards (as
commonly-shared frameworks with the industry)
Autonomic Management & Control (AMC) and
Automated Management of Networks and Services
*Definition: Autonomic Management & Control (AMC) of Networks and Services:
“Autonomic Network Management & Control (includes the notion of Autonomic
Networking)” can be expressed in the following way:
AMC = Autonomics in the Management Plane + Autonomics in the Control Plane
(whether distributed or centralized)
AMC is about Autonomics (i.e. control-loops) introduced in the Management Plane as
well as Autonomics (i.e. control-loops) introduced in the Control Plane (whether the
control-plane is distributed or centralized). A control-loop realizes self-* features
(self-configuration, self-optimization, etc).
Autonomic Management (Control-Loops, with Learning and Reasoning to effect
adaptation) can be contrasted to
Automated Management (workflow reduction and automation i.e. automation of the
processes involved in the creation of network configuration input using specialized
Task Automation Tools, e.g. Scripts, network planning tools, policy generators for
conflict-free policies)
Autonomic Management & Control (AMC) and
Automated Management of Networks and Services
“Control” in AMC is about:
•
“Control Logic(s)” that realize a control-loop in order to dynamically adapt
network resources and parameters or services.
•
The control-logics, as a software or a behavior specification, may be loaded or
replaced in nodes and network  Notion of Software-Driven Networks or
Software-Empowered Networks
•
From an architecture perspective, a control-loop can be based on
•
a “d t ut d mod ” (for fast control-loops). That means, the logic is embedded in the nodes
(Physical or Virtualized).
•
Whereas, a “c nt z d mod ” (for slow control-loops), the logic is embedded (implemented)
outside of the node.
 Both kinds of control-loops act towards a global goal to ensure a stable
state of the network.
•
A control-logic can negotiate with another control-logic, to realize dynamic
adaptation of network resources and parameters, or services, via reference points.
AFI Liaisons with diverse Groups in SDOs and Fora
AFI and Broadband Forum (BBF): Autonomicity and Self-Management in BBF Architecture
AFI and 3GPP: Autonomicity and Self-Management Functions in the Backhaul and Core Networks
to complement SON in the RAN and also their global synchronization with SON
AFI and NGMN: NGCOR Requirements calling for Autonomics-Awareness in the Management
Architecture. Autonomics-awareness is also in NGMN 5G initiative
AFI in Multi-SDO Initiative: AFI to specify Autonomics and Self-Management for various NGCOR
Use Cases and the Converged Management of Fixed and Mobile Networks
AFI and TMF (liaison is going to be established on evolution of Information & Data Models as
impacted by Autonomics and Self-Management)
AFI and ITU-T SG13: Autonomic Management and Control in FN Architecture and in NGN
AFI and ITU-T SG2, SG15 and : Autonomic Management and Control in NGN and other
Architectures, including Network Resilience, Autonomic Fault Management and Recovery
AFI and CAC in the USA and also with NIST: CAC and AFI have regular exchange of invitations and
information including invitation to events)
AFI and IEEE (Liaison envisaged, contacts have been established )
AFI and OMG SDN WG (contacts established and a Liaison is to be established )
AFI and NMRG (This Liaison/collaboration can also be formalized like the other Liaisons)
5
The GANA Reference Model for
Autonomic Networking, Cognitive
Networking and Self-Management,
i.e. Reference Model for AMC
© ETSI 2014. All rights reserved
AFI GANA Reference Model, and Modularization of logically
centralized Control Software (GANA Knowledge Plane)
•
•
•
Decision Elements (DEs) = Centralized and Distributed Control Software Logics (DEs) that operate
in different time-scales but interworking harmoniously in realizing autonomic behaviors
DE algorithms imply DE vendor differentiation.
DEs MAY be “loaded or replaced”  notion of “Software-Driven or Software-Empowered Networks”
i.e. the broader picture than Software-Defined Networks
MBTS: Model-Based-Translation Service
ONIX :Overlay Network for Information eXchange
3-Levels of Hierarchical ControlLoops demonstrate how
Autonomics can be introduced
in architectures.
Network
Governance
Interface
Hierarchy of Decision
Elements (DEs)
Knowledge Plane
ONIX
MBTS
Network Level Routing Management DE
Network Level Fault Management DE
Other Network Level DEs
e.g. Network Level QoS Management DE
GANA
Profile
Network Level DEs
(GANA Level-4)
Administrator/Network
Operator
“Fast Control-Loops” in the
Nodes/NEs, while “Slow but
network-wide Control-Loops“
should operate in the outer
centralized GANA Knowledge
Network Element (NE)
Plane (i.e. SDN – Controller & NetApps realm)
Managed Entities (MEs)/
Resources, i.e. Protocols, Stacks &
Mechanisms, and Applications
Vertical
Reference
Point
Outer Control Loop
NE (router, terminal, switch,
gateway, base-station, etc.)
NE (router, host, switch,
gateway, base-station, etc.)
Node_Main_DE
Node_Main_DE
Function-Level DE, e.g. QoS
Management DE
Function-Level DE, e.g. QoS
Management DE
Function Level DEs
(GANA Level-2)
Managed Entities (MEs)
Managed Entities (MEs)
(partitioned and assigned
to specific upper DEs)
(partitioned and assigned
to specific upper DEs)
Protocol Level DEs
(GANA Level-1)
Horizontal
Reference
Point
Node Level DEs
(GANA Level-3)
Impact of SDN on GANA Knowledge Plane
Proposal on integrating GANA Knowledge Plane DEs with SDN Controllers,
to enable Autonomcity (Approach 1)
(1) GANA Knowledge Plane DEs as second party logic with algorithms that drive an SDN Controller
via the API  Using the same Northbound API as Network Application
© ETSI 2011. All rights reserved
Impact of SDN on GANA Knowledge Plane
Proposal on integrating GANA Knowledge Plane DEs with SDN Controllers,
to enable Autonomcity (Approach 2)
(2) GANA Knowledge Plane DEs as Modules of an SDN Controller
Note: GANA also incorporates concepts
from the 4D architecture upon which
OpenFlow was founded (see in AFI
GANA Spec)
© ETSI 2014. All rights reserved
GANA Knowledge Plane DEs can
use the same Northbound API as
used by Network Applications
Impact of Virtualization on GANA
(ETSI / ISG / NFV mapping to be discussed)
Simplified ETSI /NFV / MANO
Network
Governance
Interface
OSS/
BSS
NFV
Orchestrator
EMS
VNF Manager
Knowledge Plane
?
ONIX
MBTS
Network Level Routing Management DE
Network Level Fault Management DE
Other Network Level DEs
e.g. Network Level QoS Management DE
GANA
Profile
Virtualized
Infrastructure
Manager (VIM)
Hierarchy of Decision
Elements (DEs)
Network Level DEs
(GANA Level-4)
Administrator/Network
Operator
To be investigated:
Input into GANA
Network Profiles
Introduce GANA Level 2 / 3 DEs
Vertical
Reference
Point
Outer Control Loop
NE (router, terminal, switch,
gateway, base-station, etc.)
NE (router, host, switch,
gateway, base-station, etc.)
Node_Main_DE
Node_Main_DE
Function-Level DE, e.g. QoS
Management DE
Function-Level DE, e.g. QoS
Management DE
Function Level DEs
(GANA Level-2)
Managed Entities (MEs)
Managed Entities (MEs)
(partitioned and assigned
to specific upper DEs)
(partitioned and assigned
to specific upper DEs)
Protocol Level DEs
(GANA Level-1)
Node Level DEs
(GANA Level-3)
NFVI
Virtual
Storage
Virtual
Computing
Virtual
Network
Network Element (NE)
Virtualization layer
Storage
HW
Computing
HW
Network
HW
GANA Level 2&3 DEs
Managed Entities (MEs)/
can be introduced
Resources, i.e. Protocols,inStacks &
PhysicalMechanisms,
node and
orApplications
a
Virtual Node/VNF
Horizontal
Reference
Point
GANA, NFV, SDN combination
(Proposal for discussion purpose)
GANA Network Governance
Interface
Simplified ETSI /NFV / MANO
OSS/
BSS
NFV
Orchestrator
EMS
VNF Manager
?
Virtualized
Infrastructure
Manager (VIM)
To be investigated:
Input into GANA
Network Profiles
NFVI
Introduce GANA Level 2 / 3 DEs
Virtual
Storage
Virtual
Computing
Virtual
Network
Virtualization layer
Storage
HW
Computing
HW
Network
HW
GANA Level 2&3 DEs can be
introduced in Physical node
or a Virtual Node/VNF
Research Projects can adopt the Standardized Autonomics-Enabled Architectures that
result from GANA Instantiation onto a particular target architecture, and then to peform
the following:
1. Use the Instantiated GANA Functional Blocks and Reference Points for enabling
Autonomicity/Self-Management in a target architecture, to specify Autonomic
Behaviours within the Management and the E2E Control & Data Plane Architectures
Specify Behaviours of instantiated GANA Functional Blocks (including DEs and
their Control-Loops)
Develop the GANA DE algorithms for autonomics
© ETSI 2014. All rights reserved
GANA Instantiations onto target
architectures such as the BBF
(Broadband Forum), Mesh, IMS
architectures, PTDN, etc
© ETSI 2014. All rights reserved
Instantiation of GANA onto the BBF
Architecture
Knowledge Plane
Network-LevelSecurity_Management_DE
Network Governance
Interface
Other Network-Level-DEs e.g.
Network_Level_Fault_Management_DE
Net-Level-DE(s) and
MBTS in the same
physical machine
Model-Based Translation
Service (MBTS)
Network-Level-DataPlane and
Fowarding_Management_DE
Network-LevelQoS_Management_DE
GANA
Profile
Administrator/BB Network
Operator
Remarks on Autonomic Management and
Relationships between DEs, NMS’s,
EMS’s:
1. A Decision Element (DE) is an
„Autonomic Manager Element“ that realizes
a Control-Loop over its assigned Managed
Entities (MEs), and interacts vertically and
horizontally with other DEs in order to
achieve network goals collaboratively.
Net-Level-DE
ONIX
GANA Level-2
and Level-3
DEs
NSP/BB
Network
Gateway
Model-Based Translation
Service (MBTS)
A10-NSP
L2TP
NSP1
3. All relevant Reference Points are
described in WI#2 Spec
GANA Level-2
and Level-3
DEs
GANA Level-2
and Level-3
DEs
L2TS
A10-NSP
GANA Level-2
and Level-3
DEs
User1
IP - QoS
NSP2
IP
A10-NSP
BB
Network
Gateway
Access
Node
(DSLAM)
Ethernet
Aggregation
MDF
Access NID
Loop
ASP1
IP - QoS
V
Regional Broadband
Network
Access Network
Aggregation Network
Reference Point: Rfp_NodeMainDE-to-ONIX-System
Reference Point: Rfp_ModelBasedTranslationService-to-NodeMainDE (a refinement of
Rfp_NetworkLevelDE-to-NodeMain-DE)
User2
Customer Prem. Net
U
GANA Level-2 and Level-3 DEs
embeded inside
CPE
T
A10-ASP
2. Network-Level-DEs can be considered,
collectively, as evolved EMS’s or NMS’s.
GANA Level-2
and Level-3
DEs
Network Element e.g.
BNG, Aggregation Node,
Access Node, CPE
Prioritized Reference Point:
Rfp_ModelBasedTranslationService-to-NodeMainDE (a
refinement of Rfp_NetworkLevelDE-to-NodeMain-DE)
Outer
ControlLoop
Exposing
“Views”
Objectives, Policies
from a higher level
(network-level)
Information /
Knowledge
Repository
Self-Description
&
Self-Advertisement
NODE_LEVEL_R&S_DE
NODE_LEVEL_AC_DE
NODE_LEVEL_SEC_M_DE
Control
Loop
Autonomic BNG
GANA Level-3
Node Level
NODE_LEVEL_FM_DE
Controls Level-2 DEs
FUNC_LEVEL_GCP_M_DE
FUNC_LEVEL_MON_DE
Control
Loop
FUNC_LEVEL_QoS_M_DE
FUNC_LEVEL_DP&FWD_M_DE
Control
Loop
GANA Level-2
Function Level
FUNC_LEVEL_RT_M_DE
Control
Loop
Control
Loop
Control
Loop
GANA Level-1
Protocol Level
Routing Protocol?
Monitoring
Tools /
Components
IPv4/IPv6 etc
MPLS, etc
802.1ad
Ethernet, etc
PHY
NODE_LEVEL_AC_DE – Node-Level Auto-Configuration Decision-Element
Layer 4 Protocols
Control Plane Protocols
Any type of stack on which
the control protocols are
running e.g. an IP based
transport (data plane), which
is autonomically managed
by the
FUNC_LEVEL_DP&FWD_
M_DE
Layer 3 Protocols
Layer 2.5 Protocols
0
Layer 2 Protocols
PHY
Protocol Stacks and Mechanisms
Reference Point:
Rfp_GANA-Level2_AccessToProtocolsAndMechanisms:
This interface MAY be open to enable DEs loaded into the node/device (e.g. by a
second party) to access and autonomically manage and control the MEs (Protocols,
Stacks and Mechanisms) of the device. Some of the Information/Data and Parameters
exposed by the MEs and accessible to the loaded DEs, may be standardized.
NODE_MAIN_DE
Initialization
&
Orchestration
FUNC_LEVEL_QoS_M_DE – Function-Level Quality of Service-Management Decision-Element
NODE_LEVEL_R&S_DE – Node-Level Resilience & Survivability Decision-Element
NODE_LEVEL_SEC_DE – Node-Level Security Decision-Element
FUNC_LEVEL_DP&FWD_M_DE – Function-Level DataPlane&Forwarding-Management
Decision-Element
NODE_LEVEL_FM_DE – Node-Level Fault-Management Decision-Element
FUNC_LEVEL_MON_DE – Function-Level Monitoring Decision-Element
FUNC_LEVEL_RT_M_DE – Function-Level Routing-Management Decision-Element
FUNC_LEVEL_GCP_M_DE – Function-Level Generalized Control Plane-Management Decision-Element
BNG
Aggregation Node
Objectives, Policies from a
higher level (network-level-DE)
Main Decision
Element of the
Node (Node-DE)
Level-2 Decision
Element (s) e.g.
QoS-ManagementDE
GANA’s lowest level/
layer MEs: Protocols,
Protocol Stacks,
Services/Applications
and fundamental
Mechanisms
Peers
Peers
Peers
Managed Entities
(MEs)
Objectives, Policies from a higher
level (network-level-DE)
Main Decision
Element of the
Node (Node-DE)
Level-2 Decision
Element (s) e.g.
QoS-ManagementDE
Decision Element
intrinsic to a
Managed Entities
Routing
Protocol
(MEs)
e.g. OSPF
Peers
Peers
Peers
Access Node
CPE
Objectives, Policies from a
higher level (network-level-DE)
Objectives, Policies from a
higher level (network-level-DE)
Main Decision
Element of the
Node (Node-DE)
Main Decision
Element of the
Node (Node-DE)
Level-2 Decision
Element (s) e.g.
QoSManagement-DE
Managed Entities
(MEs)
Peers
Peers
Peers
Level-2 Decision
Element (s) e.g.
QoSManagement-DE
Managed Entities
(MEs)
Instantiation of the ETSI AFI GANA
Reference Model onto the PTDN
Architecture to create an AutonomicityEnabled PTDN architecture
© ETSI 2014. All rights reserved
As is being done for other architectures (BBF,Mesh, IMS,etc), the
GANA can be instantiated onto the PTDN to create an
Autonomics-Enabled PTDN Architecture
See next slides on
Guidelines on how
to perform
Instantiation of
GANA Model onto
a target
architecture to
create an
AutonomicsEnabled
Architecture
Guidelines on how to perform
Instantiation of GANA Model onto a
target architecture to create an
Autonomics-Enabled Architecture
R. Chaparadza, Tayeb Ben Meriem, Benoit Radier, Szymon Szott, Michal Wodczak, Arun Prakash, Jianguo Ding, Said
Soulhi, Andrej Mihailovic: Implementation Guide for the ETSI AFI GANA Model: a Standardized Reference
Model for Autonomic Networking, Cognitive Networking and Self-Management: In the proceedings of the 5th
IEEE MENS Workshop at IEEE Globecom 2013, December, Atlanta, Georgia, USA
© ETSI 2014. All rights reserved
Steps Towards Architectural Enhancements and
Autonomic Behaviour Specifications for ANY Architecture
1. Instantiate Functional Blocks and Reference Points for Autonomicity/Self-Management
f om AFI’ Reference Model onto ANY Architecture and its Management Architecture
Functional Blocks of the Knowledge Plane (Net-Level-DEs, MBTS, ONIX)
Network-Level-DEs perform the role of Policy-Decision Points (PDPs) and so PDPs
can be evolved by the DEs
Network-Level-DEs (in the Knowledge Plane) evolve EMSs or NMSs
ONIX Information sharing/exchange servers facilitate advanced Auto-Discovery
Establish the type of Autonomic Functions (Decision Elements and their associated
Control-Loops and Managed Entities) that should be instantiated into what type of
Network Elements
How are the Network Elements, EMSs/NMSs enhanced by DEs and the Reference
Points instantiated to all the Functional Blocks that are specific to Autonomics/SelfManagement
2. Use the Instantiated Functional Blocks (FBs) and Reference Points for Autonomicity/SelfManagement from the Reference Model, to specify Autonomic Behaviours within the
Management and the E2E Transport Architecture
Specify Behaviours of instantiated GANA FBs (including DEs and their Control20
Loops)
Panel Session Topics for
Discussion
© ETSI 2014. All rights reserved
Reflections on IPv6 and Autonomic
Networking
•
IPv6 Forum is collaborating with ETSI in TC NTECH AFI WG,
following on EC-FP7 EFIPSANS project results on IPv6 &
Autonomics : ETSI-IPv6 Forum MoU & work in AFI)
•
There are new potential work items related to IPv6 and
Autonomic Networking that were proposed in ETSI AFI during
the ETSI 2013 Future Networks Technologies workshop
•
It is now necessary for industry to consider linking Autonomic
Networking Standardization with IPv6 by launching the
proposed new Work Items in ETSI AFI
IPv6 and Autonomic Networking
Standards
New AFI Work Items are envisaged on the IPv6 Feature(s) Usage
Requirements in Autonomic Networks:
Reference: ETSI Future Networks Workshop 2013:
http://workshop.etsi.org/2013/201304_FNTWORKSHOP/S03_SelfMgtandControlforSDN/AFI_IPv6_CHAPARADZA.pdf
The IPv6 Community can launch the following Work Items envisaged by ETSI NTECH / AFI:
IPv6-Feature(s) Usage Requirements in Autonomic 3GPP and Non-3GPP Mobile Network Reference Architectures;
 IPv6 Features that enable the Autonomics
IPv6-Feature(s) Usage Requirements in Autonomic Broadband Forum (BBF) Reference Architecture;  IPv6
Features that enable the Autonomics
IPv6-Feature(s) Usage Requirements in Autonomic NGN/IMS Architecture;  IPv6 Features that enable the
Autonomics
IPv6-Feature(s) Usage Requirements in Autonomic TISPAN CDN Reference Architecture;  IPv6 Features that
enable the Autonomics
IPv6-Feature(s) Usage Requirements in Autonomic Wireless Adhoc/Mesh/Sensor network architectures;  IPv6
Features that enable the Autonomics
Some Reflections on 5G
There are now a lot of activities around the 5G related Topics, both in Research (in particular) and also in Industry
(e.g. NGMN, TMForum / ZOOM, and other Groups)
In regard to 5G, we can observe that the following points are worthy to take note of:
•
SDN, NFV and AMC will play key roles in the 5G architecture, due to the complementarities of the three
paradigms in addressing the dynamics, flexibility in network & service compositions, and intelligence
expected in 5G networks
Regarding Autonomics:
•
5G embedded Autonomic Functions (AFs) are enablers for the edge, backhaul and core network nodes to
intelligently, optimally and adaptively provision resources in such a way as to handle the anticipated huge
traffic volumes and diversified traffic flows of various requirements that must be transported over the 5G
network. Also, advanced Autonomicity in network & services resilience is needed.
•
In 5G, more advanced Self-Organizing Network (SON) Functions could be envisaged, beyond SON functions
already introduced for 2G/3G/4G). Enrichment of SON with advanced Autonomicity/cognitive
algorithms/behaviors is also desirable; and also may be desirable is autonomic coordination of SON functions
on inter-system interfaces of Multi-RATs and Fixed/Mobile convergence interfaces.