connect communicate collaborate A Network Management Architecture proposal for the GEANT-NREN environment Pavle Vuletić, Afrodite Sevasti TNC 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 Network management evolution 90’s Device management perspective – Network management meant device control and monitoring SNMP – Simple Network Management Protocol 2000’s Network Management means much wider set of activities Service-centric or user-centric approach Emphasis on service provisioning and management, designing OSS/BSS tools “Old” network management is only one part of the overall activity software design management networking

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.) GÉANTNREN Transport Stratum Service Stratum A Transport Stratum Service Stratum A Service Stratum B Service Stratum C Service Stratum B

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. multi- domain 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 The network exists to provide services to users Sound policy and security scheme Automated multi-domain services based on OSS functions NOC

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