Vous êtes sur la page 1sur 45

The Simple Network

Managment Protocol (SNMP)

Nicolas Sayer
Nicolas.Sayer@inria.fr
Nick@loplop.net

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 1

1
Plan

1: Introduction;
2: SMI, MIB and OIDs;
3: Commandes SNMP;
4: Exemples d’agents et de requêtes;
5: Plus de SNMP.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 2

2
1: Introduction

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 3

3
Définition (général)

Les systèmes de gestion de réseau (Network


Managment Systems (NMS)) possèdent deux
éléments de bases:
Des "Manager" qui permettent aux gestionnaires du
réseau de contrôler ce dernier et réaliser des
actions sur ce réseau;
Des "Agents" qui sont l’interface entre les objets
des périphériques gérés et le Manager.
SNMP permet aux "Managers" de
communiquer aux "Agents" en leurs donnant
accès à ces objets.
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 4

4
Définition (SNMP)

SNMP est un protocole permettant de gérer les éléments d’un


réseau IP;
SNMP existe sur beaucoup de types de périphériques différents
(routeurs, switchs, rack de modems, imprimante, PC, UPS)...
SNMP permet de vérifier l’état de ces périphériques IP, mais il
peut aussi permettre de suivre leur utilisation dans le temps et
observer l’état général de santé de son réseau (@large).
SNMP offre la possibilité d’observer des données assez standard
comme le trafic réseau passant à travers un routeur, l’état de ces
interfaces; mais il peut être étendu pour transmettre des valeurs
plus spécifique au matériel utilisé: la température d’un switch; la
quantité de café disponible dans la machine...

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 5

5
Grace à SNMP

Monitor: Suivre l’état de son réseau dans


le temps;
Control: Être alerté des pannes et
défauts apparut dans le réseau;
Manage (gérer): Modifier des paramètres
de fonctionnement du réseau, de façon
manuelle ou automatique.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 6

6
Histoire

SGMP (Simple Gateway Monitoring


Protocol), crée durant le développement
de SNMP par le Networking Group de
l’IETF;
SNMP arrive en 1988; annoncé comme
le standard pour gérer des périphériques
IP.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 7

7
SNMP versions

SNMPv1: RFC 1157 (1990) standard:


Sécurité basée sur les communautées
(texte en claire);
SNMPv2c: RFC 1905, RFC 1906, RFC
1907 (1996) experimental
SNMPv3: RFC 1905 à 1907 et RFC 2571
à 2575 (1999) proposed
Authentification forte, utilisation de clefs,
bulkget, acquittement des traps.
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 8

8
Protocole SNMP

SNMP utilise un protocole de


communication ultra−simplifié:
port 161/UDP (trap: 162/UDP);
Détection des pannes assurées par des
timeout (temps max. sans réponse);
L’agent ne conserve aucun état (stateless),
n’utilise pas de mémoire de stockage.
L’intelligence réside dans le NMS et le
protocole.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 9

9
Architecture
Network Managment System Network Managment System

Network

Device Device Device


SNMP MIB
SNMP MIB
SNMP MIB
Agent Agent Agent

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 10

10
Architecture (détail)

Network Managment System

Alerte (trap)
eq

te
Réponse

(
ge )
t

Device
SNMP MIB
Agent

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 11

11
Agent

Accède aux données de management, comme défini dans la MIB,


en lecture et en écriture;
Peut envoyer un événement au "manager" de façon asynchrone
(trap);
Peut être un proxy pour un élément du réseau n’implantant pas
SNMP;
Implante l’intégralité du protocole SNMP;
L’agent peut être un logiciel comme un daemon ou service sous
NT. Il peut aussi faire partie intégrante d’un OS (Cisco IOS) voir
même être implanté directement au niveau matériel (HP gCard);
L’agent est très simple à implanter (c’est le Simple de SNMP). Il
est stateless, ne stock aucune donnée.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 12

12
Le Manager

Généralement implanté comme station de


management réseau (NMS);
Peut:
Faire des requêtes aux agents;
Recevoir les réponses des agents;
Modifier des valeurs dans les agents;
Recevoir des événements asynchrones des agents
(trap).
Généralement le NMS déclenche des alertes en fonction
des réponses obtenues (alarme sonore et visuel, pager,
SMS...)
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 13

Quelques NMS connus:


− Hewlett Packard: OpenView ;
− IBM NetView/6000 ;
− SunConnect SunNet Manager ;
− Spectrum (??? find from who).

NMS non−SNMP (mais qui possèdent généralement des modules pour


l’implanter):
− BMC: Patrol ;
− BigBrother.

13
RMON (Remote Monitoring)

RMON est un ajout dans la MIB−II de


SNMP;
Il permet de collecter de façon central
des informations sur l’état d’un réseau
(Ethernet), sa charge et l’évolution de
son utilisation;
RMON n’est PAS un protocole ! C’est
une MIB !
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 14

14
2: SMI, MIB et OID

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 15

15
MIB (généralités)

Les MIB (Management Information Database) définissent


les objets pour lesquels ils connaissent une valeur ;
L’agent et le NMS doivent posséder une copie de la MIB ;
Les MIB ont un format standard: Structure of Management
Information (SMI) (RFC1065) donnant pour chaque objet:
Pour chaque objets sont définis:
Un nom (HR): "sysContact", un identifiant numérique (4);
Une syntaxe: entier, string...
Un type d’accès: read−only/read−write ;
Une description: "Cet objet sert à cela".

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 16

Il faut voir une MIB comme une base de donnée stockant une liste d’objets et
leurs définitions. Le format de la SMI peut paraître un peu complexe à première
vu, mais il est extrêmement claire et extensible. Ce format n’est pas spécifique
aux MIB de SNMP.

La RFC SNMP spécifie que l’agent, comme le client doivent posséder une copie
de la MIB. Ceci n’est pas entièrement vrai. La majorité des clients étant capable
de faire des requêtes SNMP seront capable de faire une requête en utilisant
uniquement l’identifiant numérique. Cependant l’agent, lui, doit obligatoirement
avoir une table, il serait incapable de savoir quel valeur utiliser et avec quel "type"
la formater.

16
MIB (II)

La MIB−II (RFC1213) défini un certain nombre d’objets


de base devant être supporté par tout agent SNMP.
Exemple: Nom de l’administrateur, localisation, liste
des interfaces réseau, vitesse, octets transmit...
Il existe d’autres MIB standard pour des besoins plus
spécifiques: ATM MIB (RFC2515), BGB4 MIB
(RFC1657), Mail Monitoring MIB (RFC2249), DNS
Server MIB (1611)...
Les constructeurs ont la liberté de créer leurs propres
MIBs selon leurs besoins spécifiques (températures,
ACL...). Elles apparaissent dans l’arborescence
"private").
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 17

S’il y a une MIB−II, il existait évidement une MIB−I, mais celle−ci à été
remplacée durant les premiers âges de SNMP.

La MIB−II doit OBLIGATOIREMENT être supporté par tout agent SNMP. Elle
défini des éléments génériques comme la localisation de l’équipement, le nom de
la personne à contacter pour l’administration. Elle défini toute les informations
réseau de base. S’il y a SNMP, il y a au moins une interface réseau sachant
transmettre des informations.

Comme les mondes du réseau et du système sont de plus en plus liés; il existe une
MIB spécifique aux systèmes d’exploitation (Host Resources MIB (RFC2790)).
Celle−ci gère un certains nombres d’objets génériques au différents systèmes
d’exploitation sur le marché:
− Charge CPU ;
− Utilisation des disques ;
− Nombre d’utilisateurs connectés ;
− Table des processus.
Certains agents préfèrent utiliser des MIBs propriétaires pour l’OS, en y ajoutant
chacun leur grain de sel. Il n’y a aucune obligation d’implanter cette MIB (que la
MIB−II est obligatoire).

17
Structure de l’arborescence
SMI
root (.)

ccitt(0) iso(1) joint(2)

org (3)

dod(6)

internet(1)

directory(1) mgmt(2) experimental(3) private(4)

mib−2(1) enterprises(1)

system(1) interfaces(2) cisco(9)


.1.3.6.1.4.1.9.
sysDescr(1) sysContact(4).1.3.6.1.2.1.1.4.0
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 18

L’arbre "enterprises" contient une liste de constructeurs sous laquelle, chacun de


ces constructeurs pourront définir leur propre MIB. La liste de correspondance
OID <−> Constructeur est maintenu par l’IANA (
ftp://ftp.isi.edu/in−notes/iana/assignements/enterprise−numbers). N’importe qui à
le droit de demander d’être identifier sous l’arborescence "enterprises" à partir du
moment où ils ont réalisés un développement SNMP notable.

18
Syntaxe des Object IDentifiers
(OID)
INTEGER: un nombre 32bits. Souvent utilisé pour
donner un état. Par exemple l’état de l’interface d’un
routeur: 1=up, 2=down, 3=testing. 0 n’est
généralement pas utilisé;
OCTET STRING: Une suite de 0 ou + d’octets: (texte,
adresse MAC);
COUNTER: nombre 32bits, ne peut q’être incrémenté,
repasse à zéro quand il dépasse (232−1);
OBJECT IDENTIFIER: un autre objet;
IpAddress;

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 19

Il n’existe pas dans la MIB−II de champs d’adresse IP spécifique à IPv6. Le


groupe de travail SMING de l’IETF travail sur ce sujet.

Il faut bien faire la différence entre le fonctionnement des variables GAUGE,


COUNTER, etc... Celle−ci seront très visibles lors de l’utilisation de ces variables
dans un NMS ou un logiciel de Graph comme MRTG ou Cricket.

19
Syntaxe des Object IDentifiers
(OID) (2)
Gauge: nombre de 32bits. Possède une valeur min. et
max. (vitesse d’un port ethernet);
TimeTicks: nombre sur 32bits, mesure le temps en
centièmes de secondes (uptime);
DISPLAY STRING: Chaîne de caractères (max. 255).
Counter64: Comme un compteur 32, sauf qu’il est sur
64bits;
Il en existe beaucoup d’autres... Bon nombres de
nouveaux ont été ajoutés dans la v2 de SMI.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 20

20
Groupes d’arbres définis dans
la MIB−II (RFC1213) (1.3.6.1.2.1)
system: Défini des objets donnant des indications sur
le système: UpTime, Description, Fonction, Contact
system...
interfaces: Donne des informations sur les interfaces
réseau du système: état, trafic, erreurs...
at: Translation d’adresse (legacy);
ip: Information sur la pile IP, en l’occurrence le
routage;
icmp;
tcp: État des connexions TCP (closed, listen,
synSent...);
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 21

Il en existe quelques autres, mais généralement peu utilisés.

21
Groupes d’arbres définis dans
la MIB−II (RFC1213) (1.3.6.1.2.1)
udp: Statistiques UDP (datagram
envoyés, reçus...);
egp: État de l’EGP (Exterior Gateway
Protocol);
snmp: Informations sur l’état et le
fonctionnement de l’agent SNMP du
système.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 22

22
Les indexes

Les objets simples ont toujours un index fixé à


.0
On utilise les indexes quand il y a plusieurs
instances du même type de périphérique
(plusieurs cartes réseaux, par exemple):
interfaces.ifTable.ifEntry.ifDescr.1 = lo0
interfaces.ifTable.ifEntry.ifDescr.2 = eth0

Il existe toujours une variable donnant le


nombres d’éléments dans l’index:
interfaces.ifNumber.0 = 2

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 23

L’utilisation des indexes peut devenir compliqué quand on possède un grand


nombre de ports sur un switch par exemple. Certains constructeurs font attention à
utiliser des indexes linéaires: 1,2,3,4,5... au détriment d’une certaine logique dans
la numérotation des ports. D’autres utilisent le même numéro pour l’indexe et le
port, mais dans ce cas les indexes ne sont plus linéaires...: 1,4,24,532...

23
Les indexes (2)

Si l’incrément des indexes n’est pas


linéaire, il doit exister une table linéaire,
pointant sur chaque éléments de la table
non−linéaire:
.ifNumber.0 = 2
.ifIndex.1 = 3
.ifIndex.2 = 47

.ifTable.ifEntry.ifDescr.3 = eth3
.ifTable.ifEntry.ifDescr.47 = ge47

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 24

24
3: Commandes SNMP

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 25

25
Types de commandes

Il existe trois types de commandes en SNMP, certains


types possèdent des sous−variantes:
GET: Le manager émet une requête vers le client pour
interroger une variable, celui−ci renvoi une réponse à cette
commande;
GET−NEXT: Comme GET, sauf que l’agent répond avec


l’OID suivant dans l’arbre. Permet de "Walker" la MIB.


GET−BULK (v2): Permet de faire de requête sur des


"branches" complètes de l’arbre.


SET: Le manager émet une requête de modification sur un
élément, l’agent répond par un ACK.
TRAPs: L’agent émet spontanément une information à
destination d’un NMS.
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 26

26
GET

Le NMS envoi une


Network Managment System
requête GET avec un
Get−Réponse OID à l’agent:
R
eq

te
( GET gw.inria.fr public
.1.3.6.1.2.1.1.6.0
L’agent répond avec un
ge )

GET−RESPONSE, avec
t

la valeur correspondant à
Device l’OID demandé.
SNMP system.sysLocation.0 =
MIB "INRIA Rocquencourt /
Agent Bat 7/25"

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 27

27
GET−NEXT

Le NMS envoi une


Network Managment System
requête GET avec un
Get−Réponse OID à l’agent:
R
eq

te
( GET−NEXT gw.inria.fr
public
system.sysContact.0
L’agent répond avec un
ge )
t

GET−RESPONSE, avec
la valeur correspondant à
Device
l’OID placé APRÈS l’OID
SNMP
Agent
MIB demandé.
system.sysName.0 =
"gw.inria.fr"

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 28

C’est le GET−NEXT qui est utilisé pour "Walker" la MIB. L’agent ne conservant
aucun historique des requêtes reçus, il est incapable de savoir ce que le NMS à
demandé plus tôt.

28
SET

Le NMS envoi une


Network Managment System
requête SET avec un
OID à l’agent:
R

getResponse
eq

te
SET gw.inria.fr


(
private
system.sysContact.0 s
"Nicolas"
se )
t

L’agent répond avec un


GET−RESPONSE, avec
Device un code de retour
SNMP MIB
(OK/KO).
Agent

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 29

29
TRAP

L’agent envoie une


Network Managment System
exception (trap) avec un
TrapID et un OID:
0−coldStart, 1−

Trap

warmStart, 2−
linkDown, 3−linkUp...
En SNMPv2 et v3, le


NMS peut acquitter


Device
les traps.
SNMP MIB
Agent

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 30

En SNMP, il y a deux moyens de savoir si quelque chose ne fonctionne plus:


− En faisant des GET régulier sur l’information en question (pooling), ceci
engendre de la charge inutile, et ne permet pas d’avoir l’information
immédiatement;
− En utilisant les TRAPS, beaucoup plus joli, cependant les TRAPS sont des
événements asynchrones et ne sont pas acquittés!

30
Les Communautés (SNMPv1)

Il existe deux types de communautés:


read−only: public


read−write: private


L’authentification en SNMPv1 fonctionne grâce


à ces communautés;
La communauté (rw) est la première chose à
changer!
Il existe d’autres mécanismes de sécurités:
ACLs, communautés multiples, clefs (v3)...
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 31

31
Nouveaux PDU (Protocol Data
Units) v2 et v3
Notification: Standardise les TRAP pour
avoir un format cohérent avec les GET et
SET;
Inform: Mécanisme de communication
NMS à NMS;]
Report (unused): permet aux NMS
d’informer d’autres NMS de problemes
de communication SNMP.
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 32

32
4: Implantations SNMP
4.1: Des Agents

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 33

33
Cisco’s IOS (agent)

snmp−server engineID local 000000012345678901234567


snmp−server community public lecture 1300
snmp−server community private ecriture 1300
snmp−server location Salle Machine
snmp−server host 128.93.23.181

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 34

34
Net−SNMP SNMPd (Agent)

# Standard
syslocation INRIA/Rocq Bat. 25
syscontact Nicolas Sayer <Nick@loplop.net>
# Propritaire NET−SNMP (NET−SNMP−MIB)
proc snmpd
exec echotest /bin/echo hello world
disk / 10000
disk /dev
disk /usr
disk /u1
load 12 14 14

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 35

35
4.2: Exemples de requêtes
(Net−SNMP)

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 36

36
snmpget
[nick]$ snmpget xxx.xxx.xxx.xxx public system.sysDescr.0
system.sysDescr.0 = Linux xxxx.inria.fr 2.4.6_1.4_VTHD #1 SMP Mon Jul 16
11:53:55 CEST 2001 i686
[nick]$ snmpget −On xxx.xxx.xxx.xxx public system.sysContact.0
.1.3.6.1.2.1.1.4.0 = "Nicolas Sayer <Nicolas.Sayer@inria.fr >"
[nick]$ snmpget xxx.xxx.xxx.xxx public interfaces.ifNumber.0
interfaces.ifNumber.0 = 2

[nick@]$ snmpget xxx.xxx.xxx.xxx public interfaces.ifTable.ifEntry.ifDescr.2


interfaces.ifTable.ifEntry.ifDescr.2 = eth0
[nick]$ snmpget xxx.xxx.xxx.xxx public
interfaces.ifTable.ifEntry.ifInOctets.2
interfaces.ifTable.ifEntry.ifInOctets.2 = Counter32: 2210757931

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 37

37
snmpwalk (1) (Net−SNMP)
[nick]$ snmpwalk localhost system
system.sysDescr.0 = Linux xxxxx.inria.fr 2.4.6_1.4_VTHD #1
SMP Mon Jul 16 11:53:55 CEST 2001 i686
system.sysObjectID.0 = OID:
enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (201463445) 23 days,
7:37:14.45
system.sysContact.0 = "Nicolas Sayer"
system.sysName.0 = rocq−vthd−demof.inria.fr
system.sysLocation.0 = "Bat 7 VTHD"
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00
(...)

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 38

38
snmpwalk (2) −> Cisco
Cat6.5K
[nick]$ snmpwalk gateway public | less
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) MSFC Software (C6MSFC−IS−M), Version 12.0(7)XE1, EARLY DEPLOYMENT RELEASE SOFTWARE
(fc1)
TAC:Home:SW:IOS:Specials for info
Copyright (c) 1986−2000 by cisco Systems, Inc.
Compiled Fri 04−Feb−00 00:
system.sysObjectID.0 = OID: enterprises.9.1.258
system.sysUpTime.0 = Timeticks: (52728446) 6 days, 2:28:04.46
system.sysContact.0 =
system.sysName.0 = xxxx.inria.fr
system.sysLocation.0 = Batiment 0x − Salle Machine
system.sysServices.0 = 6
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00
interfaces.ifNumber.0 = 7
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifIndex.3 = 3
interfaces.ifTable.ifEntry.ifIndex.4 = 4
interfaces.ifTable.ifEntry.ifIndex.5 = 5
interfaces.ifTable.ifEntry.ifIndex.6 = 6
interfaces.ifTable.ifEntry.ifIndex.7 = 7
interfaces.ifTable.ifEntry.ifIndex.8 = 8
interfaces.ifTable.ifEntry.ifDescr.2 = Null0
interfaces.ifTable.ifEntry.ifDescr.3 = Loopback1
interfaces.ifTable.ifEntry.ifDescr.4 = Vlan3
interfaces.ifTable.ifEntry.ifDescr.5 = Vlan4
interfaces.ifTable.ifEntry.ifDescr.6 = Vlan230
interfaces.ifTable.ifEntry.ifDescr.7 = Vlan591
interfaces.ifTable.ifEntry.ifDescr.8 = Vlan592
interfaces.ifTable.ifEntry.ifType.2 = other(1)
interfaces.ifTable.ifEntry.ifType.3 = softwareLoopback(24)
interfaces.ifTable.ifEntry.ifType.4 = ethernetCsmacd(6)

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 39

39
5: Plus de SNMP / Biliographie.

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 40

40
HP−OV Network Node
Manager http://openview.hp.com

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 41

41
MRTG / Cricket

http://people.ee.ethz.ch/~oetiker/webtools/mrtg

http://cricket.sourceforge.net

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 42

MRTG et Cricket sont des outils différents. Cependant ils sont basés sur le même
moteur de stockage et de "graphage": Les sublimes RRD Tool !

42
Tk MIB http://net−snmp.sourceforge.net

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 43

Tkmib est livré avec Net−SNMP. Il est écrit en Perl/Tk. Il nécessite donc: Perl,
les modules Perl/Tk, et les modules SNMP de Perl (http://www.cpan.org).

43
autres...

SCLI: Client "user−friendly" SNMP (


http://www.ibr.cs.tu−bs.de/projects/scli/ );
Tkined / Scotty (
http://wwwhome.cs.utwentw.nl/~schoenw/scotty/
);
NetCol, NetSaint (http://www.netsaint.org),
Perl SNMP modules (http://www.cpan.org);
Spectrum (http://www.aprisma.com ), Netcool (
http://www.micromuse.com ), eEMU
(http://www.eemuconcept.com).
26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 44

SCLI est tout bonnement génial, un outil de ce genre manquait cruellement au


monde SNMP. Il permet d’offrir une interface simple et standard pour faire des
requêtes vers des périphériques SNMP−enabled. SCLI possède des fonctions très
pratique comme un ‘top‘ SNMP.

44
Bibliographie

NEW: Essential SNMP, O’Reilly,


Douglas R. Mauro & Kevin J. Schmidt
[en cours de traduction en français];
NET−SNMP: (
http://net−snmp.sourceforge.net);
The Simple Web (
http://www.simpleweb.org).

26/01/2002 − v1.0 Nicolas.Sayer@inria.fr 45

45