Groupe de travail Réseau	D. Katz, Juniper Networks	
Request for Comments : 5303	R. Saluja, Tenet Technologies	
Rend obsolète la RFC3373	D. Eastlake 3rd, Eastlake Enterprises	
Catégorie : Sur la voie de la normalisation	octobre 2008	
	Traduction Claude Brière de L'Isle	

Prise de contact à trois phases pour les adjacences point à point de système intermédiaire à système intermédiaire (IS-IS)

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

Notice de copyright
Copyright (C) The Internet Society (2008).

Résumé
Le protocole d'acheminement de système intermédiaire à système intermédiaire (IS-IS, Intermediate System to Intermediate System) [ISO10589] exige des protocoles fiables à la couche de liaison pour les liaisons point à point. Par suite, il n'utilise pas de prise de contact à trois phases lors de l'établissement des adjacences sur un support en point à point. Le présent document définit une extension rétro compatible au protocole qui fournit une prise de contact à trois phases. Elle est pleinement interopérable avec les systèmes qui ne prennent pas en charge l'extension.

De plus, l'extension permet un fonctionnement robuste de plus de 256 liaisons en point à point sur un seul routeur.

Cette extension a été mise en œuvre par plusieurs fabricants de routeurs ; le présent document est fourni à la communauté de l'Internet afin de permettre que des mises en œuvre inter opérables soient construites par d'autres fabricants.
Table des matières
1. Introduction	1
1.1 Terminologie	2
2. Vue d'ensemble des extensions	2
2.1 Prise de contact	2
2.2 Plus de 256 interfaces	3
3. Détails	3
3.1 Syntaxe	3
3.2 Éléments de procédure	4
4. Considérations relatives à l'IANA	5
5. Considérations sur la sécurité	5
6. Changements par rapport à la RFC 3373	5
7. Remerciements	5
8. Références normatives	5
9. Références pour information	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction

Le protocole IS-IS [ISO10589] suppose certaines exigences, déclarées dans son paragraphe 6.7.2, pour le fonctionnement de IS-IS sur des liaisons en point à point et fournit donc seulement une prise de contact en deux phases quand il établit des adjacences sur des liaisons en point à point. Le protocole ne fonctionne pas correctement si ces exigences de sous réseau pour les liaisons en point à point ne sont pas satisfaites. Le mécanisme de base défini dans la norme est que chaque côté déclare que l'autre côté est accessible si un paquet Hello est reçu de lui. Une fois que c'est fait, chaque côté envoie alors une PDU Numéro de séquence complet (CSNP, Complete Sequence Number PDU) pour déclencher la synchronisation de base de données.

Trois modes d'échec sont connus. D'abord, si la liaison a une défaillance puis revient au service, ou si un des systèmes redémarre, et que le paquet CSNP est perdu, et si le réseau a un ensemble de coupure de un à travers la liaison, les bases de données d'état de liaison de l'un ou l'autre côté de la liaison ne vont pas se synchroniser pendant toute une période de rafraîchissement d'unité de données de protocole d'état de liaison (LSP, Link State Protocol Data Unit) (jusqu'à 18 heures).

Une seconde défaillance, plus sérieuse est que si la liaison échoue dans une seule direction, la défaillance va seulement être détectée par un des systèmes. Normalement un seul des deux systèmes va annoncer l'adjacence dans ses paquets d'état de liaison, et l'algorithme de plus court chemin en premier (SPF, Shortest Path First) va donc ignorer la liaison. Cependant, si il y a deux liaisons parallèles entre les systèmes et qu'une d'elles est défaillante dans une direction, SPF va quand même calculer les chemins entre les deux systèmes, et le système qui n'a pas remarqué la défaillance va tenter de passer du trafic sur la liaison défaillante (dans la direction qui ne fonctionne pas).

Le troisième problème est que sur certaines couches physiques, l'inter connectivité entre points d'extrémité peut changer sans causer de condition de défaillance de couche de liaison. Dans ce cas, un système peut recevoir des paquets qui sont en fait destinés à un système différent (ou une liaison différente sur le même système). Le système receveur peut finir par penser qu'il a une adjacence avec le système distant quand en fait celui-ci est adjacent à un troisième système.

La solution proposée ici assure un fonctionnement correct du protocole sur des liaisons point à point non fiables. Au titre de la solution du problème de la prise de contact en trois phases, une méthode est définie pour supprimer la limitation de 255 interfaces point à point imposée par IS-IS [ISO10589]. Cette méthode est plus robuste que les méthodes ad hoc actuellement utilisées.

 	1.1	Terminologie
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Vue d'ensemble des extensions

Cette Section donne une vue générale de la prise de contact en trois phases fournie et de la façon dont 256 interfaces ou plus sont traitées.

 	2.1	Prise de contact
L'intention est de fournir une prise de contact en trois phases pour l'établissement d'une adjacence point à point de façon rétro compatible. Ceci est fait en fournissant un mécanisme facultatif qui permet à chaque système de faire rapport de ses états d'adjacence en trois phases, permettant donc à un système de ne déclarer une adjacence comme étant active que si il sait que l'autre système reçoit ses paquets Hello IS-IS (IIH, IS-IS Hello).

L'état d'adjacence en trois phases peut être d'un des types suivants :

Désactivé : c'est l'état initial d'adjacence point à point en trois phases. Le système n'a pas reçu de paquet IIH contenant l'option de prise de contact en trois phases sur ce circuit en point à point.

Initialisation : le système a reçu un paquet IIH contenant l'option de prise de contact en trois phases d'un voisin mais ne sait pas si le voisin reçoit son paquet IIH.

Activé : le système sait que le voisin reçoit ses paquets IIH.

L'état d'adjacence en trois phases qui est rapporté par ce mécanisme n'est pas égal ou équivalent à l'état d'adjacence qui est décrit dans [ISO10589]. Si ce mécanisme est pris en charge, l'adjacence peut alors avoir deux états, son état défini dans [ISO10589], et son état à trois phases. Par exemple, selon ISO 10589, la réception d'un Hello de système intermédiaire (ISH, Intermediate System Hello) va causer le passage de l'adjacence à l'état Initialisation ; cependant, la réception d'un ISH n'aura pas d'effet sur l'état à trois phases d'une adjacence, qui va rester désactivé jusqu'à ce qu'il reçoive un IIH d'un voisin qui contient l'option de prise de contact à trois phases.

De plus, l'identifiant de système du voisin et l'identifiant de circuit (nouvellement défini) étendu sont rapportés afin de détecter le cas où le même flux est reçu par plusieurs systèmes (dont un seul peut répondre).

Le mécanisme est assez similaire à celui défini dans le protocole de services de liaison Netware (NLSP, Netware Link Services Protocol) [NetLink], une variante de IS-IS utilisée pour acheminer le trafic d'échange de paquets d'inter réseaux (IPX, Internetwork Packet Exchange). La différence entre ce mécanisme et celui utilisé dans NLSP est la localisation où les informations sont portées (NLSP utilise deux des bits réservés dans l'en-tête IIH, tandis que cette solution ajoute une option séparée à l'IIH) et la présence de l'identifiant de système et de l'identifiant de circuit du voisin. En théorie, utiliser les bits d'en-tête réservés devrait être rétro compatible, car les systèmes sont supposés les ignorer. Cependant, il a été estimé que c'était risqué, car l'utilisation de mécanismes non vérifiés comme celui là a conduit à des problèmes dans le passé dans d'autres protocoles. D'autre part, de nouveaux codes d'option ont été démontrés fonctionner correctement, car le déploiement de IS-IS intégré pour IP [RFC1195] a fait exactement cela.

Le nouveau mécanisme ne vient en jeu que quand le système distant inclut la nouvelle option dans son paquet IIH ; si l'option n'est pas présente, on va supposer que le système ne prend pas en charge le nouveau mécanisme, et donc les anciennes procédures sont utilisées.

 	2.2	Plus de 256 interfaces
La spécification IS-IS a une limite implicite de 256 interfaces, contrainte par le champ de huit bits Identifiant de circuit porté dans divers paquets. Des mises en œuvre modérément habiles ont réalisé que la seule vraie contrainte est celle de 256 interfaces de LAN, et que pour cette raison seules 256 interfaces de LAN pour lesquelles un système est l'IS désigné. C'est parce que le seul endroit où l'identifiant de circuit est annoncé dans les LSP est dans l'identifiant de LSP de pseudo nœud.

Les mises en œuvre ont traité l'espace de numéros d'identifiant de circuit point à point comme étant indépendant de celui des interfaces de LAN, car ces identifiants de circuit n'apparaissent que dans les PDU IIH et sont seulement utilisés pour la détection d'un changement d'identité à l'autre extrémité d'une liaison. Plus de 256 interfaces point à point ont été prises en charge en envoyant le même identifiant de circuit sur plusieurs interfaces. Cela réduit la robustesse de l'algorithme de détection de changement d'identifiant, car il serait alors possible de changer les liaisons entre interfaces sur un système sans détecter le changement.

Comme l'identifiant de circuit est partie intégrante du nouveau mécanisme de prise de contact, un mécanisme rétro compatible pour étendre l'espace de numéros d'identifiants de circuit est inclus dans la présente spécification.

 	3.	Détails

La syntaxe et les procédures détaillées pour cette option IS-IS sont données ci-dessous.

 	3.1	Syntaxe
Un nouveau type d'option IS-IS, "Adjacence en trois phases point à point", est défini :

Type : 0xF0 (décimal 240)

Longueur : longueur totale du champ Valeur (1 à 17 octets)

Valeur :
                                       Nombre d'octets
+-----------------------------------+
| État d'adjacence trois phases     |      1
+-----------------------------------+
| ID étendu de circuit local        |      4
+-----------------------------------+
| Identifiant de système voisin     |  Longueur d'identifiant
+-----------------------------------+
| ID étendu de circuit local voisin |      4
+-----------------------------------+

État d'adjacence trois phases : l'état d'adjacence trois phases de l'adjacence point à point.
Les valeurs suivantes sont définies :
0 : Activé
1 : Initialisation
2 : Désactivé

Identifiant étendu de circuit local : identifiant univoque alloué à ce circuit quand il est créé par ce système intermédiaire.

Identifiant de système voisin : identifiant de système du système intermédiaire voisin si il est connu. La longueur de ce champ est égale à "Longueur d'identifiant" de la PDU IIH décrite dans la "PDU Hello de IS-IS point à point " (paragraphe  9.7 de [ISO10589]).

Identifiant étendu de circuit local voisin : identifiant étendu de circuit local de l'autre extrémité de l'adjacence point à point si il est connu.

Tout système qui prend en charge ce mécanisme DEVRA inclure cette option dans ses paquets IIH point à point.

Tout système qui ne comprend pas cette option DEVRA l'ignorer, et (bien sûr) NE DEVRA PAS l'inclure dans ses propres paquets IIH.

Tout système qui prend en charge ce mécanisme DOIT inclure le champ État d'adjacence trois phases dans cette option. Les autres champs dans cette option DEVRAIENT être inclus comme indiqué au paragraphe 3.2.

Tout système qui est capable de traiter cette option DEVRA suivre les procédures ci-dessous.

 	3.2	Éléments de procédure
La nouvelle procédure de prise de contact est ajoutée à l'automate à états IIH point à point IS-IS après que les essais d'acceptation de PDU ont été effectués.

Bien que l'identifiant étendu de circuit soit seulement utilisé dans le contexte de la prise de contact en trois phases, on notera qu'il protège effectivement contre l'événement improbable où une liaison est déplacée sur une autre interface sur un système qui a le même identifiant de circuit local, parce que les PDU reçues vont être ignorées (via les vérifications définies ci-dessous) et que l'adjacence existante va échouer.

Ajout d'un point e) à la fin de "Réception des PDU ISH par un système intermédiaire" (paragraphe 8.2.2 de [ISO10589]) :
Régler l'état à rapporter dans le champ État d'adjacence trois phases de l'option Adjacence trois phases point à point à Désactivé.

Ajout d'un point e) à la fin de "Envoi des PDU IIH point à point" (paragraphe 8.2.3 de [ISO10589]) :
L'IS DEVRA inclure l'option Adjacence trois phases point à point dans la PDU IIH point à point transmise. L'état trois phases actuel de l'adjacence avec son voisin sur la liaison (comme défini dans un nouveau paragraphe 8.2.4.1.1 introduit plus loin) DEVRA être rapporté dans le champ État d'adjacence trois phases. Si aucune adjacence n'existe, l'état DEVRA être rapporté comme Désactivé.

Le champ Identifiant étendu de circuit local DEVRA contenir une valeur allouée par cet IS quand le circuit est créé. Cette valeur DEVRA être unique parmi tous les circuits de ce système intermédiaire. La valeur n'est pas nécessairement en relation avec celle portée dans le champ Identifiant de circuit local de la PDU IIH.

Si l'identifiant de système et l'identifiant étendu de circuit local du système voisin sont connus (dans l'état d'adjacence trois phase Initialisation ou Activé) l'identifiant de système du voisin DEVRA être rapporté dans le champ Identifiant de système voisin, et l'identifiant étendu de circuit local du voisin DEVRA être rapporté dans le champ Identifiant étendu de circuit locale de voisin.

Ajout d'un paragraphe 8.2.4.1.1, "Prise de contact en trois phases", immédiatement avant "Traitement de PDU IIH" (paragraphe 8.2.4.2 de [ISO10589]) :
Une PDU IIH point à point reçue peut ou non contenir l'option Adjacence trois phases point à point. Si elle ne la contient pas, la liaison est supposée être fonctionnelle dans les deux directions, et les procédures décrites au paragraphe 8.2.4.2 sont suivies.

Si l'option est présente et contient un état d'adjacence trois phases invalide, la PDU DEVRA être éliminée et aucune autre action n'est effectuée.

Si l'option avec un état d'adjacence trois phases valide est présente, les champs Identifiant de système voisin et Identifiant étendu de circuit local voisin, si ils sont présents, DEVRONT être examinés. Si ils sont présents, et si l'identifiant de système voisin contenu ne correspond pas à l'identifiant de système local, ou si l'identifiant étendu de circuit local voisin ne correspond pas à l'identifiant étendu de circuit du système local, la PDU DEVRA être éliminée et aucune autre action n'est effectuée.

Si les champs Identifiant de système voisin et Identifiant étendu de circuit local voisin correspondent à ceux du système local, ou ne sont pas présents, les procédures décrites au paragraphe 8.2.4.2 sont suivies avec les changements suivants :

a) Au paragraphe 8.2.4.2 a et b, l'action "Activé" des tableaux d'état 5, 6, 7, et 8 peut créer une nouvelle adjacence mais l'état trois phases de l'adjacence DEVRA être Désactivé.

b) Si l'action effectuée au paragraphe 8.2.4.2 a ou b est "Activé" ou "Accepte", le IS DEVRA effectuer l'action indiquée par le tableau d'état de nouvelle adjacence trois phases ci-dessous, sur la base de l'état actuel d'adjacence trois phases et la valeur reçue d'état d'adjacence trois phases de l'option. (Noter que la procédure fonctionne correctement si aucun champ n'est inclus. Cela assure la rétro compatibilité avec une version antérieure de cette option.)

	État d'adjacence trois phases reçu
                                             Désactivé    Initialisation    Activé
État                 Désactivé    |  Initialiser       Activé         Désactivé
d'adjacence                        |
trois             Initialisation   |  Initialiser       Activé        Activé
phases                                 |
                      Activé            |  Initialiser        Accepté      Accepté

Tableau d'état d'adjacence trois phases

Si la nouvelle action est "Désactivé", un événement adjacencyStateChange(Down) est généré avec la raison "Voisin redémarré" et l'adjacence DEVRA être supprimée.

Si la nouvelle action est "Initialiser", aucun événement n'est généré et l'état d'adjacence trois phases DEVRA être régélé à "Initialisation".

Si la nouvelle action est "Activé", un événement adjacencyStateChange(Up) est généré.

c) Sauter le paragraphe 8.2.4.2 c et d.

d) Si la nouvelle action est "Initialiser", "Activé", ou "Accepter", suivre le paragraphe 8.2.4.2 e.

 	4.	Considérations relatives à l'IANA

Le présent document spécifie l'option IS-IS 240 (0xF0), qui a déjà été allouée. Voir la [RFC3359].

 	5.	Considérations sur la sécurité

Le présent document ne soulève pas de nouvelle question de sécurité pour IS-IS. La sécurité IS-IS peut être utilisée pour sécuriser les messages IS-IS discutés ici. Voir la [RFC5304].

 	6.	Changements par rapport à la RFC 3373

Le présent document fait des corrections rédactionnelles mineures à la [RFC3373] dans l'intention de l'avancer du statut de Information à "sur la voie de la normalisation". Il met aussi à jour la référence à la norme internationale ISO 10589 pour se référer à la version actuelle "2002".

 	7.	Remerciements

Merci à Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg, et Philip Christian de leurs contributions à ce document.

 	8.	Références normatives

[ISO10589]	Norme internationale ISO 10589, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion(ISO8473)", seconde édition, 2002.

[NetLink]	"Netware Link Services Protocol Specification, Version 1.0", Novell, Inc., février 1994.

[RFC1195]	R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", décembre 1990. (Mise à jour par les RFC 1349, 5302, 5304)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

 	9.	Références pour information

[RFC3359]	T. Przygienda, "Codets de type, longueur et valeur (TLV) réservés de système intermédiaire à système intermédiaire", août 2002. (Information)

[RFC3373]	D. Katz, R. Saluja, "Prise de contact à trois phases pour les adjacences point à point de système intermédiaire à système intermédiaire (IS-IS)", septembre 2002. (Obsolète, voir RFC5303) (Information)

[RFC5304]	T. Li et R. Atkinson, "Authentification cryptographique IS-IS", octobre 2008. (Remplace RFC3567, MàJ RFC1195) (PS, MàJ par RFC6233, RFC6232)

 	Adresse des auteurs

Dave Katz	Rajesh Saluja	Donald E. Eastlake 3rd	
Juniper Networks	Tenet Technologies	Eastlake Enterprises	
1194 N. Mathilda Ave.	30/31, 100 Feet Road, Madiwala	155 Beaver Street	
Sunnyvale, CA  94089	Bangalore - 560 068	Milford, MA  01757	
USA	INDIA	USA	
téléphone : +1-408-745-2073	téléphone : +91 80 552 2215	téléphone : +1-508-634-2066	
mél :  dkatz@juniper.net 	mél : rajesh.saluja@tenetindia.com 	mél : d3e3e3@gmail.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2008).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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.

Propriété intellectuelle
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 .

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