An increasingly common problem faced by NMS software developers is implementing network management support for new NE features, such as MPLS. The following four steps provide a linked overview of the management aspects of an NE feature:
Step 4 essentially automates the actions in steps 2 and 3. The software produced in step 4 can then form the basis of Java classes that can eventually be imported into the finished NMS. The final stage in development is then adding code to the NMS to implement the overall MPLS management feature (i.e., FCAPS). An important observation about the above is that it depicts NMS development as a type of reverse engineering. If network management is provided at the end of NE development, then it has a reverse engineering flavor. If the two occur in parallel, then no real reverse engineering effort is required. We therefore view a linked overview as the resulting knowledge emanating from following the above four steps.
Some vendors provide simultaneous releases of both NE firmware and NMS software. In other words, NE and NMS development are inextricably interwoven. Step 1 can be assisted using the RFCs on the IETF Web site [IETFWeb]. The other steps are carried out in conjunction with the NEs themselves . Some examples of linked overviews now follow. Developer Note: An ATM Linked OverviewMany technologies can seem extremely complex at first, and then, as the learning curve progresses, the essential patterns begin to emerge. ATM [Tanenbaum1996], [ATMObjects] is a good example. Stripped down to its bare (linked overview) essentials:
This list provides an overview of ATM technology. It joins (or links) the principal components needed for managing ATM. From this list, the essential ATM managed objects can be derived:
This is a good start on the road to defining managed objects for the support of ATM. It points to the merit of studying documents from the ATM Forum and ITU-T Broadband ISDN. The next stage (step 2) would be to experiment with the EMS of an ATM switch and see the above objects in practice, e.g., creating PVCs and SPVCs. Next , we would examine the MIB objects (step 3) [ATMObjects] involved in step 2, and then produce software (step 4) to read and write instances of those objects. Developer Note: An IP Linked OverviewThe convergence of layers 2 and 3 (e.g., connection-oriented operation of layer 3 networks) has forced the need for knowledge about IP onto practically everyone's agenda. IP is often used as an abbreviated form of TCP/IP, and this is the way it is used in this book. Like UNIX and Ethernet, IP is one of the great software engineering feats of the 20th century. Both are in widespread use (although UNIX, unlike DOS or Windows, has no single standard implementation) and have withstood the test of time. IP has a steep learning curve, but it can be summarized into a linked overview as follows :
So, the essential managed objects of IP are:
The next stage (step 2) would be to experiment with the EMS of an IP router (or an IP/MPLS switch) and see the above objects in practice, for example, creating IP interfaces and subnets, and configuring routing protocols. Next, we would examine the MIB objects (step 3) involved in step 2 and then produce software (step 4) to read and write instances of those objects. Embracing Short Development CyclesThe need for immediate ROI is prompting a demand for innovative management system solutions. Enterprises must be able to leverage their investments for both productivity (easier operation of networks) and financial gains (smoother business processes). This can result in shorter NMS software development cycles, which in turn requires a modified approach to producing NMS:
If a management system release occurs every four or five months, then it is no longer necessary for every single requirement to be fulfilled. Instead, requirements can and probably should be prioritized over a range of releases. When a new technology is adopted and implemented on a range of NEs (such as VoIP or FR interworking), then only the mandatory management facilities should be implemented first. The rest can follow later. The first release becomes a foundation for the later ones. In time, the initial reduced feature set grows steadily to become part of a sophisticated end-user solution. Not all users would necessarily upgradejust the ones who need the new foundation release features. The developers would carry out the bulk of the testing. As the releases occur, the user's data has to be carefully protected and upgraded as necessary. So, upgrade issues (such as scalability- related database schema changes) increasingly have to become part of the bread-and-butter of development. Implicit in all this is the end user becoming a development partner providing valuable operational feedback. The user receives regular, reliable releases, and the vendor sees fast return on development investment. Another benefit is that developers gain experience and expertise with each of the minor releases. Minimizing Code ChangesPerhaps one of the most difficult software development skills to acquire is the ability to resist changing code. This applies to good and bad code, old and new. A crucial skill for developing NMS software is the ability to make small, focused fixes for specific problems without introducing new bugs. It can be extremely difficult to resist making simultaneous changes to neighboring code, but it is a vital discipline. Unnecessary code changes introduce bugs and increase the need for testing. Every code change should be fully tested as part of a mandatory change control process. |