A Network Management Architecture
proposal for the GEANT-NREN environment
Pavle Vuletić, Afrodite Sevasti
TNC 2010, 31.5.-3.6.2010, Vilnius, Lithuania
connect • communicate • collaborate
GEANT – NREN environment
Advanced communications’ infrastructure serving research and
education community in Europe.
Multi-layer organization - at least: campus networks of end institutions,
NRENs and the GÉANT backbone.
Multitude of different technologies in use, operational procedures,
network management subsystems and procedures
One of the main aims within the GÉANT-NREN environment is the
delivery of advanced connectivity, network support and access services
for projects, institutions and end users.
Services and service support tools typically developed from scratch: no
OSS systems in NRENs
Unique network management framework for the development of service
support systems is needed in order to provide interoperability between
tools, optimal design, automated operations
connect • communicate • collaborate
Network management evolution
90’s
Device management
perspective – Network
management meant device
control and monitoring
SNMP – Simple Network
Management Protocol
management
2000’s
Network Management means
network
much wider set of activities
management
Service-centric or user-centric networking
approach
Emphasis on service
provisioning and
management, designing
OSS/BSS tools
“Old” network management is
only one part of the overall
activity
software
design
connect • communicate • collaborate
Network management standards
We analyzed various NM related standards:
TeleManagementForum (eTOM, SID, NGOSS/TNA, TAM, IPSphere)
ITU-T (M and Y standards)
ETSI-TISPAN (WG 8)
IETF/IRTF
DMTF
MEF, OIF, OGF, OMA, OMG
ITIL
Some conclusions:
Not a single standard can be applied to GEANT-NREN environment as is
(typically written from the perspective of the single enterprise for profit
commercial provider)
TMF appears to have the central position: eTOM is fully adopted by ITU-T,
ETSI TISPAN, SID is being incrementally adopted by ITU-T, IPSphere
covers some multi-domain issues, but between different OSS/BSS
connect • communicate • collaborate
System views
•
•
•
•
•
Network management activities
cannot be described from a single
viewpoint, by a single diagram or
description
Different viewpoints needed to give
answers to questions: what has to be
done?, by whom or what?, how?,…
X.901: Enterprise, Information,
Computational, Engineering,
Technology
ITU-T: Business Process View,
Management Functional View,
Management Information View,
Management Physical View
ETSI-TISPAN: Business
Requirements View,
Functional/Information View,
Implementation View
TMF Framework
connect • communicate • collaborate
OSS Design architectural
requirements
Defines the way OSS components are
organized
TMF NGOSS (recently replaced by TMF
GB942 Integration Framework documents)
design principles adopted by other
standardization bodies (mainly SOA)
Architectural requirements:
Inherently distributed architecture
Architecture uses interfaces to communicate
Architecture is componentised
Business processes are separated from
component implementation
Architecture is security-enabled
Architecture must be policy-enabled
Architecture uses shared information and data
Architecture uses a common repository
Architecture uses a common communication
vehicle (Enterprise Service Bus)
* Figure from: “The NGOSS Technology Neutral Architecture”, Release 6.0, TMF053,
connect • communicate • collaborate
GEANT – NREN environment network
architecture
Based on the ITU-T NGN architecture
Distinction is made between transport
and service stratum functions in all
domains
Transport stratum corresponds to
common resource management
functions (e.g. resource monitoring).
Service stratum corresponds to
overall service coordination and
management functions (e.g. service
monitoring)
Captures main properties of the
environment
Multiple domains with autonomous
service elements
Recurring repetition of service stratum
in order to accommodate different
services that exist (services to NOCs,
services to users etc.)
Service User
NREN
GEANT
Service Stratum
Service Stratum
Transport Stratum
Transport Stratum
Resource
Resource
GÉANT
NREN
GEANT
Resource
Resource
NREN
Service Stratum C
Service Stratum C
Service Stratum B
Service Stratum B
Service Stratum A
Service Stratum A
Transport Stratum
Transport Stratum
connect • communicate • collaborate
Geant – NREN NM processes
A minimal set of business
processes needed for the
GEANT-NREN service
development
Derived from eTOM Service
and Resource processes
mapped onto Geant-NREN
network architecture
Uses:
Analysis and
comparison of existing
service supporting tools
– overlapping or
missing functionalities
Design of new service
support tools (e.g. multidomain security incident
handling)
connect • communicate • collaborate
Geant - NREN NM Architecture – an
example
Further decomposition of
transport stratum processes
onto more primitive ones
Gives also a mapping to a
functional view
Functional view describes
main functional blocks, the
interaction between them
as a path to the design of
any workflow
Shows a possible way of
OSS system decomposition
connect • communicate • collaborate
A possible migration path for GN3
tools
Migrate the roles of existing tools
from current complete service
supporting tools (silos) closer to the
role of components in a SOA
architecture
Use process view to define a disjoint
set of processes supported by the
existing tools
Narrow the scope of functionalities
(supported processes) of some of the
existing tools
Design interfaces between them
Define common information and data
models
Any new service build within this
framework
connect • communicate • collaborate
Network management in GEANT –
NREN environment: The effect on NOC
operations
NOCs typically deal with
transport stratum functions
NOC possible shift of focus:
from device configurations/
monitoring to OSS
operations
Service User
NREN
GEANT
Service Stratum
Service Stratum
Transport Stratum
Transport Stratum
The network exists to provide
services to users
Sound policy and security
scheme
Automated multi-domain
services based on OSS
functions
NOC
Resource
Resource
NREN
GEANT
Resource
Resource
connect • communicate • collaborate
Conclusions
There are NM concepts/standards already defined and documented that
can be reused in the GEANT-NREN environment
We defined the framework that gives the answer to questions like:
WHAT has to be done in order to provide and support a particular
service?
WHICH elements are needed for the OSS system for that service?
HOW are these elements organized and how do they communicate
between themselves?
Network Management architecture does not give recommendations for
particular software best practices, development frameworks and similar.
Benefits:
Enable software components reuse
Avoid overlapping in supported functionalities, different solutions for the
same problem, the existence of different information/data models
Define a common terminology and better coordination between tasks
and activities
connect • communicate • collaborate
Thanks to…
…the GN3 JRA2T1 team that worked during the GN3 Y1 on network
management architecture:
Christos Argyropoulos,
Bartosz Belter,
Michal Giertych,
Artur Juszczyk,
Dimitrios Kalogeras,
Linus Nordberg,
Dušan Pajin,
Damian Parniewicz,
connect • communicate • collaborate
Q&A
connect • communicate • collaborate