A Network Management Architecture proposal for the GEANT-NREN environment

1. A Network Management Architecture proposal for the GEANT-NREN environment Pavle Vuletić, Afrodite Sevasti TNC 2010, 31.5.-3.6.2010, Vilnius, Lithuania

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

3. 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 management network management software design networking

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

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

6. 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,

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

8. 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)

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

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

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

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

13. Thanks to… • …the GN3 JRA2T1 team that worked during the GN3 Y1 on network management architecture: • Christos Argyropoulos, • Bartosz Belter, • Michal Giertych, • ArturJuszczyk, • Dimitrios Kalogeras, • Linus Nordberg, • Dušan Pajin, • Damian Parniewicz,

14. Q&A