Thursday 2 February 2012

OEM EMS Dilemma

You are an OEM vendor that is facing the reality of deploying your new product or service into the network of a service provider, whether it be Carrier, MSO, I/C/LEC, etc.   Let's assume you work for the Zoom Corporation and your company has sold your Zoom 2000 solution to a carrier customer and you have passed field trials which you have directly hosted and managed. Now that you have won a deal you have to consider the myriad issues related to the rollout of your solution into your customers production environment. There will be many, but this article focuses on one specific area.

Put yourself in the shoes of a Network Operations Center (NOC) manager of the service provider. As the NOC manager you are tasked with responsibility of integrating the Zoom 2000 into your network management systems (NMS) and other associated infrastructure. The marketing team has set an aggressive deployment schedule and you are asked to integrate in record time on a shoe-string budget. You will face challenges in several areas: alarm and performance metrics integration; configuration and provisioining; integrating with customer OSS; building in-house expertise; creation and documentation of numerous operational procedures; high sensitivity to capital costs, startup costs and long term operational costs; network planning. This is a subset of the considerations.

Now, you as the OEM of the Zoom 2000 want to reduce the rollout time and barriers to entry for your product. You certainly do not want to have the NOC manager put up a roadblock for your service. So you must ask yourself what you can do to remove these hurdles.

The NOC manager will want to have a complete FCAPS management solution that can integrate with his NMS. Having an Element Management System (EMS) that is designed to the specific needs of your products and solutions and is designed for integration into well known NMS systems will greatly reduce the list of demands you will face from the NOC manager.

So what are your options?

1) Build a full custom solution yourself
2) Build a solution on top of third party EMS products
3) Hire a vendor who has indepth expertise in delivering such solutions as your EMS team

Option 1

Over a decade ago this was the only option available to OEMs. But today, the challenge of the EMS is a well known problem space that has been addressed by companies that specialize in this area. Building a full size team to develop a complete custom solution will add a large cost and burden to your company. You are probably better off considering another option.

An example of a product that comes out of this type of organization is a combination will use existing web servers, message queues, high availability middleware, commonly available DB servers, etc. A lot of time and energy must be put into architecting a solution, selecting the best products to use, integrating, packing and testing all of these products together and then building a complete FCAPS solution on top of it all. This exact type of effort has been performed again and again, so you should ask yourself if you can come up with any compelling reason to reinvent the wheel.

Option 2

There are companies that have seen an opportunity to address this market and have built framework on which OEM's may then build their own custom EMS. Over the years, there have been many of these types of systems built. One of the primary issues with this approach has been that these generic frameworks always require extensions to be made which are difficult to accommodate. One other issue with this approach is that you must still maintain a significant size staff to build and maintain this EMS product. Since the EMS "problem" has been well defined and addressed, should you really be hiring in this area which is not your core competency?

Option 3

The history of EMS systems development described above has produced a third option for OEMs such as yourself. It is now possible to get the benefit of a fully FCAPS compliant solution without hiring a large in house staff to produce the product. You as an OEM can hire a company that specializes in building custom EMS solutions on top of a framework specifically designed to meet the needs of your NOC manager customer. This allows you to avoid committing a significant portion of your capital to building a large team of full time engineers for a product that is not part of your primary value proposition.

Conslusion

 The authors of NOCVue Velankani Inc. offers such a solution – a  product and  a service designed to fit the needs of OEMvendors considering options 2 and 3. If you find yourself at this crossroad please contact us to open a creative discussion focused on finding a solution that best meets your needs. We can be reached via email: mailto:inquiry@velankani.com or feel free to call at +1 (732) 981-0611 x 117.

Monday 5 December 2011

Element/Network Management Key Performance Indicatords & Reports


Element/Network Management Key Performance Indicatords & Reports

Cloud deployments, virtualized environments and smart devices and applications are increasing day by day. More and more companies are using hosted solutions and also encouraging employees using smart devices, IPads and other Wi-Fi enabled devices to be used on premises and while traveling. More companies are adopting open door policies in exchange for increased productivity while on premises or travel. The enterprise networks today comprise of network devices such as routers and switches, wireless access devices, VoIP equipment, servers, desktops, and smart devices and the network gets bigger and bigger due to high bandwidth demands.
With high utilization of bandwidth and increased applications, it is important to monitor the network and server performance constantly. Enterprise IT Centers constantly monitor the network performance and faults to prevent network outage and service disruption. It is also important to get a snapshot of utilization and bandwidth/server demands periodically and provide a high level executive view for trending and capacity planning. Top level reports and alerts identify service outage, lack of resources or security violations.  To achieve this, an automated work flow for configuration and reports and analytics are very important. Any element management or network management solution should have built in support for generating the reports that gives a quick status on health of the network, utilization, service availability and demands.
NOCVue has built in reports engine and generates various reports based on collection of data. These reports can be configured for a dash board view. NoCVue supports the following reports:
·         Availability reports
·         Utilization Reports
·         Alarm Reports
·         Inventory and Asset reports
·         Top N Reports
Availability Reports
NOCVue discovers devices initially and updates the inventory database. It periodically performs health check on discovered devices and prepares availability reports. If the devices are not reachable it generates alerts. Top N reports can be generated based on non-availability over the period of time. For example availability report based on the devices that are not reachable atleast once in last 24 hours can be generated by click of a button. The availability could be done for devices or interfaces or links. The chart here shows % of resources available over a period of time.


Utilization Reports
Utilization reports helps in determining usage trends and capacity planning. NOCVue supports bandwidth utilization, CPU utilization, memory utilization reports. Bandwidth utilization and trending helps in planning for network expansion   ahead of time so service disruption can be prevented. CPU & Memory utilization reports helps to understand the resource usage and analyze the usage and take corrective measures. 

Alarm Reports
Alarm reports provide the general health of the network and where frequent outages happen. This can identify potential faulty equipment or unstable links and take corrective action. Frequent alarms on a device can call for repairs or replacement of the device. In general the troubles can be isolated and corrected analyzing the reports before the operator is swamped with trouble tickets. The report here shows the snap shot of nodes that are in alarmed state. 



Inventory and asset reports
The inventory reports provide the total inventory of network devices, desktops, servers, applications and mobile devices  and helps planning the capital expenses required. NOCVue performs auto discovery and collects all inventory data. Periodically health check is performed to verify the current status of the inventory. The discovery is also scheduled periodically to discover any new devices that get added to the network.

Top N reports
Top N reports usually capture the most important or critical information at every category. These are typically provided to the executive for a quick review and remedy. Some of the examples are top 10 users who utilize the bandwidth most, Top 10 links where most bandwidth utilization occurs, top 10 devices that had frequent outages, top 10 servers or application  that is  used most, top 10 applications that utilize most memory and cpu etc.






Friday 2 September 2011

White Paper Challenges in Managing Optical Transport Networks

Introduction
The growth of numerous multimedia applications such as Telepresence, Video share applications, mobile broadband applications and cloud computing has resulted in increasing network traffic and bandwidth requirements both for the consumers and application providers alike. With the increase in packet traffic a solution was needed where both TDM and packet traffic can be supported in a single transport element and also services can be directly mapped onto transport technology. Most of the applications require bandwidth on demand instead of permanent connections. Though the traditional SONET/SDH/DWDM solutions offer good bandwidth with high quality of Service with predictable protection and restoration capabilities, they lack in dynamic provisioning and flexibility in multiplexing services. Besides SONET/SDH networks required considerable amount of operational expenses for managing the networks and the circuits were not used efficiently hence keeping the costs high. This forces the service providers to look for new transport technologies that support very high bandwidth rates with high QoS while containing costs so the cost per GB bandwidth is still affordable. This led to the development of new standards for “Optical Transport Network” that provides flexibility to multiplex various services and also package the services efficiently on top of optical transport. In addition standards for automatic provisioning and restoration (ASON) have been developed that will reduce the provisioning time to activate the services and reduce operational costs for managing the transport network. 

Market Drivers
The advances in mobile broadband and new video streaming technologies led to proliferation of multi-media applications to the consumers. The bandwidth demands have now increased tremendously with more and more users signing up for FiOS and high bandwidth cable modem access services. The service providers now face the challenge of offering bundled triple play/quad play services with reduced cost. This has led to deployment of high bandwidth core networks with high quality of Service and stringent SLAs. Following are major market drivers to come up with new transport technology and management standards that will meet today’s requirements as well as be ready for tomorrow’s demands. 
  • WDM systems can support higher bit rates and SONET/SDH structures cannot support that high bit rates. A new technology that can switch and multiplex multiple payloads and efficiently utilize the wavelengths is needed to meet the demands of today’s market.
  • CapEx costs have to be reduced to offer low cost high bandwidth solution.  This requires that the overall hardware/software COGS need to be reduced by reducing the processing within transport elements to carry and process payloads.
  • Proprietary implementation for error corrections, OAM functions and operational procedures should be reduced or eliminated so a multi-vendor networks can be deployed.
  • Existing technologies are inadequate to monitor payload as a whole. It is difficult to correlate facility errors to payloads and services. Better monitoring at the payload level is required. A new technology that can transport Ethernet or SONET payload as a whole is required.  
  • Management of transport nodes in general has been very complex and it is vendor specific. End to end provisioning of transport network is a manual process and needs to be carried out with lot of planning.
  • Network Planning, Topology and discovery are very specific to NEs and it is difficult for operator to understand unless NE details are known.
  • Differences in NE behaviors for the same situations such as automatic protection, network fault restoration make it difficult to repair faults and restore services
  • Lack of interoperability between vendors makes it difficult to plan for multi-carrier/multi-vendor networks.
  • Due to this complexity the operational expenses has been very high which adds to the cost of per Gb bandwidth. Better standards are needed that will enable automatic end to end provisioning and restoration. 
ITU-T, Telcordia, IETF, OIF and various other standard forums have been working on the standards for next generation technologies. The OTN standards have gained popularity and the vendors have started implementing OTN systems. To address management complexities, standards for Automatic Switching of Optical Nodes (ASON) have been developed.

Optical Transport Network
Optical Transport Network standardization efforts were started to address some of the issues faced by service providers in deploying transport networks. The major issues were ability to support higher bandwidth rates, switching and multiplexing of various services and monitoring at service/payload level. OTN has the following advantages over traditional optical transport:

  • Supports higher bandwidth rates (2.5 G to 40G per wavelength)
  • Provides efficient packing of each wavelength
  • Dynamic multiplexing of services
  • Visibility of packet content for better monitoring
  • Supports both packet and circuit(TDM) traffic
  • Automatic restoration to recover from network faults
  • Support for multiple technologies (WDM, Sonet/Sdh, Ethernet, MPLS, Microwave radio links)
  • Multi-carrier, Multi-vendor interoperability due to support for standardization
  • Processes OAM similar to SONET networks
Telecom Equipment Manufacturers have already started to develop OTN systems and the initial systems are ready to be deployed. Service providers are already thinking of migration from traditional optical networks to OTN based deployments. The network management solutions for OTN network management need to be developed in order to complete and manage the OTN deployments.
Automatic Switched Optical Network
Automatic Switched Optical Networks concept is being developed to improve resource and connection management within optical networks. Traditionally it required manual provisioning of the cross connects for the entire network to enable a service. Depending on the SLAs,  the protection paths have to be pre-planned and all cross connects need to be manually provisioned. With the ASON standards automatic end to end provisioning is made easier and also dynamic bandwidth on demand services can be offered. Automatic restoration from network faults can also be achieved instantly The aim is to automate the end to end cross connect provisioning using GMPLS control plane communications between the network elements. ASON tries to provide a common information model for the transport network so the dependency on vendor specific information or behavior is greatly reduced or eliminated. The ASON standards address the following:
  • Resource Management
  • Automatic connection management and end to end path computation
  • Connection protection/restoration
  •  Bandwidth on demand requirements
  • Customer initiated connection requests, scheduled or time of day services
  • Topology discovery
  • Traffic Engineering
The ASON architecture proposes layered architecture for the management of optical networks. It consists of management plane (MP), Control Plane (CP) and Transport Plane (TP).
Management Plane provides Element management, Network management and Service management functions including FCAPS, service provisioning, and service monitoring. The management plane interacts with control plane using a common information model that represents the resources, links, connections, and bandwidth. The Control Plane implements control functions such as connection control, call control, routing, link resource manager, termination and adaptation functions and discovery agent. The transport plane contains transport resources and is responsible for resource provisioning. Figure below illustrates the relationship between the ASON architectural components (ref G.7718-Y1709 ITU-T standards).

The scope of control plane functions and the management view of the element management functions and interfaces as per ITU-T G.7718 y 1709 are illustrated in the figure below. The management plane will implement the FCAPS functions, end to end provisioning of static cross connects, billing, and interactions with control plane for automatic end to end provisioning and restoration.

Management Challenges
The deployment of transport networks involved high operational costs as the NOC operators were required to undergo training to understand the transport network element, their provisioning and behavior. Each vendor’s equipment had their own way of cross connect provisioning, NE specific behavior for fault management, protection and recovery The network planners need to plan both working path and protection path for every service and pre provision all cross connects. Dynamic changes were very difficult and service activation, monitoring and maintenance were quite complex.

The OTN and ASON standards were developed to reduce the complexity of service provisioning and increase the interoperability between multiple vendors so a multi-carrier, multi-vendor network can be deployed easily with high QoS and relatively lower cost. This requires:
 
  • All the vendors of OTN network elements to comply with the standards proposed by ITU_T and IETF
  • Common Information model and interfaces proposed by ASON should be used in control plane and management plane
  • All interoperability requirements should be specified by a common forum and efforts should be made to have the vendors conform to standard interfaces. This effort is already undertaken  by OIF.
  • The service providers should insist on interoperability conformance by vendors prior to deployment.
The ASON standards have proposed to delegate end to end automatic provisioning using control plane. Migrating from a traditional management solution to hybrid management plane – control plane solution brings additional challenges:
 
  • Maintain consistency between management plane and control plane for topology, link status and resources information
  • Resynchronization of information when communication between management plane and control plane communication restored or when changes occur in the network
  • Ensure consistent management policy across multi-vendor/multi-domain network
  • Synchronization and coordination between management plane initiated provisioning vs. control plane initiated automatic provisioning
  • Smooth migration from a traditional management to hybrid management and also providing backward compatibility to existing deployments
  • Accurate fault analysis of transport plane failures and timely restoration
The control plane and transport plane are implemented within equipment. The vendors typically have a tendency to add proprietary implementation to standards interfaces to differentiate or increase the value. If products are developed for control plane and management plane that comply with the above requirements, it will reduce the cost of development for equipment vendors and enable interoperability between vendors while reducing management complexities. 

OTN Management Solution

The primary objective for ASON based management solution is to reduce complexities in provisioning and enabling flexibility to support bandwidth on demand and scheduled  time of day services. Any management solution for managing OTN networks should support these objectives. The OTN management solution should support control plane interactions for automatic provisioning to comply with the ASON standards.

The deployment configuration for OTN solution is provided in the figure below. The Management Plane interacts with Control plane using NMI-A interface and transport plane using NMI-T interface. The end to end provisioning for a service involves following type of connections:

  • Permanent Connection (PC): This is similar to existing static cross connect provisioning and the EMS determines the working path and protection path and establishes permanent cross connect provisioning for the service in each node without control plane involvement. Here the EMS is aware of the topology and the circuit availability based on constant interaction with the network element. This is a manual process and may take weeks to complete the provisioning process.
  • Switched  connection (SC): These are the connections established by the client systems to establish a connection for a service on demand. This is accomplished by client systems requesting a connection via control plane, use the bandwidth and tear down the connection when the service ends.
  • Soft Permanent Connection (SPC): In this case the connections are established based on a schedule. The connections are requested by management plane for a service requesting time of day services or a scheduled service. The management plane requests control plane of an ingress node to set up end to end provisioning for a service. The management plane establishes the connections between client systems and ingress/egress nodes.
For supporting these services the management plane uses NMI-A interface to interact with control plane and NMI-T interface to interact with transport plane. The transport plane interactions are same as traditional management interface to a Network element which uses TL1, SNMP or XML interfaces. The NMI-A interface depends on the implementation approach for control plane. In a distributed control plane implementations interface such as XML, REST or CORBA can be used.    

NOCVue OTN Solution

NOCVue is a scalable management platform for developing Carrier-Grade EMS solutions.  NOCVue follows industry standard protocols and interfaces to communicate with Network Elements and Operations Support and Network Management Systems.  It provides a state-of-the-art graphical user interface with intuitive, consistent and flexible views for supported management functions.  NOCVUe supports multiple operating systems and multi-databases.  Out-of-the-box support includes the core FCAPS capabilities required for a typical carrier grade EMS and NMS solution.  The platform accelerates time to market and reduces development costs by incorporating many Carrier-Grade requirements in its core. OTN/ASON management requirements can be easily incorporated into NOCVue platform. The section below describes the NOCVue solution for managing OTN networks. NOCVue high level architecture is provided  in the figure below.

NOCVue supports N-Tier architecture to support scalability, extend-ability and modularity needed for any carrier grade Management application.
Management Application Server: 
  • Can be deployed in a 1+1 High Available mode or clustering mode..
  • Supports interfaces for communicating with a wide variety of clients based on Java Swing, Web client, North Bound OSS clients and 3rd party application clients.
  • Hosts FCAPS applications and technology specific solutions like Optical, Metro-Ethernet and WiMAX etc.
  • For OTN management an application for end to end provisioning and connection management of optical networks based on ASON requirements G.7718 y.1709 can be added. The topology, inventory, fault and performance monitoring modules can use data collected at the NMI-T interface as shown in the figure below.   For connection management the application can interact with OTN module in the NSE to send requests and receive responses and notifications from control plane. The traffic engineering database can be modeled and created by interacting with control plane.
  • NOCVue provides north bound interface based on TMF standards. Specific interfaces based on MTNM v3.5, TMF 608, TMF 814 standards can be easily plugged in to NOCVue solution.
Network Service Engine: 
 
    • Hosts the standard device specific management capabilities like Fault, Performance data collection, Software Upgrades, Provisioning etc. Vendor specific customization can be implemented on top these standard capabilities.
    • Can be deployed on multiple servers based on network segregation or based on the services provided by NOCVue.  This allows NOCVue to simultaneously manage hundreds of thousands of network elements per deployment.
    • Has a wide variety of built-in protocol adapters such as SNMP, XML, HTTPS, TL1 for communicating with Network Elements.  This will meet the NMI-T interface specified in ASON standards.  Additional protocol support can be easily plugged in to the solution.
    • For NMI-A interface XML based interface using the data model specified in ITU-T G 7718 series recommendations can be used. NOCVue platform already supports XML. The specific data model needs to be incorporated. 

NOCVue Control Plane:
  • NOCVue control plane solution is provided as a middleware that can be embedded in an Network Element for distributed CP implementation or used as a proxy outside the element to help migrate from older network deployments. The control plane incorporates control plane functions such as connection management, topology, link resource manager, inventory, bandwidth availability, and routing. Control plane supports UNI for interfacing with clients and XML to interface with management plane. It provides south bound adaptation layer to interface with TP. NOCVue control plane architecture is provided in the Figure below.
  • The NOCVue control Plane supports XML to interface with Management Plane, UNI and TP. Most of the Network Elements today support XML or Netconf based interface. So providing XML based middleware will be easier to support most of the vendors. Additional protocols can be easily supported by developing protocol adapters.   
Conclusion
The ASON standards specify the requirements for automated end to end provisioning and reduce the complexities in managing optical networks. With the distributed control plane approach the provisioning can be much faster as the Network Elements are aware of the topology, availability of resources and the current traffic engineering information for efficient routing. The end to end provisioning can be achieved in seconds as opposed to months that used to take with the network operators provision each device manually. Additionally flexibility can be introduced to offer bandwidth on demand and scheduled time of day services which most of the multi media applications today need.
NOCVue being a flexible platform with most of the protocol adapters already built in,  a OTN management solution can be easily developed in a short timeframe. Additionally a control plane solution can be easily offered along with EMS/NMS solution to increase the interoperability between equipments and management systems. Common database model can be used between EMS and Control plane and the integration efforts can be reduced tremendously. The control plane software can be easily plugged into the equipment software as a module and with XML based interface it can easily interact with other modules within transport plane. Developing a control plane software in house will take a long time and in addition one needs to worry about integrating with client software and management plane. A combined single vendor solution not only offers a quick solution to equipment vendors and also provides a one shop solution for the management challenges. 
 
About Velankani
Velankani is an Engineering and Consulting services company focused on providing full product life cycle development and support for enterprise and Carrier-Grade products for the telecommunications industry.  Velankani offers its customers a portfolio of products, resources and service quality that they need to secure a competitive edge in a global market.  Our mission is to enable telecommunications product vendors the ability to meet their time and cost constraints while exceeding their performance and quality expectations.
With its corporate headquarters in Piscataway, NJ, and a 22 acre technology campus in Bangalore, India, housing over 500,000 square-foot of office space.  Velankani has the facilities and human resources needed to complete a full range of systems integration and software and hardware development projects for its growing clientele.
Velankani is ISO 9001 certified company and it follows all the standard practices in term of process improvements.
For further details, please visit our websites: www.velankani.com and www.nocvue.com