SNMPFS

An SNMP Filesystem

Rui Pedro Lopes

1,2

, Tiago Pedrosa

1,2

and Luis Pires

Polytechnic Institute of Braganc¸a, Braganc¸a, Portugal

IEETA, University of Aveiro, Aveiro, Portugal

Keywords:

Network Management, SNMP, File system.

Abstract:

The intensive operation of constantly growing, heterogeneous networks is a challenging task. Besides the

increase in size and complexity, data networks have become a critical factor for the success of many organi-

zations. During the last decade, many network management architectures where developed and standardized,

aiming at the deﬁnition of an open environment to control and optimize its operation. Many of these archi-

tectures use speciﬁc protocols and specialized tools, to allow remote monitoring and conﬁguration of network

equipment and computational platforms.

One of the best well known paradigms of human-computer interaction is the ﬁle concept and the associated

ﬁle system. Files have been around since early days in the personal computer industry and users are perfectly

comfortable associating the work produced in applications to be stored in medium.

In this paper we propose a ﬁle system interface to network management information, allowing users to open,

edit and visualize network and systems operation information.

1 INTRODUCTION

A ﬁle system is a database typically storing large

blocks of information. The information is stored in

the form of ﬁles, structured as a hierarchy of directo-

ries. Each entry in the ﬁle system, including directo-

ries and ﬁles, is characterized by a limited group of at-

tributes (instant of creation, instant of the last access,

instant of the last change, permissions, owner, group).

This paradigm is, perhaps, one of the best well known

mechanism for storing information, available in sev-

eral operating systems as well as in some embedded

devices, such as PDAs, mobile phones and even digi-

tal cameras.

Usually, ﬁles are stored locally in persistent mem-

ory, such as hard-disks or memory cards. It is also

common, particularly in enterprises, to use network

ﬁle systems to store ﬁles in a remote server, accessed

through a special protocol like NFS (Shepler et al.,

2000) or SMB. In this situation, the network server

exports part of the local ﬁle system to a set of selected

clients, allowing them to remotely access ﬁles and

directories. However, this centralized, single server

approach, suffers some scalability issues related to

throughput, capacity and fault tolerance.

Distributed ﬁle systems are designed to improve

scalability and fault tolerance by transparently bal-

ancing the access between servers. It provides the

same view to every client and is responsible for main-

taining coherence of data through distributed locking

and caching (Ghemawat et al., 2003; Howard et al.,

1988; Anderson et al., 1996).

Yet another paradigm, cloud storage systems,

such as Dropbox

, transparently synchronize the lo-

cal copy of data with a remote datacenter, allowing

user access to personal and shared ﬁles anytime, any-

where.

Based on this paradigm, we considered the possi-

bility of accessing network management information

as a set of virtual ﬁle systems. Network resources,

usually accessed through SNMP (Harrington et al.,

2002), COPS (Durham et al., 2000), or other network

management protocol, are seen as remote shares, to

be mounted in a regular workstation ﬁle system and

the instrumentation and conﬁguration information ac-

cessed as regular ﬁles.

The nature of the information as well as the pur-

pose of this SNMP File System (SNMPFS) is radi-

cally different from traditional distributed ﬁle systems

(DFS). This makes the current requirements different

http://www.dropbox.com

Lopes R., Pedrosa T. and Pires L..

SNMPFS - An SNMP Filesystem.

DOI: 10.5220/0004003000660073

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 66-73

ISBN: 978-989-8565-10-5

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

of traditional DFS. First, distributed ﬁle systems are

used to store ﬁles belonging to one or more users. In

a network management scenario, the information is

generated both by network resources and users. The

former is used for instrumentation and the later is used

for conﬁguration.

Second, the content of the majority of network

management backed ﬁles is constantly changing, be-

cause of the dynamic nature of network parameters.

As an example, consider a value representing the

number of transmitted packets or a value represent-

ing CPU load. In regular ﬁle systems, used to store

personal and application ﬁles, entries seldom change.

This allows better cache hit rates than in the former

situation.

Third, network management ﬁles are very small,

resulting from the parameters they represent. Fre-

quently, a single int is used and, some times, a small

table of values is sufﬁcient.

Fourth, the whole SNMPFS is composed of several

network services and resources, such as routers, ﬁre-

walls, web servers, and so on. Each resource exports

the information resulting from the instrumentation of

working parameters thus playing a part in a poten-

tially huge cluster of distributed ﬁle systems.

Fifth, faults are usually frequent, resulting from

connectivity problems, hardware failures, human ac-

tion and others. The system should cope with this

issues, by recovering when possible and replicating

when necessary.

2 FILE SYSTEM DESIGN

The goal of the SNMPFS is to unify around a unique

name space all of the enterprise network management

agents. For concept proving, we are using SNMP

agents, since they are common in organizations and

widely implemented by network devices. This ap-

proach allows integrating the tree of management ob-

jects of distinct SNMP agents in a single ﬁle system.

Resuming, the goals of this approach are the follow-

ing:

• allow the use of simple ﬁles and directories han-

dling tools (cd, cp, cat, ...);

• allow to consult and change the values through

simple tools (ﬁle redirection, text editors);

• allow the creation of pipes:

cat sysUpTime | toxml | mail --s

‘‘sysUpTime’’ admin@host.com;

• allow using ofﬁce tools, such as Calc or Excel, to

view and alter tabular information;

Workstation

Network

SNMP

agent

SNMP

agent

...

SMB share

SNMPFS SNMPFS SMB

NTFS

Virtual File System

APP APP APP APP APP APP

Figure 1: SNMPFS global architecture.

• allow reducing the complexity of the management

system.

The information generated by each SNMP agent

is accessed through a speciﬁc ﬁle system (SNMPFS),

working as a gateway between the regular ﬁle opera-

tions (open, read, write, append, close, . . . ) and

SNMP commands (Figure 1).

As other ﬁle systems, like Server Message Block

(SMB), also known as Common Internet File Sys-

tem (CIFS), to access SMB (Windows) shares across

a network or NTFS for local storage, applications

access data through a uniform layer (VFS - Virtual

File System). Speciﬁc ﬁle system details are of the

responsibility of each ﬁle system technology (SN-

MPFS, SMB, NTFS and so on). As a result, all the

information is stored under the same naming tree.

2.1 Topology

The system topology is straightforward: on one side,

several SNMP agents, associated with diverse enter-

prise resources; on the other side, one or more work-

stations mount the agents’ information through the

SNMPFS (Figure 2).

Figure 2: Simpliﬁed topology.

It is possible that two or more workstations mount

the same agents in its local ﬁle system. For read oper-

ations this does not present any problem. However,

SNMPFS-AnSNMPFilesystem

for update operations it is possible that potentially

many processes try to change the same value.

2.2 Locking

In conventional distributed ﬁle systems, ﬁle locking

is essential for coordinating access to shared informa-

tion among cooperating processes. If multiple pro-

cesses are writing to the same ﬁle it is necessary

to regulate the access through some kind of locking

mechanism. In SNMPFS, locking is performed by the

agent, in accordance with the managed object deﬁni-

tion, since SNMP agents may also be updated by net-

work management applications concurrently. Some

MIBs provide a mechanism to regulate concurrent ac-

cess. The Expression MIB (Kavasseri, 2000), for ex-

ample, has tables with a special column used to in-

stantiate the row – RowStatus (McCloghrie et al.,

1999b).

2.3 Security

SNMP is inherently insecure. Although true for the

versions 1 and 2c, SNMPv3 present a modular se-

curity architecture based on cryptographic protocols

and algorithms. It is mandatory that SNMPv3 im-

plementations support the HMAC-MD5-96 protocol

for authentication. They can also support the HMAC-

SHA-96 for authentication and the CBC-DES for pri-

vacy (Blumenthal and Wijnen, 2002). More recently,

a new privacy protocol was added. (Blumenthal et al.,

2004) describes the Advanced Encryption Standard

(AES) for SNMPv3 in the SNMP User-based Secu-

rity Model which can be used as an alternative to the

CBC-DES.

The SNMPv3 security service provides data in-

tegrity, data origin authentication, data conﬁdential-

ity and message timeliness as well as limited replay

protection. It is based on the concept of a user, identi-

ﬁed by a userName, with which security information

is associated. In addition to the user name, an authen-

tication key (authKey) is shared between the commu-

nicating SNMP engines, ensuring authentication and

integrity. A privacy key (privKey), also symmetric,

ensures conﬁdentiality.

Complementing the communication security, the

SNMPv3 model also provides access control through

a view-based access control model (Wijnen et al.,

2002). This model grants or denies access to MIB

portions (view subtrees) according to the predeﬁned

conﬁguration and the current user permissions.

The security details for SNMPv3, either for

authentication, integrity, conﬁdentiality and ac-

cess control, dictates the security functions for the

SNMPFS. We have to pass to the ﬁle system the

authentication and the access control required by

the SNMP model. The authentication problem is

performed by the system when mounting the ﬁle

system. A similar approach is followed for NFS or

SMB shares:

mount -t smb //server/share /mnt -o

username=aUser,password=xxx.

If the server recognizes the username and password,

the host is allowed to access the ﬁle system and a

user ID (uid) is associated with it.

Access control is enforced by ﬁle permissions. In

Unix, each ﬁle has a set of permissions (read, write,

execute) for the ﬁle owner, group and others. For ex-

ample, the permissions

-rwxr-x---

gives the owner the possibility to read, write and ex-

ecute the ﬁle, the group to read and execute and no

other user can read, write or execute.

SNMPFS translates each ﬁle permission to the

View-based Access Control mechanism of the SN-

MPv3.

2.4 Attributes

File system entries, such as ﬁles or directories, are

characterized by a set of attributes which describes

their fundamental aspects, such as size, date, permis-

sions, name and others. The name and number of at-

tributes is typically static, meaning that it is not pos-

sible to add or remove further information to each ﬁle

system entry latter on.

An attribute which is necessary to better describe

the data types and the structure of an SNMP agent is

the MIB tree it implements. The MIB tree is described

in a set of MIB ﬁles which contain each node name,

data type, restrictions and role. With this information,

the SNMPFS can present to the user a more meaningful

set of ﬁle names as well as ﬁle types (a table, a string,

an int, etc). In particular, this information is valuable

for tables, which the SNMPFS exports as Coma Sep-

arated Values (CSV) format and can be opened and

edited by a spreadsheet, such as Microsoft Excel or

OpenOfﬁce Calc.

To be able to access the meta-information about

management data, the SNMPFS has the possibility to

load MIB ﬁles from a speciﬁc directory. This infor-

mation will allow the ﬁles to have a more meaningful

name as well as adapting the content to the nature of

the information it stores.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

3 IMPLEMENTATION DETAILS

The SNMPFS implements a gateway between regular

ﬁle system access primitives and SNMP commands.

Generally, ﬁle systems are implemented at kernel

space, however, we chose to implement the ﬁle sys-

tem in userspace to facilitate the development and test

process. We used FUSE (FUSE, 2011), a stable and

well known API for ﬁle system development.

The SNMP information is somehow austere,

mainly because of the Object IDs (OIDs) that it uses

to identify each managed object. The OID is a se-

quence of integer values, separated by a ‘.’ (dot):

1.3.6.1.2.1.1.1.0. This sequence deﬁnes a path in the

agent’s tree of objects, referring to a speciﬁc value

(Figure 3). This path, for example, points to a speciﬁc

object, which refers to a value resulting from device

instrumentation.

1 2

1 2 3

3 4

"Joe" "Somewhere" 1234

1.2.2.1.0 1.2.2.2.0 1.2.2.3.0

Figure 3: Scalar values organization in the agent.

In Figure 3, for example, the OID 1.2.2.1 refers to

the lower left node in the tree. This node is associ-

ated with a speciﬁc value, a scalar, in this case, which

contains the string “Joe”. The scalar is viewed as an

additional node, a leaf, and is referred by adding a ’.0’

to the OID.

Each object, the circles in the ﬁgure, has a set of

attributes or meta-information, which allows the user

to get the semantics of the value (what does “Joe”

stands for). The attributes, as well as the overall struc-

ture, is described in a ﬁle, called a Management Infor-

mation Base (MIB), which associates a descriptive,

meaningful, name to each object and further describes

the data type, access restrictions, OID structure and

others. From the user perspective, this also allows

mapping the sequence of integers to a short name: it

is easier to refer to each object by the short name,

instead of the OID (get sysDescr, instead of get

1.3.6.1.2.1.1.1.0).

After parsing the MIB ﬁles, the SNMPFS performs

this mapping, storing the meta-information to im-

prove the information provided to the user by the ﬁle

system. The OID in the sequence of integers format

will only be used when the MIB is not available.

3.1 The MIB Parser

As mentioned above, the MIB structure is important

to SNMPFS to provide a more useful and meaningful

view of the ﬁle system. MIB ﬁles are written in a

subset of the Abstract Syntax Notation One (ASN.1),

called “Structure of Management Information” (Mc-

Cloghrie et al., 1999a). The MIB must be parser so

that the tree, nodes, types and objects extracted. We

are using Marser (Marser, 2007), an API to parse SMI

(v1 and v2).

Moreover, the information from the MIB allows to

identify tabular information, which further helps the

ﬁle system to present the information to the user in

a more manageable way. In this case, tables will be

available is CSV format, allowing the user to read and

modify it using a spreadsheet application.

Tables are represented as a further extension to the

OID tree (Figure 4). As in the previous case, where

each scalar is retrieved from a leaf, tabular values are

retrieved from several leafs, hanging on the OIDs that

represent the columns (in the ﬁgure, the table is re-

ferred with the OID 1.2.3, which has the columns

1.2.3.1 and 1.2.3.2).

1 2

3 4

192.168.1.1 192.168.100.254

192.168.64.12

193.136.34.10

192.168.100.253

192.168.100.252

Figure 4: Tabular values organization in the agent.

One or more of the columns are the index, which

SNMPFS-AnSNMPFilesystem

allows to retrieve the rows in the table. So, to

get the ﬁrst value of the table, it is necessary to

issue: get 1.2.3.2.192.168.1.1, which yields

192.168.100.254.

3.2 Files

When dealing with agents with an unknown structure,

the user usually has to explore the management in-

formation tree, retrieving all the information that the

agent stores. This operation is called ‘walk’, because

it allows to visit all the places “hidden” in the agent.

The SNMPFS has a special ﬁle which allows doing pre-

cisely this. The ﬁle, called walk.txt, lists all the

managed objects retrieved as the result of a ’walk’

operation. By simply opening this ﬁle in a text editor,

the user will be able to immediately see the objects

the SNMP agent implements:

s y s D e s c r ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 1 . 0

s y s O b j e c t I D ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 2 . 0

sysUpTime ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 3 . 0

s y s C o n t a c t ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 4 . 0

sysName ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 5 . 0

s y s L o c a t i o n ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 6 . 0

s y s S e r v i c e s ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 7 . 0

sy sORLa st Chang e ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 8 . 0

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 1

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 2

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 3

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 4

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 5

sysORID ; 1 . 3 . 6 . 1 . 2 . 1 . 1 . 9 . 1 . 2 . 6

. . .

With the information obtained in the ﬁle, the user

can conﬁgure the ﬁle system, describing which ﬁles

should be available and what is the name they should

have. The conﬁguration is written is XML and de-

ﬁne all the aspects of the ﬁle-system: the agent’s ad-

dress, access credentials, MIBs to load, which nodes

to show and where to mount:

</mibs>

<snmp a d d r e s s = ” 1 9 2 . 1 6 8 . 1 . 1 ” p o r t =” 161 ”

v e r s i o n =” v 2c ” c om mu ni ty =” p u b l i c ” />

< s c a l a r l a b e l =” sysUpTime ” />

< s c a l a r l a b e l =” s y s D e s c r ” />

<t a b l e oid = ” . 1 . 3 . 6 . 1 . 4 . 1 . 6 3 . 5 0 1 . 3 . 2 . 2 ”

f i l e =” myTable”>

</ t a b l e >

</ e n t r i e s >

</ d e vic e >

The previous conﬁguration ﬁle will result in the

appearance of 5 ﬁles in the ‘tmp’ directory – two ta-

bles, two scalars and the walk.txt (Figure 5).

Figure 5: Screenshot of an SNMPFS directory.

3.3 Values and Tables

Each ﬁle representing a scalar simply has to get the

value from the agent each time it is read. In the pre-

vious conﬁguration ﬁle, the scalar ’sysUpTime’ and

’sysDescr’ show as ﬁles, containing the information

from the agent located in 192.168.1.1.

Tables, because of the tree like structure, require

more processing. The algorithm we follow is:

r e a d c o n f i g u r a t i o m f i l e ;

f o r e a ch e n t r y

i f i s t a b l e

r e a d c ol um ns ;

i f co lu mn s empty

r e a d c ol um ns f rom MIB ;

f o r e a ch col umn

w h i l e h as more l e a f s

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

g e t l e a f ;

s t o r e i n row , c ol umn ;

end ;

The fetch of values and store in row and column

format allows to build the content around the CSV

format, that can be manipulated by a spreadsheet ap-

plication (Figure 6).

4 USE CASES

In system and network management, the administra-

tors are used to create scripts to automate some of the

typically repetitive and/or boring maintenance activ-

ities. Many of this scripts work by reading, writing

and updating conﬁguration ﬁles, altering the way dae-

mons and services work (such as e-mail, HTTP, SSH,

. . . ). The SNMPFS enables mapping SNMP informa-

tion to a ﬁle system structure, thus contributing to

the integration of monitoring, conﬁguration and ac-

counting processes. In other words, the SNMPFS will

foster administrators to develop new tools easier and

to use the same tools in different scenarios because

of the transparency and integration of the ﬁle system

paradigm.

The extension of the ﬁle system with ﬁles re-

lated to instrumentation and conﬁguration informa-

tion from network devices will further alleviate the

burden. By mounting several devices in the same ﬁle

system, where each directory represents a different

agent, enables the administrators to be able to make

queries or change values on all the equipment, just by

browsing the ﬁle system.

4.1 Monitoring

Monitoring operations require the user to retrieve,

process, analyse and visualize instrumentation infor-

mation. For example, several parameters can be

queried to get the status of remote hosts (Table 1).

Table 1: Monitoring examples.

Query Object Type

the number of users on a system hrSystemNumUsers scalar

the bytes transmitted ifInOctets;ifOutOctets table

the storage areas hrStorageTable table

the processor load hrProcessorLoad table

Other common operation is to build the topology

map of the network, representing the connections and

hosts structure. This is done with the help of the

IP forwarding table, maintained in the switches and

routers. Each table gathers the MAC addresses in

each port, allowing the correlation of addresses into

building a visual representation of the network topol-

ogy. By replicating this information (a simple copy

will do), will enable to create a view of the network a

speciﬁc times.

4.2 Conﬁguration

One challenge on integrated management of networks

is how to apply policies that are transversal to more

that one equipment. The integration of several SNMP

agents in the same ﬁle system can enable the admin-

istrator to create sound scripts to apply the policy.

In complement to these use cases, one that is be-

ing currently addressed is the use of version control

systems for maintaining snapshots of SNMP agents’

conﬁguration. Each type and version of equipment

has different ways for manipulating their conﬁgura-

tions, because of the MIBs they implement. With the

SNMPFS, administrators can make use of already ac-

cepted solutions for version control. A Distributed

Version Control, such as GIT

enables to have a mas-

ter repository for each agent as well as a local reposi-

tory in the management stations.

The ﬁrst mount of the agent, a new repository is

created and the ﬁles are added, tagged as the initial

commit. This local repository is pushed to the mas-

ter repository, which will work as another, more gen-

eral, versioning peer. The master is conﬁgured for

post commit routines, that will update the directory

where the agent is mounted. The master will apply the

changes in the ﬁle system, conﬁguring the equipment

accordingly and changing the properties that enables

the updated of the conﬁgurations. This enables that

different administrators can work on their stations us-

ing the repositories for changing conﬁgurations and

the push the conﬁgurations to the master that will

change the agents’ status. Moreover, using tags to

identify speciﬁc conﬁguration versions allows to eas-

ily change form one conﬁguration to another.

4.3 Scheduling Operations

Modern operating systems have tools that enables

users to schedule jobs (commands or shell scripts) to

run periodically at certain times or dates. One such

tool, popular un Unix-like operating systems, is cron,

used to automate system maintenance or administra-

tion. Proper conﬁgured cron jobs allows to activate

some options at some time on agents, for example, to

shutdown several devices at a speciﬁc time. More-

over, it also allows to watch ﬁles for speciﬁc val-

ues for, for example, triggering some conﬁguration

change or event (send emails, executing commands).

http://git-scm.com/

SNMPFS-AnSNMPFilesystem

Figure 6: Editing the ifTable with a spreadsheet.

5 CONCLUSIONS

Accessing and updating information is a frequent op-

eration in virtually any activity. Because of the evolu-

tion of computing platforms, the electronic informa-

tion is associated with the concept of ﬁles, residing

in a generic storage mechanism. Usually, the ﬁles

are updated by general use applications, such as of-

ﬁce suites or drawing editors. Often, the content is

in plain text, allowing standard editors to retrieve and

update the information.

Because of the ubiquity of ﬁles, modern operat-

ing system have an extensive set of tools to deal with

the maintenance of ﬁles, such as renaming, creating,

copying, backing up and restore, and so on. In en-

terprises, work ﬁles are typically stored in network

storage, made available through a virtual ﬁle system

in local desktop computers.

Network and system management (NSM) is a ma-

jor concern for maintaining the system in good work-

ing conditions. Many of the tasks involved in NSM

require monitoring and updating information result-

ing from instrumentation procedures in applications,

services and equipment. The paradigm in traditional

NSM models rely on client-server protocols, through

special purpose applications.

The SNMPFS, proposed in this paper, integrates

network devices, applications and service manage-

ment in a common platform and paradigm – the ﬁle

system. In this way, network management operations

can beneﬁt from the existing powerful operating sys-

tem tools to monitor, update instrumentation, conﬁg-

uration and monitoring information.

REFERENCES

Anderson, T. E., Dahlin, M. D., Neefe, J. M., Patterson,

D. A., Roselli, D. S., and Wang, R. Y. (1996). Servless

network ﬁle systems. ACM Transactions on Computer

Systems, 14(1):41–79.

Blumenthal, U., Maino, F., and McCloghrie, K. (2004). The

Advanced Encryption Standard (AES) Cipher Algo-

rithm in the SNMP User-based Security Model. RFC

3826 (Proposed Standard).

Blumenthal, U. and Wijnen, B. (2002). User-based Security

Model (USM) for version 3 of the Simple Network

Management Protocol (SNMPv3). RFC 3414 (Stan-

dard).

Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,

and Sastry, A. (2000). The COPS (Common Open

Policy Service) Protocol. RFC 2748 (Proposed Stan-

dard). Updated by RFC 4261.

FUSE (2011). Filesystem in userspace. http://

fuse.sourceforge.net.

Ghemawat, S., Gobioff, H., and Leung, S.-T. (2003). The

google ﬁle system. Technical report, Google.

Harrington, D., Presuhn, R., and Wijnen, B. (2002). An

Architecture for Describing Simple Network Man-

agement Protocol (SNMP) Management Frameworks.

RFC 3411 (Standard).

Howard, J. H., Kazar, M. L., Menees, S. G., Nichols, D. A.,

Satyanarayanan, M., Sidebotham, R. N., and West,

M. J. (1988). Scale and performance in a distributed

ﬁle system. ACM Transactions on Computer Systems,

6(1):51–81.

Kavasseri, R. (2000). Distributed Management Expression

MIB. RFC 2982 (Proposed Standard).

Marser (2007). Marser - a mib parser. http://

marser.sourceforge.net.

McCloghrie, K., Perkins, D., and Schoenwaelder, J.

(1999a). Structure of Management Information Ver-

sion 2 (SMIv2). RFC 2578 (Standard).

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

McCloghrie, K., Perkins, D., and Schoenwaelder, J.

(1999b). Textual Conventions for SMIv2. RFC 2579

(Standard).

Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,

Beame, C., Eisler, M., and Noveck, D. (2000). NFS

version 4 Protocol. RFC 3010 (Proposed Standard).

Obsoleted by RFC 3530.

Wijnen, B., Presuhn, R., and McCloghrie, K. (2002). View-

based Access Control Model (VACM) for the Simple

Network Management Protocol (SNMP). RFC 3415

(Standard).

SNMPFS-AnSNMPFilesystem