Transcript Manageability in Future Internet_2015.ppt

Manageability of Future Internet
Choong Seon Hong
Kyung Hee University
[email protected]
April 14, 2015
Contents
2




Introduction to Future Internet and its Manageability
Generic Network Management Architecture
GENI Working Groups related to Mgmt
A Basic SDN Architecture
Requirements for Future Internet
3
Security
• Seamless handoff/roaming
• Identity/addressing
Mobility
• Intelligent and programmable
network nodes
Programmability
• Integrity, authenticity,
confidentiality of communication
with any given peer
• Virtualization of Resources
Scalability
Interoperability
Reliability
Availability
Virtualization
• FCAPS
• Autonomic Management
Manageability
Requirements for Future Internet
4
Security
• Seamless handoff/roaming
• Identity/addressing
Mobility
• Integrity, authenticity,
confidentiality of communication
with any given peer
• Virtualization of Resources
Scalability
Interoperability
Reliability
Availability
Virtualization
Manageability
• Intelligent and programmable
network nodes
Programmability
• FCAPS
• Autonomic Management
Manageability
5
Current Network Environment
6
INTERNET
xDSL/Cable
FTTH
PSDN
10 Gigabit
Ethernet
ATM
Satellite
Fast
Ethernet
ISDN
SS#7
Gigabit
Ethernet
WANs
IN/AIN
Ethernet
Broadcast
Networks
(DAB, DVB-T)
PSTN
SONET
CDMA, GSM,
GPRS, LTE,
LTE-A
IP-based
micro-mobility
B-ISDN
Bluetooth
Zigbee
6LoWPAN
Wireless
LANs
WiBro,
HSDPA
Current Network Management Framework
7
Management Platform
Collect, organize & interpret
Operational Data
Administrator
Workstation
mgmt requests/replies
Agent
event reports
Agent
Agent
Agent
Agent Agent
Observation
& Control
Agent
Functional Requirements for NM
8

Fault Management
 detection,

Configuration Management
 identify

track of usage for charging
Performance Management
 monitor

managed resources and their connectivity, discovery
Accounting Management
 keep

isolation and correction of abnormal operations
and evaluate the behavior of managed resources
Security Management
 allow
FCAPS
only authorized access and control
Standard Management Frameworks
9

OSI Network Management Framework


CMIP (X.700 Series)
Internet Network Management Framework
SNMPv1
 SNMPv2
 SNMPv3


TeleManagement Forum


Distributed Management Task Force


SID, eTOM, NGOSS
CIM, WBEM
Open Mobile Alliance

OMA DM
10
11
Manageability for the current Internet has
been developed as an afterthought!
THINK about Manageability of Future Internet
Do we need a revolutionary approach
or an evolutionary approach?
FCAPS
?
Management for Future Internet
12

Autonomic Management/Self-Management
 Self-managing
frameworks and architecture
 Knowledge engineering,
including information modeling and ontology design
 Policy analysis and modeling
 Semantic analysis and reasoning technologies
 Virtualization of resources
 Orchestration techniques
 Self-managed networks
 Context-awareness
 Adaptive management
Research Efforts for Management of FI
13

US NSF
 Future

Complexity Oblivious Network Management architecture (CONMan)
 Global
(GENI)


Internet Design (FIND)
Environment for Networking Innovations
Operations, Management, Integration and Security (OMIS) WG
EU
 Framework



13
Program (FP) 7
4WARD In-network (INM) project
Autonomic Internet (AutoI) project
Autonomic Network Architecture (ANA) project
CONMan: Overview
14



Management interface should contain as little
protocol-specific information as possible
Complexities of protocols should be masked
from management
Goal
A generic abstraction of network entities (protocols &
devices) for management purpose
 A set of atomic management operations to work upon
the abstraction
 A way to translate high-level management objectives
to low-level operations

14
Research Efforts - EU
15
http://www.4ward-project.eu

4WARD WP4: INM (In Network Management)
 Autonomic
self-management
 Abstractions and a framework for a selforganizing management plane
 Scheme, strategies, and protocols for collaborative
monitoring, self-optimizing, and self-healing
Research Efforts - USA
16

GENI OMIS WG (Operations, Management, Integration
and Security)
 Operations,
management, integration and security processes
in GENI
 Experiment support, monitoring, and data storage
 Security monitoring and incident response
 Federation management and monitoring
 Hardware release, maintenance and integration
 Software release, maintenance and integration
 Operations metric collection and analysis
 http://www.geni.net/wg/omis-wg.html
Research Efforts - Korea
17

CASFI (Collect, Analyze, and Share for Future
Internet)
 Goals
Manageability of Future Internet
 Data Sharing Platform for Performance Measurement
 High-Precision Measurement and Analysis
 Human Behavior Analysis

 Groups

KHU, KAIST, POSTECH, CNU
 Period

2008.03.01 ~ 2013.02.28
 http://casfi.kaist.ac.kr
Management for Future Internet [1]
18

Management Interface
 Management
Information Modeling & Operations
 Instrumentation

Management Architecture
 Centralized
vs. Decentralized Management
 Peer-to-Peer
 Hybrid

Service Management
 Customer-centric
service
 Service portability
 SLA/QoS
Management for Future Internet [2]
19

Traffic Monitoring/Measurement and Analysis
 Monitoring
for large-scale and high-speed networks
 Network/application-level monitoring
 Global traffic data access/sharing
 Fast and real time monitoring
 Statistical sampling method
 Storing method for large scale traffic data
 Measurement and analysis of
social networking
Generic Network Management
Architecture
1. What is Management?
21
Network management is the act of
initializing, monitoring and modifying
the operation of the primary functions
Management functions
Action
Defined during operation
configuration
measurement
Primary functions
Defined at design time
Must be standardized
System
2. Why Management?
22
Cost reduction
 Flexibility
 Fault handling
 Security

Cost Reduction
23

General purpose designs

Internet, VoIP, SCADA, Server Farms, Internet of Things, …
Flexibility
24

Changing user requirements
Flexibility: Cyclic design
25
3. How is Management performed?
26
a.
Explicit versus implicit management
b.
Centralized versus distributed management
c.
Meta-Management
3.B Explicit versus Implicit
27


Explicit management
Implicit management
Action
measurement
System
Hard, Soft AND Brainware
Hard and Software
Self-management
Autonomic networking
configuration
From explicit to implicit management
28
Scripts, policies, …
From explicit to implicit management
29


Management needs to be increasingly part of the
functionality of a managed object, not something which
can be added afterwards
Future Networks will challenge Service and Network
Operators to find the right ways to embed intelligence
into networks in order to ensure their autonomic
management and control
3.b Centralized versus Distributed
30

Centralized
 DNS
 DHCP
 SNMP
 NetConf

Distributed
 ZeroConf,
Bonjour, …
From centralized to distributed management
31
From explicit and centralized
to implicit and distributed management
32
3.c Meta Management
33
Management is a moving target: in later design cycles we will have
to manage the management functions from the previous cycles
(meta-management)
Predicting the future: conclusions
34

There are several management invariants
 The
reasons to perform management (WHY) do not
change
 The way we do management (HOW) remains relatively
stable
 From
explicit to implicit
 From centralized to distributed
 The
management functions we have to design are a
moving target
 Meta-management

These invariants may help determining future
directions
Network Configuration - Overview
35

Network Configuration
OpenFlow
 Relation to SNMP, COPS-PR, NetConf

Action
Measurements
Configurations
System
Timeline
36
Mobile Agents
Active Networks
Web Services
1990
1996
2002
2008
2014
SNMP
COPS-PR
NetConf
OpenFlow
COPS-PR
37
Out of profile
traffic
*Common Open Policy Service (COPS) for Policy Provisioning(PR)
NetConf motivation
38



Managers need better control over routing
Routing protocols such as OSPF lack flexibility
Routing decisions should be made at a central site
NetConf characteristics
39

Intended for Configuration Management
 Based
on XML technology
 Operates on documents, instead of objects

Granularity level is therefore high
 Data

models not (yet?) defined
Security is provided at lower layers
 Use
of TCP
 Use of existing security mechanisms (SSH, TLS, SOAP,
BEEP)

Multiple operations are defined
NetConf - Operations
40









Get-Config (Source, Filter)
Edit-Config(Target, Options, Config)
Copy-Config(Source, Target)
Delete-Config(Target)
Get(Filter)
Validate(Source)
Lock(Source)
Unlock(Source)
Commit(Confirmed, Confirmed-Timeout)
OpenFlow motivation
41




Managers need better control over routing
Routing protocols such as OSPF lack flexibility
Routing decisions should be made at a central site
Forwarding hardware and routing software should
be decoupled
OpenFlow characteristics
42
Controller
OpenFlow
Protocol
SW
SSH
Secure
channel
HW Flow Ta
ble
OpenFlow switch
Manager
SNMP
COPS-PR
NetConf
UDP
TCP
SSH
Agent
Hardware
Switch, router, …
OpenFlow Example
Controller
43
Software
Layer
PC
OpenFlow Client
Flow Table
MAC
src
Hardware
Layer
*
MAC
dst
*
port 1
IP
Src
*
IP
Dst
5.6.7.8
port 2
TCP
TCP
sport dport
*
*
port 3
Action
port 1
port 4
Source: OpenNetSummit Tutorial (10/19/2011)
http://www.openflow.org/wk/index.php/OpenFlow_Tutorial
5.6.7.8
1.2.3.4
Configuration Protocols Conclusion
44


OpenFlow is (yet another) configuration management protocol
OpenFlow has many similarities to:




Granularity level of OpenFlow is:




Higher than SNMP
Same as COPS-PR
Lower than NetConf
OpenFlow somehow mixes PDUs and Data



SNMP
COPS-PR
NetConf
Easier to understand
Harder to extend
Network management research community should use their expertise
to improve OpenFlow design
Mgmt in GENI - Outline
45

GENI Working Groups for Future Internet Mgmt




Control Framework
Experiment Workflow & Services
Instrumentation & Measurements
Operation, Management, Integration & Security (OMIS)

GMOC GENI Meta Operation Center
GENI : Global Environment for Network Innovations
GENI Working Groups
46

Control Framework WG



Experiment Workflow and Services WG



Logically stitching GENI components and user-level services into a coherent system
Design of how resources are described and allocated and how users are identified and
authorized
Tools and mechanisms a researcher uses to design and perform experiments using GENI
Includes all user interfaces for researchers, as well as data collection and archiving
Instrumentation & Measurements WG


GIMS - GENI Instrumentation and Measurement Service
GENI researchers require extensive and reliable instrumentation and measurement
capabilities to gather, analyze, present and archive Measurement Data


To conduct useful and repeatable experiments
Operations, Management, Integration and Security (OMIS) WG


Designing, deploying, and overseeing the GENI infrastructure
Operation Framework
Control Framework
47

GENI control framework defines:




Interfaces between all entities
Message types including basic protocols and required functions
Message flows necessary to realize key experiment scenarios
GENI control framework includes the entities and the Control
Plane for transporting messages between these entities





component control
slice control
access control within GENI
federation
key enablers such as identification, authentication and authorization
Virtualization and Federation
48
Operation and Management
Create my experiment slice, Install my software,
debug, collect data, retry, etc.
GENI
Clearinghouse
GENI AM API
GENI AM API
GENI AM API
Components
Components
Components
PlanetLab Aggregate
virtual machines
GENI AM (aggregate Manager)
OpenFlow
Aggregate
layer2 switches
ProtoGENI
Aggregate
programmable nodes and
links
GENI Architecture - Control Framework
49
The Control Framework
WG focuses on component
control,
slice control, access control
within GENI and
federation and interaction
between these GENI
entities
Instrumentations & Measurements
50




Discuss, develop and build consensus around the architectural
framework for the instrumentation and measurement infrastructure that
will be deployed and used in GENI
Create an architecture for measurement that enables GENI goals to be
achieved
Facilitate dialog and coordination between teams focused on I&M
Identify key challenges in I&M that could otherwise inhibit the
infrastructure

Solicit feedback from users

Deploy basic instrumentation and measurement capabilities

Services

Measurement Orchestration (MO)

Measurement Point (MP)

Measurement Collection (MC)

Measurement Analysis and Presentation (MAP)

Measurement Data Archive (MDA)
Relationship to GENI Architecture
51
The Instrumentation and
Measurement WG
focuses on the
instrumentation and
measurement
infrastructure that will be
deployed and used in
GENI.
GIMS – Protocols & Communication
52


Researcher via Experiment Control service (tools), including
MO(Measurement Orchestration) service, manages the setup
and running of I&M services
Protocols for researcher/experiment control tools to access
APIs:








Xml-rpc
web services (SOAP, WSDL)
APIs for setting up and running I&M services
APIs for MP (Measurement Point) services
APIs for MC (Measurement Collection) services
APIs for MAP (Measurement Analysis and Presentation)services
APIs for MDA (Measurement for Data Archiving) service
All traffic is carried in the GENI Control Plane
GIMS Traffic Flow
53

Option 1:


Option 2:


Carry all MD (Measurement Data) traffic flows using a dedicated
measurement VLAN
Carry all MD traffic flows using the same IP network that supports the
Control Plane.
Option 3:

Carry most MD traffic flows using the same IP network that supports the
Control Plane, but for high-rate MD traffic flows, define a dedicated
measurement VLAN for the slice/experiment
Overlaps with other WG
54

Control Framework WG


common interface for operations
Security


Experiment Workflow and Services WG



lower levels of GENI & higher level should be consistent
Operation & Management Tools
Services Usage
Instrumentation & Measurements WG


Data Acquisition
Measurements for performance and management
Relationship to GENI Architecture
55
OMIS WG focuses on
GENI operations,
management and
GENI wide view of
the projects and
experiments
Operation, Management, Integration & Security (OMIS)
Network Today…
56

Vertical integrated stacks
 Similar
D.B.
to PC in 1980s
COBOL Apps.
L3 Routing
VLANS
O.S
Switch O.S.
CPU
ASIC
IBM’s Mainframe
Cisco Routers
OMIS
57

Operation
 GMOC

(GENI Meta-Operation Center)
Management
 Meta-Management

Integration
 Overlap

System for GENI
& Interfaces with other WGs
Security
 Policies,
Authorization & Authentication
Implications of Networking…
58

Restricted to ill defined vendor CLI
 Provisioning
 VM
is slow….
provisioning: 1min
 Virtual network provisioning: 1-3 weeks
Memory of TINA
(Telecommunications Information Networking Architecture)
60
Software Defined Networking
61
Current Switch
Vertical stack
Applications
Applications
Applications
Northbound
API
Network O.S.
Applications
Applications
Network O.S.
ASIC
Southbound
API
Switch Operating System
Switch Hardware

Southbound API: decouples the switch hardware from control
function


Data plane from control plane
Switch Operating System: exposes switch hardware primitives
SDN
SDN Switch
Decoupled
stack
Implications of SDN
62
Current Networking
Applications
Applications
SDN Enabled Environment
Applications
Applications
Applications
Applications
Applications
Network O.S.
Network O.S.
ASIC
Global View
ASIC
Controller (N. O.S.)
Applications
Applications
Network O.S.
ASIC
Programmatic
Control
Southbound
API
Switch O.S
Switch HW
Switch O.S
Switch HW
Switch O.S
Switch HW
Implications Of SDN
63
Current Networking
Applications
Applications
SDN Enabled Environment
Applications
Applications
Applications
Applications
Applications
Network O.S.
Network O.S.
ASIC
Controller (N. O.S.)
ASIC
Southbound
API
Applications
Applications
Switch O.S
Switch HW
Network O.S.
ASIC
•
•
Distributed protocols
• Each switch has a brain
• Hard to achieve optimal
solution
Network configured
indirectly
• Configure protocols
• Hope protocols
converge
Switch O.S
Switch HW
•
•
Switch O.S
Switch HW
Global view of the network
• Applications can achieve optimal
Southbound API gives fine grained
control over switch
• Network configured directly
• Allows automation
• Allows definition of new interfaces
How SDN Works
64
Applications
Applications
Applications
Controller (N. O.S.)
Southbound
API
Switch O.S
Switch O.S
Switch H.W
Switch H.W
How to Pick an SDN Environment
65
Applications
Applications
Applications
How easy is it to develop
on for the
Controller platform?
What is the Southbound AP!?
Network O.S.
Southbound
API
Switch Operating System
Is the switch virtual or
physical?
Is the switch
hardware and OS
closed?
Switch Hardware
SDN
OpenFlow
67

Developed in Stanford


Standardized by Open Networking Foundation (ONF)
Current Version 1.5 (Dec. 2015)

Version implemented by switch vendors
PC
How SDN Works: OpenFlow
68
Applications
Applications
Applications
Controller (N. O.S.)
OpenFlow
OpenFlow
Switch O.S
Switch O.S
Switch H.W
Switch H.W
Southbound
API
OpenFlow: Anatomy of a Flow Table Entry
69
Match
Action
Counter
Time-out
Priority
When to delete the entry
What order to process the rule
# of Packet/Bytes processed by the rule
1.
2.
3.
4.
Switch VLAN
Port
ID
Forward packet to zero or more ports
Encapsulate and forward to controller
Send to normal processing pipeline
Modify Fields
VLAN MAC
pcp src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
L4
IP
ToS Prot sport
L4
dport
Dimension of SDN Applications:
Rule installation
70
Proactive Rules
Reactive Rules
Applications
Applications
Applications
Applications
Applications
Applications
Controller (N. O.S.)
Controller (N. O.S.)
O.S
O.S
Switch H.W
Switch H.W
Dimension of SDN Applications:
Rule installation
71
Proactive Rules

Controller pre-installs flow
table entries

Zero flow setup time
Reactive Rules
 First packet of each flow
triggers rule insertion by the
controller


Requires installation of rules for
all possible traffic patterns

Requires use of aggregate rules
(Wildcards)

Require foreknowledge of traffic
patterns

Waste flow table entries


Each flow incurs flow setup time
Controller is bottleneck
Efficient use of flow tables
Dimensions of SDN Applications:
Granularity of Rules
72
Microflow
WildCards (aggregated rules)
Applications
Applications
Applications
Controller (N. O.S.)
O.S
Switch H.W
Applications
Applications
Applications
Controller (N. O.S.)
O.S
Switch H.W
73
Dimensions of SDN Applications:
Granularity of Rules
Distributed Controller
Centralized Controller
Applications
Applications
Applications
Applications
Applications
Applications
Controller (N. O.S.)
Applications
Applications
Applications
Applications
Applications
Applications
Controller (N. O.S.)
Controller (N. O.S.)
Switch O.S
Switch HW
Switch O.S
Switch HW
Controller (N. O.S.)
Switch O.S
Switch HW
Switch O.S
Switch HW
Switch O.S
Switch HW
Switch O.S
Switch HW
Google’ B4 Application
74
•
Rule installation
•
•
Rule Granularity
•
•
Proactive
Aggregate
Distributed
•
Multiple instances
References
75


http://cseweb.ucsd.edu/~vahdat/papers/b4sigcomm13.pdf (Google B4)
www.geni.net
PC
Question and Discussion
76