SISTEME SW DE MANAGEMENT SI

CONTROL INTEGRAT AL RETELELOR SI

SERVICIILOR

Master an II sem1
2015- 2016
Specializari: TSAC
(v0.5)

SWMC-Master TSAC2-2015-2016 page 1

CONTENTS

1 INTRODUCTION IN NETWORK MANAGEMENT 4

1.1 INTRODUCTION OF NETWORK MANAGEMENT (NM) 4
1.1.1 Network Management Definition 4
1.1.2 NM objectives 4
1.1.3 Basic Components of Network Management System 5
2 TELECOMMUNICATION NETWORK MANAGEMENT SUMMARY 11
2.1 INTRODUCTION 11
2.2 TRADITIONAL TMN FUNCTIONAL ARCHITECTURE 13
2.2.1 TMN Function Blocks 13
2.2.2 TMN Functionalities 16
2.2.2.1 Management Application Functionality (MAF) 16
2.2.2.2 Support Functionality 16
2.2.2.3 TMN reference points (RP) 16
2.2.3 Layered Architecture 18
2.2.3.1 Physical Architecture 18
2.2.3.2 Information Architecture 19
2.2.3.3 Logical Layered Architecture 19
2.3 NOVEL ARCHITECTURES OF TELECOM NETWORKS (NGN) 25
2.3.1 General characteristics 25
2.3.2 NGN-Architecture: Management and control 26
2.3.2.1 Architectural Planes 26
2.3.2.2 Architectural layers: vertical and horizontal decomposition 27
2.3.2.2.1 Transport Stratum Functions 28
2.3.2.2.2 Service Stratum Functions 30
2.3.2.2.3 Management Functions 30
2.3.2.2.4 End-User Functions 31
3 CURRENT INTERNET MANAGEMENT ARCHITECTURE 32
3.1 INTERNET MANAGEMENT FRAMEWORK- SUMMARY 32
3.1.1 SNMP Framework Components 33
3.1.2 SNMP Entities 33
3.2 REMOTE NETWORK MONITORING 35
3.2.1 RMON1 35
3.2.1.1 Capabilities of RMON1 37
3.2.2 RMON2 38
3.2.2.1 RMON2Capabilities 38
3.3 COMPARISON OF TMN- AND INTERNET-BASED MANAGEMENT ARCHITECTURE 39
3.3.1 CommonManagement Information Protocol (CMIP) 41
3.3.1.1 The CMIP over the OSI Management Architecture 42
3.3.1.2 CMIP Over TCP/IP (CMOT) Management Architecture 44
3.4 SNMP DETAILS 46
3.4.1 Architecture 46
3.4.1.1 SNMP Entity 47
3.4.2 SNMP Messages 49
3.4.3 SNMPv1 55
3.4.3.1 SNMPv1 Protocol Operations 56
3.4.4 SNMPv2 57
3.4.4.1 SNMPv2 Protocol Operations 57
3.4.5 SNMPv3 58
3.4.6 Recent Advances in SNMP 59
3.4.7 Example of a Monitoring system architecture of a core IP domain manager 62

SWMC-Master TSAC2-2015-2016 page 2

4 AUTONOMIC NETWORK MANGEMENT 65
4.1 AUTOMATIC, AUTONOMOUS, AND AUTONOMIC SYSTEMS 65
4.1.1 Definitions 65
4.1.2 IBMS APPLICATION OF AUTONOMICS TO COMPUTERS 65
4.1.2.1 Levels of autonomy (IBM) 65
4.1.2.2 IBM AUTONOMICS COMPUTING 66
4.1.2.2.1 Architecture of an Autonomic System 67
4.2 AUTONOMIC NETWORK MANGEMENT SYSTEM (ANMS) 69
4.2.1 Introduction 69
4.2.2 General ANM Features 69
4.2.3 IRTF Autonomic Networking Model 72
4.2.3.1 Definitions 72
4.2.3.2 IRTF Autonomic Reference Model 73
4.2.4 Industry view of autonomic management 74
4.2.5 Building a Network Knowledge Data Base for ANMS 75
4.2.5.1 Knowledge typology in ANMS 76
4.2.5.2 Approaches to network and system modeling 77
5 POLICY BASED MANAGEMENT 83
5.1 INTRODUCTION 83
5.2 PBM ARCHITECTURE 84
5.3 POLICY BASED NETWORK MANAGEMENT (PBNM) 86
6 SOFTWARE DEFINED NETWORKING TECHNOLOGY- SUMMARY 87
6.1 INTRODUCTION 87
6.1.1 Current network technologies limitations 87
6.1.2 Requirements for new network architectures 88
6.1.3 SDN approach main features 89
6.1.4 Earlier technologies related to SDN 90
6.2 SDN BASIC ARCHITECTURE 91
6.3 SDN APPLICATIONS 95
6.3.1 Enterprise Networks 95
6.3.2 Data Centers 95
6.3.3 Service Provider -SDN Approach 97
6.3.3.1 Policy Based Dynamic Servicer Chaining - example 98
6.3.3.2 Bandwidth on Demand ( BWoD)- Example 100
6.4 SDN OPENFLOW SUMMARY 101
6.4.1 ONF Key Definitions for OF switch (partial list) 101
6.4.2 OpenFlow switch components and basic functions 103
6.4.3 OpenFlow Protocol summary 108
7 REFERENCES 114

SWMC-Master TSAC2-2015-2016 page 3

1 INTRODUCTION IN NETWORK MANAGEMENT

1.1 Introduction of Network Management (NM)

1.1.1 Network Management Definition

Network management (NM): execution of the set of functions required for controlling, planning,
allocating, deploying, coordinating, and monitoring the resources of a telco/computer network
including functions such as:
initial network planning,
frequency and channels allocation
predetermined traffic routing to support load balancing
cryptographic key distribution authorization
management of : configuration, fault, security, performance, accounting
Generally, network management does not include user terminal equipment.

NM ensures the effective and efficient operations of a system within its resources in accordance
with corporate goals, through: controlling network resources and services, monitoring network
states and reporting network status and anomalies.
NM : activities, methods, procedures, and tools that pertain to the operation, administration,
maintenance, and provisioning of networked systems

1.1.2 NM objectives
Managing system resources and services
includes control, monitor, update, and report of system states, device configurations, and
network services.
Simplifying systems management complexity
extrapolate systems management information into manageable form by humans
Conversely, management systems should interpret high-level management objectives
and translate them in low level commands

Providing reliable services

high quality of service and to minimize system downtime.
distributed management systems should detect and fix network faults and errors.
NM must safeguard against all security threats.

Maintaining cost consciousness

keep track and report the usage of system resources and network users activities.

OAM
-------
Operation
keeps the network (and the network services) up and running smoothly. It includes
monitoring the network to discover problems ideally before users are affected.

Administration

SWMC-Master TSAC2-2015-2016 page 4

 keep track of network resources and how they are assigned. It includes all the
housekeeping that is necessary to keep the network under control.

Maintenance
performing repairs and upgrades
o Examples: equipment replacement, SW upgrades (e.g. patch OS image when a
new switch is added to a network
preventive and corrective/reactive measures to make the managed network run better,
such as adjusting device configuration parameters.

Provisioning
configuring resources in the network to support a given service.
o Example: setting up the network so that a new customer can receive voice service.

1.1.3 Basic Components of Network Management System

NM main components: a managing center, a managed device, and a NM protocol.

Managing center (MngC): network administrator and his facilities.

Managed device (MngD): network equipment, including its SW, that is controlled by the
MC (hub, bridge, router, server, printer, modem, mux/demux, etc.)
NM protocol (NM_prot) - MngC configures the MngDs and gets its status (e.g. SNMP,
CMIP)

MANAGING MANAGED SYSTEM

SYSTEM

Transfer of
management
Manager information and Agent
notifications

Managed objects

Figure 1-1 Basic Management Model

Two NMS primary elements :

Manager : console through which the network administrator performs NM functions. A

manager can be a network administrative device, as a management host.

Agents : entities interfacing to the actual device being managed.

o An agent can use the NM protocol to inform the MngC of an unexpected event.

SWMC-Master TSAC2-2015-2016 page 5

Examples of MDs containing managed objects: bridges/switches, hubs, routers or network
servers, etc.

The managed objects might be : HW, configuration parameters, performance statistics, etc.,
directly related to the current operation of the device.

The objects are arranged in a virtual info database, called a management information base
(MIB)

Internet RFCs and other docs - specify a typical distributed management system containing:

Network elements (NE): Equipments communicate within the network, (according to

ITU-T stds, etc.) with the purpose of being monitored or controlled (also called MDs)
o NE: HW devices - computers, routers, and terminal servers connected to
networks.
o NE is a network node containing an SNMP agent, which resides on a managed
network.
o
Manager: generates commands and receives notifications from agents.
There are usually only a few managers in a system.

Agents: collect and store mng. info (e.g. number of error packets received by an NE)
o has local knowledge of mng. info and transforms it in to the form compatible with
SNMP.
o responds to commands from the manager and sends notification to the manager.
o There are potentially many agents in a system.

Managed object: a vision of a feature of a network, from the point of view of the
management system
o All physical and logical resources (e.g. signaling terminals, routes, event logs,
alarm reports and subscriber data), are seen as managed objects.
o E.g. : a list of current active TCP connections in a particular host computer

o Managed objects differ from variables, which are particular object instances.

o Managed objects can be

scalar (defining a single object instance)
or tabular (defining multiple and related instances).

Note: In literature, managed object is sometimes used interchangeably with managed
element.

NM Stations (NMSs): (sometimes called consoles).

o execute management applications that monitor and control network elements
o Physically, NMSs are usually engineering workstation/ computers with fast
CPUs, large color displays, large memory and disk space
o At least one NMS must be present in each managed environment.

Management protocol
o Conveys mng. info between agents and NMSs

SWMC-Master TSAC2-2015-2016 page 6

 o Simple NM Protocol (SNMP) = Internet communitys de facto standard
management protocol.

Structure of Management Information (SMI)

The (SMI) language defines the rules for naming objects and to encode objects in a managed
network center.
SMI is a language by which a specific instance of the data in a managed network center is
defined.

SMI subdivides into three parts: definition of- modules, objects and notifications

o Module definitions describes information modules.

An ASN.1 (Abstract Syntax Notation) macro, called MODULE-
IDENTITY, is used to concisely convey the semantics of an information
module

o Object definitions describe managed objects.

An ASN.1 macro, OBJECT-TYPE, concisely conveys the syntax and
semantics of a managed object

o Notification definitions (also known as traps) describe unsolicited transmissions

of management information.
An ASN.1 macro, NOTIFICATION-TYPE, concisely conveys the syntax
and semantics of a notification.

Management Information Base (MIB)

o (MIB) is a DB , coming from the OSI/ISO NM model

o MIB = collection of objects in a (virtual) DB used to manage network entities

o MIB Objects are defined using a subset of

Abstract Syntax Notation One (ASN.1) called Structure of

Management Information Version 2 (SMIv2) RFC 2578

o The software that performs the parsing is a MIB compiler

o The database is hierarchical (tree-structured) and entries are addressed through

object identifiers [Mi07].

SWMC-Master TSAC2-2015-2016 page 7

Figure 1-2: ASN.1 Object Identifier Organized Hierarchically ( partial view)

Three entries at the root:

1. ISO, (International Standardization Organization),
2. ITU-T (International Telecommunication Union Telecommunication) standardization
sector,
3. and ISO-ITU-T, the joint branch of these two organizations

ISO entry has branches.

Examples:
- the organization (3) branch is labeled sequentially from the root as 1.3.
- a path over dod (6), Internet (1), management (2), mib-2 (1), and ip (4). is identified by
(1.3.6.1.2.1.4) to indicate all the labeled numbers from the root to the ip (4) entry.

Besides that entry, MIB module represents a number of network interfaces and well known
Internet protocols at the bottom of this tree.

This path shows all the standards of IP associated with the MIB-2 computer networking
management.

IETF Standards: RFCs ( very old)

RFC 1155, Structure and Identification of Management Information for TCP/IP based
internets, and its two companions

SWMC-Master TSAC2-2015-2016 page 8

 RFC 1213, Management Information Base for Network Management of TCP/IP-
based internets,
RFC 1157, A Simple Network Management Protocol.

Figure 1-3 Typical Network Management Architecture

Interactions between NMSs and MDs can be any of four different types of commands:
read, write, traverse, and trap.

Read: To monitor MDs , the NMSs read variables maintained by the devices.
Write: To control MDs , NMSs write variables stored within the MDs.
Traverse: NMSs use these operations
1. to determine which variables a managed device supports and
2. to sequentially gather information from variable tables (e.g. IP routing tables) in MDs
Trap: MDs use traps to asynchronously report certain events to NMSs.

Most NM architectures use the same basic structure and set of relationships.

End stations (managed devices), run SW enabling them to send alerts when they recognize
problems.

Mng. entities are programmed to react upon receiving alerts, by executing one, several, or a
group of actions, including
1. operator notification 2.event logging 3.system shutdown automatic attempts at system
repair.

Management entities can also poll end stations to check the values of certain variables.
Polling can be automatic or use initiated, but agents in the managed devices respond to
all polls.

Agents: SW modules that

1. first compile information about the managed devices in which they reside
2. then store this information in a management database,
3. and finally provide it (proactively or reactively) to management entities within network
management systems (NMSs) via a network management protocol.

SWMC-Master TSAC2-2015-2016 page 9

Well-known NM protocols
1. Simple Network Management Protocol (SNMP) (v.1, v.2, v.3)
2. Common Management Information Protocol (CMIP)

Management proxies: entities that provide management information on behalf of other entities.
Networks:
1. circuit swithching ( classic - telecommunications) networks ( ISDN, GSM)
2. packet networks (mainly IP - based), 4G, 5G
3. hybrid integrated networks ( e.g 3G)

Current NM solutions are defined by - ITU-Ts and IETF

1. Telecommunication Management Network (TMN) teleco networks (ITU-T)

2. Simple Network Management Protocol (SNMP) for IP networks (IETF)

SWMC-Master TSAC2-2015-2016 page 10

2 TELECOMMUNICATION NETWORK MANAGEMENT SUMMARY

2.1 Introduction
Framework defined after 1990
- ITU M.3000, M3010 ( 2000) recommendation series defined Telecommunication
Management Network (TMN), built on standards (OSI) (for public networks)
- TMN objectives:
- functionality in a multi-vendor environment;
- optimization of network functionality.

Important Note: the classical semantic of the TMN means Telecommunication Management
Network i.e. a special data network constructed to manage the telecom network itself.

Objectives:
telecommunication network be able to provide customers with the services they
demand and satisfaction
operator to have these services provided at the lowest possible cost.

TMN :
manages telco networks, (transportation backbones, aggregation, to access networks)
provides a structured framework for enabling interconnectivity and communication
across heterogeneous OSs and telecommunications networks.

ITU M.3000 rec. series cover a set of standards including

o (CMIP)- common management information protocol
o (GDMO)- guideline for definition of managed objects
o (ASN.1)- Abstract syntax notation one

Rec.M.3010 defines the general TMN management concepts

Rec. M.3010 introduces several management architectures at different levels of
abstraction.
o A functional architecture: describes a number of management functions.

o A physical architecture: defines how mng. functions may be implemented into

physical equipment.

o An information architecture: describes concepts adopted from OSI management

o A logical layered architecture (LLA): a model showing how mng. can be

structured according to different responsibilities.

SWMC-Master TSAC2-2015-2016 page 11

SWMC-Master TSAC2-2015-2016 page 12
Figure 2-1 ITU-T M3000 Recommendations

Figure 2-2 Interfaces of the classic TMN- Telcomm network

2.2 Traditional TMN Functional Architecture

2.2.1 TMN Function Blocks

Initial definitions ( M3010/1996)
Five different types of function blocks are defined
It is not necessary that all of these types are present in each possible TMN configuration.
Most TMN configurations will support multiple function blocks of the same type.

Completely specified in TMN

Partially specified in TMN

Figure 2-3 TMN Functional Blocks

OSF: Operations System Functions; MF: Mediation Functions;

WSF: Work Station Functions; NEF: Network Element Functions; QAF: Q Adaptor
Functions

SWMC-Master TSAC2-2015-2016 page 13

 OSF and MF are completely specified by the TMN recommendations.
WSF, NEF, and QAF: only parts of these function blocks are specified by TMN.

TMN arch.: concept of reference point (RP) to delineate function blocks:

Five different classes of reference points are identified

(q, f, and x) are completely described in the TMN rec.
the other classes (g , m) are outside the TMN and only partially described.

Figure 2-4 Example of RPs between Function Blocks (initial definitions)

Revised definitions M3010/2000

The TMN functional architecture is structured from the following fundamental elements:
function blocks;
Management Application Functions (MAFs);
TMN Management Function Sets and TMN Management Functions;
reference points.

Some of the function blocks are partly in and partly out of a TMN; these TMN function blocks
also perform functions outside of the TMN

The TMN function block is the smallest deployable unit of TMN management functionality.

If the TMN function block contains a Management Application Function, it may only contain
one MAF

SWMC-Master TSAC2-2015-2016 page 14

Figure 2-5 Revised TMN functional architecture
Operations Systems Function (OSF) block
- processes information related to the TM for the purpose of monitoring/coordinating
and/or controlling telecom functions including management functions (i.e. the TMN itself).

Network Element Function (NEF) block

- communicates with the TMN for the purpose of being monitored and/or
controlled.
- provides the telecom and support functions required by the telecom network being
managed.
- includes the managed telecomm functions
These functions are not part of the TMN but are represented to the TMN
by the NEF
The part of the NEF that provides this representation in support of the
TMN is part of the TMN itself, whilst the telecomm functions themselves
are outside.

Workstation Function (WSF) block

- provides the means to interpret TMN information for the human user, and vice
versa.
- translate between a TMN RP and a non-TMN RP and hence a portion of this
function block is shown outside the TMN boundary.

Transformation Function (TF) block

- provides functionality to connect two functional entities with incompatible
communication mechanisms.
- Such mechanisms may be protocols or information models or both.

NOTE The TF consolidates and extends the functionality and scope associated with the
Mediation and Q Adaption function blocks in Recommendation M.3010 (05/96).

The TF may be used

- anywhere within a TMN or

SWMC-Master TSAC2-2015-2016 page 15

 - anywhere at the boundary of a TMN.

Use cases of a TF:

Within a TMN, the TF connects two FBs, each of which supports a standardized, but
different, communication mechanism.

At the boundary of a TMN, the TF may be used either as communication between two
TMNs or between a TMN and a non-TMN environment.

At the boundary of two TMNs the TF connects two FBs , one in each TMN, each of which
supports a standardized, but different, communication mechanism.

When the TF is used between a TMN and a non-TMN environment, the TF connects a
function
block with a standardized communication mechanism in a TMN to a functional entity
with a
non-standardized communication mechanism in the non-TMN environment.

2.2.2 TMN Functionalities

2.2.2.1 Management Application Functionality (MAF)

The (MAF) represents (part of) the functionality of one or more TMN management services.
ITU-T Recommendations M.32xx-series enumerates the MAFs
The (MAF) may be identified with the type of TMN function block in which they are
implemented. The following MAF may be identified:
Operations Systems Functionality (OSF-MAF);
Network Element Functionality (NEF-MAF);
Transformation Functionality (TF-MAF);
Work Station Functionality (WSF-MAF).

2.2.2.2 Support Functionality

Support functions may optionally be found in a TMN FB.
The support functionality is potentially common to more than one TMN FB
Some support functionality assist the MAF within a TMN FB in its interactions with other FBs
Examples of such functionality include: data communication; - workstation support ; user
interface
directory system ; database; security; message communication

2.2.2.3 TMN reference points (RP)

A TMN RP defines that function block's service boundary.
This external view of functionality is captured in the set of TMN Management functions that will
have visibility from the function block.
RPs can represent the interactions between a particular pair ofFBs.

SWMC-Master TSAC2-2015-2016 page 16

Table 2-1 relationships between the FBs in terms of the RPs.

The RP concept represents the aggregate of all of the:

- abilities that a particular FB seeks from another particular FB,
- operations and/or notifications (as defined in ITU-T Recommendation X.703 [3])
that a FB can provide to a requesting FB

A RP reference point usually corresponds to PHY I/F the FBs are implemented in different
PHY blocks.

Figure 2-6 Reference point classes

Classes of RPs between
OSF, TF and NEF: q
OSF and a WSF: f
OSFs of two TMNs or between the OSF of a TMN and the equivalent OSF-like
functionality of another network: x

SWMC-Master TSAC2-2015-2016 page 17

In addition there are two further classes of non-TMN reference points which are relevant to
consider:
g Class between a WSF and users.
m Class between a QAF and non-TMN managed entities.

2.2.3 Layered Architecture

2.2.3.1 Physical Architecture

TMNs physical architecture is defined at a lower abstraction level than TMNs functional
architecture.
Function architecture
( describe different TMN functions)

PHY architecture
(defines how the various TMN
management functions can be
implemented into physical equipment)

Figure 2-7 First vertical functional split

The physical architecture shows how function blocks should be mapped upon building
blocks (physical equipment) and reference points upon interfaces.
In fact, the physical arch. defines how FBs and RPs can be implemented.
Note: one FB may contain multiple functional components and one building block may
implement multiple function blocks.

SWMC-Master TSAC2-2015-2016 page 18

Figure 2-8: Relation between TMN Architectures

2.2.3.2 Information Architecture

TMNs information architecture uses an object oriented approach ; is based on OSIs
Management Information Model [ISO93]
o the mgmt. view of a managed object is visible at the managed object boundary.
At this boundary, the management view is described in terms of:
o Attributes, which are the properties or characteristics of the object.
o Operations, which are performed upon the object.
o Behavior, which is exhibited in response to operations.
o Notifications, which are emitted by the object.

Figure 2-9 A Managed Object concept

The managed objects reside within managed systems, which include agent functions to
communicate with the manager.
TMN uses the same manager agent concept as OSI.

2.2.3.3 Logical Layered Architecture

TMN defines a hierarchy of logical layers:

SWMC-Master TSAC2-2015-2016 page 19

Figure 2-10 Layered Architectural Management Model and Function Areas (FCAPS)

The classic TMN functionalities: 5 major areas of management

F: fault
C: configuration
A: accounting
P: performance
S: security.

SWMC-Master TSAC2-2015-2016 page 20

Figure 2-11 Layers and Reference Points

Network Elements Layer (NEL):

involved with the mgmt functionality that network element itself supports,
independent of any management system.

Element Management Layer (EML):

involves managing the individual devices in the network and keeping them running.
includes functions
o to view and change a network elements configuration,

o to monitor alarm messages emitted from elements in the network,

o to instruct network elements to run self-tests.

The EML manages each network element on an individual or group basis and supports an
abstraction of the functions provided by the NEL.

The EML has one or more element OSFs, that are individually responsible, on a devolved basis
from theNML , for some subset of network element functions.

EML provides to its upper layer NML a vendor independent view

The EML roles:

1) Control and coordination of a subset of NEs on an individual NEF basis.
a. the element OSFs support interaction between the NML and the NEL by
processing the management information exchanged between network OSFs and
individual NEFs.
b. Element OSFs should provide full access to NE functionality.
2) The EML may also control and coordinate a subset of network elements on collective
basis.

3) Maintaining statistical, log and other data about elements within its scope of control.

Implementation:
An Element Management System (EMS) contains the systems and applications to manage
network elements (NE) belonging to NEL

ITU-T: the EMS key functionality is divided into five key areas :
- Fault, Configuration, Accounting, Performance , Security (FCAPS).

Portions of each of the FCAPS functionality fit into the TMN models.
EMS interfaces
- Upper: to Network Management Systems and or Service Management Systems depending
on the deployment scenario.
-Lower : to the devices.

SWMC-Master TSAC2-2015-2016 page 21

 Network Management System, (NMS)
or Service Management System, (SMS)

Element Management System

(EMS)

Managed Managed Managed Managed

Device Device Device Device

Figure 2-12 EMS Interfaces

Typically, the EMS
1. manages the functions and capabilities within each NE
2. but does not manage the traffic between different NEs in the network.

The EMS provides the foundation to implement TMNlayered operations support system
(OSS) architectures that enabling SPs:
to meet customer needs for rapid deployment of new services,
achieve quality of service (QoS) requirements.
The TeleManagement Forum Common Object Request Broker Architecture (CORBA)
EMStoNMS interface realizes desired OSS interoperability by making the TMN architecture a
practical reality.

Note: CORBA is a very complex system. In last years it is less used- - other technologies are
emerging.

Network Management Layer (NML):

Manages relationships and dependencies between network elements, to maintain E2E

connectivity of the network.
It is concerned with keeping the network running as a whole.
NML uses the sevices offered by EML and creates its own functions on top of EML.
EML manages of every element in the network,but it does not cover functions that deal
with ensuring overall network integrity.

The NML has the responsibility for the management of a network as supported by the element
management layer.
At this layer, functions addressing the management of a wide geographical area are located.

Complete visibility of the whole network is typical and, as an objective, a technology

independent view will be provided to the service management layer.

The NML roles:

SWMC-Master TSAC2-2015-2016 page 22

1) The control and coordination of the network view of all network elements within its scope or
domain.

2) The provision, cessation or modification of network capabilities for the support of service to
customers.

3) The maintenance of network capabilities.

4) Maintaining statistical, log and other data about the network and interact with the service
manager layer on performance, usage, availability, etc.

5) The network OSFs may manage the relationships (e.g. connectivity) between NEFs.

Example 1:
o In a network individual element configurations are ok but that they do not match
up properly with each-other the network does not work as intended.
o E.g.:
to configure a path across the network, each node must be configured
properly, considering the whole path properties
Likewise, timer values need to be tuned to avoid excessive timeouts and
retransmissions.

Example 2:
o Random Early Detection (RED) method is used to prevent congestion by
starting to drop randomly some packets when the average buffer fill crosses a
given threshold in a router

Pd
1

Pmax
Avg
Drop Min_th

min_th Max_th
Max_th

accept Probabilistic Drop all Buf_Size

drop

Figure 2-13 Basic RED behaviour diagram

In a chain or routers the thresholds should be correlated, otherwise it is possible to get worse
results than in a system without RED activated.

SWMC-Master TSAC2-2015-2016 page 23

 NML monitoring tasks assures that data flows reaches its destination with acceptable
throughput and delay.

Policies that makes admission control (AC) of calls at network entry points should be
coordinated across the network to be effective (otherwise a lack of resources can be
encountered despite that at each entry point an AC is applied)

o Example 1: a local/independent decision of an AC block ( i.e at an ingressI/F of

an edge node of the network) is not sufficient to guarantee that the network
domain will be not overloaded
o Example 2 : a chain of segments needing a given E2E bandwidth -> need to
assure the bandwidth on each segment.
o NM task example: connection management i.e. setup , monitor, release a
network connection

NML includes
o Actions for managing devices that are configured individually
o but ensures
that their configurations are coordinated
and monitoring for cross-network connectivity,

Service Management Layer (SML):

SML manages the network services and ensures the services functioning as intended.
SML tasks are built on top of NML

SML is responsible for, the contractual aspects of services that are being provided to customers
or available to potential new customers.
Some of the main functions of this layer are service order handling, complaint handling and
invoicing.

Roles:
1) customer facing (Note) and interfacing with other PTOs/ROAs;
2) interaction with service providers;
3) maintaining statistical data (e.g. QOS);
4) interaction between services.

Example : a customer orders a service, the service needs to be turned up.

o A new employee in an enterprise needs phone service.
o Turning up phone service a number of management operations so that the
service is activated:
A phone number must be allocated.
The company directory must be updated.
Voicemail servers and IP PBXs need to be made aware of the new
extension.
Later, the user might call the service help desk and complain that the
service is not working properly.
o Problems could include poor voice quality and calls that disconnected
unexpectedly.

SWMC-Master TSAC2-2015-2016 page 24

 o Troubleshooting the service is required to identify the root cause of the problem
and solve it.

Business Management Layer (BML):

BML manages the business associated with providing services and all the required
support functions.
Topics : billing and invoicing, helpdesk management, business forecasting, etc..
o Forecasting is important in order to plan the future network dimensioning

Roles:
1) supporting the decision-making process for the optimal investment and use of new
telecommunications resources;
2) supporting the management of OA&M related budget;
3) supporting the supply and demand of OA&M related manpower;
4) maintaining aggregate data about the total enterprise.

TMN concept is popular, and used in various implementations of network management

technologies
Typical representatives of TMN applications: CMIP- and CORBA-based
management

2.3 Novel architectures of Telecom Networks (NGN)

2.3.1 General characteristics

ITU-T Y.2001 : general definition of the Next Generation Networks ( 2002 -2005)

NGN): A packet based network able to provide telecom services and able to make use of
multiple
broadband QoS-enabled transport technologies and in which service-related functions are
independent from underlying transport-related technologies.

Main features:
packet-based network
able to provide Telecommunication multiple services
able to make use of multiple broadband,
QoS-enabled transport technologies
service-related functions are independent from underlying transport-related technologies.
enables unfettered access for users to networks and to competing service providers and/or
services of their choice.
supports generalized mobility which will allow consistent and ubiquitous provision of
services to users.

Key requirements of an NGN Architecture

Trust: Operator should be able to trust the network. User should be able to trust the
operator
Reliability: Users should find it reliable
Availability: Network should always be available

SWMC-Master TSAC2-2015-2016 page 25

 Quality: Able to control Quality of the Service
Accountability: Determine usage of the Service
Legal: Comply with laws in the local jurisdictions
Generalized Mobility support
Note: Classical Internet cannot respond in very controllable manner to the above requirements

NGN characteristics

NGN: new telecommunications network for broadband fixed access

facilitates convergence of networks and services
enables different business models across access, core network and service domains
it is an IP based network
IETF Session Initiation Protocol (SIP) will be used for call & session control
3GPP release 6 (2004) IMS will be the base for NGN IP Multimedia Subsystem
enables any IP access to Operator IMS; from
Mobile domain
Home domain
Enterprise domain
enables service mobility
enables interworking towards circuit switched networks
maintains Service Operator control for IMS signaling & media traffic

2.3.2 NGN-Architecture: Management and control

2.3.2.1 Architectural Planes

Management
SCN Applications and Plane
Service Level
Control
Plane
Transport Level
INTERNET User (Data)
Plane

Figure 2-14 NGN Generic Architecture

SCN Switched Circuit Network
Recall:
Data plane ( DPl)- transport of user data traffic directly:
o Examples of functions: traffic classification, packet marking traffic policing,
traffic shaping, buffer management, congestion avoidance, queuing and
scheduling
o transfer the user data flows and accomplish the traffic control mechanisms to
assure the desired level of QoS

SWMC-Master TSAC2-2015-2016 page 26

 Control plane (CPl)
o controls the pathways for user data traffic: e.g. Admission control, Routing,
Resource reservation.
o short term actions for resource and traffic engineering and control, including
routing. In multi-domain environment the MPl and also CPl are logically divided
in two sub-planes: inter-domain and intra-domain. This approach allows each
domain to have its own management and control policies and mechanisms.
Management plane (MPl)
o the operation, administration, and management aspects of the resources and
services to serve user data traffic: Monitoring, Management Policies
(management based not on fixed configuration of network elements but on set of
rules), Service Management, Service and network restoration.
o long term actions related to resource and traffic management in order to assure the
desired QoS levels for the users and also efficient utilization of the network
resources

2.3.2.2 Architectural layers: vertical and horizontal decomposition

Figure 2-15 NGN layered architecture [4]

The NGN functions are divided into service and transport strata according to
Recommendation Y.2011.
End-user functions are connected to the NGN by the user-to-network interface (UNI),
other networks are interconnected through the network-to-network interface (NNI).
Clear
identification of the UNI and NNI is important to accommodate a wide variety of off-
the-shelf

SWMC-Master TSAC2-2015-2016 page 27

 customer equipment while maintaining business boundaries and demarcation points in
the NGN
environment.
The application-to-network interface (ANI) forms a boundary with respect to third-
party application providers.

2.3.2.2.1 Transport Stratum Functions

- provide connectivity for all components and physically separated functions within the
NGN.
- IP is recognized as transport technology for NGN.
- transport stratum provides IP connectivity for both end-user equipment outside the
NGN, and controllers and enablers that usually reside on servers inside the NGN.
- provides end-to-end QoS, (desirable NGN feature)
-
- The transport stratum is divided into access networks and the core network, with a
function linking the two portions.

Access Functions
- manages end-user access to the network
- access-technology-dependent ( W-CDMA, xDSL, Cable access, Ethernet, optical, etc.)
such as wideband code-division multiple

SWMC-Master TSAC2-2015-2016 page 28

Figure 2-16 NGN Functional Architecture [4]
Access Transport Functions(Data Plane)
transports information across the access network.
- provide QoS control mechanisms dealing directly with user traffic: buffer management,
queuing and scheduling, packet filtering, traffic classification, marking, policing, and shaping.

Edge Functions used for traffic processing when access traffic is merged into the core
network.

Core Transport Functions (Data Plane) ensuring information transport throughout the core
network.
- provide the means to differentiate the quality of transport in the network, according to
interactions with the transport control functions.
- provide QoS mechanisms dealing directly with user traffic: buffer management,
queuing and scheduling, packet filtering, traffic classification, marking, policing and shaping,
gate control, and firewalls.

Network Attachment Control Functions (NACF)

- provide registration at the access level and initialization of end-user functions for
accessing NGN services.
- provide network-level identification/authentication
- manage the IP address space of the access network, and authenticate access sessions
- announce the contact point of the NGN service and application functions to the end
user.
-i.e. NACF assist end-user equipment in registering and starting use of the NGN.

Resource and Admission Control Functions (RACF)

- provide AC and gate control functionalities, including control of network address and
port translation (NAPT) and differentiated services field code points (DSCPs).
- AC involves checking authentication based on user profiles, through the network
attachment control functions.
- It also involves authorization based on user profiles, (cf. operator-specific policy
rules and resource availability: AC function verifies whether a resource request (e.g., for
bandwidth) is allowable given the remaining resources, as opposed to resources that are
already provisioned or used).

The RACFs interact with transport functions to control one or more of the following
functionalities
in the transport layer: packet filtering, traffic classification, marking and policing, bandwidth
reservation and allocation, NAPT, antispoofing of IP addresses, NAPT/FW traversal, and usage
metering.

Transport User Profile Functions

- This FB represents the compilation of user and other control data into a single user
profile function in the transport stratum.
- This function may be specified and implemented as a set of cooperating DBs with
functionality
residing in any part of the NGN.

Gateway Functions

SWMC-Master TSAC2-2015-2016 page 29

 - provide capabilities to interwork with other networks: e.g. PSTN, ISDN-based networks
and the Internet.
- support interworking with other NGNs belonging to other administrators.

- The NNI for other networks applies to both the control and transport levels, including
border gateways.

- Interactions between the control and transport levels may take place directly or through
the transport control functionality.

Media Handling Functions media resource processes for providing services, such as
generating
tone signals, transcoding, and conference bridging.

2.3.2.2.2 Service Stratum Functions

- provide session-based and nonsession-based services, including subscribe/notify

for presence information and a message method for instant message exchange.
- provide all of the network functionality associated with existing PSTN/ISDN services
and capabilities and interfaces to legacy customer equipment.

Service and Control Functions session control functions, a registration function, and
authentication and authorization functions at the service level. They can include functions
controlling media resources (i.e., specialized resources).

Service User Profile Functions

- represent the compilation of user data and other control data into a single user profile
function in the service stratum.
- This function may be specified and implemented as a set of cooperating databases with
functionality residing in any part of the NGN.

Application Functions
- NGNs support open APIs enabling third-party service providers to apply NGN
capabilities to create enhanced services for NGN users.
- All application functions (both trusted and untrusted) and third-party service providers
access NGN service stratum capabilities and resources through servers or gateways in the service
stratum.

2.3.2.2.3 Management Functions

- enable the NGN operator to manage the network and provide NGN services with the
expected quality, security, and reliability.

- These functions are allocated in a distributed manner to each functional entity (FE).

- They interact with network element (NE) management, network management, and
service management FEs.

SWMC-Master TSAC2-2015-2016 page 30

The management functions include charging and billing functions.

These functions interact with each other in the NGN to collect accounting information, which
provides the NGN operator with resource utilization data enabling the operator to properly bill
users.

The charging and billing functions support the collection of data for both later processing
(offline charging) and near-real-time interactions with applications such as those for prepaid
services (online charging).

2.3.2.2.4 End-User Functions

The interfaces to the end user are both physical and functional (control) interfaces,
No assumptions are made about the diverse customer interfaces and customer networks
that may be connected to the NGN access network.
All customer equipment categories are supported in the NGN, from singleline legacy
telephones to complex corporate networks.
End-user equipment may be either mobile or fixed.

SWMC-Master TSAC2-2015-2016 page 31

3 CURRENT INTERNET MANAGEMENT ARCHITECTURE

3.1 INTERNET Management Framework- summary

TCP/IP based networks:

1. IETF defined Simple Network Management Protocol (SNMP)
2. it is de facto standard in the management fields of IP networks.
3. More complex mng. are defined ( Internet Network Management Framework - NMF)
4. Complex systems are used in practice and/or developed in several projects

Current IP networks are often managed via SNMP , std. of IETF

Several versions of SNMP ( v1, v2, v3).

The SNMP is an application layer protocol and uses (UDP) to exchange Mng. info between
management entities.

The Internet Standard Management Framework

1. encompasses all of the technologies that comprise the TCP/IP NM solutions
2. SNMP Framework consists of a number of arch. components that define how mng.
information is structured, how it is stored, and how it is exchanged using the SNMP
protocol
3. describes how:
o the different components fit together
o SNMP is to be implemented in network devices
o the devices interact.

SNMP Capabilities:

SNMP agents expose management data on the managed systems as variables

(such as free memory, system name, number of running processes , default
route)

SNMP also permits active mgmt. tasks, such as modifying and applying a new
configuration.

The managing system can retrieve the information through the

o GET, GETNEXT, and GETBULK operations
o or the agent will send data without being asked using TRAP or INFORM
operations.

Management systems can also send configuration updates or controlling requests through
the SET operation to actively manage a system.

Configuration and control operations are used only when changes are needed to the
network infrastructure.

The monitoring operations are usually performed on a regular basis.

SWMC-Master TSAC2-2015-2016 page 32

 The variables accessible via SNMP are organized in hierarchies. These hierarchies,
and other metadata (such as type and description of the variable), are described by
Management Information Bases (MIBs).

Additional standards were added in recent years, such as SNMPv3 and RMON in order
to enhance its management functionalities, especially in security and performance.

3.1.1 SNMP Framework Components

Internet Standard Management Framework is entirely information-oriented.

Primary components

o Structure of Management Information (SMI)

o Management Information Bases (MIBs)

o Simple Network Management Protocol (SNMP)

o Security and Administration

Figure 3-1 TCP/IP Internet Standard Management Framework - components

Two different basic types of hardware devices are defined:

Managed Nodes (devices): network nodes + SW to allow them to be managed using
SNMP.
Network Management Station (NMS): A designated network device that runs special
SW to manage the regular managed nodes
One or more NMSes must be present on the network, as these devices run SNMP in a
centralized way

3.1.2 SNMP Entities

Each device that participates in NM using SNMP runs SW, generically called an SNMP
entity.
The SNMP entity role: implementing all functions of the SNMP protocol

SWMC-Master TSAC2-2015-2016 page 33

 Each entity consists of one of two primary SW components; they depend on whether
o the device is a managed node
o or a network management station.

Managed Node Entities

o An SNMP managed node : any network device, running SNMP communicating

via TCP/IP
hosts, routers, bridges, hubs, switches, etc.
printers, scanners, consumer electronic devices, special medical devices,
etc.

The SNMP entity on a managed node consists of the following SW elements and constructs:

o SNMP Agent:
- SW implementing SNMP to provide information to an NMS and accept
instructions from it.
- SNMP (MIB): Defines the types of information stored about the node that can
be collected and used to control the managed node
- Information exchanged using SNMP takes the form of objects from the MIB.

Network Management Station Entities

o a NMS may be a separate, high-powered TCP/IP computer for network

management

o NMS runs special SW; so NMS may not be mandatory a separate hardware
device (It may act as an NMS and also perform other functions on the network)

o The SNMP entity on a NMS consists of:

SNMP Manager:
SNMP SW allowing the NMS to collect information from
managed nodes and to send instructions to them.
SNMP Applications:
One or more SW applications that allow admin to use SNMP
to manage a network.
SNMP applications provide the I/F to the human administrator,
and allow information to be collected from the MIBs at each
SNMP agent.

SWMC-Master TSAC2-2015-2016 page 34

Figure 3-2 SNMP Operational Model

3.2 Remote Network Monitoring

The most important addition to the basic set of SNMP standards is the RMON
(Remote Network MONitoring) standard, RFC 1271. RMON is a major step forward
in internetwork management.

RMON defines a remote-monitoring MIB that supplements MIB-II and provides the
network manager with vital information about the internetwork.

RMON MIB was developed by the IETF to support monitoring and protocol analysis
of LANs.

The original version (sometimes referred to as RMON1) focused on OSI L1, L2

information in Ethernet and Token Ring networks.

It has been extended by RMON2 which adds support for Network and Application-
layer monitoring and by SMON (Oracle System MONitor) which adds support for
switched networks.

It is an industry standard specification that provides much of the functionality

offered by proprietary network analyzers.

RMON agents are built into many high-end switches and routers.

3.2.1 RMON1

RMON1 MIB allows managers to collect information from remote network segments for
the purposes of troubleshooting and performance monitoring.

SWMC-Master TSAC2-2015-2016 page 35

The RMON1 MIB provides:
Current and historical traffic statistics for a network segment, for a specific host on a
segment, and between hosts (matrix).

A versatile alarm and event mechanism for setting thresholds and notifying the network
manager of changes in network behavior.

A powerful, flexible filter and packet capture facility that can be used to deliver a
complete, distributed protocol analyzer.

Figure: listing of the RMON1 groups and where RMON fits within the ISO and IETF standards.

Figure 3-3 RMON MIB Tree Diagram

An RMON implementation typically operates in a client/server model.

Monitoring devices (commonly called probes in this context) contain RMON

software agents that collect information and analyze packets.

These probes act as servers and the NM applications communicating with them act as
clients.

While both agent configuration and data collection use SNMP, RMON is designed to
operate differently than other SNMP-based systems:

o Probes are intelligent: they have more responsibility for data collection and
processing, which reduces SNMP traffic and the processing load of the clients.
o Information is only transmitted to the management application when required,
instead of continuous polling.

SWMC-Master TSAC2-2015-2016 page 36

 Summary:
o RMON is
designed for flow-based monitoring,
while SNMP is often used for device-based management.
o RMON is similar to other flow-based monitoring technologies such as NetFlow
and SFlow because
the data collected deals mainly with traffic patterns rather than the
status of individual devices.

One disadvantage : put more of the management burden on peripheral equipments

and require more resources to do so.
Some devices balance this trade-off by implementing only a subset of the RMON MIB
groups (see below).
A minimal RMON agent implementation could support only statistics, history, alarm,
and event.

The RMON1 MIB consists of ten groups:

1. Statistics: real-time LAN statistics, e.g., utilization, collisions, CRC errors.

2. History: history of selected statistics.
3. Alarm: definitions for RMON SNMP traps to be sent when statistics exceed defined
thresholds.
4. Hosts: host specific LAN statistics, e.g., bytes sent/received, frames sent/received.
5. Hosts top N: record of N most active connections over a given time period.
6. Matrix: the sent-received traffic matrix between systems.
7. Filter: defines packet data patterns of interest, e.g., MAC address or TCP port.
8. Capture: collect and forward packets matching the Filter.
9. Event: send alerts (SNMP traps) for the Alarm group.
10. Token Ring: extensions specific to Token Ring

3.2.1.1 Capabilities of RMON1

A network manager can remotely watch the traffic on a LAN segment,

o He can identify trends, bottlenecks, and hotspots.
o When a problem arises, RMON1 also includes a powerful protocol analyzer so
the network manager has distributed troubleshooting tools immediately at hand.
o Since the RMON1 device is permanently attached to the network segment, it
is already collecting data about the remote LAN and ready to transmit it to a
central network management station whenever required.
o All this network monitoring and troubleshooting can be done remotely

Deploying network management staff resources more efficiently means that

o one expert at a central site can work on several problems by getting information
from several probes at remote sites
o or several experts with different specialities can be focused on a single segment
by getting information from a single probe.

o RMON1 has increased efficiency of net mon ~ 2.5 times.

SWMC-Master TSAC2-2015-2016 page 37

3.2.2 RMON2

The RMON2 Working Group start: 1994.

Objective: to offer a set of deliverables to the network manager,

- implementable by multiple vendors,
- allow interoperability between independently developed solutions.

RMON2 WG covers:
- vertically : all architectural layers (statistics on network- and application-layer traffic).
- horizontally : internetwork or enterprise view of network traffic.

The RMON2 MIB adds ten more groups:

1. Protocol Directory: list of protocols that the probe can monitor.

2. Protocol Distribution: traffic statistics for each protocol.
3. Address Map: maps network-layer (IP) to MAC-layer addresses.
4. Network-Layer Host: L3 traffic statistics, per each host.
5. Network-Layer Matrix: L3 traffic statistics, per source/destination pairs of hosts
6. Application-Layer Host: traffic statistics by application protocol, per host.
7. Application-Layer Matrix: traffic statistics by application protocol, per
source/destination pairs of hosts.
8. User History: periodic samples of user-specified variables.
9. Probe Configuration: remote config of probes.
10. RMON Conformance: requirements for RMON2 MIB conformance.

3.2.2.1 RMON2Capabilities

The most beneficial capability in RMON2 is

o Covering all stack - which supports protocol distribution
o view of the whole network

Although the exact contents of RMON2 may change during the standard development process,
the capabilities expected to be delivered by RMON2 include:

Higher Layer Statistics

Traffic statistics, host, matrix, and matrix topN tables at the network layer, and the
application layer.
o One can see which clients are talking to which servers, so systems can be placed
at the correct location on the correct segment for optimized traffic flow
o use case : CDN- Content Delivery Networks

Address Translation
Binding between MAC-layer addresses and network-layer addresses,
Address translation
o helps theNM ,
o supports the SNMP management platform and will lead to improved topology
maps.

SWMC-Master TSAC2-2015-2016 page 38

 This feature also adds duplicate IP address detection, (important admin problem for
network routers and Virtual LANs).

User-Defined History
New feature: the network manager can configure history studies (dymamicity !) of any
counter in the system, such as a specific history on a particular file server or a router-to-router
connection.
In the RMON1 standard, historical data are collected only on a predefined set of
statistics.

Improved Filtering
Additional filters are required to support the higher layer protocol capabilities of
RMON2.
user can configure more flexible and efficient filters, especially relating to the higher-
layer protocols.

Probe Configuration
One vendors RMON application can remotely configure another vendors RMON
probe.
o Currently, each vendor provides a proprietary means of setting up and controlling
their probes.
o The probe configuration specification is based on the Aspen MIB which was
jointly developed by AXON and Hewlett-Packard.
o The Aspen MIB provides
probe device configuration,
trap administration,
and control of the probes out-of-band serial port.

Figure 3-4 The Work Layers of RMON1 and RMON2

3.3 Comparison of TMN- and Internet-Based Management Architecture

Complexity
TMN:
Feature-rich modeling of managed objects described in GDMO.
The data modeling and abstracting are very complex because of TMSs fine-grained
definition for interface and object.

SWMC-Master TSAC2-2015-2016 page 39

SNMP:
Simplified design and architecture and usage; the SNMP variables can be easily
programmed.

Functionality
TMN:
general framework for NM, and major functional areas, widely accepted in industry.
security features are also included, e.g. access control and security logging.
The use of data communication networks (DCN) for internal communication makes
it physically secure.

SNMP
It generally follows TMNs framework for management functionalities.
But, SNMP agents can only collect information from devices, lacking the ability of
analyzing.
The openness and IP-oriented nature of SNMP makes it not secure as TMN-based
protocols, such as CMIP, which defines management services exchanged between peer
entities in TMN.

Multi-vendor
Multi-vendor support is achieved at network management layer by implementing an
interface between Element Management System (EMS) and Network Management
System (NMS).
NMS can exchange events via its interface with different EMSs
TMN: difficult and expensive to implement NMS-EMS interface because of the complexity of
TMN.

SNMP: Multi-vendor support can be offered by retrieving objects from public MIBs (e.g.,
SNMPv1) that reside in the managed devices of different vendors.
However for private MIBs, the interface for specific vendor has to be developed.

Communication
TMN: The communication between Network elements (NE) or NMS and Element
Management System (EMS) requires the special OSI protocol stacks, which are rarely
supported by common LAN or WAN.
SNMP
o is initially designed for IP technology and uses UDP to carry management data. It
can easily run on nearly any network because of the popularity of TCP/IP.
o SNMP
connectionless, lower overhead,
but no guarantee the deliver of messages.

Implementation

TMN

CMIP and CORBA architecture are examples: the development of the core components
in TMN has to rely on many third-party software packages.
The implementation and running of TMN systems have higher requirements to networks
and operation systems.

SWMC-Master TSAC2-2015-2016 page 40

 o CMIP and CORBA concentrate on reliability and stability of networks ->
complexity
o Complexity, requires more resources to develop and run
o Therefore, it is most suitable for some mission critical applications, such as
the management of transportation backbones.

SNMP

The development of SNMP interface is relatively simple :

o it uses standard TCP/IP protocols
o most popular protocol for managing networks.
The cost of implementing SNMP network management is much lower, w.r.t. TMN-
based architecture implementation

3.3.1 CommonManagement Information Protocol (CMIP)

Common Management Information Protocol (CMIP): OSI-based network mgmt.

protocol.

It provides an implementation for the services defined by CMIS (the Common

Management Information Service), allowing communication between NM
applications and management agents.

CMIS/CMIP emerged out of the ISO/OSI NM model and is defined by the ITU-T
X.700 series of recommendations (however they generally also correspond to those
designed by the IETF SNMP).

CMIP adopts an ISO reliable CO transport mechanism

CMIP provides good security (support authorization, access control, and security
logs) and flexible reporting of unusual network conditions.

The management information is exchanged between the NM application and

management agents through managed objects.

CMIP models allows both modification and performing actions on managed objects.

Managed objects are described using GDMO (the Guidelines for the Definition of
Managed Objects) and are identified by a distinguished name (DN), similar in
concept to the X.500 directory.

The management functionality implemented by CMIP is described under CMIS

services.
CMIS defines the service interface that is implemented by the CMIP.

CMIS is part of the OSI body of network standards.

Note the term CMIP is sometimes used erroneously when CMIS is intended.

SWMC-Master TSAC2-2015-2016 page 41

 CMIS/CMIP is most often used in telecom applications, in other areas
SNMP has become more popular.

The following services are made available by the Common Management Information Service
Element (CMISE) to allow management of network elements.

Management operation services

- M-CREATE/ M-DELETE: Create/delete an instance of a managed object

M-GET: Request managed object attributes (for one object or a set of objects)
M-CANCEL-GET: Cancel an outstanding GET request
M-SET: Set managed object attributes
- M-ACTION: Request an action to be performed on a managed object

Management notification services

M-EVENT-REPORT: Send events occurring on managed objects

Management association services

To transfer mgmt. info between open systems using CMIS/CMIP, peer connections, i.e.,
associations, must be established.
This requires the establishment of the following ( OSI stack):
Application layer association
Session layer connection,
Transport layer connection

and, depending on supporting communications technology, Network layer, and Link layer
connections.

CMIS initially defined mgmt. association services but it was later decided these services could
be provided by Association Control Service Element (ACSE) and these services were removed.

Here is a list of these services which were subsequently removed from ISO 9595:

M-INITIALIZE - Creates an association with (i.e. connects to) another CMISE

M-TERMINATE - Terminates an established connection
M-ABORT - Terminates the association in the case of an abnormal connection
termination

3.3.1.1 The CMIP over the OSI Management Architecture

CMIP is widely used in the teleco domain

o Telco devices typically support CMIP.

ITU endorses CMIP as the protocol for the management of devices in the (TMN)
standard.

CMIP is an ISO development, and it is designed to operate in the OSI environment.

SWMC-Master TSAC2-2015-2016 page 42

 Figure 3-5 : OSI Management architecture, which uses CMIP to access managed
information.

CMIP is part of the ITU-T X.700 OSI series of Rec.

CMIP was developed and funded by government and corporations to replace and make
up for the deficiencies of SNMP, thus improving the capabilities of network management
systems.

Figure 3-5 CMIP on the OSI Management Architecture

Common Management Information Service Element (CMISE)

Remote Operation Service Element (ROSE)
Association Control Service Element (ACSE)
File Transfer Access and Management : communications protocol for the
transfer of files between systems of different vendors
In CMIP, an agent maintains a management information tree (MIT) as a database; it
models platforms and devices using managed objects (MOs).

o These may represent LANs, ports, and interfaces.

o CMIP is used by a platform to
Create, change, retrieve, or delete MOs in the MIT
It can invoke actions or receive event notifications.

Object-oriented system concepts that are applied to the CMIP objects include
containment, inheritance, and allomorphism.
o Containment refers to the characteristic of objects being a repository of other
objects and/or attributes.
A high-level object for a communication switch, for example, can
contain several racks of equipment, each of which, in turn, can
contain several slots for printed circuit boards.

On might use the ITU-T M.3100 base class for a circuit pack to
define the general features of modules within a communication
switch.

Object classes can be defined to represent the specific modules.

SWMC-Master TSAC2-2015-2016 page 43

 o Items including line interface cards, switching elements,
and processors can be derived from the basic circuit pack
definition.
o Each of these objects exhibits the behavior, actions, and
attributes of both the derived classes and the base class.

o Allomorphism (CMIP standards concept) refer to the ability to interact with

modules through a base set of interfaces, only to have the resulting behaviors
coupled to the complete class definition.

Disabling a power supply, for instance, may exhibit significantly

different behavior than disabling a switching component.

With CMIP and other OSI management schemes, there are three types of relationships
between managed objects:

o Inheritance Tree. This defines the managed object class super and subclasses,
much as C++ base and derived classes are related.
When a class is inherited from a superclass, it possesses all the
characteristics of the superclass, with additional class-specific
extensions (additional attributes, behaviors, and actions).

o Containment Tree. This defines which MOs are contained in other managed
objects.

As an example, a subnetwork can contain several managed elements

(ME).

o Naming Tree. This defines the way in which individual objects are referenced
within the constraints of the management architecture.

Final summary Notes:

CMIP (i.e., OSI management communications)

o are different from those found in SNMP.
o are embedded in the OSI application environment and they rely on conventional
OSI peer layers for support.
o use CO transport; in most cases, these communications are acknowledged.

3.3.1.2 CMIP Over TCP/IP (CMOT) Management Architecture

The CMOT architecture is based on the OSI management framework (OSI-MF) and
the models, services, and protocols developed by ISO.
objective :
o to map the OSI management protocol architecture into the
TCP/IP environment and used to manage objects in a TCP/IP
network
o it specifies all the essential components of a NM arch.

SWMC-Master TSAC2-2015-2016 page 44

 The use of ISO protocols for the management of widely deployed TCP/IP networks
will facilitate the migration from TCP/IP to ISO protocols.

The concept of proxy management is introduced as a useful extension to the architecture.

o Proxy management provides the ability to manage network elements that

either are not addressable by means of an Internet address
or use a network management protocol other than CMIP.

A protocol-dependent interpretation of the Internet SMI is used for defining management

information.

The Internet MIB provides an initial list of managed objects.

o Finally, means are defined for using ISO management services and protocols
on top of TCP/IP transport protocols.

Management applications themselves are not included within the scope of the
CMOT architecture.

o What is currently standardized in this architecture is the minimum required for

building an interoperable multivendor network management system.

o Applications are explicitly left as a competitive issue for network developers and
providers.
CMOT- essentially uses:
OSI model at the application layer
Internet protocols at the transport layer.
To guarantee reliable transport, CMOT systems establish Application layer
connections prior to transmitting management information.
CMOTs Application layer services are built on three OSI services:
Common Management Information Service Element (CMISE)
Remote Operation Service Element (ROSE)
Association Control Service Element (ACSE)
A Lightweight Presentation Protocol (LPP) provides Presentation layer services.

Common Management Information Service (CMIS)

is the service interface specified in ITU-T Rec. X.710, ISO/IEC Intl Standard 9595 that
is employed by OSI network elements for network management.
It defines the service interface implemented by the CMIP as specified in ITU-T Rec.
X.711, ISO/IEC International Standard 9596-1.
CMIS is part of the (OSI) body of international network standards.

Common Management Information Protocol (CMIP) is the OSI specified NM protocol.

Defined in ITU-T Rec. X.711, ISO/IEC International Standard 9596-1.
provides an implementation for the services defined by the CMIS allowing
communication between NM applications and management agents.
CMIP models mgmt. information in terms of managed objects (MO)
o allows both modification and performing actions on MOs.

SWMC-Master TSAC2-2015-2016 page 45

 o MOs are described using GDMO (Guidelines for the Definition of Managed
Objects), and can be identified by a distinguished name (DN), from the X.500
directory.
CMIP also provides good security (support authorization, access control, and security
logs) and flexible reporting of unusual network conditions.

Remote Operations Service Element (ROSE) is the OSI service interface, specified in ITU-T
Rec.X.219, ISO/IEC International Standard 9072-1, that
(a) provides remote operation capabilities,
(b) allows interaction between entities in a distributed application, and
(c) upon receiving a remote operations service request, allows the receiving entity to
attempt the operation and report the results of the attempt to the requesting entity.
OSI application protocols X.400 and X.500 utilize the ROSE services.
The ROSE protocol itself is defined using the notation of ASN.1.

Association Control Service Element (ACSE) is the OSI method for establishing a call
between two application programs.
ACSE checks the identities and contexts of the application entities, and could apply an
authentication security check.

Figure 3-6: The CMOT Protocol Architecture

3.4 SNMP Details

3.4.1 Architecture

The Internet Activities Board : management framework to manage TCP/IP implementations.

Framework components:
1. A conceptual framework that defines the description rules Structure of
Management Information (SMI).
2. A virtual database : information about the managed device - Management
Information Base (MIB) - defined according to the SMI.
3. A protocol for comm. manager - agent of a managed device SNMP SNMP handled
data follow the MIB rules for objects

SNMP defines the format of packets. It reads and changes the status (values) of objects
(variables) in SNMP packets.
SMI defines the general rules for naming objects, defining object types (including range
and length), and showing how to encode objects and values.

SWMC-Master TSAC2-2015-2016 page 46

 o SMI does not define:
the number of objects an entity should manage,
the names the objects to be managed
the association between the objects and their values.
MIB : collection of named objects, their types, and their relationships to each other in
an entity to be managed.
SNMP : asynchronous request-response protocol enhanced with trap-directed polling.
o asynchronous : the protocol need not wait for a response before sending other
messages.
o trap directed polling : a manager polls in response to a trap message being sent
by an agent, which occurs when there is an exception or after some measure has
reached a certain threshold value.
o SNMP operates in a CL mode with UDP - preferred transport mode.

Figure 3-7 SNMP Architecture

3.4.1.1 SNMP Entity

An SNMP entity is an implementation of this architecture.
SNMP entity : SNMP engine and one or more associated applications.

+-------------------------------------------------------------------+
| SNMP entity |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| +-------------------------------------------------------------+ |
+-------------------------------------------------------------------+

SWMC-Master TSAC2-2015-2016 page 47

Figure 3-8 SNMP entity components

SNMP engine
SNMP engine services : for sending and receiving messages, authenticating and encrypting
messages, and controlling access to managed objects.
There is a 1-to-1 association between an SNMP engine and the SNMP entity containing it.
The engine contains:
1) Dispatcher 2) Message Processing Subsystem 3) Security Subsystem 4) Access Control
Subsystem.

snmpEngineID
Within an administrative domain, a snmpEngineID is the unique and unambiguous identifier
1-1 association between SNMP engines and SNMP entities, it also uniquely and unambiguously
identifies the SNMP entity within that administrative domain.
Note : it is possible for SNMP entities in different administrative domains to have the same value
for snmpEngineID. Federation of administrative domains may necessitate assignment of new
values.

Dispatcher
One Dispatcher per SNMP engine.
It allows for concurrent support of multiple versions of SNMP messages in the
SNMP engine. It does so by:
sending and receiving SNMP messages to/from the network,
determining the version of an SNMP message and interacting with the
corresponding Message Processing Model,
providing an abstract interface to SNMP applications for delivery of a PDU to it and
allows applications to send a PDU to a remote SNMP entity.

Message Processing Subsystem (MPS)

The MPS prepares messages for sending, and extracting data from received messages.
The MPS potentially contains multiple Message Processing Models as shown in the next figure.

+------------------------------------------------------------------+
| Message Processing Subsystem |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
+------------------------------------------------------------------+

Figure 3-9 Messaage processing Subsystem

* One or more Message Processing Models may be present

Message Processing Model
It defines the format of a particular version of an SNMP message and coordinates the
preparation and extraction of each such version-specific message format.

Security Subsystem: provides security services such as the authentication and privacy of messages
and potentially contains multiple Security Models

SWMC-Master TSAC2-2015-2016 page 48

 Access Control Subsystem
The Access Control Subsystem provides authorization services by means of one or more (*) Access
Control Models.

+------------------------------------------------------------------+
| Access Control Subsystem |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| +---------------+ +-----------------+ +------------------+ |
+------------------------------------------------------------------+

Figure 3-10 Access Control

3.4.2 SNMP Messages

Figure 3-11 SNMP messages

The seven SNMP protocol data units (PDUs) are as follows:

Manager to agent requests:
GetRequest: to retrieve the value of a variable or list of variables. Desired
variables are specified in variable bindings (values are not used). Retrieval of the
specified variable values is to be done as an atomic operation by the agent.
o A Response with current values is returned.
SetRequest: to change the value of a variable or list of variables. Variable bindings
are specified in the body of the request. Changes to all specified variables are to be
made as an atomic operation by the agent.
o A Response with (current) new values for the variables is returned.
GetNextRequest: to discover available variables and their values. Returns a
Response with variable binding for the lexicographically next variable in the MIB.
o The entire MIB of an agent can be walked by iterative application of
GetNextRequest starting at OID 0. Rows of a table can be read by
specifying column OIDs in the variable bindings of the request.
GetBulkRequest: Optimized version of GetNextRequest for multiple iterations of
GetNextRequest.
o Returns a Response with multiple variable bindings walked from the
variable binding or bindings in the request.

SWMC-Master TSAC2-2015-2016 page 49

 o PDU specific non-repeaters and max-repetitions fields are used to
control response behavior. GetBulkRequest was introduced in SNMPv2.
Agent to manager:
Response: Returns variable bindings and acknowledgement for GetRequest,
SetRequest, GetNextRequest, GetBulkRequest and InformRequest.
o Error reporting is provided by error-status and error-index fields.
Although it was used as a response to both gets and sets, this PDU was
called GetResponse in SNMPv1.
Trap: Asynchronous notification from agent to manager. Includes current
sysUpTime value, an OID identifying the type of trap and optional variable
bindings.
o Destination addressing for traps is determined in an application-specific
manner typically through trap configuration variables in the MIB.
o The format of the trap message was changed in SNMPv2 and the PDU
was renamed SNMPv2-Trap.
Manager to manager
InformRequest: Acknowledged asynchronous notification. This PDU uses the
same format as the SNMPv2 version of Trap.
M-to-M notifications were already possible in SNMPv1 (using a Trap), but as
SNMP commonly runs over UDP, delivery of a Trap was not guaranteed.
InformRequest fixes this by sending back an acknowledgement on receipt.
Receiver replies with Response parroting all information in the InformRequest. This
PDU was introduced in SNMPv2.

Figure 3-12 SNMP PDUs

SWMC-Master TSAC2-2015-2016 page 50

Figure 3-13 Types of errors

Figure 3-14 SNMP Message structure

A message in SNMP is made of four elements: version, header, security parameters, and data
(which includes the encoded PDU).

Note:
To retrieve or manipulate management information using (SNMPv3) [RFC3410], it is necessary
to know the identifier of the remote SNMP protocol engine, the so-called snmpEngineID
[RFC3411].
While an appropriate snmpEngineID can in principle be configured on each management
application for each SNMP agent, it is often desirable to discover the snmpEngineID
automatically. (RFC 5343)

SNMP uses the services of UDP on two well-known ports, 161 and 162. The well-known port
161 is used by the server (agent), and the well-known port 162 is used by the client (manager).
An SNMP manager (client) sends message to an agent via UDP destination port 161
An agent (server) sends trap messages to a manager via UDP destination port 162.
Manager Listen to 162 Agent

Figure 3-15 Port numbers for SNMP

Example SNMP/MIB/SMI relationship

SWMC-Master TSAC2-2015-2016 page 51

Figure 3-16 Example of SNMP sequence of actions

SMI
It is a component used in network management. It names objects, defines the type of data that
can be stored in an object, and shows how data can be encoded for transmission over the network
Object Attributes: Name , Type , Encoding Method

Object identifier
All objects managed by SNMP are given an object identifier.The object identifier always starts
with 1.3.6.1.2.1.

Figure 3-17 Object Identifier

Data types
Data types are simple or structured

SWMC-Master TSAC2-2015-2016 page 52

Table 3-1Data types
Conceptual data types

Figure 3-18 Conceptual data types

Encoding format

Figure 3-19 Encoding formats

Codes for data types

SWMC-Master TSAC2-2015-2016 page 53

Figure 3-20
Example 4, IPAddress 131.21.14.8

Figure 3-21

MIB
Topics: how to - Access MIB Variables

Figure 3-22
Example: udp group

SWMC-Master TSAC2-2015-2016 page 54

Figure 3-23
UDP variables and tables

Figure 3-24

Three versions of SNMP: SNMPv1, SNMPv2, and SNMPv3.

The modular design of SNMP is shown in the consistency of the architecture, structure,
and framework of all three versions; this aids gradual evolution of protocol
enhancements.

Though SNMPv1 was effective and easy to implement, but it had its problems and
limitations.

SNMPv2, is an enhancement to SNMP1 and corrected the bugs and limitations in

SNMPv1. However, it did not address security deficiencies, such as privacy of data,
masquerading, and unauthorized disclosure of data.

SNMPv3 was then developed to address security deficiencies: Added access control,
authentication, and encryption of management data.

o The SNMPv3 specs : approved by the Internet Engineering Steering Group

(IESG) as full Internet Standard in March 2002,
o vendors have begun to support SNMPv3 in their products.

3.4.3 SNMPv1

SNMPv1 is the original Internet-Standard NMF : RFCs 1155, 1157, and 1212.

There are typically three communities in SNMPv1: read-only, read-write, and trap.

SNMPv1 is still the primary SNMP implementation that many vendors support.

SWMC-Master TSAC2-2015-2016 page 55

SNMPv1s security is based on communities (just simple passwords: plain-text strings that allow
any SNMP-based application that knows the strings to gain access to a devices management
information).

3.4.3.1 SNMPv1 Protocol Operations

SNMPv1 is a simple request/response protocol.

Protocol operations: Get, GetNext, Set, and Trap.

Table 3-2 SNMP Manager Operation

Get : NMS retrieves the value of one or more object instances from an agent. If the agent
cannot provide values for all the object instances in a list, it does not provide any values.

GetNext : NMS to retrieve the value of the next object instance in a table or a list within
an agent.

Set : NMS to set the values of object instances within an agent.

Trap : used by agents to asynchronously inform the NMS of a significant event.

The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs and

distinguishes between application entities and protocol entities.
In SNMPv3, these are renamed applications and engines, respectively.

The SNMPv1 Framework also introduces the concept of an authentication service

supporting one or more authentication schemes.
In SNMPv3, the concept of an authentication service is expanded to include other
services, such as privacy.
SNMPv1 : introduces access control based on a concept called an SNMP MIB view.
SNMPv3 specifies a fundamentally similar concept called view-based access control.

SNMPv1 Framework anticipated the definition of multiple authentication schemes,

o but did not define any such schemes other than a trivial authentication scheme
based on community strings.
o This was a known fundamental weakness in the SNMPv1 Framework.

Because some users do not require strong authentication, the SNMPv1 structured an
authentication service as a separate block to be defined later.

SWMC-Master TSAC2-2015-2016 page 56

 o The SNMPv3 Framework provides
an architecture for use within that block,
as well as a definition for its subsystems.

3.4.4 SNMPv2

SNMPv2 is derived from the SNMPv1.

It is described in STD 58, RFCs 2578, 2579, 2380, and STD 62, RFCs 3416, 3417, and
3418.
SNMPv2 has no message definition.

3.4.4.1 SNMPv2 Protocol Operations

Get, GetNext, and Set idem to SNMP1.

SNMPv2 enhancements:
Trap uses a different message format and is designed to replace the SNMPv1 Trap.

New protocol operations: GetBulk and Inform.

GetBulk :
NMS retrieve large blocks of data, such as multiple rows in a table
GetBulk fills a response message with as much of the requested data as will fit.
if the agent responding to GetBulk operations cannot provide values for all the variables
in a list, it provides partial results.

Inform: NMS can send trap information to another NMS and to then receive a response.

SNMPv2 advantages over SNMPv1:

Expanded data types: 64-bit counter

Improved efficiency and performance: get-bulk operator
Confirmed event notification: inform operator
Richer error handling: errors and exceptions
Improved sets: especially row creation and deletion
Fine-tuned data definition language

Critics:

SNMPv2 framework, (RFCs 1902 1907) is incomplete

it does not meet the original design goals of the SNMPv2 project
e.g. : it failed to offer enough security and administration features for so-called
commercial grade security with

- authentication: origin identification, message integrity, and some aspects of

replay protection,
- privacy: confidentiality,
- authorization and access control, and
- suitable remote configuration and administration capabilities for these features.

SWMC-Master TSAC2-2015-2016 page 57

SNMPv2c (the Community-based SNMP version 2) is an experimental SNMP framework which
supplements the SNMPv2 Framework, as described in RFC 1901.
It adds the SNMPv2c message format, which is similar to the SNMPv1 message format.

3.4.5 SNMPv3

SNMPv3 : RFCs 3412, 3414, and 3417.

RFC 3416: Coexistence issues relating to SNMPv1, SNMPv2c, and SNMPv3

The new features of SNMPv3 (in addition to those of SNMPv2 listed above) include:

Security
authentication and privacy
authorization and access control

Administrative Framework
naming of entities
people and policies
usernames and key management
notification destinations
proxy relationships
remotely configurable via SNMP operations

SNMPv3 main contribution to network management is security.

- support for strong authentication and private communication between managed
entities
- In 2002 it became a full standard.
-
But vendors are rather slow at adopting new versions of a protocol.

Still the vast majority of vendor implementations of SNMP are SNMPv1,v2 implementations.

Some large vendors e.g. Cisco support SNMPv3 for quite some time, -> see more vendors move
to SNMPv3.

SNMPv3
- is an interoperable standards-based protocol
- provides secure access to devices by a combination of authenticating and encrypting
packets over the network.
-
The security features provided in SNMPv3 are:

Message integrity: Ensuring that a packet has not been tampered with in-transit.
Authentication: Determining the message is from a valid source.
Encryption: Scrambling the contents of a packet prevent it from being seen by an
unauthorized source.

SWMC-Master TSAC2-2015-2016 page 58

SNMPv3 provides for both security models and security levels.
- A security model is an authentication strategy that is set up for a user and the group in
which the user resides
-A security level is the permitted level of security within a security model.

A combination of a security model and a security level will determine which security
mechanism is employed when handling an SNMP packet.

Three security models are available: SNMPv1, SNMPv2c, and SNMPv3.

Figure 3-25: SNMP v3 entity architecture

3.4.6 Recent Advances in SNMP

RFC 3512 (2003) improves the ability of SNMP for configuring networks and devices; it
offers guidance in the effective use of SNMP for configuration management.
o This information is relevant to vendors that build network elements, management
application developers, and those that acquire and deploy this technology in their
networks.
RFC 3781 (2004) defines an SMIng (Structure of Management Information, Next
Generation) language extension that
o specifies the mapping of SMIng definitions of
identities,
classes,
and their attributes
and events to dedicated definitions of nodes, scalar objects, tables and
columnar objects, and notifications for application in the SNMP
management framework.

RFC 3826 (2004) enhances SNMP security : it describes a symmetric encryption

protocol that supplements the protocols described in the User based Security Model
(USM), which is a Security Subsystem for SNMPv3 in the SNMP Architecture.
o The symmetric encryption protocol is based on the Advanced Encryption
Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a
key size of 128 bits.

SWMC-Master TSAC2-2015-2016 page 59

 To enlarge the management ability for increasing heterogeneity communication devices,
network management has to meet the non-SNMP management environments.
o For example, when out-of-band IP management is used via a separate
management interface (e.g., for a device that does not support inband IP access), a
uniform way to indicate how to contact the device for management is needed.
o RFC4088 (2005) defines a URI (Uniform Resource Identifiers) scheme so that
SNMP can be designated as the protocol used for management. The scheme also
allows a URI to designate one or more MIB object instances.
Note:
[
Uniform Resource Identifier (URI) is a string of characters used to identify a name
of a resource.
Such identification enables interaction with representations of the resource over a
network, typically the World Wide Web, using specific protocols.
Schemes specifying a concrete syntax and associated protocols define each URI.
The most common form of URI is the uniform resource locator (URL), frequently
referred to informally as a web address.
]

RFC 4789 (2006) : integrate the management of IEEE 802 networks, (this document
obsoletes RFC 1089) and specifies how SNMP messages can be transmitted directly
over IEEE 802 networks.

RFC 5343 (2008) introduces a well-known localEngineID and a discovery mechanism
that can be used to learn the snmpEngineID of a remote SNMP protocol engine
o to meet the SNMPv3 requirements that an application needs to localize the
identifier (snmpEngineID) of the remote SNMP protocol engine in order to
retrieve or manipulate objects maintained on the remote SNMP entity
o The proposed mechanism is independent of the features provided by SNMP
security models and may also be used by other protocol interfaces providing
access to managed objects.

RFC 5345 (2008) : deals with the large traffic measurement; it describes an approach to
carrying out large-scale SNMP traffic measurements in order to develop a better
understanding of how the SNMP is used in real-world production networks.
o It describes the motivation, the measurement approach, and the tools and data
formats needed to carry out such an application.

RFC 5590 (2009) defines a subsystem, extending the SNMP architecture defined in RFC
3411.

As work is being done to expand the transports to include secure transports, such as the
Secure Shell (SSH) Protocol and Transport Layer Security Transport Subsystem for the
SNMP.

RFC 5591 (2009) describes a Transport Security Model for the SNMP.

RFC 5592 (2009) describes a Transport Model for the (SNMP), using the Secure Shell
(SSH) protocol.

SWMC-Master TSAC2-2015-2016 page 60

 o It also defines a portion of the MIB for use with network management protocols
in TCP/IP-based internets. In particular, it defines objects for monitoring and
managing the Secure Shell TransportModel for SNMP.
o
RFC 5608 (2009) describes the use of a Remote Authentication Dial-In User Service
(RADIUS) authentication and authorization service with SNMP secure transport models
to authenticate users and authorize creation of secure transport sessions.

SWMC-Master TSAC2-2015-2016 page 61

3.4.7 Example of a Monitoring system architecture of a core IP domain manager
( TEQUILA project example [to be completed ])
Node Monitor (NodeMon) :

o Role: node related measurements

o there exists oneNodeMon per router

o can be is hosted outside of the router on a dedicated machine, as the availability
of required measurements is limited by what is currently supported by the
available commercial routers.

o is able to perform active measurements between itself and any other NodeMons,
at path or hop level, as well as passive monitoring on the router to which it is
attached

o NodeMons are configured with information about the variable to be monitored

(sampling and summarization periods, and, if required, threshold parameters)

o NodeMon collects measurement results from either meters or probes located at

routers through passive monitoring agents or active monitoring agents

o Probes present the data they collect in a variety of ways

o NodeMon is to regulate and re-abstract various types of measured data

o NodeMon performs some short-term evaluation of results in addition to threshold

crossing detection and notification.

SWMC-Master TSAC2-2015-2016 page 62

Figure 3-26 Example: Monitoring system architecture of a core IP domain manager

( TEQUILA project [http://www.ist-tequila.org/ ])

2. Network Monitor (NetMon)

Role: Network-wide postprocessing of measurement data using a library of statistical

functions.

It is centralized and it utilizes network-wide performance and traffic measurements
collected by all the NodeMon entities in order to build a physical and logical network
view (i.e., the view of the routes that have been established over the network)

No major scalability concern with NetMon, since the analyzed data are mainly used for
nonreal-time, pro-active control of the network.

NetMon also uses hop-by-hop measurements for calculating edge-to-edge results.

Relatively frequent topological changes are common, therefore

o the monitoring system must be flexible enough to adapt to such changes
o modifications to monitoring processes are thus required to accommodate rapid
network changes.
o this is achieved through NetMon access to a Topology Repository (TopologyRep)
that contains updated information about the network physical topology and the
current network configuration as resulted from the provisioning processes.

3. SLS Monitor (SLSMon)

SWMC-Master TSAC2-2015-2016 page 63

 Role: for customer related service monitoring, auditing, and reporting

is centralized, since it must keep track of the compliance of the level of service provided
to the customer SLS instances in a domain

It utilizes information provided by the centralized NetMon and/or the various distributed
NodeMons.

The SLS Management subsystem is the main client of SLSMon

o It requests the creation of the necessary monitors whenever a SLS is invoked

o SLSMon handles the requests for activation or deactivation of monitoring a

particular set of SLSs

o SLSMon accesses a monitoring repository for measurement data collected by

NodeMons and NetMon and combines the data for each individual SLS, i.e., path
level performance related statistics and SLS specific traffic related statistics

o For each contracted SLS, the performance parameters and the traffic-related
values stored in SLS Repository (SLSRep) are checked against measurement data
to determine whether any violations occur and then reports are generated.

4. Monitoring Repository (MonRep)

Role: Data base; it consists of two major parts for data cataloguing
o a data store with database functionality for storing large amounts of data from
monitoring components
o information store for storing smaller amounts of configuration type
information and information about active monitoring processes

o Measurement data stored in the data store are used for subsequent analysis via the
Graphical User Interface (GUI), NetMon, or SLSMon.

5. Monitoring GUI (MonGUI)

is used for displaying measurement results and can be used in a Network Operations
Center.

MonGUI presents a user interface allowing human operators to request graphical views
of monitoring statistics extracted from the monitoring data store

It exposes an interface to allow other components to request display of statistics.

SWMC-Master TSAC2-2015-2016 page 64

4 AUTONOMIC NETWORK MANGEMENT

Note: Given the complexity of the subject, this chapter only outlines the ANM principles.

4.1 AUTOMATIC, AUTONOMOUS, AND AUTONOMIC SYSTEMS

4.1.1 Definitions
Automatic (Adv Automatically):
An automatic action is performed from force of habit or without any conscious thought.
Many examples can of course be found in the bio-system or artificial system.
Automatic systems do not have any knowledge outside the predefined one and no ability
to extend it.
An automatic system will always exhibit the same behaviors for the same input.
In automatic system theory, this behavior is called transfer function.

Autonomous (Adv Autonomously):

An autonomous system exhibits a large degree of self-governance.
This system takes its decision without referring to any external entities and in complete
independence.
The autonomous entity defines its own rules and principles to achieve its own goals.
An autonomous behavior is the ultimate freedom.
Autonomic (Adv Autonomically):
The word autonomic suggests the idea of self-governance within an entity based on
internal policies and principles, which can also be described as autonomics.
Autonomic relating to the autonomic nervous system (ANS) is based on internal stimuli
that trigger involuntary responses.
In medical terms, autonomic means self-controlling or functionality independent.

Other definition: the essence of autonomic management is the capability of a system to self-
govern its behavior, but only within the constraints of the (human-specified) goals that the
system as a whole seeks to achieve.

4.1.2 IBMS APPLICATION OF AUTONOMICS TO COMPUTERS

Autonomic Computing is an initiative started by IBM in 2001.

4.1.2.1 Levels of autonomy (IBM)

IBM has introduced an evolutionary process to evaluate the level of autonomic behavior (self-
managing concept) in a computing system.
This evolutionary process defines different levels of evolution of the system management
process and describes how this process evolves with the adoption of autonomic concepts and
technologies.
The five levels of evolution toward achieving a fully autonomic system are as follows:
Level 1 or Basic Level. the operator needs to monitor and configure manually each elementof
the system during its entire life cycle from installation to un-installation.
Level 2 or Managed Level. the system operator can take advantage of a set of system
management technologies to monitor multiple systems and system elements simultaneously,
using management consoles with appropriate human machine interfaces.

SWMC-Master TSAC2-2015-2016 page 65

Level 3 or Proactive Level. Advances in analytical studies of the system allow the development
of a system with predictive capacities that allow analyzing gathered information and identifying
and predicting problems and therefore propose appropriate solutions to the operator of the
system for deployment.
Level 4 or Adaptive Level.
The system is able to gather monitored information and predict situations but also to
react automatically in many situations without any human intervention.
This is based on a better understanding of system behavior and control. Once
knowledge of what to perform in which situation is specified, the system can carry out
numerous lower level decisions and actions.
Level 5 Autonomic Level.
This is the ultimate level where the interactions between the humans and the systems
are only based on high-level goals.
Human operators only specify business policies and objectives to govern systems,
o while the system interprets these high-level policies and responds accordingly.
At this level, human operators will trust the system in managing themselves and will
concentrate solely on higher level business.

4.1.2.2 IBM AUTONOMICS COMPUTING

IBM breaks down autonomic self-management into four categories (CHOP):
Self-Configuration: Automatic configuration of components;

Self-Healing: Automatic discovery, and correction of faults;

Self-Optimization: Automatic monitoring and control of resources to ensure the optimal

functioning with respect to the defined requirements;

Self-Protection: Proactive identification and protection from arbitrary attacks.

Figure 4-1 Conceptual Model of an Autonomic System (AuS)

A fundamental building block is the sensing capability (Sensors Si), which enables the system
to observe its external operational context.

AuS has a data base with knowledge of the Purpose (intention) and the Know-how to operate
itself (e.g., boot-strapping, configuration knowledge, interpretation of sensory data) without
external intervention.

SWMC-Master TSAC2-2015-2016 page 66

The actual operation of the autonomic system is dictated by the Logic, which is responsible for
making the right decisions to serve its Purpose, and influence by the observation of the
operational context (based on the sensor input).

The operation of an AuS is purpose-driven.

This includes
1. its mission (e.g., the service it is supposed to offer),
2. the policies (e.g., that define the basic behavior),
3. and the survival instinct.

If seen as a control system this would be encoded as a feedback error function

or in a heuristically assisted system - as an algorithm combined with a set of heuristics
bounding its operational space.
Heuristic or heuristics; Greek: "", "find" or "discover") refers to experience-based
techniques for problem solving, learning, and discovery. Heuristic methods are used to speed up
the process of finding a satisfactory solution, where an exhaustive search is impractical.
Examples of this method include using a "rule of thumb", an educated guess, an intuitive judgment,
or common sense.
In more precise terms, heuristics are strategies using readily accessible, though loosely
applicable, information to control problem solving in human beings and machines.

4.1.2.2.1 Architecture of an Autonomic System

An architecture for autonomic systems must accomplish three fundamental goals:

1.it must describe the external interfaces and behaviors required of individual system
components.
2.it must describe how to compose these components so that the components can
cooperate toward the goals of system-wide self-management.
3. it must describe how to compose systems from these components in such a way that
the system as a whole is self-managing.

Figure 4-2 Functional Details of an Autonomic Manager (IBM)

Autonomic manager (AM) implements a control loop called MAPE that

1. implements the life cycle from monitoring managed elements

SWMC-Master TSAC2-2015-2016 page 67

 2. and autonomically modifies their state to fulfill the administrator goals

Monitor function : mechanisms that collect, aggregate, and filter, and report details (e.g.,
metrics, topologies) collected from a managed resource under its responsibility.

Analyze function: mechanisms that correlate and model complex situation. These mechanisms
allow the autonomic manager to learn about the IT environment and help predict future
situations.
This allows the management element (ME) to analyze the collected details to
understand the current system state. This analyze function requires the use of complex models of
the various situations in which the management elements(s) could evolve.

Plan function: mechanisms that construct the actions needed to achieve goals and objectives.
- The planning mechanism uses policy information to guide its work.
- Once the situation is identified, the ME needs to define the set of actions needed to
achieve the high-level goals and objectives.

Execute function : mechanisms that control the execution of a plan with considerations for
dynamic updates.
This function allows the ME to change the behavior of the managed resource using
effectors

Figure 4-3 Autonomic Computing Reference Architecture (IBM)

The lowest layer contains the system components or managed resources.

SWMC-Master TSAC2-2015-2016 page 68

These managed resources can be any type of resource (HW/SW) and may have embedded self-
managing attributes ( recursivity) .

The next layer incorporates consistent, standard manageability interfaces for accessing and
controlling
the managed resources. These standard interfaces are delivered through a manageability end
point.

Layers three and four automate some portion of the systems process using an autonomic
manager.

Details on Autonomic Computing (AC) functions

Managed Resource
The managed resources are the controlled system components (server, router, a cluster or
business application,etc.).
Manageability Interface
The manageability interfaces define the services that are made available by the managed
resource to manage them, such as the sensors and the effectors used by an autonomic manager.
Sensor
The sensor interface allows retrieving information about the current state of a managed
resource. It also allows receiving asynchronous events (unsolicited, asynchronous
messages or notifications) that can occur.
Effector
The effector interface allows the change of different aspects of the state of the managed
resource to influence its behavior.

4.2 Autonomic Network Mangement System (ANMS)

4.2.1 Introduction
ANM(S) is an instantiation of Autonomic Computing (AC) principles and architecture to
network management.
Notation: AN = Autonomic Networking

An NMS is considered to be autonomic if it performs network management operations in a

manner that satisfied the self-CHOP characteristics.

However, applying autonomic principles to network management requirements :

A means is required to enable business rules to determine the set of resources and/or
services to be provided.
Contextual changes in the network must be sensed and interpreted, because new
management policies may be required when context changes.
As context changes, it may be necessary to adapt the management control loops that are
used to ensure that system functionality adapts to meet changing user requirements,
business goals, and environmental conditions.
A means is required to verify modeled data and to add new data dynamically so that the
system can learn and reason about itself and its environment.

4.2.2 General ANM Features

At the minimum, an autonomic network should have the following three features.

SWMC-Master TSAC2-2015-2016 page 69

 Self-awareness.
o It should have a detailed knowledge of its elements that includes
current states of all the network elements,
traffic load across the network and ultimate capacity,
internal network topology
all connections to other networks.

It needs to know the extent of its own resources, including

o the shared ones among network elements
o and fixed (individual) ones dedicated to certain elements.
Example:
B1 bandwidth for Channel 1
B2 bandwidth for Channel 2
B bandwidth shared

o In ANM the network entities must know both themselves and their surrounding
networks, including their activities, and should act accordingly.
o They should follow and update general rules to interact with neighboring network
elements in order to achieve global optimization.
o They will account their available resources and negotiate the use by other network
elements of its underutilized resources, configuring both itself and its connections
to other networks in the process.

Self-configuring and self-optimizing.

o It should never settle for the status quo but looks for ways to improve its
performance.
o It should monitor its constituent parts and change global and local network
parameters in order to achieve the desired operators goals.
o An AN must also configure and reconfigure itself under varying conditions.
o System configuration or setup should occur automatically, as well as dynamic
adjustments to that configuration to best handle changing traffic flows and
hardware and software resources.
Self-healing.
o It should be able to recover from routine and extraordinary events that might
cause some of its parts to malfunction.
o It should be able to discover faults or potential problems, and then find corrective
measures in an automatic manner.
o These can be
activating redundant modules,
sending software patches,
offloading the processing and traffic load to other network elements (load
balancing)
or reconfiguring the system to keep it functioning smoothly.
o An autonomic network should be an expert in self-protection. It should detect,
identify, and protect itself against various types of attacks to maintain overall
system security and integrity.

In ANs, the state of the network may be defined by inputs from:

individual network elements such as switches and network interfaces including

specification and configuration

SWMC-Master TSAC2-2015-2016 page 70

 historical records and current state
traffic flows
end-hosts
application performance data
logical diagrams and design specifications

Most of these sources represent relatively raw and unprocessed views that have limited
relevance.

therefore post processing and various forms of analysis must be applied to generate
meaningful measurements and assessments against which current state can be derived.

An Autonomic Network Elements (A-NE) performs the following tasks:

Sensing its environment

This is similar to the sensors in the autonomic computing architecture.
The A-NE should continuously monitor the managed element (s) under its control using
different types of sensors that could be software or hardware local or remote.
Sensors in this case should be able to intervene at different levels of the
communication stack (hardware, protocol, service, application, etc.), which makes it
very complex.

Perceiving and analyzing the context

When information is collected from the sensors, the A-NE needs to understand its
context.
The network environment is intrinsically very complex. The info collected could have
different meanings based on the context in which the A-NE is evolving.
So, it is difficult task for A-NE to interpret heterogeneous monitored information using
other levels of information (local or global).
Historical information is very important to analysis of the context and understands in
which situation the A-NE is now.
Based on high-level goals, the A-NE will try to maintain itself in a set of desired
states according to the context.
o Otherwise, the A-NE will need to autonomously perform some actions to change
its state and try to reach a desired one.
o The desired state could sometimes be the optimal one, but in some situations, this
state could only be a safe one that would ensure that the system will always
deliver the service.
o This state could then be changed to move toward an optimal one.

Learning

The A-NE will face different contexts and situations to which it has reacted,
implementing different strategies to always fulfill its assigned goal.
During these trials, the A-NE will be able to evaluate the usefulness of the implemented
situation and learn from the performed action to adapt itself to future known or
unknown situations.
Autonomic adaptation is the capability by which the A-NE will improve by learning
(increasing its knowledge) the best strategies to plan in order to react to situations.

SWMC-Master TSAC2-2015-2016 page 71

 This is, what humans do to improve their knowledge and skill should be in autonomic
networking, as an inner capacity of network elements.

Participating in Groups
NE should interact (communicate, collaborate, and exchange information and
knowledge) with other A-NE to improve its knowledge and skill.
These group interactions are also important in collectively achieving a global goal that
cannot be reached without a certain level of coordination.
These communications should be achieved within purposeful (structured and
unstructured, ad hoc) groups or clusters.
Information should be understandable to the A-NEs, though it is exchanged by autonomic
entities.
Planning
Once the context is identified and its situation is evaluated,
o the A-NE should define the strategy (list of actions) that should be taken to
either reach a desired state in case it is in an undesired state
or to reach another desired state that is better from a different
perspective, that is, performance, security, organization, and the like.
The planning process contains a set of strategies that allow the A-NE to continuously
fine tune the underlying managed elements and adapt to new contexts while always
seeking to be in desired states.
Problems: distributed nature of the network -> the planning can be very difficult as
it is not possible to enforce an action instantaneously;
o when a set of actions are identified, it is not possible to activate them also at the
same time.
As the A-NEs take their decision in an autonomic way, a consistency among the actions
should be ensured in a completely distributed way
Convergence time becomes an important aspect (e.g for routing decisions)
Note Software Defined Networking can improve the planning coherency duet o
higher degree of centraklisation and separation DataPlane versus Ctrl and Mgmt
Plane.

Actuating its state

Finally, the A-NE should have the full control of itself and the parameters that affect its
local behavior.
This happens through a set of actuators that are linked to the underlying physical and
logical resources that are part of the A-NEs boundaries.

4.2.3 IRTF Autonomic Networking Model

Autonomic Networking - Definitions and Design Goals

draft-irtf-nmrg-autonomic-network-definitions-04.txt Oct. 2014

The fundamental goal is self-management, including self-configuration, self-optimization,

self-healing and self-protection.

4.2.3.1 Definitions

Autonomic: Self-managing (self-configuring, self-protecting, self- healing, self-

optimizing); however, allowing high-level guidance by a central entity, through intent.

SWMC-Master TSAC2-2015-2016 page 72

 Automatic: A process that occurs without human intervention, with step-by-step
execution of rules. However it relies on humans defining the sequence of rules, so is
not Autonomic in the full sense. For example, a start-up script is automatic but not
autonomic.
Intent: An abstract, high level policy used to operate the network autonomically. Its
scope is an autonomic domain, such as an enterprise network. It does not contain
configuration or information for a specific node. It may contain information pertaining
to nodes with a specific role.
Autonomic Domain: A collection of autonomic nodes that instantiate the same intent.
Autonomic Function: A feature or function which requires no configuration, and can
derive all required information either through self-knowledge, discovery or through
intent.
Autonomic Service Agent: An agent implemented on an autonomic node which
implements an autonomic function, either in part (in the case of a distributed function) or
whole.
Autonomic Node: A node which employs exclusively autonomic functions. It requires
(!) no configuration. (Note that configuration can be used to override an autonomic
function. See Section 3.2 of the draft for more details.) An Autonomic Node may
operate on any layer of the networking stack. Examples are routers, switches,
personal computers, call managers, etc.
Autonomic Network: A network containing exclusively autonomic nodes.

4.2.3.2 IRTF Autonomic Reference Model

An Autonomic Network consists of Autonomic Nodes. The nodes inter-communicate through

an Autonomic Control Plane which provides a robust and secure communications overlay.
The Autonomic Control Plane is self-organizing and autonomic itself.
An Autonomic Node contains various elements, such as autonomic service agents which
implement autonomic functions. Figure 4-4 shows a reference model of an autonomic node.
The elements and their interaction are:
Autonomic Service Agents, which implement the autonomic behaviour of a specific
service or function.
Self-knowledge: An autonomic node knows its own properties and capabilities
Network Knowledge (Discovery): An autonomic service agent may require various
discovery functions in the network, such as service discovery.
Intent: Network wide high level policy. Autonomic Service Agents use an intent
interpretation engine to locally instantiate the global intent. This may involve
coordination with other Autonomic Nodes.
Feedback Loops: Control elements outside the node may interact with autonomic
nodes through feedback loops.
An Autonomic User Agent, providing a front-end to external users (administrators and
management applications) through which they can communicate intent, receive reports,
and monitor the AutonomicNetwork.
Autonomic Control Plane (ACP): Allows the node to communicate with other
autonomic nodes.
o Autonomic functions such as intent distribution, feedback loops, discovery
mechanisms, etc, use the ACP.
o The ACP can run
- inband, over a configured VPN,
over a self-managing overlay network,
or over a traditional out of band network.

SWMC-Master TSAC2-2015-2016 page 73

Security is a requirement for the ACP , which can be bootstrapped by a dedicated mechanism.

+------------------------------------------------------------+
| +----------+ +--------------+ |
| | | | Feedback | |
| | Intent | | Loops | |
| +----------+ +--------------+ |
| ^ ^ |
| Autonomic User Agent |
| V V |
| +-----------+ +------------+ +------------+ |
| | Self- | | Autonomic | | Network | |
| | knowledge |<------>| Service |<------>| Knowledge | |
| | | | Agents | | (Discovery)| |
| +-----------+ +------------+ +------------+ |
| ^ ^ |
| | | |
| V V |
|------------------------------------------------------------|
| Autonomic Control Plane |
|------------------------------------------------------------|
| Standard Operating System Functions |
+------------------------------------------------------------+

Figure 4-4 IRTF Autonomic reference model

4.2.4 Industry view of autonomic management

Figure 4-5 CISCO view of Autonomic Network

Autonomic Networking is controlled by a separate software entity running on top of
traditional operating systems that include networking components, such as IP, Open
Shortest Path First (OSPF), and so forth.
Traditional networking components are unchanged and unaware of the presence of
the autonomic process.
The autonomic components use normal interfaces that are exposed by the traditional
networking components and interact with different devices in the network.

SWMC-Master TSAC2-2015-2016 page 74


The autonomic components securely cooperate to add more intelligence to devices so
that the devices in an autonomic network can
o - autonomically configure,
o manage,
o protect,
o and heal themselves
with minimal operator intervention. They can also securely consolidate their operations to
present a simplified and abstracted view of the network to the operator.

Action Examples (CISCO):

A device joins an autonomic network.

1 The new device sends out a hello message to the neighbor. In this case, the neighbor is part of
an autonomic network domain.

2 The hello message includes the unique device identifier (UDI) of the new device.

3 The autonomic device acts as a proxy and allows the new device to join this autonomic
network domain. The autonomic network device advertises itself with the domain information to
its Layer 3 neighbors.

4 On receiving the autonomic network hello message from the neighbor and detecting the UDI
information, the new device is validated with the autonomic registrar.

5. The new device advertises its domain certificate in its hello message with all neighbors.
The neighbor information is exchanged every 10 seconds.

Figure 4-6 New device joining the Autonomic Network

4.2.5 Building a Network Knowledge Data Base for ANMS

The AM systems should describe an accurate model of the managed system

This process requires a Knowledge Base System (KBS) which can range in complexity from a
simple database to more advanced expert systems with built-in reasoning mechanisms.

SWMC-Master TSAC2-2015-2016 page 75

Steps to build KBS

1. Secification of the knowledge that must be supplied by the system.

2. Select a suitable model for each type of the domain knowledge.

3. Building methods for knowledge discovery, acquisition and processing.

Note: These issues have seldom been addressed in the literature and, rather, existing work
addresses only isolated related issues.

4.2.5.1 Knowledge typology in ANMS

A KBS ( or Network KBS) may represent two different forms of knowledge about the managed
system as the
domain knowledge : view or conceptualization of the managed domain
o structure knowledge
information about
the sorts of objects of the modeled domain,
their properties,
the relations among them,
in addition to the different factual knowledge about the domain.
o behavior knowledge
describes patterns of behavior of different components or the overall
modeled domain
control knowledge: the ways to manage and control the modeled system
o for example, as a set of domain related problems and their corresponding applied
solutions. ( this is the most intelligent part)

The Self-awareness is achieved by modeling the different components within the

managed network in a network-knowledge-base system (NKBS).

o This includes defining a set of models describing

the users of the network,
applications running on top of the underlying infrastructure,
the business goals of running the network,
the environment encompassing the network,
and the network itself.

As stated earlier, each of these models may include structure- behavior- and control-
knowledge or a combination of these types.
o E.g. , the structure knowledge may include
the current network topology
and a description of the various components capacities and constraints.

Behavior knowledge can represent (examples):

o a queue operation in case of an overflow (e.g., random drop vs. tail drop)

Control knowledge (examples):

SWMC-Master TSAC2-2015-2016 page 76

 o may specify actions to be applied to the network components (e.g., increasing a
buffer size or blocking an input port).

Sample of the different types of knowledge within an NKBS is presented in thefollowing

Table

Table 4-1 A SAMPLE OF DIFFERENT KNOWLEDGE CLASSES IN ANMS.

4.2.5.2 Approaches to network and system modeling

Current networking systems are highly distributed, complex and heterogeneous; hence,
finding a single common representation requires to define techniques for mapping this
model
o to other ones
o and from other ones.
The developed model must also be robust in capturing the highly dynamic nature of the
environment (e.g., traffic loads, active sessions).

Note: Current approaches for building an NKBS are mainly limited to representing the
network structure knowledge which are commonly referred to as Management
Information Models (MIMs) with some efforts to build simple models for control
knowledge.

The modeled network structure knowledge often includes status information for
different network components such as routers, switches and interfaces.

o Such information typically describes

the current network load,
latency
and different queues and buffers parameters.
o The mgmt information base (MIB) and the common information model (CIM)
developed by the IETF and DMTF are the two widely accepted and used
structure models.
o They are used to describe different network components and their performance
metrics.

SWMC-Master TSAC2-2015-2016 page 77

Note: The Common Information Model (CIM) is an open standard that defines how managed
elements in an IT environment are represented as a common set of objects and relationships
between them. This is intended to allow consistent management of these managed elements,
independent of their manufacturer or provider.

The only standardized model for network control-knowledge is the IETF policy control
information model (PCIM)
o PCIM provides a formalism for defining and storing policies to control the
configurations of individual network components.
o But PCIM is mainly an information model with no means to support analysis,
refinement or reasoning with the defined policies as a first step towards elements
autonomy.

Some authors propose a universal information model that provides a higher

abstraction view that can incorporate both the CIM and MIB models.

Object-oriented models
These aim at capturing both the structural and behavior knowledge of networks
Examples of projects
o NESTOR project This model includes a constraint definition language for
asserting relationships and constraints among different network objects.
o The Directory Enabled Networks-next generation (DEN-ng)
An object-oriented model that describes behavior knowledge using finite
state machines (FSM) and patterns.
The approach still relies on the ability to fully formalize the set of all
possible states for the modeled elements.

Ontologies based models

Recently, ontologies have been introduced to represent the semantics of the managed
networks [10], [11].

[Wikipedia: An ontology is an explicit specification of a conceptualization.

Tom Gruber, A Translation Approach to Portable Ontology Specifications[23]
The data described by an ontology in the OWL family is interpreted as a set of "individuals" and
a set of "property assertions" which relate these individuals to each other.

An ontology consists of a set of axioms which place constraints on sets of individuals

(called "classes") and the types of relationships permitted between them.

These axioms provide semantics by allowing systems to infer additional information

based on the data explicitly provided.

A full introduction to the expressive power of the OWL is provided in the W3C's OWL
Guide.]

Ontologies are one of the main approaches used in the scope of KBS and artificial
intelligence to solve questions related to the semantics of the modeled domain.
They describe an abstract model of a domain by defining

SWMC-Master TSAC2-2015-2016 page 78

 o a set of concepts,
o their taxonomy,
o their interrelation
o and the rules that govern these concepts in a way that can be interpreted by
machines.

The main difference between ontologies and other information models (e.g. CIM, MIB) is
that the latter models do not include axioms, semantic relations or constraints on them
which would facilitate reasoning with them.

Example: A network ontology defined using OWL and a reasoning engine based on first-order
logic (FOL) calculus is described in [11]. The work also investigates the utilization of
semantic concepts such as
o equivalency and
o containment, in order to achieve interpretability between models and commands
defined by different vendors.

Some details on OWL

[
OWL = Web Ontology Language, W3C Recommendation 10 February 2004
W3C = World Wide Web Consortium

From WikiPedia:

The Web Ontology Language (OWL) is a family of knowledge representation languages for
authoring ontologies. The languages are characterised by
o formal semantics

o and RDF/XML-based serializations for the Semantic Web.

OWL is endorsed by the World Wide Web Consortium (W3C)[1] and has attracted academic, medical
and commercial interest.

In October 2007, a new W3C working group[2] was started to extend OWL with several
new features as proposed in the OWL 1.1 member submission. [3]

W3C announced the new version of OWL on 27 October 2009. [4] This new version,
called OWL 2, soon found its way into semantic editors such as Protg and semantic
reasoners such as Pellet,[5][6] RacerPro,[7] FaCT++[8][9] and HermiT.[10]

The Resource Description Framework (RDF) is a family of World Wide Web Consortium
(W3C) specifications originally designed as a metadata data model. It has come to be used as
a general method for conceptual description or modeling of information that is
implemented in web resources, using a variety of syntax formats.

http://www.w3.org/TR/2004/REC-owl-features-20040210/#ref-rdf-schema

The OWL Web Ontology Language is designed for use by applications that need to process
the content of information instead of just presenting information to humans.

SWMC-Master TSAC2-2015-2016 page 79

OWL facilitates greater machine interpretability of Web content than that supported by
XML, RDF, and RDF Schema (RDF-S)
by providing additional vocabulary along with a formal semantics.

OWL has three increasingly-expressive sublanguages: OWL Lite, OWL DL, and OWL Full.

OWL has been designed to meet this need for a Web Ontology Language. OWL is part of the growing
stack of W3C recommendations related to the Semantic Web.

XML provides a surface syntax for structured documents, but imposes no semantic
constraints on the meaning of these documents.

XML Schema is a language for restricting the structure of XML documents and also extends
XML with datatypes.

RDF is a datamodel for objects ("resources") and relations between them, provides a simple
semantics for this datamodel, and these datamodels can be represented in an XML syntax.

RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a
semantics for generalization-hierarchies of such properties and classes.

OWL adds more vocabulary for describing properties and classes: among others, relations
between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing of
properties, characteristics of properties (e.g. symmetry), and enumerated classes.

XML main features

XML stands for EXtensible Markup Language
XML is a markup language much like HTML
XML was designed to carry data, not to display data
XML tags are not predefined. You must define your own tags
XML is designed to be self-descriptive

XML is a W3C Recommendation

The Difference Between XML and HTML

XML is not a replacement for HTML.

XML and HTML were designed with different goals:

XML was designed to transport and store data, with focus on what data is
HTML was designed to display data, with focus on how data looks
HTML is about displaying information, while XML is about carrying information.

Very simple example of XML syntax

<note>
<to>Andrew</to>
<from>James</from>

SWMC-Master TSAC2-2015-2016 page 80

 <heading>Reminder</heading>
<body>Hello body>
</note>
XML is frequently used in design and implementation of the management sytems

NOTE:
The aforementioned models are explicit in the sense that the utilization of the model is
independent from its representation.

Implicit modeling approaches

Reinforcement learning (RL), a machine learning approach, has been applied to build look-up
tables containing state-to-state transition and corresponding actions pairs [12].

In [13], concepts of forecasting functions were utilized to gradually construct a dynamic model
of the effects of various configuration actions on network components parameters.

Note: While implicit learning models are suitable for continuously evolving systems, where they
replace the periodic manual redesign of the NKBS, one limitation of gradual learning models is
their poor performance during the initial phase of learning the model.

Utility Function based models

Recently, some efforts (e.g., [14]) have been dedicated to model system control using
utility functions.
These functions are used, for example, to model service-levels as functions of system
control parameters, allocated resources and expected service demands.

Transfer functions

Transfer functions, used within a control loop, are also utilized [15] to
o represent a server behavior model in response to varying configuration
parameters
o and to model environment noise (e.g., delays and effects of the accuracy of
network monitoring measurements).

Summary of network modelling approach

SWMC-Master TSAC2-2015-2016 page 81

Figure 4-7 Classification of network modeling approaches

SWMC-Master TSAC2-2015-2016 page 82

5 POLICY BASED MANAGEMENT

5.1 Introduction
Policy : the combination of rules and services where rules define the criteria for resource
access and usage.
A policy is formally defined as an aggregation of policy rules.

Each policy rule is composed of a set of conditions and a corresponding set of actions.

The condition defines when the policy rule is applicable. Once a policy rule is activated,
one or more actions contained by that policy rule may be executed. These actions are
associated with either meeting or not meeting the set of conditions specified in the policy
rule

Policy-based systems have become a promising solution for implementing many forms of
large-scale, adaptive systems that dynamically change their behavior in response to
changes in the environment or to changing application requirements.
o This can be achieved by modifying the policy rules interpreted by distributed
entities, without recoding or stopping the system.
Such dynamic adaptability is fundamentally important in the management of increasingly
complex computing systems.

(PBM) : management paradigm that separates the rules governing the behavior of a system
from its functionality.
It promises to reduce maintenance costs of information and communication systems while
improving flexibility and runtime adaptability.

It is today present at the heart of a multitude of management architectures and paradigms,

including
SLA-driven, business-driven, autonomous, adaptive, and self-* management

PBM could relieve the suffering of managing the large computer systems and free the manager
from monitoring the equipments and systems directly and supply a systematic method for
establishing,
revising, and distributing policies.

Policy is a kind of criterion that aims at determining the choice of the actions in an individual
system. The criterion is long-lasting, illustrative, and originated from the target of the
management.

PBM advantages:
When system requirement alters, it is only necessary to change or add some new policies
instead of re-coding.

To make the best use of the resources by flexible distribution of the resources according
to the dynamic information and the different requirements of various service types.

SWMC-Master TSAC2-2015-2016 page 83

 Different users use different policies, and this is convenient for users and at the same
time makes the system more extensible and more maintainable.

Make the system less dependent on the system manager and make the system more
intelligent.

PBM is still immature and need to make improvement.

Figure 5-1 Classification of Network Management Techniques

5.2 PBM Architecture

Several working groups in the IETF and DMTF (Distributed Management Task Force) try to
define a standard policy framework and related protocols.

Policy Management Tool is the server or host where policy management

SWMC-Master TSAC2-2015-2016 page 84

software can do: policy editing policy presentation rule translation rule validation
global conflict resolution

Policy Information Repository is a data store for policy information.

It may be application specific, operating system specific, or an enterprise common repository.

It can: store policy information; search policy information; retrieve policy information

Policy Decision Point (PDP) is the arbitration component for policy evaluation, which evaluates
a state or condition to determine whether a policy enforcement action is required.
PDP can work as
rule locator; device adapter; state resource validation (requirements checking)
policy rule translation; policy transformation

Policy Enforcement Point (PEP) is a network device, such as a router, switch, firewall or host
that enforce the policies received from the PDP.
The policies are enforced (through dynamic configuration changes to access control lists, priority
queues or other parameters) as directed by the policy decision point.
PEP can do
specified Operation by policy rule; optional policy rule validation; feedback

Figure 5-2 The IETF Policy-Based Management Architecture [ ]

LDAP = Lightweight Directory Access Protocol,
COPS = Common Open Policy Protocol,
CLI = Command Line Interface.
It includes the following components:

SWMC-Master TSAC2-2015-2016 page 85

In most implementations of the framework, the Policy Server (Tools), Policy Repository, and
PDP are collocated and may potentially be hosted within the same physical device.

Summary of PBM advantages

providing better-than-best-effort service to certain users
simplifying device, network, and service management
requiring less engineers to configure the network
defining the behavior of a network or distributed system
managing the increasing complexity of programming devices
using business requirements and precedures to drive the configuration of the network

5.3 Policy Based Network Management (PBNM)

In PBNM policies are defined as the rules that govern the states and behaviors of a network.
The management system is tasked with:
the transformation of human-readable specifications of management goals to machine-
readable and verifiable rules governing the function and status of a network,
the translation of such rules to mechanical and device-dependent configurations, and
the distribution and enforcement of these configurations by management entities.

PBNM promotes the automation of establishing management-level objectives over a widerange

of systems devices.
The system administrator would interact with the networks by providing high-level abstract
policies. Such policies are device-independent and are stated in a human-friendly manner.

PBNM can adapt rapidly to the changes in management requirements via run-time
reconfigurations, rather than reengineer new object modules for deployment.

The introduction of new policies does not invalidate the correct operation of a network, provided
the newly introduced policies do not conflict with existing policies. In comparison, a newly
engineered object module must be tested thoroughly in order to obtain the same assurance.

SWMC-Master TSAC2-2015-2016 page 86

6 SOFTWARE DEFINED NETWORKING TECHNOLOGY- SUMMARY

6.1 Introduction
Why SDN?
Future Internet challenges -> need to solve the current Internet limitation and
ossification- as to support global integration of various forms of communications
Evolutionary approach
Clean slate approach
New trends

Software Defined Networks Software Defined Internet Architectures

Cloud computing
(ICN/CCN) Information/Content Centric Networking, (CON) Content Oriented
Networking, (CAN) Content Aware Networking,
Combinations
Current network architectures only partially meet todays requirements

6.1.1 Current network technologies limitations

Complexity that leads to stasis:

Current status : many discrete sets protocols, separately defined for
specific purposes
No fundamental network abstractions -> complexity
To add/move any device, IT admin. must (re) configure multiple specific
HW/SW entities using device-level management tools
Todays networks reconfigurations are performed relatively in static way
(to minimize the risk of service disruption)
The static nature of networks
not good for todays dynamic server environment, (server virtualization,
VM migration)
applications are distributed across multiple virtual machines
(VMs), which exchange traffic flows with each other.
VM migration : challenge for many aspects of traditional
networking (addressing schemes, namespaces segmented, routing-
based design).
Limited capability for dynamic differentiated QoS levels because of usually static
provisioning; not enough capability for dynamic adaptation to changing traffic,
application, and user demands.

Inconsistent policies:
Network-wide policy implementation -> need to configure ~103 - 104 devices
and mechanisms
Todays networks complexity difficult to apply a consistent set of access,
security, QoS, and other policies

Scalability issues:
Complex network (10**5 network devices in data centers)

SWMC-Master TSAC2-2015-2016 page 87

 Over-subscription based on predictable traffic patterns is no more good;
in todays virtualized data centres, traffic patterns are highly dynamic and
it is difficult to predict

Mega-operators (e.g. Google, Yahoo!, Facebook): scalability challenges

The number of of computing elements exploded
data-set exchanges among compute nodes can reach petabytes
Need hyper-scale networks to provide high-performance, low-cost connectivity
among many physical servers (need automation)
Carriers have to deliver better-differentiated services to customers
Multi-tenancy : the network must serve large groups of users with different
applications and needs
Vendor dependency
Carriers/enterprises want rapid response to changing business needs or user
demands
They are limited by vendors equipment product cycles (years)
Lack of standard, open I/F - limits the network operators ability to tailor the
network to their individual environments

6.1.2 Requirements for new network architectures

To answer to
Changing traffic patterns:
Traffic patterns have changed significantly within the enterprise data
center: todays applications access different DBs and servers, creating a
high M2M traffic before returning data to the end user device (different
from classic client-server applications)
Users- network traffic patterns changing: they want access to corporate
content and apps. from any type of device, anywhere, at any time
Enterprises : need of flexible computing model: private public or hybrid
cloud, additional traffic across the WANs
Need of flexible access to IT resources:
Increasing usage of mobile personal devices such as smart-phones,
tablets, and notebooks to access the corporate network
Need to accommodate these personal devices while protecting corporate
data and intellectual property and meeting compliance mandates
Cloud services development:
Significant growth of public and private cloud services ( SaaS, PaaS, IaaS,
NaaS,..) on demand and la carte
ITs needs for cloud services : security, compliance, auditing
requirements, elastic scaling of computing, storage, and network
resources,etc.
Need for more bandwidth:
todays high volume of data requires massive parallel processing on
thousands of inter-connected servers
demand for additional network capacity in the data center
data center networks : need of scaling to very large size, while maintaining
any-to-any connectivity
Media/content traffic high increase- need of more bandwidth

SWMC-Master TSAC2-2015-2016 page 88

6.1.3 SDN approach main features
Software- Defined Networking (SDN) aiming to transform networking
architecture
Open Networking Foundation (ONF- non-profit industry consortium )
OpenFlow I/F specifications for SDN

SDN major characteristics:

the Control Plane (CPl) and Data Planes (DPl) are decoupled
network intelligence and state are logically centralized
underlying network infrastructure is abstracted from the applications
network programability
Note: after many years of strongly defending a completely distributed control approach
in TCP/IP architecture- now a more centralized approach is proposed .

Promises for enterprises and carriers :

higher programmability opportunities, automation, and network control
enabling them to build highly scalable, flexible networks
fast adapt to changing business needs

Source: Software-Defined Networking: The New Norm for Networks ONF White Paper
April 13, 2012

SDN + OpenFlow I/F(first standard) advantages:

high-performance, granular traffic control across multiple vendors network

devices; ability to apply comprehensive and wide-ranging policies at the session,
user, device, and application levels
centralized M&C improving automation and management
common APIs abstracting the underlying networking details from the
orchestration and provisioning systems and applications;
flexibility: new network capabilities and services with no need to configure
individual devices or wait for vendor releases
programmability by operators, enterprises, independent software vendors, and
users (not just equipment manufacturers) using common programming
environments
Increased network reliability and security as a result of centralized and automated
management of network devices, uniform policy enforcement, and fewer
configuration errors
better end-user experience as applications exploit centralized network state
information to seamlessly adapt network behavior to user needs
protects existing investments while future-proofing the network
SDN allows evolution to an extensible service delivery platform capable of
responding rapidly to changing business, end-user, and market needs.

SDN problems/open issues

Centralization
( single point of failures)- reliability
Real time capability of network control
horizontal and vertical scalability
backward compatibility
security

SWMC-Master TSAC2-2015-2016 page 89

 Manufacturers/operator resiliency
etc.

6.1.4 Earlier technologies related to SDN

Open Signaling
OPENSIG WG (~1995)- attempt to make Internet, ATM, and mobile networks
more open, extensible, and programmable"
Ideas: separation between the communication HW and control SW
IETF WG - > General Switch Management Protocol (GSMP
GSMPv3, June 2002, WG has been concluded
general purpose protocol to control a label switch.
establish and release connections across the switch
Active Networking ~1995-2000
- programmable network infrastructure (for customized serviceses)
(1) user-programmable switches, in-band data transfer and out-of-band
management channels
(2) control information organized in capsules, which were program
fragments that could be carried in user messages; program fragments
would then be interpreted and executed by routers.
No large scale / significant success in practice - issues: security and perf.
4D Project [5]~2004, a clean slate design
separation between the routing decision logic and the protocols governing the
interaction between network elements.
Consequences: NOX = operating system for networks in OF context

NETCONF, 2006
IETF Network Configuration WG (still active) : NETCONF defined a
management protocol for modifying the configuration of network devices.
network devices have APIs - (to send /retrieve) configuration data
still - no separation Control/Data Plane

Ethane, 2006- precursor to SDN

new network architecture for enterprise networks
centralized controller to manage policy and security in a network
two components:
a controller to decide if a packet should be forwarded
Ethane switch : a flow table and a secure channel to the controller

IETF WG ForCES Forwarding and Control Element Seperaration, 2003.

A parallel approach to SDN
some common goals with SDN and ONF
Differences:
ForCES: the internal network device architecture is redefined as the
control element separated from the forwarding element, but the combined
entity is still represented as a single network element to the outside world
Aim: to combine new forwarding hardware with third-party
control within a single network device where the separation is kept
within close proximity (e.g., same box or room)
Howevere, in SDN: Contrl Plane (CPl) is totally moved out from net device

SWMC-Master TSAC2-2015-2016 page 90

 FORCES published docs on : arch. framework, interactions, modelling language,
forwarding element (FE) functions, protocol between Ctrl and FE

Early SDN products and activities examples

2008: Software-Defined Networking (SDN) : NOX Network Operating System [Nicira];
OpenFlow switch interface [Stanford/Nicira]
2011: Open Networking Foundation (72 members) : Board: Google, Yahoo, Verizon,
DT, Msoft, Fbook, NTT ; Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,..

6.2 SDN Basic Architecture

Evolutionary architecture ( seamless deployment possible)

CPl and DPl are separated

Network intelligence is (logically) centralized in SW-based SDN controllers, which
maintain a global view of the network.
Execute CPl SW on general purpose HW
Decoupled from specific networking HW
CPl can use use commodity servers
Data Plane (DPl ) is programmable
Maintain, control and program data plane state from a central entity
The architecture defines the control for a network (and not for a network device) The
network appears to the applications and policy engines as a single, logical switch
This simplified network abstraction can be efficiently programmed

Application Layer Application Layer

Appl. 1 Appl. n Appl. n
Appl. 1

Control
API
Plane

Control Network OS
Network Services Layer
( decoupled control logic)

I/F CPl-DPl Secure

(ex. OpenFlow) Channel)

Infrastructure Layer
Abstraction layer
Network Data
Network Plane
Element Element
Flow Table
Switch

Figure 6-1 SDN generic architectture

Control Plane
Control Applications/Program
operates on view of network :
performs different functions ( routing, traffic engineering, QoS,
security, etc.)
Input: global network view (graph/database)
Output: configuration of each network device
Control program is not a distributed system

SWMC-Master TSAC2-2015-2016 page 91

 Abstraction hides details of distributed state
Network OS: distributed system that creates a consistent, global and up-
to-date network view
In SDN it runs can on controllers ( servers) in the network
It creates the lower layer of the Control Plane
Examples: NOX, ONIX, Trema, Beacon, Maestro,

Data Plane : forwarders/switches ( Forwarding elements -FE)

NOS uses some abstraction to:
Get state information from FE
Give control directives to FE

Advantages
Centralization allows:
To alter network behavior in real-time and faster deploy new applications and
network services (hours, days not weeks or months as today).

flexibility to configure, manage, secure, and optimize network resources via

dynamic, automated SDN programs ( not waiting for vendors) .

APIs facilitate implementation of:

common network services: routing, multicast, security, access control, bandwidth
management, QoS, traffic engineering, processor and storage optimization,
energy usage
policy management, custom tailored to meet business objectives
Easy to define and enforce consistent policies across both wired and
wireless connections on a campus

SDN control and applications layers, business apps can operate on an abstraction of the
network, leveraging network services and capabilities without being tied to the details of
their implementation
Manage the entire network : intelligent orchestration and provisioning systems
ONF studies open APIs to promote multi-vendor management:
possibility for on-demand resource allocation, self-service
provisioning, truly virtualized networking, and secure cloud services.

SWMC-Master TSAC2-2015-2016 page 92

 Control Program
Application Application Application
Routing Traffic engineering QoS control

Abstract
API Network
view
Network Virtualization
Consistent updated
global
network view
Network OS

Control
Plane
Open I/F to Packet
Forwarding
e.g. OpenFlow

Swich/
Router
Swich/
Router Swich/
Router
Swich/ Forwarding
Router

Swich/ Data
Router Swich/ Plane
Flow Router
Table

Figure 6-2 Basic SDN architecture

NOS = Network Operating System

Network OS:
Distributed system that creates a consistent, updated network view
Executed on servers (controllers) in the network
Examples: NOX, ONIX, HyperFlow, Floodlight, Trema, Kandoo, Beacon,
Maestro,..
Uses forwarding abstraction in order to:
Collect state information from FE
Generate commands to FE

OpenFlow summary
the first SDN standard communications: CPl-DPl I/F

allows direct access to the Fwd. Plane of network devices (FE = switches and
routers), both physical and virtual (hypervisor-based)

allows to move CPl out of the FEs to logically centralized control software

specifies basic primitives to be used by an external SW application to program the

FwdPl (~ instruction set of a CPU)

Flow concept : to identify network traffic based on pre-defined match rules that
can be statically or dynamically programmed by the SDN control SW

SWMC-Master TSAC2-2015-2016 page 93

 network can be programmed on a per-flow basis ( provides if wanted-
extremely granular control), enabling the network to respond to real-time changes
at the application, user, and session levels

allows IT admin to define how traffic should flow through FEs based on
parameters such as usage patterns, applications, and cloud resources

Open flow capable switches

Source Ref1: OpenFlow: Enabling Innovation in Campus Networks- N.McKeown,

T.Anderson, H.Balakrishnan, G.Parulkar, L.Peterson, J.Rexford, S.Shenker, J.Turner

OpenFlow Switch
Specification scope

Router/
Switch
OpenFlow OpenFlow
Protocol

SW Secure
channel
SSL
Controller

HW Flow
Table

Figure 6-3 Idealized OpenFlow Switch.

The Flow Table is controlled by a remote controller via the Secure Channel.

Commercial switch
OpenFlow capable OpenFlow
SDN
Controller
Traditional Secure
Ctrl. SW channel Server
OpenFlow OpenFlow Farm
& Acces
Traditional Flow Point
DPl Tables

WLAN

Figure 6-4 Example of a network of OpenFlow-enabled commercial switches and routers.

SWMC-Master TSAC2-2015-2016 page 94

Figure 6-5 Example of fields characterising a flow

6.3 SDN Applications

6.3.1 Enterprise Networks

SDN unify and improve M&C;
support to programmatically enforce/ adjust network policies as well as help net
monitoring and tune performance.

eliminate middleboxes (NAT, firewalls, load balancers, access control, DPI, etc.)
by integrating their functionality within the controller

configuration changes (currently- common networks instability source) can be

performed in a more flexible and consistent way

a set of high-level abstractions are proposed that allow admin to update the entire
network

packets are processed in consistent way at network level based on flow concepts

6.3.2 Data Centers

High volume and dynamic traffic, large scale
Management and policy enforcement is critical especially to avoid service
disruption.
Still some Data Center are provisioned based on estimation of peak demand
(-) high percentage of time under-utilization
(+) but answer to high demand is very fast

Figure 6-6 Basic layered design of data center network infrastructure

Aggregation/acces and mobile-backhaul networks (AAN)

Dynamic service-chaining ( source: Ericsson)

SWMC-Master TSAC2-2015-2016 page 95

 Usually for inline services (DPI, firewalls (FWs), NAT, etc.), operators use
special middleboxes hosted on HW/VMs.
Service chaining is required to route certain subscriber traffic through more than
one such service.
Today: no protocols or tools to perform flexible, dynamic traffic steering
Currently solutions : static or non-flexible solutions
Packet-optical integration
Virtual Home Gateway (VHG)
Home Networks (HN) and Small Business

Figure 6-7 Cloud computing Architecture

Energy consumption important in big Data Centers (10-20% for networking) need
of better energy management
Proposal: SDN based Network-wide power management, (elastic tree, savings
20-65% depending on traffic conditions-have been shown)

Savings can be increased if used in cooperation with server management and

virtualization
controlling the migration of VMs as to increase the number of machines
and switches that can be shut down
however such traffic management must be balanced with scalability and
performance overheads.

Other Issues :OF sometimes excessively centralises control processing while only few
significant" flows need to be managed bottlenecks in the control communication ( if fine
granularity is wanted)

Solutions: proactive policies and wild-card rules, but the cost is paid with less to
manage traffic and gather statistics.

Proposals done: design changes like

SWMC-Master TSAC2-2015-2016 page 96

 keep control of flows as much as possible in the data plane while
maintaining enough visibility at controller level for effective flow
management.
pushing back again responsibility on many flows to the switches and
adding more efficient statistics collection mechanisms, for significant"
flows (e.g. long-lived, high-throughput) identified and managed by the
controller.
Effect: reducing the control overhead and having fewer flow table entries

6.3.3 Service Provider -SDN Approach

There is a strong interest of SP/NP for SDN developments

Source: SDN: the service provider perspective, Ericsson Review, February 21, 2013

Figure 6-8 Service Provider domains to apply SDN

Aggregation/acces and mobile-backhaul networks (AAN)

Dynamic service-chaining ( source: Ericsson)
Usually for inline services (DPI, firewalls (FWs), NAT, etc.), operators use
special middleboxes hosted on HW/VMs.
Service chaining is required to route certain subscriber traffic through more than
one such service.
Today: no protocols or tools to perform flexible, dynamic traffic steering
Currently solutions : static or non-flexible solutions
Packet-optical integration
Virtual Home Gateway (VHG)
Home Networks (HN) and Small Business

SWMC-Master TSAC2-2015-2016 page 97

 SDN approach

Figure 6-9 Examples of SDN solutions applied in SP subsystems

6.3.3.1 Policy Based Dynamic Servicer Chaining - example

Dynamic service-chaining ( source: Ericsson)

Usually for inline services (DPI, firewalls (FWs), NAT, load balancers, etc.),
special middleboxes are used hosted on HW/VMs.
Service chaining = forwarding a traffic flow traffic through one service.

Today: static or non-flexible solutions

no protocols or tools to perform flexible, dynamic traffic steering

Dynamic service-chaining
special services use optimization: selectively steering traffic through
specific services or bypassing them (avoid over-dimensioning-> capex
savings)

operators can offer : virus scanning, firewalls, content filters through an

automatic selection and subscribe portal, etc.
SDN - can support dynamic service chaining ( e.g. Ericsson - proof of concepts)
logically centralized OF-CE manage switches and middleboxes
service chains can be differentiated on subscriber behavior, application,
traditional 5-tuple, required service

Service paths are unidirectional- can be different for upstream and downstream
traffic.
Traffic steering has two phases
1. Classification of the incoming packets; assignment of a service path
to them, based on predefined policies.
2. Packets are then forwarded to the next service, based on the current
position in their assigned service path
No repeating classification is required; hence the solution is scalable.

The SDN CE can flexibly set up and reconfigure service chains

SWMC-Master TSAC2-2015-2016 page 98

 The dynamic reconfiguration of service chains needs a mechanism to handle notifications
sent from middle-boxes to the controller.
-e.g. , the DPI engine notifies CE ( via extended OF) that it has recognized a
video flow.

Virtual Network System (VNS) - concept ( source: Ericsson)- environment where

one can apply dynamic service chaining
VNS: domain of the network with centralized CPl (this excludes some traditional
control agents)
API- OpenFlow, controls the forwarders
VNS can create northbound I/Fs APIs to support creation of new features,
e.g. service chaining
The services provided may reside on devices located in different parts of the network, or
within an edge router e.g. Ericssons Smart Services Router (SSR)

Service chains are programmed (cf. operator policies) based on a combination of

information from the different layers (L2-L4. ..)
Dynamic service-chaining (contd) - example
Traffic goes first thrugh DPI + FW
After flow type has been determined (DPI) the operator may decide to
modify the services applied to it.

Example: internet video stream flow

- it may no longer need to pass the FW service after the service type has been detected

- the subsequent packets of the same flow may no longer need to pass the DPI service
either ( shorter- blue path)

Figure 6-10 Dynamic service chaining Source Ericsson

Source: SDN: the service provider perspective, Ericsson Review, February 21, 2013

SWMC-Master TSAC2-2015-2016 page 99

6.3.3.2 Bandwidth on Demand ( BWoD)- Example

Source: Operator Network Monetization Through OpenFlow-Enabled SDN, ONF
Solution Brief, April 3, 2013,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-
briefs/sb-network-monetization.pdf
WAN bandwidth demand ratio peak info rate/mean rate ~ 10 to 20 (cloud
networking, ad hoc inter-enterprise collaboration, etc.)
peaks duration very variable: 1 hour or less to several weeks or more.
Contracting Peak Information Rate ( PIR) is costly and wasteful.

Bandwidth on Demand (BWoD) dynamically adjustable if wanted ( pay what

you consume)
Connection types: subscribers; subscriber to a service GW (e.g., a cloud
data center); subscriber to a third-party interconnect point.

Current model of BWoD services (limited number of operators)
Lack of automation difficult to roll out self-provisioned services and
respond to time-sensitive changes in bandwidth requirements.
customers are given some control; they invoke the services through a
portal but very limited in scope.
Frequent changes in a distributed control environment sometimes lead to
transient overloads congestion and instability.
Lack of a standard I/F operators today must interface their OSS/BSS
systems to a vendor-specific network infrastructure. (need to redesign
control applications for each vendor)

SDN Solution : BWoD from an OF - SDN architecture with a programmatic north API
operators have centralized, granular control over the networking infrastructure.

Customers can automatically request dynamic changes to bandwidth allocation and other
QoS parameters at the packet and/or optical layers, either immediately or scheduled in
the future.

The SDN control layer can leverage topology-aware path computation to cost-effectively
enable bandwidth on demand.

SDN : real-time topological view of the network,

enables network virtualization, and
allows network bandwidth reservation to provide guaranteed performance on a
per-connection or flow basis to meet SLA requirements.

SWMC-Master TSAC2-2015-2016 page 100

Figure 6-11 Example of Bandwidth on demand SDN solution
SDNs global view of network resource supply and customer demands intelligent and
dynamic BWoD pricing.

An analytics engine could evaluate current supply and demand as well as

historical temporal demand peaks and supply.

Through continual learning of the price elasticity of demand, these adjustments

can become more refined, enabling the analytics engine to maximize network
revenue per bit.

Network virtualization allows operators to leverage the same networking and operational
infrastructure on which they deliver traditional services to create BWoD services and
new billing models.

OpenFlow switch ( forwarder)- architecture

Source: OpenFlow Switch Specification, V1.3.0 and V 1.4.0 (Wire Protocol 0x05 )Oct.
2014 ( only for Ethernet)

6.4 SDN OpenFlow summary

6.4.1 ONF Key Definitions for OF switch (partial list)

Action: an operation that forwards the packet to a port, modifies the packet (such as
decrementing the TTL field) or change its state (such as associating it with a queue).

Actions may be specified as part of the instruction set associated with a flow entry
or in an action bucket associated with a group entry.
Actions may be accumulated in the Action Set of the packet or applied
immediately to the packet

Action Bucket: a set of actions and associated parameters in a group. The group will
select one (or more) buckets for each packet.

SWMC-Master TSAC2-2015-2016 page 101

 Action Set: a set of actions associated with the packet that are accumulated while the
packet is processed by each table and that are executed when the instruction set instructs
the packet to exit the processing pipeline
Control Channel: The aggregation of components of an OF logical switch that manage
communication with controllers.
The control channel includes one OF channel per OF controller.
Counter: counts the number of packets and bytes at various specific points of the
pipeline, such as on a port or on a flow entry
Flow: a sequence of packets having one or more fields identical in various headers
( do not associate a flow with a route!)
Flow Entry: an element in a flow table used to match and process packets.
It contains a set of match fields for matching packets, a priority for matching
precedence, a set of counters to track packets, and a set of instructions to apply
Flow Table: a stage of the pipeline. It contains flow entries.
Group: a list of action buckets and some means of choosing one or more of those
buckets to apply on a per-packet basis.
Instruction: are attached to a flow entry and describe the OF processing that happens
when a packet matches the flow entry.
An instruction
either modifies pipeline processing, such as directing the packet to another
flow table,
or contains a set of actions to add to the actionset,
or contains a list of actions to apply immediately to the packet.
Match Field:a field against which a packet is matched, including packet headers, the
ingress port, and the metadata value. A match field may be wildcarded (match any value)
and in some cases bitmasked.
Matching: comparing the set of header fields and pipeline fields of a packet to the match
fields of a flow entry
Metadata: a maskable register value that is used to carry information from one table to
the next.
Message: OF protocol unit sent over an OF connection. May be a request, a reply, a
control message or a status event.
Meter: an element that can measure and control the rate of packets. The meter can
trigger a meter band if the packet rate or byte rate passing through the meter exceeds a
predefined threshold.
If the meter band drops the packet it is called Rate Limiter
OF Logical Switch: A set of OF resources that can be managed as a single entity,
includes a data path and a control channel.
Packet: an Ethernet frame, including header and payload.
Pipeline: the set of linked flow tables that provide matching, forwarding, and packet
modification in an OF switch
Port: where packets enter and exit the OpenFlow pipeline May be a physical port, a
logical port defined by the switch, or a reserved port defined by the OpenFlow protocol.
Pipeline fields: set of values attached to the packet during pipeline processing which are
not header fields. Include the ingress port, the metadata value and the Tunnel-ID value.
Queue: Schedule packets according to their priority on an output port to provide Quality-
of-Service (QoS).
Tag: a header that can be inserted or removed from a packet via push and pop actions.
Outermost Tag: the tag that appears closest to the beginning of a packet.

SWMC-Master TSAC2-2015-2016 page 102

6.4.2 OpenFlow switch components and basic functions

OpenFlow (OF) protocol runs over the Secure Sockets Layer (SSL).
Each switch is connected to other OF switches and, possibly, to end-user devices
that are the sources and destinations of packet flows.
In a switch, a series of tablesimplemented in HW or firmwareare used to
manage the flows of packets through the switch.
The switch
encapsulates and forwards the first packet of a flow to an SDN controller,
which decides whether the flow should be added to the switch flow table.
It forwards incoming packets out the appropriate port based on the flow
table.
The flow table may include priority information dictated by the
controller.
It can drop packets on a particular flow, temporarily or permanently, as
dictated by the controller.
Packet dropping can be used for security purposes, to solve
Denial-of-Service (DoS) attacks or traffic management
requirements.

An OF Switch contains :
one or more flow tables and a group table, which perform packet lookups and
forwarding,
and an OF channel to an external controller

The controller manages the switch via the OF protocol.

The controller can add, update, and delete flow entries in flow tables, both
reactively (in response to packets) and proactively.

Flow table : a set of flow entries; each flow entry consists of match fields, counters, and a
set of instructions to apply to matching packets
Matching starts at the first flow table and may continue to additional flow tables
Flow entries match packets in priority order, with the first matching entry in each
table being used.
If a matching entry is found, the instructions associated with the specific flow
entry are executed.
If no match is found in a flow table, the outcome depends on configuration of the
table-miss flow entry:
for example, the packet may be forwarded to the controller over the OF
channel, dropped, or may continue to the next flow table
A Meter Table can trigger a variety of performance-related actions on a flow
Instructions associated with each flow entry either contain actions or modify pipeline
processing
Actions included in instructions describe packet forwarding, packet modification and
group table processing.
Pipeline processing instructions allow packets to be sent to subsequent tables for further
processing and allow information, in the form of metadata, to be communicated between
tables.
Table pipeline processing stops when the instruction set associated with a
matching flow entry does not specify a next table; at this point the packet is
usually modified and forwarded

SWMC-Master TSAC2-2015-2016 page 103

 Flow entries may forward to a port (physical port/logical/reserved port )
Reserved ports may specify generic forwarding actions such as sending to the
controller, flooding, or forwarding using non-OF methods, such as normal"
switch processing
while switch-defined logical ports may specify link aggregation groups, tunnels or
loopback interfaces

Actions associated with flow entries may also direct packets to a group, which
specifies additional processing
A FT may direct a flow to a Group Table, which may trigger a variety of actions
that affect one or more flows
The group table contains group entries;
each group entry contains a list of action buckets with specific semantics
dependent on group type
The actions in one or more action buckets are applied to packets sent to
the group.
Groups represent sets of actions for flooding, or more complex forwarding
semantics (e.g. multipath, fast reroute, and link aggregation).
As a general layer of indirection, groups also enable multiple flow entries
to forward to a single identifier (e.g. IP forwarding to a common next
hop).
This abstraction allows common output actions across flow entries to be
changed eficiently.

SWMC-Master TSAC2-2015-2016 page 104

Figure 6-12 Main components of an OpenFlow switch

Switch designers are free to implement the internals in any way convenient, provided that
correct match and instruction semantics are preserved.
Ex. 1: while a flow entry may use an all group to forward to multiple ports, a
switch designer may choose to implement this as a single bitmask within the
hardware forwarding table.

Ex. 2: is matching; the pipeline exposed by an OF switch may be physically

implemented with a different number of hardware tables.

A flow table consists of flow entries.

Each flow table entry contains:
match fields: to match against packets. These consist of the ingress port and
packet headers,and optionally metadata specfied by a previous table.
priority: matching precedence of the flow entry.
counters: updated when packets are matched.
Examples include the number of received bytes and packets per port, per
flow table, and per flow-table entry; number of dropped packets; and
duration of a flow.
instructions: to modify the action set or pipeline processing.
timeouts: maximum amount of time or idle time before ow is expired by the
switch.
cookie: opaque data value chosen by the controller.
May be used by the controller to filter flow statistics, flow modication and
flow deletion. Not used when processing packets.
A flow table may include a table-miss flow entry, which renders all Match Fields
wildcards (every field is a match regardless of value) and has the lowest priority
(priority 0).

Packet s are matched against

tables in pipe-line
Packet+ OpenFlow SWitch
a. Port_in+
metadata
Port_in Packet Execute
Table Table action
Table
1 n set
0 Packet
Packet out
in
Action Set Action Set Action Set
()

Match fields: Match fields:

Port _in+ Port _in+
Metadata+ Metadata+
Packet Header (2) Packet Header

Action set Flow-

Table Action set
(1)
b. (3)

Figure 6-13 Packet flow through the processing pipeline.

Find highest-priority matching flow entry
Apply instructions:
i. Modify packet & update match fields (apply actions instruction)
ii. Update action set (clear actions and/or write actions instructions)
iii. Update metadata

SWMC-Master TSAC2-2015-2016 page 105

 Send match data and action set to next table

Flowchart detailing packet flow through an OpenFlow switch. ( v1.4.0)

The switch starts by performing a table lookup in the first flow table, and based on
pipeline processing, may perform table lookups in other flow tables

Figure 6-14 Flow processing

Figure 6-15 Alternative view of flow processing

OpenFlow : Flow Table components

The Match Fields component of a table entry consists of the following required fields:

SWMC-Master TSAC2-2015-2016 page 106

 Ingress Port: The identifier of the port on the switch where the packet arrived. It may be
a physical port or a switch-defined virtual port.
Ethernet Source and Destination Addresses: Each entry can be an exact address, a
bitmasked value for which only some of the address bits are checked, or a wildcard value
(match any value).
IPv4 or IPv6 Protocol Number: A protocol number value, indicating the next header in
the packet.
IPv4 or IPv6 Source Address and Destination Address: Each entry can be an exact
address, a bitmasked value, a subnet mask value, or a wildcard value.

TCP Source and Destination Ports: Exact match or wildcard value.

User Datagram Protocol (UDP) Source and Destination Ports: Exact match or wildcard
value.

Optional fields (partial list):

Address Resolution Protocol (ARP) Opcode: Exact match in Ether-net Type field.
Source and Target IPv4 Addresses in Address Resolution Protocol (ARP) Payload: Can
be an exact address, a bitmasked value, a subnet mask value, or a wildcard value.

IPv6 Flow Label: Exact match or wildcard.

ICMPv6 Type and Code fields: Exact match or wildcard value.
IPv6 Neighbor Discovery Target Address: In an IPv6 Neighbor Discovery message.
IPv6 Neighbor Discovery Source and Target Addresses: Link-layer address options in
an IPv6 Neighbor Discovery message.
Multiprotocol Label Switching (MPLS) Label Value, Traffic Class, and Bottom of
Stack (BoS): Fields in the top label of an MPLS label stack.

The instructions component of a table entry consists of a set of instructions that are
executed if the packet matches the entry.

The OpenFlow specification includes the following actions:

Output: Forward packet to specified port.
Set-Queue: Sets the queue ID for a packet.
When the packet is forwarded to a port using the output action, the queue
id determines which queue attached to this port is used for scheduling and
forwarding the packet.
Forwarding behavior is dictated by the configuration of the queue and is
used to provide basic QoS support.

Group: Process packet through specified group.

SWMC-Master TSAC2-2015-2016 page 107

 Push-Tag/Pop-Tag: Push or pop a tag field for a VLAN or MPLS packet.

Set-Field: The various Set-Field actions are identified by their field type; they
modify the values of respective header fields in the packet.

Change-TTL: The various Change-TTL actions modify the values of the IPv4
Time To Live (TTL), IPv6 Hop Limit, or MPLS TTL in the packet.

6.4.3 OpenFlow Protocol summary

OpenFlow Protocol messages
Controller-to-Switch: initiated by the controller and, in some cases, require a response from the
switch.
This class of messages enables the controller to manage the logical state of the switch,
including its configuration and details of flow- and group-table entries.

Also included in this class is the Packet-out message.

This message is used when a switch sends a packet to the controller and the
controller decides not to drop the packet but to direct it to a switch output port.

Asynchronous: are sent without solicitation from the controller.

This class includes various status messages to the controller. Also included is the Packet-
in message, which may be used by the switch to send a packet to the controller when
there is no flow-table match.

Symmetric: sent without solicitation from either the controller or the switch.

Hello messages are typically sent back and forth between the controller and switch when
the connection is first established.

Echo request and reply messages can be used by either the switch or controller to
measure the latency or bandwidth of a controller switch connection or just verify that the
device is operating. The Experimenter message is used to stage features to be built into
future versions of OpenFlow.

SWMC-Master TSAC2-2015-2016 page 108

Figure 6-16 Open Flow messages

6.4.4 OpenFlowManagement and Configuration Protocol (OF-CONFIG)

ONF is developing an standard configuration and management protocol of an operational Context which
is complementary to OpenFlow protocol. Versions: v1.1 2012, v1.2- 2014.

Currently there is work underway on two configuration and management protocols for OF
switches: OF Management and Configuration Protocol (OF-Config) and Open vSwitch Database
Management Protocol.

Motivation

The OF protocol assumes that an OF datapath (e.g. an Ethernet switch which supports the OF protocol)
has been configured with various artifacts such as the IP addresses of OF controllers.

OF-CONFIG enables the remote configuration of OF datapaths. While the OF protocol generally operates
on a time-scale of a flow (i.e. as flows are added and deleted), OF-CONFIG operates on a slower time-
scale.
Example is building forwarding tables and deciding forwarding actions which are done via OF
protocol while enabling/disabling a port can be done via OF-Config protocol.

OF-CONFIG frames an OF datapath as an abstraction called an OF Logical Switch.

SWMC-Master TSAC2-2015-2016 page 109

The OF-CONFIG protocol enables configuration of essential artifacts of an OF Logical Switch so that an
OF controller can communicate and control the OF Logical switch via the OF protocol.

OF-CONFIG 1.1 introduces an operating context for one or more OF datapaths called an OF Capable
Switch.

Figure 6-17 An OF Configuration Point communicates with an operational context which is capable of
supporting an OF Switch using the OF Configuration and Management Protocol (OF-CONFIG)

Terminology

OF Capable Switch
physical or virtual switching device which can act an as operational context for an OF Logical Switch. OF
Capable Switches contain and manage OF Resources which may be associated with an OF Logical
Switch context.

OF Configuration Point
It configures one or more OF Capable Switches via the OF Configuration and Management Protocol (OF-
CONFIG).

OF Logical Switch
It is a set of resources (e.g. ports) from an OF Capable Switch which can be associated with a specific OF
Controller. An OF Logical switch is an instantiation of an OF Datapath.

OF Resource
It is a resource (e.g. port or queue) associated with an OF Capable Switch and may be associated with an
OF Logical Switch.

OF Queue
It is a queuing resource of an OF Logical Switch as described in the OF specification as the queue
component of an OF datapath.

OF Port
An OF Port is a forwarding interface of an OF Logical Switch as described in the OF specification as the
port component of an OF datapath. An OF Port may map to a physical port on a physical switch or a
logical port on a physical or virtual switch.

Basic characteristics

SWMC-Master TSAC2-2015-2016 page 110

An OF Capable Switch is intended to be equivalent to an actual physical or virtual network element (e.g.
an Ethernet switch) which is hosting one or more OF datapaths by partitioning a set of OF related
resources such as ports and queues among the hosted OF datapaths.

The OF-CONFIG protocol enables dynamic association of the OF related resources of an OF Capable
Switch with specific OF Logical Switches which are being hosted on the OF Capable Switch.

OFCONFIG does not specify or report how the partitioning of resources on an OF Capable Switch is
achieved.

OF-CONFIG assumes that resources such as ports and queues are partitioned amongst multiple OF
Logical Switches such that each OF Logical Switch can assume full control over the resources that is
assigned to it.

OF-CONFIG 1.1 makes simplifying assumptions about the architecture of OF switches. The specification
is deliberately decoupled from whether the switch supports flowvisor or other virtualization models.

The service which sends OF-CONFIG messages to an OF Capable Switch is called an OF Configuration
Point.
No assumptions are made about the nature of the OF Configuration Point. For example, it may be
a service provided by SW acting as an OF controller or it may by a service provided by a
traditional network management framework.
Any interaction between the OF Configuration Points and OF controllers is outside the scope of
OF-CONFIG 1.1.

Figure 6-18 Relationship between components defined in the OF-CONFIG protocol and the OF protocol

Scope of the OF-CONFIG v1.1

OF-CONFIG 1.1 is focused on the following functions needed to configure an OpenFlow 1.3 (OFv1.2)
datapath:
The assignment of one or more OF controllers
The configuration of queues and ports
The ability to remotely change some aspects of ports (e.g. up/down)
Configuration of ceritificates for secure communication between the OF Logical Switches and
OF Controllers
Discovery of capabilities of an OF Logical Switch

SWMC-Master TSAC2-2015-2016 page 111

 Configuration of a small set of tunnel types such as IP-in-GRE, NV-GRE, VxLAN

While limited in scope, OF-CONFIG 1.1 lays the foundation on top of which various automated
and more advanced configurations will be possible in future revisions.

Outside the scope of OF-CONFIG 1.1 : Switch discovery, topology discovery, capability configuration,
event triggers, versioning, instantiation of OF Logical Switches, assignment of resources such as ports
and queues to OF Logical Switches, and bootstrap of the OpenFlow capable network are protocol. (it will
be in future versions).

Table 2 OF-SWITCH and OF-CONFIG comparison ( from OF-CONFIG spec v1.2)

OF-Config details

OF Mgmt and Config Protocol version 1.1 (OF-Config), 2012, has been released by ONF
The OF-Config protocol addresses the following components of controller-switch management:
a. OF configuration point: The OF-Config point issues OF-Config commands.

SWMC-Master TSAC2-2015-2016 page 112

 b. OF capable switch: A physical or virtual switching device contains a number of ports and
queues.
c. OF logical switch: A logical switch within the OF capable switch allocates a subset of the
ports and queues that make up an OF capable switch.

The OF-Config Point can be located in the same server or workstation as an OF controller or
within traditional network management products.
Configuration points can manage multiple OF-capable virtual or physical switches.
A configuration point may manage multiple OF capable switches, and a capable switch may be
managed by more than one configuration point.
The configuration point also communicates with OF logical switches that live within the OF
capable switch.
Specifically the control point supplies each logical Switch with the IP addresses and port
numbers of the OF controllers that will control individual packet flows through the switch.
It also specifies whether TCP or TLS will be used to communicate between the switch and
controller, and it configures certificates for communications between switches and controllers.

Each OF logical switch operates independently of the other logical switches within the same OF
capable switch.
A configuration point can discover the resources allocated to a logical switch, configure tunnels,
set port parameters, turn ports off and on, and retrieve switch status.

It receives error codes from a switch if a configuration operation fails and it can roll back the
operation in the event of a partial failure.
Implementing OF-Config in a switch requires modifying the switch's internal configuration
database and implementing the Netconf Protocol RFC (6241) to communicate between
configuration points and switches. Netconf uses XML encoding for configuration data and
protocol messages.

Configuration data is sent to, and retrieved from, switches using remote procedure calls. Netconf
can send or retrieve full and partial configuration descriptions and can convey asynchronous
notifications from the switch.

Netconf is extensible, so it will continue to support OF-Config as future capabilities are added.
Configuration points can retrieve switch configuration capabilities, so a configuration point
upgraded to a later OF-Config version can continue to support a switch that has not yet been
upgraded.
The OF-Config 1.1.1 specification contains UML diagrams XML examples and the full XML
schema defining configuration capabilities.

SWMC-Master TSAC2-2015-2016 page 113

7 REFERENCES

[1] ITU-T Recommendation, SERIES M 3000: Telecommunications management network

Principles for a telecommunications management network
[2] ITU-T Rec. Y.2001, General Overview of NGN.
[3] ITU-T Rec. Y.2011, General Principles and General Reference Model for Next
Generation Network.
[4] Keith Knightson, Naotaka Morita, NGN Architecture: Generic Principles, Functional
Architecture, and Implementation, IEEE Communications Magazine , October 2005
[5] Jianguo Ding, 2010, Advances in Network Management, CRC Press , Auerbach
Publications, 2010.
[6] http://en.wikipedia.org/wiki/Element_management_system
[7] http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
[8] http://www.faqs.org/rfcs/rfc1157.html
[9] N. Agoulmine, et. Al., Autonomic Network Management Principles: From Concepts to
Applications. Academic Press, 2010.
[10] N.Samaan and A.Karmouch, Towards Autonomic Network Management: an Analysis of
Current and Future Research Directions, IEEE COMMUNICATIONS SURVEYS &
TUTORIALS, VOL. 11, NO. 3, THIRD QUARTER 2009
[11] Y. Yemini, A.V. Konstantinou and D. Florissi, NESTOR: an architecture for network
self-management and organization, IEEE J. Select.Areas Commun., vol. 18, n. 5, pp.
758766, 2000.
[12] S. Judd and J. Strassner, Directory-enabled networks: Information model and base
schema, 1998.
[13] J. Strassner, DEN-ng: achieving business-driven network management, in Network
Operations and Management Symposium, 2002.NOMS, pp. 753766, 2002.
[14] L. Stojanovic, J. Schneider, A. Maedche, S. Libischer, R. Studer, Th.Lumpp, A. Abecker,
G. Breiter and J. Dinger, The role of ontologies in autonomic computing systems, IBM
Syst. J., vol. 43, n. 3, pp. 598616, 2004.
[15] A.K.Y. Wong, P. Ray, N. Parameswaran and J. Strassner, Ontology mapping for the
interoperability problem in network management, IEEE J. Select. Areas Commun., vol.
23, n. 10, pp. 20582068, Oct. 2005.
[16] G. Tesauro, Reinforcement Learning in Autonomic Computing: A Manifesto and Case
Studies, IEEE Internet Comput., vol. 11, n. 1,pp. 2230, Jan.-Feb. 2007.
[17] N. Samaan and A. Karmouch, An Automated Policy Based Management Framework for
Differentiated Communication Systems, IEEE J.Select. Areas Commun., vol. 23, n. 12,
pp. 22362247, December 2005.
[18] William E. Walsh, Gerald Tesauro, Jeffrey O. Kephart and Rajarshi Das, Utility
Functions in Autonomic Systems, in International Conferenceon Autonomic Computing
(ICAC-04), 2004.

SWMC-Master TSAC2-2015-2016 page 114

[19] Diao Y., J. Hellerstein, S. Parekh, R. Griffith, G.E. Kaiser and D. Phung, control theory
foundation for self-managing computing systems, IEEEJ. Select. Areas Commun., vol.
23, n. 12, pp. 2213 2222, Dec. 2005.
[20] Jianguo Ding, 2010Advances in Network Management, CRC Press , Auerbach
Publications, 2010.
[21] http://en.wikipedia.org/wiki/Element_management_system
[22] http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
[23] http://www.faqs.org/rfcs/rfc1157.html
[24] IRTF Autonomic Networking - Definitions and Design Goals,
draft-irtf-nmrg-autonomic-network-definitions-04.txt, October 2014
[25] Cisco: Autonomic Networking Infrastructure, Nov. 2014,
http://www.cisco.com/c/en/us/td/docs/wireless/asr_901/Configuration/Guide/b_asr901-
scg/b_asr901-scg_chapter_0101001.html
[26] N.McKeown, T.Anderson, et. Al., OpenFlow: Enabling Innovation n Campus Networks,
- http://www.openflow.org/documents/openflow-wp-latest.pdf.
[27] M.Mendonca, et. al., A Survey of Software-Defined Networking: Past, Present,and
Future of Programmable Networks, http://hal.inria.fr/hal-00825087/
[28] OpenFlow Switch Specification, V 1.3.0 (Wire Protocol 0x04 ) June 25, 2012
[29] SDN for cloud providers and enterprises:
http://h17007.www1.hp.com/docs/interopny/4AA4-3872ENW.pdf
[30] SDN Technical White Paper http://h17007.www1.hp.com/docs/interopny/4AA4-
3871ENW.pdf
[31] Software-Defined Networking: The New Norm for Networks ONF White Paper April 13,
2012
[32] SDN: the service provider perspective, Ericsson Review, February 21, 2013
[33] S. H.Yeganeh, et.al., On Scalability of Software-Defined Networking, IEEE Comm.
Magazine, February 2013.
[34] ONF 2012 OF--CONFIG 1.1 OpenFlow Management and Configuration Protocol
[35] ONF 2014 OF--CONFIG 1.2 OpenFlow Management and Configuration Protocol
[36]

SWMC-Master TSAC2-2015-2016 page 115