Skip navigation

Geek Speak

4 Posts authored by: mfaisalk

The terms EMS, NMS and OSS are often misunderstood and used interchangeably. This can, sometimes, lead to a confusion on which system can do what functions. Therefore I am attempting to clarify these terms in a simple way. This may help you in making informed decisions when procuring management systems.

 

But before understanding the terms for management systems, one should understand what FCAPS is, in relation to management systems. In fact every management system should perform FCAPS. The five alphabets in FCAPS stand for the following:

 

F- Fault Management – i.e.  Reading and reporting of faults in a network; for example link failure or node failure.

 

C-Configuration Management- Relates to loading/changing configuration on network elements and configuring services in network.

 

A-Account Management- Relates to collection of usage statistics for the purpose of billing.

 

P- Performance Management- Relates to reading performance related statistics, for example reading utilization, error rates, packet loss, and latency.

 

S-Security Management- Relates to controlling access to assets of network. This includes authentication, encryption and password management.

 

Ideally, any management system should do all of the FCAPS functions described above. However, some commercial solutions allow only some of the FCAPS functions. In that case, there will be a need for additional management system to do the rest of the FCAPS functions. The FCAPS applies to all types of management systems including EMS, NMS and OSS.

 

Now that we covered the general functions of management systems, let’s understand the terms, EMS, NMS and OSS.

 

EMS stands for “Element Management System”. It is also called Element manager. EMS can manage (i.e. FCAPS) a single node/element or a group of similar nodes. For example it can configure, read alarms etc. on a particular node or group of nodes.

 

NMS (Network Management System) on the other hand manages a complete network i.e. it covers all the functions of EMS as well as does FCAPS with relation to the communication between different devices.

 

So the difference between EMS and NMS is that NMS can understand the inter-relationship between individual devices, which EMS cannot. Although EMS can manage a group of devices of the same type but it treats all the devices in a group as single devices and does not recognize how individual devices interact with one another.

 

So to sum up:

  1. I.e. NMS = EMS + link/connectivity management of all devices+ FCAPS on network basis.

 

NMS can manage different types of network elements/technologies of a same vendor.

 

An example would clarify. An EMS would be able to give individual alarms on nodes. But NMS can correlate the alarms on different nodes; it can, thus find out root cause alarms when a service is disrupted. It can do so because it has network wide view and intelligence.

 

OSS (Operation Support Systems) takes a step further. It can not only manage a single vendor but can also manage multiple vendors. OSS will be needed in addition to vendor specific NMS. OSS will interact with individual NMSs and provide one dashboard for FCAPS management.

 

OSS, thus, can give a single view of the network end to end including all vendors. An example would be a service provisioning tool that can create an end to end service between Cisco and Juniper routers. This would need an OSS that can talk to the NMS of the both vendors for this purpose or can even configure the network elements directly.

 

After explaining the terms EMS, NMS and OSS, I would end up my blog by asking

 

  • Does your management system do all the FCAPS functions or some?

 

  • Do you prefer to have one network management system that does all FCAPS or different ones depending on different specialized functions?

 

Or may be I should ask, are you using any management system at all

 

Would love to hear your opinion!

Fault Management (FM) and Performance management (PM) are two important elements of OAM in layer 2 and layer 3 networks.

 

FM covers faults management related to connectivity/communication of end stations.  While PM includes, monitoring the performance of link using statistics like packet loss, latency and delay variation (also called jitter) etc.

 

Here we need to differentiate between layer 2 and layer 3 networks.

 

For layer 2 networks, FM is usually done using CCM messages (connectivity check messages) while PM is done using standard protocols like 802.1ag or Y.1731 that can monitor all parameters mentioned above.

 

For layer 3 networks, Ping and trace route are primary tools for FM and by far the most widely used tools for troubleshooting, while IP SLA is one of the PM tools for Cisco devices. IP SLA can monitor all stats including loss, latency and delay variation at IP layer ( can also do it on layer 2) in addition to helpful stats for VOIP like MOS score. (Please note, Cisco use the term IP SLA also for both layer 3 and layer 2 links, even though the stats at layer 2 are on the Ethernet layer).

 

Coming from a carrier Ethernet background in my last job, when I look back, I can say that tools especially the PM tools at layer 2, were not used very often. It may be, because many people were not aware of it or the thresholds of pass/fail for performance measurements were not very well defined. Recently, Metro Ethernet Forum (MEF) has done a great job by standardizing the threshold and limits for jitter, delay and packet loss. Therefore, the PM tools have started gaining acceptance industry wide and are being rolled out in layer 2 service provider networks more actively.

 

However, I am quite curious on how often OAM tools are used in IP networks.

 

Fault management tools like Ping/traceroute are the bread and butter of an IP engineer when it comes to troubleshooting networks but I am especially interested to know more about the IP SLA and its use in the networks.

 

So my question to you would be

 

  • How often do you use IP SLA ( or any similar tool)  in your network? Do you use it in specific applications like VoIP?

 

  • Do you used it for both layer 2 and layer 3 networks. In enterprises as well as service provider environment?

 

  • Are the thresholds of the PMs (Delay, jitter and packet loss) well defined;  by Cisco or any standard body?

 

Would love to hear your opinion here!

iStock_000059460024_Small.jpg

Well, my last blog generated quite an interest and discussion on the use of CLI for box configuration.

 

As a follow up I want to write on a related topic although it may generate some difference of opinion here but this is my goal to generate a wider discussion on this topic.

 

OK, in my last post I said that CLI is cumbersome; it takes a while to get used to and the worst thing is that if something goes wrong, the troubleshooting takes ages, sometimes.

I also said that protocols like NETCON and YANG would really make the configuration easier, more intelligent and move the focus from the box configuration to the network configuration in addition to making the configuration GUI friendly.

 

I want to bring a new dimension to this discussion.

 

Let’s see if Cisco would really like to give you a better user interface and a better configuration tool.

 

Although I write Cisco here, but it can mean any vendor that gives CLI experience, for example Juniper etc. ( I specifically mean any CLI which is propriety and vendor specific )

 

Ok to start with; let’s agree on a fact that using CLI is a skill; rather an expert skill. This skill is required to configure a box and additionally to troubleshoot networking issues. Not only do you need how to move around with CLI, but you should be able to do it with speed. Isn’t it?

 

This skill requires training and certification. If one has expert certification, it means that he is not only intelligent but he is a command guru. Correct?

 

Cisco certification is a big money making industry. If not a billion dollar, it must be generating hundreds of million dollars of revenue for Cisco ( I contacted Cisco to get real figures, but seems these are not public figures). Cisco makes money by making one pay for exams and selling them trainings. Then there is a whole echo-system of Cisco learning partners, where Cisco makes money by combining their products with training services and selling through them.

 

It costs to get expert level certifications. There is a cost if one passes, and there is more cost, if one fails.

 

An engineer may end up paying thousands of dollars on trainings and exams. We are talking about huge profits for Cisco here just because of the popularity of certifications. There is one for everyone; for a beginner to expert; for an operation guy to architects.

 

Besides creating experts, Cisco is winning here from three angles:

 

  1. It is making its customers used to CLI as customers feel at home using the codes they are trained on.
  2. It is creating loyal users and customers as they would recommend products they already know very well.
  3. It is generating big revenue. ( and big margins as it is a service)

 

For sure the It is win-win for Cisco here.

 

In my perspective, therefore, a difficult to operate switch and router is in the direct interest of Cisco, as Cisco needs experts to run their products and the experts need certifications.

Cisco, therefore, would NOT be very encouraged to make networks easy to operate and configured. Even I have seen the GUI of one of Cisco products; it simply sucks. It seems to me it is not one of their focuses.

 

Thus, this raises an important question here:

 

Why would Cisco take steps to make the network more programmable, easy to operate with newer tools and take CLI out of their central focus? Wouldn’t it like to stick around with difficult to operate products and keep on making more money?

 

Would you agree with me?

 

I like to hear, both if you agree or disagree and why?

 

UPDATE:

 

After publishing this article, the majority of comments only focused on CLI versus GUI. For sure GUI is more user-friendly but CLI has delivered well because of not having good competition either from good GUI or SNMP, uptill now.

 

However the main message was to talk about “vendor specific CLI” NOT command line in general. In programmable age, tools like NETCONF and YANG offer a standard way to configure network elements. Whether you use it with GUI or with command line, the benefits far exceed compared to vendor “CLI”. NETCONF/YANG is a standard way to configure any vendor equipment. The protocol leaves it to the vendor to determine how to apply configuration instructions and in what order within their devices. This means this puts pressure on the vendors to do additional development on their products to execute the user configuration in whatever order he ordered. This removes pressure from the user to learn configuration for multiple vendors and learn multiple CLIs. This is the future, NOT CLI.

My first experience in the IP domain was that of a shock!

 

I had moved from the optical transport domain in an operator to the IP department.

 

As an optical guy, I used Network Management system (NMS) for all tasks including configuration, fault and performance measurements. Above all, I liked the nice Graphical User Interface (GUI) of NMS.

 

However, I found that in the IP world, Command Line (CLI) is used for everything; from provisioning to troubleshooting. CLI rules in the IP domain.

 

“CLI is the tool for Engineers”, I was told.

 

OK fine! This may have something to do with my personal preference that I do not like the user interface of CLI or because I came from optical background, that this stuff seemed strange to me.

 

Irrespective of the user interface, and with all functionality that CLI provides,from my perspective, CLI is not the ideal tool for configuration. First, it focuses on a single box i.e. configuring box by box, which is cumbersome.  Second, it is to prone to human error and because of errors sometimes troubleshooting takes considerable time. And lastly, it is vendor specific so changing a vendor box needs a totally different skill-set to configure a box.

 

Therefore, as an operator, in my view, there is a need for a more flexible way of configuring/ service provisioning. The focus should move out from “box configuration” towards “network configuration”. Also, in this age of emerging technologies like SDN and NFV, where NMS is the primary focus; CLI will simply block the innovation.

 

Network configuration is a major part of the operators' OPEX. Studies put it around 45% of the total TCO of the network.

 

CLI has a place today because the management protocol -SNMP itself is not ideal for service provisioning. That is why operators are using SNMP primarily for monitoring purpose, not for configuration purposes.

 

Both CLI and SNMP, also, do not support one another important requirement for large complex service provider networks. That is they do not support transactional mode for network configuration.

 

Transaction enables multiple configurations to take place as one transaction or fail completely (All or none). To clarify this very important point, take an example of IPTV service that involves configuring one router, two switches, two firewalls and a billing system.  A transactional protocol   enables configurations on all involved network elements or NONE. This is beneficial because if there is any problem of configuration validation on even one network element, the configuration would fail on all other network elements.  This means that configuration would never be implemented partially on some network elements. This is the essence of “network configuration” as we talked earlier.

 

So do we have to live with SNMP and CLI for network configuration, forever?

 

No!

 

The NETCONF YANG protocol, developed by IETF for network management, has a single focus and that is configuring network as easy as possible. IETF learned from the experience of SNMP on what can be improved and approached the new protocol in ground up fashion. It is purpose built for configuring network.

 

NETCONF is the management protocol primarily for network configuration while Yang is text based modeling language designed to be used with NETCONF. Both are needed for a complete flexible service provisioning in IP networks.

 

There are FOUR main features of NETCONF YANG:

 

  1. Support of Transactionality:  Configurations can be applied to multiple network elements as one transaction to either succeed or otherwise.
  2. Get configuration feature. This is distinct advantage compared to SNMP. With SNMP backup config. is available but it is polluted with operational data ( Alarms, statistics); with NETCONF one can just have the configuration data.
  3. Vendor device independence. NETCONF can be used as standard configuration protocol for any vendor. The vendor’s box will sequence the configurations and execute them. This sequencing is internal to the vendor’s box and NETCONF does not need to be aware of it.
  4. Multiple network elements can be configured at one time thus saving time, configuring the network.

 

Therefore in summary, NETCONF is the right solution to solve network management issues in standard way. It is the next generation of network management protocol, which will reduce the time to provision services for an operator and will help in applying multiple configurations to multiple network elements at one time.

 

Now it is your turn to tell me:

 

  1. How do you feel about CLI as a network configuration tool, would you like to live with it forever?
  2. What issues do you face, using CLI? If there are any.
  3. Do you think NETCONF can deliver better than SNMP/CLI?

 

Would love to hear your opinion!

Filter Blog

By date: By tag: