EIDGENÖSSISCHE TECHNISCHE HOCHSCHULE LAUSANNE
`POLITECNICO FEDERALE DI LOSANNA
`SWISS FEDERAL INSTITUTE OF TECHNOLOGY LAUSANNE
`
`COMMUNICATION SYSTEMS DIVISION (SSC)
`CH-1015 LAUSANNE, SWITZERLAND
`http://sscwww.epfl.ch
`
`Push vs. Pull in Web-Based Network Management
`
`Jean-Philippe Martin-Flatin
`
`Version 1: July 1998
`Version 2: October 1998
`
`Technical Report SSC/1998/022
`
`Petitioners' Exhibit 1025
`Page 0001
`
`

`

`Push vs. Pull in Web-Based Network Management
`
`Submitted in July 1998 to IM’99, Boston, MA, USA, May 1999
`
`Jean-Philippe Martin-Flatin
`EPFL-ICA, 1015 Lausanne, Switzerland
`Email: martin-flatin@epfl.ch Fax: +41-21-693-6610 Web: http://icawww.epfl.ch
`
`Abstract
`
`In this paper, we show how Web technologies can be used effectively to (i) address some of the
`deficiencies of traditional IP network management platforms, and (ii) render these expensive platforms
`redundant. We build on the concept of embedded management application, proposed by Wellens and
`Auerbach, and present two models of network management application designs that rely on Web
`technologies. First, the pull model is based on the request/response paradigm. It is typically used to
`perform data polling. Several commercial management platforms already use Web technologies that
`rely on this model to provide for ad hoc management; we demonstrate how to extend this to regular
`management. Second,
`the
`is
`a
`novel
`approach which
`relies
`on
`the
`push model
`publish/subscribe/distribute paradigm. It is better suited to regular management than the pull model, and
`allows administrators to conserve network bandwidth as well as CPU time on the management station.
`It can be seen as a generalization of the paradigm commonly used for notification delivery. Finally, we
`introduce the concept of the collapsed network management platform, where these two models coexist.
`
`Keywords: Web-Based Management, Network Management, Push Model, Pull Model, Embedded
`Management Application, Collapsed Network Management Platform.
`
`1. Introduction
`
`If we consider the design of an IP network management application with a software engineering perspective, it is a fairly
`simple case of distributed application. There are no stringent requirements put on it, such as real-time constraints or fault
`tolerance, and some management data may even be lost. Its complexity stems from only two points: there is a large,
`sometimes very large number of nodes to manage; and all management data traffic is considered as network overhead,
`and should therefore be kept to a minimum.
`
`In the same perspective, if we analyze how IP networks are typically managed today, (that is, how network management
`platforms are designed, how efficient is SNMP as an access protocol, and how efficient is the principle of data polling
`inherent to the manager/agent paradigm), it is clear that most network management applications do not withstand the
`comparison with modern distributed applications. Why not use object-oriented analysis, design and implementation,
`which are widely adopted by the industry today? Why be limited by the few existing SNMP protocol primitives to collect
`data from an agent? Why incur the network overhead of having the manager repeatedly tell every agent what selection of
`MIB variables it is interested in, when this selection remains constant over time? Why not compress data efficiently when
`it is transferred between agents and managers? Why use an unreliable transport protocol to send a critical alarm to a
`management station when an interface goes down on a backbone router? Why make it so difficult to cross firewalls to
`manage remote subsidiaries? Why are management data transfers so often insecure?
`
`In light of the technologies widely used today, many design decisions in IP network management appear inefficient or
`outdated. But they did not in 1988-90, when the first SNMP framework was devised. Moreover, if we place ourselves in
`a historical perspective taking into account how the market evolved [13], many deficiencies in today’s commercial
`network management platforms can be analyzed and understood. The success of SNMP-based network management is
`due to a large extent to its simplicity, so it would be unfair to criticize this simplicity afterwards. Still, the way IP networks
`are typically managed in practice evolved very little throughout the 1990s. If IP network management continues to evolve
`so slowly, it runs the risk of going from simple to simplistic. This could result in a plethora of alternatives being proposed
`by multiple vendors, and in the end of open integrated network management.
`
`As we showed in earlier work [12], there are several alternatives to traditional SNMP-based management: we have
`Web-based management, mobile agents, active networks, CORBA, intelligent agents, etc. In our view, Web technologies
`are the best candidate for improving this situation in the short term. The reason for this is fivefold. First, the solutions we
`describe in this paper are simple, and could be engineered and widely deployed in less than a year; mobile agents,
`
`1
`
`Petitioners' Exhibit 1025
`Page 0002
`
`

`

`conversely, require secure environments (especially for WAN links) which no one can provide currently; similarly,
`simple, yet efficient multi-agent systems for IP network management still remain to be seen. Second, Web technologies
`have a limited footprint on network devices, unlike CORBA. Third, not only do Web technologies bring solutions to the
`above-mentioned problems, as we demonstrate in this paper, but they also offer a smooth migration path, a key feature if
`they are to be adopted by the industry. Fourth, they allow keeping a coherent single framework for open network
`management, unlike WBEM. Fifth and last, the World-Wide Web has encountered lately a tremendous success in the
`enterprise world. Its simplicity, together with the portability of Java, have made it so ubiquitous that it is difficult today
`to find any software engineering field that is not using (or migrating to use) one of its early technologies (Web browsers,
`HTTP, HTML and CGI scripts) or one of its newer technologies (Java applications, applets, servlets, RMI and JDBC).
`Web expertise is rapidly developing worldwide, and it makes sense to capitalize on this in network management.
`
`The idea of using the Web in IP network management is not new. Experiments with the early Web technologies (that is,
`Web browsers, HTTP, HTML and CGI scripts) started in 1993-94. Initially, they were only confined to secondary tasks.
`For instance, people developed HTML forms to standardize and automate problem reporting, which facilitated the work
`of calldesks. Network administrators also replaced daily, weekly and monthly printed reports with electronic versions put
`on an internal Web server. More interestingly, administrators began writing symptom-driven HTML forms that operators
`could use for routine network troubleshooting; the interactive interfaces provided by the Web proved to be much more
`user-friendly than the thick binders full of procedures that operators were used to. When network equipment documen-
`tations were shipped in electronic format, they were put on internal Web servers; not only were they easier to access, but
`administrators could then directly embed pointers to relevant pages of the documentation within symptom-driven HTML
`pages. This integration of documentation, procedures and tools was a step forward in network troubleshooting.
`
`The first important step toward Web-based network management was taken when vendors began embedding HTTP
`servers in their network equipment. Bruins [2] reports some early experiments made by Cisco in 1995, whereby the entire
`command
`line
`interface was mapped
`to URLs.
`For
`instance,
`a Web
`browser
`could
`request
`<URL:http://router_name/exec/show/interface/ethernet0/> to a router, which would treat it as if the command line
`show interface ethernet0 had been typed in interactively. This opened new doors for configuration
`management and symptom-driven HTML forms, as there was no more need to telnet into network devices.
`Mullaney [16] also describes work conducted by FTP Software, whereby agents send a static, locally stored, or a
`dynamically generated HTML page back to the management station in response to an HTTP get or post request.
`
`The second important step was taken when Java applets appeared in Netscape’s famous Web browser, in 1995. To the
`best of our knowledge, the new horizons that this technology opened up in network management were first published and
`advertised in the July 1996 issue of The Simple Times. The founding article by Wellens and Auerbach [25] introduced
`the concept of embedded management application, and showed the advantages of using HTTP rather than SNMP to
`vehicle data between managers and agents. Although the authors do not explicitly refer to applets in their article, the
`solution they propose is to transform an add-on (that has to be ported to many different management platforms and
`operating systems) into a single applet that can run everywhere. This applet is stored in the managed device, and uploaded
`by the administrator via a Web browser. Communication between the applet and its origin agent later relies on HTTP
`instead of SNMP. Bruins [2] explicitly refers to applets in his description of prototype work by Cisco; but in the scenario
`he describes, once the applet is uploaded, subsequent communication with the agent relies on SNMP, not HTTP, which
`is a poor use of applets as we will show in section 3.2.2.
`
`Wellens and Auerbach’s applet-based approach has now been adopted by many network equipment vendors, who embed
`HTTP servers and management applets in their equipment, but also by some network management platform vendors, who
`support Web browsers as front-ends to their network management platform.
`
`Since the time of this proposal, many new technologies have appeared on the Web. Today, besides applets and Java
`applications, we can also use servlets, RMI, etc. All these technologies open new possibilities and enable new designs of
`network management applications. Leveraging on these new technologies, we propose to push Wellens and Auerbach’s
`idea two steps further. First, we show that the design paradigm they propose is just one instance of a more general
`paradigm, the pull model, which can not only be applied to ad hoc management, like they do, but also to regular
`management. Second, we introduce a novel design called the push model. Unlike the pull model, it is not based on the
`request/response paradigm, but on the publish/subscribe/distribute paradigm. With this scheme, management data
`transfers are always initiated by the agent, like SNMP notifications delivery in pre-Web network management. The push
`model reduces network overhead, and moves part of the CPU burden from managers to agents.
`
`The remainder of this paper is organized as follows. In section 2, we present a summary of the main shortcomings of
`traditional SNMP-based network management, and outline how Web technologies can address them. In sections 3 and 4,
`
`2
`
`Petitioners' Exhibit 1025
`Page 0003
`
`

`

`we present the engineering details of the pull model and the push model, and analyze the pros and cons of three communi-
`cation technologies: HTTP, sockets and RMI. Finally, we introduce the concept of collapsed network management
`platform in section 5, and conclude with some perspectives for future work.
`
`2. Problems with Traditional SNMP-Based Network Management
`
`This section presents an overview of the problems encountered in traditional SNMP-based network management (that is,
`IP network management before the Web days), and describes how Web technologies can address them. These problems
`can be grouped into four categories: network management platforms, protocol efficiency, security, and transport protocol.
`The terminology used in this paper, as well as the model of a network management platform on which our analysis is
`based, are both presented in detail in [13].
`
`2.1. Network management platforms
`
`In a recent paper [13], we presented a brief history of IP network management before the Web days, showing how people
`came to use vendor-specific management GUIs (called add-ons when they are integrated in network management
`platforms). This paper also details the shortcomings of IP network management before the Web. To summarize, customers
`have four grievances: (i) network management platforms are too expensive, in terms of hardware and software; there
`should not be a need for dedicated hardware to manage networks; (ii) there should be unlimited support for third-party
`RDBMSs; today, customers are limited by the peer-to-peer agreements that have been signed, or not signed, between
`RDBMS vendors and network management platform vendors; if they want the latter to support another RDBMS that they
`happen to own already, they are charged enormous amounts of money for the “port”; (iii) for the sole purpose of network
`management1, some customers must support a Unix system, although they run a business entirely based on PCs and/or
`Mac’s; they want to use a PC or a Mac instead, but they do not want to buy a whole new (and expensive) network
`management platform.
`
`The answer of Web-based network management to grievance (i) is the collapsed network management platform, that we
`will gradually introduce in this paper. Grievance (ii) is addressed by JDBC, although there is a problem with regards to
`the poor execution speed of Java interpreted bytecode (even when speed-up techniques are used, such as the JIT compiler).
`Grievance (iii) can be solved by the platform independence of Java and the universal interface offered by Web browsers.
`
`Network equipment vendors, on the other hand, are dissatisfied primarily by the huge costs they have to bear to support
`device-specific management GUIs for their equipment. To customers, a given GUI looks more or less the same, no matter
`what management platform is used underneath. But to network equipment vendors, it does not. When a new management
`GUI is released, the code has to be ported to many different operating systems (Windows 95, Windows 98, Windows
`NT 4.x, Solaris 2.x, HP-UX 10.x, HP-UX 11.x...) and many different management platforms supporting different APIs
`(HP OpenView, Cabletron Spectrum, Sun Solstice, IBM NetView...). Over time, despite the relatively small number and
`the stability of the major management platform vendors, the number of devices supported by each vendor and the number
`of operating systems to port to have grown so large that the maintenance costs of these management GUIs have
`skyrocketed.
`
`With Web technologies, this problem is solved by applets, as we will see in section 3: the multiple incarnations of the
`same add-on are all replaced with a single piece of code, the management applet, written in Java.
`
`Customers and network equipment vendors share two other concerns. First, they both want the time-to-market of
`management GUIs to be reduced. When they purchase a brand new piece of equipment, customers want to be able to
`manage it immediately via their favorite management platform. But many months can pass between the time a new
`network device that has been trumpeted by marketing is finally released and sold to customers, and the time its
`vendor-specific management GUI has been ported to all operating systems and all existing network management
`platforms. There are many environments where the constant availability of the network is critical to the smooth running
`of the business, and network equipment cannot be purchased unless it can be managed. So, for large companies that have
`peer-to-peer agreements with all major management platform vendors, there is a time window during which they cannot
`
`1. Until roughly 1995, Windows-based network management platforms were not powerful enough to manage large networks and run
`large RDBMSs: in such environments, you had to buy a Unix system. Since then, the power of PCs has increased dramatically, much
`more than the power of Unix workstations. Customers who buy a management platform today are not exposed to this problem
`anymore.
`
`3
`
`Petitioners' Exhibit 1025
`Page 0004
`
`

`

`sell to these customers; this is a problem for customers and vendors alike. For small companies, and especially for start-up
`companies specialized in cutting-edge technology, this problem is even worse. As their market share is close to zero, they
`are of no interest to management platform vendors, who do not bother signing peer-to-peer agreements with them. Hence,
`customers who want to buy from small companies are reduced to managing their network equipment with either
`user-unfriendly MIB browsers, or with tailor-made software running on a dedicated PC sitting next to the device.
`Consequently, many markets are closed to such start-ups, which are desperate to get access to integrated network
`management.
`
`The second problem, which concerns customers and vendors alike, is versioning [16]. When upgrading a vendor-specific
`MIB and consequently a vendor-specific management GUI, customers and network equipment vendors want to cope with
`situations where the add-on integrated to the management platform has a different version level from that of the MIB
`supported by the agent. Today, since there is no such a thing as a MIB-discovery protocol, administrators either have to
`manually specify what MIB is supported by what device, which is tedious, or they have to refrain themselves from using
`MIB variables that have changed between the last and the previous MIB versions, which can cause problems.
`
`These last two concerns are again addressed by applets in Web-based management. Applet-based management software
`is embedded in a network device when you buy it, so you can manage your agent at once. When you upgrade the software
`on your agent, you can easily upgrade the management applet as well. And by transferring the management software from
`the agent to the manager, we ensure that the version of the vendor-specific MIB is always the same on both sides.
`
`2.2. Protocol efficiency
`
`Since the outset, SNMP-based network management has been hampered by two protocol engineering decisions which
`drastically reduce its efficiency. First, both SMIv1 [20] for the SNMPv1 framework, and SMIv2 [3] for the SNMPv2 and
`SNMPv3 frameworks, make the use of BER encoding [10] mandatory for SMI MIB data. Unfortunately, this encoding is
`renown for its inefficiency. Mitra [15] and Neufeld and Vuong [17] describe this issue in detail, and show that the amount
`of administrative data (identifier and length) transferred is very large compared to the actual data (content). Since ASN.1
`itself does not mandate the use of any specific encoding rules, other more efficient schemes were defined, such as
`PER [11]. But they did not make their way through to the SNMP frameworks. The second issue is in SNMP itself. SNMP
`varbind lists are relatively expensive, because the OIDs used to name variables usually take much more space than the
`values. Also, the absence of an efficient table retrieval mechanism means that the total protocol efficiency suffers from
`repeated message exchanges (and repeated computations on the agent side).
`
`These issues are addressed in Web-based network management by using HTTP 1.1 instead of SNMP to transfer SMI MIB
`data between managers and agents. The advantages are fourfold. First, this migration makes it possible to abandon BER
`encoding, and to use instead a new MIME content type for SNMP, or simply encode SMI MIB data in HTML [16].
`Second, the use of persistent connections [6], a key feature of HTTP 1.1, alleviates the network overhead and latency
`induced by multiple TCP connection setups and teardowns. Third, pipelining [6], another key feature of HTTP 1.1, allows
`the manager to make multiple requests without waiting for each response. This reduces latency, but also allows a very
`efficient use of TCP connections, when combined with persistent connections: if the time-out value of each persistent
`connection is greater than the polling frequency for that agent, the same TCP connection can be used indefinitely between
`the manager and each agent. Fourth, the network bandwidth usage can be reduced by performing transparent data
`compression. Unlike SNMP, HTTP supports the MIME concepts of content type and content transfer encoding to transfer
`data. Therefore, it is possible to compress the payload of an HTTP packet (say with gzip) on the agent, and uncompress
`it on the manager, without the management application being even aware that data is compressed when it is in transit.
`Because the payload is plain text, the expected compression rate is fairly high.
`
`The only problem not addressed by HTTP is the lack of an efficient table retrieval mechanism. This can be dealt with by
`adding a new primitive to the new MIME content type mentioned above. RMI and Object Serialization offer a neater
`solution, since they replace communication protocols like SNMP or HTTP with direct object-to-object communication.
`SNMP varbind lists are replaced with serialized objects, and the absence of an efficient table retrieval mechanism only
`affects the agent, as we will show further on. But there are also problems with RMI, as we will see in section 4.2.2.
`
`2.3. Security
`
`Security is a weak point of the SNMPv1 and SNMPv2 frameworks [22]. The lack of secure SNMP get’s and set’s has
`hampered the management of remote subsidiaries for many years. With SNMP, how can an enterprise reasonably manage
`a VPN spanning over the Internet or some kind of public network? Things have been significantly improved in this respect
`
`4
`
`Petitioners' Exhibit 1025
`Page 0005
`
`

`

`by the SNMPv3 framework, which was recently released. But field tests still remain to show that administrators are happy
`with this new security framework in deployment. Today, organizations that demand secure communications over public
`WAN links (e.g., banks) generally resort to expensive devices that perform transparent encryption and decryption at low
`protocol layers, at the boundaries of the WAN links. Whether the data is SNMP or else, it is always encrypted.
`
`Thanks to SSL [23], HTTP has proved superior to SNMP, with respect to security, for several years. SSL is a security
`protocol which sits between the transport-layer protocol (TCP) and the application-layer protocol (HTTP), and prevents
`eavesdropping, tampering and message forgery. When a URL starts with (i.e., has an RFC-1738 scheme name equals to)
`https, the HTTP client connects to port 443/tcp [9] on the server, instead of the standard HTTP port 80/tcp [9];
`then HTTP traffic is sent over SSL. Like in network management, much work is being done at IETF and W3C on Web
`security. This includes the successor of SSL, TLS [5], over which HTTP can be layered [18], but also the support for
`strongly secure electronic transactions, and the integration of strong authentication and privacy schemes in HTTP.
`
`2.4. Transport protocol: TCP vs. UDP
`
`The idea of using HTTP instead of SNMP is very intuitive: they are both request/response protocols, implemented with
`client/server technology, and an SNMP get or set can be mapped nicely to an HTTP get or post. But the fact that
`these communication protocols rely on different transport protocols immediately raises the question: Should management
`data be transported over a reliable protocol such as TCP, or an unreliable protocol like UDP? This issue has been debated
`for years. People often have strong opinions about it. Rose, one of the designers of SNMP, is fiercely opposed to using a
`reliable transport protocol [19]. Wellens and Auerbach, conversely, denounce what they call the myth of the collapsing
`backbone [25]. Their analysis takes into account the fact that in 1996, HTTP 1.0 was suffering from the lack of persistent
`connections, so the use of TCP connections for each SNMP get entailed a significant overhead and latency. As we know,
`HTTP 1.1 addresses that, which gives today even more power to their argument.
`
`We believe that network administrators should have the choice. Not only should the selection of the transport protocol be
`customizable at the enterprise level, but it should also be at the network device level, and possibly even at the MIB variable
`level. Unfortunately, today, there is no such choice: everyone uses SNMP over UDP, although nothing prevents the use
`of SNMP over TCP. Based on our professional experience, we can state that there are settings where management data is
`more important than user data. In these cases, since management data traffic and user traffic share the same medium in
`the IP world, management data should either be allocated a certain (low) proportion of the link capacity (a feature already
`offered by some equipment vendors), or given a higher priority in routers (a feature hardly ever used today, but which may
`become common in the near future with the increase of real-time multimedia traffic). Clearly, it is the duty of the adminis-
`trator to ensure that the proportion of the management data remains low compared to the link capacity, since the raison
`d’être of networks is to carry user data, not management data! Unlike WAN links, most intranets are oversized, and losses
`are rarely due to ongoing network saturation. They are rather due to mundane reasons such as Ethernet collisions, or
`temporary buffer overflow in a router in case of bursty traffic. Thus, in our view, in such networks, management data
`should be transported with a reliable protocol. Conversely, for backbone routers with impressive MTBFs, or for expensive
`intercontinental WAN links, management data is generally far less important than user traffic; in these cases, management
`data should be carried over an unreliable transport protocol such as UDP.
`
`Above, when we said “management data”, we meant data collection and network monitoring. SNMP notifications are a
`different case altogether. They are only sent in case of major problems. Because the definition of what is a major problem
`is site specific, most if not all network devices allow administrators to filter what notifications should or should not be
`sent to the NMS. Unfortunately, with the current SNMP technology, these notifications are also sent over an unreliable
`transport protocol. In our view, they should instead be given the highest possible priority. If an interface goes down in a
`backbone router, it is more important that the router reports this event back to the NMS immediately, than to actually route
`user traffic on the alternate path. Using UDP instead of TCP means that this important packet may be lost for a silly reason
`like a mere Ethernet collision on the NMS local network segment. Although TCP does not guarantee the delivery of
`packets, at least it supports automatic retransmissions and acknowledgments. UDP does not, and places the burden of
`retransmitting lost datagrams on the management application, making it unnecessarily complex.
`
`In summary, data collection and network monitoring may use reliable or unreliable transport protocols, depending on the
`site-specific needs. TCP-based network management is probably a bad idea for heavily-used backbone routers, which are
`used flat out, need to work 24x24 and 7x7, and rarely experience any problems. But it seems well suited to intranets,
`especially for SMEs with small or medium-sized networks. As for notification delivery, TCP is probably better than UDP,
`because major problems really ought to be reported to the NMS over a reliable transport protocol, to maximize the chances
`of the notification arriving at destination.
`
`5
`
`Petitioners' Exhibit 1025
`Page 0006
`
`

`

`An important side-effect of selecting UDP or TCP as a transport protocol is the issue of firewalls. More and more organi-
`zations protect their internal network from Internet intruders by setting up firewalls. In the commercial world, firewalls
`are expected to become ubiquitous in the near future. Most firewalls are setup to let HTTP traffic go through, because of
`the Web, and to filter out UDP traffic, because it can be the vehicle of well-known attacks [4]. This is a problem for
`companies that need to manage remote offices via WAN links. Some firewall systems support UDP relays, that
`dynamically learn about UDP traffic, and try to work out whether a measured pattern looks like an attack or normal usage.
`Such relays require ad hoc configuration of the firewall. Whether security or network administrators are willing to open
`up (even partially) external access to an internal NMS is primarily a matter of security policy, and is therefore site specific.
`But many may not want to, especially SMEs with remote offices that do not have in-house expertise regarding firewalls.
`For such companies, the use of TCP as a transport protocol may be the best option when they decide to protect themselves
`behind a firewall.
`
`3. The Pull Model
`
`In section 3.1, we first explain how the pull and push models work. In section 3.2, we then present the engineering details
`of pull-based ad hoc management, and show how Web technologies can complement the management functionalities
`offered by the NMS. In this case, network troubleshooting can be done from any machine running a Web browser, whereas
`the NMS remains in charge of regular management. Finally, in section 3.3, we show that Web technologies can also deal
`with regular management, and make the network management platform redundant for troubleshooting and data collection.
`
`3.1. Pull vs. Push: the newspaper metaphor
`
`In software engineering, the pull model and the push model designate two well-known approaches for exchanging data
`between two distant entities. The newspaper metaphor is a simple illustration of these models: if you want to read your
`favorite newspaper everyday, you can either go and buy it every morning, or subscribe to it once and then receive it
`automatically at home. The former is an example of pull, the latter of push. The pull model is based on the request/response
`paradigm (called data polling, or simply polling, in traditional SNMP-based network management); the client sends a
`request to the server, then the server answers, either synchronously or asynchronously. This is functionally equivalent to
`the client “pulling” the data off the server. In this approach, the data transfer is always initiated by the client, i.e. the
`manager. The push model, conversely, is based on the publish/subscribe/distribute paradigm. In this model, agents first
`advertise what MIBs they support, and what SNMP notifications they can send; the administrator then subscribes the
`manager (the NMS) to the data he/she is interested in, specifies how often the manager should receive this data, and
`disconnects. Later on, each agent individually takes the initiative to “push” data to the manager, either on a regular basis
`via a scheduler (e.g., for network monitoring) or asynchronously (e.g., to send SNMP notifications).
`
`3.2. Ad Hoc Management
`
`The simplest and most intuitive application of the applet technology is ad hoc management. In this section, we sum up the
`specificities of ad hoc and regular management, then come back to Wellens and Auerbach’s model and study its
`engineering details; we show that generic GUIs can similarly be coded as applets, and conclude with a figure illustrating
`how ad hoc management can rely entirely on Web technologies.
`
`3.2.1. Ad hoc management vs. regular management
`
`When they described the embedded management application approach, Wellens and Auerbach had ad hoc management
`in mind. Ad hoc management is always manual, and requires a user (administrator or operator) to interact with the
`management software via some GUIs. It is typical of transient tasks: you connect to a network device, retrieve some data
`to check something, and disconnect shortly after. Regular management, conversely, is concerned with ongoing data
`collection, network monitoring and event handling. It is automated to a large extent, and generally runs continuously.
`
`Ad hoc management takes place in virtually all companies. In large organizations that can afford staff dedicated to
`monitoring the network (operators), or that rely on entirely automated regular management, ad hoc management is
`complementary to regular management. For instance, an administrator may occasionally want to pop up a GUI to
`configure a router, or an operator may take a look at a time series of error rates while investigating a network problem.
`Conversely, in smaller organizations such as SMEs, ad hoc management generally replaces regular management. There
`is no operator and no dedicated NMS: the management software is only used occasionally, on an ad hoc basis. Ad hoc
`
`6
`
`Petitioners' Exhibit 1025
`Page 0007
`
`

`

`management typically consists in troublesho