SpeLi4RE.D ChicoCA85827aYvared.com
`
`
`
`
`
`42456“1
`
`Lofl
`
`DOCUMENTS|7.0. sox 3506 Document #
`
`
`
`
`
`e For more informaticr please visit: www.documertsdelivered.ccm/copyright-policy/
`
`[Name|Order ID |Service|Order Date Client Reference | Billing Number
`
`
`
`Lisa MacDonald
`42456
`05.16.2017 5:33 am
`309101-2130-12110
`ASAP Order
`
`Document Details
`
`Source : Integrated Network Management, 1999. Distributed Managementfor the Networked Millennium. Proceedings of the Sixth
`IFIP/IEEE International Symposium on
`
`Volurre :
`
`Issue:
`
`Date: 1999
`
`Pages: 3-18
`
`Author: Martin-Flatin, Jean-Philippe
`
`Title : Push vs. pull in web-based network management.
`
`Order Options
`
`“Title Page ifAvailable MDatestamp
`
`CEnglish Only
`
`™M Table of Contents if
`Available
`
`OColorif
`Available
`
`OExtra Clean
`
`M Copyright Pageif
`Available
`
`(Hardcopy
`Only
`
`OJInclude Suppl, Material if Available
`
`U Digital Only
`
`CJHTML/Text
`OK
`
`Notes
`“<cover, title page, copyright, date stamp (before Noverrber 2002), library/institution
`stamp, TOC, and article***
`
`e Documents Delivered is a mernber of the Copyright Clearance Center and adheres to copyright law.
`
`Copyright Policy | FAQ y Help | Privacy Policy
`
`Facebook's Exhibit No. 1009/1109
`Page 1
`
`Facebook's Exhibit No. 1009/1109
`Page 1
`
`

`

`
`
`Pijeliiivad|alsells
`
`
`
`‘URULO[SSTO]
`
`
`
`ndn-][rqpue
`
`Slomar
`Mazumd
`
`oN m
`
`A
`
`|
`
`
`
`Facebook's Exhibit No. 1009/1109
`Page 2
`
`memSraof})sun
`
`pate
`
`
`
`ay)Buyyomjay
`
`EEE||SS3YDNOO40AMVHENT
`
`Facebook's Exhibit No. 1009/1109
`Page 2
`
`

`

`Page 3
`
`Facebook's Exhibit No. 1009/1109
`
`Facebook's Exhibit No. 1009/1109
`Page 3
`
`

`

` \
`
`fev
`
`tS try
`errr
`=
`i
`{ TA :
`
`“
`
`Integrated Networ
`ManagementVI
`
`| Oa on
`
`DISTRIBUTED MANAGEMENT FOR THE
`NETWORKED MILLENNIUM
`
`Proceedingsof the Sixth IFIP/IEEE
`International Symposium on Integrated
`Network Management
`Boston, MA, U.S.A., 24 - 28 May 1999
`Sponsored by: IEEE Communications Society
`Co-sponsored by IFIP TC6 WG6 on Network Management
`
`Edited by
`Morris Sloman
`Department of Computing,
`Imperial College ofScience, Technology and Medicine
`London, UK
`
`Subrata Mazumdar
`Bell Laboratories
`Lucent Technologies
`Holmdel, New Jersey, USA
`
`and
`
`Emil Lupu
`Department of Computing
`Imperial College of Science, Technology and Medicine
`London, UK
`
`Published by IEEE Publishing
`
`g
`
`lIEEE
`‘Networking the Word™
`
`Pid
`
`————SS
`
`SSEa
`==a——e=a
`==
`IFIP —-
`IEEE
`COMMUNICATIONS
`SOCIETY
`
`4
`
`Facebook's Exhibit No. 1009/1109
`Page 4
`
`Facebook's Exhibit No. 1009/1109
`Page 4
`
`

`

`
`
`Facebook's Exhibit No. 1009/1109
`Page 5
`
`i|i :
`
`Facebook's Exhibit No. 1009/1109
`Page 5
`
`

`

`Pushvs. Pull in Web-Based Network
`Management
`
`J.P. Martin-Flatin
`Swiss Federal Institute of Technology, Lausanne (EPFL)
`Institute for computer Communications and Applications (ICA)
`1015 Lausanne, Switzerland
`martin-flatin@ epfl.ch
`
`Abstract
`In this paper, we build on the concept of embedded management application,
`proposed by Wellens and Auerbach, and present
`two models of network
`managementapplication designsthat rely on Web technologies. First, the pull model,
`based on the request/response paradigm, is a generalization of data polling in the
`SNMP managementframework. We explain how to use it for ad hoc management
`(e.g, troubleshooting) and regular management(e.g., network monitoring). Second,
`the push model is a novel approachthat relies on the publish/subscribe/distribute
`paradigm.It is better suited to regular managementthan the pull model, and allows
`administrators to conserve network bandwidth as well as CPU time on the
`managementstation.
`
`Keywords
`Web-Based Management, Network Management, IP Networks, Push Model,‘Pull
`Model, Java, Embedded Management Application.
`1. Introduction
`
`The idea of using- Web technologies in IP network management is not new.
`Experiments with the early Web technologies (Web browsers, HTTP, HTML and
`CGIscripts) started in 1993-94. Initially, they were only confined to secondary
`tasks [4]. The first important step toward Web-based network management was
`taken when vendors began embedding HTTP serversin their network equipment.
`Bruins [1] reports some early experiments made by Cisco in 1995, whereby the
`entire command line interface was mapped to URLs. This opened new doors for
`configuration management and symptom-driven HTMLforms,as there was no more
`need to telnet into network devices. Mullaney [7] also describes some work
`conducted by FIP Software, whereby agents send static or dynamic HTML pages
`back to the Network ManagementStation (NMS)in response to an HTTP get or
`post request. Many network equipment vendors,including Cisco, Nortel Networks
`and 3Com, now routinely embed HTTPservers in their new equipment.
`
`Facebook's Exhibit No. 1009/1109
`Page 6
`
`Facebook's Exhibit No. 1009/1109
`Page 6
`
`

`

`4
`
`Web-based Management
`
`The second important step was taken when Java applets appeared in Netscape’s
`famous Web browser, in 1995. The seminal article by Wellens and Auerbach [10]
`introduces the concept of embedded management application, and shows the
`advantages of using HTTP rather than SNMPtovehicle data between managers and
`agents. Although the authors do not explicitly refer to applets in their article, the
`solution they proposeis to transform an add-on(i.e., a vendor-specific management
`GUIthat has to be ported to many different management platforms and operating
`systems) into a single applet that can run anywhere. This applet is stored in the
`managed device, and loaded by the administrator into a Web browser. Communi-
`cation between the appletandits origin agentlater relies on HTTP instead of SNMP.
`
`Since the time of this proposal, new technologies have appeared on the Web. Today,
`in addition to applets and Java applications, we can use Java servlets and Remote
`Method Invocation (RMI), we can open persistent sockets between applets and
`servlets, etc. All these new possibilities enable new designs of network management
`applications. Leveraging on these new technologies, we propose to push Wellens and
`Auerbach’s idea two steps further. In section 2, we show that the design paradigm
`they proposeis just one instance of a more general paradigm, the pull model, which
`can not only be applied to ad hoc management, as they do, but also to regular
`management. In section 3, we introduce a novel approach based on 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, managementdata transfers
`are always initiated by the agent, as SNMP notifications delivery in pre-Web
`network management. The push model reduces network overhead, and movespart
`of the CPU burden from managers to agents.
`
`2. The Pull Model
`
`In sections 2.1 and 2.2, we describe the pull and push models, and explain the
`difference between ad hoc and regular management. In section 2.3, we present the
`engineering details of pull-based ad hoc management, and show how Web
`technologies can complement the managementfunctionalities offered by the NMS.
`In this case, network troubleshooting can be done from any machine running a Web
`browser, whereas the NMSremains in charge of regular management.Finally, in
`section 2.4, we show that Webtechnologiescan also deal with regular management.
`
`2.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 metaphoris a simpleillustration 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 formeris an
`exampleofpull, the latter of push. The pull model is based on the request/response
`paradigm (called data polling, or simply polling,
`in the SNMP management
`
`|
`
`Facebook's Exhibit No. 1009/1109
`Page 7
`
`Facebook's Exhibit No. 1009/1109
`Page 7
`
`

`

`Push vs. Pull in Web-based Network Management
`
`5
`
`framework); 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
`MIBsthey support, and what SNMPnotifications they can generate; the adminis-
`trator then subscribes the manager (the NMS)to the data he/she is interested in,
`specifies how often the managershouldreceive this data, and disconnects. Lateron,
`each agentindividually 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 SNMPnotifications).
`
`2.2. Ad hoc management ys. regular management
`
`The simplest and most intuitive application of the applet technology is ad hoc
`management, which requires a user (administrator or operator) to interact with the
`management software via some GUIs. Ad hoc managementis 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
`whocan afford staff dedicated to monitoring the network (operators), or who rely on
`entirely automated regular management, ad hoc management is complementary to
`regular management. Conversely, in Small and Medium-sized Enterprises (SMEs),
`ad hoc management generally replaces regular management. There is no operator
`and no dedicated NMS: the managementsoftwareis only used occasionally, on an
`ad hoc basis. Ad hoc managementtypically consists in troubleshooting (i.e., a
`network problem just showed up, and the administratortries to identify and fix the
`problemmanually), or configuration management(e.g., the administrator sets up a
`new router, or checksif a router is configured properly).
`2.3. Pull-based ad hoc management
`
`issues in SNMP-based network management[4]. They
`Applets address several
`decrease vendors’ developmentcosts for management GUIs; they addressthe issue
`of having different versions of a vendor-specific MIB in the same network; they cut
`the time-to-market of management GUIs downto Zero; and they are independent of
`the machine where the Web browser runs. Applets can also replace all
`the
`management GUIsthat we find in pre-Web network managementplatforms[6].
`
`Vendor-specific management GUIs codedas applets
`
`the vendor-specific
`In the approach proposed by Wellens and Auerbach,
`management GUI is coded as an applet. They call it the embedded management
`
`Facebook's Exhibit No. 1009/1109
`Page 8
`
`Facebook's Exhibit No. 1009/1109
`Page 8
`
`

`

`6
`
`Web-based Management
`
`application. The uploading of the applet by the Web browseris depicted in Figure 1.
`The HTTPserver running on the agent retrievesits vendor-specific management
`applet from local storage, e.g. from EPROM,andsendsit back to the Web browser.
`Once the applet is uploaded by the Web browser, there are two ways to proceed:
`either use SNMP or HTTP.
`
`If we use SNMP,the interactions between the manager (Web browser running on
`any machine) and the agent (network device) are depicted in Figure 1. Steps 1 and 2
`describe the applet transfer; they occur only once. Steps 3 and 4 describe the
`managementdata transfers; they are an iterative process. The dotted arrow for step 2
`is a visual aid that showsthat the applet is transferred from the agent to the manager.
`In reality, this transfer takes place between the HTTP client of the Web browser and
`the HTTP server of the agent.
`
`Networkdevice Any machine
`
`Webbrowser
`
`Administrator
`or Operator
`
`Figure 1: Pull model: HTTP together with SNMP
`
`Oncethe applet is uploaded, the user has the equivalent of an add-on in a pre-Web
`network managementplatform to interact with. Graphical interactions are translated
`into SNMP commandsbythe applet (e.g., a mouse click on the drawing ofa reset
`button can be mapped to an SNMP set). In other words, wehave a Java API making
`How can weload this SNMPstack into the browser? The simplest proach is to
`
`SNMPcalls underneath.
`
`include an SNMPstack in the applet, as described by Bruins [1], because the applet
`security model prevenis it from retrieving this stack from the localfile system. So
`each time a managementapplet is uploaded from a network device, the entire SNMP
`stack needs to be movedalong. This is clearly inefficient, especially if this transfer
`takes place across a WAN link. An improvementon this is to retrieve the SNMP
`stack separately, via a socket. Because of the applet security model, sockets may
`only be opened between an applet and its origin server, in HTTP parlance; so we
`need a proxy to act as the origin server [4]. The managementappletis first requested
`by the Web browserto the proxy; second, the proxy contacts the network device and
`
`Facebook's Exhibit No. 1009/1109
`Page 9
`
`Facebook's Exhibit No. 1009/1109
`Page 9
`
`

`

`Push vs. Pull in Web-based Network Management
`
`7
`
`retrieves the applet without the SNMPstack; third, the applet is passed alongto the
`Webbrowser which executesit; fourth, the applet opens a socket to the proxy, which
`runsthe server side of the socket; fifth, the SNMPstackis transferred via the socket;
`andsixth the socket is closed. All subsequent SNMPtraffic between the manager and
`the agent is simply relayed “as is” by the proxy.
`
`This approach worksfine; it is of limited interest though, because we do not benefit
`from the advantages of using HTTP instead of SNMP [4]: reduced network
`overhead, improved security, etc. So let us now study the case when the recurrent
`steps 3 and 4 are based on HTTPrather than SNMP(see Figure 2). This time, there
`is no need for an SNMPclient in the Web browser, thus no need for a proxy.
`
`Vendor-specific
`GUI(applet)
`
`Networkdevice
`
`ws
`Administrator
`
`Network
`map GUI
`
`Any machine
`
`Figure 2: Pull model: HTTP instead of SNMP
`
`When a MIB variable is requested by the applet, the request is made to the HTTP
`server run by the agent. The HTTP server then launches an HTTP-to-SNMPgateway
`to access the local MIB. The gateway can be a CGI script, a Java servlet, etc.
`Depending on the degree of optimization of the code run by the agent, the gateway
`can either directly access the MIB datastructures in memory,or do an explicit SNMP
`get or set. This gives a useful migration path to network equipment vendors.
`
`Generic management GUIs codedas applets
`
`So far, we followed the original idea of Wellens and Auerbach: only vendor-specific
`management GUIs are coded as applets. The next step is to code generic GUIs as
`applets, too. (A generic GUI supports a generic vendor-independent MIB such as
`MIB-II, the RMON MIBor the ATM MIB [6].) At this point, ad hoc management
`relies entirely on Web technologies (see Figure3).
`
`The Webserver can be any machineon the Internetor the intranet; for robustness,it
`Should clearly be attached to the intranet. The “MIBs” icon in the network device
`representsall the generic MIBs supported by theagent, plus its vendor-specific MIB.
`
`
`
`Facebook's Exhibit No. 1009/1109
`Page 10
`
`Facebook's Exhibit No. 1009/1109
`Page 10
`
`

`

`Web-based Management
`
`HTTP/SNMP
`gateway
`
`Network device
`
`/ Any machine
`
`(intranet or Internet)
`
`, aG
`
`eneric GUI
`(applet)
`
`.
`
`WWWserver
`
`Figure 3: Pull model: ad hoc management based on HTTP
`
`In this section, we showed that SMEsthat only rely on ad hoc managementfor their
`network equipment can save the cost of a network managementplatform by using
`Web technologies instead. Thus, depending on the pricing policy of network
`equipment vendors,
`the move
`from SNMP-based to Web-based network
`management can completely reshape the SMEs segmentof this market.
`
`2.4. Regular management
`
`In addition to ad hoc management, many organizations need to perform regular
`management. For them, network management must be automated to a large extent,
`including data polling and event handling which are not dealt with by the solutions
`wepresented so far. Let us concentrate on data polling in this section. Let us suppose
`we have two separate management platforms, side by side: one for regular
`management, based on SNMP, and one for ad hoc management, based on Web
`technologies. Let us now describe, step by step, how to integrate them.
`
`—
`
`Facebook's Exhibit No. 1009/1109
`Page 11
`
`Facebook's Exhibit No. 1009/1109
`Page 11
`
`

`

`Push vs. Pull in Web-based Network Management
`
`9
`
`Vendor-specific
`GUIs (applets)
`
`Ad»
`
`a
`
`Management
`software
`repository
`
`GUI
`applet)
`
`:
`
`f
`
`WWWserver
`\ (intranet or Internet)
`
`glue WWWserver
`
`Administrator
`or Operator
`
`7 pac
`mA\
`client
`
`definition
`
`scheduler
`
`purpose data
`repository
`
`Firewall
`
`SNMP
`trapclient
`
`Network
`device
`
`handler
`
`(intranetor Internet)
`
`Figure 4: Pull model: data polling based on HTTP
`
`The first step is to integrate a Web browser in the network managementplatform,in
`order to have a unified interface for ad hoc and regular management. This feature is
`now offered by some commercial network managementplatforms. The network map
`GUlis an appletthat is uploaded by the Web browser.It can be updated dynamically
`
`Facebook's Exhibit No. 1009/1109
`Page 12
`
`Facebook's Exhibit No. 1009/1109
`Page 12
`
`

`

`10
`
`Web-based Management
`
`by the eventcorrelator, with icons turning red, green, etc. An easy wayto update this
`map would beto open a socketdirectly between the applet and the eventcorrelator.
`But we do not necessarily want to have a network map GUI: regular management can
`rely entirely on event handlers, when it runs in unattended mode.In suchacase, the
`administrator is automatically paged, mailed or telephoned when a serious problem
`is detected. To cope with this case, we add an intermediary, the network map
`registry, between the network map GUI(s) and the event correlator. Thus, we can
`have zero, one or several network map GUIsregistered independently.
`
`The applet security model mandatesthat the applet be downloaded from the machine
`with the server side of the socket. So the WWW serverat the bottom of Figure 4 and
`the WWWserverat the top right are actually the same machine. They are represented
`separately to avoid too many overlapping arrows.
`
`The secondstep is to replace all the GUIs of the network managementplatform [6]
`with applets. The vendor-specific appletis still loaded from the network device. All
`other GUIs are retrieved from the management software repository; the WWW
`server must then act as a proxy because of the applet security model.
`
`Thethird step is to make the data repository independentof the network management
`platform. We assumeherethat data is stored in a third-party RDBMS; note that we
`may as well use a plain text file system, or an object-oriented database. The data
`repository resides on a machine that wecall the data server, which can be any
`machine of the intranet. To store or retrieve data, we use JDBC. In order to make
`Figure 4 easier to read, we assumethat we havea single data repository for polling
`and report definitions and schedules; but this is not mandatory.
`
`The fourth step is to implement data polling with HTTP. This is achieved by a
`servlet. Upon start-up,
`the polling engine retrieves all polling definitions and
`schedules from the RDBMS. The scheduler makesit poll all agents on a regular
`basis. The data retrieved for network monitoring is checked by the polling data
`interpreter, which may generate an eventin case a problemis inferred. This eventis
`then dispatched to the event correlator, which can decide to update the network
`map(s). The communication between the managerand the agent is based on ATTP.
`Thefifth step is to migrate reports generation to Web technologies. This is doneiby
`another servlet, which accesses the data repository via JDBC. This data is stored by
`the polling servlet, and is accessed independently by the report generator. For the
`sake of simplicity, we pictured the two servlets, report generation and data polling,
`as running on the same machine;butthis does not haveto be the case.
`
`this stage, data collection and network monitoring rely entirely on Web
`At
`technologies. They no longer require an expensive NMS, dedicated to network
`management. SNMPnotifications delivery and event handlersare the only tasksstill
`performedin the traditional way.
`
`Facebook's Exhibit No. 1009/1109
`Page 13
`
`Facebook's Exhibit No. 1009/1109
`Page 13
`
`

`

`Push vs. Pull in Web-based Network Management
`
`11
`
`3. The Push Model
`
`The push model generalizes to network monitoring and data collection the way
`SNMPnotifications are delivered today. Despite its large success in software
`engineering,
`it has always been confined to SNMP notification delivery in IP
`network management. To the best of our knowledge, no network management
`platform usesit today for network monitoring or data collection. Yet, we claim that
`its very design makesit better suited to regular managementthan the pull model.
`
`The chief advantages of using the push model are to conserve network bandwidth
`and movepart of the CPU burden from managers to agents. Much of the network
`overhead caused by the pull model is due to the fact that there is a lot of redundancy
`in what the manager keeps askingall agents at every polling cycle for data collection
`and network monitoring. With the push model, the manager contacts each agent
`once, subscribes to an OID once (push data definition), and specifies at what
`frequency (push frequency) the agent should send the value of this OID (push data
`schedule). Afterward, there is no more traffic going from the managerto the agent
`(except in the rare cases when the manager wishes to changeits subscription). The
`agent “remembers” what the manager subscribed to by keeping the push definitions
`and schedules on local storage; if this is EPROM,the agent can retrieve these
`definitions and schedules by itself after a reboot; if this is RAM,it needsto retrieve
`them from the manager, which stores them in the data server.
`
`The point of moving part of the CPU burden from managersto agents is to decrease
`the requirements put on NMSsin terms of CPU and memory. Network management
`platformsfor large networks are often big Unix or Windows NTservers, which cost
`a fortune to buy and maintain. Agents, on the other hand, are more powerful than
`they used to be, and many of them can reasonably doa bit of processing locally (see
`the rationale behind Goldszmidt’s Management by Delegation scheme [3], or
`Wellens and Auerbach’s myth of the dumb agent[10]).
`
`Compared to the pull model, the push model introduces a new issue: synchroni-
`zation. If the manager and the agent have internal clocks that do not synchronize
`regularly,
`they will probably drift apart. This is not a problem for network
`monitoring, but it can be for data collection [4]. For push technologies to work,it is
`therefore recommendedto synchronizethe clocks of network equipment on a regular
`basis, e.g. with NTP. Let us now delveinto the engineering details of the push model.
`
`3.1. Publication and subscription phases
`
`In the first phase, the network device (agent) publishes what MIBsit supports, and
`what SNMPnotifications it can send to the manager. A simple way to implementthis
`is to use applets, as depicted in Figure 5. First, the user selects an agent on the
`network map applet, and loads from that agent a well-known HTMLpage,e.g.
`<http://agent.domain/mgmt/mibs.html>, whichlists the applets stored on the agent.
`
`Facebook's Exhibit No. 1009/1109
`Page 14
`
`Facebook's Exhibit No. 1009/1109
`Page 14
`
`

`

`12
`
`Web-based Management
`
`Every applet publishes one MIB (vendor-specific or generic) supported by the agent,
`except one, which publishes the SNMPnotifications supported by this agent.
`
`In the second phase, the administrator subscribes the manager to MIB variables and
`SNMPnotifications. MIB data subscription applets allow him/her to select MIB
`variables as well as push frequencies. The push frequency can be specified at the
`MIBvariable level: it need not be the same forall variables of a given MIB. The push
`frequency is equal to the polling frequency considered in section 2. Obviously, the
`notification subscription applet does not have to specify a push frequency, as notifi-
`cationsare inherently asynchronous. In fact, the notification subscription applet is
`simply a filter: it specifies what notifications the manageris interested in. Other
`notifications are discarded by the agent.
`
`Network
`map GUI
`(applet)
`
`TS
`Push
`Push definitions
`scheduler
`and schedules
`serviet
`repository
`A/Notification
`subscription
`GUI(applet)
`
`~
`sa
`Administrator
`or Operator
`
`WY
`
`subscription
`GUI(applet)
`
`JDBC
`client
`
`Network map
`GUI (applet)
`
`WWWserver
`(intranet or Internet)
`
`Push
`definition
`servlet
`
`MIB data
`subscription GUI
`(applet)
`
`Notification
`subscription
`GUI(applet)
`Network
`“
`
`device
`
`Any machine
`
`General
`purpose data
`Tepository
`
`Figure 5: Push model: publication and subscription phases
`
`The publication and subscription phases are depicted in Figure 5. The details of the
`MIB and notification subscriptions are stored in the data server. In case an agent
`loses all
`its push configuration data, this allows the manager to resend all
`the
`definitions and schedules for that agent in unattended mode: the administrator does
`not have to enter it all over again manually, via a GUI. The general purpose data
`repository of the data server includes (i) the definitions and schedules of the MIB
`data subscribed to by the manager,(ii) the definitions of the notifications subscribed
`to by the manager,and(iii) the network topology definition used by the network map
`
`Facebook's Exhibit No. 1009/1109
`Page 15
`
`Facebook's Exhibit No. 1009/1109
`Page 15
`
`

`

`Push vs, Pull in Web-based Network Management
`
`13
`
`applet to construct its GUI. In reallife, these three logical data repositories may
`actually be stored into different databases, or a single database.
`
`3.2. Distribution phase
`
`In the distribution phase, the case of data collection and network monitoring is only
`marginally different from the case of notification delivery and event handling. In
`order to facilitate the comparison with the pull model, we will concentrate on data
`collection and network monitoring in this paper, that is, how to replace data polling
`‘with push technologies. Notification delivery and event handling are presented in
`" detail in [5]. Let us stress that the solutions we will describe below apply equally
`well to both cases: the communication issues between the agent and the managerare
`the same, only the servlets running on the managerside are different.
`
`General
`purpose data
`repository
`
`Data server
`
`Administrator
`or Operator
`
`Firewall
`
`:
`
`Administrator
`
`dat
`collector
`a
`
`MIBdata
`dispatcher
`
`Network
`device
`
`Figure 6: Push model: distribution phase
`
`The general purpose data repository depicted in Figure 6 includes seven different
`repositories: the three listed in section 3.1, plus (iv) the event handler definitions
`repository, (v) the event handlers invocationlog, (vi) the pushed data repository, and
`
`Facebook's Exhibit No. 1009/1109
`Page 16
`
`Facebook's Exhibit No. 1009/1109
`Page 16
`
`

`

`14
`
`Web-based Management
`
`these logically
`‘(vii) the pushed notifications repository. Again, in real life, all
`different data repositories may actually reside in one or more databases.
`
`Compared to Figure 4 (pull model), we no longer have a polling engine; instead, we
`have a pushed data collector, which receives the data necessary to monitor the
`network or build usage statistics reports. This data is stored on the data server via
`JDBC. Since the execution speed of Java code is slow, it may be a good idea to
`increase the performancebystoring data in bulk. As the polling engine in the pull
`model, the pushed data collector sends data collected for network monitoring to the
`pushed data interpreter. If an abnormal condition is detected by the pushed data
`interpreter, e.g. a device no longer sends any data, an alarm is generated in the form
`of an eventsentto the event correlator. The event correlator also receives events in
`the form of notifications (not shown here), and identifies the problem with the
`network,It can invoke an event handler, when an eventis not masked by another, in
`which case the call to the event handler is logged in the data server.
`
`The main difficulty when going from pull to push is that the data transfer is now
`initiated by the agent, instead of the manager, while the client remains on the
`managerside, and the server on the agent side. Somehow,the client and the server
`are on the wrong sides! We would like the server to initiate the communication,
`whereas communication is always initiated by the client
`in a client/server
`architecture. To addressthis issue, we have the choice between three communication
`technologies: HTTP, sockets and RMI [9].
`
`Sockets
`
`Firewall
`
`Push definitions
`and schedules
`repository
`
`device
`
`collector
`
`Any machine
`
`ane
`
`Network
`
`Figure 7: Push model: distribution via sockets
`
`that sockets are bidirectional solves the problem of server-initiated
`The fact
`‘communication: we can open a socket as usual, from the client to the server, and,
`later on, only use it to send MIB data from the socketserver to the socket client. To
`ensure that this connection remains persistent, the pushed data collector, on the
`managerside, sets an infinite time-out value on the socket whenit creates it. If the
`underlying TCP connection times out for whatever reason,it is the responsibility of
`the manager (pusheddata collector) to open a new socketto the agent.
`
`Facebook's Exhibit No. 1009/1109
`Page 17
`
`Facebook's Exhibit No. 1009/1109
`Page 17
`
`

`

`Push vs. Pull in Web-based Network Management
`
`15
`
`This socket-based solution presents a big advantage: simplicity. Sockets are very
`simple to program,especially in Java, But it also presents two potential drawbacks.
`First, if the underlying operating system of either the manager or the agent keeps
`timing out the connection (e.g., because the administrator has no control over the
`time-out value of the socket, and this time-out value happens to be lower than the
`push frequency), then this solutionis clearly inappropriate. Not only do the repeated
`socket creations and time-outs cause network and CPU overhead, but even worse, we
`cannottakethe risk to makenotifications delivery depend on suchaversatile type of
`persistent connection; there must be a wayfor the agent, not the manager,to create
`anew connectionif the previous timed out. Second,if we need to go acrossa firewall
`between the manager and the agent, there is a potential issue with sockets. Most
`firewalls filter out UDP, and let only a few TCPports go through [2]. So whether we
`use TCP or UDP sockets, firewalls will generally not let sockets go through by
`default. Thus, in order for this socket-based solution to work, the firewall system
`needs to be modified. This may not be a problem for large organizations, because
`they either have in-house expertise in firewalls to set up UDPrelays or change TCP
`filtering rules, or they can afford expensive external consultants to do the job. Butit
`may well be a problem for SMEs, who generally lack this kind of expertise, and for
`whom expensive external consultants may notbe an option.
`
`RMI
`
`t! F
`
`igure 8: Push model: distribution via RMI
`
`Just like sockets, RMI offers a bidirectional association: once an RMIclient has
`bound to an RMIserver, both of them can senddata to the other. RMIis an elegant
`solution in terms of design, because it gives a fully object-oriented view of network
`management. It offers semantics to the network management application designer
`that are higher than mere MIB variables, and makesit easier to design complex
`applications. But RMIalso presents several drawbacks.First, it requires a full JVM
`to be embeddedin all agents (as opposed to a light-weight JVM such as the one
`included in the EmbeddedJava platform [10]). Very few network devices offer this
`feature today. And manywill not have a full JVM for some time, becauseof the large
`footprint of this software on bottom-of-the-range devices that are very price
`sensitive. Second, current RMI implementationsare very slow, and use many CPU
`
`Facebook's Exhibit No. 1009/1109
`Page 18
`
`.
`Push definitions
`and schedules
`repository
`
`Push
`
`MIBdata
`
`dispatcher
`
`Network
`device
`
`Java
`appl.
`
`(et)
`
`Firewall
`a
`
`II
`
`collector
`
`Any machine
`
`Facebook's Exhibit No. 1009/1109
`Page 18
`
`

`

`16
`
`Web-based Management
`
`and memory resources; today, RMI-based network management is not scalable.
`Third, RMI communication is actually based on sockets, which are transparent to
`applications; so once again, we