1. Manageability of Future Internet
Choong Seon Hong
Kyung Hee University
April 14, 2015

2. Contents Introduction to Future Internet and its Manageability
Generic Network Management Architecture
GENI Working Groups related to Mgmt
A Basic SDN Architecture

3. Requirements for Future Internet
Integrity, authenticity, confidentiality of communication with any given peer
Security
Virtualization
Manageability
Programmability
Mobility
Seamless handoff/roaming
Identity/addressing
Virtualization of Resources
Scalability
Interoperability
Reliability
Availability
Intelligent and programmable network nodes
FCAPS
Autonomic Management 3

4. Requirements for Future Internet
Integrity, authenticity, confidentiality of communication with any given peer
Security
Virtualization
Manageability
Programmability
Mobility
Seamless handoff/roaming
Identity/addressing
Virtualization of Resources
Manageability
Scalability
Interoperability
Reliability
Availability
Intelligent and programmable network nodes
FCAPS
Autonomic Management 4

5. Management of the Current Internet5

6. Current Network Environment
INTERNET
xDSL/Cable
FTTH
PSDN
10 Gigabit
Ethernet
Satellite
SONET
PSTN
ATM
ISDN
SS#7
Fast
Ethernet
WANs
Gigabit
Ethernet
Broadcast
Networks
(DAB, DVB-T)
IN/AIN
WiBro, HSDPA
Ethernet
Bluetooth Zigbee
6LoWPAN
B-ISDN
CDMA, GSM, GPRS, LTE, LTE-A
IP-based
micro-mobility
Wireless LANs
Access Network
xDSL/Cable
PSTN
ISDN
Optical:FTTH, FTTC, FTTB 6

7. Current Network Management Framework
Collect, organize & interpret
Operational Data
Administrator
Workstation
Management Platform
Observation
& Control
mgmt requests/replies
event reports
Agent 7

8. Functional Requirements for NM
Fault Management
detection, isolation and correction of abnormal operations
Configuration Management
identify managed resources and their connectivity, discovery
Accounting Management
keep track of usage for charging
Performance Management
monitor and evaluate the behavior of managed resources
Security Management
allow only authorized access and control
FCAPS 8

9. Standard Management Frameworks
OSI Network Management Framework
CMIP (X.700 Series)
Internet Network Management Framework
SNMPv1
SNMPv2
SNMPv3
TeleManagement Forum
SID, eTOM, NGOSS
Distributed Management Task Force
CIM, WBEM
Open Mobile Alliance
OMA DM 9

10. Towards Management of the Future Internet10

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 11

12. Management for Future Internet
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 12

13. Research Efforts for Management of FI13
US NSF
Future Internet Design (FIND)
Complexity Oblivious Network Management architecture (CONMan)
Global Environment for Networking Innovations (GENI)
Operations, Management, Integration and Security (OMIS) WG EU
Framework Program (FP) 7
4WARD In-network (INM) project
Autonomic Internet (AutoI) project
Autonomic Network Architecture (ANA) project

14. 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

15. Research Efforts - EU 4WARD WP4: INM (In Network Management)
4WARD WP4: INM (In Network Management)
Autonomic self-management
Abstractions and a framework for a self- organizing management plane
Scheme, strategies, and protocols for collaborative monitoring, self-optimizing, and self-healing 15

16. Research Efforts - USA
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
OMIS 16

17. Research Efforts - Korea
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 ~ 17

18. Management for Future Internet [1]
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 18

19. Management for Future Internet [2]
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 19

20. Generic Network Management Architecture

21. 1. What is Management?
Network management is the act of initializing, monitoring and modifying the operation of the primary functions
Primary functions
Management functions
System
Action
measurement
configuration
Defined at design time
Must be standardized
Defined during operation
Action = Brainware?

22. Cost reduction Flexibility Fault handling Security 2. Why Management?
Action = Brainware?

23. Cost Reduction General purpose designs
Internet, VoIP, SCADA, Server Farms, Internet of Things, …

24. Flexibility
Changing user requirements
Bandwidth allocation

25. Flexibility: Cyclic design
Evolution versus clean-slate

26. 3. How is Management performed?
Explicit versus implicit management
Centralized versus distributed management
Meta-Management

27. 3.B Explicit versus Implicit
Explicit management
Implicit management
System
Action
measurement
configuration
Hard, Soft AND Brainware
Hard and Software
Self-management
Autonomic networking

28. From explicit to implicit management
Scripts, policies, …

29. From explicit to implicit management
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

30. 3.b Centralized versus Distributed
DNS
DHCP
SNMP
NetConf
Distributed
ZeroConf, Bonjour, …

31. From centralized to distributed management
Deficiencies centralized: single point of failure, potential performance bottleneck

32. From explicit and centralized to implicit and distributed management

33. 3.c Meta Management
SNMPv3MIB, SNMP security
Management is a moving target: in later design cycles we will have to manage the management functions from the previous cycles (meta-management)

34. Predicting the future: conclusions
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

35. Network Configuration - Overview
OpenFlow
Relation to SNMP, COPS-PR, NetConf
System
Action
Measurements
Configurations

36. Timeline Mobile Agents Active Networks Web Services 1990 1996 2002
2008
2014
SNMP
COPS-PR
NetConf
OpenFlow

37. COPS-PR *Common Open Policy Service (COPS) for Policy Provisioning(PR)
Out of profile
traffic
*Common Open Policy Service (COPS) for Policy Provisioning(PR)

38. NetConf motivation Managers need better control over routing
Routing protocols such as OSPF lack flexibility
Routing decisions should be made at a central site
Nick Feamster: ideas from 2004
IAB Workshop in 2002

39. NetConf characteristics
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
OpenFlow lijkt op COPS-PR (werkt ook op "table rows").
2) Bij Openflow 1.0 het model is een "Flow-Table"
In Openflow 1.1 kun je meerdere tables hebben,
4) Openflow heeft wel de mogelijkheid een aantal "commando's" als atomic te markeren (begin atomic / end atomic), en lijkt dus wel wat op SNMP die alle objecten binnen een set als atomic moet uitvoeren (of een row-creation)
5) Openflow heeft geen mogelijkheid ingebouwd voor commit / rollback (in tegenstelling tot Netconf)
6) Openflow 1.3 doet QoS. Daarvoor zijn "Meter Bands" (zie slide 38)
Je kunt daar traffic dat groter / kleiner is dan een x Kbps of a) droppen dan wel b) ander Diffserv code point geven
Als je nu Tiago's idee (automatisch elefant flows verplaatsen) wilt implementeren met Openflow, moet je zeggen dat verkeer > x Kbps een code point met een bepaalde waarde krijgt, en daarna je in een volgende table alles met die waarde doorstuurt naar een bepaalde lambda.

40. NetConf - Operations 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)
5) Openflow heeft geen mogelijkheid ingebouwd voor commit / rollback (in tegenstelling tot Netconf)
6) Openflow 1.3 doet QoS. Daarvoor zijn "Meter Bands" (zie slide 38)
Je kunt daar traffic dat groter / kleiner is dan een x Kbps of a) droppen dan wel b) ander Diffserv code point geven
Als je nu Tiago's idee (automatisch elefant flows verplaatsen) wilt implementeren met Openflow, moet je zeggen dat verkeer > x Kbps een code point met een bepaalde waarde krijgt, en daarna je in een volgende table alles met die waarde doorstuurt naar een bepaalde lambda.

41. OpenFlow motivation 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
Nick Feamster: ideas from 2004
IAB Workshop in 2002

42. OpenFlow characteristics
OpenFlow Protocol
Secure channel
Flow Table SW HW
OpenFlow switch
SSH
Controller
Agent
Manager
SNMP COPS-PR
NetConf
UDP
TCP
SSH
Hardware
Switch, router, …
1) het is de switch die de verbinding maakt met de controller, en niet de controller die het initiatief neemt

43. OpenFlow Client Controller PC OpenFlow Example Software Layer MAC src
Flow Table
MAC
src
dst IP
Src
Dst
TCP
sport
dport
Action
Hardware
Layer *
port 1
Bij Openflow 1.0 het model is een "Flow-Table”
Bij 1.0 kun je in de flow-table naast IP en MAC adressen ook "ports" adresseren
port 1
port 2
port 3
port 4
Source: OpenNetSummit Tutorial (10/19/2011)

44. Configuration Protocols Conclusion
OpenFlow is (yet another) configuration management protocol
OpenFlow has many similarities to:
SNMP
COPS-PR
NetConf
Granularity level of OpenFlow is:
Higher than SNMP
Same as COPS-PR
Lower than NetConf
OpenFlow somehow mixes PDUs and Data
Easier to understand
Harder to extend
Network management research community should use their expertise to improve OpenFlow design

45. Mgmt in GENI - Outline 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

46. GENI Working Groups Control Framework 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
Experiment Workflow and Services WG
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 Working Group defines what is universal across GENI components. How evolution is accommodated with or without a full transition of all GENI nodes at once. This all works at the Control Plane.
Experiment Workflow and Services WG defines what do experimenter-users need from GENI? Considers planning, scheduling, running, debugging, analyzing experiments; long running experiments & how they grow; and archiving data.
Instrumentation & Measurements WG Discusses, develops and builds consensus around the architectural framework for the instrumentation and measurement infrastructure that will be deployed and used in GENI
OMIS WG defines What are the requirements for operating GENI and managing its services? What are GENI's security requirements, both from a researcher's viewpoint and from that of its operators? Define an Operations Framework and Interfaces between GENI operations, aggregate/component management and security functions.

47. Control Framework 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
This WG is responsible for component control that is obtaining and managing resources,
slice control that is defining interfaces and mechanisms for establishing and controlling slices
access control within GENI that is usage policy representation and administration mechanisms
Federation that is interactions external to GENI
and key enablers like identities of the entities, authentication and authorization

48. Virtualization and Federation
Operation and Management
Components
Create my experiment slice, Install my software,
debug, collect data, retry, etc.
GENI
Clearinghouse
PlanetLab Aggregate
virtual machines
OpenFlow
Aggregate
layer2 switches
ProtoGENI
programmable nodes and links
GENI AM API
GENI AM (aggregate Manager) 48

49. GENI Architecture - Control Framework
The Control Framework WG focuses on component control,
slice control, access control within GENI and federation and interaction between these GENI entities
This figure shows the Control Framework relationship to GENI Architecture.
The Control Framework WG focuses on component control, slice control, access control within GENI and federation and interaction between these GENI entities

50. Instrumentations & Measurements
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)
Here we will discuss the scope of the Instrumentation and Measurement Working Group;
The WG Discusses, decides and develops the architectural framework for the instrumentation and measurement infrastructure that will be deployed and used in GENI. It is responsible for Create an architecture for measurement that enables GENI goals to be achieved, document the result and try to refine it. It facilitates dialog and coordination between teams focused on I&M. It Identifies key challenges in I&M that could otherwise inhibit the infrastructure. Gather feedback from the users and Deploys the refined instrumentation and measurement capabilities
The services need to be provided are:
Services for the measurements creation, defining which from which points, the measurements would be collected and how they would be collected. It also should provide services for measurement analysis and representation and how the data would be archived and stored.

51. Relationship to GENI Architecture
The Instrumentation and Measurement WG focuses on the instrumentation and measurement infrastructure that will be deployed and used in GENI.
This figure shows the I&M relationship to GENI Architecture.
Measure and store provides the I & M Services.
Measurement plane provides the services and for measurement services, traffic is carried by the Control Plane

52. GIMS – Protocols & Communication
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
Researcher by using Experiment Control service, including Measurement Orchestration service, manages the setup and running of I&M services
Protocols that are used by researcher/experiment control tools to access APIs are
Xml-rpc (XML based Remote procedure calls)
web services (SOAP, WSDL)
APIs for setting up and running I&M services
APIs for Measurement Point services
APIs for Measurement Collection services
APIs for Measurement Analysis and Presentation services
APIs for Measurement for Data Archiving service
All of this traffic is carried in the GENI Control Plane

53. GIMS Traffic Flow Option 1: Option 2: Option 3:
Carry all MD (Measurement Data) traffic flows using a dedicated measurement VLAN
Option 2:
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
We have three options for the traffic flow of Instrumentations & Measurements
The first option is to use a separate Virtual LAN for all Measurement Data traffic.
The second option is use the service provided by the Control plane IP Network
And the third option is to use the dedicated VLAN for high priority traffic flow for each slice or experiment and for normal Measurement Data traffic the service provided by the Control plane IP Network

54. Overlaps with other WG Control Framework WG
common interface for operations
Security
lower levels of GENI & higher level should be consistent
Experiment Workflow and Services WG
Operation & Management Tools
Services Usage
Instrumentation & Measurements WG
Data Acquisition
Measurements for performance and management
Control Framework WG: Since control-WG is defining the common interface that will be used for operations, there is a need for OMIS to make sure it has all the functions that are needed. Most of the security for the lower levels of GENI are also being defined in control-WG. There is a need to be sure they are consistent with any higher level security architecture or requirements defined by OMIS.
Experiment Workflow and Services WG: Operation & Management Tools are also used by Experiment Workflow and Services for managing the experiments’ flow and services being provided and used.
Instrumentation & Measurements WG:
Both perform Data Acquisition, analysis and gather Measurements; OMIS use these measurements for operations and management

55. Relationship to GENI Architecture
OMIS WG focuses on GENI operations, management and GENI wide view of the projects and experiments
This figure shows the OMIS relationship to GENI Architecture.
OMIS WG focuses on GENI operations, management and GENI wide view of the projects and experiments.
Operation, Management, Integration & Security (OMIS)

56. Network Today… Vertical integrated stacks Similar to PC in 1980s D.B.
O.S
CPU
COBOL Apps.
VLANS
Switch O.S.
ASIC
L3 Routing
IBM’s Mainframe
Cisco Routers

57. OMIS Operation Management Integration Security
GMOC (GENI Meta-Operation Center)
Management
Meta-Management System for GENI
Integration
Overlap & Interfaces with other WGs
Security
Policies, Authorization & Authentication
Operation, Management, Integration and Security WG defines What are the requirements for operating GENI and managing its services? What are GENI's security requirements, both from a researcher's viewpoint and from that of its operators?

58. Implications of Networking…
Restricted to ill defined vendor CLI
Provisioning is slow….
VM provisioning: 1min
Virtual network provisioning: 1-3 weeks

59. Background: Switch Internals
Physical Architecture of a Switch
Logical View of a Switch
Switching
Fabric
Processor
ASIC
AISC
data plane
control plane
Network O.S.
ASIC
Applications

60. Memory of TINA (Telecommunications Information Networking Architecture)

61. Software Defined Networking
Current Switch
Vertical stack
Applications
Northbound
API
Network O.S.
ASIC
Applications
Network O.S.
SDN
Southbound
API
SDN Switch
Decoupled stack
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

62. Implications of SDN Current Networking SDN Enabled Environment
Applications
Network O.S.
ASIC
Applications
Network O.S.
ASIC
Applications
Global View
Controller (N. O.S.)
Network O.S.
ASIC
Applications
Programmatic
Control
Southbound
API
Switch O.S
Switch HW
Switch O.S
Switch HW
Switch O.S
Switch HW

63. Implications Of SDN Current Networking SDN Enabled Environment
Network O.S.
ASIC
Applications
Network O.S.
ASIC
Applications
Controller (N. O.S.)
Applications
Southbound
API
Switch O.S
Switch HW
Network O.S.
ASIC
Applications
Distributed protocols
Each switch has a brain
Hard to achieve optimal solution
Network configured indirectly
Configure protocols
Hope protocols converge
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

64. How SDN Works Applications Controller (N. O.S.) Southbound API
Switch H.W
Switch O.S
Switch H.W
Switch O.S

65. How to Pick an SDN Environment
Applications
How easy is it to develop on for the
Controller platform?
Network O.S.
SDN
Southbound
API
What is the Southbound AP!?
Switch Operating System
Is the switch virtual or physical?
Switch Hardware
Is the switch hardware and OS closed?

66. HP, IBM, NEC, Pronto, Juniper.. and many more
The SDN Stack 66
Monitoring/ debugging tools
oftrace
oflops
openseer
ENVI (GUI)
LAVI
n-Casting …
Applications
NOX
Beacon
Trema
FloodLight …
Controller
Slicing
Software
FlowVisor
Console
FlowVisor
There are components at different levels that work together in making it work
Commercial Switches
Software
Ref. Switch
NetFPGA
Broadcom
Ref. Switch
HP, IBM, NEC, Pronto, Juniper.. and many more
OpenFlow
Switches
OpenWRT
PCEngine WiFi AP
Open vSwitch 66
Source: SDN Tutorial by B. Heller
Open Networking Summit, April 2012

67. OpenFlow Developed in Stanford
Standardized by Open Networking Foundation (ONF)
Current Version 1.5 (Dec. 2015)
Version implemented by switch vendors PC

68. How SDN Works: OpenFlow
Applications
Controller (N. O.S.)
OpenFlow
Southbound
API
OpenFlow
Switch H.W
Switch O.S
Switch H.W
Switch O.S

69. OpenFlow: Anatomy of a Flow Table Entry
Match
Action
Counter
Priority
Time-out
When to delete the entry
What order to process the rule
# of Packet/Bytes processed by the rule
Forward packet to zero or more ports
Encapsulate and forward to controller
Send to normal processing pipeline
Modify Fields
Switch
Port
VLAN ID
VLAN
pcp
MAC
src
MAC
dst
Eth
type IP
Src IP
Dst IP
ToS IP
Prot L4
sport L4
dport

70. Dimension of SDN Applications: Rule installation
Proactive Rules
Reactive Rules
Controller (N. O.S.)
Applications
Switch H.W
O.S
Controller (N. O.S.)
Applications
Switch H.W
O.S

71. Dimension of SDN Applications: Rule installation
Proactive Rules
Reactive Rules
Controller pre-installs flow table entries
Zero flow setup time
Requires installation of rules for all possible traffic patterns
Requires use of aggregate rules (Wildcards)
Require foreknowledge of traffic patterns
Waste flow table entries
First packet of each flow triggers rule insertion by the controller
Each flow incurs flow setup time
Controller is bottleneck
Efficient use of flow tables

72. Dimensions of SDN Applications: Granularity of Rules
Microflow
WildCards (aggregated rules)
Applications
Controller (N. O.S.)
Applications
Switch H.W
O.S
Controller (N. O.S.)
Switch H.W
O.S

73. Dimensions of SDN Applications: Granularity of Rules
Distributed Controller
Centralized Controller
Controller (N. O.S.)
Applications
Controller (N. O.S.)
Applications
Switch O.S
Switch HW
Controller (N. O.S.)
Applications
Controller (N. O.S.)
Applications
Switch O.S
Switch HW
Switch O.S
Switch HW
Switch O.S
Switch HW

74. Google’ B4 Application Rule installation Rule Granularity Distributed
Proactive
Rule Granularity
Aggregate
Distributed
Multiple instances

75. References
sigcomm13.pdf (Google B4) PC

76. Question and Discussion