UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Snmp for mobile computing Yin, Qing Vincent 1999

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1999-0137.pdf [ 4.39MB ]
Metadata
JSON: 831-1.0051606.json
JSON-LD: 831-1.0051606-ld.json
RDF/XML (Pretty): 831-1.0051606-rdf.xml
RDF/JSON: 831-1.0051606-rdf.json
Turtle: 831-1.0051606-turtle.txt
N-Triples: 831-1.0051606-rdf-ntriples.txt
Original Record: 831-1.0051606-source.json
Full Text
831-1.0051606-fulltext.txt
Citation
831-1.0051606.ris

Full Text

SNMP FOR MOBILE  COMPUTING  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  •  Acknowledgments  vii  Chapter 1 Introduction  1  1.1 The Idea 1.2 Thesis Objective and Contribution 1.3 Thesis Organization  1 1 2  Chapter 2 Background Knowledge 2.1  2.2 2.3 2.4 2.5  3  SNMP  3  2.1.1 Management Information Base (MLB) 2.1.2 The s c o t t y Package 2.1.3 Advent A g e n t B u i l d e r  3 4 5  Mobile IP CORBA SNMP Over CORBA Related Work  2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6  5 6 7 8  Subrata Mazumdar: SNMP/CORBA Gateway Proposal BelaBan: Multi-domain Management Proposal OrbyCom O p e n S N M P : an upcoming CORBA SNMP Manager CMU-SNMP Package: Classic Choice for C Language UCD-SNMP Package: Another Choice for C Language OutBack j S N M P : Java API for SNMP Manager  Chapter 3 Implement SNMP for Mobile IP 3.1 3.2  3.3  3.2.1 File Format...: 3.2.2 SNMP for Foreign Agent 3.2.3 The SNMP agent in s c o t t y  4.2 4.3  9 10 10 11 11 12 13  The MIB: RFC2006 Implementing SNMP Through a Scotty Agent  13 14  :  14 14 15  Performance Consideration  16  3.3.1 Mobile IP Program 3.3.2 File Size and Concurrent Access of i w i n _ s n m p . d a t . . . . . 3.3.3 Scotty scripts  16 16 17  Chapter 4 Implement Universal Personal Computing Over C O R B A 4.1  vi  UPC Architecture  19 -19  4.1.1 PCE Structure 4.1.2 Use Naming Service to Locate UHA 4.1.3 Event Sequence  20 20 21  Designing the IDL Implementing the User Home Agent  22 25  iii  4.4  4.3.1 Data Structure 4.3.2 Functional Specification  25 26  How CORBAservices  26  4.4.1 4.4.2 4.4.3 4.4.4 4.4.5  Affect the UPC Design and Implementation.  Naming Service Security Service Transaction Service Trader Service Persistence Service  26 27 28 28 29  Chapter 5 Implement SNMP for Universal Personal Computing 5.1  5.2  5.3 5.4  Defining  30  UPC-MIB  30  5.1.1 Highlights of UPC-MIB 5.1.2 Comparison with MIP-MIB  31 32  MIB to IDL Translation  33  5.2.1 Joint Inter-domain Management (XoJIDM) Standard..". 5.2.2 Object Management Group (OMG) Standard 5.2.3 Translation from UPC-MIB to IDL  34 35 35  Implementing Implementing  37 37  5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.5  the Enterprise  the SNMP Part of the IDL an Ad-hoc Agent-side SNMP/CORBA  Gateway  Advent AgentBuilder: Toolkit for Building SNMP Agent Implementing the Missing Piece of the Bridge The Class Constructor How the Gateway Works Implementing the Tree Traversal  How SNMP Affects  38 38 38 39 40  the UPC Design and Implementation  41  Chapter 6 Comparison of SNMP Implementations 6.1 6.2  Instrumenting Instrumenting  43  a MIB in the Traditional Way: Library Code the MIB for Mobile IP: A Separate Agent  6.2.1 Communicate Through a File 6.2.2 Pros and Cons 6.3  Instrumenting  6.3.1 6.3.2 6.3.3 6.3.4  a MIB in CORBA:  43 44  r. Gateway  Approach  Bi-directional Communication Lack of Availability Simplicity Location Transparency  Chapter 7 Conclusion and Future Work 7.1 7.2  Thesis Summary Future Work  45  46 46 46 47 48 48 48  Bibliography  53  Appendices Appendix Appendix Appendix Appendix Appendix  44 45  56 A B C D E  Old PCE-UA.IDL New PCE-UA.IDL UPC-MIB - Enterprise MIB for UPC UserAgentSNMP.Java - the SNMP/CORBA Gateway agent.tcl - scotty script for SNMP for Mobile IP  iv  56 58 60 65 69  List of Tables Table 5-1 Tree Walk of uhaSessionTable Table 5-2 Comparison of UPC-MTB and M1P-MIB  v  32 33  List of Figures Figure 2-1 Mobile IP Illustration Figure 2-2 OrbyCom SNMP/CORBA Gateway Figure 3-1 MIB for Mobile IP Figure 3-2 SNMP Agent in Scotty Figure 4-1 Universal Computing Concept Figure 4-2 Naming Context Hierarchy Figure 5-1 Agent-side SNMP-CORBA Gateway Figure 5-2 UPC-MIB Figure 5-3 uhaSessionTable in UPC-MIB  vi  6 11 13 16 20 20 30 31 34  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]). 1  No strong  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 B a c k g r o u n d K n o w l e d g e 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 I D ) such as  "1.3.6.1.2.1.44.1.1.1",  or symbolical names such as 3  "mipEntities".  To  access one or more MIB nodes, an SNMP manager issues an SNMP command such as SET, GET, G e t N e x t  and  Get Bulk,  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.44.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 scotty  [7] package to implement an SNMP agent for Mobile LP. Because it uses Tel  [1] scripting language, available.  scotty  is suitable for fast prototyping. Scotty is also freely  Those two features made  scotty  a popular package in the academic  community. The SNMP protocol stack is handled by needs to write a  scotty/Tel  scotty.  The application programmer  script to instrument a given MLB. Such an agent script 4  typically does the following: 1. Issue the  command  scotty  "snmp  session  -agent  ..." to put the  SNMP protocol stack on a port, typically the well known port 161. 2. Issue the  scotty  command  "mib  load  <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 command  "$s instance  <OID>  scotty  <TclVar>".  4. The value of the bound Tel variable will be fetched by  scotty  when a G E T  request is received for an O I D . 5. We can further bind Tel scripts to the G E T event of a O I D . If we do so, then scotty  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  agent, t e l  for Mobile IP is listed in Appendix E and discussed in  Section 3.2.3. 2.1.3  Advent  AgentBuilder  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 s c o t t y ) . 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  GET/SET  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  GET/SET  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  OpenSNMP  (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 Orbix . The following graph, obtained from OrbyCom's website, 1  describes  OpenSNMP'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.  Orbix (http://www.iona.com/products/orbix/index.html) is also a popular CORBA implementation besides our choice of VisiBroker. 1  10  gateway  Cork a M g r  shad&w objects  sett,.)  CORBAl CLieat  SNMP managed system SNMP  (1) badB.  :  SmajMaProxyFi  Ev*nlNotifi«r  Figure 2-2 OrbyCom SNMP/CORBA Gateway  2  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  jSNMP  (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). impressive. In particular, the little-known  I don't feel their product line-up is jSNMP  lacks in functionality compared to  many mature, traditional SNMP solutions (such as CMU-SNMP [10]). advantage of  j SNMP  The only  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 arefromthe 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 readsfromit.  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 faCOAStatus.142.103.14.170 faRegistrationRequired.0 mipEncapsulationSupported.0 mipEnable.O maAdvMinlnterval.142.103.14.170 maAdvAddress.142.103.14.170 maAdvertisementsSent.0  false active true 0 1 10 224.0.0.1 2  The file is actually dumpedfroma 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. export the values to the file i w i n _ s n m p . d a t .  14  We modified the program to  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  iwin_snmp. dat.  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 Our SNMP agent,  scotty  agent. t c l  MLB values off the file  [Appendix E], is written in scotty/Tcl. The agent reads  iwin_snmp. dat.  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.  agent. t c l  reads from the file  iwin_snmp. dat  and binds each value to the  corresponding MLB node. This read is performed periodically andfrequentlyto refresh the binding values. The default refresh interval is 10 seconds. 3. A SNMP manager sends a SNMP G E T request to the FA machine. 4.  scotty  receives the SNMP packet of the G E T request and extracts the  OID  from  the G E T request. 5.  scotty  looks up the binding value for the  agent. t c l  6.  scotty  OID.  The binding was done by  in step 2.  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  iwin_snmp.dat.  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 . If the size of i w i n _ s n m p .  d a t  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. agent. t c l  The scotty script  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 scotty  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 G E T 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 G E T 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 readfromthe file multiple times for one SNMP request. After weighing the pros and cons, we chose thefirstsolution. The interesting points of our implementation is better presented as a contrast to 17  implementation o f S N M P  over C O R B A  a n d that o f u s i n g a S N M P  t h a t i n C h a p t e r 6, a f t e r w e h a v e p r e s e n t e d S N M P o v e r  This concludes our implementation o f S N M P  library,  we  will  do  C O R B A .  for M o b i l e IP.  Next, we will  move  to a different 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  for  support o f user mobility.  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 him . The same also applies to address book mobility. This concept can be 3  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 U H A 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.  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. 3  19  •  :S..  ;  :  TAtl  download  <4  •  .  -  configuration  Figure 4-1 Universal Computing Concept 4.1.1  PCE Structure  T h e p e r s o n a l i z e d configurations o f a l l a p p l i c a t i o n s f o r a g i v e n user is c a l l e d the user's P e r s o n a l C o m p u t i n g E n v i r o n m e n t ( P C E . ) T h e U H A stores a l 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 r u n n i n g .  4.1.2 Use Naming Service to Locate UHA T o find the U H A f o r a g i v e n d o m a i n s u c h as " c s . u b c . c a " , 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.  Specifically, our  N a m i n g C o n t e x t hierarchy l o o k s l i k e this  ca  sfu  ubc  cs  ee  Figure 4-2 Naming Context Hierarchy W h e n it starts u p , the U H A uses N a m i n g S e r v i c e t o b i n d i t s e l f t o the c o r r e s p o n d i n g l e a f  20  node in the hierarchy. When a user logs in to a T A with his Logical User ID ( L U I ) 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 ,  [ { " c a " , " " } {"ubc",""} The  Pes",""}]  type field o f every Naming Component above is empty. The T A then looks up the  Naming Service to locate the desired U H A .  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 o f events is as follows. 1. The T A first provides a login screen. A user logs in with his email address such as userl@cs.ubc.ca. 2.  The T A w i l l relay the login request to the U H A running in the domain "cs.ubc.ca" and establish a connection to the U H A . T A locates the U H A through Naming Service as just described.  3.  T A downloads the user's PCE from U H A .  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 w i 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 w i l l run w i t h 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 people . IDL design is a relatively new 4  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. architecture. •  It also improved the object-orientation of the  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 P C E : : P r o f i l e . g e t ( )  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 Profile.get().  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: : P r o f i l e . So now we have eliminated two interfaces from the old LDL:  PCE:: Prof i l e  and  PCE:: Prof i l e F a c t o r y .  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 needed.  The flincation UA: : UserAgent. i n f ormLocation () is not  The IP address of the TA will be sent to UHA as a parameter in  UA: :UserAgent. l o g i n () .  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 i n t e r f a c e PCE::Service { a t t r i b u t e 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: interface Config { a t t r i b u t e s t r i n g c o n f i g N a m e ; // 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 };  typedef sequence<Config> ConfigSeq;  The old name ServiceObj is obscure. meaning  the  list  of  configuration 24  A better name would be ConfigSeq, items.  The  delimited  string  PCE:: S e r v i c e . ServiceObj  is  now  replaced  by  the  array  PCE : : S e r v i c e . Conf igSeq. The resulting PCE: : S e r v i c e is now i n t e r f a c e PCE::Service { a t t r i b u t e ConfigSeq c o n f i g S e q ; }  4.3 Implementing the User Home Agent After creating the DDL file, we run i d l 2 j a v a 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 C l a s s S e s s i o n 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 S e r v i c e objects.  Every  S e r v i c e 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 a v a . 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 s e s s i o n I D ) 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. features enhanced the development of UPC.  Some CORBA  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.  26  Naming Service is the  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. UA:  We can also eliminate the function  :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 Service , we had to include a 5  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. Transaction Service.  VisiBroker supports the  But it does not come with the free evaluation copy.  The  documentation is poor and there is nofreelyavailable 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  C h a p t e r 5 Implement S N M P f o r 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  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 Columbia . 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 3 or 4 university in the world to obtain an enterprise 6  rd  30  th  (ODD) of the root node of our UPC-MIB is {iso(l)  private(4)  enterprises(1)  ubc(60)  upcMIB(99)}  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:  upcSystem, upcTA  upcSystem  and  upcUHA.  upcTA.  and  upcUHA.  The Terminal Agent instruments  The User Home Agent instruments  upcSystem  and  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:  upcEntities  and  upcEnable.  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  read-write  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. 31  Our contact person  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 u h a S e s s i o n T a b l e 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 19 {1.3.6.1.4.1.60.99.6.1.1.4.102 {OCTET STRING} {Sep 21 20:51:59 1  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  p u t s $x prints  the result to the screen. Putting it in table form, the above result is:  Table 5-1 Tree Walk of uhaSessionTable uhaSessionLT) 101 102  uhaSessionLUI userl@cs.ubc.ca user2@cs.ubc.ca  uhaSessionTA columbia.cs.ubc.ca cascade.cs.ubc.ca  uhaSessionLoginTime Sep 21 20:50:12 1998 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 MIP-MIB mipSys t em: system-wide flags mipFA: Foreign Agent mipHA: Home Agent  UPC-MIB upcSys t em: system-wide flags upc TA: Terminal Agent upc UHA: User 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. •  mipSecurity  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/OpenNetwork 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.  uhaSessionTable  For example, the  following  MIB tree  which has 4 columns indexed by the column  defines  uhaSessionlD.  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 into : 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. 7  34  i n t e r f a c e u h a S e s s i o n E n t r y : SNMPMgmt::SmiEntry { c o n s t 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 S N l _ O c t e t S t r i n g uhaSessionLUI; r e a d o n l y a t t r i b u t e A S N l _ O c t e t S t r i n g uhaSessionTA; readonly a t t r i b u t e A S N l _ O c t e t S t r i n g uhaSessionLoginTime; };  Note again that the entire the table. There is no  interface  typedef  uhaSessionEntry  sequence  When an object is created, it is identified by  only represonts one row in  statement to represent an array of rows.  EntrylndexVarList  in order to know  which row it is representing. This raises a few questions. uhaSessionEntry  When it is created, how do we register a  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 <->  [ g a t e w a y ] <-> 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 a p p  It would require an effort of the scale of a Ph.D. thesis to program a generic, agentside SNMP/CORBA gateway. For the purpose of this thesis, we decided to do some adhoc 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 sessionID); s t r i n g uhaSessionTA ( i n long sessionID); s t r i n g uhaSessionLoginTime(in long sessionID); 1;  Note that our separate  interface.  MIB that way. The rows.  uhaSessionTable  is part of  interface  UserAgent,  not a  In other words, we extended the IDL. It is easier to instrument a  uhaSessionTable  is now broken down by columns instead of  Every column is represented by a function that returns the desired element  according to the index  sessionID.  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 string  as an example. corresponding  uhaSessionLUI(in  sessionID)  This function returns the L U I (e.g., "userl@cs.ubc.ca") of the  sessionID.  ClassSession  long  object by  The algorithm is simple. sessionID  The function retrieves the  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 .  class is attached to the nodes and  uhaSessionID,  uhaSessionLoginTime  j ava  listed in Appendix D. That  uhaSessionLUI,  uhaSessionTA  in UPC-MIB. That is, it is attached to the 4 columns of  uhaSessionTable.  5.4.3  The Class Constructor The class constructor of  UserAgentSNMP  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  UserAgent,  not in a separate object.  We use CORBA Naming Service to find the  UserAgent  for a given domain like  "cs.ubc.ca". This is similar to the way a TAfindsthe UHA as described in Section 4.1. 38  In fact, they both call the same user-defined function public S t a t i c 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  •  .101.  AgentBuilder determines that the Java class U s e r A g e n t SNMP is associated with the requested OID.  •  AgentBuilder calls U s e r A g e n t S N M P . g e t R e q M e s g ( l o n g [ ]  to retrieve  OID)  the value for the node. To instrument a MIB variable, a user-defined Java class like UserAgentSNMP  must implement the Java interface g e t R e q M e s g  ().  The  interface is mandated by AgentBuilder. Our implementation of getReqMesg.() does the following. •  Our U s e r A g e n t S N M P doesn't know the value for u h a S e s s i o n L U I .  101.  That  information is given by the following segment of IDL. i n t e r f a c e UserAgent { s t r i n g uhaSessionLUI(in  long s e s s i o n I D ) ;  }  In the object constructor, our U s e r A g e n t S N M P already obtained the reference to the 39  UserAgent.  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 UserAgent, •  and thus bridges the gap between SNMP and CORBA.  UserAgent. uhaSessionLUI  () 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. application programmer.  It puts too much burden on the  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 public  SnmpVar  getNextReqMesg(long[]  O I D , ...)  for the class UserAgentSNMP. The function takes in the O I Dfroma 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  will send a  getnext  GetNext  g e t N e x t R e q M e s g () OID  and  packet to AgentBuilder. AgentBuilder then calls our function which determines that  "userlgcs .ubc. ca"  uhaSessionLUI  The code for 5.5  uhaSessionLUI  from  scotty  uhaSessionLUI  is the value for that  OID.  .101 is the next valid  Note that the original  OID  is not a valid MLB object instance.  g e t N e x t R e q M e s g ()  is listed in Appendix D.  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 C o m p a r i s o n 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,  transmits the value out in an SNMP packet. If all applications  scotty  write to the file in the same format,  scotty  becomes a generic agent. It handles SNMP  protocol, and looks up the value from the file indexed b y 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  scotty  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 G E T requests. It is difficult to handle S E T requests. When  scotty  receives a  SET  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 orfreqentlyread 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. G E T 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 6.3.2  scotty  solution.  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 agentside 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  scotty  solution, our gateway acts like  Context hierarchy is like the file used in the  scotty  46  solution.  scotty.  The Naming  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 i p l . Another example would be to define a "reboot" node in the U P C 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 C O R B A . 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 U H A , 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. management in a traditional database management system.  50  It is like the transaction  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 afirst-yeargraduate 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/IPbased Internets, Prentice Hall, 1991.  [3]  William Stallings, SNMP, SNMPv2 and RMON - Practical Network Management, 2 Edition, Addison-Wesley, 1996. nd  [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 ofMIB 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, O M G Document # telecom/98-04-04, April 1998, http://www.bell-labs.com/user/mazum/recent_work.html http://www.belllabs.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  // File  PCE-UA.IDL  PCE-UA.idl  module PCE { typedef typedef typedef typedef typedef typedef typedef typedef typedef typedef  string string string string string string string string string string  ServiceName; ServiceObj; ServiceTypeName; Constraint; Preference;, PolicyName; PropertyName; PolicyValue; PropertyValue; HpropertyValue;  enum PropertyMode { PROP_NORMAL, PROP_READONLY, PROP_MANDOTORY, PROP_MANDO TOR Y_READONL Y };  enum ObjectRefType { APPLI_OBJECT, APPLI_CONFIG, }; struct  HardwareCapf string Hname; HpropertyValue  typedef struct  value;  sequence<HardwareCap>HardwareCapSeq; Property { PropertyName PropertyValue PropertyMode  }; typedef struct }; typedef struct  PPLI_RESOURCE_FILE  sequence Policy{ PolicyName PolicyValue  name; value; mode; <Property>  PropertySeq;  name; value;  sequence<Policy>PolicySeq; Trade{ ServiceTypeName type; Constraint constr; // Preference pref; PolicySeq policies; PropertySeq Properties;  // service type name constraint // which offers return first // all property infomation // 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 sequence<Service>ServiceSeq;  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 ////////////////////////////// module UA {  VA  ///////////////////////////////////  struct Token{ string low; string high;  if  interface UserAgent {  boolean authenticate (in string boolean tokenauthent (in string  LUI, in string LUI, in string  password) ; 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  // File  New  PCE-UA.IDL  PCE-UA.idl  ///////////////////////////// module PCE { typedef typedef typedef typedef typedef  string string string string string  typedef string typedef string typedef string  module PCE  ////////////////////////////  ServiceTypeName; Constraint; Preference; PolicyName; PropertyName; PolicyValue; PropertyValue; 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 sequence<HardwareCap>HardwareCapSeq; struct Property { PropertyName name; PropertyValue value; PropertyMode mode; }; typedef sequence <Property>  PropertySeq;  struct Policy{ PolicyName name; PolicyValue value; }; typedef sequence<Policy>PolicySeq; struct Trade{ ServiceTypeName Constraint Preference PolicySeq PropertySeq };  type; constraint; preference; policySeq; propertySeq;  interface Config { attribute attribute  string string  configName; filePath; 58  // which offers return first // search policy // all property infomation  };  typedef seqaence<Config> 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<Service> 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  LUI  void  raises (UPCAuthenticationFailure); (in AuthentToken token);  r  in string  password, in  string  TAaddr) logout  PCE::ServiceSeq string raises  getServiceSeq raises  (in AuthentToken token) (UPCAuthenticationFailure);  downloadFile (in AuthentToken token, in string (UPCAuthenticationFailure);  void uploadFile(in  AuthentToken token, in string  filename)  filename,  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  in  strin  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  upcMIB OBJECT IDENTIFIER —  — — — — — ::= { enterprises ::= {  60 }  ubc 99 }  Groups under upcMIB  upcSystem  OBJECT IDENTIFIER  upcTA OBJECT IDENTIFIER  : :=  ::= { upcMIB 1 } { upcMIB 5 }  — Terminal Agent upcSystem: : Group upcUHA OBJECT IDENTIFIER = { upcMIB 6 } upcEntities OBJECT-TYPE SYNTAX BITS { terminalAgent ( 0 ) , userHomeAgent ( 1 ACCESS STATUS  read-only 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). Therefore bit .0 and bit 1 are set to 1 for this object." r  { • upcSystem upcEnable SYNTAX ACCESS STATUS  1 }  OBJECT-TYPE INTEGER { enabled ( 1 ) read-write . mandatory  disabled  DESCRIPTION • "Indicates whether the UPC protocol enabled for the host." ::= { upcSystem  (2 ) }  should be  2 }  -- User Home Agent taLogin  OBJECT IDENTIFIER  uhaSessionTable  OBJECT-TYPE 60  ::= { upcTA  3  )  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 INDEX { uhaSessionID } ::= { uhaSessionTable 1 }  binding  list."  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 REFERENCE rr rr  61  session. "  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 ::-  {  taLogin  attempts since boot."  2 }  OBJECT-TYPE taReasonOther Counter SYNTAX read-only ACCESS mandatory STATUS DESCRIPTION "Total number of failed login attempts by either terminal agent or user home agent --reasons other than Unreachable and AuthenticationFailure." ;:= {  taLogin  4 }  taReasonUnreachable SYNTAX Counter ACCESS read-only STATUS mandatory  OBJECT-TYPE  DESCRIPTION "Total number of login unreachable." ;;= {  taLogin  denied -- user home agent  12 }  taReasonAuthenticationFailure SYNTAX Counter ACCESS read-only STATUS • mandatory  OBJECT-TYPE  DESCRIPTION "Total number of login denied by user home agent — failed authentication." ::= { uhaLogin  taLogin  15 }  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  63  OBJECT-TYPE  SYNTAX ACCESS STATUS  Counter read-only mandatory  DESCRIPTION "Total number of Login Requests denied by home agent — reason unspecified (Code 128) . " ::= { uhaLogin  5 }  uhaMNAuthenticationFailure SYNTAX Counter ACCESS read-only STATUS • mandatory  OBJECT-TYPE  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 staticfinallong[] oid_uhaSessionEntry = {1,3,6,1,4,1,60,99,6,1,1}; private staticfinallong[] oid_uhaSessionDD = {1,3,6,1,4,1,60,99,6,1,1,1}; private staticfinallong[] oid_uhaSessionLUI = {1,3,6,1,4,1,60,99,6,1,1,2}; private staticfinallong[] oid_uhaSessionTA = {1,3,6,1,4,1,60,99,6,1,1,3}; private staticfinallong[] 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, getReqMesg(): oid_uhaSessionLoginTime, sessionID=" + sessionID); retVal = myUserAgent.uhaSessionLoginTime(sessionlD); M  } 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. elementAt(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, getNextReqMesg(): 2 End of table reached."); //long[] tmp = new long[oid_uhaSessionEntry.length]; //for (int i=0;i<oid_uhaSessionEntry.length;i-H-) // Copy the OID // tmp[i] = oid_uhaSessionEntry[i]; //tmp[unp.length-2]-H-; // Increment the 2nd-last element (parallel to uhaSessionEntry.) //debug(4, "getNextReqMesg(): 2 tmp="+Utility.oidToString(tmp)); //varbind.oid = new SnmpOID(Utility.oidToString(tmp)); throw new AgentNoNextObject(); } else {// There are still more columns to go. So increment to the next column. varbind.oid = new SnmpOID(Utility.oidToString(oid_uhaSessionEntry)+ "." + nodelD + "." + index); debug(4,"getNextReqMesg(): 2 varbind.oid=" + varbind.oid); H  } return getSessionTableNode(index, nodelD);  } //Shouldn't get here! raiseError("getNextReqMesg(): Unexpected tailOID.length=" + tailOID.length); return null;  68  Appendix  E  agent.tcl - scotty script for SNMP for Mob ile IP  set dir [glob ~vyin/'thesis] set infofile /root/MobilelP/iwin-snmp.dat mib load $dir/mib/rfc2006.mib set mibPattern {*([* set lastModifiedTime 0  ]+)[ ]+(["  ]+)$}  set s [snmp session -port 1709 -agent "" ] #$s configure -agent [interp create -safe] puts [$s configure] proc debug { msg } { puts $msg }  proc reloadMib { s } { debug "Running reloadMib $s ..." global mibVars infofile mibPattern lastModifiedTime set newModifiedTime [file mtime $infofile] if { $lastModifiedTime == $newModifiedTime } { debug "\tfile not modified -- no need to reload" return } set lastModifiedTime $newModifiedTime foreach name [array names mibVars] { unset mibVars ($name) } set f [open $infofile ] while {1} { gets $f line if [eof $f] break # debug "line:$line\$" if { ![regexp $mibPattern $line junk objName objValue] continue }  # debug "objName=$objName objValue=$objValue\n" $s instance $objName mibVars($objName) $objValue }  close $f }  #  main ()  reloadMib $s job create -command "reloadMib  69  $s" -interval 5000-  }{  71  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051606/manifest

Comment

Related Items