Smart packets: applying active networks to network management
ACM Transactions on Computer Systems (TOCS)
The Active Process Interaction with Its Environment
IWAN '00 Proceedings of the Second International Working Conference on Active Networks
| Hi-index | 0.00 |
From the Book:Preface: Welcome to the revised 2nd edition of The Simple Book. This edition has ben updated to reflect developments in the world of network management since 1990. Since that time, the field has seen a maelstrom of activity. It would be foolhardy to attempt a tome that spans the whole of the field. Instead, The Simple Book focuses on the center of the activity, the Simple Network Management Protocol (SNMP), and the latest revisions to the newly standardized version 2 of the protocol, SNMPv2. This book is about the technology used to manage large communications, infrastructures, termed internets. These are composed of wide and local area networks and consist of end-systems, such as hosts, terminal servers, and printers; intermediate;systems, such as routers; and, media devices, such as bridges, hubs and multiplexors. In the last few years, the rapid growth of the number and size of internets has made management of these networks difficult: equipment additions and changes often lead to configuration errors; increased scale makes earlier, ad hoc tools impractical; increased heterogeneity makes proprietary tools unusable; and, wider range of staff expertise requires more sophisticated tools which are easier to use. In addition to the need to keep today's networks running, there is also a need to collect traffic and utilization data, so as to design, plan, and justify new extensions. Throughout The Simple Book the emphasis is on managing internets built using the Internet suite of protocols (commonly known as TCP/IP), the first success of the Open Systems philosophy. As such, it shouldn'tbesurprising that these internets are, by their very nature, heterogeneous, multi-vendor environments. Even so, the perspective presented is meant to be generic towards any kind of internetworking technology. Indeed, for better or worse, many of today's internets carry traffic from more than one protocol suite. History of Networking Management At the very end of the '80s, the network management protocol wars drew to a close. The solution of choice was based on something called the Internet-standard Networking Management Framework. This was a modest set of three documents defining: a set of rules for describing management information; an initial set of managed objects; and, a protocol used to exchange management information. This framework, at under 150 pages, was sufficient to provide a base for vendors to develop products that users could deploy. In fact, the document defining the protocol, the Simple Network Management Protocol (SNMP), was a mere 36 pages in length. In order to promote stability, and yet allow for incremental evolution, the group that oversees the development of the Internet suite, made an important policy decision: the framework could be extended by defining new managed objects, but changes to either the description rules or the protocol weren't allowed. today, with literally hundreds of SNMP- capable products, and thousands of managed object definitions, it is easy to appreciate what a wise decision the was. Because the protocol remained stable, vendors could incorporate SNMP early into a product line's lifecycle, and have interoperability across the wire. Then, as managed objects were defined for the particular kinds of products, only those specific products were affected. Unfortunately, the initial three documents weren't entirely complete. Some details were inadvertently absent. Other details, learned through implementation experience, were also missing. Of course, as more people started implementing SNMP-based products, they occasionally would interpret parts of the document differently than the writers had intended. These problems partially motivated the 1st edition of The Simple Book, which attempted to capture a great deal of the missing oral tradition. Hopefully, the first edition was a success in this regard. More importantly, The Simple Book tried to present the material in a more readable fashion. A Digression Before continuing, it is time to introduce a typographical convention used in this book. The author strives to present a balanced set of perspectives. When discussing technical matters, this is usually straightforward. Unfortunately, a lot of the issues involved are inherently non-technical in nature. From time to time, this book will express non- technical perspectives, but will label them as such, namely as soapboxes. Look for text bracketed between the symbols soap... and ...soap, which appear in the margin. At this point, it is customary to berate the opposition. In this case, I am referring to people who think that the OSI-based approach to network management (as encompassed by CMIP, the GDMO, etc.) is a good thing. After all, we are in soapbox territory! To understand the technical reasons why the OSI-based solution is fatally flawed, consult Appendix C. For now, I will merely observe that the market has made its choice: people interested in real solution to real problems go out and buy SNMP-based products, whilst people interested in politically-correct networking and marketing posturing favor talking about how wonderful the OSI approach will eventually be. As might be expected, the burdens of reality very rarely enter into these weighty marketing discussions of OSI-based network management, despite the fact that the market requires solutions, not apple juice and cookies. Where We are Now Since the three documents were originally issued in 1988, two independent trends have demonstrated the desirability of an evolution to SNMP. First, the work on SNMP security was completed in early 1992. These security features introduce rigorous authentication, authorization, and privacy features. Unfortunately, they also require a change to the envelopes used to carry SNMP traffic. Second, considerable implementation experience led to a greater understanding of how SNMP could be improved to be more effective, in terms of both efficiency and power. In mid-1992, a proposal termed the Simple Management Protocol (SMP) and Framework was suggested as the basis for the second version of SNMP. Although both efforts were considerable motivated to minimize the number of incompatible changes, some were necessary. As such, the community decided that it would be best to merge the two efforts and have a single (long-lived) transition. (The alternative, two transitions, was unthinkable!) So, a working group was formed to develop a new version of the Internet-standard Networking Management Framework (simply called SNMPv2), and to coordinate their efforts with the SNMP security working group. The working group completed its efforts in early 1993. And this has led to the publication of the 2nd edition of the The Simple Book. The good news was that the oral tradition was now written down in the documents (instead of three). That's progress for you! Unfortunately, some parts of SNMPv2 were better than others. In particular, the approach taken to add security features to SNMP had proven unworkable in the field; and, as a result, adoption of SNMPv2 in the marketplace was virtually non-existent. When the working group reformed in late 1994 to revise SNMPv2, there was tremendous dissatisfaction. Further, there was little technical direction on how to proceed other than continuing along the mis-directed path that SNMP security had originally set upon. After months of acrimonious debate, it became clear that consensus could not be reached on how to overhaul the unworkable parts of SNMPv2. As a result, the working group opted to expunge the security enhancements and move forward with the remainder. And this has lead to the publication of the revised 2nd edition. Of course, work continues on SNMP Security... A Final Note April, 1995, marked the end of my term as the IETF's Area Director for Network Management. I did not seek a second term, rather I pressured someone with sound technical judgement, superior interpersonal skills, and considerable more patience, to seek that office. It is to the benefit of the community that Deirfre C. Kostick, was confirmed in that role, though it is arguable as to whether it benefits her mental health. Regrettably, the IETF, the body which produced the original SNMP and its successor, SNMPv2, has fallen on hard times it now behaves as, and worse believes itself to be, a standards body! In the past, I have fondly referred to the IETF's credo of rough consensus and running code. Today, however, this lofty goal is more the exception than the rule. As evidence of this unhappy state, consider a threshold moment occurring in early 1995: whilst specifying the security wrapper for the next version of IP, the IETF's management decided to mandate inclusion of privacy as a part of this technology. (Actual use of privacy would be determined by each administrator, but in order to claim to conformance to the next version of IP, a product must include privacy.) Privacy technology, of course, is subject to both stringent export and use controls. These controls are a matter of various national policies and international treaties. Regardless of whether these policies are helpful, they are not to be taken lightly. Increasingly, in recent years there has been intense debate as to whether these restrictions should be reduced or eliminated. Nevertheless, in the US and many other countries, products which include general-purpose privacy must be licensed for export on a sale-by-sale basis. It is important to distinguish between technical and policy decisions. A technical decision might be how to apply cryptographic techniques when encrypting data; in contrast, a policy decision might be mandating privacy for a particular application or product. The IETF's management (and others) feel that approving, as an Internet standard, a document which mandates privacy will result in a fait accompli that this will somehow force the various national policies and international treaties to change. This demonstrates a height of arrogance that can only be achieved by a body which thinks itself empowered to declare market standards. Perhaps the term delusional might be more appropriate, given that the IETF has difficulty in even scheduling its meetings in advance. Indeed, it is quite clear that the Internet and its suite of protocols have increasingly prospered in recent years in the marketplace not because of the IETF, rather they have prospered in spite of the IETF, and its myriad of bureaucratic bungling and petty politics. Fortunately for me, the IETF is SNMP Simply Not My Problem. However, the real question is this: if the IETF continues down this path, at what point will it lose its relevance in the marketplace?