Network Working Group R

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l'Internet. Il appelle à la discussion et à des suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes officielles des protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Le présent document décrit le format commun d’encapsulation de trame de canal fibre (FC, Fiber Channel) et une procédure pour mesurer et calculer le temps de transit de trame à travers le réseau IP. La présente spécification est destinée à être utilisée par tout protocole IETF qui encapsule des trames FC.

Table des matières

1. Domaine d’application 1

2. Concepts d’encapsulation 2

3. En-tête d’encapsulation FC 2

3.1 Format d’en-tête d’encapsulation FC 2

3.2 Validation d’en-tête d’encapsulation FC 4

4. Mesure du temps de transit de trame de canal Fibre 5

5. Trame FC 6

5.1 Contenu de trame FC 6

5.2 Ordre de bit et d’octet 6

5.3 FC SOF et EOF 6

6. Considérations pour la sécurité 7

7.2 Références pour information 8

8. Remerciements 8

Appendice A Guide de numérotation des bits et octets de canal Fibre 8

Appendice B Exigences d’encapsulation du protocole 9

Appendice C Considérations relatives à l’IANA 9

Appendice D Déclaration de droits de propriété intellectuelle 10

Le présent document décrit les mécanismes communs pour le transport des trames de canal fibre sur un réseau IP, y compris le format d’encapsulation et un mécanisme pour appliquer les limites de durée de vie de trame de canal fibre.

Avertissement au lecteur familiarisé avec le canal fibre : les normes de canal fibre et celles de l’IETF utilisent toutes deux le même ordre de transmission des octets. Cependant, la numérotation des bits et des octets est différente. Voir des lignes directrices à l’Appendice A. L’organisation responsable des normes de canal fibre (le comité technique T11 de l’INCITS) a déterminé que certaines fonctions et modes de fonctionnement ne sont pas interopérables au degré requis par l’IETF (voir FC-MI [8]). Le présent document comporte des déterminations d’interopérabilité de T11 applicables sous la forme de restrictions à l’utilisation de ce mécanisme d’encapsulation.

L’utilisation de ces mécanismes dans un protocole encapsulant exige un document supplémentaire pour spécifier les fonctionnalités spécifiques du protocole encapsulant et les considérations de sécurité appropriées. Comme les considérations de sécurité pour cette encapsulation dépendent de la façon dont il est utilisé par les protocoles encapsulants, elles sont traitées dans les documents spécifiques des protocoles encapsulants.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT" et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

La plus petite unité de transmission et d’acheminement de données dans un canal fibre (FC, Fibre Channel) est la trame. Les trames FC incluent un début de trame (SOF, Start Of Frame), une fin de trame (EOF, End Of Frame ) et le contenu de la trame de canal fibre. La trame de canal fibre comporte un code de contrôle de redondance cyclique (CRC, Cyclic Redundancy Check) qui assure la détection d’erreur pour le contenu de la trame. Les trames FC sont de longueur variable. Pour faciliter le transport des trames FC sur un transport fondé sur IP tel que TCP, la trame native doit être contenue dans (encapsulée) une structure légèrement plus grande comme le montre la Figure 1.

Le format et le contenu d’une trame FC sont décrits dans les normes FC (par exemple, FC-FS [3], FC-SW-2 [4], et FC-PI [5]). Il est important pour cette encapsulation que soit respectée l’exigence FC que toutes les trames DEVRONT contenir un CRC pour la détection des erreurs de transmission.

N° de protocole : Il DEVRA contenir un nombre qui indique quel protocole d’encapsulation emploie l’encapsulation FC. Les valeurs dans le champ N° de protocole sont allouées par l’IANA (voir l’Appendice C).

Version : Il DEVRA contenir 0x01 pour indiquer que cette version de l’encapsulation FC est utilisée. Toutes les autres valeurs sont réservées pour de futures versions de l’encapsulation FC.

N° -Protocole : Le champ N° -Protocole DEVRA contenir le complément à un du contenu du champ N° protocole. Les receveurs d’encapsulation FC DEVRAIENT soit valider le CRC, soit comparer les champs N° protocole et N° -Protocole pour vérifier qu’un en-tête d’encapsulation FC est traité conformément à une politique définie par le protocole encapsulant.

-Version : Le champ -Version DEVRA contenir le complément à un du contenu du champ Version. Les receveurs d’encapsulation FC DEVRAIENT soit valider le CRC, soit comparer les champs Version et -Version pour vérifier qu’un en-tête d’encapsulation FC est traité conformément à une politique définie par le protocole encapsulant.

Spécificités du protocole encapsulant : L’usage de ces termes diffère selon le contenu du champ N° de protocole, c’est-à-dire que l’usage de ces termes est défini par le protocole d’encapsulation qui emploie cette encapsulation.

Fanions : Les bits de fanion fournissent des informations sur l’usage de l’en-tête Encapsulation FC comme le montre la Figure 3.

Bits fanions réservés : Ces bits sont réservés pour utilisation par de futures versions de l’encapsulation FC et DEVRONT être réglés à zéro à l’envoi. Les protocoles d’encapsulation qui emploient l’encapsulation décrite dans la présente spécification PEUVENT exiger la vérification qu’ils sont à zéro à réception, cependant faire ainsi crée de potentielles incompatibilités avec de futures versions de cette encapsulation. Les changements de l’usage des bits fanions réservés DOIVENT être identifiés par des changements du contenu du champ Version. Les protocoles d’encapsulation qui emploient l’encapsulation décrite dans la présente spécification NE DOIVENT PAS utiliser les bits fanions réservés d’autre façon que celle décrite dans la présente spécification.

CRCV (CRC Valid Flag, fanion de CRC valide) : Une valeur du bit CRCV de un indique que le contenu du champ CRC est valide. Une valeur du bit CRCV de zéro indique que le contenu du champ CRC est invalide. La valeur du bit CRCV DEVRA être constante pour tous les en-têtes d’encapsulation FC envoyés sur une certaine connexion.

Longueur de trame : Le champ Longueur de trame contient la longueur de la trame encapsulée FC entière, incluant l’en-tête d’encapsulation FC et la trame FC (incluant les mots SOF et EOF). Cette longueur se fonde sur une unité de mots de 32 bits. Toutes les trames FC sont alignées sur des mots de 32 bits et l’en-tête d’encapsulation FC est toujours aligné sur le mot ; donc une longueur de mot de 32 bits est acceptable.

-Fanions : Le champ -Fanions DEVRA contenir le complément à un du contenu du champ Fanions. Les receveurs d’encapsulation FC DEVRAIENT valider le CRC ou comparer les champs Fanions et -Fanions pour vérifier qu’un en-tête d’encapsulation FC est en cours de traitement conformément à une politique définie par le protocole encapsulant.

-Longueur de trame : Le champ –Longueur de trame DEVRA contenir le complément à un du contenu du champ Longueur de trame. Les receveurs d’encapsulation FC DEVRAIENT valider le CRC ou comparer les champs Longueur de trame et –Longueur de trame pour vérifier qu’un en-tête d’encapsulation FC est en cours de traitement conformément à une politique définie par le protocole encapsulant.

Horodatage (secondes) : Le champ Horodatage (secondes) contient zéro ou le nombre de secondes depuis le 1^er janvier 1900 à 0 heure jusqu’à l’heure où la trame encapsulée FC est placée dans le flux de données sortant.

Horodatage (fraction de seconde) : Le champ Horodatage (fraction de seconde) contient la fraction de la seconde au moment où la trame encapsulée FC est placée dans le flux de données sortant. Les bits de moindre poids non significatifs peuvent être mis à zéro. Le Tableau 1 donne quelques exemples de valeurs de Horodatage (fraction de seconde).

Noter que, depuis un certain moment en 1968 (seconde 2 147 483 648) le bit de poids fort (bit 0 de Horodatage (secondes)) a été établi et que le champ va déborder à un certain moment de 2036 (seconde 4 294 967 296). Si FCIP devait être encore utilisé en 2036, des moyens externes seront nécessaires pour qualifier le temps par rapport à 1900 et le temps par rapport à 2036 (et les autres multiples de 136 ans). Il existera un intervalle de 200 picosecondes qui sera alors ignoré, tous les 136 ans lorsque le champ de 64 bits sera à 0, ce qui par convention est interprété comme un horodatage invalide ou indisponible.

Les mots Horodatage (secondes) et Horodatage (fraction de seconde) suivent le format horaire décrit dans le protocole simple de l’heure du réseau (SNTP) version 4 [9]. Le contenu des mots Horodatage (secondes) et Horodatage (fraction de seconde) DEVRA être établi comme décrit à la section 4.

CRC : Lorsque le bit fanion CRCV est à zéro, le champ CRC DEVRA contenir zéro. Lorsque le bit fanion CRCV est à un, le champ CRC DEVRA contenir un CRC pour les mots 0 à 5 de l’en-tête d’encapsulation FC calculé en utilisant les équations, le polynôme, la valeur initiale, et l’ordre des bits, définis pour le canal Fibre dans FC-FS [3]. En utilisant cet algorithme, l’ordre des bits du CRC résultant correspond à celui de la couche FC-1. Le CRC transmis sur le réseau IP devra correspondre à la valeur équivalente convertie en format FC-2 comme spécifié dans FC-FS.

Les deux mécanismes visent les besoins de deux concepts et environnements de fonctionnement différents.

3.2.1 Validation d’en-tête d’encapsulation FC fondée sur la redondance

La validation d’un en-tête d’encapsulation FC fondée sur la redondance s’appuie sur les champs dupliqués et de complément à un dans l’en-tête.

Les protocoles d’encapsulation qui utilisent la validation fondée sur la redondance DEVRAIENT définir comment les appareils receveurs utilisent les champs de complément à un pour vérifier la validité de l’en-tête.

La validation d’en-tête fondée sur une redondance est un processus par étapes en ce que le premier mot est validé, puis le second, puis le troisième, et ainsi de suite. La décision qu’un candidat en-tête n’est pas valide peut être prise avant que l’en-tête complet ne soit disponible.

La validation fondée sur le CRC d’un en-tête d’encapsulation FC s’appuie sur un CRC localisé dans le dernier mot de l’en-tête.

La validation d’en-tête fondée sur le CRC définie au paragraphe 3.1 exige le calcul du CRC pour tous les octets précédant le mot CRC, et de comparer le résultat au contenu du mot CRC.

Pour se conformer à FC-FS [3], une fabrique FC doit spécifier et limiter la durée de vie d’une trame. Dans une fabrique FC composée d’éléments connectés à IP, un composant de la durée de vie de trame est le temps nécessaire pour traverser la connexion. Pour s’assurer que la durée de vie totale de la trame reste dans les limites requises par la fabrique FC, l’encapsulation décrite dans la présente spécification contient des dispositions pour enregistrer l’instant de départ d’une trame encapsulée injectée dans une connexion. Si l’origine et le receveur de la trame encapsulée ont accès à des bases de temps alignées et synchronisées, le temps de transit à travers le réseau IP peut alors être calculé.

Lorsque elle génère une trame encapsulée, une entité qui ne prend pas en charge le calcul de temps de transit DEVRA toujours régler les champs Horodatage (secondes) et Horodatage (fraction de seconde ) à zéro. En recevant une trame encapsulée, une entité qui ne prend pas en charge le calcul de temps de transit DEVRA ignorer le contenu des mots Horodatage.

Le protocole d’encapsulation DEVRA spécifier si la prise en charge de la mise en œuvre est exigée ou non. Le protocole d’encapsulation DEVRA spécifier les conditions dans lesquelles une trame encapsulée reçue DOIT avoir son temps de transit vérifié avant la transmission.

Les entités encapsulantes et désencapsulantes qui prennent en charge ce dispositif DOIVENT avoir accès à :

a) Une base de temps interne qui a la stabilité et la résolution nécessaires pour se conformer aux exigences de la spécification du protocole d’encapsulation; et

b) une base de temps qui est synchronisée et alignée avec la base de temps des autres entités auxquelles des trames encapsulées peuvent être envoyées ou reçues. La spécification du protocole encapsulant DOIT décrire la procédure de synchronisation et d’alignement.

Par rapport à sa capacité à mesurer et régler le temps de transit pour les trames encapsulées échangées avec un autre appareil, une entité est soit dans l’état synchronisé, soit dans l’état non synchronisé. Une entité est dans l’état non synchronisé à la mise sous tension et passe à l’état synchronisé une fois qu’il a aligné sa base temporelle conformément à la spécification du protocole d’encapsulation applicable.

Une entité DOIT retourner à l’état non synchronisé si elle n’est pas capable de maintenir la synchronisation de sa base horaire comme requis par la spécification du protocole d’encapsulation.

La politique de transmission de trames dans l’état non synchronisé DEVRA être définie par la spécification du protocole d’encapsulation.

Si le traitement des trames est permis dans l’état non synchronisé par la spécification du protocole d’encapsulation , l’entité DEVRA :

a) lors de la désencapsulation d’une trame, ignorer les mots Horodatage ; par exemple, si un temps de transit calculé excède une valeur qui pourrait causer la violation de la limite du temps de transit maximum de trame FC, le protocole encapsulant peut spécifier que la trame est à éliminer ; et

b) lors de l’encapsulation d’une trame régler les mots Horodatage (secondes) et Horodatage (fraction de seconde) à zéro. Par exemple, un protocole encapsulant peut spécifier que les trames pour lesquelles le temps de transit ne peut pas être déterminé ne sont jamais à transmettre sur FC.

Lors de l’encapsulation d’une trame, une entité dans l’état synchronisé DEVRA enregistrer la valeur de la base horaire dans les mots Horodatage (secondes) et Horodatage (fraction de secondes) dans l’en-tête d’encapsulation.

Lors de la désencapsulation d’une trame, une entité dans l’état synchronisé DEVRA :

a) Vérifier les mots Horodatage pour déterminer si ils contiennent une heure comme spécifié dans [9] ; si l’horodatage est valide, l’entité receveuse DEVRA calculer le temps de transit en calculant la différence entre sa base horaire et l’heure de départ enregistrée dans l’en-tête de trame ; l’entité receveuse DEVRA traiter le temps de transit calculé et la trame désencapsulée conformément à la spécification du protocole d’encapsulation applicable ; ou

b) Ici les deux mots Horodatage ont une valeur de zéro, l’entité receveuse DEVRA désencapsuler la trame sans calculer le temps de transit. La disposition de la trame et toute autre action de la part du receveur DEVRA être définie par la spécification du protocole d’encapsulation.

Note : Pour la plupart des besoins, la communication entre les entités n’est possible que dans l’état synchronisé.

Note : Toutes les utilisations des mots "caractère" ou "caractères" dans cette section se réfèrent au codage de liaison à 8/10 bits par lequel chaque "caractère" de 8 bits au sein d’une trame de liaison est codé comme un "caractère" de 10 bits pour la transmission sur la liaison. Ces mots ne se réfèrent pas à l’ASCII, Unicode, ou aucune autre forme de caractères de texte, bien que les octets provenant de tels caractères se produiront comme "caractères" à 8 bits pour ce codage. Cette utilisation a lieu ici pour la cohérence avec la norme ANSI T11 qui spécifie le canal Fibre.

Comme le montre la Figure 4, le contenu de la trame FC est défini comme les données entre les délimiteurs EOF et SOF (incluant le CRC FC) après conversion du format FC-1 en FC-2 comme spécifié par FC-FS [3].

Lorsque les appareils de canal fibre convertissent le contenu de la trame FC en transport physique FC-0, un codage est appliqué au contenu de la trame FC (par exemple, le codage 8b/10b comme celui utilisé dans le Gigabit Ethernet) pour des raisons qui incluent la redondance et la synchronisation de bas niveau entre envoyeur et receveur. À l’exception de SOF et EOF [3], toutes les discussions de contenu de trame FC dans le présent document sont au niveau d’octets de 8 bits, avant l’application d’un tel codage.

L’octet de 8 bits dans le contenu de trame FC peut être traduit directement pour la transmission sur un réseau IP. Cependant, le SOF et le EOF FC emploient des caractères spéciaux 10b qui n’ont pas d’équivalent 8b. Donc, des placements spéciaux d’octets et des codages de caractères à 8 bits sont nécessaires pour représenter le SOF et le EOF.

L’en-tête d’encapsulation, SOF, le contenu de trame FC(voir le paragraphe 5.1) et EOF sont transposés en TCP en utilisant l’ordre gros boutien des octets, qui corresponds à l’ordre standard des octets du réseau ou forme canonique [7].

Comme décrit au paragraphe 5.1, la représentation du SOF et EOF FC dans un flux d’octets de réseau IP exige un format spécial et des définitions de code à 8 bits. Donc, la trame FC encapsulée DEVRA avoir le format de la Figure 5. La redondance de la représentation SOF/EOF dans le format d’encapsulation découle du souci que les informations soient protégées contre les erreurs de transmission.

Note : Le nombre d’octets de 8 bits dans le contenu de la trame FC est toujours un multiple de quatre.

-SOF : Le champ -SOF contient le complément à un de la valeur des champs SOF. Les receveurs d’encapsulation DEVRAIENT valider le champ SOF selon une politique définie par le protocole d’encapsulation.

EOF : Les champs EOF contiennent la valeur codée de EOF choisie dans le tableau 3.

-EOF : Les champs -EOF contiennent le complément à un de la valeur dans les champs EOF. Les receveurs d’encapsulation DEVRAIENT valider le champ EOF selon une politique définie par le protocole d’encapsulation.

Note : FC-BB-2 [6] fait la liste des codes SOF et EOF qui ne sont pas montrés dans les tableaux 2 et 3 (par exemple, SOFi1 et SOFn1). Cependant, FC-MI [8] identifie ces codes comme non interopérables, de sorte qu’ils ne sont pas énumérés dans la présente spécification.

Le présent document décrit seulement le format d’encapsulation. L’utilisation réelle de ce format dans un protocole d’encapsulation exige qu’un document supplémentaire spécifie la fonction du protocole d’encapsulation et les considérations de sécurité appropriées. Comme les considérations pour la sécurité pour cette encapsulation dépendent de la façon dont elle est utilisée par les protocoles d’encapsulation, elles DEVRONT être décrites dans les documents spécifiques de protocole d’encapsulation.

[2] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", RFC2119, BCP 14, mars 1997.

[3] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, 27 octobre 2003. Les normes T11 publiées sont disponible par l’INCITS à http://www.incits.org , ou à la boutique en ligne de l’ANSI à http://www.ansi.org

[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001, 12 décembre 2002. Les normes T11 publiées sont disponible par l’INCITS à http://www.incits.org , ou à la boutique en ligne de l’ANSI à http://www.ansi.org

[5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002, 1^er décembre 2002. Les normes T11 publiées sont disponible par l’INCITS à http://www.incits.org , ou à la boutique en ligne de l’ANSI à http://www.ansi.org

[6] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, 25 juillet 2003. Les normes T11 publiées sont disponible par l’INCITS à http://www.incits.org , ou à la boutique en ligne de l’ANSI à http://www.ansi.org

[7] T. Narten, C. Burton, "Avertissement sur l'ordre canonique des adresses de couche Liaison", RFC2469, décembre 1998. (Info.)

[8] Fibre Channel Methodologies for Interconnects (FC-MI), ANSI INCITS/TR-30:2002, 1^er novembre 2002. Les normes T11 publiées sont disponible par l’INCITS à http://www.incits.org , ou à la boutique en ligne de l’ANSI à http://www.ansi.org

[9] D. Mills, "Protocole simple de l'heure du réseau (SNTP) version 4 pour IPv4, IPv6 et OSI", RFC2030, octobre 1996. (Rendue obsolète par la RFC 4330)

[10] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", RFC2434, BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[11] M. Rajagopal, E. Rodriguez, R. Weber, "Canal en fibre sur TCP/IP (FCIP)", RFC3821, juillet 2004. (P.S.)

[12] C. Monia et autres, "iFCP – un protocole pour le réseautage des mises en mémoire des canaux fibre sur Internet", RFC4172, septembre 2005. (P.S.)

Les auteurs expriment leurs remerciements à Mr. Vi Chau (vchau1@cox.net) pour ses contributions à l’équipe de conception qui a développé ce document. Mr. Chau ne travaille plus sur cette technologie.

Les auteurs remercient aussi le Dr. David Black, Mr. Mallikarjun Chadalapaka, et Mr. Robert Elliott pour leur relecture de cette spécification.

Les normes de canal Fibre et de l’IETF utilisent toutes deux le même ordre de transmission des octets. Cependant, le numérotage des bits et des octets est différent.

La numérotation des bits et des octets du canal Fibre peut être observée si le début de la structure des données montrée à la Figure 6, est coupé et collé au sommet des Figure 2 et Figure 5.

Figure 6 – Numérotation des bits et octets d’une struture de données de canal Fibre

La numérotation des bits du canal Fibre pour le champ Fanions peut être observée si le début de la structure de données de la Figure 7 est coupé et collé au sommet de la Figure 3.

Cet appendice fait la liste des exigences qui pèsent sur les protocoles d’encapsulation qui emploient cette encapsulation. Les exigences énumérées ici sont suggérées ou décrites ailleurs dans ce document, mais leur récapitulation dans cet appendice est destinées à aider les auteurs de protocole d’encapsulation à satisfaire à toutes les obligations qui leur incombent.

- spécifier le numéro alloué par l’IANA qui est utilisé dans le champ N° de protocole

Les protocoles d’encapsulation qui emploient cette encapsulation DEVRONT définir les procédures et politiques nécessaires pour vérifier qu’un en-tête d’encapsulation FC est en cours de traitement.

Les protocoles d’encapsulation qui emploient cette encapsulation DEVRONT définir les procédures et politiques nécessaires pour la détection des trames périmées. Les éléments à spécifier et les choix disponibles pour une spécification de protocole d’encapsulation sont les suivantes :

a) Les exigences du protocole d’encapsulation pour le mesure des temps de transit. Le protocole d’encapsulation PEUT permettre que la mise en œuvre de la mesure des temps de transit soit facultative.

b) Les exigences ou les lignes directrices pour la stabilité et la résolution du temps de base de l’entité.

c) La procédure pour synchroniser le temps de base de l’entité, y compris les critères pour entrer dans les états synchronisé et non synchronisé.

d) La transmission (ou l’absence de transmission) du trafic de trames en état non synchronisé.

La spécification PEUT permettre à une entité dans l’état non synchronisé de continuer à traiter le trafic de trames.

e) La procédure à suivre lorsque les trames sont reçues sans horodatage valide.

La spécification PEUT permettre que de telles trames soient acceptées par l’entité.

f) Les exigences pour régler et vérifier la limite de temps de transit et la procédure à suivre lorsque une trame reçue est éliminée à cause du dépassement de la limite de temps de transit.

Le champ Protocol# (numéro de protocole) est un nombre identifiant utilisé pour faire la distinction entre les protocoles d’encapsulation qui emploient cette encapsulation de trame FC. Les valeurs utilisées dans le champ Protocol# sont à allouer à partir d’un nouveau registre distinct qui est tenu par l’IANA.

Toutes les valeurs dans le champ Protocol# sont à enregistrer et à allouer par l’IANA avec les exceptions suivantes.

- La valeur de Protocol# 0 ne devrait pas être allouée avant que toutes les autres valeurs aient été allouées.

- Les valeurs de Protocol# 240 à 255 inclus doivent être mises de côté pour utilisation privée entre des systèmes coopératifs.

Suivant les politiques exposées dans [10], les valeurs de Protocol# qui ne sont pas citées ci-dessus ne sont à allouer que pour des RFC en cours de normalisation approuvées par l’IESG.

En plus de créer le registre des numéros de protocole d’encapsulation de trame FC, l’action de normalisation de cette RFC alloue les deux valeurs suivantes à partir du registre :

- La valeur 1 de Protocol# allouée au protocole d’encapsulation FCIP (canal Fibre sur TCP/ IP) [11].

- La valeur 2 de Protocol# allouée au protocole d’encapsulation iFCP (protocole pour le réseautage des mises en mémoire des canaux fibre sur Internet) [12].

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	R. Weber, Brocade
Request for Comments : 3643	M. Rajagopal, Broadcom Corporation
Catégorie : En cours de normalisation	F. Travostino, Nortel Networks
décembre 2003	M. O'Donnell, McDATA
	C. Monia, Nishan Systems
Traduction Claude Brière de L’Isle	M. Merhar, Sun Microsystems

Ralph Weber	Murali Rajagopal	Franco Travostino
ENDL Texas	Broadcom	Technology Center
representing Brocade Comm.	16215 Alton Parkway	Nortel Networks, Inc.
Suite 102 PMB 178	PO Box 57013	600 Technology Park
18484 Preston Road	Irvine, CA 92619	Billerica, MA 01821
Dallas, TX 75252USA	USA	USA
téléphone : +1 214 912 1373	téléphone : +1 949 450 8700	téléphone : +1 978 288 7708
mél : roweber@ieee.org	mél : muralir@broadcom.com	mél : travos@nortelnetworks.com

Michael E. O'Donnell	Charles Monia	Milan J. Merhar
McDATA Corporation	mél : cmonia@pacbell.net	Sun Microsystems
4 McDATA Parkway		43 Nagog Park
Broomfield, Co. 80021		Acton, MA 01720
USA		USA
téléphone : +1 720 558 4142		téléphone : +1 978 206 9124
mél : mike.o'donnell@mcdata.com		mél : milan.merhar@sun.com