 |
I came across an interesting situation recently and since I thought it might help other EMS Energizer readers, I am sharing it here.
One of our customers was faced with a situation that most companies would like to avoid – a mandate from its largest customer to get an EMS delivered under an extremely aggressive schedule. This is how the situation unfolded: The customer had been thinking of developing a complete management system for their device (at the present time they have a rudimentary management application) and were waiting to get a firm request from their largest customer (who happens to be a large carrier) before they spent the money on developing an enhanced management system. Since large carriers normally move slowly, they tend to give equipment vendors enough time to react especially if the equipment vendor happens to be a small company. Under normal circumstances when a large carrier begins to insist on a management application, the equipment vendor typically has about three months or so to get their management application ready before they get called on the carpet. In most situations, a three month window is sufficient enough time for a small equipment vendor to deliver a management application (at least phase 1) to the large carrier, provided the equipment vendor uses an EMS framework such as DNMS.
At the present time, since the economy isn’t exactly roaring along, the equipment vendor decided to hold off on embarking on a management application until the large carrier began to really insist on a full fledged management system - in other words threaten them with contract cancellation! Unfortunately in this case the equipment vendor misjudged their customer urgency and they were now in a bind to get a management system delivered to their customer in an extremely short period of time. In addition in this case the carrier had some unique requirements for their management application. As we all have experienced, when a carrier customer is large, they tend to act like the 800 pound gorilla that sits wherever it wants! This put the equipment vendor in the proverbial “between a rock and a hard place”, since they had to quickly deliver a management system that met the key requirements of the large carrier and yet be able to the salvage their investment in the management system so that they can make it into a product down the road.
Under this situation based on our EMS experience we would offer the following dos and don’ts to the equipment vendor
Do’s |
|
Don’ts |
Ensure that the customer requirements are clearly defined
Try to do the project in phases and keep the first phase as narrow in scope as possible
Set the expectations of the customer clearly - since time is short, if the project runs behind schedule some features may have to be traded off to keep the project on schedule
Try to keep in mind that since the schedule is extremely aggressive, it might have to be done as a “custom project” for the large carrier and not as a product to meet the larger market
Make a mid-project proof-of-concept release (even though time is short) to ensure that the customer requirements are met and there will be no surprises towards the end.
Have a person on-site at the carrier-customer location to do the basic proof of concept testing and provide inputs about the real environment
Set up a test network that replicates your customer’s network. This will be critical as the project time frame is very short
|
|
Try to be all things to all people and satisfy every requirement of the customer
Overlook quality expectations of the customer. It is important that the customer knows the focus of this effort is to deliver the project on schedule with an “acceptable” level of quality
Have an illusion that this “project” can be reused without any rewrites when the management application is aimed to satisfy the requirements of a larger market
Go directly for field testing; ensure that the management system is tested in the lab environment first
Start developing the application from scratch or use a weak platform, this will cause a lot of workarounds; it is better to use a proven management platform
Underestimate the scalability needs of the carrier as it is a very critical factor for the application’s performance in the longer term
|
Dhyan Infotech Inc is a software and services company that helps Equipment Vendors differentiate their products in the market place. Dhyan's EMS technology, DNMS (Dhyan Network/Element Management System), is a component based Element Management System, which has been widely deployed by Dhyan's customers at many Service Providers both small and large
If you have questions on EMS or related topic that you would like to get answered or would like to write a guest column in this newsletter, please send an email to ems-energizer@dhyanit.com. This is a complimentary newsletter that was sent to you because of your interest in EMS. If you do not wish to receive this newsletter please click here to unsubscribe
|
 |
Users’ requirements are shifting from just Internet access to rich applications such as e-commerce, data storage, video conferencing, VoIP (Voice over IP), Video-on-Demand (VoD), IPTV etc…which is causing the bandwidth to grow constantly. Apart from the bandwidth demand, each application expects high QoS (Quality of Service) as well. Carriers and service providers are forced to look for a technology that offers cost-effective, reliable, scalable and QoS-aware transport network to meet these demands.
Ethernet has become the most popular technology since its invention to meet the above demands. Ethernet is a full duplex, point-to-point layer-two protocol, initially developed for LANs (Local Area Networks) which supported speeds of up to 10Mbps (mega bits per second). This conventional Ethernet is cost effective and a simple system, but is challenging to modify or expand.
Ethernet technology’s aim is to forward data to its intended destination in the network. This is quite simple when the given destination address is in the same network. If it is not in the same network, the data is broadcasted over all available ports which causes problem in the effective usage of the available bandwidth. When the network grows larger, the problem becomes more severe. To improve bandwidth usage, some protocols such as ‘Spanning Tree’ were developed to decide the path of the data. But it is still difficult to predict network performance and provide guaranteed QoS and SLAs (Service Level Agreements). Service providers need a way to deliver guaranteed, deterministic services over Ethernet infrastructure on a wider scale without losing Ethernet’s cost effective benefits.
Most of the problems with the Ethernet are related to the connectionless nature. The Metro Ethernet Forum (MEF) pioneered the term Carrier Ethernet by classifying several significant technical attributes as given below that distinguish it from the more familiar enterprise Ethernet.
|
Standardized services: Customers can receive a wide range of standardized yet improved services, including converged network services, over existing equipment |
|
Scalability: Can be implemented in bandwidth from 1Mbps to 10Gbps and beyond |
|
Reliability: The network can quickly detect and recover from incidents without impacting users |
|
Quality of service: Wide choice of SLAs for end-to-end performance of business and residential services |
|
Service management: The ability to monitor, diagnose and centrally manage the network with standards-based systems and operations management. |
The key differentiator that makes a network ‘Carrier Grade’ is the OAM (Operation, Administration and Maintenance) capability. Metro Ethernet supports high bandwidths with fine granularity and at the same time it allows bandwidth to be altered dynamically, if required. Carriers offer more capacity and services and need more efficient ways to initiate, monitor and reconfigure services which implies that the management system is highly critical for its success. There are a number of standards being developed by standard bodies to handle various OAM issues, specifically those involving Ethernet in the ‘last mile’.
|
IEEE 802.1ag (Connectivity Fault Management) — Specifies support for proactive alarming of service faults and assists with the detection, verification and isolation of connectivity failures. |
|
IEEE 802.3ah (Ethernet in the First Mile) – Defining Ethernet PHYs for first mile access, be it copper, PON (Passive Optical Network) or point-to-point fiber, to allow data communication to Ethernet customer premises equipment. |
|
IEEE 802.1AB (Station and Media Access Control Connectivity Discovery) – Is required to enable standardized topology discovery by management/OSS. |
|
ITU G.8031 – SG15 Ethernet Protection. |
|
ITU Y.1731 – SG13 Ethernet OAM, which augments 802.1ag with additional performance monitoring capability. |
|
MEF Ethernet Performance Monitoring |
OAM is a key challenge as Ethernet moves into a Metro/Carrier Ethernet services. Ethernet OAM standards are in place to address most of the issues. These new standards will drive new management solutions that can address most of the operational challenges and is the key to managing Ethernet service OPEX costs. |
 |
A leading equipment vendor who is delivering best-in-class optical devices to the global marketplace for Packet Ethernet network was looking for a full fledged EMS. They had rudimentary nodal management software to configure and manage network elements which was deployed as a local craft terminal for local or remote element access. The nodal management software had several shortcomings such as being unable to (i) manage a network with more than 1000 nodes, (ii) view more than two performance metrics simultaneously, (iii) support multiple southbound interfaces, and (iv) persist data. They approached Dhyan to build a complete management solution which is to be compliant with appropriate standards.
To meet customer requirements, Dhyan developed a secure, flexible and robust end-to-end integrated management system based on the DNMS platform, as per the technical specifications mentioned in MEF 15 (Requirements for Management of Metro Ethernet Network Elements) standard. The core management functionality covered in this specification is grouped into four functional categories: Configuration Management, Fault Management, Performance Management, and Security Management.
The following list describes the features supported in the management solution in each of the functional groups as per the specification:
 |
Fault management |
 |
Detection, identification and correlation of the faults as and when it occurs and providing various management functions for addressing the faults to make service personnel’s work easy.
|
|
Northbound forwarding support to forward traps received from various network elements to NOC clients. Other than trap forwarding, email, pager and media forwarding are also supported.
|
|
Alarm management feature which helps a user to view and acknowledge alarms, assign an owner and update remedy for the alarm, manual forwarding etc are supported as well.
|
|
Configuration management |
|
Software maintenance, periodic upgrades of software and making various provisioning activities seamless to the end-user.
|
|
Network element database backup feature which enables a user to do scheduled backup periodically or instant backup when required
|
|
Performance management |
|
Real-time statistics collection and presentation of raw statistics in various graphical charts for an end user to easily understand the current network usage pattern and also be able to predict future usage patterns.
|
|
Statistic notification feature which notifies the registered users about the status and statistics in the form of reports via mail or FTP depending on the data size.
|
|
Security management |
|
Access control to the EMS application thereby offering protection; maintaining access logs and audit trails to answer questions such as who did what, when, how etc.,
|
|
Provide users to view the network element user and group details; be able to add a single user to a particular element or a bulk addition to various network elements
|
In addition the solution also supports features such as auto discovery, real-time view of the network deployment, auto-provisioning, chassis view and inventory management. |
____________________________________________________________________________________
|
|
If you have any comments or questions or would like to write a guest column in the energizer, please send an email to
ems-energizer@dhyanit.com
This is a complimentary newsletter that was sent to you because of your interest in EMS. If you do not wish to receive this newsletter please click here to unsubscribe.
|
|
|
| |
| Participation in trade shows: |
|
October 21 -23, 2009
McCormick Place,
Chicago, IL |
|
October 27 -30, 2009
Colorado Convention Center
Denver, CO
|
|
November 16-20, 2009
Jacob Javits Convention Center,
Newyork, NY |
|
| |
|
| |
Q |
What is MEF and what are the technical specifications developed by it? |
|
A |
The MEF (Metro Ethernet Forum), formed in 2001 is a non-profit organization chartered with the mission of accelerating worldwide adoption of carrier class Ethernet networks and services.
|
|
This mission is in direct response to the opportunities made available by:
|
The need and demand for a simple ubiquitous service |
|
Requirement to scale network services to enable rapid deployment of applications critical to enterprises and service providers.
|
|
Availability of low cost, high bandwidth of Ethernet, beyond the LAN |
|
Convergence of business, residential and wireless services |
MEF has approved the following technical specifications:
MEF 2: Requirements and Framework for Ethernet Service Protection |
MEF 3: Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks
|
MEF 4: Metro Ethernet Network Architecture Framework Part 1: Generic Framework |
MEF 6.1: Metro Ethernet Services Definitions Phase 2 |
MEF 7: EMS-NMS Information Model |
MEF 8: Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks |
MEF 9: Abstract Test Suite for Ethernet Services at the UNI |
MEF 10.1: Ethernet Services Attributes Phase 2 (supersedes MEF 10, below) |
MEF 11: User Network Interface (UNI) Requirements and Framework |
MEF 12: Metro Ethernet Network Architecture Framework Part 2: Ethernet Services Layer |
MEF 13: User Network Interface (UNI) Type 1 Implementation Agreement |
MEF 14: Abstract Test Suite for Traffic Management Phase 1 |
MEF 15: Requirements for Management of Metro Ethernet Phase 1 Network Elements |
MEF 16: Ethernet Local Management Interface |
MEF 17: Service OAM Framework and Requirements |
MEF 18: Abstract Test Suite for Circuit Emulation Services |
MEF 19: Abstract Test Suite for UNI Type 1 |
MEF 20: UNI Type 2 Implementation Agreement |
MEF 21: Abstract Test Suite for UNI Type 2 Part 1 Link OAM |
MEF 22: Mobile Backhaul Implementation Agreement |
MEF 23: Class of Service Phase 1 Implementation Agreement |
MEF 24: Abstract Test Suite for UNI Type 2 Part 2 E-LMI |
MEF 25: Abstract Test Suite for UNI Type 2 Part 3 Service OAM |
|
|
| |
|
| |
Dear Ram, |
I would like to take this opportunity to let you know that your company has a very capable network management applications development team. After having had a chance to work with your team, I was very impressed with their knowledge, skills, efficiency, and in addition I found your cost structure to be very competitive and attractive.
There are two areas I want to explore: (i) potential of Dhyan working on projects related to datacenter services, and (ii) potential to establish Dhyan as a trusted development partner in developing network management solutions for us.
I’ve copied my executive assistant to facilitate a meeting in the next week or two.
|
Regards,
VP, Engineering |
|
|
