Mon blog

Les centres qui gèrent les réseaux qui composent l'Internet, les NOC, ont régulièrement besoin d'échanger de l'information. Celle-ci, concernant les incidents, les nouveautés, les problèmes, circule souvent en quantités impressionnantes et est donc une bonne candidate pour l'automatisation. Ce RFC expérimental propose donc un format standard, basé sur XML, pour représenter l'information qui circule entre NOC, notamment ceux qui gèrent en commun une grande grille, ce qui est le cas d'EGEE, où travaillent les auteurs. Il est important pour de grosses infrastructures réseau comme les grilles de calculs, qui s'étendent sur plusieurs domaines administratifs, de pouvoir interpréter correctement les tickets avec un minimum de dépendance vis-à-vis de l'origine du ticket. L'effort de normalisation prend tout son sens dans ce contexte. Un ticket pourra donc être lu et compris sans avoir besoin de connaître les particularités et la terminologie du domaine d'origine.

Le but (section 1) n'est pas de remplacer les outils de gestion de tickets de chaque NOC mais d'avoir un format d'échange standard, suivant les souhaits du RFC 1297. Les tickets ainsi formatés pourront automatiquement être émis par un NOC, reçus par un autre, être analysés, etc. Ces outils de gestion de tickets seront ensuite utilisés pour analyser le problème, suivre son évolution et, d'une manière générale, assurer un bon fonctionnement du réseau.

On comprend mieux la taille du problème quant on voit que la grille de calcul EGEE qui utilise les NREN (vingt participants) pour sa connectivité, reçoit 800 tickets et 2500 messages par mois.

Notre RFC décrit un modèle de données en UML, puis un format concret de représentation en XML. Un problème classique que rencontrent toutes les tentatives de normalisation dans ce domaine est qu'il faut à la fois décrire de manière formelle l'incident, en énumérant de manière limitative les choix possibles, pour permettre son traitement automatique, tout en gardant des possibilités d'exprimer des problèmes nouveaux, ce qui impose de garder la possibilité de mettre du texte libre, non formaté.

Voyons d'abord les types de données utilisés (section 2). On y trouve plusieurs énumérés comme TT_TYPE qui indique si le ticket concerne un problème opérationnel, administratif, ou bien n'est là que pour information, TYPE qui indique si l'événement était prévu ou accidentel, TT_STATUS qui donne l'état du ticket (ouvert, résolu, annulé, fermé..., avec un diagramme de transition apparemment obligatoire). On trouve aussi bien sûr des chaînes de caractères (qui seront simplement le type W3C XML Schema xs:string) et des heures (au format du RFC 3339, alias xs:dateTime).

Armée de ces définitions, la section 3 détaille la longue liste des attributs d'un ticket. On y trouvera même un diagramme de classe UML en art ASCII... Parmi ces attributs, les grands classiques, comme l'identificateur unique du ticket (formé par la concaténation de l'identificateur du NOC et d'un identificateur local, ce qui permet d'allouer ces identificateurs uniques de manières décentralisée), l'état du ticket, sa date de création, l'identificateur du NOC qui est à l'origine du ticket (le RFC n'explique pas comment ses identificateurs, qui doivent être uniques, sont attribués et conservés), une description courte qui est sélectionnée à partir d'une liste pré-définie (pour permettre le traitement automatique) et une description longue qui est en texte libre (la langue utilisée peut être représenté dans le fichier XML par un attribut lang - pour des raisons que j'ignore, l'attribut standard XML xml:lang n'a pas été utilisé), les identificateurs de tickets ayant un rapport avec celui-ci, etc. Pour chaque attribut est indiqué s'il est obligatoire ou non.

La section 4 décrit l'approche utilisée pour l'internationalisation puisque les tickets seront échangés entre NOC de pays et de langues différents. Les champs formels (comme la description courte) n'ont pas besoin d'être adaptés (le logiciel de chaque NOC pourra les présenter comme il le voudra), les textes libres (comme la description longue de l'incident) peuvent être dans n'importe quelle langue (des systèmes de traduction automatique sont prévus pour EGEE dans le futur).

Si vous êtes impatients de voir à quoi ressemblent ces fameux tickets en XML, sautez directement à la section 5, qui présente les exemples. Voici un joli ticket indiquant une panne chez Forth en Grèce :

   <?xml version="1.0" encoding="UTF-8"?>
   <!-- This example describes a link failure that was detected -->
   <NTTDM-Document version="1.00" lang="el"
                   xmlns="urn:ietf:params:xml:ns:nttdm-1.0">
   <Ticket>
    <Original_ID>5985</Original_ID>
    <Partner_ID>01</Partner_ID>
    <TT_ID>01_5985</TT_ID>
    <TT_Title>Forth Link Failure</TT_Title>
    <TT_Type>Operational</TT_Type>
    <TT_Status>Closed</TT_Status>
    <TT_Open_Datetime>2008-12-16T10:01:15+02:00</TT_Open_Datetime>
    <TT_Short_Description>Core Line Fault</TT_Short_Description>
    <TT_Long_Description>Forth Link Failure</TT_Long_Description>
    <Type>Unscheduled</Type>
    <TT_Impact_Assessment>No connectivity</TT_Impact_Assessment>
    <Start_Datetime>2008-12-16T09:55:00+02:00</Start_Datetime>
    <TT_Last_Update_Time>2008-12-16T15:00:34+02:00</TT_Last_Update_Time>
    <Location>HERAKLION</Location>
    <History>Optical transmitter was changed</History>
    <TT_Close_Datetime>2008-12-16T15:05:00+02:00</TT_Close_Datetime>    
    <End_Datetime>2008-12-16T15:01:21+02:00</End_Datetime>
    <Network_Node>
     <Node>FORTH</Node>
    </Network_Node>
    <Network_Link_Circuit>
     <Link_Circuit>FORTH-2</Link_Circuit>
    </Network_Link_Circuit>
    <Open_Engineer>Dimitris Zisiadis</Open_Engineer>
    <Close_Engineer>Guillaume Cessieux</Close_Engineer>
    <Contact_Engineers>
     <Engineer>Spyros Kopsidas</Engineer>
     <Engineer>Chrysostomos Tziouvaras</Engineer>
    </Contact_Engineers>
    <TT_Priority>High</TT_Priority>
   </Ticket>
   </NTTDM-Document> 

On notera que l'exemple est imparfait : l'étiquette de langue el indique du grec mais le texte est entièrement en anglais.

Enfin, la section 6 contient le schéma complet, en langage W3C XML schema et la section 7 quelques avertissements de sécurité. Comme le contenu des tickets peut être sensible, il peut être utile de chiffrer et d'authentifier les tickets mais le RFC ne suggère pas de technique standard pour cela.

Merci à Xavier Jeannin pour sa relecture.