Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : LAST MILE TECHNOLOGIES - Let's Discuss Them Here -- Ignore unavailable to you. Want to Upgrade?

To: Kenneth E. Phillipps who wrote (4352)	6/26/1999 5:36:00 PM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 12823

No bother at all, Ken. I enjoy the dialog. In theory, all NGDLCs should be interoperable, and it "should" be possible to manage them from a common set of tools, from an interface and feature/attribute perspective. That's why the standards and recommendations are there to begin with. It's interesting and important to note, however, that the operation of these platforms requires integration with back office systems known as operations support systems (OSSes) which are not always as open as one would expect, or as would be the case under truly ideal conditions. Far from it. Vendors are still incorporating their own differentiating, and proprietary OAM&P (operations, administration, maintenance and provisioning) rules and syntax in their software modules in their management systems. They do this for obvious reasons, and despite the efforts and the mandates being issued by some of the international forums which prescribe such things as Telecommunications Management Network (TMN) frameworks, and OSI Reference Model adherence. I'll mention a few of the reasons for these differences in a moment (which are bolded in the last paragraph). In other words, the protocols and the data rates at the port interfaces facing the customer will surely be be interoperable, but the management systems that govern these platforms are not. What to do, then, and how could this be? --------- For example, what we might have is a carrier employing any number of different vendors wares in the same service space or across different serving areas. Sometimes within the same serving area. The carrier manages these by utilizing a "manager of managers," or MOM, approach for the sake of performing element-level Simple Network Management Protocol, or SNMP, surveillance, and other OAM&P functions. In brief, there are still sufficient differences between the different vendor renderings, especially in their management systems, despite their port interfaces meeting 'standards-based' specifications. These differences are in the management software and they are sufficient to warrant the integration of higher level management tool (the MOM) in order to make them all appear to work like "one" set of features. The MOM, in effect, performs translations of the disparate SNMP alerts and other feeds which it receives from each of the downstream elements in the field, and transforms them to some common high level presentation that satisfies all of the individual vendors' profiles, as though they were one. Of course, as the TMN and other management frameworks for discreet service platforms become accepted on a broader basis, the degrees of variance between vendors will diminish, but rest assured that there will always be some differences in the ways vendors interpret the standards and how they elect to _include_ or _exclude_ certain options. Such differences might be packet level billing, QoS and prioritization functions, firewalling, and some aspects of design which are too esoteric to mention here, and so on, which will justify the need for a MOM function for some time to come. HTH. Regards, Frank Coluccio