Choosing a Naming Convention

How do you uniquely represent every element within your network landscape under a single naming umbrella?

Following on from the introduction of naming conventions, where we covered why an OSS naming convention is so important, the following provides some insights into how to choose a naming convention.

When choosing a suitable set of naming conventions under an OSS domain, the following must be taken into consideration:

  • The first step is to identify the objects that require names in the OSS database. This can range from network assets such as network elements, circuits, rings, etc through to customer codes, network operating regions and a vast range of other objects
  • There is no single best approach to naming conventions
  • Naming conventions should be chosen that are most meaningful to the operational business units that rely on the nomenclature. If this means retaining legacy naming conventions that have been in use for many years, then the new naming conventions should attempt to mimic these as closely as possible
  • Developing OSS-level naming conventions often have to take into account the legacy characteristics of the NMS-level naming conventions that reside in the existing network management or documentation
  • Naming convention character lengths are a trade-off between the breadth of data they represent (more characters) and the ease of use (less characters)
  • In addition to operation of the OSS, naming conventions must take into account operational issues such as physical labelling of assets, the implication of data updates (eg changing the naming convention may result in changing configurations in hundreds of devices or thousands of network drawings), etc
  • We expect that it will be difficult to change naming rules because it will initiate changes that could be made down to NMS/EMS/NE level in the network. This can represent a significant amount of work, particularly if the devices aren’t remotely accessible (ie a field visit is required).
  • However, we should remember that the changes won’t need to be propagated down to the network if we are able to introduce “alternate names” in the OSS
  • In the following sections, we propose nomenclature that has a structured number of digits or characters (eg site code has 4 characters). Whilst it is possible to have nomenclature of variable character length, it can make coding of ad-hoc reports or SQL queries more difficult, so it is recommended to have fixed lengths where possible. Where it is not possible to have fixed length fields, it may be possible to have separators like the “-“ character to simplify SQL queries
  • Each vendor’s applications have their own unique characteristics with regards to naming conventions. The vendor’s experts should be consulted when refining naming conventions to suit.

Naming Convention Standards

There is no common standard for naming conventions but we base the following naming convention examples upon one of ITU-T’s approaches to naming.

ITU-T M.1400 is a good basis from which to design naming conventions. M.1400 shows a number of differing recommendations, but the table below shows the basic format of the circuit names. I’ve provided an OSS Naming Convention Template that builds upon M.1400 and still provide enough flexibility to adapt to many carriers’s specific needs.

One other important item to note is the characters that are used. There is a small problem with M.1400 because it recommends the use of the slash “/” character. This is a special character for some operating systems or applications which can cause problems that can be very difficult to isolate

So to avoid any possible problems we suggest that you use conventions with the following characters:

OK : a-z, A-Z, 0-9, ‘-‘, ‘_’

But not the following characters:

&, @, ?, /, \, !, %, ‘, “, *, accentuated characters like é,è,ù, double-byte characters (eg Chinese, Vietnamese, etc).

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *