Data Control Networks (DCN)

You cannot control what happens to you, but you can control your attitude toward what happens to you, and in that, you will be mastering change rather than allowing it to master you.”
Brian Tracy
.

A Data Control Network (DCN) is the network that carries management traffic between components of your network, OSS, BSS and beyond. It’s a vital part of any telecommunication network management solution. To use an analogy, if the OSS is a heart and your management traffic (eg SNMP traps) is blood, then your DCN is the network of arteries that carry that life-blood to your OSS.

Sometimes the DCN is referred to as “the management plane” of the network. It will generally have structural separation from “the customer plane,” or the network that carries customer traffic. This separation can take the form of logical separation (eg separate VRFs / VPN on the same network routes as customer traffic) or physical separation. Due to the importance of the DCN, many operators ensure there is a completely separate, or Out-of-Band (OOB) network, to reach network devices if the primary DCN fails.

Obviously your DCN is a vital component of your OSS but it is sometimes forgotten about when engineering an OSS solution. Most OSS topology diagrams don’t even show the DCN network, so don’t underestimate its importance.

If your DCN isn’t adequately engineered to carry the traffic between NMS / OSS / BSS interfaces across all parts of the network then your OSS won’t function correctly. Your DCN engineering must consider how management traffic can traverse firewalls and other security / segregation mechanisms. It must also be dimensioned appropriately to handle the additional OSS traffic.

DCN design and traffic engineering needs to consider:

  • The new interfaces that your OSS establishes (eg traffic between NMS and OSS that didn’t exist previously)
  • Increased data volumes if polling of the network by your OSS is made more frequent (eg poll-rates of inventory discovery or network performance metrics)
  • Inter-OSS feeds (eg traffic carried between external storage, high-availability mechanisms, communications between OSS modules, database synchronisation and even remote pollers / collectors / reflectors aggregation) and
  • Intra-OSS feeds to other management systems, BSS, etc.
  • Whether management traffic needs to be carried in-band (ie management traffic is carried across the same network as customer traffic) or OOB (out-of-band) (ie on a dedicated network that keeps management traffic segregated from customer traffic)
  • Whether it is essential to reach devices remotely in failure situations or whether field visits can suffice.
  • Evaluate in-band / out-of-band pathways, and whether reachability can be maintained during catastrophic failure
  • The ability of devices to dual or multi-home their data feeds, but also ensure that the associated data duplication issues are contained
  • Complexities of SNMP being UDP-based and X.121 / X.25 needing to utilise XOT to communicate across modern IP networks
  • Traffic dimensioning across fault, performance, inventory / configuration / provisioning, security, and line-testing independently as they may all be carried by separate interfaces.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.