Tail f Systems Whitepaper - EMS and NMS Platforms - Beyond Alarms and Maps
 

Tail f Systems Whitepaper - EMS and NMS Platforms - Beyond Alarms and Maps

on

  • 1,319 views

While Element Management Systems have traditionally focused on alarm acknowledgement, maps, and IP discovery, Network Equipment Providers are now being asked to provide plug-n-play device ...

While Element Management Systems have traditionally focused on alarm acknowledgement, maps, and IP discovery, Network Equipment Providers are now being asked to provide plug-n-play device configuration and automated service provisioning. This whitepaper addresses why it is important to take a broader view that includes configuration management and shows how Tail-f Systems’ NCS approaches these requirements.

This whitepaper:
- Introduces new challenges facing developers of EMS and NMS platforms
- Describes technical requirements for next generation platforms
- Overviews Tail-f Systems’ NCS platform in the context of these requirements
- Shows practical examples of real world scenarios and how NCS can solve them
- Demonstrates how to save development costs and turnaround new functionality faster
- Compares NCS to EMS Frameworks and IP Network Monitors

Developers, architects, product managers, and CTOs involved with EMS and NMS platforms will find this whitepaper a useful tool for planning and scoping future projects.

http://www.tail-f.com

Statistics

Views

Total Views
1,319
Views on SlideShare
1,317
Embed Views
2

Actions

Likes
0
Downloads
59
Comments
0

2 Embeds 2

http://www.slashdocs.com 1
http://www.docshut.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tail f Systems Whitepaper - EMS and NMS Platforms - Beyond Alarms and Maps Tail f Systems Whitepaper - EMS and NMS Platforms - Beyond Alarms and Maps Document Transcript

    • Tail-f Systems WhitepaperEMS/NMS - Beyond Alarms and MapsAlarms, maps, and IP discovery are among the first things that come to mind when discussing ElementIntroductionManagement Systems or Network Management Systems (EMS/NMS). While these are key functions in anetwork management solution, this whitepaper will address why it is important to take a broader view thatincludes configuration management. This paper discusses why configuration management is important, thetechnical challenges underlying provisioning carrier-class services and device configuration, and Tail-fSystems’ solution to integrating configuration management into an EMS/NMS.EMS platforms today focus on graphical displays and have been designed for monitoring networks andNew Challengesmanaging alarms. Operators have customarily accepted responsibility for device configuration settings andmanual service provisioning, but this is changing. Equipment providers are now being pressured to provideplug-n-play device configuration and automated service provisioning applications. The factors driving theserequirements are as follows: • Increased complexity and diversity among networks and devices. • Higher expectations for new services to be deployed with spotless quality. • Operator reluctance to hire more personnel to manage larger networks and more services. • Pressure to reduce operational costs and increase productivity.As a consequence, the focus in FCAPS is moving from the F and P to the C. This change also requires climbingfrom the element layer to the network and service layers and the need for higher quality northboundinterfaces. Programmatic northbound interfaces are also extremely important because vendor specificsolutions need to be efficiently integrated into the OSS applications used by service providers.Currently, developers and integrators must use complex technologies to implement programmaticnorthbound interfaces. Existing architectures give limited support for working with transactions andconfiguration changes for multiple devices and end-to-end services. More pragmatic solutions are clearlyneeded.Vendors are also struggling with the internal APIs/protocols between the EMS and the devices, creatingunnecessary costs when it comes to EMS development. In many cases, this means using SNMP and CLIsdespite all their limitations.SNMP is well suited to the job of network monitoring, but has multiple issues when handling configurationmanagement tasks. A significant coding effort is required to overcome the issues with SNMP. In response tothe challenges in using SNMP, many EMS platforms use the CLI on the device to make configuration changes.This approach lacks the benefit of a formal model, like SNMP MIBS, for the data and developers are stuck withparsing strings. This again creates costs and problems for development and maintenance.Forward-thinking designers of management systems see the advantages of using NETCONF as an EMS-deviceinterface. NETCONF provides all the benefits of SNMP (formal data models) as well as many useful featuressuch as transactions, configuration validations, rollbacks, XML-based protocols, model-discovery and efficientbulk-retrieval. Tail-f Systems © 2011 Page 1 of 11
    • Tail-f Systems WhitepaperThe challenges with current approaches used in EMS platforms are summarized in Figure 1 below,highlighting the perspectives of different participants in the network management ecosystem. Service Provider Challenges • Poor support for automated configuration and provisioning. • Lack of network and service view - element centric. • Lack of useful northbound interfaces. Network Equipment Provider Challenges • Costly development due to time spent on low-level issues like adapters, transaction management, persistence, and transformation of models to internal storage. • Costly to develop configuration management functions. • Slow turn-around time for new features. • Keeping up with internal equipment interfaces requires adapters. Industry-wide Challenges and Causes of Failure • Focus on alarms and performance monitoring results in an architecture that only solves the simple problems. • Lack of network and service view. • Lack of configuration management. • Requires extensive programming - API based. • Hard to customize. • Lack of solutions for managing different interfaces and interface versions. Figure 1: Challenges with Current Approaches to EMS DevelopmentA new generation of EMS platforms is needed to cope with the requirements for configuration and serviceNew Generation of EMS Platformsmanagement and to cut development costs.Next-generation EMS platforms need to include the following capabilities: • Model-driven - Network management is an information model management application and EMS platforms must be designed around managing models at different layers and remove manual programming steps for model management. • Dynamic - It must be possible to add new features with minimal cost, change models at run-time, and automatically update all northbound interfaces for changes. • Address configuration management - Configuration management has been done by experts using manual processes with very little support from EMS platforms. A better approach is for EMS platforms that make sure the network and services are configured correctly, including an up-to-date configuration database. • Avoid low-level programming activities - The platform should support persistence, serialization, device adapter development, rollback and transaction management, transformations between different models. For example, SQL - SNMP - WSDL. • Enable service management -The platform needs to maintain the relationship between services and devices, and be able to calculate how services will be deployed in the network. • Rich set of northbound APIs - EMS platforms need to be integrated into overall OSS solutions and must support different categories of users. The current practice of a single graphical user interface is not sufficient for professional users, scripting, or OSS integrations. Tail-f Systems © 2011 Page 2 of 11
    • Tail-f Systems WhitepaperIntroducing Tail-f Systems’ NCS NCS is comprised of a Service Manager, a Network Manager, Service Logic, a Transaction Engine, and Configuration Database. See Figure 2 for an overview. The Service Manager is responsible for modeling services and dynamically mapping them to the network layer using powerful service mapping and validation logic. A major benefit of the Service Manager is the extremely short turnaround time from service model definition to a running application. Programmatic interfaces are model-aware and are automatically updated from the service model without other inputs. Figure 2: NCS OverviewThe NCS Network Manager automates device integration including transaction management, synchronizationof configuration data, and multi-node configuration deployment and includes multiple capabilities to ensuresmooth and error-free network operations. NCS provides a rich set of northbound APIs which are all auto-rendered from a common data model. No programming is required to get a CLI or Web UI directly from themodel.NCS provides a unique model-based approach to developing management applications. Rather than addingDynamic Model-Driven Developmentmore programmers, APIs and components to address the proliferation of application, device, and versionchanges, NCS elegantly renders much of the functionality from the data models. The models cover both thedevice management aspects and the service layer.The device models tell the management application all about the device’s configuration, fault andperformance data. Application developers then model the corresponding higher-level configuration, fault andperformance models. With NCS’ approach to configuration management, the desired configuration isexpressed in the higher-level service model and this is transformed to the lower-level device model. For faultand performance management, application developers model service-related performance counters andalarm states; the device counter values and device alarms are then mapped to these higher-level servicemodels.In this way, implementing the management system in NCS is a matter of mapping the models together. Thisradically simplifies the development process and eliminates recoding on a silo by silo basis. This concept isillustrated in Figure 3 below. Tail-f Systems © 2011 Page 3 of 11
    • Tail-f Systems Whitepaper Figure 3: Model Mapping ProcessNCS uses YANG (RFC 6020) to specify semantic device and service models. The use of YANG has severalbenefits: • Open standard from IETF. • Dedicated language for network management. • Semantically rich models. YANG can define complex constraints enabling the model to capture good/bad allowed/disallowed configuration states. • Powerful enough to be used at network and service layers. • Capacity to drastically reduce internal development cost for equipment providers if NETCONF/YANG are used at the network layer.NCS avoids dealing with time-consuming stubs. Naïve model-driven frameworks generate stubs andclasses/types for the model. Programmers need to implement all the stubs in order to have the managementsystem up and running. NCS has overcome this issue and allows management systems to execute using themodel alone. This means that as soon as you have the device models you have an EMS with auto-renderedWeb UI, network CLI, and more. The programmatic steps are performed as decorations to the model.Whenever you want something specific to happen, you register a hook into the model to customize the defaultrendered behavior. This allows for a modern iterative and agile approach.Using YANG as NCS’ modeling language provides additional benefits over other EMS platforms wheredifferent modeling languages are used. For example, with other approaches the programmer needs to mapthe SNMP device model to SQL storage, a Java-based network model layer, and a WSDL northbound layer. Incontrast, a developer using NCS avoids complex mapping code by working with the model only.Tail-f Systems provides a unique patent-pending mapping engine to map the service models to the devicemodels. This drastically reduces the amount of code that needs to be developed.In many cases, extensive coding is required to map various information models to persistent storage usingtools such as Hibernate. This step is totally removed when using NCS. NCS embeds a database and the schemais always in sync with the YANG models. Programmers do not have to bother about specific storage APIs andfeatures. The programmer uses the model and NCS will make sure everything is persisted.In contrast to traditional development, model-driven EMS development has many productivity benefits. Asshown in Figure 4 below, traditional development projects usually start with informal graphical models andplain text descriptions. Tail-f Systems © 2011 Page 4 of 11
    • Tail-f Systems WhitepaperThis work goes on for a couple of months without enabling any formal validations. These informal artifactsare then handed over to programmers. After a couple of months of development the system begins to appear.However, there is no guarantee that this system is consistent with the initial sketches.Tail-f Systems’ model-driven approach enables you start from Day One with formal YANG-models. At everyrefinement you can load the models and run the EMS platform. You can add custom behavior and extend themodels iteratively. This closes the gaps between initial design and production code and drastically shortensthe development time. Figure 4: Development Process – Old vs. NewDevice and Service Configuration ManagementWhile traditional EMS platforms primarily provide support for event collection and alarm management, NCSDevice Configurationis designed from the ground up to address the most demanding configuration management requirements.The Configuration Database (CDB) is at the core of NCS. NCS is capable of keeping the CDB in sync with themanaged devices. Also, NCS can show how the configuration differs between the desired configuration in NCSand the actual configuration in the devices. Figure 5: Configuration StatusFigure 5 above shows a situation where NCS indicates that device3 has a different configuration than NCS,device1 is in sync, and we are not sure about device0 and 2. Tail-f Systems © 2011 Page 5 of 11
    • Tail-f Systems Whitepaper Figure 6: Resolving Configuration DifferencesWe can do several things to resolve this type of issue as illustrated in Figure 6 above. For example, we knowwe are out of sync in the case of device3. NCS supports a network-wide sync and audit function to detectthese types of situations and rather than comparing the complete configuration, NCS more efficientlycompares just transaction IDs. An operator can use the Compare Configuration command to inspect thedifference between NCS and the device. After inspection we can choose to reconcile in either direction.Figure 7 below shows a snippet from the Compare Configuration command. It identifies that the device ismissing Carrier Ethernet Endpoints (UNIs). Figure 7: Compare Configuration CommandWith NCS you will be able to use all interfaces to apply transaction-safe configuration changes to allconnected devices. The CLI sample below shows a single transaction to create two new interfaces on twoprovider edge routers pe1 and pe2:>set ncs managed-device pe1 config interface eth1 enabled ip 192.168.7.2 mask 255.255.255.0>set ncs managed-device pe2 config interface eth3 enabled ip 192.168.6.2 mask 255.255.255.0>commitAt a later stage this can be rolled back:> rollback 0The steps to design the service configuration in NCS are as follows:Service Configuration 1. Model your service in YANG. 2. Implement the create service method that calculates the corresponding device changes. 3. Load and run.We will illustrate these steps with Ethernet Services. An Ethernet Virtual Connection, EVC, is like a VPN at thephysical layer. Metro Ethernet Forum is standardizing this. Tail-f Systems © 2011 Page 6 of 11
    • Tail-f Systems WhitepaperA snippet of the service model is shown in Figure 8 below. An EVC is primarily made up by its type andEthernet endpoints. One important part in the model here is that references in the model are typedreferences and not just table indices like in SNMP or text strings. For example, this can be utilized by NCS sothat an endpoint that is used by an EVC can never be removed. Figure 8: Snippet of Code Used for Service ModelAfter modeling the service in YANG, NCS is ready to use the northbound interfaces to provision EthernetServices. This is illustrated in Figure 9 below with a customized Web UI.. Figure 9: Web UI as Example of Northbound Interface Tail-f Systems © 2011 Page 7 of 11
    • Tail-f Systems WhitepaperWe drag and drop the endpoints to the EVC dialog. When the user presses “Apply” the Java code shown aboveis executed. NCS will manage all the communication to the devices and make sure that the changes arewritten in a transaction-safe manner. In addition, NCS automatically captures the configuration change that aservice writes to the devices.In Figure 10 below, we see that the evc1 service created configuration data on device2 and 3. If evc1 isremoved, NCS is able to automatically clean up the device configuration. Figure 10: Device ConfigurationEvery device also “knows” which services it is supporting. See the “used by” field in Figure 11 below. Figure 11: Device AwarenessNCS also has many other features to manage the service lifecycle. When a service is activated it is importantto verify that the service functionality is correct. In many cases, this is performed by probes. NCS provides aself-test framework where service test code can be hooked to services and all services can be tested in aconsistent manner. In case of major problems, the service configuration is recalculated and deployed to thenetwork again.The tight connection between the device and service model is useful in other scenarios including the service-impact of alarms. If device2 is down we can automatically infer that evc1 is non-functioning. See Figure 12below where device2 is red because it is down. We have a corresponding alarm and the associated evc alsobecomes disabled (red). Tail-f Systems © 2011 Page 8 of 11
    • Tail-f Systems Whitepaper Figure 12: Connection between Alarms and Devices and ServicesNCS comes with a rich set of auto-rendered northbound interfaces:Northbound Interfaces • NETCONF - NETCONF is the IETF (RFC 4741) standard for configuration. It is also extremely useful for scripting since it uses a SSH and XML payload. The NETCONF northbound interface is optimal to use for northbound integration. • CLI - Not many EMS platforms render a professional CLI. NCS renders a highly useful CLI based on the device and service models in use. Therefore, you can manage both the devices and services from one CLI. • SNMP - SNMP is important in order to bridge status and northbound alarms. • Java - The NCS Java APIs can be used for further integration and development. • JavaScript - NCS publishes a high-level JavaScript API that lets Web developers build custom Web UIs on top of the service logic in NCS. Any JavaScript framework like jQuery or InfoVis can be used. Figure 13 below shows a Custom NCS Web UI based on jQuery. • Ajax-based Web UI - NCS auto-renders a highly interactive Web UI direct from the model. • TM Forum MTOSI - Future Release. Figure 13: Custom NCS Web UI Tail-f Systems © 2011 Page 9 of 11
    • Tail-f Systems WhitepaperNCS’ unique EMS-to-device-integration technology, based on NETCONF and YANG, eliminates the code andDevice Integrationintegration work needed to integrate the management system with the devices. No more adapterprogramming is needed. NCS can be used with any NETCONF-enabled device including Tail-f Systems’ ConfD.NETCONF, in contrast to SNMP or CLIs, or even web-based technologies, has many dedicated features thatsave development cost and time. These include: • Discovery of data models. NETCONF includes automatic handshaking and publishing of correct data models. This removes the manual MIB discovery process. • Native support for configuration actions like get-config and transactions. • Lightweight communication infrastructure based on SSH and XML encoding.In addition, NCS provides a gateway to integrate SNMP or CLI-enabled devices. A modeling approach is takenhere rather than using brute force programming. The device is modeled in YANG and a thin layer of mappingcode is written. As a result, features like transactions and rollbacks can be generated by the NCS engine ratherthan manually programmed into an adapter.NCS provides fault, configuration, performance, and security functionality and supports third partyFCAPS Supportaccounting applications. This enables developers to build complete FCAPS applications from scratch oraugment an existing solution. An example of a screen acknowledging alarms is shown below in Figure 14. Figure 14: NCS Alarm Acknowledgement Tail-f Systems © 2011 Page 10 of 11
    • Tail-f Systems WhitepaperNCS is a powerful solution for building EMS/NMS platforms today and in the future. Current solutionsNCS Compared to Other Approachespredominantly provide functions like monitoring, event collection, and SNMP integration. Figure 15 belowcompares NCS to EMS Frameworks and IP Network Monitors. NCS EMS Frameworks IP Network Monitors Fast Model-driven approach API-based approach Separate applications Development with auto-rendered requires extensive coding needed to be integrated interfaces provides fast increasing time-to-market and tested increasing cost turnaround from design to and development time production systems Service Unique service to device Not Supported Not Supported Management mapping solution Configuration Full transactional support, Not supported Not Supported Management including embedded configuration database Southbound NETCONF and SNMP and SNMP focus (no NETCONF) SNMP focus (no NETCONF Interfaces unique declarative CLI that is development or CLI) that is development engine intensive intensive Northbound SNMP, CLI, NETCONF, JS, No northbound CLI plus Focused on UI and not Interfaces Java, MTOSI focused on UI and not northbound northbound Figure 15: NCS Compared to Other SolutionsWhile Element Management Systems have traditionally focused on alarm acknowledgement, maps, and IPConclusionsdiscovery, network equipment providers are now being asked to provide plug-n-play device configurationand automated service provisioning. At the same time, new standards and technologies are enabling radicallyimproved approaches to developing EMS platforms. Network equipment providers now have the opportunityto further differentiate their management applications and reduce development cost and time.Tail-f Systems is the leading provider of configuration management software for networking equipment andAbout Tail-f Systemsnetwork management systems. Six of the ten largest global networking equipment providers are Tail-fSystems’ customers.Users of Tail-f Systems’ products, ConfD and NCS, benefit from bringing their products to market in less timeand with reduced risk while incorporating advanced capabilities and support for industry standards. ConfD isthe leading solution for building on-device management systems for all kinds of networking equipment. NCSis a powerful solution for automated service provisioning and configuration management that can beintegrated into an existing EMS platform or used as a model-driven solution to build new managementsystems from scratch. Tail-f Systems is actively contributing to standards that are shaping our industryincluding NETCONF, YANG, MEF Service and Device Models, and others.Tail-f Systems is headquartered in Stockholm, Sweden. For more information on the company, please visitwww.tail-f.com. Tail-f Systems © 2011 Page 11 of 11