SNMP F O R M O B I L E C O M P U T I N G by Qing Vincent Yin B.S., the University of Manitoba, 1994 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Science in THE FACULTY OF GRADUATE STUDIES (Department of Computer Science) We accept this thesis as conforming to the required standard The University of British Columbia January 1999 © Qing Vincent Yin, 1999 In presenting this thesis I partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Computer Science Department The University of British Columbia 2366 Main Mall Vancouver, BC Canada V6T 1Z4 Abstract Mobile computing is a popular subject in today's research. For a mobile environment to have industrial strength, it is essential that the system can be managed remotely in a standard way. The standard for today's network management is the Simple Network Management Protocol (SNMP.) In this thesis, we implement SNMP for two mobile environments: the traditional Mobile IP at the network/transport layer, and the Universal Personal Computing (UPC) at the session layer. We discuss the different approaches of implementation. UPC is a new concept of mobile computing developed by the IWLN project at UBC. We also implement the User Home Agent (UHA) which is the server in the UPC architecture. We also examine a new method of bridging between SNMP and CORBA, and we implement a prototype of an agent-side SNMP/CORBA gateway. The implementation on SNMP over CORBA is new in the academic community. Ideas for future research are also presented, including the implementation of a CORBA/SNMP gateway. ii Table of Contents Abstract •• List of Tables. v List of Figures • vi Acknowledgments vii Chapter 1 Introduction 1 1.1 The Idea 1 1.2 Thesis Objective and Contribution 1 1.3 Thesis Organization 2 Chapter 2 Background Knowledge 3 2.1 SNMP 3 2.1.1 Management Information Base (MLB) 3 2.1.2 The s c o t t y Package 4 2.1.3 Advent A g e n t B u i l d e r 5 2.2 Mobile IP 5 2.3 CORBA 6 2.4 SNMP Over CORBA 7 2.5 Related Work 8 2.5.1 Subrata Mazumdar: SNMP/CORBA Gateway Proposal 9 2.5.2 BelaBan: Multi-domain Management Proposal 10 2.5.3 OrbyCom O p e n S N M P : an upcoming CORBA SNMP Manager 10 2.5.4 CMU-SNMP Package: Classic Choice for C Language 11 2.5.5 UCD-SNMP Package: Another Choice for C Language 11 2.5.6 OutBack j SNMP: Java API for SNMP Manager 12 Chapter 3 Implement SNMP for Mobile IP 13 3.1 The MIB: RFC2006 13 3.2 Implementing SNMP Through a Scotty Agent 14 3.2.1 File Format...: : 14 3.2.2 SNMP for Foreign Agent 14 3.2.3 The SNMP agent in s c o t t y 15 3.3 Performance Consideration 16 3.3.1 Mobile IP Program 16 3.3.2 File Size and Concurrent Access of i w i n _ s n m p . d a t . . . . . 16 3.3.3 Scotty scripts 17 Chapter 4 Implement Universal Personal Computing Over CORBA 19 4.1 UPC Architecture -19 4.1.1 PCE Structure 20 4.1.2 Use Naming Service to Locate UHA 20 4.1.3 Event Sequence 21 4.2 Designing the IDL 22 4.3 Implementing the User Home Agent 25 iii 4.3.1 Data Structure 25 4.3.2 Functional Specification 26 4.4 How CORBAservices Affect the UPC Design and Implementation. 26 4.4.1 Naming Service 26 4.4.2 Security Service 27 4.4.3 Transaction Service 28 4.4.4 Trader Service 28 4.4.5 Persistence Service 29 Chapter 5 Implement SNMP for Universal Personal Computing 30 5.1 Defining the Enterprise UPC-MIB 30 5.1.1 Highlights of UPC-MIB 31 5.1.2 Comparison with MIP-MIB 32 5.2 MIB to IDL Translation 33 5.2.1 Joint Inter-domain Management (XoJIDM) Standard..". 34 5.2.2 Object Management Group (OMG) Standard 35 5.2.3 Translation from UPC-MIB to IDL 35 5.3 Implementing the SNMP Part of the IDL 37 5.4 Implementing an Ad-hoc Agent-side SNMP/CORBA Gateway 37 5.4.1 Advent AgentBuilder: Toolkit for Building SNMP Agent 38 5.4.2 Implementing the Missing Piece of the Bridge 38 5.4.3 The Class Constructor 38 5.4.4 How the Gateway Works 39 5.4.5 Implementing the Tree Traversal 40 5.5 How SNMP Affects the UPC Design and Implementation 41 Chapter 6 Comparison of SNMP Implementations 43 6.1 Instrumenting a MIB in the Traditional Way: Library Code 43 6.2 Instrumenting the MIB for Mobile IP: A Separate Agent 44 6.2.1 Communicate Through a File 44 6.2.2 Pros and Cons r. 45 6.3 Instrumenting a MIB in CORBA: Gateway Approach 45 6.3.1 Bi-directional Communication 46 6.3.2 Lack of Availability 46 6.3.3 Simplicity 46 6.3.4 Location Transparency 47 Chapter 7 Conclusion and Future Work 48 7.1 Thesis Summary 48 7.2 Future Work 48 Bibliography 53 Appendices 56 Appendix A Old PCE-UA.IDL 56 Appendix B New PCE-UA.IDL 58 Appendix C UPC-MIB - Enterprise MIB for UPC 60 Appendix D UserAgentSNMP.Java - the SNMP/CORBA Gateway 65 Appendix E agent.tcl - scotty script for SNMP for Mobile IP 69 iv List of Tables Table 5-1 Tree Walk of uhaSessionTable 32 Table 5-2 Comparison of UPC-MTB and M1P-MIB 33 v List of Figures Figure 2-1 Mobile IP Illustration 6 Figure 2-2 OrbyCom SNMP/CORBA Gateway 11 Figure 3-1 MIB for Mobile IP 13 Figure 3-2 SNMP Agent in Scotty 16 Figure 4-1 Universal Computing Concept 20 Figure 4-2 Naming Context Hierarchy 20 Figure 5-1 Agent-side SNMP-CORBA Gateway 30 Figure 5-2 UPC-MIB 31 Figure 5-3 uhaSessionTable in UPC-MIB 34 vi Acknowledgments Fd like to thank my thesis supervisor Prof. Son Vuong for his guidance and support of my thesis. An encouraging and kind person, Prof. Son Vuong has influenced my study at UBC in a positive way. As I look back on my time living in Vancouver, Prof. Son Vuong is surely one of the best persons I've met. I'm grateful for the careful and constructive review given by Dr. George Tsknis, especially considering that he took time to read my thesis over the Christmas holidays. I first got to know George when I worked as a TA for his CS216 course. His enthusiasm to teaching attracted me going back as a TA for his course throughout my years at UBC. Two of my fellow graduate students, Thong Huynh and Jinsong Zhu, have lent much help to my programming work for the thesis. They generously shared their expertise and resources with me to make this thesis possible. I wish them good luck on their own thesis this year! vii Chapter 1 Introduction 1.1 The Idea The area of Mobile Computing has attracted a great deal of interesting and important research in the recent years. The industry is also moving fast in this area. With a growing trend to build Mobile Computing ability into the infrastructure of computers and computer networks, there is a need to manage the mobile computing environment in a standard way and from a remote location. The Simple Network Management Protocol (SNMP, [2]) is now the standard and most popular protocol for remote monitoring and management of network devices and software. It is therefore natural to manage mobile computing through SNMP. 1.2 Thesis Objective and Contribution Mobile IP is a well researched topic in the academic community. However, none of the well-known Mobile D? implementations has SNMP capability. In fact, none of them provides any management tool. We could only monitor mobile IP activity from debugging messages. We modified an Mobile D? package, which was implemented at the University of New York, Binghamton ([14]) in C, to provide SNMP support. Network administrators can then use any existing SNMP manager (e.g. s c o t t y [7]) to monitor Mobile EP activities such as the current location of a mobile host. After gaining experience in the above exercise, we went on to implement SNMP over CORBA for Universal Personal Computing (UPC) for the IWLN project. SNMP over CORBA has only been researched in the last two years ([28]). No strong 1 implementations exist ([27]) as of this writing. To our knowledge, there is not even a prototype written for CORBA-based SNMP agents. An industrial standard is yet to be defined ([34]). We implemented a very simple agent-side gateway for our CORBA-based SNMP agent. We can now remotely monitor our UPC system from any existing SNMP manager such as s c o t t y [7]. To limit the scope of our project, our program is a stripped-down gateway heavily customized for UPC. Throughout the thesis, and particularly in Chapter 6, we present our experience and provide some practical ideas for implementing SNMP. 1.3 Thesis Organization The rest of the thesis is organized as follows. Chapter 2 highlights a few important points of background knowledge, including Mobile IP and SNMP over CORBA. In Chapter 3, we modify an existing Mobile IP implementation to support SNMP as defined in RFC2006 [13]. In Chapter 4, we implement the server side of Universal Personal Computing over CORBA. In Chapter 5, we add SNMP to our implementation of UPC. We compare the two SNMP implementations in Chapter 6 and provide closing comments in Chapter 7. 2 Chapter 2 Background Knowledge In this chapter, we highlight some background knowledge. We keep this chapter as brief as possible. Readers are referred to the Bibliography for detail information. 2.1 SNMP The Simple Network Management Protocol (SNMP [2] [3] [4]) is the standard protocol for network management. Today, SNMP is supported by virtually all network devices and many network applications. SNMP referes to a set of standards, including a protocol, a database structure specification, and a set of data objects. They together lay out the ground rules for multivendor, interoperable, TCP/LP network management. SNMP installation is divided into two parts. For a device to be managed through SNMP, a program called SNMP agent is installed on the device. SNMP agents are queried by a program called the SNMP manager that is installed on the network administrator's computer. SNMP defines the protocol of communication between the agents and the managers. The rest of this section presents the aspects of SNMP that are relevant to our thesis. 2.1.1 Management Information Base (MIB) The information for network management is stored by SNMP agents in a virtual database called the Management Information Base (MIB [5].) There are many MLBs defined either by internet RFC or by vendors and application programmers. A MTB has a logical tree structure. Every node of the tree is given an Object Identifier (O ID ) such as " 1 . 3 . 6 . 1 . 2 . 1 . 4 4 . 1 . 1 . 1 " , or symbolical names such as " m i p E n t i t i e s " . To 3 access one or more MIB nodes, an SNMP manager issues an SNMP command such as S E T , GET , G e t N e x t and G e t B u l k , etc. For example, to find out what role a host plays in the Mobile LP environment, a manager will send the command GET 1 . 3 . 6 . 1 . 2 . 1 . 4 4 . 1 . 1 . 1 to the agent. The SNMP agent might reply with a number (e.g., 1 for FA) to indicate that it is currently acting as a Foreign Agent for Mobile TP. It is important to note that the MLB is virtual and only a logical tree. It is up to every SNMP agent to implement a MLB. The SNMP agent may choose to query the network device at real time for a given OLD, and therefore does not need to maintain any intermediate storage such as a database. In this method, the MLB is never realized into an actual entity in memory or on disk. Alternatively, an SNMP agent may periodically query the network device, cache the results into memory or a file, and create an actual entity to represent the MLB. The memory structure or file format may not necessarily be in a tree form. For example, the memory structure could be a hash table, and the file could be a relational database. 2.1.2 The s c o t t y Package There are many SNMP software toolkits to help building an SNMP agent. We use the s c o t t y [7] package to implement an SNMP agent for Mobile LP. Because it uses Tel [1] scripting language, s c o t t y is suitable for fast prototyping. Scotty is also freely available. Those two features made s c o t t y a popular package in the academic community. The SNMP protocol stack is handled by s c o t t y . The application programmer needs to write a s c o t t y / T e l script to instrument a given MLB. Such an agent script 4 typically does the following: 1. Issue the s c o t t y command " s n m p s e s s i o n - a g e n t ..." to put the SNMP protocol stack on a port, typically the well known port 161. 2. Issue the s c o t t y command " m i b l o a d < f i l e > " to parse a MIB file. 3. For every O I D defined in the MIB, bind a Tel variable to it using the s c o t t y command " $ s i n s t a n c e < O I D > < T c l V a r > " . 4. The value of the bound Tel variable will be fetched by s c o t t y when a GET request is received for an O I D . 5. We can further bind Tel scripts to the GET event of a O I D . If we do so, then s c o t t y will execute the script before fetching the bound Tel variable. This gives the application the opportunity to calculate the most up-to-date value for the Tel variable. Our agent script a g e n t , t e l for Mobile IP is listed in Appendix E and discussed in Section 3.2.3. 2.1.3 Advent A g e n t B u i l d e r We use another popular toolkit, A g e n t B u i l d e r [23] from Advent Inc., to implement SNMP for Universal Personal Computing (Chapter 3) over CORBA. AgentBuilder is the most popular commercial package for creating Java-based SNMP agents. 2.2 Mobile IP Mobile DP ([H][12][14]) enables a Mobile Host to move from one local network to another while maintaining its original IP address. Mobile IP consists of three major components: the Home Agent (HA), the Foreign Agent (FA) and the Mobile Host (MH). The M H is the computer that moves from one network to another. HA is the router at the "original" local network. When M H is at home, it is just like any ordinary computer on the network. Its traffic to the internet is routed by HA. When it moves to a foreign local network, the M H registers itself with the FA which is the router at the foreign network. The address of the FA is called the care-of (CO) address of the MH. The CO Address is reported to the HA. A computer on the internet that wishes to contact the M H still uses MH's home address. The IP packets arrives at the HA. The HA encapsulates the IP packet in a new LP packet, and forwards it to the FA. The FA decapsulates the IP packet and forwards it to the MH. The relationship is depicted below. Figure 2-1 Mobile IP Illustration For our experiment, we use the Mobile LP package for Linux from the University of New York, Binghamton ([14][15][16]). I modified the source code to support SNMP. 2.3 CORBA CORBA ([21] [22]) has gained tremendous popularity recently. We choose a popular CORBA vendor, V i s i B r o k e r [19][20], to implement the Universal Personal 6 Computing (Chapter 3). CORBA is an ideal architecture for distributed computing. CORBA provides location transparency for objects (as in Object-Oriented Programming) instantiated on a network. In other words, it is an object bus. A program running on a given computer can transparently reference an object created by another program (potentially in another language) on another computer. The location transparency is provided by an Object Request Broker (ORB). The ORB runs between the LP layer and the application layer. Usually, there is an ORB running on every local subnet accessible to all hosts on the subnet. Different ORBs running on different local networks communicate with each other using Internet Inter-ORB Protocol (HOP). There are 15 standard services defined for CORBA. But most vendors, including VisiBroker, only implement a few of the promised services. In particular, VisiBroker provides Naming, Event, Security and Transaction Service. But its Security Service and Transaction Service are poorly documented and are not bundled with the standard edition of VisiBroker. In reality, most people can only use Naming Service and Event Service in VisiBroker. In our project, we only use the Naming Service. 2.4 SNMP Over CORBA For backward compatibility, we sometimes need our new CORBA application to work in the existing SNMP environment. For example, the network routers from different vendors are run by different proprietary programs. But virtually all routers today support SNMP and therefore can be managed externally and remotely by SNMP which is independant of the router's proprietary API. A network manager today would expect that new routers coming into the market will still support SNMP. So if we were to implement 7 a router in CORBA, we still need to provide an external SNMP interface. There are two cases. 1. Write a CORBA application to manage an existing SNMP device. In this case, the CORBA application is the SNMP manager. 2. Write a CORBA application in such a way that it can be managed by an existing SNMP manager such as s c o t t y / t k i n e d [9]. This is the reverse of Case 1. There is very little research done ([25][30]) for Case 2 primarily because CORBA is too new to be managed by SNMP. It will be like managing Windows NT remotely from a mainframe computer. In other words, there are better ways to manage a CORBA application remotely. However, SNMP is still the dominant protocol for network management. So any CORBA application that involves network management will still need to work with SNMP today. In our project, we implement the Universal Personal Computing over CORBA (Chapter 3), and manage it through SNMP (Chapter 4). The research for Case 1 is nearly mature today ([24][27][28][29][30][31][32][34].) The industry is almost ready to produce off-the-shelf products such as OpenSNMP (Section 2.5.3.) Even before the standards are completed, various vendors are already rolling out their products using proprietary protocols. 2.5 Related Work In this section, we highlight a few products and research results. We did not use any of them in our program. But they have influenced our design, and given ideas for future research. 8 2.5.1 Subrata Mazumdar: SNMP/CORBA Gateway Proposal Subrata Mazumdar has done much research into building a gateway between the SNMP domain and the CORBA domain ([25][26][27][28][29][30].) Some of his work has been submitted to the Object Management Group ([34],) and to be voted as a standard. A gateway is a separate process (like scot ty) . There are two kinds of gateways, the manager-side gateway (for case 1) and the agent-side gateway (for case 2). They work as follows. A manager-side gateway parses a MLB file and builds a Naming Context hierarchy in CORBA to represent a MLB tree. The O I D of a MLB node becomes a Name in the Naming Context. The gateway binds a proxy object to every Name. A CORBA application wishing to manage an existing SNMP device doesn't need to know the MLB. It first obtains the reference to the proxy object through Naming Service, then invokes the proxy's G E T / S E T method. The proxy converts such a CORBA call into an out-bound SNMP packet and sends it to the remote SNMP device. Upon receiving the reply packet from the SNMP device, the gateway decodes the value and passes it back as the function return value to the CORBA client. An agent-side gateway lets a CORBA application to be managed by any remote, existing SNMP managers. A similar Naming Context hierarchy is built. The CORBA application binds the LDL (Interface Definition Language) interfaces to the Naming Context. The gateway receives an incoming SNMP packet, looks up the IDL interface through Naming Service, and invokes the G E T / S E T method defined in the LDL. The application (now acting as a CORBA server) is responsible to implement those methods. When the function returns from the application, the gateway encapsulates the return value 9 in an out-bound SNMP packet and sends it to the remote SNMP manager. 2.5.2 Beta Ban: Multi-domain Management Proposal The gateway idea above is not restricted to SNMP. For example, we can use a similar algorithm to manage the Domain Name Service (DNS) through CORBA. The data structure of the Naming Service in CORBA is designed to be able to cover all existing directory services. CORBA gateways to SNMP, DNS or other domains have a lot in common. Instead of building many similar gateways, Bela Ban ([31] [32][33]) proposed a solution to build a single, generic, manager-side gateway with interfaces to different domains. 2.5.3 OrbyCom O p e n S N M P : an upcoming CORBA SNMP Manager OrbyCom's O p e n S N M P (http://www.orbycom.fr/OpenSnmp.htmn promises to be a manager-side SNMP/CORBA gateway similar to that described by Subrata Mazumdar. However, it is still in early Beta testing, does not offer a free evaluation copy, and only works for C++ on Orbix1. The following graph, obtained from OrbyCom's website, describes O p e n S N M P ' s architechure. It applies to any manager-side SNMP gateway in general. In the graph, the shadow objects are the proxy objects residing on the local host to represent the corresponding remote objects. 1 Orbix (http://www.iona.com/products/orbix/index.html) is also a popular CORBA implementation besides our choice of VisiBroker. 10 Cork a Mgr gateway CORBAl CLieat shad&w objects sett,.) (1) badB.: Ev*nlNotifi«r SmajMaProxyFi SNMP SNMP managed system Figure 2-2 OrbyCom SNMP/CORBA Gateway2 2.5.4 CMU-SNMP Package: Classic Choice for C Language The CMU-SNMP package ([10]) is probably the most referenced implementation. It provides an API in C to build SNMP agents. Reading its source code will give much insight into SNMP internals. 2.5.5 UCD-SNMP Package: Another Choice for C Language UCD-SNMP (http://www.ece.ucdavis.edu/ucd-snmp) from the University of California, Davis, is another popular SNMP implementation in C. Many people agree that it has a better API than CMU-SNMP. UCD-SNMP emphasizes on different aspects of SNMP than CMU-SNMP. 2 http://www.orbvcom.fr/Image6.gif 11 2.5.6 OutBack j SNMP: Java API for SNMP Manager OutBack's j S N M P (www.outbackinc.corn/products/jsnrnp) is a simple API to build SNMP manager for Java. OutBack Resource Group Inc. is an 8-person start-up company (http://www.outbackinc.com/corporate.html). I don't feel their product line-up is impressive. In particular, the little-known j S N M P lacks in functionality compared to many mature, traditional SNMP solutions (such as CMU-SNMP [10]). The only advantage of j SNMP is that it is in Java. Free evaluation copies are offered to serious shoppers. 12 Chapter 3 Implement SNMP for Mobile IP Mobile LP for IPv4 is a mature subject in research. Although decent implementations of Mobile LP have been around for a few years, none of them has industrial strength. In particular, there has been no SNMP support. To fill the gap, and to gain perspective of SNMP in a mobile environment, we implemented SNMP for Mobile LP. The Mobile LP package we used are from the University of New York, Binghamton [14]. I modified the source code in C to instrument the MLB. 3.1 The MIB: RFC2006 The MLB for Mobile IP is defined in RFC2006 [13]. The top levels of the tree are shown in the following figure. Title: Window .topO.c Creator: Tk Canvas Widget Preview: This EPS picture was not saved with a preview included in it. Comment: This EPS picture will print to a PostScript printer, but not to other types of printers. Figure 3-1 MIB for Mobile IP A large portion of the MLB is about network statistics. We focused our implementation on a few representative nodes. 13 3.2 Implementing SNMP Through a Scotty Agent We chose to use s c o t t y [7 ] to handle the SNMP protocol. The Mobile LP program communicates with s c o t t y through a file. Let's call it i w i n _ s n m p . d a t file. In the following discussion, we will use the Foreign Agent (FA) as an example. The FA writes to i w i n _ s n m p . d a t , and s c o t t y reads from it. 3.2.1 File Format We defined a simple file format for i w i n _ s n m p . d a t . The file contains two columns. The first column is the O I D of the MLB variable. The second column is the value of the variable. So the file is essentially a table indexed on O I D . A segment of the file may look like: falsBusy.O f a l s e faCOAStatus.142.103.14.170 a c t i v e faRegistrationRequired.0 true mipEncapsulationSupported.0 0 mipEnable.O 1 maAdvMinlnterval.142.103.14.170 10 maAdvAddress.142.103.14.170 224.0.0.1 maAdvertisementsSent.0 2 The file is actually dumped from a hash table in the FA. In our implementation, the hash table is the actual representation of the virtual MLB. 3.2.2 SNMP for Foreign Agent The FA has all the information for the FA portion of the MLB. In the original program, such information is held in various internal variables. We modified the program to export the values to the file i w i n _ s n m p . d a t . 14 We copy the various local variables into a hash table in memory which represents the MLB. The hash table is then dumped to the file i w i n _ s n m p . d a t . Whenever the value of a local variable changes, the corresponding entry in the hash table is updated and the file is refreshed from the hash table. With the file as the external representation of the MLB, we can now import the MLB into the SNMP agent. 3.2.3 The SNMP agent in s c o t t y Our SNMP agent, a g e n t . t c l [Appendix E], is written in scotty/Tcl. The agent reads MLB values off the file i w i n _ s n m p . d a t . It works like this: 1. a g e n t . t c l starts on the machine where the FA deamon is, and listens on a port for incoming SNMP packets. 2. a g e n t . t c l reads from the file i w i n _ s n m p . d a t and binds each value to the corresponding MLB node. This read is performed periodically and frequently to refresh the binding values. The default refresh interval is 10 seconds. 3. A SNMP manager sends a SNMP GET request to the FA machine. 4. s c o t t y receives the SNMP packet of the GET request and extracts the O I D from the GET request. 5. s c o t t y looks up the binding value for the O I D . The binding was done by a g e n t . t c l in step 2. 6. s c o t t y encapsulates the value in a return SNMP packet and sends it as the reply to the SNMP manager. 15 The following figure illustrates those steps: Figure 3-2 SNMP Agent in Scotty 3.3 Performance Consideration Our implementation of the SNMP agent is simple in concept. The simple algorithm comes with some performance concerns. 3.3.1 Mobile IP Program The FA frequently writes the entire hash table to the file i w i n _ s n m p . d a t . This is mostly redundent. An alternative would be to update in-place for only the modified entries. However, update-in-place to a file is a tricky algorithm. For a small file and light-weight MIB like ours, it is not necessary. 3.3.2 File Size and Concurrent Access of i w i n s n m p . d a t If the size of i w i n _ s n m p . d a t becomes too large, we can switch from a file to a light-weight DBMS. We then do not need to refresh the entire database as we did for a file. We just need to update the relavent records as the MIB changes. 16 The file we designed is not restricted to Mobile LP. The scotty script a g e n t . t c l has no knowledge as to who created the file. Therefore, other applications can also write SNMP information into the file i w i n _ s n m p . d a t and have a g e n t . t c l automatically reads in those values. Essentially, the file becomes a generic database for all different MLBs. And a g e n t . t c l becomes a generic gateway between user applications and SNMP domain. We will discuss this issue further in Chapter 6. If we were to have multiple programs writing to a file, concurreny will be a problem. Using a DBMS easily solves this problem. 3.3.3 Scotty scripts We wrote two versions of a g e n t , t c l . The first version is what we have just described. The disadvantage is that when a value changes in the file, it is not reflected in s c o t t y until next time s c o t t y refreshes its MLB bindings. So the SNMP manager may not always get the most up-to-date value. The second version doesn't periodically read the file i w i n _ s n m p . d a t . Instead, it reads it on demand. Whenever a SNMP GET request arrives, a g e n t . t c l reads the value from the file. Therefore, the SNMP manager always gets the most up-to-date value. The disadvantage of the second solution is that it involves file I/O for each O I D . It is OK if GET requests happen infrequently. But when a manager issues a G e t B u l k request or walks through a subtree, s c o t t y will need to retrieve multiple variables one by one. It is inefficient to read from the file multiple times for one SNMP request. After weighing the pros and cons, we chose the first solution. The interesting points of our implementation is better presented as a contrast to 17 i m p l e m e n t a t i o n o f S N M P o v e r C O R B A a n d that o f u s i n g a S N M P l i b r a r y , w e w i l l d o that i n C h a p t e r 6, after w e h a v e p r e s e n t e d S N M P o v e r C O R B A . T h i s c o n c l u d e s o u r i m p l e m e n t a t i o n o f S N M P f o r M o b i l e I P . N e x t , w e w i l l m o v e t o a d i f f e r e n t m o b i l e e n v i r o n m e n t , the U n i v e r s a l P e r s o n a l C o m p u t i n g ( U P C ) e n v i r o n m e n t f o r s u p p o r t o f u s e r m o b i l i t y . 18 Chapter 4 Implement Universal Personal Computing Over CORBA When a mobile user uses a web browser installed on a foreign network, the bookmarks configured there will be of little use to such a user. It is desirable to have the bookmark travel with him3. The same also applies to address book mobility. This concept can be generalized to any application configuration that a mobile user has at home. It will appear to the user that every computer has the same personalized configuration as his home PC. This is called Universal Personal Computing (UPC.) UPC is part of the IWIN project at UBC. We will first outline the UPC architecture, then present the implementation, and finally discuss the impact of CORBA upon the design of UPC. 4.1 UPC Architecture UPC has two software components as shown in Figure 4-1: the User Home Agent (UHA) and the Terminal Agent (TA). The communication between TA and UHA is through CORBA. The TA is a CORBA client. The UHA is a server object. The TA is written by Thong Huynh (thuynh@cs.ubc.ca). The UHA was originally written by Kangming Liu (kliu@cs.ubc.ca). I rewrote the UHA because the original UHA was insufficient for our purpose in support of network management. 3 Near the completion of this thesis, Netscape released Communicator 4.5. For the first time, it has an optional "roarning" feature that allows the bookmark to travel with the user. If roaming feature is enabled, the bookmark is stored on a roaming server. Our UPC architecture is a generalization of this concept. 19 ;:S.. : T A t l <4 download • • . -c o n f i g u r a t i o n Figure 4-1 Universal Computing Concept 4.1.1 PCE Structure T h e personal ized configurations o f a l l applicat ions for a g iven user is ca l led the user 's Personal C o m p u t i n g E n v i r o n m e n t ( P C E . ) The U H A stores al l its users' P C E i n a file. F o r every L o c a l A r e a N e t w o r k that supports U P C , there is one instance o f U H A running . 4.1.2 Use Naming Service to Locate UHA T o find the U H A for a g iven d o m a i n such as "cs .ubc.ca" , w e use C O R B A N a m i n g Service. W e create a hierarchy o f names l i k e the U N I X D N S service. Spec i f i ca l ly , our N a m i n g Context hierarchy looks l ike this ca ubc sfu c s ee Figure 4-2 Naming Context Hierarchy W h e n it starts up, the U H A uses N a m i n g Service to b i n d i tse l f to the corresponding leaf 20 node in the hierarchy. When a user logs in to a T A with his Logical User ID (LUI ) in the form o f "userl@cs.ubc.ca", the T A first parses out the domain "cs.ubc.ca", then converts it into the CosNaming name , [{"ca",""} {"ubc",""} P e s " , " " } ] The type field of every Naming Component above is empty. The T A then looks up the Naming Service to locate the desired UHA. 4.1.3 Event Sequence Every host on the internet that supports UPC has a T A running. When a user travels to a foreign host computer, the sequence of events is as follows. 1. The T A first provides a login screen. A user logs in wi th his email address such as userl@cs.ubc.ca. 2. The T A wi l l relay the login request to the U H A running in the domain "cs.ubc.ca" and establish a connection to the UHA. T A locates the U H A through Naming Service as just described. 3. T A downloads the user's PCE from UHA. 4. T A compares the user's PCE with the available resourses on the local (foreign) host, and displays a revised, localized list o f available applications. For example, i f the local host doesn't have Netscape installed, then Netscape wi l l not be an available application even i f the PCE has the Netscape configuration. 5. When the user runs an application from the list, the application wi l l run wi th the user's personalized configuration as i f the user were running it on his home computer. For example, i f the user runs Netscape, the bookmarks w i l l be downloaded from U H A and used on the foreign host. 21 6. If the user changes his personal configuration during a session (e.g., add a new bookmark,) the modified PCE will be propagated back to UHA when the user logs out from the foreign host. In other words, the user can remotely and transparently change his application configuration. The modification of PCE is persistent across sessions. This concludes the description of UPC architecture. Next, we present the functional interface. 4.2 Designing the IDL The UHA and TA communicate via CORBA. The CORBA design starts with the interface file defined by the Interface Definition Language (DDL.) The IDL for TA/UHA was originally designed by Jinsong Zhu (jzhu@,cs.ubc.ca). Thong Huynh, Kangming Liu and a few other people4. IDL design is a relatively new concept. After gaining experience during the UHA implementation, I noticed a few flaws in the original DDL and created a new DDL. The complete DDLs are listed in Appendix A and Appendix B. My implementation showed that the new DDL significantly simplified the coding on both TA and UHA. It also improved the object-orientation of the architecture. The key modifications are as follows. • ProfileFactory The old DDL has a P r o f i l e F a c t o r y interface. This interface is only used by the o l d UHA. Therefore, this interface shouldn't appear in the DDL. In fact, the UHA doesn't need a P r o f i l e F a c t o r y . So the new UHA eliminated the entire object. See appendix A for the original IDL, and appendix B for my new IDL. 22 ServiceSeq The old LDL has the following function PCE::Profile UA::UserAgent.getProfile() PCE : : Profile in turn has a ge t () function PCE::ServiceSeq PCE::Profile.get() PCE: : ServiceSeq is an array of structures that represents the user's PCE. To obtain the PCE, the client must first call UA::UserAgent.getProfile() and then P r o f i l e . g e t ( ) . This is unnecessarily complicated and indirect. The new LDL has a single function PCE::ServiceSeq UA::UserAgent.getServiceSeq() that does the job. It is a better design in terms of encapsulation and simplicity. Profile The flincation getServiceSeq () above also eliminates the need for the interface PCE: : Pr o f i l e . So now we have eliminated two interfaces from the old LDL: PCE:: Prof i l e and PCE:: Prof ileFactory. This automatically eliminates the flincation UA::UserAgent.updateProfile(). As we will see in Section 4.3, the old PCE: : P r o f i l e evolved into a private class object in the new UHA. In other words, the new LDL avoids exposing the implementation detail of UHA. InformLocation The flincation UA: : UserAgent. i n f ormLocation () is not needed. The IP address of the TA will be sent to UHA as a parameter in UA: :UserAgent. login () . 23 Tokens After login, the UHA returns a structure UA: :AuthentToken that contains some random numbers. The future communication between TA and UHA should contain this token as a simple security measure. The old LDL has the function UA::UserAgent.authenticate(). That is unnecessary and has been eliminated in the new LDL. The old LDL doesn't specify AuthentToken as a parameter in every function call. That has also been corrected in the new LDL. ConflgSeq The attribute ServiceOb j in the old structure interface PCE::Service { attribute s t r i n g ServiceObj } is a string like "BookMark: -/.netscape/bookmarks.html; Cookies: -/.netscape/cookies". The entire string represents the set of configurations for a given application. Individual configurations are separated by semi-colons. The configuration name is separated from configuration value by a colon. This is an awkward way to represent information in an object-oriented world. I have changed that into an array of objects: i n t e r f a c e C o n f i g { a t t r i b u t e s t r i n g configName; // e.g. C o o k i e s a t t r i b u t e s t r i n g f i l e P a t h ; // ~ / . n e t s c a p e / c o o k i e s }; t y p e d e f sequence C o n f i g S e q ; The old name ServiceObj is obscure. A better name would be ConfigSeq, meaning the list of configuration items. The delimited string 24 PCE:: Service. ServiceObj is now replaced by the array PCE : : Service . Conf igSeq. The resulting PCE: : Service is now interface PCE::Service { attribute ConfigSeq configSeq; } 4.3 Implementing the User Home Agent After creating the DDL file, we run idl2java compiler to generate client-side stub functions and server-side skeleton code in Java. On the server side, I implemented the skeleton functions with a subclass UserAgentlmpl. j ava. Because of the better design of the new DDL, the implementation of the server is straight forward. It consists of less than 300 lines of code plus some code shared between the client and the server. The details are as follows. 4.3.1 Data Structure • ClassSession A private object ClassSession is created for each user login session. It contains a unique sessionID, the LUI and loginTime, etc. All current sessions are stored in the hash table j a v a . u t i l .HashTable indexed by sessionID. A static class variable keeps track of the next serial sessionID. • Class PCE A private object C1 a s s PCE holds the PCE for a given user. The PCE contains the LUI, the password and an array of Service objects. Every Service object contains the list of personalized configurations for a given applications. All PCEs for the local network are collected into a hash table indexed by LUI. 25 The hash table is serialized (implements interface j ava . i o . S e r i a l i z a b l e ) in order to save the entire table in a file. A user's PCE is therefore persistent across sessions. The hash table (and the corresponding file) of PCEs is like an expanded version of the UNIX file/etc/passwd. 4.3.2 Functional Specification • login () Retrieves the correspoinding PCE by LUI from the hash table, matches the password with that stored in the PCE, generates a return token, and inserts a new session object (with a unique sessionID) into the hash table of sessions. • 1 ogout () Deletes the corresponding session object from the hash table. • getServiceSeq() Returns the array of S e r v i c e objects for the current session. The array is contained in the PCE. • down/uploadFile () Transfer files from UHA local disk to and from TA. This is used to transfer and update the hash table of PCEs. Much of the code is shared between the implementation of UHA and TA. 4.4 How CORBAservices Affect the UPC Design and Implementation The architecture of UPC is affected by the current state of CORBA. Some CORBA features enhanced the development of UPC. The lack of vendor support for many standard CORBAservices has limited the functionality of UPC. 4.4.1 Naming Service The Naming Service is available on every vendor's product. We use Naming Service to locate the UHA, including the functions related to SNMP. Naming Service is the 26 standard way to locate anything in CORBA. Without the Naming Service, the UHA will have to publish its Interoperable Object Reference (IOR [21]) to a well known file, on the web, or through other means, which are all proprietary methods. 4.4.2 Security Service The distributed nature of CORBA needs the Security Service for any serious application. The traditional Client/Server architecture has a single communication channel between a client and the server. Once the channel is established, the communication on such a channel is safer compared to a fully distributed system like CORBA. Most Client/Server applications don't bother with extra protection over an established TCP connection. When it's necessary, most DBMS vendors (such as Oracle) can encrypt TCP/TP packets in a way that is transparent to the application. The encryption scheme and key can be established at login time. In the CORBA world, there is no natural point of login. Messages are in UDP packets. All objects defined in the IDL are equally exposed to the world. In contrast, objects in a traditional Client/Server DBMS are accessible only to users who have logged on and who have been granted authorizations. To address the issue of security, CORBA defines a Security Service. Using the Security Service, the client no longer needs to pass an A u t h e n t i c a t i o n T o k e n object (Appendix B) in every function call. We can also eliminate the function U A : :UserAgent. l o g i n () from the IDL because the Security Service can reliably identify the caller. We can condense the DDL to only a few "useful" operations. 27 Since VisiBroker hasn't implemented Security Service5, we had to include a security token everywhere in our IDL. 4.4.3 Transaction Service At the end of a login session, the TA may transmit some files back to the UHA. For example, the file may be a new Netscape bookmark file. The UHA will save those files on the disk. Such an operation is logically atomic, but may contain multiple steps in reality. The best way to handle it is through a transaction like those in a database. CORBA defined a standard Transaction Service. VisiBroker supports the Transaction Service. But it does not come with the free evaluation copy. The documentation is poor and there is no freely available sample code. Fortunately, Transaction Service is not critical to our project because our environment is simple. The system adminstrator can simply backup up the configuration file regularly to safe guard any corruption. If we want our UPC implementation to have industrial-strengh and up-to-the-minute recoverability, the Transaction Service will be required. 4.4.4 Trader Service The TA is a different machine from the UHA. So the hardware and software capability will likely be different. A program that can run in UHA locally may not be able to run locally on the TA, in which case the application may be able to run remotely from the UHA. So when a user logs in to a TA, the TA negociates the list of available applications with the UHA. 5 VisiBroker has recently adopted a third-party product for their Security Service. Documentation and 28 That is best accomplished by the Trader Service. There are some declarations in our LDL for use by the Trader Service. However, no CORBA vendor today has implemented the Trader Service. As a result, we did not fully implement our LDL. 4.4.5 Persistence Service The PCE database can be modified by a program called the PCE Manager. The PCE database is read into memory by the UHA upon startup. Currently, we have programmed all the read/write operations through normal file I/O. But if we view the PCE database as a collection of CORBA objects, we can use the Persistence Service to automatically and transparently save and retrieve the PCEs. The file location, format and the instantiation of the PCE object will be transparent to the application. Further more, without direct file I/O calls, the UHA will be portable to different hosts or even different platforms. In fact, the UHA could be mobile and location transparent. However, no CORBA vendor today has implemented the Persistence Service. sample code are lacking at this point. 29 Chapter 5 Implement S N M P for Universal Personal Comput ing In last chapter, we implemented the UPC without regard of SNMP. In this chapter, we will amend our implementation to add SNMP support to UPC. To implement SNMP for UPC, we use a different approach from that for Mobile LP. First, we define the MLB as usual. Then we translate the MLB into an LDL for CORBA. The SNMP agent is a separate process from the UPC program. The relationship is depicted below. It is similar to that in Figure 2-2 on page 11. Figure 5-1 Agent-side SNMP-CORBA Gateway 5.1 Defining the Enterprise UPC-MIB Our UPC-MLB is an enterprise MLB. The Internet Assigned Number Authority (IANA, http://www.iana.org) has assigned the enterprise number 60 to the University of British Columbia6. I further assigned 99 to the subtree UPC-MLB. So the full Object Identifier 6 Apparently, someone at UBC was very early in obtaining our enterprise number 60. This number is even listed in the classic The Simple Book[2]. We are the 3rd or 4th university in the world to obtain an enterprise 30 (ODD) of the root node of our UPC-MIB is { i s o ( l ) p r i v a t e ( 4 ) e n t e r p r i s e s ( 1 ) u b c ( 6 0 ) u p c M I B ( 9 9 ) } 5.1.1 Highlights of UPC-MIB The UPC-MIB describes the managed SNMP objects on both TA and UHA. The MTB has three groups: u p c S y s t e m , u p c T A and u p c U H A . The Terminal Agent instruments u p c S y s t e m and u p c T A . The User Home Agent instruments u p c S y s t e m and u p c U H A . The UPC-MIB is depicted in the figure below. The complete ASN.l definition is in Appendex C. Tide: Window .topO.c Creator: Tk Canvas Widget Preview: This EPS picture was not saved with a preview included in it. Comment: This EPS picture will print to a PostScript printer, but not to other types of printers. Figure 5-2 UPC-MIB • upcSystem This group has two leaf nodes: u p c E n t i t i e s and u p c E n a b l e . The node u p c E n t i t i e s describes whether the host runs TA or UHA component (or both) of the UPC. The node u p c E n a b l e is in r e a d - w r i t e mode and could be set to enable or disable a TA or UHA. • upcTA This group is for the Terminal Agent. It contains some statistics such as number. And we are ahead of some big names like Apple, NASA and even AT&T. Our contact person 31 the total number of logins after boot. There is not much interesting information on a TA. • upcUHA This group is the heart of the MLB. It contains some statistics about UHA. But at the core is the uhaSessionTable that contains the list of current logins. An example of tree traversal of this table from s c o t t y is the following: $s walk x "uhaSessionTable" {puts $x} {1.3.6.1.4.1.60.99.6.1.1.1.101 INTEGER 101} {1.3.6.1.4.1.60.99.6.1.1.1.102 INTEGER 102} {1.3.6.1.4.1.60.99'.6.1.1.2.101 {OCTET STRING} userl@cs .ubc. ca } {1.3.6.1.4.1.60.99.6.1.1.2.102 {OCTET STRING} user2@cs.ubc.ca} {1.3.6.1.4.1.60.99.6.1.1.3.101 {OCTET STRING} Columbia.cs.ubc.ca} {1.3.6.1.4.1.60.99.6.1.1.3.102 {OCTET STRING} cascade.cs.ubc.ca} {1.3.6.1.4.1.60.99.6.1.1.4.101 {OCTET STRING} {Sep 21 20:50:12 1998}} {1.3.6.1.4.1.60.99.6.1.1.4.102 {OCTET STRING} {Sep 21 20:51:59 1998}} In the command, $s is a variable referencing the current SNMP session. The SNMP command is walk. The variable x holds the result of the command. And pu ts $x prints the result to the screen. Putting it in table form, the above result is: Table 5-1 Tree Walk of uhaSessionTable uhaSessionLT) uhaSessionLUI uhaSessionTA uhaSessionLoginTime 101 userl@cs.ubc.ca columbia.cs.ubc.ca Sep 21 20:50:12 1998 102 user2@cs.ubc.ca cascade.cs.ubc.ca Sep 21 20:51:59 1998 5.1.2 Comparison with MIP-MIB UPC-MLB is modeled after MLP-MLB, RFC2006 [13]. The commonality is listed below. registered with IANA is Don McWilliam (mcwillm(g)cc.ubc.ca) 32 Table 5-2 Comparison of UPC-MIB and MIP-MIB UPC-MIB MIP-MIB upcSys t em: system-wide flags mipSys t em: system-wide flags upc TA: Terminal Agent mipFA: Foreign Agent upc UHA: User Home Agent mipHA: Home Agent The major differences are: • mipMN UPC does not have a counterpart to the mobile node (MN) in mobile IP. What is mobile now is the user and his Personal Computing Environment (PCE,) not a computer. Therefore, our UPC-MIB doesn't have a counter part to the mipMN group in MIP-MIB. • m i p S e c u r i t y The security of UPC will rely on the Security Service in CORBA in the future. Currently, the Security Service is not well supported by VisiBroker. See section 4.4.2 for detail. • mipMA There is no routing involved in UPC which is at the application layer, because CORBA provides location transparency at the transport layer. So there is no counterpart to mipMA for Mobile Agent in MIP-MIB. • Traps For simplicity, there are no trap messages defined for UPC-MIB. In MIP-MIB, there is a trap for starting the agent. 5.2 MIB to IDL Translation We can now translate the MIB into DDL for the CORBA domain. With an DDL, the UPC programs do not need to have any knowledge of SNMP such as the meaning of ODD and the traversal of the MD3 tree. The UPC programs implement the DDL just 33 like any normal IDL, without compiling or linking with any SNMP library code. 5.2.1 Joint Inter-domain Management (XoJIDM) Standard The Joint Inter-domain Management (XoJIDM) task force sponsored by X/Open-Network Management Forum (NMF) has defined a translation algorithm for MJJB to JUL. The detail of the algorithm is in [24]. The algorithm maps MIB modules to DDL packages, groups to interfaces, and nodes to attributes. Those are the natural things to do. The most non-intuitive mapping is that a MIB table entry (row) is mapped to an DDL interface. In other words, every row of a MIB table is represented by an instance of a class object in Java or C++. There will be as many instantiations of the same class as there are the number of rows. Every such object has a number of attributes (variables) that match the elements of the row. For example, the following MIB tree defines u h a S e s s i o n T a b l e which has 4 columns indexed by the column u h a S e s s i o n l D . Title: Window .topO.c Creator: Tk Canvas Widget Preview: This EPS picture was not saved with a preview included in it. Comment: Figure 5-3 uhaSessionTable in UPC-MIB Using the XoJIDM algorithm, this table is translated into7: 7 The translator currently does not recognize BITS datatype. So I had to delete some definition from the UPC-MIB to make it work. The final ad-hoc IDL didn't use this translator anyway. 34 i n t e r f a c e uhaSessionEntry : SNMPMgmt::SmiEntry { const s t r i n g E n t r y l n d e x V a r L i s t = "uhaSessionID"; readonly a t t r i b u t e ASNl_Integer uhaSessionID; readonly a t t r i b u t e A SNl_OctetString uhaSessionLUI; readonly a t t r i b u t e A SNl_OctetString uhaSessionTA; readonly a t t r i b u t e A SNl_OctetString uhaSessionLoginTime; }; Note again that the entire i n t e r f a c e u h a S e s s i o n E n t r y only represonts one row in the table. There is no t y p e d e f s e q u e n c e statement to represent an array of rows. When an object is created, it is identified by E n t r y l n d e x V a r L i s t in order to know which row it is representing. This raises a few questions. When it is created, how do we register a u h a S e s s i o n E n t r y object with a SNMP agent? Later, how does the SNMP agent know which u h a S e s s i o n E n t r y instance to reference when a SNMP manager queries a particular row in the MLB table? The answers are provided below. 5.2.2 Object Management Group (OMG) Standard The creation, registration, retrieval and destruction of the class objects for CORBA/SNMP interoperability is currently being standardized [25] [34] by the Object Management Group (OMG [34]). The OMG Telecommunications Domain Task Force (under OMG Domain Technology Committee) issued the Request For Proposal (RFP) for Interworking between CORBA and TMN Systems [34] a year ago in September, 1997. The submission deadline was May, 1998, but no decision has been made as of this writing. The proposed standard uses CORBA Naming Service and Lifecycle Service to implement the LDL defined by XoJLDM standard above. 5.2.3 Translation from UPC-MIB to IDL There are a few MLB to LDL translators that are compliant to XoJLDM standard. One such 35 free translator is given in [26]. For a simple MTB like our UPC-MIB, the translation could also be done manually. There is no mature implementation of the OMG standard, but a prototype is given in [27]. All existing implementation of SNMP over CORBA is on the manager side. That is: CORBA manager <-> [gateway] <-> e x i s t i n g SNMP d e v i c e There is nothing available [25] for the following: e x i s t i n g SNMP manager <->[gateway]<-> SNMP CORBA app It would require an effort of the scale of a Ph.D. thesis to program a generic, agent-side SNMP/CORBA gateway. For the purpose of this thesis, we decided to do some ad-hoc implementation. We defined a customized IDL for SNMP to minimize the amout of coding we have to do. In particular, our DDL for u h a S e s s i o n T a b l e is i n t e r f a c e UserAgent { s t r i n g uhaSessionLUI ( i n long s e s s i o n I D ) ; s t r i n g uhaSessionTA ( i n long s e s s i o n I D ) ; s t r i n g uhaSessionLoginTime(in long s e s s i o n I D ) ; 1; Note that our u h a S e s s i o n T a b l e is part of i n t e r f a c e U s e r A g e n t , not a separate i n t e r f a c e . In other words, we extended the IDL. It is easier to instrument a MIB that way. The u h a S e s s i o n T a b l e is now broken down by columns instead of rows. Every column is represented by a function that returns the desired element according to the index s e s s i o n I D . The actual DDL also defines exceptions that correspond to traditional SNMP errors. The complete DDL is listed in Appendix B. 36 5.3 Implementing the SNMP Part of the IDL After defining the DDL above, the server implementation is straight forward. The application programmer implementing this LDL does not need to have any knowledge of SNMP. He does not even need to know the existense of SNMP. Let's use the function s t r i n g u h a S e s s i o n L U I ( i n l o n g s e s s i o n I D ) as an example. This function returns the L U I (e.g., "userl@cs.ubc.ca") of the corresponding s e s s i o n I D . The algorithm is simple. The function retrieves the C l a s s S e s s i o n object by s e s s i o n I D from the hashtable (see Section 4.3,) and returns the variable L U I within that object. The other functions have similar implementation. The next section discusses the issues pertaining to the implementation of an agent-side gateway. 5.4 Implementing an Ad-hoc Agent-side SNMP/CORBA Gateway Now that we have implemented the CORBA server that instruments MLB variables, the tricky part is how to call those functions. We don't need to know SNMP in implementing those functions, but we need to know SNMP to call those functions. We need to know which function to call and where the function is. Ideally, this task is accomplished by an agent-side SNMP/CORBA gateway. But, as explained in Section 5.2.3, there is currently no such a gateway (either standard or proprietary) on the market to systematically register, retrieve and destroy the objects that instrument a MLB. Therefore, we wrote a customized agent-side SNMP/CORBA gateway. Strictly speaking, this is not a gateway because it is not generic. But for the purpose of our particular MLB/LDL, it bridges the gap between receiving 37 incoming SNMP requests and making CORBA calls to our UPC program. So it is a customized gateway in a sense. 5.4.1 Advent AgentBuilder: Toolkit for Building SNMP Agent There are many products that provide a toolkit or an API to build a SNMP agent. We chose AgentBuilder 2.03 from Advent Inc. [23] AgentBuilder is the most popular tool in the industry to build Java-based SNMP agents. AgentBuilder converts an incoming SNMP packet into a Java data structure, then calls a user-defined Java function to handle the request. We can attach a separate Java function to every MIB node. Once we are in the Java world, we can communicate with our UPC programs through CORBA. 5.4.2 Implementing the Missing Piece of the Bridge The major piece of code is U s e r A g e n t S N M P . j a v a listed in Appendix D. That class is attached to the nodes u h a S e s s i o n I D , u h a S e s s i o n L U I , u h a S e s s i o n T A and u h a S e s s i o n L o g i n T i m e in UPC-MIB. That is, it is attached to the 4 columns of u h a S e s s i o n T a b l e . 5.4.3 The Class Constructor The class constructor of U s e r A g e n t S N M P does one thing: find the CORBA server U s e r A g e n t . Recall from Section 5.2.3 that our MIB instrumentation is integrated in U s e r A g e n t , not in a separate object. We use CORBA Naming Service to find the U s e r A g e n t for a given domain like "cs.ubc.ca". This is similar to the way a TA finds the UHA as described in Section 4.1. 38 In fact, they both call the same user-defined function public Static UA.UserAgent findUserAgent(String domain) to located the UHA. The function returns the CORBA reference to the UserAgent. 5.4.4 How the Gateway Works We are now ready to receive SNMP requests and deligate the instrumentation to the UserAgent. For example, the following sequence of events occur when a GET request is received for OLD uhaSessionLUI . 1 0 1 , i.e., the LUI associated with the index (the uhaSessionID) 101. • AgentBuilder extracts the OID 1.3.6.1.4.1.60.99.6.1.1.2.101 from the SNMP packet. That OID is the numerical representation of u h a S e s s i o n L U I . 1 0 1 . • AgentBuilder determines that the Java class UserAgent SNMP is associated with the requested OID. • AgentBuilder calls UserAgentSNMP. getReqMesg ( l o n g [ ] O I D ) to retrieve the value for the node. To instrument a MIB variable, a user-defined Java class like UserAgentSNMP must implement the Java interface getReqMesg ( ) . The interface is mandated by AgentBuilder. Our implementation of getReqMesg.() does the following. • Our UserAgentSNMP doesn't know the value for u h a S e s s i o n L U I . 1 0 1 . That information is given by the following segment of IDL. interface UserAgent { st r i n g uhaSessionLUI(in long sessionID); } In the object constructor, our UserAgentSNMP already obtained the reference to the 39 U s e r A g e n t . Now we invoke the function U s e r A g e n t . u h a S e s s i o n L U I () through CORBA. In other words, U s e r A g e n t S N M P delegates the SNMP request to U s e r A g e n t , and thus bridges the gap between SNMP and CORBA. • U s e r A g e n t . u h a S e s s i o n L U I () returns the L U I to U s e r A g e n t S N M P , which in turn passes it back to AgentBuilder. • AgentBuilder receives the returned value, encapsulates it in a return SNMP packet, and transmits the return packet to the originating SNMP manager. 5.4.5 Implementing the Tree Traversal The above steps should be enough. Their functionality is similar to that of s c o t t y [7]. But AgentBuilder does not handle MIB tables well. It puts too much burden on the application programmer. Specifically, it requires the application programmer to implement the algorithm to traverse a MIB table. Traversing a MIB is error-prone as it often involves hard-coding, and requires an in-depth knowledge of SNMP. It should be done by AgentBuilder with a generic algorithm rather than relying on every application programmer to write home-brew code. I have implemented the required Java interface p u b l i c S n m p V a r g e t N e x t R e q M e s g ( l o n g [ ] O I D , ...) for the class UserAgentSNMP. The function takes in the O I D from a S N M P : G e t N e x t request, returns the next valid O I D (together with its value) after the original O I D . The original O I D may not be a valid O I D . It just indicates the starting point of MIB traversal. That is the reason that this function is used for a G e t N e x t request, not a G e t request. For example, the s c o t t y [7] command 40 $ s g e t n e x t u h a S e s s i o n L U I will send a G e t N e x t packet to AgentBuilder. AgentBuilder then calls our function g e t N e x t R e q M e s g () which determines that u h a S e s s i o n L U I .101 is the next valid O I D and " u s e r l g c s . u b c . c a " is the value for that O I D . Note that the original O I D u h a S e s s i o n L U I from s c o t t y is not a valid MLB object instance. The code for g e t N e x t R e q M e s g () is listed in Appendix D. 5.5 How SNMP Affects the UPC Design and Implementation In Section 4.4, we discussed the impact of CORBA on the design and implementation of UPC. In this section, we briefly discuss the impact of adding SNMP on UPC. As we have seen from previous sections, adding SNMP to UPC (or any CORBA application) only involves implementing a few more LDL functions. If a SNMP/CORBA gateway is readily available, then a CORBA programmer does not need to have any SNMP knowledge in order to write a CORBA application that supports SNMP. However, at the current state, a CORBA programmer has to carefully design and program SNMP-specific features to a "normal" CORBA program. 41 Chapter 6 Comparison of S N M P Implementations In this chapter, we compare three implementations for SNMP agents: traditional agent, our SNMP for Mobile IP and our SNMP for CORBA-based UPC. 6.1 Instrumenting a MIB in the Traditional Way: Library Code We didn't use the traditional solution in either of our two SNMP implementation, but we will discuss it here as a reference algorithm. The traditional way to add SNMP to an application is for the application to call some SNMP library code, say the CMU SNMP library [10]. For each MIB variable, the application supplies a callback function. The library code receives incoming packets from the SNMP port, and invokes the appropriate callback function. Therefore, in addition to its normal duties such as acting as a Foreign Agent for Mobile IP, the application also listens on a port for SNMP packets. In other words, the SNMP protocol is build-in with the user application. This has some drawbacks: 1. Port Conflict A port could only be used by one process. So if the well-known SNMP port 161 is used by a SNMP agent for a particular MIB, then another agent instrumenting a different MIB cannot use that same port 161. The traditional way to solve the problem is to have a SNMP multiplexer (provided by the SNMP library) listen on port 161. Every "real" SNMP agent registers with that multiplexer. 2. Interference Listening on a port requires a timer to do non-blocking read for incoming SNMP packets. This may interfere with timers used by the user application. So adding SNMP limits an application programmer's choice. In particular, the Mobile LP code has complex algorithms in listening to incoming UDP packets. It will almost certainly interfere with the CMU SNMP library calls. In order to use the CMU library code, we will need to carefully alter the existing loop in the Mobile IP code. That is one of the reasons we did not use any SNMP libraries. 3. Code Size The SNMP library code is compiled into every SNMP agent. This is a big piece of code to drag along for a simple application. 4. Redundancy Multiple agents running on the same machine each loads its own copy of the same library code. For example, each agent will contain an identical MLB parser. This is redundent. 5. Language Choice When we program our application, we have to chose a programming language supported by the SNMP library. For example, the popular CMU library is for C only. Among other things, C is not a good language for prototyping and rapid application development. 6.2 Instrumenting the MIB for Mobile IP: A Separate Agent To implement SNMP for Mobile LP without the drawbacks of a traditional agent, we used a separate agent ( s c o t t y [ 7 ] ) . The detail is provided in Chapter 1. We did that specifically to avoid timer interference and to facilitate fast prototyping. 6.2.1 Communicate Through a File Instead of communicating to a SNMP port, the Mobile LP code communicates with s c o t t y through a file. This file could be considered as the actual (instead of virtual) database for MLB. Alternatively, we can use a DBMS instead of a file. After reading 44 from the file, s c o t t y transmits the value out in an SNMP packet. If all applications write to the file in the same format, s c o t t y becomes a generic agent. It handles SNMP protocol, and looks up the value from the file indexed by a given O I D , without knowing who instrumented the node. 6.2.2 Pros and Cons This solution solves the problems of the SNMP library. Since one s c o t t y process provides the agent ability to multiple applications, the applications no longer have the problems of port conflict, code size and redundency. Since the communication is through a file, there is no limit on language choice. Finally, simple file I/O is not likely to interfere with an application's normal tasks. This works well for SNMP GET requests. It is difficult to handle S E T requests. When s c o t t y receives a S E T request, it needs to pass it immediately to the application that instruments the MTB. But so far our application only writes to the file, and does not read from the file. In order to receive the requests from s c o t t y , our application has to either frequently do non-blocking reads from a port or freqently read from a file. Neither solution is elegant. We did not implement writable nodes for our MIB. What we need is an easy way to communicate bi-directionally. This problem is solved in the CORBA solution below. 6.3 Instrumenting a MIB in CORBA: Gateway Approach We could have implemented SNMP for UPC using either of the previous two solutions. But we chose to write a SNMP/CORBA gateway to explore new algorithms. 45 6.3.1 Bi-directional Communication CORBA provides a convenient way for objects to bi-directionally communicate with each other. When we want to instrument a MLB from an existing program, we only need to add a few LDL definitions without worrying about the communication. GET requests are replied with return values of LDL functions. S E T requests are carried out by calling LDL functions without return values. This solves the problem in the s c o t t y solution. 6.3.2 Lack of Availability There are many mature products available to build a traditional SNMP agent, but there is no off-the-shelf product to build SNMP for CORBA. In particular, we want an agent-side gateway. This is in fact a novel concept because agent-side SNMP/CORBA gateway is still a new and rare topic in academic research. In fact, no product, demo or even prototype exists for the time being. An industrial standard is yet to be formed [34]. In our project, we had to narrow the problem to our specific case in order to create our own gateway in a reasonable amount of time. 6.3.3 Simplicity Compared with the traditional SNMP agents, adding SNMP on UPC is relatively simple. If a generic agent-side gateway is available, then the application programmer simply needs to implement the translated LDL without any knowledge of SNMP. The application is not a SNMP agent. That is, it doesn't listen on a port for incoming SNMP packets. The gateway (which is a separate process) listens on the port. Compared with the s c o t t y solution, our gateway acts like s c o t t y . The Naming Context hierarchy is like the file used in the s c o t t y solution. 46 6.3.4 Location Transparency The Home Agent in mobile IP can inspect the source address of the UDP packets to determine the location of a Foreign Agent. In contrast, the UHA in UPC has no automatic way of knowing where the TA is, because CORBA provides location transparency. 47 Chapter 7 Conclusion and Future Work 7.1 Thesis Summary SNMP will remain a popular industrial standard for network management in the near future. A Mobile Computing environment will have to support SNMP in order to have industrial acceptence. We have explored SNMP solutions in two Mobile Computing environments: the Mobile IP and our own Universal Personal Computing. The two Mobile Computing environments are based on different infrastructure and at different layers of communication protocol. We have shown different strategies for SNMP support. We implemented a simple agent-side SNMP/CORBA gateway for UPC which allowed us to remotely monitor UPC from any existing SNMP manger, such as scotty. The work of SNMP over CORBA is particularly new and interesting. As SNMP remains the industrial-standard for network management, and as CORBA quickly gains popularity, the bridging between the two domains becomes more and more necessary. There is plenty of interesting work ahead. 7.2 Future Work Research in SNMP over CORBA is still at the initial stage. No off-the-shelf products are yet available on the market. The area has a good potential of research in the future. I spent a great deal of time gaining practical experience in SNMP and CORBA before being productive in this project. In the future, it will be better for a graduate student to learn SNMP and CORBA progressively. The following list (progressively harder) can be a roadmap for future graduate work. 48 1. Writable Nodes In this project, I only implemented readable nodes in the MLB because they are the simplest. Implementing the writable or read/write nodes can be an assignment in a graduate course. Readable nodes allow an SNMP manager to monitor an SNMP device. Writable nodes allow a manager to remotely configure a device. For example, the MLB for a network router may define its routing table as writable nodes. A manager may send commands like " S E T routingtable.ipl . . ." to remotely and dynamically change a router's routing table for destination LP address ip l . Another example would be to define a "reboot" node in the UPC MLB. Then the manager can remotely reboot the User Home Agent. 2. Traps Usually, SNMP communication is initiated by the manager. A SNMP agent responds to a manager's requests. But the agents can also actively send messages to a manager without solicitation. Those messages are called traps. For example, when an agent reboots, it can send a trap to the manager to inform the manager of this new state. Traps are like Events in CORBA. In fact, the specification for CORBA-based SNMP uses the Event Service to implement traps. The programming work can be broken down to two or three assignments in a graduate course. In our context, we can define a "userLogin" trap for UPC. Whenever a Terminal Agent forwards a login request to the UHA, the U H A sends a "userLogin" trap to any registered SNMP manager. The manager can therefore display the list of online users at real time. Without traps, the manager has to frequently poll the U H A in order to monitor the list of online users. 3. CORBAservices In Section 4.4, we discussed the impact of CORBAservices to the design of UPC. Many of the standard CORBAservices are not available from 49 CORBA vendors today. As CORBA matures, vendors will support more and more standard CORBAservices. In particular, we can use the Security, Transaction, Trader and Persistence Service to enhance the design and implementation of UPC. It could be a graduate-level course project to learn CORBA and enhance our UPC programs with various CORBAservices. The following examples illustrate specific functionalities which can be implemented. Security Service We currently pass a token with every remote invocation. The token essentially contains the user ID and password. This is necessary because CORBA is not connection-oriented and therefore every method invocation needs authentication. With the Security Service, we no longer need to pass the token in every method invocation. The Security Service provides both authentication and encryption. Persistence Service The UHA maintains a User Profile for every user. The User Profile must be persistent across sessions. Currently we manually save the User Profile to a specific directory on disk. We can eliminate that step with the Persistence Service. The Persistence Service transparently saves an object to disk and restores the object to memory. We no longer need to manually handle the conversion and the file location. Transaction Service When saving the user profiles to disk, we run the risk of corrupting the file if the save fails in the middle of the operation. For example, the disk could be full when the file is only partially saved. The Transaction Service ensures the atomicity of any sequence of operations. It is like the transaction management in a traditional database management system. 50 Trader Service A given program may require certain hardware support. The Terminal Agent needs to ensure that if a user tries to download a program from UHA, the program will be able to run with the hardware support on the TA. Every such program could be tagged with hardware-requirement properties. The TA can use the Trader Service to shop for a program that is compatible with local hardware configuration. SNMP/CORBA Gateway As introduced in Section 2.5.1, the generic way to provide SNMP support over CORBA is the SNMP/CORBA gateway. Our gateway in Section 5.4 is not a real gateway because it is too specialized for UPC. Implementing a proper gateway requires in-depth understanding of both SNMP and CORBA. This could be the scope of a Ph.D. thesis. However, if a student has already gained programming experience in SNMP and CORBA in a first-year graduate course, then he should be able to implement a portion of a generic gateway for a Master thesis. All existing gateways (only prototypes are available) are manager-side gateways. That is, they let a CORBA application to manage an existing SNMP device. For some original work, we can consider to implement an agent-side gateway so that a CORBA application can be managed by an existing, SNMP manager. The industry is still trying to form a standard for this scenario. No agent-side gateways have been implemented yet. Agent-side gateways let us wrap a CORBA application with an SNMP appearance so that the CORBA application is backward compatible with existing SNMP software. For example, we can write a CORBA client application to remotely manage our User Home Agent. However, a network manager would likely want to manage everything 51 in traditional SNMP that is familiar to him. Most network management and monitoring software only understand SNMP. In order for our new CORBA-based UHA to be compatible with the rest of internet, we need to give it an SNMP interface so that it looks like a traditional SNMP device. We can create such an interface in an ad-hoc fashion for our specific router (which we did in our thesis.) Alternatively, we can use a generic agent-side SNMP/CORBA gateway. To our knowledge, no such gateway, not even a prototype, exists, as explained in Section 6.3. J 52 Bibliography SNMP [1] John K. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, 1994, http://wvvw.cs.ubc.ca/reading-room/info/book.html [2] Marshell T. Rose, The Simple Book - An Introduction to Management of TCP/IP-based Internets, Prentice Hall, 1991. [3] William Stallings, SNMP, SNMPv2 and RMON - Practical Network Management, 2 n d Edition, Addison-Wesley, 1996. [4] Frequently Asked Questions (FAQ) of news://comp.protocols, snmp, ftp ://rtfm. mit.edu/pub/usenet/comp. protocols, snmp/ [5] David T. Perkins, Understanding SNMP MIBs, September 1993, http://netman.cit.buffalo.edu/Books.html http://netman.cit.buffalo,edu/Doc/UnderstandingSNMPvlMibs.ps.gz [6] J. Schonwalder & H. Langendorfer, How to Keep Track of Your Network Configuration, Proc. 7th Conference on Large Installation System Administration (LISA VII) Monterey (California), November 1993, http ,7/wwwhome. cs.utwente. nl/~schoenw/ scotty/#DOC S ftp://ftp.ibr.cs.tu-bs.de/pub/local/papers/discover.ps.gz [7] J. Schonwalder & H. Langendorfer, Tcl Extensions for Network Management Applications, Proc. 3rd Tcl/Tk Workshop, Toronto (Canada), July 1995, http: //wwwhome. cs. utwente.nl/~schoenw/scotty/#DOC S ftp://ftp.ibr.cs.tu-bs.de/pub/local/papers/tcltk-95.ps.gz [8] J. Schonwalder, Scotty Frequently Asked Questions, 1998, http ,7/wwwhome. cs. utwente. nl/~schoenw/scotty/#DOC S http://www.ibr.cs.tu-bs.de/~schoenw/scotty/faq/faq.html [9] Mark Newnham, Getting started with Tkined, January 1997, http://wwwhome.cs.utwente.n1/~schoenw/scotty/#DOCS http://wwwhome.cs.utwente.nl/~schoenw/scotty/docs/getstart.html [10] CMU SNMP Library, Carnegie Mellon University, http ://www.net. cmu.edu/projects/ snmp 53 Mobile IP [11] RFC1256 - ICMP Router Discover Messages, September 1991, http: //www, rfc-ed itpr. org/rfc. html [12] RFC2002 - IP Mobility Support, October 1996, http://www.rfc-editor.org/rfc. html [13] RFC2006 - The Definitions of Managed Objects for IP Mobility Support using 1 SMIv2, October 1996, http://www.rfc-editor.org/rfc.html [14] Linux Mobile-IP Software and Documentation, University of New York, Binghamton, http://anchor.cs.binghamton.edu/~mobileip/ [15] Vipul Gupta, An Introduction to the Linux 1.3.x Networking Code, Course Notes, University of New York, Binghamton, http://anchor.cs.binghamton.edu/courses/cs628/linux-net.html [16] Vipul Gupta, Linux ioctlQ Primer, Course Notes, University of New York, Binghamton, http://anchor.cs.binghamton.edu/courses/cs628/ioctl.html [17] Linux Documentation Project, http://sunsite.unc.edu/mdw/linux.html [18] M Beck, H Bohme, M Dziadzka, U Kunitz, R Magnus & D Verworner, Linux Kernel Internals, Addison-Wesley, 1996 CORBA [19] VisiBroker 3.2 for Java Software Package, Inprise Inc., http://www.inprise.com/visibroker/ [20] Doug Pedrick, Jonathan Weedon, Jon Goldberg & Erik Bleifield, Programming with VisiBroker - A Developer's Guide to VisiBroker for Java, Wiley Computer Publishing, 1998 [21] Robert Orfali, Dan Harkey & Jeri Edwards, Instant CORBA, Wiley Computer Publishing., 1997 [22] Robert Orfali & Dan Harkey, Client/Server Programming with JAVA and CORBA, Wiley Computer Publishing., 1997 SNMP Over CORBA [23] AgentBuilder 2.03 Software Package, AdventNet Inc. http://www.adventnet.com/ [24] X/Open, Inter-domain Management: Specification Translation, 54 http://www.opengroup.org/publications/catalog/p509.htm [25] My email exchange with Subrata Mazumdar. [26] Subrata Mazumdar, MIB to IDL Translator, http://nsm.research.bell-labs.com/~mazum/CorbaSnmp/SMI2IDL/Smi2IdlConv.html [27] Subrata Mazumdar, CORBA/SNMP Gateway Based Applet Demo, http://nsm.research.bell-labs.com/~mazurn/CorbaSnmp/CorbaSnmpDemo.html [28] Subrata Mazumdar, Inter-Domain Management between CORBA and SNMP: WEB-based Management - CORBA/SNMP Gateway Approach, Seventh IFIP/LEEE International Workshop on Distributed Systems: Operations & Management (DSOM'96), L'Aquila, Italy, October 28-30, http://www.bell-labs.com/user/mazum/recent_work.html http://www.bell-labs.com/user/mazum/papers/XoJLDM/CORBASnmpExt.pdf [29] Subrata Mazumdar, Directory Enabled Management Information Base -Integration of MIB with Directories using COSNaming and JNDI, Ninth TFLP/EEEE International Workshop on Distributed Systems: Operations & Management (DSOM'98), Newark, Delaware, USA, October 26-30, 1998, http://www.bell-labs.com/user/mazum/recent_work.html http://www.bell-labs.com/user/mazum/papers/INCM/DEM_Paper.pdf [30] Subrata Mazumdar, CORBA/TMN Internetworking - SNMP Part, OMG meeting at Manchester, UK, in response to RFP for CORBA/TMN Interworking, OMG Document # telecom/98-04-04, April 1998, http://www.bell-labs.com/user/mazum/recent_work.html http://www.bell-labs.com/user/mazum/papers/XoJLDM/CorbaSnmpRFPRespVG.pdf [31] Bela Ban, Towards an Object-Oriented Framework For Multi-Domain Management, December, 1995, http://simon.cs.Cornell. edu/home/bba/GOM.ps.gz [32] Luca Deri & Bela Ban, Static vs. Dynamic CMIP/SNMP Network Management Using CORBA, http://simon.cs.comell.edu/home/bba/Corba.pdfgz [33] Bela Ban, Extending CORBA for Multi-Domain Management, August 1996, http .//simon. cs. C o r n e l l . edu/home/bba/ corbagom. ps. gz [34] The Object Management Group (OMG), http://www.omg.org http://www.omg.org/library/schedule/CORBA_TMN_Interworking_RFP.htm ftp://ftp.omg.org/pub/docs/telecom/97-09-04.txt 55 Appendices Appendix A Old PCE-UA.IDL // File PCE-UA.idl module PCE { typedef string ServiceName; typedef string ServiceObj; typedef string ServiceTypeName; typedef string Constraint; typedef string Preference;, typedef string PolicyName; typedef string PropertyName; typedef string PolicyValue; typedef string PropertyValue; typedef string HpropertyValue; enum PropertyMode { PROP_NORMAL, PROP_READONLY, PROP_MANDOTORY, PROP_MANDO TOR Y_READONL Y }; enum ObjectRefType { APPLI_OBJECT, APPLI_CONFIG, PPLI_RESOURCE_FILE }; struct HardwareCapf string Hname; HpropertyValue value; typedef sequenceHardwareCapSeq; struct Property { PropertyName name; PropertyValue value; PropertyMode mode; }; typedef sequence PropertySeq; struct Policy{ PolicyName name; PolicyValue value; }; typedef sequencePolicySeq; struct Trade{ ServiceTypeName type; // service type name Constraint constr; // constraint Preference pref; // which offers return first PolicySeq p o l i c i e s ; // all property infomation PropertySeq Properties; // search policy }; 56 struct Service{ ObjectRefType type; // app or config or resource ServiceName serviceName; // user's service name ServiceObj serviceObj; // app object ref or obj which // allows access to the app config or resources Trade trade; // for Trade service HardwareCapSeq hardwareCapSeq; // hardware capability }; typedef sequenceServiceSeq; interface Profile { attribute ServiceSeq serviceSeq; // user's PCE void set (in PCE::ServiceSeq serviceSeq); PCE::ServiceSeq get (in string username); }; interface ProfileFactory { Profile createProfile(in string User_name, in ServiceSeq serviceSeq ); void deleteProfile (in Profile p) ; }; }; // module PCE ////////////////////////////// VA /////////////////////////////////// module UA { struct Token{ string low; string high; if interface UserAgent { boolean authenticate (in string LUI, in string password) ; boolean tokenauthent (in string LUI, in string password, out Token token) ; PCE: : Prof He getprofile (in string username) ; string download(in string filename); boolean uploadfin Token token, in string filename, in string data); boolean updateProfile (in string username, in PCE: .'Profile p) ; void logout (in string username); } // module UA 57 Appendix B New PCE-UA.IDL // File PCE-UA.idl ///////////////////////////// module PCE //////////////////////////// module PCE { typedef string ServiceTypeName; typedef string Constraint; typedef string Preference; typedef string PolicyName; typedef string PropertyName; typedef string PolicyValue; typedef string PropertyValue; typedef string HpropertyValue; enum PropertyMode { PROP_NORMAL, PROP_READONLY, PRO P_MANDOTORY, PR 0 P_MANDO TOR Y_ READONL Y it enum ObjectRefType { APPLI_OBJECT, APPLI_CONFIG, APPLI_RESOURCE__FILE }; struct HardwareCap{ string Hname; HpropertyValue value; }; typedef sequenceHardwareCapSeq; struct Property { PropertyName name; PropertyValue value; PropertyMode mode; }; typedef sequence PropertySeq; struct Policy{ PolicyName name; PolicyValue value; }; typedef sequencePolicySeq; struct Trade{ ServiceTypeName type; Constraint constraint; Preference preference; // which offers return first PolicySeq policySeq; // search policy PropertySeq propertySeq; // all property infomation }; interface Config { attribute string configName; attribute string filePath; 58 }; typedef seqaence ConfigSeq; interface Service { attribute string serviceName; //e. g. "NET_SCAPE", "TIC_TAC_TOE" attribute ObjectRefType type; //e.g.APPLI_OBJECT, APPLIJZONFIG attribute ConfigSeq configSeq; // e.g. {"B_MARK:/gradsl/vyin/.netscape/bookmark.html", // "COOKY:/gradsl/vyin/.netscape/cookies"} attribute Trade trade; attribute HardwareCapSeq hardwareCapSeq; }; typedef sequence ServiceSeq; }; // module PCE ///////////////////////////// module VA //////////////////////////// module VA { // This struct should be an interface to abstract the internals. struct AuthentToken{ long sessionID; // Unique among all sessions of all users string low; string high; }/ interface UserAgent { exception UPCAuthenticationFailure { string message; }; exception SNMPNoMorelndex { string message; }; exception SNMPSessionlDInvalid { string message; }; AuthentToken login (in string LUIr in string password, in string TAaddr) raises (UPCAuthenticationFailure); void logout (in AuthentToken token); PCE::ServiceSeq getServiceSeq (in AuthentToken token) raises (UPCAuthenticationFailure); string downloadFile (in AuthentToken token, in string filename) raises (UPCAuthenticationFailure); void uploadFile(in AuthentToken token, in string filename, in strin data). raises (UPCAuthenticationFailure); // SNMP stuff string getSNMPTestVar () ; long nextSessionID (in long startSessionID) raises (SNMPNoMorelndex) string uhaSessionLUI (in long sessionID) raises (SNMPSessionlDInvalid); string uhaSessionTA (in long sessionID) raises (SNMPSessionlDInvalid) string uhaSessionLoginTime (in long sessionID) raises (SNMPSessionlDInvalid); }; }; // module UA 59 Appendix C UPC-MIB - Enterprise MIB for UPC UPC-MIB DEFINITIONS ::= BEGIN — TEXTUAL-CONVENTIONS — — TEXTUAL-CONVENTIONS — — TEXTUAL-CONVENTIONS — — TEXTUAL-CONVENTIONS — — TEXTUAL-CONVENTIONS — ubc OBJECT IDENTIFIER ::= { enterprises 60 } upcMIB OBJECT IDENTIFIER ::= { ubc 99 } — Groups under upcMIB upcSystem OBJECT IDENTIFIER ::= { upcMIB 1 } upcTA OBJECT IDENTIFIER : := { upcMIB 5 } — Terminal Agent upcUHA OBJECT IDENTIFIER : : = { upcMIB 6 } upcSystem Group upcEntities OBJECT-TYPE SYNTAX BITS { terminalAgent ( 0 ) , userHomeAgent ( 1 ACCESS read-only STATUS mandatory DESCRIPTION "This object describes which UPC entities are supported by this host. The host may support more than one UPC entities. For example, the host supports both Terminal Agent (TA) and User Home Agent (UHA). Thereforer bit .0 and bit 1 are set to 1 for this object." { • upcSystem 1 } upcEnable OBJECT-TYPE SYNTAX INTEGER { enabled ( 1 ) ACCESS read-write . STATUS mandatory disabled ( 2 ) } DESCRIPTION • "Indicates whether the UPC protocol should be enabled for the host." ::= { upcSystem 2 } -- User Home Agent taLogin OBJECT IDENTIFIER ::= { upcTA 3 ) uhaSessionTable OBJECT-TYPE 60 SYNTAX SEQUENCE OF UhaSessionEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing the home agent's mobility bindi list. The home agent updates this table in response to Login events from mobile nodes." : : = { upcUHA 1 uhaSessionEntry OBJECT-TYPE SYNTAX UhaSessionEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry on the mobility binding list." INDEX { uhaSessionID } ::= { uhaSessionTable 1 } UhaSessionEntry :;= SEQUENCE { UhaSessionID INTEGER, uhaSessionLUI DisplayString, uhaSessionTA DisplayString, uhaSessionLoginTime DisplayString } uhaSessionID OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "SessionID assigned by User Agent upon login." REFERENCE rr rr AGENTCLAUSE rr CLASS-COMMAND: CLASS-NAME: UPC.UserAgentSNMP INSTANTIATE: first-time PARAMETERS: param string" END AGENTCLAUSE : := { uhaSessionEntry 1 } uhaSessionLUI OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "LUI of the corresponding session. " REFERENCE rr rr 61 AGENTCLAUSE ff CLASS-COMMAND: CLASS-NAME: UPC.UserAgentSNMP INSTANTIATE: first-time PARAMETERS: param string" END AGENTCLAUSE : := { uhaSessionEntry 2 }• uhaSessionTA OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "IP address of Terminal Agent." REFERENCE If II AGENTCLAUSE II CLASS - COMMAND: CLASS-NAME: UPC.UserAgentSNMP INSTANTIATE:' first-time PARAMETERS: param string" END AGENTCLAUSE : := { uhaSessionEntry 3 } uhaSessionLoginTime OBJECT-TYPE SYNTAX • DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The start time of the session." REFERENCE II II AGENTCLAUSE If CLASS - COMMAND: CLASS-NAME: UPC.UserAgentSNMP INSTANTIATE: first-time PARAMETERS: param string" END AGENTCLAUSE : := { uhaSessionEntry 4 } taLoginAttempted OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory 62 DESCRIPTION "Total number of login attempts since boot." ::- { taLogin 2 } taReasonOther OBJECT-TYPE SYNTAX ACCESS STATUS Counter read-only mandatory DESCRIPTION "Total number of failed login attempts by either terminal agent or user home agent --reasons other than Unreachable and AuthenticationFailure." ;:= { taLogin 4 } taReasonUnreachable OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of login denied -- user home agent unreachable." ;;= { taLogin 12 } taReasonAuthenticationFailure OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS • mandatory DESCRIPTION "Total number of login denied by user home agent — failed authentication." ::= { taLogin 15 } uhaLogin OBJECT IDENTIFIER ;:= { upcUHA 2 } uhaLoginAccepted OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION Total number of Login Requests accepted by home agent (Code 0) . : := { uhaLogin 3 } uhaReasonUnspecified OBJECT-TYPE 63 SYNTAX ACCESS STATUS Counter read-only mandatory DESCRIPTION "Total number of Login Requests denied by home agent — reason unspecified (Code 128) . " ::= { uhaLogin 5 } uhaMNAuthenticationFailure OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS • mandatory DESCRIPTION "Total number of Login Requests denied by home agent -- mobile node failed authentication (Code 131) . " :: = { uhaLogin 8 } END 64 Appendix D UserAgentSNMP.Java - the SNMP/CORBA Gateway package UPC; //import agentUtil.*; import com.adventnet.snmp2.agent.*; import Snmp2.*; import java.util.*; import org. omg. CosNaming. *; public class UserAgentSNMP implements SnmpAgentData, GetNextSupported { private UA.UserAgent myUserAgent; t // OID for MIB vars private static final long[] oid_taVisitorLUI = {1,3,6,1,4,1,60,99,5,2,0}; private static final long[] oid_uhaSessionEntry = {1,3,6,1,4,1,60,99,6,1,1}; private static final long[] oid_uhaSessionDD = {1,3,6,1,4,1,60,99,6,1,1,1}; private static final long[] oid_uhaSessionLUI = {1,3,6,1,4,1,60,99,6,1,1,2}; private static final long[] oid_uhaSessionTA = {1,3,6,1,4,1,60,99,6,1,1,3}; private static final long[] oiduhaSessionLoginTime = {1,3,6,1,4,1,60,99,6,1,1,4}; private static void raiseError ( String s) { System.err.println ("\n[UserAgentSNMP ERR]" + s); System.exit(-l); } private static void debug (int debug_level, String s) { if (debug_level <= Utility.upcDebugLevel) { System.out.println ("\n[UserAgentSNMP debug " + debugjevel + "]" + s); } } private SnmpVar getSessionTableNode(int sessionID, int columnID) { Strings; try{ if (columnID == 1) { debug(4, "getNextReqMesgO: 1 return Snmplnt(" + sessionID + ")"); return new SnmpInt(sessionlD); } else if (columnID == 2) { s = myUserAgent. uhaSessionLUI(sessionlD); debug(4, "getNextReqMesgO: 1 returnuhaSessionLUI(" + sessionID +"):" + s); return new SnmpString(s); } else if (columnID == 3) { s = myUserAgent. uhaSessionTA(sessionlD); debug(4, "getNextReqMesgO: 1 return uhaSessionTAf + sessionID + "):" + s); return new SnmpString(s); } else if (columnID == 4) { s = myUserAgent. uhaSessionLoginTime(sessionlD); debug(4, "getNextReqMesgO: 1 returnuhaSessionLoginTime(" + sessionID + "):" + s) return new SnmpString(s); 65 } else { raiseError("getNextReqMesg(): 1 Unexpected columnID-' + columnID); return new SnmpString(" 1 Bad tailOID"); } } catch (UA.UserAgentPackage. SNMPSessionlDInvalid e) { e.printStackTraceO; return new SnmpString("l SNMPSessionlDInvalid"); } } // Constructor public UserAgentSNMP() { debug(3, "ConstructorO called for UserAgentSNMP"); myUserAgent = Utility.findUserAgent("cs.ubc.ca"); } public String getReqMesg(long[] OID) { debug(3, "getReqMesg(): OID=" + Utility.oidToString(OID)); String retVal = null; if (Utility.oidCmp(OID, oidJaVisitorLUI, oid_taVisitorLUI.length)==0) { debug(4, "getReqMesg(): oidJaVisitorLUI"); retVal = myUserAgent.getSNMPTestVar(); } else if (Utility. oidCmp(OID, oiduhaSessionEntry, oid_uhaSessionEntry.length)==0) { try{ int sessionID = (int) OID[oid_uhaSessionID.length]; if (Utility.oidCmp(OID, oiduhaSessionID, oid_uhaSessioiuT).length)==0) { debug(4, "getReqMesg(): oid_uhaSessionID"); retVal = String. valueOf(sessionID); } else if (Utility. oidCmp(OID, oiduhaSessionLUI, oid_uhaSessionLUI.length)==0) { debug(4, "getReqMesg(j: oiduhaSessionLUI, sessionID=" + sessionID); retVal = myUserAgent.uhaSessionLUI(sessionlD); } else if (Utility.oidCmp(OID, oid_uhaSessionTA, oid_uhaSessionTA.length)==0) { debug(4, "getReqMesg(): oiduhaSessionTA, sessionfD=" + sessionID); retVal = myUserAgent.uhaSessionTA(sessionlD); } . • else if (Utility.oidCmp(OID, oiduhaSessionLoginTime, oid_uhaSessionLoginTime.length)==0) { debug(4, MgetReqMesg(): oid_uhaSessionLoginTime, sessionID=" + sessionID); retVal = myUserAgent.uhaSessionLoginTime(sessionlD); } else { debug(0, "getReqMesg(): Invalid node for uhaSessionTable :" + Utility.oidToString(OID)); retVal = "Invalid uhaSessionTable node"; } } catch (UA.UserAgentPackage. SNMPSessionlDInvalid e) { e.printStackTraceO; raiseError("Invalid sessionID: " + e.toStringO); } } else { debug(0, "getReqMesg(): Unknown OID : " + Utility.oidToString(OID)); 66 retVal = "Unknown OID"; } debug(4, "getReqMesgO: retVal=" + retVal); return retVal; } // getReqMesgO public String setReqMesg(long[] OID, Vector str) { return new String("TestClassSetRequestData: "+str. element At(0)); } // Modeled after /dsg/dsg3/vuong/AgentBuilder202/agentData/TrapForwardingTable.java. public SnmpVar getNextReqMesg(long[] OID, SnmpVarBind varbind) throws AgentNoNextObject, AgentSnmpException { debug(3, "getNextReqMesgO: begin," + "\n OID= "+Utility.oidToString(OID) + "\n uhaSessionEntry=" + Uhlity.oidToString(oid_uhaSessionEntry)); long[] tailOID = Utihty.airayDiff(OID,oid_uhaSessionEntry); debug(7, "getNextReqMesgO: tailOID2: "+ Utility.oidToString(tailOID)); if (tailOID. length == 1) { debug(4, "getNextReqMesgO: 1 ODD contains only nodelD without index"); int sessionID = 7777; sessionID = myUserAgent.nextSessionID(0); debug(4, "getNextReqMesgO: 1 nextSessionID=" + sessionID); varbind.oid = new SnmpOID(Utility.oidToString(OID) + "." + sessionID); debug(4,"getNextReqMesg(): 1 varbind.oid=" + varbind.oid); } catch (UA.UserAgentPackage.SNMPNoMorelndex e) { throw new AgentNoNextObject(); } try{ // ### VERY BAD HARD-CODING OF COLUMN NUMBERS #### if(tailOID[0]== 1) { debug(4, "getNextReqMesgO: 1 return Snmplnt(" + sessionID + ")"); return new SnmpInt(sessionlD); } elseif(tailOID[0]==2){ String s = myUserAgent.uhaSessionLUI(sessionID); debug(4, "getNextReqMesgO: 1 return uhaSessionLUI(" + sessionID + "):" + s); return new SnmpString(s); } elseif(tailOID[0]==3){ String s = myUserAgent.uhaSessionTA(sessionID); debug(4, "getNextReqMesgO: 1 return uhaSessionTA(" + sessionID + "):" + s); return new SnmpString(s); } elseif(tailOID[0]==4){ String s = myUserAgent.uhaSessionLoginTime(sessionlD); debug(4, "getNextReqMesgO: 1 return uhaSessionLoginTime(" + sessionID + "):" + s); return new SnmpString(s); } else { raiseError("getNextReqMesg(): 1 Unexpected tailOID[0]=" + tailOID[0]); return new SnmpString(" 1 Bad tailOID"); } 67 } catch (UA.UserAgentPackage. SNMPSessionlDInvalid e) { e.printStackTraceO; return new SnmpString("l SNMPSessionlDInvalid"); } } else if (tailOID.length == 2) { // OID contains nodelD along with index(here same as instance) debug(4, "getNextReqMesg(): 2 OID contains nodelD.index"); int nodelD = (int)(tailOID[0]); // Column # in the table, int index = (int)(tailOID[l]); //Row index. Our index has only one element. try { // Try go to the next node in the same index index = myUserAgentnextSessionlD(index); debug(4,"getNextReqMesg(): 2 nextSessionID=" + index); } catch (UA.UserAgentPackage. SNMPNoMorelndex e) { debug(4,"getNextReqMesg(): 2 No more index after" + index); nodeID++; // Last row of the column, so go to the next column try{ index = myUserAgent.nextSessionID(0); // Reset index to the smallest sessionID. } catch (UA.UserAgentPackage.SNMPNoMorelndex e2) { e2.printStackTrace(); raiseError("getNextReqMesg(): myUser. Agent.nextSessionlD(O) failed."); } } debug(7,"getNextReqMesg(): 2 nodelD-' + nodelD + " index-' + index); if (nodelD > 4) {// There are 4 columns in the table. debug(4, HgetNextReqMesg(): 2 End of table reached."); //long[] tmp = new long[oid_uhaSessionEntry.length]; //for (int i=0;i