Carrier Ethernet OAM Part 2

Standards bodies are defining the data collection, which is a good thing and could keep costs down. Discovering switches, the ports and E-line/E-Lan services configured in the switch can be made available in an inventory list view. Logical elements like services, UNIs, endpoints and profiles can also be captured by a discovery filter. These objects can be seen both under a network database list view and a Carrier Ethernet physical map. However, scale, high availability and the integration story is cloudy and can ultimately drive the costs up. Developing to a complex integration standard costs money. The end goal really is to enable informed, proactive management and swift problem resolution that effectively runs their operations.

To overcome the management challenge, we (and others) have pre-built object models to support standards-based equipment and extend the object model, which can be mapped to support various equipment.

There can be better control over networks with flow-through automation, real-time QoS performance and bandwidth monitoring that accelerates time-to-market and ensures customer Service Level Agreements (SLAs) via standards.

Performance monitoring and health checking can be real-time or historical on service and can go down to a port, EVC utilization or transmission errors, and perform QoS thresholds and KPIs. For fault, you can use RFC2544FdAlarm and RFC2544JitterAlarm that can are parsed and correlated into meaningful actionable alarms. Class-of-service flows can allow for testing of throughput, latency and jitter. The network can be engineered for different traffic priorities.

Configuration, activation and monitoring of RFC2544 tests as well as threshold definitions and notification reception can be supported. Provisioning the Ethernet services and OAM profiles can be accomplished via a user interface.  Logical elements like services, endpoints, UNIs, NNIs, and ports can be added. Various profiles like bandwidth profile, performance profile, an RFC2544 profile and CFM profile can be added and the same can be associated to endpoints of a service. 

The scaling challenge is always present and if architected correctly, management systems can scale to very large sizes. One way to accommodate scale is to use multi-threading data collection in a distributed hardware environment or virtual machines. This distributed data collection can roll up to a centralized backend to handle the correlation business logic, performance KPIs and reporting across the network.

High availability can be accomplished by hardening the OS and providing standby hardware and using database replication techniques (a topic for a future blog).

Lastly, system integration between management systems and OSS and BSS systems need not be expensive and standards bodies can tend to go overboard. Technologies can be accomplished using the cloud model by publishing an SOAP or REST API and using accepted industry protocols, which will keep costs down. The technology exists today — use it.

Eric Wegner works for Zoho Corp, http://www.webnms.com