2010-03-19March2010A. Doria (Lulea University of
Technology)J. Hadi Salim
(Znyx)R. Haas (IBM)H. Khosravi
(Intel)W. Wang (Zhejiang Gongshang
University)L. Dong (Zhejiang Gongshang
University)R. Gopal
(Nokia)J. Halpern
Ce RFC conclut, après un très long travail, les efforts du groupe de travail Forces de
l'IETF. Ce groupe était chargé de produire un
protocole permettant la communication entre les différents éléments
d'un routeur, afin de permettre d'acheter ces
éléments chez des vendeurs différents. Un tel protocole pourrait
permettre d'ouvrir le monde actuellement très fermé des routeurs de
haut de gamme, mais il n'est pas sûr du tout qu'il soit un jour
effectivement mis en œuvre.
Le travail de Forces avait commencé il y a de nombreuses années et
le premier RFC, le avait été publié en 2003. Maintenant, grâce à ce (et quelques compagnons comme le sur le protocole de transport), le travail est quasiment terminé et la
partie Normalisation de Forces avec lui. Il
reste à l'implémenter et à faire en sorte qu'il soit disponible dans
les routeurs...
Conformément au cahier des charges du , et au cadre général de Forces exposé par le , ce nouveau protocole permet la communication entre
deux catégories d'élements qui composent un
routeur, les CE (Control
Element) et les FE (Forwarding
Element). (La section 3 rappelle le vocabulaire de Forces.) Les premiers, les CE, font tourner des algorithmes
compliqués comme OSPF ou
BGP, ils prennent des décisions « de haut
niveau » et les seconds, les FE, font le travail « bête » mais
ultra-rapide, de commutation de chaque
paquet. Aujourd'hui, dans un routeur (Forces
dit NE, pour Network Element, et pas routeur) haut de
gamme, le CE est typiquement un processeur standard, avec un système d'exploitation (parfois un Unix),le
FE est un ASIC aux capacités bien plus limitées
mais aux performances fantastiques. Comme le protocole de
communication entre le CE et le FE est privé, pas question de faire
tourner du logiciel libre sur le CE, pas
question d'acheter le processeur à un vendeur et les ASIC à un
autre. C'est ce problème que Forces veut résoudre.
Dans Forces, la relation entre les CE et les FE est simple : le CE
est le maître et le FE l'esclave. Les informations nécessaires au FE
sont regroupées dans des LFB (Logical Function
Block) dont la description est faite en
XML (cf. et un exemple dans le ). Le protocole
lui-même n'utilise pas XML. Le protocole ne spécifie que la
communication entre FE et CE, pas celles qui pourraient exister entre
FE ou bien entre CE, ni celle qui relie les CE à leur gérant (l'interface
d'administration du routeur). (La section 4 rappelle le cadre général
de Forces, exposé dans le .) Le protocole Forces est
également responsable de l'établissement et de la terminaison des
associations entre un routeur (NE) et des CE ou FE (section 4.4). Une fois
l'association faite, le CE envoie des ordres au FE, ordres exprimés
avec le protocole Forces, et encapsulés dans un protocole de
transport, le TLM (Transport Layer Mapping) qui
fait l'objet d'un RFC séparé ().
La section 4.3.1 du RFC détaille la question de
l'atomicité des requêtes Forces. Le protocole
permet des requêtes atomiques (toutes sont exécutées, ou bien aucune
ne l'est, section 4.3.1.1.1) mais aussi des requêtes exécutées séquentiellement jusqu'au
premier échec (section 4.3.1.1.3) ou encore des requêtes exécutées même si la précédente
était un échec (section 4.3.1.1.2). Mieux, Forces permet des
transactionsACID
(section 4.3.1.2).
L'encodage des paquets sur le câble fait l'objet de la section
6. Tous les paquets ont un en-tête commun, suivi d'un ou plusieurs
TLV. Parmi les champs de l'en-tête commun, un
numéro de version sur 4 bits (actuellement 1), le type du message, sur
8 bits (les différents types sont décrits en section 7 et le tableau complet est dans l'annexe A.1) et les
adresses (nommées ID) de l'expéditeur et du destinataire. Ces ID, ces
adresses, sont codés sur 32 bits et doivent être uniques à l'intérieur
du routeur (mais pas forcément pour tout l'Internet). Rappelez-vous
qu'un des buts de Forces est de pouvoir gérer des équipements très
complexes, où CE et FE ne sont pas forcément dans la même boîte. À
noter que les adresses des CE et des FE sont séparées (les premières
commencent toujours par 00 et les secondes par 01).
Une fois passé l'en-tête commun, viennent les
TLV, décrits dans la section 6.2. Le choix de
TLV permet de simplifier l'analyse des messages, certains FE
n'apprécieraient en effet pas forcément de devoir analyser du XML. À
noter que le champ Valeur d'un TLV peut contenir d'autres TLV.
Le contenu légal d'un message (quels TLV, en fonction de son type)
est le sujet de la section 7. Par exemple (section 7.1.6), si le type
est Config (créer ou bien mettre à jour un attribut
du FE) ou Query (récupérer la valeur d'un attribut
du FE), il ne peut pas y avoir de TLV de réponse dans le message (mais
il y a un TLV PATH-DATA qui contient
l'identificateur de l'attribut qu'on vise). Si
le type est QueryResponse (réponse à une question
posée), en revanche, le TLV de réponse (section 7.1.7)
est obligatoire. Comme le protocole Forces est très asymétrique (les
CE commandent et les FE obéissent), la plupart des messages ne peuvent
être émis que dans une seule direction (par exemple, un
GET ne peut être que d'un CE vers un FE, le FE,
en bon subordonné, ne doit pas poser des questions à son
supérieur). Les questions et réponses sont détaillées en section 7.7 et un registre IANA stocke les valeurs possibles. L'annexe C donne plusieurs exemples d'encodage.
La traditionnelle section sur la sécurité est la 9. Les menaces
contre Forces ont été décrites dans le . Forces peut être configuré avec zéro sécurité (section
9.1), notamment si tous les composants, CE et FE, sont dans une seule
boîte fermée (ce qui est le cas de la plupart des routeurs
aujourd'hui). Autrement, la sécurité dépend essentiellement des
services du TML (section 5).
Notre ne normalise que les bits qui seront
transportés entre CE et FE, pas la manière dont ils seront encapsulés
dans un protocole de transport. La section 5 ne spécifie pas de
telles règles
mais expose le cahier des charges que devront respecter
celles-ci (appelé le TML pour Transport Mapping
Layer). Au moins une encapsulation est obligatoire pour
Forces, celle du mais d'autres sont possibles.
Parmi les exigences de cette section, la fiabilité de la délivrance
des paquets (au moins pour certains d'entre eux), la sécurité (au
minimum la possibilité d'authentifier CE et FE, de
préférence avec des mécanismes existants comme
TLS ou IPsec), le
contrôle de congestion (cf. ), la
possibilité de haute disponibilité (section 8), etc.
Je ne connais pas encore d'implémentation de niveau « production ». Ce n'est pas un travail évident, Forces est riche et complexe,
peut-être trop.