Date post: | 14-Dec-2015 |
Category: |
Documents |
Upload: | lizeth-andersen |
View: | 219 times |
Download: | 2 times |
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
Standardized Architectural Frameworks, Concepts and Models, but on individual Networking Paradigms in Silos, e.g. for AMC (Autonomics), SDN, NFV, etc
Further research activities on: the new technologies and large-scale experimentation.
Pre-Standardization on Architectural Frameworks (inc. Reference Models), Concepts, Models, etc.
Standardized Unified/Harmonized Frameworks, Concepts and Models that combine multiple Networking Paradigms
ĞƐŝƌĂďůĞC 1. ĚŽƉƚŝŽŶŽĨ^ƚĂŶĚĂƌĚƐŝŶZĞƐĞĂƌĐŚΘĨĞĞĚďĂĐŬ -ĨůŽǁ ; ĞŐ
ŝŵƉůĞŵĞŶƚĂƚŝŽŶĞdžƉĞƌŝĞŶĐĞŽŶƐƚĂŶĚĂƌĚŝnjĞĚĨƌĂŵĞǁ ŽƌŬƐ ͿƚŽ^K ƐQ &ŽƌĂ
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 “distributed model” (for fast control-loops). That means, the logic is embedded in the nodes
(Physical or Virtualized).
• Whereas, a “centralized model” (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 ArchitectureAFI 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 SONAFI and NGMN: NGCOR Requirements calling for Autonomics-Awareness in the Management Architecture. Autonomics-awareness is also in NGMN 5G initiativeAFI in Multi-SDO Initiative: AFI to specify Autonomics and Self-Management for various NGCOR Use Cases and the Converged Management of Fixed and Mobile NetworksAFI 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 NGNAFI and ITU-T SG2, SG15 and : Autonomic Management and Control in NGN and other Architectures, including Network Resilience, Autonomic Fault Management and RecoveryAFI 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
NE (router, terminal, switch, gateway, base-station, etc.)
Knowledge Plane
Function-Level DE, e.g. QoS Management DE
Node_Main_DE
Other Network Level DEse.g. Network Level QoS Management DE
Hierarchy of Decision Elements (DEs)
Managed Entities (MEs)(partitioned and assigned
to specific upper DEs)
Function-Level DE, e.g. QoS Management DE
Node_Main_DE
Managed Entities (MEs)(partitioned and assigned
to specific upper DEs)
ONIX MBTS
Vertical Reference
Point
Horizontal Reference
Point
Managed Entities (MEs)/Resources, i.e. Protocols, Stacks & Mechanisms, and Applications
Network Element (NE)
Protocol Level DEs (GANA Level-1)
Function Level DEs (GANA Level-2)
Node Level DEs (GANA Level-3)
Network Level DEs (GANA Level-4)
NE (router, host, switch, gateway, base-station, etc.)
Outer Control Loop
GANA Profile
Administrator/Network Operator
Network Governance
Interface
Network Level Fault Management DENetwork Level Routing Management DE
3-Levels of Hierarchical Control-Loops demonstrate how Autonomics can be introduced in architectures.
“Fast Control-Loops” in the Nodes/NEs, while “Slow but network-wide Control-Loops“ should operate in the outer centralized GANA Knowledge Plane (i.e. SDN – Controller & Net-Apps realm)
MBTS: Model-Based-Translation ServiceONIX :Overlay Network for Information eXchange
Impact of SDN on GANA Knowledge PlaneProposal on integrating GANA Knowledge Plane DEs with SDN Controllers, to enable Autonomcity (Approach 1)
© ETSI 2011. All rights reserved
(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
Impact of SDN on GANA Knowledge PlaneProposal on integrating GANA Knowledge Plane DEs with SDN Controllers, to enable Autonomcity (Approach 2)
© ETSI 2014. All rights reserved
Note: GANA also incorporates concepts from the 4D architecture upon which OpenFlow was founded (see in AFI GANA Spec)
GANA Knowledge Plane DEs can use the same Northbound API as used by Network Applications
(2) GANA Knowledge Plane DEs as Modules of an SDN Controller
Impact of Virtualization on GANA(ETSI / ISG / NFV mapping to be discussed)
NE (router, terminal, switch, gateway, base-station, etc.)
Knowledge Plane
Function-Level DE, e.g. QoS Management DE
Node_Main_DE
Other Network Level DEse.g. Network Level QoS Management DE
Hierarchy of Decision Elements (DEs)
Managed Entities (MEs)(partitioned and assigned
to specific upper DEs)
Function-Level DE, e.g. QoS Management DE
Node_Main_DE
Managed Entities (MEs)(partitioned and assigned
to specific upper DEs)
ONIX MBTS
Vertical Reference
Point
Horizontal Reference
Point
Managed Entities (MEs)/Resources, i.e. Protocols, Stacks & Mechanisms, and Applications
Network Element (NE)
Protocol Level DEs (GANA Level-1)
Function Level DEs (GANA Level-2)
Node Level DEs (GANA Level-3)
Network Level DEs (GANA Level-4)
NE (router, host, switch, gateway, base-station, etc.)
Outer Control Loop
GANA Profile
Administrator/Network Operator
Network Governance
Interface
Network Level Fault Management DENetwork Level Routing Management DE
NFVOrchestrator
VNF Manager
Virtualized InfrastructureManager (VIM)
Storage HW
Computing HW
Network HW
Virtualization layer
VirtualStorage
VirtualComputing
VirtualNetwork
?
Introduce GANA Level 2 / 3 DEs
OSS/BSS
Simplified ETSI /NFV / MANO
To be investigated: Input into GANA Network Profiles
EMS
NFVI
GANA Level 2&3 DEs can be introduced in Physical node or a Virtual Node/VNF
GANA, NFV, SDN combination(Proposal for discussion purpose)
NFVOrchestrator
VNF Manager
Virtualized InfrastructureManager (VIM)
Storage HW
Computing HW
Network HW
Virtualization layer
VirtualStorage
VirtualComputing
VirtualNetwork
?
Introduce GANA Level 2 / 3 DEs
OSS/BSS
To be investigated: Input into GANA Network Profiles
GANA Level 2&3 DEs can be introduced in Physical node or a Virtual Node/VNF
GANA Network Governance Interface
EMS
NFVI
Simplified ETSI /NFV / MANO
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
Regional BroadbandNetwork
Access Network
AccessNode
(DSLAM)
AccessLoop
MDFEthernet
AggregationIP
BBNetworkGateway
L2TS
IP - QoS
L2TP
Customer Prem. Net
CPE
NSP1
ASP1
A10-ASP
A10-NSP
U
User1
User2T
NIDNSP2
A10-NSP
IP - QoS
A10-NSP
V
NSP/BB Network Gateway
Aggregation Network
Network-Level-DataPlane and Fowarding_Management_DE
Network-Level-QoS_Management_DE
Network-Level-Security_Management_DE
Other Network-Level-DEs e.g. Network_Level_Fault_Management_DE
ONIX
GANA Level-2 and Level-3
DEs
GANA Level-2 and Level-3
DEsGANA Level-2
and Level-3 DEs
GANA Level-2 and Level-3
DEs
Knowledge Plane
GANA Profile
Administrator/BB Network Operator
Network Governance Interface
GANA Level-2 and Level-3
DEs
Model-Based Translation Service (MBTS)
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.
2. Network-Level-DEs can be considered, collectively, as evolved EMS’s or NMS’s.
3. All relevant Reference Points are described in WI#2 Spec
Net-Level-DE
Model-Based Translation Service (MBTS)
GANA Level-2 and Level-3 DEs embeded inside
Reference Point: Rfp_NodeMainDE-to-ONIX-System
Reference Point: Rfp_ModelBasedTranslationService-to-NodeMainDE (a refinement of Rfp_NetworkLevelDE-to-NodeMain-DE)
Network Element e.g. BNG, Aggregation Node,
Access Node, CPE
Net-Level-DE(s) and MBTS in the same physical machine
Instantiation of GANA onto the BBF Architecture
IPv4/IPv6 etc
MPLS, etc
Ethernet, etc
PHY
Layer 2.5 Protocols
Layer 2 Protocols
PHY
Layer 3 Protocols
Layer 4 Protocols
0
Information / Knowledge Repository
FUNC_LEVEL_DP&FWD_M_DEFUNC_LEVEL_QoS_M_DE
Routing Protocol?
Monitoring Tools /
Components
NODE_MAIN_DE
NODE_LEVEL_FM_DENODE_LEVEL_SEC_M_DE
NODE_LEVEL_R&S_DENODE_LEVEL_AC_DE
Self-Description&
Self-Advertisement
Initialization&
Orchestration
GANA Level-1Protocol Level
GANA Level-2Function Level
GANA Level-3Node Level
FUNC_LEVEL_MON_DE
Control Plane Protocols
FUNC_LEVEL_RT_M_DE
FUNC_LEVEL_GCP_M_DE
FUNC_LEVEL_QoS_M_DE – Function-Level Quality of Service-Management Decision-Element
FUNC_LEVEL_DP&FWD_M_DE – Function-Level DataPlane&Forwarding-Management Decision-Element
FUNC_LEVEL_RT_M_DE – Function-Level Routing-Management Decision-Element
NODE_LEVEL_AC_DE – Node-Level Auto-Configuration Decision-Element
NODE_LEVEL_R&S_DE – Node-Level Resilience & Survivability Decision-Element
NODE_LEVEL_SEC_DE – Node-Level Security Decision-Element
NODE_LEVEL_FM_DE – Node-Level Fault-Management Decision-Element
FUNC_LEVEL_MON_DE – Function-Level Monitoring Decision-Element
FUNC_LEVEL_GCP_M_DE – Function-Level Generalized Control Plane-Management Decision-Element
Controls Level-2 DEs
Autonomic BNG
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
Ref
eren
ce P
oint
: R
fp_G
AN
A-L
evel
2_A
cces
sToP
roto
cols
And
Mec
hani
sms:
This
inte
rface
MA
Y be
ope
n to
ena
ble
DEs
load
ed in
to th
e no
de/d
evic
e (e
.g. b
y a
seco
nd p
arty
) to
acce
ss a
nd a
uton
omic
ally
man
age
and
cont
rol t
he M
Es (P
roto
cols
, St
acks
and
Mec
hani
sms)
of t
he d
evic
e. S
ome
of th
e In
form
atio
n/D
ata
and
Para
met
ers
expo
sed
by th
e M
Es a
nd a
cces
sibl
e to
the
load
ed D
Es, m
ay b
e st
anda
rdiz
ed.
802.1ad
Control Loop
Control LoopControl
LoopControl
Loop
Control Loop
Control Loop
Prot
ocol
Sta
cks a
nd M
echa
nism
s
Objectives, Policies from a higher level
(network-level)
Exposing “Views”
Outer Control-
Loop
Prioritized Reference Point: Rfp_ModelBasedTranslationService-to-NodeMainDE (a refinement of Rfp_NetworkLevelDE-to-NodeMain-DE)
Main Decision Element of the
Node (Node-DE)
Objectives, Policies from a higher level (network-level-DE)
Level-2 Decision Element (s) e.g.
QoS-Management-DE
Main Decision Element of the
Node (Node-DE)
Objectives, Policies from a higher level (network-level-DE)
Level-2 Decision Element (s) e.g.
QoS-Management-DE
Managed Entities (MEs)
Decision Element intrinsic to a
Routing Protocol e.g. OSPF
Peers
Peers
Peers
BNG Aggregation Node
Managed Entities (MEs)
GANA’s lowest level/layer MEs: Protocols,
Protocol Stacks, Services/Applications
and fundamental Mechanisms
Main Decision Element of the
Node (Node-DE)
Objectives, Policies from a higher level (network-level-DE)
Level-2 Decision Element (s) e.g.
QoS-Management-DE
Managed Entities (MEs)
Access Node
Main Decision Element of the
Node (Node-DE)
Objectives, Policies from a higher level (network-level-DE)
Level-2 Decision Element (s) e.g.
QoS-Management-DE
Managed Entities (MEs)
CPE
Peers
Peers
Peers
Peers
Peers
Peers
Instantiation of the ETSI AFI GANA Reference Model onto the PTDN Architecture to create an Autonomicity-Enabled 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 Autonomics-Enabled Architecture
Guidelines on how to perform Instantiation of GANA Model onto a target architecture to create an Autonomics-Enabled Architecture
© ETSI 2014. All rights reserved
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
Steps Towards Architectural Enhancements and Autonomic Behaviour Specifications for ANY Architecture
1. Instantiate Functional Blocks and Reference Points for Autonomicity/Self-Management from AFI’s 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 DEsNetwork-Level-DEs (in the Knowledge Plane) evolve EMSs or NMSsONIX Information sharing/exchange servers facilitate advanced Auto-DiscoveryEstablish the type of Autonomic Functions (Decision Elements and their associated Control-Loops and Managed Entities) that should be instantiated into what type of Network ElementsHow are the Network Elements, EMSs/NMSs enhanced by DEs and the Reference Points instantiated to all the Functional Blocks that are specific to Autonomics/Self-Management
2. Use the Instantiated Functional Blocks (FBs) and Reference Points for Autonomicity/Self-Management 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 Control-Loops) 20
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.