a. Topologie d’un réseau iFCP
La topologie type d’un réseau iFCP est représentée à travers la figure suivante.
Figure 27 : Topologie d’un réseau iFCP
Les caractéristiques essentielles de ce réseau sont les suivantes:
– de façon générale, c’est l’interconnexion de plusieurs réseaux FC via un réseau IP,
– topologie “any-to-any”, c’est-à-dire tout le monde peut parler à tout le monde simultanément,
– chacune des réseaux FC ou région iFCP s’interface avec le backbone IP grâce à un équipement
nommé “Passerelle iFCP” ou “iFCP Gateway “.
– la Passerelle iFCP joue le rôle de commutateur et possède au moins un port FC (pour le réseau
FC) et un port WAN (pour le réseau IP).
– Chaque région FC se comporte comme un système autonome et dont la configuration est totalement
transparente au réseau IP et aux autres régions.
– Les mécanismes de communications intra régionales sont conformes aux normes FC-FS et FC-SW3
de Fibre Channel.
Le port FC de la passerelle dépend de la topologie du réseau FC dans lequel il se trouve. Ainsi cela peut
être un F_Port, un FL_Port ou un L_port.
Figure 28 : Pile de protocoles iFCP
c. Fonctionnalités
Le rôle principal d’une Fabric iFCP est de permettre la communication entre deux N_Port via un réseau
IP. Cette fonction est assurée à l’aide de la passerelle qui supporte les fonctions suivantes:
– adressage de trame et translation d’adresses
– encapsulation des trames FC avant l’injection dans le réseau IP et dés-encapsulation des trames FC
reçues depuis le réseau IP avant l’injection dans le réseau FC local.
– création de la session iFCP
Une Fabric iFCP ne supporte pas les classes de service 1, 4 et 6; seules les classes de service 2 et 3 sont
autorisées. Tout comme le réseau FC, une Fabric iFCP possède un serveur de nom appelé iSNS (internet
Storage Name Server) dont les fonctionnalités sont les suivantes:
– émuler les fonctions des Name Server des réseaux FC
– avertir de façon asynchrone les N_Ports des changements dans la Fabric iFCP
– subdiviser la Fabric iFCP en zones pour la définition et la gestion des espaces d’adressage des
équipements
– stocker et distribuer les règles de la politique de sécurité
– implémenter le mécanisme de diffusion de Fibre Channel.
Les passerelles iFCP peuvent être configurées à fonctionner selon deux modes:
· le mode d’adresse transparent
Dans ce mode, l’espace d’adressage des équipements est commune à tous les réseaux FC de la
Fabric iFCP. En d’autres termes, chaque N_Port de la Fabric iFCP possède une seule et unique adresse
FC dans toute la Fabric iFCP. Dans une Fabric iFCP, toutes les passerelles qui communiquent entre elles
doivent avoir le même mode de fonctionnement. Dans ce mode ci, on dit que la Fabric iFCP est limitée
(“bound”). Dans une telle Fabric, les commutateurs obtiennent leur Domain_ID auprès de leur principal qui
les a lui-même reçus du serveur iSNS. Ce dernier est vu comme commutateur principal par les différentes
passerelles de la Fabric iFCP. La passerelle iFCP peut être aussi le commutateur principal de sa région.
Une Fabric iFCP limitée est similaire à une Fabric FC normale sauf que chaque région possède ses propres
services FC (Fabric Controler, Name Server, etc.) et est autonome. Néanmoins, toute requête transmise au
Name Server local, sera transformée puis envoyé au serveur iSNS car les toutes les informations du Name
Server local sont incluses dans la base de données du serveur iSNS.
Le nombre (239) très faible de Domain_IDs attribuables dans la Fabric iFCP limitée reste un obstacle à
l’extension de ce type de réseau iFCP. Aussi faut il noter qu’en cas d’événement nécessitant une
reconfiguration, comme l’ajout ou le retrait d’une passerelle, toute la Fabric iFCP sera concernée par cette
opération de réaménagement. Ce mode n’est quasiment pas utilisé.
· le mode de translation d’adresse
Dans ce mode, l’espace d’adressage des équipements est local à chaque réseau FC de la Fabric
FC. Chaque réseau FC a donc la possibilité d’adresser 239 N_Ports et ce indépendamment de l’adressage
effectué dans les autres régions de la Fabric iFCP. Tout comme le mode précédent, seules les passerelles
de même mode peuvent communiquer entre elles. Une Fabric iFCP composée de passerelles en mode
translation d’adresse est dite non limitée (“Unbound”). Dans une telle Fabric où les adresses peuvent être
dupliquées d’une région à une autre, un mécanisme de translation d’adresse est effectué par les passerelles
durant le passage d’une trame d’une région à une autre via le réseau IP. Ainsi, en plus d’adresser les
N_Ports locaux, la passerelle iFCP adressera les N_Ports des autres régions de la Fabric iFCP. Dans ce
cas-ci, la base de données du Name Server n’est pas incluse dans celle du serveur iSNS. En effet, chaque
passerelle conservera dans son Name Server en plus des Domain_IDs reçus du serveur iSNS, les alias des
adresses reçues des autres régions. Ce mappage en alias des adresses des N_Ports distants, est purement
local et donc transparent au réseau IP, aux autres régions et donc au serveur iSNS. Ce mode est le plus
utilisé car il offre tous les avantages liés au protocole.
d. Fonctionnement
L’interconnexion ou l’extension de réseaux FC via un réseau IP sous iFCP n’est rien d’autre que
l’ajout d’une couche de protocole iFCP sur des commutateurs FC muni d’interfaces WAN. L’équipement ainsi
constitué et nommé passerelle iFCP et d’une part assure l’intégralité des fonctionnalités du protocole iFCP et
d’autre part possède la totalité des fonctions d’un commutateur classique du réseau IP. Le rôle principal
d’une passerelle est de permettre la communication entre deux N_Ports FC séparés dans l’espace par un
réseau IP de toute taille (figure 27).
Toute la valeur ajoutée de ce protocole réside dans l’accomplissement de cette tache. Les différentes
fonctions d’une passerelle iFCP sont les suivantes:
· Création de session
Une session iFCP est identifiée par les adresses réseau des deux N_Ports qui la constituent, reliés par
une connexion TCP. L’adresse réseau d’un N_Port est composée de son N_Port ID que lui a affecté la
passerelle auquel il est rattaché et de son iPA qui comprend l’adresse IP de sa passerelle ainsi que le
numéro de port TCP.
La création d’une session iFCP se déclenche à la réception d’une requête ELS PLOGI d’un N_Port de la
région local. Les informations qui constituent la session proviennent, en ce qui concerne le N_Port distant,
du serveur iSNS par l’intermédiaire du descripteur de N_Port distant.
En effet, à l’initialisation de chaque communication, la passerelle maintiendra les informations concernant le
N_Port distant, la figure 29 présente les informations qui constituent le descripteur du N_Port distant. Les
champs N_Port Alias sont des adresses FC affectées provisoirement aux N_Ports distants pendant la
communication pour éviter des erreurs de duplication d’adresse. Il faut noter dans un réseau iFCP,
l’attribution des adresses reste locale à chaque région iFCP, ce qui signifie que les adresses FC peuvent se
dupliquer d’une région à une autre.
Figure 29 : Descripteur de N_Port
Une fois le descripteur de N_Port distant est créé et que toutes les informations concernant les deux
N_Ports sont maintenues, la passerelle initiera avec la passerelle distante une connexion TCP sur laquelle il
lui transmettra une requête CBIND afin d’associer le message PLOGI à une session TCP et d’établir une
session iFCP. Ce message contient essentiellement le WWN des deux N_Port, ce qui permettra à la
passerelle distante de constituer à son tour, avec l’aide du serveur iSNS, un descripteur du N_Port qui lui est
distant. A la réception d’une réponse positive à la requête CBIND, la session iFCP ainsi que le descripteur
qui lui est associé seront créés par la passerelle. La figure 30 présente les informations qui constituent le
descripteur d’une session iFCP.
· Encapsulation et dés-encapsulation des trames
L’encapsulation est l’opération obligatoire qu’effectue une passerelle iFCP avant de relayer ou de
transmettre une trame sur le réseau IP quelque soit le mode de fonctionnement. Ainsi donc pour un
message PLOGI, la création de la session iFCP précédera l’encapsulation de cette trame. Le processus
d’encapsulation est conforme à la RFC 3643 et se résume globalement à l’ajout d’une entête à la trame FC
reçue du N-Port local (figure 31). La figure 32 montre le format de l’entête d’encapsulation.
Figure 32 : Format d’entête d’encapsulation
Le champ LS_Command est spécifique aux trames de service de lien. Le champ iFCP permet de
reconnaître les trames de contrôle de session et de définir le mode de fonctionnement de la passerelle.
L’encapsulation consiste donc à créer une entête d’encapsulation (28 Octets) afin de constituer un nouveau
format de trame (figure 31). Le processus d’encapsulation ne peut avoir lieu qu’à l’intérieur d’une session
iFCP.
Le mécanisme de dés-encapsulation consiste lui à se débarrasser de l’entête d’encapsulation afin de
retrouver la trame Fibre Channel émis préalablement par le N_Port distant. Cette opération est exécutée par
la passerelle sur toutes les trames qu’elle reçoit du réseau IP.
· Translation d’adresses
Contrairement au mécanisme NAT, cette opération est le plus souvent effectuée sur une trame par la
passerelle qui la reçoit. Les N_Ports transmettent les trames avec des adresses de destination qui sont des
alias affectés par leur passerelle iFCP au port destinataire. Ces adresses seront ensuite retransmise sur le
réseau IP sans modification aucune au même titre que les autres champs de la trame de données. Seule la
passerelle réceptrice modifiera cette adresse afin de la remettre au destinataire dans sa région FC. Cette
translation s’effectue à l’aide des informations du descripteur de session associé à la communication que
détient la passerelle.
Le protocole autorise les messages de service de lien FC conformes à la norme FC-FS à passer à travers le
réseau IP, ceux-ci sont tous supportés par les infrastructures iFCP. En mode translation, le transfert de ces
messages, d’un réseau FC à un autre via les passerelles iFCP, impose parfois certains traitements. En
effet, pour ce type de message, la passerelle qui transmet modifie certains champs de la trame afin de
faciliter la tache à la passerelle réceptrice pendant le processus de translation. Pour ce type de trames, les
adresses de translation sont parfois incluses dans le champ PAYLOAD.
· Ajustement du temps de traversée
Les protocoles FC et TCP imposent tout deux une durée de vie maximale aux PDU qu’ils émettent sur le
réseaux. Dans FC cette durée est définie par la variable R_A_TOV (10 s), tandis que dans TCP, le MSL
vaut environ 2 minutes.
Afin de permettre aux trames FC de s’adapter au temps de vie offert par TCP, la valeur de la variable FC
R_A_TOV sera forcée à l’aide des champs Time Stamp de l’entête d’encapsulation. De façon pratique la
valeur R_A_TOV de la Fabric iFCP sera configurée par l’opérateur de manière à considérer les temps de
traversée des deux réseaux FC et celui du réseau IP. Le temps de traversée du réseau IP appelé IP_TOV
sera stockée dans le serveur iSNS et égale à R_A_TOV/2. Il faut noter que cette valeur R_A_TOV n’est
prise en compte que lors d’une communication inter régions FC et qu’elle n’est interprétée que par la couche
iFCP. Pour bien gérer ce mécanisme, les passerelles synchronisent leur base de temps à l’aide du protocole
SNTP (Simple Network Time Protocole). Pour être synchronisé, une passerelle a besoin de transmettre une
requête SNTP au serveur iSNS qui lui permettra de localiser les serveurs SNTP de synchronisation. Le
protocole SNTP est une version simplifiée du protocole NTP (Network Time Protocole) et ses principes de
fonctionnement sont détaillés dans la RFC 2030.
Une fois synchronisé, la passerelle configurera la valeur du champ Time Stamp de chaque trame sortante
selon sa base de temps. Ainsi toute passerelle recevant cette trame pourra calculer le temps de traversée de
la trame et déduire sa validité en fonction de la valeur IP_TOV pré configurée.
e. Conclusion
Le protocole iFCP possède nativement des mécanismes qui permettent d’éviter certains problèmes liés
au protocole Fibre Channel:
– Aucun message de classe F ne circule sur le lien iFCP
Cette caractéristique représente l’atout principal de ce protocole. En effet la reconfiguration de la Fabric
FC suite à une modification est déclenchée par des messages de classe F tels que BF et RCF. Ainsi
donc dans un réseau iFCP, un problème local (reconfiguration) n’est pas transmis sur les îlots distants.
De même cette fonctionnalité résout le problème crucial de la fusion des SAN suite à une interconnexion
car les messages de fusion tels MR, SCF ou MRRA sont tous de classe F.
– L’adressage FC est local à chaque région iFCP
Un réseau Fibre Channel ne peut contenir que 239 commutateurs. Cette limite qu’impose FC est
franchie avec le mécanisme de translation d’adresse qui permet d’avoir autant d’adresse qu’on le
souhaite pourvu qu’on augmente le nombre de régions. Par contre cette limite reste une réalité à
l’intérieur de chaque région iFCP.
– La négociation du BB_Credit reste locale à chaque région iFCP
Avec leurs interfaces WAN, les passerelles permettent de s’affranchir de la distance car le paramètre de
contrôle de flux BB_Credit est négocié localement entre la passerelle et les commutateurs de sa région.
– Chaque communication nécessite une connexion TCP
Le protocole iFCP a une connexion TCP pour chaque communication et chaque connexion dispose de
sa propre qualité de service, différentiée si nécessaire. Dans les environnements SAN FC, il n’est encore
possible d’affecter des priorités plus importantes à un flux vis-à-vis d’un autre. iFCP tire donc aussi
pleinement parti des avantages que procure le couple TCP/IP en terme de gestion de qualité de services
et des différents mécanismes disponibles pour la gérer.
L’utilisation du modèle de connexions multiples de TCP reste un avantage car d’une part il permet
l’agrégation de canaux multiple qui délivre une bande passante globale plus importante qu’une utilisation
restreinte à un mode de connexion simple et d’autre part il isole les effets liés à une congestion à la session
incriminée sans influer sur le reste des échanges.
Très peu de constructeurs fournissent des interfaces iFCP, seul McDATA offre des commutateurs iFCP.
NORTEL a lui aussi annoncé promis des interfaces iFCP sur ses futurs commutateurs.
Page suivante : II.2.3.4. Le protocole iSCSI
Retour au menu : Rapport de stage dans le cadre du projet STORM